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

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

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

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

Horizon 연결 이해

Horizon 및 Blast 연결을 계획하거나 문제를 해결하기 전에 VMware Horizon Client가 리소스에 연결되는 방식을 이해하는 것이 중요합니다. 이를 통해 최상의 아키텍처를 결정하고 트래픽 흐름 및 네트워크 포트를 이해하며 문제 해결에 도움이 될 수 있습니다.

Horizon 연결 서버를 포함하여 VMware Horizon 7이 여기에 사용되지만 여기에 설명 된 대부분의 내용은 VMware Horizon Cloud에도 적용됩니다. 이 가이드는 Blast Extreme 연결에 중점을두고 있지만, 특히 연결 이해에 관한 대부분의 내용은 PCoIP 연결에도 적용됩니다.

이 가이드의 목적

이 가이드는 VMware Horizon Client와 리소스 간의 연결과 VMware Horizon 7 및 Horizon Cloud Services 모두에서 연결 문제를 해결하는 데 이러한 이해를 적용하는 방법에 중점을 둡니다.

대상 청중

이 가이드는 VMware vSphere 및 VMware vCenter Server®에 익숙한 IT 관리자 및 제품 평가자를 대상으로합니다. 가상 환경, Active Directory, ID 관리 및 디렉터리 서비스의 네트워킹 및 스토리지에 익숙하다고 가정합니다. Horizon 7과 같은 다른 기술에 대한 지식도 도움이됩니다.

구성 요소

Horizon 연결에 사용되는 Horizon 7의 핵심 구성 요소는 다음 표에 설명되어 있습니다.

표 1 : Horizon 7 구성 요소

1 차 및 2 차 프로토콜

먼저 Horizon Client가 Horizon 환경에 연결될 때 여러 다른 프로토콜이 사용되며 성공적인 연결은 두 단계로 구성된다는 점을 이해하는 것이 중요합니다.

연결의 첫 번째 단계는 항상 인증, 권한 부여 및 세션 관리를 제공하는 HTTPS를 통한 기본 XML-API 프로토콜입니다. 인증에 성공하면 하나 이상의 보조 프로토콜을 사용하여 리소스에 연결됩니다.

Horizon 7의 구성 요소 및 아키텍처를 탐색하려면 VMware Workspace ONE 및 VMware Horizon 참조 아키텍처 의 구성 요소 설계 : Horizon 7 아키텍처 섹션 을 참조하십시오.

내부 연결

내부 연결은 Horizon Client가 연결 서버에 직접 연결 한 다음 Horizon Agent에 직접 연결하는 연결입니다. 일반적으로 이것은 회사 네트워크 내부의 연결을위한 것입니다.

초기 인증 단계에서 연결은 Horizon Client에서 연결 서버로 이루어집니다. 그런 다음 보조 프로토콜 세션은 일반적으로 Horizon Client에서 Horizon Agent로 직접 연결됩니다.

보조 프로토콜 연결은 Connection Server 에서 게이트웨이 또는 터널 (Blast 보안 게이트웨이, PCoIP 보안 게이트웨이 또는 HTTPS 보안 터널)이 활성화 된 경우에만 연결 서버를 통해 라우팅됩니다. 이 구성은 프로토콜 세션이 Connection Server를 통해 터널링되어 진행중인 세션의 일부가되므로 덜 일반적입니다.

대부분의 일반적인 배포에서 연결 서버에 사용되는 유일한 게이트웨이 서비스는 VMware HTML Access (웹 기반 클라이언트) 트래픽을 처리하는 데만 사용되는 Blast 보안 게이트웨이입니다. 이 내용은이 가이드 뒷부분의 HTML 클라이언트 액세스 연결 섹션에서 별도의 항목으로 다룹니다 .

커뮤니케이션 흐름

1. Horizon Client가 연결 서버에 로그인
   • 연결 서버는 사용자의 권한을 조회합니다.
   • 사용자가 데스크톱 또는 앱을 선택합니다.
2. Horizon Client는 데스크톱 / RDSH에서 실행중인 Horizon Agent에 연결됩니다.

위의 다이어그램은 세 개의 개별 네트워크 영역을 보여 주지만 구성 요소 사이에 방화벽이없는 동일한 네트워크에 모든 내부 구성 요소를 포함하는 것도 지원됩니다.

Load Balancing

연결 서버의 부하를 분산 할 때 초기 XML-API 연결 (인증, 권한 부여 및 세션 관리) 만 부하 분산하면됩니다. 보조 프로토콜 연결은 Horizon Client에서 Horizon Agent로 직접 이동하기 때문에로드 밸런싱되지 않습니다.

Network Port

구성 요소 간의 성공적인 연결과 올바른 통신을 보장하려면 Horizon 7 배포에서 연결을위한 네트워크 포트 요구 사항을 이해하는 것이 중요합니다.

아래 다이어그램은 가능한 각 디스플레이 프로토콜과 대상 네트워크 포트를 사용하는 내부 연결을 보여줍니다.

참고 :

• 화살표는 트래픽 시작 방향 (소스에서 목적지로)을 나타냅니다.
• Horizon UDP 프로토콜은 양방향이므로 UDP 응답 데이터 그램을 허용하도록 상태 저장 방화벽을 구성해야합니다.

다음 다이어그램은 내부 Blast Extreme 연결을 허용하는 데 필요한 포트를 보여줍니다.

다음 다이어그램은 내부 PCoIP 연결을 허용하는 데 필요한 포트를 보여줍니다.

다음 다이어그램은 내부 RDP를 허용하는 데 필요한 포트를 보여줍니다.

VMware Horizon 7 의 네트워크 포트 가이드 에는 트래픽을 보여주는 다이어그램과 함께 자세한 내용이 있습니다. 내부, 외부 및 터널링 된 연결에 대한 특정 섹션과 다이어그램도 있습니다. 외부 연결에 필요한 네트워크 포트에 대한 자세한 내용 은 VMware Horizon 7 : 내부 연결 및 내부 연결 다이어그램의 네트워크 포트를 참조하십시오 .

외부 연결

외부 연결 인 경우 통신은 일반적으로 VMware Unified Access Gateway 장치를 통해 이루어집니다. 연결의 초기 인증 단계는 Horizon Client에서 Unified Access Gateway 장치로 이동 한 다음 연결 서버로 이동하는 것입니다. 프로토콜 세션 연결은 Horizon Client에서 Unified Access Gateway로 이동 한 다음 Horizon Agent로 이동합니다.

Unified Access Gateway는 Blast 보안 게이트웨이, PCoIP 보안 게이트웨이 및 HTTPS 보안 터널과 같은 게이트웨이 서비스를 실행할 수 있습니다. Blast 보안 게이트웨이 및 PCoIP 보안 게이트웨이도 연결 서버에서 활성화되어 있지 않은지 확인하십시오. 이렇게하면 프로토콜 트래픽의 이중 홉 시도가 발생하여 지원되지 않고 연결이 실패하게됩니다.

Communication Flow

위의 그림은 연결 흐름을 보여줍니다.

1. 사용자는 Horizon Client를 사용하여 Unified Access Gateway를 통해 연결 서버에 로그인합니다.
   • 연결 서버는 사용자의 권한을 조회합니다.
   • 사용자는 연결할 데스크톱 또는 애플리케이션 리소스를 선택합니다.
2. Horizon Client는 데스크톱 또는 RDSH에서 실행중인 Horizon Agent에 연결됩니다.
   • 이는 사용자가 인증 된 장치와 동일한 Unified Access Gateway 장치에서 Blast 보안 게이트웨이를 통해 이루어집니다.

Load Balancing

Horizon 트래픽을 여러 Unified Access Gateway 장치로로드 밸런싱 할 때 초기 XML-API 연결 (인증, 권한 부여 및 세션 관리)을 로드 밸런싱해야합니다. 보조 Horizon 프로토콜은 기본 Horizon XML-API 프로토콜이 라우팅 된 것과 동일한 Unified Access Gateway 장치로 라우팅되어야합니다. 이를 통해 Unified Access Gateway는 인증 된 사용자 세션을 기반으로 보조 프로토콜을 승인 할 수 있습니다.

보조 프로토콜 세션이 기본 프로토콜과 다른 Unified Access Gateway 장치로 잘못 라우팅되면 세션이 승인되지 않습니다. 따라서 연결이 DMZ에서 삭제되고 프로토콜 연결이 실패합니다. 로드 밸런서가 올바르게 구성되지 않은 경우 보조 프로토콜 세션을 잘못 라우팅하는 것은 일반적인 문제입니다.

로드 밸런서 선호도는 세션의 전체 기간 (기본 최대 10 시간) 동안 만들어진 XML-API 연결이 동일한 Unified Access Gateway 장치로 계속 라우팅되도록해야합니다.

보조 프로토콜 세션은 기본 XML-API 연결에 사용 된 것과 동일한 Unified Access Gateway 장치로 라우팅되어야하지만 보조 프로토콜 세션이로드 밸런서를 통해 라우팅되는지 여부를 선택할 수 있습니다. 이는 일반적으로로드 밸런서의 기능에 따라 다릅니다.

예를 들어 F5 BIG-IP LTM (Local Traffic Manager)을 사용하면 기본 및 보조 프로토콜 트래픽이 F5 LTM을 통과하고 소스 IP 선호도를 사용하여 보조 프로토콜 세션의 올바른 라우팅을 보장합니다. 이는 하나의 공용 IP 주소 만 필요하다는 장점이 있습니다. 로드 밸런서에 이 기능이 없거나 소스 IP 선호도를 사용할 수없는 경우 다른 옵션은 보조 프로토콜 세션이로드 밸런서를 우회 할 수 있도록 각 Unified Access Gateway 장치에 대한 추가 IP 주소를 지정하는 것입니다. 이는로드 밸런싱 된 VIP가 기본 프로토콜에 사용되고 보조 프로토콜이 각 Unified Access Gateway 장치 전용 N VIP 중 하나로 직접 라우팅되는 N + 1 VIP 방법이라고도합니다. 보다VMware Unified Access Gateway 장치 간의로드 밸런싱 .

Network Port

성공적인 외부 연결과 구성 요소 간의 올바른 통신을 보장하려면 Horizon 7 배포에서 연결을위한 네트워크 포트 요구 사항을 이해하는 것이 중요합니다. 아래 다이어그램은 가능한 각 디스플레이 프로토콜과 대상 네트워크 포트를 사용하는 외부 연결을 보여줍니다.

참고 :

• 화살표는 트래픽 시작 방향 (소스에서 목적지로)을 나타냅니다.
• Horizon UDP 프로토콜은 양방향이므로 UDP 응답 데이터 그램을 허용하도록 상태 저장 방화벽을 구성해야합니다.

다음 다이어그램은 Unified Access Gateway를 통한 외부 Blast Extreme 연결을 허용하는 데 필요한 포트를 보여줍니다.

다음 다이어그램은 Unified Access Gateway를 통한 외부 PCoIP 연결을 허용하는 데 필요한 포트를 보여줍니다.

다음 다이어그램은 Unified Access Gateway를 통한 외부 RDP 연결을 허용하는 데 필요한 포트를 보여줍니다.

VMware Horizon 7 의 네트워크 포트 가이드 에는 트래픽을 보여주는 다이어그램과 함께 자세한 내용이 있습니다. 내부, 외부 및 터널링 된 연결에 대한 특정 섹션과 다이어그램도 있습니다. 외부 연결에 필요한 네트워크 포트에 대한 자세한 내용 은 VMware Horizon 7 : 외부 연결 및 외부 연결 다이어그램의 네트워크 포트를 참조하십시오 .

아키텍처

Unified Access Gateway를 사용하여 Horizon에 대한 외부 액세스를 제공하는 경우 외부 및 내부 연결 모두에 동일한 연결 서버를 사용할 수 있습니다.

위의 다이어그램은 Unified Access Gateway 장치와 연결 서버 간의로드 밸런서를 보여 주지만 로드 밸런서없이 1 : 1 연결로도 지원됩니다. 인터넷 연결 로드 밸런서가 모든 구성 요소에서 오류를 계속 감지하므로 고 가용성은 계속 유지됩니다.

연결 문제 해결

Horizon 연결 및 세션이 설정되는 방법을 이해 했으므로 이제 작동하지 않는 시점을 살펴볼 수 있습니다. 성공적인 연결 중에 무슨 일이 발생하는지 알면 작동하지 않을 때 이해하고 문제를 해결하는 데 도움이됩니다.

이 가이드는 가능한 모든 구성 요소와 통신 흐름을 보여 주므로 외부 연결 문제 해결에 중점을 둡니다. 문제 해결 단계는 내부 연결에도 적용 할 수 있습니다.

아래 다이어그램은 외부 연결을 나타내며 숫자는 통신 흐름을 나타냅니다.

1. Unified Access Gateway 앞의 로드 밸런서에 대한 Horizon Client 인증
2. 로드 밸런서에서 Unified Access Gateway 중 하나로의 인증 트래픽
3. (선택 사항) Unified Access Gateway에서 타사 인증 소스 (예 : RADIUS, RSA SecurID, SAML 2.0 ID 공급자) 로의 인증 트래픽
4. Unified Access Gateway에서 연결 서버 앞의 로드 밸런서로의 인증 트래픽
5. 로드 밸런서에서 Connection Server 중 하나로의 인증 트래픽
6. Horizon Client에서 인증에 사용 된 동일한 Unified Access Gateway 로의 프로토콜 세션입니다. 로드 밸런싱 구성에 따라 이 트래픽은 로드 밸런서를 통해 이동할 수 있습니다.
7. Unified Access Gateway에서 Windows Server의 가상 데스크톱에서 실행중인 Horizon Agent 로의 프로토콜 세션

참고 : 연결 통신 흐름의 일부는 아니지만 Horizon Agent가 연결 서버와 통신하여 상태를 표시한다는 점에 유의해야합니다.

Horizon 연결 문제를 해결하려면 먼저 실패한 단계 (인증 또는 프로토콜)를 확인하십시오. 사용자가 인증 할 수 있습니까? 로그인하고 Horizon 리소스를 선택하고 실행할 수 있습니까? Horizon 리소스가 사용자의 연결에 실패합니까? 사용자가 인증 할 수없는 경우 초기 조사를 위에 나열된 처음 4 단계로 제한 할 수 있습니다.

대부분의 문제는 Horizon 구성 요소 자체와 관련이 없습니다. 더 일반적으로, 잘못 구성된 방화벽 차단 포트, 잘못 구성된 로드 밸런서 연결 라우팅 또는 트래픽이 대상 (Connection Server, 에이전트 또는 인증 서버)으로 라우팅되는 것을 허용하지 않는 네트워크 라우팅 문제입니다.

초기 문제 해결 단계에는 다음이 포함되어야합니다.

• 방화벽을 통해 필요한 포트가 허용되는지 확인합니다. 이 가이드의 내부 연결 및 외부 연결 섹션에서 네트워크 포트 정보를 검토하십시오. 필요한 포트에 대한 자세한 내용은 VMware Horizon 7의 네트워크 포트를 참조하십시오 .
• 네트워크 라우팅이 위 다이어그램에 표시된 모든 구성 요소간에 트래픽이 흐르도록 구성 되었는지 확인 합니다.
• 로드 밸런서의 잘못된 구성 또는 잘못 정의 된 Blast 외부 URL과 같은 일반적인 문제를 확인합니다.

조사해야 할 Communication Flow 의 주요 영역은 다음과 같습니다.

1. Horizon Client에서 Unified Access Gateway로
2. (선택 사항) 타사 인증 소스에 대한 Unified Access Gateway
3. Connection Server에 대한 Unified Access Gateway
4. Horizon Agent에 대한 Unified Access Gateway
5. Horizon Agent와 Connection Server 간

Horizon Client에서 Unified Access Gateway로

기본 인증 단계에서 Horizon Client는 Unified Access Gateway 중 하나에 연결됩니다. 이를 위해서는 TCP 443이 Horizon Client에서 Unified Access Gateway로 라우팅 될 수 있어야합니다.

보조 프로토콜 단계의 경우 필요한 포트는 사용중인 디스플레이 프로토콜과 Unified Access Gateway에서 사용하도록 구성된 특정 포트 인 Blast에 따라 다릅니다. Horizon Client와 Unified Access Gateway간에 Blast 연결이 실패하면 Unified Access Gateway에 시간 초과 로그 항목이 표시됩니다 bsg.log.

이 문제를 해결하기 위해 조사해야 할 주요 영역은 다음과 같습니다.

외부 방화벽

Horizon Client와 Unified Access Gateway 사이의 방화벽이 Horizon Client의 Blast Extreme 프로토콜 포트에 필요한 포트를 차단하지 않는지 확인합니다.

이는 Unified Access Gateway에서 blastExternalUrl 설정이 구성된 방식에 따라 포트 TCP 8443 또는 TCP 443이됩니다 .

Blast는 선택적으로 Horizon Client에서 Unified Access Gateway로 UDP 8443을 사용할 수도 있지만 먼저 TCP를 통해 초기 연결을 시도해야합니다.

로드 밸런서 선호도

보조 Horizon 프로토콜 (Blast Extreme, PCoIP)은 기본 Horizon 인증이 라우팅 된 것과 동일한 Unified Access Gateway 장치로 라우팅되어야합니다. 이를 통해 Unified Access Gateway는 인증 된 사용자 세션을 기반으로 보조 프로토콜을 승인 할 수 있습니다.

보조 프로토콜 세션이 기본 프로토콜과 다른 Unified Access Gateway 장치로 잘못 라우팅되면 세션이 승인되지 않습니다. 따라서 연결이 DMZ에서 끊어지고 Blast 연결이 실패합니다.

Blast 연결의 경우 이는 Unified Access Gateway 의 bsg.log 에 표시됩니다. 여기서 Blast 세션은 기본값 인 60 초 내에 동일한 Unified Access Gateway에 도착하지 않습니다.

[absg-master] – Removing idle route 44271692-*** to target 192.168.2.151|22443, idled for 60.00 seconds, registered for 60.01 seconds

로드 밸런서가 올바르게 구성되지 않은 경우 보조 프로토콜 세션을 잘못 라우팅하는 것은 일반적인 문제입니다. 로드 밸런서 선호도는 세션의 전체 기간 (기본 최대 10 시간) 동안 이루어진 연결이 인증에 사용 된 동일한 Unified Access Gateway 장치로 계속 라우팅되도록해야합니다.

로드 밸런서에서 선호도 및 제한 시간이 올바르게 구성되었는지 확인하십시오.

VMware Unified Access Gateway 장치 간의로드 밸런싱을 참조하십시오 .

로드 밸런서 WebSocket

Blast Extreme은 WebSocket을 사용합니다 . 일부로드 밸런서는 WebSocket을 차단할 수 있고 일부는 기본적으로 WebSocket을 비활성화 할 수 있습니다. 이는 Citrix NetScaler와 Microsoft TMG 모두에서 나타났습니다.

Unified Access Gateway 앞의로드 밸런서 구성을 확인하여 WebSocket 사용이 활성화되었는지 확인하십시오.

Blast 외부 URL

는 blastExternalUrl통일 액세스 게이트웨이에 돌풍과 연결 호라이즌 클라이언트에 의해 사용되어야하는 URL과 포트를 지정하는 통합 액세스 게이트웨이의 구성입니다.

이 값은 클라이언트가 Unified Access Gateway 장치에 연결하는 데 사용할 수있는 값으로 설정하거나 Unified Access Gateway 앞에 하나가있는 경우로드 밸런서 이름으로 설정해야합니다. 그렇지 않은 경우 Unified Access Gateway는 Blast 연결을 수신하지 않습니다.

구성을 확인하고 blastExternalUrl필요한 경우 URL 및 포트를 변경하십시오. 유효한 포트는 8443 또는 443이어야합니다.

인증서

Unified Access Gateway 및로드 밸런서에서 TLS / SSL 오프로드 또는 재 암호화를 처리하는 경우 사용되는 TLS / SSL 인증서를 확인하십시오. 로드 밸런서 및 Unified Access Gateway 장치에서 동일한 인증서를 사용해야합니다.

Unified Access Gateway에 인증서 불일치 또는 잘못된 SSL 인증서가있는 경우 연결이 실패합니다. Blast 연결이 잘못된 Unified Access Gateway 장치로 잘못 라우팅되고 해당 장치에 올바른 장치에 대한 다른 인증서가있는 경우에도 연결 실패가 발생합니다.

연결 테스트

Windows 클라이언트에서 Unified Access Gateway에 대한 연결을 테스트 할 수 있습니다. 사용중인 게이트웨이 서비스 및 포트에 따라 아래에서 적절한 명령을 사용하십시오.

PowerShell 명령 셸 열기

Test-NetConnection uag-hostname-or-ip-address -port 443

Test-NetConnection uag-hostname-or-ip-address -port 8443

Test-NetConnection uag-hostname-or-ip-address -port 4172

curl 을 동등한 추적으로 사용할 수도 있습니다 .

curl --trace <outputfile> https://hostname.domain.com

이렇게하면 설명 정보를 포함하여 모든 들어오고 나가는 데이터의 전체 추적 덤프가 지정된 출력 파일로 전송됩니다.

파일로 지정하는 대신 표준 출력 (stdout)을 사용하여 출력을 콘솔로 보내려면 파일 이름으로 "-"를 사용하십시오.

curl --trace - https://uag-hostname.domain.com

또는 curl --trace-ascii를 사용하십시오 . 이것은 --trace와 매우 유사하지만 16 진 부분은 제외하고 덤프의 ASCII 부분 만 표시합니다. 최종 사용자가 더 쉽게 읽을 수 있도록 더 작은 출력을 만듭니다.

curl --trace-ascii <outputfile> https://hostname.domain.com

Unified Access Gateway에 tcpdump 설치

tcpdump는 Unified Access Gateway 안팎에서 패킷을 추적하는 데 유용한 도구입니다. 설치하려면 다음을 실행하십시오.

/etc/vmware/gss-support/install.sh

그런 다음 tcpdump 명령을 실행할 수 있습니다. 예 :

tcpdump -i any -n -v port 443

tcpdump -i any -n -v port 8443

tcpdump -i eth0 -n -v udp port 8443

tcpdump -i any -n -v port 4172

타사 ID 공급자에 대한 Unified Access Gateway

RADIUS 또는 RSA SecurID와 같은 타사 ID 공급자를 인증 소스로 사용하도록 Unified Access Gateway를 구성한 경우 인증 소스의 호스트 이름을 확인할 수 있고 트래픽을 올바르게 라우팅 할 수 있는지 확인합니다.

반지름

Unified Access Gateway에서 다음 명령을 실행하여 이름 확인 및 연결을 확인합니다. ICMP는 방화벽에 의해 차단 될 수 있으므로 ping이 항상 작동하는 것은 아니지만 이름 확인은 작동해야합니다.

nslookup radius-server-hostname

tracepath radius-server-hostname

tcpdump로 패킷 추적

tcpdump는 Unified Access Gateway 안팎에서 패킷을 추적하는 데 유용한 도구입니다. 설치하려면 다음을 실행하십시오.

/etc/vmware/gss-support/install.sh

그런 다음 다음 tcpdump 명령을 실행할 수 있습니다.

tcpdump -i any -n -v port 1812

RDS SecurID

일반적인 문제에는 필요한 포트를 차단하는 방화벽, 제자리에 있지 않은 올바른 네트워크 라우팅, 작동하지 않는 이름 확인 또는 재협상해야하는 노드 암호가 포함됩니다.

방화벽

Unified Access Gateway는 일반적으로 UDP 포트 5500을 사용하여 RSA 인증 관리자 서버와 통신하는 RSA SecurID 클라이언트를 사용합니다 (UDP가 반대 방향으로 응답 함). 이 UDP 및 / 또는 응답 포트를 차단하는 방화벽이있는 경우 SecurID 인증이 실패합니다.

RSA Authentication Manager 서버에 대한 로그에 Unified Access Gateway의 연결이 없음이 표시됩니다.

RSA 인증 관리자 호스트 이름 확인

내부 sdconf.recRSA 인증 관리자에서 추출한 파일, 하나 이상의 호스트 이름이있다. 이러한 호스트 이름은 Unified Access Gateway에서 확인할 수 있어야합니다.

sdconf.rec파일에 있는 호스트 이름을 사용하여 Unified Access Gateway에서 다음 명령을 실행하여 이름 확인 및 연결을 확인합니다. ICMP는 방화벽에 의해 차단 될 수 있으므로 ping이 항상 작동하지는 않지만 이름 확인은 작동해야합니다.

nslookup rsa-auth-manager-hostname

tracepath rsa-auth-manager-hostname

Unified Access Gateway에서 사용하는 DNS에 해당 호스트 이름이없는 경우 실패 할 수 있습니다.

호스트 이름이 확인되지 않은 경우 해결 방법은 Unified Access Gateway에서 사용하는 DNS에 호스트 이름을 추가하거나 호스트에 대한 호스트 파일 항목을 추가하는 것입니다 (PowerShell 방법을 사용하여 배포 중에 자동으로 수행 될 수 있음).

RSA Authentication Manager 서버에 대한 로그에 Unified Access Gateway의 연결이 없음이 표시됩니다.

노드 비밀 지우기

처음 배포 할 때 노드 비밀은 Unified Access Gateway와 RSA 인증 관리자 서버간에 협상 / 교환됩니다. RSA Authentication Manager 서버가 재배포되거나 Unified Access Gateway가 재배포 된 경우 재협상이 발생하도록 다른 쪽의 노드 암호를 지워야합니다. 이 문제를 보여주는 RSA 인증 관리자 서버에 좋은 로그가 있습니다.

tcpdump로 패킷 추적

tcpdump는 Unified Access Gateway 안팎에서 패킷을 추적하는 데 유용한 도구입니다. 설치하려면 다음을 실행하십시오.

/etc/vmware/gss-support/install.sh

그런 다음 tcpdump 명령을 실행할 수 있습니다.

tcpdump -i any -n -v port 5500

위에 설명 된 호스트 이름 확인의 IP 주소를 사용하는 RSA Authentication Manager 서버와의 통신 시도가 표시됩니다. 올바르게 구성되면 UDP 데이터 그램이 대상 포트 5500에서 전송되는 것으로 표시되고 해당 포트의 응답 데이터 그램도 표시됩니다.

아웃 바운드 UDP 데이터 그램이 표시되지만 응답 데이터 그램이없는 경우 포트를 차단하는 방화벽 일 수 있으며 데이터 그램이 RSA 인증 관리자에 도달하지 않거나 응답 데이터 그램이 Unified Access Gateway로 다시 라우팅되지 않을 수 있습니다. RSA Auth Manager 로그를 확인하십시오.

연결 서버에 대한 Unified Access Gateway

기본 인증 단계의 일부로 Unified Access Gateway는 포트 TCP 443을 사용하여 연결 서버 중 하나에 연결합니다.

• 네트워킹 -TCP 443이 Unified Access Gateway에서 연결 서버로 열려 있고 존재하는 모든 방화벽을 통해 허용되며 두 구성 요소 사이에 네트워크 라우팅이 있는지 확인합니다.
• 연결 서버 URL- Unified Access Gateway에 정의 된 연결 서버 URL이 올바른지, Unified Access Gateway가 DNS를 사용하여이 URL을 확인할 수 있는지 확인합니다.
• 인증서 – 연결 서버에 Unified Access Gateway에서 신뢰하는 TLS / SSL 인증서가 있는지 확인합니다. 또는 Unified Access Gateway가 연결 서버 URL 지문으로 구성되어 있는지 확인하십시오.

연결 테스트

Unified Access Gateway 장치 명령 줄에서 원격 콘솔 또는 SSH를 엽니 다. 루트로 로그온하고 다음 명령을 실행하십시오.

curl -v -k https://hostname-or-ip-address:443/

Unified Access Gateway가 연결 서버에 성공적으로 연결할 수있는 경우 다음 스크린 샷과 유사한 출력이 표시됩니다.

그림 15 : 연결 서버에 대한 Unified Access Gateway의 성공적인 컬 테스트

Unified Access Gateway 명령 줄에서 다음 명령을 실행하여 Unified Access Gateway가 연결 서버의 이름을 확인할 수 있는지 확인합니다.

nslookup hostname

그림 16 : Unified Access Gateway의 nslookup

Unified Access Gateway에서 연결 서버에 연결하는 데 문제가있는 경우 다음과 유사하게 Unified Access Gateway의 esmanager.log 에 기록됩니다 .

[nioEventLoopGroup-7-1]ERROR view.ViewEdgeService[onFailure: 165][]: Failed to resolve hostname address in proxyDestinationUrl: s1-cs3.eucmobility.com

[nioEventLoopGroup-4-1]WARN  client.HttpClient[operationComplete: 359][]: unable to connect to s1-cs3.eucmobility.com:443, reason=io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection timed out: s1-cs3.eucmobility.com/192.168.2.33:443 retryCount:3

nioEventLoopGroup-4-1]ERROR client.HttpClient[lambda$send$1: 246][]: unable to connect to s1-cs3.eucmobility.com:443, reason=io.netty.channel.ConnectTimeoutException: connection timed out: s1-cs3.eucmobility.com/192.168.2.33:443

[Monitoring]ERROR view.ViewEdgeService[healthCheckBroker: 407][]: Exception message: io.netty.channel.ConnectTimeoutException: connection timed out: s1-cs3.eucmobility.com/192.168.2.33:443

[nioEventLoopGroup-4-1]WARN  client.HttpClient[operationComplete: 359][]: unable to connect to s1-cs3.eucmobility.com:443, reason=io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection timed out: s1-cs3.eucmobility.com/192.168.2.33:443 retryCount:2

DNS 문제

Photon 3에서 실행되는 Unified Access Gateway 3.7 이상에서는 /etc/resolv.conf 파일에 DNS 서버 IP 주소가 포함되지 않습니다. 이것은 의도적으로 설계된 것입니다. /etc/resolv.conf 파일을 수동으로 편집하지 마십시오. DNS IP 주소는 배포시 PowerShell .ini 설정 파일을 통해 또는 Unified Access Gateway 관리 콘솔을 사용하여 추가해야합니다.

호스트 이름에 .local 을 사용하지 마십시오. 멀티 캐스트 DNS (mDNS) 용으로 예약되어 있으며 .local로 끝나는 이름에 대한 확인 요청은 일반 (유니 캐스트) DNS로 전송되지 않습니다. Photon 2를 기반으로하는 이전 버전의 Unified Access Gateway에서는 .local 이름을 확인할 수 있었지만이 문제는 Unified Access Gateway 3.7 이상에서 수정되었습니다.

환경의 호스트 이름이 .local 접미사 로 지정된 경우 예약 된 접미사 .local에서 벗어날 수있을 때까지 세 가지 해결 방법이 있습니다.

1. ntpServers, proxydestinationUrl 등과 같은 설정에서 호스트 이름 참조 대신 IP 주소를 사용하십시오.
2. Unified Access Gateway 호스트 파일 (PowerShell 또는 관리 UI를 통해)에 .local 호스트에 대한 호스트 항목을 추가합니다 . / etc / hosts 파일을 직접 편집하지 마십시오.
3. DNS에 별칭 CNAME 레코드를 추가하여 모든 .local 호스트에 대한 대체 이름을 제공합니다 .
   1. 예를 들어 myinternalserver.local DNS 항목의 경우 myinternalserver.int를 CNAME으로 사용한 다음 Unified Access Gateway의 호스트 이름 참조에 .int 이름을 사용합니다.

다음 명령을 사용하여 Unified Access Gateway에 구성된 DNS 서버 IP 주소를 확인하십시오.

systemd-resolve --status

Unified Access Gateway가 각 DNS 서버 IP 주소를 ping 할 수 있는지 확인합니다.

ping <DNS Server IP Address>

DNS를 사용하여 호스트 이름을 확인합니다.

nslookup <hostname>

Unified Access Gateway에서 tcpdump를 사용하여 DNS 프로토콜 활동 (요청 및 응답)을 볼 수도 있습니다.

/etc/vmware/gss-support/install.sh

tcpdump -i any -n -v udp port 53

백그라운드에서 실행하려면 끝에 "&"를 입력하십시오.

tcpdump -i any -n -v udp port 53&

Unified Access Gateway 3.7 이상에서 nslookup을 사용하는 tcpdump 출력을 사용하면 127.0.0.53 UDP 포트 53으로가는 DNS 쿼리가 표시됩니다. 이것은 로컬 DNS 리스너 systemd-resolv이며 DNS 쿼리를 다음과 같이 구성된 DNS 서버로 전달합니다. 와 함께 표시 systemd-resolve --status

Horizon Agent에 대한 Unified Access Gateway

프로토콜 세션이 보조 세션의 일부로 연결되면 Unified Access Gateway는 가상 데스크톱 또는 Windows Server에서 실행중인 Horizon Agent에 연결됩니다 (게시 된 애플리케이션에 대해 RDSH를 실행하는 경우).

Blast 연결의 경우 TCP 22443 (및 선택적으로 UDP 22443)을 사용합니다. 방화벽이있는 경우 Unified Access Gateway에서 에이전트로의이 트래픽을 허용하고 트래픽을 허용하고 전달하는 네트워크 라우팅이 있는지 확인합니다.

연결 서버 구성 오류

연결 서버가 BSG (Blast 보안 게이트웨이)에 대해 구성된 경우 Unified Access Gateway를 통한 Blast 연결이 실패합니다.

• Blast Extreme은 다중 홉 Blast 보안 게이트웨이를 지원하지 않습니다. 예를 들어, Unified Access Gateway와 연결 서버 모두에서 BSG를 실행합니다.
• 오류는 Unified Access Gateway 의 에 표시됩니다 bsg.log.

그림 17 : 연결 서버에 터널 및 프로토콜 게이트웨이가 비활성화되어 있는지 확인

마찬가지로 PCoIP가 Unified Access Gateway를 통해 사용되는 경우 PCoIP 보안 게이트웨이 서비스를 연결 서버에 구성하면 안됩니다. 이로 인해 프로토콜의 이중 홉이 발생하고 연결이 실패 할 수 있습니다.

연결 테스트

Blast over 22443 또는 PCoIP over 4172를 사용하여 Horizon Agent에 대한 연결을 테스트 할 수 없습니다. 데스크톱은 세션이 준비 될 때까지 이러한 포트 번호를 수신하지 않기 때문입니다. 로그에서 이러한 포트의 연결 실패를 볼 수 있습니다.

Horizon Framework 채널 TCP 연결을 사용하여 테스트

curl -v telnet://virtualdesktop-ip-address:32111

Horizon MMR / CDR TCP 연결을 사용하여 테스트

curl -v telnet://virtualdesktop-ip-address:9427

HTML 클라이언트 액세스 연결

HTML Access를 사용하면 설치된 기본 Horizon Client 대신 웹 브라우저가 Horizon 리소스에 액세스하기위한 클라이언트로 사용됩니다. 한 가지 고려 사항은 브라우저가 제공된 SSL 인증서를 신뢰해야한다는 것입니다.

외부 연결에서 Unified Access Gateway는 Blast 보안 게이트웨이를 실행하고 ID를 확인하기 위해 브라우저에 Unified Access Gateway 인증서를 제공합니다.

프로토콜 세션이 일반적으로 클라이언트에서 Horizon Agent로 직접 연결되는 내부 연결을 사용하는 경우 에이전트 측은 신뢰할 수있는 인증서를 브라우저에 제공해야합니다. 이것은 몇 가지 도전을 제시합니다.

1. 기본적으로 연결 서버는 데스크톱 컴퓨터 및 RDSH 서버의 호스트 이름이 아닌 IP 주소를 클라이언트에 전송하는 것을 우선적으로 제공하므로 인증서가 일치하지 않고 신뢰할 수 없게됩니다. (이 동작은 DNS 이름을 선호하도록 변경할 수 있습니다.)
2. 데스크톱 컴퓨터와 RDSH 서버에는 클라이언트 장치의 브라우저에서 신뢰할 수있는 인증서가 설치되어 있어야합니다. 이 동작으로 인해 전통적으로 와일드 카드 인증서가 사용되었습니다.

구성

Horizon 연결 서버의 기능은 이러한 제약을 극복하는 데 도움이됩니다. Horizon Administrator에서는 HTML Access가 로컬로 사용되는 경우에만 원격 데스크톱 및 애플리케이션에 대한 보안 액세스를 제공하도록 Blast 보안 게이트웨이 사용을 구성 할 수 있습니다.

Blast Extreme 프로토콜 트래픽 세션은 연결 서버를 통해 라우팅되며 SSL 인증서와 함께 제공됩니다. 이렇게하면 연결 서버가 시스템 또는 RDSH 서버 정보를 호스트로 보내는 기본 방식을 변경할 필요가 없습니다. 또한 데스크톱 컴퓨터 및 RDSH 서버에서 인증서를 관리 할 필요가 없음을 의미합니다.

그림 18 : 연결 서버 게이트웨이 설정

연결 서버에 구성된 HTML Access 용 Blast 보안 게이트웨이 사용 설정 만 사용 하면 다음과 같은 동작이 발생합니다.

1. 연결 서버에 직접 연결하는 내부 HTML Access 사용자는 Blast 연결이 연결 서버의 Blast 보안 게이트웨이를 통해 이동합니다.
2. 내부 기본 Horizon Client에는 Blast 연결이 데스크톱으로 직접 연결됩니다.
3. Unified Access Gateway를 통해 연결하는 외부 사용자 (HTML Access 또는 기본 클라이언트)는 Blast 연결이 Unified Access Gateway의 Blast 보안 게이트웨이를 통해 이동합니다. 그런 다음 연결은 Unified Access Gateway 장치에서 Horizon Agent로 이동하고 연결 서버의 Blast 보안 게이트웨이를 건드리지 않으며 프로토콜의 이중 홉이 발생하지 않습니다.

그림 19 : HTML Access를 사용한 내부 연결

또한 연결 서버는 대부분의 사용 사례에서 Unified Access Gateway에서 실행되는 게이트웨이 서비스 (Blast 보안 게이트웨이, PCoIP 보안 게이트웨이 및 HTTPS 보안 터널)와 함께 내부 및 외부 연결 모두에 대해 공유 될 수 있음을 의미합니다. 내부 HTML Access 연결 만 연결 서버의 Blast 보안 게이트웨이를 통과합니다.

HTML 액세스 실패

경우에 따라 기본 Horizon Client가 Blast Extreme에서 작동하지만 HTML Access Client 사용이 실패 할 수 있습니다 (일부 브라우저에서는 실패하고 다른 브라우저에서는 작동하지 않음). HTML Access 및 Horizon 7을 사용하는 경우로드 밸런서 또는 Unified Access Gateway와 같은 게이트웨이를 통해 연결 서버에 연결하는 경우 먼저 Horizon 7에서 보안 설정을 구성해야합니다.

이러한 실패의 일반적인 이유는 연결 서버의 원본 확인 실패입니다. 연결 서버에서 디버그 로그 파일을보고 "Origin"을 검색하여 원본 확인 실패를 찾습니다. 자세한 내용은 Horizon 7 보안 문서에서 "원본 확인"을 참조하십시오.

이를 해결하려면 로드 밸런서를 통한 HTML 액세스 허용을 참조하십시오 .

출처 : techzone.vmware.com/resource/understand-and-troubleshoot-horizon-connections#troubleshooting

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

Horizon 연결 서버를 포함하여 VMware Horizon 7을 사용하지만 여기에 설명 된 대부분의 내용은 VMware Horizon Cloud에도 적용됩니다.

참고 :이 블로그는 얼마 전에 게시되었지만 여전히 Horizon 연결의 요지를 알 수있는 관련성이 높고 쉬운 방법입니다. 더 자세히 알아 보려면 이제 상세하고 포괄적 인 Horizon 연결 이해 및 문제 해결 가이드를 제공합니다.

1 차 및 2 차 프로토콜

먼저 Horizon Client가 Horizon 환경에 연결될 때 여러 다른 프로토콜이 사용되며 성공적인 연결은 두 단계로 구성된다는 점을 이해하는 것이 중요합니다.

연결의 첫 번째 단계는 항상 인증, 권한 부여 및 세션 관리를 제공하는 HTTPS를 통한 기본 XML-API 프로토콜입니다. 인증에 성공하면 하나 이상의 보조 프로토콜을 사용하여 리소스에 연결됩니다.

Horizon 7의 구성 요소 및 아키텍처를 탐색 하려면 VMware Workspace ONE 및 VMware Horizon 참조 아키텍처 에서 구성 요소 설계 : Horizon 7 아키텍처 섹션 을 참조하십시오.

내부 연결

내부 연결을 사용하면 초기 인증 단계에서 Horizon Client에서 연결 서버로 연결됩니다. 그런 다음 보조 프로토콜 세션은 일반적으로 Horizon Client에서 Horizon Agent로 직접 연결됩니다.

보조 프로토콜 연결은 연결 서버에서 게이트웨이 또는 터널 (Blast 보안 게이트웨이, PCoIP 보안 게이트웨이 또는 HTTPS 보안 터널)이 활성화 된 경우에만 연결 서버를 통해 라우팅됩니다. 이 구성은 프로토콜 세션이 연결 서버를 통해 터널링되어 진행중인 세션의 일부가되므로 덜 일반적입니다.

대부분의 일반적인 배포에서 연결 서버에서 사용되는 유일한 게이트웨이 서비스는 VMware HTML Access (웹 기반 클라이언트) 트래픽을 처리하는 Blast 보안 게이트웨이입니다. 이는이 게시물 뒷부분의 내부 HTML 클라이언트 액세스 연결 섹션에서 별도의 주제로 다룹니다 .

연결 서버의 부하를 분산 할 때 일반적으로 초기 XML-API 연결 (인증, 권한 부여 및 세션 관리) 만 부하 분산하면됩니다.

보조 프로토콜 연결은 Horizon Client에서 Horizon Agent로 직접 이동하기 때문에로드 밸런싱되지 않습니다.

외부 연결

연결이 외부인 경우 통신은 일반적으로 VMware UAG (Unified Access Gateway) 어플라이언스를 통해 이루어집니다. 연결의 초기 인증 단계는 Horizon Client에서 Unified Access Gateway 장치로 이동 한 다음 연결 서버로 이동하는 것입니다. 프로토콜 세션 연결은 Horizon Client에서 Unified Access Gateway로 이동 한 다음 Horizon Agent로 이동합니다.

Unified Access Gateway는 Blast 보안 게이트웨이, PCoIP 보안 게이트웨이 및 HTTPS 보안 터널과 같은 게이트웨이 서비스를 실행합니다. 이러한 게이트웨이 서비스가 연결 서버에서도 활성화되어 있지 않은지 확인하십시오.이 경우 지원되지 않는 프로토콜 트래픽의 이중 홉 시도가 발생하여 연결이 실패하게됩니다.

또한이 아키텍처에서는 외부 및 내부 연결 모두에 동일한 연결 서버를 사용할 수 있습니다.

Horizon 트래픽을 여러 UAG 장치로로드 밸런싱 할 때 초기 XML-API 연결 (인증, 권한 부여 및 세션 관리)을로드 밸런싱해야합니다. 보조 Horizon 프로토콜은 기본 Horizon XML-API 프로토콜이 라우팅 된 동일한 UAG 어플라이언스로 라우팅되어야합니다. 이를 통해 UAG는 인증 된 사용자 세션을 기반으로 보조 프로토콜을 승인 할 수 있습니다.

보조 프로토콜 세션이 기본 프로토콜과 다른 Unified Access Gateway 장치로 잘못 라우팅되면 세션이 승인되지 않습니다. 따라서 연결이 DMZ에서 삭제되고 프로토콜 연결이 실패합니다. 로드 밸런서가 올바르게 구성되지 않은 경우 보조 프로토콜 세션을 잘못 라우팅하는 것은 일반적인 문제입니다.

로드 밸런서 선호도는 세션의 전체 기간 (기본 최대 10 시간) 동안 만들어진 XML-API 연결이 동일한 UAG 어플라이언스로 계속 라우팅되도록해야합니다.

보조 프로토콜 세션은 기본 XML-API 연결에 사용 된 것과 동일한 UAG 어플라이언스로 라우팅되어야하지만 보조 프로토콜 세션이로드 밸런서를 통해 라우팅되는지 여부를 선택할 수 있습니다. 이는 일반적으로로드 밸런서의 기능에 따라 다릅니다.

예를 들어 F5 BIG-IP LTM (Local Traffic Manager)을 사용하면 기본 및 보조 프로토콜 트래픽이 F5 LTM으로 이동하며 소스 IP 선호도를 사용하여 보조 프로토콜 세션의 올바른 라우팅을 보장합니다. 이는 하나의 공용 IP 주소 만 있으면된다는 장점이 있습니다. 로드 밸런서에이 기능이없는 경우 다른 옵션은 보조 프로토콜 세션이로드 밸런서를 우회 할 수 있도록 각 UAG 어플라이언스에 대한 추가 IP 주소를 지정하는 것입니다. VMware Unified Access Gateway 장치 간의로드 밸런싱을 참조하십시오 .

내부 HTML 클라이언트 액세스 연결

HTML Access를 사용하면 설치된 기본 Horizon Client 대신 웹 브라우저가 Horizon 리소스에 액세스하기위한 클라이언트로 사용됩니다. 한 가지 고려 사항은 브라우저가 제공된 SSL 인증서를 신뢰해야한다는 것입니다. 외부 연결에서 Unified Access Gateway는 Blast 보안 게이트웨이를 실행하고 ID를 확인하기 위해 브라우저에 UAG 인증서를 제공합니다.

프로토콜 세션이 일반적으로 클라이언트에서 Horizon Agent로 직접 연결되는 내부 연결을 사용하는 경우 에이전트 측은 신뢰할 수있는 인증서를 브라우저에 제공해야합니다. 이것은 몇 가지 도전을 제시합니다.

1. 기본적으로 연결 서버는 데스크톱 컴퓨터 및 RDSH 서버의 호스트 이름이 아닌 IP 주소를 클라이언트에 전송하는 것을 우선적으로 제공하므로 인증서가 일치하지 않고 신뢰할 수 없게됩니다. (이 동작은 DNS 이름을 선호하도록 변경할 수 있습니다.)
2. 데스크톱 컴퓨터와 RDSH 서버에는 클라이언트 장치의 브라우저에서 신뢰할 수있는 인증서가 설치되어 있어야합니다. 이 동작으로 인해 전통적으로 와일드 카드 인증서가 사용되었습니다.

연결 서버의 비교적 새로운 기능은 이러한 제약을 극복하고보다 우아한 솔루션을 제공합니다. Horizon Administrator에서는 HTML Access가 로컬로 사용되는 경우에만 원격 데스크톱 및 애플리케이션에 대한 보안 액세스를 제공하도록 Blast 보안 게이트웨이 사용을 구성 할 수 있습니다.

Blast Extreme 프로토콜 트래픽 세션은 연결 서버를 통해 라우팅되며 SSL 인증서와 함께 제공됩니다. 이렇게하면 연결 서버가 시스템 또는 RDSH 서버 정보를 호스트로 보내는 기본 방식을 변경할 필요가 없습니다. 또한 데스크톱 컴퓨터 및 RDSH 서버에서 인증서를 관리 할 필요가 없음을 의미합니다.

연결 서버에 구성된 HTML Access 용 Blast 보안 게이트웨이 사용 설정 만 사용 하면 다음과 같은 동작이 발생합니다.

1. 연결 서버에 직접 연결하는 내부 HTML Access 사용자는 Blast 연결이 연결 서버의 Blast 보안 게이트웨이를 통과합니다.
2. 내부 기본 Horizon Client에는 Blast 연결이 데스크톱으로 직접 연결됩니다.
3. UAG를 통해 연결하는 외부 사용자 (HTML Access 또는 기본 클라이언트)는 Blast 연결이 UAG의 Blast 보안 게이트웨이를 통과하도록합니다. 그러면 연결이 UAG 어플라이언스에서 데스크톱으로 이동하고 연결 서버의 Blast 보안 게이트웨이를 건드리지 않습니다.

또한 연결 서버는 대부분의 사용 사례에서 UAG에서 실행되는 게이트웨이 서비스 (Blast 보안 게이트웨이, PCoIP 보안 게이트웨이 및 HTTPS 보안 터널)와 함께 내부 및 외부 연결 모두에 대해 공유 될 수 있음을 의미합니다. 내부 HTML Access 연결 만 연결 서버의 Blast 보안 게이트웨이를 통과합니다.

결론

이제 연결 방법과 트래픽 흐름을 이해 했으므로 사용되는 네트워크 포트를 살펴볼 수 있습니다. VMware Horizon 7 의 네트워크 포트 문서 에는 트래픽을 보여주는 다이어그램과 함께이 세부 정보가 있습니다. 내부, 외부 및 터널링 된 연결에 대한 특정 섹션과 다이어그램도 있습니다.

자세한 내용은 Horizon 연결 이해 및 문제 해결 가이드를 참조하십시오 .

출처:techzone.vmware.com/blog/understanding-horizon-connections