가용성 권장사항

이 페이지에서는 Google Distributed Cloud 설치의 고가용성을 보장하기 위한 권장사항을 설명합니다. Distributed Cloud는 서비스수준계약 (SLA)을 제공하지 않으며 이 페이지에 설명된 서비스 수준 목표 (SLO)만 제공합니다.

가용성 수준 선택 및 구현

비즈니스 요구사항에 가장 적합한 Distributed Cloud 워크로드의 가용성 수준을 선택해야 합니다. 예를 들어 소매점의 셀프 결제 애플리케이션은 이동통신사 셀룰러 네트워크의 에지 RAN 배포보다 가용성 위험이 훨씬 낮습니다.

목표 가용성은 비상사태를 위해 예약하는 분산 클라우드 예비 리소스 용량에 정비례합니다. 다음 표에서는 이 관계를 설명합니다. 이 추정치에는 유지보수 기간으로 예약된 다운타임이 포함되지 않습니다.

Distributed Cloud Connected 소프트웨어는 각 물리적 머신에서 일부 리소스를 사용합니다. 금액은 Distributed Cloud 연결 배포의 구체적인 구성에 따라 다릅니다. 워크로드 분산을 계획할 때 이 양을 측정하고 이를 고려하여 Distributed Cloud connected 배포를 벤치마킹하는 것이 좋습니다.

사용 중인 용량 예약된 용량 타겟 사용 가능 여부
83.33% 16.67% 99.9%
100% 0% 93.5%

하드웨어 장애 또는 다시 시작해야 하는 노드로 인해 갑자기 용량이 손실될 수 있습니다. 이를 준비하려면 선택한 가용성 수준을 충족하는 용량을 각 분산 클라우드 노드에서 항상 사용할 수 있도록 리소스 할당량을 고려하여 워크로드를 설계해야 합니다.

예를 들어 목표 가용성 99.9% 를 달성하려면 각 Distributed Cloud 클러스터의 6개 물리적 머신 중 하나가 백업으로 사용 가능하도록 워크로드를 구성해야 합니다.

생존 가능 모드 사용

Distributed Cloud를 사용하면 Distributed Cloud 하드웨어에서 실행되는 로컬 컨트롤 플레인을 사용하는 클러스터를 만들 수 있습니다. 이러한 클러스터를 사용하면 Google Cloud 와의 연결이 끊어져도 워크로드가 계속 실행될 수 있습니다. 자세한 내용은 Distributed Cloud 생존 가능 모드를 참고하세요.

소프트웨어 업데이트 및 유지보수 기간 이해하기

Google에서는 Distributed Cloud 소프트웨어를 정기적으로 업데이트합니다. 이러한 소프트웨어 업데이트는 필수이며 선택 해제할 수 없습니다. Distributed Cloud를 사용하면 각 Distributed Cloud 클러스터에 대해 개별 유지보수 기간을 지정할 수 있습니다.

유지보수 기간을 통해 컨트롤 플레인과 노드의 자동 업그레이드 수행 시기를 제어하여 워크로드의 일시적 중단 가능성을 완화할 수 있습니다. 유지보수 기간은 다음과 같은 상황에서 유용합니다.

  • 사용량이 적은 시간대: 트래픽이 줄어드는 사용량이 적은 시간대에 자동 업그레이드를 예약하여 다운타임 발생 가능성을 최소화할 수 있습니다.
  • 업무 시간 중: 누군가 업그레이드를 모니터링하고 예상치 못한 문제를 관리할 수 있도록 업무 시간 중 업그레이드가 실시되도록 할 수 있습니다.
  • 다중 클러스터 업그레이드: 지정된 간격으로 한 번에 하나씩 여러 지역에 있는 여러 클러스터에 업그레이드를 출시할 수 있습니다.

자동 업그레이드 외에도 Google은 경우에 따라 다른 유지보수 태스크를 수행해야 할 수 있습니다. 이 경우 가능한 경우 클러스터의 유지보수 기간을 따릅니다.

작업이 유지보수 기간을 초과하여 실행되면 Distributed Cloud는 작업을 일시중지하려고 시도합니다. 그런 다음 다음 유지보수 기간에 해당 작업을 재개하려고 시도합니다.

Distributed Cloud는 유지보수 기간 외에도 계획되지 않은 긴급 업그레이드를 롤아웃할 수 있는 권리를 보유합니다. 또한 지원 중단되었거나 오래된 소프트웨어의 필수 업그레이드는 유지보수 기간이 아닐 때에도 자동으로 진행될 수 있습니다.

언제든지 클러스터를 수동으로 업그레이드할 수도 있습니다. 수동으로 시작한 업그레이드는 즉시 시작되고 유지보수 기간은 무시됩니다.

새 클러스터 또는 기존 클러스터에 유지보수 기간을 설정하는 방법은 유지보수 기간 구성을 참고하세요.

제한사항

유지보수 기간에는 다음과 같은 제한사항이 있습니다.

  • 클러스터당 유지보수 기간 하나 클러스터당 유지보수 기간을 하나만 구성할 수 있습니다. 새 유지보수 기간을 구성하면 이전 유지보수 기간을 덮어씁니다.

  • 유지보수 기간의 표준 시간대 유지보수 기간을 구성하고 볼 때 사용 중인 도구에 따라 시간이 다르게 표시됩니다. 자세한 내용은 다음 섹션을 참고하세요.

유지보수 기간을 구성할 경우

보다 일반적인 --maintenance-window 플래그를 사용하여 유지보수 기간을 구성할 경우에는 표준 시간대를 지정할 수 없습니다. Google Cloud CLI 또는 API를 사용하는 경우 UTC를 사용하여 시간이 표시됩니다.Google Cloud 콘솔은 현지 시간대를 사용하여 시간을 표시합니다.

--maintenance-window-start와 같이 더욱 세분화된 플래그를 사용하면 값의 일부로 표준 시간대를 지정할 수 있습니다. 표준 시간대를 생략하면 현지 표준 시간대가 사용됩니다. 시간은 항상 UTC로 저장됩니다.

유지보수 기간을 확인할 경우

클러스터 정보를 확인할 경우 정보 확인 방법에 따라 유지보수 기간의 타임스탬프가 UTC 또는 현지 표준 시간대로 표시될 수 있습니다.

  • Google Cloud 콘솔을 사용하여 클러스터의 정보를 확인할 경우 시간은 항상 현지 표준 시간대로 표시됩니다.
  • gcloud CLI를 사용하여 클러스터에 대한 정보를 보는 경우 시간은 항상 UTC로 표시됩니다.

두 경우 모두 RRULE은 항상 UTC입니다. 즉, 예를 들어 요일을 지정하면 해당 요일은 UTC로 표시됩니다.

클러스터 유지보수 기간 구성

Distributed Cloud를 사용하면 각 Distributed Cloud 클러스터의 유지보수 기간을 지정할 수 있습니다. 이 기간은 지정한 시간과 빈도로만 Google에서 Distributed Cloud 소프트웨어를 업데이트하도록 지시합니다.

다음 규칙은 Distributed Cloud 클러스터 유지관리 기간을 관리합니다.

  • Distributed Cloud 클러스터의 유지보수 기간을 지정하면 Google은 Distributed Cloud 출시 노트를 통해 업데이트가 발표된 후 48시간이 지나면 Distributed Cloud 소프트웨어를 업데이트합니다. 출시 노트 페이지에서 Distributed Cloud 출시 노트 RSS 피드를 구독하여 소프트웨어 업데이트가 출시될 때마다 정보를 확인할 수 있습니다.
  • 유지보수 기간의 최소 길이는 6시간입니다. Distributed Cloud 설치의 복잡성과 비즈니스 요구사항에 따라 더 긴 기간을 지정할 수 있습니다.
  • 소프트웨어 업데이트의 최소 빈도는 주 1회입니다. 주간 또는 일일 유지보수 기간을 지정할 수 있습니다. 특정 요일을 포함하거나 제외할 수 있습니다.
  • 유지보수 기간이 이미 예약되었거나 유지보수 기간이 진행 중인 경우를 제외하고 언제든지 클러스터의 유지보수 기간 일정을 변경할 수 있습니다.
  • 소프트웨어 업데이트가 지정된 시간 내에 완료되지 않으면 일시중지된 후 다음 예약된 유지보수 기간에 재개됩니다.

자세한 내용은 클러스터의 유지보수 기간 구성을 참고하세요.

실패한 하드웨어 수리

Google에서 Distributed Cloud 하드웨어의 장애를 감지하면 영업일 기준 3일 이내에 현장 방문 일정을 예약하려고 시도합니다. Google 공인 기술자가 필요한 진단 및 수리를 수행하려면 Distributed Cloud 하드웨어에 대한 액세스 권한을 부여해야 합니다.

Distributed Cloud 하드웨어에 장애가 발생하고 Google에서 현장 수리를 수행하는 경우 서비스 대상 Distributed Cloud 머신에서 모든 스토리지 미디어가 제거되고 수리 기간 동안 고객이 보관합니다.

기타 장애점

Google의 통제 범위에 속하지 않으며 Distributed Cloud의 가용성에 영향을 미칠 수 있는 Distributed Cloud 설치의 다음 측면을 유지관리할 책임은 사용자에게 있습니다.

다음 단계