Planificación de una migración de datos

  • 7 minutos

Un proyecto de modernización de la plataforma de datos tiene cinco fases que suelen completarse en orden.

En nuestro escenario de distribuidor global, la junta directiva ha aprobado el proyecto de modernización, y debe empezar a organizar el personal y otros recursos. Para configurar y asignar tareas de manera óptima, debe comprender las fases del proyecto en profundidad.

En esta unidad, explorará cada una de las cinco fases con más detalle.

A diagram of the five stages of data modernization, discover, assess, plan, transform, and validate.

Inicio y detección

Normalmente, los proyectos de modernización de la plataforma de datos se inician para cumplir los requisitos empresariales o legales. Por lo tanto, es fundamental tener en cuenta estas necesidades y obtener apoyo de la alta gerencia. El primer paso consiste en completar un ejercicio de detección que incluye las consideraciones siguientes:

  • Evaluación del entorno actual

    Por lo general, muchas infraestructuras de TI evolucionan durante muchos años, quizás incluso décadas. En ese momento, la empresa y el personal pueden experimentar cambios enormes hasta el punto de que ya no sean expertos en los sistemas que tiene una organización. En raras ocasiones, las organizaciones pueden incluso olvidar que todavía tienen implementados ciertos sistemas.

  • Comprobación de las dependencias entre las aplicaciones y las bases de datos existentes

    Debe dedicar tiempo a entender cómo interactúan las aplicaciones con las bases de datos que existen en la red. Además, también debe comprender las dependencias entre bases de datos que puedan existir a fin de poder reunir colectivamente las bases de datos en agrupaciones lógicas. Al realizar este ejercicio, usará las agrupaciones lógicas de las bases de datos como base para migrarlas a Azure como una unidad.

  • Enumeración de los tipos de carga de trabajo de los sistemas

    Mostrar una lista de los tipos de carga de trabajo en los servidores de bases de datos identificados proporciona información sobre su uso. Las cargas de trabajo se pueden clasificar como analíticas (OLAP) o transaccionales (OLTP), en función de si son intensivas en lectura o escritura. Esto permite decidir a qué tecnología de plataforma de datos se va a migrar. La categorización adicional puede incluir cargas de trabajo de soporte técnico por lotes o decisiones.

Evaluación

Durante la fase de evaluación, la información recopilada durante la fase de detección se usa para realizar una evaluación completa de las cargas de trabajo identificadas a fin de establecer lo siguiente:

  • Todo bloqueador de migración potencial
  • Todo cambio importante que requiere correcciones posteriores a la migración
  • Características de Azure que las cargas de trabajo pueden utilizar

Para establecer esto, debe completar una evaluación de la carga de trabajo actual y una evaluación de los criterios de carga de trabajo.

  • Evaluación de la carga de trabajo actual

    Los servidores y aplicaciones de bases de datos identificados se clasifican y confirman para establecer lo siguiente: volumen de datos y tasas de crecimiento esperadas, uso medio de recursos y su importancia para la empresa. Esta fase también presenta la oportunidad de plantearse combinar o retirar bases de datos locales para reducir el número de bases de datos que se van a migrar y reducir el costo total de propiedad.

  • Evaluación de los criterios de carga de trabajo

    En la evaluación de los criterios de carga de trabajo, se usan los resultados de la evaluación de la carga de trabajo actual y se definen los criterios posteriores a la migración para ejecutar las cargas de trabajo identificadas.

    Supongamos que ha identificado un servidor de bases de datos transaccional muy usado durante las horas punta, pero con un uso bajo durante las horas de poca actividad. En la evaluación de los criterios de carga de trabajo, se definen criterios posteriores a la migración, como la migración a una base de datos de Azure SQL Database con escalado automático para controlar las cargas máximas.

Planificación

La fase de planificación de un proyecto de modernización de la plataforma de datos implica determinar la plataforma de destino, el enfoque de la migración y los planes de mitigación para cualquier interrupción, ya sea planificada o no planificada.

Dentro de la fase de planificación del proceso de modernización de la plataforma de datos, hay siete términos que describen cómo se puede controlar la transición de las aplicaciones y los datos desde un entorno local existente a un entorno nuevo basado en la nube (público o privado):

# Fase Acción Descripción
1. Permanencia No hacer nada Modernización continua mientras se contemplan opciones a largo plazo para los servicios que permanecen en el entorno local.
2. Rehospedaje Migración a IaaS Este enfoque elimina la necesidad de administración de centro de datos y aporta una mayor rentabilidad de la inversión (ROI) gracias a un menor costo total de propiedad (TCO).
3. Refactorizar Migración a IaaS o PaaS con cambios mínimos en las aplicaciones Este enfoque elimina la necesidad de administración de centro de datos y aporta una mayor rentabilidad de la inversión (ROI) gracias a un menor costo total de propiedad (TCO). También puede permitir una menor sobrecarga de administración gracias a la consolidación de las bases de datos.
4. Rediseño Reescritura de aspectos básicos de la aplicación para usar tecnologías en la nube Permite el uso de componentes modernos, reduce la implementación de código y facilita la implementación de DevOps de la infraestructura y servicios.
5. Recompilación Recompilación de la aplicación para usar PaaS o tecnologías sin servidor La recompilación de plataformas de datos y aplicaciones con tecnologías más recientes permite el uso de la alta disponibilidad integrada de Azure, aumenta la portabilidad y la escalabilidad de las aplicaciones, y minimiza las posibles carencias de aptitudes entre la tecnología usada y el personal que presta soporte o desarrolla la aplicación.
6. Sustituya Reemplazo de la aplicación por una solución de SaaS o una aplicación más reciente Tenga en cuenta el enfoque de reemplazo cuando una aplicación tenga dependencias en dispositivos físicos conectados al servidor o cuando se integre estrechamente con la infraestructura local.
7. Retirar Retirar las aplicaciones que ya no son necesarias Se debe tener en cuenta el enfoque de retirada cuando las aplicaciones y bases de datos heredadas ya no se usen porque no hay ningún requisito empresarial o legal de mantenerlas.

En el gráfico siguiente se muestra la cantidad de trabajo que requiere cada término en comparación con el valor que el negocio obtiene de la migración.

  • Opciones de destino de la plataforma

    Hay dos opciones de alto nivel disponibles cuando se trata de elegir la plataforma de destino.

    • Infraestructura como servicio (IaaS): en este enfoque, migrará los datos a una máquina virtual que tiene SQL Server instalado.

    • Plataforma como servicio (PaaS): en este enfoque, migrará los datos a un servicio de plataforma de datos que sea adecuado para su carga de trabajo. En el caso de las cargas de trabajo transaccionales, esto implicaría el uso de Azure SQL Database o Azure SQL Managed Instance. En el caso de las cargas de trabajo de tipo Procesamiento analítico en línea (OLAP), implicaría Azure Synapse Analytics.

  • Elección de la plataforma de destino por características

    • Azure SQL Database: se debe usar si el área expuesta de la aplicación está en el ámbito de la base de datos. SQL Database ofrece una solución de bajo mantenimiento que puede ser una excelente opción para determinadas cargas de trabajo.

    • Grupos elásticos de Azure SQL Database: los grupos elásticos permiten asignar recursos de almacenamiento y proceso a un grupo de bases de datos, en lugar de tener que administrar los recursos de cada base de datos individualmente. Además, los grupos elásticos son más fáciles de escalar que las bases de datos únicas, ya que no es necesario escalar bases de datos individuales debido a los cambios realizados en el grupo elástico.

    • Azure SQL Database sin servidor: es eficaz para reducir los costos en entornos de desarrollo y pruebas. La característica de retraso de pausa automática permite establecer el periodo inactivo antes de que la base de datos se pause automáticamente. Puede elegir entre 1 hora y 7 días, o bien deshabilitarla. Al volver a acceder a la base de datos, se reanuda y solo incurre en cargos de almacenamiento durante la pausa.

    • Azure SQL Managed Instance: sería adecuado usar este servicio si el área expuesta de la aplicación está en el ámbito de la instancia y requiere características que no están disponibles en Azure SQL Database, como las siguientes:

      • Agente SQL
      • MSDTC
      • DQS
      • MDS
      • Correo electrónico de base de datos
      • PolyBase
      • Compatibilidad con los servidores vinculados.
      • Admite servicios en la nube de Azure nuevos, como la detección de amenazas

    • SQL Server en la máquina virtual de Azure: se debe usar si el área expuesta de la aplicación está en el ámbito de la instancia y requiere características que no están disponibles en Azure SQL Managed Instance, como SQL Server Reporting Services (SSRS), SQL Server Analysis Services (SSAS) y SQL Server Integration Services (SSIS).

    • Azure Synapse Analytics: se debe usar si tiene aplicaciones que ejecutan consultas complejas en grandes cantidades de datos que pueden aprovechar el procesamiento paralelo masivo (MPP) para disminuir los tiempos de procesamiento de las consultas.

Para ver la lista de características admitidas en cada oferta de PaaS para SQL, vea Comparación de características: Azure SQL Database y Azure SQL Managed Instance.

  • Elección de la plataforma de destino por costo

    • Azure SQL Database: la naturaleza de plataforma como servicio de Azure SQL Database disminuye considerablemente los costos de administración con respecto a la topología de SQL Server en Azure IaaS más tradicional, ya que la mayor parte del trabajo necesario la completa Microsoft de manera silenciosa en segundo plano. A gran escala, se puede ahorrar bastante tiempo y esfuerzo.

    • Grupos elásticos de Azure SQL Database: los grupos elásticos de Azure SQL Database proporcionan un ahorro considerable para varias bases de datos que tengan demandas de uso impredecibles. Los recursos de proceso se comparten, lo que evita el exceso de aprovisionamiento y reduce los costos de mantenimiento y administración del servidor.

    • Azure SQL Managed Instance: este servicio se ofrece a los clientes que buscan un servicio totalmente administrado en el que pueden realizar de forma sencilla una migración mediante lift-and-shift de su entorno local con un mínimo de cambios en la configuración. El entorno ofrece un mínimo de 8 núcleos y hasta 8 TB de almacenamiento y se encuentra en una red virtual aislada. Esta oferta es ideal para los clientes que quieren acceder rápidamente a la nube y buscan evitar la sobrecarga de mantener las máquinas virtuales.

    • SQL Server en la máquina virtual de Azure: en comparación con las ofertas de PaaS, el servicio SQL Server ejecutado en máquinas virtuales de Azure incluye mayores costos de proceso, almacenamiento y administración, pero proporciona un mayor control sobre la instancia de SQL Server y la infraestructura.

    • Azure Synapse Analytics: Azure Synapse Analytics puede reducir el costo si utiliza la arquitectura de MPP para procesar consultas complejas en minutos en lugar de horas.

  • Diferencia entre migraciones sin conexión y migraciones en línea

    En la fase de planeamiento, debe considerar si quiere realizar una migración sin conexión o en línea. Si usa las migraciones sin conexión, el tiempo de inactividad de la aplicación comienza al mismo tiempo que la migración. Para limitar el tiempo de inactividad al tiempo necesario para la transición al nuevo entorno cuando finalice la migración, use una migración en línea. Es recomendable probar una migración sin conexión para determinar si el tiempo de inactividad es aceptable; si no fuera así, realice una migración en línea. Además, es posible que las opciones de migración en línea en comparación con las opciones sin conexión no estén disponibles en función de la plataforma de Azure seleccionada.

Transformación y optimización

Durante la evaluación y la planificación, debe haber identificado aspectos de las aplicaciones y la base de datos que requieran acciones posteriores a la migración que transformen u optimicen una característica. Así, se garantiza que la migración se completa correctamente. Por lo general, la transformación implica un trabajo que requiere corregir o cambiar un aspecto de una base de datos.

La optimización suele implicar una modificación en la base de datos migrada para aprovechar las ventajas de una característica u optimiza su uso en Azure.

Por ejemplo, una transformación podría implicar la modificación de un procedimiento almacenado o una consulta SQL que contiene sintaxis no admitida en la base de datos de destino. Esto requeriría ajustar la sintaxis para garantizar la compatibilidad con la plataforma de base de datos nueva, lo que garantiza que el procedimiento almacenado o la consulta se ejecute sin problemas en el entorno de destino.

  • Transformación

    Para garantizar una experiencia posterior a la migración correcta, es posible que deban realizarse uno o varios de los cambios siguientes en una base de datos.

    • Instale las actualizaciones de la versión antes de la migración.

    • Corrija los errores que identifican las herramientas de evaluación de la migración.

    • Implemente los cambios en el esquema de la base de datos.

    • Migre los servicios de bases de datos integrados existentes a Azure.

    • Controle las cargas de trabajo de SSIS en la nube.

  • Optimize (Optimizar)

    Puede que quiera seguir una o varias de las directrices de optimización siguientes durante la migración para asegurarse de que la organización esté aprovechando al máximo su inversión en Azure.

    • Evalúe las características nuevas que pueden estar disponibles en la plataforma de destino.

    • Vuelva a estructurar las cargas de trabajo en conjuntos más rentables o con mejor rendimiento.

    • Elija el nivel de servicio y de rendimiento más altos durante la migración y reduzca verticalmente cuando esta se haya completado.

    • Asegúrese de que el tamaño de las cargas de trabajo sea el correcto.

    • Minimice la distancia entre su archivo BACPAC y el centro de datos de destino.

    • Deshabilite las estadísticas automáticas durante la migración.

    • Índices y tablas de particiones

    • Quite las vistas indexadas y vuelva a crearlas cuando se haya completado el proceso.

Migración, validación y corrección

Esta fase implica la migración propiamente tal y, lo que es más importante, los pasos de validación y de corrección necesarios para confirmar una migración correcta. Las fases anteriores de planeamiento, evaluación y transformaciones garantizarán que todo está listo para realizar la migración y funcionar correctamente una vez que se haya trasladado a Azure. Lo único que queda por hacer es preparar las herramientas de migración necesarias, completar la migración, así como ejecutar las validaciones funcionales y de rendimiento posteriores a la migración para garantizar la coherencia de los datos con la base de datos de origen.

Consideraciones sobre la migración, validación y corrección

Hay una amplia gama de herramientas que se pueden usar para realizar la migración a la plataforma de destino seleccionada. Estas herramientas se analizarán en otros módulos. Mientras tanto, es importante tener en cuenta los aspectos siguientes al completar la migración:

  • Como punto de partida, comprenda los requisitos de carga de trabajo.
  • Para comenzar, seleccione las cargas de trabajo no críticas o las bases de datos de prioridad baja para la migración.
  • Ejecutar una migración de prueba
  • Pruebe la base de datos para saber si tiene algún problema.
  • Pruebe el plan para mitigar los riesgos asociados a los problemas de tiempo de inactividad y compatibilidad.
  • Evalúe las herramientas de migración en función de la interrupción para disminuir el riesgo de tiempo de inactividad de la base de datos.
  • Itere de manera continua en el proceso de migración.
  • Tenga en cuenta las ventanas de mantenimiento disponibles para la aplicación y la base de datos destinadas a la migración.
  • Deje sin conexión las bases de datos y aplicaciones antiguas.
  • Pruebe las aplicaciones de terceros.
  • Cree planes de recuperación ante desastres y mantenimiento nuevos.