Le cluster SQL entre dans la catégorie des solutions de haute disponibilité. Cependant pour cette dernière, le sous système disque qui est partagé par au moins deux de ces n?uds est connu comme étant le SPOF (ou Single Point Of Failure). Il existe plusieurs techniques pour augmenter la disponibilité et la résistance aux pannes de ce sous système comme la mise en place d’architectures RAID mais il faut compter aussi avec la liaison entre le serveur et les disques. De nos jours, la plupart des entreprises possèdent un SAN. Ceux-ci sont principalement de deux types : SAN FC et SAN iSCSI. Les SAN FC sont certainement les plus répandus. Ceux-ci utilisent la fibre optique avec le protocole FC. Les SAN ISCSI ont vu le jour un peu plus tard (en 2002) et tendent à être de plus en plus populaires  car la mise en place de ISCSI devient de moins moins onéreuse par rapport à FC. Les 2 protocoles utilisent différents équipement réseaux pour faire communiquer le serveur avec le stockage. Imaginez un peu que cette liaison soit rompue … à y penser c’est maintenant le système de liaison qui devient notre SPOF. Heureusement pour nous il est possible d’utiliser des liaison multiples pour rendre notre système de liaison redondant. Ces liaisons peuvent être gérées directement au niveau matériel (cartes HBA par exemple) ou également au niveau système d’exploitation avec Windows Server Storage 2008 R2 et MPIO par exemple. Dans ce billet nous verrons comment utiliser MPIO avec le protocole iSCSI dans le cadre d’une mise en place d’un cluster SQL Server 2008 R2.

Avant une mise en pratique une petit explication me semble nécessaire sur IiCSI.

 Qu’est ce que le protocole ISCSI ?

Le but ici n’est pas faire un cours détaillé sur le protocole car je n’ai aucune prétention à ce sujet et il existe bien des articles intéressants à ce sujet sur internet ou dans la littérature. Simplement, c’est un protocole qui utilise la couche TCPIP pour transporter des commandes SCSI.  Attention cependant à ne peut faire l’amalgame avec les connexions TCPIP classiques utilisés par les NAS !!! En effet ISCSI propose un échange de données au niveau bloc alors que les échanges entre un serveur et un NAS se fait au niveau fichier. De plus dans un réseau TCPIP classique certaines paquets peuvent être perdus et n’arrivent pas forcement dans l?ordre. Avec ISCSI une trace de la séquence des commandes est gardée dans une file d’attente et ceci dans l’ordre de leur exécution. Les performances de ce protocole peuvent être comparables à celles du protocole FC d’après ce que j’ai pu voir. D’ailleurs si un client se dévoue pour être volontaire pour faire un test grandeur nature je suis preneur :-).

Le protocole ISCSI introduit deux fonctions majeurs que sont les cibles (Target) et les initiateurs (Initiators). Les cibles représentent notre stockage et les initiateurs les équipements qui s’y connectent. La connexion entre ces 2 éléments peuvent être sécurisés via une authentification utilisant CHAP ou IPSec. Voici un schéma simplifié du système :

Avec l’introduction des chemins multiples on dédouble la liaison entre l’initiateur et une cible. De cette façon si une liaison se rompt l’autre prend le relais. Un autre avantage des chemins multiples qu’elle peut augmenter les performances du sous système disque si les chemins sont utilisés en mode round-robin.

 

 Pourquoi Windows Server Storage 2008 R2 et ISCSI Target ?

Tout simplement pour simuler un stockage distant à défaut d’en avoir un réel. Ce stockage virtuel pourra être utilisé en tant que NAS pour le stockage des fichiers d’entreprises ou encore comme stockage partagé utilisé dans une topologie cluster. C’est ce dernier cas qui nous intéresse ici. Pour ce qui est de l’installation de iSCSI Target et de la mise à disposition d’une cible je vous invite à lire l’excellent billet de Christophe Laporte sur le sujet.

 

 Cas d’étude

La configuration que j’utilise est la suivante :

 

• Deux serveurs clust20081 et clust20082 mis en cluster avec SQL 2008 R2 (SQL2008CLUST) et Windows Server 2008 R2 (WIN2008CLUST)
• Un serveur de stockage installé avec Windows 2008 Storage R2 et ISCSI Target V3.3 nommé storage
• 3 disques installés sur le serveur de stockage en tant que périphérique (device). Chaque périphérique doit appartenir à 2 cibles distinctes lorsque ceux-ci sont utilisés dans une configuration cluster. Nous avons ici 3 périphériques que nous appellerons DATA, LOG et BACKUPS. Ceci fait un total de 6 cibles.

Je précise tout de suite que la situation présente n’est pas idéale et ceci pour plusieurs raisons :

• J’utilise un même et unique réseau sur mon environnement virtuel alors qu’il faudrait distinguer physiquement les sous réseaux configurés dans le cadre du test.
• Le réseau public est utilisé par le cluster SQL et une des liaisons ISCSI entre chaque noeud et le stockage. Il faudrait implémenter une carte réseau supplémentaire pour avoir au final un sous réseau dédié pour chaque chemin.

Pour résumer nous devons implémenter deux chemins distincts entre chaque noeud du cluster et le stockage. Pour cela il faudra installer MPIO que nous utiliserons conjointement avec iSCSI. Nous appliquerons la configuration pour le périphérique nommé BACKUPS. La procédure sera valable pour n’importe quelle cible présente sur le serveur de stockage.

Tout d’abord voici ce que donne ma configuration de stockage dans l’interface de gestion ISCSI Target sur le serveur storage :

On retrouve ici les trois périphériques et leurs cibles respectives (deux pour chacun des périphériques). Observons les propriétés d’une cible :

Dans l’onglet General on retrouve le nom de la cible, sa description et un identifiant unique appelé IQN (iSCSI Qualified Name). Je vous laisse vous référer à la RFC 3720 pour déchiffrer la nomenclature relative aux IQNs.

L’onglet iSCSI Initiators permet d’autoriser la connexion à un initiateur. Il est possible d’identifier un initiateur par son nom DNS, son adresse IP, son adresse MAC ou encore par son IQN. Cette dernière méthode est à préférer.

Comment nous l’avons expliqué un peu plus haut, il est possible d’introduire une couche supplémentaire de sécurité en utilisant une authentification basée sur CHAP mais nous ne l’utiliserons pas ici. Cependant cela peut être une bonne pratique dans un contexte de production. L’onglet Virtual Disks, quant à lui, permet de connaître le ou les périphérique de stockages pouvant être connectés via la cible concernée.

Enfin, on peut noter que le serveur de stockage possède 2 cartes réseaux et qui seront utiliser pour gérer les différents chemins configurés.

On constate que deux cartes réseaux sont utilisées pour notre stockage avec les IP suivantes : 192.168.92.25 et 192.168.92.26

Passons maintenant au paramétrage côté initiateur (soit un des noeuds du cluster). Sur le serveur CLUST20081, il faut installer MPIO via les features de Windows Server 2008 R2. Ensuite il faut activer l’utilisation de MPIO conjointement avec les initiateurs iSCSI.

La fenêtre des propriétés MPIO dans l’onglet MPIO Devices montre qu’aucun périphérique Hardware iSCSI n’a le support MPIO pour le moment.

Dans l’onglet Discover Multi-Paths il faut ajouter les supports de types iSCSI et cliquer sur le bouton Add comme ci-dessous :

Vous aurez sans doute remarqué que la fenêtre est grisée car en réalité j’ai déjà activé le support pour ISCSI sur mes deux noeuds de cluster. Un redémarrage du serveur est ensuite nécessaire. Une fois le serveur redémarré, on constate qu’un périphérique Hardware possède le support MPIO. En d’autres termes, les chemins multiples seront pris en charge pour le périphérique concerné.

Il est donc temps de connecter notre cible associé au périphérique de stockage nommé BACKUP au serveur CLUST20081. Pour cela il faut lancer la console de gestion des initiateurs ISCSI.

A noter que dans mon cas j’ai deux périphériques de stockage qui sont déjà connectés au serveur CLUST20081 (DATAS ET LOGS). Pour initier une connexion au stockage, il faut commencer par se connecter au portail iSCSI sur le serveur de stockage en entrant une adresse IP ou un nom réseau. Si le portail est déjà enregistré suite à une précédente connexion, un simple rafraichissement des cibles favorites devrait suffire. Nous pouvons voir que la cible relative au périphérique de stockage BACKUP est présente. Celle-ci est identifiée par son IQN et la connexion est pour le moment inactive.

En cliquant sur le bouton Connect on va pouvoir initier une connexion entre une cible et un initiateur. L’option par défaut Add this connextion to the list of Favorites Targets … permettra une reconnexion automatique en cas de redémarrage du serveur. Pour activer les chemins multiples il faut activer l’option Enable multi-path et cliquer sur le bouton Advanced.

Les informations concernant le nouveau chemin doivent être entrées :

Les paramètres importants sont les suivants :

• Local Adapter : choisir Microsoft iSCSI Initiator
• Initiator IP : choisir l’IP d’une des cartes réseaux du serveur.
• Target Portal IP : Choisir l’IP d’un des réseaux du portail configuré sur le serveur de stockage

Il est possible ici de configurer une authentification avec CHAP mais on ne le fera pas ici. On peut également activer une vérification de type CRC qui peut être utile avec un réseau de type TCP. Il faut répéter la même opération autant de fois qu’il existe un chemin à configurer.

On peut maintenant vérifier si notre paramétrage est correct. Dans la fenêtre principale des propriétés des initiateurs iSCSI, il faut sélectionner la cible concernée et cliquer sur le bouton Devices.

 

On voit ici que nous avons deux connexions présentes pour le même périphérique en utilisant deux cibles différentes (Target 4:LUN0 et Target5:LUN0)

En cliquant ensuite sur le bouton MPIO. La fenêtre suivante permet de paramétrer les règles de répartition des IO transitant sur les différents chemins. On laissera ici la règle par défaut qui permet de faire du round-robin en utilisant les chemins présents. Cette méthode, qui plus est, permet d’augmenter les performances. On voit également les deux chemins que nous venons de paramétrer.

On peut également vérifier notre configuration via l’utilitaire en ligne de commande iscsicli.exe de la façon suivante :

iscsicli.exe ListPersistentTargets

qui donne le résultat suivant :

Il ne reste plus qu’à initialiser, partitionner et formater notre nouveau disque depuis la console de gestion des disques.

Bon paramétrage !!

David BARBARIN (Mikedavem)
MVP SQL Server