Haute disponibilité

Redondance matérielle

La configuration minimale du rack de base contient des composants de réseau, de stockage et de serveur redondants pour garantir que la panne d'un élément unique n'affecte pas la disponibilité globale du système.

La connectivité des données dans l'ensemble du système repose sur des paires redondantes de commutateurs Leaf et Spine. Le groupement de liaisons est configuré sur toutes les interfaces : ports de commutateur, cartes d'interface réseau hôtes et liaisons montantes. Les commutateurs Leaf relient les composants du rack à l'aide de câbles croisés aux interfaces réseau redondantes de chaque composant. Chaque commutateur Leaf a également une connexion à chacun des commutateurs Spine, qui sont également interconnectés. Les commutateurs Spine forment l'épine dorsale du réseau et activent le trafic externe au rack. Leurs liaisons montantes vers le réseau du centre de données se composent de deux paires de câbles, qui sont interconnectées à deux commutateurs ToR (haut de rack) redondants.

Le cluster de gestion, qui exécute le logiciel du contrôleur et les services au niveau du système, se compose de trois noeuds de gestion entièrement actifs. Les demandes entrantes passent par l'adresse IP virtuelle du cluster de noeuds de gestion et sont distribuées sur les trois noeuds par un équilibreur de charge. Si l'un des noeuds cesse de répondre et s'arrête du cluster, l'équilibreur de charge continue d'envoyer le trafic vers les deux noeuds restants jusqu'à ce que le noeud défaillant soit à nouveau en bon état et rejoigne le cluster.

Le stockage pour le système et pour les ressources cloud dans l'environnement est fourni par ZFS Storage Appliance interne. Ses deux contrôleurs forment un cluster actif-actif, offrant une haute disponibilité et un excellent débit en même temps. Les pools ZFS sont construits sur des disques dans une configuration en miroir pour une meilleure protection des données. Cela s'applique au tiroir de disque haute capacité standard ainsi qu'à un tiroir hautes performances basé sur un SSD en option.

Disponibilité du système

La couche de logiciels et de services est déployée sur le cluster de gestion à trois noeuds et tire parti de la haute disponibilité inhérente à la conception du cluster. L'environnement d'orchestration de conteneur Kubernetes utilise également le clustering pour ses propres noeuds de contrôleur et les pods de service qu'il héberge. Plusieurs répliques des microservices sont exécutées à un moment donné. Les noeuds et les pods sont distribués sur les noeuds de gestion, et Kubernetes garantit que les pods défaillants sont remplacés par de nouvelles instances pour que tous les services restent en cours d'exécution dans une configuration active/active.

Tous les services et composants stockent les données dans une base de données de cluster MySQL centrale commune, dont les instances sont déployées sur les trois noeuds de gestion. La disponibilité, l'équilibrage de charge, la synchronisation des données et la mise en cluster sont tous contrôlés par les composants internes du cluster MySQL.

Une partie importante de la mise en réseau de l'infrastructure au niveau du système est définie par logiciel. La configuration des commutateurs virtuels, des routeurs et des passerelles n'est pas stockée et gérée par les commutateurs, mais répartie entre plusieurs composants de l'architecture réseau. Le contrôleur réseau est déployé en tant que service en conteneur hautement disponible.

La structure de mise à niveau exploite la redondance matérielle et les conceptions en cluster pour fournir des mises à niveau non simultanées pour tous les composants. Lors de la mise à niveau d'une instance de composant, les instances restantes garantissent l'absence de temps d'inactivité. La mise à niveau est terminée lorsque toutes les instances de composant ont été mises à niveau et rétablies en fonctionnement normal.

Continuité de service

Private Cloud Appliance offre plusieurs fonctionnalités qui améliorent encore la haute disponibilité. La surveillance de la santé à tous les niveaux du système est un facteur clé. Les données de diagnostic et de performance sont collectées à partir de tous les composants, puis stockées et traitées de manière centralisée et mises à la disposition des administrateurs sous forme de visualisations sur les tableaux de bord standard. En outre, des alertes sont générées lorsque les mesures dépassent les seuils définis.

Pour limiter la perte de données et prendre en charge la récupération de la configuration du système et des services en cas de panne, des sauvegardes cohérentes et complètes sont effectuées régulièrement. Une sauvegarde peut également être exécutée manuellement, par exemple pour créer un point de restauration avant une modification critique. Les sauvegardes sont stockées dans un partage NFS dédié sur ZFS Storage Appliance et permettent de restaurer l'intégralité de l'enclave de service si nécessaire.

En option, les charges globales déployées sur l'appliance peuvent être protégées contre les temps d'arrêt et la perte de données grâce à l'implémentation de la récupération après sinistre. Pour ce faire, deux systèmes Private Cloud Appliance doivent être configurés sur des sites différents et être une réplique l'un de l'autre. Les ressources sous contrôle de récupération après sinistre sont stockées séparément sur les appliances de stockage ZFS de chaque système et répliquées entre les deux. Lorsqu'un incident se produit sur un site, l'environnement est activé sur le système de répliques avec un temps d'arrêt minimal. Nous recommandons que la récupération après sinistre soit implémentée pour tous les systèmes de production critiques.