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