Diseño de redes VPC

La siguiente información proporciona una descripción general de la implementación de IBM Cloud® Virtual Private Cloud para una implementación de VMware®. Es importante entender la separación e integración de VMware con VPC, sus requisitos cómo integrar y configurar la conectividad con otro tráfico de carga de trabajo.

Subredes de VPC

IBM Cloud VPC, puede realizar la segmentación lógica o el aislamiento de múltiples maneras. Esta arquitectura utiliza una analogía de segmentación VLAN tradicional siguiendo los requisitos de VMware Cloud Foundation™, pero IBM Cloud VPC utiliza subredes en lugar de VLAN. Cada tipo de tráfico del sistema tiene su propia subred VPC, y el tráfico entre las interfaces de red del adaptador VMkernel se puede controlar tanto con IBM Cloud VPC grupos de seguridad (SG) como con listas de control de acceso (ACL) de subred. El siguiente diagrama muestra una visión general del diseño de la VPC consolidada.

VPC design for consolidated VMware Cloud Foundation deployment — VPC network design for consolidated VMware Cloud Foundation deployment

Para esta arquitectura, se crea una nueva VPC para cada instancia de VMware Cloud Foundation. Esta acción es por simplicidad y para evitar problemas con la escalabilidad y los requisitos y principios arquitectónicos de VMware Cloud Foundation. Para conectarse a otras cargas de trabajo y otras VPC, puede utilizar IBM Cloud soluciones de interconectividad, como Transit Gateway.

La siguiente tabla enumera las subredes que se crean en VPC. El diseño de la subred se basa en el requisito de Cloud Foundation de VMware, que consiste en separar lógicamente los tipos de tráfico del sistema y en utilizar una subred VPC dedicada para cada usuario. Las interfaces PCI de los servidores bare metal se alojan en su propia subred. Las interfaces y dispositivos de gestión, como VMware vCenter®, VMware, el gestor SDDC y las interfaces de gestión NSX Edge™ se aprovisionan en su propia subred de gestión.

Subredes VPC para tipos de tráfico del sistema
Nombre de subred	Tipo de tráfico del sistema	Guía de dimensionamiento de subred
`vpc-host-subnet`	Tráfico de gestión de host	Número de hosts x 2 (cada PCI NIC requiere una dirección IP)
`vpc-mgmt-subnet`	Tráfico de dispositivos de gestión	Número de dispositivos de gestión de VMware Cloud Foundation
`vpc-vmot-subnet`	Tráfico de vMotion	Número de hosts
`vpc-vsan-subnet`	Tráfico de vSAN	Número de hosts
`vpc-tep-subnet`	Tráfico TEP para hosts	Número de hosts x 2 (cada host requiere 2 x TEP)

El tráfico TEP de NSX Edge y las interfaces de puerta de enlace lógica NSX Tier-0 se implementan en sus propias subredes en las implementaciones de VMware Cloud Foundation. Las siguientes subredes VPC son necesarias para el clúster de borde.

Subredes VPC para enlaces ascendentes NSX T0
Nombre de subred	Tipo de tráfico del sistema	Guía de dimensionamiento de subred
`vpc-edge-tep-subnet`	Tráfico TEP para nodos periféricos	Número de nodos de borde x 2 (cada nodo de borde requiere 2 x TEP)
`vpc-t0-public-uplink-subnet`	Subred de enlace ascendente público T0	`/29` o más grande
`vpc-t0-private-uplink-subnet`	Subred de enlace ascendente privada T0	`/29` o más grande

Para poder crear subredes en VPC, debe crear un prefijo VPC. Los prefijos de VPC se definen por zona. Para simplificar el enrutamiento, debe asignar las subredes recomendadas a partir de un único prefijo. Lo que significa que para dar cabida a cinco subredes, se necesita un prefijo /21 para atender direcciones de unos 120 hosts por zona. Si desea utilizar un prefijo con /22, puede añadir unos 60 hosts por zona. Al seleccionar un prefijo lo suficientemente grande, tendrá crecimiento para la escalabilidad y las necesidades futuras, como VMK dedicadas para NFS, replicación y enlaces ascendentes NSX Tier-0.

Listas de control de acceso y grupos de seguridad de la VPC

El servidor nativo para VPC proporciona soporte completo para las funciones de red de VPC. Las capacidades de seguridad de red, como los grupos de seguridad y las listas de control de acceso, se pueden utilizar con interfaces PCI y VLAN de servidor bare metal. En este diseño, tanto las subredes de infraestructura de nube privada ( VMware ), que se utilizan para transportar tipos de tráfico de sistema de nube privada ( VMware ), como las subredes de nube privada virtual (VPC) para cargas de trabajo de máquinas virtuales comparten el dominio de enrutamiento. Este diseño permite el uso de estas dos herramientas de seguridad VPC de red incorporadas.

Lista de control de acceso con cargas de trabajo de VMware

Una lista de control de acceso puede gestionar permitiendo o denegando el tráfico de entrada y salida para una subred. Una ACL no tiene estado, lo que significa que las reglas de entrada y salida deben especificarse de forma independiente y explícita. Cada ACL consta de reglas basadas en una IP de origen, puerto de origen, IP de destino, puerto de destino y protocolo. Cada VPC tiene una ACL predeterminada que permite todo el tráfico de entrada y de salida. Puede editar las reglas de ACL predeterminadas o crear una ACL personalizada.

Como las ACL se aplican a una subred, puede utilizarlas como servidores virtuales para controlar el tráfico hacia y desde las subredes de la VPC. Además, puede crear subredes aisladas, por ejemplo, para el tráfico de vSAN™, vMotion y TEP.

La implementación predeterminada utiliza una ACL predeterminada (allow any) para toda la VPC, pero puede personalizarla después de la implementación inicial.

Para obtener más información sobre las ACL, consulte Seguridad en VPC. Para obtener más información sobre las ACL con el servidor nativo de IBM Cloud, consulte Introducción a la red del servidor nativo de IBM Cloud.

Grupos de seguridad con cargas de trabajo VMware

Un grupo de seguridad actúa como un cortafuegos virtual que controla el tráfico de una o más interfaces de red de servidor virtual y de interfaces VLAN o PCI de servidor nativo de IBM Cloud. Un grupo de seguridad es una colección de reglas que especifican si se debe permitir o denegar el tráfico para una interfaz asociada. Puede asociar una interfaz con uno o más grupos de seguridad y editar las reglas del grupo de seguridad. También puede utilizar grupos de seguridad como origen o destino en las reglas para crear reglas más dinámicas sin especificar direcciones IP.

En este diseño, sus grupos de seguridad se utilizan para crear una agrupación lógica de los tipos de tráfico de gestión, vSAN, vMotion y TEP, y aplicar reglas para permitir los flujos de tráfico necesarios. Se crean los siguientes grupos de seguridad:

Grupos de seguridad de VPC
Nombre de grupo de seguridad	Uso
`sg-mgmt`	Dispositivos de gestión y hosts
`sg-vmot`	Adaptadores VMkernel para vMotion
`sg-vsan`	Adaptadores VMkernel para vSAN
`sg-tep`	Adaptadores VMkernel para TEP
`sg-uplink-pub`	Adaptadores VMkernel para Tier-0 uplinks públicos
`sg-uplink-priv`	Adaptadores VMkernel para enlaces ascendentes privados Tier-0
`sg-bastion`	Adaptadores VMkernel para hosts bastión (automatización VSI)

El principio básico de las normas por defecto es permitir un mínimo práctico. Por ejemplo, sg-vmot permite el tráfico entre los miembros del grupo de seguridad y la entrada icmp desde el grupo de seguridad sg-mgmt. El mismo principio se aplica a todos los grupos de seguridad utilizados para los adaptadores VMkernel. sg-mgmt permite la conectividad desde redes privadas RFC 1918. Estas normas pueden personalizarse tras la provisión inicial y la siguiente información ofrece orientaciones y principios simplificados.

Cuando se utilizan grupos de seguridad con interfaces VLAN en máquinas virtuales (VM) de ethernet virtual ( VMware ), para evitar configuraciones erróneas y malentendidos, es importante comprender cómo fluye el tráfico hacia y desde el ethernet virtual estándar y distribuido ( vSwitches, ) y cuándo atraviesa el tráfico dentro de los hosts dentro de estos ethernet virtuales ( vSwitches ).

En un entorno de virtualización de servidores ( VMware ), el tráfico entre interfaces de red VLAN con el mismo ID de VLAN en el mismo servidor bare metal suele ser reenviado por el controlador de dominio virtual ( vSwitches ) dentro del host ESXi. Si las máquinas virtuales o las interfaces VMkernel están en el mismo host y utilizan el mismo grupo de puertos e ID de VLAN, el tráfico no llega a la red VPC.

Por ejemplo, en un VMware vSphere® cluster que consta de varios hosts de servidor bare metal, se configura un vSwitch distribuido. En este caso, puede crear un grupo de puertos con el ID de VLAN 1611 y agregarlo al vSwitch específico. El tráfico entre las vNIC de dos máquinas virtuales conectadas al grupo de puertos 1611 está controlado por el vSwitch.

En este ejemplo, esto tiene las siguientes consecuencias en las implementaciones de VMware Cloud Foundation:

Las reglas del grupo de seguridad que controlan el tráfico entre las interfaces de red en Port Group VLAN ID 1611 no se aplican si el tráfico no sale del vSwitch.

Además, cuando trabaje con grupos de seguridad que se apliquen a enlaces ascendentes de puerta de enlace de nivel 0 de NSX y al tráfico de superposición de NSX, deberá definir reglas basadas en direcciones IP, por ejemplo:

Cuando se accede a una VM en una superposición de NSX con una dirección IP de 192.168.45.10 desde una VMware VM (o una VSI) en la subred de VPC y se desea permitir el tráfico a esta dirección IP, la regla del grupo de seguridad de origen debe coincidir con el tráfico saliente, y el grupo de seguridad que se asigna a los enlaces ascendentes de la puerta de enlace de nivel 0 debe coincidir con él en el entrante. En este caso, se debe utilizar una dirección IP o CIDR para que coincida con el tráfico superpuesto.
Cuando una máquina virtual de una superposición NSX con una dirección IP de 192.168.45.10 necesita comunicarse con un vCenter o SDDC manager, la regla de grupo de seguridad de enlaces ascendentes de puerta de enlace de nivel 0 debe coincidir con el tráfico saliente, y el grupo de seguridad que se asigna a la interfaz VLAN de vCenter o SDDC manager debe coincidir con este en la entrada. En este caso, se debe utilizar una dirección IP o CIDR para que coincida con el tráfico superpuesto.

Para obtener más información sobre los grupos de seguridad, consulte Seguridad en la VPC. Para obtener más información sobre los grupos de seguridad con el servidor nativo de IBM Cloud, consulte Introducción a la red del servidor nativo de IBM Cloud.

Conectividad pública con máquinas virtuales VMware en subred de VPC

El servidor nativo para VPC proporciona soporte completo para las funciones de red pública de VPC. La conectividad externa puede lograrse mediante el uso de una dirección de protocolo de Internet ( Public Gateway, IP) que esté conectada a una subred de red privada virtual (virtual private network, VPC), o mediante el uso de una dirección IP flotante que esté conectada a una interfaz PCI o VLAN de un servidor bare metal. La pasarela pública utiliza la traducción de direcciones de red de origen (SNAT) y una IP flotante utiliza la traducción de direcciones de red de destino (DNAT). Estas funciones son idénticas a las de los servidores virtuales VPC.

Las interfaces VLAN que están conectadas a una subred de VPC con una pasarela pública pueden iniciar conexiones a Internet, pero no pueden recibir conexiones desde Internet. La pasarela pública proporciona conectividad para toda una subred y el tráfico público que se origina en las máquinas virtuales de esta subred considera la dirección IP de la pasarela pública como el origen. Si la subred no está conectada a una pasarela pública, el tráfico es totalmente privado. En este diseño, las subredes vSAN, vMotion o TEP pueden ser ejemplos.

Una interfaz VLAN con una IP flotante puede iniciar o recibir conexiones a o desde Internet. La IP flotante proporciona conectividad para una sola instancia. Esta acción anula el Public Gateway de esa interfaz VLAN específica en la subred VPC, si está aprovisionada para una subred con Public Gateway adjunto.

En los despliegues de VMware Cloud Foundation, debe añadir una subred de gestión a una Public Gateway, lo que permite, por ejemplo, que el gestor SDDC se actualice directamente desde VMware repositorios de software públicos.