2019.08.19

긴급 복구란 무엇이며, 어떻게 작동하나? 성능 문제는 없나?

W. Curtis Preston | Network World
긴급 복구의 개념은 비교적 간단하다. 백업으로부터 가상머신(VM)을 직접 실행할 수 있다는 뜻이다. 이렇게 간단한 개념이지만 그 가능성은 사실상 무한하다. 다년간 백업 및 복구 분야의 진전 중에서 긴급 복구를 가장 중요하게 여기는 이유도 바로 여기에 있다.
 
ⓒ Getty Images Bank

긴급 복구가 등장하기 전에는 기본적으로 복원은 모두 똑같았다. 무엇보다 백업본 저장은 모종의 컨테이너나 이미지에 ‘tar,’ ‘cpio,’ ‘dump’의 형식으로 이루어졌다. 그러다가 ‘백업 후 복구’해 주는 상용 소프트웨어가 나오기 시작했다. 

대부분 상용 백업 제품들은 백업본 저장에 그 밖의 형식(주로 자체 고유 형식)을 채택했지만, 백업본을 먼저 복원시키지 않으면 무용지물이라는 점에서 결과는 다를 바 없었다. 복원 과정은 백업 과정과는 역순으로 이루어졌다. 즉, 백업 컨테이너를 열고 적정 파일을 추출하여 적정 위치에 복사하는 것이다.

긴급 복구의 길이 열리기 시작한 것은 일부 백업 회사들이 백업본의 직접 접근을 가능하게 해 주는 백업본 저장 방식을 채택하면서부터였다. 자체 고유 형식이든 아니든 컨테이너 안에 백업본이 갇혀 있는 일이 사라졌다. 그 결과, 파일 시스템 백업본을 먼저 복원할 필요 없이 직접 설치할 수 있게 되었다. 예를 들면, 일부 백업 시스템에서는 백업된 VMDK를 ‘VMDK로’ 직접 접근하는 것이 가능해졌다. VM웨어를 사용해 VM을 부팅할 수 있다는 뜻이다.

애초에 개별 파일의 신속한 복구를 위해 개발되었던 것이 곧 더 많은 기능으로 발전되었다. 백업본을 실제 시스템으로 설치하라는 명령을 백업 시스템에 내리기만 하면 VM의 백업본 상태를 쉽게 확인할 수 있는 길이 고객들에게 최초로 열렸다. 복원하기 전까지는 백업본 상태를 절대 알 수 없다는 대전제가 무너진 것이다. 이를 계기로 확실히 판도가 바뀌었다.
 

성능 문제

일반적인 복구 설정에서 나타나는 성능 특성을 이해하는 것이 중요한데, 여러 가지 설계상의 이유로 복구 시스템은 생산 시스템에 비해 성능이 낮을 수밖에 없기 때문이다.

첫번째 문제는 하이퍼바이저는 VMDK 이미지가 아닌, 백업 제품이 제공하는 가상 이미지를 읽는다는 점이다. 이 가상 이미지를 제공하려면 사용 중인 제품과 선택한 백업본 버전에 따라 꽤 많은 백업 시스템 작업이 소요될 수 있다. 따라서, 성능이 중요할 때에는 즉각 부팅된 이미지의 수를 제한할 것이 대부분 백업 시스템에서 권장된다. 

긴급 복구가 일반적으로 고성능이 아닌 두 번째 이유는 VMDK가 보조 스토리지에 있기 때문이다. 기본 시스템은 올-플래시 어레이(all-flash array: AFA)로 많이 이동한 반면, 오늘날 백업 시스템은 아직 그보다 속도가 훨씬 느린 SATA를 사용 중이다. 

긴급 복구 시스템에서 고성능을 방해하는 마지막 요소는 중복 제거 형식으로 저장되는 백업본이 많다는 점이다. 중복 제거 형식의 파일을 이미지로 제공하려면 처리 능력이 꽤 많이 소요되므로 시스템 성능이 저하된다. 일부 중복 제거 시스템에서는 가장 최신의 복사본을 중복 제거가 아닌 방식으로 저장할 수 있어서 긴급 복구 설정 속도가 훨씬 빨라진다.
 

긴급 복구의 작동 방식은?

고객들이 생산이나 테스트를 위해 백업본을 직접 설치할 수 있는 단계에 도달한 것은 대단한 위업이었다. 첫번째 큰 변화는 백업본을 ‘tar’나 다른 업체의 자체 고유 이미지처럼 컨테이너 내부에 저장할 수는 없기에 직접 접근이 가능한 상태로 저장해야 했다는 점이다. 또한, 데이터 위에는 해당 데이터의 여러 가지 뷰에 접근할 수 있는 방식으로 모종의 드라이버를 탑재해야 했다. 그래야만 VM의 백업본에 여러 시점으로부터 접근할 수 있기 때문이다. 가장 중요한 것은 VM이 실제로 실행되려면 이 드라이버에 읽기 쓰기 접근권이 있어야 한다는 점이다. 즉, 백업본의 직접 뷰가 아닌 ‘가상’ 뷰가 제공되어야 한다는 뜻이다. 그렇지 않으면, 백업본으로부터 VM을 실행할 때 백업본에 실제로 덮어쓰는 일이 발생한다.

위와 같은 일이 다 달성되고 나면, 백업 시스템은 적정 VMDK의 가상 뷰를 하이퍼바이저에게 제공해 주어야 한다. 이 작업은 일반적으로 NFS를 통해 이루어진다. 하이퍼바이저는 이를 데이터 저장본으로 인식하고 VM을 가져와 실행하도록 허용한다.

위에서 언급한 성능 특성으로 인해, VM은 일시적으로만 실행된다. 만일 VM이 장기적으로 필요하다면, 일반적인 VM 저장 위치로 복원시켜야 한다. 복원 작업은 스토리지 v모션(Storage vMotion)과 같은 것을 사용해서 할 수 있다.
 

긴급 복구로 할 수 있는 일은?

백업 테스트는 많은 사람이 꼽는 최고의 긴급 복구 기능 활용법이다. 단순히 특정 VM을 설치하는 수준을 넘어선다. 적절한 부팅 순서로 복구 그룹들을 만들고 여러 개의 VM을 같이 부팅함으로써 전체에 대한 복구 테스트가 가능한 백업 제품들도 있다. 그러한 테스트 덕분에 평범한 백업 관리자가 얼마나 안심하게 될지 상상할 수 있다.

긴급 복구가 원래의 설계 용도로 가장 많이 사용된다. 즉, 불투명한 VM 이미지로부터 파일 수준의 복구를 하는 것이다. VM 백업본 내부로부터 파일 수준 복구를 할 수 있는 백업 제품도 있지만 일부 고객들은 그러한 방법 대신 이 복구 방법을 선호한다.

VM 긴급 복구의 또 다른 활용 방법은 생산 VM을 테스트 등 다른 목적으로 다른 위치에 복사하는 것이다. 이번에도 마찬가지로, VM의 백업본을 다른 데이터 저장소나 하이퍼바이저로 복원할 수 있는 백업 제품이 대부분이지만, 일부 고객들은 그 작업에 다른 도구를 선호한다. 특정 VM의 VMDK에 직접 접근하는 것이 바로 이러한 고객들이 원하는 기능이다.

VM이 손상된 경우 해당 VM 전체를 복구할 때에도 긴급 복구를 제한적으로 사용할 수 있다. 예를 들어, 해당 VM의 VM 감쇠를 누군가 잘못해서 삭제하거나 손상한 경우, 백업본으로부터 해당 VM를 신속히 실행할 수 있다면 그 실수를 바로 잡으면서 비교적 빨리 복구가 가능하다. 단, 긴급 복구가 전체 DR 시스템의 자리를 대신하지는 않는다. 긴급 복구 작동 방식의 성능 특성 때문이다.

긴급 복구는 제안요청서를 발송할 때 ‘필수’ 체크리스트에 포함하는 고객이 많아질 정도로 인기가 크게 높아졌다. 긴급 복구를 사용해 매일 밤 자동으로 전체 백업을 테스트한다면 백업 시스템이 제대로 작동한다는 신뢰감이 크게 높아진다. 또한, 누군가 실수로 삭제한 VM를 즉각 부팅시켜 보인다면 얼마나 능력 있어 보일지 상상할 수 있다. 긴급 복구는 백업 시스템이 인식되는 방식을 확실히 변화시킨다.

*W. Curtis Preston은 1993 년부터 백업, 스토리지, 복구 전문가로 일했다. 그는 최근 클라우드 기반 데이터 보호 업체인 드루바(Druva)에 합류했다. ciokr@idg.co.kr
 


2019.08.19

긴급 복구란 무엇이며, 어떻게 작동하나? 성능 문제는 없나?

W. Curtis Preston | Network World
긴급 복구의 개념은 비교적 간단하다. 백업으로부터 가상머신(VM)을 직접 실행할 수 있다는 뜻이다. 이렇게 간단한 개념이지만 그 가능성은 사실상 무한하다. 다년간 백업 및 복구 분야의 진전 중에서 긴급 복구를 가장 중요하게 여기는 이유도 바로 여기에 있다.
 
ⓒ Getty Images Bank

긴급 복구가 등장하기 전에는 기본적으로 복원은 모두 똑같았다. 무엇보다 백업본 저장은 모종의 컨테이너나 이미지에 ‘tar,’ ‘cpio,’ ‘dump’의 형식으로 이루어졌다. 그러다가 ‘백업 후 복구’해 주는 상용 소프트웨어가 나오기 시작했다. 

대부분 상용 백업 제품들은 백업본 저장에 그 밖의 형식(주로 자체 고유 형식)을 채택했지만, 백업본을 먼저 복원시키지 않으면 무용지물이라는 점에서 결과는 다를 바 없었다. 복원 과정은 백업 과정과는 역순으로 이루어졌다. 즉, 백업 컨테이너를 열고 적정 파일을 추출하여 적정 위치에 복사하는 것이다.

긴급 복구의 길이 열리기 시작한 것은 일부 백업 회사들이 백업본의 직접 접근을 가능하게 해 주는 백업본 저장 방식을 채택하면서부터였다. 자체 고유 형식이든 아니든 컨테이너 안에 백업본이 갇혀 있는 일이 사라졌다. 그 결과, 파일 시스템 백업본을 먼저 복원할 필요 없이 직접 설치할 수 있게 되었다. 예를 들면, 일부 백업 시스템에서는 백업된 VMDK를 ‘VMDK로’ 직접 접근하는 것이 가능해졌다. VM웨어를 사용해 VM을 부팅할 수 있다는 뜻이다.

애초에 개별 파일의 신속한 복구를 위해 개발되었던 것이 곧 더 많은 기능으로 발전되었다. 백업본을 실제 시스템으로 설치하라는 명령을 백업 시스템에 내리기만 하면 VM의 백업본 상태를 쉽게 확인할 수 있는 길이 고객들에게 최초로 열렸다. 복원하기 전까지는 백업본 상태를 절대 알 수 없다는 대전제가 무너진 것이다. 이를 계기로 확실히 판도가 바뀌었다.
 

성능 문제

일반적인 복구 설정에서 나타나는 성능 특성을 이해하는 것이 중요한데, 여러 가지 설계상의 이유로 복구 시스템은 생산 시스템에 비해 성능이 낮을 수밖에 없기 때문이다.

첫번째 문제는 하이퍼바이저는 VMDK 이미지가 아닌, 백업 제품이 제공하는 가상 이미지를 읽는다는 점이다. 이 가상 이미지를 제공하려면 사용 중인 제품과 선택한 백업본 버전에 따라 꽤 많은 백업 시스템 작업이 소요될 수 있다. 따라서, 성능이 중요할 때에는 즉각 부팅된 이미지의 수를 제한할 것이 대부분 백업 시스템에서 권장된다. 

긴급 복구가 일반적으로 고성능이 아닌 두 번째 이유는 VMDK가 보조 스토리지에 있기 때문이다. 기본 시스템은 올-플래시 어레이(all-flash array: AFA)로 많이 이동한 반면, 오늘날 백업 시스템은 아직 그보다 속도가 훨씬 느린 SATA를 사용 중이다. 

긴급 복구 시스템에서 고성능을 방해하는 마지막 요소는 중복 제거 형식으로 저장되는 백업본이 많다는 점이다. 중복 제거 형식의 파일을 이미지로 제공하려면 처리 능력이 꽤 많이 소요되므로 시스템 성능이 저하된다. 일부 중복 제거 시스템에서는 가장 최신의 복사본을 중복 제거가 아닌 방식으로 저장할 수 있어서 긴급 복구 설정 속도가 훨씬 빨라진다.
 

긴급 복구의 작동 방식은?

고객들이 생산이나 테스트를 위해 백업본을 직접 설치할 수 있는 단계에 도달한 것은 대단한 위업이었다. 첫번째 큰 변화는 백업본을 ‘tar’나 다른 업체의 자체 고유 이미지처럼 컨테이너 내부에 저장할 수는 없기에 직접 접근이 가능한 상태로 저장해야 했다는 점이다. 또한, 데이터 위에는 해당 데이터의 여러 가지 뷰에 접근할 수 있는 방식으로 모종의 드라이버를 탑재해야 했다. 그래야만 VM의 백업본에 여러 시점으로부터 접근할 수 있기 때문이다. 가장 중요한 것은 VM이 실제로 실행되려면 이 드라이버에 읽기 쓰기 접근권이 있어야 한다는 점이다. 즉, 백업본의 직접 뷰가 아닌 ‘가상’ 뷰가 제공되어야 한다는 뜻이다. 그렇지 않으면, 백업본으로부터 VM을 실행할 때 백업본에 실제로 덮어쓰는 일이 발생한다.

위와 같은 일이 다 달성되고 나면, 백업 시스템은 적정 VMDK의 가상 뷰를 하이퍼바이저에게 제공해 주어야 한다. 이 작업은 일반적으로 NFS를 통해 이루어진다. 하이퍼바이저는 이를 데이터 저장본으로 인식하고 VM을 가져와 실행하도록 허용한다.

위에서 언급한 성능 특성으로 인해, VM은 일시적으로만 실행된다. 만일 VM이 장기적으로 필요하다면, 일반적인 VM 저장 위치로 복원시켜야 한다. 복원 작업은 스토리지 v모션(Storage vMotion)과 같은 것을 사용해서 할 수 있다.
 

긴급 복구로 할 수 있는 일은?

백업 테스트는 많은 사람이 꼽는 최고의 긴급 복구 기능 활용법이다. 단순히 특정 VM을 설치하는 수준을 넘어선다. 적절한 부팅 순서로 복구 그룹들을 만들고 여러 개의 VM을 같이 부팅함으로써 전체에 대한 복구 테스트가 가능한 백업 제품들도 있다. 그러한 테스트 덕분에 평범한 백업 관리자가 얼마나 안심하게 될지 상상할 수 있다.

긴급 복구가 원래의 설계 용도로 가장 많이 사용된다. 즉, 불투명한 VM 이미지로부터 파일 수준의 복구를 하는 것이다. VM 백업본 내부로부터 파일 수준 복구를 할 수 있는 백업 제품도 있지만 일부 고객들은 그러한 방법 대신 이 복구 방법을 선호한다.

VM 긴급 복구의 또 다른 활용 방법은 생산 VM을 테스트 등 다른 목적으로 다른 위치에 복사하는 것이다. 이번에도 마찬가지로, VM의 백업본을 다른 데이터 저장소나 하이퍼바이저로 복원할 수 있는 백업 제품이 대부분이지만, 일부 고객들은 그 작업에 다른 도구를 선호한다. 특정 VM의 VMDK에 직접 접근하는 것이 바로 이러한 고객들이 원하는 기능이다.

VM이 손상된 경우 해당 VM 전체를 복구할 때에도 긴급 복구를 제한적으로 사용할 수 있다. 예를 들어, 해당 VM의 VM 감쇠를 누군가 잘못해서 삭제하거나 손상한 경우, 백업본으로부터 해당 VM를 신속히 실행할 수 있다면 그 실수를 바로 잡으면서 비교적 빨리 복구가 가능하다. 단, 긴급 복구가 전체 DR 시스템의 자리를 대신하지는 않는다. 긴급 복구 작동 방식의 성능 특성 때문이다.

긴급 복구는 제안요청서를 발송할 때 ‘필수’ 체크리스트에 포함하는 고객이 많아질 정도로 인기가 크게 높아졌다. 긴급 복구를 사용해 매일 밤 자동으로 전체 백업을 테스트한다면 백업 시스템이 제대로 작동한다는 신뢰감이 크게 높아진다. 또한, 누군가 실수로 삭제한 VM를 즉각 부팅시켜 보인다면 얼마나 능력 있어 보일지 상상할 수 있다. 긴급 복구는 백업 시스템이 인식되는 방식을 확실히 변화시킨다.

*W. Curtis Preston은 1993 년부터 백업, 스토리지, 복구 전문가로 일했다. 그는 최근 클라우드 기반 데이터 보호 업체인 드루바(Druva)에 합류했다. ciokr@idg.co.kr
 


X