3월 29일 (금) 오후 10:19

logo

  • home
  • head
  • itnews
  • product
  • mobile
  • game
  • benchmark
  • analysis
  • blog

개봉 2023.11.22. / 등급: 12세 관람가 / 장르: 드라마 / 국가: 대한민국 감독 : 김성수 출연 : 황정민, 정우...
노량: 죽음의 바다 / 개봉 2023.12. / 장르: 액션, 드라마 / 국가: 대한민국 감독 : 김한민 출연 : 김윤석, ...

마이크로소프트의 네트워크 환경에서 여러 가지 서비스를 하는 서버들이 있지만, 역시 빼 놓을 수 없는 서비스가 하나 있다. 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서버가 어떤 서비스로서 등록되었다는 역할을 구별해 준다.


13069601498C4B92C58FC0

<화면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를 구현하기 위해 인터페이스를 포함시켜 놓은 것이다.

 

1505BC01498C4BE3B4B3DD

<표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>

 

14125F0D4992F500D4013D

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

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

 

1311200D4992F52507C49E

<화면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>을 보면서 설명을 한다.

 

12377A0E4996E3AE4C9C4F

<그림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>

 

14384F0E4996E3E0BE48C3

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

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

 

15018B0B4996E4064BE684

<화면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>

 

154EF40D4996E421B15465

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

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


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

 

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

 

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

 

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

 

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

 

156A5E0B49A41BFA6689A4

<그림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 복제 일정을 확인한 것을 볼 수 있다.

 

140C690E49A41C4B044ED1

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

 

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

 

1260680C49A41C78D09D02

<화면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을 지원하고 있다.

 

112B7D0F49A41D67E9BCA8

<그림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 이라는 파일명을 가지고 있다. 윈도우탐색기에서 도구-폴더옵션-보기 메뉴에서 '알려진 파일 형식의 파일 확장명 숨김'옵션을 지워주면 확장자까지를 확인할 수 있다.

136A380B49A41D879856F1

< 화면10. lmhosts 파일 >

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

 

1462730C49A41DA0F9A360

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

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

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

 

13607F0C49A41DC1B7C35C

<화면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






  1. 이더리움에 대해(Ethereum)

    이더리움(Ethereum)은 비탈리크 부테린(Vitalik Buterin)이 2014년 개발했습니다. 거래 명세가 담긴 블록이 사슬처럼 이어지는 블록체인(blockchain)을 기반으로 하며 네트워크만 연결되어 있다면...
    Date2017.12.16 CategoryIT KNOWLEDGE
    Read More
  2. 사물 인터넷 정의 : 필수 IoT 용어 가이드

    Jon Gold | Network World 사물 인터넷과 관련해서는 온갖 프로토콜과 표준, 기술 약어가 난무한다. IoT 언어를 조금 더 이해하기 쉽도록 하기 위해 이러한 모호한 용어들의 의미를 정리했다. 6LoWPAN : 약...
    Date2017.11.06 CategoryIT KNOWLEDGE
    Read More
  3. “빅데이터란 무엇인가?” 구성요소와 기반 기술의 이해

    InfoWorld staff | InfoWorld 인간은 매일 먹고 일하고 놀고 데이터를 생산한다. IBM에 따르면 인류가 하루에 생산하는 데이터의 양은 무려 250경 바이트에 이른다. DVD를 쌓는다면 달까지 왕복할 만큼...
    Date2017.09.16 CategoryIT KNOWLEDGE
    Read More
  4. 비트코인의 이점은 무엇인가

    비트코인은 매우 낮은 비용으로 돈을 교환할 수 있는 가장 간단한 방법입니다. 보다 쉬운 모바일 결제모바일로 비트코인 결제를 하실 때에는 "스캔-앤-페이" 두 단계만 거치면 됩니다. 카드...
    Date2017.08.11 CategoryIT KNOWLEDGE
    Read More
  5. 5G란 무엇인가 : 현황, 기술개발, 해결과제, 일정, 전망

    Craig Mathias | Network World 5G라고 알려진 차세대 무선 WAN 통신이 조만간 언론의 1면을 장식할 것으로 보인다. 5G는 유선 보완제에서 유선 대체제로 이동통신의 진화를 완성할 것이며, 전략적으...
    Date2017.07.15 CategoryIT KNOWLEDGE
    Read More
  6. [보안NW] 내부망, DMZ구간, 외부망 이란?

    개인정보보호법이 시행되면서 개인정보보호의 기술적 보호대책을 위해 내부망, DMZ구간, 외부망이라는 말이 많이 언급되고 있습니다. 내부관리계획을 세우다보면, 내부망을 단순히 사내조직원들끼리 사용...
    Date2017.07.08 CategoryIT KNOWLEDGE
    Read More
  7. Wireless Multicast 무선구간 멀티캐스트

    * Lesson 2 Describing Implications for Multicast in 802.11 (p223) 멀티캐스트는 유선쪽에서 오는 트래픽을 무선 STA에 배포 하거나 혹은 모빌리티 메시지 정보를 교환하는데 사용 합니다.     -----...
    Date2017.06.10 CategoryIT KNOWLEDGE
    Read More
  8. L2TPv3 프로토콜, VPN

    L2TPv3(Layer 2 Tunnel Protocol Version 3, RFC 3931)은 Layer2 의 프레임을 그대로 IP 캡슐화해서 remote 측으로 전달하는 프로토콜이다. 즉 CDP, STP, ARP 까지 사업자를 통해서 remote 측으로 전달 ...
    Date2017.05.13 CategoryIT KNOWLEDGE
    Read More
  9. 리눅스 vi 명령어 모음

    <command mode> h 왼쪽 j 아래 k 위 l 오른쪽 H,J,K,L(대문자): 끝까지 이동 w: 단어의 처음 특수기호 인식 왼->오 공백인식 b: 단어의처음 특수기호 인식 오->왼 공백인식 e: 단...
    Date2017.04.10 CategoryIT KNOWLEDGE
    Read More
  10. L4 스위치/Alteon SLB/서버로드밸런싱

    대부분의 네트워크망에서 꼭 알아야지만 전체 트래픽의 흐름도를 알 수 있는 Layer4 Switch 입니다. 일단 가장 Layer4 SW를 많이 사용하는 SLB(Server Load Balancing)부터 알아보겠습니다. 이후 방...
    Date2017.02.27 CategoryIT KNOWLEDGE
    Read More
  11. 프로그래밍 언어별 딥러닝 라이브러리 정리

    AI Korea Open 그룹에서도 라이브러리에 관한 투표가 있었고, 많은 분들이 관심있어할 만한 부분이라 생각해서 한 번 정리해 봤습니다! (AI Korea Open 그룹의 투표 결과) Python요즘 뜨는 언어답게, ...
    Date2017.02.02 CategoryIT KNOWLEDGE
    Read More
  12. DevOps (데브옵스)에 대하여

    최근에 DevOps(데브옵스)라는 개발방법론이 솔솔 들리고 있다.  데브옵스는 개발(Development) + 운영(Operation)을 합친 말로 개발와 운영의 상호작용을 원할하게 하는데 있다고 합니다.  [마이크로소...
    Date2016.12.27 CategoryIT KNOWLEDGE
    Read More
  13. 색공간 (sRGB, 어도비 RGB 등)

    목차가장 기본적인 색공간 RGB sRGB(standard RGB) 애플 RGB(Apple RGB) 어도비 RGB(Adobe RGB) 비디오에서 가장 많이 사용하는 색공간 YUV, YCbCr/YPbPr NTSC의 색공간 YIQ 인쇄 매체의 핵심 색공간 CMY, ...
    Date2016.11.25 CategoryIT KNOWLEDGE
    Read More
  14. 2016 SDS 그 유형과 소비 형태에 관해

    소프트웨어 정의 스토리지, Software defined storage(이하 SDS)가 어느 정도 업계에 많이 알려지고 실제로 도입되는 경우가 발생하면서 SDS에 대한 궁금함이 더욱 더 많이 생기고 있습니다. 업계의 많은 ...
    Date2016.11.04 CategoryIT KNOWLEDGE
    Read More
  15. 하둡, HDFS, 맵리듀스 개념

    빅 데이터는 클라우드 컴퓨팅만큼이나 널리 확산되고 있는 개념이다. 그러나 빅 데이터의 역량과 한계에 관해서는 사람들이 잘못 알고 있는 부분들이 많다. 특히 빅 데이터와 관련해 사람들은 다음의 질문...
    Date2016.09.21 CategoryIT KNOWLEDGE
    Read More
  16. 스토리지 풀 개요 (Storage Pool)

    풀 또는 스토리지 풀은 지정된 볼륨 세트에 대한 모든 데이터를 공동으로 포함하는 MDisk 콜렉션입니다. 그림 1은 네 개의 MDisk가 있는 스토리지 풀을 나타냅니다. 그림 1. 스토리지 풀 풀의 모든 MDi...
    Date2016.08.22 CategoryIT KNOWLEDGE
    Read More
  17. Windows Dump 구성 및 강제 생성

    Windows에서 강제로 덤프 생성하기 Action Plan 1. What: Full dump 저장을 위해 Page file을 총 메모리+1MB 정도로 증설 What: ASR 비활성화 To do. 1) Win7 > 제어판\시스템 및 보안\시스템 > 고급 선...
    Date2016.07.29 CategoryIT KNOWLEDGE
    Read More
  18. SMP(Symmetric Multi-Processing) vs AMP(Asymmetric Multi-Processing)

    오늘은 SMP와 AMP에 대해 간략히 학습하는 시간을 갖도록 하겠습니다. 1. SMP(Symmetric Multi-Processing) SMP은 두 개 이상의 동일한 프로세서가 하나의 메모리, I/O 디바이스, 인터럽트 등의 자원...
    Date2016.06.20 CategoryIT KNOWLEDGE
    Read More
  19. 쿨러 베어링 타입별 특징 (슬리브/볼/FDB)

    베어링 [bearing] : 회전하고 있는 기계의 축을 일정한 위치에 고정시키고 축의 자중과 축에 걸리는 하중을 지지하면서 축을 회전시키는 역할을 하는 기계 요소 냉각팬의 베어링 방식에...
    Date2016.05.11 CategoryIT KNOWLEDGE
    Read More
  20. 컨테이너 기반 가상화 기술

    Micro Service Architecture 에서 인프라 적으로 중요한 개념으로 꼽으면 아래와 같이 2가지로 정리할 수 있다.Application Programming Interface (API) 가상화 (virtualization) API는 이미 많은 개발...
    Date2016.04.29 CategoryIT KNOWLEDGE
    Read More
  21. 하이퍼 컨버지드 인프라 (Hyperconverged Integrated System)

    통합 시스템, 컨버지드 인프라 등으로 불리는 Integrated System의 성장과 발전이 데이터센터 전체에 상당히 크게 영향을 미칠 것으로 보입니다. 시장 조사 기관인 가트너에 따르면 2014년부터 2019년에 이...
    Date2016.03.22 CategoryIT KNOWLEDGE
    Read More
  22. 모바일IP 이론

    * Mobile IP (모바일 IP) : 모바일 IP 에 대해서 알아본다. 1. Mobile IP 정의 Mobile IP는 IETF 표준 통신 프로토콜로, 이동 기기 사용자로 하여금 한...
    Date2016.03.14 CategoryIT KNOWLEDGE
    Read More
  23. 윈도우10 단축키 모음

    윈도우 +1, +2, etc 바탕 화면으로 전환하고 시작 N을 작업 표시 줄에 응용 번째. 예를 들어,에서 번호 응용 프로그램이 목록에 첫 번째 중 하나 발사, 왼쪽에서 오른쪽으로. 윈도우 + 작업 센...
    Date2016.03.05
    Read More
  24. TLS 전송계층보안

    인터넷에서의 정보를 암호화해서 송수신하는 프로토콜. 넷스케이프 커뮤니케이션스사가 개발한 SSL(Secure Sockets Layer)에서 기반한 기술로, 국제 인터넷 표준화 기구에서 표준으로 인정받은 프로토콜이...
    Date2016.02.04 CategoryIT KNOWLEDGE
    Read More
  25. 시스코 스위치 이더채널

    Etherchannel, 이더채널 - 두 스위치간에 연결된 복수개의 포트를 하나의 포트처럼 동작시키는 것을 말한다 이더채널을 구성할 때 사용되는 프로토콜은 시스코에서 만든 PAgP(Port Aggregation Protocol)와...
    Date2015.12.28 CategoryIT KNOWLEDGE
    Read More
  26. 새로운 가상화 기술 Docker와 컨테이너

    Docker사는 지난 6월 10일에 Docker 1.0 발표와 함께 Docker를 기반으로 한 애플리케이션 개발, 배포, 실행 기능을 갖춘 서비스 "Docker Hub"를 발표했습니다. Docker는 컨테이너형 가상화를 실현하는 오픈...
    Date2015.11.25 CategoryIT KNOWLEDGE
    Read More
  27. [Network Protocol] L3 Switch 구조에 대한 이해

    안녕하세요? NetmaniasTalk입니다. 아래 글은 예전에 Netmanias Magazine에 기고했던 글의 일부로써, L3 Switch(예. Cisco 6500 series, Juniper MX series)의 구조에 대한 설명입니다. ...
    Date2015.10.27 CategoryIT KNOWLEDGE
    Read More
  28. [Network Protocol] IP QoS 소개

    안녕하세요? NetmaniasTalk입니다. 오늘도 네트워크 초보자님들을 위한 코너로써 유선망에서의 QoS에 대해서 설명드리도록 하겠습니다. Network에서 QoS라 함은 (1) 중요한 패킷(예. IPTV, VoIP, Bus...
    Date2015.10.27 CategoryIT KNOWLEDGE
    Read More
Board Pagination Prev 1 2 3 4 5 6 7 Next
/ 7