Integration Von Astra Trident
Zur Integration von Astra Trident erfordern die folgenden Design- und Architekturelemente Integration: Treiberauswahl und -Implementierung, Storage-Class-Design, Virtual Pool Design, Persistent Volume Claim (PVC) Einfluss auf die Storage-Bereitstellung, auf den Volume-Betrieb und die OpenShift-Serviceimplementierung mit Astra Trident.
Auswahl und Implementierung der Treiber
Wählen Sie einen Back-End-Treiber für Ihr Speichersystem aus und implementieren Sie ihn.
Back-End-Treiber für ONTAP
Die Back-End-Treiber für ONTAP unterscheiden sich durch das verwendete Protokoll und die Art und Weise, wie die Volumes im Storage-System bereitgestellt werden. Daher sollten Sie bei der Entscheidung, welchen Treiber eingesetzt werden soll, sorgfältig überlegen.
Auf einer höheren Ebene, wenn Ihre Applikation Komponenten hat, die gemeinsamen Storage benötigen (mehrere Pods, die auf dasselbe PVC zugreifen), sind NAS-basierte Treiber die erste Wahl, während die blockbasierten iSCSI-Treiber die Anforderungen von nicht gemeinsam genutztem Storage erfüllen. Wählen Sie das Protokoll basierend auf den Anforderungen der Applikation und der Komfort-Ebene der Storage- und Infrastrukturteams. Generell besteht für die meisten Applikationen kein Unterschied zwischen ihnen. Oftmals basiert die Entscheidung darauf, ob gemeinsam genutzter Storage (wo mehr als ein POD den gleichzeitigen Zugriff benötigen) benötigt wird.
Die verfügbaren Back-End-Treiber für ONTAP sind:
-
ontap-nas
: Jedes bereitgestellte PV ist ein vollständiges ONTAP FlexVolume. -
ontap-nas-economy
: Jedes bereitgestellte PV ist ein qtree, mit einer konfigurierbaren Anzahl von qtrees pro FlexVolume (Standard ist 200). -
ontap-nas-flexgroup
: Jedes PV, das als vollständiges ONTAP FlexGroup bereitgestellt wird, und alle Aggregate, die einer SVM zugewiesen sind, werden verwendet. -
ontap-san
: Jedes bereitgestellte PV ist eine LUN innerhalb seines eigenen FlexVolume. -
ontap-san-economy
: Jedes bereitgestellte PV ist eine LUN, mit einer konfigurierbaren Anzahl von LUNs pro FlexVolume (Standard ist 100).
Die Auswahl zwischen den drei NAS-Treibern hat einige Auswirkungen auf die Funktionen, die der Applikation zur Verfügung gestellt werden.
Beachten Sie, dass in den nachstehenden Tabellen nicht alle Funktionen durch Astra Trident zugänglich sind. Einige müssen vom Storage-Administrator nach der Bereitstellung angewendet werden, wenn diese Funktion gewünscht wird. Die Super-Skript-Fußnoten unterscheiden die Funktionalität pro Feature und Treiber.
ONTAP NAS-Treiber | Snapshots | Klone | Dynamische Exportrichtlinien | Multi-Anschluss | QoS | Größe Ändern | Replizierung |
---|---|---|---|---|---|---|---|
|
Ja. |
Ja. |
Jafußnote:5[] |
Ja. |
Jafußnote:1[] |
Ja. |
Jafußnote:1[] |
|
Jafußnote:3[] |
Jafußnote:3[] |
Jafußnote:5[] |
Ja. |
Jafußnote:3[] |
Ja. |
Jafußnote:3[] |
|
Jafußnote:1[] |
Nein |
Jafußnote:5[] |
Ja. |
Jafußnote:1[] |
Ja. |
Jafußnote:1[] |
Astra Trident bietet 2 SAN-Treiber für ONTAP, die unten aufgeführt sind.
ONTAP SAN-Treiber | Snapshots | Klone | Multi-Anschluss | Bidirektionales CHAP | QoS | Größe Ändern | Replizierung |
---|---|---|---|---|---|---|---|
|
Ja. |
Ja. |
Jafußnote:4[] |
Ja. |
Jafußnote:1[] |
Ja. |
Jafußnote:1[] |
|
Ja. |
Ja. |
Jafußnote:4[] |
Ja. |
Jafußnote:3[] |
Ja. |
Jafußnote:3[] |
Fußnote für die obigen Tabellen: Yes[1]: Nicht von Astra Trident verwaltet Yes[2]: Verwaltet von Astra Trident, aber nicht von PV granular Yes[3]: Nicht von Astra Trident verwaltet und nicht von PV granular Yes[4]: Unterstützt für RAW-Block-Volumes Yes[5]: Unterstützt von Astra Trident
Die Funktionen, die keine PV-Granularität sind, werden auf das gesamte FlexVolume angewendet, und alle PVs (also qtrees oder LUNs in gemeinsam genutzten FlexVols) teilen einen gemeinsamen Zeitplan.
Wie wir in den obigen Tabellen sehen können, ist ein Großteil der Funktionalität zwischen und ontap-nas-economy
die ontap-nas
gleiche. Da der Treiber jedoch ontap-nas-economy
die Möglichkeit zur Steuerung des Zeitplans auf PV-Granularität beschränkt, kann dies insbesondere Ihre Disaster Recovery- und Backup-Planung beeinträchtigen. Für Entwicklungsteams, die die PVC-Klonfunktion auf dem ONTAP-Storage nutzen möchten, ist dies nur mit den, ontap-san
oder ontap-san-economy
-Treibern möglich ontap-nas
.
Der solidfire-san Treiber kann auch VES klonen.
|
Back-End-Treiber für Cloud Volumes ONTAP
Cloud Volumes ONTAP bietet Datenkontrolle und Storage-Funktionen der Enterprise-Klasse für verschiedene Anwendungsfälle, einschließlich Dateifreigaben und Storage-Funktionen 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.
Back-End-Treiber für Amazon FSX for ONTAP
Amazon FSX for NetApp ONTAP ermöglicht Ihnen die Nutzung von NetApp Funktionen, Performance und Administrationsfunktionen, mit denen Sie vertraut sind, und gleichzeitig die Einfachheit, Agilität, Sicherheit und Skalierbarkeit der Speicherung von Daten auf AWS zu nutzen. 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
.
Back-End-Treiber für NetApp HCI/SolidFire
Der solidfire-san
Treiber, der mit den NetApp HCI/SolidFire-Plattformen verwendet wird, hilft dem Administrator, ein Element Backend für Trident auf der Grundlage von QoS Limits zu konfigurieren. Wenn Sie Ihr Backend so gestalten möchten, dass die spezifischen QoS-Limits für die durch Trident bereitgestellten Volumes festgelegt werden, verwenden Sie den type
Parameter in der Backend-Datei. Der Admin kann auch die Volume-Größe einschränken, die mit dem Parameter auf dem Storage erstellt werden limitVolumeSize
kann. Derzeit werden Element Storage-Funktionen wie die Größenanpassung von Volumes und die Volume-Replizierung nicht durch den Treiber unterstützt solidfire-san
. Diese Vorgänge sollten manuell über die Web-UI von Element Software durchgeführt werden.
SolidFire-Treiber | Snapshots | Klone | Multi-Anschluss | CHAP | QoS | Größe Ändern | Replizierung |
---|---|---|---|---|---|---|---|
|
Ja. |
Ja. |
Jafußnote:2[] |
Ja. |
Ja. |
Ja. |
Jafußnote:1[] |
Fußnote: Yes[1]: Nicht verwaltet durch Astra Trident Ja[2]: Wird für RAW-Block-Volumes unterstützt
Back-End-Treiber für Azure NetApp Files
Astra Trident verwendet den azure-netapp-files
Treiber für das Management des "Azure NetApp Dateien" Service.
Weitere Informationen zu diesem Treiber und zur Konfiguration finden Sie unter "Astra Trident – Back-End-Konfiguration für Azure NetApp Files".
Azure NetApp Files-Treiber | Snapshots | Klone | Multi-Anschluss | QoS | Erweitern | Replizierung |
---|---|---|---|---|---|---|
|
Ja. |
Ja. |
Ja. |
Ja. |
Ja. |
Jafußnote:1[] |
Fußnote: Yes[1]: Nicht verwaltet durch Astra Trident
Cloud Volumes Service auf Google Cloud Backend-Treiber
Astra Trident verwendet den gcp-cvs
Treiber für die Verbindung mit dem Cloud Volumes Service auf Google Cloud.
Der gcp-cvs
Treiber verwendet virtuelle Pools, um das Back-End zu abstrahieren und Astra Trident die Volume-Platzierung bestimmen zu können. Der Administrator definiert die virtuellen Pools in den backend.json
Dateien. Storage-Klassen verwenden Selektoren, um virtuelle Pools nach Etikett zu identifizieren.
-
Wenn virtuelle Pools im Backend definiert werden, versucht Astra Trident, ein Volume in den Google Cloud Storage-Pools zu erstellen, zu denen diese virtuellen Pools begrenzt sind.
-
Wenn virtuelle Pools nicht im Backend definiert sind, wählt Astra Trident aus den verfügbaren Storage-Pools der Region einen Google Cloud Storage-Pool aus.
Um das Google Cloud Backend auf Astra Trident zu konfigurieren, müssen Sie , apiRegion
und apiKey
in der Backend-Datei angeben projectNumber
. Die Projektnummer finden Sie in der Google Cloud-Konsole. Der API-Schlüssel wird aus der Datei mit dem privaten Schlüssel des Dienstkontos entnommen, die Sie beim Einrichten des API-Zugriffs für Cloud Volumes Service in der Google Cloud erstellt haben.
Weitere Informationen zu Cloud Volumes Service auf Google Cloud Service-Typen und Service-Leveln finden Sie in "Erfahren Sie mehr über Astra Trident Support für CVS für GCP".
Cloud Volumes Service für Google Cloud Treiber | Snapshots | Klone | Multi-Anschluss | QoS | Erweitern | Replizierung |
---|---|---|---|---|---|---|
|
Ja. |
Ja. |
Ja. |
Ja. |
Ja. |
Nur für den CVS-Performance-Diensttyp verfügbar. |
Hinweise zur Replikation
|
Design der Storage-Klasse
Individuelle Storage-Klassen müssen konfiguriert und angewendet werden, um ein Kubernetes Storage Class-Objekt zu erstellen. Dieser Abschnitt erläutert, wie Sie eine Storage-Klasse für Ihre Applikation entwerfen.
Spezifische Back-End-Auslastung
Die Filterung kann innerhalb eines bestimmten Storage-Klassenobjekts verwendet werden, um festzulegen, welcher Storage-Pool bzw. welche Pools für die jeweilige Storage-Klasse verwendet werden sollen. In der Storage Class können drei Filtersätze eingestellt werden: storagePools
, additionalStoragePools
Und/oder excludeStoragePools
.
Mit dem storagePools
Parameter kann der Speicher auf die Gruppe von Pools beschränkt werden, die mit allen angegebenen Attributen übereinstimmen. Mit dem additionalStoragePools
Parameter wird der Satz von Pools, den Astra Trident für die Bereitstellung verwendet, zusammen mit dem Satz von Pools erweitert, die durch die Attribute und Parameter ausgewählt storagePools
wurden. Sie können entweder nur einen der Parameter oder beide zusammen verwenden, um sicherzustellen, dass der entsprechende Satz von Speicherpools ausgewählt wird.
Der excludeStoragePools
Parameter wird verwendet, um speziell die aufgelisteten Pools auszuschließen, die mit den Attributen übereinstimmen.
QoS-Richtlinien emulieren
Wenn Sie Storage-Klassen so entwerfen möchten, dass sie Quality of Service-Richtlinien emulieren, erstellen Sie eine Storage-Klasse mit dem media
Attribut hdd
oder ssd
. Auf der Grundlage des media
in der Storage-Klasse bereits erwähnten Attributs wählt Trident das geeignete Back-End mit Servern oder ssd
Aggregaten aus, das hdd
dem Medienattribut entspricht, und leitet die Bereitstellung der Volumes dann an das spezifische Aggregat weiter. Daher können wir einen PREMIUM-Storage-Klasse erstellen, für media
den Attribute festgelegt werden, die als ssd
PREMIUM-QoS-Richtlinie klassifiziert werden könnten. Wir können einen weiteren STANDARD der Storage-Klasse erstellen, bei dem das Medienattribut auf `hdd gesetzt wäre. Dieser Standard könnte die QoS-Richtlinie SEIN. Darüber hinaus könnten wir das Attribut ``IOPS' in der Storage-Klasse verwenden, um die Bereitstellung zu einer Element Appliance umzuleiten, die als QoS-Richtlinie definiert werden kann.
Nutzung von Backend basierend auf bestimmten Funktionen
Storage-Klassen ermöglichen die direkte Volume-Bereitstellung an einem bestimmten Back-End, bei dem Funktionen wie Thin Provisioning und Thick Provisioning, Snapshots, Klone und Verschlüsselung aktiviert sind. Um festzulegen, welchen Speicher verwendet werden soll, erstellen Sie Speicherklassen, die das entsprechende Back-End mit aktivierter Funktion angeben.
Virtuelle Pools
Virtuelle Pools sind für alle Astra Trident Back-Ends verfügbar. Sie können virtuelle Pools für jedes Backend mit jedem Treiber von Astra Trident definieren.
Mit virtuellen Pools kann ein Administrator eine Abstraktionsebene über Back-Ends erstellen, auf die über Storage-Klassen verwiesen werden kann. So werden Volumes auf Back-Ends flexibler und effizienter platziert. Verschiedene Back-Ends können mit derselben Serviceklasse definiert werden. Darüber hinaus können mehrere Storage Pools auf demselben Backend erstellt werden, jedoch mit unterschiedlichen Eigenschaften. Wenn eine Storage Class mit einem Selector mit den speziellen Beschriftungen konfiguriert ist, wählt Astra Trident ein Backend, das mit allen Auswahletiketten übereinstimmt, um das Volume zu platzieren. Wenn die Storage Class Selector mit mehreren Storage Pools übereinstimmt, wählt Astra Trident einen von ihnen für die Bereitstellung des Volume aus.
Virtual Pool Design
Beim Erstellen eines Backend können Sie im Allgemeinen eine Reihe von Parametern angeben. Der Administrator konnte kein weiteres Back-End mit denselben Storage Credentials und anderen Parametern erstellen. Mit der Einführung von virtuellen Pools wurde dieses Problem behoben. Virtual Pools ist eine Ebene-Abstraktion, die zwischen dem Backend und der Kubernetes Storage Class eingeführt wird. So kann der Administrator Parameter zusammen mit Labels definieren, die über Kubernetes Storage Klassen als Selektion auf Backend-unabhängige Weise referenziert werden können. Virtuelle Pools können mit Astra Trident für alle unterstützten NetApp Back-Ends definiert werden. Dazu zählen SolidFire/NetApp HCI, ONTAP, Cloud Volumes Service auf GCP und Azure NetApp Files.
Bei der Definition von virtuellen Pools wird empfohlen, nicht zu versuchen, die Reihenfolge vorhandener virtueller Pools in einer Backend-Definition neu anzuordnen. Es wird auch empfohlen, Attribute für einen vorhandenen virtuellen Pool nicht zu bearbeiten/zu ändern und stattdessen einen neuen virtuellen Pool zu definieren. |
Emulation verschiedener Service-Level/QoS
Es ist möglich, virtuelle Pools zur Emulation von Serviceklassen zu entwerfen. Untersuchen wir mit der Implementierung des virtuellen Pools für den Cloud Volume Service für Azure NetApp Files, wie wir verschiedene Serviceklassen einrichten können. Konfigurieren Sie das Azure NetApp Files Back-End mit mehreren Labels, die unterschiedliche Performance-Levels repräsentieren. Stellen Sie servicelevel
Aspect auf das entsprechende Leistungsniveau ein, und fügen Sie weitere erforderliche Aspekte unter den einzelnen Beschriftungen hinzu. Erstellen Sie nun verschiedene Kubernetes Storage-Klassen, die verschiedenen virtuellen Pools zugeordnet werden würden. Über das parameters.selector
Feld ruft jede StorageClass ab, welche virtuellen Pools zum Hosten eines Volumes verwendet werden können.
Zuweisen eines spezifischen Satzes von Aspekten
Mehrere virtuelle Pools mit spezifischen Aspekten können über ein einzelnes Storage-Back-End entwickelt werden. Konfigurieren Sie dazu das Backend mit mehreren Beschriftungen und legen Sie die erforderlichen Aspekte unter jedem Etikett fest. Erstellen Sie nun mithilfe des Felds, das verschiedenen virtuellen Pools zugeordnet wird, verschiedene Kubernetes-Storage-Klassen parameters.selector
. Die Volumes, die im Backend bereitgestellt werden, werden im ausgewählten virtuellen Pool über die Aspekte definiert.
PVC-Merkmale, die die Storage-Bereitstellung beeinflussen
Einige Parameter außerhalb der angeforderten Storage-Klasse können sich bei der Erstellung eines PVC auf den Entscheidungsprozess von Astra Trident auswirken.
Zugriffsmodus
Wenn Sie Speicher über ein PVC anfordern, ist eines der Pflichtfelder der Zugriffsmodus. Der gewünschte Modus kann sich auf das ausgewählte Backend auswirken, um die Speicheranforderung zu hosten.
Astra Trident versucht, das verwendete Storage-Protokoll mit der in der folgenden Matrix angegebenen Zugriffsmethode abzustimmen. Dies ist unabhängig von der zugrunde liegenden Storage-Plattform.
ReadWriteOnce | ReadOnlyManche | ReadWriteViele | |
---|---|---|---|
ISCSI |
Ja. |
Ja. |
Ja (Raw Block) |
NFS |
Ja. |
Ja. |
Ja. |
Eine Anfrage nach einem ReadWriteManche PVC, die an eine Trident-Implementierung ohne konfiguriertes NFS-Backend gesendet werden, führt dazu, dass kein Volume bereitgestellt wird. Aus diesem Grund sollte der Anforderer den Zugriffsmodus verwenden, der für seine Anwendung geeignet ist.
Volume-Vorgänge
Persistente Volumes ändern
Persistente Volumes sind mit zwei Ausnahmen unveränderliche Objekte in Kubernetes. Sobald die Rückgewinnungsrichtlinie erstellt wurde, kann die Größe geändert werden. Dies hindert jedoch nicht daran, einige Aspekte des Volumes außerhalb von Kubernetes zu ändern. Das kann durchaus wünschenswert sein, wenn das Volume für spezifische Applikationen angepasst werden soll, um sicherzustellen, dass die Kapazität nicht versehentlich verbraucht wird oder das Volume einfach aus irgendeinem Grund auf einen anderen Storage Controller verschoben werden kann.
Kubernetes-in-Tree-Provisioners unterstützen derzeit keine Vorgänge zur Größenanpassung von Volumes für NFS oder iSCSI PVS. Astra Trident unterstützt die Erweiterung von NFS- und iSCSI-Volumes. |
Die Verbindungsdetails des PV können nach der Erstellung nicht geändert werden.
Erstellung von On-Demand-Volume-Snapshots
Astra Trident unterstützt die On-Demand-Volume-Snapshot-Erstellung und die Erstellung von PVCs aus Snapshots mithilfe des CSI-Frameworks. Snapshots bieten eine bequeme Methode, zeitpunktgenaue Kopien der Daten zu erstellen und haben unabhängig vom Quell-PV in Kubernetes einen Lebenszyklus. Diese Snapshots können zum Klonen von PVCs verwendet werden.
Volumes-Erstellung aus Snapshots
Astra Trident unterstützt außerdem die Erstellung von PersistenzVolumes aus Volume Snapshots. Um dies zu erreichen, erstellen Sie einfach ein PersistentVolumeClaim und erwähnen Sie den datasource
als den erforderlichen Snapshot, aus dem das Volume erstellt werden muss. Astra Trident wird dieses PVC behandeln, indem ein Volume mit den auf dem Snapshot vorhandenen Daten erstellt wird. Mit dieser Funktion können Daten regionsübergreifend dupliziert, Testumgebungen erstellt, ein defektes oder defektes Produktionsvolumen vollständig ersetzt oder bestimmte Dateien und Verzeichnisse abgerufen und auf ein anderes angeschlossenes Volume übertragen werden.
Verschieben Sie Volumes im Cluster
Storage-Administratoren können Volumes zwischen Aggregaten und Controllern im ONTAP Cluster unterbrechungsfrei für den Storage-Nutzer verschieben. Dieser Vorgang wirkt sich nicht auf Astra Trident oder den Kubernetes-Cluster aus, solange das Zielaggregat eine der SVM ist, auf die Astra Trident Zugriff hat. Was noch wichtiger ist: Wenn das Aggregat neu zur SVM hinzugefügt wurde, muss das Backend durch erneutes Hinzufügen zu Astra Trident aktualisiert werden. Dies führt Astra Trident dazu, die SVM neu zu inventarisieren, damit das neue Aggregat erkannt wird.
Das Verschieben von Volumes zwischen Back-Ends wird von Astra Trident jedoch nicht automatisch unterstützt. Dazu gehören SVMs im selben Cluster, zwischen Clustern oder auf einer anderen Storage-Plattform (auch wenn dieses Storage-System mit Astra Trident verbunden ist).
Wenn ein Volume an einen anderen Speicherort kopiert wird, kann die Funktion zum Importieren aktueller Volumes in Astra Trident verwendet werden.
Erweitern Sie Volumes
Astra Trident unterstützt die Anpassung von NFS und iSCSI PVS. Dadurch können Benutzer ihre Volumes direkt über die Kubernetes-Ebene skalieren. Eine Volume-Erweiterung ist für alle größeren NetApp Storage-Plattformen möglich, einschließlich ONTAP, SolidFire/NetApp HCI und Cloud Volumes Service Back-Ends. Um später eine mögliche Erweiterung zu ermöglichen, setzen Sie allowVolumeExpansion
in der mit dem Volume verknüpften StorageClass auf true
. Wenn die Größe des persistenten Volumes geändert werden muss, bearbeiten Sie die spec.resources.requests.storage
Anmerkung im Persistent Volume Claim auf die erforderliche Volume-Größe. Trident übernimmt automatisch die Anpassung der Größe des Volumes im Storage-Cluster.
Importieren eines vorhandenen Volumes in Kubernetes
Mit dem Volume-Import kann ein vorhandenes Storage Volume in eine Kubernetes-Umgebung importiert werden. Dies wird derzeit von den, , ontap-nas-flexgroup
, solidfire-san
azure-netapp-files
und gcp-cvs
Treibern unterstützt ontap-nas
. Diese Funktion ist hilfreich, wenn Sie eine vorhandene Applikation in Kubernetes oder während Disaster-Recovery-Szenarien portieren.
Wenn Sie die ONTAP und solidfire-san
Treiber verwenden, importieren Sie ein vorhandenes Volume mit dem Befehl tridentctl import volume <backend-name> <volume-name> -f /path/pvc.yaml
in Kubernetes, das von Astra Trident gemanagt werden soll. Die im Befehl „Importvolumen“ verwendete PVC-YAML- oder JSON-Datei weist auf eine Storage-Klasse hin, die Astra Trident als bereitstellung identifiziert. Stellen Sie bei Verwendung eines NetApp HCI/SolidFire Backend sicher, dass die Volume-Namen eindeutig sind. Wenn die Volume-Namen dupliziert sind, klonen Sie das Volume auf einen eindeutigen Namen, sodass die Funktion zum Importieren des Volumes zwischen diesen Namen unterscheiden kann.
Wenn der azure-netapp-files
Treiber oder gcp-cvs
verwendet wird, importieren Sie das Volume mit dem Befehl tridentctl import volume <backend-name> <volume path> -f /path/pvc.yaml
in Kubernetes, das von Astra Trident gemanagt werden soll. Dadurch wird eine eindeutige Volumenreferenz sichergestellt.
Wenn der obige Befehl ausgeführt wird, wird Astra Trident das Volume auf dem Backend finden und seine Größe lesen. Die Volume-Größe der konfigurierten PVC wird automatisch hinzugefügt (und bei Bedarf überschrieben). Astra Trident erstellt dann das neue PV und Kubernetes bindet die PVC an das PV.
Wenn ein Container so eingesetzt wurde, dass er das spezifische importierte PVC benötigt, bleibt er in einem ausstehenden Zustand, bis das PVC/PV-Paar über den Volumenimport gebunden ist. Nachdem das PVC/PV-Paar gebunden ist, sollte der Behälter aufstehen, sofern keine anderen Probleme auftreten.
OpenShift Services implementieren
Die Cluster-Services OpenShift mit großem Mehrwert bieten Clusteradministratoren und den gehosteten Applikationen wichtige Funktionen. Der Storage, den diese Services nutzen, kann mithilfe der Node-lokalen Ressourcen bereitgestellt werden. Dadurch wird jedoch häufig die Kapazität, Performance, Wiederherstellbarkeit und die Nachhaltigkeit des Service begrenzt. Die Nutzung eines Enterprise-Speicher-Arrays zur Bereitstellung der Kapazität für diese Services kann einen erheblich verbesserten Service ermöglichen. OpenShift und die Speicheradministratoren sollten jedoch eng zusammenarbeiten, um die besten Optionen für die einzelnen zu bestimmen. Die Red hat-Dokumentation sollte intensiv genutzt werden, um die Anforderungen zu ermitteln und sicherzustellen, dass die Anforderungen hinsichtlich Größe und Leistung erfüllt werden.
Registry-Service
Die Bereitstellung und Verwaltung von Speicher für die Registrierung wurde im dokumentiert"netapp.io""Blog".
Protokollierungsservice
Wie andere OpenShift-Services wird auch der Protokollierungsservice mithilfe von Ansible implementiert. Die Konfigurationsparameter werden von der Inventardatei, auch als Hosts bekannt, bereitgestellt für das Playbook. Es gibt zwei Installationsmethoden: Die Bereitstellung von Protokollierung während der ersten OpenShift-Installation und die Bereitstellung von Protokollierung nach der Installation von OpenShift.
Ab Red hat OpenShift Version 3.9 empfiehlt die offizielle Dokumentation gegen NFS für den Protokollierungsservice, da sie Bedenken hinsichtlich Datenbeschädigung hat. Dies basiert auf Red hat Tests ihrer Produkte. Der ONTAP NFS-Server weist diese Probleme nicht auf und kann problemlos eine Protokollierungsbereitstellung zurücksichern. Letztendlich liegt die Wahl des Protokolls für den Protokollierungsservice bei Ihnen. Ich weiß nur, dass beide bei der Nutzung von NetApp Plattformen hervorragend funktionieren. Es gibt keinen Grund, NFS zu vermeiden, wenn dies Ihre Präferenz ist. |
Wenn Sie NFS mit dem Protokollierungsdienst verwenden, müssen Sie die Ansible-Variable so einstellen openshift_enable_unsupported_configurations
, dass true
das Installationsprogramm nicht fehlschlägt.
Los geht's
Der Protokollierungsservice kann optional sowohl für Applikationen als auch für die Kernvorgänge des OpenShift-Clusters selbst implementiert werden. Wenn Sie sich für die Bereitstellung von Operationen entscheiden, werden durch Angabe der Variable openshift_logging_use_ops
als true
zwei Instanzen des Dienstes erstellt. Die Variablen, die die Protokollierungsinstanz für Vorgänge steuern, enthalten darin "OPS", während die Instanz für Anwendungen nicht.
Das Konfigurieren der Ansible-Variablen gemäß der Implementierungsmethode ist wichtig, um sicherzustellen, dass der richtige Storage von den zugrunde liegenden Services verwendet wird. Betrachten wir nun die Optionen für die einzelnen Bereitstellungsmethoden.
Die folgenden Tabellen enthalten nur die für die Speicherkonfiguration relevanten Variablen, die sich auf den Protokollierungsservice beziehen. Sie können andere Optionen finden, in "Logging-Dokumentation von redhat OpenShift" denen Sie entsprechend Ihrer Bereitstellung prüfen, konfigurieren und verwenden sollten. |
Die Variablen in der folgenden Tabelle führen dazu, dass im Ansible-Playbook ein PV und eine PVC für den Protokollierungsservice erstellt werden. Diese Details werden verwendet. Diese Methode ist wesentlich weniger flexibel als nach der Installation von OpenShift das Playbook für die Komponenteninstallation zu verwenden. Wenn Sie jedoch vorhandene Volumes zur Verfügung haben, ist dies eine Option.
Variabel | Details |
---|---|
|
Legen Sie fest |
|
Der Hostname oder die IP-Adresse des NFS-Hosts. Diese Einstellung sollte auf die Daten-LIF für Ihre Virtual Machine eingestellt sein. |
|
Der Mount-Pfad für den NFS-Export. Wenn das Volume beispielsweise als verbunden ist, |
|
Der Name, z. B. |
|
Die Größe des NFS-Exports, zum Beispiel |
Wenn Ihr OpenShift-Cluster bereits ausgeführt wird und daher Trident implementiert und konfiguriert wurde, kann das Installationsprogramm die Volumes mithilfe der dynamischen Provisionierung erstellen. Die folgenden Variablen müssen konfiguriert werden.
Variabel | Details |
---|---|
|
Setzen Sie auf „true“, um dynamisch bereitgestellte Volumes zu verwenden. |
|
Der Name der Speicherklasse, die in der PVC verwendet wird. |
|
Die Größe des im PVC angeforderten Volumens. |
|
Ein Präfix für die vom Protokollierungsservice verwendeten VES. |
|
Legen Sie fest |
|
Der Name der Speicherklasse für die OPS-Protokollierungsinstanz. |
|
Die Größe der Volume-Anforderung für die OPS-Instanz. |
|
Ein Präfix für die OPS-Instanz VES. |
Bereitstellen des Protokollierungs-Stacks
Wenn Sie die Protokollierung als Teil des ursprünglichen OpenShift-Installationsprozesses bereitstellen, müssen Sie nur den Standardprozess für die Bereitstellung befolgen. Ansible konfiguriert und implementiert die erforderlichen Services und OpenShift-Objekte, sodass der Service sobald Ansible abgeschlossen ist.
Wenn Sie die Implementierung jedoch nach der Erstinstallation durchführen, muss das Komponenten-Playbook von Ansible verwendet werden. Dieser Vorgang kann sich bei verschiedenen Versionen von OpenShift geringfügig ändern. Lesen Sie daher unbedingt "Dokumentation der redhat OpenShift Container Platform 3.11"die Informationen zu Ihrer Version.
Kennzahlungsservice
Der Kennzahlungsservice liefert dem Administrator wertvolle Informationen zum Status, zur Ressourcenauslastung und zur Verfügbarkeit des OpenShift-Clusters. Dies ist zudem für die automatische Pod-Funktionalität erforderlich, und viele Unternehmen nutzen die Daten des Kennzahlungsservice für ihre Kostenabrechnung und/oder die Anzeige von Applikationen.
Wie beim Protokollierungsservice und OpenShift als Ganzes wird auch Ansible für die Implementierung des Kennzahlungsservice verwendet. Ebenso wie der Protokollierungsservice kann der Metrikservice während der ersten Einrichtung des Clusters oder nach dessen Betrieb mithilfe der Installationsmethode für Komponenten bereitgestellt werden. Die folgenden Tabellen enthalten die Variablen, die für die Konfiguration von persistentem Storage für den Kennzahlungsservice wichtig sind.
Die nachfolgenden Tabellen enthalten nur die Variablen, die für die Storage-Konfiguration relevant sind, da sie sich auf den Kennzahlenservice beziehen. Es gibt viele andere Optionen in der Dokumentation gefunden, die entsprechend Ihrer Bereitstellung überprüft, konfiguriert und verwendet werden sollten. |
Variabel | Details |
---|---|
|
Legen Sie fest |
|
Der Hostname oder die IP-Adresse des NFS-Hosts. Diese Einstellung sollte auf die Daten-LIF für Ihre SVM eingestellt sein. |
|
Der Mount-Pfad für den NFS-Export. Wenn das Volume beispielsweise als verbunden ist, |
|
Der Name, z. B. |
|
Die Größe des NFS-Exports, zum Beispiel |
Wenn Ihr OpenShift-Cluster bereits ausgeführt wird und daher Trident implementiert und konfiguriert wurde, kann das Installationsprogramm die Volumes mithilfe der dynamischen Provisionierung erstellen. Die folgenden Variablen müssen konfiguriert werden.
Variabel | Details |
---|---|
|
Ein Präfix, das für die PVCs der Kennzahlen verwendet wird. |
|
Die Größe der Volumes, die angefordert werden sollen. |
|
Der Storage-Typ, der für Metriken verwendet werden soll. Dieser muss für Ansible auf dynamisch festgelegt sein, um PVCs mit der entsprechenden Storage-Klasse zu erstellen. |
|
Der Name der zu verwendenden Speicherklasse. |
Bereitstellen des Kennzahlenservice
Implementieren Sie den Service mithilfe von Ansible, wenn Sie die entsprechenden Ansible-Variablen in der Host-/Inventardatei festlegen. Wenn Sie zur Installationszeit OpenShift bereitstellen, wird das PV automatisch erstellt und verwendet. Wenn Sie mit den Komponenten-Playbooks implementieren, erstellt Ansible nach der Installation von OpenShift alle erforderlichen PVCs. Nachdem Astra Trident Storage für sie bereitgestellt hat, kann der Service implementiert werden.
Die oben genannten Variablen und der Prozess für die Bereitstellung können sich mit jeder Version von OpenShift ändern. Überprüfen und befolgen Sie "Der OpenShift-Implementierungsleitfaden von Red hat"Ihre Version, damit sie für Ihre Umgebung konfiguriert ist.