Google Distributed Cloud는 장애 범위를 제한하고 비즈니스 연속성에 중요한 기능을 우선시하도록 설계되었습니다. 이 문서에서는 실패가 발생할 때 클러스터 기능이 받는 영향에 대해 설명합니다. 이 정보는 문제가 있을 때 문제를 해결할 영역의 우선순위를 결정하는 데 도움이 됩니다.
추가 지원이 필요하면 Cloud Customer Care에 문의하세요.Google Distributed Cloud의 핵심 기능에는 다음 카테고리가 포함됩니다.
- 워크로드 실행: 기존 워크로드를 계속 실행할 수 있습니다. 이는 비즈니스 연속성을 유지하는 데 가장 중요한 고려사항입니다. 클러스터에 문제가 있어도 기존 워크로드는 중단 없이 계속 실행될 수 있습니다.
- 워크로드 관리: 워크로드를 생성, 업데이트, 삭제할 수 있습니다. 클러스터에 문제가 있더라도 트래픽이 증가할 때 워크로드를 확장할 수 있다는 점에서 두 번째로 중요한 고려사항입니다.
- 사용자 클러스터 관리: 노드를 관리하고 사용자 클러스터를 업데이트, 업그레이드, 삭제할 수 있습니다. 애플리케이션 수명 주기 고려사항보다는 덜 중요합니다. 기존 노드에 사용 가능한 용량이 있는 경우 사용자 클러스터를 수정할 수 없어도 사용자 워크로드에 영향을 미치지 않습니다.
- 관리자 클러스터 관리: 관리자 클러스터를 업데이트하고 업그레이드할 수 있습니다. 이는 관리자 클러스터가 사용자 워크로드를 호스팅하지 않으므로 가장 덜 중요한 고려사항입니다. 관리자 클러스터에 문제가 있으면 애플리케이션 워크로드가 중단 없이 계속 실행됩니다.
다음 섹션에서는 이러한 핵심 기능 카테고리를 사용하여 특정 유형의 실패 시나리오가 미치는 영향을 설명합니다.
오류 모드
다음 유형의 장애가 Google Distributed Cloud 클러스터의 성능에 영향을 줄 수 있습니다.
ESXi 호스트 오류
이 실패 시나리오에서 Kubernetes 노드를 호스팅하는 가상 머신(VM) 인스턴스를 실행하는 ESXi 호스트 작동이 중단되거나 네트워크가 파티셔닝될 수 있습니다.
| 워크로드 실행 | 워크로드 관리 | 사용자 클러스터 관리 | 관리자 클러스터 관리 | |
|---|---|---|---|---|
| 중단 | 가능한 중단 및 자동 복구 | 가능한 중단 및 자동 복구 | 중단 및 자동 복구 | 중단 및 자동 복구 |
| 설명 | 실패한 호스트에서 호스팅하는 VM에서 실행되는 포드가 중단되고 다른 정상 VM에 자동으로 다시 예약됩니다. 사용자 애플리케이션에 여유 워크로드 용량이 있고 여러 노드에 분산되어 있는 경우 재시도를 구현하는 클라이언트는 이 중단을 파악할 수 없습니다. |
호스트 오류가 비HA 사용자 클러스터의 제어 영역 VM 또는 HA 사용자 클러스터에서 둘 이상의 제어 영역 VM에 영향을 미치는 경우 중단이 발생합니다. | 호스트 실패가 관리자 클러스터의 제어 영역 VM 또는 작업자 VM에 영향을 미치는 경우 중단이 발생합니다. | 호스트 장애가 관리자 클러스터의 제어 영역 VM에 영향을 미치는 경우 중단이 발생합니다. |
| 복구 | vSphere HA는 정상 호스트에서 VM을 자동으로 다시 시작합니다. | vSphere HA는 정상 호스트에서 VM을 자동으로 다시 시작합니다. | vSphere HA는 정상 호스트에서 VM을 자동으로 다시 시작합니다. | vSphere HA는 정상 호스트에서 VM을 자동으로 다시 시작합니다. |
| 예방 방법 | HA 방식으로 워크로드를 배포하여 중단 가능성을 최소화합니다. | HA 사용자 클러스터를 사용하여 중단 가능성을 최소화합니다. | — | — |
VM 오류
이 실패 시나리오에서는 VM이 예기치 않게 삭제되거나 부팅 디스크가 손상되거나 운영체제 문제로 인해 VM이 손상될 수 있습니다.
| 워크로드 실행 | 워크로드 관리 | 사용자 클러스터 관리 | 관리자 클러스터 관리 | |
|---|---|---|---|---|
| 중단 | 가능한 중단 및 자동 복구 | 가능한 중단 및 자동 복구 | 중단 및 자동/수동 복구 | 중단 및 수동 복구 |
| 설명 | 실패한 작업자 VM에서 실행되는 포드가 중단되고 Kubernetes에 의해 다른 정상 VM에 자동으로 다시 예약됩니다. 사용자 애플리케이션에 여유 워크로드 용량이 있고 여러 노드에 분산되어 있는 경우 재시도를 구현하는 클라이언트는 이 중단을 파악할 수 없습니다. |
비HA 사용자 클러스터의 제어 영역 VM 또는 HA 사용자 클러스터의 두 개 이상의 제어 영역 VM이 실패하는 경우 중단이 발생합니다. | 관리자 클러스터의 제어 영역 VM 또는 작업자 VM이 실패하는 경우 중단이 발생합니다. | 관리자 클러스터의 제어 영역 VM이 실패하는 경우 중단이 발생합니다. |
| 복구 | 실패한 VM은 사용자 클러스터에서 노드 자동 복구가 사용 설정된 경우 자동으로 복구됩니다. | 실패한 VM은 관리자 클러스터에서 노드 자동 복구가 사용 설정된 경우 자동으로 복구됩니다. | 관리자 클러스터에서 실패한 작업자 VM은 관리자 클러스터에서 노드 자동 복구가 사용 설정된 경우 자동으로 복구됩니다. 관리자 클러스터의 제어 영역 VM을 복구하려면 관리자 클러스터의 제어 영역 VM 복구를 참조하세요. |
관리자 클러스터의 제어 영역 VM을 복구하려면 관리자 클러스터의 제어 영역 VM 복구를 참조하세요. |
| 예방 방법 | HA 방식으로 워크로드를 배포하여 중단 가능성을 최소화합니다. | HA 사용자 클러스터를 사용하여 중단 가능성을 최소화합니다. | — | — |
스토리지 오류
이 실패 시나리오에서는 VM의 불미스러운 성능 저하로 인해 VMDK 파일의 콘텐츠가 손상되거나 데이터 스토어 장애로 인해 etcd 데이터와 PersistentVolume(PV)이 손실될 수 있습니다.
etcd 오류
| 워크로드 실행 | 워크로드 관리 | 사용자 클러스터 관리 | 관리자 클러스터 관리 | |
|---|---|---|---|---|
| 중단 | 중단 없음 | 가능한 중단 및 수동 복구 | 중단 및 수동 복구 | 중단 및 수동 복구 |
| 설명 | — | 비HA 사용자 클러스터의 etcd 저장소 또는 HA 사용자 클러스터의 두 개 이상의 etcd 복제본이 실패하는 경우 중단이 발생합니다. | 비HA 사용자 클러스터의 etcd 저장소 또는 HA 사용자 클러스터의 두 개 이상의 etcd 복제본이 실패하는 경우 중단이 발생합니다. 관리자 클러스터의 etcd 복제본이 실패하는 경우 중단이 발생합니다. |
관리자 클러스터의 etcd 복제본이 실패하는 경우 중단이 발생합니다. |
| 예방 방법 | — | Google Distributed Cloud는 장애로부터 복구하는 수동 프로세스를 제공합니다. | Google Distributed Cloud는 장애로부터 복구하는 수동 프로세스를 제공합니다. | Google Distributed Cloud는 장애로부터 복구하는 수동 프로세스를 제공합니다. |
사용자 애플리케이션 PV 오류
| 워크로드 실행 | 워크로드 관리 | 사용자 클러스터 관리 | 관리자 클러스터 관리 | |
|---|---|---|---|---|
| 중단 | 가능한 중단 | 중단 없음 | 중단 없음 | 중단 없음 |
| 설명 | 실패한 PV를 사용한 워크로드가 영향을 받습니다. HA 방식으로 워크로드를 배포하여 중단 가능성을 최소화합니다. |
— | — | — |
부하 분산기 오류
이 실패 시나리오에서 부하 분산기 실패는 LoadBalancer 유형의 서비스를 노출하는 사용자 워크로드에 영향을 줄 수 있습니다.
| 워크로드 실행 | 워크로드 관리 | 사용자 클러스터 관리 | 관리자 클러스터 관리 | |
|---|---|---|---|---|
| 중단 및 수동 복구 | ||||
| 설명 |
대기 부하 분산기가 관리 제어 영역 VIP 연결을 복구할 때까지 몇 초간 중단됩니다. Seesaw를 사용하는 경우에는 서비스가 최대 2초, F5를 사용하는 경우에는 최대 300초 동안 중단될 수 있습니다. MetalLB의 장애 조치 중단 기간은 부하 분산기 노드 수가 증가함에 따라 증가합니다. 노드가 5개 미만이면 중단은 10초 이내입니다. |
|||
| 복구 | Seesaw HA는 백업 인스턴스를 사용하는 실패 및 장애 조치를 자동으로 감지합니다. Google Distributed Cloud는 Seesaw 장애로부터 복구하는 수동 프로세스를 제공합니다. |
|||
손상된 클러스터 복구
다음 섹션에서는 손상된 클러스터를 복구하는 방법을 설명합니다.
ESXi 호스트 오류 복구
Google Distributed Cloud는 vSphere HA를 사용하여 ESXi 호스트 장애로부터 복구를 제공합니다. vSphere HA는 ESXi 호스트를 지속적으로 모니터링하고 필요 시 다른 호스트에서 VM을 자동으로 다시 시작할 수 있습니다. 이는 Google Distributed Cloud 사용자에게 투명합니다.
VM 오류 복구
VM 오류에는 다음이 포함될 수 있습니다.
VM의 예기치 않은 삭제
스팸 저널 로그로 인해 읽기 전용이 되는 부팅 디스크와 같은 VM 부팅 디스크 손상
성능 디스크 또는 네트워크 설정 문제로 인한 VM 부팅 실패(예: IP 주소를 할당할 수 없으므로 VM을 부팅할 수 없음)
Docker 오버레이 파일 시스템 손상
업그레이드 실패로 인한 관리자 제어 영역 VM 손실
운영체제 문제
Google Distributed Cloud는 관리자 부가기능 노드, 사용자 제어 영역, 사용자 노드를 위한 자동 복구 메커니즘을 제공합니다. 이 노드 자동 복구 기능은 관리자 클러스터 및 사용자 클러스터별로 사용 설정할 수 있습니다.
관리자 제어 영역 VM은 Kubenete 클러스터에서 관리하지 않으며 가용성은 비즈니스 연속성에 영향을 주지 않는다는 점에서 특별합니다. 관리자 제어 영역 VM 실패를 복구하려면 Cloud Customer Care에 문의하세요.
스토리지 오류 복구
일부 스토리지 실패는 Google Distributed Cloud에 영향을 주지 않고 vSphere HA 및 vSAN으로 완화할 수 있습니다. 하지만 vSphere 수준에서 특정 스토리지 오류가 표면화되어 다양한 Google Distributed Cloud 구성요소에 대한 데이터 손상/손실이 발생할 수 있습니다.
클러스터 및 사용자 워크로드의 스테이트풀(Stateful) 정보는 다음 위치에 저장됩니다.
- etcd: 각 클러스터(관리자 클러스터 및 사용자 클러스터)에는 클러스터 상태(Kubernetes 객체)가 저장되는 etcd 데이터베이스가 있습니다.
- PersistentVolume: 시스템 구성요소와 사용자 워크로드 모두에서 사용됩니다.
etcd 데이터 손상 또는 손실 복구
etcd는 Kubernetes에서 사용자 애플리케이션 매니페스트를 포함한 모든 클러스터 상태를 저장하기 위해 사용하는 데이터베이스입니다. 사용자 클러스터의 etcd 데이터베이스가 손상 또는 분실되면 애플리케이션 수명 주기 작업이 작동을 중지합니다. 관리자 클러스터 etcd 데이터베이스가 손상 또는 분실되면 사용자 클러스터 수명 주기 작업이 작동을 중지합니다.
etcd는 데이터 손상 감지를 위한 신뢰할만한 빌트인 메커니즘을 제공하지 않습니다. etcd 데이터의 손상이나 손실이 의심될 경우 etcd 포드의 로그를 살펴봐야 합니다.
보류/오류/비정상 종료 루프 etcd 포드가 항상 etcd 데이터가 손상되거나 손실되었다는 의미는 아닙니다. etcd 포드를 호스팅하는 VM 오류로 인한 문제일 수 있습니다. 데이터 손상 또는 손실 시에만 다음과 같은 etcd 복구를 수행해야 합니다.
etcd 데이터 손상 또는 손실에서 (최근 클러스터 상태로) 복구하려면 클러스터에서 수명 주기 작업(예: 클러스터 생성, 업데이트 또는 업그레이드) 후 etcd를 백업해야 합니다. etcd 데이터를 백업하려면 관리자 클러스터 백업 및 사용자 클러스터 백업을 참조하세요.
etcd 데이터를 복원하면 클러스터가 이전 상태로 전환됩니다. 애플리케이션이 배포되기 전에 백업을 수행한 후 해당 백업을 사용하여 클러스터를 복원하는 경우 최근에 배포된 애플리케이션이 복원된 클러스터에서 실행되지 않습니다. 예를 들어 사용자 클러스터를 만들기 전에 스냅샷이 생성된 관리자 클러스터의 etcd 스냅샷을 사용하면 복원된 관리자 클러스터에서 사용자 클러스터 제어 영역이 삭제됩니다. 따라서 중요한 각 클러스터 작업 후 클러스터를 백업하는 것이 좋습니다.
다음과 같은 시나리오에서 etcd 데이터 손상이나 손실 장애가 발생할 수 있습니다.
데이터 손상 또는 손실로 인해 3-노드 etcd 클러스터(HA 사용자 클러스터)의 단일 노드가 영구적으로 손상됩니다. 이 경우 단일 노드만 손상되고 etcd 쿼럼은 계속 존재합니다. 이 시나리오는 etcd 복제본 중 하나의 데이터가 손상되거나 손실되는 HA 클러스터에서 발생할 수 있습니다. 실패한 etcd 복제본을 클린 상태의 새 복제본으로 교체하면 데이터 손실 없이 문제를 해결할 수 있습니다. 자세한 내용은 실패한 etcd 복제본 바꾸기를 참조하세요.
데이터 손실/손상으로 인해 두 개 이상의 3-노드 etcd 클러스터(HA 사용자 클러스터)의 노드가 영구적으로 손상됩니다. 쿼럼은 손실되므로 실패한 etcd 복제본을 새 복제본으로 교체해도 도움이 되지 않습니다. 클러스터 상태를 백업 데이터에서 복원해야 합니다. 자세한 내용은 백업(HA)에서 사용자 클러스터 복원을 참조하세요.
데이터 손실/손상으로 인해 단일 노드 etcd 클러스터(관리자 클러스터 또는 비HA 사용자 클러스터)가 영구적으로 손상됩니다. 쿼럼은 손실되므로 백업에서 새 클러스터를 만들어야 합니다. 자세한 내용은 백업(비HA)에서 사용자 클러스터 복원을 참조하세요.
사용자 애플리케이션 PV 손상 또는 손실 복구
특정 파트너 스토리지 솔루션을 사용하여 사용자 애플리케이션 PersistentVolume을 백업하고 복원할 수 있습니다. Google Distributed Cloud에 대해 검증된 스토리지 파트너 목록은 Anthos Ready 스토리지 파트너를 참조하세요.
부하 분산기 오류 복구
번들 Seesaw 부하 분산기의 경우 부하 분산기를 다시 만들어 장애에서 복구할 수 있습니다. 부하 분산기를 다시 만들려면 관리자 클러스터의 부하 분산기 업그레이드에 나와 있는 것과 동일한 버전으로 Seesaw를 업그레이드합니다.
관리자 클러스터 부하 분산기 오류가 발생하면 제어 영역이 제대로 작동하지 않을 수 있습니다. 제어 영역 액세스가 있는 관리자 제어 영역 VM에서 업그레이드를 실행합니다.
통합 부하 분산기(F5)의 경우 F5 지원에 문의하세요.
번들 MetalLB 부하 분산기의 경우 클러스터 노드를 부하 분산기로 사용합니다. 부하 분산기 문제에서는 자동 노드 복구가 트리거되지 않습니다. 수동 프로세스를 수행하여 노드를 복구할 수 있습니다.