Windows Server 2025 / 장애 조치 클러스터의 역할과 구축 전 확인할 조건
장애 조치 클러스터는 여러 서버 노드가 서비스 상태를 감시하고 장애 시 지원되는 역할을 다른 노드에서 실행하도록 구성하는 기능입니다. 서버 두 대를 준비하는 것만으로 완성되지 않으며, 응용 프로그램 지원·저장소·네트워크·쿼럼·검증과 복구 목표를 함께 설계해야 합니다.
클러스터가 줄이는 장애와 남는 장애입니다
노드는 클러스터에 참여하는 서버이고, 클러스터 역할은 노드 사이에서 관리되는 서비스나 VM 등의 자원 묶음입니다. 노드 하나가 멈추면 다른 노드에서 역할을 이어받을 수 있지만, 감지·전환·재시작 시간 동안 연결이 끊길 수 있습니다. 클라이언트의 재접속과 앱의 복구 동작도 확인해야 합니다.
고가용성은 백업이나 재해 복구와 목적이 다릅니다. 잘못 삭제한 파일이나 랜섬웨어 변경은 여러 노드가 정상이어도 남을 수 있습니다. 같은 전원·물리 호스트·저장소를 쓰는 두 VM은 그 공통 장애를 함께 겪을 수 있으므로 물리적 장애 영역도 구분합니다.
| 요구 | 주요 설계 |
|---|---|
| 노드 한 대 장애 대응 | 지원되는 클러스터 역할과 전환 |
| 삭제 전 데이터 복구 | 별도 시점 백업·복구 |
| 센터 전체 장애 대응 | 다른 장애 영역의 복제·재해 복구 |
| 웹 요청 분산 | 앱 구조에 맞는 부하 분산·상태 관리 |
일반 IIS 서버 두 대에 장애 조치 기능을 켠다고 자동으로 사이트가 고가용성으로 바뀌지 않습니다. 웹·DB·파일 서버·Hyper-V는 각각 지원되는 배치와 데이터 구조가 다릅니다. 먼저 보호할 역할과 목표 복구 시간(RTO)·허용 데이터 손실(RPO)을 정하세요.
노드와 네트워크 조건을 확인합니다
클러스터 하드웨어 및 저장소 요구 사항에 따라 Windows Server 버전, 장비·드라이버·펌웨어 지원을 확인합니다. 처음 구성하는 예시는 같은 Windows Server 2025의 유사한 노드 두 대를 기준으로 설계합니다. 일반 도메인 구성과 작업 그룹 클러스터 등 다른 배치의 조건을 섞지 않습니다.
- 관리·클러스터 통신·저장소·VM 이동 트래픽의 경로와 대역폭을 정합니다.
- 스위치·NIC·전원·저장소 경로에 단일 장애 지점이 있는지 조사합니다.
- 한 노드가 빠진 상태에도 나머지가 업무를 감당할 CPU·메모리·저장소 여유를 계산합니다.
- 도메인 기반 배치라면 내부 DNS·시각·클러스터 계정 및 이름 등록 권한을 확인합니다.
고정 IP·이름·VLAN·방화벽은 네트워크 담당자와 같은 설계표를 사용합니다. NIC가 여러 개라는 사실만으로 실제 경로가 중복된 것은 아닙니다. 같은 스위치와 케이블 경로로 연결되어 있다면 공통 장애가 남습니다.
역할에 맞는 저장소를 선택합니다
공유 저장소, SMB 기반 저장소, Storage Spaces Direct 같은 선택지는 역할·하드웨어·에디션과 지원 조건에 따라 달라집니다. 각 노드에 같은 이름의 로컬 폴더만 만든다고 같은 데이터를 제공하는 것은 아닙니다. DFS 네임스페이스 역시 데이터 복제나 클러스터 저장소를 자동 제공하지 않습니다.
| 확인 항목 | 검토할 질문 |
|---|---|
| 데이터 접근 | 다른 노드가 같은 최신 데이터를 읽을 수 있는가 |
| 장애 분리 | 노드 장애와 저장소 장애를 각각 견딜 수 있는가 |
| 지원 조건 | 해당 OS·역할·장비·프로토콜 조합이 지원되는가 |
| 성능·용량 | 노드 장애·재동기화 시에도 필요한 부하를 감당하는가 |
| 복구 | 백업 제품과 앱의 일관성·복구 순서가 검증되었는가 |
운영 디스크를 시험용 저장소 검사나 구성 마법사에 바로 넣지 않습니다. 공유 디스크의 소유권·예약·접근 경로와 데이터를 보호한 별도 시험 환경이 필요합니다. 기능·라이선스 요구도 실제 선택한 구조별로 확인하세요.
쿼럼과 감시자는 서비스 데이터를 보관하는 개념이 아닙니다
쿼럼은 통신이 분리된 상황에서 클러스터가 계속 동작할 수 있는 판단 체계입니다. 여러 쪽이 동시에 같은 자원을 소유하려는 상황을 피하는 데 필요합니다. 감시자(witness)는 투표 판단을 돕는 구성 요소이며 업무 데이터 백업이나 제3의 서비스 노드가 아닙니다.
쿼럼 감시자 배포 안내의 디스크·파일 공유·클라우드 감시자 조건을 비교합니다. 노드 수뿐 아니라 배치 위치·네트워크 분리·접근 권한과 외부 통신 가능 여부를 함께 검토하세요. 동적 쿼럼이 있다고 임의의 장애 조합을 모두 견딘다고 생각하면 안 됩니다.
감시자를 두 노드와 같은 장애 영역에 두면 전체 장애를 분리하지 못할 수 있습니다. 반대로 별도 위치에 놓더라도 경로·인증·방화벽이 맞지 않으면 투표에 쓸 수 없습니다. 감시자 종류를 고르기 전에 어떤 장애를 견뎌야 하는지 표로 정리합니다.
검증과 장애 시험을 도입 조건으로 정합니다
- 노드·네트워크·저장소·계정·이름·역할의 설계표를 작성합니다.
- 각 노드의 기능·업데이트·드라이버와 지원 조건을 맞춥니다.
- 클러스터 만들기 전에 구성 유효성 검사를 계획하고 보고서의 실패·경고를 검토합니다.
- 지원되는 역할을 구성한 뒤 계획된 이동과 예기치 않은 장애 상황을 구분해 시험합니다.
- 클라이언트 재접속·데이터 일관성·복구 시간과 경보 전달을 확인합니다.
- 백업 복구와 전체 장애 영역 상실에 대한 별도 절차를 검증합니다.
클러스터 생성 및 유효성 검사 절차를 따라 실제 구축 시 사용할 검사를 정합니다. 저장소 검사 등은 서비스에 영향을 줄 수 있으므로 운영 중 모든 검사를 무작정 실행하지 않습니다. 테스트 보고서는 성공 문구만 보지 말고 각 항목과 경고의 원인·영향·조치를 기록합니다.
이 문서에서는 기존 강좌 서버를 클러스터로 바꾸지 않습니다. 도입 결과물은 대상 역할, 요구 조건, 장애 영역, 예상 중단 시간과 검증 계획입니다. 설치 명령을 수행하기 전에 필요한 자원과 운영 담당자가 확보됐는지 판단할 수 있어야 합니다.
