OPM

vCenter 인증서에 대해 알아봅시다.

vCenter GUI 에서 인증서 관리 페이지를 보면 인증서를 확인 할 수 있습니다.

• 시스템 SSL 인증서
• VMware Certificate Authority 인증서
• STS 서명 인증서
• 신뢰할 수 있는 루트 인증서

하지만 VCSA에서 CLI로 확인하면 다음과 같이 더 많은 하위 인증서를 확인 할 수 있습니다.

for store in $(/usr/lib/vmware-vmafd/bin/vecs-cli store list | grep -v TRUSTED_ROOT_CRLS); do echo "[*] Store :" $store; /usr/lib/vmware-vmafd/bin/vecs-cli entry list --store $store --text | grep -ie "Alias" -ie "Not After";done;

• Machine SSL CERT
• TRUSTED ROOTS
• Machine
• vsphere-webclient
• vpxd
• vpxd-extension
• hvc
• data-encipherment : 게스트 OS 사용자 지정을 위해 VPXD 서비스에서 사용됩니다.
• applmgmt_password
• SMS
• wcp

노란색 부분을 Solution User 인증서라고 합니다.

1. Slack 세팅을 해줍니다.

• 워크스페이스 생성 (생략)
• 채널 생성 (생략)
• Webhook 구성

2. vCenter Server Appliance 설정

• 스크립트 생성
• 스크립트 작성
• 스크립트 권한 설정
• 스크립트 테스트

vi /slack.sh

#!/bin/bash
curl -X POST --data-urlencode "payload={\"monitor\": \"#vmware\", \"username\": \"webhookbot\", \"text\": \"Virtual Machine $VMWARE_ALARM_TARGET_NAME has changed state to $VMWARE_ALARM_NAME\",\"icon_emoji\": \":ghost:\"}" https://hooks.slack.com/services/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

3. vCenter Alarm 설정

화면과 같이 ESXi root 패스워드를 연속해서 잘못 입력을 하면 lock이 걸려 접속이 안됩니다.

콘솔에 직접 접속해서 

pam_tally2 --user root --reset 입력

몬스터 VM들의 vMotion 과제

상당한 수의 I / O를 처리하는 대규모 트랜잭션 데이터베이스 플랫폼은 vMotion 동안 성능 저하를 경험할 수 있습니다.

vSphere 7의 향상된 vMotion 로직은 이러한 모든 문제를 극복하고 성능 또는 가용성에 큰 영향을주지 않으면 서 대규모 워크로드를 실시간 마이그레이션 할 수 있습니다.

vSphere 7에서의 변화

• vMotion 로직 최적화
• 성능저하 감소
• 가상머신 스턴 타임 감소

vSphere 7의 이러한 vMotion 개선 사항을 통해 vMotion 동안 성능 저하없이 워크로드를 실시간으로 마이그레이션 할 수 있습니다. 다음 다이어그램은 vSphere 7에서 잠재적 인 성능 향상을 보여주는 테스트의 예입니다. 테스트 베드는 HammerDB 워크로드를 실행하는 큰 VM (72 vCPU / 512GB)입니다. 타임 라인에서 1 초 단위로 커밋 / 초를 모니터링합니다.

vSphere 6.7과 비교하여 vSphere 7에서이 테스트 중에 확인한 몇 가지 주요 사항은 다음과 같습니다.

• 더 이상 페이지 추적 단계에서 성능에 영향을 미치지 않습니다.
• 스턴 시간은 몇 초가 걸리지 않고 1 초 이내에 유지됩니다.
• 전체 라이브 마이그레이션 시간은 거의 20 초 짧습니다.

vSphere7 vMotion Logic

• 메모리 사전 복사 최적화
• 페이지 테이블 세분성
• 전환 단계 향상
• 성능 개선

1. 메모리 사전 복사 최적화

1-1 VMware7 이전 버전에서 vMotion 원리

 vMotion 프로세스는 VM에 대해 구성된 모든 vCPU에 페이지 추적 프로그램을 설치합니다. 이렇게하면 vMotion은 어떤 메모리 페이지를 덮어 쓰는지 이해합니다. 이를 페이지 추적 중 'Page Fire'이라고합니다. 실시간 마이그레이션 된 VM의 모든 vCPU에 추적 작업을 배포합니다.

  페이지 추적 프로그램을 설치하고 페이지 실행을 처리하기 위해 vCPU가 잠시 중지됩니다. 마이크로 초에 불과하지만 모든 vCPU를 중지하면 워크로드가 중단됩니다. VM의 컴퓨팅 리소스를 확장하면 vMotion 작업의 영향이 커집니다.

추적 작업을 위해 vCPU를 중지 한 후 모든 메모리 페이지 테이블 항목 (PTE) 이 읽기 전용으로 설정되고 TLB (Translation Lookaside Buffers) 가 플러시되어 TLB 적중을 방지하고 페이지 테이블을 강제로 이동하여 vMotion 프로세스가 완전히 이해합니다. 덮어 쓴 메모리 페이지 이 블로그 게시물에서 이러한 메모리 구성 에 대해 자세히 알아보십시오 . 여기에 설명 된 방법을 "Stop-based Page Trace Install"라고합니다.

1-2 vSphere7 에서 vMotion 하는 방법

 가장 큰 영향은 페이지 추적을 위해 모든 vCPU를 중지해야한다는 것입니다. 모든 vCPU를 중지 할 필요없이 페이지 추적 프로그램을 설치할 수 있다면 어떨까요? vSphere 7에서는“Loose Page Trace Install”이 도입되었습니다. 페이지 추적 방법은 대부분 동일하지만 모든 vCPU를 사용하는 대신 모든 추적 작업을 수행하기 위해 하나의 vCPU 만 청구합니다. VM에 권한이 부여 된 다른 모든 vCPU는 중단없이 계속 워크로드를 실행합니다.

 페이지 트레이서는 요청된 하나의 vCPU에 설치되고 모든 PTE를 읽기 전용으로 설정합니다. TLB는 vCPU에 따라 다르므로 각 vCPU는 여전히 해당 TLB를 플러시해야합니다. 그러나 이것은 영향을 최소화하기 위해 다른 시간에 발생합니다. 전체적으로이 방법은 하나의 vCPU 만 페이지 추적에 사용되므로 훨씬 효율적입니다.

2.페이지 테이블 세분성

따라서 추적 비용을 줄 였지만 더 효율적으로 만들 수 있다면 어떨까요?

메모리를 읽기 전용으로 설정하는 방식을 최적화했습니다. 즉,이 부분에서 수행 할 작업이 줄어 듭니다. 적은 작업으로 효율성이 향상됩니다.

2-1 이전버전에서 메모리 읽기방식

vSphere 7 이전의 메모리가 읽기 전용으로 설정되는 방식은 4KB 페이지 단위입니다. vSphere 7 이전 버전에서는 모든 개별 4KB 페이지를 읽기 전용 액세스로 설정해야했습니다.

2-2 vSphere 7에서 부터 메모리 읽기 방식

vSphere 7부터 VMM (Virtual Machine Monitor) 프로세스는 1GB 페이지에서 더 큰 단위로 읽기 전용 플래그를 설정합니다. 페이지 실행 (메모리 페이지 덮어 쓰기)이 발생하면 1GB PTE가 2MB 및 4KB 페이지로 나뉩니다. VMware 엔지니어는 일반적으로 vMotion 프로세스 중에 VM이 모든 메모리를 건드리지 않는 것으로 나타났습니다. vMotion 중 메모리 작업 세트 크기는 일반적으로 10-30 %입니다. vMotion 시간 동안 더 많은 메모리를 사용하면 비용 효율성이 떨어집니다.

1. 전환 단계 향상

지금까지 논의한 모든 개선 사항은 추적이 발생하는 메모리 사전 복사 단계에서 수행됩니다. 메모리 수렴 단계에 도달하면 거의 모든 메모리가 대상 호스트에 복사되고 vMotion이 대상 ESXi 호스트로 전환 할 수 있습니다. 이 마지막 단계 에서 소스 ESXi 호스트의 VM이 일시 중단되고 검사 점 데이터가 대상 호스트로 전송됩니다 . 전환 시간 (Stun Time)은 1 초 이하가되어야합니다. 대규모 VM의 경우 시간이 지남에 따라 증가하는 워크로드 크기로 인해 이는 문제가되었습니다.

전환 단계에서는 검사 점 데이터와 메모리 비트 맵을 보냅니다. 메모리 비트 맵은 VM의 모든 메모리를 추적하는 데 사용됩니다. 어떤 페이지를 덮어 쓰고 대상 ESXi 호스트로 전송해야하는지 알고 있습니다. vMotion이 마지막 메모리 페이지를 전송함에 따라 대상 호스트의 VM 전원이 켜집니다. 그러나 전송을 위해 남은 마지막 페이지가 여전히 필요할 수 있습니다. 대상에서 이러한 페이지를 식별하기 위해 소스에서 전송 된 비트 맵을 사용합니다. 고객이 메모리를 초과 커밋하는 경우 스왑 아웃 페이지는 선택적 스왑 비트 맵에서 추적됩니다.

메모리 비트 맵이 드문 드문 나 있습니다. 여기에는 마지막 메모리 페이지와 VM에서 사용중인 모든 메모리 페이지의 정보가 포함됩니다. 1GB의 메모리가있는 VM의 메모리 비트 맵 크기는 32KB입니다. 32KB를 전송하는 데 밀리 초가 걸립니다 : 문제 없습니다!

이 단계에서는 대부분의 메모리 페이지를 이미 복사 했으므로 마지막으로 남은 메모리 페이지 만 보내면됩니다. vMotion은 압축 된 메모리 비트 맵을 사용하여 밀리 초 단위로 큰 VM에 대한 비트 맵을 전송하여 기절 시간을 크게 줄입니다.

결론

vSphere 7에서 vMotion 성능이 엄청나게 개선 되었습니다.

출처 : https://blogs.vmware.com/vsphere/2020/03/vsphere-7-vmotion-enhancements.html

모듈 및 정보 : 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에서 잠재적으로 성능 문제를 일으킬 수 있습니다.

운영중인 윈도우 서버를 온라인 복제를 하려 했지만 9프로에서 Fail 발생합니다.

이를 해결하는 방법 포스팅 합니다.

테스트 OS : Windows 2019

출처 kb.vmware.com/s/article/1028881

이렇게 설정하면 윈도우 서버 핫클론이 잘진행 됩니다.

Advanced Cross vCenter Server vMotion (XVM) 기능은 가장 인기있는 VMware Fling 중 하나였습니다 . 많은 고객이이 기능이 vSphere의 통합 된 부분이되기를 원했습니다. vSphere 7 업데이트 1c 릴리스에서는 XVM 기능이 vSphere Client에 포함되었습니다!

vCenter 6.0의 vCenter vMotion과 vCenter 7 U1c의 XVM은 비슷하지만 다릅니다.

vCenter vMotion은 동일 SSO내에서만 vMotion이 가능하지만 XVM은 ELM (Enhanced Linked Mode) 또는 HLM (Hybrid Linked Mode)에 대한 요구 사항없이 vCenter Server 인스턴스간에 가상 워크로드를 마이그레이션하는 데 도움이됩니다. 즉, 서로 다른 SSO (Single Sign-On) 도메인에있는 vCenter Server간에 VM (가상 머신)을 마이그레이션 할 수 있습니다.

이에 대한 일반적인 시나리오는 온 프레미스 vSphere 인프라에서 AWS의 VMC로 워크로드 마이그레이션입니다. vCenter Server 구성의 제약없이 마이그레이션하면 많은 마이그레이션 '자유'가 가능합니다. XVM은 단일 VM 또는 대량 마이그레이션에 사용할 수 있습니다.

Important Notes

마이그레이션은 일반 vMotion과 같이 vMotion vmkernel 포트를 사용합니다. 따라서 소스 및 대상 호스트는 vMotion 포트를 사용하여 통신 할 수 있어야합니다. 양쪽 모두에서 TCP / IP Stack vMotion 을 사용했습니다.

 Use-cases

SSO 관점에서 구성에 대한 제약없이 vCenter Server 인스턴스간에 워크로드를 대량 마이그레이션하는 기능은 vSphere 환경간에 워크로드를 이동하는 강력한 도구입니다. 소스와 대상 vCenter Server 인스턴스 간의 연결이 올바르게 설정되면 XVM 기능이 도움이되는 수많은 사용 사례가 있습니다! 다음 사용 사례를 고려하십시오.

• HLM (하이브리드 연결 모드) 및 추가 구성없이 온 프레미스 vSphere 환경에서 AWS의 VMC로 VM을 마이그레이션합니다.
• 이전 vCenter Server 인스턴스에서 모든 워크로드를 마이그레이션하여 새 vSphere 버전을 채택합니다.
• VCF 업그레이드의 일부로 워크로드 마이그레이션.
• 데이터 센터 통합 및 콜로 대피.
• 일반적으로 이전 vSphere 버전을 포함하는 레거시 하드웨어를 폐기합니다.
• 글로벌 VCF 환경에서 워크로드 재조정.
• VMware Cloud 오퍼링으로 마이그레이션하십시오.

출처 : vnote42.net/2021/01/19/how-advanced-cross-vcenter-vmotion-works/

출처 : core.vmware.com/resource/introducing-advanced-cross-vcenter-server-vmotion-capability#section1

스냅샷을 제거하였는데 위 사진과 같이 99퍼센트에서 멈췄습니다.

스냅샷 파일도 그대로 있습니다.

vim-vmd vmsvc/getallvms 입력하면 107번 vmid 가상머신을 확인 할 수 있습니다.

vim-cmd vmsvc/get.tasklist 107 입력하면
removeAllSnapshots 271496505 가출력됩니다. (사이트마다 다름)
vim-cmd vimsvc/task_info 271496505 입력하면
메세지 출력을 확인 할 수 있습니다.

가장 정확한 방법입니다.
저 99%가 hang인지 아닌지 확인하는 방법
해당 가상머신이 있는 호스트에 ssh로 접 근후 esxtop 접속 > u 입력 합니다.
저기서 스냅샷이 존재하는 데이터스토어의 naa 패스의 MBREAD/s MBWRTN/s 값을 확인합니다.
다른 naa 패스에는 IO가 거의 없지만 스냅샷이 존재하는 데이터 스토어의 패스에는 IO가 발생하는 것을 확인됩니다.

결론은 저 99%가 행이 아닙니다.
스냅샷을 제거하고 consolidate 하는 작업입니다.
스냅샷 총 용량 150GB 기준 consolidate 작업만 약 7시간 걸렸습니다. (참고)

99%에서 완료 후 스냅샷 파일들 모두 제거 되었고 수정날짜도 금일 날짜로 변경 되었습니다.

tasklist도 remove all snapshot 없어졌습니다.

MBREAD/s MBWRTN/s 확인 해보니 IO사라졌습니다.

출처 :https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2053758
http://blog-stack.net/esxi-remove-all-snapshots-hangs-at-99/

1. ESXi 로그 수집

vm-support -w /vmfs/volumes/DATASTORE_NAME

2. ESXi 데몬 덤프 수집

vmkbacktrace -w -n hostd -td /vmfs/volumes/DATASTORE_NAME

2. vSAN RVC 로그 수집(루비 콘솔 수집)

/usr/bin/rvc -c "vsan.support_information 1" -c "quit" administrator@vsphere.local:'VMware1!'@vCenter FQDN > /tmp/rvc.log

참고: https://kb.vmware.com/s/article/2091539

3. ESXi esxcli vsan 명령어 수행 

esxcli vsan storage list > /tmp/storagelist

esxcli vsan cluster get > /tmp/clusterget

별첨 ) VCSA 파일 반출

xftp외의 다른 프로그램 FILEZLIA or Winscp로 접속하면 접근이 안됨

chsh -s /bin/bash

명령어를 수행해준 뒤 접속하면 접속된다

기본 설정 chsh -s /bin/appliancesh

Show configuration
ESXi 5.5 -> /opt/hp/hpssacli/bin/hpssacli ctrl all show config
ESXi 6.5 -> /opt/smartstorageadmin/ssacli/bin/ssacli ctrl all show config

Controller status
ESXi 5.5 -> /opt/hp/hpssacli/bin/hpssacli ctrl all show status
ESXi 6.5 -> /opt/smartstorageadmin/ssacli/bin/ssacli ctrl all show status

Show detailed controller information for all controllers
ESXi 5.5 -> /opt/hp/hpssacli/bin/hpssacli ctrl all show detail
ESXi 6.5 -> /opt/smartstorageadmin/ssacli/bin/ssacli ctrl all show detail

Show detailed controller information for controller in slot 0
ESXi 5.5 -> /opt/hp/hpssacli/bin/hpssacli ctrl slot=0 show detail
ESXi 6.5 -> /opt/smartstorageadmin/ssacli/bin/ssacli ctrl slot=0 show detail

Rescan for New Devices
ESXi 5.5 -> /opt/hp/hpssacli/bin/hpssacli rescan
ESXi 6.5 -> /opt/smartstorageadmin/ssacli/bin/ssacli rescan

Physical disk status
ESXi 5.5 -> /opt/hp/hpssacli/bin/hpssacli ctrl slot=0 pd all show status
ESXi 6.5 -> /opt/smartstorageadmin/ssacli/bin/ssacli ctrl slot=0 pd all show status

Show detailed physical disk information
ESXi 5.5 -> /opt/hp/hpssacli/bin/hpssacli ctrl slot=0 pd all show detail
ESXi 6.5 -> /opt/smartstorageadmin/ssacli/bin/ssacli ctrl slot=0 pd all show detail

Logical disk status
ESXi 5.5 -> /opt/hp/hpssacli/bin/hpssacli ctrl slot=0 ld all show status
ESXi 6.5 -> /opt/smartstorageadmin/ssacli/bin/ssacli ctrl slot=0 ld all show status

View Detailed Logical Drive Status
ESXi 5.5 -> /opt/hp/hpssacli/bin/hpssacli ctrl slot=0 ld 2 show
ESXi 6.5 -> /opt/smartstorageadmin/ssacli/bin/ssacli ctrl slot=0 ld 2 show

Create New RAID 0 Logical Drive
ESXi 5.5 -> /opt/hp/hpssacli/bin/hpssacli ctrl slot=0 create type=ld drives=1I:1:2 raid=0
ESXi 6.5 -> /opt/smartstorageadmin/ssacli/bin/ssacli ctrl slot=0 create type=ld drives=1I:1:2 raid=0

Create New RAID 1 Logical Drive
ESXi 5.5 -> /opt/hp/hpssacli/bin/hpssacli ctrl slot=0 create type=ld drives=1I:1:1,1I:1:2 raid=1
ESXi 6.5 -> /opt/smartstorageadmin/ssacli/bin/ssacli ctrl slot=0 create type=ld drives=1I:1:1,1I:1:2 raid=1

Create New RAID 5 Logical Drive
ESXi 5.5 -> /opt/hp/hpssacli/bin/hpssacli ctrl slot=0 create type=ld drives=1I:1:1,1I:1:2,2I:1:6,2I:1:7,2I:1:8 raid=5
ESXi 6.5 -> /opt/smartstorageadmin/ssacli/bin/ssacli ctrl slot=0 create type=ld drives=1I:1:1,1I:1:2,2I:1:6,2I:1:7,2I:1:8 raid=5

Delete Logical Drive
ESXi 5.5 -> /opt/hp/hpssacli/bin/hpssacli ctrl slot=0 ld 2 delete
ESXi 6.5 -> /opt/smartstorageadmin/ssacli/bin/ssacli ctrl slot=0 ld 2 delete

Add New Physical Drive to Logical Volume
ESXi 5.5 -> /opt/hp/hpssacli/bin/hpssacli ctrl slot=0 ld 2 add drives=2I:1:6,2I:1:7
ESXi 6.5 -> /opt/smartstorageadmin/ssacli/bin/ssacli ctrl slot=0 ld 2 add drives=2I:1:6,2I:1:7

Add Spare Disks
ESXi 5.5 -> /opt/hp/hpssacli/bin/hpssacli ctrl slot=0 array all add spares=2I:1:6,2I:1:7
ESXi 6.5 -> /opt/smartstorageadmin/ssacli/bin/ssacli ctrl slot=0 array all add spares=2I:1:6,2I:1:7

Enable Drive Write Cache
ESXi 5.5 -> /opt/hp/hpssacli/bin/hpssacli ctrl slot=0 modify dwc=enable
ESXi 6.5 -> /opt/smartstorageadmin/ssacli/bin/ssacli ctrl slot=0 modify dwc=enable

Disable Drive Write Cache
ESXi 5.5 -> /opt/hp/hpssacli/bin/hpssacli ctrl slot=0 modify dwc=disable
ESXi 6.5 -> /opt/smartstorageadmin/ssacli/bin/ssacli ctrl slot=0 modify dwc=disable

Erase Physical Drive
ESXi 5.5 -> /opt/hp/hpssacli/bin/hpssacli ctrl slot=0 pd 2I:1:6 modify erase
ESXi 6.5 -> /opt/smartstorageadmin/ssacli/bin/ssacli ctrl slot=0 pd 2I:1:6 modify erase

Turn on Blink Physical Disk LED
ESXi 5.5 -> /opt/hp/hpssacli/bin/hpssacli ctrl slot=0 ld 2 modify led=on
ESXi 6.5 -> /opt/smartstorageadmin/ssacli/bin/ssacli ctrl slot=0 ld 2 modify led=on

Turn off Blink Physical Disk LED
ESXi 5.5 -> /opt/hp/hpssacli/bin/hpssacli ctrl slot=0 ld 2 modify led=off
ESXi 6.5 -> /opt/smartstorageadmin/ssacli/bin/ssacli ctrl slot=0 ld 2 modify led=off

Modify smart array cache read and write ratio (cacheratio=readratio/writeratio)
ESXi 5.5 -> /opt/hp/hpssacli/bin/hpssacli ctrl slot=0 modify cacheratio=100/0
ESXi 6.5 -> /opt/smartstorageadmin/ssacli/bin/ssacli ctrl slot=0 modify cacheratio=100/0

Enable smart array write cache when no battery is present (No-Battery Write Cache option)
ESXi 5.5 -> /opt/hp/hpssacli/bin/hpssacli ctrl slot=0 modify nbwc=enable
ESXi 6.5 -> /opt/smartstorageadmin/ssacli/bin/ssacli ctrl slot=0 modify nbwc=enable

Disable smart array cache for certain Logical Volume
ESXi 5.5 -> /opt/hp/hpssacli/bin/hpssacli ctrl slot=0 logicaldrive 1 modify arrayaccelerator=disable
ESXi 6.5 -> /opt/smartstorageadmin/ssacli/bin/ssacli ctrl slot=0 logicaldrive 1 modify arrayaccelerator=disable

Enable smart array cache for certain Logical Volume
ESXi 5.5 -> /opt/hp/hpssacli/bin/hpssacli ctrl slot=0 logicaldrive 1 modify arrayaccelerator=enable
ESXi 6.5 -> /opt/smartstorageadmin/ssacli/bin/ssacli ctrl slot=0 logicaldrive 1 modify arrayaccelerator=enable

Enable SSD Smart Path
ESXi 5.5 -> /opt/hp/hpssacli/bin/hpssacli ctrl slot=0 array a modify ssdsmartpath=enable
ESXi 6.5 -> /opt/smartstorageadmin/ssacli/bin/ssacli ctrl slot=0 array a modify ssdsmartpath=enable

Disable SSD Smart Path
ESXi 5.5 -> /opt/hp/hpssacli/bin/hpssacli ctrl slot=0 array a modify ssdsmartpath=disable
ESXi 6.5 -> /opt/smartstorageadmin/ssacli/bin/ssacli ctrl slot=0 array a modify ssdsmartpath=disable

BIOS Information

vish 

get /hardware/bios/biosInfo

출처 : kallesplayground.wordpress.com/useful-stuff/hp-smart-array-cli-commands-under-esxi/

vCLS (vSphere Clustering Service)는 vSphere 7 업데이트 1 릴리스에 도입 된 새로운 기능입니다 . 첫 번째 릴리스는 vSphere의 클러스터링 서비스를 위해 분리되고 분산 된 제어 플레인을 생성하기위한 기반을 제공합니다.

문제는 vSphere DRS (Distributed Resource Scheduler)와 같은 클러스터 서비스가 구성 및 운영을 위해 vCenter Server 가용성에 의존한다는 것입니다. vCenter Server의 가용성을 높일 수있는 방법이 있지만 vSphere HA (고 가용성) 및 VCHA ( vCenter Server High Availability )에 대해 생각해보십시오 . 종속성은 이상적이지 않습니다. 또한 대규모 온 프레미스 및 퍼블릭 클라우드에서 vCenter Server 확장 성을 고려할 때 클러스터링 서비스를 지원하는 더 나은 솔루션이 필요합니다. 이것이 vCLS가 도입 된 이유입니다. 첫 번째 릴리스에서는 DRS 기능의 하위 집합이 이미 새로운 vCLS 기능을 사용하고 있습니다.

기본 아키텍처

vCLS 컨트롤 플레인의 기본 아키텍처는 최대 3 개의 VM (가상 머신)으로 구성되며 클러스터의 개별 호스트에 배치되는 시스템 또는 에이전트 VM이라고도합니다. 이들은 클러스터 쿼럼을 형성하는 경량 에이전트 VM입니다. 호스트가 3 개 미만인 소규모 클러스터에서 에이전트 VM의 수는 ESXi 호스트의 수와 같습니다. 에이전트 VM은 vSphere Cluster Services에서 관리합니다. 사용자는 에이전트 VM의 수명주기 또는 상태를 유지할 것으로 예상되지 않으며 일반적인 워크로드 VM처럼 취급해서는 안됩니다.

클러스터 서비스 상태

클러스터 쿼럼 상태를 형성하는 에이전트 VM은 자체 수정됩니다. 즉, 에이전트 VM을 사용할 수없는 경우 vCLS가 VM을 자동으로 인스턴스화하거나 전원을 켭니다.

클러스터 서비스에 대한 세 가지 상태가 있습니다.

• 정상 – 클러스터에서 하나 이상의 에이전트 VM이 실행 중이면 vCLS 상태가 녹색입니다. 에이전트 VM 가용성을 유지하기 위해 3 개의 에이전트 VM이 배포 된 클러스터 쿼럼이 있습니다.
• Degraded – 에이전트 VM 중 하나 이상을 사용할 수 없지만 DRS가 에이전트 VM을 사용할 수 없어 논리를 건너 뛰지 않은 경우 일시적인 상태입니다. vCLS VM 중 하나가 다시 배포되거나 실행중인 VM에 영향을 준 후 전원이 켜질 때 클러스터는이 상태 일 수 있습니다.
• 비정상 – vCLS 제어 플레인을 사용할 수 없어 (최소 1 개의 에이전트 VM) DRS 논리의 다음 실행 (워크로드 배치 또는 균형 조정 작업)을 건너 뛸 때 vCLS 비정상 상태가 발생합니다.

에이전트 VM 리소스

vCLS 에이전트 VM은 경량이므로 리소스 소비가 최소로 유지됩니다. vCLS는 vCenter Server가 vSphere 7 업데이트 1로 업그레이드 될 때 기존 배포에서 클러스터 당 최대 3 개의 에이전트 VM을 자동으로 생성합니다. 그린 필드 시나리오에서는 ESXi 호스트가 새 클러스터에 추가 될 때 생성됩니다. 공유 스토리지를 사용할 수없는 경우 에이전트 VM은 로컬 스토리지에 배치됩니다. vSAN을 사용할 때와 같이 ESXi 호스트에 공유 스토리지가 구성되기 전에 클러스터가 형성되는 경우 vCLS 에이전트 VM을 나중에 공유 스토리지로 이동하는 것이 좋습니다.

에이전트 VM은 사용자 정의 된 Photon OS를 실행합니다. 에이전트 VM 당 리소스 사양은 다음 표에 나열되어 있습니다.

2GB 가상 디스크는 씬 프로비저닝됩니다. 또한 관련된 네트워킹이 없으므로 구성된 네트워크 어댑터가 없습니다. 에이전트 VM은 vSphere Client 의 호스트 및 클러스터 개요에 표시되지 않습니다 . 이제 VM 및 템플릿 보기에 모든 vCLS 에이전트 VM이 포함 된 새 폴더 vCLS가 포함됩니다. 클러스터가 여러 개인 경우 모든 vCLS 에이전트 VM이 연속적으로 번호가 지정되어 표시됩니다.

vSphere Client에는 vCLS 에이전트 VM에 대한 정보를 표시하는 메시지와 메모가 포함되어 있으며 이러한 VM의 전원 상태 및 리소스가 vCLS에서 처리된다는 내용도 포함되어 있습니다.

운영

앞에서 언급했듯이 에이전트 VM은 vCLS에서 유지 관리됩니다. VI 관리자가 VM의 전원을 끌 필요가 없습니다. 실제로 vSphere Client는 에이전트 VM의 전원이 꺼지면 경고를 표시합니다.

호스트가 유지 관리 모드로 전환되면 vCLS 에이전트 VM은 일반 VM과 같이 클러스터 내의 다른 호스트로 마이그레이션됩니다. 고객은 클러스터 서비스를 정상 상태로 유지하기 위해 에이전트 VM 또는 해당 폴더를 제거하거나 이름을 변경하지 않아야합니다.

vCLS 에이전트 VM의 수명주기는 vSphere EAM (ESX Agent Manager)에 의해 유지됩니다. Agent Manager는 VM을 자동으로 생성하거나 사용자가 VM의 전원을 끄거나 삭제하려고 할 때 VM을 다시 생성 / 전원을 켭니다. 

아래 예는 전원 끄기 및 삭제 작업을 볼 수 있습니다. EAM이 에이전트 VM을 자동으로 복구하는 두 가지 기능 모두

자동화 및 vCLS

스크립트를 사용하여 작업을 자동화하는 고객의 경우, 예를 들어 오래된 VM을 삭제하는 정리 스크립트와 같이 에이전트 VM을 무시하도록 인식을 구축하는 것이 중요합니다. vCLS 에이전트 VM 식별은 vCLS 폴더에 에이전트 VM이 나열되는 vSphere Client에서 빠르게 수행됩니다. 또한 관리> vCenter Server Extensions> vSphere ESX Agent Manager 아래의 VM 탭을 검사하면 해당 vCenter Server 인스턴스에서 관리하는 모든 클러스터의 에이전트 VM이 나열됩니다.

모든 에이전트 VM에는 추가 속성이 있으므로 특정 자동화 된 작업에서 무시할 수 있습니다. 이러한 속성은 MOB (Managed Object Browser)를 사용하여 찾을 수도 있습니다. 특정 속성은 다음과 같습니다.

• ManagedByInfo
  • extensionKey == “com.vmware.vim.eam”
  • type == “cluster-agent”

• ExtraConfig keys
  • “eam.agent.ovfPackageUrl”
  • “eam.agent.agencyMoId”
  • “eam.agent.agentMoId”

vCLS 에이전트 VM에는 "true"로 설정된 추가 데이터 속성 키 "HDCS.agent"가 있습니다. 이 속성은 EAM에서 명시 적으로 설정 한 다른 VM ExtraConfig 속성과 함께 ESXi 호스트에 자동으로 푸시 다운됩니다.

출처 : blogs.vmware.com/vsphere/2020/09/vsphere-7-update-1-vsphere-clustering-service-vcls.html