이 문서에서는 Amazon EC2(Amazon Elastic Compute Cloud)에 설치된 Microsoft SQL Server 인스턴스를 Google Cloud의 Compute Engine에서 Microsoft SQL Server 인스턴스로 마이그레이션하는 방법을 보여줍니다. 이 마이그레이션은 Microsoft SQL Server에서 제공하는 기본 데이터베이스 기술을 기반으로 합니다. 이 방법은 사실상 Always On 가용성 그룹을 사용하는 제로 다운타임 방법입니다. Always On 가용성 그룹은 AWS와 VPN의 Google Cloud에 걸쳐 있으며, Microsoft SQL Server 데이터베이스를 복제할 수 있습니다. 이 문서에서는 사용자가 네트워크 설정, Google Cloud, Compute Engine, AWS, Microsoft SQL Server에 익숙하다고 가정합니다.
복제만 수행하려면 이 가이드의 단계를 따르되, 테스트 데이터를 추가한 후에는 중지하고 컷오버 단계를 생략하세요.
목표
- Amazon EC2의 Microsoft SQL Server와 Compute Engine Google Cloud의 Microsoft SQL Server를 아우르는 멀티 클라우드 Microsoft SQL Server Always On 가용성 그룹 배포하기
- Amazon EC2에서 기본 Microsoft SQL 인스턴스 설정하기
- Google Cloud의 Microsoft SQL Server 인스턴스를 AWS의 기본 Microsoft SQL Server(데이터 복제 타겟)에 대한 보조 인스턴스로 설정하기
- Google Cloud의 보조 Microsoft SQL Server를 Google Cloud의 기본 Microsoft SQL Server로 만들어 데이터 마이그레이션 완료하기
비용
이 문서에서는 비용이 청구될 수 있는 다음과 같은 Google Cloud 구성요소를 사용합니다.
- Compute Engine
- SQL Server VMs
프로젝트 사용량을 기준으로 예상 비용을 산출하려면 가격 계산기를 사용하세요.
이 튜토리얼에는 비용이 발생할 수 있는 AWS의 리소스도 필요합니다.
시작하기 전에
-
Google Cloud Console의 프로젝트 선택기 페이지에서 Google Cloud 프로젝트를 선택하거나 만듭니다.
-
Google Cloud 콘솔에서 Cloud Shell을 활성화합니다.
데이터베이스 마이그레이션 이해
데이터베이스 마이그레이션은 소스 데이터베이스에서 대상 데이터베이스로 데이터를 이동합니다. 일반적으로 데이터의 하위 집합을 마이그레이션하거나 소스 및 대상 데이터베이스에 다른 스키마를 포함할 수 있습니다. 하지만 이 튜토리얼에서는 전체 데이터베이스를 변경하지 않고 마이그레이션해야 하는 동종 데이터베이스 마이그레이션을 다룹니다. 이때, 대상 데이터베이스는 소스 데이터베이스의 복사본입니다.
제로 다운타임 데이터베이스 마이그레이션
제로 다운타임이라는 용어는 마이그레이션 중에 소스 데이터베이스에 액세스하는 클라이언트가 완전히 작동하며 중단되지 않는다는 것을 의미합니다. 마이그레이션이 완료된 후 클라이언트가 대상 데이터베이스에 다시 연결해야 하는 경우에만 다운타임이 발생합니다. 이 방법은 진정한 제로 다운타임은 아니지만, 이 용어는 최소의 다운타임 시나리오를 나타냅니다.
데이터베이스 마이그레이션에 대한 일반적인 설명은 데이터베이스 마이그레이션 - 개념 및 원칙(1부) 및데이터베이스 마이그레이션 - 개념 및 원칙(2부)를 참고하세요. 이 문서는 다양한 시나리오에서 데이터베이스 마이그레이션의 가능한 복잡성에 대하여 개괄적으로 설명합니다.
Microsoft SQL Server 기술을 사용한 데이터베이스 마이그레이션
일부 데이터베이스 마이그레이션 기술은 별도의 구성요소와 서비스를 제공합니다. 데이터베이스 마이그레이션에 소스 데이터베이스의 사본이 필요한 경우 기본 제공 Microsoft SQL Server 기술을 사용할 수 있습니다.
이 튜토리얼에서는 Microsoft SQL Server Always On 가용성 그룹 기술을 사용하여 소스 데이터베이스(기본)를 대상 데이터베이스(보조)에 연결합니다. 이 기술은 기본 데이터베이스에서 보조 데이터베이스로의 비동기 복제를 제공합니다. 기본 데이터베이스는 Amazon EC2에 있고 보조 데이터베이스는 Compute Engine의 Google Cloud에 있으므로 복제가 데이터베이스 마이그레이션을 수행합니다. 모든 데이터가 비동기 복제를 통해 마이그레이션되면 보조 데이터는 기본 데이터로 승격되고, 클라이언트는 계속 처리하기 위해 새로운 기본 데이터에 다시 연결할 수 있습니다.
이 접근법은 테스트 타겟 데이터베이스에 대한 테스트 복제의 명시적인 테스트를 지원합니다. 복제를 시작한 후 일정 시간 동안 실행한 후 복제를 중지할 수 있습니다. 테스트 타겟 데이터베이스는 일관된 상태에 있으므로 이를 사용하여 애플리케이션을 테스트할 수 있습니다. 테스트가 완료되면 테스트 타겟 데이터베이스를 삭제하고 라이브 데이터베이스에 대한 복제를 시작할 수 있습니다.
멀티 클라우드 데이터베이스 마이그레이션 아키텍처
다음 도표는 멀티 클라우드 데이터베이스 마이그레이션을 위한 전체 배포 아키텍처를 보여줍니다.
위의 다이어그램은 AWS의 소스(기본) SQL Server 데이터베이스를 Amazon EC2 인스턴스로 보여줍니다. 또한 이 다이어그램은 Google Cloud의 대상 데이터베이스(보조)를 보여줍니다. 데이터베이스는 Always On 가용성 그룹에 의해 연결됩니다. AWS와 Google Cloud 간의 네트워크 연결은 보안 HA VPN 연결로 간주됩니다.
멀티 클라우드 Microsoft SQL Server 가용성 그룹 설정
다음 섹션에서는 기본 노드가 AWS에 있고 보조 노드가 Google Cloud에 있는 2개의 Always On 가용성 그룹을 설정하게 됩니다. 이 구성은 문서의 앞부분에 있는 멀티 클라우드 데이터베이스 마이그레이션 아키텍처에 설명되어 있습니다.
다음 표에서는 이 가이드에서 설정한 노드와 IP 주소가 요약되어 있습니다. 모든 데이터베이스 VM에 기본 IP 주소 외에 Windows Server 장애 조치 클러스터(WSFC)의 IP 주소 1개와 가용성 그룹 리스너용 IP 주소 두 개를 할당합니다.
| 제공업체 | 인스턴스 | 기본 IP | WSFC 및 가용성 그룹 리스너 IP | WSFC | 가용성 그룹 |
|---|---|---|---|---|---|
| AWS | cluster-sql1 |
192.168.1.4 |
192.168.1.5
|
Name: cluster-dbclus
|
Name: cluster-ag
|
| Google Cloud | cluster-sql2 |
10.1.1.4 |
10.1.1.5
|
| 제공업체 | 인스턴스 | 기본 IP | — |
|---|---|---|---|
AWS |
dc-windows |
192.168.1.100 |
Domain controller |
여기에 나오는 이름 및 IP 주소는 예시입니다. 자체 이름과 IP 주소를 사용하려면 안내의 예시 값을 바꾸세요.
AWS를 위한 기본 요건
AWS에는 도메인 컨트롤러를 실행하는 머신과 SQL Server를 실행하는 가상 머신 두 개가 있어야 합니다. 이 튜토리얼의 예시로 사용된 도메인 컨트롤러의 구성은 다음과 같습니다.
Domain : dbeng.com
Domain controller : Name: dc-windows
Private IP: 192.168.1.100
VPC Subnet : 192.168.1.0/24
SQL Server service account: dbeng\sql_service
이 튜토리얼의 예시로 사용된 SQL Server VM은 Amazon EC2의 Windows Active Directory 도메인의 일부입니다. 서버에는 WSFC 및 가용성 그룹 리스너에서 사용할 두 개의 보조 IP 주소가 있습니다. SQL Server VM의 구성은 다음과 같습니다.
VM Instance : Name: cluster-sql1
Private IP: 192.168.1.4
Secondary Private IPs: 192.168.1.5, 192.168.1.6
VPC Subnet : 192.168.1.0/24
NT SERVICE\MSSQLSERVER 서비스 계정을 SQL Server 서비스 계정으로 사용할 수 있습니다. Always On 가용성 그룹 설정 중에 도메인 계정이 아닌 머신 계정(dbeng\cluster-sql1$, dbeng\cluster-sql2$)에 액세스 권한을 부여합니다. 다음 섹션에서는 가용성 그룹을 구성하는 명령어를 설명합니다.
AWS와 Google Cloud 간의 연결 기본 요건
AWS 프로젝트를 Google Cloud 프로젝트와 연결하려면 다음과 같이 네트워크 연결을 설정하세요.
- 각 프로젝트에서 Google Virtual Private Cloud와 AWS VPC를 설정하고 VPC 간에 VPN을 구성합니다. Google Cloud와 AWS 사이에 VPN을 설정하는 방법에 대한 자세한 내용은 멀티 클라우드 VPN 및 다중 영역 서브네트워크 — 멀티 클라우드 데이터베이스 배포를 위한 네트워크 설정을 참조하세요.
Cloud Shell에서는 SQL Server 인스턴스를 만드는 Google Cloud 프로젝트에서 서브넷을 만듭니다. 이미 서브넷이 있으면 그것을 사용할 수 있지만, 다음 단계에서 방화벽 규칙을 설정해야 합니다.
gcloud compute networks create demo-vpc --subnet-mode custom gcloud compute networks subnets create demo-subnet1 \ --network demo-vpc --region us-east4 --range 10.1.1.0/24이 튜토리얼에서는 다음 값을 사용합니다.
- VPC:
demo-vpc - 서브넷:
demo-subnet1; 10.1.1.0/24
서브넷은 Google Cloud 콘솔 VPC 네트워크 페이지에 표시됩니다.
- VPC:
Google Cloud 프로젝트에서 방화벽 규칙을 생성하여 Google Cloud 서브넷과 AWS 서브넷 사이의 모든 트래픽을 엽니다.
gcloud compute firewall-rules create allow-vpn-ports \ --network demo-vpc --allow tcp:1-65535,udp:1-65535,icmp \ --source-ranges 10.1.1.0/24,192.168.1.0/24방화벽 규칙이 Google Cloud 콘솔 방화벽 정책 페이지에 표시됩니다.
AWS 프로젝트에서, 다음 스크린샷과 같이 Google Cloud 서브넷과 AWS 서브넷 사이의 모든 트래픽을 열도록 보안 그룹에 방화벽 규칙을 만듭니다.
프로덕션 환경에서는 필요한 TCP/UDP 포트만 여는 것을 고려해 볼 수 있습니다. 필요한 포트만 열면 잠재적으로 위험한 트래픽이 제한되며 최소 필수 원칙을 따릅니다.
Google Cloud에서 Always On 가용성 그룹의 인스턴스 만들기
이 튜토리얼은 다음 Microsoft SQL Server 버전 및 기능을 함께 사용합니다.
- 에디션:
- Microsoft SQL Server 2016 Enterprise Edition, 또는
- Microsoft SQL Server 2017 Enterprise Edition, 또는
- Microsoft SQL Server 2019 Enterprise Edition, 또는
- Microsoft SQL Server 2022 Enterprise Edition, 또는
- Microsoft SQL Server 2016 Standard Edition, 또는
- Microsoft SQL Server 2017 Standard Edition, 또는
- Microsoft SQL Server 2019 Standard Edition, 또는
- Microsoft SQL Server 2022 Standard Edition
- 기능: Always On 가용성 그룹
다음 안내에서는 Microsoft SQL Server 2019 Enterprise Edition, sql-ent-2019-win-2019의 이미지를 사용합니다. Microsoft SQL Server 2017, 2016, 2022 Enterprise Edition을 설치하려면 대신 각각 sql-ent-2017-win-2019, sql-ent-2016-win-2019, sql-ent-2022-win-2019를 사용합니다. 전체 이미지 목록은 Compute Engine 운영체제 세부정보 페이지를 참조하세요.
다음 단계에서는 Google Cloud에 가용성 그룹을 위한 SQL Server 인스턴스를 만듭니다. 인스턴스는 별칭 IP 주소와 함께 다음 IP 주소 구성을 사용합니다.
VM Instance: Name: cluster-sql2
Private IP: 10.1.1.4
Secondary Private IPs: 10.1.1.5, 10.1.1.6
200GB 부팅 디스크 크기 및 n1-highmem-4 머신 유형으로 공개 SQL Server 이미지에서 cluster-sql2라는 인스턴스를 만듭니다. SQL Server 인스턴스에는 일반적으로 도메인 컨트롤러 인스턴스보다 더 많은 컴퓨팅 리소스가 필요합니다. 나중에 추가 컴퓨팅 리소스가 필요할 경우 이 인스턴스의 머신 유형을 변경할 수 있습니다. 추가 저장공간이 필요한 경우 디스크를 추가하거나 영구 부팅 디스크의 크기를 조절하세요. 대규모 가용성 그룹에서는 여러 인스턴스를 만들 수 있습니다.
다음 단계에는 인스턴스를 만드는 동안 Microsoft PowerShell 명령어를 실행하여 장애 조치 클러스터링 기능을 설치하는 --metadata sysprep-specialize-script-ps1 플래그도 포함됩니다.
Cloud Shell에서 AWS와 동일한 운영체제 버전을 사용하는 Google Cloud에 SQL Server 인스턴스를 만드세요.
gcloud compute instances create cluster-sql2 --machine-type n1-highmem-4 \ --boot-disk-type pd-ssd --boot-disk-size 200GB \ --image-project windows-sql-cloud --image-family sql-ent-2019-win-2019 \ --zone us-east4-a \ --network-interface "subnet=demo-subnet1,private-network-ip=10.1.1.4,aliases=10.1.1.5;10.1.1.6" \ --can-ip-forward \ --metadata sysprep-specialize-script-ps1="Install-WindowsFeature Failover-Clustering -IncludeManagementTools;"인스턴스에 연결하기 전에 Windows 사용자 이름 및 비밀번호를 설정하세요.
노트북에서 원격 데스크톱 프로토콜(RDP)을 사용하는 경우 인스턴스에 대한 액세스를 허용하는 방화벽 규칙을 만듭니다.
RDP를 사용하여 Google Cloud 인스턴스에 연결하고 관리자 권한 PowerShell을 실행합니다(관리자로 실행).
이 가이드에서는 Google Cloud에서 다른 VM을 만들지 않도록 AWS에서 도메인 컨트롤러를 사용하도록 로컬 DNS(
192.168.1.100)를 구성합니다. 프로덕션 워크로드의 경우 Google Cloud에서 도메인 컨트롤러(기본 또는 보조)를 사용하여 VPN 터널에서의 인증을 피하는 것이 좋습니다.관리자 권한 PowerShell에서 도메인 컨트롤러
192.168.1.100을 핑할 수 있습니다.ping 192.168.1.100핑에 실패하면 이 문서 앞부분의 연결 기본 요건에 설명된 대로 방화벽과 VPN 터널이 AWS와 Google Cloud 간에 올바르게 구성되었는지 확인하세요.
서버가 원래 DHCP로 설정되었으므로 고정 IP 주소를 사용하도록 인스턴스를 변경합니다.
netsh interface ip set address name=Ethernet static 10.1.1.4 255.255.255.0 10.1.1.1 1위 명령어를 실행하면 연결이 끊어집니다. RDP에 다시 연결합니다.
AWS에서 도메인 컨트롤러를 사용하도록 로컬 DNS를 구성하고 SQL Server용 로컬 방화벽 포트를 엽니다. 방화벽 포트를 열면 SQL Server가 원격 SQL Server에 연결될 수 있습니다.
netsh interface ip set dns Ethernet static 192.168.1.100 netsh advfirewall firewall add rule name="Open Port 5022 for Availability Groups" dir=in action=allow protocol=TCP localport=5022 netsh advfirewall firewall add rule name="Open Port 1433 for SQL Server" dir=in action=allow protocol=TCP localport=1433인스턴스를 Windows 도메인에 추가합니다.
Add-Computer -DomainName "dbeng.com" -Credential "dbeng.com\Administrator" -Restart -Force이 명령어를 사용하면 도메인 관리자 사용자 인증 정보를 입력하라는 메시지가 뜹니다. 명령어 실행이 완료되면 인스턴스가 다시 시작됩니다.
명령어가 실행되지 않는 경우 관리자로 실행 중인지 확인하세요.
dbeng\Administrator계정을 사용하여 RDP를 통해 인스턴스에 다시 연결합니다.SQL Server 서비스 계정을 설정합니다.
- SQL Server 2019 구성 관리자를 엽니다.
- SQL Server 서비스 탭에서 SQL Server (MSSQLSERVER)를 마우스 오른쪽 버튼으로 클릭한 다음 속성을 클릭합니다.
dbeng\sql_service의 계정과 비밀번호를 설정합니다.- SQL Server를 다시 시작합니다.
컴퓨터 이름과 일치하도록 SQL Server 인스턴스 이름을 변경하고 SQL Server를 다시 시작합니다.
Invoke-Sqlcmd -Query "EXEC sp_dropserver @@SERVERNAME, @droplogins='droplogins'" Invoke-Sqlcmd -Query "EXEC sp_addserver '$env:COMPUTERNAME', local" Stop-Service -Name "MSSQLServer" -Force Start-Service -Name "MSSQLServer"
다음은 AWS에서 인스턴스를 구성합니다.
AWS에서 인스턴스 구성
이 가이드에서는 AWS에 다음이 이미 구성되어 있다고 가정합니다.
- SQL Server 인스턴스는 Active Directory 도메인의 일부입니다.
- 로컬 DNS가 제대로 작동하고 Google Cloud의 원격 서버 이름(
cluster-sql2.dbeng.com))을 IP 주소로 변환할 수 있습니다. - AWS와 Google Cloud의 서브넷 간에 방화벽 규칙이 열려 있습니다.
AWS에서 cluster-sql1을 구성하려면 다음을 수행하세요.
- RDP를 사용하여 인스턴스에 연결합니다(
cluster-sql1). - 관리자 권한 PowerShell을 엽니다(관리자 권한으로 실행).
Windows 장애 조치 클러스터링이 아직 설치되어 있지 않으면 설치하세요.
Install-WindowsFeature Failover-Clustering -IncludeManagementTools이 기능이 아직 설치되지 않은 경우 이 명령어를 다시 시작해야 합니다. 다시 시작한 후 다음 단계를 진행합니다.
AWS에서 SQL Server 인스턴스의 로컬 방화벽 포트를 엽니다.
netsh advfirewall firewall add rule name="Open Port 5022 for Availability Groups" dir=in action=allow protocol=TCP localport=5022 netsh advfirewall firewall add rule name="Open Port 1433 for SQL Server" dir=in action=allow protocol=TCP localport=1433 netsh advfirewall firewall add rule name="ICMP Allow incoming V4 echo request" protocol="icmpv4:8,any" dir=in action=allow컴퓨터 이름과 일치하도록 SQL Server 인스턴스 이름을 변경하고 SQL Server를 다시 시작합니다.
Invoke-Sqlcmd -Query "EXEC sp_dropserver @@SERVERNAME, @droplogins='droplogins'" Invoke-Sqlcmd -Query "EXEC sp_addserver '$env:COMPUTERNAME', local" Stop-Service -Name "MSSQLServer" -Force Start-Service -Name "MSSQLServer"원격 인스턴스 이름을 사용할 때 AWS의 인스턴스를 Google Cloud의 인스턴스에 연결할 수 있는지 확인합니다. 연결을 테스트하려면 SQL Server에 대한 연결 액세스 권한이 부여된 도메인 계정에서 다음 명령어를 실행하세요.
네트워크 연결 테스트:
ping -4 cluster-sql2.dbeng.com출력은 다음과 같이 표시됩니다.
RESULTS: Pinging cluster-sql2.dbeng.com [10.1.1.4] with 32 bytes of data: Reply from 10.1.1.4: bytes=32 time=3ms TTL=127 Reply from 10.1.1.4: bytes=32 time=2ms TTL=127 Reply from 10.1.1.4: bytes=32 time=2ms TTL=127 Reply from 10.1.1.4: bytes=32 time=2ms TTL=127원격 서버에 대한 Windows 인증 테스트:
sqlcmd -E -S cluster-sql2.dbeng.com -Q "SELECT 'CONNECTED'"출력은 다음과 같이 표시됩니다.
RESULTS: -------------------------------------------------------------------------- CONNECTED (1 rows affected)
연결할 수 없는 경우 DNS가 올바르게 작동하는지, AWS와 Google Cloud 서브넷 사이에 방화벽 규칙이 열려 있는지 확인하세요.
Google Cloud 인스턴스가 가용성 그룹에 조인할 준비가 되었는지 확인
dbeng\Administrator계정을 사용하여 RDP(cluster-sql2)를 통해 Google Cloud 인스턴스에 연결합니다.- 관리자 권한 PowerShell을 엽니다(관리자 권한으로 실행).
인스턴스 이름을 사용할 때 Google Cloud의 인스턴스를 AWS의 인스턴스에 연결할 수 있는지 확인합니다. 연결을 테스트하려면 SQL Server에 대한 연결 액세스 권한이 부여된 도메인 계정에서 다음 명령어를 실행하세요.
네트워크 연결 테스트:
ping -4 cluster-sql1.dbeng.com출력은 다음과 같이 표시됩니다.
RESULTS: Pinging CLUSTER-SQL1.dbeng.com [192.168.1.4] with 32 bytes of data: Reply from 192.168.1.4: bytes=32 time=3ms TTL=127 Reply from 192.168.1.4: bytes=32 time=2ms TTL=127 Reply from 192.168.1.4: bytes=32 time=3ms TTL=127 Reply from 192.168.1.4: bytes=32 time=2ms TTL=127원격 서버에 대한 Windows 인증 테스트:
sqlcmd -E -S cluster-sql1 -Q "SELECT 'CONNECTED'"출력은 다음과 같이 표시됩니다.
RESULTS: ------------------------------------------------------------ CONNECTED (1 rows affected)연결할 수 없는 경우 DNS가 올바르게 작동하는지, AWS와 Google Cloud 서브넷 사이에 방화벽 규칙이 열려 있는지 확인하세요.
C:\SQLData및C:\SQLLog에 폴더를 만듭니다. 데이터베이스 데이터와 로그 파일은 이러한 폴더를 사용합니다.New-Item "C:\SQLData" –type directory New-Item "C:\SQLLog" –type directoryC:\SQLBackup에 폴더를 만들고\\cluster-sql2\SQLBackup에 Windows 공유를 만들어 AWS 인스턴스에서 백업을 전송합니다. 두 서버 모두에서 사용 가능한 다른 네트워크 공유를 사용할 수 있습니다.New-Item "C:\SQLBackup" –type directory New-SmbShare -Name "SQLBackup" -Path "C:\SQLBackup" -FullAccess "dbeng.com\cluster-sql1$","dbeng.com\cluster-sql2$","NT SERVICE\MSSQLSERVER","authenticated users","dbeng.com\sql_service"
이제 가용성 그룹의 인스턴스가 준비되었습니다. 인스턴스가 2개뿐이므로 다음 섹션에서는 파일 공유 감시를 구성하여 동률 처리 기능을 제공하고 쿼럼을 확보하도록 하세요.
파일 공유 감시 생성
동률 처리 기능을 제공하고 장애 조치 시나리오를 위한 쿼럼을 확보하기 위해 감시 역할을 하는 파일 공유를 만들 수 있습니다. 이 튜토리얼에서는 도메인 컨트롤러 VM에 파일 공유 감시를 만듭니다. 프로덕션 환경에서는 Active Directory 도메인 내 모든 서버에서 파일 공유 감시를 만들 수 있습니다.
dbeng\Administrator계정을 사용하여 RDP를 통해 도메인 컨트롤러 VM,dc-windows에 연결합니다.- 관리자 권한 PowerShell을 엽니다(관리자 권한으로 실행).
감시 폴더를 만듭니다.
New-Item "C:\QWitness" –type directory이 폴더를 공유합니다.
New-SmbShare -Name "QWitness" -Path "C:\QWitness" -Description "SQL File Share Witness" -FullAccess "dbeng.com\Administrator", "dbeng.com\cluster-sql1$", "dbeng.com\cluster-sql2$"dbeng.com\Administrator를 사용하여 RDP를 통해cluster-sql1및cluster-sql2에 모두 연결합니다.두 서버에서 공유 디렉터리에 액세스할 수 있는지 확인합니다.
dir \\dc-windows\QWitness공유 디렉터리에 액세스할 수 없으면 노드의 네트워크 연결을 변경하여 WINS 서버가 도메인 서버와 일치하도록 설정해 보세요. 네트워크 연결을 변경하는 데 몇 초 정도 걸릴 수 있습니다. 다음 스크린샷은 업데이트된 WINS 설정을 보여줍니다.
이제 모든 것이 준비되어 가용성 그룹을 사용할 수 있습니다. 다음 섹션에서는 장애 조치 클러스터링을 구성합니다.
장애 조치 클러스터링 구성
이 섹션에서는 WSFC를 구성하고 두 인스턴스에 대해 Always On 고가용성을 사용 설정합니다. AWS의 인스턴스에서 다음 구성 명령어를 모두 실행합니다.
- RDP를 사용하여
cluster-sql1인스턴스에 연결합니다. - 관리자 권한 PowerShell을 엽니다(관리자 권한으로 실행).
클러스터 환경을 반영하는 변수를 설정하세요. 이 예시에서는 다음과 같이 변수를 설정합니다.
$node1 = "cluster-sql1.dbeng.com" $node2 = "cluster-sql2.dbeng.com" $nameWSFC = "cluster-dbclus" #Name of cluster $ipWSFC1 = "192.168.1.5" #IP address of cluster in subnet 1 (AWS) $ipWSFC2 = "10.1.1.5" #IP address of cluster in subnet 2 (Google Cloud)장애 조치 클러스터를 만듭니다(이 명령어를 실행하는 데 다소 시간이 걸릴 수 있음).
New-Cluster -Name $nameWSFC -Node $node1, $node2 -NoStorage -StaticAddress $ipWSFC1, $ipWSFC2 Set-ClusterQuorum -FileShareWitness \\dc-windows\QWitness노드 1에서 Always On 고가용성을 사용 설정하세요. 이전에 Always On을 사용 설정하지 않았으면 이 명령어를 사용하면 SQL Server가 강제로 다시 시작됩니다.
Enable-SqlAlwaysOn -ServerInstance $node1 -Force노드 2에서 Always On 고가용성을 사용 설정하세요. 이 명령어는 SQL Always On을 사용 설정하기 전에 SQL Server 서비스를 중지시키므로 다음과 같은 내용의 오류를 무시해도 됩니다:
Enable-SqlAlwaysOn : StopService failed for Service 'MSSQLSERVER'Get-Service -ComputerName $node2 -Name "MSSQLServer" | Stop-Service -Force Enable-SqlAlwaysOn -ServerInstance $node2 -Force Get-Service -ComputerName $node2 -Name "MSSQLServer" | Start-ServiceC:\SQLData및C:\SQLLog에 폴더를 만듭니다. 이 폴더를 TestDB 데이터베이스 데이터 및 로그 파일에 사용합니다. 서버에 이러한 폴더 구조의 데이터베이스가 이미 있는 경우 이 단계를 건너뛸 수 있습니다. 확실하지 않은 경우 명령어를 실행하고 기존 폴더에 대한 오류 메시지는 무시합니다.New-Item "C:\SQLData" –type directory New-Item "C:\SQLLog" –type directory
장애 조치 클러스터 관리자가 준비되었습니다. 다음으로 가용성 그룹을 만들겠습니다.
가용성 그룹 만들기
이 섹션에서는 AWS에서 테스트 데이터베이스(cluster-sql1)를 만들고 새 가용성 그룹에서 작동하도록 구성합니다. 또는 가용성 그룹에 기존 데이터베이스를 지정할 수 있습니다.
- RDP를 사용하여
cluster-sql1인스턴스에 연결합니다. - 관리자 권한 PowerShell을 엽니다(관리자 권한으로 실행).
C:\SQLBackup에 폴더를 만들어 데이터베이스의 백업을 저장합니다. 새 데이터베이스에 가용성 그룹을 설정하려면 백업이 필요합니다.New-Item "C:\SQLBackup" –type directory아직 데이터베이스를 구성하지 않은 경우 SQL Server Management Studio를 실행하고 AWS 인스턴스(
cluster-sql1)에 테스트 데이터베이스를 만듭니다.CREATE DATABASE TestDB ON PRIMARY (NAME = 'TestDB_Data', FILENAME='C:\SQLData\TestDB_Data.mdf', SIZE = 256MB, MAXSIZE = UNLIMITED, FILEGROWTH = 256MB ) LOG ON (NAME = 'TestDB_Log', FILENAME='C:\SQLLog\TestDB_Log.ldf', SIZE = 256MB, MAXSIZE = UNLIMITED, FILEGROWTH = 256MB ) GO USE [TestDB] Exec dbo.sp_changedbowner @loginame = 'sa', @map = false; ALTER DATABASE [TestDB] SET RECOVERY FULL; GO BACKUP DATABASE TestDB to disk = 'C:\SQLBackup\TestDB-backup.bak' WITH INIT GOMicrosoft SQL Server Management Studio에서 쿼리 > SQLCMD 모드를 선택합니다.
SQL Server Management Studio는 가용성 그룹을 만드는 마법사를 제공합니다. 이 튜토리얼에서는 여러 클라우드 제공업체를 연결하는 동안 발생할 수 있는 문제를 더 쉽게 디버깅할 수 있도록 SQL 명령어를 대신 사용합니다. 원하는 경우 가용성 그룹 마법사를 실행하고 이후 단계로 건너뛰어 가용성 그룹이 동기화 중인지 확인할 수 있습니다.
SQLCMD 모드에서 다음 쿼리를 실행하세요. 기존 데이터베이스를 사용하는 경우
TestDB를 데이터베이스 이름으로 바꿉니다.첫 번째 노드에서 엔드포인트를 만들고 엔드포인트에 권한을 부여합니다.
:Connect CLUSTER-SQL1 IF NOT EXISTS (SELECT state FROM sys.endpoints WHERE name = N'Hadr_endpoint') BEGIN CREATE ENDPOINT [Hadr_endpoint] AS TCP (LISTENER_PORT = 5022) FOR DATA_MIRRORING (ROLE = WITNESS, ENCRYPTION = REQUIRED ALGORITHM AES) END GO IF (SELECT state FROM sys.endpoints WHERE name = N'Hadr_endpoint') <> 0 BEGIN ALTER ENDPOINT [Hadr_endpoint] STATE = STARTED END GO use [master] GO IF SUSER_ID('DBENG\sql_service') IS NULL CREATE LOGIN [DBENG\sql_service] FROM WINDOWS GO GRANT CONNECT ON ENDPOINT::[Hadr_endpoint] TO [DBENG\sql_service] GO첫 번째 노드에서
AlwaysOn_health확장 이벤트 세션을 사용 설정합니다. 가용성 그룹에는 확장 이벤트 세션이 필요합니다.:Connect CLUSTER-SQL1 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두 번째 노드에 엔드포인트를 만들고 엔드포인트에 권한을 부여합니다.
:Connect CLUSTER-SQL2 IF NOT EXISTS (SELECT state FROM sys.endpoints WHERE name = N'Hadr_endpoint') BEGIN CREATE ENDPOINT [Hadr_endpoint] AS TCP (LISTENER_PORT = 5022) FOR DATA_MIRRORING (ROLE = WITNESS, ENCRYPTION = REQUIRED ALGORITHM AES) END GO IF (SELECT state FROM sys.endpoints WHERE name = N'Hadr_endpoint') <> 0 BEGIN ALTER ENDPOINT [Hadr_endpoint] STATE = STARTED END GO use [master] GO IF SUSER_ID('DBENG\sql_service') IS NULL CREATE LOGIN [DBENG\sql_service] FROM WINDOWS GO GRANT CONNECT ON ENDPOINT::[Hadr_endpoint] TO [DBENG\sql_service] GO두 번째 노드에서
AlwaysOn_health확장 이벤트 세션을 사용 설정합니다. 가용성 그룹에는 확장 이벤트 세션이 필요합니다.:Connect CLUSTER-SQL2 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첫 번째 노드에서 가용성 그룹을 만듭니다.
:Connect CLUSTER-SQL1 USE [master] GO --DROP AVAILABILITY GROUP [cluster-ag]; GO CREATE AVAILABILITY GROUP [cluster-ag] WITH (AUTOMATED_BACKUP_PREFERENCE = SECONDARY, DB_FAILOVER = OFF, DTC_SUPPORT = NONE) FOR DATABASE [TestDB] REPLICA ON N'CLUSTER-SQL1' WITH (ENDPOINT_URL = N'TCP://CLUSTER-SQL1.dbeng.com:5022', FAILOVER_MODE = MANUAL, AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT, BACKUP_PRIORITY = 50, SEEDING_MODE = MANUAL), N'CLUSTER-SQL2' WITH (ENDPOINT_URL = N'TCP://cluster-sql2.dbeng.com:5022', FAILOVER_MODE = MANUAL, AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT, BACKUP_PRIORITY = 50, SEEDING_MODE = MANUAL); GO두 번째 노드를 새로 만든 가용성 그룹에 조인합니다.
:Connect CLUSTER-SQL2 ALTER AVAILABILITY GROUP [cluster-ag] JOIN; GO첫 번째 노드에서 데이터베이스 백업을 만듭니다.
:Connect CLUSTER-SQL1 BACKUP DATABASE [TestDB] TO DISK = N'\\CLUSTER-SQL2\SQLBackup\TestDB.bak' WITH COPY_ONLY, FORMAT, INIT, SKIP, REWIND, NOUNLOAD, COMPRESSION, STATS = 5 GO두 번째 노드에서 데이터베이스 백업을 복원합니다.
:Connect CLUSTER-SQL2 RESTORE DATABASE [TestDB] FROM DISK = N'\\CLUSTER-SQL2\SQLBackup\TestDB.bak' WITH NORECOVERY, NOUNLOAD, STATS = 5 GO첫 번째 노드에서 트랜잭션 로그 백업을 만듭니다.
:Connect CLUSTER-SQL1 BACKUP LOG [TestDB] TO DISK = N'\\CLUSTER-SQL2\SQLBackup\TestDB.trn' WITH NOFORMAT, INIT, NOSKIP, REWIND, NOUNLOAD, COMPRESSION, STATS = 5 GO두 번째 노드에서 트랜잭션 로그 백업을 복원합니다.
:Connect CLUSTER-SQL2 RESTORE LOG [TestDB] FROM DISK = N'\\CLUSTER-SQL2\SQLBackup\TestDB.trn' WITH NORECOVERY, NOUNLOAD, STATS = 5 GO
동기화에서 오류가 발생하지 않도록 하려면 다음 쿼리를 실행하고
connected_state_desc열의 값이CONNECTED인지 확인합니다.:Connect CLUSTER-SQL2 select r.replica_server_name, r.endpoint_url, rs.connected_state_desc, rs.last_connect_error_description, rs.last_connect_error_number, rs.last_connect_error_timestamp from sys.dm_hadr_availability_replica_states rs join sys.availability_replicas r on rs.replica_id=r.replica_id where rs.is_local=1connected_state_desc열에An error occurred while receiving data: '24(The program issued a command but the command length is incorrect)'오류 메시지가 표시되면 다음 명령어를 실행하여 오류를 제거합니다.:Connect CLUSTER-SQL1 IF SUSER_ID('DBENG\CLUSTER-SQL2$') IS NULL CREATE LOGIN [DBENG\CLUSTER-SQL2$] FROM WINDOWS GO GRANT CONNECT ON ENDPOINT::[Hadr_endpoint] TO [DBENG\CLUSTER-SQL2$] GO :Connect CLUSTER-SQL2 IF SUSER_ID('DBENG\CLUSTER-SQL1$') IS NULL CREATE LOGIN [DBENG\CLUSTER-SQL1$] FROM WINDOWS GO GRANT CONNECT ON ENDPOINT::[Hadr_endpoint] TO [DBENG\CLUSTER-SQL1$] GO이전 쿼리를 다시 실행하여 동기화 오류가 더 이상 발생하지 않도록 합니다. 오류가 해결될 때까지 몇 분 정도 기다려야 할 수 있습니다. 오류가 계속되면 Always On 가용성 그룹 구성 문제 해결(SQL Server)을 참조하세요.
가용성 그룹 설정을 완료합니다.
:Connect CLUSTER-SQL2 ALTER DATABASE [TestDB] SET HADR AVAILABILITY GROUP = [cluster-ag] GO ALTER DATABASE [TestDB] SET HADR RESUME; GO가용성 그룹이 동기화 중인지 확인하세요.
SQL Server Management Studio의 Always On 고가용성 > 가용성 그룹에서 가용성 그룹을 마우스 오른쪽 버튼으로 클릭한 다음 대시보드 표시를 선택합니다.
다음 스크린샷과 같이 기본 동기화 상태가 Synchronized(동기화됨)이고 보조 동기화 상태가 Synchronizing(동기화 중)인지 확인합니다.
리스너를 추가하려면 Always On 고가용성 > 가용성 그룹 >
cluster-ag (Primary)> 가용성 그룹 리스너에서 가용성 그룹 이름을 마우스 오른쪽 버튼으로 클릭한 다음 리스너 추가를 선택합니다.새 가용성 그룹 리스터 대화상자에서 리스너에 대한 다음 매개변수를 지정합니다.
- 리스너 DNS 이름:
ag-listener - 포트:
1433 - 네트워크 모드:
Static IP
- 리스너 DNS 이름:
두 개의 서브넷과 IP 주소 필드를 추가합니다. 이 예시에서는 다음 서브넷 및 IP 주소 쌍을 사용합니다. 이 쌍은 SQL 서비스 인스턴스 VM의 기본 IP 주소 외에 직접 만든 IP 주소입니다.
- 첫 번째 쌍에 다음 값을 입력합니다.
- 서브넷:
192.168.1.0/24 - IPv4 주소:
192.168.1.6
- 서브넷:
- 두 번째 쌍에 다음 값을 입력합니다.
- 서브넷:
10.1.1.0/24 - IPv4 주소:
10.1.1.6
- 서브넷:
- 첫 번째 쌍에 다음 값을 입력합니다.
서브넷 및 IP 주소 쌍 추가를 마치면 확인을 클릭합니다.
인스턴스 이름 대신 SQL Server 데이터베이스의 이름으로
ag-listener.dbeng.com을 사용하여 SQL Server에 연결합니다. 이 연결은 현재의 활성 인스턴스를 가리킵니다.- 객체 탐색기에서 연결을 클릭한 후 데이터베이스 엔진을 선택합니다.
- 서버에 연결 대화상자의 서버 이름 필드에 리스너의 이름을
ag-listener.dbeng.com으로 입력합니다. 서버 이름을 추가한 후 연결을 클릭합니다. 객체 탐색기는 다음 스크린샷과 같이 새 연결을 보여줍니다.
RDP를 사용하여
cluster-sql2에 연결한 경우 선택적으로 이 단계를 반복하여 연결을 설정할 수 있습니다.
테스트 데이터 추가
이 섹션에서는 cluster-sql1의 TestDB 데이터베이스에 테스트 테이블 및 일부 테스트 데이터를 추가한 다음 데이터 복제를 확인합니다.
cluster-sql1에Persons이라는 테이블을 만드세요.:Connect CLUSTER-SQL1 USE TestDB; CREATE TABLE Persons ( PersonID int, LastName varchar(255), FirstName varchar(255), PRIMARY KEY (PersonID) );몇 개의 행을 삽입합니다.
:Connect CLUSTER-SQL1 USE TestDB; INSERT INTO Persons (PersonId, LastName, FirstName) VALUES (1, 'Velasquez', 'Ava'); INSERT INTO Persons (PersonId, LastName, FirstName) VALUES (2, 'Delaxcrux', 'Paige');Enterprise 버전을 사용하는 경우 읽기 복제본(
cluster-sql2)의 읽기 액세스를 사용 설정하여 복제가 발생하는지 확인할 수 있습니다. Standard 버전은 읽기 복제본에 대한 읽기 전용 액세스를 지원하지 않습니다. Standard 버전을 사용하는 경우 다음 섹션으로 건너뛰고 Google Cloud로 컷오버를 실행합니다.:Connect CLUSTER-SQL1 ALTER AVAILABILITY GROUP [cluster-ag] MODIFY REPLICA ON N'CLUSTER-SQL2' WITH (SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL)) GOEnterprise 버전에서
cluster-sql2의 테이블을 쿼리하여 테이블 콘텐츠가 복제되었는지 확인합니다.:Connect CLUSTER-SQL2 SELECT * FROM TestDB.dbo.Persons;
이제 컷오버를 실행하는 데이터가 cluster-sql1에서 cluster-sql2로 복제됩니다. 복제만 수행하려는 경우 다음 섹션을 건너뛰고 컷오버 또는 대체를 실행하지 마세요. 복제 수행에 사용한 리소스를 원하지 않으면 이 가이드 마지막의 삭제 단계를 수행하여 요금이 청구되지 않게 할 수 있습니다.
Google Cloud로 컷오버 실행
일관된 데이터세트를 보장하려면 컷오버를 실행하기 전에 모든 데이터를 cluster-sql2에 복제할 수 있도록 cluster-sql1에 쓰는 모든 클라이언트를 중지시켜야 합니다.
일관성을 유지하려면 모든 데이터를 완전히 복제해야 합니다. 이 섹션에서는 가용성 모드를 SYNCHRONOUS_COMMIT으로 변경하여 완전한 데이터 복제를 수행합니다. 이 변경으로 cluster-sql1이 cluster-sql2로 완전히 복제됩니다.
두 노드의 가용성 모드를 동기 커밋으로 변경하려면
cluster-sql1에서 다음 SQL 명령어를 실행합니다. 두 노드를 모두 동기 커밋으로 설정하는 것이 데이터 손실을 방지하는 유일한 방법입니다.:Connect CLUSTER-SQL1 ALTER AVAILABILITY GROUP [cluster-ag] MODIFY REPLICA ON N'CLUSTER-SQL1' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT) GO ALTER AVAILABILITY GROUP [cluster-ag] MODIFY REPLICA ON N'CLUSTER-SQL2' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT) GO이제
Cluster-sql2가 기본 노드가 될 준비가 되었습니다.cluster-sql2에 연결하고 기본 노드로 지정하세요.:Connect CLUSTER-SQL2 ALTER AVAILABILITY GROUP [cluster-ag] FAILOVER; GO두 노드 모두에서 가용성 모드를 비동기 커밋으로 변경합니다.
cluster-sql2가 기본 노드이므로cluster-sql2에서 다음 SQL 명령어를 실행합니다.:Connect CLUSTER-SQL2 ALTER AVAILABILITY GROUP [cluster-ag] MODIFY REPLICA ON N'CLUSTER-SQL1' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT) GO ALTER AVAILABILITY GROUP [cluster-ag] MODIFY REPLICA ON N'CLUSTER-SQL2' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT) GO이제
cluster-sql2를 애플리케이션의 기본 노드로 사용할 수 있습니다.cluster-sql1은 비동기식으로 복제된 보조 노드입니다.이제
cluster-sql2가 기본 노드이므로cluster-sql2의 테이블을 쿼리하여 테이블 콘텐츠가 복제되었는지 확인하세요.:Connect CLUSTER-SQL2 SELECT * FROM TestDB.dbo.Persons;출력은 이 튜토리얼의 앞부분에서 테이블에 삽입한 테스트 데이터와 일치합니다.
추가 복제 확인을 수행하려면 새 테이블을 만들고 새 기본 테이블에 단일 행을 삽입하면 됩니다. 테이블과 해당 행이 보조에 나타나면 복제가 작동하는 것입니다.
대체
경우에 따라 새 기본을 원래 기본으로 되돌려야 할 수도 있습니다. 이 튜토리얼의 앞부분에서 Google Cloud로 컷오버를 완료했을 때 이전의 기본(cluster-sql1)을 새 기본(cluster-sql2)에 대한 보조로 만들었습니다.
대체를 완료하려면 Google Cloud로 컷오버를 실행하는 프로세스에 따라 다음 값을 바꿉니다.
- 원래의 기본(
cluster-sql1)을 새 기본(cluster-sql2)으로 바꿉니다. - 원래의 보조(
cluster-sql2)를 새 보조(cluster-sql1)로 바꿉니다.
정리
이 튜토리얼에서 사용된 리소스 비용이 Google Cloud 계정에 청구되지 않도록 하려면 리소스가 포함된 프로젝트를 삭제하거나 프로젝트를 유지하고 개별 리소스를 삭제하세요.
이 가이드에서 사용한 리소스 비용이 Google Cloud 계정에 청구되지 않도록 하려면 다음 안내를 따르세요.
Google Cloud에서 프로젝트 삭제
- Google Cloud 콘솔에서 리소스 관리 페이지로 이동합니다.
- 프로젝트 목록에서 삭제할 프로젝트를 선택하고 삭제를 클릭합니다.
- 대화상자에서 프로젝트 ID를 입력한 후 종료를 클릭하여 프로젝트를 삭제합니다.
AWS에서 프로젝트 삭제
AWS에서 리소스를 만들고 사용했기 때문에 그냥 두면 비용이 계속 발생하게 됩니다. 더 이상 비용이 발생하지 않게 하려면 AWS에서 해당 리소스를 삭제하세요.
다음 단계
- SQL Server용 문서 및 솔루션 자세히 살펴보기
- Google Cloud에 대한 참조 아키텍처, 다이어그램, 권장사항 살펴보기 Cloud 아키텍처 센터 살펴보기