Introduction à Xsan

Pour cette fois, je vous propose un article plus abordable que les précédents. L’objectif ici est de vous présenter l’intérêt de Xsan ainsi que vous donner un rapide aperçu de sa configuration initiale.

D’après Apple Xsan est un système de fichier 64 bits en cluster, utilisable pour tout type d’environnement demandant un haut degré de rendement sur l’accès aux données.

Concrètement qu’est-ce que cela veut dire ? Le 64 bits concerne l’adressage de l’espace disque, bien que fondamentalement intéressant, nous allons plus discuter de la partie cluster. Généralement lorsqu’on parle de clusters en informatique, on pense directement au calcul distribué qui permet d’agréger un certain nombre d’ordinateurs autour d’un système d’exploitation spécifique en vue de former un super calculateur. Ici nous sommes dans le même cas, mais pour un système de fichier. Nous allons pouvoir agréger plusieurs disques ensemble pour en faire un gros, voir un très gros étant donné que la taille maximale d’un volume avec Xsan 2 est de 2Po, soit 2000 To…

L’autre avantage de cette technologie est que ces volumes managés par Xsan seront accessibles à plusieurs machines en même temps (64 au maximum) et à haute performance.

Xsan n’est qu’une vision spécifique d’un SAN (Storage Area Network). Pour bien comprendre la différence, revoyons nos cours élémentaires d’informatique, chapitre sur les différents types de stockage.

DAS, Direct Attached Storage : C’est le cas le plus simple, un disque dur branché directement à la machine via un bus SATA, USB, FireWire… Dans ce cas, l’accès disque est relativement rapide, mais restreint à une seule machine

NAS, Network Attached Storage : Bien que ce soit utilisé pour nommer ces disques durs réseau autonome, un NAS est tout simplement un DAS partagé à travers un réseau, Ethernet généralement, et nécessitant un protocole de partage (AFP, SMB, etc.). Le principal problème de cette solution étant le point de congestion représenté par la connexion réseau et ainsi que la mauvaise tolérance de panne. Si le système hébergeant le disque flanche, aucun autre ne peut prendre la relève sans intervention humaine.

SAN, Storage Area Network : Réseau spécifiquement dédié à l’échange de données et basé sur la technologie Fibre Channel qui permet l’échange de commandes SCSI à haute vitesse à travers une paire de cuivres, un câble coaxial ou une fibre optique.

Xsan fait donc partie des SAN ici. Mais ce qui va le différencier des autres est son aspect « cluster ». Mais continuons dans nos cours élémentaires au chapitre des SAN.

Dans un SAN nous avons plusieurs composants, entre autres les initiateurs SCSI (les ordinateurs) et les cibles (vos baies Promise & Xserve RAID). Éventuellement, vous aurez vos switchs, mais ce n’est pas le principal pour le moment. Dans un SAN des plus basiques, vous allez devoir configurer vos baies RAID pour créer vos espaces de stockage (c.-a-d. regrouper vos disques sous différentes formes de RAID pour les utiliser ensuite).

Ces espaces de stockage ainsi constitués sont identifiés par des numéros d’unité logique en SCSI, autrement appelés LUN. Prenez note de la métonymie, un LUN n’est qu’un identifiant et non le groupe de disques formant un RAID.

Une fois les baies RAID configurées, vous allez devoir assigner chaque LUN à un ordinateur spécifique qui s’en servira comme d’un DAS en quelque sorte. Exception faite de la vitesse de transfert disque/machine et de la taille possible de l’espace de stockage, nous nous retrouvons avec les mêmes limitations qu’un DAS, à savoir qu’il est affecté à une seule machine. L’explication en est simple, comment savoir si une autre machine ne cherche pas à accéder aux mêmes données en même temps.

C’est ici qu’entre en jeu l’aspect clusterisé du système de fichiers de Xsan. Dans cet environnement, il y aura des machines qui seront désignées comme contrôleur de métadonnées, leur rôle sera, entre autres, de garantir le fait qu’un fichier n’est écrit que par un seul client à la fois.

Histoire de ne perdre personne, la version illustrée différenciant SAN, Xsan :

Soit deux baies RAID différentes hébergeant chacun un seul LUN (les deux LUN pourraient être sur une seule baie, le fonctionnement serait le même). Si vous n’avez pas de système de fichiers clusterisé, vous devrez assigner un LUN à un serveur et ce dernier utilisera son driver standard pour gérer l’espace de stockage, pensant qu’il a en face de lui un RAID connecté sur un bus SCSI. Dans le cas de Xsan et des systèmes de fichiers en cluster, vous allez pouvoir désigner plusieurs LUN comme composants d’un volume unique. Pour que cela fonctionne, il vous faudra disposer du client Xsan sur vos serveurs, sans quoi ils seront incapables de retrouver leurs petits au sein du SAN.

Les présentations étant faites, regardons de plus près l’histoire des contrôleurs de métadonnées. Leur rôle est de gérer l’accès aux données. Il peut y avoir plusieurs serveurs dédiés à ce rôle, mais pour un volume donné, un seul est en activité, les autres attendent et ne prendrons la relève que si le principal tombe en panne.

Quand un client Xsan cherche à accéder à une ressource sur un volume particulier, il va consulter le contrôleur en lui demandant où se trouve la ressource et si l’utilisateur a le droit de l’utiliser. Le contrôleur principal va aller rechercher ces informations sur le SAN, sur un LUN spécifiquement dédié aux métadonnées, puis renvoie le tout au client. Ces métadonnées contiennent les informations de localisation des données (où sont elles physiquement ? Sur quel disque de quel LUN ?) ainsi que les propriétés du fichier (nom, droit d’accès, date de modification, etc.) Ainsi lorsqu’un client est en train de modifier un fichier, le contrôle est informé, lorsqu’un second client va faire une demande pour ce fichier, il pourra agir en connaissance de cause.

L’intérêt de placer ces métadonnées sur des LUN dédiés à cet usage est de rendre ces dernières accessibles aux autres contrôleurs. Ainsi lorsque le principal tombera, le prochain sur la liste prendra la relève sans perdre le fils des opérations.

C’est beau n’est-ce pas ?

Voici un exemple de liste de course pour mettre tout cela en place :

• Un minimum de deux serveurs et des clients (les serveurs sont tout à la fois des clients, vous pouvez donc n’avoir que des serveurs selon vos objectifs) équipés de carte FC ainsi que de deux cartes Ethernet, donc Xserve ou Mac Pro
• Une ou plusieurs baies RAID telles que la baie Promise validée par Apple ou encore le Xserve RAID qui n’est plus vendu (si vous testez une autre baie, sachez que ce n’est pas supporté par Apple)
• Un switch pour fabric SAN compatible de chez Cisco, Qlogic ou Brocade (voir la liste ici)
• Des câbles Fibre Chanel en cuivre (courte distance)
• Des émetteurs/récepteurs optiques, deux par câble optique (longue distance)
• Un switch Ethernet Gigabit supplémentaire pour créer un réseau dédié à l’échange de données entre clients et serveurs de métadonnées (pas obligatoire, mais fortement recommandé si vous cherchez la performance)
• Une licence Xsan par client

Pour vous éviter un tour sur l’Apple Store, le montage initiale avec deux Xserve pour un volume Xsan avec une baie promise de 32 To et un switch optique 8 ports revient environs à 30 000 € TTC, ce à quoi vous rajouterez quasiment 2000 € par Mac Pro que vous souhaitez raccorder au Xsan (en plus de la configuration initiale et de Final Cut par exemple).

Je vous laisse négocier les ristournes pendant que nous passons à la configuration de ce matériel de pointe.