Stockage objet sur Arbutus

Introduction

Le stockage d'objets est une installation de stockage plus simple qu'un système de fichiers hiérarchique normal, mais qui permet d'éviter certains goulots d'étranglement de performance.

Un objet est un fichier dans un espace de nommage (namespace) plat : un objet peut être créé ou téléchargé dans son ensemble, mais vous ne pouvez pas modifier les octets qu’il contient. Un objet est nommé selon la nomenclature bucket:tag sans qu’il soit imbriqué davantage. Puisque les opérations sur les buckets concernent l’entièreté d’un fichier, le fournisseur peut utiliser une représentation interne plus simple. L’espace de nommage plat permet au fournisseur d’éviter les goulots d’étranglement des métadonnées; on peut dire que c’est une sorte de stockage de clés et de valeurs.

La meilleure façon d’utiliser le stockage objet est de stocker et d’exporter des éléments qui ne sont pas nommés dans une structure hiérarchique; auxquels on accède principalement de manière totale et en lecture seule; et pour lesquels les règles d’accès et de contrôle sont simples. Nous recommandons son utilisation avec des plateformes ou des logiciels qui sont conçus pour travailler avec des données qui vivent dans un espace de stockage objet.

Sur Arbutus, chaque projet dispose par défaut de 1 To de stockage objet. Si ceci est insuffisant, vous pouvez soit utiliser notre service d'accès rapide ou présenter une demande aux prochains concours pour l'allocation des ressources.

Contrairement à un environnement de calcul sur une grappe, les fonctions d'administration du système pour le stockage objet d'un utilisateur sont la responsabilité de cet utilisateur, ce qui signifie que les opérations comme la sauvegarde des instances doivent être effectuées par l'utilisateur. Pour plus d'information, voyez Options de stockage infonuagique.

Nous offrons deux protocoles différents pour accéder à Object Store : Swift et Amazon Simple Storage Service (S3).

Ces protocoles se ressemblent beaucoup et sont interchangeables dans la plupart des cas. Il n’est pas nécessaire de vous en tenir toujours au même protocole puisque les conteneurs ou compartiments (buckets) et les objets sont accessibles par les protocoles Swift et S3. Certaines différences existent toutefois dans le contexte du stockage objet sur Arbutus.

Swift est le protocole par défaut et est le plus simple à utiliser; vous n’avez pas à gérer les identifiants puisque l’accès se fait avec votre compte Arbutus. Par contre, Swift n’offre pas toutes les fonctionnalités de S3. Le principal cas d'usage est que vous devez utiliser S3 pour gérer vos conteneurs avec des politiques d'accès parce que Swift ne prend pas en charge ces politiques. De plus, S3 vous permet de créer et de gérer vos propres clés, ce qui peut être nécessaire si par exemple vous voulez créer du contenu en lecture seule pour une application. Consultez la liste des points compatibles des deux protocoles dans

https://docs.openstack.org/swift/latest/s3_compat.html

Accès et gestion du Object Store

Générez votre ID d'accès S3 et la clé secrète pour le protocole avec le client de ligne de commande OpenStack.

openstack ec2 credentials create

Accessing your Arbutus Object Store

Setting access policies cannot be done via web browser but must be done with a SWIFT or S3-compatible client. There are two ways to access your data containers:

object-arbutus.cloud.computecanada.ca:443

Managing your Arbutus object store

La manière recommandée de gérer les conteneurs et les objets dans l'Arbutus Object Store est d'utiliser l'outil s3cmd, qui est disponible sous Linux. Notre documentation fournit des instructions spécifiques sur la configuration et la gestion des accès avec le client s3cmd. Il est également possible d'utiliser d'autres clients compatibles S3 qui sont également compatibles avec l'Arbutus Object Store.

De plus, nous pouvons effectuer certaines tâches de gestion pour notre stockage d'objets en utilisant la section Conteneurs sous l'onglet Stockage d'Objet dans le Tableau de bord OpenStack d'Arbutus.

Cette interface fait référence aux "conteneurs de données", également appelés "buckets" dans d'autres systèmes de stockage d'objet.

En utilisant le tableau de bord, nous pouvons créer de nouveaux conteneurs de données, téléverser des fichiers et créer des dossiers. Nous pouvons également créer des conteneurs de données en utilisant des clients compatibles S3.

Veuillez noter que les conteneurs de données appartiennent à l'utilisateur qui les crée et ne peuvent pas être manipulés par d'autres utilisateurs.
Par conséquent, vous êtes responsable de la gestion de vos conteneurs de données et de leur contenu au sein de votre projet d'infonuagique.

Si vous créez un nouveau conteneur public, n'importe qui sur Internet peut lire son contenu en naviguant simplement à l'adresse suivante

https://object-arbutus.cloud.computecanada.ca/<NOM DE VOTRE CONTENEUR>/<NOM DE VOTRE OBJET>

avec vos noms de conteneurs et d'objets insérés à la place.

It's important to keep in mind that each data container on the Arbutus Object Store must have a unique name across all users. To ensure uniqueness, we may want to prefix our data container names with our project name to avoid conflicts with other users. One useful rule of thumb is to refrain from using generic names like test for data containers. Instead, consider using more specific and unique names like def-myname-test.

To make a data container accessible to the public, we can change its policy to allow public access. This can come in handy if we need to share files to a wider audience. We can manage container policies using JSON files, allowing us to specify various access controls for our containers and objects.

Managing data container (bucket) policies for your Arbutus Object Store

Attention

Be careful with policies because an ill-conceived policy can lock you out of your data container.

Currently, Arbutus Object Storage only implements a subset of Amazon's specification for data container polices. The following example shows how to create, apply, and view a policy. The first step is create a policy json file:

{
    "Version": "2012-10-17",
    "Id": "S3PolicyId1",
    "Statement": [
        {
            "Sid": "IPAllow",
            "Effect": "Deny",
            "Principal": "*",
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::testbucket",
                "arn:aws:s3:::testbucket/*"
            ],
            "Condition": {
                "NotIpAddress": {
                    "aws:SourceIp": "206.12.0.0/16",
                    "aws:SourceIp": "142.104.0.0/16"
                }
            }
        }
    ]
}

This example denies access except from the specified source IP address ranges in Classless Inter-Domain Routing (CIDR) notation. In this example the s3://testbucket is limited to the public IP address range (206.12.0.0/16) used by the Arbutus cloud and the public IP address range (142.104.0.0/16) used by the University of Victoria.

Once you have your policy file, you can implement that policy on the data container:

s3cmd setpolicy testbucket.policy s3://testbucket

To view the policy you can use the following command:

s3cmd info s3://testbucket