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
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 su storage aggregate relocation start, override-vetoes, e. override-destination-checks opzioni, fare riferimento a. "Riferimenti" Per collegarsi ai comandi di ONTAP 9: Manuale riferimento pagina.

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, quando gli aggregati vengono ricollocati dal nodo 2 al nodo 3. Alcuni degli aggregati che vengono ricollocati hanno node1 come nodo principale. Ad esempio, un tale aggregato potrebbe essere chiamato aggr_node_1. Se il trasferimento di aggr_node_1 non riesce durante la fase 3 e non è possibile forzare il trasferimento, l'aggregato verrà lasciato indietro al nodo 2.

  • Dopo la fase 4, quando il node2 viene sostituito con il node4. Quando node2 viene sostituito, aggr_node_1 verrà online con node4 come nodo home invece di node3.

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.