이 문서는 Google Cloud의 재해 복구(DR)에 대해 설명하는 시리즈 중 2부입니다. 이 부분에서는 Google Cloud 제품과 여러 플랫폼에서 작동하는 제품 모두에서 DR 계획의 구성 요소로 사용할 수 있는 서비스 및 제품을 설명합니다.
시리즈는 다음 세 부분으로 구성됩니다.
- 재해 복구 계획 가이드
- 재해 복구 구성 요소(이 도움말)
- 데이터의 재해 복구 시나리오
- 애플리케이션의 재해 복구 시나리오
- 지역별로 제한된 워크로드의 재해 복구 설계
- 재해 복구 사용 사례: 지역별로 제한된 데이터 분석 애플리케이션
- 클라우드 인프라 서비스 중단의 재해 복구 설계
소개
Google Cloud에는 재해 복구(DR) 아키텍처의 일부로 사용할 수 있는 다양한 제품이 있습니다. 이 섹션에서는 Google Cloud DR 구성 요소로 가장 일반적으로 사용되는 제품의 DR 관련 기능에 대해 설명합니다.
이러한 서비스에는 대부분 고가용성(HA) 기능이 있습니다. HA는 DR과 완전히 겹치지는 않지만 HA의 많은 목표는 DR 계획 설계에도 적용됩니다. 예를 들어 HA 기능을 활용하면 가동 시간을 최적화하고 단일 VM 장애와 같은 소규모 장애의 영향을 완화할 수 있는 아키텍처를 설계할 수 있습니다. DR과 HA의 관계에 대한 자세한 내용은 재해 복구 계획 가이드를 참조하세요.
다음 섹션에서는 이러한 Google Cloud DR 구성 요소에 대해 설명하고 이러한 구성 요소가 DR 목표를 구현하는 데 어떻게 도움이 되는지 설명합니다.
컴퓨팅 및 스토리지
Compute Engine |
|
Cloud Storage |
|
GKE |
|
Compute Engine
Compute Engine은 가상 머신(VM) 인스턴스를 제공하며 Google Cloud의 주축 역할을 합니다. Compute Engine 인스턴스의 구성, 시작, 모니터링 외에도 일반적으로 DR 계획을 구현하기 위해 다양한 관련 기능을 사용합니다.
DR 시나리오의 경우 삭제 보호 플래그를 설정하여 실수로 인한 VM 삭제를 방지할 수 있습니다. 이는 특히 데이터베이스와 같은 상태 저장 서비스를 호스팅하는 경우에 유용합니다. 낮은 RTO 및 RPO 값을 충족하려면 강력한 시스템 설계를 위한 권장사항을 따르세요.
애플리케이션이 사전 설치되어 있는 인스턴스를 구성한 다음 해당 구성을 커스텀 이미지로 저장할 수 있습니다. 커스텀 이미지는 달성하려는 RTO를 반영할 수 있습니다.
인스턴스 템플릿
Compute Engine 인스턴스 템플릿을 사용하여 VM의 구성 세부정보를 저장한 다음 기존 인스턴스 템플릿에서 인스턴스를 생성할 수 있습니다. 이 템플릿을 사용하면 필요한 만큼 인스턴스를 실행할 수 있으며 DR 대상 환경을 구축해야 할 때 원하는 방식으로 정확하게 구성할 수 있습니다. 인스턴스 템플릿은 전역적으로 복제되므로 Google Cloud 어디에서나 동일한 구성으로 인스턴스를 다시 만들 수 있습니다.
커스텀 이미지를 사용하거나 기존 VM 인스턴스를 기반으로 인스턴스 템플릿을 만들 수 있습니다.
이 문서의 뒤쪽에 있는 이미지 구성 및 배포 속도 조정 섹션에서 Compute Engine 이미지 사용에 대한 자세한 내용을 제공합니다.
관리형 인스턴스 그룹
관리형 인스턴스 그룹은 Cloud Load Balancing(이 문서의 뒷부분에서 설명)과 함께 작동하여 영역 간에 복사된 동일하게 구성된 인스턴스 그룹에 트래픽을 분산시킵니다. 관리형 인스턴스 그룹은 자동 확장 및 자동 복구와 같은 기능을 허용하며 여기에서 관리형 인스턴스 그룹이 인스턴스를 자동으로 삭제하고 다시 만들 수 있습니다.
예약
Compute Engine에서는 추가 GPU 또는 로컬 SSD를 사용하거나 사용하지 않고 커스텀 머신 유형이나 사전 정의된 머신 유형을 사용해 특정 영역에서 VM 인스턴스를 예약할 수 있습니다. DR용 중요 작업의 워크로드 용량을 확보하려면 DR 대상 영역에서 예약을 만들어야 합니다. 예약이 없으면 복구 시간 목표를 달성하는 데 필요한 주문형 용량을 얻지 못할 수 있습니다. 예약은 콜드, 또는 핫 DR 시나리오에서 유용할 수 있습니다. 예약을 만들면 완전히 구성하여 배포할 필요 없이 장애 조치용 복구 리소스를 유지하여 더 낮은 RTO 요구사항을 충족할 수 있습니다.
영구 디스크 및 스냅샷
영구 디스크는 인스턴스에서 액세스할 수 있는 내구성 있는 네트워크 저장소 기기입니다. 인스턴스와 독립적이므로 인스턴스를 삭제한 후에도 영구 디스크를 분리하고 이동하여 데이터를 보관할 수 있습니다.
재난 발생시 영구 디스크를 다시 만들고 재현할 수 있는 Compute Engine VM의 증분 백업 또는 스냅샷을 지역 간에 복사하여 사용할 수 있습니다. 또한 영구 디스크 스냅샷 만들기로 사용자 오류로 인한 데이터 손실을 방지할 수 있습니다. 스냅샷은 증분적이며, 실행 중인 인스턴스에 연결된 디스크를 스냅샷으로 작성할 경우에도 몇 분이면 생성됩니다.
영구 디스크는 장비 고장 시 데이터를 보호하고, 데이터 센터 유지보수 이벤트를 통해 데이터 가용성을 보장하는 중복 기능을 기본 제공합니다. 영구 디스크는 영역 또는 리전별로 사용됩니다. 리전 영구 디스크는 리전의 두 영역 간에 쓰기를 복제합니다. 영역 장애 시 백업 VM 인스턴스는 보조 영역에 있는 리전 영구 디스크를 강제 연결할 수 있습니다. 자세한 내용은 리전 영구 디스크를 사용하는 고가용성 옵션을 참조하세요.
라이브 마이그레이션
실시간 이전은 소프트웨어 또는 하드웨어 업데이트와 같은 호스트 시스템 이벤트가 발생하더라도 가상 머신 인스턴스가 계속 실행되게 합니다. Compute Engine은 사용자가 VM을 재부팅할 필요 없이 동일 영역에서 실행 중인 인스턴스를 또 다른 호스트로 라이브 이전합니다. 이렇게 해서 Google은 사용자의 VM에 영향을 주지 않으면서도 인프라를 보호하고 안정적인 상태로 유지하는 데 반드시 필요한 유지관리를 수행할 수 있습니다.
가상 디스크 가져오기 도구
가상 디스크 가져오기 도구를 사용하면 VMDK, VHD, RAW 등의 파일 형식을 가져와서 새 Compute Engine 가상 머신을 만들 수 있습니다. 이 도구를 사용하면 온프레미스 가상 머신과 구성이 동일한 Compute Engine 가상 머신을 만들 수 있습니다. 이는 이미 이미지에 설치된 소프트웨어의 소스 바이너리에서 Compute Engine 이미지를 구성할 수 없는 경우에 좋은 방법입니다.
Cloud Storage
Cloud Storage는 백업 파일을 저장하는 데 이상적인 객체 저장소입니다. 다음 다이어그램에 설명된 대로 특정 사용 사례에 적합한 여러 가지 스토리지 클래스가 제공됩니다.
DR 시나리오에서는 Nearline, Coldline, Archive Storage가 특히 유용합니다. 이러한 스토리지 클래스를 사용하면 표준 스토리지에 비해 스토리지 비용을 줄일 수 있습니다. 그러나 이러한 클래스에 저장된 데이터 또는 메타데이터를 검색하는 데는 추가 비용이 들며 최소 저장 기간에도 요금이 부과됩니다. Nearline은 월 1회 액세스가 가능한 백업 시나리오를 위해 설계되었으므로 비용을 낮게 유지하면서 정기적인 DR 스트레스 테스트를 수행하는 데 이상적입니다.
Nearline, Coldline, Archive는 모두 액세스 빈도가 낮은 경우에 최적화되어 있으며 가격 책정 모델은 이를 염두에 두고 설계되었습니다. 따라서 최소 저장 기간이 청구되며 클래스의 최소 저장 기간보다 이전에 이러한 클래스에서 데이터 또는 메타데이터를 검색하는 데 요금이 발생합니다.
Cloud Storage 버킷의 데이터를 실수로 또는 악의적으로 삭제하지 못하도록 보호하려면 소프트 삭제 기능을 사용하여 지정된 기간 동안 삭제되거나 덮어쓴 객체를 보존하면 됩니다.
Storage Transfer Service를 사용하면 Amazon S3 또는 HTTP 기반 소스에서 Cloud Storage로 데이터를 가져올 수 있습니다. DR 시나리오에서 Storage Transfer Service를 사용하여 다음을 수행할 수 있습니다.
- 다른 저장소 제공업체의 데이터를 Cloud Storage 버킷에 백업합니다.
- 이중 리전이나 멀티 리전의 버킷에서 단일 리전의 버킷으로 데이터를 이동하여 백업 저장 비용을 줄입니다.
Filestore
Filestore 인스턴스는 Compute Engine 인스턴스 또는 GKE 클러스터에서 실행되는 애플리케이션이 사용할 완전 관리형 NFS 파일 서버입니다.
Filestore 인스턴스는 영역 단위로 존재하며 영역 간 복제를 지원하지 않습니다. Filestore 인스턴스가 위치하는 영역이 다운된 경우에는 인스턴스를 사용할 수 없습니다. gsutil rsync 명령어를 사용하여 Filestore 볼륨을 다른 리전의 Filestore 인스턴스에 동기화해 데이터를 주기적으로 백업하는 것이 좋습니다. Compute Engine 인스턴스나 GKE 클러스터에서 실행되도록 작업을 예약해야 합니다.
DR 시나리오에서 애플리케이션은 복원 프로세스가 완료될 때까지 기다리지 않고 장애 조치 리전에서 Filestore로 전환하여 Filestore 볼륨에 빠르게 다시 액세스할 수 있습니다. 이 DR 솔루션의 RTO 값은 주로 예약된 작업 빈도에 좌우됩니다.
GKE
GKE는 컨테이너식 애플리케이션을 배포하기 위한 관리형 환경으로 프로덕션에 즉시 사용 가능합니다. GKE를 사용하면 HA 시스템을 조정할 수 있으며 다음과 같은 기능이 포함됩니다.
- 노드 자동 복구. 노드가 장시간(약 10분) 동안 연속으로 상태 확인에 실패하면 GKE는 해당 노드에 대한 복구 프로세스를 시작합니다.
- 활성 여부 조사. 포드가 실행 중임을 GKE에 주기적으로 알리는 활성 여부 조사를 지정할 수 있습니다. 포드가 조사에 실패하면 포드를 다시 시작할 수 있습니다.
- 영구 볼륨. 데이터베이스는 컨테이너의 수명을 초과하여 지속될 수 있어야 합니다. Compute Engine 영구 디스크에 매핑되는 영구 볼륨 추상화를 사용하면 개별 컨테이너와 독립적으로 스토리지 가용성을 유지할 수 있습니다.
- 다중 영역 및 지역 클러스터. Kubernetes 리소스를 한 리전 내의 여러 영역에 배포할 수 있습니다.
- 멀티 클러스터 게이트웨이를 사용하면 서로 다른 리전의 여러 GKE 클러스터에서 공유 부하 분산 리소스를 구성할 수 있습니다.
- Backup for GKE를 사용하면 GKE 클러스터에서 워크로드를 백업 및 복원할 수 있습니다.
네트워킹 및 데이터 전송
 Cloud Load Balancing |
|
Traffic Director |
|
Cloud DNS |
|
Cloud Interconnect
|
|
Cloud Load Balancing
Cloud Load Balancing은 사용자 요청을 인스턴스 집합에 분산하여 Compute Engine에 HA를 제공합니다. 장애가 발생한 인스턴스로 트래픽이 라우팅되지 않도록 인스턴스의 작업 가능 여부를 판단하는 상태 확인 기능을 사용하여 Cloud Load Balancing을 구성할 수 있습니다.
Cloud Load Balancing은 Compute Engine 인스턴스 앞에 전역으로 액세스할 수 있는 단일 IP 주소를 제공합니다. 애플리케이션은 다른 지역(예: 유럽 및 미국)에서 실행중인 인스턴스가 있을 수 있으며 최종 사용자는 가장 가까운 인스턴스 세트로 연결됩니다. 인터넷에 노출된 서비스에 대한 부하 분산을 제공하는 것 외에도 비공개 부하 분산 IP 주소 배후의 서비스를 위해 내부 부하 분산을 구성할 수 있습니다. 이 IP 주소는 Virtual Private Cloud(VPC) 내부의 VM 인스턴스에서만 액세스할 수 있습니다.
Traffic Director
Traffic Director로 서비스 메시용 완전 관리형 트래픽 제어 영역을 배포할 수 있습니다. Traffic Director는 Compute Engine과 GKE 모두에서 실행되는 서비스 프록시의 구성을 관리합니다. HA를 위해 여러 리전에 서비스를 배포할 수 있습니다. Traffic Director는 서비스 상태 확인을 오프로드하고 서비스 프록시의 장애 조치 구성을 시작하여 트래픽을 정상 인스턴스로 리디렉션합니다.
또한 Traffic Director는 고급 트래픽 제어 개념, 회로 차단, 결함 주입도 지원합니다. 회로 차단 기능을 사용하면 특정 서비스에 대한 요청에 제한을 적용하여 제한점에 이를 경우 요청이 서비스에 도달하지 못하도록 함으로써 서비스 성능이 더 이상 저하되지 않도록 할 수 있습니다. 결함 주입 기능을 사용하면 Traffic Director가 서비스에 지연을 발생시키거나 일부 요청을 취소함으로써 요청 지연 또는 취소 시의 서비스 내결함성을 테스트할 수 있습니다.
Cloud DNS
Cloud DNS는 자동화된 복구 프로세스의 일부로 DNS 항목을 프로그래매틱 방식으로 관리할 수 있는 방법을 제공합니다. Cloud DNS는 Anycast 네임서버의 글로벌 네트워크를 통해 DNS 영역을 전 세계의 중복 위치에서 제공하여 사용자에게 고가용성과 짧은 지연 시간을 제공합니다.
온프레미스에서 DNS 항목을 관리하도록 선택한 경우 Google Cloud의 VM이 Cloud DNS 전달을 통해 이러한 주소를 확인하도록 할 수 있습니다.
Cloud DNS는 DNS 요청에 응답하는 방법을 구성하는 정책을 지원합니다. 예를 들어 고가용성을 제공하거나 지리적 위치를 기반으로 DNS 요청을 라우팅하도록 라우팅 정책을 구성하여 백업 구성에 대한 장애 조치를 사용 설정할 수 있습니다.
Cloud Interconnect
Cloud Interconnect는 다른 소스의 정보를 Google Cloud로 이동하는 방법을 제공합니다. 이 제품에 대해서는 나중에 Google Cloud와의 데이터 전송에서 설명합니다.
관리 및 모니터링
| Cloud 상태 대시보드 |
|
Google Cloud Observability |
|
Cloud 상태 대시보드
Cloud 상태 대시보드에는 Google Cloud 서비스의 현재 가용성이 표시됩니다. 이 페이지에서 상태를 확인할 수 있으며, 서비스에 대한 뉴스가 있을 때마다 업데이트되는 RSS 피드를 구독할 수도 있습니다.
Cloud Monitoring
Cloud Monitoring은 Google Cloud, AWS, 호스팅된 업타임 프로브, 애플리케이션 계측, 기타 다양한 애플리케이션 구성요소에서 측정항목, 이벤트, 메타데이터를 수집합니다. 관리자에게 적시에 업데이트를 제공하기 위해 Slack 또는 Pagerduty와 같은 타사 도구에 알림을 보내도록 알림 기능을 구성할 수 있습니다. DR에 Cloud Monitoring을 사용하는 또 다른 방법은 Pub/Sub 싱크를 구성하고 Cloud Functions를 사용하여 Cloud Monitoring 알림에 대한 대응으로 자동화된 프로세스를 트리거하는 것입니다.
크로스 플랫폼 DR 구성 요소
둘 이상의 플랫폼에서 워크로드를 실행하는 경우 운영 오버헤드를 줄이는 방법은 사용중인 모든 플랫폼에서 작동하는 도구를 선택하는 것입니다. 이 섹션에서는 플랫폼과 독립적이라서 플랫폼 간 DR 시나리오를 지원하는 몇 가지 도구 및 서비스에 대해 설명합니다.
선언적 템플릿 도구
선언적 템플릿 도구를 사용하면 플랫폼 간 인프라 배포를 자동화할 수 있습니다. Terraform은 널리 사용되는 선언적 템플릿 도구입니다.
구성 관리 도구
대규모 또는 복잡한 DR 인프라의 경우 Chef 및 Ansible과 같은 플랫폼 독립적인 소프트웨어 관리 도구를 사용하는 것이 좋습니다. 이러한 도구를 사용하면 컴퓨팅 작업 부하가 어디에 있더라도 재현 가능한 구성을 적용할 수 있습니다.
객체 스토리지
일반적인 DR 패턴은 서로 다른 클라우드 공급자의 객체 스토리지에 객체 사본을 갖는 것입니다. 이를 위한 크로스 플랫폼 도구 중 하나로, 오픈소스 Python 라이브러리인 boto를 사용하여 Amazon S3 및 Cloud Storage와 상호 작용할 수 있습니다.
조정자 도구
또한 DR 구성 요소로 컨테이너를 고려해 볼 수 있습니다. 컨테이너는 서비스를 패키지화하고 플랫폼 간 일관성을 도입하는 방법입니다.
컨테이너로 작업하는 경우 일반적으로 조정자를 사용합니다. Kubernetes를 사용하면 Google Cloud 내에서 컨테이너를 관리할 수 있을 뿐만 아니라(GKE 사용) 여러 플랫폼에서 컨테이너 기반 워크로드도 조정할 수 있습니다. Google Cloud, AWS, Microsoft Azure는 모두 관리형 버전의 Kubernetes를 제공합니다.
서로 다른 클라우드 플랫폼에서 실행되는 Kubernetes 클러스터에 트래픽을 분산시키려면 가중치가 있는 레코드를 지원하고 상태 확인을 통합하는 DNS 서비스를 사용할 수 있습니다.
또한 대상 환경으로 이미지를 가져올 수 있어야 합니다. 즉 재난 발생시 이미지 레지스트리에 액세스할 수 있어야 합니다. 플랫폼과 독립적인 좋은 옵션은 Artifact Registry입니다.
데이터 전송
데이터 전송은 교차 플랫폼 DR 시나리오의 핵심 구성 요소입니다. DR 데이터 전송 시나리오에서 요구하는 사실적인 모델을 사용하여 교차 플랫폼 DR 시나리오를 설계, 구현 및 테스트해야 합니다. 데이터 전송 시나리오에 대해서는 다음 섹션에서 설명합니다.
DR용 패턴
이 섹션에서는 앞에서 설명한 구성 요소를 기반으로 DR 아키텍처의 가장 일반적인 패턴 중 일부를 설명합니다.
Google Cloud와의 데이터 전송
DR 계획에서 고려할 중요한 측면의 하나는 Google Cloud와 데이터를 주고받는 전송 속도입니다. 이는 DR 계획이 온프레미스에서 Google Cloud로, 또는 다른 클라우드 제공업체에서 Google Cloud로의 데이터 이동을 기반으로 하는 경우에 중요합니다. 이 섹션에서는 우수한 처리량을 보장할 수 있는 네트워킹 및 Google Cloud 서비스에 대해 설명합니다.
온프레미스 또는 다른 클라우드 환경에 있는 워크로드의 복구 사이트로 Google Cloud를 사용하는 경우 다음의 주요 사항을 고려하세요.
- Google Cloud에 어떻게 연결하나요?
- 사용자와 상호 연결 제공업체 간에 얼마나 많은 대역폭이 있나요?
- 제공업체가 Google Cloud에 직접 제공하는 대역폭은 무엇인가요?
- 해당 링크를 사용하여 전송되는 다른 데이터에는 무엇이 있나요?
공용 인터넷 연결을 사용하여 데이터를 전송하는 경우 ISP의 용량 및 라우팅에 제한이 있으므로 네트워크 처리량을 예측할 수 없습니다. ISP는 제한된 SLA를 제공하거나 전혀 제공하지 않을 수 있습니다. 하지만 이런 연결은 상대적으로 비용이 저렴합니다.
Cloud Interconnect는 Google과 Google Cloud에 연결하는 몇 가지 옵션을 제공합니다.
- Cloud VPN을 사용하면 Google Cloud VPC 네트워크와 대상 네트워크 사이에 IPsec VPN 터널을 만들 수 있습니다. 두 네트워크 사이에서 이동되는 트래픽은 한쪽 VPN 게이트웨이에서 암호화된 후 다른 쪽 VPN 게이트웨이에서 복호화됩니다. HA VPN을 사용하면 SLA가 99.99%인 고가용성 VPN 연결을 만들 수 있으며 중복 VPN을 만들 때보다 설정도 간편합니다.
- 다이렉트 피어링은 Google의 공개 IP 주소에 대한 네트워크 홉을 최소화합니다. 다이렉트 피어링을 사용하여 네트워크와 Google의 에지 접속 지점(PoP) 간에 인터넷 트래픽을 교환할 수 있습니다.
- Dedicated Interconnect는 온프레미스 네트워크와 Google 네트워크 간에 물리적인 직접 연결을 제공합니다. 이 서비스는 대규모 데이터 전송에 더 일관된 처리량을 제공하면서 SLA를 보장합니다. 회선은 10Gbps 또는 100Gbps이며 Google의 코로케이션 시설 중 하나에서 종료됩니다.
대역폭이 클수록 온프레미스에서 Google Cloud로 데이터를 전송하는 데 걸리는 시간을 줄일 수 있습니다. 다음 표에서는 10Gbps에서 100Gbps로 업그레이드할 때의 속도 향상을 보여줍니다.
- Partner Interconnect는 Dedicated Interconnect와 유사한 기능을 제공하지만 회선 속도가 10Gbps 미만입니다. 자세한 내용은 지원되는 서비스 제공업체를 참조하세요.
다음 다이어그램은 Google Cloud로 전송해야 하는 데이터의 양에 따라 사용할 전송 방법에 대한 안내를 제공합니다.
전송 시간 계산기를 사용하면 이동할 데이터 세트의 크기와 전송에 사용할 수 있는 대역폭을 고려하여 전송에 소요되는 시간을 파악할 수 있습니다. DR 계획의 일환으로 수행되는 데이터 전송에 대한 자세한 내용은 대규모 데이터 세트 전송을 참조하세요.
이미지 구성 및 배포 속도의 균형 조정
새 인스턴스를 배치하기 위해 시스템 이미지를 구성할 때 구성이 전개 속도에 미치는 영향을 고려하세요. 이미지 사전 구성의 양, 이미지를 유지관리하는 비용, 배포 속도 사이에 상충하는 관계가 있습니다. 예를 들어 컴퓨터 이미지가 최소한으로 구성되어 있으면 이를 사용하는 인스턴스가 종속 항목을 다운로드하고 설치해야 하므로 시작하는 데 더 많은 시간이 필요합니다. 반면에 컴퓨터 이미지가 높은 수준으로 구성되어 있으면 이를 사용하는 인스턴스가 더 빨리 시작되지만 이미지를 더 자주 업데이트해야 합니다. 완벽하게 작동하는 인스턴스를 시작하는 데 걸리는 시간은 RTO와 직접적인 상관 관계가 있습니다.
하이브리드 환경에서 머신 이미지 일관성 유지
하이브리드 솔루션(온프레미스-클라우드 또는 클라우드-클라우드)을 구현할 때는 프로덕션 환경 간에 VM 일관성을 유지할 방법을 찾아야 합니다.
완전히 구성된 이미지가 필요한 경우 여러 플랫폼에 동일한 컴퓨터 이미지를 만들 수 있는 Packer와 같은 방법을 고려하세요. 플랫폼별 구성 파일과 동일한 스크립트를 사용할 수 있습니다. Packer의 경우 버전 제어에 구성 파일을 넣어 프로덕션 환경에 배포된 버전을 추적할 수 있습니다.
또 다른 옵션으로 Chef, Puppet, Ansible, Saltstack과 같은 구성 관리 도구를 사용하여 세밀하게 세분화된 인스턴스를 구성하고 필요에 따라 기본 이미지, 최소 구성 이미지 또는 완전 구성된 이미지를 만들 수 있습니다. 이러한 도구를 효과적으로 사용하는 방법에 대한 설명은 Zero-to-Deploy with Chef on Google Cloud를 참조하세요.
또한 Amazon AMI, Virtualbox 이미지, RAW 디스크 이미지와 같은 기존 이미지를 수동으로 변환하고 Compute Engine으로 가져올 수도 있습니다.
단계식 스토리지 구현
단계식 저장소 패턴은 일반적으로 가장 최근의 백업이 더 빠른 저장소에 있는 백업에 사용되며 이전 백업을 더 저렴한 저속 저장소로 천천히 이전합니다. Cloud Storage를 사용하여 패턴을 구현하는 방법에는 데이터 출처가 Google Cloud인지 온프레미스인지에 따라 두 가지가 있습니다. 두 경우 모두 서로 다른 스토리지 클래스의 버킷 간에 객체를 마이그레이션하며, 일반적으로는 표준 스토리지 클래스에서 보다 저렴한 Nearline Storage 클래스로 마이그레이션합니다.
소스 데이터가 온프레미스에서 생성된 경우 구현은 아래의 다이어그램과 유사합니다.
또는 객체 생명 주기 규칙을 사용하여 버킷 객체의 스토리지 클래스를 변경하여 객체 클래스의 변경을 자동화할 수 있습니다.
비공개 인스턴스에 대해 동일한 IP 주소 유지
일반적인 패턴은 VM의 단일 게재 인스턴스를 유지관리하는 것입니다. VM을 교체해야 하는 경우 교체가 원래 VM인 것처럼 나타나야 합니다. 따라서 클라이언트가 새 인스턴스에 연결하는 데 사용하는 IP 주소는 동일하게 유지되어야 합니다.
가장 간단한 구성은 정확히 하나의 인스턴스를 유지관리하는 관리형 인스턴스 그룹을 설정하는 것입니다. 이 관리형 인스턴스 그룹은 원래 이미지인지 대체 이미지인지에 관계없이 인스턴스에 동일한 IP 주소가 사용되도록 하는 내부(비공개) 부하 분산기와 통합됩니다.
기술 파트너
Google은 Google Cloud에서의 백업 및 DR 사용 사례를 지원하는 강력한 파트너 생태계를 갖추고 있습니다. 특히 고객들은 파트너 솔루션을 사용하여 다음을 수행합니다.
- 온프레미스 데이터를 Google Cloud에 백업합니다. 이러한 경우 Cloud Storage는 대부분의 온프레미스 백업 플랫폼에 대한 스토리지 대상으로 통합됩니다. 이 방법을 사용하여 테이프 및 기타 스토리지 어플라이언스를 대체할 수 있습니다.
- 온프레미스에서 Google Cloud로 이동하는 DR 계획을 구현합니다. 파트너는 보조 데이터 센터를 제거하고 Google Cloud를 DR 사이트로 사용하는 데 도움을 줄 수 있습니다.
- 클라우드 기반 워크로드에 대한 DR 및 백업을 구현합니다.
파트너 솔루션에 대한 자세한 내용은 Google Cloud 웹사이트의 파트너 페이지를 참조하세요.
다음 단계
- Google Cloud 지역 및 리전에 대해 알아보기
이 DR 시리즈의 다른 도움말 읽어보기
Google Cloud에 대한 참조 아키텍처, 다이어그램, 권장사항 살펴보기. Cloud 아키텍처 센터 살펴보기