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

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

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

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

17.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: DNS-fähige Bucket-Namen verwenden

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.

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

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

17.2 Bereitstellen des Object Gateways Edit source

Wir empfehlen die Bereitstellung des Ceph Object Gateway über die DeepSea-Infrastruktur durch Hinzufügen der relevanten role-rgw [...]-Zeile(n) in der policy.cfg-Datei am Salt Master und Ausführen der erforderlichen DeepSea-Phasen.

17.3 Ausführen des Object Gateway Service Edit source

Der Object Gateway-Service wird mit dem Kommando systemctl ausgeführt. Zur Ausführung des Object Gateway Service benötigen Sie root-Berechtigungen. Beachten Sie, dass gateway_host der Hostname des Servers ist, dessen Object Gateway-Instanz ausgeführt werden muss.

Für den Object Gateway Service werden die folgenden Unterkommandos unterstützt:

systemctl status ceph-radosgw@rgw.GATEWAY_HOST

Gibt die Statusinformationen des Service aus.

systemctl start ceph-radosgw@rgw.GATEWAY_HOST

Startet den Service, sofern er noch nicht ausgeführt wird.

systemctl restart ceph-radosgw@rgw.GATEWAY_HOST

Startet den Service neu.

systemctl stop ceph-radosgw@rgw.GATEWAY_HOST

Stoppt den aktiven Service.

systemctl enable ceph-radosgw@rgw.GATEWAY_HOST

Aktiviert den Service, sodass er automatisch bei Systemstart gestartet wird.

systemctl disable ceph-radosgw@rgw.GATEWAY_HOST

Deaktiviert den Service, sodass er nicht automatisch bei Systemstart gestartet wird.

17.4 Konfigurationsoptionen Edit source

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

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

17.5.1 Zugreifen auf Object Gateway Edit source

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

17.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 Installation des Pakets müssen Sie das Modul aktivieren und das Software Repository aktualisieren:

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

Oder

root # SUSEConnect -p sle-module-public-cloud/15/x86_64
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 17.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

17.5.2 Verwalten von S3- und Swift-Konten Edit source

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

Benutzer können auch über die DeepSea-Datei rgw.sls hinzugefügt werden. Ein Beispiel finden Sie in Abschnitt 21.3.1, „Verschiedene Object Gateway-Benutzer für NFS Ganesha“.

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.

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

    Beispiel:

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

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

    Beispiel:

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

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

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

Beispiel:

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

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

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

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

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

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

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

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

17.5.2.4 Verwaltung des Benutzerkontingents 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 eines Benutzerkontingents müssen Sie zunächst dessen Parameter festlegen:

cephadm@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 Quota gelten für Buckets, die ein Benutzer besitzt. Benutzerkontingente gelten für einen Benutzer.

Sobald Sie ein Benutzerkontingent festgelegt haben, können Sie es aktivieren:

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

So deaktivieren Sie ein Kontingent:

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

So listen Sie Kontingenteinstellungen auf:

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

So aktualisieren Sie die Kontingentstatistik:

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

17.6 HTTP-Front-End 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 Sie mit der Option rgw_frontends in der Datei /etc/ceph/ceph.conf konfigurieren. Unter Abschnitt 16.3, „Ceph Object Gateway“ finden Sie eine Liste der Konfigurationsoptionen.

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

Zur Aktivierung der standardmäßigen Object Gateway-Rolle für die sichere Kommunikation über SSL benötigen Sie entweder ein von einer Zertifizierungsstelle ausgestelltes Zertifikat oder Sie müssen ein selbstsigniertes Zertifikat erstellen. Zum Konfigurieren eines Object Gateway mit aktiviertem HTTPs sind zwei Methoden verfügbar: die eine nutzt die Standardeinstellungen, die andere erweiterte Methode ermöglicht die Feinabstimmung der Einstellungen für HTTPS.

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

Standardmäßig erwartet DeepSea die Zertifikatsdatei am Salt Master unter/srv/salt/ceph/rgw/cert/rgw.pem. Es verteilt dann das Zertifikat an /etc/ceph/rgw.pem am Salt Minion mit der Object Gateway-Rolle, wo es von Ceph gelesen wird.

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 /srv/salt/ceph/rgw/cert/rgw.pem
  3. Hängen Sie den Schlüssel an die Zertifikatsdatei an:

    root@master # cat rgw.key >> /srv/salt/ceph/rgw/cert/rgw.pem

17.7.2 Einfache HTTPS-Konfiguration Edit source

Standardmäßig liest Ceph im Object Gateway Node das Zertifikat/etc/ceph/rgw.pem und verwendet Port 443 für die sichere SSL-Kommunikation. Wenn Sie diese Werte nicht ändern müssen, führen Sie die folgenden Schritte aus:

  1. Bearbeiten Sie /srv/pillar/ceph/stack/global.yml und fügen Sie folgende Zeile hinzu:

    rgw_init: default-ssl
  2. Kopieren Sie die standardmäßige Object Gateway SSL-Konfiguration in das Unterverzeichnis ceph.conf.d:

    root@master # cp /srv/salt/ceph/configuration/files/rgw-ssl.conf \
     /srv/salt/ceph/configuration/files/ceph.conf.d/rgw.conf
  3. Führen Sie die DeepSea-Phasen 2, 3 und 4 aus, um die Änderungen anzuwenden:

    root@master # salt-run state.orch ceph.stage.2
    root@master # salt-run state.orch ceph.stage.3
    root@master # salt-run state.orch ceph.stage.4

17.7.3 Erweiterte HTTPS-Konfiguration Edit source

Führen Sie folgende Schritte aus, wenn Sie die Standardwerte für SSL-Einstellungen des Object Gateways ändern müssen:

  1. Bearbeiten Sie /srv/pillar/ceph/stack/global.yml und fügen Sie folgende Zeile hinzu:

    rgw_init: default-ssl
  2. Kopieren Sie die standardmäßige Object Gateway SSL-Konfiguration in das Unterverzeichnis ceph.conf.d:

    root@master # cp /srv/salt/ceph/configuration/files/rgw-ssl.conf \
     /srv/salt/ceph/configuration/files/ceph.conf.d/rgw.conf
  3. Bearbeiten Sie /srv/salt/ceph/configuration/files/ceph.conf.d/rgw.conf und ändern Sie die Standardoptionen, wie Portnummer oder Pfad zum SSL-Zertifikat entsprechend Ihrer Einrichtung.

  4. Führen Sie die DeepSea-Phasen 3 und 4 aus, um die Änderungen anzuwenden:

    root@master # salt-run state.orch ceph.stage.3
    root@master # salt-run state.orch ceph.stage.4
Tipp
Tipp: Bindung an mehrere Ports

Der CivetWeb Server kann eine Bindung zu mehreren Ports herstellen. Dies ist nützlich, wenn Sie sowohl mit SSL-Verbindung als auch mit Nicht-SSL-Verbindung auf eine einzelne Object Gateway-Instanz zugreifen müssen. Die Zeile für eine Zwei-Port-Konfiguration entspricht dem folgenden Beispiel:

[client.{{ client }}]
rgw_frontends = beast port=80 ssl_port=443 ssl_certificate=/etc/ceph/rgw.pem

17.8 Synchronisierungsmodule Edit source

Die Object Gateway-Funktion für mehrere Standorte ermöglicht die Erstellung mehrerer Zonen und die Spiegelung der Daten und Metadaten zwischen diesen Zonen. 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.

17.8.1 Allgemeine Konfiguration Edit source

Alle Synchronisierungsmodule werden auf ähnliche Weise konfiguriert. Sie müssen eine neue Zone erstellen (weitere Informationen siehe Abschnitt 17.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:

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

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

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

cephadm@adm > radosgw-admin zone modify --rgw-zonegroup=ZONE-GROUP-NAME \
 --rgw-zone=ZONE-NAME \
 --tier-config=profiles[].source_bucket=PREFIX'*'
cephadm@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.

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

17.8.2.1 Anforderungen und Annahmen Edit source

Nehmen wir eine einfache Konfiguration für mehrere Standorte an, wie in Abschnitt 17.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.

17.8.2.2 Konfigurieren von Synchronisierungsmodulen Edit source

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

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

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

    cephadm@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 17.8.3, „Synchronisierungsmodul ElasticSearch“.

  4. Aktualisieren Sie schließlich den Zeitraum:

    cephadm@adm > radosgw-admin period update --commit
  5. Starten Sie nun „radosgw“ in der Zone:

    root # systemctl start ceph-radosgw@rgw.`hostname -s`
    root # systemctl enable ceph-radosgw@rgw.`hostname -s`

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

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

Passwort

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

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

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

17.8.4.1 Allgemeine Konfiguration 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 17.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 17.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.

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

17.8.5 Archiv-Synchronisierungsmodul Edit source

Das Archiv-Synchronisierungsmodul greift auf die Versionierungsfunktion von S3-Objekten im Object Gateway zurück. 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.

17.8.5.1 Konfiguration Edit source

Tipp
Tipp: Weitere Informationen

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

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

Zur Nutzung des Archivmoduls erstellen Sie eine neue Zone mit dem Schichttyp archive:

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

17.9 LDAP-Authentifizierung Edit source

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

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

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

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

Die folgenden Parameter in der Konfigurationsdatei /etc/ceph/ceph.conf 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 17.9.4, „Verwenden eines benutzerdefinierten Suchfilters zur Begrenzung des Benutzerzugriffs“.

17.9.4 Verwenden eines benutzerdefinierten Suchfilters zur Begrenzung des Benutzerzugriffs Edit source

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

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

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

17.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 17.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"
cephadm@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.

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

17.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 17.10.1.1, „Dynamisches Resharding“) oder ein manuelles Offline-Resharding des Bucket-Index (Informationen hierzu finden Sie in Abschnitt 17.10.1.2, „Manuelles Resharding“).

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

Wichtig
Wichtig: Konfigurationen für mehrere Standorte

Das dynamische Resharding wird nicht in Umgebungen mit mehreren Standorten unterstützt. Es ist zwar seit Ceph 12.2.2 standardmäßig deaktiviert, doch wir empfehlen, die Einstellungen gegenzuprüfen.

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

17.10.1.2 Manuelles Resharding Edit source

Das in Abschnitt 17.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:

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

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

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

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

     cephadm@adm > radosgw-admin 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. Notieren Sie sich die alte Bucket-ID. Sie benötigen Sie zum endgültigen Löschen der alten Bucket-Indexobjekte.

  4. Verifizieren Sie, dass die Objekte korrekt aufgelistet sind. Vergleichen Sie dazu die Auflistung des alten Bucket-Index mit der neuen. Löschen Sie dann die alten Bucket-Indexobjekte:

    cephadm@adm > radosgw-admin bi purge
     --bucket=BUCKET_NAME
     --bucket-id=OLD_BUCKET_ID

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

17.10.2.1 Einfache Konfigurationen Edit source

  1. Öffnen Sie die Ceph-Konfigurationsdatei und fügen Sie die folgende Option hinzu oder bearbeiten Sie sie:

    rgw_override_bucket_index_max_shards = 12
    Tipp
    Tipp: Alle oder eine Object Gateway-Instanz

    Fügen Sie zum Konfigurieren eines Bucket-Index-Shardings für alle Instanzen des Object Gateways rgw_override_bucket_index_max_shards im Abschnitt[global] ein.

    Fügen Sie zum Konfigurieren eines Bucket-Index-Shardings nur für eine Instanz des Object Gateways rgw_override_bucket_index_max_shards im Abschnitt der entsprechenden Instanz ein.

  2. Starten Sie das Object Gateway neu. Weitere Einzelheiten finden Sie in Abschnitt 17.3, „Ausführen des Object Gateway Service“.

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

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

    cephadm@adm > radosgw-admin zonegroup set < zonegroup.json
  4. Aktualisieren Sie den Zeitraum mit:

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

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

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

17.11.2 Konfigurieren des Ceph Object Gateways Edit source

17.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 Node, 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.

17.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. Der Berechtigungsnachweis des Service-Mandanten sollte über Verwaltungsrechte verfügen. Weitere detaillierte Informationen finden Sie in der offiziellen Dokumentation zu OpenStack Keystone. 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.

17.12 Poolplatzierung und Speicherklassen Edit source

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

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

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

17.12.3 Zonengruppen-/Zonenkonfiguration 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:

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

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

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

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

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

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

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

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

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

17.12.4 Anpassen der Platzierung Edit source

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

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

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

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

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

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

17.12.4.4 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

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

17.13 Object Gateways an mehreren Standorten Edit source

Zone

Eine logische Gruppierung einer oder mehrerer Object Gateway-Instanzen. Eine Zone muss als Master-Zone in einer Zonengruppe ausgewiesen sein. In ihr werden alle Buckets und Benutzer erstellt.

Zonengruppe

Eine Zonengruppe besteht aus mehreren Zonen. Es sollte eine Master-Zonengruppe vorhanden sein, in der Änderungen an der Systemkonfiguration vorgenommen werden.

Zonengruppenzuordnung

Eine Konfigurationsstruktur mit den Zuordnungen des gesamten Systems, wie zum Beispiel welche Zonengruppe der Master ist, die Beziehungen zwischen verschiedenen Zonengruppen und bestimmte Konfigurationsoptionen wie die Speicherrichtlinien.

Bereich

Ein Container für Zonengruppen. Bereiche ermöglichen die Trennung von Zonengruppen zwischen Clustern. Es ist möglich, mehrere Bereiche zu erstellen. Dies erleichtert die Ausführung vollständig verschiedener Konfigurationen im selben Cluster.

Periode

Eine Periode enthält die Konfigurationsstruktur für den aktuellen Zustand des Bereichs. Jede Periode enthält eine eindeutige ID und eine Epoche. Jedem Bereich ist eine aktuelle Periode zugeordnet, die den aktuellen Zustand der Konfiguration der Zonengruppen und Speicherrichtlinien enthält. Durch jede Konfigurationsänderung für eine Nicht-Master-Zone wird die Epoche der Periode schrittweise erhöht. Die Änderung der Master-Zone in eine andere Zone löst folgende Änderungen aus:

  • Eine neue Periode wird generiert mit einer neuen Perioden-ID und der Epoche 1.

  • Die aktuelle Periode des Bereichs wird aktualisiert, um auf die neu generierte Perioden-ID zu zeigen.

  • Die Epoche des Bereichs wird schrittweise erhöht.

Sie können jedes Object Gateway so konfigurieren, dass es Teil einer Verbundarchitektur ist. Dadurch arbeitet es in einer aktiven Zonenkonfiguration und lässt zugleich Schreibvorgänge in Nicht-Master-Zonen zu.

17.13.1 Terminologie Edit source

Nachfolgend sehen Sie eine Beschreibung der spezifischen Begriffe einer Verbundarchitektur:

17.13.2 Beispiel einer Cluster-Einrichtung Edit source

In diesem Beispiel konzentrieren wir uns auf die Erstellung einer einzelnen Zonengruppe mit drei separaten Zonen, die aktiv deren Daten synchronisieren. Zwei Zonen gehören zum selben Cluster, die dritte Zone gehört zu einem anderen Cluster. Zum Spiegeln von Datenänderungen zwischen Object Gateways wird kein Synchronisierungsagent herangezogen. Dies ermöglicht ein viel einfacheres Konfigurationsschema und Aktiv/Aktiv-Konfigurationen. Beachten Sie, dass Metadatenoperationen wie die Erstellung eines neuen Benutzers weiterhin in der Master-Zone durchgeführt werden müssen. Datenoperationen wie die Erstellung von Buckets und Objekten können jedoch von jeder anderen Zone verarbeitet werden.

17.13.3 Systemschlüssel Edit source

Beim Konfigurieren von Zonen erwartet das Object Gateway die Erstellung eines S3-kompatiblen Systembenutzers zusammen mit dessen Zugriffsschlüssel und geheimen Schlüssel. Dadurch kann eine andere Object Gateway-Instanz die Konfiguration mit dem Zugriffsschlüssel und geheimen Schlüssel entfernt abrufen. Weitere Informationen zum Erstellen von S3-Benutzern finden Sie in Abschnitt 17.5.2.1, „Hinzufügen von S3- und Swift-Benutzern“.

Tipp
Tipp

Es ist nützlich, vor der Zonenerstellung zunächst den Zugriffsschlüssel und den geheimen Schlüssel zu generieren, weil dies später die Skripterstellung und Verwendung der Konfigurationsverwaltungswerkzeuge erleichtert.

Nehmen wir für dieses Beispiel an, dass der Zugriffsschlüssel und der geheime Schlüssel in den Umgebungsvariablen festgelegt werden:

# SYSTEM_ACCESS_KEY=1555b35654ad1656d805
# SYSTEM_SECRET_KEY=h7GhxuBLTrlhVUyxSPUKUV8r/2EI4ngqJxD7iBdBYLhwluN30JaT3Q==

Im Allgemeinen umfassen Zugriffsschlüssel 20 alphanumerische Zeichen. Geheime Schlüssel bestehen aus 40 alphanumerischen Zeichen (sie dürfen auch die Zeichen +/= enthalten). Diese Schlüssel werden in der Kommandozeile generiert:

# SYSTEM_ACCESS_KEY=$(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 20 | head -n 1)
# SYSTEM_SECRET_KEY=$(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 40 | head -n 1)

17.13.4 Benennungskonventionen Edit source

In diesem Beispiel wird die Einrichtung einer Master-Zone erläutert. Wir nehmen eine Zonengruppe namens us für die USA an. Diese Zonengruppe stellt unsere Master-Zonengruppe dar. Sie enthält zwei Zonen im Format ZONENGRUPPE-ZONE. Diese Konvention ist nur ein Vorschlag unsererseits. Sie können jedes beliebige Format wählen. Zusammenfassung:

  • Master-Zonengruppe: USA us

  • Master-Zone: USA, Region Osten 1: us-east-1

  • Sekundäre Zone: USA, Region Osten 2: us-east-2

  • Sekundäre Zone: USA, Region Westen: us-west

Dies ist Teil eines größeren Bereichs namens gold. Die Zonen us-east-1 und us-east-2 sind Teil des selben Ceph Clusters, us-east-1 ist die primäre Zone. us-west befindet sich in einem anderen Ceph Cluster.

17.13.5 Standard-Pools Edit source

Wenn Object Gateway mit den entsprechenden Berechtigungen konfiguriert ist, erstellt es selbständig Standard-Pools. Die Werte für pg_num und pgp_num werden der Konfigurationsdatei ceph.conf entnommen. Pools, die sich auf eine Zone beziehen, folgen der Benennungskonvention ZONE-NAME.POOL-NAME. Für die Zone us-east-1 sind es beispielsweise die folgenden Pools:

.rgw.root
us-east-1.rgw.control
us-east-1.rgw.data.root
us-east-1.rgw.gc
us-east-1.rgw.log
us-east-1.rgw.intent-log
us-east-1.rgw.usage
us-east-1.rgw.users.keys
us-east-1.rgw.users.email
us-east-1.rgw.users.swift
us-east-1.rgw.users.uid
us-east-1.rgw.buckets.index
us-east-1.rgw.buckets.data
us-east-1.rgw.meta

Diese Pools können auch in anderen Zonen erstellt werden, indem us-east-1 durch den entsprechenden Zonennamen ersetzt wird.

17.13.6 Erstellen eines Bereichs Edit source

Konfigurieren Sie einen Bereich namens gold und machen Sie ihn zum Standardbereich:

cephadm@adm > radosgw-admin realm create --rgw-realm=gold --default
{
  "id": "4a367026-bd8f-40ee-b486-8212482ddcd7",
  "name": "gold",
  "current_period": "09559832-67a4-4101-8b3f-10dfcd6b2707",
  "epoch": 1
}

Beachten Sie, dass jeder Bereich eine ID hat, was für Flexibilität sorgt, beispielsweise beim späteren Umbenennen des Bereichs. Die current_period (aktuelle Periode) ändert sich, sobald wir eine Änderung in der Master-Zone vornehmen. Die epoch (Epoche) wird schrittweise erhöht, wenn eine Änderung an der Konfiguration der Master-Zone vorgenommen wird, was zu einer Änderung der aktuellen Periode führt.

17.13.7 Löschen der Standard-Zonengruppe Edit source

Die Standardinstallation von Object Gateway erstellt die Standard-Zonengruppe namens default. Entfernen Sie die Standard-Zonengruppe, da wir sie nicht länger benötigen.

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

17.13.8 Erstellen einer Master-Zonengruppe Edit source

Erstellen Sie eine Master-Zonengruppe namens us. Die Zonengruppe verwaltet die Zonengruppen-Zuordnungen und verteilt die Änderungen auf das restliche System. Durch Kennzeichnen der Zonengruppe als Standard lassen Sie ausdrücklich die Nennung des RGW-Zonengruppen-Schalters für spätere Kommandos zu.

cephadm@adm > radosgw-admin zonegroup create --rgw-zonegroup=us \
--endpoints=http://rgw1:80 --master --default
{
  "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"
}

Alternativ können Sie mit folgendem Kommando eine Zonengruppe als Standard kennzeichnen:

cephadm@adm > radosgw-admin zonegroup default --rgw-zonegroup=us

17.13.9 Erstellen einer Master-Zone Edit source

Erstellen Sie nun eine Standardzone und fügen Sie diese zur Standard-Zonengruppe hinzu. Beachten Sie, dass Sie diese Zone für Metadatenoperationen wie die Benutzererstellung verwenden:

cephadm@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
{
  "id": "83859a9a-9901-4f00-aa6d-285c777e10f0",
  "name": "us-east-1",
  "domain_root": "us-east-1/gc.rgw.data.root",
  "control_pool": "us-east-1/gc.rgw.control",
  "gc_pool": "us-east-1/gc.rgw.gc",
  "log_pool": "us-east-1/gc.rgw.log",
  "intent_log_pool": "us-east-1/gc.rgw.intent-log",
  "usage_log_pool": "us-east-1/gc.rgw.usage",
  "user_keys_pool": "us-east-1/gc.rgw.users.keys",
  "user_email_pool": "us-east-1/gc.rgw.users.email",
  "user_swift_pool": "us-east-1/gc.rgw.users.swift",
  "user_uid_pool": "us-east-1/gc.rgw.users.uid",
  "system_key": {
      "access_key": "1555b35654ad1656d804",
      "secret_key": "h7GhxuBLTrlhVUyxSPUKUV8r\/2EI4ngqJxD7iBdBYLhwluN30JaT3Q=="
  },
  "placement_pools": [
      {
          "key": "default-placement",
          "val": {
              "index_pool": "us-east-1/gc.rgw.buckets.index",
              "data_pool": "us-east-1/gc.rgw.buckets.data",
              "data_extra_pool": "us-east-1/gc.rgw.buckets.non-ec",
              "index_type": 0
          }
      }
  ],
  "metadata_heap": "us-east-1/gc.rgw.meta",
  "realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7"
}

Beachten Sie, dass die Schalter --rgw-zonegroup und --default die Zone zu einer Zonengruppe hinzufügen und diese zur Standardzone machen. Alternativ ist dies auch mit folgendem Kommando möglich:

cephadm@adm > radosgw-admin zone default --rgw-zone=us-east-1
cephadm@adm > radosgw-admin zonegroup add --rgw-zonegroup=us --rgw-zone=us-east-1

17.13.9.1 Erstellen von Systembenutzern Edit source

Für den Zugriff auf Zonen-Pools müssen Sie einen Systembenutzer erstellen. Beachten Sie, dass Sie diese Schlüssel auch zum Konfigurieren der sekundären Zone benötigen.

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

17.13.9.2 Aktualisieren der Periode Edit source

Da Sie die Konfiguration der Master-Zone geändert haben, müssen Sie die Änderungen für sie übernehmen, damit sie in der Konfigurationsstruktur des Bereichs wirksam werden. Zu Beginn sieht die Periode folgendermaßen aus:

cephadm@adm > radosgw-admin period get
{
  "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
}

Aktualisieren Sie die Periode und übernehmen Sie die Änderungen:

cephadm@adm > radosgw-admin period update --commit
{
  "id": "b5e4d3ec-2a62-4746-b479-4b2bc14b27d1",
  "epoch": 1,
  "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"
                  }
              ],
              "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
          }
      ]
  },
  "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
}

17.13.9.3 Starten des Object Gateways Edit source

Sie müssen vor dem Starten des Object Gateways die Zonen- und Port-Optionen für das Object Gateway in der Konfigurationsdatei angeben. Weitere Informationen zu Object Gateway und dessen Konfiguration finden Sie in Kapitel 17, Ceph Object Gateway. Der Konfigurationsabschnitt von Object Gateway sollte in etwas wie folgt aussehen:

[client.rgw.us-east-1]
rgw_frontends="beast port=80"
rgw_zone=us-east-1

Starten Sie das Object Gateway:

root # systemctl start ceph-radosgw@rgw.us-east-1

17.13.10 Erstellen einer sekundären Zone 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.

Erstellen und konfigurieren Sie die sekundäre Zone us-east-2 im sekundären Cluster. Sie können alle folgenden Kommandos im Node ausführen, in dem die Master-Zone selbst gehostet wird.

Erstellen Sie die sekundäre Zone mit dem selben Kommando, mit dem Sie auch die primäre Zone erstellt haben, lassen Sie dabei jedoch die Master-Flagge weg:

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

17.13.10.1 Aktualisieren der Periode Edit source

Informieren Sie alle Gateways über die neue Änderung in der Systemzuordnung. Aktualisieren Sie dazu die Periode und übernehmen Sie die Änderungen:

cephadm@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
}

17.13.10.2 Starten des Object Gateways Edit source

Passen Sie die Konfiguration des Object Gateways für die sekundäre Zone an und starten Sie sie:

[client.rgw.us-east-2]
rgw_frontends="beast port=80"
rgw_zone=us-east-2
cephadm@adm > sudo systemctl start ceph-radosgw@rgw.us-east-2

17.13.10.3 Aktualisieren der Ceph Dashboard-Konfiguration Edit source

  1. Mit folgendem Kommando aktualisieren Sie Ihre Dashboard-Konfiguration für mehrere Standorte anhand der Variablen mit den geheimen Schlüsseln und den Zugriffsschlüsseln:

    cephadm@adm > ceph dashboard set-rgw-api-access-key ACCESS-KEY
    cephadm@adm > ceph dashboard set-rgw-api-secret-key SECRET-KEY
  2. Stellen Sie den Dashboard-Standardwert auf admin ein:

    cephadm@adm > ceph dashboard set-rgw-api-user-id admin
  3. Deaktivieren und reaktivieren Sie das Dashboard, sodass die Einstellungen übernommen werden.

    cephadm@adm > ceph mgr module disable dashboard
    cephadm@adm >  ceph mgr module enable dashboard
  4. Wenn der Object Gateway-Node geändert wurde oder ein Lastausgleich anstelle der Object Gateways verwendet wird, aktualisieren Sie das Dashboard:

    cephadm@adm > dashboard set-rgw-api-host HOST
    cephadm@adm > dashboard set-rgw-api-port PORT

17.13.11 Hinzufügen von Object Gateway zum sekundären Cluster Edit source

Der zweite Ceph Cluster gehört zur selben Zonengruppe wie der erste, kann sich jedoch geografisch an einem anderen Ort befinden.

17.13.11.1 Standard-Bereich und -Zonengruppe Edit source

Da Sie bereits den Bereich für das erste Gateway erstellt haben, ziehen Sie den Bereich hierher und machen Sie es hier zum Standard:

cephadm@adm > radosgw-admin realm pull --url=http://rgw1:80 \
--access-key=$SYSTEM_ACCESS_KEY --secret=$SYSTEM_SECRET_KEY
{
  "id": "4a367026-bd8f-40ee-b486-8212482ddcd7",
  "name": "gold",
  "current_period": "b5e4d3ec-2a62-4746-b479-4b2bc14b27d1",
  "epoch": 2
}
cephadm@adm > radosgw-admin realm default --rgw-realm=gold

Rufen Sie die Konfiguration von der Master-Zone ab, indem Sie die Periode heranziehen:

cephadm@adm > radosgw-admin period pull --url=http://rgw1:80 \
--access-key=$SYSTEM_ACCESS_KEY --secret=$SYSTEM_SECRET_KEY

Legen Sie die Standard-Zonengruppe auf die bereits erstellte Zonengruppe us fest:

cephadm@adm > radosgw-admin zonegroup default --rgw-zonegroup=us

17.13.11.2 Konfiguration der sekundären Zone Edit source

Erstellen Sie eine neue Zone namens us-west mit denselben Systemschlüsseln:

cephadm@adm > radosgw-admin zone create --rgw-zonegroup=us --rgw-zone=us-west \
--access-key=$SYSTEM_ACCESS_KEY --secret=$SYSTEM_SECRET_KEY \
--endpoints=http://rgw3:80 --default
{
  "id": "950c1a43-6836-41a2-a161-64777e07e8b8",
  "name": "us-west",
  "domain_root": "us-west.rgw.data.root",
  "control_pool": "us-west.rgw.control",
  "gc_pool": "us-west.rgw.gc",
  "log_pool": "us-west.rgw.log",
  "intent_log_pool": "us-west.rgw.intent-log",
  "usage_log_pool": "us-west.rgw.usage",
  "user_keys_pool": "us-west.rgw.users.keys",
  "user_email_pool": "us-west.rgw.users.email",
  "user_swift_pool": "us-west.rgw.users.swift",
  "user_uid_pool": "us-west.rgw.users.uid",
  "system_key": {
      "access_key": "1555b35654ad1656d804",
      "secret_key": "h7GhxuBLTrlhVUyxSPUKUV8r\/2EI4ngqJxD7iBdBYLhwluN30JaT3Q=="
  },
  "placement_pools": [
      {
          "key": "default-placement",
          "val": {
              "index_pool": "us-west.rgw.buckets.index",
              "data_pool": "us-west.rgw.buckets.data",
              "data_extra_pool": "us-west.rgw.buckets.non-ec",
              "index_type": 0
          }
      }
  ],
  "metadata_heap": "us-west.rgw.meta",
  "realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7"
}

17.13.11.3 Aktualisieren der Periode Edit source

Um die Änderungen an der Zonengruppen-Zuordnung zu verteilen, aktualisieren und übernehmen wir die Periode:

cephadm@adm > radosgw-admin period update --commit --rgw-zone=us-west
{
  "id": "b5e4d3ec-2a62-4746-b479-4b2bc14b27d1",
  "epoch": 3,
  "predecessor_uuid": "09559832-67a4-4101-8b3f-10dfcd6b2707",
  "sync_status": [
      "", # truncated
  ],
  "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": "true",
                      "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"
                  },
                  {
                      "id": "d9522067-cb7b-4129-8751-591e45815b16",
                      "name": "us-west",
                      "endpoints": [
                          "http:\/\/rgw3: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
          },
          {
              "key": "d9522067-cb7b-4129-8751-591e45815b16",
              "val": 329470157
          }
      ]
  },
  "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
}

Beachten Sie, dass die Nummer der Perioden-Epoche um einen Schritt erhöht wurde, was eine Änderung in der Konfiguration angibt.

17.13.11.4 Starten des Object Gateways Edit source

Dieser Vorgang entspricht in etwa dem Starten des Object Gateways in der ersten Zone. Der einzige Unterschied besteht darin, dass die Object Gateway-Zonenkonfiguration den Zonennamen us-west enthalten sollte:

[client.rgw.us-west]
rgw_frontends="beast port=80"
rgw_zone=us-west

Starten Sie das zweite Object Gateway:

root # systemctl start ceph-radosgw@rgw.us-west

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

    cephadm@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 Schreiboperationen empfangen kann. Beispiel:

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

    cephadm@adm > radosgw-admin period update --commit
  3. Starten Sie schließlich das Ceph Object Gateway neu.

    root # systemctl restart ceph-radosgw@rgw.`hostname -s`

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

  1. Entnehmen Sie in der wiederhergestellten Zone die Periode aus der aktuellen Master-Zone.

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

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

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

    root # systemctl restart ceph-radosgw@rgw.`hostname -s`
  5. Wenn die sekundäre Zone eine schreibgeschützte Konfiguration sein muss, aktualisieren Sie die sekundäre Zone.

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

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

    root # systemctl restart ceph-radosgw@rgw.`hostname -s`

17.14 Lastausgleich an den Object Gateway Servern mit HAProxy Edit source

Mit dem HAProxy-Lastausgleich verteilen Sie alle Anforderungen auf mehrere Object Gateway Back-End-Server. Weitere detaillierte Informationen zum Konfigurieren von HAProxy finden Sie unter https://www.suse.com/documentation/sle-ha-15/book_sleha_guide/data/sec_ha_lb_haproxy.html.

Nachfolgend sehen Sie eine einfache Konfiguration von HAProxy zum Ausgleichen der Object Gateway Nodes mit Round-Robin als Ausgleichsalgorithmus:

tux > cat /etc/haproxy/haproxy.cfg
[...]
frontend HTTPS_FRONTEND
bind *:443 crt path-to-cert.pem [ciphers: ... ]
default_backend rgw

backend rgw
mode http
balance roundrobin
server rgw_server1 RGW-ENDPOINT1 weight 1 maxconn 100 check
server rgw_server2 RGW-ENDPOINT2 weight 1 maxconn 100 check
[...]
Diese Seite drucken