SnapMirror 액티브 동기화는 재해 복구 사이트에서 데이터의 동기식 복제본을 제공하지만, 해당 데이터를 사용하려면 운영 체제와 관련 애플리케이션이 필요합니다. 기본 자동화를 통해 전체 환경의 장애 조치 시간을 크게 개선할 수 있습니다. Pacemaker와 같은 Clusterware 제품은 사이트 전체에 클러스터를 생성하는 데 자주 사용되며, 대부분의 경우 간단한 스크립트로 장애 조치 프로세스를 구동할 수 있습니다.

운영 노드가 손실되면 클러스터웨어(또는 스크립트)가 대체 사이트에서 데이터베이스를 온라인으로 전환합니다. 한 가지 옵션은 데이터베이스를 구성하는 SAN 리소스에 대해 미리 구성된 대기 서버를 만드는 것입니다. 운영 사이트에 장애가 발생하면 클러스터웨어 또는 스크립트된 대체 시스템이 다음과 유사한 일련의 작업을 수행합니다.

이 방법의 주요 요구 사항은 원격 사이트에서 실행 중인 OS입니다. Oracle 바이너리로 사전 구성되어야 합니다. 즉, Oracle 패치 적용과 같은 작업이 운영 및 대기 사이트에서 수행되어야 합니다. 또는 재해가 선언된 경우 Oracle 바이너리를 원격 사이트로 미러링하고 마운트할 수 있습니다.

실제 활성화 절차는 간단합니다. LUN 검색과 같은 명령은 FC 포트당 몇 개의 명령만 사용하면 됩니다. 파일 시스템 마운팅은 명령에 불과하며 mount, 단일 명령으로 CLI에서 데이터베이스와 ASM을 모두 시작하고 중지할 수 있습니다.

데이터베이스 환경의 페일오버는 운영 체제 자체를 포함하도록 확장할 수 있습니다. 이론적으로 이 페일오버는 부팅 LUN에서 수행할 수 있지만 대부분의 경우 가상화된 OS에서 수행됩니다. 절차는 다음 단계와 유사합니다.

예를 들어, ESX 클러스터가 사이트에 걸쳐 있을 수 있습니다. 재해 발생 시 전환 후 재해 복구 사이트에서 가상 시스템을 온라인으로 전환할 수 있습니다.

위의 다이어그램은 "비균일 액세스"SAN이 사이트 간에 확장되지 않는 의 사용을 보여 줍니다. 이 방법은 구성이 더 간단할 수 있으며 경우에 따라 현재 SAN 기능을 고려할 때 유일한 옵션이 될 수도 있지만 이는 또한 운영 스토리지 시스템의 장애로 인해 애플리케이션이 페일오버될 때까지 데이터베이스가 중단된다는 것을 의미합니다.

복원력을 높이기 위해 이 솔루션을 과 함께 구축할 수 "균일한 액세스"있습니다. 이렇게 하면 반대쪽 사이트에서 알리는 경로를 사용하여 응용 프로그램이 계속 작동할 수 있습니다.