NetApp Tech Blog에 갔다가 Trident 관련해서 흥미로운 주제의 글이 보여서 AI 번역(+약간 수정)의 힘을 빌려 읽어보았습니다.
출처: https://community.netapp.com/t5/Tech-ONTAP-Blogs/Introducing-Fibre-Channel-support-in-Trident/ba-p/457427
NetApp ® Trident ™ 스토리지 프로비 저너 25.02 릴리스를 통해 ontap-san 드라이버(sanType: fcp)에서 파이버 채널 프로토콜(FCP)을 공식 지원합니다. 이 지원을 통해 고객은 Kubernetes/OpenShift 가상화에서 컨테이너 또는 가상 머신을 실행하는 것과 같은 최신 워크로드에 기존 파이버 채널 프로토콜(FC) 인프라 투자를 활용할 수 있습니다. FC는 고객이 테스트할 수 있도록 Trident 버전 24.10의 기술 미리보기 기능이었지만, 이제 고객이 프로덕션 환경에서도 새로운 기능을 사용할 수 있도록 지원합니다.
이 블로그에서는 FC 백엔드로 Trident를 구성하는 방법을 간략히 보여드리고 볼륨 스냅샷과 크기 조정 작업을 시연합니다.
필수 조건
이 블로그 게시물은 다음을 가정합니다.
- 최신 Trident가 설치된 Kubernetes 클러스터와 관련 kubeconfig 가 있습니다 .
- 조닝은 ONTAP 설명서 에 따라 NetApp ONTAP ® 소프트웨어를 실행하는 FC 스위치와 시스템에서 수행됩니다 .
- Trident는 Kubernetes 클러스터에 설치되었으며, 클러스터 노드는 Trident 설명서 에 따라 준비되었습니다 .
- kubeconfig를 사용하도록 kubectl이 구성된 워크스테이션에 액세스할 수 있으며 , tridentctl CLI가 설치되어 있습니다 .
트라이던트 구성
먼저 JSON 형식의 백엔드 구성을 사용하여 SAN 드라이버로 ONTAP 백엔드를 구성합니다. 액세스 정보와 스토리지 드라이버 이름 (iSCSI, NVMe, FCP에서 공통) 인 ontap-san을 제공하고, sanType을 fcp 로 설정합니다 .
$ cat 1_fcp_backend.json
{
"version": 1,
"storageDriverName": "ontap-san",
"managementLIF": "172.16.100.98",
"svm": "svm1",
"username": "admin",
"password": "Ab0xB@wks!",
"sanType": "fcp",
"useREST": false,
"backendName": "LXRRRxxbfr"
}
이 tridentctl 명령은 백엔드 LXRRRxxbfr을 생성합니다 .
$ tridentctl create backend -f 1_fcp_backend.json -n trident +------------+----------------+--------------------------------------+--------+------------+---------+ | NAME | STORAGE DRIVER | UUID | STATE | USER-STATE | VOLUMES | +------------+----------------+--------------------------------------+--------+------------+---------+ | LXRRRxxbfr | ontap-san | dd2110ac-d412-4c93-9a24-85a86b0c80f5 | online | normal. | 0 | +------------+----------------+--------------------------------------+--------+------------+---------+
백엔드가 구축되고 온라인 상태가 되면 나중에 영구 볼륨을 동적으로 프로비저닝하기 위해 해당 스토리지 클래스인 basic-fcp를 생성합니다.
$ cat 2_storage-class-basic.yaml apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: basic-fcp provisioner: csi.trident.netapp.io allowVolumeExpansion: true parameters: backendType: "ontap-san" fsType: "ext4" $ kubectl create -f ./2_storage-class-basic.yaml storageclass.storage.k8s.io/basic-fcp created
또한 나중에 스냅샷을 생성하는 데 사용할 스냅샷 클래스 csi-snapclass를 생성합니다.
$ cat 2a_snapshot-class-basic.yaml apiVersion: snapshot.storage.k8s.io/v1 kind: VolumeSnapshotClass metadata: name: csi-snapclass driver: csi.trident.netapp.io deletionPolicy: Delete $ kubectl create -f ./ 2a_snapshot-class-basic.yaml Volumesnapshotclass.snapshot.storage.k8s.io/csi-snapclass created
ONTAP 콘솔에서 확인해보니, 작업자 노드( sti-rx2540-266 )의 worldwide port name(WWPN)이 아직 ONTAP initiator groups(igroups)에 등록되지 않은 것으로 나타났습니다. 아직 워크로드 포드를 생성하지 않았기 때문입니다.
$ hostname
sti-rx2540-266.ctl.gdl.englab.netapp.com
stiA300-2911726562639::> igroup show -vserver svml
Vserver Igroup Protocol OS Type Initiators
--------- ------------ -------- ------- --------------------------------------------
svm1 sti-c210-347 fcp linux 21:00:00:24:ff:27:de:1a
21:00:00:24:ff:27:de:1b
svm1 sti-rx2540-263
fcp linux 10:00:00:10:9b:1d:73:7c
10:00:00:10:9b:1d:73:7d
svm1 sti-rx2540-263.ctl.gdl.englab.netapp.com-fcp-c38dbd10-f2a9-4762-b553-f
871fef4f7a7
fcp linux 10:00:00:10:9b:1d:73:7c
10:00:00:10:9b:1d:73:7d
21:00:00:24:ff:48:fb:14
21:00:00:24:ff:48:fb:15
svm1 trident mixed linux 18:00:00:10:9b:dd:dd:dd
4 entries were displayed작업자 노드에서 영구 볼륨과 포드를 생성하기 전에 multipath 출력을 확인하여 장치 매퍼(DM) 장치가 하나만 있는지 확인합니다.
$ multipath -ll 3600а098038303048783f4a7148556f2d dm-0 NETAPP, LUN C-Mode size=40G features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 alwp=rw |-+- policy='service-time 0' prio=10 status=enabled | |- 10:0:0:0 sda 8:0 active ready running | '- 12:0:0:0 sdc 8:32 active ready running '-+- policy='service-time 0' prio=50 status=active |- 10:0:1:0 sdb 8:16 active ready running '- 12:0:1:0 sdd 8:48 active ready running
볼륨 생성 및 스냅샷 작업 테스트
이제 이 매니페스트를 적용하여 워크로드 포드와 PersistentVolumeClaim(PVC)을 만들어 보겠습니다.
$ cat 3_sts_with_pvc.yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: my-statefulset
spec:
replicas: 1
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
volumeMounts:
- name: basic-fcp-pvc
mountPath: /mnt/basic-san
volumeClaimTemplates:
- metadata:
name: basic-fcp-pvc
spec:
accessModes: [ "ReadWriteOnce" ]
storageClassName: "basic-fcp"
resources:
requests:
storage: 20Mi
$ kubectl create -f ./ 3_sts_with_pvc.yaml
Statefulset.apps/my-statefulset createdPVC가 생성되었음을 확인합니다.
$ kubectl get pvc -A NAMESPACE NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE Default basic-fcp-pvc-my-statefulset-0 Bound pvc-fed5f2fa-9841-4313-a619-1548e9457bce 20Mi RWO basic-fop 4s
몇 초 후에 포드가 작동하기 시작합니다.
$ kubectl get po -A | grep statefulset NAMESPACE NAME READY STATUS RESTARTS AGE Default my-statefulset-0 1/1 Running 0 16s
포드가 올라간 후, 작업자 노드에 추가 DM 장치 dm-5가 있는 것을 볼 수 있습니다.
$ multipath -ll 3600а098038313768583f58394343506a dm-5 NETAPP, LUN C-Mode size=20M features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 al ua' wp=rw '-+- policy='service-time 0' prio=50 status=active |- 11:0:0:0 sde 8:64 active ready running '- 13:0:0:0 sdf 8:80 active ready running 3600а098038303048783f4a7148556f2d dm-0 NETAPP, LUN C-Mode size=40G features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 alwp=rw |-+- policy='service-time 0' prio=10 status=enabled | |- 10:0:0:0 sda 8:0 active ready running | '- 12:0:0:0 sdc 8:32 active ready running '-+- policy='service-time 0' prio=50 status=active |- 10:0:1:0 sdb 8:16 active ready running '- 12:0:1:0 sdd 8:48 active ready running
ONTAP 콘솔에서 igroup에 새 항목이 추가된 것을 확인할 수 있습니다. igroup 이름 앞에는 작업자 노드의 호스트 이름과 WWPN이 접두사로 붙습니다. 두 번째 작업자 노드 B에 ReadWriteMany(RWX) 볼륨이 연결된 경우 해당 작업자 노드의 igroup은 달라집니다. 이를 iSCSI 사양에 따라 “per-node igroup”이라고 합니다.
stiA300-2911726562639::> igroup show -vserver svml
Vserver Igroup Protocol OS Type Initiators
--------- ------------ -------- ------- --------------------------------------------
svm1 sti-c210-347 fcp linux 21:00:00:24:ff:27:de:1a
21:00:00:24:ff:27:de:1b
svm1 sti-rx2540-263
fcp linux 10:00:00:10:9b:1d:73:7c
10:00:00:10:9b:1d:73:7d
svm1 sti-rx2540-263.ctl.gdl.englab.netapp.com-fcp-c38dbd10-f2a9-4762-b553-f
871fef4f7a7
fcp linux 10:00:00:10:9b:1d:73:7c
10:00:00:10:9b:1d:73:7d
21:00:00:24:ff:48:fb:14
21:00:00:24:ff:48:fb:15
svm1 sti-rx2540-266.ctl.gdl.englab.netapp.com-fcp-8017638f-8e81-419b-8202-c
c16678b394f
fcp linux 0:00:00:90:fa:cd:fd:c0
0:00:00:90:fa:cd:fd:c1
21:00:00:24:ff:30:2:a2
21:00:00:24:ff:30:2:a3
svm1 trident mixed linux 18:00:00:10:9b:dd:dd:dd
‹space> to page down, <return> for next line, or 'g' to quit...이제 스냅샷을 생성하고 이를 통해 PVC를 복제해 보겠습니다.
이전에 생성한 PVC의 볼륨 스냅샷 ontap-fcp-snapshot을 생성하려면 다음 매니페스트를 사용합니다.
$ cat 4_fcp_ontap-snapshot.yaml
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
name: ontap-fcp-snapshot
spec:
volumeSnapshotClassName: csi-snapclass
source:
persistentVolumeClaimName: basic-fcp-pvc-my-statefulset-0
$ kubectl create -f 4_fcp_ontap-snapshot.yaml
volumesnapshot.snapshot.storage.k8s.io/ontap-fcp-snapshot created몇 초 후에 스냅샷이 준비됩니다.
$ kubectl get volumesnapshot
NAME READYTOUSE SOURCEPVC SOURCESNAPSHOTCONTENT RESTORESIZE SNAPSHOTCLASS SNAPSHOTCONTENT
CREATIONTIME AGE
ontap-fcp-snapshot true basic-fcp-pvc-my-statefulset-0 20Mi csi-snapclass snapcontent-69f30df6-353d-444b-8a8c-fe4fe3693206 4s 4s이제 이 매니페스트를 사용하여 해당 스냅샷에서 PVC ontap-fcp-pvc-from-snapshot 복제본을 만들 준비가 되었습니다 .
$ cat 5_fcp_ontap-pvc-from-snapshot.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: ontap-fcp-pvc-from-snapshot
spec:
accessModes:
- ReadWriteOnce
storageClassName: basic-fcp
resources:
requests:
storage: 20Mi
dataSource:
name: ontap-fcp-snapshot
kind: VolumeSnapshot
apiGroup: snapshot.storage.k8s.io
$ kubectl create -f 5_fcp_ontap-pvc-from-snapshot.yaml
persistenvolumeclaim/ontap-fcp-pvc-from-snapshot createdPVC 목록을 확인해보면, 다음 목록의 두 번째 PVC가 스냅샷의 PVC입니다. 따라서 복제된 PVC가 성공적으로 생성되었습니다.
$ kubectl get pvc -A NAMESPACE NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGE CLASS AGE default basic-fcp-pvc-my-statefulset-0 Bound pvc-fed5f2fa-9841-4313-a619-1548e9457bce 20Mi RWO basic-fcp 73s default ontap-fcp-pvc-from-snapshot Bound pvc-c3bf4ffc-7b11-4ef7-8334-895b971d61db 20Mi RWO basic-fcp 6s
볼륨 크기 조정 작업 테스트
마지막 테스트로, 다음 매니페스트를 사용하여 크기 조절 워크플로를 수행하기 위해 크기가 1GiB인 또 다른 FCP 지원 PVC basic-fcp-pvc를 생성합니다.
$ cat pvc-basic-1.yaml
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: basic-fcp-pvc
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
storageClassName: basic-fcp
$ kubectl create -f ./ pvc-basic-1.yaml
persistenvolumeclaim/basic-fcp-pvc created새로 만든 PVC에 포드/배포를 첨부합니다.
$ cat deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: test-deployment
labels:
app: nginx
spec:
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- image: nginx:latest
name: nginx
volumeMounts:
- mountPath: /usr/share/nginx/html
name: nginx-data
volumes:
- name: nginx-data
persistentVolumeClaim:
claimName: basic-fcp-pvc
$ kubectl create -f ./deployment.yaml
deployment.apps/test-deployment created그리고 우리는 포드가 올라오기를 기다립니다.
$ kubectl get po -A | grep test NAMESPACE NAME READY STATUS RESTARTS AGE default test-deployment-6bc4596cbc-zqv12 1/1 Running 0 14s
이제 PVC basic-fcp-pvc를 초기 1GiB에서 2GiB 크기로 패치해 보겠습니다.
$ kubectl patch pvc basic-fcp-pvc -p ‘{“spec”: {“resources”: {“requests”: {“storage”: :2Gi”}}}}’
persistenvolumeclaim/basic-fcp-pvc patched크기 조정 작업을 적용하려면 Pod를 다시 시작해야 하므로 삭제하겠습니다.
$ kubectl delete po test-deployment-6bc4596cbc-zqv12 pod “test-deployment-6bc4596cbc-zqv12” deleted
새로운 포드가 나타나면 크기 조정 작업이 수행됩니다.
$ kubectl get po -A | grep test default test-deployment-6bc4596cbc-cps8q 1/1 Running 0 5s
마지막으로 PVC를 쿼리하여 크기 조정이 성공적으로 이루어졌는지 확인하고 용량이 이제 2GiB임을 확인합니다.
$ kubectl get pvc -A | grep basic-fcp-pvc default basic-fcp-pvc Bound pvc-20414113-7630-4dcb-b522-e89853ac77f3 2Gi RWO basic-fcp 57s default basic-fcp-pvc-my-statefulset-0 Bound pvc-fed5f2fa-9841-4313-a619-1548e9457bce 20Mi RWO basic-fcp 2m24ss default ontap-fcp-pvc-from-snapshot Bound pvc-c3bf4ffc-7b11-4ef7-8334-895b971d61db 20Mi RWO basic-fcp 77s
결론
요약하자면, 쿠버네티스 클러스터에서 Trident를 사용하여 FC 백엔드를 구성했습니다. 그런 다음 FC 백엔드에 여러 개의 영구 볼륨을 생성하고 스냅샷 생성, 복제, 크기 조정과 같은 스토리지 작업이 예상대로 작동하는지 확인했습니다.
