Cette semaine, j’ai croisé toute une série d’acronymes : NAS, SAN, baies, blocs, chemins multiples. Tout ça pour répondre à une question qui me semblait facile : où sont les données?

Un NAS présente habituellement des fichiers par un protocole réseau comme SMB ou NFS. Le serveur demande « ouvre \\nas01\documents\contrat.doc »; le NAS possède le système de fichiers, ses répertoires, ses verrous et ses permissions. Plusieurs clients peuvent ouvrir le même partage parce que le NAS coordonne cet accès.

Un SAN transporte plutôt des commandes de blocs, souvent SCSI sur Fibre Channel et maintenant aussi avec iSCSI sur IP. La baie découpe sa capacité en unités logiques, des LUN, puis les présente à un serveur. Windows voit un disque, crée son propre système de fichiers et demande des blocs numérotés sans savoir quel disque physique les contient.

NAS : application → SMB → réseau → système de fichiers du NAS → disques

SAN : application → NTFS → pilote disque → SCSI/Fibre Channel
                  → contrôleur de baie → cache/RAID → disques

Cette différence impose une règle importante : deux serveurs ne peuvent pas monter librement le même LUN en lecture-écriture avec un système de fichiers ordinaire. Chacun garderait son propre cache et pourrait modifier les métadonnées sans voir l’autre, ce qui corrompt le volume. Un cluster a besoin d’un logiciel qui coordonne le propriétaire ou d’un système de fichiers conçu pour le partage. Un NAS fait déjà cette coordination au niveau fichier.

Dans la baie, le RAID répartit les données et la redondance sur plusieurs disques. Le cache du contrôleur peut confirmer rapidement une écriture avant qu’elle atteigne les plateaux, à condition d’être protégé par batterie et reproduit selon l’architecture. Si le cache volatile annonce « écrit » puis perd le courant, l’application croit à tort que sa transaction est durable.

Les performances dépendent plus des opérations d’entrée-sortie que du nombre de gigaoctets. Dix serveurs peuvent partager les mêmes disques et leurs files. Une requête SQL aléatoire attend les mouvements de têtes; une grosse copie séquentielle peut saturer le débit. Une moyenne de 5 ms cache parfois des pointes de 500 ms quand la file se remplit.

Je suivrais au moins :

1. opérations de lecture et écriture par seconde;
2. taille moyenne des demandes;
3. latence côté serveur et côté baie;
4. profondeur de file;
5. taux de cache hit;
6. capacité libre et rythme de croissance;
7. erreurs et bascules de chemins.

Le multipathing fournit deux adaptateurs, deux commutateurs et deux chemins vers les contrôleurs. Un pilote choisit un chemin et bascule si l’un tombe. Deux câbles branchés dans le même commutateur n’éliminent pas le point unique. Je testerais une panne de lien pendant une charge contrôlée et vérifierais que les entrées-sorties reprennent sans que le volume disparaisse.

Les snapshots sont séduisants : la baie mémorise les blocs originaux lorsqu’ils changent, donnant une vue rapide d’un point dans le temps. Mais un snapshot sur la même baie n’est pas une sauvegarde contre sa perte, et une photo prise sans coordonner SQL Server peut nécessiter son journal pour retrouver un état cohérent. Il faut savoir si l’application a vidé ses écritures et si les groupes de volumes ont été capturés ensemble.

La sécurité change aussi d’endroit. Le zoning Fibre Channel et le LUN masking limitent quels serveurs voient chaque LUN. Sur un NAS, partages et ACL limitent les fichiers. Présenter par erreur le volume de production à un serveur de test peut faire bien plus de dégâts qu’un simple refus d’accès.

Je n’ai pas besoin d’administrer la baie pour écrire un programme, mais je dois pouvoir dessiner le trajet de ses données. La prochaine fois qu’un écran ralentit, je comparerai le plan SQL, la mémoire du serveur, sa file disque et la latence de la baie au même moment. Et avant d’appeler un snapshot « backup », je demanderai sur quel équipement il vit et comment on le restaure si cet équipement n’est plus là.