다음은 백업 및 DR 백업/복구 어플라이언스를 배포하는 방법에 영향을 미치는 몇 가지 중요한 고려사항입니다.
조직의 복구 시간 목표 (RTO) 요구사항은 무엇인가요? RTO는 데이터가 없는 상태로 있을 수 있는 최대 시간입니다. 예를 들어 RTO가 4시간인 경우 장애 발생 후 4시간 이내에 데이터에 액세스할 수 있어야 합니다.
백업 관리를 중앙 집중화해야 하나요? 백업을 중앙에서 관리할지 여부를 결정해야 합니다.
- 중앙 집중식 백업 관리는 모든 비즈니스 라인에서 모든 워크로드의 백업을 관리할 수 있는 단일 어플라이언스 관리 콘솔이 있음을 의미합니다. 단일 어플라이언스 관리 콘솔만 관리하면 되므로 백업을 관리하는 더 효율적인 방법이 될 수 있습니다.
- 분산 백업 관리란 각 비즈니스 라인에 별도의 어플라이언스 관리 콘솔이 있음을 의미합니다. 운영 모드는 조직마다 다릅니다.
백업 사용 사례는 무엇인가요? 프로덕션 리전에서 재해가 발생할 경우 재해 복구를 위해 원격 백업이 필요한가요? 아니면 로컬에서 데이터를 보호하는 것으로 충분한가요? 재해 복구 기능이 필요한 경우 리전 간 백업을 고려해야 합니다. 즉, 한 위치가 재해의 영향을 받더라도 데이터에 계속 액세스할 수 있도록 여러 위치에 백업을 저장하는 것입니다.
워크로드가 단일 리전에 있음
리전 내에서 가장 적합한 백업 전략은 요구사항에 따라 다릅니다.
재해 복구 (DR)가 필요하지 않은 경우
최고의 성능과 최저 비용을 위해 워크로드가 실행되는 동일한 리전에 어플라이언스 관리 콘솔과 백업/복구 어플라이언스를 배포하세요. 워크로드와 동일한 리전에 백업 이미지를 저장합니다.
오프사이트에 백업 사본을 저장하려면 다른 리전에 백업을 저장하거나 이중 리전 또는 멀티 리전 스토리지를 사용하면 됩니다. 다른 리전에 백업을 저장하면 네트워크 및 스토리지 요금이 발생합니다.
백업 및 DR이 모두 필요한 경우
최고의 성능과 최저 비용을 위해 프로덕션 워크로드 리전과 동일한 리전에 어플라이언스 관리 콘솔을 배포하고 재해 복구에 사용할 수 있는 리전에 두 번째 어플라이언스 관리 콘솔을 배포합니다.
복구 시간 목표 (RTO)를 최소화하려면 프로덕션 워크로드 리전과 DR 리전 모두에 백업/복구 어플라이언스를 배포합니다. 이렇게 하면 재해 발생 시 DR 환경이 완전히 사전 프로비저닝되고 사용할 수 있습니다.
백업 이미지를 프로덕션 리전에 저장하고 복사본을 재해 복구 DR 리전에 저장하거나 이중 리전 또는 멀티 리전 스토리지를 사용합니다. 프로덕션 리전 백업 사본은 더 빠른 성능으로 일상적인 백업 요구사항을 충족할 수 있습니다. DR 리전에 복사된 데이터는 프로덕션 리전이 다운된 경우 워크로드를 복구하는 데 사용할 수 있습니다.
워크로드가 여러 리전에 있음
리전 간 최적의 백업 전략은 요구사항에 따라 다릅니다.
재해 복구 (DR)가 필요하지 않은 경우
최고의 성능과 최저 비용을 위해 워크로드가 실행되는 리전 중 하나에 어플라이언스 관리 콘솔을 배포하세요. 이를 통해 모든 워크로드와 리전에서 중앙 집중식 관리가 가능합니다.
워크로드가 실행되는 각 리전에 하나 이상의 백업/복구 어플라이언스를 배포합니다. 워크로드와 동일한 리전에 백업을 저장합니다.
오프사이트에 백업 사본을 저장하려면 다른 리전에 백업을 저장하거나 이중 리전 또는 멀티 리전 스토리지를 사용하면 됩니다. 다른 리전 또는 멀티 리전에 백업을 저장하면 네트워크 및 스토리지 요금이 발생합니다.
백업 및 DR이 모두 필요한 경우
각 프로덕션 워크로드 리전에 어플라이언스 관리 콘솔을 배포하고 DR 리전에 다른 어플라이언스 관리 콘솔을 배포합니다.
복구 시간 목표 (RTO)를 최소화하려면 프로덕션 워크로드 리전과 DR 리전 모두에 백업/복구 어플라이언스를 배포합니다. 이렇게 하면 재해 발생 시 DR 환경이 완전히 사전 프로비저닝되고 사용할 수 있습니다.
프로덕션 워크로드 리전에 백업을 저장하고 DR 리전에 사본을 저장하거나 이중 리전 또는 멀티 리전 스토리지를 사용합니다. 프로덕션 리전 백업 사본을 사용하여 백업 요구사항을 충족할 수 있습니다.
DR의 백업 이미지는 프로덕션 리전이 다운된 경우 워크로드를 복구하는 데 사용할 수 있습니다.
백업 및 DR 서비스에 권장되는 네트워크 토폴로지
Google Cloud 에서는 백업 및 DR 서비스를 배포할 때 공유 VPC를 사용하는 것이 좋습니다. 공유 VPC를 사용하는 조직은 여러 프로젝트의 리소스를 공통 VPC (VPC) 네트워크에 연결할 수 있으므로 해당 네트워크의 내부 IP를 사용하여 서로 안전하고 효율적으로 통신할 수 있습니다. 공유 VPC를 사용할 때는 프로젝트 하나를 호스트 프로젝트로 지정하고 여기에 하나 이상의 다른 서비스 프로젝트를 연결합니다. 호스트 프로젝트의 VPC 네트워크를 공유 VPC 네트워크라고 합니다. 서비스 프로젝트의 요건을 충족하는 리소스는 공유 VPC 네트워크의 서브넷을 사용할 수 있습니다.
공유 VPC를 사용하면 조직 관리자가 서브넷, 경로, 방화벽과 같은 네트워크 리소스를 중앙에서 제어하면서 서비스 프로젝트 관리자에게 인스턴스 생성 및 관리와 같은 관리 책임을 위임할 수 있습니다.
어플라이언스 관리 콘솔은 서비스 프로듀서 VPC 네트워크 VPC로 활성화됩니다. 이 서비스 프로듀서 VPC는 비공개 Google 액세스를 사용하여 프로젝트와 통신합니다. 이 연결의 기본 목적은 어플라이언스 관리 콘솔과 백업/복구 어플라이언스가 메타데이터를 교환하는 것입니다. 백업 트래픽은 이 링크를 통과하지 않습니다. 하지만 어플라이언스 관리 콘솔은 모든 네트워크에 배포된 모든 백업/복구 어플라이언스와 통신해야 합니다.
공유 VPC 권장사항
다음 권장사항을 따르는 것이 좋습니다.
어플라이언스 관리 콘솔에 연결: 서비스 제공업체 네트워크를 네트워크 내의 공유 VPC에 연결하는 것이 좋습니다. 어플라이언스 관리 콘솔의 모든 트래픽은 이 VPC를 통해, 따라서 호스트 프로젝트를 통해 흐릅니다. 공유 VPC를 통해 백업 및 DR 서비스에 연결을 프로비저닝하면 워크로드가 실행되는 프로젝트 (서비스 프로젝트)와 백업 및 DR 서비스 간의 원활한 연결도 가능합니다.
백업/복구 어플라이언스 어플라이언스 위치: 백업/복구 어플라이언스는 어플라이언스 관리 콘솔에 연결하기 위해 비공개 Google 액세스가 사용 설정된 서브넷에 배포해야 합니다. 백업/복구 어플라이언스에 사용할 프로젝트를 선택하는 데 권장되는 전략은 두 가지입니다.
중앙 호스트 프로젝트: 이 전략에서 백업 및 DR 서비스는 IT의 중앙 서비스로 취급됩니다. 중앙 백업팀이 서비스 프로비저닝을 관리합니다. 따라서 모든 백업/복구 어플라이언스는 호스트 프로젝트에서 프로비저닝되므로 중앙 관리자가 모든 백업 리소스를 중앙 프로젝트로 통합할 수 있습니다. 이 접근 방식은 모든 백업 관련 리소스와 결제를 단일 프로젝트로 통합하는 이점이 있습니다.
서비스 프로젝트에서: 이 전략은 서비스 프로젝트가 생성되고 관리가 분산된 팀에 위임되는 더 분산된 팀에 적합합니다. 이 시나리오에서는 다운스트림 서비스 프로젝트에 VPC를 프로비저닝하는 것이 좋습니다. 백업/복구 어플라이언스는 이러한 VPC 내의 서비스 프로젝트에 설치됩니다. 이를 통해 단일 프로젝트 내에서 워크로드와 백업/복구 어플라이언스를 공동 배치할 수 있습니다.
비공개 Google 액세스: 백업/복구 어플라이언스를 설치하는 각 서브넷에 비공개 Google 액세스를 사용 설정하는 것이 좋습니다. 이렇게 하면 백업/복구 어플라이언스가 Compute Engine, Cloud Storage, Cloud Logging과 같은 API와 통신할 수 있으므로 모니터링 및 알림이 작동하는 데 중요합니다. Google Cloud API에 대한 연결을 간소화하고 개선하려면 구성 옵션 요약 섹션에 설명된 대로
private.googleapis.com의 DNS 확인을 구성하세요. 비공개 Google 액세스의 경우 백업/복구 어플라이언스에서 방화벽 규칙을 구성하여 TCP 포트 443에서 CIDR 범위199.36.153.8/30에 대한 연결을 허용합니다.