El post que se presenta, es la continuación de un artículo anterior en el que sentamos las bases conceptuales del proceso de migración (Proceso de migración de bases de datos OnPrem a PaaS de Azure (Parte I). En este post, definimos un caso de uso real en el que se proyecta migración de una base de datos funcional a una Azure Managed Instance.
¡Comenzamos!
Nos adentramos en el segundo artículo de la serie, puedes acceder al contenido del primer artículo en el siguiente link: Proceso de migración de bases de datos OnPrem a PaaS de Azure (Parte I).
En el primer post, se describen y analizan las fases incluidas en un proceso de migración de bases de datos de un entorno OnPrem (servidores físicos o virtuales), o entorno virtual en Azure, a servicios de PaaS de Azure.
Como veíamos en el artículo anterior, la organización de un proyecto de migración consta de tres fases: premigración, migración y postmigración.
Tareas que acometer en un proceso de migración
El objetivo principal de este post es aplicar los conceptos vistos anteriormente para aplicarlos en un caso de uso real.
Como veremos en el desarrollo del artículo, definiremos un caso de uso de migración en la que aplicaremos las fases y tareas definidos con el apoyo de las herramientas, que también revisamos en el artículo anterior.
Como se advierte en el post anterior, cada migración puede ser única y puede requerir pasos adicionales dependiendo de los requisitos específicos de las aplicaciones en la infraestructura a la que se migra.
En cuanto a la estructura del post, se acometerán los siguientes apartados:
- Definición del caso de uso que vamos utilizar para la migración
- Aplicación de los procesos de premigración: Descubrimiento y evaluación
- Aplicación de los procesos de migración: Elección del destino de la migración, preparación del proceso en las aplicaciones de apoyo y, por último, ejecutar y poner en producción la nueva plataforma
- Insistiremos en la fase de postmigración y la importancia de los dos procesos incluidos en esa fase: Integración y seguimiento
No entraremos en detalles de creación de recursos de Azure. En este caso, nos centramos en el proceso de migración partiendo del supuesto, que dichos recursos, están creados previamente.
Ánimo, vamos allá.
Descripción del caso de uso
Una vez identificados los procesos que se llevarán a cabo en la migración de bases de datos OnPrem a servicios PaaS de Azure, pasamos a ilustrarlo con un ejemplo real en el que nos adentraremos en los detalles de los procesos y el uso de aplicaciones de apoyo que tenemos para llevarla a cabo.
Para más detalles de los procesos de una migración del alcance que vamos acometer, merece la pena analizar el post anterior al que podemos acceder desde el link Proceso de migración de bases de datos OnPrem a PaaS de Azure (Parte I).
De modo general, supongamos que una organización tiene una aplicación de gestión de ventas en línea que utiliza una base de datos SQL Server OnPrem para almacenar información sobre clientes, productos, pedidos y transacciones. Dicha organización, está experimentando un crecimiento significativo de la carga transaccional de su aplicativo y busca mejorar la escalabilidad, la disponibilidad y la administración de su base de datos y, en base a estas necesidades, se opta por una solución cloud para ajustar las necesidades técnicas a las necesidades funcionales.
Adentrándonos en el detalle técnico del caso de uso que vamos a desarrollar en este post, tenemos una base de datos con actividad OLTP (tpcc) y hemos de migrarla a una managed instance de Azure con el mínimo corte de servicio posible.
Para simular actividad a la base de datos que vamos a migrar, utilizaremos HammerDB que aplicará carga transaccional sobre ‘tpcc’. El objetivo de aplicar dicha carga transaccional es simular la actividad de un aplicativo sobre la base de datos que nos permita acercar la demo a un escenario real. Si necesitas ver el detalle de la simulación con HammerDB, consulta este link: Pruebas de carga en bases de datos OLTP con HammerDB y SQL Server (I). Test de carga monousuario. – Antonio Llompart Freire.
En este caso real, aplicamos las fases que hemos identificado con las herramientas diseñadas para cubrir los requerimientos de este tipo de proyectos.
Nota: Para las acciones que se describen en los siguientes apartados, asegúrate de tener las últimas versiones de las herramientas diagnósticas de apoyo.
Procesos de migración
Discover
El objetivo de la fase de discover (o descubrimiento) es identificar y analizar la actividad de la instancia origen que nos permitirá estimar el tipo de recursos que utilizaremos en destino y su dimensionamiento. Para ello, se activarán trazas de eventos extendidos, que serán analizados en fases posteriores.
Para acometer esta fase se definirá un evento extendido que nos permitirá la captura de llamadas dinámicas en los procesos funcionales de la aplicación a la que da soporte la base de datos:
CREATE EVENT SESSION [MigrationTraces] ON SERVER
ADD EVENT sqlserver.sql_batch_completed(
ACTION (sqlserver.sql_text,sqlserver.client_app_name,sqlserver.client_hostname,sqlserver.database_id))
ADD TARGET package0.asynchronous_file_target(SET filename=N'<<Unidad:\Directorio\>>MigrationTraces.xel’)
WITH (MAX_MEMORY=2048 KB,EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,MAX_DISPATCH_LATENCY=3 SECONDS,MAX_EVENT_SIZE=0 KB,MEMORY_PARTITION_MODE=NONE,TRACK_CAUSALITY=OFF,STARTUP_STATE=OFF)
GO
—Start the session
ALTER EVENT SESSION [MigrationTraces] ON SERVER STATE = START;
Es necesario recoger en las trazas un ciclo funcional completo para asegurar que disponemos de toda la actividad que debe ejecutarse en la plataforma de destino.
Evaluación
La fase de evaluación es crítica ya que su objetivo principal es detectar los requerimientos necesarios para establecer una base sólida para una migración exitosa, minimizando los riesgos. La fase de evaluación tiene asociada dos tareas principales:
- Análisis de los niveles de compatibilidad de las bases de datos de origen
- Análisis de la viabilidad de migración de base de datos.
Estas tareas se acometerán haciendo uso de las trazas obtenidas en la fase de discover, que nos permitirá, con el apoyo de Data Migration Assistant y Azure Migration Assistant, analizar las cargas de trabajo y niveles de compatibilidad soportadas por la instancia origen.
Análisis de los niveles de compatibilidad de las bases de datos de origen
Como vimos en el primer artículo, el objetivo de esta fase es identificar el máximo nivel de compatibilidad que podemos asignar a la base de datos sin perder funcionalidades de origen.
Nota: Aunque para el ejemplo solo hemos capturado trazas durante dos horas, es conveniente que recoja un ciclo funcional completo, es decir, hemos de recoger todos los procesos funcionales que pudieran ejecutarse en el servidor, desde todas la aplicaciones que accedan a la base de datos que se analiza.
Una vez capturadas trazas lo suficientemente representativas para el entorno funcional, haremos uso de Data Migration Assistant para determinar la compatibilidad con otras versiones de SQL:
1.- Arrancamos DMA y generamos nuevo proyecto de migración
2.- Seleccionamos la opción de Assessment
No olvidemos que estamos en la fase de evaluación, por tanto, hemos de centrarnos en analizar todos los aspectos de la migración. En las siguientes fases, nos centramos en la migración. Con DMA vamos a comprobar qué versiones de SQL Server son compatibles con la base de datos que vamos a migrar.
Creamos nuevo proyecto DMA
Seleccionamos la versión de SQL hasta la que queremos analizar compatibilidad
Conectamos con la instancia origen
Seleccionamos la base de datos a analizar
Empezamos con el assessment
En el ejemplo que se desarrolla, DMA genera un informe con datos de compatibilidad para las versiones de SQL Server 2022, 2019 y 2017. En dicho informe se indica que es compatible con dichas versiones, aunque registra alguna advertencia que no impediría cambiar el modo de compatibilidad a dichas versiones. Con los resultados obtenidos, podemos continuar con las siguiente fases de la migración, con la certeza de que, una vez migrada, podemos subir el nivel de compatibilidad de la base de datos a la versión 16 (SQL Server 2022) sin pérdida de funcionalidad.
Informe del assesment de DMA
En este caso Data Migration Assistant, no detecta incompatibilidades para migrar a las versiones 2022, 2019 y 2017. No obstante, se incluye en el informe una advertencia por el uso de ‘unqualified joins’.
Análisis de la viabilidad de migración de base de datos
Para el análisis de viabilidad de migración a servicios PaaS de Azure, utilizamos Azure Migration Assisstant integrado en Azure Data Studio.
Para empezar entramos en Azure Data Studio, conectamos a la instancia en la que se ubican las bases de datos que vamos a migrar, y abrimos la opción ‘Manage’, tal y como se muestra en las siguientes ilustraciones.
En el ejemplo que se desarrolla, DMA genera un informe con datos de compatibilidad para las versiones de SQL Server 2022, 2019 y 2017. En dicho informe se indica que es compatible con dichas versiones, aunque registra alguna advertencia que no impediría cambiar el modo de compatibilidad a dichas versiones. Con los resultados obtenidos, podemos continuar con las siguiente fases de la migración, con la certeza de que, una vez migrada, podemos subir el nivel de compatibilidad de la base de datos a la versión 16 (SQL Server 2022) sin pérdida de funcionalidad.
Opción Manage para acceso a la opción Azure SQL Migration
Empieza el proceso
Seleccionamos base de datos y trazas de eventos extendidos
Empieza el proceso de assesment
En la primera parte del proceso, Azure Migration Assistant genera un primer informe parcial en la que se muestra qué servicios de Azure son compatibles para albergar la base de datos objeto de la migración. Como podemos ver en la siguiente ilustración, es viable la migración de la base de datos ‘tpcc’ en Azure SQL Managed Instance y SQL Server on Azure Virtual Machine, no obstante, en el ejemplo nos centraremos en la opción de Azure Managed Instance.
En el mismo informe podemos apreciar que tpcc no es compatible con Azure SQL Database.
Informe parcial de viabilidad de migración en distintos servicios de Azure
Una vez confirmada la viabilidad de migración de la base de datos ‘tpcc’ a una Azure Managed Instance, hemos de determinar el dimensionamiento de dicho servicio. Para ello, arrancamos la recolección de datos de la instancia origen que se apoyará en las trazas de eventos extendidos recogidos en fases anteriores.
Activación de proceso de assesment
Resultado de estimaciones en base a actividad
En el caso del ejemplo, la recomendación es una Managed Instance Gen5 de propósito general con cuatro vCores y 32 GB de disco. El informe de viabilidad va acompañado de un informe que justifica la opción recomendada.
Detalle de estimaciones de recursos destino de la migración
Proceso de migración
Elección de la plataforma destino
En esta fase, se muestran los resultados del assesment y la elección del tipo de recurso Azure destino de la migración que, en nuestro ejemplo, es una instancia manejada.
Centramos la migración con destino a Managed Instance
Destino de la migración
Llegados aquí, tenemos a dónde queremos ir, ahora toca ejecutar y qué modelo de migración queremos ejecutar (online, offline). En nuestro caso es una migración online con downtime ~ 0.
Azure SQL target
En este paso, indicamos a Azure Migration Assistant el recurso destino de la migración. En nuestro ejemplo es una managed instance.
Elección del recurso Azure Database Migration Service
Parametrizamos la integración con Azure Database Migration Service y la ubicación de los backups que serán restaurados en el proceso de migración. Recordemos que el proceso de migración con Azure Migration Assistant, se basa en la restauración de backups, en modalidad full backup (full, diferenciales y transaction log) de la base de datos origen en la base de datos destino, de forma análoga a lo que hace log shipping.
Backup en Blob Storage y restauración en destino
En primer lugar, configuramos el modelo de migración que vamos a ejecutar, tipo de ubicación de los backups con los que vamos a interactuar y el recurso Azure Database Migration Service.
Configuración de Azure Database Migration Service
Al haber escogido la opción de Blob Storage para el almacén de los backups, hemos de indicar el Storage Account que vamos a utilizar para ello.
Configuración del contenedor para backups
Restauración de backups en el recurso PaaS destino
Una vez configurado los parámetros, arranca el proceso de restauración de backups. Este proceso se mantendrá hasta el momento de la activación de la plataforma destino.
Puesta en producción de la nueva plataforma
Una vez que hemos asegurado la restauración del todos los backups disponibles (Ready for cutover), hemos de asegurar que no hay pérdida de transacciones en el proceso de puesta en producción. Para esto, hacemos backup del taillog y esperamos la restauración de éste en la base de datos destino.
Ejecutamos el backup del taillog en la base de datos origen. Para ello, podemos utilizar un script como el que se muestra a continuación
USE master
GO
ALTER DATABASE tpcc
SET SINGLE USER
–This rolls back all uncommitted transactions in the db.
WITH ROLLBACK INMEDIATE
GO
BACKUP LOG [tpcc] TO URL =
N’https://<<storage_account>>.blob.core.windows.net/backup2/tpcc_taillog_2024_03_08_143215.trn’ WITH
NO_TRUNCATE , NOFORMAT , NOINIT , NAME = N’tpcc-taillog Database Backup’ , NOSKIP, NOREWIND, NOUNLOAD, NORECOVERY, STATS = 10
GO
OJO. Al ejecutar el backup del taillog, la base de datos origen queda en estado restoring y, por tanto, ya no tenemos accesibilidad a la base de datos origen.
En este punto solo queda la restauración del taillog y el proceso de puesta en producción de la nueva plataforma.
Restauración del taillog en el recurso destino
Y, una vez restaurado el taillog, ejecutamos el proceso de cutover (traslado) para poner en producción la nueva arquitectura.
Tras la consolidación (cutover – traslado), tenemos habilitadas y accesibles, las bases de datos en el entorno destino. En nuestro caso es una Azure Managed Instance en la que tenemos la base de datos ‘tpcc’, es accesible a los aplicativos para su operación, de ahí la importancia de la siguiente fase, la postmigración.
Procesos postmigración
La fase de postmigración tiene como objetivo asegurar que la nueva plataforma es capaz de dar servicio a los aplicativos corporativos en, al menos, las mismas condiciones que teníamos en la arquitectura original. Para asegurar este objetivo, hemos de acometer dos tareas principales:
- Integración de la nueva plataforma con el ecosistema corporativo
- Seguimiento de la eficiencia y rendimiento de la nueva plataforma
Integración de la nueva plataforma con el ecosistema corporativo
Una vez ejecutada la migración queda asegurar la continuidad de las aplicaciones que hacen uso de los datos migrados. Para ello, se ha de identificar las dependencias de la base de datos con los elementos que forman parte del ecosistema de los aplicativos: aplicaciones, servicios y procesos que están integrados con SQL Server, servicios web, informes, integraciones con otras bases de datos, entre otros.
Seguimiento de la eficiencia y rendimiento de la nueva plataforma
Esta tarea es un proceso iterativo de vigilancia continua del entorno migrado. Para ello, se hace uso de herramientas de captura y análisis de trazas como Log Analytics (por fin estamos en Azure😉), Query Store, etc.
En la siguiente ilustración se bosqueja el seguimiento que se aproxima a un proceso iterativo de mejora continua basado en el esquema de calidad de Deming (digo basado no copiado 😊).
Este esquema basado en los principios la mejora continua, da un enfoque proactivo a los procesos funcionales de los aplicativos que se integran con la arquitectura recién migrada. Este modelo junto con la adaptabilidad de los recursos de Azure, permitirán adaptar la infraestructura a las necesidades de la organización.
Conclusión
En este post, hacemos uso de las herramientas y procesos presentados en el artículo anterior, con un caso de uso real de migración. A modo de resumen, este tipo de migraciones consta de tres fases fundamentales:
Como hemos visto en el desarrollo del post, empezamos con la fase de migración en la que se incluyen las tareas de descubrimiento haciendo uso de eventos extendidos para la recogida de trazas y evaluación, con el apoyo de DMA y Azure Migration Assistant.
A continuación, con el apoyo de Azure Migration Assistant y Azure Database Migration Services, ejecutamos el proceso de migración. Dicho proceso se basa en la restauración de backups, en modalidad full backup (full, diferenciales y transaction log) de la base de datos origen en la base de datos destino, de forma análoga a lo que hace log shipping.
En la demo que se ejecuta, optamos una migración OnLine, es decir, la restauración de las bases de datos se hace con la base de datos origen operativa, y solo tenemos una caída de servicio de base de datos en el momento de poner en producción la base de datos destino, tras la restauración del taillog de origen.
Por último, incidimos en la importancia de los procesos en la postmigración: Integración y seguimiento.
Antonio Llompart Freire
Data & Cloud Mentor
