Migre Azure Kubernetes Service (AKS) y cargas de trabajo del servidor flexible de MySQL a la compatibilidad con zonas de disponibilidad

En esta guía se describe cómo migrar una carga de trabajo de servidor flexible de Azure Kubernetes Service y MySQL para completar la compatibilidad con la zona de disponibilidad en todos los servicios dependientes. Para obtener una lista completa de todas las dependencias de carga de trabajo, consulte Dependencias del servicio de carga de trabajo.

La compatibilidad con la zona de disponibilidad para esta carga de trabajo debe estar habilitada durante la creación del clúster de AKS o del servidor flexible de MySQL. Si quiere compatibilidad con zonas de disponibilidad para un clúster de AKS existente y un servidor flexible de MySQL, deberá volver a implementar esos recursos.

Esta guía de migración se centra principalmente en las consideraciones de infraestructura y disponibilidad de la ejecución de la siguiente arquitectura en Azure:

Dependencias del servicio de carga de trabajo

Para proporcionar compatibilidad completa con cargas de trabajo para zonas de disponibilidad, cada dependencia de servicio de la carga de trabajo debe admitir zonas de disponibilidad.

Hay dos tipos de métodos de servicios admitidos de zona de disponibilidad: zonal o con redundancia de zona. La mayoría de los servicios admiten uno u otro. Sin embargo, en algunos casos, hay opciones para elegir un recurso con redundancia de zona o zona para ese servicio. Indicamos qué servicios admiten recursos zonales y con redundancia de zona en las siguientes recomendaciones. También indicamos qué servicios son globales y regionales.

La arquitectura de carga de trabajo de AKS y MySQL consta de las siguientes dependencias de componente:

Azure Kubernetes Service (AKS)

• Zonal : el grupo de nodos del sistema y los grupos de nodos de usuario son zonales cuando se seleccionan previamente las zonas en las que se implementan los grupos de nodos durante la creación. Se recomienda seleccionar previamente las tres zonas para mejorar la resistencia. Se pueden agregar más grupos de nodos de usuario que admiten zonas de disponibilidad a un clúster de AKS existente y proporcionando un valor para el zones parámetro .

• Con redundancia de zona: los componentes del plano de control de Kubernetes, como etcd, el servidor de API, Scheduler y el Administrador de controladores se replican o distribuyen automáticamente entre zonas.

  Nota:

  Para habilitar la redundancia de zona de los componentes del plano de control del clúster de AKS, debe definir el grupo de nodos del sistema predeterminado con zonas al crear un clúster de AKS. Agregar más grupos de nodos zonales a un clúster de AKS no zonal existente no hará que la zona de clúster de AKS sea redundante, ya que esa acción no distribuye los componentes del plano de control entre zonas después del hecho.

Servidor flexible para Azure Database for MySQL

• Zonal: el modo de disponibilidad zonal significa que un servidor en espera siempre está disponible dentro de la misma zona que el servidor principal. Aunque esta opción reduce el tiempo de conmutación por error y la latencia de red, es menos resistente debido a una única interrupción de zona que afecta a los servidores principal y en espera.

• Con redundancia de zona: el modo de disponibilidad con redundancia de zona significa que un servidor en espera siempre está disponible dentro de otra zona de la misma región que el servidor principal. Se habilitarán dos zonas para la redundancia de zona para los servidores principal y en espera. Se recomienda esta configuración para mejorar la resistencia.

Standard Load Balancer o Azure Application Gateway

Standard Load Balancer

Para comprender las consideraciones relacionadas con los recursos de Standard Load Balancer, consulte Load Balancer y Availability Zones.

• Con redundancia de zona: elegir redundancia de zona es la manera recomendada de configurar la dirección IP de front-end con la Load Balancer existente. El front-end con redundancia de zona se corresponde con el grupo de back-end del clúster de AKS, que se distribuye entre varias zonas.

• Zonal: si ancla los grupos de nodos a zonas específicas, como la zona 1 y la 2, puede seleccionar previamente la zona 1 y 2 para la dirección IP de front-end en el Load Balancer existente. El motivo por el que es posible que quiera anclar los grupos de nodos a zonas específicas podría deberse a la disponibilidad de la serie de SKU de máquina virtual especializada, como la serie M.

Azure Application Gateway

El uso del complemento controlador de entrada de Application Gateway con el clúster de AKS solo se admite en SKU de Application Gateway v2 (Estándar y WAF). Para comprender más consideraciones relacionadas con Azure Application Gateway, consulte Escalado de Application Gateway v2 y WAF v2.

Zonal: para usar las ventajas de las zonas de disponibilidad, se recomienda crear el recurso Application Gateway en varias zonas, como la zona 1, 2 y 3. Seleccione las tres zonas para obtener la mejor estrategia de resistencia dentro de la región. Sin embargo, para corresponder a los grupos de nodos de back-end, puede anclar los grupos de nodos a zonas específicas seleccionando previamente la zona 1 y 2 durante la creación del recurso de App Gateway. El motivo por el que es posible que quiera anclar los grupos de nodos a zonas específicas podría deberse a la disponibilidad de la serie de SKU de máquina virtual especializada, como M-series.

Almacenamiento con redundancia de zona (ZRS)

• Se recomienda que el clúster de AKS esté configurado con discos ZRS administrados porque son recursos con redundancia de zona. Los volúmenes se pueden programar en todas las zonas.

• Kubernetes tiene en cuenta las zonas de disponibilidad de Azure desde la versión 1.12. Puede implementar un PersistentVolumeClaim objeto que haga referencia a un disco administrado de Azure en un clúster de AKS de varias zonas. Kubernetes se encargará de programar cualquier pod por el que se genere una notificación de este PVC en la zona de disponibilidad correcta.

• Para Azure Database for SQL, se recomienda que los archivos de datos y de registro se hospeden en el almacenamiento con redundancia de zona (ZRS). Estos archivos se replican en el servidor en espera mediante la replicación de nivel de almacenamiento disponible con ZRS.

Azure Firewall

Zonal: para usar las ventajas de las zonas de disponibilidad, se recomienda crear el recurso Azure Firewall en varias zonas, como la zona 1, 2 y 3. Se recomienda seleccionar las tres zonas para mejorar la estrategia de resistencia dentro de la región.

Azure Bastion

Regional: Azure Bastion se implementa en redes virtuales o redes virtuales emparejadas y está asociado a una región de Azure. Para más información, consulte Confiabilidad en Azure Bastion.

Azure Container Registry (ACR)

Con redundancia de zona: se recomienda crear un registro con redundancia de zona en el nivel de servicio Premium. También puede crear una réplica del Registro con redundancia de zona estableciendo la zoneRedundancy propiedad para la réplica. Para obtener información sobre cómo habilitar la redundancia de zona para ACR, consulte Habilitación de la redundancia de zona en Azure Container Registry para lograr resistencia y alta disponibilidad.

Azure Cache for Redis

Con redundancia de zona: Azure Cache for Redis admite configuraciones con redundancia de zona en los niveles Premium y Enterprise. Una caché con redundancia de zona coloca sus nodos en distintas zonas de disponibilidad de la misma región.

Microsoft Entra ID

Global: Microsoft Entra ID es un servicio global con varios niveles de redundancia interna y capacidad de recuperación automática. Microsoft Entra ID se implementa en más de 30 centros de datos de todo el mundo que proporcionan zonas de disponibilidad donde están presentes. Este número está creciendo rápidamente a medida que se implementan más regiones.

Azure Key Vault

Regional: Azure Key Vault se implementa en una región. Para mantener una alta durabilidad de las claves y los secretos, el contenido del almacén de claves se replica dentro de la región y en una región secundaria dentro de la misma geografía.

Con redundancia de zona: en el caso de las regiones de Azure con zonas de disponibilidad y sin par de regiones, Key Vault usa almacenamiento con redundancia de zona (ZRS) para replicar el contenido del almacén de claves tres veces dentro de la única ubicación o región.

Consideraciones sobre la carga de trabajo

Azure Kubernetes Service (AKS)

• Los pods pueden comunicarse con otros pods, independientemente del nodo o la zona de disponibilidad en la que el pod llegue al nodo. La aplicación puede experimentar un mayor tiempo de respuesta si los pods se encuentran en diferentes zonas de disponibilidad. Aunque se espera que las latencias de ida y vuelta adicionales entre pods se encuentren dentro de un intervalo aceptable para la mayoría de las aplicaciones, hay escenarios de aplicación que requieren baja latencia, especialmente para un patrón de comunicación chatty entre pods.

• Se recomienda probar la aplicación para asegurarse de que funciona bien entre zonas de disponibilidad.

• Por motivos de rendimiento como baja latencia, los pods se pueden ubicar en el mismo centro de datos dentro de la misma zona de disponibilidad. Para buscar pods en el mismo centro de datos dentro de la misma zona de disponibilidad, puede crear grupos de nodos de usuario con una zona única y un grupo de selección de ubicación de proximidad. Puede agregar un grupo de selección de ubicación de proximidad (PPG) a un clúster de AKS existente mediante la creación de un nuevo grupo de nodos de agente y la especificación del PPG. Utilice restricciones de propagación de la topología de pods para controlar cómo se reparten los pods en su clúster AKS entre las zonas de disponibilidad, los nodos y las regiones.

• Después de que los pods que requieren comunicación de baja latencia se encuentran en la misma zona de disponibilidad, las comunicaciones entre los pods no son directas. En su lugar, las comunicaciones de pod se canaliza a través de un servicio que define un conjunto lógico de pods en el clúster de AKS. Los pods se pueden configurar para comunicarse con AKS y la comunicación con el servicio se equilibrará automáticamente con la carga de todos los pods que son miembros del servicio.

• Para aprovechar las ventajas de las zonas de disponibilidad, los grupos de nodos contienen máquinas virtuales subyacentes que son recursos zonales. Para admitir aplicaciones que tienen diferentes demandas de proceso o almacenamiento, puede crear grupos de nodos de usuario con tamaños de máquina virtual específicos al crear el grupo de nodos de usuario.

  Por ejemplo, puede decidir usar en Standard_M32ms para los M-series nodos de usuario porque los microservicios de la aplicación requieren un alto rendimiento, una latencia baja y tamaños de máquina virtual optimizados para memoria que proporcionan recuentos elevados de vCPU y grandes cantidades de memoria. En función de la región de implementación, al seleccionar el tamaño de la máquina virtual en el Azure Portal, es posible que vea que este tamaño de máquina virtual solo se admite en la zona 1 y 2. Puede aceptar esta configuración de resistencia como equilibrio para un alto rendimiento.

• No puede cambiar el tamaño de VM de un grupo de nodos después de crearlo. Para más información sobre las limitaciones del grupo de nodos, consulte Limitaciones.

Servidor flexible para Azure Database for MySQL

La implicación de implementar los grupos de nodos en zonas específicas, como la zona 1 y la 2, es que todas las dependencias de servicio del clúster de AKS también deben admitir la zona 1 y 2. En esta arquitectura de carga de trabajo, el clúster de AKS tiene una dependencia de servicio en Azure Database for MySQL servidores flexibles con resistencia de zona. Seleccionaría la zona 1 para el servidor principal y la zona 2 para que el servidor en espera se encuentre conjuntamente con los grupos de nodos de usuario de AKS.

Azure Cache for Redis

• Azure Cache for Redis distribuye mediante un mecanismo round-robin los nodos de una caché con redundancia de zona por las zonas de disponibilidad que haya seleccionado.

• No se puede actualizar una caché Premium existente para usar la redundancia de zona. Para usar la redundancia de zona, debe volver a crear la Azure Cache for Redis.

• Para lograr una resistencia óptima, se recomienda crear el Azure Cache for Redis con tres o más réplicas para poder distribuir las réplicas entre tres zonas de disponibilidad.

Consideraciones acerca de la recuperación ante desastres

Las zonas de disponibilidad se usan para mejorar la resistencia para lograr una alta disponibilidad de la carga de trabajo dentro de la región primaria de la implementación.

La recuperación ante desastres consta de operaciones y prácticas de recuperación definidas en el plan de continuidad empresarial. El plan de continuidad empresarial aborda cómo se recupera la carga de trabajo durante un evento disruptivo y cómo se recupera completamente después del evento. Considere la posibilidad de extender la implementación a una región alternativa.

Para el nivel de aplicación, revise las consideraciones de continuidad empresarial y recuperación ante desastres de AKS en este artículo.

• Considere la posibilidad de ejecutar varios clústeres de AKS en regiones alternativas. La región alternativa puede usar una región emparejada secundaria. O bien, si no hay ningún emparejamiento de regiones para la región primaria, puede seleccionar una región alternativa en función de su consideración para los servicios disponibles, la capacidad, la proximidad geográfica y la soberanía de datos. Revise la guía de decisión de las regiones de Azure. Revise también el patrón de stamp de implementación.

• Tiene la opción de configurar active-active, active-standby, active-passive para los clústeres de AKS.

• Para su nivel de base de datos, las características de recuperación ante desastres incluyen copias de seguridad con redundancia geográfica con la capacidad de iniciar la restauración geográfica y la implementación de réplicas de lectura en otra región.

• Durante una interrupción, deberá decidir si debe iniciar una recuperación. Solo tendrá que iniciar operaciones de recuperación cuando la interrupción dure más tiempo que el objetivo de tiempo de recuperación (RTO) de la carga de trabajo. De lo contrario, esperará la recuperación del servicio comprobando el estado del servicio en el panel de Estado del servicio de Azure. En la hoja Service Health de la Azure Portal, puede ver las notificaciones asociadas a su suscripción.

• Al iniciar la recuperación con la característica de restauración geográfica en Azure Database for MySQL, se crea un nuevo servidor de base de datos mediante datos de copia de seguridad que se replican desde otra región.

Pasos siguientes

Más información sobre:

Servicios de Azure compatibles con las zonas de disponibilidad

Regiones de Azure que admiten zonas de disponibilidad