시스템을 관리하다 보면 부팅이 되지 않는 문제점을 종종 발견하게 된다. 서버의 경우는 차라리 적은데 많은 수의 클라이언트 시스템들을 관리해야 한다면 문제는 더더욱 자주 발생하게 된다. Windows 9x 계열의 클라이언트들이 점점 Windows Server 2003, Windows XP로 대체가 되가고 있고 신규수요는 대부분 XP로 발생하고 있는 실정이기 때문에 이러한 부팅의 문제점을 해결하는 것은 이제 “NT” 시스템의 부팅과정을 잘 이해하는 것으로써 해결의 실마리를 찾을 수 있을 것이다.

11-5-1-1. 부트 프로세스

NT기반 OS가 부팅되는데 어떤 과정을 거치는지 또 어떤 파일들이 사용되는지 해당 파일이 없거나 손상되었을 때 어떤 에러메시지를 만나게 되는지, 그때 해결방법은 무엇인지를 정리해 보도록 한다. 부트 프로세스를 최대한 간소화시켜서 실제로 필요한 파일과 연관시켜 설명하도록 한다. (아래에 캡처한 화면은 Microsoft Virtual PC를 이용하여 화면을 구성한 것이다.)

①    처음 파워를 켜면 POST (Power On Self Test)루틴이 시작된다. 독자들도 한번씩은 키보드와 마우스를 바꿔서 꽂았다거나 하는 경험이 있을 것이다. 그때 시스템은 Keyboard 에러가 나면서 비프음과 함께 더 이상 부팅이 되지 않게 된다. ②    그리고 MBR(Master Boot Record)를 찾는다. MBR는 파티션 정보를 가지고 있는데 여기서 Active(활성)파티션을 찾아 0번섹터에 해당하는 부트섹터를 찾게 된다. 부트섹터에는 Windows NT기반의 부팅을 시작할 수 있는 짧은 프로그램이 들어있다. ③    Windows NT의 부트섹터 프로그램은 같은 파티션에서 NTLDR을 실행시켜 메모리에 로그시킨다. NTLDR이 부팅과정을 책임질 부팅프로그램이다.	<그림11-130. POST Routine 과정>
④    NTLDR은 가장 먼저 boot.ini파일을 찾아서 화면에 사용자의 선택을 요구하는 화면을 띄운다. 단일OS가 설치된 시스템이라면 화면에 보여지지 않고 해당 OS의 다음 부팅과정을 진행한다. ⑤    NTLDR은 Ntdetect.com을 찾아서 로드한다.	<그림11-131. OS 선택화면>
⑥    Ntdetect.com은 시스템의 하드웨어를 점검하고 목록을 만든다. ⑦    NTLDR은 boot.ini의 ARC Path를 참고하여 %Systemroot%\system32 폴더에서 Ntoskrnl.exe를 로드하고 디바이스 드라이버 및 서비스들을 로드하는 작업을 한다.	<그림11-132. 커널 로드 과정>
⑧    Ntoskrnl.exe는 커널을 구성하는 작업을 한다.	<그림11-133. 커널 구성 과정>
⑨    Ntoskrnl.exe는 마지막으로 Winlogon.exe 프로세스를 로드한다. 사용자는 [Ctrl+Alt+Del]을 입력하여 로그온할 수 있는 화면을 얻는다.	<그림11-134. 로그온 프로세스 시작>

위에서 부트프로세스에 대한 설명을 했다. 그림으로 파일을 기준으로 살펴보겠다.

이번에는 부팅과정에서 어떤 문제가 생길 것인지에 대해서 접근해 보자.

부트 프로세스에서 POST과정부터 MBR을 찾는 과정까지 생기는 문제는 하드웨어 적인 문제이다. OS와는 무관하다는 뜻이다. MBR에서 파티션 정보를 찾았지만 활성파티션을 발견하지 못했다면 혹은 활성파티션은 있지만 부트섹터가 없다면 그때도 역시 시스템은 부팅이 되지 못한다. “Non system disk error” 라는 일반적인 에러를 내며 멈추고 만다. 부트섹터를 찾았지만 Windows NT의 부트섹터 프로그램이 아닌 Windows 9x의 부트섹터였다면 시스템에서는 Windows NT를 부팅할 수 없다. 부팅이 되기 위한 최소한의 기본조건은 시스템의 활성파티션에 Windows NT기반의 부트섹터가 있어야 한다는 것을 뜻한다. 아래의 내용은 Windows NT기반의 부팅과정에서 생기는 문제점을 설명한 화면이다. 단계별로 접근하고 있다.

<그림11-136. 부트프로세스 에러1>	““NTLDR is missing”혹은 “Could not found NTLDR”이라는 에러메시지가 나왔다. 이 메시지가 나왔다면 적어도 부트섹터 문제는 아니라는 것이 보장된다. 부트섹터에 있는 프로그램이 NTLDR을 찾아서 메모리에 로드하려고 시도했지만 NTLDR을 찾지 못했기 때문에 발생되는 메시지이다. (해결방법☞) 다른 시스템으로부터 ntldr 파일을 옮겨오든지 부팅디스켓으로부터 부팅을 하면 된다. (Windows2000과 2003과는 버전이 다르다)
<그림11-137. 부트프로세스 에러2>	Ntldr이 정상적으로 로딩되었다면 boot.ini파일이 필요한데 이때 boot.ini 파일이 없다고 해서 “Could not found boot.ini”등의 에러메시지를 내 보내지는 않는다. 만일 boot.ini파일이 없다면 ntldr은 자동적으로 OS가 C:\winnt 폴더에 있을 거라는 가정을 하고 다음 단계로 진행한다.   그 다음 순서인 ntdetect.com을 로드하게 되는데 만일 이 파일이 손상되었다면 부팅은 더 이상 진행이 되지 않고 “하드웨어를 점검하지 못했다”는 에러메시지를 발생시킨다. (해결방법☞) 다른 시스템으로부터 ntdetect.com 파일을 옮겨오든지 부팅디스켓으로부터 부팅을 하면 된다. (Windows2000과 2003과는 버전이 다르다)
<그림11-138. 부트프로세스 에러3>	Ntdetect.com이 로드되었다면 다음으로 필요한 파일은 %Systemroot%\system32 폴더에 있는 Ntoskrnl.exe를 로드하게 되는데 바로 이 파일이 손상되었거나 없어서 로딩하지 못하겠다는 에러메시지이다. 속으면 안 된다. 처음 이런 에러메시지를 만났을 때 많은 관리자들이 Ntoskrnl.exe파일을 찾아서 헤맨다. 다른 시스템이나 원본 CD-Rom으로부터 이 파일을 복사해다 붙여넣으려는 시도를 한다. 1.6M정도의 그다지 크지는 않은 파일이지만 아쉽게도 그것으로 해결되지는 않는다. 실제로 이 파일이 손상되어서 이러한 에러가 나오는 경우는 극히 드물다. (해결방법☞) 이 경우는 boot.ini파일을 살펴봐야 한다. Boot.ini파일의 ARC Path를 통해서 NTLDR은 Ntoskrnl.exe의 위치를 찾게 되는데 이 파일의 위치가 잘못 설정되어 있다면 (예를 들면 실제로 winnt폴더가 D:에 있는데 C:에 있는것으로 가리키고 있다거나) 시스템은 Ntoskrnl.exe를 찾지 못하고 이러한 에러메시지를 발생하는 것이다.
<그림11-139. 부트프로세스 에러4>	간혹 <그림11-139>와 같은 에러가 발생하는 경우도 있다. Boot.ini를 통해서 보게 되는 메뉴중에 분명히 리스트에는 없던 “Windows 2000 (기본값)”이라는 메뉴가 보인다. 이것도 역시 boot.ini의 ARC Path가 잘못지정되어 있기 때문에 생기는 에러이다. <그림11-140>의 경우에 이러한 에러가 발생한다. 그림에서 하이라이트된 부분이 timeout=30초 내에 OS를 선택하지 않을 때 부팅이 되는 기본OS이다. 그런데 이 기본OS와 일치하는 Path를 아래의 세개의 목록중에서 찾을 수가 없다. 그럴때는 Boot.ini파일이 없는것과 동일하게 취급된다. “Windows 2000 (기본값)”이라는 것은 C:\winnt 폴더에 OS가 설치가 되어 있을 거라고 가정하고 부팅을 시도하는 것이다.

이상으로 부팅시 생기는 문제점들에 대해서 살펴보았는데 해결방법마다 꼬박꼬박 나오는 것이 “부팅 디스켓”이라는 것이 있었다. 부팅 디스켓 만드는 방법을 알아보자.

11-5-1-2. 부팅 디스켓 만들기

초기 부팅과정에서 생기는 문제점은 부팅 디스켓 하나만으로도 해결할 수 있는 경우가 있다. 부팅 디스켓은 3.5” 디스켓 한장이면 만들수 있다. 다음과 같이 진행하면 된다.

먼저 3.5” 플로피 디스켓 한장을 준비한다. 반드시 Windows Server 2003에서 디스켓을 포맷한다. DOS에서 부팅디스켓을 어떻게 만들었는지 상기해 보면 “format a: /s”라고 /s 스위치를 주고 포맷했던 것을 기억할 것이다. 이 스위치는 a:에 DOS의 부트섹터를 만드는 작업을 해 주었다. 마찬가지이다. 하지만 그것보다 오히려 간편하다. Windows Server 2003에서 디스켓을 포맷하기만 하면 자동으로 그 디스켓의 0번 섹터에는 Windows Server 2003의 부트섹터가 생성되게 된다.

다음에 이 포맷한 디스켓에 시스템 파일을 저장해 주어야 한다. 기본적으로 시스템 파일들은 감춰져 있다. 윈도우 탐색기의 도구-폴더옵션을 열어서 ‘숨김 파일 및 폴더 표시’를 설정하고 ‘보호된 운영 시스템 파일 숨기기(권장)’을 해제한다.

C: 루트에 보면 boot.ini, NTDETECT.COM, ntldr 이 보인다. 이것을 A:로 복사한다.

이상으로 부팅디스켓이 만들어졌다. 이 디스켓이 해 주는 일은 하드디스크에서 해 주어야 할 일을 대신하는 것이다. 이것으로 초기부팅 과정에서 NTLDR이 해야 할 모든 일은 부팅 디스켓으로 처리해 준다. Ntoskrnl.exe가 로드될때까지는 이 디스켓이 역할을 담당한다.

물론 이것은 일시적이다. 이 부팅디스켓으로 부팅을 한 후에는 디스켓에 있는 시스템 파일들을 하드디스크의 C: 루트로 복사를 해야 할 것이다. 하지만 부트섹터가 망가진 경우라면 복사해서 붙여넣기를 할 수는 없다. 그때는 응급복구과정을 거쳐서 해결할 수 있다. 다음장에서 다루어진다.

제대로 복구를 하는 것은 백업을 하는 것만큼이나 중요한 일이다. 백업을 잘 하는 관리자는 많지만 의외로 복구를 잘하는 관리자는 많지 않다. 어떻게 보면 당연한 일이라 할 수 있다. 백업은 항상 하고 있지만 복구는 문제가 발생하기 전에는 해 볼 기회가 없기 때문일 것이다. 잘 돌아가는 시스템을 멈추고 복구를 위한 테스트를 해 보는 작업은 어떻게 보면 엽기적인 행동으로 비춰질 수도 있겠지만 현명한 관리자라면 비슷한 크기의 백업을 진행하게 되는 테스트 시스템을 셋팅하고 복구테스트를 해 보는 것을 잊지 말아야 할 것이다.

복구를 해야 하는 시스템에서 백업프로그램을 실행한다. 시작à실행창에 ‘ntbackup’이라고 입력하여 백업프로그램을 실행할 수 있다.

백업프로그램이 시작되었다. 복원마법사를 이용하면 편리하다.	<그림11-120. 백업으로부터 복구하기 1>
‘복원할 데이터’화면이 나오는데 이 시스템에서 백업프로그램이 수행되었다면 그림과 같이 백업된 정보가 나온다. 복원할 항목을 선택한후 [다음]을 누른다.	<그림11-121. 백업으로부터 복구하기 2>
백업데이터의 위치를 지정하니 카달로그에서 이 백업데이터가 백업한 폴더구조를 보여준다. 여기서 복구를 원하는 폴더나 파일을 체크하고 [다음]을 누른다.	<그림11-122. 백업으로부터 복구하기 3>
복원마법사가 완료되었음을 보여주는데 [마침]을 누르면 원래의 위치에 그대로 복구를 하게 된다. 여기서 [고급]을 눌러서 추가설정을 확인한다.	<그림11-123. 백업으로부터 복구하기 4>
복원할 위치를 지정하는 화면이다. 원래위치에 할 것인지, 다른 위치에 복원할 것인지 아니면 폴더구조를 무시하고 하나의 폴더에 모든 파일을 풀어놓을 것인지를 선택할 수 있다.	<그림11-124. 백업으로부터 복구하기 5>
복구할 대상디스크에 같은 파일이 있을 때 어떻게 처리할 것인지를 묻는다. 결정한 다음 [다음]을 누른다.	<그림11-125. 백업으로부터 복구하기 6>
‘고급복원옵션’에서는 NTFS퍼미션까지 복구를 할 것인지 여부를 결정할 수 있다. 기본적으로 활성화되어 있다. 하지만 NTFS파일시스템에서 백업된 데이터를 FAT파일시스템으로 복원한다면 이 퍼미션은 의미가 없다.	<그림11-126. 백업으로부터 복구하기 7>
복원마법사가 완료되었다. 요약된 정보를 확인한다.	<그림11-127. 백업으로부터 복구하기 8>
복원을 완료하였음을 보여주는 화면이다. [보고서]를 클릭하여 어떤 파일과 폴더가 복원이 되었는지, 오류는 없었는지 등을 살펴본다.	<그림11-128. 백업으로부터 복구하기 9>

시스템 상태 데이터를 백업했을때도 마찬가지로 이 복원마법사를 사용할 수 있지만 Active Directory는 정상적인 부팅을 통해서는 복원할 수 없다. Active Directory가 설치된 도메인 컨트롤러에서 정상적으로 부팅하고 시스템상태 데이터를 복원하고자 했을때는 다음과 같은 에러메시지를 만나게 된다.

Active Directory를 복원하기 위해서는 처음 부팅시 [F8] 기능키를 이용하여 고급옵션에서 ‘디렉터리 서비스 복원 모드’를 선택하여 부팅해야 한다. ‘디렉터리 서비스 복원 모드’를 선택하면 Active Directory를 시작시키지 않고 로컬 SAM 디렉터리 데이터베이스를 이용하여 시스템을 부팅한다. 이때 사용되는 관리자계정은 Administrator이고, 암호는 Active Directory설치시 ‘복원모드에서 사용할 관리자의 암호’라고 입력했던 암호가 사용된다. Active Directory의 관리자계정과 암호와는 다르니 구별해야 할 것이다. 그렇게 부팅을 하면 백업프로그램의 복원마법사를 이용해서 Active Directory를 복구할 수 있다.

위의 백업을 예약한다거나 하는 작업은 백업프로그램이 독자적으로 지원하는 기능이 아니다. OS에서 지원하는 스케쥴 서비스와 연결되어야만 구현이 가능한 방법이다. 추가로 스케쥴 서비스에 대해서 알아볼 필요가 있다. 시스템에서 예약된 작업이 동작하기 위해서는 반드시 스케쥴 서비스가 동작하고 있어야 한다.

관리도구-서비스 스냅인을 열어보면 Task Scheduler 라는 이름이 보인다. 이것이 스케쥴 서비스이다. 백업을 위한 예약작업은 백업프로그램을 통해서 접근이 가능하지만 그밖의 예약작업은 ‘시작à프로그램à보조프로그램à시스템도구à예약된 작업’을 통해서 구현할 수 있다. 사용법은 아주 간단하다. 그것보다는 명령프롬프트에서 구현할 수 있는 방법을 살펴보도록 하겠다.

마이크로소프트는 시스템에서의 예약작업을 위하여 at.exe 라는 도구를 제공한다. 아래의 박스는 명령프롬프트에서 진행된 작업이다.

보통 백업은 사용자들의 활동량이 없거나 줄어든 밤 시간에 진행된다. 당신의 회사는 밤11시부터 백업이 이루어진다고 가정해 보자. 백업을 하기 위해 밤11까지 누군가 당번을 서야 한다면? 또 꼭 이러한 측면이 아니더라도 매일같이 동일한 백업을 진행해야 하는데 이것을 일일이 프로그램을 실행하여 백업유형을 결정하고 백업할 파일과 폴더, 시스템 상태 등을 선택하고 백업을 진행하다 보면 간혹 실수를 한다거나 할 확률도 커질 것이다.

이러한 작업들은 여러분들이 직접 하고 있어서는 안된다. 그렇다면 남을 시키면 되겠지만 당신이 그 ‘남’이라면 어떻게 할까? 이런 경우는 시스템의 스케쥴 서비스를 활용하는 것이 올바른 방법이다. 이 스케쥴 서비스는 꼭 백업에만 국한된 개념은 아니다. ‘특정한 시간에 시스템이 특별한 작업을 스스로 수행하도록 설정해야겠다’라고 생각했다면 그때는 스케쥴 서비스를 이용할 것을 고려해야 한다.

백업을 예약해 보도록 한다. 예제에서는 월요일과 금요일에는 일반백업을 수행하고, 화, 수, 목요일에는 증분백업을 수행하도록 예약한다. 백업을 예약하는 것은 백업프로그램의 ‘작업예약’탭에서 접근할 수 있다. 이 시나리오를 완성하기 위해서는 두차례에 걸쳐서 스케쥴을 해야한다. 월,금요일의 일반백업이 하나이고, 화, 수, 목요일의 증분백업이 하나이다. 

<그림11-105. 백업 예약하기 1>	작업예약 인터페이스가 열리는데 서버의 프로그램이라고 보기엔 참 아기자기하게 만들었다 싶은 생각이 든다. 월요일을 클릭하고 아래의 [작업추가]버튼을 눌렀다.
<그림11-106. 백업 예약하기 2>
<그림11-107. 백업 예약하기 3>	백업할 데이터를 선택하는 화면에서 ‘내 컴퓨터에 있는 모든 파일’을 선택했다. 물론 선택을 할 수도 있다.
<그림11-108. 백업 예약하기 4>	백업을 저장할 위치를 지정해 준다.
<그림11-109. 백업 예약하기 5>	‘백업종류’를 선택하는 화면에서 월요일 백업유형으로 ‘일반’백업을 선택했다.
<그림11-110. 백업 예약하기 6>	‘백업방법’화면에서는 ‘백업 후 데이터 확인’메뉴가 기본적으로 선택되어 있지 않다. 이 옵션을 체크하면 백업이 완료되면 백업된 데이터와 원본데이터를 비교하여 무결성을 보장할 수 있는 옵션이다. 좋은 옵션이지만 백업이 제대로 되지 않는 경우가 잦은 경우에만 사용을 권장한다.   아래에 있는 ‘사용할 수 있으면 하드웨어 압축 사용’은 Windows Server 2003 자체의 기능이 아니라 백업의 효율성을 위해서 압축기능을 지원하는 백업디바이스를 사용할때만 활성화된다. [다음]을 눌렀다.
<그림11-111. 백업 예약하기 7>	백업대상이 되는 테이프나, 하드디스크의 파일에 기존파일에 붙여서 백업할 것인지 덮어쓰기를 할 것인지를 묻고 있다.
<그림11-112. 백업 예약하기 8>	‘백업시간’화면에서 ‘지금’을 선택하지 않고 ‘나중에’를 선택하여 일정을 예약해야 한다. 아래쪽의 [일정설정]버튼을 클릭한다.
<그림11-113. 백업 예약하기 9>	‘작업예약’화면에서 ‘작업예약’은 ‘매주’를 선택하고, 시작시간은 백업을 시작할 오후11시, 그리고 요일은 월요일과 금요일을 체크하였다. [확인]을 클릭한다.
<그림11-114. 백업 예약하기 10>	예약하고 있는 백업작업을 수행할 때 사용할 사용자계정을 요구한다. 이 계정은 ‘백업’권한을 가지고 있어야 한다. 사용자 권한에 대해서는 <그림11-5>화면에서 설명했던 것을 참고하라. 백업도 시스템의 권한중의 하나이다. 관리자를 위한 기본계정인 Administrator는 백업권한을 가지고 있다.
<그림11-115. 백업 예약하기 11>	일정을 설정하였으면 [다음]을 눌러서 예약을 마친다. 백업설정이 완료되었다. 요약된 정보를 확인해 본다.

이제 작업예약 탭을 확인하면 매주 월요일과 금요일에 일반백업이 이루어진다는 것을 한눈에 볼 수 있다. 계속해서 두번째 예약인 화,수,목요일의 증분백업을 예약하기 위해 <그림11-105>에서 [작업추가]버튼을 누른다. 

<그림11-116. 백업 예약하기 12>	백업종류에서 ‘증분’을 선택하여야 한다.
<그림11-117. 백업 예약하기 13>	위에서와 같은 방법으로 이번에는 화,수,목요일 밤 11시부터 백업이 진행되도록 일정을 잡았다.

<그림11-118>은 작업이 완료된 화면이다. 월, 금요일엔 일반백업이, 화, 수, 목요일에는 증분백업이 되도록 일정을 잡은 것이다.

백업의 중요성은 아무리 강조해도 지나치지 않는다. 데이터 손실을 고려해서 전용서버를 사용하고 하드디스크를 중복배치하고, 여러대의 서버를 추가하고 등등.. 여러가지 방법을 고려하겠지만 무엇보다 최선의 방법이라면 백업을 고려해야 한다. 또 다른 측면이라면 백업을 제외한 다른 백업방법들은 현재의 상태만 유지시켜줄 수 있지만 백업프로그램을 사용하는 것은 지난시점의 데이터를 복구하는 작업도 가능하다는 측면 때문에 보다 매력있는 솔루션이라고 생각한다. 서버OS에 내장된 백업프로그램에 대해서 정리해 보도록 하겠다.

11-4-1. 백업 (Backup)

먼저 백업부터 다루어보자. 인터페이스가 깔끔하긴 하지만 제대로 된 구성을 하기까지는 조금 투박한 과정을 거쳐야 한다. Windows NT 4.0 서버의 경우 제공되던 백업프로그램은 오로지 테이프 백업만 지원했다. 테이프 디바이스를 설치한 시스템에서만 백업이 가능하다는 단점이 있었지만 Windows Server 2003 에서 지원하는 백업프로그램은 테이프 백업과 더불어 파일백업을 지원하고 있다. 테이프 디바이스가 아닌 파일시스템에 파일형태로 백업이 가능하다는 것을 의미한다. 비교적 쓸만한 백업프로그램이 되었다.

‘시작à프로그램à보조프로그램à시스템도구à백업’을 실행하면 백업프로그램이 열린다. 혹은 실행창에서 ntbackup 이라고 입력한다. 백업프로그램을 왜 관리도구가 아닌 보조프로그램에 넣어 둔 것일까?

백업프로그램의 처음화면을 보면 ‘백업 마법사’ ‘복원 마법사’ ‘시스템 자동복구 복구 디스크’ 메뉴가 3개 보인다. 백업, 복원뿐만 아니라 시스템이 손상되었을 때 복구하기 위한 ‘시스템 자동복구 디스크’를 만드는 것도 이 도구를 통해서 작업한다. NT4.0환경에서 rdisk 라는 도구가 제공되었던 것과 동일하다.

백업을 해 보자. 백업마법사를 이용할 수도 있지만 ‘백업’탭을 클릭하여 차근차근 접근해 보았다.

백업탭을 열어보니 C: D: 등의 드라이브들과 ‘시스템 상태’라는 정보가 보인다. 시스템 상태는 여러가지 정보를 포함하고 있다. Active Directory, 레지스트리 등을 백업하려면 ‘시스템 상태’를 백업해야 한다. 이것은 개별적으로는 되지 않고 한꺼번에 ‘시스템 상태’라는 데이터베이스로써 한꺼번에 백업이 이루어진다. Windows Server 2003 의 백업은 시스템 상태 데이터베이스에 대해서는 원격백업을 지원하지 않는다. A에서 B의 시스템상태 데이터를 백업하지는 못한다는 것을 뜻한다. 각각 로컬백업을 해야 한다. 하지만 파일시스템에 대해서는 원격백업을 지원하는데 그러기 위해서는 먼저 원격서버에 있는 백업할 폴더에 대한 드라이브 매핑작업을 해 두어야 한다. (net use x:  \\원격서버이름\공유폴더이름 형태를 사용하면 된다.)

예제에서는 D: 전체와 ‘시스템 상태’를 백업하고자 선택했다. 아래쪽에 백업이 저장될 위치는 비활성화 되어 있다. 백업디바이스가 없기 때문에 ‘파일’로 고정되어 있는 것이다. ‘백업 미디어 또는 파일이름’에 백업파일이 저장될 위치와 파일이름을 입력하고 [백업시작]버튼을 누른다.

‘백업작업정보’화면에서는 기존에 존재하는 백업이 있을 때 덮어쓸 것인지, 덧붙여 계속 백업을 쓸 것인지를 결정한다. [백업시작]버튼을 누르면 바로 백업을 시작한다. 많이 간단하다. 추가로 백업프로그램을 살펴보기 위해 [고급]버튼을 클릭한다.

백업 종류를 보여주는 화면이 보이는데 중요한 정보이다. 백업 종류를 어떻게 결정하느냐에 따라서 백업의 성능, 테이프나 파일시스템 공간의 사용량, 복원시 편리성 등이 결정되기 때문이다.

※ 백업 타입의 이해   마이크로소프트가 백업프로그램에서 지원하는 백업종류는 5가지가 있다. 각각의 백업종류에 따라서 어떻게 백업이 되는지를 이해하는 것은 중요하다. 일반, 복사, 증분, 차등, 매일 백업에 대해서 살펴본다. 백업종류 무엇이 백업되는가? 백업표시 일반(Normal) 백업하겠다고 체크한 모든 파일과 폴더가 백업된다. 한다 복사(Copy) “ 안한다 증분(Incremental) 백업하겠다고 체크한 모든 파일과 폴더중에서 이전에 백업한 후에 바뀐 파일과 폴더만 백업한다. 한다 차등(Differential) “ 안한다 매일(Daily) 그날그날 바뀐 파일과 폴더를 백업한다. 한다   표로 정리해 보았다. 특이하게도 일반과 복사, 증분과 차등은 각각 백업방법이 동일하다. 다만 백업표시를 하고 안하고의 차이만 있을 뿐이다. 백업표시를 하고 안하고의 차이는 아주 크다. 예를 들어 월요일에 a 라는 파일을 백업하였다면 화요일에 백업을 할때는 a 라는 파일이 화요일에 사용자가 접근하여 파일을 변경하였다면 다시 백업을 하겠지만 월요일에 백업한 파일의 내용과 변화가 없다면 백업을 중복해서 하지는 않겠다는 것을 의미한다. 아래의 그림을 보면서 차이점을 이해해 보자. <그림11-100. 증분백업의 이해>   예제를 보면 a,b,c,d 라는 네개의 파일이 나온다. 매일 백업을 하는데 백업종류가 다르다는 것을 알 수 있다. 월요일에는 ‘일반’백업을 했다. 위의 표에서 설명한대로 일반백업은 선택한 모든 파일을 백업한다는 것을 알고 있다. 중요한것은 일반백업은 백업후 백업한 파일에 백업을 하였다는 표시를 한다는 것이다. 화요일에 b가 변경되고 d가 새롭게 추가되었다. a와 c는 월요일 백업한 이후로 변경이 되지 않았다. 화요일에 증분백업을 선택해서 백업을 했을때는 b와 d만 백업이 되고 a와 c는 백업이 되지 않는다. 증분백업과 차등백업은 “백업하겠다고 체크한 모든 파일과 폴더중에서 이전에 백업한 후에 바뀐 파일과 폴더만 백업한다.”는 설명을 기억하라. 그리고 나서 증분백업은 역시 자신이 백업한 파일에 대해서 표시를 한다. 그 결과 a만 변경된 수요일에 증분백업을 이용한 백업은 a만 백업되는 결과를 가져온다.   이렇게 증분백업은 변경되지 않은 파일의 중복백업을 피하게 되며 시간, 테이프 등의 절약효과를 주게 된다. 장점만 있는 것은 아니다. 데이터에 문제가 생겨서 복원을 해야 할 경우는 조금 번거로워 진다. 이 경우에 만일 목요일에 디스크가 망가져서 데이터가 전체가 유실되었을 때 수요일까지의 데이터를 복구하기 위해서는 월요일, 화요일, 수요일, 각각 백업했던 백업테이프를 차례대로 반복해가며 복원을 해야 완전한 복구가 가능할 것이기 때문이다. 아래의 예제로써 차등백업도 살펴보자. <그림11-101. 차등백업의 이해>   두번째 예제에서는 화요일부터 백업유형만 증분백업에서 차등백업으로 바뀐 것을 확인할 수 있다. 화요일까지의 백업은 앞의 예제와 다를바가 없다. 다만 화요일의 백업인 차등백업은 백업을 마치고 나서 자신이 백업한 파일에 대해서 표시를 하지 않는다. 그 결과 a만 변경된 수요일에 차등백업을 이용한 백업은 화요일의 백업을 알지 못하기에 화요일에 변경되었던 b와 d까지도 백업을 하여 결국 a, b, d를 백업되는 결과를 가져온다. 결론적으로 수요일 백업테이프 안에는 화요일에 백업한 파일이 중복되어 저장되는 형태가 된다. 불필요하게 생각될 수 있지만 이것은 증분백업에 비해 복원시 편리성을 제공한다. 같은 상황에서 수요일까지의 데이터를 완전복구하기 위해서는 월요일테이프와 수요일 테이프만 있으면 되기 때문이다.   증분백업과 차등백업의 차이를 이해하겠는가? 마이크로소프트는 이러한 백업형식을 자사의 대부분의 제품에서 지원하고 있으니 잘 정리해두면 다른 제품을 공부할때도 보다 수월해 질 것이다.   한가지 다른 측면을 고려해 보자. 위에서 일반백업과 증분백업은 ‘백업후 표시를 한다’라는 표현을 했고 복사와 차등백업은 ‘표시를 하지 않는다’라고 표현했는데 이것이 실제로는 어떻게 한다는 것일까?   그것은 파일의 속성과 관련이 있다. 윈도우 탐색기를 이용해 파일의 등록정보를 열어보면 ‘보관가능’이라는 속성이 있다. 이 속성은 파일이 변경이 되는 시점에서 자동으로 체크된다.   <그림11-102. 보관가능(Archive) 속성의 이해>   백업프로그램의 일반백업과 증분백업이 백업을 한 후에, 백업했다는 표시를 한다는 것은 바로 이 속성의 체크박스를 비우는 작업을 의미한다. 백업후 이 속성의 체크상자가 지워지고 난 후, 사용자가 접근하여 이 파일의 데이터를 변경했다면 다시 이 속성은 체크될 것이고 다음번 백업할때 증분백업이나 차등백업을 하게 되면 이 파일은 백업되게 된다. “이전에 백업한 후에 바뀐 파일과 폴더만 백업한다.”라고 한 표현은 이러한 특성을 의미하는 것이다.

백업종류를 결정하고 [확인]버튼을 누른 후 [백업 시작]버튼을 누르면 백업이 시작된다.

백업이 진행되는 상태를 보여주는 화면이다.

백업을 마쳤다. [보고서]버튼을 클릭하여 백업이 제대로 되었는지, 어떠한 파일과 폴더가 백업이 되었는지 살펴본다.

서버의 성능을 파악하여 업그레이드나 서버증설 여부를 파악하는 것도 필요하다. 막연하게 메모리가 부족한가? CPU가 느린가? 등으로 생각하기보다는 실질적인 수치를 기록하여 근거치를 마련할 필요가 있기 때문이다. 이러한 자료는 재무부서에 근거치로 제시하여 현실적인 판단을 할 수 있는 자료로 사용될 수 있을 것이다.

성능모니터의 기능을 3가지로 나누어서 접근해 보았다. 먼저 실시간으로 현재 상태를 파악하는 방법, 둘째로 회사에서 기준치를 마련하여 향후 비교할 수 있는 근거를 마련하는 방법, 마지막으로 경고를 설정하여 일정 수준에 이르렀을 때 관리자에게 통보를 한다거나 서버에서 특별한 파일을 실행하는 등 조치를 취할 수 있도록 하는 기능에 대해서 살펴보겠다.

11-3-4-1.현재 상태를 실시간으로 점검해 보자.

갑자기 서버의 응답속도가 느려졌다는 사용자들의 불평이 늘기 시작했다. 도대체 뭐가 문제인지 막연하기만 할 뿐이다. 이 경우 현 시점의 서버의 상태를 실시간으로 체크해 볼 필요가 있다. 먼저 ‘관리도구-성능’을 실행하거나 실행창에서 Perfmon 이라고 입력한다.

<그림11-59. 성능 모니터>	성능 모니터가 열렸다. 왼쪽 패널을 보면 세가지로 분류해 볼 수 있다. ‘시스템 모니터’를 클릭하여 실시간 서버상태를 볼 수 있고, 아래쪽에는 로그와 경고를 볼 수 있다. 오른쪽 패널에는 실시간 수치가 나오게 될 화면이다. 하지만 아무것도 없다. 당연한 일이지만 무엇을 모니터링 할것인지를 결정해 주어야 한다. 화면에서 + 버튼을 누른다.
<그림11-60. 성능모니터 - 카운터 추가 화면1>	카운터 추가 화면이 열리는데 이것은 개체, 카운터, 인스턴스 라는 세가지 항목으로 나뉘어 있다.
개체는 모니터링 대상을 의미한다. 메모리, CPU, 서비스, 네트워크 등 어떤 대상을 모니터링 할것인지를 ‘성능 개체’에서 선택한다. 많은 성능개체들이 있고, 성능개체를 선택할때마다 카운터들도 달라진다. 카운터는 해당 개체중에서 어떠한 수치를 모니터하고 싶은지를 결정한다. 예를 들어 메모리라는 개체를 모니터링 한다면 현재 사용중인 메모리를 측정하고 싶은것인지, 남아있는 메모리를 측정하고 싶은 것인지, 원하는 수치가 있을 것이다. 그것이 바로 카운터이다. 마지막으로 인스턴스는 개체에 대한 구체적인 대상을 뜻한다. 예를 들어 ‘프로세서(CPU)’를 모니터링 한다고 할 때 만일 당신의 시스템이 CPU를 2개 가진 시스템이었다면 인스턴스는 _Total, 0, 1 이렇게 세가지 인스턴스를 보여준다. CPU전체를 모두 모니터링 할것인지, 특별한 CPU만 모니터링 할 것인지를 결정하는 것이다. 그것이 인스턴스이다.
<그림11-61. 성능모니터 - 카운터 추가 화면2>	일일이 외워서 쓰기에는 너무나 많은 개체가 있고, 거기에 따른 카운터가 존재한다. 다행히 성능 모니터 도구에서는 어떤 개체를 선택하게 되면 가장 많이 사용되게 되는 필수적인 카운터들이 기본적으로 하이라이트되어 있는 것을 알 수 있다. 그것을 모니터링 하는 것이 우선이다. 개체, 카운터, 인스턴스를 결정하고 나면 [추가]버튼을 누른다. 몇가지를 추가한 다음 [닫기]버튼을 눌렀다.
<그림11-62. 성능모니터 – 카운터가 추가된 화면>	카운터를 추가하고 나면 <그림11-62>와 같은 화면을 만날수 있다. 기본값인 1초 간격으로 실시간으로 그래프가 움직이는 것을 확인할 수 있다. 모니터링 하는 동안에 평균치도 보여주며 최소값, 최대값 등도 볼 수 있다. 화면에 보여지는 정보를 ‘등록정보’버튼을 눌러서 조절할 수 있다. 그림에서 O으로 표기한 부분인 등록정보를 클릭하였다.
<그림11-63. 성능모니터 등록정보>	그래프 탭을 열고 ‘세로눈금’과 ‘가로눈금’을 체크하였다.
<그림11-64. 성능모니터 – 등록정보가 수정된 화면>	등록정보에서 옵션을 바꾼것과 같이 이제 그래프에는 가로, 세로 눈금이 표기된 것이 보인다.
<그림11-65. 성능모니터 – 히스토그램 보기>	기본적으로 성능모니터는 ‘차트’형태로 실시간 데이터를 보여주는데 추가로 두가지를 더 지원한다. <그림11-65>는 도구모음중에서 ‘히스토그램 보기’를 선택하여 막대그래프 형태로 보여주는 화면을 볼 수 있다. 단지 보기형태만 달라진 것일 뿐이다.
<그림11-66. 성능모니터 – 보고서 보기>	다시 ‘보고서 보기’를 선택하여 실시간 데이터를 보고서 형태로 보여지도록 설정하였다. 보고서 형태에서 1초 간격으로 계속 변경되는 데이터를 확인할 수 있다.
<그림11-67. 성능모니터 – 차트 보기>	다시 ‘차트 보기’를 선택하여 기본설정으로 돌아왔다. 색깔이 다르게 표현되기는 하지만 많은 카운터를 모니터링 하다 보면 원하는 카운터에 대한 그래프가 쉽게 눈에 들어오지 않는다. 이 경우 [Ctrl+H]를 누른다.
<그림11-68. 특정 카운터를 하이라이트한 화면>	[Ctrl+H]를 누르면 현재 선택한 카운터에 해당하는 그래프만 하이라이트되어 보인다. 구별이 쉬워진다.
<그림11-69. 성능모니터 – 카운터 재 추가 화면>	현재 추가한 카운터에서 새롭게 카운터를 더 추가하려면 <그림11-69>에서 보는것처럼 카운터의 종류가 있는 창에서 마우스 오른쪽 단추를 이용하여 ‘카운터 추가’를 선택하면 된다.
<그림11-70. 성능모니터 – 카운터 수치 저장>	또한 이 자료를 Html 포맷으로 저장하여 웹브라우저를 통해서 들여다 볼 수도 있는데 보고자료를 만들 때 유용하게 쓸 수 있다.
<그림11-71. 성능모니터 – 카운터 수치를 웹페이지로 저장>	파일 형식에서 ‘웹 페이지(*.htm)’을 선택한후 test 라고 이름을 붙였다.
<그림11-72. 성능모니터 – 웹페이지로 본 성능모니터>	웹브라우저를 통해서 그래프를 그대로 들여다 볼 수 있다. 단순한 하나의 html 파일이지만 버튼을 클릭하여 다른 타입의 그래프를 볼 수도 있고, 카운터를 클릭하고 그 카운터에 대한 수치를 확인할 수도 있다. 모니터링 하고 있는 서버와 연결되어 도구모음의 카메라 모양의 버튼을 이용하여 ‘데이터 업데이트’를 시키면 현 시점의 정보를 가져올 수도 있다.

대부분의 개체와 카운터는 기본적으로 활성화되어 있지만 디스크 관련 성능카운터들은 시스템시작과 함께 설정되어 있지 않은 것들이 있다. 필요하다면 diskperf 도구를 이용하여 카운터 설정을 바꿔줄 수 있다. <그림11-73>을 참고한다.

그림에서는 diskperf /? 를 이용하여 사용법을 알아본 다음 diskperf –YV 를 이용하여 시스템이 부팅할 때 논리, 물리 디스크 성능 카운터를 사용할 수 있도록 설정하였다.

ㅇ 병목현상을 파악하기 위한 기본 카운터들   수많은 카운터들이 있지만 ‘그중에서도 특히 어떤 카운터를 모니터링 할 것인가’는 막연한 문제가 아닐수 없다. 현실적으로 뚜렷한 객관적인 수치를 내 세우기는 어렵지만 체크해 봐야할 카운터들과 각 카운터에서 허용되는 수치 및 문제판단시 조치사항들에 대해서 정리를 해 본다. 성능개체\카운터 권장방향 허용수치 조치해야 할 사항 Memory\Pages/sec 낮은값 0-20 RAM추가 / 서버분산 고려 Memory\Available Bytes 낮은값 최소 4MB Memory\Committed Bytes 낮은값 실제 RAM보다 낮아야함 Memory\Pool Non-Paged Bytes - 지속적으로 평행선 유지 프로세스의 이상 유무 검토 Processor\%Processor Time 낮은값 80% 이하 프로세서 시간을 차지하는 프로세스 확인/프로세서 업그레이드(파일,프린트서버) 추가고려(응용프로그램서버), 서버분산, 인터럽트를 유발시키는 카드확인 / 대체 Processor\%Privileged Time 낮은값 75% 이하 Processor\%User Time 낮은값 75% 이하 Server Work Queues\Queue Length 낮은값 2 이하 System\Processor Queue Length 낮은값 2 이하 Processor\Interrupts/sec 낮은값 - PhysicalDisk\% Disk Time 낮은값 50% 이하 페이징이 발생하는지 확인한다. 페이징 문제라면 메모리 성능을 다시 점검하고, 페이징 문제가 아니라면 디스크 서브시스템을 업그레이드 한다. PhysicalDisk\      Current Disk Queue Length 낮은값 0-2 디스크 서브 시스템을 업그레이드한다. PhysicalDisk\      Avg. Disk Bytes/Transfer 낮은값 - PhysicalDisk\Disk Bytes/sec 낮은값 - Server\Bytes Total/sec 높은값 - 네트워크 어댑터 추가 고려/ 물리적인 네트워크 업그레이드/ 네트워크 분할 고려 Server\Logon/sec 높은값 - Server\Logon Total 높은값 - Network Interface\Bytes Sent/sec 높은값 - Network Interface\Bytes Total/sec 높은값 - * 참고자료 : Microsoft Technet 사이트

 

11-3-4-2. 기준치(Baseline)를 마련하자. (성능모니터 – 카운터 로그)

 

앞에서는 실시간으로 서버를 모니터링한 수치를 들여다 보았다. 어느날 사용자들이 네트워크가 서버가 너무나 느리다고 불평을 하고 있다고 가정을 해 보자. 그럴때 당신은 어떤 작업을 해야 하는가? 서버가 왜 느린 것인지를 판단하기 위해 성능 모니터를 열고 몇가지 카운터를 추가해 보았다. 하지만 그러한 카운터만으로 서버가 어디에 문제가 생긴것인지를 판단한다는 것은 너무나 막연하지 않은가? 또, 막연히 CPU가 느려서일거라는 판단에 CPU를 업그레이드했지만 여전히 서버는 나아진 성능을 제공해 주지 못하고 있다면 누구를 나무랄 것인가? 그러한 경우에 판단근거로 삼을 수 있는 근거치가 필요해 지는데 서버가 잘 동작할 때 카운터들을 기록해 두었다가 서버가 문제가 생겼다고 판단되는 시점에서 해당 카운터들을 다시 모니터링 해 본다면 기준치와의 차이점을 발견할 수 있을 것이다. 그렇다면 그 카운터에 해당하는 개체가 바로 시스템에서 병목현상을 일으키고 있는 주범이라고 할 수 있을 것이다.

 

CPU는 지속적으로 80%이상 사용되어서는 곤란하다거나 하는 식의 객관적인 수치는 현실성이 떨어진다. 회사의 상황에 따라서 얼마든지 달라질 수 있는 판단이기 때문에 그러한 객관적인 수치는 어디까지나 일반적인 판단일 뿐이고 여러분의 회사 나름대로의 기준치를 마련하는 것은 필수적인 작업이라고 할 수 있다.

 

이러한 경우에는 성능 모니터의 ‘카운터 로그’기능을 사용하여 일정시간동안 서버의 성능 카운터들을 로깅하여 기준치를 마련할 수 있다. 

<그림11-74. 카운터 로그 설정 1>	성능모니터를 열고 왼쪽패널에서 ‘카운터 로그’를 마우스 오른쪽 클릭하여 ‘새 로그 설정’을 실행한다.
<그림11-75. 카운터 로그 설정 2>	새 로그 설정 화면에서 로그의 이름을 입력했다. 예제에서는 ‘My Log’라고 하였다.
<그림11-76. 카운터 로그 설정 3>	[추가]버튼을 눌러서 로깅하고자 하는 카운터를 선택한다. 다양하게 선택하는 것이 좋다. 특히 서버의 성능판단에 큰 요인이 되는 메모리, 프로세서, 물리디스크 등의 개체에 대해서는 전체 카운터들을 추가하였다. 데이터 샘플 간격에 따라서 카운터 수치를 측정하는 회수가 달라진다. 이 간격이 짧을수록 자주 카운터를 측정할 테니 정확한 데이터를 산출할 수 있다고 생각할 수도 있겠지만 특정시간대에 서버의 수치가 지나치게 높다거나 했을 때 그 시간대의 수치가 평균치를 높일 수도 있다는 것을 고려해야 한다. 1분 간격을 설정하면 하루에 1,440번 카운터 수치를 기록할 것이다. 2분 정도로 설정할 것을 권장한다.
<그림11-77. 카운터 로그 설정 4>	다음엔 로그파일 탭으로 이동하여 로그파일 종류를 선택하였다. 필자는 CSV 타입으로 선택하였다. 마이크로소프트의 ‘엑셀’ 프로그램으로 읽을 수 있는 파일타입이다. 엑셀 형태로 데이터를 뽑아 낼 수 있다면 당신이 맘 먹는대로 데이터 변환이 가능할 것이다. 또한 차트나 각종 테이블을 만드는데 아주 유용하게 쓰일 수 있다.
<그림11-78. 카운터 로그 설정 5>	마지막으로 일정탭을 열어서 로그시작시간과 로그중지 시간을 설정하였다. 측정을 하는 대상이 회사에서 쓰는 파일서버라고 가정하면 직원들이 한참 접근하여 쓰는 시간이 중요할 것이다. 그때는 오전9시부터 오후 5시까지 정도를 측정한다. 이렇게 3일 정도를 계속 측정해 볼 것이다. 그렇게 하면 어느정도 정확한 평균치를 구해낼 수 있을 것이다. 시작시간과 중지시간을 스케쥴 할 수도 있고, 수동으로 작업할 수도 있다. 예제에서는 ‘수동으로’를 선택하였다.
<그림11-79. 카운터 로그 설정 6>	[확인]버튼을 눌러서 마치고 나오니 오른쪽 패널에 My Log 라는 로그가 하나 추가된 것을 확인할 수 있다. 마우스 오른쪽 클릭하여 ‘시작’을 누르면 로깅이 시작된다.
<그림11-80. 카운터 로그 설정 7>	원하는 시간까지 로깅을 하고 나면 같은 방법으로 ‘중지’를 눌러서 로깅을 마친다.
<그림11-81. 카운터 로그 설정 8>	이렇게 로깅된 파일은 ‘시스템 모니터’를 통해서 확인할 수 있다. 시스템 모니터를 클릭하고 도구모음 중에서 ‘로그 파일 데이터 보기’를 선택하였다<그림11-81>.
<그림11-82. 카운터 로그 설정 9>	저장된 위치에서 로그파일을 선택하고 [열기]를 클릭한다.
<그림11-83. 카운터 로그 설정 10>	예제에서 파일을 열었지만 달라진 것이 없어보인다. 다시 + 버튼을 눌러서 로깅된 파일에서 원하는 카운터를 들여다 봐야 한다. + 버튼을 눌렀다.
<그림11-84. 카운터 로그 설정 11>	성능개체’를 클릭하니 처음 했던 것과는 달리 몇가지 밖에 안 나오는 것에 주목하자. 이것은 실시간 데이터를 보기 위한 것이 아니라 로깅파일로부터 보는 것이기 때문에 모든 개체가 아니라 로깅할 때 선택했던 개체와 카운터에 대해서만 볼 수가 있는 것이다.
<그림11-85. 카운터 로그 설정 12>	보고자 하는 카운터를 선택하니 <그림11-85>와 같은 화면이 열린다. 이것은 일정시간동안 로깅된 정보를 보여준다.
<그림11-86. 카운터 로그 설정 13>	멋진 옵션이 숨어있다. 왼쪽패널의 ‘시스템 모니터’의 등록정보를 열고 ‘원본’탭을 열면 시간범위를 지정할 수 있다. 로깅된 전체데이터중에서 보고자 하는 시간동안의 데이터만 선택하여 보는 것도 가능하다.   보기 범위를 조정한 다음 [확인]버튼을 눌렀다.
<그림11-87. 카운터 로그 설정 14>	<그림11-87>에서는 선택된 시간동안의 데이터만 보여주는 것을 확인할 수 있다. CSV 포맷으로 로깅되었으므로 이렇게 성능 모니터를 통해서 들여다 볼 수도 있지만 Excel 프로그램에서 불러와서 수치를 놓고 원하는 데이터를 만들어 낼 수 있을 것이다.

<참고> 무엇을 측정하여 기준치를 마련할 것인가? 측정할 자원 측정할 성능개체 메모리 Memory, Cache 프로세서(CPU) Processor, System, Server Work Queues 디스크 서브시스템 Physical Disk, Logical Disk 네트워크 서브시스템 Server, Network Interface, Network Segment 기타 SQL Server, WINS Server, Browser, 기타 성능개체들

 

11-3-4-3. 네 상태를 내게 알려줘? (성능모니터 – 경고기능)

 

서버가 현재 어떤 상태에 놓였는지는 서버가 다운이 되었다거나 해서 응답이 없을때까지 모르는 것이 일반적인 상황이다. 하드디스크의 여유공간이 얼마 남지 않았다든가 서버가 바이러스에 감염되어 CPU활용도가 지속적으로 99%에 이르렀다거나 메모리 사용량이 많아서 지속적으로 페이징이 발생하여 메모리의 업그레이드나 어플리케이션의 분산을 고려해야 한다면 문제가 발생했을 때 관리자는 그러한 사실을 바로 알고자 할 것이다. 그럴때 성능모니터의 경고기능은 유용하다.

 

예제에서는 서버가 CPU 활용시간이 90%이상 넘어가면 관리자에게 알림메시지를 주도록 설정하고자 한다.

<그림11-88. 경고 설정 1>	성능모니터 관리도구에서 왼쪽패널의 ‘경고’를 마우스 오른쪽 클릭하여 ‘새 경고 설정’을 연다.
<그림11-89. 경고 설정 2>	새 경고설정 화면에서 구별할 수 있는 이름을 입력해 준다.
<그림11-90. 경고 설정 3>	어떠한 카운터를 모니터링 할 것인지를 결정해야 하는데 예제에서는 Processor 개체의 Processor Time 카운터를 선택했다. ‘값이 다음일 때 경고 표시’옆의 드롭다운 콤보박스를 클릭하여 ‘초과’를 선택하고, 제한값에는 90 이라고 입력하였다.
이때 ‘데이터 샘플 간격’은 중요한 의미를 가진다. 서버에서 일시적으로 특별한 어플리케이션이 실행될 때 CPU타임이 90%이상 올라가는 것은 어떻게 보면 당연한 일이라 할 수 있는데 이 데이터 샘플 간격을 너무 짧게 잡으면, 예를 들어 ‘1초’라고 잡았다면 짧은 순간 CPU타임이 90%이상으로 올라갔을 때 그러한 내용을 측정하여 관리자에게 경고메시지를 보낼 수 있다. 결국 불필요할 정도로 많은 경고 메시지를 받아야 하는 경우도 있을 것이다. 또 이 시간이 너무나 길다면 일정시간 서버가 과도한 CPU사용에 시달리고 있더라도 미처 측정이 되지 않는 경우가 발생할 것이기 때문에 적당한 수치를 설정해야 할 것이다. 예제에서는 30초 라고 설정하였다.   이제 ‘조건’은 만들었다. 다음에 해야 할 작업은 ‘이러한 조건에 만족했을때는 어떻게 할것인가’라는 ‘액션’을 처리해야 한다.
<그림11-91. 경고 설정 4>	작업탭을 열어서 ‘네트워크 메시지를 다음으로 보냄’에 wssong이라고 관리자가 사용하는 계정을 입력해 주었다. 이 서버는 앞의 조건에 만족하는 상황을 측정했을 때 wssong이라는 사용자 계정에게 메시지를 발송하게 된다. 이때의 wssong은 NetBIOS Name이다. 다음에 나오는 ‘성능 데이터 로그 시작’을 활성화하여 문제가 되는 상황을 발견했을때는 미리 정의된 로그를 시작하도록 설정할 수도 있다. 좋은 옵션이다. 특정한 문제가 발생되는 원인을 다각도로 분석해 보고자 할 때 미리 로그파일을 정의하고 로깅을 하게 되면 차후에 이 문제를 분석해 볼 수 있을 것이다.
<그림11-92. 경고 설정 5>	일정탭을 눌러서 역시 시간설정을 마쳤다.
<그림11-93. 경고 설정 6>	[확인]버튼을 눌러서 창을 닫으니 오른쪽 패널에 CPU Limit 라는 경고가 하나 설정된 것이 보인다. 녹색 아이콘이 활성화되어 있음을 보여준다. 이제부터는 이 서버는 30초마다 한차례씩 해당 카운터의 수치를 측정한다.
<그림11-94. 경고 설정 7>	Wssong 으로 로그온한 사용자는 얼마후 다음과 같은 메시지를 받게 되었다. 내용을 읽어보면 BLUESERVER라는 이름의 서버에서 어떠한 상황이 발생했는지를 보여주고 있다.
<그림11-95. 경고 설정 8>	서버의 이벤트 뷰어를 열고 ‘응용프로그램 로그’를 열어보면 같은 메시지가 로깅된 것을 확인할 수 있다. 이것은 하나의 옵션으로써 구현된 것이다.

이벤트란 무엇인가? 서버 입장에서 이벤트라면 ‘모든 것’을 의미한다. 사용자가 네트워크에 로그온 한 것도 하나의 이벤트이고, 서버에서 특별한 서비스가 시작한 것도 이벤트고, 누군가 어떤 자원에 접근한 것도, IP Address의 충돌이 발생한 것도 하나의 이벤트이다.

서버의 경우는 상대적으로 수많은 서비스들이 동작하고 있고 네트워크에서의 다른 사용자들의 접근도 다양하게 이루어지는 만큼 끊임없이 동작하고 있으며 그만큼 뭔가 맞지 않아 삐걱거리는 경우도 잦고, 또한 서버가 현재 겪고 있는 문제점이 있다면 빠른 시간내에 문제를 발견하고 해결해 주어야만 안정적인 서비스들을 제공할 수 있게 될 것이다.

서버는 이러한 일련의 이벤트가 발생할 때마다 이벤트의 성격별로 로깅(로그에 기록하는 작업을 말함)을 하고 관리자는 이벤트 뷰어라는 도구를 통해서 상태를 점검할 수 있다. 서버를 부팅시켰을 때 간혹 아래의 <그림11-52>과 같은 메시지를 받게 되는 경우가 있다.

이러한 메시지를 받았을 때 관리자는 관리도구에 있는 이벤트 뷰어의 도움을 받아야 한다. 관리도구à이벤트 뷰어를 실행하거나, 컴퓨터 관리도구에서 접근할 수도 있다. 또는 실행창에서 “eventvwr”를 입력하여 접근할 수도 있다.

이벤트 뷰어를 열면 왼쪽패널에 이벤트의 종류별로 로깅된 것을 확인할 수 있다. 예제화면에서는 응용프로그램 로그, 보안로그, 시스템로그, DNS Server로그가 있다. 처음 3가지는 모든 시스템에서 기본제공되는 이벤트들이고 DNS Server로그는 DNS서버가 동작하는 시스템에서만 제공되는 이벤트로그이다. 추가로 시스템이 Active Directory가 올라가 있는 도메인 컨트롤로라면 Directory 서비스 로그와 파일 복제 서비스 로그도 찾아볼 수 있다. 오른쪽 패널에는 로깅된 이벤트의 리스트를 보여주는데 자세히 보기 위해서는 원하는 이벤트를 더블클릭하면 된다.

이벤트를 더블클릭하면 <그림11-54>와 같은 화면을 보여주는데 여기서 몇가지 정보를 알 수 있다. 이벤트ID가 4301라는 것과 이벤트가 발생한 시간, 이벤트에 대한 구체적인 설명을 해 주고 있다.

이벤트는 <그림11-55>에서 보여지는 것처럼 3가지 유형을 가진다. 경고(!), 정보(i), 오류(x)로 나뉘는데 경고는 생길 수 있는 문제점에 대한 알림이고, 정보는 특정 서비스가 시작되었다거나 하는 등의 말그대로 정보를 주는 것이고, 오류는 서비스가 멈췄다거나, 디바이스의 오류가 발생하였다거나 하는 문제점을 알려준다.

관리자들이 가장 관심을 가져야 할 메시지는 ‘오류’메시지이다. 색깔부터 빨간색으로 표기되고 있어 사실 기분나쁘다. 늘 파란색의 ‘정보’메시지만 로깅된다면 좋겠지만 이 시간에도 당신의 서버는 수없이 많은 이벤트를 기록하고 있을 것이다. 그렇다면 이러한 메시지가 발생했을 때 어떻게 대처해야 할까?

해결하고자 하는 메시지를 더블클릭해서 자세한 정보로 접근한다. 이벤트ID와 더불어 구체적인 설명을 해 주고 있는데 이 설명만으로 이벤트가 발생한 원인을 파악할 수 있다면 좋겠지만 대부분의 경우는 그렇지 못하다. 이때 이벤트ID를 통해서 마이크로소프트의 Support 사이트를 통해서 검색을 해 보면 상당부분은 이벤트의 발생원인과 해결방법등이 기록된 기사들을 찾을 수 있다. http://support.microsoft.com나 http://www.eventid.net에 접근하여 이벤트ID를 입력하여 검색해 본다. 검색결과가 나오지 않으면 설명중에서 핵심단어를 검색할 필요가 있다. 자주 하다 보면 검색사가 될 것이다. 가장 빠른 해결책이 될 것이니 지겹지만 그렇게 접근해 볼 필요가 있다.

다음의 화면은 <그림11-56>에서 http://go.microsoft.com/fwlink/events.asp 링크를 클릭한 화면이다. 간혹 쉽게 해결책을 제시해 주기도 한다.

필자 개인적으로는 Google검색을 활용한다. 일반적으로 필요로 하는 대부분의 문제에 대한 원인 및 해결방법은 Google을 통해서 찾을 수 있었다. 해결이 되지 않아 Q&A사이트나, 마이크로소프트를 통해서 지원을 받고자 할때는 그림에서 동그라미로 표기된 부분인 ‘복사’버튼을 이용한다. 복사한 다음에 E-mail이나 게시판에 붙여넣기 하면 이벤트 전체를 상대방에게 알려줄 수 있다. 당신의 컴퓨터를 열고 복사버튼을 누른뒤 메모장에 붙여넣기를 해 보라. 무엇을 말하는지 알 수 있을 것이다.

또한 이벤트로그를 필터링 해서 볼 수도 있다. 원하는 카테고리별로, 혹은 시간대별로 로그를 필터링해서 원하는 정보를 찾을 수가 있다. 관리콘솔의 왼쪽패널에서 원하는 로그를 선택하고 마우스 오른쪽 클릭하여 ‘등록정보’로 접근한다.

필터탭을 선택하여 필터링을 설정하면 원하는 결과를 얻을 수 있다. <그림11-58>의 ‘일반’탭에서는 로그 크기 등을 결정할 수 있는데 기본적으로 이벤트 뷰어에서 저장하는 로그 크기는 512KB로 설정되어 있다. 간혹 서버를 처음 셋업하고 “로그가 꽉 차서 더 이상 로그를 기록할 수 없습니다.”라는 에러 메시지를 받게 되는 경우가 있는데 이때는 이벤트 뷰어 도구를 이용하여 로그를 비워주거나 로그 크기를 키워줄 필요가 있다.

까만색 화면 하면 DOS를 떠올리는 독자들이 있을 것이다. 그 시절 우리는 컴퓨터에서 사용하는 프로그램, 시스템 환경설정 등을 하기 위해 Autoexec.bat Config.sys와 같은 파일을 이용했던 것을 기억할 것이다. Windows에서 역시 이러한 파일이 사용되었으며 Win.ini, System.ini 등의 정보파일들도 환경설정과 관련된 파일이다.

윈도우 서버 2000 & 2003에서는 시스템의 환경설정을 위해서 이러한 파일들을 사용하지 않는다. 시스템, 하드웨어, 소프트웨어 등의 모든 구성을 레지스트리(registry)라고 부르는 데이터베이스에 저장하는 방법을 사용하고 있다. 우리가 TCP/IP등록정보를 열어서 시스템의 IP Address를 변경했다거나, 오피스XP라는 새로운 어플리케이션을 추가했다거나, 화면을 1024*768로 변경했다거나 하는 등의 모든 작업을 했을 때 이 결과는 레지스트리에 반영된다. 시스템은 부팅을 할 때 이 레지스트리로부터 설정을 읽어서 화면에 보여주고 제어하는 방식으로 동작하고 있다.

이해를 돕기 위해 다음을 확인해 본다. 레지스트리 편집도구인 regedt32.exe 를 실행창에서 입력해서 레지스트리를 연다.

“HKEY_LOCAL_MACHINE > SOFTWARE > Microsoft > Windows NT > CurrentVersion” 을 순서대로 찾아가 보라<그림11-44>.

레지스트리 편집기에서 왼쪽패널에 보이는 것이 “키(Key)”이고 오른쪽 패널에 보이는 것이 “값(Value)”들이다. 오른쪽 패널에서 몇가지 정보를 찾아볼 수 있는데, 우리에게 익숙한 내용이 많이 보일 것이다. RegisteredOwner 라는 값을 찾아서 더블클릭한다.

<그림11-45>의 예제에서는 ‘wonsuk’이라는 문자열 대신에 ‘Song won suk’을 입력하여 변경하였다. [확인]을 눌러서 변경사항을 저장한다. 그 다음에 바탕화면의 ‘내 컴퓨터’의 등록정보나, 윈도우탐색기를 열고 도움말 메뉴의 “Windows 정보”를 클릭하면 레지스트리를 통해서 바꾼 설정을 확인할 수 있다. 처음 OS를 설치할 때 입력했던 사용자 이름을 직접 레지스트리를 편집함으로써 변경한 것이다.

사소한 것 하나를 확인해 봤는데, 이렇듯 레지스트리는 시스템의 처음부터 끝까지, 결국 모든 내용을 담고 있는 하나의 데이터베이스라고 할 수 있다.

이러한 레지스트리를 잘 관리하는 일은 매우 중요한 일이다. 위의 과정을 그대로 따라해 본 독자라면 조금 까다롭다는 생각이 들 것이다. Windows 라는 이름의 OS는 ‘인터페이스가 무척 쉽다’라는 것이 큰 특징중의 하나인데, 이렇게 원시적으로 일일이 레지스트리를 찾아다니며 모든 작업을 해야만 할까? 라는 의문이 생긴다. 정답은 ‘아니오’이다.

실제로 관리자가 레지스트리 편집기를 띄워서 직접 값을 추가한다든지 변경하는 일은 레지스트리 관리작업에 있어서 아주 일부분에 지나지 않는다. 물론 관리자라면 이것의 사용방법에 대해서는 알고 있어야겠지만 레지스트리를 해부(?)하려는 노력보다는 Windows 시스템에서 하드웨어, 소프트웨어 등의 각종 설정에 대한 흐름을 이해하는 편이 더 나을 것이다.

그렇다면 어떻게 이 레지스트리를 관리하는 것일까? 그것은 바로 우리에게 너무나 익숙한 ‘제어판(Control Panel)’이다. 제어판이라구? 뜻밖의 답이라고 생각될 수 있겠지만, 우리는 제어판을 통해서 시스템에 관련된 거의 대부분의 설정을 할 수 있다는 것을 잊는 경우가 많다.

바탕화면에서 ‘내 컴퓨터’아이콘의 등록정보를 열면 ‘시스템 등록정보’가 뜨게 되는데 이것은 사실 제어판에 있는 하나의 설정이다. 또, 바탕화면을 마우스 오른쪽 클릭하고 등록정보를 열면 ‘디스플레이 등록정보’가 열리는데 이것 역시 제어판의 일부일 뿐이다. 바탕화면의 다른 것들도 마찬가지이다. 인터넷 익스플로러 아이콘의 등록정보를 열어서 ‘인터넷 옵션’을 수정한다거나, 네트워크 환경의 등록정보를 열어서 프로토콜을 추가하고, IP Address를 변경하는 등의 작업을 한다거나,,, 이 모든 작업들은 결국 제어판을 건드린다는 것을 의미한다.

제어판에서 무엇이든지 설정을 변경하면 그것은 결국 레지스트리의 데이터베이스를 변경하는 효과를 가지게 된다. 이렇듯 제어판이라고 하는 도구는 레지스트리를 관리하기 위한 간접적인 관리도구인 셈이다. 제어판을 통해서 할 수 없는 작업들은 레지스트리를 직접 편집해야 하는 경우도 있는데, 그때 그때 필요한 경우에 찾아서 작업할 수 있을 것이다.

레지스트리를 건드릴 수 있는 또 다른 방법은 어떤 것이 있을까? 또, 당신이 관리하는 시스템이 한두대가 아니라 많은 수의 시스템의 레지스트리를 관리해야 한다면? 그때 바로 정책(Policy)이 사용될 수 있는데, Active Directory와 연계하여 그룹정책(Group Policy)를 사용하면 효율적으로 도메인의 전체 사용자 및 컴퓨터에 대한 레지스트리를 간접적으로 변경하는 효과를 주기 때문에 유연성 있는 관리방법을 제공한다. 그룹정책에 대해서는 14장에서 자세히 다룬다.

지금까지 레지스트리가 관리되는 방법에 대해서 이야기했다. 이 레지스트리를 직접 관리하는 경우를 위해 간단한 사용방법에 대해서 알아본다.

레지스트리 편집기는 2가지가 제공된다. Regedit.exe와 Regedt32.exe 가 있는데, regedt32.exe를 권장한다. Regedit.exe는 Windows 9x 에서 사용되는 편집기인데 Windows Server 2003에서도 제공되고 있다. 데이터베이스는 동일하다. 편집기는 이 데이터베이스를 건드리는 도구일 뿐이니까. Regedit.exe는 레지스트리를 Key와 Value, Data등으로 검색이 가능하여 상대적으로 검색기능이 좋은 편이다. 그렇지만 레지스트리의 권한설정이나, 읽기 전용모드가 지원되지 않기 때문에 Regedt32를 사용하는 편이 좋다.

레지스트리 편집기를 실행하면 레지스트리 데이터베이스가 열린다. <그림11-47>와 같은 화면을 얻을 수 있다.

레지스트리는 계층구조로 되어 있다. 윈도우 탐색기의 구조와 아주 유사하다. 가장 크게 나누면 5개의 서브트리로 구성되어 있는데 각각이 하나의 창을 이루고 있는 것을 알 수 있다. HKEY_LOCAL_MACHINE, HKEY_CLASSES_ROOT, HKEY_CURRENT_CONFIG, HKEY_CURRENT_USER, HKEY_USERS라는 이름을 가진 5개의 서브트리가 있다. 이것을 C: D: 등의 루트폴더로 이해하면 쉽다.

뭐가 이렇게 복잡한가 싶지만 사실 그렇지만은 않다. 구분지어 본다면 HKEY_CURRENT_USER, HKEY_USERS는 시스템에서 로그온 하는 사용자에게 주어지는 설정을 담은 레지스트리이고, 나머지는 로그온하는 사용자와는 상관없이 시스템 자체에 주어지는 설정을 담고 있다. 예를 들어서 우리가 컴퓨터에서 TCP/IP설정을 변경했다면 이것은 로그온 하는 사용자와는 상관없는 시스템 설정이 변한 것이다. 이것들은 HKEY_LOCAL_MACHINE 이라는 서브트리에 저장되는 정보이다.

5개의 서브트리중에서 관리자가 직접 이 레지스트리 편집기를 통해서 작업을 하는 대부분의 경우는 HKEY_LOCAL_MACHINE 서브트리에서 이루어진다. 줄여서 “HKLM”이라고도 부르는 이 서브트리의 이름은 기억을 해 두기 바란다. 다른 서브트리의 경우는 직접 편집기로 편집하는 경우는 극히 드물다.

각 서브트리마다 키(KEY)들이 존재하고, 키 아래에는 서브키들이 있다. 최종적으로 가장 아래에 위치한, 윈도우 탐색기를 예를 들면 파일에 해당하는 값(VALUE)이 오른쪽 패널에서 펼쳐진다. 이 값들은 저마다 고유한 데이터를 가지고 있게 되며 데이터의 형식에 따라서 5가지 데이터 타입으로 구분할 수 있다.

레지스트리에 특별한 값을 하나 추가하는 작업을 예제로 알아보자. 당신은 Windows Server 2003를 테스트중이다. 시스템을 재시작하는 일을 반복해야 하는데 그때마다 로그온을 하기가 번거로워 자동으로 시스템에 로그온 하는 방법을 찾다 보니, 레지스트리를 직접 수정하면 가능하다는 것을 알게 되었다. HKLM > Software > Microsoft > Windows NT > CurrentVersion > Winlogon 키(KEY) 아래에 ‘AutoAdminLogon’이라는 값(VALUE)을 추가하고 ‘REG_SZ’데이터형식으로 “1”이라는 데이터를 입력하면 된다고 한다. 작업을 해 보자. 같은 방법으로 DefaultPassword라는 값(Value)을 추가하고 'REG_SZ'데이터형식으로 '실제 패스워드'를 데이터로 입력한다.

먼저 레지스트리 편집기를 열고, 값을 추가하고자 하는 키까지 찾아서 이동한다<그림11-48>

값을 추가하고자 하는 키를 클릭한 상태에서 편집메뉴의 ‘값 추가’를 선택한다.

‘값 추가’화면에서 ‘값 이름’에는 AutoAdminLogon이라고 입력하였다. 조금이라도 틀리면 원하는 대로 동작하지 않는다. 데이터 형식은 REG_SZ 를 선택했다. 역시 이것도 형식이 다르면 해당 값은 의미가 없다.

값 이름’을 지정한 후 [확인]을 누르면 ‘문자열 편집기’가 나온다. 문자열에 ‘활성화’를 의미하는 레지스트리 데이터인 ‘1’을 입력하고 [확인]을 눌러서 작업을 마친다.

<그림11-51>을 보면 AutoAdminLogon이라는 값(VALUE)가 추가된 레지스트리를 볼 수 있다.

서버의 하드디스크는 ‘관리’되어야 한다. 당신의 회사가 서버로서 PC급의 시스템을 사용하는 것이 아니라 전용서버제품을 구입하여 사용한다면 보다 좋은 선택이라 할 수 있다. 그만큼 비용의 측면이 감수되어야 하지만 보통의 경우 투자한만큼 만족할 만한 성능과 안정성을 보장하기 때문이다. PC급의 시스템을 사용할 때도 적은 투자비용으로 최대의 안정성을 확보하기 위해서 디스크를 효율적으로 관리하는 방법을 찾아보자. 또, 이러한 기술은 윈도우 서버에서 제공되는 소프트웨어적인 기능이기는 하지만 전용서버에서 하드웨어적으로 지원되는 것과 기술적인 측면은 별 차이가 없는 만큼, 이론적으로도 알아둘 만한 내용이다.

디스크를 사용하기 위해 먼저 파티셔닝을 하게 되고, 논리적인 몇 개의 영역으로 나눠서 디스크를 사용하게 되는데, DOS시절에는 어차피 디스크 크기가 커 봐야 1기가도 되지 않았기에 디스크 하나에 파티션 하나만 사용해도 충분했다. 점점 하드디스크의 크기가 커지면서 2개 이상의 파티션을 사용하게 되었고 파티션은 주(Primary) 파티션과 확장(Extended) 파티션이라는 2가지로 구분이 되었다. 첫번째 잡히는 파티션이 주 파티션이 되고 하나의 디스크에는 하나의 주 파티션만 있을수 있다. 주 파티션에 시스템이 부팅하는데 필요한 영역을 담을 수가 있다. 일반적으로 C: 로 사용되는 것이 그것이다. 확장 파티션에는 논리 드라이브라는 이름으로 원하는 만큼 드라이브를 추가하는 것이 가능하다. 그래서 정확히 표현한다면 디스크의 파티션은 ‘주 파티션’과 ‘확장 파티션 내의 논리파티션’이라고 나눌 수가 있겠다. NT부터는 이러한 주 파티션이 하나라는 제한이 아닌 최대 4개까지 생성하는 것이 가능해졌다. 하나의 디스크당 최대 4개의 주파티션을 생성할 수 있다. 혹은 3개의 주파티션과 1개의 확장파티션을 가지는 것도 가능하다. 하나의 디스크에서 5개 이상의 파티션을 필요로 한다면 반드시 후자를 따라야 한다. 하나의 확장파티션을 만든 다음에 그 안에서 논리드라이브를 만드는 방법을 이용해야 한다는 것이다.

Windows 2000부터는 기본디스크로서 시스템의 디스크를 관리하는 것뿐만 아니라 동적디스크로 디스크를 업그레이드하여 ‘볼륨(Volume)’단위로 디스크를 관리할 수 있게 해 준다. 기본디스크로 사용하는 것에 비하여 동적디스크는 디스크확장의 효율성, RAID1, RAID5등으로 디스크 오류제어의 효율성 등을 제공한다.

11-3-1-1. 디스크 관리 도구

DOS나 Windows9x에서 디스크를 관리하기 위해서 Fdisk 를 사용해 본 경험이 있을것이다. Windows NT계열의 OS에서는 디스크관리를 위한 특별한 도구가 제공된다. ‘컴퓨터관리’ 관리콘솔을 통해서 접근할 수도 있다<그림11-7>. 그러나 그것보다는 ‘시작à실행’창에서 diskmgmt.msc 라고 입력해 보자. 그러면 ‘디스크 관리’ 도구가 뜨는 것을 확인할 수 있을 것이다<그림11-9>

이 디스크 관리도구를 통해서 여러가지 정보를 살펴보고 추가작업을 할 수도 있다.

현재 이 시스템에는 하드디스크가 하나있고(디스크0), CD Rom 드라이브 2개가 있다.(CDRom0, CDRom1) 디스크0 는 현재 기본디스크로 설정이 되어 있으며 파티션이 3개가 있는데 C:는 주파티션이고, 일부 영역은 확장파티션으로 구성이 되어 있다. 확장파티션에는 D:라는 하나의 논리 드라이브가 잡혀 있고, 마지막에 7M의 공간은 파티션이 나누어져 있지만 C: D:와 같은 문자열이 할당되지는 않았다. 폴더의 형태로 마운트되어 있는 것이다. 마지막에 있는 ‘새 볼륨’에 마우스 오른쪽 클릭해 보니 몇가지 메뉴가 눈에 띈다. ‘파티션 활성화’를 통하여 Active Partition으로 지정할 수도 있다. 이것은 주 파티션으로 나뉘어 있을때만 가능한 작업이다. 위에서 주 파티션만 시스템 파티션이 될 수 있다고 한 것을 기억하라. D:와 같은 드라이브 문자를 변경할 수도 있으며, 새롭게 포맷을 한다거나, 파티션을 삭제하는 작업들도 가능하다. 구체적인 설명은 하지 않겠다. 인터페이스가 간결하여 쉽게 알 수 있을 것이다.

11-3-1-2. 파티션 관리하기

중요한 내용 하나를 정리하고 가자. 하나의 디스크에 생기는 여러 개의 파티션이 있는데 시스템은 이 파티션마다 번호를 붙여서 각 파티션을 구별하게 된다. 디스크, CPU, 메모리, 확장슬롯 등이 0번부터 번호가 시작되는 것과는 달리 파티션 번호는 1번부터 시작된다. 파티션1, 파티션2… 와 같은 형식을 말한다. 파티션 번호를 붙이는 방법은 디스크마다 별도로 주파티션을 1,2,..등의 순서대로 할당한 다음에 논리드라이브 3,4,.. 의 순서로 정의된다. 순서가 뭐가 중요할까 싶기도 하지만 이것 하나 때문에 시스템이 부팅이 되지 않는 상황까지 생기기도 한다. 잘 정리하자. <그림11-10>을 예로 들어보자.

<그림11-10>의 디스크0을 보면 파티션이 3개로 나뉘어 있는 것을 알 수 있다. 주파티션인 C:와 확장파티션내의 논리드라이브인 D: 그리고 폴더에 마운트된 주 파티션으로 나뉜 볼륨 하나가 있다.  파티션 번호를 붙여보면 첫번째 파티션인 C:는 1번, D:는 3번, 맨뒤의 7M 영역이 2번이 된다. D:가 먼저여서 2번인것처럼 보이지만 뒤의 영역이 주파티션으로 만들어져 있으므로 그것이 2번이 되고, 논리드라이브인 D:는 3번이 할당되는 것이다.

디스크1번을 보면 E:와 F:가 있다. 이들은 각각 디스크1번에 있어 파티션 1번과 파티션 2번을 차지하고 있다. F:는 NT가 설치되어 있는 부트파티션이다. 그 뒤로 2개의 영역이 더 보이는데 이것은 아직 파티션이 구성되어 있지 않기 때문에 파티션 번호가 할당되지 않는다. 이들 2개의 영역을 살펴보면 서로 다르다는 것을 알게 되는데, 그림에서 세번째 영역으로 보이는 1.56GB의 공간은 확장파티션 안에 있는 빈 영역이고, 마지막의 2.93GB의 공간은 아예 할당되지 않은 공간이라고 되어 있다.

위의 상황에서 당신이 만일 확장파티션의 빈공간인 세번째 영역에 G:를 생성했다고 한다면 그 G:의 파티션 번호는 3번이 된다. 기존의 E:와 F:의 파티션 번호에는 영향을 미치지 않는다<그림11-11>

하지만 할당되지 않은 빈공간인 네번째 영역에 G:를 생성하면 상황은 달라진다. 파티션 번호가 할당되는 것이 논리드라이브보다는 주 파티션이 우선하기 때문에 G:가 2번이 되고 기존의 F:는 2번 대신에 새로운 파티션 번호인 3번이 할당되게 되는 것이다<그림11-12>

이 결과로 시스템은 부팅할 때 기존의 파티션2번을 찾아서 부팅을 시도하지만 새로운 드라이브가 생기면서 WINNT 폴더를 담고 있는 파티션이 3번으로 변경되었기 때문에 부팅프로그램은 부팅에 실패하게 된다. 이 경우 부팅시 이러한 위치를 지정해 주는 파일인 boot.ini 에 올바른 파티션 번호를 수정해 주어야 한다. 시스템파티션의 루트에 있는(일반적으로 C:) boot.ini 파일을 살펴보면 파티션 번호를 확인할 수 있다. (boot.ini는 숨김, 시스템 속성을 가지고 있는 파일이므로 기본적으로 보이지 않는다. 폴더옵션을 변경하거나 실행창에서 “notepad c:\boot.ini”를 입력하여 파일을 열어본다.) 그러한 파일의 변경을 자동으로 수행하지 않기 때문에 이러한 파일의 사용법등에 대해서는 뒤에서 다시 설명하도록 한다.

11-3-1-3. 동적 디스크로 업그레이드하기

보다 효율적인 디스크관리를 위해서는 동적디스크를 사용한다고 했다. 단일 하드디스크를 가진 시스템에서는 특별한 필요성을 찾지 못하지만, PC를 회사의 서버로 사용하고 있는 경우라면 가급적이면 2개 이상의 하드디스크를 장착하고 동적디스크로 업그레이드를 하면 전용서버 부럽지 않은 하드디스크 관리를 할 수 있다.

<그림11-13. 동적디스크로 업그레이드 과정1>	디스크 관리도구에서 디스크의 정보를 나타내는 부분을 마우스 오른쪽 클릭하고 ‘동적디스크로 업그레이드’를 선택한다.
<그림11-14. 동적디스크로 업그레이드 과정 2>	동적디스크로 업그레이드 할 디스크를 선택한다.
<그림11-15. 동적디스크로 업그레이드 과정 3>	업그레이드할 디스크의 목록을 재 확인하고, [업그레이드]버튼을 클릭한다.
<그림11-16. 동적디스크로 업그레이드 과정 4>	이전버전의 OS로는 부팅할 수 없다는 경고메시지이다. 그냥 해 보는 소리가 아니다. 주의해야 할 것이다.
<그림11-17. 동적디스크로 업그레이드 과정 5>	동적디스크는 기본디스크와 디스크 관리방법이 달라진다. 기존의 파일시스템은 볼륨이라는 새로운 단위로 변경되게 된다. 파일시스템을 분리시킨다는 메시지가 나온다. [예]를 누른다.
<그림11-18. 동적디스크로 업그레이드 과정 6>	과정은 모두 마쳤다. 시스템을 재시작하면 업그레이드가 완료된다.

11-3-1-4. 단순볼륨 (Simple Volume)

가장 기본적인 볼륨이다. 아무런 추가설정이 필요없는 단일볼륨을 일컫는다. 기본디스크의 파티션과 차이가 없이 D: E: 등의 문자열을 할당하거나, 폴더에 볼륨을 마운트시키는 것이 가능하다. 이 단순볼륨은 스팬볼륨을 이용하여 공간을 확장하거나, 미러볼륨을 구성할 수 있는 기본적인 하나의 볼륨이 된다.

11-3-1-5. 스팬볼륨 (Spanned Volume)

동적디스크를 사용하면 몇가지 새로운 기능을 구현할 수 있다. 첫번째로 스팬볼륨에 대해서 살펴보자. 스팬볼륨은 이전 버전에서 ‘볼륨셋’이라고 불리웠던 기능이다. 한마디로 설명하면 디스크 공간을 효율적으로 써 보자는 것이다. 기존에 파티션을 잡아서 사용하고 있었는데 공간이 부족할 때 스팬볼륨을 사용해서 파티션을 확장할 수 있다. 또한 2개의 디스크가 있었는데 하나는 200MB, 하나는 300MB가 남았다고 가정했을 때 2개의 공간을 각각 D: E: 형태로 사용하지 않고 500MB 전체를 하나의 D:로 잡아서 사용하는 것이 가능하다.

하지만 공간을 효율적으로 쓰는 것은 가능하지만 스팬볼륨의 멤버로 되어 있는 디스크중 하나만 손상이 되어도 해당 파티션은 쓸 수가 없다는 단점이 있어서 현실적으로 서버에는 권장하지 않는 방법이다. 추가로, 스팬볼륨은 시스템파티션이나 부트파티션에는 구현될 수 없다.

예제를 통해서 스팬볼륨의 구현과정을 알아보자.

<그림11-19. 스팬볼륨 생성과정 1>	예제에서는 디스크0번과 1번, 2개의 디스크를 가진 시스템을 보여준다. 디스크0번의 할당되지 않은 4.31GB의 영역을 마우스 오른쪽 클릭하고 ‘볼륨 만들기’를 선택했다.
<그림11-20. 스팬볼륨 생성과정 2>	볼륨종류를 살펴보면 단순볼륨, 스팬볼륨, 미러볼륨, 스트라이프 볼륨이 활성화되어있고, RAID-5 볼륨은 비활성화되어 있는 것을 볼 수 있다. 이어서 설명을 하겠지만 RAID-5볼륨은 최소 3개의 물리적인 디스크가 필요하므로 비활성화된 것이다.
<그림11-21. 스팬볼륨 생성과정 3>	‘디스크 선택’화면에서 왼쪽의 ‘사용 가능한 모든 동적 디스크’에서 스팬볼륨을 구성할 디스크를 선택하고, 크기를 선택하여 [추가>>]버튼을 눌러서 오른쪽으로 선택되도록 한다. 예제에서는 디스크0번에 200MB, 디스크1번에 200MB로 총 400MB의 볼륨을 구성하였다. 두개의 디스크의 사이즈는 같지 않아도 무방하다.
<그림11-22. 스팬볼륨 생성과정 4>	다음부터는 파티션을 생성하는 과정과 차이가 없다. 드라이브 문자를 할당하거나, 하나의 폴더에 볼륨을 마운트시킬 수 있다.
<그림11-23. 스팬볼륨 생성과정 5>	원하는 파일시스템으로 볼륨을 포맷한다.
<그림11-24. 스팬볼륨 생성과정 6>	작업이 완료되었다.

11-3-1-6. 스트라이프 볼륨 (Striped Volume)

스트라이프 볼륨은 디스크 I/O(Input/Output) 성능개선을 위해서 제공된다. 자료에 따르면 단순볼륨에 비해 스트라이프 볼륨은 30% 정도의 입출력 성능 개선효과가 있다고 한다. 디스크에 데이터를 기록하는 방식 자체가 다르다. 현실적으로 일반PC에서 사용하는 IDE나 EIDE등의 컨트롤러 타입의 경우는 큰 성능의 증가를 보기는 어렵지만 대부분의 서버제품군에서 사용되는 SCSI 컨트롤러 타입의 경우에는 제대로된 성능향상을 제공한다. 그런 이유로 서버제품에서는 SCSI를 주로 사용하고 있는 것이다.

스트라이프 볼륨을 구성하면 디스크순서대로 데이터를 기록하는 것이 아니라, 64KB단위씩 평행하게 데이터를 병렬로 써 나가게 된다. 예를 들어 두개의 디스크로 스트라이프 볼륨을 구성했다면 첫번째 디스크에 64KB만큼 데이터를 기록하고, 다음엔 두번째 디스크에 64KB단위로 데이터를 기록한다. 다시 첫번째 디스크에 데이터를 기록하기 시작한다. 이렇듯 반복해서 2개의 디스크를 번갈아가면서 기록하기 때문에 입/출력 성능을 높여줄 수 있게 되는 것이다. 에서는 최소 2개에서 최대 32까지의 디스크를 스트라이프 볼륨으로 구성하는 것이 가능하다. 시스템파티션이나 부트파티션에는 구현될 수 없는 방법이다.

이러한 스트라이프 볼륨은 디스크 입/출력 성능을 높여줄 수 있다는 큰 장점이 있지만 역시 하드디스크의 물리적인 오류에 대해서는 아주 민감하다. 스트라이프의 멤버로 된 디스크중 하나만 손상이 되어도 전체 스트라이프 영역의 데이터를 읽을 수가 없게 되기 때문에 소프트웨어적인. 즉 서버 자체적으로 제공되는 스트라이프 볼륨은 현실적으로 사용을 권하지 않는다. 이론적으로만 이해하자. 그렇다면 서버에는 어떠한 기술들을 사용해야 할까? 기본적으로 서버에 요구되는 사항은 디스크중 하나의 디스크가 손상이 되었을 경우에도 오류를 극복(Fault-Tolerance)할 수 있는 방법이 필요한 것이다. 이러한 요구를 위해서 마이크로소프트는 RAID (Redundant Array Independent Disk) 기술을 지원하고 있다. 다음에 소개되는 미러볼륨과 RAID-5볼륨이 바로 그것이다.

11-3-1-7. 미러 볼륨 (Mirrored Volume)

하드디스크의 물리적인 결함을 극복할 수 있는 방법은 어떠한 것이 있을까? 어떤일이 있어도 하드디스크가 결함이 생기지 않도록 한다? 좋은 방법이지만 현재로서는 그런 기술은 없다. 그렇다면 다음으로 생각할 수 있는 것은 하드디스크를 ‘하나 더’ 가지는 방법이 있다. 바로 하드디스크를 중복해서 사용함으로써 데이터를 2중으로 가져 가겠다는 것을 뜻한다. 그러한 방법이 바로 ‘미러 볼륨’으로 구현된다.

미러볼륨의 주된 사용용도는 시스템파티션과 부트파티션이다. 시스템파티션은 보통 C:를 일컬으며 부트파티션은 OS가 설치된 폴더가 있는 파티션을 가리킨다. 하나의 디스크에 OS를 설치했을 때 당신은 시스템의 건강을 위해서 지속적으로 서비스팩을 패치하고, 알려진 바이러스를 탐지할 수 있는 도구도 설치했으며 마이크로소프트 웹사이트로부터 지속적으로 핫픽스를 통해서 버그를 패치하고 있다. 하지만, 그런 노력에도 불구하고 하드디스크가 망가지는, 어찌보면 어이가 없을수도 있는 일이 발생한다면 그런 노력은 허사가 되고 만다. 물론 백업된 데이터가 있고, 시스템을 재설치하면 될 일이겠지만 그렇게 하기에는 많은 시간과 수많은 사용자들의 원성을 살 수 밖에 없을것인데 미러볼륨은 간단히 문제를 해결해 줄 수 있다. 동일한 설정, 동일한 데이터를 가진 또 다른 디스크 하나에 복제를 떠 놓겠다는 것이다. 말 그대로 “디스크 미러(거울)”이다.

그렇게 하면 안심이다. 하나의 디스크가 망가졌어도 동일한 내용을 담은 디스크가 하나 더 있으므로 즉시 관리자는 미러된 디스크로 시스템을 재 시작시키면 시스템이 부팅되는 정도의 시간만 있으면 정상적인 서비스를 계속하도록 유지할 수가 있다. 잘 돌아가는 시스템이라고만 생각하면 디스크는 분명히 낭비가 될 수도 있지만, 디스크 하나 더 장착하는 비용으로 믿을만한 서버가 된다면 훌륭하지 않은가? 그것도 수천, 수억원 대의 전용서버가 아니라 고작 1,2백만원 정도의 PC로써 말이다.

미러 볼륨은 2개의 디스크를 필요로 한다. 지금 당신의 서버가 단일디스크를 가진 시스템이라면 당장 디스크를 하나 더 장착하자. 아주 간단히 구현할 수가 있다. 예제를 통하여 캡처한 그림을 참고한다.

<그림11-26>을 보면 디스크0번부터 디스크2번까지 3개의 디스크를 가진 시스템이라는 것을 알 수 있다. 디스크0번의 C:는 시스템 파티션인 동시에 부트파티션이다. C:에는 Windows Server 2003이 설치되어 있다. 먼저 미러볼륨을 구성하기 위해서 디스크 3개를 모두 ‘동적 디스크’로 업그레이드를 해 두었다. 업그레이드 방법은 “11-3-1-3. 동적 디스크로 업그레이드하기”에서 설명하였다.

미러볼륨을 구성하기 위해서 먼저 미러를 구성할 원본이 되는 볼륨을 마우스 오른쪽 클릭하여 ‘미러 추가’를 선택한다<그림11-27>.

미러볼륨이 될 복제대상 볼륨을 지정해 준다. 예제에서는 디스크1번에 만들겠다고 설정했다. [미러추가]버튼을 클릭한다.

볼륨을 미러했다는 메시지가 나온다. 아직 끝난 것은 아니다. 중요한 것은 ‘미러 디스크에서 부팅할 수 있게 하려면 boot.ini 파일에 적절한 항목을 추가하라’는 메시지이다. Boot.ini 파일이 시스템이 부팅할 때 필요로 하는 “OS가 설치된 폴더”의 위치를 알려준다. 이 파일에 만일 원본볼륨을 담고 있는 디스크가 물리적으로 손상이 되었을 때 동일한 내용을 복제해 둔 미러볼륨을 통해서 부팅을 할 수 있도록 boot.ini 파일에 그러한 경로를 추가하라는 것을 의미한다.

<그림11-30>은 <그림11-29>의 메시지에서 보여주는 것처럼 boot.ini파일을 편집한 그림이다. Boot.ini 파일은 텍스트 파일이다. 메모장으로 열어 볼 수 있는데, 맨 아래의 한줄이 편집된 내용이다. 하이라이트된 부분을 바로 위의 줄과 비교해 보면 rdisk(0)이 rdisk(1)로 바뀌었고, Microsoft Windows 2000 Advanced Server 뒤에 “(Mirror)”이라는 문구가 추가된 것을 알 수 있다. 이제 이 시스템에서 부팅을 하게 되면 당신은 부팅시 이 두가지중 하나를 선택하도록 요구받게 될 것이다. 리스트중 두번째를 선택하면 첫번째 디스크의 원본볼륨을 통해서 부팅하는 것이 아니라, 두번째 디스크의 미러볼륨을 통해서 부팅을 하게 된다.

위의 사항들을 잘 이해했다면 한가지 의문이 생길 것이다. Boot.ini 파일이 위치해 있는 곳이 C: 였는데, 디스크0번이 손상된 상태에서 이 파일에 접근을 못하는 것이 아닌가? 맞다. 그렇게 된다. 그래서 미러볼륨으로부터 시스템을 부팅시키기 위해서 ‘부팅 디스켓’을 생성해야 한다. 부팅 디스켓 생성에 대해서는 이번장의 후반부에서 소개되는 “부팅 디스켓 만들기”를 참고한다.

<그림11-31>은 작업을 마치고, 시스템이 미러볼륨을 구성하는 과정을 캡처한 화면이다. 64%라고 진도를 보여주는데, 이 과정에서 원본볼륨이 완전하게 미러볼륨으로 복제가 일어난다.

미러볼륨이 완성되었다. 디스크 1에도 5GB크기의 C:가 생겼다. 윈도우탐색기를 통해서 들여다 보면 단지 C: 로만 보일 뿐이다. 하지만 C:에 새로운 데이터를 저장하면 그때는 실제로는 두 개의 디스크에 동시에 데이터가 쓰여지게 된다. 디스크0번이 망가지더라도 걱정이 없다. 완전한 복제본인 디스크1이 있으니까.

더 이상 미러볼륨을 원하지 않는다면 미러볼륨을 해제하는 작업으로서 간단히 관계를 끊을 수 있다.

이것은 데이터 손실이 발생하지 않는 작업이다. 다만 미러가 제거되었으므로 더 이상 복제가 일어나지 않을 뿐이다. 독립적인 2개의 볼륨이 되는 것이다.

11-3-1-8. RAID-5 볼륨 (Stripe Set with Parity)

RAID-5볼륨은 스트라이프 볼륨의 연장선이라고 할 수 있다. 앞에서 스트라이프 볼륨의 장점은 디스크 입/출력 성능의 향상을 가져온다고 했는데, 하드 디스크의 물리적인 오류에 민감하다는 제약이 따른다고 했다. 그것을 해결하기 위해서 패리티(Parity)라고 부르는 특별한 비트를 디스크에 저장하게 되었다. 스트라이프 볼륨의 장점을 살리면서 디스크의 오류까지도 해결하겠다는 것이다. <그림11-34>을 보면서 설명한다.

<그림11-34>의 예제에서는 3개의 디스크로 구성된 RAID-5 볼륨을 보여준다. 디스크 3개를 평행하게 배열하고 이들은 각각 64KB 단위씩 스트라이핑이 구성된다. 스트라이프1부터 시작해서 데이터를 기록해 나가는데, 3개의 디스크에 모두 데이터가 기록되는 것이 아니라 2개의 디스크에만 데이터가 기록되고 나머지 하나의 디스크 공간에는 2개의 디스크의 데이터를 계산한 값이 기록된다. 이 값을 가리켜서 Parity라고 부른다. 이때 계산방식으로는 Xor연산[1]이 사용된다. 계산방법이 중요한 것이 아니라 이것을 이해하는 것이 중요하다.

위의 예제에서 RAID-5 볼륨을 구성하고 처음 데이터를 기록한다고 가정을 해 보자. 그때 데이터는 디스크1의 처음 스트라이프1에 기록되고, 다음에 디스크2의 스트라이프2에 기록된다. 디스크0에는 디스크1과 디스크2의 데이터를 Xor연산을 통하여 계산된 값. Parity 비트를 기록하는 것이다. 두번째 스트라이프에서는 디스크0과 디스크2에 데이터를 기록하고 디스크1에는 패리티, 세번째는 디스크0과 디스크1에 데이터를 기록하고 디스크2에 패리티, 이런 방식으로 디스크를 기록해 나간다.

그렇다면 어떻게 되는가? 디스크가 3개이지만 실제로 1/3에 해당하는 하나의 디스크 공간만큼은 데이터가 기록되지 않기 때문에 디스크 낭비라는 생각이 들 수도 있을 것이다. 하지만 하드디스크의 물리적인 오류가 생겼을 때 이 문제를 RAID-5 볼륨은 해결할 수 있다. 3개의 디스크중 하나에 결함이 발생하더라도 다시 원본데이터를 계산해 내는 것이 가능하기 때문이다. 어떻게? 위의 예제에서 디스크1번이 손상되었다고 가정했을 때 관리자가 할 일은 새 하드디스크를 넣고 “RAID-5 볼륨 재구성”이라는 메뉴만 관리도구에서 돌려주면 시스템은 원본 데이터를 복구해 내게 된다. 이때의 방법은 처음 데이터를 기록할 때와 차이가 없다. 순수한 데이터만이 아닌 데이터를 기준으로 특별한 원칙하에 패리티 비트가 기록되어 있기 때문에 가능한 것이다.

스트라이프 볼륨이 3개의 디스크에 전체를 데이터만 기록했던 것과 비교해서 디스크 낭비, 상대적인 쓰기 성능의 저하 등을 가져올 수는 있지만 서버에서는 무엇보다 데이터를 보호하기 위한 방법으로서 RAID-5가 사용될 수 있다. 디스크 입/출력의 성능을 요구하는 DB서버, 파일서버 등의 서버를 구축할 때 최상의 솔루션을 제공할 수 있을 것이다.

필자가 캡처한 예제를 통하여 구현과정을 살펴보자.

예제에서는 디스크3개를 가진 시스템을 보여준다. 이미 C:는 미러볼륨으로 구성되어 있고, 디스크0,1,2 에는 각각 916MB, 32GB, 18GB의 남은 공간이 있다. 이 디스크들로써 RAID-5 볼륨을 구현할 때 만들수 있는 최대크기는 얼마나 될까? 스트라이프의 동작원리를 이해하면 정답이 나온다. 스트라이프 볼륨을 구성할 때는 디스크의 각 볼륨이 동일한 크기로 구성이 되어야 한다. 당연히 위의 상황에서는 가장 작은 크기에 맞춰질 수밖에 없을 것이다. 그래서 916MB*3=2,748MB가 구현할 수 있는 최대사이즈가 된다. 하지만 이것도 전체사이즈가 되지는 않는다. 실제로 데이터가 들어갈 수 있는 공간은 패리티가 차지할 공간을 제외한 2/3이 된다. 즉 916MB*2=1,832MB가 데이터가 된다. 

<그림11-35. RAID-5 볼륨 구현과정 1>	할당되지 않은 빈 공간을 마우스 오른쪽 클릭하고 ‘볼륨 만들기’를 선택한다.
<그림11-36. RAID-5 볼륨 구현과정 2>
<그림11-37. RAID-5 볼륨 구현과정 3>	RAID-5 볼륨도 활성화 된 것이 보인다. 물리적인 디스크가 3개 이상이므로 활성화되는 것이다. RAID-5 볼륨을 선택하고 [다음]을 누른다.
<그림11-38. RAID-5 볼륨 구현과정 4>	‘디스크 선택’화면에서 왼쪽의 ‘사용 가능한 모든 동적 디스크’에서 디스크0,1,2를 선택하여 [추가>>]버튼을 눌러서 선택되도록 하고, 아래쪽에 크기를 결정해 주어야 한다. 3개의 디스크는 동일한 크기로만 구성될 수가 있다. <그림11-38>의 예제에서는 900MB를 선택했다. ‘총 볼륨 크기’가 1800MB만 나타내고 있는 것을 주목한다. 900MB*3=2700MB이지만 1/3인 900MB는 패리티 비트가 차지할 공간이므로 크기에 포함되지 않은 것이다. 최대크기는 916MB임을 보여 주는데, RAID-5 볼륨을 구성하는 디스크중에서 가장 작은 여유공간에 맞춰서 만들수 있음을 보여준다.
<그림11-39. RAID-5 볼륨 구현과정 5>	나머지 과정은 다른 볼륨 생성과 차이가 없다. 드라이브 문자열을 할당하거나 폴더에 볼륨을 마운트 시킬 수 있다.
<그림11-40. RAID-5 볼륨 구현과정 6>	기본적으로 NTFS 파일시스템으로 포맷하도록 선택되어 있다. 서버에서 NTFS를 사용한다는 것은 기본적인 일이다. 그대로 [다음]을 클릭한다.
<그림11-41. RAID-5 볼륨 구현과정 7>	거의 모든 작업을 할 때마다 항상 마지막에서는 당신이 선택했던 작업들을 요약해서 보여주는 화면이 나온다. 한번쯤 들여다 보라. 실수를 막을수 있을 것이다.