Networking - UDP Recieve Buffer errors이슈

좀있음 올한해 2013년도 마무리가 되는구나.

올해 뭘했나 생각해보면 흠 글쎄.....달라진게 뭘까 이직?업무?....글쎄...별로 내세울게 없는 부분일지도 모른다.

하아....힘들구나

요즘 XXX가상화인프라구축 프로젝트로 인해 카페나 블로그 많이 소홀했는데...사실업무가 바쁘기보다는 내가 게을러졌다고 봐도 무관하다...(나이가이제...쿨럭;;)

오늘은 몇주전 고객측의 Per-Call건에 대한 성능이슈장애처리중 맞이했던 이슈처리사항에 대해 간략하게 써보고자한다.

대충 내용은 이렇다.

환경

RedHat Enterprise Linux 6 update4

Application

JAVA

Syslog-ng

근본원인

1) ifconfig명령어로 확인했을시, frame error/drop packet counts가 지속적으로 늘어나고 있음이 확인되었다.

2) 실질적으로 대용량의 로그패킷을 해당 RHEL시스템이 분산처리하는 방식인데, 이때 UDP프로토콜을 통해 Rev받는 형태이다. 물론 netstat -su명령어를 통해 확인시, Buffer counts가 늘어나는 것을 확인할수 있었다.

참고예제)

[dhkim@redhat ~]$ ifconfig | more
eth0 : flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 0  (Local Loopback)슈
        RX packets 1936  bytes 149580 (146.0 KiB)
        RX errors 0  dropped 123  overruns 0  frame 123 <------------- frame errors counts
        TX packets 1936  bytes 149580 (146.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

dhkim@redhat ~]$ netstat -su
IcmpMsg:
    InType3: 1038
    OutType3: 1029
Udp:
    754 packets received
    1025 packets to unknown port received.
    0 packet receive errors
    1784 packets sent
    123 receive buffer errors   <-------------------- udp errors
    0 send buffer errors
UdpLite:
IpExt:
    InNoRoutes: 2
    InMcastPkts: 134
    OutMcastPkts: 143
    InOctets: 11151706
    OutOctets: 2117671
    InMcastOctets: 30574
    OutMcastOctets: 30934

사실 Networkinf 만큼 플랫폼입장에서 성능이슈 및 장애관련하여 검증하기가 너무 어렵다. 그럴것도 일반적인 신규인프라도입관련시, Server/Storage/Switch/PCI장치/Backup 등 관련된 부자재등이 구매되곤하지만 서비스를 위헌 백본 및 L4 등 상위레이어의 경우, 이미 고객사이트환경에 최적화되어있도록 구성이 되어있기 때문이다.

그렇다면 위 나열된 사항에 대해 하나씩 짚어보도록 하자.

1) frame / drop packet counts증가에 대한 근본원인
- 일반적으로 frame error count증가와 drop / error count증가 등과는 와는 밀접한 관계가 있으며, 대부분 물리적인 문제(NIC Driver Bug Fix, Switch Configure, Network Cable etc.)로 확인된다. 

그렇타면 소프트웨어적인 입장에서 frame error의 해석은 다음과 같다.

The attribute "frame" in the output of ifconfig basically indicates that there are communication problems (CRC errors, packet collision or physical problems in the device), as defined below:

그에 대한 가이드는 다음 URL을 통해 확인해보자.
http://www.cisco.com/en/US/docs/internetworking/troubleshooting/guide/tr1904.html

- 위에 대한 접근방법으로는 1차적 네트워크물리적인 환경파악이 필요했다.

- 두번째로는 ring 커널파라미터증가

- 세번째는 ChekckSumming off

[dhkim@redhat ~]$  ethtool -K ethN rx off 
[dhkim@redhat ~]$  ethtool -K ethN tx off

 

대부분 위 세가지로 frame및 drop 이슈가 close되었다고 생각된다. 완벽하지는 않지만 많은 변화를 엿보았다.

일반적으로 Parameter수정전에 하루정도의 모니터링 정보를 남기는것도 많은 도움을 줄수 있다

[dhkim@redhat ~]$ (date;ifconfig eth0) >> /tmp/packet-drop-test-$(hostname)
[dhkim@redhat ~]$ (date;ifconfig eth1) >> /tmp/packet-drop-test-$(hostname)

2) udp recieve errors counts증가

보통 위 상황에 대한 대처는 커널파라미터가 대부분의 권고사례일것이다.

나조차도 처음 접근된 부분이였으며, 또한 대부분의 시간을 할애하였기 때문이다. 하지만 여기서 엔지니어가 기억해둬야 할 사항이 있다. 한가지 부분에 접근시 어느정도 시간을 할애하였으나 근본적인 처리방법이 아니라고 판단시에는 과감히 버려야할 부분도 있기 때문이다.

대부분의 구글링 및 레드햇 KBASE의 경우 아래와 같은 가이드가 대부분일 것이다.

# cat /proc/sys/net/core/rmem_default
# cat /proc/sys/net/core/wmem_default
# cat /proc/sys/net/core/rmem_max
# cat /proc/sys/net/core/wmem_max
# cat /proc/sys/net/ipv4/udp_rmem_min
# cat /proc/sys/net/ipv4/udp_wmem_min

위에서 Rev부분만 사실 중요하지만 관련된 파라미터도 알아두자.

문제접근

- 사실 이 케이스의 경우, 지방이라는 특수성, 인터넷등 매체와의 단절된 환경으로 인해 많은 시간을 보내야 했다. 정확히 3~4일정도 소요된것으로 기억된다.

위 해결방법등 여러가지 나열해보았으나 실질적으로 가장 중요한 UDP Rev Packet 에러가 close되지 않는 이상, 고객측에게 설명하기 힘들었다.

아시다시피, 여기서 대부분의 플랫폼엔지니어입장에서는 정확한 Resolve포인트를 집어주기 힘들어졌다는것을 알고 있을것이다.. 그럼에도 불구하고 Application측에서의 튜닝 및 Packet herader size 수정 그리고 Java기반의 어플리케이션 요청하였으나, 몇달간 프로젝트수행한 현장인력에게 정확한 수정방법이 제안아닌 이상 도움이 안된다는것은 알고 있다.

3일째되는날 가장 중요한 키포인트를 알게되었다. 나로써는 처음알게된사실.....아니 기본적인 알고리즘을 알고 있었으나 실서비스환경에서의 장애상황을 본것은 처음일것이다.

[dhkim@redhat ~]$ netstat -upln

(Not all processes could be identified, non-owned process info

 will not be shown, you would have to be root to see it all.)

Active Internet connections (only servers)

Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    

udp        0      0 127.0.0.1:323           0.0.0.0:*                           -                   

udp        0      0 0.0.0.0:631             0.0.0.0:*                           -                   

udp        0      0 0.0.0.0:5353            0.0.0.0:*                           -                   

udp        0      0 0.0.0.0:56361           0.0.0.0:*                           -                   

udp        0      0 0.0.0.0:28103           0.0.0.0:*                           -                   

udp        0      0 0.0.0.0:68              0.0.0.0:*                           -                   

udp        16384      0 0.0.0.0:51              0.0.0.0:*                           -                java   

udp        0      0 0.0.0.0:123             0.0.0.0:*                           -                   

udp6       0      0 ::1:323                 :::*                                -                   

udp6       0      0 :::123                  :::*                                -                   

udp6       0      0 :::41096                :::*                                -

지속적으로 모니터링중에 netstat -upln 명령어로 확인시 UDP Rec error counts가 늘어남과 동시에 Recv-Q Counts full이 되고,  처리를 못해주는 현상을 확인할수 있었다. 즉 UDP Protocol환경에 51Port를 통해 Recv받는 Queue가 java process에 의해 정상적으로 처리하지 못하는 상황임을 알수 있었다.

해당 어플리케이션이 syslog-ng서비스도 가지고 있다는 것을 알았고, 결국 syslog-ng파일내에 Recv buffer size을 세션을 추가해야 함을 정보를 알수 있었다.

자세한 수정정보는 결론적으로 어플리케이션 개발자로부터 얻었지만, 플랫폼에서의 커널파라미터값과 처리하는 프로세스의 값을 동일시함에 따라 해당 이슈는 Closed되었다.

결론적으로 해당 이슈에 대한 결론적 방법은 고객사와의 관계적 부분이 있기 때문에 제시하기 어렵지만, 많은 도움이 되었으리라 본다.

추가적으로, 위 상황에 좀더 근본적으로 다가갈수 있도록 여러 Tools를 사용해보는것도 도움이 될수 있다.

- iptraf 실시간 패킷정보
- iperf 네트워크 Bandwidth측정툴 Server-Client
- ntop http://www.nmon.net/packages/rpm/x86_64/ntop/

그럼 이만 써야 겠다.

점점 글솜씨가 줄어드는것같네....;;