Configurer la récupération après sinistre pour SQL Server

Article
04/11/2023

Cet article explique comment protéger les SQL Server back end d’une application. Pour ce faire, vous utilisez une combinaison des technologies de continuité d’activité et récupération d’urgence de SQL Server et Azure Site Recovery.

Avant de commencer, assurez-vous que vous comprenez les fonctionnalités de récupération d’urgence de SQL Server. Ces fonctionnalités sont les suivantes :

Clustering de basculement
Groupes de disponibilité Always On
Mise en miroir de bases de données
Copie des journaux de transaction
La géoréplication active
Groupes de basculement automatique

Combinaison de technologies BCDR avec Site Recovery

Le choix d’une technologie BCDR pour la récupération des instances de SQL Server doit être basé sur votre objectif de temps de récupération (RTO) et sur l’objectif de point de récupération (RPO), comme décrit dans le tableau suivant. Combinez Site Recovery avec l’opération de basculement de la technologie choisie pour orchestrer la récupération de l’ensemble de votre application.

Type de déploiement	Technologie BCDR	RTO attendu pour SQL Server	RPO attendu pour SQL Server
SQL Server sur une machine virtuelle (VM) infrastructure as a service (IaaS) Azure ou localement.	Groupe de disponibilité AlwaysOn	Le temps nécessaire pour faire du réplica secondaire le réplica principal.	La réplication étant asynchrone vers le réplica secondaire, il y a une perte de données.
SQL Server sur une machine virtuelle Azure IaaS ou localement.	Clustering de basculement (instance de cluster de basculement AlwaysOn)	Temps nécessaire pour basculer entre les nœuds.	Étant donné que Always On FCI utilise un stockage partagé, la même vue de l’instance de stockage est disponible lors du basculement.
SQL Server sur une machine virtuelle Azure IaaS ou localement.	Mise en miroir de bases de données (mode hautes performances)	Temps nécessaire pour forcer le service, qui utilise le serveur miroir en tant que serveur de secours actif.	La réplication est asynchrone. La base de données miroir peut être un peu en retard par rapport à la base de données principale. Le décalage est généralement faible. Mais il peut devenir important si le système du serveur principal ou du serveur miroir subit une charge importante. La copie des journaux de transaction peut être un complément à la mise en miroir de bases de données. Il s’agit d’une alternative favorable à la mise en miroir asynchrone de bases de données.
SQL As Platform as a service (PaaS) sur Azure. Ce type de déploiement comprend des bases de données uniques et des pools élastiques.	La géoréplication active	30 secondes après le déclenchement du basculement. Lorsque le basculement est activé pour l’une des bases de données secondaires, toutes les autres bases de données secondaires sont automatiquement liées à la nouvelle base de données primaire.	RPO de cinq secondes. La géo-réplication active utilise la technologie Always On de SQL Server. Elle réplique de manière asynchrone les transactions validées entre une base de données primaire vers une base de données secondaire à l’aide de l’isolation d’instantané. Il est garanti que les données secondaires n’auront jamais de transactions partielles.
SQL en tant que PaaS configuré avec la géoréplication active sur Azure. Ce type de déploiement comprend des instances gérées, des pools élastiques et des bases de données uniques.	Groupes de basculement automatique	RTO d’une heure.	RPO de cinq secondes. Les groupes de basculement automatique fournissent la sémantique de groupe en plus de la géo-réplication Active. Toutefois, le même mécanisme de réplication asynchrone est utilisé.
SQL Server sur une machine virtuelle Azure IaaS ou localement.	Réplication avec Azure Site Recovery	Le RTO est généralement inférieur à 15 minutes. Pour plus d’informations, consultez le SLA RTO fourni par Site Recovery.	Une heure pour la cohérence des applications et cinq minutes pour la cohérence des incidents. Si vous souhaitez réduire le RPO, utilisez d’autres technologies BCDR.

Notes

Voici quelques considérations importantes à prendre en compte lorsque vous contribuez à protéger les charges de travail SQL avec Site Recovery :

Site Recovery est indépendant des applications. Site Recovery peut aider à protéger n’importe quelle version de SQL Server déployée sur un système d’exploitation pris en charge. Pour en savoir plus, consultez la matrice d’assistance pour la récupération des machines répliquées.
Vous pouvez choisir d’utiliser Site Recovery pour n’importe quel déploiement d’une infrastructure Azure, Hyper-V, VMware ou physique. Suivez les instructions fournies à la fin de cet article sur la façon de protéger un cluster SQL Server avec Site Recovery.
Assurez-vous que le taux de modification des données observé sur l'ordinateur se situe dans les limites de Site Recovery. Le taux de modification est mesuré en octets écrits par seconde. Pour les machines exécutant Windows, vous pouvez afficher ce taux de modification en sélectionnant l’onglet Performance dans le gestionnaire des tâches. Observez la vitesse d’écriture pour chaque disque.
Site Recovery prend en charge la réplication des instances de cluster de basculement sur Storage Spaces Direct. Pour plus d’informations, consultez Comment activer la réplication de Storage Spaces Direct.

Lorsque vous migrez votre charge de travail SQL vers Azure, il est recommandé d’appliquer les Recommandations de performances pour SQL Server sur les machines virtuelles Azure.

Récupération d’urgence d’une application

Site Recovery orchestre le test de basculement et le basculement de toute votre application à l’aide de plans de récupération.

Il existe certaines conditions préalables pour garantir que votre plan de récupération est entièrement personnalisé en fonction de vos besoins. Tout déploiement de SQL Server a généralement besoin d’un déploiement Active Directory. Il a également besoin d’une connectivité pour votre couche application.

Étape 1 : Configurer Active Directory

Configurez Active Directory sur le site de récupération secondaire afin que SQL Server fonctionne correctement.

Petite entreprise : vous disposez de quelques applications et d’un seul contrôleur de domaine pour le site local. Si vous souhaitez basculer l’ensemble du site, utilisez la réplication Site Recovery. Ce service réplique le contrôleur de domaine dans le centre de données secondaire ou sur Azure.
Moyenne à grande entreprise : Vous devrez peut-être configurer des contrôleurs de domaine supplémentaires.
- Si vous avez un grand nombre d’applications, que vous disposez d’une forêt Active Directory et que vous souhaitez effectuer un basculement par application ou charge de travail, configurez un autre contrôleur de domaine dans le centre de données secondaire ou dans Azure.
- Si vous utilisez groupes de disponibilité Always On pour effectuer une récupération sur un site distant, configurez un autre contrôleur de domaine sur le site secondaire ou dans Azure. Ce contrôleur de domaine est utilisé pour l’instance de SQL Server récupérée.

Les instructions fournies dans cet article supposent qu’un contrôleur de domaine est disponible sur le site secondaire. Pour en savoir plus, consultez les procédures pour aider à protéger Active Directory avec Site Recovery.

Étape 2 : Garantir la connectivité avec d’autres niveaux

Une fois que la couche base de données est en cours d’exécution dans la région Azure cible, assurez-vous que vous disposez d’une connectivité avec les niveaux application et Web. Prenez les mesures nécessaires à l’avance pour valider la connectivité avec le test de basculement.

Pour comprendre comment vous pouvez concevoir des applications pour les considérations de connectivité, consultez les exemples suivants :

Étape 3 : Interagir avec Always On, la géoréplication Active et les groupes de basculement automatique

Les technologies BCDR Always On, géoréplication active et groupes de basculement automatique ont des réplicas secondaires de SQL Server en cours d’exécution dans la région Azure cible. La première étape pour le basculement de votre application consiste à spécifier ce réplica comme principal. Cette étape suppose que vous disposiez déjà d’un contrôleur de domaine dans le réplica secondaire. Cette étape ne sera peut-être pas nécessaire si vous choisissez d’effectuer un basculement automatique. Basculez vos couches application et Web uniquement après la fin du basculement de la base de données.

Notes

Si vous avez aidé à protéger les machines SQL avec Site Recovery, il vous suffit de créer un groupe de récupération de ces machines et d’ajouter leur basculement dans le plan de récupération.

Créez un plan de récupération avec les machines virtuelles des couches application et web. Les étapes suivantes montrent comment ajouter le basculement de la couche base de données:

Importez les scripts pour basculer le groupe de disponibilité SQL dans une machine virtuelle Resource Manager et une machine virtuelle classique. Importez les scripts sur votre compte Azure Automation.
Ajoutez le script ASR-SQL-FailoverAG comme une action préalable du premier groupe dans le plan de récupération.
Suivez les instructions disponibles dans le script pour créer une variable Automation. Cette variable fournit le nom des groupes de disponibilité.

Étape 4 : Effectuer un test de basculement

Certaines technologies BCDR, telles que SQL Always On, ne prennent pas en charge les tests de basculement de manière native. Nous vous recommandons l’approche suivante uniquement lors de l'utilisation de ces technologies.

Configurer la Sauvegarde Azure sur la machine virtuelle qui héberge le réplica du groupe de disponibilité dans Azure.
Avant de déclencher le test de basculement du plan de récupération, récupérez la machine virtuelle à partir de la sauvegarde effectuée à l’étape précédente.
Forcez un quorum dans la machine virtuelle restaurée à partir d’une sauvegarde.
Mettez à jour l’adresse IP de l’écouteur pour qu’elle soit une adresse disponible dans le réseau de test de basculement.
Mettez l'écouteur en ligne.
Vérifiez que l’équilibreur de charge dans le réseau de basculement possède une adresse IP provenant du pool d’adresses IP front-end qui correspond à chaque écouteur de groupe de disponibilité et créée avec la machine virtuelle SQL Server du pool back-end.
Dans les groupes de récupération ultérieurs, ajoutez le basculement de votre couche application, suivi de votre couche Web pour ce plan de récupération.
Effectuez un test de basculement du plan de récupération afin de tester le basculement de bout en bout de votre application.

Procédure de basculement

Après avoir ajouté le script à l’étape 3 et l’avoir validé à l’étape 4, vous pouvez effectuer un basculement du plan de récupération créé à l’étape 3.

Notez que les étapes de basculement pour les couches application et web doivent être les mêmes dans les plans de récupération de basculement et de test de basculement.

Comment protéger un cluster SQL Server

Pour un cluster exécutant SQL Server Standard Edition ou SQL Server 2008 R2, nous vous recommandons d’utiliser la réplication Site Recovery pour protéger SQL Server.

Azure vers Azure et local vers Azure

Site Recovery ne prend pas en charge le cluster invité lors de la réplication vers une région Azure. De même, l’édition standard de SQL Server n’inclut aucune solution de récupération d'urgence à faible coût. Dans ce scénario, nous vous recommandons de protéger le cluster SQL Server sur un serveur SQL Server autonome à l’emplacement principal, et de le récupérer à l’emplacement secondaire.

Configurez une autre instance SQL Server autonome dans la région Azure principale ou le site local.
Configurez l’instance comme une copie miroir des bases de données que vous souhaitez protéger. Configurez la mise en miroir en mode haute sécurité.
Configurez Site Recovery sur le site principal pour Azure, Hyper-V ou serveurs physiques/machines virtuelles VMware.
Utilisez la réplication Site Recovery pour répliquer la nouvelle instance SQL Server sur le site secondaire. Comme il s’agit d’une copie miroir de haute sécurité, elle est synchronisée avec le cluster principal, mais répliquée à l’aide de la réplication Site Recovery.

Considérations en matière de restauration automatique

Pour les clusters SQL Server Standard, la restauration automatique après un basculement non planifié nécessite une sauvegarde et une restauration SQL Server. Cette opération est effectuée à partir de l’instance miroir vers le cluster d’origine, avec le rétablissement de la mise en miroir.

Forum aux questions

Comment les SQL Server sont-ils concédés sous licence lorsqu’ils sont utilisés avec Site Recovery ?

La réplication Site Recovery pour les SQL Server est couverte par l’avantage de la récupération d’urgence de Software Assurance. Cette couverture s’applique à tous les scénarios de Site Recovery : récupération d’urgence d’un site local vers Azure et récupération d’urgence Azure IaaS inter-régions. Pour en savoir plus, consultez la tarification Azure Site Recovery.

Site Recovery prendra-t-il en charge ma version de SQL ?

Site Recovery est indépendant des applications. Site Recovery peut aider à protéger n’importe quelle version de SQL Server déployée sur un système d’exploitation pris en charge. Pour en savoir plus, consultez la matrice d’assistance pour la récupération des machines répliquées.

Azure Site Recovery fonctionne-t-il avec la réplication transactionnelle SQL ?

Azure Site Recovery utilisant la copie au niveau du fichier, SQL ne peut pas garantir que les serveurs dans une topologie de réplication SQL associée sont synchronisés au moment du basculement Azure Site Recovery. Cela peut occasionner l’échec du lecteur de journaux et/ou des agents de distribution en raison d’une incompatibilité LSN, ce qui peut interrompre la réplication. Si vous basculez l’éditeur, le distributeur ou l’abonné dans une topologie de réplication, vous devez reconstruire la réplication. Nous vous recommandons de réinitialiser l’abonnement pour SQL Server.

Étapes suivantes

En savoir plus sur l’architecture de Site Recovery.
Pour les serveurs SQL dans Azure, apprenez-en davantage sur solutions de haute disponibilité pour la récupération dans la région Azure secondaire.
Pour SQL Database, apprenez-en davantage sur les options de continuité d’activité et de haute disponibilité pour la récupération dans la région Azure secondaire.
Pour les ordinateurs SQL server locaux, apprenez-en davantage sur les options de haute disponibilité pour la récupération dans Machines virtuelles Azure.

Partager via