[번역] Getting started with VMware Cloud Foundation(VCF)

출처 : https://cormachogan.com/2020/01/10/getting-started-with-vmware-cloud-foundation-vcf/

휴가에서 돌아온 후, 저의 최우선 과제 중 하나는 VMware 클라우드 재단(VCF)에 대해 좀 더 친숙해지는 것이었습니다. VCF에 익숙하지 않은 분들에게는 기본적으로 vRealize Operation, vRealize Log Insight 등의 제품을 모니터링 및 로깅하는 것뿐만 아니라 가상 스토리지(vSAN), 가상 네트워킹(NSX) 등 전체 vSphere 스택의 배포를 위한 '쉬운 버튼'이 된다. 그러나 VCF가 일단 자리를 잡으면 Horizon View 및 PKS와 같은 VMware의 애플리케이션 제품군이라고 할 수 있는 애플리케이션 및 조직의 서로 다른 테넌트가 사용할 수 있는 추가 가상 인프라 환경을 구축하는 데 필요한 구성 요소가 되기 때문에 훨씬 더 큰 문제가 될 수 있다.

내가 VCF 버전 3.9의 다수의 게시물 중 첫 번째가 될 예정인 이 게시물에서는 관리 도메인의 초기 배포를 거치게 될 것이다. 하지만 우리가 그것에 들어가기 전에, 우리는 VCF의 기본적인 건축 요소들을 이해하는 데 약간의 시간을 할애할 필요가 있다.

Cloud Builder

Cloud Builder는 VMware에서 제공하는 가상 어플라이언스로, VCF 관리 도메인을 배포 및 구성하는 데 사용되며, 이 작업이 완료되면 SDDC Manager로 제어 권한을 전송한다.

SDDC Manager

Cloud Builder가 관리 도메인을 구성한 후에는 제어 및 관리가 SDDC Manager에게 전달된다. 여기서부터 VCF 3.9 버전에서 Virtual infrastructure WLD, Horizon WLD, PKS WLD와 같은 워크로드 도메인의 생성과 같은 다양한 작업을 수행할 수 있다. 또한 새로운 ESXi 호스트를 WLD에서 사용하도록 커미셔닝하고, DELL(MX 시리즈)과 HPE(Syenergy 시리즈)에서 새로운 Composable Infrastructure를 관리하고, vRealize Suite(예: vRealize Operations 및 vRealize Automation)를 배포할 수 있다.

Management Domain

관리 도메인은 Cloud Foundation 인프라를 인스턴스화, 관리 및 모니터링하는 데 필요한 인프라 구성요소를 호스팅하는 데 사용된다. 관리 도메인은 처음에 구성될 때 Cloud Builder 어플라이언스를 사용하여 자동으로 생성된다.

관리 도메인에는 4개의 ESXi 노드가 필요하다. 또한 스토리지로 vSAN만 활용한다. 따라서 vSAN은 모든 VCF 관리 도메인에 필요한 기본 스토리지다.

Workload Domains

Workload Domain은 비즈니스 워크로드가 실행될 수 있도록 컴퓨팅, 스토리지 및 네트워크 리소스를 선택을 통합해서 제공한다. 이는 리소스의 논리적 추상화로서 SDDC(소프트웨어 정의 데이터 센터) 관리자에 의해 자동으로 프로비저닝되고 독립적으로 관리 및 패치된다. VCF는 SDDC 관리자를 사용하여 워크로드 도메인을 생성, 확장 및 삭제하기 위한 완전 자동화된 프로세스를 제공한다. 호스트와 클러스터도 워크로드 도메인에서 제거하여 크기를 줄일 수 있다.

워크로드 도메인은 최소 3개의 ESXi 호스트가 필요하며 vSAN 스토리지(기본값과 기본 설정)를 활용할 수 있지만 NFS 3.x 데이터스토어(VCF 3.5 이후)와 파이버 채널 스토리지(VCF 3.9 이후)의 형태로 보조 스토리지를 사용할 수도 있다.

사용자는 기본/주요 스토리지가 하나 더 있지만 보조 스토리지가 추가될 수 있다. 이것은 다음에 다루도록 하겠다.

Cloud Builder의 활동

나는 이 예에서 VCF 3.9를 배치할 것이다. 우리는 Cloud Builder부터 시작한다. Cloud Builder는 VMware에서 제공하는 단일 사용 어플라이언스 입니다. 배포는 다른 많은 vSphere 어플라이언스와 크게 다르지 않다. OVA를 배포하고 적절한 필드를 채운 후 배포가 완료되면 사용자가 Cloud Builder URL에 연결하여 배포를 계속한다. 기기 롤아웃 시 제공된 자격 증명을 사용하여 로그인하면 관리자가 Pre-bring-up 점검표를 제시한다. 이러한 모든 작업은 계속하기 전에 검증되어야 한다. VCF 구축을 고려하는 사용자는 이 체크리스트를 검증하는 데 많은 시간을 할애해야 한다. 롤아웃이 시작된 후 구성을 수정하는 것이 쉽지 않기 때문에 나중에 배치 프로세스에서 많은 시간과 노력을 절약할 수 있을 것이다. 경우에 따라서는 이미 배치된 부품을 정리하고 다시 시작해야 할 수도 있다. 따라서 이 체크리스트가 환경에 유효하다는 것을 확인하는 몇 가지 사이클을 사용하는 것이 장기적으로 유익할 것이다.

cb1.png

다음은 EULA다. 당신은 단지 배치를 계속하기 위해서 이것에 동의할 필요가 있다.

cb2-.png

그리고 이제 우리는 Cloud Builder의 내면에 도달한다. 관리자는 배포하고자 하는 소프트웨어 정의 데이터 센터(SDDC)와 관련된 정보를 입력해야 하는 샘플 구성 파일/매개 변수 시트를 제공한다.

cb3.png

구성에 정보를 입력해야 하는 SDDC의 구성 요소:

  • ESXi 호스트
  • vCenter Server
  • vSAN
  • NSX
  • SDDC 관리자
  • vRealize Log Insight

채워야 할 정보에는 라이센스 정보, 호스트 및 어플라이언스 암호, 네트워킹 정보(VLAN, IP 주소, 게이트웨이, MTU), ESXi 호스트에 대한 SSH RSA 키 지문 및 SSL 지문(SHA1)이 포함된다.

NSX에는 배포된 NSX Manager 및 3개의 NSX 컨트롤러에 대한 추가 정보가 필요하다. vRealize Log Insight는 3개의 노드 클러스터로 배포되므로 IP 주소와 호스트 이름은 물론 추가 로드 밸런서 IP 주소 및 호스트 이름이 필요하다. 여기에 채워야 하는 구성 매개 변수의 몇 가지 샘플 페이지가 있다. 호스트 이름의 DNS 확인도 관건이다. 아래는 다양한 구성 요소에 대한 라이센스가 채워지는 관리 워크로드 페이지 입니다.

VCF-Management-Workloads.png

구성의 다른 페이지는 관리 도메인을 구성하는 ESXi 호스트와 관련된다. 아래에서 볼 수 있듯이 vMotion 네트워크 및 vSAN 네트워크의 VLAN 정보와 IP 주소도 포함해야 한다.

VCF-Hosts-and-Networks.png

각 ESXi 호스트의 fingerprint 및 thumbprint도 필요하다. 이것들을 어떻게 캡처하는지 몇 가지 팁을 보여주겠다. 이것은 많은 정보처럼 보일 수 있지만, 스프레드시트는 실제로 채우기 위해 상당히 직진하고 있다. 매개 변수 시트가 채워지면 클라우드 빌더에 업로드한다.

cb4.png매개 변수 파일이 업로드되면 Cloud Builder에 의해 검증된다. 내 연구실에 이걸 배포하고 있었으므로, 검증 결과에서 여러 가지 경고가 보고되었다. 프러덕션 배포의 경우, 이 모든 사항을 검토하여 상태 보고가 성공 사례로 나타나도록 해야 한다.

cb7.png

매개 변수 파일 유효성 검사가 완료되면 SDDC를 불러올 준비가 된다. 소프트웨어 정의 데이터 센터 전체 스택을 자동으로 구축하는 실제 활동이 시작되는 시점이다.

cb6.png

아주 깔끔한 것은 모든 단계가 정확히 어떤 활동이 일어나고 있는지 보여준다는 것이다. 여기 내 실험실 환경으로부터의 바로 시작이다.

cb7.png

보다 자세한 정보를 위해 사용자는 다음과 같이 Cloud Builder 가상 어플라이언스에 SSH를 연결하고 가져오기 로그를 추적할 수 있다.

chogan@chogan-a01 ~ % ssh admin@cloud-builder-01
admin@10.27.51.134's password:*****
Last login: Thu Jan 9 11:44:01 2020 from 10.30.1.189
admin@vcf-cb-01 [ ~ ]$

admin@vcf-cb-01 [ ~ ]$ ls -lt /var/log/vmware/vcf/bringup
total 11772
-rw-r--r-- 1 vcf_bringup vcf 6426077 Jan 9 15:17 vcf-bringup-debug.log
-rw-r--r-- 1 vcf_bringup vcf 1731087 Jan 9 15:17 vcf-bringup.log
.
.
admin@vcf-cb-01 [ ~ ]$ tail -f /var/log/vmware/vcf/bringup/vcf-bringup.2020-01-08.0.log

보다 자세한 정보를 위해, bring-up의 debug 로그를 참조할 수 있다.

이제, 여러분이 잘 상상할 수 있듯이, SDDC를 세우려면 많은 단계를 거쳐야 한다. 위의 스크린샷은 전개되고 구성된 모든 것의 작은 조각에 불과하다. 하지만 요점은 이것이 이제 완전히 자동화되어 많은 시간과 노력을 절약하고 많은 경우에 고통을 덜어준다는 겁니다. 클라우드 빌더에 대해 어느 정도 숙지하고 매개 변수 시트를 채우는 방법을 익히면 4개의 랩 ESXi 노드에서 SDDC를 얼마나 빨리 롤아웃할 수 있었는지에 대해 매우 기뻤다.

몇 가지 유용한 팁

(1)Fingerprint 및 Thumbprint

매개 변수 시트를 작성할 때 SSH Fingerprint와 SSL Thumbprint를 모두 제공한다. 이 정보는 각 ESXi 호스트의 DCUI에서 사용할 수 있지만 이 정보를 검색하기 위해 각 콘솔로 이동하는 것은 PITA이다. 내 친한 친구 윌리엄은 여기 있는 자신의 사이트에서 SSL 지문을 얻는 방법에 대해 자세히 알고 있다. 하지만 SSH 지문은 어떤가?

ESXi 호스트에서 실행될 때 이 명령(William에서 가져온)은 SSL 지문을 제공한다.

[root@esx-dell-p:~] openssl x509 -in /etc/vmware/ssl/rui.crt -fingerprint -sha1 -noout
SHA1 Fingerprint=49:43:58:81:C0:20:FA:B6:20:43:8D:44:CC:D7:ED:B7:8D:48:92:E7

ssh-keyscan이 있는 호스트에서 실행할 때 이 명령은 SSH 핑거프린트를 제공한다.

chogan@chogan-a01 ~ % ssh-keyscan [ip address of host] >/dev/null | ssh-keygen -lf - | awk '{print $2}'
SHA256:ZleOMi6B3gSn43JEXrD6hfCJCgh1FPICngzYiTXykIk
(b) 적합한 용량의 디스크 없음

이 예제에서는 vSAN에 사용할 수 있는 용량 디스크가 없다고 하여 가져오기가 실패하였다. 실제적인 원인은 캐시 계층과 용량 계층에 기대되는 두 가지 유형만이 아니라 호스트 중 하나에 플래시 디바이스의 조합이 있다는 사실이었다. 정답은 KB 54793이었다. VMware Cloud Foundation for Service Provider에서 사용할 All-Flash 호스트를 구성할 때는 플래시 드라이브의 종류 또는 크기가 두 개 이하인지 확인한다. VMFS-6으로 추가 플래시 디바이스(vSAN에는 필요하지 않음)를 포맷하기만 하면 이 문제를 해결할 수 있었는데, 이 기능이 종료된 위치에서 다시 시도하는 것은 좋은 기능이다. 내 친구 Paudie에게 그 팁을 주겠다.

416A7D53-C6BB-4D33-954F-7B02FBA30120.png

(c) 올바른 라이센스가 있는지 확인

고객 환경에서는 이런 일이 일어날 것 같지 않지만, 여러분 중 가정 실험실에 있는 사람들에게는 문제가 될 수 있다. 호스트가 Distributed Switch에 가입하지 못할 때 라이센스에 문제가 발생한다:

vSphere Client에 로그인한 후 즉시 vCenter 및 호스트 라이센스가 일치하지 않는다는 경고가 표시된다. 새 표준 vCenter 라이센스를 제공하고(이전에는 필수 항목만 제공) 연결이 끊긴 호스트를 vCenter에 다시 연결한 후 RETRY를 누른다. 이번에는 ESXi 호스트가 Distributed Switch에 성공적으로 추가된다.

(a) vSAN 네트워크의 VLAN을 잘못 선택하고 (b) Log Insight Load Balancer에 할당했던 중복 IP 주소가 네트워크에 있는 경우(이 두 문제 모두 내 잘못이었다. 다행히 관리 vCenter에 로그인하고 vSAN 네트워크의 분산 포트 그룹의 VLAN ID를 수정하여 VLAN 문제를 해결할 수 있었다. 나는 또한 중복 IP(K8s 서비스)를 추적하여 네트워크에서 제거하여 Log Insight 로드 밸런서 구성이 완료되도록 했다.

이것은 모든 것을 바로 세우는 좋은 교훈이다. 이것들은 다루기에 충분히 쉬웠지만, 배치 후에 구성을 수정할 방법은 없다. 만약 당신이 잘못된 IP 주소를 어떤 것에 사용한다면, 당신은 아마도 만들어진 모든 것을 삭제하고 다시 시작해야 할 것이다. 그래서 그 교훈은, 가져오기를 하기 전에 두 번 체크하고 세 번 체크하는 것이다.

SDDC가 성공적으로 전개됐다 - woot!

모든 작업이 잘 진행되고 있으며, 추가 문제가 발생하지 않으면 전체 SDDC를 가동하고 실행한다. Cloud Builder는 SDDC Manager에 대한 링크를 제공하며 이제 워크로드 도메인 생성을 시작할 준비가 됐다. 아래 스크린샷과 비슷할 것이다.

Screenshot-2020-01-09-at-151755.png

SDDC Manager를 살펴보자. 향후 게시물에서 이 문제에 대해 좀 더 자세히 알아보겠다.

SDDC-Manager.png

그리고 여기에 vSphere 클라이언트에서 볼 수 있듯이 구축된 SDDC가 있다. 4개의 ESXi 노드, NSX Manager 및 3개의 컨트롤러(노드 항목)를 볼 수 있다. 2개의 외부 PSC(플랫폼 서비스 컨트롤러), 3개의 노드 Log Insight 클러스터 및 SDDC Manager가 있는 vCenter를 확인한다. Cloud Builder(vcf-cb-01)는 이제 목적을 달성했으므로, 제거할 수 있다.

VCF-SDDC-Inventory.png

우리가 지금 해야 할 몇 가지 다른 단계들이 있다. 그 중 하나는 vRealize Operations 및 vRealize Automation과 같은 일부 추가 vRealize 제품의 롤아웃이다. 그런 다음 워크로드 도메인과 다른 가상 인프라, Horizon View 또는 PKS를 위한 원격 워크로드 도메인을 살펴볼 수 있다. 나는 그것들을 빨리 찾을 수 있도록 노력할 것이다. 우리는 이것들이 미래의 몇몇 게시물들을 살펴볼 것이다.

VCF에 대해 자세히 알아보려면 다음 링크를 확인하십시오. 이것은 VMware.com의 공식 제품 페이지고 이것은 FAQ이다. VCF 3.9 릴리스 노트가 여기에 있다. 여기까지 읽어줘서 고마워.