Skip to main content
日本語は機械翻訳による参考訳です。内容に矛盾や不一致があった場合には、英語の内容が優先されます。

SAN ワークロード用に Google Cloud NetApp Volumes を設定

共同作成者 joan-ing
PDF

iSCSI プロトコルを使用して Google Cloud NetApp Volumes からブロックストレージボリュームをプロビジョニングするように Trident を設定できます。SAN ボリュームは、 `google-cloud-netapp-volumes-san`ストレージドライバを使用して Flex Unified ストレージプールからプロビジョニングされます。

メモ このドライバーはブロックワークロード専用であり、NASプロトコルをサポートしていません。
メモ `google-cloud-netapp-volumes-san`バックエンドは、iSCSIブロックボリュームのプロビジョニングに必要です。 `google-cloud-netapp-volumes`バックエンドはNASプロトコルのみをサポートしており、SANワークロードには使用できません。

概要

Trident は、 `google-cloud-netapp-volumes-san`ドライバを使用して、Google Cloud NetApp Volumes SAN（iSCSI）ワークロードをサポートしています。

SANボリュームはFlex Unifiedストレージプールからプロビジョニングされ、iSCSIブロックデバイスとしてKubernetesノードに提示されます。

これは次の環境に適用されます：

  • Trident 26.02以降

  • Google Kubernetes Engine（GKE）または Red Hat OpenShift

  • Google Cloud NetApp Volumes Flex統合ストレージプール

  • iSCSIベースのワークロード

Flex Unified ストレージプール

Flex Unifiedストレージプールは、iSCSIプロトコルを使用してブロックストレージを提供し、SANプロビジョニングに必要です：

  • Flex Unified REGIONAL プールがサポートされています。

  • Flex Unified ZONAL プールは、Trident 26.02.1 以降でサポートされています。

  • SANワークロードでは、*Flex*サービスレベルのみがサポートされます。

Trident SANバックエンドを設定する

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

StorageClassを作成します

SANバックエンドを設定したら、 `google-cloud-netapp-volumes-san`ドライバを参照するStorageClassを作成します。

ファイルシステムのタイプは、バックエンドではなく StorageClass で定義されます。

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

サポートされているファイルシステムの種類：

  • ext4（デフォルト）

  • ext3

  • xfs

メモ SANドライバはFlexサービスレベルのみをサポートし、 exportRule、 unixPermissions、 nasType、 snapshotDir、 `nfsMountOptions`などのNAS固有のバックエンドパラメータや階層化関連の設定は使用しません。

ブロックボリュームのプロビジョニング

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）

ROXの一般的なパターンは、既存のReadWriteOnceボリュームを複製し、クローンを読み取り専用としてマウントすることです。

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）— rawブロックのみ

ReadWriteManyは、 `volumeMode: Block`の場合にのみサポートされます。

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

ブロックボリュームの動作

ブロック ボリュームは iSCSI LUN としてプロビジョニングされ、Kubernetes ノードにブロック デバイスとして提示されます。

ブロックボリューム：

  • iSCSIプロトコルを使用する

  • ファイルシステムとrawブロックのプレゼンテーションをサポート

  • Tridentによって接続され、管理されます

  • 複数の Kubernetes アクセスモードをサポート

アクセスモード

Tridentによってプロビジョニングされたブロックボリュームは、次のアクセスモードをサポートします：

  • ReadWriteOnce（RWO）

  • ReadOnlyMany（ROX）

  • ReadWriteOncePod（RWOP）

  • ReadWriteMany（RWX）、次の場合にのみサポートされます： volumeMode: Block

volumeModeの動作

`volumeMode`フィールドは、ブロックボリュームの公開方法を制御します：

  • Filesystem Trident がボリュームをフォーマットしてマウントします。

  • Block Tridentはデバイスを接続し、rawブロックデバイスとして公開します。

サポートされている操作

`google-cloud-netapp-volumes-san`ドライバーを使用してプロビジョニングされたブロックボリュームは、次の機能をサポートします：

  • 作成

  • 削除

  • クローン

  • スナップショット

  • サイズ変更

  • インポート

追加GiBオーバープロビジョニング動作

Google Cloud NetApp Volumes ブロックボリュームには、内部メタデータのオーバーヘッドが含まれます。このオーバーヘッドにより、プロビジョニングされた容量と比較して、カーネルに表示されるデバイスサイズが小さくなります。

テストの結果：

  • 初期作成時に約 300 KiB のオーバーヘッド

  • サイズ変更後、最大約 107 MiB のオーバーヘッド

Google Cloud NetApp Volumes は GiB 単位の割り当てのみを受け入れるため、Trident は次の方法で、使用可能なデバイスサイズが常に PVC 要求を満たすか超えることを保証します（：）

  • 要求されたサイズを次の整数 GiB に切り上げる

  • 1 GiBのバッファを追加する

例：

  • PVC リクエスト：100 GiB

  • Google Cloud NetApp Volumes でのプロビジョニングサイズ：101 GiB

  • アプリケーションから見える使用可能領域：少なくとも 100 GiB

Podの例

ファイルシステムにマウントされたブロックボリューム（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

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

アタッチとマウントの動作

Google Cloud NetApp Volumes からプロビジョニングされた SAN ボリュームの場合：

  • Trident は、Flex Unified ストレージプールに論理ユニット番号（LUN）を作成します。

  • 公開中、Trident は LUN をノードごとのホストグループにマップします。

  • ノードステージング中、Trident：

    • iSCSIターゲットにログインします

    • LUNを検出します

    • マルチパスを設定します

  • もし volumeMode: Filesystem、Tridentは必要に応じてデバイスをフォーマットし、マウントします。

  • `volumeMode: Block`の場合、Tridentはデバイスを接続し、フォーマットやマウントを行わずにポッドに直接公開します。

メモ SAN ブロックボリュームでは、分散ロックや書き込み調整は提供されません。ブロックボリュームが複数のノードからアクセスされる場合（ReadWriteMany with volumeMode: Block）、アプリケーションまたはファイルシステムは同時実行性を管理する必要があります。