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é Azure sont au moins trois groupes physiquement distincts de centres de données dans chaque région Azure. Les centres de données de chaque zone sont équipés d’une infrastructure réseau, de refroidissement et d’alimentation indépendante. En cas de défaillance de zone locale, les zones de disponibilité sont conçues de telle sorte que si une zone est affectée, les services, la capacité et la haute disponibilité de la région sont pris en charge par les deux autres zones.
Les défaillances sont aussi bien des défaillances logicielles et matérielles que des événements de type tremblements de terre, inondations et incendies. La tolérance aux défaillances est obtenue par la redondance et l’isolation logique des services Azure. Pour obtenir des informations détaillées sur les zones de disponibilité dans Azure, consultez Régions et zones de disponibilité.
Les services Azure compatibles avec les zones de disponibilité sont conçus pour fournir le niveau approprié de fiabilité et de flexibilité. Ils peuvent être configurés de deux façons. Un service peut être redondant interzone, avec une réplication automatique entre les zones, ou zonal, avec des instances épinglées à une zone spécifique. Vous pouvez également combiner ces approches. Pour plus d’informations sur l’architecture zonale et redondante interzone, consultez Recommandations relatives à l’utilisation de zones de disponibilité et de régions.
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.