Skip to main content
Eine neuere Version dieses Produkts ist erhältlich.
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

Erstellen und Verwenden eines Element Backend mit der Astra Trident Installation

Details zum Elementtreiber

Astra Trident stellt den solidfire-san Storage-Treiber 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 Astra 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. Astra 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 diese Funktion debugTraceFlags nur, wenn Sie eine Fehlerbehebung durchführen und einen detaillierten Protokollauszug benötigen.

Beispiel 1: Backend-Konfiguration für solidfire-san Treiber mit drei Volume-Typen

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 diese mit dem Storage-Klassen-Parameter zu nutzen IOPS.

---
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-Klassenkonfiguration für solidfire-san Treiber mit virtuellen Pools

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

Astra Trident kopiert beim Provisioning die auf einem Storage-Pool vorhandenen Labels auf die Back-End-Storage-LUN. Storage-Administratoren können Labels je virtuellen Pool definieren und Volumes nach Label gruppieren.

In der unten abgebildeten Beispieldefinitionsdatei für das Backend werden spezifische Standardwerte für alle Speicherpools festgelegt, die die auf „Silber“ setzen type. Die virtuellen Pools werden im Abschnitt definiert storage. 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. Mit dem parameters.selector Feld ruft jede StorageClass ab, 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. Astra Trident entscheidet, welcher virtuelle Pool ausgewählt wird und stellt sicher, dass die Storage-Anforderungen 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