ILM 구현 위한 동반자, 관리SW
제품 개선 요구 교환 필요 … 우수 SW 창조자는 고객

정보의 급증과 복잡성을 더해가는 기업환경으로 인해 효율적 스토리지 자원관리는 점차 중요도를 더해가고 있다. 스토리지 관리란 무엇인가를 알아본 지난 호에 이어 이번호에서는 실제 현장에서의 스토리지 인프라 관리에 대해 알아본다. <편집자>

연제순서
1. 스토리지 관리의 개념 및 전략적 접근
2. 스토리지 관리의 실제, 그리고 현실적 완성
(이번호)

형성욱
한국EMC 차장
hyung_sungwook@emc.com

1부에서 우리는 정보의 효율적인 관리가 곧 성공적인 비즈니스로 이어지고 있는 현실에서 이를 유지하고 관리하는 스토리지 인프라 관리의 중요성이 더욱 높아지고 있음에 공감했다. 규모의 변화뿐만 아니라 그 복잡성도 증가하는 스토리지 인프라를 부족한 예산으로 관리하기 위해서는 각 기업이 처한 환경을 단계별로 수용할 수 있는 스토리지 관리 소프트웨어와 서비스를 고려해야 함을 그 전략으로 제시한 바 있다.
스토리지 인프라를 살아 움직이는 역동적인 대상으로 인식해야 하는 점과 구체적 관리 도구인 소프트웨어는 이를 수용할 수 있는 프레임워크로 이해하고 구현해야 하는 점 또한 제시했다. 2부에서는 스토리지 인프라 관리의 현실을 솔직하게 되짚어 보고 1부에서 논의된 전략적인 부분을 구체화 시켜가는 관리 소프트웨어 프레임워크의 활용을 통한 스토리지 관리 사례를 알아본다.

스토리지 인프라 관리의 끝없는 시작
스토리지 인프라뿐만 아니라 대부분의 IT 관리 시스템은 전통적으로 인력에 크게 의존하고 있는 것이 현실이다. 그렇다 보니 꼭 이러한 인력에 의한 운영이 몇 가지 단점을 제외하고는 크게 문제점이 없는 것으로 위로를 삼아왔다. 그런데 머피의 법칙처럼 피하고 싶은 불길한 상황은 꼭 발생한다. 이때서야 관리 표준화·자동화를 떠올리게 되고, 어떻게 해서든 운영 관리에 수반되는 수작업에 대한 의존을 줄이는 컴퓨팅 파워를 이용한 컴퓨터 관리를 시도하게 된다.
어느 범위까지를 관리할 것인가, 대상을 정하고 어느 정도까지를 관리할 것인지 범위에 대해 다행히 조직원의 공감을 이끌어내고 이를 구현할 각종 소프트웨어를 찾아 나서며, 그 중 하나 또는 둘을 선택하거나 아예 새로운 관리 소프트웨어 시스템을 개발하기로 하는 등 야심찬 출발을 다시 감행한다.
하지만, 관리 자동화 프로젝트가 끝나고 나서도 그 결과는 만족스럽지 않다. 이만하면 되지 않을까 싶지만, 이를 이후로도 계속 사용하는 운영자와 관리자들은 또 다른 아쉬움을 느끼고 또 다시 부족함을 경험케 된다. 그래도 이렇게 구현된 시스템을 계속 사용해가는 경우는 비교적 다행스러운 경우다. 더욱 안타까운 경우는 구현된 시스템이 관리자가 바뀌는 등 조직적인 구조가 변경돼 새로운 조직에 맞지 않는다는 이유로, 또는 새로운 기술이 도입돼야 한다는 이유로 기억 속에서 잊히게 되는 것이다.
그 다음은? 다시 프로세스 혁신 활동이나 신규 투자 사업이 일어나고 여기에 또다시 컴퓨터에 의한 컴퓨터의 관리를 시도하는 악순환의 고리가 이어진다. 이는 지나친 비약만은 아닌 우리의 현실이다. 끝없는 인프라 관리 시도. 그러나 결과는 만족스럽지 않다.
스토리지 인프라를 ‘성장하고 살아있는 대상’으로 정의하고 이를 관리하는 방법 또한 변화를 적극적으로 수용하도록 프로세스화 하는 것이 필요하다는 인식의 공유가 악순환의 고리를 선순환의 고리로 연결시키는 계기를 가져다 줄 수 있다. 인프라가 변화하면 그에 따라 프로세스를 부분적으로 발전시켜 가는 것이 지난 시간 동안 쌓은 관리 노하우를 프레임워크 상에 유지하면서 발전시켜가는 길이다.

관리 인프라는 ILM의 일부
ILM(Information Lifecycle Management)을 이야기할 때 가장 중요한 개념은 ‘유지되고 있는 모든 정보가 동일한 가치를 지닌 것은 아니므로 이를 분류(Classification)하고 분류된 정보들의 가치에 맞게 최소의 비용을 투자함으로써 최대한의 가치를 살려내어 비즈니스에 반영되도록 하는 것’이다.
그런데 가치를 판단해 분류하는 것이나 이러한 기준에 비즈니스 정책을 적용하는 것이 어느 한 시점의 결정으로 완성되지는 않는다. 비즈니스 요구 사항이 달라질 때마다 재분류 및 적용이 필요한 것처럼 스토리지 인프라의 관리 역시 한 번의 기준이나 정책으로 지속적인 효과를 기대하기는 어렵기 때문이다.
변화하는 비즈니스 요구사항은 프로세스의 변화를 요구하고 이는 곧 변화된 프로세스를 구현하는 기술요소인 관리 소프트웨어의 변화도 요구한다. 이러한 요구에 능동적으로 대처하지 않고 과거의 기준이나 사상에 묶여있는 시스템 또는 소프트웨어의 도태는 당연한 것이다. 수많은 소프트웨어 벤더들이 개방화(Open)를 표방하고 표준화를 추구하는 이유도 되도록이면 이러한 변화가 가져오는 영향을 최소화하려는 노력이라 하겠다.
그러나 불행히도 표준 자체가 발전하고 있지만, 구현되는 속도는 현실과 차이가 있다. SMI-S(Storage Management Initiative-Specification) 표준을 생각해보면, 스토리지 인프라 관리의 표준으로서의 역할이 충분하다 말할 수 없는 것이 현실이다. 관리 대상과 범위가 벤더에 의해 일방적으로 구현돼 사용자의 환경을 모두 만족할 수 없기 때문에 그 효용성이 반감되고 있는 것이다.
소프트웨어의 발전적 변화가 계속 요구되고 있지만, 구현이 현 시점에서 한 번에 이뤄지기 어렵다면 그 대안은 무엇인가? ILM 사상으로 돌아가 해답을 찾으면 ‘단계적 ILM의 접근은 결국 전체 인프라의 ILM을 완성한다’는 명제에 다다른다. 즉, 단계적 스토리지 관리 접근이 통합관리를 이뤄내게 된다는 것이다.
여기서 중요한 것은 ‘단계적 접근’이 ‘개별적 접근’이어서는 안 된다는 점이다. 공통된 프레임워크에서 공통 자원(Resource)을 활용하고 단일 관리정보 저장소(Repository)를 사용함으로써 변화되는 대상(Object)에 따라, 변화되는 범위(Scope)에 따라, 또한 변화되는 정책(Policy)에 따라 유연하게 상호연관성을 유지하면서 상호 영향 여부를 확인할 수 있어야 한다.
이렇듯 조직의 변화와 기술적 변화 요소들을 적극적으로 수용하면서도 단계적으로 기업의 성숙도 모델(EMM)에 따른 요구 기능들을 하나하나 구현하면서도 전체적인 관리 사상을 잃지 않고 비즈니스 영향까지도 파악할 수 있도록 하는 시스템, 즉 올바른 스토리지 인프라 관리 프레임워크를 구축하는 것이 최선의 대안이 될 수 있다.

조직과 함께 발전하는 프레임워크
뼈대를 구성하는 구조물로 정의되는 프레임워크 개념은 필수요소인 안정성을 온전하게 유지하면서 운영요소인 각종 기능이 원활하게 운영되도록 하는 제반 환경을 제공한다. 필수요소는 수집된 정보들이 상호 유기적인 관계를 파악하고 정책의 적용이 일관성 있게 유지되도록 하면서 그 자체로써 유연한 확장성과 안정성을 확보해야 한다. 운영요소 기능은 각 조직이나 기업의 성숙도에 따라 그리고 비즈니스의 변화에 따라 요구되는 상이한 기능들을 의미하며, 이들은 각 기능별로 분화돼 모듈화될 수 있어야 한다.
필수요소적 관점에서 단일 관리정보 저장소를 데이터베이스로 구현하고, 클러스터 지원 및 사용자 규모에 따른 유연한 확장성을 유지하면서 필요에 따라 다양한 벤더의 SMS, NMS 프레임워크 또는 사용자 개발 프레임워크와 연동돼야 한다. 운영요소인 기능들은 각 조직이나 기업에서 요구되는 계획과 할당, 모니터링과 리포팅, 디바이스 구성관리를 카테고리로 하는 모듈화된 라이선스로 세분화된 기능을 다양한 레벨로 구현하면서 단일 사용자 인터페이스를 유지해야 한다. 운영기능이 모듈화돼 있어서 필요시 동일 프레임워크에서 라이선스를 입력하는 것만으로 즉시 기능이 동작하게 해 빠르게 변화하는 비즈니스 요구사항을 신속하게 반영토록 해야 한다.
이를 통해 각 조직이나 기업이 성장 단계에 따라 요구되는 운영 요소기능을 시기에 맞춰 단계적으로 구현함과 동시에 그 필수요소에 의한 정책의 일관성이나 확장의 유연성, 안정성의 강점을 지속적으로 발전시킬 수 있기 때문이다.
운영 요소를 적시에 추가하는 실례로 조직의 업무를 반영하여 관리 행위를 표준화할 수 있는 워크플로우(Workflow)기능을 구현하거나, 장애상황을 예방 및 조치하는 원인분석(Root Cause Analysis)이나 비즈니스 영향도 파악(Business Effect Analysis) 기능 등을 구현하는 비즈니스 프로세스와 접목된 소프트웨어의 발전이 이러한 예가 될 것이다.

스토리지 관리의 실제
스토리지 관리 목적은 용량, 성능, 장애, 구성 등으로 구분해 볼 수 있다. 여기서는 실제 스토리지 관리 중 직접적인 구성 변경이 어떻게 이뤄지는지 크게 두 가지 사례를 들어 살펴보고자 한다. 그 하나는 SAN의 변경 구성관리이고 다른 하나는 스토리지 할당관리다.
인프라는 SAN의 규모가 커질수록 복잡성도 가중된다. 스위치나 디렉터가 하나만 있는 경우라면 모르지만, 5개, 10개에 이르면 상황이 달라진다. 현재 이용할 수 있는 벤더별 관리 툴은 자사의 스위치 구성과 특정 벤더의 스토리지 제품만 지원하는 제약이 있기에 조닝(Zoning), LUN 마스킹과 같은 기본적 기능을 구현하기에도 여러 가지 툴과 CLI(Com-mand Line Interface)를 통한 작업이 필요하게 된다. 결과적으로 SAN 환경은 점점 더 운영자의 실수가 많이 발생할 수밖에 없는 상황으로 가고 있다.
다양한 벤더의 스토리지 시스템과 SAN 스위치로 이뤄진 복잡한 SAN 환경은 멀티벤더 SAN 인프라를 단일 인터페이스를 사용해서 분석, 모니터링, 관리하는 중앙집중식 관리 방식을 도입하면 한결 관리가 용이해진다. 이러한 중앙집중식 SAN 관리는 기존에 사용하던 자원(Resource)과 동일하거나, 또는 더 적은 수의 자원으로 보다 많은 스토리지를 관리할 수 있어 스토리지 관리를 표준화, 간소화하고 안정성을 확보하면서 비용을 절감할 수 있는 이점이 있다.

사례 1: SAN 변경관리
많은 IT 조직이 SAN 운영 시스템을 변경하는 적절한 절차 및 방법을 갖추지 못해 회사에 불필요한 운영 중단을 가져오는 문제를 안고 있다. 정확한 정보를 적시에 확보하지 못하면 SAN 환경에서는 구성 오류 또는 하드웨어나 소프트웨어 호환성 문제 등으로 인해 장시간 운영 중단이 불가피한 상황이 발생한다. 가트너 그룹에 따르면, 운영자 오류로 발생하는 시스템 운영 중단률은 약 40%에 달한다.
예를 들어, 일부 HBA(호스트 버스 어댑터) 그룹에 대한 펌웨어 업데이트가 SAN 스위치와 호환되지 않는 것으로 판명될 수 있다. 다양한 하드웨어 및 소프트웨어 업체 제품들의 상호 운용성에 관한 최신 정보를 갖고 있지 않다면 IT 부서는 이러한 사태를 결코 미연에 방지할 수 없다.
또 다른 예로, 어느 IT 관리자가 기존 SAN 설계에 실수로 잘못된 포트 할당 명령을 입력한 경우, IT 부서는 이러한 명령어 오류를 어떻게 감지할 수 있을까? 때때로 이러한 오류는 미션크리티컬한 애플리케이션을 지원하는 인프라에 영향을 미쳐 더 큰 비용 손실을 초래할 수 있다. 또한 SAN의 규모와 복잡성이 갈수록 증가하면서 운영 중단의 위험성도 더욱 커지고 있는 것이다.
문제는 기업에서 일반적으로 많이 사용하고 있는 SAN 인프라 변경 작업이 체계적이지 않고 임시 변통적이라는 것이다. 따라서 실제로 구현되기 전까지 변경 작업이 SAN에 미치는 영향을 미리 파악한다는 것은 거의 불가능하다. 또한 많은 관리자들이 스프레드시트를 이용해 상호운용성 정보를 조회하는데 이러한 스프레드시트 형식은 현재 시점의 최신정보를 유지하기 어려워 SAN 변경 관리에 오히려 장애로 작용하기도 한다.
이런 점을 고려해 SAN 변경관리 작업은 발생할 수 있는 오류를 사전에 막고, 호환성을 확보하는데 초점을 맞춰야 한다. SAN 환경을 위한 베이스라인을 세우고, 변경 작업을 계획하고 수행하는데 철저한 준비 과정이 요구되며, 이를 통해 수동 구성 작업의 오류나 디바이스가 서로 호환되지 않아 발생하는 문제들로 인해 야기되는 다운타임을 없앨 수 있다.
SAN 변경관리 작업은 다음과 같은 단계들을 통해 수행할 수 있다.

[1단계] : IT 관리자는 변경 작업에 앞서 기존 SAN 구성이 호환성과 가용성 측면에서 최적화돼 있는지 확인해야 한다. 일차적으로 기존 SAN 환경 정보를 기반으로 발생할 수 있는 잠재적인 문제를 점검한 뒤 현재 SAN 환경에서 적절한 베이스라인을 결정한다. 이때 호환성, 가용성, 구성 문제 등을 살펴봐야 한다. 일단 현재 내재하고 있는 문제를 인식하고 나면 각 문제 해결을 위한 변경 작업을 어떻게 할지 모델링해야 한다. 이를 수행하는 데는 이전 SAN 구성의 호환성이 불완전하거나 내재된 문제점이 없었는지 판단할 수 있는 검증이 필요하다. 또한. 현재의 Zone set을 import 및 backup하고 이 상태가 변경되는지 감시가 필요하다.

[2단계] : 호환성과 가용성, 성능을 보장할 수 있는 SAN 변경을 모델링한다. 1단계에서 파악된 SAN 환경 정보를 참고해 SAN에서 어느 부분에 변경 작업을 적용해야 하는지 결정한다. 이때 얻은 베이스라인 정보는 실제 변경작업을 수행하기에 앞서 SAN 환경에 나타날 수 있는 전반적인 영향에 대해 미리 이해할 수 있게 해준다. 이를 수행하기 위해서 새로이 추가되는 구성요소를 미리 시뮬레이션 해보고 예상 문제점을 파악할 수 있어야 한다. 또한 변경 전과 변경 후의 검증 작업을 위해 각각의 시점에서 구성현황을 보관해야 한다.
[3단계] : 선택한 SAN 변경 작업의 수행 계획을 세운다. 1단계에서 얻은 초기 SAN 환경 정보는 이제 2단계에서 변경 작업을 모델링한 SAN과 어떤 차이가 있을지 비교가 가능해진다. 이제 비교 분석 보고서를 기반으로 얼마나 많은 인원이 변경작업에 투입되어야 하는지 계산해보고, 현재 사용중인 변경관리 소프트웨어를 어떻게 변경할 지 계획을 세운다. 이를 위해 추가 또는 삭제되는 구성요소들 간의 현 시점에서의 엔드 투 엔드(End-to-End) 물리적 구성현황의 정확한 도시가 필요하다.
[4단계] : 본격적인 변경작업을 수행하는 단계로, 3단계에서 수립한 계획에 따라 변경 작업을 실시한다. 이 과정에서 새로운 케이블 설치와 같은 물리적 변화도 포함될 수 있다. 케이블접속을 위해서도 물리적 구성현황 도시는 매우 유용하다.

[5단계] : 마지막으로 SAN 변경 작업이 올바르게 구현됐는지 검증을 하는 단계로, 새롭게 변경된 SAN 환경 정보를 2단계에서 수립한 변경 계획에 비춰 비교·점검을 통해 작업 결과를 평가한다. 이를 위해 2단계에서 저장된 구성현황과 작업 완료 후 저장된 구성현황의 비교가 필요하다. 만약 이 두 가지가 일치하지 않는다면 상이점을 조속히 파악해서 수정을 해야 한다. 더불어 파일시스템 생성, 로지컬 볼륨의 생성 등 애플리케이션의 작업 완료 후에도 작업의 정상적 완료 여부를 현 시점에서의 엔드 투 엔드 논리적 관계 파악을 통해 확인해야 한다.

이상적인 SAN 변경 관리는 이렇게 수행된다. 매일 수작업이 아닌 계획된 정책과 시간(Schedule)에 따라 소프트웨어 에이전트에 의해 실시간 구성 정보가 수집돼 단일 저장소(Repository)에 저장된다. 저장된 상태(Snap)를 근거로 상호 연관성이 파악된 각 구성 요소들을 최신 호환성 툴에 의해 자동으로 검증하고, 잠재된 문제들을 산업계 지식 데이터베이스를 근거로 도출해 변경 내용과 권고사항을 관련자에게 메일로 리포트 한다.
구성 변경을 위해 물리적인 케이블에 기록된 태그 내용을 살펴보는 것이 아니라 단일 저장소(Repository)에 저장된 SAN 구성 요소의 상호 접속 상태를 엔드 투 엔드로 즉시 파악하고 실제 I/O여부를 확인하면서 새로 구성될 포트를 즉시 찾아내게 된다. 동일 화면에서 조닝(Zoning)을 하고 LUN 마스킹을 수행하여 SAN 변경 관리를 마치고 다시 이 상태를 저장(Snap)해 변경 전후의 작업 내용을 확인한다.
물론, 계획 단계를 추가하면 SAN 변경 관리 작업의 초기 단계에 더 많은 시간이 요구되지만, 이런 과정을 통해 사후 문제 해결에 적은 시간이 들어 궁극적으로 운영비용을 줄일 수 있다. 뿐만 아니라, 비즈니스적으로도 안정적인 서비스가 가능한, 복원력이 강한 인프라 구조를 갖출 수 있게 된다.

사례 2: 스토리지 프로비저닝
관리자가 SAN 환경에서 부딪치는 가장 어려운 업무 중 하나가 바로 스토리지 할당작업이다. 어느 부분을 어떻게 할당해야 할지를 결정할 때 용량을 공급할 스토리지 시스템 선택, 할당할 스토리지 용량 파악, RAID 타입 및 서비스 수준 결정, 이중화된 경로 또는 로드밸런싱 경로의 숫자 결정, 서버에 우선적(Primary)으로 연결되는 스토리지 시스템의 컨트롤러 선택, 재난복구(DR)시 제공되는 미러링 타입 결정 등 관리자가 고려해야 할 이슈들이 무수히 많다. 따라서 일반적으로 스토리지 프로비저닝 작업은 복잡할 뿐만 아니라, 많은 시간이 소모되며, 오류가 발생하기 쉽다.
또한, 스토리지 프로비저닝을 수행하려면 스토리지/SAN/호스트 시스템 관리에 대한 전문적 지식이 필요하기에, 간단한 작업이라도 각 관리 주체간의 의사소통에만 수일, 심지어 수주의 시간이 소요된다. 이는 결국 서비스 수준 미달과 비효율적 운영이라는 부정적 결과를 가져오게 된다. 따라서 스토리지 환경 전반에 대한 큰 그림을 보여주는 툴과 전문 지식 없이는 최상의 결과를 얻기 어렵다.
여기에 대한 해결책으로 가상화를 간단히 추천할지도 모르겠다. 가상화가 이뤄지면 관리측면에서 요소들을 일일이 구성하지 않아도 되므로 상당히 편리할 것이라는 막연한 기대에서다. 그러나 가상화는 물리적 구성의 관리 주체가 이원화돼 애플리케이션 차원에서 관여하지 않아도 된다는 요소 기술이지 관리 대상을 사라지게 하는 마술은 아니라는 점을 간과해서는 안 된다. 즉, 스토리지의 통합관리 프레임워크의 역할은 더욱 크게 요구될 것이다.
다음에는 스토리지 프로비저닝 프로세스를 단계별로 살펴보도록 하자.
[1단계] : 호스트에 따른 스토리지 풀을 생성한다. 스토리지 풀 구성은 스토리지 프로비저닝 작업의 기초 작업이라 하겠다. 처음부터 스토리지 풀과 스토리지 정책을 잘 세워야 스토리지 할당 작업을 문제없이 수행할 수 있다. 스토리지 풀은 지역별, 서비스 요구 수준별, 애플리케이션별 등으로 그룹을 나눌 수 있다. 이렇게 논리적 그룹을 결정하고, 이 그룹들을 비즈니스 프로세스나 애플리케이션 프로세스에 연계시킴으로써 스토리지 자원 관리의 간소화가 가능하다. 이런 그룹 작업을 스토리지 정책을 바탕으로 하게 되면 스토리지 할당에 핵심적인 메커니즘을 갖춘 것이라 할 수 있다.

[2단계] : 일단 스토리지 풀이 생성되고 나면 그 다음 단계는 해당 호스트에 대한 스토리지 할당 요구를 처리하기 위해 필요한 경로·위치·종류 등을 결정하는 정책이나 규칙을 만들어야 한다. 정책은 필요 수준에 따라 플래티넘, 골드, 실버 등으로 단계별로 설정할 수 있으며, 이러한 정책들은 스토리지 풀, RAID 수준, 복제 방식, 경로 수 등 다양한 스토리지 관련 규정 등을 포함하게 된다. 스토리지 정책 마련의 이점은 반복적으로 적용할 수 있는 스토리지 할당 프로세스를 수립할 수 있게 해준다는 것이다. 정책 기반의 규칙을 마련하는 표준화로 올바른 스토리지를 할당하는 작업을 보다 용이하게 수행할 수 있으며, 결과적으로 운영비용을 절감할 수 있게 해준다.

[3단계] : 이제 스토리지 자원 풀이 결정되고, 할당 규칙도 세우고 나면, 스토리지를 호스트에 추가하는 작업은 생각보다 매우 간단하다. 새로운 서버를 시스템에 추가했을 때 해당 서버가 데이터웨어하우징 애플리케이션을 위해 더 많은 스토리지를 필요로 한다고 가정해보자. 이 애플리케이션은 가장 높은 수준의 서비스를 요구하는 플래티넘 애플리케이션이라고 했을 때 스토리지는 플래티넘 정책에 따라 추가 할당돼야 한다. 이와 같은 과정을 통해 애플리케이션에 대한 올바른 스토리지 할당을 보다 체계적이고 계획적으로 수행할 수 있다.

이상적인 스토리지 프로비저닝 작업은 다음과 같이 수행된다. 현재 보유한 스토리지를 서비스 레벨에 따라 단일 화면에 파악된 현 시점의 스토리지 현황을 이용해 스토리지 풀로 구성하고 비즈니스 정책과 애플리케이션의 중요도에 따른 정책(Allocation Policy)을 설정한다.
애플리케이션의 요구에 따라 필요한 용량을 미리 설정된 스토리지 풀을 선택하여 자동으로 파악된 유휴 용량 중 권고되는 용량을 선택한다. 해당 애플리케이션의 요구 정책을 이미 알고 있으므로 경로(Path)와 복제(Local/Remote Mirror) 방식이 사전에 정의돼 있어 운영자는 정책을 확인하고 권고된 경로를 선택하면 할당 작업을 수행할 준비가 끝나게 된다. 이미 정해진 표준화된 절차에 따라 이루어진 업무이므로 이제 단위 태스크(Task)화된 업무 리스트를 즉시 수행, 할당 작업을 완료한다.
역시, 스토리지 풀을 생성하거나 정책을 미리 설정하는 것이 초기 구축시에 더 많은 시간이 요구되지만, 이러한 표준화 작업은 의사결정을 위한 시간을 줄이고 사후 발생 가능한 문제를 제거하는데 많은 효과를 가져와 궁극적으로 운영비용을 줄일 수 있다. 더욱이 비즈니스 프로세스의 변경 등에도 유연하면서도 체계적인 변화가 가능한 인프라 구조를 갖출 수 있게 된다.
지금까지 설명한 표준화·자동화된 스토리지 인프라 관리 사례는 스토리지 관리 프레임워크인 EMC 컨트롤센터(ControlCenter) 기술로 실제 이뤄지고 있는 사례이기도 하다. 여기서 언급된 관리는 실제 구성작업을 수행하는 구성 관리를 예로 들었으나 용량 관리, 성능관리, 장애 관리 또한 이러한 단일 프레임워크를 기반으로 운영돼 해당 구성요소를 클릭하거나 드래그 앤 드롭하는 것만으로도 상호 연관 관계를 유연하게 분석할 수 있다. 모니터링하고, 리포트를 작성하고, 보고하는 일까지도 자동화된 정보 수집 기능을 이용하면 동일한 프레임워크에서 운영되는 단일 에이전트에 의해 손쉬운 구현이 가능하다.

100% 만족하는 소프트웨어?
내 요구를 100% 만족하는 소프트웨어는 있는가? 이 질문은 역설적으로 소프트웨어 공급사와 고객과의 동반자 관계가 필요한 이유를 설명한다.
벤더 입장에서는 솔루션과 서비스를 통해 스토리지 인프라를 관리하는 전세계의 노하우를 고객에게 제공하고자 노력하고 있으나, 앞서 전제했듯 고객이 처한 상황이 각각 다르고 지역적인 관습적 차이 등으로 인해 모든 요구 사항을 100% 충족한다고는 할 수 없다. 결국 살아 움직이는 소프트웨어를 내 조직의 일부로 살아있도록 하려면 끊임없는 동반자 관계를 유지하면서 발전적 아이디어를 공유하면서 함께 발전시켜 나가야 한다.
이미 전략적 파트너로 관계를 유지하는 고객이라면 벤더로부터 그들만의 고유한 요구사항까지도 충족시키는 제품으로 만들어가고 있다고 볼 수 있다. 이러한 살아있는 제품을 솔루션 및 서비스로 곁에 두려면 당장 동반자적인 입장에서 소프트웨어를 대할 필요가 있다. 지금까지는 “도대체 내 요구를 100% 만족하는 제품이 없어”라고 생각했다 하더라도 구조적으로 내 요구 사항들을 수용할 수 있는 제품을 함께 키워 나가는 것이 100% 만족하는 제품을 만드는 유일한 방법인 것이다.
혹 “당장의 관리업무도 많은데 또 무언가를 추가한다고?”라고 생각한다면 ‘당장의 관리업무’가 많은 이유가 무엇인지를 다시 되돌아보고, 습관적으로 몸에 익은 수작업 위주의 관리업무를 대폭 줄여줄 소프트웨어 솔루션, 컴퓨팅 파워를 이용할 기회를 찾아보기를 권하고 싶다.
가령, 이미 SRM(스토리지 리소스 관리) 및 디바이스 관리 소프트웨어인 EMC 컨트롤센터 소프트웨어를 보유하고 있다면 다만 동반자적인 입장을 견지하는 것만으로 이는 곧 현실적인 효과로 나타날 것이다. SRM 계획 및 프로비저닝 애플리케이션인 EMC SAN 어드바이저(SAN Advisor)는 작업 계획을 전 IT를 망라한 호환성 검증 데이터 베이스를 통해 사전 검증함으로써 시행착오를 최소화하는 효과를 제공하며, 작업 후에도 계획과 결과를 비교해 영향을 확인토록 함으로써 구성관리 효과를 체험하게끔 한다.
또 다른 예로 SRM 모니터링 및 리포트 애플리케이션인 EMC 스토리지스코프는 한국 고객을 위한 맞춤형 리포트를 제공, 고객환경에서 실제 사용되는 용량관리 리포트 형식을 자동으로 생성해 웹을 통해서나 고유 스프레드시트 형태로 현 시점의 리포트를 바로 확인할 수 있다.
100% 만족하는 소프트웨어는 처음부터 존재하는 것이 아니라 고객 스스로의 관심 속에서 만들어지는 것이다.

악순환의 고리를 선순환의 고리로
세계 유수의 벤더들이 시장성을 확인하며 앞다퉈 제품을 선보이고 테스트 베드로 활용할 만큼 한국의 IT 인프라는 수요가 앞서 나가고 있다. 여러 고객의 프로젝트에 참여해서 장애 관리에 대해서, 용량 관리나 성능 관리에 대해서 요구 사항을 정리하고 이를 구현하다 보면 어느덧 한국이 앞서 제품의 방향을 이끌고 있다는 생각에 이르기도 한다. 그만큼 한국의 IT 인프라는 모험을 감수한다고 볼 수 있고 동시에 새로운 아이디어를 전세계에 보급하는 전초 기지 역할을 하고 있는 셈이다.
앞서 이야기한 것처럼 스토리지 인프라 관리 소프트웨어는 살아있는 조직과 기업을 대상으로 하고 있고 더군다나 한국이 전초기지 역할을 하고 있어 한국의 앞서가는 요구 기능이 미리 100% 구현되어 있으리라고 기대하기 어려운 것은 사실이다.
결국 지속적인 제품 개선 및 개발 요구를 서로 주고받는 비즈니스 동반자로 손을 잡을 때 비즈니스 요구 변화에 따라 매번 새로운 스토리지 인프라 관리 프로젝트를 시작해야 했던 악순환의 고리를 끊고 스토리지 인프라 관리 소프트웨어가 견고한 프레임워크로 우리의 조직과 인프라에 함께 살아 숨쉬게 할 수 있을 것이다.