이 페이지에서는 Backup and DR Service를 초기 활성화하고 프로젝트 구성을 설정하는 방법을 설명합니다.
백업 및 DR 아키텍처의 구성요소
백업 및 DR 서비스 아키텍처는 다음 구성요소를 통해 제공됩니다.
관리 콘솔: 관리 콘솔은 백업/복구 어플라이언스의 관리 플레인 역할을 합니다. 각 백업 및 DR 배포에는 원하는 수의 백업/복구 어플라이언스를 관리하는 단일 관리 콘솔이 포함됩니다. 관리 콘솔은 백업 관리 프로젝트에 배포되며 배포된 리전 내에서 고가용성을 제공하여 영역 서비스 중단에 대한 복원력을 제공합니다.
백업/복구 어플라이언스: 백업/복구 어플라이언스는 기업 내에서 백업 데이터의 수명 주기를 효율적으로 캡처, 이동, 관리하는 데이터 이동기입니다. 백업/복구 어플라이언스는 클라우드 워크로드의 워크로드 엔티티에 배포됩니다.
백업 및 DR 에이전트: 백업 및 DR 에이전트는 애플리케이션 네이티브 API를 호출하여 영구 증분 방식으로 프로덕션 애플리케이션에서 데이터를 효율적으로 캡처하고 복구 시 애플리케이션 인식을 제공합니다. 에이전트는 보호할 애플리케이션이 있는 애플리케이션 호스트에 설치됩니다. 전체 VM 또는 일부 디스크만 보호하는 경우에는 Backup and DR 에이전트가 필요하지 않습니다.
관리 콘솔이 서비스 프로듀서 VPC 네트워크에 활성화됩니다. 이 서비스 제작자 VPC는 비공개 Google 액세스를 사용하여 프로젝트와 통신합니다.
관리 서버와 어플라이언스 간, 어플라이언스 간, 어플라이언스와 호스트 에이전트 간의 통신은 상호 TLS 인증으로 보호됩니다.
구현 관련 고려사항
다음은 백업 및 DR 서비스 배포 방법에 영향을 미치는 몇 가지 중요한 고려사항입니다.
조직의 복구 시간 목표 (RTO) 요구사항은 무엇인가요? RTO는 데이터가 없는 상태로 있을 수 있는 최대 시간입니다. 예를 들어 RTO가 4시간인 경우 재해 발생 후 4시간 이내에 데이터에 액세스할 수 있어야 합니다.
백업 관리를 중앙 집중화해야 하나요? 백업을 중앙에서 관리할지 여부를 결정해야 합니다.
- 중앙 집중식 백업 관리는 모든 사업부의 모든 워크로드에 대한 백업을 관리할 수 있는 단일 관리 콘솔이 있음을 의미합니다. 단일 관리 콘솔만 관리하면 되므로 백업을 관리하는 데 더 효율적일 수 있습니다.
- 분산 백업 관리란 각 비즈니스 라인에 별도의 관리 콘솔이 있다는 의미입니다. 운영 모드는 조직마다 다릅니다.
백업 사용 사례는 무엇인가요? 프로덕션 리전에서 재해가 발생할 경우 재해 복구 대비를 위해 백업이 필요한가요? 아니면 로컬에서 데이터를 보호하는 것으로 충분한가요? 재해 복구 기능이 필요한 경우 리전 간 백업을 고려해야 합니다. 즉, 한 위치가 재해의 영향을 받더라도 데이터에 계속 액세스할 수 있도록 여러 위치에 백업을 저장합니다.
워크로드가 단일 리전에 있음
리전 내에서 가장 적합한 백업 전략은 요구사항에 따라 다릅니다.
재해 복구 (DR)가 필요하지 않은 경우
최고의 성능과 최저 비용을 위해 워크로드가 실행되는 동일한 리전에 관리 콘솔과 백업/복구 어플라이언스를 배포하세요. 워크로드와 동일한 리전에 백업 이미지를 저장합니다.
오프사이트에 백업 사본을 저장하려면 다른 리전에 백업을 저장하거나 이중 리전 또는 멀티 리전 스토리지를 사용하면 됩니다. 다른 리전에 백업을 저장하면 네트워크 및 스토리지 요금이 발생합니다.
백업과 DR이 모두 필요한 경우
최고의 성능과 최저 비용을 위해 프로덕션 워크로드 리전과 동일한 리전에 관리 콘솔을 배포하고 재해 복구에 사용할 수 있는 리전에 두 번째 관리 콘솔을 배포합니다.
복구 시간 목표 (RTO)를 최소화하려면 프로덕션 워크로드 리전과 DR 리전 모두에 백업/복구 어플라이언스를 배포합니다. 이렇게 하면 재해 발생 시 DR 환경이 완전히 사전 프로비저닝되고 사용할 수 있습니다.
백업 이미지를 프로덕션 리전에 저장하고 복구 DR 리전에 사본을 저장하거나 이중 리전 또는 멀티 리전 스토리지를 사용합니다. 프로덕션 리전 백업 사본은 더 빠른 성능으로 일상적인 백업 요구사항을 충족할 수 있습니다. DR 리전에 복사된 데이터는 프로덕션 리전이 다운된 경우 워크로드를 복구하는 데 사용할 수 있습니다.
워크로드가 여러 리전에 있음
리전 간 최적의 백업 전략은 요구사항에 따라 다릅니다.
재해 복구 (DR)가 필요하지 않은 경우
성능을 극대화하고 비용을 절감하려면 워크로드가 실행되는 리전 중 하나에 관리 콘솔을 배포하세요. 이를 통해 모든 워크로드와 리전에서 중앙 집중식 관리가 가능합니다.
워크로드가 실행되는 각 리전에 백업/복구 어플라이언스를 하나 이상 배포합니다. 워크로드와 동일한 리전에 백업을 저장합니다.
오프사이트에 백업 사본을 저장하려면 다른 리전에 백업을 저장하거나 이중 리전 또는 멀티 리전 스토리지를 사용하면 됩니다. 다른 리전 또는 멀티 리전에 백업을 저장하면 네트워크 및 스토리지 요금이 발생합니다.
백업과 DR이 모두 필요한 경우
프로덕션 워크로드 리전에 관리 콘솔을 배포하고 DR 리전에 다른 관리 콘솔을 배포합니다.
복구 시간 목표 (RTO)를 최소화하려면 프로덕션 워크로드 리전과 DR 리전 모두에 백업/복구 어플라이언스를 배포합니다. 이렇게 하면 재해 발생 시 DR 환경이 완전히 사전 프로비저닝되고 사용할 수 있습니다.
프로덕션 워크로드 리전에 백업을 저장하고 DR 리전에 사본을 저장하거나 이중 리전 또는 멀티 리전 스토리지를 사용합니다. 백업 요구사항을 충족하는 데 프로덕션 리전 백업 사본을 사용할 수 있습니다.
DR의 백업 이미지는 프로덕션 리전이 다운된 경우 워크로드를 복구하는 데 사용할 수 있습니다.
Google Cloud 콘솔에서 백업 및 DR 서비스 설정
Google Cloud 콘솔로 이동하여 백업 및 DR 서비스 API를 활성화하고 계정의 권한을 설정합니다.
백업/복구 어플라이언스 유형
Backup and DR Service는 다양한 워크로드(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를 제공합니다. 이 스토리지 유형에서 백업은 Persistent Disk 스냅샷으로 저장되며 백업/복구 어플라이언스의 로컬 스토리지를 소비하지 않습니다.
- 표준 영구 디스크: 효율적인 블록 스토리지를 사용하려면 이 스토리지 유형을 선택하세요. 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 영구 디스크부터 시작하는 고속 블록 스토리지를 제공합니다. VMware Engine VM 및 I/O가 매우 높은 데이터베이스 또는 파일 시스템 애플리케이션에 권장됩니다. Google Cloud
나중에 디스크 풀의 용량을 확장할 수 있습니다.
데이터 액세스 예상 필요에 따라 장기 보관이 필요한 백업을 Google Cloud Standard, 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 서비스 배포 준비를 참고하세요.
Backup and 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 리전에서 지원되는 워크로드를 백업할 수 있지만 관리 콘솔은 다음 리전에서만 활성화할 수 있습니다.
| 지리적 지역 | 리전 이름 | 리전 설명 | |
|---|---|---|---|
| 북미 | |||
northamerica-northeast1 * |
몬트리올 |
 낮은 CO2
|
|
northamerica-northeast2 |
토론토 |
낮은 CO2
|
|
us-central1 |
아이오와 |
낮은 CO2
|
|
us-east1 |
사우스캐롤라이나 | ||
us-east4 |
북버지니아 | ||
us-east5 |
콜럼버스 | ||
us-south1 |
댈러스 |
낮은 CO2
|
|
us-west1 |
오리건 |
낮은 CO2 |
|
us-west2 |
로스앤젤레스 | ||
us-west3 |
솔트레이크시티 | ||
us-west4 |
라스베이거스 | ||
northamerica-south1 * |
케레타로 | ||
| 남미 | |||
southamerica-east1 |
상파울루 |
낮은 CO2
|
|
southamerica-west1 |
산티아고 |
낮은 CO2
|
|
| 유럽 | |||
europe-central2 |
바르샤바 | ||
europe-north1 |
핀란드 |
낮은 CO2
|
|
europe-southwest1 |
마드리드 |
낮은 CO2
|
|
europe-west1 |
벨기에 |
낮은 CO2
|
|
europe-west2 |
런던 |
낮은 CO2
|
|
europe-west3 |
프랑크푸르트 |
낮은 CO2
|
|
europe-west4 |
네덜란드 |
낮은 CO2
|
|
europe-west6 |
취리히 |
낮은 CO2
|
|
europe-west8 |
밀라노 | ||
europe-west9 |
파리 |
낮은 CO2
|
|
europe-west10 |
베를린 |
낮은 CO2
|
|
europe-west12 |
토리노 | ||
| 중동 | |||
me-central1 |
도하 | ||
me-central2 |
담맘 | ||
me-west1 |
이스라엘 | ||
| 아프리카 | |||
africa-south1 |
요하네스버그 | ||
| 아시아 태평양 | |||
asia-east1 |
타이완 | ||
asia-east2 |
홍콩 | ||
asia-northeast1 |
도쿄 | ||
asia-northeast2 * |
오사카 | ||
asia-northeast3 |
서울 | ||
asia-southeast1 |
싱가포르 | ||
asia-southeast2 |
자카르타 | ||
australia-southeast1 |
시드니 | ||
australia-southeast2 |
멜버른 | ||
| 인도 | |||
asia-south1 |
뭄바이 | ||
asia-south2 |
델리 |
* 몬트리올, 오사카, 케레타로의 경우 물리적 데이터 센터 1~2곳에 영역 3개가 있습니다. 드물지만 재해 발생 시 이러한 리전에 저장된 데이터가 손실될 수 있습니다.
백업/복구 어플라이언스 지원 리전
백업/복구 어플라이언스는 모든 Google Cloud 영역에 배포할 수 있습니다.
백업/복구 어플라이언스 배포를 실행하는 워크플로 서비스는 나열된 리전에서 지원됩니다. 백업/복구 어플라이언스가 배포된 리전에서 워크플로 서비스를 사용할 수 없는 경우 백업 및 DR 서비스는 기본적으로 us-central1 리전에서 워크플로를 실행합니다(어플라이언스 자체는 선택한 리전에서 계속 생성됨). 다른 리전에서 리소스 생성을 방지하도록 설정된 조직 정책이 있는 경우 us-central1 리전에서 리소스 생성을 허용하도록 조직 정책을 일시적으로 업데이트해야 합니다. 백업/복구 어플라이언스를 배포한 후 us-central1 리전을 제한할 수 있습니다.