En esta página se describen las opciones de alta disponibilidad de Google Distributed Cloud (solo software) para VMware.
Función principal
Una instalación solo de software de Google Distributed Cloud para VMware incluye un clúster de administrador y uno o varios clústeres de usuario.
El clúster de administrador gestiona el ciclo de vida de los clústeres de usuarios, incluida la creación, las actualizaciones, las mejoras y la eliminación de clústeres de usuarios. En el clúster de administrador, el nodo maestro de administrador gestiona los nodos de trabajo de administrador, que incluyen los nodos maestros de usuario (nodos que ejecutan el plano de control de los clústeres de usuario gestionados) y los nodos de complementos (nodos que ejecutan los componentes de complementos que admiten la funcionalidad del clúster de administrador).
En cada clúster de usuarios, el clúster de administrador tiene un nodo no de alta disponibilidad o tres nodos de alta disponibilidad que ejecutan el plano de control. El plano de control incluye el servidor de la API de Kubernetes, el programador de Kubernetes, el gestor de controladores de Kubernetes y varios controladores críticos para el clúster de usuario.
La disponibilidad del plano de control del clúster de usuario es fundamental para las operaciones de las cargas de trabajo, como la creación, el escalado vertical y horizontal, y la finalización de las cargas de trabajo. Es decir, una interrupción del plano de control no afecta a las cargas de trabajo en ejecución, pero las cargas de trabajo existentes pierden las funciones de gestión del servidor de la API de Kubernetes si no está disponible el plano de control.
Las cargas de trabajo y los servicios en contenedores se despliegan en los nodos de trabajo del clúster de usuario. Ningún nodo de trabajo debe ser fundamental para la disponibilidad de la aplicación, siempre que la aplicación se implemente con pods redundantes programados en varios nodos de trabajo.
Habilitar la alta disponibilidad
vSphere y Google Distributed Cloud ofrecen una serie de funciones que contribuyen a la alta disponibilidad.
vSphere HA y vMotion
Te recomendamos que habilites las dos funciones siguientes en el clúster de vCenter que aloja tus clústeres de Google Distributed Cloud:
Estas funciones mejoran la disponibilidad y la recuperación en caso de que falle un host ESXi.
vCenter HA usa varios hosts ESXi configurados como un clúster para proporcionar una recuperación rápida tras interrupciones y una alta disponibilidad rentable para las aplicaciones que se ejecutan en máquinas virtuales. Te recomendamos que aprovisiones tu clúster de vCenter con hosts adicionales y habilites la monitorización de hosts de vSphere HA con Host Failure Response configurado como Restart VMs. De esta forma, tus máquinas virtuales se pueden reiniciar automáticamente en otros hosts disponibles en caso de que falle un host ESXi.
vMotion permite migrar en tiempo real máquinas virtuales de un host ESXi a otro sin que se produzca ningún tiempo de inactividad. En el caso del mantenimiento planificado de hosts, puedes usar la migración activa de vMotion para evitar por completo el tiempo de inactividad de las aplicaciones y garantizar la continuidad de la actividad empresarial.
Clúster de administradores
Google Distributed Cloud permite crear clústeres de administrador de alta disponibilidad. Un clúster de administración de alta disponibilidad tiene tres nodos que ejecutan componentes del plano de control. Para obtener información sobre los requisitos y las limitaciones, consulta Clúster de administrador de alta disponibilidad.
Ten en cuenta que la falta de disponibilidad del plano de control del clúster de administrador no afecta a la funcionalidad de los clústeres de usuarios ni a las cargas de trabajo que se ejecutan en ellos.
Hay dos nodos de complementos en un clúster de administrador. Si uno de ellos falla, el otro puede seguir atendiendo las operaciones del clúster de administrador. Para ofrecer redundancia, Google Distributed Cloud distribuye los servicios complementarios críticos, como kube-dns, en ambos nodos complementarios.
Si asigna el valor antiAffinityGroups.enabled a true en el archivo de configuración del clúster de administrador, Google Distributed Cloud crea automáticamente reglas de antafinidades de DRS de vSphere para los nodos del complemento, lo que hace que se distribuyan en dos hosts físicos para la alta disponibilidad.
Clúster de usuarios
Para habilitar la alta disponibilidad en un clúster de usuarios, define masterNode.replicas como 3 en el archivo de configuración del clúster de usuarios. Si el clúster de usuarios tiene habilitado Controlplane V2 (opción recomendada), los tres nodos de plano de control se ejecutan en el clúster de usuarios.
Los clústeres de usuarios de alta disponibilidad antiguos que no tienen habilitado Controlplane V2
ejecutan los tres nodos de plano de control en el clúster de administrador. Cada nodo del plano de control también ejecuta una réplica de etcd. El clúster de usuario sigue funcionando mientras haya un plano de control en ejecución y un quórum de etcd. Un quórum de etcd requiere que funcionen dos de las tres réplicas de etcd.
Si asignas el valor antiAffinityGroups.enabled a true en el archivo de configuración del clúster de administrador, Google Distributed Cloud crea automáticamente reglas de antiafinidad de DRS de vSphere para los tres nodos que ejecutan el plano de control del clúster de usuario.
Esto hace que esas VMs se distribuyan en tres hosts físicos.
Google Distributed Cloud también crea reglas de antiafinidad de vSphere DRS para los nodos de trabajador de tu clúster de usuario, lo que provoca que esos nodos se distribuyan en al menos tres hosts físicos. Se usan varias reglas de antiafinidad de DRS por grupo de nodos de clúster de usuario en función del número de nodos. De esta forma, los nodos de trabajador pueden encontrar hosts en los que ejecutarse, aunque el número de hosts sea inferior al número de máquinas virtuales del grupo de nodos del clúster de usuario. Le recomendamos que incluya hosts físicos adicionales en su clúster de vCenter. También debes configurar DRS para que sea totalmente automático, de forma que, si un host deja de estar disponible, DRS pueda reiniciar automáticamente las VMs en otros hosts disponibles sin infringir las reglas de antiafinidad de las VMs.
Google Distributed Cloud mantiene una etiqueta de nodo especial, onprem.gke.io/failure-domain-name, cuyo valor se asigna al nombre de host de ESXi subyacente. Las aplicaciones de usuario que quieran tener una alta disponibilidad pueden configurar reglas podAntiAffinity con esta etiqueta como topologyKey para asegurarse de que sus pods de aplicación se distribuyan entre diferentes máquinas virtuales y hosts físicos.
También puedes configurar varios grupos de nodos para un clúster de usuario con diferentes almacenes de datos y etiquetas de nodo especiales. Del mismo modo, puedes configurar podAntiAffinity
reglas con esa etiqueta de nodo especial como topologyKey para conseguir una mayor
disponibilidad en caso de fallos del almacén de datos.
Para que las cargas de trabajo de los usuarios tengan alta disponibilidad, asegúrate de que el clúster de usuarios tenga un número suficiente de réplicas en nodePools.replicas, lo que garantiza que el número deseado de nodos de trabajo del clúster de usuarios esté en funcionamiento.
Puedes usar almacenes de datos independientes para los clústeres de administrador y los de usuario para aislar sus fallos.
Balanceador de carga
Hay dos tipos de balanceadores de carga que puedes usar para conseguir una alta disponibilidad.
Balanceador de carga MetalLB agrupado
En el caso del balanceador de carga MetalLB incluido,
la alta disponibilidad se consigue teniendo más de un nodo con enableLoadBalancer: true.
MetalLB distribuye los servicios en los nodos del balanceador de carga, pero solo hay un nodo principal que gestiona todo el tráfico de un servicio.
Durante la actualización del clúster, hay un periodo de inactividad cuando se actualizan los nodos del balanceador de carga. La duración de la interrupción de la conmutación por error de MetalLB aumenta a medida que lo hace el número de nodos del balanceador de carga. Si hay menos de 5 nodos, la interrupción se produce en un plazo de 10 segundos.
Balanceo de carga manual
Con el balanceo de carga manual, puedes configurar Google Distributed Cloud para que use el balanceador de carga que elijas, como F5 BIG-IP o Citrix. La alta disponibilidad se configura en el balanceador de carga, no en Google Distributed Cloud.
Usar varios clústeres para la recuperación tras fallos
Desplegar aplicaciones en varios clústeres de varios servidores vCenter puede proporcionar una mayor disponibilidad global y limitar el radio de explosión durante las interrupciones.
En esta configuración se usa el clúster del centro de datos secundario para la recuperación ante desastres en lugar de configurar un clúster nuevo. A continuación, se muestra un resumen general de cómo conseguirlo:
Crea otro clúster de administrador y otro clúster de usuario en el centro de datos secundario. En esta arquitectura de varios clústeres, los usuarios deben tener dos clústeres de administrador en cada centro de datos, y cada clúster de administrador ejecuta un clúster de usuario.
El clúster de usuarios secundario tiene un número mínimo de nodos de trabajador (tres) y es un sistema de reserva activo (siempre en funcionamiento).
Las implementaciones de aplicaciones se pueden replicar en los dos vCenters mediante Config Sync. Sin embargo, lo más recomendable es usar una cadena de herramientas de DevOps de aplicaciones (CI/CD, Spinnaker) que ya tengas.
En caso de desastre, el clúster de usuarios se puede cambiar de tamaño al número de nodos.
Además, es necesario cambiar el DNS para enrutar el tráfico entre los clústeres al centro de datos secundario.