Fiabilité dans Azure Operator Nexus
Important
Actuellement, cette fonctionnalité est uniquement disponible en tant que version préliminaire. Les préversions sont à votre disposition, à condition que vous acceptiez les conditions d’utilisation supplémentaires.
Cet article décrit la prise en charge de la fiabilité dans Azure Operator Nexus et couvre la résilience intrarégionale avec les zones de disponibilité. Pour obtenir une vue d’ensemble plus détaillée de la fiabilité dans Azure, consultez Fiabilité Azure.
Prise en charge des zones de disponibilité
Les zones de disponibilité sont des groupes de centres de données physiquement distincts au sein de chaque région Azure. En cas de défaillance d’une zone, les services peuvent basculer sur l’une des zones restantes.
Pour plus d’informations sur les zones de disponibilité dans Azure, consultez Que sont les zones de disponibilité ?.
Azure Operator Nexus offre des déploiements redondants des zones de disponibilité par défaut. Les composants d’Operator Nexus comme le gestionnaire de cluster et le contrôleur de structure réseau, sont tous déployés sur un cluster Azure Kubernetes Service (AKS) activé avec des zones de disponibilité. D’autres dépendances de service, telles que le service de compte de stockage et KeyVault, sont également configurées avec une redondance des zones de disponibilité.
Notes
L’instance Operator Nexus locale implémente une conception à plusieurs racks qui fournit une redondance physique à tous les niveaux de la pile. Chaque rack est conçu comme un domaine de défaillance ou une zone Nexus. Les charges de travail client peuvent être déployées sur plusieurs racks/nœuds, offrant essentiellement une expérience de zone de multi disponibilité similaire.
Expérience de défaillance de zone de disponibilité Azure
En cas de défaillance de zone de disponibilité, les appels d’API sur le cluster et les fournisseurs de ressources continuent de fonctionner sans interruption. Il n’y aura aucun impact sur les charges de travail de tenant locales en cours d’exécution ou sur la possibilité de créer des charges de travail de tenant. En outre, aucune perte de données ne doit se produire, car la résilience d’Operator Nexus et d’autres types de ressources est garantie.
Prise en charge du basculement de zone de disponibilité Azure
En cas de défaillance d’une zone de disponibilité, la reconnexion à une autre zone de disponibilité Azure est automatique et ne nécessite aucune interaction de la part de l’utilisateur.
Disponibilité sur les déploiements d’instances Operator Nexus
La responsabilité de la garantie de la disponibilité dans les déploiements de charges de travail Azure Operator Nexus est partagée. Comme indiqué dans la section précédente, les ressources basées sur Operator Nexus AKS sont déployées avec une redondance des zones de disponibilité. Dans cette section, nous examinons les meilleures pratiques pour la disponibilité des charges de travail locales.
En général, les objectifs de disponibilité sont atteints par le biais de déploiements locaux et géoredondants.
Zone Nexus : mécanisme de redondance des charges de travail locales
Les instances locales Operator Nexus ont une conception à plusieurs racks qui fournit une redondance physique à tous les niveaux de la pile. Chaque rack est désigné comme domaine d’échec, et par conséquent, peut être configuré en tant que zone Nexus où ces zones peuvent (et de préférence, doivent) être utilisées pour les déploiements de charges de travail redondantes locales.
Instance Nexus : mécanisme de redondance géographique des charges de travail
Les instances Nexus locales sont hébergées dans une région Azure spécifique. Comme indiqué précédemment, les services Azure utilisés et les ressources Nexus sont déployés dans plusieurs zones de disponibilité de cette région Azure.
Les instances Nexus qui sont distribuées géographiquement, c’est-à-dire qui ne se trouvent pas dans le même centre de données d’opérateur (il est possible que ce ne soit pas la même région géographique), et qui sont hébergées dans différentes régions Azure doivent être utilisées pour déployer de manière redondante des charges de travail pour la géoredondance.
Avertissement
Le déploiement de charges de travail sur deux instances Nexus distribuées géographiquement, par exemple, est insuffisant pour obtenir une véritable géo-redondance, sauf si les clusters Nexus géo-redondants sont hébergés dans différentes régions Azure.
Dans le cas peu probable où une région Azure devient indisponible, les services Azure ainsi que les ressources Nexus de cette région ne seront pas disponibles. Bien que sans impact sur l’exécution des charges de travail, cela empêche des fonctionnalités telles que le démarrage de nouvelles charges de travail, l’analytique, etc.
Plusieurs instances Nexus dans le même emplacement géographique
Il existe des scénarios dans lesquels plusieurs instances Nexus doivent être déployées dans le même emplacement géographique. Évidemment, il n’est pas possible d’obtenir une géoredondance des charges de travail si elles sont déployées sur des instances Nexus dans le même emplacement géographique.
Outre la disponibilité, la résilience et la possibilité de récupérer en cas de défaillance constituent un facteur à prendre en compte dans la conception de la fiabilité. Pour réussir la récupération après des défaillances et la capacité à atteindre les objectifs de délai de récupération, nous devons limiter le rayon d’impact des défaillances. Dans le cas où plusieurs instances Nexus sont déployées dans le même emplacement géographique, la conception résiliente exige que ces instances Nexus soient hébergées dans différentes régions Azure. Ainsi, lorsqu’une défaillance survient dans une région Azure, son impact est limité à une instance Nexus.