S.M.A.R.T

Windows Networking

새벽예찬 — Sat, 30 Apr 2011 21:20:27 +0900

단원	장	구분
윈도우 네트워크의 기초	1장. TCP/IP Network	1-1. TCP/IP Protocol의 개요
		1-2. TCP/IP Protocol Suite 1-2-1. Application Layer 1-2-2. Transport Layer 1-2-3. Network Layer 1-2-4. Physical (Network Interface) Layer
		1-3. TCP/IP 통신의 기본흐름
		1-4. Microsoft Network Monitor
	2장. IP Address	2-1. IP Address의 이해
		2-2. IP Addressing
		2-3. Subnet Mask, Default Gateway
		2-4. CIDR (Subnetting,Supernetting), VLSM
	3장. Public Key Infrastructure (PKI)	3-1. 암호화의 역할
		3-2. Symmetric Key (대칭키)
		3-3. Public Key (공용키)
		3-4. Certificate Authority(인증기관)
네트워크 서비스의 이해	4장. DHCP (Dynamic Host Configuration Protocol)	4-1. DHCP의 이해
		4-2. DHCP서버의 구현
		4-3. DHCP Client 구성
		4-4. DHCP의 임대 갱신 과정
		4-5. DHCP의 추가기능
		4-6. DHCP의 확장구현
	5장.DNS (Domain Name System)	5-1. DNS의 이해
		5-2. DNS의 구조 및 프로세스
		5-3. DNS 설치 및 구성
		5-4. DNS Server관리
		5-5. DNS Server 문제해결
		5-6. DNS 기타
	6장. 네트워크에서 컴퓨터 찾기(WINS)	6-1. NetBIOS Network
		6-2. NetBIOS Name 등록, 해제, 요청
		6-3. WINS 설치 및 구성
		6-4. Non- WINS 클라이언트를 위한 설정
		6-5. 최적화된 WINS 서버 구현 방법
		6-6. Lmhosts 파일
	7장. RAS & IAS서버	7-1. 전화접속 서버 (Dial-up Server) 7-1-2. 전화접속 사용자 설정
		7-2. VPN (Virtual Private Network)
		7-3. RAS정책 7-4. 인터넷인증 서버(IAS)
	8장. 인터넷연결공유와 개인네트워크 구축	8-1. 사설 네트워크의 필요성
		8-2. 인터넷 연결 공유 (ICS)
		8-3. Network Address Translation (NAT)
		8-4. NAT 고급기능
		8-5. 안전을 고려한 네트워크 환경
	9장. 인증기관과 전자메일응용	9-1. 인증기관(CA) 서비스
	9장. 인증기관과 전자메일응용	9-2. 전자메일 응용
	10장. 인터넷 서비스	10-1. Internet Information Server (IIS) 10-1-2. 웹서버 기본 설정 10-1-3. 웸사이트 리디렉션 10-1-4. 웹사이트 인증 및 기본 보안 10-1-5. 웹사이트와 가상 디렉터리 10-1-6. 다중 웹사이트 호스팅
		10-2. 보안 웹서버 구현 (SSL서버)
		10-3. FTP Server 구현
		10-4. 안전한 웹서버 운영을 위한 보안지침
윈도우 서버 관리	11장. Windows Server 2003	11-1. Account (계정)
		11-2. 파일시스템과 보안
		11-3. 자원관리 11-3-1. 디스크(Hard Disk) 11-3-2. 레지스트리(Registry) 11-3-3. 이벤트 뷰어 (Event Viewer) 11-3-4. 성능모니터(Performance Monitor)
		11-4. 백업과 복구 11-4-1. 백업 (Backup) 11-4-2. 백업 예약(Schedule Backup) 11-4-3. 복구 (Restore)
		11-5. 문제해결(troubleshooting) 11-5-1. 부트프로세스의 이해 및 문제해결 11-5-2. ERD(응급복구디스크) 11-5-3. F8 옵션의 이해 11-5-4. 복구콘솔의 활용
		11-6. 시스템 유지를 위한 업데이트
		11-7. 시스템 관리를 위한 도구
	12장. 파일, 프린트 서버관리	12-1. 파일서버 구축 및 보안
		12-2. DFS (분산파일시스템)
		12-3. Disk 할당량 관리
		12-4. 프린트서버 구축 및 관리
		12-5. Active Directory 에 공유폴더 게시
기업네트워크와 Active Directory	13장. Active Directory	13-1. Directory Service (Workgroup과 Domain)
		13-2. Active Directory의 개요
		13-3. Active Directory의 구조 및 이름
		13-4. Active Directory 설치
		13-5. Active Directory 관리 13-5-1. 개체생성하기 13-5-2. AD관리-권한 위임 13-5-3. AD관리-사이트(Sites) 13-5-4. 글로벌 카탈로그 서버 (Global Catalog) 13-5-4. FSMO (Flexible Single Master Operations) 13-5-5. Active Directory 제거
	14장. Active Directory 인프라 구축	<시나리오> 윈도우네트웍스(주) Active Directory 14-1. Active Directory 설계
		14-2. 서버 설치 및 구성
		14-3. 그룹정책(Group Policy) 구성
		14-4. Active Directory 클라이언트 되기
		14-5. 맺음말

Secure.pe.kr 안내

새벽예찬 — Tue, 10 Mar 2009 21:44:37 +0900

늘 행복하시고, 건승하시길 바랍니다.
행복하세요..!!!

Microsoft TechNet 칼럼 - 도메인 컨트롤러에 얽힌 에피소드

새벽예찬 — Wed, 14 Jan 2009 08:20:24 +0900

내 자리의 데스크탑은 Windows 2000 advanced server가 인스톨되어 있고, 그 서버는 도메인 컨트롤러로 셋업되어 하나의 도메인을 만들어 내고 있다. 노트북은 그 도메인의 멤버로 설정된 Windows 2000 professional이다.

어느날 문득 노트북의 시계를 확인하니 핸드폰의 시간보다 6분 정도 느린 것을 발견했다. 컴퓨터로 작업을 하다 보면 무의식적으로 모니터의 트레이에 위치한 시계를 통해서 시간을 체크하는 것이 일반적이다.

핸드폰의 시간을 기준으로 시계를 맞추고 나서 작업을 계속했다. 다음날 또 다시 시간이 6분 정도 느려진 것을 알게 됬다.

"왜일까??

노트북 제조회사의 서비스센터에 전화를 하니 아마도 CMOS보조 배터리의 상태가 좋지 않은 듯하다고 기사를 보내겠다고 했다. "아니요.. 오실 필요까지는 없는데.."라고 했지만 극구 직접 방문해서 확인을 해 주겠단다. '음.. 서비스 많이 좋아졌군..^^' 하는 생각을 하고 기다렸다.

제조회사의 기사가 와서 노트북을 분해하기 시작했다. 잠시후.. 어?? 당황하는 빛이 역력했다. 키보드를 뜯어냈는데 있어야 할 배터리가 나오질 않는거다. 잠시후~ 시스템을 분해하지 않았어도 될 위치에서 배터리를 발견했다. 노트북 바닥면의 메모리 확장 슬롯을 장착하는 공간에 배터리가 있었던 것이다. 으흐흐..~ (속으로 ..)
배터리를 빼내고 전압체크를 하더니 뭔가 갸우뚱하는 듯한 인상을 주었고, 어찌됬건 배터리를 교체하고 나서 1시간쯤 지났을까? 이런.. 또 다시 시계가 6분 정도 느려져 있었다. 왜 이럴까?? 하는 순간에

아차.. 하고 스치고 지나가는 생각. 부리나케 데스크탑에서 관리자로 로그온을 했다.

데스크탑의 시계를 확인하니 역시 6분 정도 느린, 지금의 노트북과 일치하는 시간을 확인할 수 있었다. 그랬구나.. 바보였어. 배터리 문제가 아니라 시스템이 정상적으로 동작하고 있었던 결과였던 것을...

노트북 담당기사가 배터리를 교체하고, 꺼낸 배터리의 전압을 체크하고 갸우뚱... 하던 모습이 이해가 되는 순간이었다.

Windows2000의 도메인컨트롤러는 SNTP (Simpel Network Time Protocol)을 이용하여 시스템들의 시간을 동기화시켜주는 기능을 제공한다. Windows2000에서 로그온 하는 클라이언트가 타임스탬프를 이용한 암호화를 통해서 도메인컨트롤러에 사용자정보를 제공하기 때문에 상대적으로 시간정보가 중요하기 때문이다.

이론으로 정리를 하고, Active Directory강의시 이러한 내용들을 강조해서 강의를 하면서도 막상 이런 실수를 하고 말았다. 모든 상황에서 알고 있는 지식이 바로바로 매칭되어 튀어 나올수 있다면 좋을텐데... 하긴, 어쩌한 그러한 순간순간의 해결을 위해서 수백페이지의 책을 읽어야 하는 지도 모를일이다.

글, 송원석 팀장 "(주)필라넷 정보기술팀”

http://technet.microsoft.com/ko-kr/library/cc700736.aspx

우체국 택배 등기 조회

새벽예찬 — Tue, 06 Jan 2009 10:43:37 +0900

http://service.epost.go.kr/iservice/trace/Trace.jsp

태도(attitude)와 능력(ability)

새벽예찬 — Thu, 18 Dec 2008 17:25:34 +0900

한 사람은 능력이 뛰어나지만 태도가 나쁘다. 또 다른 한 사람은 태도는 좋지만 능력은 떨어진다. 이 중 한 명을 해고해야 한다면 누구를 선택하겠는가? CEO라면 누구나 이 같은 딜레마 상황에 빠져봤을 것이다.

만약 GE의 잭 웰치(Welch) 전 회장이라면 어떤 선택을 할까? GE는 사람을 평가할 때 두 가지 요소를 감안한다. 하나는 태도(attitude), 또 다른 하나는 능력(ability)이다. 모든 인사 평가는 이 두 가지 요소의 조합을 통해 이뤄진다. 태도와 능력이 모두 우수한 사람에겐 파격적인 연봉 인상과 승진이 주어진다. 일반적으로 이들의 비율은 전체 직원의 20% 정도다. 반면 태도와 능력이 모두 떨어지는 10%에겐 차가운 해고 통지서가 날아든다.

문제는 둘 중 하나가 모자라는 직원을 처리하는 방법이다. 웰치 전 회장의 원칙은 간단하다. 능력이 떨어지는 직원에겐 보직 이동을 통해서 한번 더 기회를 준다. 하지만 태도가 나쁜 직원은 해고의 수순을 밟는다. 지금 당장 성과를 낼지는 몰라도 장기적 관점에서 봤을 때 조직의 문화를 파괴할 위험이 있다는 게 그의 판단이다. 여기서 말하는 태도란 '얼마나 상사의 말을 잘 따르는가' 등과 같은 문제가 아니다. '얼마나 회사가 중요하게 생각하는 가치를 지키느냐','얼마나 열정을 갖고 일하느냐' 등과 같은 조직의 문화와 관련된 것이다. 다시 세계상사의 회의실로 돌아가 보자.

검은 고양이든, 흰 고양이든 쥐만 잘 잡으면 나머지는 관용할 수 있는 것일까? 나 사장은 한 가지를 깊게 생각해 봐야 한다. '혹시 색깔 다른 고양이 한 마리가 우리 조직의 문화와 가치를 흐리거나 망치고 있지는 않는가?' 만약 '예스'라고 생각된다면 이때는 과감한 결단(해고)이 필요하다. 그대로 뒀다간 이 고양이는

쥐만 잘 잡는 게 아니라 우리 조직도 '잡아먹을' 수 있기 때문이다.

[출처] 조선일보 土日섹션경제 2008년 6월 14-15일 C3페이지, 최철규 IGM(세계경영연구원)부원장의 글 인용

윈도우 서버 2003 터미널 서비스 응용

새벽예찬 — Mon, 01 Dec 2008 05:56:58 +0900

터미널서비스를 단순히 관리 용도로만 사용한다면 특별한 설정이 필요없다. 몇가지 추가기능들을 고려해 보고자 한다. 원격제어기능, 어플리케이션 서버기능 등이 그것이다.

(1)원격 제어

당신이 회사의 고객지원부서에 근무하는 담당자라고 가정해 보자. 회사의 사용자는 오피스2000의 새로운 기능에 대해서 묻고 싶어한다. 당신은 전화상으로 사용방법에 대해서 설명할 것이다. "도구메뉴에 보면 옵션이 있죠? 그걸 열고.. 어쩌고 저쩌고... " 기껏 설명을 했더니 잘 모르겠다고 한다. 또 다시 설명하고, 스트레스는 있는 대로 받고.. 이럴 때 터미널 서비스의 원격제어 기능은 아주 유용하다. 한가지 예제일 뿐이다. 이것을 효율적으로 응용하는 것은 여러분에게 달려있다.

예제에서는 192.168.2.200 IP Address를 사용하는 터미널서버가 있다. 당신은 tsuser2 계정을 사용한다. tsuser1이라는 계정을 사용하는 사용자가 회사에서 새롭게 도입한 프로그램의 기능을 묻고 있는데 직접 프로그램을 띄운 상태에서 설명하고 싶다. 다음과 같은 절차를 통해서 원격제어로 접근해 보자.

① tsuser1에게 터미널 서버로 접속하도록 요청한다.

<화면1. tsuser1 클라이언트 접속>

② 자신도 tsuser1이 접속한 터미널 서버에 tsuser2계정으로 접속한다.

<화면2. tsuser2 클라이언트 접속>

아래의 <화면3>에서는 이해를 돕기 위해 한 컴퓨터에서 두 개의 터미널 서비스 클라이언트 창을 띄워서 각각 tsuser1, tsuser2로서 로그온한 화면을 보여준다. 화면에서 아래의 창은 tsuser1, 위의 창은 당신이 로그온한 tsuser2이다.

③ 터미널 서비스 클라이언트를 이용해 접속한 상태에서 터미널 창안에서 "시작-관리도구-터미널 서비스 관리자"를 연다. 관리콘솔의 오른쪽을 보면 현재 서버에 로그온 한 사용자의 리스트를 볼 수 있다. tsuser1과 tsuser2, wssong이 보인다. 여기서 wssong은 현재 터미널서버에 로컬로 로그온한 사용자를 보여준다. 터미널 클라이언트는 tsuser1과 tsuser2 두명이 있다. 원격제어를 원하는 tsuser1을 클릭하고 마우스 오른쪽 단추를 눌러 "원격제어"를 클릭한다.

<화면3. 원격제어 요청 >

④ 원격제어 세션을 끝낼 때 사용할 단축키를 선택한다. 예제에서는 [Ctrl]+[Tab]을 선택했다.

<화면4.원격제어 단축키 선택>

⑤ 확인버튼을 누르면 tsuser1이 로그온한 화면에서는 <화면5>의 아래창에서 보는 것처럼 "원격 제어 요청"메시지를 받게 된다. 읽어보니 tsuser2이 원격제어 요청을 하고 있으니 수락하겠느냐?는 메시지이다. 당연히 클라이언트쪽에서 [예]를 선택해야 한다.

<화면5. 원격제어 요청 메시지>

⑥ 상대방이 '원격제어요청'을 허용해 주면 아래의 <화면6>에서 볼 수 있듯이 양쪽의 터미널 창에 동일한 화면을 보여주게 된다. tsuser1이 터미널 서버에 로그온한 세션을 공통으로 사용하도록 설정이 되었다.

<화면6. 원격제어 연결 >

⑦ 한쪽에서 프로그램을 띄운다거나, 텍스트를 입력하는 등의 모든 작업은 다른 터미널 창에서도 반영이 된다. 결국 하나의 세션이 양쪽의 터미널 창을 통해서 보여지도록 허용이 되는 것을 의미한다.

<화면7. 원격제어 테스트>

지금까지 한가지 예제를 들어서 원격제어를 구현해 보았다. 응용하는 것은 각자의 할 일이다. 만일 터미널 서비스 사용자의 동의없이 사용자의 세션에 참여하고 싶다면 어떻게 할까? 그렇다면 그 사용자가 터미널 서버에 접속해서 무슨 일을 하는지를 들여다 볼 수 있을텐데, 역시 옵션이 제공된다. "관리도구-터미널 서비스 구성"을 열어서 "연결- RDP-TCP"의 등록정보를 클릭한다.<화면8>

<화면8. 터미널 서비스 구성>

원격제어 탭에서 "사용자의 허가 필요"체크박스의 체크를 해제하고 나면 상대방의 동의 없이 원격제어가 가능해진다. 어떤 용도로 사용할 수 있을까?

<화면9. 터미널 서비스 구성 - 등록정보 수정>

(2)어플리케이션 서버 구현

또 다른 용도를 고려해 보자. 회사에서 업무상 필요한 어플리케이션이 Windows2000환경에서만 작동한다면 어떻게 할까? 당연히 모든 클라이언트들은 Windows2000으로 업그레이드를 해야 할 것이다. 또, 모든 사용자가 그 어플리케이션을 사용해야 한다면 사용자들의 시스템마다 해당 어플리케이션을 설치해야 할 것이고, 당연히 회사는 적절한 라이센스를 확보해야만 법적인 대항력을 확보할 수 있게 된다. 다른 방법은 없을까? 이런 경우에 Windows2000 터미널 서비스는 역시 해결책이 될 수 있다. 터미널서버에 어플리케이션을 설치하고 사용자들이 그 어플리케이션을 쓰기 위해서 터미널서버로 로그인을 하면 된다. 하지만 터미널 클라이언트들에게 주어진 어플리케이션 이외의 프로그램에는 접근하지 못하도록 제한을 두고 싶다면 다음과 같은 방법을 고려한다.

먼저 클라이언트 연결관리자를 통해서 터미널 클라이언트 연결을 하나 만들어보자. "시작-프로그램-터미널 서비스 클라이언트-클라이언트 연결관리자"를 실행한다.<화면10>

< 화면10. 터미널 서비스 클라이언트 연결 관리자 >

파일메뉴 아래의 버튼을 이용하여 마법사를 시작한다.<화면11>

< 화면11. 클라이언트 연결 관리자 마법사 >

연결 이름을 적절히 입력하고 서버이름 항목에는 터미널 서버의 FQDN형태의 호스트이름이나 IP Address를 입력하고 [다음]을 누른다.<화면12>

< 화면12. 연결 만들기 >

로그온 정보를 입력한다. 터미널서버에 접속할 때 제시할 사용자이름과 암호, 그리고 도메인 이름을 입력한다. <화면13> "이 정보를 사용하여 자동으로 로그온"옵션을 체크하였다.

< 화면13. 로그온 정보 입력 >

화면옵션에서 터미널 서버에 연결했을 때의 해상도를 설정한다. 전체화면 모드에서 보기를 원한다면 "전체화면"옵션에도 체크해 준다.<화면14>

< 화면14. 해상도 설정 >

연결등록정보 항목에서는 느린 네트워크에서의 효율적인 전송을 위해서 "데이터 압축 사용"을 하거나 "비트맵 캐싱" 옵션을 사용하여 성능을 향상시킬 수도 있다.<화면15>

< 화면15. 클라이언트 연결 관리자 마법사 - 연결 등록 정보 >

지금 생성하는 연결이 실행할 프로그램을 지정한다. 서버에서 실행될 것이므로 서버에서 해당 프로그램을 실행하기 위한 경로를 입력한다. 단축아이콘을 생성하면 경로를 쉽게 알 수 있다. 예제에서는 인터넷 익스플로러를 실행할 경로를 입력하였다. <화면16>

< 화면16. 프로그램 시작 경로 등록 >

아이콘을 적절히 변경하고 이 연결을 등록할 프로그램 그룹을 등록한다.<화면17>

< 화면17. 아이콘 변경 >

연결 관리자 마법사를 완료한다.<화면18>

< 화면18. 클라이언트 연결 관리자 마법사 완료 >

클라이언트 연결관리자에 "터미널 서버 엑셀"이라는 아이콘이 생성되었다. 프로그램은 인터넷 익스플로러를 실행할 건데 왜 이름이 "엑셀"이냐구? 내맘이다.<화면19>

< 화면19. 클라이언트 연결 관리자에 추가된 형태 >

이제 클라이언트는 준비가 되었다. <화면13>에서 클라이언트가 로그온 할 때 사용할 정보를 제공하였지만 실제로 테스트를 해 보면 여전히 터미널 서버는 클라이언트에게 계정정보를 새롭게 요구하게 된다. 서버의 기본설정이 항상 로그온 정보를 묻도록 되어 있기 때문이다. 터미널 서버에서 이것을 해제해 보자.

관리도구-터미널 서비스 구성을 열고 연결-RDP-Tcp의 등록정보를 연다.<화면20>

< 화면20. 터미널 서비스 구성 관리도구 >

로그온 설정 탭을 열면 "항상 암호 묻기"라는 옵션이 체크되어 있음을 알 수 있다. 해제한다. "항상 다음 로그온 정보 사용"이라는 옵션을 활성화시키면 이 터미널 서버에 접근하는 사용자는 서버가 설정한 계정으로서 터미널 서버에 연결을 하는 형태가 된다. 터미널 클라이언트에게 계정정보를 요구하지 않도록 할 때 사용되는 옵션이다. <화면21>

< 화면21. RDP-Tcp 등록정보 >

이제 설정을 마쳤다. 터미널 서버에 연결해서 결과를 테스틑 해보자. 터미널 연결 관리자를 통해서 만든 연결을 클릭하면 아래의 <화면22>의 결과를 얻을 수 있다. 로그온이 됨과 동시에 터미널 클라이언트는 인터넷 익스플로러가 실행되는 것을 볼 수 있다. 그 외에 어떠한 작업도 할 수가 없다. 만일 클라이언트가 인터넷 익스플로러를 마친다면 터미널 연결까지 끊기게 된다. 터미널 서버를 어플리케이션 서버 용도로 제대로 구현할 수 있는 방법이라고 하겠다.

<화면22. 터미널 서버에 연결된 화면 >

TCP Window Size의 크기에 따른 영향

새벽예찬 — Mon, 01 Dec 2008 05:41:56 +0900

앞에서 우리는 TCP Sliding Window 에 대해서 알아 보았다. 그러면, 이러한 TCP Window라고 하는 것의 Size의 크기 여부가 네트워크에서 가지는 영향에 대해서 정리를 해 보도록 한다.먼저 정리를 해 보면, NT는 "Window size"는 8K, "Segment Size"는 1K로 설정이 되어 있다. 물론 NT의 Registry를 편집함으로써 수정은 가능하지만 권장하지는 않는다. 이미 우리의 선배들이 시행착오를 거쳐서 최적의 size로서 설정이 되어 있기 때문에 우리는 그러한 문제를 고민하는 것보다는 효율적으로 운영하는데 초점을 두는 것이 바람직하겠다. window size가 너무 작을 경우와 너무 클 경우 어떠한 일이 생길 것인지 알아보자.

(1) Window size가 작은 경우 [그림1~3]

[그림1]

Window size가 1K라고 가정을 해 보면 어떻게 될까? 이제 앞에서 보았던 전송과 응답과정을 이해했다면 금방 알 수 있는 문제다.송신측의 컴퓨터는 1K의 데이터를 전송하고 그것에 대한 응답을 기다릴 것이다. Ack신호가 오면 그 다음 차례인 2번으로 window를 sliding시켜서 또 전송을 시작할 것이다.

하나를 보내고 하나를 받고, 좋아 보이지만 답답한 방법이 아닐 수 없다.

[그림2]

[그림3]

(2) Window size가 큰 경우

Window size가 크다 혹은 작다는 것은 상대적인 개념이다. 네트워크가 얼마나 안정적이며, 또 LAN에서의 통신인지 WAN에서의 통신인지에 따라서 달라질 것이다. 또, WAN구간이라고 할 지라도 56K의 모뎀을 이용하는지 아니면 T3의 빠른 회선을 이용하는 지에 따라서 달라질 수 있다.예제를 통해서 느린 네트워크에서 window size가 큰 경우의 문제를 알아보도록 하자.[그림4]에서는 8K의 window size를 사용하고 있다. 하지만, 문제는 네트워크가 느리다는 데 있다. 속도가 느려서 혹은 트래픽이 많아서 기대되는 응답시간보다 더 오랜시간이 걸려야만 Ack신호를 받을 수 있다고 한다면, 결국엔 송신측 컴퓨터는 미처 Ack신호를 받지 못하고 "Retransmission Timer"의 시간이 만료되어 같은 데이터를 재전송해야 하는 일이 많아지게 될 것이다. 당연히 비효율적인 네트워크가 운영이 될 것이다..

[그림4]

이런 경우라면 오히려 window size를 보다 작은 size로 줄이는 것이 현명한 방법일 것이다. 위의 2가지 예제의 경우에 TCP는 "Connection Oriented protocol"이라는 가장 큰 장점이 오히려 적절하지 못한 window size로 인해서 비효율적인 Protocol이 될 수도 있다. 적절한 window size를 사용하게 된다면 TCP의 장점을 극대화한 최적의 네트워크를 구성하게 될 것이다.

TCP Sliding Window

새벽예찬 — Mon, 01 Dec 2008 05:38:08 +0900

TCP/IP Protocol Suite중의 하나인 TCP는 TCP Host간에 효율적인 데이터 전송을 위하여 "Window"라고 부르는 Buffer를 이용한다. Window는 TCP/IP통신을 원하는 컴퓨터(일반적으로 Host라고 부른다)가 송신, 혹은 수신할 수 있는 size를 가리켜 준다.

이러한 window라는 것을 이용하여 호스트간에 전송을 하고 받는 과정중에, 네트워크의 트래픽 혹은 호스트의 불안한 요소등 여러 가지 원인에 의하여 전송되는 데이터의 손실이 생길 수 있는 경우가 발생하게 된다. 반대로 안정적인 네트워크 상황하에서 보다 많은 데이터를 전송할 수 있음에도 TCP가 제공하는 가장 큰 특징중의 하나인 "확실한 전송"이라는 책임 때문에 오히려 비효율적인 전송을 하게 되는 경우도 있게 될 것이다. 이러한 요소들을 모두 고려하여 가장 효율적인 데이터 전송방법으로써 "Sliding Windows" 라는 기법을 사용하여 호스트 간의 통신에서 최적의 성능을 제공할 수 있게 된다.

그러면, 실제로 호스트간의 TCP/IP통신 중에서 "TCP Sliding windows"라는 기법이 무엇인지, 어떻게 동작을 하는지 차근차근 접근해 보도록 하자.

[그림1]

TCP/IP를 사용하는 모든 호스트들은 각각 2개의 window를 가지고 있다. 하나는 보내기 위한 window, 또 다른 하나는 받기 위한 Window이다.

[그림2]

호스트들은 실제 데이터를 보내기 전에 먼저 "TCP 3-way handshaking"을 통하여 수신컴퓨터의 receive window size에 자신의 send window size를 맞추게 된다. 상대방이 받을 수 있는 크기에 맞추어 전송을 하겠다는 것이다.

[그림2]의 "A"컴퓨터가 "B"컴퓨터에게 10K byte size의 데이터를 전송하려 한다고 가정을 해 보자.또, 이 컴퓨터의 "window size"는 8K이고, "TCP Segment Size"는 1K라고 가정을 한다. 사실 이것은 우리가 가장 많이 사용하는 Ethernet환경에 최적화된 size이기 때문에 NT는 기본적으로 위와 같은 windows와 segment size를 이용한다."TCP Segment Size"는 Application이 만든 데이터를 TCP가 받아서 IP에게 전달해서 통신을 하려고 할 때, IP에게 전달해 주는 데이터 패킷의 크기이다. 결과적으로는 실제 데이터를 TCP가 보다 작은 크기로 나누게 되는데, 이 때 나누게 되는 크기를 가리켜서 "TCP Segment Size"라고 부른다.예제의 경우와 같을 때, "A"컴퓨터는 "B"컴퓨터에게 데이터를 전송하기 위해서 먼저 10K크기의 데이터를 1K크기로 나누게 된다. 당연히 10개의 패킷으로 데이터가 나뉘게 될 것이다. TCP는 1K로 나눈 데이터마다 순서를 붙이게 된다. 1번부터 10번까지 번호를 붙이고, 1번부터 데이터 전송을 시작하게 된다.

TCP의 특징은 "신뢰성있는 전송"을 보장한다는 데 있다. 1번을 보내고, "A"컴퓨터는 "B"컴퓨터로부터 잘 받았다는 확인 메시지(Acknowledgement)를 받을 때까지 기다리게 된다. 마침내 Acknowledgement 메시지가 오면 "A"컴퓨터는 그 다음 순서인 2번 데이터를 전송한다. 생각하기에는 당연한 이야기고 그런대로 쓸 만한 방법이라고 생각할 수도 있겠지만 지극히 비효율적인 방법이다. "A"컴퓨터는 1번 데이터를 보내고 나서도 충분히 다음 데이터를 보낼 여유가 있지만, 응답을 받을 때까지 기다리고만 있어야 한다는 것이다. 만일 회선상의 문제가 있어서 Ack신호가 더욱 지연된다면 그 결과는 당연히 영 아닌 상태의 네트워크 통신을 지켜 봐야만 할 것이다. 이러한 문제점을 해결하기 위해서 TCP는 데이터를 낱개단위로만 처리하지는 않는다는 것이며, 그때 한꺼번에 전송하는 데이터의 크기를 바로 "Window Size"라고 부르는 것이다.

[그림4]

[그림4]처럼 호스트는 자신이 보내야할 전체 데이터 중에서 사용가능한 Window size만큼 데이터를 전송하기 시작한다. 위의 예제에서 window size는 8K이다. 1번부터 8번까지 순차적으로 계속해서 데이터를 내 보내게 되는 것이다. 그리고 나서 이 호스트는 상대방의 응답을 기다리게 된다. 단순하게 생각해도 일단은 하나씩 보내고 응답을 기다리는 것보다는 효율적인 방법일 것이다. 성공적으로 통신이 되어서 상대방으로부터 응답이 온다면 그때 "A"호스트는 나머지 남은 9번, 10번의 데이터를 전송한다.이것이 "TCP Sliding Windows"라는 기법이다. window size만큼 데이터를 전송하고, 상대방으로부터 Ack신호가 올 때까지 기다렸다가 Ack신호가 오면, window를 이동(Slide)시켜 다음 순서의 TCP데이터를 전송하는 방식을 말한다.

하지만, 역시 이것만으로는 뭔가 비효율적인 면이 여전히 남아있다. 1번부터 8번까지 데이터를 전송하고 상대방으로부터 1번부터 시작하여 자신이 보낸 데이터의 마지막인 8번까지의 데이터에 대한 Ack신호가 올 때까지 기다려야 한다면 어리석은 일이 아닐 수 없다. 우리가 생각하는 정도는 이미 TCP/IP를 개발한 개발자들도 충분히 고려했던 부분이었기에 그것에 대한 생각도 물론 했을 것이다. 그렇기 때문에 보다 효율적인 방법을 채택했다.

[그림 5]

일단 보내는 쪽의 TCP는 window size만큼 한꺼번에 데이터를 전송하고, 받는 쪽에서의 Ack신호가 오면 오는대로 바로바로 window를 Sliding시키는 방법이 그것이다. 다시 말하면 굳이 자신이 발송한 마지막 데이터에 대한 Ack신호가 오지 않더라고 일단 그 전의 데이터에 대한 Ack가 오게 되면 그만큼은 여분의 window size가 생긴 것이기 때문에 추가로 더 전송할 여유가 생겼다는 의미이다.

[그림 5]에서 보면 window가 이동한 그림을 볼 수 있다.예제의 경우는 받는 쪽에서 2번까지의 데이터를 잘 받았다는 Ack신호를 발송해 주게 되면 그때 "A"컴퓨터는 1,2번 데이터는 제대로 전송해야 할 책임을 완수했기 때문에 window를 이동시켜서 그 다음 순서의 데이터인 9번과 10번을 전송할 수가 있게 되었다. 추가로, 받는 측인 "B"컴퓨터는 패킷 하나마다 계속해서 Ack신호를 전송한다는 것은 역시 그것도 하나의 트래픽을 발생시키는 것이기에 약속을 해 두었다. 적어도 2개 이상의 연속된 패킷이 들어왔을 때 Ack신호를 전송하도록 한 것이 그것이다.

[그림6]

[그림6]에서처럼 1번과 3번 패킷이 도착을 했지만, 중간에 이빨이 빠진 채로 2번이 아직 도착을 하지 않았다라고 가정을 해 보자. 그렇게 되면, 받는 측의 TCP는 2개이상의 연속된 패킷이 도착하면 전송을 하자는 약속을 해 두었기에 마냥 기다려야 할 것이다.

그래서 만일의 경우를 대비하여 한가지 해결책을 강구해 두었다. 받는 측의 컴퓨터는 패킷이 도착하였을 때, "Delay Acknowledgement Timer"라고 부르는 Timer를 설치하게 된다. 이 Timer의 시간이 만료될 때까지 2번 패킷이 도착하지 않는다면, 받은 1번 패킷에 대한 Ack신호만이라도 전송을 해 주는 것이 보다 효율적이기 때문이다.

[그림7]에서 보면, 받는 측의 TCP는 1번 패킷에 설치해 둔 Timer가 만료되었고, Ack신호를 전송하고 있다.

[그림 7]

송신컴퓨터는 이렇게 수신컴퓨터의 Ack신호를 받고, window를 sliding시켜서 다음 신호를 전송하는 방식을 쓰고 있지만, 또 한가지 문제가 여전히 남아 있다. 만일 무슨 이유에선지 Ack신호가 전혀 오지 않는 상황이라면 어떻게 해야 할까? 이러한 문제를 해결하기 위해서 송신컴퓨터의 TCP는 자신이 보낼 수 있는 Window Size만큼 데이터를 전송하고 자신이 보낸 데이터에 대해서 각 Segment마다 "Retransmission Timer"라고 불리우는 timer를 설치 해 둔다. 만일 이 timer의 시간이 만료될 때까지 Ack신호가 도착하지 않으면 재전송을 하기 위한 배려이다.

[그림 8]

결국, TCP는 window size를 이용해서 한꺼번에 일정량의 데이터를 전송하며, 보다 효율을 기하기 위해서 이러한 window를 Sliding시키는 방식을 이용하여 계속적인 데이터 전송을 할 수 있도록 하고 있다. 여기에서 생길 수 있는 문제점들을 "Delay Acknowledgement Timer"와 "Retransmission Timer"를 이용해서 대비책을 마련해 두고 있는 것이다.

이상 TCP Sliding windows에 대해서 정리해 보았다. 다음엔 이어서 TCP Window Size가 네트워크에 미치는 Performance에 대해서 알아보도록 하자.

Exchange Server 2000 - Multi Domain 구성

새벽예찬 — Sat, 29 Nov 2008 10:30:08 +0900

Exchange Server 2000은 이전의 5.5버전과는 달리 Active Directory와 완전한 통합을 이루었다. Exchange Server자신이 별도의 디렉터리 데이터베이스를 가지지 않는다는 것을 의미한다. 예제의 상황을 가정하여 하나의 Exchange Server에서 여러개의 도메인의 메일서비스를 하도록 구성해 보도록 한다. Exchange Server 2000을 이용해서 여러개의 도메인에 대한 메일호스팅을 한다고 가정하면 맞겠다.

<시나리오> Secure.pe.kr 이라는 회사는 Secure.pe.kr 이라는 이름의 Windows 2000 Domain을 구성하였으며 Exchange Server 2000을 사용하여 메일서비스를 하고 있다. 이 하나의 Exchange Server 를 이용해서 mscs.co.kr 이라는 도메인의 메일서비스를 제공하도록 구성하기를 원한다. 어떻게 구성해야 할까?

<해결>

다음과 같은 순서로 구성한다.
1.DNS Zone 구성 - MX레코드 생성
2.Active Directory에서 OU생성
3.ADSI Edit를 이용하여 UPN Suffix 추가
4.Exchange Server - Recipient Policy생성
5.사용자 계정 생성

구성과정이 꽤 까다롭게 느껴질수 있지만 차근차근 제대로 구현을 해 보자.

DNS구성에 대해서는 여기에서 설명하지 않는다. 당연히 구성이 되었다고 가정하고 다음 작업부터 진행한다. DNS구성에 대해서 알고 싶다면 강의실의 'DNS'섹션을 참고하라. 먼저 Secure.pe.kr의 Active Directory에 mscs.co.kr의 사용자를 구분하여 별도로 관리하도록 OU를 하나 생성해 보자. 'Active Directory 사용자 및 컴퓨터'관리도구를 열고 왼쪽패널에서 도메인이름을 마우스 오른쪽 클릭한후 '새로 만들기'에서 '조직단위(OU)'를 선택한다.

<그림1> 새로운 OU 생성

<그림1>에서는 mscs.co.kr이라는 도메인의 사용자를 관리하기 위해 'MSCS'라는 이름의 OU를 생성하고 있다.

다음에 해야 할 작업은 Secure.pe.kr 도메인에서 mscs.co.kr 도메인 이름을 사용할 수 있도록 User Principal Name (UPN) 접미사를 추가하는 작업을 한다. 'Active Directory 사용자 및 컴퓨터'관리콘솔을 이용할 수도 있지만 그것은 도메인의 모든 사용자들에게 해당되는 작업이 되니 그것보다는 새로 생성한 'MSCS' OU에만 적용될 수 있도록 구성하는 것이 바람직하다. 이 작업은 ADSI에디터를 통해서 접근해야 한다.

Win2K 원본CD의 support-tools 폴더에 있는 셋업파일을 이용해서 Windows 2000 Support tools를 설치한다. 설치를 마치면 프로그램메뉴에 등록된 Support tool을 찾을 수 있고 거기에서 adsiedit 라는 관리도구를 확인할 수 있다. 못 찾겠으면 시작-실행 창에서 "adsiedit.msc"라고 입력해 본다.

ADSI에디터를 실행한 다음, Domain NC를 확장하고 "OU=MSCS"라는 폴더를 클릭한다음 등록정보를 연다.

<그림2> ADSI Editor

<그림3> ADSI Editor - 속성편집

Attributes 탭을 열고, 'Select a property to view' 항목에서 'uPNSuffixes'를 선택한다. 'Attribute Values'에서 Edit Attribute박스에 'mscs.co.kr'이라고 입력하고 [Add]버튼을 클릭한다. 아래의 <그림4>와 같이 구성하였다.

<그림4> ADSI Editor - uPN접미사 추가

다음에 Exchange Server를 구성하기 위해 Exchange System Manager 관리도구를 연다.

<그림5> Exchange System Manager - Recipient Policy 추가 1

Recipients를 확장하고 Recipient Policies를 마우스 오른쪽 클릭하여 '새로 만들기'를 선택하고 'Recipient Policy'를 클릭한다. New Policy 화면이 나오면 'E-Mail Address'를 선택하고 [OK]를 누른다.

<그림6> Exchange System Manager - Recipient Policy 추가 2

정책을 구성해야 한다. Name에 "MSCS사용자"라고 입력하고 [Modify]버튼을 클릭한다.

<그림7> Exchange System Manager - Recipient Policy 추가 3

<그림7>에서 '고급'탭을 연다.

<그림8> Exchange System Manager - Recipient Policy 추가 4

'필드'를 선택하고 '사용자'를 클릭한후 '로그온 이름'을 찾아서 선택한다.

<그림9> Exchange System Manager - Recipient Policy 추가 5

선택이 되면 '값'항목에는 'mscs.co.kr'이라고 입력한후 [추가]버튼을 누른다. 그렇게 해서 아래의 <그림10>과 같이 구성을 마친다.

<그림10> Exchange System Manager - Recipient Policy 추가 6

[확인]버튼을 누르면 기존에 있던 사용자에 대해서 새로운 정책을 적용시킬 수 있도록 'Apply this policy now'를 이용하라는 메시지를 보여준다. [확인]버튼을 누른다.

<그림11> Exchange System Manager - Recipient Policy 추가 7

Filter Rules를 보면 -_- 복잡한 필터가 생긴것을 확인할 수 있다. 자세히 보면 볼 수록 머리가 아프다. 넘어가자.

<그림12> Exchange System Manager - Recipient Policy 추가 8

같은 화면에서 이번엔 두번째 탭인 'E-Mail Addresses (Policy)'를 클릭한다.

<그림13> Exchange System Manager - Recipient Policy 추가 9

New E-mail Address 화면에서 'SMTP Address'를 선택하고 [OK]를 누른다.

<그림14> Exchange System Manager - Recipient Policy 추가 10

Address Editbox에 "@mscs.co.kr"이라고 입력했다. [확인]을 눌러서 창을 닫으면 'Generation rules'항목에 @mscs.co.kr이라는 SMTP주소가 추가된 것을 볼 수 있다. @secure.pe.kr의 SMTP를 [Remove]버튼을 이용하여 제거하고 아래의 <그림15>와 같이 보이도록 구성한다.

<그림15> Exchange System Manager - Recipient Policy 추가 11

[확인]버튼을 누르면 아래의 메시지가 팝업된다. [예]를 선택한다.

<그림16> Exchange System Manager - Recipient Policy 추가 12

<그림17> Exchange System Manager - Recipient Policy 추가 13

<그림17>에서는 Recipient policy가 생성된 화면을 보여준다.

이번에는 Active Directory에 새로운 사용자를 생성해 보자. Active Directory사용자 및 컴퓨터 관리콘솔을 열고, MSCS OU를 선택한 다음 마우스 오른쪽 클릭하여 '새로 만들기' '사용자'를 선택한다.

<그림18> 새로운 사용자 계정 추가 1

예제에서는 "송용하"라는 사용자를 추가하고 있다.

<그림19> 새로운 사용자 계정 추가 2

그림에서 '사용자 로그온 이름'항목에서 UPN접미사로 @mscs.co.kr이 나오는 것을 주목하자. 이것은 Exchange Server의 설정과는 무관하고, ADSI Edit를 통하여 MSCS OU의 uPNSuffixes 속성을 수정했기 때문에 나오는 결과이다. [다음]을 눌러서 암호와 관련된 설정을 하고 [다음]을 누르면 Exchange작업을 위한 화면이 열린다.

<그림20> 새로운 사용자 계정 추가 3

<그림21> 새로운 사용자 계정 추가 4

기본설정을 그대로 두고 진행한다. <그림21>을 확인하면 사용자의 로그온 이름이 yhsong@mscs.co.kr 로 되어 있음을 확인한다.

여기까지 구성하면 기본적인 구성이 완료되었다.

추가로 @mscs.co.kr 사용자가 OWA(Outlook Web Access)를 이용하여 웹인터페이스를 통한 메일서비스를 받을 수 있도록 구성하기 위해서 추가설정을 해 본다.

<그림22> OWA를 위한 구성 1

Exchange System Manager를 열고 Servers-서버이름-Protocols-HTTP-Exchange Virtual Server를 차례대로 연다. Exchange Virtual Server를 마우스 오른쪽 클릭하고 '새로만들기-Virtual Directory'를 클릭한다.

<그림23> OWA를 위한 구성 2

General탭에서 Name항목에 'MSCS'라고 입력하고 'Exchange Path'항목을 <그림23>과 같이 구성했다. 이 이름은 IIS의 웹사이트에 가상 디렉터리로 사용될 이름에 해당된다.

이제 모든 구성을 마쳤다. 웹브라우저를 실행하고 http://mail.mscs.co.kr/mscs 라고 입력하니 사용자인증을 요구한다. yhsong과 올바른 암호를 입력하면 아래의 <그림24>에서와 같이 OWA로 접속한 화면을 보여준다.

<그림24> OWA를 통해서 접속한 사용자

DNS 라운드 로빈 구성

새벽예찬 — Sat, 29 Nov 2008 10:25:51 +0900

회사에서 웹서버를 한대 운영하고 있다고 가정하자. 동시접속자들의 계속적인 증가로 인한 서버의 응답력의 저하로 서버의 업그레이드를 고려하고 있다. 서버의 업그레이드만이 최선의 방법일까? CPU가 너무 느려서 사용자들의 요청을 제대로 처리할 수 없다거나 메모리의 부족으로 혹은 하드디스크의 느린 속도로 인해서 고민중이라면 서버의 업그레이드가 고민의 일부분은 해소할 수 있겠지만, 한대의 서버로만 완전한 해결책을 제시하기는 한계가 있기 마련이다.

다른 방법은 무엇일까? 당연히 서버를 중복해서 배치하는 것을 고려할 수 있다. 한대보다는 두대가 있어서 사용자들의 요청을 처리한다면 서버의 분산을 통해서 서버의 응답력은 분명히 향상을 가져올 수 있을 것이기 때문이다.

당신은 결국 웹서버 한대를 더 설치하기로 결정했다. 2대의 웹서버. 이들을 어떻게 구성하여야 최선의 선택이 될까? 이제 새로운 고민이 시작된다. 지금 현재 당신이 웹서버를 한대 더 추가하고자 하는데 정확한 필요성을 먼저 판단해 보라. 웹서버의 성능을 높여주기 위함인지, 아니면 한대의 서버가 다운되었을때 또 다른 웹서버를 통해서 계속 서비스를 할 수 있도록 하기 위함인지..

몇가지 방법이 있다. 막연하게 생각할 수 있는 한가지는 요즘 주변에서 심심찮게 들리는 "클러스터"를 생각할 지도 모르겠다. 클러스터는 훌륭한 솔루션인 것임에는 틀림없다. 하지만 좋은 솔루션인 만큼 요구조건도 상대적으로 까다로운 편인데, 몇가지 살펴본다면 Windows 2000에서 제공하는 클러스터로 구현하기 위해서는 OS가 Windows 2000 Advanced Server이상이어야 한다는 것이고, 물리적인 환경으로 보자면 같은 네트워크에 위치해 있어야 한다는 점 등의 제약사항을 들 수 있겠다. 또 다른 솔루션을 찾아보면 "로드밸런싱" 디바이스들을 들 수가 있겠지만 무엇보다 만만치 않은 비용이 들어가야 한다.

간단하게 구현할 수 있는 방법은 없을까? 그러한 관리자라면 DNS에서 한가지 방법을 찾을 수 있다. DNS로써 구현하는 방법은 완전한 솔루션은 아니지만 가장 손쉽고 경제적으로 클라이언트의 웹서버로의 요청을 분산시킬수 있는 방법을 제공한다.

DNS가 어떻게? 개념은 너무 단순하다. 웹서버가 아무리 잘 셋팅되어 있어도 DNS가 웹서버의 위치(IP Address)를 가르쳐 주지 않으면 클라이언트들은 웹서버에 접근할 수 없다. 웹서버가 두대라면? DNS가 클라이언트의 웹서버의 IP를 요청하는 쿼리를 받을때마다 2대의 웹서버를 번갈아가면서 가르쳐줄 수 있다면 당연히 클라이언트의 요청은 분산이 되지 않을까?

이러한 기능을 DNS의 라운드로빈(Round robin)기능이라고 하고 Windows 2000의 DNS서버는 기본적으로 라운드 로빈이 활성화되어 있다. 관리자는 적절하게 관리영역에 호스트레코드만 생성하여 주면 된다.

아래의 예제를 통해서 접근해 본다. <그림1>에서는 mscs.co.kr이라는 도메인에 www 레코드가 2개 생성되어 있고 각각 192.168.0.2와 192.168.0.3 이라는 IP Address가 설정되어 있음을 보여준다.

< 그림1. DNS호스트 레코드 생성 >

두대의 웹서버를 <그림1>과 같이 DNS레코드를 구성한다. 반드시 A레코드를 사용해야 한다. CNAME은 동일한 이름의 레코드를 여러개 구성할 수 없다.

이제 구성은 끝났다.
에게?? 벌써?? 위에서 얘기한바 있다. 가장 간단하게 구성할 수 있는 방법이라고. 기본적으로 Windows 2000의 DNS는 라운드 로빈이 활성화 되어 있다. 이제 이 DNS서버는 외부의 다른 DNS서버로부터 www.mscs.co.kr 레코드에 대한 요청을 받으면 192.168.0.2와 192.168.0.3 레코드를 동시에 응답하게 된다. 하지만 이 응답이 순서가 있어서 첫번째 DNS쿼리가 오면 192.168.0.2 192.168.0.3의 순서로 응답하고 두번째 DNS쿼리가 오면 이번에는 192.168.0.3 192.168.0.2의 순서로 응답해 준다. 결국 사용자들의 웹서버에 대한 요청은 2대의 서버로 분산되는 효과를 가지게 되는 것이다.

DNS서버의 등록정보를 살펴서 라운드 로빈 구성을 살펴보자.

<그림2. DNS서버 등록정보>

DNS관리콘솔의 왼쪽패널에서 DNS서버 이름을 마우스 오른쪽 클릭하여 '등록정보'를 연다.

< 그림3. DNS서버 등록정보 - 고급옵션>

등록정보의 고급옵션을 살펴보니 여러가지 옵션이 보이는데 '라운드 로빈 사용'이 체크되어 있는 것을 확인할 수 있다.

이러한 DNS라운드 로빈을 이용하여 사용자들의 웹서버로의 요청을 분산시키는 작업은 얼마든지 가능하지만 간단한 구현만큼 한가지 맹점을 가지고 있다.

당신이 관리하는 두대의 웹서버중에서 한대의 웹서버가 문제가 생겨서 다운되었다고 가정을 해 보자. 당연히 당신은 DNS서버의 레코드중에서 문제가 생긴 웹서버의 레코드를 삭제할 것이다. 그러고 나면 당신의 웹서버에 연결하고자 하는 사용자들중 일부는 웹서버를 찾지 못한다는 에러를 만나게 될 수 있다. 원인을 살펴보니 사용자들이 여전히 문제가 생겨서 DNS에서 제거한 레코드에 해당하는 웹서버를 찾아가고 있다는 것을 발견하게 되었다. 당연히 사용자들의 요청은 웹서버로 전달될 수가 없다.

무엇이 문제인가?

DNS서버는 기본적으로 '캐쉬'를 가지는데 한번 DNS서버간의 쿼리를 통해서 원하는 레코드의 정보를 얻으면 이것을 캐쉬에 저장하고 캐쉬의 TTL이 만료되기 전에는 다른 DNS서버로 새로운 쿼리를 던지지 않는다는데서 문제가 생기는 것이다.

예를 들어서 외부의 한 사용자가 천리안의 DNS를 사용하고 있다고 가정해 보겠다. 그 사용자는 웹브라우저를 실행시키고 http://www.mscs.co.kr 이라는 사이트에 접근을 시도했다. 당연히 천리안의 DNS에게 www.mscs.co.kr의 IP Address를 요청했을 것이고 천리안의 DNS서버는 mscs.co.kr의 DNS서버에게 www레코드를 요청하게 된다. mscs.co.kr의 DNS는 192.168.0.2와 192.168.0.3 이라는 2개의 레코드를 응답하게 되고 천리안의 DNS서버는 그 정보를 캐쉬에 저장한 다음 사용자에게 응답해 주게 된다. 그렇게 해서 사용자와 웹서버와의 통신은 잘 이루어지게 되는데...

mscs.co.kr의 웹서버중 192.168.0.2 IP Address를 가진 웹서버가 다운이 되었고 mscs.co.kr 관리자는 DNS서버의 192.168.0.2 레코드를 제거하게 된다.

하지만 천리안의 DNS를 사용하는 외부의 사용자가 다시 http://www.mscs.co.kr 에 접근을 시도하게 되면 천리안의 DNS서버는 사용자가 원하는 정보를 자신의 캐쉬에서 찾아서 응답하게 되고 결국 사용자는 현재 다운이 되어 네트워크에서 사라진 192.168.0.2 웹서버에 연결을 시도한다. 웹서버를 찾을 수 없다는 에러메시지를 받게 된다.

이러한 경우는 DNS의 성능을 위해서 제공되는 '캐쉬'가 거꾸로 좋지 않은 영향을 주는 결과를 낳고 말았다. www 레코드의 TTL값을 조정하여 캐쉬로 인한 문제를 최소화해 보자.

DNS서버에서 mscs.co.kr 영역의 SOA레코드를 편집하여 전체적인 TTL을 조정할 수도 있지만 예제에서는 특별히 www 레코드의 TTL만을 바꿔보도록 한다.

< 그림4. DNS관리콘솔 - 고급옵션>

DNS관리콘솔에서 보기-고급을 선택한다. 캐쉬된 레코드나 레코드별 TTL관리 등 추가작업을 할 수가 있게 된다.

< 그림5. www 레코드 TTL조정>

www레코드의 등록정보를 열고 TTL값을 기본값인 1시간을 지우고 0시간으로 바꿨다. 이제 이 DNS서버로부터 www 레코드를 얻은 상대방 DNS서버에서는 www.mscs.co.kr 레코드의 TTL이 0이므로 캐쉬를 하지 않고 항상 필요할 때마다 새롭게 DNS서버에 쿼리하게 될 것이다.

거듭 이야기하지만 DNS를 이용한 방법으로는 당신이 원하는 완벽한 솔루션이 될 수는 없다. TTL을 바꿔서 문제를 최소화시켜도 상대방 DNS서버에서 임의로 캐쉬값을 조절하는 경우도 있고 이 문제로 몇몇 ISP의 DNS같은 경우 24시간 길게는 며칠씩 캐쉬에 정보를 가지는 경우가 있어서 당신의 회사에서 DNS서버의 레코드를 변경했어도 그것이 전체 인터넷의 DNS서버까지 완전하게 반영되기까지는 수일이 걸리는 경우도 허다하기 때문이다.

그러한 문제로 인한 피해가 회사의 손실로 영향을 미칠수 있는 경우라면 당연히 NLBS를 구현하는 것이 올바른 선택일 것이다.