Unité 5.1 : Stockage de blocs et de fichiers

Introduction

Le niveau des données commence par une décision qui est facile à mal interpréter : qui a besoin de lire et d'écrire les mêmes octets. Un Block Storage Volume est un disque privé qui appartient à exactement un 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à abordé le sujet de l'attachement d'un tel disque. Dès l'instant où deux machines ou plus doivent voir les mêmes fichiers en même temps, ce modèle est rompu, et la plateforme offre un produit géré séparé, Network File Storage, au lieu de tout truc de bloc partagé. Cette unité trace cette limite, met en surface une asymétrie de placement qui piège les architectes, puis construit le partage de fichiers partagés dont l'application de FinCorp a besoin.

1. Single-VM Block Storage Versus Managed Shared File Access

Block Storage présente un dispositif de bloc iSCSI à une 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 déplace pas d'octets entre les machines. Pour les données persistantes d'une seule application, c'est exactement ce que vous voulez, et c'est là que vit la majeure partie de la capacité du niveau de données.

Network File Storage résout le problème différent d'un système de fichiers monté par de nombreux clients à la fois. Il s'agit d'un produit géré : IONOS exécute un Cluster de deux serveurs de stockage dans un arrangement de haute disponibilité actif-passif au niveau du service, exporte les données via NFSv4.2, et vous le montez à partir de vos machines virtuelles. Les clients voient un système de fichiers POSIX partagé ; la durabilité, le basculement entre les deux serveurs, et le système de fichiers ZFS sous-jacent sont exploités pour vous. NFSv3 n'est pas pris en charge, vous devez donc planifier uniquement des clients NFSv4.2.

Les deux produits diffèrent également dans la livraison des performances. Network File Storage est basé sur la classe de performances Standard SSD de Block Storage, un partage hérite donc d'un comportement de classe SSD, mais son chemin d'écriture est limité par une latence d'écriture synchrone d'environ 20 ms. Pour atteindre une écriture agrégée élevée IOPS, il faut donc de nombreux écrivains concurrents, et la table des emplacements RPC du client NFS par défaut (typiquement 64 à 128) peut devenir le plafond avant le stockage. Les conseils documentés sont explicites : il n'est pas adapté aux charges de travail d'écriture synchrone avec des exigences de délai serrées. Lisez-le comme un stockage de fichiers partagés pour les ressources, les répertoires personnels, les journaux et les zones d'atterrissage de sauvegarde, et non comme un disque transactionnel à faible latence. Un autre fait structurel important compte à l'heure de la conception : la taille d'un Cluster est choisie en TiB avec un curseur, la taille minimale est de 2 TiB, la taille maximale est de 42 TiB, et la taille ne peut pas être diminuée après la mise en service, elle est donc un cliquet unidirectionnel 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 ressources statiques sur plusieurs machines virtuelles dans un centre de données virtuel	Une copie canonique au lieu d'une duplication par instance
Origine de diffusion de contenu/média	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 VM	Un répertoire partagé, avec chiffrement au niveau REST
Agrégation de journaux à partir de plusieurs machines virtuelles dans un répertoire partagé	Journaux centralisés à partir de nombreuses machines
Volumes persistants Kubernetes ReadWriteMany (RWX)	Volumes partagés pour des charges de travail conteneurisées

Pour FinCorp, le niveau d'application exécute plusieurs machines virtuelles sans état derrière un Load Balancer, et elles ont besoin d'un répertoire partagé pour les documents téléchargés et les modèles partagés. C'est exactement la première ligne ci-dessus : un partage monté en lecture-écriture par chaque instance d'application Node, plutôt qu'une copie des ressources intégrée à chaque image VM.

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

Network File Storage est régional et privé. Le Cluster est associé à un centre de données LAN et est accessible sur une adresse privée IPv4 ou IPv6 à l'intérieur de ce centre de données virtuel ; il n'y a pas de point de terminaison public, et un partage ne s'étend pas sur les régions. Les clients le montent sur le réseau privé LAN, ce qui garde le trafic hors d'internet et signifie que le transfert de données vers vos machines virtuelles n'est pas facturé. Le compromis est la portée : si FinCorp a besoin des mêmes données disponibles dans toutes les 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 entre régions, utilisez plutôt Object Storage (unité 5.2), qui est le magasin géo-étendu, API-adressable de la plateforme. Choisissez Network File Storage lorsque de nombreuses machines dans une région ont besoin d'un système de fichiers POSIX en temps réel ; choisissez Object Storage lorsque la portée, la mise à l'échelle ou l'accès programmatique dominent.

L'accès est également Linux-only et contrôlé par partage via des 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 de squash qui mappe les identités distantes Root et les utilisateurs à une identité anonyme. Le paramètre IP Networks supprime toujours la liste des hôtes, et la documentation recommande contre l'option no-squash pour des raisons de sécurité. Il s'agit de l'équivalent au niveau du fichier de la posture privée par défaut que le REST de l'architecture suit.

2. Correspondance du niveau avec le modèle d'accès et l'asymétrie de la zone

La décision de niveau est dictée par le modèle d'accès, et non par la taille. Un disque persistant à un seul auteur pour un VM est Block Storage. Un système de fichiers POSIX à plusieurs lecteurs et à plusieurs auteurs au sein d'une région est Network File Storage. Un stockage en bloc et d'archive à adresse API s'étendant sur plusieurs régions est Object Storage. Au sein de Block Storage, les niveaux SSD présentent un plancher de performance qui vaut la peine d'être pris en compte ici, car il se répète à travers le niveau de données : les volumes SSD offrent une performance complète par GiB uniquement à partir de 100 GiB, donc un petit volume SSD Volume sous-performe son niveau. Ce plancher est la raison pour laquelle les volumes SSD sous-dimensionnés sont découragés pour les charges de travail exigeantes, un point que l'unité 5.3 reprend pour les bases de données.

Il existe une asymétrie de placement qui surprend les architectes venant d'autres plateformes. Les zones de disponibilité ne sont pas symétriques entre le calcul et Block Storage. Un Volume Block Storage peut être placé dans la zone 1, la zone 2, la zone 3 ou Auto. Le calcul, cependant, n'offre que les zones 1, 2 et Auto : il n'y a pas de zone de calcul 3. La conséquence pratique est que vous ne pouvez pas attribuer un serveur à une « zone 3 » pour correspondre à un Volume de la zone 3, car aucune zone de calcul de ce type n'existe. Lorsque vous répartissez délibérément une paire redondante sur des zones, concevez autour de la réalité du calcul des zones 1 et 2, et ne supposez pas qu'un placement de Volume dans la 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 sur Auto, ce qui peut co-localiser des ressources que vous aviez l'intention de séparer.

DCD Marche à suivre pour la mise en œuvre

Cette marche à suivre met en place le stockage de fichiers partagés dont a besoin le niveau application de FinCorp : un Network File Storage Cluster sur le LAN d'application, un partage, et le montage à partir de plusieurs clients Linux. Elle met en œuvre la décision de la section 1 de conserver une seule copie canonique des ressources partagées plutôt que de les dupliquer par VM. Le prérequis est un centre de données virtuel existant avec un LAN d'application privé (construit dans l'unité 3.1) et le privilège d'accès et de gestion de Network File Storage sur votre groupe ; sans ce privilège, un utilisateur a un accès en lecture seule et ne peut pas mettre en place.

Objectif de construction : Mettre en place un stockage de fichiers partagés monté par plusieurs clients.

Étapes (dans le Data Center Designer) :

Dans le DCD, ouvrez Menu > Stockage & Sauvegarde > Network File Storage, puis sélectionnez Créer Cluster.
Définissez les propriétés de Cluster : entrez un nom de Cluster ; sélectionnez l'emplacement (l'emplacement du serveur où vivra le Cluster) ; définissez la taille en TiB avec le curseur, en rappelant la taille minimale de 2 TiB et que la taille ne peut pas être réduite plus tard ; laissez la version du système de fichiers à la valeur par défaut NFSv4.2.
Associez le Cluster à un centre de données : sélectionnez le centre de données (les choix dépendent de l'emplacement choisi) et le LAN du centre de données, qui doit être le LAN d'application privé. Entrez une adresse IPv4 (ou IPv6) privée avec CIDR pour le Cluster, en utilisant le panneau de recherche d'adresses privées sur la droite pour choisir une adresse libre qui ne rentre pas en conflit avec votre plage DHCP.
Cliquez sur Enregistrer. Le Cluster est créé et entre dans l'état OCCUPÉ ; attendez qu'il devienne DISPONIBLE avant de créer des partages.
À partir de la liste de Cluster, sélectionnez Gérer les partages dans la colonne OPTIONS (ou ouvrez le Cluster et utilisez l'onglet Gérer les partages), puis sélectionnez Créer un partage.
Définissez les propriétés du partage : entrez un nom de répertoire ; définissez facultativement une quote en MiB pour limiter le partage (définissez zéro pour désactiver la quote) ; définissez facultativement l'ID de groupe et l'ID d'utilisateur propriétaires, qui sont par défaut 65534.
Ajoutez un groupe de clients : entrez facultativement une description ; choisissez un mode d'écrasement NFS (la mise en correspondance de Root avec un utilisateur anonyme est la ligne de base recommandée ; évitez le mode sans écrasement) ; sous réseaux IP, ajoutez le réseau privé autorisé en notation CIDR (par exemple, le sous-réseau du LAN d'application) afin que seuls ces clients puissent monter.
Cliquez sur Enregistrer pour créer le partage.
Sur chaque client Linux, montez le partage en utilisant l'adresse IP privée du Cluster et l'UUID du partage : mount -t nfs <cluster-ip>:<share-uuid> <local-mount-path>. Chaque VM d'application qui monte le même Cluster IP et UUID voit maintenant les mêmes fichiers.

Erreurs courantes :

Surdimensionner le Cluster le premier jour. La taille ne peut que augmenter ; vous ne pouvez pas la réduire, donc commencez avec la taille réelle requise au-dessus de la taille minimale de 2 TiB et augmentez lorsque nécessaire.
Laisser le mode d'écrasement à Aucun. La documentation recommande contre cela ; mappez plutôt Root (ou tous les utilisateurs) à l'identité anonyme.
Oublier que les réseaux IP remplacent la liste des hôtes. Si l'accès est incorrect, vérifiez d'abord les réseaux IP CIDR, car ils ont toujours la priorité.
Supposer que NFSv3 fonctionnera. Seul NFSv4.2 est pris en charge ; les clients plus anciens échouent à monter.
S'attendre à un accès inter-région ou public. Le partage est privé et régional ; si vous en avez besoin, utilisez Object Storage, et non une exportation NFS plus large.
Essayer de monter à partir de Windows. Le support client est limité aux clients Linux.
Choisir Network File Storage pour une charge de travail d'écriture synchrone à latence faible. La latence d'écriture synchrone d'environ 20 ms et le plafond de slot RPC par montage rendent cela inapproprié ; ces données appartiennent à un Block Storage Volume attaché au seul VM qui en est propriétaire.

Résumé

Block Storage est un disque privé, unique VM iSCSI ; Network File Storage est un système de fichiers privé régional géré, NFSv4.2, que de nombreux clients Linux montent en même temps ; Object Storage est le magasin à étendue géographique, API-adressable. Le niveau suit le modèle d'accès, et non la capacité, et un choix de zone délibéré est important, car Block Storage offre la zone 3, tandis que le calcul ne le fait pas. Le niveau d'application sans état de FinCorp obtient un partage partagé pour ses actifs, dimensionné pour la croissance et verrouillé pour l'application LAN.

Points clés :

Block Storage = un VM, disque privé (l'attachement est couvert dans 4.2) ; Network File Storage = de nombreux clients Linux, un système de fichiers privé régional ; Object Storage = inter-région, API-adressable.
Network File Storage est uniquement NFSv4.2 (pas NFSv3), Linux-seulement, basé sur la classe Standard SSD, avec un plancher d'écriture synchrone d'environ 20 ms ; il ne s'agit pas d'un disque transactionnel à faible latence.
Un Cluster est dimensionné de 2 à 42 To et ne peut pas être réduit après la mise en service ; l'accès est contrôlé par des groupes de clients où la liste IP Networks supprime toujours la liste Hosts.
Les zones de disponibilité 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 de calcul 3, donc définissez 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, active-passive, que vous mettez en service et dimensionnez en To ; elle contient un ou plusieurs partages et s'attache à un seul centre de données LAN.
Partage : un système de fichiers individuel exporté dans un Cluster, avec sa propre quote-part, ses ID de propriétaire et ses groupes de clients ; plusieurs partages peuvent vivre dans un Cluster.
Mode Squash : le mappage des utilisateurs ou groupes Root distants ou de tous les utilisateurs à une identité anonyme (UID/GID 65534 par défaut) qui limite ce qu'un client de montage peut faire en tant qu'utilisateur privilégié.