Windows Server 2012, Data Deduplication

Windows Server 2012 RTM이 발표되고, 요 며칠 사이 테스트 해보는 중. 감동의 쓰나미가 밀려오기도 하다가, 의외로 허당 같기도 해서 롤러코스터를 타는 중. Windows Server 2012 같은 경우는 회사(프로젝트에 직접 참여한 건 아니지만)에서 Windows Server 2012 RDP (Rapid Deploy Program) 프로그램에 참여하게 돼서 교육도 받고, 최근 관심 있게 지켜보고 있는 항목. 내용은 Microsoft Evangelist이신 꼬알라(백승주)님의 블로그 내용을 참조 하였음.

Windows Server 2012, 데이터 중복 제거 기술(Data Deduplication)을 활용한 서버 스토리지 최적화

EMC나 NetApp 등 최근 스토리지 장비의 화두는 유니파이드 스토리지(Unified Storage), Thin Provisioning, 데이터 중복 제거 기술(Data Deduplication) 이 세 가지가 세일즈 포인트인 느낌을 받는데, 그 중 데이터 중복 제거 기술이 Windows Server 2012의 기본 기능으로 들어가게 됐습니다. 이 디듑의 원리는 디스크에 저장된 데이터를 아주 작은 (32K~128KB) 하나의 단위(Chunk)로 조각 내고, 디스크 내에 동일한 조각이 있다고 판단 되면 중복된 조각을 지우고 하나의 조각으로 파일 시스템 내부에서 링크를 걸어 디스크의 공간을 절약하는 것. 사실 디스크 내에서는 데이터 조각이 파편화 되기 때문에 성능과는 거리가 있고 이 작업들이 실시간으로 이루어지지 않고, 스케쥴러를 통한 백그라운드 작업으로만 이루어지기 때문에 유연하지도 않은 것 같습니다. 보통 스토리지 벤더에서는 이러한 데이터 디듑 기능이 5~10%의 성능 저하를 일으킬 수 있다고 밝히고 있습니다.

이러한 중복 제거라는 기술을 처음 접하게 된 건, 오래전 Windows 2000 시절 Professional, Server, Advanced Server 이 세 개의 버전이 모두 한 장의 시디로 포함된 WoW(Windows on Windows나 World of Warcraft 아닙니다 -_-...) 버전을 본게 처음이었는데, 세 가지의 버전을 하드디스크로 복사하면 약 1.5GB를 넘는 용량이었지만 ISO나 실제 CD 내부에서는 650MB 안에 저장이 가능했었습니다. 이는 Windows 2000 설치 파일 중 세가지 버전에서 모두 공유해서 쓸 수 있는 Driver.cab 등의 중복 파일들을 CDFS 의 인덱스에서 링크(혹은 포인터)를 걸게 됨으로서 실제 CD에 저장되는 용량을 줄여 650MB 안으로 기록하는 기술 이었습니다. 물론 엄밀히 따지면 이렇게 CDImage.exe 나 OSCDIMG.exe 를 이용하는 방법이 File Chunk를 이용한 데이터 중복 제거와는 100% 다른 기능이긴 하지만, 대략의 원리는 비슷하다고 볼 수 있을 것 같습니다. (cdimage나 oscdimg에서는 -o 옵션을 주고 이미지를 만들게 되면 MD5 Hashing을 이용해 동일한 파일을 구분하여, Deduplication을 시행합니다)

Windows Server 2012의 서버 관리자의 역할 및 추가 기능 마법사로 "파일 서버 및 iSCSI 서비스" - "데이터 중복 제거" 기능을 설치할 수 있고, 설치 후에는 서버 관리자의 "파일 및 저장소 서비스" 항목에서 확인할 수 있습니다. 논리 드라이브(볼륨) 단위로 디듑 기능을 활성화 할 수 있습니다. 간단한 작동 포인트는, OS가 설치된 파티션 디스크 (C:\)는 디듑이 활성화 되지 않음. Clustered Shared Volume(CSV) 도 적용되지 않음. 주 1회, 일 1회의 중복 제거를 위한 스케쥴러가 설정 됨. MS에서도 타 스토리지 벤더와 마찬가지로 데이터 디듑에 의한 성능 저하는 5% 내외라고 주장하고 있습니다. 주 1회(토요일 새벽) 로 잡혀있는 GarbageCollection, Scrubbing 작업의 경우는 파워쉘(PS)에서 StartDedup-Job D: -Type Scrubbing (Job Name) 이라고 하면 바로 시작 된다고 하던데 Queue에만 걸리고 실제론 잘 안 됐습니다. (날짜 바꾸기도 귀찮고, 일주일 기다렸음... 헐...)

PS C:\Users\Administrator> get-dedupmetadata d:     Volume                         : D: VolumeId                       : \\?\Volume{11e9d941-d2c6-464f-bd5f-d1e93f487b2e}\ StoreId                        : {1B76B5FD-920E-4253-A58F-01D957FE5667} DataChunkCount                 : 422567 DataContainerCount             : 30 DataChunkAverageSize           : 73.62 KB DataChunkMedianSize            : 0 B DataStoreUncompactedFreespace  : 0 B StreamMapChunkCount            : 257 StreamMapContainerCount        : 2 StreamMapAverageDataChunkCount : StreamMapMedianDataChunkCount  : StreamMapMaxDataChunkCount     : HotspotChunkCount              : 69 HotspotContainerCount          : 1 HotspotMedianReferenceCount    : CorruptionLogEntryCount        : 0 TotalChunkStoreSize            : 29.86 GB     PS C:\Users\Administrator> get-dedupstatus   FreeSpace    SavedSpace   OptimizedFiles     InPolicyFiles      Volume ---------    ----------   --------------     -------------      ------ 222.44 GB    149.84 GB    150                150                D:

실제 저장된 디스크의 내용은 데이터 디듑의 성능을 확인해보기 위해 같은 내용의 파일을 다른 이름으로 저장했고, 이는 데이터 디듑의 기능이 극대화 된 (78% 제거) 특수한 경우이며 일반적인 경우는 아니라고 생각 됩니다. D:\DD\ 폴더에는 약 192GB 가량의 파일이 저장되어있지만, 실제로 디스크에는 33GB의 공간만 점유하고 있으며, 디듑으로 세이브 된 공간은 약 150GB 가량으로 표시 됩니다.

데이터 디듑 기능 보다가 번뜩 떠오른 우스개 이야기로 살색 많이 나오는 야구 동영상들을 한 곳에 모아두면 중복 제거 비율이 더 높아질까? 아니면 같은 주인공인 영상이면 중복 제거가 더 잘 될까? 물론 이론적으로는 턱도 없는 소리(영상 압축)인 거 알지만, 흥미로운 주제여서 증명을 한번 해보고 싶었는데, 요즘 분위기로는 괜히 인증했다가 잡혀갈 거 같아서 패스 (개인적으로는 아동/동물/스너프 이런 거 혐오합니다. 노홍철보다 유재석을 더 선호합니다 (...) 

Windows 8 에도 데이터 디듑 기능을 넣어줬다면 좋겠지만 이 디듑 기능은 백 그라운드 작업을 기본으로 하기 때문에, OS 특성에도 안 맞아서 큰 효과를 낼 수 있을 지가 의문이긴 합니다. 스토리지 박스, Windows Server 2012 외에 이런 데이터 디듑을 사용할 수 있는 솔루션으로는 ZFS 파일시스템을 이용한 NexentaStor 등으로도 구현이 가능한 것으로 알고 있지만, 일반 용도의 레벨에서는 구현하기가 까다롭다는 단점이 있습니다. 간단한 Windows 시스템에서 파일 (스토리지) 서버를 구현해야 한다면 Windows Server 2012가 좋은 대안이 될 듯 합니다.

다만 한 가지 우려 되는 것은 Chunk 단위로 구분이 되기 때문에, 싱글 디스크 환경에서는 특정 섹터에 물리적으로 배드 섹터가 생기게 되면, 중복된 조각을 갖고 있는 다른(여러) 파일에 영향을 미칠 수 있을 것 같습니다. 그래서 대부분은 리던던트를 가진 RAID를 사용 하거나(서버에서는 기본적으로 사용하고 있다고 가정하거나) 사용하도록 권장을 하는 것 같습니다. 벤더에서 말하는 5~10% 의 성능 저하는 디듑이 적용 된 볼륨에서의 읽기/쓰기를 말하는 것 같고 (실제로는 성능 저하를 느끼지 못했습니다) 저장된 데이터를 조각내어 재배열하는 작업(백그라운드 스케쥴러)에는 별도의 디스크 I/O와 시간을 필요로 합니다. 하드웨어 벤더 쪽에서는 이 디듑 I/O가 발생하는 시간과 일반 I/O가 겹쳐 질 때, 디듑의 디스크 I/O를 감소시키거나 건너 띌 수 있게 관리 할 수 있다고 하는데, Windows Server 2012에선 그러한 고급 컨트롤이 되는지는 모르겠습니다. 

시스템 관리자 입장에서는 디스크 공간을 최대한 활용할 수 있는 매력적인 기능이며, 2차 백업 서버 등의 실무에는 고민 없이 곧바로 적용할 수 있는 아이템입니다. 낭비 되는 디스크의 공간을 절약하기 위한 역사를 살펴보면 MS-DOS 시절의 스태커나 더블 스페이스, NTFS의 폴더 내용 압축 등 이름만 다른 한 가지의 기술들이 사용 되어왔는데요. 데이터 디듑 기능은 이러한 압축 기반이 아닌 순수 파일 시스템 기반의 기술 입니다.

--

이런 중복 제거 기술을 극대화 해서 활용할 수 있는 곳은 VHD/VMDK 라이브러리 or DB 백업 서버 등등... 근데 괜히 잘 돌아가는 거, 신기술 적용/활용도 높여보겠다고 건드렸다가 장애 내고 긁어 부스럼 만들거 같아서 항상 딜레마임. 안 그래도 시키는 일 많은데, 안 시킨 일까지 찾아하려면 귀찮기도 하고...