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.

Errori di trasferimento aggregati

Collaboratori netapp-pcarriga netapp-aoife netapp-aherbin
PDF

Il trasferimento di aggregati (ARL) potrebbe non riuscire in diversi punti durante l'aggiornamento.

Verificare la presenza di errori di trasferimento degli aggregati

Durante la procedura, l'ARL potrebbe non funzionare nella fase 2, 3 o 5.

Fasi

  1. Immettere il seguente comando ed esaminare l'output:

    storage aggregate relocation show

    Il storage aggregate relocation show il comando mostra quali aggregati sono stati riallocati correttamente e quali no, insieme alle cause del guasto.

  2. Verificare la presenza di eventuali messaggi EMS nella console.

  3. Eseguire una delle seguenti operazioni:

    • Intraprendere l'azione correttiva appropriata, a seconda dell'output di storage aggregate relocation show E l'output del messaggio EMS.

    • Forzare il trasferimento dell'aggregato o degli aggregati utilizzando override-vetoes o il override-destination-checks opzione di storage aggregate relocation start comando.

    Per informazioni dettagliate sulle opzioni storage aggregate relocation start, override-vetoes e override-destination-checks, fare riferimento a "Riferimenti" per il collegamento al ONTAP 9 Command reference.

Gli aggregati originalmente sul node1 sono di proprietà del node4 dopo il completamento dell'upgrade

Al termine della procedura di aggiornamento, node3 deve essere il nuovo nodo home degli aggregati che in origine aveva node1 come nodo home. È possibile trasferirli dopo l'aggiornamento.

A proposito di questa attività

Gli aggregati potrebbero non riuscire a riallocare correttamente, avendo node1 come nodo principale invece di node3 nelle seguenti circostanze:

  • Durante la Fase 3, gli aggregati vengono spostati dal nodo2 al nodo3. Alcuni degli aggregati spostati hanno node1 come nodo home. Ad esempio, un aggregato di questo tipo potrebbe essere chiamato aggr_node_1. Se la rilocazione di aggr_node_1 fallisce durante la Fase 3 e la rilocazione non può essere forzata, allora l'aggregato rimane su node2.

  • Dopo la fase 4, quando il nodo2 viene sostituito con il nodo4. Quando il nodo2 viene sostituito, aggr_node_1 va online con il nodo4 come porta home invece del nodo3.

Una volta attivato il failover dello storage, è possibile risolvere il problema di proprietà non corretto dopo la fase 6, attenendosi alla seguente procedura:

Fasi

  1. immettere il seguente comando per ottenere un elenco di aggregati:

    storage aggregate show -nodes node4 -is-home true

    Per identificare gli aggregati che non sono stati correttamente ricollocati, fare riferimento all'elenco degli aggregati con il proprietario di casa del node1 ottenuto nella sezione "Preparare i nodi per l'aggiornamento" e confrontarlo con l'output del comando precedente.

  2. Confronta l'output di Fase 1 con l'output acquisito per node1 nella sezione "Preparare i nodi per l'aggiornamento" e annotare eventuali aggregati che non sono stati correttamente ricollocati.

  3. ricollocare gli aggregati rimasti al nodo4:

    storage aggregate relocation start -node node4 -aggr aggr_node_1 -destination node3

    Non utilizzare -ndo-controller-upgrade durante questa riallocazione.

  4. Immettere il seguente comando per verificare che node3 sia ora il proprietario domestico degli aggregati:

    storage aggregate show -aggregate aggr1,aggr2,aggr3…​ -fields home-name

    aggr1,aggr2,aggr3…​ è l'elenco degli aggregati che avevano il node1 come proprietario di casa originale.

    Gli aggregati che non hanno node3 come proprietario di casa possono essere ricollocati in node3 utilizzando lo stesso comando di rilocazione in Fase 3.