[SQL Server] Mise-en-place du database mirroring (via SSMS)

Ce billet traite de la mise-en-place d’une solution de database mirroring via SQL Server Management Studio (SSMS), que ce soit en mode synchrone (avec ou sans failover automatique) ou en mode asynchrone. Il concerne toutes les versions de SQL Server à partir de 2005. Le mode d’authentification par certificat sera utilisé dans nos exemples. Pour comprendre le fonctionnement du database mirroring, référez-vous au billet [SQL Server] Un peu de théorie sur le database mirroring.

Pré-requis général du database mirroring

Pour mener à bien la mise-en-place du database mirroring, voici un rappel des pré-requis généraux issus du billet [SQL Server] Mise-en-place du database mirroring (via T-SQL) :

  • Les deux serveurs (le principal) et le secondaire (ou miroir)) aient la même version de MSSQL (supérieur ou égal à 2005), ainsi que la même édition.
  • Que le serveur miroir ait assez d’espace pour la base de données secondaire.
  • Que le serveur principal n’ait pas de groupes de fichiers de type FILESTREAM.
  • Que le serveur sur lequel se trouve la base de données miroir doit permettre d’avoir une charge moyenne inférieure à 50% du CPU en cas d’utilisation en mode synchrone. En effet, en cas de surcharge (>50% du CPU consommé), le basculement (i.e., « transformation » de la base de données secondaire en base de données principale) est impossible à cause d’un gros temps de latence de la session de mirroring permettant aux bases de données concernées (i.e., base de données principale, base de données secondaire) de communiquer.
  • Chaque base de données concernée par la même session de mirroring doit avoir la même collation.
  • Le protocole de canaux nommés (Named Pipes) doit être activé.
  • Les serveurs doivent être accessibles entre eux via ce qu’on appelle FQDN (Fully Qualified Domain Names) : <nom_serveur>.<nom_domaine>.local ou <nom_serveur>.<suffixe_dns_primaire>. Si les serveurs sont en Workgroup, il faut idéalement créer des alias dans le fichier host de chaque serveur pour que cette résolution puisse fonctionner.
  • Avant tout basculement d’une base principale vers une base secondaire, assurez-vous que le(s) login(s) SQL aient le même identifiant de sécurité (SID) des deux côtés de façon à ce que le mapping du (des) login(s) SQL se fasse automatiquement pour la base secondaire devenue miroir. Pour plus de détails, voir billet [SQL Server] Eléments d’audit et opérations avancées : database mirroring.

Dans notre exemple de mise-en-place, nous supposerons :

  • Que l’on possède 3 serveurs :
    • SRV-SQL01, comme serveur principal.
    • SRV-SQL02, comme serveur secondaire (ou miroir).
    • SRV-SQL03, comme serveur témoin (ou witness).
  • Qu’on ait pour nom de domaine, IFC.
  • Qu’on veuille mettre en miroir une base de données nommée IFC_SUITE située sur le serveur SRV-SQL01.
  • Que les certificats Cert_SQL0x (où x est le numéro du serveur) et les endpoints
    Endpoint_Mirroring ont été créés (voir billet [SQL Server] Mise-en-place du database mirroring (via T-SQL)).

Modus operandi de mise-en-place du database mirroring

    … en mode synchrone avec failover automatique

Avant toute configuration via SSMS, réalisez les premières étapes relatives à la création en T-SQL des certificats, des endpoints à configurer pour qu’ils les utilisent et des logins SQL vues dans le billet [SQL Server] Mise-en-place du database mirroring (via T-SQL).

Puis sur le serveur principal, sous SSMS :

  • Clic-droit sur la base de données concernée, dans l’explorateur d’objets, puis sélection de Miroir
    (via Tâches) :
  • Accès aux paramètres de sécurité et de connexion de la session de database mirroring :

    Cela va lancer l’assistant de configuration :

  • Cliquez sur Suivant et suivez les étapes suivantes :
    • Inclusion d’un serveur témoin (witness) :

    • Choix du serveur destiné à accueillir les informations de configuration de sécurité :

    • Configuration du serveur principal et de son endpoint (point de terminaison) :

      Le port d’écoute est spécifié automatiquement par MSSQL. Mais il est possible d’en choisir un autre à condition qu’il soit ouvert et disponible, et donc non-utilisé par une autre application. Par ailleurs, ici, l’endpoint a été arbitrairement nommé Endpoint_Mirroring en référence à l’endpoint préalablement créé via T-SQL.

    • Configuration du serveur miroir et de son endpoint :

      Après avoir sélectionné dans la liste des serveurs disponibles SRV-SQL02, une boîte de dialogue de connexion à ce serveur va s’ouvrir :

      Si la connexion fonctionne, le serveur distant est sûr d’être accessible. Il reste alors à renseigner éventuellement le nom de l’endpoint et, si la valeur par défaut ne satisfait pas, le numéro du port d’écoute, puis de passer à l’étape suivante.

    • Configuration du witness et de son endpoint:

    • Spécification des comptes de connexion inter-instances :

      Vu qu’il a été prévu d’utiliser des certificats, car plus sécurisés, laissez les champs vides et passez à l’étape suivante.

    • Validation des configurations réalisées :

      Si tout va bien le résultat sera le suivant :

  • Lancement de la session de mirroring.

A la fin de la configuration du database mirroring, une boîte de dialogue s’affiche afin de permettre de soit lancer tout de suite la session de mirroring, soit le faire plus tard :

Il est possible que l’assistant configure automatiquement une adresse réseau non-FQDN, à savoir, sous la forme <Nom_serveur> :<port>, ce qui est à la fois peu pratique et peu conventionnel. Dans ce cas, passez à l’étape suivante en pressant sur Ne pas démarrer la mise en miroir.

  • Spécification d’une adresse FQDN pour chaque serveur ainsi que le port d’écoute de l’endpoint, puis lacement de la session de database mirroring:

… en mode synchrone sans failover automatique

Suivez les mêmes étapes que pour le mode synchrone avec failover automatique, sauf pour la création du witness (i.e., étape relative à l’inclusion d’un serveur témoin).

Si le database mirroring est déjà configuré, mais que l’on souhaite désactiver l’utilisation d’un witness pour pouvoir être en mode synchrone sans failover automatique, il suffira d’aller dans les propriétés de database mirroring de la base principale, de laisser la case relative au témoin vide (c’est-à-dire, en supprimant son adresse TCP), puis de cocher Haute-sécurité sans basculement automatique (synchrone) si ce n’est déjà fait.

… en mode asynchrone

Suivez les mêmes étapes que pour le mode synchrone avec failover automatique (en ignorant, bien sûr, la création du witness), puis au moment de la mise en miroir de la base principale optez pour l’option correspondant à la mise-en-miroir en mode asynchrone (haute-performance).

Pour aller plus loin…

… vous pouvez consulter le billet [SQL Server] Eléments d’audit et opérations avancées : database mirroring.

Publicités

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