Workshop - 구성관리
상태바
Workshop - 구성관리
  • 승인 2006.01.20 00:00
  • 댓글 0
이 기사를 공유합니다

자산 관계 파악의 핵심, CMDB

신중한 계획·파일로트 프로젝트 필수 … 단계별 접근 필수

모든 구성 데이터를 저장한다는 것은 상식이지만, 변화를 관리하지 않는다면 시간 낭비에 불과한 일이기도 하다. 따라서 CMDB(Configuration Management DataBase)에 시간이나 돈을 투자하기 이전에, 이러한 노력과 투자가 제대로 가치를 발휘할 수 있도록 몇 가지 단계를 밟아야 할 필요가 있다.

엄밀히 말하자면 CMDB는 자산 정보의 저장소로, CI(Configuration Items)라고도 불린다. 자산 관리 데이터베이스는 자원의 재정적인 추적을 하는 반면 CMDB는 자산의 소유권과 소재, 그리고 예상 수명을 이용해 각 IT 자산의 서비스 역할(role)을 구분한다.
CMDB는 NSM(Network and System Management) 제품이 수년 간 그래왔듯이 시리얼 같은 것들과 CPU 같은 것들을 리스팅할 뿐만 아니라, IT 자산들간의 관계를 실질적으로 문서화해 준다. 이것은 NSM 업체들은 이제 막 지원하기 시작한 기능이다. 잘 만들어진 CMDB는 예를 들어 ‘서버가 메모리와 쿨링 팬 같은 하드웨어 컴포넌트들에 의존해서 작동한다. BIOS는 하드웨어에 의존하며 운영시스템은 BIOS에 의존한다’ 등과 같은 부모 관계를 문서화 해준다. 데이터베이스가 정확하면 정확할수록 서비스의 신뢰도는 높아질 것이다.
CMDB에는 단순한 물리적인 자산 이상의 것들이 포함돼 있다. 즉 여기에는 구성, 토폴로지, 애플리케이션, 그리고 IT 서비스를 뜻하는 거의 어떠한 것이든 저장이 된다. 애플리케이션, 라이선스, 설비, 환경 및 문서화 등을 분류하는 일(categorizing)은 서버와 데스크톱, 스위치 및 라우터 만큼이나 중요하다. 그리고 가장 문제가 되는 것은 이러한 모든 CI들의 관계와 의존성인데, 그 이유는 이들이 영향을 문서화하고 프로시저를 진단하기 때문이다.
이메일과 같은 서비스의 오류가 관계 오류(서버 다운이나 방화벽에서의 포트 폐쇄)의 원인일 가능성이 있다는 정보는 언제나 네트워크 엔지니어, 시스템 관리자, 애플리케이션 개발자 및 운영자들만이 가질 수 있는 특별한 지식이다. 이것은 어떤 스위치가 특정 서버를 지원하는지와 같은 레이어 2 토폴로지 지식이거나, 혹은 어떤 애플리케이션 로드밸런서와 서버가 비즈니스 트랜잭션을 추적하는지 등과 같은 트랜잭션 지식일 수 있다. 이러한 관계를 알면 선별분류 시간(triage time)을 줄일 수 있다. 하지만 이들을 문서화해주는 CMDB가 없다면 이 지식을 갖고 있는 직원이 회사 문을 나가는 순간 정보도 함께 사라진다.

파일럿 프로젝트
성공적인 CMDB를 만드는 첫 번째 단계는 ITIL(IT Infrastructure Library) 구성 관리 베스트 프랙티스를 기반으로 파일럿 프로젝트를 시작하는 것이며, 여기에는 다음과 같은 네 가지 핵심 목표가 있다.

>> 모든 IT 자산과 구성의 어카운팅
>> 모든 IT 서비스 관리를 지원하기 위한 정확한 정보 제공
>> 사건, 문제, 변화 및 릴리즈 관리를 위한 기반 제공
>> 생산에 대조해 구성 기록들 확인 및 수정

당연히 모든 IT 자산을 애초부터 등록하고 모든 것에 제어의 담요를 덮고 싶겠지만, 한 번에 이 모든 것을 다할 수는 없다. 대신 단일 IT 서비스와 여기에 연관된 자산, 그리고 구성 항목들에 초점을 맞춰라. 첫 CMDB 프로젝트 범위를 제한함으로써 보다 수월한 관리를 할 수 있을 것이다.
CMDB용으로 요구되는 속성의 수는 조직에 따라 다르며 서비스를 정의하는 데 필요한 만큼의 수만 유지하는 게 성공의 비법이다. 예를 들어 클러스터를 갖고 있다면 개별적인 서버들이 아니라 클러스터를 문서화하라. 클러스터와 대표 서버가 구성된 방식을 CI에 대한 보조 정보로 정의하는 것만으로도 충분할 것이다.
CMDB 파일럿을 시작할 때는 조직적으로 중요한 IT 서비스(폭넓은 지원을 받게 될 것)를 선택하는 것이 최고지만, 결산에 결정적인 영향을 미치는 것은 피해야 한다. 서비스는 빈번한 업데이트를 요구해서는 안되며, 독립적일수록 좋다. 빈번한 업그레이드가 필요한 애플리케이션은 관리하기가 힘들며 에러가 발생할 가능성이 높다.
이메일은 파일럿 후보자로 몇 가지 장점을 갖고 있는데, 그 중 가장 두드러지는 것은 자주 바꿀 필요가 없다는 점이다. 또한 이메일은 보통 전용 서버와 하드웨어, 소프트웨어를 갖고 있으며, 덕분에 관계를 식별하기가 테스트 상황에서 보다 간편하다. 그리고 이메일은 성숙한 애플리케이션이기 때문에 관계를 이해하고 CI 식별 및 관계 매핑에 참여할 수 있는 사람을 많이 접할 수 있을 것이다.

구성 관리의 핵심 단계
구성관리에 포함된 핵심 단계들로는 계획(planning), 식별(identification), 제어(control), 상태 어카운팅(status accounting) 및 확인(verification) 등을 꼽을 수 있다.
프로젝트 계획 단계에는 목적과 영역(scope), 목표, 정책 및 프로시저를 정의하는 작업과, 구성 관리를 위한 조직적/기술적 컨텍스트가 포함이 된다. 애플리케이션을 선택하면 영역 요건은 충족되지만, 적절한 사람 또한 포함을 시켜야 한다. 예를 들어 이메일 파일럿에는 이메일 운영자와 관리자뿐만 아니라, 클라이언트 측 입장을 위한 서비스팀 사람도 포함돼야 할 것이다. 네트워크 엔지니어와 사건 및 변화 매니저는 애플리케이션에 관계없이 프로젝트에 소속될 것이며, 품질과 서비스의 중요성을 강조하기 위해 IT와 조직 매니저들도 포함돼야 할 것이다.
식별 단계는 모든 CI에 대한 정보뿐만 아니라 CI의 상호관계와 구성 문서에 대한 정보를 보유하고 있는 사람에게서 시작돼야 한다. 여기에는 또한 CI 식별자(identifier)와 버전 배정, 각 아이템의 레이블 작업, 그리고 이를 CMDB에 입력하는 작업 등도 포함이 된다.
프로젝트의 영역에는 이메일 애플리케이션에만 있는 모든 것이 포함된다. 이메일을 전달하는 데 포함되는 모든 하드웨어와 소프트웨어, 그리고 구성의 세부 사항들을 기록해야 할 것이다. 이러한 세부 사항들로는 이메일 애플리케이션 서버와 구성, 서버의 운영 시스템 및 구성, 스위치의 링크 속도와 구성, 그리고 이 링크가 가상랜(VLAN)에 있는지 여부 등을 들 수 있다. 사용자 인증에 디렉토리 서비스가 포함돼 있다면, 이 서비스의 하드웨어, 소프트웨어 및 구성상의 특성 또한 적용을 시켜야 한다.
제어는 이 프로세스가 돌아가도록 하는 데 있어 없어서는 안 되는 단계다. 허가받고 식별 가능한 CI만이 수용 및 기록될 수 있으며, 나아가 변경 요청 승인과 업데이트된 사양 같은 적절한 제어 문서가 없이는 어떠한 CI도 추가, 변경, 교체, 혹은 삭제되지 못한다. 예를 들어 이메일 서버에 접속한 스위치 업체가 업그레이드가 필요하다는 보안 경고를 보내면, 이러한 변경을 하기 이전에 여기에 대한 이유와 이것을 허가한 사람 등과 같은 변화를 모두 문서화해야 한다.
이로 인해 각 CI의 현재 및 과거 데이터를 보고하는 상태 어카운팅 단계로 넘어가게 된다. 이 단계의 목표는 어느 CI든 그 수명이 다하는 동안 변화를 추적한다는 것으로, 이것이 개발 중이든, 테스트 중이든, 살아 있든, 혹은 묻혀 있든 상관이 없다. 일단 이메일 스위치에 생긴 변화가 CDMB에 기록이 되면, 서비스 데스크와 같은 다른 애플리케이션이 데이터베이스로 질의를 해서 이 변화가 허가되고 완료됐는지를 확인할 수 있다.
데이터가 기록된 다음에는 확인 단계로 들어간다. 여기서는 CI의 물리적인 존재를 확인하고, 이들이 구성 관리 시스템에 정확히 기록되었는지를 확인하는 일련의 리뷰 및 감사 작업이 이뤄진다.
구성 관리 프로세스가 준비되면 CMDB는 IT 서비스를 전달하는 데 있어 유용한 툴이 될 것이다. 일단 파일럿을 실행시키고 난 후에는 e-커머스나 공급망 애플리케이션과 같이 보다 크고 중요한 IT 서비스를 공략할 수 있다. 프로세스를 정하기 전에 구성 관리 툴부터 서둘러 구입하는 오류는 범하지 말기 바란다.


댓글삭제
삭제한 댓글은 다시 복구할 수 없습니다.
그래도 삭제하시겠습니까?
댓글 0
댓글쓰기
계정을 선택하시면 로그인·계정인증을 통해
댓글을 남기실 수 있습니다.