적용 대상:
SQL Server - Windows만 해당
Always On 가용성 그룹에 도입된 고가용성 재해 복구 솔루션인 SQL Server 2012(11.x)을 사용하려면 WSFC(Windows Server 장애 조치(Failover) 클러스터링)가 필요합니다. 또한 Always On 가용성 그룹은 SQL Server 장애 조치(failover) 클러스터링에 종속되지 않지만 FCI(장애 조치(failover) 클러스터링 인스턴스)를 사용하여 가용성 그룹에 대한 가용성 복제본을 호스트할 수 있습니다. 각 클러스터링 기술의 역할을 알고 Always On 가용성 그룹 환경을 설계할 때 필요한 고려 사항을 아는 것이 중요합니다.
참고 항목
Always On 가용성 그룹 개념에 대한 자세한 내용은 Always On 가용성 그룹이란?
Windows Server 장애 조치 클러스터링 및 가용성 그룹
Always On 가용성 그룹를 배포하려면 WSFC(Windows Server Failover 클러스터)가 필요합니다. Always On 가용성 그룹를 활성화하려면 SQL Server 인스턴스가 WSFC 노드에 있고 WSFC 및 노드가 온라인 상태여야 합니다. 또한 지정된 가용성 그룹의 각 가용성 복제본은 동일한 WSFC의 서로 다른 노드에 있어야 합니다. 유일한 예외는 다른 WSFC로 마이그레이션되는 동안 가용성 그룹이 일시적으로 두 클러스터에 걸쳐 있는 경우입니다.
Always On 가용성 그룹는 WSFC(Windows Server 장애 조치(failover) 클러스터)를 사용하여 지정된 가용성 그룹에 속해 있는 가용성 복제본의 현재 역할을 모니터링 및 관리하고 장애 조치(failover) 이벤트가 가용성 복제본에 미치는 영향을 확인합니다. WSFC 리소스 그룹은 생성하는 모든 가용성 그룹에 대해 만들어집니다. WSFC는 이 리소스 그룹을 모니터링하여 주 복제본의 상태를 평가합니다.
Always On 가용성 그룹에 대한 쿼럼은 지정된 클러스터 노드가 가용성 복제본을 호스팅하는지 여부에 관계없이 WSFC의 모든 노드를 기반합니다. 데이터베이스 미러링과 달리 Always On 가용성 그룹에는 증인 역할이 없습니다.
WSFC의 전반적인 상태는 클러스터에 있는 노드 쿼럼의 투표에 의해 결정됩니다. 계획되지 않은 재해나 영구적인 하드웨어 또는 통신 장애로 인해 WSFC가 오프라인으로 전환된 경우 수동 관리 작업을 수행해야 합니다. Windows Server 또는 WSFC 관리자는 강제 쿼럼을 수행하고 내결함성이 없는 구성에서 활성 클러스터 노드를 다시 온라인으로 전환해야 합니다.
중요
Always On 가용성 그룹 레지스트리 키는 WSFC의 하위 키입니다. WSFC를 삭제하고 다시 만들려는 경우 원본 WSFC에서 가용성 복제본을 호스팅한 SQL Server의 각 인스턴스에서 Always On 가용성 그룹 기능을 비활성화했다가 다시 활성화해야 합니다.
WSFC 노드에서 SQL Server를 실행하고 WSFC 쿼럼에 대한 자세한 내용은 SQL Server를 사용한 Windows Server 장애 조치(failover) 클러스터링을 참조하세요.
SQL Server 장애 조치 클러스터 인스턴스 (FCI) 및 가용성 그룹
WSFC와 함께 SQL Server 및 FCI를 구현하여 서버 인스턴스 수준에서 장애 조치(failover)의 두 번째 계층을 설정할 수 있습니다. SQL Server의 독립 실행형 인스턴스 또는 FCI 인스턴스는 가용성 복제본을 호스트할 수 있습니다. 지정된 가용성 그룹의 복제본은 하나의 FCI 파트너에서만 호스팅할 수 있습니다. 가용성 복제본이 FCI에서 실행 중인 경우 가용성 그룹에 대한 가능한 소유자 목록에는 활성 FCI 노드만 포함됩니다.
Always On 가용성 그룹은 어떤 형태의 공유 스토리지도 의존하지 않습니다. 하지만 SQL Server FCI(장애 조치(Failover) 클러스터 인스턴스)를 사용하여 하나 이상의 가용성 복제본을 호스팅하는 경우 각 FCI에는 표준 SQL Server 장애 조치(Failover) 클러스터 인스턴스 설치와 같이 공유 스토리지가 있어야 합니다.
추가 필수 구성 요소에 대한 자세한 내용은 Always On 가용성 그룹(SQL Server)에 대한 필수 구성 요소, 제한 사항 및 권장 사항을 참조하세요.
장애 조치 클러스터 인스턴스와 가용성 그룹 비교
FCI의 노드 수에 관계 없이 전체 FCI는 가용성 그룹 내의 단일 복제본을 호스팅합니다. 다음 표에서는 FCI의 노드와 가용성 그룹 내 복제본 간의 개념적인 차이에 대해 설명합니다.
| FCI 내의 노드 | 가용성 그룹 내의 복제본 | |
|---|---|---|
| WSFC 사용 | 예 | 예 |
| 보호 수준 | 인스턴스 | 데이터베이스 |
| 스토리지 유형 | 공유 | 공유되지 않음 가용성 그룹의 복제본은 스토리지를 공유하지 않지만 FCI에서 호스트하는 복제본은 해당 FCI에서 요구하는 대로 공유 스토리지 솔루션을 사용합니다. 스토리지 솔루션은 FCI 내 노드에 의해서만 공유되고 가용성 그룹의 복제본 사이에서는 공유되지 않습니다. |
| 스토리지 솔루션 | 직접 연결됨, SAN, 탑재 지점, SMB | 노드 유형에 따라 다름 |
| 읽기 가능한 보조 복제본 | 아니요* | 예 |
| 적용할 수 있는 장애 조치(Failover) 정책 설정 | WSFC 쿼럼 FCI별 가용성 그룹 설정** |
WSFC 쿼럼 가용성 그룹 설정 |
| 장애 조치(Failover)가 실행된 리소스 | 서버, 인스턴스 및 데이터베이스 | 데이터베이스에만 해당 |
*가용성 그룹의 동기 보조 복제본은 항상 해당 SQL Server 인스턴스에서 실행되는 반면 FCI의 보조 노드는 실제로 해당 SQL Server 인스턴스를 시작하지 않았으므로 읽을 수 없습니다. FCI에서 보조 노드는 리소스 그룹 소유권이 FCI 장애 조치(Failover) 중 보조 노드로 전달된 경우에만 해당 SQL Server 인스턴스를 시작합니다. 그러나 활성 FCI 노드에서 FCI 호스팅 데이터베이스가 가용성 그룹에 속하는 경우 로컬 가용성 복제본이 읽을 수 있는 보조 복제본으로 실행 중인 경우 데이터베이스를 읽을 수 있습니다.
**가용성 그룹에 대한 장애 조치(failover) 정책 설정은 독립 실행형 인스턴스 또는 FCI 인스턴스에서 호스트되는지 여부에 관계없이 모든 복제본에 적용됩니다.
FCI에서 가용성 복제본을 호스트하기 위한 고려 사항
중요
SQL Server FCI(장애 조치(failover) 클러스터 인스턴스)에서 가용성 복제본을 호스트하려는 경우 Windows Server 2008 호스트 노드가 FCI(장애 조치(failover) 클러스터 인스턴스)에 대한 Always On 필수 구성 요소 및 제한을 충족하는지 확인합니다. 자세한 내용은 Always On 가용성 그룹 필수 구성 요소, 제한 사항 및 권장 사항(SQL Server)을 참조하세요.
SQL Server FCI(장애 조치(failover) 클러스터 인스턴스)는 가용성 그룹의 자동 장애 조치(failover)를 지원하지 않으므로 FCI 호스트가 호스트하는 가용성 복제본은 수동 장애 조치(failover)에 대해서만 구성할 수 있습니다.
모든 노드에서 사용할 수 없는 공유 디스크를 포함하도록 WSFC를 구성해야 할 수 있습니다. 예를 들어 세 개의 노드와 두 데이터 센터에 걸쳐 있는 WSFC가 있다고 가정합니다. 두 노드는 기본 데이터 센터에서 SQL Server FCI를 호스트하고 동일한 공유 디스크에 액세스할 수 있습니다. 세 번째 노드는 다른 데이터 센터에서 SQL Server의 독립 실행형 인스턴스를 호스팅하며 기본 데이터 센터에서 공유 디스크에 액세스할 수 없습니다. 이 WSFC 구성은 FCI가 주 복제본을 호스트하고 독립 실행형 인스턴스가 보조 복제본을 호스트하는 경우 가용성 그룹 배포를 지원합니다.
지정된 가용성 그룹에 대한 가용성 복제본을 호스트하도록 FCI를 선택하는 경우 FCI 장애 조치(failover)로 인해 단일 WSFC 노드가 동일한 가용성 그룹에 대해 두 개의 가용성 복제본을 호스트하려고 시도할 수 없는지 확인합니다.
다음 예에서는 이 구성을 사용할 경우 발생할 수 있는 문제를 보여 줍니다.
-
NODE01NODE02두 개의 노드를 사용하여 WSFC를 구성합니다. -
fciInstance1과NODE01에 SQL Server 장애 조치(failover) 클러스터 인스턴스NODE02를 설치하며,NODE01가 현재fciInstance1의 소유자입니다. - 에서는
NODE02독립 실행형 인스턴스인Instance3SQL Server의 다른 인스턴스를 설치합니다. -
NODE01에서 Always On 가용성 그룹에 대해fciInstance1을 사용하도록 설정합니다.NODE02에서 Always On 가용성 그룹에 대해Instance3을 사용하도록 설정합니다. 그런 다음fciInstance1주 복제본을 호스트하고Instance3보조 복제본을 호스트하는 가용성 그룹을 설정합니다. - 어느 시점에서
fciInstance1가NODE01에서 사용할 수 없게 되면, WSFC는fciInstance1를NODE02로 장애 조치(failover)를 수행합니다. 장애 조치(Failover) 후fciInstance1은 Always On 가용성 그룹에서 주 역할로 실행되는NODE02사용 인스턴스가 되지만.Instance3은 이제fciInstance1과 동일한 WSFC 노드에 있습니다. 이 경우 Always On 가용성 그룹 제약 조건을 위반하게 됩니다.
이 시나리오에서 발생하는 문제를 해결하려면 독립 실행형 인스턴스 Instance3가 NODE01 및 NODE02와 동일한 WSFC 내의 다른 노드에 있어야 합니다.
SQL Server FCI에 대한 자세한 내용은 Always On 장애 조치(failover) 클러스터 인스턴스(SQL Server)를 참조하세요.
가용성 그룹에서 WSFC 관리자 사용에 대한 제한 사항
장애 조치(failover) 클러스터 관리자를 사용하여 가용성 그룹을 조작하지 마세요. 다음은 그 예입니다.
가용성 그룹에 대한 클러스터형 서비스(리소스 그룹)에서 리소스를 추가하거나 제거하지 마세요.
가능한 소유자 및 기본 설정 소유자와 같은 가용성 그룹 속성을 변경하지 마세요. 이러한 속성은 가용성 그룹에 의해 자동으로 설정됩니다.
장애 조치(failover) 클러스터 관리자를 사용하여 가용성 그룹을 다른 노드로 이동하거나 가용성 그룹을 장애 조치하지 마세요. 장애 조치(failover) 클러스터 관리자는 가용성 복제본의 동기화 상태를 인식하지 못하므로 가동 중지 시간이 길어질 수 있습니다. Transact-SQL 또는 SQL Server Management Studio를 사용해야 합니다.
경고
장애 조치(failover) 클러스터 관리자를 사용하여 가용성 그룹을 호스트하는 장애 조치(failover) 클러스터 인스턴스 를 동일한 가용성 그룹의 복제본을 이미 호스팅하는 노드로 이동하면 가용성 그룹 복제본이 손실되어 대상 노드에서 온라인 상태가 되지 않을 수 있습니다. 장애 조치(failover) 클러스터의 단일 노드는 동일한 가용성 그룹에 대해 둘 이상의 복제본을 호스트할 수 없습니다. 이 발생 방법 및 복구 방법에 대한 자세한 내용은 가용성 그룹에서 예기치 않게 삭제된 블로그 복제본을 참조하세요.
관련 콘텐츠
- Always On 가용성 그룹이란?
- Always On 가용성 그룹 기능 사용 또는 사용 안 함
- 가용성 그룹 모니터링(Transact-SQL)
- Always On 페일오버 클러스터 인스턴스(SQL Server)
- 제한된 보안을 사용하여 SQL Server의 Windows 장애 조치(Failover) 클러스터링 구성(가용성 그룹 또는 FCI)
- SQL Server Always On 팀 블로그: 공식 SQL Server Always On 팀 블로그
- CSS SQL Server 엔지니어 블로그
- Always On 아키텍처 가이드: 장애 조치(failover) 클러스터 인스턴스 및 가용성 그룹을 사용하여 고가용성 및 재해 복구 솔루션 빌드
- 고가용성 및 재해 복구를 위한 Microsoft SQL Server Always On 솔루션 가이드