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 rassemblent les groupes de périphériques sous contrôle du logiciel Availability Suite avec une 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 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 5 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 5 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 6 illustre la configuration des groupes de ressources dans une application évolutive.
Figure 6 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 7 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 manuel nsupdate(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.