Consideraciones sobre la migración

24 minutos

Un sistema de negocios que se ejecuta en el entorno local puede tener una arquitectura que esté acoplada a otros servicios que funcionan en el mismo entorno. Es importante comprender las relaciones entre un sistema que desea migrar y las demás aplicaciones y servicios que usa su organización actualmente.

En su empresa de inicio de tecnología, la base de datos de proveedores se usa para garantizar que los componentes estén siempre en existencias y lleguen just-in-time para su uso en el proceso de fabricación. Los controladores de existencias usan dispositivos móviles para actualizar esta base de datos a medida que llegan envíos y los compradores usan un sitio web para supervisar los niveles de stock e identificar el mejor momento para pedir. Los administradores usan un conjunto de informes críticos para la empresa para supervisar el proceso y mejorar la eficacia. Quiere asegurarse de que ninguno de estos usuarios se ve afectado negativamente por la migración a Azure.

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

Investigación de dependencias

En un sistema complejo, un componente rara vez funciona completamente de forma independiente. En su lugar, realiza llamadas a otros procesos y componentes. Las bases de datos, por ejemplo, pueden depender de los servicios de directorio que hospedan cuentas de usuario. Al mover una base de datos a la nube, ¿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, ¿cuáles son las consecuencias? Por ejemplo, si mueve una base de datos de catálogo de productos y el sitio web orientado al público depende de él para determinar qué productos presentar a los usuarios, ¿el traslado provocará una interrupción en el servicio?

Compruebe si alguno de estos tipos de componentes 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 implicados en cada base de datos y componente del sistema. Consulte la documentación y, después, si no está seguro de que comprende el comportamiento de los sistemas, considere la posibilidad de ejecutar pruebas, como las capturas de red para observar el comportamiento.

Prepárate para retirarte

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, la peor eventualidad es que la nueva base de datos deja de estar disponible y los usuarios no pueden realizar sus trabajos. Es habitual mitigar este riesgo, lo que podría tener un gran impacto en la rentabilidad de su empresa, planeando revertir a la base de datos original y sin modificar en el entorno local.

Para el plan de contingencia, tenga en cuenta lo siguiente:

¿Cómo asegurarse de que puede revertir a una base de datos que no está afectada por la migración con errores? Por ejemplo, se recomienda encarecidamente realizar una copia de seguridad completa de la base de datos, justo antes de comenzar la migración.
¿Cuánto tiempo es aceptable que la base de datos esté sin conexión, si necesita recurrir a esta opción?
¿Cuánto presupuesto tiene para el plan de reserva? Por ejemplo, ¿puede permitirse replicar la base de datos en un servidor de respaldo dedicado? Si es así, puede desactivar este servidor justo antes de la migración. Para hacer retroceso, inicie este servidor. Inmediatamente tendría una base de datos que no se ve afectada por la migración, sin tener que restaurarla desde la copia de seguridad.

Migración sin conexión frente a migración 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 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 su nueva ubicación, reenvíe las transacciones que se realizan en la base de datos original a la nueva base de datos mientras continúa la migración y, a continuación, cambie las aplicaciones para conectarse a la nueva base de datos. Se trata de una migración en línea.

Es más sencillo realizar una migración sin conexión, donde los usuarios no pueden cambiar los datos mientras se realiza la migración. Sin embargo, si la base de datos está ocupada o es fundamental para el éxito de la organización, es posible 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 las horas laborables normales. Normalmente, el equipo no funciona durante los fines de semana. Entre las 6:00 p. m. del viernes y las 9:00 del domingo, la base de datos no suele usarse.

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

Desconectar la base de datos, después de que todas las transacciones se hayan completado el viernes por la noche.
Realice una copia de seguridad completa o exporte de la base de datos.
Apaga el servidor local y guárdalo por si necesitas volver atrás.
Restaure la base de datos en el sistema en la nube de destino.
Conecte el sistema de destino.
Vuelva a configurar los clientes para conectarse a la base de datos en la nube.

En este caso, es posible realizar una migración sin conexión porque hay un largo período cuando una interrupción en el servicio tiene poco efecto en los usuarios. Durante este tiempo, puede realizar 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 considere otra base de datos que admita una aplicación de ventas. El personal de ventas se distribuye en todo el mundo y también trabaja durante los fines de semana. No hay un período de actividad baja, la base de datos siempre está ocupada y, si la base de datos está sin conexión durante un período significativo, 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 la línea inferior 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 necesario para 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:

No mueva la base de datos original sin conexión antes de realizar una copia de seguridad o exportación.
Mientras la migración está en curso, los cambios se aplican a la base de datos antigua.
La herramienta de migración garantiza que estos cambios se copien en la nueva base de datos antes de la conmutación. Esto se logra a menudo mediante la reconfiguración de la base de datos antigua para replicar los cambios en el nuevo.

Migración de aplicaciones

Después de migrar una base de datos, ¿cómo (y cuándo) debe pasar al nuevo sistema y actualizar las aplicaciones para usar la nueva base de datos? Es posible que:

Mueva las aplicaciones de uno a uno a la nueva base de datos.
Mover subconjuntos de usuarios.
Adopte una combinación de ambos enfoques.

La intención es que realices la migración de aplicaciones 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 bases de datos, debe tener una configuración de trabajo ubicada en el origen original. En teoría, podrá volver rápidamente al origen original. Pero si los datos cambian constantemente, debe tener en cuenta dónde se han realizado 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 vean 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 alguna forma de replicación bidireccional entre bases de datos mientras ambos sistemas permanecen activos. Como alternativa, si el propósito de una aplicación es generar informes mensuales o semanales, generar proyecciones de ventas o realizar otras operaciones estadísticas, es posible que esta falta de coherencia no sea 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 antigua, normalmente mediante alguna forma de replicación. El proceso de replicación puede ser asincrónico, por lo que podría haber un retraso. Sin embargo, los cambios realizados en los datos de la nueva base de datos no se propagarán de nuevo a la antigua, lo que da lugar a posibles 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 provocará una "actualización perdida".

Enfoques para las pruebas

Si la base de datos desempeña un papel fundamental en su negocio, las consecuencias de un error pueden ser extensas. Para aumentar la confianza de que esto no ocurrirá, considere la posibilidad de ejecutar pruebas de rendimiento en la base de datos migrada para asegurarse de que se adapte a la carga que los usuarios puedan colocar en él y responder rápidamente. Recuerde que podría haber períodos de actividad máxima, cuando la demanda es mucho mayor que la normal. Debe asegurarse de que el sistema migrado controla 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 son correctos.

Además, debe considerar la posibilidad de ejecutar una "prueba de remojo". Una prueba de remojo es una prueba de carga diseñada para ver cómo funciona el sistema como un todo bajo presión. Una prueba de esfuerzo prolongado pone a prueba la nueva base de datos y determina si es estable bajo condiciones de alta demanda. Una prueba de remojo se ejecuta durante un período de tiempo significativo para ver lo que sucede cuando la alta demanda persiste.

Cuando haya establecido que el nuevo sistema es estable, puede empezar a migrar usuarios. Sin embargo, es posible que necesite garantía adicional de que los usuarios encontrarán el nuevo sistema aceptable. 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 cualquier problema o inconveniente con 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 optar por ejecutar la base de datos local antigua 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 le ofrece una manera rápida de revertir los usuarios al sistema antiguo si hay problemas con el nuevo sistema.
Migraciones por fases. Una manera de mitigar el impacto de los errores inesperados en producción es mover primero un pequeño número de usuarios al nuevo sistema y supervisar los resultados. Si todas las ejecuciones se ejecutan sin problemas, podría mover otros grupos de usuarios a medida que obtiene confianza en la nueva base de datos. Puede mover 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 el usuario, sino por la 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 base de datos local antigua se ejecuta en paralelo con la nueva base de datos en la nube. Debe asegurarse de que los cambios realizados en la base de datos anterior también se aplican a la nueva base de datos y que fluyen en la dirección opuesta. Puede crear scripts de esta sincronización o usar una herramienta como Azure Data Migration Service.

Si decide mantener bases de datos paralelas y sincronizar los cambios, haga estas preguntas:

Resolución de conflictos. ¿Es probable que se produzca un cambio en una fila local en un momento similar a otro cambio en la misma fila de la nube? Esto crearía un conflicto, donde no está claro qué cambio se debe conservar. ¿Cómo resolvería estos conflictos?
Tráfico de red. ¿Cuánto tráfico de red se generará mientras se sincronizan los cambios entre bases de datos? ¿Tiene suficiente capacidad de red para este tráfico?
Latencia. Cuando se produce un cambio en una de las bases de datos, ¿qué retraso (si existe) es 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 los nuevos productos sean visibles para todos los usuarios. Sin embargo, si la base de datos incluye información transaccional crítica, como los tipos de cambio de moneda, esos datos deben sincronizarse con mucha más frecuencia, si no de forma instantánea.

Migración por etapas

Una migración por etapas es donde se divide un sistema completo 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, los recursos humanos podrían usar la base de datos StaffDB , mientras que el equipo de ventas podría tener aplicaciones móviles que consultan la base de datos ProductCatalogDB y la base de datos OrdersDB .

Por supuesto, puede optar por migrar todo el sistema de base de datos a la nube en un solo uso. Esto puede ser más sencillo, ya que no tiene que ejecutar bases de datos tanto locales 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 único problema puede afectar tanto al equipo de recursos humanos como al equipo de ventas.

Considere la posibilidad de mitigar estos riesgos para sistemas de bases de datos medianas y grandes mediante la realización de una migración por etapas, donde se mueve una carga de trabajo a la vez. En este ejemplo, podría considerar la posibilidad de migrar primero la base de datos StaffDB , ya que los problemas asociados a un error se limitarían al equipo de recursos humanos y no le impedirían tomar órdenes. Al resolver los problemas que surjan con la migración de StaffDB , aprenderá las lecciones que se aplican a otras migraciones de cargas de trabajo.

A continuación, podría pensar en migrar la carga de trabajo catálogo de productos a la nube. Si lo hace, tenga en cuenta preguntas como:

¿Cómo se asegura de que los productos recién agregados al catálogo estén disponibles para el pedido?
¿Necesita sincronizar 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 base de datos únicas

Aunque solo tenga una base de datos única que admita todas las cargas de trabajo, todavía puede considerar una migración por etapas. Por ejemplo, podría dividir la base de datos en partes como esta:

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

Si migra primero las tablas de operaciones de RR. HH., cualquier problema que surja solo afecta al personal de RR. HH. Los analistas de ventas y datos siguen trabajando en la base de datos antigua sin interrupciones.

Antes de realizar una migración por etapas, debe comprender completamente las bases de datos y cómo las usan las aplicaciones. Por ejemplo, algunas tablas en tu base de datos pueden admitir tanto ventas como informes. Esto significa que no se pueden dividir las cargas de trabajo de forma limpia. Debe sincronizar estas tablas entre bases de datos locales 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 del producto, información personal del personal y detalles de pago, por lo que la seguridad siempre es una prioridad alta. Debe decidir cómo proteger estos datos durante la migración y en la nueva base de datos.

Protección del firewall

En una aplicación conectada a Internet, los servidores de bases de datos normalmente están protegidos por 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 base de datos. Se recomienda publicar el servicio de base de datos en un número de puerto privado que no se conoce en el mundo exterior. En el segundo firewall, abra este número de puerto solo para las direcciones IP de los servidores front-end. Esta disposición impide cualquier comunicación directa de un usuario malintencionado de Internet 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 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 conexión del servidor en Azure Portal.

Autenticación y autorización

En la mayoría de las bases de datos, debe controlar estrechamente quién accede a los datos y modifica los datos. Este control requiere que los usuarios se identifiquen positivamente cuando se conectan 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 de 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 asignarles permisos para completar las tareas que forman parte de su trabajo. Este proceso se denomina autorización.

Para un proyecto de migración de base 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 normalmente se almacenan en la user tabla de la mysql base de datos, pero es posible, por ejemplo, integrarlas con cuentas de usuario almacenadas en Active Directory.
Obtenga una lista de todas las cuentas de usuario. En MySQL, por ejemplo, podría 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, podría usar este comando para la cuenta de dbadmin@on-premises-host usuario:
```
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, podría usar este comando para crear una nueva cuenta:
```
CREATE USER 'dbadmin'@'cloud-host'
```
Autorice cada cuenta de usuario al nivel de acceso correcto en la base de datos en la nube. En MySQL, por ejemplo, podría usar este comando para permitir que un usuario acceda a la base de datos completa:
```
GRANT USAGE ON *.* TO 'dbadmin'@'cloud-host'
```

Encriptación

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, Tanto Azure Database for MySQL como Azure Database for MariaDB y Azure Database for PostgreSQL admiten capa de sockets seguros (SSL) para cifrar las comunicaciones. SSL se aplica de forma predeterminada y se recomienda encarecidamente no cambiar esta configuración.

Es posible que tenga que modificar la configuración de conexión de las aplicaciones cliente para usar el cifrado SSL. Analice este tema con los desarrolladores para determinar los cambios, si los hay, que son necesarios.

Supervisión y administración

Parte de la planeación de migrar una base de datos es tener en cuenta cómo los administradores de bases de datos seguirán realizando sus tareas después de la migración.

Monitorización

Los administradores de bases de datos locales están acostumbrados a supervisar regularmente para detectar problemas como limitaciones de hardware o contención en el acceso a la red. Supervisan para asegurarse de que pueden solucionar cualquier problema antes de que se vea afectado la productividad. Puede esperar que cualquier base de datos que no esté supervisada periódicamente empiece a causar problemas antes o más tarde.

Debe adoptar exactamente el mismo enfoque para las bases de datos en la nube. Puede ser más fácil resolver problemas en un sistema PaaS como Azure, ya que puede agregar recursos sin comprar, configurar y configurar ningún hardware. Sin embargo, todavía necesita detectar problemas de desarrollo, 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 los administradores actualmente. Si esas herramientas son compatibles con la solución propuesta basada en la nube, es posible que solo tenga que volver a conectarlas a las bases de datos migradas. Si no es así, debe investigar 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. Puede mostrar estos datos mediante paneles y gráficos en Azure Portal mediante la configuración de Azure Monitor. Puede crear gráficos, tablas e informes personalizados, específicamente diseñados para las necesidades de los administradores.

Administración

Los administradores de bases de datos usan herramientas preferidas para cambiar el esquema y el contenido de la base de datos local. Si usan las mismas herramientas después de la migración, puede seguir beneficiándose de su experiencia. Empiece por evaluar 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 esa compatibilidad. Si las herramientas de administración actuales no funcionarán después de la migración, intente identificar 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 instalaciones eficaces que se usan para configurar, supervisar y administrar bases de datos, y todos los demás recursos que puede 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 de Windows y Linux, para automatizar tareas administrativas complejas de bases de datos.
CLI de Azure. Se trata de una interfaz de línea de comandos para Azure. Úselo para administrar servicios y recursos en Azure. Puede usar la CLI desde los entornos de shell de Windows y Linux y desde scripts de Bash.