Configuration de la réplication de données basée sur les hôtes à l'aide du logiciel 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 illustre 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 Sun StorageTek Availability Suite 4.0. 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 effectuées dans le noeud votant du 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) au lieu du superutilisateur pour accéder aux noeuds du cluster, assurez-vous de prendre un rôle RBAC octroyant l'autorisation d'accéder à toutes les commandes d'Oracle Solaris Cluster. Cette série de procédures de réplication de données nécessite les autorisations RBAC d'Oracle Solaris Cluster suivantes si l'utilisateur n'est pas un superutilisateur :

• solaris.cluster.modify

• solaris.cluster.admin

• solaris.cluster.read

Reportez-vous au manuel System Administration Guide: Security Services 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 Availability Suite dans un cluster

Cette section présente la tolérance aux sinistres et décrit les méthodes de réplication de données utilisées par le logiciel 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 Availability Suite

Cette section décrit la méthode de réplication en miroir distante et la méthode d'instantané ponctuel utilisées par le logiciel Availability Suite. Ce logiciel utilise les commandes sndradm(1RPC) et iiadm(1II) pour répliquer les données. Pour plus d'informations sur ces commandes, reportez-vous à la documentation d'Availability Suite.

Réplication distante

La Figure 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

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.

• Pour la réplication de données synchrone, une opération d'écriture est uniquement confirmée comme étant terminé lorsque le volume distant a été mis à jour.

• Pour la réplication de données asynchrone, une opération d'écriture est confirmée comme étant terminé avant que le volume distant ait é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.

Instantané ponctuel

La Figure A-2 montre 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

Directives pour la configuration de la réplication de données basée sur les hôtes entre les clusters

Cette section fournit des directives pour la configuration de la réplication de données entre les 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 directives 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

• Configuration des groupes de ressources d'application

  • Configuration des groupes de ressources pour une application de basculement

  • Configuration des groupes de ressources pour une application évolutive

• Directives pour la gestion d'une reprise

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 la ressource de nom d'hôte logique. 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

  Le nom d'hôte logique doit être hébergé par le cluster principal. Après un basculement, le nom d'hôte logique doit être hébergé par le cluster secondaire. Le système de noms de domaines (DNS) permet d'associer le nom d'hôte logique à un cluster.

• 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é.

  • ZPoolsSearchDir. Cette propriété d'extension est nécessaire pour l'utilisation du système de fichiers ZFS.

  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.

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

Un groupe de ressources pour une application évolutive doit disposer des caractéristiques suivantes :

• Avoir une dépendance au groupe de ressources d'adresse partagée

  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

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

Directives 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 mapper le nom d'hôte logique d'une application vers 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. La Figure A-6 montre comment DNS mappe un client vers un cluster.

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 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 :

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

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

3. Démarrez le groupe de ressources sur le cluster principal.

4. 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 Tableau A-1 répertorie les tâches de cet exemple relatives à la configuration de la réplication de données pour une application NFS à l'aide du logiciel Availability Suite.

Tableau A-1 Liste des tâches : exemple d'une configuration de réplication de données

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

La Tableau 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 et les patchs Availability Suite.

Tableau A-2 Exigences matérielles et logicielles

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.

Cette section contient les procédures suivantes :

• 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

• Vérification de la configuration correcte de la réplication

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

Tableau A-3 Récapitulatif des groupes et des ressources dans 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 ressources de réplication doit comprendre un nom au format devicegroupname-stor-rg.

Cet exemple de configuration utilise le logiciel SVM. 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.

La figure suivante illustre les volumes qui sont créés dans le groupe de périphériques.

Figure A-8 Volumes du groupe de périphériques