5.8. OpenShift Data Foundation 확장 클러스터 복구
확장 클러스터 재해 복구 솔루션은 완전하거나 부분적인 사이트 중단에 직면하여 복원력을 제공하는 것이므로 애플리케이션 및 해당 스토리지에 대한 다양한 복구 방법을 이해하는 것이 중요합니다.
애플리케이션을 배포하는 방법에 따라 활성 영역에서 다시 사용할 수 있는 시간이 결정됩니다.
애플리케이션 및 해당 스토리지 복구 방법은 사이트 중단에 따라 다릅니다. 복구 시간은 애플리케이션 아키텍처에 따라 다릅니다. 다양한 복구 방법은 다음과 같습니다.
5.8.1. 영역 실패 이해 링크 복사링크가 클립보드에 복사되었습니다!
이 섹션의 목적을 위해 영역 장애는 영역의 모든 OpenShift Container Platform, 마스터 및 작업자 노드가 더 이상 두 번째 데이터 영역의 리소스와 통신하지 않는 오류로 간주됩니다(예: 전원이 꺼진 노드). 데이터 영역 간의 통신이 여전히 부분적으로 작동 중인 경우(단순으로 up 또는 down) 클러스터, 스토리지 및 네트워크 관리자가 복구에 성공하기 위해 데이터 영역 간의 통신 경로를 연결 해제해야 합니다.
샘플 애플리케이션을 설치할 때 OpenShift Container Platform 노드의 전원을 끄면 (적어도 OpenShift Data Foundation 장치가 있는 노드) 파일 업로드 애플리케이션을 사용할 수 있는지 확인하기 위해 데이터 영역의 실패를 테스트하고 새 파일을 업로드할 수 있습니다.
5.8.2. RWX 스토리지를 사용하여 영역 인식 HA 애플리케이션 복구 링크 복사링크가 클립보드에 복사되었습니다!
topologyKey를 사용하여 배포되는 애플리케이션: topology.kubernetes.io/zone 에는 각 데이터 영역에 예약된 하나 이상의 복제본이 있고 공유 스토리지(RWX) CephFS 볼륨을 사용하고 몇 분 후에 실패한 영역에 자신을 종료하고 새 Pod가 복구될 때까지 보류 중 상태로 전환되어 보류 중 상태로 고정됩니다.
이러한 유형의 애플리케이션 예는 Install Zone Aware Sample Application 섹션에 설명되어 있습니다.
애플리케이션 Pod가 CephFS 볼륨을 마운트하는 동안 permission denied 오류와 함께 CrashLoopBackOff(CLBO) 상태로 전환한 경우 영역 복구 중에 Pod가 예약된 노드를 다시 시작합니다. 잠시 기다린 다음 포드가 다시 실행되고 있는지 확인합니다.
5.8.3. RWX 스토리지를 사용하여 HA 애플리케이션 복구 링크 복사링크가 클립보드에 복사되었습니다!
topologyKey를 사용하는 애플리케이션: kubernetes.io/hostname 또는 토폴로지 구성이 없는 애플리케이션에서는 동일한 영역에 있는 모든 애플리케이션 복제본에 대해 보호되지 않습니다.
이 유사성 방지 규칙은 영역 기반이 아니므로 Pod 사양의 podAntiAffinity 및 topologyKey: kubernetes.io/hostname 에서도 발생할 수 있습니다.
이 경우 모든 복제본이 실패한 영역에 있으면 활성 영역에서 복구하는 데 RWX(ReadWriteMany) 스토리지를 사용하는 애플리케이션에 6-8분이 걸립니다. 이 일시 중지는 실패한 영역의 OpenShift Container Platform 노드가 NotReady (60 초)가 되고 기본 Pod 제거 시간 초과가 만료되는 데 사용됩니다(300초).
5.8.4. RWO 스토리지를 사용하여 애플리케이션 복구 링크 복사링크가 클립보드에 복사되었습니다!
RWO(ReadWriteOnce) 스토리지를 사용하는 애플리케이션에는 이 Kubernetes 문제에 설명된 알려진 동작이 있습니다. 이 문제로 인해 데이터 영역 장애가 발생하면 해당 영역의 RWO 볼륨(예: cephrbd 기반 볼륨)의 애플리케이션 Pod는 6-8분 후에 종료 상태로 중단되며 수동 개입없이 활성 영역에서 다시 생성되지 않습니다.
상태가 NotReady 인 OpenShift Container Platform 노드를 확인합니다. 노드가 OpenShift 컨트롤 플레인과 통신하지 못하도록 하는 문제가 있을 수 있습니다. 그러나 노드는 PV(영구 볼륨)에 대해 I/O 작업을 계속 수행할 수 있습니다.
두 Pod가 동일한 RWO 볼륨에 동시에 쓰는 경우 데이터 손상 위험이 있습니다. NotReady 노드의 프로세스가 종료될 때까지 종료되거나 차단되었는지 확인합니다.
예제 솔루션:
- 프로세스 종료를 보장하기 위해 대역 외 관리 시스템을 사용하여 노드의 전원을 끄십시오.
실패한 사이트의 노드에서 스토리지와 통신하는 데 사용되는 네트워크 경로를 철회합니다.
참고서비스를 실패한 영역 또는 노드로 복원하기 전에 PV가 있는 모든 Pod가 성공적으로 종료되었는지 확인합니다.
Terminating Pod가 활성 영역에서 다시 생성되도록 가져오려면 Pod를 강제로 삭제하거나 관련 PV에서 종료자를 삭제할 수 있습니다. 이 두 작업 중 하나가 완료되면 애플리케이션 Pod가 활성 영역에서 다시 생성되고 RWO 스토리지를 성공적으로 마운트해야 합니다.
- Pod 강제 삭제
강제 삭제는 Pod가 종료되었음을 kubelet에서 확인할 때까지 기다리지 않습니다.
oc delete pod <PODNAME> --grace-period=0 --force --namespace <NAMESPACE>
$ oc delete pod <PODNAME> --grace-period=0 --force --namespace <NAMESPACE>Copy to Clipboard Copied! Toggle word wrap Toggle overflow <PODNAME>- Pod의 이름입니다.
<NAMESPACE>- 프로젝트 네임스페이스입니다.
- 연결된 PV에서 종료자 삭제
종료 Pod로 마운트된 PVC(영구 볼륨 클레임)의 관련 PV를 찾고
oc patch명령을 사용하여 종료자를 삭제합니다.oc patch -n openshift-storage pv/<PV_NAME> -p '{"metadata":{"finalizers":[]}}' --type=merge$ oc patch -n openshift-storage pv/<PV_NAME> -p '{"metadata":{"finalizers":[]}}' --type=mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow <PV_NAME>PV의 이름입니다.
관련 PV를 쉽게 찾을 수 있는 방법은 종료 Pod를 설명하는 것입니다. 다중 연결 경고가 표시되면 경고에 PV 이름이 있어야 합니다(예:
pvc-0595a8d2-683f-443b-aee0-6e547f5f5a7c).oc describe pod <PODNAME> --namespace <NAMESPACE>
$ oc describe pod <PODNAME> --namespace <NAMESPACE>Copy to Clipboard Copied! Toggle word wrap Toggle overflow <PODNAME>- Pod의 이름입니다.
<NAMESPACE>프로젝트 네임스페이스입니다.
출력 예:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.8.5. StatefulSet Pod 복구 링크 복사링크가 클립보드에 복사되었습니다!
StatefulSet의 일부인 Pod는 RWO(ReadWriteOnce) 볼륨을 마운트하는 Pod와 유사한 문제가 있습니다. 자세한 내용은 Kubernetes 리소스 StatefulSet 고려 사항 에서 참조됩니다.
6-8분 후에 활성 영역에서 다시 생성되도록 StatefulSet의 Pod 부분을 가져오려면 RWO 볼륨이 있는 Pod로 동일한 요구 사항(즉, OpenShift Container Platform 노드의 전원이 꺼지거나 통신이 끊어짐)을 사용하여 Pod를 강제로 삭제해야 합니다.