기업에서 시스템 환경을 이중으로 구축했다고 해도, 무언가 잘못돼 재난이 일어날 가능성은 언제나 잠재돼 있다. 홍수나 지진과 같은 자연 재해일 수도 있고, 화재로 인한 재난이거나 전원이 나가는 경우일 수도 있으며, 악의를 가지고 외부에서 의도적으로 공격한 경우일 수도 있다. 사고의 원인이 무엇이든 간에 그 결과는 기업에 치명적일 수밖에 없다. 특히 시스템이 다운돼 서비스가 중단돼 있는 시간이 길어질수록 그 폐해는 더욱 심각해진다.복제 = 재해 복구?그렇다면 이런 문제에 대한 시원한 해결 방안은 없을까. 많은 IT 관리자들이 절감하고 있듯이 재해 예방의 최선책은 데이터 복제(Data Replication)다. 여기서 문제는 적은 TCO로 최상의 재해 복구를 할 수 있고, 구현·관리가 용이하며, 기업의 규모 변화에 상관없이 데이터를 보호할 수 있는 확장성을 갖춘 적합한 복제 솔루션을 찾는 일이다. 많은 기업에서 여전히 이동 매체에 백업하는 방식으로 데이터를 보관하고 있지만, 24×7×365 서비스와 같이 서비스 연속성이 점점 중요시되는 현실을 고려해 볼 때, 중요한 기업 데이터를 단순히 테이프나 광디스크에 백업하는 것에만 의존하는 것은 바람직하지 못하다. 이론적으로는 처음부터 유사한 시스템 환경을 구축해 여기에 백업받은 데이터를 복구하는 방법을 생각해 볼 수 있겠으나, 이는 여러 면에서 현실성이 떨어진다. 새로운 데이터센터를 지어 이를 운영할 수 있을 때까지 손놓고 기다릴 수 있을 만큼 여유로운 기업은 별로 없다. 그러므로 현명한 기업이라면 기업의 규모에 상관없이 테이프 백업 이상의 재해 복구 계획을 미리미리 세우고 있어야 한다. 데이터 복제를 통해 접근 가능한 최근 데이터의 복사본이 재해가 일어나지 않은 원격지에 혹시라도 존재할 수 있기 때문에 데이터 복제는 재해 복구에 필수적이다.대다수의 기업은 데이터 관련 재해에 대해 여전히 무방비 상태다. 그렇다면 이렇게 기업이 적극적으로 대처하지 못하는 이유는 무엇일까. 부족한 예산과 재해복구에 투자한 선례의 부재 외에도, ‘설마 우리에게 그런 일이 일어날까?’하는 안일한 태도가 복합적으로 작용한 결과라고 볼 수 있다. 그러나 지금이야말로 현실을 직시해 서비스가 중단되지 않도록 대책을 마련해야 할 때다. IT 관리자들은 재해 복구 계획을 세울 때, 적은 TCO로 효율적으로 데이터를 보호할 수 있는 솔루션을 선택하기 위해 데이터 복제 옵션을 주의깊게 살펴볼 필요가 있다. 최소의 비용으로 최대의 효과를 얻을 수 있는 복제 솔루션을 찾는 작업이 선행돼야 한다. 기업마다 개별화된 재해 복구 시나리오에 부합하는 복제 솔루션을 선택하는 것이 그리 간단한 일은 아니다. 그러나 스토리지 네트워크 기반의 복제 모델이라면 이런 예상되는 많은 문제점들을 해결할 수 있을 것으로 보인다. 다양한 기능을 가진 스토리지 네트워크 데이터 복제 모델은 성능이 뛰어나고, 관리가 쉬우며 비용 절감의 효과를 볼 수 있다. 또한 이 모델은 시스템 규모에 상관없이 비교적 간단하고 효과적으로 구성할 수 있으며, 향후 확장성도 보장된다는 장점을 갖고 있다. 복제 솔루션의 확장확장성에 대해 좀 더 살펴보자. 복제 솔루션을 선택하는데 있어서 무엇보다도 중요한 고려 사항이 확장성이다. 만일 처음 선택한 복제 솔루션이 단순히 하루에 몇 기가바이트씩 복제하는 일만 수행한다면, 메인 사이트에 복제할 필요가 있는 새로운 데이터가 생겼을 때, 모든 것을 다시 처음부터 시작해야 하는 번거로움이 따른다. 여기에 수반될 추가 비용, 새로 익혀야 할 세부 사항, 기존 설치된 복제 솔루션의 제거, 새로운 복제 솔루션 설치에 따른 문제점 등을 생각해 보라. 쉽게 확장될 수 있고 변경할 수 있는 복제 솔루션을 구현하는 것이 훨씬 간단하고 비용 측면에서도 효과적이다. 데이터 복제의 3가지 방법 복제에는 기본적으로 다음과 같은 3가지 종류가 있다. 하나는 서버 기반의 복제이고, 다른 하나는 디스크 기반의 복제이며, 마지막으로 스토리지 네트워크 기반의 복제를 들 수 있다. 처음 두 가지 방식은 나름대로의 장점을 가지고 있는 동시에 간과해서는 안 될 치명적인 단점을 가지고 있는 반면, 마지막에 소개할 스토리지 네트워크 기반의 복제 방식은 3가지 방식 중에서 가장 압도적인 장점을 지니고 있다. 디스크 기반의 복제(하드웨어) 대규모 스토리지 하드웨어 공급업체는 대개 하드웨어 기반의 복제 모델을 제시하며, 이들 대부분이 복제가 이뤄지는 양쪽에 이에 상응하는 스토리지 어레이를 자체적으로 보유하는 것을 전제로 한다. 예를 들어, EMC 시메트릭스는 반드시 또다른 EMC 시메트릭스에 복제돼야 한다. 다시 말해, EMC 시메트릭스가 EMC 클라리온이나 또는 다른 공급업체의 서버에 복제될 수 없다. 또한 하드웨어나 서버에 별도의 소프트웨어를 설치해야 하는 경우도 있다. 복제 기능이 있는 하이엔드 스토리지 어레이는 가격이 상당히 비쌀 뿐 아니라, 급격한 기술 발전으로 인해 금방 구식이 돼 버려 사용자는 제품을 공급한 업체에 의존적일 수밖에 없다. 몇 년이 지나 같은 공급업체나 혹은 다른 공급업체에서 새로운 복제 기술을 소개하더라도, 이에 능동적으로 대처하지 못하고 예전에 도입한 서버에 국한되기 쉽다. 또 디스크 기반의 복제 방식을 자동화하기 위해서는 사용자가 스크립트 언어나 프로그램을 직접 구현할 수 있어야 한다. 게다가 IP를 통해 복제하기 위해서는 성능이 우수한 라우터가 필요하며, 이에 따르는 비용도 만만치 않다. 일부 스토리지가 집중된 대규모의 IT 환경에서 디스크 기반의 복제 모델을 사용하고 있다.서버 기반의 복제(소프트웨어)서버 기반의 복제 모델에서 복제 소프트웨어는 복제할 데이터가 있는 각 애플리케이션 서버에 탑재되며, 이는 애플리케이션 레벨에서 동작할 수도 있고 운영체제 레벨에서 동작할 수도 있다. 서버 기반의 복제는 스토리지의 종류나 스토리지 공급업체와 독립적이다. 또한 디스크 기반 복제 모델과 마찬가지로 IP를 통해 복제하기 위해서는 고가의 라우터가 필요하다. 일반적으로 애플리케이션 중심의 소규모 IT 환경에서 서버 기반의 접근방식을 택하고 있다.서버 기반 복제 모델의 가장 큰 단점은 메인 사이트에 존재하는 각기 다른 운영체제에 대해 백업 데이터센터는 이와 동일한 운영체제를 가진 호스트를 적어도 하나 이상 보유해야 한다는 제약이 따른다는 점이다. 예를 들어, 메인 사이트에 서로 다른 5종류의 운영체제가 존재한다면, 복제한 데이터를 받기 위해서는 백업 사이트에도 이와 동일한 5종류의 운영체제 플랫폼이 필요하다. 게다가 앞에서 언급한 메인 사이트에서 1000대의 서버가 운영되고 있다면, 기업 입장에서는 이기종 플랫폼에서 1000 카피의 복제 소프트웨어 라이선스에 대한 구입, 설치, 관리, 유지에 따르는 모든 부담을 떠안게 되는 셈이다. 그 결과, 엄청난 비용이 발생하고 장비·프로그램 관리에 소요되는 인력과 시간이 낭비되며, 각기 다른 운영체제와 애플리케이션에 대해 상이한 소프트웨어를 익혀야 하는 어려움이 따른다. 스토리지 네트워크 기반의 복제(소프트웨어)스토리지 네트워크 기반의 복제 모델에서 복제 기능은 중앙화된 인밴드(호스트 서버와 SAN 스토리지 사이의 데이터 스트림 내) 소프트웨어 기반의 엔터프라이즈 스토리지 서비스 플랫폼에서 수행된다. 다른 스토리지 서비스 뿐 아니라, 복제 서비스를 기업 전반에 걸쳐 활성화하기 위해 해당 소프트웨어는 애플리케이션 서버와 스토리지 사이에서 게이트웨이 역할을 하는 어플라이언스에 설치한다.
이 방식의 장점 중 하나는 자체적으로 보유한 스토리지 하드웨어에 독립적이라는 점이고, 다른 하나는 복제 작업을 지원할 필요가 없다는 점이다. 따라서 관리·소프트웨어 비용이 절감돼 TCO를 줄일 수 있다. 이상적으로 IP 기반에서 블록 단위로 비동기적으로 데이터를 복제하는 원격 복제 방식은 특별한 네트워크 인프라 없이 같은 기종 또는 이기종의 디스크 어레이 사이에서 이뤄진다. 스토리지 서비스 플랫폼이 이미 준비된 경우라면 처음부터 새로운 솔루션 전체를 구입하지 않고도 언제라도 복제 기능을 추가할 수 있다. 따라서 새로운 솔루션 도입에 따르는 전반적인 비용은 절감되고 관리, 기술 습득에 대한 부담도 줄어드는 것은 당연하다. 스토리지 네트워크 기반 모델은 비교적 단기간에 사용자가 메인 사이트에서 재해 복구 사이트로, 또는 여러 개의 메인 사이트에서 중앙의 데이터센터로 데이터를 쉽게 복제할 수 있도록 한다. 이렇게 복제한 데이터를 나중에 원격 사이트에서 테이프에 연속 백업(Continuous Backup) 또는 제로 임팩트 백업(Zero-Impact Backup)할 수도 있다. 또 다른 장점으로는 확장성을 꼽을 수 있다. 스토리지 네트워크 복제 모델에서 복제 솔루션은 네트워크의 대역내에 놓이기 때문에, 복제가 이뤄지는 양쪽 사이트에 복제 솔루션을 한 번만 구현함으로써 얼마든지 확장할 수 있다. 차후에 서버나 스토리지가 별 무리없이 계속 추가될 수 있다. 이는 지속적으로 비싼 스토리지 어레이를 구입해 관리하거나, 각 서버마다 점점 증가하는 소프트웨어 카피를 관리해야 하는 방식과는 비교도 할 수 없을 정도로 확장성이 뛰어난 것이다.
스토리지 서비스의 기능 구현 IP에서 데이터를 원거리로 이동시켜야 하는 경우에도 스토리지 네트워크 기반의 복제는 기업의 규모가 크건 작건 비용 측면에서 효율적인 재난 복구 솔루션이다. 이 방식은 어떤 DR 시나리오도 수용할 수 있도록 포괄적인 데이터 보호 기능을 제공하기 때문에, 스토리지 크기나 종류에 상관없이 탁월한 접근방식이다.기존 스토리지 가상화 제품은 현재 사용하는 스토리지의 데이터를 일단 다른 저장소로 이동시키고 가상화 작업을 거친 후, 다시 데이터를 옮겨야 하는 단점을 가지고 있었다. 스토리지 데이터를 복제하는데는 별도의 하드웨어를 필요로 하지 않기 때문에 LAN, MAN, WAN 등 기존의 어떤 네트워크 인프라에서도 문제없다. 이런 데이터 복제는 애플리케이션 서버와는 독립적으로 구성 관리되므로, 애플리케이션 서버는 백업 사이트에 데이터를 복제하는 것을 전혀 알 수 없으며 아무런 영향도 받지 않는다. 통합된 스냅샷 엔진은 메인 사이트에서 백업 사이트로 데이터를 이동하는 동안 복제된 데이터가 손상되지 않도록 설계됐다. 만약 복제하는 동안 문제가 발생하면 복제된 데이터는 디스크에 저장되지 않는다. 애플리케이션을 감지하는 스냅샷 에이전트를 이용해 실제 데이터베이스가 데이터 무결성과 포인트 인 타임 일관성을 유지하면서 데이터를 복제할 수 있다.복제 채널을 형성하기 위해 메인 사이트의 어플라이언스는 백업 사이트의 어플라이언스와 통신한다. 초기 동기화 프로세스는 메인 사이트에서 복제 사이트로 데이터를 전송하기 위해 일어난다. 데이터 크기가 큰 경우에는 이와는 다른 방법을 적용한다. 일단 동기화 작업이 끝난 후에는 변경된 데이터만이 전송된다. 대용량 데이터에 대해서는 초기 동기화 작업에 어려움이 따른다. 예를 들어, 상대적으로 속도가 빠르지 못한 WAN 환경(T1을 예를 들면 481GB/월 정도로, 1TB 데이터를 전송하는데 약 2달 이상이 소요)에서 테라바이트의 데이터를 전송하는 데 제약이 있을 수 있다. 그러나 매일 변경된 데이터는 크지 않기 때문에 WAN으로 충분히 전송할 수 있을 것이다. 문제는 처음에 대량의 데이터를 어떻게 전송하는가에 있다. 이런 문제를 해결할 수 있는 방법으로 델타 동기(Delta-Synch) 방식이 있다. 데이터를 전부 복사할 필요없이 동기화 전에 어떤 데이터를 복제해야 하는지 결정하기 위해 양쪽의 데이터를 먼저 비교한다. 따라서 원격 사이트에 대량의 초기 데이터를 전송할 수만 있다면, 델타 동기 방식을 통해 변경된 부분만을 동기화하면 된다. 대량의 데이터를 옮기는 방법으로는 크게 다음과 같은 2가지 방법이 있다. 첫째, 메인 사이트에서 미러 볼륨을 생성하는 것이다. 먼저 복제 사이트에서 사용할 저장 매체를 메인 사이트에 설치한다. 이는 개별 어레이일 수도 있고, 비슷한 종류의 어레이로부터 제거 가능한 드라이브일 수도 있다. 설치한 저장 매체에 드라이브의 데이터를 동기화한다. 물론 이 과정은 한 사이트에서 이뤄지기 때문에 WAN 연결을 필요로 하지 않는다. 그 다음 복제 사이트에 설치한다. 두 개의 데이터 볼륨을 비교해 미러링 이후의 변경된 데이터만을 모아 이를 복제한다. 데이터 전체가 아닌 하루나 이틀 동안 변경된 데이터만을 복제하기 때문에 WAN의 부하를 줄이고 대역폭 비용을 절감할 수 있다.이와 비슷한 방식으로 테이프 백업을 이용할 수도 있다. 먼저 고속 백업방식인 제로 임팩트 백업을 통해 메인 사이트에 있는 데이터를 백업한 후, 백업한 데이터를 복제 사이트에 복구한다. 앞에서 설명한 것과 마찬가지로 양쪽의 데이터 볼륨을 비교해 백업 이후의 변경된 데이터에 대해서만 동기화가 이뤄진다. 메인 사이트의 스토리지에 문제가 발생하면 손상된 데이터 대신에 IP로 연결된 복제 데이터를 바로 사용할 수 있다. 복제 프로세스의 포인트 인 타임 일관성과 트랜잭션 무결성이 유지돼, 손상된 데이터를 대신해 사용되는 복제 데이터는 데이터베이스 일관성 체크와 같이 시간이 많이 소요되는 작업은 할 필요가 없다. 복제 정책시스템 관리자는 각 데이터 볼륨에 대해 개별적인 복제 정책을 유연성 있게 세울 수 있다. 시스템 관리자는 데이터 볼륨에 대해 자사의 환경에 맞는 복제 정책을 마련하기 위해 다음과 같은 사항을 설정할 수 있다. ·데이터 변경량 / Amount of Data Change (예 : 1MB)·시간 / Time of Day (예 : 11:30 PM)·간격 / Time interval (예 : 2분 간격) 예를 들어, 어떤 데이터 볼륨은 매일 밤 10시에 복제하고, 다른 어떤 데이터 볼륨은 5분마다 복제하도록 관리자가 자유롭게 설정할 수 있다. 또 다른 어떤 데이터 볼륨에 대해서는 마지막 복제 이후 변경된 데이터 양이 1MB가 되면 복제를 시작하도록 설정할 수도 있다. 데이터 볼륨에 대해 각각의 이상적인 복제 정책이 정해지면, 결정된 복제 정책에 따라 자동적으로 복제 프로세스를 수행한다. 트랜잭션 무결성과 포인트 인 타임 일관성데이터 복구시 백업이 유효하려면 데이터베이스의 트랜잭션 무결성과 포인트 인 타임 일관성은 더욱 중요하다. 만일 백업 데이터가 원본 데이터와 정확하게 일치하지 않으면, 결과적으로 서비스하는 기업에 치명적인 악영향을 미칠지도 모른다. 스냅샷 에이전트는 복제를 포함한 모든 백업 프로세스가 진행되는 동안 트랜잭션 무결성과 포인트 인 타임 일관성을 처음부터 끝까지 유지시킨다. 또 스냅샷 에이전트는 데이터베이스를 일정 시간 동안 백업 모드로 전환할 필요가 없다. 작업 정지 시간이 시간 단위로 측정되는 것이 아니라 초 단위로 측정되는 것이다. 재해 발생시 비즈니스 복구 메인 사이트에 시스템 장애가 발생한 경우에 시스템 관리자는 백업 데이터센터에 위치한 복제된 데이터를 애플리케이션 서버가 접근하도록 설정할 수 있다. 메인 사이트가 완전히 마비되는 경우에도 스탠바이 애플리케이션 서버를 실제로 가동하고 백업 데이터센터에서 대기함으로써 정상적인 서비스를 제공할 수 있다. 재해를 최대한 예방하기 위해 시스템 환경 내의 모든 것을 똑같이 중복 구현할 수 있도록 설계해야 하고, 장애 없이 정상적으로 운영되는 것을 확실히 하기 위해 이더넷이나 광채널에서 호스트 레벨의 다중 경로를 지정할 수 있도록 지원할 수 있어야 한다. 또한 어플라이언스를 이용해 동시에 미러링할 수 있을 뿐 아니라 2대의 어플라이언스가 서로의 상태를 모니터링할 수 있도록 Active-Active Failover 모드로 구성해야 한다. 다시 말해 하나의 어플라이언스에 문제가 발생하면 이것이 완전히 정상화될 때까지 다른 어플라이언스가 모든 입출력 연산을 담당하도록 구성하는 것이다. 24×7×365 서비스와 같이 서비스 연속성을 보장하도록 고가용성과 재해복구 대책을 적절히 응용할 수 있어야 한다.재해 복구와 관련된 대부분의 논의는 장애가 발생한 동안에 어떻게 시스템을 가동시킬 것인가에 집중된다. 그러나 이미 시스템 장애를 경험한 사람들은 장애 발생중에 서비스를 정상적으로 가동하는 것도 어렵지만, 서비스가 정상화된 이후에 메인 사이트에 모든 시스템을 복원하는 작업이 더 힘든 일이라고 지적한다. 완벽한 재해 복구 솔루션이 갖춰야 하는 기능 중 하나는 재동기(Re-synchronize) 기능이다. 이 기능을 이용하면 IT 관리자는 데이터를 메인 사이트로 쉽게 전송해 서비스가 정상화될 수 있도록 도울 수 있다. 스페어 타이어가 임시적으로 사용되는 것과 마찬가지로 백업 데이터센터도 실제 데이터를 영구적으로 대치할 목적으로 사용되는 것은 아니다. 최적의 복제 솔루션은 유연성, 확장성, 보안성을 모두 갖추어야 하며, 사용하기 쉽고 비용면에서 효과적인 복제 기능을 제공해 재난이 발생할 경우 뿐 아니라 장애 복구 프로세스가 진행되는 동안에도 시스템이 다운되는 시간을 줄일 수 있어야 한다. 더 나아가 연결 방식, 하드웨어, 인터페이스, 프로토콜, 플랫폼 등에 독립적이어야 하며, 기업 입장에서는 자사의 비즈니스 요구사항을 최대한 만족시킬 수 있는 스토리지를 자유롭게 선택할 수 있어야 한다. @
