이 문서에서는 Google Distributed Cloud (GDC) 오프라인 멀티 영역 유니버스에서 애플리케이션 데이터를 보호하는 방법을 설명합니다. 고가용성 애플리케이션을 유지하려면 로컬 서비스 중단이나 장애에 탄력적인 데이터 보호 전략을 구현하면 됩니다. GDC는 객체 스토리지 및 블록 스토리지에 대한 데이터 복제 전략을 제공하므로 유니버스에서 기본 및 보조 영역의 장애 조치 절차를 유지할 수 있습니다.
이 문서는 재해 복구 워크플로를 개발하는 플랫폼 관리자 그룹 내 IT 관리자와 GDC 유니버스에서 애플리케이션을 개발하고 유지관리하는 애플리케이션 운영자 그룹 내 애플리케이션 개발자를 대상으로 합니다.
재해 복구를 위해 비동기 데이터 복제를 사용하여 다중 영역 유니버스에서 애플리케이션 스토리지에 대한 강력한 데이터 보호를 설정할 수 있습니다.
이 접근 방식은 주기적으로 기본 영역에서 보조 영역으로 데이터를 복사하는 것을 포함합니다. 이 메커니즘은 기본 영역에 서비스 중단이 발생할 경우 데이터를 보호하고 액세스 가능하게 유지합니다.
객체 스토리지의 데이터 복제는 이중 영역 버킷을 사용하여 데이터를 자동으로 복제하며, 수동 개입이 필요하지 않습니다. 이중 영역 버킷을 만드는 방법에 대한 자세한 내용은 스토리지 버킷 만들기를 참고하세요.
블록 스토리지의 데이터 복제는 이중 영역 영구 볼륨을 사용하여 데이터를 복제하며 볼륨 장애 조치 절차가 필요합니다. 자세한 내용은 비동기식으로 볼륨 복제를 참고하세요.
데이터 복제를 구성하면 기본 영역이 오프라인일 때 데이터가 장애 조치 절차를 따릅니다. 장애 조치 절차는 블록 및 객체 스토리지 복제에 따라 다릅니다. 하지만 두 데이터 복제 전략 모두 다음의 중요한 단계를 사용합니다.
기본 영역 서비스 중단을 확인합니다.
기본 영역에서 복제를 중지합니다.
수동 개입 또는 사전 구성된 장애 조치를 통해 백업 보조 영역을 기본 영역의 역할을 맡도록 승격합니다.
새 기본 영역의 작동 상태를 확인합니다.
인프라 운영자 그룹의 구성원에게 연락하여 두 영역이 비동기 데이터 복제를 위해 구성되어 있는지 확인합니다.
비동기 데이터 복제에는 고유한 지연이 있으므로 이 설정은 0이 아닌 낮은 복구 시점 목표 (RPO)가 필요한 시스템에 가장 유용합니다. 시스템에 최소한의 데이터 손실이 필요하지만 시간으로 측정되는 작은 사전 정의된 최대 데이터 손실량(일반적으로 복구할 수 없는 재해 이벤트 직전에 생성된 데이터와 관련됨)을 허용할 수 있는 경우 비동기 데이터 복제는 애플리케이션에 구현할 가치가 있는 기능입니다.
0이 아닌 낮은 RPO의 예로는 RPO가 5분인 금융 거래 플랫폼이 있습니다. 여기서는 비동기 데이터 복제가 2분마다 보조 재해 복구 영역에 거래 데이터를 복사하도록 설정됩니다.
5분은 대량 시스템에서 허용되는 최소 데이터 손실 기간을 나타내므로 RPO가 낮은 시나리오입니다.
2분 간격의 비동기 복제에 내재된 지연으로 인해 아직 데이터가 복사되지 않은 작은 기간이 있어 손실이 발생할 수 있으므로 0이 아닌 RPO 시나리오입니다.
인프라 운영자 그룹과 협력하여 이중 영역 비동기 스토리지 복제 워크플로를 정의하고 인프라의 데이터 복제 기능이 RPO 요구사항을 지원하는지 확인해야 합니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-04(UTC)"],[],[],null,["# Data protection with multi-zone storage\n\nThis document provides information for protecting your application data in a\nGoogle Distributed Cloud (GDC) air-gapped multi-zone universe. To maintain highly available\napplications, you can implement a data protection strategy that is resilient to\nlocal outages or failures. GDC provides data replication\nstrategies for\n[object storage](/distributed-cloud/hosted/docs/latest/gdch/platform/pa-user/storage#object_storage) and\n[block storage](/distributed-cloud/hosted/docs/latest/gdch/platform/pa-user/storage#block_storage) so you can\nmaintain failover procedures for primary and secondary zones in your universe.\n\nThis document is for IT administrators within the platform administrator group\nwho are responsible for developing disaster recovery workflows, and application\ndevelopers within the application operator group who are responsible for\ndeveloping and maintaining applications in a GDC\nuniverse.\n\nFor more information, see\n[Audiences for GDC air-gapped documentation](/distributed-cloud/hosted/docs/latest/gdch/resources/audiences).\n\nStorage replication for disaster recovery\n-----------------------------------------\n\nYou can set up robust data protection for your application storage in a\nmulti-zone universe using *asynchronous data replication* for disaster recovery.\nThis approach involves copying data from a primary zone to a secondary zone at\nperiodic intervals. This mechanism keeps your data protected and accessible if\nthe primary zone experiences an outage.\n\nData replication for object storage uses dual zone buckets to automatically\nreplicate your data, and doesn't require manual intervention. For more\ninformation about creating a dual zone bucket, see\n[Create storage buckets](/distributed-cloud/hosted/docs/latest/gdch/platform/pa-user/create-storage-buckets#cli).\n\nData replication for block storage uses dual zone persistent volumes to\nreplicate your data, and requires a volume failover procedure. For more\ninformation, see\n[Replicate volumes asynchronously](/distributed-cloud/hosted/docs/latest/gdch/application/ao-user/async-block-replication).\n\nAfter you configure data replication, your data follows a *failover procedure*\nwhen the primary zone is offline. The failover procedures are distinct for block\nand object storage replication. However, both data replication strategies use\nthe following critical steps:\n\n1. Verify the primary zone outage.\n2. Stop the replication from the primary zone.\n3. Promote the backup secondary zone to assume the role of the primary zone with manual intervention or a pre-configured failover.\n4. Verify the operational status of the new primary zone.\n\nReach out to a member of the infrastructure operator group to confirm your two\nzones are configured for asynchronous data replication.\n\nThe inherent delay that comes with asynchronous data replication means that this\nsetup is most useful for systems that require a low, but non-zero recovery point\nobjective (RPO). If your system requires minimal data loss, but can tolerate a\nsmall predefined maximum amount of data loss measured in time, usually related\nto data generated just immediately before a disaster event that could be\npotentially unrecoverable, then asynchronous data replication is a valuable\nfeature to implement for your applications.\n| **Important:** Synchronous data replication is not supported. Synchronous data replication maintains strict consistency between data in two zones by immediately duplicating all data written from a primary zone to the secondary zone, which provides zero RPO in disaster scenarios.\n\nAn example of a low non-zero RPO might be a financial trading platform with an\nRPO of five minutes, where asynchronous data replication is set to copy trade\ndata to a secondary disaster recovery zone every two minutes:\n\n- This is a *low RPO* scenario because the five minutes represents the minimum acceptable data loss window for the high-volume system.\n- It's a *non-zero RPO* scenario because the inherent delay in asynchronous replication of two minute intervals means that there is a small window of time where data has not yet been copied, resulting in potential loss.\n\nYou must work with your infrastructure operator group to define your dual zone\nasynchronous storage replication workflow, and verify the infrastructure's data\nreplication capabilities support your RPO requirements.\n\nWhat's next\n-----------\n\n- [High availability for your apps](/distributed-cloud/hosted/docs/latest/gdch/platform-application/pa-ao-operations/ha-apps/overview)\n- [Deploy a highly available VM application](/distributed-cloud/hosted/docs/latest/gdch/platform-application/pa-ao-operations/ha-apps/deploy-ha-vm-app)\n- [Deploy a highly available container application](/distributed-cloud/hosted/docs/latest/gdch/platform-application/pa-ao-operations/ha-apps/deploy-ha-container-app)"]]