Networking

[NSX] The memory usage on Edge node <UUID> has reached 85% which is at or above the high threshold value of 80%.

haewon83 2024. 7. 9. 14:59

 

NSX의 Edge Node에서 발생하는 Memory Alarm은 2가지 유형으로 구분해 볼 수 있습니다.

하나는 주요 프로세스 중 하나인 Datapath가 사용하는 여러 가지 Pool 중에 특정 Pool의 사용량이 임계치를 넘어서는 경우 발상하는 Alarm과 OS가 사용하는 Available Memory가 부족했을 때 발생하는 Alarm이 두 번째입니다.

 

본 케이스는 OS의 Available Memory가 부족했을 때 발생하는 Alarm의 원인 분석을 어떻게 진행했는지 알아보도록 하겠습니다.

 

[Symptom]

NSX Manager UI에 다음과 같은 "Edge Memory Usage High" Alarm 발생

 

[Troubleshooting Notes]

1. OS Memory 사용 현황 확인

/var/log/vmware/top-mem.log 파일을 확인해보면, 다음 결과와 같이 여러 Nginx worker process가 shutting down 상태로 많은 양의 Resident Memory를 점유 중

<TIMESTAMP>
top - 20:40:39 up 173 days, 19:09,  0 users,  load average: 2.12, 2.02, 1.91
Tasks: 350 total,   3 running, 347 sleeping,   0 stopped,   0 zombie
%Cpu(s):  4.4 us,  8.9 sy,  0.0 ni, 86.3 id,  0.0 wa,  0.0 hi,  0.3 si,  0.0 st
KiB Mem : 65278848 total,  2949136 free, 45807960 used, 16521752 buff/cache
KiB Swap:        0 total,        0 free,        0 used. 12528460 avail Mem
 
    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+    TGID COMMAND
   8687 lb        20   0 3259516   2.0g   2.0g S   0.0   3.3   2:06.25    8687 /opt/vmware/nsx-edge/bin/nginx -u 0324f7ba-f22a-41ff-b78a-493089e729c6 -g daemon off;
 339030 lb        20   0 3366168 678780 642532 S   0.0   1.0  97:56.65  339030 nginx: L4LB CP process
 339031 lb        20   0 3366168 678776 642528 S   0.0   1.0  96:55.68  339031 nginx: L4LB CP process
   6984 root      20   0   33.9g 581284 138528 S 105.9   0.9 455047:12    6984 /opt/vmware/nsx-edge/sbin/datapathd --no-chdir --unixctl=/var/run/vmware/edge/dpd.ctl --pidfile=/va+
 339029 lb        20   0 3714804 497588 112700 S   5.9   0.8 397:55.32  339029 nginx: worker process
2402248 lb        20   0 3488264 483460 110044 S   0.0   0.7 516:41.57 2402248 nginx: worker process is shutting down
2253196 lb        20   0 3590816 479248 109604 S   0.0   0.7  99:23.71 2253196 nginx: worker process is shutting down
 339027 lb        20   0 3695752 478576 112872 S   0.0   0.7 247:32.23  339027 nginx: worker process
1262206 lb        20   0 3374732 475880 109248 S   0.0   0.7 148:52.96 1262206 nginx: worker process is shutting down
3623434 lb        20   0 3802020 475656 108012 S   0.0   0.7  21:58.58 3623434 nginx: worker process is shutting down
3623433 lb        20   0 3795996 469576 107932 S   0.0   0.7  14:29.50 3623433 nginx: worker process is shutting down
...

 

2. NSX에서 LB에 대한 Reconfiguration이 발생하면, Nginx는 New worker process를 생성하고 기존 Old worker process는 아직 종료되지 않은 기존 connection을 계속 Handling하고 이 후, 기존 connection이 완료되면, Old worker process도 종료

문제가 되는 부분은 Old worker process들이 종료되지 않고 남아있다는 점

그렇다면 왜 Old worker process들이 종료되지 않고 남아 있는지 확인 필요

 

3. Old worker process들이 Handling하고 있는 connection을 다음 명령어를 이용하여 확인

root@edge-node-01:/# ip netns list
root@edge-node-01:/# ip netns exec <NAMESPACE_ID> netstat -tan -p

 

확인 결과, Old worker process들이 여전히 ESTABLISHED 상태의 Connection을 가지고 있음

ESTABLISHED Connection이 남아있기 때문에 이 Process는 종료될 수 없음

tcp        0      0 <VIP>:443       <CLIENT_IP>:63484      ESTABLISHED 2402248/nginx: work 
tcp        0      0 <VIP> :443      <CLIENT_IP>  :61990      ESTABLISHED 2402248/nginx: work 
tcp        0      0 <VIP> :443      <CLIENT_IP> :62633     ESTABLISHED 2402248/nginx: work 
tcp        0      0 <VIP> :443      <CLIENT_IP> :61437      ESTABLISHED 2402248/nginx: work 
...

 

4. 왜 Connection이 계속 ESTABLISHED 상태로 유지되는지 확인하기 위해 Packet 수집

root@edge-node-01:/# tcpdump -i kni-lrport-0

 

수집된 Packet을 확인해보면, 다음과 같이 매 30초마다 Client에서 LB VIP로 TLS Payload가 전달되는 것을 알 수 있음

1 2024-07-04 02:26:46.850470 <CLIENT_IP> <VIP> TLSv1.2 118 Application Data
...
4 2024-07-04 02:27:16.853255 <CLIENT_IP> <VIP> TLSv1.2 118 Application Data
...
7 2024-07-04 02:27:46.856428 <CLIENT_IP> <VIP> TLSv1.2 118 Application Data
...
10 2024-07-04 02:28:16.859044 <CLIENT_IP> <VIP> TLSv1.2 118 Application Data

 

[Conclusion]

1. 근본적인 문제 해결을 위해서는 Old worker process에 남아있는 ESTABLISHED 상태의 Connection들이 반드시 남아 있어야 하는 Connection인지를 확인하고, 그렇지 않다면 종료하는 방안을 검토

 

2. 일시적인 문제 증상 해소를 위해서는 Active Edge Node를 Maintenance Mode로 전환