IT 관리 / 스토리지

“쓰기 시 복사 vs. 리디렉션” 스냅샷 복구 방식의 이해

W. Curtis Preston | Network World 2023.07.05
스냅샷은 매우 빠른(또는 즉각적인) 복구를 위해 전체 시스템의 가상 복사본을 만드는 데 널리 사용되는 방법이다. 잘 설계된 스냅샷 기반 복구 시스템은 매우 큰 볼륨도 몇 분만에 복구할 수 있으며 대체로 불과 몇 분 전의 시점으로 복구가 가능하다. 반면 같은 크기의 볼륨을 전통적인 방법으로 복원할 경우 많은 시간이 걸리고, 최소한 하루 정도의 데이터를 잃게 된다. 
 
ⓒ Getty Image Bank

스냅샷을 만드는 데는 쓰기 시 복사(copy-on-write)와 쓰기 시 리디렉션(redirect-on-write)의 2가지 방법이 있다. 두 방법은 시스템 성능에 큰 영향을 미치며, 이에 따라 스냅샷을 보관할 수 있는 기간도 영향을 받는다. 두 가지 방법의 장단점에 대해 알아보자. 

여기서는 일반적으로 사용되는 “볼륨”이라는 용어 대신 특정 스냅샷에 의해 보호되는 엔티티를 가리키기 위해 “보호되는 엔티티”라는 용어를 사용한다. 보호되는 엔티티가 일반적으로 RAID 볼륨인 것은 사실이지만, 특정 객체 스토리지 시스템은 RAID를 사용하지 않고 스냅샷을 채용해서 객체 저장소 또는 NAS 공유와 같은 대체 엔티티를 보호할 수 있다. 이 경우 보호되는 엔티티는 여러 디스크 드라이브에 걸쳐 존재할 수 있고 이러한 드라이브가 하나의 RAID 또는 LUN 볼륨에 상주한다는 보장은 없으므로 “보호되는 엔티티”라는 용어를 사용한다. 

모든 스냅샷 유형은 물리적 복사본이 아닌 가상 복사본이라는 공통된 특징을 공유한다. 보호되는 엔티티에 사고가 발생하면 스냅샷 하나만으로는 소용이 없다. 예를 들어 RAID 6 볼륨에서 3중 디스크 장애가 발생하는 경우 스냅샷은 아무런 도움이 되지 않을 것이다. 객체 스토리지 시스템 또는 RAID 대신 이레이저 코딩을 사용하는 모든 스토리지 시스템에는 특정 수의 동시 장애로부터 보호하기 위한 메커니즘이 포함될 수 있지만 그 수를 초과하게 되면 스냅샷은 효과가 없다. 따라서 미디어 장애에 대한 보호를 보장하려면 스냅샷을 다른 기기에 복제하거나 백업하는 것이 필수다. 사실상 가상 복사본에서 물리적 복사본을 만드는 것이다. 

참고로 현재 클라우드 업체가 스냅샷이라는 용어를 사용하고 있는데, 여기서 다루는 스냅샷은 NAS나 스토리지 어레이에 사용되는 것과 같은 전통적인 스냅샷이다. IaaS 업체의 제품을 사용하면서 스냅샷을 생성하는 경우 실질적으로는 그 볼륨의 물리적 복사본을 객체 스토리지에 만드는 것이다. 이는 사실 백업이며, 랜섬웨어 공격 또는 자연 재해로부터 보호하기 위해 다른 지역 및 다른 계정으로 복사해야 한다. 이와 같은 “스냅샷”은 여기서 다루는 스냅샷과는 매우 다르다. 

스냅샷을 만들 때 보호되는 엔티티가 있는 하드 드라이브 어레이에는 아무 일도 일어나지 않는다. 스토리지 시스템은 단순히 보호되는 엔티티의 현재 상태를 저장해야 한다는 점만 기록한다. 쓰기 시 복사와 쓰기 시 리디렉션 스냅샷의 차이는 수정된 블록의 이전 버전을 어떻게 저장하는가에 있으며, 이런 차이는 성능에 큰 영향을 미친다. 
 

쓰기 시 복사의 작동 원리 

쓰기 시 복사 시스템은 새 데이터로 블록을 덮어쓰기 전에 블록을 복제한다. 기본적으로, 보호되는 엔티티 내의 블록을 변경해야 하는 경우 시스템은 블록을 덮어쓰기 전에 별도의 스냅샷 영역으로 블록을 복사한다. 이 접근 방법에서는 스냅샷 쓰기마다 읽기 1번, 쓰기 2번 등 총 3개의 I/O 작업을 사용한다. 블록을 덮어쓰기 전에 이전 값을 읽어서 다른 위치에 쓰고, 이후 새 데이터를 쓴다. 

프로세스에서 나중에 스냅샷 액세스를 시도하는 경우 스냅샷 시스템을 통해 액세스하는데, 스냅샷 시스템은 스냅샷이 생성된 이후 어느 블록이 변경되었는지 인식하고 있다. 스냅샷 시스템은 수정된 블록의 이전 버전을 각각의 스토리지 위치에서 가져오며 수정되지 않은 블록은 원래의 보호되는 엔티티에서 읽는다. 각 블록에 대한 이 의사 결정 프로세스는 상당한 계산 오버헤드를 유발할 수 있다. 
 

쓰기 시 리디렉션의 작동 원리 

반면 쓰기 시 리디렉션 시스템은 포인터를 사용해 모든 보호되는 엔티티를 나타낸다. 블록을 변경해야 하는 경우 스토리지 시스템은 그 블록과 연결된 포인터를 다른 블록으로 리디렉션하고 그곳에 데이터를 쓴다. 스냅샷 시스템은 특정 스냅샷을 구성하는 모든 블록 위치의 레코드를 유지하는데, 이는 사실상 블록 위치에 해당하는 포인터 목록이다. 특정 스냅샷에 액세스하고자 하는 프로세스는 이러한 포인터를 이용해 원래의 위치에서 블록을 가져올 수 있다. 일부 블록이 교체되어 이제 다른 포인터로 표시된다고 해도 스냅샷 프로세스와 아무런 관련이 없다. 따라서 쓰기 시 리디렉션 시스템 내에서 스냅샷 읽기는 계산 오버헤드를 유발하지 않는다. 

쓰기 시 리디렉션 스냅샷은 보호되는 블록을 수정할 때 I/O 작업을 200%까지 줄일 수 있으며(1번 쓰기 대 2번 읽고 1번 쓰기), 스냅샷 읽기에 따르는 부가적인 계산 오버헤드를 없애준다. 반면 쓰기 시 복사 시스템은 보호되는 엔티티의 성능에 상당한 악영향을 미칠 수 있다. 저장된 스냅샷의 수가 많아지고 기간이 길어질수록 보호되는 엔티티에 미치는 성능 영향도 커진다. 이 같은 이유로 쓰기 시 복사 스냅샷은 일반적으로 백업을 위한 임시 소스로 사용된다. 스냅샷을 너무 많이 만들고 장기간 보관할 경우 보호되는 엔티티의 성능이 최대 50%까지 저하될 수 있다. 

스토리지 시스템의 스냅샷 기능을 사용해 다수의 스냅샷을 생성해 장기간 보관할 계획이라면 쓰기 시 리디렉션 시스템이나 이와 비슷한 시스템을 고려해야 한다. 어떤 업체를 선택하든 스냅샷을 어떤 식으로 사용할 것인지 잘 설명하고, 성능에 대한 업체의 우려 사항을 들어보고, 그런 다음 개념 증명 테스트로 업체의 주장을 검증해야 한다. 스냅샷은 좋은 툴이지만 적절한 방법으로 사용해야만 효과를 얻을 수 있다. 
editor@itworld.co.kr
 Tags 스냅샷 백업
Sponsored

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록발행일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.