D Visión general de Redundant Electronics

La función Redundant Electronics (RE) opcional proporciona protección contra la conmutación por error para el controlador de biblioteca. Si se producen errores en el controlador de biblioteca o de unidad, las operaciones se trasladan al controlador en espera. El controlador de biblioteca y el controlador de unidad instalados en el mismo lado de la caja de tarjetas siempre se conmutan como un par.

RE permite que un representante de soporte de Oracle reemplace una tarjeta defectuosa mientras la biblioteca está en línea y reduce al mínimo la interrupción durante las actualizaciones de firmware.

Nota:

Cualquier referencia a HBCR también hace referencia a HBC.

Consulte también:

Requisitos de Redundant Electronics

  • Dos tarjetas de controlador de biblioteca (HBCR)

  • Dos tarjetas de controlador de unidad (HBT)

    Nota:

    Para activar el modo ADI, ambas tarjetas deben ser HBT con gran capacidad de memoria.

    Si utiliza la validación de medios, Oracle recomienda que ambas tarjetas sean HBT de gran capacidad de memoria.

  • Versión mínima de firmware de SL8500 FRS_6.00 y SLC versión 4.65

  • Archivo de activación de hardware activado mediante la CLI

Ejemplos de configuración de Redundant Electronics

Cada tarjeta de controlador de biblioteca requiere una dirección IP única. Para TCP/IP dual, cada tarjeta requiere dos direcciones IP únicas: una para el puerto principal 2B y una para el puerto secundario 2A. Por lo tanto, una biblioteca equipada con RE y TCP/IP dual requiere cuatro direcciones IP únicas.

En cada tarjeta de controlador, el puerto 2B y el puerto 2A deben estar en distintos dominios de difusión. Sin embargo, el puerto 2B en la tarjeta activa y el puerto 2B en la tarjeta en espera pueden estar en el mismo dominio de difusión. Lo mismo se aplica para los puertos 2A.

Figura D-1 Ejemplos de configuración de Redundant Electronics

El texto adyacente describe Figura D-1 .

Consulte también: Visión general de TCP/IP dual y Visión general de TCP/IP múltiple.

Qué ocurre durante una conmutación por error

En una conmutación por error de la tarjeta de controlador, el controlador de biblioteca activo intenta completar todos los trabajos en curso y copia la base de datos de cartuchos a la tarjeta de controlador en espera. Si la base de datos no puede copiarse (por lo general, únicamente en caso de fallo repentino), debe realizar una auditoría después de que se completa la conmutación por error (consulte Auditoría de la biblioteca). La biblioteca devuelve los cartuchos en tránsito a las ranuras de origen. La biblioteca coloca los cartuchos que no puede devolver a una ranura de origen en una ranura del sistema para la recuperación del host (consulte la documentación de software del host).

Una vez que se completan o se produce un timeout de todos los trabajos en curso, los roles de las tarjetas cambian. El controlador en espera pasa a estar activo y el controlador anteriormente activo pasa a estar en espera. Si el controlador anteriormente activo no puede activar el software en espera, el controlador pasa a tener un estado de fallo.

Efecto de una conmutación por error sobre los usuarios

  • Los usuarios del software de gestión de cintas (Symantec o Virtual Storage Manager) no perciben ninguna interrupción.

  • Las aplicaciones host HLI ponen en cola las solicitudes durante el proceso de conmutación por error para completarlas tras la conmutación por error. Para ACSLS, únicamente se ven afectadas las solicitudes de montaje y desmontaje (consulte la documentación de software del host).

  • Finalizan las conexiones de SLC y CLI. Debe restablecer las conexiones con la biblioteca utilizando la dirección IP o el alias de DNS del nuevo controlador de biblioteca activo (el controlador anteriormente en espera).

Factores que impiden la conmutación de RE

  • El controlador de biblioteca o unidad en espera se encuentra en estado de fallo o expulsión.

  • El código en espera no se está ejecutando en las tarjetas de controlador de biblioteca o unidad en espera.

  • Hay una descarga de firmware o una inicialización de tarjetas en curso.

Factores que inician una conmutación por error automática

La conmutación por error automática se puede iniciar desde el controlador de biblioteca activo o en espera.

El controlador de biblioteca activo inicia una conmutación por error automática cuando:

  • La tarjeta de controlador de unidad asociada no está instalada o no se está comunicando.

  • Detecta un error de software interno grave.

El controlador de biblioteca en espera inicia una conmutación por error automática si el controlador activo no funciona normalmente.

Maneras de iniciar una conmutación por error manual

Antes de iniciar una conmutación manual, debe verificar que los controladores de biblioteca y de unidad en espera se ejecuten normalmente. Puede iniciar una conmutación manual mediante lo siguiente:

  • Gestión de cintas de host (ACSLS o ELS): la conmutación por error se puede iniciar desde el controlador de biblioteca activo o en espera. El controlador de biblioteca en espera acepta únicamente las solicitudes HLI set host path group y force switchover.

  • SLC: la conmutación por error se inicia desde el controlador de biblioteca activo únicamente (consulte Inicio de una conmutación manual de RE mediante SLC).

  • CLI: un representante de soporte de Oracle puede iniciar la conmutación por error desde el controlador de biblioteca activo o en espera.

Puede realizar una conmutación manual después de la instalación inicial de las tarjetas en espera, después de una actualización de firmware o periódicamente para comprobar que la función de conmutación por error funciona correctamente. No es posible conmutar manualmente los controladores de biblioteca sin los controladores de unidad (los controladores siempre se conmutan como un par).

Actualizaciones de firmware con RE

Las actualizaciones de firmware para las bibliotecas con RE causan una interrupción mínima de las operaciones de la biblioteca. La biblioteca carga y desempaqueta un código nuevo simultáneamente en las tarjetas de controlador activo y en espera, y en todos los dispositivos. A continuación, la biblioteca activa el código y vuelve a inicializar los controladores y la mayoría de los dispositivos. En la mayoría de los casos, la biblioteca omite la inicialización del robot.

Las operaciones de carga, desempaquetado y activación del código no afectan las operaciones de la biblioteca hasta que esta se reinicia. Durante el proceso de reinicio (que dura aproximadamente 10 minutos), las aplicaciones host (ACSLS y ELS) ponen en cola todas las solicitudes de montaje y desmontaje. Una vez finalizado el reinicio, las solicitudes en cola se envían al controlador de biblioteca.

Consulte Actualización de firmware de la biblioteca para obtener información sobre la descarga de firmware y la activación.