Interoperabilität und Grenzen
Änderungen vorschlagen
PDFs
NFS over TLS ist mit den standardmäßigen ONTAP Export-Policy-Kontrollen kompatibel, wird über SVM-DR und MetroCluster repliziert und weist einige wenige harte Plattformbeschränkungen sowie Betriebsempfehlungen auf, die vor der Bereitstellung bekannt sein sollten.
Interoperabilität
Unterstützte koexistierende Funktionen
Exportrichtlinien, Qtree-Exporte und Verbindungspfade. Die Exportrichtlinienregel erhält das -allow-nfs-tls-only Feld, das TLS regelbasiert vorschreiben kann. Sie wird mit bestehenden Sicherheitskontrollen wie Client-Match, Protokoll, Lese-/Schreibzugriff, Superuser, Anonymität, Chown-Modus, Allow-SUID und NTFS-UNIX kombiniert. Qtree-Exporte und Verbindungspfad-Mounts erben die TLS-Anforderung über denselben Exportrichtlinienmechanismus. System Manager zeigt die -allow-nfs-tls-only Einstellung in der NFS-Zugriffsauswahl an.
Die NFS-over-TLS-Replikation und die DR-Unterstützung sind in der folgenden Tabelle zusammengefasst. Hintergrundinformationen zum Replikationsmechanismus finden sich unter "Architektur".
| Replikation / DR | NFS über TLS in Version 9.19.1 |
|---|---|
SVM-DR |
Unterstützt. Die TLS-Schnittstellenzeile wird auf SVM-Ebene repliziert (Status, Zertifikatsname und UUID, enforce-host-auth). Das `-allow-nfs-tls-only`export-rule Feld wird mit der Exportrichtlinie repliziert. |
MetroCluster (Replikation auf SVM-Ebene) |
Unterstützt. Gleicher Replikationspfad wie SVM-DR. Der Lebenszyklus des Zertifikatsmaterials auf der Ziel-SVM liegt beim Zertifikatsmanager. |
SnapMirror (Volumenreplikation) |
Unterstützt. Orthogonal zum Client-seitigen TLS-Transport. |
Cloud-gehostete ONTAP Varianten |
Nicht unterstützt in 9.19.1. |
Funktionen mit Einschränkungen
Client-Anforderungen. Der NFS-Client muss TLS für ONC RPC gemäß "RFC 9289" implementieren. Unter Linux wird dies durch einen im Kernel integrierten NFS-Client bereitgestellt, der die xprtsec=tls (oder xprtsec=mtls) Mount-Option unterstützt und in Kombination mit dem Userspace-TLS-Handschlag-Helfer tlshd aus dem ktls-utils Paket verwendet wird. Die vollständige Client-Matrix, einschließlich minimaler Kernel-Versionen, Userspace-Paketversionen und unterstützter Linux-Distributionen, ist im Interoperability Matrix Tool (IMT) zu finden.
Einschränkungen und Vorbehalte
-
Cloud-hosted ONTAP Varianten. Cloud Volumes ONTAP und andere Cloud-hosted ONTAP Varianten werden unter ONTAP 9.19.1 nicht unterstützt.
-
NFS über Remote Direct Memory Access (RDMA). NFS über RDMA und NFS über TLS schließen sich auf demselben LIF gegenseitig aus.
Grenzwerte pro Knoten
|
Derzeit gibt es keine fest codierten Verbindungsgrenzen für NFS-over-TLS in ONTAP. Aktuelle Informationen zu den unterstützten Grenzwerten finden sich unter "Hardware Universe". |
BESTE VORGEHENSWEISE: Die Anzahl der NFS-over-TLS-Verbindungen pro Knoten sollte unter 10.000 liegen, damit ausreichend Spielraum für Mount-Stürme und HA-Übernahmen bleibt.
Cluster-spezifische Beschränkungen
Es gibt keine separate clusterweite Obergrenze, die im Code durchgesetzt wird.
Grenzwerte pro LIF und pro Objekt
-
Die Konfigurationstabelle ist über das
(SVM, LIF)Tupel indiziert. Jede LIF enthält entweder null oder eine NFS-over-TLS Konfigurationszeile. -
Genau ein Serverzertifikat wird pro NFS-over-TLS-fähigem LIF gebunden. Das Zertifikat wird zum
vserver nfs tls interface enable`Zeitpunkt angegeben und kann mit `… modify -certificate-namegeändert werden. -
-allow-nfs-tls-onlyist ein einzelner boolescher Wert pro Export-Policy-Regel. Diese Funktion fügt keine separate Obergrenze für die Regelanzahl hinzu, die standardmäßigen Maximalwerte pro Policy und pro SVM für Export-Regeln gelten.
Durchsetzungsverhalten
`-allow-nfs-tls-only true`Durchsetzung. Wenn dieses Feld `true`in einer übereinstimmenden Exportrichtlinienregel enthalten ist, werden NFS-Verbindungsversuche von übereinstimmenden Clients, die TLS für ONC RPC gemäß RFC 9289 nicht verwenden, bei der Auswertung der Exportrichtlinie abgelehnt. Bestehende TLS-Verbindungen dieser Clients sind davon nicht betroffen.
-enforce-host-auth true-Durchsetzung. Wenn true auf einem (SVM, LIF) TLS-Handschläge, deren Clientzertifikatsidentität nicht mit der konfigurierten Hostidentität für die LIF übereinstimmt, werden diese während des TLS-Handschlags abgelehnt. Das EMS-Ereignis Nblade.TLSHandshakeFailed (Schweregrad ERR, auf eine Meldung pro 10 Minuten und Ereignisquelle begrenzt) wird für jeden fehlgeschlagenen Handschlag ausgegeben.
EMS-Ratenbegrenzungen.
Nblade.TLSConfigError und Nblade.TLSHandshakeFailed sind auf einmal alle 10 Minuten pro Ereignisquelle begrenzt. Nblade.NfsTlsDisabled ist auf einmal alle 24 Stunden pro Ereignisquelle begrenzt. Dies sind beabsichtigte Obergrenzen für das Ereignisprotokollvolumen bei kontinuierlichen Fehlerbedingungen. Während eines Bursts wird nur das erste Ereignis innerhalb jedes Ratenbegrenzungsfensters protokolliert.
Weiche Grenzen und Empfehlungen
Die folgenden Angaben sind Empfehlungen, keine strikten Maximalwerte.
-
Die Anzahl der NFS-over-TLS-Verbindungen pro Knoten sollte unter 10.000 gehalten werden. Es gibt keine fest codierte Obergrenze, jedoch sollte die Anzahl der NFS-over-TLS-Verbindungen pro Knoten bei oder unter 10.000 liegen.
-
Nach der HA-Übernahme ist ein vollständiger TLS-Re-Handschlag einzuplanen. TLS-Sitzungen sind auf TCP beschränkt und überstehen eine Übernahme nicht. Jeder Client stellt auf dem verbleibenden oder Zielknoten eine neue TLS 1.3-Handshake-Verbindung her, sodass mit einem Mount-Sturm zu rechnen ist. Wenn die Anzahl der Verbindungen deutlich unter 10.000 gehalten wird, bleibt ausreichend Spielraum, um diesen Anstieg aufzufangen.