백엔드 서비스 기반 외부 패스 스루 네트워크 부하 분산기를 구성하면 기본 백엔드의 가상 머신(VM) 인스턴스 간에 연결을 배포한 후 필요한 경우 장애 조치 백엔드를 사용하도록 전환할 수 있습니다. 장애 조치는 가용성을 높이는 방법을 제공하는 동시에 기본 백엔드 VM이 정상이 아닌 경우 워크로드 관리 방법에 대한 더 많은 통제권을 제공합니다.
이 페이지에서는 외부 패스 스루 네트워크 부하 분산기의 장애 조치 관련 개념과 요구사항을 설명합니다. 외부 패스 스루 네트워크 부하 분산기 장애 조치를 구성하기 전에 다음 문서의 개념 정보를 숙지해야 합니다.
장애 조치를 구성하면 부하 분산기의 표준 트래픽 분산 알고리즘이 수정되므로 이 개념을 이해해야 합니다.
기본적으로 백엔드를 외부 패스 스루 네트워크 부하 분산기의 백엔드 서비스에 추가하면 이 백엔드가 기본 백엔드가 됩니다. 백엔드를 부하 분산기의 백엔드 서비스에 추가하거나 나중에 백엔드 서비스를 편집하여 백엔드를 장애 조치 백엔드로 지정할 수 있습니다. 장애 조치 백엔드는 기본 VM의 구성 가능한 비율이 상태 점검을 통과하지 못한 경우에만 부하 분산기로부터 연결을 수신합니다.
지원되는 백엔드
인스턴스 그룹(관리형 및 비관리형) 및 (GCE_VM_IP 엔드포인트가 있는) 영역 NEG는 백엔드로 지원됩니다. 편의상 이 페이지의 예시에서는 비관리형 인스턴스 그룹을 보여줍니다.
관리형 인스턴스 그룹을 자동 확장 및 장애 조치와 함께 사용하면 활성 풀이 기본 및 장애 조치 백엔드 사이에서 장애 조치 및 장애 복구를 반복할 수 있습니다. 이 설정이 도움이 되는 배포도 있으므로 Google Cloud는 관리형 인스턴스 그룹에 장애 조치를 구성하지 못하게 하지 않습니다.
아키텍처
다음 예시는 기본 백엔드 하나와 장애 조치 백엔드 하나가 포함된 외부 패스 스루 네트워크 부하 분산기를 보여줍니다.
- 기본 백엔드는
us-west1-a의 비관리형 인스턴스 그룹입니다. - 장애 조치 백엔드는
us-west1-c의 다른 비관리형 인스턴스 그룹입니다.
다음 예시는 두 개의 기본 백엔드와 두 개의 장애 조치 백엔드가 us-west1 리전의 두 영역 사이에 분산된 내부 패스 스루 네트워크 부하 분산기를 보여줍니다. 이 구성은 모든 기본 또는 모든 장애 복구 백엔드에 대한 단일 영역에 의존하지 않으므로 안정성을 높입니다.
- 기본 백엔드는 비관리형 인스턴스 그룹
ig-a및ig-d입니다. - 장애 조치 백엔드는 비관리형 인스턴스 그룹
ig-b및ig-c입니다.
장애 조치 중에 두 기본 백엔드 모두 비활성 상태가 되고, 두 장애 조치 백엔드의 정상 VM이 활성화됩니다. 이 예시에서 장애 조치가 작동하는 방법에 대한 자세한 설명은 장애 조치 예시를 참조하세요.
백엔드 인스턴스 그룹 및 VM
외부 패스 스루 네트워크 부하 분산기의 인스턴스 그룹은 기본 백엔드 또는 장애 조치 백엔드입니다. 백엔드를 백엔드 서비스에 추가할 때 또는 백엔드를 추가한 후 편집하여 백엔드를 장애 조치 백엔드로 지정할 수 있습니다. 그렇지 않으면 기본적으로 인스턴스 그룹은 기본 그룹이 됩니다.
기본 백엔드와 장애 조치 백엔드 여러 개를 부하 분산기의 백엔드 서비스에 추가하면 단일 외부 패스 스루 네트워크 부하 분산기에서 구성할 수 있습니다.
기본 VM은 기본 백엔드로 정의한 인스턴스 그룹의 구성원입니다. 부하 분산기가 장애 조치 백엔드를 사용하도록 전환하지 않는 한 기본 백엔드의 VM은 부하 분산기의 활성 풀(다음 섹션에서 설명)에 참여합니다.
백업 VM은 장애 조치 백엔드로 정의한 인스턴스 그룹의 구성원입니다. 장애 조치 백엔드의 VM은 기본 VM이 비정상이 될 때 부하 분산기의 활성 풀에 참여합니다. 장애 조치를 트리거하는 비정상 기본 VM 수는 구성 가능한 백분율입니다.
한도
- 인스턴스 그룹. 기본 백엔드 인스턴스 그룹과 장애 조치 백엔드 인스턴스 그룹이 각각 최대 50개씩 있을 수 있습니다.
활성 풀
활성 풀은 외부 패스 스루 네트워크 부하 분산기에서 새 연결을 전송하는 백엔드 VM 모음입니다. 활성 풀의 백엔드 VM 구성원은 장애 조치 정책의 설명대로 정상인 백엔드와 지정할 수 있는 조건에 따라 자동으로 계산됩니다.
활성 풀은 기본 VM과 백업 VM을 결합하지 않습니다. 다음 예시에서는 사용 가능한 구성원을 보여줍니다. 장애 조치 중 활성 풀에는 백업 VM만 포함됩니다. 일반 작업(장애 복구) 중 활성 풀에는 기본 VM만 포함됩니다.
장애 조치 및 장애 복구
장애 조치 및 장애 복구는 백엔드 VM을 부하 분산기의 활성 풀 안과 밖으로 전환하는 자동 프로세스입니다. Google Cloud가 활성 풀에서 기본 VM을 삭제하고 정상적인 장애 조치 VM을 추가하는 프로세스를 장애 조치라고 합니다. Google Cloud가 이를 되돌리는 프로세스를 장애 복구라고 합니다.
장애 조치 정책
장애 조치 정책은 Google Cloud가 장애 조치 및 장애 복구를 위해 사용하는 매개변수의 모음입니다. 각 외부 패스 스루 네트워크 부하 분산기에는 여러 설정이 포함된 하나의 장애 조치 정책이 있습니다.
- 장애 조치율
- 모든 백엔드 VM이 비정상적인 경우 트래픽 차단
- 장애 조치 및 장애 복구 시 연결 드레이닝
장애 조치율
구성 가능한 장애 조치율은 Google Cloud가 언제 장애 조치 또는 장애 복구를 수행하면서 활성 풀의 구성원을 변경할지 결정합니다. 이 비율은 0.0에서 1.0 이내의 값입니다.
장애 조치율을 지정하지 않으면 Google Cloud에서 기본값 0.0이 사용됩니다. 이 기본값에 의존하는 대신 사용 사례에 적합한 수로 장애 조치율을 설정하는 것이 좋습니다.
| 조건 | 활성 풀의 VM |
|---|---|
|
모든 정상 기본 VM |
하나 이상의 백업 VM이 정상인 동시에 다음 조건을 만족할 경우:
|
모든 정상 백업 VM |
| 모든 기본 VM 및 모든 백업 VM이 비정상인 동시에 이런 상황에 부하 분산 장치가 트래픽을 차단하도록 구성해 놓지 않은 경우 | 모든 기본 VM, 최후의 수단 |
다음 예시는 활성 풀의 멤버 자격을 설명합니다. 계산 예시를 보려면 장애 조치 예시를 참조하세요.
- 장애 조치율이
1.0이면 모든 기본 VM이 정상이어야 합니다. 적어도 하나의 기본 VM이 비정상이 되면 Google Cloud는 장애 조치를 수행하여 백업 VM을 활성 풀로 옮깁니다. - 장애 조치율이
0.1이면 기본 VM의 10% 이상이 정상이어야 합니다. 그렇지 않으면 Google Cloud가 장애 조치를 수행합니다. - 장애 조치율이
0.0이면 모든 기본 VM이 비정상일 때만 Google Cloud가 장애 조치를 수행합니다. 하나 이상의 기본 VM이 정상인 경우에는 장애 조치를 수행하지 않습니다.
외부 패스 스루 네트워크 부하 분산기는 트래픽 분산 알고리즘에 따라 활성 풀 내에 있는 VM 간에 연결을 배포합니다.
모든 백엔드 VM이 비정상적인 경우 트래픽 차단
기본적으로 모든 기본 및 백업 VM이 비정상적인 경우 Google Cloud는 모든 기본 VM 사이에 새로운 연결을 배포합니다. 이는 최후의 수단으로 사용됩니다.
원하는 경우 모든 기본 VM과 백업 VM이 비정상적이면 외부 패스 스루 네트워크 부하 분산기가 새 연결을 차단하도록 구성할 수 있습니다.
장애 조치 및 장애 복구 시 연결 드레이닝
장애 조치 정책에 연결 드레이닝을 사용 설정하면 연결 손상을 방지하기 위해 장애 조치나 장애 복구 후에도 기본 또는 장애 조치 인스턴스 그룹의 인스턴스에 대해 설정된 연결이 계속 연결이 설정된 인스턴스로 전송됩니다. 장애 조치 정책에서 연결 드레이닝을 중지하면 기존 연결이 장애 조치 또는 장애 복구 중에 즉시 종료됩니다.
부하 분산기의 프로토콜이 TCP이면 다음 결과가 적용됩니다.
연결 드레이닝은 기본으로 활성화되어 있습니다. 백엔드 VM이 부하 분산기의 활성 풀에 있지 않더라도 기존 TCP VM은 현재 백엔드 VM을 유지할 수 있습니다.
장애 조치 및 장애 복구 이벤트 중에 연결 드레이닝을 사용 중지할 수 있습니다. 장애 조치 및 장애 복구 중 연결 드레이닝을 사용 중지하면 설정된 TCP 세션을 포함한 모든 TCP 세션이 신속하게 종료됩니다. 백엔드 VM 연결은 TCP 재설정 패킷으로 종료될 수 있습니다.
장애 조치 및 장애 복구에서 연결 드레이닝 중지는 다음과 같은 상황에서 유용합니다.
백엔드 VM 패치. 패치 전에 기본 VM이 상태 점검에 실패하도록 구성하여 부하 분산기가 장애 조치를 수행하게 합니다. 연결 드레이닝을 사용 중지하면 모든 연결이 계획된 방식으로 신속하게 백업 VM으로 이동합니다. 이렇게 하면 기존 연결을 유지하지 않고도 업데이트를 설치하고 기본 VM을 다시 시작할 수 있습니다. 패치 후 Google Cloud는 충분한 수의 기본 VM(장애 조치 비율에 따라 정의된 만큼)이 상태 점검을 통과할 때 장애 복구를 수행할 수 있습니다.
데이터 일관성을 위한 단일 백엔드 VM. VM 하나만 모든 연결의 대상이 되도록 하려면 기본 VM에서 백업 VM으로 전환을 통해 기존 연결이 둘 다에서 지속되지 않도록 연결 드레이닝을 중지합니다. 이렇게 하면 특정 시점에 하나의 백엔드 VM만 유지하여 데이터 불일치를 줄일 수 있습니다.
장애 조치 예시
다음 예시에서는 아키텍처 섹션에 표시된 다중 영역 외부 패스 스루 네트워크 부하 분산기 예시의 장애 조치 동작을 설명합니다.
이 부하 분산기의 기본 백엔드는 비관리형 인스턴스 그룹입니다(us-west1-a의 ig-a 및 us-west1-c의 ig-d). 각 인스턴스 그룹에는 2개의 VM이 포함됩니다. 두 인스턴스 그룹의 VM 4개 모두는 기본 VM입니다.
ig-a의vm-a1ig-a의vm-a2ig-d의vm-d1ig-d의vm-d2
이 부하 분산기의 장애 조치 백엔드는 비관리형 인스턴스 그룹입니다(us-west1-a의 ig-b 및 us-west1-c의 ig-c). 각 인스턴스 그룹에는 2개의 VM이 포함됩니다. 두 인스턴스 그룹의 VM 4개 모두는 백업 VM입니다.
ig-b의vm-b1ig-b의vm-b2ig-c의vm-c1ig-c의vm-c2
정상 기본 VM 수가 2보다 작을 때 새 연결이 백업 VM으로 전달되도록 이 부하 분산기에 대해 장애 조치 정책을 구성한다고 가정해보세요. 이를 수행하기 위해서는 장애 조치율을 0.5(50%)로 설정합니다. Google Cloud는 장애 조치율에 기본 VM 수를 곱하여 정상 상태여야 하는 기본 VM의 최솟값을 계산합니다. 4 × 0.5 = 2
네 개의 기본 VM이 모두 정상적인 경우 Google Cloud는 모든 VM에 새로운 연결을 배포합니다. 기본 VM이 상태 점검에 실패하는 경우 다음이 발생합니다.
vm-a1및vm-d1이 비정상이 되면 정상 기본 VM 수가 최솟값 이상이기 때문에 Google Cloud가 남은 두 정상 기본 VM인vm-a2및vm-d2사이에 새 연결을 분산합니다.vm-a2도 상태 점검이 실패하여 정상 기본 VM이vm-d2하나만 남게 되면, Google Cloud가 정상 기본 VM 수가 최솟값보다 작아진 것을 인식하여, 장애 조치를 수행합니다. 활성 풀이 4개의 정상 백업 VM으로 설정되고 새 연결이 이 4개 사이에 분산됩니다(인스턴스 그룹ig-b및ig-c).vm-d2가 정상 상태로 남아도 활성 풀에서 삭제되고 새 연결을 수신하지 않습니다.vm-a2가 복구되고 상태 점검을 통과하면 Google Cloud가 정상 기본 VM 수가 최솟값 2 이상인 것을 인식하여, 장애 복구를 수행합니다. 활성 풀이 2개의 정상 기본 VM인vm-a2및vm-d2로 설정되고, 새 연결이 이들 간에 분산됩니다. 모든 백업 VM이 활성 풀에서 제거됩니다.다른 기본 VM이 복구되고 상태 점검이 통과하면 Google Cloud는 해당 VM을 활성 풀에 추가합니다. 예를 들어
vm-a1이 정상이 되면 Google Cloud는 정상인 3개의 기본 VM인vm-a1,vm-a2,vm-d2로 활성 풀을 설정하고, 새 연결을 배포합니다.
다음 단계
- 장애 조치를 사용하는 외부 패스 스루 네트워크 부하 분산기를 구성하고 테스트하려면 외부 패스 스루 네트워크 부하 분산기에 대한 장애 조치 구성을 참조하세요.
- 백엔드 서비스로 외부 패스 스루 네트워크 부하 분산기를 구성하고 테스트하려면 외부 패스 스루 네트워크 부하 분산기 설정을 참조하세요.