이 페이지는 Cloud Translation API를 통해 번역되었습니다.

Always On 가용성 그룹 및 Pacemaker를 사용하여 Linux에서 SQL Server 클러스터 설정

이 튜토리얼에서는 Always On 가용성 그룹(AOAG) 및 Pacemaker를 고가용성(HA) 및 재해 복구(DR) 솔루션으로 사용하여 Linux에 Microsoft SQL Server 데이터베이스 시스템을 배포하는 방법을 설명합니다. 이 문서에서 재해는 기본 데이터베이스에 장애가 발생하거나 사용할 수 없는 상태를 의미합니다.

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

이 튜토리얼은 데이터베이스 설계자, 관리자, 엔지니어를 대상으로 합니다.

목표

Linux에 SQL Server 배포
고가용성 및 재해 복구를 위한 Always On 가용성 그룹 만들기
Pacemaker를 설치하고 구성하여 SQL Server 클러스터의 장애 조치 관리
SQL Server를 사용하여 가용성 그룹으로 트래픽을 라우팅하도록 부하 분산기 구성
HA 무결성 보장을 위해 STONITH(Shoot The Other Node In The Head) 펜스 설정
장애 조치 테스트를 수행하여 SQL Server 클러스터가 예상대로 작동하는지 확인

비용

이 튜토리얼에서는 비용이 청구될 수 있는 다음과 같은 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
Google Cloud 프로젝트에 결제가 사용 설정되어 있는지 확인합니다.
Google Cloud 프로젝트에 NetApp Cloud Volumes API가 사용 설정되어 있는지 확인합니다.
Google Cloud 콘솔에서 Cloud Shell을 활성화합니다.

Cloud Shell 활성화

프로젝트 및 네트워크 준비

SQL Server AlwaysOn 가용성 그룹을 배포할 수 있도록 Google Cloud 프로젝트와 VPC를 준비하려면 다음을 수행합니다.

Google Cloud 콘솔에서 Cloud Shell 활성화 버튼을 클릭하여 Cloud Shell을 엽니다.

Google Cloud Console로 이동
기본 프로젝트 ID를 설정합니다.
```
gcloud config set project PROJECT_ID
```
PROJECT_ID를 Google Cloud 프로젝트의 ID로 바꿉니다.
기본 리전을 설정합니다.
```
gcloud config set compute/region REGION
```
REGION을 배포하려는 리전의 ID로 바꿉니다.
기본 영역을 설정합니다.
```
gcloud config set compute/zone ZONE
```
ZONE을 배포하려는 영역의 ID로 바꿉니다. 이전 단계에서 지정한 리전의 유효한 영역이어야 합니다.

Linux VM 만들기

SQL Server 클러스터의 HA 및 쿼럼을 구현하려면 SQL Server 클러스터를 호스팅할 Linux 가상 머신(VM) 3개를 배포합니다.

다음 변수를 초기화합니다.
```
PD_SIZE=30
MACHINE_TYPE=n2-standard-8
```

Linux VM을 만듭니다.

gcloud compute instances create node-1 \
--project=PROJECT_ID \
--zone REGION-a \
--machine-type $MACHINE_TYPE \
--subnet SUBNET_NAME \
--create-disk=auto-delete=yes,boot=yes,device-name=node-1,image=projects/ubuntu-os-cloud/global/images/ubuntu-2004-focal-v20240426,mode=rw,size=$PD_SIZE,type=projects/PROJECT_ID/zones/ZONE/diskTypes/pd-balanced \
--scopes=https://www.googleapis.com/auth/compute,https://www.googleapis.com/auth/servicecontrol,https://www.googleapis.com/auth/service.management.readonly,https://www.googleapis.com/auth/logging.write,https://www.googleapis.com/auth/monitoring.write,https://www.googleapis.com/auth/trace.append,https://www.googleapis.com/auth/devstorage.read_write

gcloud compute instances create node-2 \
--project=PROJECT_ID \
--zone REGION-b \
--machine-type $MACHINE_TYPE \
--subnet SUBNET_NAME \
--create-disk=auto-delete=yes,boot=yes,device-name=node-2,image=projects/ubuntu-os-cloud/global/images/ubuntu-2004-focal-v20240426,mode=rw,size=$PD_SIZE,type=projects/PROJECT_ID/zones/ZONE/diskTypes/pd-balanced \
--scopes=https://www.googleapis.com/auth/compute,https://www.googleapis.com/auth/servicecontrol,https://www.googleapis.com/auth/service.management.readonly,https://www.googleapis.com/auth/logging.write,https://www.googleapis.com/auth/monitoring.write,https://www.googleapis.com/auth/trace.append,https://www.googleapis.com/auth/devstorage.read_write

gcloud compute instances create node-3 \
--project=PROJECT_ID \
--zone REGION-c \
--machine-type $MACHINE_TYPE \
--subnet SUBNET_NAME \
--create-disk=auto-delete=yes,boot=yes,device-name=node-3,image=projects/ubuntu-os-cloud/global/images/ubuntu-2004-focal-v20240426,mode=rw,size=$PD_SIZE,type=projects/PROJECT_ID/zones/ZONE/diskTypes/pd-balanced \
--scopes=https://www.googleapis.com/auth/compute,https://www.googleapis.com/auth/servicecontrol,https://www.googleapis.com/auth/service.management.readonly,https://www.googleapis.com/auth/logging.write,https://www.googleapis.com/auth/monitoring.write,https://www.googleapis.com/auth/trace.append,https://www.googleapis.com/auth/devstorage.read_write

서브넷 SUBNET_NAME을 VPC 서브넷 이름으로 바꿉니다.

node-1, node-2, node-3에서 호스트 파일을 업데이트합니다.

참고: 프로덕션 용도로 사용하는 경우 전용 DNS(도메인 이름 시스템) 서버에서 도메인 확인을 관리해야 합니다.
1. SSH를 사용하여 각 VM에 연결합니다. 자세한 내용은 Linux VM에 연결 문서를 참조하세요.
2. 수정할 호스트 파일을 엽니다.
```
sudo vi /etc/hosts
```
3. 각 Linux VM의 내부 IP 주소를 찾고 호스트 항목을 파일 하단에 추가합니다.
  
  Compute Engine으로 이동
```
NODE1_INTERNAL_IP node-1
NODE2_INTERNAL_IP node-2
NODE3_INTERNAL_IP node-3
```
  NODE1_INTERNAL_IP, NODE2_INTERNAL_IP, NODE3_INTERNAL_IP를 각 Linux VM의 내부 IP 주소로 바꿉니다.
VM 간의 통신을 확인합니다. Always On 가용성 그룹에 참여하는 모든 VM은 다른 VM과 통신할 수 있어야 합니다.
1. 각 Linux VM으로 돌아가서 각 VM에서 명령어를 실행하고 모든 VM이 서로 통신할 수 있는지 확인합니다.
```
ping -c 4 node-1
ping -c 4 node-2
ping -c 4 node-3
```

SQL Server 설치 및 구성

Always On 가용성 그룹에 참여할 Linux VM 3개에 SQL Server 엔진을 다운로드, 설치, 구성합니다.

node-1, node-2, node-3에 SSH로 연결하고 다음 단계를 실행합니다.

공개 저장소 키를 가져옵니다.

wget -qO- https://packages.microsoft.com/keys/microsoft.asc \
| sudo tee /etc/apt/trusted.gpg.d/microsoft.asc

SQL Server Ubuntu 저장소를 등록합니다.

sudo add-apt-repository \
"$(wget -qO- https://packages.microsoft.com/config/ubuntu/20.04/mssql-server-2019.list)"

패키지 색인 파일을 업데이트하고 SQL Server를 설치합니다.
```
sudo apt-get update
sudo apt-get install -y mssql-server
```

SQL Server를 구성합니다.
1. mssql-conf 도구를 실행합니다.
```
sudo /opt/mssql/bin/mssql-conf setup
```
2. SQL Server 개발자 버전을 선택하고 라이선스 계약에 동의합니다.
  
  개발자 버전에는 모든 엔터프라이즈 기능이 포함되어 있지만 비프로덕션 환경에서만 사용할 수 있습니다. SQL Server 버전 및 Microsoft 라이선스에 관한 자세한 정보를 확인할 수 있습니다.
  
  참고: VM 인스턴스마다 SQL Server 라이선스가 필요합니다. Microsoft 애플리케이션 서버를 실행 중인 경우 소프트웨어 보증을 통한 라이선스 이동을 사용하여 Google Cloud로 전환할 수 있습니다. 자세한 내용은 Microsoft 서버 애플리케이션을 통한 라이선스 이동 사용을 참조하세요. 사용자 라이선스를 사용하지 않고 Google(PAYG)을 통해 라이선스를 구매해야 하는 경우 부팅 디스크에 SQL Server 라이선스 추가의 단계에 따라 각 VM 인스턴스의 라이선스를 구매해야 합니다.
3. SA 계정의 비밀번호를 지정합니다.
4. mssql-server 서비스가 실행 중인지 확인합니다.
```
systemctl status mssql-server --no-pager
```
VM에 방화벽이 사용 설정되어 있으면 SQL Server용 방화벽을 엽니다.
1. 다음 명령어를 실행하여 Uncomplicated Firewall이 설치되어 있고 사용 설정되었는지 확인합니다.
```
sudo ufw status
```
2. 활성 상태이면 다음 명령어를 실행하여 포트를 엽니다.
```
sudo ufw allow 1433
sudo ufw allow 5022
sudo ufw reload
```
  참고: SQL Server 또는 가용성 그룹 엔드포인트에 다른 포트를 사용하는 경우 방화벽 규칙을 적절히 변경합니다.

SQL Server에 연결

이제 SQL Server가 설치되었습니다. 연결하려면 동일한 VPC에서 Windows 머신을 만들고 SQL Server Management Studio(SSMS)를 설치하여 VM에서 새로 만든 SQL Server 인스턴스에 연결합니다.

Windows VM을 만듭니다.

Cloud Shell로 돌아가서 다음 명령어를 실행합니다.

gcloud compute instances create node4 \
--project=PROJECT_ID \
--zone ZONE \
--subnet SUBNET_NAME \
--machine-type=n2-standard-4 \
--create-disk=auto-delete=yes,boot=yes,device-name=node4,image=projects/windows-cloud/global/images/windows-server-2022-dc-v20240415,mode=rw,size=50,type=projects/p3rf-sqlserver/zones/ZONE/diskTypes/pd-balanced

원격 데스크톱을 사용하여 node-4의 Windows VM에 연결합니다.
node-4의 호스트 파일을 업데이트합니다.
1. 관리자 모드에서 메모장을 엽니다.
2. 파일 > 열기를 클릭하고 호스트 파일을 엽니다.
```
c:\Windows\System32\drivers\etc\hosts
```
3. 파일 하단에 호스트 항목을 추가합니다.
```
NODE1_INTERNAL_IP node-1
NODE2_INTERNAL_IP node-2
NODE3_INTERNAL_IP node-3
```
  NODE1_INTERNAL_IP, NODE2_INTERNAL_IP, NODE3_INTERNAL_IP를 각 VM의 해당 내부 IP 주소로 바꿉니다.
4. 저장 후 종료합니다.
Linux VM에 대한 연결을 확인합니다.
1. node-4의 Windows VM에 연결
2. 시작 버튼을 클릭하고 검색창에 powershell을 입력합니다.
3. 클릭하여 Windows PowerShell ISE 앱을 엽니다.
4. 다음 명령어를 실행하여 연결을 테스트합니다.
```
ping node-1
ping node-2
ping node-3
```
다음 단계에 따라 Microsoft SQL Server Management Studio(SSMS)를 설치합니다.
1. 원격 데스크톱을 사용하여 node-4의 Windows VM에 연결합니다.
2. RDP 세션에서 모든 창을 최소화하고 Windows PowerShell ISE 앱을 시작합니다.
3. PowerShell 프롬프트에서 SSMS 설치 프로그램을 다운로드하고 실행합니다.
```
Start-BitsTransfer `
-Source "https://aka.ms/ssmsfullsetup" `
-Destination "$env:Temp\ssms-setup.exe"
& $env:Temp\ssms-setup.exe
```
4. SSMS 설치 프로그램에서 설치를 클릭합니다.
5. 프롬프트를 수락하면 변경사항이 적용됩니다.
6. 설치가 완료되면 다시 시작을 클릭하여 원격 머신을 다시 시작합니다. 그러면 RDP 세션이 종료됩니다.
node-1의 SQL Server 인스턴스에 연결합니다.
1. RDP를 사용하여 node-4 VM으로 돌아갑니다.
2. SSMS를 열고 다음 매개변수를 사용하여 node-1에 연결합니다.
```
Server name: node-1
Authentication: SQL Server Authentication
Login: sa
```
  자세한 내용은 SQL Server Management Studio 문서를 사용하여 SQL Server 인스턴스에 연결을 참조하세요.
3. 설치 중에 만든 SA 계정의 비밀번호를 입력합니다.
4. 서버 인증서 신뢰를 선택합니다.
5. 연결을 클릭합니다.

Always On 가용성 그룹 사용 설정

Linux에서는 가용성 그룹을 먼저 만들어야 Pacemaker에서 관리할 리소스로 해당 가용성 그룹을 추가할 수 있습니다.

가용성 그룹에 참여하는 각 SQL Server 인스턴스에 대해 Always On 가용성 그룹 기능을 사용 설정합니다. node-1, node-2, node-3에서 다음 명령어를 실행합니다.

참고: 변경사항을 적용하려면 mssql-server 서비스를 다시 시작합니다.
```
sudo /opt/mssql/bin/mssql-conf set hadr.hadrenabled 1
sudo systemctl restart mssql-server
```
SSMS를 사용하여 가용성 그룹의 기본 호스트인 인스턴스에 연결합니다.

팁: node-1을 기본 호스트로 선택하는 것이 좋습니다.
1. 새 쿼리 창을 엽니다.
2. 다음 코드 스니펫을 실행하여 암호화 키, 인증서, 비공개 키를 만듭니다.
  
  팁: 암호화 키와 비공개 키에 안전한 비밀번호를 선택하세요. 나중에 사용할 수 있도록 이 비밀번호를 기억해 두세요.
  참고: 비밀번호는 8자 이상이어야 하며 대문자, 소문자, 십진법 숫자, 기호 중 3가지를 포함해야 합니다.
```
USE MASTER;

CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'ENCRYPTION_KEY_PASSWORD';
CREATE CERTIFICATE my_ag_certificate WITH SUBJECT = 'my_ag_cert';
BACKUP CERTIFICATE my_ag_certificate
TO FILE = '/var/opt/mssql/data/my_ag_certificate.cer'
WITH PRIVATE KEY (
    FILE = '/var/opt/mssql/data/my_ag_certificate.pvk',
    ENCRYPTION BY PASSWORD = 'PRIVATE_KEY_PASSWORD'
);
```
  ENCRYPTION_KEY_PASSWORD 및 PRIVATE_KEY_PASSWORD를 암호화 키와 비공개 키의 비밀번호로 바꿉니다.

인증서 및 키 파일 전송

이전 단계에서 만든 인증서 및 키 파일을 SQL Server의 보조 노드로 이동해야 합니다. 인증서와 키 파일을 node-2 및 node-3의 보조 노드로 이동하는 방법에는 여러 가지가 있습니다.

기타 전송 옵션은 Linux VM으로 파일 전송을 참조하세요.

Cloud Storage를 사용하여 인증서 및 키 파일 전송

기본 클러스터 노드에서 보조 클러스터 노드로 파일을 전송할 Cloud Storage를 만듭니다.

Cloud Storage 버킷을 만듭니다.
1. Cloud Shell로 돌아가서 다음 명령어를 실행합니다.
```
gcloud storage buckets create gs://BUCKET_NAME \
--project=PROJECT_ID \
--location=REGION \
--public-access-prevention
```
  BUCKET_NAME을 만들 버킷의 이름으로 바꿉니다. PROJECT_ID을 Google Cloud 프로젝트의 ID로 바꾸고 REGION을 버킷을 배포하려는 리전의 ID로 바꿉니다.
자세한 내용은 버킷 만들기를 참조하세요.
node-1, node-2, node-3의 SSH로 돌아가서 Google Cloud CLI를 초기화합니다.
1. 다음 명령어를 실행하여 Google Cloud CLI를 초기화합니다.
```
gcloud init
```
2. 사전 설치된 서비스 계정을 사용하려면 option [1]을 선택합니다.
3. 프로젝트의 이름을 입력합니다.
4. 질문에 n을 입력하여 기본 리전 및 영역을 설정합니다.
node-1로 돌아가서 파일을 Cloud Storage에 복사합니다.
1. 다음 명령어를 실행하여 새로 만든 파일 2개를 Cloud Storage에 업로드합니다.
```
sudo gsutil cp /var/opt/mssql/data/my_ag_certificate.cer gs://BUCKET_NAME/
sudo gsutil cp /var/opt/mssql/data/my_ag_certificate.pvk gs://BUCKET_NAME/
```
  BUCKET_NAME을 생성된 버킷의 이름으로 바꿉니다.
node-2 및 node-3으로 돌아가서 Cloud Storage의 파일을 복사합니다.
1. Cloud Storage에서 node-2로 두 파일을 다운로드합니다.
```
sudo gsutil cp gs://BUCKET_NAME/my_ag_certificate.cer /var/opt/mssql/data/
sudo gsutil cp gs://BUCKET_NAME/my_ag_certificate.pvk /var/opt/mssql/data/
```
  BUCKET_NAME을 생성된 버킷의 이름으로 바꿉니다.
2. 루트 셸에서 명령어를 실행하여 node-2 및 node-3의 파일 소유권을 변경합니다.
```
chown mssql:mssql /var/opt/mssql/data/my_ag_certificate.*
chmod 660 /var/opt/mssql/data/my_ag_certificate.*
```
  팁: 명령어를 실행한 후 루트 셸을 종료해야 합니다.

데이터베이스 미러링 엔드포인트 설정

이 섹션에서는 안전한 데이터 복제를 보장하기 위해 SQL Server 클러스터의 각 노드에서 공유하는 암호화 키와 인증서를 사용하여 데이터베이스 엔드포인트를 만듭니다.

node-4의 Windows VM으로 돌아가서 데이터베이스 미러링 엔드포인트를 만듭니다.
1. SSMS를 사용하여 node-1, node-2, node-3의 SQL Server 데이터베이스에 연결합니다. node-1, node-2, node-3을 서버 이름으로 사용하고 SA 계정에 설정한 각 비밀번호를 사용하여 SQL Server에 연결의 단계를 따릅니다.
2. 복사한 파일에서 보조 VM node-2 및 node-3에 인증서를 만듭니다. 기본 노드에 인증서와 키를 만들 때 제공한 비밀번호를 사용합니다.
```
USE MASTER;

CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'ENCRYPTION_KEY_PASSWORD';
CREATE CERTIFICATE my_ag_certificate
FROM FILE = '/var/opt/mssql/data/my_ag_certificate.cer'
WITH PRIVATE KEY (
    FILE = '/var/opt/mssql/data/my_ag_certificate.pvk',
    DECRYPTION BY PASSWORD = 'PRIVATE_KEY_PASSWORD'
);
```
  ENCRYPTION_KEY_PASSWORD 및 PRIVATE_KEY_PASSWORD를 암호화 키와 비공개 키의 비밀번호로 바꿉니다.
3. SSMS로 돌아가서 node-1, node-2, node-3에 T-SQL 명령어를 실행하여 데이터베이스 미러링 엔드포인트를 만듭니다.
  
  팁: 기본 리슨 포트는 5022이지만 사용 가능한 다른 포트를 사용할 수 있습니다.
```
CREATE ENDPOINT [my_ag_endpoint]
    AS TCP (LISTENER_PORT = 5022)
    FOR DATABASE_MIRRORING (
        ROLE = ALL,
        AUTHENTICATION = CERTIFICATE my_ag_certificate,
        ENCRYPTION = REQUIRED ALGORITHM AES
    );

ALTER ENDPOINT [my_ag_endpoint] STATE = STARTED;
```

Always On 가용성 그룹 만들기 및 구성

다음으로 SQL Server Management Studio를 사용하여 SQL Server Always On 가용성 그룹을 만들고 이전에 만든 엔드포인트를 복제에 사용합니다.

Windows VM으로 돌아가서 SSMS를 엽니다.
1. node-1에서 SQL Server 데이터베이스 엔진에 연결하고 새 쿼리 창을 엽니다.

데이터베이스를 만들고 복제 준비를 위해 데이터베이스를 백업합니다.

USE MASTER;

CREATE DATABASE [bookshelf];
ALTER DATABASE [bookshelf] SET RECOVERY FULL;
BACKUP DATABASE [bookshelf]
TO DISK = N'/var/opt/mssql/data/bookshelf.bak';

Always On 가용성 그룹을 만듭니다.

node-1, node-2, node-3의 SSMS에서 다음 T-SQL 명령어를 실행합니다. 이렇게 하면 엔드포인트가 사용 설정되고 각 노드의 SQL Server를 데이터 복제에 사용할 수 있습니다.

IF (SELECT state FROM sys.endpoints WHERE name = N'my_ag_endpoint') <> 0
BEGIN
    ALTER ENDPOINT [my_ag_endpoint] STATE = STARTED
END
GO

IF EXISTS(SELECT * FROM sys.server_event_sessions WHERE name='AlwaysOn_health')
BEGIN
    ALTER EVENT SESSION [AlwaysOn_health] ON SERVER WITH (STARTUP_STATE=ON);
END
IF NOT EXISTS(SELECT * FROM sys.dm_xe_sessions WHERE name='AlwaysOn_health')
BEGIN
    ALTER EVENT SESSION [AlwaysOn_health] ON SERVER STATE=START;
END
GO

node-1에서 다음 T-SQL 명령어를 실행하여 AOAG를 만듭니다.

USE [master]
GO

CREATE AVAILABILITY GROUP [aoag1]
WITH (
    AUTOMATED_BACKUP_PREFERENCE = SECONDARY,
    DB_FAILOVER = OFF,
    DTC_SUPPORT = NONE,
    CLUSTER_TYPE = EXTERNAL,
    REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = 0
)
FOR DATABASE [bookshelf]
REPLICA ON N'node-1' WITH (
    ENDPOINT_URL = N'TCP://node-1:5022', FAILOVER_MODE = EXTERNAL, AVAILABILITY_MODE = SYNCHRONOUS_COMMIT, BACKUP_PRIORITY = 50, SEEDING_MODE = AUTOMATIC, SECONDARY_ROLE(ALLOW_CONNECTIONS = NO)),
    N'node-2' WITH (ENDPOINT_URL = N'TCP://node-2:5022', FAILOVER_MODE = EXTERNAL, AVAILABILITY_MODE = SYNCHRONOUS_COMMIT, BACKUP_PRIORITY = 50, SEEDING_MODE = AUTOMATIC, SECONDARY_ROLE(ALLOW_CONNECTIONS = NO)),
    N'node-3' WITH (ENDPOINT_URL = N'TCP://node-3:5022', FAILOVER_MODE = EXTERNAL, AVAILABILITY_MODE = SYNCHRONOUS_COMMIT, BACKUP_PRIORITY = 50, SEEDING_MODE = AUTOMATIC, SECONDARY_ROLE(ALLOW_CONNECTIONS = NO)
);
GO

새 가용성 그룹에 참여할 각 SQL Server 인스턴스의 node-2 및 node-3에 다음 T-SQL 명령어를 실행합니다.

ALTER AVAILABILITY GROUP [aoag1] JOIN WITH (CLUSTER_TYPE = EXTERNAL);
GO

ALTER AVAILABILITY GROUP [aoag1] GRANT CREATE ANY DATABASE;
GO

bookshelf라는 새 데이터베이스를 만들고 node-1에서 실행되는 SQL Server 인스턴스의 aoag1이라는 새 가용성 그룹에 새 데이터베이스를 추가했습니다. Node-2 및 node-3가 가용성 그룹에 추가되었으며 bookshelf 데이터베이스의 데이터는 세 노드 모두에서 SQL Server 인스턴스에 동기식으로 복제됩니다.

Pacemaker 설치 및 구성

Pacemaker는 Corosync Cluster Engine과 함께 사용되는 오픈소스 고가용성 리소스 관리자 소프트웨어입니다. 이 섹션에서는 각 VM에 Pacemaker를 설치하고 구성합니다.

Pacemaker 클러스터 관리자의 SQL Server 로그인 만들기

이 섹션에서는 Pacemaker에서 각 SQL Server 인스턴스에 로그인하고 가용성 그룹을 관리하는 데 사용할 새 SQL Server 계정을 만듭니다.

node-1, node-2, node-3에서 다음 T-SQL 명령어를 실행합니다.
```
USE [master];

CREATE LOGIN [pacemaker] with PASSWORD= N'PACEMAKER_LOGIN_PASSWORD';
GO
```
PACEMAKER_LOGIN_PASSWORD를 Pacemaker 계정의 비밀번호로 바꿉니다.

T-SQL 명령어를 실행하여 가용성 그룹에 대한 로그인 권한을 Pacemaker에 부여합니다.

GRANT ALTER, CONTROL, VIEW DEFINITION ON AVAILABILITY GROUP::[aoag1] TO [pacemaker];
GRANT VIEW SERVER STATE TO [pacemaker];
GO

node-1, node-2, node-3의 SSH로 돌아가서 명령어를 실행하여 Pacemaker 로그인 정보 및 비밀번호를 SQL Server 보안 비밀 폴더에 저장합니다.

echo 'pacemaker' >> ~/pacemaker-passwd
echo 'PACEMAKER_LOGIN_PASSWORD' >> ~/pacemaker-passwd
sudo mv ~/pacemaker-passwd /var/opt/mssql/secrets/passwd
sudo chown root:root /var/opt/mssql/secrets/passwd
sudo chmod 400 /var/opt/mssql/secrets/passwd

PACEMAKER_LOGIN_PASSWORD를 Pacemaker 계정의 비밀번호로 바꿉니다.

Pacemaker 설치

다음으로 Pacemaker를 설치하고 리소스 관리를 위해 모든 Linux VM에 로그온 계정을 설정합니다.

Pacemaker에 대해 방화벽 포트를 엽니다.
1. node-1, node-2, node-3에서 다음 명령어를 실행하여 Uncomplicated Firewall이 설치되어 있고 사용 설정되었는지 확인합니다.
```
sudo ufw status
```
2. ufw가 사용 설정된 경우 node-1, node-2, node-3에서 방화벽 포트를 엽니다.
```
sudo ufw allow 2224/tcp
sudo ufw allow 3121/tcp
sudo ufw allow 5405/udp
sudo ufw allow 21064/tcp
sudo ufw allow 1433/tcp
sudo ufw allow 5022/tcp
sudo ufw reload
```
  참고: SQL Server 또는 가용성 그룹 엔드포인트에 다른 포트를 사용하는 경우 방화벽 규칙을 적절히 변경합니다.

node-1, node-2, node-3에 Pacemaker를 설치합니다.

sudo apt-get install -y pacemaker pacemaker-cli-utils crmsh resource-agents  fence-agents corosync python3-azure pcs

node-1, node-2, node-3에서 hacluster 사용자의 새 비밀번호를 설정합니다.

참고: 3개 노드 모두에 동일한 비밀번호를 설정합니다. 이 비밀번호는 나머지 설정 과정에서 필요합니다.
```
sudo passwd hacluster
```

Corosync 설정

이제 클러스터 전체에서 클러스터 멤버십과 메시지를 관리하도록 Corosync를 구성합니다.

node-1에서 Corosync용 인증 키를 만듭니다.
```
sudo corosync-keygen
```

Corosync 구성 파일을 수정합니다.

node-1로 돌아가서 corosync.conf 파일을 수정합니다.
```
sudo vi /etc/corosync/corosync.conf
```

강조표시된 섹션을 업데이트합니다. 수정 후 파일은 다음 예시와 같이 표시됩니다.

# Please read the corosync.conf.5 manual page
totem {
    version: 2

    # Corosync itself works without a cluster name, but DLM needs one.
    # The cluster name is also written into the VG metadata of newly
    # created shared LVM volume groups, if lvmlockd uses DLM locking.
    cluster_name: my_agcluster

    # crypto_cipher and crypto_hash: Used for mutual node authentication.
    # If you choose to enable this, then do remember to create a shared
    # secret with "corosync-keygen".
    # enabling crypto_cipher, requires also enabling of crypto_hash.
    # crypto works only with knet transport
    transport: udpu
    crypto_cipher: none
    crypto_hash: none
}

logging {
    # Log the source file and line where messages are being
    # generated. When in doubt, leave off. Potentially useful for
    # debugging.
    fileline: off
    # Log to standard error. When in doubt, set to yes. Useful when
    # running in the foreground (when invoking "corosync -f")
    to_stderr: yes
    # Log to a log file. When set to "no", the "logfile" option
    # must not be set.
    to_logfile: yes
    logfile: /var/log/corosync/corosync.log
    # Log to the system log daemon. When in doubt, set to yes.
    to_syslog: yes
    # Log debug messages (very verbose). When in doubt, leave off.
    debug: off
    # Log messages with time stamps. When in doubt, set to hires (or on)
    #timestamp: hires
    logger_subsys {
        subsys: QUORUM
        debug: off
    }
}
quorum {
    # Enable and configure quorum subsystem (default: off)
    # see also corosync.conf.5 and votequorum.5
    provider: corosync_votequorum
}
nodelist {
    # Change/uncomment/add node sections to match cluster configuration

    node {
        # Hostname of the node
        name: node-1
        # Cluster membership node identifier
        nodeid: 1
        # Address of first link
        ring0_addr: NODE1_INTERNAL_IP
        # When knet transport is used it's possible to define up to 8 links
        #ring1_addr: 192.168.1.1
    }
    node {
        name: node-2
        nodeid: 2
        ring0_addr: NODE2_INTERNAL_IP
    }
    node {
        name: node-3
        nodeid: 3
        ring0_addr: NODE3_INTERNAL_IP
    }
    # ...
}

NODE1_INTERNAL_IP, NODE2_INTERNAL_IP, NODE3_INTERNAL_IP를 각 노드의 내부 IP 주소로 바꿉니다.

Cloud Storage를 사용하여 구성 파일 전송

node-1에서 생성된 인증 키와 corosync 구성 파일을 Cloud Storage 버킷에 업로드합니다.
```
sudo gsutil cp /etc/corosync/authkey gs://BUCKET_NAME/
sudo gsutil cp  /etc/corosync/corosync.conf gs://BUCKET_NAME/
```
BUCKET_NAME을 이전에 만든 버킷의 이름으로 바꿉니다.
Authkey 및 구성 파일을 node-2 및 node-3에 다운로드합니다.
```
sudo gsutil cp gs://BUCKET_NAME/authkey /etc/corosync/
sudo gsutil cp gs://BUCKET_NAME/corosync.conf /etc/corosync/
```
BUCKET_NAME을 Corosync 구성 파일이 전송된 버킷의 이름으로 바꿉니다.

node-2 및 node-3의 파일 권한을 업데이트합니다.

sudo chmod 400 /etc/corosync/authkey
sudo chmod 400 /etc/corosync/corosync.conf

클러스터 통신 다시 시작 및 확인

node-1, node-2, node-3에서 Pacemaker 및 Corosync 서비스를 다시 시작합니다.
```
sudo systemctl restart pacemaker corosync
```
node-1에서 명령어를 실행하여 클러스터 상태를 확인합니다.
```
sudo crm status
```
3개 노드가 모두 온라인 상태로 표시됩니다.

클러스터 설정

다음으로 SQL Server Always On 가용성 그룹의 새 리소스를 만들어 Pacemaker 클러스터를 설정합니다.

node-1에서 다음 명령어를 실행하여 클러스터 속성을 설정합니다.

sudo crm configure property stonith-enabled=false
sudo crm configure property cluster-recheck-interval=2min
sudo crm configure property start-failure-is-fatal=true

자세한 내용은 클러스터 옵션을 참조하세요.

node-1에서 명령어를 실행하여 클러스터의 노드를 승인합니다. 이전에 hacluster 계정에 설정된 비밀번호를 사용합니다.
```
sudo pcs cluster auth -u hacluster
```
3개 노드가 모두 승인되었는지 확인합니다.
node-1, node-2, node-3에서 Pacemaker와의 통합을 위한 SQL Server 리소스 에이전트를 설치합니다.
```
sudo apt-get install mssql-server-ha
```
node-1로 돌아가서 클러스터에 가용성 그룹 리소스를 만듭니다.
1. 클러스터 리소스 관리자를 실행합니다.
```
sudo crm
```
2. configure를 입력하여 구성 메뉴로 이동합니다.
3. 다음 구성을 입력합니다.
```
primitive aoag1-cluster \
ocf:mssql:ag \
params ag_name="aoag1" \
meta failure-timeout=60s \
op start timeout=60s \
op stop timeout=60s \
op promote timeout=60s \
op demote timeout=10s \
op monitor timeout=60s interval=10s \
op monitor timeout=60s on-fail=demote interval=11s role="Master" \
op monitor timeout=60s interval=12s role="Slave" \
op notify timeout=60s
ms ms-ag1 aoag1-cluster \
meta master-max="1" master-node-max="1" clone-max="3" \
clone-node-max="1" notify="true"
```
4. commit를 입력하여 변경사항을 커밋합니다.
  
  참고: 펜싱 규칙이 설정되지 않았다는 경고가 표시됩니다. 이 메시지는 무시하세요. 이후 단계에서 펜싱 규칙이 설정됩니다.
5. exit를 입력하여 클러스터 리소스 관리자를 종료합니다.
6. 구성을 확인합니다.
```
sudo crm status
```
  node-1이 기본 노드로 승격된 것을 확인할 수 있습니다. Node-2 및 node-3를 보조 노드로 설정해야 합니다.

부하 분산기 및 가용성 그룹 리스너 설정

이 섹션에서는 트래픽을 가용성 그룹으로 라우팅하는 내부 패스 스루 TCP 부하 분산기를 사용하여 클러스터에 가상 IP 주소와 상태 점검 리소스를 만듭니다.

Cloud Shell로 돌아가서 클러스터 IP로 사용할 고정 IP 주소를 예약합니다.

gcloud compute addresses create aoag1-cluster \
--region REGION \
--subnet SUBNET_NAME
CLUSTER_ADDRESS=$(gcloud compute addresses describe aoag1-cluster \
--region $(gcloud config get-value compute/region) \
--format=value\(address\)) && \
echo "Cluster IP address: $CLUSTER_ADDRESS"

REGION 및 SUBNET_NAME을 Linux VM이 배포된 리전 및 서브넷으로 바꿉니다.

각 클러스터 노드에 비관리형 인스턴스 그룹을 만들고 새로 만든 인스턴스 그룹에 할당합니다. Cloud Shell에서 다음 명령어를 실행합니다.

gcloud compute instance-groups unmanaged create node-1-uig \
--zone=REGION-a
gcloud compute instance-groups unmanaged add-instances node-1-uig \
--zone=REGION-a \
--instances=node-1

gcloud compute instance-groups unmanaged create node-2-uig \
--zone=REGION-b
gcloud compute instance-groups unmanaged add-instances node-2-uig \
--zone=REGION-b \
--instances=node-2

gcloud compute instance-groups unmanaged create node-3-uig \
--zone=REGION-c
gcloud compute instance-groups unmanaged add-instances node-3-uig \
--zone=REGION-c \
--instances=node-3

REGION을 Linux VM이 배포된 리전으로 바꿉니다.

TCP 상태 확인 만들기 부하 분산기는 상태 점검을 사용하여 트래픽에 올바르게 응답하는 백엔드 인스턴스를 확인합니다.
```
gcloud compute health-checks create tcp aoag1-healthcheck \
--port=HEALTH_CHECK_PORT --proxy-header=NONE \
--check-interval=10 --timeout=10 --unhealthy-threshold=2 \
--healthy-threshold=2
```
HEALTH_CHECK_PORT를 선택하여 사용 가능하고 비공개 범위인 49152~65535에 있는 포트 값으로 바꿉니다. 예를 들면 60000입니다.

자세한 내용은 상태 점검 개요를 참조하세요.

클러스터 노드에 네트워크 태그를 추가합니다. 네트워크 태그는 방화벽 규칙에서 상태 점검에 사용됩니다.

gcloud compute instances add-tags node-1 \
--tags NETWORK_TAG_NAME \
--zone REGION-a
gcloud compute instances add-tags node-2 \
--tags NETWORK_TAG_NAME \
--zone REGION-b
gcloud compute instances add-tags node-3 \
--tags NETWORK_TAG_NAME \
--zone REGION-c

NETWORK_TAG_NAME을 네트워크 태그의 이름으로 바꿉니다.

태그 이름을 기준으로 상태 점검이 클러스터 노드에 도달할 수 있도록 방화벽 규칙을 만듭니다.

gcloud compute firewall-rules create mssql-aoag1-fw-rule \
--network VPC_NAME \
--action ALLOW \
--direction INGRESS \
--source-ranges 35.191.0.0/16,130.211.0.0/22 \
--target-tags NETWORK_TAG_NAME \
--rules tcp:HEALTH_CHECK_PORT

자세한 내용은 상태 점검을 위한 방화벽 규칙을 참조하세요.

부하 분산기 백엔드 서비스를 만듭니다.

gcloud compute backend-services create aoag1-backend \
--load-balancing-scheme internal \
--health-checks aoag1-healthcheck \
--no-connection-drain-on-failover \
--drop-traffic-if-unhealthy \
--failover-ratio 1.0 \
--region REGION \
--global-health-checks

백엔드 서비스에 비관리형 인스턴스 그룹 3개를 추가합니다.

gcloud compute backend-services add-backend aoag1-backend \
--instance-group node-1-uig \
--instance-group-zone REGION-a \
--region REGION

gcloud compute backend-services add-backend aoag1-backend \
--instance-group node-2-uig \
--instance-group-zone REGION-b \
--failover \
--region REGION

gcloud compute backend-services add-backend aoag1-backend \
--instance-group node-3-uig \
--instance-group-zone REGION-c \
--failover \
--region REGION

부하 분산기의 전달 규칙을 정의합니다. 전달 규칙은 프로토콜과 부하 분산기가 트래픽을 수락하는 포트를 지정합니다.
```
gcloud compute forwarding-rules create aoag1-fwd-rule \
--load-balancing-scheme internal \
--address CLUSTER_ADDRESS \
--subnet SUBNET_NAME \
--region REGION \
--backend-service aoag1-backend \
--ports ALL
```
CLUSTER_ADDRESS를 이전에 예약된 IP 주소로 바꿉니다.

팁: VPC 네트워크 또는 연결된 네트워크의 모든 리전에서 클라이언트가 클러스터에 액세스할 수 있도록 하려면 전달 규칙의 정의에 --allow-global-access를 포함해야 합니다.

자세한 내용은 전달 규칙을 참조하세요.
설정을 완료하고 네트워크 부하 분산기가 올바르게 설정되었는지 테스트하려면 node-1, node-2, node-3에 HAProxy tcp listener를 설치하고 구성합니다.
1. HAProxy를 설치합니다.
```
sudo apt-get install haproxy
```
2. Y를 선택하여 설치를 완료합니다.
3. haproxy.cfg 파일을 수정합니다.
```
sudo vi /etc/haproxy/haproxy.cfg
```
4. haproxy.cfg file의 defaults 섹션에서 mode를 tcp로 변경합니다.
5. haproxy.cfg 파일 끝에 다음 섹션을 추가합니다.
```
#---------------------------------------------------------------
# Set up health check listener for SQL Server Availability Group
#---------------------------------------------------------------
listen healthcheck
bind *:HEALTH_CHECK_PORT
```
  HEALTH_CHECK_PORT를 이전에 선택한 상태 점검 포트로 바꿉니다. 예를 들면 6000입니다.
6. 서비스를 시작하여 올바르게 구성되었는지 확인합니다.
```
sudo systemctl start haproxy.service
sudo systemctl enable haproxy.service
sudo systemctl restart haproxy.service
```
7. 부하 분산 페이지로 이동하여 부하 분산기를 클릭합니다. 비관리형 인스턴스 그룹 3개를 확인해 보면 이제 정상으로 표시됩니다.
  
  부하 분산으로 이동
  - 또는 Cloud Shell에서 다음 명령어를 실행하여 백엔드 서비스의 상태를 확인할 수 있습니다.
```
gcloud compute backend-services get-health aoag1-backend \
--region REGION
```
    REGION을 Linux VM이 배포된 리전으로 바꿉니다.
8. 비관리형 인스턴스 그룹 3개가 모두 정상으로 표시되면 다음 단계를 진행합니다.
  
  참고: 비관리형 인스턴스 그룹이 정상으로 표시되지 않으면 해당 노드에서 haproxy.service를 다시 시작해야 합니다.
```
sudo systemctl restart haproxy.service
```
Pacemaker에서 상태 점검 리소스를 만듭니다.
1. SSH를 통해 node-1에 연결하고 Pacemaker 클러스터에서 HAProxy 서비스에 대한 상태 점검 리소스를 만듭니다.
```
sudo pcs resource create aoag1-healthcheck \
service:haproxy \
op monitor interval=10s timeout=20s
```
2. 상태 리소스가 기본 노드 node-1에서 시작되었는지 확인합니다.
```
sudo crm status
```
3. 상태 점검 리소스가 기본 노드에서 시작되지 않은 경우 다음 명령어를 사용하여 리소스를 이동합니다.
```
sudo pcs resource move aoag1-healthcheck node-1
sudo pcs resource clear aoag1-healthcheck
```
  node-1에서만 부하 분산기의 상태 점검이 정상인 것을 볼 수 있습니다.
  
  부하 분산으로 이동
Pacemaker 클러스터에 가상 IP 주소 리소스를 만듭니다.
1. node-1의 SSH로 돌아가서 노드의 네트워크 인터페이스 이름을 찾습니다. 다음 단계에 이 항목이 필요합니다.
```
ip -c link
```
2. 가상 IP 주소 리소스를 만듭니다.
```
sudo pcs resource create aoag1-vip ocf:heartbeat:IPaddr2 \
ip="CLUSTER_ADDRESS" nic=NIC_NAME cidr_netmask=32 \
op monitor interval=3600s timeout=60s
```
  NIC_NAME을 이전 단계의 네트워크 인터페이스 이름으로 바꾸고 CLUSTER_ADDRESS를 예약된 IP 주소로 바꿉니다.
3. 가상 IP 주소 리소스가 기본 호스트에서 시작되었는지 확인합니다.
```
sudo crm status
```
4. 가상 IP 주소 리소스가 기본 노드에서 시작되지 않은 경우 다음 명령어를 사용하여 이동합니다.
```
sudo pcs resource move aoag1-vip node-1
```
5. 상태 점검 및 가상 IP 주소 리소스를 함께 그룹화합니다.
```
sudo pcs resource group add aoag1-group \
aoag1-healthcheck aoag1-vip
```
6. 기본 노드와 동일한 노드에서 새 그룹을 찾는 제약조건을 만듭니다.
```
sudo pcs constraint colocation add master aoag1-group with master ms-ag1 score=INFINITY
```

SQL Server 가용성 그룹의 리스너 만들기

가용성 그룹이 있는 SQL Server에 연결하려면 서버 이름 대신 가용성 그룹 리스너 이름을 사용해야 합니다. 장애 조치가 있으면 리스너가 연결을 클러스터의 새 기본 노드로 자동으로 리디렉션합니다.

SSMS로 돌아가서 node-1 데이터베이스에 연결합니다.

다음 쿼리를 실행합니다.

ALTER AVAILABILITY GROUP aoag1
ADD LISTENER 'aoag1-listener' (
    WITH IP (('CLUSTER_ADDRESS','255.255.255.0')), PORT=1433
);
GO

CLUSTER_ADDRESS를 예약된 IP 주소로 바꿉니다.

STONITH 펜스 설정

STONITH는 HA 클러스터에서 노드의 무결성을 유지하기 위한 펜싱 전략입니다. STONITH 서비스는 노드 수준에서 작동하며 응답하지 않거나 알 수 없는 상태인 노드로부터 클러스터를 보호합니다. Google Cloud의 Compute Engine에 특화된 fence_gce 펜싱 기기를 사용하는 것이 좋습니다.

펜싱 기기 설정

node1에 Compute Engine용 펜스 에이전트인 fence_gce가 설치되었는지 확인합니다.
```
sudo pcs stonith list | grep fence_gce
```
자세한 내용은 다음을 참고하세요.
- Google Compute Engine용 펜스 에이전트
- 에이전트 실행과 관련된 매개변수를 확인합니다.
```
sudo pcs stonith describe fence_gce
```

node-1에서 참여 노드마다 fence_gce 펜싱 유형 리소스를 만듭니다.

sudo pcs stonith create node-1-fence fence_gce \
plug=node-1 \
zone=REGION-a \
project=PROJECT_ID \
pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30 \
op monitor interval="300s" timeout="120s" \
op start interval="0" timeout="60s"

sudo pcs stonith create node-2-fence fence_gce \
plug=node-2 \
zone=REGION-b \
project=PROJECT_ID \
pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30 \
op monitor interval="300s" timeout="120s" \
op start interval="0" timeout="60s"

sudo pcs stonith create node-3-fence fence_gce \
plug=node-3 \
zone=REGION-c \
project=PROJECT_ID \
pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30 \
op monitor interval="300s" timeout="120s" \
op start interval="0" timeout="60s"

REGION을 Linux VM이 배포된 리전으로 바꾸고 PROJECT_ID를 프로젝트 ID로 바꿉니다.

상태 명령어를 실행하여 펜싱 에이전트의 상태를 테스트할 수 있습니다.

sudo fence_gce -o status -n node-1 --zone=REGION-a
sudo fence_gce -o status -n node-2 --zone=REGION-b
sudo fence_gce -o status -n node-3 --zone=REGION-c

펜싱 기기가 정해진 인스턴스에서만 실행되도록 하는 위치 제약조건을 만듭니다.

sudo pcs constraint location node-1-fence avoids node-1
sudo pcs constraint location node-2-fence avoids node-2
sudo pcs constraint location node-3-fence avoids node-3

Pacemaker 클러스터에서 펜싱을 사용 설정하고 클러스터 펜싱 제한 시간을 설정합니다.
```
sudo pcs -f stonith_cfg property set stonith-enabled=true
sudo pcs property set stonith-timeout="300s"
```
클러스터의 상태를 확인합니다.
```
sudo crm status
```

펜싱 기기 테스트

펜싱 기기를 설정한 후에는 다음 단계에 따라 테스트하는 것이 좋습니다.

node-2에서 펜스를 중지합니다.
1. node-1에 연결하고 다음 명령어를 실행하여 클러스터에서 node-2와 연결된 펜스 기기를 테스트합니다.
```
fence_gce -o off -n node-2 --zone=REGION-b
```
2. 클러스터의 상태를 확인합니다.
```
sudo crm status
```
3. 또한 Compute Engine에서 node-2가 사용 중지된 것을 확인할 수 있습니다.
  
  Compute Engine으로 이동
node-2에서 펜스를 다시 시작합니다.
1. node-1로 돌아가서 다음 명령어를 실행하여 인스턴스를 다시 시작합니다.
```
fence_gce -o on -n node-2 --zone=REGION-b
```
2. Pacemaker 및 Compute Engine에서 클러스터 상태를 확인합니다. 잠시 후 node-2가 다시 온라인 상태가 되는 것을 확인할 수 있습니다.
```
sudo crm status
```

Corosync에 지연된 다시 시작 구성

타이밍 문제를 방지하고 펜싱 작업 시 올바른 순서로 작업이 수행되도록 하려면 Corosync 서비스 다시 시작을 60초 동안 지연하는 것이 좋습니다.

자세한 내용은 Red Hat 기술 자료 문서를 참조하세요.

node-1, node-2, node-3에서 Corosync 서비스 시작 지연을 설정하는 systemd 삽입형 파일을 만듭니다.
1. 수정할 corosync.service를 엽니다.
```
sudo systemctl edit corosync.service
```
2. 다음 줄을 추가하고 파일을 저장한 후 편집기를 종료합니다.
```
[Service]
ExecStartPre=/bin/sleep 60
```
3. 서비스 관리자를 새로고침하고 구성이 반영되었는지 확인합니다.
```
sudo systemctl daemon-reload
systemctl status corosync.service --no-pager
```
  삽입형 섹션이 표시되면 삽입형 파일의 설정이 성공적으로 반영된 것입니다.

장애 조치 테스트

이제 장애 조치가 예상대로 작동하는지 테스트할 수 있습니다.

원격 데스크톱을 통해 node-4의 Windows VM에 연결합니다.
PowerShell 세션을 엽니다.

다음 스크립트를 실행합니다.

while ($True){
  $Conn = New-Object System.Data.SqlClient.SqlConnection
  $Conn.ConnectionString = "Server=CLUSTER_ADDRESS;User ID=sa;Password=SA_PASSWORD;Initial Catalog=master"
  $Conn.Open()

  $Cmd = New-Object System.Data.SqlClient.SqlCommand
  $Cmd.Connection = $Conn
  $Cmd.CommandText = "SELECT @@SERVERNAME"

  $Adapter = New-Object System.Data.SqlClient.SqlDataAdapter $Cmd
  $Data = New-Object System.Data.DataSet
  $Adapter.Fill($Data) | Out-Null
  $Data.Tables[0] + (Get-Date -Format "MM/dd/yyyy HH:mm:ss")

  Start-Sleep -Seconds 2
}

CLUSTER_ADDRESS를 리스너 IP 주소로, SA_PASSWORD를 SQL Server의 SA 계정 비밀번호로 바꿉니다.

스크립트는 2초마다 가용성 그룹 리스너나 DNN 리스너를 사용하여 SQL Server에 연결하고 서버 이름을 쿼리합니다.

스크립트가 실행되도록 둡니다.

node-1의 SSH로 돌아가서 명령어를 실행하여 node-2로의 장애 조치를 트리거합니다.

sudo pcs resource move ms-ag1 node-2 --master
sudo pcs resource move aoag1-group  node-2
sudo pcs resource move aoag1-vip node-2

node-4의 PowerShell 세션으로 돌아갑니다.
1. 실행 중인 스크립트의 출력을 관찰하고 장애 조치의 결과로 서버 이름이 node-1에서 node-2로 변경되는 것을 확인합니다.

node-1로 돌아가서 node-1로 장애 복구를 시작합니다.

sudo pcs resource move ms-ag1 node-1 --master
sudo pcs resource move aoag1-group  node-1
sudo pcs resource move aoag1-vip node-1

node-4의 Powershell로 돌아가서 Ctrl+C를 눌러 스크립트를 중지합니다.

삭제

튜토리얼을 완료한 후에는 만든 리소스를 삭제하여 할당량 사용을 중지하고 요금이 청구되지 않도록 할 수 있습니다. 다음 섹션은 이러한 리소스를 삭제하거나 사용 중지하는 방법을 설명합니다.

프로젝트 삭제

비용이 청구되지 않도록 하는 가장 쉬운 방법은 튜토리얼에서 만든 프로젝트를 삭제하는 것입니다.

프로젝트를 삭제하는 방법은 다음과 같습니다.

주의: 프로젝트를 삭제하면 다음과 같은 효과가 발생합니다.

프로젝트의 모든 항목이 삭제됩니다. 이 문서의 태스크에 기존 프로젝트를 사용한 경우 프로젝트를 삭제하면 프로젝트에서 수행한 다른 작업도 삭제됩니다.
커스텀 프로젝트 ID가 손실됩니다. 이 프로젝트를 만들 때 앞으로 사용할 커스텀 프로젝트 ID를 만들었을 수 있습니다. appspot.com URL과 같이 프로젝트 ID를 사용하는 URL을 보존하려면 전체 프로젝트를 삭제하는 대신 프로젝트 내에서 선택한 리소스만 삭제합니다.

여러 아키텍처, 튜토리얼, 빠른 시작을 살펴보려는 경우 프로젝트를 재사용하면 프로젝트 할당량 한도 초과를 방지할 수 있습니다.

Google Cloud 콘솔에서 리소스 관리 페이지로 이동합니다.
리소스 관리로 이동
프로젝트 목록에서 삭제할 프로젝트를 선택하고 삭제를 클릭합니다.
대화상자에서 프로젝트 ID를 입력한 후 종료를 클릭하여 프로젝트를 삭제합니다.