Omitir Vínculos de navegación | |
Salir de la Vista de impresión | |
![]() |
Guía de administración de Oracle® ZFS Storage Appliance |
Capítulo 1 Descripción general de Oracle ZFS Storage Appliance
Capítulo 3 Configuración inicial
Capítulo 4 Configuración de red
Capítulo 5 Configuración del almacenamiento
Capítulo 6 Configuración de red de área de almacenamiento
Capítulo 7 Configuración de usuario
Capítulo 8 Configuración de preferencias de dispositivos ZFSSA
Capítulo 9 Configuración de alertas
Capítulo 10 Configuración de cluster
Características y ventajas de los clusters
Descripción de la agrupación en clusters
E/S de interconexión del cluster
Descripción de gestión de recursos del cluster
Toma de control y failback en clusters
Cambios de configuración en un entorno en cluster
Consideraciones de la agrupación en clusters para almacenamiento
Interfaces IP locales privadas
Consideraciones de la agrupación en clusters para InfiniBand
Situaciones de ruta redundante de agrupación en clusters
Estimación y reducción del impacto de la toma de control
Configuración de clusters con la BUI
Configuración de agrupaciones en clusters
Desconfiguración de una agrupación en clusters
Configuración de agrupaciones en clusters con la CLI
Cierre de una configuración en clusters
Cierre del nodo principal en espera
Desconfiguración de una agrupación en clusters
Cableado de clusters ZS3-4 y 7x20
Cableado de estantes de almacenamiento
Página de configuración de clusters de la BUI
Capítulo 11 Servicios del dispositivo ZFSSA
Capítulo 12 Recursos compartidos, proyectos y esquemas
Capítulo 15 Secuencias de comandos de la CLI
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 10-5 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 sólo 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 sólo 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.