Zum Inhalt springenZur Seitennavigation springen: vorherige Seite [Zugriffstaste p]/nächste Seite [Zugriffstaste n]
Bezieht sich auf SUSE Enterprise Storage 7

21 Ceph Object Gateway Edit source

Dieses Kapitel enthält detaillierte Informationen zu Verwaltungsaufgaben, die für Object Gateway relevant sind, wie Prüfen des Servicestatus, Verwalten der Konten, Gateways an mehreren Standorten oder LDAP-Authentifizierung.

21.1 Object-Gateway-Beschränkungen und Benennungseinschränkungen Edit source

Nachfolgend sehen Sie eine Liste der wichtigen Object-Gateway-Beschränkungen:

21.1.1 Bucket-Einschränkungen Edit source

Wenn Sie Object Gateway über die S3 API verwenden, sind Bucket-Namen auf DNS-fähige Namen mit einem Bindestrich „-“ beschränkt. Wenn Sie Object Gateway über die Swift API verwenden, können Sie jede beliebige Kombination aus durch UTF-8 unterstützten Zeichen verwenden, mit Ausnahme des Schrägstrichs „/“. Die maximale Länge eines Bucket-Namens beträgt 255 Zeichen. Bucket-Namen müssen eindeutig sein.

Tipp
Tipp: Verwenden Sie DNS-fähige Bucket-Namen

Auch wenn Sie auf UTF-8 basierende Bucket-Namen über die Swift API verwenden, empfehlen wir, Buckets unter Berücksichtigung der S3-Benennungseinschränkungen zu benennen, um Probleme beim Zugriff auf diesen Bucket über die S3 API zu vermeiden.

21.1.2 Einschränkungen für gespeicherte Objekte Edit source

Maximale Anzahl der Objekte pro Benutzer

Standardmäßig keine Einschränkung (beschränkt durch ~ 2^63).

Maximale Anzahl der Objekte pro Bucket

Standardmäßig keine Einschränkung (beschränkt durch ~ 2^63).

Maximale Größe eines Objekts zum Heraufladen/Speichern

Einzelne Uploads sind auf 5 GB beschränkt. Verwenden Sie Multipart für größere Objekte. Die maximale Anzahl der Multipart-Datenblöcke beträgt 10.000.

21.1.3 HTTP-Header-Beschränkungen Edit source

Beschränkungen für HTTP-Header und Anforderungen hängen vom verwendeten Web-Frontend ab. In Beast ist die Größe des HTTP-Headers auf 16 kB beschränkt.

21.2 Bereitstellen des Object Gateways Edit source

Die Bereitstellung von Ceph Object Gateway erfolgt nach dem gleichen Verfahren wie die Bereitstellung anderer Ceph-Services, nämlich mit cephadm. Weitere Informationen finden Sie im Abschnitt 5.4.2, „Service- und Platzierungsspezifikation“ und insbesondere im Abschnitt 5.4.3.4, „Bereitstellen von Object Gateways“.

21.3 Betrieb des Object Gateway Service Edit source

Sie können die Object Gateways wie andere Ceph-Services betreiben. Identifizieren Sie dazu zunächst den Servicenamen mit dem Kommando ceph orch ps und führen Sie folgendes Kommando für den Betrieb von Services aus. Beispiel:

ceph orch daemon restart OGW_SERVICE_NAME

In Kapitel 14, Betrieb von Ceph-Services finden Sie alle Informationen über den Betrieb von Ceph-Services.

21.4 Konfigurationsoptionen Edit source

Unter Abschnitt 28.5, „Ceph Object Gateway“ finden Sie eine Liste der Object-Gateway-Konfigurationsoptionen.

21.5 Verwalten des Zugriffs auf Object Gateway Edit source

Die Kommunikation mit Object Gateway ist entweder über eine S3-fähige Schnittstelle oder eine Swift-fähige Schnittstelle möglich. Die S3-Schnittstelle ist kompatibel mit einer großen Teilmenge der S3 RESTful API. Die Swift-Schnittstelle ist kompatibel mit einer großen Teilmenge der OpenStack Swift API.

Bei beiden Schnittstellen müssen Sie einen bestimmten Benutzer erstellen und die relevante Client-Software installieren, um mit dem Gateway unter Verwendung des geheimen Schlüssels des Benutzers zu kommunizieren.

21.5.1 Zugreifen auf Object Gateway Edit source

21.5.1.1 Zugriff auf die S3-Schnittstelle Edit source

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.

  1. Installieren Sie das Paket phyton-boto:

    root # zypper in python-boto
  2. Erstellen Sie ein neues Python-Skript namens s3test.py mit folgendem Inhalt:

    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,
      )

    Ersetzen Sie HOSTNAME durch den Hostnamen des Hosts, auf dem Sie den Object-Gateway-Service konfiguriert haben, beispielsweise gateway_host.

  3. Führen Sie das Skript aus:

    python s3test.py

    Das Skript gibt in etwa Folgendes aus:

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

21.5.1.2 Zugriff auf die Swift-Schnittstelle Edit source

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

21.5.2 Verwalten von S3- und Swift-Konten Edit source

21.5.2.1 Hinzufügen von S3- und Swift-Benutzern Edit source

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:

  1. Zum Erstellen eines Swift-Benutzers (in unserer Terminologie ein Unterbenutzer) müssen Sie zunächst den zugeordneten Benutzer erstellen.

    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
  2. Zum Erstellen eines Unterbenutzers (Swift-Schnittstelle) für den Benutzer müssen Sie die Benutzer-ID (--uid=USERNAME), eine Unterbenutzer-ID und die Zugriffsstufe für den Unterbenutzer angeben.

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

    Beispiel:

    cephuser@adm > radosgw-admin subuser create --uid=example_user \
     --subuser=example_user:swift --access=full
  3. Generieren Sie einen geheimen Schlüssel für den Benutzer.

    cephuser@adm > radosgw-admin key create \
       --gen-secret \
       --subuser=example_user:swift \
       --key-type=swift
  4. Beide Kommandos geben JSON-formatierte Daten mit dem Benutzerstatus aus. Notieren Sie sich die folgenden Zeilen und merken Sie sich den Wert des secret_key:

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

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

21.5.2.2 Entfernen von S3- und Swift-Benutzern Edit source

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:

--purge-data

Löscht alle Daten, die der Benutzer-ID zugeordnet sind.

--purge-keys

Löscht alle Schlüssel, die der Benutzer-ID zugeordnet sind.

Tipp
Tipp: Entfernen eines Unterbenutzers

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

21.5.2.3 Ändern des Zugriffs und der geheimen Schlüssel von S3- und Swift-Benutzern Edit source

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
--key-type=TYPE

Gibt den Typ des Schlüssels an, entweder swift oder s3.

--gen-access-key

Generiert einen Zugriffsschlüssel nach dem Zufallsprinzip (für S3-Benutzer standardmäßig).

--gen-secret

Generiert einen geheimen Schlüssel nach dem Zufallsprinzip.

--secret=KEY

Gibt einen geheimen Schlüssel an, beispielsweise einen manuell generierten.

21.5.2.4 Aktivieren der Verwaltung von Benutzerquoten Edit source

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
--max-objects

Gibt die maximale Anzahl von Objekten an. Durch einen negativen Wert wird die Prüfung deaktiviert.

--max-size

Gibt die maximale Anzahl von Bytes an. Durch einen negativen Wert wird die Prüfung deaktiviert.

--quota-scope

Legt das Volumen für das Kontingent fest. Die Optionen sind bucket und user. Bucket-Quoten gelten für Buckets, die ein Benutzer besitzt. Benutzerquoten gelten für einen Benutzer.

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

21.6 HTTP-Frontends Edit source

Das Ceph Object Gateway unterstützt zwei eingebettete HTTP-Front-Ends: Beast und Civetweb.

Das Beast-Front-End führt das HTTP-Parsing mit der Boost.Beast-Bibliothek und die asynchrone Netzwerk-E/A mit der Boost.Asio-Bibliothek durch.

Das Civetweb-Front-End greift auf die Civetweb-HTTP-Bibliothek zurück (ein Mongoose-Fork).

Sie können diese über die Option rgw_frontends konfigurieren. Unter Abschnitt 28.5, „Ceph Object Gateway“ finden Sie eine Liste der Konfigurationsoptionen.

21.7 Aktivieren von HTTPS/SSL für Object Gateways Edit source

Zur Aktivierung des Object Gateways für die sichere Kommunikation über SSL benötigen Sie entweder ein von einer Zertifizierungsstelle ausgestelltes Zertifikat oder Sie müssen ein eigensigniertes Zertifikat erstellen.

21.7.1 Erstellen eines eigensignierten Zertifikats Edit source

Tipp
Tipp

Überspringen Sie diesen Abschnitt, wenn Sie bereits über ein gültiges Zertifikat verfügen, das von einer Zertifizierungsstelle signiert wurde.

Das folgende Verfahren beschreibt, wie ein eigensigniertes SSL-Zertifikat im Salt Master generiert wird.

  1. Wenn Ihr Object Gateway auch unter weiteren Subjektidentitäten bekannt sein soll, tragen Sie sie in die Option subjectAltName im Abschnitt [v3_req] in der Datei /etc/ssl/openssl.cnf ein:

    [...]
    [ v3_req ]
    subjectAltName = DNS:server1.example.com DNS:server2.example.com
    [...]
    Tipp
    Tipp: IP-Adressen in subjectAltName

    Sollen IP-Adressen anstelle von Domänennamen in der Option subjectAltName angegeben werden, ersetzen Sie die Beispielzeile wie folgt:

    subjectAltName = IP:10.0.0.10 IP:10.0.0.11
  2. Erstellen Sie den Schlüssel und das Zertifikat mit openssl. Geben Sie alle Daten ein, die in Ihrem Zertifikat enthalten sein sollen. Wir empfehlen die Eingabe des FQDN als Eigenname. Verifizieren Sie vor dem Signieren des Zertifikats, dass 'X509v3 Subject Alternative Name:' in den angeforderten Erweiterungen enthalten ist und dass für das resultierende Zertifikat "X509v3 Subject Alternative Name:" festgelegt wurde.

    root@master # openssl req -x509 -nodes -days 1095 \
     -newkey rsa:4096 -keyout rgw.key
     -out rgw.pem
  3. Hängen Sie den Schlüssel an die Zertifikatsdatei an:

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

21.7.2 Konfigurieren von Object Gateway mit SSL Edit source

Konfigurieren Sie Object Gateway für die Verwendung von SSL-Zertifikaten über die Option rgw_frontends. Beispiel:

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

Wenn Sie die Konfigurationsschlüssel CERT und KEY nicht angeben, sucht der Object-Gateway-Service das SSL-Zertifikat und den Schlüssel unter den folgenden Konfigurationsschlüsseln:

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

Wenn Sie den Standard-SSL-Schlüssel und -Zertifikatsspeicherort außer Kraft setzen möchten, importieren Sie sie mit dem folgenden Kommando in die Konfigurationsdatenbank:

ceph config-key set CUSTOM_CONFIG_KEY -i PATH_TO_CERT_FILE

Verwenden Sie dann die benutzerdefinierten Konfigurationsschlüssel mit der Anweisung config://.

21.8 Synchronisierungsmodule Edit source

Object Gateway wird als Service für mehrere Standorte bereitgestellt, wobei Sie Daten und Metadaten zwischen den Zonen spiegeln können. Synchronisierungsmodule werden auf das Framework für mehrere Standorte aufgesetzt und lassen die Weiterleitung von Daten und Metadaten zu einer anderen externen Schicht zu. Mit einem Synchronisierungsmodul kann eine Reihe von Aktionen durchgeführt werden, sobald eine Datenänderung vorgenommen wird (beispielsweise Metadaten-Operationen wie die Erstellung von Buckets oder Benutzern). Da die Object-Gateway-Änderungen an mehreren Standorten letztendlich an Remote-Standorten konsistent sind, werden die Änderungen asynchron verteilt. Damit sind Anwendungsfälle wie das Sichern des Objektspeichers in einem externen Cloud Cluster, eine benutzerdefinierte Sicherungslösung mit Bandlaufwerken oder die Indizierung von Metadaten in ElasticSearch abgedeckt.

21.8.1 Konfigurieren von Synchronisierungsmodulen Edit source

Alle Synchronisierungsmodule werden auf ähnliche Weise konfiguriert. Sie müssen eine neue Zone erstellen (weitere Informationen siehe Abschnitt 21.13, „Object Gateways an mehreren Standorten“) und die Option --tier_type für diese Zone festlegen, beispielsweise --tier-type=cloud für das Cloud-Synchronisierungsmodul:

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

Mit folgendem Kommando konfigurieren Sie die jeweilige Schicht:

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

KEY in der Konfiguration bezeichnet die zu aktualisierende Konfigurationsvariable und VALUE bezeichnet den neuen Wert. Verschachtelte Werte können mithilfe von Punkten angegeben werden. Beispiel:

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

Matrixeinträge können mithilfe von eckigen Klammern „[]“ um den referenzierten Eintrag angegeben werden. Soll ein neuer Matrixeintrag eingefügt werden, setzen Sie den Eintrag in eckige Klammern „[]“. Ein Indexwert von -1 verweist auf den letzten Eintrag in der Matrix. Es ist nicht möglich, einen neuen Eintrag anzulegen und im gleichen Kommando auf diesen Eintrag zu verweisen. Mit folgendem Kommando erstellen Sie beispielsweise ein neues Profil für Buckets, die mit PREFIX beginnen:

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
Tipp
Tipp: Hinzufügen und Entfernen von Konfigurationseinträgen

Mit dem Parameter --tier-config-add=KEY=VALUE fügen Sie einen neuen Schichtkonfigurationseintrag ein.

Mit --tier-config-rm=KEY entfernen Sie einen vorhandenen Eintrag.

21.8.2 Synchronisieren von Zonen Edit source

Die Konfiguration eines Synchronisierungsmoduls wird lokal in einer Zone vorgenommen. Das Synchronisierungsmodul bestimmt, ob die Zone Daten exportiert oder in einer anderen Zone geänderte Daten nur nutzen darf. Ab Luminous sind die unterstützten Synchronisierungs-Plugins ElasticSearch, rgw (das standardmäßige Synchronisierungs-Plugin zum Synchronisieren von Daten zwischen den Zonen) und log (ein Trivial-Synchronisierungs-Plugin zum Protokollieren der Metadaten-Operation in den Remote-Zonen). In den folgenden Abschnitten verwenden wir das Beispiel einer Zone mit dem Synchronisierungsmodul ElasticSearch. Bei·der·Konfiguration·eines·anderen·Synchronisierungs-Plugins wäre das Verfahren ähnlich.

Anmerkung
Anmerkung: Standardmäßiges Synchronisierungs-Plugin

rgw ist das standardmäßige Synchronisierungs-Plugin. Es muss nicht explizit konfiguriert werden.

21.8.2.1 Anforderungen und Annahmen Edit source

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.

21.8.2.2 Konfigurieren von Zonen Edit source

  1. Erstellen Sie die dritte Zone so ähnlich wie die Zonen, die in Abschnitt 21.13, „Object Gateways an mehreren Standorten“ beschrieben sind. Beispiel:

    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. Ein Synchronisierungsmodul kann für diese Zone mit folgendem Kommando konfiguriert werden:

    cephuser@adm > radosgw-admin zone modify --rgw-zone=ZONE-NAME --tier-type=TIER-TYPE \
    --tier-config={set of key=value pairs}
  3. Beispiel im Synchronisierungsmodul 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

    Die verschiedenen unterstützten „tier-config“-Optionen finden Sie in Abschnitt 21.8.3, „Synchronisierungsmodul ElasticSearch“.

  4. Aktualisieren Sie schließlich den Zeitraum:

    cephuser@adm > radosgw-admin period update --commit
  5. Starten Sie das Object Gateway in der Zone:

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

21.8.3 Synchronisierungsmodul ElasticSearch Edit source

Dieses Synchronisierungsmodul schreibt die Metadaten aus anderen Zonen zu ElasticSearch. Ab Luminous ist es die JSON-Datei der Datenfelder, die aktuell in ElasticSearch gespeichert ist.

{
  "_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 Parameter zur Konfiguration des ElasticSearch-Schichttyps Edit source

endpoint

Gibt den ElasticSearch Server-Endpunkt für den Zugriff an.

num_shards

(Ganzzahl) Die Anzahl der Shards, mit denen ElasticSearch beim Initialisieren der Datensynchronisierung konfiguriert wird. Beachten Sie, dass dies nach der Initialisierung nicht mehr geändert werden kann. Zum Ändern muss der ElasticSearch-Index neu aufgebaut und der Datensynchronisierungsvorgang neu initialisiert werden.

num_replicas

(Ganzzahl) Die Anzahl der Reproduktionen, mit denen ElasticSearch beim Initialisieren der Datensynchronisierung konfiguriert wird.

explicit_custom_meta

(true | false) Gibt an, ob alle benutzerdefinierten Metadaten der Benutzer indiziert werden oder ob Benutzer (auf Bucket-Ebene) konfigurieren müssen, welche Kundenmetadaten-Einträge indiziert werden sollten. Standardmäßig ist dies auf „false“ festgelegt.

index_buckets_list

(durch Komma getrennte Liste von Zeichenketten) Falls leer, werden alle Buckets indiziert. Andernfalls werden nur die hier genannten Buckets indiziert. Es ist möglich, Bucket-Präfixe (zum Beispiel „foo*“) oder Bucket-Suffixe (zum Beispiel „*bar“) anzugeben.

approved_owners_list

(durch Komma getrennte Liste von Zeichenketten) Falls leer, werden die Buckets aller Eigentümer indiziert (falls keine anderen Einschränkungen vorhanden sind). Andernfalls werden nur die Buckets bestimmter Eigentümer indiziert. Suffixe und Präfixe können ebenfalls angegeben werden.

override_index_path

(Zeichenkette) Falls nicht leer, wird diese Zeichenkette als ElasticSearch-Indexpfad verwendet. Andernfalls wird der Indexpfad bei Initialisierung der Synchronisierung festgelegt und generiert.

benutzername

Gibt einen Benutzernamen für ElasticSearch an, falls eine Authentifizierung erforderlich ist.

kennwort

Gibt ein Passwort für ElasticSearch an, falls eine Authentifizierung erforderlich ist.

21.8.3.2 Metadatenabfragen Edit source

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.

Abrufen einer ElasticSearch-Abfrage
GET /BUCKET?query=QUERY-EXPR

Anforderungsparameter:

  • max-keys: maximale Anzahl der Einträge, die zurückgegeben werden sollen

  • marker: Kennzeichnung für die Paginierung

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

„op“ steht für eines der folgenden Zeichen: <, <=, ==, >=, >

Beispiel:

GET /?query=name==foo

Gibt alle indizierten Schlüssel zurück, für die der Benutzer über Berechtigungen verfügt. Sie werden als „foo“ bezeichnet. Die Ausgabe ist eine Liste von Schlüsseln im XML-Format, die der S3-Antwort auf die Anforderung zum Auflisten von Buckets ähnlich ist.

Konfigurieren benutzerdefinierter Metadatenfelder

Definieren Sie, welche benutzerdefinierten Metadateneinträge (unter dem angegebenen Bucket) indiziert werden und welchen Typ diese Schlüssel haben sollen. Dies ist erforderlich, damit RGW die angegebenen benutzerdefinierten Metadatenwerte indiziert, wenn die explizite Indizierung von benutzerdefinierten Metadaten konfiguriert ist. Andernfalls ist es erforderlich in Fällen, in denen die indizierten Metadatenschlüssel keine Zeichenketten sind.

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

Mehrere Metadatenfelder müssen durch Komma getrennt werden. Ein Typ kann für ein Feld mit „;“ erzwungen werden. Derzeit sind Zeichenketten (Standard), Ganzzahlen und Datumsangaben als Typen zulässig. Mit folgendem Kommando indizieren Sie beispielsweise die Metadaten eines benutzerdefinierten Objekts („x-amz-meta-year“ als Ganzzahl, „x-amz-meta-date“ als Datum und „x-amz-meta-title“ als Zeichenkette):

POST /mybooks?mdsearch
x-amz-meta-search: x-amz-meta-year;int, x-amz-meta-release-date;date, x-amz-meta-title;string
Löschen einer benutzerdefinierten Metadatenkonfiguration

Löschen Sie eine benutzerdefinierte Konfiguration eines Metadaten-Buckets.

DELETE /BUCKET?mdsearch
Abrufen einer benutzerdefinierten Metadatenkonfiguration

Rufen Sie eine benutzerdefinierte Konfiguration eines Metadaten-Buckets ab.

GET /BUCKET?mdsearch

21.8.4 Cloud-Synchronisierungsmodul Edit source

In diesem Abschnitt erhalten Sie Informationen zu einem Modul, mit dem die Zonendaten mit einem Remote-Cloud-Service synchronisiert werden. Die Synchronisierung läuft nur in eine Richtung ab – die Daten werden nicht aus der Remote-Zone zurück synchronisiert. Dieses Modul sorgt hauptsächlich dafür, dass Daten mit mehreren Cloud-Service-Anbietern synchronisiert werden können. Derzeit werden Cloud-Anbieter unterstützt, die mit AWS (S3) kompatibel sind.

Für die Synchronisierung von Daten mit einem Remote-Cloud-Service müssen Sie Berechtigungsnachweise für Benutzer konfigurieren. Zahlreiche Cloud-Services beschränken die maximale Anzahl der Buckets, die von den einzelnen Benutzern erstellt werden können. Sie können daher die Zuordnung von Quellobjekten und Buckets, verschiedenen Zielen und verschiedenen Buckets sowie von Bucket-Präfixen konfigurieren. Die Quell-Zugriffslisten (ACLs) werden dabei nicht beibehalten. Sie können Berechtigungen bestimmter Quellbenutzer zu bestimmten Zielbenutzern zuordnen.

Aufgrund der API-Einschränkungen ist es nicht möglich, die ursprüngliche Bearbeitungszeit und das HTTP-Entitäts-Tag (ETag) des Objekts beizubehalten. Das Cloud-Synchronisierungsmodul speichert diese Angaben als Metadaten-Attribute in den Zielobjekten.

21.8.4.1 Konfigurieren des Cloud-Synchronisierungsmoduls Edit source

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.

Beispiel 21.1: Trivial-Konfiguration
{
  "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,
}
Beispiel 21.2: Nicht-Trivial-Konfiguration
{
  "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:

Verbindung

Eine Verbindung zum Remote-Cloud-Service. Umfasst „connection_id“, „access_key“, „secret“, „endpoint“ und „host_style“.

access_key

Remote-Cloud-Zugriffsschlüssel für die jeweilige Verbindung.

secret

Geheimschlüssel für den Remote-Cloud-Service.

endpoint

URL für den Endpunkt des Remote-Cloud-Service.

host_style

Hosttyp („path“ oder „virtual“) für den Zugriff auf den Remote-Cloud-Endpunkt. Der Standardwert lautet „path“.

acls

Matrix der Zugriffslistenzuordnungen.

acl_mapping

Jede „acl_mapping“-Struktur umfasst „type“, „source_id“ und „dest_id“. Hiermit wird die ACL-Mutation für die einzelnen Objekte definiert. Mit einer ACL-Mutation kann die Quellbenutzer-ID in eine Ziel-ID umgewandelt werden.

type

ACL-Typ: „id“ definiert die Benutzer-ID, „email“ definiert den Benutzer nach E-Mail und „uri“ definiert den Benutzer nach URI (Gruppe).

source_id

ID des Benutzers in der Quellzone.

dest_id

ID des Benutzers im Ziel.

target_path

Mit dieser Zeichenkette wird definiert, wie der Zielpfad erstellt wird. Der Zielpfad umfasst ein Präfix, an das der Quellobjektname angehängt wird. Das konfigurierbare Element für den Zielpfad kann die folgenden Variablen umfassen:

SID

Eindeutige Zeichenkette für die ID der Synchronisierungsinstanz.

ZONEGROUP

Name der Zonengruppe.

ZONEGROUP_ID

ID der Zonengruppe.

ZONE

Name der Zone.

ZONE_ID

ID der Zone.

BUCKET

Name des Quell-Buckets.

OWNER

ID für den Eigentümer des Quell-Buckets.

Beispiel: target_path = rgwx-ZONE-SID/OWNER/BUCKET

acl_profiles

Matrix mit Zugriffslistenprofilen.

acl_profile

Jedes Profil umfasst „acls_id“ für das Profil sowie eine „acls“-Matrix mit einer Liste der „acl_mappings“.

Profile

Liste mit Profilen. Jedes Profil umfasst Folgendes:

source_bucket

Entweder der Name eines Buckets oder ein Bucket-Präfix (Endung auf *), mit dem der oder die Quell-Bucket(s) für dieses Profil definiert werden.

target_path

Erläuterung siehe oben.

connection_id

ID der Verbindung für dieses Profil.

acls_id

ID des ACL-Profils für dieses Profil.

21.8.4.2 S3-spezifische konfigurierbare Elemente Edit source

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

Objekte mit einer Größe größer oder gleich diesem Wert werden per Multipart-Upload mit dem Cloud-Service synchronisiert.

multipart_min_part_size

Mindestgröße der Teile für die Synchronisierung von Objekten per Multipart-Upload.

21.8.5 Archiv-Synchronisierungsmodul Edit source

Das Archiv-Synchronisierungsmodul verwendet die Versionierungsfunktion von S3-Objekten im Object Gateway. Sie können eine Archivzone konfigurieren, in der die verschiedenen Versionen von S3-Objekten erfasst werden, die im Lauf der Zeit in anderen Zonen auftreten. Der Versionsverlauf in der Archivzone kann nur mithilfe von Gateways beseitigt werden, die der Archivzone zugeordnet sind.

Bei einer solchen Architektur können verschiedene nichtversionierte Zonen ihre Daten und Metadaten über die jeweiligen Zonen-Gateways spiegeln, sodass Hochverfügbarkeit für die Endbenutzer erzielt wird, während in der Archivzone alle Datenaktualisierungen erfasst und als Versionen der S3-Objekte konsolidiert werden.

Wenn Sie die Archivzone in eine Mehrzonen-Konfiguration einbinden, erhalten Sie die Flexibilität eines S3-Objektverlaufs in einer einzelnen Zone, wobei Sie den Speicherplatz einsparen, den die Reproduktionen der versionierten S3-Objekte in den verbleibenden Zonen belegen würden.

21.8.5.1 Konfigurieren des Archiv-Synchronisierungsmoduls Edit source

Tipp
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

21.9 LDAP-Authentifizierung Edit source

Abgesehen von der standardmäßigen Authentifizierung lokaler Benutzer kann Object Gateway Benutzer auch über LDAP Server Services authentifizieren.

21.9.1 Beglaubigungsverfahren Edit source

Das Object Gateway extrahiert den Berechtigungsnachweis des Benutzers aus einem Token. Ein Suchfilter wird aus dem Benutzernamen erstellt. Das Object Gateway durchsucht anhand des konfigurierten Servicekontos das Verzeichnis nach einem passenden Eintrag. Wird ein Eintrag gefunden, versucht das Object Gateway, eine Bindung zum gefundenen eindeutigen Namen mit dem Passwort aus dem Token herzustellen. Wenn der Berechtigungsnachweis gültig ist, wird die Bindung hergestellt und das Object Gateway gewährt den Zugriff.

Die Anzahl der Benutzer lässt sich begrenzen. Legen Sie dazu die Basis für die Suche auf eine bestimmte organisatorische Einheit fest oder geben Sie einen benutzerdefinierten Suchfilter an, beispielsweise eine bestimmte Gruppenmitgliedschaft, benutzerdefinierte Objektklassen oder Attribute.

21.9.2 Anforderungen Edit source

  • LDAP oder Active Directory: Eine aktive LDAP-Instanz, auf die Object Gateway zugreifen kann.

  • Servicekonto: LDAP-Berechtigungen, die vom Object Gateway mit Suchberechtigungen verwendet werden sollen.

  • Benutzerkonto: Mindestens ein Benutzerkonto im LDAP-Verzeichnis.

Wichtig
Wichtig: LDAP-Benutzer und lokale Benutzer dürfen sich nicht überlappen

Für lokale Benutzer und für Benutzer, die mit LDAP authentifiziert werden, sollten nicht dieselben Benutzernamen verwendet werden. Das Object Gateway kann sie nicht unterscheiden und behandelt sie als ein und denselben Benutzer.

Tipp
Tipp: Integritätsprüfungen

Verifizieren Sie das Servicekonto oder die LDAP-Verbindung mit dem Dienstprogramm ldapsearch. Beispiel:

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

Vergewissern Sie sich, dass Sie dieselben LDAP-Parameter verwenden wie in der Ceph-Konfigurationsdatei, um mögliche Probleme zu vermeiden.

21.9.3 Konfigurieren des Object Gateways zur Verwendung der LDAP-Authentifizierung Edit source

Die folgenden Parameter beziehen sich auf die LDAP-Authentifizierung:

rgw_ldap_uri

Gibt den zu verwendenden LDAP-Server an. Vergewissern Sie sich, dass Sie den Parameter ldaps://FQDN:port verwenden, um die offene Übertragung des Berechtigungsnachweises in Klartext zu verhindern.

rgw_ldap_binddn

Der vom Object Gateway verwendete eindeutige Name des Servicekontos.

rgw_ldap_secret

Das Passwort für das Service-Konto.

rgw_ldap_searchdn

Gibt die Basis im Verzeichnisinformationsbaum zum Suchen von Benutzern an. Sie könnte die organisatorische Einheit Ihrer Benutzer oder eine spezifischere organisatorische Einheit sein.

rgw_ldap_dnattr

Das Attribut, das im konstruierten Suchfilter zum Abgleich eines Benutzernamens verwendet wird. Abhängig von Ihrem Verzeichnisinformationsbaum (Directory Information Tree, DIT) wäre es wahrscheinlich uid oder cn.

rgw_search_filter

Wenn dieser Parameter nicht angegeben ist, konstruiert das Object Gateway automatisch den Suchfilter mit der Einstellung rgw_ldap_dnattr. Mit diesem Parameter engen Sie die Liste der zulässigen Benutzer auf sehr flexible Weise ein. Weitere Details finden Sie in Abschnitt 21.9.4, „Verwenden eines benutzerdefinierten Suchfilters zur Begrenzung des Benutzerzugriffs“.

21.9.4 Verwenden eines benutzerdefinierten Suchfilters zur Begrenzung des Benutzerzugriffs Edit source

Den Parameter rgw_search_filter können Sie auf unterschiedliche Weise verwenden.

21.9.4.1 Teilfilter zur weiteren Beschränkung des konstruierten Suchfilters Edit source

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.

21.9.4.2 Vollständiger Filter Edit source

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
Anmerkung: Attribut memberOf

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

21.9.5 Generieren eines Zugriffstokens für die LDAP-Authentifizierung Edit source

Das Dienstprogramm radosgw-token generiert den Zugriffstoken basierend auf LDAP-Benutzername und Passwort. Es gibt eine mit base-64 verschlüsselte Zeichenkette aus, die der eigentliche Zugriffstoken ist. Verwenden Sie Ihren bevorzugten S3 Client (weitere Informationen hierzu finden Sie in Abschnitt 21.5.1, „Zugreifen auf Object Gateway“), geben Sie den Token als Zugriffsschlüssel an und verwenden Sie einen leeren geheimen Schlüssel.

tux > export RGW_ACCESS_KEY_ID="USERNAME"
tux > export RGW_SECRET_ACCESS_KEY="PASSWORD"
cephuser@adm > radosgw-token --encode --ttype=ldap
Wichtig
Wichtig: Klartext-Berechtigungsnachweis

Der Zugriffstoken ist eine mit base-64 verschlüsselte JSON-Struktur und enthält den LDAP-Berechtigungsnachweis als Klartext.

Anmerkung
Anmerkung: Active Directory

Verwenden Sie für Active Directory den Parameter --ttype=ad.

21.10 Bucket-Index-Sharding Edit source

Das Object Gateway speichert Bucket-Indexdaten in einem Index-Pool, der standardmäßig .rgw.buckets.index lautet. Wenn Sie zu viele (hunderttausende) Objekte in einen einzelnen Bucket stellen und das Kontingent für die maximale Anzahl der Objekte pro Bucket (rgw bucket default quota max objects) nicht festgelegt ist, dann verschlechtert sich möglicherweise die Leistung des Index-Pools. Ein Bucket-Index-Sharding verhindert derartige Leistungseinbußen und ermöglicht eine hohe Anzahl von Objekten pro Bucket.

21.10.1 Bucket-Index-Resharding Edit source

Wenn ein Bucket groß geworden ist und die anfängliche Konfiguration nicht mehr ausreicht, muss für den Indexpool des Buckets ein Resharding durchgeführt werden. Sie können entweder das automatische Online-Resharding für den Bucket-Index durchführen (Informationen hierzu finden Sie in Abschnitt 21.10.1.1, „Dynamisches Resharding“) oder ein manuelles Offline-Resharding des Bucket-Index (Informationen hierzu finden Sie in Abschnitt 21.10.1.2, „Manuelles Resharding“).

21.10.1.1 Dynamisches Resharding Edit source

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:

  • Wenn neue Objekte zum Bucket hinzugefügt werden.

  • In einem Hintergrundprozess, der regelmäßig alle Buckets absucht. Dies ist erforderlich, um bestehende Buckets zu verarbeiten, die nicht aktualisiert werden.

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.

Konfigurieren eines dynamischen Reshardings
rgw_dynamic_resharding

Aktiviert oder deaktiviert das dynamische Index-Resharding. Mögliche Werte sind „true“ und „false“. Die Standardeinstellung ist „true“.

rgw_reshard_num_logs

Anzahl der Shards für das Resharding-Protokoll. Der Standardwert ist 16.

rgw_reshard_bucket_lock_duration

Dauer der Sperre des Bucket-Objekts beim Resharding. Die Standardeinstellung ist 120 Sekunden.

rgw_max_objs_per_shard

Maximale Anzahl der Objekte pro Bucket-Index-Shard. Der Standardwert ist 100.000 Objekte.

rgw_reshard_thread_interval

Maximale Zeit zwischen den Verarbeitungsrunden des Reshard-Threads. Die Standardeinstellung ist 600 Sekunden.

Kommandos zum Verwalten des Resharding-Vorgangs
Fügen Sie ein Bucket zur Resharding-Warteschlange hinzu mit:
cephuser@adm > radosgw-admin reshard add \
 --bucket BUCKET_NAME \
 --num-shards NEW_NUMBER_OF_SHARDS
Listen Sie die Resharding-Warteschlange auf mit:
cephuser@adm > radosgw-admin reshard list
Verarbeiten/planen Sie ein Bucket-Resharding mit:
cephuser@adm > radosgw-admin reshard process
Zeigen Sie den Bucket-Resharding-Status an mit:
cephuser@adm > radosgw-admin reshard status --bucket BUCKET_NAME
Brechen Sie das ausstehende Bucket-Resharding ab mit:
cephuser@adm > radosgw-admin reshard cancel --bucket BUCKET_NAME

21.10.1.2 Manuelles Resharding Edit source

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:

  • Es erstellt einen neuen Satz von Bucket-Index-Objekten für das angegebene Objekt.

  • Es verteilt alle Einträge dieser Indexobjekte.

  • Es erstellt eine neue Bucket-Instanz.

  • Es verknüpft die neue Bucket-Instanz mit dem Bucket, sodass alle neuen Index-Operationen durch die neuen Bucket-Indizes gehen.

  • Gibt die alte und die neue Bucket-ID an die Standardausgabe aus.

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

Prozedur 21.1: Resharding des Bucket-Index
  1. Vergewissern Sie sich, dass alle Operationen zum Bucket gestoppt sind.

  2. Sichern Sie den ursprünglichen Bucket-Index:

    cephuser@adm > radosgw-admin bi list \
     --bucket=BUCKET_NAME \
     > BUCKET_NAME.list.backup
  3. Führen Sie ein Resharding des Bucket-Index aus:

     cephuser@adm > radosgw-admin bucket reshard \
     --bucket=BUCKET_NAME \
     --num-shards=NEW_SHARDS_NUMBER
    Tipp
    Tipp: Alte Bucket-ID

    Als Teil seiner Ausgabe gibt dieses Kommando auch die neue und alte Bucket-ID aus.

21.10.2 Bucket-Index-Sharding für neue Buckets Edit source

Für ein Bucket-Index-Sharding stehen zwei Optionen zur Verfügung:

  • Verwenden Sie bei einfachen Konfigurationen die Option rgw_override_bucket_index_max_shards.

  • Verwenden Sie bei Konfigurationen mit mehreren Standorten die Option bucket_index_max_shards.

Das Bucket-Index-Sharding wird deaktiviert, wenn die Optionen auf 0 festgelegt sind. Ein Wert größer 0 aktiviert das Bucket-Index-Sharding und legt die maximale Anzahl von Shards fest.

Die folgende Formel unterstützt Sie beim Berechnen der empfohlenen Anzahl von Shards:

number_of_objects_expected_in_a_bucket / 100000

Beachten Sie, dass maximal 7877 Shards möglich sind.

21.10.2.1 Konfigurationen für mehrere Standorte Edit source

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:

  1. Exportieren Sie die Zonengruppenkonfiguration in die Datei zonegroup.json:

    cephuser@adm > radosgw-admin zonegroup get > zonegroup.json
  2. Bearbeiten Sie die Datei zonegroup.json und legen Sie die Option bucket_index_max_shards für jede benannte Zone fest.

  3. Setzen Sie die Zonengruppe zurück:

    cephuser@adm > radosgw-admin zonegroup set < zonegroup.json
  4. Aktualisieren Sie den Zeitraum mit. Siehe Abschnitt 21.13.2.6, „Aktualisieren Sie den Zeitraum mit“.

21.11 Integration von OpenStack Keystone Edit source

OpenStack Keystone ist ein Identitätsservice für das OpenStack-Produkt. Sie können das Object Gateway mit Keystone integrieren, um ein Gateway einzurichten, das einen Keystone-Authentifizierungstoken akzeptiert. Ein Benutzer, der durch Keystone für den Zugriff auf das Gateway autorisiert ist, wird am Ceph Object Gateway verifiziert und gegebenenfalls automatisch erstellt. Das Object Gateway fragt Keystone regelmäßig nach einer Liste der entzogenen Token ab.

21.11.1 Konfigurieren von OpenStack Edit source

Vor dem Konfigurieren des Ceph Gateways müssen Sie OpenStack Keystone konfigurieren, um den Swift Service zu aktivieren und auf das Ceph Object Gateway auszurichten:

  1. Festlegen des Swift Service. Sie müssen zunächst den Swift Service erstellen, um OpenStack zur Validierung von Swift-Benutzern zu verwenden:

    tux > openstack service create \
     --name=swift \
     --description="Swift Service" \
     object-store
  2. Festlegen der Endpunkte. Nach dem Erstellen des Swift Service müssen Sie diesen auf das Ceph Object Gateway ausrichten. Ersetzen Sie REGION_NAME durch den Zonengruppennamen oder Regionsnamen des Gateways.

    tux > 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. Verifizieren der Einstellungen. Nach dem Erstellen des Swift Service und dem Festlegen der Endpunkte müssen Sie die Endpunkte anzeigen, um zu verifizieren, dass alle Einstellungen korrekt sind.

    tux > openstack endpoint show object-store

21.11.2 Konfigurieren des Ceph Object Gateways Edit source

21.11.2.1 Konfigurieren der SSL-Zertifikate Edit source

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.

21.11.2.2 Konfigurieren der Optionen des Object Gateways Edit source

Die Keystone-Integration wird mit folgenden Optionen konfiguriert:

rgw keystone api version

Version der Keystone-API. Gültige Optionen sind 2 oder 3. Der Standardwert ist 2.

rgw keystone url

Die URL und Portnummer der administrativen RESTful API am Keystone-Server. Folgt dem Schema SERVER_URL:PORTNUMMER.

rgw keystone admin token

Der Token oder das gemeinsame Geheimnis, der/das intern in Keystone für administrative Anforderungen konfiguriert wird.

rgw keystone accepted roles

Die Rollen zur Verarbeitung der Anforderungen. Die Standardeinstellung ist „Member, admin“.

rgw keystone accepted admin roles

Die Liste der Rollen, mit denen Benutzer Verwaltungsrechte erhalten können.

rgw keystone token cache size

Die maximale Anzahl der Einträge im Keystone-Token-Cache.

rgw keystone revocation interval

Die Dauer in Sekunden, bevor entzogene Token überprüft werden. Der Standardwert ist 15 * 60.

rgw keystone implicit tenants

Neue Benutzer werden in ihren eigenen Mandanten mit demselben Namen erstellt. Die Standardeinstellung ist „false“.

rgw s3 auth use keystone

Wird diese Option auf „true“ festgelegt, authentifiziert das Ceph Object Gateway Benutzer mit Keystone. Die Standardeinstellung ist „false“.

nss db path

Der Pfad zur NSS-Datenbank.

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:

rgw keystone admin user

Der Benutzername des verwaltungsberechtigten Keystone-Benutzers.

rgw keystone admin password

Das Passwort des verwaltungsberechtigten Keystone-Benutzers.

rgw keystone admin tenant

Der Mandant des verwaltungsberechtigten Benutzers von Keystone Version 2.0.

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

rgw keystone admin domain

Die Domäne des verwaltungsberechtigten Keystone-Benutzers.

rgw keystone admin project

Das Projekt des verwaltungsberechtigten Keystone-Benutzers.

21.12 Pool-Platzierung und Speicherklassen Edit source

21.12.1 Anzeigen von Platzierungszielen Edit source

Mit Platzierungszielen wird gesteuert, welche Pools einem bestimmten Bucket zugeordnet werden. Das Platzierungsziel eines Buckets wird beim Erstellen festgelegt und kann nicht geändert werden. Mit folgendem Kommando rufen Sie die zugehörige placement_rule ab:

cephuser@adm > radosgw-admin bucket stats

Die Zonengruppenkonfiguration umfasst eine Liste von Platzierungszielen mit dem anfänglichen Ziel „default-placement“. Anschließend ordnet die Zonenkonfiguration die Namen der einzelnen Zonengruppen-Platzierungsziele dem lokalen Speicher zu. Diese Zonenplatzierungsdaten umfassen den Namen „index_pool“ für den Bucket-Index, den Namen „data_extra_pool“ für Metadaten zu unvollständigen Multipart-Uploads sowie je einen Namen „data_pool“ für die einzelnen Speicherklassen.

21.12.2 Speicherklassen Edit source

Speicherklassen tragen dazu bei, die Platzierung von Objektdaten individuell anzupassen. Mithilfe von S3-Bucket-Lebenszyklusregeln lässt sich der Übergang von Objekten zwischen Speicherklassen automatisieren.

Speicherklassen werden anhand von Platzierungszielen definiert. In den einzelnen Platzierungszielen der Zonengruppe sind die verfügbaren Speicherklassen jeweils mit der Anfangsklasse „STANDARD“ aufgelistet. Die Zonenkonfiguration stellt jeweils den Pool-Namen „data_pool“ für die einzelnen Speicherklassen der Zonengruppe bereit.

21.12.3 Konfigurieren von Zonengruppen und Zonen Edit source

Mit dem Kommando radosgw-admin konfigurieren Sie die Platzierung der Zonengruppen und Zonen. Mit folgendem Kommando rufen Sie die Platzierungskonfiguration der Zonengruppe ab:

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

Mit folgendem Kommando rufen Sie die Platzierungskonfiguration der Zone ab:

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
            }
        }
    ],
    ...
}
Anmerkung
Anmerkung: Keine vorherige Konfiguration mit mehreren Standorten

Falls Sie bislang noch keine Konfiguration mit mehreren Standorten vorgenommen haben, wird je eine „standardmäßige“ Zone und Zonengruppe erstellt. Änderungen an der Zone/Zonengruppe treten erst dann in Kraft, wenn Sie die Ceph Object Gateways neu starten. Wenn Sie einen Bereich für mehrere Standorte angelegt haben, treten Änderungen an der Zone/Zonengruppe in Kraft, sobald Sie diese Änderungen mit dem Kommando radosgw-admin period update --commit übergeben.

21.12.3.1 Hinzufügen eines Platzierungsziels Edit source

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

21.12.3.2 Hinzufügen einer Speicherklasse Edit source

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

21.12.4 Anpassung der Platzierung Edit source

21.12.4.1 Bearbeiten der standardmäßigen Zonengruppenplatzierung Edit source

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

21.12.4.2 Bearbeiten der standardmäßigen Benutzerplatzierung Edit source

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

21.12.4.3 Bearbeiten der standardmäßigen S3-Bucket-Platzierung Edit source

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>

21.12.4.4 Bearbeiten der Swift-Bucket-Platzierung Edit source

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

21.12.5 Verwenden von Speicherklassen Edit source

Alle Platzierungsziele umfassen eine Speicherklasse STANDARD, die standardmäßig auf neue Objekte angewendet wird. Diesen Standardwert können Sie mit default_storage_class überschreiben.

Soll ein Objekt in einer nicht standardmäßigen Speicherklasse erstellt werden, geben Sie den Namen dieser Speicherklasse in einem HTTP-Header in der Anforderung an. Das S3-Protokoll greift auf den Header X-Amz-Storage-Class zurück, das Swift-Protokoll dagegen auf den Header X-Object-Storage-Class.

In S3 Object Lifecycle Management können Sie Objektdaten zwischen Speicherklassen mithilfe von Transition-Aktionen verschieben.

21.13 Object Gateways an mehreren Standorten Edit source

Ceph unterstützt verschiedene Optionen zur Konfiguration für mehrere Standorte für das Ceph Object Gateway:

Mehrere Zonen

Eine Konfiguration, die aus einer Zonengruppe und mehreren Zonen besteht, jede Zone mit einer oder mehreren ceph-radosgw-Instanzen. Jede Zone wird durch einen eigenen Ceph Storage Cluster unterstützt. Mehrere Zonen in einer Zonengruppe bieten eine Disaster Recovery für die Zonengruppe, wenn in einer der Zonen ein erheblicher Fehler auftritt. Jede Zone ist aktiv und kann Schreibvorgänge empfangen. Neben der Disaster Recovery können mehrere aktive Zonen auch als Grundlage für Content Delivery Networks dienen.

Mehrfach-Zonengruppe

Ceph Object Gateway unterstützt mehrere Zonengruppen, jede Zonengruppe mit einer oder mehreren Zonen. Objekte, die in Zonen in einer Zonengruppe innerhalb desselben Bereichs wie eine andere Zonengruppe gespeichert sind, teilen sich einen globalen Objekt-Namespace, wodurch eindeutige Objekt-IDs über Zonengruppen und Zonen hinweg gewährleistet werden.

Anmerkung
Anmerkung

Es ist wichtig, zu beachten, dass Zonengruppen Metadaten nur untereinander synchronisieren. Daten und Metadaten werden zwischen den Zonen innerhalb der Zonengruppe repliziert. Es werden keine Daten oder Metadaten über einen Bereich hinweg gemeinsam genutzt.

Mehrere Bereiche

Ceph Object Gateway unterstützt das Konzept der Bereiche; ein global eindeutiger Namespace. Es werden mehrere Bereiche unterstützt, die einzelne oder mehrere Zonengruppen umfassen können.

Sie können jedes Object Gateway so konfigurieren, dass es in einer Aktiv/Aktiv-Zonenkonfiguration arbeitet und Schreibvorgänge in Nicht-Master-Zonen zulässt. Die Konfiguration für mehrere Standorte wird in einem Container gespeichert, der Bereich genannt wird. Der Bereich speichert Zonengruppen, Zonen und einen Zeitraum mit mehreren Epochen zur Verfolgung von Änderungen an der Konfiguration. Die rgw-Daemons übernehmen die Synchronisierung, so dass kein separater Synchronisierungsagent erforderlich ist. Dieser Ansatz zur Synchronisierung ermöglicht es dem Ceph Object Gateway, mit einer Aktiv/Aktiv-Konfiguration anstelle von Aktiv/Passiv zu arbeiten.

21.13.1 Anforderungen und Annahmen Edit source

Für eine Konfiguration für mehrere Standorte sind mindestens zwei Ceph-Speichercluster erforderlich sowie mindestens zwei Ceph Object-Gateway-Instanzen, eine für jeden Ceph-Speichercluster. Die folgende Konfiguration setzt voraus, dass sich mindestens zwei Ceph-Speichercluster an geografisch getrennten Standorten befinden. Die Konfiguration kann jedoch am gleichen Standort funktionieren. Zum Beispiel mit den Namen rgw1 und rgw2.

Für eine Konfiguration für mehrere Standorte sind eine Master-Zonengruppe und eine Master-Zone erforderlich. Eine Master-Zone ist die Quelle der Wahrheit in Bezug auf alle Metadatenoperationen in einem Cluster mit mehreren Standorten. Zusätzlich benötigt jede Zonengruppe eine Master-Zone. Zonengruppen können eine oder mehrere Neben- oder Nicht-Master-Zonen umfassen. In dieser Anleitung dient der Host rgw1 als Master-Zone der Master-Zonengruppe und der Host rgw2 als sekundäre Zone der Master-Zonengruppe.

21.13.2 Konfigurieren einer Master-Zone Edit source

Alle Gateways in einer Konfiguration für mehrere Standorte rufen ihre Konfiguration von einem ceph-radosgw-Daemon auf einem Host innerhalb der Master-Zonengruppe und der Master-Zone ab. Wählen Sie zur Konfiguration Ihrer Gateways in einer Konfiguration für mehrere Standorte eine ceph-radosgw-Instanz aus, um die Master-Zonengruppe und die Master-Zone zu konfigurieren.

21.13.2.1 Erstellen eines Bereichs Edit source

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
Anmerkung

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

21.13.2.2 Erstellen einer Master-Zonengruppe Edit source

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

21.13.2.3 Erstellen einer Master-Zone Edit source

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

21.13.2.4 Löschen der Standardzone und -gruppe Edit source

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

21.13.2.5 Erstellen von Systembenutzern Edit source

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

21.13.2.6 Aktualisieren Sie den Zeitraum mit Edit source

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
Anmerkung

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

21.13.2.7 Starten des Gateways Edit source

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

21.13.3 Konfigurieren sekundärer Zonen Edit source

In den Zonen einer Zonengruppe werden alle Daten reproduziert, sodass gewährleistet ist, dass alle Zonen dieselben Daten umfassen. Beim Erstellen der sekundären Zone führen Sie alle nachfolgenden Operationen auf einem Host aus, der für die sekundäre Zone vorgesehen ist.

Anmerkung
Anmerkung

Gehen Sie zum Hinzufügen einer dritten Zone genauso vor wie beim Hinzufügen der zweiten Zone. Verwenden Sie einen anderen Zonennamen.

Wichtig
Wichtig

Sie müssen Metadatenvorgänge, wie beispielsweise die Erstellung von Benutzern, auf einem Host innerhalb der Master-Zone ausführen. Die Master-Zone und die sekundäre Zone können Bucket-Vorgänge empfangen, doch die sekundäre Zone leitet Bucket-Vorgänge an die Master-Zone weiter. Wenn die Master-Zone inaktiv ist, schlagen Bucket-Vorgänge fehl.

21.13.3.1 Importieren des Bereichs Edit source

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

21.13.3.2 Erstellen einer sekundären Zone Edit source

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

21.13.3.3 Aktualisieren der Ceph-Konfigurationsdatei Edit source

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

21.13.3.4 Aktualisieren des Zeitraums Edit source

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
Anmerkung

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

21.13.3.5 Starten des Object Gateways Edit source

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

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

21.13.3.6 Prüfen des Synchronisierungsstatus Edit source

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

21.13.4 Allgemeine Objekt-Gateway-Wartung Edit source

21.13.4.1 Prüfen des Synchronisierungsstatus Edit source

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

21.13.4.2 Ändern der Metadaten-Master-Zone Edit source

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

21.13.5 Durchführen von Failover und Disaster Recovery Edit source

Falls die Master-Zone ausfällt, führen Sie zum Zweck eines Disaster Recovery ein Failover zur sekundären Zone durch.

  1. Machen Sie die sekundäre Zone zur Master- und Standardzone. Beispiel:

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

    Standardmäßig wird das Ceph Object Gateway in einer Aktiv/Aktiv-Konfiguration ausgeführt. Wenn der Cluster zur Ausführung in einer Aktiv/Passiv-Konfiguration konfiguriert wurde, ist die sekundäre Zone eine schreibgeschützte Zone. Entfernen Sie den Status ‑‑read-only, damit die Zone Schreibvorgänge empfangen kann. Beispiel:

    cephuser@adm > radosgw-admin zone modify --rgw-zone=ZONE-NAME --master --default \
                                                       --read-only=false
  2. Aktualisieren Sie die Periode, damit die Änderungen wirksam werden:

    cephuser@adm > radosgw-admin period update --commit
  3. Starten Sie das Ceph Object Gateway neu:

    cephuser@adm > ceph orch restart rgw

Wenn die frühere Master-Zone wiederhergestellt ist, setzen Sie die Operation zurück.

  1. Rufen Sie in der wiederhergestellten Zone den Zeitraum von der aktuellen Master-Zone ab.

    cephuser@adm > radosgw-admin realm pull --url=URL-TO-MASTER-ZONE-GATEWAY \
                               --access-key=ACCESS-KEY --secret=SECRET
  2. Machen Sie die wiederhergestellte Zone zur Master- und Standardzone:

    cephuser@adm > radosgw-admin zone modify --rgw-zone=ZONE-NAME --master --default
  3. Aktualisieren Sie die Periode, damit die Änderungen wirksam werden:

    cephuser@adm > radosgw-admin period update --commit
  4. Starten Sie das Ceph Object Gateway in der wiederhergestellten Zone neu:

    cephuser@adm > ceph orch restart rgw@rgw
  5. Wenn die sekundäre Zone eine schreibgeschützte Konfiguration sein muss, aktualisieren Sie die sekundäre Zone:

    cephuser@adm > radosgw-admin zone modify --rgw-zone=ZONE-NAME --read-only
  6. Aktualisieren Sie die Periode, damit die Änderungen wirksam werden:

    cephuser@adm > radosgw-admin period update --commit
  7. Starten Sie das Ceph Object Gateway in der sekundären Zone neu:

    cephuser@adm > ceph orch restart@rgw
Diese Seite drucken