SQL Server 2014 : AlwaysON Availability Group dans Azure (Partie 6)

Artikel
07/24/2014

Voici le sixième et dernier article consacré à la mise en place d’une solution SQL Server 2014 AlwayON Availability Group dans Azure. Les articles sont découpés selon le plan suivant :

Ce billet va traiter de la sixième partie, “Test de la bascule AlwaysON”. Pour rappel, à la fin de cette première série d’articles, nous aurons l’architecture suivante :

Test de la bascule AlwaysON

Maintenant que notre groupe de disponibilité est prêt et configuré avec un listener, nous allons tester la bascule d’un serveur à l’autre.

Afin de pouvoir faire le test et se connecter au listener, il faut que l’application cliente soit en dehors du service de Cloud qui héberge le listener.

Connexion depuis un client extérieur au cloud Service

Pour illustrer le groupe de disponibilité, j’utilise le Management Studio qui est installé sur mon Laptop (un lenovo X1 Carbon).

Depuis une machine cliente, lancez SQL Server Management Studio.

La fenêtre « Connect to Server » apparaît.

Théoriquement, le champ « Server type » est grisé mais doit afficher « Database engine ».

Dans le champ « Server name », entrez le nom de votre service de cloud et le point de terminaison ouvert dans le portail Azure. Dans mon exemple c’est :

· Demosqlao.cloudapp.net,55569.

Comment l’authentification Windows n’est pas possible dans notre cas, il faut utiliser un compte SQL. Pour cette démonstration, j’utilise le compte sa, que j’ai activé au préalable sur mes différents serveurs SQL.

Cliquez sur « Connect ».

Une fois connecté au listener, cliquez sur le bouton « New Query ».

Dans la fenêtre de droite, entrez et exécutez la requête suivante :

Select @@servername.

Le résultat vous retourne le serveur actif. Dans mon cas c’est le server SQL1 (A-FRANMERSQL1).

Bascule manuelle

Connectez-vous, via le bureau à distance, sur un de vos serveurs SQL.

Démarrez SQL Server Management Studio et connectez-vous sur votre base de données.

Une fois connectez, faîtes un clic droit sur le dossier « AlwaysON High Availability ».

Dans le menu contextuel, cliquez sur « Show Dashboard ».

Une fois le tableau de bord affiché, cliquez sur le lien, en haut à droite, « Start Failover Wizard ».

La fenêtre de l’assistant s’ouvre. Cliquez sur « Next ».

Dans la partie « Select New Primary Replica », sélectionnez le serveur qui deviendra le nouveau serveur primaire.

Cliquez sur « Next ».

Dans la fenêtre « Connect to Replica », connectez-vous au serveur précédemment sélectionné en cliquant sur le bouton « Connect ».

La fenêtre « Connect to Server » s’ouvre. Entrez les informations de connexion à votre serveur et cliquez sur le bouton « Connect ».

Une fois de retour sur la fenêtre « Connect to Replica », cliquez sur « Next ».

Dans la partie « Summary », cliquez sur le bouton « Finish ».

Une fois la bascule terminée, cliquez sur le bouton « Close ».

Vérification de la bascule

Dans mon exemple, j’ai choisi le serveur SQL2 comme nouveau server primaire. Nous allons vérifier ça depuis notre poste client (qui se trouve en dehors qu service de cloud de notre groupe de disponibilité)

Sur mon poste de travail, via SSMS, exécutez à nouveau la requête.

La requête doit vous retourner le nom du nouveau serveur primaire.

Voilà ! Nous avons donc mis en place une solution de groupe de disponibilité avec listener dans Azure. De plus, Avec SQL Server 2014 il possible d’avoir 8 serveurs de réplica dont 2 synchrones. Ces réplicas peuvent être utilisés dans des sites distants pour des solutions de « disaster recovery ». C’est ce que nous allons voir dans la série d’article suivant, où nous allons étendre notre groupe de disponibilité en installant des réplicas asynchrones dans une autre région Azure.

Franck Mercier

Pour tester Windows Server 2012 R2, Windows 8, SQL Server 2014 et Power BI, vous pouvez télécharger gratuitement une version d’évaluation :

Windows Server 2012 R2: