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.

6 réflexions au sujet de « Introduction à Xsan »

  1. Ping : Yoann Gini » Xsan et serveur mail

  2. Ping : Yoann Gini » Xsan sans baie RAID et sur un portable ?

  3. Yoann, je déterre ce post pour demander conseil concernant la baie APPLE XSAN et son fonctionnement.

    J’ai un collègue qui souhaite s’équiper d’une baie XSAN d’Apple (occasion) ; il a déjà un Xserve de 2006… je ne connais pas vraiment la config de son xserve… je maitrise pas trop sa config. Cette idée va dans le sens d’une homogénéisation de serveurs Apple déjà existants. Bref…
    Il souhaite utiliser cette baie pour stocker des vidéos (reportages TV au format MP4) ; il va dans un premier temps utiliser des disques d’origine de 500go sur l’ensemble de la baie en RAID 0 pour bénéficier de la totalité de l’espace puis il envisage ensuite de passer sur des DD de 2to (ou 3to) au fur et mesure. On en a discuté et j’ai des doutes quant à la faisabilité de son affaire… si la baie est pleine en RAID0 à 70%, il me semble impossible de remplacer un DD de 500go par un DD de 2to dans la matrice pour augmenter l’espace à chaud. Je crois que c’est la taille mini qui prime…
    Je lui ai conseillé de prévoir une refonte globale de son XSAN, quitte à racheter 5 DD d’un coup… et de faire évoluer par la suite.
    En fait, le grand débat, c’est comment faire évoluer la baie XSAN Apple pour atteindre un maximum de To (RAID0, stripping) sans forcément avoir de sécurité des données RAID5 (il dispose d’un autre espace pour sauvegarde).
    Merci pour vos éclairages car je ne connais pas vraiment la force de XSAN.

    • Très clairement, en RAID 0 on ne peut pas remplacer de disque sans perdre toutes les données.

      Ensuite, le Xserve RAID d’Apple, c’est vieux, très vieux… C’est une techno dépassé avec des performance toute relative (que ce soit en terme de redondance ou de bande passante). De même, il n’est pas dit qu’il supporte des disques de deux ou trois To. Officiellement il n’a jamais supporté plus que des disques de 700 Go…

      Je n’ai pas les détails du projet ni même ses objectifs, mais vu comme cela, j’ai l’impression que c’est une mauvaise idée…

      • Bonsoir Yoann,

        Et oui, je pense que c’est une mauvaise idée… en fait, du matos APPLE Xserve traine encore dans une armoire ; 2 Serveurs XServe 2006 et 2 baies XServe RAID ; il récupère une baie, suite à des migrations vers d’autres système de stockage. En fait, son Boss ne veut pas faire d’investissement sur le stockage vidéo dit « de transit »… cela marchait comme ça avant alors on continu… bref, il peut effectivement acheter du disque mais ca n’ira pas plus loin (ahurissant !). Je trouve que c’est une solution a court terme qui risque de prendre un temps fou ; l’idée est bien de rester sur le monde APPLE (Mac OS X server) pour plein de raison (FinalCut) et un gros parc mac ; mais pour ma part je pense qu’il faut faire le pas pour investir vers une autre solution de stockage ou laisser en état… concernant la techno XRAID d’Apple, je lui ai dit exactement ce que vous avez précisé : Trop vieux, trop risqué et pas franchement d’évolution… J’ai essayé de lui dire que des baies Thunderbolt avec des mac mini étaient certainement la solution quitte à mutualiser ses achats avec les autres collègues… mais faut-il encore défendre cette idée.
        Merci d’avoir conforter mon idée…
        Salutations,
        TB

Laisser un commentaire