Les groupes de disponibilité AlwaysOn de SQL Server sont une technologie qui a été initialement publiée par Microsoft avec SQL Server 2012.

Le concept principal, est que vous avez vos données disponibles sur plusieurs sites en même temps. Pour cela, vous avez des groupes de bases de données qui ont des répliques primaires et des répliques secondaires. Ces répliques sont hébergées sur différents serveurs et peuvent être synchronisées selon deux modes :

• Mode de disponibilité asynchrone-commit
• Mode de disponibilité synchrone-commit

Groupes de disponibilité Mode asynchrone-commit

Avec le mode asynchrone-commit, la réplique secondaire n’est jamais complètement synchronisée avec la réplique primaire. La raison en est qu’en raison de la nature asynchrone du commit, toute base de données pourrait être à la traîne à tout moment. Cela signifie que si vous utilisez le mode de commit asynchrone et que vous effectuez un basculement forcé (c’est la seule forme de basculement que vous pouvez effectuer), alors il est fortement possible d’avoir des pertes de données.

Groupes de disponibilité Mode de commit synchrone

Avec le mode de commit synchrone, après avoir été jointe à un groupe de disponibilité, une base de données secondaire rattrape la base de données correspondante et entre dans l’état « Synchronisé ». La condition préalable à cela est bien sûr que la synchronisation des données (et donc, le mouvement des données) se poursuive et qu’elle ne soit pas arrêtée pour une raison quelconque (c’est-à-dire des problèmes de réseau, d’espace disque, etc.). Si la synchronisation des données se poursuit et que le mode de validation synchrone est utilisé, alors chaque transaction validée sur une base de données primaire donnée a également été validée sur la base de données secondaire.

Exemple d’une architecture de groupes de disponibilité Always On de SQL Server

Le schéma ci-dessous illustre la configuration d’une réplique à 2 nœuds avec des groupes de disponibilité Always On de SQL Server.

Discutons plus en détail les concepts illustrés dans le schéma architectural ci-dessus.

Discussion et recommandations

Une chose qui est très importante à noter, c’est que, sur la base de l’architecture des groupes de disponibilité, chaque réplique, a son propre stockage dédié, c’est après tout, la façon d’avoir vos données disponibles sur plusieurs sites. Ceci est basé sur le principe de la redondance.

J’ai un géo-cluster avec 2 nœuds sur 2 sites différents, Site A et Site B. Sur chaque site, j’ai une réplique de mes groupes de disponibilité SQL Server. A l’exemple ci-dessus, sur le site A, j’ai mes répliques primaires, et sur le site B, mes répliques secondaires. Comme discuté précédemment, mes répliques peuvent être soit synchronisées avec un commit synchrone ou asynchrone.

Une autre chose importante à noter, c’est que si vous voulez vraiment obtenir une haute disponibilité, vous avez besoin d’un troisième site afin de servir de témoin de partage de fichiers. C’est pourquoi dans mon diagramme ci-dessus, j’ai inclus un troisième site, c’est-à-dire le site C, qui fournit un partage de fichiers afin d’être utilisé comme témoin de partage de fichiers pour le géo-cluster.

Comment connecter mon application à une base de données dans un groupe de disponibilité SQL Server ?

Si vous êtes nouveau dans les groupes de disponibilité SQL Server, vous pouvez vous demander : « comment mon application va-t-elle se connecter à la base de données ? ». Eh bien, ne vous inquiétez pas car c’est très simple. Chaque groupe de disponibilité a son propre auditeur (une paire de nom de réseau virtuel et d’IP virtuelle) que vous devez configurer lors de la création d’un groupe de disponibilité. Dans la configuration de la chaîne de connexion de votre application, vous devrez entrer ce nom/IP d’auditeur et son numéro de port afin que votre application puisse « voir » la ou les bases de données dans le groupe de disponibilité spécifique. Après cela, l’architecture de haute disponibilité sous-jacente sera transparente pour votre application.

Une note importante ici, il vous est conseillé d’utiliser les groupes de disponibilité pour votre solution uniquement si votre solution/application prend en charge cette architecture de haute disponibilité.

Que se passe-t-il pendant un basculement ?

Un basculement dans une architecture de groupes de disponibilité SQL Server est différent (et plus rapide) qu’un basculement dans une instance de cluster de basculement (FCI) SQL Server traditionnelle. La différence majeure est que chaque fois qu’un basculement a lieu pour un groupe de disponibilité SQL Server, la seule chose qui change de propriétaire, c’est l’écouteur. Cela signifie qu’après le basculement, l’écouteur du groupe de disponibilité spécifique pointera vers l’autre réplique, car cette réplique est devenue la nouvelle réplique primaire et l’autre (qui était jusqu’alors la primaire) est devenue la réplique secondaire. Tout cela suppose bien sûr que les deux répliques sont synchronisées.

Marques finales

Comme vous pouvez le voir dans la discussion et l’exemple ci-dessus, tout ce qui précède fait de SQL Server Always On une solution de haute disponibilité très puissante qui doit être définitivement prise en compte lors de la conception de centres de données actifs-actif.

Enfin, notez que ce qui précède était un exemple simplifié, afin de vous aider à comprendre les bases mêmes des groupes de disponibilité SQL Server et comment ils contribuent à avoir des instances SQL Server hautement disponibles.

Avec l’offre de groupes de disponibilité SQL Server Always On, vous pouvez construire des solutions de base de données haute disponibilité sophistiquées avec plus de 2 sites et ainsi avoir une infrastructure véritablement hautement disponible.

Dans les articles suivants, nous aborderons d’autres sujets sur les groupes de disponibilité Always On de SQL Server, alors restez à l’écoute !

Renforcez vos compétences en administration de SQL Server – Inscrivez-vous à notre cours en ligne !

Si vous voulez vraiment apprendre des techniques sophistiquées d’administration de SQL Server, alors vous devriez consulter notre cours en ligne à la demande intitulé « Essential SQL Server Administration Tips » (remise spéciale à durée limitée incluse dans le lien).

A travers ce cours, vous apprendrez des conseils pratiques essentiels d’administration de SQL Server sur la maintenance, la sécurité, les performances, l’intégration, la gestion des erreurs et plus encore. Nombreuses démonstrations en direct et ressources téléchargeables incluses !

S’inscrire maintenant avec une réduction !

Cours en ligne caractéristiques :

• Améliorer les performances des bases de données SQL Server avec le OLTP en mémoire
• Conseils essentiels d’administration de SQL Server
• Fondamentaux de SQL Server – Base de données SQL pour les débutants
• Conseils essentiels de développement SQL Server pour les développeurs SQL
• La philosophie et les principes fondamentaux de la programmation informatique
• .NET pour les débutants – Windows Forms avec C#
• Introduction à la science des données et à l’apprentissage automatique SQL Server
• Introduction à Azure SQL Database pour les débutants
• SQL Server 2019 : Nouveautés – Fonctions nouvelles et améliorées
• Entity Framework : Démarrage – Guide complet pour les débutants
• Comment importer et exporter des données dans les bases de données SQL Server
• Apprendre à installer et à commencer à utiliser SQL Server en 30 Mins
• Un guide sur la façon de démarrer et de monétiser un blog à succès

Articles connexes sur l’administration de SQL Server :

• Conseils essentiels pour l’administration de SQL Sever
• Comment patcher une instance autonome de SQL Server
• Le service de navigation de SQL Server et le port UDP 1434
• Le paramètre du nombre maximal de connexions simultanées. dans SQL Server
• La liste des 10 principales tâches quotidiennes des DBA SQL Server
• Il n’y a pas de cluster de basculement SQL Server disponible à rejoindre
• Encryptage d’une sauvegarde de base de données SQL Server
• …plus

Notez cet article : (2 votes, moyenne : 5.00 sur 5)