Die deutsche Sprachversion wurde als Serviceleistung für Sie durch maschinelle Übersetzung erstellt. Bei eventuellen Unstimmigkeiten hat die englische Sprachversion Vorrang.

Red Hat OpenShift Service auf AWS mit NetApp ONTAP

08/18/2025 Beitragende

PDFs

Überblick

In diesem Abschnitt zeigen wir, wie FSx für ONTAP als persistente Speicherschicht für auf ROSA ausgeführte Anwendungen genutzt wird. Es wird die Installation des NetApp Trident CSI-Treibers auf einem ROSA-Cluster, die Bereitstellung eines FSx für ONTAP -Dateisystems und die Bereitstellung einer Beispielanwendung mit Status gezeigt. Außerdem werden Strategien zum Sichern und Wiederherstellen Ihrer Anwendungsdaten gezeigt. Mit dieser integrierten Lösung können Sie ein gemeinsam genutztes Speicherframework einrichten, das sich mühelos über AZs skalieren lässt und die Prozesse der Skalierung, des Schutzes und der Wiederherstellung Ihrer Daten mithilfe des Trident CSI-Treibers vereinfacht.

Voraussetzungen

"AWS-Konto"
"Ein Red Hat-Konto"
IAM-Benutzer"mit entsprechenden Berechtigungen" zum Erstellen und Zugreifen auf den ROSA-Cluster
"AWS CLI"
"ROSA CLI"
"OpenShift-Befehlszeilenschnittstelle"(oc)
Helm 3"Dokumentation"
"Ein HCP ROSA-Cluster"
"Zugriff auf die Red Hat OpenShift-Webkonsole"

Dieses Diagramm zeigt den in mehreren AZs bereitgestellten ROSA-Cluster. Die Masterknoten und Infrastrukturknoten des ROSA-Clusters befinden sich im VPC von Red Hat, während sich die Worker-Knoten in einem VPC im Konto des Kunden befinden. Wir erstellen ein FSx für ONTAP Dateisystem innerhalb derselben VPC und installieren den Trident -Treiber im ROSA-Cluster, sodass alle Subnetze dieser VPC eine Verbindung zum Dateisystem herstellen können.

Rosa Architektur

Ersteinrichtung

1. Bereitstellung von FSx für NetApp ONTAP

Erstellen Sie ein Multi-AZ FSx für NetApp ONTAP in derselben VPC wie der ROSA-Cluster. Hierzu gibt es mehrere Möglichkeiten. Die Details zur Erstellung von FSxN mit einem CloudFormation Stack werden bereitgestellt

a.Klonen Sie das GitHub-Repository

$ git clone https://github.com/aws-samples/rosa-fsx-netapp-ontap.git

b. Führen Sie den CloudFormation-Stack aus. Führen Sie den folgenden Befehl aus, indem Sie die Parameterwerte durch Ihre eigenen Werte ersetzen:

$ cd rosa-fsx-netapp-ontap/fsx

$ aws cloudformation create-stack \
  --stack-name ROSA-FSXONTAP \
  --template-body file://./FSxONTAP.yaml \
  --region <region-name> \
  --parameters \
  ParameterKey=Subnet1ID,ParameterValue=[subnet1_ID] \
  ParameterKey=Subnet2ID,ParameterValue=[subnet2_ID] \
  ParameterKey=myVpc,ParameterValue=[VPC_ID] \
ParameterKey=FSxONTAPRouteTable,ParameterValue=[routetable1_ID,routetable2_ID] \
  ParameterKey=FileSystemName,ParameterValue=ROSA-myFSxONTAP \
  ParameterKey=ThroughputCapacity,ParameterValue=1024 \
  ParameterKey=FSxAllowedCIDR,ParameterValue=[your_allowed_CIDR] \
  ParameterKey=FsxAdminPassword,ParameterValue=[Define Admin password] \
  ParameterKey=SvmAdminPassword,ParameterValue=[Define SVM password] \
  --capabilities CAPABILITY_NAMED_IAM

Wobei: Regionsname: identisch mit der Region, in der der ROSA-Cluster bereitgestellt wird. Subnet1_ID: ID des bevorzugten Subnetzes für FSxN. Subnet2_ID: ID des Standby-Subnetzes für FSxN. VPC_ID: ID der VPC, in der der ROSA-Cluster bereitgestellt wird. Routetable1_ID, Routetable2_ID: IDs der Routentabellen, die mit den oben ausgewählten Subnetzen verknüpft sind. Your_allowed_CIDR: zulässiger CIDR-Bereich für die Eingangsregeln der FSx for ONTAP Sicherheitsgruppen zur Zugriffskontrolle. Sie können 0.0.0.0/0 oder ein beliebiges geeignetes CIDR verwenden, um dem gesamten Datenverkehr den Zugriff auf die spezifischen Ports von FSx für ONTAP zu ermöglichen. Administratorkennwort definieren: Ein Kennwort zum Anmelden bei FSxN. SVM-Kennwort definieren: Ein Kennwort zum Anmelden bei SVM, das erstellt wird.

Überprüfen Sie, ob Ihr Dateisystem und Ihre virtuelle Speichermaschine (SVM) mithilfe der Amazon FSx Konsole erstellt wurden, wie unten gezeigt:

FSxN erstellt

2. Installieren und konfigurieren Sie den Trident CSI-Treiber für den ROSA-Cluster

b.Trident Trident

ROSA-Cluster-Workerknoten sind mit NFS-Tools vorkonfiguriert, die Ihnen die Verwendung von NAS-Protokollen für die Speicherbereitstellung und den Speicherzugriff ermöglichen.

Wenn Sie stattdessen iSCSI verwenden möchten, müssen Sie die Worker-Knoten für iSCSI vorbereiten. Ab der Trident Version 25.02 können Sie die Worker-Knoten des ROSA-Clusters (oder eines beliebigen OpenShift-Clusters) problemlos für die Durchführung von iSCSI-Vorgängen auf FSxN-Speicher vorbereiten. Es gibt zwei einfache Möglichkeiten, Trident 25.02 (oder höher) zu installieren, das die Vorbereitung des Worker-Knotens für iSCSI automatisiert. 1. Verwenden Sie das Node-Prep-Flag über die Befehlszeile mit dem Tool Tridentctl. 2. Verwenden Sie den von Red Hat zertifizierten Trident Operator vom Operator-Hub und passen Sie ihn an. 3. Helm verwenden.

Wenn Sie eine der oben genannten Methoden verwenden, ohne die Knotenvorbereitung zu aktivieren, können Sie für die Bereitstellung von Speicher auf FSxN nur NAS-Protokolle verwenden.

Methode 1: Verwenden Sie das Tool tridentctl

Verwenden Sie das Node-Prep-Flag und installieren Sie Trident wie gezeigt. Bevor Sie den Installationsbefehl ausführen, sollten Sie das Installationspaket heruntergeladen haben. Weitere Informationen finden Sie unter "die Dokumentation hier" .

#./tridentctl install trident -n trident --node-prep=iscsi

Methode 2: Verwenden Sie den Red Hat Certified Trident Operator und passen Sie ihn an. Suchen Sie im OperatorHub den Red Hat Certified Trident Operator und installieren Sie ihn.

Operator im Operator Hub

Operator 1 installieren

Operator 2 installieren

Bediener installiert

Erstellen Sie als Nächstes die Trident Orchestrator-Instanz. Verwenden Sie die YAML-Ansicht, um benutzerdefinierte Werte festzulegen oder die iscsi-Knotenvorbereitung während der Installation zu aktivieren.

Orchestrator erstellen

NodePrep aktivieren

Orchestrator installiert

Trident installiert

Durch die Installation von Trident mit einer der oben genannten Methoden werden die ROSA-Cluster-Worker-Knoten für iSCSI vorbereitet, indem die Dienste iscsid und multipathd gestartet und Folgendes in der Datei /etc/multipath.conf festgelegt wird

iscsid aktiv

Multipathd aktiv

Datei „multipath.conf“

c.Überprüfen Sie, ob alle Trident Pods im laufenden Zustand sind.

Trident -Kapseln laufen

3. Konfigurieren Sie das Trident CSI-Backend für die Verwendung von FSx für ONTAP (ONTAP NAS)

Die Trident Back-End-Konfiguration teilt Trident mit, wie mit dem Speichersystem (in diesem Fall FSx für ONTAP) kommuniziert werden soll. Zum Erstellen des Backends stellen wir die Anmeldeinformationen der Storage Virtual Machine bereit, mit der eine Verbindung hergestellt werden soll, sowie die Clusterverwaltung und die NFS-Datenschnittstellen. Wir verwenden die"ontap-nas-Treiber" um Speichervolumes im FSx-Dateisystem bereitzustellen.

A. Erstellen Sie zunächst ein Geheimnis für die SVM-Anmeldeinformationen mit dem folgenden YAML

apiVersion: v1
kind: Secret
metadata:
  name: backend-fsx-ontap-nas-secret
  namespace: trident
type: Opaque
stringData:
  username: vsadmin
  password: <value provided for Define SVM password as a parameter to the Cloud Formation Stack>

Sie können das für FSxN erstellte SVM-Passwort auch wie unten gezeigt vom AWS Secrets Manager abrufen.

AWS-Geheimnismanager

Geheimnis abrufen

b.Fügen Sie als Nächstes mit dem folgenden Befehl das Geheimnis für die SVM-Anmeldeinformationen zum ROSA-Cluster hinzu

$ oc apply -f svm_secret.yaml

Sie können mit dem folgenden Befehl überprüfen, ob das Geheimnis im Trident-Namespace hinzugefügt wurde

$ oc get secrets -n trident |grep backend-fsx-ontap-nas-secret

Geheimnis angewendet

C. Erstellen Sie als Nächstes das Backend-Objekt. Wechseln Sie dazu in das Verzeichnis fsx Ihres geklonten Git-Repositorys. Öffnen Sie die Datei backend-ontap-nas.yaml. Ersetzen Sie Folgendes: managementLIF durch den Management-DNS-Namen, dataLIF durch den NFS-DNS-Namen der Amazon FSx SVM und svm durch den SVM-Namen. Erstellen Sie das Backend-Objekt mit dem folgenden Befehl.

Erstellen Sie das Backend-Objekt mit dem folgenden Befehl.

$ oc apply -f backend-ontap-nas.yaml

Sie können den Management-DNS-Namen, den NFS-DNS-Namen und den SVM-Namen von der Amazon FSx Konsole abrufen, wie im folgenden Screenshot gezeigt

hol dir Leben

D. Führen Sie nun den folgenden Befehl aus, um zu überprüfen, ob das Backend-Objekt erstellt wurde und die Phase „Gebunden“ und der Status „Erfolgreich“ anzeigt.

Backend erstellen

4. Speicherklasse erstellen Nachdem das Trident Backend konfiguriert ist, können Sie eine Kubernetes-Speicherklasse erstellen, um das Backend zu verwenden. Die Speicherklasse ist ein Ressourcenobjekt, das dem Cluster zur Verfügung gestellt wird. Es beschreibt und klassifiziert den Speichertyp, den Sie für eine Anwendung anfordern können.

A. Überprüfen Sie die Datei storage-class-csi-nas.yaml im Ordner fsx.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: trident-csi
provisioner: csi.trident.netapp.io
parameters:
  backendType: "ontap-nas"
  fsType: "ext4"
allowVolumeExpansion: True
reclaimPolicy: Retain

B. Erstellen Sie eine Speicherklasse im ROSA-Cluster und überprüfen Sie, ob die Speicherklasse Trident-CSI erstellt wurde.

Backend erstellen

Damit ist die Installation des Trident CSI-Treibers und seine Verbindung zum FSx für das ONTAP Dateisystem abgeschlossen. Jetzt können Sie eine Beispielanwendung mit PostgreSQL-Status auf ROSA mithilfe von Dateivolumes auf FSx für ONTAP bereitstellen.

C. Stellen Sie sicher, dass keine PVCs und PVs mit der Speicherklasse Trident-CSI erstellt wurden.

keine PVCs mit Trident

D. Überprüfen Sie, ob Anwendungen mit Trident CSI PV erstellen können.

Erstellen Sie ein PVC mit der Datei pvc-trident.yaml im Ordner fsx.

pvc-trident.yaml
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: basic
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 10Gi
  storageClassName: trident-csi

 You can issue the following commands to create a pvc and verify that it has been created.
image:redhat-openshift-container-rosa-011.png["Erstellen Sie Test-PVC mit Trident"]

Um iSCSI zu verwenden, sollten Sie iSCSI wie zuvor gezeigt auf den Worker-Knoten aktiviert haben und ein iSCSI-Backend und eine Speicherklasse erstellen. Hier sind einige Beispieldateien im YAML-Format.

cat tbc.yaml
apiVersion: v1
kind: Secret
metadata:
  name: backend-tbc-ontap-san-secret
type: Opaque
stringData:
  username: fsxadmin
  password: <password for the fsxN filesystem>
---
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: backend-tbc-ontap-san
spec:
  version: 1
  storageDriverName: ontap-san
  managementLIF: <management lif of fsxN filesystem>
  backendName: backend-tbc-ontap-san
  svm: svm_FSxNForROSAiSCSI
  credentials:
    name: backend-tbc-ontap-san-secret

cat sc.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: trident-csi
provisioner: csi.trident.netapp.io
parameters:
  backendType: "ontap-san"
  media: "ssd"
  provisioningType: "thin"
  snapshots: "true"
allowVolumeExpansion: true

5. Stellen Sie eine Beispielanwendung mit PostgreSQL-Status bereit

A. Verwenden Sie Helm, um PostgreSQL zu installieren

$ helm install postgresql bitnami/postgresql -n postgresql --create-namespace

PostgreSQL installieren

B. Stellen Sie sicher, dass der Anwendungs-Pod ausgeführt wird und ein PVC und PV für die Anwendung erstellt wurde.

PostgreSQL-Pods

PostgreSQL-PVC

postgresql pv

C. Stellen Sie einen Postgresql-Client bereit

Verwenden Sie den folgenden Befehl, um das Kennwort für den installierten PostgreSQL-Server abzurufen.

$ export POSTGRES_PASSWORD=$(kubectl get secret --namespace postgresql postgresql -o jsoata.postgres-password}" | base64 -d)

Verwenden Sie den folgenden Befehl, um einen PostgreSQL-Client auszuführen und mit dem Kennwort eine Verbindung zum Server herzustellen

$ kubectl run postgresql-client --rm --tty -i --restart='Never' --namespace postgresql --image docker.io/bitnami/postgresql:16.2.0-debian-11-r1 --env="PGPASSWORD=$POSTGRES_PASSWORD" \
> --command -- psql --host postgresql -U postgres -d postgres -p 5432

PostgreSQL-Client