Omitir Vínculos de navegación | |
Salir de la Vista de impresión | |
Gestión del rendimiento de red de Oracle Solaris 11.1 Oracle Solaris 11.1 Information Library (Español) |
1. Introducción a la gestión del rendimiento de red
2. Uso de agregaciones de enlaces
3. Cómo trabajar con redes VLAN
4. Administración de redes con puentes (tareas)
6. Administración de IPMP (tareas)
Mantenimiento de enrutamiento durante la implementación de IPMP
Cómo definir las rutas mientras usa IPMP
Cómo configurar un grupo IPMP que use DHCP
Cómo configurar manualmente un grupo IPMP de interfaz activa-activa
Cómo configurar manualmente un grupo IPMP de interfaz activa-en espera
Cómo agregar una interfaz a un grupo IPMP
Cómo eliminar una interfaz de un grupo IPMP
Cómo mover una interfaz de un grupo IPMP a otro grupo IPMP
Configuración de detección de fallos basada en sondeos
Requisitos para seleccionar destinos para la detección de fallos basada en sondeos
Configuración de la detección de fallos basada en sondeos (mapa de tareas)
Cómo seleccionar qué método de detección de fallos utilizar
Cómo especificar manualmente los sistemas de destino para la detección de fallos basada en sondeos
Supervisión de información de IPMP
Personalización de la salida del comando ipmpstat
Uso del comando ipmpstat en secuencias de comandos
7. Intercambio de información de conectividad de red con LLDP
8. Cómo trabajar con funciones de puente de centro de datos en Oracle Solaris
9. Puente virtual perimetral en Oracle Solaris
10. Equilibrador de carga integrado (descripción general)
11. Configuración del equilibrador de carga integrado
12. Gestión del equilibrador de carga integrado
13. Protocolo de redundancia de enrutador virtual (descripción general)
A. Tipos de agregaciones de enlaces: comparación de funciones
La detección de fallos basada en sondeos implica el uso de sistemas de destino, tal como se explica en Detección de fallos basada en sondeos. Para identificar destinos para la detección de fallos basada en sondeos, el daemon in.mpathd funciona en dos modos: modo de destino de enrutador o modo de destino de multidifusión. En el modo de destino de enrutador, el daemon sondea los destinos definidos en la tabla de enrutamiento. Si no se han definido destinos, el daemon funciona en modo de destino de multidifusión, en el que se envían paquetes de multidifusión para sondear los hosts vecinos en la LAN.
Preferiblemente, debe configurar los sistemas de destino para que el daemon in.mpathd realice el sondeo. Para algunos grupos IPMP, el enrutador predeterminado es suficiente como destino. Sin embargo, para algunos grupos IPMP, quizá desee configurar destinos específicos para la detección de fallos basada en sondeos. Para especificar los destinos, configure las rutas de host en la tabla de enrutamiento como destinos de sondeo. Cualquier ruta host configurada en la tabla de enrutamiento aparece enumerada antes del enrutador predeterminado. IPMP utiliza rutas host definidas explícitamente para la selección de destino. Por lo tanto, debe configurar rutas host para configurar destinos específicos de sondeo en lugar de utilizar el enrutador predeterminado.
Para configurar las rutas host en la tabla de enrutamiento, utilice el comando route. Puede utilizar la opción -p con este comando para agregar rutas persistentes. Por ejemplo, route -p add agrega una ruta que permanecerá en la tabla de enrutamiento incluso después de reiniciar el sistema. Por lo tanto, la opción -p permite agregar rutas persistentes sin necesidad de secuencias de comandos especiales para volver a crear estas rutas en cada inicio del sistema. Para utilizar de forma óptima la detección de fallos basada en sondeos, asegúrese de configurar varios destinos para recibir sondeos.
El procedimiento descrito en Cómo especificar manualmente los sistemas de destino para la detección de fallos basada en sondeos muestra la sintaxis exacta para agregar rutas persistentes a los objetivos para la detección de fallos basada en sondeos. Para obtener más información sobre las opciones para el comando route, consulte la página del comando man route(1M).
En esta sección, se describen los siguientes temas:
Siga esta lista de criterios cuando evalúe qué hosts de su red podrían servir como buenos destinos:
Asegúrese de que los posibles destinos estén disponibles y de que se estén ejecutando. Haga una lista de sus direcciones IP.
Asegúrese de que las interfaces de destino se encuentren en la misma red que el grupo IPMP que está configurando.
La máscara de red y las direcciones de difusión de los sistemas de destino deben ser las mismas que las direcciones del grupo IPMP.
El host de destino debe poder responder a las solicitudes de ICMP desde la interfaz que utiliza la detección de fallos basada en sondeos.
En el siguiente mapa de tareas, se enumeran los procedimientos para configurar la detección de fallos basada en sondeos para un grupo IPMP.
|
De manera predeterminada, la detección de fallos basada en sondeos funciona mediante direcciones de prueba. Si el controlador NIC es compatible con ella, la detección de fallos basada en enlaces también se activa automáticamente.
No puede desactivar la detección de fallos basada en enlaces si este método es compatible con el controlador NIC. Sin embargo, puede seleccionar qué tipo de detección de fallos basada en sondeos implementar.
Antes de empezar
Asegúrese de que los destinos de sondeo cumplan los requisitos descritos en Requisitos para seleccionar destinos para la detección de fallos basada en sondeos.
# svccfg -s svc:/network/ipmp setprop config/transitive-probing=true # svcadm refresh svc:/network/ipmp:default
Para obtener más información sobre la configuración de esta propiedad, consulte la página del comando man in.mpathd(1M).
# ipadm delete-addr address addrobj
Donde addrobj debe hacer referencia a un interfaz subyacente que aloja una dirección de prueba.
# svccfg -s svc:/network/ipmp setprop config/transitive-probing=false # svcadm refresh svc:/network/ipmp:default
# ipadm create-addr -a address under-interface
Donde address puede estar en notación CIDR y under-interface es una interfaz subyacente del grupo IPMP.
En este procedimiento se describe cómo agregar destinos específicos si utiliza las direcciones de prueba para implementar la detección de fallos basada en sondeos.
Antes de empezar
Asegúrese de que los destinos de sondeo cumplan los requisitos descritos en Requisitos para seleccionar destinos para la detección de fallos basada en sondeos.
$ route -p add -host destination-IP gateway-IP -static
Donde destination-IP y gateway-IP son direcciones IPv4 del host que se utilizará como un destino. Por ejemplo, para especificar el sistema de destino 192.168.10.137, que se encuentra en la misma subred que las interfaces del grupo IPMP ipmp0, escribiría lo siguiente:
$ route -p add -host 192.168.10.137 192.168.10.137 -static
Esta nueva ruta se configurará automáticamente cada vez que se reinicie el sistema. Si desea definir sólo una ruta temporal para un sistema de destino para la detección de fallos basada en sondeos, no utilice la opción -p.
Utilice el archivo de configuración IPMP /etc/default/mpathd para configurar los siguientes parámetros del sistema para los grupos IPMP.
FAILURE_DETECTION_TIME
FAILBACK
TRACK_INTERFACES_ONLY_WITH_GROUPS
Para obtener más información, consulte Cómo usar los derechos administrativos que tiene asignados de Administración de Oracle Solaris 11.1: servicios de seguridad.
Cambie el valor predeterminado de uno o más de los tres parámetros.
FAILURE_DETECTION_TIME=n
Donde n es el tiempo en segundos para que los sondeos ICMP detecten si se ha producido un fallo de la interfaz. El valor predeterminado es de 10 segundos.
FAILBACK=[yes | no]
yes: el valor yes es el comportamiento de recuperación tras fallos predeterminado de IPMP. Cuando se detecta la reparación de una interfaz fallida, el acceso de red recupera la interfaz reparada, tal como se describe en Detección de reparaciones de interfaces físicas.
no: el valor no indica que el tráfico de datos no regresa a una interfaz reparada. Cuando se detecta la reparación de una interfaz fallida, se configura el indicador INACTIVE para dicha interfaz. Este indicador significa que la interfaz no se va a utilizar para el tráfico de datos. La interfaz se puede seguir utilizando para el tráfico de sondeos.
Por ejemplo, suponga que el grupo IPMP ipmp0 consta de dos interfaces: net0 y net1. En el archivo /etc/default/mpathd, está definido el parámetro FAILBACK=no. Si net0 falla, se marca como FAILED y se vuelve no utilizable. Tras la reparación, la interfaz se marca como INACTIVE y permanece no utilizable por el valor FAILBACK=no.
Si net1 falla y solamente net0 está en el estado INACTIVE, se borra el indicador INACTIVE de net0, y la interfaz se vuelve utilizable. Si el grupo de IPMP tiene otras interfaces que también están en el estado INACTIVE, cualquiera de estas interfaces INACTIVE, y no necesariamente net0, se pueden borrar y convertir en utilizables cuando net1.
TRACK_INTERFACES_ONLY_WITH_GROUPS=[yes | no]
Nota - Para obtener información sobre este parámetro y la función de grupo anónimo, consulte Detección de fallos y función del grupo anónimo.
yes: el valor yes es el predeterminado para el comportamiento de IPMP. Este valor hace que IPMP omita las interfaces de red que no estén configuradas en un grupo IPMP.
no: el valor no define la detección de fallos y la reparación para todas las interfaces de red, independientemente de si están configuradas en un grupo IPMP. Sin embargo, cuando se detecta un fallo o reparación en una interfaz que no está configurada en un grupo IPMP, no se desencadena ninguna acción en IPMP para mantener la funciones de red de dicha interfaz. Por tanto, el valor no sólo resulta útil para comunicar fallos y no mejora directamente la disponibilidad de la red.
# pkill -HUP in.mpathd
El daemon se reinicia con los nuevos valores de los parámetros en vigor.