IaaS 고가용성 및 재해 복구 솔루션 살펴보기
IaaS용 Azure에 배포할 수 있는 다양한 기능 조합이 있습니다. 이 섹션에서는 Azure의 SQL Server HADR(고가용성 및 재해 복구) 아키텍처에 관한 다섯 가지 일반적인 예를 다룹니다.
단일 지역 고가용성 예 1 - Always On 가용성 그룹
고가용성만 필요하고 재해 복구는 필요하지 않은 경우 AG(가용성 그룹)를 구성하는 것은 SQL Server를 사용하는 위치에 관계없이 가장 널리 사용되는 방법 중 하나입니다. 아래 이미지는 단일 지역에 있는 1개의 AG가 어떤 모습일지 보여 주는 예입니다.
왜 이 아키텍처는 고려할 만한 가치가 있나요?
이 아키텍처는 여러 VM(가상 머신)에 두 개 이상의 복사본을 보관함으로써 데이터를 보호합니다.
이 아키텍처를 제대로 구현하면 데이터를 최소한으로만 손실하거나 전혀 손실하지 않고 RTO(복구 시간 목표)와 RPO(복구 지점 목표)를 충족할 수 있습니다.
이 아키텍처는 애플리케이션이 주 복제본과 보조 복제본 모두에 액세스할 수 있는 간편하고 표준화된 방법을 제공합니다(읽기 전용 복제본과 같은 항목을 사용할 예정인 경우).
이 아키텍처는 시나리오를 패치하는 과정에서 향상된 가용성을 제공합니다.
이 아키텍처에는 공유 스토리지가 필요하지 않으므로 FCI(장애 조치(failover) 클러스터 인스턴스)를 사용할 때에 비해 복잡성이 덜합니다.
단일 지역 고가용성 예 2 – Always On 장애 조치(failover) 클러스터 인스턴스
AG가 도입될 때까지는 SQL Server 고가용성을 구현하는 데 FCI가 가장 많이 사용되는 방법이었습니다. 그러나 FCI는 물리적 배포가 주로 사용될 때 설계된 것이었습니다. 가상화된 환경에서는 가상 머신에 문제가 거의 발생하지 않기 때문에 FCI는 물리적 하드웨어에서 제공했던 것만큼 많은 보호 기능을 제공하지 않습니다. FCI는 네트워크 카드 오류 또는 디스크 오류와 같은 문제를 방지하기 위해 설계되었는데 두 오류 모두 Azure에서 발생하지 않습니다.
그럼에도 불구하고 FCI는 Azure에서 한 역할을 담당합니다. 무엇이 제공되고 무엇이 제공되지 않는지에 대한 적절한 기대치를 갖고 있는 한, FCI는 더할 나위 없이 훌륭한 솔루션입니다. Microsoft 설명서에서 가져온 아래 이미지는 스토리지 공간 다이렉트를 사용할 때 FCI 배포의 모습이 어떠한지를 개괄적으로 보여줍니다.
왜 이 아키텍처는 고려할 만한 가치가 있나요?
FCI는 여전히 널리 사용되는 가용성 솔루션입니다.
Azure 공유 디스크와 같은 기능을 통해 공유 스토리지는 점점 발전하고 있습니다.
이 아키텍처는 고가용성을 위한 대부분의 RTO 및 RPO를 충족합니다(재해 복구는 처리되지 않음).
이 아키텍처는 애플리케이션이 SQL Server의 클러스터된 인스턴스에 액세스할 수 있는 간편하고 표준화된 방법을 제공합니다.
이 아키텍처는 시나리오를 패치하는 과정에서 향상된 가용성을 제공합니다.
재해 복구 예 1 – 다중 지역 또는 하이브리드 Always On 가용성 그룹
AG를 사용 중인 경우 한 가지 옵션은 여러 Azure 지역에 걸쳐 AG를 구성하거나 잠재적으로 하이브리드 아키텍처로 구성하는 것입니다. 즉, 복제본이 포함된 모든 노드가 동일한 WSFC에 참여하는 것입니다. 이 옵션은 특히 하이브리드 구성인 경우 네트워크 연결이 양호할 것을 전제로 합니다. 가장 중요한 고려 사항 중 하나는 WSFC의 감시 리소스입니다. 이 아키텍처를 사용하려면 하이브리드 솔루션인 경우뿐만 아니라 모든 지역과 잠재적으로 온-프레미스에서도 AD DS 및 DNS가 제공되어야 합니다. 아래 이미지는 Windows Server를 사용할 때 두 위치에 구성된 단일 AG의 모습이 어떠한가를 보여줍니다.
왜 이 아키텍처는 고려할 만한 가치가 있나요?
이 아키텍처는 검증된 솔루션으로, 현재 AG 토폴로지에 두 개의 데이터 센터를 가지고 있는 것과 다를 바 없습니다.
이 아키텍처는 SQL Server의 Standard 및 Enterprise Edition에서 작동합니다.
일반적으로 AG는 데이터의 추가 복사본을 사용하여 중복성을 제공합니다.
이 아키텍처는 HA와 D/R을 모두 제공하는 하나의 기능을 사용합니다.
재해 복구 예 2 – 분산형 가용성 그룹
분산형 AG는 SQL Server 2016에 도입된 Enterprise Edition 전용 기능으로, 기존 AG와는 다릅니다. 이전 예에서 설명한 것처럼 기본 WSFC를 가지고 있어 여기에 있는 모든 노드에 한 개의 AG에 참여하는 복제본이 포함되어 있는 것과 달리, 분산형 AG는 여러 AG로 구성됩니다. 읽기/쓰기 데이터베이스가 포함되어 있는 주 복제본을 전역 기본이라고 합니다. 보조 AG의 기본은 전달자라고 하며 해당 AG의 보조 복제본을 동기화 상태로 유지합니다. 본질적으로 AG의 AG인 것입니다.
이 아키텍처를 사용하면 각 클러스터에서 자체 쿼럼을 유지 관리하므로 쿼럼과 같은 작업을 더 쉽게 처리할 수 있습니다. 즉, 각 클러스터가 자체 미러링 모니터를 갖게 되는 것입니다. 분산형 AG는 모든 리소스에 대해 Azure를 사용 중인지 또는 하이브리드 아키텍처를 사용 중인지 여부에 관계없이 작동합니다.
아래 이미지는 분산형 AG 구성의 예를 보여 줍니다. 두 개의 WSFC가 있습니다. 각 WSFC가 서로 다른 Azure 지역에 있거나 한 개는 온-프레미스에 있고 다른 한 개는 Azure에 있다고 가정해 보겠습니다. WSFC마다 두 개의 복제본을 가진 AG가 있습니다. AG 1의 전역 기본은 AG 1의 보조 복제본을 AG 2의 기본이기도 한 전달자와 함께 동기화 상태를 유지시킵니다. 해당 복제본은 AG 2의 보조 복제본을 동기화 상태로 유지시킵니다.
왜 이 아키텍처는 고려할 만한 가치가 있나요?
이 아키텍처는 모든 노드의 통신이 끊길 경우 WSFC를 단일 실패 지점으로 분리합니다.
이 아키텍처에서는 한 개의 주 복제본이 모든 보조 복제본을 동기화하지는 않습니다.
이 아키텍처는 한 위치에서 다른 위치로 장애 복구를 제공할 수 있습니다.
재해 복구 예 3 - 로그 전달
로그 전달은 SQL Server에 재해 복구를 구성하는 가장 오래된 HADR 방법 중 하나입니다. 위에서 설명한 대로 측정 단위는 트랜잭션 로그 백업입니다. 데이터가 손실되지 않도록 웜 대기로의 전환을 계획하지 않으면 데이터 손실이 발생할 가능성이 큽니다. 재해 복구와 관련해서는 항상 최소한일지라도 일부 데이터는 손실된다고 가정하는 것이 좋습니다. Microsoft 설명서에서 가져온 아래 이미지는 로그 전달 토폴로지의 예를 보여 줍니다.
왜 이 아키텍처는 고려할 만한 가치가 있나요?
로그 전달은 유효성이 증명된 기능으로, 20년 이상 널리 사용되어 왔습니다.
로그 전달은 백업 및 복원을 기반으로 하기 때문에 배포하고 관리하기가 쉽습니다.
로그 전달은 강력하지 않은 네트워크에서도 작동합니다.
로그 전달은 DR에 대한 대부분의 RTO 및 RPO 목표를 충족합니다.
로그 전달은 FCI를 보호하기에 좋은 방법입니다.
재해 복구 예 4 – Azure Site Recovery
SQL Server 기반 재해 솔루션을 구현하고 싶지 않은 경우 Azure Site Recovery가 옵션이 될 수 있습니다. 그러나 대부분의 데이터 전문가는 일반적으로 RPO가 더 낮은 데이터베이스 중심 접근 방식을 선호합니다.
Microsoft 설명서에서 가져온 아래 이미지는 Azure Portal 중 어디에서 Azure Site Recovery에 대한 복제를 구성하는지를 보여 줍니다.
왜 이 아키텍처는 고려할 만한 가치가 있나요?
Azure Site Recovery는 SQL Server 외의 네트워크에서도 작동합니다.
Azure Site Recovery는 RTO 및 RPO를 충족할 수 있습니다.
Azure Site Recovery는 Azure 플랫폼의 일부로 제공됩니다.