HealthCheck, L4, GSLB

 

L4 switch HealthCheck

• 보통 L7 H/C(HTTP)를 사용하고, WAS에 `` /monitor/l7check`` 같은 Controller를 둔다.
• 방법 1) WAS 내리는 방법
  • WAS가 graceful shutdown 지원해야 함. (일단 받은 요청은 모두 처리하고 나서 종료해야 하니까)
  • WAS가 내려가는 시간 동안 delay 있음.
  • 비추천하는 방법.
• 방법 2) WAS controller에서 file exists 체크해서 응답하는 방법
  • 문제 시 파일만 삭제하면 exists가 false이므로 빠른 L4 절체가 가능하다. (서버를 내리는 것 보다 파일만 삭제하는게 더 빠르다.)
  • WAS 자체는 정상이므로 일단 받은 요청은 모두 처리 가능하다. WAS가 graceful shutdown 지원하지 않아도 사용 가능한 방법.
• 방법 3) nginx를 내리는 방법
  • nginx는 graceful shutdown 커맨드가 따로 있다.  
  • WAS에서 file check 안해도 되고 괜찮은 방법.
• 방법 4) ifdown으로 network interface를 아예 내려버리는 방법
  • graceful shutdown을 지원하지 않는듯. 가능한 방법인지 모르겠다.

 

GSLB HealthCheck

GSLB는 H/C 하는 DNS 서버라고 보면 된다.

GSLB에 대한 HealthCheck도 보통은 file로 한다.

 

구성도 1 : GSLB - L4 - 서버 구성인 경우

 

GSLB가 있더라도 여전히 L4 switch를 두어야 하는 이유는?

• 왜 L4 switch가 필요한가?
  • GSLB는 DNS 기반이기 때문에 GSLB만으로는 깔끔한 절체가 어렵다.
  • L4 없이 GSLB가 바로 앱서버(1~6)에 연결된 구조라고 가정하면, client는 1~6의 IP 중 하나를 가지고 있게 됨. 이 때 서버 1번을 절체하면, 1번 IP를 가지고 있는 client는 DNS 갱신 되기 전 까지 에러.
  • 반면 [GSLB - L4 - 앱서버] 구조에서는 client는 L4 IP만 가지고 있기 때문에 깔끔하게 절체 가능.
• L4 switch에서 app 서버로 H/C가 필요한 이유?
  • IDC-2의 3번 서버에 문제가 생긴 경우, 3번 서버만 제거하는 방법? L4가 앞에 있어 GSLB H/C만 가지고는 불가능하다.
  • GSLB는 DNS기반으로, IDC-2의 L4 VIP를 반환하기 때문. IDC-2 L4 VIP 뒤에 특정 서버를 절체하려면 L4에 대한 H/C 제어가 필요하다.

• GSLB H/C는 L4 H/C(TCP)가 아니라 L7 H/C(HTTP)로 해야 하는 이유?
  • H/C가 없는 GSLB는 그냥 일반 DNS이므로, 어떤 형태로든 H/C가 반드시 필요하다.
  • L4 H/C하는 경우는 아래 케이스를 커버하지 못한다. (L4 switch에 대한 H/C가 아니라 layer4의 TCP H/C를 의미한다.)
    • IDC-2의 1, 2, 3번 모든 서버에 장애가 발생했고, L4 스위치 자체는 제대로 동작하는 케이스.
    • L4 뒤의 모든 서버 절체했다고 하더라도, L4 스위치 자체가 정상이면 L4 H/C(TCP SYN) 결과는 정상이므로  GSLB는 여전히 IDC-2의 L4 VIP 반환한다.
  • 반면 L7 H/C 하는 경우, [L4 뒤의 서버가 하나라도 살아있으면 H/C 정상, 모든 서버를 절체하게 되면 H/C 실패]한다.
    • 모든 서버 절체하는 경우 GSLB는 IDC-2의 L4 VIP를 반환하지 않는다.

 

구성도 2 : GSLB - 인증서관리Pool - L4 - 서버 구성인 경우

(기록용) SSL Offloading Server에서 rate limit이나 path 차단 등의 기능을 지원하기 때문에 nginx가 담당하던 기능을 옮긴 후 nginx를 제거하려고 검토 해 보았으나,
1. SSL Offloading Server 관리 주체가 서비스팀이 아니라 인프라팀이라 긴급 대응이 어렵다는 점,
2. nginx에서 사용하고 있는 모듈들 (특히 인증 모듈)은 SSL Offloading Server에서 지원하지 않는다는 점
때문에 nginx 유지.

• GSLB는 SSL Offloading Pool IP를 반환. 따라서 client는 SSL Offloading Pool IP를 보고 있다는 점이 구성도 1과 다른 점.
• SSL Offloading Server에서도 이중화하고, GSLB로도 이중화하고 있는데, 이렇게 중복으로 하는 이유는?
  • SSL Offloading Server에서 양측 IDC 연결이 반드시 필요한 이유? (h/c 기능도 반드시 지원되어야 함.)
    
    • [IDC-2의 L4 뒤쪽 Origin이 모두 down 된 상황 + IDC-2의 SSL Offloading Pool은 정상인 상황] 대응하기 위해 필요
    • IDC-2의 SSL Offloading Pool은 GSLB h/c를 통과하기 때문에 GSLB는 IDC-2 SSL Offloading Pool IP를 반환함. 이 때 SSL Offloading Pool이 IDC-2의 L4에만 연결되어 있다면 client에 error 반환.
    • 반면 SSL Offloading Pool에 IDC-1, IDC-2 L4가 모두 연결되어 있다면, IDC-2 L4에 대한 SSL Offloading Pool의 h/c는 실패, IDC-1에 대해서는 성공이므로 SSL Offloading Pool은 모든 패킷을 IDC-1 L4로 보내서 정상적인 서비스 가능.
    • -----
    • SSL Offloading Pool이 GSLB h/c를 통과하지 않게끔 세팅하는 방법도 있긴 함. 이렇게 구성하는 경우 GSLB에서 빠지게 되므로 양측 IDC 연결하지 않아도 client가 반영구적 장애를 경험하지는 않으나, DNS 갱신 딜레이 동안은 장애를 경험한다는 것이 단점.
    • 게다가 SSL Offloading Pool이 전사에서 공유하는 Pool이라면, 한 팀에서 Origin 장애가 발생해도 다른 팀 Origin 서빙을 위해 SSL Offloading Pool은 여전히 정상이어야만 함. (GSLB에서 빠지면 안된다)
  • SSL Offloading Server에도 분배기능, h/c가 있는데 GSLB가 반드시 추가로 필요한 이유?
    • SSL Offloading Server를 포함한 IDC 전체 장애인 경우를 대응하기 위해 필요

SSL Offloading Pool이란? (== SSL Termination Platform)