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

12 Installation von NFS Ganesha Edit source

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.

Warnung
Warnung: Protokollübergreifender Zugriff

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.

12.1 Vorbereitung Edit source

12.1.1 Allgemeine Informationen Edit source

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

12.1.2 Anforderungen im Überblick Edit source

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.

12.2 Installationsbeispiel Edit source

In diesem Installationsbeispiel werden sowohl das Objekt Gateway als auch die CephFS File System Abstraction Layers (FSAL) von NFS Ganesha verwendet.

  1. 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.0
    root@master # salt-run state.orch ceph.stage.1
  2. 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.

  3. 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.2
    root@master # salt-run state.orch ceph.stage.3 # optional but recommended
    root@master # salt-run state.orch ceph.stage.4
  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

12.3 Hochverfügbare Aktiv-Passiv-Konfiguration Edit source

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.

Wichtig
Wichtig: Services auf demselben Computer

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

12.3.1 Standardinstallation Edit source

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.

  1. Bereiten Sie die NFS Ganesha Nodes am Salt Master vor:

    1. Führen Sie die DeepSea-Phasen 0 und 1 aus.

      root@master # salt-run state.orch ceph.stage.0
      root@master # salt-run state.orch ceph.stage.1
    2. 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
    3. Führen Sie die DeepSea-Phasen 2 bis 4 aus.

      root@master # salt-run state.orch ceph.stage.2
      root@master # salt-run state.orch ceph.stage.3
      root@master # salt-run state.orch ceph.stage.4
  2. Registrieren Sie die SUSE Linux Enterprise High Availability Extension in earth und mars.

    root # SUSEConnect -r ACTIVATION_CODE -e E_MAIL
  3. Installieren Sie ha-cluster-bootstrap in beiden Nodes:

    root # zypper in ha-cluster-bootstrap
    1. Initialisieren Sie den Cluster in earth:

      root@earth # ha-cluster-init
    2. Lassen Sie mars dem Cluster beitreten:

      root@mars # ha-cluster-join -c earth
  4. Prüfen Sie den Status des Clusters. Sie sollten zwei Nodes sehen, die im Cluster hinzugefügt wurden:

    root@earth # crm status
  5. Deaktivieren Sie in beiden Nodes den automatischen Start des NFS Ganesha Service beim Booten des Systems:

    root # systemctl disable nfs-ganesha
  6. Starten Sie die crm-Shell im Node earth:

    root@earth # crm configure

    Die nächsten Kommandos werden in der crm-Shell ausgeführt.

  7. 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=30s
    crm(live)configure# clone nfs-ganesha-clone nfs-ganesha-server meta interleave=true
    crm(live)configure# commit
    crm(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 ]
  8. 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=20
    
    crm(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
  9. 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-clone
    crm(live)configure# order ganesha-ip-after-nfs-ganesha-server Mandatory: nfs-ganesha-clone ganesha-ip
  10. 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

12.3.2 Bereinigen der Ressourcen Edit source

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

12.3.3 Einrichten der Ping-Ressource Edit source

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.

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

  2. Erstellen Sie einen Klon:

    crm(live)configure# clone ganesha-ping-clone ganesha-ping \
            meta interleave=true
  3. 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

12.3.4 NFS Ganesha HA und DeepSea Edit source

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:

  1. Kopieren Sie /srv/salt/ceph/ganesha/default.sls zu /srv/salt/ceph/ganesha/ha.sls.

  2. Entfernen Sie den Eintrag .service aus /srv/salt/ceph/ganesha/ha.sls, sodass sie wie folgt aussieht:

    include:
    - .keyring
    - .install
    - .configure
  3. Fügen Sie die folgende Zeile zu /srv/pillar/ceph/stack/global.yml hinzu:

    ganesha_init: ha

12.4 Aktiv/Aktiv-Konfiguration Edit source

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.

12.4.1 Voraussetzungen Edit source

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.

    Tipp
    Tipp: Verwenden dedizierter Server

    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

12.4.2 Konfigurieren von NFS Ganesha Edit source

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

12.4.3 Befüllen der Cluster-Kulanzdatenbank Edit source

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.

12.4.4 Neustarten der NFS Ganesha-Services Edit source

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

12.4.5 Schlussfolgerung Edit source

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.

12.5 Weitere Informationen Edit source

Weitere Informationen finden Sie im Kapitel 21, NFS Ganesha: Exportieren von Ceph-Daten über NFS.