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

Konfigurieren Sie ein NetApp HCI- oder SolidFire-Backend

Beitragende
PDFs

Erfahren Sie, wie Sie mit Ihrer Trident Installation ein Element Backend erstellen und verwenden.

Details zum Elementtreiber

Trident stellt den solidfire-san Speichertreiber für die Kommunikation mit dem Cluster bereit. Unterstützte Zugriffsmodi sind: ReadWriteOnce (RWO), ReadOnly Many (ROX), ReadWriteMany (RWX), ReadWriteOncePod (RWOP).

Der solidfire-san Speichertreiber unterstützt die Volume-Modi File und Block. Für den Filesystem Volumemodus erstellt Trident ein Volume und ein Dateisystem. Der Dateisystem-Typ wird von StorageClass angegeben.

Treiber Protokoll VolumeMode Unterstützte Zugriffsmodi Unterstützte Filesysteme

solidfire-san

ISCSI

Block-Storage

RWO, ROX, RWX, RWOP

Kein Dateisystem. Rohes Blockgerät.

solidfire-san

ISCSI

Dateisystem

RWO, RWOP

xfs, ext3, ext4

Bevor Sie beginnen

Sie benötigen Folgendes, bevor Sie ein Element-Backend erstellen.

  • Ein unterstütztes Storage-System, auf dem die Element Software ausgeführt wird.

  • Anmeldedaten für einen NetApp HCI/SolidFire Cluster-Administrator oder einen Mandantenbenutzer, der Volumes managen kann

  • Alle Kubernetes-Worker-Nodes sollten die entsprechenden iSCSI-Tools installiert haben. Siehe "Informationen zur Vorbereitung auf den Worker-Node".

Back-End-Konfigurationsoptionen

Die Back-End-Konfigurationsoptionen finden Sie in der folgenden Tabelle:

Parameter Beschreibung Standard

version

Immer 1

storageDriverName

Name des Speichertreibers

Immer „solidfire-san“

backendName

Benutzerdefinierter Name oder das Storage-Backend

IP-Adresse „SolidFire_“ + Storage (iSCSI)

Endpoint

MVIP für den SolidFire-Cluster mit Mandanten-Anmeldedaten

SVIP

Speicher-IP-Adresse und -Port

labels

Satz willkürlicher JSON-formatierter Etiketten für Volumes.

„“

TenantName

Zu verwendende Mandantenbezeichnung (wird erstellt, wenn sie nicht gefunden wurde)

InitiatorIFace

Beschränken Sie den iSCSI-Datenverkehr auf eine bestimmte Host-Schnittstelle

„Standard“

UseCHAP

Verwenden Sie CHAP zur Authentifizierung von iSCSI. Trident verwendet CHAP.

Richtig

AccessGroups

Liste der zu verwendenden Zugriffsgruppen-IDs

Findet die ID einer Zugriffsgruppe namens „Dreizack“

Types

QoS-Spezifikationen

limitVolumeSize

Bereitstellung fehlgeschlagen, wenn die angeforderte Volume-Größe über diesem Wert liegt

„“ (nicht standardmäßig durchgesetzt)

debugTraceFlags

Fehler-Flags bei der Fehlerbehebung beheben. Beispiel: { „API“:false, „Methode“:true}

Null
Warnung Verwenden Sie es nicht debugTraceFlags Es sei denn, Sie beheben Fehler und benötigen einen detaillierten Log Dump.

Beispiel 1: Back-End-Konfiguration für solidfire-san Treiber mit drei Lautstärketypen

Dieses Beispiel zeigt eine Backend-Datei mit CHAP-Authentifizierung und Modellierung von drei Volume-Typen mit spezifischen QoS-Garantien. Sehr wahrscheinlich würden Sie dann Storage-Klassen definieren, um jeden davon mit dem zu nutzen IOPS Parameter für Storage-Klasse.

---
version: 1
storageDriverName: solidfire-san
Endpoint: https://<user>:<password>@<mvip>/json-rpc/8.0
SVIP: "<svip>:3260"
TenantName: "<tenant>"
labels:
  k8scluster: dev1
  backend: dev1-element-cluster
UseCHAP: true
Types:
- Type: Bronze
  Qos:
    minIOPS: 1000
    maxIOPS: 2000
    burstIOPS: 4000
- Type: Silver
  Qos:
    minIOPS: 4000
    maxIOPS: 6000
    burstIOPS: 8000
- Type: Gold
  Qos:
    minIOPS: 6000
    maxIOPS: 8000
    burstIOPS: 10000

Beispiel 2: Back-End- und Storage-Class-Konfiguration für solidfire-san Treiber mit virtuellen Pools

Dieses Beispiel zeigt die mit virtuellen Pools zusammen mit StorageClasses konfigurierte Back-End-Definitionsdatei.

Trident kopiert bei der Bereitstellung Labels, die sich in einem Storage-Pool befinden, auf die Back-End-Storage-LUN. Storage-Administratoren können Labels je virtuellen Pool definieren und Volumes nach Label gruppieren.

In der unten gezeigten Beispiel-Backend-Definitionsdatei werden für alle Speicherpools spezifische Standardwerte festgelegt, die die definieren type Bei Silver. Die virtuellen Pools werden im definiert storage Abschnitt. In diesem Beispiel legen einige Speicherpools ihren eigenen Typ fest, und einige Pools überschreiben die oben festgelegten Standardwerte.

---
version: 1
storageDriverName: solidfire-san
Endpoint: https://<user>:<password>@<mvip>/json-rpc/8.0
SVIP: "<svip>:3260"
TenantName: "<tenant>"
UseCHAP: true
Types:
- Type: Bronze
  Qos:
    minIOPS: 1000
    maxIOPS: 2000
    burstIOPS: 4000
- Type: Silver
  Qos:
    minIOPS: 4000
    maxIOPS: 6000
    burstIOPS: 8000
- Type: Gold
  Qos:
    minIOPS: 6000
    maxIOPS: 8000
    burstIOPS: 10000
type: Silver
labels:
  store: solidfire
  k8scluster: dev-1-cluster
region: us-east-1
storage:
- labels:
    performance: gold
    cost: '4'
  zone: us-east-1a
  type: Gold
- labels:
    performance: silver
    cost: '3'
  zone: us-east-1b
  type: Silver
- labels:
    performance: bronze
    cost: '2'
  zone: us-east-1c
  type: Bronze
- labels:
    performance: silver
    cost: '1'
  zone: us-east-1d

Die folgenden StorageClass-Definitionen beziehen sich auf die oben genannten virtuellen Pools. Verwenden der parameters.selector Feld gibt in jeder StorageClass an, welche virtuellen Pools zum Hosten eines Volumes verwendet werden können. Auf dem Volume werden die Aspekte im ausgewählten virtuellen Pool definiert.

Die erste StorageClass (solidfire-gold-four) wird dem ersten virtuellen Pool zugeordnet. Dies ist der einzige Pool, der eine Goldleistung mit einem Gold bietet Volume Type QoS. Die letzte StorageClass (solidfire-silver) ruft jeden Speicherpool auf, der eine silberne Performance bietet. Trident entscheidet, welcher virtuelle Pool ausgewählt wird, und stellt sicher, dass die Speicheranforderungen erfüllt werden.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: solidfire-gold-four
provisioner: csi.trident.netapp.io
parameters:
  selector: "performance=gold; cost=4"
  fsType: "ext4"
---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: solidfire-silver-three
provisioner: csi.trident.netapp.io
parameters:
  selector: "performance=silver; cost=3"
  fsType: "ext4"
---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: solidfire-bronze-two
provisioner: csi.trident.netapp.io
parameters:
  selector: "performance=bronze; cost=2"
  fsType: "ext4"
---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: solidfire-silver-one
provisioner: csi.trident.netapp.io
parameters:
  selector: "performance=silver; cost=1"
  fsType: "ext4"
---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: solidfire-silver
provisioner: csi.trident.netapp.io
parameters:
  selector: "performance=silver"
  fsType: "ext4"

Weitere Informationen