NetApp Tech Blog에 갔다가 흥미로운 주제의 글이 보여서 AI 번역(+약간 수정)의 힘을 빌려 읽어보았습니다.

출처: https://community.netapp.com/t5/Tech-ONTAP-Blogs/SnapMirror-active-sync-and-the-active-active-data-center/ba-p/455156

SnapMirror 액티브 싱크와 액티브-액티브 데이터 센터

저는 약 1년 동안 연구실에서 SnapMirror 액티브 싱크를 열심히 사용해 왔는데, ONTAP에 추가된 기능 중 몇 년 만에 가장 멋진 기능이라고 말씀드리고 싶습니다. 특히, 대칭적인 액티브-액티브 모드로 실행되는 SnapMirror 액티브 싱크에 대해 이야기하고 있습니다. 진정한 가치는 기능 자체에 있는 것이 아니라, 이 기능을 통해 구축할 수 있는 솔루션 종류에 있습니다. SnapMirror 액티브 싱크의 기반은 SnapMirror 동기식이며, 훨씬 오래전부터 사용되어 왔고 검증도 잘 되어 있지만, 액티브-액티브 기능을 사용하기 시작한 것은 불과 1년 전입니다.

SnapMirror 액티브 싱크를 구성하는 방법은 여러 가지가 있지만, 여기서는 액티브-액티브 애플리케이션 환경에 대해 중점적으로 살펴보겠습니다. Oracle RAC, VMware, Windows Server 장애 조치 클러스터(WSFC) 등 애플리케이션 클러스터가 두 사이트에 분산되고 IO 응답 ​​시간이 대칭적인 클러스터 환경을 구축할 수 있습니다. 동기식 크로스 사이트 미러링을 통해 RPO=0을 달성하고, 내장된 ONTAP 자동화를 통해 RTO=0을 달성하며, 두 사이트 모두에서 스토리지 리소스를 항상 사용할 수 있습니다.

이 글은 동기식 복제 솔루션을 고려하는 모든 사람에게 유용할 것입니다. 하지만 Oracle RAC를 사용하여 SnapMirror 액티브 동기화 기능을 설명하겠습니다. 애플리케이션 계층부터 스토리지 계층까지 전체 솔루션의 RTO=0 및 RPO=0 특성을 살펴볼 수 있기 때문입니다. 두 사이트 모두에서 동일한 데이터베이스가 항상 작동합니다. 재해 발생 시 미러가 손상될 수 있지만, 서비스는 항상 정상 운영되는 사이트에서 실행 중이었기 때문에 실제로 장애 조치는 이루어지지 않습니다.

사용된 예시는 Oracle RAC일 수 있지만, 그 원칙은 보편적입니다. 여기에는 “선호 사이트(preferred site)”, 하트비트, 타이브레이킹, 타임아웃과 같은 개념이 포함됩니다. Oracle RAC에 대해 거의 모르더라도 계속 읽어보세요.

SnapMirror Active Sync(SM-as)의 작동 방식에 대한 자세한 내용을 살펴보기에 앞서, SnapMirror Active Sync(SM-as)의 용도에 대해 설명하고 싶습니다.

RPO=0

IT 업계에 종사하신다면 Recovery Point Objective에 대해 들어보셨을 겁니다. 특정 이벤트 발생 시 얼마나 많은 데이터 손실을 감당할 수 있을까요? 동기식 복제의 경우 RPO=0을 의미하지만, 생각보다 훨씬 미묘한 개념입니다. 저는 RPO=0에 대한 요구 사항을 볼 때 보통 두 가지 범주로 나눕니다.

• 일반적인 문제에 대한 RPO
• 재난 시나리오에 대한 RPO

일반적인 문제에 대해 RPO=0을 설정하는 것은 비교적 쉽습니다. 예를 들어 데이터베이스가 있다면 가끔씩 복구가 필요할 수 있습니다. 패치가 잘못되어 손상되었거나 누군가 잘못된 파일을 삭제했을 수도 있습니다. 일반적으로 RAID로 보호되는 스토리지와 기본적인 백업 계획만 있으면 데이터 손실 없이 데이터베이스를 복원하고, 로그를 재생하고, 문제를 해결할 수 있습니다. 이러한 일반적인 문제에 대해 RPO=0 복구 가능성을 기대할 수 있으며, ONTAP을 선택하면 절차를 더 쉽고 빠르며 저렴하게 수행할 수 있습니다. 

재해 발생 시 RPO=0을 원하면 상황은 더욱 복잡해집니다. 예를 들어 악의적인 내부자가 데이터와 백업 데이터를 파괴하려고 한다면 어떻게 해야 할까요? 적절한 기술과 솔루션을 활용하여 완전히 다른 접근 방식이 필요합니다. 저희는 이러한 분야에서 훌륭한 솔루션을 제공합니다.

SnapMirror 액티브 싱크는 사이트 손실로 이어지는 재해 시나리오에 대해 RPO=0을 보장합니다. 화재로 인한 영구적인 사이트 손실일 수도 있고, 정전으로 인한 일시적인 손실일 수도 있습니다. 스토리지 어레이를 파괴하는 전력 서지처럼 더 고립된 상황일 수도 있습니다. SM-as는 동기식 미러링을 통해 이러한 시나리오를 해결합니다. 단순히 RPO=0 복제가 아니라, 자가 복구 기능을 갖춘 통합 지능형 ​​RPO=0 복제 솔루션입니다.

RTO=0

RPO=0 요건은 종종 Recovery Time Objective (RTO) 0 요건과 함께 적용됩니다. RTO는 서비스를 받지 못할 수 있는 시간을 의미하며, 전반적으로 이해하기 쉬운 SLA입니다. 단, RTO=0이라는 예외가 있습니다. RTO=0은 무슨 뜻일까요?

IT 업계 전반에 걸쳐 “RTO=0″이라는 용어가 있습니다. 저는 RTO=0이라는 개념은 없다고 계속 주장합니다. RTO=0이라는 개념은 존재하지 않습니다. RTO=0이라는 개념은 문제가 있음을 즉시 인식하고 즉시 수정하여 서비스를 복구해야 합니다. 하지만 이는 불가능합니다. 스토리지 관점에서 볼 때, LUN 응답을 위해 10밀리초 동안 대기하는 것이 스토리지 시스템이 다른 I/O 작업으로 인해 바쁜 것인지, 아니면 데이터 센터 자체가 블랙홀에 빠져 더 이상 존재하지 않는 것인지 알 수 있는 방법이 없습니다.

RTO가 0일 수는 없지만, IT 운영 관점에서는 거의 0에 가까운 RTO를 가질 수 있습니다. “거의 0″에 대한 정확한 정의는 비즈니스 요구에 따라 달라집니다. RTO가 충분히 낮아 운영에 큰 영향을 미치지 않으면 업계에서는 RTO가 0이라고 합니다. 즉, “무중단”을 의미합니다.

모든 RTO가 스토리지 가용성만으로 결정되는 것은 아닙니다. 예를 들어, 일반적인 ONTAP 컨트롤러 장애 조치는 약 2~4초 안에 완료되며 이 시간 동안 SAN IO가 일시 중지됩니다. 그러나 OS의 시간 초과는 훨씬 더 긴 경우가 많습니다. ONTAP은 2초 안에 장애 조치를 취하고 다시 데이터를 제공할 준비가 완전히 되지만, 호스트가 IO를 재시도하기 전에 15초 동안 기다리는 경우가 있으며 이를 변경할 수 없습니다. OS 공급업체는 수년에 걸쳐 SAN 동작을 최적화해 왔지만 완벽하지는 않습니다. 드물지만 실제로 발생하고 때로는 긴 IO 시간 초과는 이미 SAN에서 가끔 발생하고 있을 것입니다. 케이블이 약간 손상되어 FC 프레임이 누락되는 경우도 있으며, 이는 짧은 성능 저하를 초래할 수 있습니다. 그러나 실제 문제를 일으키지는 않습니다. 아무것도 충돌하지 않을 것입니다.

SM은 장애 조치 작업으로서 재해를 포함한 지속적인 IT 작업을 방해하지 않아야 하므로, 업계에서 RTO라는 용어를 사용하는 방식이기 때문에 SM을 RTO=0 스토리지 솔루션이라고 부르겠습니다. 

하지만 애플리케이션 계층에 대해서는 여전히 고민해야 합니다. 예를 들어, VMware 클러스터를 여러 사이트에 분산하고 SM-as를 사용하여 기본 스토리지를 복제할 수 있지만, 특정 사이트에 장애가 발생하면 VMware HA가 해당 VM의 손실을 감지하고 정상 작동하는 사이트에서 다시 시작해야 합니다. 이 작업에는 시간이 걸립니다. 이러한 요구 사항이 RTO를 충족합니까? VM을 충분히 빠르게 시작할 수 없다면 컨테이너화를 고려할 수 있습니다. 컨테이너화의 장점 중 하나는 컨테이너를 거의 즉시 활성화할 수 있다는 것입니다. OS 부팅 시퀀스가 ​​없습니다. 이는 전반적인 RTO를 개선하는 옵션이 될 수 있습니다. 마지막으로, Oracle RAC와 같은 진정한 액티브-액티브 애플리케이션을 사용하는 경우 두 사이트에서 항상 동일한 데이터베이스를 사전에 실행할 수 있습니다. 적합한 솔루션은 RTO와 장애 조치(failover) 발생 시 전체 솔루션의 동작에 따라 달라집니다.

스토리지 관점에서 볼 때, 거의 0에 가까운 RTO를 달성하는 것은 생각보다 훨씬 더 복잡합니다. 한 사이트는 다른 사이트가 활성 상태인지 어떻게 알 수 있을까요? 쓰기 작업을 복제할 수 없는 경우 어떻게 해야 할까요? 스토리지 시스템은 영구적으로 오프라인 상태인 복제 파트너와 일시적으로만 접속할 수 있는 파트너의 차이를 어떻게 구분할까요? 호스트가 액세스하고 있지만 더 이상 최신 데이터 사본을 제공할 수 없다고 보장할 수 없는 LUN은 어떻게 해야 할까요? 복제가 복구되면 어떻게 될까요?

다이어그램으로 넘어가겠습니다…

SnapMirror 액티브 싱크 아키텍처

SM-as 복제가 어떻게 작동하는지 기본적인 내용부터 살펴보겠습니다 .

이는 다음을 보여줍니다.

• 두 개의 서로 다른 스토리지 클러스터입니다. 하나는 Cluster1이고 다른 하나는 Cluster2입니다. (jfs_as1과 jfs_as2에 대한 설명은 잠시 후에 설명하겠습니다…)
• LUN이 6개처럼 보일 수 있지만 논리적으로는 3개뿐입니다.
• 그 이유는 서로 다른 LUN 이미지가 6개 있지만, 각 jfs_as1의 LUN1은 jfs_as2의 LUN1과 기능적으로 동일하고, LUN2도 동일하고, LUN3도 동일하기 때문입니다.
• 호스트 관점에서 보면 이는 일반적인 SAN 멀티패스처럼 보입니다. LUN1과 해당 데이터는 두 클러스터 모두에서 사용 가능하고 액세스할 수 있습니다.
• IO 동작과 IO 성능은 대칭적입니다.
  • 사이트 A의 클러스터에서 LUN1 읽기를 수행하는 경우 읽기는 사이트 A의 로컬 데이터 복사본에 의해 처리됩니다.
  • 사이트 B의 클러스터에서 LUN1 읽기를 수행하는 경우 읽기는 사이트 B의 로컬 데이터 복사본에 의해 처리됩니다.
  • LUN1에 쓰기 작업을 수행하려면 쓰기가 확인되기 전에 반대 사이트에 쓰기 작업을 복제해야 합니다.

이제 장애 조치 에 대해 살펴보겠습니다 . 여기에는 중재자라는 또 다른 구성 요소가 있습니다.

메디에이터는 장애 조치를 안전하게 자동화하는 데 필수적입니다. 이상적으로는 독립적인 제 3 사이트에 배치하는 것이 좋지만, 사이트 A 또는 사이트 B에 배치하더라도 대부분의 요구 사항을 충족할 수 있습니다. 메디에이터는 사실상 타이브레이커 역할을 하는 것은 아니지만, 사실상 타이브레이커 역할을 하는 것입니다. 메디에이터는 어떠한 조치도 취하지 않고 스토리지 시스템에 대체 통신 채널을 제공합니다.

자동 장애 조치의 가장 큰 과제는 스플릿 브레인 문제이며, 이 문제는 두 사이트 간의 연결이 끊어지면 발생합니다. 어떻게 해야 할까요? 두 개의 서로 다른 사이트가 데이터의 생존 복사본으로 스스로 활성화되는 것은 바람직하지 않습니다. 하지만 한 사이트가 상대 사이트의 실제 손실과 통신 불능을 어떻게 구분할 수 있을까요?

여기서 중재자가 개입합니다. 세 번째 사이트에 배치되고 각 사이트가 해당 사이트에 별도의 네트워크 연결을 가지고 있다면, 각 사이트가 다른 사이트의 상태를 검증할 수 있는 추가 경로가 생깁니다. 위 그림을 다시 보고 다음 시나리오를 고려해 보세요.

• 중재자가 실패하거나 한쪽 또는 양쪽 사이트에서 연락이 불가능한 경우 어떻게 되나요?
  • 두 클러스터는 복제 서비스에 사용되는 동일한 링크를 통해 여전히 서로 통신할 수 있습니다.
  • 데이터는 여전히 RPO=0 보호로 제공됩니다.
• 사이트 A에 장애가 발생하면 어떻게 되나요?
  • 사이트 B에서는 파트너 스토리지 시스템과의 두 가지 통신 채널이 모두 중단됩니다.
  • 사이트 B는 RPO=0 미러링 없이 데이터 서비스를 인수합니다.
• 사이트 B에 장애가 발생하면 어떻게 되나요?
  • 사이트 A에서는 파트너 스토리지 시스템과의 두 가지 통신 채널이 모두 중단됩니다.
  • 사이트 A는 RPO=0 미러링 없이 데이터 서비스를 인수합니다.

고려해야 할 또 다른 시나리오가 있습니다. 데이터 복제 링크 손실입니다. 사이트 간 복제 링크가 손실되면 RPO=0 미러링은 당연히 불가능해집니다. 그러면 어떻게 될까요?

이는 선호 사이트 상태에 따라 제어됩니다. SM-as 관계에서 두 사이트 중 하나는 다른 사이트에 대해 보조적인 역할을 합니다. 이는 일반적인 작업에는 영향을 미치지 않으며 모든 데이터 액세스는 대칭적입니다. 하지만 복제가 중단되면 작업을 재개하려면 연결을 끊어야 합니다. 결과적으로 선호 사이트는 미러링 없이 작업을 계속하고 보조 사이트는 복제가 다시 설정될 때까지 IO 처리를 중단합니다. 이 주제에 대한 자세한 내용은 아래를 참조하십시오.

SnapMirror 액티브 싱크를 사용한 SAN 디자인

위에서 설명했듯이 SM-as는 기능적으로 두 개의 서로 다른 클러스터에 동일한 LUN을 제공합니다. 그렇다고 해서 호스트가 모든 사용 가능한 경로를 통해 LUN에 액세스해야 한다는 의미는 아닙니다. 필요할 수도 있고, 그렇지 않을 수도 있습니다. 균일(uniform) 액세스와 비균일(non-uniform) 액세스라는 두 가지 기본 옵션이 있습니다.

균일한 접근

단일 호스트 가 있고 RPO=0, RTO=0의 데이터 보호를 원한다고 가정해 보겠습니다 . SM-as를 균일한 액세스로 구성하면 LUN이 두 클러스터 모두에서 호스트에 표시될 수 있습니다.

물론, 이는 사이트 A의 완전한 손실로 인해 호스트와 애플리케이션도 손실되지만, 데이터를 위한 매우 높은 가용성의 스토리지 서비스를 확보하게 됩니다. 이는 SM-as의 덜 일반적인 사용 사례일 수 있지만, 실제로 발생하는 사례입니다. 모든 애플리케이션을 클러스터링할 수 있는 것은 아닙니다. 때로는 고가용성 스토리지를 제공하고 재해 발생 시 원격 사이트에서 대체 서버를 찾아야 한다는 사실을 받아들이는 것 외에는 할 수 있는 일이 없습니다.

균일한 접근이 가능한 또 다른 옵션은 풀 메시 네트워크 클러스터입니다.

위에 표시된 것처럼 클러스터에서 균일한 액세스 권한을 가진 SM-as를 사용하면 모든 호스트가 항상 사용 가능한 데이터 사본에 액세스할 수 있습니다. 스토리지 시스템 중 하나에 장애가 발생하거나 스토리지 복제 연결이 끊어지더라도 호스트는 계속 작동합니다. 호스트 다중 경로 관점에서는 모든 것이 단일 스토리지 시스템처럼 보입니다. 어느 한 구성 요소에 장애가 발생하면 일부 SAN 경로가 네트워크에서 사라지지만, 그 외에는 모든 것이 정상적으로 작동합니다.

지역 근접성을 갖춘 균일한 접근

SM-as의 또 다른 기능은 스토리지 시스템에 호스트의 위치를 ​​알릴 수 있는 옵션입니다. LUN을 특정 호스트에 매핑할 때, 해당 LUN이 스토리지 시스템에 로컬인지 여부를 지정할 수 있습니다.

정상 작동 시 모든 IO는 로컬 IO입니다. 읽기 및 쓰기는 로컬 스토리지 어레이에서 처리됩니다. 물론 쓰기 IO는 로컬 컨트롤러에서 원격 시스템으로 복제된 후 확인되어야 하지만, 모든 읽기 IO는 로컬에서 처리되므로 SAN을 통과할 때 추가 지연 시간이 발생하지 않습니다.

최적화되지 않은 경로는 모든 활성/최적화 경로가 손실될 때만 사용됩니다. 예를 들어, 사이트 A의 전체 어레이에 전원이 공급되지 않더라도 사이트 A의 호스트는 계속 작동할 수 있지만, 읽기 지연 시간이 길어집니다.

참고: 단순화를 위해 이 다이어그램에는 로컬 클러스터를 통과하는 중복 경로가 표시되지 않았습니다. ONTAP 스토리지 시스템 자체가 HA(가용성)를 지원하므로 컨트롤러 장애가 사이트 장애로 이어지지 않습니다. 단순히 영향을 받는 호스트에서 사용하는 로컬 경로가 변경되는 것뿐입니다.

비균일한 접근

비균일한 액세스란 각 호스트가 사용 가능한 포트의 하위 집합에만 액세스할 수 있다는 것을 의미합니다.

이 접근 방식의 주요 이점은 SAN의 단순성입니다. 네트워크 전체에 SAN을 확장할 필요가 없습니다. 일부 사용자는 사이트 간에 다크 파이버가 없거나 IP 네트워크를 통해 FC SAN 트래픽을 터널링할 인프라가 부족합니다. 경우에 따라 애플리케이션이 여러 사이트의 스토리지에 정기적으로 액세스하는 데 따른 추가적인 지연 시간 오버헤드가 용납될 수 없으므로, 균일한 액세스의 가용성 향상이 불필요해질 수 있습니다.

비균일 액세스의 단점은 복제 링크 손실을 포함한 특정 장애 시나리오에서 호스트의 절반이 스토리지에 액세스할 수 없게 된다는 것입니다. 특정 마운트에서 단일 호스트에서만 실행되는 비클러스터형 데이터베이스와 같이 단일 인스턴스로 실행되는 애플리케이션은 로컬 스토리지 연결이 끊어지면 실패합니다. 데이터는 여전히 보호되지만 데이터베이스 서버는 더 이상 액세스할 수 없습니다. 원격 사이트에서 자동화된 프로세스를 통해 다시 시작해야 합니다. 예를 들어 VMware HA는 모든 경로가 다운된 상황을 감지하고 경로를 사용할 수 있는 다른 서버에서 VM을 다시 시작할 수 있습니다. 반면 Oracle RAC와 같은 클러스터형 애플리케이션은 두 사이트에서 모두 지속적으로 실행되는 동일한 서비스를 제공할 수 있습니다. Oracle RAC가 있는 사이트가 손실된다고 해서 애플리케이션 서비스 전체가 손실되는 것은 아닙니다. 인스턴스는 여전히 사용 가능하며 손상된 사이트에서 실행 중입니다. 

ASA와의 통일된 접근

위 다이어그램은 AFF 스토리지 시스템의 경로 우선순위 지정을 보여줍니다. NetApp ASA 시스템은 SM-as를 포함하여 액티브-액티브 다중 경로 지정을 제공합니다. 다음 다이어그램을 살펴보겠습니다.

비균일 접속을 사용하는 ASA 구성은 AFF와 거의 동일하게 작동합니다. 균일 접속을 사용하면 IO가 WAN을 통과하게 됩니다. 이는 바람직할 수도 있고 바람직하지 않을 수도 있습니다. 두 사이트가 광섬유 연결을 통해 100미터 떨어져 있다면 WAN을 통과하는 추가 지연 시간은 감지할 수 없지만, 사이트가 멀리 떨어져 있다면 두 사이트 모두 읽기 성능이 저하됩니다. 반면 AFF에서는 이러한 WAN 통과 경로는 사용 가능한 로컬 경로가 없는 경우에만 사용되므로 읽기 성능이 향상됩니다.

저지연 구성에서 SM-as를 사용하는 ASA는 두 가지 흥미로운 이점을 제공합니다. 첫째, 두 배 더 많은 컨트롤러와 두 배 더 많은 경로를 사용하여 IO를 처리할 수 있으므로 단일 호스트의 성능이 기본적으로 두 배로 향상됩니다. 둘째, 전체 스토리지 시스템이 손실되더라도 호스트 액세스가 중단되지 않으므로 뛰어난 가용성을 제공합니다.

SnapMirror 액티브 싱크 대 MetroCluster

NetApp에 ​​대해 잘 아시는 분들은 SM-as의 사촌 격인 MetroCluster도 알고 계실 겁니다. SM-as는 전반적인 기능 면에서 NetApp MetroCluster와 유사하지만, RPO=0 복제 구현 방식과 관리 방식에 중요한 차이점이 있습니다.

• MetroCluster 구성은 여러 사이트에 분산된 노드를 갖춘 하나의 통합 클러스터와 유사합니다. SM-as는 지정된 RPO=0으로 동기 복제된 LUN에서 데이터를 제공하는 두 개의 독립적인 클러스터처럼 동작합니다.
• MetroCluster 구성의 데이터는 특정 시점에 특정 사이트에서만 액세스할 수 있습니다. 반대쪽에도 두 번째 데이터 사본이 있지만, 해당 데이터는 수동적입니다. 스토리지 시스템 장애 조치 없이는 액세스할 수 없습니다.
• MetroCluster와 SM-as 미러링은 서로 다른 수준에서 수행됩니다. MetroCluster 미러링은 RAID 계층에서 수행됩니다. 하위 수준 데이터는 SyncMirror를 사용하여 미러링된 형식으로 저장됩니다. LUN, 볼륨 및 프로토콜 계층에서는 미러링 사용 여부가 거의 감지되지 않습니다.
• 반면, SM-as 미러링은 프로토콜 계층에서 발생합니다. 두 클러스터는 전체적으로 독립적인 클러스터입니다. 두 데이터 사본이 동기화되면 두 클러스터는 쓰기 작업만 미러링하면 됩니다. 한 클러스터에서 쓰기가 발생하면 다른 클러스터로 복제됩니다. 쓰기 작업은 두 사이트 모두에서 완료되어야 호스트에 확인 응답됩니다. 이러한 프로토콜 분할 동작을 제외하면 두 클러스터는 일반적인 ONTAP 클러스터와 같습니다.
• MetroCluster의 가장 큰 장점은 대규모 복제입니다. RPO=0과 RTO=0에 가까운 전체 어레이를 복제할 수 있습니다. 이렇게 하면 장애 조치할 “대상”이 하나뿐이므로 장애 조치 프로세스가 간소화되고 용량 및 IOPS 측면에서 확장성이 매우 뛰어납니다.
• SM-as의 첫 번째 장점은 세분화된 복제입니다. 스토리지 시스템의 모든 데이터를 단일 단위로 복제하고 싶지 않거나 특정 워크로드에 대해 선택적으로 장애 조치를 수행해야 하는 경우가 있습니다.
• SM-as의 두 번째 장점은 액티브-액티브(active-active) 운영에 적합합니다. 이는 완전히 사용 가능한 데이터 사본을 두 개의 서로 다른 위치에 있는 동일한 성능 특성을 가진 두 개의 클러스터에 저장하고, 필요한 경우 SAN을 여러 사이트로 확장할 필요가 없는 경우에 유용합니다. 두 사이트 모두에서 애플리케이션을 이미 실행 중인 상태로 유지할 수 있으므로 장애 조치(failover) 작업 시 전체 RTO가 단축됩니다.

SnapMirror 액티브 싱크 설정

다음 섹션에서는 Oracle RAC 구성에 중점을 두지만, 개념은 대부분의 SnapMirror 액티브 싱크 배포에 적용할 수 있습니다. Oracle RAC는 본질적으로 복잡하기 때문에 Oracle RAC를 예로 들어 설명하는 것이 특히 유용합니다. SM-as에서 Oracle RAC를 구성하고 관리하는 방법, 모든 세부 사항, 요구 사항, 특히 ONTAP이 이러한 구성에 제공하는 이점을 이해한다면 모든 워크로드에 SM-as를 사용할 수 있을 것입니다.

또한, ONTAP 구성에는 CLI를 사용할 예정이지만, SystemManager GUI를 사용할 수도 있습니다. 정말 훌륭하다고 생각합니다. UI 팀은 SnapMirror Active Sync를 훌륭하게 구현해 냈습니다. 제가 CLI를 사용하는 이유는 개인적으로 CLI를 선호하기 때문이기도 하지만, CLI를 통해 단계별로 설명할 수 있다면 ONTAP의 작동 방식을 더 쉽게 설명할 수 있기 때문입니다. GUI는 여러 작업을 한 번에 자동화합니다.

마지막으로, 중재자가 이미 적절하게 구성되었다고 가정하겠습니다.

스토리지 가상 머신(SVM)

ONTAP 용어 중 하나는 SVM(가상 서버라고도 함)입니다. ONTAP 스토리지 클러스터는 멀티테넌시를 위해 설계되었습니다. 시스템을 처음 설치하면 새 VMware 서버가 애플리케이션을 실행할 수 없는 것과 같은 방식으로 스토리지 서비스를 제공하지 않습니다. 따라서 VM을 생성해야 합니다.

ONTAP SVM(특히 CLI에서는 vserver라고도 함)은 하이퍼바이저에서 실행되는 실제 VM은 아니지만, 개념적으로는 동일합니다. 자체 네트워크 주소, 보안 구성, 사용자 계정 등을 갖춘 가상 스토리지 시스템입니다. SVM을 생성하면 해당 SVM의 제어 하에 파일 공유, LUN, S3 버킷 및 기타 스토리지 리소스를 프로비저닝할 수 있습니다.

아래 예시에서 -vserver의 사용을 확인할 수 있습니다. Cluster1과 Cluster2라는 두 개의 클러스터가 있습니다. Cluster1에는 jfs_as1이라는 SVM이 포함되어 있으며, 이 SVM은 Cluster2에 있는 jfs_as2 SVM과 SnapMirror 활성 동기화 관계에 참여합니다.

저장 공간 제공

SVM이 정의되면 다음 단계는 볼륨과 LUN을 생성하는 것입니다. ONTAP에서 볼륨은 LUN이 아니라는 점을 기억하세요. 볼륨은 LUN을 포함한 데이터를 저장하는 관리 객체입니다. 일반적으로 관련 LUN을 하나의 볼륨으로 통합합니다. 볼륨 레이아웃은 일반적으로 이러한 LUN의 관리를 간소화하도록 설계되었습니다.

헷갈리시나요? 기본 볼륨과 LUN 레이아웃 다이어그램을 보여드리겠습니다.

어떤 데이터베이스 레이아웃에도 정답은 없습니다. 최적의 옵션은 데이터 처리 목적에 따라 달라집니다. 이 경우에는 세 가지 볼륨이 있습니다.

• Oracle Grid 관리 및 쿼럼 LUN을 위한 볼륨 하나.
• Oracle 데이터 파일에 대한 볼륨 1개.
• Oracle 로그에 대한 볼륨이 하나 있으며 여기에는 redo 로그, 아카이브 로그 및 제어 파일이 포함됩니다.
• 데이터 파일 IO에 대한 LUN 수는 8개입니다. 이는 ONTAP 제한 사항이 아니라 호스트 OS 관련 문제입니다. 호스트 IO 스택을 통해 SAN 성능을 최대화하려면 여러 개의 LUN이 필요합니다. 일반적으로 4~8개의 LUN이 필요합니다. 로그 및 기타 순차적으로 액세스되는 파일의 LUN 수는 그다지 중요하지 않습니다.

이 설계는 관리 용이성을 최우선으로 고려합니다. 예를 들어, 데이터베이스를 복원해야 하는 경우 가장 빠른 방법은 데이터 파일의 상태를 되돌린 다음 원하는 복원 지점으로 로그를 재생하는 것입니다. 데이터 파일을 단일 볼륨에 저장하는 경우, 해당 볼륨의 상태를 이전 스냅샷으로 되돌릴 수 있지만, 로그 파일을 데이터 파일과 분리해야 합니다. 그렇지 않으면 데이터 파일의 상태를 되돌릴 때 RPO=0 데이터 복구에 필수적인 아카이브 로그 데이터가 손실될 수 있습니다.

마찬가지로, 이 설계를 통해 성능을 더욱 쉽게 관리할 수 있습니다. 개별 LUN이 아닌 데이터 파일 볼륨에 QoS 제한을 적용하기만 하면 됩니다. 참고로, 로그 IO는 버스트(burst) 특성이 있으므로 데이터베이스 트랜잭션 로그에는 QoS 제한을 적용하지 마십시오. 트랜잭션 로그의 평균 IO는 일반적으로 상당히 낮지만, 짧은 버스트(burst)로 발생합니다. 이러한 버스트 중에 QoS가 작동하면 심각한 성능 저하가 발생할 수 있습니다. QoS는 데이터 파일에만 적용됩니다.

볼륨을 생성합니다

저는 다음과 같이 세 권의 책을 만들었습니다.

Cluster1::> vol create -vserver jfs_as1 -volume jfsAA_grid_siteA -snapshot-policy none -percent-snapshot-space 0 -size 256g -space-guarantee  
Cluster1::> vol create -vserver jfs_as1 -volume jfsAA_oradata_siteA -snapshot-policy none -percent-snapshot-space 0 -size 1t -space-guarantee  
Cluster1::> vol create -vserver jfs_as1 -volume jfsAA_logs_siteA -snapshot-policy none -percent-snapshot-space 0 -size 500g -space-guarantee none

볼륨을 생성할 때는 다양한 옵션이 있습니다. SystemManager를 사용하면 거의 모든 경우에 적합한 기본 동작의 볼륨을 얻을 수 있지만, CLI를 사용하는 경우 사용 가능한 모든 옵션을 확인해야 할 수도 있습니다.

제 경우에는 다음 속성을 포함하는 그리드, 데이터 파일 및 로그 LUN에 대한 볼륨을 만들고 싶었습니다.

• 예약된 스냅샷 비활성화. 예약된 스냅샷은 강력한 온박스 데이터 보호 기능을 제공할 수 있지만, 일정, 보존 정책 및 명명 규칙은 SLA를 기반으로 해야 합니다. 지금은 스냅샷이 의도치 않게 생성되는 것을 방지하기 위해 스냅샷을 비활성화하는 것이 좋습니다.
• 스냅샷 예약 공간을 0%로 설정하세요. SAN 환경에서는 스냅샷 공간을 예약할 필요가 없습니다.
• 공간 보장을 없음으로 설정하세요. 공간 보장은 볼륨의 용량을 시스템에 예약하므로, 데이터베이스에서는 거의 항상 낭비입니다. 대부분의 데이터베이스는 압축률이 높으므로 볼륨의 전체 크기를 예약할 필요가 없습니다.
• 공간 효율성 설정을 활성화하고 싶지만, 이는 기본 동작이며 특별한 인수가 필요하지 않습니다.

LUN 생성

다음 단계는 볼륨 내에 필요한 LUN을 생성하는 것입니다. 기본값을 사용하고 공간 예약을 비활성화하겠습니다. 이렇게 하면 LUN이 볼륨 내에서 해당 LUN에 실제로 필요한 공간만 사용하게 됩니다.

Cluster1::> lun create -vserver jfs_as1 /vol/jfsAA_grid_siteA/lun0 -size 64g -ostype linux -space-reserve disabled  
Cluster1::> lun create -vserver jfs_as1 /vol/jfsAA_grid_siteA/lun1 -size 64g -ostype linux -space-reserve disabled  
…  
Cluster1::> lun create -vserver jfs_as1 /vol/jfsAA_logs_siteA/lun0 -size 64g -ostype linux -space-reserve disabled  
Cluster1::> lun create -vserver jfs_as1 /vol/jfsAA_logs_siteA/lun1 -size 64g -ostype linux -space-reserve disabled

CG를 정의하세요

이제 Oracle 데이터 파일 LUN, Oracle 로그 LUN, RAC 클러스터 리소스 LUN, 이렇게 세 가지 데이터 볼륨이 있습니다. 세 개의 개별 볼륨이 최적의 관리 효율성을 제공하지만, 동기식 복제에는 단일 컨테이너가 필요합니다. 이 RAC 환경은 통합된 전체로 복제되고 동기화되어야 합니다. 사이트 장애 발생 시, 장애가 발생한 사이트의 모든 리소스는 서로 일관성을 유지해야 합니다. 즉, 일관성 그룹이 필요합니다.

위에서 언급했듯이 ONTAP에서 볼륨은 LUN이 아니라 관리 컨테이너일 뿐입니다. 특정 데이터 세트의 모든 LUN이 단일 볼륨에 배치된 경우, 해당 볼륨을 하나의 단위로 스냅샷을 생성하고, 복제, 복원 또는 복제할 수 있습니다. 즉, ONTAP에서 볼륨은 기본적으로 일관성 그룹입니다.

많은 SM-as 사용 사례에서 특정 애플리케이션의 모든 LUN을 단일 볼륨에 배치하는 것만으로도 데이터 보호 요구 사항을 충족할 수 있습니다. 하지만 때로는 요구 사항이 더 복잡할 수 있습니다. 관리 용이성 요구 사항에 따라 애플리케이션을 여러 볼륨으로 분리해야 하지만, 애플리케이션을 하나의 단위로 관리해야 할 수도 있습니다. 이러한 이유로 ONTAP Consistency Groups를 개발했으며, 자세한 내용은 여기 와 여기에서 확인할 수 있습니다 .

CLI에서 CG 이름과 현재 볼륨을 제공하여 3개 볼륨에 대한 일관성 그룹을 정의할 수 있습니다.

Cluster1::> consistency-group create -vserver jfs_as1 -consistency-group jfsAA -volumes jfsAA_oradata_siteA,jfsAA_logs_siteA,jfsAA_grid_siteA

그 결과, 현재 그리드, 데이터 파일, 로그 볼륨과 그 안에 포함된 LUN을 기반으로 jfsAA라는 CG를 만들었습니다. (AA는 제가 구축 중인 액티브-액티브 구성을 나타내기 위해 사용했습니다.) 또한, 클러스터가 어떤 볼륨을 호스팅하고 있는지, 그리고 그 볼륨 안에 어떤 데이터가 있는지 더 쉽게 추적할 수 있도록 접미사 _siteA를 사용했습니다. 자세한 내용은 아래에서 확인하세요.

복제 설정

사이트 A에 LUN 볼륨이 있지만 복제는 아직 작동하지 않습니다. 복제를 준비하는 첫 번째 단계는 사이트 B에 볼륨을 생성하는 것입니다. 앞서 언급했듯이 SystemManager UI는 모든 설정 작업을 자동화하지만, CLI를 사용하면 자동화된 이벤트 시퀀스의 각 단계를 더 쉽게 설명할 수 있습니다.

대상 볼륨 생성

데이터를 복제하기 전에 복제본을 호스팅할 장소가 필요합니다.

Cluster2::> vol create -vserver jfs_as2 -volume jfsAA_grid_siteB -snapshot-policy none -percent-snapshot-space 0 -size 256g -type DP -space-guarantee none  
Cluster2::> vol create -vserver jfs_as2 -volume jfsAA_oradata_siteB -snapshot-policy none -percent-snapshot-space 0 -size 1t -type DP -space-guarantee none  
Cluster2::> vol create -vserver jfs_as2 -volume jfsAA_logs_siteB -snapshot-policy none -percent-snapshot-space 0 -size 500g -type DP -space-guarantee none

위 명령은 사이트 A와 동일한 설정을 사용하여 사이트 B에 세 개의 볼륨을 생성했습니다. 단, 볼륨 유형은 “DP”로, 데이터 보호 볼륨을 의미합니다. 이는 복제 관계에 연결될 볼륨을 나타냅니다. LUN은 프로비저닝되지 않습니다. 복제가 초기화되고 클러스터 2의 볼륨 내용이 클러스터 1의 소스 볼륨과 동기화되면 LUN이 자동으로 생성됩니다.

복제 초기화

다음 명령은 활성-활성 모드에서 SnapMirror 활성 동기화 관계를 생성합니다. 이 명령은 초기화되지 않은 컨트롤러에서 실행됩니다. SnapMirror는 풀(pull) 기술로 설계되었습니다. 예를 들어, 비동기 SnapMirror 업데이트는 소스에서 새 데이터를 풀합니다. 소스에서 대상으로 푸시(push)되지 않습니다.

Cluster2::> snapmirror create -source-path jfs_as1:/cg/jfsAA -destination-path jfs_as2:/cg/jfsAA -cg-item-mappings jfsAA_grid_siteA:@jfsAA_grid_siteB,jfsAA_oradata_siteA:@jfsAA_oradata_siteB,jfsAA_logs_siteA:@jfsAA_logs_siteB -policy AutomatedFailOverDuplex  
Operation succeeded: SnapMirror create for the relationship with destination "jfs_as2:/cg/jfsAA".

이 작업은 GUI에서 보면 훨씬 더 이해가 되지만, 명령을 자세히 설명해 드리겠습니다. 기능은 다음과 같습니다.

snapmirror create

그건 자명한 사실입니다. 스냅미러 관계를 만들고 있는 거죠.

-source-path jfs_as1:/cg/jfsAA

jfs_as1이라는 SVM 소스와 jfsAA라는 일관성 그룹을 사용하세요. 이 구문은 ONTAP CLI의 다른 곳에서 확인할 수 있습니다. 일관성 그룹은  [svm name]:/cg/[cg name]으로 표시됩니다.

-destination-path jfs_as2:/cg/jfsAA

jfsAA라는 소스 CG를 jfs_as2라는 SVM에 복제하고 jfsAA라는 동일한 CG 이름을 사용합니다.

-cg-item-mappings \  
jfsAA_grid_siteA:@jfsAA_grid_siteB, \  
jfsAA_oradata_siteA:@jfsAA_oradata_siteB,\  
jfsAA_logs_siteA:@jfsAA_log_siteB

이 섹션에서는 볼륨 간 매핑을 제어합니다. 구문은 [source volume]:@[destination volume] 입니다. 소스 그리드 볼륨은 대상 그리드 볼륨에, oradata는 oradata에, 로그는 로그에 매핑했습니다. 이름의 유일한 차이점은 접미사입니다. 사용자 오류를 방지하기 위해 볼륨에 siteA 및 siteB 접미사를 사용했습니다. SystemManager 또는 CLI를 사용하여 UI에서 관리 작업을 수행하는 경우, 볼륨 이름의 접미사를 통해 자신이 사이트 A 시스템에서 작업하는지 사이트 B 시스템에서 작업하는지 쉽게 알 수 있어야 합니다.

-policy AutomatedFailOverDuplex

마지막 인수는 AutomatedFailoverDuplex 유형의 스냅미러 관계를 지정합니다. 이는 자동 장애 감지 기능을 갖춘 양방향 동기 복제를 의미합니다. 관계는 현재 존재하지만 아직 초기화되지 않았습니다. 이를 위해서는 두 번째 클러스터에서 다음 명령이 필요합니다.

Cluster2::> snapmirror initialize -destination-path jfs_as2:/cg/jfsAA  
Operation is queued: SnapMirror initialize of destination "jfs_as2:/cg/jfsAA".

다음과 같이 상태를 확인할 수 있으며, 중요한 것은 관계 상태가 InSync이고 건강한지 확인하는 것입니다.

Cluster2::> snapmirror show -vserver jfs_as2 -destination-path jfs_as2:/cg/jfsAA  
                            Source Path: jfs_as1:/cg/jfsAA  
                       Destination Path: jfs_as2:/cg/jfsAA  
                      Relationship Type: XDP  
                Relationship Group Type: consistencygroup  
                      SnapMirror Policy: AutomatedFailOverDuplex  
                           Mirror State: Snapmirrored  
                    Relationship Status: InSync  
                                Healthy: true

igroup을 정의하세요

LUN을 사용하기 전에 이니시에이터 그룹(igroup)을 정의해야 합니다. Oracle RAC 클러스터를 구축 중이므로 두 개의 서로 다른 호스트가 동일한 LUN에 액세스하게 됩니다. iSCSI를 사용하지만 FC도 동일하게 작동합니다. iSCSI 이니시에이터 ID 대신 WWN을 사용합니다.

먼저, 사이트 A 시스템에 igroup을 생성하겠습니다. 이 igroup에 매핑된 모든 LUN은 지정된 이니시에이터를 사용하는 호스트에서 iSCSI를 통해 사용할 수 있습니다.

Cluster1::> igroup create -vserver jfs_as1 -igroup jfsAA -ostype linux -initiator iqn.1994-05.com.redhat:a8ee93358a32

다음으로, 고급 모드로 전환하여 로컬 이니시에이터 이름을 로컬 SVM에 연결합니다. ONTAP은 이를 통해 경로 우선순위를 제어합니다. igroup에 WWN 또는 iSCSI 이니시에이터가 나열된 모든 호스트는 해당 igroup에 매핑된 LUN에 액세스할 수 있지만, 경로 우선순위가 최적화되지는 않습니다. 사이트 A에서 시작되는 경로가 사이트 A에 있는 호스트에 대한 최적 경로로만 광고되도록 설정하려고 합니다.

Cluster1::> set advanced  
Cluster1::*> igroup initiator add-proximal-vserver -vserver jfs_as1 iqn.1994-05.com.redhat:a8ee93358a32 -proximal-vservers jfs_as1

그런 다음 사이트 B의 호스트의 WWN 또는 iSCSI 초기자를 사용하여 사이트 B에서 프로세스를 반복합니다.

Cluster2::> igroup create -vserver jfs_as2  -igroup jfsAA -ostype linux -initiator iqn.1994-05.com.redhat:5214562dfc56  
Cluster1::*> set advanced  
Cluster2::*> igroup initiator add-proximal-vserver -vserver jfs_as2 iqn.1994-05.com.redhat:5214562dfc56 -proximal-vservers jfs_as2

proximal-vserver 정보는 추가할 필요가 없었습니다. 왜 추가하지 않았는지 이해하려면 계속 읽어보세요.

LUN 매핑

다음으로, 호스트가 LUN에 액세스할 수 있도록 LUN을 igroup에 매핑합니다. 각 사이트에 동일한 igroup 이름을 사용했지만, 이 igroup들은 서로 다른 SVM에 위치합니다.

Cluster1::> lun map -vserver jfs_as1 /vol/jfsAA_grid_siteA/lun0  -igroup jfsAA  
Cluster1::> lun map -vserver jfs_as1 /vol/jfsAA_grid_siteA/lun1  -igroup jfsAA  
…  
Cluster1::> lun map -vserver jfs_as1 /vol/jfsAA_oradata_siteA/lun6 -igroup jfsAA  
Cluster1::> lun map -vserver jfs_as1 /vol/jfsAA_oradata_siteA/lun7 -igroup jfsAA

Cluster2::> lun map -vserver jfs_as2 /vol/jfsAA_grid_siteB/lun0  -igroup jfsAA  
Cluster2::> lun map -vserver jfs_as2 /vol/jfsAA_grid_siteB/lun1  -igroup jfsAA  
…  
Cluster2::> lun map -vserver jfs_as2 /vol/jfsAA_oradata_siteB/lun6 -igroup jfsAA  
Cluster2::> lun map -vserver jfs_as2 /vol/jfsAA_oradata_siteB/lun7 -igroup jfsAA

Oracle 구성

이 시점부터 설정은 다른 Oracle RAC 서버와 동일합니다. 기능적으로는 2-사이트 Oracle Extended RAC 클러스터와 유사하지만, ASM 장애 그룹을 구성할 필요가 없습니다. 복제 서비스는 스토리지 시스템에 내장되어 있습니다.

장치 이름

Oracle에서 장치 이름을 제어하는 ​​방법은 여러 가지가 있지만, 저는 개인적으로 udev 규칙과 다중 경로 별칭을 사용하는 것을 선호합니다. 사전 작업이 더 많이 필요하지만, 사용할 정확한 명명 규칙을 더 잘 제어할 수 있습니다.

각 RAC 노드에서 multipath.conf 파일 은 다음과 같습니다.

[root@jfs12 ~]# cat /etc/multipath.conf  
multipaths {  
    multipath {  
        wwid  3600a0980383041327a2b55676c547247  
        alias grid0  
    }  
    multipath {  
        wwid  3600a0980383041327a2b55676c547248  
        alias grid1  
    }  
    multipath {  
        wwid  3600a0980383041327a2b55676c547249  
        alias grid2  
    }  
    …  
    }  
    multipath {  
        wwid  3600a0980383041334a3f55676c69734d  
        alias logs5  
    }  
    multipath {  
        wwid  3600a0980383041334a3f55676c69734e  
        alias logs6  
    }  
    multipath {  
        wwid  3600a0980383041334a3f55676c69734f  
        alias logs7  
    }  
}

그러면 다음과 같은 udev 규칙이 있습니다.

[root@jfs12 ~]# cat /etc/udev/rules.d/99-asm.rules  
ENV{DM_NAME}=="grid*", GROUP:="asmadmin", OWNER:="grid", MODE:="660"  
ENV{DM_NAME}=="oradata*", GROUP:="asmadmin", OWNER:="grid", MODE:="660"  
ENV{DM_NAME}=="logs*", GROUP:="asmadmin", OWNER:="grid", MODE:="660"

그 결과, 올바른 사용자 및 그룹 권한이 자동으로 할당된 명확한 장치 이름이 생성됩니다. /dev/mapper에서도 장치를 확인할 수 있습니다.

[root@jfs12 ~]# ls /dev/mapper  
control  grid1  logs0  logs2  logs4  logs6  oradata0  oradata2  oradata4  oradata6  vg00-root

ASM 구성

일반적인 확장 RAC와 달리, 외부 중복성을 갖춘 ASM 디스크 그룹을 생성했습니다. 즉, ASM 자체에서는 미러링이 이루어지지 않습니다. 복제 서비스는 RAC가 아닌 스토리지 시스템에서 제공됩니다. 다음과 같은 ASM 디스크 그룹을 생성했습니다.

[root@jfs12 ~]# /grid/bin/asmcmd ls  
DBF/  
GRID/  
LOGS/

이 지점부터는 설치 과정이 다른 Oracle RAC 설치와 똑같습니다.

데이터베이스 생성

저는 다음의 데이터베이스 레이아웃을 사용했습니다.

[root@jfs12 ~]# /grid/bin/asmcmd ls DBF/NTAP  
124D13D9FE3FFF29E06370AAC00A260E/  
124DA9A2A3BB954AE06370AAC00A7624/  
DATAFILE/  
NTAPpdb1/  
PARAMETERFILE/  
PASSWORD/  
TEMPFILE/  
pdbseed/  
sysaux01.dbf  
system01.dbf  
temp01.dbf  
undotbs01.dbf  
undotbs02.dbf  
users01.dbf  

[root@jfs12 ~]# /grid/bin/asmcmd ls LOGS/NTAP  
ARCHIVELOG/  
CONTROLFILE/  
ONLINELOG/  
control01.ctl  
control02.ctl  
redo01.log  
redo02.log  
redo03.log  
redo04.log

여기에는 이유가 있지만, SnapMirror Active Sync 사용과는 관련이 없습니다. 자세한 내용은 위의 “저장소 프로비저닝” 섹션을 참조하세요.

실패 시나리오

다음 다이어그램은 하드웨어 수준에서 Oracle 데이터베이스 및 스토리지 구성을 보여줍니다(중개자는 표시되지 않음). 균일하지 않은 네트워크 구성을 사용하고 있습니다. 사이트 간에는 SAN 연결이 없습니다.

위에서 호스트 근접성(host proximity)을 구성할 필요가 없다고 말씀드렸습니다. 비균일 구성을 사용하고 있기 때문입니다. SAN을 여러 사이트로 확장하지 않았습니다. 호스트에서 사용할 수 있는 경로는 로컬 경로뿐입니다. 호스트는 상대 사이트로 연결되는 스토리지 경로를 볼 수 없으므로 호스트 근접성 설정을 추가할 필요가 없습니다. 균일 구성을 사용하고 근접성 설정 제어 방식을 알아야 하는 독자를 위해 호스트 근접성 구성 지침을 포함했습니다.

아래에 설명된 데이터베이스 서비스 손실을 초래한 여러 시나리오는 균일한 네트워크 구성에서는 발생하지 않았을 것입니다. 사이트 간 SAN 연결이 없으므로 특정 사이트에서 활성 경로 손실이 발생하면 경로가 전혀 남아 있지 않음을 의미합니다. 균일한 네트워크 구성에서는 각 사이트가 반대 사이트의 대체 경로를 사용할 수 있습니다. 이 테스트에서 비균일한 구성을 선택한 이유는 SAN을 확장하지 않고도 활성-활성 RPO=0 복제를 구현할 수 있음을 보여주기 위한 것입니다. 이는 더 까다로운 사용 사례이며, 몇 가지 제한 사항이 있지만 SAN 아키텍처가 더 단순하다는 등의 이점도 있습니다.

스토리지 아키텍처를 살펴보는 또 다른 방법이 있습니다. 복제의 존재 여부는 Oracle 데이터베이스와 RAC 클러스터에서는 본질적으로 눈에 띄지 않습니다. 다양한 장애 시나리오로 인해 특정 데이터베이스 서버의 중단이나 특정 경로 손실이 발생할 수 있지만, 데이터베이스 관점에서는 LUN 세트가 하나뿐입니다. 논리적으로는 다음과 같습니다.

선호하는 사이트

구성은 대칭적이지만, 스플릿 브레인 관리와 관련된 한 가지 예외가 있습니다.

질문은 다음과 같습니다. 복제 링크가 끊어지고 두 사이트 모두 쿼럼을 확보하지 못하면 어떻게 될까요? 어떤 상황이 발생하기를 원하시나요? 이 질문은 Oracle RAC와 ONTAP 동작 모두에 적용됩니다. 변경 사항을 여러 사이트에 복제할 수 없고 운영을 재개하려면 두 사이트 중 하나는 유지되어야 하고 다른 사이트는 사용할 수 없게 됩니다.

Oracle과 css_critical

Oracle RAC의 경우, 기본적으로 짝수 개의 서버로 구성된 RAC 클러스터에서 노드 중 하나가 다른 노드보다 더 중요한 것으로 간주됩니다. 해당 노드의 우선순위가 더 높은 사이트는 사이트 격리에서 유지되지만, 다른 사이트의 노드는 제거됩니다. 우선순위는 여러 요인에 따라 결정되지만, css_critical 설정을 사용하여 이 동작을 제어할 수도 있습니다.

제 환경에는 jfs12와 jfs13 두 개의 노드가 있습니다. css_critical 의 현재 설정은 다음과 같습니다.

[root@jfs12 ~]# /grid/bin/crsctl get server css_critical  
CRS-5092: Current value of the server attribute CSS_CRITICAL is no.

[root@jfs13 trace]# /grid/bin/crsctl get server css_critical  
CRS-5092: Current value of the server attribute CSS_CRITICAL is no.

jfs12가 있는 사이트를 기본 사이트로 지정하고 싶어서 사이트 A 노드에서 이 값을 ‘예’로 변경하고 서비스를 다시 시작했습니다.

[root@jfs12 ~]# /grid/bin/crsctl set server css_critical yes  
CRS-4416: Server attribute 'CSS_CRITICAL' successfully changed. Restart Oracle High Availability Services for new value to take effect.  

[root@jfs12 ~]# /grid/bin/crsctl stop crs  
CRS-2791: Starting shutdown of Oracle High Availability Services-managed resources on 'jfs12'  
CRS-2673: Attempting to stop 'ora.crsd' on 'jfs12'  
CRS-2790: Starting shutdown of Cluster Ready Services-managed resources on server 'jfs12'  
CRS-2673: Attempting to stop 'ora.ntap.ntappdb1.pdb' on 'jfs12'  
…  

CRS-2673: Attempting to stop 'ora.gipcd' on 'jfs12'  
CRS-2677: Stop of 'ora.gipcd' on 'jfs12' succeeded  
CRS-2793: Shutdown of Oracle High Availability Services-managed resources on 'jfs12' has completed  
CRS-4133: Oracle High Availability Services has been stopped.  

[root@jfs12 ~]# /grid/bin/crsctl start crs  
CRS-4123: Oracle High Availability Services has been started.

SnapMirror Active Sync 기본 사이트

SnapMirror Active Sync는 언제든지 한 사이트를 “소스”로, 다른 사이트를 “대상”으로 간주합니다. 이는 단방향 복제 관계를 의미하지만, 실제로는 그렇지 않습니다. 이것이 선호 사이트가 결정되는 방식입니다. 복제 링크가 끊어지면 소스의 LUN 경로는 계속해서 데이터를 제공하고, 대상의 LUN 경로는 복제가 다시 설정되고 동기 상태가 될 때까지 사용할 수 없게 됩니다. 그런 다음 경로는 데이터 제공을 재개합니다.

현재 구성에서는 사이트 A가 Oracle과 ONTAP 모두에 대해 기본 사이트로 설정되어 있습니다. SystemManager를 통해 확인할 수 있습니다.

또는 CLI에서:

Cluster2::> snapmirror show -destination-path jfs_as2:/cg/jfsAA  
                            Source Path: jfs_as1:/cg/jfsAA  
                       Destination Path: jfs_as2:/cg/jfsAA  
                      Relationship Type: XDP  
                Relationship Group Type: consistencygroup  
                    SnapMirror Schedule: -  
                 SnapMirror Policy Type: automated-failover-duplex  
                      SnapMirror Policy: AutomatedFailOverDuplex  
                           Mirror State: Snapmirrored  
                    Relationship Status: InSync

핵심은 소스가 클러스터1의 SVM이라는 것입니다. 위에서 언급했듯이 “소스”와 “대상”이라는 용어는 복제된 데이터의 흐름을 나타내는 것이 아닙니다. 두 사이트 모두 쓰기 작업을 처리하여 반대쪽 사이트로 복제할 수 있습니다. 실제로 두 클러스터 모두 소스이자 대상입니다. 한 클러스터를 소스로 지정하는 것은 복제 링크가 끊어졌을 때 어떤 클러스터가 읽기-쓰기 스토리지 시스템으로 유지되는지를 제어하는 ​​것일 뿐입니다.

SnapMirror 복제 연결 손실

SM-as 복제 링크를 끊으면 클러스터가 변경 사항을 반대 사이트에 복제할 수 없기 때문에 쓰기 IO를 완료할 수 없습니다. Oracle RAC 환경에서는 다음과 같은 상황이 발생합니다.

사이트 A

사이트 A에서 복제 링크 장애가 발생하면 ONTAP이 쓰기 복제를 시도하면서 쓰기 IO 처리가 약 15초간 중단됩니다. 이 기간 동안 ONTAP은 복제 링크가 실제로 작동하지 않는 것으로 판단합니다. 15초가 지나면 사이트 A의 ONTAP 클러스터가 읽기 및 쓰기 IO 처리를 재개합니다. SAN 경로는 변경되지 않으며 LUN은 온라인 상태를 유지합니다.

사이트 B

사이트 B는 SnapMirror Active Sync 기본 사이트가 아니므로 약 15초 후에 LUN 경로를 사용할 수 없게 됩니다.

복제 링크가 15:19:44 타임스탬프에 끊어졌습니다. Oracle RAC의 첫 번째 경고는 200초 제한 시간(Oracle RAC 매개변수 disktimeout 으로 제어 )이 다가오면서 100초 후에 도착했습니다.

2024-09-10 15:21:24.702 [ONMD(2792)]CRS-1615: No I/O has completed after 50% of the maximum interval. If this persists, voting file /dev/mapper/grid2 will be considered not functional in 99340 milliseconds.  
2024-09-10 15:22:14.706 [ONMD(2792)]CRS-1614: No I/O has completed after 75% of the maximum interval. If this persists, voting file /dev/mapper/grid2 will be considered not functional in 49330 milliseconds.  
2024-09-10 15:22:44.708 [ONMD(2792)]CRS-1613: No I/O has completed after 90% of the maximum interval. If this persists, voting file /dev/mapper/grid2 will be considered not functional in 19330 milliseconds.  
2024-09-10 15:23:04.710 [ONMD(2792)]CRS-1604: CSSD voting file is offline: /dev/mapper/grid2; details at (:CSSNM00058:) in /gridbase/diag/crs/jfs13/crs/trace/onmd.trc.  
2024-09-10 15:23:04.710 [ONMD(2792)]CRS-1606: The number of voting files available, 0, is less than the minimum number of voting files required, 1, resulting in CSSD termination to ensure data integrity; details at (:CSSNM00018:) in /gridbase/diag/crs/jfs13/crs/trace/onmd.trc  
2024-09-10 15:23:04.716 [ONMD(2792)]CRS-1699: The CSS daemon is terminating due to a fatal error from thread: clssnmvDiskPingMonitorThread; Details at (:CSSSC00012:) in /gridbase/diag/crs/jfs13/crs/trace/onmd.trc  
2024-09-10 15:23:04.731 [OCSSD(2794)]CRS-1652: Starting clean up of CRSD resources.

200초 투표 디스크 시간 초과에 도달하면 이 Oracle RAC 노드는 클러스터에서 스스로 추방되고 재부팅됩니다.

Oracle RAC 복제 손실

Oracle RAC 복제 링크가 손실되면 비슷한 결과가 발생하지만, 기본적으로 시간 제한이 더 짧아집니다. Oracle RAC 노드는 스토리지 연결이 끊어진 후 200초 동안 대기한 후 삭제되지만, RAC 네트워크 하트비트가 손실된 후에는 30초만 대기합니다.

CRS 메시지는 아래와 같습니다. 30초의 시간 초과 경과를 확인할 수 있습니다. css_critical이 사이트 A에 있는 jfs12에 설정되었으므로 해당 사이트는 유지되고, 사이트 B에 있는 jfs13은 제거됩니다.

2024-09-12 10:56:44.047 [ONMD(3528)]CRS-1611: Network communication with node jfs13 (2) has been missing for 75% of the timeout interval.  If this persists, removal of this node from cluster will occur in 6.980 seconds  
2024-09-12 10:56:48.048 [ONMD(3528)]CRS-1610: Network communication with node jfs13 (2) has been missing for 90% of the timeout interval.  If this persists, removal of this node from cluster will occur in 2.980 seconds  
2024-09-12 10:56:51.031 [ONMD(3528)]CRS-1607: Node jfs13 is being evicted in cluster incarnation 621599354; details at (:CSSNM00007:) in /gridbase/diag/crs/jfs12/crs/trace/onmd.trc.  
2024-09-12 10:56:52.390 [CRSD(6668)]CRS-7503: The Oracle Grid Infrastructure process 'crsd' observed communication issues between node 'jfs12' and node 'jfs13', interface list of local node 'jfs12' is '192.168.30.1:33194;', interface list of remote node 'jfs13' is '192.168.30.2:33621;'.  
2024-09-12 10:56:55.683 [ONMD(3528)]CRS-1601: CSSD Reconfiguration complete. Active nodes are jfs12 .  
2024-09-12 10:56:55.722 [CRSD(6668)]CRS-5504: Node down event reported for node 'jfs13'.  
2024-09-12 10:56:57.222 [CRSD(6668)]CRS-2773: Server 'jfs13' has been removed from pool 'Generic'.  
2024-09-12 10:56:57.224 [CRSD(6668)]CRS-2773: Server 'jfs13' has been removed from pool 'ora.NTAP'.

복제 네트워크의 완전한 손실

Oracle RAC 스플릿 브레인 감지는 Oracle RAC 스토리지 하트비트에 종속됩니다. 사이트 간 연결 손실로 인해 RAC 네트워크 하트비트와 스토리지 복제 서비스가 동시에 손실되는 경우, RAC 사이트는 RAC 상호 연결 또는 RAC 투표 디스크를 통해 사이트 간 통신을 할 수 없게 됩니다. 짝수 노드 집합의 경우, 기본 설정에서 두 사이트 모두 강제로 종료될 수 있습니다. 정확한 동작은 이벤트 순서와 RAC 네트워크 및 디스크 하트비트 폴링 시점에 따라 달라집니다.

두 사이트 중단 위험은 두 가지 방법으로 해결할 수 있습니다. 첫째, 홀수의 RAC 노드를 사용하는 것이며, 바람직하게는 세 번째 사이트 타이브레이커를 사용합니다. 세 번째 사이트를 사용할 수 없는 경우, 타이브레이커 인스턴스를 한 사이트에 배치할 수 있습니다. 즉, 사이트 간 연결이 끊어지면 한 사이트에서 LUN 경로가 중단되지만, RAC 사이트 중 하나는 여전히 쿼럼을 유지하므로 삭제되지 않습니다.

세 번째 사이트를 사용할 수 없는 경우, RAC 클러스터의 misscount 매개변수를 조정하여 이 문제를 해결할 수 있습니다. 기본값에서 RAC 네트워크 하트비트 시간 초과는 30초입니다. 이 값은 일반적으로 RAC에서 장애가 발생한 RAC 노드를 식별하고 클러스터에서 제거하는 데 사용됩니다. 또한 투표 디스크 하트비트와도 연결됩니다.

예를 들어, Oracle RAC와 스토리지 복제 서비스 모두의 사이트 간 트래픽을 전달하는 통로가 백호에 의해 절단되면 30초간의 미스카운트 카운트다운이 시작됩니다. RAC 기본 사이트 노드가 30초 이내에 상대 사이트와 다시 연결되지 않고, 같은 30초 이내에 보팅 디스크를 사용하여 상대 사이트가 다운되었음을 확인할 수 없는 경우, 기본 사이트 노드도 강제로 제거됩니다. 결과적으로 데이터베이스 전체가 중단됩니다.

미스카운트 폴링 발생 시점에 따라 SnapMirror Active Sync가 시간 초과되어 기본 사이트의 스토리지가 30초 창이 만료되기 전에 서비스를 재개할 수 있도록 30초가 충분하지 않을 수 있습니다. 이 30초 창은 늘릴 수 있습니다.

[root@jfs12 ~]# /grid/bin/crsctl set css misscount 100  
CRS-4684: Successful set of parameter misscount to 100 for Cluster Synchronization Services.

이 값을 사용하면 선호 사이트의 스토리지 시스템이 미스카운트 제한 시간이 만료되기 전에 작업을 재개할 수 있습니다. 그 결과, LUN 경로가 제거된 사이트의 노드만 제거됩니다. 아래는 예시입니다.

2024-09-12 09:50:59.352 [ONMD(681360)]CRS-1612: Network communication with node jfs13 (2) has been missing for 50% of the timeout interval.  If this persists, removal of this node from cluster will occur in 49.570 seconds  
2024-09-12 09:51:10.082 [CRSD(682669)]CRS-7503: The Oracle Grid Infrastructure process 'crsd' observed communication issues between node 'jfs12' and node 'jfs13', interface list of local node 'jfs12' is '192.168.30.1:46039;', interface list of remote node 'jfs13' is '192.168.30.2:42037;'.  
2024-09-12 09:51:24.356 [ONMD(681360)]CRS-1611: Network communication with node jfs13 (2) has been missing for 75% of the timeout interval.  If this persists, removal of this node from cluster will occur in 24.560 seconds  
2024-09-12 09:51:39.359 [ONMD(681360)]CRS-1610: Network communication with node jfs13 (2) has been missing for 90% of the timeout interval.  If this persists, removal of this node from cluster will occur in 9.560 seconds  
2024-09-12 09:51:47.527 [OHASD(680884)]CRS-8011: reboot advisory message from host: jfs13, component: cssagent, with time stamp: L-2024-09-12-09:51:47.451  
2024-09-12 09:51:47.527 [OHASD(680884)]CRS-8013: reboot advisory message text: oracssdagent is about to reboot this node due to unknown reason as it did not receive local heartbeats for 10470 ms amount of time  
2024-09-12 09:51:48.925 [ONMD(681360)]CRS-1632: Node jfs13 is being removed from the cluster in cluster incarnation 621596607

참고: Oracle 지원팀에서는 구성 문제를 해결하기 위해 misscount 또는 disktimeout 매개변수를 변경하는 것을 강력히 권장하지 않습니다. 그러나 SAN 부팅, 가상화 및 스토리지 복제 구성을 포함한 많은 경우 이러한 매개변수 변경이 필요하고 불가피할 수 있습니다. 예를 들어 SAN 또는 IP 네트워크의 안정성 문제로 인해 RAC가 강제로 제거된 경우, 근본적인 문제를 해결하고 misscount 또는 disktimeout 값을 청구하지 않아야 합니다 . 구성 오류를 해결하기 위해 시간 초과를 변경하는 것은 문제를 해결하는 것이 아니라 문제를 가리는 것입니다. 기본 인프라의 설계 측면에 따라 RAC 환경을 적절하게 구성하기 위해 이러한 매개변수를 변경하는 것은 Oracle 지원팀의 설명과 다르며 일관성이 있습니다. SAN 부팅의 경우 disktimeout 과 일치하도록 misscount를 최대 200까지 조정하는 것이 일반적입니다 .

스토리지 시스템 장애

스토리지 시스템 장애의 결과는 복제 링크 손실의 결과와 거의 동일합니다. 정상 작동 중인 사이트에서는 쓰기 작업 시 약 15초 동안 IO가 일시 중지됩니다. 15초가 지나면 해당 사이트에서 평소처럼 IO가 재개됩니다.

실패한 사이트의 Oracle RAC 노드는 스토리지 서비스를 잃고, 강제 퇴거 및 후속 재부팅 전에 동일한 200초 디스크 시간 초과 카운트다운에 들어갑니다.

2024-09-11 13:44:38.613 [ONMD(3629)]CRS-1615: No I/O has completed after 50% of the maximum interval. If this persists, voting file /dev/mapper/grid2 will be considered not functional in 99750 milliseconds.  
2024-09-11 13:44:51.202 [ORAAGENT(5437)]CRS-5011: Check of resource "NTAP" failed: details at "(:CLSN00007:)" in "/gridbase/diag/crs/jfs13/crs/trace/crsd_oraagent_oracle.trc"  
2024-09-11 13:44:51.798 [ORAAGENT(75914)]CRS-8500: Oracle Clusterware ORAAGENT process is starting with operating system process ID 75914  
2024-09-11 13:45:28.626 [ONMD(3629)]CRS-1614: No I/O has completed after 75% of the maximum interval. If this persists, voting file /dev/mapper/grid2 will be considered not functional in 49730 milliseconds.  
2024-09-11 13:45:33.339 [ORAAGENT(76328)]CRS-8500: Oracle Clusterware ORAAGENT process is starting with operating system process ID 76328  
2024-09-11 13:45:58.629 [ONMD(3629)]CRS-1613: No I/O has completed after 90% of the maximum interval. If this persists, voting file /dev/mapper/grid2 will be considered not functional in 19730 milliseconds.  
2024-09-11 13:46:18.630 [ONMD(3629)]CRS-1604: CSSD voting file is offline: /dev/mapper/grid2; details at (:CSSNM00058:) in /gridbase/diag/crs/jfs13/crs/trace/onmd.trc.  
2024-09-11 13:46:18.631 [ONMD(3629)]CRS-1606: The number of voting files available, 0, is less than the minimum number of voting files required, 1, resulting in CSSD termination to ensure data integrity; details at (:CSSNM00018:) in /gridbase/diag/crs/jfs13/crs/trace/onmd.trc  
2024-09-11 13:46:18.638 [ONMD(3629)]CRS-1699: The CSS daemon is terminating due to a fatal error from thread: clssnmvDiskPingMonitorThread; Details at (:CSSSC00012:) in /gridbase/diag/crs/jfs13/crs/trace/onmd.trc  
2024-09-11 13:46:18.651 [OCSSD(3631)]CRS-1652: Starting clean up of CRSD resources.

스토리지 서비스가 손실된 RAC 노드의 SAN 경로 상태는 다음과 같습니다.

oradata7 (3600a0980383041334a3f55676c697347) dm-20 NETAPP,LUN C-Mode  
size=128G features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 alua' wp=rw  
|-+- policy='service-time 0' prio=0 status=enabled  
| `- 34:0:0:18 sdam 66:96  failed faulty running  
`-+- policy='service-time 0' prio=0 status=enabled  
  `- 33:0:0:18 sdaj 66:48  failed faulty running

Linux 호스트는 경로 손실을 200초보다 훨씬 빠르게 감지했지만, 데이터베이스 관점에서는 장애가 발생한 사이트의 호스트에 대한 클라이언트 연결이 기본 Oracle RAC 설정에 따라 200초 동안 동결됩니다. 전체 데이터베이스 작업은 제거가 완료된 후에야 재개됩니다.

한편, 반대쪽 사이트의 Oracle RAC 노드는 다른 RAC 노드의 손실을 기록합니다. 그 외에는 평소처럼 계속 작동합니다.

2024-09-11 13:46:34.152 [ONMD(3547)]CRS-1612: Network communication with node jfs13 (2) has been missing for 50% of the timeout interval.  If this persists, removal of this node from cluster will occur in 14.020 seconds  
2024-09-11 13:46:41.154 [ONMD(3547)]CRS-1611: Network communication with node jfs13 (2) has been missing for 75% of the timeout interval.  If this persists, removal of this node from cluster will occur in 7.010 seconds  
2024-09-11 13:46:46.155 [ONMD(3547)]CRS-1610: Network communication with node jfs13 (2) has been missing for 90% of the timeout interval.  If this persists, removal of this node from cluster will occur in 2.010 seconds  
2024-09-11 13:46:46.470 [OHASD(1705)]CRS-8011: reboot advisory message from host: jfs13, component: cssmonit, with time stamp: L-2024-09-11-13:46:46.404  
2024-09-11 13:46:46.471 [OHASD(1705)]CRS-8013: reboot advisory message text: At this point node has lost voting file majority access and oracssdmonitor is rebooting the node due to unknown reason as it did not receive local hearbeats for 28180 ms amount of time  
2024-09-11 13:46:48.173 [ONMD(3547)]CRS-1632: Node jfs13 is being removed from the cluster in cluster incarnation 621516934

중재자 전원 차단

중재자 서비스는 스토리지 작업을 직접 제어하지 않습니다. 클러스터 간의 대체 제어 경로 역할을 하며, 주로 스플릿 브레인(split-brain) 시나리오의 위험 없이 장애 조치를 자동화하기 위해 존재합니다. 정상적인 작동 시 각 클러스터는 파트너 클러스터에 변경 사항을 복제하므로, 각 클러스터는 파트너 클러스터가 온라인 상태이고 데이터를 제공하고 있는지 확인할 수 있습니다. 복제 링크에 장애가 발생하면 복제가 중단됩니다.

안전한 자동화 작업에 중재자가 필요한 이유는 중재자가 없으면 스토리지 클러스터에서 양방향 통신 손실이 네트워크 중단으로 인한 것인지 아니면 실제 스토리지 오류로 인한 것인지 판단하는 것이 불가능하기 때문입니다.

중재자는 각 클러스터가 파트너의 상태를 확인할 수 있도록 대체 경로를 제공합니다. 시나리오는 다음과 같습니다.

• 클러스터가 파트너에 직접 연결할 수 있으면 복제 서비스가 작동 중입니다. 별도의 조치는 필요하지 않습니다.
• 선호 사이트가 파트너와 직접 또는 중재자를 통해 연결할 수 없는 경우, 파트너가 실제로 연결이 끊어졌거나 격리되어 LUN 경로를 오프라인으로 설정한 것으로 간주합니다. 그러면 선호 사이트는 RPO=0 상태를 해제하고 읽기 및 쓰기 IO 처리를 계속합니다.
• 선호하지 않는 사이트가 파트너에게 직접 연락할 수 없지만 중개자를 통해 연락할 수 있는 경우 해당 경로를 오프라인으로 전환하고 복제 연결이 반환될 때까지 기다립니다.
• 비선호 사이트가 파트너와 직접 또는 운영 중재자를 통해 연결할 수 없는 경우, 파트너가 실제로 연결이 끊어졌거나 격리되어 LUN 경로가 오프라인 상태라고 가정합니다. 그러면 비선호 사이트는 RPO=0 상태를 해제하고 읽기 및 쓰기 IO 처리를 계속합니다. 복제 소스 역할을 수행하여 새로운 선호 사이트가 됩니다.

중재자가 전혀 활동할 수 없는 경우:

• 어떤 이유로든 복제 서비스에 장애가 발생하면 기본 사이트는 RPO=0 상태를 해제하고 읽기 및 쓰기 IO 처리를 재개합니다. 기본 사이트가 아닌 사이트는 경로를 오프라인으로 설정합니다.
• 선호하는 사이트에 장애가 발생하면 선호하지 않는 사이트에서는 반대 사이트가 실제로 오프라인인지 확인할 수 없으므로 서비스 중단이 발생하고, 따라서 선호하지 않는 사이트에서 서비스를 재개하는 것은 안전하지 않습니다.

서비스 복구

장애 발생 후 전원이 복구되거나 복제 링크 장애가 복구되었을 때 어떤 일이 발생하는지 설명하기는 어렵습니다. SnapMirror Active Sync는 장애가 발생한 복제 관계를 자동으로 감지하여 RPO=0 상태로 되돌립니다. 동기 복제가 다시 설정되면 경로가 다시 온라인 상태가 됩니다.

대부분의 경우 클러스터링된 애플리케이션은 장애가 발생한 경로의 복구를 자동으로 감지하고 다시 온라인 상태로 전환합니다. 경우에 따라 호스트 수준의 SAN 검사가 필요하거나 애플리케이션을 수동으로 온라인 상태로 전환해야 할 수도 있습니다. 이는 애플리케이션과 구성 방식에 따라 달라지며, 일반적으로 이러한 작업은 쉽게 자동화할 수 있습니다. ONTAP 자체는 자가 복구 기능을 갖추고 있으므로 RPO=0 스토리지 작업을 재개하기 위해 사용자 개입이 필요하지 않습니다.

SnapMirror 액티브 싱크의 또 다른 특징은 복구 속도입니다. 많은 경쟁사와 달리 ONTAP 복제는 포인터 기반 메커니즘을 사용하여 변경 사항을 추적합니다. 그 결과 복제 중단 후 재동기화가 매우 빠르게 진행됩니다. ONTAP은 복제가 며칠, 몇 주 또는 몇 달 동안 중단되더라도 변경된 블록을 식별하여 효율적이고 신속하게 원격 시스템으로 전송할 수 있습니다. 많은 경쟁사 제품은 변경된 블록보다 훨씬 더 많은 데이터를 읽고 전송해야 하는 더 느리고 비효율적인 익스텐트 기반 방식을 사용합니다. 경우에 따라 전체 미러를 다시 구축해야 할 수도 있습니다.

또한 ONTAP의 고유한 포인터 기반 기술은 재동기화 중에도 데이터의 손상되지 않은 사본을 보존합니다. 사본은 최신 상태가 아니지만, 여전히 존재합니다. 많은 경쟁 기술을 재동기화하면 재동기화가 완료될 때까지 사본이 손상됩니다. 따라서 마지막 남은 데이터 사본이 손상될 경우 고객은 심각한 데이터 손실에 노출될 수 있습니다. 

이는 ONTAP 기능이 결과를 제공할 뿐만 아니라 ONTAP이 더 잘 작동하기 때문에 더 뛰어난 최종 결과를 제공한다는 것을 보여주는 많은 예 중 하나입니다. 

SnapMirror 활성 동기화 장애 조치

선호하는 사이트를 변경하는 데는 간단한 작업이 필요합니다. 복제 동작에 대한 권한이 클러스터 간에 전환될 때 IO가 1~2초 동안 일시 중지되지만, 그 외에는 IO에 영향을 미치지 않습니다.

GUI 예:

CLI를 통해 다시 변경하는 예:

Cluster2::> snapmirror failover start -destination-path jfs_as2:/cg/jfsAA  
[Job 9575] Job is queued: SnapMirror failover for destination "jfs_as2:/cg/jfsAA                      ".  

Cluster2::> snapmirror failover show  
Source    Destination                                          Error  
Path      Path        Type     Status    start-time end-time   Reason  
-------- -----------  -------- --------- ---------- ---------- ----------  
jfs_as1:/cg/jfsAA  
         jfs_as2:/cg/jfsAA  
                      planned  completed 9/11/2024  9/11/2024  
                                         09:29:22   09:29:32

새로운 목적지 경로는 다음과 같이 확인할 수 있습니다.

Cluster1::> snapmirror show -destination-path jfs_as1:/cg/jfsAA  
                            Source Path: jfs_as2:/cg/jfsAA  
                       Destination Path: jfs_as1:/cg/jfsAA  
                      Relationship Type: XDP  
                Relationship Group Type: consistencygroup  
                 SnapMirror Policy Type: automated-failover-duplex  
                      SnapMirror Policy: AutomatedFailOverDuplex  
                           Mirror State: Snapmirrored  
                    Relationship Status: InSync

요약

위의 예시는 SnapMirror 액티브 싱크 기능을 설명하기 위해 설계되었습니다. 대부분의 기업 IT 프로젝트와 마찬가지로, 진정한 모범 사례는 거의 없습니다. 적절한 구성은 RPO, RTO, SLA 등 비즈니스 요구 사항에 따라 달라집니다. 재해 복구와 관련하여, 어떤 재해 시나리오가 다른 시나리오보다 발생 가능성이 높은지에 따라서도 달라집니다.

다음 게시물에는 Oracle RAC 타이브레이커 사용, 균일한 네트워킹 사용, 그리고 애플리케이션 IO 재개 시간 정량화 등이 포함될 예정입니다. SnapMirror 액티브 싱크는 액티브-액티브 모드로 작동하며, 안정적이고 자가 복구가 가능하며 구성 및 관리가 간편한 통합 RPO=0/RTO=0 SAN 복제 기술입니다.

더 자세히 알아보려면 SnapMirror Active Sync 에 대한 공식 ONTAP 문서를 참조하세요 . 실제로 작동하는 모습을 보고 싶으시다면 Neto와 CPOC(고객 개념 증명) 팀에 문의하시는 것을 추천합니다. Neto는 실제 워크로드를 시뮬레이션하는 데 필요한 모든 훌륭한 하드웨어를 갖추고 있습니다.