안녕하십니까, 맨날 질문만 올리는 왜국서 일하는 무지랭이입니다. (__)
질문드릴 내용은
스위치의 성능이 떨어지면 보내는 패킷에 지연이 일어날 수 있는지 알고 싶습니다.
요전번에 5000ms 지연이 일어난다고 올린 적이 있습니다만,
열심히 확인해보니
상위전화서버 -> 운영중인서버 (정상) -> 운영중인서버 -> 하위서버(비정상 5000ms 지연발생)
이더군요
왼쪽이 받은 패킷이고 오른쪽이 보낸 패킷 입니다.
Asterisk로 운영중인 서버고요, 단순히 SIP / RTP 패킷을 재전송하는 용도로 사용하고 있습니다.
받은걸 다시 보내기만 하는 것이지요 (상위 사업자 제한사항이라 이렇게 사용하고 있습니다.)
서버 사용률은 낮았는데 (CPU 이용률 10%미만)
저렇게 되는 이유를 모르겠습니다.
스위치가 넷기어의 8포트짜리라서 그쪽을 의심하고 있습니다만
스위치가 어떤 상태이건 서버에서 UDP로 송신하는데 패킷캡쳐상 지연이 일어난다는게 이해가 가질 않습니다.
(서버가 12대인데 8포트 + 8포트 구성입니다. 저런 걸 넣어 둔 전임자와 GMO 영업을 때리고 싶습니다.)
혹시 스위치가 보내는 패킷에 그것도 서버에서 송신하는 패킷에 지연을 일으킬 수 있는지요?
아무쪼록 가르침을 부탁드립니다.
감사합니다.
재전송이 아닌, 원래 패킷이 5초 지연되어 들어가나요?
일단 패킷 캡쳐상에서 seq가 연속되고 있기도 하고요
혹시 더미허브(논메니지먼트 허브)급인가요??
재대로 확인할려면 포트 모니터링 장비 붙여서 패킷로스 확인해보는 편이 좋아 보입니다..
그 외 조심할 것은 케이블의 품질입니다..
전임자에게 물어보니 초기비용 몇만원 아끼려고 24포트가 아니라 8포트 붙였다는데
인터넷은 전용선을 깔아놨고요...
경영진도 그렇고 제정신이 아니었던 것 같습니다.
100 mbps 스위치가 아닌지 체크
일단 링크는 기가빗으로 나오네요
월요일에 업체 영업 담당에게 문의넣었는데
문의 폼으로 연락하라더니 아직까지 연락이 없네요.
그런데, 5ms도 아니고 5sec는 스위치문제로 생긴 지연이라고 보기에는 너무 과도합니다.
지금 캡쳐를 서버에서 하셨으니 보내고 받은 시점 역시 서버의 시간이고, 그렇다면 저 지연은 스위치가 아니라 서버에서 발생한거라고 보는게 타당한 것으로 사료됩니다.
서버 message log나 어플리케이션(asterisk)등 에서는 해당 시간대에 특별히 에러나 워닝 같은게 안보여서 원인을 찾는데 시간이 걸리고 있습니다.
따로 원인을 확인할 방법이 있을런지요?
(하드 배드 등으로 데이터가 재대로 못날라가고 지연되는 경우)
어느 서버에서 데이터 오류나 지연이 생기는지부터 확인하세요.. (여러 서버인지 그 서버 하나인지)
하위서버는 pbx입니다만 하위서버에 udp로 보내는 저래서 하위서버와는 무관하게 발생하는게 아닐까 생각하고 있습니다.
HDD 오류라면 뭘로 검사하는게 좋을지요?
부끄럽게도 아직도 리눅스(centos6 입니다)를 잘 모릅니다.
fsck를 쓰게되면 데이터가 다 날아간다고 절대 쓰지말라고 전임자에게 배웠는데 제 자신이 무지해서 무섭네요...
처음 리눅스 배울 때 꽤나 소리를 들어서요... ㅎ
(채크하다 서비스 끊어지면 골치)
하드에서 S.M.A.R.T 채크라는 것이 있는데 리눅스 명령어 중에 이것을 채크할 수 있다면 이 내용으로 하드의 건강상태를 짐작할 수 있습니다..
저도 리눅스는 거의 모르기에....
찾아보겠습니다 ㅎㅎ
fsck는 보통 논리적인 오류(파일시스템이나 볼륨의 메타데이터 정보 불일치 등)을 검사할 때 씁니다.
SMART 검사는 smartctl -t long /dev/sdX 같은 형태로 검사하시면 되고요,
이건 하드디스크 펌웨어에서 검사를 하는 것이기 때문에, 시스템이 크게 느려지거나 하는 문제는 없습니다.
그리고 정말 디스크 자체의 문제를 파악할 수 있습니다.
badblocks 는 OS 위에서 디스크를 읽으면서 테스트하는 것이기 때문에 다른 프로세스의 IO에 영향이 있을 수 있습니다.
디스크는 문제가 없지만, 케이블이 문제가 있다거나, SATA컨트롤러가 문제가 있다거나 하는 경우에는
SMART오류는 없는데, 실제 읽기 테스트를 할 때 문제를 발견하게 됩니다.
그리고 데이터를 읽을 때 오류가 발생해야만 문제라고 보는 것이 아니고,
오류가 없다고 하더라도 전송속도가 너무 느리거나, io wait가 높게 나오는 것도 문제가 있다고 봐야합니다.
그리고 fsck로 검사를 하다가 데이터를 날린다는 이야기는,
검사를 하는 것 자체는 문제가 없지만, fsck가 오류를 발견했을 때 수정을 시도하면서 문제가 발생하는 경우가 있습니다.
그게 OS 파티션이고, 마운트되어서 현재 사용중인 파티션이면 오류를 수정하면서 운나쁘게도 시스템이 다운될수도 있는 것이지요.
그리고 제 생각에도 윗분들 말씀처럼 스위치보다는 서버 문제일 가능성을 고려해보시는 것이 좋겠네요.
IO wait가 심하게 높은 경우에는 OS 커널 쪽에서 제때제때 IO 명령을 못 받아줄 수가 있는데요,
사용중인 디스크에 문제가 있거나 컨트롤러에 문제가 발생하면 그런 경우가 있을 수 있습니다.
일시적으로 시스템이 행이 걸렸다가 풀렸다가 하는거죠.
서버에서 SSD를 사용하는데 용량을 거의 풀로 사용하면서 프리징이 걸렸다 풀렸다 하면서 네트웍도 끊어졌다 붙었다 하는 그런 경우도 있었구요.
그리고 모든 경로를 다 확인해보셨는지요?
올려주신 그림에 reverse 방향의 delta는 올려주지 않아서요.
- 상위서버 -> 운영서버: 상위서버와 운영서버 양쪽에서 패킷 캡쳐해서 비교. 보통은 불가능해서 운영서버에서만 확인하죠.
- 상위서버 <- 운영서버: 상동
- 운영서버 -> 하위서버: 운영서버와 하위서버 양쪽에서 패킷 캡쳐해서 비교. (올리신게 하위서버에서 확인한 패킷을 올리신 것 같은데 맞나요?)
- 운영서버 <- 하위서버: 상동
제가 겪은 경우인데요, 고객사에서 제공한 IDC상면에 서버를 넣었는데 네트웍 대역폭이 부족해서 비슷한 상황이 발생한 적이 있습니다.
IDC의 서버들이 shared 네트웍을 사용하는데 장애발생 당시 고객사에서 배치로 파일전송을 하면서 (그것도 한낮에!!!) 대역폭을 몽땅 사용하고 있어서......
그냥 하루만 그랬으면 넘어갔을텐데 그분들이 뭘 잘못 만들었는지 일주일정도 계속 낮에 배치를 수동으로 돌리는 바람에 ㅋㅋㅋ
IDC랑 우리랑 계약한것도 아니니 대역폭 꽉 차서 장애나는건 우리는 모르고 고객사 담당자가 바뀌었는데 연락처 갱신을 안해서 고객사에서도 모르고 있었고...
고객사 사람이랑 같이 IDC들어가서 확인해보고 알았죠.