Exemple
Configuration de la réplication de données basée sur les hôtes à l'aide du logiciel Sun StorageTek Availability Suite
Cette annexe fournit une alternative à la réplication basée sur les hôtes qui n'utilise pas Oracle Solaris Cluster Geographic Edition. Utilisez Oracle Solaris Cluster Geographic Edition pour la réplication basée sur les hôtes pour simplifier la configuration et le fonctionnement de la réplication basée sur les hôtes entre clusters. Reportez-vous à la section Présentation de la réplication de données.
L'exemple de cette annexe montre la procédure de configuration de la réplication de données basée sur les hôtes entre des clusters à l'aide du logiciel Fonction Availability Suite d'Oracle Solaris. L'exemple illustre une configuration en cluster complète pour une application NFS qui fournit des informations détaillées à propos de la réalisation des tâches individuelles. Toutes les tâches doivent être exécutées dans le cluster global. L'exemple n'inclut pas toutes les étapes requises par d'autres applications ou d'autres configurations en cluster.
Si vous utilisez le contrôle d'accès basé sur les rôles (RBAC) pour accéder aux noeuds du cluster, assurez-vous de disposer des droits RBAC fournissant l'autorisation pour toutes les commandes d'Oracle Solaris Cluster. Cette série de procédures de réplication de données nécessite les autorisations RBAC Oracle Solaris Cluster suivantes :
solaris.cluster.modify
solaris.cluster.admin
solaris.cluster.read
Reportez-vous au manuel Sécurisation des utilisateurs et des processus dans Oracle Solaris 11.2 pour plus d'informations sur l'utilisation des rôles RBAC. Reportez-vous aux pages de manuel d'Oracle Solaris Cluster pour connaître les autorisations RBAC requises par chaque sous-commande d'Oracle Solaris Cluster.
Présentation du logiciel Sun StorageTek Availability Suite dans un cluster
Cette section présente la tolérance de sinistre et décrit les méthodes de réplication des données qu'utilise le logiciel Sun StorageTek Availability Suite.
La tolérance de sinistre correspond à l'aptitude à restaurer une application sur un cluster alternatif en cas de défaillance du cluster principal. La tolérance de sinistre se base sur la réplication de données et la reprise. Une reprise déplace un service d'application vers un cluster secondaire en mettant en ligne un ou plusieurs groupes de ressources et de périphériques.
Si les données sont répliquées de manière synchrone entre le cluster principal et le cluster secondaire, aucune donnée validée n'est perdue en cas de défaillance du site principal. Cependant, si les données sont répliquées de manière asynchrone, il peut arriver que des données ne soient pas répliquées vers le cluster secondaire avant la défaillance du site principal et soient donc perdues.
Méthodes de réplication de données utilisées par le logiciel Sun StorageTek Availability Suite
Cette section décrit la méthode de réplication distante et la méthode d'instantané ponctuel utilisées par le logiciel Sun StorageTek Availability Suite. Ce logiciel utilise les commandes sndradm et iiadm pour répliquer les données. Pour plus d'informations, reportez-vous aux pages de manuel sndradm(1M) et iiadm(1M).
Réplication distante
LaFigure A–1 illustre la réplication distante. Les données du volume principal du disque principal sont répliquées sur le volume principal du disque secondaire par le biais d'une connexion TCP/IP. Un bitmap miroir distant répertorie les différences entre les volumes principaux du disque principal et du disque secondaire.
Figure A-1 Réplication distante
Dans le cadre d'une réplication de données synchrone, une opération d'écriture est uniquement confirmée comme étant terminée lorsque le volume distant a été mis à jour.
Dans le cadre d'une réplication de données asynchrone, une opération d'écriture est uniquement confirmée comme étant terminée lorsque le volume distant a été mis à jour. La réplication de données asynchrone fournit une plus grande flexibilité sur de longues distances et une connexion faible débit.
La réplication distante peut être effectuée de manière synchrone en temps réel ou non. Chaque volume définit dans chaque cluster peut être configuré individuellement pour la réplication synchrone ou la réplication asynchrone.
Instantané ponctuel
La Figure A–2 présente un instantané ponctuel. Les données du volume principal de chaque disque sont copiées sur le volume shadow du même disque. Le bitmap ponctuel répertorie les différences entre le volume principal et le volume shadow. Lorsque les données sont copiées sur le volume shadow, le bitmap ponctuel est réinitialisé.
Figure A-2 Instantané ponctuel
La réplication dans l'exemple de configuration
La Figure A–3 montre l'utilisation de la réplication distante et de l'instantané ponctuel dans cet exemple de configuration.
Figure A-3 La réplication dans l'exemple de configuration
Instructions pour la configuration de la réplication de données basée sur les hôtes entre les clusters
Cette section fournit des instructions pour la configuration de la réplication de données entre des clusters. Cette section contient également des conseils pour la configuration des groupes de ressources de réplication et des groupes de ressources d'application. Utilisez ces instructions lors de la configuration de la réplication de données pour votre cluster.
Cette section traite des sujets suivants :
Configuration des groupes de ressources de réplication
Les groupes de ressources de réplication colocalisent le groupe de périphériques sous le contrôle du logiciel Sun StorageTek Availability Suite à l'aide de la ressource de nom d'hôte logique. Un nom d'hôte logique doit exister à chaque extrémité du flux de réplication de données et être sur le même noeud de cluster qui fait office de chemin d'E/S principal vers le périphérique. Un groupe de ressources de réplication doit disposer des caractéristiques suivantes :
Etre un groupe de ressources de basculement
Une ressource de basculement peut uniquement être exécutée sur un seul noeud à la fois. En cas de basculement, les ressources de basculement prennent part au basculement.
Avoir une ressource de nom d'hôte logique
Un nom d'hôte logique est hébergé sur un noeud de chaque cluster (principal et secondaire) et sert à fournir des adresses source et cible pour le flux de réplication de données du logiciel Sun StorageTek Availability Suite.
Avoir une ressource HAStoragePlus.
La ressource HAStoragePlus force le basculement du groupe de périphériques lorsque le groupe de ressources de réplication est commuté ou basculé. Le logiciel Oracle Solaris Cluster force également le basculement du groupe de ressources de réplication lorsque le groupe de périphériques est commuté. De cette manière, le groupe de ressources de réplication et le groupe de périphériques sont toujours colocalisés ou contrôlés par le même noeud.
Les propriétés d'extension suivantes doivent être définies dans la ressource HAStoragePlus :
GlobalDevicePaths. Cette propriété d'extension définit le groupe de périphériques auquel appartient un volume.
AffinityOn property = True. Cette propriété d'extension provoque 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 s'appelle une commutation d'affinité.
Pour plus d'informations sur HAStoragePlus, reportez-vous à la page de manuel SUNW.HAStoragePlus(5).
Etre nommé d'après le groupe de périphériques avec lequel il est colocalisé, suivi de -stor-rg
Par exemple, devgrp-stor-rg.
Etre en ligne sur le cluster principal et le cluster secondaire
Configuration des groupes de ressources d'application
Pour être hautement disponible, une application doit être gérée en tant que ressource dans un groupe de ressources d'application. Un groupe de ressources d'application peut être configuré pour une application de basculement ou une application évolutive.
La propriété d'extension ZPoolsSearchDir doit être définie dans la ressource HAStoragePlus. Cette propriété d'extension est nécessaire pour utiliser le système de fichiers ZFS.
Les ressources d'application et les groupes de ressources d'application configurés sur le cluster principal doivent aussi être configurés sur le cluster secondaire. De plus, les données auxquelles accèdent les ressources d'application doivent être répliquées sur le cluster secondaire.
Cette section fournit des instructions pour la configuration des groupes de ressources d'application suivants :
Configuration des groupes de ressources pour une application de basculement
Configuration des groupes de ressources pour une application évolutive
Configuration des groupes de ressources pour une application de basculement
Dans une application de basculement, une application s'exécute sur un noeud à la fois. Si ce noeud échoue, l'application bascule sur un autre noeud du même cluster. Un groupe de ressources pour une application de basculement doit disposer des caractéristiques suivantes :
Avoir une ressource HAStoragePlus pour forcer le basculement du système de fichiers ou zpool lorsque le groupe de ressources d'application est commuté ou basculé.
Le groupe de périphériques est colocalisé avec le groupe de ressources de réplication et le groupe de ressources d'application. Par conséquent, le basculement du groupe de ressources d'application force le basculement 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 qu'un basculement du groupe de périphériques ou du groupe de ressources de réplication ne provoque pas le basculement du groupe de ressources d'application.
Si les données d'application sont globalement montées, la présence d'une ressource HAStoragePlus dans le groupe de ressources d'application n'est pas nécessaire mais recommandée.
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.
Pour plus d'informations sur HAStoragePlus, reportez-vous à la page de manuel SUNW.HAStoragePlus(5).
Doit ê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 le cluster secondaire prend la place du cluster principal.
La Figure A–4 illustre la configuration d'un groupe de ressources d'application et d'un groupe de ressources de réplication dans une application de basculement.
Figure A-4 Configuration des groupes de ressources dans une application de basculement
Configuration des groupes de ressources pour une application évolutive
Dans une application évolutive, une application s'exécute sur plusieurs noeuds pour créer un service logique unique. Si un noeud exécutant une application évolutive échoue, le basculement ne s'effectue pas. L'application continue de s'exécuter sur les autres noeuds.
Lorsqu'une application évolutive est gérée en tant que ressource dans un groupe de ressources d'application, il n'est pas nécessaire de colocaliser le groupe de ressources d'application et le groupe de périphériques. Par conséquent, il n'est pas nécessaire de créer une ressource HAStoragePlus pour le groupe de ressources d'application.
Avoir une dépendance sur le groupe de ressources d'adresses partagées
Les noeuds qui exécutent l'application évolutive utilisent l'adresse partagée pour distribuer les données entrantes.
Etre en ligne sur le cluster principal et hors ligne sur le cluster secondaire
Un groupe de ressources pour une application évolutive doit disposer des caractéristiques suivantes :
La Figure A–5 illustre la configuration des groupes de ressources dans une application évolutive.
Figure A-5 Configuration des groupes de ressources dans une application évolutive
Instructions pour la gestion d'une reprise
Si le cluster principal échoue, l'application doit être commutée sur le cluster secondaire dès que possible. Pour activer le cluster secondaire pour qu'il récupère, le DNS doit être mis à jour.
Les clients utilisent DNS pour faire correspondre le nom d'hôte logique d'une application à une adresse IP. Après une reprise, pendant laquelle une application est déplacée vers un cluster secondaire, les informations DNS doivent être mises à jour pour refléter la correspondance entre le nom d'hôte logique de l'application et la nouvelle adresse IP.
Figure A-6 Mappage DNS d'un client à un cluster
Pour mettre le DNS à jour, utilisez la commande nsupdate. Pour plus d'informations, reportez-vous à la page de manuelnsupdate(1M). Pour un exemple de gestion d'une reprise, reportez-vous à la section Exemple de gestion d'une reprise.
Après réparation, le cluster principal peut être remis en ligne. Pour repasser au cluster principal d'origine, effectuez les tâches suivantes :
Synchronisez le cluster principal au cluster secondaire pour garantir que le volume principal est à jour. Vous pouvez atteindre ce résultat en arrêtant le groupe de ressources sur le noeud secondaire pour que le flux de données de réplication puisse se purger.
Inversez la direction de la réplication des données pour que le cluster principal d'origine réplique à nouveau les données vers le cluster secondaire d'origine.
Démarrez le groupe de ressources sur le cluster principal.
Mettez le DNS à jour pour que les clients puissent accéder à l'application sur le cluster principal.
Liste des tâches : exemple d'une configuration de réplication de données
Le Table A–1 dresse la liste des tâches de cet exemple relatives à la configuration de la réplication de données pour une application NFS à l'aide du logiciel Sun StorageTek Availability Suite.
|
Connexion et installation des clusters
La Figure A–7 illustre la configuration en cluster utilisée par l'exemple de configuration. Le cluster secondaire de l'exemple de configuration contient un noeud, mais d'autres configurations en cluster peuvent être utilisées.
Figure A-7 Exemple de configuration en cluster
Le Table A–2 récapitule le matériel et les logiciels requis par l'exemple de configuration. Le SE Oracle Solaris, le logiciel Oracle Solaris Cluster et le gestionnaire de volumes doivent être installés sur les noeuds du cluster avant le logiciel Sun StorageTek Availability Suite et les patchs.
|
Exemple de configuration des groupes de périphériques et des groupes de ressources
Cette section décrit la configuration des groupes de périphériques et des groupes de ressources pour une application NFS. Pour plus d'informations, reportez-vous aux sections Configuration des groupes de ressources de réplication et Configuration des groupes de ressources d'application.
Configuration d'un groupe de périphériques sur le cluster principal
Configuration d'un groupe de périphérique sur le cluster secondaire
Configuration du système de fichiers sur le cluster principal pour l'application NFS
Configuration du système de fichiers sur le cluster secondaire pour l'application NFS
Création d'un groupe de ressources de réplication sur le cluster principal
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 primaire
Création d'un groupe de ressources d'application NFS sur le cluster secondaire
Cette section détaille les procédures suivantes :
Le tableau suivant répertorie les noms des groupes et des ressources créés par l'exemple de configuration.
|
A l'exception de devgrp-stor-rg, les noms des groupes et des ressources sont des exemples de noms qui peuvent être modifiés en fonction des besoins. Le groupe de ressource de réplication doit avoir un nom au format devicegroupname-stor-rg.
Pour plus d'informations sur le logiciel Solaris Volume Manager, reportez-vous au Chapitre 4, Configuration du logiciel Solaris Volume Manager du manuel Guide d’installation du logiciel Oracle Solaris Cluster .
Configuration d'un groupe de périphériques sur le cluster principal
Avant de commencer
Assurez-vous d'avoir effectué les tâches suivantes :
Lire les instructions et les conditions requises dans les sections suivantes :
Définir les clusters principal et secondaire comme décrit dans Connexion et installation des clusters.
- Accédez au noeud nodeA en prenant le rôle octroyant une autorisation RBAC solaris.cluster.modify.
Le noeud nodeA est le premier noeud du cluster principal. Pour un rappel de quel noeud correspond à nodeA, reportez-vous à la Figure A–7.
- Créez un ensemble de métadonnées pour contenir les données NFS et la réplication associée.
nodeA# metaset -s nfsset a -h nodeA nodeB
- Ajoutez des disques à l'ensemble de métadonnées.
nodeA# metaset -s nfsset -a /dev/did/dsk/d6 /dev/did/dsk/d7
- Ajoutez des médiateurs à l'ensemble de métadonnées.
nodeA# metaset -s nfsset -a -m nodeA nodeB
- Créez les volumes requis (ou métapériphériques).
Créez deux composants d'un miroir.
nodeA# metainit -s nfsset d101 1 1 /dev/did/dsk/d6s2 nodeA# metainit -s nfsset d102 1 1 /dev/did/dsk/d7s2
Créez le miroir avec un des composants :
nodeA# metainit -s nfsset d100 -m d101
Attachez l'autre composant au miroir et autorisez-le à synchroniser :
nodeA# metattach -s nfsset d100 d102
Créez des partitions logicielles à partir du miroir en suivant ces exemples :
d200 - Données NFS (volume principal) :
nodeA# metainit -s nfsset d200 -p d100 50G
d201 - Volume de copie ponctuel pour les données NFS :
nodeA# metainit -s nfsset d201 -p d100 50G
d202 - Volume bitmap ponctuel :
nodeA# metainit -s nfsset d202 -p d100 10M
d203 - Volume bitmap shadow distant :
nodeA# metainit -s nfsset d203 -p d100 10M
d204 : le volume pour les informations de configuration d'Oracle Solaris Cluster SUNW.NFS :
nodeA# metainit -s nfsset d204 -p d100 100M
- Créez des systèmes de fichiers pour les données NFS et le volume de configuration.
nodeA# yes | newfs /dev/md/nfsset/rdsk/d200 nodeA# yes | newfs /dev/md/nfsset/rdsk/d204
Etapes suivantes
Passez à la section Configuration d'un groupe de périphérique sur le cluster secondaire.
Configuration d'un groupe de périphérique sur le cluster secondaire
Avant de commencer
Effectuez la procédure Configuration d'un groupe de périphériques sur le cluster principal
- Accédez au noeud nodeC en prenant le rôle octroyant l'autorisation RBAC solaris.cluster.modify.
- Créez un ensemble de métadonnées pour contenir les données NFS et la réplication associée.
nodeC# metaset -s nfsset a -h nodeC
- Ajoutez des disques à l'ensemble de métadonnées.
Dans l'exemple suivant, partez du principe que les numéros DID de disque sont différents.
nodeC# metaset -s nfsset -a /dev/did/dsk/d3 /dev/did/dsk/d4
Remarque - Les médiateurs ne sont pas requis sur un cluster de noeud simple. - Créez les volumes requis (ou métapériphériques).
Créez deux composants d'un miroir.
nodeC# metainit -s nfsset d101 1 1 /dev/did/dsk/d3s2 nodeC# metainit -s nfsset d102 1 1 /dev/did/dsk/d4s2
Créez le miroir avec un des composants :
nodeC# metainit -s nfsset d100 -m d101
Attachez l'autre composant au miroir et autorisez-le à synchroniser :
metattach -s nfsset d100 d102
Créez des partitions logicielles à partir du miroir en suivant ces exemples :
d200 - Volume principal de données NFS :
nodeC# metainit -s nfsset d200 -p d100 50G
d201 - Volume de copie ponctuel pour les données NFS :
nodeC# metainit -s nfsset d201 -p d100 50G
d202 - Volume bitmap ponctuel :
nodeC# metainit -s nfsset d202 -p d100 10M
d203 - Volume bitmap shadow distant :
nodeC# metainit -s nfsset d203 -p d100 10M
d204 : le volume pour les informations de configuration d'Oracle Solaris Cluster SUNW.NFS :
nodeC# metainit -s nfsset d204 -p d100 100M
- Créez des systèmes de fichiers pour les données NFS et le volume de configuration.
nodeC# yes | newfs /dev/md/nfsset/rdsk/d200 nodeC# yes | newfs /dev/md/nfsset/rdsk/d204
Etapes suivantes
Passez à la section Configuration du système de fichiers sur le cluster principal pour l'application NFS
Configuration du système de fichiers sur le cluster principal pour l'application NFS
Avant de commencer
Effectuez la procédure dans Configuration d'un groupe de périphérique sur le cluster secondaire
- Sur les noeuds nodeA et nodeB, prenez le rôle octroyant une autorisation RBAC solaris.cluster.admin.
- Sur nodeA et nodeB, créez un répertoire de point de montage pour le système de fichiers NFS.
Par exemple :
nodeA# mkdir /global/mountpoint
- Sur nodeA et nodeB, configurez le volume principal à ne pas monter automatiquement sur le point de montage.
Ajoutez ou remplacez le texte suivant dans le fichier /etc/vfstab sur nodeA et nodeB. Le texte doit se trouver sur une seule ligne.
/dev/md/nfsset/dsk/d200 /dev/md/nfsset/rdsk/d200 \ /global/mountpoint ufs 3 no global,logging
- Sur nodeA et nodeB, créez un point de montage pour le métapériphérique d204.
L'exemple suivant crée le point de montage /global/etc.
nodeA# mkdir /global/etc
- Sur nodeA et nodeB, configurez le métapériphérique d204 à monter automatiquement sur le point de montage.
Ajoutez ou remplacez le texte suivant dans le fichier /etc/vfstab sur nodeA et nodeB. Le texte doit se trouver sur une seule ligne.
/dev/md/nfsset/dsk/d204 /dev/md/nfsset/rdsk/d204 \ /global/etc ufs 3 yes global,logging
- Montez le métapériphérique d204 sur nodeA.
nodeA# mount /global/etc
- Créez les fichiers de configuration et les informations pour le service de données NFS d'Oracle Solaris Cluster HA.
- Créez un répertoire nommé /global/etc/SUNW.nfs sur nodeA.
nodeA# mkdir -p /global/etc/SUNW.nfs
- Créez le fichier /global/etc/SUNW.nfs/dfstab.nfs-rs sur nodeA.
nodeA# touch /global/etc/SUNW.nfs/dfstab.nfs-rs
- Ajoutez la ligne suivante au fichier /global/etc/SUNW.nfs/dfstab.nfs-rs sur nodeA.
share -F nfs -o rw -d "HA NFS" /global/mountpoint
- Créez un répertoire nommé /global/etc/SUNW.nfs sur nodeA.
Etapes suivantes
Passez à la section Configuration du système de fichiers sur le cluster secondaire pour l'application NFS.
Configuration du système de fichiers sur le cluster secondaire pour l'application NFS
Avant de commencer
Effectuez la procédure Configuration du système de fichiers sur le cluster principal pour l'application NFS
- Sur le noeud nodeC, prenez le rôle octroyant une autorisation RBAC solaris.cluster.admin.
- Sur nodeC, créez un répertoire de point de montage pour le système de fichiers NFS.
Par exemple :
nodeC# mkdir /global/mountpoint
- Sur nodeC, configurez le volume principal à monter automatiquement sur le point de montage.
Ajoutez ou remplacez le texte suivant dans le fichier /etc/vfstab sur nodeC. Le texte doit se trouver sur une seule ligne.
/dev/md/nfsset/dsk/d200 /dev/md/nfsset/rdsk/d200 \ /global/mountpoint ufs 3 yes global,logging
- Montez le métapériphérique d204 sur nodeA.
nodeC# mount /global/etc
- Créez les fichiers de configuration et les informations pour le service de données NFS d'Oracle Solaris Cluster HA.
- Créez un répertoire nommé /global/etc/SUNW.nfs sur nodeA.
nodeC# mkdir -p /global/etc/SUNW.nfs
- Créez le fichier /global/etc/SUNW.nfs/dfstab.nfs-rs sur nodeA.
nodeC# touch /global/etc/SUNW.nfs/dfstab.nfs-rs
- Ajoutez la ligne suivante au fichier /global/etc/SUNW.nfs/dfstab.nfs-rs sur nodeA.
share -F nfs -o rw -d "HA NFS" /global/mountpoint
- Créez un répertoire nommé /global/etc/SUNW.nfs sur nodeA.
Etapes suivantes
Passez à la section Création d'un groupe de ressources de réplication sur le cluster principal
Création d'un groupe de ressources de réplication sur le cluster principal
Avant de commencer
Effectuez la procédure Configuration du système de fichiers sur le cluster secondaire pour l'application NFS
Assurez-vous que le fichier /etc/netmasks dispose d'un sous-réseau d'adresse IP et d'entrées de masque de réseau pour tous les noms d'hôtes logiques. Si nécessaire, modifiez le fichier /etc/netmasks pour ajouter les entrées manquantes.
- Accédez au noeud nodeA avec le rôle octroyant les autorisations RBAC solaris.cluster.modify, solaris.cluster.admin et solaris.cluster.read.
- Enregistrez le type de ressource SUNW.HAStoragePlus.
nodeA# clresourcetype register SUNW.HAStoragePlus
- Créez un groupe de ressources de réplication pour le groupe de périphériques.
nodeA# clresourcegroup create -n nodeA,nodeB devgrp-stor-rg
- -n nodeA,nodeB
Permet d'indiquer que les noeuds de cluster nodeA et nodeB peuvent contenir le groupe de ressources de réplication.
- devgrp-stor-rg
Le nom du groupe de ressources de réplication. Dans ce nom, devgrp indique le nom du groupe de périphériques.
- Ajoutez une ressource SUNW.HAStoragePlus au groupe de ressources de réplication.
nodeA# clresource create -g devgrp-stor-rg -t SUNW.HAStoragePlus \ -p GlobalDevicePaths=nfsset \ -p AffinityOn=True \ devgrp-stor
- –g
Spécifie le groupe de ressources auquel la ressource est ajoutée.
- -p GlobalDevicePaths=
Indique le groupe de périphériques sur lequel compte le logiciel Sun StorageTek Availability Suite.
- -p AffinityOn=True
Indique que la ressource SUNW.HAStoragePlus doit effectuer une commutation d'affinité pour les périphériques globaux et les systèmes de fichiers du cluster définis par -p GlobalDevicePaths=. Par conséquent, lorsque le groupe de ressources de réplication bascule ou est commuté, le groupe de périphériques associé est commuté.
Pour plus d'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# clreslogicalhostname create -g devgrp-stor-rg lhost-reprg-prim
Le nom d'hôte logique pour le groupe de ressources de réplication sur le cluster principal se nomme lhost-reprg-prim.
- Activez les ressources, gérez le groupe de ressources et mettez-le en ligne.
nodeA# clresourcegroup online -emM -n nodeA devgrp-stor-rg
- –e
Active les ressources associées.
- –M
Gère le groupe de ressources.
- –n
Indique le noeud sur lequel mettre le groupe de ressources en ligne.
- Assurez-vous que le groupe de ressources est en ligne.
nodeA# clresourcegroup status devgrp-stor-rg
Examinez le champ de l'état du groupe de ressources pour confirmer que le groupe de ressources de réplication est en ligne sur nodeA.
Etapes suivantes
Passez à la section Création d'un groupe de ressources de réplication sur le cluster secondaire.
Création d'un groupe de ressources de réplication sur le cluster secondaire
Avant de commencer
Effectuez la procédure Création d'un groupe de ressources de réplication sur le cluster principal.
Assurez-vous que le fichier /etc/netmasks dispose d'un sous-réseau d'adresse IP et d'entrées de masque de réseau pour tous les noms d'hôtes logiques. Si nécessaire, modifiez le fichier /etc/netmasks pour ajouter les entrées manquantes.
- Accédez au noeud nodeC avec le rôle octroyant les autorisations RBAC solaris.cluster.modify, solaris.cluster.admin et solaris.cluster.read.
- Enregistrez SUNW.HAStoragePlus en tant que type de ressource.
nodeC# clresourcetype register SUNW.HAStoragePlus
- Créez un groupe de ressources de réplication pour le groupe de périphériques.
nodeC# clresourcegroup create -n nodeC devgrp-stor-rg
- create
Crée le groupe de ressources.
- –n
Spécifie la liste de noeuds pour le groupe de ressources.
- devgrp
Le nom du groupe de périphériques.
- devgrp-stor-rg
Le nom du groupe de ressources de réplication.
- Ajoutez une ressource SUNW.HAStoragePlus au groupe de ressources de réplication.
nodeC# clresource create \ -t SUNW.HAStoragePlus \ -p GlobalDevicePaths=nfsset \ -p AffinityOn=True \ devgrp-stor
- create
Crée la ressource.
- –t
Spécifie le type de réplication.
- -p GlobalDevicePaths=
Spécifie le groupe de périphériques sur lequel le logiciel Sun StorageTek Availability Suite s'appuie.
- -p AffinityOn=True
Indique que la ressource SUNW.HAStoragePlus doit effectuer une commutation d'affinité pour les périphériques globaux et les systèmes de fichiers du cluster définis par -p GlobalDevicePaths=. Par conséquent, lorsque le groupe de ressources de réplication bascule ou est commuté, le groupe de périphériques associé est commuté.
- devgrp-stor
La ressource HAStoragePlus pour le groupe de ressources de réplication.
Pour plus d'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# clreslogicalhostname create -g devgrp-stor-rg lhost-reprg-sec
Le nom d'hôte logique pour le groupe de ressources de réplication sur le cluster secondaire se nomme lhost-reprg-sec.
- Activez les ressources, gérez le groupe de ressources et mettez-le en ligne.
nodeC# clresourcegroup online -eM -n nodeC devgrp-stor-rg
- online
Met en ligne.
- –e
Active les ressources associées.
- –M
Gère le groupe de ressources.
- –n
Indique le noeud sur lequel mettre le groupe de ressources en ligne.
- Assurez-vous que le groupe de ressources est en ligne.
nodeC# clresourcegroup status devgrp-stor-rg
Examinez le champ de l'état du groupe de ressources pour confirmer que le groupe de ressources de réplication est en ligne sur nodeC.
Etapes suivantes
Passez à la section Création d'un groupe de ressources d'application NFS sur le cluster primaire.
Création d'un groupe de ressources d'application NFS sur le cluster primaire
Cette procédure décrit la création des groupes de ressources d'application pour NFS. Cette procédure est spécifique à cette application et ne peut pas être utilisée pour un autre type d'application.
Avant de commencer
Effectuez la procédure Création d'un groupe de ressources de réplication sur le cluster secondaire.
Assurez-vous que le fichier /etc/netmasks dispose d'un sous-réseau d'adresse IP et d'entrées de masque de réseau pour tous les noms d'hôtes logiques. Si nécessaire, modifiez le fichier /etc/netmasks pour ajouter les entrées manquantes.
- Accédez au noeud nodeA avec le rôle octroyant les autorisations RBAC solaris.cluster.modify, solaris.cluster.admin et solaris.cluster.read.
-
Enregistrez SUNW.nfs en tant que type de ressource.
nodeA# clresourcetype register SUNW.nfs
-
Si SUNW.HAStoragePlus n'a pas été enregistré en tant que type de ressource, enregistrez-le.
nodeA# clresourcetype register SUNW.HAStoragePlus
-
Créez un groupe de ressources d'application pour le service NFS.
nodeA# clresourcegroup create \ -p Pathprefix=/global/etc \ -p Auto_start_on_new_cluster=False \ -p RG_affinities=+++devgrp-stor-rg \ nfs-rg
- Pathprefix=/global/etc
-
Spécifie le répertoire dans lequel les ressources du groupe peuvent écrire des fichiers administratifs.
- Auto_start_on_new_cluster=False
-
Spécifie que le groupe de ressources d'application n'est pas démarré automatiquement.
- RG_affinities=+++devgrp-stor-rg
-
Spécifie le groupe de ressources avec lequel le groupe de ressources d'application doit être colocalisé. Dans cet exemple, le groupe de ressources d'application doit être colocalisé avec le groupe de ressources de réplication devgrp-stor-rg.
Si le groupe de ressources de réplication est commuté vers un nouveau noeud principal, le groupe de ressources d'application est automatiquement commuté. Cependant, les tentatives de commutation du groupe de ressources d'application vers un nouveau noeud principal sont bloquées car cette action annule les exigences de colocation.
- nfs-rg
-
Le nom du groupe de ressources d'application.
-
Ajoutez une ressource SUNW.HAStoragePlus au groupe de ressources d'application.
nodeA# clresource create -g nfs-rg \ -t SUNW.HAStoragePlus \ -p FileSystemMountPoints=/global/mountpoint \ -p AffinityOn=True \ nfs-dg-rs
- create
-
Crée la ressource.
- –g
-
Spécifie le groupe de ressources auquel la ressource est ajoutée.
- -t SUNW.HAStoragePlus
-
Indique que la ressource est de type SUNW.HAStoragePlus.
- -p FileSystemMountPoints=/global/mountpoint
-
Spécifie que le point de montage pour le système de fichiers est global.
- -p AffinityOn=True
-
Indique que la ressource d'application doit effectuer une commutation d'affinité pour les périphériques globaux et les systèmes de fichiers de cluster définis par -p FileSystemMountPoints. Par conséquent, lorsque le groupe de ressources d'application bascule ou est commuté, le groupe de périphériques associé est commuté.
- nfs-dg-rs
-
Le nom de la ressource HAStoragePlus pour l'application NFS.
Pour plus d'informations à propos de 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# clreslogicalhostname create -g nfs-rg \ lhost-nfsrg-prim
Le nom d'hôte logique du groupe de ressources d'application sur le cluster principal se nomme lhost-nfsrg-prim.
-
Créez le fichier de configuration dfstab.resource-name et placez-le dans le sous-répertoire SUNW.nfs du répertoire Pathprefix du groupe de ressources conteneur.
-
Créez un répertoire nommé SUNW.nfs sur le noeud nodeA.
nodeA# mkdir -p /global/etc/SUNW.nfs
-
Créez un fichier dfstab.resource-name sur le noeud nodeA.
nodeA# touch /global/etc/SUNW.nfs/dfstab.nfs-rs
-
Ajoutez la ligne suivante au fichier /global/etc/SUNW.nfs/dfstab.nfs-rs sur nodeA.
share -F nfs -o rw -d "HA NFS" /global/mountpoint
-
Créez un répertoire nommé SUNW.nfs sur le noeud nodeA.
-
Mettez le groupe de ressources d'application en ligne.
nodeA# clresourcegroup online -M -n nodeA nfs-rg
- online
-
Met le groupe de ressources en ligne.
- –e
-
Permet d'activer les ressources associées.
- –M
-
Gère le groupe de ressources.
- –n
-
Indique le noeud sur lequel mettre le groupe de ressources en ligne.
- nfs-rg
-
Le nom du groupe de ressources.
-
Assurez-vous que le groupe de ressources d'application est en ligne.
nodeA# clresourcegroup status
Examinez le champ de l'état du groupe de ressources pour déterminer si le groupe de ressources d'application est en ligne pour nodeA et nodeB.
Etapes suivantes
Passez à la section Création d'un groupe de ressources d'application NFS sur le cluster secondaire.
Création d'un groupe de ressources d'application NFS sur le cluster secondaire
Avant de commencer
Effectuez la procédure Création d'un groupe de ressources d'application NFS sur le cluster primaire.
Assurez-vous que le fichier /etc/netmasks dispose d'un sous-réseau d'adresse IP et d'entrées de masque de réseau pour tous les noms d'hôtes logiques. Si nécessaire, modifiez le fichier /etc/netmasks pour ajouter les entrées manquantes.
- Accédez au noeud nodeC avec le rôle octroyant les autorisations RBAC solaris.cluster.modify, solaris.cluster.admin et solaris.cluster.read.
- Enregistrez SUNW.nfs en tant que type de ressource.
nodeC# clresourcetype register SUNW.nfs
- Si SUNW.HAStoragePlus n'a pas été enregistré en tant que type de ressource, enregistrez-le.
nodeC# clresourcetype register SUNW.HAStoragePlus
- Créez un groupe de ressources d'application pour le groupe de périphériques.
nodeC# clresourcegroup create \ -p Pathprefix=/global/etc \ -p Auto_start_on_new_cluster=False \ -p RG_affinities=+++devgrp-stor-rg \ nfs-rg
- create
Crée le groupe de ressources.
- –p
Spécifie une propriété du groupe de ressources.
- Pathprefix=/global/etc
Spécifie un répertoire dans lequel les ressources du groupe peuvent écrire des fichiers administratifs.
- Auto_start_on_new_cluster=False
Spécifie que le groupe de ressources d'application n'est pas démarré automatiquement.
- RG_affinities=+++devgrp-stor-rg
Spécifie le groupe de ressources avec lequel le groupe de ressources d'application doit être colocalisé. Dans cet exemple, le groupe de ressources d'application doit être colocalisé avec le groupe de ressources de réplication devgrp-stor-rg.
Si le groupe de ressources de réplication est commuté vers un nouveau noeud principal, le groupe de ressources d'application est automatiquement commuté. Cependant, les tentatives de commutation du groupe de ressources d'application vers un nouveau noeud principal sont bloquées car cette action annule les exigences de colocation.
- nfs-rg
Le nom du groupe de ressources d'application.
- Ajoutez une ressource SUNW.HAStoragePlus au groupe de ressources d'application.
nodeC# clresource create -g nfs-rg \ -t SUNW.HAStoragePlus \ -p FileSystemMountPoints=/global/mountpoint \ -p AffinityOn=True \ nfs-dg-rs
- create
Crée la ressource.
- –g
Spécifie le groupe de ressources auquel la ressource est ajoutée.
- -t SUNW.HAStoragePlus
Indique que la ressource est de type SUNW.HAStoragePlus.
- –p
Spécifie une propriété de la ressource.
- FileSystemMountPoints=/global/mountpoint
Spécifie que le point de montage pour le système de fichiers est global.
- AffinityOn=True
Indique que la ressource d'application doit effectuer une commutation d'affinité pour les périphériques globaux et les systèmes de fichiers de cluster définis par -p FileSystemMountPoints=. Par conséquent, lorsque le groupe de ressources d'application bascule ou est commuté, le groupe de périphériques associé est commuté.
- nfs-dg-rs
Le nom de la ressource HAStoragePlus pour l'application NFS.
- Ajoutez une ressource de nom d'hôte logique au groupe de ressources d'application.
nodeC# clreslogicalhostname create -g nfs-rg \ lhost-nfsrg-sec
Le nom d'hôte logique du groupe de ressources d'application sur le cluster secondaire se nomme lhost-nfsrg-sec.
- Ajoutez une ressource NFS au groupe de ressources d'application.
nodeC# clresource create -g nfs-rg \ -t SUNW.nfs -p Resource_dependencies=nfs-dg-rs nfs-rg
- Si le volume global est monté sur le cluster principal, démontez le volume global du cluster secondaire.
nodeC# umount /global/mountpoint
Si le volume est monté sur un cluster secondaire, la synchronisation échoue.
Etapes suivantes
Passez à la section Exemple d'activation de la réplication de données.
Exemple d'activation de la réplication de données
Cette section décrit l'activation de la réplication de données pour l'exemple de configuration. Cette section utilise les commandes sndradm et iiadm du logiciel Sun StorageTek Availability Suite. Pour plus d'informations sur ces commandes, reportez-vous à la documentation de. Sun StorageTek Availability Suite
Cette section détaille les procédures suivantes :
Activation de la réplication sur le cluster principal
- Accédez au noeud nodeA avec le rôle octroyant l'autorisation RBAC solaris.cluster.read.
- Videz toutes les transactions.
nodeA# lockfs -a -f
- Confirmez que les noms d'hôtes logiques lhost-reprg-prim et lhost-reprg-sec sont en ligne.
nodeA# clresourcegroup status nodeC# clresourcegroup status
Examinez le champ de l'état du groupe de ressources.
- Activez la réplication distante du cluster principal vers le cluster secondaire.
Cette étape active la réplication du cluster principal vers le cluster secondaire. Cette étape active la réplication du volume principal (d200) du cluster principal vers le volume principal (d200) du cluster secondaire. De plus, cette étape active la réplication vers le bitmap miroir distant sur d203.
Si le cluster principal et le cluster secondaire ne sont pas synchronisés, exécutez cette commande :
nodeA# /usr/sbin/sndradm -n -e lhost-reprg-prim \ /dev/md/nfsset/rdsk/d200 \ /dev/md/nfsset/rdsk/d203 lhost-reprg-sec \ /dev/md/nfsset/rdsk/d200 \ /dev/md/nfsset/rdsk/d203 ip sync
Si le cluster principal et le cluster secondaire sont synchronisés, exécutez cette commande :
nodeA# /usr/sbin/sndradm -n -E lhost-reprg-prim \ /dev/md/nfsset/rdsk/d200 \ /dev/md/nfsset/rdsk/d203 lhost-reprg-sec \ /dev/md/nfsset/rdsk/d200 \ /dev/md/nfsset/rdsk/d203 ip sync
- Activez la synchronisation automatique.
Exécutez cette commande pour le logiciel Sun StorageTek Availability Suite :
nodeA# /usr/sbin/sndradm -n -a on lhost-reprg-prim \ /dev/md/nfsset/rdsk/d200 \ /dev/md/nfsset/rdsk/d203 lhost-reprg-sec \ /dev/md/nfsset/rdsk/d200 \ /dev/md/nfsset/rdsk/d203 ip sync
Cette étape active la synchronisation automatique. Lorsque l'état actif de la synchronisation automatique est défini sur activé, les ensembles de volumes sont resynchronisés si le système se réinitialise ou si une panne se produit.
- Vérifiez que le cluster se trouve en mode de journalisation.
Utilisez la commande suivante pour le logiciel Sun StorageTek Availability Suite :
nodeA# /usr/sbin/sndradm -P
La sortie doit ressembler à ce qui suit :
/dev/md/nfsset/rdsk/d200 -> lhost-reprg-sec:/dev/md/nfsset/rdsk/d200 autosync: off, max q writes:4194304, max q fbas:16384, mode:sync,ctag: devgrp, state: logging
En mode de journalisation, l'état est journalisation et l'état actif de la synchronisation est désactivé. Lorsque quelque chose est écrit sur le volume de données du disque, le fichier bitmap sur le même disque est mis à jour.
- Activez l'instantané ponctuel.
Utilisez la commande suivante pour le logiciel Sun StorageTek Availability Suite :
nodeA# /usr/sbin/iiadm -e ind \ /dev/md/nfsset/rdsk/d200 \ /dev/md/nfsset/rdsk/d201 \ /dev/md/nfsset/rdsk/d202 nodeA# /usr/sbin/iiadm -w \ /dev/md/nfsset/rdsk/d201
Cette étape permet au volume principal du cluster principal d'être copié sur le volume shadow du même cluster. Le volume principal, le volume shadow et le volume bitmap ponctuel doivent se trouver dans le même groupe de périphériques. Dans cet exemple, le volume maître est d200, le volume en double est d201 et le volume bitmap ponctuel est d203.
- Joignez l'instantané ponctuel au jeu de mise en miroir distant.
Utilisez la commande suivante pour le logiciel Sun StorageTek Availability Suite :
nodeA# /usr/sbin/sndradm -I a \ /dev/md/nfsset/rdsk/d200 \ /dev/md/nfsset/rdsk/d201 \ /dev/md/nfsset/rdsk/d202
Cette étape associe l'instantané ponctuel au jeu de volume de mise en miroir distant. Le logiciel Sun StorageTek Availability Suite garantit la prise d'un instantané ponctuel avant que la réplication distante ne puisse avoir lieu.
Etapes suivantes
Passez à la section Activation de la réplication sur le cluster secondaire.
Activation de la réplication sur le cluster secondaire
Avant de commencer
Effectuez la procédure Activation de la réplication sur le cluster principal.
- Accédez au noeud nodeC en tant que rôle root.
- Videz toutes les transactions.
nodeC# lockfs -a -f
- Activez la réplication distante du cluster principal vers le cluster secondaire.
Utilisez la commande suivante pour le logiciel Sun StorageTek Availability Suite :
nodeC# /usr/sbin/sndradm -n -e lhost-reprg-prim \ /dev/md/nfsset/rdsk/d200 \ /dev/md/nfsset/rdsk/d203 lhost-reprg-sec \ /dev/md/nfsset/rdsk/d200 \ /dev/md/nfsset/rdsk/d203 ip sync
Le cluster principal détecte la présence du cluster secondaire et démarre la synchronisation. Reportez-vous au fichier journal système /var/adm pour Sun StorageTek Availability Suite pour plus d'informations sur le statut des clusters.
- Activez l'instantané ponctuel indépendant.
Utilisez la commande suivante pour le logiciel Sun StorageTek Availability Suite :
nodeC# /usr/sbin/iiadm -e ind \ /dev/md/nfsset/rdsk/d200 \ /dev/md/nfsset/rdsk/d201 \ /dev/md/nfsset/rdsk/d202 nodeC# /usr/sbin/iiadm -w \ /dev/md/nfsset/rdsk/d201
- Joignez l'instantané ponctuel au jeu de mise en miroir distant.
Utilisez la commande suivante pour le logiciel Sun StorageTek Availability Suite :
nodeC# /usr/sbin/sndradm -I a \ /dev/md/nfsset/rdsk/d200 \ /dev/md/nfsset/rdsk/d201 \ /dev/md/nfsset/rdsk/d202
Etapes suivantes
Passez à la section Exemple de réalisation de la réplication de données.
Exemple de réalisation de la réplication de données
Cette section décrit la réalisation de la réplication de données pour l'exemple de configuration. Cette section utilise les commandes sndradm et iiadm du logiciel Sun StorageTek Availability Suite. Pour plus d'informations sur ces commandes, reportez-vous à la documentation de. Sun StorageTek Availability Suite
Cette section détaille les procédures suivantes :
Réalisation d'une réplication distante
Dans cette procédure, le volume principal du disque principal est répliqué sur le volume principal du disque secondaire. d200 correspond au volume principal et d203 au volume bitmap miroir distant.
- Accédez au noeud nodeA en tant que rôle root.
- Vérifiez que le cluster se trouve en mode de journalisation.
Exécutez la commande suivante pour le logiciel Sun StorageTek Availability Suite :
nodeA# /usr/sbin/sndradm -P
La sortie doit ressembler à ce qui suit :
/dev/md/nfsset/rdsk/d200 -> lhost-reprg-sec:/dev/md/nfsset/rdsk/d200 autosync: off, max q writes:4194304, max q fbas:16384, mode:sync,ctag: devgrp, state: logging
En mode de journalisation, l'état est journalisation et l'état actif de la synchronisation est désactivé. Lorsque quelque chose est écrit sur le volume de données du disque, le fichier bitmap sur le même disque est mis à jour.
- Videz toutes les transactions.
nodeA# lockfs -a -f
- Répétez les étapes Step 1 à Step 3 sur nodeC.
- Copiez le volume principal de nodeA sur le volume principal de nodeC.
Exécutez la commande suivante pour le logiciel Sun StorageTek Availability Suite :
nodeA# /usr/sbin/sndradm -n -m lhost-reprg-prim \ /dev/md/nfsset/rdsk/d200 \ /dev/md/nfsset/rdsk/d203 lhost-reprg-sec \ /dev/md/nfsset/rdsk/d200 \ /dev/md/nfsset/rdsk/d203 ip sync
- Attendez la fin de la réplication et de la synchronisation des volumes.
Exécutez la commande suivante pour le logiciel Sun StorageTek Availability Suite :
nodeA# /usr/sbin/sndradm -n -w lhost-reprg-prim \ /dev/md/nfsset/rdsk/d200 \ /dev/md/nfsset/rdsk/d203 lhost-reprg-sec \ /dev/md/nfsset/rdsk/d200 \ /dev/md/nfsset/rdsk/d203 ip sync
- Confirmez que le cluster se trouve en mode de réplication.
Exécutez la commande suivante pour le logiciel Sun StorageTek Availability Suite :
nodeA# /usr/sbin/sndradm -P
La sortie doit ressembler à ce qui suit :
/dev/md/nfsset/rdsk/d200 -> lhost-reprg-sec:/dev/md/nfsset/rdsk/d200 autosync: on, max q writes:4194304, max q fbas:16384, mode:sync,ctag: devgrp, state: replicating
En mode de réplication, l'état est réplication (replicating) et l'état actif de la synchronisation automatique est activé (on). Lorsque quelque chose est écrit sur le volume principal, le volume secondaire est mis à jour par le logiciel Sun StorageTek Availability Suite.
Etapes suivantes
Passez à la section Réalisation d'un instantané ponctuel.
Réalisation d'un instantané ponctuel
Dans cette procédure, l'instantané ponctuel est utilisé pour synchroniser le volume shadow du cluster principal avec le volume principal du cluster principal. Le volume maître est d200, le volume bitmap est d203 et le volume en double est d201.
Avant de commencer
Effectuez la procédure Réalisation d'une réplication distante.
- Accédez au noeud nodeA avec le rôle octroyant les autorisations RBAC solaris.cluster.modify et solaris.cluster.admin.
- Désactivez la ressource en cours d'exécution sur nodeA.
nodeA# clresource disable nfs-rs
- Modifiez le cluster principal pour le mode de journalisation.
Exécutez la commande suivante pour le logiciel Sun StorageTek Availability Suite :
nodeA# /usr/sbin/sndradm -n -l lhost-reprg-prim \ /dev/md/nfsset/rdsk/d200 \ /dev/md/nfsset/rdsk/d203 lhost-reprg-sec \ /dev/md/nfsset/rdsk/d200 \ /dev/md/nfsset/rdsk/d203 ip sync
Lorsque quelque chose est écrit sur le volume de données du disque, le fichier bitmap sur le même disque est mis à jour. Aucune réplication ne se produit.
- Synchronisez le volume shadow du cluster principal au volume principal du cluster principal.
Exécutez la commande suivante pour le logiciel Sun StorageTek Availability Suite :
nodeA# /usr/sbin/iiadm -u s /dev/md/nfsset/rdsk/d201 nodeA# /usr/sbin/iiadm -w /dev/md/nfsset/rdsk/d201
- Synchronisez le volume shadow du cluster secondaire au volume principal du cluster secondaire.
Exécutez la commande suivante pour le logiciel Sun StorageTek Availability Suite :
nodeC# /usr/sbin/iiadm -u s /dev/md/nfsset/rdsk/d201 nodeC# /usr/sbin/iiadm -w /dev/md/nfsset/rdsk/d201
- Redémarrez l'application sur nodeA.
nodeA# clresource enable nfs-rs
- Resynchronisez le volume secondaire avec le volume principal.
Exécutez la commande suivante pour le logiciel Sun StorageTek Availability Suite :
nodeA# /usr/sbin/sndradm -n -u lhost-reprg-prim \ /dev/md/nfsset/rdsk/d200 \ /dev/md/nfsset/rdsk/d203 lhost-reprg-sec \ /dev/md/nfsset/rdsk/d200 \ /dev/md/nfsset/rdsk/d203 ip sync
Etapes suivantes
Passez à la section Vérification de la configuration correcte de la réplication.
Vérification de la configuration correcte de la réplication
Avant de commencer
Effectuez la procédure Réalisation d'un instantané ponctuel.
- Accédez aux noeuds nodeA et nodeC avec le rôle octroyant l'autorisation RBAC solaris.cluster.admin.
- Vérifiez que le cluster principal est en mode de réplication et que la synchronisation automatique est activée.
Utilisez la commande suivante pour le logiciel Sun StorageTek Availability Suite :
nodeA# /usr/sbin/sndradm -P
La sortie doit ressembler à ce qui suit :
/dev/md/nfsset/rdsk/d200 -> lhost-reprg-sec:/dev/md/nfsset/rdsk/d200 autosync: on, max q writes:4194304, max q fbas:16384, mode:sync,ctag: devgrp, state: replicating
En mode de réplication, l'état est réplication (replicating) et l'état actif de la synchronisation automatique est activé (on). Lorsque quelque chose est écrit sur le volume principal, le volume secondaire est mis à jour par le logiciel Sun StorageTek Availability Suite.
- Si le cluster principal n'est pas en mode de réplication, mettez-le en mode de réplication.
Utilisez la commande suivante pour le logiciel Sun StorageTek Availability Suite :
nodeA# /usr/sbin/sndradm -n -u lhost-reprg-prim \ /dev/md/nfsset/rdsk/d200 \ /dev/md/nfsset/rdsk/d203 lhost-reprg-sec \ /dev/md/nfsset/rdsk/d200 \ /dev/md/nfsset/rdsk/d203 ip sync
- Créez un répertoire sur un ordinateur client.
- Montez le volume principal sur le répertoire d'applications et affichez le répertoire monté.
- Démontez le volume principal du répertoire d'applications.
- Démontez le volume principal du répertoire d'applications.
client-machine# umount /dir
- Mettez le groupe de ressources d'application hors ligne sur le cluster principal.
nodeA# clresource disable -g nfs-rg + nodeA# clresourcegroup offline nfs-rg
- Modifiez le cluster principal pour le mode de journalisation.
Exécutez la commande suivante pour le logiciel Sun StorageTek Availability Suite :
nodeA# /usr/sbin/sndradm -n -l lhost-reprg-prim \ /dev/md/nfsset/rdsk/d200 \ /dev/md/nfsset/rdsk/d203 lhost-reprg-sec \ /dev/md/nfsset/rdsk/d200 \ /dev/md/nfsset/rdsk/d203 ip sync
Lorsque quelque chose est écrit sur le volume de données du disque, le fichier bitmap sur le même disque est mis à jour. Aucune réplication ne se produit.
- Assurez-vous que le répertoire PathPrefix est disponible.
nodeC# mount | grep /global/etc
- Confirmez que le système de fichiers est adéquat pour être monté sur le cluster secondaire.
nodeC# fsck -y /dev/md/nfsset/rdsk/d200
- Mettez l'application dans un état géré et mettez-la en ligne sur le cluster secondaire.
nodeC# clresourcegroup online -eM nodeC nfs-rg
- Accédez à l'ordinateur client en tant que rôle root.
Une invite ressemblant à ceci s'affiche :
client-machine#
- Montez le répertoire d'applications créé à l'Step 4 sur le répertoire d'application du cluster secondaire.
client-machine# mount -o rw lhost-nfsrg-sec:/global/mountpoint /dir
- Affichez le répertoire monté.
client-machine# ls /dir
- Démontez le volume principal du répertoire d'applications.
- Assurez-vous que le répertoire affiché dans l'Step 5 est le même que celui affiché dans l'Step 6.
- Renvoyez l'application sur le volume principal vers le répertoire d'application monté.
- Mettez le groupe de ressources d'application hors ligne sur le volume secondaire.
nodeC# clresource disable -g nfs-rg + nodeC# clresourcegroup offline nfs-rg
- Assurez-vous que le volume global est monté à partir du volume secondaire.
nodeC# umount /global/mountpoint
- Mettez le groupe de ressources d'application dans un état géré et mettez-le en ligne sur le cluster principal.
nodeA# clresourcegroup online -eM nodeA nfs-rg
- Modifiez le volume principal pour le mode de réplication.
Exécutez la commande suivante pour le logiciel Sun StorageTek Availability Suite :
nodeA# /usr/sbin/sndradm -n -u lhost-reprg-prim \ /dev/md/nfsset/rdsk/d200 \ /dev/md/nfsset/rdsk/d203 lhost-reprg-sec \ /dev/md/nfsset/rdsk/d200 \ /dev/md/nfsset/rdsk/d203 ip sync
Lorsque quelque chose est écrit sur le volume principal, le volume secondaire est mis à jour par le logiciel Sun StorageTek Availability Suite.
- Mettez le groupe de ressources d'application hors ligne sur le volume secondaire.
Voir aussi
Exemple de gestion d'une reprise
Exemple de gestion d'une reprise
Cette section décrit la mise à jour des entrées DNS. Pour plus d'informations, reportez-vous à la section Instructions pour la gestion d'une reprise.
Cette section contient la procédure suivante :
Mise à jour d'une entrée DNS
Pour une illustration du mappage d'un client vers un cluster par DNS, reportez-vous à la Figure A–6.
- Démarrez la commande nsupdate.
Pour plus d'informations, reportez-vous à la page de manuel nsupdate(1M).
- Supprimez le mappage DNS actuel entre le nom d'hôte logique du groupe de ressources d'application et l'adresse IP du cluster, pour les deux clusters.
> update delete lhost-nfsrg-prim A > update delete lhost-nfsrg-sec A > update delete ipaddress1rev.in-addr.arpa ttl PTR lhost-nfsrg-prim > update delete ipaddress2rev.in-addr.arpa ttl PTR lhost-nfsrg-sec
- ipaddress1rev
L'adresse IP du cluster principal, dans l'ordre inverse.
- ipaddress2rev
L'adresse IP du cluster secondaire, dans l'ordre inverse.
- ttl
La durée de vie, en secondes. Une valeur standard est 3600.
- Créez le nouveau mappage DNS entre le nom d'hôte logique du groupe de ressources d'application et l'adresse IP du cluster, pour les deux clusters.
Mappez le nom d'hôte logique principal à l'adresse IP du cluster secondaire et le nom d'hôte logique secondaire à l'adresse IP du cluster principal.
> update add lhost-nfsrg-prim ttl A ipaddress2fwd > update add lhost-nfsrg-sec ttl A ipaddress1fwd > update add ipaddress2rev.in-addr.arpa ttl PTR lhost-nfsrg-prim > update add ipaddress1rev.in-addr.arpa ttl PTR lhost-nfsrg-sec
- ipaddress2fwd
L'adresse IP du cluster secondaire, dans l'ordre.
- ipaddress1fwd
L'adresse IP du cluster principal, dans l'ordre.