Red Hat Blog를 보다가 관심 가는 글이 보여서 AI번역+약간 교정해 보았습니다.
출처: https://www.redhat.com/en/blog/disaster-recovery-approaches-red-hat-openshift-virtualization
소개
Red Hat OpenShift 기반 가상 머신 (VM)에 대한 재해 복구(DR) 전략은 예상치 못한 운영 중단 발생 시 비즈니스 연속성을 유지하는 데 필수적입니다. 조직이 중요 워크로드를 쿠버네티스 플랫폼으로 마이그레이션함에 따라, 이러한 워크로드를 빠르고 안정적으로 복구하는 능력은 핵심 운영 요건이 되고 있습니다.
클라우드 네이티브 환경에서는 임시 상태 비저장 VM이 보편화되었지만, 대부분의 엔터프라이즈 VM 워크로드는 상태 저장(stateful) 상태를 유지합니다. 이러한 VM은 재시작 또는 마이그레이션 중에 다시 연결할 수 있는 영구 블록 스토리지를 필요로 합니다. 결과적으로 상태 저장 VM에 대한 재해 복구(DR)는 일반적으로 상태 비저장 컨테이너 기반 애플리케이션에 초점을 맞춘 이전의 쿠버네티스 재해 복구 패턴 (Spazzoli, 2024)이 해결했던 문제와는 상당히 다른 과제를 안고 있습니다.
이 블로그 게시물은 상태 저장 VM의 고유한 요구 사항을 다룹니다. 먼저 클러스터 및 스토리지 아키텍처 선택이 장애 조치 실행 가능성, 복제 동작 및 RPO/RTO 목표에 미치는 영향을 살펴봅니다. 그런 다음 오케스트레이션 계층을 살펴보고 Red Hat Advanced Cluster Management , Helm , Kustomize 및 GitOps 파이프라인과 같은 쿠버네티스 네이티브 툴이 워크로드 배치 및 복구를 어떻게 제어하는지 보여줍니다. 마지막으로, 블록 스토리지와 쿠버네티스 매니페스트를 모두 복제하는 고급 스토리지 플랫폼이 복구 프로세스를 간소화하고 인프라와 애플리케이션 수준 자동화를 연결하는 방법을 살펴보며 마무리합니다.
용어의 수준 설정
너무 멀리 가기 전에 몇 가지 중요한 용어를 정의해 보겠습니다.
재해(Disaster):
이 논의의 맥락에서 “재해”라는 용어는 “사이트 손실”을 의미합니다. 재해 복구(DR)를 생각할 때, 항상 비즈니스 서비스 중단을 최소화하는 것이 중요합니다. 따라서 사이트 손실이 발생하면 대체 사이트에서 가능한 한 빠르고 효율적으로 서비스를 복구하기 위한 재해 복구 계획을 구현해야 합니다.
참고: 재해 복구 계획 수립은 사이트 장애 발생 시에만 수행되는 것이 아닙니다. 주요 구성 요소에 장애가 발생하여 해당 구성 요소가 복구되는 동안 개별 비즈니스 서비스를 대체 사이트로 이전해야 하는 경우, 개별 비즈니스 서비스에 대한 재해 복구 계획을 수립하는 것이 일반적입니다.
구성 요소 오류:
구성 요소 장애는 조직 내 비즈니스 애플리케이션의 하위 집합에 영향을 미치는 하나 이상의 하위 시스템 장애입니다. 이러한 장애 모드에서는 기본 사이트의 대체 시스템으로 처리를 장애 조치하거나, 비즈니스 애플리케이션 처리를 보조 사이트로 전환하기 위한 개별 재해 복구 계획을 수립해야 할 수 있습니다.
복구 지점 목표(RPO):
RPO는 재해나 장애 발생 후 복구 후 조직에서 허용하는 수준을 초과하기 전까지 손실될 수 있는 최대 데이터 양(시간 기준)으로 정의됩니다.
복구 시간 목표(RTO):
RTO는 조직이 서비스 가용성을 허용할 수 있는 최대 시간으로 정의됩니다. 다양한 아키텍처 선택이 RTO에 영향을 미치지만, 이 블로그 게시물에서는 이러한 고려 사항에 대해 자세히 다루지 않습니다.
Metro-DR 대 Regional-DR:
DR에는 메트로 DR과 지역 DR의 두 가지 유형이 있습니다.
- Metro-DR은 데이터 센터가 충분히 가깝고 네트워크 성능이 동기식 데이터 복제를 허용하는 상황에 적합합니다. 동기식 복제는 RPO(복구 목표 시점)를 0으로 설정할 수 있다는 이점이 있습니다.
- 지역 DR은 데이터 센터가 동기 복제를 지원하기에는 너무 멀리 떨어져 있어 비동기 복제를 사용해야 하는 상황을 위한 것입니다. 비동기 복제는 거의 확실히 일부 데이터 손실을 발생시키므로, 이 블로그 게시물의 목적상 데이터 손실량은 중요하지 않습니다.
참고: 스토리지 인프라가 동기 복제를 지원하지 않는 경우, 지역 DR 아키텍처를 Metro DR에 사용합니다.
재시작 스톰:
재시작 스톰은 동시에 재시작하려는 VM 수가 너무 많아 하이퍼바이저와 지원 인프라가 감당할 수 없을 때 발생하는 이벤트입니다. 이로 인해 VM을 재시작할 수 없게 되거나, VM 재시작 시간이 허용 가능한 수준을 훨씬 초과하여 지연되는 현상이 발생합니다. 이는 비악의적인 서비스 거부 공격이라고도 할 수 있습니다.
비즈니스 연속성에 대한 아키텍처 접근 방식
비즈니스 연속성과 재해 복구(DR)를 달성하는 데는 여러 가지 접근 방식이 있습니다. 이 주제에 대한 일반적인 논의를 위해서는 먼저 클라우드 네이티브 컴퓨팅 재단(CNCF)의 클라우드 네이티브 재해 복구(Cloud Native Disaster Recovery for Stateful Workloads, Spazzoli, 2024) 백서를 검토해 보십시오. 다음 다이어그램은 재해 복구에 대한 네 가지 전형적인 접근 방식을 개략적으로 보여줍니다(각 접근 방식에 대한 자세한 설명은 백서에 포함되어 있습니다).
VM에 대한 DR 요구 사항을 고려할 때 백업 및 복원과 볼륨 복제가 유일하게 적합한 DR 패턴입니다.
백업 및 복원과 볼륨 복제 모두 효과적인 접근 방식이지만, 볼륨 복제 기반 재해 복구(DR) 방식은 RPO와 RTO를 모두 최소화합니다. 따라서 본 문서에서는 볼륨 복제 기반 재해 복구(DR) 방식에만 집중하겠습니다.
분석 범위를 좁힌 후 볼륨 복제 유형에 따라 아키텍처적으로 구별되는 DR에 대한 두 가지 아키텍처 접근 방식을 논의해 보겠습니다.
- 단방향 복제
- 대칭 복제 또는 양방향 복제
단방향 복제
단방향 복제를 사용하면 볼륨이 한 데이터 센터에서 다른 데이터 센터로 복제되지만, 그 반대로는 복제되지 않습니다. 복제 방향은 스토리지 어레이를 통해 제어되며, 볼륨 복제는 동기식 또는 비동기식으로 진행될 수 있습니다. 선택은 스토리지 어레이 성능과 두 데이터 센터 간의 지연 시간에 따라 달라집니다. 비동기 복제는 서로 간의 지연 시간이 길고, 지리적으로 동일한 지역에 위치할 가능성이 높지만, 동일한 대도시권에 위치하지 않는 데이터 센터에 적합합니다.
아키텍처 측면에서 단방향 복제는 다음 그림과 유사하게 표현됩니다.
그림 2에서 볼 수 있듯이 VM(일반적으로 SAN 어레이)에서 사용되는 저장소는 단방향 복제를 허용하도록 구성됩니다.
각 데이터센터에는 두 개의 서로 다른 OpenShift 클러스터가 존재하며, 각 클러스터는 로컬 스토리지 어레이에 연결됩니다. 클러스터는 서로를 인식하지 못하므로, 이 아키텍처를 구현하는 데 필요한 유일한 제약 조건은 스토리지 공급업체가 제시하는 사항, 특히 단방향 복제를 위해 충족해야 하는 요구 사항입니다.
단방향 볼륨 복제 고려 사항
볼륨 복제는 쿠버네티스 CSI 사양에 표준화되어 있지 않습니다. 따라서 스토리지 공급업체들은 이 기능을 지원하기 위해 자체적인 custom resource definitions (CRD)를 구축했습니다. 전반적으로 이 기능을 제공하는 공급업체들은 세 가지 성숙도 단계에 있습니다.
- 볼륨 복제 기능은 CSI 수준에서 사용할 수 없거나 스토리지 어레이 API를 직접 호출하지 않고는 적절한 DR 오케스트레이션을 생성할 수 없는 방식으로 사용할 수 있습니다.
- 볼륨 복제 기능은 CSI 수준에서 사용 가능합니다.
- 볼륨 복제 기능을 사용할 수 있으며 공급업체는 네임스페이스 메타데이터(즉, 네임스페이스에 있는 VM 및 기타 매니페스트) 복원도 관리합니다.
이러한 단편화를 고려할 때, 지역별 재해 복구 설정에 맞춰 공급업체에 구애받지 않는 재해 복구 프로세스를 작성하는 것은 쉽지 않습니다. 적절한 재해 복구 오케스트레이션을 구축하기 위해 작성해야 하는 데이터의 양은 스토리지 공급업체에 따라 다릅니다.
다양한 장애 모드(OpenShift 노드 장애, 스토리지 어레이 장애(구성 요소 장애) 및 전체 데이터 센터 장애(이것이 실제 DR 시나리오))에서 이 아키텍처의 동작을 살펴보겠습니다.
OpenShift 노드 장애
노드(구성 요소) 장애 발생 시 OpenShift Virtualization 스케줄러는 클러스터에서 다음으로 적합한 노드에서 VM을 자동으로 다시 시작합니다. 이 경우 추가 조치는 필요하지 않습니다.
스토리지 어레이 오류
스토리지 어레이에 장애가 발생하면 해당 스토리지 어레이에 의존하는 모든 VM에도 장애가 발생합니다. 이 경우 DR(재해 복구) 프로세스를 실행해야 합니다. (관련 단계는 “재해 복구 프로세스” 섹션을 참조하십시오.)
데이터 센터 장애
데이터 센터 장애 발생 시, 장애의 영향을 받지 않는 데이터 센터의 모든 VM을 재시작하기 위해 재해 복구(DR) 프로세스를 실행해야 합니다. 여기서 자동화가 핵심적인 역할을 합니다. 그러나 이 프로세스는 일반적으로 중대 사고 관리 프레임워크 내에서 사람이 시작합니다. 다음 섹션에서는 관련 단계에 대한 개요를 제공합니다.
재해 복구 프로세스
DR 절차는 매우 복잡해질 수 있지만 간단히 말해서 DR 프로세스는 다음 사항을 고려해야 합니다.
- 동일한 애플리케이션에 속하는 VM은 볼륨이 일관된 방식으로 복제되어야 합니다. 이는 일반적으로 해당 VM의 볼륨이 동일한 일관성 그룹에 속함을 의미합니다.
- 일관성 그룹의 볼륨을 복제할지 여부와 복제 방향을 제어할 수 있어야 합니다. 일반적인 상황에서는 볼륨이 액티브 사이트에서 패시브 사이트로 복제됩니다. 장애 조치(failover) 중에는 볼륨이 복제되지 않습니다. 장애 복구(failback) 준비 단계에서는 볼륨이 패시브 사이트에서 액티브 사이트로 복제됩니다. 장애 복구(failback) 중에는 볼륨이 복제되지 않습니다.
- 다른 데이터 센터의 VM을 다시 시작할 수 있어야 하며 복제된 스토리지 볼륨에 연결할 수 있어야 합니다.
- 재시작 스톰을 방지하기 위해 VM 재시작을 제한해야 할 수도 있습니다. 또한, 가장 중요한 애플리케이션이 먼저 시작되도록 VM 재시작 순서의 우선순위를 지정하거나, 데이터베이스와 같은 종속 구성 요소가 해당 구성 요소에 의존하는 서비스보다 먼저 시작되도록 하는 것이 좋습니다.
비용 고려 사항
OpenShift 클러스터 구성 방식에 따라 웜 또는 핫 DR 사이트로 간주될 수 있습니다. 핫 사이트는 완전히 구독해야 하지만, 웜 사이트는 구독하지 않아도 되므로 비용 절감 효과가 있을 수 있습니다.
일반적으로 DR 사이트에서 실행 중인 활성 워크로드가 없으면 웜 사이트로 간주될 수 있습니다. 특히, persistent volumes (PVs), persistent-volume claims (PVCs), 심지어 실행 중이 아닌 VM까지 구성하여 재해 발생 시 즉시 시작될 수 있도록 준비하면서도 웜 사이트 지정을 유지할 수 있습니다.
대칭형 능동/수동
활성 사이트에 워크로드를 100% 배치하는 것은 일반적인 관행이 아닙니다. 대신, 조직에서는 주 데이터 센터와 보조 데이터 센터에 최대 50:50으로 워크로드를 분배합니다. 이는 어떤 재해 발생 시에도 모든 서비스가 한꺼번에 중단되는 것을 방지하는 실용적인 방법입니다. 또한, 전반적인 복구 작업도 그에 따라 줄어듭니다.
각 데이터 센터에 활성 VM을 배포할 때, 각 데이터 센터는 다른 데이터 센터로 장애 조치(failover)가 가능하도록 구성됩니다. 이러한 설정을 대칭형 활성/수동이라고도 합니다.
대칭형 액티브/패시브는 OpenShift Virtualization 및 위에서 살펴본 아키텍처와 함께 작동합니다. 대칭형 액티브/패시브에서는 두 데이터센터 모두 액티브로 간주되므로 모든 OpenShift 노드를 구독해야 한다는 점에 유의하세요.
대칭 복제
대칭 복제를 사용하면 볼륨이 동기식으로 양방향으로 복제됩니다. 따라서 두 데이터 센터 모두 활성 볼륨을 가질 수 있으며 해당 볼륨에 쓰기 작업을 수행할 수 있습니다. 이를 위해서는 조직에 네트워크 지연 시간이 매우 짧은(예: ~<5ms) 두 개의 데이터 센터가 있어야 합니다. 이는 일반적으로 두 데이터 센터가 동일한 대도시 지역에 있는 경우 가능하며, 따라서 이 아키텍처를 Metro-DR 이라고도 합니다 . 이러한 상황에서는 다음 아키텍처를 사용할 수 있습니다.
이 아키텍처에서는 VM이 사용하는 스토리지(일반적으로 SAN 어레이)가 두 데이터 센터 간에 대칭 복제를 수행하도록 구성됩니다.
이렇게 하면 두 데이터 센터에 걸쳐 확장된 논리적 스토리지 어레이가 생성됩니다. 대칭 복제를 구현하려면 네트워크 또는 사이트 장애 발생 시 “스플릿 브레인” 시나리오를 방지하기 위해 독립적인 중재자 역할을 하는 “증인 사이트”가 필요합니다.
위트니스 사이트는 쿼럼 생성 및 스플릿 브레인 시나리오의 동점 해소에 사용되므로 두 개의 주요 데이터센터처럼 지연 시간 측면에서 서로 가까이 있을 필요는 없습니다. 위트니스 사이트는 독립적인 가용 영역이어야 하며, 애플리케이션 워크로드를 처리하지 않고 대용량일 필요는 없지만, 데이터센터 운영(예: 물리적/논리적 보안, 전원 관리, 냉각) 측면에서 다른 데이터센터와 동일한 서비스 품질을 제공해야 합니다.
스토리지가 여러 데이터센터에 분산됨에 따라 OpenShift도 그 위에 확장됩니다. 고가용성 아키텍처에서 이를 구현하려면 OpenShift 제어 평면에 세 개의 가용성 영역(사이트)이 필요합니다. 이는 쿠버네티스의 내부 etcd 데이터베이스가 안정적인 쿼럼을 유지하기 위해 최소 세 개의 장애 도메인을 필요로 하기 때문입니다. 이는 일반적으로 제어 평면 노드 중 하나에 대한 스토리지 감시 사이트를 활용하여 구현됩니다.
대부분의 SAN(Storage Area Network) 공급업체는 자사 스토리지 어레이에 대해 대칭 복제를 지원합니다. 그러나 모든 공급업체가 CSI 수준에서 이 기능을 제공하는 것은 아닙니다. 스토리지 공급업체가 CSI 수준에서 대칭 복제를 지원하고 필요한 전제 조건과 구성이 충족되었다고 가정할 때, PVC가 생성될 때 다중 경로 논리 단위 번호(LUN)가 프로비저닝됩니다. 이 LUN에는 두 데이터센터로 연결되는 경로가 포함되므로 모든 OpenShift 노드는 두 스토리지 어레이 모두에 연결할 수 있도록 구성해야 합니다. 다중 경로 장치는 일반적으로 asymmetric logical unit access(ALUA) 구성(Pearson IT Certification, 2024)(즉, 활성/수동, 활성 경로는 가장 가까운 어레이로 가는 경로) 또는 서로 다른 가중치를 가진 활성/활성 경로(가장 가까운 어레이의 가중치가 높음)로 생성됩니다.
일부 공급업체는 파이버 채널 연결이 “균일하지” 않은 경우에도 이 아키텍처를 허용합니다. 즉, 한 사이트의 노드가 로컬 스토리지 어레이에만 연결할 수 있는 경우입니다. 이 경우에는 ALUA 구성이 생성되지 않습니다.
이 클러스터 토폴로지는 구성 요소 장애와 재해로부터 시스템을 보호하는 데 도움이 됩니다. 다양한 장애 모드에서 이 아키텍처의 동작을 살펴보겠습니다.
OpenShift 노드 장애
노드(구성 요소) 장애 발생 시 OpenShift Virtualization 스케줄러는 클러스터에서 다음으로 적합한 노드에서 VM을 자동으로 다시 시작합니다. 이 경우 추가 조치는 필요하지 않습니다.
스토리지 어레이 오류
다중 경로 LUN은 두 스토리지 어레이 중 하나에 장애가 발생하거나 유지 관리를 위해 오프라인 상태가 되는 경우에도 서비스 연속성을 제공합니다. 균일 연결 시나리오에서는 다중 경로 LUN의 수동 경로 또는 가중치가 낮은 경로를 사용하여 VM을 다른 어레이에 연결합니다. 이러한 장애는 VM에 전혀 영향을 미치지 않으므로 디스크 I/O 지연 시간이 약간 증가할 수 있습니다. 균일하지 않은 연결 시나리오에서는 VM을 연결이 가능한 노드로 마이그레이션해야 합니다.
데이터 센터 장애
전체 데이터 센터를 사용할 수 없게 되면 확장된 OpenShift는 이를 여러 노드가 동시에 장애가 발생한 것으로 인식합니다. OpenShift는 OpenShift 노드 장애 섹션에 설명된 대로 다른 데이터 센터 내 노드에 VM을 예약하기 시작합니다.
워크로드를 마이그레이션할 여유 용량이 충분하다고 가정하면 모든 머신은 결국 다른 데이터 센터에서 재시작됩니다. 재시작된 VM의 RPO는 정확히 0이며, RTO는 다음 시간의 합으로 계산됩니다.
- OpenShift가 노드가 준비되지 않은 상태임을 인식하는 데 걸리는 시간
- 노드를 펜싱하는 데 걸리는 시간
- VM을 다시 시작하는 데 걸리는 시간
- VM 부팅 프로세스를 완료하는 데 걸리는 시간
이 DR 메커니즘은 본질적으로 완전히 자율적이며 사람의 개입이 필요하지 않습니다. 하지만 이것이 항상 바람직한 것은 아닙니다. 재시작 폭풍을 방지하려면 어떤 VM을 재시작하고 언제 재시작할지 제어하는 것이 바람직한 경우가 많습니다.
Metro-DR 고려 사항
이 접근 방식과 관련하여 고려해야 할 사항은 다음과 같습니다.
- VM은 일반적으로 VLAN에 연결되므로 데이터 센터 간에 자유롭게 이동할 수 있으려면 VLAN을 메트로 데이터 센터 간에도 확장해야 합니다. 경우에 따라 이는 바람직하지 않을 수 있습니다.
- 종종, 증인 사이트 관리 네트워크(OpenShift 노드 네트워크)는 메트로 데이터 센터의 관리 네트워크와 동일한 L2 서브넷에 있지 않습니다.
- 일부 학계에서는 OpenShift 제어 평면과 스토리지 어레이 제어 평면이 두 개의 single points of failure(SPOF)이기 때문에 이를 완전한 재해 복구 솔루션으로 간주하지 않습니다. 이 SPOF는 논리적인 관점에서 의도된 것으로, 물리적 관점에서는 물론 중복성이 존재합니다. 그러나 OpenShift 또는 스토리지 어레이에 대한 단 하나의 잘못된 명령만으로도 이론상 전체 환경이 파괴될 수 있다는 것은 사실입니다. 이러한 이유로 이 아키텍처는 가장 중요한 워크로드의 경우 보다 전통적인 지역 재해 복구 아키텍처에 데이지 체인 방식으로 연결되는 경우가 있습니다.
- 재해 복구 상황에서 OpenShift는 재해의 영향을 받은 데이터 센터의 모든 VM을 동시에 정상 데이터 센터로 자동 재예약합니다. 이로 인해 재시작 스톰(restart storm)이라는 현상이 발생할 수 있습니다. Kubernetes에는 어떤 애플리케이션이 언제 장애 조치(failover)될지 제어하여 이러한 위험을 완화하는 여러 기능이 있습니다. 재시작 스톰의 개념은 이후 섹션에서 설명합니다.
비용 고려 사항
대칭형 복제의 경우, 두 사이트 모두 단일 활성 OpenShift 클러스터에 속하므로 완전히 구독되어야 합니다. 단방향 복제의 경우, 각 사이트는 100% 오버프로비저닝되어야 하며, 다른 사이트의 100% 장애 조치를 허용해야 합니다.
결론
단방향 복제 아키텍처와 대칭 복제 아키텍처 간의 결정은 OpenShift 가상화에 대한 전체 DR 전략의 토대를 마련합니다. 각 모델은 운영 복잡성, 인프라 비용, RPO/RTO 보장 및 자동화 가능성 간의 상충 관계를 갖습니다. 이중 클러스터 설계 또는 확장 클러스터 설계 중 어떤 것을 선택하든, 기본 아키텍처는 비즈니스 연속성 기대치와 인프라 제약 조건을 충족해야 합니다. 이러한 기반을 바탕으로, 2부 에서는 인프라에서 오케스트레이션으로 초점을 옮겨 스토리지를 넘어 재해 상황에서 VM이 어떻게 배치, 재시작 및 제어되는지 살펴봅니다.
