Always On 장애 조치 클러스터 인스턴스(SQL Server)

SQL Server Always On 제품의 일부로 Always On 장애 조치(failover) 클러스터 인스턴스는 WSFC(Windows Server 장애 조치(failover) 클러스터링) 기능을 활용하여 서버 인스턴스 수준 FCI( 장애 조치(failover) 클러스터 인스턴스 )에서 중복성을 통해 로컬 고가용성을 제공합니다. FCI는 WSFC(Windows Server 장애 조치(failover) 클러스터링) 노드 및 여러 서브넷에 설치된 SQL Server의 단일 인스턴스입니다. 네트워크에서 FCI는 단일 컴퓨터에서 실행되는 SQL Server의 인스턴스로 보이지만 현재 노드를 사용할 수 없게 되면 FCI는 한 WSFC 노드에서 다른 WSFC 노드로 장애 조치(failover)를 제공합니다.

FCI는 Always On 가용성 그룹을활용하여 데이터베이스 수준에서 원격 재해 복구를 제공할 수 있습니다. 자세한 내용은 장애 조치 클러스터링 및 Always On 가용성 그룹(SQL Server).

항목 내용

• 혜택

• 권장 사항

• 장애 조치 클러스터 인스턴스 개요

• 장애 조치 클러스터 인스턴스의 구성 요소

• SQL Server 장애 조치 개념 및 작업

• 관련 항목

장애 조치 클러스터 인스턴스의 장점

서버의 하드웨어 또는 소프트웨어 오류가 발생하면 서버에 연결하는 애플리케이션 또는 클라이언트에 가동 중지 시간이 발생합니다. SQL Server 인스턴스가 독립 실행형 인스턴스 대신 FCI로 구성된 경우 해당 SQL Server 인스턴스의 고가용성이 FCI에 중복 노드가 있으면 보호됩니다. FCI의 노드 중 하나만 한 번에 WSFC 리소스 그룹을 소유합니다. 오류(하드웨어 오류, 운영 체제 오류, 애플리케이션 또는 서비스 오류) 또는 계획된 업그레이드의 경우 리소스 그룹 소유권이 다른 WSFC 노드로 이동됩니다. 이 프로세스는 SQL Server에 연결하는 클라이언트 또는 애플리케이션에 투명하며, 이렇게 하면 오류 발생 시 애플리케이션 또는 클라이언트가 발생하는 가동 중지 시간을 최소화할 수 있습니다. 다음은 SQL Server 장애 조치(failover) 클러스터 인스턴스가 제공하는 몇 가지 주요 이점을 나열합니다.

• 중복성을 통해 인스턴스 수준에서 보호

• 오류가 발생할 경우 하드웨어, 운영 체제, 애플리케이션 또는 서비스의 장애를 자동으로 처리하는 시스템

  중요합니다

  Always On 가용성 그룹에서는 FCI에서 가용성 그룹 내의 다른 노드로 자동 장애 조치(failover)가 지원되지 않습니다. 즉, 자동 장애 조치(failover)가 고가용성 솔루션의 중요한 구성 요소인 경우 FCI와 독립 실행형 노드를 가용성 그룹 내에서 함께 결합해서는 안 됩니다. 그러나 재해 복구 솔루션에 대해 이 결합을 수행할 수 있습니다.

• WSFC 클러스터 디스크(iSCSI, 파이버 채널 등) 및 SMB(서버 메시지 블록) 파일 공유를 비롯한 광범위한 스토리지 솔루션 지원

• 다중 서브넷 FCI를 사용하거나 Always On 가용성 그룹 내에서 FCI 호스팅 데이터베이스를 실행하는 재해 복구 솔루션입니다. MicrosoftSQL Server 2012의 새로운 다중 서브넷 지원을 사용하면 다중 서브넷 FCI에 더 이상 가상 LAN이 필요하지 않아 다중 서브넷 FCI의 관리 효율성과 보안이 향상됩니다.

• 장애 조치(failover) 중 애플리케이션 및 클라이언트의 재구성 0개

• 유연한 자동 장애 조치 정책과 구체적인 트리거 이벤트에 대한 정책

• 전용 연결과 지속 가능한 연결을 사용하여 주기적이고 상세한 상태 감지를 통해 신뢰할 수 있는 장애 조치를 보장합니다.

• 간접 백그라운드 검사점을 통한 장애 조치 시간의 설정 가능성과 예측 가능성

• 장애 조치(failover) 중 제한된 리소스 사용량

권장 사항

프로덕션 환경에서는 장애 조치(failover) 클러스터 인스턴스의 가상 IP 주소와 함께 고정 IP 주소를 사용하는 것이 좋습니다. 프로덕션 환경에서 DHCP를 사용하지 않도록 하는 것이 좋습니다. 가동 중지 시간이 발생하는 경우 DHCP IP 임대가 만료되면 DNS 이름과 연결된 새 DHCP IP 주소를 다시 등록하는 데 추가 시간이 필요합니다.

장애 조치 클러스터 인스턴스 개요

FCI는 하나 이상의 WSFC 노드가 있는 WSFC 리소스 그룹에서 실행됩니다. FCI가 시작되면 노드 중 하나가 리소스 그룹의 소유권을 가정하고 SQL Server 인스턴스를 온라인 상태로 설정합니다. 이 노드가 소유한 리소스는 다음과 같습니다.

• 네트워크 이름

• IP 주소

• 공유 디스크

• SQL Server 데이터베이스 엔진 서비스

• SQL Server 에이전트 서비스

• SQL Server Analysis Services 서비스(설치된 경우)

• FILESTREAM 기능이 설치된 경우 하나의 파일 공유 리소스

언제든지 리소스 그룹 소유자(및 FCI의 다른 노드 없음)만 리소스 그룹에서 해당 SQL Server 서비스를 실행하고 있습니다. 자동 장애 조치 또는 계획된 장애 조치가 발생하는 경우, 다음과 같은 이벤트 순서가 진행됩니다.

1. 하드웨어 또는 시스템 오류가 발생하지 않는 한 버퍼 캐시의 모든 더티 페이지는 디스크에 기록됩니다.

2. 리소스 그룹의 모든 SQL Server 서비스는 활성 노드에서 중지됩니다.

3. 리소스 그룹 소유권은 FCI의 다른 노드로 전송됩니다.

4. 새 리소스 그룹 소유자가 SQL Server 서비스를 시작합니다.

5. 클라이언트 애플리케이션 연결 요청은 동일한 VNN(가상 네트워크 이름)을 사용하여 새 활성 노드로 자동으로 전달됩니다.

FCI는 기본 WSFC 클러스터가 양호한 쿼럼 상태인 한 온라인 상태입니다(대부분의 쿼럼 WSFC 노드는 자동 장애 조치(failover) 대상으로 사용할 수 있음). 하드웨어, 소프트웨어, 네트워크 오류 또는 부적절한 쿼럼 구성으로 인해 WSFC 클러스터의 쿼럼이 손실되면 FCI와 함께 전체 WSFC 클러스터가 오프라인 상태가 됩니다. 그런 다음, WSFC 클러스터 및 FCI를 다시 온라인 상태로 전환하기 위해 사용 가능한 나머지 노드에서 쿼럼을 다시 설정하려면 이 계획되지 않은 장애 조치 시나리오에서 수동 개입이 필요합니다. 자세한 내용은 WSFC 쿼럼 모드 및 투표 구성(; SQL Server);.

예측 가능한 장애 조치(failover) 시간

SQL Server 인스턴스가 검사점 작업을 마지막으로 수행한 시기에 따라 버퍼 캐시에 상당한 양의 더티 페이지가 있을 수 있습니다. 따라서 장애 전환은 나머지 더티 페이지를 디스크에 쓰는 데 걸리는 시간만큼 지속되어, 이로 인해 장애 전환 시간이 길어질 수 있으며 예측하기 어렵습니다. MicrosoftSQL Server 2012부터 FCI는 간접 검사점을 사용하여 버퍼 캐시에 보관된 더티 페이지의 양을 제한할 수 있습니다. 이렇게 하면 일반 워크로드에서 추가 리소스를 소비하지만 장애 조치(failover) 시간을 더 예측 가능하고 구성할 수 있습니다. 이는 조직의 서비스 수준 계약이 고가용성 솔루션에 대한 RTO(복구 시간 목표)를 지정하는 경우에 매우 유용합니다. 간접 검사점에 대한 자세한 내용은 간접 검사점을 참조하세요.

신뢰할 수 있는 건강 모니터링 및 유연한 장애 극복 정책

FCI가 성공적으로 시작되면 WSFC 서비스는 기본 WSFC 클러스터의 상태와 SQL Server 인스턴스의 상태를 모두 모니터링합니다. MicrosoftSQL Server 2012부터 WSFC 서비스는 전용 연결을 사용하여 시스템 저장 프로시저를 통해 활성 SQL Server 인스턴스에서 자세한 구성 요소 진단을 폴링합니다. 이 의미에는 세 가지 결과가 있습니다.

• SQL Server 인스턴스에 대한 전용 연결을 사용하면 FCI가 부하가 많은 경우에도 항상 구성 요소 진단을 안정적으로 폴링할 수 있습니다. 이렇게 하면 부하가 많은 시스템과 실제로 오류 조건이 있는 시스템을 구분하여 잘못된 장애 조치(failover)와 같은 문제를 방지할 수 있습니다.

• 자세한 구성 요소 진단을 사용하면 보다 유연한 장애 조치(failover) 정책을 구성할 수 있으므로 장애 조치(failover)를 트리거하는 오류 조건과 그렇지 않은 오류 조건을 선택할 수 있습니다.

• 또한 상세한 구성 요소 진단은 자동 장애 조치 문제를 소급하여 더욱 효율적으로 해결하는 데 도움을 줍니다. 진단 정보는 SQL Server 오류 로그와 함께 배치되는 로그 파일에 저장됩니다. 로그 파일 뷰어에 로드하여 장애 조치(failover) 발생으로 이어지는 구성 요소 상태를 검사하여 장애 조치(failover)의 원인을 확인할 수 있습니다.

자세한 내용은 장애 조치(failover) 클러스터 인스턴스에 대한 장애 조치(failover) 정책을 참조하세요.

장애 조치(failover) 클러스터 인스턴스의 요소

FCI는 운영 체제 버전 및 패치 수준 및 SQL Server 버전, 패치 수준, 구성 요소 및 인스턴스 이름을 포함하는 동일한 소프트웨어 구성뿐만 아니라 유사한 하드웨어 구성을 포함하는 물리적 서버(노드) 집합으로 구성됩니다. FCI가 노드 간에 장애 조치될 때 FCI가 완벽하게 작동할 수 있도록 하려면 동일한 소프트웨어 구성이 필요합니다.

WSFC 리소스 그룹
SQL Server FCI는 WSFC 리소스 그룹에서 실행됩니다. 리소스 그룹의 각 노드는 장애 조치(failover) 후 FCI의 전체 기능을 보장하기 위해 구성 설정 및 체크 뾰족한 레지스트리 키의 동기화된 복사본을 유지 관리하며 클러스터의 노드 중 하나만 한 번에 리소스 그룹(활성 노드)을 소유합니다. WSFC 서비스는 서버 클러스터, 쿼럼 구성, 장애조치 정책 및 장애조치 운영을 관리하며, 또한 FCI에 대한 VNN 및 가상 IP 주소를 설정합니다. 오류(하드웨어 오류, 운영 체제 오류, 애플리케이션 또는 서비스 오류) 또는 계획된 업그레이드의 경우 리소스 그룹 소유권은 FCI의 다른 노드로 이동됩니다. WSFC 리소스 그룹에서 지원되는 노드 수는 SQL Server 버전에 따라 달라집니다. 또한 동일한 WSFC 클러스터는 CPU, 메모리 및 디스크 수와 같은 하드웨어 용량에 따라 여러 FCI(여러 리소스 그룹)를 실행할 수 있습니다.

SQL Server 이진 파일
제품 이진 파일은 SQL Server 독립 실행형 설치와 유사한 프로세스인 FCI의 각 노드에 로컬로 설치됩니다. 그러나 시작하는 동안 서비스는 자동으로 시작되지 않고 WSFC에서 관리됩니다.

스토리지
Always On 가용성 그룹과 달리 FCI는 데이터베이스 및 로그 스토리지에 대해 FCI의 모든 노드 간에 공유 스토리지를 사용해야 합니다. 공유 스토리지는 WSFC 클러스터 디스크, SAN의 디스크 또는 SMB의 파일 공유 형식일 수 있습니다. 이렇게 하면 장애 조치(failover)가 발생할 때마다 FCI의 모든 노드에서 인스턴스 데이터의 보기가 동일합니다. 그러나 이는 공유 스토리지가 단일 실패 지점이 될 가능성이 있으며 FCI는 데이터 보호를 보장하기 위해 기본 스토리지 솔루션에 의존한다는 것을 의미합니다.

네트워크 이름
FCI용 VNN은 FCI에 대한 통합 연결 지점을 제공합니다. 이렇게 하면 애플리케이션이 현재 활성 노드를 알 필요 없이 VNN에 연결할 수 있습니다. 장애 조치(failover)가 발생하면 VNN이 시작된 후 새 활성 노드에 등록됩니다. 이 프로세스는 SQL Server에 연결하는 클라이언트 또는 애플리케이션에 투명하며, 이렇게 하면 오류 발생 시 애플리케이션 또는 클라이언트가 발생하는 가동 중지 시간을 최소화할 수 있습니다.

가상 IP
다중 서브넷 FCI의 경우 가상 IP 주소가 FCI의 각 서브넷에 할당됩니다. 장애 조치(failover) 중에 DNS 서버의 VNN이 해당 서브넷의 가상 IP 주소를 가리키도록 업데이트됩니다. 애플리케이션과 클라이언트는 다중 서브넷 장애 조치(failover) 후 동일한 VNN을 사용하여 FCI에 연결할 수 있습니다.

SQL Server 장애 조치(failover) 개념 및 작업

관련 항목