Chapitre 6 Configuration de la réplication de données à l'aide du logiciel Sun StorEdge Availability Suite 3.1

Ce chapitre fournit des instructions concernant la configuration de la réplication de données entre clusters à l'aide du logiciel Sun StorEdge Availability Suite 3.1.

Il contient également un exemple de configuration de réplication de données pour une application NFS à l'aide du logiciel Sun StorEdge Availability Suite 3.1. Cet exemple s'applique à une configuration de cluster spécifique et fournit des informations détaillées sur l'exécution de tâches individuelles. Il ne décrit pas l'ensemble des étapes requises par d'autres applications ou d'autres configurations de cluster.

Ce chapitre comprend les rubriques suivantes :

• Introduction à la réplication de données

• Instructions de configuration de la réplication de données

• Exemple de configuration

Les procédures décrites dans ce chapitre sont les suivantes :

• Procédure de configuration d'un groupe de périphériques de disques sur le cluster principal

• Procédure de configuration d'un groupe de périphériques de disques sur le cluster secondaire

• Procédure de configuration du système de fichiers sur le cluster principal d'une application NFS

• Procédure de configuration du système de fichiers sur le cluster secondaire d'une application NFS

• Procédure de création d'un groupe de ressources de réplication sur le cluster principal

• Procédure de création d'un groupe de ressources de réplication sur le cluster secondaire

• Procédure de création d'un groupe de ressources d'application sur le cluster principal

• Procédure de création d'un groupe de ressources d'application sur le cluster secondaire

• Procédure d'activation de la réplication sur le cluster principal

• Procédure d'activation de la réplication sur le cluster secondaire

• Procédure de réplication distante

• Procédure d'instantané ponctuel

• Procédure de vérification de la réussite d'une réplication

• Provocation d'un basculement

• Procédure de mise à jour de l'entrée DNS

• Procédure de configuration de l'application pour qu'elle puisse lire et écrire sur le volume secondaire

Introduction à la réplication de données

Cette rubrique aborde la tolérance de sinistre et décrit les méthodes de réplication de données utilisées par le logiciel Sun StorEdge Availability Suite 3.1.

La tolérance de sinistre

La tolérance de sinistre est la capacité du système à restaurer une application sur un autre cluster lorsque survient un échec du cluster principal. La tolérance de sinistre se base sur la réplication de données et le basculement.

La réplication de données consiste à copier les données d'un cluster principal sur un cluster de secours ou secondaire. La réplication de données fournit au cluster secondaire une copie mise à jour des données du cluster principal. Le cluster secondaire peut être situé loin du cluster principal.

Le basculement consiste à transférer automatiquement un groupe de ressources ou de périphériques depuis un cluster principal vers un cluster secondaire. En cas d'échec du cluster principal, l'application et les données sont immédiatement disponibles sur le cluster secondaire.

Méthodes de réplication de données utilisées par le logiciel Sun StorEdge Availability Suite 3.1

Cette rubrique présente les méthodes de réplication distante et d'instantané ponctuel utilisées par le logiciel Sun StorEdge Availability Suite 3.1. Ce logiciel utilise les commandes sndradm(1RPC) et iiadm(1II) pour répliquer les données. Pour de plus amples informations sur ces commandes, reportez-vous au document Sun Cluster 3.0 and Sun StorEdge Software Integration Guide.

Réplication distante

La réplication distante est illustrée dans la Figure 6–1. Les données du volume maître du disque principal sont répliquées sur celui du disque secondaire à travers une connexion TCP/IP. Un bitmap de réplication distante fait le suivi des différences entre le volume maître du disque principal et celui du disque secondaire.

Figure 6–1 Réplication distante

La réplication distante peut être effectuée de façon synchrone en temps réel ou asynchrone. Sur chaque cluster, chaque ensemble de volumes peut être configuré individuellement en choisissant une réplication synchrone ou asynchrone.

Dans la réplication de données synchrone, une opération d'écriture n'est pas confirmée comme étant terminée tant que le volume distant n'a pas été mis à jour.

Dans la réplication de données asynchrone, une opération d'écriture est confirmée comme étant terminée avant la mise à jour du volume distant. La réplication de données asynchrone fournit une plus grande flexibilité sur une longue distance et une bande passante étroite.

Instantané ponctuel

L'instantané ponctuel est illustré dans la Figure 6–2. Les données du volume maître de chaque disque sont copiées sur le volume en double du même disque. Le bitmap ponctuel fait le suivi des différences entre le volume maître et le volume en double. Une fois les données copiées sur le volume en double, le bitmap ponctuel est réinitialisé.

Figure 6–2 Instantané ponctuel

Réplication de l'exemple de configuration

La figure suivante illustre l'utilisation de la réplication distante et de l'instantané ponctuel dans l'Exemple de configuration.

Figure 6–3 Réplication de l'exemple de configuration

Instructions de configuration de la réplication de données

Cette rubrique fournit des instructions de configuration de la réplication de données entre clusters. Elle contient également des astuces pour la configuration de groupes de ressources de réplication et d'application. Suivez ces instructions pour configurer la réplication de données de votre cluster.

Cette section traite les rubriques suivantes :

• Configuration des groupes de ressources de réplication

• Configuration des groupes de ressources d'application

• Configuration des groupes de ressources pour une application de basculement

• Configuration des groupes de ressources pour une application évolutive

• Instructions de gestion d'un basculement ou d'une commutation

Configuration des groupes de ressources de réplication

Les groupes de ressources de réplication placent le groupe de périphériques sous le contrôle du logiciel Sun StorEdge Availability Suite 3.1 avec les ressources de nom d'hôte logique. Un groupe de ressources de réplication doit présenter les caractéristiques suivantes :

• Être un groupe de ressources de basculement

  Une ressource de basculement ne peut être exécutée que sur un seul noeud à la fois. En cas de basculement, les ressources de basculement interviennent.

• Disposer d'une ressource de nom d'hôte logique

  Le nom d'hôte logique doit être hébergé par le cluster principal. Après un basculement ou une commutation, le nom d'hôte logique doit figurer sur le cluster secondaire. Le DNS (système de noms de domaines) est utilisé pour associer un nom d'hôte logique à un cluster.

• Disposer d'une ressource HAStoragePlus

  La ressource HAStoragePlus génère la commutation du groupe de périphériques en cas de basculement ou de commutation du groupe de ressources de réplication. Sun Cluster génère également la commutation du groupe de ressources de réplication en cas de commutation du groupe de périphériques. Ainsi, le groupe de ressources de réplication et le groupe de périphériques sont toujours placés sur le même noeud ou contrôlés par celui-ci.

  Les propriétés d'extension suivantes doivent être définies dans la ressource HAStoragePlus :

  • GlobalDevicePaths Cette propriété d'extension détermine le groupe de périphériques auquel appartient un volume.

  • AffinityOn property = True. Cette propriété d'extension entraîne la commutation ou le basculement du groupe de périphériques lors de la commutation ou du basculement du groupe de ressources de réplication. Cette fonction est appelée commutation analogue.

  Pour de plus amples informations sur HAStoragePlus, reportez-vous à la page de manuel SUNW.HAStoragePlus(5).

• Porter le nom du groupe de périphériques avec lequel il est placé, suivi de -stor-rg

  Par exemple, groupe_périphérique-stor-rg.

• Être en ligne à la fois sur le cluster principal et le cluster secondaire

Configuration des groupes de ressources d'application

Pour être hautement disponible, une application doit être gérée en tant que ressource dans un groupe de ressources d'application. Un groupe de ressources d'application peut être configuré pour une application de basculement ou une application évolutive.

Les ressources d'application et les groupes de ressources d'application configurés sur le cluster principal doivent également l'être sur le cluster secondaire. Les données auxquelles a accès la ressource d'application doivent également être répliquées sur le cluster secondaire.

Cette rubrique fournit des instructions concernant la configuration des groupes de ressources d'application suivants :

• Configuration des groupes de ressources pour une application de basculement

• Configuration des groupes de ressources pour une application évolutive

Configuration des groupes de ressources pour une application de basculement

Dans une application de basculement, une application ne s'exécute que sur un seul noeud à la fois. En cas d'échec sur ce noeud, l'application bascule sur un autre noeud du même cluster. Le groupe de ressources d'une application de basculement doit présenter les caractéristiques suivantes :

• Disposer d'une ressource HAStoragePlus générant la commutation du groupe de périphériques en cas de basculement ou de commutation du groupe de ressources d'application

  Le groupe de périphériques est placé avec le groupe de ressources de réplication et le groupe de ressources d'application. Ainsi, la commutation du groupe de ressources d'application génère la commutation du groupe de périphériques et du groupe de ressources de réplication. Le groupe de ressources d'application, le groupe de ressources de réplication et le groupe de périphériques sont contrôlés par le même noeud.

  Notez cependant que la commutation ou le basculement du groupe de périphériques ou du groupe de ressources de réplication n'entraîne pas la commutation ou le basculement du groupe de ressources d'application.

  • Si les données de l'application sont montées globalement, la présence d'une ressource HAStoragePlus dans le groupe de ressources d'application n'est pas obligatoire, mais elle est recommandée.

  • Si les données de l'application sont montées localement, la présence d'une ressource HAStoragePlus dans le groupe de ressources d'application est obligatoire.

    Sans cela, la commutation ou le basculement du groupe de ressources d'application ne déclenchera pas la commutation ou le basculement du groupe de ressources de réplication et du groupe de périphériques. Après une commutation ou un basculement, le groupe de ressources d'application, le groupe de ressources de réplication et le groupe de périphériques ne seraient plus contrôlés par le même noeud.

  Pour de plus amples informations sur HAStoragePlus, reportez-vous à la page de manuel SUNW.HAStoragePlus(5).

• Être en ligne sur le cluster principal et hors ligne sur le cluster secondaire

  Le groupe de ressources d'application doit être mis en ligne sur le cluster secondaire lorsque celui-ci prend la relève du cluster principal.

La figure suivante illustre la configuration d'un groupe de ressources d'application et d'un groupe de ressources de réplication dans une application de basculement.

Figure 6–4 Configuration de groupes de ressources dans une application de basculement

Configuration des groupes de ressources pour une application évolutive

Dans une application évolutive, une application s'exécute sur plusieurs noeuds à la fois pour créer un service logique unique. En cas d'échec d'un noeud exécutant une application évolutive, le basculement ne se produit pas. L'application continue de s'exécuter sur d'autres noeuds.

Lorsqu'une application évolutive est gérée comme une ressource dans un groupe de ressources d'application, il n'est pas nécessaire de placer le groupe de ressources d'application avec le groupe de périphériques. Il est donc inutile de créer une ressource HAStoragePlus pour le groupe de ressources d'application.

Le groupe de ressources d'une application évolutive doit présenter les caractéristiques suivantes :

• Avoir une dépendance sur le groupe de ressources d'adresse partagée

  Les noeuds exécutant l'application évolutive utilisent l'adresse partagée pour distribuer les données entrantes.

• Être en ligne sur le cluster principal et hors ligne sur le cluster secondaire

La figure suivante illustre la configuration des groupes de ressources dans une application évolutive.

Figure 6–5 Configuration de groupes de ressources dans une application évolutive

Instructions de gestion d'un basculement ou d'une commutation

En cas d'échec du cluster principal, l'application doit être commutée sur le cluster secondaire dès que possible. Pour que s'active le basculement du cluster secondaire, le DNS doit être mis à jour. De plus, le volume secondaire doit être monté dans le répertoire du point de montage correspondant au système de fichiers de l'application.

Les DNS associent un client au nom d'hôte logique d'une application. Après un basculement ou une commutation, le mappage du DNS au cluster principal doit être supprimé et un mappage du DNS au cluster secondaire doit être créé. La figure suivante illustre la procédure de mappage du DNS d'un client à un cluster.

Figure 6–6 Mappage du DNS d'un client à un cluster

Pour mettre à jour le DNS, utilisez la commande nsupdate. Pour de plus amples informations, reportez-vous à la page de manuel nsupdate(1M). Pour consulter un exemple de gestion d'un basculement ou d'une commutation, reportez-vous à l'Exemple de gestion d'un basculement ou d'une commutation.

Une fois la réparation effectuée, le cluster principal peut être remis en ligne. Pour revenir au cluster principal d'origine, procédez comme suit :

1. Synchronisez le cluster principal avec le cluster secondaire pour garantir que le volume principal est à jour.

2. Mettez à jour le DNS pour que les clients puissent accéder à l'application sur le cluster principal.

3. Montez le volume principal dans le répertoire du point de montage correspondant au système de fichiers de l'application.

Exemple de configuration

Cette rubrique fournit un exemple pas à pas de configuration d'une réplication de données pour une application NFS à l'aide du logiciel Sun StorEdge Availability Suite 3.1.

Connexion et installation des clusters

La Figure 6–7 illustre la configuration de cluster utilisée dans l'exemple de configuration. Le cluster secondaire de l'exemple de configuration contient un noeud, mais d'autres configurations de cluster peuvent être utilisées.

Figure 6–7 Exemple de configuration de cluster

Le Tableau 6–1 fournit un résumé du matériel et des logiciels requis dans l'exemple de configuration. Le système d'exploitation, le logiciel Sun Cluster et le gestionnaire de volumes doivent être installés sur les noeuds de cluster avant de procéder à l'installation du logiciel et des patchs Sun StorEdge Availability Suite 3.1.

Tableau 6–1 Matériel et logiciels requis

Matériel ou logiciels	Conditions requises
Matériel du noeud	Le logiciel Sun StorEdge Availability Suite 3.1 est pris en charge sur tous les serveurs utilisant le système d'exploitation Solaris.   Pour de plus amples informations sur le matériel à utiliser, reportez-vous au document Sun Cluster 3.x Hardware Administration Manual for Solaris OS
Espace disque	Environ 11 Mo.
Environnement d' exploitation	Versions Solaris 8 ou Solaris 9 prises en charge par le logiciel Sun Cluster.  Tous les noeuds doivent utiliser la même version de système d'exploitation.  Pour de plus amples informations sur l'installation, reportez-vous à la rubrique Installation du logiciel.
Logiciel Sun Cluster	Logiciel Sun Cluster 3.1 4/04.   Pour obtenir des informations d'installation, reportez-vous au Chapitre 2 et à la rubrique Installation du logiciel Sun Cluster sur un cluster à noeud unique.
Gestionnaire de volume	Solstice DiskSuite/Solaris Volume Manager ou VERITAS Volume Manager (VxVM).  Tous les noeuds doivent utiliser la même version de gestionnaire de volumes.  Pour obtenir des informations d'installation, reportez-vous aux rubriques Installation et configuration du logiciel Solstice DiskSuite/Solaris Volume Manager et SPARC: installation et configuration du logiciel VxVM.
Logiciel Sun StorEdge Availability Suite 3.1	Pour de plus amples informations sur l'installation du logiciel, reportez-vous aux documents Sun StorEdge Availability Suite 3.1 Point-in-Time Copy Software Installation Guide et Sun StorEdge Availability Suite 3.1 Remote Mirror Software Installation Guide.
Patchs du logiciel Sun StorEdge Availability Suite 3.1	Pour obtenir des informations sur les patchs les plus récents, consultez le site http://sunsolve.sun.com.

Exemple de configuration des groupes de périphériques et des groupes de ressources

Ce chapitre décrit la configuration des groupes de périphériques de disques et des groupes de ressources pour une application NFS. Vous trouverez dans le tableau suivant les noms des groupes et ressources ayant été créés pour cet exemple de configuration.

Tableau 6–2 Récapitulatif des groupes et ressources de l'exemple de configuration

Groupe ou ressource	Nom	Description
Groupe de périphériques de disque	groupe_périphériques	Groupe de périphériques du disque.
Groupe de ressources et ressources de réplication	groupe_périphériques-stor-rg	Groupe des ressources de réplication.
	prin_grrép_nhlog, sec_grrép_nhlog	Noms d'hôtes logiques du groupe de ressources de réplication sur le cluster principal et sur le cluster secondaire.
	groupe_périphériques_stor	Ressource HAStoragePlus du groupe de ressources de réplication.
Groupe de ressources et ressources d'application	gr_nfs	Groupe de ressources d'application.
	prin_grnfs_nhlog, sec_grnfs_nhlog	Noms d'hôtes logiques du groupe de ressources d'application sur le cluster principal et sur le cluster secondaire.
	rs_dg_nfs	Ressource HAStoragePlus de l'application.
	rs_nfs	Ressource NFS.

À l'exception de groupe_périphériques-stor-rg, les noms des groupes et ressources ne sont donnés qu'à titre d'exemples et peuvent être modifiés si nécessaire. Le nom du groupe de ressources de réplication doit avoir le format suivant : groupe_périphériques-stor-rg.

Configuration des groupes de périphériques de disques

Cette rubrique décrit la configuration d'un groupe de périphériques de disques sur le cluster principal et sur le cluster secondaire. Cet exemple de configuration utilise le logiciel VxVM. Pour de plus amples informations sur le logiciel Solstice DiskSuite/Solaris Volume Manager, reportez-vous au Chapitre 3.

La figure suivante illustre les volumes créés dans le groupe de périphériques de disques.

Figure 6–8 Volumes du groupe de périphériques de disques

---

Remarque :

les volumes définis dans cette section ne doivent contenir aucune zone privée de label de disque, comme le cylindre 0. VxVM gère automatiquement cette contrainte.

---

Procédure de configuration d'un groupe de périphériques de disques sur le cluster principal

1. Créez un groupe de disques contenant quatre volumes, du volume 1 au volume 4.

   Pour de plus amples informations sur la configuration d'un groupe de disques à l'aide de VxVM reportez-vous au Chapitre 4.

2. Accédez au noeud_A en tant que superutilisateur.

   Le noeud_A est le premier noeud du cluster principal. Pour vous rappeler quel noeud est le noeud_A, reportez-vous à la Figure 6–7.

3. Configurez le groupe de disques pour créer un groupe de périphériques de disques.

   noeud_A# /usr/cluster/bin/scconf -a -D type=vxvm,name=groupe_périphériques \ ,nodelist=noeud_A:noeud_B

   Le groupe de périphériques de disques est appelé groupe_périphériques.

4. Démarrez le groupe de périphériques de disques.

   noeud_A# /usr/cluster/bin/scswitch -z -D groupe_périphériques -h noeud_A

5. Synchronisez le groupe de périphériques de disques à l'aide du logiciel Sun Cluster.

   noeud_A# /usr/cluster/bin/scconf -c -D name=groupe_périphériques,sync

6. Créez le système de fichiers du groupe de périphériques de disques.

   noeud_A# /usr/sbin/newfs /dev/vx/rdsk/groupe_périphériques/vol01 < /dev/null noeud_A# /usr/sbin/newfs /dev/vx/rdsk/groupe_périphériques/vol02 < /dev/null noeud_A# /usr/sbin/newfs /dev/vx/rdsk/groupe_périphériques/vol03 < /dev/null noeud_A# /usr/sbin/newfs /dev/vx/rdsk/groupe_périphériques/vol04 < /dev/null

7. Activez l'accès distant entre les noeuds des clusters principal et secondaire en ajoutant les entités suivantes au fichier /.rhosts sur le noeud_A et le noeud_B :

   noeud_C + ; + root.

Procédure de configuration d'un groupe de périphériques de disques sur le cluster secondaire

1. Suivez les étapes de la Procédure de configuration d'un groupe de périphériques de disques sur le cluster principal à l'exception des points suivants :

   • Remplacez le noeud_A par le noeud_C.

   • N'utilisez pas le noeud_B.

   • À l'Étape 3, n'incluez le noeud_C que dans la liste de noeuds. Exemple :

     noeud_C# /usr/cluster/bin/scconf -a -D type=vxvm,name=groupe_périphériques \ ,nodelist=noeud_C

   • À l'Étape 7, ajoutez les entités suivantes au fichier /.rhosts sur le noeud_C uniquement :

     noeud_A + ; noeud_B + ; + root.

Configuration des systèmes de fichiers pour une application NFS

Cette rubrique décrit la configuration des systèmes de fichiers d'une application NFS.

Procédure de configuration du système de fichiers sur le cluster principal d'une application NFS

1. Sur le noeud_A et le noeud_B, créez un répertoire de point de montage pour le système de fichiers NFS.

   Exemple :

   noeud_A# mkdir /global/point_montage

2. Sur le noeud_A et le noeud_B, configurez le volume maître à monter automatiquement sur le point de montage.

   Ajoutez ou substituez le texte suivant dans le fichier /etc/vfstab sur le noeud_A et le noeud_B. Le texte doit tenir sur une seule ligne.

   /dev/vx/dsk/groupe_périphériques/vol01 /dev/vx/rdsk/groupe_périphériques/vol01 \ /global/point_montage ufs 3 no global,logging

   Pour vous rappeler les noms et numéros de volumes utilisés dans le groupe de périphériques de disques, reportez-vous à la Figure 6–8.

3. Sur le noeud_A, créez un volume pour les informations du système de fichiers utilisées par le logiciel Sun StorEdge Availability Suite 3.1.

   noeud_A# /usr/sbin/vxassist -g groupe_périphériques make vol05 120m disque_1

   Le volume 5 contient les informations concernant le système de fichiers utilisées par le logiciel Sun StorEdge Availability Suite 3.1.

4. Sur le noeud_A, resynchronisez le groupe de périphériques avec le logiciel Sun Cluster.

   noeud_A# /usr/cluster/bin/scconf -c -D name=groupe_périphériques,sync

5. Sur le noeud_A, créez le système de fichiers du volume 5.

   noeud_A# /usr/sbin/newfs /dev/vx/rdsk/groupe_périphériques/vol05

6. Sur le noeud_A et le noeud_B, créez un point de montage pour le volume 5.

   Exemple :

   noeud_A# mkdir /global/etc

7. Sur le noeud_A et le noeud_B, configurez le volume 5 à monter automatiquement sur le point de montage.

   Ajoutez ou substituez le texte suivant dans le fichier /etc/vfstab sur le noeud_A et le noeud_B. Le texte doit tenir sur une seule ligne.

   /dev/vx/dsk/groupe_périphériques/vol05 /dev/vx/rdsk/groupe_périphériques/vol05 \ /global/etc ufs 3 yes global,logging

8. Montez le volume 5 sur le noeud_A.

   noeud_A# mount /global/etc

9. Rendez le volume 5 accessible aux systèmes distants.

   1. Créez un répertoire appelé /global/etc/SUNW.nfs sur le noeud_A.

      noeud_A# mkdir -p /global/etc/SUNW.nfs

   2. Créez le fichier /global/etc/SUNW.nfs/dfstab.rs_nfs sur le noeud_A.

      noeud_A# touch /global/etc/SUNW.nfs/dfstab.rs_nfs

   3. Ajoutez la ligne suivante au fichier /global/etc/SUNW.nfs/dfstab.rs_nfs sur le noeud_A :

      share -F nfs -o rw -d "HA NFS" /global/point_montage

Procédure de configuration du système de fichiers sur le cluster secondaire d'une application NFS

Suivez les étapes de la Procédure de configuration du système de fichiers sur le cluster principal d'une application NFS à l'exception des points suivants :

• Remplacez le noeud_A par le noeud_C.

• N'utilisez pas le noeud_B.

Création de groupes de ressources de réplication

Cette rubrique décrit la création d'un groupe de ressources de réplication sur les clusters principal et secondaire.

Procédure de création d'un groupe de ressources de réplication sur le cluster principal

1. Accédez au noeud_A en tant que superutilisateur.

2. Enregistrez SUNW.HAStoragePlus en tant que type de ressource.

   noeud_A# /usr/cluster/bin/scrgadm -a -t SUNW.HAStoragePlus

3. Créez un groupe de ressources de réplication pour le groupe de périphériques de disques.

   noeud_A# /usr/cluster/bin/scrgadm -a -g groupe_périphériques-stor-rg -h noeud_A,noeud_B

   groupe_périphériques

   Nom du groupe de périphériques de disques.

   groupe_périphériques-stor-rg

   Nom du groupe de ressources de réplication.

   -h noeud_A, noeud_B

   Spécifie les noeuds de cluster pouvant contrôler le groupe de ressources de réplication.

4. Ajoutez une ressource SUNW.HAStoragePlus au groupe de ressources de réplication.

   noeud_A# /usr/cluster/bin/scrgadm -a -j groupe_périphériques-stor \ -g groupe_périphériques-stor-rg -t SUNW.HAStoragePlus \ -x GlobalDevicePaths=groupe_périphériques \ -x AffinityOn=True

   groupe_périphériques_stor

   Ressource HAStoragePlus du groupe de ressources de réplication.

   -x GlobalDevicePaths=

   Spécifie la propriété d'extension sur laquelle s'appuie Sun StorEdge Availability Suite 3.1.

   -x AffinityOn=True

   Spécifie que la ressource SUNW.HAStoragePlus doit effectuer une commutation analogue pour les périphériques globaux et les systèmes de fichiers de cluster définis par -x GlobalDevicePaths=. Ainsi, lorsque le groupe de ressources de réplication bascule ou commute, le groupe de périphériques associé commute également.

   Pour de plus amples informations sur les propriétés d'extension, reportez-vous à la page de manuel SUNW.HAStoragePlus(5).

5. Ajoutez une ressource de nom d'hôte logique au groupe de ressources de réplication.

   noeud_A# /usr/cluster/bin/scrgadm -a -L \ -j prin_grrép_nhlog -g groupe_périphériques-stor-rg -l prin_grrép_nhlog

   où prin_grrép_nhlog correspond au nom d'hôte logique du groupe de ressources de réplication du cluster principal.

6. Activez les ressources, gérez le groupe de ressources et mettez-le en ligne.

   noeud_A# /usr/cluster/bin/scswitch -Z -g groupe_périphériques-stor-rg noeud_A# /usr/cluster/bin/scswitch -z -g groupe_périphériques-stor-rg -h noeud_A

7. Vérifiez que le groupe de ressources est en ligne.

   noeud_A# /usr/cluster/bin/scstat -g

   Vérifiez dans le champ d'état du groupe de ressources que le groupe de ressources de réplication est en ligne pour le noeud_A et le noeud_B.

Procédure de création d'un groupe de ressources de réplication sur le cluster secondaire

Suivez les étapes de la Procédure de création d'un groupe de ressources de réplication sur le cluster principal à l'exception des points suivants :

• Remplacez le noeud_A par le noeud_C.

• N'utilisez pas le noeud_B.

• Remplacez prin_grrép_nhlog par sec_grrép_nhlog.

Création de groupes de ressources d'application

Cette rubrique décrit la création de groupes de ressources d'application pour une application NFS. Les procédures présentées dans cette rubrique sont spécifiques à l'application. Elles ne peuvent être utilisées pour un autre type d'application.

Procédure de création d'un groupe de ressources d'application sur le cluster principal

1. Accédez au noeud_A en tant que superutilisateur.

2. Enregistrez SUNW.nfs en tant que type de ressource.

   noeud_A# scrgadm -a -t SUNW.nfs

3. Si SUNW.HAStoragePlus n'a pas éte enregistré en tant que type de ressource, enregistrez-le.

   noeud_A# scrgadm -a -t SUNW.HAStoragePlus

4. Créez un groupe de ressources d'application pour le groupe_périphériques.

   noeud_A# scrgadm -a -g gr_nfs \ -y Pathprefix=/global/etc \ -y Auto_start_on_new_cluster=False \ -y RG_dependencies=groupe_périphériques-stor-rg

   gr_nfs

   Nom du groupe de ressources d'application.

   Pathprefix=/global/etc

   Spécifie un répertoire dans lequel les ressources du groupe peuvent écrire des fichiers administratifs.

   Auto_start_on_new_cluster=False

   Spécifie que le groupe de ressources d'application n'est pas démarré automatiquement.

   RG_dependencies=groupe_périphériques-stor-rg

   Spécifie le groupe de ressources duquel dépend le groupe de ressources d'application. Dans cet exemple, le groupe de ressources d'application dépend du groupe de ressources de réplication.

   Si le groupe de ressources d'application est commuté vers un nouveau noeud principal, le groupe de ressources de réplication est automatiquement commuté. Cependant, si le groupe de ressources de réplication est commuté vers un nouveau noeud principal, le groupe de ressources d'application doit être commuté manuellement.

5. Ajoutez une ressource SUNW.HAStoragePlus au groupe de ressources d'application.

   noeud_A# scrgadm -a -j rs_dg_nfs -g gr_nfs \ -t SUNW.HAStoragePlus \ -x fichierSystemMountPoints=/global/point_montage \ -x AffinityOn=True

   rs_dg_nfs

   Nom de la ressource HAStoragePlus pour l'application NFS.

   -x fichierSystemMountPoints=/global/

   Spécifie que le point de montage du système de fichiers est global.

   -t SUNW.HAStoragePlus

   Spécifie que la ressource est de type SUNW.HAStoragePlus.

   -x AffinityOn=True

   Spécifie que la ressource d'application doit effectuer une commutation analogue pour les périphériques globaux et les systèmes de fichiers de cluster définis par -x GlobalDevicePaths=. Ainsi, lorsque le groupe de ressources d'application bascule ou commute, le groupe de périphériques associé commute également.

   Pour de plus amples informations sur les propriétés d'extension, reportez-vous à la page de manuel SUNW.HAStoragePlus(5).

6. Ajoutez une ressource de nom d'hôte logique au groupe de ressources d'application.

   noeud_A# /usr/cluster/bin/scrgadm -a -L -j prin_grnfs_nhlog -g gr_nfs \ -l prin_grnfs_nhlog

   où prin_grnfs_nhlog correspond au nom d'hôte logique du groupe de ressources d'application sur le cluster principal.

7. Activez les ressources, gérez le groupe de ressources d'application et mettez-le en ligne.

   1. Mettez en ligne la ressource HAStoragePlus de l'application NFS.

      noeud_A# /usr/cluster/bin/scrgadm -a -g gr_nfs \ -j rs_nfs -t SUNW.nfs -y ressource_dependencies=rs_dg_nfs

   2. Mettez le groupe de ressources d'application en ligne sur le noeud_A.

      noeud_A# /usr/cluster/bin/scswitch -Z -g gr_nfs noeud_A# /usr/cluster/bin/scswitch -z -g gr_nfs -h noeud_A

8. Vérifiez que le groupe de ressources d'application est en ligne.

   noeud_A# /usr/cluster/bin/scstat -g

   Vérifiez dans le champ d'état du groupe de ressources que le groupe de ressources d'application est en ligne pour le noeud_A et le noeud_B.

Procédure de création d'un groupe de ressources d'application sur le cluster secondaire

1. Créez la ressource de groupe d'application comme décrit de l'Étape 1 à l'Étape 6 dans la Procédure de création d'un groupe de ressources d'application sur le cluster principal, à l'exception des points suivants :

   • Remplacez le noeud_A par le noeud_C.

   • Ignorez les références au noeud_B.

   • Remplacez prin_grnfs_nhlog par sec_grnfs_nhlog.

2. Vérifiez que le groupe de ressources d'application n'est pas en ligne sur le noeud_C.

   noeud_C# /usr/cluster/bin/scswitch -n -j rs_nfs noeud_C# /usr/cluster/bin/scswitch -n -j rs_dg_nfs noeud_C# /usr/cluster/bin/scswitch -n -j sec_grnfs_nhlog noeud_C# /usr/cluster/bin/scswitch -z -g gr_nfs -h ""

   Le groupe de ressources reste hors ligne après une réinitialisation, car Auto_start_on_new_cluster=False.

3. Si le volume global est monté sur le cluster principal, démontez-le du cluster secondaire.

   noeud_C# umount /global/point_montage

   Si le volume est monté sur le cluster secondaire, la synchronisation échoue.

Exemple d'activation de la réplication de données

Cette rubrique décrit l'activation de la réplication de données dans l'exemple de configuration. Elle utilise les commandes sndradm et iiadm du logiciel Sun StorEdge Availability Suite 3.1. Pour de plus amples informations sur ces commandes, reportez-vous au document Sun Cluster 3.0 and Sun StorEdge Software Integration Guide.

Procédure d'activation de la réplication sur le cluster principal

1. Accédez au noeud_A en tant que superutilisateur.

2. Supprimez toutes les transactions.

   noeud_A# /usr/sbin/lockfs -a -f

3. Vérifiez que les noms d'hôtes logiques prin_grrép_nhlog et sec_grrép_nhlog sont en ligne.

   noeud_A# /usr/cluster/bin/scstat -g

   Examinez le champ d'état du groupe de ressources.

4. Activez la réplication distante du cluster principal vers le cluster secondaire.

   Cette étape active la réplication du volume maître du cluster principal vers le volume maître du cluster secondaire. De plus, elle active la réplication vers le bitmap distant sur le volume 4.

   • Si les clusters principal et secondaire sont désynchronisés, exécutez cette commande :

     noeud_A# /usr/opt/SUNWesm/sbin/sndradm -n -e prem_grrép_nhlog \ /dev/vx/rdsk/groupe_périphériques/vol01 \ /dev/vx/rdsk/groupe_périphériques/vol04 sec_grrép_nhlog \ /dev/vx/rdsk/groupe_périphériques/vol01 \ /dev/vx/rdsk/groupe_périphériques/vol04 ip sync

   • Si les clusters principal et secondaire sont synchronisés, exécutez cette commande :

     noeud_A# /usr/opt/SUNWesm/sbin/sndradm -n -E prem_grrép_nhlog \ /dev/vx/rdsk/groupe_périphériques/vol01 \ /dev/vx/rdsk/groupe_périphériques/vol04 sec_grrép_nhlog \ /dev/vx/rdsk/groupe_périphériques/vol01 \ /dev/vx/rdsk/groupe_périphériques/vol04 ip sync

5. Activez l'autosynchronisation.

   noeud_A# /usr/opt/SUNWesm/sbin/sndradm -n -a on prin_grrép_nhlog \ /dev/vx/rdsk/groupe_périphériques/vol01 \ /dev/vx/rdsk/groupe_périphériques/vol04 sec_grrép_nhlog \ /dev/vx/rdsk/groupe_périphériques/vol01 \ /dev/vx/rdsk/groupe_périphériques/vol04 ip sync

   Cette étape active l'autosynchronisation. Lorsque l'état actif de l'autosynchronisation est défini sur on, les ensembles de volumes sont resynchronisés en cas de réinitialisation du système ou de défaillance.

6. Vérifiez que le cluster est en mode journalisation.

   noeud_A# /usr/opt/SUNWesm/sbin/sndradm -P

   Le résultat ressemble à ce qui suit :

   /dev/vx/rdsk/groupe_périphériques/vol01 -> sec_grrép_nhlog:/dev/vx/rdsk/groupe_périphériques/vol01 autosync: off, max q writes:4194304, max q fbas:16384, mode:sync,ctag: groupe_périphériques, state: logging

   En mode journalisation, l'état est logging et l'état actif de l'autosynchronisation est off. Au cours de l'écriture sur le volume de données du disque, le fichier bitmap figurant sur ce disque est mis à jour.

7. Activez l'instantané ponctuel.

   noeud_A# /usr/opt/SUNWesm/sbin/iiadm -e ind \ /dev/vx/rdsk/groupe_périphériques/vol01 \ /dev/vx/rdsk/groupe_périphériques/vol02 \ /dev/vx/rdsk/groupe_périphériques/vol03 noeud_A# /usr/opt/SUNWesm/sbin/iiadm -w \ /dev/vx/rdsk/groupe_périphériques/vol02

   Cette étape active la copie du volume maître du disque principal sur le volume en double du même disque. Dans cet exemple, le volume maître correspond au volume 1, le volume en double au volume 2, et le volume de bitmap ponctuel au volume 3.

8. Attachez l'instantané ponctuel au jeu de miroirs distants.

   noeud_A# /usr/opt/SUNWesm/sbin/sndradm -I a \ /dev/vx/rdsk/groupe_périphériques/vol01 \ /dev/vx/rdsk/groupe_périphériques/vol02 \ /dev/vx/rdsk/groupe_périphériques/vol03

   Cette étape associe l'instantané ponctuel au jeu de miroirs distants. Le logiciel Sun StorEdge Availability Suite 3.1 assure la réalisation d'un instantané ponctuel avant la réplication distante.

Procédure d'activation de la réplication sur le cluster secondaire

1. Accédez au noeud_C en tant que superutilisateur.

2. Supprimez toutes les transactions.

   noeud_C# /usr/sbin/lockfs -a -f

3. Activez la réplication distante du cluster principal vers le cluster secondaire.

   noeud_C# /usr/opt/SUNWesm/sbin/sndradm -n -e prin_grrép_nhlog \ /dev/vx/rdsk/groupe_périphériques/vol01 \ /dev/vx/rdsk/groupe_périphériques/vol04 sec_grrép_nhlog \ /dev/vx/rdsk/groupe_périphériques/vol01 \ /dev/vx/rdsk/groupe_périphériques/vol04 ip sync

   Le cluster principal détecte la présence du cluster secondaire et démarre la synchronisation. Reportez-vous au fichier de consignation système /var/opt/SUNWesm/ds.log pour obtenir des informations sur le statut des clusters.

4. Activez l'instantané ponctuel indépendant.

   noeud_C# /usr/opt/SUNWesm/sbin/iiadm -e ind \ /dev/vx/rdsk/groupe_périphériques/vol01 \ /dev/vx/rdsk/groupe_périphériques/vol02 \ /dev/vx/rdsk/groupe_périphériques/vol03 noeud_C# /usr/opt/SUNWesm/sbin/iiadm -w \ /dev/vx/rdsk/groupe_périphériques/vol02

5. Attachez l'instantané ponctuel au jeu de miroirs distants.

   noeud_C# /usr/opt/SUNWesm/sbin/sndradm -I a \ /dev/vx/rdsk/groupe_périphériques/vol01 \ /dev/vx/rdsk/groupe_périphériques/vol02 \ /dev/vx/rdsk/groupe_périphériques/vol03

Exemple de procédure de réplication de données

Cette rubrique décrit la procédure de réplication de données de l'exemple de configuration. Elle utilise les commandes sndradm et iiadm du logiciel Sun StorEdge Availability Suite 3.1 Pour de plus amples informations sur ces commandes, reportez-vous au document Sun Cluster 3.0 and Sun StorEdge Software Integration Guide.

Procédure de réplication distante

Dans cette procédure, le volume maître du disque principal est répliqué vers le volume maître du disque secondaire. Le volume maître correspond au volume 1 et le volume bitmap miroir distant au volume 4.

1. Accédez au noeud_A en tant que superutilisateur.

2. Vérifiez que le cluster est en mode journalisation.

   noeud_A# /usr/opt/SUNWesm/sbin/sndradm -P

   Le résultat ressemble à ce qui suit :

   /dev/vx/rdsk/groupe_périphériques/vol01 -> sec_grrép_nhlog:/dev/vx/rdsk/groupe_périphériques/vol01 autosync: off, max q writes:4194304, max q fbas:16384, mode:sync,ctag: groupe_périphériques, state: logging

   En mode journalisation, l'état est logging et l'état actif de l'autosynchronisation est off. Au cours de l'écriture sur le volume de données du disque, le fichier bitmap figurant sur ce disque est mis à jour.

3. Supprimez toutes les transactions.

   noeud_A# /usr/sbin/lockfs -a -f

4. Répétez la procédure de l'Étape 1 à l'Étape 3 sur le noeud_C.

5. Copiez le volume maître du noeud_A sur le volume maître du noeud_C.

   noeud_A# /usr/opt/SUNWesm/sbin/sndradm -n -m prin_grrép_nhlog \ /dev/vx/rdsk/groupe_périphériques/vol01 \ /dev/vx/rdsk/groupe_périphériques/vol04 sec_grrép_nhlog \ /dev/vx/rdsk/groupe_périphériques/vol01 \ /dev/vx/rdsk/groupe_périphériques/vol04 ip sync

6. Attendez que la réplication soit terminée et les volumes synchronisés.

   noeud_A# /usr/opt/SUNWesm/sbin/sndradm -n -w prin_grrép_nhlog \ /dev/vx/rdsk/groupe_périphériques/vol01 \ /dev/vx/rdsk/groupe_périphériques/vol04 sec_grrép_nhlog \ /dev/vx/rdsk/groupe_périphériques/vol01 \ /dev/vx/rdsk/groupe_périphériques/vol04 ip sync

7. Vérifiez que le cluster est en mode réplication.

   noeud_A# /usr/opt/SUNWesm/sbin/sndradm -P

   Le résultat ressemble à ce qui suit :

   /dev/vx/rdsk/groupe_périphériques/vol01 -> sec_grrép_nhlog:/dev/vx/rdsk/groupe_périphériques/vol01 autosync: on, max q writes:4194304, max q fbas:16384, mode:sync,ctag: groupe_périphériques, state: replicating

   En mode réplication, l'état est replicating et l'état actif de l'autosynchronisation est on. Au cours de l'écriture sur le volume principal, le volume secondaire est mis à jour par le logiciel Sun StorEdge Availability Suite 3.1.

Procédure d'instantané ponctuel

Dans cette procédure, l'instantané ponctuel a été utilisé pour synchroniser le volume en double du cluster principal avec le volume maître du cluster principal. Le volume maître correspond au volume 1 et le volume en double au volume 2.

1. Accédez au noeud_A en tant que superutilisateur.

2. Arrêtez l'application exécutée sur le noeud_A.

   noeud_A# /usr/cluster/bin/scswitch -n -j rs_nfs

3. Mettez le cluster principal en mode journalisation.

   noeud_A# /usr/opt/SUNWesm/sbin/sndradm -n -l prem_grrép_nhlog \ /dev/vx/rdsk/groupe_périphériques/vol01 \ /dev/vx/rdsk/groupe_périphériques/vol04 sec_grrép_nhlog \ /dev/vx/rdsk/groupe_périphériques/vol01 \ /dev/vx/rdsk/groupe_périphériques/vol04 ip sync

   Au cours de l'écriture sur le volume de données du disque, le fichier bitmap figurant sur ce disque est mis à jour. Aucune réplication n'est effectuée.

4. Synchronisez le volume en double du cluster principal avec son volume maître.

   noeud_A# /usr/opt/SUNWesm/sbin/iiadm -u s /dev/vx/rdsk/groupe_périphériques/vol02 noeud_A# /usr/opt/SUNWesm/sbin/iiadm -w /dev/vx/rdsk/groupe_périphériques/vol02

5. Synchronisez le volume en double du cluster secondaire avec son volume maître.

   noeud_C# /usr/opt/SUNWesm/sbin/iiadm -u s /dev/vx/rdsk/groupe_périphériques/vol02 noeud_C# /usr/opt/SUNWesm/sbin/iiadm -w /dev/vx/rdsk/groupe_périphériques/vol02

6. Redémarrez l'application sur le noeud_A.

   noeud_A# /usr/cluster/bin/scswitch -e -j rs_nfs

7. Resynchronisez le volume secondaire avec le volume principal.

   noeud_A# /usr/opt/SUNWesm/sbin/sndradm -n -u prem_grrép_nhlog \ /dev/vx/rdsk/groupe_périphériques/vol01 \ /dev/vx/rdsk/groupe_périphériques/vol04 sec_grrép_nhlog \ /dev/vx/rdsk/groupe_périphériques/vol01 \ /dev/vx/rdsk/groupe_périphériques/vol04 ip sync

Exemple de vérification de la réussite d'une réplication

Cette rubrique décrit la procédure de confirmation de la configuration de la réplication de l'exemple de configuration.

Procédure de vérification de la réussite d'une réplication

1. Vérifiez que le cluster principal est en mode réplication et que l'autosynchronisation est activée.

   noeud_A# /usr/opt/SUNWesm/sbin/sndradm -P

   Le résultat ressemble à ce qui suit :

   /dev/vx/rdsk/groupe_périphériques/vol01 -> sec_grrép_nhlog:/dev/vx/rdsk/groupe_périphériques/vol01 autosync: on, max q writes:4194304, max q fbas:16384, mode:sync,ctag: groupe_périphériques, state: replicating

   En mode réplication, l'état est replicating et l'état actif de l'autosynchronisation est on. Au cours de l'écriture sur le volume principal, le volume secondaire est mis à jour par le logiciel Sun StorEdge Availability Suite 3.1.

   Si le cluster principal n'est pas en mode réplication, remédiez-y de la façon suivante :

   noeud_A# /usr/opt/SUNWesm/sbin/sndradm -n -u prem_grrép_nhlog \ /dev/vx/rdsk/groupe_périphériques/vol01 \ /dev/vx/rdsk/groupe_périphériques/vol04 sec_grrép_nhlog \ /dev/vx/rdsk/groupe_périphériques/vol01 \ /dev/vx/rdsk/groupe_périphériques/vol04 ip sync

2. Créez un répertoire sur une machine client.

   1. Connectez-vous à la machine client en tant que superutilisateur.

      Une invite similaire à celle-ci s'affiche :

      machine_client#

   2. Créez un répertoire sur la machine client.

      machine_client# mkdir /rép

3. Montez le répertoire de l'application sur le cluster principal, puis affichez-le.

   1. Montez le répertoire de l'application sur le cluster principal.

      machine_client# mount -o rw prem_grnfs_nhlog:/global/point_montage /rép

   2. Affichez-le.

      machine_client# ls /rép

4. Montez le répertoire de l'application sur le cluster secondaire, puis affichez-le.

   1. Démontez le répertoire de l'application sur le cluster principal.

      machine_client# umount /rép

   2. Mettez hors ligne le groupe de ressources d'application sur le cluster principal.

      noeud_A# /usr/cluster/bin/scswitch -n -j rs_nfs noeud_A# /usr/cluster/bin/scswitch -n -j rs_dg_nfs noeud_A# /usr/cluster/bin/scswitch -n -j prin_grnfs_nhlog noeud_A# /usr/cluster/bin/scswitch -z -g gr_nfs -h ""

   3. Mettez le cluster principal en mode journalisation.

      noeud_A# /usr/opt/SUNWesm/sbin/sndradm -n -l prin_grrép_nhlog \ /dev/vx/rdsk/groupe_périphériques/vol01 \ /dev/vx/rdsk/groupe_périphériques/vol04 sec_grrép_nhlog \ /dev/vx/rdsk/groupe_périphériques/vol01 \ /dev/vx/rdsk/groupe_périphériques/vol04 ip sync

      Au cours de l'écriture sur le volume de données du disque, le fichier bitmap figurant sur ce disque est mis à jour. Aucune réplication n'est effectuée.

   4. Mettez en ligne le groupe de ressources d'application sur le cluster secondaire.

      noeud_C# /usr/cluster/bin/scswitch -Z -g gr_nfs

   5. Connectez-vous à la machine client en tant que superutilisateur.

      Une invite similaire à celle-ci s'affiche :

      machine_client#

   6. Montez le répertoire de l'application créé à l'Étape 2 sur le cluster secondaire.

      machine_client# mount -o rw sec_grnfs_nhlog:/global/point_montage /rép

   7. Affichez le répertoire monté.

      machine_client# ls /rép

5. Vérifiez que le répertoire affiché à l'Étape 3 est identique à celui de l'Étape 4.

6. Renvoyez l'application du cluster principal vers le répertoire monté.

   1. Mettez hors ligne le groupe de ressources d'application sur le cluster secondaire.

      noeud_C# /usr/cluster/bin/scswitch -n -j rs_nfs noeud_C# /usr/cluster/bin/scswitch -n -j rs_dg_nfs noeud_C# /usr/cluster/bin/scswitch -n -j sec_grnfs_nhlog noeud_C# /usr/cluster/bin/scswitch -z -g gr_nfs -h ""

   2. Vérifiez que le volume global est démonté sur le cluster secondaire.

      noeud_C# umount /global/point_montage

   3. Mettez en ligne le groupe de ressources d'application sur le cluster principal.

      noeud_A# /usr/cluster/bin/scswitch -Z -g gr_nfs

   4. Mettez le cluster principal en mode réplication.

      noeud_A# /usr/opt/SUNWesm/sbin/sndradm -n -u prin_grrép_nhlog \ /dev/vx/rdsk/groupe_périphériques/vol01 \ /dev/vx/rdsk/groupe_périphériques/vol04 sec_grrép_nhlog \ /dev/vx/rdsk/groupe_périphériques/vol01 \ /dev/vx/rdsk/groupe_périphériques/vol04 ip sync

      Au cours de l'écriture sur le volume principal, le volume secondaire est mis à jour par le logiciel Sun StorEdge Availability Suite 3.1.

Exemple de gestion d'un basculement ou d'une commutation

Cette rubrique décrit la provocation d'un basculement et le transfert d'une aplication sur le cluster secondaire. Après une commutation ou un basculement, vous devez mettre à jour l'entrée DNS et configurer l'application pour qu'elle puisse lire et écrire sur le volume secondaire.

Provocation d'un basculement

1. Mettez le cluster principal en mode journalisation.

   noeud_A# /usr/opt/SUNWesm/sbin/sndradm -n -l prin_grrép_nhlog \ /dev/vx/rdsk/groupe_périphériques/vol01 \ /dev/vx/rdsk/groupe_périphériques/vol04 sec_grrép_nhlog \ /dev/vx/rdsk/groupe_périphériques/vol01 \ /dev/vx/rdsk/groupe_périphériques/vol04 ip sync

   Au cours de l'écriture sur le volume de données du disque, le fichier bitmap figurant sur ce disque est mis à jour. Aucune réplication n'est effectuée.

2. Confirmez que le cluster principal et le cluster secondaire sont en mode journalisation et que l'autosynchronisation est désactivée.

   1. Sur le noeud_A, exécutez la commande suivante :

      noeud_A# /usr/opt/SUNWesm/sbin/sndradm -P

      Le résultat ressemble à ce qui suit :

      /dev/vx/rdsk/groupe_périphériques/vol01 -> sec_grrép_nhlog:/dev/vx/rdsk/groupe_périphériques/vol01 autosync:off, max q writes:4194304,max q fbas:16384,mode:sync,ctag: groupe_périphériques, state: logging

   2. Sur le noeud_C, exécutez la commande suivante :

      noeud_C# /usr/opt/SUNWesm/sbin/sndradm -P

      Le résultat ressemble à ce qui suit :

      /dev/vx/rdsk/groupe_périphériques/vol01 <- prin_grrép_nhlog:/dev/vx/rdsk/groupe_périphériques/vol01 autosync:off, max q writes:4194304,max q fbas:16384,mode:sync,ctag: groupe_périphériques, state: logging

   Pour le noeud_A et le noeud_C, l'état doit être logging et l'état actif de l'autosynchronisation off.

3. Confirmez que le cluster secondaire est prêt à prendre la relève du cluster principal.

   noeud_C# /usr/sbin/fsck -y /dev/vx/rdsk/groupe_périphériques/vol01

4. Effectuez la commutation sur le cluster secondaire.

   noeud_C# scswitch -Z -g gr_nfs noeud_C# scswitch -Z -g gr_nfs -h noeud_C

Procédure de mise à jour de l'entrée DNS

Pour visualiser une illustration du mappage du DNS d'un client à un cluster, reportez-vous à la Figure 6–6.

1. Exécutez la commande nsupdate.

   Pour de plus amples informations, consultez la page de manuel nsupdate(1M).

2. Supprimez le mappage du DNS actif entre la machine client et le nom d'hôte logique du groupe de ressources d'application sur le cluster principal.

   > update delete machine_client A > update delete AddresseIP_1.in-addr.arpa TTL PTR machine_client

   machine_client

   Nom complet du client. Par exemple : mymachine.mycompany.com.

   adresseIP_1

   Adresse IP du nom d'hôte logique prin_grnfs_nhlog, à l'envers.

   TTL

   Durée de vie, en secondes. 3600 est la valeur courante.

3. Créez le nouveau mappage du DNS entre la machine client et le nom d'hôte logique du groupe de ressources d'application sur le cluster secondaire.

   > update add machine_client TTL A AdresseIP_2 > update add AdresseIP_3.in-addr.arpa TTL PTR machine_client

   AdresseIP_2

   Adresse IP du nom d'hôte logique sec_grnfs_nhlog, dans l'ordre normal.

   AdresseIP_3

   Adresse IP du nom d'hôte logique sec_grnfs_nhlog, à l'envers.

Procédure de configuration de l'application pour qu'elle puisse lire et écrire sur le volume secondaire

1. Configurez le volume secondaire à monter sur le point de montage du système de fichiers NFS.

   machine_client# mount -o rw sec_grnfs_nhlog:/global/point_montage /xxx

   Le point de montage a été créé à l'Étape 1 de la Procédure de configuration du système de fichiers sur le cluster principal d'une application NFS.

2. Confirmez que le cluster secondaire a accès en écriture au point de montage.

   machine_client# touch /xxx/data.1 machine_client# umount /xxx