Expliquer les options de haute disponibilité et de reprise d’activité
En plus de sa haute disponibilité intégrée, la plateforme Azure offre deux options pour fournir des niveaux plus élevés de disponibilité pour les charges de travail des machines virtuelles et PaaS. Les zones de disponibilité et les groupes à haute disponibilité protègent vos charges de travail contre les activités de maintenance planifiée et les éventuelles défaillances matérielles.
Options de haute disponibilité
La plupart des solutions de haute disponibilité SQL Server sont disponibles sur des machines virtuelles Azure. Dans une solution Azure uniquement, le système HADR s’exécute dans Azure. Dans une configuration hybride, une partie de la solution est exécutée dans Azure, tandis que l’autre est exécutée localement dans votre organisation. La flexibilité de l’environnement Azure vous permet de migrer partiellement ou totalement vers Azure afin de répondre aux exigences HADR et en termes de budget de vos systèmes de base de données SQL Server.
Zones de disponibilité
Les zones de disponibilité sont des emplacements physiques uniques dans une région. Chaque zone de disponibilité est composée d'un ou de plusieurs centres de données équipés d'une alimentation, d'un système de refroidissement et d'un réseau indépendants. Dans les régions Azure qui prennent en charge les zones de disponibilité, vous pouvez spécifier dans quelle zone vous voulez que la machine virtuelle réside quand vous choisissez d’utiliser des zones disponibles lors de la création de la machine virtuelle. Il existe trois zones de disponibilité dans chaque région Azure prise en charge. Les zones de disponibilité assurent une haute disponibilité en cas de défaillance du centre de données quand vous déployez plusieurs machines virtuelles dans différentes zones. De plus, elles offrent aussi à Microsoft un moyen d’effectuer des opérations de maintenance (en utilisant un regroupement appelé « domaine de mise à jour ») au sein de chaque région, en mettant à jour une seule zone à un moment donné. Vous pouvez répartir votre écosystème de machines virtuelles dans trois zones au sein de la région. L’utilisation de zones de disponibilité conjointement avec vos machines virtuelles Azure augmente votre durée de bon fonctionnement à quatre neuf (99,99 %), ce qui correspond à un maximum de 52,60 minutes de temps d’arrêt par an. Vous pouvez identifier les régions Azure qui prennent en charge les zones de disponibilité sur le site docs.microsoft.com. Si des zones de disponibilité sont disponibles dans votre région et si votre application peut prendre en charge la latence inter-zones minimale, les zones de disponibilité pourront fournir le niveau de disponibilité le plus élevé pour votre application.
Dans l’image ci-dessus, vous pouvez voir la configuration des zones de disponibilité. Quand vous déployez une machine virtuelle dans une région dotée de zones de disponibilité, vous êtes invité à choisir de la déployer dans la zone 1, 2 et 3. Ces zones sont des représentations logiques des centres de données physiques, ce qui signifie qu’un déploiement dans la zone 1 dans un premier abonnement n’implique pas que la zone 1 représente le même centre de données dans un autre abonnement.
Groupes à haute disponibilité
Les groupes à haute disponibilité sont similaires aux zones de disponibilité, à l’exception près qu’au lieu de répartir les charges de travail entre les centres de données d’une région, ils les répartissent entre les serveurs et les racks d’un centre de données. Étant donné que presque toutes les charges de travail sont virtuelles dans Azure, vous pouvez utiliser des groupes à haute disponibilité pour veiller à ce que les deux machines virtuelles contenant les membres de votre groupe de disponibilité Always On ne s’exécutent pas sur le même hôte physique. Les groupes à haute disponibilité peuvent fournir jusqu’à 99,95 % de disponibilité. Vous devez les utiliser en l’absence de zones de disponibilité disponibles dans une région ou quand une application ne peut pas tolérer de latence intra-zone.
Groupes de disponibilité Always On
Vous pouvez implémenter des groupes de disponibilité Always On entre deux instances de SQL Server ou plus (neuf au maximum), s’exécutant sur des machines virtuelles Azure ou entre un centre de données local et Azure. Dans un groupe de disponibilité, les transactions de base de données sont validées sur le réplica principal, puis envoyées de manière synchrone ou asynchrone à tous les réplicas secondaires. La distance physique entre les serveurs (c’est-à-dire, s’ils se trouvent ou non dans la même région Azure) détermine le mode de disponibilité à choisir. En règle générale, si la charge de travail nécessite la latence la plus faible possible ou si les réplicas secondaires sont répartis géographiquement, le mode de disponibilité asynchrone est recommandé. Si les réplicas se trouvent dans la même région Azure et que les applications peuvent supporter un certain niveau de latence, le mode de validation synchrone est à considérer. Le mode synchrone permet de veiller à ce que chaque transaction soit validée sur un ou plusieurs réplicas secondaires avant de permettre à l’application de continuer. Les groupes de disponibilité Always On offrent à la fois la haute disponibilité et la reprise d’activité après sinistre, car un seul groupe de disponibilité peut prendre en charge des modes de disponibilité synchrones et asynchrones. L’unité de basculement d’un groupe de disponibilité est un groupe de bases de données, et non l’ensemble de l’instance.
Il est aussi possible d’utiliser des groupes de disponibilité Always On à des fins de reprise d’activité. Vous pouvez implémenter jusqu’à neuf réplicas d’une base de données dans toutes les régions Azure, puis étendre encore cette architecture en utilisant des groupes de disponibilité distribués. Les groupes de disponibilité garantissent qu’une copie viable de vos bases de données se trouve dans un autre emplacement en dehors de la région primaire. En procédant ainsi, vous veillez à ce que votre écosystème de données soit protégé contre les catastrophes naturelles et les erreurs humaines.
L’image ci-dessus illustre un diagramme logique d’un groupe de disponibilité Always On, exécuté sur un cluster de basculement Windows Server. Il comprend un réplica principal et quatre réplicas secondaires. Dans ce scénario, les cinq réplicas peuvent être synchrones ou combiner des réplicas synchrones et asynchrones. N’oubliez pas que l’unité de basculement est le groupe de bases de données, pas l’instance. Bien qu’une instance de cluster de basculement offre une haute disponibilité au niveau de l’instance, elle ne fournit pas de reprise d’activité.
Instances de cluster de basculement SQL Server
Si vous avez besoin de protéger l’ensemble de l’instance, vous pouvez utiliser une instance de cluster de basculement (FCI) SQL Server, qui offre une haute disponibilité pour une instance entière, dans une seule région. Une FCI n’offre pas de reprise d’activité après sinistre sans être combinée à une autre fonctionnalité comme des groupes de disponibilité ou la copie des journaux de transaction. Les FCI nécessitent aussi un stockage partagé pouvant être fourni sur Azure par le biais d’un stockage de fichiers partagés ou d’espaces de stockage direct sur Windows Server.
Pour les charges de travail Azure, les groupes de disponibilité sont la solution de prédilection pour les déploiements plus récents, car le besoin de stockage partagé des FCI augmente la complexité des déploiements. En revanche, pour les migrations à partir de solutions locales, une FCI peut être nécessaire pour la prise en charge des applications.
Options de reprise d’activité
Alors que la plateforme Azure offre par défaut une durée de bon fonctionnement s’élevant à 99,9 %, des incidents peuvent quand même se produire et affecter le fonctionnement des applications. Il est important de mettre en place un plan de reprise d’activité approprié quand vous effectuez une migration, quel qu’en soit le type. Azure nous propose plusieurs méthodes pour veiller à ce que votre instance de SQL Server sur une machine virtuelle soit protégé en cas d’incident. Cette protection comporte deux composants. Premièrement, il existe des options de la plateforme Azure comme le stockage géorépliqué pour les sauvegardes et Azure Site Recovery, une solution de reprise d’activité complète pour toutes vos charges de travail. Deuxièmement, il existe des offres SQL Server spécifiques comme les groupes de disponibilité et les sauvegardes.
Sauvegardes SQL Server natives
Les sauvegardes sont considérées comme la force vive de tout administrateur de base de données. Il en va de même avec une solution cloud. Avec SQL Server sur une machine virtuelle Azure, vous pouvez contrôler de façon précise le moment où les sauvegardes se produisent et l’emplacement auquel elles sont stockées. Vous pouvez utiliser les travaux de l’agent SQL pour sauvegarder directement vers une URL liée au stockage d’objets blob Azure. Azure offre la possibilité d’utiliser le stockage géoredondant (GRS) ou le stockage géoredondant avec accès en lecture (RA-GRS) pour veiller à ce que vos fichiers de sauvegarde soient stockés en toute sécurité dans tout le paysage géographique.
De plus, dans le cadre de la fourniture de services de machines virtuelles Azure SQL, vos sauvegardes peuvent être gérées automatiquement par la plateforme.
Sauvegarde Azure pour SQL Server
La solution Sauvegarde Azure nécessite l’installation d’un agent sur la machine virtuelle. Cet agent communique ensuite avec un service Azure qui gère les sauvegardes automatiques de vos bases de données SQL Server. Sauvegarde Azure offre aussi un emplacement central que vous pouvez utiliser pour gérer et superviser les sauvegardes afin d’en garantir la conformité à toutes les métriques RPO/RTO spécifiées.
Comme indiqué ci-dessus, Sauvegarde Azure est une solution de sauvegarde d’entreprise complète qui propose une conservation des données à long terme, une gestion automatisée et une protection renforcée des données. Cette option coûte plus cher que d’effectuer simplement vos propres sauvegardes ou d’utiliser le fournisseur de ressources Azure pour SQL Server, mais elle offre un ensemble de fonctionnalités de sauvegarde bien plus complet.
Azure Site Recovery
Azure Site Recovery est une solution peu onéreuse qui effectue une réplication au niveau du bloc de votre machine virtuelle Azure. Ce service propose différentes options, notamment la possibilité de tester et de vérifier votre stratégie de reprise d’activité. Cette solution convient mieux aux environnements sans état (par exemple, les serveurs web) qu’aux machines virtuelles de base de données transactionnelle.
Azure Site Recovery est pris en charge pour une utilisation avec SQL Server, mais n’oubliez pas que vous avez besoin de définir un point de récupération plus élevé, ce qui implique une perte potentielle. Dans ce cas, votre RTO correspondra grosso modo à votre RPO.
- La machine virtuelle est inscrite à Azure Site Recovery
- Les données sont répliquées en continu dans le cache.
- Le cache est répliqué sur le compte de stockage cible.
- Pendant le basculement, la machine virtuelle est ajoutée à l’environnement cible