듀얼 멀티존 지역 배포 패턴

WSFC(Windows Server 장애 조치 클러스터) 노드로 구성된 IBM Cloud Windows Server 2019 Standard 가상 서버와 각 노드에 SQL Server Always On 가용성 그룹이 구성된 SQL Server Enterprise 에디션은 이중 MZR(다중 영역 영역) 배포 패턴의 기초를 형성합니다. 이 아키텍처는 MS ADDNS와 함께 재해 복구를 위한 SQL Server 배포를 제공합니다.

표시된 이중 MZR 배포 패턴은 이중 가용 영역(AZ) 패턴을 활용하고 이를 확장하여 원격 지역에 데이터베이스 복사본이 있도록 하므로 재해 복구가 필요한 운영 데이터베이스에 적합하며 다음과 같은 핵심 기술을 활용합니다:

서브넷이 두 개의 MZR에 있는 IBM Cloud VPC.
보안 그룹은 컴포넌트 간의 트래픽 흐름을 제어하는 데 사용됩니다.
서버에 대한 관리 액세스에 사용되는 하나 이상의 배스티온 호스트입니다.
인터넷 액세스를 허용하기 위해 배스티온 호스트에 연결된 플로팅 IP(FIP)입니다.
동일한 포리스트\도메인의 Active Directory 도메인 컨트롤러인 세 대의 Windows Server 2019 Standard 가상 서버(기본 MZR의 각 AZ와 복구 MZR에 하나씩)가 있습니다.
기본 MZR의 각 AZ에 하나씩, 그리고 복구 MZR에 세 번째 가상 서버인 3개의 Windows Server 2019 표준 가상 서버가 WSFC(Windows Server 장애 조치 클러스터) 노드가 됩니다.
상시 가동 가용성 그룹은 하나 이상의 클러스터 노드에서 개별 데이터베이스 집합을 고가용성으로 유지하고 데이터베이스 수준에서 작업할 수 있는 기능을 제공합니다. 가용성 그룹은 하나의 기본 복제본과 최대 8개의 보조 복제본으로 구성되며 동기식 또는 비동기식 데이터 복제를 사용합니다. 이 배포에서는
- 기본 MZR의 두 AZ 간에 사용되는 동기식 복제 iOS.
- mZR 간에 비동기 복제가 사용됩니다.
분산 네트워크 이름은 WSFC 및 Always On 가용성 그룹의 이름 리소스로, 클러스터 리소스의 이름 확인에 사용됩니다.

이 배포에서는 노드 수가 홀수이고 Node 과반수 쿼럼 모드가 사용되므로 파일 공유 감시가 필요하지 않습니다

Windows Server 장애 조치 클러스터

Windows에서 HA를 위한 Always On 가용성 그룹을 배포하려면 WSFC(Windows 서버 장애 조치 클러스터)가 필요합니다. 가용성 그룹의 각 가용성 복제본은 WSFC의 다른 노드에 있어야 합니다. 가용성 데이터베이스에 대한 보안 구성을 간소화하려면 SQL Server 인스턴스(서비스 계정)를 도메인 서비스 계정으로 실행하는 것이 좋습니다.

WSFC(Windows Server 장애 조치 클러스터)는 Windows Server 기능으로, 클러스터 노드 역할을 하는 각 서버는 이 기능을 사용하도록 설정해야 합니다. WSFC는 '두뇌 분열' 증후군을 방지하기 위해 정족수 투표에 의존하며, 여러 가지 정족수 모드가 있습니다:

Node 과반수 - 활성 클러스터 노드가 쿼럼을 결정합니다. 클러스터가 건강한 상태를 유지하려면 가능한 투표의 절반 이상이 찬성이어야 합니다.
Node 및 파일 공유 과반수 - 원격 파일 공유는 정족수 투표에 참여하는 활성 노드에 대한 투표 감시자 역할을 합니다. Node 과반수와 마찬가지로, 클러스터가 정상 상태를 유지하려면 가능한 투표의 절반 이상이 찬성이어야 합니다.
Node 및 디스크 과반수 - 공유 디스크는 정족수 투표에 참여하는 활성 노드와 함께 투표 감시자 역할을 합니다.
디스크 전용 - 공유 디스크가 감시자 역할을 하며 디스크에 액세스할 수 있는 노드에 따라 쿼럼이 결정됩니다. 최소 투표 수는 필요하지 않습니다.

SQL Server에 대한 Microsoft 권장 사항은 다음과 같습니다:

투표 노드 수가 홀수인 경우 Node 과반수 정족수 모드를 사용합니다.
투표 노드 수가 짝수인 경우 Node 및 파일 공유 과반수 정족수 모드를 사용하세요.

항상 켜져 있는 가용성 그룹

가용성 그룹은 하나의 기본 데이터베이스 세트와 최대 8개의 보조 데이터베이스 세트를 지원합니다. 보조 데이터베이스는 백업이 아니므로 정기적으로 데이터베이스와 해당 트랜잭션 로그를 백업하는 것이 중요합니다. 항상 켜짐 가용성 그룹에는 다음 세 가지 클러스터 유형 옵션(WSFC, EXTERNAL, 없음) 중 하나가 필요합니다.

WSFC - WSFC(Windows Server 장애 조치 클러스터)를 사용하여 클러스터 장애 조치를 관리합니다. 이는 Windows 서버의 고가용성 그룹을 위한 전제 조건입니다.
외부 - 외부 클러스터 관리자를 사용합니다. 예를 들어 Linux SQL Server Pacemaker 지원합니다. Linux 클러스터의 가용성 그룹은 HA를 보장하기 위해 최소 2개의 동기식 복제본이 필요하지만 자동 복구를 위해서는 최소 3개의 복제본이 필요하므로 최소 3개의 노드에 가용성 그룹을 설정하는 것이 좋습니다.
없음 - 클러스터 없는 가용성 그룹으로 알려져 있거나 처음에는 읽기 규모 가용성 그룹이라고 불렀습니다. 그러나 이 옵션은 가용성 그룹 기능의 하위 집합만 제공하며 자동 장애 조치는 포함되지 않습니다. 이 기능에는 수동 계획 및 강제 장애 조치, 동기식 및 비동기식 복제 모드, 읽기 가능한 보조 노드, 보조 복제본 백업이 포함되어 있습니다. WSFC 클러스터가 없는 가용성 그룹은 여전히 읽기 가능한 보조 노드, 읽기 전용 라우팅 및 부하 분산 기능을 제공할 수 있습니다. 페일오버는 외부 도구를 사용하여 자동화할 수 있습니다. SQL Server 2019의 새로운 기능은 읽기/쓰기 트래픽을 기본 노드로 다시 라우팅하고 수신기가 필요하지 않은 자동 트래픽 리디렉션을 통해 이 문제를 완화합니다.

다음 용어는 가용성 그룹 개념을 설명하는 데 사용됩니다:

가용성 그룹 - 개별 사용자 데이터베이스 집합에 대해 복제된 환경을 지원합니다.
HA 가용성 그룹 - 함께 장애 조치되는 데이터베이스 그룹입니다.
읽기 규모 가용성 그룹 - 읽기 전용 워크로드를 위해 SQL Server 다른 인스턴스에 복사되는 데이터베이스 그룹입니다.
기본 복제본 - 클라이언트의 읽기-쓰기 연결에 기본 데이터베이스를 사용할 수 있게 하고 각 기본 데이터베이스의 트랜잭션 로그 레코드를 모든 보조 데이터베이스로 보냅니다.
보조 복제본 - 최대 8개의 보조 복제본으로, 각 복제본은 보조 데이터베이스 세트를 호스팅하고 HA 가용성 그룹의 잠재적 장애 조치 대상으로 사용됩니다.

동기화 모드

가용성 그룹 보조 복제본은 다음 동기화 모드 중 하나를 사용하여 구성할 수 있습니다:

동기식 - 기본 복제본에 트랜잭션이 커밋되기 전에 모든 보조 복제본에서 로그가 강화됩니다(트랜잭션이 트랜잭션 로그에 커밋됨). 네트워크 지연 시간이 길면 트랜잭션이 많은 워크로드에 성능에 영향을 미칠 수 있는 데이터 손실이 전혀 발생하지 않습니다. AG당 두 개의 동기 커밋 복제본을 가질 수 있습니다. 이 모드는 동일한 AZ 또는 MZR에 있는 인스턴스에 가장 적합합니다.
비동기 - 트랜잭션이 기본 복제본의 트랜잭션 로그에 굳어지는 즉시 커밋된 것으로 간주합니다. 모든 보조 복제본에서 로그가 강화되기 전에 문제가 발생하면 데이터 손실이 발생할 수 있으며, 복구 지점은 모든 보조 복제본에서 성공한 가장 최근에 커밋된 트랜잭션이 됩니다. 이 모드는 서로 다른 MZR에 있는 인스턴스 또는 AZ와 온프레미스 사이에 있는 인스턴스에 더 적합합니다.

장애 조치 모드

가용성 그룹이 장애 조치되면 보조 복제본이 새로운 기본 복제본이 되고, 사용 가능한 경우 기본 복제본이 보조 복제본이 됩니다.

자동 장애 조치 - 자동 장애 조치는 HA를 제공하며 성공을 위해 적절하게 구성된 리스너 및 WSFC 개체에 의존합니다. 동기 커밋 가용성 모드 복제본만 자동 장애 조치의 대상이 될 수 있습니다. 자동 장애 조치가 시작되는 조건을 1~5단계로 구성할 수 있으며, 여기서 1은 기본 복제본의 SQL Server 서비스가 완전히 중단된 경우에만 장애 조치가 시작됨을 나타내고, 5는 심각하지 않은 SQL Server 오류 중 하나라도 발생하면 장애 조치가 시작됨을 나타냅니다. 기본값은 3으로, 정전 또는 기본 복제본이 응답하지 않는 경우 자동 장애 메시지가 표시되지만 일부 중요한 서버 상태의 경우에도 마찬가지입니다. 이러한 '유연한 장애 조치 정책' 조건은 상시 가동 가용성 그룹에 대한 유연한 자동 장애 조치 정책 구성에 자세히 설명되어 있습니다.
계획된 장애 조치 - 계획된 장애 조치는 데이터 손실 가능성이 없는 경우에만 수행할 수 있습니다. 즉, 코드나 SSMS 대화 상자에서 경고를 확인하기 위해 FORCE 매개 변수를 사용하지 않고 장애 조치가 수행된다는 의미입니다. 동기 커밋 가용성 모드에서는 보조 복제본에 대한 계획된 장애 조치만 가능합니다. 비동기 커밋 가용성 모드 복제본을 동기식으로 이동하고 동기화 상태를 기다린 다음 데이터 손실 없이 계획된 장애 조치를 실행할 수 있습니다. 계획된 장애 조치는 항상 SSMS, T-SQL 또는 PowerShell 통해 시작해야 합니다.
강제 장애 조치 - 수동으로 시작하는 강제 장애 조치는 기본 노드 손실과 같은 불리한 클러스터 조건에 대한 대응으로만 시작해야 합니다. SSMS 마법사, T-SQL 명령 또는 PowerShell 시작하고 최후의 수단으로 Windows Server 장애 조치 클러스터 관리자에서만 시작하세요.
WSFC 쿼럼이 다운된 경우 강제 장애 조치 - WSFC에 쿼럼이 없는 경우 WSFC를 기반으로 하는 가용성 그룹에 대해 강제 장애 조치를 수행할 수 없습니다. 먼저 구성 관리자에서 투표를 '조작'하고 노드 가중치를 수정하여 정족수를 강제 설정해야 합니다. 이 단계는 재해로 인해 대부분의 클러스터 노드가 중단된 경우와 같은 긴급 상황에서만 고려해야 합니다. 과반수 득표 없이도 온라인 노드가 주 역할을 맡도록 하기 위해 PowerShell 스크립트를 사용하여 이 작업을 수행할 수 있습니다.

장애 조치는 데이터 파일의 손실이나 트랜잭션 로그의 손상으로 인해 데이터베이스가 의심되는 등의 데이터베이스 문제로 인해 발생하는 것이 아닙니다.

기타 유형의 가용성 그룹

다음 가용성 그룹은 이 배포 패턴에서 사용되지는 않지만 이 배포 패턴을 적용하거나 확장하려는 솔루션 제공업체가 관심을 가질 수 있습니다:

기본 가용성 그룹 - 가용성 그룹의 제한된 버전으로 SQL Server Standard 버전에서만 지원됩니다. 단일 보조 복제본은 읽거나 백업할 수 없으며 각 기본 가용성 그룹은 2개의 복제본만 지원할 수 있지만 서버당 여러 개의 기본 가용성 그룹을 구성할 수 있습니다. 기본 가용성 그룹은 동기식 또는 비동기식 복제, 수동 또는 자동 장애 조치 등 가용성 그룹과 동일한 많은 기능을 사용할 수 있습니다.
분산 가용성 그룹 - 한 가용성 그룹이 다른 가용성 그룹을 보조 복제본으로 취급할 수 있도록 합니다. 읽기 전용 보조 복제본을 전 세계적으로 분산하여 지역별 읽기 전용 보조 복제본으로 워크로드를 오프로드할 수 있습니다. 각각 자체 수신기가 있는 두 가용성 그룹은 동일한 네트워크 또는 WSFC에 있을 필요가 없습니다. 이를 통해 다중 사이트 배포에서 지리적으로 원격으로 HA 및 DR을 사용할 수 있습니다. 가용성 그룹이 분산되어 있으면 WSFC가 여러 지역에 걸쳐 있을 필요가 없습니다. 기본 가용성 그룹과 보조 가용성 그룹 간에는 자동 장애 조치가 없습니다. 기본이 아닌 가용성 그룹은 읽기 전용 쿼리만 제공할 수 있지만 기본 복제본 자체는 있습니다. 보조 가용성 그룹의 기본 복제본은 보조 가용성 그룹의 다른 보조 복제본에 트랜잭션을 복제하는 작업을 담당합니다. 이 아키텍처는 각 가용성 그룹에 서로 다른 버전의 Windows Server를 보유할 수 있으므로 OS 및 SQL Server 버전 업그레이드에 유용합니다. 분산 시나리오의 각 가용성 그룹에는 자체 수신기가 있지만 분산 가용성 그룹 전체에는 수신기가 없습니다. 애플리케이션은 DNS 별칭을 사용하여 장애 조치 후 각 가용성 그룹에 직접 연결하여 읽기 가능한 보조 복제본을 활용할 수 있습니다.

분산 네트워크 이름

이 배포에서는 클러스터 리소스의 이름 확인에 사용되는 WSFC 및 Always On 가용성 그룹의 이름 리소스인 DNN(분산 네트워크 이름)을 사용합니다. 노드의 IP 주소와 별도의 IP 주소가 필요하지 않고 장애가 발생할 때 네트워크에서 무료 주소 확인 프로토콜(GARP)을 사용할 필요가 없다는 점에서 표준 네트워크 이름 리소스와 다릅니다. Windows Server 2019에서는 Active Directory 도메인 서비스의 CNO(클러스터 이름 개체)이기도 한 WSFC의 이름과 데이터베이스 수신기를 모두 DNN으로 만들 수 있습니다.