Skip to main content
Une version plus récente de ce produit est disponible.
La version française est une traduction automatique. La version anglaise prévaut sur la française en cas de divergence.

Configurer un système NetApp HCI ou SolidFire backend

Contributeurs
PDF

Découvrez comment créer et utiliser un système Element backend avec votre installation d'Astra Trident.

Avant de commencer

Vous aurez besoin des éléments suivants avant de créer un back-end d'élément.

  • Système de stockage pris en charge exécutant le logiciel Element.

  • Identifiants de locataire ou administrateur de cluster NetApp HCI/SolidFire pouvant gérer les volumes

  • Tous vos nœuds workers Kubernetes doivent avoir installé les outils iSCSI appropriés. Voir "informations de préparation du nœud de travail".

Modes de volume

Le solidfire-san le pilote de stockage prend en charge les deux modes de volume : fichier et bloc. Pour le Filesystem En mode volume, Astra Trident crée un volume et crée un système de fichiers. Le type de système de fichiers est spécifié par la classe de stockage.

Conducteur Protocole Mode Volume Modes d'accès pris en charge Systèmes de fichiers pris en charge

solidfire-san

ISCSI

Bloc

RWO,ROX,RWX

Aucun système de fichiers. Périphérique de bloc brut.

solidfire-san

ISCSI

Bloc

RWO,ROX,RWX

Aucun système de fichiers. Périphérique de bloc brut.

solidfire-san

ISCSI

Système de fichiers

RWO,ROX

xfs, ext3, ext4

solidfire-san

ISCSI

Système de fichiers

RWO,ROX

xfs, ext3, ext4
Remarque Astra Trident utilise le protocole CHAP lorsqu'il fonctionne comme un mécanisme de provisionnement CSI amélioré. Si vous utilisez CHAP (qui est la valeur par défaut pour CSI), aucune autre préparation n'est requise. Il est recommandé de définir explicitement le UseCHAP Possibilité d'utiliser CHAP avec Trident non CSI. Sinon, voir "ici".
Avertissement Les groupes d'accès aux volumes sont uniquement pris en charge par le framework classique non CSI pour Astra Trident. Lorsqu'il est configuré pour fonctionner en mode CSI, Astra Trident utilise le protocole CHAP.

Si aucun de ces deux cas AccessGroups ou UseCHAP sont définies, l'une des règles suivantes s'applique :

  • Si la valeur par défaut trident groupe d'accès détecté, groupes d'accès utilisés.

  • Si aucun groupe d'accès n'est détecté et que la version de Kubernetes est 1.7 ou ultérieure, CHAP est utilisé.

Options de configuration du back-end

Voir le tableau suivant pour les options de configuration du back-end :

Paramètre Description Valeur par défaut

version

Toujours 1

storageDriverName

Nom du pilote de stockage

Toujours « solidfire-san ».

backendName

Nom personnalisé ou système back-end de stockage

“SolidFire_” + adresse IP de stockage (iSCSI)

Endpoint

MVIP pour le cluster SolidFire avec les identifiants de locataire

SVIP

Port et adresse IP de stockage (iSCSI)

labels

Ensemble d'étiquettes arbitraires au format JSON à appliquer aux volumes.

« »

TenantName

Nom du locataire à utiliser (créé si introuvable)

InitiatorIFace

Limitez le trafic iSCSI à une interface hôte spécifique

« par défaut »

UseCHAP

Utilisez CHAP pour authentifier iSCSI

vrai

AccessGroups

Liste des ID de groupes d'accès à utiliser

Recherche l'ID d'un groupe d'accès nommé « trident »

Types

Spécifications de QoS

limitVolumeSize

Echec du provisionnement si la taille du volume demandé est supérieure à cette valeur

« » (non appliqué par défaut)

debugTraceFlags

Indicateurs de débogage à utiliser lors du dépannage. Exemple, {“api”:false, “méthode”:true}

nul
Avertissement Ne pas utiliser debugTraceFlags à moins que vous ne soyez en mesure de dépanner et que vous ayez besoin d'un vidage détaillé des journaux.

Exemple 1 : configuration back-end pour solidfire-san avec trois types de volume

Cet exemple montre un fichier back-end utilisant l'authentification CHAP et la modélisation de trois types de volumes avec des garanties de QoS spécifiques. Il est fort probable que vous définiriez ensuite des classes de stockage pour consommer chacune de ces catégories à l'aide de l' IOPS paramètre de classe de stockage.

---
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

Exemple 2 : configuration du back-end et de la classe de stockage pour solidfire-san pilote avec pools virtuels

Cet exemple représente le fichier de définition du back-end configuré avec des pools virtuels ainsi que des classes de stockage qui les renvoient.

Astra Trident copie les étiquettes présentes sur un pool de stockage vers le LUN de stockage back-end lors du provisionnement. Pour plus de commodité, les administrateurs du stockage peuvent définir des étiquettes par pool virtuel et les volumes de groupe par étiquette.

Dans l'exemple de fichier de définition de back-end illustré ci-dessous, des valeurs par défaut spécifiques sont définies pour tous les pools de stockage, qui définissent le type Du niveau Silver. Les pools virtuels sont définis dans le storage section. Dans cet exemple, certains pools de stockage définissent leur propre type et certains d'entre eux remplacent les valeurs par défaut définies ci-dessus.

---
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

Les définitions de classe de stockage suivantes font référence aux pools virtuels ci-dessus. À l'aide du parameters.selector Chaque classe de stockage indique quel(s) pool(s) virtuel(s) peut(s) être utilisé(s) pour héberger un volume. Les aspects définis dans le pool virtuel sélectionné seront définis pour le volume.

La première classe de stockage (solidfire-gold-four) sera mappé sur le premier pool virtuel. Il s'agit du seul pool offrant des performances Gold avec un Volume Type QoS De l'or. La dernière classe de stockage (solidfire-silver) appelle n'importe quel pool de stockage qui offre une performance silver. Astra Trident va décider du pool virtuel sélectionné et s'assurer que les besoins en stockage sont satisfaits.

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"

Trouvez plus d'informations