Un cliente quiere migrar su entorno SQL Server a un entorno en la nube de Microsoft Azure y nos ha pedido que le ayudemos en el proceso. Hemos redactado para ellos una informe sobre las distintas opciones de los entornos Azure SQL Server y las distintas formas de migración que actualmente son una opción viable.
Dado que esto es algo que cada vez va a ser más habitual en todas las empresas, he pensado en escribir un articulo usando la información de este informe pero de forma un poco más general y que se pueda aplicar a cualquier empresa.
Tened en cuenta que esto va a ser información escrita en inglés para un cliente y que yo voy a traducir para vosotros, por lo que además de ir a ser una chapa antológica puede que algunas cositas suenen raras.
Opciones de destino para la migración a Azure
Máquina Virtual de Azure SQL Server
La Máquina Virtual de Azure SQL proporciona una versión completa de SQL Server en la nube sin necesidad de gestionar ningún hardware local. La Máquina Virtual de Azure SQL es generalmente la mejor opción si:
- La aplicación solo funcionará en una versión específica.
- Se requiere acceso a nivel del sistema operativo (es decir, ejecutar scripts externos, automatización OLE, etc.).
- Se requieren servicios adicionales de SQL Server (SSIS/SSAS/SSRS) para ejecutarse de forma nativa (es decir, no se pueden migrar a la nube).
- Se siguen necesitando tecnologías de Alta Disponibilidad y Recuperación ante Desastres heredadas (por ejemplo, mirroring de bases de datos).
- Se requiere la función FILESTREAM.
Ventajas
- Proporciona una versión completa de SQL Server en la nube sin necesidad de gestionar hardware local.
- Permite utilizar fácilmente otras características de SQL Server, como SSRS, SSIS, etc.
- Control total del motor de SQL Server.
- Fácil migración a Azure, ya que no se requiere migrar el servidor SQL.
- Posibilidad de controlar qué versión de SQL Server se instala.
- Posibilidad de utilizar el sistema operativo como si estuviera en local.
Desventajas
- Es necesario diseñar e implementar tu propia solución de Alta Disponibilidad.
- Es posible que se requiera tiempo de inactividad al escalar los recursos de la máquina virtual (ampliar RAM, CPU etc).
- Las copias de seguridad y las actualizaciones pueden automatizarse, PERO requieren configuración adicional.
Alta Disponibilidad/Recuperación ante Desastres en Azure SQL VM
A nivel de base de datos, existen opciones como el envío de registros (log-shipping) y la Alta Disponibilidad AlwaysOn. Estas opciones deben diseñarse e implementarse por ti mismo. A nivel de la Máquina Virtual de Azure, puedes configurar conjuntos/zonas de disponibilidad. También tienes acceso a Azure Site Recovery, que proporciona la capacidad de cambiar desde la ubicación primaria a la secundaria.
Además de lo anterior, se pueden configurar clústeres de Windows Server a través de regiones, utilizando redes virtuales (vNet peering) y un balanceador de carga de Azure, siempre que las Máquinas Virtuales estén en el mismo dominio (ten en cuenta que, estrictamente hablando, esto sería Recuperación ante Desastres en lugar de Alta Disponibilidad, ya que la sincronización del Grupo de Disponibilidad [AG] se configuraría como asíncrona debido a la posible latencia de red entre regiones).
Recomendaciones
La Máquina Virtual de Azure SQL es una opción deseable, especialmente si el proveedor de software independiente (ISV) ha aprobado la aplicación para una versión específica de SQL. Esto es igual que ejecutar SQL Server en local, con la capacidad de configurar tu propia Alta Disponibilidad/Recuperación ante Desastres y escalar fácilmente a través del Portal de Azure. A nivel de la Máquina Virtual, Azure también ofrece diversas opciones de Recuperación ante Desastres para hacer que las Máquinas Virtuales sean altamente disponibles (como los conjuntos de disponibilidad).
Azure SQL Managed Instance
Azure SQL Managed Instance (MI) es un servicio completamente gestionado que se encarga de la mayoría de las tareas de administración, como parches y copias de seguridad, sin necesidad de intervención del usuario. Sin embargo, aunque las instancias administradas de SQL proporcionan un motor completo de SQL Server junto con SQL Server Agent, no se tiene acceso al sistema operativo subyacente. Basicamente tendreis una instancia SQL Server pero no podreis gestionar absolutamente nada del SO ni del Windows Server.
SQL MI tiene parches y copias de seguridad automatizadas. SQL MI también cuenta con ajuste automático, similar a Azure SQL DB, pero solo está disponible la opción «Forzar el último plan válido» (donde, si se identifica un plan de ejecución de una query «malo», se forzará automáticamente el «último plan válido» en lugar de requerir entrada manual por nuestra parte). Al crear una instancia de Azure SQL MI, esta se crea en su propia red virtual (VNET). El cifrado transparente de datos (TDE) está habilitado de forma predeterminada para todas las bases de datos, y la función de Protección contra Amenazas Avanzada también está disponible si se desea habilitar.
SQL MI solo admite el modelo de compra de vCore, y hay dos niveles de servicio disponibles: Uso General y Crítico para el Negocio. Ambos niveles de servicio garantizan una disponibilidad del 99.99%; sin embargo, Business Critical proporciona una resiliencia adicional más allá del nivel General Purpose, mediante el uso de varias réplicas aisladas. Business Critical también ofrece el rendimiento de E/S más alto y la capacidad de utilizar una réplica de solo lectura con fines de informes (o dos réplicas de solo lectura cuando se han configurado grupos de conmutación por error).
SQL MI también cuenta con el beneficio de Intelligent Insights, que monitoriza constantemente el rendimiento de las base de datos y de la instancia.
SQL MI se beneficia de la Protección contra Amenazas Avanzada, que incluye una evaluación de vulnerabilidades; esto identifica posibles vulnerabilidades en la base de datos y monitoriza las bases de datos en busca de actividades sospechosas, como ataques de inyección SQL.
Ventajas
- Muy similar a una instancia completa de SQL Server local, pero sin acceso al sistema operativo subyacente.
- Los parches y copias de seguridad se realizan automáticamente.
- Se pueden realizar copias de seguridad adicionales de tipo ad hoc en el almacenamiento de blobs de Azure.
- Acceso a SQL Server Agent, lo que significa que se pueden programar trabajos de forma nativa como se haría en una instancia local de SQL Server.
- Se pueden ejecutar consultas entre bases de datos.
- Se pueden crear varios grupos de archivos.
Desventajas
- Similar a Azure SQL DB, existen diferentes niveles de servicio. Los niveles de servicio deben ser examinados cuidadosamente antes de decidir, ya que esto podría afectar el costo total del entorno (por ejemplo, el costo del nivel de servicio Business Critical es aproximadamente el doble que el de General Purpose).
- No se tiene acceso al sistema operativo (es ventaja y desventaja a la vez, lo sé).
- Es posible que sea necesario actualizar la aplicación antes de migrar a SQL MI, ya que SQL MI siempre se ejecutará en la última versión de SQL Server.
- No se admite la conexión de una base de datos existente.
Alta disponibilidad/Recuperación ante desastres
En cuanto a las ventanas de mantenimiento, Azure SQL MI siempre se asegura de que las regiones emparejadas de Azure no se actualicen al mismo tiempo, pero no se garantiza qué región se actualizará primero. Por ejemplo, para la ubicación «Europa», el par regional A sería Europa del Norte (Irlanda) y el par regional B sería Europa Occidental (Países Bajos). Si se utiliza la función de failover por error, Microsoft recomienda elegir ventanas de mantenimiento diferentes para el principal y el secundario.
Recomendaciones
Azure SQL MI sería una opción realmente buena para migrar, ya que es muy similar a SQL Server local y SQL Server en una máquina virtual de Azure. Sin embargo, al ser un servicio gestionado, no se requiere realizar tareas de mantenimiento, como aplicar parches o tomar copias de seguridad. Permite realizar copias de seguridad ad hoc de solo lectura y almacenarlas en Azure Storage. SQL MI cuenta con grupos de failover para proporcionar una solución de alta disponibilidad/recuperación ante desastres resistente, y también tiene la capacidad de proporcionar réplicas de solo lectura. Sin embargo, si se desea tener un control más específico sobre las versiones/niveles de parches de SQL Server que se ejecutan, se debe considerar una solución alternativa.
Azure SQL Database
Azure SQL Database (DB) es un servicio completamente administrado que maneja la mayoría de las tareas de gestión, como parches y copias de seguridad, sin necesidad de intervención del usuario. Con Azure SQL DB, es posible crear una única base de datos independiente o varias bases de datos. También es posible crear múltiples bases de datos en un grupo elástico con un conjunto compartido de recursos, como CPU y memoria.
Antes de crear una base de datos, es necesario crear un servidor lógico; esto permite administrar inicios de sesión, reglas de firewall, reglas de auditoría y grupos de conmutación por error.
Azure SQL DB ofrece dos modelos de compra diferentes: el modelo de compra de vCore y el modelo de compra de DTU. Cada modelo de compra tiene tres niveles de servicio diferentes; vCore ofrece «General Purpose», «Business Critical» e «Hyperscale», y DTU ofrece «Basic», «Standard» y «Premium».
Azure SQL DB también ofrece funciones como Intelligent Insights y Automatic Tuning. Intelligent Insights supervisa automáticamente el rendimiento de todas las bases de datos, informa sobre cualquier problema de rendimiento y proporciona recomendaciones cuando sea posible. Por otro lado, el ajuste automático supervisa las cargas de trabajo ejecutadas a nivel de base de datos y puede aplicar automáticamente cambios de índice si se selecciona la opción automática o producir recomendaciones que pueden revisarse antes de ejecutar los cambios.
Azure SQL DB ofrece Advanced Threat Protection, que incluye una evaluación que identifica posibles vulnerabilidades en la base de datos y monitorea las actividades sospechosas, como ataques de inyección SQL.
En cuanto al almacenamiento de copias de seguridad, se dispone de restauración en un momento específico (Point-in-time restore, PITR) y retención a largo plazo (Long term retention, LTR). PITR tiene un período de retención entre 1 y 35 días y normalmente consiste en copias de seguridad full, diferenciales y de logs. PITR puede configurarse para cada base de datos. LTR permite almacenar copias de seguridad durante hasta 10 años y se guarda en el almacenamiento de blobs de Azure.
Ventajas
- Cuenta con la versión más reciente y estable del motor de base de datos de SQL Server.
- SQL DB permite escalar fácilmente sin tiempo de inactividad.
- Microsoft se encarga de todos los parches y las copias de seguridad.
- Alta disponibilidad incorporada, como grupos failover por error y geo-replicación.
- Cuenta con inteligencia integrada con tecnologías como el ajuste automático.
- Incluye supervisión incorporada que luego puede almacenarse en Azure Storage.
Desventajas
- No se puede acceder al sistema operativo.
- No es una instancia completa de SQL Server, por lo que no incluye funciones como SQL Server Agent (la alternativa es usar el servicio Elastic Agent que es propio de Azure).
- No se puede hacer «attach» de una base de datos.
- Existen diferentes niveles de servicio entre los que se puede elegir, lo que podría resultar más costoso para el negocio, y es necesario determinar el nivel de servicio más adecuado según los requisitos comerciales.
- No se admiten funciones como consultas entre bases de datos, ya que las bases de datos son todas independientes (la alternativa es usar consultas elásticas).
- Solo son posibles las copias de seguridad iniciadas por el sistema; no se pueden realizar copias de seguridad iniciadas por el usuario.
- Es posible que se requiera tiempo para el re-desarrollo, ya que Azure SQL DB ejecuta la versión más reciente de SQL Server.
Alta disponibilidad/Recuperación ante desastres
Existen dos opciones; una son los grupos de failover por error (similar a SQL MI), y la otra es la replicación activa entre regiones (active-geo replication). Los grupos de failover por error permiten administrar la replicación y el failover de todas o algunas bases de datos en un servidor lógico hacia otro servidor lógico en otra región. Los grupos de failover pueden ser automáticos o manuales. Se pueden delegar cargas de trabajo de solo lectura desde la base de datos primaria a bases de datos secundarias en un grupo de conmutación por error. Los grupos de failover también proporcionan redirección de extremos. Cuando se produce un failover geográfico, la cadena de conexión de su aplicación no necesita cambiarse ya que siempre se dirige al servidor principal.
La replicación activa entre regiones es una característica que le permite crear una base de datos secundaria legible continuamente sincronizada para una base de datos primaria. Puede iniciar un failover manual hacia el servidor secundario si se produce una interrupción. No tiene una función de failover automático. La replicación activa entre regiones admite múltiples secundarios.
Con las bases de datos en los niveles de servicio premium y Business Critical, es posible colocar las réplicas en diferentes zonas de disponibilidad en la misma región.
Recomendaciones
Esta será la opción más difícil de migrar, ya que Azure SQL DB carece de muchas características clave de SQL Server, como SQL Server Agent, DBMail y consultas entre bases de datos. El cliente deberá invertir mucho tiempo en re-desarrollar las bases de datos, lo que incluirá reescribir las consultas para utilizar consultas elásticas, ya que esa es la alternativa. También se pierde la capacidad de realizar y recuperar copias de seguridad ad hoc, que probablemente sean necesarias para algunos proveedores de aplicaciones. Mala opción para migrar pero quizás una buena opción para empezar desde 0.
Herramientas y Métodos de Migración a Azure SQL Server
Herramienta MAP
Destinos en Azure: Máquina Virtual SQL, Instancia Administrada de SQL, Base de Datos SQL.
La Microsoft Assessment and Planning (MAP) Toolkit proporciona informes detallados de evaluación de preparación, que incluyen información sobre hardware y software, así como recomendaciones prácticas para migraciones completas de servidores con el fin de ayudar en la planificación de migraciones de TI a gran escala. Como resultado de la evaluación del software, esta herramienta puede inventariar con éxito todos los entornos de SQL Server y analizar cada uno de ellos para preparar la migración a Azure. Es útil para identificar servidores o instancias de SQL potencialmente desconocidas, así como para extraer información útil acerca de los servidores o instancias conocidas. Esta información, recopilada en una fuente única, es útil para determinar las especificaciones del hardware del entorno objetivo (como CPUs, memoria, discos, etc.).
Asistente de Migración de Datos (DMA)
Destinos en Azure: Máquina Virtual SQL, Instancia Administrada de SQL (solo evaluación), Base de Datos SQL
DMA es una herramienta útil para verificar la idoneidad de una instancia existente de SQL Server para ser migrada a una tecnología de base de datos de Azure (incluida la VM de SQL). Ayuda a identificar problemas de compatibilidad que puedan afectar la funcionalidad de la base de datos después de la migración, de modo que puedan tenerse en cuenta antes de realizar el cambio a Azure. También recomienda mejoras de rendimiento y fiabilidad, al examinar detalladamente la instancia o bases de datos fuente existentes.
Las características de DMA incluyen:
- Problemas que bloquean la migración (y recomendaciones para resolverlos).
- Características parcialmente compatibles o no compatibles (y recomendaciones para resolverlos o encontrar soluciones alternativas).
- Cambios disruptivos.
- Cambios en el comportamiento.
- Características obsoletas.
Una vez que se genera un informe, se pueden revisar cada uno de los puntos anteriores para cada base de datos y trabajar en su resolución. Luego, DMA se puede utilizar para migrar cargas de trabajo a Azure (incluidos los usuarios de la base de datos, roles del servidor y accesos de inicio de sesión de SQL Server y Windows), ya sea a una VM de Azure SQL o a una única Base de Datos SQL. Las migraciones a Instancias Administradas de SQL no son admitidas actualmente en DMA.
Azure Migrate (Servicio de Migración de Bases de Datos DMS)
Destinos en Azure: Máquina Virtual SQL, Instancia Administrada de SQL, Base de Datos SQL
Azure Migrate es una herramienta de Azure que se utiliza para descubrir y evaluar su infraestructura existente, y luego migrar y modernizarla a Azure. También tiene la capacidad de realizar una «migración de prueba» sin afectar la configuración actual de migración.
El proceso comienza con el descubrimiento de servidores locales, seguido de una estrategia de migración recomendada y un análisis financiero basado en los servidores descubiertos. También se puede analizar las dependencias del servidor para que la migración sea más fluida, y finalmente, se procede a la evaluación de los servidores descubiertos.
Después, se pueden empezar a replicar los servidores descubiertos en Azure. Una vez que la replicación esté «completa», será posible realizar el corte de migración (junto con una migración de prueba). La replicación es continua, por lo que una vez que se ha replicado, los servidores seguirán replicándose, ahorrando tiempo al no tener que configurar la replicación nuevamente (sin embargo, tened en cuenta que hay 180 días gratuitos por máquina: una vez que el primer servidor ha comenzado a replicarse, se inicia una cuenta atrás, y una vez que transcurran los 180 días, tendreis que pagar por Azure Migrate).
Azure Migrate también facilita la gestión gracias a su interfaz gráfica, que permite ver los servidores descubiertos, lo que se ha migrado/replicado, lo que queda por hacer y el progreso de la migración.
Extensión de Migración de Azure SQL para Azure Data Studio (Servicio de Migración de Bases de Datos DMS)
Destinos en Azure: Máquina Virtual SQL, Instancia Administrada de SQL, Base de Datos SQL
La extensión de Migración de Azure SQL para Azure Data Studio es otra herramienta útil que abarca todo, desde la evaluación de los requisitos de la base de datos hasta la obtención de recomendaciones para el tamaño SKU adecuado y la migración a Azure. Calcula el SKU recomendado en función de los datos de rendimiento recopilados durante la evaluación inicial.
Las migraciones a Azure SQL VM y Azure SQL Instancia Administrada se pueden realizar en línea y fuera de línea; las migraciones en línea reducen al mínimo el tiempo de inactividad necesario para la migración, lo que las convierte en una excelente opción para bases de datos/aplicaciones críticas que no pueden permitirse estar fuera de línea. Esta opción copia efectivamente las copias de seguridad de la base de datos a un contenedor de almacenamiento de blobs, para luego restaurar los archivos en las bases de datos relevantes de Azure, similar al log shipping. El progreso de la migración también se puede monitorear desde el portal de Azure.
Las limitaciones de este método incluyen trabajos de Agente SQL, credenciales, paquetes SSIS y auditorías del servidor, que no se migran y deberán migrarse por separado.
Backup/Restore
Destinos en Azure: Máquina Virtual SQL, Instancia Administrada de SQL
Este es posiblemente el método más sencillo para migrar bases de datos a la nube, si se utilizan Azure SQL VM o Instancia Administrada de SQL (MI), ya que es similar al método que han utilizado los administradores de bases de datos durante años; sin embargo, requiere tiempo de inactividad.
En primer lugar, se hará un backup de todas las bases de datos que se deseen migrar, y luego se copiarán a la máquina virtual (si se utiliza SQL VM) o se cargarán en un contenedor de almacenamiento de Azure (si se utiliza MI).
La restauración de la base de datos, si se utiliza una VM, será como siempre ha sido. Sin embargo, para restaurar una base de datos en una MI, deberá restaurar desde una URL y proporcionar un «Shared Access Signature» (SAS) al especificar el contenedor de almacenamiento de Azure, para poder acceder al contenedor y restaurar el archivo de copia de seguridad.
En resumen…
Cada cliente será distinto y debeis realizar una análisis del entorno para decidir cuál será la mejor opción para efectuar la migración y a que servicio de Azure se hará.
Si has llegado hasta aquí, felicidades, te has vuelto completamente loco.