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

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. Les étapes des systèmes avec tiroirs disques natifs sont légèrement différentes de celles des systèmes avec LUN de baie.

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

Collecte des informations requises

Vous devez rassembler les adresses IP requises pour les modules de contrôleur avant de commencer le processus de configuration.

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 sur les commutateurs du site A (clusters commutés)

Lorsque vous câconnectez le système, vous avez besoin d'un nom d'hôte et d'une adresse IP de gestion pour chaque commutateur de cluster. Ces informations ne sont pas nécessaires si vous utilisez un cluster sans commutateur à deux nœuds ou si vous disposez d'une configuration MetroCluster à deux nœuds (un nœud sur chaque site).

Commutateur de cluster

Nom d'hôte

Adresse IP

Masque de réseau

Passerelle par défaut

Interconnexion 1

Interconnexion 2

Gestion 1

Gestion 2

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

Nœud 2 IC LIF 1

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

Nœud 2 IC LIF 2

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

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

Nœud 2

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

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 sur les commutateurs du site B (clusters avec commutateur)

Lorsque vous câconnectez le système, vous avez besoin d'un nom d'hôte et d'une adresse IP de gestion pour chaque commutateur de cluster. Ces informations ne sont pas nécessaires si vous utilisez un cluster sans commutateur à deux nœuds ou si vous disposez d'une configuration MetroCluster à deux nœuds (un nœud sur chaque site).

Commutateur de cluster

Nom d'hôte

Adresse IP

Masque de réseau

Passerelle par défaut

Interconnexion 1

Interconnexion 2

Gestion 1

Gestion 2

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 ce guide : 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 ce guide : Controller_B_1

Nœud 2

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

Exemple utilisé dans ce guide : 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

Nœud 2 IC LIF 1

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

Nœud 2 IC LIF 2

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

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

Partenaires

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)

Nœud 2 (contrôleur_B_2)

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

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

Configurer les nœuds sur le cluster en tant que paires haute disponibilité

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.

Ne s'applique pas

Obligatoire

Vérification et configuration de l'état HA des composants en mode maintenance

Lors de la configuration d'un système de stockage dans une configuration MetroCluster FC, vous devez vous assurer que l'état haute disponibilité (HA) du module de contrôleur et des composants du châssis est mcc ou mcc-2n afin que ces composants puissent démarrer correctement. Bien que cette valeur doive être préconfigurée sur les systèmes reçus de l'usine, vous devez toujours vérifier le réglage avant de continuer.

Avertissement

Si l'état haute disponibilité du module de contrôleur et du châssis est incorrect, vous ne pouvez pas configurer la MetroCluster sans avoir réinitialisé le nœud. Vous devez corriger le paramètre à l'aide de cette procédure, puis initialiser le système à l'aide de l'une des procédures suivantes :

Avant de commencer

Vérifiez que le système est en mode Maintenance.

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

    ha-config show

    L'état correct de haute disponibilité dépend de votre configuration MetroCluster.

    Type de configuration MetroCluster

    État HAUTE DISPONIBILITÉ pour tous les composants…​

    Configuration FC MetroCluster à huit ou quatre nœuds

    mcc

    Configuration FC MetroCluster à deux nœuds

    mcc-2n

    Configuration IP MetroCluster à huit ou quatre nœuds

    ccip

  2. Si l'état système affiché du contrôleur est incorrect, définissez l'état de haute disponibilité correct pour votre configuration sur le module de contrôleur :

    Type de configuration MetroCluster

    Commande

    Configuration FC MetroCluster à huit ou quatre nœuds

    ha-config modify controller mcc

    Configuration FC MetroCluster à deux nœuds

    ha-config modify controller mcc-2n

    Configuration IP MetroCluster à huit ou quatre nœuds

    ha-config modify controller mccip

  3. Si l'état système affiché du châssis n'est pas correct, définissez l'état de haute disponibilité correct pour votre configuration sur le châssis :

    Type de configuration MetroCluster

    Commande

    Configuration FC MetroCluster à huit ou quatre nœuds

    ha-config modify chassis mcc

    Configuration FC MetroCluster à deux nœuds

    ha-config modify chassis mcc-2n

    Configuration IP MetroCluster à huit ou quatre nœuds

    ha-config modify chassis mccip

  4. Démarrez le nœud sur ONTAP :

    boot_ontap

  5. Répétez cette procédure pour vérifier l'état de haute disponibilité sur chaque nœud de 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

Description de la tâche

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 à huit ou quatre nœuds

Avant de démarrer entièrement le système sur ONTAP, vous pouvez également démarrer en mode maintenance et vérifier l'affectation des disques sur les nœuds. Les disques doivent être affectés pour créer une configuration active-active entièrement symétrique, où chaque pool a le même nombre de disques qui leur sont affectés.

Description de la tâche

Les nouveaux systèmes MetroCluster ont une affectation des disques réalisée avant leur 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.

Tiroirs disques du site A

Tiroir disque (sample_shelf_name)…​

Appartient à…​

Et est attribué à ce nœud…​

Tiroir disque 1 (tiroir_A_1_1)

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 5 (tiroir_A_2_1)

Nœud A 2

Pool 0

Tiroir disque 6 (tiroir_A_2_3)

Tiroir disque 7 (tiroir_B_2_1)

Nœud B 2

Piscine 1

Tiroir disque 8 (tiroir_B_2_3)

Tiroir disque 1 (tiroir_A_3_1)

Nœud A 3

Pool 0

Tiroir disque 2 (tiroir_A_3_3)

Tiroir disque 3 (tiroir_B_3_1)

Nœud B 3

Piscine 1

Tiroir disque 4 (tiroir_B_3_3)

Tiroir disque 5 (tiroir_A_4_1)

Nœud A 4

Pool 0

Tiroir disque 6 (tiroir_A_4_3)

Tiroir disque 7 (tiroir_B_4_1)

Nœud B 4

Piscine 1

Tiroir disque 8 (tiroir_B_4_3)

Tiroirs disques du site B

Tiroir disque (sample_shelf_name)…​

Appartient à…​

Et est attribué à ce nœud…​

Tiroir disque 9 (tiroir_B_1_2)

Nœud B 1

Pool 0

Tiroir disque 10 (tiroir_B_1_4)

Tiroir disque 11 (tiroir_A_1_2)

Nœud A 1

Piscine 1

Tiroir disque 12 (tiroir_A_1_4)

Tiroir disque 13 (tiroir_B_2_2)

Nœud B 2

Pool 0

Tiroir disque 14 (tiroir_B_2_4)

Tiroir disque 15 (tiroir_A_2_2)

Nœud A 2

Piscine 1

Tiroir disque 16 (tiroir_A_2_4)

Tiroir disque 1 (tiroir_B_3_2)

Nœud A 3

Pool 0

Tiroir disque 2 (tiroir_B_3_4)

Tiroir disque 3 (tiroir_A_3_2)

Nœud B 3

Piscine 1

Tiroir disque 4 (tiroir_A_3_4)

Tiroir disque 5 (tiroir_B_4_2)

Nœud A 4

Pool 0

Tiroir disque 6 (tiroir_B_4_4)

Tiroir disque 7 (tiroir_A_4_2)

Nœud B 4

Étapes
  1. Confirmer les attributions de tiroirs :

    disk show –v

  2. Si nécessaire, affectez explicitement des disques sur les tiroirs disques connectés au pool approprié :

    disk assign

    L'utilisation de caractères génériques dans la commande vous permet d'affecter tous les disques d'un tiroir disque à l'aide d'une commande. Vous pouvez identifier les ID de tiroir disque et les baies de chaque disque disposant du storage show disk -x commande.

Assignation de la propriété des disques dans des systèmes non-AFF

Si les nœuds MetroCluster ne sont pas affectés correctement, ou si vous utilisez des tiroirs disques DS460C dans votre configuration, il est nécessaire d'attribuer des disques à chacun des nœuds de la configuration MetroCluster selon le tiroir par tiroir. Vous allez créer une configuration dans laquelle chaque nœud a le même nombre de disques dans ses pools de disques locaux et distants.

Avant de commencer

Les contrôleurs de stockage doivent être en mode maintenance.

Description de la tâche

Si votre configuration n'inclut pas de tiroirs disques DS460C, cette tâche n'est pas requise si les disques ont été correctement attribués lors de leur réception par l'usine.

Remarque

Le pool 0 contient toujours les disques qui se trouvent sur le même site que le système de stockage qui les possède.

Le pool 1 contient toujours les disques distants du système de stockage qui les possèdent.

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…​

0 - 2

Pool du nœud local 0

3 - 5

Pool 0 du nœud partenaire HA

6 - 8

Partenaire DR du pool du nœud local 1

9 - 11

Partenaire de reprise après incident du pool de partenaires de haute disponibilité 1

Ce modèle d'affectation de disque permet de s'assurer qu'un agrégat est au moins affecté en cas de mise hors ligne d'un tiroir.

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

  2. Assigner les tiroirs disques aux nœuds situés sur le premier site (site A) :

    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. Sur le premier nœud, attribuer systématiquement les tiroirs disques locaux à pool 0 et les tiroirs disques distants à pool 1 :

      disk assign -shelf local-switch-name:shelf-name.port -p pool

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

      *> disk assign -shelf FC_switch_A_1:1-4.shelf1 -p 0
      *> disk assign -shelf FC_switch_A_1:1-4.shelf2 -p 0
      
      *> disk assign -shelf FC_switch_B_1:1-4.shelf1 -p 1
      *> disk assign -shelf FC_switch_B_1:1-4.shelf2 -p 1
    2. Répétez le processus pour le second nœud du site local, en affectant systématiquement les tiroirs disques locaux au pool 0 et les tiroirs disques distants au pool 1 :

      disk assign -shelf local-switch-name:shelf-name.port -p pool

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

    *> disk assign -shelf FC_switch_A_1:1-4.shelf3 -p 0
    *> disk assign -shelf FC_switch_B_1:1-4.shelf4 -p 1
    
    *> disk assign -shelf FC_switch_A_1:1-4.shelf3 -p 0
    *> disk assign -shelf FC_switch_B_1:1-4.shelf4 -p 1
  3. Assigner les tiroirs disques aux nœuds situés sur le second site (site B) :

    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. Sur le premier nœud du site distant, attribuer systématiquement ses tiroirs disques locaux à regrouper 0 et ses tiroirs disques distants à pool 1 :

      disk assign -shelf local-switch-nameshelf-name -p pool

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

      *> disk assign -shelf FC_switch_B_1:1-5.shelf1 -p 0
      *> disk assign -shelf FC_switch_B_1:1-5.shelf2 -p 0
      
      *> disk assign -shelf FC_switch_A_1:1-5.shelf1 -p 1
      *> disk assign -shelf FC_switch_A_1:1-5.shelf2 -p 1
    2. Répétez le processus pour le second nœud du site distant en affectant systématiquement ses tiroirs disques locaux au pool 0 et ses tiroirs disques distants au pool 1 :

      disk assign -shelf shelf-name -p pool

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

    *> disk assign -shelf FC_switch_B_1:1-5.shelf3 -p 0
    *> disk assign -shelf FC_switch_B_1:1-5.shelf4 -p 0
    
    *> disk assign -shelf FC_switch_A_1:1-5.shelf3 -p 1
    *> disk assign -shelf FC_switch_A_1:1-5.shelf4 -p 1
  4. Confirmer les attributions de tiroirs :

    storage show shelf

  5. Quitter le mode Maintenance :

    halt

  6. Afficher le menu de démarrage :

    boot_ontap menu

  7. Sur chaque nœud, sélectionnez l'option 4 pour initialiser tous les disques.

Assignation de la propriété des disques dans les systèmes AFF

Si vous utilisez des systèmes AFF dans une configuration avec des agrégats en miroir et que les nœuds ne disposent pas des disques (SSD) correctement affectés, vous devez attribuer la moitié des disques de chaque tiroir à un nœud local et l'autre moitié des disques à son nœud partenaire haute disponibilité. Vous devez créer une configuration dans laquelle chaque nœud a le même nombre de disques dans ses pools de disques locaux et distants.

Avant de commencer

Les contrôleurs de stockage doivent être en mode maintenance.

Description de la tâche

Cela ne s'applique pas aux configurations qui ne disposent pas d'agrégats en miroir, qui possèdent une configuration active/passive ou qui disposent d'un nombre inégal de disques dans les pools locaux et distants.

Cette tâche n'est pas requise si les disques ont été correctement affectés lorsqu'ils ont été reçus de l'usine.

Remarque

Le pool 0 contient toujours les disques qui se trouvent sur le même site que le système de stockage qui les possède.

Le pool 1 contient toujours les disques distants du système de stockage qui les possèdent.

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

  2. Assigner les disques aux nœuds situés sur le premier site (site A) :

    Vous devez affecter un nombre égal de disques à chaque pool.

    1. Sur le premier nœud, attribuer systématiquement la moitié des disques de chaque tiroir afin de regrouper 0 et l'autre moitié au pool du partenaire haute disponibilité 0 :

      disk assign -shelf <shelf-name> -p <pool> -n <number-of-disks>

      Si le contrôleur de stockage Controller_A_1 dispose de quatre tiroirs, chacun doté de 8 SSD, vous exécutez les commandes suivantes :

      *> disk assign -shelf FC_switch_A_1:1-4.shelf1 -p 0 -n 4
      *> disk assign -shelf FC_switch_A_1:1-4.shelf2 -p 0 -n 4
      
      *> disk assign -shelf FC_switch_B_1:1-4.shelf1 -p 1 -n 4
      *> disk assign -shelf FC_switch_B_1:1-4.shelf2 -p 1 -n 4
    2. Répéter le processus pour le second nœud sur le site local, en affectant systématiquement la moitié des disques de chaque tiroir au pool 1 et l'autre moitié au pool 1 du partenaire haute disponibilité :

      disk assign -disk disk-name -p pool

      Si le contrôleur de stockage Controller_A_1 dispose de quatre tiroirs, chacun doté de 8 SSD, vous exécutez les commandes suivantes :

    *> disk assign -shelf FC_switch_A_1:1-4.shelf3 -p 0 -n 4
    *> disk assign -shelf FC_switch_B_1:1-4.shelf4 -p 1 -n 4
    
    *> disk assign -shelf FC_switch_A_1:1-4.shelf3 -p 0 -n 4
    *> disk assign -shelf FC_switch_B_1:1-4.shelf4 -p 1 -n 4
  3. Assigner les disques aux nœuds situés sur le second site (site B) :

    Vous devez affecter un nombre égal de disques à chaque pool.

    1. Sur le premier nœud du site distant, attribuer systématiquement la moitié des disques de chaque tiroir dans le pool 0 et l'autre moitié dans le pool 0 du partenaire haute disponibilité :

      disk assign -disk disk-name -p pool

      Si le contrôleur de stockage Controller_B_1 dispose de quatre tiroirs, chacun doté de 8 SSD, vous exécutez les commandes suivantes :

      *> disk assign -shelf FC_switch_B_1:1-5.shelf1 -p 0 -n 4
      *> disk assign -shelf FC_switch_B_1:1-5.shelf2 -p 0 -n 4
      
      *> disk assign -shelf FC_switch_A_1:1-5.shelf1 -p 1 -n 4
      *> disk assign -shelf FC_switch_A_1:1-5.shelf2 -p 1 -n 4
    2. Répétez le processus pour le second nœud sur le site distant en affectant systématiquement la moitié des disques de chaque tiroir au pool 1 et l'autre moitié au pool 1 du partenaire haute disponibilité :

      disk assign -disk disk-name -p pool

      Si le contrôleur de stockage Controller_B_2 dispose de quatre tiroirs, chacun doté de 8 SSD, vous exécutez les commandes suivantes :

    *> disk assign -shelf FC_switch_B_1:1-5.shelf3 -p 0 -n 4
    *> disk assign -shelf FC_switch_B_1:1-5.shelf4 -p 0 -n 4
    
    *> disk assign -shelf FC_switch_A_1:1-5.shelf3 -p 1 -n 4
    *> disk assign -shelf FC_switch_A_1:1-5.shelf4 -p 1 -n 4
  4. Confirmez les attributions de disques :

    storage show disk

  5. Quitter le mode Maintenance :

    halt

  6. Afficher le menu de démarrage :

    boot_ontap menu

  7. Sur chaque nœud, sélectionnez l'option 4 pour initialiser tous les disques.

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 nouveaux systèmes MetroCluster ont une affectation des disques réalisée avant leur 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 de nom)…​

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

Piscine 1

Tiroir disque 12 (tiroir_A_1_4)

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 affecter des disques aux tiroirs disques connectés au pool approprié à l'aide de la commande disk assigny.

    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 à regrouper 0 et les tiroirs disques distants à regrouper 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. Afficher les ID de tiroir disque et les baies pour chaque disque :

      disk show –v

Configuration de ONTAP

Vous devez configurer le protocole ONTAP sur chaque module de contrôleur.

Si vous avez besoin de netboot sur les nouveaux contrôleurs, reportez-vous à la section "Démarrage réseau des nouveaux modules de contrôleur" Dans le Guide de mise à niveau, de transition et d'extension de 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 des clusters et utiliser la commande cluster setup pour configurer le nœud en tant que 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 plus d'informations générales sur la configuration de ONTAP, reportez-vous à la section "Configurer 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 yes En appuyant sur entrée ou en saisissant vos propres valeurs no, Puis appuyez 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. Après avoir terminé l'assistant Cluster Setup et qu'il se ferme, 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

    Si il devient nécessaire de modifier l'un des paramètres que vous avez saisis pour le SVM admin ou le SVM node, vous pouvez accéder à l'assistant Cluster Setup à l'aide de la commande cluster setup.

Configuration de ONTAP dans une configuration MetroCluster à huit ou quatre nœuds

Après le démarrage de chaque nœud, vous êtes invité à exécuter l'outil System Setup afin d'effectuer une configuration de nœud et de cluster de base. Une fois le cluster configuré, vous revenez à l'interface de ligne de commandes de ONTAP pour créer des agrégats et créer la configuration MetroCluster.

Avant de commencer

Vous devez avoir câblé la configuration MetroCluster.

Description de la tâche

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

Les nouveaux systèmes MetroCluster sont préconfigurés, mais il n'est pas nécessaire d'effectuer ces étapes. Toutefois, vous devez configurer l'outil AutoSupport.

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

Cette procédure utilise l'outil de configuration du système. Vous pouvez utiliser l'assistant de configuration du cluster via l'interface de ligne de commandes.

Étapes
  1. Si vous ne l'avez pas encore fait, mettez chaque nœud sous tension et laissez-le démarrer complètement.

    Si le système est en mode maintenance, lancer la commande halt pour quitter le mode maintenance, puis lancer la commande suivante de l'invite DU CHARGEUR :

    boot_ontap

    La sortie doit être similaire à ce qui suit :

    Welcome to node setup
    
    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 setup wizard.
    				Any changes you made before quitting will be saved.
    
    To accept a default or omit a question, do not enter a value.
    .
    .
    .
  2. Activer l'outil AutoSupport en suivant les instructions fournies par le système.

  3. Répondez aux invites pour configurer l'interface de gestion des nœuds.

    Les invites sont similaires à ce qui suit :

    Enter the node management interface port: [e0M]:
    Enter the node management interface IP address: 10.228.160.229
    Enter the node management interface netmask: 225.225.252.0
    Enter the node management interface default gateway: 10.228.160.1
  4. Vérifier que les nœuds sont configurés en mode haute disponibilité :

    storage failover show -fields mode

    Dans le cas contraire, vous devez lancer la commande suivante sur chaque nœud et redémarrer le nœud :

    storage failover modify -mode ha -node localhost

    Cette commande configure le mode haute disponibilité, mais n'active pas le basculement du stockage. Le basculement de stockage est automatiquement activé lorsque la configuration de MetroCluster est effectuée ultérieurement dans le processus de configuration.

  5. Vérifiez que quatre ports sont configurés en tant qu'interconnexions de cluster :

    network port show

    L'exemple suivant montre la sortie du cluster_A :

    cluster_A::> network port show
                                                                 Speed (Mbps)
    Node   Port      IPspace      Broadcast Domain Link   MTU    Admin/Oper
    ------ --------- ------------ ---------------- ----- ------- ------------
    node_A_1
           **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
           e0g       Default      Default          up       1500  auto/1000
    node_A_2
           **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
           e0g       Default      Default          up       1500  auto/1000
    14 entries were displayed.
  6. Si vous créez un cluster sans commutateur à 2 nœuds (un cluster sans commutateurs d'interconnexion de cluster), activez le mode de mise en réseau sans commutateur :

    1. Changement au niveau de privilège avancé :

      set -privilege advanced

    Vous pouvez répondre y lorsque vous êtes invité à passer en mode avancé. L'invite du mode avancé s'affiche (*).

    1. Activer le mode sans commutateur-cluster :

      network options switchless-cluster modify -enabled true

    2. Retour au niveau de privilège admin :

      set -privilege admin

  7. Lancez l'outil de configuration du système comme indiqué dans les informations qui s'affichent sur la console du système après le démarrage initial.

  8. Utilisez l'outil System Setup pour configurer chaque nœud et créer le cluster, mais ne créez pas d'agrégats.

    Remarque Vous créez des agrégats en miroir dans des tâches ultérieures.
Une fois que vous avez terminé

Revenez à l'interface de ligne de commandes ONTAP et terminez la configuration MetroCluster en effectuant les tâches suivantes.

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.

Description de la tâche

Avant de courir metrocluster configure, Le mode HA et la mise en miroir DR ne sont pas activés et un message d'erreur peut s'afficher concernant ce comportement attendu. Vous activez le mode HA et la mise en miroir de reprise après incident plus tard lors de l'exécution de la commande metrocluster configure pour implémenter la configuration.

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.

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 en « 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 aux 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 intercluster 01 sur le système « SVMcluster01 » :

    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.

    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 :

    ONTAP 9.6 et versions ultérieures

    Lancer la commande : network interface show -service-policy default-intercluster

    ONTAP 9.5 et versions antérieures

    Lancer la commande : 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 :

    ONTAP 9.6 et versions ultérieures

    Lancer la commande : network interface show -service-policy default-intercluster -failover

    ONTAP 9.5 et versions antérieures

    Lancer la commande : 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

Pour déterminer si l'utilisation d'un port dédié pour la réplication intercluster est la bonne solution réseau intercluster, vous devez tenir compte des configurations et des exigences telles que le type de LAN, les bandes WAN disponibles, l'intervalle de réplication, le taux de changement et le nombre de ports.

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

    ONTAP 9.6 et versions ultérieures

    Lancer la commande : 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

    Lancer la commande : 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 illustre la création des 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 :

    ONTAP 9.6 et versions ultérieures

    Lancer la commande : network interface show -service-policy default-intercluster

    ONTAP 9.5 et versions antérieures

    Lancer la commande : 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 :

    ONTAP 9.6 et versions ultérieures

    Lancer la commande : network interface show –service-policy default-intercluster -failover

    ONTAP 9.5 et versions antérieures

    Lancer la commande : 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

Création d'une relation entre clusters

Vous devez créer la relation entre clusters MetroCluster.

Description de la tâche

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 secrète 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 l'option -ipsace 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 entre clusters et le cluster distant au niveau des 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 root 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.

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.

  • 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é.

  • 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. Voir "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 en utilisant la commande create -mirror true de l'agrégat de stockage.

    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 le force-small-aggregate Option permettant de 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

    • Indique si les disques à régime différent sont autorisés

    Pour plus d'informations sur ces options, reportez-vous au 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é.

Important Dans les configurations FC MetroCluster, les agrégats sans 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.
  • 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.

Remarque Les agrégats non mis en miroir doivent être locaux au nœud qu'ils possèdent.
  • 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 contient plus d'informations sur les agrégats en miroir.

É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

    • Indique si les disques à régime différent sont autorisés

    Pour plus d'informations sur ces options, consultez la page man relative à la création d'agrégat de stockage.

    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.

    Vous pouvez le vérifier à l'aide du storage aggregate show commande.

    Remarque Si vous souhaitez utiliser un seul agrégat de données en miroir, reportez-vous à la section Étape 1 pour obtenir des instructions.
  • L'état HA-config des contrôleurs et du châssis doit être « mcc ».

Description de la tâche

Vous émettez 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.

Le metrocluster configure La commande couple automatiquement les deux nœuds avec les ID système les plus bas dans chacun des deux clusters comme partenaires de reprise d'activité. Dans une configuration MetroCluster à quatre nœuds, il existe deux paires de partenaires pour la reprise après incident. La seconde paire DR est créée à partir des deux nœuds avec des ID système plus élevés.

Remarque Vous devez pas configurer Onboard Key Manager (OKM) ou la gestion externe des clés avant d'exécuter la commande metrocluster configure.
Étapes
  1. ] configurez 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 avec y lorsque vous êtes invité à passer 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. Retour 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 ce dernier. 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 d'activer la configuration MetroCluster sur tous les nœuds du groupe DR qui contient le 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 sur une configuration MetroCluster à quatre nœuds :

    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
    controller_A_2
           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
    14 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 la livraison en commande ou de la livraison hors commande des trames sur le logiciel ONTAP

Vous devez configurer soit la livraison dans l'ordre (IOD), soit la livraison hors commande (OOD) des trames en fonction de la configuration du commutateur Fibre Channel (FC).

Description de la tâche

Si le commutateur FC est configuré pour IOD, le logiciel ONTAP doit être configuré pour IOD. De la même façon, si le commutateur FC est configuré pour OOD, ONTAP doit être configuré pour OOD.

Remarque Vous devez redémarrer le contrôleur pour modifier la configuration.
Étape
  1. Configurez ONTAP pour qu'il fonctionne soit IOD ou OOD des trames.

    • Par défaut, IOD des trames est activé dans ONTAP. Pour vérifier les détails de configuration :

      1. Entrer en mode avancé :

        set advanced

      2. Vérifiez les paramètres :

        metrocluster interconnect adapter show

      mcc4-b12_siteB::*> metrocluster interconnect adapter show
                                   Adapter Link   Is OOD
      Node         Adapter Name    Type    Status Enabled? IP Address  Port Number
      ------------ --------------- ------- ------ -------- ----------- -----------
      mcc4-b1      fcvi_device_0   FC-VI    Up    false    17.0.1.2 	   	6a
      mcc4-b1      fcvi_device_1   FC-VI    Up    false    18.0.0.2   	 	6b
      mcc4-b1      mlx4_0          IB       Down  false    192.0.5.193 	 ib2a
      mcc4-b1      mlx4_0          IB       Up    false    192.0.5.194 	 ib2b
      mcc4-b2      fcvi_device_0   FC-VI    Up    false    17.0.2.2		    6a
      mcc4-b2      fcvi_device_1   FC-VI    Up    false    18.0.1.2    	 6b
      mcc4-b2      mlx4_0          IB       Down  false    192.0.2.9   	 ib2a
      mcc4-b2      mlx4_0          IB       Up    false    192.0.2.10  	 ib2b
      8 entries were displayed.
    • Les étapes suivantes doivent être effectuées sur chaque nœud pour configurer un OOD des trames :

      1. Entrer en mode avancé :

        set advanced

      2. Vérifiez les paramètres de configuration MetroCluster :

        metrocluster interconnect adapter show

        mcc4-b12_siteB::*> metrocluster interconnect adapter show
                                     Adapter Link   Is OOD
        Node         Adapter Name    Type    Status Enabled? IP Address  Port Number
        ------------ --------------- ------- ------ -------- ----------- -----------
        mcc4-b1      fcvi_device_0   FC-VI    Up    false    17.0.1.2 	   	6a
        mcc4-b1      fcvi_device_1   FC-VI    Up    false    18.0.0.2   	 	6b
        mcc4-b1      mlx4_0          IB       Down  false    192.0.5.193 	 ib2a
        mcc4-b1      mlx4_0          IB       Up    false    192.0.5.194 	 ib2b
        mcc4-b2      fcvi_device_0   FC-VI    Up    false    17.0.2.2		    6a
        mcc4-b2      fcvi_device_1   FC-VI    Up    false    18.0.1.2    	 6b
        mcc4-b2      mlx4_0          IB       Down  false    192.0.2.9   	 ib2a
        mcc4-b2      mlx4_0          IB       Up    false    192.0.2.10  	 ib2b
        8 entries were displayed.
      3. Activer OOD sur le noeud "cc4-b1" et le noeud "cc4-b2":

        metrocluster interconnect adapter modify -node node_name -is-ood-enabled true

      mcc4-b12_siteB::*> metrocluster interconnect adapter modify -node mcc4-b1 -is-ood-enabled true
      mcc4-b12_siteB::*> metrocluster interconnect adapter modify -node mcc4-b2 -is-ood-enabled true
      1. Redémarrez le contrôleur en effectuant un basculement haute disponibilité dans les deux sens.

      2. Vérifiez les paramètres :

        metrocluster interconnect adapter show

    mcc4-b12_siteB::*> metrocluster interconnect adapter show
                                 Adapter Link   Is OOD
    Node         Adapter Name    Type    Status Enabled? IP Address  Port Number
    ------------ --------------- ------- ------ -------- ----------- -----------
    mcc4-b1      fcvi_device_0   FC-VI   Up     true      17.0.1.2   	 6a
    mcc4-b1      fcvi_device_1   FC-VI   Up     true      18.0.0.2    	6b
    mcc4-b1      mlx4_0          IB      Down   false     192.0.5.193 	ib2a
    mcc4-b1      mlx4_0          IB      Up     false     192.0.5.194 	ib2b
    mcc4-b2      fcvi_device_0   FC-VI   Up     true      17.0.2.2    	6a
    mcc4-b2      fcvi_device_1   FC-VI   Up     true      18.0.1.2    	6b
    mcc4-b2      mlx4_0          IB      Down   false     192.0.2.9   	ib2a
    mcc4-b2      mlx4_0          IB      Up     false     192.0.2.10  	ib2b
    8 entries were displayed.

Configuration du protocole SNMPv3 dans une configuration MetroCluster

Avant de commencer

Les protocoles d'authentification et de confidentialité sur les switches et sur le système ONTAP doivent être identiques.

Description de la tâche

ONTAP prend actuellement en charge le chiffrement AES-128.

Étapes
  1. Créer un utilisateur SNMP pour chaque switch à partir de l'invite du contrôleur :

    security login create

    Controller_A_1::> security login create -user-or-group-name snmpv3user -application snmp -authentication-method usm -role none -remote-switch-ipaddress 10.10.10.10
  2. Répondez aux invites suivantes si nécessaire sur votre site :

    Enter the authoritative entity's EngineID [remote EngineID]:
    
    Which authentication protocol do you want to choose (none, md5, sha, sha2-256) [none]: sha
    
    Enter the authentication protocol password (minimum 8 characters long):
    
    Enter the authentication protocol password again:
    
    Which privacy protocol do you want to choose (none, des, aes128) [none]: aes128
    
    Enter privacy protocol password (minimum 8 characters long):
    
    Enter privacy protocol password again:
    Remarque Le même nom d'utilisateur peut être ajouté à différents commutateurs avec des adresses IP différentes.
  3. Créer un utilisateur SNMP pour le reste des commutateurs.

    L'exemple suivant montre comment créer un nom d'utilisateur pour un commutateur avec l'adresse IP 10.10.10.11.

    Controller_A_1::> security login create -user-or-group-name snmpv3user -application snmp -authentication-method usm -role none -remote-switch-ipaddress 10.
    10.10.11
  4. Vérifier qu'il y a une entrée de connexion pour chaque commutateur :

    security login show

    Controller_A_1::> security login show -user-or-group-name snmpv3user -fields remote-switch-ipaddress
    
    vserver      user-or-group-name application authentication-method remote-switch-ipaddress
    
    ------------ ------------------ ----------- --------------------- -----------------------
    
    node_A_1 SVM 1 snmpv3user     snmp        usm                   10.10.10.10
    
    node_A_1 SVM 2 snmpv3user     snmp        usm                   10.10.10.11
    
    node_A_1 SVM 3 snmpv3user    snmp        usm                   10.10.10.12
    
    node_A_1 SVM 4 snmpv3user     snmp        usm                   10.10.10.13
    
    4 entries were displayed.
  5. Configurer SNMPv3 sur les commutateurs à partir de l'invite du commutateur :

    Commutateurs Brocade

    snmpconfig --set snmpv3

    Commutateurs Cisco

    snmp-server user <user_name> auth [md5/sha/sha-256] <auth_password> priv (aes-128) <priv_password>

    Si vous avez besoin d'un accès RO, après "User (ro):", spécifiez "snmpv3user". L'exemple suivant utilise des commutateurs Brocade :

    Switch-A1:admin> snmpconfig --set snmpv3
    SNMP Informs Enabled (true, t, false, f): [false] true
    SNMPv3 user configuration(snmp user not configured in FOS user database will have physical AD and admin role as the default):
    User (rw): [snmpadmin1]
    Auth Protocol [MD5(1)/SHA(2)/noAuth(3)]: (1..3) [3]
    Priv Protocol [DES(1)/noPriv(2)/AES128(3)/AES256(4)]): (2..2) [2]
    Engine ID: [00:00:00:00:00:00:00:00:00]
    User (ro): [snmpuser2] snmpv3user
    Auth Protocol [MD5(1)/SHA(2)/noAuth(3)]: (1..3) [2]
    Priv Protocol [DES(1)/noPriv(2)/AES128(3)/AES256(4)]): (2..2) [3]

    L'exemple montre comment configurer un utilisateur en lecture seule. Vous pouvez régler les utilisateurs RW si nécessaire.

    Vous devez également définir des mots de passe pour les comptes inutilisés afin de les sécuriser et d'utiliser le meilleur cryptage disponible dans votre version de ONTAP.

  6. Configurez le cryptage et les mots de passe sur les autres utilisateurs du commutateur, selon les besoins de votre site.

Configuration des composants MetroCluster pour le contrôle de l'état du système

Vous devez effectuer certaines étapes de configuration spéciales avant de surveiller les composants dans une configuration MetroCluster.

Description de la tâche

Ces tâches s'appliquent uniquement aux systèmes avec des ponts FC-SAS.

À partir de Fabric OS 9.0.1, SNMPv2 n'est pas pris en charge pour la surveillance de l'état des commutateurs Brocade, vous devez utiliser SNMPv3 à la place. Si vous utilisez SNMPv3, vous devez configurer SNMPv3 dans ONTAP avant de passer à la section suivante. Pour plus de détails, voir Configuration du protocole SNMPv3 dans une configuration MetroCluster.

Remarque
  • Vous devez placer des ponts et une LIF de node-management dans un réseau dédié pour éviter les interférences provenant d'autres sources.

  • Si vous utilisez un réseau dédié pour la surveillance de l'état de santé, chaque nœud doit disposer d'une LIF de node-management sur ce réseau dédié.

Configuration des commutateurs MetroCluster FC pour le contrôle de l'état du système

Dans une configuration MetroCluster Fabric-Attached, vous devez effectuer des étapes de configuration supplémentaires pour surveiller les commutateurs FC.

Remarque Avec ONTAP 9.8, le storage switch la commande est remplacée par system switch. Les étapes suivantes présentent le storage switch Mais si vous exécutez ONTAP 9.8 ou version ultérieure, le system switch commande recommandée.
Étapes
  1. Ajouter un commutateur avec une adresse IP à chaque nœud MetroCluster :

    La commande que vous exécutez dépend de l'utilisation de SNMPv2 ou SNMPv3.

    Ajouter un commutateur à l'aide de SNMPv3 :

    storage switch add -address <ip_adddress> -snmp-version SNMPv3 -snmp-community-or-username <SNMP_user_configured_on_the_switch>

    Ajouter un commutateur à l'aide de SNMPv2 :

    storage switch add -address ipaddress

    Cette commande doit être répétée sur les quatre commutateurs de la configuration MetroCluster.

    Remarque Les commutateurs FC Brocade 7840 et toutes les alertes sont pris en charge dans le cadre de la surveillance de l'état, à l'exception de NoISLPresent_Alert.

    L'exemple suivant montre la commande d'ajout d'un commutateur avec l'adresse IP 10.10.10.10 :

    controller_A_1::> storage switch add -address 10.10.10.10
  2. Vérifier que tous les commutateurs sont correctement configurés :

    storage switch show

    La prise en compte de toutes les données peut prendre jusqu'à 15 minutes en raison de l'intervalle d'interrogation de 15 minutes.

    L'exemple suivant montre la commande donnée pour vérifier que les commutateurs MetroCluster FC sont configurés :

    controller_A_1::> storage switch show
    Fabric           Switch Name     Vendor  Model        Switch WWN       Status
    ---------------- --------------- ------- ------------ ---------------- ------
    1000000533a9e7a6 brcd6505-fcs40  Brocade Brocade6505  1000000533a9e7a6 OK
    1000000533a9e7a6 brcd6505-fcs42  Brocade Brocade6505  1000000533d3660a OK
    1000000533ed94d1 brcd6510-fcs44  Brocade Brocade6510  1000000533eda031 OK
    1000000533ed94d1 brcd6510-fcs45  Brocade Brocade6510  1000000533ed94d1 OK
    4 entries were displayed.
    
    controller_A_1::>

    Si le nom universel (WWN) du commutateur est affiché, le contrôle de l'état du ONTAP peut contacter et surveiller le commutateur FC.

Informations associées

"Administration du système"

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, vous devez effectuer des étapes de configuration spéciales pour surveiller les ponts FC-SAS dans la configuration MetroCluster.

Description de la tâche
  • 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

      9.5 et versions ultérieures

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

      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

      La prise en compte de toutes les données peut prendre jusqu'à 15 minutes en raison de l'intervalle d'interrogation. Le contrôle de l'état du système 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 universel (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.

Description de la tâche

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 alors pas la sortie attendue.

Étapes
  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. Affiche les résultats les plus récents metrocluster check run commande :

    metrocluster check aggregate show

    metrocluster check cluster show

    metrocluster check config-replication show

    metrocluster check lif show

    metrocluster check node show

    Remarque 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"

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.

Description de la tâche

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.
Étapes
  1. Accédez à la page de téléchargement Config Advisor et téléchargez l'outil.

  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 fonctionnement de la haute disponibilité locale

Si vous disposez d'une configuration MetroCluster à quatre nœuds, vérifiez le fonctionnement des paires haute disponibilité locales dans la configuration MetroCluster. Cette opération n'est pas requise dans les configurations à deux nœuds.

Description de la tâche

Les configurations MetroCluster à deux nœuds ne se composent pas de paires haute disponibilité locales, mais cette tâche ne s'applique pas.

Les exemples de cette tâche utilisent des conventions de dénomination standard :

  • Cluster_A

    • Controller_A_1

    • Contrôleur_A_2

  • Cluster_B

    • Contrôleur_B_1

    • Contrôleur_B_2

Étapes
  1. Sur cluster_A, effectuer un basculement et un retour dans les deux sens.

    1. Vérifiez que le basculement du stockage est activé :

      storage failover show

      Le résultat doit indiquer que le basculement est possible pour les deux nœuds :

      cluster_A::> storage failover show
                                    Takeover
      Node           Partner        Possible State Description
      -------------- -------------- -------- ---------------------------
      controller_A_1 controller_A_2 true     Connected to controller_A_2
      
      controller_A_2 controller_A_1 true     Connected to controller_A_1
      2 entries were displayed.
    2. Prendre le contrôle Controller_A_2 à partir du contrôleur_A_1 :

      storage failover takeover controller_A_2

      Vous pouvez utiliser le storage failover show-takeover commande permettant de surveiller la progression de l'opération de basculement.

    3. Vérifiez que le basculement est terminé :

      storage failover show

      Le résultat doit indiquer que le contrôleur_A_1 est en état de basculement, ce qui signifie qu'il a pris le relais de la haute disponibilité :

      cluster_A::> storage failover show
                                    Takeover
      Node           Partner        Possible State Description
      -------------- -------------- -------- -----------------
      controller_A_1 controller_A_2 false    In takeover
      
      controller_A_2 controller_A_1 -        Unknown
      2 entries were displayed.
    4. Remettre le contrôleur_A_2 :

      storage failover giveback controller_A_2

      Vous pouvez utiliser le storage failover show-giveback commande pour contrôler la progression de l'opération de rétablissement.

    5. Confirmer que le basculement du stockage est revenu à un état normal :

      storage failover show

      Le résultat doit indiquer que le basculement est possible pour les deux nœuds :

    cluster_A::> storage failover show
                                  Takeover
    Node           Partner        Possible State Description
    -------------- -------------- -------- ---------------------------
    controller_A_1 controller_A_2 true     Connected to controller_A_2
    
    controller_A_2 controller_A_1 true     Connected to controller_A_1
    2 entries were displayed.
    1. Répétez les sous-étapes précédentes, en prenant cette fois le contrôleur_A_1 à partir du contrôleur_A_2.

  2. Répétez les étapes précédentes sur cluster_B.

Informations associées

"Configuration haute disponibilité"

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.

Étape
  1. Utilisez les procédures négociées de basculement, de rétablissement et de rétablissement "Restaurez vos données après un incident".

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.

Étape
  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.