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

Preparare i nodi per l'aggiornamento

12/06/2024 Collaboratori

PDF

Prima di poter sostituire i nodi originali, è necessario verificare che si trovino in una coppia ha, che non vi siano dischi mancanti o guasti, che possano accedere reciprocamente allo storage e che non dispongano di LIF dati assegnati agli altri nodi del cluster. È inoltre necessario raccogliere informazioni sui nodi originali e, se il cluster si trova in un ambiente SAN, confermare che tutti i nodi del cluster sono in quorum.

Fasi

Verificare che ciascuno dei nodi originali disponga di risorse sufficienti per supportare adeguatamente il carico di lavoro di entrambi i nodi durante la modalità Takeover.

Fai riferimento "Riferimenti"al link gestione coppia ha e segui la sezione Best practice per coppie ha. Nessuno dei nodi originali deve essere eseguito con un utilizzo superiore al 50%; se un nodo viene eseguito con un utilizzo inferiore al 50%, può gestire i carichi per entrambi i nodi durante l'aggiornamento del controller.

Completare i seguenti passaggi secondari per creare una linea di base delle performance per i nodi originali:

Assicurarsi che l'account utente diagnostico sia sbloccato.

L'account utente diagnostico è destinato esclusivamente a scopi diagnostici di basso livello e deve essere utilizzato solo con le indicazioni del supporto tecnico.

Per informazioni sullo sblocco degli account utente, fare riferimento a. "Riferimenti" Per collegarsi al System Administration Reference.

Fare riferimento a. "Riferimenti" Per collegarsi al sito di supporto NetApp e scaricare il modulo di raccolta delle performance e delle statistiche (Perfstat Converged).

Il tool Perfstat Converged consente di stabilire una linea di base per le performance da confrontare dopo l'aggiornamento.
Creare una linea di base per le performance seguendo le istruzioni sul NetApp Support Site.

Fare riferimento a. "Riferimenti" Per collegarsi al sito di supporto NetApp e aprire un caso di supporto sul sito di supporto NetApp.

È possibile utilizzare il caso per segnalare eventuali problemi che potrebbero verificarsi durante l'aggiornamento.
Verificare che le batterie NVMEM o NVRAM del nodo 3 e del nodo 4 siano cariche e, in caso contrario, ricaricarle.

Controllare fisicamente il n. 3 e il n. 4 per verificare se le batterie NVMEM o NVRAM sono cariche. Per informazioni sui LED per il modello di node3 e node4, fare riferimento a. "Riferimenti" Per collegarsi a Hardware Universe.

Attenzione non tentare di cancellare il contenuto della NVRAM. Se è necessario eliminare il contenuto della NVRAM, contattare il supporto tecnico di NetApp.
Controllare la versione di ONTAP su node3 e node4.

Sui nuovi nodi deve essere installata la stessa versione di ONTAP 9.x installata sui nodi originali. Se nei nuovi nodi è installata una versione diversa di ONTAP, è necessario eseguire il netboot dei nuovi controller dopo averli installati. Per istruzioni su come aggiornare ONTAP, fare riferimento a. "Riferimenti" Collegamento a Upgrade ONTAP.

Le informazioni sulla versione di ONTAP su node3 e node4 devono essere incluse nelle confezioni di spedizione. La versione di ONTAP viene visualizzata all'avvio del nodo oppure è possibile avviare il nodo in modalità di manutenzione ed eseguire il comando:

version

Controllare se sono presenti due o quattro LIF del cluster su node1 e node2:

network interface show -role cluster

Il sistema visualizza tutte le LIF del cluster, come mostrato nell'esempio seguente:

cluster::> network interface show -role cluster
        Logical    Status     Network          Current  Current Is
Vserver Interface  Admin/Oper Address/Mask     Node     Port    Home
------- ---------- ---------- ---------------- -------- ------- ----
node1
        clus1      up/up      172.17.177.2/24  node1    e0c     true
        clus2      up/up      172.17.177.6/24  node1    e0e     true
node2
        clus1      up/up      172.17.177.3/24  node2    e0c     true
        clus2      up/up      172.17.177.7/24  node2    e0e     true

Se si dispone di due o quattro LIF del cluster su node1 o node2, assicurarsi di poter eseguire il ping di entrambe le LIF del cluster in tutti i percorsi disponibili completando i seguenti passaggi secondari:

Immettere il livello di privilegio avanzato:

set -privilege advanced

Il sistema visualizza il seguente messaggio:

Warning: These advanced commands are potentially dangerous; use them only when directed to do so by NetApp personnel.
Do you wish to continue? (y or n):

Invio y.
Eseguire il ping dei nodi e verificare la connettività:

cluster ping-cluster -node node_name

Il sistema visualizza un messaggio simile al seguente esempio:

cluster::*> cluster ping-cluster -node node1
Host is node1
Getting addresses from network interface table...
Local = 10.254.231.102 10.254.91.42
Remote = 10.254.42.25 10.254.16.228
Ping status:
...
Basic connectivity succeeds on 4 path(s) Basic connectivity fails on 0 path(s)
................
Detected 1500 byte MTU on 4 path(s):
Local 10.254.231.102 to Remote 10.254.16.228
Local 10.254.231.102 to Remote 10.254.42.25
Local 10.254.91.42 to Remote 10.254.16.228
Local 10.254.91.42 to Remote 10.254.42.25
Larger than PMTU communication succeeds on 4 path(s)
RPC status:
2 paths up, 0 paths down (tcp check)
2 paths up, 0 paths down (udp check)

+
Se il nodo utilizza due porte del cluster, si dovrebbe vedere che è in grado di comunicare su quattro percorsi, come mostrato nell'esempio.

Tornare al privilegio di livello amministrativo:

set -privilege admin

Verificare che node1 e node2 si trovino in una coppia ha e che i nodi siano collegati tra loro e che sia possibile effettuare il takeover:

storage failover show

L'esempio seguente mostra l'output quando i nodi sono collegati tra loro ed è possibile effettuare il takeover:
```
cluster::> storage failover show
                              Takeover
Node           Partner        Possible State Description
-------------- -------------- -------- -------------------------------
node1          node2          true     Connected to node2
node2          node1          true     Connected to node1
```
Nessuno dei due nodi deve essere in giveback parziale. L'esempio seguente mostra che node1 è in giveback parziale:
```
cluster::> storage failover show
                              Takeover
Node           Partner        Possible State Description
-------------- -------------- -------- -------------------------------
node1          node2          true     Connected to node2, Partial giveback
node2          node1          true     Connected to node1
```
Se uno dei nodi è in un giveback parziale, utilizzare storage failover giveback il comando per eseguire il giveback e quindi utilizzare storage failover show-giveback il comando per assicurarsi che non venga restituito alcun aggregato. Per informazioni dettagliate sui comandi, fare riferimento al "Riferimenti"link a ha Pair Management.
Conferma che né node1 né node2 possiedono gli aggregati per i quali sono il proprietario corrente (ma non il proprietario domestico):

storage aggregate show -nodes node_name -is-home false -fields owner-name, home-name, state

Se né node1 né node2 possiedono aggregati per i quali è il proprietario corrente (ma non il proprietario domestico), il sistema restituirà un messaggio simile al seguente esempio:
```
cluster::> storage aggregate show -node node2 -is-home false -fields owner-name,homename,state
There are no entries matching your query.
```
L'esempio seguente mostra l'output del comando per un nodo denominato node2 che è il proprietario di casa, ma non il proprietario corrente, di quattro aggregati:
```
cluster::> storage aggregate show -node node2 -is-home false
               -fields owner-name,home-name,state

aggregate     home-name    owner-name   state
------------- ------------ ------------ ------
aggr1         node1        node2        online
aggr2         node1        node2        online
aggr3         node1        node2        online
aggr4         node1        node2        online

4 entries were displayed.
```
Eseguire una delle seguenti operazioni:

Se il comando è in Fase 9… Quindi…

Con output vuoto

Saltare il passaggio 11 e passare a. Fase 12.

Ha avuto output

Passare a. Fase 11.
se node1 o node2 possiede aggregati per i quali è il proprietario corrente, ma non il proprietario della casa, completare i seguenti passaggi secondari:
1. Restituire gli aggregati attualmente di proprietà del nodo partner al nodo home owner:
  
  storage failover giveback -ofnode home_node_name
2. Verificare che né node1 né node2 possiedano ancora aggregati per i quali è il proprietario corrente (ma non il proprietario domestico):
  
  storage aggregate show -nodes node_name -is-home false -fields owner-name, home-name, state
  
  L'esempio seguente mostra l'output del comando quando un nodo è sia il proprietario corrente che il proprietario domestico degli aggregati:
```
cluster::> storage aggregate show -nodes node1
          -is-home true -fields owner-name,home-name,state

aggregate     home-name    owner-name   state
------------- ------------ ------------ ------
aggr1         node1        node1        online
aggr2         node1        node1        online
aggr3         node1        node1        online
aggr4         node1        node1        online

4 entries were displayed.
```
verificare che node1 e node2 possano accedere reciprocamente allo storage e verificare che non manchino dischi:

storage failover show -fields local-missing-disks,partner-missing-disks

L'esempio seguente mostra l'output quando non mancano dischi:
```
cluster::> storage failover show -fields local-missing-disks,partner-missing-disks

node     local-missing-disks partner-missing-disks
-------- ------------------- ---------------------
node1    None                None
node2    None                None
```
Se mancano dei dischi, fare riferimento al "Riferimenti"collegamento alla gestione disco e aggregato con la CLI, alla gestione logica dello storage con la CLI e alla gestione coppia ha per configurare lo storage per la coppia ha.

Se il comando è in Fase 9…	Quindi…
Con output vuoto	Saltare il passaggio 11 e passare a. Fase 12.
Ha avuto output	Passare a. Fase 11.

Verificare che node1 e node2 siano integri e idonei a partecipare al cluster:

cluster show

L'esempio seguente mostra l'output quando entrambi i nodi sono idonei e integri:

cluster::> cluster show

Node                  Health  Eligibility
--------------------- ------- ------------
node1                 true    true
node2                 true    true

Impostare il livello di privilegio su Advanced (avanzato):

set -privilege advanced

verificare che node1 e node2 eseguano la stessa release di ONTAP:

system node image show -node node1,node2 -iscurrent true

L'esempio seguente mostra l'output del comando:

cluster::*> system node image show -node node1,node2 -iscurrent true

                 Is      Is                Install
Node     Image   Default Current Version   Date
-------- ------- ------- ------- --------- -------------------
node1
         image1  true    true    9.1         2/7/2017 20:22:06
node2
         image1  true    true    9.1         2/7/2017 20:20:48

2 entries were displayed.

Verificare che né node1 né node2 siano in possesso di LIF di dati appartenenti ad altri nodi del cluster e controllare Current Node e. Is Home colonne nell'output:

network interface show -role data -is-home false -curr-node node_name

L'esempio seguente mostra l'output quando node1 non ha LIF di proprietà di altri nodi nel cluster:

cluster::> network interface show -role data -is-home false -curr-node node1
 There are no entries matching your query.

Nell'esempio seguente viene mostrato l'output quando node1 possiede le LIF dei dati di proprietà dell'altro nodo:

cluster::> network interface show -role data -is-home false -curr-node node1

            Logical    Status     Network            Current       Current Is
Vserver     Interface  Admin/Oper Address/Mask       Node          Port    Home
----------- ---------- ---------- ------------------ ------------- ------- ----
vs0
            data1      up/up      172.18.103.137/24  node1         e0d     false
            data2      up/up      172.18.103.143/24  node1         e0f     false

2 entries were displayed.

Se l'output è in Fase 15 Mostra che node1 o node2 possiede qualsiasi LIF di dati di proprietà di altri nodi nel cluster, migrare i LIF di dati lontano dal node1 o node2:

network interface revert -vserver * -lif *

Per informazioni dettagliate su network interface revert fare riferimento a. "Riferimenti" Per collegarsi ai comandi di ONTAP 9: Manuale riferimento pagina.
Controllare se node1 o node2 possiede dischi guasti:

storage disk show -nodelist node1,node2 -broken

Se uno dei dischi si è guastato, rimuoverli seguendo le istruzioni contenute in Disk and aggregate management with the CLI. (Fare riferimento a. "Riferimenti" Per collegarsi a Disk and aggregate management with the CLI.)

Raccogliere informazioni su node1 e node2 completando i seguenti passaggi secondari e registrando l'output di ciascun comando:

Queste informazioni verranno utilizzate più avanti nella procedura.
Se si dispone di un sistema con più di due porte cluster per nodo, ad esempio un sistema FAS8080 o AFF8080, prima di avviare l'aggiornamento, è necessario migrare e riassegnare le LIF del cluster a due porte cluster per nodo. Se si esegue l'aggiornamento del controller con più di due porte cluster per nodo, le LIF del cluster potrebbero non essere presenti sul nuovo controller dopo l'aggiornamento.

Registrare il modello, l'ID del sistema e il numero di serie di entrambi i nodi:

system node show -node node1,node2 -instance

Le informazioni verranno utilizzate per riassegnare i dischi e decommissionare i nodi originali.

Immettere il seguente comando sia sul nodo 1 che sul nodo 2 e registrare le informazioni sugli shelf, il numero di dischi in ogni shelf, i dettagli dello storage flash, la memoria, la NVRAM e le schede di rete dall'output:

run -node node_name sysconfig

È possibile utilizzare le informazioni per identificare i componenti o gli accessori che si desidera trasferire al nodo 3 o al nodo 4. Se non si sa se i nodi sono sistemi V-Series o se si dispone di software di virtualizzazione FlexArray, si può imparare anche dall'output.

Immettere il seguente comando sia su node1 che su node2 e registrare gli aggregati che sono online su entrambi i nodi:

storage aggregate show -node node_name -state online

È possibile utilizzare queste informazioni e le informazioni riportate nel seguente passaggio per verificare che gli aggregati e i volumi rimangano online durante l'intera procedura, ad eccezione del breve periodo in cui sono offline durante il trasferimento.

immettere il seguente comando sia su node1 che su node2 e registrare i volumi offline su entrambi i nodi:

volume show -node node_name -state offline

Dopo l'aggiornamento, eseguire di nuovo il comando e confrontare l'output con l'output in questa fase per verificare se altri volumi sono andati offline.

Immettere i seguenti comandi per verificare se sono configurati gruppi di interfacce o VLAN su node1 o node2:

network port ifgrp show

network port vlan show

Annotare se i gruppi di interfacce o le VLAN sono configurati su node1 o node2; tali informazioni sono necessarie nella fase successiva e successiva della procedura.
Completare i seguenti passaggi secondari su node1 e node2 per confermare che le porte fisiche possono essere mappate correttamente più avanti nella procedura:
1. Immettere il seguente comando per verificare la presenza di gruppi di failover sul nodo diversi da clusterwide:
  
  network interface failover-groups show
  
  I gruppi di failover sono insiemi di porte di rete presenti nel sistema. Poiché l'aggiornamento dell'hardware del controller può modificare la posizione delle porte fisiche, i gruppi di failover possono essere modificati inavvertitamente durante l'aggiornamento.
  
  Il sistema visualizza i gruppi di failover sul nodo, come illustrato nell'esempio seguente:
  cluster::> network interface failover-groups show Vserver Group Targets ------------------- ----------------- ---------- Cluster Cluster node1:e0a, node1:e0b node2:e0a, node2:e0b fg_6210_e0c Default node1:e0c, node1:e0d node1:e0e, node2:e0c node2:e0d, node2:e0e 2 entries were displayed.
2. Se sono presenti gruppi di failover diversi da clusterwide, registrare i nomi dei gruppi di failover e le porte che appartengono ai gruppi di failover.
3. Immettere il seguente comando per verificare se nel nodo sono configurate VLAN:
  
  network port vlan show -node node_name
  
  Le VLAN sono configurate su porte fisiche. Se le porte fisiche cambiano, sarà necessario ricreare le VLAN in un secondo momento della procedura.
  
  Il sistema visualizza le VLAN configurate sul nodo, come illustrato nell'esempio seguente:
```
cluster::> network port vlan show

Network Network
Node    VLAN Name Port    VLAN ID MAC Address
------  --------- ------- ------- ------------------
node1   e1b-70    e1b     70      00:15:17:76:7b:69
```
1. Se nel nodo sono configurate VLAN, prendere nota di ogni associazione di porte di rete e ID VLAN.
Eseguire una delle seguenti operazioni:

Se i gruppi di interfacce o LE VLAN sono… Quindi…

On node1 o node2

Completo Fase 23 e. Fase 24.

Non su node1 o node2

Passare a. Fase 24.
se non si sa se node1 e node2 si trovano in un ambiente SAN o non SAN, immettere il seguente comando ed esaminarne l'output:

network interface show -vserver vserver_name -data-protocol iscsi|fcp

Se non sono configurati né iSCSI né FC per SVM, il comando visualizza un messaggio simile all'esempio seguente:
```
cluster::> network interface show -vserver Vserver8970 -data-protocol iscsi|fcp
There are no entries matching your query.
```
È possibile verificare che il nodo si trovi in un ambiente NAS utilizzando network interface show con il -data-protocol nfs|cifs parametri.

Se iSCSI o FC sono configurati per SVM, il comando visualizza un messaggio simile all'esempio seguente:
```
cluster::> network interface show -vserver vs1 -data-protocol iscsi|fcp

         Logical    Status     Network            Current  Current Is
Vserver  Interface  Admin/Oper Address/Mask       Node     Port    Home
-------- ---------- ---------- ------------------ -------- ------- ----
vs1      vs1_lif1   up/down    172.17.176.20/24   node1    0d      true
```
verificare che tutti i nodi del cluster siano in quorum completando le seguenti fasi secondarie:
1. Immettere il livello di privilegio avanzato:
  
  set -privilege advanced
  
  Il sistema visualizza il seguente messaggio:
  Warning: These advanced commands are potentially dangerous; use them only when directed to do so by NetApp personnel. Do you wish to continue? (y or n):
2. Invio y.
3. Verificare lo stato del servizio cluster nel kernel, una volta per ogni nodo:
  
  cluster kernel-service show
  
  Il sistema visualizza un messaggio simile al seguente esempio:
```
cluster::*> cluster kernel-service show

Master        Cluster       Quorum        Availability  Operational
Node          Node          Status        Status        Status
------------- ------------- ------------- ------------- -------------
node1         node1         in-quorum     true          operational
              node2         in-quorum     true          operational

2 entries were displayed.
```
+
I nodi di un cluster sono in quorum quando una semplice maggioranza di nodi è in buone condizioni e può comunicare tra loro. Per ulteriori informazioni, fare riferimento a. "Riferimenti" Per collegarsi al System Administration Reference.
1. Tornare al livello di privilegi amministrativi:
  
  set -privilege admin
Eseguire una delle seguenti operazioni:

Se il cluster… Quindi…

HA UNA SAN configurata

Passare a. Fase 26.

NON ha SAN configurato

Passare a. Fase 29.

Se i gruppi di interfacce o LE VLAN sono…	Quindi…
On node1 o node2	Completo Fase 23 e. Fase 24.
Non su node1 o node2	Passare a. Fase 24.

Se il cluster…	Quindi…
HA UNA SAN configurata	Passare a. Fase 26.
NON ha SAN configurato	Passare a. Fase 29.

verificare che vi siano LIF SAN su node1 e node2 per ogni SVM che ha UN servizio SAN iSCSI o FC abilitato immettendo il seguente comando ed esaminandone l'output:

network interface show -data-protocol iscsi|fcp -home-node node_name

Il comando visualizza le informazioni LIF SAN per node1 e node2. Gli esempi seguenti mostrano lo stato nella colonna Status Admin/Oper come up/up, indicando che SAN iSCSI e il servizio FC sono abilitati:

cluster::> network interface show -data-protocol iscsi|fcp
            Logical    Status     Network                  Current   Current Is
Vserver     Interface  Admin/Oper Address/Mask             Node      Port    Home
----------- ---------- ---------- ------------------       --------- ------- ----
a_vs_iscsi  data1      up/up      10.228.32.190/21         node1     e0a     true
            data2      up/up      10.228.32.192/21         node2     e0a     true

b_vs_fcp    data1      up/up      20:09:00:a0:98:19:9f:b0  node1     0c      true
            data2      up/up      20:0a:00:a0:98:19:9f:b0  node2     0c      true

c_vs_iscsi_fcp data1   up/up      20:0d:00:a0:98:19:9f:b0  node2     0c      true
            data2      up/up      20:0e:00:a0:98:19:9f:b0  node2     0c      true
            data3      up/up      10.228.34.190/21         node2     e0b     true
            data4      up/up      10.228.34.192/21         node2     e0b     true

In alternativa, è possibile visualizzare informazioni LIF più dettagliate immettendo il seguente comando:

network interface show -instance -data-protocol iscsi|fcp

Acquisire la configurazione predefinita di qualsiasi porta FC sui nodi originali immettendo il seguente comando e registrando l'output dei sistemi:

ucadmin show

Il comando visualizza le informazioni su tutte le porte FC del cluster, come illustrato nell'esempio seguente:

cluster::> ucadmin show

                Current Current   Pending Pending   Admin
Node    Adapter Mode    Type      Mode    Type      Status
------- ------- ------- --------- ------- --------- -----------
node1   0a      fc      initiator -       -         online
node1   0b      fc      initiator -       -         online
node1   0c      fc      initiator -       -         online
node1   0d      fc      initiator -       -         online
node2   0a      fc      initiator -       -         online
node2   0b      fc      initiator -       -         online
node2   0c      fc      initiator -       -         online
node2   0d      fc      initiator -       -         online
8 entries were displayed.

È possibile utilizzare le informazioni dopo l'aggiornamento per impostare la configurazione delle porte FC sui nuovi nodi.

Se si sta aggiornando un sistema V-Series o un sistema con software di virtualizzazione FlexArray, acquisire informazioni sulla topologia dei nodi originali immettendo il seguente comando e registrando l'output:

storage array config show -switch

Il sistema visualizza le informazioni sulla topologia, come mostrato nell'esempio seguente:

cluster::> storage array config show -switch

      LUN LUN                                  Target Side Initiator Side Initi-
Node  Grp Cnt Array Name    Array Target Port  Switch Port Switch Port    ator
----- --- --- ------------- ------------------ ----------- -------------- ------
node1 0   50  I_1818FAStT_1
                            205700a0b84772da   vgbr6510a:5  vgbr6510s164:3  0d
                            206700a0b84772da   vgbr6510a:6  vgbr6510s164:4  2b
                            207600a0b84772da   vgbr6510b:6  vgbr6510s163:1  0c
node2 0   50  I_1818FAStT_1
                            205700a0b84772da   vgbr6510a:5  vgbr6510s164:1  0d
                            206700a0b84772da   vgbr6510a:6  vgbr6510s164:2  2b
                            207600a0b84772da   vgbr6510b:6  vgbr6510s163:3  0c
                            208600a0b84772da   vgbr6510b:5  vgbr6510s163:4  2a
7 entries were displayed.

completare i seguenti passaggi secondari:
1. Immettere il seguente comando su uno dei nodi originali e registrare l'output:
  
  service-processor show -node * -instance
Il sistema visualizza informazioni dettagliate sull'SP su entrambi i nodi.
1. Verificare che lo stato SP sia online.
2. Verificare che la rete SP sia configurata.
3. Registrare l'indirizzo IP e altre informazioni sull'SP.
  
  È possibile riutilizzare i parametri di rete dei dispositivi di gestione remota, in questo caso gli SP, dal sistema originale per gli SP sui nuovi nodi. Per informazioni dettagliate sull'SP, fare riferimento a. "Riferimenti" Per collegarsi al riferimento per l'amministrazione del sistema e ai comandi di ONTAP 9: Riferimento pagina manuale.

se si desidera che i nuovi nodi abbiano la stessa funzionalità concessa in licenza dei nodi originali, immettere il seguente comando per visualizzare le licenze del cluster sul sistema originale:

system license show -owner *

L'esempio seguente mostra le licenze del sito per il cluster1:

system license show -owner *
Serial Number: 1-80-000013
Owner: cluster1

Package           Type    Description           Expiration
----------------- ------- --------------------- -----------
Base              site    Cluster Base License  -
NFS               site    NFS License           -
CIFS              site    CIFS License          -
SnapMirror        site    SnapMirror License    -
FlexClone         site    FlexClone License     -
SnapVault         site    SnapVault License     -
6 entries were displayed.

Ottenere nuove chiavi di licenza per i nuovi nodi presso il NetApp Support Site. Fare riferimento a. "Riferimenti" Per collegarsi al sito di supporto NetApp.

Se il sito non dispone delle chiavi di licenza necessarie, contattare il rappresentante commerciale NetApp.

Verificare se il sistema originale ha abilitato AutoSupport immettendo il seguente comando su ciascun nodo ed esaminandone l'output:

system node autosupport show -node node1,node2

L'output del comando indica se AutoSupport è attivato, come illustrato nell'esempio seguente:

cluster::> system node autosupport show -node node1,node2

Node             State     From          To                Mail Hosts
---------------- --------- ------------- ----------------  ----------
node1            enable    Postmaster    admin@netapp.com  mailhost

node2            enable    Postmaster    -                 mailhost
2 entries were displayed.

Eseguire una delle seguenti operazioni:

Se il sistema originale…	Quindi…
AutoSupport attivato…	Passare a. Fase 34.
AutoSupport non è abilitato…	Abilitare AutoSupport seguendo le istruzioni contenute nella sezione riferimento per l'amministrazione del sistema. (Fare riferimento a. "Riferimenti" Per collegarsi al System Administration Reference.) Nota: AutoSupport è attivato per impostazione predefinita quando si configura il sistema di storage per la prima volta. Sebbene sia possibile disattivare AutoSupport in qualsiasi momento, è necessario lasciarlo attivato. L'abilitazione di AutoSupport consente di identificare in modo significativo i problemi e le soluzioni in caso di problemi nel sistema storage.

Se il sistema originale…

Quindi…

AutoSupport attivato…

Passare a. Fase 34.

AutoSupport non è abilitato…

Abilitare AutoSupport seguendo le istruzioni contenute nella sezione riferimento per l'amministrazione del sistema. (Fare riferimento a. "Riferimenti" Per collegarsi al System Administration Reference.)

Nota: AutoSupport è attivato per impostazione predefinita quando si configura il sistema di storage per la prima volta. Sebbene sia possibile disattivare AutoSupport in qualsiasi momento, è necessario lasciarlo attivato. L'abilitazione di AutoSupport consente di identificare in modo significativo i problemi e le soluzioni in caso di problemi nel sistema storage.

verificare che AutoSupport sia configurato con i dettagli corretti dell'host di posta e gli ID di posta elettronica del destinatario immettendo il seguente comando su entrambi i nodi originali ed esaminando l'output:

system node autosupport show -node node_name -instance

Per informazioni dettagliate su AutoSupport, fare riferimento a. "Riferimenti" Per collegarsi al riferimento per l'amministrazione del sistema e ai comandi di ONTAP 9: Riferimento pagina manuale.
Invia un messaggio AutoSupport a NetApp per node1 immettendo il seguente comando:

system node autosupport invoke -node node1 -type all -message "Upgrading node1 from platform_old to platform_new"

Non inviare un messaggio AutoSupport a NetApp per node2 a questo punto; lo si esegue più avanti nella procedura.
verificare che il messaggio AutoSupport sia stato inviato immettendo il seguente comando ed esaminandone l'output:

system node autosupport show -node node1 -instance

I campi Last Subject Sent: e. Last Time Sent: contiene il titolo dell'ultimo messaggio inviato e l'ora in cui il messaggio è stato inviato.
Se il sistema utilizza dischi con crittografia automatica, consultare l'articolo della Knowledge base "Come verificare se un disco è certificato FIPS" Per determinare il tipo di unità con crittografia automatica in uso sulla coppia ha che si sta aggiornando. Il software ONTAP supporta due tipi di dischi con crittografia automatica:
- Dischi SAS o NVMe NetApp Storage Encryption (NSE) certificati FIPS
- Dischi NVMe con crittografia automatica non FIPS (SED)
Non è possibile combinare dischi FIPS con altri tipi di dischi sullo stesso nodo o coppia ha.

È possibile combinare SED con dischi non crittografanti sullo stesso nodo o coppia ha.

"Scopri di più sulle unità con crittografia automatica supportate".

Preparare i nodi per l'aggiornamento

Creating your file...