Configuración de red
Sugerir cambios
PDF
La configuración de los ajustes de red cuando se utiliza vSphere con sistemas que ejecutan ONTAP es sencilla y similar a otra configuración de red.
Estas son algunas cosas a tener en cuenta:
-
Hay que separar el tráfico de la red de almacenamiento de otras redes. Se puede lograr una red independiente a través de una VLAN dedicada o switches independientes para el almacenamiento. Si la red de almacenamiento comparte rutas físicas como los enlaces ascendentes, puede que necesite calidad de servicio o puertos adicionales para garantizar el ancho de banda suficiente. No conecte los hosts directamente al sistema de almacenamiento a menos que la guía de la solución lo indique específicamente; utilice switches para tener rutas redundantes y permita que VMware HA funcione sin intervención alguna.
-
Se deben utilizar tramas gigantes si la red es compatible. Si se usan, asegúrese de que estén configurados de la misma forma en todos los dispositivos de red, VLAN, etc., en la ruta entre el almacenamiento y el host ESXi. De lo contrario, puede que observe problemas de rendimiento o conexión. La MTU también debe establecerse de forma idéntica en el switch virtual ESXi, el puerto de VMkernel y, además, en los puertos físicos o los grupos de interfaces de cada nodo ONTAP.
-
NetApp solo recomienda deshabilitar el control de flujo de red en los puertos de interconexión del clúster de un clúster de ONTAP. NetApp no hace ninguna otra recomendación en cuanto a las mejores prácticas relativas al control de flujo para los puertos de red restantes que se usan para el tráfico de datos. Debe habilitarla o deshabilitarla según sea necesario. Consulte "CONSULTE TR-4182" para obtener más información sobre el control de flujo.
-
Cuando las cabinas de almacenamiento ESXi y ONTAP están conectadas a redes de almacenamiento Ethernet, NetApp recomienda configurar los puertos Ethernet a los que se conectan estos sistemas como puertos periféricos del protocolo de árbol de expansión rápido (RSTP) o mediante la función PortFast de Cisco. NetApp recomienda habilitar la función de enlace troncal Spanning-Tree PortFast en entornos que utilizan la función Cisco PortFast y que tienen la conexión de enlaces VLAN 802.1Q habilitada tanto para el servidor ESXi como para las cabinas de almacenamiento ONTAP.
-
NetApp recomienda las siguientes prácticas recomendadas para la agregación de enlaces:
-
Utilice switches que admitan la agregación de enlaces de puertos en dos chasis de switch separados mediante un enfoque de grupo de agregación de enlaces de varios chasis, como Virtual PortChannel (VPC) de Cisco.
-
Deshabilite LACP para los puertos del switch conectados a ESXi a menos que utilice dvSwitch 5.1 o una versión posterior con LACP configurado.
-
LACP se utiliza para crear agregados de enlaces para sistemas de almacenamiento ONTAP con grupos de interfaces dinámicas multimodo con hash IP.
-
Use una política de agrupación de hash IP en ESXi.
-
En la siguiente tabla se ofrece un resumen de los elementos de configuración de red e indica dónde se aplican los ajustes.
| Elemento | ESXi | Conmutador | Nodo | SVM |
|---|---|---|---|---|
Dirección IP |
VMkernel |
No** |
No** |
Sí |
Agregación de enlaces |
Switch virtual |
Sí |
Sí |
No* |
VLAN |
VMkernel y grupos de puertos de máquina virtual |
Sí |
Sí |
No* |
Control de flujo |
NIC |
Sí |
Sí |
No* |
Árbol expansivo |
No |
Sí |
No |
No |
MTU (para tramas gigantes) |
Conmutador virtual y puerto de VMkernel (9000) |
Sí (configurado como máx.) |
Sí (9000) |
No* |
Grupos de conmutación por error |
No |
No |
Sí (crear) |
Sí (seleccione) |
*Las LIF de SVM se conectan a puertos, grupos de interfaces o interfaces VLAN que tienen VLAN, MTU y otras configuraciones. Sin embargo, la configuración no se gestiona a nivel de SVM.
**Estos dispositivos tienen direcciones IP propias para la administración, pero estas direcciones no se utilizan en el contexto de las redes de almacenamiento ESXi.
SAN (FC, NVMe/FC, iSCSI, NVMe/TCP), RDM
ONTAP ofrece almacenamiento basado en bloques para VMware vSphere utilizando el protocolo iSCSI tradicional y Fibre Channel (FCP) así como el protocolo de bloque de nueva generación altamente eficiente y eficiente, NVMe over Fabrics (NVMe-oF), con soporte para NVMe/FC y NVMe/TCP.
Para obtener las mejores prácticas detalladas para implementar protocolos de bloque para almacenamiento de máquinas virtuales con vSphere y ONTAP, consulte "Almacenes de datos y protocolos: SAN"
NFS
VSphere permite a los clientes utilizar cabinas NFS de nivel empresarial para proporcionar acceso simultáneo a los almacenes de datos en todos los nodos de un clúster ESXi. Como se ha mencionado en la "almacenes de datos" sección, existen algunas ventajas de facilidad de uso y visibilidad de la eficiencia del almacenamiento cuando se usa NFS con vSphere.
Para conocer las prácticas recomendadas, consulte "Almacenes de datos y protocolos: NFS"
Conexión de red directa
A veces, los administradores de almacenamiento prefieren simplificar sus infraestructuras eliminando los switches de red de la configuración. Esto puede ser soportado en algunos escenarios. Sin embargo, hay algunas limitaciones y advertencias a tener en cuenta.
ISCSI y NVMe/TCP
Un host que utilice iSCSI o NVMe/TCP se puede conectar directamente a un sistema de almacenamiento y funcionar normalmente. El motivo son las rutas. Las conexiones directas a dos controladoras de almacenamiento diferentes dan como resultado dos rutas independientes para el flujo de datos. La pérdida de una ruta, un puerto o una controladora no impide que se utilice la otra ruta.
NFS
Se puede utilizar el almacenamiento NFS conectado directamente, pero con una limitación considerable: El fallo no funcionará si no se realiza una ejecución significativa de secuencias de comandos, que sería responsabilidad del cliente.
El motivo por el que la recuperación tras fallos sin interrupciones se complica gracias al almacenamiento NFS de conexión directa es el enrutamiento que se produce en el sistema operativo local. Por ejemplo, supongamos que un host tiene una dirección IP de 192.168.1.1/24 y está directamente conectado a una controladora ONTAP con la dirección IP 192.168.1.50/24. Durante la conmutación al nodo de respaldo, esa dirección 192.168.1.50 puede conmutar al nodo de respaldo a la otra controladora y estará disponible para el host, pero ¿cómo detecta el host su presencia? La dirección 192.168.1.1 original todavía existe en la NIC host que ya no se conecta a un sistema operativo. El tráfico destinado a 192.168.1.50 seguiría enviándose a un puerto de red inoperable.
La segunda NIC del SO podría configurarse como 19 2.168.1.2 y sería capaz de comunicarse con la dirección fallida en 192.168.1.50, pero las tablas de enrutamiento locales tendrían un valor predeterminado de usar una dirección y solo una para comunicarse con la subred 192.168.1.0/24. Un administrador de sistema podría crear un marco de scripting que detectara una conexión de red fallida y alterara las tablas de enrutamiento locales o activara o desactivara las interfaces. El procedimiento exacto dependerá del sistema operativo en uso.
En la práctica, los clientes de NetApp disponen de NFS conectado directamente, pero normalmente solo para cargas de trabajo en las que se pueden pausar I/O durante las recuperaciones tras fallos. Cuando se utilizan montajes duros, no debe haber ningún error de E/S durante dichas pausas. El E/S se debe congelar hasta que se restauren los servicios, ya sea mediante una conmutación por recuperación o mediante intervención manual para mover las direcciones IP entre las NIC del host.
Conexión directa FC
No es posible conectar directamente un host a un sistema de almacenamiento ONTAP mediante el protocolo FC. La razón es el uso de NPIV. El WWN que identifica un puerto ONTAP FC con la red de FC utiliza un tipo de virtualización denominado NPIV. Cualquier dispositivo conectado a un sistema ONTAP debe poder reconocer un WWN de NPIV. No hay proveedores de HBA actuales que ofrezcan un HBA que se pueda instalar en un host que admita un destino NPIV.