Installation de SQL Server 2012 sur un Scale-Out file Server

Lors d’un article précédent, j’ai détaillé les étapes nécessaires à l’installation d’un Scale-Out File Server.

SMB 3.0 permet ainsi aux ressources du cluster de fichier de basculer sans qu’il y ait d’impact notable au niveau de l’applicatif client. Ainsi il est tout a fait possible de faire supporter des volumes destinés à Hyper-V ou SQL Server sur ce type d’infrastructure. En tenant compte des autres avancées de Windows Server 2012 comme le NIC Teaming, combiné aux cartes réseau 10GB, on peut aisément imaginer que la solution peut monter en charge.

Pourquoi installer les fichiers de base de données sur un serveur de fichier, alors qu’un stockage centralisé est nécessaire pour monter l’infrastructure du scale-out file server ?

Une des raison qui me vient assez rapidement à l’esprit concerne …. la migration.

Prenons le cas d’une instance qui doit être migrée (cluster ou non cluster, cela ne fait pas de différence ici). je dois :

• soit utiliser la technique du backup /restore
• soit utiliser la technique du log shipping si la phase de transition doit durer
• soit utiliser un database mirroring
• soit utiliser un scénario à base de réplication
• soit utiliser un bon vieux detach_db / attach_db

C’est ce dernier cas qui m’intéresse particulièrement, car même avec un stockage partagé, il faut

• détacher la base
• déprésenter la lun du serveur
• refaire le zoning (dans le cas d’un réseau fibre)
• présenter la lun au serveur
• attacher la base

Et tout cela en espérant que ce soit la seule base présente sur le disque, sinon, je suis contraint de migrer toutes les bases en même temps. Bref, pas très confortable si l’on doit migrer quelques dizaines, ou centaines de bases …

Si les fichiers des bases sont sur un partage réseau, il suffit alors de faire un detach / attach. Pour autant que les droits sur le share sont corrects (pour les comptes de service, ce qui peut se préparer à l’avance), la migration est grandement facilitée …

Place à la pratique : comment installer une instance SQL dont les fichiers de données sont stockées sur un partage réseau ?

Très simple mon cher. Suivez le guide.

Je ne vais pas m’appesantir sur les prérequis d’installation SQL Server : Framework 3.51 (le 4.0 est inclus dans Windows Server 2012). D’autres articles sur ce blog ont largement couvert le sujet.

Je ne vais pas non plus mettre 20 copies d’écran, c’est déjà fait. je vais donc me concentrer sur l’essentiel.

Sur l’écran d’installation “Database Engine Configuration” il faut renseigner la rubrique “Data Root Directory” avec le chemin du partage réseau. Notez que l’on peut aussi répartir sur plusieurs partages afin, par exemple, d’opter pour un Share commun pour toutes les sauvegardes des instances SQL Server.

Si vous avez suivi le précédent billet traitant de la création du scale-out file server, les autorisations sur le partage réseau doivent intégrer le compte de service de l’instance SQL. Lors de l’installation de SQL Server, un message nos invite à vérifier que les autorisations sur ce share ont bien été accordées au compte de service.

Il est aussi possible de spécifier ce paramètre lors de l’utilisation de la commande SETUP.EXE pour ceux qui souhaitent automatiser leurs installations :

Setup.exe /q /ACTION=Install /FEATURES=SQL /INSTANCENAME=MSSQLSERVER 
/SQLSVCACCOUNT="ConseilIT\SQLService" /SQLSVCPASSWORD="" 
/AGTSVCACCOUNT="ConseilIT\SQLService" /AGTSVCPASSWORD="" 
/INSTALLSQLDATADIR="\\FS-SQL\StandAlone\" 
/SQLSYSADMINACCOUNTS="Conseilit\SQLDBA" 
/IACCEPTSQLSERVERLICENSETERMS

And that’s all folks !

Les ordres SQL suivant sont compatibles avec la syntaxe du fileshare :

• CREATE DATABASE
• ALTER DATABASE
• RESTORE DATABASE
• BACKUP DATABASE
• sp_attach_db
• sp_attach_single_file_db

La création d’une base sur le fileshare se fait tout aussi simplement. Soit on utilise le répertoire par défaut, soit on spécifie le chemin lors de l’ordre create database.

Pour ma part, je pense que ce type d’infrastructure à un intérêt. La migration simplifiée entre instance en est un. Mais je ne pense pas pour autant qu’il faille systématiquement travailler de la sorte. It depends …

En tout état de cause, il s’agit d’une possibilité supplémentaire offerte dans une architecture hautement disponible et évolutive.

Une solution a base de groupe de disponibilité dont les serveurs sont virtualisés sur des Windows Server 2012 avec Hyper-V 3.0 dont les fichiers VHDX sont stockés sur un cluster de fichier de type Scale-Out avec un stockage partagé digne de ce nom… Plein de possibilités de HA/DR/Scale-Out s’offrent à nous !

Happy SQL Server sur Scale-Out File Server !