Seleccionar página
16 de abril de 2024

Proceso de migración de bases de datos OnPrem a PaaS de Azure (Parte II)

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.

fases-migracion-exitosa-azure

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á.

Migra y moderniza tus aplicaciones a la nube con Azure

Mejora la eficiencia de tu plataforma, con seguridad y cumpliendo las normativas vigentes, mientras despliegas proyectos innovadores para acelerar tu negocio y mantenerte competitivo.

Apostar por Microsoft Azure es apostar por una infraestructura sostenible con un impacto local. Usar la plataforma en la nube de Microsoft puede ofrecerte hasta un 93 % más de eficiencia energética y hasta un 98 % más de eficiencia en materia de carbono en comparación con las soluciones locales.

Contacta con nosotros para explorar cómo podemos hacer que la inteligencia artificial trabaje para tu empresa.

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.

caso-real-fases-herramientas

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

data-migration-assistant

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.

nuevo-proyecto-dma

Creamos nuevo proyecto DMA

version-sql-analizar-compatibilidad

Seleccionamos la versión de SQL hasta la que queremos analizar compatibilidad

instancia-origen-dma

Conectamos con la instancia origen

base-datos-dma

Seleccionamos la base de datos a analizar

assesment-inicio-dma

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-assesment-dma

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.

manage-azure-data-studio
manage-azure-sql-migration

Opción Manage para acceso a la opción Azure SQL Migration

inicio-migracion-base-datos

Empieza el proceso

seleccion-base-datos-trazas-eventos-extendidos

Seleccionamos base de datos y trazas de eventos extendidos

empieza-proceso-assesment

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-viabilidad-migración-servicios-azure

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.

activacion-proceso-assesment

Activación de proceso de assesment

resultado-estimaciones-base-actividad

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-estimaciones-recursos-destino-migracion

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-migración-destino-managed-instance

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.

 

azure-sql-target

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-Blob-Storage-restauración-destino

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.

configuracion-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.

configuracion-azure-database-migration-service

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.

restauracion-restauracion-backups-recurso-paas-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.

estado-ready-for-cutover-no-existen-mas-backups-restaurar

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’ , NOSKIPNOREWIND, 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.

tpcc-restoring

En este punto solo queda la restauración del taillog y el proceso de puesta en producción de la nueva plataforma.

restauracion-taillog-recurso-destino

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.

proceso-cutover-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.

azure-managed-instance-base-datos-tpcc-postmigracion

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.

integracion-sistemas-informacion
Z

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.

integracion-sistemas-informacion-mejora-continua

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:

fases-migracion-exitosa-azure

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.

Conviértete en un experto en SQL con Verne Academy

¿Necesitas mejorar el rendimiento de tu base de datos? ¿Has ido aprendiendo sin una metodología clara, picoteando de distintas fuentes para resolver necesidades puntuales, pero no cuentas con una visión general y completa? ¡Deja tus tareas más rutinarias en manos de la tecnología y focalizar tu tiempo en lo importante! Con nuestros cursos de SQL podrás refrescar todos tus conocimientos y aprender con casos prácticos diferentes conceptos y buenas prácticas que te ayudarán a conseguir bases de datos más estables y a optimizar su rendimiento.
alvaro-mollor-quesada

Antonio Llompart Freire

Data & Cloud Mentor