Windows Storage Spaces 설계, 미러·패리티와 장애 복구 순서를 구분하는 법

AI를 활용하여 생성한 이미지입니다.

Storage Spaces는 디스크 여러 개를 하나의 저장소 풀로 묶고, 그 안에 장애 대응 방식을 정한 가상 디스크를 만든 뒤 볼륨을 올리는 구조예요. 실제 운영에서 문제가 생기는 이유는 이 세 층을 한꺼번에 “디스크”라고 부르기 때문입니다. 어떤 디스크가 빠졌는지, 가상 디스크의 복원력이 무엇인지, 파일 시스템 볼륨이 정상인지 따로 확인해야 복구 순서를 거꾸로 밟지 않아요.[1]

풀·가상 디스크·볼륨을 따로 봐요

디스크 하나가 사라졌다고 바로 초기화하거나 풀에서 제거하면 안 돼요. 연결 케이블이나 HBA, 전원, 디스크 인식 상태가 원인일 수 있고, 실제 장애가 아니라 일시적인 연결 끊김일 수도 있어요. 현재 상태를 캡처한 뒤 물리 장치와 저장소 계층을 나누어 확인하는 게 안전합니다.

미러와 패리티를 사용 조건으로 선택해요

미러는 같은 데이터를 여러 디스크에 복제하는 방식이라 쓰기 지연과 복구 예측이 비교적 단순한 편이에요. 대신 같은 용량의 디스크를 여러 개 써야 하고, 원본 용량 대비 실제 사용 가능한 공간이 줄어듭니다. 데이터베이스, 가상 머신, 자주 바뀌는 작업 파일처럼 작은 쓰기가 계속 발생하는 영역이라면 미러가 설명하기 쉬운 선택이에요.

패리티는 데이터를 나누고 패리티 정보를 함께 기록해 디스크 효율을 높이는 방식이에요. 다만 작은 쓰기에서는 읽기와 계산, 다시 쓰기가 겹쳐 성능이 흔들릴 수 있어요. 백업 저장소나 큰 파일을 순차적으로 쓰는 영역에는 맞을 수 있지만, 가상 머신 디스크나 대화형 작업 볼륨을 무조건 패리티로 만들면 체감 성능이 나빠질 수 있어요. Microsoft도 볼륨을 계획할 때 워크로드와 복원력, 디스크 수를 함께 결정하도록 안내합니다.[3]

열과 인터리브를 건드리기 전에

가상 디스크의 열 수와 인터리브는 데이터가 여러 디스크에 배치되는 방식에 영향을 줘요. 디스크를 나중에 추가한다고 기존 가상 디스크의 레이아웃이 모든 경우에 자동으로 최적화되는 것은 아니에요. 기존 설계를 그대로 두고 디스크만 더하면 새 공간과 기존 공간의 성능 특성이 달라질 수 있어요.[3]

중급 사용자가 자주 하는 실수는 최대 용량만 보고 디스크를 고르는 일이에요. 실제로는 디스크 종류, 연결 버스, 캐시 장치, 기록 패턴, 복구 중 발생하는 부하가 함께 작용합니다. 만들기 전에 다음 정보를 표로 남겨 두면 장애 때 판단이 빨라져요.

• 디스크별 모델, 용량, 연결 경로와 현재 상태를 기록해요.
• 가상 디스크의 복원력, 열 수, 인터리브, 고정 프로비저닝 여부를 적어요.
• 볼륨의 파일 시스템, 드라이브 문자 또는 마운트 지점, 실제 사용량을 남겨요.
• 업무 파일과 백업 파일을 같은 풀에 둘지 분리해요.

장애가 났을 때의 순서

1. 파일 쓰기를 줄이고 현재 풀·가상 디스크·볼륨 상태를 저장해요.
2. 디스크가 운영체제와 저장소 관리 화면에서 모두 사라졌는지 비교해요.
3. 케이블, 전원, HBA, 펌웨어 같은 물리 경로를 확인해요.
4. 실제 고장으로 판단될 때만 교체 디스크를 준비하고, 복구 작업이 시작됐는지 확인해요.
5. 복구가 끝나기 전에는 성능 테스트나 대량 파일 이동을 겹치지 않게 해요.
6. 볼륨과 애플리케이션을 읽기 전용 또는 제한된 상태에서 점검한 뒤 정상 쓰기로 돌려요.

복구 중에는 남은 디스크에 추가 부하가 생겨요. 중요한 데이터를 다른 위치에 복사해야 한다면 복구 상태와 서비스 영향부터 확인하세요. 장애가 반복되는 풀에서 디스크를 계속 교체하는 식으로 버티면 원인이 컨트롤러나 전원에 있는데도 데이터만 흔들릴 수 있어요.

Storage Spaces Direct와 단일 서버를 혼동하지 않아요

단일 서버의 Storage Spaces와 Storage Spaces Direct는 운영 전제가 달라요. Storage Spaces Direct는 여러 서버의 로컬 드라이브를 묶는 클러스터 구성과 네트워크, 검증된 하드웨어 조건을 함께 요구하는 기능이에요. 일반 데스크톱이나 단일 파일 서버에 디스크를 꽂는 문제를 해결하려고 S2D 구성을 따라 하면 복잡성만 늘어납니다.[2]

반대로 클러스터를 운영한다면 디스크 장애만 보지 말고 서버 간 네트워크와 클러스터 상태를 함께 확인해야 해요. 풀과 볼륨이 정상이어도 노드 간 통신이 불안정하면 복구와 성능 판단이 왜곡될 수 있습니다.

Windows에서 가상화나 개발 환경을 함께 운영한다면 저장소 설계와 네트워크 설계를 따로 보지 않는 게 좋아요. WSL2 네트워크 모드와 포트 전달을 점검한 기존 글도 함께 참고하면, 저장소 장애와 서비스 접속 장애를 구분하는 데 도움이 됩니다. WSL2 네트워크 모드 점검 글에서 연결 경로를 확인해 보세요.

만들기 전에 정할 기준

Storage Spaces의 선택은 “미러가 더 좋다”처럼 끝나지 않아요. 저장할 데이터의 쓰기 패턴, 허용 가능한 장애 수, 복구 시간, 별도 백업 위치, 교체 디스크 확보 시간을 같이 정해야 합니다. 지금 필요한 게 용량 확장인지, 디스크 장애 대응인지, 서버 간 가용성인지 먼저 구분하면 설계가 훨씬 단순해져요.

확장과 재배치를 같은 작업으로 보지 않아요

저장소 풀에 디스크를 추가하는 것과 기존 가상 디스크의 데이터를 새 디스크까지 재배치하는 것은 다른 작업이에요. 용량이 늘었다는 화면만 보고 기존 데이터의 성능이나 장애 여유가 바로 좋아졌다고 생각하면 안 됩니다. 새 디스크가 어떤 가상 디스크에 사용되는지, 재배치 작업이 끝났는지, 복구 작업과 겹치지 않는지 확인해야 해요.[1][3]

운영 중인 서버라면 작업 시간을 정하고, 파일 서버나 가상 머신의 쓰기량이 적은 시간에 진행해요. 상태를 확인하는 동안에도 디스크가 간헐적으로 끊기는지 이벤트 로그와 저장소 상태를 함께 기록하세요. 같은 디스크가 다시 오류를 내면 단순한 용량 부족이 아니라 연결 경로 또는 전원 문제일 가능성이 커집니다.

읽기 전용 점검 명령을 먼저 준비해요

Get-StoragePool
Get-VirtualDisk
Get-PhysicalDisk
Get-Volume
Get-StorageJob

이 명령은 상태를 바꾸기보다 현재 구성과 진행 중인 작업을 파악하는 출발점으로 쓰기 좋아요. 출력은 장애 전 기준값과 비교할 수 있도록 파일로 저장하고, 디스크를 초기화하거나 풀에서 제거하는 명령은 별도의 승인 단계로 분리하세요. 복구가 필요한데도 성급하게 새 풀을 만들면 기존 메타데이터와 장애 원인을 함께 잃을 수 있어요.

백업 검증도 설계에 포함해야 해요. 미러나 패리티는 디스크 고장에 대비하는 복원력이지, 삭제·랜섬웨어·잘못된 권한·서버 전체 손실을 되돌리는 백업은 아니에요. 다른 장치나 다른 위치에 복사본을 두고, 실제 복원 테스트를 일정에 넣어야 Storage Spaces의 보호 범위를 과대평가하지 않게 됩니다.[1]

Sources

1. [1] Storage Spaces 개요 | Microsoft Learn
2. [2] Storage Spaces Direct 개요 | Microsoft Learn
3. [3] 볼륨 계획 | Microsoft Learn