Durante los últimos meses muchos clientes nos están preguntando como deberían migrar sus actuales bases de datos SQL a Azure, con este artículo queremos resumir cuales son las opciones actuales y que datos importantes hay que tener en cuenta.

1ºPaso : Qué es lo que tenemos actualmente.

Lo primero que hay que revisar es que versión de SQL tenemos y que funcionalidades estamos usando actualmente en nuestras bases de datos, para ello nos vamos a ayudar de una herramienta gratuita que Microsoft nos proporciona llamada «Data Migration Assistant»  https://www.microsoft.com/en-us/download/details.aspx?id=53595, mediante esta herramienta vamos a poder descubrir si estamos utilizando alguna funcionalidad no compatible tanto a nivel de motor/instancia de SQL como dentro de la definición de los objetos dentro de nuestras bases de datos. Esta herramienta te ofrece varias variantes para comprobar si tu base de datos es compatible con los diferentes destinos que podemos elegir actualmente en Azure.

 

 

Lo más importante de esta herramienta es que nos avisa de características bloqueantes que estemos usando y que nos limitan a la hora de poder ir a un destino u otro, como, por ejemplo:

  • Si tenemos linked server definidos en nuestra instancia actual, no podremos ir a SQL Azure, pero si podemos ir a una Instancia Manejada en Azure.
  • Si en nuestro código tenemos consultas cruzadas entre varias bases de datos nos avisará que esto no está soportado en SQL Azure.
  • Si utilizamos jobs de SQL, nos avisará que no podemos migrar a SQL Azure.

Por tanto, esta herramienta nos va a ahorrar una parte de trabajo, para no tener que mirar de forma manual que características tenemos que no nos permiten migrar a PaaS (SQL Azure o Instancia manejada) o IaaS (MV con SQL). Pero como todo, hay parte que nos va a tocar a nosotros mirar:

  • Antes comentábamos la funcionalidad de los linked servers, la herramienta nos avisa de su existencia, pero aquí nosotros tenemos que realizar un chequeo manual, porque no vale con cualquier linked server, si éste está conectado a una fuente diferente de una instancia Microsoft SQL Server, no vamos a poder crearlo en la Instancia Manejada, por tanto solo nos queda la opción de irnos a un entorno IaaS con una máquina virtual en Azure con el Sistema Operativo y el SQL instalado.
  • Si aparte del motor relacional tenemos otros motores instalados como son SSIS, SSAS y SSRS. Aquí nos va a tocar tener que revisar su contenido, teniendo en cuenta lo siguiente:
    • Los paquetes de SSIS tienen como posible destino en Azure ser migrados a Azure Data Factory, pero aquí hay que ver con que fuentes de datos estamos trabajando, si estos están en Azure o en local, para ver las diferentes alternativas de diseñar la arquitectura de Azure Data Factory.
    • Si tenemos SSAS y está configurado en modo multidimensional, si no queremos migrarlo a Tabular solo nos queda la opción de ir a SaaS con una MV con SSAS instalado. SI tenemos un SSAS configurado como Tabular tenemos la opción de migrarlo a Azure Análisis Services.
    • Si tenemos SSRS, hay que revisar si podemos ir a Power Bi Services o si no es posible, tenemos la opción de ir a IaaS con una MV con SSRS instalado.
  • Hay que revisar que aplicaciones y que servicios trabajan con las bases de datos que queremos migrar a Azure, por varias razones:
    • Si es una aplicación de terceros que te obliga a cumplir con una serie de requisitos: versión de SQL, tipo de conexión, etc. Lo más seguro es que tengas que acabar yéndote a IaaS con una MV con su versión especifica de SQL.
    • Hay que revisar el trasiego de datos entre lo que se queda en local y lo que se va a Azure, para conocer si el ancho de banda que tenemos entre local y Azure es suficiente para esa carga.
    • Tamaños de las bases de datos, esto es importante porque en SQL Azure tenemos según el nivel de servicio un límite de 1 a 4 TB.
    • Tipo de seguridad, comprobar si utilizamos seguridad Windows o nativa de SQL. SI utilizamos seguridad integrada deberemos de migrarla con el directorio activo de Azure.

 

2º PASO: Qué servicio de Azure escogemos

Una vez que tenemos todos los datos del paso anterior, ya habremos hecho una primera criba y tendremos claro si podemos ir hacia un entorno IaaS o PaaS.

Por nuestra experiencia sabemos que en las migraciones complejas una de las primeras opciones es migrar a IaaS porque la dificultad de modificar la funcionalidades no compatibles con PaaS es a tener en cuenta. Además, como hemos comentado antes, si hay aplicaciones de terceros que nos fuerzan a versiones concretas del sistema operativo o del motor de base de datos para poder migrar a PaaS hay que coordinarse, si es posible, con el desarrollador de la aplicación, lo que lo complica aún más. Cuando nos encontramos con este tipo de escenarios una de las estrategias que poder seguir es migrar a Azure en IaaS como primer paso y luego, con todo en Azure, ir planteando evolutivos que paso a paso nos permitan aprovecharnos de las ventajas de una migración a PaaS.

Pasamos a destacar los principales puntos a tener en cuenta de cada uno de los posibles destinos en Azure:

IaaS (Máquina virtual en Azure)

Si nos vamos a IaaS, tenemos que tener en cuenta que tendremos que pagar por la máquina y por las licencias del sistema operativo y del motor de SQL, para ello habrá que hacer cuentas y ver si nos podemos aprovechar de algún beneficio que Microsoft aporte por migrar a Azure.

Además, tendremos que seguir realizando las tareas propias de administración del Sistema Operativo y los servicios de SQL.

Una herramienta que nos puede ayudar a decidir que máquina necesitamos en el entorno IaaS, es Microsoft Assesment and Planning (MAP) https://www.microsoft.com/en-us/download/details.aspx?id=7826, esta herramienta permite recoger datos de consumo de recursos de las servidores actuales de SQL a migrar y darnos una idea aproximada de que tipo de máquina en Azure necesitaríamos para poder aguantar la carga actual.

 

PaaS (SQL Azure o Instancia Manejada)

En esta plataforma ya no tenemos que realizar las tareas administrativas del Sistema Operativo y el servicio de SQL, y siempre estaremos a la última versión.

Para las bases de datos que podemos migrar a PaaS directamente, tendremos que decidir a qué nivel de servicio por precio y funcionalidad nos interesa:

SQL AZURE

 Esta opción la solemos elegir cuando estamos migrando una sola base de datos que hemos revisado que no tiene ningún bloqueante y que el tamaño de la base de datos no es mayor de 4TB.

Tenemos dos sabores por DTU o por Vcores.

Un poco de historia aquí: el modelo DTU (Unidad de transacción de base de datos) fue el primero en introducirse con Azure SQL DB. DTU es una medida; una mezcla de memoria de CPU e IO. La idea era crear una medida que nos diera una idea relativa de la cantidad de energía o recursos detrás de la base de datos: cuanto mayor sea el número de DTU, más potente será la base de datos que tengamos.

El rango de DTU va de 5 en el extremo inferior hasta 4,000 en el extremo superior. El problema para muchos era no saber exactamente qué era una DTU. Después de un tiempo, Microsoft ha querido dar respuesta a esa pregunta introduciendo el precio por vCore. vCore es la abreviatura de núcleo virtual y es un modelo que está diseñado para simplificar la traducción de sus especificaciones de recursos de hardware premier en especificaciones similares en la plataforma de base de datos SQL Azure.

Es decir, con vCore, tienes cierta visibilidad de la cantidad real de RAM que está disponible, así como también una idea del tipo de procesador y la velocidad del procesador que se está utilizando en el hardware. Con el modelo DTU, todo eso es solo parte del servicio, por lo que no se conocen esos detalles.

Algunas notas:

      • Es importante tener en cuenta que en ambos casos el servicio tiene un precio por base de datos.
      • Con el modelo DTU, pagas un precio fijo por su cómputo (o E / S), así como por su almacenamiento de datos y retención de copias de seguridad.
      • Con el modelo vCore, tienes por un lado cargos por computación (qué tipo de nodo o potencia de cómputo estás usando) y por otro cargos por almacenamiento. Con vCore, tienes más flexibilidad para administrar tus gastos que con DTU.

El elegir un modelo u otro no te ata a ese modelo, puedes cambiar entre ellos. Por tanto a la pregunta ¿cuál debo usar? La respuesta es simple, depende. El modelo DTU es más simple en cuanto a la cantidad de opciones que tiene ya que con un precio fijo lo incluye todo. El modelo vCore brinda más flexibilidad y transparencia en lo que se está pagando.

En resumen, por simplicidad, el modelo DTU tiene ventaja. Además, si estas comenzando con Azure SQL Database, el modelo DTU ofrece más opciones en el extremo inferior del rendimiento, por lo que puedes comenzar a un precio más bajo que con vCore. Si tienes garantía de software con Microsoft y estas familiarizado con cómo funciona, existen algunas ventajas al usar vCore. Si no estás familiarizado con la garantía de software, puedes comenzar con el modelo DTU.

Instancia Manejada

Esta opción la elegimos cuando estamos migrando una instancia completa con todas sus bases de datos y en el paso primero no hemos detectado ningún bloqueante que no nos permita migrar a esta opción.

Este tipo de servicio PaaS, es el más parecido a una instancia de SQL en local con la ventaja de que no nos tenemos que preocupar de las típicas tareas de administración, como son: aplicación de revisiones y actualizaciones de versión automáticas, copia de seguridad automáticaalta disponibilidad.

Resumen

Lo primero que tendremos que revisar es si nuestra instancia o base de datos tiene alguna funcionalidad bloqueante para migrar a alguno de los posibles destinos en Azure, ya sea a PaaS como a IaaS. Una vez revisado y según los resultados, podremos encontrar instancias o base de datos que solo se puedan migrar directamente (sin cambios) a IaaS y otras que sí podremos PaaS sin grandes cambios. Por último, en las que se pueden migrar a PaaS nos deberemos decidir si es mejor a SQL Azure o a Instancia Manejada, teniendo en cuenta las limitaciones y el precio de cada opción.

Una vez decidido el destino, deberemos de planificar el proceso de migración, que intentaremos explicaros en próximas entradas del blog.

Por nuestra parte, ponemos a vuestra disposición toda nuestra experiencia en la realización de migraciones. Puedes ver más información en: https://www.solidq.com/es/consultoria/data-platform-modernization/

José Antonio Pineda
Últimas entradas de José Antonio Pineda (ver todo)