Unterstützte Dateisystemprotokolle

Filestore unterstützt die folgenden Dateisystemprotokolle:

NFSv3

  • Verfügbar in allen Dienststufen.
  • Unterstützt die bidirektionale Kommunikation zwischen Client und Server.
    • Es werden mehrere Ports verwendet.
    • Erstellt einen Vertrauenskanal für Netzwerkverkehr und -funktionen.
  • Bietet eine schnelle Einrichtung für den standardmäßigen POSIX-Zugriff.

NFSv4.1

  • Verfügbar in zonalen, regionalen und Enterprise-Dienstebenen.
  • Kompatibel mit modernen Firewallkonfigurationen und unterstützt die Complianceanforderungen für die Netzwerksicherheit.
    • Die Kommunikation wird immer vom Client initiiert und immer über einen einzelnen Serverport, 2049, bereitgestellt.
    • Unterstützt Client- und Serverauthentifizierung.

Jedes Protokoll eignet sich am besten für bestimmte Anwendungsfälle. In der folgenden Tabelle werden die Spezifikationen der einzelnen Protokolle verglichen:

Spezifikation NFSv3 NFSv4.1
Unterstützte Dienststufen Alle Dienststufen Zonal, regional und für Unternehmen
Bidirektionale Kommunikation Ja Nein. Die Kommunikation wird immer vom Client über den Serverport 2049 initiiert.
Authentifizierung Nein Ja. Erfordert die RPCSEC_GSS-Authentifizierung, die mit LDAP und Kerberos implementiert wird. Beide sind im Managed Service for Microsoft Active Directory verfügbar.
Unterstützt Datei- oder Verzeichnis-ACLs (Access Control Lists) Nein Ja. Unterstützt bis zu 50 ACEs (Access Control Entries) pro Liste.
Google Groups-Support Bis zu 16 Gruppen Unterstützung für unbegrenzte Gruppen bei Verbindung mit Managed Microsoft AD.
Sicherheitseinstellung sys. Erstellt einen Vertrauenskanal. sys. Erstellt einen Vertrauenskanal. krb5. Authentifiziert den Client und den Server. krb5i. Bietet Authentifizierung und Nachrichtenintegritätsprüfungen.krb5p. Bietet Authentifizierung, Nachrichtenintegritätsprüfungen und Datenverschlüsselung während der Übertragung.
Vorgangslatenz Keine Die Latenz der Vorgänge erhöht sich mit dem ausgewählten Sicherheitsniveau.
Wiederherstellungstyp Zustandslos Zustandsorientiert
Sperrtyp der Datei Network Lock Manager (NLM) Das Schloss wird vom Client gesteuert. Lease-basierte richtlinienbasierte Sperrung Die Sperre wird vom Server gesteuert.
Unterstützt Clientfehler Nein Ja
Unterstützt den Zugriff auf private Dienste Nein Nein

Vorteile von NFSv3

Das NFSv3-Protokoll bietet eine schnelle Einrichtung für den standardmäßigen POSIX-Zugriff.

Einschränkungen von NFSv3

Im Folgenden finden Sie eine Liste der Einschränkungen von NFSv3:

  • Es wird kein Zugriff auf private Dienste unterstützt.
  • Es fehlt die Client- und Serverauthentifizierung und -verschlüsselung.
  • Es gibt keine Fehlerbehandlung für Clients.

Vorteile von NFSv4.1

Das NFSv4.1-Protokoll verwendet die RPCSEC_GSS-Authentifizierung, die mit LDAP und Kerberos implementiert wird, um Client- und Serverauthentifizierung, Nachrichtenintegritätsprüfungen und die Verschlüsselung von Daten während der Übertragung bereitzustellen.

Diese Sicherheitsfunktionen machen das NFSv4.1-Protokoll mit modernen Compliance-Anforderungen an die Netzwerksicherheit kompatibel:

  • Für die gesamte Kommunikation wird ein einzelner Serverport (2049) verwendet, was die Firewallkonfiguration vereinfacht.

  • Unterstützt NFSv4.1-Datei-ACLs (Access Control Lists).

    • Jede ACL unterstützt bis zu 50 Zugriffssteuerungseinträge (ACEs) pro Datei oder Verzeichnis. Dazu gehören auch Inventarlisten.

  • Unterstützung für unbegrenzte Gruppen bei Verwendung der Managed Microsoft AD-Integration.

  • Bessere Fehlerbehandlung bei Clients durch leasebasierte richtlinienbasierte Sperrung

    • Der Client muss die fortlaufende Verbindung zum Server prüfen. Wenn der Client den Lease nicht verlängert, löst der Server die Sperre auf und die Datei wird für alle anderen Clients verfügbar, die über einen Lease Zugriff anfordern. Wenn in NFSv3 ein Client gelöscht wird, während er gesperrt ist, kann kein anderer Client, z. B. ein neuer GKE-Knoten, auf die Datei zugreifen.

  • Unterstützt die zustandsorientierte Wiederherstellung.

    • Im Gegensatz zu NFSv3 ist NFSv4.1 ein TCP- und verbindungsbasiertes zustandsorientiertes Protokoll. Der Status des Clients und des Servers in der vorherigen Sitzung kann nach der Wiederherstellung fortgesetzt werden.

Managed Service for Microsoft Active Directory

Managed Service for Microsoft Active Directory (Managed Microsoft AD) ist zwar keine strenge Anforderung, aber die einzige von Google Cloud verwaltete Lösung, die sowohl LDAP als auch Kerberos unterstützt. Beides sind Anforderungen für das Filestore NFSv4.1-Protokoll.

Administratoren wird dringend empfohlen, Managed Service for Microsoft Active Directory (Managed Microsoft AD) zur Implementierung und Verwaltung von LDAP und Kerberos zu verwenden.

Als von Google Cloud verwaltete Lösung bietet Managed Microsoft AD folgende Vorteile:

  • Bietet eine Bereitstellung für mehrere Regionen mit bis zu fünf Regionen in derselben Domain.

    • Verringert die Latenz, da Nutzer und ihre jeweiligen Anmeldeserver näher beieinander sind.

  • Unterstützt POSIX RFC 2307 und RFC 2307bis, Anforderungen für die NFSv4.1-Implementierung.

  • Automatisiert die Nutzerzuordnung für eindeutige Kennungen (UID) und global eindeutige Kennungen (GUID).

  • Nutzer und Gruppen können in Managed Microsoft AD erstellt oder dorthin migriert werden.

  • Administratoren können eine Domain-Vertrauensstellung mit der aktuellen lokalen, selbst verwalteten Active Directory- (AD-) und LDAP-Domain erstellen. Bei dieser Option ist keine Migration erforderlich.

  • Bietet ein SLA.

Zugriffssteuerung und zusätzliches Verhalten

  • Filestore NFSv4.1-ACEs werden unter Linux mit den folgenden Befehlen verwaltet:

    • nfs4_setfacl: Erstellen oder bearbeiten Sie ACEs für eine Datei oder ein Verzeichnis.
    • nfs4_getfacl: Listet die ACEs für eine Datei oder ein Verzeichnis auf.

  • Jede ACL unterstützt bis zu 50 ACEs. Sechs Einträge sind für automatisch generierte ACEs reserviert, die von chmod-Vorgängen des Kunden erstellt wurden. Diese ACEs können nach dem Erstellen geändert werden.

    Die automatisch generierten ACE-Einträge, die die Modusbits darstellen, sind in der folgenden Prioritätsreihenfolge aufgeführt:

    • DENY and ALLOW ACEs für die OWNER@
    • DENY and ALLOW ACEs für die GROUP@

    • DENY and ALLOW ACEs für EVERYONE@

      Wenn solche ACEs bereits vorhanden sind, werden sie wiederverwendet und gemäß den neuen angewandten Modus-Bits geändert.

  • Filestore NFSv4.1 unterstützt die Überprüfung des erforderlichen Zugriffs nur im POSIX-Modus RWX (Lesen, Schreiben und Ausführen). Es wird nicht zwischen write append- und write-Vorgängen unterschieden, die den Inhalt oder die SETATTR-Spezifikation ändern. Das Dienstprogramm nfs4_setfacl akzeptiert auch RWX als Verknüpfung und aktiviert automatisch alle entsprechenden Flags.

  • Die nfs4_getfacl führt keine Übersetzung des Prinzipals aus. Das nfs4_getfacl-Dienstprogramm zeigt die numerischen UID und GUID für die Hauptbenutzer an. Daher werden die speziellen Hauptkonten von OWNER@, GROUP@ und EVERYONE@ angezeigt.

  • Unabhängig davon, ob Managed Microsoft AD verwendet wird, müssen Administratoren bei der Arbeit mit AUTH-SYS und dem Dienstprogramm nfs4_setfacl die numerischen UID und GUID angeben, keine Nutzernamen. Dieses Dienstprogramm kann Namen nicht in diese Werte umwandeln. Wenn die Angabe nicht korrekt ist, wird für die Filestore-Instanz standardmäßig die nobody-ID verwendet.

  • Wenn Sie Schreibberechtigungen für eine Datei oder für Dateien angeben, die von einer übergeordneten ACE betroffen sind, muss die ACE sowohl die Flags w (Schreiben) als auch a (Anhängen) enthalten.

  • Wenn Sie die Berechtigungen für SETATTR prüfen, ähnelt die zurückgegebene Antwort POSIX in folgender Weise:

    • Superuser oder ROOT-Nutzer können alles tun.
    • Nur der Eigentümer der Datei kann die Bits für den Dateimodus, die ACLs und die Zeitstempel auf eine bestimmte Zeit und Gruppe festlegen, z. B. auf eine der GUIDs, zu denen sie gehört.
    • Andere Nutzer als der Eigentümer der Datei können die Attribute, einschließlich der ACL, aufrufen.

  • Ein einzelner ACE umfasst sowohl effektive als auch nur vererbbare Berechtigungen. Im Gegensatz zu anderen NFSv4.1-Implementierungen werden in Filestore nicht automatisch übernommene Zugriffssteuerungsobjekte repliziert, um zwischen effektiven und nur übernommenen Zugriffssteuerungsobjekten zu unterscheiden.

Einschränkungen von NFSv4.1

Im Folgenden finden Sie eine Liste der Einschränkungen von NFSv4.1:

  • Das NFSv4.1-Protokoll kann nicht mit den folgenden Funktionen kombiniert werden:

  • Das NFSv4.1-Protokoll unterstützt AUDIT and ALARM ACEs nicht. Filestore unterstützt keine Prüfung des Datenzugriffs.

  • Löschen Sie Managed Microsoft AD und das Netzwerk-Peering nach der Konfiguration nicht. Dadurch ist die Filestore-Freigabe nicht zugänglich, während sie auf einem Client bereitgestellt wird, und Ihre Daten sind nicht zugänglich. Google Cloud haftet nicht für Ausfälle, die durch Administrator- oder Nutzeraktionen verursacht werden.

  • Bei Verwendung einer der authentifizierten Kerberos-Sicherheitseinstellungen kann es zu einer gewissen Latenz bei den Vorgängen kommen. Die Latenzraten variieren je nach Dienstebene und angegebener Sicherheitseinstellung. Die Latenz steigt mit jedem höheren Sicherheitsniveau.

  • Die Prüfung des Datenzugriffs wird nicht unterstützt.

  • Für die Filestore NFSv4.1-Lösung ist die RPCSEC_GSS-Authentifizierung erforderlich. Diese Authentifizierungsmethode wird nur mit LDAP und Kerberos implementiert, die beide in Managed Microsoft AD verfügbar sind. Andere Authentifizierungsmechanismen werden nicht unterstützt.

  • Es wird kein Zugriff auf private Dienste unterstützt.

  • Wenn Sie eine Filestore-Instanz über ein freigegebene VPC mit Managed Microsoft AD verknüpfen möchten, müssen Sie gcloud oder die Filestore API verwenden. Sie können die Instanz nicht über die Google Cloud Console mit Managed Microsoft AD verknüpfen.

  • Der Domainname der verwalteten Microsoft AD-Instanz darf maximal 56 Zeichen lang sein.

  • Wenn Sie eine Enterprise-Instanz erstellen möchten, müssen Sie die Vorgänge direkt über die Filestore API ausführen. Weitere Informationen finden Sie unter Dienststufen.

  • Beim Wiederherstellen einer Sicherung muss die neue Instanz dasselbe Protokoll wie die Quellinstanz verwenden.

Nächste Schritte