백업 및 DR 서비스 배포 설정 및 계획

이 페이지에서는 백업 및 DR 서비스의 초기 활성화를 실행하고 프로젝트의 구성을 설정하는 방법을 설명합니다.

백업 및 DR 아키텍처의 구성요소

백업 및 DR 서비스 아키텍처는 다음 구성요소를 통해 제공됩니다.

  • 관리 콘솔: 관리 콘솔은 백업/복구 어플라이언스의 관리 영역 역할을 합니다. 각 백업 및 DR 배포에는 백업/복구 어플라이언스를 원하는 수만큼 관리하는 단일 관리 콘솔이 포함됩니다. 관리 콘솔은 백업 관리 프로젝트에 배포되며 배포된 리전 내에서 고가용성을 제공하므로 영역 서비스 중단에 대한 복구력을 보장합니다.

  • 백업/복구 어플라이언스: 백업/복구 어플라이언스는 기업 내에서 백업 데이터의 수명 주기를 효율적으로 캡처, 이동, 관리하는 데이터 이동 도구입니다. 백업/복구 어플라이언스는 클라우드 워크로드의 워크로드 항목에 배포됩니다.

  • 백업 및 DR 에이전트: 백업 및 DR 에이전트는 애플리케이션 네이티브 API를 호출하여 프로덕션 애플리케이션에서 영구 증분 방식으로 데이터를 효율적으로 캡처하고 복구 시 애플리케이션 인식을 제공합니다. 에이전트는 보호할 애플리케이션이 있는 애플리케이션 호스트에 설치됩니다. 전체 VM 또는 디스크의 하위 집합만 보호하는 경우에는 백업 및 DR 에이전트가 필요하지 않습니다.

관리 콘솔이 서비스 프로듀서 VPC 네트워크로 활성화됩니다. 이 서비스 제작자 VPC는 비공개 Google 액세스를 사용하여 프로젝트와 통신합니다.

구현 관련 고려사항

다음은 백업 및 DR 서비스를 배포하는 방법에 영향을 미치는 몇 가지 중요한 고려사항입니다.

  • 조직의 복구 시간 목표 (RTO) 요구사항은 무엇인가요? RTO는 데이터 없이 버틸 수 있는 최대 시간입니다. 예를 들어 RTO가 4시간이면 재해 발생 후 4시간 이내에 데이터에 액세스할 수 있어야 합니다.

  • 백업 관리를 중앙에서 통합해야 하나요? 백업을 중앙에서 관리할지 여부를 결정해야 합니다.

    • 중앙 집중식 백업 관리는 모든 비즈니스 라인에서 모든 워크로드의 백업을 관리할 수 있는 단일 관리 콘솔을 갖는 것을 의미합니다. 이렇게 하면 단일 관리 콘솔만 관리하면 되므로 백업을 더 효율적으로 관리할 수 있습니다.
    • 분산된 백업 관리는 비즈니스 라인별로 별도의 관리 콘솔이 있다는 것을 의미합니다. 운영 모드는 조직마다 다릅니다.

  • 백업 사용 사례는 무엇인가요? 프로덕션 리전에서 재해가 발생할 경우 재해 복구 준비를 위해 백업이 필요하나요? 아니면 로컬에서 데이터를 보호하는 것으로 충분하나요? 재해 복구 기능이 필요한 경우 리전 간 백업을 고려해야 합니다. 즉, 한 위치가 재해의 영향을 받더라도 데이터에 계속 액세스할 수 있도록 백업을 여러 위치에 저장합니다.

워크로드가 단일 리전에 있음

리전 내에서 가장 적합한 백업 전략은 요구사항에 따라 다릅니다.

재해 복구 (DR)가 필요하지 않은 경우

가장 빠른 성능과 낮은 비용을 위해 워크로드가 실행되는 리전과 동일한 리전에 관리 콘솔과 백업/복구 어플라이언스를 배포하세요. 백업 이미지를 워크로드와 동일한 리전에 저장합니다.

오프사이트에 백업 사본을 보관하려면 다른 리전에 백업을 저장하거나 이중 리전 또는 멀티 리전 스토리지를 사용하면 됩니다. 다른 리전에 백업을 저장하면 네트워크 및 스토리지 요금이 부과됩니다.

백업과 DR이 모두 필요한 경우

성능을 높이고 비용을 절감하려면 프로덕션 워크로드 리전과 동일한 리전에 관리 콘솔을 배포하고 재해 복구에 사용할 수 있는 리전에 두 번째 관리 콘솔을 배포하세요.

프로덕션 워크로드 리전과 DR 리전 모두에 백업/복구 어플라이언스를 배포하여 복구 시간 목표 (RTO)를 최소화합니다. 이렇게 하면 재해 발생 시 DR 환경이 완전히 사전 프로비저닝되어 사용할 수 있습니다.

프로덕션 리전에 백업 이미지를 저장하고 복사본을 재해 복구(DR) 리전에 저장하거나 이중 리전 또는 멀티 리전 스토리지를 사용하세요. 프로덕션 리전 백업 사본은 더 빠른 성능으로 일상적인 백업 요구사항을 충족할 수 있습니다. DR 리전에 복사된 데이터는 프로덕션 리전이 다운된 경우 워크로드를 복구하는 데 사용할 수 있습니다.

워크로드가 여러 리전에 있음

지역별로 가장 적합한 백업 전략은 요구사항에 따라 다릅니다.

재해 복구 (DR)가 필요하지 않은 경우

가장 빠른 성능과 낮은 비용을 위해 워크로드가 실행되는 리전 중 하나에 관리 콘솔을 배포하세요. 이를 통해 모든 워크로드와 리전을 중앙에서 관리할 수 있습니다.

워크로드가 실행되는 각 리전에 백업/복구 어플라이언스를 하나 이상 배포합니다. 백업을 워크로드와 동일한 리전에 저장합니다.

오프사이트에 백업 사본을 보관하려면 다른 리전에 백업을 저장하거나 이중 리전 또는 멀티 리전 스토리지를 사용하면 됩니다. 다른 리전 또는 멀티 리전에 백업을 저장하면 네트워크 및 스토리지 요금이 청구됩니다.

백업과 DR이 모두 필요한 경우

각 프로덕션 워크로드 리전에 관리 콘솔을 배포하고 DR 리전에 다른 관리 콘솔을 배포합니다.

프로덕션 워크로드 리전과 DR 리전 모두에 백업/복구 어플라이언스를 배포하여 복구 시간 목표 (RTO)를 최소화합니다. 이렇게 하면 재해 발생 시 DR 환경이 완전히 사전 프로비저닝되어 사용 가능합니다.

프로덕션 워크로드 리전에 백업을 저장하고 DR 리전에 사본을 저장하거나 이중 리전 또는 멀티 리전 스토리지를 사용하세요. 프로덕션 리전 백업 사본은 백업 요구사항을 충족하는 데 사용할 수 있습니다.

프로덕션 리전이 다운된 경우 DR의 백업 이미지를 사용하여 워크로드를 복구할 수 있습니다.

Google Cloud 콘솔에서 백업 및 DR 서비스 설정

Google Cloud 콘솔로 이동하여 백업 및 DR 서비스 API를 활성화하고 계정의 권한을 설정합니다.

Google Cloud 백업 및 DR 활성화

백업/복구 어플라이언스 유형

백업 및 DR 서비스는 Compute Engine VM, VMware VM, 데이터베이스, 파일 시스템 등 다양한 워크로드에 최적화된 어플라이언스 유형을 제공합니다. 필요에 가장 적합한 어플라이언스 유형을 선택할 수 있습니다. 워크로드에 가장 적합한 어플라이언스 유형을 선택하는 것이 중요합니다. 백업/복구 어플라이언스가 서비스에 제공되면 백업, 복원, 기타 작업을 항상 실행하고 다시 실행할 준비가 되어 영구적으로 계속 실행됩니다.

백업 및 DR 서비스는 다음과 같은 어플라이언스 유형을 제공합니다.

  • Compute Engine VM 또는 SAP HANA 데이터베이스용 표준: 영구 디스크를 사용하여 Compute Engine 인스턴스 또는 SAP HANA 데이터베이스만 백업하려면 이 옵션을 선택합니다. 이 어플라이언스는 기본적으로 최소 영구 디스크 용량이 10GB인 e2-standard-4 머신 유형을 추가합니다. 이 어플라이언스는 최대 5,000대의 Compute Engine VM을 관리할 수 있습니다.
  • VMware VM 및 기타 데이터베이스 또는 리소스를 위한 표준: 데이터베이스, VMware VM, 기타 리소스를 백업하는 데 최적의 성능을 지원하는 표준 구성을 원하는 경우 이 옵션을 선택합니다. 기본적으로 이 어플라이언스는 n2-standard-16 머신 유형을 추가합니다. 이렇게 하면 균형 잡힌 디스크 용량 4TB가 최소 디스크 용량으로 추가됩니다. 이 어플라이언스는 최대 1,500개의 애플리케이션을 관리할 수 있습니다.

  • VMware VM 및 기타 데이터베이스 또는 리소스를 위한 기본: 데이터베이스, VMware VM, 기타 리소스를 백업하는 데 적당한 성능을 지원하는 기본 구성을 사용하려면 이 옵션을 선택합니다. 기본적으로 이 어플라이언스는 e2-standard-16 머신 유형을 추가합니다. 이 어플라이언스는 최대 1,500개의 애플리케이션을 관리할 수 있습니다. 다음 디스크 유형 중 하나를 선택하여 데이터를 저장할 수 있습니다.

    • 최소 용량 영구 디스크: 이 옵션은 최소 디스크 용량 10GB를 제공합니다. 이 스토리지 유형에서 백업은 영구 디스크 스냅샷으로 저장되며 백업/복구 어플라이언스의 로컬 스토리지를 소비하지 않습니다.
    • 표준 영구 디스크: 효율적인 블록 스토리지를 사용하려면 이 스토리지 유형을 선택합니다. Compute Engine VM 외에도 I/O가 중간 수준 이상인 Google Cloud VMware Engine VM, 데이터베이스 또는 파일 시스템 애플리케이션에 권장합니다. 이렇게 하면 4TB의 영구 디스크 용량이 최소 디스크 용량으로 추가됩니다.
    • SSD 영구 디스크: 빠른 블록 스토리지를 사용하려면 이 스토리지 유형을 선택합니다. Compute Engine VM 외에도 I/O가 매우 높은 Google Cloud VMware Engine, 데이터베이스 또는 파일 시스템 애플리케이션에 권장합니다. 이렇게 하면 4TB의 영구 디스크 용량이 최소 디스크 용량으로 추가됩니다.

어플라이언스를 배포하면 어플라이언스 유형과 관계없이 서비스 계정이 자동으로 생성됩니다. 서비스 계정 페이지에서 서비스 계정을 볼 수 있습니다.

서비스 계정의 이름은 이메일 주소 형식인 my-service-account@my-project.iam.gserviceaccount.com로 표시되며, 여기서 appliance-name은 기기의 이름이고 projectid는 Google Cloud 프로젝트의 ID입니다.

스토리지 유형 선택

백업/복구 어플라이언스는 로컬 어플라이언스 스냅샷 풀에 백업 데이터를 저장합니다. 장기 보관을 위해 객체 스토리지에 복사할 수 있습니다. Google Cloud 에서는 다음 세 가지 유형의 로컬 객체 저장소를 제공합니다.

  • 최소 용량 영구 디스크: 백업 이미지는 백업/복구 어플라이언스의 로컬 스토리지를 사용하지 않는 영구 디스크 스냅샷으로 저장됩니다.

  • 표준 영구 디스크: 이 스토리지 유형은 4TB 영구 디스크부터 시작하는 효율적인 블록 스토리지를 제공합니다. I/O가 중간 수준 이상인 VMware Engine 및 데이터베이스 또는 파일 시스템 애플리케이션에 권장됩니다.

  • SSD 영구 디스크: 이 저장소 유형은 4TB 영구 디스크부터 시작하는 고속 블록 스토리지를 제공합니다. Google CloudVMware Engine VM 및 I/O가 매우 높은 데이터베이스 또는 파일 시스템 애플리케이션에 권장됩니다.

나중에 디스크 풀의 용량을 확장할 수 있습니다.

데이터에 액세스해야 할 것으로 예상되는 필요에 따라 장기 보관이 필요한 백업을 Google Cloud 표준, Nearline, Coldline 스토리지로 이동할 수 있습니다.

백업 및 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 확인을 구성해 보세요. 또한 TCP 포트 443에서 CIDR 범위 199.36.153.8/30에 대한 연결을 허용하도록 백업/복구 어플라이언스의 방화벽 규칙을 구성합니다.

방화벽 구성

백업 및 DR 서비스로의 인그레스에 필요한 다음 방화벽 규칙이 자동으로 추가됩니다.

목적 소스 타겟 포트 (TCP)
지원 트래픽 (어플라이언스 지원) SSH 클라이언트를 실행하는 호스트 백업/복구 어플라이언스 26
iSCSI 백업 (호스트에서 어플라이언스) 백업 및 DR 에이전트를 실행하는 호스트 백업/복구 어플라이언스 3260
StreamSnap 트래픽 (어플라이언스 간) 백업/복구 어플라이언스 백업/복구 어플라이언스 5107
관리 콘솔에 대한 백업/복구 어플라이언스 연결 백업/복구 어플라이언스 IP 또는 서브넷 *.backupdr.googleusercontent.com 443

이 규칙을 구성하는 방법에 관한 자세한 내용은 백업 및 DR 서비스 배포 준비를 참고하세요.

백업 및 DR 에이전트를 실행하는 호스트의 경우 인그레스 방화벽 규칙과의 연결을 허용하려면 다음 TCP 포트를 수동으로 추가해야 합니다.

목적 소스 타겟 포트 (TCP)
에이전트 트래픽 (어플라이언스 - 호스트) 백업/복구 어플라이언스 백업 및 DR 에이전트를 실행하는 호스트 5106

백업 트래픽에 NFS를 사용하는 호스트 또는 마운트에 NFS를 사용하는 VMware Engine에서 실행되는 ESX 호스트의 경우 다음 TCP 및 UDP 포트를 수동으로 추가하여 인그레스 방화벽 규칙과의 연결을 허용해야 합니다.

목적 소스 타겟 포트 (TCP/UDP)
NFS 백업 또는 마운트 에이전트를 실행하는 호스트 또는 마운트를 실행하는 ESXi 호스트 백업/복구 어플라이언스 111, 756, 2049, 4001, 4045

이 작업 중에 사용되는 권한 목록은 백업 및 DR 설치 권한 참조를 참고하세요.

지원되는 리전

다음 섹션에는 관리 콘솔 및 백업/복원 어플라이언스 지원 리전이 나와 있습니다.

관리 콘솔 지원 리전

백업 및 DR 서비스는 모든Google Cloud 리전에서 지원되는 워크로드를 백업하는 데 사용할 수 있지만 관리 콘솔은 다음 리전에서만 활성화할 수 있습니다. 관리 콘솔은 다른 지역으로 이동할 수 없습니다.

지리적 지역 리전 이름 리전 설명
미주
us-central1 아이오와 잎 아이콘 낮은 CO2
us-east1 사우스캐롤라이나
us-east4 북버지니아
us-west1 오리건 잎 아이콘 낮은 CO2
us-west2 로스앤젤레스
us-west4 라스베이거스
southamerica-east1 상파울루 잎 아이콘 낮은 CO2
유럽
europe-west1 벨기에 잎 아이콘 낮은 CO2
europe-west2 런던 잎 아이콘 낮은 CO2
europe-west3 프랑크푸르트 잎 아이콘 낮은 CO2
europe-west4 네덜란드 잎 아이콘 낮은 CO2
아시아 태평양
asia-east1 타이완
asia-southeast1 싱가포르
australia-southeast1 시드니
인도
asia-south1 뭄바이
asia-south2 델리

백업/복구 어플라이언스 지원 리전

백업 및 DR 서비스 백업/복구 어플라이언스는 모든 Google Cloud 존에 배포할 수 있습니다. 백업/복구 어플라이언스 배포를 실행하는 워크플로 서비스는 나열된 리전에서 지원됩니다. 백업/복구 어플라이언스가 배포된 리전에서 워크플로 서비스를 사용할 수 없는 경우 백업 및 DR 서비스는 기본적으로 us-central1 리전에서 워크플로를 실행합니다(어플라이언스 자체는 선택한 리전에서 계속 생성됨). 다른 리전에서 리소스를 만들지 못하도록 설정된 조직 정책이 있는 경우 us-central1 리전에서 리소스를 만들 수 있도록 조직 정책을 일시적으로 업데이트해야 합니다. 백업/복구 어플라이언스를 배포한 후 us-central1 리전을 제한할 수 있습니다.

다음 단계