VPC 네트워크 설계

다음 정보는 IBM Cloud® Virtual Private Cloud 배포에 대한 VMware® 배포에 대한 개요를 제공합니다. VMware 인프라 네트워킹과 VPC의 분리 및 통합, 다른 워크로드 트래픽과의 연결 통합 및 구성 방법에 대한 요구 사항을 이해하는 것이 중요합니다.

VPC 서브넷

IBM Cloud VPC 에서 여러 가지 방법으로 논리적 세분화 또는 격리를 수행할 수 있습니다. 이 아키텍처는 VMware Cloud Foundation™ 요구 사항을 따르는 기존 VLAN 세분화 비유를 사용하지만 IBM Cloud VPC에서는 VLAN 대신 서브넷을 사용합니다. 각 시스템 트래픽 유형에는 고유한 VPC 서브넷이 있으며, VMkernel 어댑터 네트워크 인터페이스 간의 트래픽은 IBM Cloud VPC 보안 그룹(SG)과 서브넷 액세스 제어 목록(ACL)을 모두 사용하여 제어할 수 있습니다. 다음 다이어그램은 통합 VPC 설계의 개요를 보여줍니다.

![통합 VMware Cloud Foundation 배포를 위한 VPC 설계 * Cloud Foundation "){: caption="위한 ](../../images/vcf-vpc-v2-arch-net-cons.svg "설계 VMware 통합 VMware Cloud Foundation " caption-side="bottom"} 위한 VPC 네트워크 설계*

이 아키텍처의 경우 각 VMware Cloud Foundation 인스턴스에 대해 새 VPC가 생성됩니다. 이 조치는 간소화를 위한 것이며 확장성 및 아키텍처 요구 사항과 VMware Cloud Foundation의 원칙과 관련된 문제를 방지하기 위한 것입니다. 다른 워크로드 및 다른 VPC에 연결하려면 IBM Cloud와 같은 상호 연결 솔루션을 사용할 수 있습니다(예: Transit Gateway).

다음 표에는 VPC에서 생성되는 서브넷이 나열되어 있습니다. 서브넷 설계는 시스템 트래픽 유형을 논리적으로 분리하고 사용되는 각 사용자에 대한 전용 VPC 서브넷을 분리하는 VMware Cloud Foundation 요구 사항을 기반으로 합니다. 베어메탈 서버 PCI 인터페이스는 자체 서브넷에서 호스팅됩니다. VMware vCenter®, VMware NSX® 관리자, SDDC 관리자 및 NSX Edge™ 관리 인터페이스와 같은 관리 인터페이스 및 어플라이언스는 자체 관리 서브넷에서 프로비저닝됩니다.

시스템 트래픽 유형에 대한 VPC 서브넷
서브네트 이름	시스템 트래픽 유형	서브네트 크기 조정 안내
`vpc-host-subnet`	호스트 관리 트래픽	호스트 수 x 2(각 PCI NIC에는 IP 주소가 필요함)
`vpc-mgmt-subnet`	관리 어플라이언스 트래픽	VMware 클라우드 파운데이션 관리 어플라이언스 수
`vpc-vmot-subnet`	vMotion 트래픽	호스트 수
`vpc-vsan-subnet`	vSAN 트래픽	호스트 수
`vpc-tep-subnet`	호스트용 TEP 트래픽	호스트 수 x 2(각 호스트에 TEP 2개 필요)

NSX 엣지 TEP 트래픽 및 NSX Tier-0 논리적 게이트웨이 인터페이스는 자체 서브넷에 배포된 VMware Cloud Foundation 배포에서 배포됩니다. 에지 클러스터에는 다음 VPC 서브넷이 필요합니다.

NSX T0 업링크를 위한 VPC 서브넷
서브네트 이름	시스템 트래픽 유형	서브네트 크기 조정 안내
`vpc-edge-tep-subnet`	엣지 노드용 TEP 트래픽	엣지 노드 수 x 2(각 엣지 노드에 2 x TEP 필요)
`vpc-t0-public-uplink-subnet`	T0 공용 업링크 서브넷	`/29` 이상
`vpc-t0-private-uplink-subnet`	T0 사설 업링크 서브넷	`/29` 이상

VPC에 서브넷을 작성할 수 있으려면 VPC 접두부를 작성해야 합니다. VPC 접두사는 구역마다 정의됩니다. 라우팅을 단순화하려면 단일 접두사에서 권장 서브넷을 할당해야 합니다. 즉, 5개의 서브넷을 수용하려면 영역당 약 120개 호스트의 주소를 제공하기 위해 /21 접두사 하나가 필요합니다. /22와 함께 접두부를 사용하려면 구역당 약 60개의 호스트를 추가할 수 있습니다. 접두사를 충분히 크게 선택하면 NFS, 복제 및 NSX Tier-0 업링크를 위한 전용 VMK와 같은 확장성 및 향후 요구 사항을 위한 성장성을 확보할 수 있습니다.

VPC 액세스 제어 목록 및 보안 그룹

Bare Metal Servers for VPC는 VPC 네트워킹 기능에 대한 완전한 지원을 제공합니다. 보안 그룹 및 액세스 제어 목록과 같은 네트워크 보안 기능은 베어메탈 서버 PCI 및 VLAN 인터페이스와 함께 사용할 수 있습니다. 이 설계에서는 VMware 시스템 트래픽 유형을 전달하는 데 사용되는 VMware 인프라 서브넷과 워크로드 VM을 위한 VPC 서브넷이 모두 라우팅 도메인을 공유합니다. 이 설계를 통해 이 두 가지 기본 제공 네트워크 VPC 보안 도구를 사용할 수 있습니다.

VMware 워크로드가 있는 액세스 제어 목록

서브넷의 인바운드 및 아웃바운드 트래픽을 허용하거나 거부하여 액세스 제어 목록을 관리할 수 있습니다. ACL은 Stateless이며, 이는 인바운드 및 아웃바운드 규칙을 개별적으로 및 명시적으로 지정해야 함을 의미합니다. 각 ACL은 소스 IP, 소스 포트, 목적지 IP, 목적지 포트 및 프로토콜을 기반으로 하는 규칙들로 구성됩니다. 모든 VPC에는 모든 인바운드 및 아웃바운드 트래픽을 허용하는 기본 ACL이 포함되어 있습니다. 기본 ACL 규칙을 편집하거나 사용자 정의 ACL을 작성할 수 있습니다.

ACL은 서브넷에 적용되므로 이를 가상 서버로 사용하여 VPC 서브넷과 주고받는 트래픽을 제어할 수 있습니다. 또한 분리된 서브넷(예: vSAN™, vMotion 및 TEP 트래픽)을 작성할 수 있습니다.

기본 배포는 전체 VPC에 대해 기본 ACL(allow any)을 사용하지만 초기 배포 후 이를 사용자 지정할 수 있습니다.

ACL에 대한 자세한 정보는 VPC에서의 보안의 내용을 참조하십시오. IBM Cloud 베어메탈 서버의 ACL에 대한 자세한 정보는 IBM Cloud 베어메탈 서버 네트워킹 소개의 내용을 참조하십시오.

VMware 워크로드가 있는 보안 그룹

보안 그룹은 하나 이상의 가상 서버 네트워크 인터페이스 및 IBM Cloud 베어메탈 서버 PCI 또는 VLAN 인터페이스의 트래픽을 제어하는 가상 방화벽으로 작동합니다. 보안 그룹은 연관된 인터페이스의 트래픽을 허용할지 또는 거부할지 여부를 지정하는 규칙 콜렉션입니다. 인터페이스를 하나 이상의 보안 그룹과 연관시키고 보안 그룹 규칙을 편집할 수 있습니다. 또한 보안 그룹을 규칙에서 소스 또는 대상으로 사용하여 IP 주소를 지정하지 않고 보다 동적인 규칙을 작성할 수도 있습니다.

이 설계에서는 보안 그룹을 사용하여 관리, vSAN, vMotion 및 TEP 트래픽 유형을 논리적으로 그룹화하고 필요한 트래픽 흐름을 허용하는 규칙을 적용합니다. 다음과 같은 보안 그룹이 만들어집니다:

VPC 보안 그룹
보안 그룹 이름	사용량
`sg-mgmt`	관리 어플라이언스 및 호스트
`sg-vmot`	vMotion용 VMkernel 어댑터
`sg-vsan`	vSAN용 VMkernel 어댑터
`sg-tep`	TEP용 VM커널 어댑터
`sg-uplink-pub`	Tier-0 공용 업링크를 위한 VMkernel 어댑터
`sg-uplink-priv`	Tier-0 프라이빗 업링크를 위한 VMkernel 어댑터
`sg-bastion`	바스티온 호스트용 VMkernel 어댑터(자동화 VSI)

기본 규칙의 기본 원칙은 실질적인 최소한의 허용입니다. 예를 들어 sg-vmot 은 보안 그룹 멤버와 보안 그룹 sg-mgmt 의 인바운드 icmp 간의 트래픽을 허용합니다. VMkernel 어댑터에 사용되는 모든 보안 그룹에 동일한 원칙이 적용됩니다. sg-mgmt 는 사설 RFC 1918 네트워크에서 연결을 허용합니다. 이러한 규칙은 초기 프로비저닝 후 사용자 지정할 수 있으며 다음 정보는 간단한 지침과 원칙을 제공합니다.

보안 그룹을 VMware 가상 머신(VM)의 VLAN 인터페이스와 함께 사용하는 경우, 잘못된 구성과 오해를 피하려면 표준 및 분산 vSwitches, 과 트래픽이 어떻게 오가는지, 트래픽이 이러한 vSwitches 호스트 내부를 통과하는지를 이해하는 것이 중요합니다.

VMware 환경에서 동일한 베어메탈 서버에서 동일한 VLAN ID를 가진 VLAN 네트워크 인터페이스 간의 트래픽은 일반적으로 ESXi 호스트 내의 vSwitches 에서 포워딩합니다. 가상 머신 또는 VM커널 인터페이스가 동일한 호스트에 있고 동일한 포트 그룹 및 VLAN ID를 사용하는 경우 트래픽이 VPC 네트워크에 도달하지 않습니다.

예를 들어, 여러 베어 메탈 서버 호스트로 구성된 VMware vSphere® 클러스터에서 분산된 vSwitch를 구성할 수 있습니다. 이 경우 VLAN ID가 1611 인 포트 그룹을 생성하여 특정 vSwitch 에 추가할 수 있습니다. 포트 그룹 1611에 연결된 두 VM의 vNIC 사이의 트래픽은 vSwitch에서 제어합니다.

이 예제에서는 VMware Cloud Foundation 배포에서 다음과 같은 결과가 발생합니다:

포트 그룹 VLAN ID 1611 의 네트워크 인터페이스 간 트래픽을 제어하는 보안 그룹 규칙은 트래픽이 vSwitch를 벗어나지 않는 경우 적용되지 않습니다.

또한 NSX Tier 0 게이트웨이 업링크 및 NSX 오버레이 트래픽에 적용되는 보안 그룹으로 작업하는 경우, 예를 들어 IP 주소를 기반으로 규칙을 정의해야 합니다:

VPC 서브넷의 VMware VM(또는 VSI)에서 IP 주소가 192.168.45.10 인 NSX 오버레이의 VM에 액세스하고 이 IP 주소로 트래픽을 허용하려는 경우 소스 보안 그룹 규칙이 나가는 트래픽과 일치해야 하며, 티어 0 게이트웨이 업링크에 할당되는 보안 그룹이 인바운드에서 이 규칙과 일치해야 합니다. 이 경우 오버레이 트래픽을 일치시키기 위해 IP 주소 또는 CIDR을 사용해야 합니다.
IP 주소가 192.168.45.10 인 NSX 오버레이의 VM이 vCenter 또는 SDDC 관리자와 통신해야 하는 경우 계층 0 게이트웨이 업링크 보안 그룹 규칙은 나가는 트래픽과 일치해야 하며 vCenter 또는 SDDC 관리자 VLAN 인터페이스에 할당되는 보안 그룹은 인바운드에서 이 규칙과 일치해야 합니다. 이 경우 오버레이 트래픽을 일치시키기 위해 IP 주소 또는 CIDR을 사용해야 합니다.

보안 그룹에 대한 자세한 정보는 VPC에서의 보안의 내용을 참조하십시오. IBM Cloud 베어메탈 서버의 보안 그룹에 대한 자세한 정보는 IBM Cloud 베어메탈 서버 네트워킹 소개의 내용을 참조하십시오.

VPC 서브넷에서 VMware VM과의 공용 연결

Bare Metal Server for VPC는 VPC 공용 네트워킹 기능에 대한 전체 지원을 제공합니다. 외부 연결은 VPC 서브넷에 연결된 Public Gateway 또는 베어메탈 서버의 PCI 또는 VLAN 인터페이스에 연결된 플로팅 IP 주소를 사용하여 이루어질 수 있습니다. 공용 게이트웨이는 소스 네트워크 주소 변환(SNAT)을 사용하고 플로팅 IP는 대상 네트워크 주소 변환(DNAT)을 사용합니다. 이러한 기능은 VPC 가상 서버와 동일합니다.

공용 게이트웨이가 있는 VPC 서브넷에 연결된 VLAN 인터페이스는 인터넷에 대한 연결을 시작할 수 있지만 인터넷에서 연결을 수신할 수 없습니다. 공용 게이트웨이는 전체 서브넷에 대한 연결을 제공하고, 이 서브넷의 VM 에서 시작하는 공용 트래픽은 공용 게이트웨이 IP 주소를 소스로 간주합니다. 서브넷이 공용 게이트웨이에 접속되지 않은 경우 트래픽은 완전히 사설입니다. 이 설계에서 vSAN, vMotion 또는 TEP 서브넷이 예가 될 수 있습니다.

부동 IP를 갖는 VLAN 인터페이스는 인터넷으로 또는 인터넷으로부터의 연결을 개시하거나 수신할 수 있습니다. 부동 IP는 단일 인스턴스에 대한 연결을 제공합니다. 이 작업은 Public Gateway 이 첨부된 서브넷에 프로비저닝된 경우 VPC 서브넷에서 해당 특정 VLAN 인터페이스의 Public Gateway 을 재정의합니다.

VMware Cloud Foundation 배포에서는 관리 서브넷을 Public Gateway에 추가해야 하며, 이를 통해 예를 들어 SDDC 관리자가 VMware 공용 소프트웨어 리포지토리에서 직접 업데이트할 수 있도록 해야 합니다.