Consideraciones de la agrupación en clusters para redes
Los fallos de los dispositivos de red, los enlaces de datos y las interfaces no ocasionan el fallo de los controladores de un subsistema agrupado en clusters. Para protegerse contra fallos de red, tanto dentro como fuera del dispositivo, se debe usar IPMP y/o LACP. Para que el enfoque relacionado con la disponibilidad sea integral, es necesario configurar correctamente la red y contar con un plan de redundancia que incluya a toda la red.
Las interfaces de red se pueden configurar como recursos únicos o privados, siempre que tengan una configuración de IP estática. Las interfaces configuradas con DHCP deben ser privadas. No se recomienda usar DHCP en clusters. Si se las configura como recurso único, todos los enlaces de datos y los dispositivos utilizados para construir una interfaz pueden estar activos solamente en un controlador a la vez. De manera similar, los dispositivos correspondientes de cada controlador deben estar conectados a las mismas redes para que el servicio se proporcione en un estado de conmutación por error. En la siguiente figura, se muestra un ejemplo.
Figura 5 Agrupación en clusters para redes
Para que un cluster funcione correctamente al construir interfaces de red a partir de dispositivos y enlaces de datos, es esencial que cada interfaz única tenga un dispositivo que use el mismo identificador y las mismas capacidades disponibles en ambos controladores. Como los identificadores de los dispositivos dependen del tipo de dispositivo y el orden en el que el dispositivo los detectó originalmente, los controladores en clusters DEBEN tener instalado hardware idéntico. Cada una de las ranuras de ambos controladores debe completarse con hardware idéntico y se las debe completar en el mismo orden en ambos controladores. Su proveedor o representante de servicio autorizado de Oracle lo ayudará a planificar actualizaciones de hardware que cumplan con estos requisitos.
Una ruta siempre está vinculada explícitamente con una única interfaz de red. Las rutas se representan en el gestor de recursos como simbiontes. Estas pueden pasar al modo activo solo cuando las interfaces a las que están vinculadas se encuentran en estado operativo. Por lo tanto, una ruta vinculada a una interfaz que se encuentra en el modo de energía en espera (exportada) no tiene efecto hasta que se activa la interfaz durante el proceso de toma de control. Esto es importante cuando hay dos agrupaciones configuradas y ambas están disponibles para una subred común. Si esa subred aloja una ruta que los dispositivos utilizan para alcanzar una o varias redes adicionales, se debe configurar una ruta separada (por ejemplo, una segunda ruta por defecto), la cual se debe vincular con cada una de las interfaces activas y en espera conectadas a esa subred.
Ejemplo:
-
La interfaz e1000g3 está asignada a "alice" y la interfaz e1000g4 está asignada a "bob".
-
Cada interfaz tiene una dirección en la red 172.16.27.0/24 y puede ser utilizada para proporcionar servicio a clientes de la red 172.16.64.0/22, a la que se accede por medio de 172.16.27.1.
-
Se deben crear dos rutas hasta 172.16.64.0/22 vía 172.16.27.1: una vinculada a e1000g3 y la otra a e1000g4.
Es buena idea asignar una dirección IP que se use solo para administración a cada controlador en cluster (probablemente sobre una red de gestión dedicada) y designar la interfaz como recurso privado. Esto garantiza que sea posible alcanzar un controlador que esté en funcionamiento desde la red de gestión aunque se encuentre en el estado AKCS_STRIPPED y esperando el failback. Esto es importante si se utilizan servicios, como LDAP y Active Directory, y se requiere acceso a otros recursos de red cuando el controlador no esté proporcionando servicio. Si esto no resulta práctico, el procesador de servicio debe estar conectado a una red confiable y/o a un concentrador terminal serie para que se pueda gestionar el controlador desde la consola del sistema.
Si no se realiza ninguna de estas acciones, es imposible gestionar o supervisar un controlador recientemente iniciado hasta que se complete el failback. Se recomienda supervisar o gestionar el controlador que proporciona el servicio para una agrupación de almacenamiento determinada. Es probable que esto sea útil cuando desee modificar algún aspecto del almacenamiento en sí, como una propiedad de un recurso compartido, o para crear un nuevo LUN. Para ello, se puede utilizar una de las interfaces de servicio para realizar tareas administrativas o se puede asignar una interfaz única independiente que se utilice solamente para gestionar la agrupación a la que fue asignada. Cualquiera sea el caso, la interfaz debe asignarse al mismo controlador que la agrupación que se utiliza para gestionar.
Impacto en los clientes de NFSv4.1: ciertos cambios de red en una configuración de cluster pueden afectar negativamente la prestación de servicios de solicitudes de clientes de NFSv4.1. Si la relación entre una dirección IP y su propietario cambia, la práctica recomendada es volver a montar el sistema de archivos desde el cliente. A diferencia de NFSv4.0, el protocolo NFSv4.1 permite que se asocien conexiones de clientes en varias direcciones IP con la misma concesión de protocolo NFSv4.1. Cuando cambia la relación entre una dirección IP y su propietario, el grupo de direcciones IP que realizan la conmutación por error juntas no es el mismo, lo cual obliga al cliente a restablecer las relaciones de concesión mediante un nuevo montaje de los sistemas de archivos.
Temas relacionados