쓸곳 많은 클라우드.. 이제는 Disaster Recovery 도...(2)

DR 은 있으면 좋은 것이 아니라...

있어야 할 것이라는 것에 대한 공감대는 전반적으로 넓혀지고 있습니다.

 

하지만... 문제는 언제나 비용과 투자에 있습니다.

 

그래서 쓸 때만 쓸 수 있는 클라우드로 DR 을 구축하겠다는 논의가 시작됩니다.

 

단, 여기서는 클라우드에 현재 운영 중인 시스템이 동작하여야 하므로, 대상 시스템을 x86 으로 한정하여야 합니다.

 AIX, HP-UX 등은 전반적인 클라우드에서 제공하는 플랫폼이 아니므로 원격의 클라우드를 사용한다고 할지라도, 그 사용은 아마도 백업 소산 이외에는 힘들 것 같습니다.

 

 원래 클라우드가 저렴하다는 것이 가장 큰 가치인 만큼, 전적으로 클라우드에 DR 을 의존하기 위해서는 x86 서버만으로 구성된 사이트로 한정됩니다.

 

 그렇다면, 플랫폼이 혼재된 사이트는 DR 클라우드 구성이 불가능한 것인가요?

 

 그렇지는 않습니다.

 

 Datacenter 내에 프라이빗 클라우드를 구성하고 해당 클라우드를 DR 용으로 호스팅한다면 충분히 가능한 모델입니다.

 

 그렇다면... 구현이 어떻게 되는지 한번 알아 보도록 합시다.

 

 

1. 백업

- 요건: 원본의 백업이 필요합니다. 단, 1일 1회가 아닌 최대 5분 단위 수준의 백업이 수행되어야 합니다.

- 필요 기능: 원본 서버의 5분 단위 수준의 이미지 증분 백업

 

2. 압축, 중복 제거, 신뢰성 확인

- 요건: Storage 의 효율적인 작업 뿐만 아니라, 원격 전송시 전송 효율성을 최대화 하기 위하여 중복 제거 및 압축이 수행되어야 합니다. 또한, 증분 백업을 지속적으로 받음에도 전체백업 이상의 Data 정합성이 필요합니다. 따라서 백업의 Checksum 수준의 정합성 수준이 아니라 주요 Application 이 해당 data 를 직접 Mount 하는 정도의 보증이 필요할 수 있습니다.

- 필요 기능: 압축, 중복 제거, Application 수준의 Data 정합성 확보

 

 

3. 원격 전송

- 요건: 원격 전송을 위하여 보안 및 압축이 수행되어야 합니다. DR 비용의 가장 큰 부분은 네트워크 비용인 만큼, 해당 비용을 최소화 하고, Data 의 유출을 막을 수 있어야 합니다.

- 필요기능: 구간별 암호화, 압축 및 최소화된 Data 용량

 

4. Standby 구현

- 요건: 장애 이후 OS 를 복원하게 되면 많은 시간이 소요됩니다. 해당 시간을 최소화하기 위하여 DR 사이트에서는 해당 서버를 Standby 직전으로 준비하여야 합니다.

- 필요기능: 전송 즉시 최신 Data 로 Append, 물리 또는 이기종 HW 를 전송 즉시 또는 최단 시간 내에 Standby  로 구현