[NSX] NSX Load Balancer Monitor
NSX Load Balancer에서는 Server Pool에 등록된 각 Member들의 상태를 확인할 수 있도록, Health Check의 일환으로 Monitor 기능을 제공합니다.
본 글에서는 Monitor 설정 시,
Support Bundle에서 구성 내용을 확인하는 방법과,
각 Server Pool Member로 전달되는 Packet을 어떻게 확인할 수 있는지 알아보겠습니다.
우선 Monitor와 관련된 기술적인 내용은 다음과 같습니다.
Active Monitor는 실제 Service Traffic과 상관없이 Load Balancer가 ICMP와 같은 Packet을 보내서 확인하는 방식
Passive Monitor는 Backend Server로부터 RST flag가 설정된 Packet을 받는 경우 Backend Server 또는 Application이 Down 되었다고 판단하는 방식
Active Monitor는 문제가 발생한 서버를 감지하는데 다소 시간이 필요하고,
Passive Monitor는 반드시 실제 Client Connection에 문제가 생겨야만 증상을 감지하기 때문에,
주로 Active/Passive Monitor를 조합
Passive Monitor를 L7 Virtual Server에 연결된 Server Pool에 설정하면, TCP RST/SSL Handshake 오류 발생 시, 연결에 문제가 있는 것으로 판단
Passive Monitor를 L4 TCP Virtual Server에 연결된 Server Pool에 설정하면, TCP SYN에 대한 응답이 없거나 TCP RST로 응답이 오면, 연결에 문제가 있는 것으로 판단
Passive Monitor를 L4 UDP Virtual Server에 연결된 Server Pool에 설정하면, ICMP error 메시지가 수신되면, 연결에 문제가 있는 것으로 판단
Passive Monitor가 정해진 최대 횟수만큼 연속적으로 문제가 발생한 것으로 판단하면, Member Server는 일시적으로 일정 기간(timeout) 동안 Unavailable 상태로 간주되며,
일정 기간 이후에 새로운 Connection으로 Member에 연결 시도하여 만약 연결이 잘 되면 Member Server의 상태 정보를 Available로 변경하고 failed count도 0으로 초기화
하지만, 연결이 잘 되지 않으면, 추가 timeout 기간은 없음
Active Monitor는 현재 HTTP/HTTPS/TCP/UDP 그리고 ICMP Protocol에 대해서 지원 가능하고, 한 Monitor는 하나의 Protocol 종류만 설정 가능
Monitor는 일반적으로 Server Pool Member의 IP Address와 Port를 이용하여 healthcheck를 수행하는데,
고객들은 Service Traffic이 오고가는 Port 보다 다른 Port를 통해서 healthcheck 하기를 원하는 경우가 있음
예를 들어, 다음과 같이 Server Pool은 80 Port로 되어 있는데,
Monitor 생성 시, Monitoring Port를 8080과 같이 다른 Port로 설정 가능
Active Monitor의 Healthcheck가 정해진 fail_count 만큼 연속적으로 실패하면 Server Pool의 Member 상태를 DOWN으로 변경하고,
이 후 Healthcheck가 정해진 rise_count 만큼 연속적으로 성공하면 Server Pool의 Member 상태를 UP으로 변경
HTTP Active Monitor의 경우에는 HTTP Request를 다음 Parameter들을 이용하여 수정 가능
- HTTP methods
- HTTP URL
- HTTP version
- HTTP request headers
- HTTP requesty body
만약 HTTP Response body match string이 지정되어 있다면, 해당 string과 Response body가 match가 되면 Member Server는 Healthy 한 것으로 판단
Response body string이 지정되어 있지 않고, Response Status Code 2xx으로 성공 Status Code가 설정되어 있다면 HTTP Healthcheck는 성공한 것으로 판단
HTTPS Active Monitor는 HTTP와 유사하게 설정할 수 있으나, HTTPS Profile을 사용해야 함
추가로 SSL Configuration을 통해서 SSL 관련 정보도 추가 가능
이외에 TCP Active Monitor는 TCP 3-way Handshake를 이용하고(실제 Data는 보내지 않음),
UDP Active Monitor는 보낸 Data와 받을 것으로 예상되는 Data가 지정되어야 함
ICMP Active Monitor의 경우에는 ICMP Echo Request를 보내고 ICMP Echo Reply Message를 받아야 Healthcheck가 성공한 것으로 판단
이제 실제로 Edge에서 수집된 Support Bundle에서 Monitor 설정을 확인하는 방법을 알아보겠습니다.
edge 디렉토리 하위에 있는 lb-pool 파일을 열어보면 각 Server Pool을 위해 설정된 Monitor의 ID 값을 확인할 수 있습니다.아래의 경우에는 해당 Server Pool에 Active Monitor 설정이 된 경우입니다
| ./edge/lb-pool { "id": { "left": 2375377081435964796, "right": 10814679071316573346 }, "display_name": "#####################", "algorithm": "ROUND_ROBIN", "snat_translation": { "auto_map": true, "port_overload": 32 }, "active_monitor_id": [ { "left": 9264802989201244908, >>>>>>>>>>>>>>>>>>>>>>>>>> "right": 10250281997735435104 >>>>>>>>>>>>>>>>>>>>>>>>>> } ], "member": [ { "ip_address": { "ipv4": ######### }, "weight": 1, "admin_state": "ENABLED", "backup_member": false }, ... { "ip_address": { "ipv4": ######### }, "weight": 1, "admin_state": "ENABLED", "backup_member": false } ], "tcp_multiplexing_enabled": true, "tcp_multiplexing_number": 6, "min_active_members": 1 }, |
이제 위에서 확인한 ID 값을 가지고, edge 디렉토리 하위에 있는 lb-monitor 파일을 확인해보면, 동일한 ID 값을 가지고 있는 Monitor 항목을 확인할 수 있습니다.
| ./edge/lb-monitor { "id": { "left": 9264802989201244908 , "right": 10250281997735435104 }, "display_name": "##################", "type": "TCP", "interval": 5, "timeout": 5, "rise_count": 3, "fall_count": 3, "monitor_port": "####", "tcp_monitor": {} }, |
이제 이러한 Monitor가 설정되어 있을 때, 특히 Active Monitor를 사용할 때, Server Pool에 등록된 각 Member Server로 어떤 Packet이 전달되는지 확인하는 방법을 알아보겠습니다.
우선, Logical Router에서 Server Pool에 등록된 Member Server들이 위치한 downlink interface의 UUID 값을 확인해야 합니다.
| edge-node-02> get logical-routers Thu Feb 29 2024 UTC 03:33:02.207 Logical Router UUID VRF LR-ID Name Type Ports Neighbors 736a80e3-23f6-5a2d-81d6-bbefb2786666 0 0 TUNNEL 4 6/5000 afe1567b-335f-40e2-beab-b478d1dac1e7 1 3 SR-Tier0-01 SERVICE_ROUTER_TIER0 6 2/50000 4f22c0b3-4a2f-4840-a8d2-cf8c797c087b 3 1 DR-Tier0-01 DISTRIBUTED_ROUTER_TIER0 5 3/50000 d533b216-a47a-4200-9eb3-007e68c3a024 4 9 SR-tier1-01 SERVICE_ROUTER_TIER1 5 2/50000 5bc895a7-8cc3-4332-9b1a-abe3bd64fa22 5 8 DR-tier1-01 DISTRIBUTED_ROUTER_TIER1 4 1/50000 96486497-be55-4cc3-8ae1-bbc7fe391d4b 6 11 SR-one-arm SERVICE_ROUTER_TIER1 5 1/50000 edge-node-02> vrf 5 edge-node-02(vrf[5])> get interfaces ... Interface : a62f9b69-c532-44a8-89a0-3e42c6292d94 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ifuid : 299 Name : infra-overlay-seg-3101-dlrp Fwd-mode : IPV4_ONLY Mode : lif Port-type : downlink IP/Mask : 172.31.1.1/24 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> MAC : 02:50:56:56:44:52 VNI : 71680 Access-VLAN : untagged LS port : 44c4d076-1e45-4632-bbf6-c458e1b3c6dc Urpf-mode : STRICT_MODE DAD-mode : LOOSE RA-mode : SLAAC_DNS_TRHOUGH_RA(M=0, O=0) Admin : up Op_state : up Enable-mcast : True MTU : 1500 arp_proxy : |
downlink interface의 UUID 값을 확인했으면, 이를 start capture command에서 이용하여 packet을 수집합니다.
아래는 Active Monitor에 Health를 감지할 Port로 tcp/80을 사용한 경우이며, Member가 1개(172.31.1.30) 밖에 없어서 정보가 제한적이지만, 실제로 Member 서버가 다수인 경우에는 여러 Member 서버들로 정해진 주기(default 5초)에 따라 TCP Syn Packet이 전달되는 것을 확인할 수 있습니다.
| edge-node-02> start capture interface a62f9b69-c532-44a8-89a0-3e42c6292d94 expr port 80 03:34:28.822724 02:50:56:56:44:52 > 00:50:56:a6:c6:4b, ethertype 802.1Q (0x8100), length 78: vlan 0, p 0, ethertype IPv4, 100.64.120.1.2444 > 172.31.1.30.80: Flags [S], seq 1575780441, win 64240, options [mss 1460,sackOK,TS val 1667462712 ecr 0,nop,wscale 8], length 0 <base64>AFBWpsZLAlBWVkRSgQAAAAgARQAAPHNvQABABj3OZEB4AawfAR4JjABQXeyAWQAAAACgAvrwAdIAAAIEBbQEAggKY2N2OAAAAAABAwMI</base64> ... 03:34:33.823793 02:50:56:56:44:52 > 00:50:56:a6:c6:4b, ethertype 802.1Q (0x8100), length 78: vlan 0, p 0, ethertype IPv4, 100.64.120.1.2456 > 172.31.1.30.80: Flags [S], seq 266293314, win 64240, options [mss 1460,sackOK,TS val 1667467713 ecr 0,nop,wscale 8], length 0 <base64>AFBWpsZLAlBWVkRSgQAAAAgARQAAPLiUQABABvioZEB4AawfAR4JmABQD99QQgAAAACgAvrwbGEAAAIEBbQEAggKY2OJwQAAAAABAwMI</base64> ... |
NSX Load Balancer를 사용하시면서, Server Pool에 Monitor 설정을 하신 경우,
만약 Monitor가 정상 동작하지 않는다고 판단하실 때,
우선 위에 설명드린 것과 같이 실제로 downlink interface를 통해 각 Member로 올바른 Packet이 전달되고 있는지부터 확인하시기 바랍니다.