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
Se utilizan la mayoría de lift-and-shift las migraciones grandes. AWS AWS Application Migration Service
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 del Servicio de migración de aplicaciones sobre la compatibilidad con SAN/NAS). Esto limita la aplicabilidad de la replicación mediante el Servicio de migración de aplicaciones 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 es compatible con plataformas x86 basadas en el sistema operativo Windows o Linux (consulte Sistemas operativos compatibles con el Servicio de migración de aplicaciones). Las plataformas que no son x86 están fuera del alcance de este método de migración. Entre ellas se incluyen RISC/CISC los sistemas ARM, las variantes de PowerPC, los sistemas IBM, como pSeries, iSeries y zSeries, y sus respectivos sistemas operativos, como AIX, HP-UX, Solaris, Linux para PowerPC, zLinux para mainframes y otras arquitecturas no x86.
El agente de AWS replicación funciona a nivel de un controlador de dispositivo de sistema de archivos virtual* en la pila de sistemas operativos 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 del Servicio de migración de aplicaciones, que contiene estas preguntas:
* Consulte las definiciones de sistema de archivos, sistema
Ventajas
Para lift-and-shift migraciones de cualquier escala, el servicio de migración de aplicaciones 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 pay-as-you-go precios, por lo que solo pagas por el servicio mientras lo utilices, sin contratos a largo plazo ni licencias complejas. El servicio de migración de aplicaciones ofrece un período gratuito de 90 días por servidor, lo que es suficiente para la mayoría de las migraciones. Para obtener más información, consulte los AWS Application Migration Service precios
en el AWS sitio web.
Desventajas
Al utilizar herramientas de replicación a nivel de bloques, como el Servicio de migración de aplicaciones, es posible que se produzcan los siguientes casos extremos y factores a tener en cuenta:
-
El servicio de migración de aplicaciones 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 (AWS patrón de orientación prescriptiva). -
El servicio de migración de aplicaciones no es compatible con la mayoría de las configuraciones de clústeres de servidores de archivos o clústeres de bases de datos 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 los dispositivos. Por ejemplo, no se admiten los clústeres de Microsoft SQL Server con la opción Storage Space Direct (S2D). Sin embargo, puede seguir utilizando el Servicio de migración de aplicaciones para replicar otros tipos de sistemas agrupados con almacenamiento en bloques compartido, como el almacenamiento compartido en configuraciones de instancias 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 en casos de esquina específicos. En general, el Servicio de migración de aplicaciones 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 poder ver el dispositivo 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 Application Migration Service no ofrece una opción de envío sin conexión, a diferencia de lo que ocurre. AWS Snowball
-
La migración requiere un período de tiempo de inactividad reducido, con un RTO de unos minutos. El Servicio de migración de aplicaciones utiliza 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.
Escenarios más adecuados
El Servicio de migración de aplicaciones cubre casi todas las lift-and-shift migraciones en su totalidad, con algunas desventajas, 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:
-
Migración a gran escala con varias oleadas de migración
-
Migración de una sola aplicación que requiere un tiempo de inactividad mínimo
Migración a gran escala con varias 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 del Servicio de Migración de Aplicaciones, 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 el Servicio de migración de aplicaciones 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 del Servicio de Migración de Aplicaciones, debe gestionarse de la misma manera que cualquier migración a gran escala descrita anteriormente.
Sin embargo, en los casos en 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 debería 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 el Servicio de migración de aplicaciones, 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 sistema de origen anterior al entorno de destino. Para ello, puede utilizar varios métodos, de acuerdo con las instrucciones de implementaciones azul/verde. En general, puede hacerse mediante el cambio de puntos de conexión DNS, el uso de zonas de DNS ponderadas, el uso de AWS Global Accelerator
