스냅샷(Snapshot) 기술의 발전을 이해하기 위한 글

컴퓨터 기술과 네트워크 기술의 지속적인 발전으로 정보 기술 수준이 지속적으로 향상되었습니다. 인류가 21세기 정보사회에 진입한 이후 디지털 통신, 디지털 멀티미디어, 전자상거래, 검색엔진, 디지털 도서관, 일기예보, 지질탐사, 과학연구 등 방대한 데이터 기반의 응용이 등장하고 다양한 정보 프레젠테이션 폭발적인 성장 추세, 스토리지는 정보 컴퓨팅 기술의 중심이 되었습니다. 스토리지 시스템에 대한 애플리케이션의 요구 사항은 계속해서 증가하고 스토리지 용량은 GB에서 TB, PB 및 EB로 계속 업그레이드되며 점점 더 커지고 있습니다.

튜링상 수상자 짐 그레이는 네트워크 환경에서 18개월마다 생성되는 데이터의 양은 역사상 데이터의 양의 합과 같다는 새로운 경험 법칙을 제안했습니다. 동시에 현대 기업의 컴퓨터 의존도는 심각하게 높아졌고 정보 데이터는 점차 기업 생존의 기반이 되었으며 데이터 손상이나 손실은 기업에 막대한 손실을 가져올 것입니다. 해커, 바이러스, 하드웨어 장비의 고장, 화재, 지진 등의 자연재해로 인해 시스템 및 데이터 정보가 손상되거나 심지어 파괴되기까지 하므로 이를 제때 복구하지 않으면 기업에 막대한 손실을 입힐 수 있습니다. , 백업 재해 복구 기술이 특히 중요해 보입니다. 특히 9.11과 같은 사건으로 인한 참사로 인해 사람들은 데이터 정보의 가치와 중요성을 더욱 깊이 인식하고 데이터 보호에 점점 더 많은 관심을 갖게 되었습니다.

지난 20년 동안 컴퓨터 기술이 크게 발전했지만 데이터 백업 기술은 크게 발전하지 못했습니다. 데이터 백업 작업의 비용과 비용은 여전히 ​​상대적으로 높고 많은 시간과 시스템 리소스를 소비하며 데이터 백업의 복구 시간 목표 및 복구 지점 목표는 상대적으로 깁니다. 전통적으로 사람들은 중요한 데이터 정보를 보호하고 데이터를 정기적으로 백업하거나 복제하기 위해 데이터 복제, 백업 및 복구와 같은 기술을 사용해 왔습니다. 데이터 백업 프로세스는 애플리케이션 성능에 영향을 미치고 시간이 많이 걸리므로 일반적으로 데이터 백업은 시스템 부하가 적은 시간(예: 야간)에 수행되도록 예약됩니다. 또한 저장 공간을 절약하기 위해 일반적으로 전체 및 증분 백업 기술이 결합됩니다.

분명히 이 데이터 백업 방법에는 상당한 결함, 즉 백업 윈도우의 문제가 있습니다. 데이터 백업 기간 동안 기업 비즈니스는 외부 서비스 제공을 일시적으로 중단해야 합니다. 엔터프라이즈 데이터 볼륨 및 데이터 증가율이 가속화됨에 따라 이 창은 점점 더 길어질 수 있으며 이는 중요한 비즈니스 시스템에 허용되지 않습니다. 은행, 통신 등 기관의 경우 정보 시스템은 24x7 무중단 운영이 필요하며, 단기 다운타임이나 소량의 데이터 손실은 막대한 손실을 초래합니다. 따라서 데이터 백업 윈도우를 최대한 줄이거 나 아예 0으로 줄이는 것이 필요하다. 그러한 요구 사항을 충족합니다.

스냅샷이란 무엇입니까(Snapshot)

스냅샷(Snapshot)은 데이터 세트의 완전하고 사용 가능한 사본인 즉석 복사라고도 하는 특정 시점의 데이터 세트의 미러 이미지입니다. 스토리지 네트워크 산업 협회 SNIA는 스냅샷을 다음과 같이 정의합니다. 특정 시점(복사가 시작되는 시점)에 해당 데이터의 이미지를 포함하는 지정된 데이터 세트의 전체 사용 가능한 복사본. 스냅샷은 스냅샷이 나타내는 데이터의 복제본이거나 데이터의 복제본일 수 있습니다.

스냅샷은 백업 소스, 데이터 마이닝 소스, 애플리케이션 상태를 저장하기 위한 체크포인트 또는 단순한 데이터 복제 수단과 같은 광범위한 애플리케이션을 가지고 있습니다. 스냅샷을 생성하는 방법도 여러 가지가 있는데, SNIA의 정의에 따르면 스냅샷 기술은 주로 분할 미러, 변경된 블록, 동시의 세 가지 범주로 나뉩니다. 후자의 두 가지는 일반적으로 포인터 재매핑 및 copy on write 기술을 사용하여 구현됩니다. 변경된 블록 방식의 유연성과 저장 공간 사용의 높은 효율성으로 인해 스냅샷 기술의 주류가 되었습니다.

스냅샷의 첫 번째 유형은 미러 분할입니다. 데이터 미러링은 인스턴트 복사 이전에 구성되며 복제를 위한 완전한 미러링이 가능할 때 미러링을 즉시 "분리"하여 인스턴트 복사를 생성할 수 있습니다. 이 기술의 장점은 빠르고 스냅샷 생성을 위한 추가 작업이 필요하지 않다는 것입니다. 그러나 단점도 명백하다 첫째, 유연성이 없고 스냅샷을 아무 때나 찍을 수 없다는 점, 둘째, 데이터 볼륨과 동일한 용량의 미러 볼륨이 필요하다, 셋째, 지속적인 미러 데이터 변경이 전체 성능에 영향을 미친다는 점이다. 스토리지 시스템.

스냅샷의 두 번째 유형은 블록을 변경하는 것입니다. 스냅샷이 성공적으로 생성된 후 소스와 타겟은 데이터가 기록될 때까지 동일한 물리적 데이터 복사본을 공유하며, 이때 소스 또는 타겟이 새 스토리지 공간에 기록됩니다. 공유 데이터 단위는 블록, 섹터, 섹터 또는 기타 세분화된 수준일 수 있습니다. 블록 변경 및 복제 정보를 기록하고 추적하기 위해서는 비트맵(bitmap)이 필요하며, 이를 통해 실제 복사된 데이터의 위치를 ​​파악하고 데이터를 소스에서 가져올지 타겟에서 가져올지 여부를 결정합니다.

스냅샷의 세 번째 유형은 동시입니다. 블록을 변경하는 것과 매우 유사하지만 항상 물리적으로 데이터를 복사합니다. 인스턴트 복사를 수행하면 데이터가 복사되지 않습니다. 대신, 데이터가 복사된 방법을 기록하는 비트맵을 생성하고 백그라운드에서 데이터의 실제 물리적 복사를 수행합니다.

다양한 스토리지 수준의 스냅샷 구현

이미지 설명

그림 1 스토리지 시스템 스택 및 스냅샷 구현

스토리지 스택은 그림 1과 같이 호스트 운영 체제에서 실행되는 애플리케이션 시스템에 물리적 스토리지 미디어를 제공하는 하드웨어 및 소프트웨어 구성 요소 집합으로 구성됩니다. 스냅샷은 다양한 방법으로 구현할 수 있으며 스토리지 스택의 여러 레벨에서도 구현할 수 있으며 크게 소프트웨어 계층과 하드웨어 계층의 두 가지 유형으로 나눌 수 있으며 컨트롤러 기반 스냅샷과 호스트 기반 스냅샷으로 나눌 수도 있습니다. 기반 스냅샷.

컨트롤러 기반 스냅샷은 스토리지 장치 계층 또는 하드웨어 계층에서 구현되며 스토리지 시스템 하드웨어 공급자가 관리하고 디스크 어레이에 통합됩니다. 이 스냅샷은 운영 체제 및 파일 시스템과 관계없이 LUN 수준(블록 수준)에서 수행됩니다. 호스트 기반 스냅샷은 장치 드라이버와 파일 시스템 수준 간에 구현되며 일반적으로 파일 시스템, 볼륨 관리자 또는 타사 소프트웨어에서 수행됩니다. 이 유형의 스냅샷은 스토리지 하드웨어가 아닌 파일 시스템 및 볼륨 관리 소프트웨어에 의존합니다. 이 스냅샷은 물리적 데이터에 작용하는 컨트롤러 기반 스냅샷과 달리 논리적 데이터 보기에 작용합니다.

위의 스토리지 레벨 중에서 물리적 스토리지 계층과 볼륨 관리자는 스냅샷 구현에 가장 적합한 두 가지 구성 요소이며 물리적 스토리지를 쉽게 활용할 수 있으며 현재 주류 구현 레벨입니다. 파일 시스템 계층에서 스냅샷을 구현하는 것은 실행 가능한 옵션이지만 데이터베이스와 같은 애플리케이션은 파일 시스템 계층에서 스냅샷 기술로 관리할 수 없기 때문에 스냅샷을 구현하기 위해 논리 볼륨을 사용하도록 직접 선택합니다. 일반적으로 응용 프로그램 계층에서 스냅샷을 구현할 필요가 없습니다.백업 메커니즘의 경우 기본 파일 시스템 또는 볼륨 관리자 인터페이스를 사용하여 구현할 수 있지만 스냅샷 데이터의 일관성을 보장하기 위해 응용 프로그램을 일시적으로 중지해야 합니다. 일반적으로 소프트웨어 계층 기반 스냅샷은 작동하기 쉽고 더 나은 복구를 제공하는 반면 하드웨어 계층 기반 스냅샷은 더 높은 성능과 내결함성을 갖는 경향이 있습니다.

스냅샷 구현 방법 및 기술

스냅샷 기술은 데이터의 실시간 이미지를 실현할 수 있으며 스냅샷 이미지는 온라인 백업을 지원할 수 있습니다. 전체 스냅샷은 모든 데이터의 완전한 읽기 전용 복사를 달성하는 것입니다.스냅샷이 차지하는 저장 공간을 줄이기 위해 사람들은 쓰기 중 복사(COW, Copy-On-Write) 및 쓰기 리디렉션(ROW, Redirecton)을 제안했습니다. 쓰기) 스냅샷 기술 . 또한 스냅샷의 성능을 향상시킬 수 있는 로그 및 지속적인 데이터 보호와 같은 스냅샷 기술의 다른 구현이 있습니다.

1. 미러 분리(SplitMirror)

미러 분할 스냅샷 기술은 먼저 스냅샷 시점이 도래하기 전에 원본 데이터 볼륨에 대한 완전한 물리적 미러 볼륨을 생성하고 유지합니다. 동일한 데이터의 두 복사본이 원본 데이터 볼륨과 미러 볼륨으로 구성된 미러 쌍에 각각 저장됩니다. 스냅샷 시점이 되면 미러링 작업을 중지하고 미러링된 볼륨을 스냅샷 볼륨으로 변환하여 데이터 스냅샷을 얻는다. 스냅샷 볼륨이 데이터 백업과 같은 애플리케이션을 완료한 후 소스 데이터 볼륨과 다시 동기화되고 다시 미러 볼륨이 됩니다.

여러 개의 연속적인 시점 스냅샷을 동시에 유지해야 하는 소스 데이터 볼륨의 경우 미리 미러 볼륨을 여러 개 생성해야 하며, 첫 번째 미러 볼륨을 데이터 백업으로 스냅샷 볼륨으로 변환하면 처음 생성된 두 번째 미러 볼륨 원본 데이터 볼륨과 동기화하고 원본 데이터 볼륨과 새로운 미러 쌍이 됩니다. 미러 분할의 스냅샷 작업 시간은 매우 짧습니다. 미러 볼륨 쌍을 분리하는 데 필요한 시간은 일반적으로 몇 밀리초에 불과합니다. 이러한 작은 백업 창은 상위 계층 응용 프로그램에 거의 영향을 미치지 않지만 이 스냅샷 기술은 유연성이 부족하고 생성할 수 없습니다. 모든 시점의 모든 데이터 볼륨에 대한 스냅샷. 또한 원본 데이터 볼륨과 동일한 용량의 미러 볼륨이 하나 이상 필요하며 미러링이 동기화되면 스토리지 시스템의 전반적인 성능이 저하됩니다.

이미지 설명

그림 2 기록 중 복사 스냅샷

Copy-on-write 스냅샷은 스냅샷 생성을 위해 미리 할당된 스냅샷 공간을 사용합니다. 스냅샷 시점 이후에는 물리적 데이터 복사가 발생하지 않으며 원본 데이터의 물리적 위치에 대한 메타데이터만 복사됩니다. 따라서 스냅샷 생성이 매우 빠르고 순식간에 완료될 수 있습니다. 그런 다음 스냅샷 사본은 원본 볼륨의 데이터 변경 사항을 추적합니다.(즉, 원본 볼륨 쓰기 작업) 원본 볼륨 데이터 블록이 처음으로 업데이트되면 원본 볼륨 데이터 블록을 먼저 읽고 스냅샷에 씁니다. 그런 다음 원래 볼륨을 새 데이터 블록으로 덮어씁니다(그림 2). Copy-on-write, 따라서 이름입니다.

이 스냅샷 기술은 스냅샷 생성 시 스냅샷 볼륨만 생성하지만, 스냅샷 시점 이후 업데이트된 데이터를 소스 데이터 볼륨에 저장하기 위해 상대적으로 적은 양의 저장 공간만 할당하면 된다. 각 소스 데이터 볼륨에는 데이터 포인터 테이블이 있고 각 레코드에는 해당 데이터 블록에 대한 포인터가 있습니다. 스냅샷을 생성할 때 스토리지 하위 시스템은 원본 데이터 볼륨의 포인터 테이블 복사본을 스냅샷 볼륨의 데이터 포인터 테이블로 생성합니다. 스냅샷 시점이 종료되면 스냅샷은 상위 계층 응용 프로그램에서 액세스할 수 있는 논리적 복사본을 생성합니다.스냅샷 볼륨과 소스 데이터 볼륨은 각각의 포인터 테이블을 통해 동일한 물리적 데이터를 공유합니다. 스냅샷이 생성된 후 소스 데이터 볼륨의 일부 데이터가 업데이트되려고 할 때 스냅샷 작업의 무결성을 보장하기 위해 기록 중 복사 기술이 사용됩니다. 스냅샷 볼륨의 데이터에 접근하기 위해서는 데이터 포인터 테이블을 질의하여 해당 데이터 블록의 포인터에 따라 접근한 데이터의 물리적 저장 위치를 ​​결정한다.

copy-on-write 기술은 복사 작업이 업데이트 작업 전에 발생하도록 하여 스냅샷 시점 이후의 데이터 업데이트가 스냅샷 볼륨에 나타나지 않도록 하여 스냅샷 작업의 무결성을 보장합니다. Copy-on-write 스냅샷은 스냅샷 시점 이전에 스토리지 리소스를 차지하지 않으며 시스템 성능에 영향을 미치지 않으며 매우 유연하게 사용할 수 있으며 모든 데이터 볼륨에 대해 언제든지 스냅샷을 생성할 수 있습니다. 스냅샷 시점에 생성되는 "백업 윈도우"의 길이는 소스 데이터 볼륨의 용량에 선형적으로 비례하며, 일반적으로 몇 초 정도이며 이는 애플리케이션에 거의 영향을 미치지 않지만 스냅샷 볼륨에 할당된 저장 공간은 매우 큽니다. 감소; 원본 데이터 볼륨이 업데이트될 때만 발생하므로 시스템 오버헤드가 매우 적습니다. 그러나 스냅샷 볼륨은 원본 데이터 볼륨의 업데이트된 데이터만 저장하기 때문에 이 스냅샷 기술은 완전한 물리적 복사본을 얻을 수 없으며 완전한 물리적 복사본이 필요한 응용 프로그램을 만났을 때 할 수 있는 일이 없으며, 업데이트된 데이터가 예약된 공간을 초과하면 스냅샷이 무효화되어 손실됩니다.

이미지 설명

그림 3 포인터 재매핑 스냅샷

이 구현은 원본 데이터 볼륨에 대한 첫 번째 쓰기 작업이 예약된 스냅샷 공간으로 리디렉션된다는 점을 제외하면 기록 중 복사와 매우 유사합니다. 스냅샷은 모든 소스 및 사본 데이터에 대한 포인터를 유지합니다. 데이터를 다시 쓰면 업데이트된 데이터에 대한 새 위치가 선택되고 데이터에 대한 포인터가 업데이트된 데이터를 가리키도록 다시 매핑됩니다. 복사본이 읽기 전용이면 데이터에 대한 포인터가 전혀 수정되지 않습니다. 리디렉션된 쓰기 작업은 스냅샷 I/O 성능을 향상시킵니다. 새로운 데이터를 스냅샷 볼륨에 직접 쓰고 동시에 비트맵 매핑 포인터를 업데이트하는 데 한 번의 쓰기 작업만 필요합니다. 쓰기 중 복사에는 한 번의 읽기와 두 번의 쓰기가 필요합니다. 즉, 원래 볼륨의 데이터 블록을 읽고 스냅샷 볼륨에 쓰고 업데이트된 데이터는 원래 볼륨에 씁니다.

스냅샷 볼륨이 원본을 저장하고 원본 볼륨이 스냅샷 복사본을 저장하는 것을 찾는 것은 어렵지 않습니다. 이로 인해 스냅샷을 삭제하기 전에 스냅샷 볼륨의 데이터를 원본 볼륨과 동기화해야 하며, 여러 스냅샷이 생성되면 원본 데이터에 대한 액세스, 스냅샷 볼륨과 원본 볼륨 데이터의 추적, 스냅샷 삭제는 매우 복잡해집니다. 또한 스냅샷 복사본은 원본 복사본에 종속되며 원본 복사본 데이터 세트는 빠르게 조각화됩니다.

4. 로그 구조 파일 구조

이 형태의 스냅샷 기술은 로그 파일을 활용하여 원본 데이터 볼륨에 쓰기 작업을 기록합니다. 원본 데이터 볼륨에 대한 모든 쓰기 작업은 로그 시스템에 기록되며 이는 각 데이터 변경에 대한 스냅샷을 생성하는 것과 같습니다. 따라서 이는 데이터베이스 시스템 트랜잭션 또는 파일 시스템 로그와 매우 유사하며 로그에서 데이터를 복구하거나 필요에 따라 트랜잭션을 합리적인 상태로 롤백할 수 있습니다. 엄밀히 말하면 이 방법은 스냅샷이라고 할 수 없지만 실제로 스냅샷의 목표를 달성할 수 있으며 ZFS, JFS, EXT3, NTFS 등과 같은 많은 파일 시스템에서 이 기능을 실현했습니다.

5. 클론 스냅샷(백그라운드 복사로 복사 쓰기)

위에서 언급한 스냅샷은 기본적으로 완전한 스냅샷 사본을 생성하지 않으므로 완전한 물리적 데이터 사본의 비즈니스 요구를 충족할 수 없습니다. 클론 스냅샷은 원본 데이터 볼륨과 일치하는 미러 스냅샷을 생성할 수 있으며 COW(Copy-On-Write) 및 미러 분할 스냅샷 기술의 이점을 최대한 활용합니다. 스냅샷 시점에서 우선 copy-on-write 방식을 사용하여 스냅샷 복사본을 빠르게 생성한 다음 백그라운드에서 복사 프로세스를 시작하여 원본 데이터 볼륨에서 스냅샷 볼륨으로 블록 수준 데이터 복사 작업을 수행합니다. . 복제가 완료되면 미러 분할 기술을 통해 클론 스냅샷을 얻을 수 있습니다. 클론 스냅샷은 또한 분할 미러 스냅샷의 단점을 상속합니다 소스 데이터 볼륨의 용량과 동일한 스냅샷 볼륨을 요구하는 것 외에도 스토리지 시스템의 전체 성능에 어느 정도 영향을 미칩니다.

6. 지속적인 데이터 보호

위의 스냅샷 기술에는 모두 공통적인 단점이 있습니다. 즉, 어느 시점에서든 원하는 만큼 많은 스냅샷을 생성할 수 없다는 것입니다. 로그형 스냅샷은 위와 같은 단점은 없으나 특정 파일 시스템에 의존하고 다른 파일 시스템을 사용하는 애플리케이션에 바로 적용할 수 없으며, 파일 시스템을 기반으로 하지 않는 데이터 애플리케이션에는 무력하다.

지속적인 백업이라고도 하는 지속적인 데이터 보호는 원본 데이터 볼륨 데이터 블록의 변경 사항을 자동으로 지속적으로 캡처하고 이러한 데이터 블록의 버전을 지속적으로 완전하게 기록합니다. 모든 데이터 블록 변경 사항은 스냅샷 시점에 스냅샷을 생성하는 다른 스냅샷 기술과 달리 즉각적인 스냅샷을 생성하기 위해 기록됩니다. 모든 쓰기 작업이 기록되고 저장되기 때문에 어느 시점에서든 데이터 상태에 동적으로 액세스할 수 있어 세분화된 데이터 복구를 제공하고 즉각적인 복구가 가능하며 복구 지점 대상을 효과적으로 줄일 수 있습니다. 블록 수준의 지속적인 데이터 보호 기술의 장점은 애플리케이션과의 느슨한 결합, 고성능 및 효율성, 연속적이고 중단 없는 시스템 운영, 스냅샷 창 문제가 없다는 것입니다. 단점은 상대적으로 높은 저장 공간이 필요하다는 점이며, 이는 블록 수준의 지속적인 데이터 보호 기술의 광범위한 적용을 제한하는 근본적인 이유이기도 합니다.

다음 표에서는 위의 스냅샷 기술을 다양한 관점에서 분석하고 비교합니다.

결론 및 전시

스냅샷 기술은 기존 데이터 백업 및 복제 기술에 대한 주요 혁신으로, 백업 윈도우의 문제를 해결하고 복구 시간 목표와 복구 시점 목표를 효과적으로 단축하며 사실상의 스토리지 업계 표준이 되었습니다.

스냅샷 기술이 발명된 이후로 사람들은 많은 중요한 개선을 이루었습니다. 스냅샷 창은 몇 초에서 순식간에 계속 축소됩니다. 스냅샷은 거의 언제든지 생성할 수 있으며 세분화가 미세해지고 숫자가 증가합니다. 스냅샷의 성능이 크게 향상되고 호스트와 응용 프로그램에 미치는 영향은 마이크로로 축소, 스냅샷의 유연성, 확장성 및 관리 용이성이 지속적으로 향상됩니다. 그러나 기술 진보에 대한 사람들의 요구는 끝이 없었습니다. 다양한 현재 솔루션의 경우 스냅샷 기술은 포괄적인 성능, 유연성 및 관리 용이성 측면에서 여전히 개선의 여지가 많습니다. 스토리지 공급업체는 계속해서 새로운 스냅샷 스토리지 제품 또는 새로운 버전을 출시하고 있으며 이는 가장 강력한 증거입니다.

【참조】

【참조】

【1】Snapshot.

http://www.snia.org/education/dictionary/s/#snapshot

【2】Point in time copy. 

http://www.snia.org.cn/dic.php?word=p

【3】Alain AzagIIry, Michael E Factor, Julian Satran. Point-in-time copy，Yesterday, Today and Tomorrow[C]. College Park, USA: the 19th IEEESymposium on Mass Storage Systems. 2002:259-270.

【4】Snapshot.  

http://www.ibm.com/developerworks/tivoli/library/t-snaptsm1/index.html

【5】Yuan Xiaoming, Lin An.여러 주류 스냅샷 기술의 분석 및 비교.Microprocessor, No.1, 2008.

【6】Wang Shupeng, Yun Xiaochun, Guo Li.A Review of the Development of Continuous Data Protection (CDP) Technology.Information Technology Letters, Volume 6, Issue 6, 2008.

【7】EMCTimeFinder. 

http://china.emc.com/products/detail/software/timefinder.htm

【8】EMCTimeFinder.

http://china.emc.com/collateral/software/data-sheet/1700-timefinder.pdf

【9】HDSShadowImage. 

http://www.hds.com/cn/products/storage-software/shadowimage-in-system-replication.html

【10】NetAppSnapshot. 

http://www.netapp.com/us/products/platform-os/snapshot.html

【11】VeritasSnapshot. 

http://eval.symantec.com/mktginfo/enterprise/yellowbooks/using_local_copy_services_03_2006.en-us.pdf 

——End——