Cette page décrit les options de haute disponibilité dans Google Distributed Cloud (logiciel uniquement) pour VMware.
Fonctionnalité de base
Une installation logicielle uniquement de Google Distributed Cloud pour VMware inclut un cluster d'administrateur et un ou plusieurs clusters d'utilisateur.
Le cluster d'administrateur gère le cycle de vie des clusters d'utilisateur, y compris leur création, leurs mises à jour, leurs mises à niveau et leur suppression. Dans le cluster d'administrateur, le maître d'administrateur gère les nœuds de calcul d'administrateur, qui incluent les maîtres d'utilisateur (nœuds exécutant le plan de contrôle des clusters d'utilisateur gérés) et les nœuds complémentaires (nœuds exécutant les composants complémentaires compatibles avec les fonctionnalités du cluster d'administrateur).
Pour chaque cluster d'utilisateur, le cluster d'administrateur comporte un nœud standard ou trois nœuds haute disponibilité exécutant le plan de contrôle. Le plan de contrôle inclut le serveur d'API Kubernetes, le programmeur Kubernetes, le gestionnaire de contrôleurs Kubernetes et plusieurs contrôleurs critiques pour le cluster d'utilisateur.
La disponibilité du plan de contrôle du cluster d'utilisateur est essentielle pour les opérations de charges de travail telles que la création, le scaling à la hausse et à la baisse, et l'arrêt d'une charge de travail. En d'autres termes, une panne du plan de contrôle n'interfère pas avec les charges de travail en cours d'exécution, mais les charges de travail existantes perdent les fonctionnalités de gestion du serveur d'API Kubernetes si son plan de contrôle est absent.
Les charges de travail et services conteneurisés sont déployés dans les nœuds de calcul du cluster d'utilisateur. Les nœuds de calcul à un seul nœud ne doivent pas être critiques pour la disponibilité d'une application tant qu'elle est déployée avec des pods redondants programmés sur plusieurs nœuds de calcul.
Activer la haute disponibilité
vSphere et Google Distributed Cloud offrent un certain nombre de fonctionnalités qui contribuent à la haute disponibilité.
vSphere HA et vMotion
Nous vous recommandons d'activer les deux fonctionnalités suivantes dans le cluster vCenter qui héberge vos clusters Google Distributed Cloud :
Ces fonctionnalités améliorent la disponibilité et la récupération en cas de défaillance d'un hôte ESXi.
vCenter HA utilise plusieurs hôtes ESXi configurés en tant que cluster pour assurer une récupération rapide des pannes et une haute disponibilité économique pour les applications exécutées sur des machines virtuelles. Nous vous recommandons de provisionner votre cluster vCenter avec des hôtes supplémentaires et d'activer la surveillance de l'hôte vSphere haute disponibilité avec Host Failure Response défini sur Restart VMs. Vos VM peuvent alors redémarrer automatiquement sur d'autres hôtes disponibles en cas de défaillance de l'hôte ESXi.
vMotion permet d'effectuer une migration à chaud sans interruption d'un hôte ESXi vers un autre hôte. Pour la maintenance planifiée de l'hôte, vous pouvez utiliser la migration à chaud vMotion pour éviter tout temps d'arrêt d'application et garantir la continuité de l'entreprise.
Cluster d'administrateur
Google Distributed Cloud permet de créer des clusters administrateur à haute disponibilité. Un cluster d'administrateur à haute disponibilité comporte trois nœuds qui exécutent des composants du plan de contrôle. Pour en savoir plus sur les exigences et les limites, consultez la section Cluster d'administrateur à haute disponibilité.
Notez que l'indisponibilité du plan de contrôle du cluster d'administrateur n'affecte pas les fonctionnalités existantes du cluster d'utilisateurs ni les charges de travail exécutées dans ces clusters.
Un cluster d'administrateur comporte deux nœuds complémentaires. Si l'un est indisponible, l'autre peut toujours traiter les opérations du cluster d'administrateur. Pour la redondance, le Cloud distribué de Google répartit les services complémentaires essentiels, tels que kube-dns, sur les deux nœuds complémentaires.
Si vous définissez antiAffinityGroups.enabled sur true dans le fichier de configuration du cluster d'administrateur, Google Distributed Cloud crée automatiquement des règles d'anti-affinité vSphere DRS pour les nœuds complémentaires, ce qui entraîne leur répartition sur deux hôtes physiques afin d'assurer une haute disponibilité.
Cluster d'utilisateur
Vous pouvez activer la haute disponibilité pour un cluster d'utilisateur en définissant masterNode.replicas sur 3 dans le fichier de configuration du cluster d'utilisateur. Si Controlplane V2 est activé sur le cluster d'utilisateur (recommandé), les trois nœuds du plan de contrôle s'exécutent dans le cluster d'utilisateur.
Les clusters d'utilisateur kubeception à haute disponibilité existants exécutent les trois nœuds du plan de contrôle dans le cluster d'administrateur. Chaque nœud du plan de contrôle exécute également une instance répliquée etcd. Le cluster d'utilisateur continuera de fonctionner tant qu'un plan de contrôle est en cours d'exécution et qu'il y a un quorum etcd. Un quorum etcd nécessite que deux des trois instances dupliquées etcd soient en cours d'exécution.
Si vous définissez antiAffinityGroups.enabled sur true dans le fichier de configuration du cluster d'administrateur, Google Distributed Cloud crée automatiquement des règles d'anti-affinité vSphere DRS pour les trois nœuds exécutant le plan de contrôle du cluster d'utilisateur.
Cela a pour effet de répartir les VM sur trois hôtes physiques.
Google Distributed Cloud crée également des règles d'anti-affinité vSphere DRS pour les nœuds de calcul de votre cluster d'utilisateur, ce qui entraîne la répartition de ces nœuds sur au moins trois hôtes physiques. Plusieurs règles d'anti-affinité DRS sont utilisées par chaque pool de nœuds de cluster d'utilisateur en fonction du nombre de nœuds. Ainsi, les nœuds de calcul peuvent trouver des hôtes sur lesquels s'exécuter, même lorsque le nombre d'hôtes est inférieur au nombre de VM dans le pool de nœuds du cluster d'utilisateur. Nous vous recommandons d'inclure des hôtes physiques supplémentaires dans le cluster vCenter. Configurez également la fonctionnalité DRS de manière à ce qu'elle soit entièrement automatisée. Ainsi, lorsqu'un hôte n'est plus disponible, le service DRS peut redémarrer automatiquement les VM sur d'autres hôtes disponibles sans enfreindre les règles d'anti-affinité de VM.
Google Distributed Cloud conserve un libellé de nœud spécial, onprem.gke.io/failure-domain-name, dont la valeur est définie sur le nom d'hôte ESXi sous-jacent. Les applications utilisateur qui souhaitent bénéficier de la haute disponibilité peuvent configurer des règles podAntiAffinity avec ce libellé comme topologyKey, pour garantir que leurs pods d'application sont propagés sur différentes VM et hôtes physiques.
Vous pouvez également configurer plusieurs pools de nœuds pour un cluster d'utilisateur avec différents datastores et des libellés de nœuds spéciaux. De même, vous pouvez configurer des règles podAntiAffinity en utilisant ce libellé de nœud spécial en tant qu'élément topologyKey afin d'améliorer la disponibilité en cas de défaillance du datastore.
Pour bénéficier de la haute disponibilité pour les charges de travail d'utilisateur, assurez-vous que le cluster d'utilisateur dispose d'un nombre suffisant d'instances dupliquées sous nodePools.replicas pour garantir l'exécution du nombre souhaité de nœuds de calcul dans le cluster d'utilisateur.
Pour isoler les défaillances des clusters d'administrateur et des clusters d'utilisateur, vous pouvez utiliser des datastores distincts.
Équilibreur de charge
Vous pouvez utiliser deux types d'équilibreurs de charge pour la haute disponibilité.
Équilibreur de charge MetalLB groupé
Pour l'équilibreur de charge MetalLB groupé, vous obtenez la haute disponibilité en disposant de plusieurs nœuds avec enableLoadBalancer: true.
MetalLB distribue les services sur les nœuds d'équilibrage de charge, mais pour un seul service, il n'y a qu'un seul nœud leader qui gère tout le trafic de ce service.
Lors de la mise à niveau du cluster, des temps d'arrêt sont constatés lorsque les nœuds de l'équilibreur de charge sont mis à niveau. La durée de la perturbation de basculement de MetalLB augmente à mesure que le nombre de nœuds d'équilibreur de charge augmente. Avec moins de cinq nœuds, la perturbation dure moins de 10 secondes.
Équilibrage de charge manuel
Avec l'équilibrage de charge manuel, vous configurez Google Distributed Cloud pour qu'il utilise un équilibreur de charge de votre choix, tel que F5 BIG-IP ou Citrix. Vous configurez la haute disponibilité sur votre équilibreur de charge, et non dans Google Distributed Cloud.
Utiliser plusieurs clusters pour la reprise après sinistre
Le déploiement d'applications dans plusieurs clusters sur plusieurs plates-formes vCenter ou GKE Enterprise peut assurer une disponibilité globale plus élevée et limiter le rayon d'action des interruptions.
Cette configuration utilise le cluster GKE Enterprise existant du centre de données secondaire pour la reprise après sinistre au lieu de configurer un nouveau cluster. Voici un résumé détaillé de cette action :
Créez un autre cluster d'administrateur et un autre cluster d'utilisateur dans le centre de données secondaire. Dans cette architecture multicluster, les utilisateurs doivent disposer de deux clusters d'administrateur dans chaque centre de données, et chaque cluster d'administrateur exécute un cluster d'utilisateur.
Le cluster d'utilisateur secondaire dispose d'un nombre minimal de nœuds de calcul (trois) et d'une instance de secours automatique (toujours en cours).
Les déploiements d'applications peuvent être répliqués sur les deux vCenter à l'aide de Config Sync, ou l'approche recommandée consiste à utiliser une chaîne d'outils DevOps (CI/CD, Spinnaker) d'application existante.
En cas de sinistre, le cluster d'utilisateur peut être redimensionné en fonction du nombre de nœuds.
De plus, un basculement DNS sera nécessaire pour acheminer le trafic entre les clusters vers le centre de données secondaire.