SQL Server on Windows 고가용성 그룹(AG) 구성 (3)

이번 포스팅에서 다룰 내용은 SQL Server를 온프레미스(On-premise) 서버를 가정한 Azure 상의 가상 머신에 설치하기 위해 만든 SQL-VM-1 과 SQL-VM-2 를 가용성 그룹으로 결합하는 과정입니다. 

 

우리가 그동안 준비해 온 모든 퍼즐 조각을 Always On 가용성 그룹으로 직접 만들어서, 두 SQL Server VM을 하나의 강력한 시스템으로 결합해 봅시다.

 

SQL-VM-1에 접속하여 SSMS의 개체 탐색기에서 Always On High Availability를 클릭하고 새 가용성 그룹 마법사를 선택합니다. 

 

데이터베이스를 선택합니다. 

 

두 번째 서버를 가용성 그룹에 추가하기 위해 Add Replica를 클릭합니다. 

 

SQL-VM-2를 연결해줍니다. 

 

복제본 지정 페이지에서 자동 장애 조치(Failover) 확인란을 선택하고 드롭다운에서 가용성 모드에 대해 Synchronous commit을 선택합니다. 

 

 

 

VM Inbound port에서 열어준 5022 번이 설정되었는지 확인하고 가용성그룹 수신기를 만들 때는 SQL Server VM의 수신기에 대한 보조 전용 IP 주소를 선택해줍니다. 

 

 

초기 데이터 동기화 선택 페이지에서 전체 데이터베이스 및 로그 백업을 선택하고, 이전에 만든 네트워크 공유 위치를 제공합니다. 

 

이렇게하면 가용성 그룹을 정상적으로 만드는게 성공한 겁니다. 이제 가용성 그룹이 정상적으로 동작하는지 확인해보겠습니다. 

 

개체 탐색기에서 Always On 고가용성, 가용성 그룹을 차례로 펼칩니다. 이 컨테이너에 새 가용성 그룹이 표시됩니다. 가용성 그룹을 마우스 오른쪽 단추로 클릭하고 대시보드 표시를 선택합니다.

 

가용성 그룹 대시보드에는 다음 예와 같이 복제본, 각 복제본의 장애 조치(failover) 모드 및 동기화 상태가 표시됩니다.

 

Failover Cluster Manager 를 열고, 클러스터를 선택한 다음, Roles 을 선택하여 클러스터 내에서 만든 가용성 그룹 역할을 확인합니다. AG1 역할을 선택하고, Resources 탭을 선택하여 다음 예와 같이 수신기 및 연결된 IP 주소를 확인합니다.

 

그러나 Failover Cluster Manager 로 장애 조치를 하면 안니다.

우리가 Failover Cluster Manager 를 사용해서 클러스터를 만들고 관리했지만, 가용성 그룹의 장애 조치만큼은 이 도구를 사용해서는 안 됩니다. 장애 조치 클러스터 관리자는 클러스터의 전반적인 상태를 관리하는 도구입니다. 하지만 가용성 그룹의 장애 조치에는 단순히 역할을 다른 서버로 넘기는 것 이상의 복잡한 과정이 포함됩니다.

 

예를 들어, 데이터베이스의 동기화 상태를 확인하고, 연결된 복제본 간의 상태를 올바르게 전환하는 등의 작업이 필요합니다. 장애 조치 클러스터 관리자를 통해 장애 조치를 시도하면, 이러한 SQL Server의 내부적인 절차를 무시하고 강제로 역할을 전환하게 되어 데이터베이스가 비정상적인 상태가 되거나, 연결 문제가 발생할 수 있습니다.

 

모든 장애 조치 작업은 반드시 SQL Server Management Studio(SSMS) 내에서 수행해야 합니다.

1. Always On 대시보드 사용: SSMS의 Always On 대시보드는 복제본의 동기화 상태를 한눈에 보여주며, 안전하게 장애 조치를 할 수 있는 기능을 제공합니다.

2. Transact-SQL(T-SQL) 사용: T-SQL 명령어를 사용하여 장애 조치를 실행할 수도 있습니다.

 

 

 

이제 가용성 그룹이 올바르게 만들어졌는지 확인하는 마지막 단계입니다. 우리가 만든 수신기(AG1-Listener)에 외부에서 제대로 접속할 수 있는지 테스트하는 과정입니다. 이 테스트는 실제 애플리케이션이 우리 데이터베이스에 어떻게 연결될지를 검증하는 아주 중요한 작업입니다.

 

우리가 만든 MyDB1에 새로운 테이블을 만들고 데이터를 입력합니다. 

USE MyDB1
GO
CREATE TABLE dbo.TestHA(
	ID INT PRIMARY KEY,
	[TEXT] NVARCHAR(50)
);
GO
INSERT INTO dbo.TestHA (ID, [TEXT]) VALUES(1, 'Hello World!');
GO

 

보조 복제본( 현재 대기 중인 서버 )이 쿼리를 허용하도록 설정되어 있지 않습니다. 기본적으로 보조 복제본은 주 복제본의 데이터를 실시간으로 받기만 할 뿐, 외부에서의 읽기(Read) 요청을 허용하지 않습니다. 우리가 보조 복제본에서 데이터를 조회하려면, 이 설정을 별도로 활성화해줘야 합니다.

 

개체 탐색기에서 Always On 고가용성 > 가용성 그룹을 확장합니다.

읽기 가능한 보조(Readable Secondary) 항목의 드롭다운 메뉴를 Yest로 변경합니다. 

 

 

현재 보조 복제본인 SQL Server로 접속해 SSMS에서 아래와 같이 쿼리를 조회하여 확인해봅니다. 

 

다음으로 사용자가 직접 역할을 전환하여, 보조 복제본이 주 복제본으로 전환되는 과정을 확인해봅시다.

 

현재 주 복제본에 연결된 SSMS의 개체 탐색기에서 AG1을 클릭하고 Failover를 선택합니다. 

 

장애 조치할 새 주 복제본 선택 페이지에서 현재 보조 복제본인 서버를 선택합니다. 

 

 

해당 서버의 장애 조치를 진행하고 완료합니다. 

 

장애 조치가 진행되었으니 그동안 역할이 바뀌었을까요?

 

확인하기 위해 Failover Cluster Manager로 접근하면 SQL-VM-2가 주 역할을 담당하고 있음을 확인할 수 있습니다. 

 

다음 테스트로 주 복제본의 SQL Server를 중지할 때 역할이 전환되는지 확인해보겠습니다. 

 

우선 현재 주 복제본인 서버에 접속 후 Failover manager에서 AG1의 속성을 열어 failover탭으로 이동합니다.

 

이후 Maximum failure in the specified period 를 10으로 변경합니다.

Windows Server Failover Clustering 에서 특정 클러스터에 대해 지정된 기간 내에 허용된 최대 장애 설정 부분입니다. 이 항목의 디폴트값은 1로 되어 있는데, 이럴 경우 클러스터가 리소스를 한번 실패 상태로 인식하면 그 기간 내에서는 추가로 자동으로 장애 조치(재시작 또는 장애 조치)를 시도하지 않고, 바로 리소스를 Failed 상태로 두게 됩니다. 따라서 해당 옵션값을 조정해야 동작합니다.

 

이렇게 해야 SQL-1이 죽었다고 시스템 전체가 Failed 하고 멈추는 걸 방지하고, SQL-2로 변경할 수 있습니다. 

 

SQL Server Configuration Manager를 열고 SQL Server 서비스를 마우스 오른쪽 단추로 클릭한 후 중지를 선택합니다. 

 

 

자동으로 SQL 서버 1번으로 바뀌는 것을 확인할 수 있습니다.