Blog de Amazon Web Services (AWS)

Monitoreando AWS Application Migration Service en varias cuentas y regiones

Por Tom Conlin, arquitecto de infraestructura de nube para AWS Professional Services
Ajay Mehta, arquitecto sénior de infraestructura de nube para AWS Professional Services
y Santosh Vallurupalli, arquitecto de infraestructura de nube para AWS Professional Services

 

Por lo general, los clientes comienzan su viaje a la nube de AWS realojando (lift and shift) los servidores en su entorno local. Lo hacen por varios motivos comerciales, como pasar de gastos de capital a gastos operativos, reducir el costo total de propiedad, reducir los costos de soporte, evacuar el centro de datos y muchos otros. AWS Application Migration Service (MGN) es el servicio automatizado de realojado (lift and shift) que facilita las migraciones de servidores a AWS a gran escala. El servicio AWS MGN permite a las organizaciones trasladar aplicaciones a AWS con un tiempo de inactividad mínimo y sin cambiar las aplicaciones ni su arquitectura. Con AWS MGN, los clientes pueden migrar servidores con un tiempo de inactividad mínimo y sin necesidad de realizar ningún cambio en la aplicación.Escalar las operaciones de migración para satisfacer las necesidades empresariales requiere muchos componentes, incluida la observabilidad. Por lo general, los servidores se agrupan por dependencias y se migran como una unidad. Para que la unidad se pueda migrar correctamente, todos los datos deben estar completamente replicados el día de la migración. El agente AWS MGN se instala en los servidores de origen y, posteriormente, replica los datos en la cuenta y la región de AWS. Como resultado de cambios en el entorno, la red o los datos, la replicación puede detenerse o retrasarse, lo que pone en peligro la migración. Además, los servidores de origen desconectados incorrectamente de MGN requieren volver a replicar los datos, lo que puede provocar un retraso en la migración. Sin visibilidad de estos eventos, los plazos y la cadencia de la migración de los clientes corren el riesgo de retrasarse. Los retrasos en la migración generan costos adicionales y el reprocesamiento requiere más horas de trabajo. Monitorear los eventos de interrupción, retraso o desconexión del servidor de origen de manera oportuna puede ayudar a mitigar estos riesgos.

En este blog, le mostramos cómo configurar una solución de monitoreo para los servidores fuente de AWS MGN, que proporciona capacidades de registro y notificación para la replicación de datos estancada, el tiempo de replicación de datos transcurrido y los servidores de origen desconectados del servicio MGN. Con esta solución, los clientes pueden supervisar las operaciones de AWS MGN en varias cuentas a las que pueden migrar servidores desde entornos locales.

Descripción general de la solución

Esta solución utiliza un concepto de cuenta de AWS central (central account) y cuenta de AWS de destino (target account). La cuenta de AWS de destino es aquella a la que se migrará el servidor de origen local y la cuenta de AWS central es a la que se reenviarán los eventos de AWS MGN y las alarmas de CloudWatch de varias cuentas de AWS de destino para su procesamiento y agregación. He aquí una explicación adicional sobre la actividad que se produce en cada una de las cuentas, junto con la arquitectura de la solución propuesta:

Figura 1: Arquitectura de solución

1. Cuenta destino

Los recursos de monitoreo de cuentas de destino incluyen las alarmas de Amazon CloudWatch, la función AWS Lambda, las reglas de Amazon EventBridge y las funciones de administración de identidades y accesos de AWS. Cuando se implementa esta solución, esta crea una función Lambda en la cuenta de destino que crea automáticamente nuevas alarmas para indicar la duración del retraso y la replicación de los datos transcurridos cada vez que se incorporan nuevos servidores de origen a AWS MGN. Posteriormente, cuando los servidores de origen se eliminan de AWS MGN, una función Lambda adicional elimina automáticamente las alarmas que se configuraron para ese servidor de origen. Esta solución configura una regla de EventBridge que reenvía los eventos al EventBus de la cuenta central cuando las alarmas de CloudWatch pasan al estado de «ALARMA».

AWS MGN envía de forma nativa ciertos eventos de MGN a AWS EventBridge, incluso cuando la replicación de datos se detiene. Se configura una regla de EventBridge para reenviar los eventos al EventBus de la cuenta central cuando los servidores de origen de MGN experimentan un estancamiento en la replicación de datos. Puede supervisar una o varias cuentas de destino con esta solución siguiendo los pasos de implementación que se describen en el resto del blog. Para simplificar, utilizaremos una sola cuenta de destino como tutorial en este blog.

2. Cuenta central

Los recursos de la cuenta de monitoreo central incluyen un EventBus personalizado, una regla de EventBridge, una función Lambda, un tema y una suscripción a Amazon Simple Notification Service y un grupo de log (LogGroup) de CloudWatch.

Se configura una regla de EventBridge en la cuenta central para ejecutar una función Lambda (denominaremos a esta función como Lambda de cuenta central) cada vez que los eventos se suban al EventBus de la cuenta central. La función Lambda procesa los eventos en un esquema común y, a continuación, envía el evento formateado a un tema de SNS y a un grupo de registro de CloudWatch.

Prerrequisitos

En este blog, asumimos que ha configurado AWS Application Migration Service y está listo para instalar el agente de replicación en los servidores de origen destinados a la migración a AWS. También asumimos que tiene una cuenta central de AWS en la que se agregarán los eventos.

Antes de seguir los pasos de implementación de la solución, asegúrese de contar con lo siguiente:

  1. Dos cuentas de AWS con permisos para implementar y administrar los servicios descritos en este blog en dichas cuentas.
  2. Un bucket de S3 para almacenar la plantilla de CloudFormation empaquetada para la implementación de la solució

Pasos de implementación de la solución

La solución incluye dos plantillas de CloudFormation, una que se implementa en la cuenta de destino para recopilar eventos y alertas de MGN y la otra que se implementa en la cuenta central para procesar los eventos agregados y enviarlos a un tema de SNS para recibir alertas por correo electrónico. Estas plantillas de CloudFormation se encuentran en las carpetas central_account/ y target_account/ del repositorio de soluciones. La solución también incluye un código de ejemplo para la función Lambda que procesa los eventos agregados en la cuenta central. La función Lambda de la cuenta central se encuentra en lambda_function/.

A continuación, se muestran los pasos para implementar esta solución

  1. Empaqueta el código Lambda de la cuenta central
  2. Implemente la solución
    1. En tu cuenta central
    2. En tu cuenta de destino

1. Empaqueta el código Lambda de la cuenta central

En esta solución, le proporcionamos un código Lambda de muestra que procesa los eventos de CloudWatch Alarms y MGN desde varias cuentas. Puedes clonar el repositorio de GitHub y personalizar el código Lambda para que se ajuste a tus necesidades. La función Central Lambda está escrita en Python y es demasiado grande para incluirla en línea en la plantilla de CloudFormation, por lo que debe estar empaquetada. Para automatizar el empaquetado de la función Lambda, proporcionamos una plantilla de CloudFormation que configura un entorno de Cloud9. Siga los pasos que se indican a continuación para implementar la plantilla Cloud9 CloudFormation, que empaquetará el código Lambda y generará una plantilla de CloudFormation de salida que se podrá utilizar posteriormente para implementar la solución.

  1. Descargue esta plantilla de CloudFormation y guárdela localmente.
  2. En su cuenta central, vaya a la consola de AWS CloudFormation
  3. Elija Crear el apilamiento Create Stack y, a continuación, elija con nuevos recursos (estándar) With new resources (standard).
  4. En la página Crear el apilamiento, bajo especificar la plantilla (template) que descargó en el paso a), seleccione cargar un archivo de plantilla (Upload a template file).
  5. Seleccione Elegir archivo y, a continuación, elija el archivo de plantilla cloud9-mgn-monitoring.yaml de su carpeta local.
  6. En la página especificar detalles del apilamiento, introduzca un nombre para el apilamiento (por ejemplo MGNMonitoringCloud9Stack).
  7. En Parámetros, introduzca estos valores para los siguientes parámetros:
    1. S3BucketName: nombre del bucket de S3 donde se cargará la plantilla de CloudFormation empaquetada.
    2. MGNCodeZipUrl: URL del archivo zip del código MGN.

Cuando el apilamiento se haya implementado correctamente, vaya a la consola de S3, haga clic en el bucket de S3 que especificó en el paso #7 anterior y descargue el archivo central_account_monitoring_resources_packaged.yaml. A continuación, continúe con el paso #2.

2. Implemente la solución

a. En su cuenta central

Tras empaquetar el código Lambda de la cuenta central y comprobar que existe en el bucket de S3 que especificó, cree un apilamiento de CloudFormation en la cuenta central de AWS mediante la plantilla de CloudFormation recientemente generada central_account_monitoring_resources_packaged.yaml. Los recursos de la cuenta central se deben implementar primero, ya que el apilamiento de CloudFormation de la cuenta de destino toma las salidas del apilamiento central como entrada.

  1. Inicie sesión en la cuenta central y abra la consola de AWS CloudFormation.
  2. Confirme que la sesión de la consola se encuentra en la misma región de AWS que el bucket de S3 en el que empaquetó el código Lambda.
  3. Elija Crear el apilamiento (Create Stack) y, a continuación, elija con nuevos recursos (estándar) With new resources (standard).
  4. En la página Crear el apilamiento, bajo especificar la plantilla (template), seleccione cargar un archivo de plantilla (Upload a template file).
  5. Seleccione Elegir archivo y, a continuación, elija el archivo de plantilla central_account_monitoring_resources_packaged.yaml de su carpeta local (central_account/).
  6. Selecciona Siguiente (Next).
  7. En la página Especificar detalles del apilamiento, introduzca un nombre para el apilamiento (por ejemplo, MGNMonitoringCentralAccountStack).
  8. En Parámetros, introduzca estos valores para los siguientes parámetros:
    1. EventBusPolicyPrincipal: una lista separada por comas de los identificadores de cuentas de AWS que enviará los eventos de MGN a la cuenta central.
    2. MGNMonitoringLambdaRoleName: el nombre de la función que asume la función Lambda de procesamiento de eventos de Central MGN.
    3. SNSSubscriptionEmail: el correo electrónico al que se envían alertas de bloqueo, retraso, replicación de datos transcurridos y desconexión del servidor de origen de MGN.
  9. En la página Configurar opciones del apilamiento, puede añadir etiquetas o elegir otras opciones, si lo desea, y luego elegir siguiente (Next).
  10. En la página de revisión, valide los parámetros, active la casilla de verificación para confirmar que se crearán los recursos de IAM y, a continuación, elija Crear apilamiento (Create stack).
  11. Asegúrese de aceptar la suscripción a SNS. Se enviará al correo electrónico que proporcionó en la plantilla de CloudFormation.

b. En su cuenta destino

Del mismo modo, implemente la plantilla de CloudFormation de la cuenta de destino a través de la consola siguiendo los pasos que se indican a continuación:

  1. SInicie sesión en la cuenta destino y abra la consola de AWS CloudFormation.
  2. Confirme que la sesión de la consola se encuentra en la misma región de AWS que el bucket de S3 en el que almacenó el código.
  3. Elija Crear el apilamiento (Create Stack) y, a continuación, elija con nuevos recursos (estándar) With new resources (standard).
  4. En la página Crear el apilamiento, bajo especificar la plantilla (template), seleccione cargar un archivo de plantilla (Upload a template file).
  5. Seleccione Elegir archivo y a continuación, vaya a la carpeta target_account y seleccione target_account_monitoring_resources.yaml.
    1. Selecciona Siguiente (Next).
    2. En la página Especificar detalles del apilamiento, introduzca un nombre para el apilamiento (por ejemplo, MGNMonitoringTargetAccountStack).
    3. En Parámetros, introduzca estos valores para los siguientes parámetros:
      1. CentralLambdaRoleArn: el ARN del rol de la función Lambda de la cuenta central. Puede obtenerlo en la sección «Salidas» del apilamiento de CloudFormation creada en la cuenta central.
      2. CentralRegion: la región de AWS para centralizar eventos. Tenga en cuenta que, si la plantilla destino se implementa en otra región de la misma cuenta, la plantilla suprimirá la creación de roles de IAM tal como existen.
      3. CentralEventBusArn: el ARN de EventBus de la cuenta central: revíselo en la sección «Salidas» del apilamiento de CloudFormation creada en la cuenta central.
      4. LagDurationThresholdinSeconds: el umbral de duración del retraso de la alarma CloudWatch del servidor de origen de MGN. El valor predeterminado es 3600 segundos o 6 horas.
      5. ElapsedReplnDurationThresholdinSeconds: el umbral de duración de la replicación transcurrido para la alarma CloudWatch del servidor de origen de MGN. El valor predeterminado es 7776000 segundos, o 90 días. Una vez que se supere este umbral, los clientes incurrirán en costes por el uso de AWS MGN.
      6. LagDurationPeriodinSeconds: el período de tiempo durante el cual se recopilan los puntos de datos para superar el umbral de duración del retraso. El valor predeterminado es 300 segundos o 5 minutos.
      7. ElapsedReplnDurationPeriodinSeconds: el período de tiempo durante el cual se recopilan los puntos de datos para las infracciones del umbral de duración de la replicación acumulada. El valor predeterminado es 300 segundos o 5 minutos.
      8. LagDurationEvaluationPeriod: el número de períodos que CloudWatch evaluará al determinar el estado de la alarma. El valor predeterminado es 1.
      9. ElapsedReplnDurationEvaluationPeriod: el número de períodos que CloudWatch evaluará al determinar el estado de la alarma. El valor predeterminado es 1.
      10. AlarmLambdaExecutionRoleName: el nombre del rol Lambda IAM de creación y eliminación de alarmas de CloudWatch. El valor predeterminado es MGN-Monitoring-Generic-Alarm-Lambda-Role.
      11. TargetAccountEventRuleRoleName: el nombre del rol de IAM de la regla de EventBridge que permite a la regla colocar los eventos en el EventBus central. El valor predeterminado es MGN-Monitoring-Generic-EventBridge-Invoke-EventBus-Role.
      12. CentralAccountLambdaRoleName: el nombre del rol de IAM que asumirá la función Lambda de la cuenta central con permiso de solo lectura para AWS MGN en la cuenta de destino. El valor predeterminado es MGN-monitoring-generic-central-account-lambda-role. Tenga en cuenta que, si se cambia el nombre de este rol, esto también debe reflejarse en el código Lambda Python de la cuenta central.
    4. En la página Configurar opciones del apilamiento, puede añadir etiquetas o elegir otras opciones, si lo desea, y luego elegir siguiente (Next).
    5. En la página de revisión, valide los parámetros, active la casilla de verificación para confirmar que se crearán los recursos de IAM y, a continuación, elija Crear apilamiento (Create stack).

Probando la solución

Para probar la solución que implementó en los pasos anteriores, puede activar manualmente los eventos de MGN para simular los eventos de migración en tiempo real. En la siguiente sección, repasamos algunos de los eventos y alarmas de MGN y presentamos opciones sobre cómo puedes activar estos eventos manualmente para probarlos.

Evento de replicación de datos estancado

Tras instalar el agente de Application Migration Service (MGN) en un servidor de origen, se creará una instancia de EC2 con la etiqueta de nombre AWS Application Migration Service Replication Server en la cuenta de AWS de destino. Este servidor facilita la replicación de datos desde el servidor de origen a AWS. Para que la replicación continúe, el servidor de replicación y el agente deben comunicarse a través del puerto 1500. Por lo tanto, puede modificar las reglas del grupo de seguridad asociadas a la instancia de replicación de MGN para cerrar el puerto 1500 y detener la replicación.

Además, en el servidor de origen, puede detener el agente de replicación, que también detiene la replicación. Cualquiera de estos escenarios provocará un estancamiento del evento de replicación de datos que coincida con la regla EventBridge de la cuenta de Target que creamos a través de la cuenta de Target CloudFormation Stack. La activación de esta regla reenvía este evento al EventBus central. A continuación, verá un correo electrónico que indica que la replicación de datos se ha estancado en el servidor y una entrada de registro en el grupo de registro de Central CloudWatch.

La notificación por correo electrónico resultante se muestra a continuación:

Duración del retraso

Para las alarmas de CloudWatch con duración de retraso, puede ajustar el umbral de alarma a 1 segundo en la alarma de duración del retraso y añadir o crear un archivo de tamaño considerable en el servidor de origen. Esto generará un evento de retraso que también enviará un correo electrónico indicando que el servidor está retrasado en el servidor y una entrada de registro en el grupo de registro de Central CloudWatch.

La notificación por correo electrónico resultante se muestra a continuación:

Duración de la replicación transcurrida

Para la duración de la replicación transcurrida, ajuste el umbral de alarma a 1 segundo en la alarma de duración de la replicación transcurrida. Esto provocará que se incumpla el umbral de duración de la replicación transcurrida y la alarma de CloudWatch pasará a un estado de ALARMA. Esto también hará que la solución envíe un correo electrónico indicando que el servidor está retrasado en el servidor y una entrada de registro en el grupo de registro de Central CloudWatch.

La notificación por correo electrónico resultante se muestra a continuación:

Servidor de origen desconectado

Para desconectar un servidor de origen, vaya a la consola de AWS Application Migration Service, seleccione un servidor de origen de la lista, haga clic en el menú desplegable Acciones y seleccione Desconectarse del servicio. Esto generará el evento de desconexión del servidor de origen.

La notificación por correo electrónico resultante se muestra a continuación:

Limpiar

Para limpiar la configuración de MGN Monitoring y los componentes implementados por los apilamientos de AWS CloudFormation, siga los pasos que se indican a continuación.

Utilice la consola de AWS CloudFormation o la CLI de AWS para eliminar los apilamientos de CloudFormation que se implementaron como parte de los pasos 1 y 2 de la implementación de la solución, en las cuentas de AWS central y de destino. Al eliminar los apilamientos de CloudFormation en ambas cuentas, se eliminarán todos los recursos definidos en las plantillas de CloudFormation central y destino.

En la cuenta central, elimina el bucket de S3 y el código Lambda que ha subido anteriormente.

Conclusión

Con la solución que se describe en este blog, puede supervisar el estado de su migración de realojamiento a AWS en varias cuentas y regiones desde un lugar central. Además, puede incluir los eventos de MGN y personalizar aún más esta solución para incluir estas alertas en las herramientas de monitoreo y alertas de su empresa, como Moogsoft, ServiceNow, etc., para crear incidentes de forma automática y tener una visibilidad en tiempo real de los problemas que podrían afectar a su migración de realojamiento a AWS. La solución también es ampliable para incluir la supervisión de otros eventos emitidos por MGN durante el ciclo de vida de la migración.

 

Este artículo fue traducido del Blog de AWS en Inglés.


Acerca de los autores

Tom Conlin es arquitecto de infraestructura de nube para AWS Professional Services. Le gusta crear soluciones automatizadas y nativas de AWS para los clientes. En su tiempo libre, le gusta relajarse con familiares y amigos, viajar y ser voluntario en un centro local de rescate de perros.

 

 

 

 

Ajay Mehta es un arquitecto sénior de infraestructura de nube para AWS Professional Services. Trabaja con clientes empresariales para acelerar la adopción de la nube mediante la creación de zonas de destino y la transformación de las organizaciones de TI para que adopten prácticas operativas en la nube y operaciones ágiles. Cuando no está trabajando, le gusta pasar tiempo con la familia, viajar y explorar nuevos lugares.

 

 

 

 

Santosh Vallurupalli es un arquitecto de infraestructura de nube que forma parte del equipo de AWS Professional services. Le gusta ayudar a los clientes en su proceso de adopción de la nube y crear soluciones nativas de la nube para problemas complejos. Cuando no está trabajando, le gusta viajar y ver «The Office» en modo de repetición.

 

 

 

 

Traductor

Luis Alberto es un profesional con más de 28 años de trayectoria en tecnología. Está localizado en Colombia y es arquitecto de Soluciones, especialista en temas de migración a AWS para clientes de diferentes industrias en Latinoamérica. Está enfocado en apoyar a sus clientes en la adopción de herramientas que los ayudan a acelerar su migración a AWS.

 

 

 

 

Revisor

César es un arquitecto de soluciones especializado en migraciones para AWS basado en Santiago de Chile.