SUSE Enterprise Storage 7: Kapitel 28. Konfiguration des Ceph-Clusters (Betriebs- und Verwaltungshandbuch)

documentation.suse.com › Dokumentation zu SUSE Enterprise Storage 7 › Betriebs- und Verwaltungshandbuch › Konfigurieren eines Clusters › Konfiguration des Ceph-Clusters

InhaltInhalt

Betriebs- und Verwaltungshandbuch

Navigation←→

Bezieht sich auf SUSE Enterprise Storage 7

28 Konfiguration des Ceph-Clusters #Edit source

28.1 Konfigurieren der Datei ceph.conf
28.2 Konfigurationsdatenbank
28.3 config-key-Speicher
28.4 Ceph OSD und BlueStore
28.5 Ceph Object Gateway

In diesem Kapitel wird beschrieben, wie Sie den Ceph-Cluster mithilfe von Konfigurationsoptionen konfigurieren.

28.1 Konfigurieren der Datei `ceph.conf` #Edit source

cephadm verwendet eine einfache ceph.conf-Datei, die nur einen minimalen Satz von Optionen für die Verbindung mit MONs, die Authentifizierung und das Abrufen von Konfigurationsinformationen enthält. In den meisten Fällen ist dies auf die Option mon_host beschränkt (obwohl dies durch die Verwendung von DNS-SRV-Datensätzen verhindert werden kann).

Wichtig

Die Datei ceph.conf dient nicht mehr als zentraler Ort zum Speichern der Cluster-Konfiguration, sondern zum Speichern der Konfigurationsdatenbank (weitere Informationen hierzu finden Sie in Abschnitt 28.2, „Konfigurationsdatenbank“).

Wenn Sie die Cluster-Konfiguration dennoch über die Datei ceph.conf ändern müssen (zum Beispiel, weil Sie einen Client verwenden, der das Lesen von Optionen aus der Konfigurationsdatenbank nicht unterstützt), müssen Sie folgendes Kommando ausführen und sich um die Pflege und Verteilung der Datei ceph.conf im gesamten Cluster kümmern:

cephuser@adm > ceph config set mgr mgr/cephadm/manage_etc_ceph_ceph_conf false

28.1.1 Zugreifen auf `ceph.conf` innerhalb der Container-Images #Edit source

Obwohl Ceph-Daemons innerhalb von Containern ausgeführt werden, können Sie dennoch auf deren Konfigurationsdatei ceph.conf zugreifen. Sie ist auf dem Hostsystem als folgende Datei gebunden und eingehängt:

/var/lib/ceph/CLUSTER_FSID/DAEMON_NAME/config

Ersetzen Sie CLUSTER_FSID durch die eindeutige FSID des aktiven Clusters, wie sie vom Kommando ceph fsid zurückgegeben wird, und DAEMON_NAME durch den Namen des spezifischen Daemons, wie er vom Kommando ceph orch ps aufgeführt wird. Beispiel:

/var/lib/ceph/b4b30c6e-9681-11ea-ac39-525400d7702d/osd.2/config

Um die Konfiguration eines Daemons zu ändern, bearbeiten Sie seine config-Datei und starten Sie ihn neu:

root # systemctl restart ceph-CLUSTER_FSID-DAEMON_NAME

Beispiel:

root # systemctl restart ceph-b4b30c6e-9681-11ea-ac39-525400d7702d-osd.2

Wichtig

Alle benutzerdefinierten Einstellungen gehen verloren, nachdem cephadm den Daemon neu bereitgestellt hat.

28.2 Konfigurationsdatenbank #Edit source

Ceph Monitors verwalten eine zentrale Datenbank mit Konfigurationsoptionen, die das Verhalten des gesamten Clusters beeinflussen.

28.2.1 Konfigurieren von Abschnitten und Masken #Edit source

Die vom MON gespeicherten Konfigurationsoptionen können sich in einem globalen Abschnitt, einem Abschnitt für den Daemon-Typ oder einem Abschnitt für den spezifischen Daemon befinden. Darüber hinaus können Optionen auch mit einer Maske verknüpft sein, um weiter einzuschränken, für welche Daemons oder Clients die Option gilt. Es gibt zwei Arten von Masken:

TYPE:LOCATION, wobei TYPE eine CRUSH-Eigenschaft wie rack oder host ist, während LOCATION einen Wert für diese Eigenschaft bezeichnet.
Zum Beispiel schränkt host:example_host die Option nur auf Daemons oder Clients ein, die auf einem bestimmten Host ausgeführt werden.
CLASS:DEVICE_CLASS, wobei DEVICE_CLASS für den Namen einer CRUSH-Geräteklasse steht wie HDD oder SSD. Zum Beispiel beschränkt class:ssd die Option nur auf OSDs, die von SSDs gesichert werden. Für Nicht-OSD-Daemons oder -Clients hat diese Maske keine Wirkung.

28.2.2 Festlegen und Lesen von Konfigurationsoptionen #Edit source

Mit folgenden Kommandos legen Sie Cluster-Konfigurationsoptionen fest oder lesen sie: Der WHO-Parameter kann ein Abschnittsname, eine Maske oder eine Kombination aus beidem sein, getrennt durch einen Schrägstrich (/). Zum Beispiel steht osd/rack:foo für alle OSD-Daemons im Rack mit dem Namen foo.

ceph config dump: Gibt die gesamte Konfigurationsdatenbank für einen ganzen Cluster aus.
ceph config get WHO: Gibt die Konfiguration für einen bestimmten Daemon oder Client (z. B. mds.a) aus, wie sie in der Konfigurationsdatenbank gespeichert ist.
ceph config set WHO OPTION VALUE: Legt die Konfigurationsoption auf den angegebenen Wert in der Konfigurationsdatenbank fest.
ceph config show WHO: Zeigt die gemeldete aktive Konfiguration für einen aktiven Daemon an. Diese Einstellungen können von denen abweichen, die von den Monitoren gespeichert werden, wenn auch lokale Konfigurationsdateien verwendet werden oder Optionen auf der Kommandozeile oder zur Laufzeit außer Kraft gesetzt wurden. Die Quelle der Optionswerte wird als Teil der Ausgabe gemeldet.
ceph config assimilate-conf -i INPUT_FILE -o OUTPUT_FILE: Importiert eine als INPUT_FILE angegebene Konfigurationsdatei und speichert alle gültigen Optionen in der Konfigurationsdatenbank. Alle Einstellungen, die nicht erkannt werden, ungültig sind oder vom Monitor nicht gesteuert werden können, werden in einer verkürzten Datei zurückgegeben, die als OUTPUT_FILE gespeichert wird. Dieses Kommando ist nützlich für die Umstellung von älteren Konfigurationsdateien auf die zentralisierte monitorbasierte Konfiguration.

28.2.3 Konfigurieren von Daemons zur Laufzeit #Edit source

In den meisten Fällen lässt Ceph es zu, dass Sie Änderungen an der Konfiguration eines Daemons zur Laufzeit vornehmen. Dies ist beispielsweise nützlich, wenn Sie die Menge der Protokollierungsausgabe erhöhen oder verringern müssen oder wenn Sie eine Clusteroptimierung der Laufzeit durchführen.

Sie können die Werte von Konfigurationsoptionen mit folgendem Kommando aktualisieren:

cephuser@adm > ceph config set DAEMON OPTION VALUE

Führen Sie zum Anpassen der Protokollstufe für die Fehlersuche zu einem bestimmten OSD folgendes Kommando aus:

cephuser@adm > ceph config set osd.123 debug_ms 20

Anmerkung

Wenn dieselbe Option auch in einer lokalen Konfigurationsdatei angepasst ist, wird die Monitoreinstellung ignoriert, da sie eine niedrigere Priorität als die Konfigurationsdatei hat.

28.2.3.1 Überschreiben von Werten #Edit source

Sie können einen Optionswert vorübergehend mit den Unterkommandos tell oder daemon ändern. Solche Änderungen wirken sich nur auf den laufenden Prozess aus und werden nach dem Neustart des Daemons oder Prozesses verworfen.

Zum Überschreiben von Werten haben Sie zwei Möglichkeiten:

Senden Sie mit dem Unterkommando tell eine Nachricht von einem beliebigen Cluster-Knoten aus an einen bestimmten Daemon:
```
cephuser@adm > ceph tell DAEMON config set OPTION VALUE
```
Beispiel:
```
cephuser@adm > ceph tell osd.123 config set debug_osd 20
```
Tipp
Mit dem Unterkommando tell werden Platzhalter als Daemon-Bezeichner akzeptiert. Führen Sie zum Anpassen der Fehlersuchestufe für alle OSD-Daemons folgendes Kommando aus:
```
cephuser@adm > ceph tell osd.* config set debug_osd 20
```
Stellen Sie mit dem Unterkommando daemon eine Verbindung zu einem bestimmten Daemon-Prozess über einen Socket in /var/run/ceph von dem Knoten aus her, auf dem der Prozess ausgeführt wird:
```
cephuser@adm > ceph daemon DAEMON config set OPTION VALUE
```
Beispiel:
```
cephuser@adm > ceph daemon osd.4 config set debug_osd 20
```

Tipp

Bei der Anzeige von Laufzeiteinstellungen mit dem Kommando ceph config show (weitere Informationen hierzu finden Sie in Abschnitt 28.2.3.2, „Anzeigen der Laufzeiteinstellungen“) werden temporär überschriebene Werte mit der Quelle override angezeigt.

28.2.3.2 Anzeigen der Laufzeiteinstellungen #Edit source

So zeigen Sie alle für einen Daemon festgelegten Optionen an:

cephuser@adm > ceph config show-with-defaults osd.0

So zeigen Sie alle für einen Daemon festgelegten nicht standardmäßigen Optionen an:

cephuser@adm > ceph config show osd.0

So prüfen Sie eine bestimmte Option:

cephuser@adm > ceph config show osd.0 debug_osd

Sie können auch eine Verbindung zu einem aktiven Daemon von dem Knoten aus herstellen, auf dem sein Prozess ausgeführt wird, und seine Konfiguration beobachten:

cephuser@adm > ceph daemon osd.0 config show

So zeigen Sie nicht standardmäßige Einstellungen an:

cephuser@adm > ceph daemon osd.0 config diff

So prüfen Sie eine bestimmte Option:

cephuser@adm > ceph daemon osd.0 config get debug_osd

28.3 `config-key`-Speicher #Edit source

config-key ist ein Service von Ceph Monitors für allgemeine Zwecke. Er vereinfacht die Verwaltung von Konfigurationsschlüsseln durch die permanente Speicherung von Schlüssel-Wert-Paaren. config-key wird hauptsächlich von Ceph-Werkzeugen und -Daemons verwendet.

Tipp

Nachdem Sie einen neuen Schlüssel hinzugefügt oder einen vorhandenen Schlüssel geändert haben, starten Sie den betroffenen Service neu, damit die Änderungen wirksam werden. Weitere Details zum Betrieb von Ceph-Services finden Sie in Kapitel 14, Betrieb von Ceph-Services.

Mit dem Kommando config-key betreiben Sie den config-key-Speicher. Das Kommando config-key verwendet folgende Unterkommandos:

ceph config-key rm KEY: Löscht den angegebenen Schlüssel.
ceph config-key exists KEY: Prüft, ob der angegebene Schlüssel vorhanden ist.
ceph config-key get KEY: Ruft den Wert des angegebenen Schlüssels ab.
ceph config-key ls: Listet alle Schlüssel auf.
ceph config-key dump: Gibt alle Schlüssel und deren Werte aus.
ceph config-key set KEY VALUE: Speichert den angegebenen Schlüssel mit dem entsprechenden Wert.

28.3.1 iSCSI Gateway #Edit source

Das iSCSI Gateway speichert oder liest seine Konfigurationsoptionen im config-key-Speicher. Allen auf das iSCSI Gateway bezogenen Schlüsseln wird die Zeichenkette iscsi vorangestellt, wie zum Beispiel:

iscsi/trusted_ip_list
iscsi/api_port
iscsi/api_user
iscsi/api_password
iscsi/api_secure

Wenn Sie beispielsweise zwei Sätze von Konfigurationsoptionen benötigen, erweitern Sie das Präfix um ein weiteres beschreibendes Schlüsselwort, z. B. datacenterA und datacenterB:

iscsi/datacenterA/trusted_ip_list
iscsi/datacenterA/api_port
[...]
iscsi/datacenterB/trusted_ip_list
iscsi/datacenterB/api_port
[...]

28.4 Ceph OSD und BlueStore #Edit source

28.4.1 Konfigurieren der automatischen Cache-Größe #Edit source

BlueStore kann so konfiguriert werden, dass die Größe der Caches automatisch geändert wird, wenn tc_malloc als Arbeitsspeicherzuordner konfiguriert und die Einstellung bluestore_cache_autotune aktiviert ist. Diese Option ist derzeit standardmäßig aktiviert. BlueStore versucht mit der Konfigurationsoption osd_memory_target, die Auslastung des OSD-Heap-Speichers unter einer bestimmten Zielgröße zu halten. Dies ist ein Best-Effort-Algorithmus und die Caches werden nicht auf eine Größe unter dem mit osd_memory_cache_min angegebenen Wert verkleinert. Die Cache-Verhältnisse werden auf der Grundlage einer Prioritätenhierarchie festgelegt. Wenn keine Prioritätsdaten vorliegen, werden die Optionen bluestore_cache_meta_ratio und bluestore_cache_kv_ratio herangezogen.

bluestore_cache_autotune: Passt automatisch die Verhältnisse an, die verschiedenen BlueStore-Caches zugewiesen sind, und beachtet dabei die Mindestwerte. Die Standardeinstellung ist true.
osd_memory_target: Wenn tc_malloc und bluestore_cache_autotune aktiviert sind, wird versucht, die Zuordnung dieser Datenmenge (in Byte) im Speicher beizubehalten.
Anmerkung
Dies ist nicht völlig mit der RSS-Speichernutzung des Prozesses identisch. Die Gesamtmenge an Heap-Speicher, die durch den Prozess zugeordnet wird, sollte im Allgemeinen nahe an diesem Ziel legen. Es gibt jedoch keine Garantie, dass der Kernel den Speicher, dessen Zuordnung aufgehoben wurde, tatsächlich freigibt.
osd_memory_cache_min: Wenn tc_malloc und bluestore_cache_autotune aktiviert sind, legen Sie die Mindestspeichermenge für Caches fest.
Anmerkung
Ein zu niedriger Wert kann zu einer erheblichen Cache-Überlastung führen.

28.5 Ceph Object Gateway #Edit source

Sie können das Verhalten des Object Gateways durch eine Reihe von Optionen beeinflussen. Wenn eine Option nicht angegeben ist, wird ihr Standardwert verwendet. Liste aller Object-Gateway-Optionen:

28.5.1 Allgemeine Einstellungen #Edit source

rgw_frontends: Konfiguriert das oder die HTTP-Front-Ends. Geben Sie mehrere Front-Ends in einer durch Komma getrennten Liste an. Die einzelnen Front-End-Konfigurationen können eine Liste mit Optionen umfassen, die durch Leerzeichen getrennt sind. Die Optionen werden jeweils in der Form „Schlüssel=Wert“ oder „Schlüssel“ angegeben. Der Standardwert ist beast port=7480.
rgw_data: Bestimmt den Speicherort der Datendateien für das Object Gateway. Die Standardeinstellung ist /var/lib/ceph/radosgw/CLUSTER_ID.
rgw_enable_apis: Aktiviert die angegebenen APIs. Die Standardeinstellung ist „s3, swift, swift_auth, admin All APIs“.
rgw_cache_enabled: Aktiviert oder deaktiviert den Object-Gateway-Cache. Die Standardeinstellung ist true.
rgw_cache_lru_size: Anzahl der Einträge im Object-Gateway-Cache. Der Standardwert ist 10000.
rgw_socket_path: Socket-Pfad für den Domänen-Socket. FastCgiExternalServer nutzt diesen Socket. Wenn Sie keinen Socket-Pfad angeben, wird das Object Gateway nicht als externer Server ausgeführt. Hier muss derselbe Pfad angegeben werden wie in der Datei rgw.conf.
rgw_fcgi_socket_backlog: Socket-Backlog für fcgi. Der Standardwert ist 1024.
rgw_host: Host für die Object-Gateway-Instanz. Dies kann eine IP-Adresse oder ein Hostname sein. Der Standardwert ist 0.0.0.0.
rgw_port: Portnummer, die die Instanz auf Anforderungen überwacht. Falls hier kein Wert angegeben ist, wird externes FastCGI auf dem Object Gateway ausgeführt.
rgw_dns_name: DNS-Name der bedienten Domäne.
rgw_script_uri: Alternativwert für die SCRIPT_URI, falls dieser in der Anforderung nicht angegeben ist.
rgw_request_uri: Alternativwert für die REQUEST_URI, falls dieser in der Anforderung nicht angegeben ist.
rgw_print_continue: Bei Betriebsbereitschaft aktivieren Sie „100-continue“. Die Standardeinstellung ist true.
rgw_remote_addr_param: Remote-Adressparameter. Dies ist beispielsweise das HTTP-Feld mit der Remote-Adresse oder die X-Forwarded-For-Adresse, wenn ein Reverse-Proxy verwendet wird. Die Standardeinstellung ist REMOTE_ADDR.
rgw_op_thread_timeout: Zeitüberschreitung (in Sekunden) für offene Threads. Der Standardwert ist 600.
rgw_op_thread_suicide_timeout: Zeitüberschreitung (in Sekunden), bevor der Object-Gateway-Prozess abgebrochen wird. Beim Wert 0 (Standard) ist dies deaktiviert.
rgw_thread_pool_size: Anzahl der Threads für den Beast-Server. Erhöhen Sie den Wert, wenn Sie mehr Anforderungen verarbeiten müssen. Der Standardwert ist 100 Threads.
rgw_num_rados_handles: Anzahl der RADOS-Cluster-Zugriffsnummern für das Object Gateway. Jeder Object-Gateway-Worker-Thread kann nun eine RADOS-Zugriffsnummer für seine Gültigkeitsdauer auswählen. Diese Option wird unter Umständen aus künftigen Versionen als veraltet entfernt. Der Standardwert ist 1.
rgw_num_control_oids: Anzahl der Benachrichtigungsobjekte für die Cache-Synchronisierung zwischen verschiedenen Object-Gateway-Instanzen. Der Standardwert ist 8.
rgw_init_timeout: Zeitraum (in Sekunden), bevor das Object Gateway die Initialisierung abbricht. Der Standardwert ist 30.
rgw_mime_types_file: Pfad und Speicherort der MIME-Typen. Für die Swift-Autoerkennung von Objekttypen. Die Standardeinstellung ist /etc/mime.types.
rgw_gc_max_objs: Maximale Anzahl der Objekte, die durch die Speicherbereinigung in einem einzelnen Speicherbereinigungszyklus verarbeitet werden kann. Der Standardwert ist 32.
rgw_gc_obj_min_wait: Minimale Wartezeit, bevor das Objekt entfernt und durch die Speicherbereinigung verarbeitet werden kann. Der Standardwert ist 2 * 3.600.
rgw_gc_processor_max_time: Maximaler Zeitraum zwischen dem Beginn zweier aufeinanderfolgender Speicherbereinigungszyklen. Der Standardwert ist 3600.
rgw_gc_processor_period: Zyklusdauer für die Speicherbereinigung. Der Standardwert ist 3600.
rgw_s3_success_create_obj_status: Alternative Erfolgsstatusantwort für create-obj. Der Standardwert ist 0.
rgw_resolve_cname: Angabe, ob das Object Gateway den Datensatz DNS CNAME aus dem Feld für den Hostnamen in der Anforderung heranziehen soll (falls der Hostname nicht mit dem DNS-Namen des Object Gateways übereinstimmt). Die Standardeinstellung ist false.
rgw_obj_stripe_size: Größe eines Objekt-Stripes für Object-Gateway-Objekte. Der Standardwert ist 4 << 20.
rgw_extended_http_attrs: Fügt einen neuen Attributsatz ein, der für eine Entität festgelegt werden kann (z. B. einen Benutzer, einen Bucket oder ein Objekt). Diese zusätzlichen Attribute können mithilfe von HTTP-Header-Feldern festgelegt werden, wenn die Entität platziert oder mit der POST-Methode bearbeitet wird. Wenn diese Option aktiviert ist, werden diese Attribute als HTTP-Felder zurückgegeben, wenn GET/HEAD für die Entität angefordert wird. Die Standardeinstellung ist content_foo, content_bar, x-foo-bar.
rgw_exit_timeout_secs: Wartezeit (in Sekunden) für einen Prozess, bevor er uneingeschränkt beendet wird. Der Standardwert ist 120.
rgw_get_obj_window_size: Fenstergröße (in Byte) für eine einzelne Objektanforderung. Der Standardwert ist 16 << 20.
rgw_get_obj_max_req_size: Maximale Anforderungsgröße einer einzelnen GET-Operation, die an den Ceph Storage Cluster gesendet wird. Der Standardwert ist 4 << 20.
rgw_relaxed_s3_bucket_names: Aktiviert lockere Namensregeln für S3-Buckets in der US-Region. Die Standardeinstellung ist false.
rgw_list_buckets_max_chunk: Maximale Anzahl an Buckets, die in einer einzelnen Operation zum Auflisten der Benutzer-Buckets abgerufen werden soll. Der Standardwert ist 1000.
rgw_override_bucket_index_max_shards: Anzahl der Shards für das Bucket-Indexobjekt. Bei der Einstellung 0 (Standard) wird kein Sharding durchgeführt. Ein zu hoher Wert (z. B. 1.000) wird nicht empfohlen, da dies die Kosten für die Bucket-Auflistung erhöht. Diese Variable ist im Client-Abschnitt oder im globalen Abschnitt festzulegen, damit sie bei einem Kommando radosgw-admin automatisch übernommen wird.
rgw_curl_wait_timeout_ms: Zeitüberschreitung (in Millisekunden) für bestimmte curl-Aufrufe. Der Standardwert ist 1000.
rgw_copy_obj_progress: Aktiviert die Ausgabe des Objektfortschritts bei umfangreichen Kopiervorgängen. Die Standardeinstellung ist true.
rgw_copy_obj_progress_every_bytes: Minimale Datenmenge (in Byte) zwischen zwei Ausgaben des Kopierfortschritts. Der Standardwert ist 1.024 * 1.024.
rgw_admin_entry: Der Einstiegspunkt für eine Admin-Anforderungs-URL. Die Standardeinstellung ist admin.
rgw_content_length_compat: Aktiviert die Kompatibilitätsverarbeitung von FCGI-Anforderungen, bei denen sowohl CONTENT_LENGTH als auch HTTP_CONTENT_LENGTH festgelegt ist. Die Standardeinstellung ist false.
rgw_bucket_quota_ttl: Zeitraum (in Sekunden), über den die im Cache gespeicherten Kontingentdaten als verbürgt gelten. Nach Ablauf dieser Zeitüberschreitung werden die Kontingentdaten erneut aus dem Cluster abgerufen. Der Standardwert ist 600.
rgw_user_quota_bucket_sync_interval: Zeitraum (Sekunden), über den die Bucket-Kontingentdaten akkumuliert werden, bevor sie mit dem Cluster synchronisiert werden. In diesem Zeitraum können andere Object-Gateway-Instanzen die Veränderungen an der Bucket-Kontingentstatistik im Zusammenhang mit Operationen für diese Instanz nicht sehen. Der Standardwert ist 180.
rgw_user_quota_sync_interval: Zeitraum (Sekunden), über den die Benutzer-Kontingentdaten akkumuliert werden, bevor sie mit dem Cluster synchronisiert werden. In diesem Zeitraum können andere Object-Gateway-Instanzen die Veränderungen an der Benutzer-Kontingentstatistik im Zusammenhang mit Operationen für diese Instanz nicht sehen. Der Standardwert ist 180.
rgw_bucket_default_quota_max_objects: Standardmäßige maximale Anzahl der Objekte pro Bucket. Dieser Wert wird für neue Benutzer festgelegt, wenn kein anderes Kontingent angegeben wurde. Er wirkt sich nicht auf vorhandene Benutzer aus. Diese Variable ist im Client-Abschnitt oder im globalen Abschnitt festzulegen, damit sie bei einem Kommando radosgw-admin automatisch übernommen wird. Der Standardwert ist -1.
rgw_bucket_default_quota_max_size: Standardmäßige maximale Kapazität pro Bucket (in Byte). Dieser Wert wird für neue Benutzer festgelegt, wenn kein anderes Kontingent angegeben wurde. Er wirkt sich nicht auf vorhandene Benutzer aus. Der Standardwert ist -1.
rgw_user_default_quota_max_objects: Standardmäßige maximale Anzahl der Objekte für einen Benutzer. Hierzu zählen alle Objekte in allen Buckets, die im Eigentum des Benutzers stehen. Dieser Wert wird für neue Benutzer festgelegt, wenn kein anderes Kontingent angegeben wurde. Er wirkt sich nicht auf vorhandene Benutzer aus. Der Standardwert ist -1.
rgw_user_default_quota_max_size: Wert für das benutzerspezifische maximale Größenkontingent (in Byte). Dieser Wert wird für neue Benutzer festgelegt, wenn kein anderes Kontingent angegeben wurde. Er wirkt sich nicht auf vorhandene Benutzer aus. Der Standardwert ist -1.
rgw_verify_ssl: Überprüft SSL-Zertifikate im Rahmen von Anforderungen. Die Standardeinstellung ist true.
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).

Einstellungen für mehrere Standorte #

rgw_zone: Name der Zone für die Gateway-Instanz. Wenn keine Zone festgelegt ist, können Sie mit dem Kommando radosgw-admin zone default eine clusterweite Standardeinstellung festlegen.
rgw_zonegroup: Name der Zonengruppe für die Gateway-Instanz. Wenn keine Zonengruppe festgelegt ist, können Sie mit dem Kommando radosgw-admin zonegroup default eine clusterweite Standardeinstellung festlegen.
rgw_realm: Name des Bereichs für die Gateway-Instanz. Wenn kein Bereich festgelegt ist, können Sie mit dem Kommando radosgw-admin realm default eine clusterweite Standardeinstellung festlegen.
rgw_run_sync_thread: Wenn der Bereich weitere Zonen für die Synchronisierung umfasst, werden Threads erzeugt, die die Synchronisierung der Daten und Metadaten übernehmen. Die Standardeinstellung ist true.
rgw_data_log_window: Zeitfenster (in Sekunden) für Datenprotokolleinträge. Der Standardwert ist 30.
rgw_data_log_changes_size: Anzahl der Einträge im Speicher, die für das Datenänderungsprotokoll beibehalten werden sollen. Der Standardwert ist 1000.
rgw_data_log_obj_prefix: Objektnamenpräfix für das Datenprotokoll. Die Standardeinstellung ist „data_log“.
rgw_data_log_num_shards: Anzahl der Shards (Objekte), in denen das Datenänderungsprotokoll abgelegt werden soll. Der Standardwert ist 128.
rgw_md_log_max_shards: Maximale Anzahl der Shards für das Metadaten-Protokoll. Der Standardwert ist 64.

Swift-Einstellungen #

rgw_enforce_swift_acls: Erzwingt die Swift-Einstellungen für die Zugriffssteuerungsliste (ACL). Die Standardeinstellung ist true.
rgw_swift_token_expiration: Zeitraum (in Sekunden), nach dem ein Swift-Token abläuft. Der Standardwert ist 24 * 3.600.
rgw_swift_url: URL für die Swift-API des Ceph Object Gateway.
rgw_swift_url_prefix: URL-Präfix für Swift StorageURL, das dem Teil „/v1“ vorangestellt wird. Hiermit können mehrere Gateway-Instanzen auf demselben Host ausgeführt werden. Wenn diese Konfigurationsvariable leer bleibt, wird aus Kompatibilitätsgründen die Standardeinstellung „/swift“ verwendet. Mit dem expliziten Präfix „/“ wird StorageURL im Root-Verzeichnis gestartet.
Warnung
Es ist nicht möglich, „/“ für diese Option festzulegen, wenn die S3-API aktiviert ist. Wichtiger Hinweis: Wenn S3 deaktiviert wird, kann das Object Gateway nicht in der Konfiguration für mehrere Standorte implementiert werden.
rgw_swift_auth_url: Standard-URL die Überprüfung der v1-Authentifizierungs-Token, wenn die interne Swift-Authentifizierung nicht verwendet wird.
rgw_swift_auth_entry: Einstiegspunkt für eine Swift-Authentifizierungs-URL. Die Standardeinstellung ist auth.
rgw_swift_versioning_enabled: Aktiviert die Objektversionierung der OpenStack Object Storage-API. Damit können Clients das Attribut X-Versions-Location für Container festlegen, die versioniert werden sollen. Das Attribut bestimmt den Namen des Containers, in dem die archivierten Versionen gespeichert werden. Aus Gründen der Zugriffssteuerungsprüfung muss dieser Container im Eigentum desselben Benutzers stehen wie der versionierte Container – ACLs werden nicht berücksichtigt. Diese Container können nicht mit dem S3-Mechanismus zur Objektversionierung versioniert werden. Die Standardeinstellung ist false.

Protokollierungseinstellungen #

rgw_log_nonexistent_bucket: Hiermit kann das Object Gateway eine Anforderung nach einem nicht vorhandenen Bucket protokollieren. Die Standardeinstellung ist false.
rgw_log_object_name: Protokollierungsformat für einen Objektnamen. Weitere Informationen zu Formatspezifizierern finden Sie auf der Handbuchseite man 1 date. Die Standardeinstellung ist %Y-%m-%d-%H-%i-%n.
rgw_log_object_name_utc: Angabe, ob ein protokollierter Objektname eine UTC-Zeit enthält. Bei der Einstellung false (Standard) wird die Ortszeit verwendet.
rgw_usage_max_shards: Maximale Anzahl der Shards für die Auslastungsprotokollierung. Der Standardwert ist 32.
rgw_usage_max_user_shards: Maximale Anzahl der Shards für die Auslastungsprotokollierung für einen einzelnen Benutzer . Der Standardwert ist 1.
rgw_enable_ops_log: Aktiviert die Protokollierung für jede erfolgreiche Object-Gateway-Operation. Die Standardeinstellung ist false.
rgw_enable_usage_log: Aktiviert das Auslastungsprotokoll. Die Standardeinstellung ist false.
rgw_ops_log_rados: Angabe, ob das Operationsprotokoll in das Ceph Storage ClusterࢮBack-End geschrieben werden soll. Die Standardeinstellung ist true.
rgw_ops_log_socket_path: Unix-Domänen-Socket für das Schreiben der Operationsprotokolle.
rgw_ops_log_data_backlog: Maximale Datengröße des Daten-Backlogs für Operationsprotokolle, die auf einen Unix-Domänen-Socket geschrieben werden. Der Standardwert ist 5 << 20.
rgw_usage_log_flush_threshold: Anzahl der kürzlich bearbeiteten („dirty“) zusammengeführten Einträge im Auslastungsprotokoll, bevor sie synchron verschoben werden. Der Standardwert ist 1024.
rgw_usage_log_tick_interval: Auslastungsprotokolldaten zu ausstehenden Verschiebungen alle „n“ Sekunden. Der Standardwert ist 30.
rgw_log_http_headers: Durch Komma getrennte Liste der HTTP-Header, die in Protokolleinträge aufgenommen werden sollen. Bei Header-Namen wird nicht zwischen Groß- und Kleinschreibung unterschieden. Geben Sie den vollständigen Header-Namen ein und trennen Sie die einzelnen Wörter jeweils durch Unterstrich. Beispiel: „http_x_forwarded_for“, „http_x_special_k“.
rgw_intent_log_object_name: Protokollierungsformat für den Intent-Protokollobjektnamen. Weitere Informationen zu Formatspezifizierern finden Sie auf der Handbuchseite man 1 date. Die Standardeinstellung ist „%Y-%m-%d-%i-%n“.
rgw_intent_log_object_name_utc: Angabe, ob der Intent-Protokollobjektname eine UTC-Zeit enthält. Bei der Einstellung false (Standard) wird die Ortszeit verwendet.

Keystone-Einstellungen #

rgw_keystone_url: URL für den Keystone-Server.
rgw_keystone_api_version: Version (2 oder 3) der OpenStack Identity-API, über die die Kommunikation mit dem Keystone-Server abgewickelt werden soll. Der Standardwert ist 2.
rgw_keystone_admin_domain: Name der OpenStack-Domäne mit Administratorberechtigung bei Verwendung der OpenStack Identity-API v3.
rgw_keystone_admin_project: Name des OpenStack-Projekts mit Administratorberechtigung bei Verwendung der OpenStack Identity-API v3. Falls kein Wert angegeben ist, wird stattdessen der Wert für rgw keystone admin tenant verwendet.
rgw_keystone_admin_token: Keystone-Administrator-Token (gemeinsames Geheimnis). Im Object Gateway hat die Authentifizierung mit dem Administrator-Token den Vorrang vor der Authentifizierung mit dem Administrator-Berechtigungsnachweis (Optionen rgw keystone admin user, rgw keystone admin password, rgw keystone admin tenant, rgw keystone admin project und rgw keystone admin domain). Die Administrator-Token-Funktion gilt als veraltet.
rgw_keystone_admin_tenant: Name des OpenStack-Mandanten mit Administratorberechtigung (Servicemandant) bei Verwendung der OpenStack Identity-API v2.
rgw keystone admin user: Name des OpenStack-Benutzers mit Administratorberechtigung für die Keystone-Authentifizierung (Servicebenutzer) bei Verwendung der OpenStack Identity-API v2.
rgw_keystone_admin_password: Passwort für den verwaltungsberechtigten OpenStack-Benutzer bei Verwendung der OpenStack Identity-API v2.
rgw_keystone_accepted_roles: Die Rollen zur Verarbeitung der Anforderungen. Die Standardeinstellung ist „Member“, „admin“.
rgw_keystone_token_cache_size: Maximale Anzahl der Einträge pro Keystone-Token-Cache. Der Standardwert ist 10000.
rgw_keystone_revocation_interval: Zeitraum (in Sekunden) zwischen zwei Überprüfungen, ob Token entzogen wurden. Der Standardwert ist 15 * 60.
rgw_keystone_verify_ssl: Überprüft SSL-Zertifikate im Rahmen von Token-Anforderungen an Keystone. Die Standardeinstellung ist true.

28.5.1.1 Weitere Hinweise #Edit source

rgw_dns_name

Ermöglicht Clients die Verwendung von vhost-Buckets.

Der vhost-Zugriff bezieht sich auf die Verwendung des bucketname.s3-endpoint/object-path. Dies ist im Vergleich zum path-Zugriff: s3-endpoint/bucket/object

Wenn der rgw dns name festgelegt ist, müssen Sie überprüfen, ob der S3 Client so konfiguriert ist, dass er Anforderungen zu dem Endpunkt leitet, der durch rgw dns name angegeben ist.

28.5.2 Konfigurieren von HTTP-Frontends #Edit source

28.5.2.1 Beast #Edit source

port, ssl_port

Portnummern der zu überwachenden IPv4- und IPv6-Ports. Sie können mehrere Portnummern angeben:

port=80 port=8000 ssl_port=8080

Der Standardwert ist 80.

endpoint, ssl_endpoint

Zu überwachende Adressen in der Form „address[:port]“, wobei die Adresse als IPv4-Adresszeichenkette mit Dezimalziffern und Punkten oder als IPv6-Adresse mit hexadezimaler Schreibweise in eckigen Klammern angegeben wird. Wenn Sie hier einen IPv6-Endpunkt angeben, wird lediglich IPv6 überwacht. Die optionale Portnummer lautet standardmäßig 80 für endpoint und 443 für ssl_endpoint. Sie können mehrere Adressen angeben:

endpoint=[::1] endpoint=192.168.0.100:8000 ssl_endpoint=192.168.0.100:8080

ssl_private_key

Optionaler Pfad zur Datei mit dem privaten Schlüssel für SSL-fähige Endpunkte. Wenn hier kein Wert angegeben ist, wird die Datei ssl_certificate als privater Schlüssel herangezogen.

tcp_nodelay

Wenn hier ein Wert angegeben ist, deaktiviert die Socket-Option den Nagle-Algorithmus für die Verbindung. Dies bedeutet, dass Pakete so bald wie möglich gesendet werden, statt abzuwarten, bis der Puffer gefüllt ist oder eine Zeitüberschreitung eintritt.

Mit dem Wert „1“ wird der Nagle-Algorithmus für alle Sockets deaktiviert.

Mit dem Wert „0“ bleibt der Nagle-Algorithmus aktiviert (Standard).

Beispiel 28.1: Beispiel einer Beast-Konfiguration #

cephuser@adm > ceph config set rgw.myrealm.myzone.ses-min1.kwwazo \
 rgw_frontends beast port=8000 ssl_port=443 \
 ssl_certificate=/etc/ssl/ssl.crt \
 error_log_file=/var/log/radosgw/beast.error.log

28.5.2.2 CivetWeb #Edit source

Anschluss

Portnummer des zu überwachenden Ports. Bei SSL-fähigen Ports hängen Sie das Suffix „s“ an (z. B. „443s“). Soll eine bestimmte IPv4- oder IPv6-Adresse gebunden werden, beachten Sie die Form „address:port“. Sie können mehrere Endpunkte angeben. Verbinden Sie sie wahlweise mit „+“ oder legen Sie mehrere Optionen fest:

port=127.0.0.1:8000+443s
port=8000 port=443s

Der Standardwert ist 7480.

num_threads

Anzahl der Threads, die CivetWeb zur Verarbeitung eingehender HTTP-Verbindungen erzeugt. Hiermit wird letztlich die Anzahl der gleichzeitigen Verbindungen verringert, die durch das Front-End verarbeitet werden können.

Der Standardwert ist der Wert der Option rgw_thread_pool_size.

request_timeout_ms

Zeitraum (in Millisekunden), über den CivetWeb auf weitere eingehende Daten wartet, bevor der Vorgang abgebrochen wird.

Der Standardwert ist 30.000 Millisekunden.

access_log_file

Pfad der Zugriffsprotokolldatei. Sie können entweder einen vollständigen Pfad angeben oder einen Pfad relativ zum aktuellen Arbeitsverzeichnis. Wenn hier kein Wert angegeben ist (Standard), werden die Zugriffe nicht protokolliert.

error_log_file

Pfad der Fehlerprotokolldatei. Sie können entweder einen vollständigen Pfad angeben oder einen Pfad relativ zum aktuellen Arbeitsverzeichnis. Wenn hier kein Wert angegeben ist (Standard), werden die Fehler nicht protokolliert.

Beispiel 28.2: CivetWeb-Beispielkonfiguration in `/etc/ceph/ceph.conf` #

cephuser@adm > ceph config set rgw.myrealm.myzone.ses-min2.ingabw \
 rgw_frontends civetweb port=8000+443s request_timeout_ms=30000 \
 error_log_file=/var/log/radosgw/civetweb.error.log

28.5.2.3 Allgemeine Optionen #Edit source

ssl_certificate: Pfad zur SSL-Zertifikatsdatei für SSL-fähige Endpunkte.
Präfix: Eine Präfixzeichenkette, die in die URI aller Anforderungen eingefügt wird. Ein Frontend, das ausschließlich mit Swift arbeitet, könnte beispielsweise das URI-Präfix /swift ausgeben.

Diese Seite drucken

Betriebs- und Verwaltungshandbuch

28 Konfiguration des Ceph-Clusters #Edit source

28.1 Konfigurieren der Datei ceph.conf #Edit source

Wichtig

28.1.1 Zugreifen auf ceph.conf innerhalb der Container-Images #Edit source

Wichtig

28.2 Konfigurationsdatenbank #Edit source

28.2.1 Konfigurieren von Abschnitten und Masken #Edit source

28.2.2 Festlegen und Lesen von Konfigurationsoptionen #Edit source

28.2.3 Konfigurieren von Daemons zur Laufzeit #Edit source

Anmerkung

28.2.3.1 Überschreiben von Werten #Edit source

Tipp

Tipp

28.2.3.2 Anzeigen der Laufzeiteinstellungen #Edit source

28.3 config-key-Speicher #Edit source

Tipp

28.3.1 iSCSI Gateway #Edit source

28.4 Ceph OSD und BlueStore #Edit source

28.4.1 Konfigurieren der automatischen Cache-Größe #Edit source

Anmerkung

Anmerkung

28.5 Ceph Object Gateway #Edit source

28.5.1 Allgemeine Einstellungen #Edit source

Einstellungen für mehrere Standorte #

Swift-Einstellungen #

Warnung

Protokollierungseinstellungen #

Keystone-Einstellungen #

28.5.1.1 Weitere Hinweise #Edit source

28.5.2 Konfigurieren von HTTP-Frontends #Edit source

28.5.2.1 Beast #Edit source

Beispiel 28.1: Beispiel einer Beast-Konfiguration #

28.5.2.2 CivetWeb #Edit source

Beispiel 28.2: CivetWeb-Beispielkonfiguration in /etc/ceph/ceph.conf #

28.5.2.3 Allgemeine Optionen #Edit source

28.1 Konfigurieren der Datei `ceph.conf` #Edit source

28.1.1 Zugreifen auf `ceph.conf` innerhalb der Container-Images #Edit source

28.3 `config-key`-Speicher #Edit source

Beispiel 28.2: CivetWeb-Beispielkonfiguration in `/etc/ceph/ceph.conf` #