Unité 5.1 : Stockage en bloc et stockage de fichiers

Introduction

La couche de données commence par une décision qu'il est facile de mal prendre : qui doit lire et écrire les mêmes octets. Un volume Block Storage est un disque privé qui appartient à un seul serveur à la fois ; c'est la bonne réponse pour un disque de démarrage ou les données d'une application unique, et l'unité 4.2 a déjà traité l'attachement d'un tel volume. Dès que deux machines ou plus doivent voir les mêmes fichiers simultanément, ce modèle ne fonctionne plus, et la plateforme propose à la place un produit géré distinct, Network File Storage, plutôt que toute astuce de bloc partagé. Cette unité trace cette ligne de démarcation, met en lumière une asymétrie de placement qui surprend les architectes, puis construit le partage de fichiers partagé dont la couche applicative de FinCorp a besoin.

1. Stockage en bloc pour une seule VM par rapport à l'accès partagé géré aux fichiers

Block Storage présente un périphérique en bloc iSCSI à une seule machine virtuelle. Vous l'attachez, le système d'exploitation invité le formate, et il se comporte comme un disque local. Ce disque est lié à son serveur : il ne s'agit pas d'un support d'accès concurrentiel, et il ne transfère pas d'octets entre les machines. Pour les données persistantes d'une seule application, c'est exactement ce que vous souhaitez, et c'est là que se trouve la majeure partie de la capacité de la couche de stockage.

Network File Storage résout le problème différent d'un système de fichiers monté simultanément par de nombreux clients. C'est un produit géré : IONOS CLOUD exploite un cluster de deux serveurs de stockage dans une configuration haute disponibilité active-passive au niveau de la couche de service, exporte les données via NFSv4.2, et vous le montez depuis vos VM. Les clients voient un système de fichiers POSIX partagé ; la durabilité, la bascule entre les deux serveurs et le système de fichiers ZFS sous-jacent sont gérés pour vous. NFSv3 n'est pas pris en charge, il faut donc planifier pour des clients NFSv4.2 uniquement.

Les deux produits diffèrent également en matière de performance. Network File Storage est construit sur la classe de performance Block Storage SSD Standard, de sorte qu'un partage hérite d'un comportement de classe SSD, mais son chemin d'écriture est limité par une latence d'écriture synchrone d'environ 20 ms. Atteindre un nombre élevé d'IOPS d'écriture agrégés nécessite donc de nombreux écrivains concurrents, et le tableau de slots RPC par défaut du client NFS d'un montage (généralement 64 à 128) peut devenir la limite avant le stockage lui-même. Les recommandations documentées sont explicites : il n'est pas adapté aux charges de travail d'écriture synchrone avec des exigences de délai strictes. Il faut le considérer comme un stockage de fichiers partagés pour des actifs, des répertoires personnels, des journaux et des zones d'atterrissage pour les sauvegardes, et non comme un disque transactionnel à faible latence. Un autre fait structurel est important au moment de la conception : la taille d'un cluster est choisie en TiB à l'aide d'un curseur, le minimum est de 2 TiB, le maximum est de 42 TiB, et la taille ne peut pas être réduite après le provisionnement, il s'agit donc d'un mécanisme à sens unique vers le haut.

Le tableau suivant, issu de la documentation du produit, répertorie les cas d'utilisation pour lesquels Network File Storage est conçu :

Cas d'utilisation	Ce qu'il couvre
Fichiers de configuration partagés, modèles et actifs statiques sur plusieurs VM dans un VDC	Une copie canonique unique au lieu d'une duplication par instance
Service de médias / origine de livraison de contenu	Images, vidéos et médias servis sans duplication par instance
Cible de sauvegarde pour les bases de données, les données d'application et les instantanés de VM	Un répertoire d'atterrissage partagé, avec chiffrement au repos
Agrégation de journaux depuis plusieurs VM dans un répertoire partagé unique	Journaux centralisés provenant de nombreuses machines
Volumes persistants Kubernetes ReadWriteMany (RWX)	Volumes partagés pour les charges de travail conteneurisées

Pour FinCorp, la couche d'application exécute plusieurs VM sans état derrière un équilibreur de charge, et elles ont besoin d'un répertoire partagé unique pour les documents téléversés et les modèles partagés. C'est précisément la première ligne ci-dessus : un partage unique monté en lecture-écriture par chaque nœud d'application, plutôt qu'une copie des actifs intégrée dans chaque image de VM.

1.1 Portée régionale et privée, et le domaine où Object Storage prend le relais

Network File Storage est régional et privé. Le cluster est associé à un LAN d'un centre de données et accessible sur une adresse IPv4 ou IPv6 privée à l'intérieur de ce VDC ; il n'y a pas de point d'accès public, et un partage n'est pas étendu sur plusieurs régions. Les clients le montent via le LAN privé, ce qui maintient le trafic hors d'Internet et signifie que le transfert de données vers vos VM n'est pas facturé. Le compromis est la portée : si FinCorp a besoin des mêmes données disponibles dans plusieurs régions, ou accessibles par des outils de type S3, le système de fichiers partagé est la mauvaise couche. Pour les données partagées inter-régions, utilisez plutôt Object Storage (unité 5.2), qui est le stockage à portée géographique et adressable par API de la plateforme. Choisissez Network File Storage lorsque de nombreuses machines d'une même région ont besoin d'un système de fichiers POSIX en direct ; choisissez Object Storage lorsque la portée, l'échelle ou l'accès programmatique priment.

L'accès est également réservé à Linux et contrôlé par partage à l'aide de groupes de clients. Chaque groupe de clients associe une liste de réseaux IP (les réseaux privés autorisés, en notation CIDR) à un mode d'écrasement qui mappe le root et les utilisateurs distants vers une identité anonyme. Le paramètre des réseaux IP prime toujours sur la liste des hôtes, et la documentation déconseille l'option sans écrasement pour des raisons de sécurité. C'est l'équivalent au niveau des fichiers de la posture par défaut privée que le reste de l'architecture suit.

2. Correspondance entre le niveau et le modèle d'accès, et l'asymétrie des zones

La décision concernant le niveau est dictée par le modèle d'accès, et non par la taille. Un disque persistant à écriture unique pour une seule VM est du Block Storage. Un système de fichiers POSIX à nombreux lecteurs et nombreux rédacteurs au sein d'une région est du Network File Storage. Un stockage de masse et d'archives à portée géographique, adressable via l'API, est du Object Storage. Au sein du Block Storage, les niveaux SSD comportent un seuil de performance à garder à l'esprit ici, car il se reproduit à travers l'ensemble de la couche de données : les volumes SSD ne délivrent la performance par Go complète qu'à partir de 100 Go, de sorte qu'un petit volume SSD sous-performe par rapport à son niveau. C'est ce seuil qui explique pourquoi les volumes SSD de taille insuffisante sont déconseillés pour les charges de travail exigeantes, un point sur lequel l'unité 5.3 revient pour les bases de données.

Il existe une asymétrie de placement qui surprend les architectes provenant d'autres plateformes. Les zones de disponibilité ne sont pas symétriques entre le calcul et le Block Storage. Un volume Block Storage peut être placé dans la zone 1, la zone 2, la zone 3, ou en mode Auto. Le calcul, en revanche, n'offre que les zones 1, 2 et Auto : il n'existe pas de zone de calcul 3. La conséquence pratique est qu'il est impossible d'attacher un serveur à une « zone 3 » pour correspondre à un volume de zone 3, car aucune zone de calcul de ce type n'existe. Lorsque vous répartissez délibérément une paire redondante entre les zones, concevez votre architecture en tenant compte de la réalité du calcul des zones 1 et 2, et ne supposez pas qu'un placement de volume en zone 3 vous offre un domaine de calcul correspondant. Traitez la sélection de zone comme une décision explicite pour toute paire redondante, plutôt que de la laisser en mode Auto, ce qui peut regrouper des ressources que vous aviez l'intention de séparer.

Déroulement de la mise en œuvre de DCD

Ce déroulement provisionne le stockage de fichiers partagé dont la couche applicative de FinCorp a besoin : un cluster Network File Storage sur le LAN applicatif, un partage, et le montage depuis plusieurs clients Linux. Il concrétise la décision de la section 1 de conserver une seule copie canonique des actifs partagés plutôt que de les dupliquer pour chaque VM. Le prérequis est un VDC existant avec un LAN applicatif privé (créé dans l'unité 3.1) et le privilège Access and Manage Network File Storage sur votre groupe ; sans ce privilège, un utilisateur a un accès en lecture seule et ne peut pas provisionner.

Objectif de construction : Provisionner un stockage de fichiers partagé monté par plusieurs clients.

Étapes (dans Data Center Designer) :

Dans DCD, ouvrez Menu > Storage & Backup > Network File Storage, puis sélectionnez Create Cluster.
Définissez les propriétés du cluster : saisissez un Cluster Name ; sélectionnez la Location (l'emplacement du serveur où le cluster résidera) ; définissez la Size en TiB à l'aide du curseur, en gardant à l'esprit le minimum de 2 TiB et le fait que la taille ne peut pas être réduite ultérieurement ; laissez File System Version sur la valeur par défaut NFSv4.2.
Associez le cluster à un centre de données : sélectionnez le Datacenter (les choix dépendent de la Location choisie) et le LAN du Datacenter, qui doit être le LAN applicatif privé. Saisissez une adresse IPv4 (ou IPv6) privée avec CIDR pour le cluster, en utilisant le panneau Finding your Private IP à droite pour choisir une adresse libre qui ne entre pas en collision avec votre plage DHCP.
Cliquez sur Save. Le cluster est créé et passe à l'état BUSY ; attendez qu'il devienne AVAILABLE avant de créer des partages.
Depuis la liste des clusters, sélectionnez Manage Shares dans la colonne OPTIONS (ou ouvrez le cluster et utilisez l'onglet Manage Shares), puis sélectionnez Create Share.
Définissez les propriétés du partage : saisissez un Directory Name ; définissez éventuellement un Quota en MiB pour limiter le partage (saisissez zéro pour désactiver le quota) ; définissez éventuellement le Group Id et le User Id propriétaires, qui sont tous deux définis sur 65534 par défaut.
Ajoutez un groupe de clients : ajoutez éventuellement une Description ; choisissez un NFS Squash Mode (la carte de root vers anonyme est la ligne de base recommandée ; évitez no-squash) ; sous IP Networks, ajoutez le réseau privé autorisé en notation CIDR (par exemple le sous-réseau du LAN applicatif) afin que seuls ces clients puissent monter le partage.
Cliquez sur Save pour créer le partage.
Sur chaque client Linux, montez le partage en utilisant l'IP privée du cluster et l'UUID du partage : mount -t nfs <cluster-ip>:<share-uuid> <local-mount-path>. Chaque VM applicative qui monte la même IP de cluster et le même UUID voit désormais les mêmes fichiers.

Erreurs courantes :

Surdimensionner le cluster dès le premier jour. La taille ne fait qu'augmenter ; vous ne pouvez pas la réduire, donc commencez à la valeur réelle au-dessus du minimum de 2 TiB et augmentez-la au besoin.
Laisser le mode squash sur None. La documentation le déconseille ; mappez root (ou tous les utilisateurs) sur l'identité anonyme à la place.
Oublier que IP Networks prime sur la liste Hosts. Si l'accès est incorrect, vérifiez d'abord le CIDR de IP Networks, car il l'emporte toujours.
Supposer que NFSv3 fonctionnera. Seuls NFSv4.2 est pris en charge ; les anciens clients échouent au montage.
S'attendre à un accès inter-régional ou public. Le partage est privé et régional ; si vous en avez besoin, utilisez Object Storage, pas un export NFS plus large.
Essayer de monter depuis Windows. La prise en charge des clients est limitée à Linux.
Choisir Network File Storage pour une charge de travail avec écriture synchrone à délai serré. La latence d'écriture synchrone d'environ 20 ms et la limite de slots RPC par montage le rendent inadapté ; ces données doivent résider sur un volume Block Storage attaché à la VM unique qui en est propriétaire.

Résumé

Block Storage est un disque iSCSI privé, dédié à une seule VM ; Network File Storage est un système de fichiers NFSv4.2 privé, géré et régional, que de nombreux clients Linux montent simultanément ; Object Storage est le stockage adressable par API, à portée géographique étendue. Le choix de la couche suit le modèle d'accès, et non la capacité, et un choix délibéré de zone est important, car Block Storage propose la zone 3, tandis que le calcul ne le propose pas. La couche d'application sans état de FinCorp reçoit un partage unique partagé pour ses ressources, dimensionné pour la croissance et restreint au LAN de l'application.

Points clés :

Block Storage = une VM, disque privé (l'attachement est traité dans la section 4.2) ; Network File Storage = de nombreux clients Linux, un système de fichiers privé régional ; Object Storage = inter-régional, adressable par API.
Network File Storage est uniquement NFSv4.2 (pas de NFSv3), réservé à Linux, construit sur la classe SSD Standard, avec un seuil de synchronisation d'écriture d'environ 20 ms ; ce n'est pas un disque transactionnel à faible latence.
Un Cluster est dimensionné de 2 à 42 TiB et ne peut pas être réduit après le provisionnement ; l'accès est contrôlé par des groupes de clients, où la liste des réseaux IP prime toujours sur la liste des hôtes.
Les zones de disponibilité de Block Storage sont 1, 2, 3 et Auto ; les zones de calcul sont uniquement 1, 2 et Auto. Il n'y a pas de zone 3 pour le calcul, il faut donc définir des zones explicites pour toute paire redondante, plutôt que de compter sur Auto.

Terminologie importante :

Cluster (Network File Storage) : l'unité gérée à deux serveurs, en mode actif-passif, que vous provisionnez et dimensionnez en TiB ; elle contient un ou plusieurs partages et s'attache à un LAN de centre de données unique.
Share : un système de fichiers exporté individuel au sein d'un Cluster, avec sa propre quota, ses identifiants de propriétaire et ses groupes de clients ; plusieurs partages peuvent coexister dans un même Cluster.
Mode Squash : la correspondance de l'utilisateur root distant ou de tous les utilisateurs vers une identité anonyme (UID/GID 65534 par défaut), qui limite les actions qu'un client de montage peut effectuer en tant qu'utilisateur privilégié.