Kubernetes K3S : le cluster de haute disponibilité le plus simple entre deux serveurs redondants
Avec la réplication temps réel et le basculement automatique fournis par Evidian SafeKit
La solution pour Kubernetes K3S
Evidian SafeKit apporte la haute disponibilité à Kubernetes entre deux serveurs redondants. Cet article explique comment implémenter rapidement un cluster Kubernetes K3S sur 2 nœuds sans stockage externe NFS, sans base de données de configuration externe et sans compétences spécifiques.
Notez que SafeKit est un produit générique. Vous pouvez implémenter avec le même produit la réplication en temps réel et le basculement de répertoires et de services, de bases de données, d'applications Docker, Podman, de machines virtuelles Hyper-V ou KVM complètes, d'applications dans le Cloud (voir la liste des modules).
Cette solution de clustering est reconnue comme la plus simple à mettre en œuvre par nos clients et partenaires. La solution SafeKit est la solution parfaite pour exécuter des applications Kubernetes K3S sur site et sur 2 nœuds.
Nous avons choisi K3S comme moteur Kubernetes car il s'agit d'une solution légère pour l'IoT et le Edge computing.
Le module miroir k3s.safe implémente :
- 2 maîtres/agents K3S actifs exécutant des pods
- la réplication de la base de données de configuration de K3S (MariaDB)
- la réplication des volumes persistants (implémentée par la classe "NFS client dynamic provisionner storage class: nfs-client")
- l'adresse IP virtuelle, le basculement automatique, la restauration automatique après panne
Comment ça marche ?
Le tableau suivant explique comment la solution fonctionne sur 2 nœuds. D'autres nœuds avec des agent K3S (sans SafeKit) peuvent être ajoutés pour une scalabilité horizontale.
Composants Kubernetes K3S | |
Noeud SafeKit PRIM | Noeud SafeKit SECOND |
K3S (master et agent) exécute des pods sur le nœud primaire | K3S (master et agent) exécute des pods sur le nœud secondaire |
Le serveur NFS s'exécute sur le nœud primaire avec :
|
Les volumes persistants sont répliqués de manière synchrone et en temps réel par SafeKit sur le nœud secondaire |
Le serveur MariaDB s'exécute sur le nœud primaire avec :
|
La base de configuration est répliquée de manière synchrone et en temps réel par SafeKit sur le nœud secondaire |
Une solution simple
SafeKit est la solution de haute disponibilité la plus simple pour exécuter des applications Kubernetes sur 2 nœuds et sur site.
SafeKit | Avantages |
Réplication synchrone en temps réel pour les volumes persistants | Pas de stockage NAS/NFS externe pour les volumes persistants |
Seulement 2 nœuds pour la haute disponibilité de Kubernetes K3S | Pas besoin de 3 nœuds comme avec la base de données etcd |
Même produit simple pour l'adresse IP virtuelle, la réplication, le basculement, la restauration après panne, l'administration, la maintenance | Évitez les différentes technologies pour l'IP virtuelle (metal-lb, BGP), la haute disponibilité des volumes persistants, la haute disponibilité de la base de données de configuration |
Prend en charge la reprise après sinistre avec deux nœuds distants | Éviter le stockage NAS répliqué |
Partenaires, le succès avec SafeKit
Cette solution indépendante de la plateforme est idéale pour un partenaire revendant une application critique et qui souhaite proposer une option de redondance et de haute disponibilité simple à déployer auprès de nombreux clients.
Avec de nombreuses références dans de nombreux pays gagnées par des partenaires, SafeKit s'est avéré être la solution la plus simple à mettre en œuvre pour la redondance et la haute disponibilité des logiciels de gestion des bâtiments, vidéosurveillance, contrôle d'accès, systèmes SCADA...
Logiciel de gestion des bâtiments (BMS)
Logiciel de gestion vidéo (VMS)
Contrôle d'accès électroniques (EACS)
Logiciels SCADA (Industrie)
Etape 1. Réplication de données temps réel et continue
Cette étape correspond à la figure suivante. Le serveur 1 (PRIM) exécute les composants Kubernetes K3S décrits dans le tableau précédent. Les utilisateurs sont connectés à l'adresse IP virtuelle du cluster miroir. SafeKit réplique les fichiers ouverts par les composants Kubernetes K3S. Seules les modifications faites par les composants à l'intérieur des fichiers sont répliquées en continue à travers le réseau, limitant ainsi le trafic.
Avec la réplication de données temps réel de SafeKit, seuls les noms des répertoires de fichiers sont à configurer dans le module miroir. Les répertoires à répliquer peuvent être localisés dans le disque système. SafeKit implémente une réplication synchrone sans perte de données en cas de panne contrairement à une réplication asynchrone.
Etape 2. Basculement automatique
Lorsque le serveur 1 est défaillant, SafeKit bascule l'adresse IP virtuelle du cluster sur le serveur 2 et redémarre automatiquement les composants Kubernetes K3S. Les composants retrouvent les fichiers répliqués à jour grâce à la réplication continue synchrone réalisée par SafeKit entre le serveur 1 et le serveur 2. Les composants Kubernetes K3S poursuivent leur exécution sur le serveur 2 en modifiant localement leurs fichiers qui ne sont plus répliqués vers le serveur 1.
Le temps de basculement est égal au temps de détection de la panne (time-out configuré à 30 secondes par défaut) et au temps de relance des composants. Sur la machine secondaire, il n'y a pas de temps lié au remontage du système de fichiers ou au passage des procédures de recovery du système de fichiers, comme avec les solutions de réplication de disques.
Etape 3. Réintégration après panne
A la reprise après panne du serveur 1 (réintégration du serveur 1), SafeKit resynchronise automatiquement les fichiers de ce serveur à partir de l'autre serveur. Seuls les fichiers modifiés sur le serveur 2 pendant l'inactivité du serveur 1 sont resynchronisés. La réintégration du serveur 1 se fait sans arrêter l'exécution des composants Kubernetes K3S sur le serveur 2.
Si SafeKit a été proprement arrêté sur le serveur 1, alors à son redémarrage, seules les zones modifiées à l'intérieur des fichiers sont resynchronisées suivant des bitmaps de modification.
Si le serveur 1 a crashé (power off), les bitmaps de modification ne sont pas sûres et elles ne sont donc pas utilisées. Tous les fichiers qui ont été modifiés depuis le moment de l'arrêt sont resynchronisés.
Etape 4. Retour à la normale avec réplication de données temps réel
Après la réintégration, les fichiers sont à nouveau en mode miroir comme à l'étape 1. Le système est en haute disponibilité avec les composants Kubernetes K3S qui s'exécutent sur le serveur 2 et avec comme secours le serveur 1. Les modifications des composants dans les fichiers sont répliquées en temps réel du serveur 2 vers le serveur 1.
Si l'administrateur souhaite que les composants Kubernetes K3S s'exécutent en priorité sur le serveur 1, il peut exécuter une commande de basculement, soit manuellement à un moment opportun, soit automatiquement par configuration.
Étape 1. Téléchargez les packages
- Téléchargez la version gratuite de SafeKit (safekit_xx.bin)
- Télécharger le module Linux
- Télécharger le script k3sconfig.sh
- Documentation (pptx)
Remarque : le script k3sconfig.sh installe K3S, MariaDB, NFS, SafeKit sur 2 nœuds Linux Ubuntu 20.04.
Étape 2. D'abord sur les deux nœuds
Sur 2 nœuds Linux Ubuntu 20.04, en tant que root :
- Assurez-vous que le nœud a accès à Internet (peut-être via un proxy)
- Copiez k3sconfig.sh, k3s.safe et le package safekit_xx.bin dans un répertoire et placez-vous dedans (cd)
- Renommer le fichier .bin en "safekit.bin"
- Assurez-vous que k3sconfig.sh et safekit.bin sont exécutables.
- Modifiez le script k3sconfig.sh et personnalisez les variables d'environnement en fonction de votre environnement
- Exécuter sur les deux nœuds : ./k3sconfig.sh prereq
Le script va :
- Installer les packages Debian requis : alien, nfs-kernel-server, nfs-common, mariadb-server
- Sécuriser MariaDB
- Créer des répertoires pour la réplication de fichiers
- Préparer le serveur NFS pour le partage des répertoires répliqués
- Installer SafeKit
Étape 3. Sur le premier nœud
Exécutez sur le premier nœud : ./k3sconfig.sh first
Le script va :
- Créer la base de données de configuration K3S et l'utilisateur k3s
- Créer le fichier de stockage des volumes persistants (fichier fragmenté) et le formater en tant que système de fichiers xfs
- Créer la configuration du cluster safekit et l'appliquer
- Installer et configurer le module k3s.safe sur le cluster
- Démarrer le module k3s en tant que "prim" sur le premier nœud
- Télécharger, installer et démarrer k3s
- Télécharger et installer la charte Helm nfs-subdir-external-provisioner
- Afficher le jeton K3S (à utiliser lors de la phase d'installation du deuxième nœud)
Étape 4. Sur le deuxième nœud
Exécutez sur le deuxième nœud : ./k3sconfig.sh second <token>
- <token> est la chaîne affichée à la fin de l'exécution de "k3sconfig.sh first" sur le premier nœud
Le script va :
- S'assurer que le module k3s est démarré en tant que prim sur le premier nœud
- Installer k3s sur le deuxième nœud
- Démarrer le module k3s
Étape 5. Vérifiez que le module SafeKit k3s est en cours d'exécution sur les deux nœuds
Vérifiez avec cette commande sur les deux nœuds : /opt/safekit/safekit –H "*" state
La réponse doit être similaire à l'image.
/opt/safekit/safekit –H "*" state
---------------- Server=http://10.0.0.20:9010 ----------------
admin action=exec
--------------------- k3s State ---------------------
Local (127.0.0.1) : PRIM (Service : Available)(Color : Green)
Success
---------------- Server=http://10.0.0.21:9010 ----------------
admin action=exec
--------------------- k3s State ---------------------
Local (127.0.0.1) : SECOND (Service : Available)(Color : Green)
Success
Étape 7. Test
Vérifiez avec les lignes de commande Linux que K3S est démarré sur les deux nœuds et que MariaDB est démarré sur le nœud principal.
- Pour tester un basculement, arrêtez le nœud PRIM en faisant défiler le menu de server0 et en cliquant sur Stop. Vérifiez qu'il y a un basculement sur server1 qui devient ALONE et exécute tous les services.
- Pour tester le retour après panne, démarrez server0 en faisant défiler son menu et en cliquant sur Start. Vérifiez qu'il devient SECOND.
- Pour tester l'échange des rôles PRIM et SECOND, faites défiler le menu de server1 et cliquez sur Swap.
Étape 8. Essayez le cluster avec une application Kubernetes telle que WordPress
Vous avez l'exemple d'une installation WordPress : un portail web avec une base de données implémentée par des pods.
Vous pouvez déployer votre propre application de la même manière.
WordPress est automatiquement hautement disponible :
- avec ses données (php + base de données) dans des volumes persistants répliqués en temps réel par SafeKit
- avec une adresse IP virtuelle pour accéder au site WordPress pour les utilisateurs
- avec basculement automatique et réintégration automatique
Remarques:
- Le chart WordPress définit un service à load balancer qui écoute sur les ports <service.port> et <service.httpsport>.
- WordPress est accessible via l'url : http://<virtual-ip>:<service.port>.
- L'IP virtuelle est gérée par SafeKit et automatiquement basculée en cas de panne.
- Par défaut, K3S implémente des load balancers avec Klipper.
- Klipper écoute sur <virtual ip>:<service.port> et achemine les paquets TCP/IP vers l'adresse IP et le port du pod WordPress qu'il a sélectionné.
$ export KUBECONFIG=/etc/rancher/k3s/k3s.yaml
$ helm repo add bitnami https://charts.bitnami.com/bitnami
$ helm install my-release bitnami/wordpress --set global.storageClass=nfs-client --set service.port=8099,service.httpsPort=4439
Journal du module
- Lisez le journal du module pour comprendre les raisons d'un basculement, d'un état d'attente etc...
Pour voir le journal du module du nœud 1 (image) :
- cliquez sur l'onglet Control
- cliquez sur node 1/PRIM sur le côté gauche pour sélectionner le serveur (il devient bleu)
- cliquez sur Module log
- cliquez sur l'icône Actualiser (flèches vertes) pour mettre à jour la console
- cliquez sur la disquette pour enregistrer le journal du module dans un fichier .txt et l'analyser dans un éditeur de texte
Cliquez sur node2 pour voir le journal du module du serveur secondaire.
Journal applicatif
- Lisez le journal applicatif pour voir les messages de sortie des scripts de redémarrage start_prim et stop_prim.
Pour voir le journal applicatif du nœud 1 (image) :
- cliquez sur l'onglet Control
- cliquez sur node 1/PRIM sur le côté gauche pour sélectionner le serveur (il devient bleu)
- cliquez sur Application Log pour voir les messages lors du démarrage et de l'arrêt des services Kubernetes
- cliquez sur l'icône Actualiser (flèches vertes) pour mettre à jour la console
- cliquez sur la disquette pour enregistrer le journal applicatif dans un fichier .txt et l'analyser dans un éditeur de texte
Cliquez sur le nœud 2 pour voir le journal applicatif du serveur secondaire.
Configuration avancée
- Dans l'onglet Advanced Configuration, vous pouvez modifier les fichiers internes du module : bin/start_prim et bin/stop_prim et conf/userconfig.xml.
Si vous apportez des modifications dans les fichiers internes, vous devez appliquer la nouvelle configuration par un clic droit sur l'icône/xxx sur le côté gauche (voir image) : l'interface vous permettra de redéployer les fichiers sur les deux serveurs.
Support
- Pour obtenir de l'aide, prenez 2 Snapshots SafeKit (2 fichiers .zip), un pour chaque serveur.
Si vous avez un compte sur https://support.evidian.com, téléchargez-les dans l'outil call desk.
Pourquoi une réplication de quelques Tera-octets ?
Temps de resynchronisation après panne (étape 3)
- Réseau 1 Gb/s ≈ 3 heures pour 1 téraoctet.
- Réseau 10 Gb/s ≈ 1 heure pour 1 téraoctet ou moins en fonction des performances d'écriture disque.
Alternative
- Pour un grand volume de données, utilisez un stockage partagé externe.
- Plus cher, plus complexe.
Pourquoi une réplication < 1 000 000 fichiers ?
- Performance du temps de resynchronisation après panne (étape 3).
- Temps pour vérifier chaque fichier entre les deux nœuds.
Alternative
- Placez les nombreux fichiers à répliquer sur un disque dur virtuel / une machine virtuelle.
- Seuls les fichiers représentant le disque dur virtuel / la machine virtuelle seront répliqués et resynchronisés dans ce cas.
Pourquoi un basculement < 25 VMs répliquées ?
- Chaque VM s'exécute dans un module miroir indépendant.
- Maximum de 25 modules miroir exécutés sur le même cluster.
Alternative
- Utilisez un stockage partagé externe et une autre solution de clustering de VMs.
- Plus cher, plus complexe.
Pourquoi un réseau LAN/VLAN entre sites distants ?
- Basculement automatique de l'adresse IP virtuelle avec 2 nœuds dans le même sous-réseau.
- Bonne bande passante pour la resynchronisation (étape 3) et bonne latence pour la réplication synchrone (quelques ms).
Alternative
- Utilisez un équilibreur de charge pour l'adresse IP virtuelle si les 2 nœuds sont dans 2 sous-réseaux (supporté par SafeKit, notamment dans le cloud).
- Utilisez des solutions de backup avec réplication asynchrone pour un réseau à latence élevée.
Partage de charge réseau et reprise sur panne |
|
Windows farm |
Linux farm |
Generic farm > | Generic farm > |
Microsoft IIS > | - |
NGINX > | |
Apache > | |
Amazon AWS farm > | |
Microsoft Azure farm > | |
Google GCP farm > | |
Other cloud > |
Architectures de clustering avancée
Plusieurs modules peuvent être déployés dans le même cluster. Ainsi, des architectures de clustering avancées peuvent être mises en œuvre :
- un cluster qui mixte ferme et miroir avec le déploiement d’un module ferme et d’un module miroir dans le même cluster,
- un cluster actif/actif avec réplication en déployant plusieurs modules miroirs sur 2 serveurs,
- un cluster Hyper-V ou un cluster KVM avec réplication temps réel et reprise de machines virtuelles complètes entre 2 hyperviseurs actifs,
- un cluster N-1 avec le déploiement de N modules miroirs sur N+1 serveurs.
Réplication de fichiers temps réel et reprise sur panne |
|||||||||||||||||||||||||||||||
Windows mirror |
Linux mirror |
||||||||||||||||||||||||||||||
Generic mirror > | Generic mirror > | ||||||||||||||||||||||||||||||
Microsoft SQL Server > | - | ||||||||||||||||||||||||||||||
Oracle > | |||||||||||||||||||||||||||||||
MariaDB > | |||||||||||||||||||||||||||||||
MySQL > | |||||||||||||||||||||||||||||||
PostgreSQL > | |||||||||||||||||||||||||||||||
Firebird > | |||||||||||||||||||||||||||||||
Windows Hyper-V > | Linux KVM > | ||||||||||||||||||||||||||||||
- | Docker > Podman > Kubernetes K3S > |
||||||||||||||||||||||||||||||
- | |||||||||||||||||||||||||||||||
- | Elasticsearch > | ||||||||||||||||||||||||||||||
Milestone XProtect > | - | ||||||||||||||||||||||||||||||
Genetec SQL Server > | - | ||||||||||||||||||||||||||||||
Hanwha Wisenet Wave > Hanwha Wisenet SSM > |
- | ||||||||||||||||||||||||||||||
Nedap AEOS > | - | ||||||||||||||||||||||||||||||
Siemens SIMATIC WinCC > Siemens SIMATIC PCS 7 > Siemens Desigo CC > Siemens Siveillance suite > Siemens Siveillance VMS > Siemens SiPass > Siemens SIPORT > |
- | ||||||||||||||||||||||||||||||
Bosch AMS > Bosch BIS > Bosch BVMS > |
- | ||||||||||||||||||||||||||||||
Amazon AWS mirror > | |||||||||||||||||||||||||||||||
Microsoft Azure mirror > | |||||||||||||||||||||||||||||||
Google GCP mirror > | |||||||||||||||||||||||||||||||
Other cloud > |
Cluster miroir d'Evidian SafeKit avec réplication de fichiers temps réel et reprise sur panne |
|
Économisez avec 3 produits en 1 |
|
Configuration très simple |
|
Réplication synchrone |
|
Retour d'un serveur tombé en panne totalement automatisé (failback) |
|
Réplication de n'importe quel type de données |
|
Réplication de fichiers vs réplication de disque |
|
Réplication de fichiers vs disque partagé |
|
Sites distants et adresse IP virtuelle |
|
Split brain et quorum En savoir plus > |
|
Cluster actif/actif |
|
Solution de haute disponibilité uniforme |
|
|
|
Cluster ferme d'Evidian SafeKit avec load balancing et reprise sur panne |
|
Pas de load balancer, ni de serveur proxy dédié, ni d'adresse Ethernet multicast spéciale En savoir plus > |
|
Toutes les fonctionnalités de clustering En savoir plus > |
|
Sites distants et adresse IP virtuelle En savoir plus > |
|
Solution de haute disponibilité uniforme En savoir plus > |
|
|
|
Cluster de type "shared nothing"" vs cluster à disque partagé |
|
|
|
|
|
Haute disponibilité vs tolérance aux fautes |
|
|
|
Réplication synchrone vs réplication asynchrone |
|
|
|
Réplication de fichiers au niveau octet vs réplication de disque au niveau du bloc |
|
|
|
Heartbeat, reprise sur panne et quorum pour éviter 2 serveurs maîtres |
|
|
|
|
|
Guide de l'utilisateur
Modules applicatifs
Release Notes
Documentation d'avant vente
Introduction
- Fonctionnalités
- Architectures
- Avantages distinctifs
-
- Cluster matériel vs logiciel
- Réplication synchrone vs asynchrone
- Réplications de fichiers vs disques
- Haute disponibilité vs tolérance aux fautes
- Load balancing matériel vs logiciel
- HA de machines virtuelles vs applications
Installation, configuration, CLI
-
- Installation du package
- Configuration des nœuds
- Configuration du cluster
- Upgrade
-
- Configuration du cluster
- Onglet Configuration
- Onglet Contrôle
- Onglet Supervision
- Onglet Configuration avancée
-
- Installation silencieuse
- Administration du cluster
- Administration du module
- Command line interface
Configuration avancée
-
- userconfig.xml + restart scripts
- Heartbeat (<hearbeat>)
- Virtual IP address (<vip>)
- Real-time file replication (<rfs>)
-
- userconfig.xml + restart scripts
- Farm configuration (<farm>)
- Virtual IP address (<vip>)
-
- Failover machine (<failover>)
- Process monitoring (<errd>)
- Network and duplicate IP checkers
- Custom checker (<custom>)
- Split brain checker (<splitbrain>)
- TCP, ping, module checkers
Support
-
- Analyse des snapshots
-
- Récupérer les clés permanentes
- S'enregistrer sur support.evidian.com
- Call desk