Gatekeeper mit Red Hat OpenShift oder Upstream-Kubernetes

Zusammenfassung: In diesem Wissensdatenbank-Artikel wird erläutert, wie Sie das Red Hat GitHub-Repository kubevirt-rawio-addon verwenden, um PowerMax Gatekeeper entweder in einer Red Hat OpenShift- oder einer Upstream-Kubernetes-Umgebung zu präsentieren. ...

Dieser Artikel gilt für Dieser Artikel gilt nicht für Dieser Artikel ist nicht an ein bestimmtes Produkt gebunden. In diesem Artikel werden nicht alle Produktversionen aufgeführt.
Andere Ressourcen ansehen

Weisungen

PowerMax-Gatekeeper

PowerMax-Gatekeeper sind kleine Geräte (in der Regel drei MB), die von Festplatten im PowerMax erstellt werden und als SCSI-Ziele für Solutions Enabler-Befehle fungieren. Konfigurations- und Statusinformationen werden standardmäßig in einer PowerMax-Hostdatenbankdatei symapi_db.bin. Sie wird als PowerMax-Konfigurationsdatenbank bezeichnet. Dies reduziert die Anzahl der Anfragen vom Host an die Storage-Arrays. Gatekeeper müssen Raw-Geräte sein, damit das Betriebssystem die SCSI-Befehle einfach und ohne Manipulation übergibt. Während physische Hosts immer mit Gatekeepern (mit einem unterstützten Betriebssystem) arbeiten, sind virtuelle Hosts auf VMware mit physischen RDMs (Raw Device Mappings), In-Guest-iSCSI unter Windows oder Linux, In-Guest-NVMe/TCP unter Linux oder Passthrough-Geräten (NIC oder HBA) beschränkt. Nur VMware kann jedoch ein echtes Rohgerät präsentieren, das als praktikabler Gatekeeper erkannt wird. Andere Virtualisierungslösungen ermöglichen es dem Nutzer, Geräte als "roh" darzustellen, aber ihre Lösungen blockieren einige SCSI-Befehle und verhindern so ihre Verwendung als Gatekeeper. Solutions Enabler kennzeichnet sie als Gatekeeper, meldet aber einen Fehler wie unten.

Wenn Sie die Gatekeeper untersuchen, wird außerdem der Status "CLS" oder "closed" angezeigt.

Daher können Sie die erforderlichen SCSI-Befehle nicht übergeben.

Um diese Lösung nutzen zu können, müssen Sie ein Protokoll verwenden, das Solutions Enabler auf dem ausgewählten Betriebssystem unterstützt. Weitere Informationen finden Sie in der Produktdokumentation.

Red Hat GitHub-Lösung

Dell bat Red Hat um Unterstützung bei der Entwicklung eines Workarounds für Gatekeeper in einer OpenShift-Umgebung für einige unserer gemeinsamen Kunden. Zu diesem Zweck haben sie eine Lösung entwickelt, die sowohl für OpenShift als auch für Upstream-Kubernetes funktioniert, mit leichten Variationen in der Implementierung. Das GitHub-Repository heißt kubevirt-rawio-addon und befindet sich hier: https://github.com/openshift-cnv/kubevirt-rawio-addon Das GitHub enthält eine Readme-https://github.com/openshift-cnv/kubevirt-rawio-addon/blob/main/README.md.

Das Add-on installiert mehrere Komponenten:

  • Ändern von Webhooks zum Ändern von Objekten im laufenden Betrieb
  • Webhook wird validiert – eine OpenShift-spezifische Sicherheitsprüfung
  • Sicherheitskonfiguration zum Zulassen privilegierter Funktionen
  • Sidecar-Haken 

Der Sidecar ist ein kleiner zusätzlicher Container, der neben dem VM-Pod ausgeführt wird und die Low-Level-Konfiguration der VM ändert, bevor er gestartet wird. Es fängt die von KubeVirt generierte VM-Konfiguration ab, sucht die annotierten Festplatten und legt rawio=yes fest. KubeVirt ruft dann den XML-Code zurück. Die zugrundeliegende libvirt/QEMU-Architektur unterstützt dies, stellt es aber nicht zur Verfügung, so dass diese geringfügige Anpassung erforderlich ist. Es ist möglich, dass KubeVirt dies in Zukunft verfügbar macht, dann wird der Workaround unnötig sein.


  
Implementierung auf OpenShift

  
Das Repository enthält alle Anweisungen für die Implementierung dieser Lösung. Da Red Hat Eigentümer der Lösung ist, empfiehlt Dell, die aktuellen Anweisungen zu befolgen, die sich in Zukunft ändern können.  Dell aktualisiert den Wissensdatenbank-Artikel nicht, um diese Änderungen widerzuspiegeln. Der Höflichkeit halber stellen wir die folgenden grundlegenden Informationen zur Verfügung, empfehlen jedoch Nutzern dieses Wissensdatenbank-Artikels, diese zusammen mit dem Repository zu verwenden.

  
Wie bereits erwähnt, können Sie dies auf OpenShift oder Upstream-Kubernetes implementieren. Da die Schritte für OpenShift durchgeführt werden, gibt es einige Punkte, die bei Upstream-Kubernetes zu beachten sind.

  
    
   
  • Wenn Sie auf Vanilla K8s implementieren, muss cert-manager installiert sein. Wenn der PowerMax CSI-Treiber installiert ist, ist dieser vorhanden
    • 
   
  • Wenn Sie auf Vanilla K8s implementieren, benötigen Sie einen privilegierten Namespace. Sie können den Namespace in den Skripten verwenden oder einen eigenen erstellen und die Skripte dann ändern.
    • 
  

  
Die beiden Skripte, die Sie für die Implementierung benötigen, befinden sich im Hack-Ordner . Das rawio-setup.sh ist das erste Skript und ist für beide Plattformen identisch, aber beachten Sie, dass es auf dem openshift-cnv-Namespace basiert, der nur auf OpenShift vorhanden ist. Fügen Sie den Namespace hinzu oder erstellen Sie einen neuen und ändern Sie das Skript für K8s. Das VM-Erstellungsskript ist für die Plattform eindeutig, verwendet aber auch hier den openshift-cnv-Namespace. Bei OpenShift ist dies rawio-create-vm-openshift.sh. Die Skripte sind für die Erstellung einer Testumgebung konzipiert und müssen für eine Produktionseinrichtung geändert werden. Insbesondere erstellt das rawio-setup.sh Skript ein virtuelles SCSI-Gerät. Ändern Sie stattdessen das Skript so, dass es Ihre PowerMax-Storage-Klasse verwendet. Darüber hinaus geht das Skript von einem einzelnen Node für die Planung der VM aus. Ändern Sie ihn, damit er auf jedem Worker-Node ausgeführt werden kann. Das Skript verwendet ein vorinstalliertes Fedora-Betriebssystem.

  
Beispielskripte finden Sie unter Ergänzende Inhalte.

  
Grundlegende Schritte

  
  
Beachten Sie, dass die PowerMax-CSI kein Gerät erstellen kann, das kleiner als 50 MB ist, selbst wenn Sie einen herkömmlichen 3-MB-Gatekeeper anfordern. Es verursacht kein Problem.

  

  

  
Andere Virtualisierungslösungen

  
Keine der folgenden Lösungen funktioniert mit diesem Red Hat-Repository.

  
    
   
  • K8s-basierte Lösungen wie SUSE Harvester – SUSE muss eigene Lösung entwickeln
    • 
   
  • KVM-Lösungen wie Proxmox oder Oracle KVM (oVirt) - diese sind nicht KubeVirt-basiert und können nicht verwendet werden
    • 
  

  

   

   

  

  
 

                
Weitere Informationen

        
rawio-setup.sh

  
 

  

   #!/bin/bash
  

  
 

  

   set -euo pipefail
  

  
 

  

   if [ -z "${KUBEVIRT_NAMESPACE:-}" ]; Dann
  

  

     Wenn kubectl ns openshift-cnv &>/dev/null; erhält, dann
  

  

       NAMESPACE="openshift-cnv"
  

  

     oder
  

  

       NAMESPACE="kubevirt"
  

  

     fi
  

  

   oder
  

  

     NAMESPACE="$KUBEVIRT_NAMESPACE"
  

  

   fi
  

  
 

  

   PVC_NAMESPACE="${PVC_NAMESPACE:-default}"
  

  

   SC_NAME="PowerMax-2164-Standard"
  

  

   PVC_NAME="SCSI-RAWIO-PVC"
  

  
 

  

   # Erstellen Sie einen Namespace, wenn er nicht vorhanden ist.
  

  

   kubectl get ns "$PVC_NAMESPACE" >/dev/null 2>&1 || kubectl create ns "$PVC_NAMESPACE"
  

  
 

  

   # PVC erstellen
  

  

   echo "PVC-$PVC_NAME im Namespace $PVC_NAMESPACE erstellen..."
  

  
 

  

   kubectl apply -f – <<EOF
  

  

   apiVersion: v1
  

  

   Art: Persistenter Volume-Anspruch
  

  

   Metadaten:
  

  

     name: $PVC_NAME
  

  

     Namespace: $PVC_NAMESPACE
  

  

   Spec:
  

  

     storageClassName: $SC_NAME
  

  

     volumeMode: Sperren
  

  

     accessModes:
  

  

       - ReadWriteOnce (Einmal lesen)
  

  

     Ressourcen:
  

  

       Anforderungen:
  

  

         Speicher: 8 Meilen
  

  

   EOF
  

  
 

  

   echo ""
  

  

   echo "=== Einrichtung abgeschlossen ==="
  

  

   echo "StorageClass:   $SC_NAME"
  

  

   echo "PVC:            $PVC_NAMESPACE/$PVC_NAME"
  

  

   echo ""
  

  
 

  
*******************************************

  
rawio-create-vm-openshift.sh

  
 

  

   #!/bin/bash
  

  
 

  

   set -euo pipefail
  

  
 

  

   PVC_NAMESPACE="${PVC_NAMESPACE:-default}"
  

  

   PVC_NAME="${PVC_NAME:-scsi-rawio-pvc}"
  

  

   VM_NAME="${VM_NAME:-rawio-test-vm}"
  

  

   VM_SA="${VM_SA:-rawio-vm}"
  

  

   CONTAINER_DISK="${CONTAINER_DISK:-quay.io/kubevirt/fedora-with-testtooling:v20240717-a087e7e}"
  

  

   SCC_NAME="${SCC_NAME:-rawio-vm}"
  

  

   KUBEVIRT_NAMESPACE="OpenShift-CNV"
  

  
 

  

   echo "ServiceAccount $VM_SA im Namespace $PVC_NAMESPACE erstellen"
  

  
 

  

   kubectl apply -f – <<EOF
  

  

   apiVersion: v1
  

  

   Art: Serviceaccount
  

  

   Metadaten:
  

  

     name: $VM_SA
  

  

     Namespace: $PVC_NAMESPACE
  

  

   EOF
  

  
 

  

   echo "Erstellen von SCC $SCC_NAME für Servicekonto $VM_SA"
  

  
 

  

   kubectl apply -f – <<EOF
  

  

   apiVersion: security.openshift.io/v1
  

  

   Art: SecurityContextConstraints
  

  

   Metadaten:
  

  

     name: $SCC_NAME
  

  

   Priorität: 11
  

  

   allowPrivilegedContainer: false
  

  

   allowHostDirVolumePlugin: true
  

  

   allowHostNetwork: false
  

  

   allowHostPorts: false
  

  

   allowHostPID: false
  

  

   allowHostIPC: false
  

  

   allowedCapabilities:
  

  

     - NET_BIND_SERVICE
  

  

     - SYS_NICE
  

  

     - SYS_RAWIO
  

  

     - SETFCAP
  

  

   defaultAddCapabilities: []
  

  

   seccompProfiles:
  

  

     - Laufzeit/Standard
  

  

     -Unconfined
  

  

     - localhost/kubevirt/kubevirt.json
  

  

   Volumes:
  

  

     - "*"
  

  

   readOnlyRootFilesystem: false
  

  

   runAsUser:
  

  

     type: Ausführen alsAny
  

  

   seLinuxContext:
  

  

     type: Ausführen alsAny
  

  

   fsGroup:
  

  

     type: Ausführen alsAny
  

  

   supplementalGroups:
  

  

     type: Ausführen alsAny
  

  

   Benutzer:
  

  

     - System:ServiceAccount:${PVC_NAMESPACE}:${VM_SA}
  

  

   groups: []
  

  

   EOF
  

  
 

  

   echo "Erstellen von VM $VM_NAME im Namensraum $PVC_NAMESPACE"
  

  

   echo "PVC:               $PVC_NAME"
  

  

   echo "ServiceAccount:    $VM_SA"
  

  

   echo "Container-Festplatte:    $CONTAINER_FESTPLATTE
  

  
 

  

   kubectl apply -f – <<EOF
  

  

   apiVersion: kubevirt.io/v1
  

  

   Art: Virtuelle Maschine
  

  

   Metadaten:
  

  

     name: $VM_NAME
  

  

     Namespace: $PVC_NAMESPACE
  

  

     Anmerkungen:
  

  

       kubevirt.io/rawioSupport: "lun0"
  

  

   Spec:
  

  

     Ausführen: true
  

  

     Vorlage:
  

  

       Metadaten:
  

  

         Anmerkungen:
  

  

           kubevirt.io/rawioSupport: "lun0"
  

  

       Spec:
  

  

         Domäne:
  

  

           Cpu:
  

  

             Kerne: 2
  

  

           Ressourcen:
  

  

             Anforderungen:
  

  

               Speicher: 2Gi
  

  

           Geräte:
  

  

             Rng: {}
  

  

             Datenträger:
  

  

               - Name: disk0
  

  

                 Datenträger:
  

  

                   Bus: Virtio
  

  

               - Name: LUN0
  

  

                 Lun:
  

  

                   Bus: SCSI
  

  

               -Namen: $VM_SA
  

  

                 Datenträger:
  

  

                   Bus: Virtio
  

  

         Volumes:
  

  

           - Name: disk0
  

  

             containerDisk:
  

  

               Bild: $CONTAINER_FESTPLATTE
  

  

           - Name: LUN0
  

  

             persistentVolumeClaim:
  

  

               claimName: $PVC_NAME
  

  

           -Namen: $VM_SA
  

  

             Serviceaccount:
  

  

               serviceAccountName: $VM_SA
  

  

   EOF
  

  
 

  

   echo ""
  

  

   echo "VM $VM_NAME erstellt. Ich warte darauf, dass es anfängt..."
  

  

   echo "Überwachen mit: kubectl get vmi -n $PVC_NAMESPACE $VM_NAME -w"
  

  

   echo "Konsole:    virtctl console -n $PVC_NAMESPACE $VM_NAME"
  

  

   echo ""
  

  

   echo "Aufräumen:"
  

  

   echo " kubectl delete vm -n $PVC_NAMESPACE $VM_NAME"
  

  

   echo " kubectl delete scc $SCC_NAME"
  




        

        
        
Betroffene Produkte

        PowerMax, PowerMax, PowerMax 2000, PowerMax 2500, PowerMax 8000, PowerMax 8500, PowerMaxOS 10







                        

                            

    

        

            

                
                    
 Artikeleigenschaften

                
            

            

                

                        
Artikelnummer: 000472526

                

                
                

                        
Artikeltyp: How To

                

                

                        
Zuletzt geändert: 03 Juni 2026


                

                    

                            
Version:  1

                    


            


        

    

    

        

            

                
                    
Antworten auf Ihre Fragen erhalten Sie von anderen Dell NutzerInnen

                
            

            

                

                    
                



            


        

    

    

        

            

                
                    
Support Services

                
            

            

                

                    Prüfen Sie, ob Ihr Gerät durch Support Services abgedeckt ist.