자격증과 세미나, 프로그램 이야기를 주저없이 써봅니다.

Since 2008. 10.

IT 자격증/MCTS, MCSE, MCITP

최적화된 WINS 서버 구현 방법

럭키맨 운수 2009. 2. 25. 01:13
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을 이용한다. 이 트래픽이 심각하게 고려해야 할 수준이라면 몇가지 설정을 통해서 복제트래픽을 최적화 해 줄 수도 있다.