Grundlegendes zu NAS-Protokollen in Azure NetApp-Dateien

Artikel
12/15/2023

NAS-Protokolle stellen fest, wie Unterhaltungen zwischen Clients und Servern stattfinden. NFS und SMB sind die NAS-Protokolle, die in Azure NetApp Files verwendet werden. Jede bietet ihre eigenen unterschiedlichen Methoden für die Kommunikation, aber in ihrer Wurzel arbeiten sie meist auf die gleiche Weise.

Beide dienen einem einzelnen Dataset für viele unterschiedlichen netzwerkgebundenen Clients.
Beide können verschlüsselte Authentifizierungsmethoden zum Freigeben von Daten verwenden.
Beide können mit Freigabe- und Dateiberechtigungen abgesperrt werden.
Beide können Daten in-Flight verschlüsseln.
Beide können mehrere Verbindungen verwenden, um die Leistung zu parallelisieren.

Network File System (NFS)

NFS wird hauptsächlich mit Linux/UNIX-basierten Clients wie Red Hat, SUSE, Ubuntu, AIX, Solaris und Apple OS verwendet. Azure NetApp Files unterstützt jeden NFS-Client, der in den RFC-Standards arbeitet. Windows kann auch NFS für den Zugriff verwenden, funktioniert jedoch nicht mit RFC-Standards (Request for Comments).

RFC-Standards für NFS-Protokolle finden Sie hier:

NFSv3

NFSv3 ist ein grundlegendes Angebot des Protokolls und hat die folgenden Schlüsselattribute:

NFSv3 ist zustandslos, was bedeutet, dass der NFS-Server die Zustände der Verbindungen (einschließlich Sperren) nicht nachverfolgt.
Die Sperrung wird außerhalb des NFS-Protokolls mit Network Lock Manager (NLM) behandelt. Da Sperren nicht in das Protokoll integriert sind, können veraltete Sperren manchmal auftreten.
Da NFSv3 zustandslos ist, kann die Leistung mit NFSv3 in einigen Workloads erheblich besser sein, insbesondere bei Workloads mit Vorgängen mit hohen Metadaten wie OPEN, CLOSE, SETATTR und GETATTR. Dies ist der Fall, da es weniger allgemeine Arbeit gibt, die zum Verarbeiten von Anforderungen auf dem Server und Client durchgeführt werden muss.
NFSv3 verwendet ein grundlegendes Dateiberechtigungsmodell, bei dem nur der Besitzer der Datei, eine Gruppe und alle anderen Personen eine Kombination aus Lese-/Schreib-/Ausführungsberechtigungen zugewiesen werden können.
NFSv3 kann NFSv4.x ACLs verwenden, ein NFSv4.x-Verwaltungsclient wäre jedoch erforderlich, um die ACLs zu konfigurieren und zu verwalten. Azure NetApp Files unterstützt nicht die Verwendung nicht standardmäßiger POSIX-Entwurfs-ACLs.
NFSv3 erfordert auch die Verwendung anderer zusätzlicher Protokolle für regelmäßige Vorgänge wie Portermittlung, Montage, Sperrung, Statusüberwachung und Kontingente. Jedes zusätzliche Protokoll verwendet einen eindeutigen Netzwerkport, was bedeutet, dass NFSv3-Vorgänge durch Firewalls mit bekannten Portnummern mehr Gefährdung erfordern.
Azure NetApp Files verwendet die folgenden Portnummern für NFSv3-Vorgänge. Es ist nicht möglich, diese Portnummern zu ändern:
- Portmapper (111)
- Mount (635)
- NFS (2049)
- NLM (4045)
- NSM (4046)
- Rquota (4049)
NFSv3 kann Sicherheitsverbesserungen wie Kerberos verwenden, Kerberos wirkt sich jedoch nur auf den NFS-Teil der Pakete aus; Zusätzliche Protokolle (z. B. NLM, Portmapper, Mount) sind in der Kerberos-Unterhaltung nicht enthalten.
- Azure NetApp Files unterstützt nur NFSv4.1 Kerberos-Verschlüsselung
NFSv3 verwendet numerische IDs für die Benutzer- und Gruppenauthentifizierung. Benutzernamen und Gruppennamen sind nicht für die Kommunikation oder Berechtigungen erforderlich, was das Spoofing eines Benutzers vereinfachen kann, aber die Konfiguration und Verwaltung sind einfacher.
NFSv3 kann LDAP für Benutzer- und Gruppensuche verwenden.

Unterstützung der NFSv3-Dienstversion

NFSv3 unterstützt derzeit die folgenden Versionen jedes zusätzlichen Protokolls in Azure NetApp Files:

Dienst	Unterstützte Versionen
Portmapper	4, 3, 2
NFS	4, 3*
Montiert	3, 2, 1
Nlockmgr	4
Status	1
Rquotas	1

* NFS unterstützte Versionen werden basierend auf der für das Azure NetApp Files-Volume ausgewählten Version angezeigt.

Diese Informationen können mit dem folgenden Befehl aus Ihrem Azure NetApp Files-Volume gesammelt werden:

# rpcinfo -s <Azure NetApp Files IP address>

NFSv4.x

NFSv4.x bezieht sich auf alle NFS-Versionen oder Nebenversionen unter NFSv4, einschließlich NFSv4.0, NFSv4.1 und NFSv4.2. Azure NetApp Files unterstützt derzeit nur NFSv4.1.

NFSv4.x hat die folgenden Merkmale:

NFSv4.x ist ein zustandsbehaftetes Protokoll, was bedeutet, dass der Client und der Server die Zustände der NFS-Verbindungen nachverfolgen, einschließlich Sperrzuständen. Der NFS-Mount verwendet ein Konzept, das als "Status-ID" bezeichnet wird, um die Verbindungen nachzuverfolgen.
Die Sperre ist in das NFS-Protokoll integriert und erfordert keine zusätzlichen Sperrprotokolle, um NFS-Sperren nachzuverfolgen. Stattdessen werden Sperren auf Leasebasis gewährt. Sie laufen nach einer bestimmten Dauer ab, wenn eine Client- oder Serververbindung verloren geht, wodurch die Sperre wieder zum System für die Verwendung mit anderen NFS-Clients zurückgegeben wird.
Die Zustandsfähigkeit von NFSv4.x enthält einige Nachteile, z. B. potenzielle Unterbrechungen bei Netzwerkausfällen oder Speicherfailovern sowie Leistungsaufwand in bestimmten Workloadtypen (z. B. hohe Metadatenworkloads).
NFSv4.x bietet gegenüber NFSv3 viele erhebliche Vorteile, darunter:
- Bessere Sperrkonzepte (leasebasiertes Sperren)
- Bessere Sicherheit (weniger Firewallports erforderlich, Standardintegration mit Kerberos, granulare Zugriffssteuerungen)
- Weitere Features
- Zusammengesetzte NFS-Vorgänge (mehrere Befehle in einer einzigen Paketanforderung, um Netzwerkchatter zu reduzieren)
- Nur TCP
NFSv4.x kann ein robusteres Dateiberechtigungsmodell verwenden, das windows NTFS-Berechtigungen ähnelt. Diese granularen ACLs können auf Benutzer oder Gruppen angewendet werden und ermöglichen die Festlegung von Berechtigungen für einen breiteren Bereich von Vorgängen als grundlegende Lese-/Schreib-/Ausführungsvorgänge. NFSv4.x kann auch die standardmäßigen POSIX-Modusbits verwenden, die NFSv3 verwendet.
Da NFSv4.x keine zusätzlichen Protokolle verwendet, wird Kerberos bei Verwendung auf die gesamte NFS-Unterhaltung angewendet.
NFSv4.x verwendet eine Kombination aus Benutzer-/Gruppennamen und do Standard Zeichenfolgen, um Benutzer- und Gruppeninformationen zu überprüfen. Der Client und der Server müssen sich auf die Do Standard zeichenfolgen für die ordnungsgemäße Benutzer- und Gruppenauthentifizierung einigen. Wenn die do Standard zeichenfolgen nicht übereinstimmen, wird der NFS-Benutzer oder die GRUPPE squashen dem angegebenen Benutzer in der Datei "/etc/idmapd.conf" auf dem NFS-Client (z. B. niemand) squashen.
Während NFSv4.x standardmäßig do Standard zeichenfolgen verwendet, ist es möglich, den Client und den Server so zu konfigurieren, dass er auf die klassischen numerischen IDs zurückgreifen kann, die in NFSv3 angezeigt werden, wenn AUTH_SYS verwendet wird.
NFSv4.x verfügt über eine umfassende Integration in Benutzer- und Gruppennamenzeichenfolgen, und der Server und die Clients müssen sich auf diese Benutzer und Gruppen einigen. Erwägen Sie daher die Verwendung eines Namensdienstservers für die Benutzerauthentifizierung wie LDAP auf NFS-Clients und -Servern.

Häufig gestellte Fragen zu NFS in Azure NetApp Files finden Sie in den Häufig gestellten Fragen zu Azure NetApp Files NFS.

Server Message Block (SMB)

SMB wird in erster Linie mit Windows-Clients für NAS-Funktionen verwendet. Es kann jedoch auch auf Linux-basierten Betriebssystemen wie AppleOS, RedHat usw. verwendet werden. Diese Bereitstellung erfolgt mithilfe einer Anwendung namens Samba. Azure NetApp Files verfügt über offizielle Unterstützung für SMB mit Windows und macOS. SMB/Samba auf Linux-Betriebssystemen kann mit Azure NetApp Files arbeiten, aber es gibt keinen offiziellen Support.

Azure NetApp Files unterstützt nur SMB 2.1- und SMB 3.1-Versionen.

SMB weist die folgenden Merkmale auf:

SMB ist ein zustandsbehaftetes Protokoll: Clients und Server Standard einen "Zustand" für SMB-Freigabeverbindungen für bessere Sicherheit und Sperrung enthalten.
Das Sperren in SMB gilt als obligatorisch. Wenn eine Datei gesperrt ist, kann kein anderer Client in diese Datei schreiben, bis die Sperre freigegeben wurde.
SMBv2.x und höher verwenden zusammengesetzte Aufrufe zum Ausführen von Vorgängen.
SMB unterstützt die vollständige Kerberos-Integration. Mit der Konfiguration von Windows-Clients wird Kerberos häufig verwendet, ohne dass Endbenutzer jemals wissen.
Wenn Kerberos nicht für die Authentifizierung verwendet werden kann, kann Windows NT LAN Manager (NTLM) als Fallback verwendet werden. Wenn NTLM in der Active Directory-Umgebung deaktiviert ist, schlagen Authentifizierungsanforderungen, die Kerberos nicht verwenden können, fehl.
SMBv3.0 und höher unterstützen die End-to-End-Verschlüsselung für SMB-Freigaben.
SMBv3.x unterstützt Multichannel für Leistungssteigerungen in bestimmten Workloads.
SMB verwendet Benutzer- und Gruppennamen (über SID-Übersetzung) für die Authentifizierung. Benutzer- und Gruppeninformationen werden von einem Active Directory-Do Standard controller bereitgestellt.
SMB in Azure NetApp Files verwendet standardmäßige WINDOWS New Technology File System (NTFS) -ACLs für Datei- und Ordnerberechtigungen.

Häufig gestellte Fragen zu SMB in Azure NetApp Files finden Sie in den häufig gestellten Fragen zu Azure NetApp Files SMB.

Duale Protokolle

Einige Organisationen verfügen über reine Windows- oder reine UNIX-Umgebungen (homogen), in denen auf alle Daten nur eine der folgenden Ansätze zugegriffen wird:

SMB- und NTFS-Dateisicherheit
NFS und UNIX Dateisicherheit – Modusbits oder NFSv4.x Zugriffssteuerungslisten (ACLs)

Viele Websites müssen jedoch den Zugriff auf Datensätze sowohl von Windows- als auch UNIX-Clients (heterogen) ermöglichen. Für Umgebungen mit diesen Anforderungen verfügt Azure NetApp Files über systemeigene Dualprotokoll-NAS-Unterstützung. Nachdem der Benutzer im Netzwerk authentifiziert wurde und sowohl über entsprechende Freigabe- oder Exportberechtigungen als auch über die erforderlichen Berechtigungen auf Dateiebene verfügt, kann der Benutzer mithilfe von NFS oder von Windows-Hosts mit SMB auf die Daten von UNIX-Hosts zugreifen.

Gründe für die Verwendung von Dualprotokollvolumes

Die Verwendung von Dualprotokollvolumes mit Azure NetApp Files bietet verschiedene Vorteile. Wenn Datensätze nahtlos und gleichzeitig von Clients mit unterschiedlichen NAS-Protokollen aufgerufen werden können, können die folgenden Vorteile erzielt werden:

Reduzieren Sie die allgemeinen Verwaltungsaufgaben des Speicheradministrators.
Es muss nur eine einzelne Kopie von Daten für den NAS-Zugriff von mehreren Clienttypen gespeichert werden.
Mit protokollagnostischen NAS können Speicheradministratoren den Stil der ACL und die Zugriffssteuerung steuern, die Endbenutzern präsentiert werden.
Zentrale Identitätsverwaltungsvorgänge in einer NAS-Umgebung.

Häufige Überlegungen bei Umgebungen mit dualen Protokollen

Der Nas-Zugriff mit dualen Protokollen ist von vielen Organisationen für seine Flexibilität wünschenswert. Es gibt jedoch eine Vorstellung von Schwierigkeiten, die eine Reihe von Überlegungen schafft, die für das Konzept der gemeinsamen Nutzung über Protokolle hinweg einzigartig sind. Diese Überlegungen umfassen, sind jedoch nicht beschränkt auf:

Anforderung von Wissen über mehrere Protokolle, Betriebssysteme und Speichersysteme hinweg.
Kenntnisse von Namendienstservern, z. B. DNS, LDAP usw.

Darüber hinaus können externe Faktoren ins Spiel kommen, z. B.:

Umgang mit mehreren Abteilungen und IT-Gruppen (z. B. Windows-Gruppen und UNIX-Gruppen)
Unternehmenskäufe
Do Standard Konsolidierungen
Sanierungen

Trotz dieser Überlegungen kann das Dual-Protocol NAS-Setup, die Konfiguration und der Zugriff einfach und nahtlos in jede Beliebige Umgebung integriert werden.

So vereinfacht Azure NetApp Files die Verwendung von dualen Protokollen

Azure NetApp Files konsolidiert die Infrastruktur, die für erfolgreiche NAS-Umgebungen mit dualem Protokoll erforderlich ist, in einer einzigen Verwaltungsebene, einschließlich Speicher- und Identitätsverwaltungsdienste.

Dual-Protocol-Konfiguration ist einfach, und die meisten Aufgaben werden vom Azure NetApp Files-Ressourcenverwaltungsframework abgeschirmt, um Vorgänge für Cloudoperatoren zu vereinfachen.

Nachdem eine Active Directory-Verbindung mit Azure NetApp Files hergestellt wurde, können Dual-Protocol-Volumes die Verbindung verwenden, um sowohl die Windows- als auch die UNIX-Identitätsverwaltung zu verarbeiten, die für die ordnungsgemäße Benutzer- und Gruppenauthentifizierung mit Azure NetApp Files-Volumes ohne zusätzliche Konfigurationsschritte außerhalb der normalen Benutzer- und Gruppenverwaltung innerhalb der Active Directory- oder LDAP-Dienste erforderlich ist.

Durch das Entfernen der zusätzlichen speicherorientierten Schritte für Konfigurationen mit dualen Protokollen optimiert Azure NetApp Files die allgemeine Dualprotokollbereitstellung für Organisationen, die nach Azure wechseln möchten.

Funktionsweise von Azure NetApp Files mit dualen Protokollvolumes

Auf hoher Ebene verwenden Azure NetApp Files Dual-Protocol-Volumes eine Kombination aus Namenszuordnung und Berechtigungsstilen, um einen konsistenten Datenzugriff unabhängig vom verwendeten Protokoll bereitzustellen. Das bedeutet, ob Sie von NFS oder SMB auf eine Datei zugreifen, können Sie sicher sein, dass Benutzer mit Zugriff auf diese Dateien darauf zugreifen können, und Benutzer ohne Zugriff auf diese Dateien nicht darauf zugreifen können.

Wenn ein NAS-Client den Zugriff auf ein Dual-Protocol-Volume in Azure NetApp Files anfordert, treten die folgenden Vorgänge auf, um dem Endbenutzer eine transparente Benutzeroberfläche zu bieten.

Ein NAS-Client stellt eine NAS-Verbindung mit dem Dual-Protocol-Volume von Azure NetApp Files dar.
Der NAS-Client übergibt Benutzeridentitätsinformationen an Azure NetApp Files.
Azure NetApp Files überprüft, um sicherzustellen, dass der NAS-Client/benutzer Zugriff auf die NAS-Freigabe hat.
Azure NetApp Files verwendet diesen Benutzer und ordnet ihn einem gültigen Benutzer zu, der in Namensdiensten gefunden wurde.
Azure NetApp Files vergleicht diesen Benutzer mit den Berechtigungen auf Dateiebene im System.
Dateiberechtigungen steuern die Zugriffsebene des Benutzers.

In der folgenden Abbildung user1 authentifiziert sich Azure NetApp Files für den Zugriff auf ein duales Protokollvolume über SMB oder NFS. Azure NetApp Files findet die Windows- und UNIX-Informationen des Benutzers in der Microsoft Entra-ID und ordnet dann die Windows- und UNIX-Identitäten des Benutzers 1:1 zu. Der Benutzer wird überprüft und user1 erhält user1die Zugriffsanmeldeinformationen.

In diesem Fall user1 erhält er vollzugriff auf seinen eigenen Ordner (user1-dir) und keinen Zugriff auf den HR Ordner. Diese Einstellung basiert auf den im Dateisystem angegebenen Sicherheits-ACLs und user1 erhält den erwarteten Zugriff, unabhängig davon, von welchem Protokoll sie auf die Volumes zugreifen.

Überlegungen für Azure NetApp Files Dual-Protocol-Volumes

Wenn Sie Azure NetApp Files-Volumes für den Zugriff auf SMB und NFS verwenden, gelten einige Überlegungen:

Sie benötigen eine Active Directory-Verbindung. Daher müssen Sie die Anforderungen für Active Directory-Verbindungen erfüllen.
Dual-Protocol-Volumes erfordern eine Reverse-Lookupzone in DNS mit einem zugeordneten PTR-Eintrag (Pointer) des AD-Hostcomputers, um Fehler beim Erstellen von Dualprotokollvolumes zu verhindern.
Ihr NFS-Client und zugehörige Pakete (z nfs-utils. B. ) sollten auf dem neuesten Stand sein, um die beste Sicherheits-, Zuverlässigkeits- und Featureunterstützung zu erhalten.
Dual-Protocol-Volumes unterstützen sowohl Active Directory-Domäne Services (AD DS) als auch Microsoft Entra Do Standard Services.
Dual-Protocol-Volumes unterstützen die Verwendung von LDAP über TLS mit Microsoft Entra Do Standard Services nicht. Weitere Informationen finden Sie unter Überlegungen zu LDAP über TLS.
Unterstützte NFS-Versionen sind: NFSv3 und NFSv4.1.
NFSv4.1-Features wie paralleles Netzwerkdateisystem (pNFS), Sitzungstrunking und Empfehlungen werden derzeit nicht mit Azure NetApp Files-Volumes unterstützt.
Erweiterte Windows-Attribute set/get werden in Dualprotokollvolumes nicht unterstützt.
Weitere Überlegungen zum Erstellen eines Dualprotokollvolumes für Azure NetApp Files finden Sie in weiteren Überlegungen.