Unterstützte Dateisystemprotokolle

Filestore unterstützt die folgenden Dateisystemprotokolle:

NFSv3

  • In allen Service-Stufen verfügbar.
  • Unterstützt die bidirektionale Kommunikation zwischen Client und Server.
    • Verwendet mehrere Ports.
    • Erstellt einen Vertrauenschannel für Netzwerkverkehr und ‑vorgänge.
  • Bietet eine schnelle Einrichtung für den Standard-POSIX-Zugriff.

NFSv4.1

  • Verfügbar in den Dienststufen „Zonal“, „Regional“ und „Enterprise“.
  • Wird vom Filestore-CSI-Treiber unterstützt, um zonale oder Enterprise-Instanzen zu erstellen und mit NFSv4.1-Semantik einzubinden.
  • Kompatibel mit modernen Firewallkonfigurationen und unterstützt die Einhaltung von Anforderungen an die Netzwerksicherheit.
    • Die Kommunikation wird immer vom Client initiiert und immer über einen einzelnen Serverport, 2049, bereitgestellt.
    • Unterstützt die 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 unternehmensweit
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 in Managed Service for Microsoft Active Directory verfügbar.
Unterstützt ACLs (Access Control Lists) für Dateien oder Verzeichnisse Nein Ja. Es werden bis zu 50 Access Control Entries (ACEs) pro Liste unterstützt.
Unterstützung für Gruppen Bis zu 16 Gruppen Unbegrenzte Unterstützung von 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 Authentifizierungs- und Nachrichtenintegritätsprüfungen.krb5p. Bietet Authentifizierung, Prüfungen der Nachrichtenintegrität und Verschlüsselung von Daten während der Übertragung.
Vorgangslatenz Keine Die Latenz von Vorgängen steigt mit dem ausgewählten Sicherheitsniveau.
Wiederherstellungstyp Zustandslos Zustandsorientiert
Typ der Dateisperrung Network Lock Manager (NLM). Die Sperre wird vom Client gesteuert. Leasebasierte Empfehlungsperre. Die Sperre wird vom Server gesteuert.
Unterstützung bei Clientfehlern Nein Ja
Unterstützt den Zugriff auf private Dienste Ja Ja
Unterstützt Private Service Connect (GA auf der Zulassungsliste) Nein Ja

Vorteile von NFSv3

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

NFSv3-Einschränkungen

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

  • Es fehlt die Client- und Serverauthentifizierung sowie die Verschlüsselung.
  • Es fehlt die Fehlerbehandlung für den Client.

Vorteile von NFSv4.1

Das NFSv4.1-Protokoll verwendet die RPCSEC_GSS-Authentifizierung, die mit LDAP und Kerberos implementiert wird, um Client- und Serverauthentifizierung, Prüfungen der Nachrichtenintegrität und die Verschlüsselung von Daten bei der Übertragung zu ermöglichen.

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

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

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

    • Jede ACL unterstützt bis zu 50 ACEs (Access Control Entries) pro Datei oder Verzeichnis. Dazu gehören auch Erbschaftsnachweise.

  • Bei der Einbindung von Managed Microsoft AD werden unbegrenzt viele Gruppen unterstützt.

  • Unterstützt eine bessere Behandlung von Clientfehlern mit leasebasierten Empfehlungssperren.

    • Der Client muss die fortgesetzte Verbindung zum Server bestätigen. Wenn der Client die Lease nicht verlängert, gibt der Server die Sperre frei und die Datei wird für jeden anderen Client verfügbar, der über eine Lock-Lease Zugriff anfordert. Wenn in NFSv3 ein Client gelöscht wird, während er gesperrt ist, kann nicht über einen anderen Client, z. B. einen neuen GKE-Knoten, auf die Datei zugegriffen werden.

  • Unterstützt die zustandsorientierte Wiederherstellung.

    • Im Gegensatz zu NFSv3 ist NFSv4.1 ein zustandsorientiertes Protokoll, das auf TCP und Verbindungen basiert. Der Status von Client und Server 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 zwingende Voraussetzung, aber die einzige von Google Cloudverwaltete Lösung, die sowohl LDAP als auch Kerberos unterstützt. Beide sind für das Filestore-NFSv4.1-Protokoll erforderlich.

Administratoren wird dringend empfohlen, Managed Service for Microsoft Active Directory (Managed Microsoft AD) zu verwenden, um LDAP und Kerberos zu implementieren und zu verwalten.

Als von Google Cloudverwaltete Lösung bietet Managed Microsoft AD die folgenden Vorteile:

  • Bietet die Bereitstellung in mehreren Regionen und unterstützt bis zu fünf Regionen in derselben Domain.

    • Die Latenz wird verringert, 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 Zuordnung von eindeutigen Kennungen (UID) und global eindeutigen Kennungen (GUID) zu Nutzern.

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

  • Administratoren können eine Vertrauensstellung für die aktuelle lokale, selbstverwaltete Active Directory-Domain (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 durch Clientvorgänge von chmod erstellt werden. Diese ACEs können nach dem Erstellen geändert werden.

    Die automatisch generierten ACE-Einträge, die die Modusbits darstellen, werden 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 entsprechend den neuen angewendeten Modus-Bits geändert.

  • Filestore NFSv4.1 unterstützt die Prü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 nfs4_setfacl-Tool akzeptiert auch RWX als Abkürzung und aktiviert automatisch alle entsprechenden Flags.

  • Das nfs4_getfacl übersetzt das Hauptkonto nicht automatisch. Das Dienstprogramm nfs4_getfacl zeigt die numerischen UID und GUID für die Principals an. Daher werden die speziellen Hauptkonten von OWNER@, GROUP@ und EVERYONE@ angezeigt.

  • Unabhängig davon, ob Sie Managed Microsoft AD verwenden, müssen Administratoren bei der Arbeit mit AUTH-SYS und dem nfs4_setfacl-Dienstprogramm die numerischen UID und GUID angeben, nicht die Nutzernamen. Mit diesem Tool können Namen nicht in diese Werte übersetzt werden. Wenn sie nicht korrekt angegeben wird, wird für die Filestore-Instanz standardmäßig die nobody-ID verwendet.

  • Wenn Sie Schreibberechtigungen für eine Datei oder sogar für Dateien angeben, die von einem geerbten ACE betroffen sind, muss der 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 in folgender Weise POSIX:

    • Der Superuser oder ROOT-Nutzer kann alles tun.
    • Nur der Dateieigentümer kann die Modusbits, ACLs und Zeitstempel auf eine bestimmte Zeit und Gruppe festlegen, z. B. auf eine der GUID, zu der sie gehört.
    • Andere Nutzer als der Dateieigentümer können die Attribute, einschließlich der ACL, ansehen.

  • Ein einzelner ACE umfasst sowohl effektive als auch nur geerbte Berechtigungen. Im Gegensatz zu anderen NFSv4.1-Implementierungen repliziert Filestore geerbte ACEs nicht automatisch, um zwischen effektiven und nur geerbten ACEs zu unterscheiden.

NFSv4.1-Einschränkungen

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

  • Das NFSv4.1-Protokoll kann nicht mit Filestore-Multishares für GKE kombiniert werden.

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

  • Nach der Konfiguration dürfen Sie Managed Microsoft AD und das Netzwerk-Peering nicht löschen. Dadurch wird die Filestore-Freigabe unzugänglich, wenn sie auf einem Client gemountet ist, und Ihre Daten sind nicht mehr verfügbar. Google Cloud ist nicht für Ausfälle verantwortlich, die durch Administrator- oder Nutzeraktionen verursacht werden.

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

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

  • Die Filestore-NFSv4.1-Lösung verwendet die RPCSEC_GSS-Authentifizierung, die mit LDAP und Kerberos implementiert wird. Beide sind in Managed Microsoft AD verfügbar. Filestore NFSv4.1 kann wie NFSv3 auch ohne Authentifizierungsmechanismen verwendet werden. Andere Authentifizierungsmethoden werden nicht unterstützt.

  • Wenn eine Filestore-Instanz über eine freigegebene VPC in Managed Microsoft AD eingebunden werden soll, müssen Sie gcloud oder die Filestore API verwenden. Sie können die Instanz nicht über dieGoogle Cloud -Konsole mit Managed Microsoft AD verknüpfen.

  • Der Domainname für Managed Microsoft AD darf maximal 56 Zeichen lang sein.

  • Wenn Sie eine Enterprise-Instanz erstellen möchten, müssen Sie 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