Storage Virtual Machines (SVMs) bieten Isolation und administrative Trennung zwischen Mandanten auf einem ONTAP System. Die Zuweisung einer SVM zu Anwendungen ermöglicht die Delegation von Berechtigungen und die Anwendung bewährter Verfahren zur Begrenzung des Ressourcenverbrauchs.

Für die Verwaltung der SVM stehen mehrere Optionen zur Verfügung:

In jedem Fall sollte die Schnittstelle im DNS hinterlegt sein, und der DNS-Name sollte bei der Konfiguration von Trident verwendet werden. Dies erleichtert bestimmte DR-Szenarien, beispielsweise SVM-DR ohne Verwendung der Netzwerkidentitätsbeibehaltung.

Es gibt keine Präferenz zwischen einem dedizierten oder einem gemeinsam genutzten Management-LIF für die SVM. Sie sollten jedoch sicherstellen, dass Ihre Netzwerksicherheitsrichtlinien mit dem von Ihnen gewählten Ansatz übereinstimmen. Ungeachtet dessen sollte die Management-LIF über DNS zugänglich sein, um maximale Flexibilität zu gewährleisten. "SVM-DR" wird in Verbindung mit Trident verwendet.

ONTAP Speichersysteme haben eine maximale Anzahl an Volumes, die je nach Softwareversion und Hardwareplattform variiert. Siehe "NetApp Hardware Universe" Die genauen Grenzwerte hängen von Ihrer spezifischen Plattform und ONTAP Version ab. Wenn die maximale Speicherkapazität erreicht ist, schlagen Bereitstellungsvorgänge nicht nur für Trident, sondern für alle Speicheranforderungen fehl.

Tridents ontap-nas Und ontap-san Treiber stellen für jedes erstellte Kubernetes Persistent Volume (PV) ein FlexVolume bereit. Der ontap-nas-economy Der Treiber erzeugt ungefähr ein FlexVolume pro 200 PVs (konfigurierbar zwischen 50 und 300). Der ontap-san-economy Der Treiber erzeugt ungefähr ein FlexVolume pro 100 PVs (konfigurierbar zwischen 50 und 200). Um zu verhindern, dass Trident alle verfügbaren Volumes auf dem Speichersystem verbraucht, sollten Sie ein Limit für die SVM festlegen. Sie können dies über die Befehlszeile tun:

Der Wert für max-volumes variiert je nach verschiedenen Kriterien, die für Ihre Umgebung spezifisch sind:

Der max-volumes Der Wert bezieht sich auf die Gesamtmenge der auf allen Knoten im ONTAP Cluster bereitgestellten Daten und nicht auf einen einzelnen ONTAP Knoten. Infolgedessen können Bedingungen auftreten, bei denen ein ONTAP Clusterknoten über weitaus mehr oder weniger von Trident bereitgestellte Volumes verfügt als ein anderer Knoten.

Ein ONTAP -Cluster mit zwei Knoten kann beispielsweise maximal 2000 FlexVol Volumes hosten. Die Festlegung der maximalen Lautstärkeanzahl auf 1250 erscheint sehr sinnvoll. Wenn jedoch nur "Aggregate" Wenn von einem Knoten Daten dem SVM zugewiesen werden oder die von einem Knoten zugewiesenen Aggregate nicht bereitgestellt werden können (z. B. aufgrund von Kapazitätsengpässen), wird der andere Knoten zum Ziel für alle von Trident bereitgestellten Volumes. Dies bedeutet, dass die Volumenbegrenzung für diesen Knoten möglicherweise erreicht wird, bevor max-volumes Dieser Wert wird erreicht, was sich sowohl auf Trident als auch auf andere Volumenoperationen auswirkt, die diesen Knoten verwenden. Diese Situation lässt sich vermeiden, indem sichergestellt wird, dass die Aggregate von jedem Knoten im Cluster dem von Trident verwendeten SVM in gleicher Anzahl zugewiesen werden.

NetApp Trident unterstützt das Klonen von Volumes bei Verwendung von ontap-nas , ontap-san , solidfire-san , Und gcp-cvs Speichertreiber. Bei der Verwendung des ontap-nas-flexgroup oder ontap-nas-economy Treiber, Klonen wird nicht unterstützt. Wenn aus einem bestehenden Volume ein neues Volume erstellt wird, wird ein neuer Snapshot erstellt.

Um die maximale Größe für von Trident erstellbare Volumes zu konfigurieren, verwenden Sie die limitVolumeSize Parameter in Ihrem backend.json Definition.

Zusätzlich zur Steuerung der Volumegröße im Speicherarray sollten Sie auch die Kubernetes-Funktionen nutzen.

Um die maximale Größe für FlexVols zu konfigurieren, die als Pools für die Treiber ontap-san-economy und ontap-nas-economy verwendet werden, verwenden Sie die limitVolumePoolSize Parameter in Ihrem backend.json Definition.

Sie können die Benutzernamen und Passwörter für CHAP-Initiator und -Ziel in Ihrer Backend-Definition angeben und Trident veranlassen, CHAP auf der SVM zu aktivieren. Verwenden des useCHAP Parameter in Ihrer Backend-Konfiguration, Trident authentifiziert iSCSI-Verbindungen für ONTAP -Backends mit CHAP.

Durch die Nutzung einer ONTAP QoS-Richtlinie, die auf die SVM angewendet wird, wird die Anzahl der von den bereitgestellten Trident -Volumes verbrauchbaren IOPS begrenzt. Dies hilft dabei "Mobbing verhindern" oder dass ein außer Kontrolle geratener Container Arbeitslasten außerhalb der Trident SVM beeinträchtigt.

Sie können in wenigen Schritten eine QoS-Richtlinie für die SVM erstellen. Die genauesten Informationen finden Sie in der Dokumentation zu Ihrer ONTAP -Version. Das folgende Beispiel erstellt eine QoS-Richtlinie, die die insgesamt für die SVM verfügbaren IOPS auf 5000 begrenzt.

Zusätzlich können Sie, sofern Ihre ONTAP -Version dies unterstützt, die Verwendung eines QoS-Minimums in Betracht ziehen, um einen gewissen Durchsatz für containerisierte Workloads zu garantieren. Adaptives QoS ist nicht mit einer SVM-Richtlinie kompatibel.

Die Anzahl der für die containerisierten Workloads reservierten IOPS hängt von vielen Aspekten ab. Dazu gehören unter anderem:

Wichtig ist zu beachten, dass eine auf SVM-Ebene zugewiesene QoS-Richtlinie dazu führt, dass alle der SVM bereitgestellten Volumes denselben IOPS-Pool nutzen. Wenn eine oder wenige der containerisierten Anwendungen einen hohen IOPS-Bedarf haben, könnte dies zu einer Belastung für die anderen containerisierten Workloads führen. In diesem Fall sollten Sie erwägen, externe Automatisierung zur Zuweisung von QoS-Richtlinien pro Volume zu verwenden.

Die Dienstgüte (QoS) gewährleistet, dass die Leistung kritischer Arbeitslasten nicht durch konkurrierende Arbeitslasten beeinträchtigt wird. ONTAP QoS-Richtliniengruppen bieten QoS-Optionen für Volumes und ermöglichen es Benutzern, die Durchsatzobergrenze für eine oder mehrere Workloads zu definieren. Weitere Informationen zu QoS finden Sie unter "Gewährleistung des Durchsatzes mit QoS" . Sie können QoS-Richtliniengruppen im Backend oder in einem Speicherpool festlegen, und diese werden auf jedes in diesem Pool oder Backend erstellte Volume angewendet.

ONTAP kennt zwei Arten von QoS-Richtliniengruppen: traditionelle und adaptive. Traditionelle Richtliniengruppen bieten einen festen maximalen (bzw. minimalen, in späteren Versionen) Durchsatz in IOPS. Adaptive QoS skaliert den Durchsatz automatisch an die Workload-Größe und hält dabei das Verhältnis von IOPS zu TBs|GBs aufrecht, während sich die Größe der Workload ändert. Dies bietet einen erheblichen Vorteil, wenn Sie Hunderte oder Tausende von Workloads in einer großen Bereitstellung verwalten.

Beachten Sie Folgendes beim Erstellen von QoS-Richtliniengruppen:

Weitere Informationen zu QoS-Richtliniengruppen finden Sie unter "ONTAP Befehlsreferenz" .

Die Beschränkung des Zugriffs auf die von Trident erstellten NFS-Volumes, iSCSI-LUNs und FC-LUNs ist ein entscheidender Bestandteil der Sicherheitsarchitektur Ihrer Kubernetes-Bereitstellung. Dadurch wird verhindert, dass Hosts, die nicht Teil des Kubernetes-Clusters sind, auf die Volumes zugreifen und möglicherweise Daten unerwartet ändern.

Es ist wichtig zu verstehen, dass Namespaces die logische Grenze für Ressourcen in Kubernetes sind. Die Annahme ist, dass Ressourcen im selben Namensraum gemeinsam genutzt werden können; wichtig ist jedoch, dass es keine Möglichkeit zur Nutzung über verschiedene Namensräume hinweg gibt. Dies bedeutet, dass PVs zwar globale Objekte sind, aber wenn sie an ein PVC gebunden sind, nur von Pods im selben Namespace zugänglich sind. Es ist von entscheidender Bedeutung, sicherzustellen, dass Namensräume gegebenenfalls zur Trennung verwendet werden.

Die größte Sorge der meisten Organisationen hinsichtlich der Datensicherheit im Kubernetes-Kontext besteht darin, dass ein Prozess in einem Container auf Speicher zugreifen kann, der auf dem Host eingebunden ist, aber nicht für den Container bestimmt ist. "Namensräume" sind so konzipiert, dass diese Art von Kompromiss verhindert wird. Es gibt jedoch eine Ausnahme: privilegierte Container.

Ein privilegierter Container ist ein Container, der mit wesentlich mehr Berechtigungen auf Hostebene als üblich ausgeführt wird. Diese werden nicht standardmäßig deaktiviert. Stellen Sie daher sicher, dass Sie die entsprechende Funktion deaktivieren. "Pod-Sicherheitsrichtlinien" .

Bei Volumes, auf die sowohl von Kubernetes als auch von externen Hosts zugegriffen werden soll, sollte der Speicher auf traditionelle Weise verwaltet werden, wobei das PV vom Administrator eingeführt und nicht von Trident verwaltet wird. Dadurch wird sichergestellt, dass das Speichervolume erst dann zerstört wird, wenn sowohl Kubernetes als auch externe Hosts die Verbindung getrennt haben und das Volume nicht mehr verwenden. Zusätzlich kann eine benutzerdefinierte Exportrichtlinie angewendet werden, die den Zugriff von den Kubernetes-Clusterknoten und von Zielservern außerhalb des Kubernetes-Clusters ermöglicht.

Bei Bereitstellungen mit dedizierten Infrastrukturknoten (z. B. OpenShift) oder anderen Knoten, die keine Benutzeranwendungen einplanen können, sollten separate Exportrichtlinien verwendet werden, um den Zugriff auf Speicherressourcen weiter einzuschränken. Dazu gehört das Erstellen einer Exportrichtlinie für Dienste, die auf diesen Infrastrukturknoten bereitgestellt werden (z. B. die OpenShift-Dienste „Metrics“ und „Logging“), und für Standardanwendungen, die auf Nicht-Infrastrukturknoten bereitgestellt werden.

Sie sollten sicherstellen, dass für jedes Backend eine Exportrichtlinie existiert, die nur den Zugriff auf die im Kubernetes-Cluster vorhandenen Knoten erlaubt. Trident kann Exportrichtlinien automatisch erstellen und verwalten. Auf diese Weise beschränkt Trident den Zugriff auf die Volumes, die es den Knoten im Kubernetes-Cluster bereitstellt, und vereinfacht das Hinzufügen/Löschen von Knoten.

Alternativ können Sie auch manuell eine Exportrichtlinie erstellen und diese mit einer oder mehreren Exportregeln füllen, die jede Knotenzugriffsanfrage verarbeiten:

Durch Ausführen dieser Befehle können Sie einschränken, welche Kubernetes-Knoten Zugriff auf die Daten haben.

Der showmount Diese Funktion ermöglicht es einem NFS-Client, die SVM nach einer Liste der verfügbaren NFS-Exporte abzufragen. Ein im Kubernetes-Cluster bereitgestellter Pod kann die folgende Aktion ausführen: showmount -e Mit dem Befehl get erhalten Sie eine Liste der verfügbaren Mounts, einschließlich derer, auf die es keinen Zugriff hat. Dies stellt zwar für sich genommen keine Sicherheitslücke dar, liefert aber unnötige Informationen, die einem nicht autorisierten Benutzer möglicherweise dabei helfen, eine Verbindung zu einem NFS-Export herzustellen.

Sie sollten deaktivieren showmount durch Verwendung des ONTAP CLI-Befehls auf SVM-Ebene:

Jedes SolidFire -Konto repräsentiert einen eindeutigen Volume-Inhaber und erhält seine eigenen CHAP-Anmeldeinformationen (Challenge-Handshake Authentication Protocol). Sie können auf einem Konto zugewiesene Datenträger entweder über den Kontonamen und die zugehörigen CHAP-Anmeldeinformationen oder über eine Datenträgerzugriffsgruppe zugreifen. Einem Konto können bis zu zweitausend Volumes zugeordnet werden, aber ein Volume kann nur zu einem Konto gehören.

Verwenden Sie SolidFire Quality of Service (QoS)-Richtlinien, wenn Sie eine standardisierte Servicequalitätseinstellung erstellen und speichern möchten, die auf viele Volumes angewendet werden kann.

Sie können QoS-Parameter pro Volume festlegen. Die Leistungsfähigkeit jedes Volumes kann durch die Festlegung von drei konfigurierbaren Parametern, die die QoS definieren, sichergestellt werden: Min IOPS, Max IOPS und Burst IOPS.

Hier sind die möglichen Minimal-, Maximal- und Burst-IOPS-Werte für die 4-Kb-Blockgröße.

Blockgröße und Bandbreite haben einen direkten Einfluss auf die Anzahl der IOPS. Mit zunehmender Blockgröße erhöht das System die Bandbreite auf ein Niveau, das zur Verarbeitung der größeren Blockgrößen erforderlich ist. Mit zunehmender Bandbreite sinkt die Anzahl der IOPS, die das System erreichen kann. Siehe "SolidFire Servicequalität" Für weitere Informationen zu QoS und Leistung.

Element unterstützt zwei Authentifizierungsmethoden: CHAP und Volume Access Groups (VAG). CHAP verwendet das CHAP-Protokoll zur Authentifizierung des Hosts gegenüber dem Backend. Volume Access Groups steuert den Zugriff auf die von ihnen bereitgestellten Volumes. NetApp empfiehlt die Verwendung von CHAP zur Authentifizierung, da es einfacher ist und keine Skalierungsbeschränkungen aufweist.

Die CHAP-Authentifizierung (Überprüfung, ob der Initiator der beabsichtigte Volumennutzer ist) wird nur bei kontobasierter Zugriffskontrolle unterstützt. Wenn Sie CHAP zur Authentifizierung verwenden, stehen Ihnen zwei Optionen zur Verfügung: unidirektionales CHAP und bidirektionales CHAP. Unidirektionales CHAP authentifiziert den Zugriff auf das Volume mithilfe des SolidFire -Kontonamens und des Initiator-Geheimnisses. Die bidirektionale CHAP-Option bietet die sicherste Methode zur Authentifizierung des Volumes, da das Volume den Host über den Kontonamen und das Initiator-Geheimnis authentifiziert und der Host anschließend das Volume über den Kontonamen und das Ziel-Geheimnis authentifiziert.

Wenn CHAP jedoch nicht aktiviert werden kann und VAGs erforderlich sind, erstellen Sie die Zugriffsgruppe und fügen Sie die Hostinitiatoren und Volumes der Zugriffsgruppe hinzu. Jeder IQN, den Sie einer Zugriffsgruppe hinzufügen, kann mit oder ohne CHAP-Authentifizierung auf jedes Volume in der Gruppe zugreifen. Wenn der iSCSI-Initiator für die Verwendung der CHAP-Authentifizierung konfiguriert ist, wird eine kontobasierte Zugriffskontrolle verwendet. Wenn der iSCSI-Initiator nicht für die Verwendung der CHAP-Authentifizierung konfiguriert ist, wird die Zugriffskontrolle über Volume Access Groups (VAG) verwendet.