메트로-DR 확장 클러스터 복구

Red Hat OpenShift Data Foundation 4.9

Red Hat OpenShift Data Foundation의 메트로 재해에서 애플리케이션 및 스토리지를 복구하는 방법에 대한 지침.

초록

이 문서에서는 Red Hat OpenShift Data Foundation에서 발생한 재해를 복구하는 방법에 대해 설명합니다.
중요
Recovering a Metro-DR stretch cluster is a technology preview feature. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

머리말

Metro 재해 복구 확장 클러스터는 전체 또는 부분적인 사이트 중단시 복원력을 제공하는 것입니다. 따라서 애플리케이션 및 스토리지에 대한 다양한 복구 방법을 이해하는 것이 중요합니다.

애플리케이션 설계 방법은 활성 영역에서 다시 사용 가능하게 되는 시간을 결정합니다.

애플리케이션 및 해당 스토리지의 복구 방법은 사이트 중단에 따라 다릅니다. 복구 시간은 애플리케이션 아키텍처에 따라 다릅니다. 다양한 복구 방법은 다음과 같습니다.

1장. 영역 장애 이해

이 섹션의 목적상 영역 장애는 영역 장애(예: 전원이 꺼진 노드)의 모든 OpenShift Container Platform, 마스터 및 작업자 노드가 더 이상 두 번째 데이터 영역의 리소스와 통신하지 않는 실패로 간주됩니다. 데이터 영역 간의 통신이 여전히 부분적으로 작동하거나 축소된 경우 클러스터, 스토리지 및 네트워크 관리자 간 통신 경로가 데이터 영역 간의 연결이 끊어져 복구에 성공해야 합니다.

2장. RWX 스토리지를 사용하여 영역 인식 HA 애플리케이션 복구

topologyKey: topology.kubernetes.io/zone 을 사용하여 배포된 애플리케이션은 각 데이터 영역에서 스케줄링된 복제본이 하나 이상 있고 공유 스토리지를 사용하며, RWX(ReadWriteMany) CephFS 볼륨을 사용하는 경우 새 연결을 위해 30-60초 이내에 활성 영역에서 복구됩니다. 실패한 데이터 영역에서 라우터 Pod가 오프라인인 경우 HAProxy 가 연결을 새로 고치는 짧은 일시 중지입니다.

이러한 유형의 애플리케이션 예는 Install Zone Aware Sample Application 섹션에 설명되어 있습니다.

중요

샘플 애플리케이션을 설치할 때 파일 업로드자 애플리케이션을 사용할 수 있는지 확인하고 새 파일을 업로드할 수 있도록 OpenShift Container Platform 노드 (OpenShift Data Foundation 장치가 있는 노드)의 전원을 끄면 데이터 영역의 실패를 테스트하고 새 파일을 업로드할 수 있습니다.

3장. RWX 스토리지를 사용하여 HA 애플리케이션 복구

topologyKey: kubernetes.io/hostname 또는 토폴로지 구성이 없는 애플리케이션은 동일한 영역에 있는 모든 애플리케이션 복제본을 보호하지 않습니다.

참고

이는 Pod 사양의 podAntiAffinitytopologyKey: kubernetes.io/hostname 에서도 발생할 수 있습니다. 이 유사성 방지 규칙은 영역 기반이 아닌 호스트 기반이기 때문입니다.

이러한 상황이 발생하고 모든 복제본이 실패한 영역에 있는 경우 RWX(ReadWriteMany) 스토리지를 사용하는 애플리케이션은 활성 영역에서 복구하는 데 6-8 분이 걸립니다. 이러한 일시 중지는 실패한 영역의 OpenShift Container Platform 노드가 NotReady (60초)가 된 다음 기본 Pod 제거 제한 시간이 만료(300초)될 때 사용됩니다.

4장. RWO 스토리지를 사용하여 애플리케이션 복구

ReadWriteOnce(RWO) 스토리지를 사용하는 애플리케이션에는 이 Kubernetes 문제에 설명된 알려진 동작이 있습니다. 이 문제로 인해 데이터 영역 오류가 발생하는 경우 해당 영역의 모든 애플리케이션 Pod(예: RWO 볼륨 마운트)는 6-8분 후에 Terminating 상태로 유지되며 수동 조작 없이 활성 영역에서 다시 생성되지 않습니다.

상태가 NotReady 인 OpenShift Container Platform 노드를 확인합니다. 노드가 OpenShift 컨트롤 플레인과 통신하지 못하도록 하는 문제가 있을 수 있습니다. 그러나 노드는 영구 볼륨(PV)에 대해 계속 I/O 작업을 수행할 수 있습니다.

두 Pod가 동일한 RWO 볼륨에 동시에 쓰는 경우 데이터 손상 위험이 있습니다. NotReady 노드의 프로세스가 종료될 때까지 종료되거나 차단되었는지 확인합니다.

솔루션 예:

  • 프로세스 종료를 보장하기 위해 확인을 통해 노드의 전원을 끄려면 대역 외 관리 시스템을 사용하십시오.
  • 스토리지와 통신할 수 없는 사이트의 노드에서 사용하는 네트워크 경로를 인출합니다.

    참고

    실패한 영역 또는 노드로 서비스를 복원하기 전에 PV가 있는 모든 Pod가 성공적으로 종료되었는지 확인합니다.

Terminating Pod가 활성 영역에서 재생성되도록 하려면 Pod를 강제로 삭제하거나 관련 PV에서 종료자를 삭제할 수 있습니다. 이러한 두 작업 중 하나가 완료되면 애플리케이션 포드는 활성 영역에서 다시 생성하고 RWO 스토리지를 성공적으로 마운트해야 합니다.

Pod를 강제 삭제합니다.

강제 삭제는 Pod가 종료된 kubelet의 확인을 기다리지 않습니다.

$ oc delete pod <PODNAME> --grace-period=0 --force --namespace <NAMESPACE>
<PODNAME>
Pod 이름입니다.
<NAMESPACE>
프로젝트 네임스페이스입니다.
연결된 PV에서 종료자 삭제

Terminating Pod에서 마운트하는 PVC(영구 볼륨 클레임)의 관련 PV를 찾고 oc patch 명령을 사용하여 종료자를 삭제합니다.

$ oc patch -n openshift-storage pv/<PV_NAME> -p '{"metadata":{"finalizers":[]}}' --type=merge
<PV_NAME>

PV의 이름입니다.

관련 PV를 쉽게 찾을 수 있는 방법은 Terminating pod를 설명하는 것입니다. 다중 연결 경고가 표시되면 경고에 PV 이름이 있어야 합니다(예: pvc-0595a8d2-683f-443b-aee0-6e547f5f5a7c).

$ oc describe pod <PODNAME> --namespace <NAMESPACE>
<PODNAME>
Pod 이름입니다.
<NAMESPACE>

프로젝트 네임스페이스입니다.

출력 예:

[...]
Events:
  Type     Reason                  Age   From                     Message
  ----     ------                  ----  ----                     -------
  Normal   Scheduled               4m5s  default-scheduler        Successfully assigned openshift-storage/noobaa-db-pg-0 to perf1-mz8bt-worker-d2hdm
  Warning  FailedAttachVolume      4m5s  attachdetach-controller  Multi-Attach error for volume "pvc-0595a8d2-683f-443b-aee0-6e547f5f5a7c" Volume is already exclusively attached to one node and can't be attached to another

5장. StatefulSet Pod 복구

StatefulSet의 일부인 Pod는 Pod mount ReadWriteOnce (RWO) 볼륨과 비슷한 문제가 있습니다. Kubernetes 리소스 StatefulSet 고려 사항 에서 자세한 내용을 참조합니다.

6-8분 후에 활성 영역에서 Pod를 다시 생성하려면 동일한 요구 사항(즉, OpenShift Container Platform 노드의 전원이 꺼지거나 통신 연결이 끊긴)을 RWO 볼륨이 있는 Pod를 강제로 삭제해야 합니다.