VMWare KB는 주로 두 가지 이유로 인해 오랫동안 실행되는 스냅 샷에 눈살을 찌푸리게됩니다.
수많은 스냅 샷을 생성하면 데이터 저장소가 가득 찰 수 있습니다. 스냅 샷은 단순히 델타 파일입니다. 거의 꽉 찬 50 Gig VMDK가 있고 스냅 샷을 생성한다고 가정 해 보겠습니다. 스냅 샷에서 모든 단일 비트를 뒤집습니다. 델타 파일도 약 50GB입니다. 다시 스냅 샷, 비트, 다른 50 기가 델타 파일을 뒤집습니다. 이것들은 빨리 통제 할 수 없게됩니다.
큰 스냅 샷을 커밋하면 위험이 따릅니다. 스냅 샷을 통합 할 때 델타 변경 사항을 원래 VMDK에 기록합니다. 시간이 걸리고 어떤 일이 발생하면 VMDK를 손상시킬 위험이 있습니다.
그들의 경고는 논리적으로 이해되는 것 같습니다.
그렇게 말하면 내 컴퓨터를 스냅 샷 VMDK에서 영구적으로 실행하는 것이 본질적으로 좋지 않습니까? 내 나무를 다음과 같이 만들고 싶습니다.
- 베이스
- 스냅 1
- 스냅 2
- 당신은 여기에 있습니다
- 스냅 1
기본 시스템을 설치하고 프로비저닝 한 직후 스냅 1과 2가 사용됩니다. 이들은 자주 새로 고칠 계획이므로 트리를 다음과 같이 간단하게 만들 것입니다.
- 베이스
- 스냅 1
- 당신은 여기에 있습니다
- 스냅 2
- 스냅 1
Snap2를 삭제하고 Snap2를 다시 만드십시오.
다음과 같은 이유로 이것이 어떤 영향을 미칠 수 있는지 알 수 없습니다.
단순히 기본 이미지를 설치하고 데이터 저장소를 채울 수있는 방법이 없으면 즉시 델타를 가져갔습니다. 기본 이미지가 10GB (50GB 씬 프로비저닝 디스크)라고 가정 할 때, 델타가 모든 단일 비트를 뒤집 었더라도 총 총 사용량은 60GB (잠긴 10GB 기본 VMDK + 50GB의 델타 인)가 될 수 있습니다 스냅 샷 VMDK 파일). 이것은 더 이상 스냅 샷을 만들지 않는다고 가정합니다.
유스 케이스는 스냅 샷 통합을 요구하지 않으므로 델타를 통합 할 때 오류가 발생하지 않습니다. Snap1으로 돌아가 Snap2를 삭제하면 Snap2에 있던 모든 델타가 단순히 삭제됩니다.
스토리지로드는 정확히 동일하므로 동일한 IOPS를 가져와야합니다. 일부 파일 (주로 시스템 파일)이 원래 VMDK에 존재하고 다른 파일 (베이스 이후의 모든 파일)이 델타에 상주하지만 ESXI가 어떻게 신경 쓰는지 알지 못합니다. 모든 파일은 동일한 물리적 데이터 저장소에 있으므로 성능은 스냅 샷없이 원래 VMDK의 모든 항목을 참조하는 것과 동일해야합니다.
이견있는 사람? RAID가 DAS 인 데이터 저장소가있는 ESXI 5.5.
vCenter 라이센스가 없으므로 템플릿 및 복제 작업이 중단됩니다.
테스트 결과
오늘 테스트를 시작하기 위해 일찍 도착했습니다. 결과는 다음과 같습니다. 성능 저하가 있지만 왜 그런지 잘 모르겠습니다.
스냅 샷 전에 :
스냅 샷 후 :
