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

Le présent chapitre vous explique comment configurer la réplication des données entre les clusters grâce au logiciel Sun StorEdge Availability Suite version 3.1 ou 3.2.

Il contient également un exemple de configuration de la réplication des données pour une application NFS à l'aide du logiciel Sun StorEdge Availability Suite. 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 se compose des sections suivantes :

• Introduction à la réplication des données

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

• Liste des tâches : exemple de configuration de réplication des données

• Connexion et installation des clusters

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

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

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

• Exemple de commutation et de gestion d'un basculement

Introduction à la réplication des données

La présente section définit la tolérance de sinistre et décrit les méthodes de réplication des données que le logiciel Sun StorEdge Availability Suite utilise.

Définition de la tolérance de sinistre

On appelle "tolérance de sinistre" 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 des données et le basculement.

Lorsque l'on réplique des données, on les copie du cluster principal vers un cluster secondaire ou de sauvegarde. La réplication des 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 est le déplacement d'un groupe de ressources ou de périphériques d'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 des données utilisées par le logiciel Sun StorEdge Availability Suite

La présente section décrit deux méthodes utilisées par le logiciel Sun StorEdge Availability Suite : la réplication distante et l'instantané ponctuel. Ce logiciel utilise les commandes sndradm(1RPC) et iiadm(1II) pour répliquer les données. Pour obtenir de plus amples informations sur ces commandes, consultez l'un des manuels suivants :

• Logiciel Sun StorEdge Availability Suite version 3.1 : Sun Cluster 3.0 and Sun StorEdge Software Integration Guide

• Logiciel Sun StorEdge Availability Suite version 3.2 : Sun Cluster 3.0/3.1 and Sun StorEdge Availability Suite 3.2 Software Integration Guide

Réplication distante

Le principe de réplication distante est illustré dans la Figure 6–1. Les données du volume maître du disque principal sont répliquées sur celui du disque secondaire via une connexion TCP/IP. Un bitmap distant identifie les 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 manière synchrone, en temps réel, ou de façon asynchrone. Sur chaque cluster, chaque ensemble de volumes peut être configuré individuellement en choisissant une réplication synchrone ou asynchrone.

• Lors de la réplication synchrone des données, l'achèvement d'une opération d'écriture n'est confirmé que lorsque le volume distant a été mis à jour.

• Lors de la réplication asynchrone des données, l'achèvement d'une opération d'écriture est confirmé avant la mise à jour du volume distant. La réplication asynchrone des données fournit une plus grande flexibilité sur de longues distances et avec une faible bande passante.

Instantané ponctuel

Le principe de l'instantané ponctel 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 identifie les 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 des méthodes de réplication distante et d'instantané ponctuel dans une configuration donnée à titre d'exemple.

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

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

Le présente section vous explique comment configurer la réplication des données entre les 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 sujets suivants :

• 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 colocalisent le groupe de périphériques sous le contrôle du logiciel Sun StorEdge Availability Suite via la ressource 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 nœud à la fois. En cas de basculement, les ressources de basculement interviennent.

• Comporter 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, il doit être hébergé par le cluster secondaire. Pour associer un nom d'hôte logique à un cluster, l'on utilise le DNS (Domain Name System, système de noms de domaines).

• Disposer d'une ressource HAStoragePlus

  La ressource HAStoragePlus assure la commutation du groupe de périphériques en cas de basculement ou de commutation du groupe de ressources de réplication. Sun Cluster assure é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 nœud ou contrôlés par le même nœud.

  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 = 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 obtenir 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ériques-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

Une application de basculement consiste en une application exécutée sur un seul nœud à la fois. En cas d'échec sur ce nœud, l'application bascule sur un autre nœud 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 qui assure 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 provoque celle 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 nœud.

  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 d'application sont montées globalement, la présence d'une ressource HAStoragePlus dans le groupe de ressources d'application n'est pas nécessaire ; elle est seulement conseillée.

  • Par contre, si les données d'application sont montées localement, la présence d'une ressource HAStoragePlus dans le groupe de ressources d'application est nécessaire.

    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 seront donc plus contrôlés par le même nœud.

  Pour obtenir 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 des groupes de ressources dans une application de basculement

Configuration des groupes de ressources pour une application évolutive

Une application évolutive consiste en une application qui s'exécute sur plusieurs nœuds afin de créer un seul service logique. En cas d'échec d'un nœud exécutant une application évolutive, le basculement ne se produit pas. L'application continue de s'exécuter sur d'autres nœuds.

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'adresses partagées

  Les nœuds qui exécutent 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 des groupes de ressources dans une application évolutive

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

Si le cluster principal échoue, l'application doit être basculée sur le cluster secondaire aussi rapidement que possible. Pour que le cluster secondaire prenne la relève, le DNS doit être mis à jour.

Le DNS associe 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 manière dont le DNS associe 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 obtenir de plus amples informations, reportez-vous à la page de manuel nsupdate(1M). Pour en savoir plus sur la gestion d'un basculement ou d'une commutation, reportez-vous à la section Exemple de commutation et de gestion d'un basculement .

Une fois réparé, le cluster principal peut être remis en ligne. Pour le remettre en ligne, 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.

Liste des tâches : exemple de configuration de réplication des données

La liste suivante répertorie les tâches de cet exemple de configuration de la réplication des données pour une application NFS, à l'aide du logiciel Sun StorEdge Availability Suite.

Tableau 6–1 Liste des tâches : Exemple de configuration de la réplication des données

Tâche	Instructions
1. Connectez et installez les clusters.	Connexion et installation des clusters
2. Configurez les groupes de périphériques de disques, les systèmes de fichiers de l'application NFS et les groupes de ressources sur les clusters principal et secondaire.	Exemple de configuration des groupes de périphériques et des groupes de ressources
3. Activez la réplication des données sur les clusters principal et 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
4. Effectuez la réplication des données.	Procédure de réplication distante Procédure d'instantané ponctuel
5. Vérifiez la configuration de la réplication des données.	Procédure de vérification de la réussite d'une réplication

Connexion et installation des clusters

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

Figure 6–7 Exemple de configuration de cluster

Le Tableau 6–2 répertorie les logiciels et le matériel requis par l'exemple de configuration. Le système d'exploitation Solaris, le logiciel Sun Cluster et le gestionnaire de volumes doivent être installés sur les nœuds de cluster avant que vous ne procédiez à l'installation du logiciel et des patchs Sun StorEdge Availability Suite.

Tableau 6–2 Matériel et logiciels requis

Matériel ou logiciels	Conditions requises
Matériel du nœud	Le logiciel Sun StorEdge Availability Suite est pris en charge par tous les serveurs qui exécutent le système d'exploitation Solaris.  Pour obtenir de plus amples informations sur le matériel requis, reportez-vous au document Sun Cluster 3.0-3.1 Hardware Administration Manual for Solaris OS
Espace disque	Environ 15 Mo.
Système d'exploitation Solaris	Toute version du système d'exploitation Solaris prise en charge par le logiciel Sun Cluster.  Tous les nœuds doivent utiliser la même version de Solaris.  Pour obtenir de plus amples informations sur l'installation, reportez-vous à la section Installation du logiciel .
Logiciel Sun Cluster	Logiciel Sun Cluster 3.1 8/05.  Pour obtenir de plus amples informations sur l'installation, reportez-vous au Chapitre 2, Installation et configuration du logiciel Sun Cluster
Gestionnaire de volumes	Logiciel Solstice DiskSuite ou Solaris Volume Manager ou VERITAS Volume Manager (VxVM).  Tous les nœuds doivent utiliser la même version de gestionnaire de volumes.  Pour obtenir de plus amples informations sur l'installation, reportez-vous aux sections Installation et configuration du logiciel Solstice DiskSuite ou Solaris Volume Manager et SPARC : Installation et configuration du logiciel VxVM .
Logiciel Sun StorEdge Availability Suite	Pour obtenir de plus amples informations sur l'installation du logiciel Sun StorEdge Availability Suite, reportez-vous aux manuels correspondant à votre version :  Sun StorEdge Availability Suite version 3.1 : 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 Sun StorEdge Availability Suite version 3.2 : Sun StorEdge Availability Suite 3.2 Software Installation Guide
Patchs du logiciel Sun StorEdge Availability Suite	Pour obtenir de plus amples informations sur les derniers patchs, visitez le site http://www.sunsolve.com.

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

Le présente section décrit la configuration des groupes de périphériques de disques et des groupes de ressources pour une application NFS. Pour obtenir de plus amples informations, reportez-vous aux sections Configuration des groupes de ressources de réplication et Configuration des groupes de ressources d'application.

Cette section explique les procédures 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

• Création d'un groupe de ressources d'application NFS sur le cluster principal

• Création d'un groupe de ressources d'application NFS sur le cluster secondaire

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

Le tableau suivant répertorie les noms groupes et des ressources créés pour l'exemple de configuration.

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

Groupe ou ressource	Nom	Description
Groupe de périphériques de disques	groupe_périphériques	Groupe de périphériques de disques
Groupe de ressources et ressources de réplication	groupe_périphériques-stor-rg	Groupe de 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 les clusters principal et secondaire
	groupe_périphériques_stor	Ressource HAStoragePlus pour le 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 les clusters principal et secondaire
	rs_dg_nfs	Ressource HAStoragePlus pour 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 groupe de ressources de réplication doit avoir un nom respectant le format devicegroup-stor-rg .

Cet exemple de configuration utilise le logiciel VxVM. Pour obtenir de plus amples informations sur le logiciel Solstice DiskSuite ou Solaris Volume Manager, reportez-vous au Chapitre 3, Installation et configuration du logiciel Solstice DiskSuite ou Solaris Volume Manager .

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 procédure ne doivent contenir aucune zone privée de label de disque, comme le cylindre 0. Le logiciel VxVM gère automatiquement cette contrainte.

---

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

Avant de commencer

Vérifiez que les tâches suivantes ont bien été effectuées.

• Lire les instructions et conditions préalables des sections suivantes :

  • Introduction à la réplication des données

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

• Configurer les clusters principal et secondaire selon la procédure décrite à la section Connexion et installation des clusters .

Étapes

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

   Le nodeA est le premier nœud du cluster principal. Pour savoir quel nœud est considéré comme nodeA, reportez-vous à la Figure 6–7.

2. Créez un groupe de disques sur le nodeA. Ce groupe contiendra quatre volumes, du volume 1 (vol01) au volume 4 (vol04).

   Pour obtenir de plus amples informations sur la configuration d'un groupe de disques à l'aide du logiciel VxVM, reportez-vous au Chapitre 4, SPARC : Installation et configuration de VERITAS Volume Manager.

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

   nodeA# /usr/cluster/bin/scconf -a \ -D type=vxvm,name=devicegroup,nodelist=nodeA:nodeB

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

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

   nodeA# /usr/sbin/newfs /dev/vx/rdsk/devicegroup/vol01 < /dev/null nodeA# /usr/sbin/newfs /dev/vx/rdsk/devicegroup/vol02 < /dev/null

   Aucun système de fichiers n'est requis pour vol03 ni vol04, qui sont utilisés comme des volumes bruts.

Étapes suivantes

Passez à la section Procédure de configuration d'un groupe de périphériques de disques sur le cluster secondaire.

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

Avant de commencer

Vérifiez que vous avez bien suivi la procédure de la section Procédure de configuration d'un groupe de périphériques de disques sur le cluster principal.

Étapes

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

2. Créez un groupe de disques sur le nodeC. Ce groupe contiendra quatre volumes, du volume 1 (vol01) au volume 4 (vol04).

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

   nodeC# /usr/cluster/bin/scconf -a \ -D type=vxvm,name=devicegroup,nodelist=nodeC

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

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

   nodeC# /usr/sbin/newfs /dev/vx/rdsk/devicegroup/vol01 < /dev/null nodeC# /usr/sbin/newfs /dev/vx/rdsk/devicegroup/vol02 < /dev/null

   Aucun système de fichiers n'est requis pour vol03 ni vol04, qui sont utilisés comme des volumes bruts.

Étapes suivantes

Passez à la section 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 principal d'une application NFS

Avant de commencer

Vérifiez que vous avez bien suivi la procédure de la section Procédure de configuration d'un groupe de périphériques de disques sur le cluster secondaire.

Étapes

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

   Exemple :

   nodeA# mkdir /global/mountpoint

2. Sur le nodeA et le nodeB, 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 nodeA et le nodeB. Le texte doit tenir sur une seule ligne.

   /dev/vx/dsk/devicegroup/vol01 /dev/vx/rdsk/devicegroup/vol01 \ /global/mountpoint ufs 3 no global,logging

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

3. Sur le nodeA, créez un volume pour les informations du système de fichiers utilisé par le service de données Sun Cluster HA pour NFS.

   nodeA# /usr/sbin/vxassist -g devicegroup make vol05 120m disk1

   Le volume 5 (vol05) contient les informations du système de fichiers utilisé par le service de données Sun Cluster HA pour NFS.

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

   nodeA# /usr/cluster/bin/scconf -c -D name=devicegroup,sync

5. Sur le nodeA, créez un système de fichiers pour le vol05.

   nodeA# /usr/sbin/newfs /dev/vx/rdsk/devicegroup/vol05

6. Sur le nodeA et le nodeB, créez un point de montage pour le vol05.

   Exemple :

   nodeA# mkdir /global/etc

7. Sur le nodeA et le nodeB, configurez le vol05 pour qu'il soit automatiquement monté sur le point de montage.

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

   /dev/vx/dsk/devicegroup/vol05 /dev/vx/rdsk/devicegroup/vol05 \ /global/etc ufs 3 yes global,logging

8. Montez le vol05 sur le nodeA.

   nodeA# mount /global/etc

9. Faites en sorte que le vol05 soit accessible depuis un système distant.

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

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

   2. Créez le fichier /global/etc/SUNW.nfs/dfstab.nfs-rs sur le nodeA.

      nodeA# touch /global/etc/SUNW.nfs/dfstab.nfs-rs

   3. Ajoutez la ligne suivante dans le fichier /global/etc/SUNW.nfs/dfstab.nfs-rs du nodeA :

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

Étapes suivantes

Passez à la section Procédure de configuration du système de fichiers sur le cluster secondaire d'une application NFS.

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

Avant de commencer

Vérifiez que vous avez bien suivi la procédure de la section Procédure de configuration du système de fichiers sur le cluster principal d'une application NFS .

Étapes

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

   Exemple :

   nodeC# mkdir /global/mountpoint

2. Sur le nodeC, configurez le volume maître pour qu'il soit automatiquement monté sur le point de montage.

   Sur le fichier /etc/vfstab du nodeC, ajoutez le texte suivant (ou écrivez-le à la place du texte existant). Le texte doit tenir sur une seule ligne.

   /dev/vx/dsk/devicegroup/vol01 /dev/vx/rdsk/devicegroup/vol01 \ /global/mountpoint ufs 3 no global,logging

3. Sur le nodeC, créez un volume pour les informations du système de fichiers utilisé par le service de données Sun Cluster HA pour NFS.

   nodeC# /usr/sbin/vxassist -g devicegroup make vol05 120m disk1

   Le volume 5 (vol05) contient les informations du système de fichiers utilisé par le service de données Sun Cluster HA pour NFS.

4. Sur le nodeC, synchronisez une nouvelle fois le groupe de périphériques à l'aide du logiciel Sun Cluster.

   nodeC# /usr/cluster/bin/scconf -c -D name=devicegroup,sync

5. Sur le nodeC, créez le système de fichiers du vol05.

   nodeC# /usr/sbin/newfs /dev/vx/rdsk/devicegroup/vol05

6. Sur le nodeC, créez un point de montage pour le vol05.

   Exemple :

   nodeC# mkdir /global/etc

7. Sur le nodeC, configurez le vol05 pour qu'il soit automatiquement monté sur le point de montage.

   Sur le fichier /etc/vfstab du nodeC, ajoutez le texte suivant (ou écrivez-le à la place du texte existant). Le texte doit tenir sur une seule ligne.

   /dev/vx/dsk/devicegroup/vol05 /dev/vx/rdsk/devicegroup/vol05 \ /global/etc ufs 3 yes global,logging

8. Montez le vol05 sur le nodeC.

   nodeC# mount /global/etc

9. Faites en sorte que le vol05 soit accessible depuis un système distant.

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

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

   2. Créez le fichier /global/etc/SUNW.nfs/dfstab.nfs-rs sur le nodeC.

      nodeC# touch /global/etc/SUNW.nfs/dfstab.nfs-rs

   3. Ajoutez la ligne suivante dans le fichier /global/etc/SUNW.nfs/dfstab.nfs-rs du nodeC :

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

Étapes suivantes

Passez à la section 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 principal

Avant de commencer

Vérifiez que vous avez bien suivi la procédure de la section Procédure de configuration du système de fichiers sur le cluster secondaire d'une application NFS.

Étapes

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

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

   nodeA# /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.

   nodeA# /usr/cluster/bin/scrgadm -a -g devicegroup-stor-rg -h nodeA,nodeB

   devicegroup

   Nom du groupe de périphériques de disques

   devicegroup-stor-rg

   Nom du groupe de ressources de réplication

   -h nodeA, nodeB

   Spécifie les nœuds de cluster qui peuvent gérer le groupe de ressources de réplication

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

   nodeA# /usr/cluster/bin/scrgadm -a -j devicegroup-stor \ -g devicegroup-stor-rg -t SUNW.HAStoragePlus \ -x GlobalDevicePaths=devicegroup \ -x AffinityOn=True

   devicegroup-stor

   Ressource HAStoragePlus du groupe de ressources de réplication.

   -x GlobalDevicePaths=

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

   -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 obtenir de plus amples informations sur ces 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.

   nodeA# /usr/cluster/bin/scrgadm -a -L -j lhost-reprg-prim \ -g devicegroup-stor-rg -l lhost-reprg-prim

   lhost-reprg-prim est le nom d'hôte logique du groupe de ressources de réplication sur le cluster principal.

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

   nodeA# /usr/cluster/bin/scswitch -Z -g devicegroup-stor-rg nodeA# /usr/cluster/bin/scswitch -z -g devicegroup-stor-rg -h nodeA

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

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

   Examinez la zone d'état du groupe de ressources pour vérifier que le groupe de ressources de réplication est en ligne sur le nodeA.

Étapes suivantes

Passez à la section 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 de réplication sur le cluster secondaire

Avant de commencer

Vérifiez que vous avez suivi la procédure de la section Procédure de création d'un groupe de ressources de réplication sur le cluster principal .

Étapes

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

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

   nodeC# /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.

   nodeC# /usr/cluster/bin/scrgadm -a -g devicegroup-stor-rg -h nodeC

   devicegroup

   Nom du groupe de périphériques de disques

   devicegroup-stor-rg

   Nom du groupe de ressources de réplication

   -h nodeC

   Désigne le nœud de cluster qui peut gérer le groupe de ressources de réplication

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

   nodeC# /usr/cluster/bin/scrgadm -a -j devicegroup-stor \ -g devicegroup-stor-rg -t SUNW.HAStoragePlus \ -x GlobalDevicePaths=devicegroup \ -x AffinityOn=True

   devicegroup-stor

   Ressource HAStoragePlus du groupe de ressources de réplication.

   -x GlobalDevicePaths=

   Indique la propriété d'extension sur laquelle s'appuie le logiciel Sun StorEdge Availability Suite.

   -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 obtenir de plus amples informations sur ces 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.

   nodeC# /usr/cluster/bin/scrgadm -a -L -j lhost-reprg-sec \ -g devicegroup-stor-rg -l lhost-reprg-sec

   lhost-reprg-sec est le nom d'hôte logique du groupe de ressources de réplication sur le cluster principal.

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

   nodeC# /usr/cluster/bin/scswitch -Z -g devicegroup-stor-rg

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

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

   Examinez la zone d'état du groupe de ressources pour vérifier que le groupe de ressources de réplication est en ligne sur le nodeC.

Étapes suivantes

Passez à la section Création d'un groupe de ressources d'application NFS sur le cluster principal .

Création d'un groupe de ressources d'application NFS sur le cluster principal

Cette section décrit la procédure de création des groupes de ressources d'application pour NFS. Cette procédure ne concerne que cette application.

Avant de commencer

Vérifiez que vous avez bien respecté la procédure de la section Procédure de création d'un groupe de ressources de réplication sur le cluster secondaire.

Étapes

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

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

   nodeA# scrgadm -a -t SUNW.nfs

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

   nodeA# scrgadm -a -t SUNW.HAStoragePlus

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

   nodeA# scrgadm -a -g nfs-rg \ -y Pathprefix=/global/etc \ -y Auto_start_on_new_cluster=False \ -y RG_dependencies=devicegroup-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=devicegroup-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 nœud 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 nœud principal, le groupe de ressources d'application doit être commuté manuellement.

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

   nodeA# scrgadm -a -j nfs-dg-rs -g nfs-rg \ -t SUNW.HAStoragePlus \ -x FileSystemMountPoints=/global/mountpoint \ -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 obtenir de plus amples informations sur ces 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.

   nodeA# /usr/cluster/bin/scrgadm -a -L -j lhost-nfsrg-prim -g nfs-rg \ -l lhost-nfsrg-prim

   lhost-nfsrg-prim est le 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.

      nodeA# /usr/cluster/bin/scrgadm -a -g nfs-rg \ -j nfs-rs -t SUNW.nfs -y Resource_dependencies=nfs-dg-rs

   2. Mettez le groupe de ressources d'application en ligne sur le nœud_A.

      nodeA# /usr/cluster/bin/scswitch -Z -g nfs-rg nodeA# /usr/cluster/bin/scswitch -z -g nfs-rg -h nodeA

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

   nodeA# /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 nodeA et le nodeB.

Étapes suivantes

Passez à la section Création d'un groupe de ressources d'application NFS sur le cluster secondaire.

Création d'un groupe de ressources d'application NFS sur le cluster secondaire

Avant de commencer

Vérifiez que vous avez bien respecté la procédure de la section Création d'un groupe de ressources d'application NFS sur le cluster principal .

Étapes

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

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

   nodeC# scrgadm -a -t SUNW.nfs

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

   nodeC# scrgadm -a -t SUNW.HAStoragePlus

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

   nodeC# scrgadm -a -g nfs-rg \ -y Pathprefix=/global/etc \ -y Auto_start_on_new_cluster=False \ -y RG_dependencies=devicegroup-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=devicegroup-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 nœud 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 nœud principal, le groupe de ressources d'application doit être commuté manuellement.

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

   nodeC# scrgadm -a -j nfs-dg-rs -g nfs-rg \ -t SUNW.HAStoragePlus \ -x FileSystemMountPoints=/global/mountpoint \ -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 obtenir de plus amples informations sur ces 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.

   nodeC# /usr/cluster/bin/scrgadm -a -L -j lhost-nfsrg-sec -g nfs-rg \ -l lhost-nfsrg-sec

   lhost-nfsrg-sec est le nom d'hôte logique du groupe de ressources d'application sur le cluster secondaire.

7. Ajoutez une ressource NFS au groupe de ressources d'application.

   nodeC# /usr/cluster/bin/scrgadm -a -g nfs-rg \ -j nfs-rs -t SUNW.nfs -y Resource_dependencies=nfs-dg-rs

8. Vérifiez que le groupe de ressources d'application n'est pas en ligne sur le nœud_C.

   nodeC# /usr/cluster/bin/scswitch -n -j nfs-rs nodeC# /usr/cluster/bin/scswitch -n -j nfs-dg-rs nodeC# /usr/cluster/bin/scswitch -n -j lhost-nfsrg-sec nodeC# /usr/cluster/bin/scswitch -z -g nfs-rg -h ""

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

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

   nodeC# umount /global/mountpoint

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

Étapes suivantes

Passez à la section Exemple d'activation de la réplication de données

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

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

Cette section explique les procédures suivantes:

• 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 d'activation de la réplication sur le cluster principal

Étapes

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

2. Supprimez toutes les transactions.

   nodeA# /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.

   nodeA# /usr/cluster/bin/scstat -g nodeC# /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 vise à activer la réplication des données du volume maître du cluster principal sur le volume maître du cluster secondaire, ainsi que vers le bitmap distant situé sur le vol04.

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

     nodeA# /usr/opt/SUNWesm/sbin/sndradm -n -e lhost-reprg-prim \ /dev/vx/rdsk/devicegroup/vol01 \ /dev/vx/rdsk/devicegroup/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devicegroup/vol01 \ /dev/vx/rdsk/devicegroup/vol04 ip sync

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

     nodeA# /usr/opt/SUNWesm/sbin/sndradm -n -E lhost-reprg-prim \ /dev/vx/rdsk/devicegroup/vol01 \ /dev/vx/rdsk/devicegroup/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devicegroup/vol01 \ /dev/vx/rdsk/devicegroup/vol04 ip sync

5. Activez l'autosynchronisation.

   nodeA# /usr/opt/SUNWesm/sbin/sndradm -n -a on lhost-reprg-prim \ /dev/vx/rdsk/devicegroup/vol01 \ /dev/vx/rdsk/devicegroup/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devicegroup/vol01 \ /dev/vx/rdsk/devicegroup/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.

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

   La sortie résultante doit se présenter comme suit :

   /dev/vx/rdsk/devicegroup/vol01 -> lhost-reprg-sec:/dev/vx/rdsk/devicegroup/vol01 autosync: off, max q writes:4194304, max q fbas:16384, mode:sync,ctag: devicegroup, 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.

   nodeA# /usr/opt/SUNWesm/sbin/iiadm -e ind \ /dev/vx/rdsk/devicegroup/vol01 \ /dev/vx/rdsk/devicegroup/vol02 \ /dev/vx/rdsk/devicegroup/vol03 nodeA# /usr/opt/SUNWesm/sbin/iiadm -w \ /dev/vx/rdsk/devicegroup/vol02

   Cette étape active la copie du volume maître du cluster principal sur le volume en double du même cluster. Le volume maître, le volume en double et le volume du bitmap ponctuel doivent se trouver dans le même groupe de périphériques. Dans cet exemple, le volume maître est vol01 ; le volume en double, vol02 et celui du bitmap ponctuel, vol03.

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

   nodeA# /usr/opt/SUNWesm/sbin/sndradm -I a \ /dev/vx/rdsk/devicegroup/vol01 \ /dev/vx/rdsk/devicegroup/vol02 \ /dev/vx/rdsk/devicegroup/vol03

   Cette étape associe l'instantané ponctuel au jeu de miroirs distants. Le logicel Sun StorEdge Availability Suite prend un instantané ponctuel avant le début de la réplication distante.

Étapes suivantes

Passez à la section Procédure d'activation de la réplication sur le cluster secondaire.

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

Avant de commencer

Vérifiez que vous avez bien respecté la procédure de la section Procédure d'activation de la réplication sur le cluster principal.

Étapes

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

2. Supprimez toutes les transactions.

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

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

   nodeC# /usr/opt/SUNWesm/sbin/sndradm -n -e lhost-reprg-prim \ /dev/vx/rdsk/devicegroup/vol01 \ /dev/vx/rdsk/devicegroup/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devicegroup/vol01 \ /dev/vx/rdsk/devicegroup/vol04 ip sync

   Le cluster principal détecte la présence du cluster secondaire et démarre la synchronisation. Pour obtenir des informations sur le statut des clusters, ouvrez le fichier journal système /var/opt/SUNWesm/ds.log.

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

   nodeC# /usr/opt/SUNWesm/sbin/iiadm -e ind \ /dev/vx/rdsk/devicegroup/vol01 \ /dev/vx/rdsk/devicegroup/vol02 \ /dev/vx/rdsk/devicegroup/vol03 nodeC# /usr/opt/SUNWesm/sbin/iiadm -w \ /dev/vx/rdsk/devicegroup/vol02

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

   nodeC# /usr/opt/SUNWesm/sbin/sndradm -I a \ /dev/vx/rdsk/devicegroup/vol01 \ /dev/vx/rdsk/devicegroup/vol02 \ /dev/vx/rdsk/devicegroup/vol03

Étapes suivantes

Passez à la section Exemple de procédure de réplication des données .

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

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

Cette section explique les procédures suivantes:

• Procédure de réplication distante

• Procédure d'instantané ponctuel

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

Procédure de réplication distante

Cette procédure permet de répliquer le volume maître du disque principal sur celui du disque secondaire. Le volume maître est vol01 et celui du bitmap distant, vol04.

Étapes

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

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

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

   La sortie résultante doit se présenter comme suit :

   /dev/vx/rdsk/devicegroup/vol01 -> lhost-reprg-sec:/dev/vx/rdsk/devicegroup/vol01 autosync: off, max q writes:4194304, max q fbas:16384, mode:sync,ctag: devicegroup, 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.

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

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

5. Copiez le volume maître du nœud_A sur le volume maître du nœud_C.

   nodeA# /usr/opt/SUNWesm/sbin/sndradm -n -m lhost-reprg-prim \ /dev/vx/rdsk/devicegroup/vol01 \ /dev/vx/rdsk/devicegroup/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devicegroup/vol01 \ /dev/vx/rdsk/devicegroup/vol04 ip sync

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

   nodeA# /usr/opt/SUNWesm/sbin/sndradm -n -w lhost-reprg-prim \ /dev/vx/rdsk/devicegroup/vol01 \ /dev/vx/rdsk/devicegroup/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devicegroup/vol01 \ /dev/vx/rdsk/devicegroup/vol04 ip sync

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

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

   La sortie résultante doit se présenter comme suit :

   /dev/vx/rdsk/devicegroup/vol01 -> lhost-reprg-sec:/dev/vx/rdsk/devicegroup/vol01 autosync: on, max q writes:4194304, max q fbas:16384, mode:sync,ctag: devicegroup, state: replicating

   En mode Réplication, l'état est replicating et l'état actif de l'autosynchronisation est on. Lorsqu'une opération d'écriture est effectuée sur le volume principal, le volume secondaire est mis à jour par le logiciel Sun StorEdge Availability Suite.

Étapes suivantes

Passez à la section Procédure d'instantané ponctuel .

Procédure d'instantané ponctuel

Dans cette procédure, l'instantané ponctuel est utilisé pour synchroniser le volume en double avec le volume maître, sur le cluster principal. Le volume maître est vol01 ; celui du bitmap, vol04 ; le volume en double, vol02.

Avant de commencer

Vérifiez que vous avez bien respecté la procédure de la section Procédure de réplication distante .

Étapes

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

2. Désactivez la ressource qui s'exécute sur le nodeA.

   nodeA# /usr/cluster/bin/scswitch -n -j nfs-rs

3. Mettez le cluster principal en mode Journalisation.

   nodeA# /usr/opt/SUNWesm/sbin/sndradm -n -l lhost-reprg-prim \ /dev/vx/rdsk/devicegroup/vol01 \ /dev/vx/rdsk/devicegroup/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devicegroup/vol01 \ /dev/vx/rdsk/devicegroup/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.

   nodeA# /usr/opt/SUNWesm/sbin/iiadm -u s /dev/vx/rdsk/devicegroup/vol02 nodeA# /usr/opt/SUNWesm/sbin/iiadm -w /dev/vx/rdsk/devicegroup/vol02

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

   nodeC# /usr/opt/SUNWesm/sbin/iiadm -u s /dev/vx/rdsk/devicegroup/vol02 nodeC# /usr/opt/SUNWesm/sbin/iiadm -w /dev/vx/rdsk/devicegroup/vol02

6. Redémarrez l'application sur le nœud_A.

   nodeA# /usr/cluster/bin/scswitch -e -j nfs-rs

7. Resynchronisez le volume secondaire avec le volume principal.

   nodeA# /usr/opt/SUNWesm/sbin/sndradm -n -u lhost-reprg-prim \ /dev/vx/rdsk/devicegroup/vol01 \ /dev/vx/rdsk/devicegroup/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devicegroup/vol01 \ /dev/vx/rdsk/devicegroup/vol04 ip sync

Étapes suivantes

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

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

Avant de commencer

Vérifiez que vous avez bien respecté la procédure de la section Procédure d'instantané ponctuel .

Étapes

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

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

   La sortie résultante doit se présenter comme suit :

   /dev/vx/rdsk/devicegroup/vol01 -> lhost-reprg-sec:/dev/vx/rdsk/devicegroup/vol01 autosync: on, max q writes:4194304, max q fbas:16384, mode:sync,ctag: devicegroup, state: replicating

   En mode Réplication, l'état est replicating et l'état actif de l'autosynchronisation est on. Lorsqu'une opération d'écriture est effectuée sur le volume principal, le volume secondaire est mis à jour par le logiciel Sun StorEdge Availability Suite.

2. Si le cluster principal n'est pas en mode Réplication, activez ce mode.

   nodeA# /usr/opt/SUNWesm/sbin/sndradm -n -u lhost-reprg-prim \ /dev/vx/rdsk/devicegroup/vol01 \ /dev/vx/rdsk/devicegroup/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devicegroup/vol01 \ /dev/vx/rdsk/devicegroup/vol04 ip sync

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

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

      L'invite qui apparaît ressemble à celle-ci :

      client-machine#

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

      client-machine# mkdir /dir

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

      client-machine# mount -o rw lhost-nfsrg-prim:/global/mountpoint /dir

   2. Affichez-le.

      client-machine# ls /dir

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

      client-machine# umount /dir

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

      nodeA# /usr/cluster/bin/scswitch -n -j nfs-rs nodeA# /usr/cluster/bin/scswitch -n -j nfs-dg-rs nodeA# /usr/cluster/bin/scswitch -n -j lhost-nfsrg-prim nodeA# /usr/cluster/bin/scswitch -z -g nfs-rg -h ""

   3. Mettez le cluster principal en mode Journalisation.

      nodeA# /usr/opt/SUNWesm/sbin/sndradm -n -l lhost-reprg-prim \ /dev/vx/rdsk/devicegroup/vol01 \ /dev/vx/rdsk/devicegroup/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devicegroup/vol01 \ /dev/vx/rdsk/devicegroup/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. Vérifiez que le répertoire PathPrefix est disponible.

      nodeC# mount | grep /global/etc

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

      nodeC# /usr/cluster/bin/scswitch -Z -g nfs-rg

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

      L'invite qui apparaît ressemble à celle-ci :

      client-machine#

   7. Montez le répertoire créé à l'Étape 3 sur l'application du cluster secondaire.

      client-machine# mount -o rw lhost-nfsrg-sec:/global/mountpoint /dir

   8. Affichez-le.

      client-machine# ls /dir

6. Assurez-vous que le répertoire affiché à l'Étape 4 correspond bien à celui qui apparaît à l'Étape 5.

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

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

      nodeC# /usr/cluster/bin/scswitch -n -j nfs-rs nodeC# /usr/cluster/bin/scswitch -n -j nfs-dg-rs nodeC# /usr/cluster/bin/scswitch -n -j lhost-nfsrg-sec nodeC# /usr/cluster/bin/scswitch -z -g nfs-rg -h ""

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

      nodeC# umount /global/mountpoint

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

      nodeA# /usr/cluster/bin/scswitch -Z -g nfs-rg

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

      nodeA# /usr/opt/SUNWesm/sbin/sndradm -n -u lhost-reprg-prim \ /dev/vx/rdsk/devicegroup/vol01 \ /dev/vx/rdsk/devicegroup/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devicegroup/vol01 \ /dev/vx/rdsk/devicegroup/vol04 ip sync

      Lorsqu'une opération d'écriture est effectuée sur le volume principal, le volume secondaire est mis à jour par le logiciel Sun StorEdge Availability Suite.

Voir aussi

Exemple de commutation et de gestion d'un basculement

Exemple de commutation et de gestion d'un basculement

Cette section explique comment provoquer une commutation et décrit le transfert de l'application sur le cluster secondaire. Après une commutation ou un basculement, mettez à jour les entrées du DNS. Pour obtenir de plus amples informations, reportez-vous à la section Instructions de gestion d'un basculement ou d'une commutation.

Cette section explique les procédures suivantes:

• Provocation d'un basculement

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

Provocation d'un basculement

Étapes

1. Mettez le cluster principal en mode Journalisation.

   nodeA# /usr/opt/SUNWesm/sbin/sndradm -n -l lhost-reprg-prim \ /dev/vx/rdsk/devicegroup/vol01 \ /dev/vx/rdsk/devicegroup/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devicegroup/vol01 \ /dev/vx/rdsk/devicegroup/vol04 ip sync

   Lors d'une opération d'écriture sur le volume des données du disque, le volume du bitmap du même groupe de périphériques est mis à jour. Aucune réplication n'est effectuée.

2. Assurez-vous que le cluster principal et le cluster secondaire sont en mode Journalisation et que l'autosynchronisation est désactivée.

   1. Sur le nodeA, vérifiez le mode et la configuration :

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

      La sortie résultante doit se présenter comme suit :

      /dev/vx/rdsk/devicegroup/vol01 -> lhost-reprg-sec:/dev/vx/rdsk/devicegroup/vol01 autosync:off, max q writes:4194304,max q fbas:16384,mode:sync,ctag: devicegroup, state: logging

   2. Sur le nodeC, vérifiez le mode et la configuration :

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

      La sortie résultante doit se présenter comme suit :

      /dev/vx/rdsk/devicegroup/vol01 <- lhost-reprg-prim:/dev/vx/rdsk/devicegroup/vol01 autosync:off, max q writes:4194304,max q fbas:16384,mode:sync,ctag: devicegroup, state: logging

   Pour le nœud_A et le nœud_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.

   nodeC# /usr/sbin/fsck -y /dev/vx/rdsk/devicegroup/vol01

4. Effectuez la commutation sur le cluster secondaire.

   nodeC# scswitch -Z -g nfs-rg

Étapes suivantes

Passez à la section Procédure de mise à jour de l'entrée DNS .

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

Pour une illustration de la manière dont le DNS associe un client à un cluster, reportez-vous à la Figure 6–6.

Avant de commencer

Vérifiez que vous avez bien respecté la procédure de la section Provocation d'un basculement.

Étapes

1. Exécutez la commande nsupdate.

   Pour obtenir de plus amples informations, reportez-vous à la page de manuel nsupdate(1M).

2. Supprimez le mappage DNS entre le nom d'hôte local du groupe de ressources d'application et l'adresse IP de chacun des clusters.

   > update delete lhost-nfsrg-prim A > update delete lhost-nfsrg-sec A > update delete ipaddress1rev.in-addr.arpa ttl PTR lhost-nfsrg-prim > update delete ipaddress2rev.in-addr.arpa ttl PTR lhost-nfsrg-sec

   ipaddress1rev

   Adresse IP du cluster principal, dans l'ordre inverse.

   ipaddress2rev

   Adresse IP du cluster secondaire, dans l'ordre inverse.

   ttl

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

3. Créez un mappage DNS entre le nom d'hôte local du groupe de ressources d'application et l'adresse IP de chacun des clusters.

   Associez le nom d'hôte logique principal à l'adresse IP du cluster secondaire, puis le nom d'hôte logique secondaire, à celle du cluster principal.

   > update add lhost-nfsrg-prim ttl A ipaddress2fwd > update add lhost-nfsrg-sec ttl A ipaddress1fwd > update add ipaddress2rev.in-addr.arpa ttl PTR lhost-nfsrg-prim > update add ipaddress1rev.in-addr.arpa ttl PTR lhost-nfsrg-sec

   ipaddress2fwd

   Adresse IP du cluster secondaire, dans l'ordre normal.

   ipaddress1fwd

   Adresse IP du cluster principal, dans l'ordre normal.

   ipaddress2rev

   Adresse IP du cluster secondaire, dans l'ordre inverse.

   ipaddress1rev

   Adresse IP du cluster principal, dans l'ordre inverse.