FailOver SQL Server 2012

Solution de haute disponibilité

• Mise en miroir d’une BD
• Cluster FAILOVER pour SQL Server
• AAG (AlwaysOn Availability Group )
Mise en miroir d’une BD
• Copie d’une base de données sur une autre instance
• Uniquement pour les bases de données utilisateurs
• Ne s’applique pas pour les bases de données systemes
• 2 instances SQL Server
• 2 Modes possibles :
• Mode synchrone
• Mode Asynchrone
Cluster FAILOVER pour SQL Server
• Il s'agit du cluster SQL classique basé sur la fonctionnalité
WSFC (Windows Server Failover Clustering).
• FCI fournit une haute disponibilité locale par redondance
au niveau instance de serveur (une instance unique
installée sur plusieurs nœuds).
• En cas de défaillance d'un nœud, l'instance démarrera sur
un autre nœud.
• Les clients se connectent à cette instance à partir d'un
VNN (nom de réseau virtuel) qui est une ressource de
cluster.
•  Nécessite un Stockage partagé (SAN, SMB…) pour les
données de base de données et les journaux.
• Dans la solution FCI, le stockage partagé est un SPOF
(Single Point Of Failure).
•  
• Les services SQL (instance) peuvent basculer entre des
nœuds WSFC (la perte d'un serveur est donc couverte). Si
Cluster FAILOVER pour SQL Server
 
• Les services SQL (instance) peuvent basculer entre des
nœuds WSFC (la perte d'un serveur est donc couverte). Si
le stockage échoue, le service s'arrête.
Cluster FAILOVER pour SQL Server
 
• Les services SQL (instance) peuvent basculer entre des
nœuds WSFC (la perte d'un serveur est donc couverte). Si
le stockage échoue, le service s'arrête.
• Disponible dans la version SQL Standard
Cluster FAILOVER pour SQL Server
 
 AAG (AlwaysOn Availability Group )

• La fonctionnalité Groupe de disponibilité est un mélange de mise

en cluster SQL et de mise en miroir SQL (MS la présente
également comme une alternative à la mise en miroir SQL,
obsolète depuis SQL Server 2012).
• L'AG est également basé sur un cluster WSFC
• la différence est que sur chaque nœud une instance SQL
est installée et active
• AAG est composé de répliques (un réplica est un groupe d'une ou
plusieurs bases de données). Il existe un réplica principal et un à
4 répliques secondaires (8 pour SQL 2014) (un réplica secondaire
est une copie des bases de données du réplica principal
 AAG (AlwaysOn Availability Group )

• Un AAG est un groupe de ressources de cluster WSFC (qui contient

au moins les ressources de cluster VNN et VIP sur lesquelles les
clients vont se connecter
• À l'heure T, l'AAG est hébergé par une instance. Il s'agit donc du
réplica principal
• tous les autres réplicas synchronisés sur celle-ci. Il existe deux
types de synchronisation: synchrone et asynchrone
 AAG (AlwaysOn Availability Group )

• Si le réplica principal échoue le basculement automatique s’éffectue

sur un des réplicas secondaires (Modes synchrone)
• Pour le Mode asynchrone seule le basculement manuel qui est
possible
• Sur tous les réplicas d'un groupe de disponibilité, un seul peut être
un «réplica principal» à la fois.
• Par exemple, avec un AG composé de deux nœuds et contenant
deux bases de données, il est impossible d’avoir une base de
données active sur un nœud et le second DB actif sur le deuxième
nœud. Pour réaliser cette configuration, nous devons créer
deux AG (sur les deux mêmes nœuds) avec une base de données
dans chaque AG (il y a donc deux réplica principal,
c'est la configuration que je vais faire dans cet article).
AAG (AlwaysOn Availability Group )
AAG (AlwaysOn Availability Group )
AAG (AlwaysOn Availability Group )
Cluster FAILOVER pour SQL Server
 
• À des fins de comparaison, les groupes de disponibilité
AlwaysOn ne nécessitent pas de stockage partagé.
Solution de haute disponibilité
• LAB1 : Mise en miroir d’une BD
• LAB2 : Cluster FAILOVER pour SQL Server
• LAB3 : AAG (AlwaysOn Availability Group )