출처: https://community.netapp.com/t5/Tech-ONTAP-Blogs/Symmetric-active-active-Oracle-clustering-with-ONTAP/ba-p/451314
특별한 기술적 설명 보다는, Oracle RAC 환경에서 Active-Active 모드의 SnapMirror Activ Sync가 잘 동작한다는 예를 보여주는 것 같습니다.
액티브-액티브 데이터 센터(Oracle 포함!)
저는 15년 넘게 Oracle 고객과 DR 솔루션을 협력해 왔습니다. 물론 완벽한 솔루션은 RPO=0과 RTO=0이겠지만, 모든 애플리케이션이 RPO=0 동기식 솔루션에서 발생하는 쓰기 지연 시간을 감당할 수 있는 것은 아닙니다. 경우에 따라 15분의 RPO나 그보다 약간 더 긴 RTO로 만족해야 할 수도 있습니다.
하지만 때로는 데이터가 정말 중요하기 때문에 RPO=0 및 RTO=0이 필요합니다.
한동안 SnapMirror active sync(이전 명칭: SnapMirror Business Continuity)를 통해 이 기능을 구현할 수 있었지만, 이제는 대칭적인 액티브-액티브(symmetric active-active) 모드로 구현할 수 있습니다. 이제 완전히 다른 두 사이트에 두 개의 클러스터를 구성하여 각각 동일한 성능 특성을 가진 데이터를 제공할 수 있으며, 사이트 간에 SAN을 확장할 필요도 없습니다.
이것이 고객들이 “액티브-액티브 데이터 센터”라고 부르는 시스템의 기반입니다. 기본 사이트와 재해 복구 사이트는 없습니다. 두 개의 사이트만 있습니다. 데이터베이스의 절반은 사이트 A에서, 나머지 절반은 사이트 B에서 실행됩니다. 각 로컬 스토리지 시스템은 로컬 데이터 복사본에서 모든 읽기 I/O를 처리합니다. 쓰기 I/O는 물론, 확인되기 전에 반대쪽 사이트에 복제됩니다. 이는 동기식 미러링의 작동 방식과 유사합니다. 대칭형 스토리지 I/O는 데이터베이스 응답과 애플리케이션 동작이 대칭적임을 의미합니다.
SnapMirror 액티브-액티브 모드의 액티브 싱크는 현재 일부 고객에게 기술 프리뷰로 제공됩니다. Oracle RAC는 아직 지원되는 구성은 아니지만, 기술적으로 작동하지 않을 이유는 없습니다. 이 기능이 정식 출시될 때를 대비하고 싶었습니다. 지난 몇 주 동안 전원과 네트워크 연결을 끊었지만, 아직 데이터베이스가 손상되지 않았습니다.
참고: 복구 절차가 필요한지 판단하는 데 일정 시간이 걸리기 때문에 RTO=0이라는 것은 사실상 불가능합니다. 단일 I/O 작업이 1초 안에 완료되지 않았다고 해서 전체 재해 복구(failover)가 발생하는 것은 바람직하지 않습니다. SnapMirror 액티브 싱크는 이미 상대 사이트에서 운영되고 있기 때문에 RTO=0 솔루션이라고 생각합니다 . 작업 재개 지연은 장애 복구 자체 때문이 아니라, 자동화된 환경에서도 장애 복구가 필요한지 확인하는 데 최소 15~30초가 걸리는 경우가 있습니다.
3번째 사이트 Oracle RAC 타이브레이커를 사용하거나 사용하지 않는 참조 아키텍처를 개발하고 있으며, 관련 동영상도 몇 개 공개할 계획입니다. 작동 방식을 간략하게 설명드리겠습니다. 다이어그램을 살펴보고 계속 읽어 보시면 그 가치를 이해하실 수 있을 것입니다.
구조
이는 NTAP이라는 데이터베이스와 NTAP1, NTAP2라는 두 개의 인스턴스를 사용하는 일반적인 Oracle RAC 구성입니다. 다이어그램은 처음에는 복잡해 보일 수 있지만, 이해하는 데 도움이 되는 핵심 사항은 다음과 같습니다.
SnapMirror Active Sync가 보이지 않습니다.
Oracle과 호스트 관점에서 보면 이는 단일 클러스터에 있는 LUN 세트 하나일 뿐입니다. 복제는 눈에 보이지 않습니다. 두 사이트에 동일한 LUN 세트가 있습니다. SAN을 여러 사이트로 확장하지도 않았지만, 원한다면 그렇게 할 수도 있었습니다. 굳이 그럴 필요가 없다면 사이트 간 ISL을 생성하지 않는 것이 좋습니다.
RAC를 설치했을 때, 쿼럼 관리에 사용할 LUN이 각각 3개씩 있는 호스트가 두 대 있었습니다. 이 호스트들(jfs12와 jfs13)은 모두 동일한 일련 번호와 동일한 데이터를 가진 동일한 LUN을 사용합니다.
데이터베이스를 생성할 때 데이터 파일용 8-LUN ASM 디스크 그룹과 로그용 8-LUN ASM 디스크 그룹을 생성했습니다. 어떤 호스트를 사용하여 데이터베이스를 생성하든 상관없습니다. 두 호스트 모두 동일한 LUN을 사용하고 있습니다.
두 개의 서로 다른 사이트에 경로가 존재하는 단일 시스템으로 생각해 보세요. 두 클러스터 중 어느 경로든 동일한 LUN으로 연결됩니다.
SnapMirror Active Sync는 대칭적입니다.
이제 두 인스턴스 모두에 데이터베이스 연결을 설정할 수 있습니다. 해당 인스턴스가 읽기 작업을 수행해야 하는 경우, 데이터는 로컬 드라이브에서 검색됩니다. 쓰기 작업은 확인되기 전에 반대 사이트에 복제되므로 사이트 간 지연 시간은 최대한 짧아야 합니다.
어떤 사이트를 사용하든 상관없습니다. 의도적으로 성능 한계가 다른 여러 컨트롤러 모델을 사용하지 않는 한 데이터베이스 성능은 동일합니다. 이는 타당한 선택입니다. RPO=0/RTO=0을 원하지만, 사이트 중 하나는 임시 사이트로 설계되어 다른 사이트와 동일한 저장 용량을 필요로 하지 않을 수 있습니다.
SnapMirror Active Sync는 복원력이 뛰어납니다.
이 부분은 아직 문서화 작업 중입니다. 컨트롤러 장애를 감지하는 하트비트 역할을 하는 중재자 서비스가 있습니다. 중재자는 활성 타이브레이커 서비스는 아니지만, 동일한 개념입니다. 각 클러스터가 상대 클러스터의 상태를 확인하기 위한 대체 통신 채널 역할을 합니다. 예를 들어, 사이트 B의 클러스터에 갑자기 장애가 발생하면 사이트 A의 클러스터는 직접 또는 중재자를 통해 클러스터 B에 연결할 수 없게 됩니다. 이를 통해 클러스터 A는 미러링을 해제하고 작업을 재개할 수 있습니다.
전반적으로 “그냥 잘 됩니다”. 예를 들어, 제가 처음 테스트한 것은 한 사이트의 전원을 끄는 것이었습니다. 결과는 다음과 같습니다.
- 한 세트의 경로는 응답을 중단했지만 다른 세트의 경로는 계속 사용 가능했습니다.
- 더 이상 쓰기를 복제할 수 없기 때문에 모든 쓰기 IO가 일시 중지되었습니다.
- 약 30초 후, 살아남은 사이트는 정전이 발생한 사이트가 실제로 죽은 것으로 간주하고 미러링을 중단하여 살아남은 사이트가 작업을 재개할 수 있도록 했습니다.
- 장애가 발생한 사이트의 Oracle 인스턴스는 무려 200초 동안 스토리지 접속을 시도했습니다. 이는 RAC의 기본 시간 초과 설정입니다. 필요한 경우 변경할 수 있습니다.
- 200초가 지난 후, Oracle 인스턴스는 자체 재부팅을 수행했습니다. 이는 호스트에서 재시도 루프에 갇힌 IO 작업으로 인해 데이터가 손상되는 것을 방지하기 위한 것입니다.
- 이는 장애가 발생한 노드에서 중단된 트랜잭션이 정상 작동 중인 노드에서 다시 실행되기 전에 200초 동안 보류되었음을 의미합니다. 이는 스토리지 시스템의 RTO(복구 시간 목표)가 장애 조치 시간에 영향을 미치는 유일한 요인이 아님을 보여주는 좋은 예입니다.
복구 프로세스는 예상치 못하게 원활하게 진행되었습니다.
- 고장난 저장 시스템에 전원이 복구되었습니다.
- 전원을 완전히 켜고 자체 테스트하고 부팅하고 클러스터 작업을 재개하는 데 약 8분이 걸렸습니다.
- 살아남은 사이트는 다른 사이트의 귀환을 감지했습니다.
- 미러는 사이트 A와 사이트 B의 상태를 매우 가깝게 맞추기 위해 비동기식으로 재동기화되었습니다. 이 작업에는 약 5분이 걸렸습니다.
- 그런 다음 미러는 동기화 상태로 전환되었습니다.
- Oracle 서버에서 SAN 경로의 존재를 감지했습니다.
- 부팅 프로세스를 지연시키고 있던 Oracle RAC 프로세스가 사용 가능한 RAC 쿼럼 장치를 찾았습니다.
- 데이터베이스 인스턴스가 다시 나타났습니다.
예상치 못한 놀라움이었습니다. 복구 작업이 더 필요할 거라고 생각했는데, 그냥 “전원 다시 켜기”만 하면 모든 게 정상으로 돌아왔습니다.
할 일이 더 많은데, 다양한 작업의 타이밍 파악, 로그 수집, RAC 튜닝, 특히 Oracle RAC 쿼럼 동작 기록 등이 있습니다. 복잡하지는 않지만, Oracle에서 제대로 문서화되어 있지는 않습니다.
ONTAP의 다음 버전이 출시되면 더 많은 기능을 만나볼 수 있을 것입니다.
