Skip to main content
ONTAP MetroCluster
La version française est une traduction automatique. La version anglaise prévaut sur la française en cas de divergence.

Configuration du logiciel MetroCluster dans ONTAP

Contributeurs
PDF

Vous devez installer chaque nœud dans la configuration MetroCluster de ONTAP, y compris les configurations au niveau des nœuds et la configuration des nœuds en deux sites. Vous devez également implémenter la relation MetroCluster entre les deux sites.

logiciel de configuration des nœuds et clusters haute qualité de flux de production
Étapes

  1. Collectez les adresses IP requises pour les modules de contrôleur avant de commencer le processus de configuration.

  2. Complétez la fiche d'informations sur le réseau IP pour le site A.

Fiche d'informations sur le réseau IP pour le site A

Avant de configurer le système, vous devez obtenir des adresses IP et d'autres informations réseau pour le premier site MetroCluster (site A) de votre administrateur réseau.

Informations de création du site À partir d'un cluster

Lors de la création du cluster, vous avez besoin des informations suivantes :

Type d'information

Vos valeurs

Nom du cluster. Exemple utilisé dans cette information : site_A

Domaine DNS

Serveurs de noms DNS

Emplacement

Mot de passe administrateur

Information sur un nœud du site

Vous avez besoin d'une adresse IP de gestion, d'un masque de réseau et d'une passerelle par défaut pour chaque nœud du cluster.

Nœud

Port

Adresse IP

Masque de réseau

Passerelle par défaut

Nœud 1. Exemple utilisé dans ces informations : Controller_A_1

Nœud 2. Non requis si vous utilisez une configuration MetroCluster à deux nœuds (un nœud sur chaque site).

Exemple utilisé dans ces informations : Controller_A_2

Site A LIFs et ports pour le peering de cluster

Pour chaque nœud du cluster, vous devez disposer des adresses IP de deux LIF intercluster, y compris un masque de réseau et une passerelle par défaut. Les LIFs intercluster sont utilisés pour mutualiser les clusters.

Nœud

Port

Adresse IP du LIF intercluster

Masque de réseau

Passerelle par défaut

IC node 1 LIF 1

Nœud 1 ci LIF 2

Informations sur le serveur de temps du site A.

Vous devez synchroniser l'heure, qui nécessite un ou plusieurs serveurs de temps NTP.

Nœud

Nom d'hôte

Adresse IP

Masque de réseau

Passerelle par défaut

Serveur NTP 1

Serveur NTP 2

Site A nbsp; informations AutoSupport

Vous devez configurer le AutoSupport sur chaque nœud, qui nécessite les informations suivantes :

Type d'information

Vos valeurs

De l'adresse e-mail

Hôtes de messagerie

Noms ou adresses IP

Protocole de transport

HTTP, HTTPS OU SMTP

Serveur proxy

Adresses e-mail ou listes de distribution du destinataire

Messages longs

Messages concis

Site A informations sur le processeur de service

Vous devez activer l'accès au processeur de service de chaque nœud pour le dépannage et la maintenance. Pour ce faire, les informations réseau suivantes sont nécessaires pour chaque nœud :

Nœud

Adresse IP

Masque de réseau

Passerelle par défaut

Nœud 1

Fiche d'informations sur le réseau IP pour le site B

Avant de configurer le système, vous devez obtenir des adresses IP et d'autres informations réseau pour le second site MetroCluster (site B) de votre administrateur réseau.

Informations de création de cluster du site B

Lors de la création du cluster, vous avez besoin des informations suivantes :

Type d'information

Vos valeurs

Nom du cluster. Exemple utilisé dans cette information : site_B

Domaine DNS

Serveurs de noms DNS

Emplacement

Mot de passe administrateur

Informations sur le nœud du site B.

Vous avez besoin d'une adresse IP de gestion, d'un masque de réseau et d'une passerelle par défaut pour chaque nœud du cluster.

Nœud

Port

Adresse IP

Masque de réseau

Passerelle par défaut

Nœud 1. Exemple utilisé dans ces informations : Controller_B_1

Nœud 2. Non requis pour les configurations MetroCluster à deux nœuds (un nœud sur chaque site).

Exemple utilisé dans ces informations : Controller_B_2

Les LIF du site B et les ports pour le peering de clusters

Pour chaque nœud du cluster, vous devez disposer des adresses IP de deux LIF intercluster, y compris un masque de réseau et une passerelle par défaut. Les LIFs intercluster sont utilisés pour mutualiser les clusters.

Nœud

Port

Adresse IP du LIF intercluster

Masque de réseau

Passerelle par défaut

IC node 1 LIF 1

Nœud 1 ci LIF 2

Informations sur le serveur de temps du site B.

Vous devez synchroniser l'heure, qui nécessite un ou plusieurs serveurs de temps NTP.

Nœud

Nom d'hôte

Adresse IP

Masque de réseau

Passerelle par défaut

Serveur NTP 1

Serveur NTP 2

Site B nbsp; informations AutoSupport

Vous devez configurer le AutoSupport sur chaque nœud, qui nécessite les informations suivantes :

Type d'information

Vos valeurs

De l'adresse e-mail

Hôtes de messagerie

Noms ou adresses IP

Protocole de transport

HTTP, HTTPS OU SMTP

Serveur proxy

Adresses e-mail ou listes de distribution du destinataire

Messages longs

Messages concis

Site B nbsp; informations SP

Vous devez activer l'accès au processeur de service de chaque nœud pour le dépannage et la maintenance. Pour ce faire, vous devez disposer des informations réseau suivantes pour chaque nœud :

Nœud

Adresse IP

Masque de réseau

Passerelle par défaut

Nœud 1 (contrôleur_B_1)

Similarités et différences entre les configurations cluster standard et MetroCluster

La configuration des nœuds de chaque cluster dans une configuration MetroCluster est similaire à celle des nœuds d'un cluster standard.

La configuration MetroCluster est basée sur deux clusters standard. Physiquement, la configuration doit être symétrique. Chaque nœud présente la même configuration matérielle et tous les composants MetroCluster doivent être câblés et configurés. Cependant, la configuration logicielle de base des nœuds dans une configuration MetroCluster est identique à celle des nœuds d'un cluster standard.

Étape de configuration

Configuration standard en cluster

Configuration MetroCluster

Configurez la gestion, le cluster et la LIF de données sur chaque nœud.

La même chose dans les deux types de clusters

Configurer l'agrégat root.

La même chose dans les deux types de clusters

Configurez le cluster sur un nœud.

La même chose dans les deux types de clusters

Joignez l'autre nœud au cluster.

La même chose dans les deux types de clusters

Créez un agrégat racine en miroir.

Facultatif

Obligatoire

Peer-to-peer des clusters

Facultatif

Obligatoire

Activez la configuration MetroCluster.

Restauration des paramètres par défaut du système et configuration du type de HBA sur un module de contrôleur

Pour garantir la réussite de l'installation de MetroCluster, réinitialisez et restaurez les valeurs par défaut sur les modules de contrôleur.

Important

Cette tâche n'est requise que pour les configurations étendues utilisant des ponts FC-SAS.

Étapes

  1. Dans l'invite DU CHARGEUR, renvoie les variables environnementales à leur paramètre par défaut :

    set-defaults

  2. Démarrer le nœud en mode Maintenance, puis configurer les paramètres des HBA du système :

    1. Démarrage en mode maintenance :

      boot_ontap maint

    2. Vérifiez les paramètres actuels des ports :

      ucadmin show

    3. Mettez à jour les paramètres de port selon vos besoins.

    Si vous disposez de ce type de HBA et du mode souhaité…​

    Utilisez cette commande…​

    FC CNA

    ucadmin modify -m fc -t initiator adapter_name

    Ethernet CNA

    ucadmin modify -mode cna adapter_name

    Cible FC

    fcadmin config -t target adapter_name

    Initiateur FC

    fcadmin config -t initiator adapter_name

  3. Quitter le mode Maintenance :

    halt

    Une fois que vous avez exécuté la commande, attendez que le nœud s'arrête à l'invite DU CHARGEUR.

  4. Redémarrez le nœud en mode maintenance pour que les modifications de configuration prennent effet :

    boot_ontap maint

  5. Vérifiez les modifications que vous avez effectuées :

    Si vous disposez de ce type de HBA…​

    Utilisez cette commande…​

    CNA

    ucadmin show

    FC

    fcadmin show

  6. Quitter le mode Maintenance :

    halt

    Une fois que vous avez exécuté la commande, attendez que le nœud s'arrête à l'invite DU CHARGEUR.

  7. Démarrez le nœud sur le menu de démarrage :

    boot_ontap menu

    Une fois que vous avez exécuté la commande, attendez que le menu de démarrage s'affiche.

  8. Effacez la configuration du nœud en tapant « wipconconfig » à l'invite du menu de démarrage, puis appuyez sur entrée.

    L'écran suivant affiche l'invite du menu de démarrage :

    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.

Configuration des ports FC-VI sur une carte X1132A-R6 à quatre ports sur les systèmes FAS8020

Si vous utilisez la carte X1132A-R6 à quatre ports sur un système FAS8020, vous pouvez passer en mode de maintenance pour configurer les ports 1a et 1b pour FC-VI et pour l'utilisation d'un initiateur. Cela n'est pas nécessaire pour les systèmes MetroCluster reçus en usine, dans lesquels les ports sont configurés de façon appropriée pour votre configuration.

Description de la tâche

Cette tâche doit être effectuée en mode Maintenance.

Remarque La conversion d'un port FC en port FC-VI avec la commande ucadmin n'est prise en charge que sur les systèmes FAS8020 et AFF 8020. La conversion de ports FC en ports FCVI n'est pas prise en charge sur toute autre plateforme.
Étapes

  1. Désactiver les ports :

    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. Vérifiez que les ports sont désactivés :

    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. Définir les ports a et b en mode FC-VI :

    ucadmin modify -adapter 1a -type fcvi

    La commande définit le mode sur les deux ports de la paire de ports 1a et 1b (même si seul 1a est spécifié dans la commande).

    *> 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. Vérifiez que la modification est en attente :

    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. Arrêter le contrôleur, puis redémarrer en mode maintenance.

  6. Confirmer le changement de configuration :

    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.

Vérification de l'affectation du disque en mode maintenance dans une configuration à deux nœuds

Avant de démarrer entièrement le système sur ONTAP, vous pouvez également démarrer le système en mode maintenance et vérifier l'affectation des disques sur les nœuds. Il convient d'attribuer aux disques pour créer une configuration entièrement symétrique avec les deux sites possédant leurs propres tiroirs disques et servant les données, où chaque nœud et chaque pool disposent d'un nombre égal de disques en miroir qui leur sont affectés.

Avant de commencer

Le système doit être en mode Maintenance.

Description de la tâche

Les attributions de disques des nouveaux systèmes MetroCluster sont réalisées avant l'expédition.

Le tableau suivant présente des exemples d'affectations de pools pour une configuration MetroCluster. Les disques sont affectés à des pools par tiroir.

Tiroir disque (exemple name)…​

Sur le site…​

Appartient à…​

Et est attribué à ce nœud…​

Tiroir disque 1 (tiroir_A_1_1)

Site A

Nœud A 1

Pool 0

Tiroir disque 2 (tiroir_A_1_3)

Tiroir disque 3 (tiroir_B_1_1)

Nœud B 1

Piscine 1

Tiroir disque 4 (tiroir_B_1_3)

Tiroir disque 9 (tiroir_B_1_2)

Site B

Nœud B 1

Pool 0

Tiroir disque 10 (tiroir_B_1_4)

Tiroir disque 11 (tiroir_A_1_2)

Nœud A 1

Si votre configuration inclut des tiroirs disques DS460C, il est conseillé d'attribuer manuellement les disques en suivant les instructions suivantes pour chaque tiroir 12 disques :

Affectez ces disques dans le tiroir…​

À ce nœud et pool…​

1 - 6

Pool du nœud local 0

7 - 12

Pool du partenaire de reprise après incident 1

Ce modèle d'affectation des disques minimise l'effet sur un agrégat en cas de mise hors ligne d'un tiroir.

Étapes

  1. Si vous avez reçu l'usine de votre système, confirmez les attributions de tiroirs :

    disk show –v

  2. Si nécessaire, vous pouvez explicitement attribuer des disques aux tiroirs disques connectés au pool approprié

    disk assign

    Les tiroirs disques du même site que le nœud sont affectés au pool 0 et les tiroirs disques situés sur le site partenaire sont affectés au pool 1. Vous devez affecter un nombre égal de tiroirs à chaque pool.

    1. Si ce n'est pas le cas, démarrez chaque système en mode maintenance.

    2. Sur le nœud du site A, attribuer systématiquement les tiroirs disques locaux à pool 0 et les tiroirs disques distants à pool 1:
      disk assign -shelf disk_shelf_name -p pool

      Si le contrôleur de stockage node_A_1 dispose de quatre tiroirs, vous exécutez les commandes suivantes :

      *> 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. Sur le nœud du site distant (site B), attribuer systématiquement ses tiroirs disques locaux à Pool 0 et ses tiroirs disques distants à pool 1:
      disk assign -shelf disk_shelf_name -p pool

      Si le contrôleur de stockage node_B_1 dispose de quatre tiroirs, vous exécutez les commandes suivantes :

    *> 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. Affiche les ID de tiroir disque et les baies pour chaque disque :
      disk show –v

Vérification de l'état des composants HA

Dans une configuration MetroCluster étendue qui n'est pas préconfigurée en usine, vous devez vérifier que l'état HA du contrôleur et du composant de châssis est défini sur « mcc-2n pour qu'ils s'démarrent correctement. Pour les systèmes reçus en usine, cette valeur est préconfigurée et vous n'avez pas besoin de la vérifier.

Avant de commencer

Le système doit être en mode Maintenance.

Étapes

  1. En mode Maintenance, afficher l'état HA du module de contrôleur et du châssis :

    ha-config show

    Le module de contrôleur et le châssis doivent indiquer la valeur "mcc-2n".

  2. Si l'état système affiché du contrôleur n'est pas « mcc-2n », définissez l'état HA du contrôleur :

    ha-config modify controller mcc-2n

  3. Si l'état système affiché du châssis n'est pas “mcc-2n”, définissez l'état HA du châssis :

    ha-config modify chassis mcc-2n

    Arrêtez le nœud.

    Attendez que le nœud soit de nouveau à l'invite DU CHARGEUR.

  4. Répétez cette procédure sur chaque nœud de la configuration MetroCluster.

Configuration d'ONTAP dans une configuration MetroCluster à deux nœuds

Dans une configuration MetroCluster à deux nœuds, sur chaque cluster, vous devez démarrer le nœud, quitter l'assistant de configuration du cluster et utiliser cluster setup commande permettant de configurer le nœud dans un cluster à un seul nœud.

Avant de commencer

Vous ne devez pas avoir configuré le processeur de service.

Description de la tâche

Cette tâche est destinée aux configurations MetroCluster à deux nœuds qui utilisent un stockage NetApp natif.

Cette tâche doit être effectuée sur les deux clusters en configuration MetroCluster.

Pour obtenir des informations plus générales sur la configuration de ONTAP, reportez-vous au "Configuration ONTAP"

Étapes

  1. Mettez le premier nœud sous tension.

    Remarque Vous devez répéter cette étape sur le nœud sur le site de reprise d'activité.

    Le nœud démarre, puis l'assistant de configuration du cluster démarre sur la console vous informant que AutoSupport sera activé automatiquement.

    ::> 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. Créez un nouveau cluster :

    create

  3. Indiquez si le nœud doit être utilisé comme un cluster à un seul nœud.

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

  4. Acceptez les valeurs par défaut du système « oui » en appuyant sur entrée ou entrez vos propres valeurs en tapant « non », puis en appuyant sur entrée.

  5. Suivez les invites pour compléter l'assistant Cluster Setup, en appuyant sur entrée pour accepter les valeurs par défaut ou en saisissant vos propres valeurs, puis en appuyant sur entrée.

    Les valeurs par défaut sont déterminées automatiquement en fonction de votre plate-forme et de votre configuration réseau.

  6. Une fois l'assistant Cluster Setup terminé et qu'il quitte, vérifiez que le cluster est actif et que le premier nœud fonctionne correctement :

    cluster show

    L'exemple suivant montre un cluster dans lequel le premier nœud (cluster 1-01) est sain et peut participer :

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

    S'il est nécessaire de modifier les paramètres que vous avez saisis pour le SVM admin ou le SVM node, vous pouvez accéder à l'assistant Cluster Setup en utilisant le cluster setup commande.

Configuration des clusters dans une configuration MetroCluster

Vous devez peer-to-peer les clusters, mettre en miroir les agrégats racine, créer un agrégat de données en miroir, puis lancer la commande pour mettre en œuvre les opérations MetroCluster.

Peering des clusters

Les clusters de la configuration MetroCluster doivent être dans une relation de pairs, de sorte qu'ils puissent communiquer entre eux et exécuter la mise en miroir des données essentielle à la reprise sur incident de MetroCluster.

Informations associées

"Configuration cluster et SVM peering express"

"Considérations relatives à l'utilisation de ports dédiés"

"Points à prendre en compte lors du partage de ports de données"

Configuration des LIFs intercluster

Vous devez créer des LIFs intercluster sur les ports utilisés pour la communication entre les clusters partenaires MetroCluster. Vous pouvez utiliser des ports ou ports dédiés qui ont également le trafic de données.

Configuration des LIFs intercluster sur des ports dédiés

Vous pouvez configurer les LIFs intercluster sur des ports dédiés. Cela augmente généralement la bande passante disponible pour le trafic de réplication.

Étapes

  1. Lister les ports dans le cluster :

    network port show

    Pour connaître la syntaxe complète de la commande, reportez-vous à la page man.

    L'exemple suivant montre les ports réseau dans « 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. Déterminer les ports disponibles pour dédier aux communications intercluster :

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

    Pour connaître la syntaxe complète de la commande, reportez-vous à la page man.

    L'exemple suivant montre que les ports « e0e » et « e0f » n'ont pas été affectés à des 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. Créer un failover group pour les ports dédiés :

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

    L'exemple suivant attribue les ports « e0e » et « e0f » au groupe de basculement « Intercluster01 » sur le SVM système « 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. Vérifier que le groupe de basculement a été créé :

    network interface failover-groups show

    Pour connaître la syntaxe complète de la commande, reportez-vous à la page 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. Créer les LIF intercluster sur le SVM système et les assigner au failover group.

    Version ONTAP

    Commande

    ONTAP 9.6 et versions ultérieures

    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 et versions antérieures

    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

    Pour connaître la syntaxe complète de la commande, reportez-vous à la page man.

    L'exemple suivant crée les LIFs intercluster « cluster01_icl01 » et « cluster01_icl02 » dans le groupe de basculement « 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. Vérifier que les LIFs intercluster ont été créés :

    Version ONTAP

    Commande

    ONTAP 9.6 et versions ultérieures

    network interface show -service-policy default-intercluster

    ONTAP 9.5 et versions antérieures

    network interface show -role intercluster

    Pour connaître la syntaxe complète de la commande, reportez-vous à la page 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. Vérifier que les LIFs intercluster sont redondants :

    Version ONTAP

    Commande

    ONTAP 9.6 et versions ultérieures

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

    Dans ONTAP 9.5 et versions antérieures

    network interface show -role intercluster -failover

    Pour connaître la syntaxe complète de la commande, reportez-vous à la page man.

    L'exemple suivant montre que les LIFs intercluster « cluster01_icl01 » et « cluster01_icl02 » sur le port SVM « e0e » basculeront vers le port « 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
Informations associées

"Considérations relatives à l'utilisation de ports dédiés"

Configuration des LIFs intercluster sur des ports data partagés

Vous pouvez configurer les LIFs intercluster sur des ports partagés avec le réseau de données. Cela réduit le nombre de ports nécessaires pour la mise en réseau intercluster.

Étapes

  1. Lister les ports dans le cluster :

    network port show

    Pour connaître la syntaxe complète de la commande, reportez-vous à la page man.

    L'exemple suivant montre les ports réseau dans « 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. Création des LIFs intercluster sur le SVM système :

    Version ONTAP

    Commande

    ONTAP 9.6 et versions ultérieures

    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 et versions antérieures

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

    Pour connaître la syntaxe complète de la commande, reportez-vous à la page man.

    L'exemple suivant crée les LIFs intercluster « cluster01_icl01 » et « 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. Vérifier que les LIFs intercluster ont été créés :

    Version ONTAP

    Commande

    ONTAP 9.6 et versions ultérieures

    network interface show -service-policy default-intercluster

    ONTAP 9.5 et versions antérieures

    network interface show -role intercluster

    Pour connaître la syntaxe complète de la commande, reportez-vous à la page 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. Vérifier que les LIFs intercluster sont redondants :

    Version ONTAP

    Commande

    ONTAP 9.6 et versions ultérieures

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

    ONTAP 9.5 et versions antérieures

    network interface show -role intercluster -failover

    Pour connaître la syntaxe complète de la commande, reportez-vous à la page man.

    L'exemple suivant montre que les LIFs intercluster « cluster01_icl01 » et « cluster01_icl02 » sur le port « e0c » basculeront vers le port « 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
Informations associées

"Points à prendre en compte lors du partage de ports de données"

Création d'une relation entre clusters

Vous devez créer la relation entre clusters MetroCluster.

Création d'une relation entre clusters

Vous pouvez utiliser le cluster peer create commande permettant de créer une relation homologue entre un cluster local et un cluster distant. Une fois la relation homologue créée, vous pouvez exécuter cluster peer create sur le cluster distant afin de l'authentifier auprès du cluster local.

Avant de commencer

  • Vous devez avoir créé des LIF intercluster sur chaque nœud des clusters qui sont en cours de peering.

  • Les clusters doivent exécuter ONTAP 9.3 ou version ultérieure.

Étapes

  1. Sur le cluster destination, créez une relation entre pairs et le cluster source :

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

    Si vous spécifiez les deux -generate-passphrase et -peer-addrs, Uniquement le cluster dont les LIFs intercluster sont spécifiés dans -peer-addrs peut utiliser le mot de passe généré.

    Vous pouvez ignorer -ipspace Option si vous n'utilisez pas un IPspace personnalisé. Pour connaître la syntaxe complète de la commande, reportez-vous à la page man.

    L'exemple suivant crée une relation de cluster peer-to-peer sur un cluster distant non spécifié :

    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. Sur le cluster source, authentifier le cluster source sur le cluster destination :

    cluster peer create -peer-addrs peer_LIF_IPs -ipspace ipspace

    Pour connaître la syntaxe complète de la commande, reportez-vous à la page man.

    L'exemple suivant authentifie le cluster local sur le cluster distant aux adresses IP 192.140.112.101 et 192.140.112.102 de LIF 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.

    Entrez la phrase de passe de la relation homologue lorsque vous y êtes invité.

  3. Vérifiez que la relation entre clusters a été créée :

    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. Vérifier la connectivité et l'état des nœuds de la relation peer-to-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
Création d'une relation de cluster peer-to-peer (ONTAP 9.2 et versions antérieures)

Vous pouvez utiliser le cluster peer create commande permettant de lancer une demande de relation de peering entre un cluster local et distant. Une fois la relation homologue demandée par le cluster local, vous pouvez l'exécuter cluster peer create sur le cluster distant pour accepter la relation.

Avant de commencer

  • Vous devez avoir créé des LIFs intercluster sur chaque nœud des clusters en cours de peering.

  • Les administrateurs du cluster doivent avoir accepté la phrase de passe que chaque cluster utilisera pour s'authentifier auprès de l'autre.

Étapes

  1. Sur le cluster cible de protection des données, créez une relation de pairs avec le cluster source de protection des données :

    cluster peer create -peer-addrs peer_LIF_IPs -ipspace ipspace

    Vous pouvez ignorer -ipspace Option si vous n'utilisez pas un IPspace personnalisé. Pour connaître la syntaxe complète de la commande, reportez-vous à la page man.

    L'exemple suivant crée une relation de cluster peer-to-peer avec le cluster distant aux adresses IP LIF intercluster 192.168.2.201 et 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:

    Entrez la phrase de passe de la relation homologue lorsque vous y êtes invité.

  2. Sur le cluster source de protection des données, authentifiez le cluster source sur le cluster destination :

    cluster peer create -peer-addrs peer_LIF_IPs -ipspace ipspace

    Pour connaître la syntaxe complète de la commande, reportez-vous à la page man.

    L'exemple suivant authentifie le cluster local sur le cluster distant aux adresses IP 192.140.112.203 et 192.140.112.204 de LIF intercluster :

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

    Entrez la phrase de passe de la relation homologue lorsque vous y êtes invité.

  3. Vérifiez que la relation entre clusters a été créée :

    cluster peer show –instance

    Pour connaître la syntaxe complète de la commande, reportez-vous à la page 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. Vérifier la connectivité et l'état des nœuds de la relation peer-to-peer :

    cluster peer health show

    Pour connaître la syntaxe complète de la commande, reportez-vous à la page 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

Mise en miroir des agrégats racine

Pour assurer la protection des données, vous devez mettre en miroir les agrégats racine.

Description de la tâche

Par défaut, l'agrégat root est créé comme un agrégat de type RAID-DP. Vous pouvez changer l'agrégat racine de RAID-DP à l'agrégat de type RAID4 La commande suivante modifie l'agrégat racine pour l'agrégat de type RAID4 :

storage aggregate modify –aggregate aggr_name -raidtype raid4

Remarque Sur les systèmes non ADP, le type RAID de l'agrégat peut être modifié depuis le RAID-DP par défaut vers le RAID4 avant ou après la mise en miroir de l'agrégat.
Étapes

  1. Mettre en miroir l'agrégat racine :

    storage aggregate mirror aggr_name

    La commande suivante met en miroir l'agrégat racine pour « Controller_A_1 » :

    controller_A_1::> storage aggregate mirror aggr0_controller_A_1

    Cela met en miroir l'agrégat, il se compose d'un plex local et d'un plex distant situé sur le site MetroCluster distant.

  2. Répétez l'étape précédente pour chaque nœud de la configuration MetroCluster.

Informations associées

"Gestion du stockage logique"

"Concepts relatifs à ONTAP"

Crée un agrégat de données en miroir sur chaque nœud

Vous devez créer un agrégat de données en miroir sur chaque nœud du groupe de reprise sur incident.

Avant de commencer

  • Vous devez savoir quels disques ou LUN de baie seront utilisés dans le nouvel agrégat.

  • Si votre système compte plusieurs types de disques (stockage hétérogène), vous devez comprendre comment vous assurer que le type de disque approprié est sélectionné.

Description de la tâche

  • Les disques et les LUN de baie sont détenus par un nœud spécifique. Lorsque vous créez un agrégat, tous les disques de cet agrégat doivent être détenus par le même nœud, qui devient le nœud de rattachement de cet agrégat.

  • Les noms d'agrégats doivent être conformes au schéma de nommage que vous avez déterminé lors de la planification de votre configuration MetroCluster.

    "Gestion des disques et des agrégats"

Étapes

  1. Afficher la liste des pièces de rechange disponibles :

    storage disk show -spare -owner node_name

  2. Créer l'agrégat :

    storage aggregate create -mirror true

    Si vous êtes connecté au cluster depuis l'interface de gestion du cluster, vous pouvez créer un agrégat sur n'importe quel nœud du cluster. Pour s'assurer que l'agrégat est créé sur un nœud spécifique, utilisez le -node paramètre ou spécifiez les disques qui sont détenus par ce nœud.

    Vous pouvez spécifier les options suivantes :

    • Nœud de rattachement de l'agrégat (c'est-à-dire le nœud qui détient l'agrégat en fonctionnement normal)

    • Liste de disques spécifiques ou de LUN de baies à ajouter à l'agrégat

    • Nombre de disques à inclure

      Remarque Dans la configuration minimale prise en charge, dans laquelle un nombre limité de disques sont disponibles, vous devez utiliser l'option force-petits agrégats pour créer un agrégat RAID-DP à trois disques.

    • Style de checksum à utiliser pour l'agrégat

    • Type de disques à utiliser

    • Taille des disques à utiliser

    • Vitesse de conduite à utiliser

    • Type RAID des groupes RAID sur l'agrégat

    • Nombre maximal de disques ou de LUN de baies pouvant être inclus dans un groupe RAID

    • Si des disques avec différents RPM sont autorisés pour plus d'informations sur ces options, reportez-vous à la section storage aggregate create page de manuel.

      La commande suivante crée un agrégat en miroir avec 10 disques :

    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. Vérifier le groupe RAID et les disques de votre nouvel agrégat :

    storage aggregate show-status -aggregate aggregate-name

Création d'agrégats de données sans mise en miroir

Vous pouvez choisir de créer des agrégats de données non mis en miroir pour des données ne nécessitant pas la mise en miroir redondante fournie par les configurations MetroCluster.

Avant de commencer

  • Vous devez savoir quels disques ou LUN de baie seront utilisés dans le nouvel agrégat.

  • Si votre système compte plusieurs types de disques (stockage hétérogène), vous devez comprendre comment vous pouvez vérifier que le type de disque approprié est sélectionné.

Exemple 1. Description de la tâche

ATTENTION : dans les configurations FC MetroCluster, les agrégats non mis en miroir ne seront en ligne qu'après un basculement si les disques distants de l'agrégat sont accessibles. En cas de panne de liens ISL, le nœud local risque de ne pas pouvoir accéder aux données dans les disques distants sans mise en miroir. La défaillance d'un agrégat peut entraîner le redémarrage du nœud local.

Remarque Les agrégats non mis en miroir doivent être locaux au nœud qu'ils possèdent.

  • Les disques et les LUN de baie sont détenus par un nœud spécifique. Lorsque vous créez un agrégat, tous les disques de cet agrégat doivent être détenus par le même nœud, qui devient le nœud de rattachement de cet agrégat.

  • Les noms d'agrégats doivent être conformes au schéma de nommage que vous avez déterminé lors de la planification de votre configuration MetroCluster.

  • Le "Gestion des disques et des agrégats" contient plus d'informations sur la mise en miroir des agrégats.

Étapes

  1. Afficher la liste des pièces de rechange disponibles :

    storage disk show -spare -owner node_name

  2. Créer l'agrégat :

    storage aggregate create

    Si vous êtes connecté au cluster depuis l'interface de gestion du cluster, vous pouvez créer un agrégat sur n'importe quel nœud du cluster. Pour vérifier que l'agrégat est créé sur un nœud spécifique, il est important d'utiliser le -node paramètre ou spécifiez les disques qui sont détenus par ce nœud.

    Vous pouvez spécifier les options suivantes :

    • Nœud de rattachement de l'agrégat (c'est-à-dire le nœud qui détient l'agrégat en fonctionnement normal)

    • Liste de disques spécifiques ou de LUN de baies à ajouter à l'agrégat

    • Nombre de disques à inclure

    • Style de checksum à utiliser pour l'agrégat

    • Type de disques à utiliser

    • Taille des disques à utiliser

    • Vitesse de conduite à utiliser

    • Type RAID des groupes RAID sur l'agrégat

    • Nombre maximal de disques ou de LUN de baies pouvant être inclus dans un groupe RAID

    • Si des disques avec différents RPM sont autorisés pour plus d'informations sur ces options, reportez-vous à la section storage aggregate create page de manuel.

      La commande suivante crée un agrégat sans mise en miroir avec 10 disques :

    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. Vérifier le groupe RAID et les disques de votre nouvel agrégat :

    storage aggregate show-status -aggregate aggregate-name

Mise en œuvre de la configuration MetroCluster

Vous devez exécuter le metrocluster configure Commande pour démarrer la protection des données en configuration MetroCluster.

Avant de commencer

  • Chaque cluster doit contenir au moins deux agrégats de données en miroir non racines.

    Les agrégats de données supplémentaires peuvent être mis en miroir ou non.

    Vérifier les types d'agrégats :

    storage aggregate show

    Remarque Si vous souhaitez utiliser un seul agrégat de données en miroir, reportez-vous à la section "Configurer le logiciel MCC dans ONTAP" pour obtenir des instructions.

  • L'état ha-config des contrôleurs et du châssis doit être “mcc-2n”.

Description de la tâche

Vous pouvez lancer le metrocluster configure Commande unique, sur l'un des nœuds, pour activer la configuration MetroCluster. Vous n'avez pas besoin d'exécuter la commande sur chacun des sites ou nœuds, et ce n'est pas quel nœud ou site vous choisissez d'exécuter la commande.

Étapes

  1. Configurer le MetroCluster au format suivant :

    Si votre configuration MetroCluster possède…​

    Alors, procédez comme ça…​

    Plusieurs agrégats de données

    Depuis n'importe quelle invite de nœud, configurer MetroCluster :

    metrocluster configure node-name

    Un seul agrégat de données en miroir

    1. Depuis l'invite de n'importe quel nœud, passez au niveau de privilège avancé :

      set -privilege advanced

      Vous devez répondre par « y » lorsque vous êtes invité à continuer en mode avancé et que vous voyez l'invite du mode avancé (*>).

    2. Configurez le MetroCluster avec le -allow-with-one-aggregate true paramètre :

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

    3. Revenir au niveau de privilège admin :
      set -privilege admin
    Remarque Il est recommandé d'avoir plusieurs agrégats de données. Si le premier groupe de reprise après incident ne dispose que d'un seul agrégat et que vous souhaitez ajouter un groupe de reprise après incident avec un seul agrégat, vous devez déplacer le volume de métadonnées depuis cet agrégat. Pour plus d'informations sur cette procédure, voir "Déplacement d'un volume de métadonnées dans les configurations MetroCluster".

    La commande suivante permet la configuration de MetroCluster sur tous les nœuds du groupe DR qui contient « Controller_A_1 » :

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

[Job 121] Job succeeded: Configure is successful.

  2. Vérifiez l'état de la mise en réseau sur le site A :

    network port show

    L'exemple suivant montre l'utilisation du port réseau :

    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. Vérifier la configuration MetroCluster des deux sites de la configuration MetroCluster.

    1. Vérifier la configuration à partir du site 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. Vérifier la configuration à partir du site 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

Configuration de ponts FC-SAS pour le contrôle de l'état du système

Dans les systèmes exécutant des versions ONTAP antérieures à 9.8, si votre configuration inclut des ponts FC-SAS, vous devez effectuer quelques étapes de configuration spéciales pour surveiller les ponts FC-SAS dans la configuration MetroCluster.

  • Les outils de surveillance SNMP tiers ne sont pas pris en charge pour les ponts FiberBridge.

  • Depuis la version ONTAP 9.8, les ponts FC-SAS sont surveillés par défaut via des connexions intrabande, ce qui n'est pas nécessaire.

Remarque Avec ONTAP 9.8, le storage bridge la commande est remplacée par system bridge. Les étapes suivantes présentent le storage bridge Mais si vous exécutez ONTAP 9.8 ou version ultérieure, le system bridge commande recommandée.
Étapes

  1. Dans l'invite de cluster ONTAP, ajoutez le pont au contrôle de l'état de santé :

    1. Ajoutez le pont à l'aide de la commande pour votre version de ONTAP :

      Version ONTAP

      Commande

      ONTAP 9.5 et versions ultérieures

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

      ONTAP 9.4 et versions antérieures

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

    2. Vérifiez que le pont a été ajouté et est correctement configuré :

      storage bridge show

      Il peut s'avérer nécessaire de prendre jusqu'à 15 minutes pour refléter toutes les données à cause de l'intervalle d'interrogation. Le moniteur d'intégrité ONTAP peut contacter et surveiller le pont si la valeur de la colonne "état" est ""ok"" et si d'autres informations, telles que le nom mondial (WWN), sont affichées.

      L'exemple suivant montre que les ponts FC-SAS sont configurés :

    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::>

Vérification de la configuration MetroCluster

Vous pouvez vérifier que les composants et les relations de la configuration MetroCluster fonctionnent correctement. Vous devez effectuer un contrôle après la configuration initiale et après avoir apporté des modifications à la configuration MetroCluster. Vous devez également effectuer une vérification avant le basculement (prévu) ou le rétablissement.

Si le metrocluster check run la commande est émise deux fois en peu de temps sur l'un des clusters ou les deux clusters. un conflit peut se produire et la commande risque de ne pas collecter toutes les données. Ensuite metrocluster check show les commandes n'affichent pas la sortie attendue.

  1. Vérifiez la configuration :

    metrocluster check run

    La commande s'exécute en arrière-plan et peut ne pas être terminée immédiatement.

    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. Afficher des résultats plus détaillés :

    metrocluster check run

    metrocluster check aggregate show

    metrocluster check cluster show

    metrocluster check config-replication show

    metrocluster check lif show

    metrocluster check node show

    Le metrocluster check show les commandes affichent les résultats des plus récentes metrocluster check run commande. Vous devez toujours exécuter le metrocluster check run avant d'utiliser le metrocluster check show commandes de manière à ce que les informations affichées soient à jour.

    L'exemple suivant montre le metrocluster check aggregate show Résultat de la commande pour une configuration MetroCluster à quatre nœuds saine :

    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.

    L'exemple suivant montre le metrocluster check cluster show Résultat de la commande pour une configuration MetroCluster à quatre nœuds saine. Il indique que les clusters sont prêts à effectuer un basculement négocié si nécessaire.

    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.
Informations associées

"Gestion des disques et des agrégats"

"Gestion du réseau et des LIF"

Vérification des erreurs de configuration MetroCluster avec Config Advisor

Vous pouvez accéder au site de support NetApp et télécharger l'outil Config Advisor pour vérifier les erreurs de configuration courantes.

Config Advisor est un outil de validation de la configuration et de vérification de l'état de santé. Vous pouvez le déployer sur des sites sécurisés et sur des sites non sécurisés à des fins de collecte des données et d'analyse du système.

Remarque Le support pour Config Advisor est limité et n'est disponible qu'en ligne.

  1. Accédez à la page de téléchargement Config Advisor et téléchargez l'outil.

    "Téléchargement NetApp : Config Advisor"

  2. Exécutez Config Advisor, examinez les résultats de l'outil et suivez les recommandations du produit pour résoudre tous les problèmes détectés.

Vérification du basculement, de la résolution et du rétablissement

Il est recommandé de vérifier les opérations de basculement, de rétablissement et de rétablissement de la configuration MetroCluster.

  1. Utilisez les procédures de basculement négocié, de rétablissement et de rétablissement mentionnées dans le "Effectuez les opérations de basculement, de rétablissement et de rétablissement".

Protection des fichiers de sauvegarde de configuration

Vous pouvez fournir une protection supplémentaire pour les fichiers de sauvegarde de la configuration du cluster en spécifiant une URL distante (HTTP ou FTP) dans laquelle les fichiers de sauvegarde de configuration seront chargés en plus des emplacements par défaut dans le cluster local.

  1. Définissez l'URL de la destination distante pour les fichiers de sauvegarde de configuration :

    system configuration backup settings modify URL-of-destination

    Le "Gestion du cluster via l'interface de ligne de commandes" Contient des informations supplémentaires sous la section gestion des sauvegardes de configuration.