Auf dieser Seite wird beschrieben, wie Sie NFS-Clients verbinden.
Hinweis
Wenn Sie eine Firewall verwenden, um den Netzwerkverkehr zu steuern, und NFS-Traffic zulassen möchten, lesen Sie den Artikel Firewallregeln für den Zugriff auf NFS-Volumes.
Installieren Sie die NFS-Clienttools entsprechend Ihrem Linux-Distributionstyp, um Ihren 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
Zugriffssteuerung für Volumes mit Exportrichtlinien
Die Zugriffssteuerung für Volumes 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 IPs oder Netzwerk-CIDRs, die die zulässigen Clients definieren, die das Volume bereitstellen dürfen. Eine Regel definiert auch die Art des Zugriffs, den die Clients haben, z. B. Lesen und Schreiben oder Schreibgeschützt.
Auf den folgenden Tabs können Sie Richtlinien basierend auf NFS-Versionen ansehen:
NFS ohne Kerberos
Alle NFS-Versionen ohne Kerberos verwenden die Sicherheitsvariante AUTH_SYS. In diesem Modus müssen Sie die Exportregeln genau verwalten, um nur Clients zuzulassen, denen Sie vertrauen und die die Integrität von Nutzer- und Gruppen-IDs gewährleisten können.
Als Sicherheitsmaßnahme ordnen NFS-Server NFS-Aufrufe mit UID=0 (Root) automatisch UID=65534 (anonym) zu, die nur eingeschränkte Berechtigungen für das Dateisystem hat. Weitere Informationen finden Sie unter Nutzer-ID-Squashing.
NFSv4.1 mit Kerberos
NFSv4.1 mit Kerberos verwendet Exportrichtlinien und eine 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 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 Verwaltungsclients.
| 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 bereitgestellt werden,
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, bestimmt der Zugriff auf Dateiebene, was ein Nutzer tun darf. Weitere Informationen finden Sie unter NFS-Zugriffssteuerung auf Dateiebene für UNIX-ähnliche Volumes.
Exportrichtlinien verwalten
Folgen Sie der Anleitung unten, um die Exportrichtlinie eines Volumes mit der Google Cloud CLI zu aktualisieren.
gcloud
Volume mit einer Exportrichtlinie aktualisieren
So aktualisieren Sie ein Volume mit einer Exportrichtlinienregel:
gcloud netapp volumes update VOLUME_ID \ --project=PROJECT_ID \ --location=LOCATION \ --export-policy=access-type=ACCESS_TYPE,allowed-clients=ALLOWED_CLIENTS_IP_ADDRESSES,has-root-access=TRUE_OR_FALSE,nfsv3=NFSV3,nfsv4=NFSV4
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 Standort des Volumes.ACCESS_TYPE: Der Zugriffstyp muss entwederREAD_WRITE,READ_ONLYoderREAD_NONEsein.ALLOWED_CLIENTS_IP_ADDRESSES: eine durch Kommas getrennte Liste der IP-Adressen oder ‑Bereiche der zulässigen Clients.NFSV3: Legen Sietrueoderfalsefest, um diese Regel auf NFSv3 anzuwenden.NFSV4: Legen Sietrueoderfalsefest, um diese Regel auf NFSv4 anzuwenden.
Mehrere Exportrichtlinienregeln hinzufügen
Wenn Sie mehrere Exportregeln hinzufügen möchten, wiederholen Sie den Parameterblock export-policy.
Jeder Parameterblock export-policy besteht aus mehreren Schlüssel/Wert-Paaren im folgenden Format:
--export-policy=KEY1=VALUE1,KEY2=VALUE2,KEY3=VALUE3...
Beispiel: Doppelpunkt und Komma als Trennzeichen verwenden
Wenn Sie mehrere IP-Adressen oder CIDRs für allowed-clients angeben, werden die Werte möglicherweise nicht korrekt von der Google Cloud CLI geparst, da das Flag --export-policy Kommas als Standardtrennzeichen zwischen verschiedenen Schlüsseln wie access-type und nfsv3 verwendet. Wenn ein Wert wie allowed-clients auch Kommas enthält, kann der Parser nicht zwischen einem neuen Schlüssel/Wert-Paar und einer zusätzlichen IP-Adresse in der Liste allowed-clients unterscheiden. Um diese Kommas zu unterscheiden, konfigurieren Sie die Google Cloud CLI so, dass ein
anderes Parameter-Trennzeichen mit Google Cloud CLI-Escapingverwendet wird.
Der folgende Befehl zeigt das Beispiel aus
Best Practices für Exportrichtlinien.
Die erste Regel verwendet einen Doppelpunkt als Parameter-Trennzeichen, um die durch Kommas getrennte Liste allowed-clients korrekt zu parsen. Die zweite und dritte Regel verwenden das Standardkomma als Trennzeichen.
gcloud netapp volumes update my_volume --location=us-east4 \ --export-policy=^:^access-type=READ_WRITE:allowed-clients="10.10.5.3,10.10.5.9":nfsv3=true:nfsv4=true:has-root-access=true \ --export-policy=access-type=READ_WRITE,allowed-clients=10.0.5.0/24,nfsv3=true,has-root-access=false \ --export-policy=access-type=READ_ONLY,allowed-clients=10.0.6.0/24,nfsv3=true,has-root-access=false
Beispiel: squash-mode als Parameter verwenden
Im folgenden Beispiel wird der alternative Parameter squash-mode verwendet, um eine NO_ROOT_SQUASH-Regel für Administratorhosts und eine ALL_SQUASH-Regel für einen CIDR-Bereich zu erstellen.
gcloud netapp volumes update my_volume --location=us-east4 \ --export-policy=^:^allowed-clients="10.10.5.3,10.10.5.9":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 unter Google Cloud SDK für Exportrichtlinien für Volumes.
Nutzer-ID-Squashing
NFS-Exportrichtlinien bieten Steuerelemente für das Squashing von Nutzer- und Gruppen-IDs, mit denen Sie Nutzer- und Gruppen-IDs aus Sicherheitsgründen einer anonymen Nutzer-ID zuordnen können.
Root-Squashing
NFS-Server verbessern die Sicherheit, indem sie den Root-Nutzer (UID=0) auf „nobody“ (UID=65534) umleiten. Dadurch wird Root zu einem nicht privilegierten Nutzer für den Dateizugriff auf das Volume. Diese Funktion wird als Root-Squashing bezeichnet. Die Option, sie zu deaktivieren und die Berechtigungen von Root beizubehalten, 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 Console eine
Exportrichtlinienregel erstellen, enthalten dieStandardeinstellungen den Zugriff Lesen und Schreiben und Root-Squashing. Die
Google Cloud API, die Google Cloud CLI und Terraform unterstützten zuvor die Steuerung
des Root-Squashing mit dem has-root-access Parameter. has-root-access wird zwar weiterhin akzeptiert, wurde aber durch den Parameter squash-mode ersetzt.
Erstellen Sie als Best Practice eine spezielle Exportregel, die den Root-Zugriff für Ihre vertrauenswürdigen Administratorhosts aktiviert und den Root-Zugriff für andere Clients deaktiviert. Platzieren Sie diese Regel zuerst, vor allgemeineren Regeln.
Squashing von Nutzer- und Gruppen-IDs
Mit dem Parameter squash-mode können Sie sowohl Nutzer- als auch Gruppen-IDs auf eine anonyme UID umleiten. Das kann für öffentliche SFTP-Dropbox-Verzeichnisse nützlich sein. Dieser Parameter ersetzt auch den Parameter has-root-access und wird von 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 auf „nobody“ umgeleitet.all-squash: Diese Option bietet anonymen Zugriff für alle Nutzer, einschließlich Root. Alle Nutzer werden auf die UID und GID umgeleitet, die durch den Parameteranon-uidangegeben werden. Wenn Sieall-squashverwenden, müssen Sie auchanon-uidangeben undaccess-typeaufREAD_WRITEsetzen.
Hinweise
Beachten Sie Folgendes für Exportrichtlinienregeln mit squash mode:
Eine Exportrichtlinie unterstützt nur eine
all-squash-Regel.Wenn
all-squashaktiviert ist, wird der Root-Nutzer auf „anonym“ umgeleitet. Dies kann durch eine Regel mit höherer Priorität überschrieben werden, dieno-root-squashverwendet.Die Volume-Replikation wird für Volumes mit einer Exportrichtlinienregel im Stil
squash-modenicht unterstützt.Beim Service-Level „Flex File“ ändert
all-squashdie Inhaberschaft des Root-Inode des Volumes nicht automatisch. Fügen Sie dazu eineno-root-squash-Exportregel hinzu, mit der der Root-Nutzer mitchowndie Inhaberschaft des Root-Inode in die erforderliche UID ändern kann.Der Parameter
has-root-accesswird unterstützt. Verwenden Sie entwederhas-root-accessodersquash-mode, aber nicht beide Parameter gleichzeitig.Beim Service-Level „Flex Unified“ wird
all-squashnicht unterstützt.
Anleitung zum Bereitstellen für NFS-Clients
Folgen Sie der Anleitung unten, um eine Anleitung zum Bereitstellen für NFS-Clients mit der Google Cloud Console, der Google Cloud CLI oder dem ONTAP-Modus zu erhalten.
Console
Rufen Sie in der Google Cloud Console die Seite NetApp Volumes auf.
Klicken Sie auf Volumes.
Klicken Sie auf Mehr anzeigen.
Wählen Sie Anleitung zum Bereitstellen aus.
Folgen Sie der Anleitung zum Bereitstellen in der Google Cloud Console.
Ermitteln Sie den Bereitstellungsbefehl und verwenden Sie die Bereitstellungsoptionen, es sei denn, Ihre Arbeitslast hat spezifische Anforderungen an die Bereitstellungsoptionen.
Nur NFSv3: Wenn Ihre Anwendung keine Sperren verwendet oder Sie Ihre Clients nicht für die NSM-Kommunikation konfiguriert haben, empfehlen wir, die Bereitstellungsoption
nolockhinzuzufügen.
gcloud
So rufen Sie die Anleitung zum Bereitstellen 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: der Name des Volumes.PROJECT_ID: der Name des Projekts, in dem sich das Volume befindet.LOCATION: der Standort des Volumes.
Weitere Informationen zu zusätzlichen optionalen Flags finden Sie in der Google Cloud SDK-Dokumentation zu Volumes.
ONTAP-Modus
Führen Sie die folgenden Schritte aus, um den Hostnamen oder die IP-Adresse und den Exportpfad Ihres Volumes zu ermitteln:
Suchen Sie alle Netzwerkschnittstellen für den Dienst
data_cifs.Bestimmen Sie den Exportpfad, der dem Verbindungspfad entspricht, den Sie für Ihr Volume angegeben haben.
Erstellen Sie den Bereitstellungspfad im Format
<var>IP</var>:<var>junction-path</var>. Fügen Sie alle erforderlichen Bereitstellungsoptionen hinzu.
Nachdem Sie die erforderlichen Befehle ermittelt haben, finden Sie unter ONTAP-Modus eine Anleitung zum Senden von ONTAP-Befehlen an den Speicherpool.
Zusätzliche Anleitung für NFSv4.1
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. Der Linux-Bereitstellungsbefehl stellt immer die höchste verfügbare NFS-Version bereit, es sei denn, Sie geben die bereitzustellende Version an. Wenn Sie mit NFSv4.1 bereitstellen 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 Sicherheits-IDs verwendet werden.
Sicherheits-IDs sind Strings im Format <username|groupname>@<full_qualified_domain>.
Ein Beispiel für eine Sicherheits-ID ist bob@example.com.
Der Client muss die intern verwendeten UIDs und GIDs in eine Sicherheits-
ID übersetzen, bevor er eine NFSv4-Anfrage an den Server sendet. Der Server muss die Sicherheits-IDs 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.
Wenn Sie Kerberos für NFSv4 verwenden, werden in der Sicherheits-ID Kerberos-Principals im Format username@DOMAINNAME gespeichert, wobei DOMAINNAME (in Großbuchstaben) zum Realm-Namen wird.
Numerische IDs
Für Nutzer, die die Namenszuordnungen nicht konfigurieren und stattdessen NFSv4 als Ersatz für NFSv3 verwenden möchten, hat NFSv4 eine Option namens numeric ID eingeführt, die codierte Textstrings für UID und GID als Sicherheits-IDs sendet. Dadurch wird der Konfigurationsprozess für Nutzer vereinfacht.
Mit dem folgenden Befehl können Sie die 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 von der Art der IDs oder Sicherheits-IDs, die Sie verwenden, müssen Sie rpc.idmapd auf Ihrem NFS-Client konfigurieren. Wenn Sie der Installationsanleitung für Clientdienstprogramme im Abschnitt Hinweis gefolgt sind, sollte es 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 bereitstellen. Die Mindestkonfiguration für rpc.idmapd besteht darin, die Domain-Einstellung einzurichten. Andernfalls wird der Root-Nutzer als „nobody“ mit
UID=65534 or 4294967295 angezeigt.
Folgen Sie der Anleitung unten, um rpc.idmapd auf Ihrem NFS-Client zu konfigurieren:
Öffnen Sie auf Ihrem Client die Datei
/etc/idmapd.confund ändern Sie den Domain-Parameter in einen der folgenden Werte:Wenn Ihr Volume nicht für LDAP aktiviert ist,
domain = defaultv4iddomain.com.Wenn Ihr Volume für LDAP aktiviert ist,
domain = <FDQN_of_Windows_Domain>.
Aktivieren Sie die Änderungen an
rpc.idmapd, indem Sie den folgenden Befehl ausführen:nfsidmap -c
NFSv4.2-Unterstützung
Die Service-Levels „Flex Unified“, „Standard“, „Premium“ und „Extreme“ unterstützen jetzt zusätzlich zu NFSv4.1 auch das NFSv4.2-Protokoll auf Volumes, für die NFSv4.1 bereits aktiviert ist.
Beim Bereitstellen eines NFS-Volumes wählt der Linux-Bereitstellungsbefehl automatisch die höchste verfügbare NFS-Version aus. Wenn Sie ein für NFSv4.1 aktiviertes Volume bereitstellen, wird standardmäßig NFSv4.2 verwendet, es sei denn, die Bereitstellungsoption vers=4.1 ist explizit angegeben.
NetApp Volumes unterstützt erweiterte NFS-Attribute xattrs mit NFSv4.2. Die Verwendung und Einschränkungen von xattrs, wie in
TR-4962 beschrieben, gelten
ebenfalls.
Firewallregeln für den Zugriff auf NFS-Volumes
NFS verwendet mehrere Ports für die Kommunikation zwischen dem Client und einem Server. Für die Kommunikation zwischen Google Compute Engine und NetApp Volumes werden diese Ports standardmäßig nicht blockiert. Wenn Sie eine Firewall verwenden, müssen Sie den Zugriff auf die folgenden Ports für den vollständigen NetApp Volume PSA CIDR oder die einzelnen Volume-IP-Adressen aktivieren:
111 TCP/UDP portmapper635 TCP/UDP mountd2049 TCP/UDP nfsd4045 TCP/UDP nlockmgr(nur für NFSv3)4046 TCP/UDP status(nur für NFSv3)
Die IP-Adressen für NetApp Volumes werden automatisch aus dem CIDR-Bereich zugewiesen, den Sie dem Dienst während des Netzwerk-Peerings zugewiesen haben. Weitere Informationen finden Sie unter Zugriff auf private Dienste konfigurieren.
Verwendung von Advisory Locks mit NFSv3
Wenn Sie Advisory Locks mit NFSv3 verwenden, müssen Sie den Daemon rpc.statd auf Ihrem Client ausführen, um Network Lock Manager zu unterstützen. Dieser funktioniert mit NFS, um Advisory Locks für Dateien und Datensätze im Stil von System V über das Netzwerk bereitzustellen. Ihr NFS-Client muss einen Ingress-Port für rpc.statd öffnen, um Network Lock Manager-Callbacks zu empfangen. In den meisten Linux-Distributionen wird rpc.statd gestartet, wenn Sie die erste NFS-Freigabe bereitstellen. Dabei wird ein zufälliger Port verwendet, den Sie mit dem Befehl rpcinfo -p ermitteln können. Damit rpc.statd mit Firewalls kompatibel ist, konfigurieren Sie es so, dass ein statischer Port verwendet wird.
Informationen zum Festlegen statischer Ports für rpc.statd finden Sie in den folgenden Ressourcen:
Wenn Sie keine NFSv3-Advisory Locks oder Network Lock Manager verwenden, können Sie Ihre NFSv3-Freigaben mit der Bereitstellungsoption nolock bereitstellen.
NFSv4.1 implementiert die Sperrfunktion im NFSv4.1-Protokoll, das über die vom Client initiierte TCP-Verbindung zum NFSv4.1-Server auf Port 2049 ausgeführt wird.
Der Client muss keine Firewallports für eingehenden Traffic öffnen.
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.
Um einheitliche Nutzerinformationen zwischen NFS-Client und ‑Server zu gewährleisten, 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:
Wenn Sie Kerberized NFS verwenden, müssen Sie möglicherweise die in diesem Abschnitt genannten Bereitstellungsanleitungen verwenden, um LDAP zu konfigurieren und die Konsistenz zwischen Client und Server zu gewährleisten.
Nächste Schritte
Volumes mit hoher Kapazität mit mehreren Speicherendpunkten verbinden.