Denali – plusieurs groupes de disponibilité

Depuis la sortie de la CTP3 et la publication de billets sur les groupes de disponibilité, j’ai reçu quelque messages contenant des questions.

Les groupes de disponibilité sont en fait un mix des solutions de clustering et de mirroring, reprenant les avantages des deux technologies. Le cluster permet de protéger plusieurs bases de données car l’instance dans son intégralité est virtualisée sur le groupe de serveurs. En cas de panne d’un nœud, l’instance bascule sur un autre nœud. Un autre atout du cluster de basculement était de fournir un et un seul point d’accès () pour l’instance, quelles que soit le nœud actif. Le nom réseau et l’adresse IP sont des paramètres invariables, donc même s’il y a basculement (failover) les applications se reconnectent à l’instance. Sauf que ce basculement est “lent”. il faut compter entre 30 secondes et jusqu’à deux minutes pour une bascule complète. On ne peut donc pas parler de haute disponibilité. C’est là que la mise en miroir d’une base de données prends tout son intérêt. Si la session de mise en miroir est synchrone, alors le basculement est très rapide (un peu moins en mode asynchrone car il y a plus de transactions à rejouer). L’inconvénient du DBM vient du fait qu’une session de mise en miroir ne pouvait contenir qu’une seule base.

C’est pourquoi les groupes de disponibilité sont une solution couvrant les avantages du cluster

  • un point d’accès au travers du listener (ni plus ni moins qu’un point d’accès dans le groupe de ressource) :

image

  • la protection de plusieurs bases de données. En effet sur le DBM, il fallait créer autant de session de mise en miroir que de bases de données à protéger. Avec les AAG (AlwaysOn Availability Groups), plusieurs bases “fonctionnent” de concert. Car dans SQL Server 2008 (R2) si une application utilisait plusieurs bases, il fallait que le réplica actif soit sur la même instance. Dans un AAG, il peut y avoir plusieurs bases :

image

  • la possibilité d’accéder à une base de données en lecture seule (sur els réplicas secondaires) comme avec du Log Shipping ou pourquoi pas de la réplication
  • la possibilité de faire des backup de bases de données sur un serveur secondaire afin de soulager le serveur primaire

On par de groupe de disponibilité, mais il est tout a fait possible de créer plusieurs groupes de disponibilité au sein d’un cluster. Chaque AAG possède sa propre adresse IP virtuelle et son propre nom réseau. Il est donc possible de répartir la charge sur les différents nœuds en “croisant” les réplicas primaires et secondaires.

image

Un des problèmes majeurs du Database Mirroring se situait au niveau des logins de type SQL. pour des logins Windows, le SID du login étant identique sur l’ensemble des serveurs, il n’y avait pas de soucis. Par contre pour un login SQL, il fallait synchroniser les SIDs. Ce qui constituait un frein à l’adoption de la technologie. Avec les bases de données contenues (contained databases), cette limitation disparait et les AAG utilisées de concert avec les users avec mot de passe annoncent clairement un virage vers la mobilité des bases de données.

A propos Christophe

Consultant SQL Server Formateur certifié Microsoft MVP SQL Server MCM SQL Server 2008
Cet article, publié dans SQL Server, est tagué , , , , , . Ajoutez ce permalien à vos favoris.

Un commentaire pour Denali – plusieurs groupes de disponibilité

  1. Ping : Groupes de disponibilité et disaster recovery | Christophe LAPORTE – Consultant SQL Server

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s