RAID (Redundant Array of Independent Disks)는 여러 개의 하드디스크를 통하여

대용량 디스크 또는, 데이타 속도 증가, 데이타 백업, 안정성을 높이는데 사용이 된다.

RAID는 설치 할 때 용도에 맞게 선택을 잘 하여야만 하는데, 이는 득이 될 수도 있고

실이 될 수도 있으니 초기 세팅시에 주의를 하여야 한다.

왜냐하면, 사용 도중 다른 레벨로 세팅을 하거나 다른 환경 변화에 따라 대용량의

주요 데이타를 유실되거나 백업하는 수고가 생기가 된다.

수 많은 RAID가 있지만 가장 많이 사용하고 있는 몇 가지 레벨만 기술하려 한다.

 

1. 개별하드 방식
  1) 최소 하드디스크 개수 : 1
  2) 최대 용량 : 하드디스크 용량
  3) 설명 : 컴퓨터 내부에 있는 하드디스크의 D: E: F: G: 처럼 사용을 하는 것인데, 대부분
         JBOD라고 하지만 실제적으로 JBOD의 의미와는 다른 것이다.
         또한, RAID에는 개별하드 방식이란 것은 없다.
         다만, RAID를 설명하기 위하여 기술을 하였다.
  4) 장점 : RAID를 사용하지 않기 때문에 디스크를 이리 저리 옭기는 이동성이 좋다.
         디스크 장애시에 장애 디스크의 데이타만 유실된다.
  5) 단점 : 컴퓨터에 많은 디스크가 보여 관리하기 힘들고, 대용량 파일 저장이 힘들다.

 

2. RAID 0 (스트라이핑(striping))
  1) 최소 하드디스크 개수 : 2
  2) 최대 용량 : 하드디스크의 수 x 하드디스크 용량
  3) 설명 :
    -. 일반적으로 데이타 속도를 높인다던가 대용량 디스크로 만들어 사용하는 영상편집
       작업용 스토리지에 사용된다.
    -. 컴퓨터에서 1개의 하드디스크 처럼 보이는데, 각 하드디스크를 계속 합하는것과 같다.
    -. 하드디스크가 증가 할 수록 디스크 용량 및 속도가 증가한다.
  4) 장점 :
    -. 데이타 속도가 가장 빠르다.(이론상 하드디스크 1개 속도 x 하드디스크의 수)
    -. 컴퓨터에서 1개의 디스크만 보이므로 관리하기 편하다.
    -. 대용량 디스크가 되므로 대용량 파일을 용이하게 저장 할 수 있다.
    -. 150MB/s 이상 속도의 영상편집의 작업용으로 적합하다.
  5) 단점 :
    -. 1개의 하드디스크가 장애가 나면 전체 하드디스크의 데이타를 유실하므로
       가장 불안전하다.
    -. 필히 디스크의 데이타를 실시간 백업을 해야한다.

 

3. RAID 1 (미러링(mirroring))
  1) 최소 하드디스크 개수 : 2
  2) 최대 용량 : (하드디스크의 수/2) x 하드디스크 용량
  3) 설명 :
    -. 원본 하드디스크와 복사본 하드디스크가 있다고 생각하면 된다.
    -. 전체 하드디스크 중 반은 원본 데이타가 있고 반은 복사본 데이타가 있다고

       생각하면 된다.
    -. 따라서, 실제적으로 절반의 하드디스크만 사용하게 된다.
    -. 데이타를 안전하게 보존 하는 용도로 사용 된다.
    -. 컴퓨터에서는 2개 중 1개만 보이게 된다.(4개 중 2개......)
  4) 장점 :
    -. RAID 중 가장 데이타를 안전하게 보존한다.
    -. 1개의 하드디스크 장애시 새로운 하드디스크 장착으로 데이타를 복구 시킬 수 있다.
  5) 단점 :
    -. 하드디스크를 절반만 사용하게 되므로 백업 디스크가 매우 아깝고 그 만큼 돈도

       많이 든다.

  
4. RAID 5 (Parity)
  1) 최소 하드디스크 개수 : 3
  2) 최대 용량 : (하드디스크의 수-1) x 하드디스크 용량
  3) 설명 :
    -. 각 하드디스크에 데이타 정보가 들어있는 Parity를 저장한다.
    -. 1개의 하드디스크 장애시 새로운 하드디스크 장착으로 데이타를 복구 시킬 수 있다.
    -. 데이타를 안전하게 보존 하는 용도로 사용 된다.
    -. 컴퓨터에서 1개의 하드디스크 처럼 보인다.
  4) 장점 :
    -. RAID 1에 비하여 더 많은 용량의 데이타를 사용 할 수 있다.
    -. 데이타를 안전하게 보존한다.
  5) 단점 :
    -. 2개 이상의 하드디스크 장애시 데이타 손실이 일어난다.
    -. 디스크 생성 및 복구(rebuild)시에 많은 시간이 소요된다.
       (예 : 500G x 4EA = 2Tera 구성시 최소 12시간 이상 소요)
    -. 데이타 갱신시에 Parity 정보를 갱신해야 하기 때문에 속도가 느릴 수 있다.

 

5. RAID 0+1
  1) 최소 하드디스크 개수 : 4
  2) 최대 용량 : (하드디스크의 수/2) x 하드디스크 용량
  3) 설명 :
    -. RAID 0 생성 후에 RAID 1를 생성 한다고 생각하면 된다.
    -. 하드디스크를 합하고 복사본 하드디스크를 만드는 것과 같다.
    -. 대용량 데이타를 안전하게 보관하는 용도로 사용된다.
    -. RAID 1과 같이 실제적으로 절반의 하드디스크만 사용하게 된다.
    -. 컴퓨터에서 1개의 하드디스크 처럼 보인다.
  4) 장점 :
    -. 데이타 속도가 빠르다.(이론상 하드디스크 1개 속도 x (하드디스크의 수/2))
    -. 컴퓨터에서 1개의 디스크만 보이므로 관리하기 편하다.
    -. 대용량 디스크가 되므로 대용량 파일을 용이하게 저장 할 수 있다.
    -. 데이타를 안전하게 보존 한다.
    -. 1개의 하드디스크 장애시 새로운 하드디스크 장착으로 데이타를 복구 시킬 수 있다.
  5) 단점 :
    -. 하드디스크를 절반만 사용하게 되므로 백업 디스크가 매우 아깝고 그 만큼 돈도

        많이 든다.

 

6. RAID 레벨 비교
  1) 안정성 : RAID 1 > RAID 5 > RAID 0+1 > 개별하드방식 > RAID 0
  2) 속  도 : RAID 0 > RAID 0+1 > RAID 5 > 개별하드방식 > RAID 1

 

출처 : www.fgint.com www.colossus.co.kr

◎ KR도메인

한국인터넷정보센터 ROOT 네임서버 하루 3회 반영
- 1회 8:00 ~ 9:00 (전날 18:00시 ∼ 8:00시에 변경 접수된 도메인)
- 2회 12:00 ~ 13:00 (8:00시 ∼ 12:00시에 변경 접수된 도메인)
- 3회 18:00 ~ 19:00 (12:00시 ∼ 18:00시에 변경 접수된 도메인)
(예 : 네임서버를 20:00시에 변경했을 경우 익일 1회째 반영되며 반영 후 4~5시간 후 서비스 가능)

◎ 국제도메인

ROOT 네임서버에 하루 2회 반영
- 1회 : 01:00 ~ 02:00
- 2회 : 13:00 ~ 14:00
(반영 후 24시간~48시간 후 서비스 가능)

출처 : Tong - 훈스구락부님의 Network통

회계인사 신시스템 

1. 현 서버 사용 현황 

 

1. 사용 서버명

IBM RS/6000 SP2 Thin node 4대

2. CPU

CPU명 : Power2 66MHZ

CPU개수 : 4 CPU (1CPU * 4대)

3. Memory

1024 MB (256MB * 4대)

4. Disk

      내장 디스크 : 8.8GB (2.2GB * 4대)

외장 디스크 : 45GB (13GB + 12GB + 16GB + 4GB)

 

 

2. 현 서버 사용률 

 

1) CPU 

Node 1 : 60%-70%

        Node 2 : 65%-75%

        Node 3 : 80%-90%

        Node 4 : 80%-90%

2) Memory (실메모리 + 사용중인 가상메모리)

Node 1 : 98% ( 30438/31050 ) 

        Node 2 : 97% ( 36870/37960 )

        Node 3 : 97% ( 51707/53458 )

        Node 4 : 97% ( 44067/45252 )

 

3) 디스크 

Node 1 :  내장 85% (1828/2148)

          외장 45%(5856/13056)

        Node 2 :  내장 94% (2028/2148)

                  외장 60%(7352/12288)

        Node 3 : :  내장 94% (2028/2148)

                  외장 92%(15224/16608)

        Node 4 :  내장 99% (2128/2148)

                  외장 96%(4144/4296)

 

 

 

 

 

3.향후 시스템 확장 방안 

 

1. 전체 사용자수 : 200 명

2. 피크 타임시 최대 동시 사용자수 : 150 명 

3. 서비스 시간        : 09:00 – 17:00

4. 5년간 업무 증가율 : 년 30 % 증가 

 

1. 메모리 산정 기준 

1.         OS 커널 로드량                                            : 256MB

2.         OS 관리 영역(telnet, shell size,login user )   : 150 MB (1MB * 150)

3.         DB 엔진                                                                        : 80MB

4.         DB  SGA                                                          : 400MB

5.         MTS (멀티스레드방식)                   : 75MB (동시사용자 * 0.5MB = 150 * 0.5)

6.         어플리케이션 메모리                    : 75MB( 150 * 0.5)

7.         사용자 파일로드 :  1024MB

8.         버퍼케시율 : 20%                                                                      

(256 + 150 + 80+ 400 + 75 + 75+ 1024) * 1.2 = 2060 * 1.2 = 2472 MB

9.         업무중 배치 처리 : 15%

2472 * 1.15 = 2842MB

10.      시스템 여유율 : 40%

2842 * 1.4 = 3979 MB

 

메모리 용량은 최소 4015 MB 이어야 합니다.

 

2. 디스크 산정기준 

1. 내장 디스크 

1.         OS                                                                         : 2000 MB

2.         페이징 스페이스 : 실 메모리의 1배   : 4096 MB

3.         DB 엔진                                                             : 1500 MB

4.         어플리케이션 프로그램                             : 2000 MB

5.         여유율 : 50%                                                                       : 9596 MB * 1.5 = 14394 MB

 

2. 외장 디스크 

1.         순수DB 요구량(20GB로 가정)                                   : 2000 MB

2.         DB 구성 오버해드                                         : 2000 MB

3.         일반 DATA                          : 30000 MB

4.         RAID5 구성 시 오버해드 : 30%               : (2000 + 2000 + 30000) * 1.3 = 51000

5.         디스크 여유율 : 40%                                     : 51000 * 1.4 = 71400

 

디스크 용량은 내장 18.2GB, 외장 72GB 이어야 합니다 

[시스템 관리 노하우를 말한다] ③ 장애 복구와 ITIL 적용

 

연재순서
1회. 시스템 유지·보수와 성능 관리
2회. 고가용성과 시스템 용량 산정
3회. 장애 복구와 ITIL 적용

 

인터넷 의존도가 높아감에 따라 ‘Web time is Real Time’이라는 말은 이미 우리 생활의 필수 요구사항이 되었다. 갈수록 사용자들은 참을성을 잃어가고, 다양한 네트워크와 데이터 서비스 환경 하에서 장애(Crash) 처리에 소요되는 시간(MTTR :Mean Time to Recover)은 이제 촌각을 다투고 있다.

어쩌면 시스템 관리자에게 가장 귀찮은 일 중 하나인 백업과 복구에 대한 기술은 매우 복잡하게 얽혀 있으며, 반드시 하지 않으면 안 되는 업무 분야이기도 하다. 이 글에서는 이전 두 번의 연재와 함께 효율적인 시스템 관리란 주제로 다음의 6가지 사항 중 “장애복구”와 “ITIL”의 적용을 다루고 있다.

[1] 시스템 유지보수(System Maintenance) 일반론
[2] 성능 관리(Performance Management) 분야
[3] 가용성 관리(Availability Management) 분야
[4] 용량 관리(Capacity planning & Sizing) 분야
[5] 장애 복구(Crash Recovery) 분야.
[6] 서비스 엔지니어의 관점에서 바라보는 ITIL의 적용

지난 글에서 다루었던 성능 관리(Performance Management) 분야는 어떻게 보면 시스템 엔지니어들에게는 흥미롭고 재미있는 분야이기도 하다. 성능상의 문제가 있는 시스템을 튜닝하여 고객이 원하는 Response Time을 이끌어 내는 업무는 속된 말로 “잘하면 칭찬(?), 못해도 본전(?)”이기 때문이다.

그러나 시스템의 백업과 복구 처리에서 ‘본전(?)’이라는 말은 용납되지 않는다. 장애가 발생하여 서비스가 중단된 것도 회사에 커다란 손실로 작용하는데, 복구마저 할 수 없는 상황이라면, 이러한 사태를 초래한 시스템 엔지니어는 도태될 것이 분명하다.

이번 글에서 다루는 장애 복구 처리는 가용성의 연장선상에서 Resiliency를 고려한 분야들을 다루고자 한다. “고가용성의 연장선상에서의 복제기술, 그리고, 재해 복구 시스템”에 대해서 전반적인 분야들을 다룰 것이며 근본적인 원칙들을 생각해 볼 것이다. 마지막으로 시스템 엔지니어의 서비스 프로세스를 관리하는 한 방법으로 ITIL(IT Infrastructure Library)이라는 Best Practice의 적용에 관하여 개괄적으로 논하고자 한다.

장애 복구
고가용성의 연장선상에서의 복제기술
고가용성의 분야에서 시스템 이중화에 대한 내용을 언급했었는데, 복제기술은 그 연장선상에 있으며 Crash Recovery를 위한 가장 치밀한 전략적 방법으로 사용될 수 있다.

특히 여기에서는 복제 기술이 가용성(Availability)에 미치는 영향에 대해서 웹 서버에 사용되는 단순한 파일 시스템 복제부터 실시간 거래 시스템에 사용되는 엄청난 규모의 데이터베이스의 트랜잭션 복제(Transactional Replication)를 가지고 설명할 것이다(‘프로세스의 복제’와 ‘Failover 시간 단축을 위한 복제’ 기술도 언급하지만, 주로 ‘재난 복구(Disaster Recovery)의 용이함을 위한 복제’ 기술을 다루고자 한다).

복제기술이란 데이터를 하나의 디스크 집합에서 하나의 완전히 다른 여분의(Redundant) 디스크 집합으로 이동하는 것이다. 복제는 디스크 미러링(Disk Mirroring)과는 다른 기술인데, 미러링은 디스크들을 하나의 논리적 볼륨(Logical Volume)으로 구성하여 가용성을 향상시킨 것이고, 이에 반해 복제는 디스크들을 두 개의 완전히 독립적인 부분으로 인식하는 것이기 때문이다.

복제가 제대로 수행되면 데이터베이스의 복구에 사용되는 모든 물리적 종속파일(완전한 데이터베이스)이 복제된 시스템에서도 존재하게 된다. 결국 복제는 일관성이 유지되는 두 개의 동일한 데이터 집합이며, 이상적으로는 이 두 개의 디스크가 물리적으로 다른 호스트에 연결되어 있는 디스크를 의미하게 된다.

복제는 RAID-1이나 RAID-5보다 더 많은 디스크 공간이 필요하게 되며, 이렇게 투자함으로써 다양한 운영상의 장애나 성능 손상(Performance Outages)을 더 빨리 복구할 수 있고, 장애 시간(Downtime)에 대한 예측 및 방어가 가능하다.

복제가 필수적으로 요구되는 환경
로드 밸런싱이 필요한 서버
복제된 웹 서버들은 어느 호스트에서든 동일한 URL을 가지고 접근하여 동일한 파일 시스템을 액세스함으로써 정확히 같은 내용을 보여주어야 한다.

복제 서버 형태로 확장성 있는(Scalable) 서버 팜(Farm)을 구성할 때는 적어도 어느 정도 수준의 파일 시스템 복제가 필요하다. 프론트-엔드 웹 서버 클라이언트들을 위해서는 대형 NFS 서버를 사용할 수 있다. 그러나 아주 대형 팜에서는 그런 NFS 서버들조차도 서로가 서로의 사본이 될 수 있다.

소프트웨어 개발 환경에서 일반적으로 사용되는 파일 시스템(개발 도구, 라이브러리, 문서들이 복제의 좋은 예이다)을 사용함으로써 NFS 서버를 사용하고 있는 모든 개발자들에게 빠른 속도로 액세스할 수 있게 해 준다.

짧은 장애 극복 시간이 필요한 환경
시간이 돈과 직결되고, 경제적 절대 가치가 커질수록 장애 복구를 위한 시간은 아주 짧아져야만 한다. 콜(Call)을 라우팅(Routing)하거나 제공해 주는 통신 관련 응용 프로그램은 몇 초 내에 장애로부터 정상적으로 작동되어야 한다. 또한 매매 거래에서 주문을 전달하고 확인하는 서버는 장애시 5초에서 10초 내에 복구될 수 있어야 한다.

따라서 응용 프로그램과 그 프로세스들을 복제하는 방법만이 요구되는 시간 내에 복구가 완료될 수 있다는 것을 보장할 수 있다. 이런 용도의 서버는 대부분 메인프레임 서버이거나 완벽한 클러스터링이 구현되어 있어야 한다.

데이터 손실 극복과 빠른 복구 위치
만약 데이터베이스에서 데이터 불일치가 발생하여 테이프 장치로부터 장시간 백업을 내려 받아 전체 복구를 해야 한다면 어떻게 할 것인가? 이건이 온라인 서비스라면 장애 복구를 도와야 할 직원들이 장애 시간 내내 고객 불편 전화에 시달리게 된다. 시간과 업무의 정확성이 중요한, 다시 말해 복제가 필수적인 환경에서 데이터베이스나 파일 시스템의 손실을 막기 위해 복수 서버에 복수 개의 복사본을 만들기 위한 투자는 당연한 것이다.

또한 데이터베이스의 체크포인트(Checkpoint)나 리두 로그(Redo Log, 또는 Archive)를 사용하여 복구할 수 있다. 혹은 데이터 손실이 발생한 시점을 알 수 있다면 특정 시간대의 상태로 돌릴 수 있는 TSPITR(Point Intime Recovery)가 가능하다(그러나 다양한 장애에 대처하기 위해서는 전체 복제가 필수적이다).

WAN 병목현상(Bottleneck) 해결
NFS와 다른 여러 파일 시스템 액세스 기법들은 LAN 환경에서 사용할 목적으로 디자인되어 왔다. WAN 환경에서 파일 액세스 프로토콜(File Access Protocol)은 빠른 참조를 할 때나 탐색의 용도로는 쓸 만하지만, 파일에 대한 주문형(On-Demand), 실시간 액세스(Real-Time Access) 용도로는 대기 시간(Latency)과 대역폭(Bandwidth) 때문에 쓰기가 힘들다.

만약 여러 곳에서 동일한 데이터를 액세스하고 평균 대역폭이 낮으며 일반적인 라운드 트립 대기시간(Round Trip Latency)이 길다면 WAN에서의 병목 현상을 없애기 위하여 데이터베이스나 파일 시스템의 복제를 사용해야 할 것이다. 경험에 따르면 평균 액세스 시간이 두 배로 늘어난 경우가 바로 이러한 예가 될 수 있다. 이런 경우 해결 방법은 복제된 데이터베이스를 로컬에서 액세스하는 것이다(분산 데이터베이스 환경 구축).

일반적인 재난 복구
데이터베이스를 날려버리는 것은 논리적인 재난에 속한다. 그러나 하드웨어 자체의 장애나 화재, 홍수 같은 자연재해의 경우는 어떻게 할 것인가? 만약 전체 복제가 이루어진 사이트가 있어서 서비스할 준비가 되어 있다면, 테이프로부터 데이터를 내려 받아 시스템을 완전히 다시 설정하는 복구 절차를 밟지 않더라도, 빠른 시간 내에 서비스를 다시 가능하게 할 수 있다.

데이터 손실이나 자연재해에 의한 복구 방법은 동일하며, 어느 경우든지 최소한의 조치를 취하기 위해서는 응용 프로그램 개발자와의 긴밀한 협조가 필요하다는 것을 알게 될 것이다. 재난은 복제가 가장 이상적으로 적용될 수 있는 시스템 수준의 재난과 데이터와 환경 요소에 대한 복제가 요구되는 환경적 재난의 두 가지로 나뉜다.

복제는 간단하게는 하나의 디스크를 완전하게 백업해서 정상적인 다른 시스템에서 다시 로드해서 사용하는 것도 있고, 복잡하게는 시스템에 로드가 심하게 걸리거나 장애 시 네트워크 상에 있는 다른 복제 시스템에 프로세서의 현재 메모리 상태를 복제하는 것까지를 포함한다. 복잡한 것에서 간단한 것에 이르기까지 복제 기법을 크게 5가지 목록으로 분류한다면 다음과 같다.

데이터베이스 복제
복제기법들이 적용된 시스템 환경 중에서 데이터베이스 분야는 가장 광범위하게 복제 기술이 적용된 사례이며, 최근의 긴급 재난 복구 센터 구축시 가장 많은 기술적 분야를 고려해야 하는 부분이기도 하다. 데이터베이스 복제는 다양한 재난, 예를 들어 주 데이터베이스가 손상되거나 동작 중이던 시스템의 장애시 MTTR을 분 단위가 아닌 초 단위로 낮추어 주고, 전체적인 시스템의 물리적인 장애로부터 시스템을 보호해 준다.

데이터베이스의 복제는 파일 복제 기법을 변형하거나 로그 재생(Red Log Replay)을 이용할 수도 있고, 데이터베이스의 자체 기능, 예를 들면 분산 트랜잭션 관리 혹은 써드 파티 트랜잭션 프로세싱과 큐 시스템을 이용하여 트랜잭션이 복수 서버에서 동작하는 복수 데이터베이스 인스턴스에 트랜잭션을 수행할 수 있게 해준다.

데이터베이스 로그 재생은 데이터베이스 복제의 가장 단순한 방법이며, 파일 시스템 복제를 본 딴 방법이다. 모든 데이터베이스는 특정한 구조, 일반적으로 ‘Undo’와 ‘Redo’에 바뀐 내용을 저장하여 시스템 장애 발생시 트랜잭션을 다시 돌리는 데 사용한다.

로그 재생은 로그 파일을 복사해서 다른 시스템에 복사하고 그리고 나서 복제 서버의 데이터베이스에서 복구 매니저(Recovery Manager)를 사용하여 그 트랜잭션을 다시 적용함으로써 시간 간격은 좀 있지만 원본과 거의 동일한 데이터베이스를 만든다. 데이터베이스 복제 기술 중 하나인 리플리케이션(Replication) 기술에 대해서 알아보자

SYMMETRIC REPLICATION
우선 이 환경은 오라클의 RDBMS를 중심으로 설명하도록 하겠다. 분산 환경에서 다른 사이트에 있는 데이터를 로컬 사이트에도 유지하면, 네트워크를 거치지 않으므로 데이터를 액세스하는 순간의 성능도 향상되고 network failure가 발생하여도 작업을 계속 진행할 수 있다. 이렇게 분산 환경에서 다른 사이트에 있는 데이터를 자신의 사이트에 오브젝트로 복사하여 사용하는 것을 ‘리플리케이션’이라고 하며, 오라클에서는 다음과 같은 두 가지의 리플리케이션 방법을 제공한다.

Read-only snapshot(Basic Replication)
이것은 기본적인 리플리케이션 방법으로, 분산 환경 중의 한 노드에 있는 마스터 테이블에 대한 read-only snapshot을 로컬 사이트에 유지하고 주기적으로 마스터 테이블의 변경된 내용을 반영하게 된다.

<그림 1> Read-Only Snapshot

Symmetric replication(Advanced Replication)
read-only snapshot이 마스터 테이블에서만 변경 작업이 가능하고 스냅샷은 읽기만 가능한 데 반해 symmetric replication 환경에서는 이 환경에 포함된 모든 복제된 데이터들을 변경 가능하고, 이 변경 사항이 나머지 모든 사이트에 전달된다. 또한 read-only snapshot이 데이터 레벨의 변경 사항을 반영(propagate)하는데 반해 symmetric replication은 스키마-레벨의 변경 사항도 다른 사이트에 반영할 수 있다.

<그림 2> Multi-Master Snapshot

asynchronous와 synchronous replication 기법의 비교
마스터 사이트나 updatable 사이트(변경이 발생하는 사이트)에서 다른 마스터 사이트로 데이터를 리플리케이션하는 방법으로 asynchronous 방법과 synchronous 방법, 두 가지가 있다. 이 두 가지 방법을 비교하면 다음과 같다.

asynchronous replication(store and forward 기법)
모든 트랜잭션은 deferred RPC 큐(queue)에 일단 저장된 후 정해진 시간 간격마다 전달(propagate)된다. replicated 마스터 테이블을 포함하고 있는 어느 한 사이트가 문제가 생긴다하더라도, 나머지 사이트들 사이에서의 전달에 전혀 지장을 주지 않는다. deferred 트랜잭션의 변경을 전달하는 시간 간격은 사용자가 원하는 대로 지정할 수 있다.

다른 사이트에서의 변화가 바로 로컬 사이트로 반영되는 것이 아니므로 리플리케이션되는 테이블들 사이에 일시적인 불일치 상태가 발생하게 된다.

여러 사이트에 같은 데이터를 변경하는 경우 충돌이 발생하는데, 이 충돌은 변경 사항이 반영되기 전까지는 감지되지 않는다. 충돌 분석(conflict resolution) 방법은 오라클이 제공하는 기본적인 방법과 사용자가 정의하는 방법이 있는데, 이러한 방법을 적용하기 위해서는 테이블에 필요한 정보를 저장할 컬럼을 추가해야 하는 등, 리플리케이션 환경을 구축하기 전에 고려해서 구성해야 하는 사항이 있다.

그러므로 리플리케이션 환경을 기반으로 애플리케이션을 구현하기 이전에 반드시 충돌 분석에 대해 결정하여야 한다. synchronous replication에 비해 반응 시간이 빠르다.

synchronous replication
다른 사이트의 변경사항이 즉시 로컬 사이트에 반영된다. 같은 데이터가 여러 사이트에서 변경된다 할지라도 충돌이 발생하지 않는다. 변경 사항을 synchronous하게 반영하여야 하는 사이트가 다운되었거나 네트워크 실패(network failure)가 발생하면, 이 문제가 해결되거나 문제의 사이트를 리플리케이션 환경에서 제거할 때까지 그 환경에 포함되어 있는 로컬 사이트의 데이터에 대한 변경 작업은 수행될 수 없다. 반응 시간이 asynchronous replication에 비해 느리다.

Read-only snapshot과 Updatable snapshot의 비교
read-only snapshot은 쿼리만 할 수 있고 마스터 테이블만이 변경될 수 있다. Updatable snapshot은 리모트 마스터 테이블(remote master table) 뿐만 아니라 스냅샷도 직접 변경할 수 있다. Updatable snapshot은 변경 내용이 마스터 테이블로 전달된다.

Read-only snapshot과 달리 updatable snapshot은 단일 마스터 테이블로부터 만들어져야 하며, 테이블의 join으로 구성되어질 수 없다. Updatable snapshot은 read-only snapshot과 마찬가지로 마스터 테이블의 풀 카피(full copy) 본을 유지할 수도 있고 마스터 테이블의 row들 중 일정 조건을 만족하는 row들만을 선택한 것일 수도 있다.

Updatable snapshot과 replicated master의 비교
symmetric replication을 구성하는 두 가지 방법인 replicated master와 updatable snapshot의 차이점은 다음과 같다.

updatable snapshot
‘pull’ technology, 즉 필요한 때에 리플리케이션을 받아오는 기법이다. 이렇게 변경된 데이터를 받아오는 것을 REFRESH라고 한다. 스냅샷은 마스터 테이블 데이터의 서브셋(subset)만을 복제하도록 지정할 수 있다. 스냅샷은 set-oriented로, 보다 긴 시간 간격 후에 여러 개의 트랜잭션에 의해 이루어진 변경 사항을 보다 효율적으로, 그리고 배치성 형태로 복제하게 된다.

마스터에서 스냅샷으로의 성능이 스냅샷에서 마스터로의 성능보다 중요한 경우에, 그리고 스냅샷에서 발생하는 트랜잭션의 수가 마스터에서 발생하는 트랜잭션의 수보다 훨씬 작은 경우에 적당하다. 노드가 리플리케이션으로 분리가 가능하거나 마스터가 되는 한 노드에만 커넥션이 되기를 바라는 경우에 적당하다. 스냅샷에는 unique 인덱스를 만들 수 없다.

즉 unique나 primary key constraint도 부여해서는 안 된다. 성능을 위해 인덱스가 필요할 때는 unique가 아닌 일반 인덱스를 생성하면 된다. updatable snapshot의 경우는 simple snapshot만이 가능하기 때문에 대부분 fast refresh 방법을 사용한다.

fast refresh 방식의 경우 마스터 테이블의 변경 사항만이 로그에 기록되어 스냅샷 사이트로 전달되는데, 이 때 성능상의 이유로 인해 로그의 내용이 순차적으로 스냅샷 베이스 테이블에 반영되지 않기 때문에 순간적으로 중복 상태가 될 수 있다(이 문제는 오라클8에서 declarative constraints 기능을 이용하여 트랜잭션이 끝난 후 충돌을 확인함으로써 해결할 수 있다).

replicated master
‘push’ technology, 즉 리플리케이션을 전달해주는 방식이다. 이렇게 데이터의 변경 사항을 전달하는 것을 Propagation이라 한다. replicated master는 복제되는 테이블의 전체 데이터를 포함해야 한다. 멀티-마스터 리플리케이션은 각각의 트랜잭션이 발생함에 따라 그 트랜잭션을 전달하여 복제되도록 하는 방법이다.

마스터 사이트는 다른 마스터 사이트의 리플리케이션 환경 내의 객체 구성 등의 구조가 같기 때문에 페일오버 시스템(failover system)으로 사용 가능하다. 그러나 스냅샷은 마스터와는 다른 내부 구조를 가지므로 페일오버 시스템으로 사용하기에는 부적합하다.

마스터 사이트는 복제되는 테이블 사이에 ROWID가 같지 않다. 스냅샷은 ROWID를 이용하여 refresh하지만, 마스터는 primary key를 이용하여 전달한다. 충돌이 발생하면 마스터 사이트에서 감지하고 해결한다. 모든 마스터 노드들이 서로 연결되어 있어야 한다. 복제되는 모든 테이블은 반드시 primary key를 가져야 한다.

지금까지 복제기술에 대한 사례로 데이터베이스 시스템의 리플리케이션에 대해서 알아보았다. 마지막으로 근래에 이슈가 되어온 재해 복구 시스템에 대해서 알아보자.

재해 복구 시스템
사실 대부분의 사람들은 실제 재해에 대해서는 이야기하는 것을 꺼린다. 재해는 인재(테러나 전쟁 등으로 인한)이든 천재(홍수, 지진 등)이든 간에 사무실에서의 대비 수준으로 해결할 수 있는 이상의 변화를 초래할 수 있다. 극단적인 경우 재산 손실뿐만 아니라 인명 손실까지 발생할 수 있는 것이다.

이 때문에 실제로는 거의 대비할 수조차 없는 일들에 대해 준비해야 하고, 모든 사람들이 얘기하는 것조차 꺼려하는 이슈에 관해서도 토의를 해야 한다.

항상 강조하지만, 두 가지 문제를 하나의 해법으로 대처하려고 해서는 안 된다는 것이다. 언제나 그런 것은 아니지만, 고가용성과 재해 복구를 다른 접근 방법을 가지고 받아들일 필요가 있다. 즉 고가용성을 위한 ‘장애 복구’와 ‘재해 복구’에 대해서는 다른 이해의 관점을 가질 필요가 있다(재해복구 시스템 구성 시에 고려해야 할 사항들은 박스로 정리해 놓았다).

재해복구 전략 수립시 고려사항

[1] RSO(Recovery Scope Objective) - 계정계, 정보계, 대외계 - 원격지 단순 데이터 백업, - 재해대비 시스템 복구를 위한 백업 [2] RTO(Recovery Time Objective) - 2시간내, 4시간내, 8시간내, 24시간내 [3] RPO(Recovery Point Objective) - 특정 백업 시점 데이터 복구 - 전일 마감 데이터 백업 시점 - 재해발생 시점 데이터 복구 [4] RCO(Recovery Communications Objective) - 네트워크 복구 수준 - 지역 모점, 주요 영업점, 전 영업점 [5] BCO(Backup Center Objective) - 자체 2nd 센터에 재해복구시스템 구축 - 자체 2nd 센터에 전문업체와 재해복구시스템 구축 공조 - 재해복구시스템 구축 전문업체에 위탁

어떤 비즈니스 프로세스가 크리티컬한가? 이 크리티컬 비즈니스 프로세스가 얼마나 긴 시간동안 다운되어 있는가? 파이낸셜 손실은 어느 정도 발생하며, 견딜 수 있는가? 다운타임 동안 제공할 수 있는 최소한의 서비스는 어느 정도 레벨인가? 등 이러한 분석 정보를 배경으로 다음의 세 가지 사항을 명확히 판단해야 한다.

[1] RTO(Recovery Time Objective) : 몇 시간 안에 복구할 수 있는가?
[2] RPO(Recovery Point Objective) : 어느 시점까지의 데이터로 복귀할 것인가?
[3] Dependency : 업무간 상호 연관성은 어느 정도인가?

또한 백업방법별로 그 특성을 고려하여 재해복구 센터를 구성할 때 반영하여야 한다(<표 1> 참조).

백업 방안별 특성

백업방안 특성 시스템 미러링 ＊ CPU/데이터베이스 미러링으로 주 센터와 백업 센터간 동일한 시스템 이미지 구성 ＊ 데이터 손실이 없어 재해/장애시에도 영향이 없는 시스템 구성 ＊ 영업점과 주 센터 및 백업 센터간 통신 라인 이중화 구성을 통해 신속한 복구 가능 실시간 데이터 이중화 ＊ 실시간으로 주 센터와 백업 센터간 데이터베이스 레벨의 이중화 백업체제 구성 ＊ 주 센터와 백업 센터간의 데이터베이스를 직접 이중화하는 방안 - 로그 또는 저널을 이용하여 주 센터의 DB를 백업 센터에서 생성하는 방안 - 백업 센터에서 로그를 적용하여 DB를 갱신하는 시간이 소요(Dedicated DB 용량) 실시간 트랜잭션 로그 이중화 ＊ 실시간으로 주 센터와 백업 센터간 로그 또는 저널만을 이중화 백업체제 구성 ＊ 데이터베이스는 주기적으로 원격 백업 또는 PTAM(Pickup Truck Access Method) ＊ 재해발생시에 이중화된 로그를 이용하여 백업 센터의 데이터베이스를 재해시점까지 복구 백업 테이프 이용 복구 방안 ＊ 주기적으로 시스템 및 데이터 백업 테이프를 원격지에 PTAM 방식으로 소산 보관 ＊ 복구시스템 사용 계약을 통해 주기적 복구 시스템 구축 테스트 실시로 복구시간 단축 ＊ 점진적인 재해발생 대비 복구방안으로 급진적인 재해시 갱신된 데이터 손실

<그림 3> DR 구성시 Trade-Off 그래프

비용 문제는 그렇다 치더라도 많은 수의 재해 복구 사이트는 대부분의 시간을 아무 것도 하지 않는 상태로 보내기 마련이다. 이 경우 메인 사이트에서는 자원 부족 현상이 빚어지고 있는 상황에서 막대한 양의 컴퓨팅 자원이 거의 놀고 있는 상태가 되면 구매 승인 담당자 측에서 볼 때 매우 신경에 거슬릴 것이다.

물론 재해 복구 사이트를 마련하는 일은 텅 빈 집채만한 건물에 컴퓨터나 네트워크 따위를 잔뜩 갖다 놓고 재해가 발생하기만을 기다리면 되는 것을 훨씬 상회하는 성격의 것이다. 작업적인 측면에서의 요구사항을 마련하는 단계에서는 그 쏟아져 나오는 막대한 유형과 해당 양의 작업들이 매우 복잡한 상호 연관성을 갖고 있다는 사실을 깨닫게 될 것이다.

재해 복구 시스템은 메인 사이트와 반드시 동기화되어 있어야 하며 이것은 하드웨어 수준에서 달성되어야 한다. 주 센터와 백업 센터와의 DR 구성시, 동기화의 백업 병목지점을 판단하고 그 성능을 고려하여야 한다. 지역적으로 고려되어야 하는 요소는 ‘테이프 드라이브에 따른 용량과 성능’, 그리고 ‘데이터 버스에 따른 성능’ 등이다.

DLT, AIT 장비는 수십 Gb에서 수 백 Gb를 동시에 백업처리할 수 있으며 초당 성능 또한 다양하다. 데이터 버스 역시 Narrow SCSI에서 Wide, Ultra SCSI에 걸쳐, Fiber Channel까지 다양한 대역폭(36Gb/Hour360Gb/Hour)을 제공한다. 그러나 가장 빈번하게 병목요소가 되며, DR 구성시 문제의 핵심 요소가 되는 요인은 네트워크 대역폭의 문제이다(<표 2> 참조).

DR 구성시 네트워크 대역폭의 고려

통신회선 대역폭 초당 전송량 사용용도 T1 1.5Mbps 0.15Mb/s 소량의 트랜잭션 T3 45Mbps 4.5Mb/s 중간급의 트랜잭션 ATM OC-3 155Mbps 15.5Mb/s 중간급의 트랜잭션 ESCON 200Mbps 17Mb/s 근거리 구성 Fiber 1024Mbps 100Mb/s 대량의 트랜잭션 DWDM 2.5Gbps 2.5Gb/s 대량의 트랜잭션

데이터가 재해 복구 센터로 옮겨진 후
어떤 방법을 사용했던 간에 일단 데이터가 원격 사이트로 옮겨진 후에는 해결되어야 할 이슈들이 많다.

첫째, 백업 테이프가 재해 복구 사이트에서 읽혀질 수 있는가? 읽어 들이기 위해 특화된 소프트웨어가 필요한 것은 아닌가? 소프트웨어 라이선스를 요구하는 것은 아닌가? 라이선스 키 등은 가지고 있는가? 라이선스 키를 입수하는 데 시간이 얼마나 걸리나?

둘째, 데이터 복원을 시작하기 전에 테이프 인덱스를 재구성해야 하는가? 얼마나 걸리나?

셋째, 실행 가능한 응용 프로그램들이 재해 복구 사이트에서 갖추어져 있는가? 가장 최신 버전인가? 사이트별로 실행하는 내용에 호환되지 않는 부분이 있는가? 관련된 데이터가 재해 복구 사이트의 응용 프로그램 버전에서 사용 가능한가?

넷째, 응용 프로그램이 최신 버전으로 갖추어져 있다고 한다면 재해 복구 사이트에서 실행하기 위해서 별도의 라이선스 키가 필요하지 않은가?

우선순위 정하기
재해 발생이 확인된 다음에는 시스템 관리자가 핵심 응용 프로그램을 재해 복구 사이트로 이전하여 필요한 모든 절차를 빠짐없이 수행해야 한다. 이들 절차는 자연스럽게 이어지되 빠르게 수행될 수 있으면 좋겠지만, 현실적으로는 그렇게 수월하지 않다. 필요한 사항들을 절차와 우선순위에 맞게 나열하여 보자

첫째, 어떤 프로그램이 먼저 실행되어야 하는가? 어떤 데이터가 먼저 복원되어야 하는가?

둘째, 재해 복구 사이트에서 전혀 필요하지 않은 응용프로그램은 무엇이 있는가?

셋째, 재해가 계속되는 경우 서비스를 대체할 어떤 프로그램이 필요한가?

넷째, 희소 자원에 대한 우선 순위는 누가 갖는가?

다섯째, 특정 그룹이 다른 그룹에 앞서 서비스를 받을 수 있도록 하는 결정은 어떤 근거로 내려지는가(최고 결정권자가 없다면 대체 결정권자가 자리에 있어야 한다).

전체 테스트
가장 중요하면서 간과할 수 없는 것이 재해 복구 절차의 전체 테스트이다. 재해 복구 절차를 모두 테스트하는 것은 실제 재해가 발생했을 때 가능한 자연스럽고 껄끄럽지 않게 실행에 옮길 수 있는 가장 좋은 방법이다. 모두 테스트하지 않게 되면 재해가 발생했을 경우 분명히 상황이 더욱 복잡 미묘하게 악화될 가능성을 내포하게 되는 것이다.

주말이나 연휴기간을 택해서 관련된 사용자 및 운용자들이 모두 참석한 가운데 실제 재해상황을 완벽하게 구성하여 놓고 모든 시나리오와 재해 단계별 복구 테스트를 실시하여야 한다. 최악의 경우에서부터 충돌 레벨이 낮은 단계까지 절차적으로 우선순위에 따라 진행하여야 하며, 각 단계별 시나리오 별 복구 시간을 기록하여 복구 계획에 역으로 반영하여야 한다.

재해를 테스트하는 일은 대단히 비용이 많이 들어가는 일이지만, 그렇다고 테스트를 하지 않았다가는 사업을 완전히 접을 수밖에 없는 막대한 대가를 치를 수도 있으므로 분명히 해야만 하는 필수 절차이다. 테스트가 되지 않는 재해 복구 센터를 운영한다는 것은 재해 복구를 위한 모든 노력과 비용이 수포가 될 수 있는 시한폭탄을 끌어안고 있는 것과 같다.

서비스 엔지니어의 관점에서 바라보는 ITIL의 적용
ITIL 서론
기업의 IT 인프라스트럭처 관리의 초점이 IT 시스템에서 비즈니스로 옮겨가고 있다. 이전의 IT 인프라 관리가 IT 시스템 자체의 성능에 집중되었다면, 최근에는 IT 시스템을 비즈니스와 연계해 관리?운영할 수 있는 비즈니스 관리 측면이 크게 부각되고 있다. 즉 IT 인프라 관리의 개념이 서비스와 비즈니스 가치를 포괄하는 비 IT적 측면으로 확대되고 있는 것이다.

지금까지의 IT 인프라 관리는 네트워크, 애플리케이션, 시스템, 데이터베이스 등 기업의 IT 인프라를 구성하는 요소들의 성능과 안정성 등 IT적 관점에서만 관리된 경향이 강했기 때문에 IT 시스템이 실제 비즈니스에 미치는 영향을 체계적으로 분석하는데 어려움을 겪었다. 특히 성공적으로 구축된 IT 시스템이라 할지라도 ROI를 산출하는 데 취약하다는 지적을 받아 왔다.

그러나 비즈니스 측면에서 IT 인프라를 관리한다면 IT 시스템이 어떤 비즈니스를 수행하고 창출하는지를 정확하게 정의하고, 전산 장애가 발생했을 경우 비즈니스에 어떤 영향을 미치는지를 파악해 대처할 수 있게 된다. 이를 통해 기업들은 IT 인프라 관리 비용을 절감하고 비즈니스에 최적화된 IT 인프라를 유지할 수 있게 된다.

지금까지 기업 내의 IT 관리부서나 CIO는 나름대로의 독자적인 경험에 의존해 IT 업무 프로세스 관리를 해오고, IT 운영을 위한 표준 절차나 가이드라인이 명확하지 않아 상당한 업무 비용 손실을 초래하고 질 높은 서비스를 제공하지 못했다. 최근 이 같은 문제들을 극복하기 위해 기업들은 보다 체계화되고 선진화된 표준 운영 프로세스인 ITIL을 도입해 IT 관리 운영에 대한 기본 틀을 정립하려고 노력 중이다.

최근 가트너가 발표한 자료에 의하면 현재 세계적으로 약 25%의 기업들이 ITIL을 활용하고 있고 2004년에 본격적으로 도입되기 시작한 ITIL은 2005년에는 지금보다 약 5∼10% 더 많은 기업들이 적극적으로 활용할 것으로 전망하고 있다.

ITIL의 개념
ITIL은 IT 서비스 관리(ITSM: IT Service Management)에 대한 프레임워크 구현을 돕기 위한 문서들의 집합이다. ITIL 프레임워크는 특정 기업 내의 복잡한 IT 환경에 대해 비즈니스와 서비스 중심의 최적의 프레임워크를 제시한다.

ITIL은 어떤 종류의 조직에도 어떤 규모의 기업에도 활용 가능하고, 어떤 벤더에도 종속적이지 않은 포괄적이면서도 공개적인 표준 가이드로서, 1986년 영국 정부(CCTA : Central Computer and Telecommunications Agency)의 의해 개발되어 현재 업게 선두 1만개 기업들로부터 그 유효성과 효율성을 검증받아 표준 IT 서비스 관리 프레임워크로 사용되고 있다.

IT 프로세스 관리 프레임워크 Best Practice를 기반으로 만들어진 ITIL은 제공하는 프로세스 및 서비스에 따라 다음의 다섯 가지 영역으로 구성되며 서로 밀접한 관계와 인터페이스를 갖고 있다.

[1] Service Delivery

IT 서비스 제공자가 비즈니스 고객에게 충족한 지원을 제공하기 위해 필요한 서비스 및 프로세스를 정의하고 있다.

[2] Service Support

IT 서비스 사용자가 비즈니스 관련 IT 서비스를 항상 받을 수 있도록 보장하는 데에 필요한 관련 프로세스를 포함하고 있다.

[3] Applications Management

소프트웨어 개발 라이프 사이클을 포함하고 있으며 소프트웨어 라이프 사이클 지원 및 IT 서비스 테스팅까지 확장하여 다루고 있다.

[4] ICT Infrastructure Management

IT 인프라스트럭처를 운영?관리하기 위해 필요한 주요 프로세스를 포함하고 있다.

[5] The Business Perspective

전체 비즈니스의 중요 부분으로서의 IT 서비스 제공 품질의 개선 및 이해를 다루고 있다.

ITIL은 IT 서비스를 고객의 비즈니스 요구사항과 연계하여 더 나은 서비스를 제공할 수 있도록 IT 조직에 Best Practice를 제공한다. 즉 ITIL은 방법론이 아니라 IT 조직이 IT 서비스 관리를 할 수 있도록 제공되는 실천 모델이다.

<그림 4> 사람, 프로세스, 기술에 의한 IT 서비스 관리

ITIL은 고품질의 IT 서비스 제공에 초점을 맞춰 IT 조직, 고객 및 파트너를 중심으로 다루고 있다. 여기서 IT 서비스라 함은 사람(People)에 의해 수행되고, 기술(Technology)에 의해 지원되는 프로세스(Process)라고 할 수 있다. 즉 서비스란 기술의 지원을 받은 조직에 의해 수행된 프로세스의 결과이고, 따라서 체계적으로 정의된 프로세스를 갖고 있지 못한 조직은 일도 제대로 수행할 수가 없다.

그러므로 체계적이지 못한 IT 운영 관리 프로세스는 반드시 정립되어야 하고, IT 운영 관리 프로세스 정립 및 혁신을 위해서는 전세계적으로 검증된 모델인 ITIL이 요구된다. 이처럼 사람, 프로세스, 기술이란 세 가지 요소들의 최적화된 융합으로 IT 조직을 비즈니스 기반의 운영 방식으로 바꾸어 보다 우월한 IT 서비스를 제공하도록 하는 운영 방식이 ITSM(IT Service Management)이다.

ITSM은 운영자 중심이 아닌 고객과 프로세스 중심의 운영방식이라 할 수 있고, 협의된 서비스 수준 1(Service Level Agreements)에 맞는 서비스를 제공함으로써 효율적인 프로세스 운영을 통해 비용절감을 목표로 한다(Gartner: Processes forms a big part of IT service management. Availability in a complex computing environment does not happen on its own or automatically by acquiring high-availability technology. It takes strategy, planning, policy and implementation to achieve it. These are people and process issues, not technology issues).

<그림 5> Service Support와 Service Delivery의 영역

ITIL은 서비스 써포트(Service Support)와 서비스 딜리버리(Service Delivery)라는 핵심 영역으로 IT 프로세스 영역을 구분하고 있는데, 서비스 써포트는 IT 서비스 제공의 융통성과 안정성을 보장하기 위해 사건, 장애, 변경, 버전, 설정 관리로 구분되어 있고, 서비스 딜리버리는 IT 서비스의 품질과 비용 효율성을 보장하기 위해 서비스 수준, 가용성, 용량, IT 서비스의 재무, IT 서비스 연속성 관리로 구분되어 있다.

즉 서비스 써포트는 IT 서비스 사용자가 고품질의 서비스를 제공받도록 하는 데에 필요한 관련 프로세스들을 포함하고, 서비스 딜리버리는 다양한 각도에서 비즈니스 요구에 대한 분석을 하여 고객이 원하는 수준의 서비스를 정의·계약하고, 정의된 서비스 수준을 위해 요구되는 요소(하드웨어, 소프트웨어, 테크놀로지, 가용성 및 금전적 요구 조건)들을 파악하여 서비스 수준을 모니터링하는 것이다.

또한 ITIL은 ISO 9000 품질시스템과 EFQM(European Foundation for Quality Management) 및 CMM(Capability Mature Model)과 깊은 관계를 갖고 있고 IT 서비스 관리에 필요한 주요 프로세스 및 Best Practice를 제공함으로써 이러한 품질 시스템을 지원하고 있다. 따라서 기업들이 ITIL을 선택함으로써 IT 서비스 관리 분야에서 ISO와 같은 품질 시스템에 대한 인증을 공인받을 수 있고 IT 서비스에 대한 품질 및 비즈니스 중심의 IT 프로세스 실천 모델을 보유할 수 있다.

ITIL의 도입 효과
이미 유럽의 대다수 기업에서 1990년대 말에 ITIL을 적용했고 미국에서도 ITIL의 도입이 꾸준히 늘고 있다. 그렇다면 전세계적으로 많은 기업들과 정부기관이 ITIL을 적용하는 이유가 무엇일까 알아보자. 그리고 투자비용 대비 이득 측면에서도 그 이점을 살펴보자. 첫번째로 기업 내에서 얻는 효과로는 다음과 같다.

＊ IT 변경 사항에 대한 관리, 제어권의 향상
＊ IT 비용 관리 프로세스를 통한 IT 비용의 절감
＊ IT와 비즈니스를 연계 관리
＊ IT 관리도구의 적용을 위한 프로세스 셋업
＊ 아웃소싱에 대한 결정을 위한 프레임워크 준비
＊ 상호 대화를 위한 단일화된 참조모델
＊ 체계적/명확한 IT 조직체계
＊ 프로세스 표준화
＊ 일의 중복 감소
＊ ISO 9000 인증 가능

두 번째로 IT 고객은 다음과 같은 효과를 기대할 수 있다.
＊ 문서로 상세하게 잘 정리된 IT 서비스
＊ 보다 안정적인 IT 운영환경
＊ 제공 서비스에 대한 품질 보증에 따라 신뢰성 증가
＊ 명확한 대화 통로 제공
＊ 신속한 신규 IT 서비스 런칭

세번째로, 신속한 ROI를 기대할 수 있다. 미국 내의 ITIL 컨설팅 회사인 Interprom사에 의하면 ITIL을 적용한 고객사의 경우 IT 다운타임을 65%를 줄임으로써 100명의 사용자 당 연간 19만 7000 US 달러의 절감 효과를 보았으며, 700만 US 달러의 수입 손실을 감소, 그리고 22일의 투자회수 기간이 산정되었다.

이 경우의 고객은 직접 ITIL을 지원하는 관리도구를 적용한 경우이다. 또 다른 고객의 경우 서비스 콜의 해결 시간을 50% 감소시켰으며 1주일에 처리 가능한 콜 량도 450건에서 2000건으로 증대함으로써 생산성을 향상시켰다.

ITIL이 주목받고 있는 상황에서, IT 관련 서비스를 창출하고 제공하는 기업들은 자사뿐만 아니라 고객사 및 외부 기업의 IT 관리 조직이 세계적으로 검증된 표준이 될 만한 프로세스 모델인 ITIL을 채택하도록 도와주고, ITIL과 더불어 CMM 등의 다른 프로세스 모델을 통합적으로 적용하는 방안에 대해서도 검토할 수 있어야 하겠다.

ITIL에 관심을 갖기 바라며
3번의 연재를 마치면서, 마지막으로 ITIL에 대한 시스템 엔지니어들이 관심을 권장하고 싶다. ITIL에 대하여 혹자는 한 때의 유행처럼 여길 수도 있고, 혹자는 컨설팅 업체의 상술로 비하하는 이도 있다.

하지만 ITSMF에서 추진하는 ITIL의 적용과정을 통하여 고객과 조직(엔지니어)과 상품(기술)이 어떤 프로세스로 흐르며, 어떤 메쏘돌로지와의 조화로운 통합적 적용 방안으로써 작용하는지 알고, 우리의(엔지니어의) 업무 체계를 폭넓게 이해하고 능동적으로 이끌어 갈 수 있는 이해력을 키우는 데 도움이 될 것이다.@

* 이 기사는 ZDNet Korea의 제휴매체인 마이크로소프트웨어에 게재된 내용입니다.

 

원문 : http://www.zdnet.co.kr/techupdate/lecture/etc/0,39024989,39134780,00.htm

 

[시스템 관리 노하우를 말한다] ② 고가용성·시스템 용량 산정

 

연재순서
1회. 시스템 유지·보수와 성능 관리
2회. 고가용성과 시스템 용량 산정
3회. 장애 복구와 ITIL 적용

 

흔히 가용성(Availability)의 척도는 9라는 숫자의 조합으로 평가된다. 가용성을 99%로 유지하는 것과 99.99%로 유지하는 것에는 엄청난 비용과 기술의 차이가 있다.

가용성은 선형적으로 증가하지 않으며, 페일오버(Failover)라 불리는 스위치 오버(Switch Over)에 걸리는 시간과 관련된 문제이기 때문이다. “우리 회사의 시스템은 매우 중요한 업무를 처리하며, 365일 24시간 쉬지 않고 서비스가 진행되어야 하므로 100%의 가용성을 유지해야 합니다”라는 고객의 요구를 어떻게 받아들여야 할까?

이번 글에서는 고가용성(두 시스템간의 Monitoring & Protection)에 대한 논의와 시스템 용량 산정에 대하여 일반적인 원칙과 사례를 들어 설명하고자 한다. 3개월에 걸쳐 다룰 내용은 다음과 같으며, [1]과 [2]는 지난 글에서 다뤘고, 이번에는 [3]과 [4]에 대해 알아볼 차례다.

  

가용성과 용량 관리

가용성과 용량 관리(용량 산정)라는 분야에서 시스템 관리자가 관심을 가져야 하는 지식의 범위는 의외로 넓다. 흔히 ‘Availability’라는 단어로 포장되어 있는 가용성의 분야에는 SPOF(Single Point of Failure)를 제거하기 위한 어마어마한 노력들이 포함되어 있으며, 용량 산정을 정확히 예측하기 위한 분야에서도 많은 엔지니어의 경험과 숙련도가 요구되어 왔다.

가용성 관리를 위한 주제로 가용성의 측정, 고가용성 시스템의 구축 원칙(일반적인 법칙), 각 시스템 및 구성 요소별(데이터베이스 서버, 웹 서버, 애플리케이션 서버, 네트워크 등) 구축방법(사례) 등을 논의해 보고자 한다.

용량 관리(Capacity planning & Sizing)에 대한 이론적인 접근을 통하여 지난 번에 언급한 성능 관리가 어떻게 연계되어 있으며, 전세계적인 표준 벤치마킹 사이트(www.tpc.org, www.specbench.org, www.spec.org) 등에서 제공되는 정보들이 시스템 사이징에 어떻게 이용되는지 사례별로 살펴보고자 한다.

 

가용성 관리 분야

가용성 구축 일반론
가용성에 대한 일반적인 공식은 다음과 같다.

여기서 A는 가용성(Availability, %)을 나타내며, MTBF는 Mean Time Between Failures, MTTR은 Mean Time To Recover(복구하는 데 걸리는 시간)를 의미한다. 실제로 MTTR이 최소화될수록 가용성은 100%에 가깝게 된다.

예를 들어, 어떤 시스템의 MTBF가 5만 시간이고, MTTR이 30분이라면 앞의 공식에 따라 이 시스템의 가용성은 99.999%가 된다. 결국 5년 8개월 동안 단 30분의 다운타임이 발생해야만 99.999%의 가용성이 보장된다는 것이다(우리나라 관공서의 장비 의무보존 기간을 평균 5년으로 보았을 때, 이 가용성 수치는 달성하기 불가능해 보인다). 게다가 이 가용성 수치를 99.9999%로 끌어올리기 위해서는 5년 8개월 동안 단 3분의 다운타임이 보장되어야 한다.

MTBF의 핵심은 시스템에 고장이 생길 때까지 걸리는 평균시간을 의미한다. M은 평균적인 추세를 의미하기도 하는데, 예를 들어 평균적인 HDD의 수명이 제조사들이 발표하는 것처럼 11.5년이라면 500개의 드라이브가 설치된 디스크 어레이(Disk Array)는 평균 16.5일마다 디스크를 교체해 주어야 한다는 확률이 나온다.

<표 1> 가용성 측정(자료출처 : Blueprints for High Avaiability)

<표 1>은 가장 간단한 의미에서 가용성을 계산하는 방식이다. 최근의 추세는 SLA에 가용성에 대한 질적/양적인 규정을 명시하기 때문에 이 계산 공식은 좀 더 세분화되어야 하며, 더 자세한 상황들이 고려되어야 한다.

실제로 고객이 요구하는 MTBF는 일요일 새벽 1시부터 6시가 아니라, 목요일 오전 9시 30분부터 11시 30분 사이에 더 가치가 있을 것이다. 따라서 “어느 시간대에 100%의 시스템 가용성을 달성할 수 있는가?” 하는 것이 SLA에서 가용성 협상의 관건이 될 수 있을 것이다.

서버 다운의 정의와 원인 분석

서버 다운은 상황의 긴박함 정도를 고려하거나, 다운으로 인한 임팩트가 단순한지 복잡한지에 따라 다양하게 사용된다. 가장 흔한 다운의 정의는 서버 자체나 디스크, 네트워크, 운영체제, 주요 응용 프로그램 등의 서버를 이루고 있는 구성요소에 문제가 생겼을 때를 말한다. 보다 엄밀히 따져보며 서버 및 네트워크의 속도 저하, 백업 시스템의 고장, 일부 데이터를 읽을 수 없는 상황도 다운에 해당된다.

궁극적으로 SLM에서 바라보는 서버 다운은 “사용자(User, Customer)가 계획된 시간 안에 작업을 마칠 수 없을 때”, 이를 시스템 다운으로 정의할 수 있다. 일반적으로 서버 다운의 원인을 분석해 보면 다음과 같은 결과를 얻을 수 있다.

◆ 예정된 다운타임 : 30%
◆ 소프트웨어 다운 : 40%
- 서버 소프트웨어 : 30%
- 클라이언트 소프트웨어 : 5%
- 네트워크 소프트웨어 : 5%
◆ 사람 : 15%
◆ 하드웨어 : 10%
◆ 환경 : 5%

예정된 다운(Planed Downtime)이 많은 비중을 차지하고 있는 것은 정상적으로 볼 수 있다. 소프트웨어로 인한 다운타임이 많은 퍼센트를 차지하는 것은 서버 소프트웨어(운영체제 포함), 클라이언트 소프트웨어, 네트워크 소프트웨어 등의 버그는 시스템 안정성을 위하여 가장 통제하기 힘든 분야이기 때문이다.

하드웨어가 안정화되어 갈수록 소프트웨어로 인한 다운타임의 비중은 높아질 것이며, 또한 소프트웨어가 점점 더 복잡해지면서 소프트웨어 자체 문제로 인한 장애가 더 많이 발생할 것이다.

시스템 다운의 특이할 만한 점은 사람에 의한 비중이 15%나 된다는 것이다. 여기에는 사람들의 직무태만이나 부주의로 인한 실수와 시스템 운영방법을 완벽하게 숙지하지 않아서 발생하는 문제로 크게 나눌 수 있다. 이렇게 사람으로 인한 시스템 다운의 해결책으로는 지속적인 교육과 시스템 구성을 기능에 맞게 단순화시켜 구성하는 방법을 제시할 수 있다.

가용성의 단계

크게 가용성의 단계는 시스템의 severity level에 따라 다음과 같이 크게 4단계로 구분한다(하지만 이 구분이 명확하게 구분해낼 수 있는 기준을 제시하는 것은 아니다. 실제로 가용성을 증가시키기 위한 수많은 단계와 함께 결집된 기술은 그처럼 단순하지 않기 때문이다).

1단계, 일반적인 가용성 : Normal 시스템
시스템이나 디스크를 보호하기 위한 장치는 전혀 없으며, 1단계 백업 이외에는 별 다른 것이 없다. 시스템이 다운되면 백업한 시점 이후의 데이터를 잃을 수도 있고, 특별한 회복능력(resilence)이 보장되지 않는다.

2단계, 가용성 증가 : 데이터 보호
1단계에 비하여 온라인 데이터 보호를 제외하고는 별로 다를 것이 없다. 데이터 보호을 위하여 Raid 5(Parity bit을 이용한 Raid)나 미러링(Mirroring) 같은 수준의 낮은 데이터 보호가 진행될 뿐이다. 디스크가 모두 훼손되었을 경우 치명적인 시스템 다운은 피할 수 없다.

3단계, 고가용성 : 시스템 보호
이 단계는 흔히 HA(High Availability)라고 하는데, 두 대의 같은 기능을 수행할 수 있는 시스템을 클러스터로 구성한 후 한 쪽 시스템이 제 기능을 수행할 수 없을 경우 다른 시스템이 대체 작동하게 함으로써, 시스템이 가지고 있는 대부분의 SPOF(Single Point of Failure)를 제거할 수 있는 매우 큰 장점이 있다. 이 단계에서 일반적인 가용성은 99.98%까지 끌어올릴 수 있으나, 중복 투자되는 비용의 천문학적인 증가를 고려하여야 하며 End-to-End HA 시스템을 구성할 때는 반드시 네트워크까지도 고려하여야만 한다.

4단계, 재난 복구 시스템
재해에 대한 자동 복구 시스템을 구축하는 것은 시스템 보호 단계 중 가장 비용이 많이 소요되며, 최상의 IT 기술력이 결집되어야만 가능하다. 천재지변에 대비하여 시스템은 원격지에 서로 이중화되어야 하며, 백업 시스템은 언제든지 자동으로 메인 시스템을 대체할 준비가 되어 있어야 한다.

이 단계에서는 무정지 시스템(Fault Tolerant System)의 구성을 포함하는 경우도 있는데, 한 시스템 안에 두세 개의 대체 부품을 장착하여 특정 부품에 문제가 생기더라도 각 부품이 대체 동작하거나 병렬로 동작해 시스템의 다운타임을 극소화시킬 수 있는 시스템을 말한다.

그럼 가용성을 증가시켜 나가는 각 단계별 구성요소의 구축방법과 사례를 통해서 고가용성 시스템의 활용 측면을 살펴 보도록 하자.

가용성을 위한 데이터 보호

실제로 고가용성 시스템에서 디스크는 고장날 확률이 가장 높은 구성 요소이다. MTBF를 떨어뜨리는 가장 대표적인 디스크 장치는 그러면서도 데이터 보호와 성능를 위하여 가장 신경을 많이 써야 하는 부분이기도 하다. 일반적으로 디스크 어레이를 구성하는 방식은 Raid Level에 따라 그 가용성의 정도가 달라진다(아래 박스 참조).

레이드 단계

Raid-0 : 스트라이핑(Striping) 디스크 스트라이핑 기술을 이용하여 여러 개의 디스크를 마치 하나의 디스크를 이용하는 것처럼 사용한다. 데이터 정크 단위로 각 세그먼트를 순차적으로 기록한다. 따라서 각 디스크는 쓰기 작업을 동시에 끝마칠 수 있으므로 저장 속도는 싱글 디스크에 쓸 때보다 향상된다. 그러나 Raid-0가 시스템이나 테이터의 가용성을 높여주지는 않는다. 어레이 하나의 디스크가 파손될 경우 어레이 전체의 데이터를 잃게 된다. Raid-1 : 미러링 Raid-1의 미러링 방식은 두 번째 디스크상에 모든 바이트를 복사해서 유지하는 모델이다. 100% Synchnization을 사용한다. 따라서 한 디스크가 파손된다면 다른 하나의 동기화된 디스크에서 데이터를 추출할 수 있다. 결국 쓰기 작업은 양쪽에서 발생하며, 읽기 작업은 두 개의 디스크 중에서 먼저 읽혀진 쪽에서 발생한다. 단점으로 비용대비 디스크 공간의 사용률이 떨어진다는 것을 감안하여야 한다. 또한 미러링을 구성하였다고 해서 백업을 하지 않는 것은 위험천만한 발상이다. Raid-0+1, 혹은 Raid-1+0 Raid-1+0는 Raid의 기술적 결합 가운데 가장 뛰어난 방법 중 하나이다. Raid-0+1은 먼저 일련의 디스크를 스트라이프한 후 같은 구성의 스트라이프된 디스크와 미러링하는 것을 의미하며, Raid-1+0은 선택된 한 쌍의 디스크를 미러링한 후 미러링된 디스크들을 스트라이프하는 구성방법이다. 스트라이핑의 특성을 이해한다면 실제로 Raid-1+0이 데이터의 가용성 측면에서 더 우수하다. 실제 1+0의 유일한 단점은 스트라이프된 각각의 구성 요소가 동일한 크기를 가질 필요가 있다는 것이다. Raid-2 : Hamming Encoding Raid-2는 디스크에 씌어지는 데이터의 정확성을 체크하기 위해 ECC 메모리의 데이터 보정 방법을 채택하고 있다. 입력 데이터에 일정한 redundancy를 추가해 에러를 검출 및 수정하는 코드를 말하는 것으로 1948년 Shannon에 의해 수학적으로 증명이 되고, 이후 1950년에 single error correcting이 가능한 Hamming Code가 처음으로 발표되었다. 이 Raid-2 기법에 의한 Array 구성 방법이 상용화된 적은 없다. Raid-3, 4, 5 : Parity Raid Raid Level 3, 4, 5는 원본 데이터의 완전한 복사본을 유지함으로써 발생하는 디스크 공간의 낭비를 줄이기 위하여 XOR(eXclusive ORs)에 의해 발생되는 계산된 Parity bit 값을 사용한다. 이 패리티 Raid 모델은 약 20～25%의 디스크 공간 오버헤드(OverHead)를 가지고 있을 뿐이며, 이것도 스트라이프된 디스크의 수에 따라 달라진다. Raid-3은 가상 디스크 블럭(Virtual Disk Blocks)을 사용하여 I/O를 발생시키는데, 불규칙한 데이터의 I/O 수행속도는 느리지만 연속적인 I/O 수행 속도는 매우 빠르다. 한 번에 하나의 디스크에 대해서만 I/O 작업을 진행한다는 단점이 있다. Raid-4는 하나의 디스크 전체를 Parity bit 저장을 위해서만 사용한다. 10개의 디스크가 Raid-4로 구성되었다면 9개의 디스크에는 데이터가 나머지 한 개의 디스크에는 Parity가 저장된다. 이 구성의 단점은 나머지 9개의 디스크에 데이터 I/O가 진행되는 동안 하나의 Parity 디스크에는 I/O 집중에 의한 병목현상이 발생할 수 있다는 것이다. Raid-5는 Single Parity 디스크를 운용하지 않는다는 점을 제외하면 Raid-4와 거의 유사하다. 1번 디스크에 데이터가 저장되면 1번이 아닌 다른 디스크에 Parity bit가 저장되는 방식으로 모든 Raid-5상의 디스크들이 데이터와 Parity를 저장할 수 있다. 최근 도입되는 신형 어레이 장비는 대용량의 자체 캐시와 Parity Bit 연산 전용 CPU를 탑재함으로써 쓰는 작업시(Write) 발생하는 오버헤드를 극복하고 있다.

물리적인 디스크 레이아웃(Layout)을 재배열할 때는 다음의 고려사항에 유념해야 한다.

[1]핫 플러깅 디스크(Hot Plugging Disk) : 시스템이 서비스를 계속 진행 중인 상태에서 디스크의 물리적인 교체 작업이 가능해야 한다.

[2]물리적 용량 : 하나의 디스크 사이즈는? 하나의 컨트롤러에 배열될 수 있는 디스크의 갯수는? Raid 레벨에 따른 오버헤드에 의하여 줄어드는 디스크 공간의 크기는?

[3]성능 : 하나의 컨트롤러에 전체(Full) 디스크를 배열하고 다른 하나의 컨트롤러에는 두세 개의 디스크만을 나열한다면 어레이 컨트롤러의 커넥션에 의한 성능 저하를 야기시킬 가능성이 있다.

[4]캐비넷 스페이스(Cabinet Space) : 슬롯 부족으로 인한 캐비넷의 추가 구매가 발생할 수 있다. 최초 구성시 철저한 계획의 부족이라고밖에 볼 수 없다.

[5]케이블 관리 : SAN이나 NAS의 경우 광케이블의 길이 및 관리 또한 충분한 고려대상이다.

[6]파워 서플라이 : 데이터센터나 다른 건물들에서 추가될 하드웨어 전체가 사용할 충분한 전력량 확보도 확인해야 한다.

Raid 구성에 대한 원론적인 논의보다는 현재 스토리지 시장의 변화와 이슈들을 들여다보는 것이 더 유익할 것이다. 지난 수년간 스토리지를 도입해온 기업들은 SAN(DAS)이나 NAS의 형태로 스토리지 시스템을 구성하면서 서버 접속 및 스토리지 확장의 편리성을 비롯하여 다수의 서버와 다수의 스토리지 접속을 통한 정보 공유거리 제약의 한계 및 성능 한계 극복, 통합 관리에 따른 관리 비용 및 관리노력 감소 등 많은 이점을 제공받았다.

하지만 업무목적과 지역적인 위치에 따라 스토리지가 다르게 도입되었고, 결국 스토리지와 그 주변 자원을 관리하는 업무가 또 하나의 업무가 된 부작용을 초래하였다.

관리 데이터와 네트워크, 시스템, 애플리케이션, 사용자, 장비 및 지원 등의 관리 부분들 내의 데이터 관계를 나타내는 공통 정보모델로써, CIM은 MOF(Managed Object Format)로 UML(Universal Modeling Language)을 이용해 정의되는데, 비용 절감과 가용성을 극대화하기 위해 On-Site나 지리적으로 분산된 스토리지 자원들의 중앙 집중화된 관리를 가능하게 하는 것이다.

<그림 1> 다양한 플랫폼의 지원

  

시스템 보호를 통한 고가용성 구현

컴퓨터 시스템의 대부분은 보통 12개 이상의 구성요소(프로세서, 디스크, 메모리, 파워서플라이, 팬, 메인보드, 확장 슬롯, 백본 등)들로 이루어지며, 이 구성요소들 각각의 하부 요소들이 편재돼 있다. 결국 하나의 시스템에는 SPOF를 구성하는 매우 다양한 형태의 부품들이 MTBF의 길목을 노리고 있는 것이다.

만약 대체 서버가 구성되어 있다면 각각의 SPOF에 대한 확실한 Resillience를 확보하여 이론적으로는 최소한 98% 이상의 가용성을 확보할 수 있게 되는 것이다 이러한 페일오버 시스템(Failover System)에 대한 전반적인 구성과 이슈들을 살펴보자.

페일오버의 요구사항

클러스터는 두 서버들이 서로 가까운 곳에 위치해 있어야 하는데, 그 중에서도 두 서버들이 클러스터로 바뀌도록 요구하는 다양한 구성 요소들에 대해서 살펴보아야 한다. 필요한 구성요소들은 다음과 같다.

◆ 서버 : 주(Primary) 서버와 대기(Take) 서버(또는 스탠바이 서버), 이렇게 두 대의 서버가 필요하다. 어떤 경우에는 대기 서버를 대체 서버라고 부르기도 하지만 이는 같은 의미로 볼 수 있다. 주 서버가 제 기능을 수행할 수 없는 상황이 닥치면 주 서버에서 멈춘 응용 프로그램을 대체 서버로 마이그레이션(migration)하는 과정을 페일오버라고 한다.

◆ 네트워크 커넥션 : 페일오버를 구성하는 데에는 세 가지의 다른 네트워크 연결이 요구된다. 첫 째는 쌍으로 엮여진 HeartBeat 네트워크로, 한 서버에서 다른 서버로 바로 통신하지만 이것은 전적으로 상호간에 독립적이며 매우 기본적인 것이라 할 수 있다. 이 네트워크는 서버들이 다른 서버와 연결하게 하고 모니터하도록 하여 쌍을 이루는 상대에게 조치가 필요한 일이 발생하는 것을 즉시 알아차리게 된다.

두 번째 네트워크 연결은 일반 서비스 네트워크를 의미한다. 세 번째는 관리를 위한 네트워크로 페일오버가 발생한 후에라도 시스템 관리자들에게 각각의 서버 간의 네트워크 경로를 보장한다.

◆ 디스크 : 페일오버에는 두 종류의 디스크 유형이 있는데, 첫 번째인 내부 비공유 디스크들을 현재 동작하고 있는 서버가 아닐 경우 각각의 시스템이 시스템 작동을 위해서 페일오버 과정을 초기화하여 유지하게 하는 소프트웨어를 포함하여 운영체제와 필요한 다른 파일들을 가지고 있다. 다른 종류의 디스크는 공유된 디스크들(Shared Disk)이고, 여기에는 중요한 응용 프로그램의 데이터가 자리를 잡고 있다.

페일오버가 발생했을 때 디스크들을 서버들 사이에서 이동(migration)하여 클러스터된 양 서버에 의해 접속이 가능하게 된다. 비록 일반적인 환경에 놓여 있다 하더라도 한 번에 하나의 서버에 접속할 수 있으므로 페일오버 상의 모든 디스크들은 일반적으로 여유분을 가지고 있어야 한다.

◆ 애플리케이션 : 페일오버에서 응용 프로그램은 클러스터 디자인의 중요한 요소로 취급되어야 한다. 그럼에도 불구하고 응용 프로그램에 대한 중요성은 일반적인 페일오버 디자인에서 추가적인 비용문제를 야기시킨다.

대부분의 경우 양쪽 서버에서 동시에 실행될 경우의 애플리케이션 비용과 한 쪽씩 교대로 실행되는 경우의 애플리케이션 비용은 차이가 있다. 양쪽 서버에서 완벽하게 작동되는 제 가격의 라이선스를 구매함으로써 HA를 구성하는 비용은 최초의 예상보다 높아질 것이 분명하다.

◆ SPOF : 페일오버 시스템에서 SPOF는 거의 모든 부분에서 제거되었다고 볼 수 있다. 싱글 노드 서버에서 일반적으로 잘 알려진 SPOF(PROM, CPU, 메모리, SCSI 컨트롤러, 애플리케이션 등)들은 거의 대부분 페일오버 시스템상에서 제거된 것처럼 보인다.

그러나 페일오버 시스템상에서도 여전히 SPOF의 문제점은 남아 있다. 이것은 매우 일반적인 구성 요소로 쌍으로 된 모든 요소와 관련이 있다. 클러스터의 구성 요소가 있다면 두 서버가 사용할 수 없는 경우 고가용성을 가졌다고 볼 수 없기 때문이다.

 

 

페일오버 구성 방법

페일오버 환경설정에 사용되는 다양한 방법들 중 몇 가지를 살펴보고, 이를 적용하는 경우의 이슈들을 살펴보자. 한정된 지면상 2 노드(Two-Node) 페일오버를 중심으로 그 구현방식들을 살펴보고자 한다.

2 노드로 운용되는 페일오버 환경 설정은 가장 간단하면서 널리 이용되는 경우이다. 투 노드 환경 설정은 크게 비대칭형(Asymmetric)과 대칭형(Symmetric)의 두 가지로 나뉜다.

비대칭형 2 노드 환경 설정에서는 한 개의 노드가 활성화되어 대부분의 일을 수행하게 되고, 그 동안 다른 하나의 노드는 스탠바이 전용으로, 즉 활성화되어 있던 노드가 고장을 일으키게 되면 바로 이를 대체할 수 있는 대기 상태가 된다. 대칭형 2 노드의 경우에는 양 노드가 완전히 개별적으로 돌아가고 있다가 어느 한 쪽이 고장을 일으키게 되면 살아남은 다른 노드에 이를 고스란히 떠넘겨 두 배의 작업을 처리할 수 있게 함으로써, 고장난 노드가 고쳐질 때까지 버틸 수 있도록 되어 있다.

Asymmetric 1-to-1 페일오버

<그림 2> Asymmetric 페일오버 구성 사례

<그림 2>에서 나타나는 페일오버의 예는 가장 단순한 형태이면서 전형적인 액티브-스탠바이(Active-Standby)의 모델을 보이고 있다. 최초 액티브 노드에서는 공유 디스크를 마운트한 상태이며, 서비스 네트워크 IP를 가지고 있다. 물론 응용 프로그램의 실행과 서비스를 진행하고 있으며, 클러스터 소프트웨어는 시스템의 모든 서비스가 정상적으로 진행되는지의 여부를 모니터링하고 있다.

만일 액티브 노드의 모든 SOOF 중 서비스를 정상적으로 제공할 수 없는 장애 상황에 봉착하게 되면 클러스터 소프트웨어는 응용 프로그램의 서비스를 내리고, 공유 디스크(Shared Disk)를 Unmount하며, 서비스 네트워크 IP를 놓는다. 반대로 스탠바이 서버는 서비스 네트워크 IP를 가지고 와서 네트워크 카드에 설정하고, 공유 디스크를 마운트시키며, 응용 프로그램이 서비스를 시작할 수 있도록 준비한다. 각 클라이언트들은 동일한 IP로부터 서비스를 공급받게 된다.

이러한 비대칭 페일오버 시스템에서 가장 큰 고민거리는 같은 비용을 주고 도입한 스탠바이 서버가 놀고 있다는 상황이다. 물론 가용성을 끌어올리기 위하여 지대한 역할을 했다는 것을 엔지니어의 입장에서는 이해할 수 있겠지만, 비용을 지출한 고객의 입장을 정당화하기는 힘든 문제이다.

Symmetric 1-to-1 페일오버

<그림 3> Symmetric 페일오버 구성 사례

Symmetric 페일오버 시스템은 액티브-액티브 페일오버로서 비용적인 측면보다 효율적인 비용 대 효용을 달성할 수 있으므로 대칭형 페일오버가 바람직하다고 볼 수 있다. 100% 이상의 중복 투자를 하는 대신 이중 연결(Dual-Connect) 디스크와 HeartBeat 네트워크에 들어가는 비용만 추가될 뿐이다.

실제로 대칭형 페일오버 시스템에서 남아 있는 가장 큰 문제점은 Take Over가 발생한 시점 이후로 한 서버가 두 대의 서버가 하던 일을 하게 됨으로써 과부하(Over Load)가 걸릴 수 있다는 것이다. 필자는 이러한 대칭형 시스템이 페일오버된 후 한 노드에서 과부하를 견디지 못하고 두 대의 노드가 순차적으로 다운되는 현상을 목격한 적이 있는데, 이것은 정밀한 용량 산정(Capacity planning & Sizing)이 뒷받침되지 않은 상태에서 페일오버 디자인이 되었기 때문이다.

또 한 가지 남아 있는 문제점은 페일오버가 발생할 경우 첫 번째 노드에서 진행되던 트랜잭션이 취소(rollback)되지 않고, 두 번째 노드로까지 완벽하게 Take over가 될 수 있는지의 문제이다. 이 문제를 해결하는 대표적인 사례가 오라클 9i RAC(Real Application Cluster)인데, 한 노드에서 진행되던 트랜잭션이 롤백되지 않고 다른 노드의 인스턴스에서 이어서 처리되도록 하기 위하여 캐시 퓨전이라는 기능을 사용하고 있다. 결과적으로 응용 프로그램의 트랜잭션 Take Over 문제에 대해서는 애플리케이션의 완벽한 테스트와 적용이 요구된다.

데이터 보호와 시스템 보호를 통해서 고가용성을 구성하는 몇 가지 방법과 사례만을 위주로 살펴보았다(시스템 복구의 구현에 대해서는 다음 글에 언급하고자 한다). 이 안에는 네트워크의 이중화 구성 방법에 대해서는 전혀 언급하지 못한 것이 아쉽다(실제로 필자가 재직하고 있는 회사는 150여명의 뛰어난 네트워크 엔지니어들이 포진하고 있다).

가용성의 다양한 측면을 이해하고, 가용성의 목적인 Business Availability로 그 기능과 역할이 전달될 때, 진정한 엔지니어링의 힘과 효용이 두드러질 것이다. 좁은 의미에서의 가용성을 다루어 보았지만, 관리자로서 반드시 관심을 가지고 그 기술적 추이를 지켜봐야 할 분야이다.

 

용량 산정 분야

몇 년 전, 한 업체가 신규 데이터베이스 시스템을 도입할 때 직접 설치 지원을 나간 적이 있었다. 그 고객에게 이 시스템의 용량 산정을 어떻게 하였느냐고 물었더니 영업사원이 제안서에 제시한 대로 구입한 것이라는 답변을 했다. 그 영업사원에게 어떤 방식으로 용량 산정을 했냐고 또 물었더니 고객이 제시한 가격에 맞추어서 부품들을 끼워넣었다고 했다. 이것이 우리의 현실이다.

기업의 규모가 크고 재정적인 뒷받침이 확고한 전산실에서는 정확한 컨설팅을 의뢰하여 시스템 도입을 진행하지만 대다수의 기업에서 시스템을 도입할 때는 ‘주먹구구’가 현실인 것이다. 결국 필자가 설치 지원을 나갔던 그 업체는 2년이 채 지나지 않아서 CPU와 메모리 그리고 신규 디스크 어레이의 도입을 검토하게 되었고, 최근에는 다시 새로운 시스템의 도입을 고려하고 있다고 한다.

시스템의 용량 산정에 대한 기술은 매우 전략적인 접근이 필요하다. Capacity Planning & Sizing에 대한 이론적, 기술적인 정보들은 IT 기업의 핵심 기술력에 포함되며, 실제로 잘 공유되지 않는(오픈되지 않는) 기술군 중 하나이다. 하나의 시스템을 계획할 때, 그 구성요소 각각에 대한 정밀한 용량 산정 없이 장비 도입이 이루어진다면 이러한 사례는 불을 보듯 뻔한 현상으로 다가올 것이다.

정확한 용량 산정을 위해서는 매우 다양한 시스템 구성요소들을 살펴보아야 하지만, 여기에서는 CPU, 메모리, 디스크 용량에 대한 사이징 방법과 국제적인 벤치마크 테스트가 어떻게 사용되는지 살펴보도록 하겠다.

용량 계획 프로세스와 고려사항
용량 산정을 위해서 일반적으로 <그림 4>와 같은 프로세스를 적용시키는 것이 보편적이다.

<그림 4> 용량 산정 프로세스

 

[1] Estimate Load : 작업(업무) 로드량을 측정한다. 여기에는 실제로 시스템에 적용될 응용 프로그램과 그 환경(투-티어, 쓰리-티어인지, 미들웨어나 WAS 제품의 특성, 로드량의 증가분과 변수)들도 고려되어야 한다.

[2] Compare Load HW, SW : 분석된 작업(업무) 로드량을 바탕으로 하드웨어와 소프트웨어의 용량을 분석한다. 측정된 성능 측정표를 기반으로 시스템의 물리적, 논리적 용량 산정이 분석된다.

[3] Make Cost/Benefit Trade-off : 최상의 효율을 고려한 하드웨어/소프트웨어의 용량과 최적의 투자비용에 대한 Trade-off를 준비한다.

이후 설치, 모니터, 튜닝 과정을 통해 시스템의 안정화를 유도한다. 또한 안전한 시스템의 예측(Prediction)을 위해서는 다음의 4가지 요소들이 주의 깊게 다루어져야 한다.

[1] Consider All Resources : 현재 병목현상을 발생시키는 요소가 아니더라도 모든 자원을 대상으로 용량 산정 계획을 진행하여야 한다. 현재 디스크 I/O 자원의 Utilization이 100%에 도달했다고 해서 디스크 자원만 증설하는 것보다 앞으로 사용량이 늘어날 가능성이 있는 CPU나 메모리 자원에 대해서도 동시에 고려하는 것이 바람직하다.

[2] Application Environments : 얼마나 많은 사용자가 사용하는가? 이 애플리케이션은 OLTP 목적인가? DSS 목적인가? 시스템을 이용하는 애플리케이션은 CPU intensive한가? I/O intensive한가? 이 애플리케이션은 Short Job인가? Long Job인가? 등 애플리케이션의 특성은 시스템의 성능과 용량 사전 계획에 궁극적인 결정 포인트로서 작용한다.

[3] Annual Inflation : “WorkLoad가 어떤 형태로 늘어나는가?” 하는 것은 매우 중요한 요소 중 하나이다. 예를 들어 매년 15%씩 업무 증가량이 발생한다고 했을 때, 사용자가 15% 늘어날 수도 있고, 프로그램의 트랜잭션량이 늘어난 것일 수도 있으며, 처리해야 할 데이터량이 늘어난 것일 수도 있다. 결국 늘어난 Job Load의 특성에 따라 CPU, 메모리, 디스크 I/O, 네트워크 등의 용량 산정 요소가 바뀔 수 있다.

[4] Performance of complex system : 성능분석 포인트는 용량 산정과 가장 깊은 관계를 맺고 있는 분야이다. 부정확한 성능 분석 데이터로부터 정확한 시스템 용량 산정 계획이 이루어질 수 없다. 복잡한 시스템에서 한 요소에 대한 성능 분석은 서브 시스템 부분에 대한 구체적인 성능 통계 데이터들의 취합으로부터 이루어져야 하므로 보다 더 정밀한 분석을 요한다.

예를 들어 I/O 성능에 대한 분석이 I/O 용량 산정으로 이어지기 위해서는 I/O 보드, SCSI 컨트롤러, I/O 버스, 디스크 어레이, 디스크 자체 등 I/O 활동을 구성하고 있는 모든 서브 시스템에 대한 구체적인 성능 분석들이 정확하게 이루어져야 한다.

 

각 요소별 용량 산정 사례

정밀한 시스템의 용량 산정을 하기 위해서는 앞에서 설명한 용량 산정시 고려사항 항목들을 모두 검증해야만 한다. 서브 시스템의 세부 용량이라든가, 애플리케이션의 특성 분석 및 반영 등이 빠져서는 결정적으로 완벽한 시스템 용량 산정이 이루어졌다고 볼 수는 없다.

그러나 일반적으로 시스템의 용량 산정을 진행할 때 서브 시스템의 구체적인 성능 및 용량은 제조사의 테스트 결과를 신뢰하거나 국제적인 벤치마크 결과를 반영하므로, 시스템의 CPU, 메모리, 디스크 공간에 대한 사이징만을 진행한다. 그리고 애플리케이션에 대한 벤치마크 결과는 소프트웨어 생산 업체의 자체적인 테스트를 통하여 보정률을 적용한다.

이에 근거하여 보편적으로 시스템 구축시 CPU, 메모리, 디스크 공간의 용량 산정 방법을 알아보자.

<표 2> 일반적인 산정 기준

※ tpmC = 동시사용자수×분당 트랜잭션(사용자수×트랜잭션 복잡도(50%))+인터페이스(가중치%)×네트워크 보정(30%)×피크 타임 보정(50%)×I/O 부하(20%)×년간 업무증가 및 여유율(연 20%)

※ 메모리 용량 = {(OS 커널(100M)+[ SGA() ]+사용자수×5MB)+[Webserver()]+인터페이스(가중치%) }+여유율(30%)

※ AP 서버 디스크 용량 = {OS 커널(제조사 표준 값)+[Pkg(제조사 표준 값)]+[웹 서버(제조사 표준값)]+메모리 Swap(실제 메모리의 두 배) }×여유율(30%)

※ DB 서버 디스크 용량 = {(Data file() + archive file() + RAID 보정}×여유율(30%)

<표 3>CPU 용량 산정 사례

<표 2>의 기준들은 다시 강조해서 말하지만, 보편적인 형태의 용량 산정시 기준들이다. www.tpc.org에 제공되는 벤치마크 기준은 TPC-C(OLTP 기반), TPC-W(웹 기반), TPC-H(대량의 데이터 처리 기반) 등의 다양한 표준을 제시한다. 그리고 피크 타임 보정율, 애플리케이션 복잡성에 따른 보정율, 시스템 소프트웨어 보정율 등은 해당 제조사와 소프트웨어 개발 업체의 테스트된 신뢰성 있는 정보를 기반으로 설정되어야 한다. 그럼 각각에 대한 구체적인 적용사례들을 살펴보자.

CPU 용량 산정 사례

이 CPU 용량 산정 사례는 2001년 1월에 발표된 S사의 엔터프라이즈 모델의 tpmC 값 21871.90을 기준으로 한 기업의 데이터베이스 서버의 트랜잭션량을 분석한 결과이다. 용량 산정시 고려되었던 핵심 기준은 1000만명의 고객이 동시에 액세스할 때의 Job Load량의 Inflation이었다. 기준이 되는 일 발생 트랜잭션 처리 수(629,760)는 DB 엔진을 대상으로 분석한 결과 값이며, DB 크기와 트랜잭션 분석(조회 15 : 저장 1건)의 비율이 적용되었다.

CPU당 처리될 수 있는 분당 트랜잭션량을 비교한 결과 1000만 고객을 대상으로 할 경우 현재 트랜잭션의 3배를 가중시킨 결과 현재 CPU 사용률(Idle Time 90% 이상)을 고려해 8개의 CPU 구성을 결정하였다. 물론 이러한 구성이 완벽한 CPU 용량 산정이라고 볼 수는 없으나, 애플리케이션 개발 업체의 검증된 보정율과 하드웨어 제조사의 스펙을 기준으로 최대한 객관적인 수준의 사이징을 유도하였다고 판단된다.

메모리 용량 산정의 사례

<표 4> 메모리 용량 산정 사례

용량 산정 당시 시스템에서는 6GB 메모리 중에 실제 DB 시스템에서 사용되는 메모리량은 1/3을 약간 웃도는 상태였는데, 현재 상태의 메모리 크기로도 800만명의 고객을 대상으로 충분한 서비스가 가능하지만 1000만명을 대상으로 하는 tpmC 값을 고려할 때 7638MB의 메모리를 산정하여야 했다(이 값에는 여유율 40%가 포함된다. 이 값은 과도하게 산정된 감이 없지 않다).

데이터베이스 서버의 메모리 산정에서 가장 중요한 것은 데이터베이스 인스턴스 메모리와 그 여유율, 그리고 동시 접속자들의 세션 수에 비례하는 Private Memory의 총합이라고 볼 수 있다. 따라서 앞 사례의 경우 데이터베이스 엔진의 특성이 메모리 용량 산정의 관건이라고 볼 수 있다.

디스크 용량 산정의 사례

<표 5> 디스크 용량 산정의 사례

이 시스템의 Internal Disk로 구성되어 있는 데이터베이스 서버의 저장 공간은 총 64GB이며, 이 중 오라클 데이터를 저장하기 위한 할당된 공간은 24GB(24GB 중 13GB 사용, 사용률 55%)로 분석되었다. 이 때 사용 공간에 대한 용량 산정은 Raid 1+0로 구성할 것인지, Raid-5로 구성할 것인지에 따라 많은 편차를 보이게 될 것이며, 레이드 구성 방식이 성능에 미치는 영향력 또한 간과할 수 없을 것이다.

또한 데이터 및 트랜잭션이 3배 이상 증가하는 1000만 고객 시점에 디스크 I/O 병목현상을 예상하여야 하며, 따라서 현재의 I/O Throuput 및 Utilization을 고려하여 속도가 빠른 외장형 디스크 어레이를 적용하여야 한다. 현재 초당 I/O량이 5.46mb/s인 것을 감안하였을 때, 앞으로 3배의 I/O량이 늘어났을 경우 16.38mb/s를 처리할 수 있는 고성능의 외장형 디스크 어레이가 요구된다.

용량 산정의 새로운 이슈, SLM

이상에서 시스템을 구성하는 세 가지 요소(CPU, 메모리, 디스크)에 대한 용량 산정의 일반적인 규칙들과 사례를 통하여 살펴보았는데, 최근 들어 용량 산정에 영향을 미치는 새로운 이슈로 등장한 것이 바로 SLM(Service Level Management)이다.

시스템이 어떤 부품들로 구성되어 있는지, 어떤 데이터베이스가 운용되고 있는지, 네트워크 백본이 어떻게 구성되어 있는지도 중요하다. 그러나 고가용성 시스템을 구성하는 경우에도 SLM이 적용되었듯이, 용량 산정의 보다 근본적인 기준은 비즈니스 목표를 달성하기 위한 서비스 레벨이 맞추어져야 한다는 것이다.

IT 인프라스트럭처 전체를 놓고 하나의 서비스가 완벽하게 전달될 때까지 서비스 레벨은 조율되어야 하며, 이에 따라 고가용성 시스템의 용량 산정이 이루어져야 한다. 이 같은 변화의 원인은 이제 우리 IT 서비스 시장이 성숙되어 가고 있는 데서 기인한다고 본다. 주먹구구식 시스템 디자인으로 불과 1～2년 만에 증설이나 시스템 변경이 횡횡하던 시절은 하루 빨리 벗어나야 할 것이다. @


* 이 기사는 ZDNet Korea의 제휴매체인 마이크로소프트웨어에 게재된 내용입니다. 

 

원문 : http://www.zdnet.co.kr/builder/system/server/0,39031667,39133853,00.htm

[시스템 관리 노하우를 말한다] ① 시스템 유지·보수와 성능 관리

 

연재순서
1회. 시스템 유지·보수와 성능 관리
2회. 고가용성과 시스템 용량 산정
3회. 장애 복구와 ITIL 적용

 

‘시스템 엔지니어’라는 직업으로 활동하고 있는 수많은 관리자들이 오늘도 밤을 지새우며 전산실을 지키고 있을 것이다.

오늘날 그들에게 요구되는 역할(role)은 예전처럼 단순하지 않다. 하드웨어와 몇몇 운영체제 명령어를 구사할 줄 알면 시스템을 운용할 수 있었던 시절은 이미 오래 전에 지나갔다.

엔터프라이즈 아키텍처를 지향하는 전산실의 업무 환경은 시스템 엔지니어에게 광범위한 기술적 지식과 자신만의 전문화를 필요로 하고 있다. 단순한 오퍼레이터(Operator)가 아닌 엔터프라이즈 아키텍처의 코디네이터(Co-ordinator)로서의 시스템 관리자는 나름대로의 비즈니스 마인드과 테크니컬 비전을 가지고 있어야 한다.

이것은 어떻게 보면 딜레마이기도 하다. 한 분야에서 최고의 권위자가 될 정도로 전문성을 유지하면서, 전반적인 IT 인프라스트럭처에 대하여 해박해야 한다는 것은 상반되는 개념은 아니지만, 시스템 관리자에게 끊임없는 자기 계발과 노력을 요구하기 때문이다. 이 글에서는 시스템 관리자의 이런 계발과 노력에 도움이 되고자 다음의 분야들을 3회에 나누어 다뤄 보고자 한다.

시스템 관리라는 분야가 워낙 방대한 분야이기 때문에 어떤 분야를 다루어야 하며, 어떤 분야는 다루지 않아도 된다는 규칙 같은 것은 없지만, 보편적으로 시스템 관리자들이 현재까지 해왔고 또 앞으로 맞닥뜨리게 될 영역들을 주제로 정하게 되었다. 전반적인 글의 비중은 관리적인 측면에서의 프로세스적인 면과 기술적인 내용을 위주로 전개될 것이며, 효율적인 시스템 관리를 위한 조언들과 경험(사례)을 포함시켜서 진행하려 한다.

시스템 유지보수 일반론

e-비지니스 관점에서의 시스템 관리

1996년 6월 미국의 대표적인 온라인 증권회사인 찰스슈왑사는 전산 시스템이 1시간 동안 다운되는 시련을 겪었다. 동시에 수십 만 건의 트랜잭션을 처리하던 전산 시스템은 한 순간에 고철덩어리가 되어 버렸고, 수십 만 e-트레이딩 주자들의 항의가 빗발쳤다. 이 기업의 주식은 그 1시간의 다운타임 동안 26%가 하락해 버렸고, 회사의 신뢰는 바닥에 떨어지고 말았다. 불안정한 IT 인프라스트럭처의 운용이 기업의 이익 구조를 최악의 상황으로 몰고 간 것이다.

이제 IT 인프라스트럭처는 기업 경쟁력을 좌지우지하는 핵심 기능으로 급부상하였고, 모든 업무(인사, 재무, 회계, 생산, 판매, 재고, 마케팅, 고객 서비스 등)는 통합되고, 전사적자원관리(ERP), 지식관리시스템(KMS), 고객관계관리(CRM) 등의 형태로 전환되어 기업의 경영 방향을 결정짓는다. 즉 오늘날의 기업 경영에 있어서 전산 시스템 자체는 기업의 오퍼레이션 뿐만 아니라 그 기업의 자체 경쟁력을 제고하는 중요한 전략적 도구가 되었다.

다운타임의 비용
다운으로 인한 비용은 값으로만 측정되지 않는다. 다운으로 인하여 잃게 되는 것은 사용자를 잃는 것과 함께 사용자가 어떠한 작업을 하다가 손해를 입었는가에 달려 있다.

만약 사용자가 개발자라면 다른 비용보다도 개발자를 고용하고 개발 기간에 든 비용이 더 클 것이다. 물론 거대한 개발 조직이라면 비용은 상당할 수 있다. 시스템 다운으로 작업할 수 없었던 부분을 보충하기 위해서 필요한 야근수당 등은 여기에서 빠져 있는 것이다. <표 1>은 산업 직군별 비즈니스 형태별 다운타임이 발생했을 경우 시간당 평균 비용을 나타내고 있다(현재 시점의 환율을 적용하여 한화로 환산하여 보았다).

<표 1> 다운타임에 따른 평균 비용 (원화로 환산, 자료출처 : 데이터퀘스트, 펄스펙티브, 2003년 12월 31일)

이 다운타임 비용에는 잠재고객을 다른 회사로 빼앗김으로써 장기적으로 회사에 누적될 기회비용의 손실 같은 것은 제외되어 있다. 표면적으로 회사가 입은 손실만 분석된 셈이다.

이제 시스템 관리자는 자신의 시스템이 다운되어 있는 동안 기업 입장에서 얼마만큼의 손실이 발생하는가에 대하여 정확하게 이해하고 있어야 한다. 서비스 엔지니어의 입장에서 항상 SLA에 관심을 가져야 하는 이유가 여기에 있다. 특히 시스템 다운으로 인한 직접 혹은 간접적인 손해 비용을 이해하고, 그에 따른 시스템 관리 포인트를 생각해보면 어디에서 기초해야 하는지는 자명해진다.

경영진은 전산 시스템에 요구하는 가용성에 대하여 SLA에 반드시 규정하고 있으며, 심지어는 구체적인 전산 업무 처리량(트랜잭션 단위로)까지 명시하고 있다. 하루 100만 건의 트랜잭션을 처리해야만 정상적인 기업의 이익구조가 유지된다면 이 트랜잭션 양, 또는 한 건의 트랜잭션을 처리하는 데 소요되는 시간이 SLA에 명기되는 것이다.

따라서 시스템 관리자가 관심을 가져야 하는 분야는 시스템을 구성하고 있는 하드웨어나 운영체제 자체가 아니라, 어떻게 관리하면 ‘이 시스템으로 기업이 요구하는 가용성과 성능, 업무처리량을 유지할 수 있느냐’하는 것에 초점을 맞추어야 한다.

시스템 유지보수를 위한 제언
만약 필자에게 주어진 시스템이 세상에서 가장 완벽한 시스템이라면 어떨까? 이 시스템의 하드웨어, 운영체제(OS), 데이터베이스, 애플리케이션에 대하여 전혀 신경을 쓰지 않아도 시스템은 다운타임 없이 운용되며, 고객(Customer & User)은 항상 최상의 만족도를 나타낸다고 상상해 보자. 정말 행복한 상상이 아닐 수 없다.

하지만 아직까지 필자가 거쳐본 수 백 가지 유형의 IT 인프라 중에서 그러한 시스템은 없었다. 하다못해 로그 파일이라도 정리하지 않으면 시스템은 새벽 3시의 단잠을 방해하는 말썽꾸러기로 변해 버리기 때문이다.

그래서 시스템 관리의 제 1법칙은 ‘유지보수가 항상 필요하다’는 것이다. 그 유지보수는 시스템의 가용성(Availability)과 업무에 미치는 영향(Business affection)을 최소화 시키는 범위 내에서 이루어지는 것이 바람직하다. 24시간 365일 운용되는 시스템의 유지보수를 위하여 다운타임을 요구하는 것은 비즈니스 수익(Profit)을 깎아먹는 것이므로 이러한 시스템에는 항상 최적의 대안으로 탄력성(Resilience)을 확보하여야만 한다. 시스템 유지보수를 위한 전반적인 고려사항들을 정리해 보자.

성공적인 유지보수를 위한 계획과 고려사항
성공적인 유지보수를 위해서는 몇 가지 고려해야 할 조항이 있다. 우선 유지보수 작업 전에 이 작업이 다른 서버, 클라이언트, 네트워크, 데이터베이스, 애플리케이션 등에 미치는 영향을 항상 고려하여야 한다. 그리고 예상할 수 있는 최악의 상황에 대비하여 항상 계획적으로 작업을 진행하여야 한다.

데이터베이스를 업그레이드 하는데, 업그레이드 후 테이블의 모든 내용이 사라졌다든가, 파트 교체를 진행하는 과정에 정전기로 메인보드가 손상을 입게 된다든가 하는 상황을 예측해 볼 수 있다. 특히 시스템에서 진행되는 작업이 완벽하게 진행되지 못했을 경우, 원상태로 되돌려 놓을 방안이 강구되어야 한다.

이러한 원상복구 계획 없이 중요한 시스템을 변경하는 작업은 금물이다. 즉 작업 전에 전반적인 환경에 대한 백업이 요구되며 하드웨어 차원에서의 리던던시(redundancy)를 확보해 놓은 상태에서 작업이 진행되어야 한다. 또한 유지보수 작업에 영향을 미칠 수 있는 전반적인 상황을 분석하고, 설립된 계획에 대해서는 동료 또는 상관에게 자문을 구하는 것이 바람직하다. 실제로 수립된 계획이 완벽하다고 하더라도 동료의 계획에 대한 검토는 더 좋은 개선과 대안을 이끌어 낼 수 있다. 그 외의 내용을 정리하면 다음과 같다.

시스템 변경시의 제안 사항
시스템 변경은 더욱 주의를 요한다. 이때 고려할 사항을 보면 우선 시스템에 발생시키는 변경 작업은 한 번에 한 가지씩만 적용하는 것이 좋다. 필자가 초보 DBA로 데이터베이스 시스템을 운용할 때, 인스턴스 튜닝을 하면서 동시에 다섯 가지의 파라미터 값(Value)을 변경시킨 적이 있었다.

데이터베이스를 재가동 시켰을 때 문제가 발생했는데 어떤 파라미터의 수정이 원인이 되었는지 알아내기 위해서는 많은 시간이 소모되었다. 시스템의 하드웨어 교체, 운영체제의 업그레이드, 패치, 애플리케이션의 환경 설정 등의 모든 작업에도 이 규칙은 적용되어져야 한다.

또한 시스템에서 발생하는 모든 변경작업은 문서화되어야 한다. 사실 엔지니어들의 취약점이 바로 문서화인데, 자신이 작업한 내용을 반드시 틀에 얽매인 완벽한 문서로 남길 필요는 없다. 작업 중에 자신이 참조한 기술문서에 주석처리(comment) 형태로 기술해도 좋고, 작업 화면을 스풀링(spooling) 해서 남겨 놓아도 좋다. 요즘에는 화면에서 작업하는 모든 과정을 동영상으로 캡처해 주는 유틸리티 프로그램도 좋은 것들이 많이 사용되어지고 있다.

이와 함께 시스템의 변경을 자동으로 관리해 주는 툴을 사용하는 것도 좋은 방법이다. 국내에서는 별로 이러한 툴들이 보편화되지 않았는데, 변경관리를 자동으로 모니터링하고, 로깅하면, 알람 기능을 제공하는 프로그램들은 매우 유용하다. 변경 이력사항을 정리해 놓고 있으면 이전 환경과의 비교가 용이해 복구가 쉬워지고, 관리자 간의 인수인계나 심지어는 해킹에 의한 시스템 파일의 변경·파괴에도 쉽게 대처할 수 있다. 이 외에 고려할 사항을 보면 다음과 같다.

성능 관리 분야
시스템의 성능 관리(Performance management)는 매우 핵심적인 주제이며, 시스템 엔지니어에게 필수적인 분야이다. 이 분야에 대해서는 조금 심도 있는 내용을 들여다보아야 한다. 성능 관리는 튜닝과 직결되는데, 시스템이나 데이터베이스, 애플리케이션에서 발생하는 튜닝 포인트를 이해하고, 적절한 방법을 적용하는 것은 그리 쉽고 간단하지 않다.

하드웨어의 특성이나 운영체제의 커널(Kernel)에 대한 이해부터 시스템 자원(resource)을 이용하는 전반적인 프로그램(프로세스)에 대해서도 자세히 알고 있어야 한다. 시스템 관리자는 잘못된 프로세스의 자원 사용 패턴, 플랫폼별 병목현상의 특징, 심지어는 하드웨어의 성능을 무시하고 원천적으로 잘못 설치(install)된 경우의 상황분석 능력까지 가지고 있어야 한다.

성능 관리는 “시스템이 가지고 있는 자원을 보다 적절히 배치해서 사용자에게 빠른 응답시간을 제공하기 위한 작업”이라고 정의할 수 있다. 구체적으로 ‘불필요한 작업의 Unload’, ‘자원 사용 방법의 개선’, ‘시스템 용량 증설’, ‘사용자의 시스템에 대한 이해 향상’, ‘시스템을 정확하게 업무 목적에 적용하는 것’ 등의 행동이 수반된다.

사실 성능 튜닝은 끝이 없다. 성능을 유지하기 위한 기본값(Baseline Measurement)를 설정(SLA 기반)해 놓고, 병목현상을 분석하고, 이것을 제거하는 절차는 시스템을 이용하는 고객이 만족할 때까지 지속적으로 반복된다. 시스템의 성능을 좌우하는 요소들을 카테고리별로 분석하면 <그림 1>과 같다.

<그림 1> 성능 영향요소 분석

<그림 1>에서 나타나는 세 가지 카테고리(시스템의 환경 변화, 워크로드의 특성, 시스템의 처리량 변화)가 전반적인 시스템의 성능을 좌우하며, 따라서 이러한 각 요소들에 대해서 정확한 파악이 있어야 성능 관리의 토대가 준비되었다고 볼 수 있다. 어떤 하드웨어가 설치되었으며, 이 시스템에서 실행되고 있는 운영체제 및 소프트웨어에 대한 경향분석(예를 들어 프로그램이 CPU 지향적인가, 디스크 I/O 지향적인가)은 시스템의 성능 관리 및 튜닝을 위한 기초자료로서 활용될 것이다.

성능 관리를 시작하기 전에 분명히 규정하고 넘어가야 할 것들이 있는데, 바로 성능 튜닝을 위한 용어 정의이다. 용어에 대한 이해가 선행되지 않으면 개념적으로 난해한 요소들에 부딪힐 수 있기 때문이다. 그 중에서 몇 가지 핵심적인 용어의 의미를 명확히 정의하여 보자. 이 용어들은 용량 관리(Capacity Planing & Sizing) 분야의 이해를 위해서라도 꼭 이해하고 있어야 한다.

성능 관리 분야의 용어 정리

▲ Bandwidth - 초과될 수 없는 최상의 용량 - 오버헤드를 무시한 측정치 - The best(perfect) case number - 실행시 도달할 수 없는 어떤 값(실행시 inefficiency(무능, 무효과, 비능률), 오버헤드가 있기 때문) ▲ Throughput - 특정시간 동안 실제 할 수 있는 작업의 량(what you really get) - Bandwidth 중 실제로 사용되는 capacity - 실제 Throughput의 측정값은 다양한 요소들에 의해 영향 받는다.(H/W, S/W, human, Random access) - 정확한 Throughput 값의 측정은 불가능하며, 단지 근사치(Approximated value)만을 구할 수 있다. - Maximum Throughput을 측정한다면 100% 사용율(utilization)에서 얼마나 많은 작업량이 가능한가를 평가하는 것이 된다. ▲ Response Time - 총 경과시간(+ wait time 포함, + Run Queue 대기시간) - 사용자가 응답을 받기까지 걸린 총 시간 - Elapsed Time for an operation to complete - Usually the same thing as latency ▲ Service Time - 실제 request를 처리하는데만 사용된 시간(Queue 대기시간, Wait Time 제외) = actual processing time - The best(perfect) case number - Response Time에서 Wait Time(Queue Delay)을 빼면 Service Time이 된다. ▲ Utilization - 측정대상 작업을 수행하기 위해 사용된 자원의 사용량(독자적이건, 종합적이건) - 자원량 : Throughput을 수행하기 위한 - 백분율(%)로 표시되면 일반적으로 busy%(률)로 나타낸다.

이 용어들은 서로 상관관계를 가지고 있는데, 이용(utilization)이 100%에 도달하는 순간이 되면 반응 시간(Response Time)은 빠르게 되지만(자원의 이용방법에 따라 다르다), Troughput은 포화상태에 도달하여 떨어지게 되어 있다. 이 시점의 Throughput을 ‘Drop-Off’이라고 한다. 결국 성능 튜닝은 100% Busy 상태에 도달한 자원(Drop-Off된 자원)의 소재를 찾아서 그 가용성을 높여주는 것이 목표이다.

그렇다면 이제 시스템의 어떤 자원(resource)이 100% Busy 상태에 도달하여 있으며, 어떻게 이것을 분석해 낼 것인가 하는 문제가 대두된다. 시스템의 구성 요소를 성능 튜닝의 시각으로는 CPU, 메모리, 디스크 I/O, 네트워크, Users(Session or Process(thread))의 다섯 가지 요소로 분리하여 분석한다(결국 이 다섯 가지가 자원(Resource)이다.)

일반적인 유닉스 시스템에서는 커널에서 발생하는 모든 시스템 액티비티(system activity)를 Kstat이라고 하는 스트럭처에 저장해 놓고, sar, vmstat, iostat, mpstat, netstat 또는 OS 의존적(dependent)인 명령어나 툴(IBM AIX의 topas, nmon, HP-UX의 glance, 썬 솔라리스의 SMC, memtool, 그리고 top과 같은 프리웨어도 많이 사용된다)을 사용하여 현재의 성능 상태 정보를 분석할 수 있다.

운영체제마다 제공하는 툴이나 명령어는 조금씩 다르지만 기본적인 커널 메커니즘을 이해하면 대부분의 운영체제가 같은 방법으로 성능 관리 정보를 나타내고 있음을 알 수 있다. 먼저 <그림 2>를 통하여 CPU 및 디스크 I/O의 병목현상을 분석하는 원리를 이해하여 보자.

<그림 2> 프로세스 라이프 사이클

하나의 프로세스(쓰레드)가 시작되면 이 프로세스를 구성하고 있는 실행 최소 단위로서의 쓰레드는 CPU 자원을 바로 획득할 수 없는 경우 CPU에 있는 런 큐(Run Queue)에서 대기하게 된다. 만약 CPU 자원이 충분하게 여유가 있다면 이 쓰레드들은 대기(ready) 상태에서 바로 CPU상으로 올라가 러닝(running) 상태에 도달하게 될 것이다. 결국 런 큐상에 기다리고 있는 쓰레드의 수가 일정 기준치 이상으로 나타난다면 CPU는 병목상태에 있다고 판단할 수 있다.

<그림 2>에서는 추가적으로 디스크 I/O 병목현상에 대한 상황도 포함되어 있다. CPU상의 러닝 중인 쓰레드가 100% CPU에 집중된 일(job)이 아닌 한, 이 쓰레드는 메모리나 디스크로부터 처리해야 할 데이터를 요구하게 될 것이다. 디스크로부터 대량의 데이터를 요구했을 경우 만약 디스크 I/O 속도가 느리다면 러닝 쓰레드는 디스크로부터 데이터가 모두 올라올 때까지 Sleep Queue(또는 Turn Stil Queue라고도 한다)에서 대기하다가 처리해야할 데이터가 모두 올려지면 다시 대기 상태로 가서(awakened됨), schedule deamon으로부터 CPU 타임을 할당 받아 올라온 데이터를 처리하게 된다.

이 때 Sleep Queue에 대기하고 있는 쓰레드를 ‘Blocked thread’라고 하는데, 이 수치가 발생하는 것은 디스크 I/O 병목현상이 발생하는 것을 의미한다. 일반적으로 sar나 vmstat, iostat 명령어를 통하여 <리스트 1>과 같은 정보를 얻어 낼 수 있다.

<리스트 1> sar나 vmstat, iostat 명령어를 통해 얻은 정보

# sar -q 3 10 SunOS ekist3 5.8 Generic_108528-21 sun4u    10/19/04 17:31:12 runq-sz %runocc swpq-sz %swpocc 17:31:15     1.0     33 17:31:15 ........................................................................................................... # vmstat 3 procs memory page disk faults cpu r b w swap free re mf pi po fr de sr m0 m1 m2 m1 in sy cs us sy id 0 0 0 12882976 5217864 752 1114 2274 12 12 0 0 2 1 1 0 2091 2504 1437 198 90 548 0 0 0 12492912 4991664 776 2 5077 0 0 0 0 0 0 0 0 943 2639 2274 4 1 95 0 0 0 12492224 4992376 556 344 5128 0 0 0 0 0 0 0 0 770 3364 1981 9 3 88 0 0 0 12492840 4995552 726 315 6114 0 0 0 0 0 0 0 0 1280 4235 2869 4 2 94 0 0 0 12492832 4996656 579 0 5370 0 0 0 0 0 0 0 0 1119 2709 2266 1 2 97 0 0 0 12492832 4996616 632 0 5130 0 0 0 0 0 0 0 0 3063 18771 6342 16 4 80 0 0 0 12492832 4996248 643 48 5173 0 0 0 0 0 0 0 0 2003 9592 4110 24 2 74 # iostat -xnP 3 extended device statistics r/s w/s kr/s kw/s wait actv wsvc_t asvc_t 1.7%w %b device 0.2 1.2 9.8 10.4 0.0 0.0 0.1 22.4 0 2 c1t1d0s0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 c1t1d0s1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 c1t1d0s2 0.0 0.0 0.0 0.0 0.0 0.0 0.0 21.7 0 0 c1t1d0s3 0.0 0.0 0.0 0.0 0.0 0.0 0.0 25.2 0 0 c1t1d0s4 0.1 1.3 7.1 14.3 0.0 0.0 0.0 12.9 0 2 c1t1d0s5 0.0 1.0 0.0 0.5 0.0 0.0 0.0 24.6 0 2 c1t1d0s7 0.2 1.2 9.8 10.4 0.0 0.0 0.1 23.7 0 2 c1t0d0s0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 15.9 0 0 c1t0d0s1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 c1t0d0s2 0.0 0.0 0.0 0.0 0.0 0.0 0.0 24.3 0 0 c1t0d0s3 0.0 0.0 0.0 0.0 0.0 0.0 0.0 26.6 0 0 c1t0d0s4 0.1 1.3 7.1 14.3 0.0 0.0 0.0 13.0 0 2 c1t0d0s5 0.0 1.0 0.0 0.5 0.0 0.0 0.0 25.4 0 2 c1t0d0s7 35.6 21.4 3408.0 280.0 0.0 0.2 0.0 2.8 0 10 c4t40d0s0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 c4t40d0s2 0.0 44.9 0.0 1437.2 0.0 0.0 0.0 1.0 0 4 rmt/0 0.1 45.0 1,9 1440.0 0.0 0.0 0.0 1.0 0 4 rmt/1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 1.0 0 0 ekist3:vold(pid715)

이 명령들이 나타내는 결과는 현재 시스템에서 어떠한 병목현상도 발생하고 있지 않다는 것을 보여주고 있다. sar 명령의 runq-sz 필드와 vmstat 명령의 r 필드가 바로 런 큐 쓰레드의 갯수를 의미하며, b 필드가 블럭 쓰레드의 수치를 나타내고 있다.

또 한 가지 iostat 명령을 통하여 나타난 asvc_t라는 필드는 average service time(실제로는 반응 시간)을 의미하는데, 이 필드가 20～30ms를 넘으면 디스크 I/O 로드량이 많다고 볼 수 있고, 50ms(밀리세컨드) 이상의 시간을 넘어서면 병목현상이라고 규정하는 것이 일반적이다. %b 필드는 자원의 utilization을 백분율로 나타낸 것으로 이 수치가 100%에 도달하면 throughput은 drop-off 되기 시작한다.

그 외에도 해당 디스크 디바이스에서 발생하는 초당 read/writer량을 분석할 수 있으며 디스크 장치의 커넥션으로 발생하는 wait 발생 건수도 측정할 수 있다.

메모리 자원의 운용원리와 성능분석 포인트
일반적으로 메모리는 다음과 같은 구조로 시스템 아키텍처상의 역할을 수행한다.

<그림 3> 가상/물리적 메모리의 운용

하나의 프로세스가 점유하는 메모리 영역은 물리적 메모리(Physical Memory) 영역과 SWAP 영역에서 동시에 구성되는데, 액티브하게 실행되는 일부가 Page In & Page Out 과정을 통하여 물리적 메모리 영역을 이용하는 것이다. 가상 메모리 기법은 제한된 물리적 메모리를 프로세스가 직접 이용하는 것보다 더 많은 메모리를 프로세스에게 제공하기 위하여 사용되는 기법이다.

프로세스가 이용하는 데이터는 Data & BSS 영역(상수 값, Static 변수, Global 변수 등이 저장됨), Heap(데이터를 저장하기 위하여 malloc() 함수 등으로 동적으로 할당되는 공간), Stack(지역변수(local variable)이 저장) 영역 등에 저장되고, 이 데이터를 CPU 상의 쓰레드가 요구할 때, MMU(Memory Management Unit)에서 제공되는 Address Translation Table을 통하여 물리적 메모리상으로 로드하게 된다.

물리적 메모리를 운용할 때는 일반적으로 LRU 알고리즘이 사용되는데, 이것은 물리적 메모리상에서 최근에 자주 사용된 데이터(데이터가 있는 메모리 페이지)는 조만간 또 사용될 가능성이 있으므로 오래 남아 있도록 하고, 최근에 자주 사용되지 않은 데이터는 조만간 참조될 가능성이 적으므로 Page Out(또는 Age-Out)해 Free Memory를 확보하도록 하는 알고리즘을 말한다.

시스템의 커널 구조에서 Memory Management Module은 조만간 메모리 자원을 요구할 프로세스를 위하여 일정량의 Free Memory를 미리 확보하려는 구조로 설계되어 있다. 요구되는 일정량의 Free Memory가 확보되어 있는 정상적인 상태에서는 추가적인 Free Momory를 확보하려는 활동을 하지 않지만 일단 Free Memory가 부족해지면 Page-Out Deamon은 LRU 알고리즘에 의하여 자주 참조된 데이터와 참조되지 않은 데이터 영역을 검색하여 Page-In, Page-Out 활동을 시작한다.

이 활동이 극대화되어 기준치보다 많은 Page Scanning 활동이 이루어지면 메모리 병목현상을 규정할 수 있으며, 만일 하나의 프로세스를 사용하는 물리적 메모리상의 페이지를 하나씩 Page-Out 시키는 활동으로 메모리 확보가 어려워지면, 그 프로세스가 사용하는 모든 페이지를 한꺼번에 Page-Out 시키는데, 이것을 Swap-Out이라고 한다. Swap-Out이 발생한 상황이라면 이것은 의심할 여지없는 메모리 병목현상이라고 볼 수 있다.

메모리 병목현상과 디스크 I/O의 상관관계
그럼 메모리 병목현상과 디스크 I/O와의 상관관계와 그 원리를 이해하여 보자.

<그림 4> System Cache Hierarchies

각 업체의 플랫폼에 따라 독특한 시스템 아키텍처를 가지고 있지만, 일반적인 시스템의 캐시 구조(cache hierarchy)는 <그림 4>와 같은 형태로 구성되어 있다. <그림 4>에서 CPU의 레지스터에서 데이터를 발견하여 처리하였을 경우를 3초로 환산하면, 물리적 메모리상에서 처리되는 상황을 7.5분으로, 메모리에서 발견되지 않아서 디스크로부터 메모리로 로드하여 처리하는 경우는 7.7개월로 환산할 수 있다(이 비례 값들은 SCSI 장치의 종류에 따라 또는 Fiber Channel을 사용하는 경우에 따라 조금씩 달라질 수 있다).

처리 단위를 유심히 보면 레지스터 메모리, L1/L2 캐시, 물리적 메모리까지는 나노 세컨드(nano second) 단위로 데이터 이동 처리가 진행되지만, 디스크 I/O로 이어지는 순간 밀리 세컨드(mili second) 단위로 바뀐다. 결국은 시스템의 메모리 분야와 I/O 분야의 튜닝은 “어떻게 하면 디스크나 네트워크로부터의 물리적인 I/O량을 줄일 것인가”에 따라 결정된다고 볼 수 있다.

가장 병목현상이 빈번하게 발생하며 성능상에 가장 큰 문제를 유발하는 요소가 바로 이 디스크 I/O 분야이다. 그래서 시스템의 데이터 캐싱 처리기법이나 애플리케이션의 데이터 액세스 방법이 시스템의 성능을 좌우하는 것이다. 예를 들어, 데이터베이스를 액세스하는 애플리케이션의 SQL 문장이 <리스트 2>와 같은 방법(Plan)으로 데이터를 쿼리한다면 어떨까? 가장 단순한 예이지만 <리스트 2>의 SQL 실행계획 및 그 결과를 비교해 보고 시스템의 입장에서 분석해 보자.

<리스트 2> 데이터 쿼리의 한 방법

SQL> select SERIAL_NO,DOCU_NO,OPEN_DATE,ASSOCIATE_NAME          from DATA_TAB1          where SERIAL_NO='200042204000019'; SERIAL_NO,    DOCU_NO,    OPEN_DATE,    ASSOCIATE_NAME -------------------------------------------------------------- 200042204000019 98107653036    2004-10-20     홍길동 Elapsed: 00:00:06.80                 ----> Estimated Time Execution Plan ---------------------------------------------------------- 0    SELECT STATEMENT Optimizer=CHOOSE 1    0     TABLE ACCESS (FULL) OF 'DATA_TAB1'    ---> 테이블 전체를 메모리로 로드함 Statistics ---------------------------------------------------------- 0 recursive calls 0 db block gets 2458 consistent gets ---> 물리적 메모리 사용량 2363 physical reads ---> 발생된 디스크 I/O량 0 redo size 584 bytes sent via SQL*Net to client 503 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 1 rows processed [ 튜닝 후 데이터 엑세스 방법의 변경 ] Elapsed: 00:00:00.14 Execution Plan ---------------------------------------------------------- 0        SELECT STATEMENT Optimizer=CHOOSE 1    0     TABLE ACCESS (BY INDEX ROWID) OF 'DATA_TAB1' 2     1     INDEX (RANGE SCAN) OF 'DATA_TAB1_IDX01' (NON-UNIQUE) ---> 필요한 인덱스 블럭과 데이터 테이블만 메모리로 로드함 Statistics ---------------------------------------------------------- 0 recursive calls 0 db block gets 5 consistent gets ---> 메모리 사용량과 디스크 I/O량을 현격하게 줄임 2 physical reads 0 redo size 584 bytes sent via SQL*Net to client 503 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 1 rows processed

첫 번째 실행계획은 적절한 인덱스가 없었기 때문에 100만 건이 들어있는 테이블의 모든 데이터를 메모리로 로드하여 단 한 건의 데이터를 추출하고 있다. 결국 이 SQL 문장이 한 번 실행되는 동안 2363개의 데이터 블록(8Kb 블럭)이 디스크 I/O를 통하여 메모리로 전달되었고(약 18.4Mb), 2458개의 메모리 블럭을 사용(19.2Mb)한 것이다.

이 SQL 문장의 튜닝(적절한 인덱스 생성) 후, 디스크 I/O량은 16Kb, 메모리 사용량은 40Kb로 획기적으로 줄어들었으며, 처리시간도 6.8초에서 0.14초로 단축되었다. 시스템은 애플리케이션의 요구를 처리하기 위하여 Free Memory를 확보하기 위한 Page Scanning, Page In, Page Out을 수행할 것이고, 데이터의 메모리 로드를 위하여 디스크 I/O 작업을 수행한다. 튜닝을 통하여 전체적인 시스템의 자원 사용량은 1000배 이상으로, 처리시간은 48.5배로 줄어든 것이다.

병목현상 전이를 고려하는가?
지금까지 네트워크 자원을 제외한 시스템 상의 CPU, 디스크 I/O, 메모리 자원의 운용과 병목현상을 트레이스하는 원리에 대하여 알아보았다. 이 외에도 성능 관리를 위하여 심도 있게 관심을 가져야 하는 분야는 ‘프로세스 자체에 대한 원리’, ‘System Locking Mechanism’, ‘파일 시스템 및 대용량 스토리지’, 네트워크’ 등의 추가적인 이해가 선행되어야 한다. 앞에서 살펴 본 자원 위주의 운용 원리 이해는 시스템 성능 관리를 위한 가장 기본이 되는 요구조건들이다.

그런데 성능 관리와 튜닝 작업을 하면서 고려하여야 할 매우 중요한 원칙이 하나 있다. 바로 성능 튜닝 과정에서 병목현상 전이(轉移)를 잘 관찰하고, 이를 고려하여 튜닝하여야 한다는 것이다. 필자는 어느 고객사의 대용량 데이터베이스 시스템을 튜닝하면서, 디스크 I/O 병목현상을 해결하기 위하여 엄청난 고생을 한 적이 있다.

운영체제(OS), 데이터베이스, 애플리케이션 등 모든 분야를 분석한 결과 애플리케이션의 데이터 액세스 방식을 개선하여 디스크 I/O 병목현상을 해결할 수 있음을 알게 되었다. 이 튜닝 방법이 적용되자마자 전체 고객사의 모든 사용자들은 자신의 클라이언트 애플리케이션이 Hang-Up 상태가 되어 전혀 실행되지 않는다고 아우성치기 시작했다.

원인은 디스크 I/O 병목현상이 지속되던 동안 CPU는 느린 I/O 속도를 타고 천천히 올라오는 데이터를 대상으로 여유 있는 작업을 하고 있었으나, 디스크 I/O 병목현상이 제거되자 엄청난 데이터들이 빠른 속도로 CPU 상의 프로세스(쓰레드)에게 제공되기 시작한 것이다. 결국 디스크 I/O 병목현상은 CPU 병목현상으로 전이되어 원래의 디스크 병목현상이 지속되던 시스템 상태보다 훨씬 심각한 장애로 나타났던 것이다.

균형적인 튜닝을 위해서 권장되는 것이 반드시 Trade-Off 작업 계획서를 기반으로 튜닝을 진행하라는 것이다. 한 가지 시스템 자원을 튜닝하여 개선할 경우 다른 자원에 어떤 영향을 미칠 것인가를 반드시 분석하여 놓고 튜닝을 실행하여야 한다.

보편적으로 Trade-Off는 성능 대 비용의 상관 관계를 분석할 때 많이 사용하지만, 성능 관리와 튜닝 과정에서도 반드시 적용되어야 한다. 결국 필자는 개선된 디스크 I/O 속도를 적절한 수준(?)으로 낮추어 튜닝함으로써 CPU Hang-Up 문제를 해결하고, 동시에 고객이 원하는 적절한 수준의 성능을 제공할 수 있었다.

성능 관리 및 튜닝 업무 영역을 보다 효과적으로 진행하기 위해서 요구되는 분야의 지식이 바로 애플리케이션에 관련된 것들이다. 실제로 시스템 관리자가 관리하고 있는 하드웨어 자원을 이용하는 것은 애플리케이션이다. 시스템에서 성능 이슈가 발생했을 때, top과 같은 명령으로 시스템을 관찰하면 전체 리소스의 대부분을 장악하고 있는 일부 프로그램(프로세스)을 쉽게 찾을 수 있다. 이 프로그램이 어떤 아키텍처를 기반으로 만들어져 있으며, 어떤 형태로 자원을 점유하고 있는 지를 찾아내는 것이 성능 튜닝의 핵심이라고 볼 수도 있다.

실제로 프로세스 실행상태를 트레이싱하는 것은 프로그래머의 협조를 얻어야 하는 경우가 많다. 그러나 시스템 레벨에서 truss 명령, adb, sdb, dbx, 디버그 등의 디버깅 툴을 이용하여 시스템 레벨에서의 문제점을 찾을 수 있다. 구체적인 디버깅 방법이나 성과는 플랫폼(또는 운영체제)별로 매우 다양하며, 각 운영체제는 이를 위한 강력한 툴들을 지원하고 있다. 시스템 관리자라면 손에 익은 디버깅 툴 하나 정도는 능숙하게 구사할 수 있어야 한다.

마흔 살, 그리고 개발자의 길
몇 해 전 미국 IBM의 선임 컨설턴트로 있는 분의 초빙을 받아 시카고에서 열린 시스템의 전반적인 분야와 데이터베이스에 대한 세미나에 참석한 적이 있다. 교육 받은 내용은 둘째 치고, 미국의 IT 풍토에서 50세 가까이 된 분이 아직도 전문 IT 엔지니어로서 컨설팅과 전산 인프라 관리를 담당하고 있는 모습이 매우 인상적이었다.

상대적으로 우리나라에서는 아직도 40세를 넘기면 세일즈(마케팅) 분야로의 전환을 고려해야만 하는 현실인 것이 너무도 아쉽고 서글펐다. 썬마이크로시스템즈의 수석 엔지니어이든 IBM의 탑건이든 나이가 들어서도 가방 들고 고객사를 관리해야 하는 시스템 관리자의 활동에 우리의 IT 환경은 고운 눈길을 보내지 않고 있다.

신기술에 대한 적응능력이나 속도가 늦다고 해서 IT 엔지니어의 길을 포기하는 사례가 일반적일 것이다. 하지만 IT 엔지니어로서의 비전을 고민하다 마흔 살이 넘어 주위를 둘러보니 같이 입사한 동료가 어느새 자신의 인사권을 좌지우지 하는 것을 보고 실의에 빠지는 현실은 기술을 중시한다는 국가적 모토와는 무엇인가 맞지 않는 것 같다.

결국 이러한 현실은 막대한 국가적인 손실이며, 오래된 엔지니어의 경험과 노하우가 허무하게 사장되는 풍토 속에서 우리의 IT 인프라가 운영되고 있는 것이다. 이제는 숙련된 프로페셔널 시스템 관리자가 인정받고 정착할 수 있는 환경이 필요하다. 이들이 IT 강국의 실질적인 반석이 되어야 할 것이다.@

* 이 기사는 ZDNet Korea의 제휴매체인 마이크로소프트웨어에 게재된 내용입니다.

 

원문 : http://www.zdnet.co.kr/techupdate/lecture/etc/0,39024989,39134231,00.htm

출처 : http://www.brandonhutchinson.com/savemail_panic_in_Sendmail.html

 

 

savemail panic in sendmail

"savemail panics" occur when sendmail is unable to deliver a bounced message to the postmaster alias. After being unable to deliver a message for 5 days (by default), sendmail will bounce email to the postmaster alias.

If this alias is not properly configured, sendmail will have a savemail panic: it will not attempt future delivery of the message, but the message remains in the mail queue directory for examination by the system administrator. sendmail renames the header of the queued message from qf* to Qf*, making it easy to identify these messages in your mail queue. These "lost" messages may also be identified with the mailq -qL command (thanks to Jonathan Kop for introducing me to this command).

To diagnose the cause of a savemail panic, first make sure you have the following entries in /etc/aliases:

# Basic system aliases -- these MUST be present
MAILER-DAEMON:    postmaster
postmaster:    root

If these entries are present, try running sendmail -bv MAILER-DAEMON and sendmail -bv postmaster. If these commands hang, rebuild the aliases database with by running newaliases or sendmail -bi.

If you still experience savemail panics, gather one or more "lost" message IDs with mailq -qL, rename the appropriate Qf* file to qf*, and execute the following command (thanks to Jonathan Kop for providing this troubleshooting step):
sendmail -v -qImessage_ID -d11

Example sendmail syslog error messages:

Oct 24 04:18:57 host sm-mta[4499]: g9N5EwE3004499: Losing q5/qfg9N5EwE3004499: savemail panic
Oct 24 04:18:57 host sm-mta[4499]: g9N5EwE3004499: SYSERR(root): savemail: cannot save rejected email anywhere

Oct 24 04:18:57 host sm-mta[4499]: g9J7o0Ds022688: to=postmaster, delay=5+01:28:57, mailer=local, pri=8490691, dsn=5.1.1, stat=User unknown
Oct 24 04:18:57 host sm-mta[4499]: g9J7o0Ds022688: g9N5EwE5004499: postmaster notify: User unknown
Oct 24 04:18:57 host sm-mta[4499]: g9N5EwE5004499: to=MAILER-DAEMON, delay=00:00:00, mailer=local, pri=9851, dsn=5.1.1, stat=User unknown
Oct 24 04:18:57 host sm-mta[4499]: g9N5EwE5004499: to=postmaster, delay=00:00:00, mailer=local, pri=9851, dsn=5.1.1, stat=User unknown
Oct 24 04:18:57 host sm-mta[4499]: g9N5EwE5004499: g9N5EwE6004499: return to sender: User unknown
Oct 24 04:18:57 host sm-mta[4499]: g9N5EwE6004499: to=MAILER-DAEMON, delay=00:00:00, mailer=local, pri=10875, dsn=5.1.1, stat=User unknown

After you have fixed the savemail panic problem, you will want to examine, move, or delete messages that have been preserved by sendmail as a result of a savemail panic.

The following commands will delete messages preserved by a savemail panic (using multiple mail queues):

for queue_dir in q1 q2 q3 q4 q5
do
   cd /var/spool/mqueue/$queue_dir
   for i in `ls Qf* | cut -c3-`
   do
      rm *$i
   done
done

The following commands will delete messages preserved by a savemail panic (using a single mail queue):

cd /var/spool/mqueue/$queue_dir
for i in `ls Qf* | cut -c3-`
do
   rm *$i
done