Les fondamentaux du cloud computing

Services de stockage

Stockage objet, bloc et fichier : comment chacun organise les données différemment, quelles charges chacun sert vraiment, et l'erreur classique d'examen qui consiste à les traiter comme interchangeables.

Débutant 17 minutes 4 Objectifs d'apprentissage
  1. Distinguer le stockage objet, bloc et fichier selon la façon dont chacun organise les données et y donne accès
  2. Associer un type de stockage à une charge de travail selon son profil d'accès
  3. Expliquer pourquoi durabilité et disponibilité sont 2 garanties distinctes, pas une seule
  4. Identifier les produits de stockage objet, bloc et fichier proposés par AWS, Azure et Google Cloud

Le même mot, 3 métiers très différents

"Le stockage" sonne comme une seule chose jusqu'à ce que vous en ayez réellement besoin. Une application de partage de photos qui stocke 50 millions de photos d'utilisateurs, une base de données qui écrit des milliers de petites mises à jour par seconde, et 5 serveurs web qui doivent tous lire le même dossier de configuration partagé sont 3 problèmes complètement différents, et aucun stockage unique ne résout bien les 3 à la fois. Les fournisseurs cloud proposent 3 types de stockage distincts exactement pour cette raison : objet, bloc et fichier. Les distinguer par ce qu'ils sont construits pour faire, pas seulement par leur nom, est la vraie compétence que cette leçon enseigne.

Stockage objet : des buckets remplis de fichiers étiquetés

Commencez par l'application de partage de photos. Chaque image est téléversée une fois, lue de nombreuses fois, et jamais modifiée sur place : vous remplacez une photo, vous ne modifiez pas 4 Ko de son contenu. Amazon S3, le modèle du stockage objet, organise les données exactement selon ce profil : un bucket est un conteneur, et chaque fichier à l'intérieur est un objet, adressé par une clé unique plutôt que par un chemin de dossier. Il n'y a pas de véritable hiérarchie de dossiers en dessous, juste un espace de noms plat où la clé "photos/vacances/plage.jpg" ressemble à un chemin mais n'est en réalité qu'une chaîne de caractères.

Le stockage objet échange l'édition en place contre une échelle massive, un coût faible et une forte durabilité, S3 est conçu pour une durabilité de 99,999999999 % (11 neufs), atteinte en stockant les données de façon redondante entre plusieurs zones de disponibilité. Cette combinaison explique pourquoi le stockage objet est le choix par défaut pour les data lakes, les sauvegardes, les fichiers de sites statiques et les fichiers média : des charges définies par un accès écrit une fois, lu souvent, pas par des modifications constantes et localisées.

Stockage bloc : des blocs numérotés pour une seule machine

Considérez maintenant une base de données relationnelle qui écrit et réécrit des lignes en permanence. Cette charge a besoin d'une faible latence et de la capacité de modifier de petites portions de données sur place, exactement ce que le stockage objet n'offre pas. Le stockage bloc, sur le modèle d'Amazon EBS, découpe un volume en blocs de taille fixe, adressés par numéro, et attache ce volume à une seule instance, de la même façon qu'un disque dur s'attache à un seul ordinateur. Le système d'exploitation de cette instance peut formater le volume, le monter, et le traiter comme un disque local, parce que fonctionnellement, c'en est un.

Le stockage bloc est zonal : un volume EBS vit dans 1 zone de disponibilité précise et ne peut s'attacher qu'à des instances de cette même zone, c'est exactement pour cela qu'une base de données sur un seul volume EBS a toujours besoin de sa propre stratégie de réplication ou de sauvegarde pour survivre à une panne de zone. En échange de cette contrainte, le stockage bloc livre la performance à faible latence et haut débit d'IOPS dont une base de données en fonctionnement, ou le disque de démarrage d'une machine virtuelle, a réellement besoin.

Stockage fichier : un arbre de dossiers, plusieurs machines à la fois

Le troisième scénario, 5 serveurs web partageant le même dossier de configuration, a besoin de quelque chose qu'aucun des 2 autres ne fournit directement : un accès simultané depuis plusieurs machines vers la même structure de dossiers hiérarchique. Le stockage fichier, sur le modèle d'Amazon EFS, résout cela avec un protocole de système de fichiers réseau (NFS), pour que chaque serveur monte le même système de fichiers et voie les mêmes dossiers et fichiers, les modifications de l'un étant visibles pour les autres immédiatement. Contrairement à un volume EBS à attachement unique, un système de fichiers comme EFS s'agrandit automatiquement à mesure que des données s'ajoutent et peut être monté par de nombreuses instances EC2, conteneurs, et même des serveurs sur site en même temps.

La frontière, côte à côte

PropriétéObjetBlocFichier
Données organisées commeEspace de noms plat d'objets adressés par cléBlocs numérotés de taille fixeDossiers et fichiers hiérarchiques
S'attache àAccessible sur le réseau par tout client autorisé1 instance à la fois (typiquement)Plusieurs instances à la fois
Meilleur profil d'accèsÉcrit une fois, lu souvent, sans édition en placeLectures et écritures fréquentes et petites, faible latenceLectures et écritures partagées entre machines
Cas d'usage typiqueSauvegardes, média, data lakes, fichiers statiquesBases de données, volumes de démarrage, charges transactionnellesContenu partagé, répertoires personnels, configuration partagée sur une flotte
Produit AWSS3EBSEFS
Produit AzureBlob StorageManaged DisksAzure Files
Produit Google CloudCloud StoragePersistent DiskFilestore

Exemple chiffré : 1 site e-commerce, 3 décisions de stockage

Une plateforme e-commerce doit stocker 3 types de données différents, et la bonne réponse change à chaque fois. Les photos produit, des millions, téléversées une fois et servies en continu aux acheteurs : stockage objet, parce que rien dans une photo produit n'a besoin d'être modifié sur place, et le volume favorise l'échelle et le coût du stockage objet. La base de données transactionnelle qui suit commandes et inventaire : stockage bloc, parce que chaque paiement écrit et réécrit des lignes et a besoin de la faible latence que seul un volume directement attaché livre. Un dossier partagé de fichiers de cache de session que 6 serveurs web identiques derrière un répartiteur de charge doivent tous lire et écrire ensemble : stockage fichier, parce que c'est le seul des 3 construit pour un accès multi-instance simultané au même arbre de dossiers.

Échangez 2 de ces choix et le système soit casse franchement, une base de données ne tournera pas correctement sur du stockage objet, soit fonctionne mais gaspille argent et performance sur un mauvais accord qu'il n'avait pas besoin de faire.

Le piège : moins cher ne veut pas dire interchangeable

Il est tentant de regarder le prix bas au gigaoctet du stockage objet et de le voir comme "l'option économique" que vous pouvez glisser n'importe où. Ce n'est pas le cas. Le stockage objet est bon marché précisément parce qu'il renonce à l'accès en place et à faible latence dont dépend une base de données en fonctionnement ou un volume de démarrage. Déplacer les fichiers de données d'une base de données vers du stockage objet ne fait pas économiser d'argent sur un système qui fonctionne, cela produit un système qui ne fonctionne pas, parce que le type de stockage et le profil d'accès doivent correspondre. Le prix est une conséquence du compromis, pas un substitut à sa compréhension.

Où cela vous mène

3 questions trient presque toute décision de stockage : les données sont-elles modifiées sur place ou juste écrites une fois et lues, ont-elles besoin d'être partagées par plusieurs machines à la fois, et ont-elles besoin de démarrer ou faire tourner un système d'exploitation directement. Le stockage objet répond "écrit une fois, lu souvent, sans besoin de partage". Le stockage bloc répond "attaché à une machine, modifié constamment, a besoin de vitesse". Le stockage fichier répond "dossier partagé, plusieurs machines". La prochaine leçon quitte le stockage brut pour la couche à laquelle la plupart des applications parlent réellement en direct : les bases de données.