Red Hat Blog를 보다가 관심 가는 글이 보여서 AI번역+약간 교정해 보았습니다.
출처: https://developers.redhat.com/articles/2025/08/11/disaster-recovery-approaches-red-hat-openshift-virtualization-part-2
Red Hat OpenShift Virtualization을 위한 재해 복구 접근 방식 에서는 클러스터 토폴로지, 스토리지 아키텍처, 복제 전략이 서비스 가용성을 어떻게 뒷받침하는지 살펴보며 재해 복구의 기반을 마련했습니다. 이 후속 게시물에서는 다음 단계로, Kubernetes 네이티브 구조와 GitOps 워크플로를 사용하여 애플리케이션 페일오버를 조율합니다. 여기서 재해 복구(DR)는 데이터의 위치보다는 중단 발생 시 워크로드를 재배포하고, 우선순위를 지정하고, 검증하는 방식에 더 중점을 둡니다. 이를 통해 운영 계층에 선언적 제어, 자동화 및 감사 기능을 제공합니다.
Kubernetes 및 GitOps를 사용하여 가상 머신 장애 조치 조정
단방향 및 대칭 볼륨 복제 패턴(관련 클러스터 토폴로지 포함)이 데이터를 보호하는 방식을 이전에 파악했으므로, 이제 기반 인프라에서 워크로드 자체로 초점을 전환할 수 있습니다. 지금까지 논의한 아키텍처 기반은 가상 머신(VM) 디스크의 가용성을 보장하지만, 개별 VM의 실행 위치, 재시작 순서, 또는 위기 상황에서 운영자가 이러한 작업을 어떻게 조정해야 하는지에 대해서는 거의 언급하지 않습니다.
이러한 간극을 메우려면 재해 복구에 대한 애플리케이션 중심적인 관점이 필요합니다. 즉, 장애 조치를 쿠버네티스 기능과 고수준 자동화를 통해 관리되는 통제된 배치 활동으로 간주해야 합니다. 다음 섹션에서는 스토리지 복제에서 애플리케이션 장애 조치로 관점을 전환하여, Node Selectors, tolerations, Red Hat Advanced Cluster Management 배치 규칙이 Ansible , Helm , Kustomize 와 같은 도구와 함께 어떻게 작동하여 사람의 감독을 유지하면서 적시에 적절한 사이트로 워크로드를 전달하는지 살펴봅니다.
재해 복구 프로세스에 대한 일반적인 요구 사항은 다음과 같습니다.
- DR 전략은 전체 DR 오케스트레이션, 장애 조치, 장애 복구 및 기타 모든 중간 상태를 고려해야 합니다.
- 개별 애플리케이션뿐만 아니라 애플리케이션 그룹(일반적으로 애플리케이션 계층이라고 함)에 대해서도 DR 프로세스를 시작할 수 있어야 합니다.
- DR 프로세스가 실제로 작동하는지 확인하기 위해 정기적으로 DR 연습이나 리허설을 수행하는 것이 가능해야 합니다.
이전에 설명한 두 가지 아키텍처 접근 방식 내에서 DR 관련 활동을 조율하는 방법을 분석해 보겠습니다.
듀얼 클러스터 토폴로지의 재해 복구 프로세스
단방향 볼륨 복제 패턴에 해당하는 듀얼 클러스터 토폴로지에서 DR 수명 주기는 그림 1에 나와 있습니다.
이 다이어그램에서는 다음 단계가 설명되어 있습니다.
- 정상 상태에서는 VM이 기본 사이트에서 실행되고 볼륨은 보조 사이트에 복제됩니다.
- 장애 조치(failover) 상태에서는 VM의 PV와 PVC가 DR 사이트에 생성되거나 이미 존재하며, VM은 DR 사이트에서 올바른 볼륨에 연결되어 시작됩니다. 볼륨이 복제 중이었으므로 즉시 사용할 수 있습니다.
- 장애가 발생한 사이트가 복구되면 DR 사이트의 볼륨이 기본 사이트로 다시 복제되도록 설정됩니다. 이 상태는 정상 상태와 유사합니다.
- 정상 상태로 돌아가려면 장애 복구가 발생해야 합니다. 장애 복구 상태에서는 DR 사이트에서 기본 사이트로의 복제가 중단되고 VM이 시작되어 기본 사이트의 볼륨에 연결됩니다.
앞서 설명했듯이, 많은 엔터프라이즈 스토리지 플랫폼은 멀티클러스터 애플리케이션 장애 조치의 복잡성을 줄이기 위해 점점 더 높은 수준의 성숙도를 제공합니다. 성숙도 수준에 따라 해당 재해 복구 프로세스를 구축하기 위해 필요한 작업을 분석해 보겠습니다.
- CSI 드라이버는 VolumeReplication을 지원하지 않습니다. DR 자동화는 볼륨 상태를 관리하기 위해 스토리지 어레이 API와 통신해야 하며, PV, PVC, VM을 관리하기 위해 OpenShift API와 통신해야 합니다.
- CSI에서 지원하는 VolumeReplication: 일반적으로 이러한 공급업체는 패시브 사이트에서 PV 및 PVC 생성을 간소화하는 방법을 제공합니다. 따라서 PVC/PV는 SAN 볼륨에 연결될 때까지 대기하며 수정 없이 이름으로 참조할 수 있습니다. 이 기능은 VM을 대체 사이트로 마이그레이션하는 과정을 크게 간소화합니다. 하지만 VM 자체를 관리하는 것은 여전히 OpenShift 관리자의 책임입니다.
- 스토리지 공급업체가 지원하는 VolumeReplication 및 네임스페이스 메타데이터: 일부 스토리지 플랫폼은 PVC 복제를 넘어 관련 Kubernetes 객체를 동기화하여 인프라 복제와 GitOps 스타일 애플리케이션 관리 간의 격차를 효과적으로 메웁니다. 이러한 플랫폼은 VirtualMachines, ConfigMaps, Secrets와 같은 사용자 지정 리소스를 포함한 애플리케이션 상태를 복구 사이트에서 자동으로 재구성합니다. 이러한 접근 방식은 DR 오케스트레이션의 책임을 스토리지 계층 자체로 이전하여 순수한 GitOps 기반 워크플로에 대한 대안을 제공하거나, 자동화 수준을 높이고 업스트림 자동화에 대한 의존도를 낮춰 워크플로를 개선합니다.
단일 클러스터 토폴로지의 재해 복구 프로세스
단일 클러스터 토폴로지에서 두 데이터 센터는 공통 쿠버네티스 제어 평면과 대칭형 복제 스토리지 패브릭을 공유합니다. 이 아키텍처는 클러스터 간 재배포가 아닌 클러스터 내 배치 방식으로 재해 복구를 지원합니다.
VM이 두 사이트 간에 자유롭게 이동할 수 있도록 설정할 수도 있습니다. 하지만 실제로는 그렇게 하면 고려해야 할 몇 가지 추가적인 복잡성이 발생합니다. 예를 들면 다음과 같습니다.
- VM은 한 사이트에만 존재하는 로컬 서비스나 데이터베이스에 종속될 수 있습니다.
- VM이 자유롭게 떠다니도록 허용하면 여러 노드를 동시에 사용할 수 없게 되면 재시작 스톰이 발생할 수 있습니다.
- 정상 상태에서 KubeVirt 스케줄러가 사이트 간에 VM을 자유롭게 라이브 마이그레이션하도록 허용하면(예: 클러스터를 업그레이드하기 위해 노드를 드레이닝하는 경우) VM의 메모리를 대체 사이트로 마이그레이션해야 하며, 기가바이트에서 테라바이트에 달하는 데이터가 사이트 간에 복사되면서 네트워크에 부담을 줄 수 있습니다.
VM이 실행될 사이트를 제어하는 것이 목표라고 가정하면, Kubernetes는 실제로 노드 레이블 및 선택기, 오염 및 허용, 친화성/반친화성 규칙, 토폴로지 확산 제약 조건과 같은 기본 기능을 통해 필요한 수단을 제공합니다.
이러한 네이티브 기본 요소에 기반한 장애 조치 전략은 쿠버네티스의 조정 루프를 활용하여 맞춤형 스크립트나 외부 오케스트레이터를 사용하지 않도록 합니다. 워크플로는 선언적, 멱등적, 버전 제어 방식을 유지하여 쿠버네티스 내에서 일상적인 워크로드 스케줄링을 처리하는 메커니즘과 동일한 방식으로 재해 복구 정책을 적용할 수 있습니다. 이러한 이점으로는 이동 부품 감소, 원활한 업그레이드, 내장된 관측 가능성, 그리고 복구 시간 단축 등이 있습니다.
장애 조치 프로세스를 제어하는 데 사용할 쿠버네티스 기능을 선택하는 것은 유연성보다 단순성을 중시하는 선택입니다. 노드 선택기는 이해하고 구현하기가 비교적 쉽습니다. 하지만 테인트(taint) 및 톨러레이션(toleration)과 같은 다른 기능들은 장애 조치 작업 관리에 있어 더욱 유연한 기능을 제공합니다. 편의상 이 논의는 노드 선택기에 국한하겠습니다.
노드 선택기를 사용하면 일관된 레이블(예: Primary 기본 사이트와 DR 보조 사이트)이 모든 작업자 노드에 적용됩니다. 예:
사이트 의 노드 레이블 Primary:
metadata:
label:
topology.kubernetes.io/site=Primary사이트 의 노드 레이블 DR:
metadata:
label:
topology.kubernetes.io/site=DRVM을 생성할 때 nodeSelector는 원하는 사이트의 워커 노드 레이블과 일치하는 값으로 정의됩니다. 예:
spec:
template:
spec:
nodeSelector:
topology.kubernetes.io/site: Primary그림 3에서 볼 수 있듯이 Kubernetes는 VM이 생성될 때 레이블이 일치하는 작업자 노드에서만 실행되도록 보장합니다.
재해 발생 시 기본 사이트의 모든 작업자 노드가 손실됩니다. KubeVirt 스케줄러가 일치하는 레이블을 가진 노드를 찾을 수 없기 때문에 VM을 예약할 수 없습니다. 하지만 멀티클러스터 토폴로지 패턴과 달리 VM은 클러스터에 이미 정의되어 있습니다. 즉, VM 템플릿에서 사용하는 노드 선택기 규칙 하나만 변경해도 장애 조치가 영향을 받습니다.
장애 조치를 트리거하려면 노드 선택기에 Primary에서 DR로 패치를 적용합니다.
spec:
template:
spec:
nodeSelector:
topology.kubernetes.io/site: DR또 다른 방법은 노드 선택기를 완전히 제거하여 제약 조건을 제거하는 것입니다. 하지만 노드 선택기를 제거하는 데 따르는 문제는 위에서 설명한 모든 이유로 인해 장애 복구에 대한 완전한 제어권을 잃게 된다는 것입니다.
그림 4에서 볼 수 있듯이, 쿠버네티스 스케줄러는 정상 사이트의 워커에 VM 포드를 다시 생성합니다. 스트레치드 스토리지는 디스크 재연결을 투명하게 처리합니다.
애플리케이션 장애 조치 설계 및 구현 간소화
애플리케이션 장애 조치에 대한 필수 프로세스를 설명한 후, 재해 복구를 설계, 구현, 실행하는 데 있어 GitOps를 우선시하는 접근 방식에 대한 몇 가지 모범 사례를 살펴보겠습니다.
재해 복구의 주요 목표는 서비스를 최대한 빠르고 안정적으로 복구하는 것입니다. 이를 염두에 두고 Kubernetes 기능과 Kubernetes 네이티브 툴을 최대한 활용하는 것이 좋습니다. 이를 통해 복잡한 오케스트레이션, 맞춤형 자동화 솔루션, 수동 프로세스의 필요성을 최소화할 수 있으며, 이러한 모든 작업은 비용, 복잡성, 운영 위험을 증가시킵니다.
다음의 네 가지 관행은 위의 철학과 일치합니다.
- 모든 DR 상태를 선언적으로 설명하세요.
- DR 오케스트레이션 상태의 각 단계를 서로 다른 단계(델타)로 설명하세요.
- 맞춤형 자동화보다 특수 목적의 GitOps 컨트롤러를 선호합니다.
- 항상 “브레이크 글래스(break glass)” 옵션을 준비해 두세요.
이에 대해 더 자세히 살펴보겠습니다.
모범 사례 1: BAU 및 DR 상태를 모두 선언적으로 설명
재해 복구 프로세스는 선언적일 때, 즉 수행 방식이 아닌 수행해야 할 작업 을 표현할 때 가장 복원력이 뛰어납니다 . 쿠버네티스 환경에서 이러한 선언적 접근 방식은 BAU(Business As Usual) 구성과 DR 구성이 모두 버전 관리 매니페스트로 저장되는 GitOps 방법론과 자연스럽게 부합합니다. 두 상태를 모두 선언적으로 설명함으로써 쿠버네티스가 일상적인 작업에 제공하는 것과 동일한 일관성, 감사 가능성 및 반복성을 장애 조치 전략에도 적용할 수 있습니다.
선언적 상태 설명은 GitOps 컨트롤러에서 적용할 수 있는 단일 진실 소스를 제공합니다. 이러한 컨트롤러는 수동 개입 없이 실제 클러스터 상태를 선언된 목표 상태(BAU 또는 DR)와 일치하도록 조정합니다. 인시던트 발생 시, 장애 조치는 알려진 정상 매니페스트를 제어된 방식으로 다시 적용하는 방식으로 진행됩니다. 또한, 하위 환경에서의 테스트 실행을 통해 DR 매니페스트를 검증할 수 있으므로 실제 장애 발생 전에 DR 구성을 시뮬레이션하거나 테스트하는 것이 더욱 용이해집니다.
실제로 이는 모든 사이트별 스케줄링 로직, 스토리지 연결, 네트워크 정책 및 DNS 재정의를 쿠버네티스 네이티브 YAML로 인코딩하는 것을 의미합니다. 그런 다음 이러한 정의를 버전 관리에 적용합니다. GitOps 컨트롤러는 변경 사항을 관찰하고 클러스터에 자동으로 적용하여 워크로드를 원하는 상태로 전환합니다. 이러한 접근 방식은 모호성을 제거하고, 스트레스가 많은 사고 상황에서 오류 발생 가능성을 줄이며, DR 리허설을 확실하고 정확하게 실행할 수 있도록 합니다.
모범 사례 2: DR 상태를 BAU 상태의 델타로 설명
BAU와 DR 상태를 모두 선언적으로 표현한 다음 단계는 DR 상태를 BAU 구성의 델타 (즉, 간결한 차이)로 설명하여 중복을 방지하는 것입니다. DR을 델타로 설명하는 주요 이점은 검증을 간소화한다는 것입니다. 검토자는 전체 배포 매니페스트를 검토할 필요가 없습니다. 대신, 장애 조치 중에 변경된 내용이 유효하고 완전하며 정확한지 확인하기만 하면 됩니다. 이러한 명확성은 인지적 부담을 줄이고, 구성 편차를 제한하며, 반복 가능한 리허설을 지원합니다. Git은 표준 레코드가 됩니다. 아무리 사소한 변경이라도 가시적이고, 되돌릴 수 있으며, 귀속될 수 있습니다.
Kustomize 및 Helm과 같은 쿠버네티스 네이티브 툴링은 이러한 델타 기반 접근 방식을 실용적이고 관용적으로 만듭니다. 예를 들어 Kustomize를 사용하면 표준 배포를 설명하는 공통 기본 디렉터리가 정의되며, Node Selector, 복제본 수 또는 주석과 같은 사이트별 세부 사항을 변경하기 위해 최소한의 범위 지정 패치를 적용하는 overlay/dr 디렉터리(예시)는 DR 사이트로의 배포를 지원하기 위해 필요한 변경 사항을 나타냅니다. Kustomize는 오버레이를 기본 디렉터리에 병합하여 전체 매니페스트를 생성함으로써 일관성을 보장하는 동시에 DR 관련 로직을 분리합니다.
Helm은 템플릿화된 매니페스트와 매개변수화된 values.yaml 파일을 통해 동일한 개념을 지원합니다. 공유된 Helm 차트는 BAU 및 DR 환경 모두에서 재사용할 수 있으며, 별도의 values-dr.yaml 파일을 통해 사소한 재정의가 적용됩니다. Kustomize와 마찬가지로 이 모델은 변경 사항을 엄격하게 제어하고 두 상태 간의 명확하고 감사 가능한 차이점을 제공합니다.
모범 사례 3: 맞춤형 자동화보다 특수 목적의 GitOps 컨트롤러를 선호
재해 복구를 구현할 때 쿠버네티스 네이티브 제어 플레인과 GitOps 워크플로를 활용하면 맞춤형 자동화를 구축하는 것보다 장기적인 안정성이 더욱 향상됩니다. Argo CD, Flux, Red Hat Advanced Cluster Management와 같은 특수 목적 컨트롤러는 애플리케이션 배치 및 정책 조정을 선언적이고 안전하며 대규모로 관리하도록 설계되었습니다. 이러한 컨트롤러는 내장된 드리프트 감지, 역할 기반 액세스 제어(RBAC) 통합, 관찰 지표, 그리고 여러 환경에서 일관된 동작을 통해 운영 복잡성을 줄여줍니다. 이러한 기능은 사용자 지정 스크립트에서 복제하기 어렵고 비용도 많이 듭니다.
컨트롤 플레인 선택은 클러스터 토폴로지에 따라 부분적으로 달라집니다. 멀티클러스터 토폴로지에서 컨트롤 플레인은 클러스터 간 재배포를 처리해야 합니다. 이는 일반적으로 GitOps 툴링과 배치 로직의 조합을 통해 이루어집니다. Argo CD와 같은 GitOps 컨트롤러는 공유 Git 저장소의 변경 사항을 관찰하고 복구 클러스터에 매니페스트를 적용합니다. Red Hat Advanced Cluster Management는 배치 객체를 관리하여 이러한 접근 방식을 보완합니다. 재해 발생 시 배치 규칙을 업데이트하면 선언적이고 관찰 가능하며 완벽하게 감사 가능한 방식으로 전체 워크로드가 기본 클러스터에서 재해 복구 클러스터로 이동합니다.
단일 클러스터 토폴로지에서 재해 복구는 동일한 제어 평면 내에서 워크로드를 리디렉션하는 작업입니다. 재해 복구는 클러스터 내 배치 작업이 됩니다. 컨트롤러는 클러스터 간 배포를 관리하는 대신 클러스터 내 스케줄링 로직을 업데이트하는 역할을 합니다.
GitOps 컨트롤러는 이러한 작업에 매우 적합하며, 원하는 스케줄링 로직을 지속적으로 조정하고 선언적 리소스를 통해 배치 규칙을 적용합니다. 실제로 이는 Git 저장소에서 사이트별 선택자, 테인트 또는 어피니티 규칙을 조정하는 것을 의미합니다. 컨트롤러는 업데이트를 관찰하고 패치를 적용하며 클러스터 전체에서 규정 준수 여부를 확인합니다. 이 모델은 Kubernetes의 핵심 강점인 멱등성, 관찰 가능성, 반복 가능성을 유지하면서도 맞춤형 스크립팅의 필요성을 제거합니다.
Red Hat Advanced Cluster Management와 같은 정책 기반 솔루션은 거버넌스 프레임워크를 통해 이 프로세스를 제어합니다. 거버넌스 프레임워크에서는 ConfigurationPolicy 리소스가 노드 선택기와 같은 사이트별 설정을 적용합니다. 정책에서 필드 하나만 변경해도 모든 VM을 재해 복구 사이트로 이전할 수 있습니다. Red Hat Advanced Cluster Management는 규정 준수 여부를 확인하고 어떤 워크로드가 성공적으로 이전되었는지에 대한 가시성을 제공합니다.
또한 일부 고급 스토리지 플랫폼은 Kubernetes 및 GitOps 워크플로와 기본적으로 통합되어 선언적으로 장애 조치를 트리거할 수 있는 API 또는 사용자 지정 리소스 정의(CRD)를 제공합니다. 이러한 플랫폼이 볼륨과 함께 애플리케이션 메타데이터도 복제하는 경우, 스토리지 인식과 정책 기반 자동화를 결합한 하이브리드 제어 플레인 역할을 수행할 수 있습니다.
이러한 기본 컨트롤러를 활용함으로써 조직은 실전 테스트를 거쳐 Kubernetes 생태계에 통합되고 독립적으로 보안 검토가 가능한 도구의 이점을 누릴 수 있습니다.
모범 사례 4: 항상 “브레이크 글래스” 옵션 확인
최고의 재해 복구 계획조차도 제어 영역 가용성 문제를 고려해야 합니다. 특히, 사이트 장애 발생 시 Git 저장소나 GitOps 컨트롤러에 접속하지 못할 수 있습니다. “break glass” 옵션을 사용하면 Git 기반 워크플로와의 호환성을 유지하면서 수동 도구를 사용하여 장애 조치를 시작할 수 있습니다.
GitOps 기반 시스템의 경우, 장애 조치 매니페스트를 로컬에서 렌더링하여 명령줄 도구를 통해 직접 적용하는 것이 일반적입니다. 이는 Git 저장소의 사본이 로컬에 저장됨을 의미합니다. 예를 들어 Kustomize를 사용하면 다음 명령을 사용하여 장애 조치 구성을 DR 사이트에 적용할 수 있습니다.
oc apply -k overlays/dr
마찬가지로 Helm을 사용하면 DR 관련 값 파일을 렌더링하고 적용할 수 있습니다.
helm template my-release ./chart -f values-dr.yaml | oc apply -f -
이러한 수동 명령은 GitOps 컨트롤러를 우회하지만 여전히 동일한 선언적 변경 사항을 적용하여 성능이 저하된 조건에서도 일관되고 예측 가능한 장애 조치를 가능하게 합니다.
이러한 관행을 채택하면 예상치 못한 상황을 관리 가능한 운영 단계로 전환하고 가장 어려운 상황에서도 재해 복구가 가능하도록 보장할 수 있습니다.
결론
Red Hat OpenShift에서 가상 머신에 대한 재해 복구는 하나의 기본적인 결정, 즉 클러스터 및 스토리지 아키텍처 선택에서 시작됩니다. 대칭 복제를 사용하는 확장 클러스터를 선택하든, 단방향 복제를 사용하는 이중 클러스터 설계를 선택하든, 이 아키텍처는 장애 조치 실행 방식에 대한 모든 다운스트림 결정을 형성합니다. 이 아키텍처는 실현 가능한 복구 지점 목표(RPO) 및 복구 시간 목표(RTO) 목표, 안전하게 적용할 수 있는 자동화, 그리고 플랫폼과 서비스 운영팀이 각각 얼마나 많은 운영 복잡성을 감당해야 하는지를 결정합니다.
이후 워크로드 배치 및 장애 조치 로직을 선언적으로 정의하여 인프라 기능과 애플리케이션 오케스트레이션 간의 원활한 핸드오프를 구현하는 데 중점을 둡니다. 쿠버네티스 네이티브 기본 요소, GitOps 워크플로, 그리고 Red Hat Advanced Cluster Management 와 같은 도구 를 사용하면 이러한 정의를 자동화, 감사 및 사전 테스트할 수 있습니다. 하지만 이러한 정의의 효과는 기반 아키텍처에 따라 제한됩니다. 따라서 강력한 재해 복구 전략은 단순히 VM이나 매니페스트에만 국한되지 않습니다. 토폴로지, 스토리지 동작 및 운영 설계를 종단 간 통합하는 것입니다.
