Google Cloud의 OpenShift: 활성-수동 및 활성-비활성 구성의 재해 복구 전략

이 문서에서는 Google Cloud 의 OpenShift 배포 환경에서 재해 발생 시 다운타임을 최소화하고 빠르게 복구할 수 있도록 활성-수동 및 활성-비활성 재해 복구를 계획하고 구현하는 방법을 설명합니다. 또한 데이터 백업, 코드 기반 구성 관리, 보안 비밀 처리에 관한 권장사항을 제공하여 재해 발생 시 애플리케이션을 신속하게 복구할 수 있도록 지원합니다.

이 문서는Google Cloud에 배포된 OpenShift 컨테이너 플랫폼에서 애플리케이션의 가용성과 복원력을 유지할 책임을 맡은 시스템 관리자, 클라우드 설계자, 애플리케이션 개발자를 대상으로 합니다.

이 문서는 장애 발생 시 워크로드의 고가용성을 유지하고 신속하게 복구할 수 있도록 하는 애플리케이션 수준 전략에 중점을 두는 시리즈의 일부입니다. 이 문서에서는 사용자가 이미 OpenShift를 사용한 재해 복구 권장사항을 읽었다고 가정합니다. 이 시리즈의 문서는 다음과 같습니다.

• Google Cloud의 OpenShift 재해 복구
• OpenShift를 사용한 고가용성 권장사항
• Google Cloud의 OpenShift: 활성-수동 및 활성-비활성 설정을 위한 재해 복구 전략(이 페이지)

재해 복구 아키텍처

이 섹션에서는 활성-수동 및 활성-비활성 재해 복구 시나리오의 아키텍처를 설명합니다.

사용 제품

• Google Compute Engine
• Google Cloud 전역 외부 HTTPS 부하 분산기
• Google Cloud 패스스루 네트워크 부하 분산기
• Cloud DNS
• 네트워크 엔드포인트 그룹
• Cloud Storage
• Cloud SQL
• Persistent Disk
• Cloud Storage
• Secret Manager
• Cloud Monitoring
• VPC 네트워크

활성-수동 배포

다음 다이어그램은 Google Cloud에서 OpenShift의 활성-수동 배포 시나리오를 보여줍니다.

위의 다이어그램에 표시된 것처럼 재해 복구를 위한 활성-수동 배포에서는 기본 리전의 OpenShift 클러스터가 모든 프로덕션 트래픽을 처리합니다. 다른 리전의 보조 클러스터는 기본 클러스터 장애를 대비해 즉시 인계받을 수 있도록 대기 상태로 유지됩니다. 이 설정은 보조 클러스터를 미리 프로비저닝하고 웜 상태로 유지함으로써 다운타임을 최소화합니다. 즉, 필요한 인프라와 애플리케이션 구성요소가 모두 준비되어 있으나, 필요할 때까지 트래픽을 실제로 처리하지 않는 상태입니다. 또한 애플리케이션 데이터는 수동 클러스터로 복제되어 RPO에 맞게 데이터 손실을 최소화합니다.

한 리전의 클러스터가 기본(활성) 사이트로 작동하며 모든 프로덕션 트래픽을 처리합니다. 다른 리전의 보조 클러스터는 재해 복구용으로 대기합니다. 이 보조 클러스터는 웜 상태로 유지되며, 기본 클러스터 장애 시 최소한의 지연으로 즉시 인계받을 수 있습니다.

활성-수동 DR 시나리오의 구성요소 설명

이 아키텍처는 다음 구성으로 이루어져 있습니다.

• 기본 OpenShift 클러스터(활성): 기본Google Cloud 리전에 위치하며, 프로덕션 워크로드를 실행하고 정상 운영 상태에서 모든 사용자 트래픽을 처리합니다.
• 보조 OpenShift 클러스터(수동): 장애 격리를 위해 별도의Google Cloud 리전에 위치하며, 웜 대기 클러스터로 동작합니다. 이 클러스터는 일부 구성과 실행이 완료된 상태로, 기본 시스템 장애 시 인계받을 준비가 되어 있습니다. 필요한 인프라, OpenShift 구성, 애플리케이션 구성요소가 배포되어 있지만, 장애 조치 이벤트가 트리거될 때까지는 실제 프로덕션 트래픽을 처리하지 않습니다.
• Google Cloud 리전: 재해 복구의 기반을 제공하는 지리적으로 분리된 위치입니다. 서로 다른 리전을 사용할 경우 대규모 장애가 한 리전에 영향을 미치더라도 대기 클러스터에는 영향을 미치지 않습니다.
• 전역 외부 HTTPS 부하 분산기: 애플리케이션 트래픽의 단일 전역 진입점으로 동작합니다. 정상 상태에서는 모든 트래픽이 기본(활성) 클러스터로 라우팅되도록 구성되어 있습니다. 상태 점검 기능을 통해 기본 클러스터의 가용성을 모니터링합니다.
• 데이터 복제 메커니즘: 기본 클러스터의 주요 애플리케이션 데이터를 보조 클러스터에 복제하는 지속적인 프로세스 또는 도구를 의미합니다(예: 데이터베이스 또는 영구 볼륨 상태). 이 방식은 데이터 일관성을 보장하고, 장애 조치 시 데이터 손실을 최소화하여 RPO를 충족할 수 있도록 합니다.
• 모니터링 및 상태 점검: 기본 클러스터와 그 애플리케이션의 상태와 가용성을 지속적으로 평가하는 시스템입니다(예: Cloud Monitoring, 부하 분산기 상태 점검, 내부 클러스터 모니터링 등). 이러한 시스템은 장애를 빠르게 감지하는 데 중요합니다.
• 장애 조치 메커니즘: 기본 클러스터에서 복구할 수 없는 장애가 감지되면 트래픽을 보조 클러스터로 리디렉션하는 사전 정의된 프로세스(수동, 반자동 또는 완전 자동)입니다. 일반적으로 이 프로세스는 전역 부하 분산기의 백엔드 구성을 업데이트하여 보조 클러스터를 대상으로 지정함으로써, 해당 클러스터를 새로운 활성 사이트로 전환하는 단계를 포함합니다.
• VPC 네트워크: 리전 간 데이터 복제 및 관리에 필요한 연결 기능을 제공하는 기본 Google Cloud 네트워크 인프라입니다.

활성-비활성 배포

활성-비활성 DR에서는 보조 리전을 대기 상태로 유지하며, 재해 발생 시에만 활성화됩니다. 데이터가 지속적으로 복제되는 활성-대기 구성과 달리, 이 전략은 Cloud Storage에 저장된 주기적 백업에 의존하며, 장애 조치 시 인프라가 프로비저닝되고 데이터가 복원됩니다. OpenShift 데이터 보호 API(OADP)와 통합된 Velero와 같은 도구를 사용하여 주기적으로 백업을 수행할 수 있습니다. 이 접근 방식은 비용을 최소화하므로, 복구 시간이 다소 길어도 되는 애플리케이션에 적합합니다. 또한 이 방식은 조직이 복구 시간 목표(RTO)와 복구 지점 목표(RPO)를 보다 유연하게 설정하고 조정할 수 있도록 지원합니다.

활성-비활성 DR 시나리오에서는 데이터가 대기 리전에 정기적으로 백업되지만, 실시간으로 복제되지는 않습니다. 인프라는 장애 조치 프로세스의 일부로 프로비저닝되며, 데이터는 최신 백업본에서 복원됩니다. Velero 오픈소스 프로젝트를 기반으로 한 OpenShift 데이터 보호 API(OADP)를 사용하여 정기적으로 백업을 수행할 수 있습니다. 이 백업을 버전 관리 기능이 사용 설정된 Cloud Storage 버킷에 저장하는 것이 좋습니다. 재해 발생 시 OADP를 사용하여 클러스터의 콘텐츠를 복원할 수 있습니다. 이 접근 방식은 지속적인 비용을 최소화하지만 활성-대기 구성에 비해 RTO가 길어지고 RPO가 높아질 수 있습니다. 이 구성은 복구 시간 목표가 더 긴 애플리케이션에 적합합니다.

다음 다이어그램은 활성-비활성 배포와 장애 조치 프로세스를 보여줍니다.

장애 조치 프로세스는 다음과 같습니다.

1. 모니터링된 서비스를 사용할 수 없게 되면 DR 이벤트가 트리거됩니다.
2. 파이프라인이 DR 리전에 인프라를 자동으로 프로비저닝합니다.
3. 새 OpenShift 클러스터가 프로비저닝됩니다.
4. OADP를 통해 최신 백업에서 애플리케이션 데이터, 보안 비밀, 객체가 복원됩니다.
5. Cloud DNS 레코드가 DR 리전의 부하 분산기를 가리키도록 업데이트됩니다.

위의 다이어그램에 표시된 것처럼 두 개의 개별 OpenShift 리전 클러스터가 서로 다른 Google Cloud 리전(us-central1, europe-west1 등)에 배포됩니다. 각 클러스터는 리전 내에서 고가용성을 유지해야 하며 중복성 확보를 위해 여러 영역을 사용해야 합니다.

활성-비활성 DR 시나리오의 구성요소 설명

이 아키텍처는 다음 구성으로 이루어져 있습니다.

• 기본 리전(리전 A): 프로덕션 트래픽을 처리하는 완전한 OpenShift 클러스터가 포함되어 있습니다.
• 보조 리전(리전 B): 처음에는 최소한의 리소스(VPC 및 서브넷)가 포함됩니다. 장애 조치 시 인프라(Compute Engine 인스턴스 및 OCP)가 프로비저닝됩니다.
• 백업 스토리지: Google Cloud Storage 버킷은 주기적 백업을 저장합니다(애플리케이션 오브젝트를 위한 OADP 또는 Velero 백업뿐만 아니라 PV 및 데이터베이스 백업도 포함). 버킷에는 버전 관리와 교차 리전 복제를 사용하는 것이 좋습니다.
• 구성 관리: Git 저장소는 코드형 인프라(IaC, 예: Terraform)와 Kubernetes 또는 OpenShift 매니페스트(GitOps용)를 저장합니다.
• 백업 도구: 기본 클러스터에 구성된 OADP(Velero)는 Cloud Storage에 예약 백업을 수행합니다.
• 조정: 스크립트 또는 자동화 도구가 장애 조치 중 인프라 프로비저닝 및 복원 프로세스를 트리거합니다.

사용 사례

이 섹션에서는 활성-수동 및 활성-비활성 배포의 다양한 사용 사례를 예시로 보여줍니다.

활성-수동 DR 사용 사례

활성-수동 DR은 다음과 같은 사용 사례에 권장됩니다.

• 콜드 복원(즉시 액세스할 수 없는 백업에서 복원)으로는 달성하기 어려운 낮은 RTO(예: 수분~수시간)를 요구하는 애플리케이션
• 지속적인 데이터 복제가 가능하고 RPO를 최소화해야 하는 시스템(예: 수분~수초)
• 다운타임 제한이 엄격한 규제 산업과, 다운타임으로 인한 비즈니스 영향이 커서 웜 대기 클러스터를 유지할 만한 가치가 있는 중요 비즈니스 애플리케이션

활성-비활성 DR 사용 사례

활성-비활성 DR은 다음과 같은 사용 사례에 권장됩니다.

• 더 긴 RTO(예: 수분~수시간)를 허용할 수 있는 애플리케이션
• 비용 최적화가 중요한 환경으로, 지속적으로 실행되는 대기 클러스터의 비용이 금지되는 경우. 지속 비용의 주요 부분은 컴퓨팅 인스턴스 실행이 아니라 객체 스토리지 사용에 해당합니다.
• 개발, 테스트 또는 중요도가 낮은 프로덕션 워크로드
• 복구 시간이 덜 중요하게 작용하는 보관 또는 일괄 처리 시스템

설계 고려사항

이 섹션에서는 이 참조 아키텍처를 사용하여 보안, 신뢰성, 운영 효율성, 비용, 성능 관련 특정 요구사항을 충족하는 토폴로지를 개발할 때 고려해야 하는 설계 요소, 권장사항, 설계 권장사항을 설명합니다.

활성-수동 설계 고려사항

이 섹션에서는 활성-수동 DR 시나리오에 대한 설계 고려사항을 설명합니다.

애플리케이션 상태 및 구성 보호

OpenShift Container Platform은 OADP를 제공하며, 클러스터에서 실행되는 애플리케이션에 대한 포괄적인 재해 복구 보호 기능을 제공합니다. 이를 사용하여 컨테이너화된 애플리케이션과 가상 머신에서 모두 사용하는 Kubernetes 및 OpenShift 객체(예: 배포, 서비스, 경로, PVC, ConfigMap, 보안 비밀, CRD)를 백업할 수 있습니다. 단, OADP는 전체 클러스터 백업 및 복원을 지원하지 않습니다. 백업을 구성하고 예약하는 방법과 복원 작업을 실행하는 방법을 알아보려면 Red Hat 문서를 참조하세요.

OADP는 애플리케이션에서 사용하는 블록 스토리지와 NFS 스토리지에 의존하는 영구 볼륨에 대한 백업 및 복원 프로세스를 제공합니다. 이러한 프로세스는 Restic 또는 Kopia와 같은 도구를 사용하여 스냅샷을 생성하거나 파일 수준 백업을 수행함으로써 실행할 수 있습니다.

OADP는 객체 정의 백업, 구성 일관성 보장, 필요 시 특정 애플리케이션 또는 네임스페이스 복원을 수행하는 데 유용하며, 데이터 복제를 보완합니다.

활성-수동 구성에서 RPO와 RTO를 추가로 줄이기 위해 기본 리전과 보조 리전 간 데이터 복제를 구성하는 것이 좋습니다.

데이터 복제는 보조 클러스터가 중단 없이 인계할 수 있도록 보장하는 데 중요합니다. 다음 섹션에 설명된 바와 같이, 기본 클러스터에서 보조 클러스터로의 데이터 복제 구현은 애플리케이션이 사용하는 스토리지 유형에 따라 달라집니다.

블록 스토리지(영구 볼륨)

Google Persistent Disk 비동기 복제를 사용하여 기본 리전에서 보조 리전으로 데이터를 복사합니다. 이 접근 방식에서는 기본 리전에 기본 디스크를, 보조 리전에 보조 디스크를 만들고, 두 디스크 간 복제를 설정합니다. 일관성 그룹을 사용하면 두 디스크가 동일한 시점의 복제 데이터를 포함하도록 보장되며, 이 데이터가 DR에 사용됩니다. 자세한 내용은 Persistent Disk 비동기 복제 구성을 참조하세요.

PersistentVolume 객체

OpenShift에서 두 클러스터 모두에 이러한 디스크에 연결되는 PersistentVolumes 객체를 만들고, 애플리케이션이 두 클러스터에서 동일한 Persistent Volume Claim(PVC)을 사용하도록 설정합니다.

애플리케이션 수준 복제

일부 애플리케이션(예: 데이터베이스, 메시지 큐)은 클러스터 간에 구성할 수 있는 기본 제공되는 복제 기능을 갖추고 있습니다. 또한 Pub/Sub와 같은 관리형 서비스를 사용하여 특정 유형의 애플리케이션 데이터나 이벤트의 복제를 지원할 수도 있습니다. (예: 데이터베이스 및 메시지 큐)

데이터베이스 백업

애플리케이션은 다양한 유형의 데이터베이스 제품을 사용할 수 있습니다. 이 문서에서는 데이터베이스 백업 설계 시 고려사항을 설명하기 위해 PostgreSQL을 예시 데이터베이스로 사용합니다.

클러스터 내 데이터베이스 운영자를 사용하는 자체 호스팅 백업

CloudNative PostgreSQL Operator와 같은 데이터베이스 운영자는 PostgreSQL 클러스터의 예약 백업 및 재해 복구를 지원할 수 있습니다. CloudNative PostgreSQL Operator는 pg_basebackup과 같은 도구와 기본적으로 통합되며, 스트리밍 복제 백업을 지원합니다. 백업은 내구성과 복구를 위해 Google Cloud Storage(Cloud Storage)와 같은 클라우드 스토리지 서비스에 저장할 수 있습니다.

기본 리전과 보조 리전의 클러스터 간 스트리밍 복제를 설정하여, 기본 리전의 장애 발생 시에도 데이터가 사용 가능하도록 할 수 있습니다. 이 스트리밍 복제는 일반적으로 리전 내에서는 동기식으로, 리전 간에는 비동기식으로 수행됩니다. 자세한 구성 단계는 CloudNativePG 문서를 참조하세요.

재해 발생 시, 새로운 PostgreSQL 클러스터에 백업을 복원하여 다운타임과 데이터 손실을 최소화할 수 있습니다. 다음은 CloudNative PostgreSQL Operator를 사용하여 예약 백업을 사용 설정하는 구성 스니펫의 예시입니다.

        apiVersion: postgresql.cnpg.io/v1
        kind: ScheduledBackup
        metadata:
        name: backup-example
        spec:
        schedule: "0 0 0 * * *"
        backupOwnerReference: self
        cluster:
            name: pg-backup

관리형 서비스

Cloud SQL과 같은 관리형 데이터베이스는 백업 및 복제 기능이 기본적으로 제공됩니다. 기본 데이터베이스 인스턴스에서 보조 리전의 복제본으로 비동기 복제를 설정하는 것이 좋습니다. 자세한 내용은 Cloud SQL의 복제 정보를 참조하세요. OpenShift에서는 각 클러스터에 맞는 올바른 데이터베이스 연결 문자열을 지정하도록 보안 비밀 또는 구성 맵을 설정합니다.

비동기 복제는 0이 아닌 RPO를 초래하므로, 최신 데이터 기록이 손실될 가능성이 있습니다. 데이터 손실을 완화할 수 있도록 애플리케이션을 설계해야 합니다. 또는 다른 복제 방식을 사용하는 것도 고려해 보세요.

또한 Cloud SQL 자동 백업을 사용 설정하는 것이 좋습니다. 자세한 내용은 주문형 및 자동 백업 만들기 및 관리를 참조하세요.

장애 조치 프로세스

기본 클러스터에 장애가 발생하면 Cloud DNS는 상태 점검과 장애 조치 정책에 따라 트래픽을 자동으로 보조 리전 클러스터로 리디렉션합니다.

보조 클러스터가 읽기 복제본에서 기본으로 승격되면 활성 사이트로 전환되어 프로덕션 트래픽을 처리합니다. 데이터베이스 쓰기 작업을 허용하려면 이러한 승격이 필요합니다.

Cloud SQL에 대한 DR을 설정하려면 Google Cloud SQL 재해 복구 문서에 설명된 단계를 따르세요. 비동기 데이터베이스 또는 스토리지 복제를 사용하면 RPO가 0이 아니게 되며, 애플리케이션이 최신 쓰기 데이터 손실을 허용할 수 있도록 보장하는 데 도움이 됩니다. 또는 다른 복제 방식을 사용하는 것도 고려해 보세요.

안전한 보안 비밀 관리

데이터베이스 비밀번호, API 키, TLS 인증서와 같은 보안 비밀은 DR의 중요한 구성 요소입니다. 새 클러스터에서 이러한 보안 비밀을 안전하고 신뢰성 있게 복원할 수 있어야 합니다.

보안 비밀 관리의 일반적인 접근 방식은 다음과 같습니다.

• 외부 보안 비밀 사용: 외부 보안 비밀 운영자와 같은 도구를 사용하여 Google Secret Manager에서 보안 비밀을 가져옵니다.
• OADP 운영자를 사용하여 보안 비밀 백업: 외부 저장소를 사용하지 않는 경우 보안 비밀이 백업에 포함되어 있는지 확인합니다.
• 정기적 교체: 보안 비밀을 정기적으로 교체하고, 보안 비밀 관리 전략이 DR 시나리오를 지원하도록 합니다.
• 테스트: 단계적 환경에서 보안 비밀 복원을 테스트하여 모든 서비스가 제공된 사용자 인증 정보로 시작될 수 있는지 확인합니다.
• 검증: DR 클러스터가 외부 저장소에서 보안 비밀을 가져올 수 있도록 필요한 IAM 역할 또는 인증 방식을 갖추고 있는지 확인합니다.

네트워킹 및 트래픽 관리

여러 OpenShift 클러스터(예: 기본 및 보조 클러스터) 간의 트래픽을 분산하기 위한 기본 인그레스 포인트로 Google Cloud의 전역 외부 HTTPS 부하 분산기를 사용합니다. 이 전역 서비스는 근접성, 상태, 가용성을 기준으로 사용자 요청을 적절한 백엔드 클러스터로 전달합니다.

전역 부하 분산기를 OpenShift 클러스터에 연결하려면 다음 방법 중 하나를 사용하면 됩니다.

• 리전 부하 분산기 사용(인터넷 NEG): 각 OpenShift 클러스터의 인그레스 서비스(OCP 라우터)를 노출하는 리전 부하 분산기의 외부 IP 주소를 참조하도록Google Cloud 인터넷 네트워크 엔드포인트 그룹(NEG)을 구성합니다. 이후 전역 부하 분산기가 이러한 리전 부하 분산기의 IP로 트래픽을 라우팅합니다. 이 접근 방식은 추상화 레이어를 제공하지만 추가 네트워크 홉이 포함됩니다.
• 직접 포드 라우팅(Compute Engine_VM_IP_PORT NEGs): OpenShift 인그레스 컨트롤러 통합 구성을 Compute Engine_VM_IP_PORT 유형의 Google Cloud네트워크 엔드포인트 그룹(NEG)을 사용하도록 구성합니다. 이 접근 방식은 전역 부하 분산기가 OpenShift 인그레스 컨트롤러(라우터) 포드의 내부 PodIP:TargetPort를 직접 타대상으로 지정할 수 있게 합니다. 이 방법은 추가 홉 및 노드 프록시 단계를 우회합니다. 일반적으로 더 낮은 지연 시간을 제공하고, 전역 부하 분산기에서 보다 직접적인 상태 점검을 수행할 수 있도록 합니다.

두 구성 방식 모두 전역 부하 분산기가 서로 다른 리전의 클러스터 간 트래픽 분산을 효과적으로 관리할 수 있도록 합니다. 자세한 내용은 외부 백엔드가 있는 전역 외부 애플리케이션 부하 분산기 설정을 참조하세요.

VPC

VPC 관리를 위해서는 다음과 같은 접근 방식이 권장됩니다.

• 공유 VPC: 기본 클러스터와 보조 클러스터 모두에 대한 네트워크 관리를 중앙 집중화하려면 공유 VPC를 사용합니다. 이 접근 방식은 관리 작업을 단순화하고 리전 간 네트워크 정책의 일관성을 보장합니다.
• 전역 동적 라우팅: VPC 내에서 전역 동적 라우팅을 사용 설정하여 리전 간 경로를 자동으로 전파하고, 클러스터 간 원활한 연결을 보장합니다.
• 커스텀 모드 VPC: 클러스터가 실행되는 리전에 커스텀 모드 VPC를 사용하고, 해당 리전에 맞는 특정 서브넷을 만듭니다. 이 구성은 Compute Engine_VM_IP_PORT 라우팅과 같은 방식에서 필요한 VPC 네이티브 포드 네트워킹에 자주 필요합니다.
• VPC 네트워크 피어링: 각 리전 및 클러스터에 대해 별도의 VPC 네트워크를 사용해야 하는 경우, VPC 네트워크 피어링을 사용하여 리전과 클러스터를 연결합니다.

서브넷 및 IP 주소

네트워크 분할을 유지하고 IP 주소 충돌을 방지하기 위해 각 리전에 리전별 서브넷을 생성합니다.

라우팅 문제를 방지하기 위해 리전 간 IP 주소 범위가 서로 겹치지 않도록 합니다.

Red Hat Service Mesh를 사용한 클러스터 간 트래픽

OpenShift는 여러 OpenShift 클러스터에 배포된 서비스 간에 통신을 가능하게 하는 서비스 메시 연합을 지원합니다. 이 기능은 장애 조치 또는 데이터 복제 중에 서비스가 클러스터 간 통신을 수행해야 하는 DR 시나리오에서 특히 유용합니다.

기본 클러스터와 보조 클러스터 간 서비스 메시 연합을 설정하는 방법은 Red Hat 문서를 참조하세요.

활성-비활성 설계 고려사항

이 섹션에서는 활성-비활성 DR 솔루션을 위한 설계 고려사항을 설명합니다.

코드 기반 애플리케이션 구성(GitOps)

모든 클러스터 및 애플리케이션 구성을 Git 저장소에 저장하기 위해 GitOps 접근 방식을 채택하는 것이 좋습니다. 이 접근 방식은 다른 클러스터에서 안정적으로 실행 중인 것으로 확인된 상태로 동기화할 수 있게 함으로써 DR 시나리오에서 빠른 복구를 가능하게 합니다. 백업을 통해 런타임 상태의 스냅샷을 확보할 수 있지만 재해 발생 후 애플리케이션 로직, 매니페스트, 인프라 정의를 신속하게 다시 배포할 수 있는 신뢰할 수 있는 방법 또한 필요합니다.

OpenShift GitOps 운영자 사용

Argo CD를 기반으로 하는 OpenShift GitOps 운영자는 OpenShift 환경 내에서 GitOps 패턴을 직접 구현할 수 있도록 Red Hat이 지원하는 방식을 제공합니다. 이 운영자는 선택한 구성을 클러스터 상태와 지속적으로 조정하는 프로세스를 자동화하고 해당 구성을 Git 저장소에 저장합니다.

OpenShift GitOps 운영자의 컨트롤러는 클러스터 상태가 해당 저장소에 정의된 구성과 일치하도록 지속적으로 보장합니다. 리소스가 변경되거나 누락되면 자동으로 이를 조정합니다. 자세한 내용은 Red Hat OpenShift GitOps 정보를 참조하세요.

DR 시나리오 실행

재해가 발생한 경우 다음을 수행합니다.

• 다른 리전에 새로운 OpenShift 클러스터를 설정합니다.
• OpenShift GitOps 운영자를 설치합니다.
• Git 저장소를 참조하는 동일한 애플리케이션 매니페스트를 적용합니다.

이 연산자는 클러스터 상태를 저장소와 일치하도록 동기화하며, 코드에 정의된 배포, 서비스, 경로, 운영자 및 기타 리소스를 신속하게 다시 배포합니다.

DR 중 문제가 발생하지 않도록 다음을 수행하는 것이 좋습니다.

• Git 저장소에서 엄격한 브랜칭 및 태그 지정 전략을 유지하여 DR에 적합한 안정적인 구성을 식별할 수 있도록 합니다.
• DR 클러스터가 Git 저장소에 액세스할 수 있는 네트워크 연결과 적절한 권한을 가지고 있는지 확인합니다.
• 장애 조치 중 수동 개입을 방지하기 위해 모든 리소스 유형(예: 인프라 구성요소, 애플리케이션 워크로드, 구성)을 코드로 포함합니다.

방화벽 규칙

트래픽 흐름을 제어하고 보안을 강화하기 위해 두 클러스터에 일관되게 적용할 수 있는 통합 방화벽 정책을 정의합니다.

최소 권한 원칙을 따릅니다. 즉, 애플리케이션 기능에 필요한 트래픽만 허용하도록 인바운드 및 아웃바운드 트래픽을 제한합니다.

배포

이 참조 아키텍처를 기반으로 토폴로지를 배포하는 방법은 Red Hat 문서를 참조하세요.

다음 단계

• 클러스터 상태, 복제 상태, 백업 성공 여부, 기본 및 보조 환경의 애플리케이션 성능을 모니터링하고 알림을 구현하는 방법을 알아봅니다.
• OpenShift를 설치하는 방법 Google Cloud 알아보기
• Google Cloud의 Red Hat 솔루션에 대해 자세히 알아보기