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à di node2 dopo il completamento dell'upgrade

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

A proposito di questa attività

Gli aggregati potrebbero non riuscire a riallocare correttamente, ovvero hanno node2 come nodo principale invece di node1, nelle seguenti circostanze:

  • Durante la fase 3, quando gli aggregati vengono ricollocati dal nodo 2 al nodo 1.

    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 viene lasciato indietro al nodo 2.

  • Dopo la fase 4, quando il node2 viene sostituito con i nuovi moduli di sistema.

    Quando node2 viene sostituito, aggr_node_1 verrà online con node1 come nodo home invece di node2.

È possibile risolvere il problema di proprietà errato dopo la fase 6, dopo aver attivato il failover dello storage, completando la seguente procedura:

Fasi

  1. Ottieni un elenco di aggregati:

    storage aggregate show -nodes node2 -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. Confrontare l'output del passaggio 1 con l'output acquisito per il nodo 1 nella sezione "Preparare i nodi per l'aggiornamento" e annotare eventuali aggregati che non sono stati correttamente ricollocati.

  3. Spostare gli aggregati rimasti sul nodo 2:

    storage aggregate relocation start -node node2 -aggr aggr_node_1 -destination node1

    Non utilizzare il parametro -ndo-controller-upgrade durante questo trasferimento.

  4. Verificare che node1 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 node1 come proprietario di casa possono essere ricollocati in node1 utilizzando lo stesso comando di rilocazione nella fase 3.