ONTAP Backend-Treiber unterscheiden sich durch das verwendete Protokoll und die Art und Weise, wie die Volumes auf dem Speichersystem bereitgestellt werden. Überlegen Sie sich daher gut, welchen Treiber Sie einsetzen möchten.

Auf einer höheren Ebene, wenn Ihre Anwendung Komponenten enthält, die gemeinsam genutzten Speicher benötigen (mehrere Pods greifen auf denselben PVC zu), sind NAS-basierte Treiber die Standardwahl, während die blockbasierten iSCSI-Treiber die Anforderungen von nicht gemeinsam genutztem Speicher erfüllen. Wählen Sie das Protokoll basierend auf den Anforderungen der Anwendung und dem Komfortniveau der Speicher- und Infrastrukturteams. Im Allgemeinen gibt es für die meisten Anwendungen kaum einen Unterschied zwischen ihnen, daher basiert die Entscheidung oft darauf, ob gemeinsam genutzter Speicher (auf den mehr als ein Pod gleichzeitig zugreifen muss) benötigt wird oder nicht.

Folgende ONTAP Backend-Treiber stehen zur Verfügung:

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

Beachten Sie, dass in den folgenden Tabellen nicht alle Funktionen über Trident zugänglich sind. Einige dieser Einstellungen müssen vom Speicheradministrator nach der Bereitstellung vorgenommen werden, wenn die gewünschte Funktionalität gewünscht ist. Die hochgestellten Fußnoten unterscheiden die Funktionalität pro Feature und Treiber.

Trident bietet 2 SAN-Treiber für ONTAP an, deren Funktionen im Folgenden dargestellt werden.

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

Wie wir aus den obigen Tabellen ersehen können, besteht ein Großteil der Funktionalität zwischen den ontap-nas Und ontap-nas-economy ist dasselbe. Da jedoch ontap-nas-economy Der Treiber schränkt die Möglichkeit ein, den Zeitplan auf Ebene einzelner PVs zu steuern; dies kann sich insbesondere auf Ihre Notfallwiederherstellungs- und Datensicherungsplanung auswirken. Für Entwicklungsteams, die die PVC-Klonfunktion auf ONTAP -Speicher nutzen möchten, ist dies nur möglich, wenn sie Folgendes verwenden: ontap-nas , ontap-san oder ontap-san-economy Fahrer.

Cloud Volumes ONTAP bietet Datenkontrolle sowie Speicherfunktionen der Enterprise-Klasse für verschiedene Anwendungsfälle, darunter Dateifreigaben und Blockspeicher, die NAS- und SAN-Protokolle (NFS, SMB / CIFS und iSCSI) unterstützen. 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 und Cloud Volume ONTAP für GCP.

Mit Amazon FSx for NetApp ONTAP können Sie die Ihnen vertrauten Funktionen, die Leistung und die administrativen Möglichkeiten von NetApp nutzen und gleichzeitig die Einfachheit, Agilität, Sicherheit und Skalierbarkeit der Datenspeicherung auf AWS in Anspruch nehmen. FSx für ONTAP unterstützt viele ONTAP Dateisystemfunktionen und Administrations-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 Der 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 konfigurieren möchten, dass die spezifischen QoS-Grenzwerte für die von Trident bereitgestellten Volumes festgelegt werden, verwenden Sie die type Parameter in der Backend-Datei. Der Administrator kann außerdem die Größe des auf dem Speicher erstellten Volumes mithilfe der limitVolumeSize Parameter. Aktuell werden Element-Speicherfunktionen wie die Größenänderung von Datenträgern und die Replikation von Datenträgern nicht unterstützt. solidfire-san Treiber. Diese Vorgänge sollten manuell über die Web-Benutzeroberfläche von Element Software durchgeführt werden.

Trident verwendet die azure-netapp-files Fahrer zur Verwaltung des"Azure NetApp Files" Service.

Weitere Informationen zu diesem Treiber und dessen Konfiguration finden Sie in"Trident Backend-Konfiguration für Azure NetApp Files" .

Trident verwendet die gcp-cvs Treiber zur Verbindung mit dem Cloud Volumes Service auf Google Cloud.

Der gcp-cvs Der Treiber verwendet virtuelle Pools, um das Backend zu abstrahieren und Trident die Bestimmung der Volume-Platzierung zu ermöglichen. Der Administrator definiert die virtuellen Pools im backend.json Dateien. Speicherklassen verwenden Selektoren, um virtuelle Pools anhand ihrer Bezeichnung zu identifizieren.

Um das Google Cloud-Backend auf Trident zu konfigurieren, müssen Sie Folgendes angeben: projectNumber , apiRegion , Und apiKey in der Backend-Datei. Die Projektnummer finden Sie in der Google Cloud Console. Der API-Schlüssel stammt aus der privaten Schlüsseldatei des Dienstkontos, die Sie beim Einrichten des API-Zugriffs für den Cloud Volumes Service auf Google Cloud erstellt haben.

Für Details zum Cloud Volumes Service auf Google Cloud (Diensttypen und Servicelevel) siehe"Erfahren Sie mehr über die Trident Unterstützung für CVS für GCP." .

Mithilfe von Filtern kann innerhalb eines bestimmten Speicherklassenobjekts ermittelt werden, welcher Speicherpool oder welche Gruppe von Speicherpools mit dieser bestimmten Speicherklasse verwendet werden soll. In der Speicherklasse können drei Filtersätze festgelegt werden: storagePools , additionalStoragePools und/oder excludeStoragePools .

Der storagePools Mit diesem Parameter kann der Speicher auf die Pools beschränkt werden, die den angegebenen Attributen entsprechen. Der additionalStoragePools Der Parameter dient dazu, die Menge der Pools, die Trident für die Bereitstellung verwendet, zusammen mit der Menge der durch die Attribute ausgewählten Pools zu erweitern. storagePools Parameter. Sie können entweder den einen oder den anderen Parameter einzeln oder beide zusammen verwenden, um sicherzustellen, dass die richtigen Speicherpools ausgewählt werden.

Der excludeStoragePools Der Parameter dient dazu, die aufgelisteten Pools, die den Attributen entsprechen, gezielt auszuschließen.

Wenn Sie Speicherklassen entwerfen möchten, um QoS-Richtlinien zu emulieren, erstellen Sie eine Speicherklasse mit der media Attribut als hdd oder ssd . Basierend auf der media Trident wählt für jedes in der Speicherklasse angegebene Attribut das passende Backend aus. hdd oder ssd Aggregate werden erstellt, um das Medienattribut abzugleichen und anschließend die Bereitstellung der Volumes auf das jeweilige Aggregat zu steuern. Daher können wir eine Speicherklasse PREMIUM erstellen, die Folgendes hätte: media Attribut festgelegt als ssd was als PREMIUM QoS-Richtlinie eingestuft werden könnte. Wir können eine weitere Speicherklasse STANDARD erstellen, deren Medienattribut auf hdd gesetzt wäre, die als STANDARD QoS-Richtlinie klassifiziert werden könnte. Wir könnten auch das Attribut „IOPS“ in der Speicherklasse verwenden, um die Bereitstellung auf ein Element-Gerät umzuleiten, das als QoS-Richtlinie definiert werden kann.

Speicherklassen können so konzipiert werden, dass die Volumenbereitstellung auf einem bestimmten Backend gesteuert wird, 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 den erforderlichen aktivierten Funktionen angeben.

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

Virtuelle Pools ermöglichen es einem Administrator, eine Abstraktionsebene über Backends zu erstellen, auf die über Storage Classes verwiesen werden kann, um eine größere Flexibilität und effizientere Platzierung von Volumes auf Backends zu gewährleisten. Verschiedene Backends können mit derselben Serviceklasse definiert werden. Darüber hinaus können auf demselben Backend mehrere Speicherpools mit unterschiedlichen Eigenschaften erstellt werden. Wenn eine Speicherklasse mit einem Selektor mit den spezifischen Bezeichnungen konfiguriert ist, wählt Trident ein Backend aus, das allen Selektorbezeichnungen entspricht, um das Volume dort zu platzieren. Wenn die Bezeichnungen des Speicherklassenselektors mit mehreren Speicherpools übereinstimmen, wählt Trident einen davon aus, um das Volume bereitzustellen.

Es ist möglich, virtuelle Pools zur Emulation von Serviceklassen zu entwerfen. Anhand der virtuellen Pool-Implementierung für Cloud Volume Service für Azure NetApp Files wollen wir untersuchen, wie wir verschiedene Dienstklassen einrichten können. Konfigurieren Sie das Azure NetApp Files -Backend mit mehreren Bezeichnungen, die unterschiedliche Leistungsstufen darstellen. Satz servicelevel den jeweiligen Aspekt dem entsprechenden Leistungsniveau zuordnen und unter jeder Bezeichnung weitere erforderliche Aspekte hinzufügen. Erstellen Sie nun verschiedene Kubernetes-Speicherklassen, die unterschiedlichen virtuellen Pools zugeordnet werden. Verwenden des parameters.selector Im Feld „StorageClass“ wird für jede StorageClass angegeben, welche virtuellen Pools zum Hosten eines Volumes verwendet werden können.

Ausgehend von einem einzigen Speicher-Backend können mehrere virtuelle Pools mit jeweils spezifischen Eigenschaften entworfen werden. Konfigurieren Sie dazu das Backend mit mehreren Labels und legen Sie unter jedem Label die erforderlichen Aspekte fest. Erstellen Sie nun verschiedene Kubernetes-Speicherklassen mithilfe der parameters.selector Feld, das verschiedenen virtuellen Pools zugeordnet werden würde. Die im Backend bereitgestellten Volumes weisen die im gewählten virtuellen Pool definierten Eigenschaften auf.

Bei der Erstellung eines PVC können neben den angeforderten Speicherklassen auch andere Parameter den Trident -Bereitstellungsprozess beeinflussen.

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

Trident wird versuchen, das verwendete Speicherprotokoll mit der angegebenen Zugriffsmethode gemäß der folgenden Matrix abzugleichen. Dies ist unabhängig von der zugrunde liegenden Speicherplattform.

Eine Anfrage für ein 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 für seine Anwendung geeigneten Zugriffsmodus verwenden.

Persistente Volumes sind, mit zwei Ausnahmen, unveränderliche Objekte in Kubernetes. Nach der Erstellung können die Rückforderungsrichtlinie und die Größe angepasst werden. Dies verhindert jedoch nicht, dass bestimmte Aspekte des Volumes außerhalb von Kubernetes modifiziert werden. Dies kann wünschenswert sein, um das Volume für bestimmte Anwendungen anzupassen, um sicherzustellen, dass die Kapazität nicht versehentlich verbraucht wird, oder 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 Erstellung von Volume-Snapshots bei Bedarf sowie die Erstellung von PVCs aus Snapshots mithilfe des CSI-Frameworks. Snapshots bieten eine komfortable Methode zur Aufbewahrung von zeitpunktbezogenen Kopien der Daten und haben einen vom Quell-PV in Kubernetes unabhängigen Lebenszyklus. Mithilfe dieser Snapshots können PVCs geklont werden.

Trident unterstützt auch die Erstellung von PersistentVolumes aus Volume-Snapshots. Um dies zu erreichen, erstellen Sie einfach einen PersistentVolumeClaim und geben Sie den entsprechenden Eintrag an. datasource als der erforderliche Snapshot, aus dem das Volume erstellt werden muss. Trident wird dieses PVC verarbeiten, indem ein Volume mit den im Snapshot vorhandenen Daten erstellt wird. Mit dieser Funktion können Daten regionsübergreifend dupliziert, Testumgebungen erstellt, ein beschädigtes oder fehlerhaftes Produktionsvolume vollständig ersetzt oder bestimmte Dateien und Verzeichnisse abgerufen und auf ein anderes angeschlossenes Volume übertragen werden.

Speicheradministratoren haben die Möglichkeit, Datenträger zwischen Aggregaten und Controllern im ONTAP Cluster zu verschieben, ohne den Speicherkonsumenten zu beeinträchtigen. Dieser Vorgang hat keine Auswirkungen auf Trident oder den Kubernetes-Cluster, sofern es sich bei dem Zielaggregat um ein solches handelt, auf das die von Trident verwendete SVM Zugriff hat. Wichtig ist, dass, wenn das Aggregat neu zum SVM hinzugefügt wurde, das Backend aktualisiert werden muss, indem es erneut zu Trident hinzugefügt wird. Dies veranlasst Trident, das SVM neu zu inventarisieren, damit das neue Aggregat erkannt wird.

Das Verschieben von Datenvolumen zwischen verschiedenen Backends wird von Trident jedoch nicht automatisch unterstützt. Dies umfasst SVMs innerhalb desselben Clusters, SVMs zwischen Clustern oder SVMs auf einer anderen 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. Dies ermöglicht es Benutzern, ihre Volumes direkt über die Kubernetes-Schicht zu vergrößern oder zu verkleinern. Die Speichererweiterung ist für alle wichtigen NetApp Speicherplattformen möglich, einschließlich ONTAP, SolidFire/ NetApp HCI und Cloud Volumes Service Backends. Um eine spätere Erweiterung zu ermöglichen, setzen Sie allowVolumeExpansion Zu true in Ihrer StorageClass, die dem Volume zugeordnet ist. Immer wenn die Größe des persistenten Volumes geändert werden muss, bearbeiten Sie die spec.resources.requests.storage Anmerkung im Persistent Volume Claim zur erforderlichen Volumengröße. Trident kümmert sich automatisch um die Größenanpassung des Volumes im Speichercluster.

Der Volume-Import ermöglicht es, ein vorhandenes Speichervolume in eine Kubernetes-Umgebung zu importieren. Dies wird derzeit unterstützt durch ontap-nas , ontap-nas-flexgroup , solidfire-san , azure-netapp-files , Und gcp-cvs Fahrer. Diese Funktion ist nützlich beim Portieren einer bestehenden Anwendung nach Kubernetes oder in Notfallwiederherstellungsszenarien.

Bei der Verwendung von ONTAP und solidfire-san Fahrer, verwenden Sie den Befehl tridentctl import volume <backend-name> <volume-name> -f /path/pvc.yaml Ein vorhandenes Volume in Kubernetes importieren, das von Trident verwaltet werden soll. Die im Import-Volume-Befehl verwendete PVC-YAML- oder JSON-Datei verweist auf eine Speicherklasse, die Trident als Provisionierer identifiziert. Bei Verwendung eines NetApp HCI/ SolidFire Backends muss sichergestellt werden, dass die Volume-Namen eindeutig sind. Falls die Volumennamen doppelt vorkommen, klonen Sie das Volumen unter einem eindeutigen Namen, damit die Volumenimportfunktion sie unterscheiden kann.

Wenn die azure-netapp-files oder gcp-cvs Wenn der Treiber verwendet wird, verwenden Sie den Befehl tridentctl import volume <backend-name> <volume path> -f /path/pvc.yaml Das Volume soll in Kubernetes importiert und von Trident verwaltet werden. Dies gewährleistet eine eindeutige Volumenreferenz.

Wenn der obige Befehl ausgeführt wird, findet Trident das Volume im Backend und liest dessen Größe aus. Die konfigurierte PVC-Volumengröße wird automatisch hinzugefügt (und gegebenenfalls überschrieben). Trident erstellt dann das neue PV und Kubernetes bindet das PVC an das PV.

Wenn ein Container so eingesetzt wird, dass er die spezifische importierte PVC benötigt, bleibt er im Status "ausstehend", bis das PVC/PV-Paar über den Volumenimportprozess gebunden wird. Nach dem Verbinden der PVC/PV-Leitungen sollte sich der Behälter hochziehen lassen, sofern keine anderen Probleme auftreten.

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

Wie andere OpenShift-Dienste wird auch der Protokollierungsdienst mithilfe von Ansible bereitgestellt, wobei die Konfigurationsparameter aus der Inventardatei (auch Hosts genannt) stammen, die dem Playbook übergeben wird. Es werden zwei Installationsmethoden behandelt: die Bereitstellung der Protokollierung während der Erstinstallation von OpenShift und die Bereitstellung der Protokollierung nach der Installation von OpenShift.

Wenn Sie NFS mit dem Protokollierungsdienst verwenden möchten, müssen Sie die Ansible-Variable festlegen. openshift_enable_unsupported_configurations Zu true um zu verhindern, dass das Installationsprogramm fehlschlägt.

Nachdem die entsprechenden Ansible-Variablen in Ihrer hosts/inventory-Datei definiert wurden, können Sie den Dienst mithilfe von Ansible bereitstellen. Wenn Sie die Bereitstellung zum Zeitpunkt der OpenShift-Installation durchführen, wird das PV automatisch erstellt und verwendet. Wenn Sie die Bereitstellung mithilfe der Komponenten-Playbooks durchführen, erstellt Ansible nach der OpenShift-Installation alle benötigten PVCs und stellt den Dienst bereit, nachdem Trident Speicherplatz dafür bereitgestellt hat.

Die oben genannten Variablen und der Bereitstellungsprozess können sich mit jeder Version von OpenShift ändern. Bitte überprüfen und befolgen Sie die Anweisungen."Red Hats OpenShift-Bereitstellungsleitfaden" für Ihre Version, damit sie für Ihre Umgebung konfiguriert ist.