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 nodos principales 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.

Figura 2-23  Agrupación en clusters para redes

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 nodo a la vez. De manera similar, los dispositivos correspondientes de cada nodo deben estar conectados a las mismas redes para que el servicio se proporcione en un estado conmutado por error. En el diagrama previo se muestra un ejemplo.

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 nodos. Como los identificadores de los dispositivos dependen del tipo de dispositivo y el orden en el que el dispositivo los detectó originalmente, los nodos principales en clusters DEBEN tener instalado hardware idéntico. Cada una de las ranuras de ambos nodos debe completarse con hardware idéntico y se las debe completar en el mismo orden en ambos nodos. 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. En el gestor de recursos las rutas se representan como simbiontes y pueden pasar al modo activo solo cuando las interfaces a las que están vinculadas están en estado operativo. Por lo tanto, una ruta vinculada a una interfaz que actualmente está en el modo de energía en espera (exportada) no tiene efecto hasta que se active 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 un enrutador que es utilizado por los dispositivos para alcanzar una o varias redes adicionales, se debe configurar una ruta separada (por ejemplo, una segunda ruta predeterminada) y se la 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 nodo principal de los clusters (probablemente sobre una red de gestión dedicada) y designar la interfaz como recurso privado. Esto garantiza que sea posible alcanzar un nodo 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 nodo no esté proporcionando el 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 nodo desde la consola del sistema.

Si no se realiza ninguna de estas acciones, es imposible gestionar o supervisar un nodo recientemente iniciado hasta que se complete el failback. Tal vez sea conveniente supervisar o gestionar el nodo principal que proporciona el servicio para una agrupación de almacenamiento en particular. Es probable que sea útil cuando desee modificar algún aspecto del almacenamiento en sí, por ejemplo, modificar una propiedad de un recurso compartido o 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 nodo que la agrupación que se utiliza para gestionar.