2025년 10월 24일
SQL Server DB 마이그레이션 전략 (MSCS/WSFC 고가용성) – 클라이언트 접속 VIP 유지
요약
노후 서버를 신규 장비로 교체하면서 SQL Server 고가용성(WSFC/MSCS 기반 FCI) 을 유지·개선하는 마이그레이션 방안입니다.
핵심은 클라이언트 접속 엔드포인트(VNN/VIP)를 그대로 유지하여 애플리케이션 수정 없이 전환하고, 노드의 RIP(Real IP)는 신규 네트워크 정책에 맞게 변경하는 것입니다.
본 글은 운영 표준화에 유리한 스윙(Swing) FCI / Side-by-Side 전략을 기준으로 “절차 + 체크리스트 + 스크립트”까지 한 번에 정리합니다.
0. 용어 정리(이 글에서 쓰는 기준)
- WSFC/MSCS: Windows Server Failover Clustering (전통적으로 MSCS라고도 부름)
- FCI: SQL Server Failover Cluster Instance
(공유 스토리지 기반, “인스턴스 단위” 고가용성) - VNN: Virtual Network Name
(클라이언트가 주로 접속하는 “이름”; DNS/AD 컴퓨터 계정(VCO)과 연결됨) - VIP: Virtual IP
(VNN에 매핑되는 클러스터 IP 리소스; 클라이언트가 바라보는 IP) - RIP: Real IP
(각 노드 서버의 실제 IP — 관리/백업/모니터링/복제 트래픽에 사용) - CNO: Cluster Name Object
(클러스터 자체 컴퓨터 계정) - VCO: Virtual Computer Object
(FCI의 VNN에 해당하는 컴퓨터 계정)
실무 관점 포인트
“VIP만” 유지한다고 해서 항상 앱 변경이 0이 되는 것은 아닙니다.
대부분의 앱은 IP가 아닌 VNN(이름) 으로 접속합니다.
따라서 본 글의 ‘VIP 유지’는 실무적으로 VNN+VIP를 함께 유지하는 것을 기본 전제로 합니다.
1. 목표 아키텍처 한눈에 보기(예시)
[Application / App Servers]
|
| (No change) Connect endpoint
v
VNN: SQLPROD -> VIP: 10.10.10.100 (unchanged)
|
v
[WSFC / SQL Server FCI]
/ \
Node A Node B
RIP: 10.20.20.21 RIP: 10.20.20.22
(Management/Backup/Monitoring network)
Shared Storage / Private (Heartbeat) networks exist as per standard design- VNN/VIP 유지 → 앱/연동 시스템의 연결 문자열 변경 최소화(대부분 “0”에 수렴)
- RIP 변경 → 신규 장비/랙/보안정책(관리망/백업망 분리 등)에 부합
2. 마이그레이션 전략 선택지(비교)
| 전략 | 요약 | 장점 | 고려사항/리스크 |
|---|---|---|---|
| 스윙 FCI(권장) | 신규 클러스터/FCI를 임시 VNN/VIP로 구축 → 데이터 사전 동기화 → 컷오버 때 기존 VNN/VIP 승계 | 절차 표준화, 사전 리허설/롤백 설계 용이, 다운타임 최소화 | AD(VCO/CNO 권한), DNS/SPN, 스토리지/데이터 동기화 설계 필요 |
| AG 보조(선택) | 기존→신규로 AG를 구성해 동기화 후 컷오버 | 다운타임을 더 줄일 수 있음 | 구성·운영 복잡도, 라이선스/에디션/네트워크 요구 증가 |
| 인플레이스 | 기존 노드를 교체/업그레이드 | 단순 | 리허설/롤백 어렵고 운영 리스크 큼 |
본 글은 스윙 FCI 기준으로 설명합니다.
3. 네트워크/IP 설계 (VIP 유지 + RIP 변경을 동시에 만족시키는 방법)
3.1 VIP(클라이언트 접속 IP) 유지
- 예:
VIP = 10.10.10.100/24
컷오버 후에도 동일 IP를 신규 FCI가 사용 - (선택) DNS TTL 사전 인하
- VNN/VIP가 완전히 동일하다면 TTL 영향은 제한적입니다.
- 하지만 일부 클라이언트 캐시, DNS 갱신 확인, 멀티서브넷 등 변수가 있으면 TTL 인하가 도움이 됩니다.
3.2 노드 RIP(관리/백업/모니터링 IP) 변경
- 예: 구 노드
10.10.10.11/12→ 신규 노드10.20.20.21/22 - 관리망/백업망/하트비트망이 분리된 환경이라면 각 NIC별 RIP 전부 재설계/검증
3.3 가장 중요한 전제: “VIP 서브넷 연결성”은 반드시 유지돼야 함
VIP를 기존 서브넷에 그대로 두려면, 신규 노드가 다음 중 하나를 만족해야 합니다.
- 권장(가장 흔함): 클라이언트 VLAN(=VIP 서브넷)에 연결된 NIC를 유지
- 관리망/백업망은 별도 NIC로 신규 대역 사용
- 또는: 동일 NIC에 secondary IP로 VIP 서브넷을 수용(네트워크 정책에 따라 제한될 수 있음)
- 또는: 멀티서브넷/클라우드 환경이면 별도 패턴(예: ILB/Overlay) 필요
결론: “노드 RIP가 바뀐다”는 것과 “VIP 서브넷 연결을 유지한다”는 것은 동시에 설계되어야 합니다.
4. IP 계획 표(템플릿)
| 리소스 | 기존 | 신규 | 변경 여부 | 비고 |
|---|---|---|---|---|
| VIP(VNN) | 10.10.10.100 | 10.10.10.100 | 유지 | 클라이언트 접속 IP |
| 노드A RIP(관리망) | 10.10.10.11 | 10.20.20.21 | 변경 | 운영 접근/백업/모니터링 |
| 노드B RIP(관리망) | 10.10.10.12 | 10.20.20.22 | 변경 | 운영 접근/백업/모니터링 |
| 백업망(선택) | 10.30.30.x | 10.40.40.x | 변경 | 분리망 운영 시 |
| Heartbeat/Private | 별도 대역 | 동일/신규 | 환경별 | 라우팅/방화벽 점검 |
5. 단계별 실행 절차(체크리스트 포함)
A. 사전 준비 (D‑14 ~ D‑2)
재고/현황 파악
- SQL 버전/에디션/CU, 인스턴스 이름, 포트(고정/동적), Collation, 서비스 계정
- DB 목록, 크기, 백업 전략, RPO/RTO, 주요 배치/ETL/연동
- SQL Agent 잡/연결 서버/크리덴셜/프록시/SSIS/SSRS 등 종속성
호환성/표준 정렬
- 신규 OS/SQL 패치 레벨 표준화
- 클러스터 기능/스토리지/네트워크 검증(사전
Test-Cluster계획) - 동일한 설정 템플릿 적용(MAXDOP, Cost Threshold, Max Memory, TempDB 등)
AD/DNS 사전 작업(가장 자주 터지는 구간)
- 기존 FCI VCO(예: SQLPROD) 의 위치(OU)와 권한 확인
- 신규 클러스터 CNO(예: CLUSNEW$) 가 VCO를 제어할 수 있도록 권한 설계
- 이상적: VCO에 대해 신규 CNO에 Full Control(또는 클러스터 요구 권한) 부여
- (선택) DNS TTL 인하(운영 정책에 맞게)
네트워크/RIP 설계
- 신규 대역(VLAN/서브넷/게이트웨이)
- 방화벽/ACL 업데이트 목록 작성
- App → VIP:1433
- Backup/Monitoring → 노드 RIP(에이전트/WinRM/WMI/SMB 등)
- 관리망 접근 정책(점프서버/운영자 PC)
백업/복구 리허설(반드시 수행)
- 전체/차등/로그 백업 → 별도 환경에서 실제 복원 검증
- 경로, 권한, 압축, 암호화(사용 시), 복원 시간 측정
성능 기준선(Baseline)
- CPU/IOPS/Wait Stats/상위 쿼리/Query Store(가능 시) 스냅샷 확보
- 전환 후 “회귀(regression)” 판정 근거로 사용
B. 신규 클러스터 구축 (D‑7 ~ D‑2)
- 신규 노드에 RIP(신규 대역) 부여
(원격 끊김 대비 iDRAC/iLO/콘솔 확보) - WSFC 구성(쿼럼 구성: 디스크/파일공유/클라우드 위트니스)
- 공유 스토리지/LUN 구성 및 권한, MPIO, 드라이버 정합성 확인
- 임시 VNN/임시 VIP 로 신규 FCI 인스턴스 설치
예:SQLNEW-TMP,10.20.20.200 - SQL 서버 설정 표준화(COLLATION, TempDB, 메모리/병렬, 유지보수 잡 등)
데이터 이행 채널 결정
- 운영 표준화 관점에서는 다음 조합이 가장 흔합니다.
- 초기 시드(seed): Full 백업/복원
- 동기화: 로그 전달(Log Shipping) 또는 주기적 로그 복원(수동/자동)
C. 데이터 동기화 (D‑2 ~ D‑1)
- 운영 DB 전체 백업 → 신규 FCI에
WITH NORECOVERY로 복구 - 로그 백업/전송/적용 자동화(스케줄링) → Lag 최소화
- 앱/배치 영향 최소화를 위해 동기화 타이밍과 백업 윈도우를 명확히 운영
D. 컷오버(D‑Day) — 런북 형태로 실행
컷오버는 “기술 작업”이 아니라 “운영 이벤트”입니다.
반드시 담당자/승인자/시간/롤백 기준이 포함된 런북으로 실행하세요.
1) 다운타임 시작 공지 / 변경창 확보
- 사용자 공지, 점검 페이지/기능 잠금 등 준비
2) 쓰기 트래픽 차단
- SQL Agent 잡 중지, ETL/배치/연동 중지
- 앱 쓰기 차단(가능하면 Read-only 모드)
3) 최종 동기화
- 최종 로그 백업(필요 시 tail-log) → 신규 적용 →
WITH RECOVERY
4) VNN/VIP 승계(핵심 단계)
- 구 클러스터에서 기존 SQL Network Name / IP 리소스 Offline
- 신규 클러스터의 임시 VNN을 기존 VNN(예: SQLPROD) 으로 변경
- 신규 클러스터의 IP 리소스를 기존 VIP(10.10.10.100) 로 변경
- DNS 등록/전파 확인, 필요 시 강제 등록(정책 범위 내)
- SPN 재등록(필요 시)
5) 가동 확인(즉시 검증)
SQLPROD(VNN) /10.10.10.100(VIP) 접속 확인- 핵심 트랜잭션(Write) / 주요 조회(Read) / 리포트 / 배치 재개
- 백업/모니터링 에이전트 정상 동작 확인
6) 다운타임 종료 공지
E. 후속 정리 (D+1 ~)
- Failover 테스트(계획된 장애조치) 1회 이상
- 백업/모니터링/DR 재연결 및 검증
- 구 장비 폐기/반납(보안 와이프, CMDB 정리, IP 회수)
6. 운영자가 바로 쓰는 스크립트 모음(템플릿)
주의
아래 스크립트는 “예시 템플릿”입니다.
실제 리소스 이름은 환경마다 다르므로Get-ClusterResource로 정확한 리소스명 확인 후 적용하세요.
6.1 (신규 클러스터) VIP를 기존 VIP로 변경
# IP Address 리소스 목록
Get-ClusterResource |
Where-Object { $_.ResourceType -eq 'IP Address' } |
Format-Table Name, State, OwnerGroup
# 예: 대상 리소스명을 변수로 지정
$ipResName = "IP Address 1"
# 리소스 중지
Stop-ClusterResource -Name $ipResName
# IP 파라미터 업데이트 (기존 VIP 10.10.10.100/24)
$ipRes = Get-ClusterResource -Name $ipResName
$ipRes | Set-ClusterParameter -Name "Address" -Value "10.10.10.100"
$ipRes | Set-ClusterParameter -Name "SubnetMask" -Value "255.255.255.0"
$ipRes | Set-ClusterParameter -Name "EnableDhcp" -Value 0
# 재기동
Start-ClusterResource -Name $ipResName6.2 (신규 클러스터) VNN(Network Name) 변경 및 Online
# Network Name 리소스 목록
Get-ClusterResource |
Where-Object { $_.ResourceType -eq 'Network Name' } |
Format-Table Name, State, OwnerGroup
# 예: 임시 VNN 리소스명을 지정
$vnnResName = "SQL Network Name (SQLNEW-TMP)"
# Offline 후 이름 변경(파라미터 Name)
Stop-ClusterResource -Name $vnnResName
(Get-ClusterResource -Name $vnnResName) |
Set-ClusterParameter -Name "Name" -Value "SQLPROD"
# Online
Start-ClusterResource -Name $vnnResName실무 팁
멀티서브넷/특수 DNS 정책이 있다면 Network Name 리소스의RegisterAllProvidersIP,HostRecordTTL같은 파라미터가 이슈가 될 수 있습니다. 단일 서브넷이면 보통 기본값으로 충분합니다.
6.3 DNS 확인(운영자 검증용)
# DNS 조회(클라이언트 관점)
nslookup SQLPROD
# (필요 시) 로컬 DNS 캐시 플러시(앱 서버/운영자 PC에서)
ipconfig /flushdns6.4 SPN 재등록(필요 시)
:: 서비스 계정 SPN 조회
setspn -L DOMAIN\svc-sql
:: (예시) 포트 1433 고정인 경우 - 중복 방지 위해 -S 사용
setspn -S MSSQLSvc/SQLPROD:1433 DOMAIN\svc-sql
setspn -S MSSQLSvc/SQLPROD.DOMAIN.LOCAL:1433 DOMAIN\svc-sql
:: 중복 SPN 점검(권장)
setspn -XSPN 관련 장애 신호
- SSPI handshake failed / Kerberos 인증 실패
- 특정 앱 서버에서만 간헐적 로그인 실패
이 경우 SPN 중복/권한/레코드 전파를 우선 점검합니다.
6.5 노드 RIP 변경(Windows) — 원격 끊김 대비 필수
# 주의: 원격 접속 단절을 대비해 iDRAC/iLO/콘솔 확보 후 실행 권장
# 기존 IP 제거(예: 10.10.10.*)
Get-NetIPAddress -InterfaceAlias "Ethernet0" -AddressFamily IPv4 |
Where-Object { $_.IPAddress -like "10.10.10.*" } |
Remove-NetIPAddress -Confirm:$false
# 새 RIP 부여(예: 10.20.20.21/24)
New-NetIPAddress -InterfaceAlias "Ethernet0" `
-IPAddress "10.20.20.21" -PrefixLength 24 -DefaultGateway "10.20.20.1"
# DNS 등록(정책 허용 범위 내)
Register-DnsClient7. 품질 보증(QA) 체크리스트
클러스터/인프라
- [ ]
Test-Cluster결과 Warning/Error에 대한 조치 완료(또는 승인된 예외 문서화) - [ ] 공유 스토리지/MPIO/디스크 소유권 정상
- [ ] Failover(수동/자동) 테스트 통과
접속점(VNN/VIP)
- [ ] VIP(10.10.10.100)로 접속 정상
- [ ] VNN(SQLPROD)로 접속 정상 (연결 문자열 변경 없음)
- [ ] DNS 레코드/전파 확인(nslookup 결과 일치)
네트워크/RIP 변경 반영
- [ ] 노드 RIP(10.20.20.21/22) 기준으로 운영 접근(RDP/WinRM) 정상
- [ ] 백업/모니터링/보안(ACL/허용목록) 시스템에 신규 RIP 반영 완료
- [ ] 방화벽/보안장비 정책 업데이트 완료
보안/계정
- [ ] SPN 중복 없음(
setspn -X) - [ ] Kerberos/SSPI 오류 없음(또는 예외 원인/대응 기록)
- [ ] SQL Agent Job/Proxy/Credential 정상
데이터/업무
- [ ] 핵심 트랜잭션(Write) / 주요 조회(Read) / 리포트 테스트 통과
- [ ] 성능 기준선 대비 동등 이상(또는 회귀 분석/조치 계획 수립)
8. 롤백 플랜(안전망)
롤백 전제
- 컷오버 이후 신규 환경에 쓰기 트래픽이 들어가면 “단순 롤백”은 어려워집니다.
따라서 런북에는 롤백 결정 시점(Go/No-Go 게이트) 을 반드시 둡니다.
단순 롤백(권장 시나리오)
1) 신규 클러스터에서 VNN/VIP Offline
2) 구 클러스터에서 VNN/VIP Online(AD/DNS 권한/상태 복구 포함)
3) 앱 접속 정상화 확인
4) 데이터 정합성 확인 후 재시도 일정 수립
9. 자주 묻는 질문(FAQ)
Q1. VIP를 유지하면 정말 앱 수정이 없나요?
A. 대부분은 없습니다. 다만 다음은 반드시 함께 점검해야 합니다.
- 앱이 IP로 붙는지, VNN(이름)으로 붙는지(대부분 VNN)
- 방화벽/WAF/LB/보안장비가 “노드 RIP 변경”을 인지해야 하는지
- 모니터링/백업 에이전트가 노드 RIP를 기준으로 허용목록을 쓰는지
Q2. 노드 RIP 변경 시 가장 큰 주의점은?
A. 원격 접속 단절입니다. 반드시 iDRAC/iLO 콘솔 확보 후 진행하세요.
추가로 다음도 자주 문제 됩니다.
- NIC 바인딩/Metric/라우팅 우선순위
- DNS 등록 갱신
- 백업/모니터링 서버의 접근 허용 정책(ACL) 즉시 갱신
Q3. 단일 서브넷/멀티 서브넷 모두 가능한가요?
A. 가능합니다. 다만 멀티 서브넷 환경은 추가 고려가 필요합니다.
- DNS 등록 정책(
RegisterAllProvidersIP등) - 클라이언트 드라이버 옵션(예:
MultiSubnetFailover=True여부) - 장애 시 연결 지연/재시도 정책