21 Ceph Object Gateway #

Für den Zugriff auf die S3-Schnittstelle benötigen Sie einen REST Client. S3cmd ist ein Kommandozeilen-S3 Client. Sie finden ihn im OpenSUSE Build Service. Das Repository enthält Versionen für SUSE Linux Enterprise und für openSUSE-basierte Distributionen.

Wenn Sie Ihren Zugriff auf die S3-Schnittstelle testen möchten, können Sie ein kleines Python-Skript schreiben. Das Skript stellt eine Verbindung zum Object Gateway her, erstellt einen neuen Bucket und listet alle Buckets auf. Die Werte für aws_access_key_id und aws_secret_access_key werden den Werten für access_key und secret_key entnommen, die vom Kommando radosgw_admin in Abschnitt 21.5.2.1, „Hinzufügen von S3- und Swift-Benutzern“ zurückgegeben wurden.

Für den Zugriff auf das Object Gateway über die Swift-Schnittstelle benötigen Sie den swift-Kommandozeilen-Client. In der entsprechenden Handbuchseite man 1 swift erfahren Sie mehr über dessen Kommandozeilenoptionen.

Das Paket befindet sich im Modul „Public Cloud“ für SUSE Linux Enterprise 12 ab SP3 und SUSE Linux Enterprise 15. Vor der Installation des Pakets müssen Sie das Modul aktivieren und das Software Repository aktualisieren:

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

oder

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

Führen Sie zur Installation des swift-Pakets folgendes Kommando aus:

root # zypper in python-swiftclient

Beim Swift-Zugang wird die folgende Syntax verwendet:

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

Ersetzen Sie IP_ADDRESS durch die IP-Adresse des Gateway Servers und SWIFT_SECRET_KEY durch dessen Wert der Ausgabe des Kommandos radosgw-admin key create, das für den swift-Benutzer in Abschnitt 21.5.2.1, „Hinzufügen von S3- und Swift-Benutzern“ ausgeführt wurde.

Beispiel:

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

Die Ausgabe ist:

my-new-bucket

Sie müssen einen Benutzer, einen Zugriffsschlüssel und ein Geheimnis erstellen, um Endbenutzer für die Interaktion mit dem Gateway zu aktivieren. Es gibt zwei Arten von Benutzern: einen Benutzer und einen Unterbenutzer. Benutzer werden für die Interaktion mit der S3-Schnittstelle verwendet, während Unterbenutzer Benutzer der Swift-Schnittstelle sind. Jeder Unterbenutzer ist einem Benutzer zugeordnet.

Führen Sie zum Erstellen eines Swift-Benutzers folgende Schritte aus:

Beim Zugriff auf das Object Gateway über die S3-Schnittstelle müssen Sie einen S3-Benutzer erstellen, indem Sie folgendes Kommando ausführen:

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

Beispiel:

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

Das Kommando erstellt auch den Zugriff und geheimen Schlüssel des Benutzers. Überprüfen Sie dessen Ausgabe nach den Schlüsselwörtern access_key und secret_key und deren Werte:

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

Das Verfahren zum Löschen von Benutzern ist bei S3- und Swift-Benutzern in etwa gleich. Im Fall von Swift-Benutzern müssen Sie jedoch möglicherweise den Benutzer einschließlich dessen Unterbenutzer löschen.

Geben Sie zum Entfernen eines S3- oder Swift-Benutzers (einschließlich aller Unterbenutzer) user rm und die Benutzer-ID im folgenden Kommando an:

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

Geben Sie zum Entfernen eines Unterbenutzers subuser rm und die Unterbenutzer-ID an.

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

Die folgenden Optionen stehen Ihnen zur Verfügung:

Tipp: Entfernen eines Unterbenutzers

Wenn Sie einen Unterbenutzer entfernen, dann entfernen Sie auch den Zugriff auf die Swift-Schnittstelle. Der Benutzer bleibt im System.

Die Parameter access_key und secret_key kennzeichnen den Object-Gateway-Benutzer für den Zugriff auf das Gateway. Das Ändern der bestehenden Benutzerschlüssel ist identisch mit dem Erstellen neuer Schlüssel, weil die alten Schlüssel überschrieben werden.

Führen Sie für S3-Benutzer folgendes Kommando aus:

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

Führen Sie für Swift-Benutzer folgendes Kommando aus:

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

Mit dem Ceph Object Gateway können Sie Kontingente für Benutzer und Buckets für Benutzer festlegen. Kontingente umfassen die maximale Anzahl der Objekte in einem Bucket sowie die maximale Speichergröße in Megabyte.

Vor dem Aktivieren einer Benutzerquote müssen Sie zunächst deren Parameter festlegen:

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

Sobald Sie eine Benutzerquote festgelegt haben, können Sie sie aktivieren:

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

So deaktivieren Sie ein Kontingent:

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

So listen Sie Kontingenteinstellungen auf:

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

So aktualisieren Sie die Kontingentstatistik:

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

Nehmen wir eine einfache Konfiguration für mehrere Standorte an, wie in Abschnitt 21.13, „Object Gateways an mehreren Standorten“ beschrieben. Sie besteht aus zwei Zonen: us-east und us-west. Nun fügen wir eine dritte Zone us-east-es hinzu. Diese Zone verarbeitet nur die Metadaten der anderen Standorte. Diese Zone kann sich im selben Ceph-Cluster befinden wie us-east oder auch in einer anderen Zone. Diese Zone würde nur die Metadaten aus anderen Zonen nutzen. Object Gateways in dieser Zone verarbeiten Endbenutzeranforderungen nicht direkt.

Da der ElasticSearch Cluster nun Objekt-Metadaten speichert, ist es wichtig, dass der ElasticSearch-Endpunkt nicht öffentlich gemacht wird und nur für Cluster-Administratoren zugänglich ist. Die Anzeige von Metadaten-Abfragen für den Endbenutzer selbst ist problematisch, weil der Benutzer nur seine Metadaten abfragen soll und nicht die Metadaten anderer Benutzer. Der ElasticSearch Cluster müsste Benutzer ähnlich wie RGW authentifizieren, was ein Problem darstellt.

Ab Luminous kann RGW in der Metadaten-Masterzone nun die Endbenutzeranforderungen verarbeiten. Dadurch ist es möglich, dass der ElasticSearch-Endpunkt nicht öffentlich zugänglich ist und gleichzeitig das Authentifizierungs- und Autorisierungsproblem gelöst ist, weil RGW selbst die Endbenutzeranforderungen authentifizieren kann. Zu diesem Zweck führt RGW eine neue Abfrage in den Bucket APIs ein, die ElasticSearch-Anforderungen verarbeiten können. Diese Anforderungen müssen an die Metadaten-Masterzone gesendet werden.

Die folgenden Beispiele zeigen eine Trivial- und eine Nicht-Trivial-Konfiguration für das Cloud-Synchronisierungsmodul. Hierbei ist zu beachten, dass die Trivial-Konfiguration mit der Nicht-Trivial-Konfiguration in Konflikt kommen kann.

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

Erläuterung der Konfigurationsbegriffe:

Das Cloud-Synchronisierungsmodul arbeitet lediglich mit Back-Ends zusammen, die mit AWS S3 kompatibel sind. Dieses Verhalten kann beim Zugriff auf S3-Cloud-Services mithilfe bestimmter konfigurierbarer Elemente beeinflusst werden:

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

Tipp: Weitere Informationen

Weitere Informationen zum Konfigurieren von Gateways für mehrere Standorte finden Sie in Abschnitt 21.13, „Object Gateways an mehreren Standorten“.

Weitere Informationen zum Konfigurieren von Synchronisierungsmodulen finden Sie in Abschnitt 21.8, „Synchronisierungsmodule“.

Zur Nutzung des Archiv-Synchronisierungsmoduls erstellen Sie eine neue Zone mit dem Schichttyp 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

Beispiel eines Teilfilters:

"objectclass=inetorgperson"

Das Object Gateway generiert den Suchfilter wie üblich mit dem Benutzernamen aus dem Token und dem Wert von rgw_ldap_dnattr. Der konstruierte Filter wird dann mit dem Teilfilter aus dem Attribut rgw_search_filter kombiniert. Abhängig vom Benutzernamen und den Einstellungen sieht der finale Suchfilter möglicherweise folgendermaßen aus:

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

In diesem Fall erhält der Benutzer „hari“ nur dann Zugriff, wenn er im LDAP-Verzeichnis gefunden wird, über die Objektklasse „inetorgperson“ verfügt und ein gültiges Passwort angegeben hat.

Ein vollständiger Filter muss einen Token USERNAME enthalten, der beim Authentifizierungsversuch durch den Benutzernamen ersetzt wird. Der Parameter rgw_ldap_dnattr wird in diesem Fall nicht mehr verwendet. Verwenden Sie beispielsweise folgenden Filter, um die gültigen Benutzer auf eine bestimmte Gruppe zu beschränken:

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

Anmerkung: Attribut memberOf

Für die Verwendung des Attributs memberOf in LDAP-Suchen ist die serverseitige Unterstützung Ihrer spezifischen LDAP Server-Implementierung erforderlich.

Seit SUSE Enterprise Storage 5 unterstützen wir das Online-Bucket-Resharding. Es erkennt, wenn die Anzahl der Objekte pro Bucket einen bestimmten Schwellwert erreicht, und erhöht automatisch die Anzahl der vom Bucket-Index verwendeten Shards. Dieser Vorgang reduziert die Anzahl der Einträge in jedem Bucket-Index-Shard.

Der Erkennungsvorgang wird in folgenden Fällen ausgeführt:

Ein Bucket, für den ein Resharding durchgeführt werden muss, wird zur Warteschlange reshard_log hinzugefügt und das Resharding wird für später geplant. Die Reshard-Threads werden im Hintergrund ausgeführt und führen das geplante Resharding für die einzelnen Buckets nacheinander durch.

Das in Abschnitt 21.10.1.1, „Dynamisches Resharding“ erwähnte dynamische Resharding wird nur für einfache Object-Gateway-Konfigurationen unterstützt. Bei Konfigurationen mit mehreren Standorten müssen Sie das in diesem Abschnitt erläuterte manuelle Resharding verwenden.

Führen Sie für ein manuelles Offline-Resharding des Bucket-Index folgendes Kommando aus:

cephuser@adm > radosgw-admin bucket reshard

Das Kommando bucket reshard führt Folgendes aus:

Tipp

Bei der Wahl der Anzahl der Shards dürfen Sie nicht mehr als 100.000 Einträge pro Shard vorsehen. Bucket-Index-Shards, die Primzahlen sind, funktionieren tendenziell besser bei der gleichmäßigen Verteilung von Bucket-Indexeinträgen auf die Shards. Zum Beispiel sind 503 Bucket-Index-Shards besser als 500, da erstere Zahl eine Primzahl ist.

Konfigurationen für mehrere Standorte können einen anderen Index-Pool zum Verwalten von Failover haben. Legen Sie zum Konfigurieren einer konsistenten Anzahl von Shards für Zonen in einer Zonengruppe die Option bucket_index_max_shards in der Konfiguration der Zonengruppe fest:

Das Ceph Object Gateway fragt Keystone regelmäßig nach einer Liste der entzogenen Token ab. Diese Anforderungen sind verschlüsselt und signiert. Keystone kann ebenfalls konfiguriert werden, um eigensignierte Token bereitzustellen, die ebenfalls verschlüsselt und signiert sind. Sie müssen das Gateway so konfigurieren, dass es diese signierten Nachrichten entschlüsseln und verifizieren kann. Daher müssen die OpenSSL-Zertifikate, die Keystone zum Erstellen der Anforderungen verwendet, in das Format „nss db“ konvertiert werden:

root # mkdir /var/ceph/nss
root # 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"

OpenStack Keystone kann über ein eigensigniertes SSL-Zertifikat mit dem Ceph Object Gateway interagieren. Installieren Sie entweder das SSL-Zertifikat von Keystone im Knoten, auf dem das Ceph Object Gateway ausgeführt wird, oder legen Sie alternativ den Wert der Option rgw keystone verify ssl auf „false“ fest. Wenn Sie rgw keystone verify ssl auf „false“ festlegen, versucht das Gateway nicht, das Zertifikat zu verifizieren.

Die Keystone-Integration wird mit folgenden Optionen konfiguriert:

Es ist auch möglich, den Keystone Service-Mandanten, den Benutzer und das Passwort für Keystone (für Version 2.0 der OpenStack Identity API) auf ähnliche Weise zu konfigurieren wie OpenStack Services normalerweise konfiguriert werden. Dadurch vermeiden Sie, das gemeinsame Geheimnis rgw keystone admin token in der Konfigurationsdatei festzulegen, das in Produktionsumgebungen deaktiviert sein sollte. Die Anmeldedaten des Service-Mandanten sollten Administratorrechte enthalten. Weitere Details finden Sie in der offiziellen OpenStack Keystone-Dokumentation. Die entsprechenden Konfigurationsoptionen sind wie folgt:

Ein Ceph Object-Gateway-Benutzer wird einem Keystone-Mandanten zugeordnet. Einem Keystone-Benutzer sind verschiedene Rollen zugewiesen, möglicherweise zu mehr als einem Mandanten. Wenn das Ceph Object Gateway das Ticket erhält, sieht es sich den Mandanten und die Benutzerrollen an, die diesem Ticket zugewiesen sind, und akzeptiert die Anforderung oder weist sie zurück, je nach Einstellung der Option rgw keystone accepted roles.

Tipp: Zuordnung zu OpenStack-Mandanten

Obgleich Swift-Mandanten standardmäßig zum Object-Gateway-Benutzer zugeordnet werden, ist mit der Option rgw keystone implicit tenants auch deren Zuordnung zu OpenStack-Mandanten möglich. Dadurch verwenden Container den Mandanten-Namespace statt des S3-ähnlichen globalen Namespace, das standardmäßig für Object Gateway verwendet wird. Wir empfehlen, die Zuordnungsmethode in der Planungsphase festzulegen, um Verwirrung zu vermeiden. Wenn eine Option später gewechselt wird, betrifft dies nur neuere Anforderungen, die unter einem Mandanten zugeordnet werden. Ältere Buckets, die vorher erstellt wurden, sind weiterhin in einem globalen Namespace enthalten.

Bei Version 3 der OpenStack Identity API sollten Sie die Option rgw keystone admin tenant ersetzen durch:

Soll ein neues Platzierungsziel mit dem Namen „temporary“ erstellt werden, fügen Sie das Ziel zunächst in die Zonengruppe ein:

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

Geben Sie dann die Zonenplatzierungsdaten für dieses Ziel an:

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

Soll eine neue Speicherklasse mit dem Namen „COLD“ in das Ziel „default-placement“ eingefügt werden, fügen Sie die Klasse zunächst in die Zonengruppe ein:

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

Geben Sie dann die Zonenplatzierungsdaten für diese Speicherklasse an:

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

Neue Buckets greifen standardmäßig auf das Ziel default_placement der Zonengruppe zurück. Mit folgendem Kommando können Sie diese Zonengruppeneinstellung ändern:

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

Ein Ceph Object-Gateway-Benutzer kann ein nicht leeres Feld default_placement in den Benutzerinformationen festlegen und ist damit in der Lage, das standardmäßige Platzierungsziel der Zonengruppe zu überschreiben. Ebenso kann default_storage_class die Speicherklasse STANDARD überschreiben, die standardmäßig auf Objekte angewendet wird.

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

Wenn das Platzierungsziel einer Zonengruppe Tags enthält, können die Benutzer nur dann Buckets mit diesem Platzierungsziel erstellen, wenn ihre Benutzerinformationen mindestens ein passendes Tag im Feld „placement_tags“ umfassen. Damit ist es möglich, den Zugriff auf bestimmte Speichertypen einzuschränken.

Diese Felder können nicht direkt mit dem Kommando radosgw-admin bearbeitet werden. Sie müssen das JSON-Format daher manuell bearbeiten:

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

Wird ein Bucket mit dem S3-Protokoll erstellt, kann ein Platzierungsziel als Teil von LocationConstraint angegeben werden, sodass die standardmäßigen Platzierungsziele des Benutzers und der Zonengruppe überschrieben werden.

In der Regel muss LocationConstraint mit api_name der Zonengruppe übereinstimmen:

<LocationConstraint>default</LocationConstraint>

Sie können nach api_name einen Doppelpunkt und ein benutzerdefiniertes Platzierungsziel einfügen:

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

Wird ein Bucket mit dem Swift-Protokoll erstellt, können Sie ein Platzierungsziel im HTTP-Header unter X-Storage-Policy angeben:

X-Storage-Policy: NEW-PLACEMENT

Ein Bereich stellt einen global eindeutigen Namespace dar, der aus einer oder mehreren Zonengruppen mit einer oder mehreren Zonen besteht. Zonen enthalten Buckets, die ihrerseits Objekte enthalten. Durch einen Bereich kann das Ceph Object Gateway mehrere Namespaces und deren Konfiguration auf derselben Hardware unterstützen. Ein Bereich umfasst das Konzept von Zeiträumen. Jeder Zeitraum stellt den Zustand der Zonengruppe und der Zonenkonfiguration in der Zeit dar. Jedes Mal, wenn Sie eine Änderung an einer Zonengruppe oder Zone vornehmen, müssen Sie den Zeitraum aktualisieren und bestätigen. Standardmäßig erstellt das Ceph Object Gateway aus Gründen der Abwärtskompatibilität keinen Bereich. Als bewährtes Verfahren empfehlen wir, Bereiche für neue Cluster zu erstellen.

Erstellen Sie einen neuen Bereich namens Gold für die Konfiguration für mehrere Standorte. Öffnen Sie dazu eine Kommandozeilenschnittstelle auf einem Host, der für die Master-Zonengruppe und -Zone identifiziert wurde. Führen Sie dann folgendes Kommando aus:

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

Wenn der Cluster einen einzigen Bereich umfasst, geben Sie das Flag --default an. Wenn ‑‑default angegeben wird, verwendet radosgw-admin standardmäßig diesen Bereich. Wenn ‑‑default nicht angegeben ist, muss beim Hinzufügen von Zonengruppen und Zonen entweder das Flag --rgw-realm oder das Flag --realm-id angegeben werden, um den Bereich zu identifizieren.

Nach dem Erstellen des Bereichs gibt radosgw-admin die Bereichskonfiguration zurück:

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

Anmerkung

Ceph generiert eine eindeutige ID für den Bereich, die bei Bedarf die Umbenennung eines Bereichs ermöglicht.

Ein Bereich muss mindestens eine Zonengruppe enthalten, die als Master-Zonengruppe für den Bereich dient. Erstellen Sie eine neue Master-Zonengruppe für die Konfiguration für mehrere Standorte. Öffnen Sie dazu eine Kommandozeilenschnittstelle auf einem Host, der für die Master-Zonengruppe und -Zone identifiziert wurde. Erstellen Sie mit folgendem Kommando eine Master-Zonengruppe mit dem Namen us:

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

Wenn der Bereich eine einzige Zonengruppe umfasst, geben Sie das Flag --default an. Wenn --default angegeben ist, verwendet radosgw-admin beim Hinzufügen neuer Zonen standardmäßig diese Zonengruppe. Wenn --default nicht angegeben ist, muss beim Hinzufügen von Zonen entweder das Flag --rgw-zonegroup oder das Flag --zonegroup-id angegeben werden, um den Bereich zu identifizieren.

Nach dem Erstellen der Master-Zonengruppe gibt radosgw-admin die Zonengruppenkonfiguration zurück. Beispiel:

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

Wichtig

Zonen müssen auf einem Ceph Object-Gateway-Knoten erstellt werden, der sich innerhalb der Zone befindet.

Erstellen Sie eine neue Master-Zone für die Konfiguration für mehrere Standorte. Öffnen Sie dazu eine Kommandozeilenschnittstelle auf einem Host, der für die Master-Zonengruppe und -Zone identifiziert wurde. Führen Sie Folgendes aus:

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

Anmerkung

Die Optionen --access-key und --secret sind im obigen Beispiel nicht angegeben. Diese Einstellungen werden der Zone hinzugefügt, wenn im nächsten Abschnitt der Benutzer erstellt wird.

Nach dem Erstellen der Master-Zone gibt radosgw-admin die Zonenkonfiguration zurück. Beispiel:

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

Wichtig

Die folgenden Schritte gehen von einer Konfiguration für mehrere Standorte mit neu installierten Systemen aus, in denen noch keine Daten gespeichert sind. Löschen Sie nicht die Standardzone und ihre Pools, wenn Sie sie bereits zum Speichern von Daten verwenden. Ansonsten werden die Daten gelöscht und können nicht wiederhergestellt werden.

Die Standardinstallation von Object Gateway erstellt die Standard-Zonengruppe namens default. Löschen Sie die Standardzone, falls sie vorhanden ist. Stellen Sie sicher, dass Sie sie zuerst aus der Standard-Zonengruppe entfernen.

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

Löschen Sie die Standard-Pools in Ihrem Ceph-Speichercluster, falls sie vorhanden sind:

Wichtig

Im folgenden Schritt wird von einer Konfiguration für mehrere Standorte mit neu installierten Systemen ausgegangen, in denen aktuell noch keine Daten gespeichert sind. Löschen Sie nicht die Standard-Zonengruppe, wenn Sie sie bereits zum Speichern von Daten verwenden.

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

Warnung

Wenn Sie die Standard-Zonengruppe löschen, löschen Sie auch den Systembenutzer. Wenn Ihre Admin-Benutzerschlüssel nicht verteilt sind, schlägt die Object-Gateway-Verwaltungsfunktion des Ceph Dashboards fehl. Wenn Sie mit diesem Schritt fortfahren, machen Sie mit dem nächsten Abschnitt zum Neuerstellen des Systembenutzers weiter.

Die ceph-radosgw-Daemons müssen sich authentifizieren, bevor sie Bereichs- und Zeitrauminformationen abrufen. Erstellen Sie in der Master-Zone einen Systembenutzer, um die Authentifizierung zwischen den Daemons zu vereinfachen:

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

Notieren Sie sich den access_key und den secret_key, da die sekundären Zonen sie zur Authentifizierung bei der Master-Zone benötigen.

Fügen Sie den Systembenutzer zur Master-Zone hinzu:

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

Aktualisieren Sie die Periode, damit die Änderungen wirksam werden:

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

Aktualisieren Sie nach der Aktualisierung der Master-Zonenkonfiguration den Zeitraum:

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

Nach dem Aktualisieren des Zeitraums gibt radosgw-admin die Zeitraumkonfiguration zurück. Beispiel:

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

Anmerkung

Durch Aktualisieren des Zeitraums wird die Epoche geändert und sichergestellt, dass andere Zonen die aktualisierte Konfiguration erhalten.

Starten und aktivieren Sie den Ceph Object-Gateway-Service auf dem Object-Gateway-Host. Ermitteln Sie mit dem Kommando ceph fsid die eindeutige FSID des Clusters. Ermitteln Sie den Namen des Object-Gateway-Daemons mit dem Kommando ceph orch ps --hostname HOSTNAME.

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

Importieren Sie die Bereichskonfiguration mit dem URL-Pfad, dem Zugriffsschlüssel und dem Geheimnis der Masterzone in der Master-Zonengruppe auf den Host. Geben Sie zum Importieren eines nicht standardmäßigen Bereichs den Bereich mit den Konfigurationsoptionen --rgw-realm oder --realm-id an.

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

Anmerkung

Durch Importieren des Bereichs wird auch die aktuelle Zeitraumkonfiguration des entfernten Hosts abgerufen und zum aktuellen Zeitraum auch auf diesem Host gemacht.

Wenn dieser Bereich der Standardbereich oder der einzige Bereich ist, machen Sie den Bereich zum Standardbereich.

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

Erstellen Sie eine neue sekundäre Zone für die Konfiguration für mehrere Standorte. Öffnen Sie dazu eine Kommandozeilenschnittstelle auf einem Host, der für die sekundäre Zone identifiziert wurde. Geben Sie die Zonengruppen-ID, den neuen Zonennamen und einen Endpunkt für die Zone an. Verwenden Sie nicht das Flag --master. Alle Zonen werden standardmäßig in einer Aktiv/Aktiv-Konfiguration ausgeführt. Wenn die sekundäre Zone keine Schreibvorgänge akzeptieren soll, geben Sie das Flag --read-only an. Dadurch wird eine Aktiv/Passiv-Konfiguration zwischen der Master-Zone und der sekundären Zone erstellt. Geben Sie zusätzlich den access_key und den secret_key des generierten Systembenutzers an, der in der Master-Zone der Master-Zonengruppe gespeichert ist. Führen Sie Folgendes aus:

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]

Beispiel:

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

Wichtig

Die folgenden Schritte gehen von einer Konfiguration für mehrere Standorte mit neu installierten Systemen aus, in denen noch keine Daten gespeichert sind. Löschen Sie nicht die Standardzone und ihre Pools, wenn Sie sie bereits zum Speichern von Daten verwenden. Andernfalls gehen die Daten verloren und können nicht wiederhergestellt werden.

Löschen Sie die Standardzone, falls erforderlich:

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

Löschen Sie die Standard-Pools in Ihrem Ceph-Speichercluster, falls erforderlich:

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

Aktualisieren Sie die Ceph-Konfigurationsdatei auf den Hosts der sekundären Zone. Fügen Sie dazu die Konfigurationsoption rgw_zone und den Namen der sekundären Zone zum Instanzeintrag hinzu.

Führen Sie hierzu folgendes Kommando aus:

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

Aktualisieren Sie nach der Aktualisierung der Master-Zonenkonfiguration den Zeitraum:

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
}

Anmerkung

Durch Aktualisieren des Zeitraums wird die Epoche geändert und sichergestellt, dass andere Zonen die aktualisierte Konfiguration erhalten.

Starten und aktivieren Sie auf dem Object-Gateway-Host den Ceph Object-Gateway-Service:

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

Prüfen Sie den Synchronisierungsstatus, wenn die sekundäre Zone aktiv ist. Durch die Synchronisierung werden Benutzer und Buckets, die in der Master-Zone erstellt wurden, in die sekundäre Zone kopiert.

cephuser@adm > radosgw-admin sync status

Die Ausgabe gibt den Status der Synchronisierungsvorgänge an. Beispiel:

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

Anmerkung

Sekundäre Zonen akzeptieren zwar Bucket-Vorgänge, leiten allerdings Bucket-Vorgänge an die Master-Zone um. Dann synchronisieren sie sich mit der Master-Zone, um das Ergebnis der Bucket-Vorgänge zu erhalten. Wenn die Master-Zone inaktiv ist, schlagen Bucket-Vorgänge, die in der sekundären Zone ausgeführt werden, fehl. Objektvorgänge sollten jedoch erfolgreich sein.

Informationen über den Reproduktionsstatus einer Zone können abgefragt werden mit:

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

Wichtig

Seien Sie vorsichtig, wenn Sie die Zone ändern, die der Metadaten-Master ist. Wenn eine Zone die Synchronisierung der Metadaten mit der aktuellen Master-Zone noch nicht abgeschlossen hat, kann sie bei der Hochstufung zum Master keine verbleibenden Einträge mehr verarbeiten und diese Änderungen gehen verloren. Aus diesem Grund empfehlen wir, zu warten, bis der radosgw-admin-Synchronisierungsstatus einer Zone die Metadaten-Synchronisierung abgeschlossen hat, bevor sie zum Master hochgestuft wird. Ähnlich verhält es sich, wenn Änderungen an Metadaten von der aktuellen Master-Zone verarbeitet werden, während eine andere Zone zum Master hochgestuft wird. Diese Änderungen gehen wahrscheinlich verloren. Um dies zu vermeiden, empfehlen wir, alle Object-Gateway-Instanzen in der vorherigen Master-Zone herunterzufahren. Nach dem Hochstufen einer anderen Zone kann deren neuer Zeitraum mit radosgw-admin abgerufen werden und die Gateways können neu gestartet werden.

Führen Sie zum Hochstufen einer Zone (z. B. Zone us-west in der Zonengruppe us) zum Metadaten-Master folgende Kommandos für diese Zone aus:

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

Dadurch wird ein neuer Zeitraum generiert, und die Object-Gateway-Instanzen in der Zone us-west senden diesen Zeitraum an andere Zonen.