Note di rilascio di MetroCluster
Configurazione del software MetroCluster in ONTAP
Suggerisci modifiche
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.
-
Prima di iniziare il processo di configurazione, raccogliere gli indirizzi IP richiesti per i moduli controller.
-
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.
Questa attività è necessaria solo per le configurazioni stretch che utilizzano bridge FC-SAS.
-
Al prompt DEL CARICATORE, riportare le variabili ambientali alle impostazioni predefinite:
set-defaults -
Avviare il nodo in modalità manutenzione, quindi configurare le impostazioni per gli HBA nel sistema:
-
Avviare in modalità di manutenzione:
boot_ontap maint -
Verificare le impostazioni correnti delle porte:
ucadmin show -
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_nameEthernet CNA
ucadmin modify -mode cna adapter_nameDestinazione FC
fcadmin config -t target adapter_nameIniziatore FC
fcadmin config -t initiator adapter_name -
-
Uscire dalla modalità di manutenzione:
haltDopo aver eseguito il comando, attendere che il nodo si arresti al prompt DEL CARICATORE.
-
Riavviare il nodo in modalità Maintenance per rendere effettive le modifiche di configurazione:
boot_ontap maint -
Verificare le modifiche apportate:
Se si dispone di questo tipo di HBA…
Utilizzare questo comando…
CNA
ucadmin showFC
fcadmin show -
Uscire dalla modalità di manutenzione:
haltDopo aver eseguito il comando, attendere che il nodo si arresti al prompt DEL CARICATORE.
-
Avviare il nodo dal menu di boot:
boot_ontap menuDopo aver eseguito il comando, attendere che venga visualizzato il menu di avvio.
-
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.
Questa attività deve essere eseguita in modalità manutenzione.
|
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. |
-
Disattivare le porte:
storage disable adapter 1astorage 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. *>
-
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 -
Impostare le porte a e b sulla modalità FC-VI:
ucadmin modify -adapter 1a -type fcviIl 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.
-
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 -
Spegnere il controller, quindi riavviarlo in modalità di manutenzione.
-
Confermare la modifica della configurazione:
ucadmin show localNode 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.
Il sistema deve essere in modalità di manutenzione.
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.
-
Se il sistema è stato ricevuto dalla fabbrica, confermare le assegnazioni degli shelf:
disk show –v -
Se necessario, è possibile assegnare esplicitamente i dischi sugli shelf di dischi collegati al pool appropriato
disk assignGli 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.
-
In caso contrario, avviare ciascun sistema in modalità di manutenzione.
-
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 poolSe 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
-
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 poolSe 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
-
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.
Il sistema deve essere in modalità di manutenzione.
-
In modalità Maintenance (manutenzione), visualizzare lo stato ha del modulo controller e dello chassis:
ha-config showIl modulo controller e lo chassis devono visualizzare il valore “mcc-2n”.
-
Se lo stato di sistema visualizzato del controller non è “mcc-2n”, impostare lo stato ha per il controller:
ha-config modify controller mcc-2n -
Se lo stato di sistema visualizzato dello chassis non è “mcc-2n”, impostare lo stato ha per lo chassis:
ha-config modify chassis mcc-2nArrestare il nodo.
Attendere che il nodo sia tornato al prompt DEL CARICATORE.
-
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.
Non è necessario aver configurato il Service Processor.
Questa attività è destinata alle configurazioni MetroCluster a due nodi che utilizzano lo storage NetApp nativo.
I nuovi sistemi MetroCluster sono preconfigurati; non è necessario eseguire questa procedura. Tuttavia, è necessario configurare AutoSupport.
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)"
-
Accendere il primo nodo.
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}: -
Creare un nuovo cluster:
create -
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]: -
Accettare l'impostazione predefinita del sistema “yes” premendo Invio oppure immettere i propri valori digitando “no” e premendo Invio.
-
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.
-
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 showL'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 setupcomando.
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.
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.
-
Elencare le porte nel cluster:
network port showPer 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 -
Determinare quali porte sono disponibili per la comunicazione tra cluster:
network interface show -fields home-port,curr-portPer 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 -
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_portsNell'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
-
Verificare che il gruppo di failover sia stato creato:
network interface failover-groups showPer 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 -
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_groupONTAP 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_groupPer 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
-
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-interclusterONTAP 9.5 e versioni precedenti
network interface show -role interclusterPer 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 -
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 -failoverIn ONTAP 9.5 e versioni precedenti
network interface show -role intercluster -failoverPer 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
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.
-
Elencare le porte nel cluster:
network port showPer 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 -
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 netmaskONTAP 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 netmaskPer 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
-
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-interclusterONTAP 9.5 e versioni precedenti
network interface show -role interclusterPer 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 -
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 -failoverONTAP 9.5 e versioni precedenti
network interface show -role intercluster -failoverPer 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
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.
-
È 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.
-
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 ipspaceSe si specificano entrambi
-generate-passphrasee.-peer-addrs, Solo il cluster i cui LIF intercluster sono specificati in-peer-addrspuò utilizzare la password generata.È possibile ignorare
-ipspaceSe 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. -
Nel cluster di origine, autenticare il cluster di origine nel cluster di destinazione:
cluster peer create -peer-addrs peer_LIF_IPs -ipspace ipspacePer 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.
-
Verificare che la relazione peer del cluster sia stata creata:
cluster peer show -instancecluster01::> 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 -
Verificare la connettività e lo stato dei nodi nella relazione peer:
cluster peer health showcluster01::> 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.
-
È 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.
-
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
-ipspaceSe 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.
-
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 ipspacePer 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.
-
Verificare che la relazione peer del cluster sia stata creata:
cluster peer show –instancePer 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
-
Verificare la connettività e lo stato dei nodi nella relazione peer:
cluster peer health showPer 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.
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
|
|
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. |
-
Eseguire il mirroring dell'aggregato root:
storage aggregate mirror aggr_nameIl 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.
-
Ripetere il passaggio precedente per ciascun nodo della configurazione MetroCluster.
Creazione di un aggregato di dati mirrorato su ciascun nodo
È necessario creare un aggregato di dati mirrorato su ciascun nodo del gruppo DR.
-
È 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.
-
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.
-
Visualizzare un elenco delle parti di ricambio disponibili:
storage disk show -spare -owner node_name -
Creare l'aggregato:
storage aggregate create -mirror trueSe 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
-nodeo 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
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 createpagina 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
-
-
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.
-
È 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.
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.
|
|
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.
-
Visualizzare un elenco delle parti di ricambio disponibili:
storage disk show -spare -owner node_name -
Creare l'aggregato:
storage aggregate createSe 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
-nodeo 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 createpagina 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
-
-
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.
-
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
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”.
È 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.
-
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-nameUn singolo aggregato di dati mirrorato
-
Dal prompt di qualsiasi nodo, passare al livello di privilegio avanzato:
set -privilege advancedRispondere con “y” quando viene richiesto di passare alla modalità avanzata e viene visualizzato il prompt della modalità avanzata (*).
-
Configurare MetroCluster con
-allow-with-one-aggregate trueparametro:metrocluster configure -allow-with-one-aggregate true node-name -
Tornare al livello di privilegio admin:
set -privilege admin
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.
-
-
Verificare lo stato della rete sul sito A:
network port showL'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. -
Verificare la configurazione MetroCluster da entrambi i siti nella configurazione MetroCluster.
-
Verificare la configurazione dal sito A:
metrocluster showcluster_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 -
Verificare la configurazione dal sito B:
metrocluster showcluster_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.
|
|
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.
|
-
Dal prompt del cluster ONTAP, aggiungere il bridge al monitoraggio dello stato di salute:
-
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-nameONTAP 9.4 e versioni precedenti
storage bridge add -address bridge-ip-address -name bridge-name -
Verificare che il bridge sia stato aggiunto e configurato correttamente:
storage bridge showA 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.
-
Controllare la configurazione:
metrocluster check runIl 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.
-
Visualizzazione di risultati più dettagliati:
metrocluster check runmetrocluster check aggregate showmetrocluster check cluster showmetrocluster check config-replication showmetrocluster check lif showmetrocluster check node showIl
metrocluster check showi comandi mostrano i risultati dei più recentimetrocluster check runcomando. Eseguire sempre ilmetrocluster check runprima di utilizzaremetrocluster check showi comandi in modo che le informazioni visualizzate siano aggiornate.Nell'esempio riportato di seguito viene illustrato il
metrocluster check aggregate showOutput 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 showOutput 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.
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.
|
|
Il supporto per Config Advisor è limitato e disponibile solo online. |
-
Accedere alla pagina di download di Config Advisor e scaricare lo strumento.
-
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.
-
Utilizzare le procedure per lo switchover negoziato, la riparazione e lo switchback indicate in "Ripristino in caso di disastro".
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.
-
Impostare l'URL della destinazione remota per i file di backup della configurazione:
system configuration backup settings modify URL-of-destinationIl "Gestione dei cluster con la CLI" Contiene ulteriori informazioni nella sezione Gestione dei backup di configurazione.