Omitir V�nculos de navegaci�n | |
Salir de la Vista de impresi�n | |
Guía de administración del sistema: servicios IP |
Parte I Introducción a la administración del sistema: servicios IP
1. Conjunto de protocolos TCP/IP de Oracle Solaris (descripción general)
Parte II Administración de TCP/IP
2. Planificación de la red TCP/IP (tareas)
3. Introducción a IPv6 (descripción general)
4. Planificación de una red IPv6 (tareas)
5. Configuración de servicios de red TCP/IP y direcciones IPv4 (tareas)
6. Administración de interfaces de red (tareas)
7. Configuración de una red IPv6 (tareas).
8. Administración de redes TCP/IP (tareas)
9. Resolución de problemas de red (Tareas)
10. Descripción detallada de TCP/IP e IPv4 (referencia)
11. IPv6 en profundidad (referencia)
12. Acerca de DHCP (descripción general)
13. Planificación del servicio DHCP (tareas)
14. Configuración del servicio DHCP (tareas)
15. Administración de DHCP (tareas)
16. Configuración y administración del cliente DHCP
17. Solución de problemas de DHCP (referencia)
18. Comandos y archivos DHCP (referencia)
19. Arquitectura de seguridad IP (descripción general)
20. Configuración de IPsec (tareas)
21. Arquitectura de seguridad IP (referencia)
22. Intercambio de claves de Internet (descripción general)
23. Configuración de IKE (tareas)
24. Intercambio de claves de Internet (referencia)
25. Filtro IP en Oracle Solaris (descripción general)
27. IP para móviles (Descripción general)
28. Administración de IP móvil (tareas)
29. Archivos y comandos de IP para móviles (referencia)
30. Introducción a IPMP (descripción general)
Componentes IPMP de Oracle Solaris
Daemon de múltiples rutas, in.mpathd
Terminología y conceptos de IPMP
Detección de fallos y conmutación por error
Detección de reparaciones y recuperación tras los errores
Expansión de la carga saliente
Cómo evitar que las aplicaciones utilicen direcciones de prueba
Configuraciones de interfaces IPMP
Interfaces de reserva en un grupo IPMP
Configuraciones comunes de interfaces IPMP
Comprobación del estado de una interfaz
Funciones de detección de fallos IPMP y recuperación
Detección de fallos basada en vínculos
Detección de fallos basada en sondeos
Detección de reparaciones de interfaces físicas
Qué ocurre durante la conmutación por error de la interfaz
31. Administración de IPMP (tareas)
Parte VII Calidad de servicio IP (IPQoS)
32. Introducción a IPQoS (Descripción general)
33. Planificación para una red con IPQoS (Tareas)
34. Creación del archivo de configuración IPQoS (Tareas)
35. Inicio y mantenimiento de IPQoS (Tareas)
36. Uso de control de flujo y recopilación de estadísticas (Tareas)
La función de reconfiguración dinámica (DR) permite volver a configurar el hardware del sistema, como las interfaces, mientras el sistema está en ejecución. En esta sección se explica cómo DR interopera con IPMP.
En un sistema que admite la DR de NIC, IPMP se puede utilizar para mantener la conectividad y evitar la interrupción de las conexiones existentes. Puede conectar, desconectar o volver a conectar tarjetas NIC de forma segura en un sistema que admita DR y utilice IPMP. Esto es posible porque IPMP se integra en la estructura del Gestor de coordinación de reconfiguración (RCM). RCM administra la reconfiguración dinámica de los componentes del sistema.
Normalmente se utiliza el comando cfgadm para llevar a cabo las operaciones de DR. Sin embargo, algunas plataformas proporcionan otros métodos. Consulte la documentación de su plataforma para obtener más información. Encontrará información específica sobre DR en los siguientes recursos.
Tabla 30-1 Recursos de documentación para la reconfiguración dinámica
|
Puede agregar interfaces a un grupo IPMP en cualquier momento utilizando el comando ifconfig, tal como se describe en Cómo configurar un grupo IPMP con múltiples interfaces. De este modo, cualquier interfaz de los componentes del sistema que conecte tras el inicio del sistema se podrá sondear y agregar a un grupo IPMP existente. Si es preciso, puede configurar las interfaces que acaba de agregar en su propio grupo IPMP.
Estas interfaces y las direcciones de datos que se configuran en ellas están inmediatamente disponibles para el grupo IPMP. Sin embargo, para que el sistema configure y utilice las interfaces automáticamente tras un reinicio, debe crear un archivo /etc/hostname.interfaz para cada interfaz nueva. Para obtener más información, consulte Cómo configurar una interfaz física tras la instalación del sistema.
Si ya existe un archivo /etc/hostname.interfaz cuando se conecta la interfaz, RCM configura automáticamente la interfaz de acuerdo con el contenido de este archivo. De este modo, la interfaz recibe la misma configuración que habría recibido tras el inicio del sistema.
Todas las solicitudes para desconectar los componentes del sistema que contengan NIC se comprueban antes para garantizar el mantenimiento de la conectividad. Por ejemplo, de modo predeterminado no puede desconectar una NIC que no se encuentre en un grupo IPMP. Tampoco puede desconectar una NIC que contenga las únicas interfaces en funcionamiento de un grupo IPMP. Sin embargo, si debe eliminar el componente del sistema, puede modificar este comportamiento con la opción -f de cfgadm, tal como se explica en la página del comando man cfgadm(1M).
Si las comprobaciones son correctas, las direcciones de datos asociadas con la NIC desconectada conmutarán por error a una NIC en funcionamiento del mismo grupo, como si la NIC que se desconecta hubiera fallado. Cuando se desconecta la NIC, todas las direcciones de prueba de las interfaces NIC se desconfiguran. A continuación, la NIC se desconecta del sistema. Si falla alguno de estos pasos, o falla la DR de otro hardware del mismo componente del sistema, se restablece el estado original de la configuración anterior. Recibirá un mensaje de estado sobre este evento. De lo contrario, la solicitud de desconexión se completará correctamente. Ya podrá eliminar el componente del sistema. Las conexiones existentes no se interrumpen.
RCM registra la información de configuración asociada con cualquier NIC que se desconecte de un sistema en ejecución. Como consecuencia, RCM trata la reconexión de una NIC que se ha desconectado previamente del mismo modo que lo haría con la conexión de una nueva NIC. Por tanto, RCM sólo realiza conexiones.
Sin embargo, las NIC reconectadas cuentan con un archivo /etc/hostname. interfaz. En ese caso, RCM configura automáticamente la interfaz de acuerdo con el contenido del archivo /etc/hostname. interfaz. Asimismo, RCM informa al daemon in.mpathd de cada dirección de datos que se alojó originalmente en la interfaz reconectada. Cuando la interfaz reconectada funciona correctamente, todas sus direcciones de datos se recuperan tras los errores en la interfaz reconectada como si se hubiera reparado.
Si la NIC que se reconecta no tiene ningún archivo /etc/hostname. interfaz, no hay ninguna información de configuración disponible. RCM no tiene información sobre cómo configurar la interfaz. Una consecuencia de esta situación es que las direcciones que se habían conmutado por error a otra interfaz no se recuperarán tras los errores.
Las tarjetas NIC que no están presentes durante el inicio del sistema representan un caso especial de detección de fallos. Durante el inicio, las secuencias de inicio supervisan las interfaces con archivos /etc/hostname.interfaz que no se pueden sondear. Todas las direcciones de datos que haya en dicho archivo /etc/hostname. interfaz se alojan de manera automática en otra interfaz del grupo IPMP.
En tal caso, recibirá mensajes de error similares a los siguientes:
moving addresses from failed IPv4 interfaces: hme0 (moved to hme1) moving addresses from failed IPv6 interfaces: hme0 (moved to hme1)
Si no existe ninguna dirección alternativa, recibirá mensajes de error similares a los siguientes:
moving addresses from failed IPv4 interfaces: hme0 (couldn't move; no alternative interface) moving addresses from failed IPv6 interfaces: hme0 (couldn't move; no alternative interface)
Nota - En este caso de detección de fallos, sólo se mueven a una interfaz alternativa las direcciones de datos que se especifican en el archivo /etc/hostname. interfaz de la interfaz que falta. Cualquier dirección que se obtenga por otros medios, como RARP o DHCP, no se obtendrá ni se moverá.
Si se reconecta con DR una interfaz con el mismo nombre que otra interfaz que no estaba presente durante el inicio del sistema, RCM sondea la interfaz automáticamente. A continuación, RCM configura la interfaz de acuerdo con el contenido del archivo /etc/hostname.interfaz de la interfaz. Finalmente, RCM recupera tras los errores las direcciones de datos, como si la interfaz se hubiera reparado. Por tanto, la configuración de red final es idéntica a la configuración que se habría realizado si el sistema se hubiera iniciado con la interfaz presente.