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
PDFs

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

Was Sie benötigen

  • 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".

Was Sie wissen müssen

Der solidfire-san Der Storage-Treiber unterstützt beide Volume-Modi: Datei und Block. Für das Filesystem VolumeMode erstellt Astra Trident ein Volume und erstellt 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

Kein Dateisystem. Rohes Blockgerät.

solidfire-san

ISCSI

Block-Storage

RWO, ROX, RWX

Kein Dateisystem. Rohes Blockgerät.

solidfire-san

ISCSI

Dateisystem

RWO, ROX

xfs, ext3, ext4

solidfire-san

ISCSI

Dateisystem

RWO, ROX

xfs, ext3, ext4
Hinweis Astra Trident verwendet CHAP, wenn es als erweiterte CSI-Bereitstellung funktioniert. Wenn Sie CHAP verwenden (das ist die Standardeinstellung für CSI), ist keine weitere Vorbereitung erforderlich. Es wird empfohlen, das explizit festzulegen UseCHAP Option zur Verwendung von CHAP mit nicht-CSI Trident. Anderenfalls siehe "Hier".
Warnung Volume-Zugriffsgruppen werden nur vom herkömmlichen, nicht-CSI-Framework für Astra Trident unterstützt. Bei der Konfiguration für die Verwendung im CSI-Modus verwendet Astra Trident CHAP.

Wenn keine AccessGroups Oder UseCHAP Sind festgelegt, gilt eines der folgenden Regeln:

  • Wenn die Standardeinstellung trident Zugriffsgruppe wird erkannt, Zugriffsgruppen werden verwendet.

  • Wenn keine Zugriffsgruppe erkannt wird und die Kubernetes-Version 1.7 oder höher ist, wird CHAP verwendet.

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, um iSCSI zu authentifizieren

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.
Hinweis Astra Trident kopiert bei allen erstellten Volumes alle auf einem Storage-Pool vorhandenen Beschriftungen in die zugrunde liegende Storage-LUN zum Zeitpunkt der Bereitstellung. Storage-Administratoren können Labels pro Storage-Pool definieren und alle Volumes gruppieren, die in einem Storage-Pool erstellt wurden. Dies bietet eine praktische Möglichkeit, Volumes anhand einer Reihe anpassbarer Etiketten, die in der Backend-Konfiguration bereitgestellt werden, zu unterscheiden.

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 Speicherpools

Dieses Beispiel zeigt die mit virtuellen Speicherpools und StorageClasses konfigurierte Back-End-Definitionsdatei.

In der unten gezeigten Beispiel-Backend-Definitionsdatei werden für alle Speicherpools spezifische Standardwerte festgelegt, die die definieren type Bei Silver. Die virtuellen Speicherpools werden im definiert storage Abschnitt. In diesem Beispiel legt ein Teil des Speicherpools seinen 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 Speicherpools. 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 Speicherpool zugeordnet. Dies ist der einzige Pool, der Gold Performance mit einem bietet Volume Type QoS Von Gold. Die letzte StorageClass (solidfire-silver) Bezeichnet jeden Speicherpool, der eine silberne Leistung bietet. Astra Trident entscheidet, welcher virtuelle Storage Pool ausgewählt wird und ob 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