By 조셉 슬론, 역 한빛리포터 2기 김병익님
『Network Troubleshooting Tools』라는 책에서, 나는 네트워크 문제해결에 있어 결정적인 단서가 되는 정보를 취합하는데 사용할 수 있는 많은 도구들을 소개했다.
이 책은 당연히 네트워크가 이미 존재한다는 것을 가정한다. 이 책에서 언급하지는 않지만, 새로운 네트워크를 구성하거나 기존 네트워크를 재구성하는 데에는 고려해야 할 설계 원칙이 있다. 이 원칙은 네트워크에 문제가 덜 발생하도록 한다거나, 혹은 발생된 문제의 피해를 최소화한다거나 혹은 문제 진단을 더욱 간단하게 만들 수 있다는 것이다.
일반적으로 네트워크 구성 실패는 피할 수 없다. 즉, 이것이 현실이며 설계에 있어 이 점은 꼭 기억해야만 한다.
네트워크 설계는 항상 효율성, 비용, 성능, 유지보수 등등의 상호 배타적인 선택의 문제에 직면한다.
네트워크는 항상 문제를 최소화 하도록 설계되어야 하는 반면에, 이 최소화를 위한 노력은 다른 조건들과 충돌을 야기한다. 이런 딜레마들에 대한 간단한 해결책은 없다. 그러나 대부분의 네트워크들에 있어서 도움이 될 수 있는 일반적인 몇 가지 지침들은 있다.
오류의 형태
오류를 가진 네트워크를 설계할 수도 있다는 전제는 먼저 시스템들이 어떤 식으로 오류를 일으키는 지에 대한 철저한 이해를 필요로 한다. 그래서 설계 원칙에 관해 이야기 하기 전에 시스템 오류에 관하여 먼저 알아보는 것이 도움이 될 것이다.
나는 여러가지 다른 형태의 오류를 설명하는 것부터 시작할 것이다. 이 분류는 다소 지나치게 단순화되었을 수도 있지만, 우리의 요구에는 적합한 것이다.
단순 오류: 아마도 다뤄야 할 가장 단순한 형태는 어느 한 부분에서의 오류나 간단한 오류가 발생했을 때일 것이다. 그러나, 이런 형태의 오류는 네트워크가 동작하지 않는데 있어 단지 한 요소일 뿐이다.
이론적으로는 어떤 장치가 동작하지 않는지 구분 해야만 한다. 그러나, 대부분 이런 단순한 경우는 없다. 대부분의 경우에 오류는 여러 장치들이 함께 동작하지 않는 것으로 나타난다. 예를 들면, DNS 서버가 운영중인 네트워크상에 케이블 연결장치가 불량이 있다면, 해당 서버는 이용가능하지 않게 되고, DNS 서비스가 작동하지 않을 것이며, 이는 곧 여러 서비스들 중 메일서비스를 작동하지 않게 할 것이다. 사실상 단지 한 개의 장치만 오류가 났을 뿐이다: 커넥터. 커넥터가 일단 복구되면, 다른 모든 것들은 기적적으로 살아날 것이다.
상호 독립적인 여러 오류: 때때로 당신은 거의 동시에 여러 개의 오류에 직면할 것이다. 앞의 단순한 커넥터 오류의 예처럼 당신은 간혹 여러 개의 오류가 생겼다고 오해할 수도 있을 것이다.
그러나, 간혹 실제로 하나 이상의 장치가 오류가 생길 수도 있을 것이다. 상호 독립적인 여러 오류들이라는 것은 오류의 발생 시간이 우연히 일치했다는 의미 정도에 지나지 않는다. 이 오류들 사이에는 어떠한 연관관계도 없다.
불행히도 다음의 3가지 이유 때문에 상호 독립적인 다수의 오류들은 다루기가 어려울 수 있다. 첫째로, 오류가 실제로 하나 이상이라는 사실을 명확히 깨달아야만 한다는 것이다. 둘째로, 오류에 기인한 증상들을 서로서로 구분해내는 것이 어렵다. 마지막으로, 아무 연관관계가 존재하지 않을지라도 오류들 사이의 연관관계를 찾아보려고 하는 것이 인간 본성이라는 것이다. 이런 경향이 당신을 왜곡된 길로 이끌 것이다.
연쇄 오류: 흔히 어떤 하나의 오류가 다음 것을 야기하는 일련의 오류들의 연속을 가리켜 연쇄 오류라고 하는 것으로 알려져 있다. 그러나 실제 연쇄 오류라는 것은 각각의 오류가 명확히 분리된 개별적인 문제이다.
예를 들면, 전원공급장치의 오류는 인터페이스에 손상을 가져올 수 있다. 장치를 다시 구동하기 위해서는 전원공급장치와 인터페이스 모두를 수리 혹은 교체해야 할 필요가 있다(물론 당연히 전원공급장치 먼저 교체해야 한다).
진짜 연쇄 오류는 많은 다른 서비스들에 영향을 끼치는 단순 오류와 구분하기 어렵다. 그러나 차이는 사용자들과는 관련이 없다는 것이다. 이것은 문제해결에 있어 매우 중요하다.
시스템 오류: 아마도 대부분의 치명적인 오류 형태는 시스템 오류일 것이며, 이 시스템 오류라는 말은 과도하게 사용되어지기도 하고, 때로는 잘못 적용되어지기도 하는 말이다. 시스템 오류들은 구성 요소들 간의 예기치 않은, 불분명한 상호작용에 기인한다.
이 상호작용은 서로 영향을 주고받는 독립적인 오류들의 결과 일수도 있고, 혹은 단순히 장치들간의 예기치 않은 부조화에 기인한 것 일 수도 있다. 시스템 오류는 명백하지 않고 혹은 즉각적으로 이해되기 힘든 낯설고, 예측 불가능 한 상호작용을 필요로 한다.
여러 개의 단순한 오류들은 상호작용이 없다면 시스템 오류가 아니다. 또한, 상호작용이 명백히 이해된다면, 연쇄 오류들도 시스템 오류가 아니다. 아마도 시스템 오류들이 가장 쉽게 설명될 수 있는 것은 예를 통해서 일 것이다.
사례 연구: 시스템 오류의 예
수년 전 나는 내 자신이 구성한 대학 네트워크 망을 확장하는 과정에서 시스템 오류에 맞닥뜨렸다. 논리적으로 이 대학 네트워크망은 4개의 서브네트워크(대학 관리 부서용 네트워크, 학부용 네트워크, 학생 실험실 네트워크, 그리고 학내 인터넷 접속과 전화접속 서비스 이용 등을 위한 외부 엑세스용 네트워크)로 이루어져 있었다.
초기에는 이런 서브넷들은 모두 메일 및 DNS 서버와 라우터 겸용으로 사용되는 중앙집중 호스트에 연결되어 있었다. 각 개별 서브넷은 허브로 연결된 호스트들의 집합이다. 네트워크의 논리적 구조는 [그림 1a]와 같다.
이 네트워크는 충분히 잘 작동했으며 오래지 않아, 특히 웹과의 통합으로 인해 초기 네트워크 하드웨어의 성능을 넘어설 정도로 성장했다. 이 네트워크의 발전을 위한 다음 단계는 라우터를 기존 서버 서비스들과 분리하여 독립적으로 설치하는 것과 많은 허브들을 스위치로 교체하는 것이었다.
메일서버에서는 간단히 라우팅 서비스를 중지하는 반면, 4개의 네트워크 모두는 라우터와 연결된 상태를 유지하기로 결정이 되었다. 이런 결정은 로컬 메일이 라우터를 경유할 필요가 없게 되므로, 네트워크에 이전보다 큰 효율을 가져다주게 되고, 또한, 라우터가 다운되는 경우에도 메일을 이용할 수 있으므로, 약간의 안정성을 추가로 가져다준다.
서로 다른 네트워크상의 많은 사용자가 사실상 근접해서 위치해 있기 때문에, 가상 LAN을 지원하는 스위치를 선택하였다. 새로운 네트워크의 논리적 구조는 그림 1b와 같다.
이 구조가 어떻게 시스템 오류를 야기했는지 이해하기 위해서는 사용된 호스트와 스위치에 관해 좀더 상세한 부분을 이해해야 할 필요가 있다. 현 메일/DNS 서버는 각각의 포트, 혹은 4개의 네트워크와의 인터페이스를 위해 서로 다른 이더넷 주소 혹은 MAC 주소를 사용하는 카드를 가져야 함에도 불구하고 같은 이더넷 주소 혹은 MAC 주소를 사용하는 4쌍둥이 이더넷 카드를 가지고 있었다.
이런 구성은 일반적이지 않지만, 어쨌든 공급업체의 문서에 따르면, IEEE는 모든 포트들에 하나의 같은 주소를 사용하는 장비 주소 접근법, 혹은 각각의 포트에 서로 다른 주소를 사용하는 포트 주소 접근법을 사용할 것인지를 공급업자에게 맡기고 있다고 한다. (원래 초기 구성에서 서로 다른 네트워크들에 대해서 별도의 MAC 주소를 사용했을 때는 모든 것이 잘 동작했다.)
스위치의 특징은 스위치들 사이를 돌아다니는 패킷의 흐름에서 MAC 주소를 알아낸 후, 이 주소정보를 패킷의 흐름을 제어하기 위한 정보로 사용한다. 패킷이 포트에 도착하면, 그패킷의 송신자 MAC 주소가 포트의 주소 테이블에 기록된다. 스위치는 또한 각 포트의 주소테이블을 찾아서 목적지 주소를 알아낸다.
스위치가 일치하는 것을 찾아내면, 패킷을 MAC 주소를 알고 있는 해당 포트를 통해서 전송한다. 아마도 이때 중요한 것은 다른 어떤 포트로는 패킷을 보내지 않는다는 것이다. (만약, 목적지 주소가 스위치의 어떤 주소 테이블에도 없다면 스위치는 일반 허브처럼 모든 포트를 통해 해당 패킷을 전송하게 된다.)
장치들이 한 포트에서 다른 포트로 이동되면 일반적으로 스위치는 MAC 주소를 해당 포트에 추가하고 그 주소가 있던 다른 주소 테이블에서 해당 주소를 삭제할 것이다. 전통적인 스위치에서는 메일서버가 사용하던 장비 주소 접근법이 어떤 문제도 일으키지 않았다. 개별 네트워크상의 스위치 하나하나는 다른 네트워크들에서 무슨 일이 벌어지는지 알 수가 없었다.
위의 구조를 가지고 VLAN 사용을 가정해보자. VLAN 장비의 원 개념은 물리적 장치를 논리적으로 여러 개의 장치로 나누어 사용한다는 것이다. 만약, 당신이 3명의 학부생과 2명의 직원, 그리고 4명의 컴퓨터학과 학생 그룹을 같은 논리적(?) 망 안에 연결하여 구성한다고 가정해 보자.
전통적인 스위치를 사용하게 되면 각기 다른 서브넷에 존재하는 3가지 형태의 사용자가 있기 때문에 3개의 다른 스위치가 필요하다. 더군다나 이 스위치들을 연결하기 위해 네트워크 백본으로 돌아가는 3종류의 케이블이 필요하다.
VLAN을 지원하는 스위치를 사용하게 되면 스위치가 3개의 논리적인 스위치들로 나누어 진다. 각 논리적 스위치는 특정 서브넷상의 트래픽만 처리하게 된다. 그러므로 3개의 물리적 스위치대신에 하나의 스위치만 구매하면 된다. 그리고 네트워크 백본상에 VLAN 기술을 사용하게 되면, 백본과 논리적 망사이에 하나의 케이블 (트렁크라인)만이 필요하게 된다. 스위치는 트래픽을 정리한 후, 각각의 적당한 논리 스위치로 트래픽을 보낸다. 명백히 VLAN 기술은 여러면에서 상당한 이득을 가져다준다.
이것은 흥미로운 질문을 불러 일으킨다: VLAN을 지원하는 스위치상에서 주소 테이블이 어떻게 관리되는가? 특히 한 주소 테이블에 장치가 추가될 때, 물리적 스위치상의 모든 포트용 주소 테이블에서 제거되야만 하는 것인가?, 또는 단지 동일한 논리 스위치상의 포트에서만 제거되는 것인가?
장치들이 한 네트워크에서 다른 네트워크로 이동되면 물리적 스위치상의 모든 테이블에서 주소가 제거되야만 한다고 생각할 지도 모른다. 그리고 실제 이것은 많은 VLAN 스위치상에서 작동하는 방식이다. 그러나 이 결정은 메일 서버의 장비 주소 접근법과 같이 사용될 때 문제를 불러 일으킨다.
문제는 메일 서버가 모든 4개의 네트워크에 동시에 존재할 필요가 있다는 점이다. 서버로부터 패킷이 스위치상의 한 포트에 도착하면 다른 모든 포트와의 연결은 끊어진다. 네트워크상에서는 적당한 논리 스위치에게 여전히 서버로의 패킷을 보낼 것이다. 그러나 해당 논리 스위치의 어떤 주소 테이블에도 서버 주소가 더 이상 존재하지 않기 때문에 모든 포트로 패킷을 보내게 된다. 만약 한 사람만이 서버와 통신하게 되면 스위치는 빠르게 안정화된다. 그러나 동시 통신에는 문제가 있다.
서버의 주소 구조와 VLAN의 사용사이의 부조화가 의심할 여지없이 우리 문제의 원인이었다. 이 설명은 간단하다. 문제는 매우 주기적이었고 주로 많은 패킷이나 연결을 잃게 하는 네트워크 성능의 저하로서 나타났다. 모순되게도 스위치의 주소 테이블은 넘쳐났다.
트렁크 라인 등을 가로지르는 분리된 트래픽이 문제인 것처럼 보였다. 대부분 이런 문제들의 경우에는 단편적인 설명들이 사실들 뒤에 짜맞추어진다. 종종 생산 시스템들의 경우처럼, 문제를 좀더 자세하게 연구 한다거나 문제 발생이전으로 돌아가기가 힘들다. 일단 문제의 속성이 파악되면 변화가 만들어지고 그 변화는 문제를 해결한다. 특히 ifconfig라는 명령은 서버상의 각 포트에 서로 다른 MAC 주소를 할당하는 사용되곤 한다.
시스템 특징과 시스템 오류
앞에서 얘기된 것처럼 시스템 오류의 특징은 2개 혹은 그 이상의 시스템 파트들이 불분명하고 예상치 못한 방식으로 바람직하지 못한 상호작용을 하는 것이다. 앞서의 예가 시스템 오류에 관한 이 정의와 어떻게 부합되는지에 주목해야 한다. 각각의 네트워크 부분들은 단독으로는 혹은 대부분의 경우에 완벽하게 동작한다. 부분 부분들의 상호작용이 문제를 일으키는 것이다. 메일 서버로의 다중 연결이 다중 상호작용을 발생시키고 이 상호작용이 명확하지 않기 때문에 문제를 진단하고 고치기기 매우 어려웠다.
무엇이 시스템 오류를 불러 일으키는가? Charles Perrow의 고전책 『Normal Accident』에서 그는 원자력 발전소에서 항공 관제 시스템에 이르기까지 많은 다양한 시스템을 분석했다. Perrow의 작업을 단순화하는 위험이 있긴 하지만, 그가 밝혀낸 바에 의하면, 시스템에서 쉽사리 시스템 오류를 불러 일으키는 여러가지 인자들이 있다. 우선 시스템을 단순화하면 할수록 시스템 오류의 발생 가능성은 줄어든다. 복잡한 시스템에서는 상호작용이 많아져서 잘못될 수 있는 것이 많다. 그리고 무언가가 잘못되면 이해해야 할 것들도 많아지기 때문이다. 불분명하고 숨겨진 상호작용 같은 것들이 많아진다. 복잡한 시스템에서는 정보들이 간접적으로 모아지거나 유추되어질 수 밖에 없다.
두 번째로 단순한 시스템은 많은 상호 연결을 가진 시스템들보다 시스템 오류가 날 가능성이 적다. 많은 크로스 연결을 가진 시스템들은 부품들이 상호 작용할 소지가 더욱 많이 있다. 실제적인 상호연결은 대부분 진단하기 어려운 문제들을 발생시키는 불분명한 것들이다.
선형성과 밀접하게 관련이 있는 것은 시스템내부의 부품들 사이의 연관정도 이다. 느슨하게 연관되어 있는 단순한 시스템은 복잡하게 연관되어 있는 시스템들보다 문제가 덜 생긴다. 밀접하게 연관되어 있는 시스템들에서는 상호작용이 보다 즉각적이고 치명적이다.
당신이 그 문제들에 대해 생각하기를 멈추게 되면 이런 특징들 중 어떤 것들도 특별히 놀라울 것이 없다. 그러나 만약 당신이 이 문제들에 대해 계속 생각한다면 매우 쉽게 조망할 수 있다. 간단히 말해서 나는 대부분의 네트워크들을 복잡하지만 비교적 선형적인 시스템들로 분류한다. (사실 대부분의 네트워크들은 트리 구조이다. 그러나 이것은 장치들 사이의 경로가 명백하게 선형적이라는 것을 암시한다.)
대부분의 하드웨어는 밀접하게 연관되는 경향이 있다. 그러나 하드웨어를 사용하는 프로토콜들은 느슨한 연관성을 제공한다. 이런 점에 동의하지 않더라도 상관없다. 시스템에 선형이냐 비선형이냐, 밀접하게 연관되었느냐 느슨하게 연관되었느냐 아님, 단순하냐 복잡하냐 등의 범주를 할당지우는 것은 대부분 judgment call이다. 이것들은 상대적 분류이다. 보다 중요한 것은 네트워크에 절대적인 분류를 적용시키는 것보다는 이런 측면에서 서로 다른 네트워크 설계를 비교해보는 것이다.
진단 오류
불행히도 당신이 문제를 진단하기 시작할 때, 당신이 접한 문제가 어떤 종류의 문제인지 명백하게 알려지는 것은 거의 없다. 마음속으로 가능성에 대해 생각하는 것은 도움이 될 수 있지만 대부분의 경우 당신이 그 문제를 해결할 때까지 그 문제가 어떤 종류의 문제인지 분류하는 것이 불가능 할 때도 있을 것이다.
대부분의 경우 당신이 더 많이 알기 전까지는 모든 오류들을 간단한 오류처럼 다루기 시작할 것이다. 오류의 내용 중 명백한 부분부터 살펴보는 것으로 시작하고 거기서부터 나아간다. 앞서 DNS 서버의 불량 커넥터 예에서 당신은 아마도 DNS 문제를 나타내는 메일 소프트웨어의 에러 메시지를 통해 시작을 할 것이다. 다음으로 DNS 정보를 검사하려고 시도할 것이고 이것은 DNS 서비스가 사용 불가능한 것을 알게 해줄 것이며 계속해서 DNS 서버 자체가 통신이 안되는 것을 발견하게 될 것이다. 당신은 이런식으로 오류의 근원을 완전히 없애는 작업을 계속 해나갈 것이다.
기계 시스템에서는 접근성이 가장 중요한 단서다. 네트워크에서는 논리적 접근성이 이를 대신한다.-다른 시스템이 누구에 의해 사용되어지고 있고, 혹은 다른 시스템이 해당 시스템을 사용 중인지 등의 논리적 접근성(이 모든 얘기가 매우 모호하게 들린다면 이런 단계들에 사용되는 특정 도구를 설명하는
『Network Troubleshooting Tools』을 참조해라.)
다른 형태의 오류들을 인식하는 것도 도움이 될 수 있다. 간단한 오류를 진단할 때, 일반적인 방법은 나누어서 차례차례 해결해 나가는 것이다. 앞의 예제에서도 실제 오류에서 몇 단계씩이나 떨어져 있는 현상에만 주의를 고정시키는 것보다는 다른 곳으로 기꺼이 주의를 돌리는 것이 중요함을 알 수 있다. 앞의 예에서 메일 구성파일이나 DNS를 조사하는데 시간을 쓴 것은 거의 낭비였다.
두개 혹은 그 이상의 장치들이 거의 동시에 오류가 발생했을 때 문제 중의 하나를 해결하는 것은 전체 문제를 해결하지 못하기 때문에 문제를 진단하기 어렵게 만든다. 중요한 것은 다수의 오류가 생길 가능성이 있다는 것을 인정하는 것이다. 일반적으로 문제를 해결하기 위해 장치들을 번갈아 교체해 가면서 나누어서 해결해가는 방법은 문제 하나를 완전 해결하기 위해 고안된 방법이다.
다수의 오류가 있는 경우 당신이 하나의 문제에 접근해 감에 따라 다른 문제로부터는 더욱더 멀어진다. 전형적으로 당신이 문제들중 하나를 해결하면 증상이 변화할 것이다. 이런것이 대부분 시스템 오류이다.
네트워크 디자인
다른 형태의 오류를 이해하는 것은 단지 문제를 진단하는 데에만 부분적으로 도움을 주는 반면, 오류를 불러일으키는 네트워크의 특성에 관해 생각하게 되면 이것은 네트워크 설계에 매우 큰 도움이 된다. 그러나 이런 방법이 해결책이 될 수는 없다. 네트워크 설계에 있어서 첫번째 단계에서는 오류를 피하도록 해야 하는 것이 당연하다. 뿐만 아니라 오류의 영향을 최소화하고 문제 해결을 단순화하는 것도 필요하다. 불행히도 이런 것들은 상호 모순되는 목표이다. 예를 들면 오류의 영향을 고려하는 설계는 해당 오류에 관한 정보를 원격에서 수집하기 어렵게 만들 수도 있다.
단순 오류: 간단한 오류를 피하기 위해서는 일반적인 조언이 적용된다. 신뢰성있는 장비를 사용해라. 일상적인 상태에서 장비를 테스트하고 유지 관리해라. 문서를 최신 상태로 유지해라. 장비를 위한 몇몇 공급자와 프로토콜들을 표준화해서 가능한한 단순하게 장비를 유지해라. 불행히도 몇몇 프로토콜만 사용하도록 하는 것은 네트워크로 할 수 있는 것을 제한하게 만든다. 표준화된 장비는 아마도 해당 장비를 위해 많은 비용을 지불하게 할 것을 의미한다. 대부분의 경우에 있어 공급업자만큼 경제적일 수는 없고 특별한 요구는 그것이 필요하지 않을 때까지 비싼 장비를 사용하게끔 강제된다. 이런 제안들에 놀래야 할 것은 없다.
복수 오류와 연쇄 오류: 물론 단순 오류들을 줄이는 것이 복수 오류를 막는 첫 단계이다. 그것들이 독립 오류이든 연쇄 오류이든 시스템 오류이든지 간에 말이다. 다음 단계는 네트워크 부분들의 상호 작용을 최소화하는 것이다. 파티셔닝은 데이터 링크 계층에서 세그멘테이션을 통해 되어지기도 하고, 네트워크 레벨에서 서브네팅을 사용해서 되어지기도 한다. 때때로 간과될지라도 방화벽은 보안 문제에만 제한될 필요는 없다. 방화벽은 서브넷 사이의 트래픽을 제어하는 일반적인 도구로 사용되기도 한다. 그러나 파티셔닝은 상호작용을 제한하기는 하지만, 그것은 또한 데이터의 수집을 어렵게 한다.
네트워크를 나누게 되면 (가장 작은 네트워크는 아닐지라도 어떤 크기로라도 네트워크를 나누는 것을 고려해야만 한다.) 체크포인트를 만드는 것이 중요하다. 가장 간단한 곳, 이것은 당신이 원격에서 접속하고 데이타를 모을 수 있는 도구를 가지고 있는 각 파티션의 컴퓨터이다. 나는
『Network Troubleshooting Tools』라는 책에서 이런 용도로 사용되는 많은 유용한 도구들을 소개했다. 당신은 이런 종류의 정보를 수집하기 위해 라우터 같은 네트워크 장비를 구성할 수 있다. 만약, 당신의 예산이 허용된다면, RMON 탐색기나 비슷한 것을 고려할 수 있을 것이다. 물론 그렇게 하는 것은 당신의 네트워크를 복잡하게 만들 것임을 알아야 한다. 예를 들면, 당신은 적어도 선택된 장비들을 위해 SNMP 트래픽을 통과시키기 위해 라우터나 방화벽들을 재구성해야 할 필요가 있다.
시스템 오류: 시스템 오류는 가장 진단하기 어려운 문제(그리고 결과적으로 당신이 직면하게 될 가장 돈이 많이 드는 문제 중의 하나이므로)이기 때문에 당신은 아마도 당신의 네트워크가 이런 형태의 문제를 가지지 않거나 제한하도록 하는 구조를 만드는데 특별한 주의를 기울이기를 원할 것이다. 앞서 논의되었던 모든 것들이 도움이 될 것이며 다음 단계는 네트워크에 시스템 오류를 야기할 수 있는 특징들에 관해 생각하는 것이다.
우선 네트워크를 가능한한 선형으로 유지해라. 트리 구조의 네트워크가 임의의 그물 구조보다 선호된다. 일반적으로 간혹 중복 연결을 제외하고는 대부분의 네트워크들은 대부분 선형이거나 트리 구조다. 모순되게도 튼튼하게 하기 위한 중복 경로가 반대 효과를 가져오기도 한다. 이런 예상 가능한한 문제들이 네트워크를 주의 깊게 테스트해야 할 필요가 있게 만드는 한 요소이다. 당신이 추가적인 경로를 설정하면 그것들이 문제를 일으킬 수 있다는 점을 인식해야 할 필요가 있다. 관리 임무를 지원하기 위해 최대로 단순한 구조를 유지하도록 노력해라.
대부분의 네트워크에서 개별적인 장치들은 비록 장치들을 사용하는 프로토콜과 서비스는 느슨하게 연관되어 있을지라도 비교적 밀접하게 연관되어 있다. 밀접하게 연관된 시스템에서 버퍼와 중복은 명백하게 설계되어져야 할 필요가 있다. 이것은 몇몇 프로토콜에서는 되어졌지만 다른 것들에서는 아니다. 가능하다면 적절한 것을 선택해라.
복잡성과 효율성은 종종 시스템에서 밀접하게 연결되어 진다. 모순되게도 가장 단순한 해결책이 매우 효율적인 해결책이다. 결과적으로 네트워크가 기능하기 위해서는 몇 단계의 복잡성이 필요하다. 복잡성은 대부분의 경우 신뢰성을 향상시키기 위해 추가되어 진다. 일반적으로 간단한 것이 더 좋다.
마지막으로 앞서 얘기된 것처럼 시스템 오류의 주요 원인은 상호작용이고 이는 불분명하며 예측 불가능하다. 이런 형태의 문제를 다루거나 혹은 피하기 위해서 당신은 네트워크에서 어떤 일이 벌어지는지를 최대한 많이 알기를 원할 것이다. 불행히도 이것은 네트워크의 기본 설계 원칙인 투명성과 직접적으로 충돌한다. 사용자의 관점에서 네트워크가 어떻게 동작하는지에 관한 자세한 내용들은 관심이 없다. 결과적으로 네트워크는 사용자들에게 자세한 것을 보여주지 않도록 설계되어야 한다. 만약 TCP 세션에서 패킷이 누락되면 프로토콜이 사용자들이 미처 알지 못하도록 패킷을 재전송하도록 할 것이다. 아마도 사용자들은 네트워크가 다소 느려졌다는 정도만 알아차릴 것이다. 문제를 해결해야 할 사람의 입장에서는 정보 감추기는 최후의 수단이다. 해결책은 네트워크의 동작 원리를 철저히 이해하는 것과 정보를 수집하기위한 좋은 도구들을 갖는 것 뿐이다.
결론
공학적인 문제들은 언제나 상호 배타적인 선택을 하지 않을 수 없게 만든다: 선형성과 중복성, 단순성과 효율성, 투명성과 정보가용성. 이런 것들은 네트워크를 구축하는데 있어 조심스런 균형을 요구한다. 모든 경우에 다 잘 작동되는 마술 같은 지침서는 없다. 신뢰성의 향상이나 문제 진단의 용이성 등은 항상 비용문제를 수반한다. 그러나 문제 진단에 있어 첫번째 단계는 무슨 일이 벌어지고 있는지를 이해하는 것과 문제점들을 인식하는 것이다. 당신의 대안들과 복잡성을 비교하고 어디에서 문제가 생길지 예측하려고 노력해라.
조셉 D 슬론은 1970년대 중반부터 컴퓨터 일을 해왔다. 그는 1981년에 학부생으로써 유닉스를 사용하기 시작했으며, 처음에는 응용프로그램 개발자였고, 후에는 시스템 개발자이자 시스템 관리자였다. 1988이래로 Lander 대학에서 수학과 컴퓨터 공학을 가르치며, 네트워크킹 컴퓨터 실험실을 관리한다. 그곳에서 그는
『Network Troubleshooting Tools』에 설명된 소프트웨어 도구들을 테스트 및 사용하고 있다.
Return to: sysadmin.hanbitbook.co.kr
