이제 VMware는 vSphere 7.0 Update 2(U2) 론칭의 일부로 vSphere with Tanzu를 위한 또 다른 로드 밸런서 옵션을 제공합니다. Avi Networks 기술(이전의 Avi Vantage)을 기반으로 구축된 이 새로운 로드 밸런서는 vSphere with Tanzu 배포 환경에 사용할 수 있는 또 다른 프러덕션-레디(production-ready) 로드 밸런서 옵션을 제공합니다. 이제 NSX Advanced Load Balancer 또는 줄여서 NSX ALB라고 하는 이 로드 밸런서는 슈퍼바이저 제어부 API 서버, TKG(게스트) 클러스터 API 서버 및 유형의 로드 밸런서 서비스가 필요한 모든 Kubernetes 애플리케이션에 대해 가상 IP 주소(VIP)를 제공합니다. 이 게시물에서는 새 NSX ALB의 단계별 배포를 살펴보겠습니다.
한 가지 궁금한 점은 HA-Proxy 대신 NSX ALB를 사용해야 하는 이유이거나 사용해야 하는 것입니다. 먼저 NSX ALB는 VMware에서 설계한 제품이기 때문에 예상한 엄격한 테스트와 자격 요건을 모두 거친 것입니다. 이제 vSphere with Tanzu 구축용 VMware 스택을 완벽하게 구축했으며 타사 구성 요소는 혼합하지 않았습니다. 둘째, HA-Proxy보다 훨씬 뛰어난 사용자 환경을 제공하며, 포스트에서 볼 수 있듯이 구성 및 모니터링이 훨씬 직관적입니다. 마지막으로 vSphere with Tanzu의 어떤 구성 요소가 NSX ALB UI를 통해 로드 밸런싱 서비스를 사용하고 있는지 완벽하게 파악할 수 있습니다. 이는 HA-Proxy 장치와는 관련이 없습니다.
NSX ALB는 OVA로 사용할 수 있습니다. 이 배포에서는 버전 20.1.4-2p1을 사용합니다. NSX ALB는 이 포털에서 다운로드할 수 있습니다. 배포 시 필요한 유일한 정보는 (a) 정적 IP 주소, (b) 서브넷 마스크, (c) 기본 게이트웨이 및 (d) 배포 후 어플라이언스에 안전하게 로그인할 수 있기를 원하는 사용자/시스템의 SSH 로그인 인증 키입니다. 한 가지 주의할 점은 NSX ALB에는 HA-Proxy 장치보다 훨씬 많은 리소스가 필요하다는 것입니다. HA-Proxy에는 CPU 2개, 4GB 메모리 및 20GB 디스크가 필요합니다. NSX ALB에는 CPU 8개, 24GB 메모리 및 128GB 디스크가 필요합니다. 또한 NSX ALB는 Virtual Services를 실행하기 위해 서비스 엔진이라는 추가 장치를 프로비저닝합니다. 이 장치는 나중에 게시됩니다. 이러한 서비스 엔진은 각 SE에 CPU 1개, 2GB 메모리 및 15GB 디스크가 필요한 만큼 무게가 조금 더 가볍습니다. 따라서 리소스 관리를 적절하게 계획하십시오.
NSX ALB를 배포한 후 초기화하려면 몇 분 정도 시간을 주면 브라우저를 어플라이언스의 구성된 IP 주소에 연결하여 관리 포털에 액세스할 수 있습니다.
1단계 – 네트워크 구성 계획
어플라이언스를 배포하기 전에 (a) 배포할 네트워크 토폴로지 종류와 (b) vSphere with Tanzu 배포에 대해 따로 설정해야 하는 IP 주소 범위를 메모하는 것이 좋습니다. HA-Proxy에서와 마찬가지로 FrontEnd/Load Balancer/VIP(Virtual IP) 네트워크와 Workload 네트워크 모두에 동일한 네트워크의 여러 세그먼트를 사용할 수 있습니다. 다른 옵션은 VIP 및 워크로드 노드를 두 개의 서로 다른 네트워크에 배치하는 것입니다. 워크로드 네트워크는 Tanzu 슈퍼바이저 클러스터 노드와 TKG(게스트) 클러스터 노드에서, VIP는 서로 다른 클러스터의 API 서버에서 각각 사용됩니다.
내 설정에는 VIP와 워크로드 네트워크를 위한 공유 네트워크가 있습니다. 설정을 다음과 유사하게 시각화할 수 있습니다(NSX Advanced Load Balancer Appliance와 서비스 엔진을 구분하지 않으므로 단순화된 보기임 참고). 아래 다이어그램에서 NSX ALB는 별도의 Frontend/VIP 및 Workload 네트워크가 있는 배포 환경에 있습니다. 이러한 유형의 배포가 구현되면 VIP 네트워크와 워크로드 네트워크 간에 경로가 있어야 합니다.
다음은 동일한 네트워크의 IP 주소 범위를 사용하여 VIP 주소와 워크로드 IP 주소 요구 사항을 충족하는 다른 배포 방법입니다. 다음은 내 설정에서 사용할 구성입니다.
시작하기 전에 고려해야 할 요구사항은 다음과 같습니다.
- 앞에서 언급한 관리 네트워크의 NSX ALB에 대한 1개의 정적 IP 주소
- 관리 네트워크에서 서비스 엔진의 정적 IP 주소 X개의 범위
- 관리 네트워크의 슈퍼바이저 콘트롤 플레인 노드에 대한 5개의 정적 IP 주소 범위
- 프런트 엔드/VIP 네트워크의 Y개 로드 밸런서 VIP 수 범위
- 워크로드 네트워크의 슈퍼바이저 콘트롤 플레인과 TKG(게스트) 클러스터 노드의 Z개의 IP 주소 범위
- 위의 X, Y 및 Z 범위는 관리자에 의해 결정되며 배포되는 게스트 클러스터 및 로드 밸런서 서비스
애플리케이션의 크기와 수에 따라 달라질 가능성이 높습니다. 이제 이 정보를 캡처하면 구성을 시작할 수 있습니다.
2단계 – NSX 고급 로드 밸런서 구성
첫 번째 단계는 관리자 계정을 만드는 것입니다. admin 및 선택적 전자 메일 주소에 대한 암호를 입력한 다음 Create Account를 클릭합니다. AVI 버전도 여기에 표시됩니다.
그런 다음 일부 DNS 항목과 백업 암호를 제공합니다.
동일한 창에서 아래로 스크롤하면 NTP 서버를 제공해야 합니다. 기본 NTP 서버(us.pool.ntp.org)를 유지하거나 사용자 고유의 NTP 서버를 제공하도록 선택할 수 있습니다. UI를 사용하여 기본 항목을 삭제할 수 있습니다.
그런 다음 SMTP 알림을 설정할지 여부를 결정합니다. 없으면 None으로 설정합니다.
다음 단계는 Orchestrator 통합을 선택하는 것입니다. VMware 선택:
다음에 vCenter 자격 증명을 제공합니다. Permissions을 Write(기본값)로 설정하고 SDN Integration을 None(기본값)으로 설정합니다. 이렇게 하면 NSX ALB에 기본 클라우드라는 새 클라우드 구성이 생성됩니다. vSphere with Tanzu 및 NSX ALB에서 지원되는 유일한 클라우드 구성입니다. 잠시 후 이 구성을 자세히 살펴보겠습니다.
vCenter Server에 성공적으로 연결되면 드롭다운 목록에서 Data Center를 선택합니다. 정적 IP 주소 관리를 사용하고 있으며 정적 경로도 설정하지 않고 있습니다. 앞서 언급한 바와 같이 별도의 VIP 및 워크로드 네트워크를 사용하기로 결정한 경우 정적 경로를 구현해야 할 수도 있습니다. 그 이유는 서비스 엔진이 VIP 네트워크에만 연결되어 있기 때문에 워크로드 네트워크에 연결하는 방법을 알려주려면 정적 경로를 추가해야 하기 때문입니다. VIP와 워크로드 네트워크 간 경로가 필요한 이유입니다. 그러나 설치 프로그램이 단일 플랫 네트워크에서 VIP 및 워크로드를 위한 세그먼트를 사용하고 있으므로 여기에 아무것도 추가할 필요가 없습니다.
다음 창에서는 서비스 엔진의 IP 주소 풀을 정의합니다. 선택한 네트워크가 NSX ALB 관리 주소에 연결할 수 있어야 한다는 점에 유의하여 드롭다운에서 관리 네트워크를 선택합니다. NSX ALB와 SE를 동일한 분산 포트 그룹(VL530-DPortGroup)에 둘 다 배치했습니다. 그 후에, 그것은 단순히 서비스 엔진과 게이트웨이 정보를 위한 하이픈으로 분리된 주소 범위인 CIDR 포맷을 사용하여 서브넷을 채우는 문제이다. 설정에서 서비스 엔진에 8개의 정적 IP 주소를 할당했습니다. 운영 환경에 다른 주소 범위가 필요하다고 결정할 수 있습니다.
마지막 단계는 Tenant Settings입니다. No로 설정합니다. vSphere with Tanzu 및 NSX ALB는 이 버전에서 여러 테넌트를 지원하지 않습니다.
이 시점에서 초기 설정이 완료됩니다. 이제 NSX Advanced Load Balancer 포털에 배치됩니다(아래 그림 참조).
3단계 – 추가 NSX 고급 로드 밸런서 설정
이제 로드 밸런서에 구현해야 vSphere with Tanzu에 대한 워크로드 관리를 사용하도록 설정할 수 있는 몇 가지 추가 작업이 있습니다. 이러한 작업은 다음과 같이 요약할 수 있습니다.
- 기본 인증 사용
- 워크로드 관리를 사용하도록 설정할 때 사용되는 자체 서명된 SSL/TLS 인증서 생성
- 라이센스 설치
- Service Engine Group 구성
- Service Engine Network 구성
- VIP 네트워크 구성
- 가상 서비스에 VIP를 할당하는 새 IPAM 프로파일 생성
- 기본-클라우드에 새 IPAM
- 자체 서명된 SSL/TLS 인증서 내보내기
이러한 각 작업을 수행하고 이를 구현하는 방법을 보여드리겠습니다.
3.1 단계 – 기본 인증 사용
NSX ALB 포털의 왼쪽 상단에는 3개의 병렬 라인이 있습니다. Applications, Operations, Templates, Infrastructure, Administration가 포함된 드롭다운 메뉴를 보려면 이 옵션을 클릭하십시오. Administration를 선택합니다. 브라우저 상단에는 Accounts, Settings, Controller 등의 항목이 표시됩니다. Settings을 선택합니다. Authentication/Authorization, Access Settings, DNS/NTP등과 같은 항목의 하위 메뉴를 제공해야 합니다. Access Settings 설정을 선택합니다. 오른쪽에는 연필 아이콘이 있어야 합니다. System Access Settings을 편집하려면 이 옵션을 클릭하십시오. 마지막으로 아래와 같이 “Allow Basic Authentication” 확인란을 선택합니다. 다음에서 변경:
이렇게:
3.2단계 – 자체 서명된 SSL/TLS 인증서 생성
시스템 액세스 설정에 머무르면서 새 자체 서명 인증서를 생성합니다. 물론 직접 서명된 인증서를 가져올 수도 있지만, 제 경우에는 편의를 위해 자체 서명된 인증서로 진행하려고 합니다. 나중에 vSphere에서 워크로드 관리를 설정할 때 이 인증서를 제공해야 합니다.
SSL/TLS 인증서 섹션의 설치에서 이미 존재하는 인증서를 삭제합니다. 내 설정에는 System-Default-Portal-Cert와 System-Default-Portal-Cert-EC256이라는 이름이 있었다.
원래 SSL/TLS 인증서를 삭제한 후 시스템 액세스 설정은 다음과 같이 표시됩니다.
그런 다음 SSL/TLS 인증서 드롭다운을 클릭하고 Create Certificate 옵션을 선택합니다.
Name을 제공하고 Type이 Self Signed으로 설정되어 있는지 확인하고, 해당 유형이 NSX ALB의 FQDN이어야 하는 Common Name을 지정하고, 마지막으로 NSX ALB의 IP 주소와 동일한 Subject Alternate Name (SAN)을 제공합니다. Algorithm, Key Size, Days Until Expiry는 기본값으로 둘 수 있습니다. 인증서 관리에 대한 자세한 내용은 공식 문서에서 확인할 수 있습니다. 자체 서명된 인증서가 생성되면 인증서를 Save한 다음 업데이트된 시스템 액세스 설정을 Save할 수 있습니다. 자체 서명된 인증서를 변경한 후 브라우저를 새로 고쳐야 합니다.
3.3단계 – 라이센스 설치
라이센스 섹션은 Administration > Settings 섹션에도 있습니다. 키를 통해 설치하거나 파일로 업로드할 수 있습니다.
적용되면 이 화면의 라이센스 목록에 새 라이센스가 표시되어야 합니다.
3.4단계 서비스 엔진 그룹 구성
OK – 이제 대부분의 하우스키핑 작업이 완료되었습니다. 이제 나머지 구성 설정으로 이동할 때입니다. 왼쪽 위 모서리에 있는 기본 ‘three-bar’ 아이콘에서 목록에서 Infrastructure를 선택합니다. 그러면 창 위쪽의 메뉴 항목 목록이 변경됩니다. 이 목록에는 Service Engine Group이 나와 있습니다. 기본 그룹이라는 Service Engine Group을 표시합니다. 편집할 오른쪽에 있는 연필 아이콘을 클릭합니다. Basic Settings 및 Advanced 두 가지 구성 화면이 있습니다. 고급 화면에서 서비스 엔진 배치(예: 클러스터, 호스트 및 데이터스토어)에 사용할 vSphere 개체를 선택할 수 있습니다. 여기서 변경한 유일한 사항은 클러스터를 선택하고 데이터 저장소를 공유하도록 설정하는 것입니다. 다음과 같습니다.
다른 건 다 기본 사항으로 남겨뒀어요 그러나 가용성 목적으로 배포할 수 있는 Service Engines 수(HA 모드), SE에서 실행할 수 있는 Virtual Services 수, 확장할 수 있는 규모 등과 같은 고급 구성 설정을 훨씬 더 많이 수행할 수 있습니다. 공식 AVI 문서에는 이 블로그 게시물의 범위를 벗어난 이러한 고려 사항에 대한 HA 및 Placement에 대한 많은 정보가 있습니다.
3.5단계 – 서비스 엔진 네트워크 확인
인프라 보기에서 네트워크를 선택합니다. 여기서는 vSphere 환경의 모든 네트워크를 볼 수 있습니다. VL530-DPortGroup이 관리 네트워크이고 VL530-DPortGroup이 결합된 VIP/워크로드 네트워크에 사용되는 환경에서 이렇게 나타납니다.
초기 구축의 일환으로 Service Engines의 관리 네트워크와 IP 주소 범위를 선택했습니다. 이러한 서브넷은 관리 네트워크에서 구성되었으며 위의 서비스 엔진에 8개의 IP 주소를 사용할 수 있는 구성된 서브넷이 있습니다. 자세히 살펴보려면 관리 네트워크와 연결된 + 기호를 클릭하면 됩니다. 여기에는 다음과 같은 내용이 표시됩니다.
네트워크가 정적 IP 풀로 구성되었습니다. 자세히 보려면 네트워크 오른쪽에 있는 연필 아이콘을 클릭하십시오. 네트워크 설정이 표시됩니다. 주소 풀 설정을 보려면 IP 주소 풀 오른쪽에 있는 연필 아이콘을 클릭합니다. 그런 다음 다음과 같은 내용이 표시되어야 합니다.
모든 것이 구성된 것처럼 보입니다. 좋아요! 취소를 클릭하고 다시 취소를 클릭합니다. 관리 네트워크의 서비스 엔진의 IP 주소 범위가 올바르게 정의되었습니다.
3.6단계 – VIP 네트워크 구성
네트워크 보기에 머무르면서 이제 유사한 프로세스를 거치겠지만 이번에는 로드 밸런서 IP 주소/가상 IP 주소(VIP)에 대해 살펴보겠습니다. 로드 밸런서 서비스가 필요한 다양한 Kubernetes 제어부 및 Kubernetes 응용 프로그램에서 사용하는 IP 주소입니다. 네트워크 목록에서 VIP가 상주할 네트워크를 선택합니다. 연필 아이콘을 다시 한 번 클릭하여 설정을 편집합니다.
이제 +ADD Subnet 버튼을 클릭합니다. IP 서브넷을 추가하고 CIDR 형식을 사용하여 네트워크 서브넷을 추가합니다. 그런 다음 해당 보기에서 연필 아이콘을 클릭해서 +Add Static IP Address Pool를 봅니다.
이제 제어 영역 및 로드 밸런서 서비스에 할당할 VIP 주소 범위를 추가하십시오. 제 환경에서는 VIP를 8밖에 할당하지 않았기 때문에 이것을 작게 유지하고 있습니다. 다시 말해, 이는 매우 작은 범위의 VIP이므로 프로덕션 환경을 위해 훨씬 더 광범위한 VIP를 고려할 수 있습니다.
IP 서브넷에 사용되는 CIDR 형식을 확인합니다. 주소 범위는 네트워크 CIDR의 하위 집합이어야 합니다. 이 네트워크의 일부만 개인 용도로 사용할 수 있습니다. 나중에 vSphere에서 워크로드 관리를 사용하도록 설정할 때 주의해야 하며 워크로드 네트워크 주소 범위에 동일한 서브넷 마스크를 사용해야 합니다. 이는 VIP 네트워크와 워크로드 네트워크의 개체가 성공적으로 통신할 수 있도록 하기 위함입니다. 저장을 클릭하고 다시 저장을 클릭합니다. 이제 FrontEnd/VIP 네트워크의 VIP에 대한 IP 주소 범위가 정의되었습니다. 이제 서비스 엔진과 서브넷이 구성된 VIP 네트워크를 통해 네트워크 보기가 다음과 같이 표시됩니다.
3.7 가상 서비스에 VIP를 할당하는 새 IPAM 생성
IPAM은 앞서 언급한 쿠버네티스 제어부 및 애플리케이션과 같은 가상 서비스에 VIP를 할당하는 데 사용됩니다. 왼쪽 위 모서리에 있는 메뉴를 클릭하고 드롭다운 목록에서 템플릿을 선택합니다. 상단에서 프로필이 선택되었는지 확인한 다음 하위 항목 IPAM/DNS Profiles을 선택합니다. 오른쪽의 파란색 Create 버튼을 클릭하고 IPAM Profile을 선택합니다. 프로필 이름을 Default-IPAM으로 설정하고 유형을 AviVantage IPAM으로 설정하십시오. 그런 다음 +Add Usable Network를 클릭합니다. 여기서 사용 가능한 네트워크용 클라우드를 기본-클라우드로 설정하고 사용 가능한 네트워크를 이전 VIP에 사용된 포트 그룹으로 설정합니다(내 경우 VLAN574-DPortGroup). 내 설정은 다음과 같습니다.
저장을 클릭하여 새 IPAM 프로파일을 저장합니다.
3.8 Default-Cloud에 새 IPAM Profile 추가
기본 메뉴에서 인프라 섹션을 선택하고 클라우드 옵션을 선택합니다. 그러면 vSphere with Tanzu 및 NSX ALB에서 지원되는 유일한 클라우드 옵션인 기본 클라우드가 표시됩니다.
다시 한 번 연필 아이콘을 클릭하여 클라우드 구성을 편집합니다. 인프라 창의 아래쪽에서 IPAM Profile을 찾은 다음 드롭다운에서 이전에 생성된 Default-IPAM을 선택합니다. 따라서 이제 요청 및 스핀업된 모든 가상 서비스가 기본 IPAM VIP 범위에서 IP 주소를 얻습니다. 클라우드 구성을 저장합니다.
3.9 자체 서명된 인증서 내보내기
Templates > Security > SSL/TLS Certificates에서 다운로드할 수 있습니다. 인증서를 내보낼 가장 오른쪽 필드에 아이콘이 있습니다. 이렇게 하면 인증서를 클립보드에 복사할 수 있습니다. 그러면 설정이 완료됩니다. 이제 vSphere with Tanzu Workload Management를 사용하도록 설정할 수 있습니다.
4단계 워크로드 관리 활성화
워크로드 관리의 전체 구현은 차근차근 진행하지 않을 것입니다. 다만 이전 게시물과 다른 몇 가지 단계가 있어 언급할 만하다. 주요 차이점은 Load Balancer 네트워크가 이제 Avi를 로드 밸런서 유형으로 사용한다는 것입니다. 로드 밸런서 IP 주소 범위는 포함되지 않습니다. 이 범위는 이제 NSX ALB에서 제공합니다. 마지막으로 로드 밸런서 네트워크 구성에서 요청된 인증서가 이전에 3.9 단계에서 생성한 자체 서명 인증서입니다.
위의 관리 네트워크는 감독자 제어부 노드에서 사용하는 5개의 IP 주소 범위에서 시작 IP 주소를 찾습니다.
워크로드 네트워크는 감독자 노드 및 TKG 클러스터 노드에서 사용하는 IP 주소의 범위를 정의합니다. 서브넷은 다른 범위이긴 하지만 NSX ALB의 VIP 네트워크에 대해 사용한 것과 정확히 일치합니다. 왜냐하면 지금 몇 번 언급했듯이 그들은 같은 네트워크를 공유하고 있기 때문이다. 그러나 각 네트워크의 노드는 서로 통신할 수 있어야 합니다. 그들이 같은 서브넷에 있기 때문에, 나는 정적 경로를 가지고 아무것도 할 필요가 없었다. VIP와 워크로드 네트워크가 분리된 경우 이 작업이 필요합니다.
이제 워크로드 관리 배포가 성공했다고 가정할 수 있습니다. 이로 인해 vSphere 인벤토리에 표시되어야 하는 두 개의 Avi Service Engine(기본적으로)이 차례로 생성됩니다. 감독관제비행기는 VIP 범위에서 다음과 같은 IP 주소를 요청하고 할당받게 됩니다.
한 가지 유의할 점은 감독관제기가 VIP를 할당받았더라도 클러스터에 바로 로그인하지 못할 수 있다는 점이다. 가상 서비스/서비스 엔진 초기화가 완료될 때까지 기다려야 합니다. 상태/상태는 NSX ALB 포털에서 확인할 수 있습니다.
테스트를 완료하기 위해 TKG 게스트 클러스터도 vSphere with Tanzu 네임스페이스에 배포했으며 제어부 API 서버에도 VIP 주소가 할당되었습니다.
우리는 다음과 같이 TKG 구축을 시각화할 수 있습니다. 여기서 노드들은 워크로드 네트워크 범위에서 할당되고 API 서버는 VIP 범위에서 주소를 할당받습니다.
하지만 이전 HA-Proxy에 비해 새로운 NSX ALB의 좋은 점은 이제 어플라이언스의 상태 및 상태를 완벽하게 파악하고 누가 VIP 주소를 사용하고 있는지를 완벽하게 파악할 수 있다는 점입니다. 예를 들어, 다음은 VIP를 제공하는 Infrastructure > Service Engines의 보기입니다.
다음은 Applications > Virtual Services 뷰를 통해 가상 서비스를 사용하는 사용자를 보여 줍니다. 이 경우 하나는 슈퍼바이저 제어부 API 서버이고 다른 하나는 TKG 제어부 API 서버입니다.
결론적으로 새로운 NSX 고급 로드 밸런서는 여러 가지 면에서 HA-프록시보다 훨씬 우수합니다. 배포에 대한 사용자 환경이 크게 향상되었으며, 구성에 몇 가지 추가 단계가 필요하더라도 설정하기가 그리 복잡하지 않습니다. 가상 서비스의 상태 및 사용에 대한 가시성은 2일차 운영에 매우 유용할 것이며 vSphere에서 실행되는 Kubernetes 배포를 프로비저닝하고 관리하는 관리자에게 몇 가지 유용한 통찰력을 제공할 것입니다. NSX ALB에서 사용할 수 있는 구성 옵션은 훨씬 많습니다. 자세한 내용은 AVI Vantage 설치 가이드를 참조하십시오(AVI Vantage는 원래 이름입니다).
마지막 정보 하나. NSX ALB는 로드 밸런서 서비스만 제공합니다. 네트워크 오버레이 기능은 제공하지 않습니다. 즉, 쓰기 시 여전히 PodVM에 대한 슈퍼바이저 클러스터에서는 지원되지 않습니다. PodVM과 vSAN Data Persistence 플랫폼과 같은 슈퍼바이저 서비스를 사용하려면 전체 NSX-T를 배포해야 합니다.
