Continuité d’activité et HADR pour SQL Server sur les machines virtuelles Azure

S’applique à : SQL Server sur la machine virtuelle Azure

Cet article compare et contraste les solutions de continuité d’activité Azure uniquement et hybrides que vous pouvez utiliser pour la haute disponibilité et récupération d’urgence (HADR) avec votre serveur SQL Server sur les machines virtuelles Azure (VM)

La continuité d’activité consiste à poursuivre votre activité en cas de sinistre, à planifier la récupération et à garantir la haute disponibilité de vos données. SQL Server sur des machines virtuelles Azure peut aider à réduire le coût d’une solution de base de données à haute disponibilité et reprise d’activité (HADR).

Remarque

Il est possible d’effectuer un lift-and-shift de votre solution d’instance de cluster de basculement et de groupe de disponibilité vers SQL Server sur des machines virtuelles Azure à l’aide d’Azure Migrate.

Vue d’ensemble

SQL Server sur les machines virtuelles Azure prend en charge les types de solutions suivants :

• Azure uniquement : le système HADR s’exécute dans Azure.
• 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. C’est à vous de vous assurer que vos systèmes de base de données disposent de capacités HADR qui répondent aux besoins de votre entreprise en matière d’objectif de délai de récupération (RTO), d’objectif de point de récupération (RPO) et de contrat de niveau de service (contrat SLA).

Les mécanismes de haute disponibilité intégrés fournis par Azure, comme le service de réparation pour les services cloud et la détection de la récupération après défaillance pour les machines virtuelles, ne garantit pas que vous puissiez respecter le SLO, RTO ou RPO. Bien que ces mécanismes contribuent à protéger la haute disponibilité de la machine virtuelle, ils ne protègent pas la disponibilité de SQL Server exécuté sur la machine virtuelle. Il est possible que l’instance de SQL Server échoue pendant que la machine virtuelle est en ligne et saine. Même les mécanismes haute disponibilité fournis par Azure tiennent compte des temps morts des machines virtuelles en raison d’événements tels que la récupération après une défaillance matérielle ou logicielle et des mises à niveau du système d’exploitation.

Fonctionnalités de continuité des activités

Le tableau suivant répertorie les fonctionnalités SQL Server Azure uniquement et hybrides que vous pouvez utiliser pour la haute disponibilité (HA), la récupération d’urgence (DR) ou les deux (HA/DR) :

Ces fonctionnalités SQL Server sont prises en charge pour la continuité d’activité dans une configuration Azure uniquement ou hybride. Certaines des options sont idéales pour la haute disponibilité et récupération d’urgence (HA/DR), la haute disponibilité (HA), tandis que d’autres sont utilisées pour la récupération d’urgence (DR).

fonctionnalités SQL Server	Option de haute disponibilité/récupération d’urgence	Détails
Groupes de disponibilité AlwaysOn	Haute disponibilité et récupération d’urgence	Fournit une protection au niveau de la base de données, augmente la haute disponibilité et récupération d’urgence en ajoutant des réplicas dans différentes zones de disponibilité ou régions.
Instances de cluster de basculement AlwaysOn	Haute disponibilité	Utilise le stockage partagé pour assurer la protection au niveau de l’instance. Augmentez la protection au niveau de la base de données et de l’instance en combinant les groupes de disponibilité.
Copie des journaux de transaction	Récupération d’urgence	La protection au niveau de la base de données pour la récupération d’urgence implique l’envoi de sauvegardes de journaux de transactions à partir d’un serveur principal et leur restauration sur un serveur secondaire. Un partage de fichiers Azure est nécessaire.
Sauvegarde et restauration SQL Server avec Stockage Blob Azure	Récupération d’urgence	Sauvegardes de base de données de production stockées dans le stockage Blob Azure pour la protection de la récupération d’urgence.
Azure Site Recovery	Récupération d’urgence	Solution de récupération d’urgence qui réplique les machines virtuelles d’un site principal vers un site secondaire.

Vous pouvez combiner les technologies pour implémenter une solution SQL Server qui offre des capacités de haute disponibilité et de récupération d’urgence. Selon la technologie que vous utilisez, un déploiement hybride peut nécessiter un tunnel VPN avec le réseau virtuel Azure. Bien que les technologies soient identiques, il peut y avoir des différences dans la façon dont elles sont configurées dans Azure ou dans une conception hybride.

Groupes de disponibilité (HADR)

La protection de votre SQL Server sur des machines virtuelles Azure au niveau de la base de données peut être effectuée à l’aide de groupes de disponibilité en tant que solution haute disponibilité et récupération d’urgence (HADR). Les réplicas exécutés sur les machines virtuelles Azure dans la même région offrent une haute disponibilité. Une machine virtuelle de contrôleur de domaine est nécessaire, car le clustering de basculement Windows nécessite un domaine Active Directory.

Pour commencer, consultez le didacticiel sur le groupe de disponibilité.

Pour une redondance, une disponibilité et une protection de récupération d’urgence plus élevées, les machines virtuelles Azure peuvent être déployées dans différentes zones de disponibilité, comme indiqué dans la vue d’ensemble des groupes de disponibilité. L’extension des réplicas de disponibilité exécutés dans plusieurs centres de données sur les machines virtuelles Azure renforce la couverture de la récupération d’urgence. Une solution inter-régions vous aide à vous protéger contre l’indisponibilité totale du site.

Au sein d’une région, tous les réplicas doivent se trouver dans le même service cloud et sur le même réseau virtuel. Étant donné que chaque région a un réseau virtuel distinct, ces solutions nécessitent une connectivité réseau-à-réseau. Pour plus d’informations, consultez Configurer une connexion réseau-à-réseau à l’aide du portail Azure. Pour obtenir des instructions détaillées, consultez Configurer un groupe de disponibilité AlwaysOn SQL Server dans différentes régions Azure.

Dans une configuration hybride, certains réplicas de disponibilité s’exécutant dans les machines virtuelles Azure et d’autres réplicas s’exécutant sur site pour la récupération d’urgence entre sites. Le site de production peut être local ou situé dans un centre de données Azure.

Étant donné que tous les réplicas de disponibilité doivent être dans le même cluster de basculement, ce dernier doit couvrir les deux réseaux (un cluster de basculement de plusieurs sous-réseaux). Cette configuration nécessite une connexion VPN entre Azure et le réseau local.

Pour une récupération d’urgence réussie de vos bases de données, vous devez également installer un contrôleur de domaine de réplica sur le site de récupération d’urgence. Pour commencer, consultez le didacticiel sur le groupe de disponibilité.

Instances de cluster de basculement (HA)

SQL Server sur les machines virtuelles Azure prend en charge les instances de cluster de basculement (FCI) et cette solution fournit une haute disponibilité au niveau de l’instance. Pour une protection accrue, vous pouvez créer une redondance au niveau de la base de données et de l’instance en créant des groupes de disponibilité sur des instances de cluster de basculement. La fonctionnalité d’instance de cluster de basculement nécessite un stockage partagé, et il existe cinq solutions qui fonctionnent avec SQL Server sur machines virtuelles Azure :

• Utilisation de disques partagés Azure pour Windows Server 2019. Les disques managés partagés sont un produit Azure qui permet d’attacher un disque managé à plusieurs machines virtuelles simultanément. Les machines virtuelles du cluster peuvent lire ou écrire sur le disque que vous avez attaché en fonction de la réservation choisie par l’application en cluster par le biais des réservations persistantes SCSI (SCSI PR). SCSI PR est une solution de stockage de norme industrielle dont tirent parti les applications qui s’exécutent sur un réseau de zone de stockage (SAN) local. L’activation des réservations persistantes SCSI sur un disque managé vous permet de migrer ces applications vers Azure en l’état.

• Utilisation d’espaces de stockage direct (S2D) pour fournir un réseau SAN virtuel basé sur un logiciel pour Windows Server 2016 et les versions ultérieures.

• Utilisation d’un partage de fichiers Premium pour Windows Server 2012 et versions ultérieures. Les partages de fichiers Premium offrent une faible latence, s’appuient sur des disques SSD, et sont entièrement pris en charge pour une utilisation avec une instance de cluster de basculement.

• Utilisation de stockage pris en charge par une solution de partenaire pour le clustering. Pour obtenir un exemple spécifique qui utilise SIOS DataKeeper, consultez l’entrée de blog sur le clustering de basculement et SIOS DataKeeper.

• Utilisation de stockage de bloc partagé pour une cible iSCSI distante par le biais d’Azure ExpressRoute. Par exemple, NPS (NetApp Private Storage) expose une cible iSCSI via ExpressRoute avec Equinix dans les machines virtuelles Azure.

Pour les solutions de stockage partagé et de réplication de données proposées par des partenaires Microsoft, contactez le fournisseur pour tout problème lié à l’accès aux données lors du basculement.

Pour commencer, préparez votre machine virtuelle pour FCI.

Copie des journaux de transaction (DR)

Une autre solution de récupération d’urgence dans Azure est la copie des journaux de transaction qui envoie automatiquement des sauvegardes de journaux de transactions d’une base de données primaire sur un serveur principal vers une ou plusieurs bases de données secondaires sur un serveur secondaire séparé. La configuration de la copie des journaux de transaction utilise un partage de fichiers Azure pour stocker les sauvegardes du journal des transactions.

Si vous devez configurer la copie des journaux de transaction dans un environnement hybride, un serveur se trouve sur une machine virtuelle Azure et l’autre est sur site pour la récupération d’urgence entre sites. La copie des journaux de transaction dépendant du partage de fichiers Windows, une connexion VPN entre le réseau virtuel Azure et le réseau local est requise.

Pour une récupération d’urgence réussie de vos bases de données, vous devez également installer un contrôleur de domaine de réplica sur le site de récupération d’urgence.

Sauvegarder et restaurer (DR)

La sauvegarde de vos bases de données de production est nécessaire pour la récupération d’urgence. Dans Azure, vous pouvez sauvegarder les bases de données directement dans le stockage d’objets blob dans un autre centre de données pour la récupération d’urgence.

Dans une solution hybride, les bases de données de production sur site peuvent être sauvegardées directement dans Stockage Blob Azure pour la récupération d’urgence.

Pour plus d’informations, consultez Sauvegarde et restauration pour SQL Server sur des machines virtuelles Azure.

Réplication à l’aide d’Azure Site Recovery (DR)

Azure Site Recovery peut être utilisé comme solution de récupération d’urgence dans Azure et dans une configuration hybride.

Dans Azure, l’instance SQL Server de production dans un centre de données Azure répliquée directement dans Stockage Azure dans un autre centre de données Azure pour la récupération d’urgence.

Pour les environnements hybrides, une instance SQL Server de production locale est répliquée directement dans Stockage Azure pour la récupération d’urgence.

Pour plus d’informations, consultez l’article Protéger SQL Server à l’aide de la récupération d’urgence SQL Server et d’Azure Site Recovery.

Réplica de récupération d’urgence gratuit dans Azure

Si vous avez Software Assurance, vous pouvez implémenter des plans de reprise d’activité hybride avec SQL Server sans entraîner des coûts de licence supplémentaires pour l’instance de reprise d’activité passive. Vous pouvez également bénéficier de réplicas DR gratuits avec une licence paiement à l’utilisation si tous les réplicas sont hébergés dans Azure.

Par exemple, vous pouvez avoir deux réplicas secondaires passifs gratuits lorsque les trois réplicas sont hébergés dans Azure :

Ou vous pouvez configurer un environnement de basculement hybride avec un réplica local principal sous licence, un réplica passif gratuit pour la haute disponibilité, un réplica passif gratuit pour la récupération d’urgence locale et un réplica passif gratuit pour la récupération d’urgence dans Azure :

Pour plus d’informations, consultez les conditions de licence du produit.

Pour activer cet avantage, accédez à votre ressource de machine virtuelle SQL Server. Sélectionnez Configurer sous Paramètres, puis choisissez l’option HA/DR sous Licence SQL Server, puis sélectionnez Appliquer pour enregistrer vos paramètres. Lorsque les trois réplicas sont hébergés dans Azure, les clients avec paiement à l’utilisation ont également le droit d’utiliser le type de licence HA/DR.

Considérations importantes pour HADR SQL Server dans Azure

Les machines virtuelles Azure, le stockage et le réseau ont des caractéristiques opérationnelles différentes par rapport à celles d’une infrastructure informatique non virtualisée sur site. Pour une implémentation réussie d’une solution HADR SQL Server dans Azure, vous devez comprendre ces différences et concevoir votre solution de façon à les gérer.

Nœuds haute disponibilité d’un groupe à haute disponibilité

Les groupes à haute disponibilité dans Azure vous permettent de placer les nœuds haute disponibilité dans des domaines d’erreur et des domaines de mise à niveau distincts. La plateforme Azure attribue un domaine de mise à jour et un domaine d’erreur à chaque machine virtuelle de votre groupe à haute disponibilité. Cette configuration au sein d’un centre de données assure la disponibilité d’au moins une des machines virtuelles pendant un événement de maintenance planifié ou non, avec le niveau de 99,95 % stipulé dans le contrat de niveau de service (SLA) Azure.

Pour une configuration à haute disponibilité, placez toutes les machines virtuelles SQL Server correspondantes dans le même groupe à haute disponibilité afin d’éviter la perte d’applications ou de données lors d’un événement de maintenance. Seuls les nœuds du même service cloud peuvent faire partie du même groupe à haute disponibilité. Pour plus d’informations, consultez Gestion de la disponibilité des machines virtuelles.

Nœuds haute disponibilité d’une zone de disponibilité

Les Zones de disponibilité sont des emplacements physiques uniques au sein d’une région Azure. Chaque zone 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. La séparation physique des zones de disponibilité dans une région contribue à protéger les applications et les données des défaillances dans le centre de données en veillant à ce qu’au moins une machine soit disponible et réponde au contrat de niveau de service Azure de 99,99 %.

Pour une configuration à haute disponibilité, placez les machines virtuelles SQL Server correspondantes réparties sur les zones de disponibilité dans la région. Des frais supplémentaires sont facturés pour les transferts réseau-à-réseau entre les zones de disponibilité. Pour plus d’informations, consultez Zones de disponibilité.

Latence du réseau dans un environnement hybride

Déployez votre solution HADR en partant du principe qu’il peut y avoir des périodes de latence réseau élevée entre votre réseau local et Azure. Quand vous déployez des réplicas sur Azure, utilisez la validation asynchrone au lieu de la validation synchrone comme mode de synchronisation. Quand vous déployez des serveurs de mise en miroir de bases de données localement et dans Azure, utilisez le mode haute performance plutôt que le mode haute sécurité.

Consultez les bonnes pratiques de configuration HADR pour les paramètres de cluster et HADR qui peuvent aider à prendre en charge l’environnement Cloud.

Prise en charge de la géo-réplication

La géoréplication dans les disques Azure ne prend pas en charge le fichier de données et le fichier d’historique de la même base de données à stocker sur des disques distincts. GRS réplique les modifications sur chaque disque indépendamment et de manière asynchrone. Ce mécanisme garantit l’ordre d’écriture dans un seul disque sur la copie géo-répliquée, mais pas entre les copies géo-répliquées de plusieurs disques. Si vous configurez une base de données pour stocker le fichier de données et le fichier journal sur des disques distincts, les disques récupérés après un sinistre peuvent contenir une copie plus à jour du fichier de données que le fichier journal, ce qui interrompt le journal WAL (write-ahead log) dans SQL Server et les propriétés ACID (atomicité, cohérence, isolation et durabilité) des transactions.

Si vous n’avez pas l’option de désactiver la géoréplication sur le compte de stockage, conservez tous les fichiers de données et fichiers journaux pour une base de données sur le même disque. Si vous devez utiliser plusieurs disques en raison de la taille de la base de données, déployez l’une des solutions de reprise d’activité indiquées plus haut pour assurer la redondance des données.

Étapes suivantes

Déterminez si un groupe de disponibilité ou une instance de cluster de basculement est la meilleure solution de continuité d’activité pour votre entreprise. Passez ensuite en revue les bonnes pratiques en matière de configuration de votre environnement pour la haute disponibilité et la reprise d’activité.