はじめに
本記事では、前回の実施したOpenshiftの構築後に、Storage通信用のNIC設定を行います。
また、ONTAPでiSCSI Storage基盤を作成し、SVMの管理LIFを含めてStorage用のNetworkのみで利用する手順について記載します。
OpenShift VirtualizationとNetApp Trident利用時におけるベストプラクティスについては、
NetAppのBlogの記載が参考になります。
本記事では利用するONTAPが9.18.1となる為、作成したPersistent Volume(PV)に自動的にランサムウェア対策機能が有効化されますが、ランサムウェア対策機能に関する内容では無いのであえて無効化して進めます。
何をしたい？できる？
- NMState Operator設定とStorage通信用のNIC設定
- ONTAPでOpenShiftのPersistent Volume(PV)用のSVM作成
- NetApp Tridentの導入
TridentとSVM管理LIFとの通信について
NetApp Tridentを使用してONTAPストレージを接続する際、ストレージ管理と実際のデータ入出力は分離した形でNetwork設計する事が推奨されますが、本記事ではあえてTrident ControllerのからHost Networkを利用できるような形で設定します。
NetApp Trident 25.10以降で、Trident OrchestratorまたはHelm Chartのパラメーター設定だけで宣言的にHost Networkを有効化する事ができるようになってます。
Trident Release Noteの、
Added an option for Trident controller to use host networking via helm, operator, and tridentctl (Issue #858).
の記載の部分になります。
Storage Driverの選択
使用されるプロトコルとStorage上でのVolumeのプロビジョニング方法によって区別されるものになりますが、明確な要望やStorage側の各種上限（Volume数やSize）に抵触しない限りは、”ontap-nas”または”ontap-san”を選択する事になるかと思います。
詳細はマニュアルを参照頂ければと思いますが、本記事で使用するSANのDriverでは以下の機能の違いがあります。
記事における環境情報
本記事では、以下の環境で実施した内容となります。
OSやモジュールは以下の構成としています。
- ONTAP 9.18.1
- NetApp Trident 26.02.1
- Windows Server 2025 Hyper-V環境
- Red Hat Enterprise Linux 9.8
- OpenShift 4.21.17
環境のイメージとしては以下の通りです。
設定手順
1. OpenShiftの各Nodeへ追加のネットワーク設定
1-1. 仮想マシンへNIC追加
OpenShift環境の5 Node分に対し仮想マシンの設定でVLAN 21のNetworkに繋がるネットワークアダプターを追加します。
「仮想LANを有効にする」のチェックボックスをオンにしてVLAN IDを設定すると、仮想マシンが送出するイーサネットフレームに指定したVLAN IDを記述したVLANタグが付与されます。
つまり、仮想マシンのLinux OS上ではvlan設定が不要という事です。
本記事ではuser01で操作しており、OpenShift Install時にuser01の公開鍵を登録してますので、踏み台サーバからSSH接続を利用して確認します。
# SSHで公開鍵を使って接続
> ssh -i /home/user01/.ssh/id_rsa core@control-01.ocp200.example.org
Red Hat Enterprise Linux CoreOS 9.6.20260520-0
Part of OpenShift 4.21, RHCOS is a Kubernetes-native operating system
managed by the Machine Config Operator (`clusteroperator/machine-config`).
(中略)
# 追加NICの確認
> ip a s eth1
33: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 00:15:5d:d7:09:33 brd ff:ff:ff:ff:ff:ff
1-2. NMState Operatorインストール及びNMStateの作成
OpenShiftクラスター上で ノードのネットワーク設定を管理するためのオペレーターであるNMStateの導入を実施します。
OpenShiftのGUI画面にアクセスし、左側の[エコシステム]から[ソフトウェアカタログ]をクリックします。
表示された画面でNMStateと入力し、表示される[Kubernetes NMState Operator]をクリックします。
表示された画面で[インストール]をクリックします。
表示された画面で値を変更することなく[インストール]をクリックします。
peratorインストールが完了後、[Operatorの表示]をクリックします。
[NMState]タブをクリックし、表示された画面で[NMStateの作成]をクリックします。
NMState の作成では、値を変更せずに、画面下方の[作成]をクリックします。
管理画面にログインし直すと、画面左側の[ネットワーク]の項目が増えている点が確認できます。
1-3. NodeNetworkConfigurationPolicy (NNCP) の適用
NMCPとはクラスターを構成する各ノードのネットワーク設定を定義するカスタムリソースで、ブリッジ接続やVLAN設定、NICのチーミング、Nodeへ固定IPの付与などを行う際に使用します。
IP等の環境情報は以下の通りに設定します。
| 名前 | IP | 役割 |
|---|---|---|
| control-01.ocp200.example.org | 172.16.21.45 | OpenShift Control Node |
| control-02.ocp200.example.org | 172.16.21.46 | OpenShift Control Node |
| control-03.ocp200.example.org | 172.16.21.47 | OpenShift Control Node |
| compute-01.ocp200.example.org | 172.16.21.48 | OpenShift Compute Node |
| compute-01.ocp200.example.org | 172.16.21.49 | OpenShift Compute Node |
本記事の環境では、yamlファイルを作成し、踏み台サーバから設定を実施します。
# 追加NICにIPを付与しているNodeNetworkConfigurationPolicyを作成
> cat nncp-storage-control-01.yaml
apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
name: storage-net
spec:
nodeSelector:
kubernetes.io/hostname: control-01.ocp200.example.org
desiredState:
interfaces:
- name: eth1
type: ethernet
state: up
ipv4:
enabled: true
address:
- ip: 172.16.21.45
prefix-length: 24
# nodeSelectorとaddressを変更したものを5 Node分用意
> ls |grep nncp
nncp-storage-compute-01.yaml
nncp-storage-compute-02.yaml
nncp-storage-control-01.yaml
nncp-storage-control-02.yaml
nncp-storage-control-03.yaml
作成したPolicyを適用し、nncpがocコマンドで表示される事を確認します。
# 適用前は何も表示されない事の確認
> oc get nncp
No resources found
> oc get nnce
No resources found
# Policyを適用
> oc apply -f nncp-storage.yaml
nodenetworkconfigurationpolicy.nmstate.io/storage-net created
# リソースが表示される事の確認
> oc get nncp
NAME STATUS REASON
storage-compute1 Available SuccessfullyConfigured
storage-compute2 Available SuccessfullyConfigured
storage-control1 Available SuccessfullyConfigured
storage-control2 Available SuccessfullyConfigured
storage-control3 Available SuccessfullyConfigured
> oc get nnce
NAME STATUS STATUS AGE REASON
NAME STATUS STATUS AGE REASON
compute-01.ocp200.example.org.storage-compute1 Available 2m8s SuccessfullyConfigured
compute-02.ocp200.example.org.storage-compute2 Available 2m4s SuccessfullyConfigured
control-01.ocp200.example.org.storage-control1 Available 2m37s SuccessfullyConfigured
control-02.ocp200.example.org.storage-control2 Available 2m6s SuccessfullyConfigured
control-03.ocp200.example.org.storage-control3 Available 64s SuccessfullyConfigured
# OpenShiftのNodeへpingを飛ばして疎通確認
> ping -c 2 172.16.21.45
PING 172.16.21.45 (172.16.21.45) 56(84) bytes of data.
64 バイト応答 送信元 172.16.21.45: icmp_seq=1 ttl=64 時間=0.365ミリ秒
64 バイト応答 送信元 172.16.21.45: icmp_seq=2 ttl=64 時間=0.378ミリ秒
--- 172.16.21.45 ping 統計 ---
送信パケット数 2, 受信パケット数 2, 0% packet loss, time 1029ms
rtt min/avg/max/mdev = 0.365/0.371/0.378/0.006 ms
2. ONTAPへiSCSI用Storageの設定
Linux用のiscsi設定はこちらの記事にも記載しています。
2-1. iSCSI用のSVM作成
まずは、SVMを作成します。
iSCSI用のSVM作成手順例については、過去の記事を参照頂ければと思います。
# SVMの作成
> vserver create -vserver iscsi100 -subtype default
[Job 1501] Job succeeded:
Vserver creation completed.
# Volume作成時に利用するAggregateの定義
> vserver modify -vserver iscsi100 -aggr-list aggr1_node1,aggr1_node2
# ONTAP9.18.1からはランサム対策機能がデフォルトで有効となるので、ここでは無効化
> security anti-ransomware auto-enable modify -new-volume-auto-enable false
2-2. iSCSI用のSVMへLIFの作成
管理用とデータ通信用(ONTAP Node毎に1つ)のLIFを作成します。
以下の設定では、SVM管理用とデータ通信LIF用が、OpenShift Nodeで追加したNICに設定したNetworkセグメント(172.16.21.0/24)と同じになりますので、TridentOrchestratorの作成の際にhostNetwork: trueの設定を記載しないと、TridentのControllerからのAPI疎通に失敗します。
# LIFの作成
> network interface create -vserver iscsi100 -lif manage -service-policy default-management -address 172.16.21.60 -netmask 255.255.255.0 -home-node PS-A400-01 -home-port a0a-21
> network interface create -vserver iscsi100 -lif data01 -service-policy default-data-iscsi -address 172.16.21.61 -netmask 255.255.255.0 -home-node PS-A400-01 -home-port a0a-21
> network interface create -vserver iscsi100 -lif data02 -service-policy default-data-iscsi -address 172.16.21.62 -netmask 255.255.255.0 -home-node PS-A400-02 -home-port a0a-21
# 設定情報の確認
> network interface show -vserver iscsi100
Logical Status Network Current Current Is
Vserver Interface Admin/Oper Address/Mask Node Port Home
----------- ---------- ---------- ------------------ ------------- ------- ----
iscsi100
data01 up/up 172.16.21.61/24 PS-A400-01 a0a-21 true
data02 up/up 172.16.21.62/24 PS-A400-02 a0a-21 true
manage up/up 172.16.21.60/24 PS-A400-01 a0a-21 true
3 entries were displayed.
2-3. iSCSIのSVMへの有効化
NFS設定を有効化し、SVMのroot Volumeへアクセス設定を実施します。
# SVMへiscsi有効化
> iscsi create -vserver iscsi100
# 状態の確認
> iscsi show -vserver iscsi100
Vserver: iscsi100
Target Name: iqn.1992-08.com.netapp:sn.207a3c86631a11f1b9abd039ead56cfd:vs.16
Target Alias: iscsi100
Administrative Status: up
2-4. APIアクセス用のユーザ用意
本記事ではONTAP Cluster全体へアクセスでは無く、個々のSVMにAPIを投げる形で作成したいので作成したSVMでAPIアクセス用のユーザ作成が必要になります。
ここでは楽をする為に、SVM作成時に自動で作成されるvsadminユーザを利用します。
# ユーザへのPassword設定
> security login password -vserver iscsi100 -username vsadmin
Enter a new password:
Enter it again:
# UserのUnlock
> security login unlock -vserver iscsi100 -username vsadmin
# User情報の確認
> security login show -vserver iscsi100
Vserver: iscsi100
Second
User/Group Authentication Acct Authentication
Name Application Method Role Name Locked Method
-------------- ----------- ------------- ---------------- ------ --------------
vsadmin http password vsadmin no none
vsadmin ontapi password vsadmin no none
vsadmin ssh password vsadmin no none
3 entries were displayed.
3. Compute NodeへのiSCSI設定
OpenShiftのCompute Node上でiSCSIとMulthPathの設定を行います。
3-1. iscsidの設定
# Compute NodeへSSH接続
> ssh -i /home/user01/.ssh/id_rsa core@compute-01.ocp200.example.org
# iSCSIの有効化とサービス開始
> sudo systemctl enable --now iscsid
Created symlink /etc/systemd/system/multi-user.target.wants/iscsid.service → /usr/lib/systemd/system/iscsid.service.
> sudo systemctl start iscsid
# iSCSIの状態確認
> sudo systemctl status iscsid
● iscsid.service - Open-iSCSI
Loaded: loaded (/usr/lib/systemd/system/iscsid.service; enabled; preset: disabled)
Active: active (running) since Mon 2026-06-08 09:33:19 UTC; 34s ago
TriggeredBy: ● iscsid.socket
Docs: man:iscsid(8)
man:iscsiuio(8)
man:iscsiadm(8)
Main PID: 1137490 (iscsid)
Status: "Ready to process requests"
Tasks: 1 (limit: 153069)
Memory: 3.8M
CPU: 17ms
CGroup: /system.slice/iscsid.service
mq1137490 /usr/sbin/iscsid -f
Jun 08 09:33:19 compute-01.ocp200.example.org systemd[1]: Starting Open-iSCSI...
Jun 08 09:33:19 compute-01.ocp200.example.org systemd[1]: Started Open-iSCSI.
3-2. ONTAP向けのiSCSIターゲットの探索とLoginの実施
Compute NodeでONTAPのSVMに設定したiSCSI用LIFのIPアドレスを指定して探索とログインを実施します。
# discoveryの実施
> sudo iscsiadm -m discovery -t st -p 172.16.21.61:3260
172.16.21.61:3260,1037 iqn.1992-08.com.netapp:sn.207a3c86631a11f1b9abd039ead56cfd:vs.16
172.16.21.62:3260,1038 iqn.1992-08.com.netapp:sn.207a3c86631a11f1b9abd039ead56cfd:vs.16
# loginの実施
> sudo iscsiadm -m node -T iqn.1992-08.com.netapp:sn.207a3c86631a11f1b9abd039ead56cfd:vs.16 -l
Logging in to [iface: default, target: iqn.1992-08.com.netapp:sn.207a3c86631a11f1b9abd039ead56cfd:vs.16, portal: 172.16.21.61,3260]
Logging in to [iface: default, target: iqn.1992-08.com.netapp:sn.207a3c86631a11f1b9abd039ead56cfd:vs.16, portal: 172.16.21.62,3260]
Login to [iface: default, target: iqn.1992-08.com.netapp:sn.207a3c86631a11f1b9abd039ead56cfd:vs.16, portal: 172.16.21.61,3260] successful.
Login to [iface: default, target: iqn.1992-08.com.netapp:sn.207a3c86631a11f1b9abd039ead56cfd:vs.16, portal: 172.16.21.62,3260] successful.
# iSCSIセッションの確認
> sudo iscsiadm -m session
tcp: [1] 172.16.21.61:3260,1037 iqn.1992-08.com.netapp:sn.207a3c86631a11f1b9abd039ead56cfd:vs.16 (non-flash)
tcp: [2] 172.16.21.62:3260,1038 iqn.1992-08.com.netapp:sn.207a3c86631a11f1b9abd039ead56cfd:vs.16 (non-flash)
3-3. Multipathの設定
# multipathの設定ファイルを編集
> sudo cat /etc/multipath.conf
defaults {
find_multipaths no
}
blacklist {
device {
vendor .*
product .*
}
}
blacklist_exceptions {
device {
vendor NETAPP
product LUN
}
}
Multipathの開始を行い、状態を確認します。
# Multipathの開始
> sudo systemctl enable --now multipathd
# 状態の確認
> sudo systemctl status multipathd
● multipathd.service - Device-Mapper Multipath Device Controller
Loaded: loaded (/usr/lib/systemd/system/multipathd.service; enabled; preset: enabled)
Active: active (running) since Mon 2026-06-08 09:44:05 UTC; 17s ago
TriggeredBy: ○ multipathd.socket
Process: 1149785 ExecStartPre=/sbin/modprobe -a scsi_dh_alua scsi_dh_emc scsi_dh_rdac dm-multipath (code=exited, s>
Process: 1149803 ExecStartPre=/sbin/multipath -A (code=exited, status=0/SUCCESS)
Main PID: 1149808 (multipathd)
Status: "up"
Tasks: 7
Memory: 19.0M
CPU: 53ms
CGroup: /system.slice/multipathd.service
mq1149808 /sbin/multipathd -d -s
Jun 08 09:44:05 compute-01.ocp200.example.org systemd[1]: Starting Device-Mapper Multipath Device Controller...
Jun 08 09:44:05 compute-01.ocp200.example.org multipathd[1149808]: --------start up--------
Jun 08 09:44:05 compute-01.ocp200.example.org multipathd[1149808]: read /etc/multipath.conf
Jun 08 09:44:05 compute-01.ocp200.example.org multipathd[1149808]: path checkers start up
Jun 08 09:44:05 compute-01.ocp200.example.org systemd[1]: Started Device-Mapper Multipath Device Controller.
4. NetApp Tridentの導入・設定
4-1. Tridentをインストール
OpenShiftのGUI画面にアクセスし、左側の[エコシステム]から[ソフトウェアカタログ]をクリック後に表示された画面でTridentと入力し、表示される[NetApp Trident]をクリックします。
(Certifiedの方を利用)
表示された画面で[インストール]をクリックします。
表示された画面の下方にある[インストール]をクリックします。
Install完了後に、[Operatorの表示]をクリックします。
表示された画面で[Trident Orchestrator]タブから[TridentOrchestratorの作成]をクリックします。
本記事はiSCSI環境を使用するので、表示された画面の[YAMLビュー]において、nodePrepへiscsiの追記を実施します。また、SVMの管理LIFへOpenShiftのNodeに設定した追加NICから通信させたいのでhostNetwork: trueを追記し、画面下方の[作成]をクリックします。
Installが完了した事を確認します。
踏み台サーバからTrident Install後の状態について確認します。
# Trident Install後の確認
> oc get pod -n trident
NAME READY STATUS RESTARTS AGE
trident-controller-c8bd97f44-wxqhc 6/6 Running 0 2m26s
trident-node-linux-4l4qv 2/2 Running 0 2m26s
trident-node-linux-bptjr 2/2 Running 0 2m26s
trident-node-linux-fx48k 2/2 Running 0 2m26s
trident-node-linux-n246j 2/2 Running 0 2m26s
trident-node-linux-q55mz 2/2 Running 0 2m26s
4-2. SVM資格情報の設定
踏み台サーバから、Tridentが上記の[2-2. iSCSI用のSVMへLIFの作成]の管理LIFへ接続する際に使用する認証資格情報を登録します。
# マニフェスト
> cat trident-svm-secret.yaml
apiVersion: v1
kind: Secret
metadata:
name: ontap-svm-admin
namespace: trident
type: Opaque
stringData:
username: vsadmin
password: XXXXXXX
# 作成したファイルの適用
> oc apply -f trident-svm-secret.yaml
secret/ontap-svm-admin created
> oc get secret -n trident
NAME TYPE DATA AGE
ontap-svm-admin Opaque 2 6s
trident-csi Opaque 6 6m13s
trident-encryption-keys Opaque 1 6m13s
4-3. Trident Backendの設定
Backendの設定は、ONTAP等のStorageとTridentを接続するための定義になり、Storage管理IP、認証情報、SVM、使用するドライバなどを指定し、OpenShiftからVolumeを動的に作成できるようにします。
本記事では後述するStorageClassをSVM毎に分けるような形で設定するので、
labels:{svm:SVM名}の記載を実施します。
指定可能な内容やサンプルはマニュアルを参照してください。
踏み台サーバから操作を実施します。
# マニフェスト
> cat backend-san1.yaml
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
name: backend-tbc-ontap-san
namespace: trident
spec:
version: 1
backendName: ontap-san-backend
storageDriverName: ontap-san
managementLIF: 172.16.21.60
svm: iscsi100
labels:
svm: iscsi100
credentials:
name: ontap-svm-admin
defaults:
spaceReserve: none
# 作成したファイルの適用
> oc apply -f backend-san1.yaml -n trident
tridentbackendconfig.trident.netapp.io/backend-tbc-ontap-san created
# 作成後の確認
> oc get tridentbackend -n trident
NAME BACKEND BACKEND UUID
tbe-h9qvw ontap-san-backend e5583e1d-4e1f-4121-b948-b15ef117c396
> oc get tbc -n trident
NAME BACKEND NAME BACKEND UUID PHASE STATUS
backend-tbc-ontap-san ontap-san-backend e5583e1d-4e1f-4121-b948-b15ef117c396 Bound Success
4-4. StorageClassの設定
StorageClassは、動的プロビジョニングで使用するStorageの種類やポリシーを定義する設定で、ユーザからの要求と上記で設定したBackendを関連させるためにStorageClassを設定します。
指定可能な内容はマニュアルを参照してください。
踏み台サーバから操作を実施します。
# マニフェスト
> cat storageclass-san1.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: ontap-san
provisioner: csi.trident.netapp.io
parameters:
backendType: "ontap-san"
selector: svm=iscsi100
fsType: "ext4"
allowVolumeExpansion: true
# 作成したファイルの適用
> oc apply -f storageclass-san1.yaml
storageclass.storage.k8s.io/ontap-san created
# 作成後の確認
> oc get storageclass
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE
ontap-san csi.trident.netapp.io Delete Immediate true 6s
4-5. VolumeSnapshotClassの設定
PVのSnapshotを管理するためのオブジェクトになりますが、CSIドライバーを複数利用する環境ではないのでOpenShiftクラスター1つだけ作成します。
VolumeSnapshotを作成する際には、VolumeSnapshotClassの名前を指定が必要となります。
踏み台サーバから操作を実施します。
# マニフェスト
> cat volume-snap-class1.yaml
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
name: csi-snapclass
driver: csi.trident.netapp.io
deletionPolicy: Delete
# 作成したファイルの適用
> oc apply -f volume-snap-class1.yaml
volumesnapshotclass.snapshot.storage.k8s.io/csi-snapclass created
# 作成後の確認
> oc get vsclass
NAME DRIVER DELETIONPOLICY AGE
csi-snapclass csi.trident.netapp.io Delete 45s
4-6. Persistent Volume(PV)の作成
PersistentVolumeClaim(PVC)は永続化Storageに対するユーザの要求・リクエストで、容量、アクセスモード(書き込み権限の有無など)、StorageClassを定義します。
PVCで定義されたすべての要件に一致すると、PVCはその一致したPVにバインドされ、PVからStorageを利用できるようになります。
PersistentVolumeは、管理者/TridentによりプロビジョニングされたStorageリソースでクラスタレベルで管理されます。
(クラスタのどのNameSpaceからも利用できる)
BackendのStorageとマッピングされ、Podが削除されてもPVは削除されない形になります。
(Podのライフサイクルと関係なし)
踏み台サーバから後述で作成するPod用やPersistentVolumeClaim用のNamespaceを作成します。
> oc create namespace testspace01
namespace/testspace01 created
# 作成後の確認
> oc get ns testspace01
NAME STATUS AGE
testspace01 Active 18s
Persistent Volumeの払い出しを実施します。
# PersistentVolumeClaim マニフェスト
> cat pvc-san.yaml
---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: pvc-san
namespace: testspace01
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
storageClassName: ontap-san
# マニフェストの適用
> oc apply -f pvc-san.yaml
persistentvolumeclaim/pvc-san created
# 作成後の確認
> oc get pvc -n testspace01
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE
pvc-san Bound pvc-28da9a22-e9b1-4a90-b2ab-35afd1500db1 1Gi RWO ontap-san <unset> 6s
> oc get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS VOLUMEATTRIBUTESCLASS REASON AGE
pvc-28da9a22-e9b1-4a90-b2ab-35afd1500db1 1Gi RWO Delete Bound testspace01/pvc-san ontap-san <unset> 17s
ONTAP側から作成されたVolumeを確認してみます。
Trident Backendに記載した通り、VolumeとLUNがシンプロビジョニング状態で作成されているのが確認できます。
> vol show -vserver iscsi100 -fields size,space-guarantee
vserver volume size space-guarantee
-------- ------------- ---- ---------------
iscsi100 iscsi100_root 1GB volume
iscsi100 trident_pvc_28da9a22_e9b1_4a90_b2ab_35afd1500db1 1.10GB none
2 entries were displayed.
> lun show -vserver iscsi100 -instance
Vserver Name: iscsi100
LUN Path: /vol/trident_pvc_28da9a22_e9b1_4a90_b2ab_35afd1500db1/lun0
Volume Name: trident_pvc_28da9a22_e9b1_4a90_b2ab_35afd1500db1
Qtree Name: ""
LUN Name: lun0
LUN Size: 1GB
OS Type: linux
Space Reservation: disabled
(中略)
4-7. PVへのSnapshot作成
PVCを指定してSnapshotの作成を実施します。
踏み台サーバから操作を実施します。
# マニフェスト
> cat pvc-san-snap1.yaml
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
name: pvc-san-snap
namespace: testspace01
spec:
volumeSnapshotClassName: csi-snapclass
source:
persistentVolumeClaimName: pvc-san
# 作成したファイルの適用
> oc apply -f pvc-san-snap1.yaml
volumesnapshot.snapshot.storage.k8s.io/pvc-san-snap created
# 作成後の確認
> oc get vsclass
NAME DRIVER DELETIONPOLICY AGE
csi-snapclass csi.trident.netapp.io Delete 17m
> oc get volumesnapshot -n testspace01
NAME READYTOUSE SOURCEPVC SOURCESNAPSHOTCONTENT RESTORESIZE SNAPSHOTCLASS SNAPSHOTCONTENT CREATIONTIME AGE
pvc-san-snap true pvc-san 1Gi csi-snapclass snapcontent-48721a73-aad8-4103-bf31-7d27428b0275 12s 13s
ONTAP側から作成されたSnapshotを確認してみます。
> volume snapshot show -vserver iscsi100 -volume trident*
---Blocks---
Vserver Volume Snapshot Size Total% Used%
-------- -------- ------------------------------------- -------- ------ -----
iscsi100 trident_pvc_28da9a22_e9b1_4a90_b2ab_35afd1500db1
snapshot-48721a73-aad8-4103-bf31-7d27428b0275 164KB 0% 44%
なお、NAS用の設定を実施して作成したPVCでも、同じVolumeSnapshotClassを指定してSnapshotの作成ができます。
# 環境情報の確認
> oc get tbc -n trident
NAME BACKEND NAME BACKEND UUID PHASE STATUS
backend-tbc-ontap-nas ontap-nas-backend 310536fc-f58e-4e1f-9dfa-46617b88b69d Bound Success
backend-tbc-ontap-san ontap-san-backend e5583e1d-4e1f-4121-b948-b15ef117c396 Bound Success
> oc get storageclass
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE
ontap-nas csi.trident.netapp.io Delete Immediate true 30h
ontap-san csi.trident.netapp.io Delete Immediate true 2d2h
> oc get pvc -n testspace01
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE
pvc-nas01 Bound pvc-c91d83c3-f13c-47ef-9288-4f269d6cd704 3Gi RWX ontap-nas <unset> 10s
# Snapshotの作成
> cat pvc-nas-snap1.yaml
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
name: pvc-nas-snap01
namespace: testspace01
spec:
volumeSnapshotClassName: csi-snapclass
source:
persistentVolumeClaimName: pvc-nas01
> oc apply -f pvc-nas-snap1.yaml
volumesnapshot.snapshot.storage.k8s.io/pvc-nas-snap01 created
> oc get volumesnapshot -n testspace01
NAME READYTOUSE SOURCEPVC SOURCESNAPSHOTCONTENT RESTORESIZE SNAPSHOTCLASS SNAPSHOTCONTENT CREATIONTIME AGE
pvc-nas-snap01 true pvc-nas01 304Ki csi-snapclass snapcontent-2e99b158-8e83-41af-acf1-062da29c175a 21s 22s
参考及びリンク
Demystifying Clone Strategy in Storage Profile and its relationship with Trident Storage Class
Configure Red Hat OpenShift Container Platform to allow Trident Storage across a host interface
【今から覚えるONTAPの操作】iSCSI用のSVMを作成する
Red Hat OpenShift クラスタに Trident をインストールしてストレージオブジェクトを作成する
OpenShift VirtualizationでTrident + ONTAP利用①【OpenShiftのInstall】