재해 복구 구성 요소

이 도움말은 Google Cloud Platform(GCP)의 재해 복구(DR)에 대해 설명하는 여러 부분으로 구성된 시리즈 중 두 번째 부분입니다. 이 부분에서는 DR 계획(GCP 제품 및 모든 플랫폼에서 작동하는 제품)의 구성 요소로 사용할 수 있는 서비스와 제품에 대해 설명합니다.

시리즈는 다음 세 부분으로 구성됩니다.

소개

GCP에는 재해 복구(DR) 아키텍처의 일부로 사용할 수 있는 다양한 제품이 있습니다. 이 섹션에서는 GCP DR 구성 요소로 가장 일반적으로 사용되는 제품의 DR 관련 기능에 대해 설명합니다.

이러한 서비스의 대부분은 HA(고 가용성) 기능을 가지고 있습니다. HA는 DR과 완전히 겹치지는 않지만 HA의 많은 목표는 DR 계획 설계에도 적용됩니다. 예를 들어 HA 기능을 활용하면 가동 시간을 최적화하고 단일 VM 장애와 같은 소규모 장애의 영향을 완화할 수 있는 아키텍처를 설계할 수 있습니다. DR과 HA의 관계에 대한 자세한 내용은 재해 복구 계획 가이드를 참조하세요.

다음 섹션에서는 이러한 GCP DR 구성 요소와 이러한 구성 요소가 DR 목표를 구현하는 데 어떻게 도움이 되는지 설명합니다.

컴퓨팅 및 저장소

Compute Engine
  • 확장 가능한 컴퓨팅 리소스
  • 사전 정의 및 커스텀 머신 유형
  • 빠른 부팅 시간
  • 스냅샷
  • 인스턴스 템플릿
  • 관리형 인스턴스 그룹
  • 영구 디스크
  • 라이브 마이그레이션
Cloud Storage
  • 내구성 높은 객체 저장소
  • 지리적 중복 스토리지
  • 스토리지 클래스
  • 객체 수명 주기 관리
  • 다른 소스에서 데이터 전송
  • 기본적으로 미사용 데이터 암호화
GKE
  • 컨테이너식 애플리케이션 배포 및 확장을 위한 관리형 환경
  • 영구 볼륨
  • 노드 자동 복구
  • 활성 및 준비 여부 조사
  • 다중 영역 및 리전 클러스터
  • 리전 간 클러스터 관리를 위한 명령줄 도구

Compute Engine

Compute Engine은 가상 머신(VM) 인스턴스를 제공하며 GCP의 주축 역할을 합니다. Compute Engine 인스턴스의 구성, 시작, 모니터링 외에도 일반적으로 DR 계획을 구현하기 위해 다양한 관련 기능을 사용합니다.

DR 시나리오의 경우 삭제 보호 플래그를 설정하여 실수로 인한 VM 삭제를 방지할 수 있습니다. 이는 특히 데이터베이스와 같은 상태 저장 서비스를 호스팅하는 경우에 유용합니다. 낮은 RTO 및 RPO 값을 충족 시키려면 강력한 시스템을 설계하는 모범 사례를 따르세요.

애플리케이션이 사전 설치되어 있는 인스턴스를 구성한 다음 해당 구성을 커스텀 이미지로 저장할 수 있습니다. 커스텀 이미지는 달성하려는 RTO를 반영할 수 있습니다.

인스턴스 템플릿

Compute Engine 인스턴스 템플릿을 사용하여 VM의 구성 세부 정보를 저장한 다음 기존 인스턴스 템플릿에서 인스턴스 만들기를 할 수 있습니다. 이 템플릿을 사용하여 필요한 만큼 인스턴스를 실행할 수 있으며 DR 타겟 환경을 구축해야 할 때 원하는 방식으로 정확하게 구성할 수 있습니다. 인스턴스 템플릿은 전역으로 복제되므로 동일한 구성으로 GCP의 모든 위치에서 인스턴스를 쉽게 다시 만들 수 있습니다.

커스텀 이미지를 사용하거나 기존 VM 인스턴스를 기반으로 인스턴스 템플릿을 만들 수 있습니다.

이 문서의 뒤쪽에 있는 이미지 구성 및 배포 속도 조정 섹션에서 Compute Engine 이미지 사용에 대한 자세한 내용을 제공합니다.

관리형 인스턴스 그룹

관리형 인스턴스 그룹은 Cloud Load Balancing(이 문서의 뒷부분에서 설명)과 함께 작동하여 영역 간에 복사된 동일하게 구성된 인스턴스 그룹에 트래픽을 분산시킵니다. 관리형 인스턴스 그룹은 자동 확장 및 자동 복구와 같은 기능을 허용하며 여기에서 관리형 인스턴스 그룹이 인스턴스를 자동으로 삭제하고 다시 만들 수 있습니다.

영구 디스크 및 스냅샷

영구 디스크는 인스턴스에서 액세스할 수 있는 내구성 있는 네트워크 저장소 기기입니다. 인스턴스와 독립적이므로 인스턴스를 삭제한 후에도 영구 디스크를 분리하고 이동하여 데이터를 보관할 수 있습니다.

재난 발생시 영구 디스크를 다시 만들고 재현할 수 있는 Compute Engine VM의 증분 백업 또는 스냅샷을 지역 간에 복사하여 사용할 수 있습니다. 또한 영구 디스크 스냅샷 만들기로 사용자 오류로 인한 데이터 손실을 방지할 수 있습니다. 스냅샷은 증분적이며, 실행 중인 인스턴스에 연결된 디스크를 스냅샷으로 작성할 경우에도 몇 분이면 생성됩니다.

영구 디스크에는 장비 고장 시 데이터를 보호하고, 데이터 센터 유지관리 이벤트를 통해 데이터 가용성을 보장하는 중복 기능이 내장되어 있습니다.

실시간 이전

실시간 이전은 소프트웨어 또는 하드웨어 업데이트와 같은 호스트 시스템 이벤트가 발생하더라도 가상 머신 인스턴스가 계속 실행되게 합니다. Compute Engine은 사용자가 VM을 재부팅할 필요 없이 동일 영역에서 실행 중인 인스턴스를 또 다른 호스트로 라이브 이전합니다. 이렇게 해서 Google은 사용자의 VM에 영향을 주지 않으면서도 인프라를 보호하고 안정적인 상태로 유지하는 데 반드시 필요한 유지관리를 수행할 수 있습니다.

가상 디스크 가져오기 도구

가상 디스크 가져오기 도구를 사용하면 VMDK, VHD 및 RAW를 비롯한 파일 형식을 가져와 새 Compute Engine 가상 컴퓨터를 만들 수 있습니다. 이 도구를 사용하면 온프레미스 가상 컴퓨터와 동일한 구성을 가진 Compute Engine 가상 컴퓨터를 만들 수 있습니다. 이는 이미 이미지에 설치된 소프트웨어의 소스 바이너리에서 Compute Engine 이미지를 구성할 수 없는 경우에 좋은 방법입니다.

Cloud Storage

Cloud Storage는 백업 파일을 저장하는 데 이상적인 객체 저장소입니다. 다음 다이어그램에 설명된 대로 특정 사용 사례에 적합한 다양한 저장소 클래스를 제공합니다.

고주파 액세스를 위한 다 지역 및 지역 저장소를 보여주는 다이어그램, 저주파 액세스의 Nearline 및 최저 주파수 액세스를 위한 Coldline

DR 시나리오에서 Nearline 및 Coldline 저장소는 특히 중요합니다. Nearline 및 Coldline 모두 다중 지역 또는 지역 저장소에 비해 저장소 비용을 절감합니다. 그러나 이러한 클래스에 저장된 데이터 또는 메타데이터를 검색하는 데 드는 추가 비용과 비용이 부과되는 최소 저장 기간이 있습니다. Nearline은 월 1회 액세스가 가능한 백업 시나리오를 위해 설계되었으므로 비용을 낮게 유지하면서 정기적인 DR 스트레스 테스트를 수행하는 데 이상적입니다.

Nearline 및 Coldline 모두 드문 액세스에 최적화되어 있으며 가격 모델은 이를 염두에 두고 설계되었습니다. 따라서 최소 저장 기간이 청구되며 클래스의 최소 저장 기간보다 이전에 이러한 클래스에서 데이터 또는 메타데이터를 검색하는 데 요금이 발생합니다.

Storage Transfer Service를 사용하면 Amazon S3 또는 HTTP 기반 소스에서 Cloud Storage로 데이터를 가져올 수 있습니다. DR 시나리오에서 Storage Transfer Service를 사용하여 다음을 수행할 수 있습니다.

  • 다른 저장소 제공업체의 데이터를 Cloud Storage 버킷에 백업합니다.
  • 다중 지역 저장소 버킷에서 Nearline Storage 버킷으로 데이터를 이동하여 백업 저장 비용을 낮춥니다.

GKE

GKE는 컨테이너식 애플리케이션 배포를 위한 관리형 환경입니다. GKE를 사용하면 HA 시스템을 조정할 수 있으며 다음과 같은 기능이 포함됩니다.

  • 노드 자동 복구. 노드가 장시간(약 10분) 동안 연속으로 상태 확인에 실패하면 GKE는 해당 노드에 대한 복구 프로세스를 시작합니다.
  • 활성 여부 조사. 포드가 실행 중임을 GKE에 주기적으로 알리는 활성 여부 조사를 지정할 수 있습니다. 포드가 조사에 실패하면 포드를 다시 시작할 수 있습니다.
  • 영구 볼륨. 데이터베이스는 컨테이너의 수명을 초과하여 지속될 수 있어야 합니다. Compute Engine 영구 디스크에 매핑되는 영구 볼륨 추상화를 사용하면 개별 컨테이너와 독립적으로 저장용량 가용성을 유지할 수 있습니다.
  • 다중 영역 및 지역 클러스터. Kubernetes 리소스를 한 지역 내의 여러 영역에 배포할 수 있습니다.
  • Kubemci. 이 도구를 사용하면 서로 다른 지역의 여러 GKE 클러스터에 트래픽을 부하 분산하도록 전역 부하 분산기를 구성할 수 있습니다.

네트워킹 및 데이터 전송

Cloud Load Balancing
  • 리전 간
  • 단일 Anycast IP
  • 상태 확인
  • Cloud CDN 통합
  • 자동 확장 통합
Cloud Interconnect
  • Cloud VPN(IPsec VPN)
  • 다이렉트 피어링
Cloud DNS
  • 프로그래매틱 방식의 DNS 관리
  • 액세스 제어
  • 영역에 서비스를 제공하는 Anycast

Cloud Load Balancing

Cloud Load Balancing은 사용자 요청을 인스턴스 집합에 배포하여 Compute Engine에 HA를 제공합니다. 장애가 발생한 인스턴스로 트래픽이 라우팅되지 않도록 인스턴스에서 작업을 수행할 수 있는지 여부를 결정하는 상태 확인 기능을 사용하여 Cloud Load Balancing을 구성할 수 있습니다.

Cloud Load Balancing은 Compute Engine 인스턴스 앞에 전역으로 액세스할 수 있는 단일 IP 주소를 제공합니다. 애플리케이션은 다른 지역(예: 유럽 및 미국)에서 실행중인 인스턴스가 있을 수 있으며 최종 사용자는 가장 가까운 인스턴스 세트로 연결됩니다. 인터넷에 노출된 서비스에 대한 부하 분산을 제공하는 것 외에도 비공개 부하 분산 IP 주소 배후의 서비스를 위해 내부 부하 분산을 구성할 수 있습니다. 이 IP 주소는 가상 사설 클라우드(VPC) 내부의 VM 인스턴스에서만 액세스할 수 있습니다.

Cloud DNS

Cloud DNS는 자동화된 복구 프로세스의 일부로 DNS 항목을 프로그래매틱 방식으로 관리할 수 있는 방법을 제공합니다. Cloud DNS는 Anycast 네임서버의 글로벌 네트워크를 통해 DNS 영역을 전 세계의 중복 위치에서 제공하여 사용자에게 높은 가용성과 짧은 지연 시간을 제공합니다.

Cloud Interconnect

Cloud Interconnect는 다른 출처의 정보를 GCP로 이동하는 방법을 제공합니다. 이 제품에 대해서는 나중에 GCP와의 데이터 전송에서 설명합니다.

관리 및 모니터링

Cloud 상태 대시보드
  • GCP 서비스 상태
Stackdriver
  • 업타임 모니터링
  • 알림
  • Logging
  • Error reporting
Deployment Manager
  • 반복 가능하고 일관된 배포 프로세스
  • 동시 배포
  • 템플릿
  • 코드형 인프라

Cloud 상태 대시보드

Cloud 상태 대시보드에는 GCP 서비스의 현재 가용성이 표시됩니다. 페이지의 상태를 볼 수 있으며 서비스에 대한 뉴스가 있을 때마다 업데이트되는 RSS 피드를 구독할 수 있습니다.

모니터링

모니터링은 GCP, AWS, 호스팅된 가동 시간 프로브, 애플리케이션 계측 및 기타 다양한 애플리케이션 구성 요소에서 측정항목, 이벤트 및 메타데이터를 수집합니다. 관리자에게 적시에 업데이트를 제공하기 위해 Slack 또는 Pagerduty와 같은 타사 도구에 알림을 보내도록 알림을 구성할 수 있습니다. DR에 Stackdriver를 사용하는 또 다른 방법은 Cloud Pub/Sub 싱크를 구성하고 Cloud Functions를 사용하여 Stackdriver 알림에 대한 자동화된 프로세스를 트리거하는 것입니다.

Deployment Manager

Deployment Manager를 사용하면 일련의 템플릿으로 GCP 환경을 정의할 수 있습니다. 그런 다음 템플릿을 사용하면 하나의 명령어로 반복하여 일관적으로 환경을 작성할 수 있습니다. 마찬가지로 하나의 명령어로 환경을 해체할 수 있습니다. 따라서 Cloud Deployment Manager는 어떤 리전에서든 안정적으로 작성할 수 있는 DR 복구 환경을 정의하기에 이상적입니다.

크로스 플랫폼 DR 구성 요소

둘 이상의 플랫폼에서 작업 부하를 실행하는 경우 운영 오버헤드를 줄이는 방법은 사용중인 모든 플랫폼에서 작동하는 도구를 선택하는 것입니다. 이 섹션에서는 플랫폼에 구애받지 않으며 플랫폼 간 DR 시나리오를 지원하는 몇 가지 도구 및 서비스에 대해 설명합니다.

선언적 템플릿 도구

선언적 템플릿 도구를 사용하면 플랫폼 간에 인프라를 쉽게 배포할 수 있습니다. 앞에서 설명했듯이 GCP 전용 배포에 Deployment Manager를 사용할 수 있습니다. 크로스 플랫폼 배포에서 Terraform은 가장 널리 사용되는 선언적 템플릿 도구 중 하나입니다.

구성 관리 도구

대규모 또는 복잡한 DR 인프라의 경우 Chef 및 Ansible과 같은 플랫폼 독립적인 소프트웨어 관리 도구를 사용하는 것이 좋습니다. 이러한 도구를 사용하면 컴퓨팅 작업 부하가 어디에 있더라도 재현 가능한 구성을 적용할 수 있습니다. 이러한 유형의 도구를 사용하는 예는 Ansible with Spinnaker 가이드Zero-to-Deploy with Chef on GCP를 참조하세요.

객체 저장소

일반적인 DR 패턴은 서로 다른 클라우드 공급자의 객체 저장소에 객체 사본을 갖는 것입니다. 이를 위한 크로스 플랫폼 도구 중 하나인 boto는 오픈소스 Python 라이브러리로서 Amazon S3 및 Cloud Storage와 상호 작용할 수 있습니다.

조정자 도구

또한 DR 구성 요소로 컨테이너를 고려해 볼 수 있습니다. 컨테이너는 서비스를 패키지화하고 플랫폼 간 일관성을 도입하는 방법입니다.

컨테이너로 작업하는 경우 일반적으로 조정자를 사용합니다. Kubernetes는 GCP(GKE 사용) 내의 컨테이너를 관리하는 것뿐만 아니라 여러 플랫폼에서 컨테이너 기반 작업 부하를 조정하는 방법을 제공합니다. GCP, AWS 및 Microsoft Azure는 모두 Kubernetes의 관리 버전을 제공합니다.

서로 다른 클라우드 플랫폼에서 실행되는 Kubernetes 클러스터에 트래픽을 분산시키려면 가중치가 있는 레코드를 지원하고 상태 확인을 통합하는 DNS 서비스를 사용할 수 있습니다.

또한 대상 환경으로 이미지를 가져올 수 있어야 합니다. 즉 재난 발생시 이미지 레지스트리에 액세스할 수 있어야 합니다. 플랫폼에 독립적인 좋은 옵션은 Container Registry입니다.

데이터 전송

데이터 전송은 교차 플랫폼 DR 시나리오의 핵심 구성 요소입니다. DR 데이터 전송 시나리오에서 요구하는 사실적인 모델을 사용하여 교차 플랫폼 DR 시나리오를 설계, 구현 및 테스트해야 합니다. 데이터 전송 시나리오에 대해서는 다음 섹션에서 설명합니다.

DR용 패턴

이 섹션에서는 앞에서 설명한 구성 요소를 기반으로 DR 아키텍처의 가장 일반적인 패턴 중 일부를 설명합니다.

GCP와의 데이터 전송

DR 계획의 중요한 측면은 데이터를 GCP 간에 얼마나 빨리 전송할 수 있는지입니다. DR 계획이 온프레미스에서 GCP로 또는 다른 클라우드 제공업체에서 GCP로 데이터 정보를 이동하는 것을 기반으로 하는 경우 중요합니다. 이 섹션에서는 우수한 처리량을 보장할 수 있는 네트워킹 및 GCP 서비스에 대해 설명합니다.

온프레미스 또는 다른 클라우드 환경에 있는 작업 부하의 복구 사이트로 GCP를 사용하는 경우 다음 주요 항목을 고려해야 합니다.

  • GCP에 어떻게 연결합니까?
  • 사용자와 상호 연결 제공업체 간에 얼마나 많은 대역폭이 있습니까?
  • 제공업체가 GCP에 직접 제공한 실제 대역폭은 얼마입니까?
  • 해당 링크를 사용하여 전송되는 다른 데이터는 무엇입니까?

공용 인터넷 연결을 사용하여 데이터를 전송하는 경우 ISP의 용량 및 라우팅에 제한이 있으므로 네트워크 처리량을 예측할 수 없습니다. ISP는 제한된 SLA를 제공하거나 전혀 제공하지 않을 수 있습니다. 하지만 이런 연결은 상대적으로 비용이 저렴합니다.

GCP 간에 데이터를 이동하는 다른 옵션은 다음과 같습니다.

  • Cloud VPN. GCP와의 데이터 전송 시 클라우드 VPN을 사용하여 전송 중인 데이터를 암호화할 수 있습니다. 원본 및 대상 네트워크 간에 IPsec VPN 연결이 시작됩니다. 한쪽 VPN 게이트웨이에서 두 네트워크 사이의 트래픽 이동을 암호화하면 이후 다른 쪽 VPN 게이트웨이에서 이를 복호화합니다.
  • 다이렉트 피어링. 네트워크 홉을 최소화하기 위해 직접 피어링을 사용하여 네트워크와 Google의 에지 접속 지점(POP) 간에 인터넷 트래픽을 교환할 수 있습니다.
  • Cloud Interconnect. 이 서비스는 여러 서비스 제공업체 중 하나를 통해 직접 GCP 연결을 제공합니다. Cloud Interconnect는 대규모 데이터 전송에 더 일관된 처리량을 제공하며 일반적으로 네트워크 가용성 및 성능에 대한 SLA가 포함되어 있습니다. 자세한 내용은 직접 서비스 제공업체에 문의하세요.

다음 다이어그램은 GCP로 전송해야 하는 데이터 양에 따라 사용할 전송 방법에 대한 지침을 제공합니다.

다양한 전송 솔루션을 사용하여 Y축(0에서 100TB까지)의 데이터 양과 X 축의 데이터 위치 카테고리(예: 'In GCP', 'On-premises with good connectivity'등)를 보여주는 차트의 각 카테고리

DR 계획의 일환으로 수행되는 데이터 전송에 대한 자세한 내용은 빅데이터 세트 전송을 참조하세요.

이미지 구성 및 배포 속도의 균형 조정

새 인스턴스를 배치하기 위해 시스템 이미지를 구성할 때 구성이 전개 속도에 미치는 영향을 고려하세요. 이미지 사전 구성의 양, 이미지를 유지관리하는 비용, 배포 속도 사이에 상충하는 관계가 있습니다. 예를 들어 컴퓨터 이미지가 최소한으로 구성되어 있으면 이를 사용하는 인스턴스가 종속 항목을 다운로드하고 설치해야 하므로 시작하는 데 더 많은 시간이 필요합니다. 반면에 컴퓨터 이미지가 높은 수준으로 구성되어 있으면 이를 사용하는 인스턴스가 더 빨리 시작되지만 이미지를 더 자주 업데이트해야 합니다. 완벽하게 작동하는 인스턴스를 시작하는 데 걸리는 시간은 RTO와 직접적인 상관 관계가 있습니다.

이미지 부팅 시간에 매핑된 3개 수준의 번들(번들되지 않음에서 완전히 번들됨까지)을 보여주는 다이어그램(가장 번들된 것이 가장 빨리 부팅됨)

하이브리드 환경에서 시스템 이미지 일관성 유지

하이브리드 솔루션(온프레미스-클라우드 또는 클라우드-클라우드)을 구현할 때는 프로덕션 환경 간에 VM 일관성을 유지할 방법을 찾아야 합니다.

완전히 구성된 이미지가 필요한 경우 여러 플랫폼에 동일한 컴퓨터 이미지를 만들 수 있는 Packer와 같은 방법을 고려하세요. 플랫폼별 구성 파일과 동일한 스크립트를 사용할 수 있습니다. Packer의 경우 버전 제어에 구성 파일을 넣어 프로덕션 환경에 배포된 버전을 추적할 수 있습니다. Packer 및 기타 오픈소스 유틸리티로 이미지를 지속적으로 빌드하기 위한 자동화된 파이프 라인을 만드는 방법에 대한 설명은 Jenkins, Packer 및 Kubernetes를 사용한 자동화된 이미지 빌드를 참조하세요.

또 다른 옵션으로 Chef, Puppet, Ansible 또는 Saltstack과 같은 구성 관리 도구를 사용하여 세밀하게 세분화된 인스턴스를 구성하고 기본 이미지, 최소 구성 이미지 또는 필요에 따라 완전 구성된 이미지를 만들 수 있습니다. 이러한 도구를 효과적으로 사용하는 방법에 대한 설명은 Ansible with Spinnaker 가이드Zero-to-Deploy with Chef on GCP를 참조하세요.

또한 Compute Engine으로 Amazon AMI, Virtualbox 이미지 및 RAW 디스크 이미지와 같은 기존 이미지를 수동 변환하고 가져오기할 수 있습니다.

단계식 저장소 구현

단계식 스토리지 패턴은 일반적으로 가장 최근의 백업이 더 빠른 스토리지에 있는 백업에 사용되며 이전 백업을 더 저렴한 저속 스토리지로 천천히 마이그레이션합니다. Cloud Storage를 사용하여 패턴을 구현하는 방법에는 데이터가 발생한 위치(GCP 또는 온프레미스)에 따라 두 가지가 있습니다. 두 경우 모두 다양한 스토리지 클래스의 버킷 간에 객체를 마이그레이션하며, 일반적으로 표준 스토리지 클래스에서 보다 저렴한 Nearline Storage 클래스로 마이그레이션합니다.

영구 디스크에서 표준 스토리지로, 다시 Nearline 스토리지로 마이그레이션하는 데이터를 보여주는 다이어그램

소스 데이터가 GCP에서 생성된 경우 구현은 아래의 다이어그램과 유사합니다.

Cloud Interconnect를 통해 온프레미스에서 Cloud Storage로 마이그레이션하는 데이터를 보여주는 다이어그램

또는 객체 수명 주기 규칙을 사용하여 버킷 객체의 스토리지 클래스를 변경하는 방법으로 객체 클래스의 변경을 자동화할 수 있습니다.

비공개 인스턴스에 대해 동일한 IP 주소 유지

일반적인 패턴은 VM의 단일 게재 인스턴스를 유지관리하는 것입니다. VM을 교체해야 하는 경우 교체가 원래 VM인 것처럼 나타나야 합니다. 따라서 클라이언트가 새 인스턴스에 연결하는 데 사용하는 IP 주소는 동일하게 유지되어야 합니다.

가장 간단한 구성은 정확히 하나의 인스턴스를 유지관리하는 관리 인스턴스 그룹을 설정하는 것입니다. 이 관리 인스턴스 그룹은 내부(비공개) 부하 분산기와 통합되어 원래 IP 주소인지 대체 IP 주소인지에 관계없이 동일한 IP 주소를 사용하여 인스턴스를 앞당기는 것을 보장합니다.

기술 파트너

Google은 GCP를 사용한 백업 및 DR 사용 사례를 지원하는 강력한 파트너 환경을 갖추고 있습니다. 특히 파트너 솔루션을 사용하는 고객은 다음과 같은 작업을 수행합니다.

  • 온프레미스 데이터를 GCP로 백업합니다. 이러한 경우 Cloud Storage는 대부분의 온프레미스 백업 플랫폼에 대한 저장소 대상으로 통합됩니다. 이 방법을 사용하여 테이프 및 기타 스토리지 어플라이언스를 대체할 수 있습니다.
  • 온프레미스에서 GCP로 이동하는 DR 계획을 구현합니다. 파트너는 보조 데이터 센터를 제거하고 GCP를 DR 사이트로 사용하는 데 도움을 드립니다.
  • 클라우드 기반 작업 부하에 대한 DR 및 백업을 구현합니다.

파트너 솔루션에 대한 자세한 내용은 GCP 웹사이트의 파트너 페이지를 참조하세요.

다음 단계