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.
1. Téléchargez les packages
- Téléchargez la version gratuite de SafeKit (safekit_xx.bin)
- Télécharger le module Linux k3s.safe
- 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.
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 en personnalisant les variables d'environnement en fonction de votre environnement (dont l'adresse IP virtuelle)
- 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
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)
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
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
6. Démarrez la console Web SafeKit pour administrer le cluster
- Connectez un navigateur à l'url de la console Web SafeKit
http://server0-IP:9010.>/li> - Vous devriez voir une page similaire à l'image.
- Vérifiez avec des lignes de commande Linux que K3S est démarré sur les deux nœuds (démarré dans
start_primetstart_second) et que MariaDB est démarré sur le nœud principal (démarré dansstart_prim).
7. Tests
- Arrêtez le nœud PRIM en faisant défiler son menu contextuel et en cliquant sur
Stop. - Vérifiez qu'il y a un basculement sur le nœud 2 qui doit devenir ALONE (vert).
- Et avec des lignes de commande sous Linux, vérifiez le basculement des services (arrêtés sur le nœud 1 dans le script
stop_primet démarrés sur le nœud 2 dans le scriptstart_prim). MariaDB et K3S devraient s'exécuter sur le nœud 2.
Si ALONE (vert) n’est pas atteint sur le nœud 2, analysez pourquoi avec le journal du module du nœud 2.
- cliquez sur
node2pour afficher le journal du module. - exemple de journal de module SQL Server où le nom du service dans
start_primn'est pas valide. Le processus sqlserver.exe est surveillé mais comme il n'est pas démarré, à la fin le module s'arrête.
Si tout va bien, lancez un démarrage du nœud 1, qui resynchronisera les répertoires répliqués depuis le nœud 2.
Si les choses vont mal, arrêtez le nœud 2 et forcez le démarrage en tant que primaire du nœud 1, qui redémarrera avec ses données localement saines au moment de l'arrêt.
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
9. Support
- Pour obtenir du support, prenez deux
snapshotsSafeKit (deux fichiers .zip), un pour chaque nœud. - Si vous avez un compte sur https://support.evidian.com, téléchargez-les dans l'outil call desk.
10. Si nécessaire, configurez un checker splitbrain
- Voir ci-dessous "Quels sont les différents scénarios en cas d'isolement réseau dans un cluster ?" pour savoir si vous devez configurer un checker splitbrain.
- Dans la configuration du module, cliquez sur
Advanced configuration(voir image) pour modifieruserconfig.xml. - Déclarez le checker splitbrain en ajoutant dans la section
<check>deuserconfig.xml:<service> ... <check> ... <splitbrain ident="witness" exec="ping" arg="IP du witness"/> </check> - Appliquez la configuration avec
Save and applypour redéployer le fichier userconfig.xml modifié sur les deux nœuds (le module doit être arrêté sur les deux nœuds à l'étapeSave and apply).
Paramètres :
ident="witness"identifie le témoin (witness) avec un nom de ressource :splitbrain.witness. Vous pouvez modifier cette valeur pour identifier le témoin.exec="ping"fait référence au code ping à exécuter. Ne modifiez pas cette valeur.arg="witness IP"est un argument pour le ping. Changez cette valeur avec l'IP du témoin (un élément robuste, typiquement un routeur).
Un seul réseau
Lorsqu'il y a un isolement réseau, le comportement par défaut est :
- comme les heartbeats sont perdus pour chaque nœud, chaque nœud passe en ALONE et exécute l'application avec son adresse IP virtuelle (double exécution de l'application modifiant ses données locales),
- lorsque l'isolement est réparé, un nœud ALONE est obligé de s'arrêter et de resynchroniser ses données depuis l'autre nœud,
- à la fin, le cluster est PRIM-SECOND (ou SECOND-PRIM selon la détection d'adresse IP virtuelle en double faite par Windows).
Deux réseaux avec un réseau de réplication dédié
Lorsqu'il y a un isolement réseau, le comportement avec un réseau de réplication dédié est :
- un réseau de réplication dédié est implémenté sur un réseau privé,
- les heartbeats sur le réseau de production sont perdus (réseau isolé),
- les heartbeats sur le réseau de réplication fonctionnent (réseau non isolé),
- le cluster reste à l'état PRIM/SECOND.
Un seul réseau et un checker split-brain
Lorsqu'il y a un isolement du réseau, le comportement avec un split-brain checker est :
- un split-brain checker a été configuré avec l'adresse IP d'un témoin (typiquement un routeur),
- le split-brain agit lorsqu'un serveur passe de PRIM à ALONE ou de SECOND à ALONE,
- en cas d'isolement du réseau, avant de passer en ALONE, les deux nœuds testent l'adresse IP,
- le nœud qui peut accéder à l'adresse IP passe à ALONE, l'autre passe à WAIT,
- lorsque l'isolement est réparé, le nœud WAIT resynchronise ses données et devient SECOND.
Remarque : Si le témoin est en panne ou déconnecté, les deux nœuds passent à WAIT et l'application n'est plus en cours d'exécution. C'est pourquoi vous devez choisir un témoin robuste comme un routeur.
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 ≤ 32 VMs répliquées ?
- Chaque VM s'exécute dans un module miroir indépendant.
- Maximum de 32 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 (typiquement un aller-retour de moins de 2 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 Vision > Hanwha Wisenet > |
- | ||||||||||||||||||||||||||||||
| 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 > | |||||||||||||||||||||||||||||||
- Demonstration
- Examples of redundancy and high availability solution
- Evidian SafeKit sold in many different countries with Milestone
- 2 solutions: virtual machine cluster or application cluster
- Distinctive advantages
- More information on the web site
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 |
|
|
|
|
|
|
|
Evidian SafeKit 8.2
Toutes les nouvelles fonctionnalités par rapport à la 7.5 décrites dans le release notes
Packages
- Windows (with Microsoft Visual C++ Redistributable)
- Windows (without Microsoft Visual C++ Redistributable)
- Linux
- OS supportés et derniers fixes
Licence d'essai gratuit d'un mois
Documentation technique
Information produit
Training
Introduction
-
- Demonstration
- Examples of redundancy and high availability solution
- Evidian SafeKit sold in many different countries with Milestone
- 2 solutions: virtual machine or application cluster
- Distinctive advantages
- More information on the web site
- SafeKit training
-
- Cluster of virtual machines
- Mirror cluster
- Farm cluster
Installation, Console, CLI
- Install and setup / pptx
- Package installation
- Nodes setup
- Upgrade
- Web console / pptx
- Configuration of the cluster
- Configuration of a new module
- Advanced usage
- Securing the web console
- Command line / pptx
- Configure the SafeKit cluster
- Configure a SafeKit module
- Control and monitor
Advanced configuration
- Mirror module / pptx
- start_prim / stop_prim scripts
- userconfig.xml
- Heartbeat (<hearbeat>)
- Virtual IP address (<vip>)
- Real-time file replication (<rfs>)
- How real-time file replication works?
- Mirror's states in action
- Farm module / pptx
- start_both / stop_both scripts
- userconfig.xml
- Farm heartbeats (<farm>)
- Virtual IP address (<vip>)
- Farm's states in action
Troubleshooting
- Troubleshooting / pptx
- Analyze yourself the logs
- Take snapshots for support
- Boot / shutdown
- Web console / Command lines
- Mirror / Farm / Checkers
- Running an application without SafeKit
Support
- Evidian support / pptx
- Get permanent license key
- Register on support.evidian.com
- Call desk