Descubrimiento del entorno Windows

Con las tecnologías disponibles en la actualidad, por ejemplo AWS Application Migration Service, trasladar Windows Server, Linux y otros sistemas operativos basados en x86 y sus cargas de trabajo a otros sistemas operativos 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 sus cargas de trabajo de Microsoft de forma rápida, segura y fluida.

Evaluación

Si bien puede «forzar» migraciones más pequeñas (como las que implican 100 servidores) con un mínimo de planificación y automatización, no puede mover 500 o más servidores con esta metodología. Las siguientes consideraciones son las principales que contribuyen al éxito de una migración a gran escala, y puede utilizar la evaluació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 saludables 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 versiones principales). Esto no solo reduce la cantidad de escenarios que hay que 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 hubieran creado utilizando imágenes estandarizadas, infraestructura como código (IaC) o procesos de integración y entrega continuas (CI/CD).

Por ejemplo, se recomienda reconstruir un servidor web típico con iAC oCI/CD when migrating, as opposed to manually migrating the individual server. It's also a best practice to store all persistent data in a datastore such as a database, file share, or repository. If systems aren't rebuilt using IaC or CI/CD, al menos, utilizar herramientas de administración de la configuración (como Puppet, Chef o Ansible) para estandarizar los servidores que tienen.

Datos de calidad

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 son un inventario preciso de los servidores, las aplicaciones de los servidores, el software de los servidores con sus versiones, el número CPUs, la cantidad de memoria y el número de discos. Le recomendamos que capture todos los datos que los planificadores de oleadas necesiten para la planificación o cualquier dato que vaya a utilizar como parte de la automatización del proceso de migración.

Automatización

La automatización es esencial para las migraciones a gran escala. Algunos 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 PowerShell, o la carga o actualización del software para, por AWS ejemplo, el AWS Systems Manager agente (SSM Agent), el CloudWatch agente Amazon u otro software de respaldo o administración necesario para ejecutarse. 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 varias semanas. Un plan eficaz incluye lo siguiente:

• Utilice la planificación de oleadas para organizar los servidores en oleadas de acuerdo con sus dependencias y prioridades.

• Planifique semanalmente (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.

• Utilice una hour-to-hourplanificación detallada (en torno a la transición real) para describir el período de mantenimiento de la transición.

• Utilice los criterios de aprobación o rechazo para describir en qué circunstancias se considerará que una aplicación se ha transferido a la ubicación de origen AWS o se debe devolver por error a la ubicación de origen.

• Utilice las actividades de limpieza como actividades de seguimiento que deben completarse. Estas actividades pueden realizarse fuera del período de mantenimiento temporal o una vez finalizada la hiperatención. Las actividades de limpieza incluyen la verificación de las copias de seguridad y varios agentes, la eliminación del agente del Servicio de Migración de Aplicaciones de un servidor o la eliminación del servidor de origen y los recursos asociados.

Movilización

Durante la fase de movilización, es importante descubrir el mayor número posible de complejidades y variaciones de la organización para poder tenerlas en cuenta a la hora de planificar la migración. Lo ideal sería evitar tener que lidiar con este tipo de complejidades y variaciones durante el período de transición del mantenimiento y evitar posibles fallos.

Los desafíos de las migraciones a gran escala

Los errores de migración se producen cuando una o varias aplicaciones se han trasladado a sus nuevos entornos y no se pueden cumplir los requisitos funcionales o de rendimiento durante el período de mantenimiento de la migración. Esto hace que la aplicación o las aplicaciones devuelvan por error a su ubicación original. Además, todas las demás aplicaciones que dependen de esa aplicación o aplicaciones también necesitan realizar una recuperación por recuperación. 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 sensibles a la latencia, se pueden producir problemas de rendimiento que se traduzcan en tiempos de respuesta o de transacción inaceptables.

Por ejemplo, una aplicación suele trasladar sus servidores de bases de datos y aplicaciones a la nube al mismo tiempo, ya que se comunican entre sí con frecuencia y necesitan el tiempo de respuesta inferior a un milisegundo del que disponen cuando ambos se encuentran en el mismo centro de datos. Mover solo la base de datos a la nube probablemente genere 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 suma 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 de TI compartidos

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, autenticación, parches, escáneres de seguridad, herramientas de administración de servicios de TI, copias de seguridad, hosts 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 que la carga de trabajo se traslade a la nube. Estos cambios de configuración suelen estar asociados a las siguientes dependencias de la carga de trabajo:

• Reglas de firewall

• Listas de permitidos

• 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 se comuniquen entre sí. Podría ser posible resolver estos problemas dentro del período de interrupción, pero los cambios en este momento pueden llevar mucho tiempo o requerir registros de cambios que no se pueden gestionar a tiempo.

Pruebas funcionales de las aplicaciones

Otro desafío para las migraciones a gran 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 un equipo de aplicaciones proporcione un plan de pruebas escrito o automatizado que pueda ejecutar durante el período de mantenimiento temporal para validar que su aplicación es totalmente funcional y tiene un rendimiento aceptable. Para reducir al mínimo el período de mantenimiento temporal, la prueba debería poder completarse en 30 minutos.

Herramientas para descubrir la dependencia de las aplicaciones

Determinar las dependencias entre las aplicaciones es fundamental para el éxito de las migraciones, tanto para detectar las dependencias sensibles a la latencia como para detectar los elementos de configuración de la conectividad. Existen varias herramientas disponibles en el mercado para descubrir las dependencias, como AWS Application Discovery Service(herramienta con y sin agente) y Cloudamize (herramienta basada en agentes).

Cuando elija una herramienta para descubrir la dependencia de las 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 pasivas de detección de dependencias 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 entre las aplicaciones. Los equipos de aplicaciones suelen estar bien informados sobre las dependencias que dependen de 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 una lista de admitidos por parte de un socio. Puede utilizar sus conocimientos institucionales para mejorar la detección de las dependencias de las aplicaciones, pero le recomendamos que también considere y mitigue los riesgos que ello implica. Por ejemplo, existe el riesgo de que se pierdan 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 las aplicaciones.