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 :
Liste des tâches : exemple de configuration de réplication des données
Exemple de configuration des groupes de périphériques et des groupes de ressources
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.
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.
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
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.
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.
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é.
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.
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 d'application
Instructions de gestion d'un basculement ou d'une commutation
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
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
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.
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.
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.
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 :
Synchronisez le cluster principal avec le cluster secondaire pour garantir que le volume principal est à jour.
Mettez à jour le DNS pour que les clients puissent accéder à l'application sur le cluster principal.
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. | |
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. | |
5. Vérifiez la configuration de la réplication des données. |
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.
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 :
|
Patchs du logiciel Sun StorEdge Availability Suite |
Pour obtenir de plus amples informations sur les derniers patchs, visitez le site http://www.sunsolve.com. |
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
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.
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.
Vérifiez que les tâches suivantes ont bien été effectuées.
Lire les instructions et conditions préalables des sections suivantes :
Configurer les clusters principal et secondaire selon la procédure décrite à la section Connexion et installation des clusters .
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.
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.
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.
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.
Passez à la section Procédure de configuration d'un groupe de périphériques de disques sur le cluster secondaire.
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.
Accédez au nodeC en tant que superutilisateur.
Créez un groupe de disques sur le nodeC. Ce groupe contiendra quatre volumes, du volume 1 (vol01) au volume 4 (vol04).
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.
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.
Passez à la section Procédure de configuration du système de fichiers sur le cluster principal d'une application NFS .
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.
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 |
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.
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.
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 |
Sur le nodeA, créez un système de fichiers pour le vol05.
nodeA# /usr/sbin/newfs /dev/vx/rdsk/devicegroup/vol05 |
Sur le nodeA et le nodeB, créez un point de montage pour le vol05.
Exemple :
nodeA# mkdir /global/etc |
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 |
Montez le vol05 sur le nodeA.
nodeA# mount /global/etc |
Faites en sorte que le vol05 soit accessible depuis un système distant.
Créez un répertoire appelé /global/etc/SUNW.nfs sur le nodeA.
nodeA# mkdir -p /global/etc/SUNW.nfs |
Créez le fichier /global/etc/SUNW.nfs/dfstab.nfs-rs sur le nodeA.
nodeA# touch /global/etc/SUNW.nfs/dfstab.nfs-rs |
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 |
Passez à la section Procédure de configuration du système de fichiers sur le cluster secondaire d'une application NFS.
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 .
Sur le nodeC, créez un répertoire de point de montage pour le système de fichiers NFS.
Exemple :
nodeC# mkdir /global/mountpoint |
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 |
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.
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 |
Sur le nodeC, créez le système de fichiers du vol05.
nodeC# /usr/sbin/newfs /dev/vx/rdsk/devicegroup/vol05 |
Sur le nodeC, créez un point de montage pour le vol05.
Exemple :
nodeC# mkdir /global/etc |
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 |
Montez le vol05 sur le nodeC.
nodeC# mount /global/etc |
Faites en sorte que le vol05 soit accessible depuis un système distant.
Créez un répertoire appelé /global/etc/SUNW.nfs sur le nodeC.
nodeC# mkdir -p /global/etc/SUNW.nfs |
Créez le fichier /global/etc/SUNW.nfs/dfstab.nfs-rs sur le nodeC.
nodeC# touch /global/etc/SUNW.nfs/dfstab.nfs-rs |
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 |
Passez à la section Procédure de création d'un groupe de ressources de réplication sur le cluster principal .
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.
Accédez au nodeA en tant que superutilisateur.
Enregistrez SUNW.HAStoragePlus en tant que type de ressource.
nodeA# /usr/cluster/bin/scrgadm -a -t SUNW.HAStoragePlus |
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 |
Nom du groupe de périphériques de disques
Nom du groupe de ressources de réplication
Spécifie les nœuds de cluster qui peuvent gérer le groupe de ressources de réplication
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 |
Ressource HAStoragePlus du groupe de ressources de réplication.
Spécifie la propriété d'extension sur laquelle s'appuie le logiciel Sun StorEdge Availability Suite.
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).
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.
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 |
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.
Passez à la section Procédure de création d'un groupe de ressources de réplication sur le cluster secondaire.
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 .
Accédez au nodeC en tant que superutilisateur.
Enregistrez SUNW.HAStoragePlus en tant que type de ressource.
nodeC# /usr/cluster/bin/scrgadm -a -t SUNW.HAStoragePlus |
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 |
Nom du groupe de périphériques de disques
Nom du groupe de ressources de réplication
Désigne le nœud de cluster qui peut gérer le groupe de ressources de réplication
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 |
Ressource HAStoragePlus du groupe de ressources de réplication.
Indique la propriété d'extension sur laquelle s'appuie le logiciel Sun StorEdge Availability Suite.
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).
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.
Activez les ressources, gérez le groupe de ressources et mettez-le en ligne.
nodeC# /usr/cluster/bin/scswitch -Z -g devicegroup-stor-rg |
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.
Passez à la section 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.
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.
Accédez au nodeA en tant que superutilisateur.
Enregistrez SUNW.nfs en tant que type de ressource.
nodeA# scrgadm -a -t SUNW.nfs |
Si SUNW.HAStoragePlus n'a pas éte enregistré en tant que type de ressource, enregistrez-le.
nodeA# scrgadm -a -t SUNW.HAStoragePlus |
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 |
Nom du groupe de ressources d'application.
Spécifie un répertoire dans lequel les ressources du groupe peuvent écrire des fichiers administratifs.
Spécifie que le groupe de ressources d'application n'est pas démarré automatiquement.
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.
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 |
Nom de la ressource HAStoragePlus pour l'application NFS.
Spécifie que le point de montage du système de fichiers est global.
Spécifie que la ressource est de type SUNW.HAStoragePlus.
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).
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.
Activez les ressources, gérez le groupe de ressources d'application et mettez-le en ligne.
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 |
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 |
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.
Passez à la section Création d'un groupe de ressources d'application NFS sur le cluster secondaire.
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 .
Accédez au nodeC en tant que superutilisateur.
Enregistrez SUNW.nfs en tant que type de ressource.
nodeC# scrgadm -a -t SUNW.nfs |
Si SUNW.HAStoragePlus n'a pas éte enregistré en tant que type de ressource, enregistrez-le.
nodeC# scrgadm -a -t SUNW.HAStoragePlus |
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 |
Nom du groupe de ressources d'application.
Spécifie un répertoire dans lequel les ressources du groupe peuvent écrire des fichiers administratifs.
Spécifie que le groupe de ressources d'application n'est pas démarré automatiquement.
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.
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 |
Nom de la ressource HAStoragePlus pour l'application NFS.
Spécifie que le point de montage du système de fichiers est global.
Spécifie que la ressource est de type SUNW.HAStoragePlus.
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).
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.
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 |
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.
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.
Passez à la section 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
Accédez au nodeA en tant que superutilisateur.
Supprimez toutes les transactions.
nodeA# /usr/sbin/lockfs -a -f |
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.
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 |
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.
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.
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.
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.
Passez à la section Procédure d'activation de la réplication sur le cluster secondaire.
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.
Accédez au nodeC en tant que superutilisateur.
Supprimez toutes les transactions.
nodeC# /usr/sbin/lockfs -a -f |
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.
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 |
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 |
Passez à la section 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:
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.
Accédez au nodeA en tant que superutilisateur.
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.
Supprimez toutes les transactions.
nodeA# /usr/sbin/lockfs -a -f |
Répétez la procédure, de l'Étape 1 à l'Étape 3 sur le nodeC.
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 |
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 |
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.
Passez à la section 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.
Vérifiez que vous avez bien respecté la procédure de la section Procédure de réplication distante .
Accédez au nodeA en tant que superutilisateur.
Désactivez la ressource qui s'exécute sur le nodeA.
nodeA# /usr/cluster/bin/scswitch -n -j nfs-rs |
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.
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 |
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 |
Redémarrez l'application sur le nœud_A.
nodeA# /usr/cluster/bin/scswitch -e -j nfs-rs |
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 |
Passez à la section Procédure de vérification de la réussite d'une réplication
Vérifiez que vous avez bien respecté la procédure de la section Procédure d'instantané ponctuel .
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.
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 |
Créez un répertoire sur une machine client.
Montez le répertoire de l'application sur le cluster principal, puis affichez-le.
Montez le répertoire de l'application sur le cluster secondaire, puis affichez-le.
Démontez le répertoire de l'application sur le cluster principal.
client-machine# umount /dir |
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 "" |
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.
Vérifiez que le répertoire PathPrefix est disponible.
nodeC# mount | grep /global/etc |
Mettez le groupe de ressources d'application en ligne sur le cluster secondaire.
nodeC# /usr/cluster/bin/scswitch -Z -g nfs-rg |
Connectez-vous à la machine client en tant que superutilisateur.
L'invite qui apparaît ressemble à celle-ci :
client-machine# |
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 |
Affichez-le.
client-machine# ls /dir |
Assurez-vous que le répertoire affiché à l'Étape 4 correspond bien à celui qui apparaît à l'Étape 5.
Renvoyez l'application du cluster principal vers le répertoire monté.
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 "" |
Vérifiez que le volume global est démonté sur le cluster secondaire.
nodeC# umount /global/mountpoint |
Mettez le groupe de ressources d'application en ligne sur le cluster principal.
nodeA# /usr/cluster/bin/scswitch -Z -g nfs-rg |
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.
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:
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.
Assurez-vous que le cluster principal et le cluster secondaire sont en mode Journalisation et que l'autosynchronisation est désactivée.
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 |
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.
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 |
Effectuez la commutation sur le cluster secondaire.
nodeC# scswitch -Z -g nfs-rg |
Passez à la section 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.
Vérifiez que vous avez bien respecté la procédure de la section Provocation d'un basculement.
Exécutez la commande nsupdate.
Pour obtenir de plus amples informations, reportez-vous à la page de manuel nsupdate(1M).
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 |
Adresse IP du cluster principal, dans l'ordre inverse.
Adresse IP du cluster secondaire, dans l'ordre inverse.
Durée de vie, en secondes. 3600 est la valeur courante.
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 |
Adresse IP du cluster secondaire, dans l'ordre normal.
Adresse IP du cluster principal, dans l'ordre normal.
Adresse IP du cluster secondaire, dans l'ordre inverse.
Adresse IP du cluster principal, dans l'ordre inverse.