IBM Cloud Docs
Consideraciones sobre diseño de redes

Consideraciones sobre diseño de redes

Los sistemas SAP en un entorno tienen requisitos específicos en cuanto a servidores, sistemas operativos, configuración de red y almacenamiento soportado.

En algunos aspectos, las cargas de trabajo de SAP que utilizan una infraestructura como servicio de proveedor de servicios de nube (por ejemplo, IBM Cloud® for SAP) se parecen a las prácticas existentes (durante muchas décadas) para ejecutar cargas de trabajo de SAP que utilizan un centro de datos externo o un proveedor de centros de datos. Un entorno SAP tiene requisitos específicos con respecto a la conectividad, entre hosts dentro de Cloud IaaS y con sistemas externos, e IBM Cloud® for SAP proporciona un amplio conjunto de funciones más allá del alojamiento de sistemas SAP para mejorar el entorno de SAP.

Para ayudarle en la fase de planificación de su proyecto, en las secciones siguientes se proporcionan consideraciones sobre el diseño del portfolio de IBM Cloud® for SAP para Redes.

Prefacio: unidades de medida de datos/información

Generalmente el rendimiento del almacenamiento de red se muestra en Mbps o en Gbps.

Es importante tener en cuenta que Mb (Megabits) es un prefijo decimal y MiB (Mebibyte) es un prefijo binario, por lo que están en diferentes escalas. Esto es aún más confuso si se tiene en cuenta que MiB (Mebibyte) se utilizaba generalmente en Microsoft Windows como Megabyte.

En las futuras referencias al rendimiento, en la documentación sobre redes se utiliza Mb (Megabits) y MiB (Mebibyte) basándose en el sistema de unidades (SI) definido por IEC y adoptado por IEEE, ISO y NIST.

Por ejemplo:

  • 100 Mbps (Megabits por segundo) serían 12 MiB/s (Mebibyte por segundo)
  • 1000 Mbps (Megabits por segundo), también llamado 1 Gbps (Gigabits por segundo), serían 120 MiB/s (Mebibyte por segundo)
  • 10 Gbps (Gigabits por segundo) serían 1200 MiB/s (Mebibyte por segundo)

Consideraciones sobre la conectividad de red

Para obtener una visión general de las opciones de conectividad disponibles, consulte Determinación del acceso al entorno del sistema SAP.

Los sistemas SAP suelen ser el punto focal de las operaciones empresariales, con un gran número de aplicaciones integradas (incluidas aplicaciones antiguas).

En la mayoría de las circunstancias para las cargas de trabajo de SAP, es necesaria una conexión con la red interna existente y se recomienda utilizar IBM Cloud® Direct Link 2.0 para aprovechar la seguridad, la baja latencia y el alto rendimiento (disponible hasta 10 Gbps) de una conexión como Routed OSI Layer-2/3.

Estas opciones de conectividad dependen de los requisitos empresariales, por ejemplo si el negocio desea utilizar la nube y también reducir el riesgo de seguridad mediante el aislamiento de los flujos de red a través de su estructura de red y seguridad existentes. En estos diseños de conectividad "desconectados" o "solo privados", lo mejor es solicitar a IBM Cloud® información adicional y discutir los casos de uso.

Además, SAP insiste en no recomendar que se dividan las capas del sistema SAP entre ubicaciones locales y ubicaciones en la nube y depende de la empresa la evaluación de este tema; por ejemplo, SAP no recomienda mantener la ejecución de SAP AnyDB de la infraestructura en una ubicación local y conectar con la ejecución de SAP NetWeater desde la infraestructura en una ubicación en la nube. Para los sistemas IBM Power Virtual Server, esta división de las capas de SAP System no recibe soporte.

Traer su propia red (subred/CIDR/Rango direcciones IP)

Muchas empresas prefieren traer su propia subred/CIDR/Rango de direcciones IP (BYOIP) en la cuenta de IBM Cloud; esto está disponible en función de la selección de la infraestructura y del entorno.

Infraestructura de VPC

Si se utiliza la infraestructura VPC, se puede definir y utilizar la propia subred. Consulte VPC - Traer su propia subred.

Esto cambia dependiendo de si se utilizan los espacios de direcciones de red privada reservados por la IANA ( IPv4 ) RFC 1918, ya que cualquier dirección IP dentro de estos rangos se considera no enrutable. Estas direcciones no son exclusivas en Internet ya que podrían ser utilizadas por cualquier red privada sin coordinación con IANA o un registro de Internet, por lo que estas direcciones solo son exclusivas dentro de una red privada. Estos espacios de direcciones de red privada IPv4 son:

  • Clase A - 10.0.0.0/8
  • Clase B - 172.16.0.0/12
  • Clase C - 192.168.0.0/16

Si utiliza un rango de subred propia que se define en los espacios de direcciones de red privada reservados por la IANA ( IPv4 ) RFC 1918, entonces la conectividad a una red interna existente es posible cuando se utilizan funciones VPC (por ejemplo, Public Gateway o IP flotantes).

No se admite el uso de un rango de subred propia no definido en los espacios de direcciones de red privada reservados por la IANA ( IPv4 ) del RFC 1918, ya que esto no permitiría la conectividad a una red interna existente cuando se utiliza con un PGW ( Public Gateway ) e IP flotantes.

Infraestructura clásica con VMware

Si el negocio existente utiliza SAP en VMware, se puede utilizar IBM Cloud para VMware junto con VMware HCX y IBM Cloud® Direct Link para crear una red bidireccional con puente entre el centro de datos existente con VMware e IBM Cloud para VMware. Esto utiliza el direccionamiento de red del servicio de VMware existente en VMware HCX y en superposición con respecto a VMWare NSX en IBM Cloud para VMware, lo cual que crea:

  • Un túnel de migración cifrado que utiliza HCX Cloud Gateway (CGW) + HCX WAN Optimizer (WAN-OPT)
  • Un túnel de aplicación cifrado que utiliza el concentrador HCX High Throughput Layer 2 (HT L2C)

Encontrará más información en Visión general de IBM Cloud for VMware Solutions - VMware HCX.

Consideraciones sobre la topología de red

Dependiendo del número y de la configuración de sistemas SAP que se combinan con la disposición de los flujos de red entre estos sistemas por razones de seguridad o rendimiento, la topología de red será significativamente diferente. El diseño de esta topología refleja los requisitos de empresa en cuanto a seguridad, rendimiento, coste, flexibilidad y conectividad.

Mediante la aplicación empresarial Enterprise Resource Planning (ERP), por ejemplo, un sistema SAP que aloja la instancia de producción que utiliza el enfoque de niveles de sistema SAP con alta disponibilidad de SAP NetWeaver y SAP HANA:

  • SAP NetWeaver, hay al menos cuatro hosts en lugar de 1:

    • Servicios centrales (ASCS)
    • Servidor de aplicaciones principal (PAS), también conocido como Instancia central (CI)
    • Instancia del servidor de réplica de puesta en cola (ERS)
    • Servidor de aplicaciones adicional (AAS)
  • SAP HANA, hay al menos 2 hosts (posiblemente 3) en lugar de 1:

    • Nodo principal de SAP HANA (mediante SAP HANA System Replication)
    • Nodo de migración tras error secundario de SAP HANA (mediante SAP HANA System Replication)
    • Nodo de migración tras error terciario de SAP HANA (mediante SAP HANA System Replication)
  • A continuación se describe 1 sistema SAP dentro del entorno SAP. Un entorno SAP puede utilizar:

    • Una pista, 5 sistemas SAP (Recinto de pruebas > Desarrollo > Pruebas > Transferencia > Producción)
    • Doble Pista, 5 Sistemas SAP (Recinto de pruebas > Desarrollo de nuevas características + Desarrollo del mantenimiento > Pruebas de nuevas características + Pruebas del mantenimiento > Transferencia > Producción)

Por lo tanto, para un entorno SAP se pueden necesitar entre 30 y 50 instancias de SAP, distribuidas entre 10-50 servidores de host (físicos o virtualizados). Esto es antes de que se añadan más aplicaciones empresariales para operaciones de negocio, industria o funciones geográficas específicas.

El tamaño de los entornos de SAP tiene un impacto directo en la topología de red.

Normalmente, aunque esto varía entre caso y caso, se necesitan las siguientes redes para satisfacer los escenarios y el rendimiento que necesita la empresa que utiliza SAP Business Applications:

  • Red interna para la comunicación entre varias instancias en un entorno SAP con diferentes enfoques de niveles de sistema SAP
  • Red para las transferencias de gestión y almacenamiento de sistemas de base de datos
  • Red que se utiliza en producción

Sin embargo, en el escenario más sencillo podría haber una red privada para todo. Depende de los requisitos de la empresa.

Sistemas de gestión adicionales para habilitar sistemas SAP

En función del sistema operativo, de la carga de trabajo de SAP y de la conectividad de red, es posible que tenga que configurar el acceso a muchos más sistemas SAP y no SAP. A continuación se muestra una lista de diversos sistemas de gestión que las cargas de trabajo de SAP pueden requerir para operar:

  • Servidor de actualización de paquetes de sistema operativo, con los distintos canales de suscripción de los paquetes de sistema operativo para SAP HANA y SAP NetWeaver.
    • Para sistemas IBM Power Virtual Server, puede utilizar repositorios de actualización de AIX SUMA o SUSE disponibles públicamente, o puede utilizar sus propios servidores AIX NIM o SUSE RMT.
  • Servidor de descarga de software y parches. Cuando descarga el software en el servidor, puede utilizar diversos protocolos para transferir los archivos como SCP o SFTP para transferir el software al servidor de destino para su instalación.
  • Servidor de hora (NTP), que utiliza NTP en la red troncal privada de IBM Cloud, NTP de Internet público o host NTP privado.
  • Hosts de pasarela (y proxy) y cortafuegos
  • Host bastión/administrativo. Habilita el paso a través seguro a los recursos de la nube desde Internet público u otro acceso de red; generalmente utiliza SSH estrechamente protegido en un puerto no predeterminado.
  • Host administrativo que se habilita con VNC o RDP. Permite el acceso de la GUI a una máquina de destino (si la GUI y VNC o RDP están instalados en el destino).
  • Hosts VPN. Permite la conexión protegida a la red interna existente.
  • Hosts de direccionamiento de red, a través de TelCo o proveedor de servicios de red. Permite la conexión privada de alto rendimiento segura a la red interna existente.
  • Host del servicio de gestión de copia de seguridad
  • Almacenamiento de archivos de red, a través del sistema de archivos de red (por ejemplo, NFSv3 o NFSv4.1). Ejecuta mandatos del sistema de archivos encapsulados por paquetes TCP/IP.
  • Almacenamiento en bloque de red, que utiliza el protocolo iSCSI controlado por MPIO. Ejecuta mandatos SCSI encapsulados por paquetes TCP/IP.
  • Almacenamiento en bloque de red, que utiliza el protocolo Fibre Channel (FC). Ejecuta mandatos SCSI encapsulados por tramas FC.

Fibre Channel solo se necesita para sistemas IBM Power Virtual Server y se gestiona automáticamente durante el suministro.

Configuración de nube híbrida para SAP

A continuación se indican los elementos de configuración específicos que necesita tener en cuenta al planificar el entorno SAP, mediante los sistemas de soporte de SAP existentes locales en combinación con el porfolio de IBM Cloud® for SAP para crear una configuración de nube híbrida:

  • SAP Transport Management System (STMS, también llamado TMS) . Configure STMS sobre en base a los Grupos de transporte para impedir el uso compartido de archivos entre centros de datos.
  • SAProuter. Proporciona acceso a SAP Online Service System (OSS). Utilice SAProuter en local para acceder a OSS. Este SAProuter se puede utilizar a través de saltos de SAProuter si no se permite el direccionamiento basado en IP entre sus sistemas basados en IBM Cloud y SAProuter en local. Como alternativa, puede configurar otro SAProuter que se basa en un servidor basado en IBM Cloud con una IP pública y conectarlo al sistema SAP OSS a través de Internet.
  • SAP Solution Manager. El acceso a SAP Solution Manager tiene varios requisitos de conectividad entre SAP Solution Manager y sus sistemas gestionados. Las diferencias dependen del caso de uso. Estos casos de uso requieren saber la conectividad de red necesaria.
  • Si va a desplegar pasarelas públicas o IP flotantes, debe examinar los detalles de la conversión de direcciones de red (NAT) y el comportamiento de las aplicaciones SAP. Consulte el documento NAT(SAP ) para considerar posibles problemas en la capa de aplicación, especialmente en las llamadas a funciones remotas ( SAP, RFC).

Consideraciones sobre consumo de red

La comunicación de red de carga de trabajo de SAP tradicional es relativamente pequeña con menos de 100 MiB de tráfico de red por día, como por ejemplo:

  • Transacciones de usuario desde SAPGUI; para Windows, para Java (utilizado con macOS o Linux)
  • Transacciones de usuario desde SAP WebGUI
  • Transacciones de usuario con apps Dynpro de web de SAP desde SAP NetWeaver Business Client (NWBC)
  • Llamada a función remota de SAP (RFC SAP) entre sistemas SAP y no SAP
  • Entrada salida de iDOC de SAP entre sistemas SAP y no SAP con terceros (por ejemplo, bancos, proveedores)

Sin embargo, hay comunicaciones de red de carga de trabajo SAP mucho más grandes que consumen mucho más tráfico de red, como por ejemplo:

  • Bibliotecas preinstaladas de SAPUI5 y temas correspondientes a SAP Fiori Launchpad y apps
    • 10 MiB - 25 MiB (estimación) por sesión nueva que se carga desde el asistente web de SAP (también llamado XRay); el navegador coloca estas bibliotecas preinstaladas en memoria caché. Una vez almacenadas en la memoria caché, las bibliotecas se pueden utilizar en cualquier nuevo separador del navegador, incluso después de reiniciar el navegador o de cerrar la sesión de SAP Fiori, hasta que se borra la memoria caché
    • 20 KiB - 500 KiB (estimación) por cada nueva app Fiori que se carga dentro de la sesión
  • SAP HANA System Replication (HSR) síncrona o asíncrona, con envío por streaming de Gigabytes de datos al pes entre los nodos principal y secundario (o terciario)

Con el aumento del tráfico de software SAP del diseño nuevo, se puede superar en gran medida la cantidad de tráfico de red visto en el uso pasado de SAP.

El diseño de sus aplicaciones SAP para que utilice la red troncal privada de IBM Cloud para estas transferencias de datos es importante, ya que no hay cargos de entrada/salida, mientras que el uso de internet público incurre en cargos de salida.

Debe calcular la cantidad de datos que se transfieren. Durante las etapas iniciales de implementación del proyecto, esto puede resultar difícil. Sin embargo, se puede realizar una estimación aproximada de la magnitud.

Consideraciones sobre el rendimiento de red

SAP suele recomendar un rendimiento de red de 10 Gbps (redundante) para el tráfico entre sus servidores de aplicaciones y las bases de datos SAP HANA, y para otros clientes SAP HANA, como SAP Business Intelligence.

Para despliegues de SAP NetWeaver mediante SAP AnyDB con almacenamiento local, incluso para configuraciones de tres niveles, las redes de 1 Gbps suelen ser suficientes.

Consideraciones sobre el rendimiento de latencia de red

Para las operaciones de negocio y los sistemas dependientes que no son SAP, es posible que necesite que se cumplan determinados indicadores de rendimiento de clave de latencia (ICR). Esto debería tener en cuenta la ubicación de los hosts y las pruebas de latencia mediante la red troncal privada de IBM Cloud.

Es necesaria la prueba de latencia mediante la métrica Tiempo de ida y vuelta Time (RTT) cuando se diseña la alta disponibilidad (HA) y la recuperación tras desastre (DR) para SAP HANA.

Si se está diseñando una migración tras error de alta disponibilidad dentro de una ubicación del sitio, en casi todos los casos se podrán cumplir los requisitos de réplica del sistema SAP HANA.

Sin embargo, si se diseña la alta disponibilidad para SAP HANA en varios sitios dentro de una región, o si se diseña una recuperación tras desastre en varias regiones, la latencia que utiliza la métrica RTT (Tiempo de ida y vuelta) se debe probar y considerar cuidadosamente.

Esto se debe a que IBM Cloud busca garantizar una alta disponibilidad de la plataforma, utilizando ubicaciones de sitios geográficamente dispersos con tolerancia a errores (por ejemplo, diferentes evaluaciones de riesgo). Más información disponible en Cómo IBM Cloud garantiza una alta disponibilidad y redundancia.

En particular, para la infraestructura VPC, las zonas de disponibilidad son ubicaciones geográficamente dispersas dentro de la región. Para la mayoría de las cargas de trabajo, este diseño proporciona más redundancia en toda la región. Sin embargo, el sistema de réplica de SAP HANA requiere una baja latencia de red, lo que puede dificultar el cumplimiento de la métrica de tiempo de ida y vuelta (RTT) debido a las limitaciones de transferencia de datos físicos de tecnología actuales del cableado desde el punto de vista físico (es decir, la velocidad de la luz sobre el cable de fibra óptica).

Consideraciones sobre la seguridad de los puertos de red

La siguiente información es un breve resumen del Portal de ayuda de SAP- Puertos TCP/IP de todos los productos de SAP, que proporciona un ejemplo de las consideraciones que se requieren para la seguridad de sus sistemas de SAP y de todo el panorama de la infraestructura de TI en IBM Cloud.

Según las aplicaciones técnicas de SAP que se utilicen y los escenarios de negocio que se aborden, los distintos hosts necesitarán que se abran diferentes puertos. Normalmente, para cumplir este requisito, los grupos de puertos de cortafuegos se combinan con las reglas de cortafuegos. También puede utilizar reglas de cortafuegos individuales por host, aunque a menudo se vuelve inmanejable.

En la tabla siguiente se incluyen algunos de los puertos clave para utilizar con sistemas SAP que utilizan SAP NetWeaver y SAP HANA, que necesitan corrección, en función del número de instancia de la aplicación técnica de SAP; los números de instancia 00, 01, 02 son los valores predeterminados en las diversas aplicaciones técnicas de SAP y estarán en patrones diferentes (estos patrones aparecen resaltados con code blocks ):

Puertos comunes utilizados con aplicaciones técnicas de SAP
Aplicación técnica de SAP Componente Puerto
Direccionador de SAP
Direccionador de SAP 3200
Direccionador de SAP 3299
SAP NetWeaver
SAP NetWeaver AS Primary App Server (diálogo PAS) Instancia 01 3201
SAP NetWeaver AS PAS Gateway Instancia 01 3301
SAP NetWeaver AS Central Services Messenger Server (ASCS MS) Instancia 01 3602
SAP NetWeaver AS PAS Gateway (con SNC habilitado) Instancia 01 4801
SAP NetWeaver AS ICM HTTP (prefijo de puerto 80) 8001
SAP NetWeaver AS ICM HTTPS (Seguro, prefijo de puerto 443) 44301
SAP NetWeaver sapctrl HTTP (instalación de host dual) 50113
SAP NetWeaver sapctrl HTTPS (instalación de host dual) 50114
SAP HANA
SAP HANA sapctrl HTTP (instalación de un host) 50013
SAP HANA sapctrl HTTPS (instalación de un host) 50014
SAP HANA Internal Web Dispatcher 30006
SAP HANA MDC System Tenant SYSDB Index Server 30013
SAP HANA MDC Tenant 1 Index Server 30015
SAP HANA ICM HTTP Internal Web Dispatcher 8000
SAP HANA ICM HTTPS (Secure) Internal Web Dispatcher 4300
SAP Web Dispatcher
SAP Web Dispatcher ICM HTTP (prefijo de puerto 80) Número de instancia 90 8090
SAP Web Dispatcher ICM HTTPS (Seguro, prefijo de puerto 443) Número de instancia 90 44390
SAP HANA XSA
SAP HANA XSA Instancia 00 Client HTTPS para la conexión con el Web Dispatcher gestionado mediante xscontroller (direccionador de plataforma) para fines de autenticación de usuarios. 30032
SAP HANA XSA Instancia 00 Internal HTTPS para la conexión desde el Web Dispatcher gestionado mediante xscontroller (direccionador de plataforma) a xsuaaserver para fines de autenticación de usuarios. 30031
SAP HANA XSA Instancia 00 Client HTTPS para la conexión con el Web Dispatcher gestionado mediante xscontroller para fines de acceso a datos. 30030
SAP HANA XSA Instancia 00 Dynamic Range Internal HTTPS para la conexión desde el Web Dispatcher gestionado mediante xscontroller (direccionador de plataforma) para acceder a la instancia de aplicación. 51000-51500
SAP HANA XSA Instancia 00 Internal HTTPS xsexecagent a xscontroller 30029
SAP HANA XSA Instancia 00 Direccionamiento Web Dispatcher HTTP(S) 30033
SAP NetWeaver Java
Puerto SAP NetWeaver AS JAVA P4 50304
Puerto SAP NetWeaver AS JAVA P4 50404

Consideraciones sobre la seguridad de la segregación de tráfico de red

Puede separar diferentes tipos de tráfico de red en su entorno, ya sea por restricciones de seguridad o por consideraciones de rendimiento.

La segregación de redes resulta útil en los siguientes casos de uso de la carga de trabajo de SAP:

  • Varios servidores que intercambian datos
    • Sistemas SAP en una arquitectura lógica de tres niveles, donde las instancias de base de datos SAP y de aplicación SAP están en hosts diferentes.
  • Varios sistemas SAP que intercambian grandes cantidades de datos
    • Por lo tanto, los servidores de bases de datos, que necesitan tener una baja latencia de red y un alto rendimiento de red al almacenamiento de archivos/ en bloque de red deben evitar los cortafuegos. Sin embargo, la base de datos necesita protección frente a otros sistemas y al acceso de red.

Para utilizar la segregación de redes de forma eficaz, se debe permitir la interconectividad en condiciones específicas.

Separación de subredes en la infraestructura VPC

Para separar el tráfico, utilice varias subredes.

Cada VPC para una región puede contener varias subredes. Estas subredes dentro de la VPC están habilitadas para comunicarse entre sí, a menos que estén bloqueadas por una ACL de red o un Grupo de seguridad. Por lo tanto, dos servidores virtuales en la infraestructura de VPC pueden tener una interfaz de red virtual (vNIC) en distintas subredes entre sí.

La ACL de red o el grupo de seguridad permitirían flujos de interconectividad de red específicos a través de estas subredes separadas.

Sin embargo, un servidor virtual en la infraestructura de VPC no puede tener varias interfaces de red virtual (vNIC) asignadas a varias subredes.

Separación de subredes en la infraestructura clásica

Para separar el tráfico, utilice varias VLAN y subredes.

Cada VLAN puede ser pública o privada y es específica del centro de datos y del pod del centro de datos. La VLAN puede contener varias subredes. Estas subredes dentro de la VLAN están habilitadas para comunicarse entre sí, a menos que estén bloqueadas por un dispositivo de pasarela.

Por lo tanto, dos hosts nativos en la infraestructura clásica pueden tener tarjetas de interfaz de red física asignadas a distintas VLAN y subredes.

El dispositivo de pasarela permitiría flujos de interconectividad de red específicos a través de estas subredes separadas.

De forma predeterminada, un servidor nativo (puede cambiar en función de las especificaciones de hardware) utiliza tarjetas de interfaz de red física (NIC) y consume cuatro puertos Ethernet:

  • eth0 NIC / eth2 NIC redundante
    • VLAN pública, como DMZ entroncada al dispositivo de pasarela
      • Subred primaria pública
        • IP pública detrás de DMZ
  • eth1 NIC / eth3 NIC redundante
    • VLAN privada, como DMZ entroncada al dispositivo de pasarela
      • Subred primaria pública
        • IP privada detrás de DMZ
  • mgmt0 --- IPMI (zona de red de administración)

Los servidores nativos se pueden reconfigurar de forma predeterminada si las especificaciones de hardware lo permiten, con más subredes. Esto permite conseguir la máxima separación del tráfico y puede aumentar el rendimiento mediante el uso de diferentes tarjetas de interfaz de red (NIC) para gestionar el rendimiento de la red en paralelo. Un ejemplo de esta reconfiguración puede ser el siguiente:

  • eth0 NIC / eth2 NIC redundante
    • VLAN pública, como DMZ entroncada al dispositivo de pasarela
      • Subred primaria pública
        • IP pública detrás de DMZ
  • eth1 NIC / altered to eth4 NIC redundante
    • VLAN privada, como DMZ entroncada al dispositivo de pasarela
      • Subred primaria pública
        • IP privada detrás de DMZ
  • eth3 NIC adicional / eth5 NIC redundante adicional
    • VLAN privada
      • Subred A portátil secundaria privada
        • IP privada detrás de DMZ
      • Subred B portátil secundaria privada
        • IP privada detrás de DMZ
  • mgmt0 --- IPMI (zona de red de administración)

Una reconfiguración como la del ejemplo no estará disponible en todos los escenarios.

Para SAP HANA y para conseguir el alto rendimiento de la red y la seguridad necesarios, las VLAN adicionales pueden ayudar. Lea las recomendaciones de SAP para entornos locales en SAP HANA. Requisitos de red e identifique la configuración de red adecuada para satisfacer sus necesidades empresariales.

Separación de subredes en VMware en la infraestructura clásica

Para separar el tráfico con IBM Cloud for VMware Solutions Dedicated, utilice varias subredes dentro de VMware Overlay VXLAN (basado en VMware NSX).

En IBM Cloud for VMware Solutions Dedicated, VMware Overlay VXLAN (basado en VMware NSX) se conecta a VLAN pública y a VLAN privada en la red de la infraestructura clásica como sistema subyacente; la gestión de VMware NSX utiliza las subredes portátiles secundarias privadas para acceder a VXLAN. Esto proporciona un control completo del diseño de la red cuando se ejecuta en VMware y permite asignar una IP de VMware VM desde cualquier rango definido.

Si en su lugar se utiliza un despliegue manual de VMware en un servidor nativo, VMware vSwitch utilizaría directamente la subred portátil secundaria de la VLAN privada para asignar una dirección IP de VMware VM de la red de infraestructura clásica.

La segregación de tráfico se debe diseñar cuidadosamente en los despliegues basados en VMware debido a los despliegues elaborados basados en VMware, donde podría ser necesario separar de forma estricta los distintos tipos de tráfico de red por motivos de seguridad.