Site WWW de Laurent Bloch
Slogan du site

ISSN 2271-3905
Cliquez ici si vous voulez visiter mon autre site, orienté vers des sujets moins techniques.

Pour recevoir (au plus une fois par semaine) les nouveautés de ce site, indiquez ici votre adresse électronique :

Systèmes de fichiers en réseau
NFS, SANs et NAS
Article mis en ligne le 24 mai 2007
dernière modification le 15 avril 2015

par Laurent Bloch

Comment stocker les données

Pour un centre de calcul d’une certaine importance, et maintenant grâce à la baisse des coûts pour un particulier, il y a trois modèles de solutions possibles pour stocker les bases de données :

  1. disques connectés directement aux serveurs par des attachements SATA ou SCSI ;
  2. disques organisés selon la technologie SAN (Storage Area Network) ;
  3. disques organisés selon la technologie NAS (Network Attached Storage).

Nous allons examiner successivement ces trois solutions.

Disques connectés directement aux serveurs

Cette solution est identique à celle qui existe pour les ordinateurs personnels. Il existe plusieurs techniques de connexion : ATA comme AT Attachment, SATA comme Serial ATA et SCSI(Small Computer Systems Interface). SCSI est réputé mieux adapté aux usages professionnels, mais il existe des armoires de disques SATA pour faire des NAS de second niveau bon marché, et cette technologie progresse.

La connexion d’un disque SCSI à un ordinateur suppose l’installation dans le fond de panier de l’ordinateur d’une carte contrôleur SCSI qui comporte l’interface adéquate, appelée bus. Il faudra aussi configurer le système d’exploitation pour y inclure les pilotes SCSI adéquats. À un bus SCSI on pourra raccorder, selon les versions, huit ou seize appareils SCSI, disques ou autres (le contrôleur compte pour un), qui seront connectés en chaîne les uns derrière les autres. Retenons que tout raccordement d’une chaîne SCSI à un ordinateur nécessite une intervention avec ouverture du boîtier de la machine. Il s’agit d’une connexion de bas niveau, étroitement couplée à un ordinateur donné.


Chaîne de trois disques SCSI connectée à un ordinateur

Systèmes de fichiers en réseau

Lorsque plusieurs ordinateurs cohabitent sur le même réseau local il
est tentant de leur permettre de partager des fichiers. Cette
tentation a donné naissance aux systèmes de fichiers en réseau, dont
les principaux représentants sont NFS (Network File System)
pour les systèmes Unix, SMB (Server Message Block), aussi
appelé CIFS (Common Internet File System), pour les systèmes
Windows. Citons également le système AppleShare pour les
ordinateurs Apple.

Le principe de ces systèmes est toujours le même : le système de
fichiers distant est présenté à l’utilisateur comme s’il était local,
et celui-ci émet des appels système habituels pour y effectuer des
opérations d’entrée-sortie. Le noyau du système intercepte ces appels
système et les encapsule dans un message qui va être envoyé au
système distant. Le message contient la description de l’opération
d’entrée-sortie à effectuer. Il s’agit donc d’un appel de procédure
à distance, ou
Remote Procedure Call,
RPC en abrégé.
Le résultat de l’opération est retourné à l’expéditeur par le
même procédé.

On concevra aisément que ce processus, qui consiste à commander
l’exécution d’un programme sur un autre ordinateur, est une faille
béante de sécurité. Il est donc recommandé de limiter l’usage des
systèmes de fichier en réseau à des environnements soigneusement
contrôlés. Ces systèmes reposent généralement sur des protocoles sans état,
ce qui fait qu’ils ne comportent pas de système de verouillage
pour garantir la cohérence des fichiers distants. Il est souvent
prudent de permettre l’accès à des systèmes de fichiers distants
soit à plusieurs utilisateurs, mais uniquement en lecture, soit
en lecture et en écriture, mais à un seul utilisateur.

Pour partager des données réparties de façon plus complexe sans
encourir les risques que nous venons d’évoquer, il convient
d’utiliser pour gérer les données accessibles par le réseau un
Système de Gestion de Bases de Données, qui comportera alors les dispositifs
désirables de contrôle d’accès.

Architecture SAN

L’architecture SAN est fondamentalement une extension de la
technologie SCSI, dont elle reprend les principes tout en en
améliorant la réalisation sur les points suivants :

  1. le protocole SCSI a été étendu pour donner deux protocoles plus puissants, Fibre Channel et iSCSI, qui permettent des débits et des longueurs de câbles supérieurs ;
  2. le maximum théorique d’appareils que l’on peu connecter à un SAN en Fibre Channel est de 16 millions ;
  3. plusieurs ordinateurs connectés à un même SAN peuvent accéder concurrement à tous les disques du SAN.

On voit bien le progrès que la technologie SAN apporte en extension
et en souplesse de configuration pour de vastes ensembles de serveurs
et de support de stockage.

La figure 4 montre la topologie d’un SAN de type
fabric en Fibre Channel ; il y a deux types de
topologies possibles : fabric et arbitrated loop ; la
seconde était justifiée par le prix prohibitif des commutateurs de
type fabric, mais comme ceux-ci sont devenus plus abordables,
la topologie arbitrated loop, moins efficace, ne se justifie
plus vraiment et je ne la décrirai pas ici. Lorsque le protocole
iSCSI sera sorti de son état actuel de quasi-prototype, il sera
possible de construire des SANs à base de commutateurs Ethernet
Gigabit, beaucoup plus économiques. En effet, un commutateur 16 ports
Fibre Channel de marque Brocade coûte de l’ordre de 10 000 Euros,
contre 2 à 3 000 Euros pour un commutateur Gigabit Ethernet chez Cisco.(tarif 2007)


Topologie d’un SAN en Fibre Channel

Les serveurs comportent des HBA (Host Bus Adapters),
qui ne sont pas autre chose que des contrôleurs SCSI adaptés au
support Fibre Channel.

Contrairement à ce que pourrait suggérer la figure, le commutateur
n’affranchit pas les serveurs de la gestion de bas niveau du protocole
Fibre Channel (c’est-à-dire en fait SCSI), ils doivent notamment
être dotés du matériel et des pilotes adéquats. Le commutateur ne fait
qu’aiguiller des flots d’octets vers la bonne destination.

Comme les données sur les disques sont traitées au niveau physique,
cela veut dire que les serveurs doivent être dotés de logiciels
absolument compatibles, il n’y a aucune abstraction des données.

Architecture NAS

Comme l’indiquent les noms des méthodes d’accès disponibles, un NAS (Network Attached Storage) est un serveur de fichiers (le terme est important) connecté au
réseau. Les autres serveurs peuvent accéder au fichiers servis par le
NAS au moyen des protocoles de partage de fichiers habituels : NFS
(Network File System) pour les systèmes Unix, SMB (Server
Message Block)
, aussi appelé CIFS (Common Internet File
System)
, pour les systèmes Windows.


Topologie d’un NAS

La figure 5 représente l’architecture d’un NAS. L’objet
appelé « tête du NAS » est en fait un ordinateur équipé d’un système
d’exploitation spécialisé qui ne fait que du service de fichiers. En
général c’est un système Unix dépouillé de toutes les fonctions inutiles
pour le système de fichiers, et spécialement optimisé pour ne faire
que cela. Le plus souvent, la façon dont le NAS effectue la gestion
de bas niveau de ses disques est... un SAN en Fibre Channel.

Quelle est la différence entre un NAS et un serveur de fichiers
ordinaire ? Fonctionnellement, on pourrait répondre : aucune.
En fait, tout est dans le système d’exploitation spécialisé.
Les protocoles de partage de fichiers mis en œuvre sur des
systèmes ordinaires ont la réputation de performances médiocres
et de robustesse problématique. Les NAS de fournisseurs sérieux
ont résolu ces difficultés et offrent des performances excellentes.

Quel est l’avantage du NAS par rapport au SAN ? Les serveurs de
calcul sont totalement découplés des serveurs de données, il n’est
plus nécessaire de les équiper du matériel et des pilotes nécessaires
à l’accès physique aux disques, une carte Ethernet Gigabit (quelques
dizaines d’Euros) et la pile TCP/IP standard font l’affaire et on ne
s’occupe plus de rien. Il est prudent de prévoir un réseau réservé
à l’usage du NAS et de ses clients.

Quelles sont les limites de l’architecture NAS ? C’est du service
de fichiers, donc les accès de bas niveau ne sont pas disponibles
(c’est d’ailleurs le but). Dans l’antiquité, les SGBD utilisaient
souvent un mode d’accès aux disques qui court-circuitait le système
de fichiers (raw device), pour des raisons de performances.
Aujourd’hui l’amélioration des caractéristiques du matériel a fait
que cette approche n’est plus guère utilisée.
Les base de données Oracle chez Oracle, Inc. sont installées
sur des NAS de la maison Network Appliance.

Quels sont les autres services disponibles avec un NAS ?

 mirroring de systèmes de fichiers à distance, par
exemple duplication des données sur un site de secours ;
 gestion du cycle de vie des données : on peut prévoir un
stockage de second niveau pour les données inactives mais qu’il
faut garder, sur des disques plus lents et moins chers ;
 sauvegarde des données autonome, sans intervention des serveurs
de calcul : la tête de NAS est un ordinateur, capable de piloter une
sauvegarde selon le protocole NDMP (Network Data Management
Protocol)
supporté par le logiciel de sauvegarde Time
Navigator
.

Dernier avantage : les solutions NAS sont moins onéreuses que les
solutions SAN, parce qu’au lieu de mettre de la quincaillerie
partout, le matériel destiné au stockage de données est concentré
dans une seule armoire, un rack pour les petits NAS. Il existe
aujourd’hui des NAS personnels, pour un prix de l’ordre de la
centaine d’Euros.

Pour en savoir plus sur SCSI, SAN et NAS on consultera avec profit le
livre de W. Curtis Preston[
1].

© 2008 Laurent Bloch



Index

  • appel de procédure à distance, 3

  • NAS, voir Network Attached Storage
  • Network Attached Storage, 1, 5
  • Network File System, 1, 3, 5
  • NFS, voir Network File System, voir Network File System

  • Remote Procedure Call, 3
  • RPC, voir Remote Procedure Call

  • SAN, voir Storage Area Network
  • Storage Area Network, 1, 5
  • système
    • de Gestion de Bases de Données, 3

Références

[1]
W. Curtis Preston. SANs and NAS. O’Reilly, Sebastopol, California, 2002.





Ce document a été traduit de LATEX par HEVEA