NAS ou SAN : différences et critères de choix du stockage en réseau

NAS (Network Attached Storage) et SAN (Storage Area Network) désignent différentes façons de fournir du stockage au moyen d’une infrastructure réseau. En règle générale, un NAS sert des fichiers et des répertoires aux clients ; un SAN fournit un stockage en blocs qu’un serveur peut utiliser comme périphérique de stockage. La différence ne tient pas simplement à la taille de l’équipement ou au nombre de disques : l’essentiel est de savoir quelle ressource le système client voit et qui gère le système de fichiers.

Avec un NAS, l’équipement ou le serveur de stockage gère généralement le système de fichiers et publie des ressources partagées pour les utilisateurs ou les applications. Avec un SAN, le serveur connecté reçoit des volumes ou des unités logiques et gère normalement son propre système de fichiers sur ceux-ci. Appeler « NAS » n’importe quel serveur doté de disques partagés, ou « SAN » tout stockage rapide, risque donc de masquer des décisions importantes concernant l’accès, l’administration et la compatibilité.

Les deux architectures peuvent être utilisées en entreprise et coexister. Une organisation peut partager les dossiers des équipes au moyen d’un NAS et réserver un SAN aux serveurs qui ont besoin de volumes en blocs. Il n’existe pas de vainqueur universel : si le problème consiste à faciliter l’accès aux documents, les priorités ne sont pas les mêmes que lorsqu’une application doit gérer un volume en blocs.

Avec l’accès aux fichiers, le client demande des opérations sur des éléments identifiés comme fichiers et répertoires : ouvrir, lire, écrire ou modifier des attributs. Les utilisateurs peuvent parcourir des dossiers partagés et les applications utilisent les chemins et autorisations fournis par le service. Des protocoles tels que SMB et NFS prennent en charge ce modèle. Les clients voient une structure de fichiers partagée, même si l’implémentation et les options disponibles dépendent du serveur et du protocole.

Avec l’accès aux blocs, le stockage présente au serveur une unité logique sous la forme d’un périphérique qu’il peut partitionner ou formater. Le protocole transmet des opérations sur des blocs, et non un dossier prêt à parcourir. Le système d’exploitation du serveur gère le système de fichiers, tandis que le stockage sous-jacent fournit les blocs. iSCSI est une méthode normalisée de transport des commandes de stockage SCSI sur des réseaux IP ; sa spécification décrit le protocole, mais ne garantit pas à elle seule les performances, la disponibilité ou la facilité de déploiement.

Cette distinction a des conséquences opérationnelles. Dans le modèle fichier, la gestion des autorisations, des chemins partagés et de l’accès de plusieurs clients constitue une part essentielle du service. Dans le modèle bloc, il faut définir qui présente et utilise chaque volume, et comment éviter que plusieurs serveurs écrivent dans un système de fichiers qui n’est pas conçu pour les accès simultanés. Ne partez pas du principe qu’un volume partagé en blocs peut être monté en toute sécurité sur plusieurs serveurs : cela dépend du système de fichiers, du cluster et de la configuration prise en charge.

SMB est une famille de protocoles de partage de fichiers sur réseau, largement associée aux environnements Windows, sans toutefois se limiter à un seul système d’exploitation. La documentation de Microsoft décrit les fonctions du protocole et son implémentation dans Windows et Windows Server. Pour évaluer un NAS, vérifiez les versions de SMB proposées par l’équipement, les options d’authentification et d’autorisation prises en charge, ainsi que la compatibilité des fonctions requises par l’organisation avec ses clients. Le nom du protocole ne répond pas, à lui seul, à ces questions.

NFS donne lui aussi accès à des fichiers et répertoires sur le réseau. Sa documentation pour Windows Server explique la prise en charge de NFS dans ce système ; les options effectives dépendent des versions et des implémentations du serveur et du client. Si des systèmes Unix ou Linux côtoient d’autres plateformes, vérifiez l’interopérabilité concrète : versions prises en charge, correspondance des identités, autorisations, verrouillage des fichiers et configuration des exportations. NFS ne transforme pas automatiquement un équipement en SAN : il reste un protocole d’accès aux fichiers.

iSCSI sert à présenter du stockage en blocs sur des réseaux IP. La RFC 7143 définit le protocole iSCSI, tandis que la RFC 7146 traite des exigences de sécurité pour les protocoles de stockage en blocs sur IP au moyen d’IPsec. Ces références techniques permettent de comprendre le périmètre de chaque technologie, mais ne remplacent ni la documentation du fournisseur, ni la conception du réseau, ni les politiques de sécurité. Avant de choisir iSCSI, confirmez la compatibilité des initiateurs, des cibles, des systèmes d’exploitation et des outils d’administration prévus.

La capacité annoncée ne suffit pas à comparer des déploiements. Dimensionnez le réseau en fonction des charges de travail prévues et examinez la congestion, la redondance, la latence, les chemins alternatifs et les éventuels points de défaillance uniques. Un SAN peut utiliser iSCSI sur Ethernet ; il ne faut donc pas supposer que tout SAN exige un réseau physique distinct. Néanmoins, isoler ou segmenter le trafic de stockage peut être une décision de conception pertinente : son impact opérationnel, son isolation et sa disponibilité doivent être évalués dans le contexte concerné.

La charge d’administration fait également partie du coût. Avec un NAS, l’équipe responsable peut gérer les ressources partagées, les utilisateurs, les quotas, les autorisations, les sauvegardes et les mises à jour du service. Avec un SAN, en plus de gérer les volumes, elle peut devoir coordonner leur présentation aux serveurs, la connectivité, le multipathing et l’administration des systèmes de fichiers sur les hôtes. Ce sont des responsabilités de conception courantes, et non une liste identique pour chaque produit : les fonctions incluses et le travail requis varient selon la solution.

La sécurité doit être examinée de bout en bout. Déterminez comment les clients s’authentifient, comment les accès sont autorisés, quel trafic peut atteindre les services de stockage et comment les communications sont protégées selon l’architecture et le produit. Pour iSCSI, la RFC 7146 apporte des éléments de contexte sur la protection des protocoles de blocs sur IP ; elle ne permet pas de conclure qu’une installation particulière est sécurisée. Documentez aussi la gestion des changements, le basculement et les tests de restauration. La redondance ne remplace pas les sauvegardes : elle protège contre certaines défaillances, mais pas nécessairement contre les suppressions, les erreurs d’exploitation ou les incidents touchant les données répliquées.

Il n’est pas rigoureux d’affirmer que le NAS coûte toujours moins cher ou que le SAN évolue toujours mieux sans préciser la capacité, les performances, la disponibilité, le support et la durée d’utilisation prévue. Une comparaison économique doit inclure le stockage, les équipements réseau et adaptateurs nécessaires, les licences, les garanties, la consommation, l’espace, le support et les heures d’administration. Un NAS simple peut réduire le travail initial dans un scénario de dossiers partagés ; un besoin de blocs intégré aux serveurs peut justifier un SAN. Ce sont des hypothèses d’évaluation, pas des conclusions valables pour tous les fournisseurs.

Demandez à chaque option de répondre à la même charge de travail et au même niveau de service. Définissez l’espace utile nécessaire, la croissance attendue, le nombre de clients, les profils de lecture et d’écriture importants et le délai de reprise requis. Vérifiez ensuite que la documentation du produit étaye ces caractéristiques et identifiez les composants qui ne sont pas compris dans l’offre. Ne comparez pas une capacité brute à une capacité utilisable, ni une valeur maximale commerciale à une garantie de performances pour votre charge.

Il est également utile de distinguer la capacité de la facilité d’extension. Vérifiez les limites documentées concernant les disques, les volumes, les clients, les protocoles et l’extension, ainsi que les conditions de support et les parcours de migration. Les guides généraux sur le stockage aident à comprendre les catégories, mais ne prouvent pas les performances d’un équipement précis. Sans modèle, configuration et conditions d’utilisation définis, rien ne permet de publier une comparaison de prix ou de performances entre des solutions.

Comme premier filtre, déterminez ce que les applications doivent utiliser : des dossiers partagés ou des volumes en blocs gérés par les serveurs. Validez ensuite les protocoles et les systèmes d’exploitation, puis attribuez les responsabilités liées à l’exploitation, à la sécurité et à la reprise. Cet ordre évite de choisir sur la base d’un chiffre de vitesse isolé ou du nom d’une architecture.

Le tableau constitue un point de départ, et non une certification de l’adéquation d’une technologie à un cas particulier. Certaines solutions commerciales combinent les services de fichiers et de blocs ; cela n’efface pas les différences entre les modèles d’accès et ne prouve pas que tous les protocoles sont disponibles dans chaque configuration. Vérifiez les capacités précises dans la documentation du modèle à déployer et des versions logicielles concernées.

Avant de décider, réunissez une description des applications, des clients, des données et des objectifs de reprise. Si l’organisation ne peut pas encore préciser les exigences de latence, de disponibilité, de croissance ou d’accès simultanés, consignez ces lacunes et ne présentez pas un choix préliminaire comme définitif. Il n’est pas non plus nécessaire de commencer par une marque : établissez d’abord le modèle d’accès, puis évaluez les produits capables de le prendre en charge.

Une courte liste de validation aide à transformer la comparaison en décision vérifiable :

• L’application a-t-elle besoin d’un accès aux fichiers ou aux blocs ?
• Quelles versions de SMB, NFS ou iSCSI chaque extrémité prend-elle en charge ?
• Comment les identités et les autorisations sont-elles attribuées, et qui gère les volumes et les ressources partagées ?
• Quelle conception réseau, quelle redondance et quel isolement la solution exige-t-elle ?
• Comment les sauvegardes sont-elles effectuées, la restauration vérifiée et les interruptions gérées ?
• Quels coûts d’achat, de support, d’exploitation et d’extension sont inclus dans le calcul ?

La réponse la plus utile est généralement une architecture adaptée aux exigences démontrables, et non une étiquette plus prestigieuse. Pour partager des fichiers, commencez par évaluer le NAS et ses protocoles ; lorsque le serveur doit gérer des blocs, examinez le SAN ou des services équivalents et leurs exigences de coordination. Si les deux besoins existent, envisagez de les couvrir séparément. Décidez à partir d’exigences, de compatibilités et de responsabilités documentées, et indiquez clairement ce qui n’a pas encore été mesuré ou confirmé.