ASR(Azure Site Recovery)을 사용하여 클러스터 저장소에 SIOS DataKeeper를 사용하는 WSFC(Windows Server 장애 조치 클러스터)를 복제하는 방법

소개

따라서 SQL Server FCI(장애 조치 클러스터 인스턴스) 또는 Azure에 SAP ASCS/ERS 클러스터를 구축했습니다. 클러스터의 각 노드는 서로 다른 가용 영역(AZ)에 상주하거나 지연 요구 사항이 엄격하고 PPG(배치 근접 그룹)를 사용 중이고 모든 노드가 동일한 가용 세트에 상주할 수 있습니다. 시나리오에 관계없이 이제 단일 인스턴스를 실행하는 것보다 비즈니스 크리티컬 애플리케이션에 대해 훨씬 더 높은 수준의 가용성을 갖게 되었습니다.

이제 당신이 가지고 고가용성(HA) 덮여, 당신은 무엇을 할거야 재해 복구 ? 여러 AZ를 없애는 지역 재해는 드물지만 최근 역사에서 알 수 있듯이 대자연은 정말 큰 타격을 줄 수 있습니다. 전체 지역이 오프라인 상태가 될 경우에 대비해야 합니다.

ASR(Azure Site Recovery)은 한 지역에서 다른 지역으로 전체 VM을 복제할 수 있는 Microsoft의 DRaaS(재해 복구) 제품입니다. 또한 온프레미스에서 Azure로 가상 머신 및 물리적 서버를 복제할 수 있지만 이 블로그 게시물의 목적을 위해 Azure 지역 간 DR 기능에 중점을 둘 것입니다.

Azure Site Recovery 설정

다음을 사용하여 클러스터를 이미 구축했다고 가정합니다. SIOS 데이터 키퍼 . 그렇지 않은 경우 시작하는 데 도움이 되는 몇 가지 지침이 있습니다.

Azure VM에서 SQL Server를 사용하는 장애 조치(failover) 클러스터 인스턴스 SAP ASCS/SCS 클러스터 공유 디스크용 SIOS DataKeeper Cluster Edition 또한 Azure Site Recovery에 익숙하다고 가정합니다. ASR 설정에 대한 또 다른 가이드 대신 최신 선적 서류 비치 마이크로소프트에서. 대신 이 문서에서는 고려하지 않았을 수 있는 몇 가지 사항과 다른 서브넷으로 장애 조치(failover)한 후 클러스터를 수정하는 데 필요한 특정 단계에 초점을 맞춥니다.

페어링된 영역

DR 경로를 시작하기 전에 Azure 쌍으로 된 지역의 개념을 알고 있어야 합니다. Azure의 모든 지역에는 기본 DR 지역이 있습니다. 페어링된 지역에 대해 자세히 알아보려면 선적 서류 비치 훌륭한 배경을 제공합니다. 정말 좋은 것들도 있어요 혜택 짝을 이룬 지역을 사용하는 것이 중요하지만 DR 사이트를 호스팅하는 데 사용할 지역을 결정하는 것은 전적으로 귀하에게 달려 있습니다.

클라우드 감시 위치

처음에 클러스터를 구축할 때 쿼럼에 대한 감시 유형을 선택해야 했습니다. 파일 공유 감시 또는 클라우드 감시를 선택했을 수 있습니다. 일반적으로 이러한 감시 유형 중 하나는 클러스터 노드와 별도의 AZ에 있어야 합니다.

그러나 재해 발생 시 전체 클러스터가 DR 지역에서 실행된다는 점을 고려할 때 더 나은 옵션이 있습니다. 클라우드 감시를 사용하고 DR 지역에 배치해야 합니다. 클라우드 감시를 DR 지역에 배치하면 로컬 AZ 오류에 대한 복원력을 제공할 뿐만 아니라 전체 지역에 오류가 발생하고 ASR을 사용하여 DR 지역에서 클러스터를 복구해야 하는 경우에도 보호할 수 있습니다. Dynamic Quorum 및 Dynamic Witness의 마법을 통해 DR 지역이 일시적으로 오프라인 상태가 되더라도 프로덕션 클러스터에 영향을 미치지 않을 것임을 확신할 수 있습니다.

다중 VM 일관성

ASR을 사용하여 클러스터를 복제할 때 활성화하는 것이 중요합니다. 다중 VM 일관성 각 클러스터 노드의 복구 지점이 동일한 시점에 있는지 확인합니다. 이렇게 하면 VM 간에 발생하는 DataKeeper 블록 수준 복제가 완전한 재동기화 없이 복구 후에도 계속될 수 있습니다.

크래시 일관된 복구 지점

애플리케이션 일관성 복구 지점은 복제된 클러스터에서 지원되지 않습니다. ASR 복제 옵션을 구성할 때 애플리케이션 일관성 복구 지점을 활성화하지 마십시오.

장애 조치 후 IP 주소를 유지하시겠습니까?

ASR을 사용하여 DR 사이트에 복제할 때 VM의 IP 주소를 동일하게 유지하는 방법이 있습니다. Microsoft는 제목의 기사에서 설명했습니다. 장애 조치 중 IP 주소 유지 . 장애 조치 후 IP 주소를 동일하게 유지할 수 있으면 IP 주소를 기반으로 하는 클러스터 IP 주소 또는 DataKeeper 미러 엔드포인트를 수정할 필요가 없으므로 복구 프로세스가 간소화됩니다.

그러나 내 경험상 실제로 위의 지침을 따르는 사람을 본 적이 없으므로 다른 서브넷에서 클러스터를 복구하려면 복구 후 클러스터를 온라인으로 전환하기 전에 몇 가지 추가 단계가 필요합니다.

첫 번째 장애 조치 시도

복구 계획

다중 VM 일관성을 사용하고 있으므로 복구 계획을 사용하여 VM을 장애 조치해야 합니다. 그만큼 선적 서류 비치 그렇게 하는 방법에 대한 매우 간단한 지침을 제공합니다. 복구 계획은 함께 복구하려는 VM을 그룹화하여 모두 함께 장애 조치되도록 합니다. 여러 VM 그룹을 동일한 복구 계획에 추가하여 전체 인프라가 순서대로 장애 조치되도록 할 수도 있습니다.

복구 계획은 장애 조치가 복구를 성공적으로 완료할 수 있도록 사후 복구 스크립트를 실행할 수도 있습니다. 아래에 설명하는 단계는 모두 복구 계획의 일부로 스크립팅되어 전체 복구 프로세스를 완전히 자동화할 수 있습니다. 이 블로그 게시물에서 해당 프로세스를 다루지는 않겠지만 Microsoft 이 프로세스를 문서화 .

고정 IP 주소

복구 프로세스의 일부로 새 VM에 고정 IP 주소가 있는지 확인하려고 합니다. VM이 항상 동일한 주소를 사용하도록 Azure Portal에서 인터페이스 속성을 조정해야 합니다. 공용 IP 주소를 인터페이스에 추가하려면 이때도 추가해야 합니다.

네트워크 구성

복제된 VM이 DR 사이트에서 성공적으로 복구된 후 가장 먼저 해야 할 일은 기본 연결을 확인하는 것입니다. IP 구성이 정확합니까? 인스턴스가 올바른 DNS 서버를 사용하고 있습니까? 이름 확인이 올바르게 작동합니까? 원격 서버를 ping할 수 있습니까?

네트워크 통신에 문제가 있는 경우 아래에 설명된 나머지 단계는 실패할 수밖에 없습니다. 이 단계를 건너뛰지 마세요!

로드 밸런서

아시다시피 Azure의 클러스터를 사용하려면 클라이언트 연결이 작동하도록 부하 분산 장치를 구성해야 합니다. 로드 밸런서는 복구 계획의 일부로 장애 조치되지 않습니다. 이 새 vNet에 현재 상주하는 클러스터를 기반으로 새 로드 밸런서를 빌드해야 합니다. 이 작업을 수동으로 수행하거나 복구 계획의 일부로 스크립트를 작성하여 자동으로 수행할 수 있습니다.

네트워크 보안 그룹

이 새 서브넷에서 실행한다는 것은 이러한 인스턴스에 적용할 네트워크 보안 그룹을 지정해야 함을 의미합니다. 인스턴스가 필요한 포트를 통해 통신할 수 있는지 확인해야 합니다. 이 작업을 수동으로 수행할 수도 있지만 복구 계획의 일부로 스크립트를 작성하는 것이 좋습니다.

IP 클러스터 주소 수정

동일한 서브넷에서 인스턴스를 복구하기 위해 앞에서 설명한 변경을 수행할 수 없는 경우 다음 단계를 완료하여 새 서브넷에서 사용할 클러스터 IP 주소와 DataKeeper 주소를 업데이트해야 합니다.

모든 클러스터에는 코어 클러스터 IP 주소가 있습니다. 장애 조치(failover) 후 WSFC UI를 시작하면 클러스터가 연결할 수 없다는 것을 보게 됩니다. 클러스터에서 사용하는 IP 주소가 새 서브넷에서 유효하지 않기 때문입니다.

해당 IP 주소 리소스의 속성을 열면 IP 주소를 새 서브넷에서 작동하는 것으로 변경할 수 있습니다. 네트워크 및 서브넷 마스크도 업데이트해야 합니다.

해당 IP 주소를 수정하면 클러스터 리소스에서 사용하는 다른 클러스터 주소에 대해서도 동일한 작업을 수행해야 합니다.

DataKeeper 미러 주소 수정

SIOS DataKeeper 미러는 IP 주소를 미러 끝점으로 사용합니다. 이는 미러 및 미러 작업에 저장됩니다. 다른 서브넷에서 DataKeeper 기반 클러스터를 복구하면 미러가 재동기화 보류 상태로 나타나는 것을 볼 수 있습니다. 또한 원본 IP와 대상 IP가 DR 사이트의 서브넷이 아닌 원래 서브넷을 반영한다는 것을 알 수 있습니다.

이 문제를 해결하려면 SIOS에서 CHANGEMIRRORENDPOINTS . CHANGEMIRRORENDPOINTS의 사용법은 다음과 같습니다.

emcmd <NEW 소스 IP> CHANGEMIRRORENDPOINTS <볼륨 문자> <ORIGINAL 대상 IP> <NEW 소스 IP> <NEW 대상 IP> 이 예에서 명령 및 출력은 다음과 같습니다.

명령이 실행되면 DataKeeper GUI가 아래와 같이 새 IP 주소를 반영하도록 업데이트됩니다. 미러도 미러링 상태가 됩니다.

결론

이제 고가용성을 위한 SIOS DataKeeper와 재해 복구를 위한 Azure Site Recovery의 조합을 사용하여 비즈니스 크리티컬 애플리케이션의 재해 복구를 성공적으로 구성하고 테스트했습니다. 질문이 있거나 SQL Server, SAP ASCS 및 ERS, SAP HANA, Oracle 또는 기타 비즈니스 크리티컬 애플리케이션과 같은 비즈니스 크리티컬 애플리케이션을 위한 고가용성 및 재해 복구를 설계 및 구현하는 데 도움이 되도록 SIOS에 문의하려면, 저희에게 연락주세요 .