장애 조치(Failover) 클러스터링 및 AlwaysOn 가용성 그룹(SQL Server)

아티클
08/27/2013

SQL Server 2012에 도입된 고가용성 재해 복구 솔루션인 AlwaysOn 가용성 그룹을 사용하려면 WSFC(Windows Server 장애 조치(Failover) 클러스터링)가 필요합니다. 또한 AlwaysOn 가용성 그룹을 사용하는 데 SQL Server 장애 조치(Failover) 클러스터링이 필요하지 않더라도 FCI(장애 조치(Failover) 클러스터링 인스턴스)를 사용하여 가용성 그룹의 가용성 복제본을 호스팅할 수 있습니다. 각 클러스터링 기술의 역할과 AlwaysOn 가용성 그룹 환경을 디자인하는 데 고려해야 할 사항을 알고 있어야 합니다.

[!참고]

AlwaysOn 가용성 그룹 개념에 대한 자세한 내용은 AlwaysOn 가용성 그룹 개요(SQL Server)를 참조하십시오.

항목 내용:

Windows Server 장애 조치(Failover) 클러스터링
SQL Server 장애 조치(Failover) 클러스터링
가용성 그룹과 WSFC 장애 조치(Failover) 클러스터 관리자 사용에 대한 제한 사항

Windows Server 장애 조치(Failover) 클러스터링 및 가용성 그룹

AlwaysOn 가용성 그룹을 배포하려면 WSFC(Windows Server 장애 조치(Failover) 클러스터링) 클러스터가 필요합니다. AlwaysOn 가용성 그룹을 사용하도록 설정하려면 SQL Server 인스턴스가 WSFC 노드에 있고 WSFC 클러스터 및 노드가 온라인 상태여야 합니다. 또한 지정된 가용성 그룹의 각 가용성 복제본은 동일한 WSFC 클러스터의 서로 다른 노드에 있어야 합니다. 유일한 예외는 다른 WSFC 클러스터로 마이그레이션되는 동안 가용성 그룹이 일시적으로 두 클러스터에 걸쳐 있는 경우입니다.

AlwaysOn 가용성 그룹은 WSFC(Windows Server 장애 조치(Failover) 클러스터링) 클러스터를 사용하여 지정된 가용성 그룹에 속해 있는 가용성 복제본의 현재 역할을 모니터링 및 관리하고 장애 조치(Failover) 이벤트가 가용성 복제본에 미치는 영향을 확인합니다. WSFC 리소스 그룹은 생성하는 모든 가용성 그룹에 대해 만들어집니다. WSFC 클러스터는 이 리소스 그룹을 모니터링하여 주 복제본의 상태를 평가합니다.

AlwaysOn 가용성 그룹에 대한 쿼럼은 지정된 클러스터 노드가 가용성 복제본을 호스팅하는지 여부에 관계없이 WSFC 클러스터의 모든 노드를 기반합니다. 데이터베이스 미러링과 달리 AlwaysOn 가용성 그룹에는 모니터 역할이 없습니다.

WSFC 클러스터의 전반적인 상태는 클러스터에 있는 노드 쿼럼의 투표에 의해 결정됩니다. 계획되지 않은 재해나 영구적인 하드웨어 또는 통신 장애로 인해 WSFC 클러스터가 오프라인으로 전환된 경우 수동 관리 작업을 수행해야 합니다. Windows Server 또는 WSFC 클러스터 관리자는 강제 쿼럼을 수행하고 내결함성이 없는 구성에서 활성 클러스터 노드를 다시 온라인으로 전환해야 합니다.

중요
AlwaysOn 가용성 그룹 레지스트리 키는 WSFC 클러스터의 하위 키입니다. WSFC 클러스터를 삭제한 다음 다시 만들려는 경우 원본 WSFC 클러스터에서 가용성 복제본을 호스팅한 SQL Server의 각 인스턴스에서 AlwaysOn 가용성 그룹 기능을 사용하지 않도록 설정한 후 다시 사용하도록 설정해야 합니다.

WSFC(Windows Server 장애 조치(Failover) 클러스터링) 노드에서 SQL Server를 실행하는 방법과 WSFC 쿼럼에 대한 자세한 내용은 SQL Server의 WSFC(Windows Server 장애 조치(Failover) 클러스터링)를 참조하십시오.

맨 위로 이동 링크와 함께 사용되는 화살표 아이콘 [맨 위]

OS 업그레이드를 위한 AlwaysOn 가용성 그룹의 클러스터 간 마이그레이션

SQL Server 2012 SP1부터 AlwaysOn 가용성 그룹에서는 새 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) 클러스터링을 구현하여 서버 인스턴스 수준에서 장애 조치(Failover)의 두 번째 계층을 설정할 수 있습니다. 가용성 복제본은 독립 실행형 SQL Server 인스턴스 또는 FCI 인스턴스에서 호스팅할 수 있습니다. 지정된 가용성 그룹의 복제본은 하나의 FCI 파트너에서만 호스팅할 수 있습니다. 가용성 복제본이 FCI에서 실행 중인 경우 가용성 그룹에 대한 가능한 소유자 목록에는 활성 FCI 노드만 포함됩니다.

AlwaysOn 가용성 그룹은 어떤 형태의 공유 저장소에도 종속되지 않습니다. 하지만 SQL Server FCI(장애 조치(Failover) 클러스터 인스턴스)를 사용하여 하나 이상의 가용성 복제본을 호스팅하는 경우 각 FCI에는 표준 SQL Server 장애 조치(Failover) 클러스터 인스턴스 설치와 같이 공유 저장소가 있어야 합니다.

사전 요구 사항에 대한 자세한 내용은 온라인 설명서의 AlwaysOn 가용성 그룹(SQL Server)에 대한 사전 요구 사항, 제한 사항 및 권장 사항의 "가용성 복제본을 호스팅하기 위해 SQL Server FCI(장애 조치 클러스터 인스턴스) 사용에 대한 사전 요구 사항 및 제한 사항" 섹션을 참조하십시오.

장애 조치(Failover) 클러스터 인스턴스와 가용성 그룹 비교

FCI의 노드 수에 관계 없이 전체 FCI는 가용성 그룹 내의 단일 복제본을 호스팅합니다. 다음 표에서는 FCI의 노드와 가용성 그룹 내 복제본 간의 개념적인 차이에 대해 설명합니다.

	FCI 내의 노드	가용성 그룹 내의 복제본
WSFC 클러스터 사용	예	예
보호 수준	인스턴스	데이터베이스
저장소 유형	공유됨	공유되지 않음1
저장소 솔루션	직접 연결됨, SAN, 탑재 지점, SMB	노드 유형에 따라 다름
읽기 가능한 보조 복제본	아니요2	예
적용할 수 있는 장애 조치(Failover) 정책 설정	WSFC 쿼럼 FCI별 가용성 그룹 설정3	WSFC 쿼럼 가용성 그룹 설정
장애 조치(Failover)가 실행된 리소스	서버, 인스턴스 및 데이터베이스	데이터베이스만

1가용성 그룹의 복제본은 저장소를 공유하지 않는 반면 FCI가 호스팅하는 복제본은 해당 FCI가 요구하는 대로 공유 저장소 솔루션을 사용합니다. 저장소 솔루션은 FCI 내 노드에 의해서만 공유되고 가용성 그룹의 복제본 사이에서는 공유되지 않습니다.

2가용성 그룹의 동기적 보조 복제본은 항상 해당 SQL Server 인스턴스에서 실행되는 반면 FCI의 보조 노드는 실제로 해당 SQL Server 인스턴스를 시작하지 않았으며 따라서 읽을 수 없습니다. FCI에서 보조 노드는 리소스 그룹 소유권이 FCI 장애 조치(Failover) 중 보조 노드로 전달된 경우에만 해당 SQL Server 인스턴스를 시작합니다. 하지만 FCI가 호스팅하는 데이터베이스가 가용성 그룹에 속해 있을 때 활성 FCI 노드에서 로컬 가용성 복제본이 읽기 가능한 보조 복제본으로 실행되는 경우 이 데이터베이스는 읽을 수 있습니다.

3가용성 그룹에 대한 장애 조치(Failover) 정책 설정은 독립 실행형 인스턴스에서 호스팅되는지 FCI 인스턴스에서 호스팅되는지에 관계없이 모든 복제본에 적용됩니다.

[!참고]

장애 조치(Failover) 클러스터링 내의 노드 수 및 다양한 버전의 SQL Server용 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) 클러스터 인스턴스)에서 가용성 복제본을 호스팅하려는 경우 Windows Server 2008 호스트 노드가 FCI에 대한 AlwaysOn 사전 요구 사항 및 제한 사항을 충족하는지 확인해야 합니다. 자세한 내용은 온라인 설명서의 AlwaysOn 가용성 그룹(SQL Server)에 대한 사전 요구 사항, 제한 사항 및 권장 사항을 참조하십시오.

SQL ServerFCI(장애 조치(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은 NODE01 및 NODE02 모두에 SQL Server 장애 조치(Failover) 클러스터 인스턴스 fciInstance1을 설치합니다. 여기에서 NODE01은 fciInstance1의 현재 소유자입니다.
Marcel은 NODE02에 독립 실행형 인스턴스인 또 다른 SQL Server 인스턴스, Instance3을 설치합니다.
Marcel은 NODE01에서 AlwaysOn 가용성 그룹을 사용하도록 fciInstance1을 설정합니다. NODE02에서 Marcel은 AlwaysOn 가용성 그룹을 사용하도록 Instance3을 설정합니다. 그런 다음 Marcel은 fciInstance1이 주 복제본을 호스팅하고 Instance3이 보조 복제본을 호스팅하는 가용성 그룹을 설정합니다.
어느 시점에 NODE01에서 fciInstance1을 사용할 수 없게 되면 WSFC 클러스터를 통해 fciInstance1에서 NODE02로 장애 조치(Failover)가 수행됩니다. 장애 조치(Failover) 후 fciInstance1은 NODE02에서 주 역할로 실행되는 AlwaysOn 가용성 그룹 사용 인스턴스가 되지만 Instance3은 이제 fciInstance1과 동일한 WSFC 노드에 있습니다. 이 경우 AlwaysOn 가용성 그룹 제약 조건을 위반하게 됩니다.

이 시나리오에서 발생한 문제를 해결하려면 독립 실행형 인스턴스인 Instance3이 NODE01 및 NODE02와 동일한 WSFC 클러스터의 다른 노드에 있어야 합니다.

SQL Server 장애 조치(Failover) 클러스터링에 대한 자세한 내용은 AlwaysOn 장애 조치(failover) 클러스터 인스턴스(SQL Server)를 참조하십시오.

맨 위로 이동 링크와 함께 사용되는 화살표 아이콘 [맨 위]

가용성 그룹과 WSFC 장애 조치(Failover) 클러스터 관리자 사용에 대한 제한 사항

다음의 예처럼 장애 조치(Failover) 클러스터 관리자를 사용하여 가용성 그룹을 조작하지 마십시오.

가용성 그룹에 대한 클러스터형 서비스(리소스 그룹)에 리소스를 추가하거나 제거하지 마십시오.
가능한 소유자 및 기본 설정 소유자와 같은 가용성 그룹 속성을 변경하지 마십시오. 이러한 속성은 가용성 그룹에 의해 자동으로 설정됩니다.
장애 조치(Failover) 클러스터 관리자를 사용하여 가용성 그룹을 다른 노드로 옮기거나 가용성 그룹을 장애 조치(Failover)을 수행하지 마십시오. 장애 조치(Failover) 클러스터 관리자에서는 가용성 복제본의 동기화 상태를 인식하지 못하기 때문에 이로 인해 작동 중지 시간이 길어질 수 있습니다. Transact-SQL 또는 SQL Server Management Studio를 사용해야 합니다.

맨 위로 이동 링크와 함께 사용되는 화살표 아이콘 [맨 위]