Google Cloud에서 OpenShift의 재해 복구

재해 복구(DR)는Google Cloud의 OpenShift Container Platform에 배포된 애플리케이션의 연속성을 유지하는 데 필수적입니다. 이 문서에서는 Google Cloud에서 OpenShift를 사용하는 DR의 아키텍처 옵션을 간략하게 설명하여 조직이 재해 발생 시 최소한의 다운타임과 신속한 복구를 달성할 수 있도록 지원합니다.

이 문서는Google Cloud에 배포된 OpenShift Container Platform에서 애플리케이션의 가용성 및 복원력을 유지하는 시스템 관리자, 클라우드 설계자, 애플리케이션 개발자를 대상으로 합니다.

이 문서는 장애 발생 시 워크로드의 고가용성을 유지하고 신속하게 복구할 수 있도록 하는 애플리케이션 수준 전략에 중점을 두는 시리즈의 일부입니다. 이 시리즈의 문서는 다음과 같습니다.

DR 계획

DR 계획은 클라우드에서 프로덕션 워크로드를 실행하는 데 중요한 구성요소입니다. OpenShift와 Google Cloud 는 강력한 인프라 수준 중복성을 제공하지만, 심각한 장애로부터 신속하게 복구할 수 있도록 애플리케이션을 설계하고 구성해야 합니다.

효과적인 DR 계획에는 다층적 접근 방식이 필요합니다. 빠른 재배포를 위해 애플리케이션 및 시스템의 명확한 복구 시간 목표(RTO) 및 목표 복구 시간(RPO)을 정의하는 것으로 시작합니다.

마지막으로, 보안 비밀과 사용자 인증 정보도 복구 가능하고 안전하게 관리되어야 합니다. 이러한 모든 요소를 고려하면 다른 리전에서 새 OpenShift 클러스터를 빠르게 만들거나 비활성 보조 클러스터로 장애 조치할 수 있는 DR 체계를 달성할 수 있습니다. 이 보조 클러스터는 장애가 발생할 때까지 오프라인 상태로 유지되며, 장애가 발생하면 최소한의 다운타임으로 작업을 인계하기 위해 시작되고 온라인 상태가 됩니다.

DR 아키텍처

Google Cloud에서 OpenShift를 사용한 DR에 사용할 수 있는 다양한 배포 아키텍처 옵션이 있습니다. 이러한 각 옵션은 비용, 복잡성, 가용성에 미치는 영향이 다릅니다. 다음 표에서는 이러한 아키텍처에 대한 개요를 보여줍니다.

아키텍처 설명 사용 사례 장점 단점
active-passive 한 클러스터는 활성 상태로 모든 트래픽을 처리하고 다른 클러스터는 수동 상태로 인계 받을 준비가 되어 있습니다. 데이터가 수동 클러스터에 복제됩니다. RTO 및 RPO 요구사항이 중간 정도인 애플리케이션에 적합합니다. 구현이 더 간단하고 대기 클러스터 비용이 저렴합니다. 장애 조치 시간, 데이터 동기화 지연 가능성으로 인해 RTO가 높아집니다.
활성-비활성 활성-수동과 유사하지만 비활성 클러스터는 DR 이벤트가 발생할 때까지 사용되지 않습니다. 데이터가 정기적으로 백업됩니다. 높은 RTO 및 RPO가 허용되는 비용에 민감한 환경에 적합합니다. 비활성 상태일 때 운영 비용이 낮으며 보조 시스템이 활성 상태로 실행되지 않는 DR(콜드 DR)에 적합합니다. 데이터가 오래될 수 있지만 활성화 및 동기화 시간으로 인해 RTO가 높습니다.
active-active 두 클러스터 모두 활성 상태이며 리전 간 부하 분산 및 데이터 복제를 통해 트래픽을 처리합니다. 다운타임이 최소화되고 가용성이 높은 중요 애플리케이션 가장 낮은 RTO 및 RPO, 지속적인 가용성 복잡성과 비용이 가장 높으며 강력한 네트워크와 데이터 동기화가 필요합니다.

다음 단계