Accéder au contenuNavigation Accéder à la page : page précédente [raccourci clavier p] / page suivante [raccourci clavier n]
documentation.suse.com / Documentation de SUSE Enterprise Storage 7.1 / Guide d'opérations et d'administration / Accès aux données de la grappe / Ceph Object Gateway
S'applique à SUSE Enterprise Storage 7.1

21 Ceph Object Gateway

Ce chapitre présente des détails sur les tâches d'administration liées à Object Gateway, telles que la vérification de l'état du service, la gestion des comptes, les passerelles multisites ou l'authentification LDAP.

21.1 Restrictions d'Object Gateway et règles de dénomination

Voici la liste des limites importantes d'Object Gateway :

21.1.1 Limitations des compartiments

Lors de l'approche d'Object Gateway via l'API S3, les noms de compartiment doivent être conformes au DNS et peuvent contenir le caractère tiret (« - »). Lors de l'approche d'Object Gateway via l'API Swift, vous pouvez utiliser n'importe quelle combinaison de caractères UTF-8 à l'exception du caractère « / ». Le nom d'un compartiment peut comporter jusqu'à 255 caractères. Chaque nom de compartiment doit être unique.

Astuce
Astuce : utilisation de noms de compartiment conformes au DNS

Bien que vous puissiez utiliser n'importe quel nom de compartiment basé sur UTF-8 dans l'API Swift, il est recommandé de nommer les compartiments conformément aux règles de dénomination S3 afin d'éviter les problèmes d'accès au même compartiment via l'API S3.

21.1.2 Limitations des objets stockés

Nombre maximal d'objets par utilisateur

Aucune restriction par défaut (limite de ~ 2^63).

Nombre maximal d'objets par compartiment

Aucune restriction par défaut (limite de ~ 2^63).

Taille maximale d'un objet à charger/stocker

La limite est de 5 Go par chargement. Utilisez le chargement en plusieurs parties pour les objets plus volumineux. Le nombre maximal s'élève à 10 000 pour les tranches en plusieurs parties.

21.1.3 Limitations d'en-tête HTTP

La limitation de requête et d'en-tête HTTP dépend de l'interface Web utilisée. L'entité par défaut limite la taille de l'en-tête HTTP à 16 ko.

21.2 Déploiement de la passerelle Object Gateway

Le déploiement de la passerelle Ceph Object Gateway suit la même procédure que le déploiement des autres services Ceph, à l'aide de cephdm. Pour plus de détails, reportez-vous au Section 8.2, « Spécification de service et de placement », en particulier au Section 8.3.4, « Déploiement d'instances Object Gateway ».

21.3 Exploitation du service Object Gateway

Vous pouvez utiliser les passerelles Object Gateway de la même manière que les autres services Ceph en identifiant d'abord le nom du service avec la commande ceph orch ps, puis en exécutant la commande suivante pour l'exploitation des services, par exemple :

ceph orch daemon restart OGW_SERVICE_NAME

Reportez-vous au Chapitre 14, Exécution des services Ceph pour obtenir des informations complètes sur le fonctionnement des services Ceph.

21.4 Options de configuration

Reportez-vous à la Section 28.5, « Ceph Object Gateway » pour obtenir une liste des options de configuration d'Object Gateway.

21.5 Gestion des accès à la passerelle Object Gateway

Vous pouvez communiquer avec Object Gateway en utilisant une interface compatible avec S3 ou Swift. L'interface S3 est compatible avec un vaste sous-ensemble de l'API RESTful d'Amazon S3. L'interface Swift est compatible avec un vaste sous-ensemble de l'API OpenStack Swift.

Les deux interfaces nécessitent la création d'un utilisateur spécifique et l'installation du logiciel client approprié pour communiquer avec la passerelle à l'aide de la clé secrète de l'utilisateur.

21.5.1 Accès à Object Gateway

21.5.1.1 Accès à l'interface S3

Pour accéder à l'interface S3, un client REST est nécessaire. S3cmd est un client S3 de ligne de commande. Il est disponible dans OpenSUSE Build Service. Le dépôt contient des versions de distributions SUSE Linux Enterprise et de distributions openSUSE.

Si vous voulez tester votre accès à l'interface S3, vous pouvez aussi écrire un petit script Python. Le script se connecte à Object Gateway, crée un compartiment et dresse la liste de tous les compartiments. Les valeurs de aws_access_key_id (ID_clé_accès_AWS) et de aws_secret_access_key (Clé_accès_secret_AWS) sont issues des valeurs de access_key (clé_accès) et de secret_key (clé_secret) renvoyées par la commande radosgw_admin de la Section 21.5.2.1, « Ajout d'utilisateurs S3 et Swift ».

  1. Installez le paquetage python-boto :

    # zypper in python-boto
  2. Créez un script Python appelé s3test.py avec le contenu suivant :

    import boto
    import boto.s3.connection
    access_key = '11BS02LGFB6AL6H1ADMW'
    secret_key = 'vzCEkuryfn060dfee4fgQPqFrncKEIkh3ZcdOANY'
    conn = boto.connect_s3(
    aws_access_key_id = access_key,
    aws_secret_access_key = secret_key,
    host = 'HOSTNAME',
    is_secure=False,
    calling_format = boto.s3.connection.OrdinaryCallingFormat(),
    )
    bucket = conn.create_bucket('my-new-bucket')
    for bucket in conn.get_all_buckets():
      print "NAME\tCREATED".format(
      name = bucket.name,
      created = bucket.creation_date,
      )

    Remplacez HOSTNAME par le nom de l'hôte sur lequel vous avez configuré le service Object Gateway, par exemple gateway_host.

  3. Exécutez le script :

    python s3test.py

    Le script produit un résultat similaire à ceci :

    my-new-bucket 2015-07-22T15:37:42.000Z

21.5.1.2 Accès à l'interface Swift

Pour accéder à Object Gateway via l'interface Swift, vous devez disposer du client de ligne de commande swift. La page de manuel man 1 swift fournit des informations complémentaires sur les options de ligne de commande du client.

Le paquetage est inclus dans le module « Public Cloud » (Cloud public) pour SUSE Linux Enterprise 12 à partir de SP3 et SUSE Linux Enterprise 15. Avant d'installer le paquetage, vous devez activer le module et rafraîchir le dépôt des logiciels :

# SUSEConnect -p sle-module-public-cloud/12/SYSTEM-ARCH
sudo zypper refresh

Ou

# SUSEConnect -p sle-module-public-cloud/15/SYSTEM-ARCH
# zypper refresh

Pour installer la commande swift, exécutez ce qui suit :

# zypper in python-swiftclient

L'accès swift utilise la syntaxe suivante :

> swift -A http://IP_ADDRESS/auth/1.0 \
-U example_user:swift -K 'SWIFT_SECRET_KEY' list

Remplacez IP_ADDRESS par l'adresse IP du serveur de passerelle, et _SECRET_KEY par la valeur de la clé secrète SWIFT dans la sortie de la commande radosgw-admin key create exécutée pour l'utilisateur swiftswift à la Section 21.5.2.1, « Ajout d'utilisateurs S3 et Swift ».

Par exemple :

> swift -A http://gateway.example.com/auth/1.0 -U example_user:swift \
-K 'r5wWIxjOCeEO7DixD1FjTLmNYIViaC6JVhi3013h' list

La sortie est la suivante :

my-new-bucket

21.5.2 Gestion des comptes S3 et Swift

21.5.2.1 Ajout d'utilisateurs S3 et Swift

Vous devez créer un utilisateur, une clé d'accès et un secret pour permettre aux utilisateurs finaux d'interagir avec la passerelle. Il existe deux types d'utilisateur : user et subuser. Alors que des users sont employés pour les interactions avec l'interface S3, les subusers sont les utilisateurs de l'interface Swift. Chaque subuser est associé à un user.

Pour créer un utilisateur Swift, procédez de la façon suivante :

  1. Pour créer un utilisateur Swift (qui est un subuser suivant notre terminologie), vous devez d'abord créer le user qui lui est associé.

    cephuser@adm > radosgw-admin user create --uid=USERNAME \
     --display-name="DISPLAY-NAME" --email=EMAIL

    Par exemple :

    cephuser@adm > radosgw-admin user create \
       --uid=example_user \
       --display-name="Example User" \
       --email=penguin@example.com
  2. Pour créer un subuser (interface Swift) pour l'utilisateur, vous devez indiquer l'ID utilisateur (--uid=USERNAME), un ID subuser et le niveau d'accès du subuser.

    cephuser@adm > radosgw-admin subuser create --uid=UID \
     --subuser=UID \
     --access=[ read | write | readwrite | full ]

    Par exemple :

    cephuser@adm > radosgw-admin subuser create --uid=example_user \
     --subuser=example_user:swift --access=full
  3. Générez une clé secrète pour l'utilisateur.

    cephuser@adm > radosgw-admin key create \
       --gen-secret \
       --subuser=example_user:swift \
       --key-type=swift
  4. Les deux commandes afficheront des données au format JSON indiquant l'état de l'utilisateur. Notez les lignes suivantes et souvenez-vous de la valeur de secret_key (clé_secrète) :

    "swift_keys": [
       { "user": "example_user:swift",
         "secret_key": "r5wWIxjOCeEO7DixD1FjTLmNYIViaC6JVhi3013h"}],

Lorsque vous accédez à Object Gateway via l'interface S3, vous devez créer un utilisateur S3 en exécutant :

cephuser@adm > radosgw-admin user create --uid=USERNAME \
 --display-name="DISPLAY-NAME" --email=EMAIL

Par exemple :

cephuser@adm > radosgw-admin user create \
   --uid=example_user \
   --display-name="Example User" \
   --email=penguin@example.com

La commande crée également l'accès et la clé secrète de l'utilisateur. Vérifiez le résultat des mots clés access_key (clé_accès) et secret_key (clé_secret), et leurs valeurs :

[...]
 "keys": [
       { "user": "example_user",
         "access_key": "11BS02LGFB6AL6H1ADMW",
         "secret_key": "vzCEkuryfn060dfee4fgQPqFrncKEIkh3ZcdOANY"}],
 [...]

21.5.2.2 Suppression d'utilisateurs S3 et Swift

La procédure de suppression des utilisateurs est similaire pour les utilisateurs S3 et Swift. Dans le cas d'utilisateurs Swift cependant, vous devrez peut-être supprimer l'utilisateur ainsi que ses subusers.

Pour supprimer un utilisateur S3 ou Swift (y compris tous ses subusers), spécifiez user rm et l'ID utilisateur dans la commande suivante :

cephuser@adm > radosgw-admin user rm --uid=example_user

Pour supprimer un subuser, spécifiez subuser rm et l'ID de celui-ci.

cephuser@adm > radosgw-admin subuser rm --uid=example_user:swift

Vous pouvez utiliser les options suivantes :

--purge-data

Purge toutes les données associées à l'ID utilisateur.

--purge-keys

Purge toutes les clés associées à l'ID utilisateur.

Astuce
Astuce : suppression d'un subuser

Lorsque vous supprimez un subuser, vous supprimez également l'accès à l'interface Swift. L'utilisateur est conservé dans le système.

21.5.2.3 Modification de l'accès utilisateur S3 et Swift et des clés secrètes

Les paramètres access_key (clé_accès) et secret_key (clé_secret) identifient l'utilisateur Object Gateway lors de l'accès à la passerelle. La modification des clés utilisateur existantes revient à créer de nouvelles clés, car les anciennes clés sont écrasées.

Pour les utilisateurs S3, exécutez la commande suivante :

cephuser@adm > radosgw-admin key create --uid=EXAMPLE_USER --key-type=s3 --gen-access-key --gen-secret

Pour les utilisateurs Swift, exécutez la commande suivante :

cephuser@adm > radosgw-admin key create --subuser=EXAMPLE_USER:swift --key-type=swift --gen-secret
--key-type=TYPE

Indique le type de clé. Soit swift, soit s3.

--gen-access-key

Génère une clé d'accès aléatoire (pour l'utilisateur S3 par défaut).

--gen-secret

Génère une clé secrète aléatoire.

--secret=KEY

Indique une clé secrète, par exemple générée manuellement.

21.5.2.4 Activation de la gestion des quotas utilisateur

La passerelle Ceph Object Gateway vous permet de définir des quotas sur les utilisateurs et les compartiments appartenant aux utilisateurs. Les quotas incluent le nombre maximal d'objets dans un compartiment et la taille de stockage maximale en mégaoctets.

Avant d'activer un quota utilisateur, vous devez tout d'abord définir ses paramètres :

cephuser@adm > radosgw-admin quota set --quota-scope=user --uid=EXAMPLE_USER \
 --max-objects=1024 --max-size=1024
--max-objects

Indique le nombre maximal d'objets. Une valeur négative désactive la vérification.

--max-size

Indique le nombre maximal d'octets. Une valeur négative désactive la vérification.

--quota-scope

Définit l'étendue du quota. Les options sont bucket (compartiment) et user (utilisateur). Les quotas de compartiment s'appliquent aux compartiments appartenant à un utilisateur. Les quotas utilisateur s'appliquent à un utilisateur.

Une fois que vous avez défini un quota utilisateur, vous pouvez l'activer :

cephuser@adm > radosgw-admin quota enable --quota-scope=user --uid=EXAMPLE_USER

Pour désactiver un quota :

cephuser@adm > radosgw-admin quota disable --quota-scope=user --uid=EXAMPLE_USER

Pour dresser la liste des paramètres de quota :

cephuser@adm > radosgw-admin user info --uid=EXAMPLE_USER

Pour mettre à jour les statistiques de quota :

cephuser@adm > radosgw-admin user stats --uid=EXAMPLE_USER --sync-stats

21.6 Interfaces clients HTTP

La passerelle Ceph Object Gateway prend en charge deux interfaces clients HTTP : Beast et Civetweb.

L'interface client Beast utilise la bibliothèque Boost.Beast pour l'analyse HTTP et la bibliothèque Boost.Asio pour les entrées/sorties (I/O) réseau asynchrones.

L'interface client Civetweb utilise la bibliothèque HTTP Civetweb, qui est un dérivé de Mongoose.

Vous pouvez les configurer avec l'option rgw_frontends. Reportez-vous à la Section 28.5, « Ceph Object Gateway » pour obtenir une liste des options de configuration.

21.7 Activation de HTTPS/SSL pour les passerelles Object Gateway

Pour activer la passerelle Object Gateway qui permet de communiquer en toute sécurité par le biais du protocole SSL, vous devez disposer d'un certificat émis par une autorité de certification ou créer un certificat auto-signé.

21.7.1 Création d'un certificat auto-signé

Astuce
Astuce

Ignorez cette section si vous avez déjà un certificat valide signé par une autorité de certification.

La procédure suivante décrit comment générer un certificat SSL auto-signé sur Salt Master.

  1. Si Object Gateway doit être connu par d'autres identités de sujet, ajoutez-les à l'option sujetAltName dans la section [v3_req] du fichier /etc/ssl/openssl.cnf :

    [...]
    [ v3_req ]
    subjectAltName = DNS:server1.example.com DNS:server2.example.com
    [...]
    Astuce
    Astuce : adresses IP dans subjectAltName

    Pour utiliser des adresses IP à la place de noms de domaine dans l'option subjectAltName, remplacez la ligne d'exemple par la suivante :

    subjectAltName = IP:10.0.0.10 IP:10.0.0.11
  2. Créez la clé et le certificat à l'aide d'openssl. Entrez toutes les données que vous devez inclure dans votre certificat. Il est recommandé d'entrer le nom de domaine complet (FQDN) comme nom commun. Avant de signer le certificat, vérifiez que « X509v3 Subject Alternative Name: » est inclus dans les extensions requises et que « X509v3 Subject Alternative Name: » est défini dans le certificat généré.

    root@master # openssl req -x509 -nodes -days 1095 \
     -newkey rsa:4096 -keyout rgw.key
     -out rgw.pem
  3. Ajoutez la clé à la fin du fichier de certificat :

    root@master # cat rgw.key >> rgw.pem

21.7.2 Configuration d'Object Gateway avec SSL

Pour configurer Object Gateway afin d'utiliser des certificats SSL, utilisez l'option rgw_frontends. Par exemple :

cephuser@adm > ceph config set WHO rgw_frontends \
 beast ssl_port=443 ssl_certificate=config://CERT ssl_key=config://KEY

Si vous ne spécifiez pas les clés de configuration CERT et KEY, le service Object Gateway recherche le certificat et la clé SSL sous les clés de configuration suivantes :

rgw/cert/RGW_REALM/RGW_ZONE.key
rgw/cert/RGW_REALM/RGW_ZONE.crt

Si vous souhaitez remplacer l'emplacement par défaut de la clé et du certificat SSL, importez-les dans la base de données de configuration à l'aide de la commande suivante :

ceph config-key set CUSTOM_CONFIG_KEY -i PATH_TO_CERT_FILE

Utilisez ensuite vos clés de configuration personnalisées à l'aide de la directive config://.

21.8 Modules de synchronisation

Object Gateway est déployé en tant que service multisite tandis que vous pouvez mettre en miroir des données et des métadonnées entre les zones. Les modules de synchronisation sont construits au sommet de la structure multisite qui permet de transmettre des données et des métadonnées à un niveau externe différent. Un module de synchronisation permet d'effectuer un ensemble d'opérations chaque fois qu'un changement se produit dans les données (par exemple, opérations de métadonnées telles que la création d'un compartiment ou d'un utilisateur). Comme les modifications multisite Object Gateway sont finalement cohérentes sur les sites distants, elles sont propagées de manière asynchrone. Cela couvre des cas d'utilisation tels que la sauvegarde du stockage d'objets sur une grappe cloud externe, une solution de sauvegarde personnalisée à l'aide de lecteurs de bande ou encore l'indexation de métadonnées dans ElasticSearch.

21.8.1 Configuration des modules de synchronisation

Tous les modules de synchronisation sont configurés d'une manière similaire. Vous devez créer une zone (voir Section 21.13, « Passerelles Object Gateway multisites » pour plus de détails) et définir son option --tier_type, par exemple --tier-type=cloud, pour le module de synchronisation cloud :

cephuser@adm > radosgw-admin zone create --rgw-zonegroup=ZONE-GROUP-NAME \
 --rgw-zone=ZONE-NAME \
 --endpoints=http://endpoint1.example.com,http://endpoint2.example.com, [...] \
 --tier-type=cloud

Vous pouvez configurer le niveau spécifique à l'aide de la commande suivante :

cephuser@adm > radosgw-admin zone modify --rgw-zonegroup=ZONE-GROUP-NAME \
 --rgw-zone=ZONE-NAME \
 --tier-config=KEY1=VALUE1,KEY2=VALUE2

KEY dans la configuration spécifie la variable de configuration que vous souhaitez mettre à jour et VALUE indique sa nouvelle valeur. Les valeurs imbriquées peuvent être accédées à l'aide d'un point. Par exemple :

cephuser@adm > radosgw-admin zone modify --rgw-zonegroup=ZONE-GROUP-NAME \
 --rgw-zone=ZONE-NAME \
 --tier-config=connection.access_key=KEY,connection.secret=SECRET

Vous pouvez accéder aux entrées de tableau en ajoutant des crochets « [] » avec l'entrée référencée et vous pouvez ajouter une nouvelle entrée de tableau à l'aide de crochets « [] ». La valeur d'index -1 fait référence à la dernière entrée du tableau. Il n'est pas possible de créer une entrée et de la référencer à nouveau dans la même commande. Par exemple, une commande pour créer un profil pour les compartiments commençant par PREFIX se présenterait comme suit :

cephuser@adm > radosgw-admin zone modify --rgw-zonegroup=ZONE-GROUP-NAME \
 --rgw-zone=ZONE-NAME \
 --tier-config=profiles[].source_bucket=PREFIX'*'
cephuser@adm > radosgw-admin zone modify --rgw-zonegroup=ZONE-GROUP-NAME \
 --rgw-zone=ZONE-NAME \
 --tier-config=profiles[-1].connection_id=CONNECTION_ID,profiles[-1].acls_id=ACLS_ID
Astuce
Astuce : ajout et suppression d'entrées de configuration

Vous pouvez ajouter une nouvelle entrée de configuration de niveau à l'aide du paramètre --tier-config-add=KEY=VALUE.

Vous pouvez supprimer une entrée existante à l'aide de --tier-config-rm=KEY.

21.8.2 Synchronisation des zones

Une configuration de module de synchronisation est locale pour une zone en particulier. Le module de synchronisation détermine si la zone exporte des données ou ne peut consommer que des données modifiées dans une autre zone. Depuis la version « Luminous », les plug-ins de synchronisation pris en charge sont ElasticSearch, rgw (qui est le plug-in de synchronisation par défaut des données entre les zones) et log (qui est un plug-in générique de synchronisation consignant les opérations de métadonnées entre zones distantes). Les sections suivantes s'appuient sur l'exemple d'une zone qui utilise le module de synchronisation ElasticSearch. Le processus serait similaire pour la configuration de tout autre plug-in de synchronisation.

Note
Note : plug-in de synchronisation par défaut

rgw est le plug-in de synchronisation par défaut et il n'est pas nécessaire de le configurer explicitement.

21.8.2.1 Exigences et hypothèses

Supposons que vous ayez la configuration multisite simple décrite à la Section 21.13, « Passerelles Object Gateway multisites » et composée de deux zones : us-east et us-west. Maintenant, nous ajoutons une troisième zone us-east-es, qui traite uniquement les métadonnées des autres sites. Cette zone peut résider dans la même grappe Ceph ou dans une autre que us-east. Cette zone ne consommera que les métadonnées d'autres zones et les passerelles Object Gateway de cette zone ne serviront pas directement les requêtes des utilisateurs finaux.

21.8.2.2 Configuration des zones

  1. Créez la troisième zone similaire à celles décrites dans la Section 21.13, « Passerelles Object Gateway multisites », par exemple :

    cephuser@adm > radosgw-admin zone create --rgw-zonegroup=us --rgw-zone=us-east-es \
    --access-key=SYSTEM-KEY --secret=SECRET --endpoints=http://rgw-es:80
  2. Il est possible de configurer un module de synchronisation pour cette zone avec la commande suivante :

    cephuser@adm > radosgw-admin zone modify --rgw-zone=ZONE-NAME --tier-type=TIER-TYPE \
    --tier-config={set of key=value pairs}
  3. Par exemple, dans le module de synchronisation ElasticSearch :

    cephuser@adm > radosgw-admin zone modify --rgw-zone=ZONE-NAME --tier-type=elasticsearch \
    --tier-config=endpoint=http://localhost:9200,num_shards=10,num_replicas=1

    Pour les différentes options tier-config prises en charge, reportez-vous à la Section 21.8.3, « Module de synchronisation ElasticSearch ».

  4. Enfin, mettez à jour la période :

    cephuser@adm > radosgw-admin period update --commit
  5. Démarrez ensuite la passerelle Object Gateway dans la zone :

    cephuser@adm > ceph orch start rgw.REALM-NAME.ZONE-NAME

21.8.3 Module de synchronisation ElasticSearch

Ce module de synchronisation écrit les métadonnées d'autres zones dans ElasticSearch. À partir de la version « Luminous », voici les champs de données JSON qui sont stockés dans ElasticSearch.

{
  "_index" : "rgw-gold-ee5863d6",
  "_type" : "object",
  "_id" : "34137443-8592-48d9-8ca7-160255d52ade.34137.1:object1:null",
  "_score" : 1.0,
  "_source" : {
    "bucket" : "testbucket123",
    "name" : "object1",
    "instance" : "null",
    "versioned_epoch" : 0,
    "owner" : {
      "id" : "user1",
      "display_name" : "user1"
    },
    "permissions" : [
      "user1"
    ],
    "meta" : {
      "size" : 712354,
      "mtime" : "2017-05-04T12:54:16.462Z",
      "etag" : "7ac66c0f148de9519b8bd264312c4d64"
    }
  }
}

21.8.3.1 Paramètres de configuration du type de niveau ElasticSearch

endpoint

Indique le noeud d'extrémité du serveur ElasticSearch auquel accéder.

num_shards

(entier) Nombre de partitions avec lesquelles ElasticSearch sera configuré lors de l'initialisation de la synchronisation des données. Notez que cela ne peut pas être modifié après l'initialisation. Toute modification nécessite la reconstruction de l'index ElasticSearch et la réinitialisation du processus de synchronisation des données.

num_replicas

(entier) Nombre de répliques avec lesquelles ElasticSearch sera configuré lors de l'initialisation de la synchronisation des données.

explicit_custom_meta

(true | false) Indique si toutes les métadonnées personnalisées de l'utilisateur seront indexées ou si l'utilisateur devra configurer (au niveau compartiment) les entrées de métadonnées client à indexer. La valeur par défaut est « false ».

index_buckets_list

(liste de chaînes séparées par des virgules) Si elle est vide, tous les compartiments seront indexés. Dans le cas contraire, l'indexation portera uniquement sur les compartiments spécifiés ici. Il est possible de fournir des préfixes de compartiment (« foo * », par exemple) ou des suffixes de compartiment (« *bar », par exemple).

approved_owners_list

(liste de chaînes séparées par des virgules) Si elle est vide, les compartiments de tous les propriétaires seront indexés (sous réserve d'autres restrictions) ; dans le cas contraire, l'indexation portera uniquement sur les compartiments appartenant aux propriétaires spécifiés. Il est également possible de définir des suffixes et des préfixes.

override_index_path

(chaîne) Si elle n'est pas vide, cette chaîne sera utilisée comme chemin d'index ElasticSearch. Dans le cas contraire, le chemin d'index sera déterminé et généré lors de l'initialisation de la synchronisation.

username

Spécifie un nom d'utilisateur pour ElasticSearch si l'authentification est nécessaire.

password

Spécifie un mot de passe pour ElasticSearch si l'authentification est nécessaire.

21.8.3.2 Requêtes de métadonnées

Étant donné que la grappe ElasticSearch stocke désormais les métadonnées d'objet, il est important que le noeud d'extrémité ElasticSearch ne soit pas exposé à tous les utilisateurs, mais accessible uniquement aux administrateurs de la grappe. L'exposition de requêtes de métadonnées à l'utilisateur final lui-même engendre un problème, car celui-ci doit interroger uniquement ses métadonnées et non pas celles des autres utilisateurs. Cette opération requiert que la grappe ElasticSearch authentifie les utilisateurs d'une manière similaire à RGW, ce qui pose problème.

À partir de la version « Luminous » de RGW, la zone maître des métadonnées peut traiter les demandes des utilisateurs finaux. Cette approche présente l'avantage de masquer le noeud d'extrémité ElasticSearch pour le public et de résoudre le problème d'authentification et d'autorisation, puisque RGW peut authentifier lui-même les requêtes de l'utilisateur final. Dans cette optique, RGW introduit une nouvelle requête dans les API de compartiment pouvant desservir les requêtes ElasticSearch. Toutes ces requêtes doivent être envoyées à la zone maître de métadonnées.

Obtention d'une requête ElasticSearch
GET /BUCKET?query=QUERY-EXPR

Paramètres de requête :

  • max-keys : nombre maximal d'entrées à renvoyer

  • marker : marqueur de pagination

expression := [(]<arg> <op> <value> [)][<and|or> ...]

op est l'un des opérateurs suivants : <, <=, ==, >=, >

Par exemple :

GET /?query=name==foo

Renvoie toutes les clés indexées pour lesquelles l'utilisateur dispose d'une autorisation de lecture et qui s'appellent « foo ». Dans ce cas, la sortie se compose d'une liste XML de clés similaire à la sortie des compartiments de liste S3.

Configuration des champs de métadonnées personnalisés

Définissez quelles entrées de métadonnées personnalisées doivent être indexées (sous le compartiment indiqué) et précisez le type de ces clés. Si l'indexation explicite de métadonnées personnalisées est configurée, cette opération est nécessaire pour que rgw indexe les valeurs de ces métadonnées personnalisées. Dans le cas contraire, cette opération est nécessaire lorsque les clés de métadonnées indexées ne sont pas du type chaîne.

POST /BUCKET?mdsearch
x-amz-meta-search: <key [; type]> [, ...]

Les champs de métadonnées doivent être séparés les uns des autres par des virgules ; pour forcer le type d'un champ, indiquez « ; ». Les types actuellement autorisés sont « string » (chaîne - valeur par défaut), « integer » (entier) et « date ». Par exemple, si vous souhaitez indexer des métadonnées d'objet personnalisées x-amz-meta-year comme entier, x-amz-meta-date comme date et x-amz-meta-title comme chaîne, vous exécuteriez la commande suivante :

POST /mybooks?mdsearch
x-amz-meta-search: x-amz-meta-year;int, x-amz-meta-release-date;date, x-amz-meta-title;string
Suppression de la configuration des métadonnées personnalisée

Supprimez la configuration de compartiment de métadonnées personnalisée.

DELETE /BUCKET?mdsearch
Obtention de la configuration des métadonnées personnalisée

Récupérez la configuration de compartiment de métadonnées personnalisée.

GET /BUCKET?mdsearch

21.8.4 Module de synchronisation cloud

Cette section présente un module qui synchronise les données de zone avec un service cloud distant. La synchronisation est unidirectionnelle : la date n'est pas resynchronisée à partir de la zone distante. L'objectif principal de ce module est de permettre la synchronisation des données auprès de plusieurs fournisseurs de services cloud. Actuellement, il prend en charge les fournisseurs de services cloud qui sont compatibles avec AWS (S3).

Pour synchroniser les données auprès d'un service cloud distant, vous devez configurer les informations d'identification de l'utilisateur. Étant donné que de nombreux services cloud introduisent des limites sur le nombre de compartiments que chaque utilisateur peut créer, vous pouvez configurer l'assignation des objets et compartiments sources, des cibles différentes pour différents compartiments et des préfixes de compartiment. Notez que les listes d'accès (ACL) sources ne seront pas conservées. Il est possible d'assigner les autorisations d'utilisateurs sources spécifiques à des utilisateurs cibles spécifiques.

En raison de limitations d'API, il n'existe aucun moyen de conserver l'heure de modification de l'objet d'origine ni la balise d'entité HTTP (Etag). Le module de synchronisation cloud enregistre ces informations sous forme d'attributs de métadonnées sur les objets cibles.

21.8.4.1 Configuration du module de synchronisation cloud

Voici des exemples d'une configuration générique et non générique pour le module de synchronisation cloud. Notez que la configuration générique peut entrer en conflit avec la configuration non générique.

Exemple 21.1 : configuration générique
{
  "connection": {
    "access_key": ACCESS,
    "secret": SECRET,
    "endpoint": ENDPOINT,
    "host_style": path | virtual,
  },
  "acls": [ { "type": id | email | uri,
    "source_id": SOURCE_ID,
    "dest_id": DEST_ID } ... ],
  "target_path": TARGET_PATH,
}
Exemple 21.2 : configuration non générique
{
  "default": {
    "connection": {
      "access_key": ACCESS,
      "secret": SECRET,
      "endpoint": ENDPOINT,
      "host_style" path | virtual,
    },
    "acls": [
    {
      "type": id | email | uri,   #  optional, default is id
      "source_id": ID,
      "dest_id": ID
    } ... ]
    "target_path": PATH # optional
  },
  "connections": [
  {
    "connection_id": ID,
    "access_key": ACCESS,
    "secret": SECRET,
    "endpoint": ENDPOINT,
    "host_style": path | virtual,  # optional
  } ... ],
  "acl_profiles": [
  {
    "acls_id": ID, # acl mappings
    "acls": [ {
      "type": id | email | uri,
      "source_id": ID,
      "dest_id": ID
    } ... ]
  }
  ],
  "profiles": [
  {
   "source_bucket": SOURCE,
   "connection_id": CONNECTION_ID,
   "acls_id": MAPPINGS_ID,
   "target_path": DEST,          # optional
  } ... ],
}

Voici l'explication des termes de configuration utilisés :

connection

Représente une connexion au service cloud distant. Contient les valeurs « connection_id », « access_key », « secret », « endpoint » et « host_style ».

access_key

Clé d'accès cloud distant qui sera utilisée pour la connexion spécifique.

secret

Clé secrète du service cloud distant.

endpoint

URL du noeud d'extrémité du service cloud distant.

host_style

Type de style hôte (« path » [chemin] ou « virtual » [virtuel]) à utiliser lors de l'accès au noeud d'extrémité cloud distant. La valeur par défaut est « path ».

acls

Tableau des assignations de liste d'accès.

acl_mapping

Chaque structure « acl_mapping » contient les valeurs « type », « source_id » et « dest_id ». Celles-ci définissent la mutation ACL pour chaque objet. Une mutation ACL permet de convertir l'ID utilisateur source en ID cible.

type

Type d'ACL : « id » définit l'identifiant utilisateur, « email » définit l'utilisateur à l'aide de son adresse électronique et « uri » définit l'utilisateur selon son URI (groupe).

source_id

ID de l'utilisateur dans la zone source.

dest_id

ID de l'utilisateur dans la destination.

target_path

Chaîne qui définit la façon dont le chemin cible est créé. Le chemin cible spécifie un préfixe auquel le nom de l'objet source est ajouté. Les valeurs du chemin cible pouvant être configurées sont les variables suivantes :

SID

Chaîne unique qui représente l'ID d'instance de synchronisation.

ZONEGROUP

Nom du groupe de zones.

ZONEGROUP_ID

ID du groupe de zones.

ZONE

Nom de la zone.

ZONE_ID

ID de la zone.

BUCKET

Nom du compartiment source.

OWNER

ID du propriétaire du compartiment source.

Par exemple : target_path = rgwx-ZONE-SID/OWNER/BUCKET

acl_profiles

Tableau des profils de listes d'accès.

acl_profile

Chaque profil contient une valeur « acls_id » qui représentent le profil et un tableau « acls » qui reprend une liste des « acl_mappings ».

profiles

Liste des profils. Chaque profil contient les éléments suivants :

source_bucket

Nom ou préfixe (si se termine avec *) de compartiment qui définit le ou les compartiments sources de ce profil.

target_path

Voir ci-dessus pour l'explication.

connection_id

ID de la connexion qui sera utilisée pour ce profil.

acls_id

ID du profil d'ACL qui sera utilisé pour ce profil.

21.8.4.2 Valeurs configurables spécifiques à S3

Le module de synchronisation cloud fonctionne uniquement avec les interfaces dorsales compatibles avec AWS S3. Quelques valeurs configurables peuvent être utilisées pour modifier son comportement lors de l'accès aux services cloud S3 :

{
  "multipart_sync_threshold": OBJECT_SIZE,
  "multipart_min_part_size": PART_SIZE
}
multipart_sync_threshold

Les objets dont la taille est égale ou supérieure à cette valeur seront synchronisés avec le service cloud à l'aide du téléchargement en plusieurs parties.

multipart_min_part_size

Taille minimale des parties à utiliser lors de la synchronisation d'objets à l'aide du téléchargement en plusieurs parties.

21.8.5 Module de synchronisation de l'archivage

Le module de synchronisation de l'archivage utilise la fonction de contrôle de version des objets S3 dans Object Gateway. Vous pouvez configurer une zone d'archivage qui capture les différentes versions des objets S3 au fur et à mesure qu'elles apparaissent dans d'autres zones. L'historique des versions que la zone d'archivage conserve ne peut être éliminé que par le biais des passerelles associées à cette dernière.

Avec une telle architecture, plusieurs zones sans contrôle de version peuvent mettre en miroir leurs données et métadonnées via leurs passerelles de zone de manière à offrir une haute disponibilité aux utilisateurs finaux, tandis que la zone d'archivage capture toutes les mises à jour de données pour les consolider en tant que versions d'objets S3.

En incluant la zone d'archivage dans une configuration multizone, vous bénéficiez de la flexibilité d'un historique des objets S3 au sein d'une zone unique, tout en économisant l'espace que les répliques des objets S3 avec contrôle de version consommeraient dans les autres zones.

21.8.5.1 Configuration du module de synchronisation de l'archivage

Astuce
Astuce : pour en savoir plus

Reportez-vous à la Section 21.13, « Passerelles Object Gateway multisites » pour plus de détails sur la configuration des passerelles multisites.

Reportez-vous à la Section 21.8, « Modules de synchronisation » pour plus de détails sur la configuration des modules de synchronisation.

Pour utiliser le module de synchronisation de l'archivage, vous devez créer une zone dont le type de niveau est défini sur archive :

cephuser@adm > radosgw-admin zone create --rgw-zonegroup=ZONE_GROUP_NAME \
 --rgw-zone=OGW_ZONE_NAME \
 --endpoints=http://OGW_ENDPOINT1_URL[,http://OGW_ENDPOINT2_URL,...]
 --tier-type=archive

21.9 authentification LDAP

Outre l'authentification par défaut des utilisateurs locaux, Object Gateway peut également utiliser les services du serveur LDAP pour authentifier les utilisateurs.

21.9.1 Mécanisme d'authentification

Object Gateway extrait les informations d'identification LDAP de l'utilisateur à partir d'un jeton. Un filtre de recherche est défini à partir du nom d'utilisateur. La passerelle Object Gateway utilise le compte de service configuré pour rechercher une entrée correspondante dans l'annuaire. Si une entrée est trouvée, la passerelle Object Gateway tente d'établir une liaison avec le nom distinctif trouvé et le mot de passe à partir du jeton. Si les informations d'identification sont valides, la liaison réussit et Object Gateway accorde l'accès.

Vous pouvez limiter les utilisateurs autorisés en définissant la base de la recherche sur une unité organisationnelle spécifique ou en spécifiant un filtre de recherche personnalisé, qui, par exemple, exige l'appartenance à un groupe spécifique, des classes d'objets personnalisées ou des attributs.

21.9.2 Configuration requise

  • LDAP ou Active Directory : instance LDAP en cours d'exécution accessible par Object Gateway.

  • Compte de service : informations d'identification LDAP que la passerelle Object Gateway doit utiliser avec les autorisations de recherche.

  • Compte utilisateur : au moins un compte utilisateur dans l'annuaire LDAP.

Important
Important : différenciation des utilisateurs LDAP et des utilisateurs locaux

Vous ne devez pas utiliser les mêmes noms d'utilisateur pour les utilisateurs locaux et les utilisateurs authentifiées à l'aide de LDAP. La passerelle Object Gateway ne peut pas les distinguer et les traite comme un même utilisateur.

Astuce
Astuce : contrôle d'intégrité

Vérifiez le compte de service ou la connexion LDAP à l'aide de l'utilitaire ldapsearch. Par exemple :

> ldapsearch -x -D "uid=ceph,ou=system,dc=example,dc=com" -W \
-H ldaps://example.com -b "ou=users,dc=example,dc=com" 'uid=*' dn

Veillez à utiliser les mêmes paramètres LDAP que dans le fichier de configuration Ceph pour éliminer les problèmes éventuels.

21.9.3 Configuration de la passerelle Object Gateway en vue de l'utilisation de l'authentification LDAP

Les paramètres suivants sont liés à l'authentification LDAP :

rgw_s3_auth_use_ldap

Définissez cette option sur true pour activer l'authentification S3 avec LDAP.

rgw_ldap_uri

Indique le serveur LDAP à utiliser. Veillez à utiliser le paramètre ldaps://FQDN:PORT afin d'éviter de transmettre les informations d'identification en texte brut sur une liaison non sécurisée.

rgw_ldap_binddn

Nom distinctif (DN) du compte de service utilisé par Object Gateway.

rgw_ldap_secret

Mot de passe du compte de service.

rgw_ldap_searchdn

Indique la base dans l'arborescence des informations d'annuaire pour la recherche d'utilisateurs. Il peut s'agir de l'unité organisationnelle de vos utilisateurs ou d'une unité organisationnelle plus spécifique.

rgw_ldap_dnattr

Attribut utilisé dans le filtre de recherche en vue de correspondre à un nom d'utilisateur. Il s'agit le plus souvent de uid ou cn selon votre arborescence d'annuaire.

rgw_search_filter

Si cette information n'est pas indiquée, la passerelle Object Gateway s'appuie sur le paramètre rgw_ldap_dnattr pour définir automatiquement le filtre de recherche. Utilisez ce paramètre pour limiter librement la liste des utilisateurs autorisés. Reportez-vous à la Section 21.9.4, « Utilisation d'un filtre de recherche personnalisé pour limiter l'accès des utilisateurs » pour plus d'informations.

21.9.4 Utilisation d'un filtre de recherche personnalisé pour limiter l'accès des utilisateurs

Il existe deux moyens d'utiliser le paramètre rgw_search_filter.

21.9.4.1 Filtre partiel de restriction supplémentaire du filtre de recherche construit

Voici un exemple de filtre partiel :

"objectclass=inetorgperson"

La passerelle Object Gateway génère le filtre de recherche comme d'habitude avec le nom d'utilisateur issu du jeton et la valeur de rgw_ldap_dnattr. Le filtre construit est ensuite combiné au filtre partiel à partir de l'attribut rgw_search_filter. En fonction du nom d'utilisateur et des paramètres, le filtre de recherche final peut devenir ce qui suit :

"(&(uid=hari)(objectclass=inetorgperson))"

Dans ce cas, l'utilisateur « hari » ne recevra un accès que s'il se trouve dans l'annuaire LDAP, possède la classe d'objets « inetorgperson » et a fourni un mot de passe valide.

21.9.4.2 Filtre complet

Un filtre complet doit contenir un jeton USERNAME qui sera remplacé par le nom d'utilisateur lors de la tentative d'authentification. Le paramètre rgw_ldap_dnattr n'est plus utilisé dans ce cas. Par exemple, pour limiter les utilisateurs valides à un groupe spécifique, utilisez le filtre suivant :

"(&(uid=USERNAME)(memberOf=cn=ceph-users,ou=groups,dc=mycompany,dc=com))"
Note
Note : attribut memberOf

L'utilisation de l'attribut memberOf dans les recherches LDAP requiert la prise en charge côté serveur dans votre implémentation de serveur LDAP spécifique.

21.9.5 Génération d'un jeton d'accès pour l'authentification LDAP

L'utilitaire radosgw-token génère le jeton d'accès basé sur le nom d'utilisateur et le mot de passe LDAP. Il génère une chaîne codée en base 64 correspondant au jeton d'accès physique. Utilisez votre client S3 favori (voir Section 21.5.1, « Accès à Object Gateway ») et spécifiez le jeton en tant que clé d'accès ainsi qu'une clé secrète vide.

> export RGW_ACCESS_KEY_ID="USERNAME"
> export RGW_SECRET_ACCESS_KEY="PASSWORD"
cephuser@adm > radosgw-token --encode --ttype=ldap
Important
Important : informations d'identification en texte clair

Le jeton d'accès est une structure JSON codée en base 64 qui contient les informations d'identification LDAP en texte clair.

Note
Note : Active Directory

Pour Active Directory, utilisez le paramètre --ttype=ad.

21.10 Partitionnement d'index de compartiment

Object Gateway stocke les données d'index de compartiment dans une réserve d'index, par défaut .rgw.buckets.index. Si vous placez trop d'objets (plusieurs centaines de milliers) dans un même compartiment et que le quota du nombre maximal d'objets par compartiment (rgw bucket default quota max objects) n'est pas défini, les performances de la réserve d'index risquent de se dégrader. Le partitionnement d'index de compartiment maintient le niveau de performances et autorise un nombre élevé d'objets par compartiment.

21.10.1 Repartitionnement d'index de compartiment

Si un compartiment est devenu volumineux et que sa configuration initiale n'est plus suffisante, la réserve d'index du compartiment doit être redéfinie. Vous pouvez soit utiliser le repartitionnement d'index de compartiment en ligne automatique (voir Section 21.10.1.1, « Repartitionnement dynamique »), soit repartitionner l'index de compartiment hors ligne manuellement (voir Section 21.10.1.2, « Repartitionnement manuel »).

21.10.1.1 Repartitionnement dynamique

Depuis la version 5 de SUSE Enterprise Storage, le repartitionnement de compartiments en ligne est pris en charge. Il vérifie si le nombre d'objets par compartiment atteint un certain seuil et augmente automatiquement le nombre de partitions utilisées par l'index de compartiment. Ce processus réduit le nombre d'entrées dans chaque partition d'index de compartiment.

Le processus de détection s'exécute :

  • Lorsque les nouveaux objets sont ajoutés au compartiment.

  • Dans un processus d'arrière-plan qui analyse périodiquement tous les compartiments. Cela est nécessaire pour traiter les compartiments existants qui ne sont pas mis à jour.

Un compartiment devant être partitionné est ajouté à la file d'attente reshard_log en vue de son traitement ultérieur. Les threads de repartitionnement s'exécutent en arrière-plan et effectuent un repartitionnement planifié à la fois.

Configuration du repartitionnement dynamique
rgw_dynamic_resharding

Active ou désactive le repartitionnement dynamique d'index de compartiment. Les valeurs admises sont « true » ou « false ». La valeur par défaut est « true ».

rgw_reshard_num_logs

Nombre de partitions pour le journal de repartitionnement. La valeur par défaut est 16.

rgw_reshard_bucket_lock_duration

Durée de verrouillage sur l'objet Compartiment pendant le repartitionnement. La valeur par défaut est de 120 secondes.

rgw_max_objs_per_shard

Nombre maximal d'objets par partition d'index de compartiment. La valeur par défaut est de 100 000 objets.

rgw_reshard_thread_interval

Durée maximale entre deux exécutions du repartitionnement de threads. La valeur par défaut est de 600 secondes.

Commandes d'administration du processus de repartitionnement
Ajouter un compartiment à la file d'attente du repartitionnement :
cephuser@adm > radosgw-admin reshard add \
 --bucket BUCKET_NAME \
 --num-shards NEW_NUMBER_OF_SHARDS
Dresser la liste de la file d'attente de repartitionnement :
cephuser@adm > radosgw-admin reshard list
Traiter/planifier un repartitionnement de compartiment :
cephuser@adm > radosgw-admin reshard process
Afficher l'état du repartitionnement de compartiment :
cephuser@adm > radosgw-admin reshard status --bucket BUCKET_NAME
Annuler la mise en attente du repartitionnement de compartiment :
cephuser@adm > radosgw-admin reshard cancel --bucket BUCKET_NAME

21.10.1.2 Repartitionnement manuel

Le repartitionnement dynamique mentionné à la Section 21.10.1.1, « Repartitionnement dynamique » est pris en charge uniquement pour les configurations Object Gateway simples. Pour les configurations multisites, utilisez le repartitionnement manuel décrit dans cette section.

Pour repartitionner l'index de compartiment manuellement hors ligne, utilisez la commande suivante :

cephuser@adm > radosgw-admin bucket reshard

La commande bucket reshard effectue les opérations suivantes :

  • Elle crée un nouvel ensemble d'objets d'index de compartiment pour l'objet spécifié.

  • Elle propage toutes les entrées de ces objets d'index.

  • Elle crée une nouvelle instance de compartiment.

  • Elle lie la nouvelle occurrence de compartiment au compartiment afin que toutes les nouvelles opérations d'index passent par les nouveaux index de compartiment.

  • Elle copie l'ancien ID et le nouvel ID de compartiment vers la sortie standard.

Astuce
Astuce

Lorsque vous choisissez un certain nombre de partitions, tenez compte des points suivants : visez un maximum de 100 000 entrées par partition. Les nombres premiers de partitions d'index de compartiment ont tendance à mieux répartir les entrées d'index de compartiment entre les partitions. Par exemple, 503 partitions d'index de compartiment fonctionnent mieux que 500 puisque 503 est un nombre premier.

Procédure 21.1 : Repartitionnement de l'index de compartiment
  1. Assurez-vous que toutes les opérations à effectuer dans le compartiment sont bien arrêtées.

  2. Sauvegardez l'index de compartiment original :

    cephuser@adm > radosgw-admin bi list \
     --bucket=BUCKET_NAME \
     > BUCKET_NAME.list.backup
  3. Repartitionnez l'index de compartiment :

     cephuser@adm > radosgw-admin bucket reshard \
     --bucket=BUCKET_NAME \
     --num-shards=NEW_SHARDS_NUMBER
    Astuce
    Astuce : ancien ID de compartiment

    Dans le cadre de sa sortie, cette commande affiche également le nouvel ID et l'ancien ID du compartiment.

21.10.2 Partitionnement d'index des nouveaux compartiments

Deux options affectent le partitionnement d'index de compartiment :

  • Utilisez l'option rgw_override_bucket_index_max_shards pour les configurations simples.

  • Utilisez l'option bucket_index_max_shards pour les configurations multisites.

Définir les options sur 0 désactive le partitionnement d'index de compartiment. Une valeur supérieure à 0 active le partitionnement d'index de compartiment et définit le nombre maximal de partitions.

La formule suivante permet de calculer le nombre recommandé de partitions :

number_of_objects_expected_in_a_bucket / 100000

Sachez que le nombre maximal de partitions est 7877.

21.10.2.1 Configurations multisites

Les configurations multisites peuvent disposer d'une réserve d'index différente pour gérer le basculement. Pour configurer un nombre de partitions cohérent pour les zones d'un groupe de zones, définissez l'option bucket_index_max_shards dans la configuration du groupe de zones :

  1. Exportez la configuration du groupe de zones dans le fichier zonegroup.json :

    cephuser@adm > radosgw-admin zonegroup get > zonegroup.json
  2. Modifiez le fichier zonegroup.json et définissez l'option bucket_index_max_shards pour chaque zone nommée.

  3. Réinitialisez le groupe de zones :

    cephuser@adm > radosgw-admin zonegroup set < zonegroup.json
  4. Mettez à jour la période. Reportez-vous à la Section 21.13.2.6, « Mise à jour de la période ».

21.11 Intégration à OpenStack Keystone

OpenStack Keystone est un service d'identité pour le produit OpenStack. Vous pouvez intégrer la passerelle Object Gateway à Keystone pour configurer une passerelle qui accepte un jeton d'authentification Keystone. Un utilisateur autorisé par Keystone à accéder à la passerelle est vérifié du côté de Ceph Object Gateway et créé automatiquement, si nécessaire. Object Gateway interroge Keystone périodiquement pour obtenir la liste des jetons révoqués.

21.11.1 Configuration d'OpenStack

Avant de configurer la passerelle Ceph Object Gateway, vous devez configurer OpenStack Keystone afin d'activer le service Swift et de le faire pointer vers la passerelle Ceph Object Gateway :

  1. Définissez le service Swift. Pour utiliser OpenStack en vue de la validation des utilisateurs Swift, créez d'abord le service Swift :

    > openstack service create \
     --name=swift \
     --description="Swift Service" \
     object-store
  2. Définissez les noeuds d'extrémité. Après avoir créé le service Swift, pointez vers la passerelle Ceph Object Gateway. Remplacez REGION_NAME par le nom du groupe de zones ou de la région de la passerelle.

    > openstack endpoint create --region REGION_NAME \
     --publicurl   "http://radosgw.example.com:8080/swift/v1" \
     --adminurl    "http://radosgw.example.com:8080/swift/v1" \
     --internalurl "http://radosgw.example.com:8080/swift/v1" \
     swift
  3. Vérifiez les paramètres. Après avoir créé le service Swift et défini les noeuds d'extrémité, affichez ceux-ci pour vérifier que tous les paramètres sont corrects.

    > openstack endpoint show object-store

21.11.2 Configuration de la passerelle Ceph Object Gateway

21.11.2.1 Configuration des certificats SSL

Ceph Object Gateway interroge Keystone périodiquement pour obtenir la liste des jetons révoqués. Ces requêtes sont codées et signées. Il est également possible de configurer Keystone pour fournir des jetons signés automatiquement, qui sont aussi codés et signés. Vous devez configurer la passerelle afin qu'elle puisse décoder et vérifier ces messages signés. Par conséquent, les certificats OpenSSL que Keystone utilise pour créer les requêtes doivent être convertis au format « nss db » :

# mkdir /var/ceph/nss
# openssl x509 -in /etc/keystone/ssl/certs/ca.pem \
 -pubkey | certutil -d /var/ceph/nss -A -n ca -t "TCu,Cu,Tuw"
rootopenssl x509 -in /etc/keystone/ssl/certs/signing_cert.pem \
 -pubkey | certutil -A -d /var/ceph/nss -n signing_cert -t "P,P,P"

Pour permettre à Ceph Object Gateway d'interagir avec OpenStack Keystone, ce dernier peut utiliser un certificat SSL auto-signé. Installez le certificat SSL de Keystone sur le noeud exécutant Ceph Object Gateway ou définissez l'option rgw keystone verify ssl sur « false ». Définir rgw keystone verify ssl sur « false » signifie que la passerelle ne tentera pas de vérifier le certificat.

21.11.2.2 Configuration des options de la passerelle Object Gateway

Vous pouvez configurer l'intégration de Keystone à l'aide des options suivantes :

rgw keystone api version

Version de l'API Keystone. Les options valides sont 2 ou 3. La valeur par défaut est 2.

rgw keystone url

URL et numéro de port de l'API RESTful d'administration sur le serveur Keystone. Suit le modèle URL_SERVEUR:NUMÉRO_PORT.

rgw keystone admin token

Jeton ou secret partagé qui est configuré en interne dans Keystone pour les requêtes d'administration.

rgw keystone accepted roles

Rôles nécessaires pour répondre aux requêtes. Par défaut « Member, admin ».

rgw keystone accepted admin roles

Liste des rôles autorisant un utilisateur à obtenir des privilèges d'administration.

rgw keystone token cache size

Nombre maximal d'entrées dans le cache de jetons Keystone.

rgw keystone revocation interval

Nombre de secondes avant le contrôle de jetons révoqués. Par défaut, 15 * 60.

rgw keystone implicit tenants

Créez des utilisateurs dans leurs locataires du même nom. La valeur par défaut est « false ».

rgw s3 auth use keystone

Si ce paramètre est défini sur « false », Ceph Object Gateway authentifie les utilisateurs à l'aide de Keystone. La valeur par défaut est « false ».

nss db path

Chemin d'accès à la base de données NSS.

Il est également possible de configurer le locataire du service Keystone, le nom d'utilisateur et le mot de passe Keystone (pour la version 2.0 de l'API Identity OpenStack) d'une façon similaire aux services OpenStack. De cette façon, vous pouvez éviter de définir le secret partagé rgw keystone admin token dans le fichier de configuration, qui doit être désactivé dans les environnements de production. Les informations d'identification du locataire du service doivent disposer de privilèges d'administration. Pour plus de détails, reportez-vous à la documentation officielle OpenStack Keystone. Les options de configuration associées sont les suivantes :

rgw keystone admin user

Nom d'utilisateur de l'administrateur Keystone.

rgw keystone admin password

Mot de passe de l'administrateur Keystone.

rgw keystone admin tenant

Locataire de l'utilisateur administrateur Keystone version 2.0.

Un utilisateur Ceph Object Gateway est assigné à un locataire Keystone. Un utilisateur Keystone possède plusieurs rôles qui lui sont assignés, sur plusieurs locataires, le cas échéant. Lorsque la passerelle Ceph Object Gateway reçoit le ticket, elle examine le locataire et les rôles utilisateur qui lui sont attribués, et elle accepte ou rejette la demande en fonction de la valeur de l'option rgw keystone accepted roles.

Astuce
Astuce : assignation aux locataires OpenStack

Les locataires Swift sont assignés à l'utilisateur Object Gateway par défaut, mais peuvent l'être également aux locataires OpenStack grâce à l'option rgw keystone implicit tenants. Les conteneurs utiliseront alors l'espace de noms du locataire à la place de l'espace de noms global S3 associé par défaut à Object Gateway. Il est recommandé de choisir la méthode d'assignation au stade de la planification afin d'éviter toute confusion. En effet, l'affectation ultérieure de l'option concerne uniquement les requêtes plus récentes qui sont alors assignées sous un locataire, alors que les compartiments créés précédemment continuent à résider dans un espace de noms global.

Pour la version 3 de l'API Identity OpenStack, vous devez remplacer l'option rgw keystone admin tenant par :

rgw keystone admin domain

Domaine de l'utilisateur administrateur Keystone.

rgw keystone admin project

Projet de l'utilisateur administrateur Keystone.

21.12 Placement de réserve et classes de stockage

21.12.1 Affichage des cibles de placement

Les cibles de placement contrôlent les réserves associées à un compartiment particulier. La cible de placement d'un compartiment est sélectionnée lors de la création et ne peut pas être modifiée. Vous pouvez afficher son paramètre placement_rule en exécutant la commande suivante :

cephuser@adm > radosgw-admin bucket stats

La configuration du groupe de zones contient une liste de cibles de placement avec une cible initiale nommée « default-placement ». La configuration de la zone assigne ensuite le nom de la cible de placement de chaque groupe de zones à son stockage local. Ces informations de placement de zone incluent le nom « index_pool » pour l'index de compartiment, le nom « data_extra_pool » pour les métadonnées sur les téléchargements multiparties incomplets et un nom « data_pool » pour chaque classe de stockage.

21.12.2 Classes de stockage

Les classes de stockage aident à personnaliser le placement des données d'objets. Les règles de cycle de vie de compartiment S3 peuvent automatiser la transition des objets entre les classes de stockage.

Les classes de stockage sont définies en fonction des cibles de placement. Chaque cible de placement de groupe de zones répertorie ses classes de stockage disponibles avec une classe initiale nommée « STANDARD ». La configuration de zone fournit un nom de réserve « data_pool » pour chacune des classes de stockage du groupe de zones.

21.12.3 Configuration des groupes de zones et des zones

Utilisez la commande radosgw-admin sur les groupes de zones et les zones pour configurer leur placement. Vous pouvez interroger la configuration du placement de groupe de zones à l'aide de la commande suivante :

cephuser@adm > radosgw-admin zonegroup get
{
    "id": "ab01123f-e0df-4f29-9d71-b44888d67cd5",
    "name": "default",
    "api_name": "default",
    ...
    "placement_targets": [
        {
            "name": "default-placement",
            "tags": [],
            "storage_classes": [
                "STANDARD"
            ]
        }
    ],
    "default_placement": "default-placement",
    ...
}

Pour interroger la configuration du placement de zone, exécutez la commande suivante :

cephuser@adm > radosgw-admin zone get
{
    "id": "557cdcee-3aae-4e9e-85c7-2f86f5eddb1f",
    "name": "default",
    "domain_root": "default.rgw.meta:root",
    ...
    "placement_pools": [
        {
            "key": "default-placement",
            "val": {
                "index_pool": "default.rgw.buckets.index",
                "storage_classes": {
                    "STANDARD": {
                        "data_pool": "default.rgw.buckets.data"
                    }
                },
                "data_extra_pool": "default.rgw.buckets.non-ec",
                "index_type": 0
            }
        }
    ],
    ...
}
Note
Note : aucune configuration multisite précédente

Si vous n'avez effectué aucune configuration multisite auparavant, le système crée pour vous une zone et un groupe de zones « default » (par défaut). Les modifications apportées à cette zone/ce groupe de zones ne prennent effet qu'après avoir redémarré les passerelles Ceph Object Gateway. Si vous avez créé un domaine Kerberos pour plusieurs sites, les modifications de zone/groupe de zones entrent en vigueur une fois que vous les avez validées avec la commande radosgw-admin period update --commit.

21.12.3.1 Ajout d'une cible de placement

Pour créer une cible de placement nommée « temporary », commencez par l'ajouter au groupe de zones :

cephuser@adm > radosgw-admin zonegroup placement add \
      --rgw-zonegroup default \
      --placement-id temporary

Ensuite, fournissez les informations de placement de zone pour cette cible :

cephuser@adm > radosgw-admin zone placement add \
      --rgw-zone default \
      --placement-id temporary \
      --data-pool default.rgw.temporary.data \
      --index-pool default.rgw.temporary.index \
      --data-extra-pool default.rgw.temporary.non-ec

21.12.3.2 Ajout d'une classe de stockage

Pour ajouter une nouvelle classe de stockage nommée « COLD » à la cible « default-placement », commencez par l'ajouter au groupe de zones :

cephuser@adm > radosgw-admin zonegroup placement add \
      --rgw-zonegroup default \
      --placement-id default-placement \
      --storage-class COLD

Ensuite, fournissez les informations de placement de zone pour cette classe de stockage :

cephuser@adm > radosgw-admin zone placement add \
      --rgw-zone default \
      --placement-id default-placement \
      --storage-class COLD \
      --data-pool default.rgw.cold.data \
      --compression lz4

21.12.4 Personnalisation du placement

21.12.4.1 Modification du placement des groupes de zones par défaut

Par défaut, les nouveaux compartiments utilisent la cible default_placement du groupe de zones. Vous pouvez modifier ce paramètre de groupe de zones avec la commande suivante :

cephuser@adm > radosgw-admin zonegroup placement default \
      --rgw-zonegroup default \
      --placement-id new-placement

21.12.4.2 Modification du placement par défaut de l'utilisateur

Un utilisateur de Ceph Object Gateway peut remplacer la cible de placement par défaut du groupe de zones en définissant un champ default_placement non vide dans les informations utilisateur. De même, la valeur default_storage_class peut remplacer la classe de stockage STANDARD appliquée aux objets par défaut.

cephuser@adm > radosgw-admin user info --uid testid
{
    ...
    "default_placement": "",
    "default_storage_class": "",
    "placement_tags": [],
    ...
}

Si la cible de placement d'un groupe de zones contient des balises, les utilisateurs ne seront pas en mesure de créer des compartiments avec cette cible de placement, excepté si leurs informations utilisateur contiennent au moins une balise correspondante dans leur champ « placement_tags ». Cela peut être utile pour restreindre l'accès à certains types de stockage.

La commande radosgw-admin ne peut pas modifier ces champs directement, raison pour laquelle vous devez modifier manuellement le format JSON :

cephuser@adm > radosgw-admin metadata get user:USER-ID > user.json
> vi user.json     # edit the file as required
cephuser@adm > radosgw-admin metadata put user:USER-ID < user.json

21.12.4.3 Modification du placement du compartiment par défaut S3

Lors de la création d'un compartiment avec le protocole S3, une cible de placement peut être fournie dans le cadre de l'option LocationConstraint pour remplacer les cibles de placement par défaut de l'utilisateur et du groupe de zones.

Normalement, l'option LocationConstraint doit correspondre à la valeur api_name du groupe de zones :

<LocationConstraint>default</LocationConstraint>

Vous pouvez ajouter une cible de placement personnalisée à la valeur api_name en insérant à sa suite un caractère « : » suivi de la cible :

<LocationConstraint>default:new-placement</LocationConstraint>

21.12.4.4 Modification du placement du compartiment Swift

Lorsque vous créez un compartiment avec le protocole Swift, vous pouvez fournir une cible de placement dans l'option X-Storage-Policy de l'en-tête HTTP :

X-Storage-Policy: NEW-PLACEMENT

21.12.5 Utilisation des classes de stockage

Toutes les cibles de placement ont une classe de stockage STANDARD qui est appliquée par défaut aux nouveaux objets. Vous pouvez remplacer cette valeur par défaut avec son option default_storage_class.

Pour créer un objet dans une classe de stockage autre que celle par défaut, spécifiez le nom de cette classe de stockage dans un en-tête HTTP avec la requête. Le protocole S3 utilise l'en-tête X-Amz-Storage-Class, tandis que le protocole Swift utilise l'en-tête X-Object-Storage-Class.

Vous pouvez utiliser la fonction de gestion du cycle de vie des objets S3 (S3 Object Lifecycle Management) pour déplacer les données d'objets entre les classes de stockage à l'aide d'opérations Transition.

21.13 Passerelles Object Gateway multisites

Ceph prend en charge plusieurs options de configuration multisite pour la passerelle Ceph Object Gateway :

Multizone

Configuration composée d'un groupe de zones et de plusieurs zones, chacune d'elles présentant une ou plusieurs instances ceph-radosgw. Chaque zone est soutenue par sa propre grappe de stockage Ceph. Plusieurs zones au sein d'un groupe fournissent une reprise après sinistre pour le groupe de zones en cas de défaillance importante de l'une d'elles. Chaque zone est active et peut recevoir des opérations d'écriture. Outre la reprise après sinistre, plusieurs zones actives peuvent également servir de base aux réseaux de distribution de contenu.

Groupe multizone

Ceph Object Gateway prend en charge plusieurs groupes de zones, chacun d'entre eux comportant une ou plusieurs zones. Les objets stockés dans les zones d'un groupe de zones inclus dans le même domaine qu'un autre groupe de zones partagent un espace de noms d'objet global, ce qui permet de garantir l'unicité des ID d'objet dans les groupes de zones et les zones.

Note
Note

Il est important de noter que les groupes de zones synchronisent uniquement les métadonnées entre eux. Les données et les métadonnées sont répliquées entre les zones du groupe de zones. Aucune donnée ou métadonnée n'est partagée dans un domaine.

Plusieurs domaines

Ceph Object Gateway prend en charge la notion de domaines ; un espace de noms globalement unique. Plusieurs domaines sont pris en charge et peuvent englober un ou plusieurs groupes de zones.

Vous pouvez configurer chaque passerelle Object Gateway pour qu'elle fonctionne dans une configuration de zone active-active, ce qui permet d'écrire dans des zones non maîtres. La configuration multisite est stockée dans un conteneur appelé domaine. Le domaine stocke des groupes de zones, des zones et une période avec plusieurs époques pour le suivi des modifications apportées à la configuration. Les daemons rgw gèrent la synchronisation, ce qui élimine le besoin d'un agent de synchronisation distinct. Cette approche de la synchronisation permet à la passerelle Ceph Object Gateway de fonctionner avec une configuration active-active plutôt qu'active-passive.

21.13.1 Exigences et hypothèses

Une configuration multisite nécessite au moins deux grappes de stockage Ceph et au moins deux instances Ceph Object Gateway, une pour chaque grappe de stockage Ceph. Dans la configuration suivante, au moins deux grappes de stockage Ceph doivent être situées dans des emplacements géographiquement distincts. Cependant, la configuration peut fonctionner sur le même site. Par exemple, sous les noms rgw1 et rgw2.

Une configuration multisite nécessite un groupe de zones maître et une zone maître. Une zone maître est une source fiable pour toutes les opérations de métadonnées dans une grappe multisite. En outre, chaque groupe de zones nécessite une zone maître. Les groupes de zones peuvent avoir une ou plusieurs zones secondaires ou non maîtres. Dans ce guide, l'hôte rgw1 fait office de zone maître du groupe de zones maître et l'hôte rgw2 sert de zone secondaire du groupe de zones maître.

21.13.2 Configuration d'une zone maître

Toutes les passerelles d'une configuration multisite récupèrent leur configuration à partir d'un daemon ceph-radosgw sur un hôte au sein du groupe de zones maître et de la zone maître. Pour configurer vos passerelles dans une configuration multisite, sélectionnez une instance ceph-radosgw pour configurer le groupe de zones maître et la zone maître.

21.13.2.1 Création d'un domaine

Un domaine représente un espace de noms globalement unique constitué d'un ou de plusieurs groupes de zones contenant une ou plusieurs zones. Les zones comportent des compartiments qui, à leur tour, contiennent des objets. Un domaine permet à Ceph Object Gateway de prendre en charge plusieurs espaces de noms et leur configuration sur le même matériel. Un domaine contient la notion de périodes. Chaque période représente l'état de la configuration du groupe de zones et de la zone dans le temps. Chaque fois que vous apportez une modification à un groupe de zones ou à une zone, mettez à jour la période et validez-la. Par défaut, la passerelle Ceph Object Gateway ne crée pas de domaine pour des raisons de compatibilité avec les versions précédentes. Il est recommandé de créer des domaines pour les nouvelles grappes.

Créez un nouveau domaine appelé gold pour la configuration multisite en ouvrant une interface de ligne de commande sur un hôte identifié pour desservir le groupe de zones et la zone maîtres. Ensuite, exécutez la commande suivante :

cephuser@adm > radosgw-admin realm create --rgw-realm=gold --default

Si la grappe a un seul domaine, spécifiez l'indicateur --default. Si l'indicateur --default est spécifié, radosgw-admin utilise ce domaine par défaut. Si l'indicateur --default n'est pas spécifié, l'ajout de groupes de zones et de zones nécessite la spécification de l'indicateur --rgw-realm ou --realm-id pour identifier le domaine lors de l'ajout de groupes de zones et de zones.

Une fois le domaine créé, radosgw-admin renvoie la configuration du domaine :

{
  "id": "4a367026-bd8f-40ee-b486-8212482ddcd7",
  "name": "gold",
  "current_period": "09559832-67a4-4101-8b3f-10dfcd6b2707",
  "epoch": 1
}
Note
Note

Ceph génère un ID unique pour le domaine, ce qui permet de renommer un domaine, le cas échéant.

21.13.2.2 Création d'un groupe de zones maître

Un domaine doit compter au moins un groupe de zones maître. Créez un groupe de zones maître pour la configuration multisite en ouvrant une interface de ligne de commande sur un hôte identifié pour desservir le groupe de zones et la zone maîtres. Créez un groupe de zones maître appelé us en exécutant la commande suivante :

cephuser@adm > radosgw-admin zonegroup create --rgw-zonegroup=us \
--endpoints=http://rgw1:80 --master --default

Si le domaine ne comporte qu'un seul groupe de zones, spécifiez l'indicateur --default. Si l'indicateur --default est spécifié, radosgw-admin utilise ce groupe de zones par défaut lors de l'ajout de nouvelles zones. Si l'indicateur --default n'est pas spécifié, l'ajout de zones nécessite l'indicateur --rgw-zonegroup ou --zonegroup-id pour identifier le groupe de zones lors de l'ajout ou de la modification de zones.

Une fois le groupe de zones maître créé, radosgw-admin renvoie la configuration du groupe de zones. Par exemple :

{
 "id": "d4018b8d-8c0d-4072-8919-608726fa369e",
 "name": "us",
 "api_name": "us",
 "is_master": "true",
 "endpoints": [
     "http:\/\/rgw1:80"
 ],
 "hostnames": [],
 "hostnames_s3website": [],
 "master_zone": "",
 "zones": [],
 "placement_targets": [],
 "default_placement": "",
 "realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7"
}

21.13.2.3 Création d'une zone maître

Important
Important

Les zones doivent être créées sur un noeud Ceph Object Gateway qui se situe dans la zone.

Créez une zone maître pour la configuration multisite en ouvrant une interface de ligne de commande sur un hôte identifié pour desservir le groupe de zones et la zone maîtres. Exécutez la commande suivante :

cephuser@adm > radosgw-admin zone create --rgw-zonegroup=us --rgw-zone=us-east-1 \
--endpoints=http://rgw1:80 --access-key=SYSTEM_ACCESS_KEY --secret=SYSTEM_SECRET_KEY
Note
Note

Les options --access-key et --secret ne sont pas spécifiées dans l'exemple ci-dessus. Ces paramètres sont ajoutés à la zone lorsque l'utilisateur est créé dans la section suivante.

Une fois la zone maître créée, radosgw-admin renvoie la configuration de la zone. Par exemple :

  {
      "id": "56dfabbb-2f4e-4223-925e-de3c72de3866",
      "name": "us-east-1",
      "domain_root": "us-east-1.rgw.meta:root",
      "control_pool": "us-east-1.rgw.control",
      "gc_pool": "us-east-1.rgw.log:gc",
      "lc_pool": "us-east-1.rgw.log:lc",
      "log_pool": "us-east-1.rgw.log",
      "intent_log_pool": "us-east-1.rgw.log:intent",
      "usage_log_pool": "us-east-1.rgw.log:usage",
      "reshard_pool": "us-east-1.rgw.log:reshard",
      "user_keys_pool": "us-east-1.rgw.meta:users.keys",
      "user_email_pool": "us-east-1.rgw.meta:users.email",
      "user_swift_pool": "us-east-1.rgw.meta:users.swift",
      "user_uid_pool": "us-east-1.rgw.meta:users.uid",
      "otp_pool": "us-east-1.rgw.otp",
      "system_key": {
          "access_key": "1555b35654ad1656d804",
          "secret_key": "h7GhxuBLTrlhVUyxSPUKUV8r/2EI4ngqJxD7iBdBYLhwluN30JaT3Q=="
      },
      "placement_pools": [
          {
              "key": "us-east-1-placement",
              "val": {
                  "index_pool": "us-east-1.rgw.buckets.index",
                  "storage_classes": {
                      "STANDARD": {
                          "data_pool": "us-east-1.rgw.buckets.data"
                      }
                  },
                  "data_extra_pool": "us-east-1.rgw.buckets.non-ec",
                  "index_type": 0
              }
          }
      ],
      "metadata_heap": "",
      "realm_id": ""
  }

21.13.2.4 Suppression de la zone et du groupe par défaut

Important
Important

Les étapes suivantes supposent une configuration multisite utilisant des systèmes nouvellement installés qui ne stockent pas encore de données. Ne supprimez pas la zone par défaut et ses réserves si vous les utilisez déjà pour stocker des données, sinon les données seront supprimées et irrécupérables.

L'installation par défaut d'Object Gateway crée le groupe de zones par défaut appelé default. Supprimez la zone par défaut si elle existe. Veillez à la supprimer d'abord du groupe de zones par défaut.

cephuser@adm > radosgw-admin zonegroup delete --rgw-zonegroup=default

Supprimez les réserves par défaut de votre grappe de stockage Ceph si elles existent :

Important
Important

L'étape suivante suppose une configuration multisite utilisant des systèmes nouvellement installés qui ne contiennent actuellement pas de données. Ne supprimez pas le groupe de zones par défaut si vous l'utilisez déjà pour stocker des données.

cephuser@adm > ceph osd pool rm default.rgw.control default.rgw.control --yes-i-really-really-mean-it
cephuser@adm > ceph osd pool rm default.rgw.data.root default.rgw.data.root --yes-i-really-really-mean-it
cephuser@adm > ceph osd pool rm default.rgw.gc default.rgw.gc --yes-i-really-really-mean-it
cephuser@adm > ceph osd pool rm default.rgw.log default.rgw.log --yes-i-really-really-mean-it
cephuser@adm > ceph osd pool rm default.rgw.meta default.rgw.meta --yes-i-really-really-mean-it
Avertissement
Avertissement

La suppression du groupe de zones par défaut entraîne celle de l'utilisateur système. Si vos clés d'administrateur ne sont pas propagées, la fonctionnalité de gestion d'Object Gateway de Ceph Dashboard ne fonctionnera pas. Passez à la section suivante pour recréer votre utilisateur système si vous poursuivez cette étape.

21.13.2.5 Création d'utilisateurs système

Les daemons ceph-radosgw doivent s'authentifier avant de récupérer les informations de domaine et de période. Dans la zone maître, créez un utilisateur système pour simplifier l'authentification entre les daemons :

cephuser@adm > radosgw-admin user create --uid=zone.user \
--display-name="Zone User" --access-key=SYSTEM_ACCESS_KEY \
--secret=SYSTEM_SECRET_KEY --system

Notez les paramètres access_key et secret_key car les zones secondaires exigent l'authentification auprès de la zone maître.

Ajoutez l'utilisateur système à la zone maître :

cephuser@adm > radosgw-admin zone modify --rgw-zone=us-east-1 \
--access-key=ACCESS-KEY --secret=SECRET

Mettez à jour la période pour que les modifications prennent effet :

cephuser@adm > radosgw-admin period update --commit

21.13.2.6 Mise à jour de la période

Après avoir mis à jour la configuration de la zone maître, mettez à jour la période :

cephuser@adm > radosgw-admin period update --commit

Une fois la période mise à jour, radosgw-admin renvoie la configuration de la période. Par exemple :

{
  "id": "09559832-67a4-4101-8b3f-10dfcd6b2707", "epoch": 1, "predecessor_uuid": "", "sync_status": [], "period_map":
  {
    "id": "09559832-67a4-4101-8b3f-10dfcd6b2707", "zonegroups": [], "short_zone_ids": []
  }, "master_zonegroup": "", "master_zone": "", "period_config":
  {
     "bucket_quota": {
     "enabled": false, "max_size_kb": -1, "max_objects": -1
     }, "user_quota": {
       "enabled": false, "max_size_kb": -1, "max_objects": -1
     }
  }, "realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7", "realm_name": "gold", "realm_epoch": 1
}
Note
Note

La mise à jour de la période modifie l'époque et garantit que les autres zones reçoivent la configuration mise à jour.

21.13.2.7 Démarrage de la passerelle Gateway

Sur l'hôte Object Gateway, démarrez et activez le service Ceph Object Gateway. Pour identifier le FSID unique de la grappe, exécutez ceph fsid. Pour identifier le nom du daemon Object Gateway, exécutez ceph orch ps --hostname HOSTNAME.

cephuser@ogw > systemctl start ceph-FSID@DAEMON_NAME
cephuser@ogw > systemctl enable ceph-FSID@DAEMON_NAME

21.13.3 Configuration des zones secondaires

Les zones d'un groupe de zones répliquent toutes les données pour garantir que chaque zone possède les mêmes données. Lors de la création de la zone secondaire, exécutez toutes les opérations suivantes sur un hôte identifié pour desservir cette dernière.

Note
Note

Pour ajouter une troisième zone, suivez les mêmes procédures que pour ajouter la zone secondaire. Utilisez un nom de zone différent.

Important
Important

Vous devez exécuter les opérations de métadonnées, telles que la création d'utilisateurs, sur un hôte de la zone maître. La zone maître et la zone secondaire peuvent recevoir des opérations de compartiment, mais la zone secondaire redirige les opérations de compartiment vers la zone maître. Si la zone maître est arrêtée, les opérations de compartiment échouent.

21.13.3.1 Extraction du domaine

À l'aide du chemin URL, de la clé d'accès et du secret de la zone maître dans le groupe de zones maître, importez la configuration du domaine vers l'hôte. Pour extraire un domaine autre que celui par défaut, spécifiez le domaine à l'aide des options de configuration --rgw-realm ou --realm-id.

cephuser@adm > radosgw-admin realm pull --url=url-to-master-zone-gateway --access-key=access-key --secret=secret
Note
Note

L'extraction du domaine récupère également la configuration de la période en cours de l'hôte distant et en fait également la période en cours sur cet hôte.

Si ce domaine est le domaine par défaut ou le seul domaine, définissez-le comme par défaut.

cephuser@adm > radosgw-admin realm default --rgw-realm=REALM-NAME

21.13.3.2 Création d'une zone secondaire

Créez une zone secondaire pour la configuration multisite en ouvrant une interface de ligne de commande sur un hôte identifié pour desservir la zone secondaire. Spécifiez l'ID du groupe de zones, le nom de la nouvelle zone et un noeud d'extrémité pour cette dernière. N'utilisez pas l'indicateur --master. Toutes les zones s'exécutent dans une configuration active-active par défaut. Si la zone secondaire ne doit pas accepter les opérations d'écriture, spécifiez l'indicateur --read-only pour créer une configuration active-passive entre la zone maître et la zone secondaire. En outre, fournissez la clé d'accès (access_key) et la clé secrète (secret_key) de l'utilisateur système généré stockées dans la zone maître du groupe de zones maître. Exécutez la commande suivante :

cephuser@adm > radosgw-admin zone create --rgw-zonegroup=ZONE-GROUP-NAME\
 --rgw-zone=ZONE-NAME --endpoints=URL \
 --access-key=SYSTEM-KEY --secret=SECRET\
 --endpoints=http://FQDN:80 \
 [--read-only]

Par exemple :

cephuser@adm > radosgw-admin zone create --rgw-zonegroup=us --endpoints=http://rgw2:80 \
--rgw-zone=us-east-2 --access-key=SYSTEM_ACCESS_KEY --secret=SYSTEM_SECRET_KEY
{
  "id": "950c1a43-6836-41a2-a161-64777e07e8b8",
  "name": "us-east-2",
  "domain_root": "us-east-2.rgw.data.root",
  "control_pool": "us-east-2.rgw.control",
  "gc_pool": "us-east-2.rgw.gc",
  "log_pool": "us-east-2.rgw.log",
  "intent_log_pool": "us-east-2.rgw.intent-log",
  "usage_log_pool": "us-east-2.rgw.usage",
  "user_keys_pool": "us-east-2.rgw.users.keys",
  "user_email_pool": "us-east-2.rgw.users.email",
  "user_swift_pool": "us-east-2.rgw.users.swift",
  "user_uid_pool": "us-east-2.rgw.users.uid",
  "system_key": {
      "access_key": "1555b35654ad1656d804",
      "secret_key": "h7GhxuBLTrlhVUyxSPUKUV8r\/2EI4ngqJxD7iBdBYLhwluN30JaT3Q=="
  },
  "placement_pools": [
      {
          "key": "default-placement",
          "val": {
              "index_pool": "us-east-2.rgw.buckets.index",
              "data_pool": "us-east-2.rgw.buckets.data",
              "data_extra_pool": "us-east-2.rgw.buckets.non-ec",
              "index_type": 0
          }
      }
  ],
  "metadata_heap": "us-east-2.rgw.meta",
  "realm_id": "815d74c2-80d6-4e63-8cfc-232037f7ff5c"
}
Important
Important

Les étapes suivantes supposent une configuration multisite utilisant des systèmes nouvellement installés qui ne stockent pas encore de données. Ne supprimez pas la zone par défaut et ses réserves si vous les utilisez déjà pour stocker des données, sinon les données seront perdues et irrécupérables.

Supprimez la zone par défaut si nécessaire :

cephuser@adm > radosgw-admin zone delete --rgw-zone=default

Supprimez les réserves par défaut de votre grappe de stockage Ceph si nécessaire :

cephuser@adm > ceph osd pool rm default.rgw.control default.rgw.control --yes-i-really-really-mean-it
cephuser@adm > ceph osd pool rm default.rgw.data.root default.rgw.data.root --yes-i-really-really-mean-it
cephuser@adm > ceph osd pool rm default.rgw.gc default.rgw.gc --yes-i-really-really-mean-it
cephuser@adm > ceph osd pool rm default.rgw.log default.rgw.log --yes-i-really-really-mean-it
cephuser@adm > ceph osd pool rm default.rgw.users.uid default.rgw.users.uid --yes-i-really-really-mean-it

21.13.3.3 Mise à jour du fichier de configuration Ceph

Mettez à jour le fichier de configuration Ceph sur les hôtes de la zone secondaire en ajoutant l'option de configuration rgw_zone et le nom de la zone secondaire à l'entrée de l'instance.

Pour ce faire, exécutez la commande suivante :

cephuser@adm > ceph config set SERVICE_NAME rgw_zone us-west

21.13.3.4 Mise à jour de la période

Après avoir mis à jour la configuration de la zone maître, mettez à jour la période :

cephuser@adm > radosgw-admin period update --commit
{
  "id": "b5e4d3ec-2a62-4746-b479-4b2bc14b27d1",
  "epoch": 2,
  "predecessor_uuid": "09559832-67a4-4101-8b3f-10dfcd6b2707",
  "sync_status": [ "[...]"
  ],
  "period_map": {
      "id": "b5e4d3ec-2a62-4746-b479-4b2bc14b27d1",
      "zonegroups": [
          {
              "id": "d4018b8d-8c0d-4072-8919-608726fa369e",
              "name": "us",
              "api_name": "us",
              "is_master": "true",
              "endpoints": [
                  "http:\/\/rgw1:80"
              ],
              "hostnames": [],
              "hostnames_s3website": [],
              "master_zone": "83859a9a-9901-4f00-aa6d-285c777e10f0",
              "zones": [
                  {
                      "id": "83859a9a-9901-4f00-aa6d-285c777e10f0",
                      "name": "us-east-1",
                      "endpoints": [
                          "http:\/\/rgw1:80"
                      ],
                      "log_meta": "true",
                      "log_data": "false",
                      "bucket_index_max_shards": 0,
                      "read_only": "false"
                  },
                  {
                      "id": "950c1a43-6836-41a2-a161-64777e07e8b8",
                      "name": "us-east-2",
                      "endpoints": [
                          "http:\/\/rgw2:80"
                      ],
                      "log_meta": "false",
                      "log_data": "true",
                      "bucket_index_max_shards": 0,
                      "read_only": "false"
                  }

              ],
              "placement_targets": [
                  {
                      "name": "default-placement",
                      "tags": []
                  }
              ],
              "default_placement": "default-placement",
              "realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7"
          }
      ],
      "short_zone_ids": [
          {
              "key": "83859a9a-9901-4f00-aa6d-285c777e10f0",
              "val": 630926044
          },
          {
              "key": "950c1a43-6836-41a2-a161-64777e07e8b8",
              "val": 4276257543
          }

      ]
  },
  "master_zonegroup": "d4018b8d-8c0d-4072-8919-608726fa369e",
  "master_zone": "83859a9a-9901-4f00-aa6d-285c777e10f0",
  "period_config": {
      "bucket_quota": {
          "enabled": false,
          "max_size_kb": -1,
          "max_objects": -1
      },
      "user_quota": {
          "enabled": false,
          "max_size_kb": -1,
          "max_objects": -1
      }
  },
  "realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7",
  "realm_name": "gold",
  "realm_epoch": 2
}
Note
Note

La mise à jour de la période modifie l'époque et garantit que les autres zones reçoivent la configuration mise à jour.

21.13.3.5 Démarrage de la passerelle Object Gateway

Sur l'hôte Object Gateway, démarrez et activez le service Ceph Object Gateway :

cephuser@adm > ceph orch start rgw.us-east-2

21.13.3.6 Vérification de l'état de la synchronisation

Lorsque la zone secondaire est opérationnelle, vérifiez l'état de la synchronisation. La synchronisation copie les utilisateurs et les compartiments créés dans la zone maître vers la zone secondaire.

cephuser@adm > radosgw-admin sync status

La sortie indique l'état des opérations de synchronisation. Par exemple :

realm f3239bc5-e1a8-4206-a81d-e1576480804d (gold)
    zonegroup c50dbb7e-d9ce-47cc-a8bb-97d9b399d388 (us)
         zone 4c453b70-4a16-4ce8-8185-1893b05d346e (us-west)
metadata sync syncing
              full sync: 0/64 shards
              metadata is caught up with master
              incremental sync: 64/64 shards
    data sync source: 1ee9da3e-114d-4ae3-a8a4-056e8a17f532 (us-east)
                      syncing
                      full sync: 0/128 shards
                      incremental sync: 128/128 shards
                      data is caught up with source
Note
Note

Les zones secondaires acceptent les opérations de compartiment ; toutefois, elles les redirigent vers la zone maître, puis se synchronisent avec la zone maître pour recevoir le résultat des opérations de compartiment. Si la zone maître est arrêtée, les opérations de compartiment exécutées sur la zone secondaire échouent, mais les opérations sur les objets réussissent.

21.13.3.7 Vérification d'un objet

Par défaut, les objets ne sont pas revérifiés si la synchronisation d'un objet réussit. Pour activer la vérification, définissez l'option rgw_sync_obj_etag_verify sur true. Après l'activation, les objets facultatifs seront synchronisés. Une somme de contrôle MD5 supplémentaire vérifie qu'elle est calculée sur la source et la destination. Cela permet de garantir l'intégrité des objets récupérés à partir d'un serveur distant via HTTP, y compris la synchronisation multisite. Cette option peut affecter les performances des RGW, car davantage de calculs sont nécessaires.

21.13.4 Maintenance générale d'Object Gateway

21.13.4.1 Vérification de l'état de la synchronisation

Pour obtenir des informations sur l'état de réplication d'une zone, exécutez la commande suivante :

cephuser@adm > radosgw-admin sync status
        realm b3bc1c37-9c44-4b89-a03b-04c269bea5da (gold)
    zonegroup f54f9b22-b4b6-4a0e-9211-fa6ac1693f49 (us)
         zone adce11c9-b8ed-4a90-8bc5-3fc029ff0816 (us-west)
        metadata sync syncing
              full sync: 0/64 shards
              incremental sync: 64/64 shards
              metadata is behind on 1 shards
              oldest incremental change not applied: 2017-03-22 10:20:00.0.881361s
data sync source: 341c2d81-4574-4d08-ab0f-5a2a7b168028 (us-east)
                  syncing
                  full sync: 0/128 shards
                  incremental sync: 128/128 shards
                  data is caught up with source
          source: 3b5d1a3f-3f27-4e4a-8f34-6072d4bb1275 (us-3)
                  syncing
                  full sync: 0/128 shards
                  incremental sync: 128/128 shards
                  data is caught up with source

La sortie peut différer selon l'état de la synchronisation. Les partitions sont décrites comme deux types différents lors de la synchronisation :

Partitions obsolètes

Les partitions obsolètes sont des partitions qui nécessitent une synchronisation complète des données et des partitions nécessitant une synchronisation incrémentielle des données, car elles ne sont pas à jour.

Partitions de récupération

Les partitions de récupération sont des partitions qui ont rencontré une erreur lors de la synchronisation et signalées comme devant effectuer une nouvelle tentative. L'erreur provient principalement de problèmes mineurs tels que l'échec du verrouillage d'un compartiment. Le problème se résout généralement spontanément.

21.13.4.2 Vérification des journaux

Uniquement dans le cadre d'une configuration multisite, vous pouvez vérifier le journal de métadonnées (mdlog), le journal d'index du compartiment (bilog) ainsi que le journal de données (datalog). Vous pouvez les lister et les découper. Toutefois, ce n'est généralement pas nécessaire, car, par défaut, l'option rgw_sync_log_trim_interval est définie sur 20 minutes. Si l'option n'est pas définie manuellement sur 0, vous ne devrez le découper à aucun moment, au risque d'entraîner des effets indésirables.

21.13.4.3 Modification de la zone maître des métadonnées

Important
Important

Faites preuve de précaution lorsque vous modifiez la zone maître des métadonnées. Si une zone n'a pas terminé la synchronisation des métadonnées depuis la zone maître actuelle, elle ne peut pas desservir les entrées restantes une fois promue au rang de maître et ces modifications sont perdues. De ce fait, nous vous recommandons d'attendre que l'état de synchronisation radosgw-admin d'une zone indique que la synchronisation des métadonnées est terminée avant de la promouvoir au rang de maître. De même, si les modifications apportées aux métadonnées sont traitées par la zone maître actuelle alors qu'une autre zone est promue au rang de maître, ces modifications risquent d'être perdues. Pour éviter cela, nous vous recommandons de fermer toutes les instances d'Object Gateway sur l'ancienne zone maître. Une fois qu'une autre zone a été promue, sa nouvelle période peut être récupérée à l'aide de l'extraction de période radosgw-admin et la ou les passerelles peuvent être redémarrées.

Pour promouvoir une zone (par exemple, la zone us-west dans le groupe de zones us) en tant que maître de métadonnées, exécutez les commandes suivantes sur cette zone :

cephuser@ogw > radosgw-admin zone modify --rgw-zone=us-west --master
cephuser@ogw > radosgw-admin zonegroup modify --rgw-zonegroup=us --master
cephuser@ogw > radosgw-admin period update --commit

Cela génère une nouvelle période et les instances d'Object Gateway de la zone us-west envoient cette période à d'autres zones.

21.13.5 Basculement et reprise après sinistre

Si la zone maître échoue, basculez vers la zone secondaire pour la reprise après sinistre.

  1. Faites de la zone secondaire la zone maître et la zone par défaut. Par exemple :

    cephuser@adm > radosgw-admin zone modify --rgw-zone=ZONE-NAME --master --default

    Par défaut, Ceph Object Gateway s'exécute dans une configuration active-active. Si la grappe a été configurée pour s'exécuter dans une configuration active-passive, la zone secondaire est une zone en lecture seule. Retirez l'état --read-only pour autoriser la zone à recevoir les opérations d'écriture. Par exemple :

    cephuser@adm > radosgw-admin zone modify --rgw-zone=ZONE-NAME --master --default \
                                                       --read-only=false
  2. Mettez à jour la période pour que les modifications prennent effet :

    cephuser@adm > radosgw-admin period update --commit
  3. Redémarrez la passerelle Ceph Object Gateway :

    cephuser@adm > ceph orch restart rgw

En cas de reprise de la zone maître précédente, annulez l'opération.

  1. Depuis la zone récupérée, extrayez la dernière configuration de domaine de la zone maître actuelle.

    cephuser@adm > radosgw-admin realm pull --url=URL-TO-MASTER-ZONE-GATEWAY \
                               --access-key=ACCESS-KEY --secret=SECRET
  2. Faites de la zone récupérée la zone maître et la zone par défaut:

    cephuser@adm > radosgw-admin zone modify --rgw-zone=ZONE-NAME --master --default
  3. Mettez à jour la période pour que les modifications prennent effet :

    cephuser@adm > radosgw-admin period update --commit
  4. Redémarrez la passerelle Ceph Object Gateway dans la zone récupérée :

    cephuser@adm > ceph orch restart rgw@rgw
  5. Si la zone secondaire doit être une configuration en lecture seule, mettez à jour la zone secondaire :

    cephuser@adm > radosgw-admin zone modify --rgw-zone=ZONE-NAME --read-only
  6. Mettez à jour la période pour que les modifications prennent effet :

    cephuser@adm > radosgw-admin period update --commit
  7. Enfin, redémarrez la passerelle Ceph Object Gateway dans la zone secondaire :

    cephuser@adm > ceph orch restart@rgw