21 Ceph Object Gateway #

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 ».

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

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 :

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"}],
 [...]

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 :

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.

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

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

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

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.

É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.

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.

{
  "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,
}

{
  "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 :

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
}

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

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.

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 : 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.

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 :

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.

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 :

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.

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 :

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.

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

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 :

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 : 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 :

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

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

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

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

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>

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

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

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

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"
}

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

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": ""
  }

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

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

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.

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

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

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

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

À 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

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

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

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

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

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

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

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

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

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

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.

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.

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 :

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.

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.