Ignorer les liens de navigation | |
Quitter l'aperu | |
![]() |
Guide d'administration système d'Oracle Solaris Cluster Oracle Solaris Cluster (Français) |
1. Introduction à l'administration d'Oracle Solaris Cluster
2. Oracle Solaris Cluster et RBAC
3. Fermeture et initialisation d'un cluster
4. Méthodes de réplication de données
7. Administration des interconnexions de cluster et des réseaux publics
8. Ajout et suppression d'un nud
10. Configuration du contrôle de l'utilisation du CPU
11. Mise à jour du logiciel ou installation d'un microprogramme Oracle Solaris Cluster
12. Sauvegarde et restauration d'un cluster
13. Administration de Oracle Solaris Cluster avec les interfaces graphiques
Présentation du logiciel Sun StorageTek Availability Suite dans un cluster
Méthodes de réplication de données utilisées par le logiciel Sun StorageTek Availability Suite
Réplication par miroir distant
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
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'un basculement
Liste des tâches : exemple d'une configuration de réplication de données
Connexion et installation des clusters
Exemple de configuration des groupes de périphériques et des groupes de ressources
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 fichier 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
Exemple d'activation de la réplication de données
Activation de la réplication sur le cluster principal
Activation de la réplication sur le cluster secondaire
Exemple de réalisation de la réplication de données
Réalisation d'une réplication par miroir distant
Réalisation d'un instantané ponctuel
Vérification de la configuration correcte de la réplication
Exemple de gestion d'un basculement
Cette annexe fournit une alternative à la réplication basée sur les hôtes qui n'utilise pas Oracle Solaris Cluster Geographic Edition. Oracle vous recommande d'utiliser Oracle Solaris Cluster Geographic Edition pour la réplication basée sur les hôtes pour simplifier la configuration et l'opération de la réplication basée sur les hôtes au sein d'un cluster. 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 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 nœud 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 nœuds du cluster, assurez-vous de disposer des droits RBAC fournissant l'autorisation pour toutes les commandes de Oracle Solaris Cluster. Cette série de procédures de réplication de données nécessite les autorisations RBAC de Oracle Solaris Cluster suivantes si l'utilisateur n'est pas un superutilisateur :
solaris.cluster.modify
solaris.cluster.admin
solaris.cluster.read
Pour plus d'informations à propos de l'utilisation des rôles RBAC, reportez-vous au System Administration Guide: Security Services . Reportez-vous aux pages de manuel de Oracle Solaris Cluster pour les autorisations RBAC que nécessite chaque sous-commande de Oracle Solaris Cluster.
Cette section présente la tolérance de sinistre et décrit les méthodes de réplication de données utilisées par le logiciel Sun StorageTek Availability Suite.
La tolérance de sinistre correspond à l'aptitude d'un système à 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 le basculement. Le basculement désigne le déplacement automatique d'un groupe de ressources ou d'un groupe de périphériques d'un cluster principal à un cluster secondaire. En cas de défaillance du cluster principal, les applications et les données sont immédiatement disponibles sur le cluster secondaire.
Cette section décrit la méthode de réplication par miroir distant et la méthode d'instantané ponctuel utilisées par le logiciel Sun StorageTek Availability Suite. Ce logiciel utilise les commandes sndradm(1RPC) et iiadm(1II) pour répliquer des données.
La Figure A-1 montre la réplication par miroir distant. 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 par miroir distant
La réplication par miroir distant 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.
La Figure A-2 montre un instantané ponctuel. Les données du volume principal de chaque disque sont copiées sur le volume en double du même disque. Le bitmap ponctuel répertorie les différences entre le volume principal et le volume en double. Lorsque les données sont copiées sur le volume en double, le bitmap ponctuel est réinitialisé.
Figure A-2 Instantané ponctuel
La Figure A-3 montre l'utilisation de la réplication par miroir distant et de l'instantané ponctuel dans cet exemple de configuration.
Figure A-3 La réplication dans l'exemple de configuration
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 :
Les groupes de ressources de réplication colocalise 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 groupe de ressources de réplication doit disposer des caractéristiques suivantes :
Être un groupe de ressources de basculement
Une ressource de basculement peut uniquement être exécutée sur un seul nœud à 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 DNS (Domain Name System) est utilisé pour 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 nœud.
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'analogie.
ZPoolsSearchDir. Cette propriété d'extension est nécessaire pour l'utilisation du système de fichiers ZFS.
Pour plus d'informations à propos de HAStoragePlus, reportez-vous à la page de manuel SUNW.HAStoragePlus(5).
Être nommé d'après le groupe de périphériques avec lequel il est colocalisé, suivi de -stor-rg
Par exemple, devgrp-stor-rg.
Être en ligne 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 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
Dans une application de basculement, une application s'exécute sur un nœud à la fois. Si ce nœud échoue, l'application bascule sur un autre nœud 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 groupe de périphériques 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 nœud.
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.
Sans une ressource HAStoragePlus, le basculement du groupe de ressources d'application ne déclenchera pas le basculement du groupe de ressources de réplication et du groupe de périphériques. Après un basculement, le groupe de ressources d'application, le groupe de ressources de réplication et le groupe de périphériques ne seront pas contrôlés par le même nœud.
Pour plus d'informations à propos de 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
Dans une application évolutive, une application s'exécute sur plusieurs nœuds pour créer un service logique unique. Si un nœud exécutant une application évolutive échoue, le basculement ne s'effectue pas. L'application continue de s'exécuter sur les autres nœuds.
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 nœuds qui exécutent l'application évolutive utilisent l'adresse partagée pour distribuer les données entrantes.
Être en ligne sur le cluster principal et hors ligne sur le cluster secondaire
La Figure 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
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.
Le DNS associe un client au nom d'hôte logique d'une application. Après un basculement, le mappage DNS du cluster principal doit être supprimé et un mappage DNS doit être créé pour le cluster secondaire. La Figure A-6 montre comment un DNS mappe un client à 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, voir la page de manuel nsupdate(1M). Pour un exemple de gestion d'un basculement, reportez-vous à la section Exemple de gestion d'un basculement.
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.
Mettez le DNS à jour pour que les clients puissent accéder à l'application sur le cluster principal.
La Tableau A-1 répertorie dans cet exemple les tâches de configuration de la réplication de données pour une application NFS à l'aide du logiciel Sun StorageTek Availability Suite.
Tableau A-1 Liste des tâches : exemple d'une configuration de réplication de données
|
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 nœud, 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 logiciel Oracle Solaris Cluster pour SE Oracle Solaris et le logiciel gestionnaire de volumes doivent être installés sur les nœuds du cluster avant le logiciel Sun StorageTek Availability Suite et les patchs.
Tableau A-2 Exigences matérielles et logicielles
|
Cette section décrit la configuration des groupes de périphériques et des groupes de ressources pour une application NFS. Pour des informations supplémentaires, 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 fichier 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
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
|
À 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.
Cette exemple de configuration utilise le logiciel VxVM. Pour plus d'informations à propos du &logiciel Solaris Volume Manager, reportez-vous au Chapitre 4, Configuration du logiciel Solaris Volume Manager du Guide d’installation du logiciel Oracle Solaris Cluster.
La figure suivant illustre les volumes créés dans le groupe de périphériques.
Figure A-8 Volumes pour le groupe de périphériques
Remarque - Les volumes définis dans cette procédure ne doivent pas comprendre de zone privée d'étiquette de disque, par exemple, cylindre 0. Le logiciel VxVM gère cette contrainte automatiquement.