기업내 IT 환경이 복잡 다단해지면서, 여러 장애들로 관리자들은 골머리를 앓고 있다. 관리자는 장애가 발생했을 때 그 유형들도 다양해 장애 해결에 적잖은 시간을 투자해야한다. 기업 또한 장애가 해결될 때까지 업무가 마비돼 경제적 손실도 무시하지 못한다. 따라서 장애를 해결하기 위한 트러블슈팅은 관리자들이나 기업 모두가 관심을 쏟고 있다.
트러블슈팅은 장애가 발생했을 때부터 그 원인을 규명하고 장애를 복구할 때까지의 작업을 말한다. 트러블슈팅을 하기 위해서는 많은 장애 요인을 고려하고 넓은 각도에서 접근해야하기 때문에 관리자들은 어려움을 토로하고 있다. 따라서 다양한 활용사례들이 관리자에게 도움을 줄 수 있다. 이글을 통해 활용사례를 기반으로 한 트러블슈팅 방법론에 대해 알아본다.
트러블슈팅은 ▲ 문제 정의 ▲ 사실 수집 ▲ 원인 추론 ▲ 조치 방안 작성과 구현 단계로 나뉜다. 문제 정의는 현상을 파악하고 원인을 찾아내기 이전에 시스템의 문제를 명확히 표현, 규정하는 단계이다. 예를 들면 ‘웹 서버에 접속이 안된다’ ‘라우터로의 핑(ping)이 안된다’ ‘서버 접속 시간이 어제보다 오래 걸린다’ 등으로 현상을 밝히는 정도를 말한다. 문제 정의는 사실을 수집하는 근거를 마련할 뿐 아니라 경험에 따른 원인 추론에도 도움이 되기 때문에 구체적으로 기술하는 것이 바람직하다.
사실 수집은 정의된 문제에 대해 대략의 점검 항목과 내용을 결정하고, 그것에 적합한 솔루션을 선정하고 자료를 수집하는 단계를 의미한다. 반응 시간, 커넥션 파일 등 문제 유형에 맞는 솔루션을 선택해 수집하는 방법을 결정하는 것이 중요하다. 수집 방법은 구성 장비의 명령어를 통해 얻는 것이 대표적인데, 이런 명령어는 장비 상태를 모니터링하고, 장애 상황을 파악하는 기초 데이터를 얻을 수 있다.
그밖에도 각 네트워크 세그먼트 상태를 파악하는데 유용한 패킷 분석 툴과 트랜잭션(transaction)별 응답 시간을 클라이언트-네트워크-서버로 구분해 보여주는 애플리케이션 성능 툴을 통해서도 많은 정보를 얻을 수 있다.
경험과 정보, 원인 추론의 중심
장애가 발생한 원인을 추론하는 것은 수집된 자료를 바탕으로 문제 장비나 환경 등을 추론하는 단계다. 사실 수집을 통해 얻은 정보를 체계적으로 분석해 원인이 될 만한 부분으로 좁혀가는 것이 이 단계에서 매우 중요하다. 기존의 축적된 경험이나 제조업체의 정보가 필수적이다. 각각의 트러블슈팅 사례는 문서로 남겨 다른 트러블슈팅의 원인 추론 단계에서 사용하기도 한다.
원인 추론이 끝났다면, 각각의 원인에 따른 조치 방안을 마련하고 구현 단계를 거쳐 문제를 해결한다. 가장 가능성있는 방안부터 순서대로 작성하며 많은 것들을 한꺼번에 작업하지 않도록 하는 것이 바람직하다. 여러 방안을 동시에 수행하게 되면 결과적으로는 문제가 해결되더라도 원인을 정확히 파악하지 못하기 때문이다. 또한 트러블슈팅을 지역별/분야별로 나눠 수행하는 것 또한 큰 도움이 된다. (표 3)은 조치 방안을 작성한 예다.
지금까지 개괄적인 트러블슈팅의 단계를 파악했다면, 이제부터는 사례를 통해 자세히 트러블슈팅 방법론에 대해 알아본다.
A 증권사 홈 트레이딩 서비스의 MAC 플래핑 문제
파이어월의 트래픽 필터링으로 처리
홈 트레이딩 서비스는 웹 서비스를 제공하는 대표적인 사이트의 구성으로, 인터넷과 직접 연결돼 있어 사이트를 보호하기 위한 파이어월을 설치했다(그림 2). 또한 사용자가 인터넷 액세스를 하는데 발생하는 과다한 트래픽을 분산하기 위해 여러 파이어월에 4계층 스위치를 두는 등, 다소 복잡한 네트워크를 구성하고 있다.
이 네트워크에서 발생한 문제는 몇 개의 서버가 접속이 끊기며 그 서버로는 핑(Ping)조차 되지 않는 것이었다. 또한 인터넷에서 뿐만 아니라 내부의 동일 세그먼트에도 도달할 수 없다는 것이 문제가 됐다.
사실 수집 단계에서 두 가지의 로그를 발견했는데, 첫번째는 스위치2에서 몇몇 서버와의 링크가 다운됐다는 것이고, 두번째는 스위치1에서 4계층 스위치와 스위치2 간 특정 MAC 어드레스의 플래핑(Flapping)이 발생된다는 것이다. 링크가 다운된 포트가 접속이 끊겼던 서버 포트는 아니었지만, 플래핑 로그에 남겨진 MAC 어드레스가 문제를 일으킨 서버의 MAC 어드레스였기 때문에 원인 추론의 단서로 볼 수 있다.
보통 플래핑은 2계층 스위치로 구성된 네트워크에서 루핑(Looping)을 방지하기 위해 사용되는 스패닝트리에 문제가 생길 경우나 시스템을 이중화하기 위해 사용하는 프로토콜에서 같은 MAC 어드레스를 사용함으로써 주로 발생한다. 하지만 이 경우에는 적합하지 않았고, 좀더 정확한 사실 수집을 위해 패킷 분석기를 통해 4계층 접속 포트를 모니터링한 결과, 내부 스위치2에 접속된 서버의 MAC을 소스로 찍은 채 4계층 포트를 통해 거꾸로 들어오는 패킷이 있다는 사실을 알 수 있었다.
즉 그 구간의 동일 패킷이 나가는 것과 들어오는 것 두개씩 짝지어 있으며, 이것은 정상적인 경우에는 있을 수 없는 일이다. 왜냐하면 2계층 스위치는 내부 서버의 MAC 어드레스 테이블을 통해 스위칭하기 때문에 다른 포트로 패킷을 보내지 않기 때문이다. 하지만 서버와의 링크가 다운된다면 그 서버의 MAC 테이블은 초기화돼 사라지므로 스위치는 패킷을 전 포트로 복사해 보낸다(그림 3).
(그림 3)에서 서버1이 다운됐을 경우, 스위치2의 MAC 테이블에서 서버1의 어드레스가 삭제된다. 이때 서버2가 서버1과 통신하고 있었다면, 서버1으로의 패킷은 스위치2를 기준으로 전 포트로 플러딩(Flooding)이 발생한다.
그러므로 파이어월이 IP 어드레스만 보고 내부에 있는 서버로 여기고 패킷을 리다이렉트시키는 것을 MAC 어드레스 플래핑의 원인으로 생각할 수 있다(그림 4). 사실 어떤 기종의 스위치는 이런 MAC 플래핑 현상을 네트워크의 루핑(Looping)으로 여겨 대략 30초 동안 그 MAC 어드레스에 대해 포워딩 기능을 수행하지 않는다. 다시 말해 핑도 안 되며 몇몇 서버의 장애 현상이 모두 설명될 수 있다.
이런 원인에 따른 조치 방안은 기존 2계층 스위치를 플래핑 현상을 무시해버리는 장비로 교체하는 것과 장비는 그대로 두면서 파이어월 쪽으로 패킷을 보내지 않거나 받지 않도록 조정하는 것이다.
결국 (그림 5)에서처럼 내부 서버의 IP를 소스로 해 들어오는 트래픽을 파이어월 또는 4계층 스위치에서 필터링해 문제를 해결했다.
B 대학교 멀티캐스트 문제
멀티캐스트 어드레스 전환으로 문제 해결
이 대학은 ATM 지원 라우터나 스위치로 구성된 초고속 ATM 네트워크를 구축하고, 신규 방송 서버를 도입해 전체 세그먼트에 초고속 서비스를 준비하고 있었다. 이런 초고속 서비스 도입은 네트워크의 대역폭을 상당 부분 할당해야 하므로 세밀한 사전 계획이 중요해, 여러 각도의 방송 기획이 마련됐다.
이 대학은 방송 서비스를 시행한다면 원하는 사용자에게만 트래픽을 전송하는 멀티캐스트 방식이 적합하다고 판단했다. 멀티캐스트는 브로드캐스트 방식과는 달리 PC와 네트워크 장비간 IGMP(Internet Group Management Protocol)를 통해 방송을 보고싶은 정보를 교환해 특정 PC에 컨텐츠를 전송하는 것이다. 하지만 테스트 단계에서 멀티캐스트 서버를 구동하면 전체 네트워크로 데이터가 전송돼 많은 대역폭 낭비가 생겼고, 심지어 사용자들이 다른 업무를 볼 수 없는 지경이었다.
먼저 패킷 분석기로 PC와 네트워크 장비 간의 IGMP를 주고 받는 과정을 분석했고, 실제 멀티캐스트 패킷을 전송하는 2계층 스위치와 라우터의 로그를 살펴봤다. PC에서 프로그램을 띄우면 라우터에서는 정상적으로 IGMP 등록이 됐으며 패킷 레벨에서도 문제점을 찾아낼 수 없었다.
결국 스위치의 오동작을 의심해 sh multicast 명령으로 멀티캐스트 라우터를 확인하고, sh cam 명령어로 특정 포트의 멀티캐스트 어드레스가 등록되는지 확인했는데 모두 정상이었다.
결국 패킷 분석기를 통해 수집된 데이터를 분석해보니 IGMP 등록 과정이 아닌 사용하는 2계층의 멀티캐스트 MAC 어드레스에 문제가 있음을 알게됐다. 멀티캐스트 MAC 어드레스는 규격에서 상위단 IP 어드레스와 중복되는 부분이 있는데, IP 32개 당 1개의 MAC이 대응되는 방식이다.
보통 멀티캐스트 IP 어드레스에서 사용할 수 없는 어드레스가 있는데, 이 어드레스는 다른 용도로 고정되어 있기 때문이다. 고정된 IP 어드레스와 매칭되는 멀티캐스트 MAC 어드레스는 결국 더 많은 IP 어드레스를 사용하지 못하도록 한다. 224.1.1.1이 고정돼 사용할 수 없지만, 그것과 같은 MAC 어드레스를 사용하는 225.129.1.1도 사용할 수 없다는 뜻이다.
결국 멀티캐스트 그룹 어드레스를 바꾸는 것으로 이 문제는 해결할 수 있었다. 하지만 그 당시에 스위치 운영체제를 상위 버전으로 수 차례 업그레이드하는 조치 방안을 반복 수행했던 것을 생각하면, 사실 수집과 원인 추론 단계가 얼마나 중요한 지를 알 수 있다.
C 대학교 VPN 구현시 MTU 값
DF 비트 전환과 소프트웨어 업그레이드로 해결
서울과 대전에 캠퍼스를 둔 이 대학은 네트워크가 VPN (Virtual Private Network)으로 연결돼 있다. 대전 캠퍼스는 사용자가 인터넷+VPN 방식으로 서버에 접속하는 형태인데, VPN 피어(peer)는 별도의 VPN 게이트웨이를 두지 않고 인터넷 라우터의 VPN 기능으로 구현했다.
VPN이므로 대전 사용자들이 서버에 접속하기 위해서는 VPN 라우터에서 들어오는 패킷에 VPN 헤더를 붙이고 목적지 IP를 상위단 라우터로 지정하는 터널링 과정이 필요하다. 이 대학은 사용자가 서울 캠퍼스 서버에 접속해 업무를 진행할 때, 초기 화면 접속은 가능하지만 실제 업무를 할 수 없는 것이 문제였다.
VPN 트러블슈팅은 인터넷 구간을 살펴볼 수 없다는 것과 실제 패킷이 암호화로 인해 해독이 불가능하다는 단점이 지닌다. 즉, 사실 수집이 어렵고 원인 추론도 다양할 수 있다. 먼저 라우터에서 디버깅(Debugging) 기능을 수행해 VPN 라우터간 피어 형성 과정을 모니터링했고, 터널링을 통해 나가는 패킷 카운트를 보았는데 모두 정상이었다.
단 서울 VPN 라우터의 로그에서 ISP(Internet Service Provider) 라우터에서 ICMP(Internet Control Message Protocol)로 보내는 메시지를 발견했고, 내용을 분석 한 결과 VPN 라우터에서 MTU(Maximum Transmission Unit) 이상의 데이터를 전송한다는 것을 알 수 있었다. 일반적으로 라우터는 MTU보다 큰 데이터가 들어오면 적당히 나눠 전송한다. 하지만 서울 캠퍼스 서버와 라우터의 이더넷 구간을 패킷 분석기로 모니터링한 결과 서버에서 보내는 데이터 중 DF (Don’t Fragment) 비트가 1로 설정된 패킷이 많다는 것을 알 수 있었다. DF 비트는 앞에서 설명한 프래그먼트(Fragment)를 수행하지 못하도록 하는 옵션으로 1이 설정돼 있으면 라우터는 데이터를 나누지 못하고 VPN 헤더를 그대로 덧붙여 전송한다. 또한 상단 라우터에서는 MTU 값보다 큰 데이터가 넘어오면 전송을 해야한다는 것을 모르고 버릴 수도 있다.
조치 방안으로는 라우터의 이더넷 MTU를 VPN 헤더로 고려해 ‘1500-VPN Header’로 설정하는 것과 아예 서버에서 VPN 헤더에 맞춰 패킷을 보내는 것을 생각했다. 하지만 이같은 작업은 번거롭거나 불가능했다. VPN은 이런 문제가 빈번히 발생할 수 있기 때문에 장비들은 DF 비트를 0으로 만들어 전송한다. 장비마다 다르겠지만, DF 비트를 지원하지 않는 장비의 경우에는 소프트웨어를 업그레이드해 DF 비트를 조절할 수 있다.
D 증권사 UDP 포워딩 문제
TTL 값 수정으로 패킷 이동 가능
이 증권사는 시세 정보의 특성상 클라이언트의 요청에 대한 데이터 전송이라기 보다는 지속적인 업데이트를 필요로 해, UDP(User Datagram Protocol) 패킷 형식으로 데이터를 전송한다.
증권사 시세 UDP는 보통 모든 지점, 모든 사용자에게 전송되는데, 이 증권사는 특정 지역에 신규 라우터가 도입돼 시세가 전송되지 않는 문제가 발생했다. 그 특정 지점의 이더넷 네트워크에 패킷 분석기를 이용해 데이터를 살펴봤다. 실제로 패킷이 도달하지 않았고 서버에서부터 사용자까지의 구간에 있는 라우터의 인터페이스에서 ‘sh ip account’라는 명령어를 통해 데이터가 지점 라우터까지는 전송됐으나 그 라우터의 이더넷으로 나가지 않는다는 것을 발견했다.
시세를 전송할 때 UDP 패킷의 목적지 어드레스는 10.255.255.255 혹은 150.1.255.255 등의 브로드캐스트 어드레스를 사용하는데, 이는 네트워크 장비에서 기본적으로 막는 어드레스다(그림 11). 따라서 데이터를 받는 지점 라우터에는 이더넷으로 브로드캐스트 패킷을 포워딩하도록 설정해야 한다. 이런 명령어는 네트워크 장비의 버전에 따라 꼭 설정해야 되거나 설정하지 않아도 되므로 혼동을 가져올 수 있다.
다른 예로 시세 정보가 서버가 위치한 세그먼트에서는 보이는데 다른 세그먼트로는 전송되지 않는 경우다. 먼저 시세전송 라우터의 디버깅을 걸었더니 UDP 패킷이 이더넷 인터페이스로 들어오고 있는데, 다른 인터페이스로는 전송하지 않는 것이었다. 그러면 일단 라우터를 의심하게 되는데, 좀더 자세히 보고자 패킷 분석기로 서버 앞단에서 데이터를 수집해 분석했더니 원인은 다른 곳에 있었다.
데이터의 TTL(Time to Live) 값이 모두 1인 것이다. UDP 패킷은 브로드캐스트 어드레스를 사용하는 것이 일반적인데, 이는 2계층에서 도달할 수 있는 곳까지 보내라는 의미다. 따라서 서버가 TTL값을 1로 설정해 전송하는 경우가 있다. TTL은 패킷의 루프를 막기 위해 각 3계층 장비들은 패킷을 받으면 1씩 줄여 전송하는 방식으로 일정 구간을 지난 패킷을 자동으로 소멸시키는 원리다.
즉 디코드(Decode) 내용에서처럼 TTL 값은 1인 데이터는 라우터에서 TTL이 0이 돼 다른 세그먼트로 전송되지 않았던 것이다. 결국 문제는 TTL값을 수정해 보내도록 서버의 옵션을 변경함으로써 해결했다.
E 통신사 메신저 사용으로 응답시간 지연
성능 분석 툴을 이용, 네트워크 지연 장비 분석
E 통신사는 전사적으로 모든 직원이 메신저를 사용했는데 PC를 부팅하면 자동으로 메신저 접속을 하느라 오랜 시간동안 PC가 멈춘 것이 문제가 됐다. CPU 20%미만으로 네트워크 장비에 자원도 넉넉했고 핑 등을 수행해도 특별히 의심스러운 부분은 없었다.
그리고 일단 부팅만 하면 다른 업무를 보는데도 별 문제가 없어 전반적인 네트워크의 지연 시간을 의심하기에는 어려웠다. 결국 메신저 애플리케이션에 초점을 맞춰 분석을 하기 시작했는데, 일차적으로 문제가 사용자 PC인지, 네트워크나 서버인지를 파악하기 위해 응답시간 분석 툴을 사용해 분석에 들어갔다.
사실 수집을 위해 성능 분석 툴을 사용해 PC에 에이전트를 설치하고 서버측 미러링(Mirroring)을 통해 분석을 실시했다(그림 12). 이 툴은 사용자 PC와 서버 사이에 소프트웨어 에이전트를 설치해 각각의 응답시간을 보여주는데, 분석 결과 메신저 로그인하는데 걸리는 시간이 대략 86초 정도 걸렸고 그 동안은 PC가 계속 멈추는 현상이 발생했다. 구간별로 보면 서버에서의 지연 시간이 대부분이었고, 상대적으로 네트워크나 PC에서 걸리는 지연 시간은 거의 없는 것으로 분석됐다.
서버의 패킷 흐름을 좀 더 자세히 분석해 특정 플레임의 전송이 오래 걸린 것을 알 수 있었는데, 패킷간 소요 시간이 무려 17초나 걸렸다. 결국 사용자 리스트를 전송하는 패킷으로 판명됐고, DB 수정 끝에 정상적인 응답시간을 기록할 수 있었다.
