윈도우 서버 바로알기

윈도우 서버 바로알기

 

Part 1. 윈도우 서버로 무엇을 할 수 있을까?

 

이 강좌는 윈도우 서버가 네트워크나 시스템을 운영하는데 기본적으로 활용된다는 것은 알고 있지만, 정확히 이 서버가 무엇을 하는지는 알지 못하는 초보자를 위해 준비했다. 앞으로 6회에 걸쳐 그동안 필자가 경험으로 익힌 내용을 초보자들이 쉽게 익히고, 적용해보도록 할 것이다. 이번 달에는 윈도우 서버로 무엇을 할 수 있을지, 그 종류는 어떤 것이 있는지 알아본다.

필자가 초보시절 전산실에서 무엇을 해야 할지 모르고 방황할 때 NT4.0을 보고 "이거다" 싶은 생각이 든 적이 있었다. NT4.0이 무엇인지 개략만 듣고 배우고 싶어하는 마음에 여기저기 쫓아다닌 기억도 난다. 하루는 관련 업체에 찾아가 무작정 가르쳐달라고 조른 기억도 난다. 하지만 업체에서는 무작정 NT4.0을 배우겠다고 하지 말고, SQL인지 익스체인지인지 분명히 하라며 필자를 돌려보냈다. 그 당시 필자는 SQL이 뭔지 익스체인지가 뭔지도 모르고 있었던 때라 마냥 서운하기만 했다.

나중에 안 사실이지만, NT4.0만 가지고는 밥벌이를 하기 어렵다. 물론 대기업 같은 경우 NT4.0을 전문으로 하는 엔지니어가 있을 수 있지만 그런 자리는 들어가기도, 새로 나기도 힘들다. 중소기업이면 운영체제인 NT4.0을 할 줄 알고 상위의 서비스를 지원하는 서버 제품군도 다룰 줄 아는 엔지니어를 선호하기 때문이다.

'서버가 뭐예요?'

회사에 입사해 NT4.0과 윈도우2000을 다루면서도 서버에 대한 개념을 남에게 설명하는 것은 매우 어려운 일이었다. 누가 나에게 "서버가 뭐에요?" 아니면 "서버가 도대체 무엇을 하나요?"라고 물어오면 "대표적으로 홈페이지를 서비스한다"고 대답한다. 하지만 이는 스스로 만족하지 못한 답이란 것을 알기에, 남에게 서버를 쉽게 설명할 수 있는 방법을 찾아보기로 했다.

서버는 Serve라는 단어에서 유래가 됐다. Serve는 여러가지 의미가 있지만 우리가 말하는 서버는 '시중들다', '접대하다', '공급하다' 라는 의미가 가장 적합한 것 같다. Server는 시중드는 사람 또는 공급자이다. 서버를 설명할 때 클라이언트(client)를 설명하지 않을 수 없다. 클라이언트는 '의뢰인', '단골'이라는 뜻이 있다. 즉, 서버에게 무엇을 의뢰해서 의뢰한 내용을 얻어내는 단골이다.

우리가 흔히 이야기하는 서버 클라이언트는 네트워크 세상에서 서버가 어떤 특정 서비스를 클라이언트에게 바로 제공할 수 있게 공급자의 자세를 가지고 있다. 클라이언트는 다양한 서비스를 받을 수 있으며, 서버의 제약이 없다면 그 서비스를 언제 어디서나 의뢰해 서비스를 받을 수 있다.

다양한 서비스는 NOS(Network Operation System)라는 NT4.0이나 윈도우2000과 2003만을 가지고는 힘들다. 물론 간단하게 홈페이지만을 보여주겠다고 하면, 이미 열거한 NOS만으로 충분히 서비스할 수 있지만 인터넷이 발전하면서 환경이 복잡해지고 NOS만으로 서비스는 불가능하다.

왜 마이크로소프트가 NOS에 SQL이나 익스체인지 또는 ISA(Internet Security & Acceleration) 서버를 NOS 제품군에 포함을 시키지 않았을까. 그냥 익스체인지를 윈도우2000이나 2003에 포함시켰으면 좋았을텐데. 하지만 뭐, 마이크로소프트의 마케팅 전략인 것을... 소비자의 입장에서는 같이 포함시켜 저렴하게 판매했으면 하는 바람이 있지만 말그대로 바람일 뿐이다.

간단한 윈도우 서버의 역사

윈도우 서버라는 것이 어떻게 태어나게 됐는지 아는 것도 서버를 이해하는데 유용한 정보가 될 것이다. 우선 간단하게나마 계보를 살펴보자(그림).

 

윈도우 NT의 개발 역사와 장점

톰 R. 하프힐의 글에 의하면 윈도우 NT는 5년간에 걸쳐 약 600만 코드로 구성됐고 1억 5000만 달러가 소요됐다. 개발 비용이 지금 돈으로 약 2000억 원이 소요된 것이고, 95년도 경제 규모로 볼 때는 어마어마한 비용이 소요된 것이다.

그리고 부지런히 NT4.0을 배우고 있는 와중에 개발 코드 네임이 카이로와 휘슬러라는 윈도우2000에 대한 소식이 들려왔다. 윈도우2000의 개발 코드명인 카이로는 마이크로소프트의 본사에서 상당히 먼 거리다. 이것과 비교해서 윈도우 95의 코드 네임은 시카고였다. 그만큼 윈도우2000 개발 과정이 멀고 어렵다는 이야기다.

윈도우2000은 윈도우 98과 NT4.0의 인터페이스를 일원화했으며, NT커널을 사용해 진정한 32비트 아키텍처를 갖췄으며, FAT32와 NTFS를 지원했다. 윈도우2000의 핵심 요소는 누가 뭐라해도 액티브 디렉토리 서비스다. 마이크로소프트는 윈도우2000을 발표하기 전이나, 발표한 후에도 액티브 디렉토리를 알리는데 많은 노력을 한 것도 사실이다.

역시, 윈도우2000에도 IIS가 포함됐고 MMS라는 스트리밍 동영상 서버 기능이 추가됐다. 다행히 동영상 서비스 기능을 윈도우2000이 내장하고 있어 따로 비용이 들지 않는다. NT4.0에서는 원격 컨트롤 기능이 내장됐던 것이 없다. 일반적으로 VNC라는 원격 관리 프로그램을 이용했는데 사용하기 상당히 답답했다. PCAnywhere라는 제품은 마음에 들었지만 상용 버전인 것으로 알고 있다. 윈도우2000은 나름대로 안정성과 신뢰성을 바탕으로 빠르게 NT4.0에서 윈도우2000으로 업그레이드가 됐다. 잘 운영되고 있는 윈도우2000을 사용할 만 하니 곧 윈도우2003이 나왔다. 윈도우2003은 한층 강화된 디렉토리 서비스와 IIS 6.0을 기반으로 하는 닷넷 서비스를 지원한다. 윈도우2003은 닷넷으로 가는 첫걸음이다. 다른 나라는 환경이 어떨지 잘 모르지만 아직 국내에서는 윈도우2000에서 윈도우 2003으로 업그레이드한 경우는 드물다.

지금까지 NT4.0에서 윈도우2000으로 업그레이드된 과정을 살펴보면서 간단하게 서버의 탄생과정과 장점을 살펴봤다. 이제 각 서버 제품군별로 각각의 특징과 기능을 살펴보고 어떤 상황에서 어떤 서버 제품들을 사용해야 할지 알아보자.

 

다양한 윈도우 서버 제품군

윈도우 서버 제품군은

▲윈도우 2000 서버

▲윈도우 2003 서버

▲SQL 서버

▲BizTalk 서버

▲커머스 서버

▲컨텐트 매니지먼트 서버

▲익스체인지 서버

▲오퍼레이션 매니저

▲시스템 매니지먼트 서버

▲ISA 서버 등으로 구분된다.

이외에도 몇가지가 더 있지만 이들 제품만 알아도 충분할 것이다.

·윈도우2000 서버

어떻게 보면 가장 할 말이 많은 제품이고 열거한 제품의 기반이 되는 제품이다. 윈도우2000은 제대로된 32비트 체제를 갖춘 진정한 엔터프라이즈 NOS다. 엔터프라이즈 NOS를 만들기 위해 마이크로소프트는 신뢰성을 높였다. 윈도우2000 발표 당시 빌게이츠는 NT4.0과 윈도우2000에 대한 재부팅이 필요한 기간을 NT4.0은 7일, 윈도우2000은 28일로 설명했다. 이것이 어떤 것을 기준으로 나왔는지는 모르겠으나 숫자상의 비교만 봐도 윈도우2000이 안정적이다. 실제적으로 서버를 운영하면서 정기적인 재부팅은 하지 않는다. 시스템이 다운될 때나 필요에 의해서 재부팅을 하는 것 외에는 윈도우2000으로 운영하면서 일정한 기간마다 재부팅을 하는 경우는 없다. 참고로, 윈도우2000을 운영하면서 두달 넘게 재부팅을 하지 않은 적도 있다. 그래도 쌩쌩하게 잘 운영되고 있다. 그것이 SQL이든 IIS이든 말이다.

이렇게 신뢰성을 높이고 안정성을 높이면서 윈도우2000은 엔터프라이즈 시장 진입을 꾀했다. 윈도우2000의 서버 제품군을 네 가지로 나누면서 하드웨어 지원과 각 버전마다 특별한 기능을 넣어 제품을 차별화하면서 중소기업과 대형 시장을 함께 노리고 있었다.

윈도우 서버 제품군에는 윈도우2000 프로페셔널이라는 제품이 있다. 윈도우2000 프로페셔널은 윈도우2000을 NT로 비교하면 NT3.5 워크스테이션으로 보면 되겠다(그림). 윈도우 서버 제품군을 나누면서 중소와 대형을 확실하게 구분했고 CPU와 메모리 사용 제한을 각각 다르게 가져갔으며, 어드밴스 서버 이상에서는 네트워크와 장애에 관련된 네트워크 로드밸런싱과 클러스터링을 지원한다. 네트워크 로드밸런싱은 여러대의 서버가 같은 서비스를 하고 있어 로드밸런싱을 할 수 있으며 한대의 호스트가 장애를 일으켜도 서비스 정지가 없다는 장점이 있다. 클러스터링도 장애에 대비한 기능을 가지고 있지만 클러스터링은 스토리지를 필요로 한다. 왜냐하면 SQL이나 익스체인지와 같은 애플리케이션을 분산해 저장하는 것보다 스토리지라는 한곳의 저장소를 이용해야 하는 특성 때문이다.

 

이밖에도 액티브 디렉토리, 향상된 TCP/IP 기반의 네트워킹, 향상된 보안 인프라와 원격 관리 등 할 말이 많지만 다른 제품군 설명을 위해 접어두고 추가적으로 설명하도록 한다.

 

 

·윈도우2003 서버

윈도우2003에서는 개선된 액티브 디렉토리도 있지만 초미의 관심사는 닷넷(.NET)이다. 닷넷 또는 닷넷 프레임워크(.NET Framework)란 빠르게 변하는 개발 환경과 모든 것이 웹(Web)으로 집중되는 인터넷 시대에 부흥하기 위해 마이크로소프트가 개발한 프로그램 개발 환경이다. 닷넷의 특징은 한마디로 플랫폼에 독립적이면서 프로그램을 개발하기가 쉬워졌다는 것이다. 일정한 규칙 즉, CLS(Common Language Specification)를 따르는 언어라면 어떤 언어라도 이 프레임워크에서 실행할 수 있다.

그리고 CLS를 따르는 언어는 CLR(Common Language Runtime)이라는 독립적인 환경에서 실행된다. 닷넷 프레임워크를 위한 코드를 만들 수 있도록 마이크로소프트에서 기존 언어의 문제점을 보안하고 장점들을 살려 만든 새로운 언어가 C#이다. C#은 닷넷 프레임워크에는 여러 언어가 존재하지만 그 중에서 가장 중심이 되고 또 개발자가 쉽게 다가갈 수 있는 언어다.
닷넷 프레임워크는 그림과 같이 CLR과 BCL(Base Class Library)로 구성되며 용도에 따라서 웹에서 사용하는 ASP.NET과 일반 애플리케이션을 구성하는 윈도우 폼(form)으로 구분할 수 있다. ASP.Net에서 사용하는 폼이 웹폼(WebForm)이기 때문에 웹폼 프로그램이라고도 한다.
닷넷 환경이란 어떤 운영체제에서도 닷넷 플랫폼만 설치돼 있다면 닷넷의 프로그램이 실행되는 환경이다. 즉, 본래의 운영체제 안에 닷넷 프레임워크라는 독립적으로 운영할 수 있는 또 하나의 플랫폼을 집어넣는 것으로, 이렇게 되면 실제 운영되고 있는 플랫폼이 무엇이든지 간에 닷넷 프레임워크라는 환경만 만들게 되면, CLR이 실행될 수 있고, CLS를 따르는 어떠한 언어로 작성된 프로그램이라도 실행할 수 있다.

 

 

·SQL 서버

너무나도 잘 아는 제품이다. 아마 윈도우 서버에 탑재된 서버 제품 중 가장 많이 쓰이는 제품이 아닐까 생각된다. SQL은 초기에 마이크로소프트에서 자체로 제작해 시작한 것이 아니다. 사이베이스라는 제품의 SQL엔진을 사용했지만 추후에 사이베이스의 엔진을 도입해서 자체적으로 SQL을 제작했다. 이 부분은 알아야 할 사항이 많아서 4월 강좌에서 자세히 설명할 것이다.

 

 

·BizTalk 서버 

시스템, 직원 및 거래 업체를 이전보다 빠르고 효과적으로 통합할 수 있게 해주는 BizTalk 서버다.

BizTalk 서버는

▲거래 업체 구축과 관리 서비스

▲비즈니스 활동 모니터링

▲포괄적인 규칙 엔진

▲문서 전송과 라우팅 서비스 등을 제공한다.  

 

 

·커머스 서버

차세대 온라인 비즈니스를 빠르게 구축하는데 필요한 마이크로소프트 윈도우 서버 시스템 플랫폼이다. 또한 마이크로소프트 닷넷 기술 중에서 커머스 서버를 사용하면, 사이트의 기능을 확장하고 이윤을 창출하며 사용자 경험을 확장할 수 있다. 커머스 서버 사용자 프로파일링, 개인화, 카탈로그 관리, 주문 처리, 글로벌리제이션과 고급 온라인 업무 분석 등을 위한 강력한 기능을 제공한다.

 

 

·컨텐트 매니지먼트 서버 

마이크로소프트 닷넷 기술과 연결된 마이크로소프트 컨텐트 매니지먼트 서버는 기업이 빠르고 효율적으로 컨텐트가 풍부한 웹 사이트를 구축, 배포하고 유지 관리할 수 있는 기업 웹 컨텐트 관리 시스템이다. 컨텐트 매니지먼트 서버는 웹 게시 절차를 간소화해 사이트 유지 관리 비용을 절감하고, 기업 사용자가 자신들의 독자적인 컨텐트를 관리할 수 있도록 한다.

 

 

·익스체인지 서버

많은 사람들이 익스체인지가 메일 서버가 아니라는 것을 알 것이다. 익스체인지는 메시징 시스템으로 메일 기능도 하지만 메시지를 주고 받는 역할을 한다. 대표적인 것이 MSN이다. 사내 인트라에서(만일 회사가 전국적이나 아니면 세계적으로) 메시징 시스템으로 쓰일 수가 있고 그것에 전자우편이 통합돼 있다. 이 제품도 이용하는 비율이 높기 때문에 그 이외의 서버 제품군에서 자세히 다룰 예정이다.

 

 

·오퍼레이션 매니저

마이크로소프트 오퍼레이션 매니저(Microsoft Operation Manager)이라는 것으로 일반적으로 맘(MOM)이라고 부른다. MOM은 IT 작업의 효율성을 향상시키기 위한 엔터프라이즈급 작업 관리를 제공한다. SMS(System Management Server)와 결합을 해서 사용한다면 서버를 모니터링하는 좋은 솔루션이 될 수 있다.

 

 

·SMS(Systems Management Server)

마이크로소프트 플랫폼의 변경과 구성 관리를 위한 포괄적인 솔루션을 제공하므로, 조직들은 적절한 소프트웨어와 업데이트를 신속하고 비용 효율적으로 사용자에게 제공할 수 있다. 단적인 예로 패치를 수동으로 하지 않고 SMS를 이용해 원하는 시간대에 작업하고 스스로 재부팅할 수 있도록 설정할 수 있다.

 

 

·ISA 서버

마이크로소프트 ISA(Internet Security and Acceleration) 서버 2004는 고급 애플리케이션 계층 파이어월, VPN과 웹 캐시 솔루션으로 네트워크 보안과 성능을 향상시켰다. ISA 2000은 다뤄봤지만 불편한 점이 적지 않다. 이런 부분을 해소했고 보다 쉽게 구성할 수 있도록 했다고 하니 보다 쉽게 파이어월과 웹 캐시(프락시)를 이용할 수 있다. 또한 윈도우2000에서 지원하는 VPN 보다 강력한 기능으로 제공한다.

 

이외에도 많은 서버 제품군이 있다. 그러나 대중적이고 많이 사용되는 제품들과 필요하다고 생각이 되는 관점에서 서버 제품군들을 골라봤다. 주로 애플리케이션용 서버는 제외했다. 이 글을 읽는 분은 윈도우 서버에 대해서 관심을 가진 초보자라고 생각된다. 당부하고 싶은 것은 쉽게 배운 것은 쉽게 잊어버린다는 사실이다. 손으로 익히지 않고 눈으로 익히면 쉽게 잊기 마련이다. 모든 기능을 몸소 체험하고 장애가 발생했을 때 하나씩 해결하는 것이 얻는 게 더 많을 것이다.

 

 

Part 2. 윈도우 서버의 꽃, 액티브 디렉토리

 

윈도우 서버는 다양한 인터넷 서비스를 지원하는 네트워크 운영체제다. 윈도우 서버는 과거 NT 4.0에서 윈도우 2000, 2003까지 지속적으로 발전하고 있다. 마이크로소프트는 윈도우 2000 이후에 핵심 기술로 불리는 액티브 디렉토리를 개발하면서 확고한 자리를 굳히기 시작했다. 이번 강좌는 윈도우 2000의 핵심인 액티브 디렉토리에 대해 자세히 알아본다.

 

마이크로소프트가 윈도우 2000을 발표할 때, 마케팅의 많은 부분을 액티브 디렉토리(Active Directory)를 알리는데 쏟았다. 그도 그럴 것이 윈도우 2000에서 액티브 디렉토리를 뺀다면 별로 할 얘기가 없기 때문이다. 모든 서비스(DHCP, 파일 서버, 프린터 서버 등)가 이 액티브 디렉토리하에서 실행된다고 봐도 된다. 물론 액티브 디렉토리가 없으면 윈도우 2000에서 서비스를 제공하지 못하는 것은 아니지만 어느정도의 한계가 있다.

이제부터 액티브 디렉토리 뿐만 아니라 윈도우 2000의 기술적인 부분이 있어서 우리의 신입사원 귤창규군과 함께 이야기를 풀어나가기로 한다. 귤창규군을 소개하자면, 필자와 같이 일하는 엔지니어로, 근면 성실하고 실력이 출충한 직원이다. 귤을 굉장히 좋아하는데 매번 혼자 먹어서 귤창규군이라고 부르고 있다.

필자 : 귤창규군, 액티브 디렉토리가 뭐죠?
귤창규군 : 액티브 디렉토리는 네트워크의 자원인 웹서버, 파일서버, SQL서버나 프린터 서버 등을 쉽게 찾을 수 있도록 하고, 모든 자원을 액티브 디렉토리가 관리해줌으로서 관리를 편리하게 할 수 있는 것입니다.

맞는 말이다. 모든 내용을 담고 있다고 할 수 없지만 핵심적인 부분을 빠뜨리지 않고 이야기했다. 윈도우 2000으로 넘어오면서 마이크로소프트는 기존의 NT 4.0의 도메인이라는 한계를 극복하고 보란 듯이 엔터프라이즈 네트워크 운영체제로 발돋움하기를 원했고, 그것을 액티브 디렉토리가 담당해 줄 것이라고 믿고 있다. 이런 액티브 디렉토리에 대해 알기 전에 먼저 두가지 꼭 짚고 넘어갈 것이 있다. 바로 DNS(Domain Name System)와 워크그룹이다.

 

 

일반 DNS와 액티브 디렉토리 DNS의 차이점

DNS(Domain Name System)라고 하면 일반적으로 www.ionthenet.co.kr이라는 인터넷 웹페이지 어드레스를 브라우저에 입력해 해당 웹서버에서 데이터를 가져오면 브라우저에 그 데이터가 펼쳐지면서 홈페이지를 볼 수 있다. 이같은 작업은 웹서버도 필요하지만 www.ionthenet.co.kr이라는 어드레스를 컴퓨터가 인식할 수 있는 숫자로 바꿔야 하는 시스템이 필요하다. 간략하게 설명하면 웹브라우저에서 www.ionthenet.co.kr이라고 입력하면 자신의 네트워크 등록정보에 입력된 DNS 서버로 가서 www.ionthenet.co.kr의 IP 어드레스가 있는지 묻는다. IP 어드레스를 접속자의 PC로 보내고 다시 같은 IP 어드레스를 가지고 웹 서버와 TCP 직접 통신을 맺어 데이터를 교환하는 것이다. 그러나 자신이 네트워크 등록 정보에 설정한 DNS에 해당 도메인명과 IP를 가지고 있지 않다면 루트네임서버로부터 질의를 한다. 전세계적으로 루트네임서버는 13개가 있는데, 그 역할이 다르다.

루트네임서버에서 첫 단계의 네임서버에서 co.kr이라는 것을 알고, 두 번째 단계에서는 ionthenet이라는 것을 알게 되면 ionthenet.co.kr의 도메인에 대한 네임서버는 누구인가를 찾아서 해당 네임서버에서 IP 값을 클라이언트에게 반환한다(그림 1). 참고자료는 http://secure.pe.kr/default.aspx?tabid=1&module=Lecture View&id=2245&code=7를 통해 확인할 수 있다.

(그림 1) 인터넷 접속 단계

초기의 DNS는 그 시스템이 적어서 LMHOSTS 파일이라는 곳에 각 서버의 IP 어드레스와 매핑되는 웹 어드레스를 넣어뒀다. 그러나 인터넷이 방대해지면서 업데이트의 문제로 인해 DNS라는 시스템이 개발돼 DNS 트리 구조로 해결했다. 

이런 DNS의 개념을 윈도우 2000의 액티브 디렉토리에 도입하게 됐다. 액티브 디렉토리를 지원하는 DNS는 인터넷 DNS로도 사용할 수 있지만, 가능하면 액티브 디렉토리만을 위해서 사용하는 것이 좋다. 마이크로소프트에서는 액티브 디렉토리 DNS와 인터넷 DNS 사이에 파이어월을 놓고 TCP/UDP 53번 통신만을 가능하게 하라고 권장한다.

 

SRV와 증분 영역 전송 기능을 가진 액티브 디렉토리

그렇다면 액티브 디렉토리와 DNS는 무엇이 다를까. 우선 가장 큰 차이점은 SRV이다. SRV는 서비스 위치 레코드 값으로 이를 통해 누가 도메인 컨트롤러이고 누가 글로벌 카달로그(Global Catalog 이하 GC)인지 사이트가 어디인지 알 수 있다.

누가 도메인 컨트롤러이고 누가 글로벌 카달로그인지 아는 것은 매우 중요하다. 이것을 모른다면 클라이언트는 글로벌 카탈로그를 몰라 액티브 디렉토리의 자원 등 기타 다른 것을 검색하지 못해서, 본인이 사용하고 싶어하는 자원을 이용하지 못하는 경우가 생긴다. 어떤 것이 도메인 컨트롤러인지를 모른다면 애당초 도메인으로 로그온하지 못해서 액티브 디렉토리의 서비스를 이용하지 못할 것이다. 이런 맥락으로 본다면 SRV는 상당히 중요하다.

액티브 디렉토리는 동적 업데이트를 지원한다. 동적 업데이트는 DNS 서버에서 클라이언트에 대한 정보를 수동으로 수정하거나 등록하는 것이 아니고 클라이언트가 도메인에 결합되면서 자동으로 자신의 정보를 DNS에 등록하는 것을 말한다. 필수는 아니지만 동적 업데이트를 사용하는 것이 좋다.

또다른 하나는 증분(increment) 영역 전송 기능이다. 이것 역시 필수는 아니지만 필요하다. DNS에 대한 정보는 일반적으로 마스터라는 서버와 세컨더리라는 서버로 운영된다. 일반적으로 마스터에서는 기록과 수정을 할 수 있고 이 정보를 그대로 센컨더리로 전송한다. 이전의 고전적인 DNS는 마스터의 모든 영역을 다 전송했지만 이 액티브 디렉토리 DNS에서는 변형된 정보만을 전송한다. 이 기능을 이용하면 편리하다. 일반적으로 DNS는 같은 네트워크에 위치하지 않는다. 마스터가 다운되면 세컨더리가 동작하기 때문에 마스터쪽의 네트워크가 다운돼도 연속적으로 서비스할 수 있다는 장점이 있다.

액티브 디렉토리를 설치하기 전에 DNS를 액티브 디렉토리에 미리 설치하고 구성할 수 있으며, DNS가 설치되지 않았다면 액티브 디렉토리를 설치하면서 DNS를 자동으로 구성할 수 있다. DNS를 조금더 명확하게 알려면 수동으로 구성한 후 액티브 디렉토리를 설치할 것을 권장한다.

 

도메인 vs 워크그룹

우선 (그림 2, 3)을 잘 비교해 보자. (그림 2)와 (그림 3)은 한눈에 봐도 뭔가가 다르다. 데이터센터에 대해 바로 다음 호에서 자세하게 다루겠지만, 여기서는 간략하게 두 그림의 차이점을 설명한다. 디렉토리 데이터베이스는 윈도우 2000 액티브 디렉토리를 이야기하는 것과 마찬가지이다. 이것이 NT 4.0일 때에는 SAM(Security Account Manager)이라는 것과 동일하게 처리됐다. 그러나 그 규모나 사용면에서 큰 차이가 있다. 워크그룹이라는 것은 액티브 디렉토리를 서비스하고 컴퓨터가 없는 모델이다. 이 말은 (그림 2)에서 본다면 사용자가 gildong이라는 계정으로 윈도우 2000 프로페셔널에 로그온해야 하고, 윈도우 NT 워크스테이션이 프린터 서버로 동작하고 있다면 이 워크스테이션에도 gildong이라는 계정이 있어야 한다. 계정이 있어야 프린터 서버를 사용할 수 있기 때문이다. (그림 2)에서는 모든 서버에 gildong이라는 계정이 있어야 어떤 서비스에 접근할 때에도 액세스하는데 지장이 없다. 계정이 여러군데 분산돼 있으면 아무렇지도 않은 것 같지만 관리하기가 쉽지 않고 능률이 오르지 않는다. 계정 하나만 가지고 설명했지만 다른 부분에서 각각의 서버의 SAM에는 gildong 계정 정보를 가지고 있어야 한다. 액티브 디렉토리에서는 이것을 (그림 3)에서 보는 것처럼 DC(Domain Controller)가 다 가지고 있고 여기에 설정된 계정 정보를 가지고 각각의 멤버 서버에 접근할 수 있다. 이제부터 본격적으로 액티브 디렉토리에 대해 이야기 해보자.

(그림 2) 디렉토리 데이터 베이스 비교 1

(그림 3) 디렉토리데이터 베이스 비교 1

 

인증과 확인으로 안전해지는 액티브 디렉토리

필자가 처음에 액티브 디렉토리에 대해 개념조차 잡지 못한 적이 있는데, 그 이야기를 먼저 해 보자. 액티브 디렉토리를 이야기하면 도메인이라는 말이 참 많이 나온다. 일반적으로 도메인이라면 ionthenet.co.kr을 말하지만 액티브 디렉토리에서의 도메인은 범위를 말한다고 이해하면 된다. 도메인의 네트워크 범위는 다를 수 있다. 서로 다른 네트워크를 사용하지만 같은 도메인으로 결합해서 해당 도메인에 있는 자원을 사용할 수 있다. 도메인은 논리적인 범위를 말한다. 물리적인 범위는 한 사무실의 네트워크가 도메인이 될 수 있고 한건물 전체가 도메인이 될 수가 있고, 서울 본사, 부산 지사, 대전 지사가 도메인이 될 수도 있다. 여기에 미국 지사까지도 도메인으로 묶을 수 있다. 이같은 점이 액티브 디렉토리의 매력이다. 예를 들어서 대전지사에 있는 파일 서버에 사용자가 접근할 수 있고 파일을 열람할 수 있는 권한이 있다. 그리고 대전지사와 함께 협력 업무를 한다면 파일 서버를 통해 필요한 자료를 주고 받을 수도 있다.

액티브 디렉토리를 이야기할 때 가장 중점적인 두 부분이 관리와 보안이다. 우선 보안에 대해서 간단하게 살펴보자. 네트워크의 자원을 사용하기 위해서는 인증(Authentication)과 확인(Authorization)이 필요하다.

필자 : 귤창규군, 인증과 확인이 뭐죠?
귤창규군 : 인증은 어떤 서비스나 개체에 접근할 때 서비스나 개체가 '너는 누구니?' 하고 인증하는 것입니다. 예를 들면 어떤 회사에서 재무팀이 회계 관련 사이트에 접속한다면 전 사원이 주소를 안다고 해도 아무나 접속하지 못하게 해야 하기 때문에 이에 대한 인증 절차를 걸쳐야 한다. 브라우저를 통해 접속한다면 인증창이 뜨면서 '너는 누구니?' 하고 물어보면 나는 재무팀의 김양이야. 내 ID는 kim이고 비밀번호는 1234라고 입력하면 웹페이지가 보여지게 것이죠.
필자 : 그럼 확인은요?
귤창규군 : 글쎄, 그건 잘 모르겠는데요.
필자 : 그렇게 인증을 거쳤다고 바로 데이터에 액세스할 수 있는건 아니죠. 윈도우에서는 ACL(Access Control List)라고 해서 개체에 대한 권한을 설정하는데 이것이 확인입니다. '이 페이지(해당 폴더)는 재무팀만이 볼 수 있다'라고 설정했기 때문에 김양은 볼 수 있는 것이죠. 만일 다른 사용자가 자신의 계정으로 접근을 한다면 kim이라는 ID를 사용한다고 해도 보는 것이 불가능한 것입니다. 이것이 이중 보안 절차입니다.

 

편리한 데이터베이스의 관리 

액티브 디렉토리는 중요한 사용자 정보를 가지고 누가 어디에 접근하고 접근할 수 없는지 구분한다. 그럼 이같은 정보를 어디에 어떻게 저장하고 있을까. 액티브 디렉토리를 설치하게 되면 c:\winnt\ntds라는 폴더가 생긴다. 여기서 보면 ntds.dit라는 파일이 생기는데, 이 파일은 수정된 액세스 데이터베이스이며 이 파일에 사용자 정보가 거의 담겨져 있다. NT 4.0에서는 이같은 정보를 SAM이라는 곳에 보관했지만, 액티브 디렉토리와 비교해보면 그 규모나 사용면에서 본다면 현저하게 차이가 있다.

Ntds.dit에 들어 있는 정보와 ntds.dit를 관리하는 모든 프로그램을 일컬어 '디렉토리 서비스'라고 부른다. 액티브 디렉토리라고 부르는 것은 마이크로소프트의 디렉토리 서비스를 뜻한다. 노벨의 네트웨어가 디렉토리 서비스를 시작했고, 마이크로소프트는 이 디렉토리 서비스를 한단계 발전시켜 액티브 디렉토리를 만든 것이다. 이렇게 한곳의 DC 또는 여러곳의 DC에서만 계정 정보라든지 기타 액티브 디렉토리에 관련된 모든 사항을 관리하기 때문에 관리가 쉽다. 

이제 이렇게 ntds.dit라는 액티브 디렉토리를 이용하려면 DNS에서 말했던 것처럼 액티브 디렉토리 서버를 찾아서 로그온해야 한다. 어디에 있는지 알려 주는 것이 DNS의 역할이고 액티브 디렉토리를 찾았으면 적절한 계정과 비밀번호를 이용해 로그온해야 한다. 로그온할 때는 LDAP(Lightweight Directory Access Protocol)이라는 프로토콜을 사용해 로그온을 시도한다. 다음은 액티브 디렉토리에서 사용되는 프로토콜이다.

·액티브 디렉토리 : 윈도우 2000에서는 이전 버전에서 사용하던 평면적인(flat) 형태의 NetBIOS 도메인 이름은 하위 호환성을 위해서만 제공하고 도메인의 네임 서비스로서 DNS를 채택했다. 또한 도메인 컨트롤러를 찾는 요청에 WINS가 아닌 DNS 서버가 사용된다.

·TCP/IP(Transmission Control Protocol/Internet Protocol) : TCP/IP를 윈도우 2000의 기본 프로토콜로 채택함으로써 인터넷 통신에 최적화된 시스템을 운영할 수 있다.

·DHCP(Dynamic Host Configuration Protocol) : 액티브 디렉토리로부터 승인을 얻지 못한 DHCP 서비스를 정지시킴으로써 잘못된 DHCP 서버로 인한 클라이언트의 IP 획득 실패 등의 오류를 해결했다.

·커베로스(Kerberos) : 도메인 환경에서 이전의 NTLM을 대체할 보안 인증 프로토콜이다. 이것은 SSO(Single Sign On)과 상호 인증을 제공한다.

·X.509 : 이것은 PKI(Public Key Infrastructure) 기반 인증서(Certificate) 서비스의 표준 프로토콜이다. 액티브 디렉토리는 X.509 표준을 지원하며 인증서와 사용자 계정의 매핑을 통해 사용자를 인증할 수 있도록 제공한다.

·SNTP(Simple Network Time Protocol) : 윈도우 2000에서 로그온할 때 사용자가 로그온하는 시간 정보가 사용된다. 로그온 서버와 클라이언트의 시간이 일치하지 않는다면 사용자는 로그온을 실패하게 된다. 도메인 컨트롤러는 타임 서버(Time Server)로 동작하고 도메인의 멤버인 클라이언트의 시간과 동기화를 제공한다. 그때 SNTP 프로토콜이 사용된다.

·LDAP(Lightweight Directory Access Protocol) : 액티브 디렉토리에 접근할 때 사용하는 프로토콜이다. 윈도우 2000의 액티브 디렉토리는 LDAP 프로토콜에 근간을 두고 있다. 역시 사용자가 액티브 디렉토리에 쿼리를 찾고자 한다면 LDAP 프로토콜을 필요로 한다. 이때 도메인 컨트롤러는 LDAP 서버이고 사용자의 컴퓨터는 LDAP 클라이언트가 된다.

·LDIF(LDAP Data Interchange Format) : 도메인 컨트롤러 간의 액티브 디렉토리 데이터베이스 복사시 사용되는 프로토콜이다.

사용자 입장에서 편의성 강화

클라이언트는 액티브 디렉토리에 로그온해 업무를 시작할 것이다. 회계와 관련된 자료를 프린터해서 회의할 수도 있고 영업 전략 회의를 하기 위해서 파일 서버에 저장된 자료를 다시 한번 검토할 수 있다. 이렇게 사용자가 원하는 서비스가 어디에 위치해 있는지는 클라이언트에게는 중요하지 않다. 다만 그것을 쉽게 찾을 수가 있고 이용하는 것이 중요하다. 이렇게 찾아주는 역할을 하는 것이 액티브 디렉토리다.

사용자가 어떤 자원을 찾을 때에는 이 글로벌 카탈로그를 이용한다. 전체 검색하는 것이 아니고 빠르고 효율적인 검색 방법을 제공한다. 이렇게 검색도 제대로 하고 모든 클라이언트가 만족하면서 사용하고 있다가 회사가 지사를 가지거나 확장하면 전산 시스템도 확장해야 한다. 이렇게 확장하면 전산 담당자는 골치가 아플 것이다. 다시 새로운 계정을 지사에 심어야 하고 가서 권한 설정도 다시 해야 하고, 여러가지 복잡한 문제에 접하게 된다. 그러나 액티브 디렉토리는 이같은 확장을 쉽게 하도록 지원한다.

온더넷으로 간단하게 예를 들어보자. 우선 착각하지 말아야 할 것은 DNS에서 말한 www.ionthenet.co.kr은 인터넷용 도메인이다. 지금부터 말하는 ionthenet.co.kr은 액티브 디렉토리 도메인이다. 서울에 있는 사무실 직원들은 DNS를 통해서 iontehnet.co.kr라는 도메인을 이용해 업무를 원할하게 보고 있었다. 실질적으로 로그온하는 액티브 디렉토리 서버는 pdc.ionthenet.co.kr이 될 것이다. 이것은 자식 도메인이 아니고 pdc라는 것은 호스트 이름이다. 일반적으로 마이크로소프트에서는 PDC(Primary Domain Controller) 라고 이름을 붙인다.

부산에 지사를 개설하면 전산 시스템도 확장해야 한다. 이렇게 되면 부산의 액티브 디렉토리 도메인은 자식 도메인이라고 해서 busan.ionthenet.co.kr이라는 도메인을 하나 더 만든다. 이렇게 해서 부산에서는 pdc.busan.ionthenet.co.kr이라는 DC에 로그인해서 액티브 디렉토리 서비스를 이용할 수 있다. 그럼 부산의 액티브 디렉토리 서버를 어떻게 설정할까? 그냥 간단하게 액티브 디렉토리를 설치하면 된다.

그러나 서울에 있는 PDC를 설치할 때는 도메인을 ionthenet.co.kr로 했지만 부산에서 설치할 때의 기존 도메인을 추가해야 하는 것이 차이가 있다. 이것을 자식 도메인이라고 한다. 이렇게 설치하고 계정 정보라든지 기타 설정을 따로 잡아야 하는 것은 아니다. 그냥 내버려두면 둘이 알아서 설정하는데, 이같은 기능이 가능한 것은 복제라는 것이다. NT 4.0과 윈도우 2000의 액티브 디렉토리의 차이점은 백업 도메인 컨트롤러의 차이점이다.

중앙 관리로 효율성 향상

NT 4.0에서의 PDC와 BDC(Backup Domain Controller)라는 모델을 기본으로 한다. PDC가 다운되면 BDC가 도메인 컨트롤러 역할을 한다. 그러나 NT 4.0에서의 주도메인 컨트롤러와 백업 도메인 컨트롤러의 차이는 있다. 주도메인 컨트롤러의 사용자 계정이 담겨져 있는 SAM 데이터베이스만이 수정할 수 있다. 백업 도메인 컨트롤러는 읽기만 가능해 주 도메인 컨트롤러의 SAM 데이터베이스를 백업 도메인 컨트롤러로 가져와서 읽기만 할 수 있다. 이는 만일 주도메인 컨트롤러가 서버 장애로 다운된다면 백업 도메인 컨트롤러에서 서비스는 계속할 수 있지만 제대로 된 서비스를 한다고는 할 수 없다. 서비스를 하는 방법은 있지만 바로 적용되지 않는다.

윈도우 2000은 이같은 점을 극복했다. 도메인 안에 있는 모든 DC는 수정할 수 있다. 이 말은 이제는 백업 도메인 컨트롤러의 개념이 없다는 것이다. 모든 DC는 하는 일이 같다(엄밀히 얘기하면 도메인 첫번째 설치된 DC와는 차이가 있다). 각각의 계정 정보를 어떤 도메인 컨트롤러에서도 수정할 수 있다. 이렇게 수정된 액티브 디렉토리 데이터베이스, 즉 ntds.dit는 서로 복제된다. 이 복제로 인해서 주도메인 컨트롤러와 백업 도메인 컨트롤러의 경계가 없어졌다. 이는 온더넷의 부산 지사에서 새로운 도메인 컨트롤러를 추가하면 5분 단위로 복제가 이뤄진다는 뜻이다. 

그래서 서울에 액티브 디렉토리 서버의 정보를 복제한다. 만일 부산에서 계정 정보가 수정되거나 새로운 계정이 추가됐다면 이를 서울의 액티브 디렉토리 서버에 반영하게 된다. 이런 것들이 복제로 이뤄진다. 부산에서 변경되면 변경된 사항이 서울로 전파되고 서울에서 변경된 사항이 부산으로 전파된다. 이렇게 되면 관리 측면에서 용이하다.

관리자는 서버의 정보를 복제하는 동안 네트워크 트래픽에 대해 걱정하지 않을 수 없다. 사실 현재 우리나라 네트워크 인프라는 전세계 1위라고 해도 과언이 아니다. 그만큼 네트워크 인프라가 훌륭하게 구축돼 있지만, 액티브 디렉토리는 서로 복제가 이뤄질 때 네트워크 트래픽 문제를 고려해 복제된 사항을 보낼 때 기존 데이터의 10%로 압축해 보낸다. 이렇게 함은 보다 원활하게 네트워크 전송을 도울 수 있다.

NT 4.0의 주도메인 컨트롤과 백업 도메인 컨트롤에 대해 이야기했다. 만일 서울 사무실만 있었다면 서울 사무실에서는 백업 DC가 있어야 한다. PDC가 서버 장애로 서비스하지 못하면 BDC가 그 역할을 대신해 NT 4.0과 같이 지속적으로 서비스할 수 있을 것이다. 윈도우 2000 액티브 디렉토리는 설치된 용도와는 상관없이 수정과 생성이 이뤄지기 때문이다. 

이렇게 해서 부산지사까지 확장하는데 별 어려움없이 작업이 이뤄졌다. 그런데 대전, 대구, 광주 등 회사가 번창해 지사가 계속 생기는 것이다. 이같은 상황이라면 전산 시스템도 확장해야 하고 관리 인원도 많이 필요하다. 이미 액티브 디렉토리 가장 큰 쟁점은 보안과 관리라고 언급했듯이, 각 지사마다 관리자를 둬야 할 것인가를 고민해야 한다. 하지만 마이크로소프트는 그렇게 하지 않아도 된다고 말한다. 대전 지사에서는 관리자를 도와줄 오퍼레이터 정도의 관리자를 둬서 패스워드 변경이라든지 기타 간단하고 반복적인 작업, 이를테면 백업 작업 등을 관리할 수 있다. 그 이외의 여러가지 기술은 중앙의 관리자가 처리하면 된다. 중앙에서 처리하면 각 DC가 이를 복제하기 때문에 지사의 사람들은 그냥 로그온해서 서비스를 이용하기만 하면 된다. 참고로 마이크로소프트는 사용자 계정을 1500만 개를 만들어 테스트했는데 원활하게 이뤄졌다고 한다. 여러 개로 분산된 환경은 관리하기가 수월하지는 않지만, 액티브 디렉토리를 통해 관리를 편리하게 할 수 있다. 

터미널 서비스를 이용한 애플리케이션 공유

윈도우 2000은 NT 4.0보다 현격하게 향상된 점이 하나 있는데, 바로 터미널 서비스다. 이것은 마이크로소프트가 제작한 것이 아니고 서드파티 제품인데 상당히 가볍고 여러 가지 장점이 있다. 윈도우 2000으로 발전하면서 많은 관리자들이 이 터미널 서비스를 이용해서 원활하게 원격에서 관리하고 있다. 내가 관리자라서 주로 터미널 서버의 관리자 모드만을 이용해 그럴지 몰라도 터미널 서버는 애플리케이션 모드라는 것도 있다. 예를 들어, 사무실에 20여 명의 사무를 보는 직원이 있는데, 이 모든 직원들이 마이크로소프트 오피스를 이용한다고 하자. 그렇다면 20여 명의 마이크로소프트 오피스 라이선스를 구입해야 할지 모른다. 그러나 이것을 윈도우 2000 서버에 오피스 프로그램을 설치하고 클라이언트는 터미널 서비스 클라이언트 라이선스만을 가지고 서버에 접속해 오피스 작업을 한다면 더욱 저렴하게 사용할 수 있다.

이렇게 터미널 서버를 이용해서 서버를 관리하는 관리자들이 있다. 그런데 이 터미널은 자기 앞의 모니터를 놓고 보면서 서버를 컨트롤하는 것과 마찬가지이기 때문에 이것이 뚫린다면 참으로 위험하다. 그래서 어떤 IP 대역에서 터미널 서비스를 접근하지 못하고 대신 사무실 PC에서만 터미널 서버로 접근할 수 있게 IPSec을 이용해서 설정하려고 했다. IPSec은 TCP/IP 필터링보다는 한단계 진일보한 시스템이다.

이렇게 IPSec을 이용해서 설정해야 하는 서버가 30대가 넘었다. 각각의 서버에서 IPSec을 이용해 사용자가 원하는 사항을 설정하려면 하루 종일 걸릴 것이다. 이같은 상황은 워크그룹에서나 일어날 수 있다. 그러나 액티브 디렉토리하의 멤버 서버들이기 때문에 GPO(Group Policy Object)라는 것이 적용된다. 액티브 디렉토리 서버에서 어떤 정책을 적용하면 이것이 각각의 멤버 서버에 적용된다. 그래서 액티브 디렉토리 서버에 IPSec을 설정한 것이다. 복제를 통해 변경된 정책은 백업 도메인 컨트롤러에 적용됐고 각각의 멤버 서버에도 적용됐다. 아주 단편적인 이야기지만 가슴에 와 닿을 것이다.

액티브 디렉토리에 대한 것은 마이크로소프트 홈페이지 말고도 여러 사이트에서 쉽게 정보를 얻을 수 있다. 어떤 것이든 처음 접하는 주제는 어렵기 마련이다. 4년전 스트리밍 서버를 공부하는데 그렇게 용어가 적응이 안돼 고생했던 기억이 난다. 액티브 디렉토리도 생소한 용어가 많을 것이다. 하나하나씩 접근하면 어렵지 않게 액티브 디렉토리에 대해 하나씩 배울 수 있을 것이다.

 

 

Part 3. 웹서비스를 위해 탄생한 IIS

 

마이크로소프트가 윈도우 2000을 발표하면서 액티브 디렉토리를 알리는데 주력한 것과 동시에 IIS에도 많은 공을 들여 NT4.0의 IIS4.0 보다 훨씬 더 개선된 성능의 IIS5.0을 선보였다. IIS는 웹서비스 뿐만 아니라 FTP 서비스, SMTP 서비스, NNTP 서비스 등을 한 서버에서 지원하는 서비스를 말한다. 이번 강좌는 IIS가 지원하는 서비스인 FTP에 대해 알아본다.

 

IIS(Internet Infomation Server)는 인터넷 서비스와 관련된 웹서비스, FTP 서비스, SMTP(Simple Mail Transport Protocol) 서비스, NNTP(Network News Transfer Protocol), 서버익스텐션 등이 한 서버에서 동작할 수 있는 서비스다. 이는 서비스와 프로세스를 분석해 보면 조금 더 자세히 알게 된다. 예를 들어 리눅스의 웹서비스는 APACHE로 실행되고, FTP는 PROFTPD로, 전자우편은 Sendmail이 각각 담당하고 있다. 이 세가지 서비스를 총괄적으로 관리하고 담당할 서비스는 따로 없다.

이제 IIS에 대한 개념을 알게 됐으니 하나씩 자세히 이야기를 해 보자. IIS에 대해 보다 자세하게 이야기하기 전에 인터넷 서비스와 밀접한 DNS를 간단히 짚어보자.  

인터넷용 DNS로 외부 질의시 활용

DNS는 지난 강좌에서 상세히 설명했다. 그러나 IIS에서 DNS는 지난 강좌에서 설명한 액티브 디렉토리 DNS와는 큰 차이가 난다. 즉, 마이크로소프트에서 이야기하는 액티브 디렉토리 DNS는 어느 한 네트워크 구역으로 이해하면 쉽다. 액티브 디렉토리 도메인을 벗어나면, 외부 네트워크와 연결할 때에는 그 도메인 이름을 액티브 디렉토리 DNS가 찾을 수 없다. 왜냐하면 그 도메인 네임의 IP가 없기 때문에 찾지 못한다. 그리고 액티브 디렉토리 DNS 특성상 인터넷으로 질의를 하지 못한다. 이렇기 때문에 마이크로소프트에서 추천하는 것은 인터넷용 DNS를 따로 둬 외부에 질의할 DNS는 인터넷용 DNS를 이용하는 것을 권고한다. 이렇게 설치하면 액티브 디렉토리 DNS에서 인터넷용 DNS로 쿼리하고 그 결과값을 받아 온다. 2월호의 인터넷 DNS 구성도를 보면 웹브라우저에 입력한 어드레스가 어떻게 호스트까지 전달되는지 쉽게 이해할 것이다.

실제로 필자가 경험한 이야기다. 어느날 고객사의 서버를 이전하면서 실수로 DNS에서 IP를 잘못 적었다. 그것도 끝자리 한자리만. 때문에 페이지가 자기 사이트가 아닌 다른 사이트로 접속됐다. 그런데 미국에 DNS의 정보 변경이 완료돼 우리가 운영하는 DNS에서 IP를 변경하고 캐시값을 줄였는데도 하루가 지나도록 다른 사이트로 접속되는 것이다. 이는 DNS를 우리 회사만 운영하는 것이 아니고 여러나라에서 여러 DNS 서버를 운영하기 때문이다.  각자 주기적으로 DNS 정보 변경을 업데이트해야 되는데 이것이 완료돼야 고객사의 홈페이지를 제대로 볼 수 있는 것이다. 이것 때문에 고객에게 욕먹은 것은 둘째치고 회사 사람들에게 창피했다. 밤을 새워 일을 마무리했는데도 제대로 사고의 개요을 제대로 파악하지 못했으니 말이다. 시스템을 관리하다보면 일이 꼬여서 갑자기 하늘이 노랗게 변하는 경우가 있지만 절대 당황하거나 서두르면 안된다. 일을 더 그르치게 된다.

 

웜의 진원지로 활용되는 IIS

IIS의 구성요소는 (화면 1)을 보면 한눈에 들어오게 된다. (화면 1)은 제어판→프로그램 추가 제거→윈도우 구성 요소→IIS→자세히 버튼을 클릭하면 모두 볼 수 있다.

(화면 1)은 윈도우 2000을 초기 설치할 때도 볼 수 있는 화면이다. 미리 구성을 계획했다면 초기 설치시에 구성 요소를 선택하고 설치를 마무리하고 해당 구성 요소의 보안 취약점을 윈도우 업데이트를 통해 보강해야 한다. 그렇지 않고 윈도우 2000의 설치를 마치고 난 후 IIS의 구성 요소를 추후에 설치해도 상관없다. 그러나 설치가 끝나면 반드시 윈도우 업데이트를 통해 보안 취약점을 패치하기 바란다.

마이크로소프트의 IIS는 항상 뜨거운 감자였다. NT4.0에 IIS4.0을 운영하던 시절에 서버가 원인 모르게 다운됐다. 서버에서 운영되는 웹사이트에 접속하면 브라우저는 ASP 0125라는 메시지만 뿌린다. 이는 윈도우 2000으로 업그레이드되면서 해결됐다. 그리고 그 유명했던 코드레드와 님다도 IIS에서 동작했다. 코드레드와 님다 웜은 자기 자신만이 감염되는 것이 아니고 다른 시스템까지 감염해 앞으로 전개될 웜의 특성을 단적으로 보여주기도 했다.

IT 업계에서 자주 거론되는 것은 그만큼 유명하다는 것이다. 해커의 특성 중 하나가 유명한 시스템을 공격해 자기 만족을 높이는데 있다고 한다. 완벽한 보안은 없다는 것을 의미하기도 한다. 보안 전문가들이나 해커는 모든 시스템에서 허점은 있기 마련이라고 말한다. 금융권의 경우도 따로 해커를 둬 자사 시스템의 보안상 취약점을 발견하기도 한다. 누가 먼저 뚫느냐가 중요한게 아니라 누가 먼저 알아내느냐가 문제이기 때문이다. 

(화면 1) IIS의 구성 요소 

필자는 윈도우 2000의 IIS 설치시 IIS에서 많이 사용되는 FTP, WWW, SMTP를 설치했다. 그리고 과외적으로 NNTP를 더 추가했다. 설치를 마치고 난 후 시작→관리 도구를 보면 인터넷 서비스 관리자라는 메뉴가 생긴다. 이것을 실행해도 되고 명령줄에서 INETMGR이라고 해도 실행된다(화면 2).

(화면 2) IIS 실행화면

(화면 2)에서 ism은 마스터 부분이다. 이 마스터 부분은 윈도우 2000 설치시 정했던 호스트 네임과 동일하게 설정된다. 마스터에서 설정된 값은 그 아래 존재하는 모든 사이트에 영향을 미친다. FTP WWW에 대한 마스터 기능을 설정할 수 있지만 SMTP에 대한 설정은 마스터 부분에서 설정할 수 없다. SMTP에 대한 설정은 (화면 2)의 기본 SMTP 가상 서버의 등록정보를 열어 편집해야 한다.

마스터에서 팝업 메뉴를 보면 주목해야할 두가지 메뉴가 있다. '구성 백업/복원'과 'IIS 다시 시작'이다. 윈도우 2000으로 발전하면서 IIS는 그 버전이 5.0으로 업데이트됐고 기존 4.0과는 많은 부분이 달라졌다. IIS를 백업받아 놓는다면 시스템이 완전히 망가져 재설치하고 백업본으로 복구하게 될 경우 많은 도움이 된다. IIS 4.0에서는 레지스트리에 많은 설정 값이 있었다. 그러나 윈도우 2000에서는 메타베이스가 많은 정보를 저장해 레지스트리를 컴파일해서 읽어들이는 값을 줄일 수 있기에, 성능에도 도움이 된다. 메타베이스는 메타에디터라는 프로그램으로 수정할 수 있다. 이렇게 백업을 받는 이 메타베이스를 백업받는 것으로 시스템을 재설치하고 시스템 백업 파일을 이용해 시스템에 관련된 사항을 복구하고 메타베이스를 이용해 복구하면 기존의 정보를 그대로 복구할 수 있다. 웹사이트가 한 두개라면 그걸 사람이 일일이 기억하는 것이 가능하겠지만 사이트가 수십, 수백개가 되고 설정 사항을 모르면 복구하기가 힘들 것이다.

또하나 'IIS 다시 시작'이라는 메뉴다. 이 메뉴는 서버를 재부팅하는 수고를 덜어준다. 이 메뉴는 DOS 명령으로도 가능하다. DOS 창에 C:Documents and Settingsdec1231>IISRESET /RESTART를 입력하고 실행하면 다음과 같은 결과값을 얻는다.

중지하려고 합니다...
인터넷 서비스를 성공적으로 중지했습니다.
시작하려고 합니다...
인터넷 서비스를 성공적으로 다시 시작했습니다.

이와 같은 경우는 서버를 재부팅해서 얻는 결과와 같고 IIS에 관련된 사항을 메모리에서 내렸다가 다시 켜는 것을 말한다. 한마디로 서버 호스트는 살아 있으면서 IIS만을 재시작하는 효과와 맞먹는다. 웹서버가 꼬이고 웹의 부하가 높다면 우선 이것으로 조치를 취하게 되면 어느정도 숨통은 트인다. 그러나 이것이 최선의 해결책은 아니다. 문제점은 반드시 근본을 찾아서 고쳐야 한다.

 

마스터의 FTP 등록정보와 설정 사항

등록정보를 보면 FTP와 WWW를 설정할 수 있다. 우선 FTP에 대한 사항을 먼저 설명하겠다. 해당 등록정보의 탭에 대한 설정 사항은 각 메뉴가 어떤 역할을 하는지 설명할 것이다. 자세한 설정보다는 각 메뉴의 개념을 잡는 방향으로 설명하도록 하겠다.

(화면 3) ism 등록 정보

마스터에서 설정하는 사항이나 '기본 FTP 사이트(화면 1)'의 설정 사항이나 큰 차이는 없다. 다만 마스터이기 때문에 여기에서 설정한 값들이 그대로 기본 FTP 사이트에 적용된다는 것이다. 여기서 설정한 값들이 기본 FTP 사이트에 적용되는 것은 사실이지만 그 적용된 값은 기본 FTP 사이트에서 동작된다. 그래서 다음 설명부터는 특별히 언급하지 않으면 마스터의 FTP 등록정보를 말하는 것이고 기본 FTP 사이트라고 하면 (화면 2)의  FTP 사이트를 말하는 것이다.

그럼 같은 설정 값이면 왜 마스터를 만들어서 관리하는 것일까. FTP 사이트는 그렇게 많이 필요하지 않지만 앞에서 백업/복원에서 설명했듯이 많은 수의 웹사이트가 있다고 가정하자. ISP의 요청으로 IP가 변경된다고 생각해보자. 아니면 ADMIN 말고 IIS 관리자를 따로 두었는데 그 관리자가 그만 두었으면 삭제해야 할 것이다. 이것을 몇 십개, 몇 백개의 사이트의 등록정보를 모두 읽어 변경해야 한다면 작업량은 무수히 많을 것이다. 이럴때 마스터를 이용해 한번에 일괄적으로 변경하면 아주 효율적이다.

(화면 3)에서 FTP를 일반적으로 설정할 수 있다. 설명란에는 FTP 사이트의 이름을 넣고 IP 어드레스와 포트는 수정할 수 없다. 기본 FTP 사이트는 IP 어드레스와 포트를 수정할 수 있다. 만일 네트워크 어댑터를 두개 이상 사용하고 한 네트워크 어댑터로만 FTP를 수신하려면 여기서 해당 IP를 할당하면 된다. 그렇지 않고 모두 할당하지 않는다면 모든 어댑터가 FTP에 접속할 준비를 한다.

기본 FTP 사이트를 보면 TCP 21번으로 기본적으로 할당돼 있다. 연결 설정은 기본값으로 지정돼 있다. 이 연결값에 해당하는 시간이 지나면 FTP는 자동으로 연결이 끊어지게된다.

(화면 4) 이벤트 등록 정보

(화면 4)는 커넥션이 자동으로 끊어진 것을 이벤트 로그에서 보여주는 것이다. 로깅 사용은 기본으로 설정돼 있다. 로그가 쌓이는 기본적인 경로는 C:WINNTsystem32LogFiles MSFTPSVC1이다. 그러나 서버의 성능을 높이려면 이 로그를 시스템 파티션이 아닌 다른 파티션에 쌓이게 해야 한다. 따라서 로깅 사용의 등록정보로 들어가 일반 속성에서 로그 파일 디렉토리 부분을 변경하는 것을 권장한다. 그리고 어떤 항목을 로그에 기록할 것인가 하는 것도 이 부분에서 설정할 수 있다.

보안 기능과 메시지 기능 활용하기

고객의 서버가 해킹됐다는 이야기를 듣고 시스템을 살펴보면 이 부분에서 익명의 연결 허용을 체크해 놓은 경우가 많다. 익명이라는 것은 FTP 접속을 시도할 때 액티브 디렉토리에서 사용자에 대한 인증과 확인 작업이 없는 것을 의미한다. 웹브라저를 띄워 FTP://HOSTADDRESS를 입력하면 기본적으로 인증창이 뜬다. '너는 누구니?'하고 서버가 물어 보는 것이다. 그럼 사용자는 이에 맞는 아이디와 패스워드를 클릭해야 하는 것이 인증이다. 그러나 이같은 과정을 통과했다고 해서 바로 액세스가 되는 것이 아니다. 디렉토리에 부여된 ACL(Access Control List)을 통해서 디렉토리에 접근 권한이 있어야 결국 디렉토리 리스트를 볼 수 있다. 그러나 익명 연결 계정이 체크돼 있다면 이와같은 두 과정을 무시하고 아무나 들어오라고 설정한 것과 마찬가지다. 참고로 최근에는 디렉토리를 올릴 때 그냥 평범한 이름으로 올리지 않는다. 윈도우 탐색기나 DOS 창에서 일반 커맨드 명령으로 지우지 않게 파일 이름을 위장해서 올려놓는다. 따라서 IIS를 초기 설치하고 네트워크에 연결하기 전에 이 값은 꼭 해제하고 저장하기를 권장한다. 운영자는 기본적으로 ADMINISTRATORS 그룹이 기본 운영자다. 일반 사용자에게 FTP에 대한 운영권을 맡기려면 여기에서 권한을 추가하면 일반 사용자 계정으로 FTP를 변경할 수 있다.

메시지 기능은 사용자들이 FTP로 접속하고 끊을 때 메시지를 뿌려준다. 그렇게 큰 의미는 없지만 사용자가 메시지를 보고 어느 서버를 접속했는지 알려줄 수 있다.

이미 언급했지만 마스터의 FTP 등록정보 등록시 기본 FTP 사이트의 설정값도 같이 변경해야 한다. 홈디렉토리 메뉴는 마스터라고 생각하지 말고 기본 FTP 사이트라고 생각하고 설명을 이해하기 바란다. 여기에는 사용자가 접속할 홈디렉토리에 대한 권한을 설정할 수 있다. 읽기와 쓰기 기능을 부여하는데, 현재 읽기만 설정돼 있다면 인증과 확인이 진행되고 있다하더라도 읽기만 가능하다. 디렉토리 목록 스타일은 사용자가 접속시 디렉토리 리스트를 어떤 방식으로 보여주는가에 있다.  

디렉토리 보안에서는 FTP에 접속할 수 있거나 접속할 수 없도록 설정할 수 있다. 이같은 방법은 IP 접속을 제한하기 위함이다. FTP 접속을 시도하게 되면 접속자의 IP를 체크할 수 있기 때문이다. 아울러 단일 IP 접속 제한과 특정한 네트워크 대역 전체에 접속 제한 기능을 설정할 수 있다.

 

여러 FTP 만들기

서버 관리자가 사무실에서 기본 FTP 사이트를 만들어 제대로 운영하고 있었다. 어느날 재무팀에서 재무팀 자료는 돈과 관련된 자료이니 다른 사람이 접속하지 못하게 해달라는 요청이 들어왔다. 완전 별개의 사이트로 만들어 달라는 요구로, 몇가지 방법이 있다. 기본 FTP 사이트에 재무팀 폴더를 만들고 ACL에서 재무팀 계정을 하나 만들어 재무팀 계정만 접근하게 하는 것이다. 그러나 재무팀은 완전 별개의 FTP를 원한다.

이렇게 되면 두 가지 방법이 있다. 마스터의 팝업 메뉴를 띄우면 새로 만들기→FTP 사이트가 있다. 이 메뉴를 이용하면 된다. 다른 기본 설정 사항은 이미 설명한 기본 FTP 사이트와 동일하지만 기존의 기본 FTP 사이트와 포트 충돌을 피하기 위해 다른 포트를 할당해야 한다. 21번 포트를 사용하겠다고 하면 포트 충돌로 인해 설정이 이뤄지지 않는다. 기본 포트인 1024 윗단의 포트를 설정해 사용하면 별무리없이 설정될 것이다.

다른 하나는 파이어월이나 다른 네트워크의 특성으로 인해, 하는 수 없이 21번 포트를 사용해야 하는 경우는 가상 디렉토리를 이용해야한다. 이 메뉴는 기본 FTP 사이트 아래 생성된다. 기본 FTP 사이트의 팝업 메뉴를 띄워 새로만들기→가상디렉토리를 선택한다. 가상 디렉토리를 설정할 때 주의할 점은 가상 디렉토리명과 계정명이 동일해야 한다는 것이다. 이것만 조심하면 사이트를 생성하는 데에는 어려운 점이 없을 것이다.

FTP 포트에 대한 말이 나온김에 FTP 특성에 대해 간단히 집고 넘어가야 할 것은 액티브 모드와 패시브 모드다. 어느 서버 운영체제든 FTP의 연결 포트는 21(COMMAND PORT)번이다. 한가지 더 알고 있어야 할 사항은 FTP의 데이터 전송 포트는 20번(CONTROL PORT)이다. 이것을 다시 한번 정리하면

·액티브 모드 : COMMAND PORT 21번
                     CONTROL PORT 20번

·패시브 모드 : COMMAND PORT 21번
                     CONTROL PORT 1024이후

이것을 이해하고 있다면 파이어월 설정이나 기타 네트워크의 특성 때문에 FTP 접속이 안되는 경우를 체크할 수 있을 것이다. 원격에서 텔넷 명령을 이용해서 서버의 FTP 접속을 간단하게 COMMAND로 테스트할 수 있다. 방법은 다음과 같다.

C:Documents and SettingsAdministrator>TELNET ISM.WBH.COM

이와같은 명령을 실행한후, 입력하는 명령은 명령창에 보이지가 않는다. 사용자 계정과 패스워드를 통해 접속하면 다음과 같은 화면을 볼 수 있다.

220 ism Microsoft FTP Service (Version 5.0).
331 Password required for 계정명
230 User 계정명 logged in.

이것으로 FTP 설정에 대한 설명을 마치도록 한다. 끝으로 한마디 더 한다면 로그에 대한 부분이다. 로그에 대한 사항은 WWW를 다루면서 자세히 설명할 예정이지만, 로그가 서버의 성능에 영향을 미치는 것은 당연한 결과다. 특히, 웹 같은 경우는 접속이 많은 경우 서버의 성능에 영향을 미친다. FTP 로그는 그렇게 많은 양의 데이터는 일반적으로 기록되지 않지만 FTP 홈폴더가 해킹을 당했다면 믿을 건 로그밖에 없다. 어디서 접속했는지 로그에 접속자 IP가 기록되기 때문이다. 실제로 경찰청 사이버 수사대라며 XXXX년 XX월 XX일의 FTP 로그를 달라는 요청을 받은 적이 있다. 해당 파일을 삭제하거나 첨부한 경우가 로그에 기록되고 그 IP를 바탕으로 행적을 추적하려는 것이다. 로그 기록은 평상시에는 쓸데없는 일일지 모르고 성능에 영향을 미치지만 기록해 두면 지난 일에 대한 히스토리를 기록하는 것과 마찬가지이기 떄문에 안 좋은 일이 생기면 유용하게 사용할 수 있다.

Part 4. 웹 서비스와 SMTP 서비스 설정 방법

 

IIS는 웹 서비스 뿐만 아니라 FTP 서비스, SMTP 서비스, NNTP 서비스 등을 한 서버에서 지원한다. 지난 시간에는 IIS가 지원하는 서비스인 FTP 서비스를 설정하는 방법에 대해 살펴봤다. 이번 강좌는 IIS에서 웹 서비스와 SMTP 서비스를 설정하기 위한 메뉴의 기능에 대해 자세히 알아본다.

IIS(Internet Infomation Server)는 인터넷 서비스와 관련된 웹 서비스, FTP 서비스, SMTP(Simple Mail Transport Protocol) 서비스, NNTP(Network News Transfer Protocol), 서버익스텐션 등이 한 서버에서 동작할 수 있도록 지원한다. 윈도우 2000의 IIS를 이용해 FTP, 웹, SMTP를 가장 많이 활용하고 있다. 지난 시간에 이어 이번 강좌에서는 웹, SMTP 설정 방법을 알아본다.

 

웹 등록정보와 설정

마스터에서 웹 서비스의 등록정보를 열면 (화면 1)을 볼 수 있다. 이 등록정보 사항은 새롭게 웹사이트를 만들면 해당 웹사이트에 대한 등록정보와 거의 동일하다. 마스터 속성에 대해 간단히 설명하기 전에 IIS 5.0에서 보다 좋아진 기능에 대해 알아본다.

(화면 1) 웹 서비스 마스터 속성

마스터에서 팝업으로 메뉴를 띄우면 여러가지 메뉴가 있는데, 그 중에 주목할만한 메뉴가 '구성 백업/복원'과 'IIS 다시 시작'이다. 구성 백업/복원 메뉴는 많은 웹 사이트를 재설치하는 경우나 호스트를 교체해야 하는 경우에 활용한다. 기존 IIS 4.0에서는 레지스트리에 많은 정보가 담겨 있었으나, 5.0에서는 메타베이스라는 것에 IIS에 대한 정보가 담겨있다. 이것을 이용하면 사고가 발생해도 신속하고 편안하게 복구할 수 있다. 백업을 하면 기본적으로 SYSTEM32INETSRVMETABACK이란 폴더에 저장되고, 복원하려면 IIS를 올리고 이 파일을 이용해 복원하면 된다.

기존 4.0을 사용한 사용자라면, IIS에 문제가 발생했을 때 문제의 원인을 모른다면 대부분 재부팅을 시도한다. 하지만 서버를 재부팅하려면 시간도 오래 걸리고 IIS 서비스만 국한된 것이 아니고 다른 서비스에도 영향을 미친다. 이럴 때 대비해 5.0에서는 IIS만을 재부팅하는 효과를 볼 수 있는 명령어가 있다. 이때 사용되는 메뉴가 IIS 다시 시작이다. 메뉴에서뿐만 아니라 DOS에서는 IISRESET이라는 명령어를 사용하면 된다.

다른 명령어라면 다른 컴퓨터와 연결됐다면 그 컴퓨터를 연결해서 이 명령어를 수행할 수 있지만, 이것은 IIS에서만 사용할 수 있다. 다음은 IIS에서 사용할 수 있는 다양한 명령어이다.

/RESTART : 모든 인터넷 서비스를 중지한 다음 다시 시작한다. 이것은 IIS만을 재부팅하는 효과가 있다.

/START : 모든 인터넷 서비스를 시작한다. STOP 명령으로 세웠으면 이 명령어로 다시 시작한다.

/STOP : 인터넷 서비스를 중지한다.

/REBOOT : 컴퓨터를 다시 부팅한다. 이 명령어를 사용하면 컴퓨터가 전체적으로 다시 부팅한다. 

/STATUS : 모든 인터넷 서비스의 상태를 표시한다. 웹, FTP, SMTP에 대한 서비스 상태를 나타낸다. 

몇가지 명령어가 더 있으나 이정도만 잘 알아두면 도움이 될 것이다. 이제 각 구성 요소에 대해 간단히 알아본다. 자세한 내용은 해당 관련 서적이나 마이크로소프트 사이트를 통해 익히기를 바란다.

ㆍ웹 사이트 확인 
마스터에 있는 '웹 사이트 확인'은 해당 웹 사이트에 대한 설명으로 구성된다. 여러 개의 웹 사이트를 만들다 보면 관리자 역시 헷갈리는 경우가 있다. 특히 초보자들이 그런 경험을 많이 하게 되는데,  이럴 때 설명(description)과 네이밍(naming)을 제대로 해놓으면 도움이 된다. 폴더를 하나 만들어도 급하다고 아무렇게나 만들지 말고, 다시 한번 생각해서 누가 봐도 구분할 수 있는 이름으로 만들어야 한다.

마스터에서는 설명 부분만 나타나지만 웹 사이트를 개설하면 IP 어드레스와 TCP 포트, SSL 포트가 활성화돼 값을 입력할 수 있다. 설명란에는 웹 사이트에 대해 구분할 수 있도록 적으면 되고, 이 설명이 어떤 설정에 영향을 주는 것은 아니다.

IP 어드레스 란에는 모두 할당되지 않음과 네트워크 어댑터에 등록된 모든 IP 값이 나온다. 여러 개의 웹사이트가 있을 경우, 예를 들어 A.COM/ B.COM/ C.COM이 있고, 세 개의 IP를 가지고 있다면 각각의 사이트가 다른 IP를 사용할 수 있다. 이렇게 하는 이유는 A, B, C 사이트 모두가 접속자가 많아서 하나의 IP로 감당하지 못하면, 여러 IP로 나눠 분산시켜야 하기 때문이다.

그렇지 않고 A, B, C를 모두 한 IP로 운영한다면 고급 메뉴에서 호스트 헤더를 이용해야 한다. 모두 같은 IP에서 웹 접속을 요청할 때 IIS가 어느 사이트로 보내야 할지 모를 때, 고급 메뉴의 호스트 헤더는 이를 구분하는 역할을 한다.

·연결
연결 메뉴는 접속자 수를 설정하는 역할을 한다. 접속자 수 뿐만 아니라 연결 제한 시간도 설정할 수 있다. 로깅 사용은 FTP에서 설명한 것과 마찬가지로 로그를 데이터 파티션이나 시스템 파티션으로 설정하지 말고 다른 파티션으로 설정하는 것을 권장한다.

·운영자
운영자 메뉴에서는 기본적으로 어드민(administrators)의 구성원이 운영자가 된다. 다른 일반 사용자가 IIS에 접근하는 것을 차단하도록 설정된다. 어드민의 구성원 말고 다른 그룹의 구성원에게 IIS의 관리를 맡기려면 운영자 메뉴에서 추가할 수 있다. 추가를 눌러 액티브 디렉토리의 구성원을 추가하거나 로컬의 구성원을 IIS의 관리자로 설정할 수 있다.

ㆍ성능
성능 메뉴는 웹에 대한 성능을 조정하는 것이다. 예상되는 방문자 수를 체크해 그에 적합하게 IIS의 성능을 조정하면 된다. 하지만 기본값을 그대로 두는 것을 권장한다. 대역폭도 조절할 수 있지만, 네트워크가 허용하는 최대의 대역폭을 사용할 수 있도록 기본값으로 그대로 두는 것을 권장한다. CPU 사용량을 설정하는 메뉴도 있지만, 언제 어느때 CPU 사용량이 얼마가 될지는 아무도 모르기 때문에 이것도 권장값을 그대로 둘 것을 권한다.

ㆍISAPI 필터
ISAPI 필터는 HTTP 요청을 처리하는 동안 서버에서 발생하는 이벤트에 응답하는 프로그램이다. 이 부분은 프로그램 성격이 강하므로 여기서는 간단하게 정의만 알아두자.  

·홈 디렉토리
홈 디렉토리 메뉴를 클릭하면 '이 리소스에 연결하면 다음에서 컨텐츠를 가져옵니다'라는 메시지가 뜬다(화면 2). 이는 웹 사이트의 내용이 어디에 있는가를 지정하는 것이다. 세 가지 경우가 있는데,

첫번째는 이 컴퓨터에 있는 디렉토리이다. 이렇게 지정하면 해당 호스트에 컨텐츠가 있는 것이다. 따라서 로컬 경로를 통해 해당 디렉토리를 지정하면 된다.

두번째는 다른 컴퓨터에 있는 공유 디렉토리라는 것인데, 이 부분은 네트워크를 통해서 다른 서버에 있는 컨텐츠의 내용을 액세스할 때 사용한다. 두 서버간에는 폴더를 공유할 수 있는 구성이 미리 준비가 돼 있어야 한다.
세번째는 URL로 리디렉션이라는 것인데 리다이렉트한다는 뜻이다. 단적인 예를 들면 A.COM으로 들어오는 접속을 B.COM으로 전환하고 싶을 때 이 메뉴를 설정하면 된다. 구성은 우선 자신의 호스트에 A.COM을 새로 개설한다. 데이터 내용은 없어도 된다. 이 웹 사이트는 리디렉션을 하는 것이 목적이기 때문에 해당 사이트의 등록 정보를 열어서 홈 디렉토리의 URL로 리디렉션을 체크하면 바로 (화면 2)와 같은 '다음으로 리디렉션'을 입력하는 창이 나온다. 체크해야 하는 값이 세 개가 나타나는데 그렇게 어렵지 않은 내용이므로 쉽게 이해할 수 있을 것이다.

(화면 2) 홈 디렉토리에서 기본 웹사이트 등록정보

로컬 경로 메뉴에서 컨텐츠의 경로를 설정하고, 그 컨텐츠에 대한 IIS에서의 권한이나 방문 기록 등을 체크할 수 있다. 쉽게 이해할 수 있는 내용이다. 한가지 강조하고 싶은 것은 쓰기 권한이다. 쓰기라는 것은 실행할 수 있는 권한이다. 필자는 예전에는 CGI를 IIS와 연동해서 사용했다. 그러나 CGI는 IIS와 궁합이 맞지 않는다. 그것은 CGI에 대해서는 쓰기 권한을 주어야 동작하기 때문이다. 악의적인 해커들이 CGI용 스크립트를 서버에 올려놓고 실행하면 그들의 의도대로 서버는 실행된다. 보안에 취약한 부분은 아예 사용하지 않는 것이 좋다. 또다른 경우는 보통 웹사이트는 파일을 업로드해야 하는 경우가 많다. 자료실이 대표적인 경우다. 이 자료실을 운영하려면 해당 컨텐츠가 저장된 폴더에 IUSR_호스트 네임이라는 인터넷 액세스 계정에 쓰기 권한이 있어야 하고 아울러 해당 웹사이트에도 쓰기 권한을 주어야 한다. 역시 쓰기 권한이 많으면 보안에 취약한 부분이 드러나므로 가급적이면 쓰기 권한을 적게 운영할 것을 권장한다.

애플리케이션 설정에서는 기본 애플리케이션 기본값으로 그대로 두고 실행 권한은 스크립트 그리고 애플리케이션 보호는 보통(풀링됨)으로 설정돼 있다. 여기서 애플리케이션이라는 것은 ASP를 동작할 수 있도록 하는 것이다. 어떤 사용자가 웹에 접속했는데 그 사이트는 ASP로 만들어져 있다. 접속했다고 바로 그 페이지를 접속한 사용자에게 보여주는 것이 아니다. ASP는 한번 컴파일돼야 하기 때문이다. 메모리에서 컴파일이 되고 난 후 이것이 접속한 사용자에게 전달된다. 여기서 말하는 애플리케이션은 ASP로 보아도 된다. 만일 CGI가 있다면 CGI가 기본 애플리케이션이 될 수 있다.

실행 권한이라는 것은 ASP를 실행하는 권한을 말한다. 이에 대한 구성은 실행 권한 옆의 구성 버튼을 눌러 보면 정의가 나온다. ASP의 접속 요청이 되면 C:WINNTSystem32inetsrvasp.dll의 DLL이 호출돼 동작하게 된다. 이 호출된 DLL은 메모리에서 상주하면서 동작한다. 메모리에 상주하면서 동작하는 프로세스의 이름은 DLLHOST.EXE다. 처음 서버를 만들고 웹사이트를 개설하면 이 DLLHOST.EXE라는 프로세스가 잘 보이지 않는다. 왜냐하면 실행되지 않았기 때문이다. 접속자가 접속하면 이 프로세스가 두 개 생기게 된다. 하나는 시스템 용이고 다른 하나는 웹 사이트 용이라면 보다 쉽게 이해가 될 것이다.

IIS 5.0에서는 ASP 애플리케이션에 대한 메모리 관리식의 메모리 할당 방법을 제공하는데, 바로 이것이 애플리케이션 보호다. 이미 언급했듯이 DLLHOSTE.EXE라는 프로세스에서 ASP.DLL이 모두 처리되는데 여러 개의 웹 사이트가 있다고 가정해보자. 보통(풀링됨)으로 설정돼 있다면 하나는 시스템이 사용하는 것이고 또하나는 각각의 웹 사이트가 ASP.DLL을 처리하기 위해서 사용하는 것이다. 일반적으로 이와 같이 사용하는 것을 권장한다. 낮음(IIS프로세스)은 메모리 할당 공간을 한군데만 잡아서 IIS와 관련된 사항과 ASP.DLL이 같은 곳에서 사용하게 된다. 높음(격리됨)을 선택하면 각각의 웹사이트가 DLLHOST.EXE를 개별적으로 가지고 있고 각 사이트의 ASP.DLL은 할당된 메모리 공간에서 실행된다. 이렇게 하면 서로 간의 사이트가 애플리케이션에 대한 간섭을 받지 않기 때문에 한 사이트의 잘못된 ASP 코딩으로 인해 다른 사이트가 다운되는 일은 없지만, 메모리를 많이 차지한다는 단점이 있다.

·기본 문서 사용
문서라는 메뉴에서는 초기 페이지를 설정해야 한다. 내가 만약 INDEX.ASP를 초기 페이지로 설정하고 싶다면 문서 메뉴에 INDEX.ASP를 놓고 홈 폴더에 INDEX.ASP만 있다면 이 파일이 자동적으로 초기 페이지로 설정된다. 여러 개의 초기 페이지를 잡았다면 우선 순위에 의해 초기 페이지가 설정된다.

문서 바닥글 사용은 해당 웹사이트에 대한 웹 페이지의 보통 바닥글을 표시한다. 예를 들어 저작권을 표시하고 싶다면 여기에 저작권이 표시되는 페이지의 경로를 설정하면 웹 사이트의 모든 페이지에서 하단의 자동으로 병합하게 된다.

·디렉토리 보안
이 해당 웹사이트에 보안 부분이다. 보안과 백업은 사고가 발생한 후 사태의 심각성을 인식하는 경우가 많다. 보안은 예전에 1.25 대란이 일어난 이후로 많은 인식의 변화가 있었지만, 그래도 아직은 보안에 대한 인식이 부족하다. 특히, 전문적인 관리자가 없는 중소 기업의 문제는 더욱 심각하다.

디렉토리 보안 메뉴에서는 익명의 액세스가 기본값으로 설정돼 있다. '리소스를 액세스하는데 사용자 이름/암호가 필요가 없습니다'라는 글이 나오는데, 이는 그냥 접속을 신청하면 열어주겠다는 것이다. 액디브 디렉토리 편에서 언급했지만 서버는 인증과 확인 과정을 거쳐 리소스를 신청한 접속자에게 액세스 권한을 준다. 그러나 웹 접속은 이런 과정이 필요치 않다. 엄밀히 말하면 일반적인 형식이 그런 인증과 확인 절차가 필요없다는 것이다. 웹의 성격상 웹 접속은 세계 어느 누구나 접속할 수 있어야 하기 때문이다. 하지만 접속 제한을 둘 수도 있다. 편집을 클릭하고 들어가면 기본적으로 IUSR_HOSTNAME이라는 익명의 액세스 계정이 있다. 웹에 접속하면 누구나 이 계정을 이용해 컨텐츠에 액세스해 컨텐츠를 볼 수 있다.
인증된 액세스 메뉴에서는  기본 인증  도메인 서버의 다이제스트 인증  윈도우 통합 인증으로 구분된다. 기본 인증은 웹 사이트에 액세스하는 사용자를 확인하는 가장 기본적인 인증 방법이다. 인증과 확인 절차를 거치지만 그것이 네트워크를 타고 전송될 때 CLEAR TEXT라고 해서 암호화되지 않고 텍스트 상태 그대로 전송된다. 만일 어느 누가 해당 네트워크에 네트워크 패킷 캡쳐 툴, 예를 들어 윈도우 서버의 네트워크 모니터 또는 스니퍼 프로그램을 심었다면 해당 패킷을 잡아 볼 수 있다는 단점이 있다. 이 방법을 이용하는 이유는 모든 웹 브라우저를 지원할 수 있기 때문이다. 그래서 다양한 플랫폼과 웹 브라우저를 지원하고 인증을 거쳐야 한다면 이 방법을 이용하면 된다.

도메인 서버의 다이제스트 인증에서 말하는 도메인은 액티브 디렉토리 도메인이다. 이 방법은 해싱 알고리즘을 사용한다. 해싱 알고리즘은 전자서명으로 생각하면 된다. 이것은 액티브 디렉토리의 사용자에 대한 인증과 같이 이뤄지기 때문에 마이크로소프트의 인터넷 익스플로러 5.0 이상이 필요하다. 인증 방법 중에 가장 안전한 방법이다.

윈도우 통합 인증 역시 해싱 알고리즘을 이용하지만 액티브 디렉토리와는 별개로 사용된다. 윈도우 통합 인증은 일반적으로 단독으로 운영되는 웹 서버에서 사용하고, 또한 클라이언트의 웹 브라우저 버전이 익스플로러 2 이상이면 가능하다.

보안성으로 보면, 도메인 서버의 다이제스트 인증 윈도우 통합 인증 기본 인증 순이다. 이와 관련해 특수한 상황, 예를 들어 회사 내에서만 서버에 접속할 수 있게 한다든지, 아니면 특정 부서만이 웹에 접속할 수 있게 하려는 경우가 있을 것이다. 세부적인 사항에 따라 다르겠지만 일반적으로 인증된 액세스를 이용해 ID와 패스워드를 입력하게 해서 웹에 접속하면 된다. 그러나 이 자료는 너무 중요해 회사에서만 볼 수 있도록 설정하려면 IP 어드레스와 도메인 이름 제한 메뉴를 이용한다. IP로 접속을 제한하지 않고 ID와 패스워드를 알고 있다면 어디서나 접속할 수 있기 때문이다.

IP 어드레스와 도메인 이름 제한의 편집을 클릭하면 추가로 들어가면 단일 컴퓨터, 컴퓨터 그룹, 도메인 이름으로 접속을 제한할 수 있다. 단일 컴퓨터라면 쉽게 한 IP만에 접속하는 것을 거부하겠다는 설정을 하면 된다. 컴퓨터 그룹은 한 네트워크 대역에 대해 전부 거부한다. 도메인 이름은 해당 도메인에 대해 접속을 거부하는 것이다.

기본값으로 액세스 허가가 설정돼 있고 다음 설정 사항은 없다. 하지만 거부하겠다고 해서 액세스 거부를 설정하면 그 설정한 사람만 접속을 허용하는 경우다. 현재 모든 컴퓨터에 대해 액세스를 허가하기 때문에 추가를 실행해 거부할 IP나 네트워크 대역을 입력하면 된다. 보안 통신은 인증서를 생성해 웹에 접속할 때 기본적으로 이 인증서를 이용한다.

·HTTP 헤더
HTTP 헤더 메뉴에는 IIS 서비스가 전송하는 HTTP 페이지 헤더가 있다. 여기서 관리자가 제어해야 할 것은 컨텐츠 만료일, 컨텐츠 등급, MIME 타입이다. 컨텐츠 만료일은 현재 사이트에 대한 컨텐츠에 만료일을 설정한 것으로, 유료 웹사이트에 적용하면 유용하게 사용할 수 있다. 

사용자 정의 HTTP 헤더는 기본적으로 정의된 헤더값 이외에 추가하고 싶은 헤더값을 따로 사용한다. 컨텐츠 등급은 성인물이나 폭력성이 강한 부분을 체크하는데, 그렇게 많이 활용되는 것 같지는 않다. 그냥 기본적으로 이런 것이 있다 정도만 알아두어도 무방하다.

MIME 매핑은 설정하기 보다는 개념을 알아두면 쉽게 이해할 수 있다. MIME는 서버가 어떤 웹 전송이라도 시작 부분에 MIME 헤더를 집어넣으며, 클라이언트는 헤더가 나타내는 데이터 형식에 따라 이를 재생하기 위한 적절한 애플리케이션을 선택한다. 이같은 재생용 프로그램 중 일부는 웹 클라이언트, 즉 브라우저에 기본적으로 탑재되며, 그 외의 프로그램은 필요할 때마다 다운로드한다.

최근에는 웬만한 애플리케이션이 다 포함돼 있기 때문에 그렇게 추가하지 않아도 되지만, 특별한 애플리케이션을 위해서는 여기에서 추가해야 한다.

·사용자 정의 오류
사용자 정의 오류 메뉴는 사용자가 웹에 접속할 때 접속되지 않는 사항에 대해 에러 메세지를 브라우저에 보내주는 것이다. 기본적으로 탑재된 에러 메시지는 C:\WINNT\help\iisHelp\common에 있으며, 만일 자기만의 특별한 에러가 있다면 해당 디렉토리에서 HTM 파일을 만들어서 설정해 놓으면 된다.

에러 메세지를 보면 번호가 있는데, 이 번호를 알아두면 웹 접속 로그라든지 기타 IIS와 관련된 로그를 볼 때 이해가 쉬워진다. 기본적으로 200번 대의 메시지는 접속에 성공한 부류이고 300번 대의 메시지는 리다이렉션에 대한 것이다. 그리고 400번 대와 500번 대는 에러에 대한 메시지를 나타낸다. 보다 자세한 사항은 RFC2616 문서를 참고하면 보다 명확하게 해답을 얻을 수 있다.

지금까지 웹 서비스에 대한 설정 사항에 대해 알아봤다. IIS의 핵심 사항인 웹이기에 설명이 조금 길어졌고 조금 깊게 들어간 부분도 있다.

 

SMTP 등록정보와 설정

SMTP(Simple Mail Transfer Protocol)가 전자우편을 보내는 기능만 하는 것으로 아는 사람들이 많다. SMTP는 보내고 받기를 다 할 수 있다. 그럼 전자우편을 받을때는 POP3라는 프로토콜을 사용하는데, SMTP는 전자우편을 보내고 받기를 다 지원하는데 왜 POP3라는 것이 필요한지 궁금할 것이다. SMTP는 서버 대 서버간 또는 서버 대 클라이언트에서 전자우편을 보내고 받을 때 사용되는 프로토콜이다. 클라이언트가 서버에서 전자우편을 받을때에는 POP3라는 것이 필요하다. 가장 이해가 쉬운 설명이 우체국이다.

내가 우체국(서버)까지 직접 가서 편지를 보낸다. 이는 내 컴퓨터에서 보내는 메일 서버가 지정돼 있기 때문에 보내는 메일 서버까지 찾아가는 과정이다. 그러나 보내는 메일 서버가 어떻게 주소를 알고 도착지 우체국(SMTP 서버)로 보낼까. 편지 봉투에는 주소가 있다. 이것을 보고 보낼 것이다. 인터넷으로 말한다면 DNS의 MX[Mail eXchage]라는 것을 보고 도착해야 할 우체국이 어디구나 하고 판가름한다. DNS라는 것이 있고 이것에 대한 설정 파일이 있는데, 그 파일 안을 보면 MX라고 하는 전자우편이 전달되는 서버가 명시돼 있다. 이걸 보고 보내는 메일 서버는 도착지 SMTP 서버로 우편을 보낸다. 이렇게 해서 우편이 제대로 도착되면 집배원 아저씨(POP3)가 배달한다. 집배원 아저씨가 우편을 배달하는 구간이 POP3 구간이라고 보면 된다. 역시 마찬가지로 집배원 아저씨도 여러분의 주소를 보고 여러분의 집에 있는 사서함(여러분의 메일 클라이언트 프로그램)에 편지를 배달해 놓는다. 이와 같은 원리를 이해한다면 전자우편이 전달되는 과정을 파악할 수 있을 것이다.

SMTP의 설정 사항은 마스터에 포함돼 있지 않다. 웹나 FTP와 마찬가지로 (화면 3)과 같은 설정 메뉴가 있다.

(화면 3)SMTP 가상 서버 등록정보

·일반
일반 메뉴에서는 SMTP 사이트에 대한 설명을 넣을 수 있고 IP를 할당할 수 있다. IP 할당을 하는 부분은 웹의 IP 할당에서 설명한 것과 동일하다.

고급을 클릭해 들어가면 IP 어드레스에 포트를 할당할 수 있다. 여러가지 상황에 맞춰 포트가 충돌되지 않게 TCP 25번 포트가 아닌 다른 IP 포트를 할당해 사용할 수 있다. 포트를 사용할 때는 먼저 열린 포트를 점검하고 사용하지 않는 포트를 할당해야 할 것이다. 만일 포트가 충돌되면 IIS에 모든 서비스는 사용 중이라는 메시지가 나올 것이다.

연결 부분을 보면 연결 수를 다음으로 제한한다는 내용이 나온다. SMTP 사용량에 대한 제한을 설정하는 것이다. 수신과 송신으로 나눠져 있는데, 수신은 기본적으로 비활성화돼 있다. 수신해야 하는 경우는 이 부분을 체크하고 설정하면 된다. 송신 부분에서는 10분에 1000건으로 제한돼 있다. 10분 동안 1000통의 전자우편을 발송할 수 없다는 내용이다. 그리고 도메인당 100개로 돼 있는데 기본 SMTP를 클릭하면 오른쪽 창에 도메인과 현재 세션이라는 것이 나타난다. 여기서 말하는 도메인은  설정돼 있는 도메인을 말한다. 도메인을 따로 설정한 것이 없다면 해당 서버는 한번 발송시 100개로 제한돼 있다.

실제로 운영하다 보면 이 전자우편 때문에 머리가 아픈 적이 한두번이 아니다. 운영되는 사이트에서 무작위로 전자우편을 발송하지 않는지, 릴레이가 걸려서 고생하지는 않는지 말이다. 우선, 운영되는 사이트가 무작위 전자우편을 발송하는 것은 SMTP 로그를 설정해 로그를 분석해야 한다. 로깅 사용에 대한 부분도 FTP와 웹과 동일하다. 모든 것을 체크하고 로그를 다른 파티션으로 잡을 것을 권장한다.

·액세스
액세스 제어 부분은 웹에서 말했던 세 가지 인증 방식과 거의 동일하다. 그러나 마지막의 윈도우 보안 패키지는 윈도우 서버와 클라이언트가 윈도우 제품군으로 이뤄져야 하고, 클라이언트가 가지고 있는 ID와 패스워드는 요청되는 서버의 사용자 계정으로 등록돼 있어야 한다.
보안 통신 부분은 인증서와 암호로 구성돼 있다. 외부 인증서를 사용할 수 있고 액티브 디렉토리에 있는 CA 서비스를 이용해 인증서를 사용할 수 있다. 많은 내용이 필요하기 때문에 간단하게 개념만 체크해보자. 연결 제어는 인증이 아니라 IP 어드레스나 도메인 이름을 통해서 SMTP 서버에 액세스하는 사용자를 제어하는 부분이다. 여기에서 허용하는 IP나 도메인만이 해당 서버와 연결돼 전자우편을 전송할 수 있다. 기본값은 모든 연결을 허용하지 않는 것이다. 설정 원리는 웹의 액세스 제한 부분과 마찬가지다.

SMTP는 전자우편을 주고 받는 것이라고 이미 설명했다. 그런데 이렇게 전자우편을 전송(릴레이)하는데 있어서 SMTP는 구분하지 않고 마냥 전송하는 것을 원칙으로 한다. 그래서 IIS에서는 이같은 릴레이 제한을 두려고 했다. 여기서 IP 어드레스와 도메인으로 설정할 수 있으며 해당 서버에서 테스트를 할 수 있다. 테스트는 www.mail-abuse.com/nominats.html에서 할 수 있다.

·메시지
메시지 메뉴는 보내려는 메시지를 설정하는 것이다. 읽어 보면 어렵지 않게 이해할 수 있다. 다만 여기서 주목할 만한 것은 SMTP에 관련된 폴더는 설치시에 C:\INETPUB\MAILROOT라는 폴더로 지정된다. 각 전자우편의 특성에 맞게 해당 폴더로 메시지가 떨어지는데, 이 메시지가 많아지고 전자우편을 지우지 않으면 서버가 먹통이 되는 경우도 있다. 심지어 메시지 수가 너무 많아 윈도우 탐색기로 지우지 못하는 경우도 있다.

그리고 C:\ 파티션이 시스템에 전자우편이 쌓이는 것도 디스크 성능에 막대한 영향을 주게 된다. 이런 이유로 MAILROOT에 관련된 폴더를 시스템이나 데이터와 관련이 없는 파티션으로 이동하면 서버의 성능을 한층 더 높일 수 있다. 문제는 이 SMTP는 지우고 옮긴다고 해서 옮겨지는 것이 아니다. 재부팅하면 기본값인 INETPUB\MAILROOT가 다시 만들어지고 그쪽으로 전자우편이 떨어진다. IIS에 대해 설명할 때 언급했지만 IIS는 메타베이스와 연동돼 동작한다고 했다. 그래서 METAEDITOR를 서버에 설치하고 SMTP에 대한 사항을 수정하면 C:\가 아닌 F:\나 G:\에 MAILROOT를 놓을 수 있다. 방법은 우선 마이크로소프트 다운로드 사이트에서 METAEDIT라고 검색하는데, 버전은 2.2다. 그리고 해당 프로그램을 해당 서버에 설치한다. 그리고 다음과 같은 방법으로 처리를 한다. 참고로 없는 것은 애써 찾으려 하지 말고 그냥 넘어가도 된다.

configure the SMTP service to use the new root directory, you must change the path information in the metabase. To manually make the changes necessary to the metabase, use MetaEdit from the IIS Resource Kit or programmatically use ADSI APIs. To do this, perform the following steps:
 
1. Edit the metabase and open LM/SMTPSVC.
2. Edit ID 36930 to reference the new SortTemp directory.
3. Open LM/SMTPSVC/1/QueueDirectory and edit the string to reference the new
  folder.
4. Open LM/SMTPSVC/1/PickupDirectory and edit the string to reference the new
  folder.
5. Open LM/SMTPSVC/1/DropDirectory and edit the string to reference the new
  folder
6. Open LM/SMTPSVC/1/BadMailDirectory and edit the string to reference the new
  folder.
7. From the command prompt or services, stop the IIS Admin Service using the
  following command:
 
   net stop IISADMIN
 
8. For the changes to take effect, restart the Web Publishing Service using the
  following command:

  net start W3SVC

REFERENCES
For additional information on the metabase and the utilities used for modifying the metabase, click the article numbers below to view the articles in the Microsoft Knowledge Base:
Q240941 An Introduction to the IIS Metabase
Q240225 Description of Adsutil and MetaEdit Used to Modify the Metabase

·배달
전자우편을 배달하는 조건이 있다. 이는 아웃바운드에 해당된다. 인바운드로 들어오는 것은 상관없다. 설정 사항을 찬찬히 살펴보면 어려움없이 이해할 수 있을 것이다. 크게 어려운 부분이 없어 개념만 잡고 넘어간다.

·LDAP 라우팅
LDAP에 대해서는 액티브 디렉토리에 대해서 간단하게 설명했다. 액티브 디렉토리를 사용하고 이 LDAP을 이용해서 전자우편을 전달한다. 이 부분은 익스체인지와도 연동된다.

 

·보안
이 부분은 관리자 설정 부분이다. 웹에서 설명한 것과 동일하므로 생략한다. 

이렇게 해서 IIS의 웹과 SMTP 서비스에 대한 구성 정보와 개념을 살펴봤다. IIS는 뛰어난 성능을 자랑한다. 실제로 여러가지 서버의 부하 상황을 유연하게 대처하고 있다. 마이크로소프트는 이제 2003의 IIS 6.0은 한층 더 업그레이드를 해서 영원히 죽지 않는 사이트를 만들었다고 말한다. 약간의 과장이 됐다고 해도, 각각의 사이트에서 과부하에 대한 기준을 설정해 그 기준을 넘으면 자동으로 해당 사이트만을 재시작하는 구성을 갖춰 관리자들이 서버 관리를 수월하게 할 수 있도록 돕는다.

 

Part 5. 마이크로소프트 SQL 서버의 역사

 

인터넷이 발달하기 전까지만 해도 마이크로소프트는 자그마한 소프트웨어 회사에 불과했다. 하지만 마이크로소프트는 여러 업체들과 협력 관계를 맺으면서 기술을 습득해 현재의 거대 소프트웨어 업체로 발전했다. 마이크로소프트 SQL 서버 역시 애슈턴 테이트와 사이베이스의 기술을 기반으로 만들어져 현재는 엔터프라이즈 환경까지도 널리 활용되고 있다. 이번 강좌는 SQL 서버가 어떻게 개발, 발전하게 됐는지 알아본다.

필자가 학교 다닐 때 코볼이라는 프로그램 언어와 사이베이스라는 데이터베이스를 배웠던 기억이 난다. 당시에는 코볼이 대세였고, 은행권의 인터페이스 및 데이터베이스로 연결을 할 때 코볼로 만들어졌다. 혹 기억할지 모르지만 예전에는 은행 창구에 서서 은행원들의 모니터를 보면 텍스트만 볼 수 있었다. 이렇게 입력한 데이터가 그 은행이 사용하는 데이터베이스에 입력되고 사용자는 통장에서 확인할 수 있는 시스템이다. 이렇게 운영되던 것이 4GL(Fourth-Generation Language)인 파워빌더, 델파이, 비주얼 베이직, 비주얼 C로 발전했다. 이같은 프로그램 언어는 인터넷이 급격히 발전하면서 웹 방식으로 전환됐다.

 

프로그램 언어가 발전하는 동안 마이크로소프트 SQL 서버도 같이 발전했다. 사실 필자가 대학생일 당시에는 마이크로소프트 SQL 서버가 무엇인지 몰랐고 인터페이스 조차도 구경하지 못했다. 서버에 관심을 두게 됐을 때 마이크로소프트 SQL 서버라는 것을 들었다.

 

많은 분들이 마이크로소프트 SQL 서버의 역사에 대해 모르는 경향이 있어, 이번 강좌는 먼저 마이크로소프트 SQL 서버가 어떻게 생겨났고 발전했는지 알아보는 시간을 가질 예정이다. 사실 SQL의 역사를 몰라도 마이크로소프트 SQL 서버 제품을 다루는 데 큰 지장은 없다. 필자 역시 서버 제품의 설치 매뉴얼을 보고 설치부터 시작했으니까. 그러나 진정한 DB 전문가로 발전하고 싶거나 SQL 프로그램을 할 계획이라면 마이크로소프트 SQL 서버의 역사를 알고 있어야 한다. 이 말은 마이크로소프트 SQL 서버의 데이터베이스 엔진의 모태가 사이베이스라는 결론이 난다. 마이크로소프트 SQL 서버는 윈도우 서버에서 동작하는 것이기 때문에 마이크로소프트 SQL 서버의 역사를 이야기할 때 윈도우 서버의 역사도 함께 소개되고 있다.

 

 

마이크로소프트, 다양한 업체와 협력해 기술 습득 

1986년 마이크로소프트는 1153명의 직원과 연매출 1억 9700만 달러의 기업에 불과했다. 이 당시 마이크로소프트는 데스크톱 중심인 MS-DOS에 주력했는데, 이는 오늘날의 주환경인 서버/클라이언트 환경에는 관심을 두지 않았다는 것이다. 아울러 이때 마이크로소프트는 자체적으로 제품을 개발하는 것보다 타사와의 협력으로 시장을 개척해 나갔다. 애슈턴 테이트(Ashton-Tate)나 사이베이스와의 관계가 대표적이라고 할 수 있겠다.

마이크로소프트는 DBMS의 필요성을 느끼기 시작했고 자체적으로 개발하는 여력이 안돼 타사의 제품을 찾고 있었다. 그러던 중 사이베이스의 DataServer 제품에 관심을 가졌다. 이 제품은 저장 프로시저, 트리거(현재 마이크로소프트 SQL에서도 구현 가능한 기능) 등의 새로운 기능을 탑재하면서 서버/클라이언트 환경에 맞게 설계됐고 평가도 좋았다. 마이크로소프트는 사이베이스와 협력을 맺고 로열티를 지불하면서 데이터베이스 엔진을 활용하고 사이베이스가 제품 제작까지 맡았다. 뿐만 아니라 데스크톱 버전에서 명성을 얻고 있었던 애슈턴 테이트의 dBASE를 활용하기 위해 협력을 맺었다. 그 결과로 1989년 5월에 애슈턴 테이트/마이크로소프트 SQL 서버 1.0이 출시됐다. 이 협력으로 마이크로소프트는 제품을 보다 확장할 수 있는 계기를 가졌다. 제품 판매는 마이크로소프트와 애슈턴 테이트가 맡고 제품 생산은 사이베이스가 맡았다.

마이크로소프트는 애슈턴 테이트의 Dbase 사용자 그룹과 연결할 목적으로 협약을 맺었으나, 애슈턴 테이트의 Dbase Ⅳ는 발표도 늦었고 버그도 발견되는 등 여러 문제가 발생했다. 이같은 이유로 협력은 파기됐고 마이크로소프트는 독자적으로 SQL 서버를 만들려는 시도를 했다. 이는 독자적으로 만들려고 했다기 보다는 제품명을 바꾸기 위한 이유가 됐다. 그 결과로 1989년 마이크로소프트 SQL 서버 버전 1.1을 발표했다. 이 제품은 기존 애슈턴 테이트/마이크로소프트 SQL 서버의 업그레이드 제품에 불과했지만, 기존 제품의 버그를 많이 수정했고 컴퓨터 산업의 분수령이 됐던 윈도우 3.0(1990년 5월)을 지원한다는 점을 주목받았다. 윈도우 플랫폼을 완벽하게 지원할 수 있다는 점은 마이크로소프트 SQL 서버가 성공하는 중요한 요인이 되기도 했다.

그럼, 마이크로소프트는 SQL 서버의 원조 엔진이었던 사이베이스와의 관계는 어떻게 될까. 마이크로소프트 SQL 버전 1.1의 SQL 서버 엔진은 사이베이스에 의해 만들어졌다. 따라서 마이크로소프트는 소스 코드에 쉽게 접근하지 못했고 버그가 발견돼도 수정과 변경은 사이베이스에 따로 요청해야했다.

이같은 협력 관계는 좋은 점도 있지만 단점도 있다. 양사의 업무 우선 순위가 달라 협조 체계가 순조롭게 지원되지 않았다는 점이다. 이런 불편함 속에서 1991년 초 마이크로소프트는 고객 지원을 목적으로 소스 코드를 볼 수 있게 됐고, 이것은 마이크로소프트에게는 많은 도움이 됐다. 비록 수정은 할 수 없었지만 어디에 어떤 오류가 발생했는지를 마이크로소프트의 SQL 서버 개발자 그룹이 파악할 수 있었기 때문이다. 1991년 중반부터 마이크로소프트는 버그를 수정할 수 있게 됐지만, 직접 버그를 수정하는 방식이 아니고 잘못된 부분을 사이베이스에 전달해 수정하는 방식으로 이뤄졌다. 이렇게 제품에 대한 신뢰성을 쌓으면서 개발자 그룹은 SQL 서버에 대해 전문가가 됐다.

 

 

사이베이스와 경쟁 관계 돌입

 

윈도우 3.0이 발표되면서 사용자들은 자연스럽게 마이크로소프트 DOS에서 윈도우 3.0으로 이동했다. 이제 마이크로소프트는 윈도우 차기 버전과 윈도우용 애플리케이션 개발에 혼신의 힘을 모으기로 했다. 새로운 마이크로 커널 기반의 운영체제를 제대로 개발했는데, 이것이 NT(New Technology)다. NT는 코드명인데, 이 코드명을 그대로 제품명에 결합했고 그 정식 이름은 마이크로소프트 윈도우 NT가 된 것이다.

 

1991년 가을 마이크로소프트 SQL 서버 버전 4.2의 베타 테스트에 들어갔으며 1992년 1월에 공식적으로 제품을 발표했다. 이 제품은 마이크로소프트가 독자적으로 개발한 것은 아니다. 여전히 데이터베이스 엔진은 사이베이스를 이용했고 제품 개발 역시 마이크로소프트와 사이베이스가 협력해 개발한 것이다. 또한 마이크로소프트 SQL 서버 버전 4.2는 마이크로소프트 DOS, 윈도우, OS/2를 위한 클라이언트 인터페이스 라이브러리도 포함됐다. 이같은 형태로 오늘날의 마이크로소프트 SQL의 틀을 형성했고, 4.2를 마지막으로 사이베이스로부터 더 이상 데이터베이스 엔진의 소스 코드를 받지 않아도 되는 상황에 이르렀다. 

 

1993년 윈도우 NT 3.1이 출시됐다. 그리고 30일 이내에 NT용 마이크로소프트 SQL 서버 제품을 공급하기 시작했고, 윈도우 NT에 마이크로소프트 SQL 서버라는 공식을 만들어갔다. 또한 고객의 테스트 뿐만 아니라 공식 TPC(Transaction Processing Council)에서도 유닉스 시스템과 성능을 겨룰만한 결과가 나왔다. 시장의 반응은 좋았고 9개월 내에 마이크로소프트 SQL 서버 사업은 두배 이상으로 증가했다. 이렇게 마이크로소프트가 발전하면서 사이베이스와의 관계는 협력 관계에서 긴장과 경쟁의 관계로 발전하게 된 것이다.

 

DBMS 시장에서는 오라클과 경쟁했다. 1987년 마이크로소프트와 사이베이스의 협약 관계에 의하면 마이크로소프트는 제품의 권리만을 행사할 수 있었다. 제품의 수정이나 추가적인 기능은 독자적으로 할 수 없었고 사이베이스를 통해서만 할 수 있었다. 그러나 이미 언급한 것처럼 양사의 업무 쟁점이 다르기 때문에 마이크로소프트로서는 그렇게 좋은 관계가 되지 못했다. 또한 사이베이스와의 관계 변화와 경제적인 이유로 더 이상 협력 관계는 지속되지 못했다. 이렇게 양사의 협력 관계가 깨지면서 마이크로소프트는 유닉스, 노벨, 사이베이스와 경쟁 관계가 됐다. 이같은 경쟁 관계가 돼 마이크로소프트는 사이베이스가 보유한 시장 점유율을 잠식해 갔다. 양사는 1994년 12월에 완전 결별을 선언했는데, 이때 사이베이스는 SYSTEM10 버전이었다.

 

 

SQL 서버 6.5 버전 독자 개발 완성

 

이제 마이크로소프트는 독자적인 데이터베이스 제품이 필요하게 됐다. SQL95라는 이름으로 1995년 말까지 데이터베이스를 발표할 계획을 세웠지만, 많은 사람들이 제품 발표 시기에 대해 회의적이었고 혹자는 SQL97이나 SQL2000이 될 것이라고 말했다. 1994년 당시 데이터베이스 제품의 주요 쟁점은 복제였다. 신제품인 SQL95는 복제에 초점을 맞춰서 개발이 되었고, 또한 스크롤할 수 있는 커서도 쟁점이 되었기 때문에 스크롤 가능한 커서의 구현이 필요하다고 생각을 했다.

 

1994년 10월 베타테스트 버전이 발표됐으며 베타 테스트 사이트가 2000여 개가 넘어섰다. 마침내 1995년 6월 14일 마이크로소프트는 SQL 서버 6.0(SQL95)이 정식으로 발표됐다. 시장의 반응은 상당히 좋았지만 오라클, 사이베이스, 인포믹스 등의 시장 점유율과 비교해 본다면 아직은 만족할 만한 성과는 아니었다. 개발팀은 다시 마이크로소프트 SQL 서버 6.5를 개발하기 시작했다. 마이크로소프트 SQL 서버 6.0에서의 미비한 부분과 특히 1995년 인터넷과 데이터 웨어하우징의 중요성이 크게 대두됐기 때문에 이 부분에 초점을 맞췄고 더 사용하기 쉽도록 개선하며 ANSI SQL 표준을 따르도록 했으며 훨씬 더 많은 분산 트랜잭션을 제공했다. 마이크로소프트 SQL 서버 6.0이 발표된 1995년 12월에 마이크로소프트 SQL 서버 6.5 베타 버전이 출시됐다. 그리고 다음해인 1996년 4월에 정식 버전으로 마이크로소프트 SQL 서버 6.5가 출시됐다.

 

사실 마이크로소프트는 독자적으로 개발했다고는 하지만 데이터베이스 엔진에 대한 소스 코드는 사이베이스 것을 많이 모방했다. 이런 이유로 한쪽에서는 마이크로소프트 SQL 서버 6.0과 6.5를 개발하는데 노력하면서 다른 한쪽으로는 완전한 독자 제품을 개발하기 위한 연구가 진행되고 있었다. 새로운 SQL 서버(코드명 : 스핑크스)는 기존 데이터베이스 엔진과 다른 전혀 새로운 데이터베이스 엔진(새로운 저장 구조, 데이터 액세스 방법, 잠금 기술, 복구 알고리즘, 트랜잭션 로그 구조, 메모리 구조, 최적화 등) 전체의 구조를 만드는 것을 목표로 했다. 새로운 마이크로소프트 SQL 서버는 두가지 목표가 있었다. 우선 잠금 관리자를 사용해 행 수준의 잠금을 완전하게 하고, 또다른 하나는 분산 이종 쿼리와 임시 쿼리의 효과적인 처리 등을 허용하는 새로운 쿼리 프로세스를 개발하는 것이다.

 

 

SQL 서버 7.0 발표로 업그레이드 지속 

 

1997년 가을에 마이크로소프트 SQL 7.0 베타1이 발표됐다. 마이크로소프트 SQL 서버 6.5 사용자들이 7.0으로의 업그레이드 지원은 필수였다. 1998년 6월에 베타3 버전을 발표했고 고객에게 지원을 아끼지 않았다. 12만 개가 넘는 사이트가 베타3 버전을 다운받았다. 마이크로소프트는 4년의 노력 끝에 1998년 11월 라스베이거스에서 정식 제품 발표회를 가졌다. 제품이 발표될 즈음 십여 개의 사이트는 마이크로소프트 SQL 서버 7.0을 사용하고 있었다. 그리고 같은 해 12월에 마이크로소프트는 빌드 7.00.623.07을 발표했다. 현재 필자가 테스트하고 있는 마이크로소프트 SQL 서버 2000의 빌드는 8.00.760이다.

 

마이크로소프트는 SQL 서버에 대한 개발을 지속적으로 진행했다. SHILOH(현재 주로 사용이 되고 있는 마이크로소프트 SQL 2000이다)는 마이크로소프트 SQL 서버 7.0 이후 버전이 될 것이고, YUKON(마이크로소프트 SQL 서버 2005로 올 하반기 제품 출시를 목표로 하고 있는 64비트 제품)은 차기 SQL 서버의 개정 버전이 될 것이다. 마이크로소프트는 SHILOH의 개발 계획을 버전 업그레이드 형식보다는 수퍼 서비스팩 정도로 추가할 것으로 생각했고 SHILOH의 출시 계획은 7.0 발표 이후 1년으로 계획을 세웠다. 그러나 그 계획은 변경됐다. 그 이유는 완전히 바뀐 7.0에 대한 시장의 반응 때문이었다. 마이크로소프트 SQL 7.0은 시장에서 폭발적인 반응을 보였다. 제품이 팔린 양도 마이크로소프트가 예상했던 것보다 훨씬 많았다. 1999년 5월 마이크로소프트 SQL 서버 7.0 첫번째 서비스팩이 발표됐고, 2000년 3월에는 두번째 서비스 팩이 발표됐다. 마이크로소프트는 수퍼 서비스팩이 필요없다고 판단했다. 계획을 바꾼 또 다른 이유는 고객의 요청 때문이다. 캐스케이딩 업데이트와 데이터를 삭제할 때 참조 무결성이 유지되지 않았다. 또한 파티션 뷰가 더 막강해지기를 원했다. 마지막으로 원래 계획했던 것보다 더 크고 막강한 좋은 제품을 만들어야 한다는 압력이 있었다. 이는 데이터베이스 시장의 선두 주자인 오라클은 마이크로소프트 SQL 서버 7.0의 없는 기능이 오라클에 있다고 발표한 것이 원인이 되었다. 개발팀의 계획은 전면적으로 수정됐고, 7.0의 두가지 단점만을 고치려고 했던 것이 이제는 새로운 제품을 개발하는 것으로 바뀌게 됐다.

 

 

한글판으로 활용도 높인 SQL 2000

 

마이크로소프트 SQL 2000의 개발은 엄격한 보안 속에서 이뤄졌고, 1999년 11월 베타1이 출시될 때까지 기능에 대한 아무런 언급이 없었고 2000년 2월 윈도우 2000이 발표될 때까지 공식적으로 발표되지 않았다. 내부적으로 코드명 CYOTE로 불린 마이크로소프트 SQL 2000은 분산 파티션 뷰를 지원함으로 예상치 못한 데이터 양의 성장을 관리할 수 있다. 마이크로소프트 SQL 2000이라는 제품명으로 결정됐다. 기존에 지향해 오던 버전명이 확 바뀐 것이다. 마이크로소프트는 기존 7.0에 비해 완전히 새로운 제품명이 필요하게 됐는데, 7.5라고 한다면 기존의 제품의 업그레이드 정도 밖에 인식이 안될 것이라고 판단했다. 그렇다고 제품명을 8.0으로 한다면 마이크로소프트의 제품 중 2000이라는 이름을 사용하지 않는 백오피스 제품이 된다. 이와 같은 이유로 마이크로소프트 SQL 2000이라는 제품명을 붙였다.

 

마이크로소프트 SQL 서버 2000은 기존의 개체들(테이블 제약, 뷰, 트리거)을 크게 바꿨을 뿐만 아니라 수십가지의 새로운 언어 기능을 추가했다. 한국 사람들이 볼 때는 뭐니 뭐니 해도 한글판이 있다는 것이 가장 좋다. 온라인 백서(마이크로소프트 SQL을 설치하면서 추가적으로 설치가 가능한데 SQL 서버의 모든 설명서가 여기에 있다. 대부분의 사람들이 잘 모르면 온라인 백서를 보라고 권할 정도로 설명도 잘돼 있고 쿼리 예제도 있다. 7.0까지는 온라인 백서가 영어였다)가 한글로 돼 있어 수월하게 볼 수 있다.

 

6.5에서 7.0으로 변화할 때처럼 데이터베이스 엔진을 통째로 바꾼 것이 아니기 때문에 두개의 베타 버전만이 발표됐고, 2000년 8월 6일 빌드번호 8.00.194.01로 고정하고 3일후 8월 9일에 제품을 출시했다.

 

 

개발자와 DBA로 구성되는 SQL 업무 영역

 

지금까지 SQL 서버의 발전 과정을 살펴봤다. 그렇다면 SQL 서버를 다루는 사람들은 어떤 업무를 하는지 궁금하다. 어느 SQL이든 마찬가지겠지만 업무의 성격에 따라 개발자와 관리자로 나뉜다. 관리자는 일반적으로 DBA(DataBase Administrator)라고 한다. DBA는 SQL에 관련된 모든 사항을 알아야 하는 팔방 미인이어야 한다. 개발에 경험도 있고 서버 관리도 할 줄 알아야 하고 네트워크에 대해서도 알아야 한다. 전에 한번 업체의 의뢰를 받아서 마이크로소프트 SQL 서버의 포트인 1433/TCP로 연결이 안된다고 한다. 서버를 들어가서 이렇게 저렇게 보았는데 크게 이상한 부분이 없었다.

 

고객환경을 파악해보니 파이어월을 사용하고 있었고, 문제는 파이어월에서 발생한 것이었다. 네트워크 장비인 파이어월은 하드웨어 솔루션도 있고 마이크로소프트의 ISA라는 서버 제품도 있다. 결국 의뢰자는 네트워크 통신 테스트를 시도해 보지 못했고 해당 포트가 정상적으로 열리는지를 잘 모르고 있었다. 이렇게 모르면 애꿎은 윈도우 2000이나 마이크로소프트 SQL 서버만 가지고 헛고생을 하게 된다는 것이다.

 

인터넷이 발전하기 전에는 데이터베이스의 네트워크 부분이 그리 큰 쟁점이 되지 않았다. 회사 내부에서 데이터베이스를 액세스를 할 정도의 업무 환경이었다. 그리고 또한가지 재미있는 사실은 아직도 금융권이나 대기업들은 유닉스에 오라클을 사용해야 한다는 의식이 팽배해 있다. 대형 업체들은 DBA와 개발자가 구분돼 업무를 분담하는 것을 기본으로 하고 있고 아직은 많은 대형 업체들이 오라클을 사용하고 있는 것이 현실이다.

 

인터넷의 붐을 타고 IT가 급속도로 발전하면서, 이득을 본 것 중에 하나가 마이크로소프트 SQL 서버다. 많은 사람들이 마이크로소프트 SQL 서버를 접하게 됐고 이 제품을 데이터베이스로 만들고 운용하게 됐다. 그러나 마이크로소프트 SQL 서버는 아직 DBA의 업무를 정식으로 필요로 하지 않는다고 많은 사람들이 생각하고 있다. 어떻게 보면 DBA 자체가 필요없다고 생각하는것과 같은 맥락이다. 이는 개발자가 DBA 업무도 해야한다는 뜻이다. 이같은 상황은 기업이 적은 비용으로 마이크로소프트 SQL 서버를 이용하기 원하기 때문에, 개발자가 관리자의 업무까지 수행하기 때문이다. 이런 상황 때문인지 마이크로소프트 SQL 서버는 DBA를 따로 둘 필요가 없다는 인식이 있지만, 사실은 아니다. 마이크로소프트 SQL 서버도 엄연하게 엔터프라이즈급으로 활용되므로 DBA가 존재해야 한다.

 

 

프로그래밍이 기본인 DBA

 

데이터베이스는 프로그램과 연관돼 있어, 프로그래머의 잘못으로 인해 데이터베이스 오류가 발생한다고 생각하기 쉽다. 이보다 먼저 데이터베이스가 서버에서 어떻게 성능에 영향을 미치는지를 고려해야 한다. 결과값이 나온다고 해서 성능에 아무 이상이 없다고 생각하면 안된다. 데이터베이스의 성능을 파악할 줄 모른다면 DBA와 같이 만들었던 프로그램이 어떻게 서버에 영향을 미치는지 테스트해 보는 것도 좋다. 이렇게 하면서 서서히 DBA로 접근하는 것이다.

 

필자는 프로그래밍 경험이 없다. 그래서 필자는 스스로 반쪽짜리 DBA라고 말한다. 예를 들어 어떤 문제가 발생했고 이것이 잘못된 쿼리에서 기인을 했다고 하자. 필자는 프로그램을 하지 못해 이것을 어떻게 수정해야 서버가 제대로 돌아가는지 모른다. 원인을 찾아냈으나 그것을 해결하는 것은 미지수다. 원인을 알고도 해결하지 못한다는 것은 답답한 현실이다.

 

여러분이 SQL을 배우고 DBA가 목표라면 SQL 프로그래밍을 현업에서 해 보라고 적극 권하고 싶다. 이렇게 프로그래밍 경험을 가지고 DBA를 한다면 DBA에 대한 업무 이해도 더욱 빨라질 것이다. 또한 결과물이 나왔다고 해서 그것에 만족하지 말고 서버에서 적극 테스트해 보라고 권장하고 싶다. 물론 운영중인 서버가 아니어야 한다.

 

이렇게 글을 쓰고 있는 중에 SI팀에게 의뢰를 받았다. 한 고객사에서 마이크로소프트 SQL 서버를 사용하고 있는데, 현재 접속자가 평상시 보다는 많다는 내용이다. 그렇다고 폭주라고 보기는 어렵고 사이트 로딩이 상당히 느린 상태다. 필자는 직접 해당 사이트를 접속해 테스트를 시도했는데, 첫페이지가 그냥 하얗게만 있고 전혀 로딩할 생각을 하지 않고 있다. 해당 업체의 허락을 받고 서버에 접속해보니 sqlservr.exe라는 프로세스가 CPU 100%를 차지하고 마우스 포인터는 메트릭스 식(슬로우와 끊김현상)으로 동작하고 있었다. 답답한 심정을 참아가며 몇가지를 간단하게 점검해 보니, 데이터베이스 프로그래밍을 잘못한 결과였다. 프로그램은 조인과 인덱스의 오류, 커서의 남발이 원인이었다. 이런 이유로 사이트가 느려지고 있다고 업체에 이야기했더니, 프로그램 오류라면 전에도 로딩이 어려웠어야 하는데, 갑자기 그런 이유를 모르겠다고 반문한다. 이는 현재 서버의 사양으로 봐서 전에 100명의 동시 접속자를 서버 컴퓨팅의 능력으로 처리할 수 있지만, 200명의 접속자는 이 서버가 감당하지 못했기 때문이다. 해결책은 데이터베이스 프로그램을 다시 짜야하지만, 이는 말처럼 쉽지 않은 것이 문제다.

 

 

GUI로 용이한 사용 환경 제공

 

마이크로소프트 SQL은 오라클과 항상 비교된다. 어제 모 인터넷 사이트에 올라온 글을 보니 마이크로소프트 SQL에 대한 몇가지 평가가 있었다. ‘마이크로소프트 SQL은 오라클에 비하면 하나의 툴 정도밖에 안된다’ ‘오라클보다는 가벼우니 마이크로소프트 SQL을 사용해라’ ‘이제 마이크로소프트 SQL도 명실상부하게 엔터프라이즈 급이다’ ‘사용해볼 만하다’ 등의 여러가지 평가들이 있었다.

 

필자는 오라클을 잘 몰라서, 마이크로소프트 SQL의 성능을 오라클과 비교할 수 없지만, 한가지 확실한 것은 마이크로소프트 SQL 서버가 RDBMS 제품으로 사용하지 못할 제품은 아니라는 것이다. 마이크로소프트의 정책상 사용하기가 쉽게 만들어져 쉽게 보이는 것이다. 

 

이같은 평가를 받은 원인은 GUI(Graphical User Interface) 때문이다. 키보드 입력 작업보다는 마우스 클릭 작업이 많아 쉽게 보인다. 나중에 기회가 되면 설명하겠지만 EM(Enterprise Manager)은 마이크로소프트 SQL 서버를 설치하면 SQL 프로그램 그룹에 자동으로 설치가 되는 데이터베이스 매니저 프로그램이다. 그럼 데이터베이스도 생성되고 삭제도 쉽게 클릭만으로 가능하다. 이같은 기능을 지원하는 것이 저장 프로시저(Stored Procedure)로, 프로시저가 없으면 일일이 타이핑을 해야 할 것이다. 

Part 6. 마이크로소프트 미디어 서버의 모든 것

 

지금까지 IIS, SQL 등 윈도우 서버의 주요 제품군을 살펴봤다. 이번 강좌는 동영상을 운영할 수 있는 미디어 서버가 어떻게 구성되고 운영되는지 알아보려고 한다. 국내 네트워크 환경에서는 동영상을 빈번히 활용하고 있기 때문에 관리자 역시 미디어 서버를 구축, 운영하는 방법을 파악하는 것이 전체 윈도우 서버를 관리하데 도움이 될 것이다.

필자가 처음 회사에 입사를 한 후 NT 4.0을 열심히 배우고 있었다. 회사에 늦게까지 남아서 일을 하고 있을 때 동료가 컴퓨터를 통해 영화를 보고 있었다. 이젠 컴퓨터로 영화도 볼 수 있는 세상이라고 생각을 했다. 그런데 그 화면을 불러오는 어드레스가 웹을 접속하는 방식과 비슷하다는 점을 발견했다. 또 여기에는 동영상 서버가 있다는 것도 알아냈다. 서버라고 하면, 필자가 공부하는 것이 아닌가. 동영상 서버도 서버의 한 종류인가 고민하면서 미디어 서버를 통해 유료 서비스까지 사용하면서 공부하게 됐다.

당시 배우던 윈도우 서버는 NT 4.0이다. 이때의 미디어 서버는 지금의 윈도우 2000 서버처럼 컴포넌트 형식으로 포함된 것이 아니고 미디어 서버 4.1을 따로 다운로드받아 설치해야 했다. 물론 무료였다. NT 4.0을 깔고 서비스팩 옵션을 깔고 나면 미디어 서버 4.1 버전이 설치됐다. 미디어 서버가 설치되면 인코딩 프로그램도 설치된다. 미디어 서버를 설치하고 난 후 동영상 파일을 올려 놓고 MMS(Micorsoft Media Server)라는 프로토콜을 이용해 접속하면 동영상을 볼 수 있다.

또한 그 당시의 동영상 대표는 RM, RV로 운영되는 리얼 플레이어였다. 마이크로소프트는 MMS 프로토콜을 업계의 표준으로 만들려고 많은 노력을 했고, 아울러 MMS에서 지원하는 파일 확장자를 따로 만들었다. 이때는 동영상으로는 ASF 파일과 WAV라는 확장자가 마이크로소프트 미디어 서버에서 동작하도록 인식됐다. 사실 이때는 그렇게 많은 부분을 마이크로소트프 미디어 서버가 차지하지 못했다. NT 4.0과 스트리밍 기타 서버 제품군을 섭렵하면서 어느덧 윈도우 2000 서버가 출시됐다.

 

동영상을 볼 수 있는 MMS

윈도우 2000으로 시스템이 바뀌기 시작했다. 마이크로소프트는 미디어 서버를 윈도우 2000에 무료로 내장했다. 괜찮은 생각이었고 무료는 어느 누구에게도 반길만한 일이었다. 윈도우 2000이 출시되면서 미디어 서버의 인터페이스는 깔끔해졌고 더욱 사용하기 편하게 만들었다. 또한 윈도우 2000으로 바뀌면서 WMT(Windows Media Technology)라는 변화된 용어를 사용하기 시작했다. 미디어 서버 4.1에서는 ASF 파일 확장자를 주로 사용했지만, 윈도우 2000으로 바뀌면서 WMV라는 파일 확장자가 ASF를 대체한다. 이렇게 되면서 동영상으로는 WMV, ASF 파일이 스트리밍할 수 있게 됐고, 음성으로는 WAV. MP3 등이 가능해졌다. 그러나 필자의 기억으로는 아직까지 이 부분에 대한 용어가 제대로 확립된 것 같지 않다. 사람에 따라 동영상 서버, 스트리밍 서버, 미디어 서버, MMS 서버라고 달리 불렀기 때문이다. 현재 마이크로소프트의 공식 명칭을 윈도우 미디어 서버로 하고 있다(www.microsoft.com/korea/windows/windowsmedia/).

스트리밍(streaming)의 뜻은 '물이 흐른다'이다. 개울에서 물이 흐른다고 하면 스트리밍이라는 단어를 사용하는데, 이것을 서버에서 본다면 미디어 서버가 영상을 접속한 사용자에게 물이 흐르는 것처럼 끊임없이 보내주는 형식을 취하고 있다. 미디어 서버의 스트리밍은 네트워크 관점에서 본다면 물이 흐르는 것처럼 끊김없이 영상이 전달하는 것이기에 스트리밍이라는 용어가 도입됐다. 또 하나, MMS는 하나의 프로토콜이다.

우리가 온더넷의 홈페이지에 들어가려면 http://www.infoage.co.kr에 접속해야 하는데, http라는 것이 프로토콜의 한 종류라는 것을 알 것이다. http가 웹 접속을 위해 개발된 프로토콜이라면 MMS는 동영상을 위해서 개발된 프로토콜이다. 마이크로소프트는 이것을 업계의 표준으로 만들려고 했지만 실패했다. 하지만 우리나라에서 만큼은 거의 성공을 거뒀다고 평가할 수 있다. 이렇게 MMS가 우리나라에서 자리 잡을 수 있었던 부분은 리얼네트웍스의 비싼 라이선스 가격 때문일 것이다. 초창기 리얼네트웍스의 RM을 알아 봤을 때 1000만원 단위의 라이선스 비용이 드는 것으로 알고 있다. 마이크로소프트는 리얼네트웍스의 시장을 잠식을 하기 위해서 미디어 서버를 윈도우 2000에 무료로 포함했고 현재 우리나라에서 만큼은 성공하고 있다. 많은 동영상을 운영하고 싶어하는 사이트는 윈도우 2000 서버를 도입하면서 미디어 서버로 운영했다. 윈도우2000의 라이선스 비용이 있겠지만 리얼네트웍스의 RM보다는 저렴했기 때문이다. 비용도 비용이지만 사실 여부를 떠나서 초보자도 쉽게 윈도우 서버를 운영할 수 있다는 생각도 있을 것이라는 개인적인 추측도 해본다.

 

 

웹 서버를 통해 재접속되는 동영상

이제 서버에 있는 WMV, ASF 파일을 어떻게 만들어 서버에 올려 놓는지 궁금하다. 우선 미디어 서버에의 접속은 인터넷 공간에서 이뤄진다(그림 1). 대부분의 많은 웹 사이트가 미디어 서버에 다이렉트로 연결해서 동영상을 보지는 않는다. 거의 대부분의 사이트가 웹 서버를 이용해 미디어 서버로 재접속한다. 미디어 서버에 접속할 때 mms://211.62.35.21/media/파일명을 치면 외우기가 여간 어렵지 않다. 그래서 웹 서버에서 링크를 활용해 미디어 서버로 가게 되는 것이 일반적인 방식이다.

일반적으로 (그림 1)과 같은 과정을 통해 동영상을 보게 된다. 여기에 미디어 서버에 동영상 파일은 어떻게 올릴 수 있는지를 설명해야 한다. 대부분이 FTP를 이용해 올린다. 물론 네트워크 드라이브를 연결해 올려도 되지만 파일 전송을 위한 프로토콜 FTP를 사용해 올리는 것을 권장한다. 인코딩 서버에서 제작이 된 WMV, ASF는 제작자를 통해 미디어 서버에 올려진다. 미디어 서버 메뉴 구성을 설명하면서 다시 언급하겠지만 유니캐스트라는 방식이 있다. 이 유니캐스트 중에 브로드캐스트라는 것이 있는데 쉽게 이야기하면 실시간 방송이다. 가끔 고객들에게 문의를 받으면 착각하는 부분들이 있는데 VOD와 브로드캐스트다.

VOD는 이미 설명한 것처럼 동영상 제작이 마쳐진 상태의 파일을 미디어 서버에 올려 서비스를 하게 되면 VOD라고 표현을 한다. 우리들이 흔히 말하는 라이브는 브로드캐스트, 유니캐스트라고 표현해야 하지만 이것이 어려워 그냥 라이브라고 한다. 이렇게 라이브로 구축하려면 방송 장비도 갖춰야 한다. 현장의 영상과 소리를 담을 수 있도록 카메라와 오디오 장비가 있어야 한다. 그리고 아날로그 신호를 디지털 신호로 받아 들일 수 있는 캡처카드가 장착돼 있는 PC도 한대 있어야 하고, 여기에는 인코딩 프로그램이 깔려 있어야 하며 이 인코딩 프로그램에서 캡처 카드를 인식하고 있어야 한다. 그리고 카메라에서 컴퓨터로 데이터를 전송할 수 있는 외부 연결 잭이 있어야 한다. 이렇게 되면 현장에서 어떤 영상을 카메라에 실시간으로 담고 있고 그것이 캡처카드로 받아지면서 아날로그가 디지털로 변환된다. 그리고 인코딩 프로그램에 의해 이렇게 카메라로부터 전송되는 영상을 미디어 서버로 전송하게 된다. 그러면 (그림 1)과 같은 방식으로 사용자들은 보게 된다.

사용자들은 이것이 실시간인지 인식하지 못할 수도 있다. 실시간 방송이라도 영상의 지연이 있어 TV처럼 바로 보여지는 것이 아니라 약 12초 정도의 차이가 있다. 이것은 필자가 라이브 시스템을 구축을 해 보고 직접 테스트를 했다. 캡처카드는 라이브를 할 때도 필요하지만 VOD용으로도 필요하다. 보통 카메라로 찍게 되면 6mm짜리 테이프인데 이것을 코덱용 데크에 넣고 돌리고 캡처카드를 통해 컴퓨터에 영상이 저장된다. VOD는 편집(화면 잘라내기, 자막삽입 등)이 가능하므로 영상을 일단 한번 컴퓨터로 불러 들인 후 다시 또 편집기 프로그램을 이용해서 불필요한 영상을 제거하거나 필요한 자막이나 음악을 삽입하기도 한다. 윈도우에서는 프리미어라는 것을 이용했고 다른 편집 프로그램도 많다.

미디어 서버 운영에 대한 기초 지식, 인코딩

필자는 실제로 회사 내부를 찍어 실시간으로 회사 홈페이지에 띄운 적이 있다. 이때 윈도우 2000 서버를 미디어 서버로 구축했고 인코딩 서버에 OSPREY 캡처카드를 장착했고 미디어 인코더 7.0을 설치했다. 잘 운영이 되던 것이 2일 정도 지나면 인코딩 서버가 다운됐다. 이유를 알아보니 OSPREY의 드라이버 문제로 판명됐다. 드라이버를 최신의 것으로 업데이트하면서 이 문제는 말끔하게 해결됐다. 서버 관리자들이 가장 간과하는 것 중의 하나가 드라이버 업데이트 문제다. 서버의 스펙을 정확하게 파악해야함을 물론이고 해당 사이트를 방문해 최신의 드라이버로 업데이트해야 한다. 물론 이렇게 하기 전에는 반드시 테스트를 거쳐야 한다.

인코딩에 대한 이야기가 나왔으니 한가지만 더 짚고 넘어가겠다. 인코딩을 하면 여러가지 설정을 하는 부분이 있는데, 그중 중요한 부분은 비트율(BIT RATE)라고 할 수 있겠다. 비트율이란 네트워크에서 바이너리 컨텐츠가 스트리밍되는 속도, 일반적으로 Kbps로 측정한다. ASF, WMV 파일이나 라이브 스트림의 비트율은 스트리밍 컨텐츠가 만들어진 후 인코딩 프로세스가 진행될 때 결정된다. 쉽게 말하면 해당 ASF, WMV 파일 등의 네트워크에서 전송이 되는 속도를 의미한다. 이 비트율이 결정된다면 그것은 최대 동시 접속자 수를 결정하는 것과 마찬가지다. 쉽게 계산하면서 설명해보자. 인코딩할 당시 비트율 적용을 250Kbps로 설정했다. 이 말은 사용자가 이 동영상을 접속하면 초당 250Kbps의 네트워크 대역폭을 사용한다. 일반적으로 현재 100Mbps 전용 회선을 사용하고 있다. 한사람이 250Kbps를 접속하고 있다면 문제가 없지만, 현재 동시에 접속하는 사용자가 많다면 서버는 느려지기 마련이다. 

대역폭을 정하는 이유는 무엇일까. 왜 동영상을 보여주는 서버에서 비트율을 결정하지 않고 인코딩을 할 때 비트율을 결정할까. 비트율은 화질과 아주 밀접한 관련이 있다. 비트율이 높다면, 예를 들어 1Mbps라든지 3Mbps로 스트리밍한다면 아주 선명한 고화질을 볼 수 있다. 그 대가로 네트워크의 대역폭 문제로 인해 동시 접속자수를 많이 수용하지 못한다. 비트율이 낮은 250,300Kbps면 화질이 그렇게 좋지는 않지만 많은 사용자를 접속하게 할 수 있다.

WMV와 AVI 파일 용량을 비교해 보면 아주 많이 차이가 나는 것을 볼 수 있다. AVI 영화를 보면 보통 700∼800MB의 용량이지만 WMV로 같은 영화를 보면 약 100MB 정도의 용량이다. 이는 비트율과 연관시키면 된다. AVI 역시 윈도우의 규격 파일 형식이다. 그러나 700MB나 되는 것을 네트워크로 전송한다면 네트워크 대역폭이 낭비되는 것이다. 그런데로 화질이 괜찮고 네트워크 전송에도 적합하게 만든 형식을 WMV이고 이것은 윈도우 미디어 인코더로 변환하면 나타나는 확장자다. 이렇게 인코딩을 할 때 여러가지 방식이 적용되지만 가장 대표적인 방식이 ZIP을 압축할 때와 마찬가지로 동영상이 압축이 된다고 생각하면 된다.

쉽게 예를 들어보면, 아마겟돈 영화에서 우주로 출발하려고 하는 젊은 굴착 기사를 기억하면 된다. 주인공의 딸과 사랑에 빠진 굴착 기사가 우주로 떠나기 전 들판에서 둘이 누워서 대화를 할때는 약간의 움직임만이 있다. 이렇게 되면 압축률이 상당히 좋아진다. 이 장면이 3분이라고 생각을 하면 3분 동안 백그라운드 배경은 변하지 않고 두 사람의 몸동작만 변한다. 이렇게 되면 변하지 않는 그림은 계속해 고정적으로 처리가 되고 변하는 부분만이 처리하면 되기 때문이다.

이렇게 길게 인코딩에 대해 설명했지만, 사실 인코딩 부분은 서버와는 많은 관련은 없다. 엄격하게 얘기를 한다면 인코딩 제작자는 좋은 화질을 만들고 네트워크에 맞게 비트율을 결정하고 편집을 한후 미디어 서버에 올려 놓으면 끝이다. 여기부터는 미디어 서버 관리자가 맡아야 할 몫이다. 그러나 인코딩과 서버 운영이 밀접하지는 않지만 어느 정도 연관이 있기 때문에 알아두어야 할 부분 정도만 간단하게 설명했다.

미디어 서버의 메뉴 구성과 기능
간단하게 메뉴에 대해 설명하면서 기능을 살펴본다.
 

☞ 서버 추가·제거·새로고침
마이크로소프트 제품의 특징은 다른 서버와 연결하는 것이다. 예를 들어 이렇게 다른 서버로 (그림 1)과 똑같은 인터페이스로 연결을 못한다면 설정 사항을 볼 수 없기 때문에 어쩔 수 없이 다른 서버에 따로 접속해야 한다. 이같은 관리 부분 때문이었는지 서버 추가 버튼을 클릭해 해당 서버의 호스트네임이나 IP를 적어 놓으면, ISM이라고 써진 부분이 해당 호스트 네임으로 변하면서 그 서버의 인터페이스를 불러오게 된다. 상당히 편하지만, 보안상으로는 안 좋은 부분이 있다. 한 서버가 뚫리게 된다면 다른 서버도 무사하지 못하기 때문이다. 보안은 편안함과 불편함의 양면을 가지게 된다. 보안이 강화되면 사용자들의 불편함이 늘지만 시스템의 안전성이 보장된다. 이것이 보안 관리자들의 가장 큰 숙제다.

이렇게 다른 서버를 연결을 해서 해당 서버의 설정을 둘러보고 수정한 후 미디어서버를 종료하고 난후 다음에 다시 (화면 1)을 열게 되면 기본 값으로 로컬호스트의 미디어 서버가 열리지만 아직 연결했던 서버도 드롭다운 리스트로 볼 수 있다. 연결했던 호스트를 제거하려면 서버 제거 메뉴를 이용해 해당 서버를 제거하면 된다. 서버 새로고침은 환경 설정을 한후 적용이 안된다고 생각되면 사용한다.
 
☞ 서버 구성
윈도우2000 미디어 서버는 크게 유니캐스트와 멀티캐스트 방식으로 나뉜다. 유니캐스트는 일대일 통신이라고 보면 되는데, 이때 사용되는 프로토콜이 MMS이다(그림 2). 그러나 자세하게 속내를 보면 MMS만을 이용을 하는 것은 아니다. 순차적으로 보면 MMS→MMST→MMSU→HTTP 라는 네가지 프로토콜이 사용된다. MMS는 미디어 서버와 계속해 커넥션을 맺고 데이터가 제대로 전송됐는지 체크한 후 다음 영상을 보내는 과정이다. 중간에 끊김 현상이 발생하거나 데이터가 전송되지 않는다면 잘 보내지지 않을 것을 전송한 후 다음 영상을 보낸다. MMST는 MMS+TCP라고 보면 된다. 쉽게 MMS에 TCP 프로토콜을 결합한 것이다. MMSU는 MMS+UDP이다. UDP의 특성은 TCP와는 다르게 에러 체크를 하지 않는다는 것이다. 일단 전송의 목적이 있는 것이다. 대표적인 UDP를 사용하는 것이 DNS 서버다. HTTP는 여러분이 일반적으로 웹 접속을 하는 HTTP를 이야기 한다. HTTP의 특성은 커넥션이 맺어지지 않으며 한번에 많은 양의 데이터를 전송하는데 목적이 있다. MMS와 HTTP의 차이점에 대한 질문을 자주 받는데 우선 안전성의 문제다. MMS는 에러체크, 제어와 클라이언트로부터 영상 전송에 대한 피드백을 받지만 HTTP는 아니다. 눈에 드러나는 차이는 MMS를 사용하면 시간을 조정하는 스크롤이 있지만 HTTP로 한다면 그것을 사용할 수 없다. 마지막으로 중요한 것은 로그다. HTTP로 한다면 로그가 기록되지 않기 때문에 분석이 불가능해진다. 문제가 생기면 해결도 쉽지가 않을 것이다. 로그는 서버를 분석하는데 중요한 자료가 된다. 로그가 없으면 그건 일반 PC라고 봐도 된다.

멀티캐스트 방식은 TV를 연상하면 쉽다. 24시간 내내 방송하는 케이블TV를 볼 때, 우리는 TV를 켜서 그냥 채널만 맞추면 된다. 마찬가지로 미디어 서버에서 멀티캐스트를 놓으면 우리는 그냥 그 채널만 알면 된다. 유니캐스트가 일대일의 형식이라면 멀티캐스트는 일대다의 형식이다. 멀티캐스트의 장점은 하나의 스트리밍 채널로 여러 클라이언트가 붙는 것이기 때문에 네트워크 대역폭이 상당히 절약이 된다는 점이다. 유니캐스트는 접속자가 붙는 숫자만큼의 네트워크 대역폭이 필요하지만 멀티캐스트는 그 채널에 대한 대역폭만 가지고 있으면 된다. 이렇게 좋은게 왜 사람들에게 알려지지 않고 사용이 되지 않는가라는 의문을 품을 수  있다. 멀티캐스트를 지원하지 않는 라우터가 있다. 라우터는 보통 내부에서 외부로, 외부에서 내부로 통하는 네트워크 관문 역할을 하는데 멀티캐스트를 지원하지 않는 라우터가 있다. 이런 이유로 인해 멀티캐스트가 각광을 받고 있지 못한다. 유니캐스트를 이용하면 가끔 네트워크의 대역폭 문제로 인해 서비스의 품질이 저하가 되는 경우가 있다. 이런 이유로 인해 CDN(Content Delivery Network)이라는 기술이 탄생했다. 이것은 미디어 서버 뿐만이 아니라 모든 것에 적용이 되지만 미디어 서버가 적용하는 것이 구조상 쉽다. CDN의 개념은 복제의 개념으로 똑같은 서버를 각 ISP(KT, 데이콤, 하나로통신 등)에 두어 가장 네트워크가 좋은 구간으로 연결한다고 생각하면 된다. 그리고 장애에 대비한 방편이기도 하다. 한쪽의 ISP에서 문제가 발생하면 다른 쪽으로 붙을 수 있도록 조치를 취한다.

 

 

☞ 서버 등록정보
서버 등록정보에서는 미디어 서버의 전체적으로 접속하는 클라이언트의 수를 제한, 최대 대역폭 설정, 파일 최대 비트 전송률이 있다. 최대 클라이언트 수와 최대 대역폭은 별칭(alias) 별로 설정할 수 있다. 여러 개의 별칭 게지시점을 가지고 운영을 하는데 한곳의 별칭 게시지점의 트래픽이 폭주하는 것을 알았다면 이곳의 최대 클라이언트 수를 0으로 하게 되면 이 별칭 게시지점은 완전히 막히게 된다. 여러 개의 별칭 게시지점을 가지고 운영하고 트래픽이 폭주하게 된다면 임시방편으로 좋은 처리수단이 될 수 있다.

게시지점에 대해 보안 설정을 할 수 있다. 기본값은 '인증을 사용할 수 없습니다'로 설정돼 있다. 이는 연결하는 누구에게나 동영상을 스트리밍한다는 뜻이다. 그 이외의 세가지 값인 HTTP-BASIC 인증과 그룹 등록 서비스 계정 데이터베이스, HTTP-BASIC 인증과 NTLM 계정 데이터베이스, 마이크로소프트 윈도우 NT LAN 매니저 인증과 계정 데이터베이스라고 하는 세가지 방식은 인증과 확인을 걸치는 작업을 한다. 세가지  인증 방식의 차이는 윈도우 관련 서적이나 마이크로소프트의 사이트에서 쉽게 알아낼 수 있다. 세가지 방식의 공통은 '너가 누구니?' 하고 조그만 창이 뜨면서 물어 본다. 그럼 여기에 아이디와 패스워드를 넣어야 동영상을 볼 수 있다. 필요한 부분이 있다면 요긴하게 사용해 볼만한 기능이다.

배포 인증은 한쪽의 미디어 서버에서 다른쪽 미디어 서버로 스트림을 배포하는 것이다. 사용자는 경우에 따라서는 다른 쪽의 미디어 서버를 연결해 동영상을 볼 수 있다. 마이크로소프트 서버 운영에 대한 큰 관점은 분산 환경이다. 한쪽의 서버가 부하에 걸리면 하나를 더 증설해 대처하기 위한 목적인데, 이때 사용되는 메뉴라고 보면 된다.

게시지점 로그의 기본값은 '사용 안함'이다. 로깅 사용을 체크하고 매일, 매주, 매월, 파일크기 제한으로 할 것인지를 선택하고 로그 파일 디렉토리를 지정하면 그쪽에 로그 파일이 생성된다. 미디어 서버 로그 파일 항목은 다른 웹 서버와 많이 다르기 때문에 한번 연구를 해야 한다. 서버를 파악하는 데에도 도움이 많이 되니 한번 짚고 넘어가야 할 부분이다.

MMS라는 프로토콜을 사용하면 서버는 1755/TCP가 LISTEN 상태에 있다. 그렇게 흔한 경우는 아니지만 간혹 파이어월로 인해 1755가 막히는 경우가 있다. 이럴 때는 어쩔수 없이 HTTP를 이용한 스트리밍 배포를 해야 하고 설정은 HTTP 스트림과 배포에서 할 수 있다. 

 

 

☞ 모니터 서버
게시지점 이벤트라고 하는 메뉴는 게시지점에 연결과 연결을 끊는 정보를 보여주게 된다. 현재 어느 게시지점에, 어떤 것이 연결되고 있는지 실시간으로 볼 수 있는 기능이다. 게시지점 클라이언트는 연결하는 클라이언트에 대한 정보를 담고 있다. 스테이션에 관한 사항은 설명을 생락하도록 하겠다.

 

그러면 간단하게 VOD를 위한 게시지점을 하나 만들어 보도록 하자. 우선 왼쪽 창의 서버 구성에서 유니캐스트 게시지점으로 간다. 그리고 오른쪽을 보면 마법사를 사용해 새로운 주문형 게시지점 만들기가 클릭이 돼 있는데 복잡하기만 하고 어렵다. 이 기능을 해제하고 왼쪽의 주문형을 클릭하면 팝업으로 새로 만들기를 선택한다(화면 3).

 

별칭 부분에는 아무렇게나 입력해도 되지만 이왕이면 각각의 게시지점을 잘 구분할 수 있게 이름을 짓도록 하자. MEDIA라고 입력하고, 디렉토리 경로는 찾아보기해서 해당 폴더를 선택해도 되고 직접 입력을 해도 된다. 여기서 한가지 주의 사항은 직접 입력시 디렉토리 경로가 다르더라도 확인을 하고 설정 작업을 마칠 수 있다는 것이다. 물론 미디어 서버에 연결하는 클라이언트에게 스트리밍을 하지 못하는 것은 당연하다.

 

이렇게 설정하면 이제 서버는 준비가 됐다. 테스트를 하려고 하면 윈도우 미디어 플레이어를 열고 파일→URL열기 메뉴로 가서 다음과 같은 형식으로 입력을 한다. MMS://서버 IP나 도메인 이름/별칭/파일명으로 한다. 이같은 호스트가 DNS에서 MEDIA.MS.COM이라는 DNS 이름을 가지고 있고 IP가 211.222.222.222라고 한다면 연결 방식은 MMS://MEDIA.MS.COM/MEDIA/파일명이나 MMS://211.222.222.222/MEDIA/파일명이 된다.

 

유니캐스트의 또하나의 방식 유니캐스트 브로드캐스트 설정이다. 유니캐스트 방식과 마찬가지로 마법사를 이용하겠다는 체크를 해제하고 난후 왼쪽의 브로드캐스트의 새로 만들기를 선택하면 (화면 3)을 볼 수 있다.
 

 

 

(화면 3)의 별칭은 VOD를 생성하는 유니캐스트 게시지점과 같은 역할을 한다. (화면 3)의 ①은 경로 유형인데 어디서 영상을 받아 사용자에게 전달할 것인가를 결정하는 것으로,

▲윈도우 미디어 인코더

▲원격 윈도우 미디어 게시지점

▲원격 윈도우 미디어 스테이션로 세가지 유형으로 나뉜다.

 

윈도우 미디어 인코더 방식은 앞부분에서 설명을 한 것이다. 윈도우 미디어 인코더에서 영상을 전송받는 것으로 설정을 하자. ②는 미디어 인코더에 연결하는 어드레스다. 이 어드레스로 인코더에서 미디어 서버로 영상을 가져오는 것이다. ③은 일반적으로 MSBD라는 프로토콜을 사용하고 7007/TCP를 사용하는데 역시 파이어월 문제로 인해 설정돼도 연결이 안되는 경우가 있다. 이럴 때는 HTTP로 인코더를 연결해서 영상을 전송받아야 한다.

 

 

미디어 서버 활용 FAQ

이렇게 해서 간단하게 서버 구성의 메뉴와 간단하게 설정을 했다. 이제 실질적으로 운영하면서 겪었던 몇가지 사례와 FAQ를 살펴보자.

 

☞ 동영상이 보이지 않는다. 서버가 잘못된 것인지 의심하는 이들이 많다.
천만의 말씀. 서버는 잘 운영되고 있다. 클라이언트가 서버에 연결하는 어드레스를 잘못 입력한 것이 아닌지 의심해봐야 한다. 그리고 이런 경우는 미디어 플레이어로 지정된 파일을 찾을 수 없다는 메시지가 나오고 '자세히'를 클릭하면 영어로 PATH가 잘못됐으니 확인해 보라는 메시지도 있다.
또다른 이유는 버전이 다를 경우에도 동영상이 안보일 수 있다. 윈도우 미디어의 버전은 4부터 시작해서 7, 8, 9로 이어진다. 현재 윈도우 2003에서는 미디어 9 시리즈가 탑재돼 있다. 마이크로소프트의 정책이 그러하듯이 윈도우 2000에서 미디어 7, 8로 인코딩된 것을 윈도우 2003인 미디어 9에서 돌리면 동영상을 볼 수 없는 경우가 있다. 이럴 때는 미디어 9에서 다시 인코딩을 해야 한다.

 

☞ 동영상이 소리만 나오고 화면이 까맣게 나오는데.
이 경우는 100% 클라이언트의 네트워크 대역폭이 충분하지 못하기 때문이다. 초창기에는 이런 경우를 자주 봤지만 이제는 네트워크 초강대국이라 그런지 거의 못 들어본다. 이런 일이 생기는 이유는 클라이언트가 미디어 서버에 연결하고 인코딩할 때 결정됐던 대역폭을 가지고 있어야 하는데 그렇지 못하면 대역폭이 큰 영상은 전송을 실패하고 대역폭이 작은 소리만 전송이 되는 것이다. 인터넷 회선을 쓰는 업체에 문의하면 도움이 될 것이다. 

 

☞ 동시 접속자가 1000명을 예상하고 있는데, 어떤 방법을 사용해야 할까.
300Kbps로 한다고 가정하고 10명의 동시 접속자수면 3Mbps다. 100명이면 30Mbps 그리고 300명이면 90Mbps다. 수치상으로는 330명까지 가능하지만 1000명은 수용할 수 없다. 이럴 때는 윈도우 2000 어드밴스드 서버를 이용해서 네트워크 로드 밸런싱을 구성해야 한다. 물론 서버는 3대가 필요하면 각 회선도 100Mbps 전용 회선이 필요하다. 요새는 100M 이상의 회선 서비스가 지원되니 이 부분으로 고려해야 할 것이다.

 

☞ 인코딩 서버와 미디어 서버를 구매하려고 합니다. 미디어 서버의 사양은 제온 3.06 듀얼, 메모리 2GB, 인코딩 서버는 펜티엄 4에 메모리 512MB로 구성하려고 한다. 구성이 적합한지 궁금하다.
이 같은 사례는 빈번히 일어난다. 일반적으로 인코딩은 서버라는 개념이 없어서 그런지 그저 그런 사양으로 하고, 사람들이 접속을 하는 미디어 서버는 고사양이어야 한다는 생각을 가지고 있다. 인코딩 서버는 컴퓨팅 자원을 아주 많이 소모하고, 그중 CPU의 자원을 거의 다 사용한다. 그리고 인코딩하는 데이터를 저장하려면 하드디스크 용량도 많아야 한다. 반면, 미디어 서버는 네트워크에 연결되는 장비이기 때문에 네트워크 대역폭만 확보되면 별 지장이 없다. 100Mbps에 사양이 낮은 PC로 미디어 서버를 사용해도 원할하게 운영할 수 있다. 실제로 100Mbps 회선에서 95Mbps까지 사용한 적이 있는데, 이때 CPU 상태를 보니 10% 전후를 사용했다. 이 정도라면 아주 여유롭다고 볼 수 있다.

 

 

Part 7. 윈도우 서버의 다양한 제품군

 

이번 강좌는 연재의 마지막 순서로 그 외의 서버 제품군을 다룰 것이다. 그 이외의 서버 제품군에 대해서는 1회 윈도우 서버와 제품군에 대해 설명할 때 간략하게 소개한 적이 있다. 필자의 경험상 서버 관리자가 되면 다양한 서버를 운영하고 싶어진다. 하지만 무작정 도전해보는 것보다는 서버 기능을 제대로 파악해서 자신이 진정으로 하고 싶은 것을 찾아서 배우는 것을 추천한다.

윈도우 서버 제품군은

▲윈도우 2000 서버

▲윈도우 2003 서버

▲SQL 서버

▲BizTalk 서버

▲커머스 서버

▲컨텐트 매니지먼트 서버

▲익스체인지 서버

▲오퍼레이션 매니저

▲시스템 매니지먼트 서버

▲ISA 서버 등으로 구분된다.

이외에도 몇가지가 더 있지만 이들 제품만 알아도 충분할 것이다. 이번 강좌에서는 지금까지 다루지 않았던 마이크로소프트 익스체인지 서버와 ISA 2000, 애플리케이션 센터, SMS 등에 대해 알아본다.

메세징 시스템의 대명사, 마이크로소프트 익스체인지 서버

익스체인지 서버는 마이크로소프트의 양대 산맥중 하나다. 필자는 익스체인지 서버를 제대로 운영해 보고 싶어, 테스트 환경을 만들었다. 액티브 디렉토리 도메인 컨트롤러 서버 1대와 익스체인지 서버가 돌아갈 서버 1대 그리고 익스체인지 클라이언트 1대를 가지고 테스트 환경을 만들었다. 참고로 자기가 운영할 서버나 테스트 환경을 만들 때 서버를 조립해 활용하는 것을 추천한다. 처음에 서버를 구입할 때 완제품을 들여오는 경우가 많은데, 스스로 조립을 하면 하드웨어 구조가 쉽게 파악된다는 점에서 유용하다. 예를 들어 케이블을 연결할 때도 모양이 같다고 꽂는 것이 아니라, 왜 여기에 케이블이 꽂히는지 생각하는게 중요하다. 또한 어떻게 전송이 될 것인지도 고민하면서 작업을 하면 능률은 배가될 것이다.

조립을 끝마치고 익스체인지 2000을 설치하다 보면 부팅이 안되는 경우가 있을 것이다. 이는 자주 겪지 못하는 경우라 처음에는 당황하지만, 이 역시 해결책은 있다. 지금까지 하드웨어 작업만 했고, 하드웨어의 문제가 있다고 판단해 문제가 빨리 해결되지 않을 것이다. 하지만 해당 제품의 홈페이지에 가서 문제를 뒤지다 보면 쉽게 찾을 수 있다.

이렇게 몇 번의 경험을 거치면 어떤 업체의 제품인지에 상관없이 해결책을 찾을 수 있다. 인텔, 썬, 컴팩이라는 브랜드는 상관없이 서버라는 구조는 같기 때문이다. 따라서 서버 관리자는 서버 환경을 조성하는 것부터 시작해 애플리케이션을 설치하는 것까지 모두 파악하고 있어야 문제가 발생했을 때 쉽게 해결할 수 있다. 문제가 서버단 하드웨어 때문인지, 운영체제 때문인지, 애플리케이션의 문제인지 아니면 네트워크 단의 문제인지 관련된 모든 사항을 알고 있어야 한다. 그래야 서버 관리자는 팔방미인으로 다시 태어날 수 있다.

테스트 환경은 자기가 꾸미기 나름이고 몇 대가 됐든 상관없다. 익스체인지를 설치하기로 마음먹었다면, 액티브 디렉토리의 DNS에 대해 자세히 알고 있어야 한다. 이 부분은 2회 강좌인 액티브 디렉토리에서 언급했다. 다시 한번 간단히 설명하면 DNS는 무엇이 어디에 있는지 알려주는 것으로, 보통 액티브 디렉토리로 로그인할 때 계정명@도메인명을 사용한다. UPN(Universal Principal Name) 방식이다. 아니면 로그온을 할 때, 계정명/패스워드/도메인을 선택하면 된다. 이렇게 로그인을 하는 동안 이뤄지는 작업 중의 하나가 dec1231이 로그온을 요청하고 이 요청에 대해 아이디와 패스워드가 맞는지 틀리지는 확인하고 SID 등을 부여하는 일이다. 이렇게 부여받으려면 인증하는 서버를 찾아야 하는데, 이를 액티브 디렉토리라는 서버에서 작업한다. 즉, 액티브 디렉토리가 어디 있는지 알려주는 것이 DNS다.

도메인에 들어갈 때 클라이언트에서 일어나는 가장 일반적인 에러는 일반 DNS 서버를 잡아서 생기는 것이다. 코넷이나 데이콤과 같은 일반 DNS 서버들은 액티브 디렉토리에 대한 레코드를 가지고 있지 않다. 그리고 가져서는 안된다. 그러므로 클라이언트는 액티브 디렉토리 서버를 찾지 못하고 에러를 방출한다. 한마디로, 무엇을 찾으려고 집밖에 나갔다가 아무것도 찾지 못하고 도로 집으로 돌아오는 경우다. 따라서 DNS는 액티브 디렉토리에서 중요하게 생각하는 부분이다.

익스체인지 서버를 설치하려면 먼저 액티브 디렉토리를 구축해야 하며, 액티브 디렉토리를 구축하기 전에는 DNS를 먼저 구축해야 한다. DNS는 액티브 디렉토리를 설치하는 중간 과정에서 설치할 수 있지만, 먼저 수동으로 설치하고 액티브 디렉토리를 설치하기를 권장한다. 액티브 디렉토리를 설치하는 중에 DNS를 설치하면 자동으로 설치하기에 그 과정을 제대로 파악하기 힘들기 때문이다. 수동으로 설치하면서 설정 과정을 하나씩 파악해 가는 것을 적극 권장한다.

액티브 디렉토리와 DNS를 설치했다면, 주의할 것이 하나 있다. DNS가 자기 자신을 루트 네임서버로 등록한다는 것이다. 이렇게 설정되면 안된다. 그 이유는 DNS 자기 서버의 구역에 해당하는 도메인 네임이 없다면 DNS는 루트 네임서버라고 했으니 나가 보지도 못하는 형국이 된다. 자신의 액티브 디렉토리 안에서 루트가 된다면 별 문제가 안되지만, 외부로 DNS 쿼리를 날려야 하는 경우는 해당 어드레스를 찾지 못한다. 서버를 다 설치하고 자기 자신의 루트 네임서버를 지우지 않는다면 윈도우 업데이트 사이트를 방문하지 못한다. 그러니 루트 네임 서버를 지우기 바란다.  

그 이외의 DNS에 대해서는 2회 액티브 디렉토리를 참고하거나 마이크로소프트 사이트를 방문하면 쉽게 찾을 수가 있다.

익스체인지를 다루기 전에 액티브 디렉토리에 대해 제대로 파악하고 있어야 한다. 익스체인지 5.x와는 다르게 2000부터는 액티브 디렉토리의 계정이 익스체인지의 계정이 된다. 즉, 따로 익스체인지에 계정을 만들지 않아도 된다. 익스체인지가 설치되면 액티브 디렉토리의 구조도 전부 변하기 때문이다. 여러가지 면에서 액티브 디렉토리를 모르고 익스체인지를 한다는 것은 배추를 소금에 절이지 않고 김치를 담그는 것과 같다. 액티브 디렉토리에 대해 충분히 공부하기 바란다.

익스체인지를 설치하면 낯선 부분을 많이 접한다. 기존의 셋업과는 약간 다른 부분이 있다. 컴포넌트를 선택하는 부분이 조금 난해하지만 관련 서적을 펼쳐 놓고 셋업을 시작하면 어렵지 않게 작업할 수 있다. 다만 수차 말하지만 사전 정지 작업인 DNS와 액티브 디렉토리를 설정해 놓고 시작해야 에러가 발생하지 않고 한번에 설치할 수 있다. 익스체인지를 설치하는 동안 큰 변화는 액티브 디렉토리 서버의 CPU 사용률이 엄청나다는 것이다. 셋업을 하다가 에러가 발생하는 가장 큰 이유는 두가지인데, DNS 서버 설정 부분과 액티브 디렉토리 서버가 제대로 응답하지 못해서 나타나는 경우다. CPU 사용률을 보니 그럴 법도 하다. 구조를 변경하느라 자원 사용률이 너무 많아서 셋업이 안되는 경우도 있다. 이럴 때는 액티브 디렉토리 서버가 한가한 때를 이용해 설치하기를 권장한다.
셋업이 다 끝났다면 바로 익스체인지를 활용할 수 있다. 그러나 익스체인지는 서버만 있다고 해서 완성되는 것은 아니다. 클라이언트도 설치해서 클라이언트가 어떻게 동작하는지도 같이 확인해야 한다. 클라이언트에 아웃룩을 버전에 맞게 설치하고 전자우편 보내기를 시작한다. 보내지지 않는다면 무엇이 이상한가 확인해본다. 서버에 서비스하는 포트는 접속이 잘 되는지, 설정 부분에 이상은 없는지, 아이디와 패스워드는 맞는지 등을 점검한다.

아웃룩 2000은 일정을 체크하는 기능이 있다. 회의 주체자가 몇 시에 미팅을 할 것이라고 메시지를 보내면 답변자들은 참석 여부를 밝힐 수 있다. 서버에서는 누가 메시지를 열어 봤는지 등도 알 수 있는 편리한 기능이다. 한 사무실에 직원이 모두 있는 환경이면 그리 매력적인 기능이 아닐테지만, 여러 곳에 사무실을 가진 기업은 좋은 기능이 될 수 있을 것이다.

필자가 익스체인지로 테스트 한 부분은 여기까지다. 윈도우 2000이나 MS SQL 그리고 익스체인지 등은 훌륭한 서버다. 그러나 이런 서버를 좀더 세련되고 편하게 운영하려면 그 서버에 맞게 스크립트를 잘 다룰 줄 알면 운영하는데 아주 편하다. 특히, 익스체인지는 메세징 시스템에 맞게 비주얼 베이직 같은 프로그램을 같이 잘 다룬다면 더 없이 행복한 관리자가 될 것이다. 익스체인지만으로도 좋은 메세징 시스템으로 사용할 수 있지만 기업의 구미에 맞추려면 비주얼 베이직이나 관련 프로그램을 다룰 할 줄 알아야 할 것이다.

 

파이어월과 프록시 역할의 ISA 2000

ISA 2000은 프록시 2.0에서 발전했다. ISA 2000으로 둔갑하면서 파이어월 기능을 추가했고 ISA 2003은 더욱더 강력하게 프록시와 파이어월 기능을 구현한다. ISA 2000 제품을 일본에서 많이 사용한다고 한다. 마이크로소프트 관계자와 대화하던 중 익스체인지 ISA 2000은 일본어는 있는데 왜 한국어 버전이 없는가라고 물었다. 이유는 한국 마이크로소프트는 일본에 비해 매출이 한참 떨어진다는 것이다. 본사에 뭐 하나 지원해 달라고 할 때도 눈치 보인단다. 우리 딴에는 마이크로소프트 제품을 꽤 많이 사용하고 있는 것으로 생각하지만 그렇지 않은가 보다.

현실적으로 파이어월 제품으로 ISA 2000을 쓰는 곳이 그렇게 많지 않은 것은 사실이다. 특히, 큰 회사는 전문 파이어월을 선호한다. 사실 파이어월은 서버 제품이라기 보다는 네트워크 제품이기 때문이다. 마이크로소프트에서 개발해서 그런지 서버 쪽으로 명명된 것이다.

ISA 2000을 다룬다면 ISA 2003을 다루는 것은 그리 어렵지 않을 것이다. ISA 2000을 설치하려면 서버가 있어야 하지만 ISA 2000은 반드시 LAN 카드가 2장이 있어야 한다. LAN 카드가 2장이 있더라도 사설 IP 대역인 LAT(Local Address Table)의 IP는 꼭 필요하다. 이것을 설정하지 않으면 ISA 2000의 설치가 중간에 중단된다. LAT는 파이어월 안쪽에 있어야 할 클라이언트의 IP 어드레스의 모음이라고 보면 된다. 본질적으로 클라이언트의 파이어월, 프록시 역할을 해야 하는데, 그것이 없으니 더 이상 설치하지 못하게 했다.

이렇게 설치를 완료하면 ISA 2000에 필요한 패치를 하면 된다. ISA 2000의 파이어월 기능은 여느 파이어월과 다른 점이 없지만 패킷 필터링 뿐만이 아니라 애플리케이션 필터링도 가능하다는 것이다. 보통 네트워크에서 데이터가 전송될 때 패킷이라는 단위로 만들어지고 그 패킷에는 갖가지 정보들이 있다. 목적지 어드레스도 가지고 있을 것이고 포트 번호도 가지고 있을 것이다. 패킷 필터링은 이런 패킷의 구조를 분석해 서버에서 거부하는 패킷의 조건에 해당되면 그것을 ISA 2000에서 차단한다. 이런 패킷 필터링은 WELL-KNOWN 서비스 공격에는 취약하다. 웹 서비스 포트인 80 포트를 이용해 공격하면 패킷 필터링은 막을 수 없기 때문이다. ISA 2000은 애플리케이션 필터링 기능이 있어서 이 부분을 이용하면 패킷 필터링에서 통과한 패킷을 애플리케이션 단에서 분석해 불필요한 트래픽이라면 거부할 수 있다.

ISA 2000은 파이어월 기능도 있지만 프록시 기능이 있다. 프록시란 PC 사용자와 인터넷 사이에서 중개자 역할을 수행하는 서버로, 보안이나 관리적 차원의 규제 그리고 캐시 서비스 등을 제공한다. 프록시 서버는 사용자로부터 웹 페이지 전송 요청 등과 같은 인터넷 서비스 요청을 받는다. 만약 그 요구가 필터 요건을 통과한 정당한 요구라면, 프록시 서버는 자신의 로컬 캐시에 이전에 다운로드받았던 웹 페이지가 존재하는지를 확인한다. 만약 그 페이지가 발견되면, 사용자의 요구를 인터넷에서 새로 찾지 않고 로컬 캐시에 있는 내용을 사용자에게 보낸다. 그러나 사용자가 캐시에 없는 내용을 요구한 경우에는, 프록시 서버가 사용자를 대신해 자기 자신의 IP 어드레스 중 하나를 사용해 외부의 인터넷에 있는 서버에 페이지 요구를 전달하고, 요청한 페이지가 도착하면, 프록시 서버는 원래의 요청자에게 그것을 전달한다. 프록시 서버의 이점은 모든 사용자들에게 캐시 서비스를 한다는 점이다. 만약 사용자들의 페이지 요구가 빈번한 인터넷 사이트가 있다면, 그 내용들은 사용자의 응답시간을 개선시킬 수 있도록 프록시 서버의 캐시에 있는 것이 좋을 것이다. 그러나 실제로 캐시 서버라고 불리는 특별한 서버도 있다. 그외에도 프록시 서버는 또한 입출력에 관한 기록을 남기는 일도 함께 수행한다.

ISA 2000의 클라이언트는 시큐어 NAT, 파이어월 클라이언트, 웹 프록시 클라이언트로 나뉜다. 간단하게 (표)로 비교해 보자.

 

파이어월 클라이언트 시큐어 NAT 웹 프록시

- Winsock 애플리케이션을 지원 다중연결(multiconnection) 프로토콜을 위해서는

   애플리케이션 필터가 필요

- HTTP , HTTP-S , FTP등을 지원운영체제에서만 동작

- TCP/IP가 설치된 모든 운영체제에서 동작 웹 브라우저를 통해 모든 운영체제에서 동작

- 사용자 기반의 인증을 지원 사용자 기반의 인증을 지원하지 않음

- 사용자 기반의 인증을 지원

(표)를 보면 각각의 클라이언트의 차이점을 구분할 수 있다. ISA 2000은 물론 서버들의 파이어월로도 이용할 수 있다. ISA 2000의 웹 게시 마법사로 웹 서버를 이용할 수 있고 서버 게시로 다른 마이크로소프트 SQL EXCHANGE MEDIA 등을 모두 이용할 수 있다.

파이어월을 배우려면 네트워크에서 대해 전문가는 아니더라도 네트워크가 어떻게 동작을 하는지를 알아야  도움이 될 수 있다.

 

그 이외의 많은 제품들

1회 강좌에서 마이크로소프트의 많은 제품에 대해 간단하게 언급했다. 사실 필자는 여지껏 설명했던 서버들은 다뤘지만 그밖의 다른 제품들은 다루지 못해서 자세히 설명하지는 못하겠다. 그 이외의 제품에 대해서는 간단하게 아는 것만 설명하도록 한다.

·애플리케이션 센터(Application Center)
이 서버는 애플리케이션을 로드밸런싱하는 역할을 한다. 현재 있는 곳의 서버 중에 애플리케이션용 서버가 8대 있다. 애플리케이션 센터의 역할은 COM+에 등록된 애플리케이션에 대해 로드밸런싱처럼 분할하는 역할을 한다. 마이크로소프트에서 제시하는 로드밸런싱은 네트워크 로드밸런싱으로 웹서버 단에서 분할하고 데이터베이스로 가기 직전에 애플리케이션 센터를 거쳐 클러스터된 데이터베이스로 가는 구조를 보이고 있다. 이렇게 하려면 비용이 많이 들 것이다.

·Sharepoint Portal Server
ERP(Enterprise Resource Planning)를 위해서 생긴 서버라고 보면 된다. 쉽게 생각하면 여기에는 윈도우 2000, MS SQL, 익스체인지가 섞여 있다고 보면 된다. 이는 ERP에 필요한 조건들이다.

·SMS(System Management Server)
SMS는 패치와 시스템 관리를 담당한다. 이 SMS와 같이 동반돼야 할 부분이 MOM(Microsoft Operation Manager)이다. SMS의 역할은 윈도우 쪽의 패치와 성능 분석 등이다. MOM도 성능 분석을 하면서 리포팅 기능이 있다. 쉽게 보면 서버를 관리하는 서버로, 서버 대수가 많다면 아주 유용하게 활용할 수 있다. 100여 대가 되는 것을 한번에 패치하려고 한다고 생각하면 일단 밤샐 각오를 해야 한다. 이런 부분을 SMS가 해주니 편한 기능이라는 것은 사실이다.

 

 

원문 : 아래의 글들을 엮어서 하나의 글로 포스팅하였습니다.

part 1 - 저자 : 이인석_오늘과내일 운영관리팀 대리

http://www.ionthenet.co.kr/newspaper/view.php?idx=9181

http://www.ionthenet.co.kr/newspaper/view.php?idx=9182

part 2 - 저자 : 이인석_오늘과내일 운영관리팀 대리

http://www.ionthenet.co.kr/newspaper/view.php?idx=9372

part 3 - 저자 : 이인석_오늘과내일 운영관리팀 대리

http://www.ionthenet.co.kr/newspaper/view.php?idx=9507

part 4 - 저자 : 이인석_오늘과내일 운영관리팀 대리

http://www.ionthenet.co.kr/newspaper/view.php?idx=9595

http://www.ionthenet.co.kr/newspaper/view.php?idx=9597

part 5- 저자 : 이인석_오늘과내일 운영관리팀 대리

http://www.ionthenet.co.kr/newspaper/view.php?idx=9768

part 6- 저자 : 이인석_아이캔매니지먼트

http://www.ionthenet.co.kr/newspaper/view.php?idx=10008

part 7- 저자 : 이인석_아이캔매니지먼트 운영관리팀 과장

http://www.ionthenet.co.kr/newspaper/view.php?idx=10133

[출처] 윈도우 서버 바로알기|작성자 mybrainz