Haute disponibilité avec trois nœuds et comportement en cas de défaillance d'un nœud

À quoi cela sert

Avec trois nœuds, le plan de contrôle du cluster survit à la défaillance d'un nœud, et les volumes existent sous forme de copies sur plusieurs nœuds. Si un nœud tombe en panne, Kubernetes redémarre les services concernés sur un autre nœud, et le stockage y rattache une copie du volume.

Les services applicatifs et les services de données (MariaDB, Elasticsearch, RabbitMQ) s'exécutent chacun en une seule instance. Tant qu'un service n'est pas de nouveau prêt sur un autre nœud, il est interrompu. Comptez quelques minutes. Ce chapitre décrit comment planifier un cluster à trois nœuds et que faire après une défaillance.

Prérequis

Trois appliances EasyUC dans le même segment réseau, sans filtrage entre elles.
Une source de temps interne commune pour les trois nœuds.
Suffisamment d'espace de stockage par nœud pour les copies des volumes.
Des noms DNS pour les interfaces web et les cibles CUCM qui peuvent être déplacés vers un autre nœud. Il n'existe pas d'adresse IP virtuelle partagée.
Pour Teams : une adresse publique ou un NAT 1:1 vers le nœud sur lequel s'exécute le SBC, ainsi qu'un plan pour modifier cette correspondance.

Pas à pas : construire un cluster à trois nœuds

Mettez en service la première appliance et installez EasyUC.
Ajoutez le deuxième puis le troisième nœud l'un après l'autre avec Knoten hinzufügen. Attendez à chaque fois que le nœud soit « Bereit ».
Sur chaque nœud, définissez la même source de temps sur la console sous NTP Server, un nœud après l'autre.
Sur la carte Speicher, vérifiez qu'elle indique « alle gesund ».
Saisissez les adresses dans le DNS, dans CUCM et dans le pare-feu de manière à pouvoir les déplacer vers un autre nœud.
Configurez le transfert des sauvegardes vers un serveur externe. Un cluster ne remplace pas une sauvegarde.

Pas à pas : après la défaillance d'un nœud

Ouvrez le Manager via l'adresse d'un nœud en fonctionnement. Si nécessaire, le Manager redémarre sur un autre nœud.
Sur la carte Knoten, vérifiez quel nœud est « Nicht bereit ».
Sur la carte EasyUC, vérifiez si tous les composants sont de nouveau prêts.
Modifiez les enregistrements DNS, les cibles dans CUCM et, pour Teams, la correspondance NAT s'ils pointent vers le nœud défaillant.
Corrigez la cause et redémarrez le nœud. À son retour, le stockage resynchronise les copies.
Si le nœud est définitivement perdu, supprimez-le avec Knoten entfernen et ajoutez une nouvelle appliance.

Champs et options

Champs et options
Champ / action	Signification et utilisation
1 nœud	Aucune redondance dans le cluster. La protection provient de la virtualisation (haute disponibilité de l'hyperviseur, snapshots) et des sauvegardes.
2 nœuds	Ne tolère pas la défaillance du plan de contrôle : etcd a besoin d'une majorité des nœuds.
3 nœuds	Le plan de contrôle tolère la défaillance d'un nœud. C'est la taille recommandée pour la redondance.
Plan de contrôle	Chaque nœud est un serveur K3s avec etcd. Des nœuds de travail purs ne sont pas proposés.
Stockage	Longhorn conserve des copies des volumes sur plusieurs nœuds. Si un nœud manque, la carte Speicher affiche les volumes concernés comme « eingeschränkt ».
Services applicatifs et de données	Une instance chacun. Redémarrage sur un autre nœud après une défaillance, avec interruption.
Mises à jour	Une mise à jour d'EasyUC redémarre tous les services ensemble. L'application est indisponible pendant plusieurs minutes, y compris dans un cluster.
Non disponible	Réplication de la base de données, plusieurs instances par service, basculement sans interruption et mises à jour sans interruption.

Vérifier le résultat et résoudre les problèmes

La carte Knoten affiche trois nœuds avec « Bereit », et la carte Speicher indique « alle gesund ».
Si un composant reste non prêt après une défaillance, la carte EasyUC affiche le motif sur le composant. Le bouton Reconcile cluster déclenche une nouvelle réconciliation.
Si les utilisateurs n'atteignent pas l'interface après une défaillance, le nom DNS pointe généralement encore vers le nœud défaillant.
Si aucun appel Teams n'arrive après une défaillance, la correspondance NAT pointe encore vers l'ancien nœud. Le SBC s'exécute sur le nœud où s'exécute le service média ACD.
Dans le menu de la console, la source de temps ne peut être activée qu'avec un nœud ou exactement trois nœuds. Le paquet hors ligne signé de la page System-Updates requiert exactement trois nœuds.
Les appels actifs via le service média ACD ou le SBC Teams du nœud défaillant ne peuvent pas être sauvegardés.