Para enlazar una LIF a un grupo de puertos, asocie la dirección IP de LIF con un grupo de puertos físicos. El principal método para añadir puertos físicos juntos es LACP. La funcionalidad de tolerancia a fallos de LACP es bastante sencilla; cada puerto de un grupo de LACP se supervisa y se elimina del grupo de puertos en caso de que se produzca un funcionamiento incorrecto. No obstante, existen muchos conceptos erróneos sobre cómo funciona LACP con respecto al rendimiento:

El enfoque más común en entornos de mayor tamaño que consisten en muchos hosts de base de datos es crear un agregado LACP de un número adecuado de interfaces 10Gb (o más rápidas) mediante el equilibrio de carga de IP. Este enfoque permite a ONTAP ofrecer un uso uniforme de todos los puertos, siempre y cuando existan suficientes clientes. El equilibrio de carga se desglosa cuando hay menos clientes en la configuración porque la conexión troncal LACP no redistribuye la carga de forma dinámica.

Cuando se establece una conexión, el tráfico en una dirección determinada se coloca en un solo puerto. Por ejemplo, una base de datos que realiza una exploración de tabla completa en un sistema de archivos NFS conectado a través de un tronco LACP de cuatro puertos lee los datos aunque solo una tarjeta de interfaz de red (NIC). Si sólo hay tres servidores de base de datos en un entorno de este tipo, es posible que los tres estén leyendo desde el mismo puerto, mientras que los otros tres puertos estén inactivos.

La vinculación de una LIF a un puerto físico provoca un control más granular sobre la configuración de red, ya que una dirección IP determinada en un sistema ONTAP solo está asociada con un puerto de red a la vez. A continuación, la resiliencia se lleva a cabo mediante la configuración de grupos de conmutación al respaldo y las políticas de conmutación por error.

El comportamiento de las LIF durante la interrupción de la red está controlado por las políticas de conmutación por error y los grupos de recuperación tras fallos. Las opciones de configuración han cambiado con las distintas versiones de ONTAP. Consulte la "Documentación de gestión de redes de ONTAP para políticas y grupos de conmutación por error" Para obtener detalles específicos de la versión de ONTAP que se va a poner en marcha.

ONTAP 8,3 y superiores permiten la gestión de recuperación tras fallos de LIF en función de dominios de retransmisión. Por lo tanto, un administrador puede definir todos los puertos que tienen acceso a una subred determinada y permitir que ONTAP seleccione una LIF de conmutación al nodo de respaldo adecuada. Algunos clientes pueden utilizar este enfoque, pero tiene limitaciones en un entorno de red de almacenamiento de alta velocidad debido a la falta de previsibilidad. Por ejemplo, un entorno puede incluir ambos puertos 1GB para acceso rutinario al sistema de archivos y puertos 10Gb para las operaciones de I/O del archivo de datos Si ambos tipos de puertos existen en el mismo dominio de retransmisión, la conmutación por error de LIF puede provocar que se muevan las operaciones de I/O del archivo de datos de un puerto 10Gb a un puerto 1GB.

En resumen, tenga en cuenta las siguientes prácticas:

Ajuste la auto-revert parámetro como desee. La mayoría de los clientes prefieren establecer este parámetro en true Para que la LIF vuelva a su puerto de inicio. Sin embargo, en algunos casos, los clientes han establecido esto en 'false' para que se pueda investigar una conmutación por error inesperada antes de devolver una LIF a su puerto de origen.

Un concepto erróneo común es que debe haber una relación de 1:1 GbE entre los volúmenes y los LIF de NFS. Aunque esta configuración es necesaria para mover un volumen a cualquier punto de un clúster mientras no se crea tráfico de interconexión adicional, no es categóricamente un requisito. Hay que tener en cuenta el tráfico entre clústeres, pero la mera presencia del tráfico entre clústeres no crea problemas. Muchas de las pruebas de rendimiento publicadas creadas para ONTAP incluyen I/O predominantemente indirectas

Por ejemplo, un proyecto de base de datos que contiene una cantidad relativamente pequeña de bases de datos críticas para el rendimiento que solo requerían un total de 40 volúmenes podría justificar un volumen de 1:1 GB para la estrategia LIF, una disposición que requeriría 40 direcciones IP. Posteriormente, cualquier volumen se podría mover a cualquier parte del clúster junto con la LIF asociada; el tráfico siempre sería directo, minimizando todas las fuentes de latencia incluso a niveles de microsegundos.

Como ejemplo por contador, un entorno alojado de gran tamaño se podría gestionar más fácilmente con una relación de 1:1:1 entre clientes y las LIF. Con el tiempo, es posible que se deba migrar un volumen a un nodo diferente, lo cual provocaría cierto tráfico indirecto. Sin embargo, el efecto de rendimiento debe ser indetectable a menos que los puertos de red en el conmutador de interconexión estén saturados. Si hay algún problema, se puede establecer un nuevo LIF en nodos adicionales y el host puede actualizarse en la siguiente ventana de mantenimiento para eliminar el tráfico indirecto de la configuración.