eviden-logo

Evidian > Produits > Logiciel de haute disponibilité - Zéro surcoût matériel > Kubernetes K3S : le cluster de haute disponibilité le plus simple entre deux serveurs redondants

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

Comment le logiciel Evidian SafeKit met en œuvre simplement la haute disponibilité de Kubernetes K3S entre deux serveurs redondants ?

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 :

  • une IP virtuelle/port NFS
  • un export de partage NFS
  • des volumes persistants K3S
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 :

  • une IP virtuelle/port MariaDB
  • la base de données de configuration de K3S
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)

Comment fonctionne le cluster miroir de SafeKit avec Kubernetes K3S ?

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.

Réplication de données temps réel et reprise sur panne dans un cluster Kubernetes K3S

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.

Basculement automatique dans un cluster Kubernetes K3S

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.

Réintégration après panne dans un cluster Kubernetes K3S

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.

Retour à la normale d'un cluster Kubernetes K3S

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.

Essai gratuit de SafeKit + module miroir pour Kubernetes K3S + guide d'installation rapide

Utilisation typique avec SafeKit

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

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 ?

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.

Modules SafeKit pour des solutions de redondance et de haute disponibilité plug&play

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 :

Démonstrations de solutions de redondance et de haute disponibilité

Webinaire SafeKit

Ce webinaire présente en 2 minutes Evidian SafeKit.

Dans ce webinaire, vous comprendrez les clusters ferme et miroir de SafeKit.

Cluster Microsoft SQL Server

Cette vidéo montre la configuration d'un module miroir avec réplication temps réel synchrone et reprise sur panne.

La réplication de fichiers et le basculement sont configurés pour Microsoft SQL Server mais fonctionnent de la même manière pour d'autres bases de données.

Essai gratuit ici

Cluster Apache

Cette vidéo montre une configuration d'un module ferme avec équilibrage de charge et reprise sur panne.

L'équilibrage de charge et le basculement sont configurés pour Apache mais fonctionnent de la même manière pour d'autres services Web.

Essai gratuit ici

Cluster Hyper-V

Cette vidéo montre un cluster Hyper-V avec des réplications complètes de machines virtuelles.

Les machines virtuelles peuvent s'exécuter sur les deux serveurs Hyper-V et elles sont redémarrées en cas de panne.

Essai gratuit ici

Clients de SafeKit dans tous les domaines d'activité

  • Meilleurs cas d'utilisation de haute disponibilité avec SafeKit

    Meilleurs cas d'utilisation [+]

  • Haute disponibilité de la gestion vidéo, du contrôle d'accès, de la gestion des bâtiments avec SafeKit

    Gestion vidéo, contrôle d'accès, gestion des bâtiments [+]

  • Harmonic utilise SafeKit pour la haute disponibilité dans la télédiffusion

    Télévision numérique [+]

  • Natixis utilise SafeKit comme solution de haute disponibilité de ses applications bancaires

    Finance [+]

  • Fives Syleps met en œuvre la haute disponibilité SafeKit dans la logistique automatisée

    Industrie [+]

  • Copperchase déploie la haute disponibilité SafeKit dans le contrôle du trafic aérien

    Transport aérien [+]

  • Wellington IT déploie la haute disponibilité SafeKit dans les banques

    Banque [+]

  • La RATP choisit la solution de haute disponibilité SafeKit pour ses lignes de métro

    Transport métropolitain [+]

  • Systel déploie la haute disponibilité SafeKit dans les centres d'appels des pompiers et du SAMU

    Santé [+]

  • La haute disponibilité de l'ERP de l'armée Française est réalisée avec SafeKit à la DGA

    Gouvernement [+]

Différentiateurs de la solution de haute disponibilité SafeKit par rapport à la concurrence

Documentation technique de SafeKit

Formation à SafeKit

Introduction

  1. Introduction / pptx

    • Fonctionnalités
    • Architectures
    • Avantages distinctifs
  2. Compétition / pptx

    • 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

  1. Installation / pptx

    • Installation du package
    • Configuration des nœuds
    • Configuration du cluster
    • Upgrade
  2. Console web / pptx

    • Configuration du cluster
    • Onglet Configuration
    • Onglet Contrôle
    • Onglet Supervision
    • Onglet Configuration avancée
  3. Ligne de commande / pptx

    • Installation silencieuse
    • Administration du cluster
    • Administration du module
    • Command line interface

Configuration avancée

  1. Module miroir / pptx

    • userconfig.xml + restart scripts
    • Heartbeat (<hearbeat>)
    • Virtual IP address (<vip>)
    • Real-time file replication (<rfs>)
  2. Module ferme / pptx

    • userconfig.xml + restart scripts
    • Farm configuration (<farm>)
    • Virtual IP address (<vip>)
  3. Checkers / pptx

    • Failover machine (<failover>)
    • Process monitoring (<errd>)
    • Network and duplicate IP checkers
    • Custom checker (<custom>)
    • Split brain checker (<splitbrain>)
    • TCP, ping, module checkers

Support

  1. Outils pour le support / pptx

    • Analyse des snapshots
  2. Support Evidian / pptx

    • Récupérer les clés permanentes
    • S'enregistrer sur support.evidian.com
    • Call desk