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

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

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).

La plupart des solutions HADR SQL Server sont prises en charge sur les machines virtuelles, en tant que solutions Azure uniquement et solutions hybrides. 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.

Cet article compare les solutions de continuité d’activité disponibles pour SQL Server sur machines virtuelles Azure.

Vue d’ensemble

Il vous incombe de garantir que votre système de base de données dispose des fonctions HADR requises par le contrat de niveau de service. Le fait qu’Azure fournisse des mécanismes haute disponibilité, 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 contrat de niveau de service. 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.

Le stockage géoredondant (GRS) dans Azure est implémenté avec une fonctionnalité appelée géoréplication. GRS peut ne pas être une solution de reprise d’activité adéquate pour vos bases de données. Comme la géoréplication envoie les données de manière asynchrone, il est possible que les mises à jour récentes soient perdues en cas de sinistre. Vous trouverez plus d’informations sur les limitations de la géoréplication dans la section Prise en charge de la géoréplication.

Notes

Il est maintenant 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.

Architectures de déploiement

Azure prend en charge les technologies SQL Server suivantes pour la continuité d’activité :

• Groupes de disponibilité AlwaysOn
• Instances de cluster de basculement AlwaysOn
• Copie des journaux de transaction
• Sauvegarde et restauration SQL Server avec Stockage Blob Azure
• Mise en miroir de base de données - Dépréciée dans SQL Server 2016
• Azure Site Recovery

Vous pouvez combiner les technologies pour implémenter une solution SQL Server qui offre des fonctions de haute disponibilité et de reprise d’activité. Selon la technologie que vous utilisez, un déploiement hybride peut nécessiter un tunnel VPN avec le réseau virtuel Azure. Les sections suivantes présentent des exemples d’architectures de déploiement.

Azure uniquement : Solutions de haute disponibilité

Vous pouvez avoir une solution de haute disponibilité pour SQL Server au niveau de la base de données avec des groupes de disponibilité AlwaysOn. Vous pouvez également créer une solution de haute disponibilité au niveau de l’instance avec des instances de cluster de basculement AlwaysOn. Pour une protection accrue, vous pouvez créer une redondance aux deux niveaux en créant des groupes de disponibilité sur des instances de cluster de basculement.

Technology	Exemples d’architecture
Groupes de disponibilité	Les réplicas de disponibilité exécutés sur les machines virtuelles Azure dans la même région offrent une haute disponibilité. Vous devez configurer une machine virtuelle de contrôleur de domaine, car le clustering de basculement Windows nécessite un domaine Active Directory. Pour une redondance et une disponibilité 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é. Pour commencer, consultez le didacticiel sur le groupe de disponibilité.
Instances de cluster de basculement	Les instances de cluster de basculement sont prises en charge sur les machines virtuelles SQL Server. Étant donné que la fonctionnalité d’instance de cluster de basculement nécessite un stockage partagé, cinq solutions 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

Azure uniquement : Solutions de reprise d’activité après sinistre

Vous pouvez disposer d’une solution de reprise d’activité pour vos bases de données SQL Server dans Azure en utilisant des groupes de disponibilité, la mise en miroir de bases de données ou la sauvegarde et la restauration à l’aide d’objets blob de stockage.

Technology	Exemples d’architecture
Groupes de disponibilité	Réplicas de disponibilité exécutés dans plusieurs centres de données sur les machines virtuelles Azure pour la récupération d’urgence. Cette 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 aura 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.
Mise en miroir de bases de données	Serveurs principal et miroir s’exécutant dans des centres de données différents pour la récupération d’urgence. Vous devez les déployer à l’aide de certificats de serveur.
Sauvegarde et restauration avec Stockage Blob Azure	Bases de données de production sauvegardées directement dans le stockage d’objets blob dans un autre centre de données pour la reprise d’activité. Pour plus d’informations, consultez Sauvegarde et restauration pour SQL Server sur des machines virtuelles Azure.
Réplication et basculement de SQL Server vers Azure avec Azure Site Recovery	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 reprise d’activité. 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.

Informatique hybride : Solutions de reprise d’activité après sinistre

Vous pouvez disposer d’une solution de reprise d’activité pour vos bases de données SQL Server dans un environnement informatique hybride utilisant des groupes de disponibilité, la mise en miroir de bases de données, la copie des journaux de transaction et la sauvegarde et la restauration avec Stockage Blob Azure.

Technology	Exemples d’architecture
Groupes de disponibilité	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é.
Mise en miroir de bases de données	Un serveur partenaire exécuté sur une machine virtuelle Azure et l’autre exécuté sur site pour la reprise d’activité entre sites utilisant des certificats de serveur. Les serveurs partenaires n’ont pas besoin d’être dans le même domaine Active Directory, et aucune connexion VPN n’est requise. Un autre scénario de mise en miroir de bases de données implique un serveur partenaire exécuté sur une machine virtuelle Azure et l’autre exécuté localement dans le même domaine Active Directory pour la récupération d’urgence entre sites. 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.
Copie des journaux de transaction	Un serveur exécuté sur une machine virtuelle Azure et l’autre exécuté localement 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.
Sauvegarde et restauration avec Stockage Blob Azure	Bases de données de production locales sauvegardées directement dans Stockage Blob Azure pour la reprise d’activité. Pour plus d’informations, consultez Sauvegarde et restauration pour SQL Server sur des machines virtuelles Azure.
Réplication et basculement de SQL Server vers Azure avec Azure Site Recovery	Instance SQL Server de production locale répliquée directement dans Stockage Azure pour la reprise d’activité. 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. Cochez la case pour confirmer que cette machine virtuelle SQL Server sera utilisée comme réplica passif, 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éo-réplication dans les disques Azure ne prend pas en charge le fichier de données et le fichier journal 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é.