Hyper-V
SnapMirror 활성 동기화를 통한 Oracle 데이터베이스 페일오버
변경 제안
PDF
SnapMirror 액티브 동기화에서 Oracle 데이터베이스를 호스팅하는 주된 이유는 계획된 스토리지 이벤트 및 계획되지 않은 스토리지 이벤트 중에 투명한 페일오버를 제공하기 위해서입니다.
SnapMirror 액티브 동기화는 계획된 스토리지 페일오버 작업과 계획되지 않은 두 가지 유형의 스토리지 페일오버 작업을 지원하며, 두 가지 방식으로 작동합니다. 계획된 페일오버는 관리자가 원격 사이트로 빠르게 전환하기 위해 수동으로 시작하는 반면, 계획되지 않은 페일오버는 3차 사이트의 중재자가 자동으로 시작합니다. 계획된 페일오버의 주된 목적은 증분 패치 및 업그레이드를 수행하고, 재해 복구 테스트를 수행하거나, 전체 활성 동기화 기능을 입증하기 위해 1년 내내 사이트 간 작업을 전환하는 공식적인 정책을 채택하는 것입니다.
이 다이어그램은 정상, 장애 조치 및 장애 복구 작업 중에 발생하는 상황을 보여 줍니다. 쉽게 이해할 수 있도록 복제된 LUN을 설명합니다. 실제 SnapMirror 활성 동기화 구성에서는 각 볼륨에 하나 이상의 LUN이 포함되어 있는 볼륨을 기반으로 복제가 수행되지만 그림을 더 단순하게 만들기 위해 볼륨 계층이 제거되었습니다.
정상 작동
정상 작동 시 로컬 또는 원격 복제본에서 LUN에 액세스할 수 있습니다. 빨간색 선은 ALUA에서 광고한 최적화된 경로를 나타내며, 그 결과 입출력이 이 경로를 통해 우선적으로 전송되어야 합니다.
녹색 선은 활성 경로이지만 해당 경로의 IO가 SnapMirror 활성 동기화 경로를 통해 전달되어야 하기 때문에 지연 시간이 더 많이 발생합니다. 추가 지연 시간은 SnapMirror 활성 동기화에 사용되는 사이트 간 상호 연결의 속도에 따라 달라집니다.
실패
계획되거나 계획되지 않은 페일오버 때문에 액티브 미러 복사본을 사용할 수 없게 되면 더 이상 사용할 수 없게 됩니다. 그러나 원격 시스템에는 동기식 복제본이 있고 원격 사이트에 대한 SAN 경로가 이미 존재합니다. 원격 시스템에서 해당 LUN에 대한 IO를 처리할 수 있습니다.
페일오버
페일오버하면 원격 복제본이 활성 복제본이 됩니다. 경로가 Active에서 Active/Optimized로 변경되고 IO는 데이터 손실 없이 계속 처리됩니다.
복구
소스 시스템이 서비스로 반환되면 SnapMirror 활성 동기화는 복제를 다시 동기화하지만 다른 방향을 실행할 수 있습니다. 이제 이 구성은 기본적으로 시작점과 동일하지만 활성 미러 사이트가 대칭 이동된 경우는 예외입니다.
장애 복구
필요한 경우 관리자는 페일백을 수행한 후 LUN의 활성 복사본을 원래 컨트롤러로 다시 이동할 수 있습니다.