[번역] A Closer Look at vSAN Snapshots

출처 : https://blogs.vmware.com/virtualblocks/2019/12/04/closer-look-vsan-snapshots/

고객과 자주 대화하는 것은 vSAN 스냅샷이 표준 VMFS 스냅샷과 어떻게 다른지다. 이 글에서는 아키텍처 차이점과 이전 VM 스냅샷 구현과 비교하여 vSAN 성능을 크게 향상시키는 방법을 확인하고자 한다.

vmfsSparse Snapshots

일반적으로 redo 로그 형식이라고 하는 vmfsSparse는 VMware에서 원래 사용하는 스냅샷 형식이다. VMFS, NFS(VAAI-NAS 미포함) 및 vSAN 5.5에서 사용되는 형식이다.

redo 로그 형식을 사용해서 기본 디스크의 스냅샷을 생성하면 하위 델타 디스크가 생성된다. 그런 다음, 부모는 PIT(Point-in-Time) 사본으로 간주된다. VM의 실행 지점은 이제 델타 디스크다. 가상 시스템의 새로운 쓰기는 델타로 이동하지만, 기본 디스크나 체인의 다른 스냅샷은 읽기를 충족한다.

vmfsSparse.png

vmfsSparse/redo 로그 스냅샷의 주요 문제 중 하나는 VM의 성능에 부정적인 영향을 미칠 수 있다는 것이다. 성능 저하는 스냅샷 또는 스냅샷 트리의 사용 기간, 트리의 깊이, VM과 게스트 운영 체제가 스냅샷이 생성된 시점에서 얼마나 변경되었는지에 따라 결정된다. 통합 작업(스냅샷 삭제 또는 변환)은 스냅샷 델타의 양과 기본 vmdk로 롤백해야 하는 변경 사항 수에 따라 매우 많은 시간이 소요될 수 있다.

또한 VM의 전원을 켜는 데 걸리는 시간이 지연될 수 있다. 그렇기 때문에 VMware는 영구적으로 redo 로그 형식을 사용하여 스냅샷에서 프로덕션 가상 머신을 실행할 것을 권장하지 않는다. 그렇기 때문에 VMware KB 문서 KB1025279는 3개 이하의 vmfsSparse 스냅샷과 72시간 이하의 보존 스냅샷을 권장한다.

vsanSparse Snapshots

vSAN을 사용하는 경우 vmfsSparse/redo 로그 개체 대신 VM 스냅샷이 생성되면 vsanSparse 델타 개체가 생성된다.  vsanSparse 스냅샷 형식의 목표는 기존 redo 로그 메커니즘을 계속 사용하면서도 "메모리 내" 메타데이터 캐시와 보다 효율적인 스파스 파일 시스템 레이아웃을 활용하여 스냅샷 성능을 향상시키는 것이다.

vsanSparse의 작동 방식

vSAN을 사용하면 VM이 개체로 구성된다. 델타 디스크(스냅샷) 개체는 그레인(grain)의 집합으로 구성되며, 여기서 각 그레인은 가상 디스크 데이터를 포함하는 섹터의 블록이다. VMDK 개체는 각 델타를 백업한다. 델타는 변경된 그레인만 보관하므로 공간 효율이 높다.

아래 다이어그램에서 기본 디스크 개체는 Disk.vmdk라고 하며 체인의 맨 아래에 있다. 다양한 간격으로 세 개의 스냅샷 개체(Disk-001.vmdk, Disk-002.vmdk, Disk-003.vmdk)가 있으며 게스트 OS 쓰기 역시 다양한 간격으로 발생하여 스냅샷 델타의 변경으로 이어지고 있다.

  • 기본 개체 – 그레인 1,2,3 & 6
  • 델타 객체 디스크-001 – 그레인 1 & 4에 쓰기
  • 델타 객체 디스크-002 – 그레인 2 & 4에 쓰기
  • 델타 객체 디스크-003 – 그레인 1 & 6에 쓰기

writes.png

이제 VM에서 읽으면 다음과 같이 반환된다.

  • 그레인 1 – Delta 개체 디스크-003에서 검색
  • 그레인 2 – 델타 개체 디스크-002에서 검색
  • 그레인 3 – 기본 개체에서 검색
  • 그레인 4 – Delta 개체 디스크-002에서 검색
  • 그레인 5 – Base object에서 검색 – 0이(가) 작성되지 않은 상태로 반환됨
  • 그레인 6 – Delta 개체 디스크-003에서 검색

가상 시스템에 대한 스냅샷이 생성된 경우를 고려한다. 게스트 OS가 디스크에 쓰기를 보낼 때 vsanSparse 드라이버가 쓰기를 수신한다. 쓰기는 항상 스냅샷 체인의 제일 위 객체로 이동한다. 쓰기가 승인되면 vsanSparse 드라이버는 "메모리 내" 메타데이터 캐시를 업데이트하고 게스트 OS에 대한 쓰기를 다시 확인하십시오. 후속 읽기 시 vsanSparse 드라이버는 메타데이터 캐시를 참조할 수 있으며 캐시 적중 시 데이터 블록을 즉시 찾을 수 있다.

vsansparse2.gif

읽기는 스냅샷 트리의 하나 이상의 vsanSparse 델타에서 처리된다. vsanSparse 드라이버는 "메모리 내" 메타데이터 캐시를 확인하여 읽을 델타 또는 델타를 결정한다. 이는 특정 스냅샷 수준에서 기록된 데이터의 부분에 따라 달라진다. 따라서 읽기 I/O 요청을 충족하기 위해 스냅샷 로직은 스냅샷 트리의 모든 델타를 통과하지 않아도 되지만 필요한 vsanSparse 델타로 직접 이동하여 요청된 데이터를 검색할 수 있다. 필요한 데이터가 병렬로 있는 모든 델타에게 읽기가 전송된다.

그러나 캐시 누락 시 vsanSparse 드라이버는 최신 데이터를 가져오기 위해 여전히 각 계층을 통과해야 한다. 이는 요청이 모든 계층에 병렬로 전송된다는 점에서 읽기 요청과 유사한 방식으로 수행된다.

고려 사항

vsanSparse in-memory 캐시는 처음에는 "알 수 없는" 범위가 있다. 즉, 캐시가 차갑다(cold). 알 수 없는 범위에서 읽기 요청이 있을 경우 캐시 누락이 생성된다. 이 범위는 향후 요청을 위해 검색되고 캐시된다. 상상할 수 있듯이, 캐시 누락은 I/O 지연 시간을 증가시킨다.

캐시는 메모리에 저장되어 있으며 영구 스토리지에 대해 약속된 적이 없다. 즉, 호스트에 장애가 발생하거나 VM 전원이 꺼지거나 재부팅되면 캐시가 비게 된다. VM이 반환되어 I/O를 생성하면 캐시가 다시 채워진다.

vmfsSparse 스냅샷과 달리 vsanSparse 스냅샷에는 보존 제한이 없지만 스냅샷을 장기간 사용할 경우 정기적으로 읽기 캐시 사용량 및 vSAN 데이터스토어 용량을 확인하는 것이 좋다.

스냅샷은 훌륭한 툴이지만 스냅샷이 너무 크게 성장하지 않도록 모니터링하는 것이 중요하다. 잠재적인 성능 문제를 방지하려면 VM이 스냅샷에서 실행 중일 때 경고하도록 vCenter Server 경보를 설정하는 것을 고려해 보십시오.

alarm.gif

마치면서

vsanSparse 스냅샷 형식은 vSAN 관리자에게 엔터프라이즈급 스냅샷 및 클론을 제공한다. 기존 redo 로그 메커니즘을 계속 사용하면서도 "메모리 내" 메타데이터 캐시와 보다 효율적인 스파스 파일 시스템 레이아웃을 활용하여 스냅샷 성능을 향상시키는 것을 목적으로 한다. 자세한 내용은 Introduction to vsanSparse snapshots tech note를 참조하기 바란다.

구강사의 간단요약

  • vSAN은 vsanSparse라는 형식을 사용한다. <- ICM 수업에 나온 내용
  • vsanSparse는 vmfsSparse에 비해서 효과적이다. <- vSAN의 키는 캐시 처리
  • 스냅샷은 장시간 및 남용하는 것은 권하지 않는다.
  • 말로만해서는 실행이 잘 안되니, Alarm 기능을 활용해보자!