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

11 Ceph Object Gateway

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.

11.1 Object Gateway-Beschränkungen und Benennungseinschränkungen

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

11.1.1 Bucket-Einschränkungen

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.

11.1.2 Einschränkungen für gespeicherte Objekte

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.

11.1.3 HTTP-Header-Beschränkungen

Beschränkungen für HTTP-Header und Anforderungen hängen vom verwendeten Web-Frontend ab. Das standardmäßige CivetWeb beschränkt die Anzahl der HTTP-Header auf 64 und die Größe der HTTP-Header auf 16 KB.

11.2 Bereitstellen des Object Gateways

Wir empfehlen die Bereitstellung des Ceph Object Gateways ü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.

11.3 Ausführen des Object Gateway Service

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.

11.4 Konfigurationsparameter

Das Verhalten des Object Gateways lässt sich durch eine große Anzahl von Optionen in der ceph.conf-Datei beeinflussen. Nachfolgend sehen Sie eine Liste der wichtigsten Optionen: Eine vollständige Liste finden Sie unter http://docs.ceph.com/docs/master/radosgw/config-ref/.

rgw_thread_pool_size

Anzahl der Threads für den CivetWeb Server. Erhöhen Sie den Wert, wenn Sie mehr Anforderungen verarbeiten müssen. Der Standardwert ist 100 Threads.

rgw_num_rados_handles

Die Anzahl der RADOS Cluster-Zugriffsnummern (weitere Informationen finden Sie unter http://docs.ceph.com/docs/master/rados/api/librados-intro/#step-2-configuring-a-cluster-handle) für Object Gateway. Wenn Sie über eine konfigurierbare Anzahl von RADOS-Zugriffsnummern verfügen, wird die Leistung für alle Arten von Workloads erheblich verbessert. Jeder Object Gateway Worker-Thread würde nun eine RADOS-Zugriffsnummer für seine Gültigkeitsdauer auswählen müssen. Der Standardwert ist 1.

rgw_max_chunk_size

Die maximale Größe eines Datenblocks, der bei einer einzelnen Operation gelesen wird. Die Leistung bei der Verarbeitung von großen Objekten wird verbessert, wenn der Wert auf 4 MB (4194304) erhöht wird. Der Standardwert ist 128 KB (131072).

11.4.1 Weitere Hinweise

rgw dns name

Wenn der Parameter rgw dns name zur ceph.conf-Datei hinzugefügt wird, müssen Sie sicherstellen, dass der S3 Client so konfiguriert ist, dass er Anforderungen zum Endpunkt leitet, der durch rgw dns name angegeben ist.

11.5 Verwalten des Zugriffs auf Object Gateway

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.

11.5.1 Zugreifen auf Object Gateway

11.5.1.1 Zugriff auf die S3-Schnittstelle

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 11.5.2.1, „Hinzufügen von S3- und Swift-Benutzern“ zurückgegeben wurden.

  1. Installieren Sie das Paket phyton-boto:

    sudo 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}\t{created}".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

11.5.1.2 Zugriff auf die Swift-Schnittstelle

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 ist im "Public Cloud"-Modul für SUSE Linux Enterprise 12 SP3 enthalten. Vor Installation des Pakets müssen Sie das Modul aktivieren und das Software Repository aktualisieren:

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

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

sudo zypper in python-swiftclient

Beim Swift-Zugang wird die folgende Syntax verwendet:

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 11.5.2.1, „Hinzufügen von S3- und Swift-Benutzern“ ausgeführt wurde.

Beispiel:

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

Die Ausgabe ist:

my-new-bucket

11.5.2 Verwalten von S3- und Swift-Konten

11.5.2.1 Hinzufügen von S3- und Swift-Benutzern

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

    sudo radosgw-admin user create --uid=username \
     --display-name="display-name" --email=email

    Beispiel:

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

    sudo radosgw-admin subuser create --uid=uid \
     --subuser=uid \
     --access=[ read | write | readwrite | full ]

    Beispiel:

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

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

sudo radosgw-admin user create --uid=username \
 --display-name="display-name" --email=email

Beispiel:

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

11.5.2.2 Entfernen von S3- und Swift-Benutzern

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:

sudo radosgw-admin user rm --uid=example_user

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

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

11.5.2.3 Ändern des Zugriffs und der geheimen Schlüssel von S3- und Swift-Benutzern

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:

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

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

11.5.2.4 Verwaltung des Benutzerkontingents

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:

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

sudo radosgw-admin quota enable --quota-scope=user --uid=example_user

So deaktivieren Sie ein Kontingent:

sudo radosgw-admin quota disable --quota-scope=user --uid=example_user

So listen Sie Kontingenteinstellungen auf:

sudo radosgw-admin user info --uid=example_user

So aktualisieren Sie die Kontingentstatistik:

sudo radosgw-admin user stats --uid=example_user --sync-stats

11.6 Aktivieren von HTTPS/SSL für Object Gateways

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

11.6.1 Erstellen eines eigensignierten Zertifikats

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 Node generiert wird.

  1. Fügen Sie für alle Hostnamen, durch die Ihr Object Gateway erkannt werden soll, die Option subjectAltName zum Abschnitt [v3_req] der Datei /etc/ssl/openssl.cnf hinzu:

    [...]
    [ v3_req ]
    subjectAltName = ${ENV::SAN}
    [...]
  2. Erstellen Sie den Schlüssel und das Zertifikat mit openssl. Stellen Sie vor openssl das Präfix env SAN=DNS:fqdn. 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 # env SAN=DNS:fqdn openssl req -x509 -nodes -days 1095 \
     -newkey rsa:4096 -keyout rgw.key -out /srv/salt/ceph/rgw/cert/rgw.pem

11.6.2 Einfache HTTPS-Konfiguration

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_configurations: rgw-ssl
    rgw_init: default-ssl
  2. 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

11.6.3 Erweiterte HTTPS-Konfiguration

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

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

  3. 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. Trennen Sie bei Angabe der Ports die Nummern durch ein Pluszeichen ("+"). Die Zeile für eine Zwei-Port-Konfiguration entspricht dem folgenden Beispiel:

[client.{{ client }}]
rgw_frontends = civetweb port=80+443s ssl_certificate=/etc/ceph/rgw.pem

11.7 Sync-Module

Die mit Jewel eingeführte Object Gateway-Funktion für mehrere Standorte ermöglicht die Erstellung mehrerer Zonen und die Spiegelung der Daten und Metadaten zwischen diesen Zonen. Sync-Module 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 Sync-Modul kann eine Reihe von Aktionen durchgeführt werden, sobald eine Datenänderung vorgenommen wird (Metadaten-Optionen wie die Erstellung von Buckets oder Benutzern werden auch als Datenänderungen betrachtet). Da die RGW-Änderungen an mehreren Standorten letztendlich an Remote-Standorten konsistent sind, werden die Änderungen asynchron verteilt. Dies würde das Entsperren von Anwendungsfällen ermöglichen, wie Sichern des Objektspeichers in einem externen Cloud Cluster oder eine benutzerdefinierte Sicherungslösung mit Bandlaufwerken. Metadaten werden dabei u.a. in Elasticsearch indiziert.

11.7.1 Synchronisieren von Zonen

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

Anmerkung
Anmerkung: Standardmäßiges Sync-Plugin

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

11.7.1.1 Anforderungen und Annahmen

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

11.7.1.2 Konfigurieren von Sync-Modulen

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

    root # 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 Sync-Modul kann für diese Zone mit folgendem Kommando konfiguriert werden:

    root # radosgw-admin zone modify --rgw-zone={zone-name} --tier-type={tier-type} \
    --tier-config={set of key=value pairs}
  3. Beispiel im Sync-Modul elasticsearch:

    root # 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 11.7.2, „Speichern von Metadaten in Elasticsearch“.

  4. Aktualisieren Sie schließlich den Zeitraum:

    root # 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`

11.7.2 Speichern von Metadaten in Elasticsearch

Dieses Sync-Modul 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"
    }
  }
}

11.7.2.1 Parameter zur Konfiguration des Elasticsearch-Schichttyps

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.

11.7.2.2 Metadatenabfragen

Da der Elasticsearch Cluster nun Objektmetadaten speichert, ist es wichtig, dass der Elasticsearch-Endpunkt nicht öffentlich gemacht wird und nur für Cluster-Administratoren zugänglich ist. Die Anzeige von Metadatenabfragen 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. Die aktuell zulässigen Typen sind Zeichenkette (Standardeinstellung), Ganzzahl und Datum. Beispiel: Wenn Sie die benutzerdefinierten Objektmetadaten "x-amz-meta-year" als Ganzzahl, "x-amz-meta-date" als Datum und "x-amz-meta-title" als Zeichenkette indizieren möchten, müssen Sie Folgendes festlegen:

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

11.8 LDAP-Authentifizierung

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

11.8.1 Authentifizierungsverfahren

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.

11.8.2 Anforderungen

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

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.

11.8.3 Konfigurieren des Object Gateways zur Verwendung der LDAP-Authentifizierung

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 11.8.4, „Verwenden eines benutzerdefinierten Suchfilters zur Begrenzung des Benutzerzugriffs“.

11.8.4 Verwenden eines benutzerdefinierten Suchfilters zur Begrenzung des Benutzerzugriffs

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

11.8.4.1 Teilfilter zur weiteren Beschränkung des konstruierten Suchfilters

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.

11.8.4.2 Vollständiger Filter

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.

11.8.5 Generieren eines Zugriffstokens für die LDAP-Authentifizierung

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 11.5.1, „Zugreifen auf Object Gateway“), geben Sie den Token als Zugriffsschlüssel an und verwenden Sie einen leeren geheimen Schlüssel.

root@minion > export RGW_ACCESS_KEY_ID="username"
root@minion > export RGW_SECRET_ACCESS_KEY="password"
root@minion > 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.

11.9 Bucket-Index-Sharding

Das Object Gateway speichert Bucket-Indexdaten in einem Index-Pool, der standardmäßig .rgw.buckets.index lautet. Wenn Sie zu viele (hundertausende) 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.

11.9.1 Bucket-Index-Resharding

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

11.9.1.1 Dynamisches Resharding

Ab SUSE Enterprise Storage 5 unterstützen wird 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 ab 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:
root@minion > radosgw-admin reshard add \
 --bucket BUCKET_NAME \
 --num-shards NEW_NUMBER_OF_SHARDS
Listen Sie die Resharding-Warteschlange auf mit:
root@minion > radosgw-admin reshard list
Verarbeiten/planen Sie ein Bucket-Resharding mit:
root@minion > radosgw-admin reshard process
Zeigen Sie den Bucket-Resharding-Status an mit:
root@minion > radosgw-admin reshard status --bucket BUCKET_NAME
Brechen Sie das ausstehende Bucket-Resharding ab mit:
root@minion > radosgw-admin reshard cancel --bucket BUCKET_NAME

11.9.1.2 Manuelles Resharding

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

root@minion > 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 Objekteinträ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 11.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:

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

     root@minion > 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:

    root@minion > radosgw-admin bi purge
     --bucket=BUCKET_NAME
     --bucket-id=OLD_BUCKET_ID

11.9.2 Bucket-Index-Sharding für neue Buckets

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.

11.9.2.1 Einfache Konfigurationen

  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 11.3, „Ausführen des Object Gateway Service“.

11.9.2.2 Konfigurationen für mehrere Standorte

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:

    root@minion > 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 mit:

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

    root@minion > radosgw-admin period update --commit

11.10 Integrieren von OpenStack Keystone

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.

11.10.1 Konfigurieren von OpenStack

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:

    root # 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 Namen des Zonengruppennamens oder Regionnamens des Gateways.

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

    root # openstack endpoint show object-store

11.10.2 Konfigurieren des Ceph Object Gateways

11.10.2.1 Konfigurieren der SSL-Zertifikate

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 ein eigensigniertes SSL-Zertifikat verwenden, damit Ceph Object Gateway mit OpenStack Keystone interagieren kann. 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.

11.10.2.2 Konfigurieren der Optionen des Object Gateways

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

11.11 Object Gateways an mehreren Standorten

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.

11.11.1 Terminologie

Nachfolgend sehen Sie eine Beschreibung der spezifischen Begriffe einer Verbundarchitektur:

11.11.2 Beispiel einer Cluster-Einrichtung

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.

11.11.3 Systemschlüssel

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

11.11.4 Benennungskonventionen

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.

11.11.5 Standard-Pools

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.

11.11.6 Erstellen eines Bereichs

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

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

11.11.7 Löschen der Standard-Zonengruppe

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 > radosgw-admin zonegroup delete --rgw-zonegroup=default

11.11.8 Erstellen einer Master-Zonengruppe

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 > 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 > radosgw-admin zonegroup default --rgw-zonegroup=us

11.11.9 Erstellen einer Master-Zone

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 > 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 > radosgw-admin zone default --rgw-zone=us-east-1
cephadm > radosgw-admin zonegroup add --rgw-zonegroup=us --rgw-zone=us-east-1

11.11.9.1 Erstellen von Systembenutzern

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 > radosgw-admin user create --uid=zone.user \
--display-name="Zone User" --access-key=$SYSTEM_ACCESS_KEY \
--secret=$SYSTEM_SECRET_KEY --system

11.11.9.2 Aktualisieren der Periode

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

11.11.9.3 Starten des Object Gateways

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

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

Starten Sie das Object Gateway:

sudo systemctl start ceph-radosgw@rgw.us-east-1

11.11.10 Erstellen einer sekundären Zone

Erstellen und konfigurieren Sie die sekundäre Zone namens us-east-2 im selben 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 > 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"
}

11.11.10.1 Aktualisieren der Periode

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

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

11.11.10.2 Starten des Object Gateways

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="civetweb port=80"
rgw_zone=us-east-2
cephadm > sudo systemctl start ceph-radosgw@rgw.us-east-2

11.11.11 Hinzufügen von Object Gateway zum sekundären Cluster

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

11.11.11.1 Standard-Bereich und -Zonengruppe

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 > 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 > radosgw-admin realm default --rgw-realm=gold

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

cephadm > 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 > radosgw-admin zonegroup default --rgw-zonegroup=us

11.11.11.2 Konfiguration der sekundären Zone

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

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

11.11.11.3 Aktualisieren der Periode

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

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

11.11.11.4 Starten des Object Gateways

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="civetweb port=80"
rgw_zone=us-west

Starten Sie das zweite Object Gateway:

sudo systemctl start ceph-radosgw@rgw.us-west

11.11.12 Failover und Disaster Recovery

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:

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

    root # radosgw-admin zone modify --rgw-zone={zone-name} --master --default \
    --read-only=False
  2. Aktualisieren Sie die Periode, damit die Änderungen wirksam werden.

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

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

    root # radosgw-admin zone modify --rgw-zone={zone-name} --master --default
  3. Aktualisieren Sie die Periode, damit die Änderungen wirksam werden.

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

    root # radosgw-admin zone modify --rgw-zone={zone-name} --read-only
  6. Aktualisieren Sie die Periode, damit die Änderungen wirksam werden.

    root # 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`

11.12 Lastausgleich an den Object Gateway Servern mit HAProxy

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-12/book_sleha/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:

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