VMware vSAN

VMware KB : Top 20 article for vSAN

VMware Support Insider에 올라오는 Top 20 articles for vSphere의 KB를 정리

VMware KB : Top 20 article for vSAN

[번역] Changing the default repair delay time for a host failure in vSAN (2075456)

출처 : https://kb.vmware.com/s/article/2075456

제목 : vSAN에서 호스트 장애시 기본 복구 지연시간 변경 (2075456)

목적

이 문서는 VMware vSAN(이전의 Virtual SAN)에서 복구 지연 시간을 변경하는 단계가 나와 있다. 이 시간은 vSAN 클러스터에 속한 ESXi 호스트에서 장애가 감지된 후 디스크 구성 요소를 복구하기 전에 vSAN이 대기하는 시간이다.

원인

이 VMware vSAN 고급 설정은 호스트가 실패한 상태 또는 유지 보수 모드에 있는 후 vSAN이 디스크 개체를 재구성하기 전에 대기하는 시간을 지정한다. 기본적으로 복구 지연 값은 60분으로 설정되며, 이는 호스트에 장애가 발생할 경우 vSAN이 특정 호스트에 있는 디스크 개체를 다시 빌드하기 전에 60분을 기다린다는 것을 의미한다. 이는 vSAN이 장애가 일시적인지 아니면 영구적인지 확실하지 않기 때문이다.

SSD(Solid State Disk) 또는 MD(Magnetic Disk)와 같은 물리적 하드웨어 구성 요소에서 장애가 감지되면 vSAN은 즉시 디스크 개체를 재구축하여 응답한다.

해결

아래 단계는 vSAN 6.x에 대해 여전히 유효하지만 필요한 경우 vSAN 상태 플러그인의 즉시 개체 복구 버튼을 사용하여 즉시 복구를 시작할 수 있다.

기본 복구 지연 시간을 변경하려면 ESXi 고급 옵션 vsan.clomrepairdelay를 수정한다.

기본 60분은 다양한 구성을 포함하도록 설계되었으며, 위의 옵션을 너무 공격적으로 설정하면 불필요한 재동기화 작업이 발생할 수 있으며, 이 고급 옵션을 변경할 때 다음 요소를 고려한다.
- ESXi 업데이트 설치(업데이트를 수행하는 경우)
- ESXi 호스트 부팅 시간(전원 켜기 자체 테스트 포함)
- vSAN에 대한 SSD 로그 복구

참고: 클롬 수리(clom repair) 지연에 대해 설정할 수 있는 최대값은 4294967295이다.

vSAN 6.7 U1 이상

vSAN 6.7 U1에서 vCenter에서 "Clom Repair" 값을 변경하는 옵션이 도입됨 따라서 vCenter를 사용할 수 있는 경우 클러스터 개체 > Configure > vSAN > Services > Advanced 옵션:

rtaImage.png

Object Repair Timer 옵션을 원하는 값으로 변경:

rtaImage-2.png

UI를 통해 위에서 변경한 후 Maintenance/Disk Group/Disk/reboot 관련 작업을 진행하기 전에 최소 180초 이상 기다린다.

이전 버전의 vSAN과 마찬가지로 GUI를 사용하는 경우 명령줄을 통해 clomd 서비스를 다시 시작할 필요가 없음

vSAN 6.7 GA 이하인 경우

복구 지연 시간을 변경하려면 vSAN 클러스터의 각 ESXi 호스트에서 다음 단계를 실행한다.

1. 각 ESXi 호스트에 대한 SSH 세션을 연다. 자세한 내용은 ESXi 5.x(2004746년)에서 ESXi Shell 사용을 참조한다.

2. 복구 지연 시간을 변경하려면 다음 esxcli 명령을 실행한다.

esxcli system settings advanced set -o /VSAN/ClomRepairDelay -i <value in minutes>

또는 다음 esxcfg 명령을 사용할 수 있다.

esxcfg-advcfg --set <Value in minutes> /VSAN/ClomRepairDelay

ClomRepairDelay 값을 매우 낮게 설정하면 호스트가 재부팅되거나 일시적으로 네트워크가 중단되어 ESXi 호스트가 네트워크 파티셔닝될 때 구성 요소의 불필요한 복사가 발생할 수 있다.

다음 명령을 실행해서 CLOM(Cluster Level Object Manager) 서비스 clomd를 다시 시작해서 변경 내용을 적용한다.

/etc/init.d/clomd restart

clomd 서비스를 다시 시작하면 CLOM 작업이 잠시 중단된다. 정전 기간은 1초 미만이 되어야 한다. 그러나 clomd 서비스가 재시작될 때 가상 시스템을 프로비저닝하는 경우 해당 프로비저닝 작업이 실패할 수 있다.

4. vSAN 클러스터의 각 ESXi 호스트에 1~3단계를 적용한다.

VMware vSphere Web Client를 사용하여 복구 지연 시간을 변경하려면 vSAN 클러스터의 각 ESXi 호스트에서 다음 단계를 실행한다.

    1. vSphere Web Client를 사용하여 VMware vCenter Server에 관리자 자격 증명을 사용하여 로그인한다.
    2. vSAN 클러스터를 선택하고 ESXi host > Manage > Settings을 강조 표시한다.
    3. Advanced System Settings > VSAN.ClomRepairDelay를 선택한다.
    4. Edit을 누른다.
    5. VSAN.ClomRepairDelay 값(분 단위)을 수정한다.
      /etc/init.d/clomd restart

      clomd 서비스를 다시 시작하면 CLOM 작업이 잠시 중단된다. 정전 기간은 1초 미만이 되어야 한다. 그러나 clomd 서비스가 재시작될 때 가상 시스템을 프로비저닝하는 경우 해당 프로비저닝 작업이 실패할 수 있다.

    6. 다음 명령을 실행해서 CLOM(Cluster Level Object Manager) 서비스 clomd를 다시 시작해서 변경 내용을 적용한다.
    7. VSAN 클러스터의 각 ESXi 호스트에 1~6단계를 적용한다.
향후 고려 사항

고장이 해결된 후에는 설정을 기본값인 60분으로 재설정해야 한다. 위의 단계를 참조로 사용한다.

 

VMware KB : Top 20 article for vSAN

[번역] vSAN Performance Graphs in the vSphere Web Client (2144493)

출처 : https://kb.vmware.com/s/article/2144493

제목 : vSphere Web Client에서 vSAN Performance Graphs (2144493)

목적

이 자료에서는 vSAN(이전의 Virtual SAN) 6.2 이상에서 사용할 수 있는 vSAN 성능 그래프를 설명한다.

해결

vSAN 성능 그래프/차트를 가져오려면 먼저 vSAN 성능 서비스를 사용하도록 설정해야 한다.

서로 다른 수준의 엔티티(클러스터, 호스트, 디스크 그룹, 물리적 디스크, 가상 시스템 및 가상 디스크)와 다른 관점(가상 시스템 사용, vSAN 백엔드)에서 성능 변경을 볼 수 있다.

vSAN 성능을 이해하기 위해 모니터링할 수 있는 그래프가 여러 개 있다. 사용 가능한 모든 vSAN 성능 그래프의 세부 정보는 다음과 같다.

영문 문서의 표 참조 : https://kb.vmware.com/s/article/2144493#ClusterPerf

 

VMware KB : Top 20 article for vSAN

[번역] Images converted from Qcow2 and other formats do not boot successfully on VMware Integrated OpenStack running on VSAN storage (2144687)

출처 : https://kb.vmware.com/s/article/2144687

제목 : VSAN 스토리지(에서 실행되는 VMware Integrated OpenStack에서 Qcow2 및 기타 형식에서 변환된 이미지가 성공적으로 부팅되지 않는다 (2144687)

증상

raw 또는 qcow2와 같은 비 네이티브 형식에서 변환된 이미지를 VSAN 스토리지에서 실행하는 경우 다음 증상 중 하나 이상을 경험한다.

목적

이 문제는 다음과 같은 경우에 발생한다.

해결

이는 VMware VIO(Integrated OpenStack) 2.0.x에 영향을 미치는 알려진 문제다.

이 문제를 해결하려면:

1. 이미지를 임시로 저장하기에 충분한 스토리지가 있는 Ubuntu 14.04 가상 시스템을 생성한다.

2. qemu-utils 버전 2.5를 설치한다.

debian 패키지를 다운로드하여 설치 : https://packages.debian.org/sid/qemu-utils

또는 원본에서 빌드하려면 https://github.com/qemu/qemu/releases/tag/v2.5.0으로 이동한다. 이미지 작성 방법은 https://github.com/qemu/qemu을 참조한다.

3. 다음 qemu-img convert 명령을 실행하여 업데이트된 qemu 이진 파일을 사용하여 qcow2 이미지를 vmdk 이미지로 변환한다.

qemu-img convert -f qcow2 -O vmdk -o subformat=streamOptimized source_qcow_image_path destination_path_to_vmdk

예:

qemu-img convert -f qcow2 -O vmdk -o subformat=streamOptimized CentOS-7-x86_64-GenericCloud-1503.qcow2 CentOS-7-x86_64-GenericCloud-1503.vmdk

4. 다음 스크립트를 사용하여 변환된 이미지에 포함된 vmdk 버전 설정을 업데이트한다.

printf '\x03' | dd conv=notrunc of=<vmdk file name> bs=1 seek=$((0x4))

예:

printf '\x03' | dd conv=notrunc of=CentOS-7-x86_64-GenericCloud-1503.vmdk bs=1 seek=$((0x4))

 

VMware KB : Top 20 article for vSAN

[번역] Correlating VxRAIL Release with VMware build numbers (52075)

출처 : https://kb.vmware.com/s/article/52075

제목 : Correlating VxRAIL Release with VMware build numbers (52075)

목적

이 문서는 VXRAIL 버전, VXRAIL Manager 버전을 vCenter Server, ESXI 및 vSAN 빌드 번호와 비교한다. 종종 EMC TSE에 클러스터를 나중 빌드로 업그레이드하도록 제안한다. 해당 VxRail 버전을 사용하여 vCenter Server 및 ESXi 호스트를 업그레이드할 수 있도록 EMC TSE를 올바른 VxRail 버전과 공유한다.

VxRAIL Appliance의 경우 오프라인 번들/VUM을 통해 호스트 및 vCenter Server를 직접 업그레이드할 수 없으며, 모든 업그레이드는 VxRAIL Manager를 통해 수행되어야 함

해결

영문 문서의 표 참조 : https://kb.vmware.com/s/article/52075

 

VMware KB : Top 20 article for vSAN

[번역] Understanding vSAN memory consumption in ESXi 6.0 U3, 6.5.0d, and later (2113954)

출처 : https://kb.vmware.com/s/article/2113954

제목 : Understanding vSAN memory consumption in ESXi 6.0 U3, 6.5.0d, and later (2113954)

목적

이 문서에서는 vSAN 6.2(ESXi 6.0 업데이트 3 이상) 및 vSAN 6.6(ESXi 6.5.0d 이상)의 최신 버전에서 메모리 소비량에 대한 정보를 제공하고 예제 시나리오를 제공한다.

해결

vSAN 메모리 소비량을 계산하려면 다음과 같은 방정식을 사용할 수 있다.

vSANFootprint = HOST_FOOTPRINT + NumDiskGroups * DiskGroupFootprint

DiskGroupFootprint = DISKGROUP_FIXED_FOOTPRINT + DISKGROUP_SCALABLE_FOOTPRINT + CacheSize * CACHE_DISK_FOOTPRINT + NumCapacityDisks * CAPACITY_DISK_FOOTPRINT

HOST_FOOTPRINT: 디스크 그룹에 관계없이 각 ESXi 호스트에 대해 vSAN에서 사용하는 메모리 양

NumDiskGroups: 호스트의 디스크 그룹 수(범위 1-5)

DiskGroupFootprint: 호스트의 각 개별 디스크 그룹에 할당된 메모리 양.

NumCapacityDisks: 각 디스크 그룹의 용량 디스크 수입니다.

Capacity_DISK_FOOTPRINT: 디스크 크기에 관계 없이 용량 디스크당 할당된 메모리 양.

DISKGROUP_FIXED_FOOTPRINT: 호스트의 각 개별 디스크 그룹에 할당된 고정 메모리 양.

DISKGROUP_SCALABLE_FOOTPRINT: ESXi 호스트의 물리적 메모리 양을 기준으로 각 개별 디스크 그룹에 할당된 메모리 양

CacheSize: 캐시 디스크 크기(GB)(SSD의 경우 0~600, 하이브리드 0~2TB)

CASE_DISK_FOOTPRINT: 캐시 디스크의 GB당 할당된 메모리 양.

상수
HOST_FOOTPRINT = 7100 MB
CAPACITY_DISK_FOOTPRINT = 160 MB (ALL_FLASH)
CACHE_DISK_FOOTPRINT = 20 MB (ALL_FLASH)
DISKGROUP_FIXED_FOOTPRINT = 1360 MB (ALL_FLASH) *
CAPACITY_DISK_FOOTPRINT = 180 MB (HYBRID)
CACHE_DISK_FOOTPRINT = 10 MB (HYBRID)
DISKGROUP_FIXED_FOOTPRINT = 1610 MB (HYBRID)
DISKGROUP_SCALABLE_FOOTPRINT = 0.5% of system memory **

중복 제거 기능이 설정된 디스크 그룹의 경우 디스크 그룹당 120MB의 추가 비용이 발생한다.
하이브리드 구성의 경우 확장 가능한 설치 공간은 시스템 메모리의 0.5% 또는 캐시 디스크 크기의 0.2% 중 더 작은 것이 될 것이다.

모든 플래시의 캐시 디스크는 600GB로 제한되므로 600GB보다 큰 SSD를 사용하면 추가 메모리를 소비하지 않는다.

방정식은 호스트의 디스크 그룹 간에 디스크 수와 크기가 동일한 동종 디스크 그룹을 가정한다. 디스크 그룹의 경우 디스크 그룹 풋프린트는 각 디스크 그룹을 개별적으로 계산하고 집계해야 한다.

호스트 SSD 크기가 600GB인 몇 가지 작업 예를 들어보자. 각 디스크 그룹은 256GB의 시스템 메모리를 가진 호스트에 3개의 MD(또는 All Flash Case용 데이터 디바이스)를 가지고 있다.

예 1: 호스트당 하나의 디스크 그룹, 하이브리드 구성:

공식:

HOST_FOOTPRINT + ( NumDiskGroups * ( DISKGROUP_FIXED_FOOTPRINT + DISKGROUP_SCALABLE_FOOTPRINT + ( CacheSize * CACHE_DISK_FOOTPRINT) + NumCapacityDisks * CAPACITY_DISK_FOOTPRINT)))

예:

7100 + (1610 + 1228 + 600 * 10 + 3 * 180) = 16478 MB

예 2: 호스트당 3개의 디스크 그룹, 하이브리드 구성:

공식:

HOST_FOOTPRINT + NumDiskGroups * (DISKGROUP_FIXED_FOOTPRINT + DISKGROUP_SCALABLE_FOOTPRINT + CacheSize * CACHE_DISK_FOOTPRINT + NumCapacityDisks * CAPACITY_DISK_FOOTPRINT)

예:

7100 + 3 * (1610 + 1228 + 600 * 10 + 3 * 180) = 35234 MB

예 3: 호스트당 하나의 디스크 그룹, 올플래시 구성:

공식:

HOST_FOOTPRINT + NumDiskGroups * (DISKGROUP_FIXED_FOOTPRINT + DISKGROUP_SCALABLE_FOOTPRINT + CacheSize * CACHE_DISK_FOOTPRINT + NumCapacityDisks * CAPACITY_DISK_FOOTPRINT)

예:

7100 + (1360 + 1310 + 600 * 20 + 3 * 160) = 22250 MB

예4: 호스트당 3개의 디스크 그룹, 중복제거 구성:

공식:

HOST_FOOTPRINT + NumDiskGroups * (DISKGROUP_FIXED_FOOTPRINT + DISKGROUP_SCALABLE_FOOTPRINT + CacheSize * CACHE_DISK_FOOTPRINT + NumCapacityDisks * CAPACITY_DISK_FOOTPRINT)

예:

7100 + 3 * (1360 + 120 + 1310 + 600 * 20 + 3 * 160) = 52910 MB

관련 정보

vSAN 클러스터에 참여하는 호스트의 메모리 요구 사항을 계산할 때 고려할 사항:

VMware KB : Top 20 article for vSAN

[번역] vSAN "Proactive rebalance" and "Automatic Rebalance" (2149809)

출처 : https://kb.vmware.com/s/article/2149809

제목 : vSAN "Proactive rebalance" and "Automatic Rebalance" (2149809)

목적

이 문서의 목적은 vSAN의 "Proactive Rebalance and Automatic Rebalance"이 적용될 수 있는 경우에 대해 설명하는 것이다.

디스크가 상태 점검에서 클러스터 균형이 맞지 않고, 공간 사용량이 많은 디스크가 있음을 나타내는 오류를 보고하는 경우 vSAN 버전을 기반으로 공간 사용량을 위해 디스크 전체로 로드를 분산하기 위해 사전/자동 재조정을 실행해야 할 수 있다.

Proactive Rebalance : VC GUI의 vSAN Health 플러그인을 통해 또는 RVC 콘솔을 통해 vSAN 클러스터의 개체 재조정을 수동으로 시작한다. 이 기능은 vSAN 6.7 U2 이상에서만 지원된다.

Automatic Rebalance : vSAN 6.7 U3 이후부터는 사전 재조정을 수동으로 트리거할 필요가 없다. 클러스터 전체 구성 및 임계값 설정을 통해 모든 재조정 작업을 자동화할 수 있다.

해결

Proactive Rebalance : vSAN 클러스터 균형이 맞지 않을 경우 수동 재조정 실행이 필요할 수 있다. 이 작업은 과도하게 사용된 Disk에서 활용도가 낮은 Disk로 구성 요소를 이동시킨다. 수동 재조정을 수행할 때 이 작업은 24시간 동안 실행되었다가 중지된다.

수동 재조정 실행은 일부 시스템 리소스를 활용하며 이 프로세스를 완료하는 데 몇 시간이 걸릴 수 있다. 이는 클러스터 간 디스크 사용량 분산을 줄이기 위해 재조정해야 하는 개체 수에 따라 달라진다.
vSAN 성능 차트를 모니터링하여 워크로드가 최소일 때 사전 리밸런싱을 실행하는 것이 좋다.

vSphere 6.7 U2 이하에서 사전 예방적 균형 재조정을 실행하려면:

  1. vSphere Web Client에서 vSAN 클러스터로 이동한다.
  2. Monitor 탭을 누르고 vSAN을 누른다.
  3. Health를 누른다.
  4. vSAN 상태 서비스 테이블에서 Warning: Virtual SAN Disk Balance를 선택한다. 호스트의 디스크 밸런스를 검토할 수 있다.
  5. 클러스터를 재조정하려면 Rebalance Disks 버튼을 클릭한다.

이 작업은 몇 시간이 걸릴 수 있다.

RVC(사용되지 않음)를 사용하여 릴리스에서 Proactive Rebalance을 실행하려면:

  1. RVC(Ruby vSphere Console)에 로그인한다.
  2. 컴퓨터 네임스페이스로 변경한다.
  3. 재조정해야 하는 데이터 양을 확인하려면 vSAN 클러스터에서 다음 명령 실행:
    vsan.proactive_rebalance_info <vSAN-cluster-number, or "." for current rvc path location>

출력은 다음과 같이 나타난다:

/localhost/Test-DC/computers/Test-CL> vsan.proactive_rebalance_info .
2019-08-16 19:31:08 +0000: Retrieving proactive rebalance information from host esxi-3.labs.org ...
2019-08-16 19:31:08 +0000: Retrieving proactive rebalance information from host esxi-1.labs.org ...
2019-08-16 19:31:08 +0000: Retrieving proactive rebalance information from host esxi-2.labs.org ...
2019-08-16 19:31:09 +0000: Fetching vSAN disk info from esxi-3.labs.org (may take a moment) ...
2019-08-16 19:31:09 +0000: Fetching vSAN disk info from esxi-2.labs.org (may take a moment) ...
2019-08-16 19:31:09 +0000: Fetching vSAN disk info from esxi-1.labs.org (may take a moment) ...
2019-08-16 19:31:10 +0000: Done fetching vSAN disk infos

Proactive rebalance start: 2019-08-16 19:30:47 UTC
Proactive rebalance stop: 2019-08-17 19:30:54 UTC
Max usage difference triggering rebalancing: 30.00%
Average disk usage: 56.00%
Maximum disk usage: 63.00% (17.00% above minimum disk usage)
Imbalance index: 10.00%
No disk detected to be rebalanced

이러한 균형 재조정은 24시간 이내에 시작되고 중지된다는 것을 알게 될 것이다.

균형 재조정을 시작하려면 다음 명령을 실행한다:
vsan.proactive_rebalance -s <vSAN-cluster-number>

출력은 다음과 같이 나타난다:

/localhost/Test-DC/computers/Test-CL> vsan.proactive_rebalance . -s
2019-08-16 19:30:55 +0000: Processing vSAN proactive rebalance on host esxi-3.labs.org ...
2019-08-16 19:30:55 +0000: Processing vSAN proactive rebalance on host esxi-1.labs.org ...
2019-08-16 19:30:55 +0000: Processing vSAN proactive rebalance on host esxi-2.labs.org ...

이 작업은 몇 시간이 걸릴 수 있다.

기본 24시간을 초과하여 재조정을 실행하려면 재조정 런타임, <값은 초 단위로 표시됨>을 변경해야 한다.

예를 들어, 일주일 동안 실행되도록 재조정 설정:
vsan.properties_vasance . -t 604800

이 경우 이 작업은 완료되거나 일주일 동안 수행된다. 한 주가 다 되기 전에 재조정이 끝나면 프로세스가 종료된다.

Automatic Rebalance :

vSAN 6.7 U3 디스크 재조정은 더 이상 수동 방법이 아니며, vSAN 클러스터 설정 내에서 서비스로 사용하도록 설정해야 한다(아래 설명 참조). 이 옵션을 사용하도록 설정하지 않으면, vSAN 디스크 중 하나라도 용량 임계값 80%를 초과하는 경우에만 vSAN 디스크에 대한 재조정을 시작하게 된다.

디스크 재조정은 vSAN 클러스터의 I/O 성능에 영향을 줄 수 있다. 성능에 영향을 주지 않기 위해 최대 성능이 필요할 때 임계값을 변경하거나 자동 균형 재조정을 해제할 수 있다.

Automatic Rebalance:

  1.  vSAN 클러스터로 이동한다.
  2. Configure 탭을 누르다.
  3. vSAN에서 Services를 선택한다.
  4. Advanced Options를 클릭한다.
  5. 클릭해서 Automatic Rebalance Enable/Disable 한다.
  6. 요구 사항에 따라 분산 임계값을 20에서 75 사이의 백분율로 설정한다.

재균형을 시작하기 위한 임계값은 기본적으로 30%로 설정되며, 이는 두 개의 디스크가 이 분산(한 디스크는 다른 디스크보다 30% 더 로드됨)을 가지면 구성 요소의 재균형이 시작됨을 의미한다. 분산이 설정된 임계값(기본값 15%)의 절반에 도달할 때까지(또는 자동 균형 재조정이 비활성화될 때까지) 재조정은 계속된다.

vSAN 클러스터의 디스크 사용량 세부 정보를 볼 수 있는 vSAN 디스크 밸런스에 대한 상태 점검도 있다. 자동 재조정을 사용하도록 설정한 경우 vSAN은 자동으로 이 상태 검사를 녹색으로 유지하려고 시도한다. 실행 중지된 경우 이 상태 점검이 트리거되며 관리자가 수동으로 디스크 재조정 태스크를 트리거하거나 자동 재조정 기능을 다시 사용하도록 설정해야 한다.

관련 정보

vSAN 6.5에서 rvc 콘솔에서 사용할 수 있는 vsan.proactive_rebalance 플래그:

vsan.proactive_rebalance . -h
usage: proactive_rebalance [opts] cluster
Configure proactive rebalance for vSAN
  cluster: Path to ClusterComputeResource
-s, --start            Start proactive rebalance
-t, --time-span=<i>   Determine how long this proactive rebalance lasts in seconds, only be valid when option 'start' is specified
-v, --variance-threshold=<f>    Configure the threshold, that only if disk's used_capacity/disk_capacity exceeds this threshold(comparing to the disk with the least fullness in the cluster), disk is qualified for proactive rebalance, only be valid when option 'start' is specified
  -i, --time-threshold=<i>   Threshold in seconds, that only when variance threshold continuously exceeds this threshold, corresponding disk will be involved to proactive rebalance, only be valid when option 'start' is specified
  -r, --rate-threshold=<i>    Determine how many data in MB could be moved per hour for each node, only be valid when option 'start' is specified
  -o, --stop                      Stop proactive rebalance
  -h, --help                      Show this message

다음에 대한 자세한 정보:

 

VMware KB : Top 20 article for vSAN

[번역] How to manually remove and recreate a vSAN disk group using esxcli (2150567)

출처 : https://kb.vmware.com/s/article/2150567

제목 : esxcli를 사용해서 vSAN 디스크 그룹을 수동으로 제거하고, 재생성하는 방법 (2150567)

목적

이 문서는 ESX Command Line Interface(esxcli)를 사용해서, vSAN 디스크 그룹을 수동으로 제거하고 재생성하는 단계가 나와 있으며, 이는 vCenter Server에 액세스할 수 없거나 vSphere Web Client에서 오류가 발생하여 디스크 그룹 관리에 액세스할 수 없는 경우에 해당된다.

해결

esxcli 명령을 사용해서 디스크 그룹을 제거 및 재생성:

이 단계는 주의 깊게 따르지 않으면 데이터가 파괴될 수 있다.

1. SSH를 사용하여 루트 사용자로 디스크 그룹을 소유하는 ESXi 호스트에 로그인한다.

2. 다음 명령 중 하나를 실행하여 호스트를 유지 보수 모드로 전환한다. 다음 3가지 옵션이 있다.

VMware는 ensureObjectAccessibility 옵션을 사용할 것을 권장한다. esureObjectAccessibility 모드 또는 evacuateAllData 모드 사용에 실패할  경우에는 데이터 손실을 초래할 수 있다.

3. 다음 명령을 실행하여 기존 그룹에 캐시 및 용량 디스크 ID를 기록한다.
esxcli vsan storage list

용량 계층 장치의 출력 예:

naa.123456XXXXXXXXXXX:
Device: naa.123456XXXXXXXXXXX
Display Name: naa.123456XXXXXXXXXXX
Is SSD: true
VSAN UUID: 52164f1b-668b-ec68-b293-919b04e78fa3
VSAN Disk Group UUID: 52ab175f-17c6-6f42-e10a-ca86fc1d008e
VSAN Disk Group Name: naa.50000XXXXX1245
Used by this host: true
In CMMDS: true
On-disk format version: 5
Deduplication: true
Compression: true
Checksum: 5356031598619392290
Checksum OK: true
Is Capacity Tier: true
Encryption: false
DiskKeyLoaded: false

캐시 디스크의 경우:
VSAN UUID와 VSAN Disk Group UUID 필드가 일치한다.
보고 출력 : Is Capacity Tier: false

4. 디스크 그룹을 제거한다.

esxcli vsan storage remove -u <VSAN Disk Group UUID>

다음 명령을 사용해서 디스크 그룹 UUID를 항상 두번 확인한다.
esxcli vsan storage list

5. 실제 Disk를 교체한 경우 Additional Information 섹션을 참조한다.

6. 다음 명령을 사용하여 디스크 그룹을 생성한다.

esxcli vsan storage add -s naa.xxxxxx -d naa.xxxxxx -d naa.xxxxxxxx -d naa.xxxxxxxxxxxxxxxxxxx

naa.xxxxxx는 디스크 디바이스의 NAA ID이며 디스크 디바이스는 다음과 같은 옵션에 따라 식별된다.

7. esxcli vsan storage list 명령을 실행하여 "CMMDS:" 필드 출력에서 새 디스크 그룹을 확인하고 모든 디스크가 True를 보고하는지 확인한다.

관련 정보

실제 Disk를 교체하는 경우 추가 단계가 필요하다:

1) 전원 끄기를 트리거하거나 호스트 유지 보수를 수행하기 전에 해결 방법 섹션 2단계에 설명된 대로 노드가 유지 보수 모드에 있을 것을 권장한다.

vSAN 디스크는 다음과 같은 상황에서 핫 스왑이 가능하다.

a) 하이브리드 구성 및 컨트롤러에서 핫 스와핑 Disk 지원

b) 모든 플래시, 중복제거 및 압축이 사용되지 않으며 컨트롤러에서 핫 스와핑 Disk를 지원

컨트롤러가 Disk의 핫 스와핑을 지원하는지 또는 Deduplication과 Compression을 사용하도록 설정되어 있는지 확실하지 않은 경우 해당 컨트롤러를 지원되지 않는 것으로 간주하고 노드를 유지 보수 모드로 전환하여 접근성을 보장하고 노드 전원을 끄고 디스크를 교체한다.

참고: Deduplication과 Compression이 활성화된 디스크 그룹은 장애가 발생한 디스크를 교체하기 전에 디스크 그룹을 삭제해야 한다. 위의 해결 방법 섹션의 단계에 따라 고장난 디스크를 교체한다.

장애가 발생한 디스크를 핫 스왑할 수 있는 경우 새 디스크를 감지하여 ESXi에 사용할 수 있도록 HBA 다시 검색을 실행한다.

2) SSH를 통해 root로 노드에 로그인하고 아래 명령을 실행하여 모든 HBA를 다시 검색한다.
esxcli storage core adapter rescan --all

3) 다음 명령을 실행하여 컨트롤러를 통해 모든 디스크가 표시되는지 확인한다.

vdq -iqlless

모든 디스크의 SSD와 캐패시티 디스크의 naa.xxxxx와 태그가 나열된다.

4) 다음 명령을 실행해서 적합한 새 캐패시티 디스크에 대한 디스크 태그를 지정한다.

esxcli vsan storage tag add -d naa.xxxxxx

올플래시 환경에만 필요하다.

5) 명령을 실행해서 SSD 디스크를 캐시 디스크로 태그 지정

esxcli vsan storage tag add -s t10.NVMe____INTEL_SSDPEDMD800G4_____

vdq -iq 명령 출력에서 정확한 이름을 기록한다.

 

VMware KB : Top 20 article for vSAN

[번역] vSAN Health Service - Data Health – vSAN Object Health (2108319)

출처 : https://kb.vmware.com/s/article/2108319

제목 : vSAN Health Service - Data Health – vSAN Object Health (2108319)

목적

이 문서는 vSAN Health Service의 Data health – vSAN Object Health에 대해 설명하고, 오류를 보고하는 이유에 대해서 자세히 알아본다.

해결

질문: Data Health – vSAN Object Health의 기능은?

오브젝트 상태 점검은 매우 빠른 시각에 두 가지 측면을 제공하도록 설계됐다.

질문: 오류 상태는 어떤 의미인가?

어떤 오브젝트가 건강하지 않을 때 가질 수 있는 가능한 상태들이다.

Data move : vSAN이 클러스터의 ESXi 호스트 및 스토리지에 대한 데이터를 구축(build)하는 이유는 사용자가 유지 보수 모드, 제거 요청, 재조정 작업 때문이다. 이 상태의 오브젝트는 정책을 완전히 준수하고 정상이지만 vSAN은 이를 적극적으로 재구성하고 있다. 물체가 위험에 처하지 않기 때문에 걱정하지 말아야 한다. 그러나 개체가 이 상태에 있는 동안 성능에 영향을 미칠 수 있다. 재동기화 구성 요소 뷰를 교차 참조하여 활성 데이터 동기화 작업에 대해 자세히 알아본다.

Healthy: 오브젝트는 정책과 정확히 일치하며 완벽한 상태에 있으며 현재 이동 중이거나 다른 방법으로 작업되지 않고 있다.

Inaccessible: 어떤 오브젝트는 허용하도록 구성된 것보다 더 많은 (영구적이거나 일시적인) 장애를 겪었으며, 현재 사용할 수 없고 접근할 수 없다. 고장이 일시적이지 않은 경우(예: ESXi 호스트 재부팅)에는 이러한 액세스 불가능한 상태에서는 이러한 오브젝트를 사용하는 가상 시스템이 올바르게 작동할 수 없으므로 가용성을 복원하기 위해 장애가 발생한 ESXi 호스트, 네트워크 장애, 디스크 제거 등과 같은 기본 근본 원인을 최대한 빨리 해결한다.

Non-availability related incompliance : 이것은 다른 상태들 중 어느 상태도 적용되지 않을 때 모든 상태들을 사로잡는 상태다. 이 상태의 개체는 해당 정책을 준수하지 않지만 가용성(NumberOfFailuresToTolrate) 정책을 충족하고 있는 경우다. 현재 이 상태를 적용할 수 있는 문서화된 사례는 없다.

Non-availability related reconfig : vSAN이 가용성과 관련 없는 스토리지 정책 변경을 요청했기 때문에 클러스터의 ESXi 호스트 및 스토리지에 대한 데이터를 재구성하는 중이다. 즉, 이러한 오브젝트는 NumberOfFailuresToTollate 정책을 완전히 준수하며 데이터 이동은 NumberOfDiskStripesPerObject와 같은 또 다른 정책 변경을 충족하기 위한 것이다. 이 상태의 물체는 위험하지 않기 때문에 걱정할 필요가 없다.

Reduced availability - active rebuild : 그 오브젝트는 고장을 겪었지만, 그 실패를 견딜 수 있도록 구성되었다. I/O가 계속 흘러 객체에 접근할 수 있으며, vSAN은 객체를 규정 준수 상태로 되돌리기 위해 새로운 구성요소를 재구축하여 객체를 재보호하는 작업에 적극적으로 임하고 있다.

Reduced availability with no rebuild: 이 개체에 장애가 발생했지만 vSAN은 이를 용인할 수 있었다. 예를 들어 I/O가 흐르고 있으며 객체에 액세스할 수 있다. 그러나 vSAN은 개체를 다시 보호하는 작업을 수행하지 않고 있다. 이는 지연 타이머(사용가능성 감소 - 재구축 없음 - 지연 타이머) 때문이 아니라 다른 이유 때문이다. 클러스터에 리소스가 부족하기 때문일 수도 있고, 과거에 리소스가 부족했기 때문일 수도 있고, 과거에 재보호 실패가 있었고 vSAN이 아직 재시도하지 않았기 때문일 수도 있다. 리소스가 모두 소모될 수 있는 경우 첫 번째 평가에서는 제한 상태 점검을 참조한다. 후속 장애에 대한 완전한 보호로 돌아가려면 가능한 한 빨리 장애를 해결하거나 리소스를 추가해야 한다.

Reduced availability with no rebuild - delay timer: 이 오브젝트는 장애가 발생했지만 vSAN은 이를 허용할 수 있었다. I/O가 흐르고 있으며 오브젝트에 접근할 수 있다. 그러나 vSAN은 재보호 발행(issuing) 전 60분(기본값) 지연 타이머가 만료되기를 기다리고 있어 아직 오브젝트 재보호 작업을 진행하지 않고 있다.

지연 기간 내에 실패한 실체를 복구할 수 없는 것으로 알려진 경우, 지연 타이머를 건너뛰고 즉시 재보호에 착수하라는 명시적 요청을 발행하도록 선택할 수 있다.

그러나 장애가 발생한 호스트가 능동적으로 재부팅 중이거나 잘못된 드라이브를 당겼다가 다시 삽입되고 있다는 사실을 알고 있다면, 개체를 완전히 다시 보호하는 가장 빠른 방법이므로 이러한 작업이 완료될 때까지 기다리는 것이 바람직하다.

Reduced Availability With Paused Rebuild : 오브젝트가 장애를 겪었거나 최근 정책이 가용성 요구사항이 더 높은 것으로 변경되었다. 그러나 사용 가능한 리소스가 부족하여 오브젝트 재구축이 일시 중지된다.

Reduced Availability With Policy Pending : 오브젝트 정책이 최근에 변경되었지만 개체에 아직 적용되지 않은 경우다. 오브젝트의 현재 가용성이 새 정책이 예상하는 것보다 작다. 임시 상태이며 리소스 제한으로 인해 새 정책이 수락될 수 있는지 여부에 따라 결국 'healthy' 또는 'Reduced Availability With Policy Pending Failed'로 전환된다는 점에 유의한다. 그리고 클러스터에서 사용 중인 과도 용량에 따라 오브젝트는 몇 분에서 몇 시간까지 상태를 유지하게 된다. 이 상태에 대해 사용자 작업이 필요하지는 않다.

Reduced Availability With Policy Pending Failed : 오브젝트 정책이 변경되었지만 사용 가능한 리소스가 부족하여 오브젝트에 적용하지 못한다. vSAN이 오브젝트에 새 가용성 정책을 자동으로 다시 적용하여 오브젝트의 규정을 완전히 준수할 수 있도록 하려면 사용자가 클러스터에 리소스를 추가해야 한다.

Non-availability Related In-compliance With Policy Pending : 오브젝트 정책이 최근에 변경되었으며 아직 적용되지 않았다. 오브젝트는 여전히 새 가용성 정책을 완전히 준수하지만 새로운 비 가용성 관련 정책을 준수하지 않는다. 임시 상태이며 리소스 제한으로 인해 새 정책이 수락될 수 있는지 여부에 따라 결국 'healthy' 또는 'Non-availability Relate In-compliance With Policy Pending Failed' 상태로 전환된다는 점에 유의한다. 그리고 클러스터에서 사용 중인 과도 용량에 따라 오브젝트는 몇 분에서 몇 시간까지 상태를 유지하게 된다. 이 상태에 대해 사용자 작업이 필요하지 않다.

Non-availability Relate In-compliance With Policy Pending Failed : 오브젝트 정책이 최근에 변경되었지만 리소스가 부족하여 개체에 적용하지 못한다. 오브젝트는 여전히 새 가용성 정책을 완전히 준수한다. vSAN이 오브젝트에 새로운 가용성 관련 정책을 자동으로 다시 적용하여 완벽하게 준수할 수 있도록 하려면 사용자는 클러스터에 리소스를 추가해야 한다.

Non-availability Related In-compliance With Paused Rebuild : 오브젝트가 현재 정책을 준수하지 않지만 가용성(NumberOfFailuresToTolrate) 정책을 충족하고 있는 경우다. 그러나 사용 가능한 리소스가 부족하여 개체 재구축이 일시 중지되었다.

질문 : 문제를 해결하고 오류 상태를 어떻게 수정하는가?

위의 목록에서 오브젝트 상태를 검토하면 오브젝트 관점에서 vSAN 클러스터에서 어떤 작업이 수행되고 있는지, 수정 작업을 수행해야 하는지 여부를 알 수 있다.

오브젝트 상태에 문제가 있거나 오브젝트가 예기치 않은 상태일 경우 VMware Support에 문의한다. 자세한 내용은 My VMware에서 지원 요청을 제출하는 방법(2006985)을 참조한다.

관련 정보

VMware vSANlog 수집에 대한 자세한 내용은 vSAN 지원 로그 수집 및 VMware에 업로드(2072796)를 참조한다.

VMware KB : Top 20 article for vSAN

[번역] FAQ: Support statement for 512e and 4K Native drives for VMware vSphere and vSAN (2091600)

출처 : https://kb.vmware.com/s/article/2091600

제목 : FAQ: VMware vSphere 및 vSAN용 512e 및 4K 네이티브 드라이브에 지원 (2091600)

목적

이 문서는 VMware vSphere 및 VMware vSAN(이전의 Virtual SAN)의 GA 버전에 대한 512e 및 4K Native(4Kn) 드라이브 지원에 대한 FAQ를 제공한다.

참고:

영향/위험

vSphere/vSAN 6.0 이전 버전은 4Kn/512e 직접 연결 Disk 드라이브를 사용하도록 설계되지 않았으며, 512e 드라이브는 버전 6.5 이상에서만 지원된다.

Virtual SAN은 새로운 vsanSparse 스냅샷 형식을 포함하여 버전 6.0 이후 4K 정렬 I/O 작업에 최적화되어 있단다. 그러나 이전 ESXi 빌드의 제한으로 인해 4k 정렬을 완전히 사용할 수 없었다.

해결

4K Native 및 512e 드라이브란?

업계 표준 디스크 드라이브는 네이티브(물리적) 512바이트 섹터 크기를 사용해 왔다. 그러나, 더 큰 용량에 대한 수요 증가로 인해, 스토리지 산업은 최근 4KB (4096 바이트)의 물리적 섹터를 사용하는 새로운 고급(advanced) 포맷을 도입했다.

디스크 섹터 크기는 디스크 드라이브에서 I/O 작업의 원자단위를 나타내기 때문에 장치 드라이버, 파일 시스템 등의 운영 체제 및 하이퍼바이저(여기서 OS로 통칭) 소프트웨어의 설계에 중요한 요소다. 모든 OS 버전이 디스크 드라이브의 4KB 섹터를 활용하도록 수정된 것은 아니다. 따라서 이러한 최신 장치의 펌웨어는 4KB 네이티브(4Kn) 또는 512B 에뮬레이션(512e)인 논리 섹터 크기를 노출할 수 있다.

4Kn은 물리적 섹터와 논리적 섹터의 크기가 모두 4,096바이트인 고급 포맷이다.

512e는 물리적 섹터 크기가 4,096바이트인 고급 포맷이지만 논리 섹터 크기는 512바이트 섹터 크기를 에뮬레이트한다. 512e의 목적은 아직 4Kn 섹터를 지원하지 않는 OS와 함께 새로운 기기를 사용하는 것이다. 그러나 본질적으로 512바이트 에뮬레이션은 4KB 정렬되지 않은 모든 쓰기 작업에 대해 장치 펌웨어의 읽기-수정-쓰기 프로세스를 포함한다.

예를 들어, I/O 작업이 디스크 시작부터 바이트 단위의 4KB 오프셋으로 정렬되지 않거나 길이가 4KB의 배수가 아닌 워크로드는 모든 쓰기 작업에 대해 드라이브에서 수행되는 읽기-수정-쓰기 프로세스로 인한 정렬 불이익을 받는다. 작은 동작에서는 벌점이 더 뚜렷하다. 대규모 I/O의 경우, 작업당 지연 시간은 전송 시간에 의해 지배된다. 많은 512e 드라이브는 구형 512n 드라이브보다 약간 빠르기 때문에, 일반적으로 특정 작동 크기(예: 256KB 이상, 때로는 그보다 작음) 후에 정렬 패널티가 취소된다.

다시 말해, 512e 섹터가 있더라도, 애플리케이션과 OS가 4KB 정렬 I/O를 수행하는 것이 선호된다. 이것은 일반적인 문제일 뿐 특정 OS에는 특별한 문제가 없다.

또한 읽기-수정-쓰기 벌칙은 자기 디스크(HDD)와 솔리드 스테이트 디스크(SSD) 모두에 적용되지만 자기 디스크의 IOPS 수가 훨씬 적기 때문에 성능 영향이 더 뚜렷하다.

이 표는 기본 512바이트 섹터를 새로운 고급 포맷과 비교한다.

포맷 논리 섹터 크기 물리 섹터 크기
512n 512 512
512e 512 4,096
4Kn 4,096 4,096
현재 GA 버전의 vSphere 및 VSAN은 4K Native 드라이브를 지원하십니까?

예, vSphere 6.7 및 vSAN 6.7부터는 4K Native 하드 디스크 드라이브를 지원하며, vSphere & vSAN은 이 지원의 일환으로 512n VMDK를 게스트 OS에 계속 노출할 것이다. vSphere 배포에는 VMFS 6 데이터스토어가 필요하며 현재는 4KN HDD에서 RDM을 지원하지 않는다.

512e 드라이브를 지원하는 vSphere 및 vSAN 버전은?

vSphere 6.5 및 vSAN 6.5 이상에서는 512e 드라이브를 직접 연결 드라이브로 지원 vSphere & vSAN이 게스트 OS에 512n을 노출한다.

512e 드라이브 지원에는 vSphere 6.5부터 VMFS 6.0이 필요하다.

버전 6.5 이전 버전에서는 512e를 vSphere 및 vSAN에 노출하는 직접 연결 드라이브가 지원되지 않는다(아래 예외 참조). 자세한 내용은 영향/위험 섹션을 참조하십시오.

예외: vSphere 6.0 이상 버전은 직접 연결된 512e 드라이브에 매핑된 물리적 모드 RDM을 지원한다.

호환되는 RAID 컨트롤러 뒤에 512e 드라이브가 있고, RAID 컨트롤러가 512n 드라이브를 vSphere에 노출하는 경우 어떻게 하시겠습니까?

RAID 컨트롤러가 512e 드라이브를 512n 형식 드라이브로 vSphere에 노출하는 한 vSphere는 이 구성을 지원한다. RAID 컨트롤러도 vSphere 호환성 가이드에 나열되어 있어야 한다. RAID 컨트롤러 벤더에 문의하여 구성을 확인하고 실행할 워크로드에 부정적인 성능 영향이 없는지 확인한다.

VMware KB : Top 20 article for vSAN

[번역] "There is no more space for virtual disk .vmdk" error when starting vSAN VM (2146613)

출처 : https://kb.vmware.com/s/article/2146613

제목 : vSAN VM을 시작할 때 "There is no more space for virtual disk .vmdk" 오류 (2146613)

증상

vSAN 가상 시스템을 시작할 수 없으며 다음과 같은 증상이 발생하는 경우:

There is no more space for virtual disk <VM name>.vmdk. You might be able to continue this session by freeing disk space on the relevant volume and clicking retry.

목적

이 문서의 목적은 가상 디스크 오류에 대해 공간이 더 이상 없는 원인과 이 문제를 해결하기 위한 정보를 설명하는 것이다.

원인

VM 스토리지 정책의 비준수로 인해 오브젝트 생성이 실패한다.

해결

이 문제를 해결하려면 오브젝트에 스트라이핑 정책을 적용할 때 가용성 및 스트라이핑 요구 사항을 모두 충족할 수 있는 공간이 충분한지 확인한다.

보고된 총 여유 공간은 물리적 용량이다.

필요한 공간을 계산하려면 새 오브젝트에 적용할 스토리지 정책을 고려해야 한다.

vSAN 기본 스토리지 정책에서:

사용 가능한 보고된 원시(raw) 여유 공간은 새 오브젝트 크기와 약간의 작은 메타데이터 오버헤드의 두 배 미만이다. 이 크기보다 큰 개체를 만들려고 하면 오류가 발생하여 실패한다.

예를 들면 다음과 같다.

그러나 오브젝트 공간 예약이 0(씬 프로비저닝됨)이기 때문에 용량을 오버 커밋할 수 있다. 이로 인해 프로비저닝된 개체가 증가함에 따라 용량 계층 공간이 부족해질 위험이 발생한다.

기본 정책을 사용하여 크기가 255GB보다 작거나 같은 오브젝트체에 별도의 vSAN 호스트에 2개의 구성 요소(복제)가 배치되는지 확인한다. 스트라이프 너비가 1이기 때문에, 이 물체의 구성요소는 더 작은 청크로 분할되지 않는다. 그러나 어떤 용량 계층 디스크에서 사용 가능한 최소 여유 공간이 개체 크기보다 작을 경우, 이 경우 CLOMD는 한번 이상의 반복을 시도하여 용량 계층 디스크의 여유 공간에 가장 잘 맞는 더 작은 동일한 스트라이프로 복제본을 분할한다.

고려해야 할 요인은 용량 계층 디스크에서 구성 요소가 얼마나 잘 균형을 이루느냐 하는 것이다. 일부 Disk가 다른 Disk보다 많이 활용되면 사용 가능한 공간이 용량 계층 Disk에 클러스터 간에 균등하게 분산되지 않는다. 따라서 최소 공통 분모에 맞도록 더 작은 스트라이프를 만들 수 있으며, 동일한 Disk에 다른 Disk보다 사용 가능한 공간이 더 많은 경우 일부 스트립이 있을 수 있다. 스트라이프는 성능 최적화가 아닌 최적의 공간 할당을 위한 것이기 때문에 스트라이프가 동일한 용량 계층 디스크에 함께 배치되는 것이 허용된다.

예 : 노드당 디스크 그룹이 하나씩 있는 3개 노드 클러스터가 있다고 가정한다.

이 계산의 문제는 RAID-1의 미러 2개가 동일한 호스트에 있을 수 없다는 것이다. 따라서 첫 번째 복제본이 2개 노드에 걸쳐 분산된 경우, 미러는 충분한 공간이 없는 세 번째 노드에만 존재해야 한다. 이는 vSAN의 모범 사례가 최소 요구사항이 3개 노드임에도 4노드 클러스터를 사용하는 이유 중 하나이다.

구강사의 추가 해설 : 50G 크기로 스트라이프될 경우, 250G 를 저장하기 위해서 5개의 캐패시티 티어 디스크가 필요해진다. 즉, 1대의 호스트의 디스크로 부족하기 때문에 2개의 호스트가 사용되게 된다. FTT 1을 구현하기 위해서 또 다시 5개의 디스크가 필요해진다. 그러나 남은 호스트는 1대뿐...

요약하면, 보고된 원시 여유 공간은 모든 호스트의 모든 용량 계층 디스크에서 사용 가능한 모든 공간을 조합한 것으로, 이 공간이 반드시 사용 가능함을 의미하지는 않는다.

관련 정보

MD <255GB인 경우, 참조 : Using small magnetic disks for vSAN might result in VM failures

[번역] vSAN Design Considerations – Deduplication and Compression

출처 : https://blogs.vmware.com/virtualblocks/2020/06/18/vsan-design-considerations-deduplication-and-compression/

글 "Write Buffer Sizing in vSAN when Using the Very Latest Hardware"에서는 vSAN의 2계층 스토리지 시스템 구현에 대한 많은 기본 사항과 하드웨어가 시스템의 성능을 어떻게 변화시킬 수 있는지에 대해 설명하였다. 데이터 중복 제거 및 압축과 같은 소프트웨어 관련 설정이 성능에 미치는 영향 vSAN에서 구현되는 방식, 성능에 영향을 미칠 수 있는지 여부와 시기에 대한 이해도를 높이는 방법을 단계별로 살펴보겠다.

중복제거 및 압축이란?

데이터 중복 제거는 동일한 블록을 여러 번 저장하는 대신 중복 블록이 하나 이상 발견될 때를 감지해 해시 테이블을 이용해 데이터 구조의 단일 블록을 참조하는 기법이다. 데이터 압축은 데이터 블록 내의 콘텐츠와 같이 주어진 양의 데이터를 필요로 하며, 보다 효율적인 방법으로 데이터를 저장하기 위해 인코딩 기법을 사용한다. 이 두 기법은 서로 무관하지만 비슷한 목표인 공간 효율을 달성하려고 시도한다.

공간 효율성이 구현되는 방법은 솔루션에 따라 다르며, 공간 절약의 수준과 그 결과를 얻기 위해 필요한 노력에 영향을 미칠 수 있다. 어떤 방법을 구현하든 중복제거 기술과 압축 기술은 모두 기회주의적 공간 효율성 기능이다. 용량 절감 수준은 보장되지 않는다. 반면 RAID-5 또는 RAID-6와 같은 삭제 코드를 사용하는 데이터 배치 기술은 결정론적이다. 그것들은 탄력적인 방법으로 저장된 데이터에 대해 보장된 수준의 공간 효율을 제공한다.

vSAN에서 구현되는 방법

vSAN의 중복제거 및 압축(DD&C)은 클러스터 수준에서 단일 공간 효율성 기능으로 실행되며, 이 프로세스는 데이터가 용량 계층으로 디스테이징될 때 수행되며, 이는 쓰기 승인 내용이 VM에 다시 전송된 다음이다. 수신확인이 전송될 때까지 모든 형태의 데이터 조작을 최소화하면 게스트 VM에서 보이는 쓰기 지연 시간을 낮게 유지할 수 있다.

데이터가 저장되면 중복 제거 프로세스는 디스크 그룹 내에서 발견된 4KB 데이터 블록(vSAN의 중복 제거 도메인)을 중복 제거할 수 있는 기회를 모색한다. 이 작업은 압축 프로세스를 따른다. 4KB 블록을 50% 이상 압축할 수 있다면 그렇게 할 것이다. 그렇지 않으면 그대로 유지되며 데이터를 용량 계층으로 계속 디스테이징할 수 있다.

Figure01.gif

그림 1. 디스테이징 프로세스 중 데이터 중복 제거 및 압축

이러한 방식으로 DD&C를 구현하면 쓰기 승인을 게스트로 다시 보내기 전에 중복제거를 수행하는 인라인 시스템에서 발견된 성능 저하를 방지할 수 있다. 또한 이미 유휴 상태인 데이터를 중복 제거해야 하는 문제도 피할 수 있다. DD&C 프로세스는 쓰기 승인을 게스트 VM에 전송한 후 수행되지만 vSAN에서 이를 사용하도록 설정하면 특정 상황에서 성능에 영향을 줄 수 있으며, 이 프로세스는 아래에서 설명하기로 한다.

2계층 스토리지 시스템 기본 사항

vSAN은 2계층 분산 스토리지 시스템(two-tier distributed storage system)이다. 수신 데이터는 최적의 성능을 위해 게스트로 즉시 전송되는 쓰기 승인 정보를 사용하여 쓰기 버퍼에 기록되며, vSAN에서 결정한 시간과 빈도에 용량 계층으로 전송된다. 이 아키텍처는 용량에서 기가바이트/테라바이트당 비용을 합리적으로 유지하면서 더 높은 수준의 스토리지 성능을 제공한다.