Google Distributed Cloud se ha diseñado para limitar el alcance de los fallos y priorizar las funciones que son esenciales para la continuidad del negocio. En este documento se explica cómo se ve afectada la funcionalidad de tus clústeres cuando se produce un fallo. Esta información puede ayudarte a priorizar las áreas en las que debes solucionar problemas.
La funcionalidad principal de Google Distributed Cloud incluye las siguientes categorías:
- Ejecutar cargas de trabajo: las cargas de trabajo actuales pueden seguir ejecutándose. Este es el factor más importante para mantener la continuidad del negocio. Aunque tu clúster tenga un problema, las cargas de trabajo pueden seguir ejecutándose sin interrupciones.
- Gestionar cargas de trabajo: puedes crear, actualizar y eliminar cargas de trabajo. Este es el segundo factor más importante a la hora de escalar cargas de trabajo cuando aumenta el tráfico, incluso si el clúster tiene algún problema.
- Gestionar clústeres de usuarios: puedes gestionar nodos, actualizar, mejorar y eliminar clústeres de usuarios. Esto es menos importante que las consideraciones sobre el ciclo de vida de la aplicación. Si hay capacidad disponible en los nodos, la imposibilidad de modificar los clústeres de usuarios no afecta a las cargas de trabajo de los usuarios.
- Gestionar clústeres de administrador: puedes actualizar y mejorar el clúster de administrador. Este es el factor menos importante, ya que el clúster de administrador no aloja ninguna carga de trabajo de usuario. Si tu clúster de administrador tiene un problema, tus cargas de trabajo de aplicaciones seguirán ejecutándose sin interrupciones.
En las siguientes secciones se usan estas categorías de funciones principales para describir el impacto de tipos específicos de situaciones de error.
Modos de fallo
Los siguientes tipos de fallos pueden afectar al rendimiento de los clústeres de Google Distributed Cloud.
Fallo del host ESXi
En este caso de fallo, un host ESXi que ejecuta instancias de máquinas virtuales (VM) que alojan nodos de Kubernetes puede dejar de funcionar o sufrir una partición de red.
| Ejecutar cargas de trabajo | Gestionar cargas de trabajo | Gestionar clústeres de usuarios | Gestionar clústeres de administradores | |
|---|---|---|---|---|
| Interrupción | Posibles interrupciones y recuperación automática | Posibles interrupciones y recuperación automática | Interrupciones y recuperación automática | Interrupciones y recuperación automática |
| Explicación | Los pods que se ejecutan en las VMs alojadas por el host con errores se interrumpen y se vuelven a programar automáticamente en otras VMs en buen estado. Si las aplicaciones de usuario tienen capacidad de carga de trabajo de repuesto y se distribuyen en varios nodos, los clientes que implementen reintentos no podrán observar la interrupción. |
Si el fallo del host afecta a la VM del plano de control de un clúster de usuario que no es de alta disponibilidad o a más de una VM del plano de control de un clúster de usuario de alta disponibilidad, se producirá una interrupción. | Si el fallo del host afecta a la VM de plano de control o a las VMs de trabajador del clúster de administrador, se producirá una interrupción. | Si el fallo del host afecta a la máquina virtual de plano de control del clúster del administrador, se producirá una interrupción. |
| Recuperación | vSphere HA reinicia automáticamente las VMs en hosts en buen estado. | vSphere HA reinicia automáticamente las VMs en hosts en buen estado. | vSphere HA reinicia automáticamente las VMs en hosts en buen estado. | vSphere HA reinicia automáticamente las VMs en hosts en buen estado. |
| Prevención | Implementa cargas de trabajo de alta disponibilidad para minimizar la posibilidad de que se produzcan interrupciones. | Usa clústeres de usuarios de alta disponibilidad para minimizar la posibilidad de que se produzcan interrupciones. | — | — |
Fallo de la VM
En este caso, es posible que una VM se elimine de forma inesperada, que un disco de arranque se dañe o que una VM se vea comprometida debido a problemas del sistema operativo.
| Ejecutar cargas de trabajo | Gestionar cargas de trabajo | Gestionar clústeres de usuarios | Gestionar clústeres de administradores | |
|---|---|---|---|---|
| Interrupción | Posibles interrupciones y recuperación automática | Posibles interrupciones y recuperación automática | Interrupciones y recuperación automática o manual | Interrupción y recuperación manual |
| Explicación | Los pods que se ejecutan en las VMs de trabajador con errores se interrumpen y Kubernetes los vuelve a programar automáticamente en otras VMs en buen estado. Si las aplicaciones de usuario tienen capacidad de carga de trabajo de repuesto y se distribuyen en varios nodos, los clientes que implementen reintentos no podrán observar la interrupción. |
Si falla la VM del plano de control de un clúster de usuario que no es de alta disponibilidad o más de una VM del plano de control de un clúster de usuario de alta disponibilidad, se producirá una interrupción. | Si falla la VM de plano de control o las VMs de trabajador del clúster de administrador, se producirá una interrupción. | Si falla la VM de plano de control del clúster de administrador, se producirá una interrupción. |
| Recuperación | La VM que ha fallado se recupera automáticamente si la opción reparación automática de nodos está habilitada en el clúster de usuario. | La VM que ha fallado se recupera automáticamente si la reparación automática de nodos está habilitada en el clúster de administrador. | La VM de trabajador que ha fallado en el clúster de administrador se recupera automáticamente si la reparación automática de nodos está habilitada en el clúster de administrador. Para recuperar la máquina virtual de plano de control del clúster de administrador, consulta Reparar la máquina virtual de plano de control del clúster de administrador. |
Para recuperar la máquina virtual de plano de control del clúster de administrador, consulta Reparar la máquina virtual de plano de control del clúster de administrador. |
| Prevención | Implementa cargas de trabajo de alta disponibilidad para minimizar la posibilidad de que se produzcan interrupciones. | Usa clústeres de usuarios de alta disponibilidad para minimizar la posibilidad de que se produzcan interrupciones. | — | — |
Fallo de almacenamiento
En este caso, el contenido de un archivo VMDK podría dañarse debido a un apagado incorrecto de una máquina virtual, o bien un fallo en un almacén de datos podría provocar la pérdida de datos de etcd y de PersistentVolumes (PVs).
Error de etcd
| Ejecutar cargas de trabajo | Gestionar cargas de trabajo | Gestionar clústeres de usuarios | Gestionar clústeres de administradores | |
|---|---|---|---|---|
| Interrupción | Sin interrupciones | Posible interrupción y recuperación manual | Interrupción y recuperación manual | Interrupción y recuperación manual |
| Explicación | — | Si falla el almacén etcd de un clúster de usuario que no es de alta disponibilidad o más de una réplica de etcd en un clúster de usuario de alta disponibilidad, se producirá una interrupción. | Si falla el almacén etcd de un clúster de usuario que no es de alta disponibilidad o más de una réplica de etcd en un clúster de usuario de alta disponibilidad, se producirá una interrupción. Si falla la réplica de etcd de un clúster de administrador, se produce una interrupción. |
Si falla la réplica de etcd de un clúster de administrador, se produce una interrupción. |
| Prevención | — | Google Distributed Cloud proporciona un proceso manual para recuperarse de un fallo. | Google Distributed Cloud proporciona un proceso manual para recuperarse del fallo. | Google Distributed Cloud proporciona un proceso manual para recuperarse del fallo. |
Fallo de PV de la aplicación de usuario
| Ejecutar cargas de trabajo | Gestionar cargas de trabajo | Gestionar clústeres de usuarios | Gestionar clústeres de administradores | |
|---|---|---|---|---|
| Interrupción | Posible interrupción | Sin interrupciones | Sin interrupciones | Sin interrupciones |
| Explicación | Las cargas de trabajo que usan el PV fallido se ven afectadas. Implementa cargas de trabajo de alta disponibilidad para minimizar la posibilidad de que se produzcan interrupciones. |
— | — | — |
Fallo del balanceador de carga
En este caso, un fallo del balanceador de carga podría afectar a las cargas de trabajo de los usuarios que expongan servicios de tipo LoadBalancer.
| Ejecutar cargas de trabajo | Gestionar cargas de trabajo | Gestionar clústeres de usuarios | Gestionar clústeres de administradores | |
|---|---|---|---|---|
| Interrupción y recuperación manual | ||||
| Explicación |
Hay unos segundos de interrupción hasta que el balanceador de carga de reserva recupera la conexión VIP del plano de control de administrador. La interrupción del servicio puede durar hasta 2 segundos al usar Seesaw y hasta 300 segundos al usar F5. 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 equilibrador de carga. Si hay menos de 5 nodos, la interrupción se produce en un plazo de 10 segundos. |
|||
| Recuperación | Seesaw HA detecta automáticamente el fallo y cambia a la instancia de copia de seguridad. Google Distributed Cloud proporciona un proceso manual para recuperarse de un fallo de Seesaw. |
|||
Recuperar un clúster dañado
En las siguientes secciones se describe cómo recuperar un clúster dañado.
Recuperación tras fallos del host ESXi
Google Distributed Cloud se basa en vSphere HA para recuperarse de un fallo de host ESXi. vSphere HA puede monitorizar continuamente los hosts ESXi y reiniciar automáticamente las VMs en otros hosts cuando sea necesario. Este proceso es transparente para los usuarios de Google Distributed Cloud.
Recuperación tras fallos de máquinas virtuales
Los errores de las máquinas virtuales pueden ser los siguientes:
Eliminación inesperada de una VM.
Corrupción del disco de arranque de la VM, como un disco de arranque que pasa a ser de solo lectura debido a registros de diario de spam.
La VM no se inicia debido a problemas de configuración de la red o del disco de bajo rendimiento, como que la VM no se puede iniciar porque no se le puede asignar una dirección IP.
El sistema de archivos superpuesto de Docker está dañado.
Pérdida de la VM de plano de control del administrador debido a un error de actualización.
Problemas con el sistema operativo.
Google Distributed Cloud proporciona un mecanismo de recuperación automática para los nodos del complemento de administrador, los planos de control de usuario y los nodos de usuario. Esta función de reparación automática de nodos se puede habilitar en cada clúster de administrador y clúster de usuario.
La máquina virtual del plano de control del administrador es especial porque no la gestiona un clúster de Kubernetes y su disponibilidad no afecta a la continuidad del negocio. Para recuperar la máquina virtual de plano de control del administrador en caso de fallo, ponte en contacto con Cloud Customer Care.
Recuperación tras fallos de almacenamiento
Algunos de los fallos de almacenamiento se pueden mitigar con vSphere HA y vSAN sin que afecten a Google Distributed Cloud. Sin embargo, es posible que se produzcan errores de almacenamiento que se manifiesten a nivel de vSphere y provoquen daños o pérdidas de datos en varios componentes de Google Distributed Cloud.
La información con estado de un clúster y las cargas de trabajo de los usuarios se almacenan en los siguientes lugares:
- etcd: cada clúster (clúster de administrador y clúster de usuario) tiene una base de datos etcd que almacena el estado (objetos de Kubernetes) del clúster.
- PersistentVolumes se usan tanto en los componentes del sistema como en las cargas de trabajo de los usuarios.
Recuperación de datos de etcd dañados o perdidos
etcd es la base de datos que usa Kubernetes para almacenar todo el estado del clúster, incluidos los archivos de manifiesto de las aplicaciones de los usuarios. Las operaciones del ciclo de vida de la aplicación dejarían de funcionar si la base de datos etcd del clúster de usuario se dañara o se perdiera. Las operaciones del ciclo de vida del clúster de usuario dejarían de funcionar si la base de datos etcd del clúster de administrador se daña o se pierde.
etcd no proporciona un mecanismo integrado fiable para detectar la corrupción de datos. Debes consultar los registros de los pods de etcd si sospechas que los datos de etcd están dañados o se han perdido.
Un pod de etcd pendiente, con errores o en bucle de fallos no siempre significa que los datos de etcd estén dañados o perdidos. Esto podría deberse a errores en las máquinas virtuales que alojan los pods de etcd. Solo debes realizar la siguiente recuperación de etcd si los datos se han dañado o perdido.
Para poder recuperarse (a un estado reciente del clúster) de una corrupción o pérdida de datos de etcd, los datos de etcd deben copiarse después de cualquier operación del ciclo de vida del clúster (por ejemplo, crear, actualizar o mejorar). Para crear una copia de seguridad de los datos de etcd, consulta Crear una copia de seguridad de un clúster de administradores y Crear una copia de seguridad de un clúster de usuarios.
Al restaurar los datos de etcd, el clúster vuelve a un estado anterior. Si se crea una copia de seguridad antes de implementar una aplicación y, a continuación, se usa esa copia para restaurar el clúster, la aplicación que se haya implementado recientemente no se ejecutará en el clúster restaurado. Por ejemplo, si usas la instantánea de etcd de un clúster de administrador que se ha creado antes de crear un clúster de usuario, el clúster de administrador restaurado tendrá eliminado el plano de control del clúster de usuario. Por lo tanto, te recomendamos que hagas una copia de seguridad del clúster después de cada operación crítica del clúster.
La corrupción o la pérdida de datos de etcd pueden producirse en los siguientes casos:
Un solo nodo de un clúster de etcd de tres nodos (clúster de usuario de alta disponibilidad) se ha dañado permanentemente debido a la pérdida o al daño de datos. En este caso, solo se ha interrumpido un nodo y el quórum de etcd sigue existiendo. Este escenario puede darse en un clúster de alta disponibilidad, donde los datos de una de las réplicas de etcd estén dañados o se hayan perdido. El problema se puede solucionar sin perder datos sustituyendo la réplica de etcd que ha fallado por una nueva en estado limpio. Para obtener más información, consulta Reemplazar una réplica de etcd con fallos.
Dos nodos de un clúster de etcd de tres nodos (clúster de usuario de alta disponibilidad) se han dañado permanentemente debido a la pérdida o al daño de datos. Se ha perdido el quórum, por lo que sustituir las réplicas de etcd fallidas por otras nuevas no sirve de nada. El estado del clúster debe restaurarse a partir de los datos de la copia de seguridad. Para obtener más información, consulta Restaurar un clúster de usuarios a partir de una copia de seguridad (alta disponibilidad).
Un clúster de etcd de un solo nodo (clúster de administrador o clúster de usuario no de alta disponibilidad) se ha dañado de forma permanente debido a la pérdida o al daño de datos. Se pierde el quórum, por lo que debes crear un nuevo clúster a partir de la copia de seguridad. Para obtener más información, consulta Restaurar un clúster de usuarios a partir de una copia de seguridad (sin alta disponibilidad).
Recuperación de una corrupción o pérdida de PV de una aplicación de usuario
Puedes usar determinadas soluciones de almacenamiento de partners para crear copias de seguridad y restaurar los PersistentVolumes de aplicaciones de usuarios. Para ver la lista de partners de almacenamiento que se han calificado para Google Distributed Cloud, consulta Partners de almacenamiento aptos para GDC.
Recuperación tras fallos del balanceador de carga
En el caso de los balanceadores de carga de Seesaw agrupados, puedes recuperarte de los fallos recreando el balanceador de carga. Para volver a crear el balanceador de carga, actualiza Seesaw a la misma versión que se muestra en la documentación de la versión 1.16 Actualizar el balanceador de carga de tu clúster de administrador.
En el caso de que se produzcan errores en el balanceador de carga del clúster de administrador, es posible que no se pueda acceder al plano de control. Ejecuta la actualización en la máquina virtual de plano de control del administrador que tenga acceso al plano de control.
Si tienes un balanceador de carga integrado (F5), ponte en contacto con el equipo de Asistencia de F5.
En el caso del balanceador de carga MetalLB agrupado, se usan los nodos del clúster como balanceadores de carga. La reparación automática de nodos no se activa cuando hay problemas con el balanceador de carga. Puedes seguir el proceso manual para reparar el nodo.
Siguientes pasos
Si necesitas más ayuda, ponte en contacto con el servicio de atención al cliente de Cloud.
También puedes consultar la sección Obtener asistencia para obtener más información sobre los recursos de asistencia, incluidos los siguientes:
- Requisitos para abrir un caso de asistencia.
- Herramientas para ayudarte a solucionar problemas, como registros y métricas.
- Componentes, versiones y funciones compatibles de Google Distributed Cloud para VMware (solo software).