SQL Server 장애 조치 클러스터: DBA를 위한 완벽 가이드 [2026]

SQL Server 장애 조치 클러스터는 고가용성 솔루션 유지하는 것 SQL Server 서버에 장애가 발생하더라도 인스턴스는 계속 작동합니다. 이는 동일한 인스턴스를 여러 물리적 서버(노드라고 함)에서 실행함으로써 가능해집니다. 따라서 하나의 서버에 장애가 발생하면 다른 서버가 자동으로 인계받아 클라이언트 측에서 수동 개입이나 변경 없이 작동합니다.

1.2 주요 구성 요소 및 아키텍처

A SQL Server 장애 조치 클러스터 인스턴스는 각각 고유한 역할을 수행하는 다섯 가지 핵심 구성 요소로 구성됩니다. 이 구성 요소들은 함께 하나의 논리적 단위를 형성하며, 클라이언트는 이를 마치 하나의 서버처럼 상호 작용합니다.

노드 : 클러스터에 참여하는 물리적 서버들입니다. 특정 시점에는 정확히 하나의 노드만 활성화되어 실행됩니다. SQL Server 예를 들어, 나머지 노드들은 대기하면서 활성 노드의 상태를 모니터링합니다.
공유 저장소: SAN, iSCSI, Storage Spaces Direct 또는 SMB 파일 공유와 같은 스토리지 볼륨은 모든 노드에서 동시에 액세스할 수 있습니다. 모든 노드가 동일한 스토리지에서 읽고 쓰기 때문에 노드 간 데이터 복제가 필요하지 않으며, 어떤 노드가 인계받더라도 동일한 데이터베이스 파일을 즉시 사용할 수 있습니다.
가상 네트워크 이름 및 가상 IP 주소: 클라이언트가 현재 활성화된 물리적 노드와 관계없이 항상 연결하는 안정적인 ID입니다. 장애 조치가 발생하면 가상 네트워크 이름과 IP 주소가 새 활성 노드에 다시 등록되어 애플리케이션에 전환이 투명하게 이루어집니다.
Windows Server 장애 조치 클러스터링(WSFC): 모든 것을 하나로 묶어주는 기반 플랫폼인 WSFC는 하트비트 네트워크를 통해 노드 및 리소스 상태를 지속적으로 모니터링하고, 리소스 그룹 소유권을 관리하며, 장애가 감지되면 페일오버 프로세스를 오케스트레이션합니다.
정족수: WSFC 내의 투표 메커니즘은 스플릿 브레인 상황을 방지합니다. 각 노드는 클러스터 상태에 대한 투표권을 행사하며, 노드 수가 짝수인 클러스터의 경우 감시 디스크 또는 파일 공유가 추가 투표권을 제공합니다. 클러스터는 과반수 투표가 확보된 경우에만 온라인 상태를 유지하므로, 서로 격리된 두 노드 그룹이 동시에 클러스터 소유권을 주장하는 것을 방지합니다. SQL Server 예.

이러한 구성 요소들은 명확한 계층 구조로 작동합니다.rarchy: WSFC는 노드를 관리하고 쿼럼을 유지하며, 노드들은 동일한 스토리지에 대한 접근 권한을 공유하고, 가상 네트워크 이름은 클라이언트에게 모든 노드에 걸쳐 일관된 연결 지점을 제공합니다. 노드에 장애가 발생하면 WSFC는 하트비트 손실을 감지하고 쿼럼이 여전히 유지되는지 확인한 후, 가상 네트워크 이름, 가상 IP, 스토리지 등을 포함한 리소스 그룹 소유권을 대기 노드로 이전하고 모든 노드를 복구합니다. SQL Server 다시 온라인 상태가 됩니다. 전체 과정은 자동으로 진행되며 클라이언트 측에서 아무런 변경도 필요하지 않습니다.

1.3 FCI와 상시 가동 가용성 그룹 비교

SQL Server WSFC 기반의 Always On 기술 두 가지를 제공합니다. 주요 차이점은 다음과 같습니다.

장애 조치 클러스터 인스턴스(FCI): 인스턴스 수준의 고가용성(HA)을 제공합니다. 모든 데이터베이스가 동시에 장애 조치를 수행합니다. 공유 스토리지가 필요합니다. 노드 간 데이터 복제는 지원하지 않습니다. 재해 복구(DR) 기능이 내장되어 있지 않습니다.
상시 가동 가능 그룹(AG): 데이터베이스 수준의 고가용성. 로그 기반 복제를 통해 보조 복제본을 생성합니다. 공유 스토리지가 필요하지 않습니다. 고가용성(HA) 및 재해 복구(DR)를 모두 지원합니다.

기존 공유 스토리지를 사용하는 경우 인스턴스 수준의 장애 조치를 위해 FCI를 사용하십시오. 재해 복구 또는 읽기 가능한 보조 스토리지가 필요한 경우 FCI를 AG와 결합하십시오.

1.4 이점 및 제한 사항

이점:

하드웨어, 운영 체제 또는 서비스 장애 발생 시 자동 페일오버 기능 제공;
클라이언트 재구성 없음;
간접 체크포인트를 통한 예측 가능한 페일오버 시간;
유연한 공유 스토리지 옵션.

제한 사항 :

공유 스토리지는 스토리지 자체에 이중화가 되어 있지 않으면 단일 장애 지점이 됩니다.
하나의 노드만 실행됩니다. SQL Server 한 번에 모두 읽기 작업을 수행하므로 읽기 로드 밸런싱이 적용되지 않습니다.
AG와 페어링하지 않으면 내장된 DR 기능이 없습니다.

2. 필수 조건 및 요건

2.1 하드웨어 및 소프트웨어

동일하거나 동등한 하드웨어, 64비트 프로세서 및 장애 조치 클러스터링 인증을 받은 스토리지 컨트롤러를 갖춘 최소 2대의 물리적 서버가 필요합니다.
Windows Server 2016, 2019 또는 2022(Standard 또는 Datacenter)가 필요합니다. 모든 노드는 동일한 OS 에디션, 버전 및 누적 업데이트 수준을 실행해야 합니다.
SQL Server 스탠다드 또는 엔터프라이즈 에디션. 모든 노드는 동일한 버전을 실행해야 합니다. SQL Server 버전 및 패치 레벨.

2.2 네트워크 및 도메인 요구 사항

모든 노드는 동일한 Active Directory 도메인에 속해야 합니다. 워크그룹 클러스터, 다중 도메인 클러스터 및 읽기 전용 도메인 컨트롤러는 지원되지 않습니다.
모든 네트워크 어댑터에 고정 IP 주소를 할당하십시오. 클러스터 하트비트 트래픽을 위해 노드당 최소 하나의 네트워크 인터페이스 카드(NIC)를 전용으로 사용하십시오. 이름 확인을 위해 DNS(도메인 이름 시스템)를 구성하십시오.
설치 계정에는 모든 노드에 대한 로컬 관리자 권한이 필요합니다. 컴퓨터 객체 생성 Active Directory의 권한.

2.3 공유 스토리지 옵션

SQL Server 장애 조치 클러스터링은 여러 공유 스토리지 기술을 지원합니다. 인프라 및 예산에 가장 적합한 기술을 선택하십시오.

SAN(파이버 채널 또는 iSCSI): Most 공통 사항입니다. 모든 노드는 동일한 논리 장치 번호(LUN)에 액세스해야 합니다. 단일 경로 오류를 방지하려면 다중 경로 I/O(MPIO)를 사용하십시오.
스토리지 스페이스 다이렉트(S2D): 로컬에 연결된 NVMe 또는 SSD가 노드 간에 풀링됩니다. Windows Server 2016 Datacenter 이상이 필요합니다.
서버 메시지 블록(SMB) 파일 공유 및 클러스터 공유 볼륨(CSV): 지원됨 SQL Server 2014년 이후.

클러스터의 모든 디스크를 기본 NT 파일 시스템으로 포맷합니다(NTFS클러스터 노드에 마운트된 볼륨을 사용하지 마십시오.

3. 클러스터 계획 수립

설치 전에 노드 구성 유형과 쿼럼 설정을 계획해야 합니다. 이는 클러스터 안정성과 하드웨어 호환성에 직접적인 영향을 미칩니다.ost:

3.1 구성 유형

SQL Server 장애 조치 클러스터는 네 가지 유형의 노드 구성을 지원하며, 각 유형은 단순성, 하드웨어 호환성 등에서 장단점을 가집니다.ost그리고 대기 용량은 서로 다릅니다.

유형 1: 활성/대기. 1개의 FCI, 2개의 노드. 노드 1은 활성 노드이고, 노드 2는 대기 노드입니다. 대기 노드는 활성 노드의 하트비트를 지속적으로 모니터링하고 활성 노드에 장애가 발생하면 FCI를 인계받습니다. 이것이 가장 간단한 구성입니다.ost 생산 과정에서 흔히 볼 수 있습니다.
유형 2: 액티브/액티브. 2개의 FCI가 2개의 물리적 노드를 공유합니다. 노드 1은 FCI 1의 활성 노드이자 FCI 2의 대기 노드이며, 노드 2는 FCI 2의 활성 노드이자 FCI 1의 대기 노드입니다. 두 노드는 상호 대기 노드로서, 정상 작동 시 모두 활성 워크로드를 처리합니다. 어느 한 노드에 장애가 발생하면, 나머지 노드가 장애가 발생한 노드의 FCI를 인계받아 자체 FCI를 계속 실행합니다. 따라서 각 노드는 두 FCI의 총 워크로드를 처리할 수 있도록 충분한 용량으로 설계되어야 합니다.
유형 3: N+1. N개의 FCI가 N+1개의 노드를 공유합니다. 각 FCI는 하나의 활성 노드를 가지며, 모든 N개의 FCI는 하나의 공통 대기 노드를 공유합니다. 공유 대기 노드는 활성 노드 중 하나라도 장애가 발생하면 그 부하를 독립적으로 감당할 수 있어야 합니다.
유형 4: N+M. N개의 FCI가 N+M개의 노드를 공유합니다. 각 FCI는 하나의 활성 노드를 가지며, 모든 N개의 FCI는 M개의 대기 노드를 공유합니다. M개의 대기 노드는 모든 N개의 활성 노드에 대한 장애 조치를 담당하여 잠재적 부하를 더 많은 대기 용량에 분산시키고, N+1 구성에 비해 노드당 하드웨어 요구 사항을 줄입니다.

3.2 정족수 지침

쿼럼은 클러스터가 온라인 상태를 유지하는 데 필요한 충분한 정상 구성원이 있는지 여부를 결정합니다. 쿼럼을 설정하고 유지 관리할 때 다음 지침을 염두에 두십시오.

분할된 상황에서 과반수 확보를 보장하고 스플릿 브레인을 방지하기 위해 정족수 투표의 총 개수를 홀수로 설정하십시오.
2노드 클러스터의 경우 다음을 사용하십시오. 노드 및 디스크 다수 세 번째 투표로 증거 디스크를 사용합니다. 증거 디스크에는 드라이브 문자가 필요하지 않습니다.
정족수가 l이면ost 완전히 차단하고, 최후의 수단으로 쿼럼을 강제로 확보하여 살아남은 노드를 복구한 다음, 프로덕션 환경으로 복귀하기 직전에 즉시 재구성합니다.

4. Windows Server 장애 조치 클러스터(WSFC) 설치

4.1 공유 스토리지 준비

클러스터를 생성하기 전에 모든 공유 스토리지를 연결하고 구성하십시오.

모든 스토리지 LUN을 클러스터의 모든 노드에 물리적으로 연결하거나 프로비저닝하십시오.
에 첫 번째 노드만, 열다 디스크 관리각 디스크를 온라인 상태로 만들고, 초기화하고, 생성합니다. NTFS 드라이브 문자가 있는 볼륨을 생성합니다. 증거 디스크용으로 작은 볼륨(1~2GB)을 생성하며, 드라이브 문자는 필요하지 않습니다.
나머지 각 노드에서 열기 디스크 관리 디스크를 온라인 상태로만 전환하십시오. 재초기화 또는 재포맷은 하지 마십시오. 첫 번째 노드와 드라이브 문자가 일치하지 않으면 수동으로 드라이브 문자를 할당하십시오.

4.2 장애 조치 클러스터링 기능 설치 및 유효성 검사

클러스터를 생성하기 전에 모든 노드에 장애 조치 클러스터링 기능을 설치하고 유효성을 검사하십시오.

각 노드에서 열기 서버 관리자 -> 역할 및 기능 추가 -> 기능, 고르다 장애 조치 클러스터링그리고 클릭 설치메시지가 표시되면 재부팅하십시오. PowerShell을 사용하는 방법:
```
Install-WindowsFeature -Name Failover-Clustering -IncludeManagementTools
```
어느 노드에서든 열기 장애 조치 클러스터 관리자 -> 구성 유효성 검사모든 노드 h를 추가합니다.ost이름을 지정하고 모든 테스트를 실행합니다. PowerShell 대안:
```
Test-Cluster -Node Node1, Node2
```
진행하기 전에 유효성 검사 보고서의 모든 오류를 해결하십시오. Storage Spaces Direct를 사용하지 않는 경우 Storage Spaces Direct 경고는 무시해도 됩니다.

4.3 WSFC 생성

검증이 완료되면 클러스터를 생성하고 구성을 확인합니다.

In 장애 조치 클러스터 관리자클릭 클러스터 생성모든 노드 h를 추가합니다.ost이름을 지정하려면 클러스터 이름과 고정 가상 IP 주소를 입력한 다음 클릭하세요. 다음PowerShell 대안:
```
New-Cluster -Name ClusterName -Node Node1, Node2 -StaticAddress x.x.x.x
```
도메인 권한이 제한된 경우, 이 단계를 실행하기 전에 Active Directory 관리자에게 클러스터 이름 컴퓨터 개체를 미리 준비해 달라고 요청하십시오.
생성 후, 정족수가 충족되었는지 확인하십시오. 노드 및 디스크 다수 증인 디스크가 할당되었습니다.
$XNUMX Million 미만 스토리지 -> 디스크각 클러스터 디스크의 이름을 해당 역할에 맞게 변경합니다(예: SQL_DATA, SQL_LOG, 증거). 아래에 Networks각 클러스터 네트워크의 이름을 트래픽 유형을 반영하도록 변경하십시오.

5. 설치 SQL Server 장애 조치 클러스터 인스턴스

5.1 설치 방법 선택

SQL Server 설치 프로그램은 장애 조치 클러스터 인스턴스를 설치하는 두 가지 방법을 제공합니다. 사용 환경에 맞는 방법을 선택하십시오.

통합 설치(노드 추가): 첫 번째 노드에 완전하고 작동 가능한 FCI를 설치한 다음, 각 후속 노드를 다음 방법을 사용하여 추가하십시오. 노드 추가 옵션. 더 간단하고 m에게 추천합니다.ost 배포.
고급/엔터프라이즈 설치: 달리기 장애 조치 클러스터 준비 먼저 모든 노드에서 작업을 수행한 다음 실행하세요. 완전 장애 조치 클러스터 공유 디스크를 소유한 노드에서 이 작업을 수행합니다. 이 방법은 모든 노드를 병렬로 준비한 후 배포하려는 대규모 멀티 노드 롤아웃에 사용합니다.

5.2 첫 번째 노드 설치

달리기 SQL Server 통합 방식을 사용하여 FCI를 생성하기 위해 첫 번째 노드에서 설정을 진행합니다.

달리기 SETUP.EXE 관리자 권한으로 선택하세요. 설치 -> New SQL Server 장애 조치 클러스터 설치.
On 기능 선택선택한다. 데이터베이스 엔진 서비스 관리 도구 - 기본 사항.
On 인스턴스 구성, 들어가다 SQL Server 네트워크 이름 — 클라이언트가 연결할 때 사용하는 가상 이름입니다.
On 클러스터 리소스 그룹설명적인 그룹 이름을 입력하세요.
On 클러스터 디스크 선택데이터, 로그 및 백업 파일에 사용할 공유 디스크를 선택하십시오.
On 클러스터 네트워크 구성서브넷별로 IP 주소를 할당합니다. 설정 과정에서 다중 서브넷 클러스터에 대한 OR 종속성이 자동으로 설정됩니다.
On 서버 구성서비스 계정을 설정하십시오. 자동화된 암호 관리를 위해 그룹 관리 서비스 계정(gMSA)을 사용하고, 백업용으로 도메인 계정을 사용하십시오.
On 데이터베이스 엔진 구성인증 모드를 선택하고 데이터 디렉터리 경로를 설정하십시오. 시스템 데이터베이스, 사용자 데이터베이스, 로그, 백업 및 TempDB는 각각 별도의 디스크에 배치하십시오.
요약을 검토하고 클릭하세요 설치.

5.3 나머지 노드 추가

첫 번째 노드가 완료되면 추가 노드를 FCI에 추가합니다.

추가 노드에서 실행하세요. SETUP.EXE 선택 설치 -> 노드를 추가하세요 SQL Server 장애 조치 클러스터.
On 클러스터 노드 구성기존 FCI 인스턴스를 선택합니다.
On 클러스터 네트워크 구성이 노드의 서브넷에 IP 주소를 할당합니다.
On 서비스 계정서비스 계정 암호가 첫 번째 노드에 설정된 암호와 일치하는지 확인한 다음 클릭하십시오. 설치.
각 노드가 추가될 때마다 이 과정을 반복합니다.

6 Post-설치: 구성 및 테스트

6.1 필수 SQL Server 설정

FCI가 작동된 직후 이러한 설정을 적용하십시오.

세트 최대 서버 메모리 캡으로 SQL Server메모리를 확보하고 운영 체제 및 클러스터 서비스를 위한 여유 공간을 남겨둡니다.
```
EXEC sp_configure 'show advanced options', 1; RECONFIGURE;
EXEC sp_configure 'max server memory', <value_in_MB>; RECONFIGURE;
```
세트 최대 병렬 처리 정도(MAXDOP) 귀사의 NUMA(비균일 메모리 접근) 토폴로지에 따라 다릅니다.

TempDB를 별도의 볼륨으로 이동하여 I/O를 격리하십시오.

USE master;
ALTER DATABASE tempdb MODIFY FILE (NAME = tempdev, FILENAME = 'D:\TempDB\tempdb.mdf');
ALTER DATABASE tempdb MODIFY FILE (NAME = templog, FILENAME = 'D:\TempDB\templog.ldf');

해상도tart SQL Server 파일 이동이 적용되려면 서비스가 필요합니다.

6.2 테스트 페일오버

클러스터를 프로덕션 환경으로 이전하기 전에 장애 조치 동작을 검증하십시오.

In 장애 조치 클러스터 관리자을 마우스 오른쪽 버튼으로 클릭하고 SQL Server FCI 역할 및 선택 무브 -> 노드 선택보조 노드를 선택하고 클릭하세요. OK.
역할 상태가 표시될 때까지 기다리세요 달리는 새 노드에서.
클라이언트 컴퓨터에서 연결하세요. SQL Server 가상 네트워크 이름을 사용하여 연결 문자열을 변경하지 않고 연결이 성공하는지 확인합니다.
검토 SQL Server 오류 로그 및 Windows 클러스터 이벤트 로그를 확인하여 장애 조치가 정상적으로 수행되었는지 확인하십시오. tar복구 시간 목표(RTO)를 구하세요.

7. 관리, 모범 사례 및 문제 해결

7.1 장애 조치 정책 및 모니터링

In 장애 조치 클러스터 관리자을 마우스 오른쪽 버튼으로 클릭하고 SQL Server FCI 역할 -> 등록 -> 장애 조치 장애 조건 수준과 상태 확인 시간 초과를 설정합니다. 부하가 심한 서버에서는 시간 초과를 늘려 잘못된 장애 조치를 방지하십시오.
클러스터 상태를 모니터링하세요 장애 조치 클러스터 관리자, Windows 이벤트 뷰어 밸리 SQL Server 오류 로그 및 SQL Server 활동 모니터 실시간 리소스 및 세션 가시성을 제공합니다.
자동 장애 조치 후에는 다음 사항을 검토하십시오. SQL Server 진단하다ost이벤트 발생 전까지의 구성 요소 상태에 대한 IC 로그(오류 로그와 함께 저장됨)를 사용합니다. SQL Server 확장 이벤트 장애 조치 시간대를 중심으로 리소스 상태 및 오류 조건에 대한 자세한 추적 정보를 수집합니다.

7.2 가지 모범 사례

모든 노드에 고정 IP를 사용하십시오. 동적 Host 장애 조치 중 DHCP 임대 만료는 다운타임을 연장하고 DNS 등록을 복잡하게 만듭니다.
정족수 투표 수는 항상 홀수로 유지하십시오. 노드를 추가하여 투표 수가 짝수가 되면 증인 노드를 추가하십시오.
하드웨어 변경, 드라이버 업데이트 또는 중요한 운영 체제 구성 변경 후에는 클러스터 유효성 검사를 실행하십시오.
모든 노드에 동일한 드라이브 문자를 할당하기 전에 SQL Server 설치 과정에서 발생하는 불일치는 설치를 차단하며, 이후에도 수정하기 어렵습니다.
설치일 전에 Active Directory 관리자와 상의하십시오. 컴퓨터 개체 생성 권한은 필수 사항입니다.ost 일반적인 사전 설치 차단 요인.
테스트를 거친 상태를 유지하세요 SQL Server 백업 FCI가 있더라도 이러한 전략은 효과적이지 않습니다. FCI는 노드 장애로부터 데이터를 보호하지만, 데이터 손상, 실수로 인한 삭제 또는 스토리지 수준 손실로부터는 보호하지 못합니다. 이러한 상황을 방지하기 위한 유일한 안전장치는 정기적인 백업 및 복원 일정입니다.

7.3 일반적인 문제 및 수정 사항

Active Directory 권한 오류: Active Directory(AD) 관리자에게 클러스터 컴퓨터 개체를 미리 준비하도록 요청하거나 권한을 부여하십시오. 컴퓨터 객체 생성 모든 속성 읽기 설치 계정으로 이동합니다.
노드에서 공유 스토리지가 보이지 않습니다. 해상도tart iSCSI를 Tar서버 가져오기 스토리지 h에 대한 서비스ost그런 다음 각 노드의 iSCSI 이니시에이터에서 다시 연결합니다. LUN 마스킹 및 영역 설정을 확인합니다.
드라이버 또는 업데이트 수준에 대한 유효성 검사 경고: 최신 누적 업데이트를 적용하세요. Windows Update를 유효성 검사를 다시 실행하기 전에 모든 노드에서 이 작업을 수행하십시오.
노드 장애 발생 후 WSFC가 오프라인 상태가 되었습니다. 강제 쿼럼 기능을 사용하여 남아있는 노드들을 온라인 상태로 만드세요. 데이터베이스를 복구하세요 장애의 영향을 받은 부분을 복구하고, 쿼럼을 복원한 다음, 프로덕션 환경으로 복귀하기 전에 재구성하십시오. 실행 DBCC 체크DB 정상적인 작업 부하를 재개하기 전에 복구된 각 데이터베이스의 무결성을 확인합니다.
잘못된 자동 장애 조치: FCI 역할 속성에서 상태 점검 시간 제한을 늘리십시오. 진단을 검토하십시오.ostIC 로그를 사용하여 실제 장애와 일시적인 리소스 사용량 급증을 구분합니다.

8. FAQ

질문: 특정 기능을 구현하는 데 필요한 최소 노드 수는 몇 개입니까? SQL Server 장애 조치 클러스터?

A: 최소 두 개의 노드가 필요합니다. 하나는 활성 노드 역할을 하며 프로그램을 실행합니다. SQL Server 인스턴스입니다. 다른 하나는 대기 상태입니다. Most 프로덕션 배포 start는 2노드 액티브/패시브 구성입니다.

Q : 않습니다 SQL Server FCI는 공유 스토리지가 필요합니까?

A: 네. Always On 가용성 그룹과 달리 FCI는 모든 노드가 동일한 스토리지(SAN(파이버 채널 또는 iSCSI), Storage Spaces Direct 또는 SMB 파일 공유)에 액세스해야 합니다. 공유 스토리지를 통해 장애 조치 후에도 모든 노드에서 동일한 데이터베이스 파일에 액세스할 수 있습니다.

Q : 무엇 SQL Server 해당 에디션들이 페일오버 클러스터링을 지원하나요?

A: SQL Server Standard 및 Enterprise 에디션은 FCI를 지원합니다. Express 및 Developer 에디션은 지원하지 않습니다. Enterprise 에디션은 더 많은 노드를 지원하며 유지 관리 중 온라인 인덱스 작업과 같은 추가적인 고가용성 기능을 제공합니다.

Q : 할 수 있습니다 SQL Server FCI와 Always On Availability Group을 함께 사용할 수 있습니까?

A: 네. FCI 노드는 h를 할 수 있습니다.ost 가용성 그룹 복제본을 사용하면 FCI에서 인스턴스 수준의 고가용성(HA)을, 가용성 그룹에서 데이터베이스 수준의 재해 복구(DR)를 모두 제공받을 수 있습니다. 하지만 가용성 그룹의 자동 페일오버는 FCI-h에서 또는 FCI-h로의 페일오버에는 적용되지 않습니다.osted 복제본은 지원되지 않습니다. 해당 구성에서는 수동 페일오버만 가능합니다.

Q: 얼마나 오래 걸리나요? SQL Server 장애 조치에는 일반적으로 몇 시간이 걸립니까?

A: 장애 조치 시간은 인스턴스가 복구되기 전에 디스크에 기록해야 하는 버퍼 캐시의 변경된 페이지 수에 따라 달라집니다.tar새 노드에서 ts를 실행합니다. 간접 체크포인트가 활성화된 경우(기본값) SQL Server 2012년 이후), 더러운 페이지는 테두리로 둘러싸여 있습니다.ost 장애 조치는 30초 이내에 완료됩니다. 실제 RTO는 워크로드, 스토리지 속도 및 데이터베이스 복구 시간에 따라 달라집니다.

질문: 정족수란 무엇이며, 왜 중요한가요?

A: 쿼럼은 WSFC가 클러스터에 요청을 처리하고 온라인 상태를 유지할 수 있을 만큼 충분한 정상 멤버가 있는지 판단하는 데 사용하는 메커니즘입니다. 이는 서로 격리된 두 노드 그룹이 각각 자신이 클러스터의 권한 있는 소유자라고 믿는 스플릿 브레인 상황을 방지합니다. SQL Server 예를 들어, 정족수가 l인 경우ostWSFC는 데이터 무결성을 보호하기 위해 클러스터를 오프라인으로 전환합니다.

Q : 할 수 있습니다 SQL Server FCI를 Active Directory가 없는 워크그룹 클러스터에 설치할 수 있습니까?

A : 아닙니다. SQL Server FCI를 사용하려면 모든 노드가 동일한 Active Directory 도메인의 구성원이어야 합니다. 워크그룹 클러스터, 다중 도메인 클러스터 및 읽기 전용 도메인 컨트롤러가 포함된 클러스터는 지원되지 않는 구성입니다.

질문: 장애 조치가 발생하면 클라이언트 연결에는 어떤 일이 발생합니까?

A: 활성 연결 SQL Server 장애 조치 중에 인스턴스가 삭제됩니다. 인스턴스가 새 노드에서 온라인 상태가 되면 가상 네트워크 이름과 가상 IP가 다시 등록되고, 연결 문자열에 재시도 로직을 사용하는 클라이언트는 구성 변경 없이 자동으로 다시 연결됩니다.

질문: 기존 노드에 노드를 추가하거나 제거할 수 있나요? SQL Server 장애 조치 클러스터?

A: 네. 달리세요. SQL Server 아무 노드에나 설정하고 선택하세요 노드를 추가하세요 SQL Server 장애 조치 클러스터 노드를 추가하려면, 또는 노드를 제거합니다 SQL Server 장애 조치 클러스터 노드를 추가하거나 제거하는 것은 클러스터의 다른 노드에 대한 다운타임을 필요로 하지 않습니다.

질문: 계획된 페일오버와 자동 페일오버의 차이점은 무엇입니까?

A: 계획된 장애 조치는 관리자가 수동으로 시작하며, 일반적으로 패치 적용이나 하드웨어 교체와 같은 유지 보수 작업을 위해 수행됩니다. 이를 통해 다음과 같은 이점을 얻을 수 있습니다. SQL Server 더티 페이지를 플러시하고 소유권을 이전하기 전에 깔끔하게 종료하여 다운타임을 최소화합니다. WSFC는 상태 모니터링에서 활성 노드에 장애가 발생했음을 감지하면 자동 페일오버를 트리거하며, 복구 시간은 필요한 크래시 복구 정도에 따라 달라집니다.

질문: 어떻게 복구하나요? SQL Server WSFC 전체가 오프라인 상태가 될 경우 장애 조치 클러스터를 구성할 수 있을까요?

A: 정족수가 l이면ost 그리고 클러스터는 할 수 없습니다tar일반적으로, 강제 쿼럼을 사용하여 장애 허용 상태가 아닌 상태로 생존 노드를 온라인 상태로 전환합니다. 생존 노드에서 다음 PowerShell 명령을 실행하십시오. Start-ClusterNode -ForcQuorum클러스터가 온라인 상태가 되면 데이터베이스를 복구하고 데이터 무결성을 확인한 다음, 나머지 노드와 함께 쿼럼을 재구성한 후 프로덕션 환경으로 복귀하십시오.

질문: 매번 클러스터 유효성 검사 마법사를 실행해야 하나요? SQL Server 설치?

A: 네, 그리고 중요한 하드웨어 또는 구성 변경 후에도 마찬가지입니다. Microsoft는 모든 유효성 검사 테스트를 오류 없이 통과한 장애 조치 클러스터 구성만 지원합니다. 유효성 검사를 건너뛰면 지원되지 않는 구성이 실행되어 장애 발생 시 예측할 수 없는 동작을 할 위험이 있습니다.

9. 결론

SQL Server 장애 조치 클러스터링(FCI)은 WSFC를 통해 투명한 인스턴스 수준의 고가용성을 제공하며, 자동 장애 조치가 가능하고 클라이언트 재구성이 필요하지 않습니다. 공유 스토리지를 사용할 수 있고 인스턴스의 모든 데이터베이스가 하나의 단위로 함께 장애 조치되어야 하는 경우에 적합한 선택입니다. 재해 복구 또는 보조 읽기 워크로드가 필요한 환경에서는 FCI를 Always On 가용성 그룹과 함께 사용하여 두 가지 시나리오를 모두 지원할 수 있습니다.

참고자료

마이크로소프트 공식 문서: Windows Server 장애 조치 클러스터 SQL Server
마이크로소프트 공식 문서: 상시 가동 장애 조치 클러스터 인스턴스
마이크로소프트 공식 문서: 장애 조치 클러스터 인스턴스 설치
마이크로소프트 공식 문서: WSFC 정족수 모드 및 투표 구성

저자에 관하여

위안 셩 10년 이상의 경력을 가진 선임 데이터베이스 관리자(DBA)입니다. SQL Server 환경 및 기업 데이터베이스 관리 분야에서 그는 금융 서비스, 의료, 제조 분야에서 수백 건의 데이터베이스 복구 시나리오를 성공적으로 해결했습니다.

원은 다음을 전문으로 합니다. SQL Server 데이터베이스 복구, 고가용성 솔루션, 성능 최적화 분야의 전문가입니다. 그는 수 테라바이트 규모의 데이터베이스 관리, Always On Availability Groups 구현, 미션 크리티컬 비즈니스 시스템을 위한 자동 백업 및 복구 전략 개발 등 풍부한 실무 경험을 보유하고 있습니다.

Yuan은 기술적 전문성과 실용적인 접근 방식을 통해 데이터베이스 관리자와 IT 전문가가 복잡한 문제를 해결하는 데 도움이 되는 포괄적인 가이드를 만드는 데 중점을 둡니다. SQL Server 효율적으로 도전합니다. 그는 최신 정보를 유지합니다. SQL Server Microsoft의 새로운 릴리스와 진화하는 데이터베이스 기술을 활용하고, 정기적으로 복구 시나리오를 테스트하여 권장 사항이 실제 모범 사례를 반영하는지 확인합니다.

에 대한 질문이 SQL Server 복구가 필요하거나 추가적인 데이터베이스 문제 해결 지침이 필요하신가요? Yuan이 환영합니다. 피드백과 제안 이러한 기술적 자원을 개선하기 위해.