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

Configurazione del software MetroCluster in ONTAP

Collaboratori
PDF

È necessario impostare ciascun nodo nella configurazione MetroCluster in ONTAP, incluse le configurazioni a livello di nodo e la configurazione dei nodi in due siti. È inoltre necessario implementare la relazione MetroCluster tra i due siti.

software di configurazione cluster e nodo di alto livello per il workflow
Fasi

  1. Prima di iniziare il processo di configurazione, raccogliere gli indirizzi IP richiesti per i moduli controller.

  2. Completare il foglio di lavoro con le informazioni sulla rete IP per il sito A.

Foglio di lavoro con le informazioni sulla rete IP per il sito A.

Prima di configurare il sistema, è necessario ottenere gli indirizzi IP e altre informazioni di rete per il primo sito MetroCluster (sito A) dall'amministratore di rete.

Informazioni sulla creazione del cluster del sito A.

Quando si crea il cluster per la prima volta, sono necessarie le seguenti informazioni:

Tipo di informazione

I tuoi valori

Nome del cluster. Esempio utilizzato in queste informazioni: Site_A.

Dominio DNS

Server dei nomi DNS

Posizione

Password dell'amministratore

Informazioni sul nodo del sito A.

Per ciascun nodo del cluster, sono necessari un indirizzo IP di gestione, una maschera di rete e un gateway predefinito.

Nodo

Porta

Indirizzo IP

Maschera di rete

Gateway predefinito

Nodo 1. Esempio utilizzato in queste informazioni: Controller_A_1

Nodo 2. Non richiesto se si utilizza una configurazione MetroCluster a due nodi (un nodo per ogni sito).

Esempio utilizzato in queste informazioni: Controller_A_2

Porta e LIF del sito A per il peering del cluster

Per ciascun nodo del cluster, sono necessari gli indirizzi IP di due LIF intercluster, tra cui una maschera di rete e un gateway predefinito. Le LIF dell'intercluster vengono utilizzate per eseguire il peer dei cluster.

Nodo

Porta

Indirizzo IP della LIF dell'intercluster

Maschera di rete

Gateway predefinito

Nodo 1 IC LIF 1

Nodo 1 IC LIF 2

Informazioni sul server di riferimento orario del sito A.

È necessario sincronizzare l'ora, che richiede uno o più server di riferimento orario NTP.

Nodo

Nome host

Indirizzo IP

Maschera di rete

Gateway predefinito

Server NTP 1

Server NTP 2

Sito A nbsp; informazioni AutoSupport

È necessario configurare AutoSupport su ciascun nodo, che richiede le seguenti informazioni:

Tipo di informazione

I tuoi valori

Da indirizzo e-mail

Mail host

Indirizzi IP o nomi

Protocollo di trasporto

HTTP, HTTPS O SMTP

Server proxy

Indirizzi e-mail o liste di distribuzione del destinatario

Messaggi completi

Messaggi concisi

Informazioni SP del sito A.

È necessario abilitare l'accesso al Service Processor (SP) di ciascun nodo per la risoluzione dei problemi e la manutenzione. Ciò richiede le seguenti informazioni di rete per ciascun nodo:

Nodo

Indirizzo IP

Maschera di rete

Gateway predefinito

Nodo 1

Foglio di lavoro con le informazioni sulla rete IP per il sito B

Prima di configurare il sistema, è necessario ottenere gli indirizzi IP e altre informazioni di rete per il secondo sito MetroCluster (sito B) dall'amministratore di rete.

Informazioni sulla creazione del cluster del sito B.

Quando si crea il cluster per la prima volta, sono necessarie le seguenti informazioni:

Tipo di informazione

I tuoi valori

Nome del cluster. Esempio utilizzato in queste informazioni: Site_B.

Dominio DNS

Server dei nomi DNS

Posizione

Password dell'amministratore

Informazioni sul nodo del sito B.

Per ciascun nodo del cluster, sono necessari un indirizzo IP di gestione, una maschera di rete e un gateway predefinito.

Nodo

Porta

Indirizzo IP

Maschera di rete

Gateway predefinito

Nodo 1. Esempio utilizzato in queste informazioni: Controller_B_1

Nodo 2. Non richiesto per configurazioni MetroCluster a due nodi (un nodo per sito).

Esempio utilizzato in queste informazioni: Controller_B_2

LIF e porte del sito B per il peering dei cluster

Per ciascun nodo del cluster, sono necessari gli indirizzi IP di due LIF intercluster, tra cui una maschera di rete e un gateway predefinito. Le LIF dell'intercluster vengono utilizzate per eseguire il peer dei cluster.

Nodo

Porta

Indirizzo IP della LIF dell'intercluster

Maschera di rete

Gateway predefinito

Nodo 1 IC LIF 1

Nodo 1 IC LIF 2

Informazioni sul server di riferimento orario del sito B.

È necessario sincronizzare l'ora, che richiede uno o più server di riferimento orario NTP.

Nodo

Nome host

Indirizzo IP

Maschera di rete

Gateway predefinito

Server NTP 1

Server NTP 2

Sito B nbsp; informazioni AutoSupport

È necessario configurare AutoSupport su ciascun nodo, che richiede le seguenti informazioni:

Tipo di informazione

I tuoi valori

Da indirizzo e-mail

Mail host

Indirizzi IP o nomi

Protocollo di trasporto

HTTP, HTTPS O SMTP

Server proxy

Indirizzi e-mail o liste di distribuzione del destinatario

Messaggi completi

Messaggi concisi

Sito B nbsp; informazioni SP

È necessario abilitare l'accesso al Service Processor (SP) di ciascun nodo per la risoluzione dei problemi e la manutenzione, che richiede le seguenti informazioni di rete per ciascun nodo:

Nodo

Indirizzo IP

Maschera di rete

Gateway predefinito

Nodo 1 (controller_B_1)

Analogie e differenze tra cluster standard e configurazioni MetroCluster

La configurazione dei nodi in ciascun cluster in una configurazione MetroCluster è simile a quella dei nodi in un cluster standard.

La configurazione di MetroCluster si basa su due cluster standard. Fisicamente, la configurazione deve essere simmetrica, con ciascun nodo con la stessa configurazione hardware e tutti i componenti MetroCluster devono essere cablati e configurati. Tuttavia, la configurazione software di base per i nodi in una configurazione MetroCluster è uguale a quella per i nodi in un cluster standard.

Fase di configurazione

Configurazione standard del cluster

Configurazione di MetroCluster

Configurare le LIF di gestione, cluster e dati su ciascun nodo.

Lo stesso vale per entrambi i tipi di cluster

Configurare l'aggregato root.

Lo stesso vale per entrambi i tipi di cluster

Impostare il cluster su un nodo del cluster.

Lo stesso vale per entrambi i tipi di cluster

Unire l'altro nodo al cluster.

Lo stesso vale per entrambi i tipi di cluster

Creare un aggregato root mirrorato.

Opzionale

Obbligatorio

Peer dei cluster.

Opzionale

Obbligatorio

Abilitare la configurazione MetroCluster.

Ripristino delle impostazioni predefinite del sistema e configurazione del tipo di HBA su un modulo controller

Per garantire una corretta installazione di MetroCluster, ripristinare le impostazioni predefinite dei moduli controller.

Importante

Questa attività è necessaria solo per le configurazioni stretch che utilizzano bridge FC-SAS.

Fasi

  1. Al prompt DEL CARICATORE, riportare le variabili ambientali alle impostazioni predefinite:

    set-defaults

  2. Avviare il nodo in modalità manutenzione, quindi configurare le impostazioni per gli HBA nel sistema:

    1. Avviare in modalità di manutenzione:

      boot_ontap maint

    2. Verificare le impostazioni correnti delle porte:

      ucadmin show

    3. Aggiornare le impostazioni della porta secondo necessità.

    Se si dispone di questo tipo di HBA e della modalità desiderata…​

    Utilizzare questo comando…​

    FC CNA

    ucadmin modify -m fc -t initiator adapter_name

    Ethernet CNA

    ucadmin modify -mode cna adapter_name

    Destinazione FC

    fcadmin config -t target adapter_name

    Iniziatore FC

    fcadmin config -t initiator adapter_name

  3. Uscire dalla modalità di manutenzione:

    halt

    Dopo aver eseguito il comando, attendere che il nodo si arresti al prompt DEL CARICATORE.

  4. Riavviare il nodo in modalità Maintenance per rendere effettive le modifiche di configurazione:

    boot_ontap maint

  5. Verificare le modifiche apportate:

    Se si dispone di questo tipo di HBA…​

    Utilizzare questo comando…​

    CNA

    ucadmin show

    FC

    fcadmin show

  6. Uscire dalla modalità di manutenzione:

    halt

    Dopo aver eseguito il comando, attendere che il nodo si arresti al prompt DEL CARICATORE.

  7. Avviare il nodo dal menu di boot:

    boot_ontap menu

    Dopo aver eseguito il comando, attendere che venga visualizzato il menu di avvio.

  8. Cancellare la configurazione del nodo digitando “wipeconfig” al prompt del menu di avvio, quindi premere Invio.

    La seguente schermata mostra il prompt del menu di avvio:

    Please choose one of the following:

     (1) Normal Boot.
     (2) Boot without /etc/rc.
     (3) Change password.
     (4) Clean configuration and initialize all disks.
     (5) Maintenance mode boot.
     (6) Update flash from backup config.
     (7) Install new software first.
     (8) Reboot node.
     (9) Configure Advanced Drive Partitioning.
     Selection (1-9)?  wipeconfig
 This option deletes critical system configuration, including cluster membership.
 Warning: do not run this option on a HA node that has been taken over.
 Are you sure you want to continue?: yes
 Rebooting to finish wipeconfig request.

Configurazione delle porte FC-VI su una scheda X1132A-R6 quad-port su sistemi FAS8020

Se si utilizza la scheda a quattro porte X1132A-R6 su un sistema FAS8020, è possibile accedere alla modalità di manutenzione per configurare le porte 1a e 1b per l'utilizzo di FC-VI e Initiator. Questa operazione non è necessaria sui sistemi MetroCluster ricevuti dalla fabbrica, in cui le porte sono impostate in modo appropriato per la configurazione.

A proposito di questa attività

Questa attività deve essere eseguita in modalità manutenzione.

Nota La conversione di una porta FC in una porta FC-VI con il comando ucadmin è supportata solo sui sistemi FAS8020 e AFF 8020. La conversione delle porte FC in porte FCVI non è supportata su altre piattaforme.
Fasi

  1. Disattivare le porte:

    storage disable adapter 1a

    storage disable adapter 1b

    *> storage disable adapter 1a
Jun 03 02:17:57 [controller_B_1:fci.adapter.offlining:info]: Offlining Fibre Channel adapter 1a.
Host adapter 1a disable succeeded
Jun 03 02:17:57 [controller_B_1:fci.adapter.offline:info]: Fibre Channel adapter 1a is now offline.
*> storage disable adapter 1b
Jun 03 02:18:43 [controller_B_1:fci.adapter.offlining:info]: Offlining Fibre Channel adapter 1b.
Host adapter 1b disable succeeded
Jun 03 02:18:43 [controller_B_1:fci.adapter.offline:info]: Fibre Channel adapter 1b is now offline.
*>

  2. Verificare che le porte siano disattivate:

    ucadmin show

    *> ucadmin show
         Current  Current    Pending  Pending    Admin
Adapter  Mode     Type       Mode     Type       Status
-------  -------  ---------  -------  ---------  -------
  ...
  1a     fc       initiator  -        -          offline
  1b     fc       initiator  -        -          offline
  1c     fc       initiator  -        -          online
  1d     fc       initiator  -        -          online

  3. Impostare le porte a e b sulla modalità FC-VI:

    ucadmin modify -adapter 1a -type fcvi

    Il comando imposta la modalità su entrambe le porte della coppia di porte, 1a e 1b (anche se solo 1a è specificata nel comando).

    *> ucadmin modify -t fcvi 1a
Jun 03 02:19:13 [controller_B_1:ucm.type.changed:info]: FC-4 type has changed to fcvi on adapter 1a. Reboot the controller for the changes to take effect.
Jun 03 02:19:13 [controller_B_1:ucm.type.changed:info]: FC-4 type has changed to fcvi on adapter 1b. Reboot the controller for the changes to take effect.

  4. Confermare che la modifica è in sospeso:

    ucadmin show

    *> ucadmin show
         Current  Current    Pending  Pending    Admin
Adapter  Mode     Type       Mode     Type       Status
-------  -------  ---------  -------  ---------  -------
  ...
  1a     fc       initiator  -        fcvi       offline
  1b     fc       initiator  -        fcvi       offline
  1c     fc       initiator  -        -          online
  1d     fc       initiator  -        -          online

  5. Spegnere il controller, quindi riavviarlo in modalità di manutenzione.

  6. Confermare la modifica della configurazione:

    ucadmin show local

    Node           Adapter  Mode     Type       Mode     Type       Status
------------   -------  -------  ---------  -------  ---------  -----------
...
controller_B_1
               1a       fc       fcvi       -        -          online
controller_B_1
               1b       fc       fcvi       -        -          online
controller_B_1
               1c       fc       initiator  -        -          online
controller_B_1
               1d       fc       initiator  -        -          online
6 entries were displayed.

Verifica dell'assegnazione dei dischi in modalità manutenzione in una configurazione a due nodi

Prima di avviare completamente il sistema su ONTAP, è possibile avviare il sistema in modalità manutenzione e verificare l'assegnazione dei dischi sui nodi. I dischi devono essere assegnati in modo da creare una configurazione completamente simmetrica con entrambi i siti che possiedono i propri shelf di dischi e i dati di servizio, in cui a ciascun nodo e a ciascun pool è assegnato un numero uguale di dischi mirrorati.

Prima di iniziare

Il sistema deve essere in modalità di manutenzione.

A proposito di questa attività

I nuovi sistemi MetroCluster hanno completato le assegnazioni dei dischi prima della spedizione.

La tabella seguente mostra esempi di assegnazioni di pool per una configurazione MetroCluster. I dischi vengono assegnati ai pool in base allo shelf.

Shelf di dischi (nome di esempio)…​

Sul sito…​

Appartiene a…​

E viene assegnato al nodo…​

Shelf di dischi 1 (shelf_A_1_1)

Sito A

Nodo A 1

Pool 0

Shelf di dischi 2 (shelf_A_1_3)

Shelf di dischi 3 (shelf_B_1_1)

Nodo B 1

Pool 1

Shelf di dischi 4 (shelf_B_1_3)

Shelf di dischi 9 (shelf_B_1_2)

Sito B

Nodo B 1

Pool 0

Shelf di dischi 10 (shelf_B_1_4)

Shelf di dischi 11 (shelf_A_1_2)

Nodo A 1

Se la configurazione include shelf di dischi DS460C, è necessario assegnare manualmente i dischi utilizzando le seguenti linee guida per ciascun cassetto da 12 dischi:

Assegnare questi dischi nel cassetto…​

A questo nodo e pool…​

1 - 6

Pool del nodo locale 0

7 - 12

Pool del partner DR 1

Questo schema di assegnazione dei dischi riduce al minimo l'effetto su un aggregato se un cassetto passa offline.

Fasi

  1. Se il sistema è stato ricevuto dalla fabbrica, confermare le assegnazioni degli shelf:

    disk show –v

  2. Se necessario, è possibile assegnare esplicitamente i dischi sugli shelf di dischi collegati al pool appropriato

    disk assign

    Gli shelf di dischi nello stesso sito del nodo vengono assegnati al pool 0 e gli shelf di dischi situati nel sito del partner vengono assegnati al pool 1. È necessario assegnare un numero uguale di shelf a ciascun pool.

    1. In caso contrario, avviare ciascun sistema in modalità di manutenzione.

    2. Sul nodo del sito A, assegnare sistematicamente gli shelf di dischi locali al pool 0 e gli shelf di dischi remoti al pool 1:
      disk assign -shelf disk_shelf_name -p pool

      Se lo storage controller node_A_1 dispone di quattro shelf, eseguire i seguenti comandi:

      *> disk assign -shelf shelf_A_1_1 -p 0
*> disk assign -shelf shelf_A_1_3 -p 0

*> disk assign -shelf shelf_A_1_2 -p 1
*> disk assign -shelf shelf_A_1_4 -p 1

    3. Sul nodo del sito remoto (sito B), assegnare sistematicamente i propri shelf di dischi locali al pool 0 e i relativi shelf di dischi remoti al pool 1:
      disk assign -shelf disk_shelf_name -p pool

      Se lo storage controller node_B_1 dispone di quattro shelf, eseguire i seguenti comandi:

    *> disk assign -shelf shelf_B_1_2   -p 0
*> disk assign -shelf shelf_B_1_4  -p 0

*> disk assign -shelf shelf_B_1_1 -p 1
 *> disk assign -shelf shelf_B_1_3 -p 1

    1. Mostra gli ID e gli alloggiamenti degli shelf di dischi per ciascun disco:
      disk show –v

Verifica dello stato ha dei componenti

In una configurazione stretch MetroCluster non preconfigurata in fabbrica, è necessario verificare che lo stato ha del controller e del componente dello chassis sia impostato su “mcc-2n” in modo che si avvii correttamente. Per i sistemi ricevuti dalla fabbrica, questo valore è preconfigurato e non è necessario verificarlo.

Prima di iniziare

Il sistema deve essere in modalità di manutenzione.

Fasi

  1. In modalità Maintenance (manutenzione), visualizzare lo stato ha del modulo controller e dello chassis:

    ha-config show

    Il modulo controller e lo chassis devono visualizzare il valore “mcc-2n”.

  2. Se lo stato di sistema visualizzato del controller non è “mcc-2n”, impostare lo stato ha per il controller:

    ha-config modify controller mcc-2n

  3. Se lo stato di sistema visualizzato dello chassis non è “mcc-2n”, impostare lo stato ha per lo chassis:

    ha-config modify chassis mcc-2n

    Arrestare il nodo.

    Attendere che il nodo sia tornato al prompt DEL CARICATORE.

  4. Ripetere questi passaggi su ciascun nodo della configurazione MetroCluster.

Impostazione di ONTAP in una configurazione MetroCluster a due nodi

In una configurazione MetroCluster a due nodi, su ciascun cluster è necessario avviare il nodo, uscire dall'installazione guidata cluster e utilizzare cluster setup per configurare il nodo in un cluster a nodo singolo.

Prima di iniziare

Non è necessario aver configurato il Service Processor.

A proposito di questa attività

Questa attività è destinata alle configurazioni MetroCluster a due nodi che utilizzano lo storage NetApp nativo.

Questa attività deve essere eseguita su entrambi i cluster nella configurazione MetroCluster.

Per ulteriori informazioni generali sulla configurazione di ONTAP, consultare "Setup ONTAP (Configurazione guidata)"

Fasi

  1. Accendere il primo nodo.

    Nota Ripetere questo passaggio sul nodo del sito di disaster recovery (DR).

    Il nodo si avvia, quindi viene avviata la procedura guidata di configurazione del cluster sulla console per informare che AutoSupport verrà attivato automaticamente.

    ::> Welcome to the cluster setup wizard.

You can enter the following commands at any time:
  "help" or "?" - if you want to have a question clarified,
  "back" - if you want to change previously answered questions, and
  "exit" or "quit" - if you want to quit the cluster setup wizard.
     Any changes you made before quitting will be saved.

You can return to cluster setup at any time by typing "cluster setup".
To accept a default or omit a question, do not enter a value.

This system will send event messages and periodic reports to NetApp Technical
Support. To disable this feature, enter
autosupport modify -support disable
within 24 hours.

Enabling AutoSupport can significantly speed problem determination and
resolution, should a problem occur on your system.
For further information on AutoSupport, see:
http://support.netapp.com/autosupport/

Type yes to confirm and continue {yes}: yes

Enter the node management interface port [e0M]:
Enter the node management interface IP address [10.101.01.01]:

Enter the node management interface netmask [101.010.101.0]:
Enter the node management interface default gateway [10.101.01.0]:



Do you want to create a new cluster or join an existing cluster? {create, join}:

  2. Creare un nuovo cluster:

    create

  3. Scegliere se utilizzare il nodo come cluster a nodo singolo.

    Do you intend for this node to be used as a single node cluster? {yes, no} [yes]:

  4. Accettare l'impostazione predefinita del sistema “yes” premendo Invio oppure immettere i propri valori digitando “no” e premendo Invio.

  5. Seguire le istruzioni per completare la procedura guidata Cluster Setup, premere Invio per accettare i valori predefiniti o digitare i propri valori, quindi premere Invio.

    I valori predefiniti vengono determinati automaticamente in base alla piattaforma e alla configurazione di rete.

  6. Dopo aver completato la procedura guidata Cluster Setup e averlo chiuso, verificare che il cluster sia attivo e che il primo nodo funzioni correttamente:

    cluster show

    L'esempio seguente mostra un cluster in cui il primo nodo (cluster1-01) è integro e idoneo a partecipare:

    cluster1::> cluster show
Node                  Health  Eligibility
--------------------- ------- ------------
cluster1-01           true    true

    Se è necessario modificare una delle impostazioni immesse per l'SVM amministrativa o il nodo SVM, è possibile accedere alla procedura guidata Cluster Setup utilizzando cluster setup comando.

Configurazione dei cluster in una configurazione MetroCluster

È necessario eseguire il peer dei cluster, eseguire il mirroring degli aggregati root, creare un aggregato di dati mirrorati e quindi eseguire il comando per implementare le operazioni MetroCluster.

Peering dei cluster

I cluster nella configurazione di MetroCluster devono essere in una relazione peer in modo da poter comunicare tra loro ed eseguire il mirroring dei dati essenziale per il disaster recovery di MetroCluster.

Informazioni correlate

"Configurazione rapida del peering di cluster e SVM"

"Considerazioni sull'utilizzo di porte dedicate"

"Considerazioni sulla condivisione delle porte dati"

Configurazione delle LIF tra cluster

È necessario creare LIF intercluster sulle porte utilizzate per la comunicazione tra i cluster di partner MetroCluster. È possibile utilizzare porte o porte dedicate che dispongono anche di traffico dati.

Configurazione di LIF intercluster su porte dedicate

È possibile configurare le LIF tra cluster su porte dedicate. In genere, aumenta la larghezza di banda disponibile per il traffico di replica.

Fasi

  1. Elencare le porte nel cluster:

    network port show

    Per la sintassi completa dei comandi, vedere la pagina man.

    L'esempio seguente mostra le porte di rete in “cluster01”:

    cluster01::> network port show
                                                             Speed (Mbps)
Node   Port      IPspace      Broadcast Domain Link   MTU    Admin/Oper
------ --------- ------------ ---------------- ----- ------- ------------
cluster01-01
       e0a       Cluster      Cluster          up     1500   auto/1000
       e0b       Cluster      Cluster          up     1500   auto/1000
       e0c       Default      Default          up     1500   auto/1000
       e0d       Default      Default          up     1500   auto/1000
       e0e       Default      Default          up     1500   auto/1000
       e0f       Default      Default          up     1500   auto/1000
cluster01-02
       e0a       Cluster      Cluster          up     1500   auto/1000
       e0b       Cluster      Cluster          up     1500   auto/1000
       e0c       Default      Default          up     1500   auto/1000
       e0d       Default      Default          up     1500   auto/1000
       e0e       Default      Default          up     1500   auto/1000
       e0f       Default      Default          up     1500   auto/1000

  2. Determinare quali porte sono disponibili per la comunicazione tra cluster:

    network interface show -fields home-port,curr-port

    Per la sintassi completa dei comandi, vedere la pagina man.

    L'esempio seguente mostra che le porte “e0e” e “e0f” non sono state assegnate a LIF:

    cluster01::> network interface show -fields home-port,curr-port
vserver lif                  home-port curr-port

Cluster cluster01-01_clus1   e0a       e0a
Cluster cluster01-01_clus2   e0b       e0b
Cluster cluster01-02_clus1   e0a       e0a
Cluster cluster01-02_clus2   e0b       e0b
cluster01
        cluster_mgmt         e0c       e0c
cluster01
        cluster01-01_mgmt1   e0c       e0c
cluster01
        cluster01-02_mgmt1   e0c       e0c

  3. Creare un gruppo di failover per le porte dedicate:

    network interface failover-groups create -vserver system_SVM -failover-group failover_group -targets physical_or_logical_ports

    Nell'esempio seguente vengono assegnate le porte “e0e” e “e0f” al gruppo di failover “intercluster01” sulla SVM di sistema “cluster01”:

    cluster01::> network interface failover-groups create -vserver cluster01 -failover-group
intercluster01 -targets
cluster01-01:e0e,cluster01-01:e0f,cluster01-02:e0e,cluster01-02:e0f

  4. Verificare che il gruppo di failover sia stato creato:

    network interface failover-groups show

    Per la sintassi completa dei comandi, vedere la pagina man.

    cluster01::> network interface failover-groups show
                                  Failover
Vserver          Group            Targets
---------------- ---------------- --------------------------------------------
Cluster
                 Cluster
                                  cluster01-01:e0a, cluster01-01:e0b,
                                  cluster01-02:e0a, cluster01-02:e0b
cluster01
                 Default
                                  cluster01-01:e0c, cluster01-01:e0d,
                                  cluster01-02:e0c, cluster01-02:e0d,
                                  cluster01-01:e0e, cluster01-01:e0f
                                  cluster01-02:e0e, cluster01-02:e0f
                 intercluster01
                                  cluster01-01:e0e, cluster01-01:e0f
                                  cluster01-02:e0e, cluster01-02:e0f

  5. Creare LIF intercluster sulla SVM di sistema e assegnarle al gruppo di failover.

    Versione di ONTAP

    Comando

    ONTAP 9.6 e versioni successive

    network interface create -vserver system_SVM -lif LIF_name -service-policy default-intercluster -home-node node -home-port port -address port_IP -netmask netmask -failover-group failover_group

    ONTAP 9.5 e versioni precedenti

    network interface create -vserver system_SVM -lif LIF_name -role intercluster -home-node node -home-port port -address port_IP -netmask netmask -failover-group failover_group

    Per la sintassi completa dei comandi, vedere la pagina man.

    Nell'esempio seguente vengono create le LIF dell'intercluster “cluster01_icl01” e “cluster01_icl02” nel gruppo di failover “intercluster01”:

    cluster01::> network interface create -vserver cluster01 -lif cluster01_icl01 -service-
policy default-intercluster -home-node cluster01-01 -home-port e0e -address 192.168.1.201
-netmask 255.255.255.0 -failover-group intercluster01

cluster01::> network interface create -vserver cluster01 -lif cluster01_icl02 -service-
policy default-intercluster -home-node cluster01-02 -home-port e0e -address 192.168.1.202
-netmask 255.255.255.0 -failover-group intercluster01

  6. Verificare che le LIF dell'intercluster siano state create:

    Versione di ONTAP

    Comando

    ONTAP 9.6 e versioni successive

    network interface show -service-policy default-intercluster

    ONTAP 9.5 e versioni precedenti

    network interface show -role intercluster

    Per la sintassi completa dei comandi, vedere la pagina man.

    cluster01::> network interface show -service-policy default-intercluster
            Logical    Status     Network            Current       Current Is
Vserver     Interface  Admin/Oper Address/Mask       Node          Port    Home
----------- ---------- ---------- ------------------ ------------- ------- ----
cluster01
            cluster01_icl01
                       up/up      192.168.1.201/24   cluster01-01  e0e     true
            cluster01_icl02
                       up/up      192.168.1.202/24   cluster01-02  e0f     true

  7. Verificare che le LIF dell'intercluster siano ridondanti:

    Versione di ONTAP

    Comando

    ONTAP 9.6 e versioni successive

    network interface show -service-policy default-intercluster -failover

    In ONTAP 9.5 e versioni precedenti

    network interface show -role intercluster -failover

    Per la sintassi completa dei comandi, vedere la pagina man.

    L'esempio seguente mostra che le LIF dell'intercluster “cluster01_icl01” e “cluster01_icl02” sulla porta SVM “e0e” effettueranno il failover sulla porta “e0f”.

    cluster01::> network interface show -service-policy default-intercluster –failover
         Logical         Home                  Failover        Failover
Vserver  Interface       Node:Port             Policy          Group
-------- --------------- --------------------- --------------- --------
cluster01
         cluster01_icl01 cluster01-01:e0e   local-only      intercluster01
                            Failover Targets:  cluster01-01:e0e,
                                               cluster01-01:e0f
         cluster01_icl02 cluster01-02:e0e   local-only      intercluster01
                            Failover Targets:  cluster01-02:e0e,
                                               cluster01-02:e0f
Informazioni correlate

"Considerazioni sull'utilizzo di porte dedicate"

Configurazione delle LIF tra cluster su porte dati condivise

È possibile configurare le LIF di intercluster sulle porte condivise con la rete dati. In questo modo si riduce il numero di porte necessarie per la rete tra cluster.

Fasi

  1. Elencare le porte nel cluster:

    network port show

    Per la sintassi completa dei comandi, vedere la pagina man.

    L'esempio seguente mostra le porte di rete in “cluster01”:

    cluster01::> network port show
                                                             Speed (Mbps)
Node   Port      IPspace      Broadcast Domain Link   MTU    Admin/Oper
------ --------- ------------ ---------------- ----- ------- ------------
cluster01-01
       e0a       Cluster      Cluster          up     1500   auto/1000
       e0b       Cluster      Cluster          up     1500   auto/1000
       e0c       Default      Default          up     1500   auto/1000
       e0d       Default      Default          up     1500   auto/1000
cluster01-02
       e0a       Cluster      Cluster          up     1500   auto/1000
       e0b       Cluster      Cluster          up     1500   auto/1000
       e0c       Default      Default          up     1500   auto/1000
       e0d       Default      Default          up     1500   auto/1000

  2. Creazione di LIF intercluster sulla SVM di sistema:

    Versione di ONTAP

    Comando

    ONTAP 9.6 e versioni successive

    network interface create -vserver system_SVM -lif LIF_name -service-policy default-intercluster -home-node node -home-port port -address port_IP -netmask netmask

    ONTAP 9.5 e versioni precedenti

    network interface create -vserver system_SVM -lif LIF_name -role intercluster -home-node node -home-port port -address port_IP -netmask netmask

    Per la sintassi completa dei comandi, vedere la pagina man.

    Nell'esempio seguente vengono creati i LIF dell'intercluster “cluster01_icl01” e “cluster01_icl02”:

    cluster01::> network interface create -vserver cluster01 -lif cluster01_icl01 -service-
policy default-intercluster -home-node cluster01-01 -home-port e0c -address 192.168.1.201
-netmask 255.255.255.0

cluster01::> network interface create -vserver cluster01 -lif cluster01_icl02 -service-
policy default-intercluster -home-node cluster01-02 -home-port e0c -address 192.168.1.202
-netmask 255.255.255.0

  3. Verificare che le LIF dell'intercluster siano state create:

    Versione di ONTAP

    Comando

    ONTAP 9.6 e versioni successive

    network interface show -service-policy default-intercluster

    ONTAP 9.5 e versioni precedenti

    network interface show -role intercluster

    Per la sintassi completa dei comandi, vedere la pagina man.

    cluster01::> network interface show -service-policy default-intercluster
            Logical    Status     Network            Current       Current Is
Vserver     Interface  Admin/Oper Address/Mask       Node          Port    Home
----------- ---------- ---------- ------------------ ------------- ------- ----
cluster01
            cluster01_icl01
                       up/up      192.168.1.201/24   cluster01-01  e0c     true
            cluster01_icl02
                       up/up      192.168.1.202/24   cluster01-02  e0c     true

  4. Verificare che le LIF dell'intercluster siano ridondanti:

    Versione di ONTAP

    Comando

    ONTAP 9.6 e versioni successive

    network interface show –service-policy default-intercluster -failover

    ONTAP 9.5 e versioni precedenti

    network interface show -role intercluster -failover

    Per la sintassi completa dei comandi, vedere la pagina man.

    L'esempio seguente mostra che le LIF dell'intercluster “cluster01_icl01” e “cluster01_icl02” sulla porta “e0c” effettueranno il failover sulla porta “e0d”.

    cluster01::> network interface show -service-policy default-intercluster –failover
         Logical         Home                  Failover        Failover
Vserver  Interface       Node:Port             Policy          Group
-------- --------------- --------------------- --------------- --------
cluster01
         cluster01_icl01 cluster01-01:e0c   local-only      192.168.1.201/24
                            Failover Targets: cluster01-01:e0c,
                                              cluster01-01:e0d
         cluster01_icl02 cluster01-02:e0c   local-only      192.168.1.201/24
                            Failover Targets: cluster01-02:e0c,
                                              cluster01-02:e0d
Informazioni correlate

"Considerazioni sulla condivisione delle porte dati"

Creazione di una relazione peer del cluster

È necessario creare la relazione peer del cluster tra i cluster MetroCluster.

Creazione di una relazione peer del cluster

È possibile utilizzare cluster peer create per creare una relazione peer tra un cluster locale e remoto. Una volta creata la relazione peer, è possibile eseguire cluster peer create sul cluster remoto per autenticarlo nel cluster locale.

Prima di iniziare

  • È necessario aver creato le LIF di intercluster su ogni nodo dei cluster che vengono sottoposti a peering.

  • I cluster devono eseguire ONTAP 9.3 o versione successiva.

Fasi

  1. Sul cluster di destinazione, creare una relazione peer con il cluster di origine:

    cluster peer create -generate-passphrase -offer-expiration MM/DD/YYYY HH:MM:SS|1…​7days|1…​168hours -peer-addrs peer_LIF_IPs -ipspace ipspace

    Se si specificano entrambi -generate-passphrase e. -peer-addrs, Solo il cluster i cui LIF intercluster sono specificati in -peer-addrs può utilizzare la password generata.

    È possibile ignorare -ipspace Se non si utilizza un IPSpace personalizzato. Per la sintassi completa dei comandi, vedere la pagina man.

    Nell'esempio seguente viene creata una relazione peer del cluster su un cluster remoto non specificato:

    cluster02::> cluster peer create -generate-passphrase -offer-expiration 2days

                     Passphrase: UCa+6lRVICXeL/gq1WrK7ShR
                Expiration Time: 6/7/2017 08:16:10 EST
  Initial Allowed Vserver Peers: -
            Intercluster LIF IP: 192.140.112.101
              Peer Cluster Name: Clus_7ShR (temporary generated)

Warning: make a note of the passphrase - it cannot be displayed again.

  2. Nel cluster di origine, autenticare il cluster di origine nel cluster di destinazione:

    cluster peer create -peer-addrs peer_LIF_IPs -ipspace ipspace

    Per la sintassi completa dei comandi, vedere la pagina man.

    Nell'esempio seguente viene autenticato il cluster locale nel cluster remoto agli indirizzi IP LIF 192.140.112.101 e 192.140.112.102 dell'intercluster:

    cluster01::> cluster peer create -peer-addrs 192.140.112.101,192.140.112.102

Notice: Use a generated passphrase or choose a passphrase of 8 or more characters.
        To ensure the authenticity of the peering relationship, use a phrase or sequence of characters that would be hard to guess.

Enter the passphrase:
Confirm the passphrase:

Clusters cluster02 and cluster01 are peered.

    Inserire la passphrase per la relazione peer quando richiesto.

  3. Verificare che la relazione peer del cluster sia stata creata:

    cluster peer show -instance

    cluster01::> cluster peer show -instance

                               Peer Cluster Name: cluster02
                   Remote Intercluster Addresses: 192.140.112.101, 192.140.112.102
              Availability of the Remote Cluster: Available
                             Remote Cluster Name: cluster2
                             Active IP Addresses: 192.140.112.101, 192.140.112.102
                           Cluster Serial Number: 1-80-123456
                  Address Family of Relationship: ipv4
            Authentication Status Administrative: no-authentication
               Authentication Status Operational: absent
                                Last Update Time: 02/05 21:05:41
                    IPspace for the Relationship: Default

  4. Verificare la connettività e lo stato dei nodi nella relazione peer:

    cluster peer health show

    cluster01::> cluster peer health show
Node       cluster-Name                Node-Name
             Ping-Status               RDB-Health Cluster-Health  Avail…
---------- --------------------------- ---------  --------------- --------
cluster01-01
           cluster02                   cluster02-01
             Data: interface_reachable
             ICMP: interface_reachable true       true            true
                                       cluster02-02
             Data: interface_reachable
             ICMP: interface_reachable true       true            true
cluster01-02
           cluster02                   cluster02-01
             Data: interface_reachable
             ICMP: interface_reachable true       true            true
                                       cluster02-02
             Data: interface_reachable
             ICMP: interface_reachable true       true            true
Creazione di una relazione peer del cluster (ONTAP 9.2 e versioni precedenti)

È possibile utilizzare cluster peer create per avviare una richiesta di relazione di peering tra un cluster locale e remoto. Una volta richiesta la relazione peer dal cluster locale, è possibile eseguire cluster peer create sul cluster remoto per accettare la relazione.

Prima di iniziare

  • È necessario aver creato le LIF di intercluster su ogni nodo dei cluster in fase di peering.

  • Gli amministratori del cluster devono aver concordato la passphrase utilizzata da ciascun cluster per autenticarsi con l'altro.

Fasi

  1. Nel cluster di destinazione per la protezione dei dati, creare una relazione peer con il cluster di origine per la protezione dei dati:

    cluster peer create -peer-addrs peer_LIF_IPs -ipspace ipspace

    È possibile ignorare -ipspace Se non si utilizza un IPSpace personalizzato. Per la sintassi completa dei comandi, vedere la pagina man.

    Nell'esempio riportato di seguito viene creata una relazione di peer del cluster con il cluster remoto agli indirizzi IP LIF dell'intercluster 192.168.2.201 e 192.168.2.202:

    cluster02::> cluster peer create -peer-addrs 192.168.2.201,192.168.2.202
Enter the passphrase:
Please enter the passphrase again:

    Inserire la passphrase per la relazione peer quando richiesto.

  2. Nel cluster di origine per la protezione dei dati, autenticare il cluster di origine nel cluster di destinazione:

    cluster peer create -peer-addrs peer_LIF_IPs -ipspace ipspace

    Per la sintassi completa dei comandi, vedere la pagina man.

    Nell'esempio seguente viene autenticato il cluster locale nel cluster remoto agli indirizzi IP LIF 192.140.112.203 e 192.140.112.204 dell'intercluster:

    cluster01::> cluster peer create -peer-addrs 192.168.2.203,192.168.2.204
Please confirm the passphrase:
Please confirm the passphrase again:

    Inserire la passphrase per la relazione peer quando richiesto.

  3. Verificare che la relazione peer del cluster sia stata creata:

    cluster peer show –instance

    Per la sintassi completa dei comandi, vedere la pagina man.

    cluster01::> cluster peer show –instance
Peer Cluster Name: cluster01
Remote Intercluster Addresses: 192.168.2.201,192.168.2.202
Availability: Available
Remote Cluster Name: cluster02
Active IP Addresses: 192.168.2.201,192.168.2.202
Cluster Serial Number: 1-80-000013

  4. Verificare la connettività e lo stato dei nodi nella relazione peer:

    cluster peer health show

    Per la sintassi completa dei comandi, vedere la pagina man.

    cluster01::> cluster peer health show
Node       cluster-Name                Node-Name
             Ping-Status               RDB-Health Cluster-Health  Avail…
---------- --------------------------- ---------  --------------- --------
cluster01-01
           cluster02                   cluster02-01
             Data: interface_reachable
             ICMP: interface_reachable true       true            true
                                       cluster02-02
             Data: interface_reachable
             ICMP: interface_reachable true       true            true
cluster01-02
           cluster02                   cluster02-01
             Data: interface_reachable
             ICMP: interface_reachable true       true            true
                                       cluster02-02
             Data: interface_reachable
             ICMP: interface_reachable true       true            true

Mirroring degli aggregati root

È necessario eseguire il mirroring degli aggregati root per garantire la protezione dei dati.

A proposito di questa attività

Per impostazione predefinita, l'aggregato root viene creato come aggregato di tipo RAID-DP. È possibile modificare l'aggregato root da RAID-DP a aggregato di tipo RAID4. Il seguente comando modifica l'aggregato root per l'aggregato di tipo RAID4:

storage aggregate modify –aggregate aggr_name -raidtype raid4

Nota Nei sistemi non ADP, il tipo RAID dell'aggregato può essere modificato dal RAID-DP predefinito a RAID4 prima o dopo il mirroring dell'aggregato.
Fasi

  1. Eseguire il mirroring dell'aggregato root:

    storage aggregate mirror aggr_name

    Il seguente comando esegue il mirroring dell'aggregato root per “controller_A_1”:

    controller_A_1::> storage aggregate mirror aggr0_controller_A_1

    Questo esegue il mirroring dell'aggregato, quindi è costituito da un plex locale e da un plex remoto situati nel sito MetroCluster remoto.

  2. Ripetere il passaggio precedente per ciascun nodo della configurazione MetroCluster.

Informazioni correlate

"Gestione dello storage logico"

"Concetti di ONTAP"

Creazione di un aggregato di dati mirrorato su ciascun nodo

È necessario creare un aggregato di dati mirrorato su ciascun nodo del gruppo DR.

Prima di iniziare

  • È necessario sapere quali dischi o LUN di array verranno utilizzati nel nuovo aggregato.

  • Se nel sistema sono presenti più tipi di dischi (storage eterogeneo), è necessario comprendere come assicurarsi di selezionare il tipo di disco corretto.

A proposito di questa attività

  • I dischi e le LUN degli array sono di proprietà di un nodo specifico; quando si crea un aggregato, tutti i dischi dell'aggregato devono essere di proprietà dello stesso nodo, che diventa il nodo principale dell'aggregato.

  • I nomi degli aggregati devono essere conformi allo schema di denominazione stabilito al momento della pianificazione della configurazione MetroCluster.

    "Gestione di dischi e aggregati"

Fasi

  1. Visualizzare un elenco delle parti di ricambio disponibili:

    storage disk show -spare -owner node_name

  2. Creare l'aggregato:

    storage aggregate create -mirror true

    Se si è connessi al cluster nell'interfaccia di gestione del cluster, è possibile creare un aggregato su qualsiasi nodo del cluster. Per assicurarsi che l'aggregato venga creato su un nodo specifico, utilizzare -node o specificare i dischi di proprietà di quel nodo.

    È possibile specificare le seguenti opzioni:

    • Nodo principale dell'aggregato (ovvero, il nodo proprietario dell'aggregato durante il normale funzionamento)

    • Elenco di unità o LUN di array specifici da aggiungere all'aggregato

    • Numero di dischi da includere

      Nota Nella configurazione minima supportata, in cui è disponibile un numero limitato di dischi, è necessario utilizzare l'opzione force-Small-aggregate per consentire la creazione di un aggregato RAID-DP a tre dischi.

    • Stile checksum da utilizzare per l'aggregato

    • Tipo di dischi da utilizzare

    • Dimensioni delle unità da utilizzare

    • Velocità del disco da utilizzare

    • Tipo RAID per i gruppi RAID sull'aggregato

    • Numero massimo di unità o LUN di array che possono essere inclusi in un gruppo RAID

    • Se sono consentiti dischi con diversi RPM per ulteriori informazioni su queste opzioni, consultare la storage aggregate create pagina man.

      Il seguente comando crea un aggregato mirrorato con 10 dischi:

    cluster_A::> storage aggregate create aggr1_node_A_1 -diskcount 10 -node node_A_1 -mirror true
[Job 15] Job is queued: Create aggr1_node_A_1.
[Job 15] The job is starting.
[Job 15] Job succeeded: DONE

  3. Verificare il gruppo RAID e i dischi del nuovo aggregato:

    storage aggregate show-status -aggregate aggregate-name

Creazione di aggregati di dati senza mirror

È possibile creare aggregati di dati senza mirroring per i dati che non richiedono il mirroring ridondante fornito dalle configurazioni MetroCluster.

Prima di iniziare

  • È necessario sapere quali dischi o LUN di array verranno utilizzati nel nuovo aggregato.

  • Se nel sistema sono presenti più tipi di dischi (storage eterogeneo), è necessario comprendere come verificare che sia selezionato il tipo di disco corretto.

Esempio 1. A proposito di questa attività

ATTENZIONE: Nelle configurazioni MetroCluster FC, gli aggregati senza mirror saranno online solo dopo uno switchover se i dischi remoti nell'aggregato sono accessibili. In caso di errore degli ISL, il nodo locale potrebbe non essere in grado di accedere ai dati dei dischi remoti senza mirror. Il guasto di un aggregato può causare il riavvio del nodo locale.

Nota Gli aggregati senza mirror devono essere locali rispetto al nodo che li possiede.

  • I dischi e le LUN degli array sono di proprietà di un nodo specifico; quando si crea un aggregato, tutti i dischi dell'aggregato devono essere di proprietà dello stesso nodo, che diventa il nodo principale dell'aggregato.

  • I nomi degli aggregati devono essere conformi allo schema di denominazione stabilito al momento della pianificazione della configurazione MetroCluster.

  • Il "Gestione di dischi e aggregati" contiene ulteriori informazioni sugli aggregati di mirroring.

Fasi

  1. Visualizzare un elenco delle parti di ricambio disponibili:

    storage disk show -spare -owner node_name

  2. Creare l'aggregato:

    storage aggregate create

    Se si è connessi al cluster nell'interfaccia di gestione del cluster, è possibile creare un aggregato su qualsiasi nodo del cluster. Per verificare che l'aggregato sia creato su un nodo specifico, utilizzare -node o specificare i dischi di proprietà di quel nodo.

    È possibile specificare le seguenti opzioni:

    • Nodo principale dell'aggregato (ovvero, il nodo proprietario dell'aggregato durante il normale funzionamento)

    • Elenco di unità o LUN di array specifici da aggiungere all'aggregato

    • Numero di dischi da includere

    • Stile checksum da utilizzare per l'aggregato

    • Tipo di dischi da utilizzare

    • Dimensioni delle unità da utilizzare

    • Velocità del disco da utilizzare

    • Tipo RAID per i gruppi RAID sull'aggregato

    • Numero massimo di unità o LUN di array che possono essere inclusi in un gruppo RAID

    • Se sono consentiti dischi con diversi RPM per ulteriori informazioni su queste opzioni, consultare la storage aggregate create pagina man.

      Il seguente comando crea un aggregato senza mirror con 10 dischi:

    controller_A_1::> storage aggregate create aggr1_controller_A_1 -diskcount 10 -node controller_A_1
[Job 15] Job is queued: Create aggr1_controller_A_1.
[Job 15] The job is starting.
[Job 15] Job succeeded: DONE

  3. Verificare il gruppo RAID e i dischi del nuovo aggregato:

    storage aggregate show-status -aggregate aggregate-name

Implementazione della configurazione MetroCluster

È necessario eseguire metrocluster configure Comando per avviare la protezione dei dati in una configurazione MetroCluster.

Prima di iniziare

  • Su ciascun cluster devono essere presenti almeno due aggregati di dati mirrorati non root.

    È possibile eseguire il mirroring o il mirroring di aggregati di dati aggiuntivi.

    Verificare i tipi di aggregato:

    storage aggregate show

    Nota Se si desidera utilizzare un singolo aggregato di dati mirrorato, vedere "Configurare il software MCC in ONTAP" per istruzioni.

  • Lo stato ha-config dei controller e dello chassis deve essere “mcc-2n”.

A proposito di questa attività

È possibile eseguire il metrocluster configure Per abilitare la configurazione MetroCluster, eseguire una sola volta il comando su uno dei nodi. Non è necessario eseguire il comando su ciascuno dei siti o nodi e non è importante il nodo o il sito su cui si sceglie di eseguire il comando.

Fasi

  1. Configurare MetroCluster nel seguente formato:

    Se la configurazione di MetroCluster dispone di…​

    Quindi…​

    Aggregati di dati multipli

    Dal prompt di qualsiasi nodo, configurare MetroCluster:

    metrocluster configure node-name

    Un singolo aggregato di dati mirrorato

    1. Dal prompt di qualsiasi nodo, passare al livello di privilegio avanzato:

      set -privilege advanced

      Rispondere con “y” quando viene richiesto di passare alla modalità avanzata e viene visualizzato il prompt della modalità avanzata (*).

    2. Configurare MetroCluster con -allow-with-one-aggregate true parametro:

      metrocluster configure -allow-with-one-aggregate true node-name

    3. Tornare al livello di privilegio admin:
      set -privilege admin
    Nota La Best practice consiste nell'avere più aggregati di dati. Se il primo gruppo DR dispone di un solo aggregato e si desidera aggiungere un gruppo DR con un aggregato, è necessario spostare il volume di metadati dal singolo aggregato di dati. Per ulteriori informazioni su questa procedura, vedere "Spostamento di un volume di metadati nelle configurazioni MetroCluster".

    Il seguente comando abilita la configurazione MetroCluster su tutti i nodi del gruppo DR che contiene “controller_A_1”:

    cluster_A::*> metrocluster configure -node-name controller_A_1

[Job 121] Job succeeded: Configure is successful.

  2. Verificare lo stato della rete sul sito A:

    network port show

    L'esempio seguente mostra l'utilizzo della porta di rete:

    cluster_A::> network port show
                                                          Speed (Mbps)
Node   Port      IPspace   Broadcast Domain Link   MTU    Admin/Oper
------ --------- --------- ---------------- ----- ------- ------------
controller_A_1
       e0a       Cluster   Cluster          up     9000  auto/1000
       e0b       Cluster   Cluster          up     9000  auto/1000
       e0c       Default   Default          up     1500  auto/1000
       e0d       Default   Default          up     1500  auto/1000
       e0e       Default   Default          up     1500  auto/1000
       e0f       Default   Default          up     1500  auto/1000
       e0g       Default   Default          up     1500  auto/1000

7 entries were displayed.

  3. Verificare la configurazione MetroCluster da entrambi i siti nella configurazione MetroCluster.

    1. Verificare la configurazione dal sito A:
      metrocluster show

      cluster_A::> metrocluster show

Cluster                   Entry Name          State
------------------------- ------------------- -----------
 Local: cluster_A         Configuration state configured
                          Mode                normal
                          AUSO Failure Domain auso-on-cluster-disaster
Remote: cluster_B         Configuration state configured
                          Mode                normal
                          AUSO Failure Domain auso-on-cluster-disaster

    2. Verificare la configurazione dal sito B:
      metrocluster show

      cluster_B::> metrocluster show
Cluster                   Entry Name          State
------------------------- ------------------- -----------
 Local: cluster_B         Configuration state configured
                          Mode                normal
                          AUSO Failure Domain auso-on-cluster-disaster
Remote: cluster_A         Configuration state configured
                          Mode                normal
                          AUSO Failure Domain auso-on-cluster-disaster

Configurazione di bridge FC-SAS per il monitoraggio dello stato di salute

Nei sistemi con versioni di ONTAP precedenti alla 9.8, se la configurazione include bridge FC-SAS, è necessario eseguire alcune procedure di configurazione speciali per monitorare i bridge FC-SAS nella configurazione MetroCluster.

  • Gli strumenti di monitoraggio SNMP di terze parti non sono supportati per i bridge FibreBridge.

  • A partire da ONTAP 9.8, i bridge FC-SAS vengono monitorati per impostazione predefinita tramite connessioni in-band e non è necessaria alcuna configurazione aggiuntiva.

Nota A partire da ONTAP 9.8, la storage bridge il comando viene sostituito con system bridge. La procedura riportata di seguito mostra storage bridge Ma se si utilizza ONTAP 9.8 o versione successiva, il comando system bridge è preferibile utilizzare il comando.
Fasi

  1. Dal prompt del cluster ONTAP, aggiungere il bridge al monitoraggio dello stato di salute:

    1. Aggiungere il bridge utilizzando il comando per la versione di ONTAP in uso:

      Versione di ONTAP

      Comando

      ONTAP 9.5 e versioni successive

      storage bridge add -address 0.0.0.0 -managed-by in-band -name bridge-name

      ONTAP 9.4 e versioni precedenti

      storage bridge add -address bridge-ip-address -name bridge-name

    2. Verificare che il bridge sia stato aggiunto e configurato correttamente:

      storage bridge show

      A causa dell'intervallo di polling, potrebbero essere necessari 15 minuti per riflettere tutti i dati. Il monitor dello stato di ONTAP può contattare e monitorare il bridge se il valore nella colonna “Satus” è “ok” e se vengono visualizzate altre informazioni, come il nome globale (WWN).

      L'esempio seguente mostra che i bridge FC-SAS sono configurati:

    controller_A_1::> storage bridge show

Bridge              Symbolic Name Is Monitored  Monitor Status  Vendor Model                Bridge WWN
------------------  ------------- ------------  --------------  ------ -----------------    ----------
ATTO_10.10.20.10  atto01        true          ok              Atto   FibreBridge 7500N   	20000010867038c0
ATTO_10.10.20.11  atto02        true          ok              Atto   FibreBridge 7500N   	20000010867033c0
ATTO_10.10.20.12  atto03        true          ok              Atto   FibreBridge 7500N   	20000010867030c0
ATTO_10.10.20.13  atto04        true          ok              Atto   FibreBridge 7500N   	2000001086703b80

4 entries were displayed

 controller_A_1::>

Verifica della configurazione MetroCluster

È possibile verificare che i componenti e le relazioni nella configurazione di MetroCluster funzionino correttamente. Dopo la configurazione iniziale e dopo aver apportato eventuali modifiche alla configurazione MetroCluster, è necessario eseguire un controllo. È inoltre necessario eseguire un controllo prima di un'operazione di switchover negoziata (pianificata) o di switchback.

Se il metrocluster check run il comando viene emesso due volte in un breve periodo di tempo su uno o entrambi i cluster, può verificarsi un conflitto e il comando potrebbe non raccogliere tutti i dati. Successivo metrocluster check show i comandi non mostrano l'output previsto.

  1. Controllare la configurazione:

    metrocluster check run

    Il comando viene eseguito come processo in background e potrebbe non essere completato immediatamente.

    cluster_A::> metrocluster check run
The operation has been started and is running in the background. Wait for
it to complete and run "metrocluster check show" to view the results. To
check the status of the running metrocluster check operation, use the command,
"metrocluster operation history show -job-id 2245"
    cluster_A::> metrocluster check show

Component           Result
------------------- ---------
nodes               ok
lifs                ok
config-replication  ok
aggregates          ok
clusters            ok
connections         ok
volumes             ok
7 entries were displayed.

  2. Visualizzazione di risultati più dettagliati:

    metrocluster check run

    metrocluster check aggregate show

    metrocluster check cluster show

    metrocluster check config-replication show

    metrocluster check lif show

    metrocluster check node show

    Il metrocluster check show i comandi mostrano i risultati dei più recenti metrocluster check run comando. Eseguire sempre il metrocluster check run prima di utilizzare metrocluster check show i comandi in modo che le informazioni visualizzate siano aggiornate.

    Nell'esempio riportato di seguito viene illustrato il metrocluster check aggregate show Output di comando per una configurazione MetroCluster a quattro nodi sana:

    cluster_A::> metrocluster check aggregate show

Last Checked On: 8/5/2014 00:42:58

Node                  Aggregate                  Check                      Result
---------------       --------------------       ---------------------      ---------
controller_A_1        controller_A_1_aggr0
                                                 mirroring-status           ok
                                                 disk-pool-allocation       ok
                                                 ownership-state            ok
                      controller_A_1_aggr1
                                                 mirroring-status           ok
                                                 disk-pool-allocation       ok
                                                 ownership-state            ok
                      controller_A_1_aggr2
                                                 mirroring-status           ok
                                                 disk-pool-allocation       ok
                                                 ownership-state            ok


controller_A_2        controller_A_2_aggr0
                                                 mirroring-status           ok
                                                 disk-pool-allocation       ok
                                                 ownership-state            ok
                      controller_A_2_aggr1
                                                 mirroring-status           ok
                                                 disk-pool-allocation       ok
                                                 ownership-state            ok
                      controller_A_2_aggr2
                                                 mirroring-status           ok
                                                 disk-pool-allocation       ok
                                                 ownership-state            ok

18 entries were displayed.

    Nell'esempio riportato di seguito viene illustrato il metrocluster check cluster show Output di comando per una configurazione MetroCluster a quattro nodi sana. Indica che i cluster sono pronti per eseguire uno switchover negoziato, se necessario.

    Last Checked On: 9/13/2017 20:47:04

Cluster               Check                           Result
--------------------- ------------------------------- ---------
mccint-fas9000-0102
                      negotiated-switchover-ready     not-applicable
                      switchback-ready                not-applicable
                      job-schedules                   ok
                      licenses                        ok
                      periodic-check-enabled          ok
mccint-fas9000-0304
                      negotiated-switchover-ready     not-applicable
                      switchback-ready                not-applicable
                      job-schedules                   ok
                      licenses                        ok
                      periodic-check-enabled          ok
10 entries were displayed.
Informazioni correlate

"Gestione di dischi e aggregati"

"Gestione di rete e LIF"

Verifica degli errori di configurazione di MetroCluster con Config Advisor

È possibile accedere al sito di supporto NetApp e scaricare lo strumento Config Advisor per verificare la presenza di errori di configurazione comuni.

Config Advisor è uno strumento per la convalida della configurazione e il controllo dello stato di salute. È possibile implementarlo sia in siti sicuri che in siti non sicuri per la raccolta di dati e l'analisi del sistema.

Nota Il supporto per Config Advisor è limitato e disponibile solo online.

  1. Accedere alla pagina di download di Config Advisor e scaricare lo strumento.

    "Download NetApp: Config Advisor"

  2. Eseguire Config Advisor, esaminare l'output dello strumento e seguire le raccomandazioni nell'output per risolvere eventuali problemi rilevati.

Verifica dello switchover, della riparazione e dello switchback

Verificare le operazioni di switchover, riparazione e switchback della configurazione MetroCluster.

  1. Utilizzare le procedure per lo switchover negoziato, la riparazione e lo switchback descritte nella "Eseguire lo switchover, la riparazione e lo switchback".

Protezione dei file di backup della configurazione

È possibile fornire una protezione aggiuntiva per i file di backup della configurazione del cluster specificando un URL remoto (HTTP o FTP) in cui verranno caricati i file di backup della configurazione oltre alle posizioni predefinite nel cluster locale.

  1. Impostare l'URL della destinazione remota per i file di backup della configurazione:

    system configuration backup settings modify URL-of-destination

    Il "Gestione dei cluster con la CLI" Contiene ulteriori informazioni nella sezione Gestione dei backup di configurazione.