Redundancia y comportamiento ante fallos

Información general

En EasyUC la redundancia existe en dos niveles. Con tres nodos, el plano de control de Kubernetes y etcd sobreviven a la pérdida de un nodo. Longhorn mantiene copias de los volúmenes en varios nodos.

La aplicación y los servicios de datos, en cambio, se ejecutan cada uno como instancia única. Si falla un nodo, Kubernetes reinicia los servicios afectados en otro nodo. Se trata de una recuperación basada en reinicio, no de una conmutación por error sin interrupción.

Plano de control y quórum de etcd

etcd almacena el estado del clúster de Kubernetes. Cada nodo de EasyUC es un nodo servidor y, por tanto, un miembro de etcd. El plano de control sigue operativo mientras esté disponible la mayoría de estos miembros.

Con tres nodos, esa mayoría es dos. Si falla un nodo, los otros dos siguen funcionando. Dos nodos no ofrecen tolerancia a fallos, porque tras un fallo se pierde la mayoría. La tabla está en Por qué tres nodos.

Réplicas de Longhorn

Longhorn mantiene copias de los volúmenes en varios nodos. Si falla un nodo, existe una réplica en otro nodo y Longhorn puede conectarla allí. Mientras falta un nodo, Longhorn muestra los volúmenes afectados como degraded.

En un único nodo, los volúmenes no son redundantes. El Manager muestra el estado de todos los volúmenes.

Qué ocurre cuando falla un nodo

Kubernetes y Longhorn recuperan los servicios sin intervención manual. Esto lleva tiempo y, hasta entonces, los servicios afectados no están disponibles.

1. 1

   Falla un nodo

   Los servicios de este nodo dejan de estar accesibles.

2. 2

   Kubernetes detecta el fallo

   El nodo se marca como no disponible. Normalmente tarda unos minutos.

3. 3

   Reinicio en otro nodo

   Kubernetes inicia los componentes afectados en uno de los nodos restantes.

4. 4

   Se conecta el volumen

   Longhorn conecta allí la réplica del volumen.

5. 5

   Servicio disponible de nuevo

   Los componentes vuelven a ejecutarse. Si los usuarios, CUCM o el NAT para Microsoft apuntan a la dirección del nodo que ha fallado, cámbielos; consulte Planificar las direcciones.

Cada servicio como instancia única

Hoy cada servicio se ejecuta como instancia única. Esto se aplica tanto a los componentes de EasyUC como a MariaDB, Elasticsearch, RabbitMQ, el Manager, acd-media y teams-sbc. Si falla un nodo, Kubernetes reinicia los servicios afectados en otro nodo. Esto tarda unos minutos; las llamadas activas en ese nodo finalizan.

Hoy no existe lo siguiente:

• replicación de la base de datos, por ejemplo con Galera
• varias instancias por servicio
• conmutación automática por error sin interrupción
• actualizaciones graduales (rolling updates). Durante una actualización, todos los servicios se reinician a la vez; consulte Actualizaciones.
• alertas por correo electrónico, SNMP o Prometheus

Planificar las direcciones: sin IP virtual compartida

EasyUC no proporciona una dirección IP virtual compartida. Los usuarios, CUCM y el NAT para Microsoft apuntan a la dirección de un nodo. Para poder cambiar tras un fallo, planifique lo siguiente:

• Nombres DNS en lugar de direcciones IP fijas para usuarios, agentes y CUCM.
• Para Teams, un NAT 1:1 que pueda trasladar tras un fallo al nodo donde se ejecuta teams-sbc.
• Un certificado web que contenga todos los nombres con los que EasyUC deba estar accesible; consulte Certificados.
• Hacia CUCM, jtapi y acd-media se conectan al host de CUCM configurado en los ajustes de AXL.

Instalaciones de un único nodo

Un único nodo no tiene redundancia dentro del clúster. La protección procede de la virtualización: alta disponibilidad del hipervisor, instantáneas de VM y copias de seguridad. Lo que cubren la copia de seguridad de la base de datos y la copia completa se describe en Copia de seguridad y restauración.

Supervisión

Está disponible la siguiente información:

• Estado y uso de los nodos en el Manager
• Estado de los volúmenes de Longhorn en el Manager
• Estado de los componentes, en directo en el Manager
• Historial de copias de seguridad en el Manager
• Estado de la puerta de enlace del SBC de Teams, notificado a la interfaz de administración cada 20 segundos