Installation d’un Groupe de Disponibilité avec Denali – Partie 4

Cet article fait partie d’une série dont vous trouverez le sommaire ici : https://blogs.technet.com/b/sql/archive/2011/09/08/installation-d-un-groupe-de-disponibilit-233-avec-denali-introduction.aspx

Création du Groupe de Disponibilité (Availability Group)

Qu'est-ce qu'un Availability Group ?

Comme nous l'avons vu en introduction, l'Availability Group permet de répondre aux besoins suivants :

· La solution permet d'assurer une bascule simultanée de toutes les bases de données du groupe en cas d'incident. Cette approche permet de répondre aux besoins de disponibilité des applications qui accèdent à plusieurs bases de données en même temps sans avoir à mettre en œuvre des contournements complexes.

· Répliquer les données sur plusieurs instances (le maximum étant 5 copies au total) tout en permettant aux applications d'y accéder via un nom virtuel unique sans avoir besoin de solution de réplication matérielle.

· Accéder aux copies répliquées en mode lecture seule pour permettre de décharger l'instance principale de la charge générée par exemple par les sauvegardes ou les rapports.

· Solution de cluster dispersé géographiquement purement à base de logiciel.

Cette solution de disponibilité peut être vue comme une combinaison des bons côtés du mirroring et du cluster à bascule que nous connaissions avec SQL 2008 R2.

Avant de créer à proprement parler le groupe de disponibilité, il faut monter une base de données sur l'un des deux serveurs SQL. Prenons par exemple la base de données d'exemple AdventureWorks disponible en téléchargement pour Denali à cette adresse : https://msftdbprodsamples.codeplex.com/releases/view/55330

La procédure pour remonter les bases de données est disponible à cette adresse : https://social.technet.microsoft.com/wiki/contents/articles/sql-server-samples-readme.aspx

Création du Groupe de Disponibilité

La création et configuration de l'Availability Group se fait dans SSMS (SQL Server Management Studio). Si la fonctionnalité a bien été activée comme indiquée à l'étape précédente, le conteneur "Availability Group" apparait dans SSMS sous le conteneur "Management".

Il est possible de lancer l'assistant de création d'un Availability Group (AG).

Donnez un nom au groupe de disponibilité, par exemple, dans notre cas : AdventureWorksAG et cliquez sur Suivant.

Il est alors possible de choisir la ou les bases de données qui feront partie de l'Availability Group que nous sommes en train de créer. Si vous choisissez plusieurs bases de données, toutes ces bases basculeront en même temps.

Pour notre maquette, nous choisirons uniquement la base "AdventureWorksDW". Vérifiez que le status indique bien "Meets prerequisites".

Indiquez ensuite les instances SQL qui ont été activée pour supporter AlwaysOn qui possèderont une copie de la base de données. Par défaut l'instance sur laquelle SSMS est connecté est ajouté à la liste des réplicas.

Ajoutez le server SQL-SRV-2 à la liste des réplicas possibles de la base AdventureWorksDW.

Note: Il faut démarrer le service "SQL Server Browser" si ce n'est déjà fait et mettre le service en démarrage automatique pour le bon fonctionnement du cluster HADR.

Il est possible de modifier le mode du réplica pour passer du mode 'Automatic failover' (mode proposé par défaut) aux modes 'High performance' (commit asynchrone et bascule forcée avec potentielle perte de données) ou 'High safety' (bascule manuelle seulement). Nous laisserons le mode 'Automatic failover'.

Le 'Connection Mode in Secondary role' est plus intéressant. C'est ce paramètre qui autorise ou non les connexions sur la copie de la base de données. Par exemple si vous avez une application de génération de rapport, vous pouvez décharger l'instance primaire, utiliser ses ressources pour servir au mieux les clients et utiliser les ressources de l'instance secondaire pour servir les fonctionnalités de reporting. Les modes autorisés sont :

· Disallow connections : Aucune connexion n'est autorisée sur l'instance si elle est en mode secondaire. Par exemple, dans le cas où la latence de réplication n'est pas permise.

· Allow only read-intent connections : Seulement les applications qui indiquent dans la chaine de connexion le mode 'read-intent' pourront se connecter à cette instance en mode secondaire.

· Allow all connections : Toute application peut se connecter à l'instance, peu importe la chaine de connexion mais seulement des opérations de lecture seront possibles sur la base.

Pour les besoins de notre maquette nous allons prendre le dernier mode : "Allow all connections".

Dans l'étape suivant nous allons renseigner le nom réseau du Groupe de Disponibilité. C'est ce nom virtuel qui sera utilisé ensuite par les clients pour se connecter à la(les) base(s) du groupe. Ce nom est appelé un Listener.

Vous pouvez choisir l'option client DHCP dans le cas où vous avez un serveur DHCP sur le réseau. Cette option est particulièrement intéressante dans le cas de cluster répartit sur plusieurs subnets. Lors de la bascule d'un nœud à l'autre, le cluster prendra une IP du subnet où il se trouve.

Dans le cas où vous voudriez ajouter une IP manuellement, sélectionnez l'option "Skip". Vous ajouterez un Listener manuellement depuis SQL Server Management Studio (SSMS) une fois le groupe de disponibilité créé.

Il est aussi possible lors de cette étape de changer le port d'écoute. Pour notre maquette, nous laisserons le port par défaut.

Pour le moment la base de données est sur le serveur SQL-SRV-1. La mise en œuvre du Groupe de Disponibilité autorise plusieurs modes pour la copie initiale des données vers SQL-SRV-2 :

· SQL Denali effectue la synchronisation initiale des données avec une mécanique de sauvegarde / restauration automatisé. Cette opération nécessite l'utilisation d'un partage sur le réseau et peut ne pas être appropriée dans le cas de manipulations de gros volumes de données.

· Pour les scénarios manipulant des gros volumes de données ou dans le cas où une copie existe déjà sur la ou les instances cible, le système laisse la main au DBA pour mettre les copies en place. Dans ce cas, le système ne procède pas à la synchronisation initiale.

Dans le cas de notre maquette, pour des raisons de simplicité, nous allons choisir la première option. Le partage peut être sur n'importe quel serveur sur le réseau mais il faut qu'il soit accessible par tous les nœuds du cluster pour pouvoir procéder à la restauration des données.

La configuration du groupe de disponibilité est maintenant terminée. Laissez l'assistant vérifier que tout est bon.

Si vous souhaitez scripter cette opération, vous pouvez obtenir le script au moment du résumé.

Et le résultat de l'opération :

Il reste à vérifier que notre cluster fonctionne !

C’est ce que nous allons voir dans l’article suivant, disponible à cette adresse : https://blogs.technet.com/b/sql/archive/2011/09/20/installation-d-un-groupe-de-disponibilit-233-avec-denali-partie-5.aspx