NFS-Clients verbinden

Auf dieser Seite wird beschrieben, wie Sie NFS-Clients verbinden.

Hinweise

Installieren Sie die NFS-Clienttools entsprechend Ihrer Linux-Distribution, um den Client vorzubereiten:

RedHat

Führen Sie dazu diesen Befehl aus:

sudo yum install -y nfs-utils

SuSe

Führen Sie dazu diesen Befehl aus:

sudo yum install -y nfs-utils

Debian

Führen Sie dazu diesen Befehl aus:

sudo apt-get install nfs-common

Ubuntu

Führen Sie dazu diesen Befehl aus:

sudo apt-get install nfs-common

Volume-Zugriffssteuerung mit Exportrichtlinien

Die Volume-Zugriffssteuerung in NFSv3 und NFSv4.1 basiert auf der IP-Adresse des Clients. Die Exportrichtlinie des Volumes enthält bis zu 20 Exportregeln. Jede Regel ist eine durch Kommas getrennte Liste von IP-Adressen oder Netzwerk-CIDRs, die Allowed Clients definieren, die das Volume einbinden dürfen. Eine Regel definiert auch die Art des Zugriffs, den die Clients haben, z. B. Lesen und Schreiben oder Nur lesen.

Auf den folgenden Tabs finden Sie Richtlinien basierend auf NFS-Versionen:

NFS ohne Kerberos

Alle NFS-Versionen ohne Kerberos verwenden den Sicherheits-Flavor AUTH_SYS. In diesem Modus müssen Sie die Exportregeln sorgfältig verwalten, damit nur Clients, denen Sie vertrauen und die die Integrität von Nutzer- und Gruppen-IDs gewährleisten können, Daten exportieren dürfen.

Aus Sicherheitsgründen werden NFS-Aufrufe mit UID=0 (root) auf NFS-Servern automatisch UID=65534 (anonym) zugeordnet, was zu eingeschränkten Berechtigungen für das Dateisystem führt. Weitere Informationen finden Sie unter Nutzer-ID-Kürzung.

NFSv4.1 mit Kerberos

NFSv4.1 mit Kerberos verwendet Exportrichtlinien und zusätzliche Authentifizierung mit Kerberos für den Zugriff auf Volumes. Sie können Exportregeln für Folgendes konfigurieren:

• Nur Kerberos (krb5)

• Kerberos-Signierung (krb5i)

• Kerberos-Datenschutz (krb5p)

Best Practices für Exportrichtlinien

Wir empfehlen die folgenden Best Practices für Exportrichtlinien:

• Ordnen Sie die Exportregeln von der spezifischsten zur am wenigsten spezifischen Regel.

• Exportieren Sie nur zu den vertrauenswürdigen Clients, z. B. zu bestimmten Clients oder CIDRs mit den vertrauenswürdigen Clients.

• Beschränken Sie den Root-Zugriff auf eine kleine Gruppe vertrauenswürdiger Administrationsclients.

Regel	Zulässige Clients	Zugriff	Root-Zugriff	Beschreibung
1	10.10.5.3, 10.10.5.9	Lesen und Schreiben	An	Verwaltungsclients. Der Root-Nutzer bleibt Root und kann alle Dateiberechtigungen verwalten.
2	10.10.5.0/24	Lesen und Schreiben	Aus	Alle anderen Clients aus dem Netzwerk 10.10.5.0/24 dürfen das Laufwerk einbinden, aber der Root-Zugriff wird auf „nobody“ abgebildet.
3	10.10.6.0/24	Schreibgeschützt:	Aus	Ein anderes Netzwerk darf Daten aus dem Volume lesen, aber nicht schreiben.

Nachdem ein Client ein Volume bereitgestellt hat, wird durch den Zugriff auf Dateiebene bestimmt, was ein Nutzer tun darf. Weitere Informationen finden Sie unter NFS-Zugriffssteuerung auf Dateiebene für UNIX-ähnliche Volumes.

Zusammenfassung von Nutzer-IDs

NFS-Exportrichtlinien bieten Steuerelemente für das Squashing von Nutzer- und Gruppen-IDs. Damit können Sie Nutzer- und Gruppen-IDs aus Sicherheitsgründen einer anonymen Nutzer-ID zuordnen.

Root Squashing

NFS-Server verbessern die Sicherheit, indem sie den Root-Nutzer (UID=0) auf „nobody“ (UID=65534) umleiten. Dadurch wird Root zu einem Nutzer ohne Berechtigungen für den Dateizugriff auf dem Volume. Diese Funktion wird als Root-Squashing bezeichnet. Die Option zum Deaktivieren und Beibehalten der Root-Berechtigungen heißt auf NFS-Servern no_root_squash.

Standardmäßig sind Volumes ohne definierte Exportrichtlinie für Client-IP-Adressen nicht zugänglich. Wenn Sie in der Google Cloud -Konsole eine Exportrichtlinienregel erstellen, umfassen die Standardeinstellungen Lese- und Schreibzugriff und Root-Squash. DieGoogle Cloud API, die Google Cloud CLI und Terraform unterstützten bisher die Steuerung von Root-Squashing mit dem Parameter has-root-access. has-root-access wird zwar weiterhin akzeptiert, wurde aber durch den Parameter squash-mode ersetzt.

Als Best Practice sollten Sie eine dedizierte Exportregel erstellen, die Root-Zugriff für Ihre vertrauenswürdigen Administratorhosts ermöglicht und Root-Zugriff für andere Clients deaktiviert. Platzieren Sie diese Regel vor allgemeineren Regeln.

Zusammenführen von Nutzer- und Gruppen-IDs

Mit dem Parameter squash-mode können Sie sowohl Nutzer- als auch Gruppen-IDs in eine anonyme UID umwandeln. Das kann für öffentliche SFTP-Dropbox-Verzeichnisse nützlich sein. Dieser Parameter ersetzt auch den Parameter has-root-access und wird in der API, der Google Cloud CLI und Terraform unterstützt.

Der Parameter squash-mode akzeptiert die folgenden Werte:

• no-root-squash: In diesem Modus bleibt der Root-Nutzer Root und wird nicht auf „nobody“ (UID=65534) umgeleitet.

• root-squash: Mit dieser Einstellung wird der Root-Nutzer zu „nobody“ neu zugeordnet.

• all-squash: Diese Option bietet anonymen Zugriff für alle Nutzer, einschließlich des Root-Nutzers. Alle Nutzer werden der UID und GID zugeordnet, die durch den Parameter anon-uid angegeben werden. Wenn Sie all-squash verwenden, müssen Sie auch anon-uid angeben und access-type auf READ_WRITE festlegen.

Hinweise

Beachten Sie Folgendes für Exportrichtlinienregeln mit squash mode:

• Eine Exportrichtlinie unterstützt nur eine all-squash-Regel.

• Wenn all-squash aktiviert ist, wird der Root-Nutzer auf „anonymous“ (anonym) reduziert. Dies kann durch eine Regel mit höherer Priorität, in der no-root-squash verwendet wird, überschrieben werden.

• Die Volume-Replikation wird für Volumes mit einer Exportrichtlinienregel vom Typ squash-mode nicht unterstützt.

• Beim Service-Level „Flex“ wird der Inode des Stammverzeichnisses des Volumes durch all-squash nicht automatisch geändert. Fügen Sie dazu eine no-root-squash-Exportregel hinzu, damit der Root-Nutzer mit chown den Eigentümer des Root-Inode in die erforderliche UID ändern kann.

• Der Parameter has-root-access wird unterstützt. Verwenden Sie entweder has-root-access oder squash-mode, aber nicht beide Parameter gleichzeitig.

Volume bearbeiten

So aktualisieren Sie die Exportrichtlinie eines Volumes mit dem Squash-Modus über die Google Cloud CLI:

gcloud

So aktualisieren Sie ein Volume mit einer Exportrichtlinie im Squash-Modus:

gcloud netapp volumes update VOLUME_ID \
  --project=PROJECT_ID \
  --location=LOCATION \
  --export-policy=access-type=ACCESS_TYPE,squash-mode=SQUASH_MODE,anon-uid=ANON_UID,allowed-clients=ALLOWED_CLIENTS_IP_ADDRESSES

Ersetzen Sie die folgenden Informationen:

• VOLUME_ID: die ID des Volumes.

• PROJECT_ID: der Name des Projekts, in dem sich das Volume befindet.

• LOCATION: Der Speicherort des Volumes.

• ACCESS_TYPE: Der Zugriffstyp muss entweder READ_WRITE, READ_ONLY oder READ_NONE sein.

• SQUASH_MODE: Die Exportregel muss entweder NO_ROOT_SQUASH, ROOT_SQUASH oder ALL_SQUASH sein.

• ANON_UID: Die UID-Nummer, auf die die UIDs zusammengeführt werden sollen.

• ALLOWED_CLIENTS_IP_ADDRESSES: Eine durch Kommas getrennte Liste zulässiger Client-IP-Adressen oder -Bereiche.

Exportrichtlinienparameter können wiederholt werden, um mehrere Regeln einzuschließen.

Das folgende Beispiel zeigt, wo eine Exportrichtlinie sowohl root-squash- als auch all-squash-Regeln hat:

gcloud netapp volumes update my_volume --location=us-east4 \
--export-policy=allowed-clients=10.0.1.18,nfsv3=true,access-type=READ_WRITE,squash-mode=NO_ROOT_SQUASH \
--export-policy=allowed-clients=10.0.2.0/24,nfsv3=true,access-type=READ_WRITE,squash-mode=ALL_SQUASH,anon-uid=2000

Weitere Informationen zu zusätzlichen optionalen Flags finden Sie in der Google Cloud SDK-Dokumentation zur Richtlinie zum Exportieren von Datenträgern.

Anleitung zum Bereitstellen für NFS-Clients

Gehen Sie nach der folgenden Anleitung vor, um mit der Google Cloud Console oder der Google Cloud CLI Bereitstellungsanleitungen für NFS-Clients abzurufen:

Console

1. Rufen Sie in der Google Cloud Console die Seite NetApp Volumes auf.

   Zu NetApp Volumes

2. Klicken Sie auf Volumes.

3. Klicken Sie auf  Mehr anzeigen.

4. Wählen Sie Bereitstellungsanleitung aus.

5. Folgen Sie der Bereitstellungsanleitung in der Google Cloud -Konsole.

6. Ermitteln Sie den Bereitstellungsbefehl und verwenden Sie die Bereitstellungsoptionen, sofern Ihre Arbeitslast keine spezifischen Anforderungen an die Bereitstellungsoptionen hat.

   Nur NFSv3: Wenn Ihre Anwendung keine Sperren verwendet oder Sie Ihre Clients nicht für die NSM-Kommunikation konfiguriert haben, empfehlen wir, die Mount-Option nolock hinzuzufügen.

gcloud

So rufen Sie die Bereitstellungsanleitung für ein Volume auf:

 gcloud netapp volumes describe VOLUME_NAME \
    --project=PROJECT_ID \
    --location=LOCATION \
    --format="value(mountOptions.instructions)"

Ersetzen Sie die folgenden Informationen:

• VOLUME_NAME ist der Name des Volumes.

• PROJECT_ID: der Name des Projekts, in dem sich das Volume befindet.

• LOCATION: Der Speicherort des Volumes.

Weitere Informationen zu zusätzlichen optionalen Flags finden Sie in der Google Cloud SDK-Dokumentation zu Volumes.

Zusätzliche NFSv4.1-Anleitung

Wenn Sie NFSv4.1 für Volumes der Service Levels „Flex Unified“, „Standard“, „Premium“ und „Extreme“ aktivieren, wird NFSv4.2 automatisch für diese Volumes aktiviert. Mit dem Linux-Bereitstellungsbefehl wird immer die höchste verfügbare NFS-Version bereitgestellt, sofern Sie die Version nicht angeben. Wenn Sie die Bereitstellung mit NFSv4.1 durchführen möchten, verwenden Sie den Parameter -o vers=4.1 in Ihrem Bereitstellungsbefehl.

In NFSv3 werden Nutzer und Gruppen anhand von Nutzer-IDs (UID) und Gruppen-IDs (GID) identifiziert, die über das NFSv3-Protokoll gesendet werden. Es ist wichtig, dass dieselbe UID und GID denselben Nutzer und dieselbe Gruppe auf allen Clients darstellen, die auf das Volume zugreifen. Bei NFSv4 ist keine explizite UID- und GID-Zuordnung mehr erforderlich, da Sicherheitskennungen verwendet werden. Sicherheitskennungen sind Strings, die als <username|groupname>@<full_qualified_domain> formatiert sind. Ein Beispiel für einen Sicherheitsbezeichner ist [e-mail]. Der Client muss die intern verwendeten UIDs und GIDs in einen Sicherheitsbezeichner übersetzen, bevor er eine NFSv4-Anfrage an den Server sendet. Der Server muss die Sicherheitskennungen für eine eingehende Anfrage in UIDs und GIDs übersetzen und umgekehrt für seine Antwort. Der Vorteil der Verwendung von Übersetzungen besteht darin, dass jeder Client und der Server unterschiedliche interne UIDs und GIDs verwenden können. Der Nachteil ist jedoch, dass alle Clients und der Server eine Zuordnungsliste zwischen UIDs und GIDs sowie Nutzer- und Gruppennamen verwalten müssen. Die Zuordnungsinformationen auf Clients können aus lokalen Dateien wie /etc/passwd und /etc/groups oder einem LDAP-Verzeichnis stammen. Die Konfiguration dieser Zuordnung wird von rpc.idmapd verwaltet, das auf Ihrem Client ausgeführt werden muss.

Bei NetApp-Volumes muss das LDAP Zuordnungsinformationen bereitstellen. Active Directory ist der einzige unterstützte RFC2307bis-kompatible LDAP-Server. Bei Verwendung von Kerberos für NFSv4 werden Kerberos-Principals im Format username@DOMAINNAME in der Sicherheits-ID gespeichert, wobei DOMAINNAME (in Großbuchstaben) zum Bereichsnamen wird.

Numerische IDs

Für Nutzer, die die Namenszuordnungen nicht konfigurieren möchten und stattdessen NFSv4 als Ersatz für NFSv3 verwenden möchten, wurde in NFSv4 die Option numeric ID eingeführt, mit der UID- und GID-codierte Textstrings als Sicherheitskennungen gesendet werden. Das vereinfacht den Konfigurationsprozess für Nutzer.

Hinweis: Bei den neuesten Linux-Distributionen ist die Option numeric ID standardmäßig aktiviert.

Mit dem folgenden Befehl können Sie Ihre Clienteinstellung prüfen:

     cat /sys/module/nfs/parameters/nfs4_disable_idmapping
   

Der Standardwert ist Y, wodurch numerische IDs aktiviert werden. NetApp Volumes unterstützt die Verwendung numerischer IDs.

rpc.idmapd auf dem NFS-Client konfigurieren

Unabhängig davon, welche Art von IDs oder Sicherheitskennungen Sie verwenden, müssen Sie rpc.idmapd auf Ihrem NFS-Client konfigurieren. Wenn Sie der Installationsanleitung für Client-Dienstprogramme im Abschnitt Vorbereitung gefolgt sind, sollte das Dienstprogramm bereits installiert sein, wird aber möglicherweise nicht ausgeführt. Bei einigen Distributionen wird es automatisch mit systemd gestartet, wenn Sie die ersten NFS-Volumes einbinden. Die Mindestkonfiguration für rpc.idmapd besteht darin, die Domäneneinstellung einzurichten. Andernfalls wird der Nutzer-Root als „nobody“ mit UID=65534 or 4294967295 angezeigt.

So konfigurieren Sie rpc.idmapd auf Ihrem NFS-Client:

1. Öffnen Sie auf Ihrem Client die Datei /etc/idmapd.conf und ändern Sie den Parameter „domain“ in einen der folgenden Werte:

   • Wenn Ihr Volume nicht für LDAP aktiviert ist, domain = defaultv4iddomain.com.

   • Wenn für Ihr Volume LDAP aktiviert ist, domain = <FDQN_of_Windows_Domain>.

2. Aktivieren Sie die Änderungen an rpc.idmapd mit dem folgenden Befehl:

    nfsidmap -c

Unterstützung für NFSv4.2

Die Service-Levels „Flex Unified“, „Standard“, „Premium“ und „Extreme“ unterstützen jetzt das NFSv4.2-Protokoll zusätzlich zu NFSv4.1 auf Volumes, für die NFSv4.1 bereits aktiviert ist.

Beim Bereitstellen eines NFS-Volumes wählt der Linux-Befehl „mount“ automatisch die höchste verfügbare NFS-Version aus. Wenn ein NFSv4.1-fähiges Volume automatisch bereitgestellt wird, wird standardmäßig NFSv4.2 verwendet, sofern die Bereitstellungsoption vers=4.1 nicht explizit angegeben wird.

NetApp Volumes unterstützt NFS-erweiterte Attribute xattrs mit NFSv4.2. Die in TR-4962 beschriebenen Nutzungsbedingungen und Einschränkungen von xattrs gelten ebenfalls.

Linux mit LDAP verbinden

Wenn Sie erweiterte NFSv3-Gruppen oder NFSv4.1 mit Sicherheits-IDs verwenden, haben Sie NetApp Volumes so konfiguriert, dass Ihr Active Directory als LDAP-Server verwendet wird. Dazu haben Sie ein Active Directory an einen Speicherpool angehängt.

Damit die Nutzerinformationen zwischen NFS-Client und ‑Server konsistent bleiben, müssen Sie möglicherweise Ihren Client so konfigurieren, dass Active Directory als LDAP-Namensdienst für Nutzer- und Gruppeninformationen verwendet wird.

Verwenden Sie die folgenden Ressourcen, um LDAP zu konfigurieren:

• Bereitstellungsleitfaden für RedHat

• Bereitstellungsanleitung für Ubuntu

• Bereitstellungsanleitung für SuSe

Wenn Sie Kerberized NFS verwenden, müssen Sie möglicherweise die in diesem Abschnitt erwähnten Bereitstellungsanleitungen verwenden, um LDAP zu konfigurieren und für Konsistenz zwischen Client und Server zu sorgen.

Nächste Schritte

Volumes mit hoher Kapazität mit mehreren Speicherendpunkten verbinden: