Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

...

전환(switch-over)은 복제 클러스터 내의 하나의 시스템에서 다른 시스템으로 자원에 대한 액세스를 수동 교환하는 동작입니다. 소스 노드를 강등시킨 후 타깃노드를 소스노드 역할로 승격하여 서비스를 위한 데이터를 활성화하는 과정입니다. 수동절체 라고도 하며 이와 반대로 장애에 자동 대응하는 개념으로 장애조치(fail-over)가 있습니다.

...

FSR은 파일삭제에 대한 백업을 제공합니다. 파일삭제에 대한 백업은 의도치 않게 삭제 되는 파일들을 타깃의 특정경로에 임시로 저장해 두는 기능으로 archive 속성에 의해 지정될 수 있습니다. archive 속성은 기본 비활성화 되어 있으며 백업될 경로와 보관될 기간을 지정할 수 있습니다.


스냅샷

스냅샷은 특정 시점의 스토리지의 파일 시스템을 사진 찍듯이 캡처해서 데이터를 백업하는 기술 입니다. 복제 운영 중 사고로 최신 데이터가 훼손되거나 말웨어 감염과 같은 보안이슈에 노출되어 데이터 무결성이 훼손되면 복제의 기능만으로는 대응할 수 없습니다.

이런 경우를 대비해 복제와는 별개로 백업을 미리 해 두는게 일반적이며, 백업 유형에 따라 전체 백업 또는 전체 스냅샷, 증분 스냅샷을 통해 사용자의 데이터를 보호할 수 있습니다.

FSR은 스냅샷 기능을 복제 리소스를 기준으로 구현하고 있으며 따라서 스냅샷 제어도 리소스를 기준으로 합니다. 또한 스냅샷은 각 노드의 디스크 볼륨에 이미지로 저장 되고 노드 내에서 제어하고 처리됩니다. 이것은 클러스터 노드 들 간의 스냅샷들에 대한 상호 연동은 없다는 뜻 입니다. 노드 별로 스냅샷을 운영하다가 복구가 필요하면 노드에 저장된 이미지로 개별 복구하면 됩니다.

스냅샷 볼륨

스냅샷을 운영하기에 앞서 가장 먼저 고려해야 할 것은 스냅샷을 저장해 둘 볼륨을 지정하는 것 입니다. 복제 볼륨 내에 스냅샷을 보관해 둘 수 도 있고 외부의 다른 디스크 볼륨에 저장할 수도 있습니다. 이것은 볼륨에서 사용된 공간과 여유 공간을 보고 정해야 하는데, 여유 공간이 많지 않다면 외부의 볼륨에 지정하여 스냅샷을 저장하는 것이 좋습니다. 

스냅샷을 위한 볼륨 공간은 현재 데이터의 크기 만큼의 용량을 필요로 합니다.

예를 들어 1TB 볼륨에 100GB 를 사용하고 있다면 여기에 필요한 스냅샷 용량은 100GB 입니다. 만약 사용 용량이 100GB 를 넘어서 150GB 가 된다면 새로운 스냅샷을 기록하는데 최대 150GB 용량이 요구될 것 입니다.

다음은 스냅샷을 운영하기 위한 구체적인 구성 사례입니다.

  • 복제 볼륨 1TB, 사용공간 300GB
  • 1일 1회 스냅샷 기록, 1주(7일)의 스냅샷 스케줄 유지

위 예의 경우 1주 동안 7개 스냅샷 이미지 공간이 요구 되므로 스냅샷 저장을 위한 볼륨의 공간은 최소 300GB * 7 = 2.1TB 이며 최대 1TB * 7 = 7TB 가 됩니다.

스냅샷은 Copy On Write(COW) 기술을 기반으로 합니다. 데이터에 변경이 발생할 때 원본을 저장해 두는 것 입니다. 따라서 스냅샷을 생성한 지 얼마 지나지 않은 초기에는 변경점이 많지 않으므로 스냅샷이 차지하는 용량이 작습니다. 그렇지만 시간이 지날수록 데이터 변경 분은 점차 늘어나고 결국 데이터의 모든 영역이 변경 됬다고 가정하면 전체 원본 데이터를 저장해 둘 스냅샷 공간이 필요하게 됩니다. 결론적으로 스냅샷에 필요한 최대 용량은 데이터 전체 크기의 백업분에 해당하는 용량과 같다고 할 수 있습니다. 

당장 스냅샷에 필요한 공간은 현재 사용되는 공간 만큼의 용량을 요구하겠지만 볼륨의 사용량은 시간이 갈수록 증가할 수 있으므로 이를 염두에 두어서 최대 용량으로 고려해야 한다는 것 입니다.

Info
다른 제품의 스냅샷 기능의 매뉴얼에는 전체 볼륨의 수십% 의 볼륨 여유 공간을 확보하는 것을 권장한다고 되어 있는 경우가 있습니다. 그러나 이것은 스냅샷을 위한 최대용량을 말하는게 아니라 단지 권장용량을 의미하기 때문에 스냅샷 용량 구성에 대해 오해를 불러 일으킬 수 있습니다. 이를 알지 못하고 충분한 여유 공간 없이 스냅샷을 운영하다 보면 어느 시점에 가서 더 이상 스냅샷을 생성하지 못하게 될 것 입니다.

...

Info
title최대 사양

FSR 스냅샷은 Windows 에서 Volume Shadow Copy Service 의 명세를 따릅니다.

  • Windows 의 VSS 최대 볼륨 지원 크기는 64TB 입니다. 64TB 이상의 볼륨은 스냅샷을 지원하지 않습니다.
  • 하나의 볼륨에 최대 512개의 스냅샷 이미지를 기록할 수 있습니다(공유 폴더의 경우 기본 64개). 그 이상의 스냅샷을 기록할 경우 가장 오래된 스냅샷이 삭제됩니다.

리눅스 LVM 은 특별히 스냅샷 용량에 대해 제한하지 않습니다. 단지 스토리지 용량에 한정적 입니다.


전/후 처리

FSR 스냅샷은 응용 일관성(Application Consistency)을 보장하는 스냅샷을 지향합니다. 응용 프로그램이 일관성을 가진 스냅샷을 획득하기 위해선 다음의 절차가 수행되어야 합니다.

  1. 스냅샷을 기록하기 전
    1. 응용 I/O 작업을 일시 중단하고 응용의 메모리 버퍼를 Flush 하여 디스크를 최신 데이터로 갱신합니다.
    2. 해당 볼륨에 대한 파일시스템 캐쉬를 Flush 합니다.
  2. 스냅샷을 기록합니다.
  3. 응용 I/O 작업을 재개합니다.

위 절차에서 볼 수 있듯이 스냅샷을 기록하기 전과 후에 최신 데이터를 볼륨에 반영하는데 필요한 절차가 필요합니다.

이처럼 사용자는 FSR 의 스냅샷 사전/사후 핸들러를 통해 스크립트 형식으로 응용을 제어할 기회를 가지며 이 절차들이 충분히 수행 되었을 때 응용 일관성을 보장한 스냅샷을 취할 수 있습니다.

만약 위 절차대로 응용을 제어할 수 없다면 최소한 파일시스템 캐쉬를 Flush 해서 파일시스템 일관성(Filesystem Consistency)을 가진 스냅샷으로 기록해야 하며 이마저도 수행하지 않는다면 충돌 일관성(Crash Consistency) 수준의 스냅샷만을 확보하게 될 것 입니다.



Info

Windows 의 VSS 서비스는 이러한 응용 일관성 스냅샷을 보장하기 위하여 VSS Writer 를 응용 프로그램에서 구현하도록 제안하고 있습니다. VSS는 응용의 VSS Writer 와 상호 연동하여 스냅샷 요청이 있을 경우 위 절차를 차례로 수행하여 응용 일관성 스냅샷을 구현합니다. 따라서 VSS Writer 를 구현한 응용 프로그램을 대상으로 한다면 사전/사후 핸들러를 작성할 필요가 없습니다. 다음은 VSS Writer 를 지원하는 대표적인 프로그램들 입니다.

현실적으로는 위 프로그램들을 제외하면 대부분의 응용 프로그램들에선 VSS Writer 를 구현하고 있지 않습니다.