(이 질문은 특히 Hyper-v에 관한 것이지만 Hyper-v에 대한 특정 답변이 그러한 일반적인 설명에 적용되지 않는 한 실제로 일반화된 VM 스냅샷 답변에 관심이 있습니다.)
저는 적당한 규모의 VM 인프라(VM 수천 개)를 갖춘 대기업에서 일하고 있습니다. 내 서버 엔지니어 중 한 명이 VM 스냅샷을 매우 오랫동안 저장하는 것을 허용하지 않는다고 말했습니다. VM에 중요한 변경을 하기 전에 대체 수단으로 스냅샷을 찍을 수는 있지만 곧 삭제해야 한다고 합니다. 그 후(며칠 정도 지나면 변경 사항이 아무 것도 중단하지 않는다는 것을 확신하게 됩니다).
나는 그 절차에 만족합니다. 스냅샷이 실제 백업 등의 프록시 역할을 할 것이라고 기대하지 않습니다. 그리고 환경에서 공간을 절약하려는 그들의 바람을 존중할 수 있습니다. 내가 동의하지 않는 것은 그의 추론입니다. 그는 나중에 스냅샷을 삭제해야 하는 이유는 "스냅샷이 무제한으로 커질 수 있기 때문에 HDD에 쓸 때마다 제한 없이 스냅샷에 추가 데이터를 쓰기 때문입니다. 이는 원래 가상 HDD를 프로비저닝할 때와 다릅니다. 여기서는 최대 크기를 지정할 수 있습니다. 스냅샷의 최대 크기는 지정할 수 없습니다."
제가 이해한 바로는 스냅샷 이미지는 상위 디스크 이미지의 DELTA입니다. 예를 들어, 원본 이미지에 다음과 같은 블록이 있는 경우:
0101 0101 0101
... 그런 다음 중간 섹션을 다음과 같이 다시 작성합니다.
0101 1111 0101
... 그런 다음 스냅샷은 둘 사이의 차이점만 저장합니다(복잡성을 추가하는 일부 데이터 구조 오버헤드도 있지만 스토리지 관점에서는 중요하지 않음). 게다가 내가 가게 된다면 이해해고쳐 쓰기해당 블록을 원래 상태로 되돌리면 델타는 해당 블록을 삭제합니다(해당 블록에 대한 향후 읽기는 원본 이미지를 통해 읽혀지도록).
(저는 스냅샷이 차이점을 저장하는 방법에 대해 잘 모릅니다. 모든 것을 체계적으로 유지하는 데 필요한 매우 복잡한 구조가 있다고 확신합니다. 차이점을 저장한다는 원칙에만 관심이 있지만 그렇지 않습니다. 변경 사항의 "실행 기록"입니다.)
그는 스냅샷이 그런 식으로 작동하지 않는다고 말했습니다. 그는 데이터 블록이 있으면 이를 변경하고 다시 변경하며, 이 작업을 수행할 때마다 스냅샷이 커져서 결국 많은 양을 소모하게 된다고 말했습니다. 디스크 공간.
스냅샷은 원본 이미지의 크기를 결코 초과할 수 없으며(예를 들어 문자 그대로 HDD의 모든 단일 비트를 뒤집으면 델타가 이를 저장하게 됨) 일정한 오버헤드 크기도 있을 수 있다는 것이 제가 이해한 바입니다. 그는 이것이 사실이 아니며, 가상 HDD에 쓰기가 점점 더 많이 이루어짐에 따라 VM 스냅샷이 무제한으로 커질 것이라고 생각하는 것 같습니다.
VM 스냅샷 작동 방식에 대해 제가 잘못 이해하고 있는 걸까요?
답변1
엔지니어들이 모범 사례를 따르고 있지만 이유는 잘못되었습니다. VHDX(또는 사용 중인 가상 디스크 기술)가 다음을 수행한다는 점에서는 맞습니다.
- 완전히 새로 작성하는 대신 재작성 시 작성된 블록을 재사용하세요.
- 상위 가상 디스크에 대해 구성된 최대 크기와 동일한 크기 제한을 설정하십시오. 스냅샷의 최대 크기를 지정할 수 없는 이유는 상위 VHDX가 이미 이를 지정했기 때문입니다.
그러나 블록이 원래 상태로 반환되면 이전에 작성된 델타를 삭제하는 메커니즘을 알지 못합니다. 소스 및 델타 블록에서 차이 알고리즘을 실행하는 것과 단순한 블록 쓰기 기록을 유지하는 것의 성능 오버헤드는 상대적으로 작은 규모에서도 상당합니다.
하지만 VM에 디스크 변동이 많이 발생하지 않는 한 스냅샷이 심각하게 커지는 것을 볼 수 없을 것입니다.
단일 스냅샷이 있는 VM도 심각한 성능 손실이 없지만 어디에도 언급된 내용은 없습니다.
스냅샷에는 세 가지 실제 문제가 있습니다.
- 환경 문제로 인해 AVHDX 디스크가 분리될 수 있음
- 스냅샷이 존재하는 매 순간은 "가치 있는 것"에서 "책임"으로 스펙트럼을 따라 이동합니다.
- 데이터가 중복되지 않습니다
또한 스냅샷 자체가 무제한으로 확장될 수 없더라도 스냅샷을 제어할 수 없는 환경을 상상해 보십시오. 단일 스냅샷은 이론적으로 상위 스냅샷의 할당 크기를 두 배로 늘릴 수 있습니다. 저는 Microsoft가 VM당 스냅샷 50개라는 하드 캡을 설정했다고 생각합니다. 하지만 이는 기술에서 요구하기 때문이 아니라 "괜찮아 이제 바보 같군요"라는 일종의 안전 장치로만 설정한 것입니다. 따라서 VM의 이론적 상한은 할당 크기의 51배입니다. 그런 일이 일어날 가능성은 없지만 여러 개의 스냅샷이 포함된 몇 개의 VM만 있어도 스토리지 관리자가 얼마나 골치 아픈 일을 겪을 수 있는지 알 수 있습니다. 이는 합리적인 스냅샷 사용 제한을 설정하는 데 확실히 유리합니다.
스냅샷의 환경 문제
이 범주에는 많은 것들이 문제의 근본 원인이 될 수 있습니다. 이 모든 문제는 하나의 근본적인 문제로 귀결됩니다. 즉, 상위 VHDX가 다음에서 수정되는 경우입니다.어느그렇다면 AVHDX는 완전히 무효화되고 전혀 쓸모가 없습니다. 소유하는 VM의 전원이 켜져 있으면 그러한 수정이 엄청나게 어려울 것입니다. 그러나 소유하는 VM이 꺼져 있으면 상위 VHDX는 파일일 뿐입니다. Hyper-V 또는 다른 시스템은 하위 AVHDX에 액세스하려고 시도할 때까지 아무 문제도 없다는 것을 알 수 없습니다.
스냅샷이 오래 존재할수록 문제가 발생할 가능성이 높아집니다. 특히 관리자가 여러 명인 환경에서는 더욱 그렇습니다. VM에 여러 개의 스냅샷이 있는 경우 문제가 잠재적으로 복잡해집니다.
이 문제는 스냅샷에만 국한되지 않습니다. 이러한 문제는 모든 가상 디스크 차이점 보관용 시스템에서 발생할 수 있습니다.
시간이 지남에 따라 스냅샷의 가치가 하락합니다.
이것이 스냅샷을 오랫동안 보관하지 않는 주된 이유입니다. 당신이 올바르게 추측했듯이, 차분 메커니즘은 다음을 수행합니다.~ 아니다변경 사항에 대한 역사적 기록을 유지합니다. 블록에 대한 가장 최근 변경 사항만 유지됩니다. 따라서 현재 스냅샷 이후 형태로 존재하는 가상 머신과 스냅샷을 생성할 당시 존재했던 VM만 남게 됩니다. 이전 버전으로 되돌리거나 새 버전을 유지할 수 있습니다. 중간은 없습니다.
논쟁의 여지가 있고 이러한 일이 발생했기 때문에 모든 것이 단일 가상 머신에서 실행되는 소규모 Exchange 환경이 있다고 가정해 보겠습니다. Exchange 2013에서 Exchange 2016으로 업그레이드하기 전에 스냅샷을 찍고 1년 동안 실행합니다. 그 스냅샷이 무슨 소용이 있나요? 다시 돌아가시겠습니까? 병합을 삭제할 때 병합 시간이 얼마나 걸릴지 추측해 보세요.
스냅샷은 데이터를 중복하지 않습니다
스냅샷의 목적은 가상 머신을 특정 시점으로 빠르게 되돌리는 것입니다. 이는 가상 머신의 상태를 직접 수정하여 수행됩니다. 어떤 경우에도 데이터를 복제하지 않습니다. AVHDX가 손상된 경우 상위 항목만 유효한 정보를 보유하며 스냅샷이 손실된 이후 변경된 내용은 모두 손실됩니다. 상위 VHDX가 손상되면 두 파일 모두 쓸모가 없습니다. 또한 저는 AVHDX에 들어가서 변경된 데이터만 가져올 수 있는 도구를 알지 못합니다. 따라서 의미 있는 기간 동안 다양한 상태를 유지하려면 백업이 최선의 선택입니다. 스냅샷만큼 작업이 빠르거나 편리하지는 않지만 다른 모든 문제를 해결합니다.