서버의 잦은 다운시 해결책은 뭘까요?

위에서 좋은 말씀을 많이 해주셨네요.

굳이 따로 추가적으로 적지 않아도 될 만큼 말이지요.

뭐 혹시나 나중에라도 이런 경우를 겪으시는 분들이나 이래저래 검색엔진을 타고 들어오실 분들을 위해서 이런 경우를 겪을때의 해결책에 대해서 한번 나열을 해 보도록 하지요.

일단 해당 시스템에 대한 시스템 로그를 남기고 확인하는것이 중요하지요. 하다못해 시스템이 살아있는 경우라면 dmesg를 확인하거나 시스템이 뻗어서 리부팅해버리는 경우라면 /var/log/messages* 파일들을 확인해 보시는것이 1차적인 순서겠지요.

그리고 이런 시스템 다운 증상이 주기적으로 나타난다면 sysstat(레드햇 기준입니다) 서비스를 가동하여 주요 시스템 sar 값을 남기고 실제 서비스 운용시 서비스 프로세스나 cpu 사용량, 메모리 사용량등에 어떤 특별한 문제가 있는지, 서비스가 죽을때 context switch가 과도하게 많이 일어나는지, 물리적 메모리 사용량은 얼마나 되는지, 스왑 사용량은 얼마나 되는지 등을 확인하시는것이 중요하겠지요.

이와 연관해서 top 내용만 보지 마시고, 너무 top은 신뢰하지 마시고 iostat이나 vmstat 값을 실시간으로 띄워두시거나, 혹은 계속적으로 모니터링하기는 불가능한 상황이시라면 watch 등을 이용하시거나, 아니면 vmstat 등의 출력을 특정 파일로 보내도록 프로세스를 작동 후 시스템 상황을 살펴보시는 것도 좋겠지요.

그리고 만일 프로세스 뿐만이 아니라 시스템이 down될 경우라면 하드웨어도 왠지 의심이 가지요.

pc급에서는 잘 만나볼 수 없지만 어느정도 이상 서버라는 개념이 있는 서버라면 시스템 내에 IPMI Based의 시스템 관리방식을 제공합니다. 특히 어떤 시스템이 Down이 될 정도의 하드웨어의 물리적 이슈가 있다면 이를 SEL(System Event Log)에 남겨두고 이벤트화 하여 관리를 하지요. 서버별로 이를 CMOS BIOS에서 BMC SEL Log 항목에서 확인이 가능한 서버가 있는가 하면 영 확인이 안되는 서버도 있곤 합니다. (인텔 화이트박스들이 그런 경우가 많지요)

만일 OS상에서 On-Line 으로 SEL Log를 확인하시려면 /etc/init.d/ipmi start 하셔서 ipmi를 활성화하시고 - 일단 활성화가 안된다 하면 해당 메인보드에서 ipmi를 지원하지 않는겁니다. - ipmitool을 이용해서 몇가지 항목을 체크해볼 수 있겠지요.

뭐 간단하게 sel log를 확인하려면 ipmitool sel list 명령어로 SEL log를 확인해본다거나, 명확하게 신뢰는 가지 않습니다만 ipmitool sdr 이나 ipmitool sensor 등으로 주요 하드웨어 항목을 체크해 보실수도 있습니다.

아마 이 정도라면 기본적인 항목은 체크가 된다고 보실 수 있지요.

기타 하드웨어 장애 이슈의 경우 개념있는 서버들은 기본적으로 전면 패널에 하드웨어중 어떤 부분이 문제가 있는지 LED로 나타내주는 경우도 있고, 좀 개념이 부족한 서버는 어디가 문제가 있는지는 안나오는데 일단 문제가 있다고 LED로 표시만 해줘서 엔지니어의 속을 태우기도 합니다.

제가 많은 서버들을 오랫동안 만져보질 못하고 IBM에 대해서만 경험이 있는지라, 대략 IBM 기준으로만 말씀을 드리자면 IBM같은 경우는 얼마전부터 PC-Doctor 라고 하는 녀석을 ROM상에 포함하고 있어서 주요 하드웨어 항목을 스스로 체크하고, 하다못해 메모리 불량의 경우도 정확하게 메모리가 불량이라거나 하는 부분들을 체크할 수 있도록 하는 기능들을 포함하고 있습니다.

이런 정도면 일반적인 경우의 장애는 어느정도 해결이 가능하지요.

기타 필요하다면 snmp 서비스를 이용하고, 여기에 주요 시스템 사용량 내역은 MRTG나 RRTTOOL을 이용해서 좀 더 그래피컬하게 모니터링을 할 수도 있겠고, 프로세스 분석이 필요하면 돌아가고 있는 프로세스를 strace해버리고, 영 안되면 gdb와 기타등등의 다양한 프로파일링 툴을 이용해서 프로세스 프로파일링에 들어가고 하는 고단하고 따분하고 지루하며 참 답답할수밖에 없는 방식으로 접어들게 됩니다. 시스템 프로파일링을 위해서 Oprofile을 이용하기도 하고, 정말 죽긴 죽는데 대책이 없다!! 하면 그냥 netdump나 diskdump를 이용해서 메모리 덤프를 떠서 이를 레드햇등의 업체에 보내서 덤프 분석을 의뢰하는 지경에 이르는 경우도 있지요. 보내놓으면 금방 답이 오느냐 하면 그것도 아니고 말이지요. 짧게는 몇주에서 길게는 몇달까지도 걸립니다.

그런데 재미있는 경우가 무엇이냐 하면 이렇게 몇달을 기다리다가 문득 생각나서 OS를 업데이트를 탁 하고 했더니!! 아무런 이상없이 잘 돌더라 하는 경우도 생기고 하는 것이지요.

그래서 결국 하고자 하는 이야기는, 처음부터 하드웨어와 OS, 소프트웨어의 Certification을 잘 확인해서 초반에 제안할때부터 잘 들어간다면 이런 일을 줄일 수 있지 않겠느냐 하는 이야기를 할 수밖에 없는겁니다. -_- 이게 상당히 원론적이고 아무렇지 않게 할 수도 있는 이야기입니다만, 위같은 과정을 수십 수백여차례 겪고 나면 결국 초반에 시스템 궁합 맞추는것이 그 무엇보다도 중요하다는것을 깨닫게 된답니다.

사실 각 요소요소만 따지고 들자면 이상이 있는 경우가 얼마나 있겠습니까? 지금 당장 우리가 쓰기에는 잘 돌지도 않고 문제가 된다고 하지만 실제로 남들은 그걸로 서비스도 잘 하고 편리하게 이용하고 있는데 말이지요. 결국은 어딘가 어긋나있는 부분이 있는데 그런 부분을 이해할 수 있는 엔지니어분들이 세계적으로도 그다지 많은편은 아니기 때문에 이런 문제점들이 발생을 하고, 또 이를 찾아내지 못해 원인 불명이라고 생각하고 서버를 재설치하거나 애꿎은 어플리케이션이나 OS나 하드웨어등을 탓하게 되는 경우가 많지요.

뭐 인생이 다 그렇답니다. -_-　
　
====================여기부터 식인어흥====================
어흥 몰라 어흥? 호랑이 어흥!! 떡 하나 주면 어흥!! 떡 두개 주면 어흥어흥!!