Consideraciones sobre la migración

24 minutos

Un sistema empresarial que se ejecuta en el entorno local puede tener una arquitectura que esté acoplada a otros servicios que operen en el mismo entorno. Es importante comprender las relaciones entre un sistema que se quiere migrar y las demás aplicaciones y servicios que la organización está usando actualmente.

En la empresa start-up de tecnología, la base de datos de proveedores se usa para garantizar las existencias de los componentes y su llegada puntual para utilizarse en el proceso de fabricación. Los controladores de las existencias usan dispositivos móviles para actualizar esta base de datos a medida que llegan las entregas y los compradores usan un sitio web para supervisar los niveles de existencias e identificar el mejor momento para el pedido. Los administradores usan un conjunto de informes críticos para la empresa para supervisar el proceso y mejorar la eficacia. Asegúrese de que la migración a Azure no afecta negativamente a ninguno de estos usuarios.

Aquí aprenderá a planear y ejecutar una migración de base de datos fluida a la nube.

Investigación de las dependencias

En un sistema complejo, no es común que un componente funcione de manera totalmente independiente. En su lugar, hace llamadas a otros procesos y componentes. Por ejemplo, las bases de datos pueden depender de los servicios de directorio que hospedan las cuentas de usuario. Cuando se mueve una base de datos a la nube, ¿se puede acceder a ese servicio de directorio? Si no es así, ¿cómo iniciarán sesión los usuarios? Cuando se pasa por alto una dependencia como esta, puede haber un error total de la base de datos.

Para mitigar los riesgos, compruebe si la base de datos depende de servicios como los siguientes:

Servicios de directorio, como Active Directory.
Otros almacenes de entidades de seguridad.
Otras bases de datos.
API web u otros servicios de red.

Recuerde también que otros componentes pueden depender de la base de datos. Si mueve la base de datos sin volver a configurar los componentes dependientes, ¿qué consecuencias tiene? Por ejemplo, si mueve una base de datos del catálogo de productos, y el sitio web de acceso público depende de ella para decidir qué productos deben presentarse a los usuarios, ¿provocará esto una interrupción en el servicio?

Compruebe si alguno de estos tipos de componente depende de la base de datos:

Sitios web y API web.
Aplicaciones cliente, como aplicaciones móviles y software de escritorio.
Otras bases de datos.
Los informes
Almacenamientos de datos.

Para realizar estas comprobaciones, hable con las partes interesadas, los administradores y los desarrolladores involucrados en cada base de datos y componente del sistema. Consulte la documentación y, si no está seguro de comprender el comportamiento de los sistemas, considere la posibilidad de ejecutar pruebas, como capturas de red para observar el comportamiento.

Preparación para la reversión

En cualquier proyecto de migración, siempre debe estar preparado para un error. En un proyecto de migración de base de datos a la nube, lo peor que puede pasar es que la nueva base de datos deje de estar disponible y los usuarios no puedan hacer su trabajo. Es habitual que, para mitigar este riesgo —que puede tener un gran impacto en la rentabilidad de su empresa—, se planifique la reversión a la base de datos original sin modificar en el entorno local.

Para el plan de reversión, tenga en cuenta lo siguiente:

¿Cómo asegurarse de que puede revertir a una base de datos que no esté alterada por la migración con errores? Por ejemplo, se recomienda encarecidamente hacer una copia de seguridad completa de la base de datos, justo antes de comenzar la migración.
¿Cuánto tiempo se acepta que la base de datos esté sin conexión si se necesita revertirla?
¿Con cuánto presupuesto cuenta para el plan de reversión? Por ejemplo, ¿puede permitirse replicar la base de datos en un servidor de reversión dedicado? En ese caso, puede desactivar el servidor justo antes de la migración. Para revertir, inicie este servidor. Tendrá de inmediato una base de datos que no se ve afectada por la migración, sin tener que restaurarla a partir de la copia de seguridad.

Migración sin conexión o en línea

Para migrar una base de datos, tiene al menos dos opciones:

Nota:

La opción en línea no está disponible actualmente para las bases de datos MySQL en Data Migration Service.

Detenga el sistema, transfiera la base de datos y, a continuación, vuelva a configurar y reinicie el sistema para usar la nueva base de datos. Se trata de una migración sin conexión.
Mantenga el sistema en ejecución mientras mueve la base de datos a la nueva ubicación, ponga al día las transacciones que se realizan en la base de datos original en la nueva base de datos mientras se realiza la migración y, a continuación, cambie las aplicaciones para que se conecten a la nueva base de datos. Se trata de una migración en línea.

Es más fácil realizar una migración sin conexión, en la que los usuarios no pueden cambiar los datos mientras se realiza la migración. Sin embargo, si la base de datos está ocupada o es crítica para el éxito de la organización, puede que no sea posible.

Migraciones sin conexión

Supongamos que la base de datos admite un equipo de analistas que trabajan en una sola zona horaria durante el horario comercial normal. En general, el equipo no trabaja los fines de semana. Entre las 18:00 del viernes y las 9:00 del domingo, la base de datos no tiene un uso frecuente.

En esta situación, puede realizar una migración sin conexión durante el fin de semana, siguiendo estos pasos:

Desconecte la base de datos, después de que todas las transacciones se hayan completado el viernes por la noche.
Haga una copia de seguridad completa o exporte la base de datos.
Apague el servidor local y consérvelo en caso de que tenga que revertir.
Restaure la base de datos en el sistema en la nube de destino.
Conecte el sistema de destino.
Vuelva a configurar los clientes para que se conecten a la base de datos en la nube.

En este caso, la migración sin conexión es posible porque hay un período largo en el que una interrupción en el servicio afecta poco a los usuarios. Durante este tiempo, puede hacer una copia de seguridad y restauración completas de la base de datos, sabiendo que no perderá ningún cambio.

Migraciones en línea

Ahora piense en otra base de datos que funcione con una aplicación de ventas. El personal de ventas está distribuido por todo el mundo y también trabaja los fines de semana. No hay un período de baja actividad, la base de datos siempre está ocupada y, si desconecta la base de datos durante un período prolongado, afectará a los usuarios. La actividad de ventas es crítica para la empresa, por lo que una interrupción en el servicio tendrá un efecto directo en los beneficios de la organización.

En casos como este, considere la posibilidad de realizar una migración en línea. En una migración en línea, el tiempo de inactividad se limita al tiempo que se tarda en cambiar a la nueva base de datos. Use una herramienta como Azure Data Migration Service para ejecutar una migración en línea. Las migraciones en línea tienen las siguientes diferencias con las migraciones sin conexión:

La base de datos original no se desconecta antes de hacer una copia de seguridad o una exportación.
Mientras la migración está en curso, las modificaciones se aplican a la base de datos anterior.
La herramienta de migración garantiza que estas modificaciones se copien en la nueva base de datos antes del cambio. A menudo esto se logra reconfigurando la base de datos anterior para replicar las modificaciones en la nueva.

Migración de aplicaciones

Después de migrar una base de datos, ¿cómo y cuándo debe pasarse al nuevo sistema y actualizar las aplicaciones para usar la nueva base de datos? Puede hacer lo siguiente:

Mover las aplicaciones una a una a la nueva base de datos.
Mover los subconjuntos de usuarios.
Adoptar una combinación de ambos enfoques.

La intención es que realice la migración de la aplicación en pequeñas fases que se puedan revertir fácilmente si algo sale mal. Independientemente de si ha seguido un enfoque sin conexión o en línea para la migración de la base de datos, debe contar con una configuración funcional ubicada en el origen primero. En teoría, podrá volver a cambiar al origen primero rápidamente. Pero si los datos cambian constantemente, debe tener en cuenta dónde han tenido lugar estos cambios.

En una migración sin conexión, el origen y los destinos son independientes entre sí. Es posible que los usuarios y las aplicaciones ya no tengan una vista coherente de los datos. En un sistema transaccional, es probable que esta situación sea inaceptable. En este caso, tendría que mantener algún tipo de replicación bidireccional entre las bases de datos mientras ambos sistemas permanecen activos. Como alternativa, si la finalidad de una aplicación es generar informes mensuales o semanales, generar proyecciones de ventas o realizar otras operaciones estadísticas, esta falta de coherencia podría no ser tan preocupante. Dichas aplicaciones toman una "vista larga" de los datos, en lugar de depender de datos actualizados. En este último caso, las aplicaciones transaccionales usan la nueva base de datos, mientras que las aplicaciones de informes se mueven más lentamente.
En una migración en línea, la nueva base de datos se mantiene sincronizada con la anterior, normalmente mediante algún tipo de replicación. El proceso de replicación puede ser asincrónico, por lo que podría haber un retraso. Sin embargo, los cambios hechos en los datos de la nueva base de datos no se propagarán de nuevo a la anterior, lo que podría provocar conflictos. Una aplicación que se ejecuta en la base de datos anterior podría realizar un cambio conflictivo en los datos modificados en la nueva base de datos. La replicación sobrescribirá ciegamente el cambio en la nueva base de datos, lo que generará una "actualización perdida".

Enfoques para las pruebas

Si la base de datos desempeña un papel fundamental en su empresa, las consecuencias de un error podrían ser amplias. Para aumentar la confianza de que esto no suceda, considere la posibilidad de ejecutar pruebas de rendimiento en la base de datos migrada para asegurarse de que pueda encargarse de la carga que los usuarios puedan colocar en ella y responder rápidamente. Recuerde que puede haber períodos de picos de actividad, cuando la demanda es mucho mayor que la normal. Debe asegurarse de que el sistema migrado controle la carga de trabajo esperada.

Realice siempre algún tipo de prueba de regresión en la nueva base de datos antes de permitir el acceso a los usuarios. Estas pruebas comprobarán que el comportamiento y la funcionalidad del sistema sean correctos.

Además, debe considerar la posibilidad de ejecutar una "prueba de inmersión". Una prueba de inmersión es una prueba de carga diseñada para ver cómo funciona el sistema en su conjunto bajo presión. Una prueba de inmersión hace hincapié en la nueva base de datos y determina si es estable bajo una demanda alta. Una prueba de inmersión se ejecuta durante un período de tiempo considerable para ver lo que sucede cuando la demanda alta se mantiene.

Cuando haya determinado que el nuevo sistema es estable, puede empezar a migrar usuarios. Sin embargo, es posible que necesite garantías adicionales de que el nuevo sistema será aceptable para los usuarios. En este momento, puede considerar la "prueba controlada". Una prueba controlada remite de forma transparente a un pequeño subconjunto de usuarios al nuevo sistema, pero no saben que están accediendo a él. Se trata de una forma de prueba ciega, diseñada para que pueda encontrar problemas o incidencias en el nuevo sistema. Supervise las respuestas de estos usuarios y realice los ajustes necesarios.

Mantenimiento de sistemas paralelos

Hay varias razones por las que puede elegir ejecutar la anterior base de datos local en paralelo con la nueva base de datos en la nube:

Períodos de prueba. Como vimos en el tema anterior, es conveniente ejecutar pruebas controladas en la base de datos migrada para evaluar la funcionalidad, la estabilidad y la capacidad antes de usarla con personas. Mantener el sistema local en paralelo ofrece una manera rápida de revertir los usuarios al sistema anterior si hay problemas con el nuevo sistema.
Migraciones por fases. Una manera de mitigar el impacto de errores inesperados en producción consiste en trasladar un número pequeño de usuarios al nuevo sistema primero y supervisar los resultados. Si todo funciona sin problemas, puede trasladar otros grupos de usuarios a medida que confíe en la nueva base de datos. Puede trasladar los usuarios alfabéticamente, por departamento, por ubicación o por rol, hasta que estén todos en la nueva base de datos.
Migraciones por etapas. Otro enfoque consiste en segmentar la migración, no por usuario, sino por carga de trabajo. Por ejemplo, puede migrar las tablas de bases de datos que sirven a Recursos Humanos, antes de las que sirven a Ventas.

En todos estos casos, hay un período en el que la anterior base de datos local se ejecuta en paralelo con la nueva base de datos en la nube. Debe asegurarse de que los cambios hechos en la base de datos anterior también se apliquen a la nueva base de datos y que fluyan en la dirección opuesta. Puede crear un script para esta sincronización o usar una herramienta como Azure Data Migration Service.

Si decide mantener bases de datos paralelas y sincronizar los cambios, hágase estas preguntas:

Resolución de conflictos. ¿Es probable que se produzca un cambio en una fila local en el mismo momento que se produzca un cambio diferente en la misma fila en la nube? Esto crearía un conflicto, donde no queda claro qué cambio se debe conservar. ¿Cómo se resuelven estos conflictos?
Tráfico de red. ¿Cuánto tráfico de red se generará mientras se sincronicen los cambios entre las bases de datos? ¿Tiene suficiente capacidad de red para este tráfico?
Latencia. Cuando hay un cambio en una de las bases de datos, ¿qué retraso (si existe) resulta aceptable antes de que ese cambio llegue a la otra base de datos? Por ejemplo, en un catálogo de productos, es posible que pueda esperar hasta un día antes de que todos los usuarios puedan ver los nuevos productos. Sin embargo, si la base de datos incluye información crítica sobre las transacciones, como los tipos de cambio de moneda, los datos se deben sincronizar con mucha más frecuencia, si no se hace de forma instantánea.

Migraciones por etapas

Una migración por etapas es aquella donde un sistema completo se divide en cargas de trabajo y se migra una carga de trabajo a la vez.

Varias bases de datos

Un sistema complejo puede incluir varias bases de datos que admiten varias cargas de trabajo. Por ejemplo, Recursos Humanos podría usar la base de datos StaffDB, mientras que el equipo de Ventas podría tener aplicaciones móviles que consulten la base de datos ProductCatalogDB y la base de datos OrdersDB.

Por supuesto, puede optar por migrar todo el sistema de bases de datos a la nube de una sola vez. Esto puede ser más sencillo, ya que no tiene que ejecutar bases de datos tanto en el entorno local como en la nube. No es necesario tener en cuenta cómo se comunican esas bases de datos durante la migración. Sin embargo, los riesgos de error son mayores. Un problema único podría afectar al equipo de Recursos Humanos y al equipo de Ventas.

Considere la posibilidad de mitigar estos riesgos para los sistemas de bases de datos de tamaño medio y grande a través una migración por etapas, donde se mueve una carga de trabajo a la vez. En este ejemplo, puede considerar la posibilidad de migrar la base de datos StaffDB en primer lugar, ya que los problemas asociados a un error estarían limitados al equipo de Recursos Humanos y no impedirían aceptar pedidos. Al solucionar los problemas que surjan con la migración de StaffDB, aprenderá lecciones que podrá aplicar a las migraciones de otras cargas de trabajo.

A continuación, podría pensar en migrar la carga de trabajo Product Catalog a la nube. Si lo hace, tenga en cuenta las siguientes preguntas:

¿Cómo se puede garantizar que los productos que se han agregado recientemente al catálogo están disponibles para hacer pedidos?
¿Tiene que sincronizar los datos con la base de datos OrdersDB, que permanece en el entorno local?
¿Qué latencia es aceptable para que los nuevos productos lleguen a la base de datos OrdersDB desde el catálogo de productos?

Migraciones por etapas de una base de datos única

Incluso puede considerar una migración por etapas si solo tiene una base de datos única que admita todas las cargas de trabajo. Por ejemplo, podría dividir la base de datos en partes, de este modo:

Tablas para las operaciones de RR. HH.
Tablas para Ventas.
Tablas para análisis e informes.

Si migra las tablas de operaciones de RR. HH. en primer lugar, cualquier problema que surja solo afectará al personal de RR. HH. Ventas y los analistas de datos continúan trabajando en la base de datos anterior sin interrupciones.

Antes de realizar una migración por etapas, debe conocer totalmente las bases de datos y de qué manera las usan las aplicaciones. Por ejemplo, algunas tablas de la base de datos podrían usarse en ventas e informes. Esto significa que no puede dividir sin problemas las cargas de trabajo. Tiene que sincronizar estas tablas entre las bases de datos en el entorno local y en la nube, hasta que se hayan migrado todas las cargas de trabajo.

Problemas de seguridad

Las bases de datos pueden contener datos confidenciales, como detalles de productos, información personal de los empleados y detalles de pago, por lo que la seguridad siempre es una prioridad alta. Tiene que decidir cómo proteger estos datos durante la migración y en la nueva base de datos.

Protección por firewall

En una aplicación conectada a Internet, los servidores de bases de datos suelen protegerse con al menos dos firewalls. El primer firewall separa Internet de los servidores front-end, si estos servidores hospedan sitios web o API web, por ejemplo. Solo el puerto TCP 80 debe estar abierto en el firewall externo, pero este puerto debe estar abierto para todas las direcciones IP de origen, excepto las direcciones bloqueadas.

El segundo firewall separa los servidores front-end de los servidores de bases de datos. Se recomienda publicar el servicio de base de datos en un número de puerto privado que el mundo exterior no conozca. En el segundo firewall, abra este número de puerto solo para las direcciones IP de los servidores front-end. Esta disposición evita toda comunicación directa de un usuario de Internet malintencionado a los servidores de bases de datos.

Si planea migrar servidores de bases de datos a máquinas virtuales de Azure, use una red virtual con grupos de seguridad de red (NSG) para replicar las reglas de firewall. Si usa Azure Database for MySQL, Azure Database for MariaDB o Azure Database for PostgreSQL, puede crear reglas de firewall para proteger la base de datos mediante la página Seguridad de la conexión del servidor en Azure Portal.

Autenticación y autorización

En la mayoría de las bases de datos, es necesario controlar estrechamente quién accede a los datos y los modifica. Este control requiere que los usuarios se identifiquen positivamente cuando se conecten a la base de datos. Este proceso se denomina autenticación y normalmente se realiza con un nombre de usuario y una contraseña. Los sistemas de base de datos como MySQL, MariaDB y PostgreSQL proporcionan sus propios mecanismos de autenticación. Debe asegurarse de que sigue autenticando a los usuarios de forma segura al migrar los sistemas a la nube.

Nota:

Los servicios Azure Database for MySQL, Azure Database for MariaDB y Azure Database for PostgreSQL emulan la autenticación tradicional de MySQL, MariaDB y PostgreSQL.

Cuando sepa quién es el usuario, debe asignarle permisos para completar las tareas que forman parte de su trabajo. Este proceso se denomina autorización.

En el caso de un proyecto de migración de bases de datos, debe asegurarse de que los usuarios están autorizados correctamente en la base de datos en la nube:

Averigüe dónde se almacenan las cuentas de usuario en el sistema local. En MySQL, las cuentas de usuario suelen almacenarse en la tabla user de la base de datos mysql, pero es posible, por ejemplo, realizar la integración con cuentas de usuario almacenadas en Active Directory.
Obtenga una lista de todas las cuentas de usuario. En MySQL, por ejemplo, puede usar este comando:
```
SELECT host, user FROM mysql.user;
```
Para cada cuenta de usuario, averigüe qué acceso tiene a la base de datos. En MySQL, por ejemplo, puede usar este comando para la cuenta de usuario dbadmin@on-premises-host:
```
SHOW GRANTS FOR 'dbadmin'@'on-premises-host';
```
Vuelva a crear cada cuenta de usuario en la base de datos en la nube. En MySQL, por ejemplo, puede usar este comando para crear una cuenta:
```
CREATE USER 'dbadmin'@'cloud-host'
```
Autorice a cada cuenta de usuario en el nivel de acceso correcto de la base de datos en la nube. En MySQL, por ejemplo, puede usar este comando para permitir que un usuario acceda a la base de datos completa:
```
GRANT USAGE ON *.* TO 'dbadmin'@'cloud-host'
```

Cifrado

A medida que los datos se envían a través de la red, podrían ser interceptados por un ataque llamado "intermediario". Para evitar esto, Azure Database for MySQL, Azure Database for MariaDB y Azure Database for PostgreSQL admiten la Capa de sockets seguros (SSL) para cifrar las comunicaciones. SSL se aplica de forma predeterminada, y se recomienda encarecidamente que no cambie esta configuración.

Es posible que tenga que modificar la configuración de conexión de las aplicaciones cliente para usar el cifrado SSL. Comente este tema con los desarrolladores para decidir qué cambios son necesarios, si proceden.

Supervisión y administración

Parte del planeamiento de la migración de una base de datos consiste en considerar cómo los administradores de bases de datos seguirán realizando sus tareas después de la migración.

Supervisión

Los administradores de bases de datos locales están acostumbrados a supervisar periódicamente para detectar problemas, como cuellos de botella de hardware o contención de acceso a la red. Supervisan para asegurarse de poder corregir cualquier problema antes de que se vea afectada la productividad. Es de esperar que cualquier base de datos que no se supervise periódicamente empiece a causar problemas tarde o temprano.

Debe adoptar exactamente el mismo enfoque en las bases de datos en la nube. Podría ser más fácil solucionar problemas en un sistema PaaS como Azure, ya que puede agregar recursos sin necesidad de comprar, instalar ni configurar ningún hardware. Sin embargo, sigue siendo necesario detectar los problemas que acontezcan, por lo que la supervisión es una prioridad alta entre las tareas diarias.

Antes de migrar bases de datos a la nube, averigüe qué herramientas de supervisión usan actualmente los administradores. Si esas herramientas son compatibles con la solución propuesta basada en la nube, es posible que solo necesite volver a conectarlas a las bases de datos migradas. Si no es así, debe investigar las alternativas.

Tenga en cuenta que Azure incluye un conjunto de herramientas de supervisión de rendimiento y recopila una amplia variedad de contadores de rendimiento y datos de registro. Estos datos se muestran mediante paneles y gráficos en Azure Portal mediante la configuración de Azure Monitor. Cree gráficos, tablas e informes personalizados, especialmente diseñados para las necesidades de los administradores.

Administración

Los administradores de bases de datos usan sus herramientas preferidas para cambiar el esquema y el contenido de la base de datos en el entorno local. Si usan las mismas herramientas después de la migración, puede seguir sacando provecho de sus conocimientos. Para empezar, evalúe si el conjunto de herramientas existente es compatible con la base de datos propuesta hospedada en la nube. Muchas herramientas serán compatibles porque se basan en estándares ampliamente adoptados, como SQL, pero es importante comprobar la compatibilidad. Si las herramientas de administración actuales no funcionan después de la migración, intente descubrir alternativas con los administradores.

Azure incluye varias herramientas que puede usar para administrar bases de datos MySQL, MariaDB y PostgreSQL:

Azure Portal. Este sitio web tiene recursos eficaces que se usan para configurar, supervisar y administrar bases de datos, así como todos los demás recursos que pueda crear en la nube de Azure.
Azure PowerShell. Se trata de un entorno de ejecución de scripting y un lenguaje que tiene un amplio conjunto de comandos. Use PowerShell, que está disponible para entornos Windows y Linux, para automatizar tareas administrativas complejas de bases de datos.
Azure CLI. Se trata de una interfaz de la línea de comandos para Azure. Úsela para administrar servicios y recursos en Azure. Puede usar la CLI desde los entornos de shell de Windows y Linux, y desde los scripts de Bash.

Continuar