마이크로소프트의 네트워크 환경에서 여러 가지 서비스를 하는 서버들이 있지만, 역시 빼 놓을 수 없는 서비스가 하나 있다. Windows NT4.0 에 비하면 Windows 2000 환경에서는 그 역할이 많이 줄어들었지만 여전히 필수적인 하나의 서비스임에는 틀림없다. WINS서버가 왜 필요하고, 네트워크에서 차지하는 역할은 무엇인지, 최적화된 관리방법은 무엇인지 차근차근 접근해 보도록 하자.

1.NetBIOS Network

BIOS(Basic Input Output System)는 컴퓨터에서 각종 디바이스들의 입출력을 담당하는 표준시스템이다. 컴퓨터 한 대만 있는 환경이 아닌 네트워크 환경을 고려해보면 이것만으로는 부족하다는 것을 알 수 있다. 하나의 시스템에 국한된 환경이 아니라 컴퓨터대 컴퓨터간의 입출력을 처리해야 할 필요성이 생긴 것이다. 이에 IBM은 Network에서 구현되는 BIOS를 개발했다. 이것이 NetBIOS이다.

이것은 네트워크에 있는 시스템들간의 통신을 위한 컴퓨터 이름 관리, 그리고 지속적인 통신을 위한 세션유지 등을 처리하고 실제 패킷을 전송할 책임이 있는 프로토콜을 호출하는데 필요한 일련의 방법들을 제공하고 있다. 하나의 어플리케이션이 네트워크 상에 있는 다른 컴퓨터의 어플리케이션에게 데이터를 주고 받는 데 필요한 네트워크 통신 부분과의 연결지점 역할을 담당하는 것이라고 이해하면 되겠다.

그렇다면 이들 NetBIOS 프로토콜을 사용하는 어플리케이션이 상대방 컴퓨터를 찾을 때는 어떤 이름을 사용할까? 당연히 NetBIOS 이름을 통해서 상대방 시스템을 찾게 된다. 이러한 이름체계 역시 NetBIOS 라는 표준에 맞도록 정의되어 있다.

 

NetBIOS Name = 컴퓨터이름 (15byte) + 플래그 (1byte)

NetBIOS는 16byte로 구성이 되어 있지만 실제로 컴퓨터 이름으로 할당할 수 있는 바이트수는 15바이트로 제한된다. 마지막 16byte째의 플래그는 특별한 용도로 사용된다. 하나의 서버가 하는 일은 다양하다. 예를 들어서 네트워크에 자신의 자원을 제공해 줄 수 있는 역할인 '서버 서비스'를 하고 있고, 자신도 클라이언트로서 다른 자원에 접근할 수 있는 '워크스테이션 서비스'도 하고 있고, 또 도메인 컨트롤러라면 도메인 사용자들의 로그온을 처리해 주는 '로그온 서비스'도 하고 있고, 다른 서버로부터 알림 메시지를 받기 위한 '메신저 서비스'도 하고 있을 것이다. 이러한 각각의 서비스를 구별하기 위하여 16byte째의 플래그가 사용된다. 이 16번째의 플래그는 1byte를 차지하며 2자리수의 Hexadecimal (16진수) 값으로 만들어지고 각각 서비스 타입별로 숫자가 지정되어 있다. 자주 볼 수 있는 플래그를 정리해 보면 <표1>과 같다.

 

<1C> Domain controller <20> Server service <03> Messenger Service <00> Workstation Service <1D> Master Browser <1B> Domain Master Browser, PDC <1E> Potential Browser

                        <표1. NetBIOS Name Flag>

아래의 <화면1>은 secure라는 도메인에서 도메인 컨트롤러로 셋팅된 blue라는 이름의 서버에서 nbtstat 명령어를 통해서 blue 서버가 등록해서 사용하는 NetBIOS 이름들을 살펴 보았다. Blue 라는 이름이 여러개 등록되어 있는 것이 보이고 이름의 뒤쪽에는 <00> <20>등의 숫자가 보인다. 이것이 NetBIOS이름의 16번째 byte에 해당하는 플래그이다. 그리고 이것은 blue서버가 어떤 서비스로서 등록되었다는 역할을 구별해 준다.

<화면1. nbtstat -n>

실제로 이러한 NetBIOS 이름이 어떤 경우에 사용되는지 예를 들어보자. 클라이언트가 blue의 자원에 접근하고자 한다면 사용자는 '\blue공유이름' 의 형태로 접근을 하게 될 것이다. 이때 실제로 네트워크 상에 요청을 확인해 보면 'BLUE <20>'을 찾는 것을 확인할 수 있다. 서버로서의 blue를 찾는 요청이기 때문이다. 또, Win98혹은 NT4.0 사용자가 secure 도메인으로 로그온을 시도한다면 도메인에서 로그온을 받아주는 서버, 즉 도메인 컨트롤러를 찾아야 한다. 그때의
요청은 실제로는 'SECURE <1C>'가 된다.

이렇듯 클라이언트가 특정 서버의 NetBIOS 이름을 찾기 위해서는 선행되어야 할 일이 있다. 당연히 네트워크에 서버의 NetBIOS이름이 등록되어 있어야 찾을 수가 있을 것이다. 그렇다면 서버는 어떤 방법으로 네트워크에 자신의 NetBIOS 이름을 등록하는 것일까? 또, 클라이언트는 어떤 방법으로 네트워크에 등록된 NetBIOS 이름을 찾을 수가 있는 것일까? 여기서 WINS의 필요성은 출발 할 수 있다.

마이크로소프트는 자사의 네트워크에서 NetBIOS를 채택하고 꾸준히 이를 지원해 왔다. 그리고 NetBEUI (NetBIOS Extended User Interface)를 개발하여 NetBIOS를 지원해 왔다. NetBEUI는 NetBIOS를 지원하기 위해서 개발된 프로토콜이므로 NetBIOS를 완전하게 지원할 수 있는 잘 동작하는 프로토콜이다. 하지만 이 프로토콜의 통신방법은 브로드캐스트에 의존하고 있고, 이것은 라우터로 브로드캐스트 도메인이 분리된 확장된 네트워크 환경에서는 큰 문제점을 안고 있다. 라우팅이 되지 않기 때문에 네트워크의 확장성이 매우 떨어지게 되는 단점이 있는 것이다. 더불어 인터넷 표준 프로토콜로써 TCP/IP프로토콜이 사용이 되고 회사의 네트워크가 더 이상 로컬 LAN에만 국한되어 단순히 파일이나 프린트 공유정도만을 요구하지는 않는다. 대부분의 시스템에서 인터넷에 접근을 하는 것이 기본적인 사항이 되어가고 있으니 NetBEUI를 사용하는 클라이언트라도 추가로 TCP/IP를 설치하여 사용할 필요성이
생기게 되었다. 마이크로소프트 역시 TCP/IP를 지원하고 있다.

여기서 한가지 고려해 보아야 할 점이 있다. NetBIOS 어플리케이션은 브로드캐스트 통신방법에 기초한 NetBIOS Name을 통해서 통신을 한다. 하지만, TCP/IP환경에서는 IP Address로써 각각의 시스템을 구분하고 IP Address를 근거해서 통신을 한다. 마이크로소프트에서 TCP/IP를 지원한다고 하더라도 여전히 기존의 어플리케이션이 NetBIOS를 필요로 하고 있고, 이것을 TCP/IP에서도 지원해 주어야만 호환성에 문제가 발생하지 않을 것이다. 그래서 TCP/IP 프로토콜의 구조를 살펴보면 <표2>의 빨간색 사각형 부분에 'NetBT'라는 프로토콜이 포함되어 있음을 알 수 있다. NetBIOS over TCP/IP를 줄인 표기이다. TCP/IP상에서 NetBIOS를 구현하기 위해 인터페이스를 포함시켜 놓은 것이다.

 

<표2. Windows 2000 TCP/IP 구조>

위에서 보듯이 NetBIOS 어플리케이션들은 NetBT 인터페이스를 통해서 TCP/IP의 TCP나 UDP를 호출하는 것이 가능해진다. 그렇지만 통신상에서 구별하는 이름에는 여전히 차이가 있다. NetBIOS 어플리케이션에서는 NetBIOS이름을 통해서 상대방 시스템을 찾으려 시도할 것이고, TCP/IP 프로토콜에서는 그러한 이름을 알 수가 없다.누군가가 이 문제점을 해결해 주어야 한다. 이것을 해결하기 위한 인터넷 표준이 두가지 마련되어 있다.

2. NetBIOS Name 등록, 해제, 요청

 

NetBIOS이름이 사용되기 위해서는 먼저 네트워크에 등록이 되어야 한다. 이름등록을 하는 방법으로는 두가지가 제공이 된다.

첫 번째 방법은 브로드캐스트를 이용하는 것이다. 시스템이 시작되고 NetBIOS 어플리케이션이 시작되게 되면 이름등록을 진행하게 된다. 이때 브로드캐스트를 통해서 네트워크에 자신의 이름을 등록하게 된다. 만일 사용하고자 하는 이름을 누군가 미리 등록해서 사용하고 있다면 이름충돌의 에러메시지를 받게 되고, 해당 이름등록은 실패하게 된다.

두 번째 방법은 NetBIOS Name 서버에게 이름등록을 요청하는 방법이다. 네트워크에 브로드캐스트를 발생시키지 않으므로 보다 권장할 만한 방법이라고 하겠다. NetBIOS Name서버에게 이름등록을 요청하기 위해서 해당 시스템은 NetBIOS Name서버의 클라이언트로 셋팅되어야 한다. NetBIOS 이름해제는 반대과정이다. 이것은 NetBIOS 어플리케이션이 중지될 때 발생하는 일이다. 결과적으로는 시스템이 셧다운 될 때 생기는 과정이라고 할 수 있다.

NetBIOS 이름분해 요청 (Name Resolution Request)

이것은 클라이언트가 자원을 가진 서버의 NetBIOS이름에 해당하는 IP Address를 찾고자 할 때 생기는 일이다. 파일서버의 자원에 접근하기 위해 서버를 검색할 때 혹은 도메인으로 로그온을 시도할 때 등등 여러 가지 상황에서 NetBIOS 이름요청이 활성화된다. NetBIOS 이름 요청 방법도 역시 두 가지가 제공된다. 첫 번째 방법은 브로드캐스트를 이용하는 것이고, 두 번째 방법은 NetBIOS 이름 서버에게 찾고자 하는 NetBIOS 이름을 직접 쿼리하는 것이다.

전체적으로 정리하자면, 하나의 시스템이 NetBIOS Name 클라이언트로 셋팅되면 자신의 NetBIOS 이름을 등록할 때도 NetBIOS 이름 서버를 이용하고, 다른 시스템의 NetBIOS Name을 쿼리할 때도 역시 NetBIOS 이름 서버를 이용하게 되는 것이다. 브로드캐스트라고 하는 통신방법이 좋지 않은 것만은 아니다. 아무런 설정이 필요없이 통신의 문제점을 해결해 줄 수 있는 편한 방법이라고도 생각할 수 있지만 라우터로 분리된 네트워크에서 원격지의 노드의 NetBIOS이름을 찾는 것은 불가능한 일이 된다. 또 노드수가 많아진다면 그만큼 네트워크에 브로드캐스트가 많아지므로 결과적으로 네트워크에 커다란 트래픽을 주게 된다.

따라서 기업 네트워크에서 NetBIOS이름을 필요로 한다면 NetBIOS 이름서버를 사용하는 것이 보다 바람직한 방법이다. 마이크로소프트는 NetBIOS Name Server로서 WINS (Windows Internet Name Service)서버를 제공해 주고 있다.

 

* 참고 : NetBIOS Resolution 방법에 따른 클라이언트 분류 B-Node (0x1) : Broardcast를 통한 NetBIOS Resolution을 하는 클라이언트 P-Node (0x2) : NetBIOS Name Server (WINS)를 통해 NetBIOS Resolution을 하는 클라이언트 M-Node (0x4) : Broadcast를 먼저 시도하고 실패하면 NetBIOS Name Server를 통해 Resolution을 시도 P-Node (0x8) : NetBIOS Name Server에게 먼저 쿼리하고 실패하면 Broadcast를 통해 시도하는 클라이언트

3. WINS(Windows Internet Name Service) 설치 및 구성

위에서 WINS서버를 구현하는 방법이 가장 바람직하다는 말을 했다. 그렇다면 이 WINS서버를 설치하고 구성을 해 보도록 하자. WINS서비스를 먼저 추가해 주어야 한다. 제어판-Windows구성요소 추가-네트워킹서비스-WINS를 통해서 추가할 수 있다.<화면2>

 

<화면2. WINS 서비스 설치>

설치가 완료되면 그것으로 WINS서버의 준비는 끝났다. 다음엔 WINS서버에게 자신의 NetBIOS이름을 등록하고 다른 서버의 NetBIOS 이름을 쿼리할 수 있도록 클라이언트 셋팅을 해야 한다. 제어판-네트워크 및 전화 접속 연결을 통해서 TCP/IP 등록정보를 연 다음, [고급]버튼을 클릭하면 WINS 탭을 볼 수 있다. [추가]를 이용하여앞에서 WINS 서버로 설정한 시스템의 IP Address를 입력한다. 예제에서는 172.16.0.1을 입력했다.<화면3>

 

<화면3. WINS Client 설정>

클라이언트도 구성을 했다. 이것으로써 WINS서버와 WINS클라이언트 구성을 모두 마쳤다. 사실 설치는 너무나 쉽다. 이러한 서비스들의 필요성을 이해하는 것이 보다 중요한 일이라고 생각한다. 과정을 이해하면 보다 커다란 환경의 네트워크를 만나게 되었을 때도 적절히 대처를 하는 것이 용이할 것이기 때문이다. 이제 WINS서버쪽에서 WINS 관리도구를 열어보면 <화면4>에서 보는 것처럼 클라이언트가 등록되어 있음을 알 수 있다. 또 다른 WINS 클라이언트가 bluenote 라는 NetBIOS 이름에 대한 IP Address를 요청한다면 이 WINS서버는 응답을 할 수가 있게 된다. 이러한 일련의 과정들은 동적으로 동작한다. 관리자는 WINS서비스를 추가해 주고, 네트워크 상의 모든 클라이언트를 WINS Client로만 구성해 주면 나머지는 Windows 2000이 서비스를 해준다.

4. Non- WINS 클라이언트를 위한 설정 - WINS Proxy Agent, Static Mapping

만일 네트워크에 비 WINS 클라이언트가 있다면 그들을 지원해야 할 필요가 있다. 비 WINS 클라이언트는 자신의 NetBIOS이름을 WINS 서버에 등록을 하지 않는다. 또, 다른 서버의 자원에 접근하기 위해서 NetBIOS Name resolution을 할 때도 역시 WINS서버에게 쿼리하지 않고 브로드캐스트를 이용한다. 아래의 <그림1>을 보면서 설명을 한다.

 

<그림1. Non-WINS 클라이언트를 위한 구성>

<그림1>의 예제에서는 라우터로서 분리된 2개의 브로드캐스트 도메인을 보여준다. 왼쪽의 세그먼트에는 WINS서버가 있고, WINS Client인 'Blue'라는 이름의 컴퓨터도 존재한다. 오른쪽의 세그먼트에는 왼쪽의 WINS Server의 클라이언트로 설정된 WINS Client도 있고, 'Red'라는 이름의 Non-WINS Client도 존재한다.

첫 번째 상황을 가정해 본다. 예제와 같은 환경에서 Blue가 Red의 자원에 접근을 하고자 한다(①).

Blue의 사용자는 \redpublic 이라는 UNC 경로를 사용하여 red에 접근을 시도했다. red 라는 NetBIOS Name은 TCP/IP 통신을 위해서 당연히 IP Address로 매핑 (resolution)되어야 한다. blue는 WINS Client이므로 NetBIOS Name Resolution 방법으로써 WINS서버에게 Resoultion 요청을 하게 된다(②).

이 요청을 받은 WINS Server는 WINS Database에서 "Red <20>"이라는 NetBIOS이름을 검색한다. 하지만 red의 레코드를 찾지 못한다. 이유는 Red가 Non-WINS Client이므로 자신의 NetBIOS Name을 WINS Server에 등록하지 않았기 때문이다. 결국 WINS Server는 Blue에게 NetBIOS Name Resolution을 하지 못했다는 응답을 하게 되고, Blue는 그 다음 Resolution방법으로 브로드캐스트를 시도하게 된다. 그렇지만, 라우터로 네트워크가 분리되어 있고 Red 는 원격지의 네트워크에 위치해 있으므로 검색에 실패하게 된다. 결과적으로 Blue에서는 "네트워크 경로를 찾지 못했습니다." 라는 에러 메시지를 확인하게 된다. 통신실패를 의미한다.

해결방법은 있다. 기본적으로 WINS Server는 동적으로 동작하지만 관리자가 수동으로 레코드를 추가할 수도 있다. Static mapping을 통하여 Red를 WINS Server에 추가해 주면 된다. WINS 관리콘솔의 왼쪽 패널의 서버이름 아래에 있는 '활성등록'을 선택한 다음 마우스 오른쪽 클릭하여 '새 정적 매핑'을 선택한다. Red 의 IP Address를 할당해 주면 된다. <화면5>

 

<화면5. WINS 레코드 정적 매핑>

<화면6>을 보면 정적 매핑으로 추가한 Red 의 레코드를 확인할 수 있다. 이제 WINS 클라이언트인 Blue는 WINS Server를 통하여 Red 의 IP Address를 쿼리할 수 있게 되었다.

 

<화면6. 정적매핑된 WINS 레코드 확인>

두 번째 상황도 고려해 보도록 하자. 이번에는 Non-WINS Client인 Red가 WINS Client인 Blue를 찾고자 할 때의 상황을 생각한다. Red의 사용자는 Blue의 public 공유폴더에 연결하기 위하여 \bluepublic 이라는 UNC를 통해서 접근을 시도했다(③).

Red 는 Non-WINS Client 이므로 Blue의 NetBIOS Name을 찾기 위해 WINS서버에게 쿼리하지 않는다. 브로드캐스트를 이용해서 Name Resolution을 시도할 것이다(④).

당연히 라우터의 건너편 네트워크에 존재하는 Blue로부터 응답이 올 수가 없다. 역시 에러 메시지를 받게 될 것이다. 이것을 해결할 방법은 있다. 다행히 오른쪽 편의 네트워크에 WINS Client가 존재한다. 이 WINS Client가 Non-WINS Client를 대신해서 WINS 서버에 요청을 전달해 주게 구성할 수 있다. 이때 이러한 WINS Client를 가리켜서 'WINS Proxy Agent'라고 부른다.

WINS Proxy Agent를 구성하기 위해서는 Agent로 구성할 시스템에서 레지스트리 편집기(regedt32.exe 혹은 regedit.exe)를 통해서 레지스트리를 열고,

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNetBTParameters 키를 찾은후 'EnabledProxy' 값을 '1'로 설정하면 된다.<화면7>

 

<화면7. WINS Proxy Agent 구성하기>

뭔가 되긴 된 듯해 보이지만 석연찮은 구석이 있다. 이거 WINS 클라이언트가 아닌 녀석이 하나 끼어있으니까 이래저래 번거로운걸? 하는 생각이 들었다면 지금까지 내용을 잘 이해한 독자라는 생각이 든다. 방법은 있다. 아주 간단한 방법. Non-WINS Client를 두지 않고 전체 모든 시스템을 WINS 클라이언트로 만들면 모든 것이 해결된다. WINS를 사용하자.

5. 최적화된 WINS 서버 구현 방법

 

3장에서 WINS서버를 설치하고 클라이언트를 설정하는 방법을 설명하였다. 지극히 쉬운 방법이지만 이렇게 설정해 놓은 WINS서버가 실패했을 경우 즉 서비스가 멈추는 상황이 발생한다면 큰일이 아닐 수 없다. 회사에서 WINS서버의 활용도가 크면 클수록 문제발생시의 불편함은 커지기 마련일 것이다.

 

네트워크 상에서 서비스가 구현이 될 때 관리자가 반드시 고려해 봐야 할 부분이 이러한 것이다. 서비스를 하던 서버가 멈췄더라도 여전히 클라이언트는 원하는 작업을 계속할 수 있어야 한다는 것이다. 바로 효율성(Availability)을 고려해야 한다는 것을 의미한다.

 

또 한가지는, 회사에 하나의 서버가 있는데 서버가 수용하기 어려울 정도로 많은 사용자가 서비스를 요청한다면? 당연히 결과는 너무나 느린 응답시간 때문에 사용자들의 불만은 커질 것이고 심한 경우는 서버의 다운으로 까지 이어져서 네트워크가 마비되는 결과를 초래할 수도 있을 것이다. 효율성과 더불어 추가로 고려해야 할 사항이 바로 성능(Performance)이다. 이 두가지 사항을 감안하여 기업 네트워크 상에 WINS서버를 구현한다면 어떻게 하는 것이 최선의 방법이 될 것인지 알아보도록 한다.

 

아래의 <그림2>를 보면서 접근을 해 보자. 예제그림은 서울에 본사가 있고, 부산에 지사가 있는 회사이다. 서울과 부산간에는 상대적으로 느린 WAN 링크를 이용하고 있고, 두 지역간에는 서로간에 자원을 공유해야 할 필요성이 있다. WINS서버를 구현하고자 하는데 효율성과 성능을 고려해서 최적화된 WINS 서비스를 구현하기를 원한다. WINS서버는 몇대를 두고 어디에 배치를 하고, 클라이언트는 어떻게 설정을 해 줘야 할까?

 

<그림2. 최적화된 WINS 구현>

 

WINS 서비스의 효율성과 성능을 높일 수 있는 방법중 가장 일반적인 것은 서버를 여러대 배치하는 것이다. 하나의 서버가 서비스를 하지 못하더라도 다른 서버가 계속 서비스를 제공할 수 있기 때문이다. 두 대를 배치한다고 가정하면 서울에만 2대의 WINS서버를 두는 것보다는 지역마다 하나씩 두는 것이 바람직할 것이다. 그렇지 않으면 부산에 있는 WINS Client가 자신의 NetBIOS 이름을 등록할 경우, 또는 다른 서버의 NetBIOS Name 해석을 요청할 때마다 상대적으로 느린 WAN 구간을 거쳐야 할 것이다.

 

여기서 우리가 고려해 보아야 할 점은 두 대의 서버가 각각 정상적으로 동작하고 있는 경우라면 가급적이면 WAN 트래픽이 발생하지 않도록 해야 한다는 것이다.  일단 서울에 WINS-A를 설치하였다. 그리고 서울에 있는 모든 컴퓨터를 WINS-A의 클라이언트로 설정하였다. 다음에 부산에 WINS-B를 설치하고 부산의 모든 컴퓨터를 WINS-B의 WINS Client로 설정하였다. 이렇게 하면 서울에서의 WINS 트래픽은 서울지역에만 국한되고, 부산에서의 WINS 트래픽은 부산지역에서만 발생될 것이다.

 

<그림2>에서 부산의 WINS Client인 RED가 서울에 있는 BLUE 라는 이름의 서버를 찾고자 한다면 어떻게 될 것인지 생각해 보자. RED는 WINS-B에게 BLUE 라는 NetBIOS 이름을 쿼리할 것이다. 하지만 WINS-B는 BLUE의 IP Address를 알 수가 없다. 왜냐하면 BLUE는 자신의 클라이언트가 아니기 때문이다. BLUE의 레코드는 서울의 WINS서버인 WINS-A가 가지고 있을 뿐이다. 서울의 WINS서버와 부산의 WINS서버의 WINS Database는 서로 다르다. WINS-A는 서울의 WINS Client의 레코드를 가지고 있고, WINS-B는 부산의 WINS Client의 레코드를 가지고 있다. 서울과 부산간에 자원의 공유가 가능해 지려면 이 두 WINS서버들의 WINS Database가 교환될 필요성이 생긴다. 이 과정을 WINS Database Replication을 설정함으로써 가능하게 만든다.

 

이들 두 대의 WINS서버는 서로를 WINS Database Replication Partner로 설정하여 자신의 DB를 밀어주고(push partner), 상대방의 DB를 끌어오는(Pull partner) 형태로 서로 다른 WINS Database를 하나로 통합할 수가 있게 된다. 이렇게 하면 부산에 있는 WINS Client가 자신의 WINS서버에게 서울의 레코드를 요청하더라도 올바른 응답을 받을 수 있게 된다. WINS 데이터베이스 복제파트너는 WINS 관리콘솔에서 '복제파트너'를 통해서 추가할 수 있다. <화면8>에서는 172.16.0.200 WINS서버를 복제파트너로 추가하고 등록정보를 열어서 Pull / push 복제 일정을 확인한 것을 볼 수 있다.

 

<화면8. WINS 복제 파트너 등록정보>

 

이번엔 다른 측면을 고려해 보자. 만일 부산에 있는 WINS 서버가 멈춘다면 어떻게 될까? 당연한 얘기지만 부산지역의 WINS Client는 더 이상 WINS서버를 이용할 수가 없다. 그러면 그 클라이언트들은 부산지역의 서버를 찾을 때는 WINS서버를 이용할 수 없으므로 다음 방법인 브로드캐스트를 이용해서 검색을 할 수도 있겠지만 서울지역에 위치한 서버를 찾고자 할 때는 실패할 수밖에 없게 된다. 그렇다면 이러면 되겠다. 부산에 있는 WINS서버가 동작하고 있을 때는 해당 서버를 통해서 서비스를 받고, 만일 부산의 WINS 서버가 문제가 있다면 서울의 WINS 서버를 사용하면 될 것이다. 그렇게 동작하도록 하기 위해서 부산의 WINS Client들에게 두 번째 WINS서버를 추가로 설정을 해 줄 수 있다. <화면9>의 빨간색 표기부분을 보면 2개의 IP Address가 설정되어 있다. [추가]버튼을 이용하여 WINS서버를 추가할 수 있고 오른편의 [화살표]버튼을 이용하여 쿼리순서를 결정할 수 있다. 물론 서울의 WINS Client들은 두 번째 WINS Server로서 부산의 WINS서버를 이용할 수 있도록 설정해 줘야 한다.

 

<화면9. TCP/IP WINS 설정>

 

정리하면 다음과 같다. 지역마다 WINS서버를 하나씩 배치하고 이들 WINS 서버들은 서로 데이터베이스를 복제할 수 있도록 파트너로 설정을 한다. 클라이언트들에게는 첫 번째 WINS서버의 IP Address를 자신의 지역에 있는 WINS서버로 설정을 하고 첫 번째 서버가 다운되었을 상황을 대비하여 다른 지역의 WINS서버를 두 번째 WINS서버로 설정을 해 준다. 그렇게 해 두면 자신의 지역의 WINS서버가 동작하는 동안에 WINS쿼리는 WAN 링크를 이용하지 않을 것이며 첫 번째 WINS서버에 문제가 생겼을 때도 여전히 두 번째 WINS서버를 통해서 NetBIOS 이름을 쿼리할 수 있게 된다. WINS 서버간의 데이터베이스 복제 트래픽은 물론 WAN을 이용한다. 이 트래픽이 심각하게 고려해야 할 수준이라면 몇가지 설정을 통해서 복제트래픽을 최적화 해 줄 수도 있다.

6. Lmhosts 파일

 

WINS서버를 사용하지 않고 라우트된 도메인 환경에서 서로간에 자원공유가 가능하도록 할 수 있을까? RFC 표준만 그대로 지원한다면 방법은 없다. 하지만 마이크로소프트는 추가로 Lmhosts 파일을 통해서 NetBIOS Name Resolution을 지원하고 있다.

 

<그림3. 'Color' 도메인의 예제>

<그림3>을 예제로 설명하도록 한다. 회사의 도메인 이름은 Color 이다. 이 회사는 서울과 대전으로 지역이 나뉘어 있고 서울에는 Red 라는 이름의 도메인 컨트롤러가 위치해 있다. 서울과 대전에는 각각 Blue와 White 라는 파일서버가 있고, 서울과 대전의 클라이언트들은 도메인으로 로그온을 하고 Blue와 White 2대의 자원을 공유해서 사용하고 있다. 지역별로 구분을 한 예제이지만 서울과 대전이라는 WAN 구간의 경우에 한정된 것은 아니다.

한 지역에서도 라우터로써 네트워크가 나뉘어 있는 상황이라면 <그림3>의 예제와 같은 형태로 볼 수 있다. 서울과 대전이라는 지역적인 측면보다는 2개의 서로 다른 네트워크라고 이해하도록 하자. WINS서버가 없더라도 같은 네트워크 안에서 클라이언트들은 서버를 찾는데 어려움이 없다. 브로드캐스트라는 차선의 방법이 제공되기 때문이다. 하지만, 문제는 자신과 다른 네트워크 즉 라우터 건너편에 존재하는
서버에게 접근하려면 그때는 문제가 생긴다. 브로드캐스트가 라우터를 넘지 못하므로 서버를 찾을 방법이 없는 것이다.

이것을 해결하기 위해서 클라이언트 컴퓨터에서 lmhosts 파일을 이용할 수 있다. lmhosts 파일은 %systemroot%system32driversetc 폴더에 위치해 있다. (%systemroot%는 NT기반의 컴퓨터에서는 winnt 폴더를 의미한다.) <화면10> 해당폴더에는 몇가지 파일이 더 보인다. 다른 파일들 역시 TCP/IP 환경에서 각각 필요에 따라 사용된다. lmhosts 파일을 자세히 보면 다른 파일과 다른 것을 알 수 있다. hosts, protocol 등의 파일과 비교해서 '종류'를 살펴보면 'SAM 파일'로 되어 있는 것을 알 수 있다. 다른 파일들은 확장자가 없지만 lmhosts 파일은 실제로는 lmhosts.sam 이라는 파일명을 가지고 있다. 윈도우탐색기에서 도구-폴더옵션-보기 메뉴에서 '알려진 파일 형식의 파일 확장명 숨김'옵션을 지워주면 확장자까지를 확인할 수 있다.

< 화면10. lmhosts 파일 >

lmhosts 파일을 사용하기 위해서는 확장자를 지워주어야 한다. 여기서 클라이언트 컴퓨터에서는 기본적으로 lmhosts 파일을 사용하지 않고 있음을 알 수 있다. 확장명을 지워주고 메모장을 사용해서 파일을 열어본다. 이 파일은 텍스트 파일이므로 텍스트를 읽을 수 있는 프로그램이면 뭐든 상관없다. 아래의 <화면11>은 메모장(notepad)를 사용해서 열어본 파일을 보여준다.

 

<화면11.메모장으로 열은 lmhosts 파일>

파일에 대한 설명이 있고, 텍스트의 맨 앞에는 한결같이 '#'이 붙어 있다. 이것은 주석처리됨을 의미한다. 끝까지 읽어봐도 #이 붙어 있음을 알 수 있다. 기본적으로는 아무런 내용이 존재하지 않는 빈 파일과 같다. <화면11>의 파란박스부분을 보면 #PRE, #DOM 등의 문자들이 보인다. 여기서의 #은 의미를 가진다. 이러한 것들은 특별한 의미가 있는 '태그(tag)'들이다. 사용법은 파일에 기록된 설명을 참고하자.

그렇다면 이 파일을 어떻게 사용할까? 예제를 들어서 작성을 해 보자. <그림3>의 예제에서 Green 이라는 컴퓨터의 사용자는 color 도메인으로 로그온 하기 위해서 도메인 컨트롤러인 Red를 찾아야 하고, Blue 라는 서버에 연결하여 자원에 접근도 해야 한다. 이것을 가능하게 하기 위한 방법은 Green 컴퓨터의 lmhosts 파일을 편집함으로써 해결할 수 있다. lmhosts 파일을 열고 <화면12>와 같이 기록을 하면 된다.

 

<화면12. lmhosts 파일 편집>

화면에서는 blue 서버가 192.168.10.200 IP Address를 사용하고 있음을 기록했고, #PRE #DOM 태그를 이용하여 Color 도메인의 도메인 컨트롤러가 Red 이고 Red는 192.168.10.2 IP Address를 사용하고 있음을 나타내고 있다. 여기서 #DOM 은 도메인명을 지정해 주는 것이고, #PRE는 시스템 시작과 동시에 PreLoad 시키는 것을 의미한다. #PRE 태그를 이용하면 시스템이 시작될 때 #PRE 태그가 붙어 있는 라인의 내용을 메모리에 로딩을 하게 되고 이것은 시스템을 끌 때까지는 계속 메모리에 올라와 있게 된다. 또는 명령프롬프트에서 'nbtstat -R'을 이용해서 로딩 시킬 수도 있다. Green 컴퓨터에서 nbtstat 유틸리티를 이용해서 잠시 들여다 보자.

<lmhosts 파일 설정 전> D:>net view \blue <--net.exe 유틸리티를 이용하여 blue 서버의 공유자원 리스트를 요청하고 있다. 시스템 오류 53이(가) 생겼습니다. 네트워크 경로를 찾지 못했습니다. <-- blue 라는 서버를 찾을 수 없음을 보여준다. < lmhosts 파일 설정 후 > D:>net view \blue \blue의 공유 리소스 공유이름     유형              용도설명 --------------------------------------------------------------------- Address       Disk          "Access to address objects" Down          Disk               dvd           Disk HANKOOK.log   Disk          "Exchange message tracking logs" NETLOGON      Disk          Logon server share SYSVOL        Disk          Logon server share 영화          Disk 명령을 잘 실행했습니다. D:>nbtstat -c <-- NetBIOS 이름을 성공적으로 해석(resolution)하면 NetBIOS 캐쉬에 일시적으로 저장한다. 기본적으로 10분이라는 시간동안 저장된다. 캐쉬를 보기 위한 스위치 '-c' 를 이용했다. NIC: Node IpAddress: [192.168.20.112] Scope Id: [] NetBIOS Remote Cache Name Table Name       Type        Host         Address         Life[sec] ------------------------------------------------------------ BLUE      <20>     UNIQUE    192.168.10.200       595 <-- blue <20>이 캐쉬에 등록되었다. 캐쉬에서 사라질 때까지의 남은 시간 (TTL)이 595초임을 알 수 있다. D:>nbtstat -R <-- NetBIOS Cache를 모두 삭제하고, lmhosts 파일에서 #PRE 태그가 붙은 레코드를 캐쉬에 로딩시키는 명령이다. Successful purge and preload of the NBT Remote Cache Name Table. D:>nbtstat -c NIC: Node IpAddress: [203.239.61.109] Scope Id: [] NetBIOS Remote Cache Name Table        Name       Type        Host         Address         Life[sec] ------------------------------------------------------------ RED       <03>     UNIQUE    192.168.10.2        -1 RED       <00>     UNIQUE    192.168.10.2        -1 RED       <20>     UNIQUE    192.168.10.2        -1 COLOR     <1C>     GROUP     192.168.10.2        -1 <-- 다시 캐쉬를 확인하니 BLUE 의 레코드는 삭제되고,#PRE 태그가 붙어있던 레코드가 추가된 것이 보인다. TTL이 -1 (무한 대)임을 확인하자. D:>

예제에서 서울에 있는 Black 컴퓨터가 대전의 White를 찾을 수 있도록 하기 위해서는 역시 Black 컴퓨터의 lmhosts 파일에 White 의 정보를 추가해 주어야 한다. WINS 서버를 사용하지 못할 때 해결할 수 있는 차선책이긴 하지만 어디까지나 차선책일 뿐이다. 사실상 번거롭다. 수많은 클라이언트들을 관리해야 하는 관리자라면 이러한 작업들이 보통 귀찮은 작업이 아니다.

lmhosts를 WINS 서버의 오류시 사용하게 될 백업 측면에서 접근을 하는 것 정도라면 고려해 볼만 하지만, 그것도 오히여 lmhosts 파일보다는 WINS서버의 오류시 그것을 대체하게 될 WINS서버를 추가로 구현하는 방법으로 접근하는 것이 바람직하다고 생각한다.

이러한 WINS서버 역시 장기적으로는 사용되지 않을 서비스가 된다. 당장 회사의 네트워크 환경이 Windows2000으로 완전히 전환되었다면(이것은 서버뿐이 아니라 클라이언트 시스템까지 Windows 2000으로 바뀌는 것을 의미한다.) 더 이상 WINS 설정을 하지 않아도 좋다. 이들은 DNS 쿼리를 통하여 자원에 접근하는 것이 가능하기 때문이다.아직은 시기상조이다. 당분간은 여전히 이전 버전의 클라이언트들을 지원해야 하므로 WINS의 존재는 분명히 필요하다.

출처 - http://blog.daum.net/luckyman717