Migrer des charges de travail de serveur flexible MySQL et Azure Kubernetes Service (AKS) vers la prise en charge de la zone de disponibilité
Ce guide explique comment migrer une charge de travail Serveur flexible MySQL et Azure Kubernetes Service pour bénéficier de la prise en charge de la zone de disponibilité sur tous les services dépendants. Pour obtenir la liste complète de toutes les dépendances de charge de travail, consultez Dépendances de service des charges de travail.
La prise en charge des zones de disponibilité pour cette charge de travail doit être activée lors de la création de votre cluster AKS ou de votre serveur flexible MySQL. Si vous souhaitez prendre en charge une zone de disponibilité pour un cluster AKS et un serveur flexible MySQL existant, vous devez redéployer ces ressources.
Ces conseils de migration se concentrent principalement sur les considérations relatives à l’infrastructure et à la disponibilité de l’exécution de l’architecture suivante sur Azure :
Dépendances de service des charges de travail
Pour fournir une prise en charge complète des charges de travail pour les zones de disponibilité, chaque dépendance de service de la charge de travail doit prendre en charge les zones de disponibilité.
Il existe deux types d’approches des services pris en charge par la zone de disponibilité : zonale ou redondante interzone. La plupart des services prennent en charge l’un ou l’autre. Toutefois, dans certains cas, il existe des options pour choisir une ressource zonale ou redondante interzone pour ce service. Nous indiquons quels services prennent en charge les ressources zonales et redondantes interzone dans les suggestions suivantes. Nous indiquons également quels services sont globaux et régionaux.
L’architecture de charge de travail AKS et MySQL se compose des dépendances de composants suivantes :
Azure Kubernetes Service (AKS)
Zonal : le pool de nœuds système et les pools de nœuds utilisateur sont zonaux lorsque vous préélectionnez les zones dans lesquelles les pools de nœuds sont déployés pendant la création. Nous vous recommandons de pré-sélectionner les trois zones pour une meilleure résilience. D’autres pools de nœuds utilisateur qui prennent en charge les zones de disponibilité peuvent être ajoutés à un cluster AKS existant et en fournissant une valeur pour le paramètre
zones.Redondant interzone : les composants du plan de contrôle Kubernetes tels que etcd, le serveur d’API, le Planificateur et le Gestionnaire de contrôleurs sont automatiquement répliqués ou distribués entre les différentes zones.
Remarque
Pour activer la redondance interzone des composants du plan de contrôle de cluster AKS, vous devez définir votre pool de nœuds système par défaut avec des zones lorsque vous créez un cluster AKS. L’ajout de pools de nœuds zonaux à un cluster AKS non zonal existant ne rend pas la zone du cluster AKS redondante interzone, car cette action ne distribue pas les composants du plan de contrôle entre les zones a posteriori.
Serveur flexible Azure Database pour MySQL
Zonal : le mode de disponibilité zonal signifie qu’un serveur de secours est toujours disponible dans la même zone que le serveur principal. Bien que cette option réduise le temps de basculement et la latence réseau, elle est moins résiliente en raison d’une panne de zone unique impactant les serveurs principaux et de secours.
Redondant interzone : le mode de disponibilité redondant interzone signifie qu’un serveur de secours est toujours disponible dans une autre zone dans la même région que le serveur principal. Deux zones sont activées pour la redondance de zone pour les serveurs principaux et de secours. Nous recommandons cette configuration pour une meilleure résilience.
Azure Standard Load Balancer ou Azure Application Gateway
Standard Load Balancer
Pour comprendre les considérations relatives aux ressources Standard Load Balancer, consultez Load Balancer et zones de disponibilité.
Redondant interzone : choisir la redondance interzone est la méthode recommandée pour configurer votre adresse IP front-end avec votre instance Load Balancer existante. Le serveur frontal redondant interzone correspond au pool principal du cluster AKS, qui est distribué entre plusieurs zones.
Zonal : si vous épinglez vos pools de nœuds à des zones spécifiques telles que la zone 1 et 2, vous pouvez pré-sélectionner la zone 1 et 2 pour votre adresse IP front-end dans l’instance Load Balancer existante. Vous voudrez peut-être épingler vos pools de nœuds à des zones spécifiques en raison de la disponibilité de séries de références SKU de machine virtuelle spécialisées telles que la série M.
Azure Application Gateway
L’utilisation du module complémentaire Contrôleur d’entrée Application Gateway avec votre cluster AKS est prise en charge uniquement sur les références SKU Application Gateway v2 (Standard et WAF). Pour d’autres considérations relatives à Azure Application Gateway, consultez Mise à l’échelle d’Application Gateway v2 et WAF v2.
Zonal : pour utiliser les avantages des zones de disponibilité, nous vous recommandons de créer la ressource Application Gateway dans plusieurs zones, telles que les zones 1, 2 et 3. Sélectionnez les trois zones pour une meilleure stratégie de résilience intrarégion. Toutefois, pour correspondre à vos pools de nœuds principaux, vous pouvez épingler vos pools de nœuds à des zones spécifiques en pré-sélectionnant les zones 1 et 2 lors de la création de votre ressource App Gateway. Vous voudrez peut-être épingler vos pools de nœuds à des zones spécifiques en raison de la disponibilité de séries de références SKU de machine virtuelle spécialisées telles que M-series.
Stockage redondant interzone (ZRS)
Nous vous recommandons de configurer votre cluster AKS avec des disques ZRS managés, car ce sont des ressources redondantes interzone. Les volumes peuvent être planifiés sur toutes les zones.
Kubernetes prend en charge les zones de disponibilité Azure depuis la version 1.12. Vous pouvez déployer un objet
PersistentVolumeClaimréférençant un disque managé Azure dans un cluster AKS multizone. Kubernetes se chargera de planifier tout pod qui réclame ce PVC dans la zone de disponibilité adéquate.Pour Azure Database pour SQL, nous vous recommandons d’héberger les données et les fichiers journaux dans un stockage redondant interzone (ZRS). Ces fichiers sont répliqués sur le serveur de secours via la réplication de niveau stockage disponible avec le stockage redondant interzone.
Pare-feu Azure
Zonal : pour utiliser les avantages des zones de disponibilité, nous vous recommandons de créer la ressource Pare-feu Azure dans plusieurs zones, telles que les zones 1, 2 et 3. Nous vous recommandons de sélectionner les trois zones afin d’obtenir la meilleure stratégie de résilience intra-région.
Azure Bastion
Régional : Azure Bastion est déployé sur des réseaux virtuels ou des réseaux virtuels appairés, et il est associé à une région Azure. Pour plus d’informations, consultez Fiabilité dans Azure Bastion.
Azure Container Registry (ACR)
Redondant interzone : nous vous recommandons de créer un registre redondant interzone dans le niveau de service Premium. Vous pouvez également créer un réplica de registre redondant interzone en définissant la propriété zoneRedundancy du réplica. Pour savoir comment activer la redondance de zone pour votre ACR, consultez Activer la redondance de zone dans Azure Container Registry à des fins de résilience et de haute disponibilité.
Cache Azure pour Redis
Redondant interzone : Azure Cache pour Redis prend en charge les configurations redondantes interzones dans les niveaux Premium et Entreprise. Un cache redondant interzone place ses nœuds dans différentes zones de disponibilité au sein de la même région.
Microsoft Entra ID
Global : Microsoft Entra ID est un service mondial avec plusieurs niveaux de redondance interne et de récupération automatique. Microsoft Entra ID est déployé dans plus de 30 centres de données du monde entier qui fournissent des zones de disponibilité lorsqu’elles sont présentes. Ce nombre augmente rapidement à mesure que d’autres régions sont déployées.
Azure Key Vault
Régional : Azure Key Vault est déployé dans une région. Pour maintenir une durabilité élevée de vos clés et secrets, le contenu de votre coffre de clés est répliqué dans la région ainsi que dans une région secondaire au sein de la même zone géographique.
Redondant interzone : pour les régions Azure avec des zones de disponibilité et aucune paire de régions, Key Vault utilise le stockage redondant interzone (ZRS) pour répliquer le contenu de votre coffre de clés trois fois dans l’emplacement/la région unique.
Considérations relatives à la charge de travail
Azure Kubernetes Service (AKS)
Les pods peuvent communiquer avec d’autres pods, quel que soit le nœud ou la zone de disponibilité où le pod atterrit sur le nœud. Votre application peut rencontrer un temps de réponse plus élevé si les pods se trouvent dans des zones de disponibilité différentes. Bien que les latences aller-retour supplémentaires entre les pods soient censées être comprises dans une plage acceptable pour la plupart des applications, il existe des scénarios d’application qui nécessitent une faible latence, en particulier pour un modèle de communication bavard entre les pods.
Nous vous recommandons de tester votre application pour vous assurer qu’elle fonctionne correctement dans les zones de disponibilité.
Pour des raisons de performances avec une latence si faible, les pods peuvent être colocalisés dans le même centre de données au sein de la même zone de disponibilité. Pour colocaliser des pods dans le même centre de données au sein de la même zone de disponibilité, vous pouvez créer des pools de nœuds utilisateur avec une zone unique et un groupe de placement de proximité. Vous pouvez ajouter un groupe de placement de proximité à un cluster AKS existant en créant un pool de nœuds d’agent et en spécifiant le groupe de placement de proximité. Utilisez les contraintes de répartition de la topologie des pods pour contrôler la répartition des pods dans votre cluster AKS entre les zones de disponibilité, les nœuds et les régions.
Une fois que les pods qui nécessitent une communication à faible latence sont colocalisés dans la même zone de disponibilité, les communications entre les pods ne sont pas directes. Au lieu de cela, elles sont envoyées via un service qui définit un ensemble logique de pods dans votre cluster AKS. Les pods peuvent être configurés pour communiquer avec AKS et la communication avec le service est automatiquement équilibrée sur tous les pods membres du service.
Pour tirer parti des zones de disponibilité, les pools de nœuds contiennent des machines virtuelles sous-jacentes qui sont des ressources zonales. Pour prendre en charge les applications qui ont des demandes de calcul ou de stockage différentes, vous pouvez créer des pools de nœuds utilisateur avec des tailles de machine virtuelle spécifiques lorsque vous créez le pool de nœuds utilisateur.
Par exemple, vous pouvez décider
Standard_M32mssousM-seriespour vos nœuds utilisateur, car les microservices de votre application nécessitent un débit élevé, une faible latence et des tailles de machines virtuelles à mémoire optimisée qui fournissent un nombre élevé de processeurs virtuels et de grandes quantités de mémoire. Selon la région de déploiement, lorsque vous sélectionnez la taille de machine virtuelle dans le portail Azure, vous pouvez constater que cette taille de machine virtuelle est prise en charge uniquement dans les zones 1 et 2. Vous pouvez accepter cette configuration de résilience comme compromis pour bénéficier de performances élevées.Vous ne pouvez pas changer la taille des machines virtuelles d’un pool de nœuds, une fois que vous l’avez créé. Pour plus d’informations sur les limitations du pool de nœuds, consultez Limitations.
Serveur flexible Azure Database pour MySQL
L’implication du déploiement de vos pools de nœuds dans des zones spécifiques, telles que les zones 1 et 2, est que toutes les dépendances de service de votre cluster AKS doivent également prendre en charge les zones 1 et 2. Dans cette architecture de charge de travail, votre cluster AKS a une dépendance de service sur les Serveurs flexibles Azure Database pour MySQL avec résilience de zone. Vous devez sélectionner la zone 1 pour votre serveur principal et la zone 2 pour que votre serveur de secours soit colocalisé avec vos pools de nœuds utilisateur AKS.
Cache Azure pour Redis
Azure Cache pour Redis distribue les nœuds dans un cache redondant interzone de manière alternée sur les zones de disponibilité sélectionnées.
Vous ne pouvez pas mettre à jour un cache Premium existant pour qu’il utilise la redondance de zone. Pour utiliser la redondance de zone, vous devez recréer le cache Azure Cache pour Redis.
Pour obtenir une résilience optimale, nous vous recommandons de créer votre cache Azure Cache pour Redis avec trois réplicas ou plus afin de pouvoir distribuer les réplicas sur trois zones de disponibilité.
Considérations relatives à la récupération d’urgence
Les zones de disponibilité sont utilisées pour une meilleure résilience afin d’obtenir une haute disponibilité de votre charge de travail dans la région primaire de votre déploiement.
La récupération d’urgence se compose des opérations de récupération et des pratiques définies dans votre plan de continuité d’activité. Votre plan de continuité d’activité traite à la fois de la façon dont votre charge de travail se rétablit lors d’un événement perturbant et de la façon dont elle est entièrement récupérée après l’événement. Envisagez d’étendre votre déploiement à une autre région.
Pour votre couche Application, consultez les considérations relatives à la continuité d’activité et à la récupération d’urgence pour AKS dans cet article.
Envisagez d’exécuter plusieurs clusters AKS dans d’autres régions. L’autre région peut utiliser une région jumelée secondaire. Ou, lorsqu’il n’existe pas de jumelage de région pour votre région primaire, vous pouvez sélectionner une autre région en fonction de vos besoins en termes de services, de capacité, de proximité géographique et de souveraineté des données. Consultez le guide de décision des régions Azure. Passez également en revue le modèle d’empreintes de déploiement.
Vous avez la possibilité de configurer les modes actif-actif, actif-veille, actif-passif pour vos clusters AKS.
Pour votre couche Données, les fonctionnalités de continuité d’activité et de reprise d’activité incluent des sauvegardes géoredondantes offrant la possibilité de lancer une géorestauration et le déploiement de réplicas en lecture dans une autre région.
Lors d’une panne, vous devez décider s’il faut lancer une récupération. Vous devez lancer des opérations de récupération uniquement lorsque la panne risque de durer plus longtemps que l’objectif de délai de récupération (RTO) de votre charge de travail. Sinon, vous attendez la récupération du service en vérifiant le statut du service dans le tableau de bord Azure Service Health. Dans le panneau Service Health du portail Azure, vous pouvez afficher toutes les notifications associées à votre abonnement.
Lorsque vous lancez la récupération avec la fonctionnalité de géorestauration dans Azure Database pour MySQL, un nouveau serveur de base de données est créé à l’aide de données de sauvegarde répliquées à partir d’une autre région.
Étapes suivantes
Pour en savoir plus :