Redondance et comportement en cas de panne

Vue d'ensemble

La redondance dans EasyUC existe à deux niveaux. Avec trois nœuds, le plan de contrôle Kubernetes et etcd survivent à la perte d'un nœud. Longhorn conserve des copies des volumes sur plusieurs nœuds.

L'application et les services de données, en revanche, fonctionnent chacun en instance unique. Si un nœud tombe en panne, Kubernetes redémarre les services concernés sur un autre nœud. Il s'agit d'une reprise par redémarrage, et non d'un basculement sans interruption.

Plan de contrôle et quorum etcd

etcd stocke l'état du cluster Kubernetes. Chaque nœud EasyUC est un nœud serveur et donc un membre etcd. Le plan de contrôle reste opérationnel tant qu'une majorité de ces membres est disponible.

Avec trois nœuds, cette majorité est de deux. Si un nœud tombe en panne, les deux autres continuent de fonctionner. Deux nœuds n'apportent aucune tolérance aux pannes, car la majorité est perdue dès la première panne. Le tableau figure dans Pourquoi trois nœuds.

Réplicas Longhorn

Longhorn conserve des copies des volumes sur plusieurs nœuds. Si un nœud tombe en panne, un réplica existe sur un autre nœud et Longhorn peut l'y attacher. Tant qu'un nœud manque, Longhorn affiche les volumes concernés comme degraded.

Sur un nœud unique, les volumes ne sont pas redondants. Le Manager affiche l'état de tous les volumes.

Comportement en cas de panne d'un nœud

Kubernetes et Longhorn rétablissent les services sans intervention manuelle. Cela prend du temps, et les services concernés restent indisponibles jusque-là.

1. 1

   Un nœud tombe en panne

   Les services de ce nœud ne sont plus joignables.

2. 2

   Kubernetes détecte la panne

   Le nœud est marqué comme indisponible. Cela prend généralement quelques minutes.

3. 3

   Redémarrage sur un autre nœud

   Kubernetes démarre les composants concernés sur un nœud restant.

4. 4

   Attachement du volume

   Longhorn y attache le réplica du volume.

5. 5

   Service de nouveau disponible

   Les composants fonctionnent à nouveau. Si les utilisateurs, CUCM ou la NAT pour Microsoft pointent vers l'adresse du nœud en panne, basculez-les. Consultez Planifier les adresses.

Chaque service en instance unique

Chaque service fonctionne aujourd'hui en instance unique. Cela concerne les composants EasyUC ainsi que MariaDB, Elasticsearch, RabbitMQ, le Manager, acd-media et teams-sbc. Si un nœud tombe en panne, Kubernetes redémarre les services concernés sur un autre nœud. Cela prend quelques minutes, et les appels actifs sur ce nœud sont terminés.

Les éléments suivants n'existent pas aujourd'hui :

• réplication de la base de données, par exemple avec Galera
• plusieurs instances par service
• basculement automatique sans interruption
• mises à jour progressives (rolling updates). Pendant une mise à jour, tous les services redémarrent ensemble. Consultez Mises à jour.
• alertes par e-mail, SNMP ou Prometheus

Planifier les adresses : pas d'IP virtuelle partagée

EasyUC ne fournit pas d'adresse IP virtuelle partagée. Les utilisateurs, CUCM et la NAT pour Microsoft pointent vers l'adresse d'un nœud. Pour pouvoir basculer après une panne, prévoyez les éléments suivants :

• Des noms DNS plutôt que des adresses IP fixes pour les utilisateurs, les agents et CUCM.
• Pour Teams, une NAT 1:1 que vous pouvez déplacer après une panne vers le nœud où s'exécute teams-sbc.
• Un certificat web contenant tous les noms sous lesquels EasyUC doit être joignable. Consultez Certificats.
• Vers CUCM, jtapi et acd-media se connectent à l'hôte CUCM configuré dans les paramètres AXL.

Installations à nœud unique

Un nœud unique n'offre aucune redondance au sein du cluster. La protection repose sur la virtualisation : haute disponibilité de l'hyperviseur, instantanés de VM et sauvegardes. Le périmètre de la sauvegarde de la base de données et de la sauvegarde complète est décrit dans Sauvegarde et restauration.

Supervision

Les informations suivantes sont disponibles :

• État et utilisation des nœuds dans le Manager
• État des volumes Longhorn dans le Manager
• État des composants, en direct dans le Manager
• Historique des sauvegardes dans le Manager
• État de la passerelle du SBC Teams, transmis à l'interface d'administration toutes les 20 secondes