Skip to main content
La versione in lingua italiana fornita proviene da una traduzione automatica. Per eventuali incoerenze, fare riferimento alla versione in lingua inglese.

Configura Google Cloud NetApp Volumes per carichi di lavoro SAN

Collaboratori joan-ing
PDF

È possibile configurare Trident per eseguire il provisioning di volumi di storage a blocchi utilizzando il protocollo iSCSI da Google Cloud NetApp Volumes. I volumi SAN vengono creati dai pool di storage Flex Unified utilizzando il google-cloud-netapp-volumes-san driver di storage.

Nota Questo driver è dedicato ai carichi di lavoro a blocchi e non supporta i protocolli NAS.
Nota Il google-cloud-netapp-volumes-san backend è necessario per il provisioning di volumi a blocchi iSCSI. Il google-cloud-netapp-volumes backend supporta solo protocolli NAS e non può essere utilizzato per carichi di lavoro SAN.

Panoramica

Trident supporta i carichi di lavoro SAN (iSCSI) di Google Cloud NetApp Volumes utilizzando il driver google-cloud-netapp-volumes-san.

I volumi SAN vengono forniti dai pool di storage Flex Unified e presentati ai nodi Kubernetes come dispositivi a blocchi iSCSI.

Ciò si applica ai seguenti ambienti:

  • Trident 26.02 e versioni successive

  • Google Kubernetes Engine (GKE) o Red Hat OpenShift

  • Google Cloud NetApp Volumes Flex pool di storage unificati

  • Carichi di lavoro basati su iSCSI

Pool di storage unificati Flex

I pool di storage Flex Unified forniscono storage a blocchi utilizzando il protocollo iSCSI e sono necessari per il provisioning SAN:

  • Sono supportati i pool regionali Flex Unified.

  • I pool Flex Unified ZONAL sono supportati a partire da Trident 26.02.1.

  • Per i carichi di lavoro SAN è supportato esclusivamente il livello di servizio Flex.

Configura un backend SAN Trident

apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: gcnv-san
  namespace: trident
spec:
  version: 1
  storageDriverName: google-cloud-netapp-volumes-san
  projectNumber: "<project-number>"
  location: "<region>"
  sdkTimeout: "600"
  storage:
  - labels:
      cloud: gcp
      performance: flex
    network: "<vpc-network>"
    serviceLevel: Flex

Crea un StorageClass

Dopo aver configurato il backend SAN, crea una StorageClass che fa riferimento al driver google-cloud-netapp-volumes-san.

Il tipo di file system è definito nella StorageClass, non nel backend.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: gcnv-san
provisioner: csi.trident.netapp.io
parameters:
  backendType: "google-cloud-netapp-volumes-san"
  fsType: "ext4"
allowVolumeExpansion: true

Tipi di filesystem supportati:

  • ext4 (predefinito)

  • ext3

  • xfs

Nota Il driver SAN supporta solo il livello di servizio Flex e non utilizza parametri backend specifici del NAS come exportRule, unixPermissions, nasType, snapshotDir, nfsMountOptions o impostazioni relative al tiering.

Effettuare il provisioning dei volumi a blocchi

ReadWriteOnce (RWO)

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: gcnv-san-rwo
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 100Gi
  storageClassName: gcnv-san

ReadWriteOncePod (RWOP)

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: gcnv-san-rwop
spec:
  accessModes:
    - ReadWriteOncePod
  resources:
    requests:
      storage: 100Gi
  storageClassName: gcnv-san

ReadOnlyMany (ROX)

Un modello comune per ROX è clonare un volume ReadWriteOnce esistente e montare il clone come di sola lettura.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: gcnv-san-rox
spec:
  accessModes:
    - ReadOnlyMany
  resources:
    requests:
      storage: 100Gi
  storageClassName: gcnv-san
  dataSource:
    kind: PersistentVolumeClaim
    name: gcnv-san-rwo

ReadWriteMany (RWX) — solo raw block

ReadWriteMany è supportato solo quando volumeMode: Block.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: gcnv-san-raw-rwx
spec:
  accessModes:
    - ReadWriteMany
  volumeMode: Block
  resources:
    requests:
      storage: 100Gi
  storageClassName: gcnv-san

Comportamento del volume a blocchi

I volumi a blocchi vengono forniti come LUN iSCSI e presentati ai nodi Kubernetes come dispositivi a blocchi.

Volumi a blocchi:

  • Utilizzare il protocollo iSCSI

  • Supporta la presentazione sia del file system che dei blocchi raw

  • Sono allegati e gestiti da Trident

  • Supporta più modalità di accesso a Kubernetes

Modalità di accesso

I volumi a blocchi forniti da Trident supportano le seguenti modalità di accesso:

  • ReadWriteOnce (RWO)

  • ReadOnlyMany (ROX)

  • ReadWriteOncePod (RWOP)

  • ReadWriteMany (RWX), supportato solo quando volumeMode: Block

Comportamento di volumeMode

Il volumeMode campo controlla come viene esposto un volume di blocco:

  • Filesystem Trident formatta e monta il volume.

  • Block Trident collega il dispositivo e lo espone come raw block device.

Operazioni supportate

Volumi a blocchi forniti utilizzando il google-cloud-netapp-volumes-san driver support:

  • Crea

  • Elimina

  • Clona

  • Snapshot

  • Ridimensionare

  • Importare

Comportamento di overprovisioning extra GiB

I volumi a blocchi di Google Cloud NetApp Volumes includono un overhead interno di metadati. Questo overhead riduce le dimensioni del dispositivo visibile al kernel rispetto alla capacità fornita.

I test dimostrano:

  • Circa 300 KiB di overhead sulla creazione iniziale

  • Fino a circa 107 MiB di overhead dopo un ridimensionamento

Poiché Google Cloud NetApp Volumes accetta solo allocazioni di interi GiB, Trident garantisce che la dimensione utilizzabile del dispositivo soddisfi o superi sempre la richiesta PVC:

  • Arrotondamento della dimensione richiesta al GiB intero successivo

  • Aggiunta di un buffer aggiuntivo di 1 GiB

Esempio:

  • Richiesta PVC: 100 GiB

  • Dimensioni fornite in Google Cloud NetApp Volumes: 101 GiB

  • Spazio utilizzabile visibile all'applicazione: almeno 100 GiB

Esempi di pod

Volume a blocchi montato sul filesystem (RWO)

apiVersion: v1
kind: Pod
metadata:
  name: app-rwo
spec:
  containers:
  - name: app
    image: ubuntu:22.04
    command: ["sleep", "infinity"]
    volumeMounts:
    - name: data
      mountPath: /mnt/data
  volumes:
  - name: data
    persistentVolumeClaim:
      claimName: gcnv-san-rwo

Dispositivo a blocchi raw (RWX)

apiVersion: v1
kind: Pod
metadata:
  name: app-raw-rwx
spec:
  containers:
  - name: app
    image: ubuntu:22.04
    command: ["sleep", "infinity"]
    volumeDevices:
    - name: data
      devicePath: /dev/xda
  volumes:
  - name: data
    persistentVolumeClaim:
      claimName: gcnv-san-raw-rwx

Comportamento di attach e mount

Per i volumi SAN forniti da Google Cloud NetApp Volumes:

  • Trident crea un Logical Unit Number (LUN) in un pool di storage Flex Unified.

  • Durante la pubblicazione, Trident mappa la LUN su un gruppo host per nodo.

  • Durante la messa in scena del nodo, Trident:

    • Accede all'iSCSI target

    • Scopre il LUN

    • Configura multipath

  • Se volumeMode: Filesystem, Trident formatta il dispositivo se necessario e lo monta.

  • Se volumeMode: Block, Trident collega il dispositivo e lo espone direttamente al pod senza formattarlo o montarlo.

Nota I volumi a blocchi SAN non forniscono blocco distribuito o coordinamento delle scritture. Quando un volume a blocchi è accessibile da più nodi (ReadWriteMany con volumeMode: Block), l'applicazione o il file system devono gestire la concorrenza.