|
|
|
|
CMDB(Configuration Management DataBase) |
| “IT 인프라에 진정한 단일 소스를 제공하라” |
 |
2007년 05월 29일 00:00:00 |
데이터넷
|
 |
|
|
‘통합 뷰·애플리케이션 의존성 매핑’ 제공 …
‘연합과 조화’가 최대 관건
CMDB(Configuration Management DataBase), 즉 구성 관리 데이터베이스는 차세대 자동화 및 애널리틱스(analytics)를 갖출 수 있도록 IT를 변모시켜 준다는 약속을 내걸고 있다. 하지만 복잡한 전용 설계로 인해 실제로는 금이 아닌 금빛 돌을 얻게 될 수도 있다. 미래의 유연성을 저당 잡힐 필요 없이 CMDB의 금광을 캐내는 방법을 알아보자.
21세기의 골드러시가 기업을 온통 휩쓸어버릴 태세다. 업체들의 약속의 말은, CMDB가 IT 인프라에 있어 진정한 단일 소스를 제공하리라는 것이다. 더 이상 무분별하게 구분된 기능들로 기간 비즈니스 서비스 고장을 야기하는 복잡성에 우리의 눈이 멀게 되지 않을 것이다. 대신 CMDB는 네트워크 자산과 그 구성에 대한 통합 뷰를 제공하며, 장비와 애플리케이션 의존성을 매핑하고, 우리가 기계가 아니라 서비스를 관리할 수 있게 해준다. 그리고 이 모든 것은 틀림없이 생산성 향상, 다운타임 감소, 반복되는 작업의 자동화, 그리고 네트워크와 시스템 관리의 용감한 신세대를 위한 플랫폼을 가져다 준다.
기계가 아니라 서비스 관리
문제는 골드러시가 탐욕스러운 이들에 의해 주도되고 있다는 사실이다. 고객이 가장 관심을 두는 것을 명심하고 있다고 주장하는 많은 업체들이 ‘통합된(integrated)’ CMDB 플랫폼을 이용해 우리를 인질로 잡고 자신들의 배를 채울 것이다. 물론 소프트웨어 회사들은 돈을 벌기 위해 비즈니스를 하고, 록인(lock-in)은 반복되는 매출을 만들어 낼 수 있는, 시간이 증명해 준 수단이다. 물론 그렇다고 해서 우리가 그것을 좋아해야 할 이유는 없다.
나아가 대부분의 전도사들은 어떠한 IT 조직이든 CMDB를 중심으로 캠프를 설치하는 어떤 IT 조직이든 많은 난관에 봉착하게 된다는 사실은 얼렁뚱땅 넘어가고 있다. 가장 심각한 문제는 이종의 IT 데이터 리포지토리를 연합시키고(federating), 호환되지 않는 스키마에 저장된 정보를 조화시키는(reconciling) 일이다. 물론 업체들은 언제나처럼 해결책을 갖고 있다. 더 많은 소프트웨어를 사라는 것이다. 이 경우에는 CMDB를 중심으로 해서 구성된 관리 스위트가 될 것이다.
사실 업체들이 CMDB에 접근하는 구조적 방식에는 두 가지가 있다. 어떤 업체는 스탠드얼론 제품을 제공하는데, 이것은 IT가 자산 관리 시스템 같은 다른 애플리케이션을 구입할 필요 없이 CMDB를 배치할 수 있게 해준다. 하지만 스탠드얼론과 독립성을 혼돈해서는 안 된다. 스탠드얼론 CMDB는 써드파티 시스템보다는 자기 패밀리 업체의 제품과 더 성공적으로 연합할 것이다.
이와 달리 어떤 업체들은 서비스 데스크 애플리케이션과 같은, 하나 이상의 관리 스위트 컴포넌트에 CMDB를 임베딩한다. 스위트로 다중 애플리케이션을 사용하는 기업들은 통합이 대폭 단순화된 것을 알 수 있겠지만, 써드파티 데이터 저장소들을 연합시키느라 여전히 애를 먹을 것이다. 그리고 이 두 범주에서 모두 활동하는 업체들도 몇몇 있다.
배짱 두둑한 IT 조직에서는 이기종 툴 세트를 간수하는 데 어떤 기여를 했을까? 지금까지의 정황을 보면, 이들은 전체 주주들을 불러모으지 않고 상호운용성이라는 개념에 대해 립 서비스만 하는 의심스러운 표준 전 CMDB 워크그룹에 믿음을 주고 있는 게 분명하다.
임무는 바로 ‘제어’
IT 관리 업체들이 제품 스위트를 CMDB 중심으로 설계하는 이유는 한 가지, 즉 제어 때문이다. 이들은 CMDB가 관리 소프트웨어 구매에 영향을 미치는 핵심 요소라는 사실을 잘 알고 있다. CA 비즈니스 서비스 최적화(Business Service Optimization) 부문의 제품관리 이사인 알렌 베일레리언(Arlen Beylerian)은 “CMDB를 소유하고 있다면 관리 인프라를 소유하게 될 것”이라고 말했다.
그렇다면 CMDB에게 이러한 힘을 실어주는 것은 무엇일까? 구성 관리, 즉 자산과 이들의 관계에 대한 명확한 그림을 확보하는 것은 IT의 기반이다. 이것은 변화 관리나 근본 원인 분석과 같은 필수 작업들 뿐만 아니라, 데이터 센터 자동화와 같은 것들의 버팀목이 된다.
CMDB를 사용함으로써 IT는 기존의 서버 구성과, 그 위에서 어떤 애플리케이션이 돌아가는지, 어떤 비즈니스 서비스가 이것을 지원하는지, 그리고 어떤 사용자나 그룹이 이 서비스를 소모하는지 등을 파악할 수 있다. 그리고 이런 모든 정보는 IT에서 헬프데스크, 변화 관리 및 내부 SLA 모니터링 등을 처리하는 데 사용할 수 있다.
도급업체 방어를 위한 전자기기 공급업체인 EFW는 최근 CMDB를 배치해 하드웨어 및 소프트웨어 자산에 서비스를 연합시키는 데 사용하고 있다.
텍사스 주 포트 워쓰에서 EFW의 솔루션 센터 매니저로 일하고 있는 해리 버틀러는 “이메일 서버는 단순한 익스체인지 서버보다 훨씬 더 큰 의미가 있다”고 말했다. 그는 익스체인지 서버는 보다 큰 통신 서버 웹에 연결되며, 어떠한 자산으로의 어떠한 변화든 영향을 미치게 된다.
버틀러는 “마이크로소프트 패치를 푸싱할 필요가 있는 사람은 자신의 범위에 미치고 접촉하는 모든 것을 볼 수가 있다”며, “익스체인지 서버를 중단하면, 블랙베리 엔터프라이즈 서버(BlackBerry Enterprise Server)는 말을 건낼 곳이 없다”고 말했다. CMDB를 이용해 변화를 모델링함으로서 버틀러는 모든 임원의 블랙베리를 실수로 중단시키는 일을 피할 수 있으며, 물론 이는 버틀러의 경력에 도움이 되고 있다.
이러한 종류의 명확한 그림을 제공할 수 있는 능력은 CMDB라는 말에서 짐작하듯 단 하나의 데이터베이스로 인한 것이 아니라 탐색 툴, 자산 관리 제품, 헬프데스크 애플리케이션, 엑셀 파일 등에서 나오는 정보의 집합에서 비롯되는 것이다. 이 기사를 위해 실시한 설문조사에서, 구성 정보의 소스는 자산 및 구성 관리 시스템에서부터 비지오(Visio)와 관리 다이어그램까지, 다양했다.
잘 설계된 CMDB는 연합 모델을 통해 많은 데이터 리포지토리에 있는 정보에 액세스할 수 있으며, 이 모델에서 CMDB는 자산, 즉 서버의 이름과 이것이 연관된 애플리케이션과 서비스에 대해 한정된 정보를 저장한다. 보다 상세한 정보는 자산 관리 애플리케이션이나 탐색 툴 같은 다른 데이터 저장소에 있을 것이다. 수행하고자 하는 작업이나 프로세스에 따라, CMDB는 다른 CMDB 등 적합한 데이터 저장소로 손을 뻗침으로써, 자산에 대한 추가 정보를 가져온다.
CMDB는 또한 이종의 데이터 저장소로부터 수집된 정보를 조화(reconciliation)시킬 수 있을 것이다. 조화에는 두 가지 기능이 있다. 우선 CMDB는 다중 데이터 소스로부터 끌어오기 때문에 하나 이상의 탐색 툴이 같은 자산에 대한 정보를 수집한다. 조화는 IT에서 어떤 툴의 정보가 CMDB에 의해 사용될 것인지를 판단할 수 있게 해준다.
예를 들어 패치 관리 대행자가 특정 서버에 대한 OS 상태에 대해 가장 좋은 정보를 제공해주는 반면, 같은 서버에 설치된 장비 드라이버에 대해서는 헬프데스크 툴이 제공하는 정보가 가장 상세하다는 사실을 파악할 수 있다. 패치 관리 에이전트가 또한 장비 드라이버 정보도 제공한다면 CMDB는 이것을 무시하고 헬프데스크 툴을 선택할 것이다.
둘째, 조화는 써드파티 툴에 의해 사용되는, 자산과 속성을 설명하는 서로 다른 스키마들을 조화시킨다. 예를 들어 패치 관리 대행자는 이름에 따라 서버를 설명하는 한편, 헬프데스크 대행자는 MAC 어드레스를 사용한다. 조화는 서로 다른 툴들이 같은 자산을 이야기할 때를 CMDB가 파악할 수 있게 보장해 준다.
복잡성 덜기 위해
글로는 연합과 조화를 간단히 설명할 수 있다. 하지만 실제로 이들은 실행하기가 극도로 복잡하며, 맞춤 통합, SDK, 업체들의 API 퍼블리싱, 혹은 일종의 웹 서비스가 포함되는 경우가 많다. CMDB에는 써드파티 데이터를 통합할 수 있는 조화 엔진이 포함돼 있지만, 이것을 사용하려면 먼저 IT에서 자산과 그 속성용으로 잘 정의된 네이밍 스키마를 만들기 위해 역시 막대한 노력을 해야만 한다.
업체들은 우리가 하나의 관리 스위트만 사면 이러한 복잡성을 일부 덜 수 있다고 호언하고 있다. BMC는 자사의 아트리움(Atrium) CMDB와 다른 제품들간의 긴밀한 통합을 주장하고 있다. 예를 들어 버튼을 한번만 클릭하면 레미디(Remedy)나 BMC 컨피규레이션 매니저(Configuration Manager) 포트폴리오로부터 관련 정보가 불려 나오며, 이것이 CMDB 사용자 인터페이스로 전달된다는 것이다.
알티리스(Altiris), CA 및 옵스웨어(Opsware) 제품도 유사한 기능을 갖고 있다. CA의 CMDB CI(configuration item) 뷰어(viewer)는 유니센터 서비스 데스크(Unicenter Service Desk) 안에서 하나의 탭으로 나타난다. 유니센터 네트워크(Unicenter Network)나 시스템 매니지먼트(Systems Management) 등과 같은 다른 CA 제품과 연합을 한다. 이외에 보다 폭넓은 관리 스위트의 주요 항목으로 CMDB를 통합시키고 있는 업체들도 있다.
조화의 측면에서 보자면 BMC는 간편한 통합을 위해 자사 제품에서 DMTF CIM(Common Information Model) 표준을 따르고 있다. 모든 CA 관리 제품들은 매니지먼트 데이터베이스(Management Database)라는 표준 리포지토리를 이용하는데, 이것은 CA 제품군 내에서의 조화 작업을 단순화해준다. 써드 파티 제품용으로 CA는 XML을 통해 데이터를 임포팅하여, 이것을 CA CMDB 스키마로 번역할 수 있는 UFA(Universal Federation Adapter)를 추천하고 있다.
EMC는 BMC, HP, IBM 티볼리 및 매니지드오브젝츠(Managed Objects) 등 써드파티 업체 제품들로부터 나오는 정보를 연합 및 조화시키기 위해 미리 만들어진 어댑터를 제공한다. 하지만 CA와 마찬가지로 EMC는 어댑터를 설치 및 가동시키기 위해서는 자사의 전문가 서비스 팀이 필요하다고 말했다. HP는 페러그린(Peregrine)에서 인수한 커넥트IT(ConnectIT)라는 조화 및 연합 기술을 이용하고 있는데, 이 기술은 하나의 데이터 소스로부터 다른 것으로 필드를 매핑해준다.
BMC 아트리움 솔루션 마케팅 선임 매니저인 브라이언 에머슨은 “일단 CMDB에 투자를 하면 미리 통합돼 있는 모든 애플리케이션이 경쟁력을 갖게 된다”고 말했다. “같은 고객에게 새로운 애플리케이션이든, 다른 애플리케이션이든, 더 쉽게 판매할 수 있다.”
이상하게도 사람들은 그다지 걱정이 없어 보인다. 설문조사에 따르면 복잡성이 가장 염려된다고 답한 응답자가 40%에 달하는 데 비해, CMDB를 이행할 때 가장 중요한 것은 다양한 업체 툴들로부터 연합을 할 수 있는 능력이라고 답한 사람은 11%에 불과했다.
EFW의 버틀러는 CA의 CMDB와 여기에 연합하는 몇 가지 비 CA 툴을 갖고 있다. 하지만 그는 CMDB 때문에 다른 CA 제품을 구입했다. 그는 “몇 가지 비 CA 툴을 구입한 후 이것을 CA로 바꿨는데, 그 이유는 이것이 훨씬 이음새가 없기 때문”이라며, “데이터의 연합이 가장 절실하다”고 말했다.
소프트웨어 개발업체인 I2의 존 프래지어도 같은 생각이다. 그는 현재 알티리스의 CMDB를 사용하고 있다. 그는 또한 알티리스 CMDB와 써드파티 제품을 연합시키고 있지만, 알타리스가 향후 구매에 더 큰 영향을 미친다고 말했다. “알티리스 제품을 더 구입하고 싶은 것은 인정할 수밖에 없는 사실이다. 올해 봄에도 우리는 알티리스의 서비스 데스크를 구입했다.”
표준이냐 립 서비스냐?
다양성을 존중하는 조직들은 당분간은 개방형 표준에서 챔피언을 찾지 못할 것이다. 이종의 자원들로부터 나오는 정보를 연합하기 위한 초안 사양 제작에 참여하는 업체가 소수에 불과하기 때문이다. 이 프로젝트는 2006년 4월 출범한 CMDB 피더레이션 워크그룹에서 주도하고 있으며, 사양은 완성이 되면 표준 기구로 제출될 예정이다.
이 워크그룹은 세 가지 큰 문제에 초점을 맞추고 있다. 첫째는 데이터 저장소에서 관리하고 있는 자원을 이들이 등록할 수는 방법을 제공한다는 것이다. 둘째는 소위 아이덴티파이어 서비스(identifier service)라는 시스템 개발인데, 이 시스템은 같은 자원이 인식되는 서로 다른 방식을 파악할 수 있을 것이다. 예를 들어 서버가 하나의 리포지토리에서는 MAC 어드레스별로, 다른 곳에서는 이름이나 위치별로 등록돼 있다는 사실을 안다는 얘기다. 셋째, 이 그룹은 다양한 데이터 저장소들로부터 정보를 질의하기 위한 상호교환 포맷을 검토 중이다.
완전히 다시 만드는 일을 피하기 위해서 이 그룹은 가능한 곳에서는 기존의 작업을 통합시키려 할 것이라고 마크 존슨은 말했다. 그는 현재 이 워크그룹 멤버이자 IBM에서 선임 프로그래머로 일하고 있다. 예를 들어 CIM은 공통 객체로서 IT 구성요소를 지정하기 위한 스키마를 제공한다.
존슨은 “CIM은 지금까지 돼 있는 것들에 영향을 미치리라 확신한다”며, “데이터 모델링 부분에 대해, 자원과 연관된 모든 속성들이 무엇인지를 생각한다면 거기서 많은 부분에 손을 댈 필요가 없다”고 말했다.
존슨은 이 그룹이 웹 서비스를 이용해 관리 시스템으로 접속하는 통합 레이어를 설명하는 오아시스(OASIS) 표준인 WSDM(Web Services Distributed Management) 같은 다른 사양을 조사하고 있다고 말했다. 그 자체가 복잡한 IT 서비스 및 시스템을 모델링하기 위한 초안 사양인 SML(Service Modeling System) 또한 포함시킬 물망에 올라 있다. BMC, HP, IBM 및 마이크로소프트가 CMDB와 SMM 워크그룹의 멤버임을 감안할 때, 동화(assimilation)의 가능성이 높아 보인다.
이러한 모든 재활용은 듣기에는 좋아 보이지만 컨소시엄이 배타적 집단이기 때문에 문제가 되기도 한다. 멤버십은 원래의 설립 업체들, 즉 BMC, 후지쯔, HP 및 IBM에서 CA와 마이크로소프트까지 이제 넓혀졌다. 하지만 EMC나 매니지드 오브젝츠 같은 다른 업체들은 참여가 저지되고 있다.
존슨은 “회원 수를 무제한으로 둘 수는 없다”며, “어느 정도까지 다른 업체를 참여시키자는 논의가 진행되고 있다”고 밝혔다. 이기종 환경에서 상호운용성을 진작시키기 위해 만들고 있다는 표준 사양에 대한 태도로는 그리 믿음직해 보이지가 않는다. 게다가 사양이 언제 등장할지조차도 확실치가 못하다. 원래 목표는 2006년 12월이었으나 올해 중 언젠가로 발표 날짜는 연기됐다.
한동안 연합 워크그룹은 주요 업체들이 상호운용성 표준에 대한 개념을 두고 간단한 인 스위트(in-suite) 통합에 대한 약속으로 고객을 사로잡기 위한 립 서비스를 할 수 있게 해줄 것이다(표준 기반 제품이 시장에 나올 때까지 최소한 2~3년간은).
존슨은 표준 부재가 기업의 CMDB 배치를 막지는 못할 것이라고 말했다. 그 한 가지 이유는 이들은 초보적인 데이터로 파퓰레이팅된 CMDB과 IT 자산의 일부로 우선 작게 시작하는 경향이 있기 때문이다. “이들은 시간이 흐르면서 제품과 프로세스가 성숙해짐에 따라 이것을 확장시켜 나갈 것”이라고 존슨은 설명했다.
전체적으로 볼 때 CMDB 시장은 아직 유년기지만 건강하게 성장할 것으로 전망되고 있다. 포레스터 리서치는 이 기술의 설치 기반 수가 현재 약 600개에서 5년 내에 4천 개 이상으로 늘어난다고 추산했다.
하지만 표준이 등장하기까지, IT는 이종의 데이터 저장소를 연결시키기 위한 얼마간의 노력을 해야 할 것이다. 두 업체가 파트너 관계를 맺고 있거나, 한 업체가 통합 전문이라면, API나 다른 커넥터를 이용해 CMDB와 데이터 저장소를 아웃 오브 더 박스(out of the box)로 연결할 수 있을 것이다. 하지만 대부분의 경우 연합이 작동되게 하려면 한 업체, 혹은 두 곳 모두의 전문가 서비스 팀이나 컨설턴트를 이용해야 한다.
그리고 일단 링크가 수립이 되면 둘 중 한 제품이 업그레이드될 때 신중히 처리해야 하는데, 그 이유는 이런 변화로 인해 통합이 오해될 수 있기 대문이다. 이러한 문제는 분명 시간이 지날수록 운영비를 늘리게 될 것이다.
인수의 물결
고객의 IT 관리 구매를 좌우할 수 있는 잠재력으로 볼 때, IT 업체들이 CMDB 배너를 두고 경쟁을 벌이리라는 것은 불을 보듯 뻐한 일이다. 지난 해에는 업체들의 CMDB 제품을 강화하기 위해, 혹은 이들을 시장에 내놓기 위해 이뤄진 수많은 인수 사례들이 있었다. HP는 머큐리(Mercury)를, CA는 센듀리(Cendury)를, 시만텍은 렐리코어(Relicore)를 인수했으며, EMC는 엔레이어즈(nLayers)를 자사 목록에 추가시켰다. 그리고 2005년 말에 IBM은 콜레이션(Collation)이라는 회사를 접수했다. 이러한 인수들에서의 공통분모는 애플리케이션 의존성 매핑(application-dependency mapping)이다.
애플리케이션 의존성 매핑은 CMDB를 위한 핵심 기술이다. 이것은 서버, 라우터 및 스위치 등 애플리케이션을 지원하는 장비의 시각적 맵을 파악하고 만들어 준다. 애플리케이션 의존성 매핑은 또한 소프트웨어 컴포넌트와 애플리케이션이 의존하는 코드 의존성뿐만 아니라, 애플리케이션이 기업망에서 이동할 수 있게 해주는 네트워크 구성(라우팅 테이블이나 포트 할당 등)을 조사한다.
애플리케이션을 지원하는 기반 장비들사이의 접속과 이들의 구성은 가동시간에 큰 영향을 미친다. 하지만 오늘날 네트워크의 복잡성을 감안할 때 IT가 애플리케이션 인프라간의 의존성에 대한 명확한 그림을 얻기는 쉬운 일이 아니다. CMDB는 맵을 제공함으로써, IT에서 잠재적인 변화의 영향을 보다 잘 파악하고 애플리케이션 오류를 진단할 수 있게 도와준다.
한편 BMC, 매니지드오브젝츠 및 옵스웨어 등과 같은 업체들은 자체의 애플리케이션 의존성 기술을 만들었다. 알티리스는 올 하반기에 이 기술을 내놓을 계획이며, 타이드웨이(Tideway)는 스탠드얼론 애플리케이션 의존성 매핑 회사들 가운데 가장 마지막 주자다. |
|
|
|
|
|
|
|
|
|
| ⓒ 데이터넷(http://t564.ndsoftnews.com) 무단전재 및 재배포금지 | 저작권문의 |
|
|
|
|
|
|
| |
| 가장 많이 본 기사 |
|
|
 |
|
KT, ‘28GHz 기업전용 5G 네트워크’ 개발 성공
