Architecture du stockage basé sur les objets et spécifications standard S3

Stockage d’objets est de plus en plus populaire parmi les architectures de stockage de données. Par rapport à systèmes de fichiers et stockage en bloc, le stockage d’objets n’est confronté à aucune limitation lors de la gestion de pétaoctets de données. De par sa conception, la nature illimitée du stockage d’objets le rend adapté aux contextes Big Data et Cloud.

De plus, le stockage d’objets est simple et efficace. CA offre réplication facile des données, évolutivité et est adapté aux contextes “Write Once Read Many” tels que l’analyse de données. Ces caractéristiques combinées à sa facilité de mise en œuvre et à sa programmabilité expliquent son utilisation largement répandue.

Qu’est-ce qu’un objet exactement ? Comment fonctionne le stockage d’objets et qu’est-ce qui lui permet d’évoluer ? Nous visons à clarifier cela.

Le stockage d’objets n’est pas exclusif aux services cloud tels qu’AWS Simple Storage Service (S3), et plusieurs solutions de stockage d’objets locales existent comme alternatives. Car AWS S3 établit une norme pour l’interface API du stockage objet, les solutions de stockage et les applications qui en consomment sont fédérées sous « compatibilité S3 ». Toute application compatible S3 fonctionne avec un grand nombre de solutions de stockage d’objets compatibles S3 et vice-versa, ce qui améliore leur croissance.

Cet article est le premier d’une série de trois :

Stockage d’objets : comment ça marche, pourquoi ça évolue

Comme son nom l’indique, le stockage d’objets contient des données sous forme d’objets. Le paradigme central du stockage d’objets consiste à optimiser les données communes et métadonnées opérations tout en couplant les deux ensemble. De quoi est composé un objet ?

C’est la combinaison d’une clé (octroi d’accès), d’une valeur (données réelles) et de métadonnées associées : à la fois l’objet et les métadonnées supplémentaires ajoutées par le stockage d’objets pour une gestion à grande échelle. Ces métadonnées sont stockées au même endroit que les données, contrairement aux systèmes de fichiers. La clé, utilisée pour accéder à l’objet, est le nom, le chemin et l’ID d’objet unique (OID) de l’objet généré par le stockage d’objets.

Les métadonnées jouent un rôle clé dans le stockage d’objets, permettant de faire une abstraction de la hiérarchie trouvée dans les systèmes de fichiers. Avec le stockage basé sur des objets, tout est stocké dans un référentiel plat sans hiérarchie. L’indexation et la gestion ultérieure sont réalisées grâce à l’utilisation exclusive des propriétés des métadonnées.

L’enrichissement personnalisé des métadonnées dans les objets est pris en charge, ce qui permet une analyse des données plus flexible. Ils aident également à contrôler la réplication des données.

Les périphériques de stockage d’objets (OSD) sont les périphériques physiques prenant en charge le stockage réel et sont soit des disques dédiés, soit des partitions dédiées au sein des disques. Les OSD peuvent être de différents types et appartenir à un ou plusieurs pools de stockage. Ces pools sont des divisions logiques de données, des objets propres et sont répliqués sur plusieurs OSD, comme indiqué ci-dessous.

Grâce à cette réplication de données sur plusieurs emplacements, le stockage d’objets permet :

• La haute disponibilité assurer une faible latence pour les requêtes et aucun goulot d’étranglement sur un seul appareil occupé ;
• Résilience et les basculements contre les pannes d’appareil ;
• Évolutivitéoù une quantité infinie d’OSD peut être ajoutée.

Il est facile avec le stockage de données objet de commencer petit et grandir: le stockage disponible et le nombre d’appareils peuvent être étendus sans mettre en danger les données existantes. C’est aussi simple que d’ajouter un nouveau nœud avec des disques bruts dans le cluster, qui sont automatiquement intégrés dans les pools de stockage. La suppression d’un périphérique de stockage est également gérée, en copiant les données qu’il détenait auparavant sur d’autres périphériques. Et la combinaison du nom, du chemin et de l’ID des objets permet d’éliminer les collisions de noms.

Cette capacité à faire évoluer le stockage est infinie. En termes de performances, il n’y a aucune différence entre la gestion de téraoctets ou de pétaoctets de données. Cela est dû à la structure plate du stockage d’objets et à l’utilisation de métadonnées d’objet supplémentaires dans l’indexation et la gestion efficace du magasin.

Dans l’ensemble, le stockage d’objets est adapté à de grands volumes de données non structurées, et n’expose jamais son infrastructure de stockage sous-jacente à ses consommateurs. Il s’agit d’une architecture adaptée au stockage distribué et évolutif. Plongeons maintenant plus avant dans l’interface permettant d’accéder à ces données.

Accès aux données de stockage d’objets : la norme API S3

Différentes implémentations de stockage d’objets existent, avec une interface moderne commune : l’interface API S3.

Dans le stockage d’objets, il est courant de transporter des données à l’aide d’un API REST HTTP. Plusieurs implémentations propriétaires de ces API existaient dans le passé pour le stockage d’objets, et peu de développeurs ont programmé les utiliser. En 2006, AWS Simple Storage Solution (S3) a établi des bases communes largement acceptées pour cette interface API.

En d’autres termes : S3 sera utilisé ici pour désigner le norme ouvertepas le service AWS.

L’API S3 REST est facile à apprendre et à utiliser. Il permet aux utilisateurs d’écrire, de répertorier, d’obtenir et de supprimer des objets à partir d’un point de terminaison unique, à l’aide de PUT, GET, etc… Dans le stockage objet, les données sont réparties logiquement en buckets : des partitions protégées de données accessibles uniquement par leur utilisateur S3 associé. Le nom du compartiment est généralement un préfixe d’un URI de demande S3.

Les utilisateurs S3 peuvent posséder un ou plusieurs compartiments, et leur Identifiants S3 leur accorder cet accès. Les informations d’identification S3 sont une paire de clé d’accès et de clé secrète. Ces deux clés sont confidentielles et accordent un accès en écriture, lecture et suppression à tout ce que l’utilisateur possède dans le stockage d’objets, elles doivent donc être propagées avec soin.

Dans l’ensemble, l’API S3 offre un certain nombre d’avantages :

• Sécurité car toute opération nécessite des informations d’identification S3 ;
• Confidentialité et isolation des données avec plusieurs utilisateurs, chaque utilisateur se voyant attribuer une partie isolée du stockage ;
• Atomicitéles écritures et les mises à jour sont effectuées en une seule transaction.

La convergence des fournisseurs de stockage et des applications utilisateur sur cette norme est un facteur extrêmement bénéfique pour la croissance du stockage objet, tant pour les fournisseurs que pour les utilisateurs. Les applications compatibles S3 ont un large marché de différentes solutions de stockage possibles, et les fournisseurs de stockage d’objets sont eux-mêmes compatibles avec de nombreuses applications S3 différentes.

Utilisation du stockage d’objets via des clients S3

L’accès aux objets s’effectue par programmation, via des clients S3. Ces clients sont utilisés par les applications compatibles S3 pour interagir avec le stockage. Il existe deux types de client :

• Clients de ligne de commande, tels que CLI AWS ou s5cmd. s5cmd est open-source, l’un des clients les plus rapides et la méthode recommandée pour interagir avec les solutions de stockage d’objets S3 via la CLI. Il est écrit en Go et peut être utilisé à partir d’un binaire pré-construit, construit à partir de la source ou utilisé dans un conteneur Docker ;
• SDK AWS, qui sont des outils de développement permettant aux applications d’interroger le stockage d’objets compatible S3. Les SDK existent pour un certain nombre de langages de programmation différents, notamment Java, C++, Python, JavaScript et plus encore.

Schémas d’URI S3

L’accès à un objet à l’aide de l’API nécessite le nom de l’objet, le nom du compartiment et le nom de la région si vous utilisez AWS S3. Ceux-ci sont ensuite fusionnés dans un URI REST, servant d’identifiant unique pour un objet. Cet URI utilise le s3:// famille de régimes :

• s3://: Obsolète, utilisé pour créer une superposition basée sur des blocs au-dessus du stockage S3 et ne sera pas utilisé dans ce contexte ;
• s3n://: protocole natif S3, prend en charge les objets individuels jusqu’à une taille de 5 Go ;
• s3a://: Successeur de s3n, construit avec le SDK AWS, plus performant, moins limité et le conseillé option pour le stockage d’objets.

De plus, nous devons spécifier le S3 point final. Par défaut, lorsque les clients S3 interrogent ces schémas, ils interrogent le stockage d’objets Amazon AWS S3. Cela doit être modifié lors de l’utilisation d’autres solutions de stockage d’objets, qui utilisent leur propre point de terminaison. Dans les paramètres de configuration des applications compatibles S3 ou en tant qu’options pour les outils CLI S3, il est possible de modifier le point de terminaison utilisé pour S3.

Utilisation des identifiants pour les clients

Les informations d’identification doivent être transmises au client afin de se connecter à un compartiment donné dans le stockage d’objets. La plupart des clients S3 peuvent récupérer les informations d’identification de différentes manières, mais les trois manières les plus courantes sont :

• En tant que variables d’environnement : AWS_ACCESS_KEY_ID pour la clé d’accès et AWS_SECRET_ACCESS_KEY pour la clé secrète ;
• Comme un credentials dossier, sous ~/.aws/credentials;
• Dans le config dossier, sous ~/.aws/config.

Lorsque l’un de ces 3 est fourni, le client S3 est en mesure de les récupérer pour se connecter à l’instance de stockage d’objets. Notez que les paramètres d’identification ont un ordre de prioritéles variables d’environnement ayant la priorité la plus élevée.

Étant donné que ces informations d’identification accordent l’accès à toutes les opérations d’un compartiment S3, leur sécurisation est essentielle. Il n’est pas recommandé de les transmettre en tant qu’options dans le shell, car elles seront enregistrées en texte brut. Par conséquent, les gérer comme des fichiers ou des variables d’environnement est la méthode préférée. Dans les environnements Kubernetes, Secrets Kubernetes aider à gérer ces informations d’identification et à les transmettre aux conteneurs en tant que variables d’environnement se fait en toute sécurité à l’aide env et envFrom de même que secretRef.

Conclusion

Le stockage basé sur des objets est populaire pour sa simplicité d’utilisation, car chaque opération de fichier est gérée avec des requêtes HTTP telles que PUT, GET…

Certaines solutions de stockage d’objets sont sur site, bien que le modèle soit associé au cloud. Les deux plus populaires sont open-source et simples à déployer. Ce sont des alternatives à part entière aux fournisseurs de stockage d’objets dans le cloud et n’auront pas d’impact sur la façon dont les consommateurs de stockage d’objets se comportent.

Les deux articles suivants de la série expliquent comment héberger le stockage d’objets dans un cluster local, via Tour et Ceph et à travers MinIO.