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.
Migración con AWS Application Migration Service
La mayoría de las migraciones más grandes se pueden levantar y cambiar. AWS AWS Transform MGN
Este método de replicación a nivel de bloque no admite el almacenamiento conectado a la red (NAS), las unidades compartidas, como los recursos compartidos del Sistema de archivos de red (NFS) o los recursos compartidos del Sistema de archivos de Internet común (CIFS) o el bloque de mensajes del servidor (SMB). Solo admite el almacenamiento a nivel de bloque que esté conectado directamente al sistema migrado en el momento de la migración. (Para obtener más información, consulte las preguntas frecuentes de MGN sobre SAN/NAS soporte). Esto limita la aplicabilidad de la replicación mediante MGN en la mayoría de los sistemas agrupados, ya que la mayoría de los clústeres dependen del almacenamiento compartido de varias implementaciones. Para obtener más información, consulte las secciones de ventajas y desventajas de esta página.
El método de replicación a nivel de bloques requiere la instalación de un agente de AWS replicación en el nivel del sistema operativo (SO), y ese agente solo admite plataformas x86 basadas en el sistema operativo Windows o Linux (consulte Sistemas operativos compatibles con MGN). Non-x86 las plataformas están fuera del alcance de este método de migración. Entre ellas se incluyen ARM, RISC/CISC los sistemas, las variantes de PowerPC, los sistemas IBM, como pSeries, iSeries y zSeries, y sus respectivos sistemas operativos, como AIX, Solaris, Linux para PowerPC HP-UX, zLinux para mainframes y otras arquitecturas que no son x86.
El agente de AWS replicación funciona a nivel de un controlador de dispositivo de un sistema de archivos virtual* en la pila del sistema operativo y captura cualquier bloque de datos para escribirlo en los dispositivos a nivel de bloque subyacentes (incluidas las unidades, los discos duros y los dispositivos SAN conectados directamente), como se explica en la página de preguntas frecuentes de MGN bajo estas preguntas:
* Consulte las definiciones de sistema de archivos, sistema
Ventajas
Para las migraciones de cualquier escala en las que se necesite levantar y cambiar de lugar, MGN ofrece muchas ventajas:
-
La replicación es fácil de configurar (no requiere una curva de aprendizaje pronunciada).
-
Se amplía rápidamente, ya que despliega agentes en las máquinas de origen.
-
Puede utilizar la Fábrica de migración a la nube
para automatizar la mayoría de las tareas manuales, administrar varias máquinas y organizar oleadas de migración. -
Es compatible con una amplia gama de arquitecturas de sistemas operativos x86.
-
Es compatible con cualquier tipo de entorno de origen (centro de datos local, cualquier otra nube u otra Región de AWS).
-
Es independiente de las aplicaciones, por lo que es compatible con cualquier aplicación que se ejecute en los servidores de origen.
-
No se requiere ninguna licencia ni compra. AWS ofrece precios de pago por uso, por lo que solo paga por el servicio mientras lo utilice, sin contratos a largo plazo ni licencias complejas. MGN ofrece un período gratuito de 90 días por servidor, que es suficiente para la mayoría de las migraciones. Para obtener más información, consulte los AWS Transform MGN precios
en el sitio web. AWS
Desventajas
Al utilizar herramientas de replicación a nivel de bloque, como MGN, es posible que se produzcan los siguientes casos extremos y factores a tener en cuenta:
-
MGN no admite sistemas de archivos compartidos montados ni dispositivos de almacenamiento compartido, como los NAS, incluidos CIFS/SMB los sistemas de archivos NFS. Para obtener más información sobre los métodos de replicación para NAS o sistemas de archivos compartidos, consulte el agente de replicación MGN para migrar NFS Share
(artículo de AWS Re:post) y Migrar sistemas de archivos compartidos en una migración AWS grande (patrón de orientación prescriptiva).AWS -
MGN no admite la mayoría de las configuraciones de clústeres de servidores de archivos o bases de datos agrupados con almacenamiento compartido debido a las limitaciones en la forma en que ese almacenamiento compartido se representa a nivel del sistema operativo a través de las capas de controladores de dispositivo. Por ejemplo, no se admiten los clústeres de Microsoft SQL Server con la opción Storage Space Direct (S2D). Sin embargo, aún puede usar MGN para replicar otros tipos de sistemas agrupados con almacenamiento en bloques compartido, como el almacenamiento compartido en configuraciones de instancia de clúster de conmutación por error (FCI) en el clúster de conmutación por error de Windows Server (WSFC), como se describe en la entrada del blog Migración de clústeres de Microsoft Windows para AWS usar CloudEndure Migration, almacenamiento expuesto desde matrices SAN externas (conexiones iSCSI) y algunos clústeres
de grupos de disponibilidad Always On (AAG) de Microsoft SQL Server Always On en maletines de esquina específicos. En general, MGN admite la replicación de un dispositivo a nivel de bloque desde un servidor donde el dispositivo de almacenamiento está completamente presente en el servidor durante la migración. (El agente de AWS replicación debe estar instalado en el servidor y el agente debe estar visible para la replicación). Sin embargo, todos estos escenarios requieren procedimientos muy específicos y dan como resultado períodos de transición más largos. -
Los sistemas que tienen una alta tasa de cambios de datos (como las bases de datos OLTP) pueden tener requisitos de red o rendimiento más altos, lo cual complica los esfuerzos de migración.
-
El ancho de banda de la red debe ser suficiente para que la cantidad de datos se transfieran dentro del periodo de migración y transición planificado. Esto se debe a que MGN no ofrece una opción de envío fuera de línea, a diferencia de. AWS Snowball
-
La migración requiere un pequeño período de inactividad, con un RTO de minutos. MGN utiliza las instantáneas de EBS como parte del proceso de migración, y los nuevos discos de EBS que se crean a partir de dichas instantáneas tienen inicialmente un rendimiento inferior. Con algunos patrones de lectura de bases de datos, esto podría aumentar el periodo de transición efectivo hasta que la base de datos migrada alcance su máximo rendimiento.
Best-fit escenarios
MGN cubre casi todas las migraciones de elevación y cambio de marchas en su totalidad, con pocas desventajas, tal y como se ha explicado en las dos secciones anteriores. Esta herramienta puede ocuparse de la mayoría de los casos extremos, como los clústeres de bases de datos, siempre que el periodo de transición más largo necesario para estos sistemas satisfaga los requisitos de migración.
En las siguientes secciones se describen dos escenarios con mayor profundidad:
-
Large-scale migración con múltiples oleadas de migración
-
Migración de una sola aplicación que requiere un tiempo de inactividad mínimo
Large-scale migración con múltiples oleadas de migración
Un ejemplo de migración a gran escala es la salida de un centro de datos que se caracteriza por sus requisitos de tamaño y velocidad. Por lo general, también implica una restricción de tiempo específica, como la finalización del contrato de arrendamiento del centro de datos. En este caso, la escala determina el enfoque. Las oleadas de migración se determinan y agrupan por aplicaciones, incluidas las bases de datos, y cada oleada tiene una fase planificada de preparación, migración y transición final con requisitos de tiempo de inactividad específicos.
Dentro de cada oleada de migración, es mejor trasladar los servidores de bases de datos a escala mediante la replicación a nivel de bloques de MGN, salvo contadas excepciones en los siguientes casos especiales, que pueden requerir un enfoque de migración independiente:
-
Mayoría de sistemas de bases de datos agrupados en clústeres
-
Sistemas de bases de datos en los que la tasa de cambio supera el rendimiento de red disponible (lo cual puede provocar un retraso en la replicación)
Para cada caso especial, considere la compensación entre sus requisitos de tiempo de inactividad y el nivel de esfuerzo que implica el uso de otra herramienta de migración. En algunos casos, es mucho más fácil utilizar el mismo enfoque de migración para todos los sistemas en lugar de utilizar herramientas independientes y crear procesos diferentes para sistemas específicos. Si MGN no admite los requisitos de tiempo de inactividad de un sistema específico, le recomendamos que utilice uno de los métodos descritos en la sección Migración con herramientas de bases de datos nativas.
Migración de aplicaciones individuales
El escenario de una sola aplicación representa un enfoque detallado para migrar una sola aplicación fundamental para la empresa que requiera un tiempo de inactividad mínimo o casi nulo durante la migración o algunas de esas aplicaciones. El alcance de la migración puede variar en función de la criticidad empresarial y los requisitos de tiempo de inactividad, a diferencia de los requisitos de velocidad y escalabilidad del escenario anterior (migración a gran escala). Si la aplicación permite un tiempo de inactividad dentro del RTO de MGN, debe gestionarse de la misma manera que cualquier migración a gran escala descrita anteriormente.
Sin embargo, en los casos en los que el tiempo de transición debe ser lo más cercano posible al mínimo (por ejemplo, cuando la base de datos migrada tiene patrones de lectura que requieren mucho tiempo para funcionar a pleno rendimiento y los períodos de transición deben ser pequeños), se debe considerar un enfoque más detallado y granular. En general, ese enfoque implica pasos y requisitos adicionales, que requieren más esfuerzo y tiempo. Uno de los pasos consiste en separar la migración de la base de datos de la migración del servidor de aplicaciones y utilizar las herramientas de migración de bases de datos descritas en la siguiente sección para mantener sincronizadas las bases de datos de origen y destino. Para lograr la sincronización puede utilizar varios métodos. Cada método tiene ventajas y desventajas, e implica diferentes compensaciones entre la cantidad de tiempo de inactividad y la complejidad de la sincronización. Sin embargo, mantener la base de datos sincronizada entre los entornos de origen y de destino permite desvincular la capa de base de datos de la capa de aplicación. Suponiendo que los servidores de aplicaciones no almacenan los datos persistentes de forma local, sino que los transfieren a la capa de base de datos, la sincronización también elimina las restricciones de tiempo de inactividad de la capa de aplicación.
Al desacoplar las capas de base de datos y aplicaciones, puede migrar los servidores de aplicaciones mediante MGN, como en el escenario anterior. Los servidores de aplicaciones de destino se pueden iniciar en el entorno de destino mientras los sistemas de origen siguen funcionando, procesando los datos y almacenándolos en la capa de base de datos. Como la capa de base de datos ya está sincronizada con la de destino, el tiempo de transición es mínimo: solo implica cambiar de red y redirigir las solicitudes de los clientes del antiguo sistema de origen al entorno de destino. Para ello, puede utilizar varios métodos, siguiendo las instrucciones para las blue/green implementaciones, normalmente cambiando los puntos de enlace del DNS, utilizando zonas de DNS ponderadas, utilizando métodos similares AWS Global Accelerator
