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 netapp-aruldeepa
PDFs

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

Element-Treiberdetails

Trident bietet die solidfire-san Speichertreiber zur Kommunikation mit dem Cluster. Unterstützte Zugriffsmodi sind: ReadWriteOnce (RWO), ReadOnlyMany (ROX), ReadWriteMany (RWX), ReadWriteOncePod (RWOP).

Der solidfire-san Der Speichertreiber unterstützt die Volume-Modi file und block. Für die Filesystem Im Modus volumeMode erstellt Trident ein Volume und ein Dateisystem. Der Dateisystemtyp wird durch die StorageClass festgelegt.

Treiber Protokoll Lautstärkemodus Unterstützte Zugriffsmodi Unterstützte Dateisysteme

solidfire-san

iSCSI

Block

RWO, ROX, RWX, RWOP

Kein Dateisystem. Rohblockgerät.

solidfire-san

iSCSI

Dateisystem

RWO, RWOP

xfs, ext3 , ext4

Bevor Sie beginnen

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

  • Ein unterstütztes Speichersystem, auf dem die Element-Software läuft.

  • Anmeldeinformationen für einen NetApp HCI/ SolidFire Cluster-Administrator oder Mandantenbenutzer, der Volumes verwalten kann.

  • Auf allen Ihren Kubernetes-Worker-Knoten sollten die entsprechenden iSCSI-Tools installiert sein. Siehe"Informationen zur Vorbereitung der Worker-Knoten" .

Backend-Konfigurationsoptionen

Die folgenden Tabellen enthalten die Backend-Konfigurationsoptionen:

Parameter Beschreibung Standard

version

Immer 1

storageDriverName

Name des Speichertreibers

Immer "solidfire-san"

backendName

Benutzerdefinierter Name oder das Speicher-Backend

"solidfire_" + Speicher (iSCSI) IP-Adresse

Endpoint

MVIP für den SolidFire -Cluster mit Mandantenanmeldeinformationen

SVIP

Speicher (iSCSI) IP-Adresse und Port

labels

Satz beliebiger, im JSON-Format vorliegender Bezeichnungen, die auf Datenträger angewendet werden sollen.

""

TenantName

Zu verwendender Mandantenname (wird erstellt, falls nicht gefunden)

InitiatorIFace

iSCSI-Datenverkehr auf eine bestimmte Hostschnittstelle beschränken

"Standard"

UseCHAP

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

true

AccessGroups

Liste der zu verwendenden Zugriffsgruppen-IDs

Findet die ID einer Zugriffsgruppe mit dem Namen "trident"

Types

QoS-Spezifikationen

limitVolumeSize

Die Bereitstellung schlägt fehl, wenn die angeforderte Volume-Größe diesen Wert überschreitet.

"" (wird nicht standardmäßig erzwungen)

debugTraceFlags

Debug-Flags zur Verwendung bei der Fehlersuche. Beispiel: {"api":false, "method":true}

null
Warnung Nicht verwenden debugTraceFlags Es sei denn, Sie befinden sich in der Fehlersuche und benötigen einen detaillierten Protokollauszug.

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

Dieses Beispiel zeigt eine Backend-Datei, die CHAP-Authentifizierung verwendet und drei Volumentypen mit spezifischen QoS-Garantien modelliert. Höchstwahrscheinlich würden Sie dann Speicherklassen definieren, um jede dieser Klassen mithilfe der folgenden Methode zu nutzen: IOPS Speicherklassenparameter.

---
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: Backend- und Speicherklassenkonfiguration für solidfire-san Fahrer mit virtuellen Pools

Dieses Beispiel zeigt die Backend-Definitionsdatei, die mit virtuellen Pools konfiguriert ist, sowie StorageClasses, die auf diese verweisen.

Trident kopiert die auf einem Speicherpool vorhandenen Labels beim Provisioning auf die Backend-Speicher-LUN. Zur Vereinfachung können Speicheradministratoren Bezeichnungen pro virtuellem Pool definieren und Volumes nach Bezeichnung gruppieren.

In der unten gezeigten Beispiel-Backend-Definitionsdatei sind spezifische Standardwerte für alle Speicherpools festgelegt, die die type bei Silver. Die virtuellen Pools sind definiert in der 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 des parameters.selector Im Feld „StorageClass“ wird jeweils angegeben, welcher virtuelle Pool (oder welche virtuellen Pools) zum Hosten eines Volumes verwendet werden kann. Das Volumen wird die im gewählten virtuellen Pool definierten Aspekte aufweisen.

Die erste Speicherklasse(solidfire-gold-four wird dem ersten virtuellen Pool zugeordnet. Dies ist der einzige Pool, der Gold-Leistung mit einem bietet Volume Type QoS aus Gold. Die letzte Speicherklasse(solidfire-silver ) nennt jeden Speicherpool, der eine Silber-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