Casos de uso de red
IBM Power Virtual Server Nube privada en Ubicación del cliente
Revise los casos de uso de red comunes dentro de la arquitectura de red de IBM® Power® Virtual Server.
Caso de uso 1: Red privada dentro de un pod
Con este caso de uso, puede establecer una red privada dentro de un pod que permita la comunicación entre las aplicaciones que se encuentran en el pod. Puede establecer una red privada dentro del pod utilizando el método de asignación de direcciones IP, Classless Inter-Domain Routing (CIDR).
Puede desplegar máquinas virtuales en un pod que tenga una configuración predeterminada utilizando uno de los patrones siguientes:
- Afinidad: en este patrón, las máquinas virtuales se despliegan en el mismo host físico. Por lo tanto, las máquinas virtuales pueden comunicarse entre sí en el mismo host a través del conmutador Ethernet conectado.
- Antiafinidad: en este patrón, las máquinas virtuales se despliegan en distintos hosts físicos. Se necesita una configuración personalizada en el conmutador Ethernet conectado externamente para habilitar la comunicación entre máquinas virtuales desplegadas en distintos hosts físicos.
Ejemplo
Tiene un servidor de bases de datos y un servidor web que necesitan comunicarse exclusivamente entre sí. Puede conectar ambos servidores a la misma red privada para habilitar la comunicación entre ellos.
La figura 1 describe la red privada dentro de un tipo de pod de configuración de red.
Caso 2: Múltiples conexiones externas
Con este caso de uso, puede acceder a la conectividad externa hacia y desde las máquinas virtuales de una subred. También puede establecer una conectividad de red sólo saliente mediante la configuración dinámica de la puerta de enlace de traducción de direcciones de red (NAT).
Para acceder a la conectividad externa, debe crear interfaces pares y establecer una subred externa en un espacio de trabajo. Las máquinas virtuales desplegadas en el espacio de trabajo pueden acceder al entorno externo.
Para acceder a la conectividad externa, siga estos pasos:
Paso 1: Crear una interfaz paritaria
Para crear una interfaz par, siga estos pasos:
-
Crear un espacio de trabajo.
-
Abra un ticket de soporte para crear una interfaz paritaria. El equipo de soporte configura una interfaz paritaria con una de las siguientes combinaciones:
- Capa 2
- Capa 2 y Capa 3 con ruta BGP
- Capa 2 y Capa 3 con ruta estática
- Ruta BGP de capa 3
- Ruta estática de capa 3
La combinación de interfaces pares se basa en el tipo de cableado de red de datos de su infraestructura. Si necesita una combinación específica de interfaz de pares, debe especificar la combinación en el ticket.
Paso 2: Crear una subred externa
Para crear una subred externa, utilice una de las interfaces pares configuradas en Step 1. Opcionalmente, si elige la configuración NAT para la red externa de Capa 3 (BGP o estática), debe proporcionar la dirección
IP de origen NAT. La dirección IP de origen se utiliza en su cortafuegos para permitir el tráfico. Para redes externas de Capa 2, la configuración NAT no es aplicable.
Para crear una subred externa, seleccione una de las siguientes opciones para permitir la configuración de la puerta de enlace NAT:
- Sólo Border Gateway Protocol (BGP): Puede utilizar BGP con o sin configuración de pasarela NAT. Debe proporcionar la dirección IP de origen y utilizar la misma dirección IP en su cortafuegos para permitir el tráfico. Para obtener más información sobre el caso de uso de BGP con NAT activado, consulte Outbound-only. Para obtener más información sobre el caso de uso de BGP sin NAT activado, consulte Conectividad externa bidireccional a través de BGP.
- Sólo estático: Puede utilizar enrutamiento estático con o sin configuración de pasarela NAT. Debe proporcionar la dirección IP de origen y utilizar la misma dirección IP en su cortafuegos para permitir el tráfico. Para obtener más información sobre el caso de uso de la ruta estática con NAT activado, consulte Sólo salida. Para obtener más información sobre el caso de uso de rutas estáticas sin NAT activado, consulte Conectividad externa bidireccional a través de rutas estáticas.
La configuración de la pasarela NAT no está disponible con las rutas L2. Para más información, consulte Conectividad externa bidireccional - Capa 2.
Paso 3: Despliegue de máquinas virtuales para acceder a la conectividad externa
Para configurar su espacio de trabajo, abra un ticket de soporte.
Puede desplegar máquinas virtuales en su espacio de trabajo después de recibir la confirmación del equipo de soporte sobre la finalización de la configuración de su espacio de trabajo. Las máquinas virtuales pueden acceder al entorno externo
utilizando rutas BGP con NAT habilitado o rutas estáticas con NAT habilitado que haya seleccionado en Step 2. Para obtener más información sobre la configuración de las máquinas virtuales en su espacio de trabajo, consulte
Configuración de una instancia de Power Virtual Server.
Sólo salidas
Los casos de uso de outbount-only sólo son aplicables con una configuración de pasarela NAT emparejada con BGP o rutas estáticas. Para más información, consulte Conectividad externa múltiple.
Con este caso de uso, puede establecer una red privada que permita la comunicación entre aplicaciones dentro del pod y con puntos de destino externos. Sin embargo, las aplicaciones dentro del pod no son accesibles desde los puntos de destino en la red externa. Puede establecer una conectividad de red sólo saliente a través de la configuración dinámica de la puerta de enlace NAT, asemejándose a una red establecida mediante el uso de routers.
Ejemplo
Una máquina virtual dentro de un pod descarga y despliega software de Internet.
Puede especificar el tipo de red solo de salida cuando defina los requisitos de red antes de la instalación del pod. Para obtener más información, consulte Requisito de red. Después de la instalación del pod, puede configurar el tipo de red sólo de salida utilizando el sistema de incidencias del Centro de soporte. Para obtener más información, consulte la sección Obtención de soporte.
La figura 2 describe el tipo de configuración de red sólo de salida. ![Tipo de red sólo de salida*Tipo de red sólo](./figures/outbound-ext-conn-dnat.png "" caption-side="bottom"} de red sólo de "){: caption="
Conectividad externa bidireccional a través de BGP
Con este caso de uso, puede establecer una red que permita la comunicación entre las aplicaciones dentro del pod y con los puntos de destino en la red externa. Al configurar las reglas de cortafuegos de capa 3, puede permitir tanto conexiones de entrada como de salida. Configure manualmente el BGP entre el pod router y la red corporativa. Utilizando la configuración de BGP, establezca una conexión entre la red privada y la red corporativa. Para configurar BGP manualmente, póngase en contacto con el Centro de soporte. Para obtener más información, consulte la sección Obtención de soporte.
Ejemplo
Tiene un servidor de bases de datos que se ejecuta dentro del pod. Debe acceder al servidor de bases de datos desde otra aplicación que resida fuera del pod pero dentro de la red corporativa. Acceso de entrada de capa 3, puede direccionar el tráfico y aplicar el cortafuegos corporativo o las reglas de direccionamiento para acceder al servidor de bases de datos. La red corporativa puede acceder a las subredes de pod utilizando una conexión BGP.
La figura 3 describe la conectividad externa bidireccional a través del tipo BGP de configuración de red.
Conectividad externa bidireccional mediante rutas estáticas
Con este caso de uso, puede establecer una red que permita la comunicación entre aplicaciones dentro del pod y con puntos de destino en la red externa. Reglas de cortafuegos de capa 3, puede permitir conexiones de entrada y salida. Establezca una ruta estática entre los direccionadores periféricos que están dentro del pod y al direccionador de salto siguiente que está dentro de la red corporativa. La ruta estática establece una conexión entre la subred de pod y la red corporativa. Para establecer manualmente la conectividad de ruta estática, póngase en contacto con el centro de soporte. Para obtener más información, consulte la sección Obtención de soporte.
Ejemplo
Tiene un servidor de bases de datos que se ejecuta dentro del pod. Debe acceder al servidor de bases de datos desde otra aplicación que resida fuera del pod pero dentro de la red corporativa. Acceso de entrada de capa 3, puede direccionar el tráfico y aplicar el cortafuegos corporativo o las reglas de direccionamiento para acceder al servidor de bases de datos. La red corporativa puede acceder a las subredes de pod a través de una conexión de ruta estática.
La figura 4 describe la conectividad externa bidireccional a través de rutas estáticas tipo de configuración de red.
Conectividad externa bidireccional - Capa 2
Con este caso de uso, puede crear una red que permita la comunicación entre aplicaciones dentro del pod y con puntos de destino en la red externa. Integre un cortafuegos de capa 2 con una de las redes corporativas existentes para permitir las conexiones de salida. En este tipo de red, la conectividad externa bidireccional evita el router y se conecta al tejido de red IBM Power Virtual Server. Puede establecer este tipo de conectividad cuando desee el mismo espacio de direcciones IP en redes internas y externas. Todas las demás redes externas implican dos subredes distintas.
La Figura 5 describe la conectividad externa bidireccional utilizando una configuración de red de tipo cortafuegos de Capa 2.
Caso práctico 3: Conectividad de red para la suscripción completa a Linux
Con este caso de uso, puede establecer una red entre una máquina virtual en el pod y el servidor Red Hat Satellite en IBM Cloud. La máquina virtual tiene la imagen en stock de Red Hat Enterprise Linux (RHEL) con la suscripción completa de Linux.
Conecte la máquina virtual en el pod a una red de proxy en el entorno de red corporativo. Conecte la red de proxy al servidor Red Hat Satellite en IBM Cloud utilizando Direct Link o una conexión VPN. La máquina virtual del pod puede acceder al servidor satélite Linux® para recuperar arreglos de software y otros artefactos.
La conectividad de red para la suscripción completa a Linux puede establecerse proporcionando los requisitos de red antes de la instalación del pod. Para obtener más información, consulte Requisito de red. Una vez instalado el pod, puede configurar la conectividad de red para la suscripción completa de Linux utilizando el sistema de incidencias del Centro de soporte. Para obtener más información sobre la suscripción completa de Linux, consulte Suscripción completa de Linux para Power Virtual Server Private Cloud. Para obtener más información sobre cómo ponerse en contacto con el Centro de soporte, consulte la sección Obtención de soporte.
La figura 6 describe la conectividad de red entre una máquina virtual y un servidor Red Hat Satellite en la configuración de IBM Cloud.
{: caption=" Linux completaConectividad de red para una " caption-side="bottom"} Linux completa
Caso práctico 4: Red DHCP dentro del módulo
Con este caso de uso, puede utilizar el protocolo DHCP (Dynamic Host Configuration Protocol) dentro del pod para asignar dinámicamente una dirección IP a una máquina virtual.
La presencia de la red DHCP dentro del pod es obligatoria cuando se utiliza OpenShift Container Platform en el entorno IBM Power Virtual Server Nube privada en la ubicación del cliente. La red DHCP está diseñada para su uso exclusivo en la OpenShift Container Platform.
IBM Power Virtual Server Nube privada en los pods de ubicación de clientes pueden configurarse para incluir una red DHCP privada y basada en hardware. El direccionador periférico dentro del pod se configura con la agrupación DHCP y la pasarela. Puede desplegar máquinas virtuales en la red DHCP. A las máquinas virtuales se les asignan direcciones IP del servidor DHCP.
Sólo puede conectar una tarjeta de interfaz de red (NIC) DHCP a una máquina virtual. Si conecta más de un NIC DHCP a una máquina virtual, sólo un NIC adquiere la dirección IP del servidor DHCP que está asignado a la máquina virtual.
Cuando cree una red DHCP, tenga en cuenta que las cuatro primeras direcciones IP están reservadas. Debe configurar una red que tenga más de cuatro direcciones IP. Por ejemplo, si la máscara de subred es 255.255.255.248, el número total de direcciones IP es ocho. No puede crear una red con una máscara de subred más allá de 255.255.255.248 porque tiene menos o igual que cinco direcciones IP.