Fiabilité dans Elastic SAN
Cet article décrit la prise en charge de la fiabilité dans Azure Elastic SAN. Il couvre à la fois la résilience régionale avec les zones de disponibilité, la récupération d'urgence et la continuité des activités.
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 Elastic SAN prend en charge le déploiement de zones de disponibilité avec un stockage localement redondant (LRS) et un déploiement régional avec un stockage redondant interzone (ZRS).
Prérequis
LRS et ZRS d’Elastic SAN sont actuellement disponibles uniquement dans un sous-ensemble de régions. Pour obtenir la liste des régions, consultez Cibles de mise à l’échelle pour Elastic SAN.
Créer une ressource à l’aide de zones de disponibilité
Pour créer un Elastic SAN avec une zone de disponibilité activée, consultez Déployer un Elastic SAN.
Expérience en cas de panne de zone
Lors du déploiement d’un Elastic SAN, si vous sélectionnez ZRS pour l’option de redondance de votre SAN, le basculement zonal est pris en charge par la plateforme sans intervention manuelle. Un Elastic SAN utilisant ZRS est conçu pour auto-guérir et se rééquilibrer pour tirer parti automatiquement des zones saines.
Si vous avez déployé un Elastic SAN utilisant LRS, vous devrez peut-être déployer un nouveau SAN à l’aide d’instantanés exportés vers des disques managés.
Conception à faible latence
Les différences de latence entre un Elastic SAN sur LRS et un Elastic SAN sur ZRS ne sont pas particulièrement élevées. Toutefois, pour les charges de travail sensibles aux pics de latence, envisagez un Elastic SAN sur LRS, car il offre la latence la plus faible.
Migration de zones de disponibilité
Pour migrer un Elastic SAN sur les RS vers ZRS, vous devez créer un instantané des volumes de votre Elastic SAN, les exporter vers des captures instantanées de disque managé, déployer un Elastic SAN sur ZRS, puis créer des volumes sur le SAN sur ZRS à l’aide de ces instantanés de disque. Pour savoir comment utiliser des instantanés (préversion), consultez Instantanés de volumes Azure Elastic SAN (préversion).
Récupération d'urgence et continuité d’activité
La récupération d’urgence (DR) consiste à récupérer après des évènements à fort impact, comme des catastrophes naturelles ou des échecs de déploiements, qui entraînent un temps d’arrêt et une perte de données. Quelle qu’en soit la cause, la meilleure solution en cas de sinistre est d’avoir un plan de DR bien défini et testé, et une conception d’application qui prend activement en charge la DR. Avant de commencer à réfléchir à la création de votre plan de récupération d’urgence, consultez Suggestions pour la conception d’une stratégie de récupération d’urgence.
En ce qui concerne la récupération d’urgence (DR), Microsoft utilise le modèle de responsabilité partagée. Dans un modèle de responsabilité partagée, Microsoft garantit que l’infrastructure de référence et les services de plateforme sont disponibles. En même temps, de nombreux services Azure ne répliquent pas automatiquement les données ou reviennent d’une région défaillante pour effectuer une réplication croisée vers une autre région activée. Pour ces services, vous êtes responsable de la configuration d’un plan de récupération d’urgence qui fonctionne pour votre charge de travail. La plupart des services qui s’exécutent sur des offres PaaS (Platform as a Service) Azure fournissent des fonctionnalités et des conseils pour prendre en charge la récupération d’urgence et vous pouvez utiliser fonctionnalités spécifiques au service pour prendre en charge la récupération rapide pour vous aider à développer votre plan de récupération d’urgence.
Récupération d’urgence à région unique et multirégion
Pour Azure Elastic SAN, vous êtes responsable de l’expérience de récupération d’urgence. Vous pouvez prendre des instantanés de vos volumes et les exporter vers des instantanés de disque managé. Ensuite, vous pouvez copier un instantané incrémentiel vers une nouvelle région pour stocker vos données dans une région autre que la région dans laquelle se trouve votre Elastic SAN. Vous devez exporter vers des régions géographiquement éloignées de votre région primaire pour réduire la possibilité que plusieurs régions soient affectées en raison d’un sinistre.
Détection, notification et gestion des pannes
Vous trouverez des déclarations de panne dans Azure Service Health - Microsoft Azure.
Capacité et résilience proactive de la récupération d’urgence
Microsoft et ses clients opèrent selon le modèle de responsabilité partagée. La responsabilité partagée implique que pour la récupération d’urgence activée par le client (services responsables du client), vous devez traiter la récupération d’urgence pour tout service que vous déployez et contrôlez. Vous devez prévalider n’importe quel service que vous déployez avec Elastic SAN. Pour vous assurer que la récupération est proactive, vous devez toujours prédéployer des secondaires, car il n’existe aucune garantie de capacité au moment de l’impact pour ceux qui n’ont pas fait de préallocation.