Descubrimiento del entorno de Windows

Con las tecnologías disponibles en la actualidad, como el Servicio de migración de aplicaciones, trasladar Windows Server, Linux y otros sistemas operativos basados en x86 y sus cargas de trabajo a AWS es bastante sencillo. Sin embargo, lograr que esas cargas de trabajo funcionen correctamente y hacerlo a gran escala presenta un conjunto diferente de desafíos. El objetivo de esta sección es identificar las consideraciones de migración que pueden permitirle migrar las cargas de trabajo de Microsoft de forma rápida, segura y sin problemas.

Evalúa

Si bien puede «forzar» migraciones más pequeñas (como las que involucran 100 servidores) con una planificación y una automatización mínimas, no puede mover 500 o más servidores con esta metodología. Las siguientes consideraciones contribuyen de manera importante a una migración a gran escala exitosa, y puede utilizar laEvaluación de preparación para la migración (MRA)para identificar las áreas de consideración en las que desea centrarse.

Arquitectura empresarial

Cuanta más deuda tecnológica haya en el medio ambiente, más difícil será migrar. Las organizaciones que cuentan con programas de arquitectura empresarial sólidos se esfuerzan por limitar su entorno a las versiones actuales y recientes de software y sistemas (a menudo denominadas versiones N y N -1 de las principales versiones). Esto no solo reduce la cantidad de escenarios que debe tener en cuenta, sino que también aprovecha los avances de las versiones más recientes. Por ejemplo, Windows Server 2012, Windows Server 2008 y las versiones anteriores de Windows Server son cada vez más difíciles de automatizar en el entorno de Windows Server que las versiones más actuales. La concesión de licencias también es más difícil para las versiones antiguas y no compatibles.

Administración de la estandarización y la configuración

La estandarización del entorno es otro factor a tener en cuenta. Se considera que las organizaciones que tienen entornos construidos y mantenidos a mano se parecen más a las mascotas. Cada sistema es único y hay muchas más combinaciones de configuración posibles que si se crearan utilizando imágenes estandarizadas, infraestructura como código (IaC) o canalizaciones de integración continua y entrega continua (CI/CD).

Por ejemplo, se recomienda reconstruir un servidor web típico mediante IAC o CI/CD durante la migración, en lugar de migrar manualmente el servidor individual. También se recomienda almacenar todos los datos persistentes en un almacén de datos, como una base de datos, un recurso compartido de archivos o un repositorio. Si los sistemas no se reconstruyen mediante IaC o CI/CD, deberían utilizar al menos herramientas de administración de la configuración (como Puppet, Chef o Ansible) para estandarizar los servidores de los que disponen.

Buenos datos

Los buenos datos también son un factor clave para el éxito de las migraciones. Los datos precisos sobre los servidores actuales y sus metadatos son esenciales para la automatización y la planificación. La falta de datos fiables aumenta la dificultad a la hora de planificar una migración. Algunos ejemplos de datos fiables incluyen un inventario preciso de los servidores, las aplicaciones en los servidores, el software de los servidores con versiones, la cantidad de CPU, la cantidad de memoria y la cantidad de discos. Le recomendamos que capture todos los datos que los planificadores de olas necesiten para planificar o cualquier dato que tenga previsto utilizar como parte de la automatización del proceso de migración.

 Automation

La automatización es esencial para las migraciones a gran escala. Los ejemplos de automatización incluyen la instalación del agente, la actualización de las versiones de software de las utilidades necesarias para la automatización, como .NET oPowerShell, cargando o actualizando software para AWS, como el AWS Systems Manager Agent (SSM Agent), AmazonCloudWatchagente u otro software de respaldo o administración necesario para ejecutarse en AWS.

Planificación detallada

Desarrollar y gestionar un plan detallado también es esencial para las migraciones a gran escala. Debe contar con un plan bien definido para migrar 50 servidores a la semana durante muchas semanas. Un plan eficaz incluye lo siguiente:

• Usaplanificación de olaspara organizar los servidores en oleadas de acuerdo con sus dependencias y prioridades.

• Usaplanificación semanal(antes de la transición) para comunicarse con los equipos de aplicaciones e identificar la red, el DNS, el firewall y otros detalles que deben abordarse durante la transición.

• Uso detallado, hour-to-hourplaneando(alrededor del período de transición real) para describir el período de mantenimiento del período de transición.

• Usacriterios de entrada y salidapara describir en qué circunstancias una aplicación se considerará transferida a AWS o se debe devolver por error a la ubicación de origen.

• Usaactividades de limpiezacomo actividades de seguimiento que deben completarse. Estas actividades pueden realizarse fuera del período de mantenimiento temporal o después de la finalización dehipercuidado. Las actividades de limpieza incluyen verificar las copias de seguridad y varios agentes, eliminar el agente del Servicio de migración de aplicaciones de un servidor o eliminar el servidor de origen y los recursos asociados.

Moviliza

Durante la fase de movilización, es importante descubrir la mayor cantidad posible de complejidades y variaciones de la organización para poder tenerlas en cuenta durante la planificación de la migración. Lo ideal sería evitar estas complejidades y variaciones durante el período de mantenimiento intermedio y evitar cualquier fallo.

Desafíos de las migraciones a gran escala

Los errores de migración se producen cuando una o varias aplicaciones se transfieren a sus nuevos entornos y no se pueden cumplir los requisitos funcionales o de rendimiento dentro del período de mantenimiento de la migración. Esto hace que la aplicación o las aplicaciones vuelvan por error a su ubicación original. Además, todas las demás aplicaciones que dependen de esa aplicación o aplicaciones también deben realizar una recuperación por error. Las migraciones fallidas tienden a afectar no solo a la ola actual sino también a las futuras, ya que las aplicaciones deben reprogramarse.

Dependencias sensibles a la latencia

Una de las principales razones de las migraciones fallidas son las dependencias sensibles a la latencia. Si no se identifican las dependencias que son sensibles a la latencia, se pueden presentar problemas de rendimiento que se traduzcan en tiempos de respuesta o transacciones inaceptables. Por ejemplo, normalmente una aplicación mueve sus servidores de bases de datos y aplicaciones a la nube al mismo tiempo porque se comunican entre sí con frecuencia y necesitan un tiempo de respuesta inferior a un milisegundo que tienen cuando ambos están en el mismo centro de datos. Es probable que mover solo la base de datos a la nube introduzca muchos segundos de latencia en esas transacciones, lo que tendrá un impacto significativo en el rendimiento de la aplicación. Esto también se aplica a las aplicaciones que dependen en gran medida unas de otras y que deben estar en el mismo centro de datos para funcionar adecuadamente.

Por lo tanto, comprender y abordar las dependencias de las aplicaciones es de vital importancia a la hora de planificar las migraciones. Las aplicaciones y los servicios que dependen unos de otros deben identificarse para poder migrarlos juntos.

Servicios compartidos de TI

Una vez que una carga de trabajo está en la nube, necesita una variedad de servicios para funcionar y mantenerse de forma adecuada y segura. Esto incluye una zona de aterrizaje, un perímetro de red y seguridad, la autenticación, los parches, los escáneres de seguridad, las herramientas de administración de servicios de TI, las copias de seguridad, los servidores bastiones y otros recursos. Sin estos servicios, es posible que las cargas de trabajo no funcionen correctamente y se vean obligadas a volver a su ubicación original por error.

Actualizaciones de configuración

En la mayoría de los casos, debe realizar varios cambios de configuración para que una carga de trabajo funcione correctamente después de trasladarla a la nube. Estos cambios de configuración suelen estar asociados a las siguientes dependencias de la carga de trabajo:

• Reglas de firewall

• Permitir listas

• Registros DNS

• Cadenas de conexión

Si no realiza las actualizaciones de configuración adecuadas, es posible que la carga de trabajo, sus usuarios y sus sistemas dependientes no puedan comunicarse entre sí. Podría ser posible resolver estos problemas dentro del período de interrupciones, pero los cambios en este momento pueden llevar mucho tiempo o requerir registros de cambios que no se puedan completar a tiempo.

Pruebas funcionales de aplicaciones

Otro desafío para las migraciones a escala es la necesidad de realizar pruebas funcionales de las aplicaciones. Esto es especialmente importante, ya que muchas organizaciones confían en los equipos de aplicaciones para identificar las dependencias sensibles a la latencia, los servicios compartidos de TI o las actualizaciones de configuración necesarias. Lo ideal es que el equipo de aplicaciones proporcione un plan de pruebas escrito o automatizado que puedan ejecutar durante el período de mantenimiento de transición para validar que la aplicación funciona a pleno rendimiento con un rendimiento aceptable. Para reducir al mínimo el período de mantenimiento durante la transición, la prueba debería poder completarse en 30 minutos.

Herramientas para la detección de dependencias de aplicaciones

Determinar las dependencias entre las aplicaciones es fundamental para que las migraciones se realicen correctamente, tanto para detectar las dependencias sensibles a la latencia como para los elementos de configuración de conectividad. Hay varias herramientas disponibles en el mercado para descubrir dependencias, comoServicio de descubrimiento de aplicaciones(agente y herramienta sin agente) yCloudamize(herramienta basada en agentes).

Al elegir una herramienta para la detección de dependencias de aplicaciones, tenga en cuenta lo siguiente:

• Duración— Le recomendamos que ejecute las herramientas de detección durante el tiempo suficiente para capturar los eventos específicos de la aplicación, como los picos conocidos, los eventos de fin de mes y otros eventos. El mínimo recomendado es de 30 días.

• Activo (basado en agentes)— Las herramientas de detección de dependencias activas suelen estar integradas en el núcleo del sistema operativo y capturan todas las transacciones. Sin embargo, este suele ser el método más caro y lento.

• Pasivo (sin agente)— Las herramientas de descubrimiento de dependencias pasivas son mucho más baratas y rápidas de implementar, pero corren el riesgo de perder algunas conexiones menos utilizadas.

• Conocimiento institucional— Si bien las herramientas de descubrimiento de aplicaciones proporcionan información más detallada y precisa, la mayoría de las organizaciones confían en sus equipos de aplicaciones y en sus conocimientos institucionales para descubrir las dependencias de las aplicaciones. Los equipos de aplicaciones suelen conocer las dependencias sensibles a la latencia, pero no es raro que pasen por alto algunos detalles, como los ajustes de configuración de la conectividad, las reglas del firewall o los requisitos de la lista de permitidos de un socio. Puede utilizar el conocimiento institucional para mejorar la detección de dependencias de aplicaciones, pero le recomendamos que también considere y mitigue los riesgos involucrados. Por ejemplo, existe el riesgo de que falten elementos de configuración de conectividad o dependencias sensibles a la latencia si solo depende del conocimiento de sus equipos de aplicaciones. Esto podría provocar interrupciones o migraciones fallidas. Para mitigar este riesgo, le recomendamos que realice pruebas funcionales detalladas de la aplicación.