SUSE Enterprise Storage 6: Kapitel 21. NFS Ganesha: Exportieren von Ceph-Daten über NFS (Verwaltungshandbuch)

documentation.suse.com › Dokumentation zu SUSE Enterprise Storage 6 › Verwaltungshandbuch › Zugreifen auf Cluster-Daten › NFS Ganesha: Exportieren von Ceph-Daten über NFS

InhaltInhalt

Verwaltungshandbuch

Navigation←→

Bezieht sich auf SUSE Enterprise Storage 6

21 NFS Ganesha: Exportieren von Ceph-Daten über NFS #Edit source

21.1 Installation
21.2 Konfiguration
21.3 Benutzerdefinierte NFS Ganesha-Rollen
21.4 Starten oder Neustarten von NFS Ganesha
21.5 Festlegen des Protokollierumfangs
21.6 Verifizieren der exportierten NFS-Freigabe
21.7 Einhängen der exportierten NFS-Freigabe

NFS Ganesha ist ein NFS-Server (weitere Informationen hierzu finden Sie unter Sharing File Systems with NFS (Freigabe von Dateisystemen mit NFS) ), der in einem Benutzeradressenbereich anstatt als Teil des Betriebssystem-Kernels ausgeführt wird. Mit NFS Ganesha binden Sie Ihren eigenen Speichermechanismus ein, wie zum Beispiel Ceph, und greifen von einem beliebigen NFS Client darauf zu.

S3 Buckets werden pro Benutzer zu NFS exportiert, beispielsweise über den Pfad GANESHA_NODE:/USERNAME/BUCKETNAME.

Ein CephFS wird standardmäßig über den Pfad GANESHA_NODE:/cephfs exportiert.

Anmerkung: NFS Ganesha-Leistung

Angesichts des erhöhten Protokoll-Overheads und der zusätzlichen Latenz durch zusätzliche Netzwerk-Hops zwischen Client und Speicher kann ein Zugriff auf Ceph über einen NFS-Gateway die Anwendungsleistung im Vergleich zu nativen CephFS- oder Object Gateway-Clients erheblich senken.

21.1 Installation #Edit source

Die Installationsanweisungen finden Sie unter Kapitel 12, Installation von NFS Ganesha.

21.2 Konfiguration #Edit source

Eine Liste aller Parameter, die in der Konfigurationsdatei verfügbar sind, finden Sie unter:

man ganesha-config
man ganesha-ceph-config für Optionen zur Dateisystem-Abstraktionsschicht (File System Abstraction Layer, FSAL) zu CephFS.
man ganesha-rgw-config für FSAL-Optionen zum Object Gateway.

Dieser Abschnitt enthält Informationen, die Ihnen beim Konfigurieren des NFS Ganesha-Servers für den Export der Cluster-Daten über das Object Gateway und CephFS helfen.

Die NFS Ganesha-Konfiguration setzt sich aus zwei Teilen zusammen: Servicekonfiguration und Exportkonfiguration. Die Servicekonfiguration wird durch /etc/ganesha/ganesha.conf gesteuert. Beachten Sie, dass Änderungen an dieser Datei überschrieben werden, wenn DeepSea-Phase 4 ausgeführt wird. Bearbeiten Sie zum dauerhaften Ändern der Einstellungen die Datei /srv/salt/ceph/ganesha/files/ganesha.conf.j2, die sich am Salt Master befindet. Die Exportkonfiguration wird im Ceph Cluster als RADOS-Objekte gespeichert.

21.2.1 Servicekonfiguration #Edit source

Die Servicekonfiguration wird in /etc/ganesha/ganesha.conf gespeichert und steuert alle Einstellungen für NFS Ganesha-Daemons, u. a. den Speicherort der Exportkonfiguration im Ceph Cluster. Beachten Sie, dass Änderungen an dieser Datei überschrieben werden, wenn DeepSea-Phase 4 ausgeführt wird. Bearbeiten Sie zum dauerhaften Ändern der Einstellungen die Datei /srv/salt/ceph/ganesha/files/ganesha.conf.j2, die sich am Salt Master befindet.

21.2.1.1 Abschnitt RADOS_URLS #Edit source

Im Abschnitt RADOS_URLS wird der Ceph Cluster-Zugriff zum Auslesen der NFS Ganesha-Konfiguration aus RADOS-Objekten konfiguriert.

RADOS_URLS {
  Ceph_Conf = /etc/ceph/ceph.conf;

  UserId = "ganesha.MINION_ID";
  watch_url = "rados://RADOS_POOL/ganesha/conf-MINION_ID";
}

Ceph_Conf: Dateipfad der Ceph-Konfiguration.
UserId: cephx-Benutzer-ID.
watch_url: RADOS-Objekt-URL, die auf Neustartbenachrichtigungen überwacht werden soll .

21.2.1.2 RGW-Abschnitt #Edit source

RGW {
  ceph_conf = "/etc/ceph/ceph.conf";
  name = "name";
  cluster = "ceph";
}

ceph_conf: Zeigt auf die Datei ceph.conf. Bei der Bereitstellung mit DeepSea ist es nicht erforderlich, diesen Wert zu ändern.
name: Der Name des Ceph Client-Benutzers. der von NFS Ganesha verwendet wird.
cluster: Name des Ceph Clusters. SUSE Enterprise Storage 6 unterstützt derzeit nur einen Cluster-Namen, nämlich standardmäßig ceph.

21.2.1.3 RADOS-Objekt-URL #Edit source

%url rados://RADOS_POOL/ganesha/conf-MINION_ID

NFS Ganesha unterstützt das Auslesen der Konfiguration aus einem RADOS-Objekt. Mit der Anweisung %url kann eine RADOS-URL angegeben werden, die den Speicherort des RADOS-Objekts bezeichnet.

Für eine RADOS-URL stehen zwei Formate zur Auswahl: rados://<POOL>/<OBJECT> oder rados://<POOL>/<NAMESPACE>/<OBJECT>. POOL bezeichnet hierbei den RADOS-Pool, in dem das Objekt gespeichert ist, NAMESPACE ist der Pool-Namespace, in dem das Objekt gespeichert ist, und OBJECT entspricht dem Objektnamen.

Zur Unterstützung der NFS Ganesha-Verwaltungsfunktionen im Ceph Dashboard muss das RADOS-Objekt für die einzelnen Service-Daemons bestimmte Namenskonventionen einhalten. Der Name des Objekts muss als conf-MINION_ID angegeben werden, wobei MINION_ID die Salt Minion-ID des Knotens bezeichnet, auf dem dieser Service ausgeführt wird.

Diese URL wird in DeepSea ordnungsgemäß erzeugt und Sie müssen keine Änderungen vornehmen.

21.2.1.4 Ändern der standardmäßigen NFS Ganesha Ports #Edit source

NFS Ganesha verwendet standardmäßig Port 2049 für NFS und 875 für die Unterstützung von „rquota“. Die standardmäßigen Portnummern ändern Sie mit den Optionen NFS_Port und RQUOTA_Port im Abschnitt NFS_CORE_PARAM. Beispiel:

NFS_CORE_PARAM
{
NFS_Port = 2060;
RQUOTA_Port = 876;
}

21.2.2 Exportkonfiguration #Edit source

Die Exportkonfiguration wird als RADOS-Objekte im Ceph Cluster gespeichert. Die einzelnen Exportblöcke werden jeweils in getrennten RADOS-Objekten mit dem Namen export-<id> gespeichert, wobei <id> mit dem Attribut Export_ID der Exportkonfiguration übereinstimmen muss. Die Exporte und die NFS Ganesha-Services werden mithilfe der conf-MINION_ID-Objekte verknüpft. Die einzelnen Serviceobjekte enthalten eine Liste mit RADOS-URLs für die verschiedenen Exporte, die mit dem betreffenden Service exportiert wurden. Ein Exportblock sieht wie folgt aus:

EXPORT
{
  Export_Id = 1;
  Path = "/";
  Pseudo = "/";
  Access_Type = RW;
  Squash = No_Root_Squash;
  [...]
  FSAL {
    Name = CEPH;
  }
}

Zum Erstellen des RADOS-Objekts für den obigen Exportblock muss zunächst der Exportblock-Code in einer Datei gespeichert werden. Anschließend können Sie den Inhalt der zuvor gespeicherten Datei mit dem RADOS CLI-Werkzeug in einem RADOS-Objekt speichern.

cephadm@adm > rados -p POOL -N NAMESPACE put export-EXPORT_ID EXPORT_FILE

Weil sie das Exportobjekt gestellt haben, können Sie den Export mit einer Serviceinstanz verknüpfen. Ergänzen Sie hierzu das Serviceobjekt mit der entsprechenden RADOS-URL des Exportobjekts. In den folgenden Abschnitten erfahren Sie, wie Sie einen Exportblock konfigurieren.

21.2.2.1 Export-Hauptabschnitt #Edit source

Export_Id

Jeder Export benötigt eine eindeutige „Export_Id“ (obligatorisch).

Path

Exportpfad im entsprechenden CephFS Pool (obligatorisch). Damit können Unterverzeichnisse vom CephFS exportiert werden.

Pseudo

Pfad für das NFS-Exportziel (obligatorisch für NFSv4). Damit wird definiert, unter welchem NFS-Exportpfad die exportierten Daten verfügbar sind.

Beispiel: Mit dem Wert /cephfs/ und nach dem Ausführen von

root # mount GANESHA_IP:/cephfs/ /mnt/

Die CephFS-Daten sind im Verzeichnis /mnt/cephfs/ am Client verfügbar.

Access_Type

„RO“ für schreibgeschützten Zugriff, „RW“ für Schreib-/Lesezugriff und „None“ für „kein Zugriff“.

Tipp: Beschränkung des Zugriffs auf Clients

Wenn Sie Access_Type = RW im Hauptabschnitt EXPORT beibehalten und den Zugriff auf einen bestimmten Client im Abschnitt CLIENT beschränken, können andere Clients dennoch eine Verbindung herstellen. Soll der Zugriff auf alle Clients deaktiviert und nur für bestimmte Clients aktiviert werden, geben Sie Access_Type = None im Abschnitt EXPORT an und legen Sie dann im Abschnitt CLIENT einen weniger restriktiven Zugriffsmodus für mindestens einen Client fest:

EXPORT {

	FSAL {
 access_type = "none";
 [...]
 }

 CLIENT {
		clients = 192.168.124.9;
		access_type = "RW";
		[...]
 }
[...]
}

Squash

NFS Squash-Option.

FSAL

Exportieren der Dateisystem-Abstraktionsschicht (File System Abstraction Layer, FSAL). Weitere Informationen hierzu finden Sie in Abschnitt 21.2.2.2, „FSAL-Unterabschnitt“.

21.2.2.2 FSAL-Unterabschnitt #Edit source

EXPORT
{
  [...]
  FSAL {
    Name = CEPH;
  }
}

Name: Definiert, welches Back-End NFS Ganesha verwendet. Zulässige Werte sind CEPH für CephFS oder RGW für das Object Gateway. Je nach Auswahl muss eine role-mds oder role-rgw in der policy.cfg definiert werden.

21.3 Benutzerdefinierte NFS Ganesha-Rollen #Edit source

Sie können NFS Ganesha-Rollen für Cluster Nodes definieren. Diese Rollen werden dann den Nodes in der policy.cfg zugewiesen. Die Rollen ermöglichen Folgendes:

Getrennte NFS Ganesha Nodes für den Zugriff auf das Object Gateway und CephFS.
Zuweisen verschiedener Object Gateway-Benutzer zu NFS Ganesha Nodes.

Mit verschiedenen Object Gateway-Benutzern können NFS Ganesha Nodes auf verschiedene S3 Buckets zugreifen. S3 Buckets werden für die Zugriffskontrolle verwendet. Hinweis: S3 Buckets dürfen nicht mit Ceph Buckets verwechselt werden, die in der CRUSH Map verwendet werden.

21.3.1 Verschiedene Object Gateway-Benutzer für NFS Ganesha #Edit source

Im folgenden Verfahrensbeispiel für den Salt Master sehen Sie, wie zwei NFS Ganesha-Rollen mit verschiedenen Object Gateway-Benutzern erstellt werden. In diesem Beispiel werden die Rollen gold und silver verwendet, für die DeepSea bereits Beispiele zu Konfigurationsdateien bereitstellt.

Öffnen Sie die Datei /srv/pillar/ceph/stack/global.yml mit einem Editor Ihrer Wahl. Erstellen Sie die Datei, falls noch nicht vorhanden.
Die Datei muss folgende Zeilen enthalten:
```
rgw_configurations:
  - rgw
  - silver
  - gold
ganesha_configurations:
  - silver
  - gold
```
Diese Rollen werden später in der policy.cfg zugewiesen.
Erstellen Sie eine Datei /srv/salt/ceph/rgw/users/users.d/gold.yml und fügen Sie folgenden Inhalt hinzu:
```
- { uid: "gold1", name: "gold1", email: "gold1@demo.nil" }
```
Erstellen sie eine Datei /srv/salt/ceph/rgw/users/users.d/silver.yml und fügen Sie folgenden Inhalt hinzu:
```
- { uid: "silver1", name: "silver1", email: "silver1@demo.nil" }
```
Nun müssen für jede Rolle Schablonen für die ganesha.conf erstellt werden. Die Originalschablone von DeepSea ist ein guter Anfang. Erstellen Sie zwei Kopien:
```
root@master # cd /srv/salt/ceph/ganesha/files/
root@master # cp ganesha.conf.j2 silver.conf.j2
root@master # cp ganesha.conf.j2 gold.conf.j2
```
Für die neuen Rollen sind Schlüsselbunde für den Zugriff auf den Cluster erforderlich. Kopieren Sie ganesha.j2, um den Zugriff zu gewähren:
```
root@master # cp ganesha.j2 silver.j2
root@master # cp ganesha.j2 gold.j2
```

Kopieren Sie den Schlüsselbund für das Object Gateway:

root@master # cd /srv/salt/ceph/rgw/files/
root@master # cp rgw.j2 silver.j2
root@master # cp rgw.j2 gold.j2

Object Gateway benötigt auch die Konfiguration für die verschiedenen Rollen:

root@master # cd /srv/salt/ceph/configuration/files/
root@master # cp ceph.conf.rgw silver.conf
root@master # cp ceph.conf.rgw gold.conf

Weisen Sie die neu erstellten Rollen zu den Cluster Nodes in der Datei /srv/pillar/ceph/proposals/policy.cfg zu:
```
role-silver/cluster/NODE1.sls
role-gold/cluster/NODE2.sls
```
Ersetzen Sie NODE1 und NODE2 durch die Namen der Nodes, denen Sie die Rollen zuweisen möchten.
Führen Sie die DeepSea-Phasen 0 bis 4 aus.

21.3.2 Trennen der CephFS- und Object Gateway-FSAL #Edit source

Im folgenden Verfahrensbeispiel für den Salt Master sehen Sie, wie zwei neue verschiedene Rollen erstellt werden, die CephFS und Object Gateway verwenden:

Öffnen Sie die Datei /srv/pillar/ceph/rgw.sls mit einem Editor Ihrer Wahl. Erstellen Sie die Datei, falls noch nicht vorhanden.

Die Datei muss folgende Zeilen enthalten:

rgw_configurations:
  ganesha_cfs:
    users:
      - { uid: "demo", name: "Demo", email: "demo@demo.nil" }
  ganesha_rgw:
    users:
      - { uid: "demo", name: "Demo", email: "demo@demo.nil" }

ganesha_configurations:
  - ganesha_cfs
  - ganesha_rgw

Diese Rollen werden später in der policy.cfg zugewiesen.

Nun müssen für jede Rolle Schablonen für die ganesha.conf erstellt werden. Die Originalschablone von DeepSea ist ein guter Anfang. Erstellen Sie zwei Kopien:

root@master # cd /srv/salt/ceph/ganesha/files/
root@master # cp ganesha.conf.j2 ganesha_rgw.conf.j2
root@master # cp ganesha.conf.j2 ganesha_cfs.conf.j2

Bearbeiten Sie die Datei ganesha_rgw.conf.j2 und entfernen Sie den Abschnitt:

{% if salt.saltutil.runner('select.minions', cluster='ceph', roles='mds') != [] %}
        [...]
{% endif %}

Bearbeiten Sie die Datei ganesha_cfs.conf.j2 und entfernen Sie den Abschnitt:

{% if salt.saltutil.runner('select.minions', cluster='ceph', roles=role) != [] %}
        [...]
{% endif %}

Für die neuen Rollen sind Schlüsselbunde für den Zugriff auf den Cluster erforderlich. Kopieren Sie ganesha.j2, um den Zugriff zu gewähren:
```
root@master # cp ganesha.j2 ganesha_rgw.j2
root@master # cp ganesha.j2 ganesha_cfs.j2
```
Die Zeile caps mds = "allow *" kann aus der Datei ganesha_rgw.j2 entfernt werden.

Kopieren Sie den Schlüsselbund für das Object Gateway:

root@master # cp /srv/salt/ceph/rgw/files/rgw.j2 \
/srv/salt/ceph/rgw/files/ganesha_rgw.j2

Object Gateway benötigt die Konfiguration für die neue Rolle:

root@master # cp /srv/salt/ceph/configuration/files/ceph.conf.rgw \
/srv/salt/ceph/configuration/files/ceph.conf.ganesha_rgw

Weisen Sie die neu erstellten Rollen zu den Cluster Nodes in der Datei /srv/pillar/ceph/proposals/policy.cfg zu:
```
role-ganesha_rgw/cluster/NODE1.sls
role-ganesha_cfs/cluster/NODE1.sls
```
Ersetzen Sie NODE1 und NODE2 durch die Namen der Nodes, denen Sie die Rollen zuweisen möchten.
Führen Sie die DeepSea-Phasen 0 bis 4 aus.

21.3.3 Unterstützte Vorgänge #Edit source

Die RGW-NFS-Schnittstelle unterstützt die meisten Operationen für Dateien und Verzeichnisse, mit den folgenden Einschränkungen:

Links (u. a. symbolische Links) werden nicht unterstützt.
NFS-Zugriffssteuerungslisten (ACLs) werden nicht unterstützt. Unix-Benutzer- und Gruppeneigentum/-berechtigungen werden unterstützt.
Verzeichnisse können nicht verschoben oder umbenannt werden. Sie können Dateien zwischen Verzeichnissen verschieben.
Es wird nur eine vollständige, sequenzielle Schreib-E/A unterstützt. Schreiboperationen werden daher als Uploads erzwungen. Zahlreiche typische E/A-Operationen, z. B. die Bearbeitung von Dateien im Speicherort, scheitern daher zwangsläufig, da sie nichtsequenzielle Speichervorgänge umfassen. Bestimmte Dateidienstprogramme schreiben scheinbar sequenziell (z. B. bestimmte Versionen von GNU-tar), scheitern jedoch aufgrund der seltenen nichtsequenziellen Speichervorgänge. Beim Einhängen per NFS kann im Allgemeinen durch synchrones Einhängen erzwungen werden, dass die sequenzielle E/A einer Anwendung sequenzielle Schreibvorgänge auf den NFS-Server durchführt (Option -o sync). NFS-Clients, die nicht synchron eingehängt werden können (z. B. Microsoft Windows*), können keine Dateien hochladen.
NFS-RGW unterstützt Schreib-/Leseoperationen lediglich für Blockgrößen unter 4 MB.

21.4 Starten oder Neustarten von NFS Ganesha #Edit source

Führen Sie zum Aktivieren und Starten des NFS Ganesha Service folgende Kommandos aus:

root@minion > systemctl enable nfs-ganesha
root@minion > systemctl start nfs-ganesha

Starten Sie NFS Ganesha neu mit:

root@minion > systemctl restart nfs-ganesha

Wenn NFS Ganesha gestartet oder neu gestartet wird, hat es eine Kulanzzeitüberschreitung von 90 Sekunden für NFS v4. Während des Kulanzzeitraums werden neue Anforderungen von Clients aktiv abgelehnt. Somit erfahren Clients möglicherweise eine Verlangsamung ihrer Anforderungen, wenn sich NFS im Kulanzzustand befindet.

21.5 Festlegen des Protokollierumfangs #Edit source

Sie ändern die standardmäßige Fehlersuchestufe NIV_EVENT durch Bearbeiten der Datei /etc/sysconfig/nfs-ganesha. Ersetzen Sie NIV_EVENT durch NIV_DEBUG oder NIV_FULL_DEBUG. Durch Erhöhen der Protokollausführlichkeit können in den Protokolldateien große Datenmengen produziert werden.

OPTIONS="-L /var/log/ganesha/ganesha.log -f /etc/ganesha/ganesha.conf -N NIV_EVENT"

Nach dem Ändern des Protokollierumfangs ist ein Neustart des Service erforderlich.

21.6 Verifizieren der exportierten NFS-Freigabe #Edit source

In NFS v3 können Sie überprüfen, ob die NFS-Freigaben im NFS Ganesha Server Node exportiert werden:

root@minion > showmount -e
/ (everything)

21.7 Einhängen der exportierten NFS-Freigabe #Edit source

Führen Sie zum Einhängen der exportierten NFS-Freigabe (wie in Abschnitt 21.2, „Konfiguration“ konfiguriert) auf einem Client-Host folgendes Kommando aus:

root # mount -t nfs -o rw,noatime,sync \
 nfs_ganesha_server_hostname:/ /path/to/local/mountpoint

Diese Seite drucken