Décrire les fonctionnalités de haute disponibilité et de reprise d’activité d’Azure pour les machines virtuelles Azure
Azure propose trois options principales pour améliorer la disponibilité des déploiements IaaS :
Groupes à haute disponibilité
Zones de disponibilité
Azure Site Recovery
Ces trois options sont externes à la machine virtuelle et ne savent pas quel type de charge de travail y est exécuté.
Groupes à haute disponibilité
Les groupes à haute disponibilité assurent le bon fonctionnement des machines virtuelles qui sont confrontées aux opérations de maintenance liées à Azure et aux points de défaillance uniques dans un centre de données unique. Ils comptent parmi les fonctionnalités de disponibilité les plus anciennes de la plateforme Azure et peuvent être considérés comme des règles anti-affinité pour vos machines virtuelles. Ainsi, si vous avez deux machines virtuelles SQL Server dans un groupe à haute disponibilité ou une paire dans une configuration de copie des journaux de transaction, vous avez la garantie qu’elles ne s’exécuteront jamais sur le même serveur physique.
Les groupes à haute disponibilité sont séparés en domaines d’erreur et domaines de mise à jour pour prendre en charge les mises à jour de l’infrastructure Azure sous-jacente. Les domaines d’erreur sont des ensembles de serveurs au sein d’un centre de données qui utilisent la même source d’alimentation et le même réseau. Vous pouvez avoir jusqu’à trois domaines d’erreur dans un centre de données, comme le montre l’image ci-dessous (FD 0, 1 et 2). Les domaines de mise à jour, désignés par UD dans l’image ci-dessous, indiquent les groupes de machines virtuelles et les équipements physiques sous-jacents pouvant être redémarrés en même temps. Les différents domaines de mise à jour garantissent la séparation.
Les groupes à haute disponibilité et les zones de disponibilité ne protègent pas contre les pannes dans l’invité, par exemple, un incident SGBDR ou du système d’exploitation. C’est pourquoi vous devez implémenter des solutions supplémentaires comme des groupes de disponibilité ou des instances de cluster de basculement pour atteindre vos RTO et RPO. Les groupes à haute disponibilité et les zones de disponibilité sont conçus pour limiter l’impact des problèmes environnementaux au niveau d’Azure, notamment les défaillances du centre de données, les défaillances matérielles physiques, les pannes réseau et les coupures d’alimentation.
Pour une application multiniveau, vous devez placer chaque niveau de l’application dans son propre groupe à haute disponibilité. Par exemple, si vous créez une application web dotée d’un back-end SQL Server avec Active Directory Domain Services (AD DS), vous devez créer un groupe à haute disponibilité pour chaque niveau (web, base de données et AD DS).
Les groupes à haute disponibilité ne sont pas la seule façon de séparer des machines virtuelles IaaS. Azure fournit également des zones de disponibilité, mais vous ne pouvez pas combiner les deux. Vous devez choisir l’une ou l’autre de ces méthodes.
Zones de disponibilité
Les zones de disponibilité tiennent compte de l’échec au niveau du centre de données dans Azure. Chaque région Azure est composée de nombreux centres de données avec des connexions réseau à faible latence. Quand vous déployez des ressources de machine virtuelle dans une région qui prend en charge les zones de disponibilité, vous avez la possibilité de déployer ces ressources dans la Zone 1, 2 ou 3. Une zone est un emplacement physique unique, c’est-à-dire un centre de données dans une région Azure.
Les numéros de zone sont des représentations logiques. Par exemple, si deux abonnés Azure déploient une machine virtuelle dans la Zone 1 dans leurs propres abonnements, cela ne signifie pas que ces machines virtuelles existent dans le même centre de données Azure physique. Par ailleurs, en raison de la distance, une latence supplémentaire peut être introduite dans les déploiements zonaux. Vous devez tester la latence entre vos machines virtuelles pour vérifier qu’elle répond à vos objectifs de performances. Dans la plupart des cas, la latence aller-retour est inférieure à 1 milliseconde, ce qui prend en charge le déplacement synchrone des données dans des fonctionnalités telles que les groupes de disponibilité. Vous pouvez également déployer Azure SQL Database dans des zones de disponibilité.
Azure Site Recovery
Azure Site Recovery offre une disponibilité améliorée pour les machines virtuelles au niveau Azure et peut fonctionner avec des machines virtuelles hébergeant SQL Server. Azure Site Recovery réplique une machine virtuelle d’une région Azure vers une autre pour créer une solution de reprise d’activité pour cette machine virtuelle. Comme indiqué précédemment, cette fonctionnalité ne sait pas que SQL Server s’exécute sur la machine virtuelle et ne sait rien des transactions. Bien qu’Azure Site Recovery puisse atteindre le RTO, il peut ne pas atteindre le RPO parce qu’il ne tient pas compte de l’emplacement des données dans SQL Server. Azure Site Recovery affiche un RTO mensuel de deux heures. Bien que les professionnels des bases de données préfèrent en majorité utiliser une méthode basée sur les bases de données pour la reprise d’activité, Azure Site Recovery fonctionne bien s’il répond à vos besoins en termes de RTO et de RPO.