ONTAP-Backend-Treiber unterscheiden sich durch das verwendete Protokoll und die Art, wie die Volumes auf dem Speichersystem bereitgestellt werden. Daher sollten Sie sorgfältig überlegen, welchen Treiber Sie einsetzen.

Auf einer höheren Ebene gilt: Wenn Ihre Anwendung Komponenten enthält, die gemeinsam genutzten Speicher benötigen (mehrere Pods greifen auf dieselbe PVC zu), sind NAS-basierte Treiber die Standardwahl, während die blockbasierten iSCSI-Treiber den Bedarf an nicht gemeinsam genutztem Speicher abdecken. Wählen Sie das Protokoll basierend auf den Anforderungen der Anwendung und dem Erfahrungsstand der Speicher- und Infrastrukturteams. Allgemein gesprochen gibt es für die meisten Anwendungen kaum Unterschiede zwischen ihnen, sodass die Entscheidung oft davon abhängt, ob gemeinsam genutzter Speicher (bei dem mehr als ein Pod gleichzeitig Zugriff benötigt) erforderlich ist oder nicht.

Die verfügbaren ONTAP Backend-Treiber sind:

Die Wahl zwischen den drei NAS-Treibern hat einige Auswirkungen auf die Funktionen, die der Anwendung zur Verfügung gestellt werden.

Beachten Sie, dass in den folgenden Tabellen nicht alle Funktionen über Trident verfügbar sind. Einige müssen vom Speicheradministrator nach der Bereitstellung angewendet werden, falls diese Funktionalität gewünscht ist. Die hochgestellten Fußnoten kennzeichnen die Funktionalität pro Feature und Treiber.

Trident bietet 2 SAN-Treiber für ONTAP, deren Fähigkeiten unten gezeigt werden.

Die Merkmale, die nicht PV-granular sind, werden auf das gesamte FlexVolume angewendet, und alle PVs (d. h. qtrees oder LUNs in gemeinsamen FlexVols) teilen sich einen gemeinsamen Zeitplan.

Wie wir in den obigen Tabellen sehen können, ist vieles der Funktionalität zwischen dem ontap-nas und dem ontap-nas-economy gleich. Da jedoch der ontap-nas-economy Treiber die Möglichkeit einschränkt, den Zeitplan auf PV-Granularität zu steuern, kann dies insbesondere Ihre Notfallwiederherstellungs- und Backup-Planung beeinflussen. Für Entwicklungsteams, die die PVC-Klonfunktionalität auf ONTAP-Speicher nutzen möchten, ist dies nur möglich, wenn sie die ontap-nas, ontap-san oder ontap-san-economy Treiber verwenden.

Cloud Volumes ONTAP bietet Datenkontrolle zusammen mit Speicherfunktionen der Enterprise-Klasse für verschiedene Anwendungsfälle, einschließlich Dateifreigaben und Blockspeicher auf Blockebene für NAS- und SAN-Protokolle (NFS, SMB / CIFS und iSCSI). Die kompatiblen Treiber für Cloud Volume ONTAP sind ontap-nas, ontap-nas-economy, ontap-san und ontap-san-economy. Diese gelten für Cloud Volume ONTAP für Azure, Cloud Volume ONTAP für GCP.

Amazon FSx for NetApp ONTAP ermöglicht es Ihnen, NetApp-Funktionen, Leistung und Verwaltungsfunktionen zu nutzen, mit denen Sie vertraut sind, während Sie gleichzeitig von der Einfachheit, Agilität, Sicherheit und Skalierbarkeit der Datenspeicherung auf AWS profitieren. FSx for ONTAP unterstützt viele ONTAP-Dateisystemfunktionen und Verwaltungs-APIs. Die kompatiblen Treiber für Cloud Volume ONTAP sind ontap-nas, ontap-nas-economy, ontap-nas-flexgroup, ontap-san und ontap-san-economy.

Der solidfire-san Treiber, der mit den NetApp HCI/SolidFire Plattformen verwendet wird, hilft dem Administrator, ein Element-Backend für Trident auf Basis von QoS-Grenzwerten zu konfigurieren. Wenn Sie Ihr Backend so gestalten möchten, dass spezifische QoS-Grenzwerte für die von Trident bereitgestellten Volumes festgelegt werden, verwenden Sie den type Parameter in der Backend-Datei. Der Administrator kann außerdem die Volume-Größe, die auf dem Speicher erstellt werden kann, mit dem limitVolumeSize Parameter beschränken. Derzeit werden Element-Speicherfunktionen wie Volume-Resize und Volume-Replikation nicht über den solidfire-san Treiber unterstützt. Diese Vorgänge sollten manuell über die Element Software Web-Oberfläche durchgeführt werden.

Trident verwendet den azure-netapp-files-Treiber, um den "Azure NetApp Files"-Dienst zu verwalten.

Weitere Informationen zu diesem Treiber und wie Sie ihn konfigurieren können, finden Sie in "Trident Backend-Konfiguration für Azure NetApp Files".

Innerhalb eines bestimmten Speicherklassenobjekts kann mithilfe von Filtern festgelegt werden, welcher Speicherpool oder welche Speicherpools für diese bestimmte Speicherklasse verwendet werden sollen. Drei Filtergruppen können in der Speicherklasse festgelegt werden: storagePools, additionalStoragePools, und/oder excludeStoragePools.

Der storagePools Parameter hilft, den Speicher auf die Menge der Pools zu beschränken, die mit beliebigen angegebenen Attributen übereinstimmen. Der additionalStoragePools Parameter wird verwendet, um die Menge der Pools, die Trident für die Bereitstellung verwendet, zusammen mit der durch die Attribute und storagePools Parameter ausgewählten Menge von Pools zu erweitern. Sie können entweder einen der beiden Parameter allein oder beide zusammen verwenden, um sicherzustellen, dass die geeignete Menge an Speicherpools ausgewählt wird.

Der `excludeStoragePools`Parameter wird verwendet, um die aufgelistete Gruppe von Pools, die den Attributen entsprechen, gezielt auszuschließen.

Wenn Sie Storage Classes entwerfen möchten, um Quality of Service-Richtlinien zu emulieren, erstellen Sie eine Storage Class mit dem media Attribut als hdd oder ssd. Basierend auf dem media Attribut, das in der Storage Class angegeben ist, wählt Trident das passende Backend aus, das hdd oder ssd Aggregate bereitstellt, um das Media-Attribut abzugleichen, und leitet dann die Bereitstellung der Volumes auf das spezifische Aggregat weiter. Daher können wir eine Storage Class PREMIUM erstellen, bei der das media Attribut als ssd gesetzt ist, was als PREMIUM QoS-Richtlinie klassifiziert werden kann. Wir können eine weitere Storage Class STANDARD erstellen, bei der das Media-Attribut auf hdd gesetzt ist, was als STANDARD QoS-Richtlinie klassifiziert werden kann. Wir könnten auch das ``IOPS'' Attribut in der Storage Class verwenden, um die Bereitstellung auf ein Element Appliance umzuleiten, das als QoS-Richtlinie definiert werden kann.

Speicherklassen können so konzipiert werden, dass sie die Volume-Bereitstellung auf einem bestimmten Backend steuern, auf dem Funktionen wie Thin und Thick Provisioning, Snapshots, Klone und Verschlüsselung aktiviert sind. Um festzulegen, welcher Speicher verwendet werden soll, erstellen Sie Speicherklassen, die das entsprechende Backend mit der erforderlichen aktivierten Funktion angeben.

Virtuelle Pools sind für alle Trident Backends verfügbar. Sie können virtuelle Pools für jedes Backend definieren, wobei Sie jeden von Trident bereitgestellten Treiber verwenden können.

Virtuelle Pools ermöglichen es einem Administrator, eine Abstraktionsebene über Backends zu erstellen, die über Storage Classes referenziert werden können, um mehr Flexibilität und eine effiziente Platzierung von Volumes auf den Backends zu erreichen. Verschiedene Backends können mit derselben Serviceklasse definiert werden. Außerdem können mehrere Speicherpools auf demselben Backend, aber mit unterschiedlichen Eigenschaften erstellt werden. Wenn eine Storage Class mit einem Selektor mit den spezifischen Labels konfiguriert wird, wählt Trident ein Backend aus, das allen Selektor-Labels entspricht, um das Volume zu platzieren. Wenn die Selektor-Labels der Storage Class mit mehreren Speicherpools übereinstimmen, wählt Trident einen davon aus, um das Volume bereitzustellen.

Es ist möglich, virtuelle Pools zur Emulation von Dienstklassen zu entwerfen. Anhand der Implementierung virtueller Pools für Cloud Volume Service für Azure NetApp Files untersuchen wir, wie wir verschiedene Dienstklassen einrichten können. Konfigurieren Sie das Azure NetApp Files-Backend mit mehreren Labels, die unterschiedliche Leistungsstufen repräsentieren. Setzen Sie den servicelevel Aspekt auf die entsprechende Leistungsstufe und fügen Sie unter jedem Label weitere erforderliche Aspekte hinzu. Erstellen Sie nun verschiedene Kubernetes Storage Classes, die jeweils unterschiedlichen virtuellen Pools zugeordnet werden. Mit dem parameters.selector Feld gibt jede StorageClass an, welche virtuellen Pools zum Hosten eines Volumes verwendet werden können.

Aus einem einzigen Storage-Backend lassen sich mehrere virtuelle Pools mit jeweils spezifischen Aspekten erstellen. Konfigurieren Sie dazu das Backend mit mehreren Labels und legen Sie unter jedem Label die benötigten Aspekte fest. Erstellen Sie anschließend verschiedene Kubernetes Storage Classes, indem Sie das parameters.selector Feld verwenden, das den verschiedenen virtuellen Pools zugeordnet wird. Die auf dem Backend bereitgestellten Volumes enthalten dann die im jeweiligen virtuellen Pool definierten Aspekte.

Einige Parameter außerhalb der angeforderten Speicherklasse können den Trident-Bereitstellungsentscheidungsprozess bei der Erstellung eines PVC beeinflussen.

Bei der Anforderung von Speicherplatz über eine PVC ist der Zugriffsmodus eines der Pflichtfelder. Der gewünschte Modus kann Einfluss darauf haben, welches Backend für die Verarbeitung der Speicheranforderung ausgewählt wird.

Trident versucht, das verwendete Speicherprotokoll der angegebenen Zugriffsmethode gemäß der folgenden Matrix zuzuordnen. Dies ist unabhängig von der zugrunde liegenden Speicherplattform.

Eine Anfrage für eine ReadWriteMany PVC, die an eine Trident-Bereitstellung ohne konfiguriertes NFS-Backend gesendet wird, führt dazu, dass kein Volume bereitgestellt wird. Aus diesem Grund sollte der Anfragende den Zugriffsmodus verwenden, der für seine Anwendung geeignet ist.

Persistente Volumes sind in Kubernetes – mit zwei Ausnahmen – unveränderliche Objekte. Nach ihrer Erstellung können die Reclaim-Policy und die Größe angepasst werden. Dies verhindert jedoch nicht, dass bestimmte Aspekte des Volumes außerhalb von Kubernetes geändert werden. Dies kann wünschenswert sein, um das Volume für spezifische Anwendungen anzupassen, um sicherzustellen, dass die Kapazität nicht versehentlich verbraucht wird, oder einfach, um das Volume aus beliebigen Gründen auf einen anderen Speichercontroller zu verschieben.

Die Verbindungsdetails des PV können nach der Erstellung nicht mehr geändert werden.

Trident unterstützt die bedarfsgesteuerte Erstellung von Volume-Snapshots und die Erstellung von PVCs aus Snapshots mithilfe des CSI-Frameworks. Snapshots bieten eine komfortable Methode zur Verwaltung zeitpunktgenauer Kopien der Daten und haben einen vom Quell-PV in Kubernetes unabhängigen Lebenszyklus. Diese Snapshots können zum Klonen von PVCs verwendet werden.

Trident unterstützt auch die Erstellung von PersistentVolumes aus Volume-Snapshots. Dazu erstellen Sie einfach eine PersistentVolumeClaim und geben den datasource gewünschten Snapshot an, aus dem das Volume erstellt werden soll. Trident wird diese PVC verarbeiten, indem ein Volume mit den auf dem Snapshot vorhandenen Daten erstellt wird. Mit dieser Funktion ist es möglich, Daten regionsübergreifend zu duplizieren, Testumgebungen zu erstellen, ein beschädigtes oder beschädigtes Produktionsvolume vollständig zu ersetzen oder bestimmte Dateien und Verzeichnisse abzurufen und auf ein anderes angeschlossenes Volume zu übertragen.

Speicheradministratoren haben die Möglichkeit, Volumes zwischen Aggregaten und Controllern im ONTAP Cluster unterbrechungsfrei für den Speicherkonsumenten zu verschieben. Dieser Vorgang hat keine Auswirkungen auf Trident oder den Kubernetes-Cluster, solange das Zielaggregat eines ist, auf das die von Trident verwendete SVM Zugriff hat. Wichtig ist, dass, wenn das Aggregat neu zur SVM hinzugefügt wurde, das Backend durch erneutes Hinzufügen zu Trident aktualisiert werden muss. Dadurch wird Trident veranlasst, die SVM neu zu inventarisieren, sodass das neue Aggregat erkannt wird.

Das Verschieben von Volumes zwischen Backends wird von Trident nicht automatisch unterstützt. Dies gilt für Verschiebungen zwischen SVMs im selben Cluster, zwischen Clustern oder auf eine andere Speicherplattform (selbst wenn dieses Speichersystem mit Trident verbunden ist).

Wenn ein Volume an einen anderen Speicherort kopiert wird, kann die Volume-Importfunktion verwendet werden, um die aktuellen Volumes in Trident zu importieren.

Trident unterstützt die Größenänderung von NFS-, iSCSI- und FC-PVs. Dadurch können Benutzer ihre Volumes direkt über die Kubernetes-Schicht anpassen. Die Volume-Erweiterung ist für alle gängigen NetApp Speicherplattformen möglich, einschließlich ONTAP und SolidFire/NetApp HCI-Backends. Um eine spätere Erweiterung zu ermöglichen, setzen Sie allowVolumeExpansion auf true in Ihrer StorageClass, die dem Volume zugeordnet ist. Wann immer das Persistent Volume vergrößert werden muss, bearbeiten Sie die spec.resources.requests.storage Annotation im Persistent Volume Claim auf die gewünschte Volume-Größe. Trident kümmert sich dann automatisch um die Größenänderung des Volumes im Speichercluster.

Der Volume-Import ermöglicht das Importieren eines vorhandenen Speichervolumes in eine Kubernetes-Umgebung. Dies wird derzeit von den ontap-nas, ontap-nas-flexgroup, solidfire-san und azure-netapp-files Treibern unterstützt. Diese Funktion ist nützlich beim Portieren einer bestehenden Anwendung nach Kubernetes oder während Notfallwiederherstellungsszenarien.

Bei Verwendung der ONTAP- und solidfire-san Treiber verwenden Sie den Befehl tridentctl import volume <backend-name> <volume-name> -f /path/pvc.yaml, um ein vorhandenes Volume in Kubernetes zu importieren, damit es von Trident verwaltet wird. Die im Import-Volume-Befehl verwendete PVC-YAML- oder JSON-Datei verweist auf eine Storage-Class, die Trident als Provisioner identifiziert. Bei Verwendung eines NetApp HCI/SolidFire Backends stellen Sie sicher, dass die Volume-Namen eindeutig sind. Wenn die Volume-Namen doppelt vorhanden sind, klonen Sie das Volume unter einem eindeutigen Namen, damit die Volume-Importfunktion zwischen ihnen unterscheiden kann.

Wenn der azure-netapp-files Treiber verwendet wird, verwenden Sie den Befehl tridentctl import volume <backend-name> <volume path> -f /path/pvc.yaml, um das Volume in Kubernetes zu importieren, damit es von Trident verwaltet wird. Dadurch wird eine eindeutige Volume-Referenz sichergestellt.

Wenn der oben stehende Befehl ausgeführt wird, findet Trident das Volume im Backend und liest dessen Größe aus. Es wird automatisch die konfigurierte Größe des PVC-Volumes hinzugefügt (und bei Bedarf überschrieben). Anschließend erstellt Trident das neue PV und Kubernetes bindet das PVC an das PV.

Wenn ein Container so bereitgestellt wurde, dass er die spezifische importierte PVC benötigt, bleibt er im Status „Ausstehend“, bis das PVC/PV-Paar über den Volume-Importprozess gebunden ist. Nachdem das PVC/PV-Paar gebunden ist, sollte der Container starten, sofern keine weiteren Probleme auftreten.

Die Bereitstellung und Verwaltung des Speichers für die Registry wurde auf "netapp.io" in der "Blog" dokumentiert.

Wie andere OpenShift-Dienste wird der Protokollierungsdienst mithilfe von Ansible mit den in der Inventardatei, auch Hosts genannt, bereitgestellten Konfigurationsparametern bereitgestellt, die dem Playbook übergeben wird. Es gibt zwei Installationsmethoden, die behandelt werden: die Bereitstellung der Protokollierung während der anfänglichen OpenShift-Installation und die Bereitstellung der Protokollierung, nachdem OpenShift installiert wurde.

Wenn Sie NFS mit dem Protokollierungsdienst verwenden, müssen Sie die Ansible-Variable openshift_enable_unsupported_configurations auf true setzen, um zu verhindern, dass die Installation fehlschlägt.

Mit den entsprechenden Ansible-Variablen, die in Ihrer Hosts/Inventory-Datei definiert sind, stellen Sie den Dienst mit Ansible bereit. Wenn Sie während der OpenShift-Installation bereitstellen, wird das PV automatisch erstellt und verwendet. Wenn Sie mit den Komponenten-Playbooks nach der OpenShift-Installation bereitstellen, erstellt Ansible alle benötigten PVCs und nachdem Trident Speicher dafür bereitgestellt hat, wird der Dienst bereitgestellt.

Die oben genannten Variablen und der Bereitstellungsprozess können sich mit jeder Version von OpenShift ändern. Stellen Sie sicher, dass Sie "Red Hat's OpenShift Implementierungs-Leitfaden" für Ihre Version überprüfen und befolgen, damit diese für Ihre Umgebung konfiguriert ist.