이 글에서는 Windows Server 2019 환경에서 실행되는 SQL Server에 Always On 가용성 그룹(Availability Groups)을 설치하고 구성하는 전 과정을 단계별로 안내합니다. 장애 조치(Failover) 시나리오와 함께 실무에서 자주 마주치는 오류 해결 방법까지 상세히 다룹니다.
Always On 가용성 그룹은 Microsoft SQL Server에서 고가용성(HA)을 제공하는 핵심 기능으로, MSSQL 2012 버전부터 도입되었습니다.
SQL Server Always On 가용성 그룹의 주요 기능
SQL Server 가용성 그룹은 다음과 같은 용도로 활용할 수 있습니다.
- MS SQL의 고가용성 확보 및 자동 장애 조치(Failover)
- 노드 간 SELECT 쿼리 부하 분산 (보조 복제본을 읽기 전용으로 사용 가능)
- 보조 복제본에서의 백업 수행
- 데이터 이중화 — 각 복제본이 가용성 그룹 데이터베이스의 사본을 보관
Always On은 Windows Server 장애 조치 클러스터(WSFC)를 기반으로 동작합니다. WSFC는 가용성 그룹 노드를 모니터링하며 자동 장애 조치를 수행합니다. 참고로 MS SQL Server 2017부터는 WSFC 없이도 Always On을 사용할 수 있으며, Linux 호스트에서도 지원됩니다. Linux 기반 클러스터를 구축할 때는 WSFC 대신 Pacemaker를 사용할 수 있습니다.
Standard Edition과 Enterprise Edition의 차이
Always On은 Standard 에디션에서도 사용 가능하지만 몇 가지 제약이 있습니다.
- 복제본은 최대 2개 (주 복제본 1개 + 보조 복제본 1개)로 제한
- 보조 복제본을 읽기 용도로 사용 불가
- 보조 복제본에서 백업 수행 불가
- 가용성 그룹당 데이터베이스 1개만 지원
Enterprise 에디션에는 이러한 제한이 없습니다.
핵심 용어 정리
- Always On 가용성 그룹: 복제본과 데이터베이스의 집합
- 복제본(Replica): 가용성 그룹에 속한 SQL Server 인스턴스. 주 복제본(Primary) 또는 보조 복제본(Secondary) 역할을 가지며, 하나의 복제본은 여러 개의 데이터베이스를 포함할 수 있습니다.
각 가용성 그룹 노드는 반드시 Windows 장애 조치 클러스터의 멤버여야 하며, 각 SQL Server 인스턴스는 여러 개의 가용성 그룹을 가질 수 있습니다. 하나의 가용성 그룹은 최대 8개의 보조 복제본까지 구성할 수 있습니다.
주 복제본에 장애가 발생하면 클러스터가 투표를 통해 새로운 주 복제본을 선출하고, Always On이 보조 복제본 중 하나를 주 복제본으로 승격시킵니다. 사용자는 Always On 작업 시 리스너(Listener)(특수한 클러스터 IP 주소와 해당 DNS 이름)에 접속하기 때문에, 장애 조치 후에도 쓰기 쿼리를 정상적으로 실행할 수 있습니다. 리스너는 또한 보조 복제본 간 SELECT 쿼리 부하 분산 역할도 담당합니다.
Always On을 위한 Windows 장애 조치 클러스터 구성
먼저 Always On에서 사용할 모든 노드에 장애 조치 클러스터를 구성해야 합니다.
테스트 환경 구성
- Windows Server 2019가 설치된 가상 머신 2대
- SQL Server 2019 Enterprise 인스턴스 2개
- 노드 호스트명: testnode1, testnode2 / SQL Server 인스턴스명: node1, node2
1단계: 장애 조치 클러스터링 역할 설치
서버 관리자(Server Manager)를 통해 장애 조치 클러스터링(Failover Clustering) 역할을 추가하거나, PowerShell로 설치할 수 있습니다.
Install-WindowsFeature –Name Failover-Clustering –IncludeManagementTools
설치는 자동으로 진행되며, 별도의 설정은 아직 필요하지 않습니다.
2단계: 클러스터 생성
장애 조치 클러스터 관리자(Failover Cluster Manager) 스냅인(FailoverClusters.SnapInHelper.msc)을 실행하여 새 클러스터를 생성합니다. 클러스터에 참여시킬 호스트 이름들을 추가한 뒤, 마법사가 제공하는 유효성 검사 테스트를 진행합니다.
3단계: 클러스터 이름 및 IP 설정
클러스터 이름을 지정하고 네트워크와 클러스터 IP 주소를 선택합니다. 클러스터 이름은 DNS에 자동으로 등록되므로 DNS 레코드를 수동으로 만들 필요가 없습니다. 이 예제에서는 클러스터 이름을 ClusterAG로 지정했습니다.
이후 디스크 추가 옵션(Add all eligible storage to the cluster)은 나중에 추가할 수 있으므로 체크를 해제합니다.
4단계: 클러스터 쿼럼(Cluster Quorum) 구성
클러스터가 두 개의 노드만으로 구성된 경우 클러스터 쿼럼 구성이 필수입니다. 쿼럼은 결정권 투표 역할을 합니다. 예를 들어 클러스터 노드 중 하나가 사용 불가 상태가 되면, 클러스터는 어떤 노드가 실제로 온라인 상태이고 서로 통신 가능한지 판별해야 합니다. 쿼럼은 이러한 클러스터 일관성을 보장합니다 (클러스터 → 추가 작업 → 클러스터 쿼럼 설정 구성).
쿼럼 감시(Witness) 유형 중 파일 공유 감시(File Share Witness)를 선택하고, 공유 폴더의 UNC 경로를 지정합니다. 이 디렉터리는 직접 생성해야 하며, 반드시 장애 조치 클러스터 외부의 서버에 위치해야 합니다.
파일 공유 감시 오류 발생 시 해결 방법
클러스터 구성 중 다음과 같은 오류가 나타날 수 있습니다.
There was an error configuring the file share witness. Unable to save property changes for File Share Witness. The system cannot find the file specified.
이는 클러스터가 실행 중인 사용자 계정에 공유 폴더 접근 권한(NTFS 권한)이 없기 때문일 가능성이 높습니다. 기본적으로 클러스터는 로컬 사용자 계정으로 실행됩니다. 클러스터의 모든 컴퓨터 계정에 폴더 권한을 부여하거나, 클러스터 서비스의 실행 계정을 변경한 후 해당 계정에 권한을 부여하면 해결됩니다.
이것으로 Windows 장애 조치 클러스터의 기본 구성이 완료되었습니다.
MS SQL Server에서 Always On 가용성 그룹 구성
SQL Server 인스턴스를 일반적인 방식으로 설치한 후, Always On 가용성 그룹을 활성화하고 구성할 수 있습니다.
1단계: Always On 기능 활성화
SQL Server 구성 관리자(SQL Server Configuration Manager)에서 인스턴스 속성을 열어 Always On을 활성화합니다. 아래와 같이 SQL Server가 이미 WSFC 클러스터에 속해 있는 것을 자동으로 감지한 것을 확인할 수 있습니다. Enable Always On Availability Groups를 체크하고 MSSQL 인스턴스 서비스를 재시작합니다. 두 번째 인스턴스에도 동일하게 적용합니다.
팁: Always On 구성 전에 SQL Server 서비스가 로컬 시스템(Local System) 계정으로 실행 중이지 않은지 반드시 확인하세요. 그룹 관리 서비스 계정(gMSA) 또는 일반 도메인 계정 사용을 권장합니다. 그렇지 않으면 Always On 구성을 완료할 수 없습니다.
2단계: 새 가용성 그룹 마법사 실행
SSMS(SQL Server Management Studio)를 실행하여 호스트에 연결한 후, Always On 고가용성을 우클릭하고 새 가용성 그룹 마법사(New Availability Group Wizard)를 실행합니다.
참고로 SSMS 18.x에서는 SQL Server 2017/2019의 일부 Always On 설정(GUI에서만 지원)을 T-SQL 없이 설정할 수 있으므로, 최신 버전의 SSMS 사용을 권장합니다.
가용성 그룹 이름을 지정하고 Database Level Health Detection 옵션을 선택합니다. 이 옵션을 사용하면 Always On이 특정 데이터베이스에 문제가 발생했을 때 이를 감지할 수 있습니다.
3단계: 데이터베이스 및 복제본 추가
가용성 그룹에 추가할 SQL Server 데이터베이스를 선택합니다. Add Replica를 클릭해 두 번째 SQL 서버를 연결합니다. 이런 식으로 최대 8대의 서버까지 추가할 수 있습니다.
복제본 구성 시 주요 옵션은 다음과 같습니다.
- Initial Role(초기 역할): 그룹 생성 시점의 복제본 역할. Primary 또는 Secondary 중 선택
- Automatic Failover(자동 장애 조치): 데이터베이스를 사용할 수 없게 되면 Always On이 주 역할을 다른 복제본으로 이전. 필수 체크 항목
- Availability Mode(가용성 모드): 동기 커밋(Synchronous Commit) 또는 비동기 커밋(Asynchronous Commit) 선택. 동기 모드에서는 주 복제본에 들어온 트랜잭션이 동기 모드로 설정된 모든 보조 복제본에 전송되며, 주 복제본은 다른 복제본들이 디스크에 기록을 완료한 후에야 트랜잭션을 종료합니다. 따라서 주 복제본 장애 시에도 데이터 손실이 없습니다. 비동기 모드에서는 주 복제본이 다른 복제본의 응답을 기다리지 않고 즉시 변경 사항을 기록합니다.
- Readable Secondary(읽기 가능 보조 복제본): 보조 복제본에 대해 SELECT 쿼리 실행을 허용하는 파라미터. 'Yes'로 설정하면 클라이언트가
ApplicationIntent=readonly없이 연결해도 읽기 전용 접근이 가능합니다. - Required synchronized secondaries to commit(커밋에 필요한 동기화 보조 복제본 수): 트랜잭션을 완료하기 위해 필요한 동기화된 보조 복제본의 개수. 복제본 수에 맞게 설정하며, 이 예제에서는 1로 설정했습니다.
Endpoint 탭에서는 아무것도 수정하지 않습니다.
4단계: 백업 기본 설정
Backup Preferences 탭에서는 백업을 어느 복제본에서 수행할지 선택할 수 있습니다. 기본값인 Prefer Secondary(보조 복제본 우선)를 그대로 두는 것을 권장합니다.
5단계: 리스너 구성 및 동기화
가용성 그룹 리스너의 이름, 포트, IP 주소를 지정합니다. Read-Only Routing 설정은 기본값으로 유지합니다.
복제본 동기화 유형을 선택합니다. 여기서는 첫 번째 항목인 Automatic seeding(자동 초기화)을 체크한 상태로 진행했습니다.
이후 설정 검증이 진행되며, 오류가 없으면 Finish를 클릭해 변경 사항을 적용합니다.
리스너 생성 오류(EVENTID 1194) 해결
모든 테스트가 성공했음에도 불구하고, 설치 후 결과 단계에서 가용성 그룹 리스너 생성 오류가 발생하는 경우가 있습니다. 클러스터 이벤트 로그에 EVENTID 1194가 기록됩니다.
Cluster network name resource failed to create its associated computer object in the domain.
이는 클러스터에 리스너 생성 권한이 충분하지 않다는 의미입니다. Microsoft 문서에 따르면 클러스터 개체에 컴퓨터 유형 개체 생성 권한만 부여하면 됩니다. AD에서 권한 위임(delegation)을 통해 처리하는 것이 안전하며, 빠르지만 비권장 방법으로 CLUSTERAG$ 개체를 임시로 Domain Admins 그룹에 추가하는 방법도 있습니다.
가용성 그룹 진단이나 SQL 성능 저하 문제를 분석할 때는 SQL Server의 표준 진단 도구뿐 아니라 Windows 클러스터 로그도 면밀히 살펴봐야 합니다.
6단계: 리스너 수동 추가
이 예제에서는 가용성 그룹은 생성되었지만 리스너가 생성되지 않았으므로, 수동으로 추가했습니다. 가용성 그룹의 컨텍스트 메뉴를 열고 Add Listener를 클릭합니다.
리스너의 IP 주소, 포트, DNS 이름을 지정한 후, Always On 그룹의 Availability Group Listeners 섹션에 리스너가 정상적으로 표시되는지 확인합니다.
이로써 Always On 가용성 그룹의 기본 구성이 완료되었습니다.
SQL Server Always On: 동작 확인 및 장애 조치 테스트
가용성 그룹 대시보드(Availability Group Dashboard)를 열어 상태를 확인합니다. 그룹이 정상적으로 생성되고 동작 중임을 확인할 수 있습니다.
수동 장애 조치(Failover) 테스트
node2를 수동으로 주 인스턴스로 만들어 보겠습니다. 가용성 그룹을 우클릭하고 Failover를 선택합니다.
Failover Readiness 값을 주목하세요. No data loss로 표시되면 장애 조치 과정에서 데이터가 손실되지 않음을 의미합니다. node2에 연결한 후 Finish를 클릭하고, node2가 가용성 그룹의 주 복제본(Primary Instance)으로 전환되었는지 확인합니다.
리스너 연결 확인
리스너가 올바르게 동작하는지 확인합니다. SSMS에서 리스너 DNS 이름과 포트를 쉼표로 구분하여 입력합니다. 예: ag1-listener-1,1445
데이터베이스에 간단한 INSERT, SELECT, UPDATE 쿼리를 실행해 정상 동작을 검증합니다.
자동 장애 조치 테스트
주 복제본의 자동 장애 조치를 확인해 보겠습니다. TESTNODE2에서 sqlservr.exe 프로세스를 강제 종료합니다.
남아 있는 노드(TESTNODE1\NODE1)에서 가용성 그룹 상태를 확인합니다. testnode2\node2가 사용 불가 상태가 되자, 클러스터가 자동으로 testnode1\node1의 상태를 주(Primary)로 전환했습니다.
쿼럼 오류 발생 시 대처 방법
리스너 상태도 확인해야 합니다. 클라이언트는 리스너를 통해 접속하기 때문입니다. 이 예제에서는 리스너 연결에는 성공했지만, 데이터베이스에 접근하려 할 때 다음과 같은 오류가 발생했습니다.
Unable to access database 'TestDatabase' because it lacks a quorum of nodes for high availability. Try the operation again later.
이 오류는 Required synchronized secondaries to commit 옵션 때문에 발생했습니다. 구성 시 이 값을 1로 설정했기 때문에, 남은 주 복제본이 하나뿐인 현재 상황에서 Always On이 데이터베이스 접속을 허용하지 않는 것입니다.
이 값을 0으로 변경한 후 쿼리를 다시 실행하면 정상 동작합니다.
testnode1은 주 인스턴스 상태를 유지했고, testnode2는 보조 복제본이 되었습니다. testnode2가 꺼져 있는 동안 testnode1에서 변경한 데이터는 컴퓨터가 다시 켜진 후 성공적으로 동기화되었습니다.
마무리
지금까지 모든 것이 올바르게 동작하며, 치명적인 장애가 발생해도 데이터를 읽기/쓰기 가능한 상태로 유지할 수 있음을 확인했습니다. Always On 가용성 그룹은 생각보다 쉽게 구성할 수 있으며, SQL Server 기반의 장애 조치 솔루션을 구축하려는 경우 가용성 그룹이 훌륭한 선택이 될 것입니다.