Systèmes de fichiers cloud : architecture, types et performances

Un système de fichiers cloud donne aux applications et aux utilisateurs accès à une arborescence partagée de fichiers et de répertoires sur un réseau. Il expose généralement les opérations habituelles via NFS ou SMB, tandis que le service gère les nœuds de stockage, les métadonnées, la réplication et la reprise derrière le point de montage.

Cette définition compte, car le stockage de fichiers cloud est souvent confondu avec le stockage objet et le stockage par blocs. Ces trois modèles peuvent contenir les mêmes données, mais leurs interfaces et leur comportement lors d'accès simultanés diffèrent. Le choix dépend des attentes de l'application, du nombre de clients et de la contrainte principale : latence, débit ou traitement des métadonnées.

Qu'est-ce qu'un système de fichiers cloud ?

Un système de fichiers cloud fournit un stockage de fichiers à partir d'une infrastructure cloud. Les clients voient des fichiers nommés dans des dossiers et peuvent généralement les ouvrir, les lire, les modifier, les renommer, les lister et les verrouiller. Le stockage est indépendant d'une instance de calcul particulière : plusieurs machines peuvent monter le même partage et utiliser un espace de noms commun.

Il peut s'agir d'un service de fichiers réseau géré, d'un système distribué administré par le client ou d'un système parallèle destiné au calcul intensif. Dans chaque cas, les applications manipulent des fichiers, tandis que la couche de stockage traduit ces opérations vers un ou plusieurs serveurs, disques ou objets.

Les modèles de systèmes distribués dans le cloud définissent plus largement la coordination entre les nœuds de stockage, les services et les clients.

Ces systèmes conviennent aux répertoires personnels partagés, aux systèmes de gestion de contenu, aux travaux multimédias, aux environnements de compilation, aux données de recherche et aux applications conçues pour une interface POSIX ou Windows. Ils sont moins adaptés lorsqu'une application utilise déjà une API objet, nécessite un volume dédié à faible latence ou confie ses enregistrements et transactions à une base de données.

Fichiers, objets, blocs et bases de données

Le stockage cloud recouvre plusieurs modèles. Pour choisir une architecture, partez de l'interface dont l'application a besoin.

Modèle	Interface vue par l'application	Usages adaptés	Limite principale
Stockage de fichiers	Fichiers et répertoires montés via NFS, SMB ou un client natif	Dossiers partagés, applications existantes, répertoires personnels, gestion de contenu	La latence du réseau et des métadonnées peut limiter la montée en charge
Stockage objet	Objets dans des compartiments, accessibles par API	Sauvegardes, médias, jeux de données, archives, ressources applicatives	Une API objet plutôt qu'une interface de système de fichiers généraliste
Stockage par blocs	Volume brut rattaché à un hôte	Bases de données, disques de démarrage, traitements transactionnels, systèmes de fichiers personnalisés	Généralement rattaché à un seul hôte ou géré comme un volume en cluster
Base de données	Enregistrements interrogés via SQL ou une autre interface dédiée	Données structurées, index, transactions, état applicatif	Ne constitue pas un dépôt de fichiers généraliste

Une base de données peut placer ses fichiers sur du stockage par blocs. Un traitement analytique peut préparer des objets avant de les traiter dans un système de fichiers parallèle. Ces services peuvent travailler ensemble sans être interchangeables. Le guide du stockage cloud de Hivenet présente ces modèles dans un contexte plus large.

Comment fonctionne l'architecture d'un système de fichiers cloud ?

Les implémentations diffèrent, mais la plupart comprennent cinq couches fonctionnelles.

1. Clients et protocoles d'accès

Un client monte le système de fichiers et transforme les appels de l'application en requêtes réseau. Les environnements Linux et Unix utilisent souvent NFS ; Windows utilise souvent SMB. Les clients et services actuels permettent toutefois d'autres combinaisons. Par exemple, Azure Files prend en charge SMB et NFS. Google Cloud Filestore prend en charge NFSv3 et, sur certains niveaux de service, NFSv4.1.

Le protocole influence l'authentification, le verrouillage, la mise en cache, la reprise après panne et la compatibilité des clients. Le choix entre NFS et SMB dépend donc du fonctionnement de l'application.

2. Espace de noms et métadonnées

La couche de métadonnées suit les entrées des répertoires, les noms de fichiers, les propriétaires, les permissions, les horodatages et l'emplacement des données. Lister un grand répertoire ou créer des milliers de petits fichiers peut solliciter fortement cette couche, même si le volume de données reste modeste.

Certains systèmes séparent les métadonnées du contenu des fichiers pour faire évoluer ces deux chemins indépendamment. Dans CephFS, les serveurs de métadonnées gèrent les métadonnées du système de fichiers, tandis que le contenu est stocké sous forme d'objets dans le cluster RADOS. La documentation de l'architecture Ceph explique l'organisation de ces composants.

3. Serveurs de données ou nœuds de stockage

La couche de données stocke le contenu des fichiers et traite les lectures et écritures. Un service géré masque ces nœuds. Un système distribué autogéré donne davantage de contrôle sur leur placement, leur capacité et leur comportement en cas de panne. Il peut répliquer les données, utiliser un codage à effacement ou répartir les fragments entre plusieurs domaines de panne.

La distribution peut dépasser la capacité d'un serveur unique, mais elle n'accélère pas toutes les opérations. Les performances dépendent toujours du placement des données, du réseau, de la taille des requêtes, de la contention et du nombre de clients actifs en parallèle. Le guide sur les systèmes distribués et décentralisés distingue la répartition du travail de celle du contrôle.

4. Mise en cache et cohérence

Les clients mettent en cache les données et les métadonnées pour réduire les allers-retours réseau. Le système doit définir quand ce cache reste valide et comment les clients qui écrivent simultanément voient les changements. Une cohérence plus stricte et un verrouillage plus contraignant simplifient le comportement applicatif, mais peuvent augmenter le travail de coordination. Une mise en cache moins stricte peut améliorer le débit tout en augmentant le risque de lectures obsolètes ou de conflits.

Avant une migration, testez les opérations dont dépend l'application : renommage atomique, verrouillage consultatif ou obligatoire, cohérence après fermeture et réouverture, permissions, liens symboliques et comportement lors d'une interruption du client ou du serveur.

5. Administration et protection

La couche de contrôle provisionne les partages, applique les politiques d'identité et de réseau, surveille la capacité et les performances, crée des instantanés et coordonne la reprise. La disponibilité dépend du niveau de service et de l'architecture choisie. Un service régional peut protéger contre une panne de zone ; un service zonal peut privilégier le coût ou les performances locales. Un instantané protège contre certaines suppressions ou corruptions, mais ne remplace pas un plan de sauvegarde et de restauration testé.

Les types de systèmes de fichiers cloud

Services de fichiers réseau gérés

Ces services fournissent un partage sans demander au client d'exploiter ses propres serveurs de fichiers. Amazon Elastic File System propose des systèmes NFS pour les environnements AWS. Google Cloud Filestore fournit des partages NFS gérés. Azure Files fournit des partages SMB et NFS. Leurs versions de protocole, niveaux de service, architectures régionales, règles de capacité et modes de provisionnement des performances diffèrent.

Le service géré réduit le travail d'exploitation sans supprimer les choix d'architecture. Amazon EFS propose notamment les types Regional et One Zone, ainsi que plusieurs modes de débit. Filestore distingue différents niveaux, dont les services zonaux et régionaux. Azure Files propose plusieurs protocoles, supports, options de redondance et méthodes d'authentification. Consultez la documentation actuelle pour la région et la configuration prévues plutôt qu'un seul débit maximal annoncé.

Systèmes de fichiers distribués

Un système distribué stocke et sert les fichiers sur plusieurs nœuds tout en présentant un espace de noms commun. CephFS fournit ainsi un système de fichiers compatible POSIX au-dessus d'un stockage objet distribué. D'autres architectures organisent différemment le stockage, les métadonnées et la coordination.

L'autogestion donne plus de contrôle sur la topologie et les réglages, mais rend aussi l'équipe responsable des mises à niveau, du quorum, des réparations, de l'équilibrage de capacité, de la surveillance et des tests de panne. Elle se justifie surtout lorsque les limites d'un service géré ne conviennent pas à l'application.

Systèmes de fichiers parallèles

Ces systèmes déplacent les données simultanément à travers plusieurs serveurs ou périphériques. Ils servent au calcul haute performance, à l'apprentissage automatique, à la simulation, au rendu et aux traitements dans lesquels de nombreux processus utilisent un jeu de données partagé.

Lustre en est un exemple. Amazon FSx for Lustre en fournit une version gérée et peut relier une interface de fichiers haute performance aux données conservées dans Amazon S3. L'accès parallèle peut fournir un débit agrégé élevé, mais les opérations sur les petits fichiers, la configuration des clients, la bande passante et les modes d'accès déterminent les performances réelles.

Que signifie GPFS dans le cloud computing ?

GPFS signifie General Parallel File System. C'est l'ancien nom du produit aujourd'hui appelé IBM Storage Scale, et non un terme générique pour tous les systèmes de fichiers parallèles. IBM décrit Storage Scale comme un système de fichiers en cluster réparti sur un ou plusieurs nœuds. Il peut être déployé sur une infrastructure cloud adaptée pour partager un espace de noms et accéder aux données en parallèle, à condition de concevoir et d'exploiter correctement le cluster. La documentation IBM rattache Storage Scale, Spectrum Scale et GPFS à la même gamme de produits.

NFS ou SMB : quel protocole choisir ?

Question	Point de départ pour NFS	Point de départ pour SMB
Environnement client	Majorité de systèmes Linux ou Unix	Majorité de systèmes Windows et lecteurs réseau natifs
Identités	Utilisateurs et groupes POSIX ou authentification NFS avec Kerberos	Intégration Active Directory et listes de contrôle d'accès Windows
Attentes de l'application	Permissions Unix et comportement NFS	Partage Windows et comportement SMB
Clients mixtes	Prise en charge explicite des clients Linux et Unix requis	Prise en charge explicite des clients Windows, macOS ou Linux requis

La prise en charge dépend du service et du niveau choisi. Google documente NFSv3 sur les niveaux Filestore et NFSv4.1 sur certains niveaux, avec des différences d'authentification et de verrouillage. Azure documente SMB pour Windows, Linux et macOS, et NFS pour Linux. Vérifiez la version du client, les exigences de chiffrement, le fournisseur d'identité et les règles de verrouillage.

Comment évaluer les performances ?

Un débit maximal suffit rarement à prévoir le comportement d'une application. Mesurez plusieurs dimensions.

• Latence : temps nécessaire pour terminer une opération. Les opérations sur les métadonnées et les petites entrées-sorties aléatoires y sont souvent sensibles.
• IOPS : opérations par seconde. Notez la proportion de lectures et d'écritures et la taille des requêtes : un même nombre d'IOPS peut correspondre à des volumes de données très différents.
• Débit : données transférées par seconde. Les lectures et écritures séquentielles de grande taille profitent généralement davantage de clients parallèles et de chemins réseau plus larges.
• Débit des métadonnées : créations, ouvertures, consultations d'attributs, renommages et listes de répertoires par seconde. Il compte particulièrement pour des millions de petits fichiers.
• Concurrence : nombre de clients, de threads et de fichiers ouverts. Une seule machine virtuelle peut ne pas atteindre la limite agrégée d'un service conçu pour de nombreux clients.
• Reprise : comportement observé par les clients lorsqu'un nœud, un chemin réseau ou une zone de disponibilité tombe en panne.

Les réglages du fournisseur comptent aussi. Les performances d'Amazon EFS dépendent du type de système, du mode de performance, du mode de débit, de la classe de stockage et de la région. Google précise que les performances de Filestore varient notamment avec le cache, le nombre et le type de clients, les options de montage, la capacité et le niveau de service.

Un plan de test pratique

1. Relevez les tailles de fichiers, la proportion de lectures et d'écritures, les opérations sur les métadonnées, la concurrence et les pointes de trafic en production.
2. Testez avec la famille d'instances, la région, le chemin réseau, le système d'exploitation et les options de montage prévus.
3. Combinez des tests synthétiques et un test applicatif. Un test de bande passante séquentielle ne représente pas un environnement de compilation ou un répertoire de millions de petits fichiers.
4. Incluez des essais avec cache froid et cache chaud, puis des essais assez longs pour révéler les limites temporaires de performance ou le plafonnement.
5. Simulez le redémarrage d'un client et, si le service le permet, l'interruption d'un domaine de panne. Vérifiez la récupération des verrous et le comportement de l'application.
6. Mesurez les coûts en parallèle : capacité provisionnée, paramètres de performance, instantanés, trafic entre zones et transferts de données.

Quel modèle de stockage pour quel usage ?

Usage	Point de départ	Raison
Données applicatives Linux ou répertoires personnels partagés	Service NFS géré	Montage habituel et accès partagé de type POSIX
Partages de service sous Windows	Service SMB géré	Clients Windows, permissions et intégration à l'annuaire
HPC, rendu ou entraînement distribué	Système parallèle, souvent associé à du stockage objet	Débit agrégé élevé entre de nombreux processus
Sauvegardes, archives, médias et lacs de données	Stockage objet	Accès par API, capacité, gestion du cycle de vie et durabilité
Base de données transactionnelle	Base gérée ou architecture de stockage par blocs prise en charge	Latence prévisible et garanties de durabilité adaptées à la base
Conteneurs avec état	Stockage de fichiers ou par blocs via CSI, selon le mode d'accès	Volumes persistants correspondant aux besoins de partage

Une application qui fonctionne bien avec des objets n'a pas nécessairement besoin d'une interface de fichiers. Le stockage objet peut conserver les données de référence, tandis qu'un système parallèle fournit un espace de travail temporaire à haut débit. Hivenet propose du stockage objet compatible S3 pour les jeux de données, sauvegardes, médias, archives et données applicatives.

Sécurité, résilience et exploitation

Avant de migrer un système de production, vérifiez les points suivants :

• Identités et permissions : définissez les utilisateurs, groupes, comptes de service, listes de contrôle d'accès et droits d'administration.
• Isolation réseau : privilégiez les réseaux privés lorsque c'est possible et limitez les sous-réseaux clients, ports et groupes de sécurité.
• Chiffrement : confirmez le chiffrement au repos et en transit pour le protocole et le niveau choisis.
• Domaines de panne : identifiez le caractère zonal ou régional du service et les pannes qu'il est conçu pour tolérer.
• Instantanés et sauvegardes : fixez les objectifs de perte de données et de délai de reprise, puis testez la restauration.
• Surveillance : suivez la capacité, la latence, les IOPS, le débit, le plafonnement, la charge des métadonnées, les erreurs clients et les échecs de sauvegarde.
• Localisation des données : vérifiez où résident les fichiers, répliques, instantanés et sauvegardes, notamment en présence d'exigences de résidence.

La place de Hivenet dans le choix du stockage

L'offre publique de stockage de Hivenet distingue les mêmes besoins : stockage compatible S3 pour les objets, Store with Hivenet pour les fichiers du quotidien et Send pour les transferts volumineux. Les besoins de stockage par blocs, réseau ou HPC passent actuellement par un échange avec l'équipe commerciale ; ils ne sont pas présentés comme des systèmes de fichiers cloud en libre-service.

Pour les traitements intensifs, choisissez une interface adaptée à la façon dont l'application accède aux données. Le stockage objet convient aux jeux de données et aux résultats durables lorsqu'une API S3 répond au besoin. Le stockage par blocs, réseau ou HPC répond à d'autres exigences : volumes rattachés, montages partagés ou accès parallèle. La présentation de Compute with Hivenet décrit les options actuelles pour les traitements GPU et CPU.

Questions fréquentes

Un système de fichiers cloud est-il la même chose que le stockage cloud ?

Non. Le stockage cloud comprend les modèles fichier, objet et bloc. Un système de fichiers expose précisément des fichiers et des répertoires, généralement par un montage et un protocole de partage.

Plusieurs machines peuvent-elles écrire dans le même système ?

De nombreux systèmes gérés et distribués acceptent plusieurs clients simultanés. La sécurité des écritures dépend toutefois des règles de verrouillage et de cohérence du service, ainsi que de la coordination assurée par l'application.

Une base de données est-elle un système de fichiers cloud ?

Non. Elle gère des enregistrements structurés, des requêtes, des index et des transactions. Ses fichiers peuvent être placés sur du stockage par blocs ou de fichiers, mais les applications doivent utiliser l'interface de la base plutôt que modifier directement ces fichiers.

Qu'est-ce que le Google File System ?

Le Google File System, ou GFS, est une architecture distribuée décrite par Google dans un article de recherche de 2003. Elle a influencé des systèmes de stockage ultérieurs, mais ne désigne pas Google Cloud Filestore. L'article original sur GFS décrit un serveur maître qui coordonne les métadonnées et des serveurs de fragments qui stockent les données selon les besoins étudiés par Google.

Quel est l'avantage principal d'un système de fichiers parallèle ?

Il peut répartir les accès entre plusieurs cibles de stockage pour permettre des lectures ou écritures simultanées. Le bénéfice dépend de la configuration du réseau, des clients, du traitement des métadonnées et des entrées-sorties de l'application.

Comment choisir un système de fichiers cloud ?

Commencez par la compatibilité applicative : protocole, système d'exploitation, permissions, verrouillage et cohérence. Testez ensuite la latence, le débit, les métadonnées, la concurrence, la reprise, la disponibilité régionale et le coût total avec un traitement représentatif.