Haute disponibilité

Redondance matérielle

La configuration minimale du rack de base contient des composants redondants de mise en réseau, de stockage et de serveur pour garantir que la défaillance 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ôte et liaisons montantes. Les commutateurs Leaf interconnectent les composants du rack à l'aide de câbles croisés vers des interfaces réseau redondantes dans chaque composant. Chaque commutateur Leaf possède également une connexion à chacun des commutateurs Spine, qui sont également interconnectés. Les commutateurs Spine forment l'épine dorsale du réseau et permettent 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 (en haut du 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 réparties sur les trois noeuds par un équilibreur de charge. Si l'un des noeuds cesse de répondre et se ferme à partir 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 l'appareil 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 protection optimale des données.

disponibilité du système

La couche des logiciels et des 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 conteneurs Kubernetes utilise également le clustering pour ses propres noeuds de contrôleur et les pods de service qu'il héberge. De nombreuses répliques des microservices sont exécutées à un moment donné. Les noeuds et les pods sont répartis sur les noeuds de gestion, et Kubernetes garantit que les pods en échec sont remplacés par de nouvelles instances pour que tous les services soient exécutés dans une configuration active/active.

Tous les services et composants stockent les données dans une base de données MySQL centrale commune. La base de données de cluster MySQL comporte des instances déployées sur les trois noeuds de gestion. La disponibilité, l'équilibrage de charge, la synchronisation des données et le clustering sont tous contrôlés par des 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 est répartie entre plusieurs composants de l'architecture réseau. Le contrôleur réseau est déployé en tant que service conteneurisé hautement disponible.

La structure de mise à niveau tire parti de la redondance matérielle et des 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 qu'il n'y a pas 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.

Disponibilité de l'instance de calcul

Pour une instance de calcul, la haute disponibilité fait référence à la récupération automatisée d'une instance en cas de défaillance de l'infrastructure sous-jacente. L'état des noeuds de calcul, des hyperviseurs et des instances de calcul est surveillé en permanence. Chaque noeud de calcul est interrogé avec un intervalle de 5 minutes. Lorsque les instances de calcul tombent en panne, le système tente par défaut de les récupérer automatiquement.

Par défaut, le système tente de redémarrer les instances dans le domaine de pannes sélectionné, mais les instances dans les autres domaines de pannes si les ressources disponibles dans le domaine de pannes sélectionné sont insuffisantes. Le domaine de pannes sélectionné est celui spécifié dans la configuration d'instance.

Si un noeud de calcul tombe en panne en raison d'un redémarrage non planifié, lorsque le noeud de calcul revient à un fonctionnement normal, les instances sont redémarrées. Au prochain intervalle d'interrogation, par défaut, si des instances qui doivent être en cours d'exécution mais qui ont un état différent sont détectées, la commande de démarrage est exécutée à nouveau. Si des instances se sont arrêtées et conservent cet état, l'hyperviseur tente de les redémarrer jusqu'à 5 fois. Les instances qui n'étaient pas en cours d'exécution avant l'indisponibilité du noeud de calcul restent arrêtées lorsque le noeud de calcul est à nouveau opérationnel.

Un noeud de calcul est considéré comme défaillant lorsqu'il a été déconnecté du réseau de données ou a été mis hors tension pendant environ 5 minutes. Ce délai d'expiration de 5 minutes correspond à deux tentatives d'interrogation ayant échoué. Il s'agit du seuil permettant de placer le noeud de calcul à l'état FAIL et son agent à l'état EVACUATING. Cette condition est requise avant le démarrage de la migration au redémarrage.

La migration au redémarrage implique que toutes les instances de calcul du noeud de calcul défaillant sont arrêtées et redémarrées sur un autre noeud de calcul. Une fois la migration terminée, l'agent du noeud de calcul défaillant indique que les instances ont été évacuées. Si le noeud de calcul se réinitialise, il doit passer par un processus de nettoyage qui supprime toutes les configurations d'instance obsolètes et les disques virtuels associés. Après le nettoyage, le noeud de calcul peut à nouveau héberger les instances de calcul.

Pendant toute la migration au redémarrage, les instances restent à l'état de configuration "déplacement". Une fois la migration terminée, l'état de configuration de l'instance devient "en cours d'exécution". Les instances arrêtées avant l'échec ne sont pas migrées car elles ne sont associées à aucun noeud de calcul.

Continuité de service

Compute Cloud@Customer 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 du personnel Oracle.

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.

En option, les charges globales déployées sur Compute Cloud@Customer 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 infrastructures Compute Cloud@Customer doivent être configurées sur des sites différents et configurées pour être des répliques les unes des autres. Les ressources sous contrôle de récupération après sinistre sont stockées séparément sur les appareils 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éplique avec un temps d'inactivité minimal. Nous recommandons que la récupération après sinistre soit implémentée pour tous les systèmes de production critiques.