D Panoramica dell'elettronica ridondante

La funzionalità opzionale di elettronica ridondante (RE, Redundant Electronics) fornisce protezione failover per il controller della libreria. In caso di errori al controller della libreria o dell'unità, le operazioni passeranno al controller in standby. I controller della libreria e dell'unità installati sullo stesso lato del supporto schede vengono sempre commutati in coppia.

RE consente a un rappresentante dell'assistenza Oracle di sostituire una scheda guasta mentre la libreria è connessa, con un impatto minimo sul funzionamento della libreria durante gli aggiornamenti del firmware.

Nota:

Qualsiasi riferimento a HBCR riguarda anche HBC.

Vedere anche

Requisiti dell'elettronica ridondante

  • Due schede del controller della libreria (HBCR)

  • Due schede del controller dell'unità (HBT)

    Nota:

    Per abilitare la modalità ADI, entrambe le schede devono essere HBT con molta memoria.

    Se si utilizza la convalida dei supporti, Oracle consiglia che entrambe le schede siano HBT con molta memoria.

  • Minimo SL8500 con firmware versione FRS_6.00 e SLC versione 4.65

  • File di attivazione dell'hardware abilitato mediante l'interfaccia CLI

Esempi di configurazione dell'elettronica ridondante

Ogni scheda del controller della libreria richiede un proprio indirizzo IP esclusivo. Per TCP/IP doppio, ogni scheda richiede due indirizzi IP univoci: uno per la porta primaria 2B e una per la porta secondaria 2A. Una libreria dotata di RE e TCP/IP doppio richiede pertanto quattro indirizzi IP univoci.

Su ciascuna scheda del controller, le porte 2B e 2A devono trovarsi su domini broadcast diversi. Tuttavia, la porta 2B sulla scheda attiva e la porta 2B sulla scheda in standby possono trovarsi nello stesso dominio broadcast. Lo stesso è vero per le porte 2A.

Figura D-1 Esempi di configurazione dell'elettronica ridondante

Il testo circostante descrive Figura D-1 .

Vedere anche Panoramica del TCP/IP doppio e Panoramica del TCP/IP multiplo.

Cosa si verifica durante un failover

In una scheda del controller del failover, il controller della libreria attivo tenta di completare tutti i job in corso e copia il database della cartuccia sulla scheda del controller in standby. Se il database non può essere copiato (in genere solo in caso di guasto improvviso), è necessario eseguire un controllo dopo failover (vedere Controllo della libreria). La libreria restituisce eventuali cartucce in transito ai rispettivi slot iniziali. La libreria posiziona tutte le cartucce che non riesce a restituire al rispettivo slot iniziale in uno slot di sistema per il recupero dell'host (consultare la documentazione del software dell'host).

Al termine o allo scadere del timeout di tutti i job in corso, i ruoli delle schede vengono commutati. Il controller in standby diventa attivo e il controller precedentemente attivo viene impostato in standby. Se il controller precedentemente attivo non può attivare il software in standby, il controller passa allo stato di errore.

Effetto di un failover sugli utenti

  • Gli utenti del software di gestione dei nastri (Symantec o Virtual Storage Manager) non avvertono alcuna interruzione.

  • Le applicazioni host HLI accodano le richieste durante il processo di failover per il completamento dopo la commutazione del failover. Per ACSLS, sono influenzate solo le richieste di installazione e disinstallazione (consultare la documentazione del software dell'host).

  • Le connessioni SLC e CLI vengono terminate. È necessario ristabilire le connessioni alla libreria utilizzando l'indirizzo IP o l'alias DNS del nuovo controller della libreria attivo (ossia il precedente controller in standby).

Fattori che impediscono una commutazione RE

  • Lo stato del controller della libreria o dell'unità in standby indica la presenza di un problema o lo stato di espulsione.

  • Il codice standby non è in esecuzione sulle schede del controller della libreria o dell'unità in standby.

  • È in corso il download del firmware o l'inizializzazione della scheda.

Fattori che avviano un failover automatico

Il failover automatico può essere avviato dal controller della libreria attivo o in standby.

Il controller della libreria attivo avvia un failover automatico nei casi indicati di seguito.

  • La scheda del controller dell'unità associata non è installata o non supporta la comunicazione.

  • Rileva un errore software interno irreversibile.

Il controller della libreria in standby avvia un failover automatico se determina che il controller attivo non funziona normalmente.

Modi per avviare un failover manuale

Prima di avviare una commutazione manuale, è opportuno accertarsi che i controller della libreria in standby e dell'unità funzionino normalmente. È possibile avviare una commutazione manuale utilizzando gli strumenti indicati di seguito.

  • Gestione nastri dell'host (ACSLS o ELS): il failover può essere avviato dal controller della libreria attivo o in standby. Il controller della libreria in standby accetta solo richieste HLI set host path group e force switchover.

  • SLC: il failover viene avviato solo dal controller della libreria attivo (vedere Avvio di una commutazione RE manuale mediante SLC).

  • CLI: un rappresentante dell'assistenza Oracle può avviare il failover dal controller della libreria attivo o in standby.

È possibile eseguire una commutazione manuale dopo l'installazione iniziale delle schede in standby, dopo un aggiornamento del firmware o periodicamente per controllare che la funzione di failover funzioni correttamente. Se non è possibile commutare manualmente i controller della libreria senza i controller dell'unità, in quanto i controller vengono sempre commutati in coppia.

Aggiornamenti del firmware con RE

Gli aggiornamenti del firmware per le librerie RE arrecano un disagio minimo al funzionamento della libreria. La libreria carica e decomprime il nuovo codice contemporaneamente sulle schede del controller attivo e in standby e su tutti i dispositivi. In seguito la libreria attiva il codice e inizializza di nuovo i controller e la maggior parte dei dispositivi. Nella maggior parte delle circostanze la libreria non esegue l'inizializzazione del robot.

Il caricamento, la decompressione e l'attivazione del codice non implicano disagi per il funzionamento della libreria fino a quando non viene eseguito il reboot. Durante il processo di reboot (che richiede circa 10 minuti), le applicazioni host (ACSLS ed ELS) accodano tutte le richieste di installazione e disinstallazione. Al termine del reboot, le richieste accodate vengono inviate al controller della libreria.

Per informazioni sul download e l'attivazione del firmware, vedere Aggiornamento del firmware della libreria.