Skip to main content
La versione in lingua italiana fornita proviene da una traduzione automatica. Per eventuali incoerenze, fare riferimento alla versione in lingua inglese.

Spegni il controller FAS2700 per sostituire lo chassis

Collaboratori netapp-jsnyder
PDF

Arresta o prendi il controllo del controller compromesso nel tuo sistema FAS2700 utilizzando la procedura appropriata per la tua configurazione prima di sostituire lo chassis.

Opzione 1: La maggior parte delle configurazioni

Questa procedura si applica ai sistemi con configurazioni a due nodi. Per ulteriori informazioni sull'arresto regolare durante la manutenzione di un cluster, vedere "Shutdown anomalo e accendere il sistema storage System Resolution Guide - NetApp Knowledge base".

Prima di iniziare

  • Assicurarsi di disporre delle autorizzazioni e delle credenziali necessarie:

    • Credenziali dell'amministratore locale per ONTAP.

    • Accessibilità del BMC per ciascun controller.

  • Assicurarsi di disporre degli strumenti e delle attrezzature necessarie per la sostituzione.

Fasi

  1. Accedere al cluster tramite SSH o da qualsiasi nodo del cluster utilizzando un cavo della console locale e un laptop/console.

  2. Impedire a tutti i client/host di accedere ai dati sul sistema NetApp.

  3. Sospendere i processi di backup esterni.

  4. Se AutoSupport è abilitato, sospendere la creazione di casi e indicare per quanto tempo si prevede che il sistema sia offline:

    system node autosupport invoke -node * -type all -message "MAINT=2h Replace chassis"

  5. Identificare l'indirizzo SP/BMC di tutti i nodi del cluster:

    system service-processor show -node * -fields address

  6. Uscire dalla shell del cluster:

    exit

  7. Accedere allo SP/BMC di ciascun controller utilizzando l'indirizzo IP identificato nel passaggio precedente:

    • Se si accede dal BMC tramite SSH, connettersi utilizzando l'indirizzo SP/BMC (ad esempio, ssh admin@<SP/BMC_address>), quindi immettere il comando system console e autenticarsi.

    • Se si utilizza una console locale o un laptop collegato direttamente al controller, accedere utilizzando le stesse credenziali dell'amministratore del cluster.

  8. Arrestare i due nodi situati nel telaio danneggiato:

    system node halt -node <node1>,<node2> -skip-lif-migration-before-shutdown true -ignore-quorum-warnings true -inhibit-takeover true

    Nota Per i cluster che utilizzano SnapMirror Synchronous che operano in modalità StrictSync: system node halt -node <node1>,<node2> -skip-lif-migration-before-shutdown true -ignore-quorum-warnings true -inhibit-takeover true -ignore-strict-sync-warnings true

  9. Immettere y per ciascun controller nel cluster quando viene visualizzato:

    Warning: Are you sure you want to halt node <node_name>? {y|n}:

  10. Attendere che ogni controller si arresti e visualizzi il prompt DEL CARICATORE.

Opzione 2: Il controller è in una configurazione MetroCluster

Nota Non utilizzare questa procedura se il sistema si trova in una configurazione MetroCluster a due nodi.

Prendere il controllo e arrestare il controller non funzionante in modo che il controller funzionante continui a fornire dati dalla memoria del controller non funzionante. Per fare questo, si sopprime la creazione automatica dei casi in AutoSupport, si disabilita il giveback automatico e si porta il controller non funzionante al prompt LOADER. Il prompt LOADER è lo stato di arresto sicuro da cui è possibile sostituire la FRU.

  • Se si dispone di un cluster con più di due nodi, questo deve trovarsi in quorum. Se il cluster non è in quorum o un controller integro mostra false per idoneità e salute, è necessario correggere il problema prima di spegnere il controller compromesso; vedere "Sincronizzare un nodo con il cluster".

  • Se si dispone di una configurazione MetroCluster, è necessario confermare che lo stato di configurazione MetroCluster è configurato e che i nodi sono in uno stato abilitato e normale (metrocluster node show).

Fasi

  1. Se AutoSupport è attivato, eliminare la creazione automatica del caso richiamando un messaggio AutoSupport:

    system node autosupport invoke -node * -type all -message MAINT=<number of hours down>h

    Ciò impedisce l'apertura automatica di richieste di assistenza durante la finestra di manutenzione. La durata massima della soppressione è di 72 ore. Se la manutenzione termina prima del termine, è possibile riattivare la creazione di richieste di assistenza richiamando un AutoSupport messaggio con MAINT=END. Per ulteriori informazioni, consultare "Come disabilitare la creazione automatica di casi durante le finestre di manutenzione programmate".

    Il seguente messaggio AutoSupport elimina la creazione automatica del caso per due ore:

    cluster1:*> system node autosupport invoke -node * -type all -message MAINT=2h

  2. Disattivare il giveback automatico dalla console del controller integro: storage failover modify –node local -auto-giveback false

  3. Portare la centralina danneggiata al prompt DEL CARICATORE:

    Se il controller non utilizzato visualizza…​ Quindi…​

    Il prompt DEL CARICATORE

    Passare alla fase successiva.

    In attesa di un giveback…​

    Premere Ctrl-C, quindi rispondere y quando richiesto.

    Prompt di sistema o prompt della password (inserire la password di sistema)

    Assumere il controllo o arrestare il controller compromesso dal controller integro: storage failover takeover -ofnode impaired_node_name

    Quando il controller non utilizzato visualizza Waiting for giveback…​ (in attesa di giveback…​), premere Ctrl-C e rispondere y.