멀티 리전 재해 복구를 위한 Microsoft SQL Server 배포

이 가이드에서는 두 Google Cloud 리전 간에 재해 복구(DR) 솔루션으로 Microsoft SQL Server 데이터베이스 시스템을 배포 및 관리하고 장애가 발생한 데이터베이스 인스턴스에서 정상적으로 작동하는 인스턴스로 장애 조치하는 방법을 설명합니다. 이 문서에서 재해는 기본 데이터베이스에 장애가 발생하거나 사용할 수 없는 상태를 의미합니다.

기본 데이터베이스는 데이터베이스가 위치한 리전에 장애가 발생하거나 액세스할 수 없는 상태가 되었을 때 장애가 발생할 수 있습니다. 리전을 사용할 수 있고 정상적으로 작동하더라도 시스템 오류로 인해 기본 데이터베이스에 장애가 발생할 수 있습니다. 이럴 때 재해 복구는 처리를 계속하기 위해 보조 데이터베이스를 클라이언트에 제공하는 과정을 의미합니다.

이 가이드는 데이터베이스 설계자, 관리자, 엔지니어를 대상으로 합니다.

목표

Microsoft SQL Server의 AlwaysOn 가용성 그룹을 사용하여 Google Cloud에 멀티 리전 재해 복구 환경을 배포합니다.
재해 이벤트를 시뮬레이션하고 전체 재해 복구 프로세스를 수행하여 재해 복구 구성을 검사합니다.

비용

이 문서에서는 비용이 청구될 수 있는 다음과 같은 Google Cloud 구성요소를 사용합니다.

프로젝트 사용량을 기준으로 예상 비용을 산출하려면 가격 계산기를 사용하세요. Google Cloud를 처음 사용하는 사용자는 무료 체험판을 사용할 수 있습니다.

이 문서에 설명된 태스크를 완료했으면 만든 리소스를 삭제하여 청구가 계속되는 것을 방지할 수 있습니다. 자세한 내용은 삭제를 참조하세요.

시작하기 전에

이 가이드에는 Google Cloud 프로젝트가 필요합니다. 새 프로젝트를 만들거나 기존에 만든 프로젝트를 선택할 수 있습니다.

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector
Make sure that billing is enabled for your Google Cloud project.
In the Google Cloud console, activate Cloud Shell.

Activate Cloud Shell

재해 복구 이해

Google Cloud에서 재해 복구(DR)는 특히 리전에 장애가 발생하거나 액세스할 수 없을 때 연속적인 처리 기능을 제공하는 것입니다. 데이터베이스 관리 시스템과 같은 시스템에 대해 최소 2개 이상의 리전에 시스템을 배포하여 DR을 구현합니다. 이렇게 설정하면 한 리전을 사용할 수 없게 되어도 시스템이 계속 작동합니다.

데이터베이스 시스템 재해 복구

기본 데이터베이스 인스턴스에 장애가 발생할 때 보조 데이터베이스를 사용할 수 있게 만드는 프로세스를 데이터베이스 재해 복구(또는 데이터베이스 DR)라고 합니다. 이 개념에 대한 자세한 내용은 Microsoft SQL Server 재해 복구를 참조하세요. 이상적으로 보조 데이터베이스 상태는 기본 데이터베이스가 사용할 수 없게 된 시점에 기본 데이터베이스와 일치합니다. 또는 보조 데이터베이스에 기본 데이터베이스의 최근 트랜잭션 일부만 누락됩니다.

재해 복구 아키텍처

Microsoft SQL Server에서 다음 다이어그램은 데이터베이스 DR을 지원하는 최소한의 아키텍처를 보여줍니다.

기본 및 보조 인스턴스가 R1 리전의 두 영역 간에 배치되고, 보조 인스턴스 하나가 R2 리전에 배치됩니다.

그림 1. Microsoft SQL Server의 표준 재해 복구 이키텍처.

이 아키텍처의 동작은 다음과 같습니다.

Microsoft SQL Server의 두 인스턴스(기본 인스턴스와 보조 인스턴스)가 동일한 리전(R1)에 배치되지만 영역은 서로 다릅니다(A 및 B 영역). R1에 있는 두 인스턴스는 동기 커밋 모드를 사용하여 해당 상태를 조정합니다. 동기 모드가 사용되는 이유는 고가용성을 지원하고 데이터를 일관적인 상태로 유지하기 때문입니다.
Microsoft SQL Server의 한 인스턴스(보조 또는 재해 복구 인스턴스)가 두 번째 리전(R2)에 배치됩니다. DR을 위해 R2의 보조 인스턴스는 비동기 커밋 모드를 사용하여 R1의 기본 인스턴스와 동기화됩니다. 비동기 모드는 성능상의 이유로 사용됩니다(기본 인스턴스의 커밋 처리 속도에 영향을 주지 않음).

앞의 다이어그램에서 아키텍처는 가용성 그룹을 보여줍니다. 가용성 그룹은 리스너와 함께 사용될 경우 클라이언트가 다음 인스턴스로 경우 클라이언트에 동일한 연결 문자열을 제공합니다.

기본 인스턴스
대기 인스턴스(영역 장애 발생 후)
보조 인스턴스(리전 장애 발생 후 및 보조 인스턴스가 새로운 기본 인스턴스로 전환된 후)

위 아키텍처의 한 가지 변형에서는 첫 번째 리전(R1)에 있는 두 인스턴스를 동일한 영역에 배포합니다. 이 방식은 성능이 향상될 수 있지만 가용성이 높지 않습니다. 단일 영역 중단 시 DR 프로세스를 시작해야 할 수 있습니다.

기본 재해 복구 프로세스

리전을 사용할 수 없으면 DR 프로세스가 시작되고 다른 작동 리전에서 처리가 계속되도록 기본 데이터베이스가 장애 조치됩니다. DR 프로세스에는 리전 장애를 완화하고 사용 가능한 리전에서 실행되는 기본 인스턴스를 설정하기 위해 수동 또는 자동으로 수행해야 하는 작업 단계가 기술됩니다.

기본 데이터베이스 DR 프로세스는 다음 단계들로 구성됩니다.

기본 데이터베이스 인스턴스를 실행하는 첫 번째 리전(R1)이 사용할 수 없는 상태가 됩니다.
운영팀이 재해 상태를 인식하고, 공식적으로 재해를 인정하고, 장애 조치가 필요한지 여부를 결정합니다.
장애 조치가 필요하면 두 번째 리전(R2)에 있는 보조 데이터베이스 인스턴스가 새로운 기본 인스턴스로 설정됩니다.
클라이언트가 새로운 기본 데이터베이스에서 처리를 재개하고 R2의 기본 인스턴스에 액세스합니다.

이러한 기본 프로세스는 작동하는 기본 데이터베이스를 다시 설정하지만, 새 기본 인스턴스에 대기 및 보조 데이터베이스 인스턴스가 포함된 전체 DR 아키텍처를 설정하지 않습니다.e.

재해 복구 프로세스 완료

전체 DR 프로세스는 장애 조치 후 전체 DR 아키텍처를 설정하기 위한 단계를 추가하여 기본 DR 프로세스를 확장합니다. 다음 다이어그램은 전체 데이터베이스 DR 아키텍처를 보여줍니다.

전체 데이터베이스 DR 아키텍처에서는 R2 리전에 있는 보조 인스턴스가 기본 인스턴스가 되고 R3 리전에 새로운 보조 인스턴스가 생성됩니다.

그림 2. 사용할 수 없는 기본 리전(R1)에서 재해 복구.

이 전체 데이터베이스 DR 아키텍처는 다음과 같이 작동합니다.

기본 데이터베이스 인스턴스를 실행하는 첫 번째 리전(R1)이 사용할 수 없는 상태가 됩니다.
운영팀이 재해 상태를 인식하고, 공식적으로 재해를 인정하고, 장애 조치가 필요한지 여부를 결정합니다.
장애 조치가 필요하면 두 번째 리전(R2)에 있는 보조 데이터베이스 인스턴스가 기본 인스턴스로 설정됩니다.
새로운 대기 인스턴스인 또 다른 보조 인스턴스가 생성되고 R2에서 시작되고 기본 인스턴스에 추가됩니다. 대기 인스턴스는 기본 인스턴스와 다른 영역에 배치됩니다. 기본 데이터베이스는 이제 가용성이 높은 2개의 인스턴스(기본 및 대기)로 구성됩니다.
세 번째 리전(R3)에서는 새로운 보조(대기) 데이터베이스 인스턴스가 생성되고 시작됩니다. 이 보조 인스턴스는 R2의 새 기본 인스턴스에 비동기적으로 연결됩니다. 이 시점에서 원래 재해 복구 아키텍처가 다시 생성되고 작동됩니다.

복구된 리전으로 대체

첫 번째 리전(R1)이 온라인으로 전환된 후 새 보조 데이터베이스를 호스팅할 수 있습니다. R1이 곧 사용 가능한 상태가 되면 R3(세 번째 리전) 대신 R1에서 전체 복구 프로세스의 5단계를 구현할 수 있습니다. 이 경우에는 세 번째 리전이 필요하지 않습니다.

다음 다이어그램은 R1이 시간 내에 사용 가능하게 되었을 때의 아키텍처를 보여줍니다.

R1 리전이 시간 내에 복구되면 R1 리전에 보조 인스턴스가 생성됩니다.

그림 3. 장애가 발생한 R1 리전이 다시 사용 가능하게 된 후의 재해 복구.

이 아키텍처에서 복구 단계는 앞의 전체 재해 복구 프로세스에서 설명한 것과 동일하며, R1이 R3 대신 보조 인스턴스의 위치로 사용되는 것만 다릅니다.

SQL Server 버전 선택

이 가이드에서 지원되는 Microsoft SQL Server 버전은 다음과 같습니다.

SQL Server 2016 Enterprise Edition
SQL Server 2017 Enterprise Edition
SQL Server 2019 Enterprise Edition
SQL Server 2022 Enterprise Edition

이 가이드에서는 SQL Server의 AlwaysOn 가용성 그룹 기능이 사용됩니다.

고가용성(HA) Microsoft SQL Server 기본 데이터베이스가 필요하지 않고, 단일 데이터베이스 인스턴스만 기본 인스턴스로 사용해도 충분한 경우에는 다음 SQL Server를 사용할 수 있습니다.

SQL Server 2016 Standard Edition
SQL Server 2017 Standard Edition
SQL Server 2019 Standard Edition
SQL Server 2022 Standard Edition

SQL Server의 2016, 2017, 2019, 2022 버전에서는 Microsoft SQL Server Management Studio가 이미지에 설치되어 있습니다. 따라서 이를 별도로 설치할 필요가 없습니다. 하지만 프로덕션 환경에서는 Microsoft SQL Server Management Studio의 한 인스턴스를 각 리전의 개별 VM에 설치하는 것이 좋습니다. HA 환경을 설정할 때는 한 영역을 사용할 수 없을 때 다른 영역을 사용할 수 있도록 각 영역에 대해 한 번씩 Microsoft SQL Server Management Studio를 설치해야 합니다.

멀티 리전 DR을 위한 Microsoft SQL Server 설정

이 섹션에서는 Microsoft SQL Server에 대한 다음 이미지가 사용됩니다.

Microsoft SQL Server 2016 Enterprise Edition의 경우 sql-ent-2016-win-2016
Microsoft SQL Server 2017 Enterprise Edition의 경우 sql-ent-2017-win-2016
Microsoft SQL Server 2019 Enterprise Edition의 경우 sql-ent-2019-win-2019
Microsoft SQL Server 2022 Enterprise Edition의 경우 sql-ent-2022-win-2022

전체 이미지 목록은 이미지를 참조하세요.

2인스턴스 고가용성 클러스터 설정

SQL Server에 대해 멀티 리전 데이터베이스 DR 아키텍처를 설정하려면 먼저 한 리전에 2인스턴스 고가용성(HA) 클러스터를 만듭니다. 한 인스턴스는 기본 인스턴스로, 다른 인스턴스는 보조 인스턴스로 사용됩니다. 이 단계를 수행하려면 SQL Server AlwaysOn 가용성 그룹 구성의 안내를 따릅니다. 이 가이드에서는 기본 리전(R1으로 표시)에 us-central1이 사용됩니다. 시작하기 전에 다음 고려사항을 검토하세요.

SQL Server AlwaysOn 가용성 그룹 구성의 단계를 따랐으면 동일 리전(us-central1)에 2개의 SQL Server 인스턴스가 생성됩니다. us-central1-a에 기본 SQL Server 인스턴스(node-1)를 배포하고 us-central1-b에 대기 인스턴스(node-2)를 배포해 보겠습니다.
이 튜토리얼에서는 그림 4의 아키텍처를 구현하지만 두 개 이상의 영역에 도메인 컨트롤러를 설정하는 것이 가장 좋습니다. 이렇게 하면 HA 및 DR이 지원되는 데이터베이스 아키텍처를 설정할 수 있습니다. 예를 들어 한 영역에서 중단이 발생해도, 이 영역이 배포된 아키텍처의 단일 장애점이 되지 않습니다.

동기화 모드에서 기본 및 보조 인스턴스는 한 리전의 서로 다른 영역에 배치되며, 비동기 모드의 보조 인스턴스가 또 다른 리전에 배치됩니다.

그림 4. 이 가이드에서 구현된 표준 재해 복구 아키텍처.

재해 복구를 위한 보조 인스턴스 추가

다음으로 세 번째 SQL Server 인스턴스(이름이 node-3인 보조 인스턴스)를 설정하고 네트워크를 다음과 같이 구성합니다.

Windows Server 장애 조치 클러스터 노드의 특수 스크립트를 만듭니다. 이 스크립트는 필요한 Windows 기능을 설치하고 WSFC 및 SQL Server의 방화벽 규칙을 만듭니다. 또한 데이터 디스크를 포맷하고 SQL Server에 대한 데이터 및 로그 폴더를 만듭니다.

cat << "EOF" > specialize-node.ps1

$ErrorActionPreference = "stop"

# Install required Windows features
Install-WindowsFeature Failover-Clustering -IncludeManagementTools
Install-WindowsFeature RSAT-AD-PowerShell

# Open firewall for WSFC
netsh advfirewall firewall add rule name="Allow SQL Server health check" dir=in action=allow protocol=TCP localport=59997

# Open firewall for SQL Server
netsh advfirewall firewall add rule name="Allow SQL Server" dir=in action=allow protocol=TCP localport=1433

# Open firewall for SQL Server replication
netsh advfirewall firewall add rule name="Allow SQL Server replication" dir=in action=allow protocol=TCP localport=5022

# Format data disk
Get-Disk |
 Where partitionstyle -eq 'RAW' |
 Initialize-Disk -PartitionStyle MBR -PassThru |
 New-Partition -AssignDriveLetter -UseMaximumSize |
 Format-Volume -FileSystem NTFS -NewFileSystemLabel 'Data' -Confirm:$false

# Create data and log folders for SQL Server
md d:\Data
md d:\Logs
EOF

다음 변수를 초기화합니다.
```
VPC_NAME=VPC_NAME
SUBNET_NAME=SUBNET_NAME
REGION=us-east1
PD_SIZE=200
MACHINE_TYPE=n2-standard-8
```
각 항목의 의미는 다음과 같습니다.
- VPC_NAME: VPC 이름
- SUBNET_NAME: us-east1 리전의 서브넷 이름

SQL Server 인스턴스를 만듭니다.

gcloud compute instances create node-3 \
--zone $REGION-b \
--machine-type $MACHINE_TYPE \
--subnet $SUBNET_NAME \
--image-family sql-ent-2022-win-2022 \
--image-project windows-sql-cloud \
--tags wsfc,wsfc-node \
--boot-disk-size 50 \
--boot-disk-type pd-ssd \
--boot-disk-device-name "node-3" \
--create-disk=name=node-3-datadisk,size=$PD_SIZE,type=pd-ssd,auto-delete=no \
--metadata enable-wsfc=true \
--metadata-from-file=sysprep-specialize-script-ps1=specialize-node.ps1

새 SQL Server 인스턴스에 대해 Windows 비밀번호를 설정합니다.
1. Google Cloud 콘솔에서 Compute Engine 인스턴스 페이지로 이동합니다.
  
  Compute Engine으로 이동
2. Compute Engine 클러스터 node-3의 연결 열에서 Windows 비밀번호 설정 드롭다운 목록을 선택합니다.
3. 사용자 이름과 비밀번호를 설정합니다. 나중에 사용할 수 있도록 기록해 둡니다.
RDP를 클릭하여 node-3 인스턴스에 연결합니다.
이전 단계에서 설정한 사용자 이름과 비밀번호를 입력한 후 확인을 클릭합니다.
인스턴스를 Windows 도메인에 추가합니다.
1. Start(시작) 버튼을 마우스 오른쪽 버튼으로 클릭하고(또는 Win+X 누름) Windows PowerShell(관리자)을 클릭합니다.
2. '예'를 클릭하여 권한 승격 프롬프트를 확인합니다.
3. 컴퓨터를 Active Directory 도메인에 연결하고 다시 시작합니다.
```
Add-Computer -Domain DOMAIN -Restart
```
  DOMAIN을 Active Directory 도메인의 DNS 이름으로 바꿉니다.
  
  다시 시작이 완료될 때까지 1분 정도 기다립니다.

장애 조치 클러스터에 보조 인스턴스 추가

그런 후 Windows 장애 조치 클러스터에 보조 인스턴스(node-3)를 추가합니다.

RDP를 사용하여 node-1 또는 node-2 인스턴스에 연결하고 관리자 사용자로 로그인합니다.
관리자 사용자로 PowerShell 창을 열고 이 튜토리얼의 클러스터 환경에 대한 변수를 설정합니다.
```
$node3 = "node-3"
$nameWSFC = "SQLSRV_CLUSTER" # Name of cluster 
```
SQLSRV_CLUSTER를 SQL Server 클러스터의 이름으로 바꿉니다.
클러스터에 보조 인스턴스를 추가합니다.
```
Get-Cluster | WHERE Name -EQ $nameWSFC | Add-ClusterNode -NoStorage -Name $node3
```
이 명령어를 실행하는 데 시간이 걸릴 수 있습니다. 프로세스가 응답하지 않고 자동으로 반환되지 않을 수 있으므로 이따금 Enter를 누르세요.
노드에서 AlwaysOn 고가용성 기능을 사용 설정합니다.
```
Enable-SqlAlwaysOn -ServerInstance $node3 -Force
```

노드가 이제 장애 조치 클러스터에 포함됩니다.

보조 인스턴스를 기존 가용성 그룹에 추가합니다.

그런 후 SQL Server 인스턴스(보조 인스턴스) 및 데이터베이스를 가용성 그룹에 추가합니다.

원격 데스크톱을 사용하여 node-3에 연결합니다. 도메인 사용자 계정으로 로그인합니다.
SQL Server 구성 관리자를 엽니다.
탐색창에서 SQL Server 서비스를 선택합니다.
서비스 목록에서 SQL Server(MSSQLSERVER)를 마우스 오른쪽 버튼으로 클릭하고 속성을 선택합니다.
다음으로 로그온에서 계정을 변경합니다.
- 계정 이름: DOMAIN\sql_server. 여기서 DOMAIN은 Active Directory 도메인의 NetBIOS 이름입니다.
- 비밀번호: 이전에 sql_server 도메인 계정에 대해 선택한 비밀번호를 입력합니다.
확인을 클릭합니다.
SQL Server를 다시 시작하라는 메시지가 표시되면 예를 선택합니다.
3개 인스턴스 노드(node-1, node-2, node-3)에서 Microsoft SQL Server Management Studio를 열고 기본 인스턴스(node-1)에 연결합니다.
1. 객체 탐색기로 이동합니다.
2. 연결 드롭다운 목록을 선택합니다.
3. Database Engine을 선택합니다.
4. 서버 이름 드롭다운 목록에서 node-1을 선택합니다. 클러스터가 나열되지 않으면 필드에 입력합니다.
새 쿼리를 클릭합니다.

참고: 분산 네트워크 이름을 사용하여 AlwaysOn 가용성 그룹을 설정한 경우에는 9단계와 10단계가 필요하지 않습니다.
다음 명령어를 붙여 넣어서 노드에 사용되는 리스너에 IP 주소를 추가한 후 실행을 클릭합니다.
```
ALTER AVAILABILITY GROUP [bookshelf-ag] MODIFY LISTENER 'bookshelf' (ADD IP ('LOAD_BALANCER_IP_ADDRESS', '255.255.255.0'))
```
LOAD_BALANCER_IP_ADDRESS를 us-east1 리전에 있는 부하 분산기의 IP 주소로 바꿉니다.
객체 탐색기에서 AlwaysOn 고가용성 노드를 확장한 후 가용성 그룹 노드를 확장합니다.
이름이 bookshelf-ag인 가용성 그룹을 마우스 오른쪽 버튼으로 클릭한 후 복제본 추가를 선택합니다.
소개 페이지에서 AlwaysOn 고가용성 노드를 클릭한 후 가용성 그룹 노드를 클릭합니다.
복제본에 연결 페이지에서 연결을 클릭하여 기존 보조 복제본 node-2에 연결합니다.
복제본 지정 페이지에서 복제본 추가를 클릭한 후 새 노드 node-3을 추가합니다. 자동 장애 조치는 동기 커밋을 일으키므로 자동 장애 조치를 선택하지 마세요. 이러한 설정은 리전 경계를 넘어서며, 이는 권장되지 않는 방식입니다.
데이터 동기화 선택 페이지에서 자동 시드를 선택합니다.

리스너가 없기 때문에 검사 페이지에 경고가 생성되지만, 이는 무시해도 됩니다.
마법사 단계를 완료합니다.

node-1 및 node-2의 장애 조치 모드는 자동이고 node-3의 경우에는 수동입니다. 이러한 차이는 재해 복구와 고가용성을 구별하기 위한 한 가지 방법입니다.

가용성 그룹이 이제 준비되었습니다. 고가용성을 위한 2개 노드와 재해 복구를 위한 세 번째 노드가 구성되었습니다.

재해 복구 시뮬레이션

이 섹션에서는 이 가이드의 재해 복구 아키텍처를 테스트하고 선택사항인 DR 구현을 고려합니다.

장애 시뮬레이션 및 DR 장애 조치 수행

기본 리전의 장애 또는 서비스 중단을 시뮬레이션합니다.
1. node-1의 Microsoft SQL Server Management Studio에서 node-1에 연결합니다.
2. 테이블을 만듭니다. 이후 단계에 복제본을 추가한 후 이 테이블이 있는지 여부를 확인하여 복제본이 작동하는지 확인합니다.
```
USE bookshelf
GO
CREATE TABLE dbo.TestTable_Before_DR (ID INT NOT NULL)
GO
```
3. Cloud Shell의 기본 리전(us-central1)에서 두 서버를 종료합니다.
```
gcloud compute instances stop node-2 --zone us-central1-b --quiet
gcloud compute instances stop node-1 --zone us-central1-a --quiet
```
참고: 오류를 만드는 또 다른 방법은 node-1 및 node-2를 실행하는 VM을 중지하는 것입니다. 이 방식은 정상적인 인스턴스 종료 대신 하드 오류를 시뮬레이션합니다.
node-3의 Microsoft SQL Server Management Studio에서 node-3에 연결합니다.
장애 조치를 실행하고 가용성 모드를 동기 커밋으로 설정합니다. 노드가 비동기 커밋 모드이므로 장애 조치를 강제 적용해야 합니다.
```
ALTER AVAILABILITY GROUP [bookshelf-ag] FORCE_FAILOVER_ALLOW_DATA_LOSS
GO
ALTER AVAILABILITY GROUP [bookshelf-ag]
MODIFY REPLICA ON 'node-3' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT)
GO
```
처리를 재개할 수 있습니다. node-3가 이제 기본 인스턴스입니다.
(선택사항) node-3에서 새 테이블을 만듭니다. 복제본을 새 기본 인스턴스와 동기화한 후 이 테이블이 복제본에 복제되었는지 확인합니다.
```
USE bookshelf
GO
CREATE TABLE dbo.TestTable_After_DR (ID INT NOT NULL)
GO
```

이 시점에서는 node-3이 기본이지만 원래 리전으로 돌아가거나 완전한 DR 아키텍처를 다시 만들기 위해 새로운 보조 인스턴스 및 대기 인스턴스를 설정해야 할 수도 있습니다. 다음 섹션에서는 이러한 옵션들에 대해 설명합니다.

(선택사항) 트랜잭션을 완전히 복제하는 DR 아키텍처 다시 만들기

이 사용 사례에서는 기본 데이터베이스에 장애가 발생하기 전 기본 데이터베이스에서 보조 데이터베이스로 모든 트랜잭션이 복제되는 장애 상황을 다룹니다. 이 이상적인 시나리오에서는 데이터가 전혀 손실되지 않습니다. 보조 데이터베이스의 상태는 장애 시점에 기본 데이터베이스와 일치합니다.

이 시나리오에서는 두 가지 방법으로 완전한 DR 아키텍처를 다시 만들 수 있습니다.

원래 기본 및 원래 대기(사용 가능한 경우)로 돌아갑니다.
원래 기본 및 대기를 사용할 수 없는 경우를 대비하여 node-3에 대해 새로운 대기 및 보조를 만듭니다.

방법 1: 원래 기본 및 대기로 돌아가기

Cloud Shell에서 원래(이전) 기본 및 대기를 시작합니다.

gcloud compute instances start node-1 --zone us-central1-a --quiet
gcloud compute instances start node-2 --zone us-central1-b --quiet

Microsoft SQL Server Management Studio에서 node-1 및 node-2를 보조 복제본으로 추가합니다.

node-3에서 비동기 커밋 모드로 2개 서버를 추가합니다.

USE [master]
GO
ALTER AVAILABILITY GROUP [bookshelf-ag]
MODIFY REPLICA ON 'node-1' WITH (FAILOVER_MODE = MANUAL)
GO
ALTER AVAILABILITY GROUP [bookshelf-ag]
MODIFY REPLICA ON 'node-1' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT)
GO
ALTER AVAILABILITY GROUP [bookshelf-ag]
MODIFY REPLICA ON 'node-2' WITH (FAILOVER_MODE = MANUAL)
GO
ALTER AVAILABILITY GROUP [bookshelf-ag]
MODIFY REPLICA ON 'node-2' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT)
GO

node-1에서 데이터베이스 동기화를 다시 시작합니다.
```
USE [master]
GO
ALTER DATABASE [bookshelf] SET HADR RESUME;
GO
```
node-2에서 데이터베이스 동기화를 다시 시작합니다.
```
USE [master]
GO
ALTER DATABASE [bookshelf] SET HADR RESUME;
GO
```

node-1을 다시 기본으로 만듭니다.

node-3에서 node-1의 가용성 모드를 동기 커밋으로 변경합니다. node-1 인스턴스가 다시 기본이 됩니다.

USE [master]
GO
ALTER AVAILABILITY GROUP [bookshelf-ag]
MODIFY REPLICA ON 'node-1' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT)
GO

node-1에서 node-1을 기본으로 변경하고 다른 2개 노드를 보조로 변경합니다.

USE [master]
GO
-- Node 1 becomes primary
ALTER AVAILABILITY GROUP [bookshelf-ag] FORCE_FAILOVER_ALLOW_DATA_LOSS;
GO

-- Node 2 has synchronous commit
ALTER AVAILABILITY GROUP [bookshelf-ag]
MODIFY REPLICA ON 'node-2' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT)
GO

-- Node 3 has asynchronous commit
ALTER AVAILABILITY GROUP [bookshelf-ag]
MODIFY REPLICA ON 'node-3' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT)
GO

모든 명령어가 성공하면 다음 다이어그램에 표시된 것처럼 node-1이 기본이 되고 다른 노드는 보조가 됩니다.

객체 탐색기에 가용성 그룹이 표시됩니다.

방법 2: 새로운 기본 및 대기 설정

장애로부터 원래 기본 및 대기 인스턴스를 복구하지 못하거나 복구하는 데 시간이 너무 오래 걸리거나 해당 리전에 액세스하지 못하게 될 경우도 있습니다. 한 가지 방법은 node-3을 기본으로 유지하고 다음 다이어그램에 표시된 것처럼 새로운 대기 및 새로운 보조 인스턴스를 만드는 것입니다.

대기 인스턴스는 개별 영역이지만 기본과 동일한 리전에 생성되고, 보조 인스턴스는 개별 리전에 생성됩니다.

그림 5. 원래 기본 리전 R1을 사용할 수 없는 경우의 재해 복구.

이 구현을 위해서는 다음을 수행해야 합니다.

us-east1에서 node-3을 기본으로 유지합니다.
us-east1의 다른 영역에 새로운 대기 인스턴스(node-4)를 추가합니다. 이 단계에서는 새로운 배포를 고가용성으로 설정합니다.
개별 리전(예: us-west2)에 새로운 보조 인스턴스(node-5)를 만듭니다. 이 단계에서는 재해 복구를 위해 새로운 배포를 설정합니다. 전체 배포가 이제 완료되었습니다. 데이터베이스 아키텍처가 HA 및 DR을 완전히 지원합니다.

(선택사항) 트랜잭션이 누락된 경우 대체 실행

기본에서 커밋된 하나 이상의 트랜잭션이 장애 시점(하드 오류라고도 부름)에 보조로 복제되지 않는 경우는 덜 이상적인 장애 상태입니다. 장애 조치 단계에서 복제되지 않은 모든 커밋된 트랜잭션이 손실됩니다.

이 시나리오의 장애 조치 단계를 테스트하기 위해서는 하드 오류를 일으켜야 합니다. 하드 오류를 일으키는 가장 좋은 방법은 다음과 같습니다.

기본 및 보조 인스턴스가 연결되지 않도록 네트워크를 변경합니다.
테이블 추가 또는 일부 데이터 삽입 등의 방법으로 기본을 변경합니다.
보조가 새로운 기본이 되도록 앞에서 설명한 대로 장애 조치 프로세스를 진행합니다.

장애 조치 프로세스 단계가 이상적인 시나리오의 단계와 동일하지만 네트워크 연결이 중단된 후 기본에 추가된 테이블이 보조에 표시되지 않는다는 것만 다릅니다.

하드 오류를 해결하기 위한 유일한 옵션은 가용성 그룹에서 복제본(node-1 및 node-2)을 삭제하고 복제본을 다시 동기화하는 것입니다. 동기화하면 보조와 일치하도록 상태가 변경됩니다. 오류 이전에 복제되지 않은 트랜잭션은 모두 손실됩니다.

node-1을 보조 인스턴스로 추가하기 위해서는 이전에 node-3을 추가할 때와 동일한 단계(장애 조치 클러스터에 보조 인스턴스 추가 참조)를 따르면 되지만, 한 가지 차이가 있습니다. 지금은 node-1이 아닌 node-3이 기본입니다. node-3의 인스턴스를 가용성 그룹에 추가하는 서버 이름으로 바꿔야 합니다. 동일한 VM(node-1 및 node-2)을 사용할 경우에는 서버를 Windows Server 장애 조치 클러스터에 추가할 필요가 없습니다. SQL Server 인스턴스만 다시 가용성 그룹에 추가합니다.

이 시점에서는 node-3이 기본이고 node-1 및 node-2는 보조입니다. 이제 node-1로 돌아가서 node-2를 대기로, node-3을 보조로 만들 수 있습니다. 시스템 상태는 이제 오류 이전과 동일합니다.

자동 장애 조치

보조 인스턴스를 기본으로 설정하여 자동으로 장애 조치하면 문제가 발생할 수 있습니다. 원래 기본이 다시 사용 가능하게 된 후 일부 클라이언트가 보조에 액세스하고 다른 클라이언트는 복원된 기본에 쓰기를 수행하는 분할 브레인 상황이 발생할 수 있습니다. 이 경우 기본 및 보조가 병렬로 업데이트되고 상태가 달라집니다. 이 상황을 방지하기 위해, 이 튜토리얼에서는 사용자가 장애 조치 여부(또는 시점)를 결정하는 수동 장애 조치 지침을 제공합니다.

자동 장애 조치를 구현할 경우에는 구성된 인스턴스 중 하나만 기본이 되고 수정될 수 있도록 해야 합니다. 모든 대기 또는 보조 인스턴스는 상태 복제를 위한 기본을 제외하고 모든 클라이언트에 쓰기 액세스를 제공하지 않아야 합니다. 또한 후속 장애 조치가 단시간 내에 연속적으로 급하게 수행되지 않도록 해야 합니다. 예를 들어 5분 간격으로 장애 조치를 수행하는 것은 믿을 만한 재해 복구 전략이 되지 않습니다. 자동 장애 조치 프로세스를 위해서는 이와 같이 문제가 될 만한 시나리오의 대비책을 마련하고, 경우에 따라 복잡한 의사결정이 필요하면 데이터베이스 관리자의 도움도 요청해야 합니다.

대체 배포 아키텍처

이 가이드에서는 다음 다이어그램에 표시된 것처럼 장애 조치 시 기본 인스턴스가 되는 보조 인스턴스가 포함된 재해 복구 아키텍처를 설정합니다.

동기화 모드에서 기본 및 보조 인스턴스는 한 리전의 서로 다른 영역에 배치되며, 비동기 모드의 보조 인스턴스가 또 다른 리전에 배치됩니다.

그림 6. Microsoft SQL Server를 사용하는 표준 재해 복구 이키텍처.

즉, 장애 조치 시 결과 배포에는 대체가 가능할 때까지 또는 대기(HA용) 및 보조(DR용)를 구성할 때까지 단일 인스턴스가 포함됩니다.

대체 배포 아키텍처는 2개의 보조 인스턴스를 구성하는 것입니다. 두 인스턴스 모두 기본의 복제본입니다. 장애 조치가 수행될 때 보조 중 하나를 대기로 다시 구성할 수 있습니다. 다음 다이어그램은 장애 조치 이전 및 이후의 배포 아키텍처를 보여줍니다.

2개의 보조 인스턴스가 R2 리전의 개별 영역에 배치됩니다.

그림 7. 2개의 보조 인스턴스가 포함된 표준 재해 복구 아키텍처.

장애 조치 후에는 R2 리전에 있는 보조 인스턴스 중 하나가 대기 인스턴스가 됩니다.

그림 8. 장애 조치 후 2개의 보조 인스턴스가 포함된 표준 재해 복구 아키텍처.

여전히 2개의 보조 중 하나를 대기로 만들어야 하지만(그림 8), 이 프로세스는 처음부터 새 대기를 만들고 구성하는 것보다 훨씬 빠릅니다.

또한 2개의 보조 인스턴스를 사용하는 이 아키텍처와 동일한 설정으로 DR을 해결할 수도 있습니다. 두 번째 리전에 2개의 보조를 배포하는 것 외에도(그림 7) 세 번째 리전에 또 다른 2개의 보조를 배포할 수 있습니다. 이 설정을 사용하면 기본 리전에 오류가 발생한 후 HA 및 DR 지원 배포 아키텍처를 효율적으로 만들 수 있습니다.

삭제

이 가이드에서 사용한 리소스 비용이 Google Cloud 계정에 청구되지 않도록 하려면 다음 안내를 따르세요.

프로젝트 삭제

In the Google Cloud console, go to the Manage resources page.
Go to Manage resources
In the project list, select the project that you want to delete, and then click Delete.
In the dialog, type the project ID, and then click Shut down to delete the project.

다음 단계

Google Cloud에 대한 참조 아키텍처, 다이어그램, 권장사항 살펴보기 Cloud 아키텍처 센터를 살펴보세요.