_아카이브‎ > ‎

자주하는 질문(FAQ)


AvailabilityGuard와 관련한 일반적인 질문 내용과 답변을 제공해 드립니다.
이외에 추가 질문내용은 인포트릭(주)로 연락을 주시기 바랍니다.

최근 질문과 응답

  • 최적의 HA/DR 환경구축 AvailabilityGuard는 어떻게 최적의 HA/DR 환경을 구축합니까?AvailabilityGuard로 IT 인프라와 재해복구 구성으로 수집한 정보들은 DR을 위한 총소유비용(TCO, Total Cost of Ownership)을 크게 낮추고 효율을 크게 개선하기 ...
    2014. 2. 23. 오후 7:39에 김주철님이 게시
  • DR 테스트 활용 AvailabilityGuard를 활용해서 HA/DR 테스트 계획을 어떻게 개선합니까?AvailabilityGuard를 활용하면 DR 환경을 테스트해야 하는 수고와 압박을 크게 줄일 수 있습니다. AvailabilityGuard를 이용하는 IT 담당자는 DR 테스트를 성공할 ...
    2014. 2. 23. 오후 7:36에 김주철님이 게시
  • HA/DR 구성 취약점 확인 AvailabilityGuard가 HA/DR 구성의 취약점을 확인하는 방법은 무엇입니까?격차 분석(Gap Analysis) AvailabilityGuard는 취약점을 확인하기 위해 수백 건의 검수목록을 포함하고 있는 지식베이스를 사용합니다. 이들 검수목록, 즉 낙인된 격차들은 ...
    2014. 2. 23. 오후 7:38에 김주철님이 게시
  • HA/DR 구성 분석 AvailabilityGuard에 대한 보다 자세한 내용을 알고 싶습니다?AvailabilityGuard가 IT 인프라 전체를 부담 없이 검수하기 위해 갖추고 있는 몇 가지 구성요소를 살펴보도록 하겠습니다.  무에이전트 데이터 수집과 정밀검사  AvailabilityGuard는 ...
    2014. 2. 23. 오후 7:37에 김주철님이 게시
  • DR 문제 대응 AvailabilityGuard는 DR 문제에 어떻게 대응하는가?AvailabilityGuard는 DR 위험요소와 취약점을 탐지하기 위해 IT 인프라를 자동적으로 그리고 정기적으로 정밀검사하는 포괄적인 DR 모니터링 및 분석 솔루션입니다. AvailabilityGuard는 스토리지, 서버, 데이터베이스 ...
    2014. 2. 23. 오후 5:43에 김주철님이 게시
7개의 게시물 중 1 - 5 더보기 »


최적의 HA/DR 환경구축

게시자: 김주철, 2011. 8. 1. 오전 2:13


AvailabilityGuard는 어떻게 최적의 HA/DR 환경을 구축합니까?

AvailabilityGuard로 IT 인프라와 재해복구 구성으로 수집한 정보들은 DR을 위한 총소유비용(TCO, Total Cost of Ownership)을 크게 낮추고 효율을 크게 개선하기 위한 기회를 찾는데 유용하게 활용할 수 있습니다. 거기에는 다음과 같은 개선이 가능한 기회들이 있습니다:

  • 스토리지 구성요소의 활용도 - 활용하고 있지 않은 스토리지 구성요소를 찾아내어 스토리지를 필요로 하는 다른 애플리케이션에 재사용할 수 있습니다. AvailabilityGuard는 상관 관계 능력을 온전히 가동해서 신규로 추가된 스토리지는 예리하게 제외하고 클러스터 시스템에 스토리지 자원을 매핑하는 등의 분석을 합니다.
  • 복제 구성의 오류 - SLA 기준에 맞지 않는 복제 작업, 과도하게 점유하고 있는 대역폭 및 의도와 달리 전혀 복제가 이루어지고 있지 않는 복제 작업 등을 찾아냅니다. 예를 들면, 페이징이나 기타 임시파일의 동기 복제 등. 
  • 터무니 없는 SLA - 목표한 SLA에 비해 과도하게 구성된 인프라에 의해 데이터보호 영역을 찾아냅니다. 예를 들면, SLA 요건보다 초과해서 BCV를 구성하고 있는 EMC 볼륨의 검출 등. 
  • 사용되지 않는 구성요소 - 매우 오래된 복제본이나 전혀 사용되지 않고 있는 구성요소 등을 찾아냅니다.


DR 테스트 활용

게시자: 김주철, 2011. 8. 1. 오전 2:13


AvailabilityGuard를 활용해서 HA/DR 테스트 계획을 어떻게 개선합니까?

AvailabilityGuard를 활용하면 DR 환경을 테스트해야 하는 수고와 압박을 크게 줄일 수 있습니다. AvailabilityGuard를 이용하는 IT 담당자는 DR 테스트를 성공할 것이라는 확신을 가질 수 있기 때문에 압박의 수위가 그 만큼 낮아지게 됩니다. AvailabilityGuard는 수작업으로 하던 정보 수집과 검수 목록 작성을 자동화하므로 그만큼 수고를 덜게 됩니다. AvailabilityGuard는 또한 주요 관심 분야, 즉 대부분의 구성변경이나 DR 격차가 발생한 곳에 집중할 수 있도록 도와드립니다. 이런 식으로 DR 관리자는 경직되고 진부한 테스트 일정 대신에 가장 가치 있는 곳에 자신의 노력을 효과적으로 집중할 수 있습니다.

테스트 그 자체는 거의 격차가 없는 환경에서 수행합니다. 이것은 테스트 자체에 포함되는 위험요소들은 크게 놀랄만한 것이 없거나 약화되어 테스트를 보다 신속하게 진행할 수 있음을 의미합니다. 결과적으로, 테스트 중에 예기치 못한 가동중단의 위협은 크게 경감되고 테스트 후에 정정해야 할 내용도 거의 없습니다. 문제를 테스트하는 행위와 별도로, AvailabilityGuard의 광범위한 문서는 절제되고 이해력 있는 방식으로 구성문제를 신속하게 해결하는데 무한한 가치를 제공합니다.

HA/DR 구성 취약점 확인

게시자: 김주철, 2011. 8. 1. 오전 2:12


AvailabilityGuard가 HA/DR 구성의 취약점을 확인하는 방법은 무엇입니까?

격차 분석(Gap Analysis)

AvailabilityGuard는 취약점을 확인하기 위해 수백 건의 검수목록을 포함하고 있는 지식베이스를 사용합니다. 이들 검수목록, 즉 낙인된 격차들은, 바이러스 예방 프로그램이 단순히 바이러스를 확인하는 것이 아니고 바이러스 방지에 대해 낙인을 하는 것처럼, HA/DR 격차나 취약점을 확인하고 그 문제를 해결하기 위한 지침을 제공합니다. 격차를 찾기 위해, AvailabilityGuard가 생성한 시스템 문서에 이들 낙인을 적용합니다. 예를 들어 어떤 낙인이 원격지로 복제된 복수의 SAN 볼륨에 저장된 데이터파일을 포함하고 있는 데이터베이스를 찾을 수 있습니다. 그리고, 복제 볼륨을 구성하는 볼륨 중에 하나의 데이터 연령이 다름을 알게 됩니다. 이것은 볼륨 세트가 시점의 일관성을 이탈하고 있음을 즉, 오염되어 있다는 것을 의미합니다.

AvailabilityGuard의 광범위한 지식베이스는 다음과 같은 영역을 포괄합니다:

  • 데이터 완결성 – DR 환경을 가동시스템 환경과 비교하여 그 데이터의 완결성을 검사합니다. 이 범주의 격차는 임의의 데이터가 DR 환경에는 결핍되어 있음을 의미합니다. 
  • 데이터 일관성 – 데이터의 일관성과 사용가능 여부를 검사합니다. 
  • 스토리지 구성 – 부적절하게 할당된 스토리지를 검사합니다. 예를 들면, 디바이스 일관성 그룹에 잘못 연결된 스토리지 볼륨 등. 
  • SLA 침해 – 재해복구 SLA 정책이나 요건을 위반하는 항목을 검사합니다. 
  • 데이터 가용성과 데이터 경로 문제 – 데이터나 애플리케이션의 부적절한 매핑을 검사합니다. 
  • 데이터 변조 – 재해복구(DR) 지역의 데이터 사본에 대한 부적절한 변조를 검사합니다. 
  • 부적절한 프로세스 흐름 – DR 프로세스 부적절한 절차를 검사합니다. 예를 들면 데이터 사본이나 분리 등이 완료되기 전에 데이터베이스 백업모드의 종료 등. 
  • 이중화 결함 – 이중화를 만족할 만한 기준 이하의 영역을 확인합니다. 예를 들면, 너무 적은 패브릭 경로, 보호되는 스토리지 볼륨과 보호되지 않는 스토리지 볼륨이 혼재된 볼륨 그룹, 결함이 있거나 잘못 구성된 클러스터 구성원 등등. 
  • 일반적인 결함 – 최상의 시행안이나, 업체 고유의 구성 권고안 등과 같은 원칙을 위배하고 있는 일반적인 결함을 검사합니다.


HA/DR 구성 분석

게시자: 김주철, 2011. 8. 1. 오전 2:11


AvailabilityGuard에 대한 보다 자세한 내용을 알고 싶습니다?

AvailabilityGuard가 IT 인프라 전체를 부담 없이 검수하기 위해 갖추고 있는 몇 가지 구성요소를 살펴보도록 하겠습니다. 

무에이전트 데이터 수집과 정밀검사 

AvailabilityGuard는 IT 인프라에 관한 토폴로지를 구성하고 데이터 수집을 위해 무에이전트 탐지 기술을 사용합니다. 이것은 AvailabilityGuard가 다양한 네트워크 구성요소들에 에이전트를 설치하지 않고 “외장형태(Out-of-the-box)”로 즉시 적용이 가능한 솔루션임을 의미합니다. 가동시스템과 DR 환경의 포괄적인 조망을 생성하기 위해 표준 API와 완벽하게 보안된 방법으로 다양한 원천으로부터 수집한 데이터는 읽기모드로 전환됩니다: 

  • 스토리지 자원관리 소프트웨어 – EMC ECC 및 HDS HighCommand 등
  • 서버와 운영시스템 – SSH, WMI 등의 표준 프로토콜의 통해서 Solaris, AIX, HP/UX, Linux 및 Windows 서버 등을 지원
  • 스토리지 장비 – SMI-S와 같은 표준 프로토콜과 업체 고유의 API를 통해 연결
  • 데이터베이스 – 구성정보 수집을 위해 표준 ODBC 링크를 통해 연결 

데이터수집은 일차와 이차 지역을 망라하는 원격지 인프라를 포함합니다. 수집한 데이터에는 OS와 애플리케이션 정보, 데이터 레이아웃(SAN, DAS, NAS) 등이 포함되어 있습니다. 

탐지와 정밀검사 프로세스는 임의의 잠재적인 구성변경이 데이터보호와 가용성에 영향을 미치기 전에 신속하게 탐지하기 위해 IT 인프라와 현재의 구성을 재검사하도록 정기적인 일정에 맞추어 놓을 수 있습니다. 이것은 AvailabilityGuard가 지속적인 데이터보호와 모니터링의 위해 항시적으로 변경을 탐지하고 평가하도록 합니다. 

DR 종속성 매핑 

AvailabilityGuard는 일차와 이차 지역의 각 객체 간의 종속성을 매핑하고 다음과 같은 관계를 설정합니다: 
  • 자원과 그들의 용도 간의 상관 관계 – AvailabilityGuard는 스토리지 자원을 데이터베이스, 파일시스템 및 애플리케이션 등에 따라 그룹을 짓고 연결합니다. 우선적으로 애플리케이션, 데이터베이스 및 스토리지 볼륨 간의 연관성을 이해하고 문서화합니다.
  • 데이터 세트 복제의 매핑 AvailabilityGuard는 데이터 세트의 복제를 추적하고 분석한 후 DR 인프라 내에서 데이터베이스와 애플리케이션을 매핑하기 위한 광범위한 레이아웃을 생성합니다.
  • 복제 데이터와 DR 자원 간의 상관 관계 – 끝으로, AvailabilityGuard는 복제 세트와 DR 자원 및 애플리케이션 간의 종속성과 상관 관계를 맺고 그들 간의 상관 관계를 이해합니다. 

DR 환경을 효과적으로 모니터하고 관리하기 위해서는 애플리케이션, 데이터베이스 및 스토리지 자원 전반에 걸친 다양한 데이터 관계와 상호 종속성의 상속에 대한 이해가 필수적입니다. 정밀검사/데이터 수집 프로세스는 종속 매핑 프로세스와 결합해서 모든 가동시스템과 DR 자원 그리고 애플리케이션들이 그들을 활용하는 방법을 명쾌하게 이해하도록 해 드립니다. 

AvailabilityGuard의 데이터 수집 및 종속 매핑 프로세스는 모니터링 환경에 엄청난 개선을 가져다 줍니다. 이러한 정보로 무장한 IT 담당자는 DR 자산의 영속적인 기능을 유지하면서 변경관리에 능동적으로 대처할 수 있습니다. 무엇보다 먼저, IT 부서는 전체 데이터 흐름에 대한 문서를 작성할 수 있는 능력을 보유하게 됩니다. 이것은 DR 테스트나 재해복구의 실제상황 연출에 앞서 DR 격차를 탐지하고 가동시스템의 문제를 해결하기 위한 필수적인 도구입니다. 

예를 들면, 다음과 같은 상황을 생각해봅시다: 


위의 구성을 보면, Application Server 1을 2개의 SAN 볼륨(A와 B 볼륨)에 데이터베이스를 저장해서 운영하고 있습니다. AvailabilityGuard는 이들 2개의 볼륨이 Application 1이 사용하는 하나의 데이터 세트를 구성하는 것으로 확인합니다. 그리고 난 후, 복제 경로를 따라가서 복제 본 세트에 상응하는 A’와 B’ 볼륨을 확인합니다. 위에서 보는 바와 같이, B’ 볼륨은 다른 서버(Application 2 DR Server)에 잘못 매핑되고 있다는 사실이 드러납니다. 

만일 재해가 발생할 때까지 이 사실이 해결되지 않고 남아 있다면, Application 1 DR Server는 복제 본 전체를 찾을 수 없기 때문에 결코 작동할 수 없을 것입니다. 따라서 데이터베이스는 가동할 수 없게 됩니다. 일련의 노력으로 문제의 본질을 깨달은 후에 그 문제를 확인했을 때, 시스템 및 스토리지 관리자는 어떤 스토리지 - B’, C, D, 또는 E -가 누락되었는지 확인해야 합니다. 그러나 문서화된 최신자료가 없다면 정답을 찾기란 불가능에 가깝습니다. 실제상황을 가정해서 그 데이터 세트가 수십 대의 디스크를 포함하고 있고 말 그대로 B’ 볼륨이 수천 개의 다른 드라이브 가운데 하나라고 생각해보면, 그 문제의 심각성은 말하지 않아도 분명합니다.

DR 문제 대응

게시자: 김주철, 2011. 8. 1. 오전 2:09


AvailabilityGuard는 DR 문제에 어떻게 대응하는가?

AvailabilityGuard는 DR 위험요소와 취약점을 탐지하기 위해 IT 인프라를 자동적으로 그리고 정기적으로 정밀검사하는 포괄적인 DR 모니터링 및 분석 솔루션입니다. AvailabilityGuard는 스토리지, 서버, 데이터베이스, 클러스터 및 복제 인프라를 정밀검사할 때 지식베이스를 사용합니다. 이 지식베이스는 수백 건의 낙인된 DR 취약점을 포함하고 있으며 지속적으로 갱신됩니다. AvailabilityGuard는 중용한 데이터가 항상 보호되고 있으며 격차가 해소되었음을 보증합니다. 무에이전트 솔루션으로서 AvailabilityGuard는 철저하게 부담을 주지 않고 위험요소를 추가하지 않습니다.

AvailabilityGuard는 다음과 같은 절차를 제공합니다:

  • 문서화 – 가동시스템과 DR 센터의 모든 IT 자원 및 그와 관련된 종속성에 대한 문서를 광범위하게 정기적으로 갱신합니다. 또한, 정교한 가상화 및 보고서 툴을 포함하고 있습니다. 

  • 탐지 – 낙인된 DR 취약점에 대한 독보적이고 광대한 지식베이스를 기반으로 DR 격차와 취약점을 광범위하게 탐지합니다. 

  • 최적화 – IT DR 자원을 최적화함으로써 자산의 효율성과 활용도를 크게 개선합니다. 

AvailabilityGuard는 DR 문제에 어떻게 대응 하는가?

  • 광범위하면서 신속한 정밀검사 – 스토리지, 복제시스템, 운영시스템 및 데이터베이스 등을 포함한 수천 가지의 구성요소를 신속하게 정밀 검사합니다. 가동시스템과 DR 인프라에 대한 자동 정밀검사는 완벽하고 최신의 문서를 제공합니다. 노동집약적이고 오류 가능성이 많은 수작업이 필요 없습니다. 

  • 상호관계에 대한 이해와 매핑AvailabilityGuard는 어떤 데이터를 복제하고 있고, 어떻게 접근하고 참조하는 가를 분석합니다. RecoverGuard는 데이터 흐름을 추적해서 가동시스템 애플리케이션과 그들의 다양한 사본들 그리고 이들 사본에 접근할 수 있는 호스트 간의 관계를 수립합니다. 

  • 가장 광범위한 지식베이스 활용 – AvailabilityGuard는 격차를 발견하기 위해 수천 건의 낙인된 취약점을 포함하는 광범위한 지식베이스를 활용합니다. 이 지식베이스는 수 많은 기업의 전문가와 경험을 집적한 결과물입니다. 낙인된 취약점은 모든 가동시스템과 DR 인프라 구성요소 및 각각에 상응하는 데이터 흐름에 광범위하게 매핑되고 연결되어 있습니다. Continuity Software 연구소는 고객, 산업 전문가 및 업체 등과 지속적인 정보교류를 통해서 새로운 위협에 대해 낙인하고 정의하며 AvailabilityGuard의 지식베이스에 추가합니다. 

  • 부담 삼가 AvailabilityGuard는 에이전트 없는 솔루션으로 전혀 부담을 주지 않으며 위험요소를 별도로 추가하지 않습니다.

HA/DR 구성의 일관성 검증

게시자: 김주철, 2011. 8. 1. 오전 2:01


HA/DR 구성의 일관성을 위한 일반적인 검증방법과 그 한계는 무엇입니까?

격차는 대부분의 기업, 심지어 변경관리 시행안을 엄격하게 적용하고 있는 기업에서도 발견되고 있습니다. 그러한 상황을 구제하기 위한 노력으로 기업들은 DR 솔루션에 대한 감사를 정기적으로 실시하고 있습니다. 운영팀은 정상적인 운영상태(즉, 예비 시스템환경, 복제 메커니즘 등)를 점검하고 규정된 SLA를 만족하고 있는지 확인하기 위해 다양한 검수목록이나 일정표를 사용합니다. 그러나 시스템의 변경은 이러한 감사절차가 따라올 수 없을 정도로 빠르고, 경우에 따라서 개별적으로 일어나기도 합니다. 결과적으로 감사 절차에 격차가 발생하게 됩니다. 이러한 이유로 전체적인 정기감사와 년간 수회에 걸쳐 실시되는 테스트를 수행하는 외부 컨설턴트를 고용하는 기업도 있습니다.

감사(Auditing)

감사는 DR 솔루션의 무결성을 유지관리하기 위해 매우 중요합니다. 일반적으로 감사는 사전에 나열한 검수목록에 따라 광범위한 점검을 시행합니다. 검수목록은 감사 전문가 의견을 토대로 만들어지고 취약점을 탐지하기 위해 설계됩니다. 그러나 비용문제로 인해, 감사는 DR 절차의 타당성을 검토하는데 충분한 주기로 시행되지 못하고 있습니다. 거기에 더해서, 감사는 완료하기까지 수주에서 수개월이 소요되므로 감사를 종료한 시점에 그 정보는 이미 효력을 상실하기도 합니다.

테스트(Testing)

테스트의 목적은 DR 솔루션이 제대로 작동하는지 실제 장애 시나리오에 따라 모의하는 것입니다. 테스트는 DR 솔루션이 실제상황에서 제대로 작동하는가에 대한 의문에 명확한 답을 제시하므로 매우 중요합니다. 테스트는 가동시스템의 가용성과 데이터보호 상황을 유지하는 동시에 실제 장애를 모의해야 하므로 보다 많은 준비를 해야 합니다. 실제 테스트는 어떤 환경을 다시 문서화하고, 각각의 팀은 어떤 문제를 담당해야 하고, 예상되는 격차를 어떻게 점검할 것인가를 결정하기 위해 몇 주간에 걸쳐 야단법석을 떤 후에야 진행이 됩니다.

테스트는 가능한 한 실제상황과 같아야 합니다. 그러나 많은 경우에 있어서 이것은 달성하기에 매우 어려운 일입니다. 쉽게 간과한 종속성이나 세부구성 등으로 인해 격차를 탐지하지 못하고 넘어가기도 합니다. 예를 들어, 테스트 중에는 도메인 서버, 파일 서버, 데이터베이스 등과 같이 DR 자원 대신에 무의식적으로 가동시스템 환경의 자원을 사용하기도 합니다. 이러한 경우에, 이들 시스템은 테스트 중에는 제대로 기능을 하겠지만, 가동시스템이 사용 불가한 실제 상황에서는 제대로 작동하지 않을 것이 확실합니다. 다른 한편, “유사 실제상황” 테스트는 가동중단과 데이터 손실을 초래할 수도 있습니다.

또한, 테스트 중에 문제를 확인하느라 완료되는 시간이 지연되기 때문에 테스트는 빈번하게 부분적으로만 진행되는 경향이 있습니다. 최상의 환경하에서 중요한 애플리케이션은 일년에 기껏해야 한 번이나 두 번 정도 테스트를 하지만, 다른 애플리케이션은 격년에 걸쳐 한번 테스트를 합니다. 거기에 더해서, 테스트는 종종 작은 부문으로 나뉘고 순차적으로 진행되기 때문에 서로 종속관계에 있는 어떤 애플리케이션들은 전혀 테스트하지 못하고 있습니다(Gartner 보고서). 그 결과로, 가장 최근의 테스트 결과도 부정확하고 위험하며, 기껏해야 변화하고 있는 환경에 대한 단순한 스냅샷에 지나지 않습니다.

결론 – 자동화 필요

많은 기업들이 광범위한 감사와 테스트를 수행하는데 필요한 시간을 할애하기가 어렵다는 것을 알고 있습니다. 단지 한가지 알려진 문제를 한 서버에서 찾아내는 것만으로도 수 시간, 심지어 하루 종일 문제해결에 매달려야 합니다. 하물며, 수백 대의 서버에 수천 건의 알려진 문제를 점검하는 데에는 그 모든 것을 처리할 시간조차 모자랍니다. 프로세스의 자동화는 완전하고 정확하며 무엇보다도 항상 최신의 상태를 유지합니다. 그러나 자동화 자체만으로는 충분하지가 않습니다. DR 환경에서 격차를 찾아내기 위해 자체적으로 준비한 검수목록은 수십 개의 항목을 나열하고는 있지만 여전히 재해복구에 위협이 될만한 잠재적인 위협을 모두 포함하고 있지는 못합니다. 오로지 수백 명의 DR 전문가들로부터 집대성해서 광범위하게 최상의 시행안을 담은 지식베이스만이 효과적일 수 있습니다. 검증은 IT 환경에서 관계성과 종속성의 실제 매핑에 기초해야 합니다. 결론적으로 자동화는 부담이 되어서는 안되며, 그렇지 않으면 오히려 그 자체가 데이터 가용성에 위험요소를 만들어 낼 것입니다.

HA/DR 실패의 원인

게시자: 김주철, 2011. 8. 1. 오전 2:00


일반적인 HA/DR 실패의 원인은 무엇입니까?

HA/DR 실패의 원인은 일반적으로 IT 환경에 광범위하고 상시적인 변경이 일어나고 있다는 사실에 근본을 두고 있습니다. 대부분의 기업은 수백 종의 애플리케이션을 수천 대의 서버상에 운영하고, 다양한 스토리지 플랫폼에 데이터를 저장하며 세계 전역에 걸쳐 복수의 데이터센터 환경을 갖추고 있습니다. 이미 충분히 복잡한 환경에 변경이 일상적으로 더해지고 있습니다. HA/DR 솔루션은 동일성을 유지해야 하기 때문에 이러한 상시적인 변경 모두를 복제시스템 환경에도 적용해야 합니다. 새로운 볼륨을 추가하고 복제 프로세스를 재구성하는 것과 같은 임의의 작은 구성상의 변경도 가동시스템과 재해복구 환경에 격차를 만들어 낼 수 있습니다. 아주 작은 격차조차도 HA/DR 솔루션이 필요할 때 제대로 동작하는 것을 방해할 수 있습니다.

가동시스템과 HA/DR 환경 사이에 격차는 다음과 같은 이유로 발생하고 있습니다:

대규모 시스템구성
규모가 클수록 격차의 원인이 되는 오류의 가능성이 높아집니다. 이기종 환경
같은 기업 내에서도 복수의 운영시스템(OS), 복수의 데이터베이스, 복수의 스토리지 플랫폼 등을 포함한 다양한 기술의 솔루션을 운영하고 있습니다. 결과적으로 DR 데이터센터의 IT 환경은 가동시스템의 데이터센터와 일관성을 유지하기가 어렵습니다.

다단계 종속성
DR 솔루션은 여러 계층 – 운영시스템, 스토리지, 데이터베이스, 네트워크, 서버 및 애플리케이션 – 간에 종속성은 필연적입니다. 이들 계층 간의 종속성으로 인해 작은 오류도 훨씬 큰 영향을 미치게 됩니다.

너무 많은 사공
일반적으로 DR 애플리케이션 구성에는 DBA, DR 전문가, 애플리케이션 개발자 및 다양한 계약 당사자 등과 같은 다양한 전문가들이 관여하게 되어 있습니다. 다양한 IT 담당자들 간의 사소한 의사소통 결핍은 DR 솔루션을 산으로 가게 하는 원인이 될 수 있습니다.

DR 격차로 인해 발생하는 위험요소를 영역별로 살펴보면 다음과 같습니다:

데이터보호 관련 위험요소
애플리케이션 데이터, 메타데이터 및 데이터 링크 등은 격차로 인해 위협을 받을 수 있습니다. 격차는 복제, 설정, 절차 진행 과정, 접근, 매핑, 조닝 등을 포함한 여러 부문에 걸쳐 발생할 수 있습니다. 그러므로 데이터의 정합성과 그 데이터의 내부구조의 일관성을 유지하는 일은 여간 난감한 일이 아닐 수 없습니다.

가용성 관련 위험요소
가용성의 격차는 클러스터와 데이터베이스의 구성오류나 예비 호스트의 복제 스토리지에 잘못된 매핑 등등으로 인해 발생할 수 있습니다. 그러한 격차의 존재는 예비 호스트, 즉 DR 서버가 필요할 때 제대로 동작하지 못하게 하는 원인이 될 수 있습니다.

최적화 관련 위험요소
스토리지 자원 배치에서 발생하는 격차는 스토리지 자원의 과도한 할당과 SAN 자원을 비효율적인 사용의 원인이 되고 최상의 시행안을 적용할 수 없게 됩니다.

이들 영역은 서로 관련되어 있고 상호 종속되어 있습니다. 예를 들면, DBA가 절차에 따라 추가적인 스토리지 공간을 요청했을 때, 스토리지 관리자는, 하나는 데이터베이스 파일을 위해 그리고 다른 하나는 일반 파일을 위해, 새로운 스토리지의 두 세트를 적절하게 구성하고 할당합니다. 일반적으로 각 세트는 각각의 복제 정책과 일관성 그룹 규정을 갖고 있을 것입니다. 그러나 그러한 구성은 향후 몇 주 후에 적용이 될 것입니다. 결과적으로, DBA가 데이터베이스 확장을 위한 관리 권한을 수행할 것이고, 데이터베이스 확장에 사용된 DBA가 설정한 새로운 스토리지는 DR환경에 부적합하게 될 것입니다. 그 결과 복제 데이터 세트 전체가 무용지물이 될 것입니다.

1-7 of 7