Replacing devices
운영되거나 실패한 장치를 안전하게 교체하기 위한 명령
초록
보다 포괄적 수용을 위한 오픈 소스 용어 교체
Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 용어를 교체하기 위해 최선을 다하고 있습니다. 먼저 마스터(master), 슬레이브(slave), 블랙리스트(blacklist), 화이트리스트(whitelist) 등 네 가지 용어를 교체하고 있습니다. 이러한 변경 작업은 작업 범위가 크므로 향후 여러 릴리스에 걸쳐 점차 구현할 예정입니다. 자세한 내용은 CTO Chris Wright의 메시지를 참조하십시오.
Red Hat 문서에 관한 피드백 제공
문서 개선을 위한 의견을 보내 주십시오. 개선할 내용에 대해 알려주십시오. 피드백을 보내주시려면 다음을 확인하십시오.
특정 문구에 대한 간단한 의견 작성 방법은 다음과 같습니다.
- 문서가 Multi-page HTML 형식으로 표시되는지 확인합니다. 또한 문서 오른쪽 상단에 피드백 버튼이 있는지 확인합니다.
- 마우스 커서를 사용하여 주석 처리하려는 텍스트 부분을 강조 표시합니다.
- 강조 표시된 텍스트 아래에 표시되는 피드백 추가 팝업을 클릭합니다.
- 표시된 지침을 따릅니다.
보다 상세하게 피드백을 제출하려면 다음과 같이 Bugzilla 티켓을 생성하십시오.
- Bugzilla 웹 사이트로 이동하십시오.
- 구성 요소 섹션에서 설명서를 선택합니다.
- 설명 필드에 문서 개선을 위한 제안 사항을 기입하십시오. 관련된 문서의 해당 부분 링크를 알려주십시오.
- 버그 제출을 클릭합니다.
머리말
배포 유형에 따라 다음 절차 중 하나를 선택하여 스토리지 장치를 교체할 수 있습니다.
AWS에 배포된 동적으로 생성된 스토리지 클러스터는 다음을 참조하십시오.
- VMware에 배포된 동적으로 생성된 스토리지 클러스터는 2.1절. “VMware 인프라에서 운영되거나 실패한 스토리지 장치 교체” 을 참조하십시오.
- Red Hat Virtualization에 배포된 동적으로 생성된 스토리지 클러스터는 3.1절. “Red Hat Virtualization 설치 관리자 프로비저닝 인프라에서 운영되거나 실패한 스토리지 장치 교체” 에서 참조하십시오.
- Microsoft Azure에 배포된 동적으로 생성된 스토리지 클러스터는 4.1절. “Azure 설치 관리자 프로비저닝 인프라에서 운영 또는 실패한 스토리지 장치 교체” 을 참조하십시오.
로컬 스토리지 장치를 사용하여 배포된 스토리지 클러스터의 경우 다음을 참조하십시오.
OpenShift Data Foundation은 이기종 OSD 크기를 지원하지 않습니다.
1장. AWS에 배포된 동적으로 프로비저닝된 OpenShift Data Foundation
1.1. AWS 사용자 프로비저닝 인프라에서 운영 또는 실패한 스토리지 장치 교체
AWS 사용자 프로비저닝 인프라에서 동적으로 생성된 스토리지 클러스터에서 장치를 교체해야 하는 경우 스토리지 노드를 교체해야 합니다. 노드를 교체하는 방법에 대한 자세한 내용은 다음을 참조하십시오.
1.2. AWS 설치 관리자 프로비저닝 인프라에서 운영 또는 실패한 스토리지 장치 교체
AWS 설치 관리자 프로비저닝 인프라에서 동적으로 생성된 스토리지 클러스터에서 장치를 교체해야 하는 경우 스토리지 노드를 교체해야 합니다. 노드를 교체하는 방법에 대한 자세한 내용은 다음을 참조하십시오.
2장. VMware에 배포된 동적으로 프로비저닝된 OpenShift Data Foundation
2.1. VMware 인프라에서 운영되거나 실패한 스토리지 장치 교체
새 볼륨에서 새 PVC(영구 볼륨 클레임)를 생성하고 VMware 인프라에 동적으로 배포된 OpenShift Data Foundation에서 하나 이상의 VMDK(가상 머신 디스크)를 교체해야 하는 이전 개체 스토리지 장치(OSD)를 제거합니다.
사전 요구 사항
데이터가 탄력적인지 확인합니다.
- OpenShift 웹 콘솔에서 스토리지 → Data Foundation 을 클릭합니다.
-
Storage Systems 탭을 클릭한 다음
ocs-storagecluster-storagesystem을 클릭합니다. - 블록 및 파일 대시보드의 상태 카드 개요 탭에서 Data Resiliency 에 녹색 표시가 있는지 확인합니다.
절차
교체해야 하는 OSD와 OSD가 예약된 OpenShift Container Platform 노드를 확인합니다.
$ oc get -n openshift-storage pods -l app=rook-ceph-osd -o wide
출력 예:
rook-ceph-osd-0-6d77d6c7c6-m8xj6 0/1 CrashLoopBackOff 0 24h 10.129.0.16 compute-2 <none> <none> rook-ceph-osd-1-85d99fb95f-2svc7 1/1 Running 0 24h 10.128.2.24 compute-0 <none> <none> rook-ceph-osd-2-6c66cdb977-jp542 1/1 Running 0 24h 10.130.0.18 compute-1 <none> <none>
이 예에서는
rook-ceph-osd-0-6d77d6c7c6-m8xj6을 교체해야 하며compute-2는 OSD가 예약된 OpenShift Container Platform 노드입니다.참고교체할 OSD가 정상이면 포드 상태가
Running이 됩니다.OSD를 교체할 OSD 배포를 축소합니다.
OSD를 교체할 때마다
osd_id_to_remove매개변수를 OSD ID로 업데이트하고 이 단계를 반복합니다.$ osd_id_to_remove=0
$ oc scale -n openshift-storage deployment rook-ceph-osd-${osd_id_to_remove} --replicas=0여기서
osd_id_to_remove는rook-ceph-osd접두사 직후 Pod 이름의 정수입니다. 이 예제에서 배포 이름은rook-ceph-osd-0입니다.출력 예:
deployment.extensions/rook-ceph-osd-0 scaled
rook-ceph-osdPod가 종료되었는지 확인합니다.$ oc get -n openshift-storage pods -l ceph-osd-id=${osd_id_to_remove}출력 예:
No resources found.
중요rook-ceph-osdPod가종료상태인 경우force옵션을 사용하여 Pod를 삭제합니다.$ oc delete pod rook-ceph-osd-0-6d77d6c7c6-m8xj6 --force --grace-period=0
출력 예:
warning: Immediate deletion does not wait for confirmation that the running resource has been terminated. The resource may continue to run on the cluster indefinitely. pod "rook-ceph-osd-0-6d77d6c7c6-m8xj6" force deleted
새 OSD를 추가할 수 있도록 클러스터에서 이전 OSD를 제거합니다.
이전
ocs-osd-removal작업을 삭제합니다.$ oc delete -n openshift-storage job ocs-osd-removal-job
출력 예:
job.batch "ocs-osd-removal-job" deleted
openshift-storage프로젝트로 이동합니다.$ oc project openshift-storage
클러스터에서 이전 OSD를 제거합니다.
$ oc process -n openshift-storage ocs-osd-removal -p FAILED_OSD_IDS=${osd_id_to_remove} -p FORCE_OSD_REMOVAL=false |oc create -n openshift-storage -f -OSD가 3개뿐인 클러스터에서 FORCE_OSD_REMOVAL 값을 "true"로 변경해야 합니다. OSD를 제거한 후 3개의 데이터 복제본을 모두 복원할 수 있는 공간이 충분하지 않은 클러스터에서는 FORCE_OSD_REMOVAL 값을 "true"로 변경해야 합니다.
주의이 단계에서는 클러스터에서 OSD가 완전히 제거됩니다.
osd_id_to_remove의 올바른 값이 제공되었는지 확인합니다.
ocs-osd-removal-jobPod의 상태를 확인하여 OSD가 성공적으로 제거되었는지 확인합니다.Completed상태로 인해 OSD 제거 작업이 성공했는지 확인합니다.$ oc get pod -l job-name=ocs-osd-removal-job -n openshift-storage
OSD 제거가 완료되었는지 확인합니다.
$ oc logs -l job-name=ocs-osd-removal-job -n openshift-storage --tail=-1 | egrep -i 'completed removal'
출력 예:
2022-05-10 06:50:04.501511 I | cephosd: completed removal of OSD 0
중요ocs-osd-removal-jobPod가 실패하고 Pod가 예상Completed상태에 없는 경우 Pod 로그를 확인하여 추가 디버깅을 확인합니다.예를 들면 다음과 같습니다.
# oc logs -l job-name=ocs-osd-removal-job -n openshift-storage --tail=-1
설치 시 암호화를 활성화한 경우 해당 OpenShift Data Foundation 노드에서 제거된 OSD 장치에서
dm-cryptmanageddevice-mapper매핑을 제거합니다.ocs-osd-removal-jobPod 로그에서 교체된 OSD의 PVC 이름을 가져옵니다.$ oc logs -l job-name=ocs-osd-removal-job -n openshift-storage --tail=-1 |egrep -i ‘pvc|deviceset’
출력 예:
2021-05-12 14:31:34.666000 I | cephosd: removing the OSD PVC "ocs-deviceset-xxxx-xxx-xxx-xxx"
이전에 식별한 각 노드에 대해 다음을 수행합니다.
스토리지 노드의 호스트에
디버그Pod와chroot를 만듭니다.$ oc debug node/<node name><node name>노드의 이름입니다.
$ chroot /host
이전 단계에서 식별한 PVC 이름을 기반으로 관련 장치 이름을 찾습니다.
$ dmsetup ls| grep <pvc name><pvc name>PVC의 이름입니다.
출력 예:
ocs-deviceset-xxx-xxx-xxx-xxx-block-dmcrypt (253:0)
매핑된 장치를 제거합니다.
$ cryptsetup luksClose --debug --verbose ocs-deviceset-xxx-xxx-xxx-xxx-block-dmcrypt
중요충분하지 않은 권한으로 인해 위의 명령이 정지되면 다음 명령을 실행합니다.
-
CTRL+Z를 눌러 위 명령을 종료합니다. 정지된 프로세스의 PID를 찾습니다.
$ ps -ef | grep crypt
kill명령을 사용하여 프로세스를 종료합니다.$ kill -9 <PID><PID>- 는 프로세스 ID입니다.
장치 이름이 제거되었는지 확인합니다.
$ dmsetup ls
-
ocs-osd-removal작업을 삭제합니다.$ oc delete -n openshift-storage job ocs-osd-removal-job
출력 예:
job.batch "ocs-osd-removal-job" deleted
데이터 암호화와 함께 외부 키 관리 시스템(KMS)을 사용하는 경우 이제 고립된 키가기 때문에 이전 OSD 암호화 키를 Vault 서버에서 제거할 수 있습니다.
검증 단계
실행 중인 새 OSD가 있는지 확인합니다.
$ oc get -n openshift-storage pods -l app=rook-ceph-osd
출력 예:
rook-ceph-osd-0-5f7f4747d4-snshw 1/1 Running 0 4m47s rook-ceph-osd-1-85d99fb95f-2svc7 1/1 Running 0 1d20h rook-ceph-osd-2-6c66cdb977-jp542 1/1 Running 0 1d20h
Bound상태에 있는 새 PVC가 생성되었는지 확인합니다.$ oc get -n openshift-storage pvc
출력 예:
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE ocs-deviceset-0-0-2s6w4 Bound pvc-7c9bcaf7-de68-40e1-95f9-0b0d7c0ae2fc 512Gi RWO thin 5m ocs-deviceset-1-0-q8fwh Bound pvc-9e7e00cb-6b33-402e-9dc5-b8df4fd9010f 512Gi RWO thin 1d20h ocs-deviceset-2-0-9v8lq Bound pvc-38cdfcee-ea7e-42a5-a6e1-aaa6d4924291 512Gi RWO thin 1d20h
선택 사항: 클러스터에서 클러스터 전체 암호화를 사용하는 경우 새 OSD 장치가 암호화되었는지 확인합니다.
새 OSD 포드가 실행 중인 노드를 식별합니다.
$ oc get -n openshift-storage -o=custom-columns=NODE:.spec.nodeName pod/<OSD-pod-name><OSD-pod-name>는 OSD 포드의 이름입니다.
예를 들면 다음과 같습니다.
$ oc get -n openshift-storage -o=custom-columns=NODE:.spec.nodeName pod/rook-ceph-osd-0-544db49d7f-qrgqm
출력 예:
NODE compute-1
이전 단계에서 확인한 각 노드에 대해 다음을 수행합니다.
디버그 Pod를 생성하고 선택한 호스트에 대한 chroot 환경을 엽니다.
$ oc debug node/<node name><node name>노드의 이름입니다.
$ chroot /host
ocs-deviceset이름 옆에crypt키워드가 있는지 확인합니다.$ lsblk
- OpenShift 웹 콘솔에 로그인하고 스토리지 대시보드를 확인합니다.
3장. Red Hat Virtualization에 배포된 동적으로 프로비저닝된 OpenShift Data Foundation
3.1. Red Hat Virtualization 설치 관리자 프로비저닝 인프라에서 운영되거나 실패한 스토리지 장치 교체
새 볼륨에 새 PVC(영구 볼륨 클레임)를 생성하고 이전 개체 스토리지 장치(OSD)를 제거합니다.
사전 요구 사항
데이터가 탄력적인지 확인합니다.
- OpenShift 웹 콘솔에서 스토리지 → Data Foundation 을 클릭합니다.
-
Storage Systems 탭을 클릭한 다음
ocs-storagecluster-storagesystem을 클릭합니다. - 블록 및 파일 대시보드의 상태 카드 개요 탭에서 Data Resiliency 에 녹색 표시가 있는지 확인합니다.
절차
교체해야 하는 OSD와 OSD가 예약된 OpenShift Container Platform 노드를 확인합니다.
$ oc get -n openshift-storage pods -l app=rook-ceph-osd -o wide
출력 예:
rook-ceph-osd-0-6d77d6c7c6-m8xj6 0/1 CrashLoopBackOff 0 24h 10.129.0.16 compute-2 <none> <none> rook-ceph-osd-1-85d99fb95f-2svc7 1/1 Running 0 24h 10.128.2.24 compute-0 <none> <none> rook-ceph-osd-2-6c66cdb977-jp542 1/1 Running 0 24h 10.130.0.18 compute-1 <none> <none>
이 예에서는
rook-ceph-osd-0-6d77d6c7c6-m8xj6을 교체해야 하며compute-2는 OSD가 예약된 OpenShift Container Platform 노드입니다.참고교체할 OSD가 정상이면 포드 상태가
Running이 됩니다.OSD를 교체할 OSD 배포를 축소합니다.
OSD를 교체할 때마다
osd_id_to_remove매개변수를 OSD ID로 업데이트하고 이 단계를 반복합니다.$ osd_id_to_remove=0
$ oc scale -n openshift-storage deployment rook-ceph-osd-${osd_id_to_remove} --replicas=0여기서
osd_id_to_remove는rook-ceph-osd접두사 직후 Pod 이름의 정수입니다. 이 예제에서 배포 이름은rook-ceph-osd-0입니다.출력 예:
deployment.extensions/rook-ceph-osd-0 scaled
rook-ceph-osdPod가 종료되었는지 확인합니다.$ oc get -n openshift-storage pods -l ceph-osd-id=${osd_id_to_remove}출력 예:
No resources found.
중요rook-ceph-osdPod가종료상태인 경우force옵션을 사용하여 Pod를 삭제합니다.$ oc delete pod rook-ceph-osd-0-6d77d6c7c6-m8xj6 --force --grace-period=0
출력 예:
warning: Immediate deletion does not wait for confirmation that the running resource has been terminated. The resource may continue to run on the cluster indefinitely. pod "rook-ceph-osd-0-6d77d6c7c6-m8xj6" force deleted
새 OSD를 추가할 수 있도록 클러스터에서 이전 OSD를 제거합니다.
이전
ocs-osd-removal작업을 삭제합니다.$ oc delete -n openshift-storage job ocs-osd-removal-job
출력 예:
job.batch "ocs-osd-removal-job"
openshift-storage프로젝트로 이동합니다.$ oc project openshift-storage
클러스터에서 이전 OSD를 제거합니다.
$ oc process -n openshift-storage ocs-osd-removal -p FAILED_OSD_IDS=${osd_id_to_remove} -p FORCE_OSD_REMOVAL=false |oc create -n openshift-storage -f -OSD가 3개뿐인 클러스터에서 FORCE_OSD_REMOVAL 값을 "true"로 변경해야 합니다. OSD를 제거한 후 3개의 데이터 복제본을 모두 복원할 수 있는 공간이 충분하지 않은 클러스터에서는 FORCE_OSD_REMOVAL 값을 "true"로 변경해야 합니다.
주의이 단계에서는 클러스터에서 OSD가 완전히 제거됩니다.
osd_id_to_remove의 올바른 값이 제공되었는지 확인합니다.
ocs-osd-removal-jobPod의 상태를 확인하여 OSD가 성공적으로 제거되었는지 확인합니다.Completed상태로 인해 OSD 제거 작업이 성공했는지 확인합니다.$ oc get pod -l job-name=ocs-osd-removal-job -n openshift-storage
OSD 제거가 완료되었는지 확인합니다.
$ oc logs -l job-name=ocs-osd-removal-job -n openshift-storage --tail=-1 | egrep -i 'completed removal'
출력 예:
2022-05-10 06:50:04.501511 I | cephosd: completed removal of OSD 0
중요ocs-osd-removal-job이 실패하고 Pod가 예상Completed상태가 아닌 경우 Pod 로그를 확인하여 추가 디버깅을 확인합니다.예를 들면 다음과 같습니다.
# oc logs -l job-name=ocs-osd-removal-job -n openshift-storage --tail=-1'
설치 시 암호화를 활성화한 경우 해당 OpenShift Data Foundation 노드에서 제거된 OSD 장치에서
dm-cryptmanageddevice-mapper매핑을 제거합니다.ocs-osd-removal-jobPod 로그에서 교체된 OSD의 PVC 이름을 가져옵니다.$ oc logs -l job-name=ocs-osd-removal-job -n openshift-storage --tail=-1 |egrep -i ‘pvc|deviceset’
출력 예:
2021-05-12 14:31:34.666000 I | cephosd: removing the OSD PVC "ocs-deviceset-xxxx-xxx-xxx-xxx"
이전에 식별한 각 노드에 대해 다음을 수행합니다.
스토리지 노드의 호스트에
디버그Pod와chroot를 만듭니다.$ oc debug node/<node name><node name>노드의 이름입니다.
$ chroot /host
이전 단계에서 식별한 PVC 이름을 기반으로 관련 장치 이름을 찾습니다.
$ dmsetup ls| grep <pvc name><pvc name>PVC의 이름입니다.
출력 예:
ocs-deviceset-xxx-xxx-xxx-xxx-block-dmcrypt (253:0)
매핑된 장치를 제거합니다.
$ cryptsetup luksClose --debug --verbose ocs-deviceset-xxx-xxx-xxx-xxx-block-dmcrypt
중요충분하지 않은 권한으로 인해 위의 명령이 정지되면 다음 명령을 실행합니다.
-
CTRL+Z를 눌러 위 명령을 종료합니다. 정지된 프로세스의 PID를 찾습니다.
$ ps -ef | grep crypt
kill명령을 사용하여 프로세스를 종료합니다.$ kill -9 <PID><PID>- 는 프로세스 ID입니다.
장치 이름이 제거되었는지 확인합니다.
$ dmsetup ls
-
ocs-osd-removal작업을 삭제합니다.$ oc delete -n openshift-storage job ocs-osd-removal-job
출력 예:
job.batch "ocs-osd-removal-job" deleted
데이터 암호화와 함께 외부 키 관리 시스템(KMS)을 사용하는 경우 이제 고립된 키가기 때문에 이전 OSD 암호화 키를 Vault 서버에서 제거할 수 있습니다.
검증 단계
실행 중인 새 OSD가 있는지 확인합니다.
$ oc get -n openshift-storage pods -l app=rook-ceph-osd
출력 예:
rook-ceph-osd-0-5f7f4747d4-snshw 1/1 Running 0 4m47s rook-ceph-osd-1-85d99fb95f-2svc7 1/1 Running 0 1d20h rook-ceph-osd-2-6c66cdb977-jp542 1/1 Running 0 1d20h
Bound상태에 있는 새 PVC가 생성되었는지 확인합니다.$ oc get -n openshift-storage pvc
선택 사항: 클러스터에서 클러스터 전체 암호화를 사용하는 경우 새 OSD 장치가 암호화되었는지 확인합니다.
새 OSD 포드가 실행 중인 노드를 식별합니다.
$ oc get -n openshift-storage -o=custom-columns=NODE:.spec.nodeName pod/<OSD-pod-name><OSD-pod-name>는 OSD 포드의 이름입니다.
예를 들면 다음과 같습니다.
$ oc get -n openshift-storage -o=custom-columns=NODE:.spec.nodeName pod/rook-ceph-osd-0-544db49d7f-qrgqm
출력 예:
NODE compute-1
이전에 식별한 각 노드에 대해 다음을 수행합니다.
디버그 Pod를 생성하고 선택한 호스트에 대한 chroot 환경을 엽니다.
$ oc debug node/<node name><node name>노드의 이름입니다.
$ chroot /host
ocs-deviceset이름 옆에crypt키워드가 있는지 확인합니다.$ lsblk
- OpenShift 웹 콘솔에 로그인하고 스토리지 대시보드를 확인합니다.
4장. Microsoft Azure에 배포된 동적으로 프로비저닝된 OpenShift Data Foundation
4.1. Azure 설치 관리자 프로비저닝 인프라에서 운영 또는 실패한 스토리지 장치 교체
Azure 설치 관리자 프로비저닝 인프라에서 동적으로 생성된 스토리지 클러스터에서 장치를 교체해야 하는 경우 스토리지 노드를 교체해야 합니다. 노드를 교체하는 방법에 대한 자세한 내용은 다음을 참조하십시오.
5장. 로컬 스토리지 장치를 사용하여 배포된 OpenShift Data Foundation
5.1. 로컬 스토리지 장치에서 지원하는 클러스터에서 운영 또는 실패한 스토리지 장치 교체
다음 인프라의 로컬 스토리지 장치를 사용하여 배포된 OpenShift Data Foundation의 OSD(오브젝트 스토리지 장치)를 교체할 수 있습니다.
- 베어 메탈
- VMware
- Red Hat Virtualization
하나 이상의 기본 스토리지 장치를 교체해야 할 수 있습니다.
사전 요구 사항
- 교체 장치는 장치 교체와 유사한 인프라 및 리소스로 구성된 것이 좋습니다.
데이터가 탄력적인지 확인합니다.
- OpenShift 웹 콘솔에서 스토리지 → Data Foundation 을 클릭합니다.
-
Storage Systems 탭을 클릭한 다음
ocs-storagecluster-storagesystem을 클릭합니다. - 블록 및 파일 대시보드의 상태 카드 개요 탭에서 Data Resiliency 에 녹색 표시가 있는지 확인합니다.
절차
- 관련 작업자 노드에서 기본 스토리지 장치를 제거합니다.
관련 OSD Pod가 CrashLoopBackOff 상태로 이동했는지 확인합니다.
교체해야 하는 OSD와 OSD가 예약된 OpenShift Container Platform 노드를 확인합니다.
$ oc get -n openshift-storage pods -l app=rook-ceph-osd -o wide
출력 예:
rook-ceph-osd-0-6d77d6c7c6-m8xj6 0/1 CrashLoopBackOff 0 24h 10.129.0.16 compute-2 <none> <none> rook-ceph-osd-1-85d99fb95f-2svc7 1/1 Running 0 24h 10.128.2.24 compute-0 <none> <none> rook-ceph-osd-2-6c66cdb977-jp542 1/1 Running 0 24h 10.130.0.18 compute-1 <none> <none>
이 예에서는
rook-ceph-osd-0-6d77d6c7c6-m8xj6을 교체해야 하며compute-2는 OSD가 예약된 OpenShift Container Platform 노드입니다.OSD를 교체할 OSD 배포를 축소합니다.
$ osd_id_to_remove=0
$ oc scale -n openshift-storage deployment rook-ceph-osd-${osd_id_to_remove} --replicas=0여기서
osd_id_to_remove는rook-ceph-osd접두사 직후 Pod 이름의 정수입니다. 이 예제에서 배포 이름은rook-ceph-osd-0입니다.출력 예:
deployment.extensions/rook-ceph-osd-0 scaled
rook-ceph-osdPod가 종료되었는지 확인합니다.$ oc get -n openshift-storage pods -l ceph-osd-id=${osd_id_to_remove}출력 예:
No resources found in openshift-storage namespace.
중요rook-ceph-osdPod가 몇 분 이상종료중이면force옵션을 사용하여 Pod를 삭제합니다.$ oc delete -n openshift-storage pod rook-ceph-osd-0-6d77d6c7c6-m8xj6 --grace-period=0 --force
출력 예:
warning: Immediate deletion does not wait for confirmation that the running resource has been terminated. The resource may continue to run on the cluster indefinitely. pod "rook-ceph-osd-0-6d77d6c7c6-m8xj6" force deleted
새 OSD를 추가할 수 있도록 클러스터에서 이전 OSD를 제거합니다.
이전
ocs-osd-removal작업을 삭제합니다.$ oc delete -n openshift-storage job ocs-osd-removal-job
출력 예:
job.batch "ocs-osd-removal-job" deleted
openshift-storage프로젝트로 이동합니다.$ oc project openshift-storage
클러스터에서 이전 OSD를 제거합니다.
$ oc process -n openshift-storage ocs-osd-removal -p FAILED_OSD_IDS=${osd_id_to_remove} -p FORCE_OSD_REMOVAL=false |oc create -n openshift-storage -f -OSD가 3개뿐인 클러스터에서 FORCE_OSD_REMOVAL 값을 "true"로 변경해야 합니다. OSD를 제거한 후 3개의 데이터 복제본을 모두 복원할 수 있는 공간이 충분하지 않은 클러스터에서는 FORCE_OSD_REMOVAL 값을 "true"로 변경해야 합니다.
주의이 단계에서는 클러스터에서 OSD가 완전히 제거됩니다.
osd_id_to_remove의 올바른 값이 제공되었는지 확인합니다.
ocs-osd-removal-jobPod의 상태를 확인하여 OSD가 성공적으로 제거되었는지 확인합니다.Completed상태로 인해 OSD 제거 작업이 성공했는지 확인합니다.$ oc get pod -l job-name=ocs-osd-removal-job -n openshift-storage
OSD 제거가 완료되었는지 확인합니다.
$ oc logs -l job-name=ocs-osd-removal-job -n openshift-storage --tail=-1 | egrep -i 'completed removal'
출력 예:
2022-05-10 06:50:04.501511 I | cephosd: completed removal of OSD 0
중요ocs-osd-removal-job이 실패하고 Pod가 예상Completed상태가 아닌 경우 Pod 로그를 확인하여 추가 디버깅을 확인합니다.예를 들면 다음과 같습니다.
# oc logs -l job-name=ocs-osd-removal-job -n openshift-storage --tail=-1
설치 시 암호화를 활성화한 경우 해당 OpenShift Data Foundation 노드에서 제거된 OSD 장치에서
dm-cryptmanageddevice-mapper매핑을 제거합니다.ocs-osd-removal-jobPod 로그에서 교체된 OSD의 PVC(영구 볼륨 클레임) 이름을 가져옵니다.$ oc logs -l job-name=ocs-osd-removal-job -n openshift-storage --tail=-1 |egrep -i 'pvc|deviceset'
출력 예:
2021-05-12 14:31:34.666000 I | cephosd: removing the OSD PVC "ocs-deviceset-xxxx-xxx-xxx-xxx"
이전에 식별한 각 노드에 대해 다음을 수행합니다.
스토리지 노드의 호스트에
디버그Pod와chroot를 만듭니다.$ oc debug node/<node name><node name>노드의 이름입니다.
$ chroot /host
이전 단계에서 식별한 PVC 이름을 기반으로 관련 장치 이름을 찾습니다.
$ dmsetup ls| grep <pvc name><pvc name>PVC의 이름입니다.
출력 예:
ocs-deviceset-xxx-xxx-xxx-xxx-block-dmcrypt (253:0)
매핑된 장치를 제거합니다.
$ cryptsetup luksClose --debug --verbose <ocs-deviceset-name><ocs-deviceset-name>이전 단계에서 식별한 PVC 이름을 기반으로 하는 관련 장치의 이름입니다.
중요충분하지 않은 권한으로 인해 위의 명령이 정지되면 다음 명령을 실행합니다.
-
CTRL+Z를 눌러 위 명령을 종료합니다. 정지된 프로세스의 PID를 찾습니다.
$ ps -ef | grep crypt
kill명령을 사용하여 프로세스를 종료합니다.$ kill -9 <PID><PID>- 는 프로세스 ID입니다.
장치 이름이 제거되었는지 확인합니다.
$ dmsetup ls
-
삭제해야 하는 PV(영구 볼륨)를 찾습니다.
$ oc get pv -L kubernetes.io/hostname | grep <storageclass-name> | grep Released
출력 예:
local-pv-d6bf175b 1490Gi RWO Delete Released openshift-storage/ocs-deviceset-0-data-0-6c5pw localblock 2d22h compute-1
PV를 삭제합니다.
$ oc delete pv <pv_name>- 노드에 물리적으로 새 장치를 추가합니다.
deviceInclusionSpec과 일치하는 장치의 PV 프로비저닝을 추적합니다. PV를 프로비저닝하는 데 몇 분이 걸릴 수 있습니다.$ oc -n openshift-local-storage describe localvolumeset localblock
출력 예:
[...] Status: Conditions: Last Transition Time: 2020-11-17T05:03:32Z Message: DiskMaker: Available, LocalProvisioner: Available Status: True Type: DaemonSetsAvailable Last Transition Time: 2020-11-17T05:03:34Z Message: Operator reconciled successfully. Status: True Type: Available Observed Generation: 1 Total Provisioned Device Count: 4 Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Discovered 2m30s (x4 localvolumeset- node.example.com - NewDevice over 2m30s) symlink-controller found possible matching disk, waiting 1m to claim Normal FoundMatch 89s (x4 localvolumeset- node.example.com - ingDisk over 89s) symlink-controller symlinking matching diskPV가 프로비저닝되면 PV에 대해 새 OSD Pod가 자동으로 생성됩니다.
ocs-osd-removal작업을 삭제합니다.$ oc delete -n openshift-storage job ocs-osd-removal-job
출력 예:
job.batch "ocs-osd-removal-job" deleted
데이터 암호화와 함께 외부 키 관리 시스템(KMS)을 사용하는 경우 이제 고립된 키가기 때문에 이전 OSD 암호화 키를 Vault 서버에서 제거할 수 있습니다.
검증 단계
실행 중인 새 OSD가 있는지 확인합니다.
$ oc get -n openshift-storage pods -l app=rook-ceph-osd
출력 예:
rook-ceph-osd-0-5f7f4747d4-snshw 1/1 Running 0 4m47s rook-ceph-osd-1-85d99fb95f-2svc7 1/1 Running 0 1d20h rook-ceph-osd-2-6c66cdb977-jp542 1/1 Running 0 1d20h
중요새 OSD가 몇 분 후에
Running으로 표시되지 않으면rook-ceph-operatorPod를 다시 시작하여 조정을 강제 적용합니다.$ oc delete pod -n openshift-storage -l app=rook-ceph-operator
출력 예:
pod "rook-ceph-operator-6f74fb5bff-2d982" deleted
새 PVC가 생성되었는지 확인합니다.
$ oc get -n openshift-storage pvc | grep localblock
출력 예:
ocs-deviceset-0-0-c2mqb Bound local-pv-b481410 1490Gi RWO localblock 5m ocs-deviceset-1-0-959rp Bound local-pv-414755e0 1490Gi RWO localblock 1d20h ocs-deviceset-2-0-79j94 Bound local-pv-3e8964d3 1490Gi RWO localblock 1d20h
선택 사항: 클러스터에서 클러스터 전체 암호화를 사용하는 경우 새 OSD 장치가 암호화되었는지 확인합니다.
새 OSD 포드가 실행 중인 노드를 식별합니다.
$ oc get -n openshift-storage -o=custom-columns=NODE:.spec.nodeName pod/<OSD-pod-name><OSD-pod-name>는 OSD 포드의 이름입니다.
예를 들면 다음과 같습니다.
$ oc get -n openshift-storage -o=custom-columns=NODE:.spec.nodeName pod/rook-ceph-osd-0-544db49d7f-qrgqm
출력 예:
NODE compute-1
이전 단계에서 확인한 각 노드에 대해 다음을 수행합니다.
디버그 Pod를 생성하고 선택한 호스트에 대한 chroot 환경을 엽니다.
$ oc debug node/<node name><node name>노드의 이름입니다.
$ chroot /host
ocs-deviceset이름 옆에crypt키워드가 있는지 확인합니다.$ lsblk
- OpenShift 웹 콘솔에 로그인하고 스토리지 대시보드에서 OSD 상태를 확인합니다.
전체 데이터 복구는 복구되는 데이터 볼륨에 따라 더 오래 걸릴 수 있습니다.
5.2. IBM Power에서 운영되거나 실패한 스토리지 장치 교체
IBM Power의 로컬 스토리지 장치를 사용하여 배포된 OpenShift Data Foundation의 OSD(오브젝트 스토리지 장치)를 교체할 수 있습니다.
하나 이상의 기본 스토리지 장치를 교체해야 할 수 있습니다.
사전 요구 사항
- 교체 장치는 장치 교체와 유사한 인프라 및 리소스로 구성된 것이 좋습니다.
데이터가 탄력적인지 확인합니다.
- OpenShift 웹 콘솔에서 스토리지 → Data Foundation 을 클릭합니다.
-
Storage Systems 탭을 클릭한 다음
ocs-storagecluster-storagesystem을 클릭합니다. - 블록 및 파일 대시보드의 상태 카드 개요 탭에서 Data Resiliency 에 녹색 표시가 있는지 확인합니다.
절차
교체해야 하는 OSD와 OSD가 예약된 OpenShift Container Platform 노드를 확인합니다.
$ oc get -n openshift-storage pods -l app=rook-ceph-osd -o wide
출력 예:
rook-ceph-osd-0-86bf8cdc8-4nb5t 0/1 crashLoopBackOff 0 24h 10.129.2.26 worker-0 <none> <none> rook-ceph-osd-1-7c99657cfb-jdzvz 1/1 Running 0 24h 10.128.2.46 worker-1 <none> <none> rook-ceph-osd-2-5f9f6dfb5b-2mnw9 1/1 Running 0 24h 10.131.0.33 worker-2 <none> <none>
이 예에서는
rook-ceph-osd-0-86bf8cdc8-4nb5t를 교체해야 하며worker-0은 OSD가 예약된 node입니다.참고교체할 OSD가 정상이면 포드 상태가
Running이 됩니다.OSD를 교체할 OSD 배포를 축소합니다.
$ osd_id_to_remove=0
$ oc scale -n openshift-storage deployment rook-ceph-osd-${osd_id_to_remove} --replicas=0여기서
osd_id_to_remove는rook-ceph-osd접두사 직후 Pod 이름의 정수입니다. 이 예제에서 배포 이름은rook-ceph-osd-0입니다.출력 예:
deployment.extensions/rook-ceph-osd-0 scaled
rook-ceph-osdPod가 종료되었는지 확인합니다.$ oc get -n openshift-storage pods -l ceph-osd-id=${osd_id_to_remove}출력 예:
No resources found in openshift-storage namespace.
중요rook-ceph-osdPod가 몇 분 이상종료중이면force옵션을 사용하여 Pod를 삭제합니다.$ oc delete -n openshift-storage pod rook-ceph-osd-0-86bf8cdc8-4nb5t --grace-period=0 --force
출력 예:
warning: Immediate deletion does not wait for confirmation that the running resource has been terminated. The resource may continue to run on the cluster indefinitely. pod "rook-ceph-osd-0-86bf8cdc8-4nb5t" force deleted
새 OSD를 추가할 수 있도록 클러스터에서 이전 OSD를 제거합니다.
교체할 OSD와 연결된
DeviceSet을 확인합니다.$ oc get -n openshift-storage -o yaml deployment rook-ceph-osd-${osd_id_to_remove} | grep ceph.rook.io/pvc출력 예:
ceph.rook.io/pvc: ocs-deviceset-localblock-0-data-0-64xjl ceph.rook.io/pvc: ocs-deviceset-localblock-0-data-0-64xjl이 예에서 PVC(영구 볼륨 클레임) 이름은
ocs-deviceset-localblock-0-data-0-64xjl입니다.PVC와 연결된 영구 볼륨(PV)을 확인합니다.
$ oc get -n openshift-storage pvc ocs-deviceset-<x>-<y>-<pvc-suffix>
여기서,
x,y,pvc-suffix는 이전 단계에서 식별된DeviceSet의 값입니다.출력 예:
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE ocs-deviceset-localblock-0-data-0-64xjl Bound local-pv-8137c873 256Gi RWO localblock 24h
이 예에서 관련 PV는
local-pv-8137c873입니다.교체할 장치의 이름을 확인합니다.
$ oc get pv local-pv-<pv-suffix> -o yaml | grep path여기서
pv-suffix는 이전 단계에서 확인된 PV 이름의 값입니다.출력 예:
path: /mnt/local-storage/localblock/vdc
이 예에서 장치 이름은 ECDHE
입니다.교체할 OSD와 연결된
prepare-pod를 확인합니다.$ oc describe -n openshift-storage pvc ocs-deviceset-<x>-<y>-<pvc-suffix> | grep Used
여기서,
x,y,pvc-suffix는 이전 단계에서 식별된DeviceSet의 값입니다.출력 예:
Used By: rook-ceph-osd-prepare-ocs-deviceset-localblock-0-data-0-64knzkc
이 예에서
prepare-pod이름은rook-ceph-osd-prepare-ocs-deviceset-localblock-0-data-0-64kkc입니다.이전
ocs-osd-removal작업을 삭제합니다.$ oc delete -n openshift-storage job ocs-osd-removal-job
출력 예:
job.batch "ocs-osd-removal-job" deleted
openshift-storage프로젝트로 변경합니다.$ oc project openshift-storage
클러스터에서 이전 OSD를 제거합니다.
$ oc process -n openshift-storage ocs-osd-removal -p FAILED_OSD_IDS=${osd_id_to_remove} -p FORCE_OSD_REMOVAL=false |oc create -n openshift-storage -f -OSD가 3개뿐인 클러스터에서 FORCE_OSD_REMOVAL 값을 "true"로 변경해야 합니다. OSD를 제거한 후 3개의 데이터 복제본을 모두 복원할 수 있는 공간이 충분하지 않은 클러스터에서는 FORCE_OSD_REMOVAL 값을 "true"로 변경해야 합니다.
주의이 단계에서는 클러스터에서 OSD가 완전히 제거됩니다.
osd_id_to_remove의 올바른 값이 제공되었는지 확인합니다.
ocs-osd-removal-jobPod의 상태를 확인하여 OSD가 성공적으로 제거되었는지 확인합니다.Completed상태로 인해 OSD 제거 작업이 성공했는지 확인합니다.$ oc get pod -l job-name=ocs-osd-removal-job -n openshift-storage
OSD 제거가 완료되었는지 확인합니다.
$ oc logs -l job-name=ocs-osd-removal-job -n openshift-storage --tail=-1 | egrep -i 'completed removal'
출력 예:
2022-05-10 06:50:04.501511 I | cephosd: completed removal of OSD 0
중요ocs-osd-removal-job이 실패하고 Pod가 예상Completed상태가 아닌 경우 Pod 로그를 확인하여 추가 디버깅을 확인합니다.예를 들면 다음과 같습니다.
# oc logs -l job-name=ocs-osd-removal-job -n openshift-storage --tail=-1
설치 시 암호화를 활성화한 경우 해당 OpenShift Data Foundation 노드에서 제거된 OSD 장치에서
dm-cryptmanageddevice-mapper매핑을 제거합니다.ocs-osd-removal-jobPod 로그에서 교체된 OSD의 PVC 이름을 가져옵니다.$ oc logs -l job-name=ocs-osd-removal-job -n openshift-storage --tail=-1 |egrep -i ‘pvc|deviceset’
출력 예:
2021-05-12 14:31:34.666000 I | cephosd: removing the OSD PVC "ocs-deviceset-xxxx-xxx-xxx-xxx"
이전에 식별한 각 노드에 대해 다음을 수행합니다.
스토리지 노드의 호스트에
디버그Pod와chroot를 만듭니다.$ oc debug node/<node name><node name>노드의 이름입니다.
$ chroot /host
이전 단계에서 식별한 PVC 이름을 기반으로 관련 장치 이름을 찾습니다.
$ dmsetup ls| grep <pvc name><pvc name>PVC의 이름입니다.
출력 예:
ocs-deviceset-xxx-xxx-xxx-xxx-block-dmcrypt (253:0)
매핑된 장치를 제거합니다.
$ cryptsetup luksClose --debug --verbose ocs-deviceset-xxx-xxx-xxx-xxx-block-dmcrypt
중요충분하지 않은 권한으로 인해 위의 명령이 정지되면 다음 명령을 실행합니다.
-
CTRL+Z를 눌러 위 명령을 종료합니다. 정지된 프로세스의 PID를 찾습니다.
$ ps -ef | grep crypt
kill명령을 사용하여 프로세스를 종료합니다.$ kill -9 <PID><PID>- 는 프로세스 ID입니다.
장치 이름이 제거되었는지 확인합니다.
$ dmsetup ls
-
삭제해야 하는 PV를 찾습니다.
$ oc get pv -L kubernetes.io/hostname | grep localblock | grep Released
출력 예:
local-pv-d6bf175b 1490Gi RWO Delete Released openshift-storage/ocs-deviceset-0-data-0-6c5pw localblock 2d22h compute-1
PV를 삭제합니다.
$ oc delete pv <pv-name><pv-name>- 는 PV의 이름입니다.
이전 장치를 교체하고 새 장치를 사용하여 새 OpenShift Container Platform PV를 생성합니다.
교체할 장치로 OpenShift Container Platform 노드에 로그인합니다. 이 예에서 OpenShift Container Platform 노드는
worker-0입니다.$ oc debug node/worker-0
출력 예:
Starting pod/worker-0-debug ... To use host binaries, run `chroot /host` Pod IP: 192.168.88.21 If you don't see a command prompt, try pressing enter. # chroot /host
이전에 식별된 장치 이름인 ECDHE/disk를 사용하여 교체할
/dev/disk를 기록합니다.# ls -alh /mnt/local-storage/localblock
출력 예:
total 0 drwxr-xr-x. 2 root root 17 Nov 18 15:23 . drwxr-xr-x. 3 root root 24 Nov 18 15:23 .. lrwxrwxrwx. 1 root root 8 Nov 18 15:23 vdc -> /dev/vdc
LocalVolumeCR의 이름을 찾고 교체할/dev/disk장치를 제거하거나 주석 처리합니다.$ oc get -n openshift-local-storage localvolume
출력 예:
NAME AGE localblock 25h
# oc edit -n openshift-local-storage localvolume localblock
출력 예:
[...] storageClassDevices: - devicePaths: # - /dev/vdc storageClassName: localblock volumeMode: Block [...]CR을 편집한 후 변경 사항을 저장해야 합니다.
교체될 장치가 있는 OpenShift Container Platform 노드에 로그인하고 이전
심볼릭링크를 제거합니다.$ oc debug node/worker-0
출력 예:
Starting pod/worker-0-debug ... To use host binaries, run `chroot /host` Pod IP: 192.168.88.21 If you don't see a command prompt, try pressing enter. # chroot /host
교체할 장치 이름의 이전
심볼릭 링크를확인합니다. 이 예에서 장치 이름은 ECDHE입니다.# ls -alh /mnt/local-storage/localblock
출력 예:
total 0 drwxr-xr-x. 2 root root 17 Nov 18 15:23 . drwxr-xr-x. 3 root root 24 Nov 18 15:23 .. lrwxrwxrwx. 1 root root 8 Nov 18 15:23 vdc -> /dev/vdc
심볼릭링크를 제거합니다.# rm /mnt/local-storage/localblock/vdc
심볼릭 링크가제거되었는지 확인합니다.# ls -alh /mnt/local-storage/localblock
출력 예:
total 0 drwxr-xr-x. 2 root root 6 Nov 18 17:11 . drwxr-xr-x. 3 root root 24 Nov 18 15:23 ..
- 이전 장치를 새 장치로 교체합니다.
올바른 OpenShift Cotainer Platform 노드에 다시 로그인하고 새 드라이브의 장치 이름을 확인합니다. 동일한 장치를 재설정하지 않는 한 장치 이름을 변경해야 합니다.
# lsblk
출력 예:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT vda 252:0 0 40G 0 disk |-vda1 252:1 0 4M 0 part |-vda2 252:2 0 384M 0 part /boot `-vda4 252:4 0 39.6G 0 part `-coreos-luks-root-nocrypt 253:0 0 39.6G 0 dm /sysroot vdb 252:16 0 512B 1 disk vdd 252:32 0 256G 0 disk
이 예에서 새 장치 이름은
vdd입니다.새
/dev/disk를 사용할 수 있게 되면 LocalVolume CR에 새 디스크 항목을 추가할 수 있습니다.LocalVolume CR을 편집하고 새
/dev/disk를 추가합니다.이 예에서 새 장치는
/dev/vdd입니다.# oc edit -n openshift-local-storage localvolume localblock
출력 예:
[...] storageClassDevices: - devicePaths: # - /dev/vdc - /dev/vdd storageClassName: localblock volumeMode: Block [...]CR을 편집한 후 변경 사항을 저장해야 합니다.
새 PV의
Available상태와 올바른 크기가 있는지 확인합니다.$ oc get pv | grep 256Gi
출력 예:
local-pv-1e31f771 256Gi RWO Delete Bound openshift-storage/ocs-deviceset-localblock-2-data-0-6xhkf localblock 24h local-pv-ec7f2b80 256Gi RWO Delete Bound openshift-storage/ocs-deviceset-localblock-1-data-0-hr2fx localblock 24h local-pv-8137c873 256Gi RWO Delete Available localblock 32m
새 장치에 사용할 새 OSD를 만듭니다.
새 OSD를 배포합니다. Operator가 조정하도록
rook-ceph-operator를 다시 시작해야 합니다.rook-ceph-operator의 이름을 확인합니다.$ oc get -n openshift-storage pod -l app=rook-ceph-operator
출력 예:
NAME READY STATUS RESTARTS AGE rook-ceph-operator-85f6494db4-sg62v 1/1 Running 0 1d20h
rook-ceph-operator를 삭제합니다.$ oc delete -n openshift-storage pod rook-ceph-operator-85f6494db4-sg62v
출력 예:
pod "rook-ceph-operator-85f6494db4-sg62v" deleted
이 예에서 rook-ceph-operator Pod 이름은
rook-ceph-operator-85f6494db4-sg62v입니다.rook-ceph-operatorPod가 다시 시작되었는지 확인합니다.$ oc get -n openshift-storage pod -l app=rook-ceph-operator
출력 예:
NAME READY STATUS RESTARTS AGE rook-ceph-operator-85f6494db4-wx9xx 1/1 Running 0 50s
새 OSD를 생성하려면 Operator를 다시 시작한 후 몇 분이 걸릴 수 있습니다.
ocs-osd-removal작업을 삭제합니다.$ oc delete -n openshift-storage job ocs-osd-removal-job
출력 예:
job.batch "ocs-osd-removal-job" deleted
데이터 암호화와 함께 외부 키 관리 시스템(KMS)을 사용하는 경우 이제 고립된 키가기 때문에 이전 OSD 암호화 키를 Vault 서버에서 제거할 수 있습니다.
검증 단계
실행 중인 새 OSD가 있는지 확인합니다.
$ oc get -n openshift-storage pods -l app=rook-ceph-osd
출력 예:
rook-ceph-osd-0-76d8fb97f9-mn8qz 1/1 Running 0 23m rook-ceph-osd-1-7c99657cfb-jdzvz 1/1 Running 1 25h rook-ceph-osd-2-5f9f6dfb5b-2mnw9 1/1 Running 0 25h
새 PVC가 생성되었는지 확인합니다.
$ oc get -n openshift-storage pvc | grep localblock
출력 예:
ocs-deviceset-localblock-0-data-0-q4q6b Bound local-pv-8137c873 256Gi RWO localblock 10m ocs-deviceset-localblock-1-data-0-hr2fx Bound local-pv-ec7f2b80 256Gi RWO localblock 1d20h ocs-deviceset-localblock-2-data-0-6xhkf Bound local-pv-1e31f771 256Gi RWO localblock 1d20h
선택 사항: 클러스터에서 클러스터 전체 암호화를 사용하는 경우 새 OSD 장치가 암호화되었는지 확인합니다.
새 OSD 포드가 실행 중인 노드를 식별합니다.
$ oc get -n openshift-storage -o=custom-columns=NODE:.spec.nodeName pod/<OSD-pod-name><OSD-pod-name>는 OSD 포드의 이름입니다.
예를 들면 다음과 같습니다.
$ oc get -n openshift-storage -o=custom-columns=NODE:.spec.nodeName pod/rook-ceph-osd-0-544db49d7f-qrgqm
출력 예:
NODE compute-1
이전에 식별한 각 노드에 대해 다음을 수행합니다.
디버그 Pod를 생성하고 선택한 호스트에 대한 chroot 환경을 엽니다.
$ oc debug node/<node name><node name>노드의 이름입니다.
$ chroot /host
ocs-deviceset이름 옆에crypt키워드가 있는지 확인합니다.$ lsblk
- OpenShift 웹 콘솔에 로그인하고 스토리지 섹션에서 OpenShift Data Foundation 대시보드의 상태 카드를 확인합니다.
전체 데이터 복구는 복구되는 데이터 볼륨에 따라 더 오래 걸릴 수 있습니다.
5.3. IBM Z 또는 LinuxONE 인프라에서 운영되거나 실패한 스토리지 장치 교체
IBM Z 또는 LinuxONE 인프라에서 운영 또는 실패한 스토리지 장치를 새로운 CSI(SCSI) 디스크로 교체할 수 있습니다.
IBM Z 또는 LinuxONE은 외부 디스크 스토리지의 영구 스토리지 장치로 SCSI FCP 디스크(SCSI 디스크)를 지원합니다. FCP 장치 번호, 세계 포트 이름 두 개(WWPN1 및 WWPN2), 논리 단위 번호(LUN)를 사용하여 SCSI 디스크를 식별할 수 있습니다. 자세한 내용은 https://www.ibm.com/support/knowledgecenter/SSB27U_6.4.0/com.ibm.zvm.v640.hcpa5/scsiover.html을 참조하십시오.
사전 요구 사항
데이터가 탄력적인지 확인합니다.
- OpenShift 웹 콘솔에서 스토리지 → Data Foundation 을 클릭합니다.
-
Storage Systems 탭을 클릭한 다음
ocs-storagecluster-storagesystem을 클릭합니다. - 블록 및 파일 대시보드의 상태 카드 개요 탭에서 Data Resiliency 에 녹색 표시가 있는지 확인합니다.
절차
모든 디스크를 나열합니다.
$ lszdev
출력 예:
TYPE ID zfcp-host 0.0.8204 yes yes zfcp-lun 0.0.8204:0x102107630b1b5060:0x4001402900000000 yes no sda sg0 zfcp-lun 0.0.8204:0x500407630c0b50a4:0x3002b03000000000 yes yes sdb sg1 qeth 0.0.bdd0:0.0.bdd1:0.0.bdd2 yes no encbdd0 generic-ccw 0.0.0009 yes no
SCSI 디스크는
ID섹션에서 <device-id>:<wwwpn>:<lun-id> 구조를 사용하여으로 표시됩니다. 첫 번째 디스크는 운영 체제에 사용됩니다. 하나의 스토리지 장치가 실패하면 새 디스크로 교체할 수 있습니다.zfcp-lun디스크를 제거합니다.
디스크에서 다음 명령을 실행하고
scsi-id를 교체할 디스크의 SCSI 디스크 식별자로 바꿉니다.$ chzdev -d scsi-id예를 들어 다음 명령은 장치 ID 0
.0.8204, WWPN0x500507630a0b50a4및 LUN0x4002403000000000을 사용하여 하나의 디스크를 제거합니다.$ chzdev -d 0.0.8204:0x500407630c0b50a4:0x3002b03000000000
새 SCSI 디스크를 추가합니다.
$ chzdev -e 0.0.8204:0x500507630b1b50a4:0x4001302a00000000
참고새 디스크의 장치 ID는 교체할 디스크와 동일해야 합니다. 새 디스크는 WWPN 및 LUN ID로 식별됩니다.
모든 FCP 장치를 나열하여 새 디스크가 구성되었는지 확인합니다.
$ lszdev zfcp-lun
출력 예:
TYPE ID ON PERS NAMES zfcp-lun 0.0.8204:0x102107630b1b5060:0x4001402900000000 yes no sda sg0 zfcp-lun 0.0.8204:0x500507630b1b50a4:0x4001302a00000000 yes yes sdb sg1