Omitir vínculos de navegación | |
Salir de la Vista de impresión | |
![]() |
Guía de administración de Oracle® ZFS Storage Appliance, versión 2013.1.3.0 |
Acerca de Oracle ZFS Storage Appliance
Configuración de Oracle ZFS Storage Appliance
Configuración inicial del dispositivo
Configuración inicial con la BUI
Configuración inicial mediante el uso de la CLI
Trabajo con la página de configuración de red de la BUI
Configuración de dispositivos de red
Configuración de enlaces de datos de red
Configuración de interfaces de red
Configuración de rutas múltiples de redes IP (IPMP)
Configuración de rendimiento y disponibilidad de red
Configuración de enrutamiento de red
Configuración de redes con la BUI
Creación de una interfaz con un solo puerto mediante el uso de la BUI
Modificación de una interfaz con la BUI
Creación de una interfaz con un solo puerto mediante el uso de la BUI
Creación de una interfaz de enlaces agregados de LACP mediante el uso de la BUI
Creación de un grupo IPMP mediante la detección de fallos por estado del enlace y basada en sondeos
Creación de un grupo IPMP mediante la detección de fallos por estado del enlace únicamente
Ampliación de una agregación de LACP con la BUI
Ampliación de un grupo IPMP con la BUI
Creación de una interfaz y un enlace de datos de partición InfiniBand con la BUI
Creación de una VNIC sin un ID de VLAN para controladores en clusters mediante el uso de la BUI
Creación de VNIC con el mismo ID de VLAN para controladores en clusters mediante el uso de la BUI
Agregación de una ruta estática con la BUI
Supresión de una ruta estática con la BUI
Configuración de redes con la CLI
Agregación de una ruta estática mediante el uso de la CLI
Supresión de una ruta estática mediante el uso de la CLI
Cambio de la propiedad de hosts de conexión múltiple a estricto con la CLI
Configuración del almacenamiento
Selección de un perfil de almacenamiento
Configuración de perfiles de datos
Importación de grupos de almacenamiento existentes
Desconfiguración del almacenamiento
Cambio de nombre de una agrupación de almacenamiento
Limpieza de agrupaciones de almacenamiento
Configuración de una agrupación de almacenamiento con la BUI
Agregación de dispositivos de caché a una agrupación existente con la BUI
Agregación de dispositivos de caché a una agrupación existente con la CLI
Descripción del estado del dispositivo
Panel de control de actividad de disco
Ejecución continua del panel de control
Configuración del panel de control de estado
Modificación de las estadísticas de las actividades desplegadas
Modificación de los umbrales de las actividades
Configuración de red de área de almacenamiento
Configuración de canal de fibra de SAN
Configuración de modo de los puertos FC con la BUI
Detección de puertos FC con la BUI
Creación de grupo de iniciadores FC con la BUI
Asociación de un LUN con un grupo de iniciadores FC con la BUI
Cambio de modo de los puertos FC con la CLI
Detección de puertos FC con la CLI
Creación de grupo de iniciadores FC con la CLI
Asociación de un LUN con un grupo de iniciadores FC con la CLI
Asignación de alias a iniciadores y grupos de iniciadores mediante secuencias de comandos con la CLI
Configuración de iniciadores iSCSI de SAN
Creación de una hoja de trabajo de análisis con la BUI
Configuración de destinos iSER de SAN
Agregación de un destino iSCSI con un IQN generado automáticamente con la CLI
Agregación de un destino iSCSI con un IQN específico y autenticación RADIUS con la CLI
Agregación de iniciador iSCSI con autenticación CHAP mediante el uso de la CLI
Agregación de un grupo de destinos iSCSI con la CLI
Agregación de un grupo de iniciadores iSCSI con la CLI
Configuración de destino SRP con la BUI
Configuración de destino SRP con la CLI
Administración de propiedades de usuario
Agregación de un administrador con la BUI
Agregación de un rol con la BUI
Agregación de autorizaciones a un rol con la BUI
Supresión de autorizaciones de un rol con la BUI
Agregación de un usuario que pueda ver solamente el panel de control mediante el uso de la BUI
Agregación de un rol con la CLI
Agregación de un administrador con la CLI
Agregación de autorizaciones a un rol con la CLI
Supresión de autorizaciones de un rol con la CLI
Configuración de preferencias de Oracle ZFS Storage Appliance
Configuración de preferencias con la CLI
Configuración de claves SSH públicas con la CLI
Agregación de una alerta de umbral con la BUI
Agregación de una acción de alerta con la BUI
Agregación de una alerta de umbral con la CLI
Agregación de una acción de alerta con la CLI
Envío de alertas por correo electrónico
Reanudación/suspensión de conjunto de datos
Reanudación/suspensión de hoja de trabajo
Ejecución de un flujo de trabajo
Configuración de agrupaciones en clusters
Descripción de la agrupación en clusters
Ventajas y desventajas de los clusters
E/S de interconexión del cluster
Gestión de recursos de clusters
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
Consideraciones de la agrupación en clusters para redes
Interfaces IP locales privadas
Consideraciones de la agrupación en clusters para InfiniBand
Estimación y reducción del impacto de la toma de control
Configuración de agrupación en clusters con la BUI
Desconfiguración de agrupación en clusters con la BUI
Cierre de una configuración en clusters con la CLI
Cierre del nodo principal en espera con la CLI
Desconfiguración de agrupaciones en clusters con la CLI
Cableado de clusters ZS4-4, ZS3-4 y 7x20
Cableado de estantes de almacenamiento para agrupación en clusters
Mantenimiento de Oracle ZFS Storage Appliance
Trabajo con recursos compartidos
Integración de aplicaciones con Oracle ZFS Storage Appliance
Un modo de fallo común en los sistemas en clusters es el que se conoce como separación de redes (split-brain), donde cada uno de los nodos principales en clusters cree que su par ha fallado e intenta tomar el control. Sin lógica adicional, esta condición puede causar una amplia gama de comportamientos inesperados y destructivos cuyo diagnóstico o corrección pueden ser difíciles. El disparador canónico de esta condición es el fallo del medio de comunicación compartido entre los nodos principales; en el caso de Oracle ZFS Storage Appliance, esto ocurriría si se produjera un fallo en los enlaces de E/S del cluster. Además de la redundancia incorporada de enlace triple (se necesita solo un enlace para evitar que se active la toma de control), el software del dispositivo también realiza un procedimiento de arbitraje para determinar cuál es el nodo que debe continuar con la toma de control.
Hay una serie de mecanismos de arbitraje que son utilizados por productos similares; normalmente requieren el uso de discos de quórum (que usan reservas SCSI) o servidores de quórum. Para que sea posible utilizar discos ATA sin necesidad de hardware adicional, Oracle ZFS Storage Appliance utiliza un enfoque diferente que recurre al tejido del almacenamiento en sí para proporcionar la exclusividad mutua requerida. El proceso de arbitraje consiste en intentar ejecutar un comando SAS ZONE LOCK en cada uno de los expansores SAS visibles en el tejido de almacenamiento, en un orden predefinido. El dispositivo que logre obtener correctamente todos los bloqueos tomará el control, mientras que el otro se restablecerá de manera automática. Como un dispositivo en clusters que se inicia y detecta que no se puede comunicar con su par intenta tomar el control y llevar a cabo el mismo proceso de arbitraje, se restablecerá continuamente hasta que se restaure al menos uno de los enlaces de E/S del cluster. Esto garantiza que un fallo subsiguiente del otro nodo no ocasione una interrupción prolongada. Estos bloqueos de la zona SAS se liberan cuando se realiza la operación de failback o aproximadamente 10 segundos desde que el nodo cuyo estado es AKCS_OWNER renueva su propio acceso al tejido de almacenamiento.
Este mecanismo de arbitraje es simple, económico y no requiere hardware adicional, pero requiere que los dos dispositivos en clusters tengan acceso al menos a un expansor SAS común en el tejido de almacenamiento. En condiciones normales, cada dispositivo tiene acceso a todos los expansores, de manera que el arbitraje consistirá en la toma de al menos dos bloqueos de zona SAS. Sin embargo, es posible concebir situaciones de fallos múltiples en las que los dispositivos no tienen acceso a ningún expansor común. Por ejemplo, si se extraen dos de los cables SAS o si se apaga un estante de discos, cada dispositivo tendrá acceso a subconjuntos separados de expansores. En este caso, cada dispositivo podrá bloquear correctamente todos los expansores a los que tiene acceso, concluirá que el par ha fallado e intentará proceder con la toma de control. Esto puede generar bloqueos irrecuperables debido a conflictos de afiliación de discos y/o daño grave de los datos.
Tenga en cuenta que si bien las consecuencias de esta condición son graves, se puede producir solamente si hay varios fallos (con frecuencia solo en el caso de 4 fallos o más). La solución de agrupación en clusters incrustada en Oracle ZFS Storage Appliance está diseñada para garantizar que no haya un único punto de fallo y proteger tanto los datos como la disponibilidad contra todo fallo posible sin agregar costos ni complejidad innecesarios en el sistema. Sigue siendo posible que se produzcan varios fallos masivos que ocasionen la pérdida de servicio o datos, de la misma manera en la que ningún diseño RAID puede proteger contra una cantidad ilimitada de fallos de discos.
Figura 2-26 Prevención de separación de redes
Afortunadamente, la mayoría de estas situaciones de fallo se producen a causa de errores humanos y son completamente prevenibles con la instalación correcta del hardware y la capacitación del personal en relación con las mejores prácticas para la configuración y la gestión de clusters. Los administradores deben asegurarse siempre que los tres enlaces de E/S del cluster estén conectados y funcionen (como se muestra en la ilustración) y que todos los cables del almacenamiento estén conectados como se muestra en el diagrama de configuración que se incluye con los dispositivos. Es particularmente importante que se detecten dos rutas a cada estante de discos (como se muestra en la ilustración) antes de pasar el cluster a producción y que esas rutas estén disponibles en todo momento de allí en más, con la excepción evidente de cambios transitorios de cables para aumentar la capacidad o reemplazar componentes con fallos. Los administradores deben utilizar alertas para supervisar el estado de los enlaces de interconexión del cluster y las rutas de los estantes de discos, y para corregir con rapidez los fallos que puedan producirse. Garantizando la conectividad adecuada, se protege tanto la disponibilidad como la integridad de los datos si falla algún componente de hardware o software.
Figura 2-27 Dos rutas en un cluster