Partager via

Haute disponibilité SQL Server dans Azure avec SQLServer AlwaysOn

  • Article

Assurer la continuité des services proposés par le système d’information nécessite une analyse de ses dépendances, de ses composantes critiques et la définition d’objectifs tels que le RPO (Recovery Point Objective : perte de données maximum acceptable suite à un sinistre ou un problème majeur) ou le RTO (Recovery Time Objective : délai maximum acceptable de redémarrage de l’activité suite à un sinistre ou un problème majeur). Certaines solutions offrent des fonctions natives de haute disponibilité : c’est le cas de SQL Server. Et progressivement le support de ces mécanismes est intégré dans le Cloud avec Windows Azure…

En effet, SQL Server 2012 fournit plusieurs options permettant de garantir un haut niveau de disponibilité pour un serveur ou une base de données.

· Copie des journaux de transaction (« Log Shipping ») :

La copie des journaux de transaction fonctionne au niveau de la base de données. Vous pouvez utiliser la copie des journaux de transactions pour gérer une ou plusieurs bases de données de secours semi-automatique (appelées bases de données secondaires) pour une base de données de production unique correspondante appelée base de données primaire.

· Mise en miroir de bases de données (« Database Mirroring ») :

La « Mise en miroir de base de données » est une solution qui fonctionne au niveau de la base de données et permet d'optimiser sa disponibilité en utilisant presque instantanément le basculement. La mise en miroir de base de données peut être utilisée pour gérer une base de données de secours ou une base de données miroir pour une base de données de production correspondante désignée sous le nom de base de données principale. A la différence de SQL Entreprise, SQL Standard ne rend possible le Mirroring qu’en mode synchrone (« Safety Full Only » pour la standard) : l’opération de « Redo » n'est alors faite que sur un seul thread : https://social.msdn.microsoft.com/Forums/en-US/sqlreplication/thread/d591a375-8a2f-4f2e-b6cf-9c02e60d3b8b. Il est possible d’utiliser SQL Express comme serveur témoin : https://msdn.microsoft.com/en-us/library/cc645993.aspx

· Instances de cluster de basculement AlwaysOn (« AlwaysOn Failover Cluster Instances ») :

Les instances de cluster de basculement AlwaysOn exploitent la fonctionnalité WSFC (clustering de basculement Windows Server) pour fournir une haute disponibilité locale grâce à la redondance au niveau de l'instance de serveur : une instance de cluster de basculement (FCI). Une instance FCI est une instance unique de SQL Server installée sur plusieurs nœuds WSFC (clustering de basculement Windows Server) et, éventuellement, sur plusieurs sous-réseaux. Sur le réseau, une instance de cluster de basculement FCI apparaît en tant qu'instance de SQL Server s'exécutant sur un ordinateur unique, mais elle permet le basculement d'un nœud WSFC vers un autre en cas d'indisponibilité du nœud actuel.

· Groupes de disponibilité AlwaysOn (« AlwaysOn Availability Groups ») :

Introduite dans SQL Server 2012, cette fonction offre une solution de haute disponibilité et de récupération d'un ensemble de bases de données. Un groupe de disponibilité prend en charge un environnement de basculement pour un ensemble de bases de données, appelées bases de données de disponibilité, qui basculent de concert. Un groupe de disponibilité bascule au niveau d'un réplica de disponibilité : un ensemble de bases de données primaires en lecture-écriture et un à quatre ensembles de bases de données secondaires correspondantes (5 répliques dans SQL Server 2012, 9 dans SQL Server 2014). Éventuellement, les bases de données secondaires peuvent être rendues disponibles pour l'accès en lecture seule et/ou certaines opérations de sauvegarde. Cette fonction nécessite le déploiement des instances SQL Server sur des nœuds de clustering de basculement Windows Server (WSFC) mais ne requiert pas le « clustering de basculement SQL Server ».

L’architecture logique d’un exemple représentatif de solution AlwaysOn est illustrée dans le diagramme suivant :

image

Le tableau suivant synthétise les différentes options proposées par les solutions permettant de mettre en œuvre une solution SQL Server hautement disponible.

image

L’utilisation des groupes de disponibilité de SQL Server AlwaysOn est maintenant supportée dans les machines virtuelles de Windows Azure (c’est d’ailleurs la seule offre « Cloud public » à supporter ce type de scénario haute disponibilité sur SQL Server). Il est donc maintenant possible de déployer un ou plusieurs base(s) de données secondaire(s), ce qui non seulement améliore la disponibilité des serveurs SQL, mais optimise leur usage en permettant de les décharger des tâches de reporting BI et de sauvegardes.

Cette nouveauté requiert le déploiement d'un correctif de Windows Server 2012, qu’il faut installer à l'intérieur de chaque VM Azure hébergeant un réplica de groupe de disponibilité dans le Cluster. Ce hotfix modifie le fichier CLUSRES.DLL et peut être téléchargé depuis l'adresse suivante : https://support.microsoft.com/kb/2854082
Grâce à ce correctif, le Cluster de serveurs Windows modifié la logique de la ressource « adresse IP », afin de répondre aux sondes personnalisées (custom probes) du Load Balancer Azure puis de rediriger le trafic entrant uniquement vers la VM correspondant au nœud actif hébergeant le réplica primaire du groupe de disponibilité de la base de données.

Il n'est pas possible de créer plus d'un écouteur de groupe de disponibilité (« Availability Group Listener ») : cette limitation vient du fait que le nom de réseau Cluster utilisé par cet écouteur est l'adresse IP publique du Service Cloud...

La configuration de la chaîne de connexion à l’infrastructure SQL Server déployée utilise le point de terminaison de l'écouteur du groupe de disponibilité :

Server=tcp:AGListener,1433;Database=MyDB;IntegratedSecurity=SSPI

Elle permet d’acheminer automatiquement les connexions de base de données vers le nœud primaire. Le Load Balancer Azure achemine les requêtes vers un nœud secondaire dans le cas d'un scénario de basculement automatique ou manuel. Cette configuration de haute disponibilité de SQL Server dans Azure peut aussi être utilisée afin d'assurer la continuité de service pendant les opérations de mise à jour.

image

Le support de cette fonction permet également de mettre en place des scénarios de reprise après sinistre pour les solutions SQL Server à demeure, en déployant une ou plusieurs répliques secondaires sur des Machines virtuelles Windows Azure. En outre, les réplicas secondaires déployés dans le Cloud permettent de décharger l’infrastructure à demeure de la production de rapports et des sauvegardes. Ce dernier point présente un intérêt complémentaire pour les entreprises qui exigent le maintien des sauvegardes en dehors du datacenter pour des raisons de conformité.

L'utilisation des groupes de disponibilité AlwaysOn requiert une configuration préalable de WSFC pour les nœuds de réplica, qui exige à son tour que le ou les contrôleurs de domaine Active soient accessibles à partir des autres ordinateurs virtuels, ce qui nécessite un VNET qui sera utilisé par toutes les VM de la topologie de configuration.

       

Pour obtenir plus d’informations, je vous invite à consulter les livres blancs et documentations dont voici les références :