Zur erfolgreichen Bereitstellung von NFS Ganesha müssen Sie eine role-ganesha zu /srv/pillar/ceph/proposals/policy.cfg hinzufügen. Weitere Informationen finden Sie in Abschnitt 5.5.1, „Die Datei policy.cfg“. Für NFS Ganesha muss entweder eine role-rgw oder einerole-mds in der Datei policy.cfg vorhanden sein.

Es ist zwar möglich, den NFS Ganesha-Server in einem bereits vorhandenen Ceph Node zu installieren und auszuführen, wir empfehlen jedoch, ihn auf einem dedizierten Host mit Zugriff auf den Ceph Cluster auszuführen. Die Client-Hosts sind normalerweise nicht Teil des Clusters, doch sie müssen Netzwerkzugriff auf den NFS Ganesha-Server haben.

Fügen sie zur Aktivierung des NFS Ganesha-Servers zu einem beliebigen Zeitpunkt nach der ersten Installation die role-ganesha zu policy.cfg hinzu und führen Sie mindestens die DeepSea-Phasen 2 und 4 erneut aus. Weitere Informationen finden Sie in Abschnitt 5.3, „Cluster-Bereitstellung“.

NFS Ganesha wird über die Datei /etc/ganesha/ganesha.conf konfiguriert, die im NFS Ganesha Node vorhanden ist. Diese Datei wird jedoch bei jeder Ausführung der DeepSea-Phase 4 überschrieben. Wir empfehlen daher, die von Salt verwendeten Schablonen zu bearbeiten, bei der es sich um die Datei /srv/salt/ceph/ganesha/files/ganesha.conf.j2 am Salt Master handelt. Detaillierte Informationen zur Konfigurationsdatei finden Sie im Abschnitt 21.2, „Konfiguration“.

Die folgenden Anforderungen müssen erfüllt sein, bevor DeepSea-Phasen 2 und 4 zur Installation von NFS Ganesha ausgeführt werden können:

In dieser Einrichtung hat earth die IP-Adresse 192.168.1.1 und mars die Adresse 192.168.1.2.

Außerdem können Clients über zwei virtuelle IP-Adressen nach dem Floating-IP-Prinzip eine Verbindung mit dem Service herstellen, und zwar unabhängig davon, auf welchem physischen Node er ausgeführt wird. 192.168.1.10 wird für die Cluster-Verwaltung mit Hawk2 verwendet und 192.168.2.1 exklusiv für die NFS-Exporte. Dies erleichtert später die Anwendung von Sicherheitsbeschränkungen.

Das folgende Verfahren beschreibt das Installationsbeispiel. Weitere Informationen finden Sie unter https://www.suse.com/documentation/sle-ha-15/book_sleha_quickstarts/data/art_sleha_install_quick.html.

Falls ein NFS Ganesha, wie zum Beispiel earth, in einem der Nodes ausfällt, beheben Sie das Problem und bereinigen Sie die Ressource. Erst nach Bereinigung der Ressource kann ein Failback der Ressource zu earth ausgeführt werden, falls NFS Ganesha in mars ausfällt.

So bereinigen Sie die Ressource:

root@earth # crm resource cleanup nfs-ganesha-clone earth
root@earth # crm resource cleanup ganesha-ip earth

Es kann vorkommen, dass der Server den Client aufgrund eines Netzwerkproblems nicht erreicht. Eine Ping-Ressource kann dieses Problem erkennen und abschwächen. Die Konfiguration dieser Ressource ist optional.

DeepSea unterstützt nicht die Konfiguration von NFS Ganesha HA. Um zu verhindern, dass DeepSea nach der Konfiguration von NFS Ganesha HA ausfällt, schließen Sie Starten und Stoppen des NFS Ganesha-Service von DeepSea-Phase 4 aus:

Für die Beispielkonfiguration ist Folgendes erforderlich:

Prüfen Sie nach der Implementierung der NFS Ganesha Nodes, ob der Cluster funktionsfähig ist und die standardmäßigen CephFS-Pools vorhanden sind:

cephadm@adm > rados lspools
cephfs_data
cephfs_metadata

Prüfen Sie, ob auf beiden NFS Ganesha Nodes die Datei /etc/ganesha/ganesha.conf installiert ist. Falls die folgenden Blöcke noch nicht vorhanden sind, fügen Sie sie in die Konfigurationsdatei ein, damit RADOS als Wiederherstellungs-Back-End für NFS Ganesha aktiviert wird.

NFS_CORE_PARAM
{
    Enable_NLM = false;
    Enable_RQUOTA = false;
    Protocols = 4;
}
NFSv4
{
    RecoveryBackend = rados_cluster;
    Minor_Versions = 1,2;
}
CACHEINODE {
    Dir_Chunk = 0;
    NParts = 1;
    Cache_Size = 1;
}
RADOS_KV
{
    pool = "rados_pool";
    namespace = "pool_namespace";
    nodeid = "fqdn"
    UserId = "cephx_user_id";
    Ceph_Conf = "path_to_ceph.conf"
}

Die Werte für rados_pool und pool_namespace finden Sie in der bereits vorhandenen Zeile in der Konfiguration mit der Form:

%url rados://rados_pool/pool_namespace/...

Der Wert für die Option nodeid entspricht dem FQDN des Computers und die Werte für die Optionen UserId und Ceph_Conf sind im bereits vorhandenen Block RADOS_URLS zu finden.

Aufgrund von Legacy-Versionen von NFS sind wir nicht in der Lage, den Kulanzzeitraum vorzeitig aufzuheben, weshalb der Neustart des Servers verlängert wird. Aus diesem Grund sind Optionen für NFS vor Version 4.2 deaktiviert. Auch der Großteil des NFS Ganesha-Cachings ist deaktiviert, da die Ceph-Bibliotheken bereits ein aggressives Caching vornehmen.

Das Wiederherstellungs-Back-End „rados_cluster“ speichert seine Daten in RADOS-Objekten. Auch wenn dies keine große Datenmenge ist, soll sie doch hochverfügbar sein. Hierzu wird der CephFS-Metadaten-Pool herangezogen, in dem ein neuer Namespace „ganesha“ erstellt wird, getrennt von den CephFS-Objekten.

Anmerkung: Cluster Node-IDs

Der Großteil der Konfiguration auf beiden Hosts ist identisch; die Option nodeid im Block „RADOS_KV“ muss jedoch jeweils eine eindeutige Zeichenkette für die einzelnen Knoten enthalten. Standardmäßig wird nodeid als Hostname des Knotens in NFS Ganesha festgelegt.

Sollen andere feste Werte verwendet werden, also nicht die Hostnamen, legen Sie beispielsweise nodeid = 'a' auf einem Knoten fest und nodeid = 'b' auf dem anderen Knoten.

Es muss gewährleistet sein, dass alle Knoten im Cluster gegenseitig sichtbar sind. Hierzu wird ein RADOS-Objekt zwischen den Hosts freigegeben. NFS Ganesha übermittelt anhand dieses Objekts den aktuellen Status im Hinblick auf einen Kulanzzeitraum.

Das Paket nfs-ganesha-rados-grace enthält ein Kommandozeilenwerkzeug zum Abfragen und Bearbeiten dieser Datenbank. Wenn das Paket nicht auf mindestens einem Knoten installiert ist, installieren Sie es wie folgt:

root # zypper install nfs-ganesha-rados-grace

Mit dem Kommando werden die Datenbank erstellt und beide nodeids hinzugefügt. In diesem Beispiel erhalten die beiden NFS Ganesha Nodes die Bezeichnung ses6min1.example.com und ses6min2.example.com. Führen Sie folgendes Kommando auf einem der NFS Ganesha-Hosts aus:

cephadm@adm > ganesha-rados-grace -p cephfs_metadata -n ganesha add ses6min1.example.com
cephadm@adm > ganesha-rados-grace -p cephfs_metadata -n ganesha add ses6min2.example.com
cephadm@adm > ganesha-rados-grace -p cephfs_metadata -n ganesha
cur=1 rec=0
======================================================
ses6min1.example.com     E
ses6min2.example.com     E

Hiermit wird die Kulanzdatenbank erstellt und sowohl „ses6min1.example.com“ als auch „ses6min2.example.com“ werden in die Datenbank aufgenommen. Das letzte Kommando gibt den aktuellen Status zurück. Bei neu hinzugefügten Hosts wird stets angenommen, dass sie den Kulanzzeitraum erzwingen; bei beiden ist daher die Flagge „E“ gesetzt. Die Werte „cur“ und „rec“ zeigen die aktuelle Epoche und die Wiederherstellungsepoche, womit nachverfolgt werden kann, welche Hosts die Wiederherstellung zu welchem Zeitpunkt durchführen dürfen.

Starten Sie auf beiden NFS Ganesha Nodes die entsprechenden Services neu:

root # systemctl restart nfs-ganesha.service

Prüfen Sie nach dem Neustart der Services die Kulanzdatenbank:

cephadm@adm > ganesha-rados-grace -p cephfs_metadata -n ganesha
cur=3 rec=0
======================================================
ses6min1.example.com
ses6min2.example.com

Anmerkung: Flagge „E“ gelöscht

Beachten Sie, dass bei beiden Knoten die Flagge „E“ gelöscht ist. Dies bedeutet, dass die Knoten den Kulanzzeitraum nicht mehr erzwingen und sich nun im normalen Betriebsmodus befinden.

Sobald Sie alle obigen Schritte ausgewählt haben, können Sie das exportierte NFS von einem der beiden NFS Ganesha-Server einhängen und normale NFS-Operationen für die Server ausführen.

In der Beispielkonfiguration wird vorausgesetzt, dass Sie einen NFS Ganesha-Server bei einem Ausfall manuell innerhalb von 5 Minuten neu starten. Nach 5 Minuten kann der Metadatenserver die Sitzung des NFS Ganesha-Clients abbrechen und den gesamten zugehörigen Zustand stornieren. Werden die Capabilities der Sitzung storniert, bevor der restliche Cluster in den Kulanzzeitraum eintritt, können die Clients des Servers unter Umständen nicht den gesamten Zustand wiederherstellen.