4.12. 로컬 스토리지를 사용하는 영구저장장치
4.12.1. 로컬 블록을 사용하는 영구 스토리지
OpenShift Container Platform은 로컬 볼륨을 사용하여 영구 스토리지를 통해 프로비저닝될 수 있습니다. 로컬 영구 볼륨을 사용하면 표준 영구 볼륨 클레임 인터페이스를 사용하여 디스크 또는 파티션과 같은 로컬 스토리지 장치에 액세스할 수 있습니다.
시스템에서 볼륨 노드 제약 조건을 인식하고 있기 때문에 로컬 볼륨은 노드에 수동으로 Pod를 예약하지 않고 사용할 수 있습니다. 그러나 로컬 볼륨은 여전히 기본 노드의 가용성에 따라 달라지며 일부 애플리케이션에는 적합하지 않습니다.
로컬 볼륨은 정적으로 생성된 영구 볼륨으로 사용할 수 있습니다.
4.12.1.1. Local Storage Operator 설치
Local Storage Operator는 기본적으로 OpenShift Container Platform에 설치되지 않습니다. 다음 절차에 따라 이 Operator를 설치하고 구성하여 클러스터에서 로컬 볼륨을 활성화합니다.
사전 요구 사항
- OpenShift Container Platform 웹 콘솔 또는 CLI(명령줄 인터페이스)에 액세스할 수 있습니다.
절차
openshift-local-storage
프로젝트를 생성합니다.$ oc adm new-project openshift-local-storage
선택 사항: 인프라 노드에서 로컬 스토리지 생성을 허용합니다.
Local Storage Operator를 사용하여 로깅 및 모니터링과 같은 구성 요소를 지원하는 인프라 노드에 볼륨을 생성할 수 있습니다.
Local Storage Operator에 작업자 노드가 아닌 인프라 노드가 포함되도록 기본 노드 선택기를 조정해야 합니다.
Local Storage Operator가 클러스터 전체 기본 선택기를 상속하지 못하도록 하려면 다음 명령을 입력합니다.
$ oc annotate namespace openshift-local-storage openshift.io/node-selector=''
선택 사항: 단일 노드 배포의 CPU 관리 풀에서 로컬 스토리지를 실행할 수 있습니다.
단일 노드 배포에서 Local Storage Operator를 사용하고
관리
풀에 속하는 CPU를 사용할 수 있습니다. 관리 워크로드 파티셔닝을 사용하는 단일 노드 설치에서 이 단계를 수행합니다.Local Storage Operator가 관리 CPU 풀에서 실행되도록 다음 명령을 실행합니다.
$ oc annotate namespace openshift-local-storage workload.openshift.io/allowed='management'
UI에서
웹 콘솔에서 Local Storage Operator를 설치하려면 다음 단계를 따르십시오.
- OpenShift Container Platform 웹 콘솔에 로그인합니다.
-
Operators
OperatorHub로 이동합니다. - Local Storage를 필터 상자에 입력하여 Local Storage Operator를 찾습니다.
- 설치를 클릭합니다.
- Operator 설치 페이지에서 클러스터의 특정 네임스페이스를 선택합니다. 드롭다운 메뉴에서 openshift-local-storage를 선택합니다.
- 업데이트 채널 및 승인 전략 값을 원하는 값으로 조정합니다.
- 설치를 클릭합니다.
완료되면 Local Storage Operator가 웹 콘솔의 설치된 Operator 섹션에 나열됩니다.
CLI에서
CLI에서 Local Storage Operator를 설치합니다.
openshift-local-storage.yaml
과 같은 Local Storage Operator의 Operator 그룹 및 서브스크립션을 정의하는 오브젝트 YAML 파일을 생성합니다.예: openshift-local-storage.yaml
apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: local-operator-group namespace: openshift-local-storage spec: targetNamespaces: - openshift-local-storage --- apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: local-storage-operator namespace: openshift-local-storage spec: channel: stable installPlanApproval: Automatic 1 name: local-storage-operator source: redhat-operators sourceNamespace: openshift-marketplace
- 1
- 설치 계획에 대한 사용자 승인 정책입니다.
다음 명령을 입력하여 Local Storage Operator 오브젝트를 생성합니다.
$ oc apply -f openshift-local-storage.yaml
이 시점에서 OLM(Operator Lifecycle Manager)은 Local Storage Operator를 인식합니다. Operator의 ClusterServiceVersion (CSV)이 대상 네임스페이스에 표시되고 Operator가 제공한 API를 작성할 수 있어야 합니다.
모든 Pod 및 Local Storage Operator가 생성되었는지 확인하여 로컬 스토리지 설치를 확인합니다.
필요한 모든 Pod가 생성되었는지 확인합니다.
$ oc -n openshift-local-storage get pods
출력 예
NAME READY STATUS RESTARTS AGE local-storage-operator-746bf599c9-vlt5t 1/1 Running 0 19m
CSV(ClusterServiceVersion) YAML 매니페스트를 확인하여
openshift-local-storage
프로젝트에서 Local Storage Operator를 사용할 수 있는지 확인합니다.$ oc get csvs -n openshift-local-storage
출력 예
NAME DISPLAY VERSION REPLACES PHASE local-storage-operator.4.2.26-202003230335 Local Storage 4.2.26-202003230335 Succeeded
모든 확인이 통과되면 Local Storage Operator가 성공적으로 설치됩니다.
4.12.1.2. Local Storage Operator를 사용하여 로컬 볼륨을 프로비저닝
동적 프로비저닝을 통해 로컬 볼륨을 생성할 수 없습니다. 대신 Local Storage Operator에서 영구 볼륨을 생성할 수 있습니다. 로컬 볼륨 프로비저너는 정의된 리소스에 지정된 경로에서 모든 파일 시스템 또는 블록 볼륨 장치를 찾습니다.
사전 요구 사항
- Local Storage Operator가 설치되어 있습니다.
다음 조건을 충족하는 로컬 디스크가 있습니다.
- 노드에 연결되어 있습니다.
- 마운트되지 않았습니다.
- 파티션이 포함되어 있지 않습니다.
절차
로컬 볼륨 리소스를 생성합니다. 이 리소스는 로컬 볼륨에 대한 노드 및 경로를 정의해야 합니다.
참고동일한 장치에 다른 스토리지 클래스 이름을 사용하지 마십시오. 이렇게 하면 여러 영구 볼륨(PV)이 생성됩니다.
예: Filesystem
apiVersion: "local.storage.openshift.io/v1" kind: "LocalVolume" metadata: name: "local-disks" namespace: "openshift-local-storage" 1 spec: nodeSelector: 2 nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/hostname operator: In values: - ip-10-0-140-183 - ip-10-0-158-139 - ip-10-0-164-33 storageClassDevices: - storageClassName: "local-sc" 3 volumeMode: Filesystem 4 fsType: xfs 5 devicePaths: 6 - /path/to/device 7
- 1
- Local Storage Operator가 설치된 네임스페이스입니다.
- 2
- 선택 사항: 로컬 스토리지 볼륨이 연결된 노드 목록이 포함된 노드 선택기입니다. 이 예에서는
oc get node
에서 가져온 노드 호스트 이름을 사용합니다. 값을 정의하지 않으면 Local Storage Operator에서 사용 가능한 모든 노드에서 일치하는 디스크를 찾습니다. - 3
- 영구 볼륨 오브젝트를 생성할 때 사용할 스토리지 클래스의 이름입니다. Local Storage Operator가 존재하지 않는 경우 스토리지 클래스를 자동으로 생성합니다. 이 로컬 볼륨 세트를 고유하게 식별하는 스토리지 클래스를 사용해야 합니다.
- 4
- 로컬 볼륨의 유형을 정의하는
Filesystem
또는Block
중 하나에 해당 볼륨 모드입니다.참고원시 블록 볼륨(
volumeMode: Block
)은 파일 시스템으로 포맷되지 않습니다. Pod에서 실행되는 모든 애플리케이션이 원시 블록 장치를 사용할 수 있는 경우에만 이 모드를 사용합니다. - 5
- 로컬 볼륨이 처음 마운트될 때 생성되는 파일 시스템입니다.
- 6
- 선택할 로컬 스토리지 장치 목록이 포함된 경로입니다.
- 7
- 이 값을
LocalVolume
리소스의 실제 로컬 디스크 파일 경로(예:/dev/disk/
)로 바꿉니다. 프로비저너가 배포되면 이러한 로컬 디스크에 PV가 생성됩니다.by-id
/wwn참고RHEL KVM을 사용하여 OpenShift Container Platform을 실행하는 경우 VM 디스크에 일련 번호를 할당해야 합니다. 그렇지 않으면 재부팅 후 VM 디스크를 확인할 수 없습니다.
virsh edit <VM
> 명령을 사용하여 <serial>mydisk</serial
> 정의를 추가할 수 있습니다.
예: 블록
apiVersion: "local.storage.openshift.io/v1" kind: "LocalVolume" metadata: name: "local-disks" namespace: "openshift-local-storage" 1 spec: nodeSelector: 2 nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/hostname operator: In values: - ip-10-0-136-143 - ip-10-0-140-255 - ip-10-0-144-180 storageClassDevices: - storageClassName: "local-sc" 3 volumeMode: Block 4 devicePaths: 5 - /path/to/device 6
- 1
- Local Storage Operator가 설치된 네임스페이스입니다.
- 2
- 선택 사항: 로컬 스토리지 볼륨이 연결된 노드 목록이 포함된 노드 선택기입니다. 이 예에서는
oc get node
에서 가져온 노드 호스트 이름을 사용합니다. 값을 정의하지 않으면 Local Storage Operator에서 사용 가능한 모든 노드에서 일치하는 디스크를 찾습니다. - 3
- 영구 볼륨 오브젝트를 생성할 때 사용할 스토리지 클래스의 이름입니다.
- 4
- 로컬 볼륨의 유형을 정의하는
Filesystem
또는Block
중 하나에 해당 볼륨 모드입니다. - 5
- 선택할 로컬 스토리지 장치 목록이 포함된 경로입니다.
- 6
- 이 값을
LocalVolume
리소스의 실제 로컬 디스크 파일 경로(예:dev/disk/
)로 바꿉니다. 프로비저너가 배포되면 이러한 로컬 디스크에 PV가 생성됩니다.by-id
/wwn
참고RHEL KVM을 사용하여 OpenShift Container Platform을 실행하는 경우 VM 디스크에 일련 번호를 할당해야 합니다. 그렇지 않으면 재부팅 후 VM 디스크를 확인할 수 없습니다.
virsh edit <VM
> 명령을 사용하여 <serial>mydisk</serial
> 정의를 추가할 수 있습니다.OpenShift Container Platform 클러스터에 로컬 볼륨 리소스를 생성합니다. 방금 생성한 파일을 지정합니다.
$ oc create -f <local-volume>.yaml
프로비저너가 생성되었고 해당 데몬 세트가 생성되었는지 확인합니다.
$ oc get all -n openshift-local-storage
출력 예
NAME READY STATUS RESTARTS AGE pod/diskmaker-manager-9wzms 1/1 Running 0 5m43s pod/diskmaker-manager-jgvjp 1/1 Running 0 5m43s pod/diskmaker-manager-tbdsj 1/1 Running 0 5m43s pod/local-storage-operator-7db4bd9f79-t6k87 1/1 Running 0 14m NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/local-storage-operator-metrics ClusterIP 172.30.135.36 <none> 8383/TCP,8686/TCP 14m NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE daemonset.apps/diskmaker-manager 3 3 3 3 3 <none> 5m43s NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/local-storage-operator 1/1 1 1 14m NAME DESIRED CURRENT READY AGE replicaset.apps/local-storage-operator-7db4bd9f79 1 1 1 14m
필요한 데몬 세트 프로세스 및 현재 개수를 기록해 둡니다.
0
의 개수는 레이블 선택기가 유효하지 않음을 나타냅니다.영구 볼륨이 생성되었는지 확인합니다.
$ oc get pv
출력 예
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE local-pv-1cec77cf 100Gi RWO Delete Available local-sc 88m local-pv-2ef7cd2a 100Gi RWO Delete Available local-sc 82m local-pv-3fa1c73 100Gi RWO Delete Available local-sc 48m
LocalVolume
오브젝트 편집은 안전하지 않은 작업이므로 이를 수행하면 기존 영구 볼륨의 fsType
또는 volumeMode
가 변경되지 않습니다.
4.12.1.3. Local Storage Operator없이 로컬 볼륨 프로비저닝
동적 프로비저닝을 통해 로컬 볼륨을 생성할 수 없습니다. 대신 개체 정의에서 영구 볼륨(PV)을 정의하여 영구 볼륨을 생성할 수 있습니다. 로컬 볼륨 프로비저너는 정의된 리소스에 지정된 경로에서 모든 파일 시스템 또는 블록 볼륨 장치를 찾습니다.
PVC가 삭제될 때 PV를 수동으로 프로비저닝하면 PV를 재사용할 때 데이터 누출의 위험이 발생할 수 있습니다. Local Storage Operator는 로컬 PV를 프로비저닝할 때 장치의 라이프 사이클을 자동화하는 것이 좋습니다.
사전 요구 사항
- 로컬 디스크가 OpenShift Container Platform 노드에 연결되어 있습니다.
절차
PV를 정의합니다.
PersistentVolume
오브젝트 정의로example-pv-filesystem.yaml
또는example-pv-block.yaml
과 같은 파일을 생성합니다. 이 리소스는 로컬 볼륨에 대한 노드 및 경로를 정의해야 합니다.참고동일한 장치에 다른 스토리지 클래스 이름을 사용하지 마십시오. 이렇게 하면 여러 PV가 생성됩니다.
example-pv-filesystem.yaml
apiVersion: v1 kind: PersistentVolume metadata: name: example-pv-filesystem spec: capacity: storage: 100Gi volumeMode: Filesystem 1 accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Delete storageClassName: local-sc 2 local: path: /dev/xvdf 3 nodeAffinity: required: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/hostname operator: In values: - example-node
참고원시 블록 볼륨(
volumeMode: block
)은 파일 시스템과 함께 포맷되지 않습니다. Pod에서 실행되는 모든 애플리케이션이 원시 블록 장치를 사용할 수 있는 경우에만 이 모드를 사용합니다.example-pv-block.yaml
apiVersion: v1 kind: PersistentVolume metadata: name: example-pv-block spec: capacity: storage: 100Gi volumeMode: Block 1 accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Delete storageClassName: local-sc 2 local: path: /dev/xvdf 3 nodeAffinity: required: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/hostname operator: In values: - example-node
OpenShift Container Platform 클러스터에 PV 리소스를 생성합니다. 방금 생성한 파일을 지정합니다.
$ oc create -f <example-pv>.yaml
로컬 PV가 생성되었는지 확인합니다.
$ oc get pv
출력 예
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE example-pv-filesystem 100Gi RWO Delete Available local-sc 3m47s example-pv1 1Gi RWO Delete Bound local-storage/pvc1 local-sc 12h example-pv2 1Gi RWO Delete Bound local-storage/pvc2 local-sc 12h example-pv3 1Gi RWO Delete Bound local-storage/pvc3 local-sc 12h
4.12.1.4. 로컬 볼륨 영구 볼륨 클레임 생성
로컬 볼륨은 Pod가 액세스할 수 있는 영구 볼륨 클레임(PVC)으로서 정적으로 생성되어야 합니다.
사전 요구 사항
- 영구 볼륨은 로컬 볼륨 프로비저너를 사용하여 생성됩니다.
절차
해당 스토리지 클래스를 사용하여 PVC를 생성합니다.
kind: PersistentVolumeClaim apiVersion: v1 metadata: name: local-pvc-name 1 spec: accessModes: - ReadWriteOnce volumeMode: Filesystem 2 resources: requests: storage: 100Gi 3 storageClassName: local-sc 4
방금 작성한 파일을 지정하여 OpenShift Container Platform 클러스터에서 PVC를 생성합니다.
$ oc create -f <local-pvc>.yaml
4.12.1.5. 로컬 클레임 연결
로컬 볼륨이 영구 볼륨 클레임에 매핑된 후 리소스 내부에서 지정할 수 있습니다.
사전 요구 사항
- 동일한 네임스페이스에 영구 볼륨 클레임이 있어야 합니다.
절차
리소스 사양에 정의된 클레임을 포함합니다. 다음 예시는 Pod 내에서 영구 볼륨 클레임을 선언합니다.
apiVersion: v1 kind: Pod spec: # ... containers: volumeMounts: - name: local-disks 1 mountPath: /data 2 volumes: - name: local-disks persistentVolumeClaim: claimName: local-pvc-name 3 # ...
방금 생성한 파일을 지정하여 OpenShift Container Platform 클러스터에 리소스를 생성합니다.
$ oc create -f <local-pod>.yaml
4.12.1.6. 로컬 스토리지 장치에 대한 검색 및 프로비저닝 자동화
로컬 스토리지 Operator는 로컬 스토리지 검색 및 프로비저닝을 자동화합니다. 이 기능을 사용하면 배포 중에 연결된 장치가 있는 베어 메탈, VMware 또는 AWS 스토어 인스턴스와 같이 동적 프로비저닝을 사용할 수 없는 경우 설치를 단순화할 수 있습니다.
자동 검색 및 프로비저닝은 기술 프리뷰 기능 전용입니다. Technology Preview 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.
자동 검색 및 프로비저닝은 온프레미스 또는 플랫폼 관련 배포와 함께 Red Hat OpenShift Data Foundation을 배포하는 데 사용되는 경우 완전히 지원됩니다.
다음 절차에 따라 로컬 장치를 자동으로 검색하고 선택한 장치에 대한 로컬 볼륨을 자동으로 프로비저닝하십시오.
LocalVolumeSet
오브젝트를 주의해서 사용하십시오. 로컬 디스크에서 PV(영구 볼륨)를 자동으로 프로비저닝하면 로컬 PV에서 일치하는 모든 장치를 클레임할 수 있습니다. LocalVolumeSet
오브젝트를 사용하는 경우 Local Storage Operator가 노드에서 로컬 장치를 관리하는 유일한 엔티티인지 확인합니다. 노드를 두 번 이상 대상으로 하는 LocalVolumeSet
의 여러 인스턴스를 생성할 수 없습니다.
사전 요구 사항
- 클러스터 관리자 권한이 있어야 합니다.
- Local Storage Operator가 설치되어 있습니다.
- OpenShift Container Platform 노드에 로컬 디스크가 연결되어 있습니다.
-
OpenShift Container Platform 웹 콘솔과
oc
명령줄 인터페이스(CLI)에 액세스할 수 있습니다.
절차
웹 콘솔에서 로컬 장치를 자동으로 검색할 수 있도록 하려면 다음을 수행합니다.
-
Operators
설치된 Operators를 클릭합니다. -
openshift-local-storage
네임스페이스에서 로컬 스토리지를 클릭합니다. - 로컬 볼륨 검색 탭을 클릭합니다.
- 로컬 볼륨 검색 생성 을 클릭한 다음 양식 보기 또는 YAML 보기를 선택합니다.
-
LocalVolumeDiscovery
오브젝트 매개변수를 구성합니다. Create를 클릭합니다.
Local Storage Operator는
auto-discover-devices
라는 로컬 볼륨 검색 인스턴스를 생성합니다.
-
Operators
노드에 사용 가능한 장치 목록을 표시하려면 다음을 수행합니다.
- OpenShift Container Platform 웹 콘솔에 로그인합니다.
-
컴퓨팅
노드로 이동합니다. - 열기를 원하는 노드 이름을 클릭합니다. "노드 세부 정보" 페이지가 표시됩니다.
선택한 장치 목록을 표시하려면 디스크 탭을 선택합니다.
로컬 디스크가 추가되거나 제거되면 장치 목록이 지속적으로 업데이트됩니다. 장치를 이름, 상태, 유형, 모델, 용량 및 모드로 필터링할 수 있습니다.
웹 콘솔에서 발견된 장치에 대한 로컬 볼륨을 자동으로 프로비저닝하려면 다음을 수행합니다.
-
Operator
설치된 Operator로 이동하고 Operator 목록에서 로컬 스토리지를 선택합니다. -
로컬 볼륨 세트
로컬 볼륨 세트 만들기를 선택합니다. - 볼륨 세트 이름과 스토리지 클래스 이름을 입력합니다.
그에 따라 필터를 적용하려면 모든 노드 또는 노드 선택을 선택합니다.
참고모든 노드 또는 노드 선택을 사용하여 필터링하는지의 여부와 관계없이 작업자 노드만 사용할 수 있습니다.
로컬 볼륨 세트에 적용할 디스크 유형, 모드, 크기 및 제한을 선택하고 만들기를 클릭합니다.
몇 분 후에 “Operator 조정됨”을 나타내는 메시지가 표시됩니다.
-
Operator
대신 CLI에서 검색된 장치에 대한 로컬 볼륨을 프로비저닝하려면 다음을 수행합니다.
다음 예와 같이
local-volume-set.yaml
과 같은 로컬 볼륨 세트를 정의하는 오브젝트 YAML 파일을 생성합니다.apiVersion: local.storage.openshift.io/v1alpha1 kind: LocalVolumeSet metadata: name: example-autodetect spec: nodeSelector: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/hostname operator: In values: - worker-0 - worker-1 storageClassName: local-sc 1 volumeMode: Filesystem fsType: ext4 maxDeviceCount: 10 deviceInclusionSpec: deviceTypes: 2 - disk - part deviceMechanicalProperties: - NonRotational minSize: 10G maxSize: 100G models: - SAMSUNG - Crucial_CT525MX3 vendors: - ATA - ST2000LM
로컬 볼륨 세트 오브젝트를 생성합니다.
$ oc apply -f local-volume-set.yaml
로컬 영구 볼륨이 스토리지 클래스를 기반으로 동적으로 프로비저닝되었는지 확인합니다.
$ oc get pv
출력 예
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE local-pv-1cec77cf 100Gi RWO Delete Available local-sc 88m local-pv-2ef7cd2a 100Gi RWO Delete Available local-sc 82m local-pv-3fa1c73 100Gi RWO Delete Available local-sc 48m
결과는 노드에서 제거된 후 삭제됩니다. 심볼릭 링크는 수동으로 제거해야 합니다.
4.12.1.7. Local Storage Operator Pod에서 허용 오차 사용
테인트를 노드에 적용하여 일반 워크로드를 실행하지 못하도록 할 수 있습니다. Local Storage Operator가 테인트된 노드를 사용하도록 허용하려면 Pod
또는 DaemonSet
정의에 허용 오차를 추가해야 합니다. 그러면 생성된 리소스가 이러한 테인트된 노드에서 실행될 수 있습니다.
LocalVolume
리소스를 통해 Local Storage Operator Pod에 허용 오차를 적용하고 노드 사양을 통해 노드에 테인트를 적용합니다. 노드의 테인트는 해당 테인트를 허용하지 않는 모든 Pod를 거절하도록 노드에 지시합니다. 다른 Pod에 없는 특정 테인트를 사용하면 Local Storage Operator Pod가 해당 노드에서도 실행될 수 있습니다.
테인트 및 허용 오차는 key, value 및 effect로 구성되어 있습니다. 인수로는 key=value:effect
로 표시됩니다. Operator는 이러한 매개 변수 중 하나를 비워두는 것을 허용합니다.
사전 요구 사항
- Local Storage Operator가 설치되어 있습니다.
- 로컬 디스크는 테인트와 함께 OpenShift Container Platform 노드에 연결되어 있습니다.
- 테인트된 노드는 로컬 스토리지를 프로비저닝해야 합니다.
절차
테인트된 노드에서 스케줄링을 위해 로컬 볼륨을 구성하려면 다음을 수행하십시오.
다음 예와 같이
Pod
를 정의하는 YAML 파일을 수정하고LocalVolume
사양을 추가합니다.apiVersion: "local.storage.openshift.io/v1" kind: "LocalVolume" metadata: name: "local-disks" namespace: "openshift-local-storage" spec: tolerations: - key: localstorage 1 operator: Equal 2 value: "localstorage" 3 storageClassDevices: - storageClassName: "local-sc" volumeMode: Block 4 devicePaths: 5 - /dev/xvdg
선택 사항: 테인트된 노드에만 로컬 영구 볼륨을 생성하려면 다음 예와 같이 YAML 파일을 수정하고
LocalVolume
사양을 추가합니다.spec: tolerations: - key: node-role.kubernetes.io/master operator: Exists
정의된 허용 오차가 결과 데몬 세트로 전달되어, 지정된 테인트를 포함하는 노드에 대해 디스크 제조 업체 및 프로비저너 Pod를 생성할 수 있습니다.
4.12.1.8. Local Storage Operator 지표
OpenShift Container Platform은 Local Storage Operator에 대한 다음 지표를 제공합니다.
-
lso_discovery_disk_count
: 각 노드에서 발견된 총 장치 수 -
lso_lvset_provisioned_PV_count
:LocalVolumeSet
개체에서 생성한 총 PV 수 -
lso_lvset_unmatched_disk_count
: 기준 불일치로 인해 Local Storage Operator가 프로비저닝을 위해 선택하지 않은 총 디스크 수 -
lso_lvset_orphaned_symlink_count
:LocalVolumeSet
개체 기준과 더 이상 일치하지 않는 PV가 있는 장치 수 -
lso_lv_orphaned_symlink_count
:LocalVolume
오브젝트 기준과 더 이상 일치하지 않는 PV가 있는 장치 수 -
lso_lv_provisioned_PV_count
:LocalVolume
의 프로비저닝된 총 PV 수
이러한 메트릭을 사용하려면 다음을 수행해야합니다.
- Local Storage Operator를 설치할 때 모니터링 지원을 활성화합니다.
-
OpenShift Container Platform 4.9 이상으로 업그레이드하는 경우 네임스페이스에
operator-metering=true
레이블을 추가하여 메트릭을 수동으로 지원합니다.
메트릭에 대한 자세한 내용은 메트릭 관리를 참조하십시오.
4.12.1.9. Local Storage Operator 리소스 삭제
4.12.1.9.1. 로컬 볼륨 또는 로컬 볼륨 세트 제거
때때로 로컬 볼륨 및 로컬 볼륨 세트를 삭제해야 합니다. 리소스에서 항목을 제거하고 영구 볼륨을 삭제하는 것은 일반적으로 충분합니다. 동일한 장치 경로를 재사용하거나 다른 스토리지 클래스로 관리하려면 추가 단계가 필요합니다.
다음 절차에서는 로컬 볼륨을 제거하는 예시를 간단히 설명합니다. 동일한 절차를 사용하여 로컬 볼륨 세트 사용자 정의 리소스의 심볼릭 링크를 제거할 수도 있습니다.
사전 요구 사항
영구 볼륨이
해제된
또는사용 가능
상태여야 합니다.주의아직 사용 중인 영구 볼륨을 삭제하면 데이터 손실 또는 손상이 발생할 수 있습니다.
절차
이전에 생성된 로컬 볼륨을 편집하여 원하는 디스크를 제거합니다.
클러스터 리소스를 편집합니다.
$ oc edit localvolume <name> -n openshift-local-storage
-
devicePaths
아래의 행으로 이동하여 원하는 디스크를 나타내는 모든 항목을 삭제합니다.
생성된 영구 볼륨을 삭제합니다.
$ oc delete pv <pv-name>
디렉터리를 삭제하고 노드에 심볼릭 링크를 포함했습니다.
주의다음 단계는 루트 사용자로 노드에 액세스하는 것입니다. 이 절차의 단계 이후에 노드 상태를 수정하면 클러스터가 불안정해질 수 있습니다.
$ oc debug node/<node-name> -- chroot /host rm -rf /mnt/local-storage/<sc-name> 1
- 1
- 로컬 볼륨을 생성하기 위해 사용되는 스토리지 클래스의 이름입니다.
4.12.1.9.2. Local Storage Operator 설치 제거
Local Storage Operator의 설치를 제거하려면 openshift-local-storage
프로젝트에서 Operator 및 모든 생성된 리소스를 제거해야 합니다.
로컬 스토리지 PV를 아직 사용 중 일 때 Local Storage Operator의 설치를 제거하는 것은 권장되지 않습니다. Operator 제거 후 PV는 유지되지만, PV 및 로컬 스토리지 리소스를 제거하지 않고 Operator를 제거한 후 다시 설치하면 알 수 없는 동작이 발생할 수 있습니다.
사전 요구 사항
- OpenShift Container Platform 웹 콘솔에 액세스합니다.
절차
프로젝트에 설치된 로컬 볼륨 리소스(예: localvolume ,
localvolume
setlocalvolumediscovery
)를 삭제합니다.$ oc delete localvolume --all --all-namespaces $ oc delete localvolumeset --all --all-namespaces $ oc delete localvolumediscovery --all --all-namespaces
웹 콘솔에서 Local Storage Operator의 설치를 제거합니다.
- OpenShift Container Platform 웹 콘솔에 로그인합니다.
-
Operators
설치된 Operator로 이동합니다. - Local Storage를 필터 상자에 입력하여 Local Storage Operator를 찾습니다.
- Local Storage Operator 끝에 있는 옵션 메뉴 를 클릭합니다.
- Operator 제거를 클릭합니다.
- 표시되는 창에서 제거를 클릭합니다.
Local Storage Operator에서 생성한 PV는 삭제될 때까지 클러스터에 남아 있습니다. 이러한 볼륨이 더 이상 사용되지 않으면 다음 명령을 실행하여 해당 볼륨을 삭제합니다.
$ oc delete pv <pv-name>
openshift-local-storage
프로젝트를 삭제합니다.$ oc delete project openshift-local-storage
4.12.2. hostPath를 사용하는 영구 스토리지
OpenShift Container Platform 클러스터의 hostPath 볼륨은 호스트 노드 파일 시스템의 파일 또는 디렉터리를 Pod에 마운트합니다. 대부분의 Pod에는 hostPath 볼륨이 필요하지 않지만 테스트에 필요한 빠른 옵션을 제공합니다.
클러스터 관리자는 권한으로 실행되도록 Pod를 구성해야 합니다. 이를 통해 동일한 노드의 Pod에 액세스 권한이 부여됩니다.
4.12.2.1. 개요
OpenShift Container Platform은 단일 노드 클러스터에서 개발 및 테스트를 위해 hostPath 마운트를 지원합니다.
프로덕션 클러스터에서는 hostPath를 사용할 수 없습니다. 대신, 클러스터 관리자는 GCE 영구 디스크 볼륨, NFS 공유 또는 Amazon EBS 볼륨과 같은 네트워크 리소스를 프로비저닝합니다. 네트워크 리소스는 스토리지 클래스 사용을 지원하여 동적 프로비저닝을 설정합니다.
hostPath 볼륨은 정적으로 프로비저닝해야 합니다.
컨테이너 루트, /
또는 호스트와 컨테이너에서 동일한 경로에 마운트하지 마십시오. 컨테이너에 충분한 권한이 있는 경우 호스트 시스템이 손상될 수 있습니다. /host
를 사용하여 호스트를 마운트하는 것이 안전합니다. 다음 예는 /host
의 컨테이너에 마운트되는 호스트의 /
디렉터리를 보여줍니다.
apiVersion: v1 kind: Pod metadata: name: test-host-mount spec: containers: - image: registry.access.redhat.com/ubi8/ubi name: test-container command: ['sh', '-c', 'sleep 3600'] volumeMounts: - mountPath: /host name: host-slash volumes: - name: host-slash hostPath: path: / type: ''
4.12.2.2. 정적으로 hostPath 볼륨을 프로비저닝
hostPath 볼륨을 사용하는 Pod는 수동(정적) 프로비저닝을 통해 참조해야 합니다.
절차
PV(영구 볼륨)를 정의합니다.
PersistentVolume
오브젝트 정의를 사용하여pv.yaml
파일을 생성합니다.apiVersion: v1 kind: PersistentVolume metadata: name: task-pv-volume 1 labels: type: local spec: storageClassName: manual 2 capacity: storage: 5Gi accessModes: - ReadWriteOnce 3 persistentVolumeReclaimPolicy: Retain hostPath: path: "/mnt/data" 4
파일에서 PV를 생성합니다.
$ oc create -f pv.yaml
PVC(영구 볼륨 클레임)를 정의합니다.
PersistentVolumeClaim
오브젝트 정의를 사용하여pvc.yaml
파일을 생성합니다.apiVersion: v1 kind: PersistentVolumeClaim metadata: name: task-pvc-volume spec: accessModes: - ReadWriteOnce resources: requests: storage: 1Gi storageClassName: manual
파일에서 PVC를 생성합니다.
$ oc create -f pvc.yaml
4.12.2.3. 권한이 있는 Pod에서 hostPath 공유 마운트
영구 볼륨 클레임을 생성한 후 애플리케이션에 의해 내부에서 사용될 수 있습니다. 다음 예시는 Pod 내부에서 이 공유를 마운트하는 방법을 보여줍니다.
사전 요구 사항
- 기본 hostPath 공유에 매핑된 영구 볼륨 클레임이 있습니다.
절차
기존 영구 볼륨 클레임을 마운트하는 권한이 있는 Pod를 생성합니다.
apiVersion: v1 kind: Pod metadata: name: pod-name 1 spec: containers: ... securityContext: privileged: true 2 volumeMounts: - mountPath: /data 3 name: hostpath-privileged ... securityContext: {} volumes: - name: hostpath-privileged persistentVolumeClaim: claimName: task-pvc-volume 4
4.12.3. 논리 볼륨 관리자 스토리지를 사용하는 영구 스토리지
LVM(Logical Volume Manager) 스토리지는 TopoLVM CSI 드라이버를 사용하여 단일 노드 OpenShift 클러스터에서 로컬 스토리지를 동적으로 프로비저닝합니다.
LVM Storage는 Logical Volume Manager를 사용하여 씬 프로비저닝 볼륨을 생성하고 제한된 리소스 단일 노드 OpenShift 클러스터에서 블록 스토리지의 동적 프로비저닝을 제공합니다.
LVM 스토리지를 사용하여 볼륨 그룹, PVC(영구 볼륨 클레임), 볼륨 스냅샷 및 볼륨 복제를 생성할 수 있습니다.
4.12.3.1. 논리 볼륨 관리자 스토리지 설치
단일 노드 OpenShift 클러스터에 LVM(Logical Volume Manager) 스토리지를 설치하고 워크로드의 스토리지를 동적으로 프로비저닝하도록 구성할 수 있습니다.
OpenShift Container Platform CLI(oc
), OpenShift Container Platform 웹 콘솔 또는 RHACM(Red Hat Advanced Cluster Management)을 사용하여 단일 노드 OpenShift 클러스터에 LVM 스토리지를 배포할 수 있습니다.
4.12.3.1.1. LVM 스토리지를 설치하기 위한 사전 요구 사항
LVM 스토리지를 설치하기 위한 전제 조건은 다음과 같습니다.
- 최소 10밀리CPU 및 100MiB의 RAM이 있는지 확인합니다.
- 모든 관리 클러스터에 스토리지를 프로비저닝하는 데 사용되는 전용 디스크가 있는지 확인합니다. LVM 스토리지는 비어 있고 파일 시스템 서명이 포함되지 않은 디스크만 사용합니다. 디스크가 비어 있고 파일 시스템 서명을 포함하지 않도록 하려면 디스크를 사용하기 전에 초기화하십시오.
이전 LVM 스토리지 설치에서 구성한 스토리지 장치를 재사용할 수 있는 개인 CI 환경에 LVM 스토리지를 설치하기 전에 사용하지 않는 디스크를 지웁니다. LVM 스토리지를 설치하기 전에 디스크를 지우지 않으면 수동 조작 없이 디스크를 재사용할 수 없습니다.
참고사용 중인 디스크를 초기화할 수 없습니다.
- RHACM(Red Hat Advanced Cluster Management)을 사용하여 LVM 스토리지를 설치하려면 OpenShift Container Platform 클러스터에 RHACM을 설치해야 합니다. RHACM을 사용하여 LVM 스토리지 설치 섹션을 참조하십시오.
4.12.3.1.2. OpenShift Container Platform 웹 콘솔을 사용하여 LVM 스토리지 설치
Red Hat OpenShift Container Platform OperatorHub를 사용하여 LVM 스토리지를 설치할 수 있습니다.
사전 요구 사항
- 단일 노드 OpenShift 클러스터에 액세스할 수 있습니다.
-
cluster-admin
및 Operator 설치 권한이 있는 계정을 사용하고 있습니다.
절차
- OpenShift Container Platform 웹 콘솔에 로그인합니다.
-
Operators
OperatorHub를 클릭합니다. -
스크롤하거나 키워드로
필터링
상자에 LVM 스토리지 를 입력하여 LVM 스토리지를 찾습니다. - 설치를 클릭합니다.
Operator 설치 페이지에서 다음 옵션을 설정합니다.
- stable-4.12 로 채널을 업데이트합니다.
- 클러스터의 특정 네임스페이스로 설치 모드 입니다.
-
Operator 권장 네임스페이스 openshift-storage로 네임스페이스 가 설치되어 있습니다.
openshift-storage
네임스페이스가 없으면 Operator 설치 중에 생성됩니다. 자동 또는 수동으로의 승인 전략 .
자동 업데이트를 선택하면 OLM(Operator Lifecycle Manager)은 개입 없이 Operator의 실행 중인 인스턴스를 자동으로 업그레이드합니다.
수동 업데이트를 선택하면 OLM에서 업데이트 요청을 생성합니다. 클러스터 관리자는 Operator를 최신 버전으로 업데이트하기 위해 해당 업데이트 요청을 수동으로 승인해야 합니다.
- 설치를 클릭합니다.
검증 단계
- LVM Storage에 성공적으로 설치를 나타내는 녹색 눈금이 표시되는지 확인합니다.
4.12.3.1.3. OpenShift 웹 콘솔을 사용하여 설치된 LVM 스토리지 설치 제거
Red Hat OpenShift Container Platform 웹 콘솔을 사용하여 LVM 스토리지를 설치 제거할 수 있습니다.
사전 요구 사항
- LVM Storage에서 프로비저닝한 스토리지를 사용하는 클러스터의 모든 애플리케이션을 삭제하셨습니다.
- LVM 스토리지를 사용하여 프로비저닝된 PVC(영구 볼륨 클레임) 및 PV(영구 볼륨)를 삭제했습니다.
- LVM Storage에서 프로비저닝한 모든 볼륨 스냅샷을 삭제했습니다.
-
oc get logicalvolume
명령을 사용하여 논리 볼륨 리소스가 없음을 확인했습니다. -
cluster-admin
권한이 있는 계정을 사용하여 단일 노드 OpenShift 클러스터에 액세스할 수 있습니다.
절차
-
Operator
설치된 Operator 페이지에서 LVM Storage 로 스크롤하거나 이름별 필터링 에 LVM Storage
를 입력하여 찾습니다. - LVMCluster 탭을 클릭합니다.
- LVMCluster 페이지 오른쪽에 있는 작업 드롭다운 메뉴에서 LVMCluster 삭제 를 선택합니다.
- 세부 정보 탭을 클릭합니다.
- Operator 상세 정보 페이지 오른쪽에 있는 작업 드롭다운 메뉴에서 Operator 제거를 선택합니다.
- 제거를 선택합니다. LVM 스토리지는 실행을 중지하고 완전히 제거됩니다.
4.12.3.1.4. RHACM을 사용한 LVM 스토리지 설치
LVM Storage는 RHACM(Red Hat Advanced Cluster Management)을 사용하여 단일 노드 OpenShift 클러스터에 배포됩니다. PlacementRule
리소스에 지정된 선택기와 일치하는 관리 클러스터에 Operator를 배포하고 구성하는 RHACM에 정책
오브젝트를 생성합니다. 이 정책은 나중에 가져오고 배치 규칙을 충족하는 클러스터에도 적용됩니다.
사전 요구 사항
-
cluster-admin
및 Operator 설치 권한이 있는 계정을 사용하여 RHACM 클러스터에 액세스할 수 있습니다. - LVM 스토리지에서 사용할 각 단일 노드 OpenShift 클러스터의 전용 디스크입니다.
- 단일 노드 OpenShift 클러스터는 RHACM에서 가져오거나 생성해야 합니다.
절차
- OpenShift Container Platform 인증 정보를 사용하여 RHACM CLI에 로그인합니다.
정책을 생성할 네임스페이스를 생성합니다.
# oc create ns lvms-policy-ns
정책을 생성하려면 다음 YAML을
policy-lvms-operator.yaml
과 같은 이름으로 파일에 저장합니다.apiVersion: apps.open-cluster-management.io/v1 kind: PlacementRule metadata: name: placement-install-lvms spec: clusterConditions: - status: "True" type: ManagedClusterConditionAvailable clusterSelector: 1 matchExpressions: - key: mykey operator: In values: - myvalue --- apiVersion: policy.open-cluster-management.io/v1 kind: PlacementBinding metadata: name: binding-install-lvms placementRef: apiGroup: apps.open-cluster-management.io kind: PlacementRule name: placement-install-lvms subjects: - apiGroup: policy.open-cluster-management.io kind: Policy name: install-lvms --- apiVersion: policy.open-cluster-management.io/v1 kind: Policy metadata: annotations: policy.open-cluster-management.io/categories: CM Configuration Management policy.open-cluster-management.io/controls: CM-2 Baseline Configuration policy.open-cluster-management.io/standards: NIST SP 800-53 name: install-lvms spec: disabled: false remediationAction: enforce policy-templates: - objectDefinition: apiVersion: policy.open-cluster-management.io/v1 kind: ConfigurationPolicy metadata: name: install-lvms spec: object-templates: - complianceType: musthave objectDefinition: apiVersion: v1 kind: Namespace metadata: labels: openshift.io/cluster-monitoring: "true" pod-security.kubernetes.io/enforce: privileged pod-security.kubernetes.io/audit: privileged pod-security.kubernetes.io/warn: privileged name: openshift-storage - complianceType: musthave objectDefinition: apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: openshift-storage-operatorgroup namespace: openshift-storage spec: targetNamespaces: - openshift-storage - complianceType: musthave objectDefinition: apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: lvms namespace: openshift-storage spec: installPlanApproval: Automatic name: lvms-operator source: redhat-operators sourceNamespace: openshift-marketplace remediationAction: enforce severity: low - objectDefinition: apiVersion: policy.open-cluster-management.io/v1 kind: ConfigurationPolicy metadata: name: lvms spec: object-templates: - complianceType: musthave objectDefinition: apiVersion: lvm.topolvm.io/v1alpha1 kind: LVMCluster metadata: name: my-lvmcluster namespace: openshift-storage spec: storage: deviceClasses: - name: vg1 deviceSelector: 2 paths: - /dev/disk/by-path/pci-0000:87:00.0-nvme-1 - /dev/disk/by-path/pci-0000:88:00.0-nvme-1 thinPoolConfig: name: thin-pool-1 sizePercent: 90 overprovisionRatio: 10 nodeSelector: 3 nodeSelectorTerms: - matchExpressions: - key: app operator: In values: - test1 remediationAction: enforce severity: low
- 1
- LVM Storage를 설치하려는 단일 노드 OpenShift 클러스터에 설정된 라벨과 일치하도록
PlacementRule.spec.clusterSelector
의 키와 값을 바꿉니다. - 2
- 볼륨 그룹을 기본 디스크로 제어하거나 제한하려면
LVMCluster
YAML의deviceSelector
섹션에 디스크의 로컬 경로를 수동으로 지정할 수 있습니다. - 3
- 추가 작업자 노드의 하위 집합인 노드 필터를 추가하려면
nodeSelector
섹션에서 필요한 필터를 지정합니다. LVM Storage는 새 노드가 표시될 때 추가 작업자 노드를 감지하고 사용합니다.
중요이
nodeSelector
노드 필터 일치는 Pod 레이블 일치와 동일하지 않습니다.다음 명령을 실행하여 네임스페이스에 정책을 생성합니다.
# oc create -f policy-lvms-operator.yaml -n lvms-policy-ns 1
- 1
policy-lvms-operator.yaml
은 정책이 저장되는 파일의 이름입니다.
이렇게 하면
lvms-policy-ns
네임스페이스에Policy
,PlacementRule
,PlacementBinding
오브젝트가 생성됩니다. 이 정책은 배치 규칙과 일치하는 클러스터에Namespace
,OperatorGroup
,Subscription
,LVMCluster
리소스를 생성합니다. 그러면 선택 기준과 일치하는 단일 노드 OpenShift 클러스터에 Operator가 배포되고 스토리지를 프로비저닝하는 데 필요한 리소스를 설정하도록 구성합니다. Operator는LVMCluster
CR에 지정된 모든 디스크를 사용합니다. 디스크가 지정되지 않은 경우 Operator는 단일 노드 OpenShift 노드에서 사용되지 않는 디스크를 모두 사용합니다.중요장치를
LVMCluster
에 추가한 후에는 제거할 수 없습니다.
4.12.3.1.5. RHACM을 사용하여 설치된 LVM 스토리지 제거
RHACM을 사용하여 설치한 LVM 스토리지를 제거하려면 Operator 배포 및 구성을 위해 생성한 RHACM 정책을 삭제해야 합니다.
RHACM 정책을 삭제하면 정책이 생성된 리소스는 제거되지 않습니다. 리소스를 제거하려면 추가 정책을 생성해야 합니다.
정책을 삭제할 때 생성된 리소스는 제거되지 않으므로 다음 단계를 수행해야 합니다.
- LVM Storage에서 프로비저닝한 모든 PVC(영구 볼륨 클레임) 및 볼륨 스냅샷을 제거합니다.
-
LVMCluster
리소스를 제거하여 디스크에서 생성된 Logical Volume Manager 리소스를 정리합니다. - 추가 정책을 생성하여 Operator를 제거합니다.
사전 요구 사항
정책을 삭제하기 전에 다음 사항이 삭제되었는지 확인합니다.
- LVM Storage에서 프로비저닝한 스토리지를 사용하는 관리형 클러스터의 모든 애플리케이션.
- LVM 스토리지를 사용하여 프로비저닝된 PVC 및 PV(영구 볼륨)입니다.
- LVM Storage에서 프로비저닝한 모든 볼륨 스냅샷.
-
cluster-admin
역할의 계정을 사용하여 RHACM 클러스터에 액세스할 수 있는지 확인합니다.
절차
OpenShift CLI(
oc
)에서 다음 명령을 사용하여 hub 클러스터에 LVM Storage를 배포하고 구성하기 위해 생성한 RHACM 정책을 삭제합니다.# oc delete -f policy-lvms-operator.yaml -n lvms-policy-ns 1
- 1
policy-lvms-operator.yaml
은 정책이 저장된 파일의 이름입니다.
LVMCluster
리소스를 제거하는 정책을 생성하려면 다음 YAML을 이름이lvms-remove-policy.yaml
과 같은 파일에 저장합니다. 이를 통해 Operator는 클러스터에서 생성한 모든 Logical Volume Manager 리소스를 정리할 수 있습니다.apiVersion: policy.open-cluster-management.io/v1 kind: Policy metadata: name: policy-lvmcluster-delete annotations: policy.open-cluster-management.io/standards: NIST SP 800-53 policy.open-cluster-management.io/categories: CM Configuration Management policy.open-cluster-management.io/controls: CM-2 Baseline Configuration spec: remediationAction: enforce disabled: false policy-templates: - objectDefinition: apiVersion: policy.open-cluster-management.io/v1 kind: ConfigurationPolicy metadata: name: policy-lvmcluster-removal spec: remediationAction: enforce 1 severity: low object-templates: - complianceType: mustnothave objectDefinition: kind: LVMCluster apiVersion: lvm.topolvm.io/v1alpha1 metadata: name: my-lvmcluster namespace: openshift-storage 2 --- apiVersion: policy.open-cluster-management.io/v1 kind: PlacementBinding metadata: name: binding-policy-lvmcluster-delete placementRef: apiGroup: apps.open-cluster-management.io kind: PlacementRule name: placement-policy-lvmcluster-delete subjects: - apiGroup: policy.open-cluster-management.io kind: Policy name: policy-lvmcluster-delete --- apiVersion: apps.open-cluster-management.io/v1 kind: PlacementRule metadata: name: placement-policy-lvmcluster-delete spec: clusterConditions: - status: "True" type: ManagedClusterConditionAvailable clusterSelector: matchExpressions: - key: mykey operator: In values: - myvalue
-
PlacementRule.spec.clusterSelector
필드의 값을 설정하여 LVM Storage를 제거할 클러스터를 선택합니다. 다음 명령을 실행하여 정책을 생성합니다.
# oc create -f lvms-remove-policy.yaml -n lvms-policy-ns
LVMCluster
CR이 제거되었는지 확인하는 정책을 생성하려면check-lvms-remove-policy.yaml
과 같은 이름이 있는 파일에 다음 YAML을 저장합니다.apiVersion: policy.open-cluster-management.io/v1 kind: Policy metadata: name: policy-lvmcluster-inform annotations: policy.open-cluster-management.io/standards: NIST SP 800-53 policy.open-cluster-management.io/categories: CM Configuration Management policy.open-cluster-management.io/controls: CM-2 Baseline Configuration spec: remediationAction: inform disabled: false policy-templates: - objectDefinition: apiVersion: policy.open-cluster-management.io/v1 kind: ConfigurationPolicy metadata: name: policy-lvmcluster-removal-inform spec: remediationAction: inform 1 severity: low object-templates: - complianceType: mustnothave objectDefinition: kind: LVMCluster apiVersion: lvm.topolvm.io/v1alpha1 metadata: name: my-lvmcluster namespace: openshift-storage 2 --- apiVersion: policy.open-cluster-management.io/v1 kind: PlacementBinding metadata: name: binding-policy-lvmcluster-check placementRef: apiGroup: apps.open-cluster-management.io kind: PlacementRule name: placement-policy-lvmcluster-check subjects: - apiGroup: policy.open-cluster-management.io kind: Policy name: policy-lvmcluster-inform --- apiVersion: apps.open-cluster-management.io/v1 kind: PlacementRule metadata: name: placement-policy-lvmcluster-check spec: clusterConditions: - status: "True" type: ManagedClusterConditionAvailable clusterSelector: matchExpressions: - key: mykey operator: In values: - myvalue
다음 명령을 실행하여 정책을 생성합니다.
# oc create -f check-lvms-remove-policy.yaml -n lvms-policy-ns
다음 명령을 실행하여 정책 상태를 확인합니다.
# oc get policy -n lvms-policy-ns
출력 예
NAME REMEDIATION ACTION COMPLIANCE STATE AGE policy-lvmcluster-delete enforce Compliant 15m policy-lvmcluster-inform inform Compliant 15m
정책이 모두 호환되면 다음 YAML을
lvms-uninstall-policy.yaml
과 같은 이름의 파일에 저장하여 LVM 스토리지를 제거하는 정책을 생성합니다.apiVersion: apps.open-cluster-management.io/v1 kind: PlacementRule metadata: name: placement-uninstall-lvms spec: clusterConditions: - status: "True" type: ManagedClusterConditionAvailable clusterSelector: matchExpressions: - key: mykey operator: In values: - myvalue --- apiVersion: policy.open-cluster-management.io/v1 kind: PlacementBinding metadata: name: binding-uninstall-lvms placementRef: apiGroup: apps.open-cluster-management.io kind: PlacementRule name: placement-uninstall-lvms subjects: - apiGroup: policy.open-cluster-management.io kind: Policy name: uninstall-lvms --- apiVersion: policy.open-cluster-management.io/v1 kind: Policy metadata: annotations: policy.open-cluster-management.io/categories: CM Configuration Management policy.open-cluster-management.io/controls: CM-2 Baseline Configuration policy.open-cluster-management.io/standards: NIST SP 800-53 name: uninstall-lvms spec: disabled: false policy-templates: - objectDefinition: apiVersion: policy.open-cluster-management.io/v1 kind: ConfigurationPolicy metadata: name: uninstall-lvms spec: object-templates: - complianceType: mustnothave objectDefinition: apiVersion: v1 kind: Namespace metadata: name: openshift-storage - complianceType: mustnothave objectDefinition: apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: openshift-storage-operatorgroup namespace: openshift-storage spec: targetNamespaces: - openshift-storage - complianceType: mustnothave objectDefinition: apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: lvms-operator namespace: openshift-storage remediationAction: enforce severity: low - objectDefinition: apiVersion: policy.open-cluster-management.io/v1 kind: ConfigurationPolicy metadata: name: policy-remove-lvms-crds spec: object-templates: - complianceType: mustnothave objectDefinition: apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition metadata: name: logicalvolumes.topolvm.io - complianceType: mustnothave objectDefinition: apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition metadata: name: lvmclusters.lvm.topolvm.io - complianceType: mustnothave objectDefinition: apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition metadata: name: lvmvolumegroupnodestatuses.lvm.topolvm.io - complianceType: mustnothave objectDefinition: apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition metadata: name: lvmvolumegroups.lvm.topolvm.io remediationAction: enforce severity: high
다음 명령을 실행하여 정책을 생성합니다.
# oc create -f lvms-uninstall-policy.yaml -ns lvms-policy-ns
추가 리소스
4.12.3.2. LVM 스토리지에 사용되는 장치의 크기를 구성하는 제한 사항
LVM 스토리지를 사용하여 스토리지를 프로비저닝하는 데 사용할 수 있는 장치의 크기를 구성하는 제한 사항은 다음과 같습니다.
- 프로비저닝할 수 있는 총 스토리지 크기는 기본 LVM(Logical Volume Manager) 씬 풀의 크기와 초과 프로비저닝 요인으로 제한됩니다.
논리 볼륨의 크기는 PE(물리 확장 영역) 및 논리 확장 영역(LE)의 크기에 따라 다릅니다.
- 물리 및 논리 장치 생성 중에 PE 및 LE의 크기를 정의할 수 있습니다.
- 기본 PE 및 LE 크기는 4MB입니다.
- PE 크기가 증가하면 커널 제한 및 디스크 공간에 따라 LVM의 최대 크기가 결정됩니다.
아키텍처 | RHEL 6 | RHEL 7 | RHEL 8 | RHEL 9 |
---|---|---|---|---|
32비트 | 16 TB | - | - | - |
64비트 | 8 EB [1] 100 TB [2] | 8 EB [1] 500 TB [2] | 8 EB | 8 EB |
- 중간 크기.
- 테스트된 크기.
4.12.3.3. 논리 볼륨 관리자 클러스터 생성
LVM Storage를 설치한 후 Logical Volume Manager 클러스터를 생성할 수 있습니다.
OpenShift Container Platform은 베어 메탈 사용자 프로비저닝 인프라에서 단일 노드 OpenShift 클러스터에 대한 추가 작업자 노드를 지원합니다. LVM Storage는 새 노드가 표시될 때 추가 작업자 노드를 감지하고 사용합니다. 추가 작업자 노드에 대한 노드 필터를 설정해야 하는 경우 클러스터를 생성하는 동안 YAML 보기를 사용할 수 있습니다.
OpenShift Container Platform 클러스터에서 LVMCluster
CR(사용자 정의 리소스)의 단일 인스턴스만 생성할 수 있습니다.
이 노드 필터 일치는 Pod 레이블 일치와 동일하지 않습니다.
사전 요구 사항
- OperatorHub에서 LVM Storage를 설치했습니다.
절차
OpenShift Container Platform 웹 콘솔에서 Operator
설치된 Operator 를 클릭하여 설치된 모든 Operator를 확인합니다. 선택한 프로젝트가
openshift-storage
인지 확인합니다.- LVM Storage 를 클릭한 다음 LVMCluster 에서 LVMCluster 만들기를 클릭합니다.
- LVMCluster 생성 페이지에서 양식 보기 또는 YAML 보기를 선택합니다.
- 클러스터 이름을 입력합니다.
- 생성을 클릭합니다.
선택 사항: 노드 필터를 추가하려면 YAML 보기를 클릭하고
nodeSelector
섹션에서 필터를 지정합니다.apiVersion: lvm.topolvm.io/v1alpha1 kind: LVMCluster metadata: name: my-lvmcluster spec: storage: deviceClasses: - name: vg1 thinPoolConfig: name: thin-pool-1 sizePercent: 90 overprovisionRatio: 10 nodeSelector: nodeSelectorTerms: - matchExpressions: - key: app operator: In values: - test1
선택 사항: 디스크의 로컬 장치 경로를 편집하려면 YAML 보기를 클릭하고
deviceSelector
섹션에서 장치 경로를 지정합니다.spec: storage: deviceClasses: - name: vg1 deviceSelector: paths: - /dev/disk/by-path/pci-0000:87:00.0-nvme-1 - /dev/disk/by-path/pci-0000:88:00.0-nvme-1 thinPoolConfig: name: thin-pool-1 sizePercent: 90 overprovisionRatio: 10
검증 단계
-
OpenShift Container Platform 웹 콘솔의 왼쪽 창에서 스토리지
스토리지 클래스 를 클릭합니다. -
lvms-<device-class-name
> 스토리지 클래스가LVMCluster
생성을 사용하여 생성되었는지 확인합니다. 기본적으로1은
device-class-name
입니다.
4.12.3.4. LVM 스토리지를 사용하는 스토리지 프로비저닝
Operator 설치 중에 생성된 스토리지 클래스를 사용하여 PVC(영구 볼륨 클레임)를 프로비저닝할 수 있습니다. 블록 및 파일 PVC를 프로비저닝할 수 있지만 PVC를 사용하는 Pod가 생성될 때만 스토리지가 할당됩니다.
LVM Storage는 1GiB 단위로 PVC를 프로비저닝합니다. 요청된 스토리지는 가장 가까운 GiB로 반올림됩니다.
절차
LVM Storage가 배포될 때 생성되는
StorageClass
를 식별합니다.StorageClass
이름은lvms-<device-class-name> 형식으로 되어 있습니다
.device-class-name
은Policy
YAML의LVMCluster
에 제공한 장치 클래스의 이름입니다. 예를 들어deviceClass
가1이라고 하는 경우storageClass
이름은lvms-
입니다.vg1
스토리지 클래스의
volumeBindingMode
가WaitForFirstConsumer
로 설정됩니다.애플리케이션에 스토리지가 필요한 PVC를 생성하려면 다음 YAML을
pvc.yaml
과 같은 이름의 파일에 저장합니다.PVC를 생성하는 YAML의 예
# block pvc apiVersion: v1 kind: PersistentVolumeClaim metadata: name: lvm-block-1 namespace: default spec: accessModes: - ReadWriteOnce volumeMode: Block resources: requests: storage: 10Gi storageClassName: lvms-vg1 --- # file pvc apiVersion: v1 kind: PersistentVolumeClaim metadata: name: lvm-file-1 namespace: default spec: accessModes: - ReadWriteOnce volumeMode: Filesystem resources: requests: storage: 10Gi storageClassName: lvms-vg1
다음 명령을 실행하여 PVC를 생성합니다.
# oc create -f pvc.yaml -ns <application_namespace>
생성된 PVC는 이를 사용하는 Pod를 배포할 때까지
보류 중
상태로 유지됩니다.
4.12.3.5. 단일 노드 OpenShift 클러스터의 스토리지 확장
OpenShift Container Platform은 베어 메탈 사용자 프로비저닝 인프라에서 단일 노드 OpenShift 클러스터에 대한 추가 작업자 노드를 지원합니다. LVM Storage는 노드가 표시될 때 새로운 추가 작업자 노드를 감지하고 사용합니다.
4.12.3.5.1. 단일 노드 OpenShift 클러스터에 용량을 추가하여 스토리지 확장
단일 노드 OpenShift 클러스터에서 구성된 작업자 노드의 스토리지 용량을 확장하려면 디스크를 추가하여 용량을 늘릴 수 있습니다.
사전 요구 사항
- LVM Storage에서 사용할 각 단일 노드 OpenShift 클러스터에 사용되지 않은 추가 디스크가 있습니다.
절차
- 단일 노드 OpenShift 클러스터의 OpenShift Container Platform 콘솔에 로그인합니다.
-
Operator
설치된 Operator 페이지에서 openshift-storage
네임스페이스에서 LVM Storage Operator 를 클릭합니다. -
LVMCluster 탭을 클릭하여 클러스터에서 생성된
LVMCluster
CR을 나열합니다. - 작업 드롭다운 메뉴에서 LVMCluster 편집 을 선택합니다.
- YAML 탭을 클릭합니다.
LVMCluster
CR YAML을 편집하여deviceSelector
섹션에 새 장치 경로를 추가합니다.참고LVMCluster
생성 중에deviceSelector
필드가 포함되지 않은 경우deviceSelector
섹션을 CR에 추가할 수 없습니다.LVMCluster
를 제거한 다음 새 CR을 생성해야 합니다.apiVersion: lvm.topolvm.io/v1alpha1 kind: LVMCluster metadata: name: my-lvmcluster spec: storage: deviceClasses: - name: vg1 deviceSelector: paths: - /dev/disk/by-path/pci-0000:87:00.0-nvme-1 1 - /dev/disk/by-path/pci-0000:88:00.0-nvme-1 - /dev/disk/by-path/pci-0000:89:00.0-nvme-1 2 thinPoolConfig: name: thin-pool-1 sizePercent: 90 overprovisionRatio: 10
추가 리소스
4.12.3.5.2. RHACM을 사용하여 단일 노드 OpenShift 클러스터에 용량을 추가하여 스토리지 확장
RHACM을 사용하여 단일 노드 OpenShift 클러스터에서 구성된 작업자 노드의 스토리지 용량을 확장할 수 있습니다.
사전 요구 사항
-
cluster-admin
권한이 있는 계정을 사용하여 RHACM 클러스터에 액세스할 수 있습니다. - LVM Storage에서 사용할 각 단일 노드 OpenShift 클러스터에 사용되지 않은 추가 디스크가 있습니다.
절차
- OpenShift Container Platform 인증 정보를 사용하여 RHACM CLI에 로그인합니다.
- 추가할 디스크를 찾습니다. 추가할 디스크는 기존 디스크의 장치 이름 및 경로와 일치해야 합니다.
단일 노드 OpenShift 클러스터에 용량을 추가하려면 기존 정책 YAML의
deviceSelector
섹션을 편집합니다(예:policy-lvms-operator.yaml
).참고LVMCluster
생성 중에deviceSelector
필드가 포함되지 않은 경우deviceSelector
섹션을 CR에 추가할 수 없습니다.LVMCluster
를 제거한 다음 새 CR에서 다시 생성해야 합니다.apiVersion: apps.open-cluster-management.io/v1 kind: PlacementRule metadata: name: placement-install-lvms spec: clusterConditions: - status: "True" type: ManagedClusterConditionAvailable clusterSelector: matchExpressions: - key: mykey operator: In values: - myvalue --- apiVersion: policy.open-cluster-management.io/v1 kind: PlacementBinding metadata: name: binding-install-lvms placementRef: apiGroup: apps.open-cluster-management.io kind: PlacementRule name: placement-install-lvms subjects: - apiGroup: policy.open-cluster-management.io kind: Policy name: install-lvms --- apiVersion: policy.open-cluster-management.io/v1 kind: Policy metadata: annotations: policy.open-cluster-management.io/categories: CM Configuration Management policy.open-cluster-management.io/controls: CM-2 Baseline Configuration policy.open-cluster-management.io/standards: NIST SP 800-53 name: install-lvms spec: disabled: false remediationAction: enforce policy-templates: - objectDefinition: apiVersion: policy.open-cluster-management.io/v1 kind: ConfigurationPolicy metadata: name: install-lvms spec: object-templates: - complianceType: musthave objectDefinition: apiVersion: v1 kind: Namespace metadata: labels: openshift.io/cluster-monitoring: "true" pod-security.kubernetes.io/enforce: privileged pod-security.kubernetes.io/audit: privileged pod-security.kubernetes.io/warn: privileged name: openshift-storage - complianceType: musthave objectDefinition: apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: openshift-storage-operatorgroup namespace: openshift-storage spec: targetNamespaces: - openshift-storage - complianceType: musthave objectDefinition: apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: lvms namespace: openshift-storage spec: installPlanApproval: Automatic name: lvms-operator source: redhat-operators sourceNamespace: openshift-marketplace remediationAction: enforce severity: low - objectDefinition: apiVersion: policy.open-cluster-management.io/v1 kind: ConfigurationPolicy metadata: name: lvms spec: object-templates: - complianceType: musthave objectDefinition: apiVersion: lvm.topolvm.io/v1alpha1 kind: LVMCluster metadata: name: my-lvmcluster namespace: openshift-storage spec: storage: deviceClasses: - name: vg1 deviceSelector: paths: - /dev/disk/by-path/pci-0000:87:00.0-nvme-1 - /dev/disk/by-path/pci-0000:88:00.0-nvme-1 - /dev/disk/by-path/pci-0000:89:00.0-nvme-1 # new disk is added thinPoolConfig: name: thin-pool-1 sizePercent: 90 overprovisionRatio: 10 nodeSelector: nodeSelectorTerms: - matchExpressions: - key: app operator: In values: - test1 remediationAction: enforce severity: low
다음 명령을 실행하여 정책을 편집합니다.
# oc edit -f policy-lvms-operator.yaml -ns lvms-policy-ns 1
- 1
policy-lvms-operator.yaml
은 기존 정책의 이름입니다.
이 명령은
LVMCluster
CR에 지정된 새 디스크를 사용하여 스토리지를 프로비저닝합니다.
4.12.3.5.3. PVC 확장
용량을 추가한 후 새 스토리지를 활용하기 위해 LVM 스토리지로 기존 PVC(영구 볼륨 클레임)를 확장할 수 있습니다.
사전 요구 사항
- 동적 프로비저닝이 사용됩니다.
-
제어
StorageClass
오브젝트에allowVolumeExpansion
이true
로 설정되어 있습니다.
절차
다음 명령을 실행하여 원하는 PVC 리소스의
.spec.resources.requests.storage
필드를 새 크기로 수정합니다.oc patch <pvc_name> -n <application_namespace> -p '{ "spec": { "resources": { "requests": { "storage": "<desired_size>" }}}}'
-
PVC의
status.conditions
필드를 보고 크기 조정이 완료되었는지 확인합니다. OpenShift Container Platform은 확장 중에 PVC에크기 조정
조건을 추가하며, 이는 확장이 완료된 후 제거됩니다.
4.12.3.6. 단일 노드 OpenShift 클러스터에서 LVM 스토리지 업그레이드
현재 단일 노드 OpenShift 클러스터에서 OpenShift Data Foundation Logical Volume Manager Operator 4.11에서 LVM Storage 4.12로 업그레이드할 수 없습니다.
이 과정에서 데이터는 보존되지 않습니다.
절차
- PVC(영구 볼륨 클레임)에서 보존할 데이터를 백업합니다.
- OpenShift Data Foundation Logical Volume Manager Operator 및 해당 Pod에서 프로비저닝한 모든 PVC를 삭제합니다.
- OpenShift Container Platform 4.12에 LVM 스토리지를 다시 설치합니다.
- 워크로드를 다시 생성합니다.
- 4.12로 업그레이드한 후 생성된 PVC에 백업 데이터를 복사합니다.
4.12.3.7. 단일 노드 OpenShift의 볼륨 스냅샷
LVM 스토리지에서 프로비저닝한 PV(영구 볼륨)의 볼륨 스냅샷을 가져올 수 있습니다. 복제된 볼륨의 볼륨 스냅샷을 생성할 수도 있습니다. 볼륨 스냅샷을 사용하면 다음을 수행할 수 있습니다.
애플리케이션 데이터를 백업합니다.
중요볼륨 스냅샷은 원래 데이터와 동일한 장치에 있습니다. 볼륨 스냅샷을 백업으로 사용하려면 스냅샷을 안전한 위치로 이동해야 합니다. OpenShift API를 사용하여 데이터 보호 백업 및 복원 솔루션을 사용할 수 있습니다.
- 볼륨 스냅샷을 만든 상태로 되돌립니다.
추가 리소스
4.12.3.7.1. 단일 노드 OpenShift에서 볼륨 스냅샷 생성
thin 풀의 사용 가능한 용량과 Overprovisioning 제한을 기반으로 볼륨 스냅샷을 생성할 수 있습니다. LVM Storage는 lvms-<deviceclass-name> 이름을 사용하여
생성합니다.
VolumeSnapshotClass
를
사전 요구 사항
-
PVC(영구 볼륨 클레임)가
Bound
상태인지 확인했습니다. 이는 일관된 스냅샷에 필요합니다. - 스냅샷을 생성하기 전에 PVC의 모든 I/O를 중지했습니다.
절차
-
oc
명령을 실행해야 하는 단일 노드 OpenShift에 로그인합니다. 다음 YAML을
lvms-vol-snapshot.yaml
과 같은 이름으로 파일에 저장합니다.볼륨 스냅샷을 생성하는 YAML의 예
apiVersion: snapshot.storage.k8s.io/v1 kind: VolumeSnapshot metadata: name: lvm-block-1-snap spec: volumeSnapshotClassName: lvms-vg1 source: persistentVolumeClaimName: lvm-block-1
PVC와 동일한 네임스페이스에서 다음 명령을 실행하여 스냅샷을 생성합니다.
# oc create -f lvms-vol-snapshot.yaml
PVC의 읽기 전용 사본이 볼륨 스냅샷으로 생성됩니다.
4.12.3.7.2. 단일 노드 OpenShift에서 볼륨 스냅샷 복원
볼륨 스냅샷을 복원하면 새 PVC(영구 볼륨 클레임)가 생성됩니다. 복원된 PVC는 볼륨 스냅샷과 소스 PVC와 독립적입니다.
사전 요구 사항
- 스토리지 클래스는 소스 PVC와 동일해야 합니다.
요청된 PVC의 크기는 스냅샷의 소스 볼륨과 동일해야 합니다.
중요스냅샷은 스냅샷의 소스 볼륨과 동일한 크기의 PVC로 복원되어야 합니다. 더 큰 PVC가 필요한 경우 스냅샷이 성공적으로 복원된 후 PVC의 크기를 조정할 수 있습니다.
절차
- 소스 PVC 및 볼륨 스냅샷 이름의 스토리지 클래스 이름을 확인합니다.
다음 YAML을
lvms-vol-restore.yaml
과 같은 이름의 파일에 저장하여 스냅샷을 복원합니다.PVC를 복원하는 YAML의 예.
kind: PersistentVolumeClaim apiVersion: v1 metadata: name: lvm-block-1-restore spec: accessModes: - ReadWriteOnce volumeMode: Block Resources: Requests: storage: 2Gi storageClassName: lvms-vg1 dataSource: name: lvm-block-1-snap kind: VolumeSnapshot apiGroup: snapshot.storage.k8s.io
스냅샷과 동일한 네임스페이스에서 다음 명령을 실행하여 정책을 생성합니다.
# oc create -f lvms-vol-restore.yaml
4.12.3.7.3. 단일 노드 OpenShift에서 볼륨 스냅샷 삭제
볼륨 스냅샷 리소스 및 PVC(영구 볼륨 클레임)를 삭제할 수 있습니다.
절차
다음 명령을 실행하여 볼륨 스냅샷 리소스를 삭제합니다.
# oc delete volumesnapshot <volume_snapshot_name> -n <namespace>
참고PVC(영구 볼륨 클레임)를 삭제하면 PVC의 스냅샷이 삭제되지 않습니다.
복원된 볼륨 스냅샷을 삭제하려면 다음 명령을 실행하여 볼륨 스냅샷을 복원하도록 생성된 PVC를 삭제합니다.
# oc delete pvc <pvc_name> -n <namespace>
4.12.3.8. 단일 노드 OpenShift의 볼륨 복제
복제본은 모든 표준 볼륨처럼 사용할 수 있는 기존 스토리지 볼륨과 중복됩니다.
4.12.3.8.1. 단일 노드 OpenShift에서 볼륨 복제 생성
볼륨의 복제를 생성하여 데이터의 특정 시점을 복사합니다. PVC(영구 볼륨 클레임)는 다른 크기로 복제할 수 없습니다.
복제된 PVC에는 쓰기 액세스 권한이 있습니다.
사전 요구 사항
-
PVC가
Bound
상태에 있는지 확인했습니다. 이는 일관된 스냅샷에 필요합니다. -
StorageClass
가 소스 PVC와 동일한지 확인했습니다.
절차
- 소스 PVC의 스토리지 클래스를 확인합니다.
볼륨 복제를 생성하려면 다음 YAML을
lvms-vol-clone.yaml
과 같은 이름의 파일에 저장합니다.볼륨을 복제하는 YAML의 예
apiVersion: v1 kind: PersistentVolumeClaim Metadata: name: lvm-block-1-clone Spec: storageClassName: lvms-vg1 dataSource: name: lvm-block-1 kind: PersistentVolumeClaim accessModes: - ReadWriteOnce volumeMode: Block Resources: Requests: storage: 2Gi
다음 명령을 실행하여 소스 PVC와 동일한 네임스페이스에 정책을 생성합니다.
# oc create -f lvms-vol-clone.yaml
4.12.3.8.2. 단일 노드 OpenShift에서 복제된 볼륨 삭제
복제된 볼륨을 삭제할 수 있습니다.
절차
복제된 볼륨을 삭제하려면 다음 명령을 실행하여 복제된 PVC를 삭제합니다.
# oc delete pvc <clone_pvc_name> -n <namespace>
4.12.3.9. LVM 스토리지 모니터링
클러스터 모니터링을 활성화하려면 LVM 스토리지를 설치한 네임스페이스에 다음 레이블을 추가해야 합니다.
openshift.io/cluster-monitoring=true
RHACM에서 클러스터 모니터링 활성화에 대한 자세한 내용은 Observability 및 사용자 정의 지표 추가 를 참조하십시오.
4.12.3.9.1. 메트릭
메트릭을 확인하여 LVM 스토리지를 모니터링할 수 있습니다.
다음 표에서는 topolvm
메트릭을 설명합니다.
경고 | 설명 |
---|---|
| LVM thinpool에 사용된 데이터 공간의 백분율을 나타냅니다. |
| LVM thinpool에 사용된 메타데이터 공간의 백분율을 나타냅니다. |
| LVM 씬 풀의 크기를 바이트 단위로 나타냅니다. |
| LVM 볼륨 그룹의 사용 가능한 공간을 바이트 단위로 나타냅니다. |
| LVM 볼륨 그룹의 크기를 바이트 단위로 나타냅니다. |
| LVM 씬 풀의 사용 가능한 초과 프로비저닝 크기를 바이트 단위로 나타냅니다. |
지표는 10분마다 업데이트되거나 씬 풀에서 새 논리 볼륨 생성과 같은 변경이 있을 때 업데이트됩니다.
4.12.3.9.2. 경고
thin 풀 및 볼륨 그룹이 최대 스토리지 용량에 도달하면 추가 작업이 실패합니다. 이는 데이터 손실을 초래할 수 있습니다.
LVM 스토리지는 thin 풀 및 볼륨 그룹 사용이 특정 값을 초과하면 다음 경고를 보냅니다.
경고 | 설명 |
---|---|
| 이 경고는 볼륨 그룹과 씬 풀 사용량이 노드에서 75%를 초과하면 트리거됩니다. 데이터 삭제 또는 볼륨 그룹 확장이 필요합니다. |
| 이 경고는 볼륨 그룹과 씬 풀 사용량이 노드에서 85%를 초과하면 트리거됩니다. 이 경우 볼륨 그룹이 매우 가득 차 있습니다. 데이터 삭제 또는 볼륨 그룹 확장이 필요합니다. |
| 이 경고는 볼륨 그룹의 thin pool data uusage가 노드에서 75%를 초과하면 트리거됩니다. 데이터 삭제 또는 씬 풀 확장이 필요합니다. |
| 이 경고는 볼륨 그룹의 씬 풀 데이터 사용량이 노드에서 85%를 초과하면 트리거됩니다. 데이터 삭제 또는 씬 풀 확장이 필요합니다. |
| 이 경고는 볼륨 그룹의 씬 풀 메타데이터 사용량이 노드에서 75%를 초과하면 트리거됩니다. 데이터 삭제 또는 씬 풀 확장이 필요합니다. |
| 이 경고는 볼륨 그룹의 씬 풀 메타데이터 사용량이 노드에서 85%를 초과하면 트리거됩니다. 데이터 삭제 또는 씬 풀 확장이 필요합니다. |
4.12.3.10. must-gather를 사용하여 로그 파일 및 진단 정보 다운로드
LVM Storage에서 자동으로 문제를 해결할 수 없는 경우 must-gather 툴을 사용하여 로그 파일 및 진단 정보를 수집하여 문제를 검토하고 솔루션을 결정할 수 있습니다.
절차
LVM 스토리지 클러스터에 연결된 클라이언트에서
must-gather
명령을 실행합니다.$ oc adm must-gather --image=registry.redhat.io/lvms4/lvms-must-gather-rhel9:v4.12 --dest-dir=<directory_name>
추가 리소스
4.12.3.11. LVM Storage 참조 YAML 파일
샘플 LVMCluster
CR(사용자 정의 리소스)은 YAML 파일의 모든 필드를 설명합니다.
LVMCluster CR의 예
apiVersion: lvm.topolvm.io/v1alpha1 kind: LVMCluster metadata: name: my-lvmcluster spec: tolerations: - effect: NoSchedule key: xyz operator: Equal value: "true" storage: deviceClasses: 1 - name: vg1 2 nodeSelector: 3 nodeSelectorTerms: 4 - matchExpressions: - key: mykey operator: In values: - ssd deviceSelector: 5 paths: - /dev/disk/by-path/pci-0000:87:00.0-nvme-1 - /dev/disk/by-path/pci-0000:88:00.0-nvme-1 - /dev/disk/by-path/pci-0000:89:00.0-nvme-1 thinPoolConfig: 6 name: thin-pool-1 7 sizePercent: 90 8 overprovisionRatio: 10 9 status: deviceClassStatuses: 10 - name: vg1 nodeStatus: 11 - devices: 12 - /dev/nvme0n1 - /dev/nvme1n1 - /dev/nvme2n1 node: my-node.example.com 13 status: Ready 14 ready: true 15 state: Ready 16
- 1
- 클러스터에서 생성할 LVM 볼륨 그룹입니다. 단일
deviceClass
만 생성할 수 있습니다. - 2
- 노드에서 생성할 LVM 볼륨 그룹의 이름입니다.
- 3
- LVM 볼륨 그룹을 생성할 노드입니다. 필드가 비어 있으면 모든 노드가 고려됩니다.
- 4
- 노드 선택기 요구 사항 목록입니다.
- 5
- LVM 볼륨 그룹을 만드는 데 사용되는 장치 경로 목록입니다. 이 필드가 비어 있으면 노드에서 사용되지 않는 모든 디스크가 사용됩니다. 장치를 LVM 볼륨 그룹에 추가한 후에는 제거할 수 없습니다.
- 6
- LVM thin pool 구성입니다.
- 7
- LVM 볼륨 그룹에 생성할 thin 풀의 이름입니다.
- 8
- thin 풀을 만드는 데 사용해야 하는 LVM 볼륨 그룹의 남은 공간 백분율입니다.
- 9
- thin 풀에서 사용 가능한 스토리지와 비교하여 추가 스토리지를 프로비저닝할 수 있는 요인입니다.
- 10
deviceClass
의 상태.- 11
- 각 노드에 있는 LVM 볼륨 그룹의 상태.
- 12
- LVM 볼륨 그룹을 만드는 데 사용되는 장치 목록입니다.
- 13
deviceClass
가 생성된 노드입니다.- 14
- 노드의 LVM 볼륨 그룹의 상태.
- 15
- 이 필드는 더 이상 사용되지 않습니다.
- 16
LVMCluster
의 상태.
4.12.4. LVMS를 사용하여 로컬 영구 스토리지 문제 해결
OpenShift Container Platform은 PV(영구 볼륨)의 범위를 단일 프로젝트로 지정하지 않으므로 클러스터 전체에서 공유되고 PVC(영구 볼륨 클레임)를 사용하여 모든 프로젝트에서 요청할 수 있습니다. 이로 인해 문제 해결이 필요한 여러 문제가 발생할 수 있습니다.
4.12.4.1. Pending 상태에 있는 PVC 조사
PVC(영구 볼륨 클레임)는 여러 가지 이유로 Pending
상태로 고정될 수 있습니다. 예를 들면 다음과 같습니다.
- 컴퓨팅 리소스가 충분하지 않음
- 네트워크 문제
- 일치하지 않는 스토리지 클래스 또는 노드 선택기
- 사용 가능한 볼륨 없음
-
PV(영구 볼륨)가
Not Ready
상태인 노드
oc describe
명령을 사용하여 정지된 PVC에 대한 세부 정보를 검토하여 원인을 식별합니다.
절차
다음 명령을 실행하여 PVC 목록을 검색합니다.
$ oc get pvc
출력 예
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE lvms-test Pending lvms-vg1 11s
다음 명령을 실행하여 PVC와 관련된 이벤트를
Pending
상태로 유지합니다.$ oc describe pvc <pvc_name> 1
- 1
- &
lt;pvc_name
>을 PVC 이름으로 바꿉니다. 예를 들면lvms-vg1
입니다.
출력 예
Type Reason Age From Message ---- ------ ---- ---- ------- Warning ProvisioningFailed 4s (x2 over 17s) persistentvolume-controller storageclass.storage.k8s.io "lvms-vg1" not found
4.12.4.2. 누락된 LVMS 또는 Operator 구성 요소에서 복구
스토리지 클래스 "Not found" 오류가 발생하면 LVMCluster
리소스를 확인하고 모든 LVMS(Logical Volume Manager Storage) Pod가 실행 중인지 확인합니다. LVMCluster
리소스가 없는 경우 생성할 수 있습니다.
절차
다음 명령을 실행하여 LVMCluster 리소스가 있는지 확인합니다.
$ oc get lvmcluster -n openshift-storage
출력 예
NAME AGE my-lvmcluster 65m
클러스터에
LVMCluster
리소스가 없는 경우 다음 명령을 실행하여 해당 리소스를 생성합니다.$ oc create -n openshift-storage -f <custom_resource> 1
- 1
- &
lt;custom_resource&
gt;를 요구 사항에 맞는 사용자 정의 리소스 URL 또는 파일로 바꿉니다.
사용자 정의 리소스의 예
apiVersion: lvm.topolvm.io/v1alpha1 kind: LVMCluster metadata: name: my-lvmcluster spec: storage: deviceClasses: - name: vg1 default: true thinPoolConfig: name: thin-pool-1 sizePercent: 90 overprovisionRatio: 10
다음 명령을 실행하여 LVMS의 모든 포드가
openshift-storage
네임스페이스에서Running
상태인지 확인합니다.$ oc get pods -n openshift-storage
출력 예
NAME READY STATUS RESTARTS AGE lvms-operator-7b9fb858cb-6nsml 3/3 Running 0 70m topolvm-controller-5dd9cf78b5-7wwr2 5/5 Running 0 66m topolvm-node-dr26h 4/4 Running 0 66m vg-manager-r6zdv 1/1 Running 0 66m
예상되는 출력은
lvms-operator
및 Cryostat-manager
의 인스턴스 중 하나입니다. 각 노드에 대해topolvm-controller
및topolvm-node
의 인스턴스 1개가 예상됩니다.topolvm-node
가Init
상태에 있는 경우 LVMS에서 사용할 사용 가능한 디스크를 찾지 못했습니다. 문제 해결에 필요한 정보를 검색하려면 다음 명령을 실행하여 Cryostat-manager
Pod의 로그를 검토합니다.$ oc logs -l app.kubernetes.io/component=vg-manager -n openshift-storage
4.12.4.3. 노드 장애로 복구
클러스터의 특정 노드가 실패했기 때문에 PVC(영구 볼륨 클레임)가 Pending
상태가 되는 경우가 있습니다. 실패한 노드를 식별하기 위해 topolvm-node
Pod의 재시작 횟수를 검사할 수 있습니다. 재시작 횟수가 증가하면 기본 노드의 잠재적인 문제가 발생하므로 추가 조사 및 문제 해결이 필요할 수 있습니다.
절차
다음 명령을 실행하여
topolvm-node
Pod 인스턴스의 재시작 횟수를 검사합니다.$ oc get pods -n openshift-storage
출력 예
NAME READY STATUS RESTARTS AGE lvms-operator-7b9fb858cb-6nsml 3/3 Running 0 70m topolvm-controller-5dd9cf78b5-7wwr2 5/5 Running 0 66m topolvm-node-dr26h 4/4 Running 0 66m topolvm-node-54as8 4/4 Running 0 66m topolvm-node-78fft 4/4 Running 17 (8s ago) 66m vg-manager-r6zdv 1/1 Running 0 66m vg-manager-990ut 1/1 Running 0 66m vg-manager-an118 1/1 Running 0 66m
노드 문제를 해결한 후 PVC가
Pending
상태인 경우 강제 정리 절차를 수행해야 할 수 있습니다.
추가 리소스
4.12.4.4. 디스크 장애에서 복구
PVC(영구 볼륨 클레임)와 연결된 이벤트를 검사하는 동안 실패 메시지가 표시되면 기본 볼륨 또는 디스크에 문제가 있을 수 있습니다. 디스크 및 볼륨 프로비저닝 문제는 종종 StorageClass <storage_class_name>을 사용하여 볼륨을 프로비저닝하지 못했습니다
. 일반적으로 보다 구체적인 두 번째 오류 메시지가 표시됩니다.
절차
다음 명령을 실행하여 PVC와 관련된 이벤트를 검사합니다.
$ oc describe pvc <pvc_name> 1
- 1
- &
lt;pvc_name
>을 PVC 이름으로 바꿉니다. 다음은 디스크 또는 볼륨 오류 오류 메시지와 그 원인의 몇 가지 예입니다.- 볼륨 존재를 확인하지 못했습니다. 볼륨이 이미 있는지 확인하는 데 문제가 있음을 나타냅니다. 볼륨 확인 오류는 네트워크 연결 문제 또는 기타 오류로 인해 발생할 수 있습니다.
- 볼륨 바인딩 실패: 사용 가능한 PV(영구 볼륨)가 PVC의 요구 사항과 일치하지 않는 경우 볼륨을 바인딩하지 못하는 경우가 발생할 수 있습니다.
- FailedMount 또는 FailedUnMount: 이 오류는 볼륨을 노드에 마운트하거나 노드에서 볼륨을 마운트 해제 할 때 문제가 있음을 나타냅니다. 디스크가 실패한 경우 Pod에서 PVC 사용을 시도할 때 이 오류가 표시될 수 있습니다.
-
볼륨은 이미 하나의 노드에 독점적으로 연결되어 있으며 다른 노드에만 연결되어 있지 않습니다. 이 오류는
ReadWriteMany
액세스 모드를 지원하지 않는 스토리지 솔루션과 함께 표시될 수 있습니다.
- 문제가 발생하는 호스트에 대한 직접 연결을 설정합니다.
- 디스크 문제를 해결합니다.
디스크 문제를 해결한 후 오류 메시지가 유지되거나 다시 발생하는 경우 강제 정리 절차를 수행해야 할 수 있습니다.
추가 리소스
4.12.4.5. 강제 정리 수행
문제 해결 절차를 완료한 후 디스크 또는 노드 관련 문제가 지속되는 경우 강제 정리 절차를 수행해야 할 수 있습니다. 강제 정리는 영구 문제를 포괄적으로 해결하고 LVMS의 적절한 기능을 확인하는 데 사용됩니다.
사전 요구 사항
- LVM(Logical Volume Manager) 드라이버를 사용하여 생성된 모든 PVC(영구 볼륨 클레임)가 제거되었습니다.
- 해당 PVC를 사용하는 Pod가 중지되었습니다.
절차
다음 명령을 실행하여
openshift-storage
네임스페이스로 전환합니다.$ oc project openshift-storage
다음 명령을 실행하여
논리 볼륨
CR(사용자 정의 리소스)이 남아 있지 않은지 확인합니다.$ oc get logicalvolume
출력 예
No resources found
다음 명령을 실행하여
LVMVolumeGroup
CR이 남아 있지 않은지 확인합니다.$ oc get lvmvolumegroup
출력 예
No resources found
다음 명령을 실행하여
LVMVolumeGroupNodeStatus
CR을 제거합니다.$ oc delete lvmvolumegroupnodestatus --all
다음 명령을 실행하여
LVMCluster
CR을 제거합니다.$ oc delete lvmcluster --all