cephx
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.
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.
Die Installationsanweisungen finden Sie unter Kapitel 12, Installation von NFS Ganesha.
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.
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.
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"; }
Dateipfad der Ceph-Konfiguration.
cephx-Benutzer-ID.
RADOS-Objekt-URL, die auf Neustartbenachrichtigungen überwacht werden soll .
RGW { ceph_conf = "/etc/ceph/ceph.conf"; name = "name"; cluster = "ceph"; }
Zeigt auf die Datei ceph.conf
. Bei der Bereitstellung mit DeepSea ist es nicht erforderlich, diesen Wert zu ändern.
Der Name des Ceph Client-Benutzers. der von NFS Ganesha verwendet wird.
Name des Ceph Clusters. SUSE Enterprise Storage 6 unterstützt derzeit nur einen Cluster-Namen, nämlich standardmäßig ceph
.
%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.
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; }
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.
Jeder Export benötigt eine eindeutige „Export_Id“ (obligatorisch).
Exportpfad im entsprechenden CephFS Pool (obligatorisch). Damit können Unterverzeichnisse vom CephFS exportiert werden.
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.
„RO“ für schreibgeschützten Zugriff, „RW“ für Schreib-/Lesezugriff und „None“ für „kein Zugriff“.
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"; [...] } [...] }
NFS Squash-Option.
Exportieren der Dateisystem-Abstraktionsschicht (File System Abstraction Layer, FSAL). Weitere Informationen hierzu finden Sie in Abschnitt 21.2.2.2, „FSAL-Unterabschnitt“.
EXPORT { [...] FSAL { Name = CEPH; } }
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.
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.
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.j2root@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.j2root@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.j2root@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.confroot@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.
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.j2root@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.j2root@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.
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.
Führen Sie zum Aktivieren und Starten des NFS Ganesha Service folgende Kommandos aus:
root@minion >
systemctl
enable nfs-ganesharoot@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.
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.
In NFS v3 können Sie überprüfen, ob die NFS-Freigaben im NFS Ganesha Server Node exportiert werden:
root@minion >
showmount
-e / (everything)
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