OPM

vSAN 소프트웨어 아키텍처 구성 요소

vSAN 아키텍처에는 다음 다섯 가지 주요 소프트웨어 구성 요소가 포함됩니다.

vSAN 아키텍처를 쉽게 집짓기에 비유할 수 있으면 이에 따라 CLOM은 설계자, DOM은 계약자, LSOM은 작업자, CMMDS는 매니저, 마지막으로 RDT는 건물 공급 배달 트럭입니다.

1. <CLOM> Cluster Level Object Manager (클러스터 수준 개체 관리자):  

CLOM은 건축가입니다. CLOM은 vSAN 클러스터의 각 ESXi 호스트에서 사용자 공간 데몬으로 존재하며 다음을 담당합니다.

• 개체 오케스트레이션.
• 생성 작업 중 개체 배치.
• 구성 요소 배치가 정의된 스토리지 정책을 충족하는지 확인합니다.
• 구성 요소를 교체해야 하는 경우 재구축을 예약합니다.

2. <DOM> Distributed Object Manager 분산 개체 관리자: 

DOM은 계약자 입니다.

DOM은 커널 공간에 존재하며 호스트를 부팅하지 않고 모니터링하거나 다시 시작할 수 있는 데몬이 없습니다. DOM은 객체 가용성 및 초기 I/O 요청을 처리하는 역할을 합니다.

• vSAN 클러스터의 모든 DOM은 복구 중에 개체를 재동기화합니다.
• 각 객체에는 DOM 소유자와 DOM 클라이언트가 있습니다.
• DOM 소유자는 개체에 I/O를 보낼 수 있는 프로세스를 결정합니다.
• DOM 클라이언트는 특정 가상 머신을 대신하여 객체에 대한 I/O를 수행합니다.
• DOM 클라이언트는 구성 요소를 포함하는 모든 노드에서 실행됩니다.
• 객체의 로컬 구성 요소를 생성하도록 LSOM에 지시합니다.
• DOM 개체에는 vdisk, snapshot, vmnamespace, vmswap, vmem 등이 포함됩니다.

3. <LSOM> Local Log Structure Object Manager 로컬 로그 구조 개체 관리자: 

LSOM은 작업자 입니다.

DOM과 마찬가지로 LSOM은 커널 공간에 존재하며 ESXi 호스트를 부팅하지 않고 모니터링하거나 다시 시작할 수 있는 데몬이 없습니다. 모든 구성 요소는 LSOM 계층에 존재하며 LSOM은 I/O를 처리하고 로컬 디스크에 있는 구성 요소의 일관성을 보장합니다.

• 읽기 및 쓰기 버퍼링을 제공합니다.
• DOM의 지시에 따라 로컬 구성 요소를 생성합니다.
• 쓰기 작업이 완료되면 DOM에 승인을 반환하고 읽기 작업에 대한 페이로드를 반환합니다.
• 배포, 쿼럼, I/O 동기화 등을 인식하지 못합니다. DOM은 이 모든 것을 해결합니다. LSOM은 I/O 처리만 담당합니다.
• vSAN 데이터스토어에 대한 암호화 프로세스를 수행합니다.
• 비정상 스토리지 및 네트워크 장치를 보고합니다.
• 실패한 장치에서 I/O 재시도를 수행합니다
• vSAN 노드 부팅 시 솔리드 스테이트 드라이브 로그 복구 수행

4. <CMMDS> Cluster Monitoring Membership and Directory Services : 

CMMDS는 매니저입니다.

개체, 호스트, 디스크, 네트워크 인터페이스, 정책, 이름 등의 모든 vSAN 인벤토리를 처리합니다.

• CLOM 및 DOM에 토폴로지 및 개체 구성 정보를 제공합니다.
• 개체의 소유자를 선택합니다.
• 호스트, 네트워크 및 장치와 같은 모든 클러스터 항목의 인벤토리를 작성합니다.
• 메모리 내 데이터베이스에 대한 정책 관련 정보와 같은 개체 메타데이터 정보를 저장합니다.
• 마스터, 백업 및 에이전트와 같은 클러스터 역할을 정의합니다.

5. <RDT> Reliable Datagram Transport (안정적인 데이터그램 전송):

RDT 는 공급 배달 트럭 입니다.

RDT는 클러스터 네트워크 통신에 사용되는 vSAN 네트워크 프로토콜 입니다.

• vSAN 클러스터의 모든 호스트 간의 통신은 1초마다 발생합니다. 업데이트는 vSAN 트래픽 전송을 위한 네트워크 프로토콜인 RDT를 통해 교환됩니다 .

출처 : https://vinception.fr/vmware-vsan-architecture-components/

https://www.altaro.com/vmware/vsan-architecture-components/

모듈 및 정보 : https://code.vmware.com/web/tool/12.3.0/vmware-powercli

1. 모듈을 다운받아 오프라인 설치 준비를 해줍니다.

2. 오프라인 설치 하기

Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.

새로운 크로스 플랫폼 PowerShell 사용 https://aka.ms/pscore6

PS C:\Users\kwon>$env:PSModulePath
C:\Users\kwon\Documents\WindowsPowerShell\Modules;C:\Program Files\WindowsPowerShell\Modules;C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules

$env:PSModulePath 명령어를 사용하여 Powershell 모듈 path를 확인 합니다. (3가지 경로가 나옴)

C:\Users\kwon\Documents\WindowsPowerShell\Modules;C:\Program Files\WindowsPowerShell\Modules;C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules

현재 운영중인 vCenter, ESXi 버전에 맞는 PowerCLI 모듈 버전을 받아 복사해 줍니다.

Get-ChildItem -Path 'C:\Program Files\WindowsPowerShell\Modules' -Recurse | Unblock-File

Unblock-File 명령어로 해당 모듈들을 신뢰할수있게 적용 해줍니다.

<Note> Windows는 인터넷에서 무언가를 다운로드하면 "신뢰할 수 없는" 것으로 간주되어 차단을 해제할 때까지 사용이 차단됩니다.

Get-Module VMware* -ListAvailable

사용가능한 VMware 모듈 정보 확인 합니다.

Connect-VIServer -Server vCenterFQDN(IP) -User 계정정보(SSO) -Password 암호

Set-PowerCLIConfiguration -InvalidCertificateAction Ignore

DRS 수행 시 Consumed Memory와 Active Memory의 연관 관계에 대하여 알아보겠습니다.

이사례를 보면 클러스터에는 그림1과 같이 유사한 VM들(메모리 구성 측면에서) 가진 3개의 호스트가 있습니다.

표 1과 같이 호스트들 중에 active Memory가 낮은 VM들이 있는 호스트가 한대 있습니다. (Host 10.156.236.128)

로드밸런싱하는동안 DRS는 active Memory를 고려하므로, 이 호스트의 active Memory가 낮고 나머지 다른 호스트들의 active memory가 높고 일정하게 유지되는 경우 active memory의 로드 분포에 불균형을 일으키도록 클러스터를 그림2과 같이 Imbalanced라고 표기 합니다.

그 결과 메모리 사용량이 많은 VM들 중 하나가 active Memory가 적은 호스트로 마이그레이션됩니다

참고로 거의 모든 물리적 메모리가 이미 세 호스트에 있는 VM들에 매핑되었습니다(총 consumed Memory는 모든 호스트의 총 용량과 비슷하거나 같음).

vMotion을 사용하여 마이그레이션할 추가 VM을 수용하려면 active Memory가 낮은 호스트가 실행 중인 기존 VM에서 메모리를 회수해야 합니다. 이로 인하여 호스트에서 실행 중인 VM 중 하나에 대해 메모리 경합이 발생하며 이 경우 다음과 같이 스왑됩니다.
그림3 에 나와 있습니다.

보시다 시피 consumed Memory가 클러스터의 모든 호스트에서 다소 균등하게 균형을 이루고 있을 때 우리는 DRS가 VM을 마이그레이션하지 않을 것으로 예상합니다.

마이그레이션이 발생하더라도 우리는 그 어떤 VM들이 balloon 이나 swap이 일어나지 않을 것이라 예상 합니다.

swap은 VM에서 잠재적으로 성능 문제를 일으킬 수 있습니다.

출처 : https://blogs.vmware.com/virtualblocks/2020/10/21/hci-economics-maximize-vsan-thin-provisioning-to-maximize-savings/

많은 조직이 2012 년에 블록 스토리지 어레이의 현실을 처리하기 위해 "항상 Eager Zero Thick 사용"정책을 채택했습니다. vSAN으로 전환 할 때 씬 프로비저닝은 스토리지 비용을 절감 할 수있는 빠르고 안전한 방법으로 재검토되어야합니다.

1. 관리 및 모니터링 오버 헤드 – VMFS 블록 스토리지와 함께 씬 프로비저닝을 사용하는 경우 각 데이터 스토어에서 공간 부족 상태를 모니터링해야합니다. VMFS의 초기 버전은 용량 제한 (2TB)이 더 작았습니다. 이로 인해 공간 부족 상태를 방지하기위한 추가 모니터링 오버 헤드가 발생했습니다. 어레이에서 사용되는 더 큰 풀에서만 사용되는 씬 프로비저닝은이 오버 헤드를 줄였습니다. vSAN은 사용 가능한 모든 용량을 풀링하므로 씬 프로비저닝을 모니터링 할 단일 풀로 설정하는 어레이의 동작을 미러링합니다. vSAN 7U1은 vSAN 관리자가 용량이 적은 경우에 도움이되도록 데이터 스토어에서 용량을 숨길 수있는 "운영 예약"을 추가로 구현했습니다.

2. VMFS Performance overhead  – 씬 프로비저닝 성능 오버 헤드는 수년 전에 우려되었던 것이었지만 시대는 변했습니다. 역사적으로 VMFS에서 이것은 SCSI 예약으로 수행되었으며 성능 관련 문제를 일으킬 수 있습니다. ATS가이 문제를 완화했지만 vSAN은 클러스터 된 파일 시스템없이 블록 소유권을 처리하므로 설계 상이 문제가 없다는 점에 주목할 가치가 있습니다. vSAN은 기본적으로 "희소"라는 점에서 NFS와 더 유사하게 작동하며 VMDK를 "두꺼움"으로 설정하는 것은 쓰기 IO 경로의 순 최적화가 아니라 용량 예약입니다.

3. Array performance overhead – 일부 구형 스토리지 어레이는 씬 프로비저닝을 사용하기위한 성능 오버 헤드를 전달했습니다. 디스크에 메타 데이터 맵을 저장하면 읽기 IO가 100 % 증폭되고 어레이의 절반에서 성능이 효과적으로 감소됩니다. vSAN (예 : 최신 어레이)은 메타 데이터 맵을 플래시에 저장하고이를 DRAM에 캐시하여이 문제를 방지합니다.

4. Shared VMDK Support requirements – 과거에 공유 된 VMDK (예 : Oracle에 필요한 것)에는 Eager Zero Thick 볼륨이 필요했습니다. 이것은 더 이상 vSAN의 요구 사항이 아닙니다 .

5. Vendor/application support – 일부 공급 업체가 불필요하게 오래된 모범 사례를 따르는 경우입니다. 대부분의 주요 애플리케이션 공급 업체가 씬 및 일부 이전 홀드 아웃 (예 : Microsoft Exchange)을 지원한다는 점은 주목할 가치가 있습니다.씬 프로비저닝을 지원하도록 변경되었습니다 .

6. 씬 프로비저닝은 신뢰성이 떨어졌습니다. 오랫동안 씬 프로비저닝을 사용해 온 사람이라면 씬 프로비저닝이 항상 앞뒤가 맞지 않는다는 것을 알 수 있었습니다. 나와 통화한 고객 중 한 명이 페타바이트의 차이를 발견했습니다. 윈도우즈에서는 드라이브가 50GB를 사용하는 것으로 보고되지만 씬 VMDK는 200GB를 사용하고 있는 것으로 표시되며 어레이는 VMFS에 500GB를 사용하고 있는 것으로 표시됩니다. 이는 NTFS/XFS/EXT4 등이 새로운 쓰기를 사용 가능한 공간으로 적극적으로 리디렉션하는 비친화적인 씬 파일 시스템의 결과입니다. 시간이 지남에 따라 씬 프로비저닝 절감 효과가 서서히 회복될 것입니다. TRIM/UNMAP을 통해 이 문제를 해결할 수 있었지만, 이러한 명령은 스토리지 컨트롤러를 압도하여 문제를 일으킨 전력이 있습니다. 또한 블록 회수 작업은 두 가상 시스템 계층에서 모두 관리하되 추가적인 VMFS 계층에서 관리해야 했습니다. vSAN은 단일 계층(가상 시스템에서 VMDK로)에서 회수함으로써 이러한 복잡성을 방지합니다. vSAN은 스케일아웃 컨트롤러 시스템을 사용하여 많은 성능 문제를 완화합니다. 컨트롤러 성능을 스케일아웃하여 메타데이터 작업을 처리하고 UNMAP 명령의 디스테이징을 지능적으로 제한할 수 있습니다. UNMAP 지원을 활성화하면 씬 프로비저닝을 20-30% 더 절약할 수 있습니다.

VMware vSAN은 씬 스토리지를 제공 할뿐만 아니라 씬을 유지할 준비가되어 있습니다. 이렇게 20-50 %의 용량 절감 효과를 더하면 안전하고 일관된 방식으로 총 스토리지 비용이 절감됩니다.

출처 : https://blogs.vmware.com/virtualblocks/2020/10/21/hci-economics-maximize-vsan-thin-provisioning-to-maximize-savings/

vSAN 클러스터 Automatic Rebalance 에 대해 알아보겠습니다.

요약:

• 디스크 폴트나 호스트장애로 60분이상 유지보수모드 실행 시 데이터 불균형 발생 할 수 있음
• vSAN 6.7 이상 부터는 Automatic Rebalance 필수 사용
• Automatic Rebalance 서비스 실행 시 즉시 데이터 마이그레이션이 실행 되며 워크로드에 형향 줄 수 있음

 vSAN 6.7 이상 버전 부터는 Automatic Rebalance 서비스 실행 시 자동으로 클러스터의 데이터 불균형을 조정해 줍니다.

Automatic Rebalance(자동 재조정) : vSAN 6.7 U3 부터  디스크 재조정은 더 이상 수동 방법이 아니며 vSAN 클러스터 설정 내에서 서비스로 활성화해야 합니다(아래 설명). 이 기능이 사용하도록 설정되어 있지 않으면 vSAN 디스크가 80% 용량 임계값을 초과할 때만 vSAN이 vSAN 디스크에 대한 재조정을 시작합니다. 참고:  디스크 재조정은 vSAN 클러스터의 I/O 성능에 영향을 줄 수 있습니다. 이러한 성능 영향을 방지하기 위해 임계값을 변경하거나 최대 성능이 필요할 때 자동 재조정을 끌 수 있습니다.

그렇다면 Automatic Rebalance(자동 재조정)을 활성화해야 합니까?

예, vSAN 클러스터에서 자동 재조정 기능을 활성화하는 것이 좋습니다.  기능이 6.7 U3에 추가되었을 때 VMware는 고객 환경에 이 기능을 천천히 도입하기를 원했으며 vSAN 7에서도 이 방식을 유지했습니다. 최신 버전의 스케줄러 및 재동기화에 대한 최적화로 이 기능은 기본적으로 다음에서 활성화됩니다. 

클러스터에서 자동 재조정을 일시적으로 비활성화하려는 드문 경우가 있을 수 있습니다. 짧은 시간에 기존 클러스터에 많은 수의 추가 호스트를 추가하는 것이 그러한 가능성 중 하나일 수 있으며 기본 테스트에 사용되는 중첩된 랩 환경일 수도 있습니다. 대부분의 경우 자동 재조정을 활성화해야 합니다.