Oleadas de migración, servidores y bases de datos - AWS Guía prescriptiva

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Oleadas de migración, servidores y bases de datos

Los proyectos de migración comienzan con la siguiente lista de preguntas abiertas, que son comunes en los tres escenarios descritos en la sección anterior:

  • ¿Cómo podemos crear oleadas de migración?

  • ¿Cómo podemos agrupar los servidores dentro de cada oleada?

  • ¿Deberían migrarse los servidores de bases de datos antes que los servidores de aplicaciones o junto con ellos?

  • ¿Qué herramienta debemos utilizar para las migraciones de bases de datos?

Sin embargo, para abordar estas preguntas, primero debemos aclarar algunas definiciones. Esta sección de la guía se centra en el término base de datos y en lo que significa en el contexto de las oleadas migratorias. Esta definición es importante porque la comprensión de ese término podría cambiar el enfoque general de migración para determinadas oleadas de migración o incluso cambiar las oleadas de migración al cambiar los servidores entre diferentes oleadas.

¿El término base de datos describe un servidor que ejecuta el software DBMS o el punto de entrada lógico de la base de datos? ¿Se refiere a una base de datos entre varias del mismo servidor o a un clúster de servidores? Según el contexto, una base de datos puede hacer referencia a cualquiera de las dos opciones. Los administradores de bases de datos (DBAs) suelen considerar bases de datos lógicas, no servidores físicos. Sin embargo, en el contexto de las migraciones, especialmente lift-and-shift las migraciones a gran escala, una base de datos suele corresponder a un servidor físico o a un clúster de servidores.

La migración de una base de datos debe estar alineada y asociada a la aplicación con la que trabaja, ya que la base de datos lógica siempre forma parte de la aplicación y de sus dependencias. Sin embargo, la ubicación física de esa base de datos lógica puede variar. Por ejemplo, podría estar ubicada en:

  • Un servidor físico independiente, sin ninguna otra base de datos presente.

  • Un servidor físico independiente ubicado junto con otras bases de datos lógicas.

  • Un clúster de servidores físicos, ya sea como una base de datos lógica única o como parte de un conjunto más amplio de bases de datos que sirven a otras aplicaciones.

Crear el mapeo de dependencias para las oleadas de migración resulta complicado si no existe una one-to-one dependencia clara entre los servidores de aplicaciones y de bases de datos, especialmente cuando varias bases de datos lógicas de diferentes aplicaciones están ubicadas en el mismo servidor físico. Estos sistemas de bases de datos requieren un enfoque de cambio de plataforma que implica la descomposición o consolidación de las bases de datos, lo que complica los esfuerzos de migración a gran escala. lift-and-shift 

Aquí es donde las herramientas de migración de bases de datos (como las herramientas nativas de los proveedores del motor de bases de datos o de terceros) pueden ayudar. Estas herramientas funcionan en un nivel de base de datos lógico en lugar del enfoque de replicación a nivel de bloques AWS Application Migration Service, y pueden mover los datos o las bases de datos en un nivel lógico entre servidores físicos y ubicaciones. Estas herramientas de migración de bases de datos nativas pueden ayudarle a consolidar las bases de datos lógicas en un único servidor físico. También pueden hacer lo contrario: pueden descomponer las bases de datos lógicas entre varios servidores de bases de datos físicos para alinearlas con diferentes aplicaciones y distribuirlas en diferentes oleadas de migración.