VMware Engine용 프라이빗 클라우드 네트워킹
이 문서에서는 Google Cloud VMware Engine의 개요를 제공하고, 네트워킹 개념을 설명하고, 가장 일반적인 트래픽 흐름을 검토하고, VMware Engine을 사용하여 아키텍처를 설계할 때 고려해야 할 사항을 알려드립니다. 또한 VMware Engine의 작동 방식과 기능, 최고의 아키텍처를 결정할 때 고려할 사항을 설명합니다.
이 문서는 Google Cloud에서 호스팅되는 VMware 지원 애플리케이션의 보안, 연결, 가용성을 설계, 유지관리 또는 문제 해결하는 작업을 담당하는 네트워크 엔지니어, 클라우드 엔지니어, 설계자 또는 운영자를 위해 작성되었습니다.
이 문서에서는 VMware Engine 및 해당 요구사항과 기능에 대해 자세히 알아볼 수 있습니다. 해당 기술을 자세히 살펴보거나 기술을 시험 사용 또는 프로덕션에 배포하려는 경우, 이 문서를 통해 VMware Engine의 작동 방식과 신규 또는 기존 Google Cloud 환경에 통합하는 방법을 이해할 수 있습니다. 이 문서에서는 네트워킹의 모든 특성을 검토하고 해당 사용 사례에 가장 적합한 솔루션을 결정할 수 있도록 도와줍니다.
VMware Engine 네트워킹은 온프레미스 네트워크 및 기타 Google Cloud 서비스와도 기존 연결이 있는 Virtual Private Cloud(VPC) 네트워크와 통합됩니다. VMware Engine은 우수한 성능과 안정적인 고대역폭 인프라를 기반으로 빌드되어, 고객에게 비용 효율적인 최적의 VMware 경험을 제공합니다.
개요
VMware Engine은 Google Cloud에서 VMware 워크로드를 마이그레이션하고 실행할 수 있도록 Google에서 제공되는 서비스입니다.
VMware Engine은 VMware vSphere, vCenter Server, vSAN, NSX-T 구성요소로 구성되는 완전 관리형 VMware 소프트웨어 정의 데이터 센터(SDDC)를 제공합니다. VMware Engine에는 기업 프로덕션 워크로드를 지원하도록 Google Cloud의 전용 환경에서 클라우드 통합을 위한 HCX가 포함되어 있습니다. VMware Engine을 사용하여 Google Cloud Console을 통해 직접 전용 VMware 환경에 연결하여 온프레미스 워크로드를 Google Cloud로 마이그레이션하거나 확장할 수 있습니다. 이 기능을 사용하면 애플리케이션을 리팩터링하는 비용 또는 복잡성 없이 클라우드로 마이그레이션하고, 온프레미스 환경과 일관성 있게 워크로드를 실행하고 관리할 수 있습니다. Google Cloud에서 VMware 워크로드를 실행하면 확장성 및 민첩성 이점을 활용하면서도 작업 부담을 줄이고, 기존 도구, 정책, 프로세스와의 연속성을 유지할 수 있습니다.
VMware Engine은 Google Cloud의 고성능, 확장 가능한 인프라를 기반으로 구축되었으며, 완전 중복성 및 전용 100Gbps 네트워킹과 최대 99.99% 가용성을 제공하여 VMware 스택의 요구를 충족시켜 줍니다. Cloud Interconnect 및 Cloud VPN과 같은 클라우드 네트워킹 서비스는 온프레미스 환경에서 클라우드로의 액세스를 제공합니다. 클라우드 서비스에 대한 이러한 연결의 높은 대역폭은 비용 및 운영 오버헤드를 최소화하면서도 성능 및 유연성을 제공하도록 최적화되어 있습니다. 이러한 서비스 및 나머지 Google Cloud 간에 엔드 투 엔드 방식의 원스톱 지원을 통해 통합되고 원활한 환경을 제공합니다.
워크로드를 이동한 후에는 BigQuery, Cloud 운영, Cloud Storage, Anthos, Cloud AI와 같은 Google Cloud 서비스에 즉시 액세스할 수 있습니다. 또한 Google Cloud는 다른 Google Cloud 제품 및 서비스와 이용 환경을 통합하기 위해 완전 통합된 청구와 ID 관리 및 액세스 제어를 제공합니다.
사용 사례
다음 다이어그램은 Google Cloud 서비스를 활용하면서 Google Cloud에 VMware 환경을 마이그레이션 또는 확장할 수 있는 방법을 보여주는 대표적인 참조 아키텍처입니다. VMware Engine은 다음 사용 사례에 대한 솔루션을 제공합니다.
온보딩 요구사항
Google Cloud에 VMware Engine 배포를 시작하기 전에 온보딩 요구사항을 읽어보세요.
시스템 구성요소
개략적으로 VMware Engine 구성요소는 다음과 같습니다.
- Google Cloud:
- VMware Engine:
- NSX-T
- HCX
- vCenter
- vSAN
- Google Cloud 조직:
- VPC 네트워크가 포함된 Google Cloud 프로젝트
- Partner Interconnect 또는 Dedicated Interconnect를 사용하는 Cloud Interconnect 또는 온프레미스 시스템에 대한 Cloud VPN 연결
- VMware Engine 리전에 대한 비공개 서비스 액세스
- 비공개 서비스 액세스 연결
- Google 관리 서비스 통합
- VMware Engine:
- (선택사항) 온프레미스 리소스:
- 네트워킹
- 스토리지
- HCX(Layer 2 연결에 권장, L2 스트레치라고도 함)
- vCenter
프라이빗 클라우드는 ESXi 호스트, vCenter, vSAN, NSX-T, HCX로 구성된 격리된 VMware 스택입니다. 이러한 구성요소를 통틀어 Google Cloud VMware Engine 구성요소라고 하며, 클라우드 관리자가 프라이빗 클라우드를 만들면 배포됩니다. 그러면 조직의 사용자가 비공개 서비스 액세스 연결을 설정하여 VPC 네트워크에서 VMware Engine 프라이빗 클라우드에 비공개로 액세스할 수 있습니다. 다음 다이어그램은 이 아키텍처를 보여줍니다.
비공개 서비스 액세스는 VPC 네트워크와 Google 또는 타사 소유 네트워크 간의 비공개 연결입니다. Google 또는 타사 등 서비스 제공 법인은 서비스 제작자라고도 합니다.
VMware Engine에 연결된 VPC 네트워크마다 Google Cloud에 비공개 서비스 액세스 연결을 만들 때 생성되는 서비스 제작자 VPC 네트워크가 있습니다. Google Cloud 프로젝트에는 Memorystore 및 Cloud SQL과 같은 다른 Google Cloud 서비스에 연결하는 데 사용할 수 있는 공유 VPC 네트워크가 있습니다. 예를 들어 VMware Engine 워크로드에서 이러한 데이터베이스에 계속 액세스하도록 허용하면서 온프레미스 MySQL 또는 PostgreSQL VM을 VMware Engine으로 리프트 앤 시프트한 후 Google Cloud에 포함된 데이터베이스 마이그레이션 서비스를 사용하여 Cloud SQL에 마이그레이션할 수 있습니다.
VMware에서는 NSX-T를 온프레미스로 사용할 필요가 없습니다. 또한 다른 메커니즘을 사용하여 Layer 2(L2) 스트레치 및 워크로드 마이그레이션을 달성할 수 있으므로 사용 사례에 대해 HCX 사용이 필수가 아닙니다. 그러나 이 옵션을 선택하면 프라이빗 클라우드를 만들 때 이 기능이 자동으로 배포되므로 효율적인 워크로드 마이그레이션 및 편의성을 위해 HCX를 사용하는 것이 좋습니다.
네트워킹 기능
다음은 VMware Engine의 네트워킹 기능에 대한 요약 설명입니다.
- 다중 VPC 연결: VMware Engine을 사용하면 동일한 프라이빗 클라우드를 여러 VPC 네트워크에 연결할 수 있습니다(총 3개, 리전 인터넷 서비스를 사용하는 경우 2개). 이러한 VPC 네트워크는 소비자 VPC 네트워크 또는 관리형 파트너 서비스(MPS)일 수 있습니다.
- 서브넷: 프라이빗 클라우드에서 관리 및 워크로드 서브넷을 만들 수 있습니다.
- 동적 라우팅: NSX에서 관리하는 VMware Engine 서브넷은 BGP(Border Gateway Protocol)를 통해 나머지 Google 네트워크와 온프레미스 위치에 자동으로 공지됩니다.
- 리전 및 전역 라우팅 기능: 프라이빗 클라우드를 연결하는 서비스 제작자 공유 VPC 네트워크가 리전 내에서만 또는 전역으로 라우팅할 수 있는지 여부를 제어할 수 있습니다.
- 공개 IP 서비스 및 인터넷 게이트웨이(인그레스 및 이그레스): VMware Engine은 인그레스 및 인터넷 게이트웨이 이그레스를 위해 고유한 공개 IP 서비스가 있습니다. 이것은 리전 서비스입니다.
- 방화벽 정책: VMware Engine에서는 NSX 분산 방화벽(횡방향) 및 NSX 게이트웨이 방화벽(종방향)을 사용하여 L4 및 L7 방화벽 정책을 만들 수 있게 해줍니다. 예를 들어 웹 서버와 같은 공개 IP 주소로 워크로드에 액세스하도록 세부적인 제어를 적용할 수 있습니다.
- 횡방향 보안을 위한 서비스 체이닝: 파트너 보안 솔루션(IDS, IPS 또는 NGFW)을 등록하여 VM 간에 이동하는 횡방향 트래픽을 검사하도록 네트워크 서비스를 구성하는 기능을 제공합니다.
- 엔드포인트 보호: VMware Engine으로 지원되는 VM은 지원되는 제3자와의 파트너 통합을 통해 맬웨어 및 바이러스로부터 보호될 수 있습니다. 자세한 내용은 공식 VMware 문서를 참조하세요.
- 다른 Google 서비스에 대한 비공개 액세스: VMware Engine은 비공개 Google 액세스 및 비공개 서비스 액세스를 사용하여 다른 Google Cloud 서비스와 통합됩니다. 지원되는 전체 서비스 목록은 서비스에 대한 비공개 액세스 옵션을 참조하세요.
- DNS 기능
- 관리 어플라이언스 액세스를 위한 DNS: Cloud DNS를 사용하여 VMware Engine 관리 어플라이언스(예: vCenter 및 NSX Manager)의 전역 주소 확인을 사용하면 사용자 개입 없이 어플라이언스에 액세스할 수 있습니다.
- 워크로드 DNS: 모든 비공개 클라우드에 대해 가장 적합한 DNS 설정을 결정합니다. NSX-T DNS 서비스를 사용하면 DNS 쿼리를 특정 DNS 서버로 전달할 수 있고 VMware Engine 또는 온프레미스에서 DNS 서버를 만들거나, Cloud DNS 또는 Compute Engine을 사용할 수 있습니다.
- DHCP 서버: NSX-T 세그먼트에 대한 DHCP 서버 지원이 포함됩니다.
- DHCP 릴레이: DHCP 릴레이를 사용하면 예를 들어 조직이 온프레미스 IP 주소 관리(IPAM) 시스템과 통합할 수 있습니다.
- 사이트 간 Layer 2 VPN 및 Layer 3 VPN: 이러한 서비스는 각각 Layer 2 VPN 및 IPsec VPN을 사용하여 NSX에 직접 구성됩니다.
- 부하 분산: 이 서비스는 상태 확인은 물론 L4 및 L7 지원을 포함하는 NSX-T의 기본 제공되는 부하 분산 기능을 사용합니다.
- 부분 IP 멀티캐스트 라우팅 지원: VMware 문서에 설명된 대로 프로토콜 독립 실행형 멀티캐스트(PIM)가 지원됩니다.
- 부분 IPv6 지원: 이 기능을 통해 조직은 NSX-T 3.0 설 가이드에 설명된 대로 VMware Engine 지원 애플리케이션에 IPv6를 활용할 수 있습니다.
- 장거리 VM 마이그레이션(vMotion): 온프레미스 및 클라우드 간에 또는 포함된 WAN 최적화, 암호화, 복제 지원 이동성을 지원하는 VMware Engine 내에서 클라우드 간에 라이브(애플리케이션 실행이 계속됨) 및 콜드(애플리케이션 전원이 차단됨) 마이그레이션 모두 지원됩니다. 이러한 지원은 서비스에 포함된 VMware HCX 덕분입니다.
- 고급 네트워크 작업: 폴링 및 트랩과 함께 포트 미러링, Traceflow, 패킷 캡처, SNMP v1/ v2/v3 등의 기본 제공 NSX 도구 및 계측을 사용할 수 있습니다.
네트워크 및 주소 범위
Google Cloud VMware Engine은 VMware Engine 서비스가 배포되는 각 리전에 대해 네트워크를 만듭니다. 네트워크는 기본적으로 라우팅이 사용 설정된 단일 TCP Layer 3 주소 공간입니다. 이 리전에서 생성된 모든 프라이빗 클라우드 및 서브넷은 추가 구성 없이도 서로 통신할 수 있습니다. 워크로드 가상 머신에 NSX-T를 사용하여 네트워크 세그먼트(서브넷)를 만들 수 있습니다. 온프레미스 네트워크, 프라이빗 클라우드의 관리 네트워크, VPC 서브넷과 겹치지 않는 RFC 1918 주소 범위를 구성할 수 있습니다. 비공개로 사용되는 공개 IP(PUPI) 주소도 지원됩니다.
기본적으로 모든 서브넷은 서로 통신하여 프라이빗 클라우드 간의 라우팅에 대한 구성 오버헤드를 줄입니다. 동일한 리전의 프라이빗 클라우드 간의 데이터 트래픽은 동일한 Layer 3 네트워크에 유지되고 리전 내 로컬 네트워크 인프라를 통해 전송되므로 이러한 프라이빗 클라우드 간의 통신에 이그레스가 필요하지 않습니다. 이 접근 방식에서는 서로 다른 프라이빗 클라우드에 다른 워크로드를 배포할 때 WAN 또는 이그레스 성능 페널티를 없애줍니다.
개념적으로 비공개 클라우드는 vCenter 서버에서 관리되는 격리된 VMware 스택(ESXi 호스트, vCenter, vSAN, NSX) 환경으로 생성됩니다. 관리 구성요소는 vSphere/vSAN 서브넷 CIDR 범위에 선택된 네트워크에 배포됩니다. 네트워크 CIDR 범위는 배포 중에 서로 다른 서브넷으로 분할됩니다.
VMware Engine의 관리 서브넷
VMware Engine에는 여러 IP 주소 범위가 사용됩니다. 일부 IP 주소 범위는 필수이며 배포하려는 서비스에 따라 달라집니다. IP 주소 공간은 온프레미스 서비스넷, VPC 서브넷, 계획된 워크로드 서브넷과 겹치지 않아야 합니다. 다음 섹션에서는 IP 주소 범위 및 이 범위를 사용하는 해당 서비스의 집합을 설명합니다.
아래는 다음 섹션에서 설명하는 서비스의 관리 서브넷 개요를 제공하는 다이어그램입니다.
vSphere/vSAN CIDR
프라이빗 클라우드를 초기화하고 만들려면 다음 IP 주소 범위가 필요합니다.
| 이름 | 설명 | 주소 범위 |
|---|---|---|
| vSphere/vSAN CIDR | VMware Management 네트워크에 필요 프라이빗 클라우드 생성 중에 지정해야 함. vMotion에도 필요합니다. | /21, /22, /23 또는 /24 |
비공개 클라우드를 만들면 여러 관리 서브넷이 자동으로 생성됩니다. 관리 서브넷은 이 문서의 앞 부분에서 설명한 필수 vSphere/vSAN CIDR 할당을 사용합니다. 다음은 이 CIDR 범위를 사용하여 생성된 서로 다른 서브넷에 대한 예시 아키텍처 및 설명입니다.
- 시스템 관리: ESXi 호스트의 관리 네트워크, DNS 서버, vCenter 서버를 위한 VLAN 및 서브넷입니다.
- vMotion: ESXi 호스트의 vMotion 네트워크용 VLAN 및 서브넷.
- vSAN: ESXi 호스트의 vSAN 네트워크용 VLAN 및 서브넷.
- NsxtEdgeUplink1: 외부 네트워크의 VLAN 업링크용 VLAN 및 서브넷.
- NsxtEdgeUplink2: 외부 네트워크의 VLAN 업링크용 VLAN 및 서브넷.
- NsxtEdgeTransport: NSX-T에서 Layer 2 네트워크의 범위를 제어하는 전송 영역에 대한 VLAN 및 서브넷.
- NsxtHostTransport: 호스트 전송 영역용 VLAN 및 서브넷.
예:
지정된 vSphere/vSAN 서브넷 CIDR 범위는 여러 서브넷으로 구분됩니다. 다음 표에서는 CIDR 범위로 192.168.0.0을 사용하여 허용되는 프리픽스(/21~/24)의 구분 예시를 제공합니다.
| 지정된 vSphere/vSAN 서브넷 CIDR/프리픽스 | 192.168.0.0/21 |
192.168.0.0/22 |
192.168.0.0/23 |
192.168.0.0/24 |
|---|---|---|---|---|
| 시스템 관리 | 192.168.0.0/24 |
192.168.0.0/24 |
192.168.0.0/25 |
192.168.0.0/26 |
| vMotion | 192.168.1.0/24 |
192.168.1.0/25 |
192.168.0.128/26 |
192.168.0.64/27 |
| vSAN | 192.168.2.0/24 |
192.168.1.128/25 |
192.168.0.192/26 |
192.168.0.96/27 |
| NSX-T 호스트 전송 | 192.168.4.0/23 |
192.168.2.0/24 |
192.168.1.0/25 |
192.168.0.128/26 |
| NSX-T 에지 전송 | 192.168.7.208/28 |
192.168.3.208/28 |
192.168.1.208/28 |
192.168.0.208/28 |
| NSX-T Edge Uplink1 | 192.168.7.224/28 |
192.168.3.224/28 |
192.168.1.224/28 |
192.168.0.224/28 |
| NSX-T Edge Uplink2 | 192.168.7.240/28 |
192.168.3.240/28 |
192.168.1.240/28 |
192.168.0.240/28 |
선택한 CIDR 범위에 따라 각 서브넷의 서브넷 마스크가 변경됩니다. 예를 들어 /21의 vSphere/vSAN CIDR을 선택하면 /24 시스템 관리 서브넷, /24 vMotion 서브넷, /24 vSAN 서브넷, /23 NSX-T 호스트 전송 서브넷, /28 NSX-T 에지 전송 서브넷, /28 NSX-T 에지 uplink1, /28 NSX-T 에지 uplink2가 생성됩니다.
HCX 배포 CIDR 범위
프라이빗 클라우드의 HCX에는 다음 IP 주소 범위가 필요합니다.
| 이름 | 설명 | 주소 범위 |
|---|---|---|
| HCX 배포 CIDR 범위 | HCX 네트워크 배포에 필요. 프라이빗 클라우드 생성 시 선택적. | /27 이상 |
할당된 IP 주소 범위
다음 IP 주소는 VMware Engine에 대한 비공개 서비스 액세스를 위해 필요합니다.
| 이름 | 설명 | 주소 범위 |
|---|---|---|
| 할당된 IP 주소 범위 | VMware Engine을 포함한 Google Cloud 서비스에 대한 비공개 서비스 연결에 사용할 주소 범위. | /24 이상 |
Edge 서비스 및 클라이언트 서브넷
다음 IP 주소 범위는 VMware Engine에서 제공되는 에지 네트워킹 서비스를 사용 설정하기 위해 필요합니다.
| 이름 | 설명 | 주소 범위 |
|---|---|---|
| Edge 서비스 CIDR 범위 | 지점 및 사이트 간 VPN과 같은 선택적인 에지 서비스, 인터넷 액세스, 공개 IP 주소가 사용 설정된 경우에 필요합니다. 범위는 리전별 기준으로 결정됩니다. | /26 |
| 클라이언트 서브넷 | 지점 및 사이트 간 VPN에 필요. DHCP 주소는 클라이언트 서브넷에서 VPN 연결에 제공됨. | /24 |
서비스에 대한 Google 비공개 액세스 옵션
Google Cloud는 VMware Engine 또는 Google VPC 네트워크에서 실행되는 워크로드에 대한 몇 가지 비공개 액세스 옵션을 제공합니다. 비공개 서비스 액세스는 VPC 네트워크와 VMware Engine 서비스 간의 비공개 연결을 제공합니다. 비공개 Google 액세스를 사용하는 경우 VMware 워크로드가 Google Cloud 네트워크를 나가지 않고도 다른 Google Cloud API 및 서비스에 액세스할 수 있습니다.
비공개 서비스 액세스
VMware Engine은 비공개 서비스 액세스를 사용하여 VPC 네트워크를 비공개 IP 주소 지정을 사용해 Google 조직의 테넌트 폴더에 있는 서비스 제작자 VPC 네트워크에 연결합니다.
비공개 서비스 액세스를 구성하는 방법은 비공개 서비스 액세스 구성을 참조하세요. 비공개 서비스 액세스는 VPC 네트워크 피어링 연결을 만들기 때문에 경로 가져오기 및 내보내기가 중요합니다.
Google 및 타사(서비스 제작자라고 함)는 VPC 네트워크에서 호스팅되는 내부 IP 주소로 서비스를 제공할 수 있습니다. 비공개 서비스 액세스를 사용하면 이러한 내부 IP 주소에 연결할 수 있습니다. 비공개 연결은 다음 기능을 지원합니다.
VPC 네트워크와 VMware VM의 VM 인스턴스는 내부 IP 주소만을 사용하여 통신합니다. VM 인스턴스는 비공개 서비스 액세스를 통해 사용 가능한 서비스에 도달하기 위해 인터넷 액세스 또는 외부 IP 주소가 필요하지 않습니다.
내부 IP 주소를 사용하여 비공개 서비스 액세스를 지원하는 VMware VM과 Google Cloud 지원 서비스 간의 통신.
Cloud VPN 또는 Cloud Interconnect를 사용하여 VPC 네트워크에 온프레미스 연결을 설정한 경우 기존의 온프레미스 연결을 사용하여 VMware Engine 프라이빗 클라우드에 연결할 수 있습니다.
자체 프로젝트에서 공유 VPC 네트워크를 사용하는 경우 서비스 프로젝트의 VM 인스턴스가 환경과 연결할 수 있도록, 할당된 IP 주소 범위와 비공개 연결을 호스트 프로젝트에 만들어야 합니다.
비공개 서비스 액세스를 VMware Engine 프라이빗 클라우드 만들기와 독립적으로 설정할 수 있습니다. VPC 네트워크를 연결할 프라이빗 클라우드를 만들기 전이나 후에 비공개 연결을 만들 수도 있습니다.
따라서 비공개 서비스 액세스를 구성할 때 내부 IP 주소 범위를 할당한 후 이전 섹션의 설명에 따라 비공개 연결을 만들어야 합니다. 이 할당된 범위는 비공개 서비스 액세스 연결을 위해 사용되는 예약된 CIDR 블록이며 로컬 VPC 네트워크에 사용될 수 없습니다. 이 범위는 서비스 제작자를 위해서만 설정되며, VPC 네트워크와 서비스 제작자의 VPC 네트워크가 겹치지 않도록 합니다. 비공개 서비스 연결을 만들 경우 할당을 지정해야 합니다. 서비스 제작자 측면에 대한 상세 설명은 비공개 서비스 액세스 사용 설정을 참조하세요.
IP 주소가 겹치지 않도록 방지하기 위해 비공개 서비스 연결에서 모든 VMware Engine 서브넷을 할당하는 것이 좋습니다. 다음 스크린샷에서는 비공개 서비스 연결을 위해 VMware Engine CIDR 블록이 사용되고 IP 주소 겹침을 방지하기 위해 gcve-2 CIDR 블록이 할당됩니다.
서비스 네트워킹은 수신된 동적 경로에서 겹치는 주소를 확인하지 않으므로 비공개 서비스 액세스를 VMware 이외 서비스용으로 예약된 프리픽스와 연결해야 합니다. 이렇게 하면 CIDR 범위를 예약하고 이를 VPC 네트워크에서 사용할 수 없기 때문에 IP 주소 겹침으로 인한 문제를 방지할 수 있습니다.
비공개 서비스 액세스를 구성할 때는 servicenetworking-googleapis-com 비공개 연결에서 모든 경로 가져오기 및 내보내기를 올바르게 수행하도록 VPC 피어링 연결이 구성되었는지 확인합니다. 또한 VMware Engine에서 비공개 연결을 설정할 때 사용할 수 있도록 피어링된 프로젝트 ID를 기록해두어야 합니다.
서비스 제작자 VPC 네트워크는 프라이빗 클라우드(비공개 vCenter 및 단일 NSX-T 설치)를 포함하는 VMware Engine 서비스에 자동으로 연결됩니다.
VMware Engine은 Cloud SQL, Redis용 Memorystore, Memorystore for Memcached, AI Platform Training, GKE 비공개 클러스터와 같은 비공개 서비스 액세스를 사용하는 서비스 제작자 VPC 네트워크 내에 프로비저닝된 여러 Google Cloud 서비스에 동일한 연결을 사용합니다. 이러한 서비스를 사용하려면 VMware Engine으로 비공개 서비스 연결을 설정하기 위해 사용한 CIDR 범위를 선택할 수 있습니다.
VMware Engine 서비스 포털에서 리전 상태가 연결되면 해당 리전에 대해 테넌트 프로젝트 ID를 사용하여 비공개 연결을 검토할 수 있습니다. 비공개 연결 세부정보에는 VPC 네트워크 피어링을 통해 학습된 경로가 표시됩니다. 내보낸 경로에는 리전에서 학습되고 VPC 피어링을 통해 내보낸 비공개 클라우드가 표시됩니다.
프라이빗 클라우드는 하나의 vCenter와 최대 64개의 노드가 있는 단일 NSX-T 설치를 나타냅니다. 여러 프라이빗 클라우드를 배포할 수 있습니다. 프라이빗 클라우드 하나에 대한 64노드 한도에 도달하면 다른 프라이빗 클라우드를 만들 수 있습니다. 즉, 2개의 프라이빗 클라우드, 2개의 vCenter 설치, 2개의 NSX-T 설치를 관리합니다.
사용 사례에 따라 64노드 한도에 도달하지 않고 단일 프라이빗 클라우드를 배포하거나 여러 프라이빗 클라우드를 배포할 수 있습니다. 예를 들어 데이터베이스 워크로드가 있는 하나의 프라이빗 클라우드와 VDI 사용 사례용 별도의 프라이빗 클라우드 또는 미주 워크로드용 프라이빗 클라우드와 EMEA 워크로드용 다른 프라이빗 클라우드를 배포할 수 있습니다. 또는 사용 사례에 따라 동일한 프라이빗 클라우드 내 여러 클러스터에서 워크로드를 분리할 수 있습니다.
비공개 Google 액세스
비공개 Google 액세스를 사용하면 VMware Engine VM에 외부 IP 주소를 할당하지 않고도 Google API 및 서비스에 연결할 수 있습니다. 비공개 Google 액세스가 구성된 후 트래픽은 인터넷 게이트웨이로 라우팅된 다음, Google 네트워크를 벗어나지 않고도 요청된 서비스로 라우팅됩니다.
자세한 내용은 비공개 Google 액세스: 자세히 살펴보기를 참조하세요.
주요 트래픽 흐름
이 섹션에서는 일부 주요 트래픽 흐름을 검토하고 모든 서로 다른 네트워킹 흐름을 지원하기 위해 사용되는 아키텍처를 설명합니다.
다음은 VMware Engine용 디자인을 만들 때 고려해야 할 사항에 대한 예시입니다.
VMware Engine 온프레미스 및 원격 사용자 연결
다음은 온프레미스 데이터 센터에서 또는 원격 위치에서 VMware Engine 환경에 액세스하기 위해 사용할 수 있는 옵션입니다.
- 원격 사용자 연결:
- 온프레미스 연결:
VPN 게이트웨이는 온프레미스, VPC 네트워크, 비공개 클라우드와 같은 여러 사이트 간의 보안 연결을 제공합니다. 이러한 암호화된 VPN 연결은 인터넷을 통과하여 VPN 게이트웨이에서 종료됩니다. 동일한 VPN 게이트웨이에 여러 연결을 만들면 모든 VPN 터널은 사용 가능한 게이트웨이 대역폭을 공유합니다.
지점 및 사이트 간 VPN 게이트웨이를 사용하면 사용자가 컴퓨터에서 VMware Engine에 원격으로 연결할 수 있습니다. 지점 및 사이트 간 VPN 게이트웨이는 리전당 하나만 만들 수 있습니다.
지점 및 사이트 간 VPN 게이트웨이는 TCP 및 UDP 연결을 허용하며, 컴퓨터에서 연결할 때 사용할 프로토콜을 선택할 수 있습니다. 또한 구성된 클라이언트 서브넷은 TCP와 UDP 클라이언트 모두에 사용되고, CIDR 블록에서 정의한 범위는 2개의 서브넷으로 나뉩니다(TCP용과 UDP 클라이언트용으로 하나씩).
지점 및 사이트 간 VPN은 VMware Engine 리전 네트워크와 클라이언트 컴퓨터 간에 암호화된 트래픽을 전송합니다. 지점 및 사이트 간 VPN을 사용하여 프라이빗 클라우드 vCenter 및 워크로드 VM을 비롯한 프라이빗 클라우드 네트워크에 액세스할 수 있습니다. 지점 및 사이트 간 VPN 게이트웨이 설정에 대한 상세 설명은 VMware 네트워크에서 VPN 게이트웨이 구성을 참조하세요.
또한 사이트 간 VPN 연결을 위한 Cloud VPN 또는 Cloud Interconnect을 사용하여 온프레미스 네트워크와 VMware Engine 비공개 클라우드 사이에 연결을 설정할 수 있습니다. VPC 네트워크에서 Cloud VPN 및 Cloud Interconnect를 프로비저닝합니다. 자세한 내용은 Cloud VPN 및 Cloud Interconnect 문서를 참조하세요.
VPN 연결 옵션은 NSX-T IPsec VPN, NSX-T Layer 2 VPN, HCX Layer 2 VPN입니다(예: Layer 2 스트레치 구성). NSX-T IPsec VPN의 사용 사례는 VMware Engine 프라이빗 클라우드 내에서 직접 VPN 종료를 사용하는 엔드 투 엔드 암호화입니다. NSX-T VPN 기능에 대한 상세 설명은 VMware 가상 사설망(VPN) 문서를 참조하세요.
Cloud Router 또는 Cloud VPN이 있는(그리고 경계 게이트웨이 프로토콜이 사용될 경우를 위해 VLAN 연결이 있는) VPC 네트워크에 비공개 서비스 액세스를 구성하는 것이 좋습니다. 그렇지 않으면 VPC 경로를 구성해야 합니다. 아키텍처에 여러 VPC 피어링 연결이 포함된 경우 VPC 피어링은 비전환성입니다.
Interconnect 또는 VPN을 통해 공지되는 온프레미스 경로는 경로 가져오기 및 내보내기가 구성된 경우 비공개 서비스 액세스를 통해 자동으로 전파됩니다. 이렇게 하려면 VPC 피어링 연결에서 가져오기 및 내보내기 경로를 수동으로 편집해야 합니다.
또한 VPC 네트워크 피어링은 전환 라우팅을 지원하지 않으므로 비공개 서비스 액세스를 통해 학습된 경로는 온프레미스 시스템에 자동으로 전파되지 않습니다. 다른 네트워크에서 가져온 경로는 VPC 네트워크의 Cloud Router에 의해 자동으로 공지되지 않습니다. 그러나 VPC 네트워크에서 Cloud Router의 커스텀 IP 범위 공지를 사용하여 경로를 피어 네트워크의 대상 위치와 공유할 수 있습니다. 정적 라우팅을 사용하는 Cloud VPN 터널의 경우 온프레미스 네트워크에서 피어 네트워크의 대상 범위에 대한 정적 경로를 구성해야 합니다.
VMware Engine으로 인그레스
이 섹션에서는 VMware Engine으로 인그레스에 대한 다음 옵션을 설명합니다.
- VMware Engine 공개 IP 서비스를 사용하는 인그레스
- VPC 네트워크에서 인그레스
- 온프레미스 데이터 센터에서 인그레스
선택하는 옵션은 인터넷으로 Google Cloud 인프라를 피어링하려는 위치에 따라 달라집니다. 다음 다이어그램은 이러한 인그레스 옵션을 보여줍니다.
다음 섹션에서는 각 옵션에 대해 자세히 설명합니다.
VMware Engine을 사용하는 인그레스
VMware Engine 인터넷 게이트웨이를 사용하면 VMware Engine 포털의 프라이빗 클라우드 내에 있는 리소스에 대한 주문형 공개 IP 주소를 생성하고 삭제할 수 있습니다. 이 시나리오에서는 각 공개 IP 주소는 구성된 고유한 프라이빗 클라우드 IP 주소에 해당합니다.
공개 인그레스는 NAT도 담당하는 공개 IP 게이트웨이를 통해 제공될 수 있으므로 공개 인터넷에서 들어오는 사용자는 Google 공개 IP 주소에 연결됩니다. Google 공개 IP 주소는 VMware Engine의 가상 머신 비공개 IP 주소로 변환됩니다(NSX-T 세그먼트로 지원됨).
외부의 인바운드 연결이 노출된 공개 IP로 연결되도록 허용하는 방화벽 규칙을 만들 때 방화벽 규칙은 공개 IP 게이트웨이에 적용되며, 이러한 방화벽 규칙을 VMware Engine 포털에 프로비저닝해야 합니다.
tier-0 논리 라우터는 일반적으로 인터넷에 연결하는 가상 머신과 같은 종방향 라우팅에 사용됩니다. tier-1 논리 라우터는 횡방향 라우팅에 사용되며 tier 1에 대해 여러 서브넷을 구성할 수 있습니다.
공개 IP 주소를 사용하면 인터넷 리소스가 비공개 IP 주소의 프라이빗 클라우드 리소스와 인바운드 통신을 할 수 있습니다. 비공개 IP 주소는 프라이빗 클라우드의 가상 머신 또는 소프트웨어 부하 분산기입니다. 공개 IP 주소를 사용하면 프라이빗 클라우드에서 실행 중인 서비스를 인터넷에 노출할 수 있습니다.
공개 IP 주소와 연결된 리소스는 항상 인터넷 액세스를 위해 공개 IP 주소를 사용합니다. 기본적으로 아웃바운드 인터넷 액세스만 공개 IP 주소에서 허용되며, 공개 IP 주소로 들어오는 트래픽은 거부됩니다. 인바운드 트래픽을 허용하려면 특정 포트에 대한 공개 IP 주소의 방화벽 규칙을 만듭니다.
조직의 사용자는 VM 워크로드와 같은 해당 비공개 클라우드에 있는 특정 노드에 공개 IP를 노출하고 할당할 수 있습니다. 공개 IP 주소는 하나의 비공개 IP 주소에만 할당될 수 있습니다. 공개 IP 주소는 할당을 해제할 때까지 비공개 IP 주소를 전담합니다. ESXi 호스트 또는 vCenter는 노출시키지 않는 것이 좋습니다.
공개 IP를 할당하려면 이름, 위치 또는 리전, 연결된 로컬 주소를 제공해야 합니다.
VPC 네트워크를 사용하는 인그레스
Cloud Load Balancing을 사용하여 VPC 네트워크를 통해 VMware Engine에 인그레스를 제공할 수 있습니다. 필요한 기능에 따라 원하는 부하 분산기를 선택할 때 해당 부하 분산기의 백엔드로 관리형 인스턴스 그룹(MIG) 또는 비관리형 인스턴스 그룹을 만들어 VPC 피어링 연결을 통해 트래픽을 프록시할 수 있습니다. 또한 이 시나리오에서 Google Cloud Marketplace에서 타사 가상 네트워크 어플라이언스를 사용할 수 있습니다.
SQL 삽입 또는 교차 사이트 스크립팅과 같은 분산 서비스 거부(DDOS) 및 웹 공격으로부터 애플리케이션 및 웹사이트를 보호하기 위해 Google Cloud Armor는 물론 Google에 고유한 공개 IP 공간을 사용하려는 경우를 대비하여 사용자 IP 사용(BYOIP)과 Cloud Load Balancing을 결합할 수 있습니다.
온프레미스 네트워크를 사용하는 인그레스
온프레미스 인그레스를 제공하려면 Cloud Interconnect를 사용하는 것이 좋습니다. 개념 증명을 위해 또는 낮은 처리량과 지연 시간 없음이 요구될 경우 대신 Cloud VPN을 사용할 수 있습니다.
VMware Engine에서 이그레스
VMware Engine 이그레스에는 여러 옵션이 있습니다.
- VMware Engine 인터넷 게이트웨이를 통한 이그레스
- VPC 네트워크를 통한 이그레스
- 온프레미스 데이터 센터를 통한 이그레스
다음 아키텍처에서는 VMware Engine 관점에서 이그레스 흐름에 대한 이러한 옵션을 볼 수 있습니다.
VMware Engine을 사용하는 공개 이그레스
각 리전에 대해 개별적으로 워크로드에 대한 인터넷 액세스 및 공개 IP 서비스를 구성할 수 있습니다. Google Cloud의 인터넷 에지 또는 온프레미스 연결을 사용하여 VMware 워크로드에서 인터넷 연결 트래픽을 전달할 수 있습니다.
VMware Engine 비공개 클라우드에 호스팅되는 가상 머신에서 공개 인터넷으로 향하는 트래픽은 티어0 게이트웨이를 통해 이그레스됩니다. 티어0 게이트웨이는 트래픽을 인터넷 게이트웨이로 전달합니다. 인터넷 게이트웨이는 소스 포트 주소 변환(PAT)을 수행합니다. 인터넷 서비스는 리전별 서비스이며, 각 리전에 대해 개별적으로 사용 설정됩니다.
VPC 네트워크를 사용하는 공개 이그레스
또는 VMware Engine 서비스 포털에서 인터넷 및 공개 IP 서비스를 사용 중지하고 VPC 네트워크에서 공개 이그레스를 제공할 수 있습니다. 이 경우 인터넷 액세스는 기본 0.0.0.0/0 경로를 공지한 경우 VPC 네트워크를 통과합니다.
이 패킷 흐름을 사용하려면 VMware Engine 리전에 대해 인터넷 액세스를 사용 중지하고 기본 0.0.0.0/0 경로를 삽입합니다.
또한 VPC 네트워크를 통해 트래픽을 이그레스할 수 있도록, 할당된 공개 IP 주소와 지점 및 사이트 간 VPN 게이트웨이도 삭제해야 합니다.
기본 경로는 고객 VPC 네트워크에 표시되어야 하며, 그런 다음 VMware Engine에 자동으로 전파됩니다. 기본 요건은 VPC 네트워크와 VMware Engine 사이에 VPC 피어링 연결에서 VPC 서비스 제어를 사용 설정하는 것입니다.
네트워크 주소 변환(NAT)을 수행하려면 Compute Engine 인스턴스를 배포하거나 중앙화된 타사 가상 네트워크 어플라이언스 클러스터(Cloud Marketplace에서 제공)와 연결된 내부 부하 분산기를 가리키도록 기본 경로 0.0.0.0/0을 설정하고 VPC 네트워크에서 공개 인터넷으로 이그레스하도록 인스턴스에서 소스 NAT를 수행합니다. 자세한 내용은 VPC 네트워크에서 경로 사용 방법을 참조하세요.
온프레미스 데이터 센터를 사용하는 공개 이그레스
인터넷 및 공개 IP 서비스를 사용 중지하고 온프레미스에서 공개 이그레스를 제공할 경우 온프레미스 데이터 센터를 통해 이그레스할 수 있습니다. 이렇게 하면 Cloud VPN 또는 Cloud Interconnect를 통해 온프레미스 데이터 센터에 연결되기 전 인터넷 액세스가 VPC 네트워크를 통과합니다.
온프레미스 데이터 센터를 통해 공개 이그레스를 구현하려면 기본 0.0.0.0/0 경로를 공지한 후 여기에 설명된 대로 기본 경로를 올바르게 가져올 수 있도록 피어링 연결에서 VPC 서비스 제어를 사용 설정합니다.
VPC 서비스 제어에 대한 상세 설명은 VPC 서비스 제어 문서를 참조하세요.
VPC 피어링 연결에서 VPC 서비스 제어를 사용 중지하면 기본 경로(0.0.0.0/0)가 공지되고 VPC 피어링 연결을 통해 전파되더라도 온프레미스 연결을 통한 인터넷 액세스도 사용 중지됩니다.
서비스 개요: 프라이빗 클라우드에서 프라이빗 클라우드로
프라이빗 클라우드는 VMware Engine 서비스 포털을 통해 관리됩니다. 프라이빗 클라우드에는 자체 관리 도메인에 있는 자체 vCenter 서버가 있습니다. VMware 스택은 Google Cloud 위치의 격리된 전용 베어 메탈 하드웨어 노드에서 실행됩니다. 프라이빗 클라우드 환경은 단일 장애점을 제거하도록 설계되었습니다.
다음 다이어그램은 VMware Engine의 프라이빗 클라우드 간 통신을 위한 두 가지 네트워크 경로를 보여줍니다. 경로는 프라이빗 클라우드가 동일한 리전에 있는지 또는 다른 리전에 있는지에 따라 다릅니다.
- VMware Engine 서비스 내의 동일한 리전에 있는 두 프라이빗 클라우드 간의 통신은 직접 연결을 통해 이루어집니다. 이러한 프라이빗 클라우드 간의 통신이 로컬에서 발생하도록 동일한 리전에 여러 프라이빗 클라우드를 배포할 수 있습니다.
- 프라이빗 클라우드가 서로 다른 리전에 있는 경우 Google에서 관리하고 소유하고 있는 서비스 제작자 VPC 네트워크를 통해 연결이 전송됩니다. 라우팅 모드가 전역으로 설정되어 있는 한 이 같이 적용됩니다.
서비스 개요: 프라이빗 클라우드에서 VPC로
이 섹션에서는 VPC 네트워크와 프라이빗 클라우드 사이의 연결을 검토합니다. VPC 네트워크는 비공개 서비스 액세스 모델을 사용하여 서비스 제작자 VPC 네트워크와 연결된 후 연결을 VMware Engine 리전으로 확장합니다. 전역 라우팅이 서비스 제작자 VPC 네트워크에 사용 설정되고 VMware Engine 서비스 포털에서 만드는 모든 네트워크가 NSX-T에서 등급 0 라우터에 의해 자동으로 공지됩니다. 경로 교환과 VMware Engine 및 VPC 간 연결을 위해 피어링 연결에 가져오기 및 내보내기 플래그가 사용 설정되었는지 확인합니다.
다음 다이어그램은 이 경우의 트래픽 흐름을 보여줍니다.
서비스 개요: 프라이빗 클라우드에서 공유 VPC로
공유 VPC 네트워크를 사용할 때 이 연결은 프라이빗 클라우드를 VPC 네트워크에 연결하는 이전 예시와 유사합니다. 차이점은 프라이빗 클라우드를 공유 VPC 네트워크에 연결하면 워크로드가 서비스 프로젝트에 상주하며 호스트 프로젝트 공유 VPC 네트워크의 IP 주소 공간을 사용한다는 것입니다. 따라서 공유 VPC 네트워크 및 Interconnect 또는 VPN이 구성된 호스트 프로젝트에서 비공개 서비스 액세스를 구성해야 합니다.
예를 들어 서비스 프로젝트에 프라이빗 클라우드, IAM, 결제를 사용하려면 호스트 프로젝트의 공유 VPC 네트워크에 비공개 서비스 액세스 연결이 설정되어 있는지 확인하세요.
서비스 개요: 프라이빗 클라우드에서 온프레미스로
프라이빗 클라우드에서 온프레미스로 연결되는 경우 프로젝트와 조직에 VPC 네트워크가 있으며 프라이빗 클라우드와 온프레미스 데이터 센터 간에 연결이 있습니다.
앞서 언급했듯이 VMware Engine을 설정할 때 비공개 서비스 액세스 연결을 위해 서브넷(이상적으로는 향후 충돌을 방지하기 위해 VMware Engine의 서브넷도 포함)을 할당해야 합니다. 이 서브넷을 할당하는 동안 프라이빗 클라우드가 존재하는 VMware Engine 리전에 연결하는 서비스 제작자 VPC 네트워크를 만듭니다.
VPC 피어링 연결이 생성되고 프로비저닝되면 서비스 제작자 VPC 네트워크가 VPC 네트워크에 연결됩니다. 이렇게 하면 프라이빗 클라우드에서 VPC 네트워크 내 모든 서브넷과 IP 주소에 연결할 수 있습니다. 비공개 서비스 액세스를 구성할 때 VPC 피어링 연결에서 경로 가져오기와 내보내기를 사용 설정해야 합니다.
다음 다이어그램은 VMware Engine의 프라이빗 클라우드와 온프레미스 데이터 센터 간의 엔드 투 엔드 연결을 보여줍니다.
비공개 Google 액세스: 자세히 살펴보기
Google Cloud 리소스에 외부 IP 주소를 제공하지 않고도 비공개 Google 액세스를 사용하여 Google API 및 서비스에 연결할 수 있으므로 VMware Engine 서비스가 이를 활용하고 인터넷 게이트웨이를 사용하여 Google API에 도달할 수 있습니다.
내부 IP 주소만 있는 VM 인스턴스는 비공개 Google 액세스를 활용하여 Google API 및 서비스의 외부 IP 주소에 도달할 수 있습니다. 비공개 Google 액세스가 구성되면 트래픽은 인터넷 게이트웨이로 라우팅된 다음 요청된 서비스로 라우팅됩니다.
VMware Engine에 대해 비공개 Google 액세스를 사용 설정하기 위해 VMware Engine 환경에서 비공개 가상 IP 주소를 사용하도록 DNS 서버를 구성합니다. 자세한 내용은 온프레미스 호스트용 비공개 Google 액세스 및 온프레미스 호스트용 비공개 Google 액세스 구성을 참조하세요.
private.googleapis.com 도메인에는 199.36.153.8/30이 사용됩니다.
DNS 변환을 관리하기 위해서는 NSX-T에서 제공되는 DNS 서비스를 사용하여 지정된 DNS 서버로 요청을 전달할 수 있습니다. DNS 서버는 VMware Engine, Cloud DNS, 온프레미스 DNS 서버에서 VM일 수 있습니다. 이전 섹션에 설명된 대로 인터넷에 액세스하는 방법에 따라 이러한 옵션 중 하나가 사용됩니다.
비공개 Google 액세스에서는 Cloud Storage, Cloud Spanner, BigQuery와 같은 대부분의 Google API 및 서비스를 지원합니다. 비공개 Google 액세스에서는 App Engine, Memorystore 또는 Filestore를 지원하지 않습니다. 비공개 액세스 옵션에 대한 자세한 내용은 서비스 비공개 액세스 옵션을 참조하세요.
다음은 Google Cloud 서비스에서 VMware Engine을 사용하는 방법의 예입니다.
- VMware VM에서 Cloud Storage에 액세스하여 데이터를 내보내거나 확장된 스토리지 대상으로 설정합니다.
- Cloud Monitoring을 사용하여 모든 공개, 비공개, 하이브리드 애플리케이션을 모니터링합니다.
- 데이터베이스에서 BigQuery로 데이터를 분석용으로 가져옵니다.
- 고성능 및 비공개 컨테이너식 애플리케이션 배포를 위해 Anthos를 배포합니다.
다음 다이어그램에서는 Google API 및 서비스와의 통신에 사용되는 두 가지 네트워크 경로를 보여줍니다. 비공개 Google 액세스 구성은 VMware Engine에 사용 설정된 인터넷 액세스에 따라 다릅니다.
- 인터넷 액세스가 VMware Engine을 통해 제공되고 리전에 대해 사용 설정되었으면 비공개 Google 액세스 및 인터넷 액세스에 인터넷 게이트웨이가 사용됩니다.
- 온프레미스에서 또는 VPC 네트워크를 통해
0.0.0.0/0경로를 공지하여 인터넷 액세스를 제공하는 경우 통신에서는 서비스 제작자 VPC 네트워크 인터넷 게이트웨이를 사용합니다. VMware Engine 인터넷 서비스를 통한 액세스는 무시됩니다.
옵션 1: VMware Engine에서 제공하는 인터넷 액세스를 통한 비공개 Google 액세스
리전의 VMware Engine을 통해 인터넷 액세스를 제공하는 경우 비공개 Google 액세스 및 인터넷은 인터넷 게이트웨이를 사용하고 PAT를 수행합니다. 이 경우 비공개 Google 액세스의 DNS 변환을 제외한 추가 구성이 필요하지 않습니다.
옵션 2: 온프레미스 또는 고객 VPC에서 제공하는 인터넷 액세스를 통한 비공개 Google 액세스
온프레미스로 또는 VPC 네트워크를 통해 인터넷 액세스를 제공하는 경우 조직의 테넌트 VPC 네트워크에서 인터넷 게이트웨이를 통해 Google API로 패킷을 라우팅하도록 VMware Engine 서비스를 구성해야 합니다. VPN 또는 Interconnect나 VPC 네트워크를 통해 온프레미스에 도달하려면 VPC 네트워크를 통하는 다른 트래픽의 패킷을 라우팅하도록 VMware Engine 서비스를 구성하세요.
모든 트래픽에 대해 VMware Engine 리전의 인터넷 액세스 및 공개 IP 서비스를 중지하고 온프레미스를 통해 기본 0.0.0.0/0 경로를 삽입합니다.
온프레미스 또는 VPC 네트워크를 통해 인터넷 액세스를 제공하는 경우 공개 IP 서비스를 사용 중지하기 전에 할당된 모든 공개 IP 주소와 지점 및 사이트 간 VPN 게이트웨이를 삭제하세요. VPC 네트워크에 경로가 표시되고 테넌트 VPC 네트워크로 경로가 내보내졌는지 확인합니다.
또한 VPC 네트워크와 VMware Engine 간에 VPC 피어링 연결에서 VPC 서비스 제어를 사용 설정해야 합니다.
마지막으로 Google API에 대한 액세스에서 제한된 가상 IP 주소를 사용하므로 필요한 CNAME 및 A 레코드에 따라 DNS를 구성해야 합니다. Google API에 대한 액세스는 VPC 네트워크가 아닌 Google 조직을 통해 이루어집니다.
프라이빗 클라우드에서 관리형 Partner Services로
관리형 파트너 서비스(MPS)를 사용하면 MPS 코로케이션 시설에서 호스팅하는 하드웨어 및 소프트웨어를 통해 Google Cloud 고객에게 업무상 중요한 SaaS(Software as a service) 제품을 제공할 수 있습니다.
프라이빗 클라우드와 MPS 간의 트래픽 흐름의 경우 VMware Engine은 멀티 VPC 연결을 사용합니다. 이 기능을 사용하면 추가 소비자 VPC 네트워크뿐만 아니라 Google MPS에도 연결할 수 있습니다. 다음 다이어그램에서는 프라이빗 클라우드와 MPS뿐만 아니라 추가 소비자 VPC 네트워크 간의 연결을 간단하게 보여줍니다.
추가 리소스: VMware
VMware 스택에 대한 상세 설명은 VMware 구성요소 버전 및 NSX 3.0 디자인 가이드를 참조하세요.