NFS Ganesha ermöglicht den NFS-Zugriff auf das Object Gateway oder das CephFS. In SUSE Enterprise Storage 6 werden die NFS-Versionen 3 und 4 unterstützt. NFS Ganesha wird im Benutzerbereich statt im Kernel-Bereich ausgeführt und interagiert direkt mit dem Object Gateway oder dem CephFS.
Native CephFS- und NFS-Clients sind nicht durch Dateisperren in Samba eingeschränkt und umgekehrt. In Anwendungen, die auf der protokollübergreifenden Dateisperre beruhen, können dort Beschädigungen auftreten, wenn der Zugriff auf CephFS-gestützte Samba-Freigabepfade auf andere Weise erfolgt.
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:
Die role-ganesha
muss mindestens einem Node zugewiesen sein.
Sie können nur eine role-ganesha
pro Minion definieren.
NFS Ganesha benötigt entweder ein Object Gateway oder ein CephFS.
Auf Minions mit der Rolle role-ganesha
muss das kernelgestützte NFS deaktiviert werden.
In diesem Installationsbeispiel werden sowohl das Objekt Gateway als auch die CephFS File System Abstraction Layers (FSAL) von NFS Ganesha verwendet.
Wenn Ihnen dies nicht geläufig ist, führen Sie zunächst die DeepSea-Phasen 0 und 1 aus, bevor Sie mit diesem Verfahren fortfahren.
root@master #
salt-run
state.orch ceph.stage.0root@master #
salt-run
state.orch ceph.stage.1
Bearbeiten Sie nach Ausführung der Phase 1 von DeepSea die Datei/srv/pillar/ceph/proposals/policy.cfg
und fügen Sie folgende Zeile hinzu:
role-ganesha/cluster/NODENAME
Ersetzen Sie NODENAME durch den Namen eines Nodes in Ihrem Cluster.
Stellen Sie außerdem sicher, dass eine role-mds
und eine role-rgw
zugewiesen sind.
Führen Sie mindestens die Phasen 2 und 4 von DeepSea aus. Wir empfehlen, dazwischen auch Phase 3 auszuführen.
root@master #
salt-run
state.orch ceph.stage.2root@master #
salt-run
state.orch ceph.stage.3 # optional but recommendedroot@master #
salt-run
state.orch ceph.stage.4
Prüfen Sie, ob NFS Ganesha funktionsfähig ist. Stellen Sie hierzu fest, ob der NFS Ganesha- Service auf dem Minion Node ausgeführt wird:
root@master #
salt
-I roles:ganesha service.status nfs-ganesha MINION_ID: True
In diesem Abschnitt finden Sie ein Beispiel, wie eine Aktiv-Passiv-Konfiguration mit zwei Nodes des NFS Ganesha-Servers eingerichtet wird. Für die Einrichtung ist die SUSE Linux Enterprise High Availability Extension erforderlich. Die beiden Nodes werden earth
und mars
genannt.
Services mit eigener Fehlertoleranz und eigenem Lastenausgleich dürfen nicht auf Cluster Nodes ausgeführt werden, die im Rahmen der Failover-Services isoliert werden. Führen Sie Ceph Monitor-, Metadatenserver-, iSCSI- oder Ceph OSD-Services daher nicht in Hochverfügbarkeits-Einrichtungen aus.
Detaillierte Informationen zu SUSE Linux Enterprise High Availability Extension finden Sie unter https://www.suse.com/documentation/sle-ha-15/.
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.
Bereiten Sie die NFS Ganesha Nodes am Salt Master vor:
Führen Sie die DeepSea-Phasen 0 und 1 aus.
root@master #
salt-run
state.orch ceph.stage.0root@master #
salt-run
state.orch ceph.stage.1
Weisen Sie den Nodes earth
und mars
die role-ganesha
in Datei/srv/pillar/ceph/proposals/policy.cfg
zu:
role-ganesha/cluster/earth*.sls role-ganesha/cluster/mars*.sls
Führen Sie die DeepSea-Phasen 2 bis 4 aus.
root@master #
salt-run
state.orch ceph.stage.2root@master #
salt-run
state.orch ceph.stage.3root@master #
salt-run
state.orch ceph.stage.4
Registrieren Sie die SUSE Linux Enterprise High Availability Extension in earth
und mars
.
root #
SUSEConnect
-r ACTIVATION_CODE -e E_MAIL
Installieren Sie ha-cluster-bootstrap in beiden Nodes:
root #
zypper
in ha-cluster-bootstrap
Initialisieren Sie den Cluster in earth
:
root@earth #
ha-cluster-init
Lassen Sie mars
dem Cluster beitreten:
root@mars #
ha-cluster-join
-c earth
Prüfen Sie den Status des Clusters. Sie sollten zwei Nodes sehen, die im Cluster hinzugefügt wurden:
root@earth #
crm
status
Deaktivieren Sie in beiden Nodes den automatischen Start des NFS Ganesha Service beim Booten des Systems:
root #
systemctl
disable nfs-ganesha
Starten Sie die crm
-Shell im Node earth
:
root@earth #
crm
configure
Die nächsten Kommandos werden in der crm-Shell ausgeführt.
Führen Sie in earth
die crm-Shell aus, um die folgenden Kommandos zur Konfiguration der Ressource für NFS Ganesha Daemons als Klon des Ressourcentyps „systemd“ auszuführen:
crm(live)configure#
primitive nfs-ganesha-server systemd:nfs-ganesha \ op monitor interval=30scrm(live)configure#
clone nfs-ganesha-clone nfs-ganesha-server meta interleave=truecrm(live)configure#
commitcrm(live)configure#
status 2 nodes configured 2 resources configured Online: [ earth mars ] Full list of resources: Clone Set: nfs-ganesha-clone [nfs-ganesha-server] Started: [ earth mars ]
Erstellen Sie eine einfache IPAddr2 mit der crm-Shell:
crm(live)configure#
primitive ganesha-ip IPaddr2 \ params ip=192.168.2.1 cidr_netmask=24 nic=eth0 \ op monitor interval=10 timeout=20crm(live)#
status Online: [ earth mars ] Full list of resources: Clone Set: nfs-ganesha-clone [nfs-ganesha-server] Started: [ earth mars ] ganesha-ip (ocf::heartbeat:IPaddr2): Started earth
Wir stellen eine Beziehung zwischen dem NFS Ganesha-Server und der Floating-IP-Adresse über Kollokation und Anordnung her.
crm(live)configure#
colocation ganesha-ip-with-nfs-ganesha-server inf: ganesha-ip nfs-ganesha-clonecrm(live)configure#
order ganesha-ip-after-nfs-ganesha-server Mandatory: nfs-ganesha-clone ganesha-ip
Führen Sie das Kommando mount
am Client aus, um sicherzustellen, dass die Cluster-Einrichtung vollständig ist:
root #
mount
-t nfs -v -o sync,nfsvers=4 192.168.2.1:/ /mnt
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 earthroot@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.
Definieren Sie die Ping-Ressource:
crm(live)configure#
primitive ganesha-ping ocf:pacemaker:ping \
params name=ping dampen=3s multiplier=100 host_list="CLIENT1 CLIENT2" \
op monitor interval=60 timeout=60 \
op start interval=0 timeout=60 \
op stop interval=0 timeout=60
host_list
ist eine Liste mit IP-Adressen, die durch Leerzeichen getrennt sind. Die IP-Adressen werden regelmäßig gepingt, um nach Netzwerkausfällen zu suchen. Wenn ein Client ständig Zugriff auf den NFS-Server haben muss, fügen Sie ihn zu host_list
hinzu.
Erstellen Sie einen Klon:
crm(live)configure#
clone ganesha-ping-clone ganesha-ping \
meta interleave=true
Das folgende Kommando erstellt eine Einschränkung für den NFS Ganesha-Service. Der Node wird dadurch gezwungen, zu einem anderen Node zu wechseln, wenn host_list
nicht erreichbar ist.
crm(live)configure#
location nfs-ganesha-server-with-ganesha-ping
nfs-ganesha-clone \
rule -inf: not_defined ping or ping lte 0
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:
Kopieren Sie /srv/salt/ceph/ganesha/default.sls
zu /srv/salt/ceph/ganesha/ha.sls
.
Entfernen Sie den Eintrag .service
aus /srv/salt/ceph/ganesha/ha.sls
, sodass sie wie folgt aussieht:
include: - .keyring - .install - .configure
Fügen Sie die folgende Zeile zu /srv/pillar/ceph/stack/global.yml
hinzu:
ganesha_init: ha
Dieser Abschnitt zeigt ein Beispiel einer einfachen NFS Ganesha-Aktiv/Aktiv-Einrichtung. Es sollen zwei NFS Ganesha-Server auf demselben vorhandenen CephFS implementiert werden. Die Server bestehen aus zwei Ceph Cluster Nodes mit separaten Adressen. Die Clients müssen manuell darauf verteilt werden. Bei einem „Failover“ in dieser Konfiguration muss der andere Server auf dem Client manuell ausgehängt und wieder eingehängt werden.
Für die Beispielkonfiguration ist Folgendes erforderlich:
Aktiver Ceph Cluster. Weitere Informationen zum Implementieren und Konfigurieren des Ceph Clusters mit DeepSea finden Sie in Abschnitt 5.3, „Cluster-Bereitstellung“.
Mindestens ein konfiguriertes CephFS. Weitere Informationen zum Implementieren und Konfigurieren von CephFS finden Sie in Kapitel 11, Installation des CephFS.
Zwei Ceph Cluster Nodes, auf denen NFS Ganesha implementiert ist. Weitere Informationen zum Implementieren und Konfigurieren von NFS Ganesha finden Sie in Kapitel 12, Installation von NFS Ganesha.
NFS Ganesha Nodes können Ressourcen gemeinsam mit anderen Ceph-spezifischen Services nutzen. Zur Leistungssteigerung werden dennoch dedizierte Server empfohlen.
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.
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 nodeid
s 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.comcephadm@adm >
ganesha-rados-grace -p cephfs_metadata -n ganesha add ses6min2.example.comcephadm@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
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.
Weitere Informationen finden Sie im Kapitel 21, NFS Ganesha: Exportieren von Ceph-Daten über NFS.