OPM

graylog는 중앙 집중식 로그 관리 시스템(LMS : log managemnet service)으로서 방대한 양의 로그 데이터를 집계, 구성 및 이해하는 수단을 제공 합니다.

기본적으로 graylog + 데이터 노드 + MongoDB로 구성 됩니다.

여기서 데이트 노드는 Elasticsearch 또는 OpenSearch중 선택해서 구성 가능 합니다.

이구성으로 페타바이트 규모의 로그 데이터를 심층적으로 분석할 수 있습니다.

기본적으로 아래와 같은 아키텍처로 구성 됩니다.

Senario

인터넷이안되는 폐쇠망 환경에서 VMware 인프라 오픈소스 모니터링 환경 구현

https://grafana.com/grafana/dashboards/8159-vmware-vsphere-overview/

Environment

OS : RockOS 9.2 (Blue Onyx)

Monitor: Grafana 10.0.2

DB : Influxdb2.7

Plugin : Telegraf 1.27.3

vCenter : 7.0.3

###사전 준비###

• 설치파일 다운로드 및 업로드 (Grafana, InfluxDB, Telegraf)
• OS 방화벽 (Firewalld 포트 오픈)

1. 설치파일 다운로드 및 업로드

1-1 Grafana rpm 파일 다운로드

https://grafana.com/grafana/download/10.0.2 접속 하여 설치 파일 다운로드

1-2 Influxdb rpm 파일 다운로드

https://docs.influxdata.com/influxdb/v2.7/install/?t=Linux 접속 하여 해당 링크에서 rpm 파일 다운로드

1-3 Telegraf rpm 파일 다운로드

https://github.com/influxdata/telegraf/releases 접속 하여 해당 링크에서 rpm 파일 다운로드

2. OS방화벽 포트 오픈 (Firewalld)

2-1 grafana 포트 오픈 (TCP:3000)

firewall-cmd --zone=public --permanent --add-port=3000/tcp

2-2 InfluxDB 포트 오픈 (TCP:8086)

firewall-cmd --zone=public --permanent --add-port=8086/tcp

2-3 Firewalld Reload

firewall-cmd --reload

2-4 --list-all 명령어를 이용하여 정상 확인

firewall-cmd --zone=public --list-all

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 인증서라고 합니다.

vSAN 성능 분석할 때 참고용 수치로 활용하시기 바랍니다.

스토리지레벨 성능 확인 시 백엔드 탭을 활용하면 됩니다.

하이퍼 바이저 유지보수 모드 후 60분뒤 데이터 리빌드가 일어나는데 해당 시간에 지연시간 및 미결 IO에 피크친 그래프가보여 놀라는 상황이 발생할 수 있습니다. 그러나 백그라운드 IO이며 VM레벨에서 영향 없음을 확인할 수 있습니다.

백앤드 데이터 수치를 하나하나 확인해 봅니다. 복구 쓰기 IOPS 가 발생했다는 것은 가상 오브젝트 리빌드가 발생했다는것을 의미합니다.

아래 수치 운영 시 참고 하세요 (호스트약 45대 1VSAN 클러스터 환경)

최대값 기준

읽기 IOPS : 183009

다시동기화 읽기 IOPS: 172808

쓰기 IOPS: 38596

복구 쓰기IOPS : 172438

최대값기준

읽기 처리량: 10.66GB/초

다시동기화 읽기 처리량 : 10.55GB/초

쓰기 처리량  : 416.24MB/초

복구 쓰기 처리량 : 10.52GB 초

최대값 기준

읽기 지연 시간 : 47.541밀리초

다시 동기화 읽기 지연 시간: 1.621밀리초

쓰기 지연 시간 : 0.321

복구 쓰기 지연 시간 : 61.428 밀리초  

최대값 기준

정체 : 0

최대값기준

미결 IO : 1,570

어떤 애플리케이션을 ? -> pod

얼마나 ? -> ReplicaSet

어디에 ? -> Node, Namespace

어떤방식으로 배포? -> Deployment

어떻게 로드밸런싱 ? -> Service, Endpoints

kubectl 명령어 사용 시 아래와 같은 상황이 발생하며 실행이 안됩니다.

The connection to the server localhost:8080 was refused - did you specify the right host or port?

현재 사용자의 홈디렉토리 하위의 .kube 폴더의 config 파일 존재 확인해 봅니다.

~/.kube/config 파일 유무 확인

Unable to connect to the server: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "kubernetes")

unset KUBECONFIG
export KUBECONFIG=/etc/kubernetes/admin.conf
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

해당 명령어를 수행하여 해결한다

VM 사전 준비

호스트 네임 변경

sudo -i

sudo hostnamectl set-hostname k8s-master

sudo -i

swap 해제

swapoff -a

sudo sed -i '/ swap / s/^/#/' /etc/fstab

방화벽 해제

sudo ufw disable

필요 패키지 설치

sudo apt-get update -y

sudo apt-get install -y curl ethtool ebtables socat conntrack

iptables 설정

cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
br_netfilter
EOF
cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
EOF
sudo sysctl --system

Docker 설치

sudo apt-get -y update
sudo apt-get -y install \
apt-transport-https \
ca-certificates \
curl \
gnupg \
lsb-release

Docker의 공식 GPG키 추가

curl -fsSL https://download.docker.com/linux/ubuntu/gpg |\
sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg

안정적 저장소 설정

echo \
"deb [arch=amd64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] \
https://download.docker.com/linux/ubuntu \
$(lsb_release -cs) stable" | \
sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

도커 엔진 설치

sudo apt-get -y update

sudo apt-get -y install docker-ce docker-ce-cli containerd.io

cgroup 설정

sudo mkdir /etc/docker
cat <<EOF | sudo tee /etc/docker/daemon.json
{
"exec-opts": ["native.cgroupdriver=systemd"],
"log-driver": "json-file",
"log-opts": {
"max-size": "100m"
},
"storage-driver": "overlay2"
}
EOF

도커 실행 및 확인

sudo systemctl enable docker
sudo systemctl daemon-reload
sudo systemctl restart docker
sudo systemctl status docker

Kubernetes 설치

apt패키지 인덱스를 업데이트하고 Kubernetes apt저장소를 사용하는 데 필요한 패키지를 설치

sudo apt-get -y update

sudo apt-get install -y apt-transport-https ca-certificates curl

Google Cloud 공개 서명 키 다운로드

sudo curl -fsSLo /usr/share/keyrings/kubernetes-archive-keyring.gpg \
https://packages.cloud.google.com/apt/doc/apt-key.gpg

K8S apt 리포지토리 추가

echo "deb \
[signed-by=/usr/share/keyrings/kubernetes-archive-keyring.gpg] \
https://apt.kubernetes.io/ kubernetes-xenial main" | \
sudo tee /etc/apt/sources.list.d/kubernetes.list

apt 패키지 색인을 업데이트하고, kubelet, kubeadm, kubectl을 설치하고 해당 버전을 고정

sudo apt-get -y update

sudo apt-get install kubeadm=1.22.11-00 kubelet=1.22.11-00 kubectl=1.22.11-00

sudo apt-mark hold kubelet kubeadm kubectl

systemctl enable --now kubelet

kubeadm 초기화

kubeadm init --pod-network-cidr=192.168.0.0/16 --apiserver-advertise-address=<Master IP>

<마스터 노드만 설정> 사용자에 대해 kubectl 작동하도록 설정

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
export KUBECONFIG=/etc/kubernetes/admin.conf

<마스터 노드만 설정> Calico 네트워크 플러그인 설치

kubectl create -f https://projectcalico.docs.tigera.io/manifests/tigera-operator.yaml

kubectl create -f https://projectcalico.docs.tigera.io/manifests/custom-resources.yaml

***POD network 변경시 wget 명령어로  https://projectcalico.docs.tigera.io/manifests/custom-resources.yaml

custom-resources.yaml 파일을 다운받고 IP 수정을 해준 뒤 로컬의 파일을 kubectl create -f 명령어로 실행 해 줘어야 한다. 디폴트는 192.168.0.0/16 

<마스터 노드만 설정> Calico pod 확인

watch kubectl get pods -n calico-system

<마스터 노드만 설정> Kubectl 자동완성 적용

source <(kubectl completion bash)
echo "source <(kubectl completion bash)" >> ~/.bashrc
source /etc/bash_completion
alias k=kubectl
complete -F __start_kubectl k

<마스터 노드만 설정> master node에도 pod 를 생성 할 수 있도록 설정

kubectl taint nodes --all node-role.kubernetes.io/master-

<워커 노드 설정>

sudo kubeadm join 10.20.1.6:6443 --token ixujii.6720hcftvfzfu6iz --discovery-token-ca-cert-hash sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

노드 확인

kubectl get nodes

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 입력

ETCD : ETCD 데이터 저장소는 Node, POD, Config, Secret, Account, Role, Binding 등과 같은 클러스터 정보를 저장 합니다.

Kube-apiserver : 클러스터 내의 모든 작업을 오케스트레이션 합니다.

Kubelet

몬스터 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

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에서도 이 방식을 유지했습니다. 최신 버전의 스케줄러 및 재동기화에 대한 최적화로 이 기능은 기본적으로 다음에서 활성화됩니다. 

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

CLOM (Cluster Level Obejct Manager)

CLOM(클러스터 수준 개체 관리자)은 개체 구성이 해당 스토리지 정책과 일치하는지 확인하는 역할을 합니다. CLOM은 해당 정책을 충족하는 데 사용할 수 있는 디스크 그룹이 충분한지 아닌지를 확인합니다. 또한 클러스터에서 구성 요소 및 감시 기능을 배치할 위치를 결정합니다.

CMMDS (Cluster Monitoring, Membership, and Directory Service )

CMMDS(클러스터 모니터링, 멤버 자격 및 디렉토리 서비스)는 네트워크로 연결된 노드 멤버 클러스터의 복구 및 유지 보수를 담당합니다. 호스트 노드, 디바이스 및 네트워크와 같은 항목의 인벤토리를 관리합니다. 또한 vSAN 개체에 대한 정책 및 RAID 구성과 같은 메타데이터 정보도 저장합니다.

DOM (Distributed Object Manager)

DOM(분산 개체 관리자)은 구성 요소를 생성하고 클러스터에 분산하는 역할을 합니다. DOM 개체가 생성되면 노드(호스트) 중 하나가 해당 개체에 대한 DOM 소유자로 지정됩니다. 이 호스트는 클러스터 전체에서 해당 하위 구성 요소를 찾은 후 vSAN 네트워크를 통해 해당 구성 요소로 I/O를 리디렉션함으로써 해당 DOM 개체에 대한 모든 IOPS를 처리합니다. DOM 개체에는 vdisk, snapshot, vmnamespace, vmswap, vmem 등이 포함됩니다.

LSOM (Log-Structured Object Manager)

LSOM(로그 구조 개체 관리자)은 vSAN 파일 시스템의 데이터를 vSAN 구성 요소 또는 LSOM 개체(데이터 구성 요소 또는 감시 구성 요소)로서 로컬로 저장하는 역할을 합니다.

vSAN 관련 Daemon

clomd
vsanObserver
vsandevicemonitord
vsandpd
vsanmgmtd
vsantraced

출처 : docs.vmware.com/kr/VMware-vSphere/7.0/vsan-network-design-guide/GUID-725668B0-B1B9-48A0-AB4F-A6386C7D649E.html

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

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

테스트 OS : Windows 2019

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

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

vSAN 6.7 U3버전 부터 SCSI-3 영구 예약 (SCSI3-PR) 지원을 추가합니다. 온 프레미스 지원과 함께 VMware Cloud on AWS 서비스에 처음 릴리스되었습니다.

이 통합을 통해 고객은 가용성 그룹으로 재구성하거나 대체 클라우드 서비스로 플랫폼을 재구성 할 필요없이 클러스터 된 SQL 워크로드를 VMware Cloud on AWS 서비스로 직접 가져올 수 있습니다.

How does it work?

SQL Server 클러스터를 구축하려면 여러 게스트 VM간에 디스크 리소스를 공유해야합니다. 그러면 기본 게스트 OS가 필요에 따라 장치를 이동하면서 소유권을 제어합니다. 최신 공유 스토리지 솔루션에서이를 수행하는 데 사용하는 메커니즘을 SCSI-3 영구 예약이라고합니다.

주어진 가상 디스크에서 SCSI3-PR 지원을 활성화하려면 :

1. 디스크 모드 를 Independent – ​​Persistent 로 설정하십시오 .
2. 하드 디스크는 또한 SCSI 버스 공유 가 Physical로 설정된 SCSI 컨트롤러에 연결되어야합니다 .
3. 최고성능을 위하여 PVSCSI(VMware Paravirtual) 컨트롤러를 사용하십시오
4. 마지막으로 영구 예약을 구성하는 데 충분히 중요한 데이터는 관리 효율성을 보장하기위한 전용 스토리지 정책이 필요할 것입니다.(옵션)

이 기능은 기본 게스트 OS 스토리지 vMotion에 대한 직접 디스크 액세스에 대한 책임을 넘기므로 Microsoft SQL Server에서 공유 디스크를 사용할 때 스냅 샷 및 복제 작업이 지원되지 않습니다.

결론

클러스터형 솔루션의 운영 단순화를 선호하는 고객은 이제 Microsoft SQL Server 클러스터의 검증 된 가용성과 VMware 하이브리드 클라우드 및 vSAN 스토리지 정책 기반 관리의 유연성 및 관리 용이성을 결합 할 수 있습니다.

출처 : blogs.vmware.com/virtualblocks/2019/03/04/native-sql-server-cluster-support-on-vsan/

출처 : https://core.vmware.com/resource/sql-server-failover-cluster-instance-vmware-vsan-native#sec8219-sub2

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

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

클라이언트 드라이브 리디렉션 기능을 사용하여 로컬 클라이언트 시스템의 폴더 및 드라이브를 원격 데스크톱 및 게시된 애플리케이션과 공유할 수 있습니다.

공유 드라이브는 매핑된 드라이브 및 USB 스토리지 디바이스를 포함할 수 있습니다. 매핑된 드라이브는 UNC(Universal Naming Convention) 경로를 가질 수 있습니다.

공유 폴더 이름의 최대 길이는 117자입니다.

클라이언트 드라이브 리디렉션 기능은 Microsoft OneDrive, Google Drive 및 엔터프라이즈 파일 스토리지 공유를 지원하지 않습니다.

Windows 원격 데스크톱에서 공유 폴더 및 드라이브는 Windows 운영 체제 버전에 따라 내 PC 폴더 또는 컴퓨터 폴더에 표시됩니다. 메모장과 같은 게시된 애플리케이션에서 공유 폴더 또는 드라이브에 있는 파일을 탐색하고 열 수 있습니다.

로컬 파일 시스템에서 직접 게시된 애플리케이션에서 로컬 파일을 여는 기능을 켤 수도 있습니다. 이 기능을 사용할 경우 로컬 파일을 마우스 오른쪽 단추로 클릭하여 클라이언트 시스템의 연결 프로그램 메뉴를 선택하면 사용 가능한 게시된 애플리케이션이 나열됩니다.

파일을 두 번 클릭할 때 게시된 애플리케이션에서 파일이 자동으로 열리도록 설정할 수도 있습니다. 이 기능을 사용하면 특정 파일 확장명을 갖는 로컬 파일 시스템의 모든 파일이 사용자가 로그인한 서버에 등록됩니다. 예를 들어 Microsoft Word가 서버의 게시된 애플리케이션이면 로컬 파일 시스템에서 .docx 파일을 마우스 오른쪽 버튼으로 클릭하고 Microsoft Word 게시된 애플리케이션에서 파일을 열 수 있습니다.

클라이언트 드라이브 리디렉션 설정은 모든 원격 데스크톱 및 게시된 애플리케이션에 적용됩니다.

사전 요구 사항

원격 데스크톱 또는 게시된 애플리케이션과 폴더 및 드라이브를 공유하려면 Horizon 관리자가 클라이언트 드라이브 리디렉션 기능을 사용하도록 설정해야 합니다.

Horizon administrator는 Horizon Client에서 클라이언트 드라이브 리디렉션 기능을 숨길 수 있습니다.

프로시저

1. [설정] 대화 상자를 열고 [공유] 패널을 표시합니다.

2. 클라이언트 드라이브 리디렉션 설정을 구성 합니다.

다음에 수행할 작업

원격 데스크톱 또는 게시된 애플리케이션 내에서 공유 폴더를 볼 수 있는지 확인합니다.

• Windows 원격 데스크톱 내에서 Windows 운영 체제 버전에 따라 [파일 탐색기]를 열고 내 PC 폴더를 확인하거나 [Windows 탐색기]를 열고 컴퓨터 폴더를 확인합니다.
• 게시된 애플리케이션 내에서 파일 > 열기 또는 파일 > 다른 이름으로 저장을 선택하고 폴더 또는 드라이브로 이동합니다.

공유를 위해 선택한 폴더 및 드라이브는 다음 명명 규칙 중 하나(이상)를 사용할 수 있습니다.

일부 Horizon Agent 버전의 경우 리디렉션된 폴더가 Windows 10의 장치 및 드라이브와 네트워크 위치의 두 입구를 가질 수 있으며 두 입구는 동시에 나타날 수 있습니다. 모든 볼륨 레이블(A:~Z:)을 이미 사용 중인 경우 리디렉션된 폴더에는 하나의 입구만 있습니다.

출처 : docs.vmware.com/kr/VMware-Horizon-Client-for-Windows/5.4/horizon-client-windows-user/GUID-CFB7E9B1-63E0-418A-8814-572296507783.html

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/

Thin : 공간이 보장되지 않으며 디스크가 기록 될 때 사용됩니다.
thick (Lazy Thick) : 공간이 블록에 의해 예약되어 나중에 초기화되므로 VMFS는 블록이 처음 작성 될 때 제로잉 이됩니다.
EZT 또는 Eager Zero Thick : 전체 디스크가 제로잉이 되이므로 VMFS는 메타 데이터를 쓸 필요가 없습니다. VMFS는 메타 데이터 업데이트를 조정할 수 없으므로 공유 디스크 사용 사례에 필요합니다.

VMFS와 vSAN은 어떻게 다릅니까?
이러한 가상 디스크 유형은 vSAN에서 의미가 없습니다. vSAN 관점에서 모든 개체는 씬 입니다. 이것은 NFS가 항상 예비와 예약이 가능한 작업 (NFS VAAI 처럼)과 유사하지만 실제로 제로잉 하거나 VMFS에서와 같이 공간을 채우지 않는다는 사실을 바꾸지는 않습니다. VMFS에서 이것은 ATS와 WRITE_SAME을 사용하여 크게 완화 될 수 있습니다 (작업의 추가적인 개선으로). 얼마나 많은 데이터베이스와 응용 프로그램이 파일 시스템을 미리 작성하고 미리 할당 하는지를 감안할 때 저는이 이점에 대해 항상 모호했습니다. ext4 파일 시스템을 만드는 것이 더 느린 경우와 같은 몇 가지 코너 케이스가있을 수 있지만 정말로 신경 쓴다면 일반적으로 이 문제를 해결할 수 있다 (mkfs.ext4 -E nodiscard).

VAAI는 최신 All-Flash 어레이, VMFS6 개선 등의 이점이 있을 수 있지만 씬 VMDK에 대한 오버헤드는 크게 낮췄다. UNMAP/TRIM 스토리지 회수에는 씬 VMDK가 필요하므로 대부분의 사용 사례에서 씬(Thin)은 타당한 이유가 없는 기본값이 되도록 권장한다.

vSAN에서 씬을 선택하는 이유
EZT 디스크가 있다고해서 VMFS와 동일한 방식으로 vSAN 성능이 반드시 향상되는 것은 아닙니다. VMFS에서 먼저 제로잉을하면 메타 데이터 할당과 관련된 "번인"병목 현상을 피할 수있는 이점이 있습니다.

디스크 유형이 "thick"또는 "eager zero thick"으로 설정된 vSAN이 씬 vSAN 정책이 있음에도 불구하고 씩 동작하는 이유는 무엇입니까? 레거시 지원의 이유로 씩 VMDK 디스크 유형 집합은 SPBM 정책을 재정의한다. VM에서 "Thick Provisioning"을 사용해야 하는 경우 vSAN 옵션 "Object Space Reservation"이 100(Thick Provisioning)으로 설정된 상태로 VM에 스토리지 정책을 적용하십시오.

먼저 vSAN은 자체적으로 공간 예약을 제어합니다. Object Space Reservation 정책 즉 OSR = 100 % (Thick) 또는 OSR = 0 % (Thin). 이는 용량을 예약하고 클러스터의 공간 부족을 허용하는 할당을 방지하려는 경우에 사용됩니다.

In general, I recommend the default of “Thin” as it offers the most capacity flexibility and thick provisioning tends to be reserved for cases where it is impossible or incredibly difficult to ever add capacity to a cluster and you have very little active monitoring of a cluster.

FT 및 공유 디스크 사용 사례 (RAC, SQL, WFC 등)는 어떻습니까? 

이 요구 사항은 vSAN에 대해 제거되었습니다. vSAN의 경우 이러한 기능을 활용하기 위해 개체 공간 예약을 너무 두껍게 구성 할 필요도 없습니다. VMFS는 공유 된 VMDK 메타 데이터 업데이트를 단일 소유자가 소유하는 방식으로 인해 여전히 몇 가지 이점이있을 수 있습니다 (vSAN 메타 데이터 업데이트는 분산되므로 문제가되지 않음).

Thin VMDK를 기본값으로 사용하면 무엇을 얻을 수 있습니까?

당신은 많은 공간을 절약합니다. 업계의 다른 사람들과 대화하면 용량이 20-30 % 절약됩니다. TRIM / UNMAP 자동 회수와 결합하면 더 많은 공간을 다시 크롤링 할 수 있습니다! 이를 통해 스토리지 비용을 크게 절감 할 수 있습니다. 추가로 중복 제거 및 압축은 OSR = 0 %이고 기본 씬 VMDK 유형을 선택한 경우에만 의도 한대로 작동합니다.

또한 자동 회수하도록 구성된 경우 공간 부족 상태가 발생할 가능성이 낮아 가용성이 높아질 수 있습니다. vSAN의 Eager Zero Thick 또는 Thick VMDK는 vSAN에 대한 과잉 약정을 방지하는 방식으로 용량을 예약하지 않고 단순히 더 많은 용량을 사용합니다.

vSAN 데이터 스토어에 저장된 EZT 또는 씩 (thick) VMDK를 설정 한 경우 상태 경보가 예상됩니다. 잘못된 구성으로 간주됩니다. KB 66758에는 이에 대한 자세한 정보가 포함되어 있습니다 . 용량을 예약해야하는 경우 (당분간) SPBM 용량 예약 정책을 사용하십시오. 또한 William Lam에는이 주제에 대한 블로그도 있습니다.
출처 : blogs.vmware.com/virtualblocks/2020/11/16/thick-vs-thin-on-vsan-2020-edition/

VXRAIL환경에서 vCenter 구성시 두가지 방법이 있습니다.

초기 VXRAIL Manager에서 자동 배포하는 VXRAIL vCenter Server 방식

수동으로 VMware vCenter Server Appliance를 배포해서 Join 시키는 Customer-supplied vCenter 방식 이 있습니다.

- VXRAIL vCenter Server = VXRAIL Internal vCenter

VxRail의 초기 릴리스에서는 vCenter Server 장치를 VxRail 장치에 배포했습니다.
이 vCenter Server 장치의 라이센스가 VxRail에 포함되어 있습니다.
이 vCenter Server 배포를 "내부" 또는 "Internal vCenter"라고 합니다.
일관성을 위해 이 가이드에서 사용되는 용어는 VxRail vCenter Server입니다.
VxRail은 VxRail vCenter Server의 배포 및 수명 주기 관리를 조정합니다.
이 VxRail vCenter Server는 배포된 VxRail 클러스터만 관리할 수 있습니다.

- Customer-supplied vCenter = VXRAIL External vCenter = Existing vCenter

VxRail 장치는 선택적으로 VxRail 클러스터 외부에서 호스팅되는 호환 가능한 vCenter Server 환경에 가입할 수 있습니다.
이 기능을 사용하면 중앙 vCenter Server 인스턴스가 여러 VxRail 클러스터를 관리할 수 있습니다.
각 VxRail 환경은 vSAN 데이터스토어로 구성된 호스트의 클러스터로 vCenter Server 내에 나타납니다.
이 환경을 "external" 또는 "existing" vCenter Server라고 합니다.

일관성을 위해 이 가이드에서 사용되는 용어는 customer-supplied vCenter Server입니다.

이 vCenter Server 인스턴스는 VxRail 장치를 배포하기 전에 존재해야 하며 별도의 고객이 제공한 라이센스가 필요합니다.
고객이 제공한 vCenter Server의 배포, 구성 및 수명 주기 관리를 담당합니다.

VxRail 클러스터의 가상 인프라는 VxRail vCenter Server 또는 Customer-supplied vCenter와 같은 단일 vCenter Server 인스턴스에 의해 관리됩니다.

VxRail 장치를 배포할 때 vCenter 배포 유형이 선택되어 변경하기가 어렵습니다.

Customer-supplied vCenter 에서 VxRail vCenter Server로 변경하려면 출고 시 재설정해야 하며 모든 데이터를 VxRail 장치에서 지우고 다시 설치해야 합니다.

반면 VxRail vCenter Server를 Customer-supplied vCenter로 마이그레이션할 수는 있지만 제품 자격 확인 요청이 필요합니다.

참고 : Customer-supplied vCenter는 더 많은 구성 옵션을 제공하며 권장됩니다.

유형별 배포 방법

1. VxRail vCenter Server 7.0

VxRail 배포의 일부로 Embeded PSC가 있는 vCenter Server 인스턴스가 구성됩니다.

vCenter Server 및 PSC는 단일 Linux 기반 가상 시스템에서 호스팅됩니다.

Embeded PSC가 포함된 vCenter Server는 관리 중인 VxRail 클러스터에 배포되며 배포 후 클러스터 밖으로 이동할 수 없습니다.

VxRail vCenter의 라이센스는 VxRail vCenter Server용이며 Customer-supplied vCenter에 사용할 수 있도록 전송할 수 없습니다.

따라서 사용이 제한되거나 제한된 vCenter Server 라이센스로 간주 될 수 있습니다.

2. VxRail vCenter Server 6.0 – 6.7

VxRail 배포의 일부로 External PSC가 있는 vCenter Server 인스턴스가 구성됩니다.

vCenter Server와 PSC는 별도의 Linux 기반 가상 머신입니다.

VxRail vCenter Server와 PSC는 모두 관리 중인 VxRail 클러스터에 배포되며 배포 후 클러스터 밖으로 이동할 수 없습니다.

Use case
VxRail vCenter Server는 다음과 같은 경우에 적합합니다.
• Single VxRail clusters
• Standalone environments

참고:  Stretched clusters는 권장되지 않습니다.
왜냐하면 site-affinity rule(PFTT=0)이 사용되는 경우 ISL(Inter-Switch Link) 오류가 발생하고 
vCenter와 동일한 사이트에 있지 않은 모든 가상 시스템의 전원이 꺼지기 때문입니다.

Limitations (6.x 및 7.0)
• VxRail vCenter Server는 자체 VxRail 클러스터만 관리합니다.
• 다른 VxRail 클러스터 또는 다른 ESXi 호스트를 관리할 수 없습니다.
▪ 고객이 제공한 vCenter Server로 사용할 수 없습니다.
• 향상된 링크 모드는 VxRail 7.0.100 이상에서 지원됩니다.
• Single Sign-On 도메인은 vsphere.local이므로 사용자 지정할 수 없습니다.
• VxRail vCenter Server는 4.5.200 이전 버전의 VxRail 암호화를 지원하지 않습니다.

3. CustomerSupplied vCenter Server

다음 그림에서는 여러 VxRail 클러스터가 Customer-supplied vCenter 환경의 일부인 예를 보여 줍니다.

각 클러스터는 vCenter 내에서 별도의 클러스터로 나타납니다.

중앙 집중식 관리뿐만 아니라 동일한 vCenter 환경에 속하므로 vSAN 환경 간에 VM을 쉽게 마이그레이션하여 워크로드 균형을 최적화하고 VxRail 장치 업그레이드 및 확장을 간소화할 수 있습니다.

Use case
Customer-supplied vCenter 솔루션은 다음과 같은 경우에 필요합니다.
• VxRail이 기존 VMware 플랫폼에 추가되고 있으며 단일 관리 인스턴스가 필요합니다.
• 여러 VxRail 클러스터가 배포되며 단일 관리 인터페이스가 필요합니다.
• 2-노드 클러스터에는 vCenter Server를 배포할 수 없습니다.

VxRail 4.5.200 이전 버전에서는 다음과 같은 경우 Customer-supplied vCenter 솔루션이 필요합니다.
• 확장된 클러스터는 솔루션의 일부입니다.
• vSAN 암호화가 필요합니다. vSAN 클러스터에서 DARE(Data at Rest Encryption)를 사용하도록 설정하는 경우 KMS(Key Management Server)가 vSAN 클러스터 외부에 있어야 합니다.

Limitations
• VxRail Manager는 고객이 제공한 vCenter Server를 업그레이드하지 않습니다.
VxRail 장치 소프트웨어를 업그레이드하기 전에 릴리스 정보를 참조하여 필요한 최소 vCenter Server 릴리스 번호를 확인합니다. VxRail 업그레이드 전에 Customer-supplied vCenter를 업그레이드해야 할 수 있습니다.

• Customer-supplied vCenter 가 4.7 이전 버전을 실행하는 VxRail 클러스터에서 호스트되는 경우 RPQ가 필요합니다.

▪ VxRail 클러스터 종료 기능을 사용하려면 모든 VM의 전원을 수동으로 꺼야 합니다.
▪ vSAN 오류가 발생할 경우 vCenter를 원격 사이트에 백업하는 것이 좋습니다.

Notes
• Customer-supplied vCenter는 라이센스에 대한 책임이 있습니다.
• Customer-supplied vCenter를 사용할 경우 Log Insight가 활성화되지 않습니다.
• vCenter HA 네트워크에 대해 하나의 공용 IP 주소만 지원됩니다.

출처 : www.delltechnologies.com/resources/en-us/asset/technical-guides-support-information/products/converged-infrastructure/vxrail-vcenter-server-planning-guide.pdf