2014년 4월 국내 굴지의 시스템통합(SI) 업체인 SDS의 데이터센터에 화재가 발생했다. 이곳에 전산서버를 두고 있는 카드사는 일주일 동안 전산업무가 마비됐다. 또 다른 계열사인 보험사는 열흘 넘게 인터넷라운지 등 주요 서비스가 먹통이 돼 소비자들이 불편을 겪었다. 금융당국 지침에 따라 재해·재난 발생 시 3시간 이내에 재해복구시스템을 기동해 업무를 정상화해야 한다. 그러나 SDS는 DR 센터(백업서버를 보유하고 있는 곳)를 갖추고 있었지만, 이 시스템을 기동하지도 못했다.
서버운영프로세스 자동화 관리 시스템(DR 자동화)이 필요한 이유?
시스템 관리자 1명이 커버할 수있는 시스템을 50대 라고 가정할때, 5명 이라면 250대의 시스템을 운영할 수 있다고 가정하자.
관리시스템은 지속적으로 증가되어 400~ 500대를 5명이서 관리를 해야 하는 상황이 발생하게 된다면 어떠한 상황이 발생하게 될까? 다양한 시스템 및 새로운 장비들이 추가로 도입되어 관리자의 Skill도 향상 되어야 하며 DR에 대한 변경관리도 필요하개 된다. 또한, 현실적으로 주센터와 DR센터간의 관리인력의 비율이 부적절하게 배분되어 있지 않은 경우가 많으며 금융감독기관에서 요구하고 있는 주센터의 장애선포 후 3~4시간안에 복구가 불가할 수 밖에 없다.
- 공공기관: 운영관리 인력 대비 DR관리 인력은 가장 낮음
- 제조업체 : 운영관리 인력 대비 DR관리 인력이 낮음
- 금융기관: 운영관리 인력과 DR관리 인력 이 비슷
이로 인하여 시스템 관리의 자동화가 필요하며, 이는 표준화된 관리 방법론(판단기준 필요)이 요구되며 ISO22301, 22302에 표준화 되어 있다. ISO의 국제규격을 준수해야 하는 이유는 향 후에 설명하도록 하겠다.
그렇다면 자동화 솔루션으로 어떤 개선을 가져올 수 있을까?
자
동화 솔루션의 발전(Work flow 개념)
1. 자동화 솔루션의 종류(batch 작업) *이러한 제품은 들은 기능도 많으며 고가임.
(1) BMC Control-M
- Non Stop Scheduling 제공하며, 전 세계적으로 검증된 배치작업 자동화 솔루션
- 금융기관에서 batch 작업을 위해 주로 사용하는 제품(기간계에서 -> 정보계로 일단위 배치 작업 등)
(2) JOB-PaSS
- 반복 수행되는 Batch 작업등을 다양한 컴포넌트를 통하여 손쉽게 정의하고 자동으로 수행 할 수 있는 스케줄링 솔루션으로 안 정적인 서비스를 제공하고 전체 작업의 흐름을 직관적으로 파악이 가능하게 합니다.*제조사: 데이터투테크놀러지(국산)
상기에 대표적으로 나열한 솔루션들은 기능이 많고 고가이 제품이라 DR에 사용할 수 있는 대안 제품의 니즈가 발생하였고
대표저긴 솔루션은 아래와 같다.
(1) MDRM
(2) SANOVI(IBM에서 인수)
(3) 기타
자 그렇다면 자동화관리와 관련된 용어 몇 가지를 살펴보고자 한다.
- BCP(DR에 대한 전략)
재난 발생시 비지니스 연속성을 유지하기 위한 방법론. 지난해 9·11 미국 테러사건 이후 급부상하고 있는 개념으로 이는 재해, 재난으로 정상적인 운용이 어려운 데이터 백업과 같은 단순복구 뿐 아니라 고객 서비스 지속성 보장, 핵심 업무기능을 지속하는 환경을 조성해 기업가치를 최대화하는 것을 말한다. 이를 위해선 우선 기업이 운용하고 있는 시스템에 대한 평가와 비즈니스 프로세스를 파악, 재해에 따른 업무 손실을 최소화하기 위한 방법을 구축하는 작업이 필요하다.
- DRMS(어떻게 DR을 관리할 것인가)
- DRM
- DR
- IPL: 단순서버기동자동화(서버, 어플리케이션, DB, 네트워크장비 등)
: 왜 IPL을 하는가?
1. 메모리 정리(누수방지)
2. 정기적인 PM
- DR 구성 시 대상선정
(1) 대상선정 필요: 핵심업무의 등급에 따라 예 1~ 3순 등급
(2) 구현방법론
- RTO (실시간) 는 ‘목표 복구 시간’이다.
RPO(Recovery Point Objectives)는 ‘목표 복구 지점’이다. 정보시스템이 운영 중에 장애가 발생하여 온라인 비즈니스를 유지할 수 없거나 주요 정보의 유실로 더 이상의 서비스를 할 수 없을 때, 비즈니스 연속을 위해 어느 시점으로 정보시스템을 되돌리거나 정보의 복구가 되어야 하는지를 결정하게 하는 지표이다. 기존 레거시 관점에서는 정보를 일일 백업하여 정보 유실시에 바로 하루 이전 데이터 또는 그 이전의 과거 데이터를 복구하여 서비스를 재 가동했다. 이 때 바로 RPO는 1일이 되는 것이며 또는 1일보다 더 과거가 되는 2일, 3일 등이 될 수도 있다. 물론 과거에는 데이터 복원만이라도 되면 그나마 다행이었던 시절이라 이러한 RPO가 용납이 되던 시절이었으며 운영 시스템의 장애에 대해 클러스터(Cluster) 기술을 이용하여 정보 시스템을 이중화/다중화했다. 그러나 이러한 클러스터 기술은 기업의 비즈니스 로직을 담고 있는 애플리케이션의 이중화일 뿐이지 정보 데이터를 보호하지는 못했다. 그러면 오늘날 IT 기술이 더 이상 기업의 비즈니스를 조력하는 위치에서 리드하는 자리로 변화된 지금 적절한 RPO는 무엇일까? 일 단위의 RPO를 고집한다면 더 이상 온라인 비즈니스를 유지하기 어려울 것이다. 정보시스템이 파격적인 변화를 야기할 4차 산업 혁명이 도래하는 오늘날, 분 또는 초단위의 RPO 지표를 고려해야 할 것이다.
- RPO (시점: 는 ‘목표 복구 지점’이다.)
RTO(Recovery Time Objectives)는 ‘목표 복구 시간’이다.
RTO는 정보시스템 장애시 시스템을 원상태로 복원하는데 소요되는 시간을 의미한다. 불과 몇 해 전만 해도 대다수 기업들은 RPO를 4~6시간 정도로 고려해 정보 시스템을 설계했다. 그러나 폭발적으로 증가하는 정보와 재사용 및 공유로 인하여 이제 4 ~ 6 시간 안에 정보를 보호하여 두었다가 복원하는 것이 이제 불가능에 가깝다. 또한 시간 단위의 복원은 사슬처럼 복잡하게 얽혀 있는 기업의 비즈니스 시스템을 유지하는 것은 불가능하다. 이제는 실시간 그리고 실시간에 근접한 복구 시간을 요구하고 있다. 물론 과거에도 기업의 중요한 시스템은 고 비용을 들여서 실시간 복구 시스템을 구축하였다. FTS(Fault Tolerant System) 또는 BCS(Business Continuity System)은 기업의 주요 시스템에만 적용되어 있었다. 이러한 시스템은 고 비용으로 모든 정보 시스템에 적용할 수 없었고 최소 업무 영향도를 가지고 구축하였다. 그러나 오늘날에는 모든 단위 시스템의 중요도가 비슷하다. 예전처럼 어느 한 개의 단일 시스템서비스 구동만으로는 기업의 비즈니스 연속성을 유지하기 어렵다. 그러므로 대 고객 접점인 프리젠테이션 레이어부터 데이터베이스 시스템 안쪽까지 일련의 정보 시스템이 동등한 RTO를 요구한다. 또한 장애 시 복구에 소요되는 시간도 분 또는 초 단위의 소요시간을 목표로 해야 한다. 2000년대 초반에 RTO를 줄이기 위한 노력 중 하나가 바로 VTL(Virtual Tape Library) 도입이었다. 정보 복구를 위하여 Sequential I/O를 하는 테이프(Tape) 매체보다는 Random I/O를 하는 디스크(Disk) 매체를 마치 테이프(Tape)처럼 가상화해 사용한 것이다. 백업 시간에는 큰 차이가 없으나 디스크(Disk) 매체 복구 시 복구해야 할 블록 위치로 바로 접근해 복구하기 때문에 테이프 매체보다는 빠른 RTO를 제공할 수 있었다. 그리고 오늘날에는 리스토어 과정 없이 백업된 이미지를 바로 서비스에 사용하는 기술이 x86 플랫폼(물리, 가상화)에서 손쉽게 구현되면서 RTO ~ 초 단위로 변화되고 있다.
- RLO(Recovery Level Objectives)는 ‘목표 복구 레벨(수준)’이다.
정보 시스템을 구성 요소는 크게 OS(운영체제), 파일 데이터, 데이터베이스, 애플리케이션으로 나눌 수 있다. 즉 정보시스템 장애 시 복구가 요구되는 요소이기도 하다. 그러나 지금까지 대부분의 정보시스템은 데이터(파일, 데이터베이스)만을 보호해 복구하는데 중점을 뒀다. 운영체제나 애플리케이션은 다시 재설치가 가능했기때문이다. 정보 및 데이터는 유실되면 다시는 돌이킬 수 없었기 때문에 당연한 것이었다고 생각된다. 많은 시간이 소요되더라도 운영체제와 애플리케이션을 재설치 해왔던 것이다.하물며 애플리케이션의 많은 튜닝 값들은 모두 복원하기 어려웠을 것이다. 그리고 과거에 유닉스 시스템을 중심으로 하는 정보시스템에서 운영체제의 복원 방법은 각 서버 제조사의 특화된 기능으로만 제공되던 것이기 때문에 고려대상에서 제외되어 왔다. 그러나 오늘날의 x86 중심의 다운사이징 환경에서는 다양한 수준의 복원이 가능하다. 정보시스템의 장애 유형에 따라서 운영체제, 파일 데이터, 데이터베이스 및 애플리케이션의 선택적인 복원이 가능한 기술들이 소개되고 있다. 또한 선별적인 복원을 위해 각 요소들을 별도로 백업 및 보관할 필요 없이 단일 백업으로 각 필요한 장애에 따라서 복원을 하기 때문에 Backup Window(백업 스케줄 구성)를 단순하게 운영하는 것 또한 큰 장점이다. 즉 단일 백업 이미지로 논리적인 선별적 복원을 하게 한다.
- RlO(Recovery location Objectives)는 ‘목표 복구 위치’이다.
전통적으로 데이터 백업은 테이프(Tape) 매체에 기록했다. 그리고 아직도 여전히 소산을 위해 일부 운영 중이다. 그리고 앞서 언급했듯이 보다 신속한 복구를 위하여 디스크(Disk) 매체를 이용한 VTL을 사용하는 경우도 있다. 이것이 전통적인 레거시 백업 저장소라고 할 수 있다. 그렇다면 2018년 최근 트렌드는 무엇일까? 바로 디스크에 백업하거나 어플라이언스에 백업 및 복제하는 것이며 또한 클라우드를 활용해 백업 및 서비스 재 시작할 이미지를 보관하는 것이다. 글로벌 비즈니스를 하는 기업은 클라우드를 활용해 비즈니스 성장과 축소에 발빠르게 대응하고 있으며 이러한 정보시스템 보호 기술도 변화되고 있다. 최근 트렌드의 공통점은 백업 및 보관된 이미지를 리스토어라는 일련의 장시간이 필요로 하는 과정에서 탈피하여 즉각 서비스하는 관점으로 옮겨갔다는 것이다. 이 또한 오늘날 기업의 비즈니스 생존 전략에 부합한다고 할 수 있다. 즉 기존의 익숙한 것을 버려야 또렷한 미래가 보인다고 할 수 있다. 최근 동향은 어플라이언스를 도입해 정보시스템을 보호하며 원격지 소산 또한 어플라이언스를 원격지에 두고 백업 이미지를 복제하는 구축 방식이다. 그리고 다양한 장애 유형에 따라서 선별적인 복구 방안을 마련함으로써 소프트웨어와 저장장치를 단일 구축해 도입 비용, 운영 편의성 및 확장성을 보장한다.
* 예)
1순위 RPO 0 RTO 4
2순위 RPO 10M RTO 6H
*
RTO 스크립트로 할것인가 or 자동화로 할 것인가?
RPO 관점에서는 스토리지 복제, CDC, S/W 복제
*
정통부 DR가이드 RPO RTS
1. 미러 사이트 0 2H
2. HOT SITE 5m 4h
3. COLD SITE
자동화 관리에서 가장 중요한 것은
(1) 운영관리의 자동화 Work flow
(2) 복구과정 가시화 View(복구 과정을 확인) * RPO 및 RTO 관점
(3) 리스크 예방 관리