Explorer les options de haute disponibilité et de reprise d’activité

15 minutes

Pour envisager une solution pour des machines virtuelles, vous devez d’abord comprendre les options de disponibilité pour les déploiements basés sur IaaS.

Infrastructure en tant que service (IaaS) et plateforme en tant que service (PaaS)

En matière de disponibilité, le choix d’IaaS ou de PaaS a des conséquences importantes. Avec IaaS, vous disposez d’une machine virtuelle, ce qui signifie qu’il existe un système d’exploitation avec une installation de SQL Server. L’administrateur ou le groupe responsable de SQL Server a le choix entre plusieurs solutions HADR (haute disponibilité et reprise d’activité) et contrôle largement la configuration de cette solution.

Avec les déploiements basés sur PaaS comme Azure SQL Database, les solutions HADR sont intégrées à la fonctionnalité et doivent simplement être activées dans la plupart des cas. Le nombre d’options pouvant être configurées est minimal.

En raison de ces différences, le choix d’IaaS ou de PaaS peut influencer la conception finale de votre solution HADR.

Fonctionnalités HADR de SQL Server pour machine virtuelle Azure

Si vous utilisez IaaS, vous pouvez recourir aux fonctionnalités fournies par SQL Server pour augmenter la disponibilité. Dans certains cas, vous pouvez les combiner avec des fonctionnalités de niveau Azure pour augmenter davantage la disponibilité.

Les fonctionnalités disponibles dans SQL Server sont présentées dans le tableau ci-dessous.

Nom de la fonctionnalité	Protection
Instances de cluster de basculement (FCI) Always On	Instance
Groupe de disponibilité Always On	Base de données
Copie des journaux de transactions	Base de données

Une instance SQL Server correspond à l’installation complète de SQL Server (binaires et tous les objets à l’intérieur de l’instance comme les connexions, les travaux SQL Server Agent et les bases de données). La protection au niveau de l’instance signifie que la totalité de l’instance est prise en compte dans la fonctionnalité de disponibilité.

Une base de données dans SQL Server contient les données dont se servent les utilisateurs finaux et les applications. SQL Server s’appuie sur des bases de données système, mais il existe aussi des bases de données créées à l’intention des utilisateurs finaux et des applications. Une instance SQL Server a toujours ses propres bases de données système. La protection au niveau de la base de données signifie que tout ce qui se trouve dans la base de données ou qui est capturé dans le journal des transactions pour une base de données utilisateur ou d’application est pris en compte dans le cadre de la fonctionnalité de disponibilité. Tout ce qui existe en dehors de la base de données ou qui n’est pas capturé dans le journal des transactions, comme les travaux SQL Server Agent et les serveurs liés, doit être traité manuellement pour que le serveur de destination puisse agir en tant que principal dans le cas d’un événement de basculement planifié ou non planifié.

Les FCI et les groupes de disponibilité nécessitent un mécanisme de cluster sous-jacent. Pour les déploiements de SQL Server s’exécutant sur Windows Server, il s’agit d’un cluster de basculement Windows Server (WSFC). Pour Linux, il s’agit de Pacemaker.

Instances de cluster de basculement Always On

Une FCI est configurée au moment de l’installation de SQL Server. Une instance autonome de SQL Server ne peut pas être convertie en FCI. Un nom unique est attribué à la FCI, ainsi qu’une adresse IP différente de celle des serveurs sous-jacents, ou nœuds, participant au cluster. Le nom et l’adresse IP doivent également être différents de ceux du mécanisme de cluster sous-jacent. Les applications et les utilisateurs finaux utilisent le nom unique de la FCI pour l’accès. Cette abstraction permet aux applications de ne pas avoir à connaître l’emplacement d’exécution de l’instance. L’une des principales différences entre les FCI basées sur Azure et les FCI locales est la nécessité d’utiliser un équilibreur de charge interne (ILB) pour Azure. Cet équilibreur permet de garantir que les applications et les utilisateurs finaux peuvent se connecter au nom unique de la FCI.

Quand une FCI bascule sur un autre nœud d’un cluster, que le basculement soit lancé manuellement ou qu’il survienne à la suite d’un problème, la totalité de l’instance redémarre sur un autre nœud. Cela signifie que le processus de basculement se traduit par l’arrêt complet et le démarrage de SQL Server. Les applications ou les utilisateurs finaux connectés à la FCI sont déconnectés pendant le basculement, et seules les applications qui peuvent gérer cette interruption et récupérer peuvent se reconnecter automatiquement.

Au moment du démarrage sur l’autre nœud, l’instance passe par le processus de récupération. La FCI est cohérente jusqu’au point de défaillance. Il n’y a donc techniquement aucune perte de données, mais les transactions qui doivent être restaurées le sont dans le cadre de la récupération. Comme indiqué ci-dessus, étant donné qu’il s’agit d’une protection au niveau de l’instance, tout le nécessaire (connexions, travaux SQL Server Agent, etc.) est déjà présent afin que tout fonctionne normalement une fois les bases de données prêtes.

Les FCI nécessitent une copie d’une base de données, ce qui constitue également un point de défaillance unique. Pour qu’un autre nœud puisse accéder à la base de données, les FCI nécessitent une forme de stockage partagé. Pour les architectures basées sur Windows Server, vous pouvez utiliser un partage de fichiers Azure Premium, iSCSI, un disque partagé Azure, des espaces de stockage direct (S2D) ou une solution tierce prise en charge comme SIOS DataKeeper. Les FCI utilisant l’édition Standard de SQL Server peuvent avoir jusqu’à deux nœuds. Les FCI nécessitent également Active Directory Domain Services (AD DS) et Domain Name Service (DNS), ce qui signifie que AD DS et DNS doivent être implémentés quelque part dans Azure pour que les FCI fonctionnent.

À l’aide de Windows Server 2016 ou ultérieur, les FCI peuvent utiliser le réplica de stockage pour créer une solution de reprise d’activité native pour FCI sans avoir à utiliser une autre fonctionnalité telle que la copie des journaux de transaction ou des groupes de disponibilité.

Groupes de disponibilité Always On

Les groupes de disponibilité ont été introduits dans SQL Server 2012 édition Entreprise, mais sont présents dans l’édition Standard depuis SQL Server 2016. Un groupe de disponibilité peut contenir une seule base de données dans l’édition Standard, alors qu’il peut en contenir plusieurs dans l’édition Entreprise. Bien que les groupes de disponibilité présentent des similitudes avec les FCI, ils sont différents à bien des égards.

La plus grande différence entre une FCI et un groupe de disponibilité tient au fait que les groupes de disponibilité offrent une protection au niveau de la base de données. Le réplica principal est l’instance participant à un groupe de disponibilité qui contient les bases de données en lecture/écriture. Un réplica secondaire est l’emplacement où le principal envoie des transactions au moyen du transport de journal pour le garder synchronisé. Le déplacement des données entre un réplica principal peut être synchrone ou asynchrone. Une base de données sur un réplica secondaire est dans un état de chargement, ce qui signifie qu’elle peut recevoir des transactions mais qu’elle ne peut pas être une copie entièrement accessible en écriture tant que ce réplica ne devient pas le principal. Un groupe de disponibilité dans l’édition Standard peut avoir au maximum deux réplicas (un principal, un secondaire), tandis que l’édition Entreprise prend en charge jusqu’à neuf réplicas (un principal, huit secondaires). Vous pouvez initialiser un réplica secondaire à partir d’une sauvegarde de la base de données ou, depuis SQL Server 2016, avec une fonctionnalité appelée « amorçage automatique ». L’amorçage automatique utilise le transport de flux de journaux pour transmettre en streaming la sauvegarde au réplica secondaire pour chaque base de données du groupe de disponibilité, en utilisant les points de terminaison configurés.

Un groupe de disponibilité fournit une abstraction avec l’écouteur. L’écouteur fonctionne comme le nom unique affecté à une FCI et possède son propre nom et sa propre adresse IP qui diffèrent de ceux de tout autre élément (WSFC, nœud, etc.). L’écouteur nécessite également un équilibreur de charge interne et passe par un arrêt et un démarrage. Les applications et les utilisateurs finaux peuvent se servir de l’écouteur pour se connecter. Toutefois, contrairement à une FCI, l’écouteur n’est pas obligatoire. Des connexions peuvent être établies directement à l’instance. Dans l’édition Entreprise, vous pouvez également configurer des réplicas secondaires pour un accès en lecture seule et les utiliser pour d’autres fonctionnalités telles que les vérifications de cohérence de base de données (DBCC) et les sauvegardes.

Les groupes de disponibilité peuvent afficher un temps de basculement inférieur à celui d’une FCI, ce qui les rend particulièrement attrayants. Bien que les groupes de disponibilité ne nécessitent pas de stockage partagé, chaque réplica dispose d’une copie des données, ce qui augmente le nombre total de copies de la base de données et les coûts de stockage globaux. Le stockage est local pour chaque réplica. Par exemple, si l’empreinte des données des bases de données sur le réplica principal est de 1 To, il en est de même pour chaque réplica. S’il y a cinq réplicas, vous avez donc besoin de 5 To d’espace.

Souvenez-vous que tout objet qui existe en dehors de la base de données ou qui n’est pas capturé dans le journal des transactions de la base de données doit être créé manuellement et pris en compte sur toute autre instance SQL Server au cas où cette instance deviendrait le nouveau réplica principal. Les travaux SQL Server Agent, les connexions au niveau de l’instance et les serveurs liés sont des exemples d’objets dont vous avez la responsabilité. Si vous pouvez utiliser l’authentification Windows ou des bases de données autonomes avec des groupes de disponibilité, cela simplifie l’accès.

De nombreuses organisations peuvent rencontrer des difficultés lors de l’implémentation d’architectures hautement disponibles. La solution de haute disponibilité fournie par la plateforme Azure peut suffire, ou elles peuvent utiliser une solution PaaS comme Azure SQL Managed Instance. Avant d’examiner les solutions de la plateforme Azure, nous allons nous pencher sur une autre fonctionnalité de SQL Server qu’il est important de connaître : la copie des journaux de transaction.

Copie des journaux de transaction

La copie des journaux de transaction remonte aux débuts de SQL Server. Cette fonctionnalité basée sur la sauvegarde, la copie et la restauration est l’une des méthodes les plus simples pour obtenir un environnement HADR pour SQL Server. La copie des journaux de transaction est principalement utilisée pour la reprise d’activité, mais elle peut également servir à améliorer la disponibilité locale.

La copie des journaux de transaction, au même titre que les groupes de disponibilité, fournit une protection au niveau de la base de données, ce qui signifie que vous devez toujours tenir compte des travaux SQL Server Agent, des serveurs liés, des connexions au niveau de l’instance, etc. La copie des journaux de transaction ne fournissant nativement aucune abstraction, le passage à un autre serveur participant à la copie des journaux de transaction doit pouvoir tolérer un changement de nom. Si ce n’est pas possible, vous pouvez configurer des méthodes au niveau de la couche réseau, comme un alias DNS, pour tenter d’atténuer les problèmes de changement de nom.

Le mécanisme de copie des journaux de transaction est simple : la base de données source sur le serveur principal est d’abord entièrement sauvegardée, puis restaurée dans un état de chargement (STANDBY ou NORECOVERY) sur une autre instance appelée « serveur secondaire » ou « secours semi-automatique ». Cette nouvelle copie de la base de données est appelée « base de données secondaire ». Un processus automatisé intégré à SQL Server sauvegarde ensuite automatiquement le journal des transactions de la base de données primaire, copie la sauvegarde sur le serveur de secours et enfin restaure la sauvegarde sur le secours.