HyperSnapShot

Storage

HyperSnapShot

refer 2025. 2. 6. 15:31

용어

1. RTO

RTO(Recovery Time Objective) 목표 복구 시간을 말한다.

IT 시스템, 애플리케이션, 데이터 등의 장애 발생 시 허용 가능한 최대 복구 시간을 의미 한다.

즉, 장애가 발생한 후 시스템이 정상적으로 복구될 때까지 걸릴 수 있는 최대 시간이다.

(1-1) 예 : 온라인 쇼핑몰

한 온라인 쇼핑몰이 RTO를 2시간으로 설정했다 가정

만약 서버 장애로 인해 웹사이트가 다운되었다면, 2시간 이내에 서비스가 복구되어야 한다.

2시간을 초과하면 고객 불만 증가, 매출 손실, 브랜드 신뢰도 하락 등의 문제가 발생할 수 있다.

이를 위해 쇼핑몰은 백업 서버, 클라우드 복구 솔루션, 긴급 대응팀 등을 준비해 둔다.

(1-2) 예 : 은행의 인터넷 뱅킹 시스템

은행의 인터넷 뱅킹 시스템은 RTO를 30분으로 설정할 수 있다.

은행 서비스는 고객의 금융 거래와 직결되므로 빠르게 복구되어야 한다.

시스템 장애가 발생하면 30분 이내에 복구하지 못할 경우 고객 신뢰도 하락, 금융 손실 등 문제가 생긴다.

2. RPO

RPO(Recovery Point Objective) 목표 복구 지점을 말한다.

IT 시스템, 애플리케이션, 데이터 등의 장애 발생 시 데이터 손실을 최소화하기 위한 목표 지점이다.

RPO는 얼마나 최신 데이터를 복구할 수 있는지를 정의하는 데 중요한 지표이다.

(2-1) 예

A회사는 매일 자정에 데이터를 백업하고, 시스템에 문제가 생기면 가장 최근 백업 시점으로 복구를 관리하고 있으며,

RPO는 24시간 이다. 즉, 데이터 손실이 24시간 내에 발생할 수 있으며, 이를 감수할 수 있는 범위로 설정된 것이다.

만약 A회사가 24간 자정 이후 발생한 데이터를 복구할 수 없다면, 그 데이터는 손실되게 된다.

(2-2) 예

B회사는 1시간마다 데이터를 백업하고, 시스템에 문제가 생기면 최근 백업 시점으로 복구를 관리하고 있으며,

RPO는 1시간 이다. 시스템에 문제가 발생할 경우, 최근 1시간 내의 데이터만 손실되고, 1시간 전에 백업된 데이터로 복구가 가능하다. RPO는 데이터 복구의 목표 시점으로, 기업의 서비스 요구 사항과 복구 전략에 따라 다르게 설정될 수 있다.

RPO가 짧을수록 데이터 손실을 최소화할 수 있지만,, 백업 빈도나 비용이 증가할 수 있다.

3. COW

스냅샷의 COW(Copy-On-Write) 방식은 저장소 시스템에서 효율적으로 데이터를 관리하고, 데이터 변경 사항을 기록하는 기법이다. 이 기법은 주로 가상화 환경이나 파일 시스템에서 스냅샷을 만들 때 사용된다.

(3-1) COW의 작동 원리

(1) 기존 데이터에 대한 참조 유지

스냅샷을 만들 때, 기존의 데이터는 변경되지 않는다.

대신, 변경될 데이터는 새로운 위치에 저장되며 기존 데이터는 그대로 참조된다.

(2) 데이터 변경 시 복사본 생성

새로운 데이터가 기존 데이터의 일부를 변경하려고 할때, COW방식은 기존 데이터를 복사하여 새로운 공간에 저장한다.

그 후, 변경이 이루어지며, 변경된 부분만 새로운 복사본에 기록된다.

(3) 스냅샷의 효율성

COW 방식은 새로운 데이터가 기존 데이터를 덮어쓰지 않고, 변경된 부분만 새로 복사해서 저장하므로, 스냅샷을 생성하는 데 필요한 시간과 저장 공간이 적다. 이로 인해 스냅샷을 빠르고 효율적으로 생성할 수 있다.

(4) 예

A라는 파일시스템이 있다.

- 스냅샷 생성 전 상태 : 파일 시스템A는 데이터가 있고, 스냅샷으로 찍을 준비를 하고 있다.

- 스냅샷 생성 : 스냅샷을 생성할 때, A 파일 시스템에 있는 모든 데이터는 그대로 유지된다. 즉, 실제 데이터는 그대로 참조되고, 새로운 스냅샷은 A의 상태를 참조하는 포인터를 만든다.

- 데이터 변경 : 만약 A파일 시스템의 어떠한 파일이 변경되었다면, 그 변경된 데이터는 새로운 블록에 기록된다.

기존의 데이터는 그대로 유지되고, 변경된 부분만 복사되어 새로운 위치에 저장된다.

원본은 스냅샷에서 그대로 유지되고, 변경된 부분은 새로운 블록에 저장된다.

4. COW 장점

- 효율적인 스냅샷 생성 : 데이터 변경이 일어날 때마다 전체 데이터를 복사하는 대신, 변경된 부분만 복사하므로 스냅샷 생성이 빠르고 저장 공간을 절약할 수 있다.

- 데이터 무결성 보장 : 스냅샷을 만든 후에도 원본 데이터는 변경되지 않으며, 변경된 데이터만 새로운 공간에 기록되기 때문에 데이터 무결성이 보장된다.

- 빠른 복구 : 스냅샷을 통해 빠르게 특정 시점으로 복구할 수 있다. 복구 시, 스냅샷은 변경되지 않은 데이터를 그대로 참조하고, 변경된 부분만 원래 상태로 되돌리면 된다.

5. COW 단점

- 성능 저하: 변경될 데이터가 많아지면 COW 방식으로 인한 성능 저하가 발생할 수 있다.

특히, 새로운 데이터를 복사할 때마다 I/O 작업이 발생하므로, 많은 변화가 일어날 경우 성능에 영향을 줄 수 있다.

- 공간 사용 증가: 처음에는 공간 효율적이지만, 시간이 지나면서 많은 변경이 이루어지면 변경된 데이터를 저장하는 데 필요한 공간이 증가할 수 있다.

6. 결론

COW 방식은 스냅샷을 효율적으로 관리할 수 있게 해주며, 데이터를 안전하게 보호하고 복구할 수 있는 유용한 방법이다. 데이터가 변경될 때마다 전체 데이터를 복사하지 않고, 변경된 부분만 복사하기 때문에 시스템 성능과 저장 공간을 효율적으로 사용할 수 있다. 하지만, 읽기,쓰기I/O가 많이 발생할 경우 성능에 영향을 받는다. 스냅샷 으로 백업관리 시 점점 많은 용량을 요구한다.

7 . ROW

ROW(Redirect-On-Write) 방식은 스냅샷을 생성할 때, 기존 데이터를 변경하려는 요청이 있을 경우 그 데이터를 새로운 위치로 리디렉션(redirect) 하는 방식이다. 이 방식은 스냅샷의 생성과 관련하여 기존 데이터를 덮어쓰지 않고 새로운 블록에 저장하는 방식으로 작동한다.

8. ROW 방식의 작동 원리

- 스냅샷 생성

스냅샷을 생성할 때, 기존의 데이터는 그대로 유지된다.

스냅샷은 기존 데이터의 **"기록된 상태"**를 그대로 참조하는 일종의 포인터로 구성된다.

- 데이터 변경 시 리디렉션

데이터가 변경될 때, 기존 데이터 블록을 덮어쓰는 대신, 새로 변경된 데이터를 새로운 블록에 저장한다.

그리고 기존의 데이터는 스냅샷에 포함된 상태로 유지된다.

이렇게 되면, 스냅샷은 변경되지 않은 원본 데이터를 그대로 참조하고, 새로운 데이터는 새로운 위치에 기록된다.

- 스냅샷과 데이터 일관성

스냅샷은 데이터가 변경되기 전의 상태를 그대로 유지하며, 변경된 부분만 새로 기록되는 방식이다. 기존 데이터는 스냅샷이 생성될 당시의 상태를 유지하므로, 데이터의 일관성과 무결성이 보장된다.

(8-1) 예
가장 간단한 예로, A라는 파일 시스템이 있다고 가정한다.

- 스냅샷 생성 전

파일 시스템 A에 데이터가 있다.

- 스냅샷 생성

스냅샷을 생성하면, A 시스템의 데이터를 그대로 참조하는 포인터가 생성된다.

이 시점에서 스냅샷은 A 시스템의 상태를 캡처하며, 기존 데이터는 그대로 유지된다.

- 데이터 변경

만약 A 시스템에서 파일을 변경하려고 하면, 기존 데이터는 변경되지 않고, 변경된 데이터는 새로운 블록에 기록된다.

즉, 변경된 데이터는 기존 블록에 덮어쓰지 않고 새로운 위치에 저장된다.

- 스냅샷과 데이터

스냅샷은 여전히 기존 데이터를 참조한다.

변경된 데이터는 새로운 블록에 저장되며,

스냅샷은 그 시점의 원본 데이터를 그대로 유지한다.

9. ROW 방식의 장점
- 성능 개선

기존 데이터를 덮어쓰지 않고 새로운 위치에 기록하기 때문에, 원본 데이터에 대한 I/O 작업이 덜 발생하고, 데이터 변경 시 성능 저하를 줄일 수 있다. 또한, 스냅샷을 생성할 때 더 빠르게 작업을 처리할 수 있다.

- 데이터 무결성 유지

기존 데이터는 변경되지 않고 새로운 데이터는 새로운 위치에 기록되므로, 스냅샷을 통해 원본 데이터의 일관성 및 무결성을 유지할 수 있다.

- 스냅샷 생성의 효율성

기존 데이터에 덮어쓰지 않기 때문에, 스냅샷 생성 시 기존 데이터가 변경되지 않으므로 스냅샷이 추가적인 복사를 요구하지 않고 효율적으로 생성된다.

10. ROW 방식의 단점
- 공간 효율성 감소

기존 데이터를 덮어쓰지 않고 새로운 블록에 데이터를 기록하기 때문에, 시간이 지날수록 변경된 데이터가 쌓이게 되어 저장 공간을 더 많이 사용하게 된다. 여러 번의 데이터 변경이 발생하면, 새로운 블록이 계속 추가되어 공간 효율성이 낮아질 수 있다.

- 복잡한 관리

ROW 방식은 데이터를 새로운 블록에 기록하기 때문에, 여러 번의 변경이 발생하면 각 데이터 블록이 흩어져 관리가 어려워질 수 있다. 관리하는 데 더 많은 작업이 필요할 수 있다.

11. COW와 ROW 비교
COW (Copy-On-Write)는 데이터를 변경하려고 할 때, 기존 데이터를 복사하여 새로운 위치에 기록한다.

즉, 변경 시 새로운 복사본을 만들어 저장하는 방식이다.

ROW (Redirect-On-Write)는 데이터를 변경하려고 할 때, 기존 데이터를 그대로 두고 변경된 데이터를 새로운 블록에 기록한다. 즉, 기존 데이터는 스냅샷에서 그대로 참조되고, 변경된 데이터만 새로 기록된다.

12. 결론
ROW 방식은 스냅샷 생성 시 기존 데이터를 덮어쓰지 않고 변경된 데이터를 새로운 블록에 기록하는 방식으로,

데이터 무결성을 유지하고 성능을 개선할 수 있다.

하지만, 시간에 따라 저장 공간을 더 많이 소모할 수 있는 단점이 있다.

데이터 변경이 빈번한 시스템에서는 스냅샷을 효율적으로 관리하기 위해 ROW 방식이 유용할 수 있다.

13. 메타데이터 볼륨 LBA

디스크의 주소 지정 방식인 LBA(Logcal Block Address)를 사용하여 메타데이터를 설명하는 것을 말한다.

(13-1) LBA 주소 지정 방식

LBA 주소 지정 방식은 물리적인 구조를 고려할 필요 없이 디스크의 0번 실린더, 0번헤드 , 1번 섹터를 0번으로 하여 디스크의 마지막 섹터까지 순차적으로 지정한다.
LBA는 TB(BeraByte) 크기의 디스크까지 사용 가능하다.

(13-2) 메타데이터 볼륨 LBA 사용 사례

scan과 함께 사용 시 : 디스크에서 메타데이터를 찾을 첫 번째 LBA를 지정한다.
메타데이터는 LBA의 일부로 전송되거나, 애플리케이션에 노출될 수 있다.
메타데이터 MFT 엔트리가 존재하면 볼륨 크기를 계사할 수 있다.

(13-3) CHS(Cylinder, Head, Sector)주소 지정 방식

CHS는 물리적인 실린더, 헤드, 섹터의 주소를 각각 지정해 접근하는 방식이다.
CHS는 8GB 이하 디스크에서만 사용이 가능하다.

(13-4) MFT

엔트리의 크기(1KB)는 부트섹터에 기록된다.

파일의 크기가 1KB 이상이라면 여러 개의 엔트리를 사용할 수 있다.

1개의 파일이 여러 개의 엔트리를 사용하는 경우

- 첫 엔트리를 "기준 엔트리" 라고 부른다.

- 나머지 엔트리는 "기준 엔트리"주소를 포함한다.

MFT엔트리는 일종의 "소지품이 담겨 있는 큰 박스"

박스의 외부는 이름과 주소 등 기본적인 정보가 붙어 있다.

기본 정보는 고정된 필드로 저장된다.

박스의 내부는 처음에는 비어 있지만, 박스보다 더 작은 물건은 그 어떤 것이라도 집어 넣을 수 있으며,

특정한 정보를 속성이라는 이름으로 저장할 수 있다.

MFT 엔트리의 할당 상태는 $MFT파일의 $BITMAP 속성에 기록된다.

- MFT상태값

FILE : 정상적인 엔트리
BAAD : 오류가 난 엔트리

- MFT 활용여부

사용중인지 여부
파일인지 디렉토리인지 여부

- 파일시스템 메타데이터 파일(File System Metadata File)

메타데이터 파일 : 파일시스템 관리 데이터

MTF 엔트리에서 처음 16개의 엔트리를 지칭함

사용자에게는 보이지 않음

"$"로 시작하며, 파일이름에 대문자+소문자를 포함한다.($MFT는 예외)

일반파일이나 디렉토리는 24번 엔트리부터 시작함

엔트리	파일 이름	설명
0	$MFT	MFT 자신을 위한 엔트리를 저장
1	$MFTMirr	MFT 엔트리의 백업본
2	$LogFile	트랜잭션 저널 기록을 저장
3	$Volume	볼륨레이블, 버전 등 볼륨에 관한 정보를 저장
4	$AttrDef	식별자 값, 이름, 크기 등 여러 속성 정보를 저장
5	.	루트 디렉토리를 저장
6	$Bitmap	각 클러스터의 할당 상태를 저장
7	$Boot	부트섹터와 부트코드를 저장
8	$BadClus	불량섹터가 있는 클러스터에 대한 정보를 저장
9	$Secure	파일 보안과 접근 권한에 대한 정보를 저장
10	$Upcase	모든 유니코드 문자의 대문자를 저장
11	$Extend	추가 확장을 위한 파일을 저장하는 디렉토리 (다만, MS는 일반적으로 이 디렉토리 안에 어떠한 파일도 저장하지 않는다)

(13-5) 부트섹터

디스크의 1번째 섹터를 부트섹터라고 한다.

컴퓨터는 0부터 기록하기 때문에 실질적인 부트섹터는 2번째가 된다.

옛날에 사용하던 플로피 디스켓을 포함한 모든 디스크의 첫번째 섹터를 부트섹터라 말한다.

디스크의 첫번째 섹터는 실제로 파티션 정보 등이 기록되는 마스터 부트 레코드(MBR) 이다.

마스터 부트 레코드는 실제로 파티션 정보 등이 기록된다.

부트섹터는 부팅 프로그램을 담을 수 있다. 부트블록 이라고 부르리도 한다.

14. ROW

스토리지 시스템이 기존 데이터를 수정하기 위한 쓰기 요청을 받으면 스토리지 시스템은

새 데이터를 새 위치에 쓰고 수정된 데이터 블록의 포인터를 새 위치로 보냅니다.

15. Data organization - 데이터 구성

스토리지 풀에 생성된 LUN은 메타데이터 볼륨과 데이터 볼륨으로 구성됩니다.

메타데이터 볼륨 : 데이터 구성 정보(LBA, 버전 및 클론 ID)와 데이터 속성을 기록합니다.
논리 블록 주소(LBA)는 논리 블록의 주소를 나타냅니다. 버전은 스냅샷 시점에 해당하며, 클론ID는 데이터 복사본의 수를 나타냅니다.

16. Source volume 소스 볼륨

스냅샷이 필요한 소스 데이터를 저장하는 볼륨입니다.

사용자에게는 소스 LUN또는 기존 스냅샷으로 표현됩니다.

17. Snapshot volume 스냅샷 볼륨

소스 LUN에 대한 스냅샷이 생성된 후 생성된 논리적 데이터 복제본 이다.

스냅샷 볼륨은 사용자에게 스냅샷 LUN으로 표현된다.

스토리지 풀의 단일 LUN은 데이터 구성 양식(LBA, 버전 또는 복제ID)

을 사용하여 동일한 LBA로 여러 데이터 사본을 구성합니다.

스냅샷 볼륨과 소스 볼륨의 공유 메타데이터는 동일한 공유 트리에 저장된다.

18. Snapshot copy 스냅샷 복사

스냅샷이 활성화된 시점에 여러 스냅샷 사본을 얻기 위해 스냅샷을 복사한다.

스냅샷에 데이터가 기록되고 스냅샷 데이터가 변경되면 스냅샷 사본의 데이터는 스냅샷이 활성화된 시점의 스냅샷 데이터와 동일하다.

19. Snapshot cascading 스냅샷 케스케이딩

스냅샷 케스케이딩은 기존 스냅샷에 대한 스냅샷을 만드는 것이다.

스냅샷 복사와 달리 케스케이드는 스냅샷은 소스 스냅샷에 기록된 데이터를 포함하여 특정 시점의 기존 스냅샷에 대한 일관된 데이터 사본이다.이와 대조적으로 스냅샷 복사는 소스 스냅샷이 활성화된 시점의 데이터를 보존하며 소스 스냅샷에 기록된 데이터는 제외한다. 시스템은 최대 8단계 케스케이드 스냅샷을 지원한다.

20. Snapshot consistency group 스냅샷 일관성 그룹

스토리지의 Protection Group(보호 그룹)은 연관된 LUN간의 데이터 일관성을 보장한다.

스토리지는 Protection Group(보호 그룹)에 대한 스냅샷을 지원한다.

즉, 스냅샷은 보호 그룹의 각 멤버 LUN에 대해 동시에 생성된다.

스냅샷 일관성 그룹은 주로 데이터베이스에서 사용한다.

일반적으로 데이터베이스는 서로 다른 LUN에 서로 다른 유형의 데이터를 저장하며 이러한 LUN은 서로 연관되어 있다.

스냅샷을 사용하여 데이터베이스를 백업하려면 동일한 시점에 LUN 스냅샷을 만들어야 데이터가 완전하고 데이터베이스 복구에 사용할 수 있다.

21. Target LUN 대상 LUN

소스 LUN의 스냅샷으로 변환될 LUN이다.

용량은 소스 LUN과 동일하다.

22. Target LUN group 대상 LUN

소스 LUN 그룹의 스냅샷으로 변환될 LUN그룹이다.

대상 LUN 그룹의 LUN 용량과 수량은, 소스 LUN 그룹의 LUN 용량과 수가 동일하다.

1. 개념

스냅샷은 데이터 백업 기술 중 하나이며 사진을 찍는 것과 마찬가지로 스냅샷을 찍는 것은 대상 애플리케이션 상태의 특정 시점 사본을 즉시 만들어 백업 창 없이 데이터 백업을 가능하게 하고, 이를 통해 서비스 연속성 및 데이터 안정성 요구 사항을 충족한다. 스냅샷은 COW(Copy-On-Write) 또는 ROW(Redirect-On-Write) 기술을 사용한다.

2. 정의

HUAWEI HyperSnap은 사용자가 필요할 경우 롤백할 수 있는 원본 데이터(LUN)의 일관적인 시점 복사본을 만들 수 있다.

여기에는 데이터 복사 시점의 소스 데이터의 정적 이미지가 포함된다.

소스 LUN에 대한 스냅샷을 만드는 것 외에도 화웨이 스토리지 시스템은 기존 스냅샷(부모)에 대한 스냅샷(자식)도 만들 수 있다. 이러한 자식 및 부모 스냅샷을 캐스케이딩 스냅샷이라고 하며 HyperSnap은 아래와 같은 장점을 제공한다.

호스트 서비스를 중단하지 않고도 온라인 백업을 지원한다.
성능 저하 없이 쓰기 가능한 ROW 스냅샷을 제공한다.
이전 스냅샷 이후 소스 데이터가 변경되지 않은 경우 스냅샷은 추가적인 저장 공간을 차지하지 않는다. 소스 데이터가 변경된 경우 변경된 데이터를 저장하는 데 소량의 공간만 필요하다.

3. 라이센스 요구사항

HyperSnap을 사용하려면 라이센스가 필요함

4. 작동원리

ROW 스냅샷을 구현하는 작동 원래는 아래와 같습니다.

스냅샷 만들기: 스냅샷이 생성되고 활성화되면 소스 LUN과 동일한 데이터 복사본이 생성된다. 그런 다음 스토리지 시스템은 소스 LUN의 포인터를 스냅샷에 복사하여 스냅샷이 소스 LUN 데이터의 스토리지 위치를 가리키도록 합다. 이를 통해 소스 LUN과 스냅샷이 동일한 LBA를 공유할 수 있다.

소스 LUN에 데이터 쓰기: 스냅샷이 생성된 후 애플리케이션 서버가 소스 LUN에 데이터를 쓸 때 스토리지 시스템은 ROW를 사용하여 새 데이터를 스토리지 풀의 새 위치에 저장하고 소스 LUN의 포인터를 새 위치로 지정한다. 스냅샷 포인터는 여전히 원래 소스 데이터의 스토리지 위치를 가리키므로 스냅샷 생성 시점의 소스 데이터가 저장된다.

스냅샷 데이터 읽기: 스냅샷이 생성된 후 클라이언트 애플리케이션은 스냅샷에 액세스하여 스냅샷 생성 시점에 소스 LUN의 데이터를 읽을 수 있다. 스토리지 시스템은 스냅샷의 포인터를 사용하여 요청된 데이터를 찾아 클라이언트에 반환한다.

HyperSnap은 소스 LUN의 데이터를 빠르게 복구할 수 있도록 지원한다. 실수로 삭제, 손상 또는 바이러스 공격으로 인해 소스 LUN의 데이터가 손실된 경우 스냅샷이 생성된 시점으로 소스 LUN을 롤백하여 데이터 손실을 최소화할 수 있다.

- 스냅샷이 생성되기 전 소스 LUN의 메타데이터 정보를 확인하자.

- 스냅샷 읽기 및 쓰기 프로세스를 확인하자.

원래 볼륨(소스 LUN)과 스냅샷은 모두 매핑 테이블을 사용하여 물리적 공간에 액세스합니다. 소스 LUN의 기존 데이터는 ABCDE 이며 물리적 공간에 순서대로 저장된다. 원래 데이터가 수정되기 전에 스냅샷의 매핑 테이블은 비어 있다. 스냅샷에 대한 모든 읽기 요청은 소스 LUN으로 리디렉션된다.
소스 LUN이 C를 F 로 변경하는 쓰기 요청을 받으면 기존 데이터를 P2 에 덮어쓰는 대신, 새 데이터가 새 물리적 공간 P5 에 기록된다.
데이터가 새 물리적 공간에 쓰여진 후, L2->P2 엔트리가 스냅샷의 매핑 테이블에 추가된다. 그 후 스냅샷의 논리적 주소 L2가 읽히면 읽기 요청이 소스 LUN으로 리디렉션되지 않고, 대신 요청된 데이터는 물리적 공간 P2 에서 직접 읽힌다.
소스 LUN의 매핑 테이블에서 시스템은 L2->P2를 L2->P5 로 변경한다. 소스 LUN의 데이터는 ABFDE 로 변경되고 스냅샷의 데이터는 여전히 ABCDE 이다.