SQL Server – Les solutions pour créer un Guest Cluster

Si vous suivez régulièrement les billets de ce blog, ou si vous suivez simplement l’actualité autour de Windows, Hyper-V et SQL Server, vous vous demandez probablement quelle technologie utiliser pour monter votre prochain cluster.

Il serait difficile pour moi, voire plutôt présomptueux, de vous dire dès à présent quelle solution est la mieux adaptée à votre situation. On est bien d’accord qu’un audit préliminaire s’impose. Mais néanmoins, voici un petit récapitulatif de l’état de l’art en matière d’installation de cluster SQL Server (FCI) sur des machines virtuelles, qui elles-mêmes peuvent être en haute disponibilité sur un cluster Hyper-V.

Cette liste n’est probablement pas exhaustive, et l’évolution technologique est permanente, ce qui pourrait m’amener à apporter des modification à ce billet. La problématique tourne essentiellement autour du stockage partagé pour l’instance virtuelle.

  • Historiquement, il était possible de disposer d’une ou plusieurs LUN dans les machines virtuelles en utilisant la technologie iSCSI. Il suffit de disposer d’un Target iSCSI, ce peut être Windows Storage Server, Windows Server “ancienne génération ” + le add-in target iSCSI, Windows Server 2012, des utilitaires tels que Starwind Software ou toute baie de disque ayant faisant office de cible iSCSI (comme peut le faire un petit NAS).
    On dispose ainsi de volumes partagés au sein des VMs qu’il suffit d’ajouter dans le stockage du cluster et ensuite de dérouler l’installation de SQL Server.
  • Avec l’arrivée de Windows Server 2012, le paysage du Guest Cluster a évolué. En effet il est a présent possible de disposer de carte HBA virtuelles. Ces cartes virtuelles disposent de leur propre World Wide Name et sont visibles, au même titre que des cartes physiques sur un hôte, afin de configurer le zoning.
    Le transfert de données au travers d’un réseau fibre souffre de moins de latence qu’un réseau de type Ethernet (iSCSI), même si les débits peuvent être comparables. Mais le cout reste plus élevé.
    Les volumes sont alors directement disponibles pour l’installation de SQL Server.
  • SQL Server 2012 est à présent supporté dans une configuration où tous les fichiers des bases de donnes système et utilisateur sont stockés sur un partage réseau de type SMB3. Windows Server 2012 propose la fonctionnalité de scale-out file server, mettant a disposition un partage réseau hautement disponible et insensible au basculement d’hôte. Cette solution est parfaitement acceptable et simplifie la construction un cluster de basculement SQL Server, car du coup, on n’a plus besoin de stockage partagé directement dans les machines virtuelles du cluster SQL, mais seulement d’un partage SMB3.
    Cet article détaillait pas à pas l’installation de SQL Server sur un Scale-Out File Server. Très simple à transposer pour une installation cluster, comme je m’étais amusé, par simple défi technologique, à créer un cluster SQL Server Express sur Scale-Out File Server.
    Cette solution très élégante permet de simplifier également la migration d’une base d’un serveur à l’autre, ou bien pour gagner du temps lors d’une montée de version, qui s’apparente alors à un simple detach / attach au niveau de la base de donnée.
  • Windows Server 2012 R2 apporte bon nombre d’innovations dont certaines liées à la fonctionnalité Hyper-V et au cluster (quorum dynamique). On peut tout particulièrement noter qu’il est à présent possible de partager un fichier VHDX entre machines virtuelles. Le stockage partagé d’un cluster devant alors très simple à manipuler car il s’agit de simples fichiers stockés sur un partage SMB3 hautement disponible (scale-out file server) ou bien sur un disque CSV (détaillé ci dessous) du cluster Hyper-V. SQL Server 2014 supporte donc le fait que les données d’une instance virtuelle soit hébergée sur des disques partagés de type Shared VHDX. la mise en place n’est pas très compliquée et est détaillée dans cet article.
    Encore une fois il s’agit là d’une technique intéressante car le fichier VHDX peut être partagé entre de multiples VMs et peut ainsi faciliter des migrations ou bien un rééquilibrage manuel de la charge de certaines instances.
  • Les disques CSV existent depuis un certain temps maintenant. Cependant, ils étaient réservés au cluster Hyper-V. Ces disques, des volumes partagés de type Fiber Chanel, iSCSI ou bien Shared VHDX ne sont plus soumis à une réservation SCSI3 au niveau du volume, mais au niveau du fichier, ce qui permet à plusieurs nœuds, plusieurs groupes de ressources ou plusieurs applications de lire et écrire en même temps sur un même volume, tant qu’il ne s’agit pas du même fichier. La notion de propriété est transférée du nœud vers un service.
    Il est ainsi possible d’installer plusieurs instances SQL Server sur un seul volume CSV partagé. La distinction se fait alors au niveau du répertoire. Encore une fois, cela œuvre dans le sens de la simplification d’installation et d’une plus grande modularité de la solution offrant plus de possibilités en terme d’installation ou de migrations.
  • Il est également possible de disposer d’un stockage partagé en s’appuyant sur du FCoE. Je n’ai malheureusement pas eu l’occasion de tester ce genre de choses, je ne pourrais guerre donner d’avis sur cette méthode consistant à encapsuler des trames FC dans des trames Ethernet.

Vous le voyez, il existe différentes solutions afin de parvenir à construire un cluster de basculement à l’intérieur de machines virtuelles, qui elles aussi peuvent être en haute disponibilité, en s’appuyant sur une partie des solutions présentées ici.

Pour ma part, difficile de faire un choix sur ce que je considère comme la meilleure solution, car chacune possède ses avantages et inconvénients. N’oubliez pas non plus que le cluster physique, sans couche de virtualisation, n’est pas obsolète, occulté par une frénésie de virtualisation.

Ne perdez pas de vue non plus qu’il est également possible de virtualiser le stockage, ce qui peut offrir des gains en performance (oui oui !!), des gains en souplesse, etc. Probablement un marché à suivre.

Et surtout pensez à ne pas oublier les fonctionnalités offertes par SQL Server nativement pour aller vers la haute disponibilité et/ou le disaster recovery, sans pour autant s’appuyer sur un cluster de basculement : le log shipping, la mise en miroir de bases de données, la réplication (P2P), les groupes de disponibilités qui se voient maintenant greffé une option hybride en disposant de réplicas on-premise et de réplicas dans le cloud. Sans oublier non plus qu’une base de données peut aussi voir ses fichiers stockés également sur Azure alors que votre instance est on-premise.

Bref, vous l’aurez compris, le panel des possibilités offertes dans ce domaine est large et le métier d’architecte de bases de données, de consultant, de DBA, de formateur n’a jamais été aussi passionnant.

Si vous avez des questions ou si vous souhaitez mettre en place une configuration SQL Server hautement disponible vous correspondant, n’hésitez pas à me contacter.

happy HA !

A propos Christophe

Consultant SQL Server Formateur certifié Microsoft MVP SQL Server MCM SQL Server 2008
Cet article, publié dans Hyper-V, SQL Server, Windows, est tagué , , , , , , , , . Ajoutez ce permalien à vos favoris.

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