Google Distributed Cloud está diseñado para limitar el alcance de las fallas y priorizar las funciones que son fundamentales para la continuidad del negocio. En este documento, se explica cómo se ve afectada la funcionalidad de tus clústeres cuando hay una falla. Esta información puede ayudarte a priorizar áreas para solucionar problemas si tienes problemas.
Si necesitas asistencia adicional, comunícate con Atención al cliente de Cloud.La funcionalidad principal de Google Distributed Cloud incluye las siguientes categorías:
- Ejecuta cargas de trabajo: Las cargas de trabajo existentes pueden seguir ejecutándose. Esta es la consideración más importante para mantener la continuidad del negocio. Incluso si el clúster tiene un problema, las cargas de trabajo existentes pueden seguir ejecutándose sin interrupción.
- Administrar cargas de trabajo: Puedes crear, actualizar y borrar cargas de trabajo. Esta es la segunda consideración más importante para escalar las cargas de trabajo cuando el tráfico aumenta, incluso si el clúster tiene un problema.
- Administrar clústeres de usuario: Puedes administrar nodos, actualizar, actualizar y borrar clústeres de usuario. Esto es menos importante que las consideraciones del ciclo de vida de la app. Si hay capacidad disponible en los nodos existentes, la incapacidad de modificar los clústeres de usuario no afecta las cargas de trabajo del usuario.
- Administrar clústeres de administrador: Puedes actualizar el clúster de administrador. Esta es la consideración menos importante, ya que el clúster de administrador no aloja ninguna carga de trabajo del usuario. Si el clúster de administrador tiene un problema, las cargas de trabajo de la aplicación seguirán ejecutándose sin interrupciones.
En las siguientes secciones, se usan estas categorías de funcionalidad principal para describir el impacto de tipos específicos de situaciones de falla.
Modos de falla
Los siguientes tipos de fallas pueden afectar el rendimiento de los clústeres de Google Distributed Cloud.
Falla del host de ESXi
En esta situación de falla, un host ESXi que ejecuta instancias de máquina virtual (VM) que alojan nodos de Kubernetes podría dejar de funcionar o quedar particionado en la red.
| Ejecuta cargas de trabajo | Administrar cargas de trabajo | Administra clústeres de usuarios | Administrar clústeres de administrador | |
|---|---|---|---|---|
| Interrupción | Posibles interrupciones y recuperación automática | Posibles interrupciones y recuperación automática | Interrupción y recuperación automática | Interrupción y recuperación automática |
| Explicación | Los Pods que se ejecutan en las VM alojadas por el host con errores se interrumpen y se reprograman de forma automática en otras VM en buen estado. Si las aplicaciones de usuario tienen capacidad de carga de trabajo libre y se distribuyen entre varios nodos, la interrupción no se puede observar para los clientes que implementan reintentos. |
Si la falla del host afecta la VM del plano de control en un clúster de usuario sin alta disponibilidad o más de una VM de plano de control en un clúster de usuario con alta disponibilidad, habrá interrupción. | Si la falla del host afecta la VM del plano de control o las VM de trabajador en el clúster de administrador, habrá interrupción. | Si la falla del host afecta la VM del plano de control en el clúster de administrador, habrá interrupción. |
| Recuperación | La alta disponibilidad de vSphere reinicia de forma automática las VM en hosts en buen estado. | La alta disponibilidad de vSphere reinicia de forma automática las VM en hosts en buen estado. | La alta disponibilidad de vSphere reinicia de forma automática las VM en hosts en buen estado. | La alta disponibilidad de vSphere reinicia de forma automática las VM en hosts en buen estado. |
| Prevención | Implementa cargas de trabajo de alta disponibilidad para minimizar las posibilidades de interrupción. | Usa clústeres de usuario de alta disponibilidad para minimizar la posibilidad de interrupción. | — | — |
Falla de VM
En esta situación de falla, es posible que una VM se borre de forma inesperada, que un disco de arranque se dañe o que una VM se vea comprometida debido a problemas del sistema operativo.
| Ejecuta cargas de trabajo | Administrar cargas de trabajo | Administra clústeres de usuarios | Administrar clústeres de administrador | |
|---|---|---|---|---|
| Interrupción | Posibles interrupciones y recuperación automática | Posibles interrupciones y recuperación automática | Interrupción y recuperación automática o manual | Interrupción y recuperación manual |
| Explicación | Los Pods que se ejecutan en las VM de trabajador con errores se interrumpen y Kubernetes los reprograma de forma automática en otras VM en buen estado. Si las aplicaciones de usuario tienen capacidad de carga de trabajo libre y se distribuyen entre varios nodos, la interrupción no se puede observar para los clientes que implementan reintentos. |
Si la VM del plano de control en un clúster de usuario sin alta disponibilidad o más de una VM de plano de control en un clúster de usuario con alta disponibilidad fallan, habrá interrupción. | Si la VM del plano de control o las VM de trabajador en el clúster de administrador fallan, habrá interrupción. | Si la VM del plano de control en el clúster de administrador falla, habrá interrupción. |
| Recuperación | La VM con errores se recupera automáticamente si se habilita la reparación automática del nodo en el clúster de usuarios. | La VM con errores se recupera automáticamente si la reparación automática de nodos está habilitada en el clúster del administrador. | La VM de trabajador con errores en el clúster de administrador se recupera de forma automática si la reparación automática de nodos está habilitada en el clúster de administrador. Para recuperar la VM del plano de control del clúster de administrador, consulta Repara la VM del plano de control del clúster de administrador. |
Para recuperar la VM del plano de control del clúster de administrador, consulta Repara la VM del plano de control del clúster de administrador. |
| Prevención | Implementa cargas de trabajo de alta disponibilidad para minimizar las posibilidades de interrupción. | Usa clústeres de usuario de alta disponibilidad para minimizar la posibilidad de interrupción. | — | — |
Falla de almacenamiento
En esta situación de falla, el contenido de un archivo VMDK puede dañarse debido a un apagado desordenado de una VM, o una falla del almacén de datos puede hacer que se pierdan los datos de etcd y los PersistentVolumes (PV).
Falla de etcd
| Ejecuta cargas de trabajo | Administrar cargas de trabajo | Administra clústeres de usuarios | Administrar clústeres de administrador | |
|---|---|---|---|---|
| Interrupción | Sin interrupciones | Posibles interrupciones y recuperación manual | Interrupción y recuperación manual | Interrupción y recuperación manual |
| Explicación | — | Si el almacenamiento de etcd en un clúster de usuario sin alta disponibilidad o más de una réplica de etcd en un clúster de usuario con alta disponibilidad falla, habrá interrupción. | Si el almacenamiento de etcd en un clúster de usuario sin alta disponibilidad o más de una réplica de etcd en un clúster de usuario con alta disponibilidad falla, habrá interrupción. Si la réplica de etcd en un clúster de administrador falla, habrá interrupción. |
Si la réplica de etcd en un clúster de administrador falla, habrá interrupción. |
| Prevención | — | Google Distributed Cloud proporciona un proceso manual para recuperarse de la falla. | Google Distributed Cloud proporciona un proceso manual para recuperarse de la falla. | Google Distributed Cloud proporciona un proceso manual para recuperarse de la falla. |
Falla de PV de la aplicación del usuario
| Ejecuta cargas de trabajo | Administrar cargas de trabajo | Administra clústeres de usuarios | Administrar clústeres de administrador | |
|---|---|---|---|---|
| Interrupción | Posible interrupción | Sin interrupciones | Sin interrupciones | Sin interrupciones |
| Explicación | Las cargas de trabajo que usan el PV con errores se ven afectadas. Implementa cargas de trabajo de alta disponibilidad para minimizar las posibilidades de interrupción. |
— | — | — |
Falla del balanceador de cargas
En esta situación de falla, una falla del balanceador de cargas puede afectar las cargas de trabajo del usuario que exponen Services de tipo LoadBalancer.
| Ejecuta cargas de trabajo | Administrar cargas de trabajo | Administra clústeres de usuarios | Administrar clústeres de administrador | |
|---|---|---|---|---|
| Interrupción y recuperación manual | ||||
| Explicación |
Habrá algunos segundos de interrupción hasta que el balanceador de cargas en espera recupere la conexión VIP del plano de control del administrador. La interrupción del servicio puede ser de hasta 2 segundos cuando se usa Seesaw y hasta 300 segundos cuando se usa F5. La duración de la interrupción de la conmutación por error de MetalLB aumenta a medida que aumenta la cantidad de nodos del balanceador de cargas. Con menos de 5 nodos, la interrupción ocurre en un plazo de 10 segundos. |
|||
| Recuperación | La alta disponibilidad de Seesaw detecta de forma automática la falla y conmuta por error al uso de la instancia de copia de seguridad. Google Distributed Cloud proporciona un proceso manual para la recuperación de una falla de Seesaw. |
|||
Recupera un clúster dañado
En las siguientes secciones, se describe cómo recuperar un clúster dañado.
Recuperación ante fallas del host de ESXi
Google Distributed Cloud se basa en vSphere HA para proporcionar la recuperación ante una falla de host de ESXi. vSphere HA puede supervisar de manera continua los hosts ESXi y reiniciar automáticamente las VM en otros hosts cuando sea necesario. Esto es transparente para los usuarios de Google Distributed Cloud.
Recuperación ante fallas de VM
Las fallas de VM pueden incluir lo siguiente:
Eliminación inesperada de una VM
La corrupción del disco de arranque de la VM, como un disco de arranque que pasa a ser de solo lectura debido a los registros de diario de spam
Falla de inicio de la VM debido a problemas de configuración de red o disco de bajo rendimiento, como que la VM no se puede iniciar porque no se le puede asignar una dirección IP.
Se dañó el sistema de archivos de superposición de Docker.
Pérdida de la VM del plano de control del administrador debido a una falla de actualización.
Problemas del sistema operativo
Google Distributed Cloud proporciona un mecanismo de recuperación automática para los nodos del complemento de administrador, los planos de control del usuario y los nodos de usuario. Esta función de reparación automática de nodos se puede habilitar por clúster de administrador y clúster de usuario.
La VM del plano de control del administrador es especial en el sentido de que no la administra un clúster de Kubernetes, y su disponibilidad no afecta la continuidad del negocio. Para recuperar las fallas de las VM del plano de control del administrador, comunícate con Atención al cliente de Cloud.
Recuperación ante fallas de almacenamiento
Algunas de las fallas de almacenamiento se pueden mitigar con vSphere HA y vSAN sin afectar a Google Distributed Cloud. Sin embargo, algunas fallas de almacenamiento pueden surgir del nivel de vSphere, lo que causa daños o pérdida de datos en varios componentes de Google Distributed Cloud.
La información con estado de un clúster y las cargas de trabajo de usuario se almacenan en los siguientes lugares:
- etcd: Cada clúster (clúster de administrador y de usuario) tiene una base de datos de etcd que almacena el estado (objetos de Kubernetes) del clúster.
- PersistentVolumes: Los usan los componentes del sistema y las cargas de trabajo del usuario.
Recuperación ante daños o pérdidas de datos de etcd
Kubernetes usa la base de datos de etcd para almacenar todo el estado del clúster, incluidos los manifiestos de las aplicaciones del usuario. Las operaciones del ciclo de vida de la aplicación dejarían de funcionar si la base de datos de etcd del clúster de usuario está dañada o se pierde. Las operaciones del ciclo de vida del clúster de usuario dejarán de funcionar si la base de datos de etcd del clúster de administrador está dañada o se pierde.
etcd no proporciona un mecanismo integrado y confiable para detectar la corrupción de datos. Debes buscar los registros de los Pods de etcd si sospechas que los datos de etcd están dañados o se pierden.
Un Pod de etcd pendiente, con errores y con una falla de repetición no siempre implica que los datos de etcd estén dañados o se pierden. Esto podría deberse a la existencia de errores en las VM que alojan los Pods de etcd. Debes realizar la siguiente recuperación de etcd solo para el daño o la pérdida de datos.
Para poder recuperar (el estado reciente del clúster) de la corrupción o pérdida de datos similares, se debe crear una copia de seguridad de los datos de etcd después de cualquier operación de ciclo de vida del clúster (por ejemplo, crear, actualizar o mejorar). Para crear una copia de seguridad de los datos de etcd, consulta Crea una copia de seguridad de un clúster de administrador y Crea una copia de seguridad de un clúster de usuario.
Restablecer los datos de etcd hace que el clúster tenga un estado anterior. Si se realiza una copia de seguridad antes de implementar una aplicación y, luego, esa copia se usa para restablecer el clúster, la aplicación recién implementada no se ejecutará en el clúster restablecido. Por ejemplo, si usas la instantánea etcd de un clúster de administrador que se crea una instantánea antes de crear un clúster de usuario, entonces se quita el plano de control del clúster del usuario restablecido en el clúster de administrador restablecido. Por lo tanto, te recomendamos crear una copia de seguridad del clúster después de cada operación de clúster crítica.
La corrupción o la falla de pérdida de los datos de etcd pueden ocurrir en las siguientes situaciones:
Un nodo único de un clúster de etcd de tres nodos (clúster de usuario de alta disponibilidad) se bloquea de forma permanente debido al daño o pérdida de datos. En este caso, solo un nodo se dañó y el quórum de etcd aún existe. Esta situación puede ocurrir en un clúster de alta disponibilidad, en el que los datos de una de las réplicas de etcd se dañan o pierden. El problema se puede solucionar sin perder datos si se reemplaza la réplica de etcd con errores por una nueva en estado limpio. Para obtener más información, consulta Reemplaza una réplica de etcd con errores.
Dos nodos de un clúster de etcd de tres nodos (clúster de usuario de alta disponibilidad) se rompen de forma permanente debido al daño o pérdida de datos. Se pierde el quórum, por lo que reemplazar las réplicas de etcd con errores por otras nuevas no ayuda. El estado del clúster debe restablecerse a partir de los datos de la copia de seguridad. Para obtener más información, consulta Restablece un clúster de usuario desde una copia de seguridad (HA).
Un clúster de etcd de un solo nodo (clúster del administrador o clúster de usuario sin alta disponibilidad) se rompe de forma permanente debido al daño o pérdida de datos. El quórum se pierde, por lo que debes crear un clúster nuevo a partir de la copia de seguridad. Para obtener más información, consulta Restablece un clúster de usuario desde una copia de seguridad (sin alta disponibilidad).
Recuperación ante daños o pérdidas de PV de la aplicación del usuario
Puedes usar ciertas soluciones de almacenamiento de socios para crear una copia de seguridad y restablecer de los PersistentVolumes de aplicaciones de usuario. Si quieres conocer la lista de socios de almacenamiento calificados para Google Distributed Cloud, consulta Socios de almacenamiento de Anthos Ready.
Recuperación ante fallas del balanceador de cargas
En el caso del balanceador de cargas de Seesaw en paquetes, puedes recuperarte de las fallas recreando el balanceador de cargas. Para volver a crear el balanceador de cargas, actualiza Seesaw a la misma versión que se muestra en Actualiza el balanceador de cargas del clúster de administrador.
En el caso de fallas del balanceador de cargas del clúster de administrador, es posible que el plano de control esté fuera del alcance. Ejecuta la actualización en la VM del plano de control del administrador en la que hay acceso al plano de control.
Para obtener información sobre los balanceadores de cargas integrados (F5), comunícate con el equipo de asistencia de F5.
Para el balanceador de cargas de MetalLB en paquetes, usa nodos del clúster como balanceadores de cargas. La reparación automática de nodos no se activa debido a problemas del balanceador de cargas. Puedes seguir el proceso manual para reparar el nodo.