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

8 Bereitstellen der verbleibenden wichtigsten Services mit cephadm

Nachdem Sie den Ceph-Basiscluster bereitgestellt haben, sollten Sie die wichtigsten Services auf weitere Cluster-Knoten verteilen. Stellen Sie zusätzliche Services bereit, um die Daten des Clusters für Clients zugänglich zu machen.

Derzeit unterstützen wir die Bereitstellung von Ceph-Services auf der Kommandozeile mit dem Ceph-Orchestrator (ceph orch-Unterkommandos).

8.1 Das Kommando ceph orch

Mit dem Ceph-Orchestrator-Kommando ceph orch (einer Schnittstelle zum cephadm-Modul) werden die Clusterkomponenten aufgelistet und Ceph-Services auf neuen Cluster-Knoten bereitgestellt.

8.1.1 Anzeigen des Orchestrator-Status

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

cephuser@adm > ceph orch status

8.1.2 Auflisten von Geräten, Services und Daemons

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

8.2 Service- und Platzierungsspezifikation

Die Spezifikation der Bereitstellung von Ceph-Services erfolgt am besten durch Erstellen einer YAML-formatierten Datei mit der Spezifikation der Services, die Sie bereitstellen möchten.

8.2.1 Erstellen von Servicespezifikationen

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:

service_type

Der Typ des Service. Er kann entweder ein Ceph-Service (mon, mgr, mds, crash, osd oder rbd-mirror), ein Gateway (nfs oder rgw) oder Teil des Überwachungs-Stacks (alertmanager, grafana, node-exporter oder prometheus) sein.

service_id

Der Name des Service. Für Spezifikationen vom Typ mon, mgr, alertmanager, grafana, node-exporter und prometheus ist die Eigenschaft service_id nicht erforderlich.

placement

Gibt an, auf welchen Knoten der Service ausgeführt wird. Weitere Informationen finden Sie in Abschnitt 8.2.2, „Erstellen von Platzierungsspezifikationen“.

spec

Zusätzliche Spezifikation, die für den Servicetyp relevant ist.

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

8.2.2 Erstellen von Platzierungsspezifikationen

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

8.2.3 Anwenden von Clusterspezifikationen

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

8.2.4 Exportieren der Spezifikation eines aktiven Clusters

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

8.3 Bereitstellen von Ceph-Services

Sobald der Basiscluster ausgeführt wird, können Sie Ceph-Services auf weiteren Knoten bereitstellen.

8.3.1 Bereitstellen von Ceph Monitors und Ceph Managers

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

8.3.2 Bereitstellen von Ceph OSDs

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

  • Weisen Sie Ceph an, alle verfügbaren und nicht verwendeten Speichergeräte zu verbrauchen:

    cephuser@adm > ceph orch apply osd --all-available-devices
  • Verwenden Sie DriveGroups (weitere Informationen hierzu finden Sie im Abschnitt 13.4.3, „Hinzufügen von OSDs mit der DriveGroups-Spezifikation“), um OSD-Spezifikationen zu erstellen, die Geräte beschreiben, die basierend auf ihren Eigenschaften bereitgestellt werden. Beispiele hierfür sind der Gerätetyp (SSD oder HDD), die Gerätemodellnamen, die Größe oder die Knoten, auf denen die Geräte vorhanden sind. Wenden Sie dann die Spezifikation mit folgendem Kommando an:

    cephuser@adm > ceph orch apply osd -i drive_groups.yml

8.3.3 Bereitstellen von Metadatenservern

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

8.3.4 Bereitstellen von Object Gateways

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

8.3.4.2 Bereitstellung mit einem Untercluster

Mit Unterclustern können Sie die Knoten in Ihren Clustern organisieren, um Workloads zu isolieren und die elastische Skalierung zu erleichtern. Wenden Sie die folgende Konfiguration an, wenn Sie die Bereitstellung mit einem Untercluster durchführen:

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

8.3.5 Bereitstellen von iSCSI-Gateways

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

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

8.3.5.1 Sichere SSL-Konfiguration

Zur Verwendung einer sicheren SSL-Verbindung zwischen dem Ceph Dashboard und der iSCSI-Ziel-API benötigen Sie ein Paar gültiger SSL-Zertifikate und Schlüsseldateien. Sie können entweder von einer Zertifizierungsstelle ausgestellt oder eigensigniert sein (weitere Informationen finden Sie im Abschnitt 10.1.1, „Erstellen von eigensignierten Zertifikaten“). Nehmen Sie zum Aktivieren von SSL die Einstellung api_secure: true in Ihre Spezifikationsdatei auf:

spec:
  api_secure: true

Um das SSL-Zertifikat und den Schlüssel festzulegen, können Sie den Inhalt 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:
  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-----

8.3.6 Bereitstellen von NFS Ganesha

Wichtig
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
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
  • EXAMPLE_NFS mit einer beliebigen Zeichenkette, die den NFS-Export identifiziert.

  • EXAMPLE_POOL mit dem Namen des Pools, in dem das NFS-Ganesha-RADOS-Konfigurationsobjekt gespeichert werden soll.

  • EXAMPLE_NAMESPACE (optional) mit dem gewünschten Object-Gateway-NFS-Namespace (zum Beispiel ganesha).

8.3.7 Bereitstellung rbd-mirror

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

8.3.8 Bereitstellen des Überwachungs-Stacks

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

  1. Aktivieren Sie das Modul prometheus im Ceph-Manager-Daemon. Dadurch werden die internen Ceph-Kennzahlen offengelegt, so dass Prometheus sie lesen kann:

    cephuser@adm > ceph mgr module enable prometheus
    Anmerkung
    Anmerkung

    Stellen Sie sicher, dass dieses Kommando vor dem Bereitstellen von Prometheus ausgeführt wird. Wenn das Kommando vor der Bereitstellung nicht ausgeführt wurde, müssen Sie Prometheus erneut bereitstellen, um die Konfiguration von Prometheus zu aktualisieren:

    cephuser@adm > ceph orch redeploy prometheus
  2. Erstellen Sie eine Spezifikationsdatei (z. B. monitoring.yaml) mit einem Inhalt ähnlich dem folgenden:

    service_type: prometheus
    placement:
      hosts:
      - ses-min2
    ---
    service_type: node-exporter
    ---
    service_type: alertmanager
    placement:
      hosts:
      - ses-min4
    ---
    service_type: grafana
    placement:
      hosts:
      - ses-min3
  3. Wenden Sie die Überwachungsservices mit folgendem Kommando an:

    cephuser@adm > ceph orch apply -i monitoring.yaml

    Es kann ein oder zwei Minuten dauern, bis die Überwachungsservices bereitgestellt sind.

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

Diese Seite drucken