Migración de clústeres de conmutación por error de Windows - Recomendaciones de AWS
EvaluaciónMovilizaciónMigración

Migración de clústeres de conmutación por error de Windows

Un clúster de conmutación por error de Microsoft es un grupo de servidores con almacenamiento mayoritariamente compartido entre ellos. Puede usar clústeres de conmutación por error para facilitar la alta disponibilidad de sus aplicaciones y servicios. También puede migrar los clústeres de conmutación por error a la Nube de AWS para beneficiarse de su fiabilidad, rendimiento y menor TCO.

Los clústeres de conmutación por error de Windows funcionan de forma diferente en la nube que en los entornos en las instalaciones. Es importante tener en cuenta que solo se pueden implementar clústeres de varias subredes en la nube. A diferencia de los entornos en las instalaciones, la dirección IP de un clúster de conmutación por error de Windows se asigna a una instancia de Elastic Network Adapter (ENA) y no en el nivel de sistema operativo. En un entorno en las instalaciones, el sistema operativo gestiona la asignación de direcciones IP, pero un proveedor de nube (AWS) gestiona la asignación de direcciones IP en la nube. Como la agrupación en clústeres de conmutación por error es una característica de nivel de sistema operativo, no puede controlar la conmutación por error de IP. Por lo tanto, la misma IP no puede realizar la conmutación por error entre nodos. Para solucionar este problema, puede utilizar clústeres de varias subredes, en los que los clústeres se conmutan por error a una IP secundaria. La IP secundaria se asigna a ENA en otra subred y puede conectarse. Para obtener más información, consulte Failover Clustering Networking Basics and Fundamentals en la documentación de Microsoft.

La migración de un clúster de conmutación por error de Windows a AWS puede ser un proceso complejo, pero con una planificación e implementación cuidadosas se puede realizar con una interrupción mínima de las operaciones empresariales. Por ejemplo, cada aplicación se configura de forma diferente en un clúster de conmutación por error, por lo que es imprescindible comprender sus necesidades y, luego, averiguar de antemano cómo se pueden satisfacer en la nube. El proceso consta de los pasos siguientes:

  • Garantizar que todos los nodos del clúster ejecuten la misma versión de Windows y todas las actualizaciones necesarias

  • Configurar el quórum del clúster

  • Garantizar que se haga una copia de seguridad de todas las aplicaciones y los datos y que se puedan restaurar durante la migración

Evaluación

La fase de evaluación es un paso fundamental en el proceso de migración de un clúster de conmutación por error a AWS. Durante esta fase, recopilará información sobre su entorno actual, determinará la viabilidad de migrar a AWS e identificará los posibles desafíos o riesgos. Le recomendamos que siga estos pasos durante la fase de evaluación:

  • Evalúe el nivel de preparación de las aplicaciones: determine si las aplicaciones se pueden migrar a AWS sin modificaciones o si es necesario actualizarlas o reescribirlas para usar los servicios nativos en la nube.

  • Evalúe sus requisitos de red y seguridad: determine los requisitos de red y seguridad, tal como la configuración de firewalls, equilibradores de carga y VPN.

  • Evalúe los requisitos de migración de datos: determine cómo se migran los datos a AWS, tales como el tamaño y la ubicación de los datos, el tiempo necesario para la migración y los costos de transferencia de datos. En un entorno local, es posible que utilice diversas tecnologías de almacenamiento, como JBOD, NAS y SAN. Cada una puede presentar los datos a su aplicación a través de diferentes métodos de acceso, como SAN Fibre Channel, iSCSI, SAS o recursos compartidos SMB o NFS.

  • Identifique los posibles riesgos y desafíos: identifique los posibles riesgos o desafíos que puedan afectar al proceso de migración, como el tiempo de inactividad, los problemas de compatibilidad o la pérdida de datos.

  • Estime los costos: calcule el costo de la migración a AWS, tal como el costo de las instancias de Amazon EC2, el almacenamiento, la transferencia de datos y cualquier otro Servicios de AWS necesario.

  • Cree un plan de migración: en función de la información recopilada durante la fase de evaluación, cree un plan de migración detallado que incluya los plazos, los recursos necesarios y los pasos necesarios para migrar a AWS.

Evaluación del entorno actual

Evalúe el entorno actual, tal como las configuraciones de hardware y software, para determinar qué debe migrarse a AWS. Identifique cualquier dependencia entre las aplicaciones, los servidores y las bases de datos.

Determinación de la estrategia de migración

Considere sus opciones para migrar a AWS, por ejemplo, un enfoque de migración mediante lift-and-shift o el rediseño del entorno para usar los servicios nativos en la nube.

  • Migración de clústeres de conmutación por error tradicional: si va a configurar de manera manual un clúster de conmutación por error de Microsoft desde cero, puede seguir las instrucciones de Deploy SQL Server on Amazon EC2. El almacenamiento compartido es una de las consideraciones más importantes a la hora de migrar un clúster de conmutación por error. Amazon EBS Multi-Attach no admite la reserva persistente de SCSI-3, pero Amazon FSx para Windows File Server y Amazon FSx para NetApp ONTAP funcionan bien como opciones de almacenamiento compartido. Uno de los casos de uso más comunes es el uso de una instancia de clúster de conmutación por error Always On para un clúster de SQL Server con Amazon FSx para Windows File Server. Para más información, consulte Simplify your Microsoft SQL Server high availability deployments using Amazon FSx for Windows File Server en el blog de AWS sobre almacenamiento. El siguiente paso es llevar los nodos a la nube. Esto se puede lograr mediante AWS Application Migration Service. Para más información, consulte Migrating your Microsoft Windows clusters to AWS using CloudEndure Migration en el blog de AWS sobre almacenamiento. A continuación, puede configurar un rol agrupado en clústeres para su aplicación a fin de ofrecer alta disponibilidad.

  • Migración prácticamente sin tiempo de inactividad mediante un clúster expandido: un clúster expandido podría ser una buena opción si tiene una aplicación empresarial fundamental que migrar a la nube y no puede permitirse el tiempo de inactividad. Con un clúster expandido de Microsoft, el sitio A y el sitio B deben comunicarse entre sí a través de una red, pero pueden tener su propio almacenamiento compartido individual. Puede utilizar esto a su favor en un escenario de migración. Por ejemplo, su origen (ya sea en las instalaciones o en la nube de otro proveedor) puede ser el sitio A, que tiene conectividad de red con una VPC de Amazon en la que se implementa el sitio B. Una vez que el sitio B esté en funcionamiento, puede pasar al sitio B. El mecanismo de replicación de datos es fundamental en este enfoque, ya que la tecnología de almacenamiento de origen puede tener factores limitantes en cuanto al método de replicación que podría funcionar.

  • Migración de un clúster de conmutación por error implementado en VMware en las instalaciones a VMware en la AWS: VMware Cloud en AWS es compatible de manera nativa con la reserva persistente de SCSI-3. Esto permite alojar un clúster de conmutación por error en un disco de máquina virtual (VMDK) en VMware Cloud en AWS. Para más información, consulte Migrating SQL Server FCI cluster with shared disks to VMware Cloud on AWS en la documentación de VMware.

    Aviso

    A partir del 30 de abril de 2024, AWS ni sus socios de canales dejarán de revender VMware Cloud en AWS. El servicio seguirá estando disponible a través de Broadcom. Le recomendamos ponerse en contacto con el representante de AWS para más información.

  • Migración de una FCI de SQL Server mediante Amazon EBS Multi-Attach: puede utilizar las reservas de Amazon EBS Multi-Attach y NVMe para crear instancias de clúster de conmutación por error (FCI) de SQL Server con volúmenes io2 de Amazon EBS como almacenamiento compartido en los clústeres de conmutación por error de Windows Server. Estos volúmenes se pueden vincular solo a las instancias que se encuentren en la misma zona de disponibilidad. Para la implementación de clústeres de conmutación por error de Windows Server mediante volúmenes io2 de Amazon EBS son necesarios los controladores de Windows más recientes que traducen los comandos de reserva SCSI en comandos de reserva de NVMe.  Para más información sobre cómo migrar las FCI de SQL Server en las instalaciones a AWS en una única zona de disponibilidad mediante este enfoque, consulte la entrada del blog de AWS How to deploy a SQL Server failover cluster with Amazon EBS Multi-Attach on Windows Server.

La fase de evaluación es fundamental para garantizar una migración satisfactoria del clúster de conmutación por error a AWS. Si dedica tiempo a recopilar información e identificar los posibles desafíos, puede desarrollar un plan de migración integral que minimice el tiempo de inactividad, reduzca el riesgo y garantice una transición fluida a AWS.

Movilización

Durante la migración de un clúster de conmutación por error a AWS, la fase de movilización implica preparar el clúster para la migración a AWS y probarlo para garantizar su correcto funcionamiento. La fase de movilización incluye los siguientes pasos:

  1. Prepare el entorno de destino: en este paso, creará los recursos de AWS necesarios para alojar el clúster de conmutación por error. Esto implica configurar una VPC, subredes, grupos de seguridad y otros recursos necesarios.

  2. Prepare el entorno de origen: en este paso, prepare el clúster de conmutación por error existente para la migración. Esto puede implicar realizar cambios en la configuración de la red, configurar la replicación o instalar el software necesario.

  3. Valide el clúster: una vez preparados los entornos de origen y de destino, puede realizar una prueba de validación para asegurarse de que el clúster funciona correctamente. Esto implica ejecutar una serie de pruebas para garantizar que el clúster pueda realizar correctamente la conmutación por error al entorno de destino.

  4. Cree un enlace de replicación: después de la prueba de validación, puede crear un enlace de replicación entre los entornos de origen y de destino. Esto garantiza que cualquier cambio realizado en el entorno de origen se replique en el entorno de destino.

  5. Supervise la replicación: una vez establecido el enlace de replicación, supervise el proceso de replicación para asegurarse de que todos los cambios se replican correctamente.

  6. Realice la conmutación por error del clúster: después de comprobar que la replicación funciona correctamente, realice la conmutación por error final al entorno de destino. Esto implica detener los servicios del clúster en el entorno de origen e iniciarlos en el entorno de destino.

  7. Pruebe la conmutación por error: una vez finalizada la conmutación por error, realice una prueba para asegurarse de que las aplicaciones y los servicios que se ejecutan en el clúster funcionan correctamente en el nuevo entorno

Migración

La migración de un clúster de conmutación por error de Microsoft puede ser un proceso complejo que requiere una planificación e implementación cuidadosas para garantizar un resultado exitoso. Es esencial evaluar minuciosamente el entorno existente, identificar los posibles problemas y desarrollar un plan de migración integral que incluya las pruebas y la validación antes de realizar cualquier cambio en el entorno de producción. Durante la fase de migración, es importante supervisar de cerca el proceso y abordar rápidamente cualquier problema o comportamiento inesperado. La comunicación y la colaboración entre todas las partes interesadas, incluidos los equipos de TI, los usuarios empresariales y los proveedores, son fundamentales para un proceso de migración fluido.

Además, es importante tener en cuenta el impacto de la migración en cualquier aplicación o servicio de terceros que se ejecute en el clúster de conmutación por error. Identifique las dependencias y pruebe esas aplicaciones minuciosamente para asegurarse de que siguen funcionando según lo previsto tras la migración. Otro aspecto clave de la fase de migración es establecer un plan de reversión en caso de que se produzcan problemas o fallos imprevistos durante el proceso de migración. Lo ideal es que este plan incluya medidas para revertir la migración y restaurar el entorno original y, al mismo tiempo, minimizar cualquier impacto en el entorno de producción.

Por último, una vez que se complete la migración y el clúster de conmutación por error se ejecute correctamente en el nuevo entorno, es importante realizar la validación y las pruebas posteriores a la migración para confirmar que todo funciona según lo previsto. Esto incluye la supervisión del rendimiento, la validación de las capacidades de conmutación por error y la garantía de que todas las aplicaciones y servicios funcionan correctamente.