Ce chapitre fournit des instructions concernant la configuration de la réplication de données entre clusters à l'aide du logiciel Sun StorEdge Availability Suite 3.1.
Il contient également un exemple de configuration de réplication de données pour une application NFS à l'aide du logiciel Sun StorEdge Availability Suite 3.1. Cet exemple s'applique à une configuration de cluster spécifique et fournit des informations détaillées sur l'exécution de tâches individuelles. Il ne décrit pas l'ensemble des étapes requises par d'autres applications ou d'autres configurations de cluster.
Ce chapitre comprend les rubriques suivantes :
Les procédures décrites dans ce chapitre sont les suivantes :
Procédure de configuration d'un groupe de périphériques de disques sur le cluster principal
Procédure de configuration d'un groupe de périphériques de disques sur le cluster secondaire
Procédure de configuration du système de fichiers sur le cluster principal d'une application NFS
Procédure de configuration du système de fichiers sur le cluster secondaire d'une application NFS
Procédure de création d'un groupe de ressources de réplication sur le cluster principal
Procédure de création d'un groupe de ressources de réplication sur le cluster secondaire
Procédure de création d'un groupe de ressources d'application sur le cluster principal
Procédure de création d'un groupe de ressources d'application sur le cluster secondaire
Procédure d'activation de la réplication sur le cluster principal
Procédure d'activation de la réplication sur le cluster secondaire
Cette rubrique aborde la tolérance de sinistre et décrit les méthodes de réplication de données utilisées par le logiciel Sun StorEdge Availability Suite 3.1.
La tolérance de sinistre est la capacité du système à restaurer une application sur un autre cluster lorsque survient un échec du cluster principal. La tolérance de sinistre se base sur la réplication de données et le basculement.
La réplication de données consiste à copier les données d'un cluster principal sur un cluster de secours ou secondaire. La réplication de données fournit au cluster secondaire une copie mise à jour des données du cluster principal. Le cluster secondaire peut être situé loin du cluster principal.
Le basculement consiste à transférer automatiquement un groupe de ressources ou de périphériques depuis un cluster principal vers un cluster secondaire. En cas d'échec du cluster principal, l'application et les données sont immédiatement disponibles sur le cluster secondaire.
Cette rubrique présente les méthodes de réplication distante et d'instantané ponctuel utilisées par le logiciel Sun StorEdge Availability Suite 3.1. Ce logiciel utilise les commandes sndradm(1RPC) et iiadm(1II) pour répliquer les données. Pour de plus amples informations sur ces commandes, reportez-vous au document Sun Cluster 3.0 and Sun StorEdge Software Integration Guide.
La réplication distante est illustrée dans la Figure 6–1. Les données du volume maître du disque principal sont répliquées sur celui du disque secondaire à travers une connexion TCP/IP. Un bitmap de réplication distante fait le suivi des différences entre le volume maître du disque principal et celui du disque secondaire.
La réplication distante peut être effectuée de façon synchrone en temps réel ou asynchrone. Sur chaque cluster, chaque ensemble de volumes peut être configuré individuellement en choisissant une réplication synchrone ou asynchrone.
Dans la réplication de données synchrone, une opération d'écriture n'est pas confirmée comme étant terminée tant que le volume distant n'a pas été mis à jour.
Dans la réplication de données asynchrone, une opération d'écriture est confirmée comme étant terminée avant la mise à jour du volume distant. La réplication de données asynchrone fournit une plus grande flexibilité sur une longue distance et une bande passante étroite.
L'instantané ponctuel est illustré dans la Figure 6–2. Les données du volume maître de chaque disque sont copiées sur le volume en double du même disque. Le bitmap ponctuel fait le suivi des différences entre le volume maître et le volume en double. Une fois les données copiées sur le volume en double, le bitmap ponctuel est réinitialisé.
La figure suivante illustre l'utilisation de la réplication distante et de l'instantané ponctuel dans l'Exemple de configuration.
Cette rubrique fournit des instructions de configuration de la réplication de données entre clusters. Elle contient également des astuces pour la configuration de groupes de ressources de réplication et d'application. Suivez ces instructions pour configurer la réplication de données de votre cluster.
Cette section traite les rubriques suivantes :
Configuration des groupes de ressources pour une application de basculement
Configuration des groupes de ressources pour une application évolutive
Instructions de gestion d'un basculement ou d'une commutation
Les groupes de ressources de réplication placent le groupe de périphériques sous le contrôle du logiciel Sun StorEdge Availability Suite 3.1 avec les ressources de nom d'hôte logique. Un groupe de ressources de réplication doit présenter les caractéristiques suivantes :
Être un groupe de ressources de basculement
Une ressource de basculement ne peut être exécutée que sur un seul noeud à la fois. En cas de basculement, les ressources de basculement interviennent.
Disposer d'une ressource de nom d'hôte logique
Le nom d'hôte logique doit être hébergé par le cluster principal. Après un basculement ou une commutation, le nom d'hôte logique doit figurer sur le cluster secondaire. Le DNS (système de noms de domaines) est utilisé pour associer un nom d'hôte logique à un cluster.
Disposer d'une ressource HAStoragePlus
La ressource HAStoragePlus génère la commutation du groupe de périphériques en cas de basculement ou de commutation du groupe de ressources de réplication. Sun Cluster génère également la commutation du groupe de ressources de réplication en cas de commutation du groupe de périphériques. Ainsi, le groupe de ressources de réplication et le groupe de périphériques sont toujours placés sur le même noeud ou contrôlés par celui-ci.
Les propriétés d'extension suivantes doivent être définies dans la ressource HAStoragePlus :
GlobalDevicePaths Cette propriété d'extension détermine le groupe de périphériques auquel appartient un volume.
AffinityOn property = True. Cette propriété d'extension entraîne la commutation ou le basculement du groupe de périphériques lors de la commutation ou du basculement du groupe de ressources de réplication. Cette fonction est appelée commutation analogue.
Pour de plus amples informations sur HAStoragePlus, reportez-vous à la page de manuel SUNW.HAStoragePlus(5).
Porter le nom du groupe de périphériques avec lequel il est placé, suivi de -stor-rg
Par exemple, groupe_périphérique-stor-rg.
Être en ligne à la fois sur le cluster principal et le cluster secondaire
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
Dans une application de basculement, une application ne s'exécute que sur un seul noeud à la fois. En cas d'échec sur ce noeud, l'application bascule sur un autre noeud du même cluster. Le groupe de ressources d'une application de basculement doit présenter les caractéristiques suivantes :
Disposer d'une ressource HAStoragePlus générant la commutation du groupe de périphériques en cas de basculement ou de commutation du groupe de ressources d'application
Le groupe de périphériques est placé avec le groupe de ressources de réplication et le groupe de ressources d'application. Ainsi, la commutation du groupe de ressources d'application génère la commutation du groupe de périphériques et du groupe de ressources de réplication. Le groupe de ressources d'application, le groupe de ressources de réplication et le groupe de périphériques sont contrôlés par le même noeud.
Notez cependant que la commutation ou le basculement du groupe de périphériques ou du groupe de ressources de réplication n'entraîne pas la commutation ou le basculement du groupe de ressources d'application.
Si les données de l'application sont montées globalement, la présence d'une ressource HAStoragePlus dans le groupe de ressources d'application n'est pas obligatoire, mais elle est recommandée.
Si les données de l'application sont montées localement, la présence d'une ressource HAStoragePlus dans le groupe de ressources d'application est obligatoire.
Sans cela, la commutation ou le basculement du groupe de ressources d'application ne déclenchera pas la commutation ou le basculement du groupe de ressources de réplication et du groupe de périphériques. Après une commutation ou un basculement, le groupe de ressources d'application, le groupe de ressources de réplication et le groupe de périphériques ne seraient plus contrôlés par le même noeud.
Pour de plus amples informations sur HAStoragePlus, reportez-vous à la page de manuel SUNW.HAStoragePlus(5).
Être en ligne sur le cluster principal et hors ligne sur le cluster secondaire
Le groupe de ressources d'application doit être mis en ligne sur le cluster secondaire lorsque celui-ci prend la relève du cluster principal.
La figure suivante illustre la configuration d'un groupe de ressources d'application et d'un groupe de ressources de réplication dans une application de basculement.
Dans une application évolutive, une application s'exécute sur plusieurs noeuds à la fois pour créer un service logique unique. En cas d'échec d'un noeud exécutant une application évolutive, le basculement ne se produit pas. L'application continue de s'exécuter sur d'autres noeuds.
Lorsqu'une application évolutive est gérée comme une ressource dans un groupe de ressources d'application, il n'est pas nécessaire de placer le groupe de ressources d'application avec le groupe de périphériques. Il est donc inutile de créer une ressource HAStoragePlus pour le groupe de ressources d'application.
Le groupe de ressources d'une application évolutive doit présenter les caractéristiques suivantes :
Avoir une dépendance sur le groupe de ressources d'adresse partagée
Les noeuds exécutant l'application évolutive utilisent l'adresse partagée pour distribuer les données entrantes.
Être en ligne sur le cluster principal et hors ligne sur le cluster secondaire
La figure suivante illustre la configuration des groupes de ressources dans une application évolutive.
En cas d'échec du cluster principal, l'application doit être commutée sur le cluster secondaire dès que possible. Pour que s'active le basculement du cluster secondaire, le DNS doit être mis à jour. De plus, le volume secondaire doit être monté dans le répertoire du point de montage correspondant au système de fichiers de l'application.
Les DNS associent un client au nom d'hôte logique d'une application. Après un basculement ou une commutation, le mappage du DNS au cluster principal doit être supprimé et un mappage du DNS au cluster secondaire doit être créé. La figure suivante illustre la procédure de mappage du DNS d'un client à un cluster.
Pour mettre à jour le DNS, utilisez la commande nsupdate. Pour de plus amples informations, reportez-vous à la page de manuel nsupdate(1M). Pour consulter un exemple de gestion d'un basculement ou d'une commutation, reportez-vous à l'Exemple de gestion d'un basculement ou d'une commutation.
Une fois la réparation effectuée, le cluster principal peut être remis en ligne. Pour revenir au cluster principal d'origine, procédez comme suit :
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.
Montez le volume principal dans le répertoire du point de montage correspondant au système de fichiers de l'application.
Cette rubrique fournit un exemple pas à pas de configuration d'une réplication de données pour une application NFS à l'aide du logiciel Sun StorEdge Availability Suite 3.1.
La Figure 6–7 illustre la configuration de cluster utilisée dans l'exemple de configuration. Le cluster secondaire de l'exemple de configuration contient un noeud, mais d'autres configurations de cluster peuvent être utilisées.
Le Tableau 6–1 fournit un résumé du matériel et des logiciels requis dans l'exemple de configuration. Le système d'exploitation, le logiciel Sun Cluster et le gestionnaire de volumes doivent être installés sur les noeuds de cluster avant de procéder à l'installation du logiciel et des patchs Sun StorEdge Availability Suite 3.1.
Tableau 6–1 Matériel et logiciels requis
Matériel ou logiciels |
Conditions requises |
---|---|
Matériel du noeud |
Le logiciel Sun StorEdge Availability Suite 3.1 est pris en charge sur tous les serveurs utilisant le système d'exploitation Solaris. Pour de plus amples informations sur le matériel à utiliser, reportez-vous au document Sun Cluster 3.x Hardware Administration Manual for Solaris OS |
Espace disque |
Environ 11 Mo. |
Environnement d' exploitation |
Versions Solaris 8 ou Solaris 9 prises en charge par le logiciel Sun Cluster. Tous les noeuds doivent utiliser la même version de système d'exploitation. Pour de plus amples informations sur l'installation, reportez-vous à la rubrique Installation du logiciel. |
Logiciel Sun Cluster |
Logiciel Sun Cluster 3.1 4/04. Pour obtenir des informations d'installation, reportez-vous au Chapitre 2 et à la rubrique Installation du logiciel Sun Cluster sur un cluster à noeud unique. |
Gestionnaire de volume |
Solstice DiskSuite/Solaris Volume Manager ou VERITAS Volume Manager (VxVM). Tous les noeuds doivent utiliser la même version de gestionnaire de volumes. Pour obtenir des informations d'installation, reportez-vous aux rubriques Installation et configuration du logiciel Solstice DiskSuite/Solaris Volume Manager et SPARC: installation et configuration du logiciel VxVM. |
Logiciel Sun StorEdge Availability Suite 3.1 |
Pour de plus amples informations sur l'installation du logiciel, reportez-vous aux documents Sun StorEdge Availability Suite 3.1 Point-in-Time Copy Software Installation Guide et Sun StorEdge Availability Suite 3.1 Remote Mirror Software Installation Guide. |
Patchs du logiciel Sun StorEdge Availability Suite 3.1 |
Pour obtenir des informations sur les patchs les plus récents, consultez le site http://sunsolve.sun.com. |
Ce chapitre décrit la configuration des groupes de périphériques de disques et des groupes de ressources pour une application NFS. Vous trouverez dans le tableau suivant les noms des groupes et ressources ayant été créés pour cet exemple de configuration.
Tableau 6–2 Récapitulatif des groupes et ressources de l'exemple de configuration
Groupe ou ressource |
Nom |
Description |
---|---|---|
Groupe de périphériques de disque |
groupe_périphériques |
Groupe de périphériques du disque. |
Groupe de ressources et ressources de réplication |
groupe_périphériques-stor-rg |
Groupe des ressources de réplication. |
prin_grrép_nhlog, sec_grrép_nhlog |
Noms d'hôtes logiques du groupe de ressources de réplication sur le cluster principal et sur le cluster secondaire. |
|
groupe_périphériques_stor |
Ressource HAStoragePlus du groupe de ressources de réplication. |
|
Groupe de ressources et ressources d'application |
gr_nfs |
Groupe de ressources d'application. |
prin_grnfs_nhlog, sec_grnfs_nhlog |
Noms d'hôtes logiques du groupe de ressources d'application sur le cluster principal et sur le cluster secondaire. |
|
rs_dg_nfs |
Ressource HAStoragePlus de l'application. |
|
rs_nfs |
Ressource NFS. |
À l'exception de groupe_périphériques-stor-rg, les noms des groupes et ressources ne sont donnés qu'à titre d'exemples et peuvent être modifiés si nécessaire. Le nom du groupe de ressources de réplication doit avoir le format suivant : groupe_périphériques-stor-rg.
Cette rubrique décrit la configuration d'un groupe de périphériques de disques sur le cluster principal et sur le cluster secondaire. Cet exemple de configuration utilise le logiciel VxVM. Pour de plus amples informations sur le logiciel Solstice DiskSuite/Solaris Volume Manager, reportez-vous au Chapitre 3.
La figure suivante illustre les volumes créés dans le groupe de périphériques de disques.
les volumes définis dans cette section ne doivent contenir aucune zone privée de label de disque, comme le cylindre 0. VxVM gère automatiquement cette contrainte.
Créez un groupe de disques contenant quatre volumes, du volume 1 au volume 4.
Pour de plus amples informations sur la configuration d'un groupe de disques à l'aide de VxVM reportez-vous au Chapitre 4.
Accédez au noeud_A en tant que superutilisateur.
Le noeud_A est le premier noeud du cluster principal. Pour vous rappeler quel noeud est le noeud_A, reportez-vous à la Figure 6–7.
Configurez le groupe de disques pour créer un groupe de périphériques de disques.
noeud_A# /usr/cluster/bin/scconf -a -D type=vxvm,name=groupe_périphériques \ ,nodelist=noeud_A:noeud_B |
Le groupe de périphériques de disques est appelé groupe_périphériques.
Démarrez le groupe de périphériques de disques.
noeud_A# /usr/cluster/bin/scswitch -z -D groupe_périphériques -h noeud_A |
Synchronisez le groupe de périphériques de disques à l'aide du logiciel Sun Cluster.
noeud_A# /usr/cluster/bin/scconf -c -D name=groupe_périphériques,sync |
Créez le système de fichiers du groupe de périphériques de disques.
noeud_A# /usr/sbin/newfs /dev/vx/rdsk/groupe_périphériques/vol01 < /dev/null noeud_A# /usr/sbin/newfs /dev/vx/rdsk/groupe_périphériques/vol02 < /dev/null noeud_A# /usr/sbin/newfs /dev/vx/rdsk/groupe_périphériques/vol03 < /dev/null noeud_A# /usr/sbin/newfs /dev/vx/rdsk/groupe_périphériques/vol04 < /dev/null |
Activez l'accès distant entre les noeuds des clusters principal et secondaire en ajoutant les entités suivantes au fichier /.rhosts sur le noeud_A et le noeud_B :
noeud_C + ; + root. |
Suivez les étapes de la Procédure de configuration d'un groupe de périphériques de disques sur le cluster principal à l'exception des points suivants :
Remplacez le noeud_A par le noeud_C.
N'utilisez pas le noeud_B.
À l'Étape 3, n'incluez le noeud_C que dans la liste de noeuds. Exemple :
noeud_C# /usr/cluster/bin/scconf -a -D type=vxvm,name=groupe_périphériques \ ,nodelist=noeud_C |
À l'Étape 7, ajoutez les entités suivantes au fichier /.rhosts sur le noeud_C uniquement :
noeud_A + ; noeud_B + ; + root. |
Cette rubrique décrit la configuration des systèmes de fichiers d'une application NFS.
Sur le noeud_A et le noeud_B, créez un répertoire de point de montage pour le système de fichiers NFS.
Exemple :
noeud_A# mkdir /global/point_montage |
Sur le noeud_A et le noeud_B, configurez le volume maître à monter automatiquement sur le point de montage.
Ajoutez ou substituez le texte suivant dans le fichier /etc/vfstab sur le noeud_A et le noeud_B. Le texte doit tenir sur une seule ligne.
/dev/vx/dsk/groupe_périphériques/vol01 /dev/vx/rdsk/groupe_périphériques/vol01 \ /global/point_montage ufs 3 no global,logging |
Pour vous rappeler les noms et numéros de volumes utilisés dans le groupe de périphériques de disques, reportez-vous à la Figure 6–8.
Sur le noeud_A, créez un volume pour les informations du système de fichiers utilisées par le logiciel Sun StorEdge Availability Suite 3.1.
noeud_A# /usr/sbin/vxassist -g groupe_périphériques make vol05 120m disque_1 |
Le volume 5 contient les informations concernant le système de fichiers utilisées par le logiciel Sun StorEdge Availability Suite 3.1.
Sur le noeud_A, resynchronisez le groupe de périphériques avec le logiciel Sun Cluster.
noeud_A# /usr/cluster/bin/scconf -c -D name=groupe_périphériques,sync |
Sur le noeud_A, créez le système de fichiers du volume 5.
noeud_A# /usr/sbin/newfs /dev/vx/rdsk/groupe_périphériques/vol05 |
Sur le noeud_A et le noeud_B, créez un point de montage pour le volume 5.
Exemple :
noeud_A# mkdir /global/etc |
Sur le noeud_A et le noeud_B, configurez le volume 5 à monter automatiquement sur le point de montage.
Ajoutez ou substituez le texte suivant dans le fichier /etc/vfstab sur le noeud_A et le noeud_B. Le texte doit tenir sur une seule ligne.
/dev/vx/dsk/groupe_périphériques/vol05 /dev/vx/rdsk/groupe_périphériques/vol05 \ /global/etc ufs 3 yes global,logging |
Montez le volume 5 sur le noeud_A.
noeud_A# mount /global/etc |
Rendez le volume 5 accessible aux systèmes distants.
Créez un répertoire appelé /global/etc/SUNW.nfs sur le noeud_A.
noeud_A# mkdir -p /global/etc/SUNW.nfs |
Créez le fichier /global/etc/SUNW.nfs/dfstab.rs_nfs sur le noeud_A.
noeud_A# touch /global/etc/SUNW.nfs/dfstab.rs_nfs |
Ajoutez la ligne suivante au fichier /global/etc/SUNW.nfs/dfstab.rs_nfs sur le noeud_A :
share -F nfs -o rw -d "HA NFS" /global/point_montage |
Suivez les étapes de la Procédure de configuration du système de fichiers sur le cluster principal d'une application NFS à l'exception des points suivants :
Remplacez le noeud_A par le noeud_C.
N'utilisez pas le noeud_B.
Cette rubrique décrit la création d'un groupe de ressources de réplication sur les clusters principal et secondaire.
Accédez au noeud_A en tant que superutilisateur.
Enregistrez SUNW.HAStoragePlus en tant que type de ressource.
noeud_A# /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.
noeud_A# /usr/cluster/bin/scrgadm -a -g groupe_périphériques-stor-rg -h noeud_A,noeud_B |
Nom du groupe de périphériques de disques.
Nom du groupe de ressources de réplication.
Spécifie les noeuds de cluster pouvant contrôler le groupe de ressources de réplication.
Ajoutez une ressource SUNW.HAStoragePlus au groupe de ressources de réplication.
noeud_A# /usr/cluster/bin/scrgadm -a -j groupe_périphériques-stor \ -g groupe_périphériques-stor-rg -t SUNW.HAStoragePlus \ -x GlobalDevicePaths=groupe_périphériques \ -x AffinityOn=True |
Ressource HAStoragePlus du groupe de ressources de réplication.
Spécifie la propriété d'extension sur laquelle s'appuie Sun StorEdge Availability Suite 3.1.
Spécifie que la ressource SUNW.HAStoragePlus doit effectuer une commutation analogue pour les périphériques globaux et les systèmes de fichiers de cluster définis par -x GlobalDevicePaths=. Ainsi, lorsque le groupe de ressources de réplication bascule ou commute, le groupe de périphériques associé commute également.
Pour de plus amples informations sur les propriétés d'extension, reportez-vous à la page de manuel SUNW.HAStoragePlus(5).
Ajoutez une ressource de nom d'hôte logique au groupe de ressources de réplication.
noeud_A# /usr/cluster/bin/scrgadm -a -L \ -j prin_grrép_nhlog -g groupe_périphériques-stor-rg -l prin_grrép_nhlog |
où prin_grrép_nhlog correspond au nom d'hôte logique du groupe de ressources de réplication du cluster principal.
Activez les ressources, gérez le groupe de ressources et mettez-le en ligne.
noeud_A# /usr/cluster/bin/scswitch -Z -g groupe_périphériques-stor-rg noeud_A# /usr/cluster/bin/scswitch -z -g groupe_périphériques-stor-rg -h noeud_A |
Vérifiez que le groupe de ressources est en ligne.
noeud_A# /usr/cluster/bin/scstat -g |
Vérifiez dans le champ d'état du groupe de ressources que le groupe de ressources de réplication est en ligne pour le noeud_A et le noeud_B.
Suivez les étapes de la Procédure de création d'un groupe de ressources de réplication sur le cluster principal à l'exception des points suivants :
Remplacez le noeud_A par le noeud_C.
N'utilisez pas le noeud_B.
Remplacez prin_grrép_nhlog par sec_grrép_nhlog.
Cette rubrique décrit la création de groupes de ressources d'application pour une application NFS. Les procédures présentées dans cette rubrique sont spécifiques à l'application. Elles ne peuvent être utilisées pour un autre type d'application.
Accédez au noeud_A en tant que superutilisateur.
Enregistrez SUNW.nfs en tant que type de ressource.
noeud_A# scrgadm -a -t SUNW.nfs |
Si SUNW.HAStoragePlus n'a pas éte enregistré en tant que type de ressource, enregistrez-le.
noeud_A# scrgadm -a -t SUNW.HAStoragePlus |
Créez un groupe de ressources d'application pour le groupe_périphériques.
noeud_A# scrgadm -a -g gr_nfs \ -y Pathprefix=/global/etc \ -y Auto_start_on_new_cluster=False \ -y RG_dependencies=groupe_périphériques-stor-rg |
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 noeud principal, le groupe de ressources de réplication est automatiquement commuté. Cependant, si le groupe de ressources de réplication est commuté vers un nouveau noeud principal, le groupe de ressources d'application doit être commuté manuellement.
Ajoutez une ressource SUNW.HAStoragePlus au groupe de ressources d'application.
noeud_A# scrgadm -a -j rs_dg_nfs -g gr_nfs \ -t SUNW.HAStoragePlus \ -x fichierSystemMountPoints=/global/point_montage \ -x AffinityOn=True |
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 de plus amples informations sur les 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.
noeud_A# /usr/cluster/bin/scrgadm -a -L -j prin_grnfs_nhlog -g gr_nfs \ -l prin_grnfs_nhlog |
où prin_grnfs_nhlog correspond au nom d'hôte logique du groupe de ressources d'application sur le cluster principal.
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.
noeud_A# /usr/cluster/bin/scrgadm -a -g gr_nfs \ -j rs_nfs -t SUNW.nfs -y ressource_dependencies=rs_dg_nfs |
Mettez le groupe de ressources d'application en ligne sur le noeud_A.
noeud_A# /usr/cluster/bin/scswitch -Z -g gr_nfs noeud_A# /usr/cluster/bin/scswitch -z -g gr_nfs -h noeud_A |
Vérifiez que le groupe de ressources d'application est en ligne.
noeud_A# /usr/cluster/bin/scstat -g |
Vérifiez dans le champ d'état du groupe de ressources que le groupe de ressources d'application est en ligne pour le noeud_A et le noeud_B.
Créez la ressource de groupe d'application comme décrit de l'Étape 1 à l'Étape 6 dans la Procédure de création d'un groupe de ressources d'application sur le cluster principal, à l'exception des points suivants :
Remplacez le noeud_A par le noeud_C.
Ignorez les références au noeud_B.
Remplacez prin_grnfs_nhlog par sec_grnfs_nhlog.
Vérifiez que le groupe de ressources d'application n'est pas en ligne sur le noeud_C.
noeud_C# /usr/cluster/bin/scswitch -n -j rs_nfs noeud_C# /usr/cluster/bin/scswitch -n -j rs_dg_nfs noeud_C# /usr/cluster/bin/scswitch -n -j sec_grnfs_nhlog noeud_C# /usr/cluster/bin/scswitch -z -g gr_nfs -h "" |
Le groupe de ressources reste hors ligne après une réinitialisation, car Auto_start_on_new_cluster=False.
Si le volume global est monté sur le cluster principal, démontez-le du cluster secondaire.
noeud_C# umount /global/point_montage |
Si le volume est monté sur le cluster secondaire, la synchronisation échoue.
Cette rubrique décrit l'activation de la réplication de données dans l'exemple de configuration. Elle utilise les commandes sndradm et iiadm du logiciel Sun StorEdge Availability Suite 3.1. Pour de plus amples informations sur ces commandes, reportez-vous au document Sun Cluster 3.0 and Sun StorEdge Software Integration Guide.
Accédez au noeud_A en tant que superutilisateur.
Supprimez toutes les transactions.
noeud_A# /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.
noeud_A# /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 active la réplication du volume maître du cluster principal vers le volume maître du cluster secondaire. De plus, elle active la réplication vers le bitmap distant sur le volume 4.
Si les clusters principal et secondaire sont désynchronisés, exécutez cette commande :
noeud_A# /usr/opt/SUNWesm/sbin/sndradm -n -e prem_grrép_nhlog \ /dev/vx/rdsk/groupe_périphériques/vol01 \ /dev/vx/rdsk/groupe_périphériques/vol04 sec_grrép_nhlog \ /dev/vx/rdsk/groupe_périphériques/vol01 \ /dev/vx/rdsk/groupe_périphériques/vol04 ip sync |
Si les clusters principal et secondaire sont synchronisés, exécutez cette commande :
noeud_A# /usr/opt/SUNWesm/sbin/sndradm -n -E prem_grrép_nhlog \ /dev/vx/rdsk/groupe_périphériques/vol01 \ /dev/vx/rdsk/groupe_périphériques/vol04 sec_grrép_nhlog \ /dev/vx/rdsk/groupe_périphériques/vol01 \ /dev/vx/rdsk/groupe_périphériques/vol04 ip sync |
Activez l'autosynchronisation.
noeud_A# /usr/opt/SUNWesm/sbin/sndradm -n -a on prin_grrép_nhlog \ /dev/vx/rdsk/groupe_périphériques/vol01 \ /dev/vx/rdsk/groupe_périphériques/vol04 sec_grrép_nhlog \ /dev/vx/rdsk/groupe_périphériques/vol01 \ /dev/vx/rdsk/groupe_périphériques/vol04 ip sync |
Cette étape active l'autosynchronisation. Lorsque l'état actif de l'autosynchronisation est défini sur on, les ensembles de volumes sont resynchronisés en cas de réinitialisation du système ou de défaillance.
Vérifiez que le cluster est en mode journalisation.
noeud_A# /usr/opt/SUNWesm/sbin/sndradm -P |
Le résultat ressemble à ce qui suit :
/dev/vx/rdsk/groupe_périphériques/vol01 -> sec_grrép_nhlog:/dev/vx/rdsk/groupe_périphériques/vol01 autosync: off, max q writes:4194304, max q fbas:16384, mode:sync,ctag: groupe_périphériques, state: logging |
En mode journalisation, l'état est logging et l'état actif de l'autosynchronisation est off. Au cours de l'écriture sur le volume de données du disque, le fichier bitmap figurant sur ce disque est mis à jour.
Activez l'instantané ponctuel.
noeud_A# /usr/opt/SUNWesm/sbin/iiadm -e ind \ /dev/vx/rdsk/groupe_périphériques/vol01 \ /dev/vx/rdsk/groupe_périphériques/vol02 \ /dev/vx/rdsk/groupe_périphériques/vol03 noeud_A# /usr/opt/SUNWesm/sbin/iiadm -w \ /dev/vx/rdsk/groupe_périphériques/vol02 |
Cette étape active la copie du volume maître du disque principal sur le volume en double du même disque. Dans cet exemple, le volume maître correspond au volume 1, le volume en double au volume 2, et le volume de bitmap ponctuel au volume 3.
Attachez l'instantané ponctuel au jeu de miroirs distants.
noeud_A# /usr/opt/SUNWesm/sbin/sndradm -I a \ /dev/vx/rdsk/groupe_périphériques/vol01 \ /dev/vx/rdsk/groupe_périphériques/vol02 \ /dev/vx/rdsk/groupe_périphériques/vol03 |
Cette étape associe l'instantané ponctuel au jeu de miroirs distants. Le logiciel Sun StorEdge Availability Suite 3.1 assure la réalisation d'un instantané ponctuel avant la réplication distante.
Accédez au noeud_C en tant que superutilisateur.
Supprimez toutes les transactions.
noeud_C# /usr/sbin/lockfs -a -f |
Activez la réplication distante du cluster principal vers le cluster secondaire.
noeud_C# /usr/opt/SUNWesm/sbin/sndradm -n -e prin_grrép_nhlog \ /dev/vx/rdsk/groupe_périphériques/vol01 \ /dev/vx/rdsk/groupe_périphériques/vol04 sec_grrép_nhlog \ /dev/vx/rdsk/groupe_périphériques/vol01 \ /dev/vx/rdsk/groupe_périphériques/vol04 ip sync |
Le cluster principal détecte la présence du cluster secondaire et démarre la synchronisation. Reportez-vous au fichier de consignation système /var/opt/SUNWesm/ds.log pour obtenir des informations sur le statut des clusters.
Activez l'instantané ponctuel indépendant.
noeud_C# /usr/opt/SUNWesm/sbin/iiadm -e ind \ /dev/vx/rdsk/groupe_périphériques/vol01 \ /dev/vx/rdsk/groupe_périphériques/vol02 \ /dev/vx/rdsk/groupe_périphériques/vol03 noeud_C# /usr/opt/SUNWesm/sbin/iiadm -w \ /dev/vx/rdsk/groupe_périphériques/vol02 |
Attachez l'instantané ponctuel au jeu de miroirs distants.
noeud_C# /usr/opt/SUNWesm/sbin/sndradm -I a \ /dev/vx/rdsk/groupe_périphériques/vol01 \ /dev/vx/rdsk/groupe_périphériques/vol02 \ /dev/vx/rdsk/groupe_périphériques/vol03 |
Cette rubrique décrit la procédure de réplication de données de l'exemple de configuration. Elle utilise les commandes sndradm et iiadm du logiciel Sun StorEdge Availability Suite 3.1 Pour de plus amples informations sur ces commandes, reportez-vous au document Sun Cluster 3.0 and Sun StorEdge Software Integration Guide.
Dans cette procédure, le volume maître du disque principal est répliqué vers le volume maître du disque secondaire. Le volume maître correspond au volume 1 et le volume bitmap miroir distant au volume 4.
Accédez au noeud_A en tant que superutilisateur.
Vérifiez que le cluster est en mode journalisation.
noeud_A# /usr/opt/SUNWesm/sbin/sndradm -P |
Le résultat ressemble à ce qui suit :
/dev/vx/rdsk/groupe_périphériques/vol01 -> sec_grrép_nhlog:/dev/vx/rdsk/groupe_périphériques/vol01 autosync: off, max q writes:4194304, max q fbas:16384, mode:sync,ctag: groupe_périphériques, state: logging |
En mode journalisation, l'état est logging et l'état actif de l'autosynchronisation est off. Au cours de l'écriture sur le volume de données du disque, le fichier bitmap figurant sur ce disque est mis à jour.
Supprimez toutes les transactions.
noeud_A# /usr/sbin/lockfs -a -f |
Répétez la procédure de l'Étape 1 à l'Étape 3 sur le noeud_C.
Copiez le volume maître du noeud_A sur le volume maître du noeud_C.
noeud_A# /usr/opt/SUNWesm/sbin/sndradm -n -m prin_grrép_nhlog \ /dev/vx/rdsk/groupe_périphériques/vol01 \ /dev/vx/rdsk/groupe_périphériques/vol04 sec_grrép_nhlog \ /dev/vx/rdsk/groupe_périphériques/vol01 \ /dev/vx/rdsk/groupe_périphériques/vol04 ip sync |
Attendez que la réplication soit terminée et les volumes synchronisés.
noeud_A# /usr/opt/SUNWesm/sbin/sndradm -n -w prin_grrép_nhlog \ /dev/vx/rdsk/groupe_périphériques/vol01 \ /dev/vx/rdsk/groupe_périphériques/vol04 sec_grrép_nhlog \ /dev/vx/rdsk/groupe_périphériques/vol01 \ /dev/vx/rdsk/groupe_périphériques/vol04 ip sync |
Vérifiez que le cluster est en mode réplication.
noeud_A# /usr/opt/SUNWesm/sbin/sndradm -P |
Le résultat ressemble à ce qui suit :
/dev/vx/rdsk/groupe_périphériques/vol01 -> sec_grrép_nhlog:/dev/vx/rdsk/groupe_périphériques/vol01 autosync: on, max q writes:4194304, max q fbas:16384, mode:sync,ctag: groupe_périphériques, state: replicating |
En mode réplication, l'état est replicating et l'état actif de l'autosynchronisation est on. Au cours de l'écriture sur le volume principal, le volume secondaire est mis à jour par le logiciel Sun StorEdge Availability Suite 3.1.
Dans cette procédure, l'instantané ponctuel a été utilisé pour synchroniser le volume en double du cluster principal avec le volume maître du cluster principal. Le volume maître correspond au volume 1 et le volume en double au volume 2.
Accédez au noeud_A en tant que superutilisateur.
Arrêtez l'application exécutée sur le noeud_A.
noeud_A# /usr/cluster/bin/scswitch -n -j rs_nfs |
Mettez le cluster principal en mode journalisation.
noeud_A# /usr/opt/SUNWesm/sbin/sndradm -n -l prem_grrép_nhlog \ /dev/vx/rdsk/groupe_périphériques/vol01 \ /dev/vx/rdsk/groupe_périphériques/vol04 sec_grrép_nhlog \ /dev/vx/rdsk/groupe_périphériques/vol01 \ /dev/vx/rdsk/groupe_périphériques/vol04 ip sync |
Au cours de l'écriture sur le volume de données du disque, le fichier bitmap figurant sur ce disque est mis à jour. Aucune réplication n'est effectuée.
Synchronisez le volume en double du cluster principal avec son volume maître.
noeud_A# /usr/opt/SUNWesm/sbin/iiadm -u s /dev/vx/rdsk/groupe_périphériques/vol02 noeud_A# /usr/opt/SUNWesm/sbin/iiadm -w /dev/vx/rdsk/groupe_périphériques/vol02 |
Synchronisez le volume en double du cluster secondaire avec son volume maître.
noeud_C# /usr/opt/SUNWesm/sbin/iiadm -u s /dev/vx/rdsk/groupe_périphériques/vol02 noeud_C# /usr/opt/SUNWesm/sbin/iiadm -w /dev/vx/rdsk/groupe_périphériques/vol02 |
Redémarrez l'application sur le noeud_A.
noeud_A# /usr/cluster/bin/scswitch -e -j rs_nfs |
Resynchronisez le volume secondaire avec le volume principal.
noeud_A# /usr/opt/SUNWesm/sbin/sndradm -n -u prem_grrép_nhlog \ /dev/vx/rdsk/groupe_périphériques/vol01 \ /dev/vx/rdsk/groupe_périphériques/vol04 sec_grrép_nhlog \ /dev/vx/rdsk/groupe_périphériques/vol01 \ /dev/vx/rdsk/groupe_périphériques/vol04 ip sync |
Cette rubrique décrit la procédure de confirmation de la configuration de la réplication de l'exemple de configuration.
Vérifiez que le cluster principal est en mode réplication et que l'autosynchronisation est activée.
noeud_A# /usr/opt/SUNWesm/sbin/sndradm -P |
Le résultat ressemble à ce qui suit :
/dev/vx/rdsk/groupe_périphériques/vol01 -> sec_grrép_nhlog:/dev/vx/rdsk/groupe_périphériques/vol01 autosync: on, max q writes:4194304, max q fbas:16384, mode:sync,ctag: groupe_périphériques, state: replicating |
En mode réplication, l'état est replicating et l'état actif de l'autosynchronisation est on. Au cours de l'écriture sur le volume principal, le volume secondaire est mis à jour par le logiciel Sun StorEdge Availability Suite 3.1.
Si le cluster principal n'est pas en mode réplication, remédiez-y de la façon suivante :
noeud_A# /usr/opt/SUNWesm/sbin/sndradm -n -u prem_grrép_nhlog \ /dev/vx/rdsk/groupe_périphériques/vol01 \ /dev/vx/rdsk/groupe_périphériques/vol04 sec_grrép_nhlog \ /dev/vx/rdsk/groupe_périphériques/vol01 \ /dev/vx/rdsk/groupe_périphériques/vol04 ip sync |
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.
machine_client# umount /rép |
Mettez hors ligne le groupe de ressources d'application sur le cluster principal.
noeud_A# /usr/cluster/bin/scswitch -n -j rs_nfs noeud_A# /usr/cluster/bin/scswitch -n -j rs_dg_nfs noeud_A# /usr/cluster/bin/scswitch -n -j prin_grnfs_nhlog noeud_A# /usr/cluster/bin/scswitch -z -g gr_nfs -h "" |
Mettez le cluster principal en mode journalisation.
noeud_A# /usr/opt/SUNWesm/sbin/sndradm -n -l prin_grrép_nhlog \ /dev/vx/rdsk/groupe_périphériques/vol01 \ /dev/vx/rdsk/groupe_périphériques/vol04 sec_grrép_nhlog \ /dev/vx/rdsk/groupe_périphériques/vol01 \ /dev/vx/rdsk/groupe_périphériques/vol04 ip sync |
Au cours de l'écriture sur le volume de données du disque, le fichier bitmap figurant sur ce disque est mis à jour. Aucune réplication n'est effectuée.
Mettez en ligne le groupe de ressources d'application sur le cluster secondaire.
noeud_C# /usr/cluster/bin/scswitch -Z -g gr_nfs |
Connectez-vous à la machine client en tant que superutilisateur.
Une invite similaire à celle-ci s'affiche :
machine_client# |
Montez le répertoire de l'application créé à l'Étape 2 sur le cluster secondaire.
machine_client# mount -o rw sec_grnfs_nhlog:/global/point_montage /rép |
Affichez le répertoire monté.
machine_client# ls /rép |
Vérifiez que le répertoire affiché à l'Étape 3 est identique à celui de l'Étape 4.
Renvoyez l'application du cluster principal vers le répertoire monté.
Mettez hors ligne le groupe de ressources d'application sur le cluster secondaire.
noeud_C# /usr/cluster/bin/scswitch -n -j rs_nfs noeud_C# /usr/cluster/bin/scswitch -n -j rs_dg_nfs noeud_C# /usr/cluster/bin/scswitch -n -j sec_grnfs_nhlog noeud_C# /usr/cluster/bin/scswitch -z -g gr_nfs -h "" |
Vérifiez que le volume global est démonté sur le cluster secondaire.
noeud_C# umount /global/point_montage |
Mettez en ligne le groupe de ressources d'application sur le cluster principal.
noeud_A# /usr/cluster/bin/scswitch -Z -g gr_nfs |
Mettez le cluster principal en mode réplication.
noeud_A# /usr/opt/SUNWesm/sbin/sndradm -n -u prin_grrép_nhlog \ /dev/vx/rdsk/groupe_périphériques/vol01 \ /dev/vx/rdsk/groupe_périphériques/vol04 sec_grrép_nhlog \ /dev/vx/rdsk/groupe_périphériques/vol01 \ /dev/vx/rdsk/groupe_périphériques/vol04 ip sync |
Au cours de l'écriture sur le volume principal, le volume secondaire est mis à jour par le logiciel Sun StorEdge Availability Suite 3.1.
Cette rubrique décrit la provocation d'un basculement et le transfert d'une aplication sur le cluster secondaire. Après une commutation ou un basculement, vous devez mettre à jour l'entrée DNS et configurer l'application pour qu'elle puisse lire et écrire sur le volume secondaire.
Mettez le cluster principal en mode journalisation.
noeud_A# /usr/opt/SUNWesm/sbin/sndradm -n -l prin_grrép_nhlog \ /dev/vx/rdsk/groupe_périphériques/vol01 \ /dev/vx/rdsk/groupe_périphériques/vol04 sec_grrép_nhlog \ /dev/vx/rdsk/groupe_périphériques/vol01 \ /dev/vx/rdsk/groupe_périphériques/vol04 ip sync |
Au cours de l'écriture sur le volume de données du disque, le fichier bitmap figurant sur ce disque est mis à jour. Aucune réplication n'est effectuée.
Confirmez que le cluster principal et le cluster secondaire sont en mode journalisation et que l'autosynchronisation est désactivée.
Sur le noeud_A, exécutez la commande suivante :
noeud_A# /usr/opt/SUNWesm/sbin/sndradm -P |
Le résultat ressemble à ce qui suit :
/dev/vx/rdsk/groupe_périphériques/vol01 -> sec_grrép_nhlog:/dev/vx/rdsk/groupe_périphériques/vol01 autosync:off, max q writes:4194304,max q fbas:16384,mode:sync,ctag: groupe_périphériques, state: logging |
Sur le noeud_C, exécutez la commande suivante :
noeud_C# /usr/opt/SUNWesm/sbin/sndradm -P |
Le résultat ressemble à ce qui suit :
/dev/vx/rdsk/groupe_périphériques/vol01 <- prin_grrép_nhlog:/dev/vx/rdsk/groupe_périphériques/vol01 autosync:off, max q writes:4194304,max q fbas:16384,mode:sync,ctag: groupe_périphériques, state: logging |
Pour le noeud_A et le noeud_C, l'état doit être logging et l'état actif de l'autosynchronisation off.
Confirmez que le cluster secondaire est prêt à prendre la relève du cluster principal.
noeud_C# /usr/sbin/fsck -y /dev/vx/rdsk/groupe_périphériques/vol01 |
Effectuez la commutation sur le cluster secondaire.
noeud_C# scswitch -Z -g gr_nfs noeud_C# scswitch -Z -g gr_nfs -h noeud_C |
Pour visualiser une illustration du mappage du DNS d'un client à un cluster, reportez-vous à la Figure 6–6.
Exécutez la commande nsupdate.
Pour de plus amples informations, consultez la page de manuel nsupdate(1M).
Supprimez le mappage du DNS actif entre la machine client et le nom d'hôte logique du groupe de ressources d'application sur le cluster principal.
> update delete machine_client A > update delete AddresseIP_1.in-addr.arpa TTL PTR machine_client |
Nom complet du client. Par exemple : mymachine.mycompany.com.
Adresse IP du nom d'hôte logique prin_grnfs_nhlog, à l'envers.
Durée de vie, en secondes. 3600 est la valeur courante.
Créez le nouveau mappage du DNS entre la machine client et le nom d'hôte logique du groupe de ressources d'application sur le cluster secondaire.
> update add machine_client TTL A AdresseIP_2 > update add AdresseIP_3.in-addr.arpa TTL PTR machine_client |
Adresse IP du nom d'hôte logique sec_grnfs_nhlog, dans l'ordre normal.
Adresse IP du nom d'hôte logique sec_grnfs_nhlog, à l'envers.
Configurez le volume secondaire à monter sur le point de montage du système de fichiers NFS.
machine_client# mount -o rw sec_grnfs_nhlog:/global/point_montage /xxx |
Le point de montage a été créé à l'Étape 1 de la Procédure de configuration du système de fichiers sur le cluster principal d'une application NFS.
Confirmez que le cluster secondaire a accès en écriture au point de montage.
machine_client# touch /xxx/data.1 machine_client# umount /xxx |