8 Bereitstellen der verbleibenden wichtigsten Services mit cephadm #

Mit folgendem Kommando werden der aktuelle Modus und Status des Ceph-Orchestrators angezeigt.

cephuser@adm > ceph orch status

Führen Sie zum Auflisten aller Datenträgergeräte folgendes Kommando aus:

cephuser@adm > ceph orch device ls
Hostname   Path      Type  Serial  Size   Health   Ident  Fault  Available
ses-master /dev/vdb  hdd   0d8a... 10.7G  Unknown  N/A    N/A    No
ses-min1   /dev/vdc  hdd   8304... 10.7G  Unknown  N/A    N/A    No
ses-min1   /dev/vdd  hdd   7b81... 10.7G  Unknown  N/A    N/A    No
[...]

Tipp: Services und Daemons

Service ist ein allgemeiner Begriff für einen Ceph-Service eines bestimmten Typs, zum Beispiel Ceph Manager.

Daemon ist eine bestimmte Instanz eines Service, z. B. ein Prozess mgr.ses-min1.gdlcik, der auf einem Knoten namens ses-min1 ausgeführt wird.

Führen Sie zum Auflisten aller Services, die cephadm kennt, folgendes Kommando aus:

cephuser@adm > ceph orch ls
NAME  RUNNING  REFRESHED  AGE  PLACEMENT  IMAGE NAME                  IMAGE ID
mgr       1/0  5m ago     -    <no spec>  registry.example.com/[...]  5bf12403d0bd
mon       1/0  5m ago     -    <no spec>  registry.example.com/[...]  5bf12403d0bd

Tipp

Sie können die Liste mit dem optionalen Parameter --host auf Services auf einem bestimmten Knoten und mit dem optionalen Parameter --service-type auf Services eines bestimmten Typs beschränken. Akzeptiert werden die Typen mon, osd, mgr, mds und rgw.

Führen Sie folgendes Kommando aus, um alle von cephadm bereitgestellten aktiven Daemons aufzulisten:

cephuser@adm > ceph orch ps
NAME            HOST     STATUS   REFRESHED AGE VERSION    IMAGE ID     CONTAINER ID
mgr.ses-min1.gd ses-min1 running) 8m ago    12d 15.2.0.108 5bf12403d0bd b8104e09814c
mon.ses-min1    ses-min1 running) 8m ago    12d 15.2.0.108 5bf12403d0bd a719e0087369

Tipp

Fragen Sie den Status eines bestimmten Daemons mit --daemon_type und --daemon_id ab. Bei OSDs ist die ID die numerische OSD-ID. Bei MDS ist die ID der Name des Dateisystems:

cephuser@adm > ceph orch ps --daemon_type osd --daemon_id 0
cephuser@adm > ceph orch ps --daemon_type mds --daemon_id my_cephfs

Sie können für jede Art von Service eine eigene Spezifikationsdatei erstellen, wie zum Beispiel:

root@master # cat nfs.yml
service_type: nfs
service_id: EXAMPLE_NFS
placement:
  hosts:
  - ses-min1
  - ses-min2
spec:
  pool: EXAMPLE_POOL
  namespace: EXAMPLE_NAMESPACE

Alternativ können Sie mehrere (oder alle) Servicetypen in einer Datei angeben, z. B. cluster.yml, die beschreibt, auf welchen Knoten bestimmte Services ausgeführt werden sollen. Denken Sie daran, einzelne Servicetypen mit drei Bindestrichen (---) zu trennen:

cephuser@adm > cat cluster.yml
service_type: nfs
service_id: EXAMPLE_NFS
placement:
  hosts:
  - ses-min1
  - ses-min2
spec:
  pool: EXAMPLE_POOL
  namespace: EXAMPLE_NAMESPACE
---
service_type: rgw
service_id: REALM_NAME.ZONE_NAME
placement:
  hosts:
  - ses-min1
  - ses-min2
  - ses-min3
---
[...]

Die oben genannten Eigenschaften haben folgende Bedeutung:

Tipp: Anwenden spezifischer Services

Ceph-Cluster-Services haben in der Regel eine Reihe von für sie spezifischen Eigenschaften. Beispiele und Details zu den Spezifikationen der einzelnen Services finden Sie in Abschnitt 8.3, „Bereitstellen von Ceph-Services“.

Zum Bereitstellen von Ceph-Services muss cephadm wissen, auf welchen Knoten sie bereitgestellt werden sollen. Verwenden Sie die Eigenschaft placement und führen Sie die Host-Kurznamen der Knoten auf, für die der Service gilt:

cephuser@adm > cat cluster.yml
[...]
placement:
  hosts:
  - host1
  - host2
  - host3
[...]

Nachdem Sie eine vollständige cluster.yml-Datei mit Spezifikationen zu allen Services und deren Platzierung erstellt haben, können Sie den Cluster mit folgendem Kommando anwenden:

cephuser@adm > ceph orch apply -i cluster.yml

Führen Sie zum Anzeigen des Clusterstatus das Kommando ceph orch aus. Weitere Informationen finden Sie unter Abschnitt 8.1.1, „Anzeigen des Orchestrator-Status“.

Obwohl Sie dem Ceph-Cluster Services mithilfe der Spezifikationsdateien bereitgestellt haben (wie in Abschnitt 8.2, „Service- und Platzierungsspezifikation“ beschrieben), kann die Konfiguration des Clusters während seines Betriebs von der ursprünglichen Spezifikation abweichen. Möglicherweise haben Sie auch die Spezifikationsdateien versehentlich entfernt.

Führen Sie zum Abrufen der vollständigen Spezifikation eines aktiven Clusters folgendes Kommando aus:

cephuser@adm > ceph orch ls --export
placement:
  hosts:
  - hostname: ses-min1
    name: ''
    network: ''
service_id: my_cephfs
service_name: mds.my_cephfs
service_type: mds
---
placement:
  count: 2
service_name: mgr
service_type: mgr
---
[...]

Tipp

Sie können die Option --format anhängen, um das Standard-Ausgabeformat yaml zu ändern. Sie können zwischen json, json-pretty oder yaml wählen. Beispiel:

ceph orch ls --export --format json

Für den Ceph-Cluster werden drei oder fünf MONs bereitgestellt, die auf verschiedenen Knoten verteilt sind. Wenn sich fünf oder mehr Knoten im Cluster befinden, empfehlen wir die Bereitstellung von fünf MONs. Es hat sich bewährt, MGRs auf denselben Knoten wie MONs zu installieren.

Wichtig: Beziehen Sie den Bootstrap-MON ein

Wenn Sie MONs und MGRs bereitstellen, denken Sie daran, den ersten MON einzubeziehen, den Sie bei der Konfiguration des Basisclusters in Abschnitt 7.2.5, „Festlegen des ersten MON/MGR-Knotens“ hinzugefügt haben.

Wenden Sie zum Bereitstellen von MONs folgende Spezifikation an:

service_type: mon
placement:
  hosts:
  - ses-min1
  - ses-min2
  - ses-min3

Anmerkung

Wenn Sie einen weiteren Knoten hinzufügen müssen, hängen Sie den Hostnamen an dieselbe YAML-Liste an. Beispiel:

service_type: mon
placement:
 hosts:
 - ses-min1
 - ses-min2
 - ses-min3
 - ses-min4

Wenden Sie auf ähnliche Weise zum Bereitstellen von MONs folgende Spezifikationen an:

Wichtig

Stellen Sie sicher, dass mindestens drei Ceph Manager in jeder Bereitstellung vorhanden sind.

service_type: mgr
placement:
  hosts:
  - ses-min1
  - ses-min2
  - ses-min3

Tipp

Wenn sich MONs oder MGRs nicht im gleichen Teilnetz befinden, müssen Sie die Teilnetzadressen anhängen. Beispiel:

service_type: mon
placement:
  hosts:
  - ses-min1:10.1.2.0/24
  - ses-min2:10.1.5.0/24
  - ses-min3:10.1.10.0/24

Wichtig: Wenn ein Speichergerät verfügbar ist

Ein Speichergerät gilt als verfügbar, wenn alle folgenden Bedingungen erfüllt sind:

• Das Gerät hat keine Partitionen.

• Das Gerät hat keinen LVM-Status.

• Das Gerät ist nicht eingehängt.

• Das Gerät enthält kein Dateisystem.

• Das Gerät enthält kein BlueStore-OSD.

• Das Gerät ist größer als 5 GB.

Wenn die oben genannten Bedingungen nicht erfüllt sind, verweigert Ceph die Bereitstellung derartiger OSDs.

Zum Bereitstellen von OSDs haben Sie zwei Möglichkeiten:

Für CephFS sind ein oder mehrere Metadata Server (MDS)-Services erforderlich. Wenn Sie ein CephFS erstellen möchten, erstellen Sie zunächst MDS-Server durch Anwenden der folgenden Spezifikation:

Anmerkung

Stellen Sie sicher, dass Sie mindestens zwei Pools, einen für CephFS-Daten und einen für CephFS-Metadaten, erstellt haben, bevor Sie die folgende Spezifikation anwenden.

service_type: mds
service_id: CEPHFS_NAME
placement:
  hosts:
  - ses-min1
  - ses-min2
  - ses-min3

Erstellen Sie das CephFS, sobald die MDS funktionsfähig sind:

ceph fs new CEPHFS_NAME metadata_pool data_pool

cephadm stellt ein Object Gateway als eine Sammlung von Daemons bereit, die einen bestimmten Bereich und eine Zone verwalten.

Sie können entweder einen Object-Gateway-Service mit einem bereits vorhandenen Bereich und einer bereits vorhandenen Zone verknüpfen (weitere Informationen finden Sie im Abschnitt 21.13, „Object Gateways an mehreren Standorten“), oder Sie können einen nicht vorhandenen REALM_NAME (Bereichsnamen) und ZONE_NAME (Zonennamen) angeben, die dann automatisch erstellt werden, nachdem Sie die folgende Konfiguration angewendet haben:

service_type: rgw
service_id: REALM_NAME.ZONE_NAME
placement:
  hosts:
  - ses-min1
  - ses-min2
  - ses-min3
spec:
  rgw_realm: RGW_REALM
  rgw_zone: RGW_ZONE

8.3.4.1 Verwenden des sicheren SSL-Zugangs #

 

Um eine sichere SSL-Verbindung zum Object Gateway zu verwenden, benötigen Sie ein Paar gültiger SSL-Zertifikats- und Schlüsseldateien (weitere Details finden Sie im Abschnitt 21.7, „Aktivieren von HTTPS/SSL für Object Gateways“). Sie müssen SSL aktivieren, eine Portnummer für SSL-Verbindungen sowie die SSL-Zertifikats- und Schlüsseldateien angeben.

Nehmen Sie Folgendes in Ihre Spezifikation auf, um SSL zu aktivieren und die Portnummer anzugeben:

spec:
  ssl: true
  rgw_frontend_port: 443

Um das SSL-Zertifikat und den Schlüssel festzulegen, können Sie deren Inhalte direkt in die YAML-Spezifikationsdatei einfügen. Das Pipe-Zeichen (|) am Zeilenende weist den Parser darauf hin, dass er eine mehrzeilige Zeichenkette als Wert erwarten soll. Beispiel:

spec:
  ssl: true
  rgw_frontend_port: 443
  rgw_frontend_ssl_certificate: |
   -----BEGIN CERTIFICATE-----
   MIIFmjCCA4KgAwIBAgIJAIZ2n35bmwXTMA0GCSqGSIb3DQEBCwUAMGIxCzAJBgNV
   BAYTAkFVMQwwCgYDVQQIDANOU1cxHTAbBgNVBAoMFEV4YW1wbGUgUkdXIFNTTCBp
   [...]
   -----END CERTIFICATE-----
   rgw_frontend_ssl_key: |
   -----BEGIN PRIVATE KEY-----
   MIIJRAIBADANBgkqhkiG9w0BAQEFAASCCS4wggkqAgEAAoICAQDLtFwg6LLl2j4Z
   BDV+iL4AO7VZ9KbmWIt37Ml2W6y2YeKX3Qwf+3eBz7TVHR1dm6iPpCpqpQjXUsT9
   [...]
   -----END PRIVATE KEY-----

Tipp

Statt den Inhalt der SSL-Zertifikats- und Schlüsseldateien einzufügen, können Sie die Schlüsselwörter rgw_frontend_ssl_certificate: und rgw_frontend_ssl_key: weglassen und sie in die Konfigurationsdatenbank hochladen:

cephuser@adm > ceph config-key set rgw/cert/REALM_NAME/ZONE_NAME.crt \
 -i SSL_CERT_FILE
cephuser@adm > ceph config-key set rgw/cert/REALM_NAME/ZONE_NAME.key \
 -i SSL_KEY_FILE

8.3.4.1.1 Konfigurieren des Object Gateway zur Überwachung von Port 443 und 80 #

 

Führen Sie die folgenden Schritte aus, um das Object Gateway zur Überwachung beider Ports, Port 443 (HTTPS) und Port 80 (HTTP), zu konfigurieren:

Anmerkung

Die Kommandos in diesem Verfahren verwenden den Standardwert default für den Bereich und die Zone.

1. Stellen Sie das Object Gateway bereit, indem Sie eine Spezifikationsdatei angeben. Weitere Informationen zur Object-Gateway-Spezifikation finden Sie in Abschnitt 8.3.4, „Bereitstellen von Object Gateways“. Verwenden Sie den folgenden Befehl:

   cephuser@adm > ceph orch apply -i SPEC_FILE

2. Wenn SSL-Zertifikate nicht in der Spezifikationsdatei enthalten sind, fügen Sie sie mit dem folgenden Kommando hinzu:

   cephuser@adm > ceph config-key set rgw/cert/default/default.crt -i certificate.pem
   cephuser@adm > ceph config-key set rgw/cert/default/default.key -i key.pem

3. Ändern Sie den Standardwert der Option rgw_frontends:

   cephuser@adm > ceph config set client.rgw.default.default rgw_frontends \
    "beast port=80 ssl_port=443"

4. Entfernen Sie die von cephadm erstellte spezifische Konfiguration. Stellen Sie fest, für welches Ziel die Option rgw_frontends konfiguriert wurde, indem Sie dieses Kommando ausführen:

   cephuser@adm > ceph config dump | grep rgw

   Wenn das Ziel beispielsweise client.rgw.default.default.node4.yiewdu lautet, entfernen Sie den aktuellen spezifischen Wert für rgw_frontends:

   cephuser@adm > ceph config rm client.rgw.default.default.node4.yiewdu rgw_frontends

   

   Tipp

   Statt einen Wert für rgw_frontends zu entfernen, können Sie ihn auch angeben. Beispiel:

   cephuser@adm > ceph config set client.rgw.default.default.node4.yiewdu \
    rgw_frontends "beast port=80 ssl_port=443"

5. Starten Sie Object Gateways neu:

   cephuser@adm > ceph orch restart rgw.default.default

service_type: rgw
service_id: REALM_NAME.ZONE_NAME.SUBCLUSTER
placement:
  hosts:
  - ses-min1
  - ses-min2
  - ses-min3
spec:
  rgw_realm: RGW_REALM
  rgw_zone: RGW_ZONE
  subcluster: SUBCLUSTER

iSCSI ist ein Storage Area Network (SAN)-Protokoll, das Clients (genannt Initiators) das Senden von SCSI-Kommandos an SCSI-Speichergeräte (Ziele) auf Remote-Servern ermöglicht.

Wenden Sie die folgende Konfiguration für die Bereitstellung an. Stellen Sie sicher, dass trusted_ip_list die IP-Adressen aller iSCSI-Gateway- und Ceph-Manager-Knoten enthält (wie im folgenden Ausgabebeispiel gezeigt).

Anmerkung

Stellen Sie sicher, dass der Pool erstellt wurde, bevor Sie die folgende Spezifikation anwenden.

service_type: iscsi
service_id: EXAMPLE_ISCSI
placement:
  hosts:
  - ses-min1
  - ses-min2
  - ses-min3
spec:
  pool: EXAMPLE_POOL
  api_user: EXAMPLE_USER
  api_password: EXAMPLE_PASSWORD
  trusted_ip_list: "IP_ADDRESS_1,IP_ADDRESS_2"

Anmerkung

Stellen Sie sicher, dass die für trusted_ip_list aufgelisteten IPs kein Leerzeichen nach der Kommatrennung aufweisen.

spec:
  api_secure: true

spec:
  pool: EXAMPLE_POOL
  api_user: EXAMPLE_USER
  api_password: EXAMPLE_PASSWORD
  trusted_ip_list: "IP_ADDRESS_1,IP_ADDRESS_2"
  api_secure: true
  ssl_cert: |
    -----BEGIN CERTIFICATE-----
    MIIDtTCCAp2gAwIBAgIYMC4xNzc1NDQxNjEzMzc2MjMyXzxvQ7EcMA0GCSqGSIb3
    DQEBCwUAMG0xCzAJBgNVBAYTAlVTMQ0wCwYDVQQIDARVdGFoMRcwFQYDVQQHDA5T
    [...]
    -----END CERTIFICATE-----
  ssl_key: |
    -----BEGIN PRIVATE KEY-----
    MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQC5jdYbjtNTAKW4
    /CwQr/7wOiLGzVxChn3mmCIF3DwbL/qvTFTX2d8bDf6LjGwLYloXHscRfxszX/4h
    [...]
    -----END PRIVATE KEY-----

Wichtig

NFS Ganesha unterstützt NFS-Version 4.1 und neuer. NFS Ganesha unterstützt nicht NFS-Version 3.

cephadm stellt NFS Ganesha unter Verwendung eines vordefinierten RADOS-Pools und eines optionalen Namespace bereit. Wenden Sie zum Bereitstellen von NFS Ganesha folgende Spezifikation an:

Anmerkung

Sie müssen über einen vordefinierten RADOS-Pool verfügen, da sonst der ceph orch apply-Vorgang fehlschlägt. Weitere Informationen zum Erstellen eines Pools finden Sie im Abschnitt 18.1, „Erstellen eines Pools“.

service_type: nfs
service_id: EXAMPLE_NFS
placement:
  hosts:
  - ses-min1
  - ses-min2
spec:
  pool: EXAMPLE_POOL
  namespace: EXAMPLE_NAMESPACE

Der Service rbd-mirror synchronisiert RADOS-Blockgeräte-Images zwischen zwei Ceph-Clustern (weitere Details finden Sie im Abschnitt 20.4, „RBD-Image-Spiegel“). Stellen Sie rbd-mirror mit folgender Spezifikation bereit:

service_type: rbd-mirror
service_id: EXAMPLE_RBD_MIRROR
placement:
  hosts:
  - ses-min3

Der Überwachungs-Stack besteht aus Prometheus, Prometheus-Exportern, Prometheus Alertmanager und Grafana. Ceph Dashboard nutzt diese Komponenten, um detaillierte Kennzahlen zur Clusternutzung und -leistung zu speichern und zu visualisieren.

Tipp

Wenn für Ihre Bereitstellung benutzerdefinierte oder lokal bereitgestellte Container-Images der Überwachungs-Stack-Services erforderlich sind, finden Sie Informationen hierzu im Abschnitt 16.1, „Konfigurieren von benutzerdefinierten oder lokalen Images“.

Führen Sie zum Bereitstellen des Überwachungs-Stacks folgende Schritte aus:

Wichtig

Prometheus, Grafana und das Ceph Dashboard sind automatisch so konfiguriert, dass sie miteinander kommunizieren. Dies führt zu einer voll funktionsfähigen Grafana-Integration im Ceph Dashboard, wenn es wie oben beschrieben bereitgestellt wird.

Die einzige Ausnahme von dieser Regel ist die Überwachung mit RBD-Images. Weitere Informationen zu diesem Thema finden Sie unter dem Stichwort Abschnitt 16.5.4, „Aktivieren der RBD-Image-Überwachung“.