Ignorer les liens de navigation | |
Quitter l'aperu | |
![]() |
Guide d'administration système d'Oracle Solaris Cluster Oracle Solaris Cluster 3.3 3/13 (Français) |
1. Présentation de l'administration d'Oracle Solaris Cluster
2. Oracle Solaris Cluster et RBAC
3. Arrêt et initialisation d'un cluster
4. Méthodes de réplication de données
Présentation de l'administration des périphériques globaux et de l'espace de noms global
Autorisations du périphérique global pour Solaris Volume Manager
Reconfiguration dynamique avec les périphériques globaux
Administration des périphériques répliqués basés sur le stockage
Administration des périphériques répliqués Hitachi TrueCopy
Configuration d'un groupe de réplication Hitachi TrueCopy
Configuration des périphériques DID pour la réplication à l'aide de Hitachi TrueCopy
Vérification d'une configuration de groupe de périphériques global répliqué Hitachi TrueCopy
Exemple : configuration d'un groupe de réplication TrueCopy pour Oracle Solaris Cluster
Administration des périphériques répliqués EMC Symmetrix Remote Data Facility
Configuration d'un groupe de réplication EMC SRDF
Configuration de périphériques DID pour la réplication à l'aide d'EMC SRDF
Vérification de la configuration d'un groupe de périphériques globaux répliqués EMC SRDF
Exemple : configuration d'un groupe de réplication SRDF pour Oracle Solaris Cluster
Présentation de l'administration des systèmes de fichiers de cluster
Restrictions du système de fichiers de cluster
Administration des groupes de périphériques
Mise à jour de l'espace de noms des périphériques globaux
Migration de l'espace de noms des périphériques globaux
Ajout et enregistrement de groupes de périphériques
Ajout et enregistrement d'un groupe de périphériques (Solaris Volume Manager)
Ajout et enregistrement d'un groupe de périphériques (disque brut)
Ajout et enregistrement d'un groupe de périphériques répliqué (ZFS)
Maintenance des groupes de périphériques
Suppression et annulation de l'enregistrement d'un groupe de périphériques (Solaris Volume Manager)
Suppression d'un noeud de tous les groupes de périphériques
Suppression d'un noeud d'un groupe de périphériques (Solaris Volume Manager)
Suppression d'un noeud d'un groupe de périphériques de disque brut
Modification des propriétés des groupes de périphériques
Définition du nombre souhaité de noeuds secondaires pour un groupe de périphériques
Affichage sous forme de liste de la configuration d'un groupe de périphériques
Changement du noeud principal d'un groupe de périphériques
Mise en état de maintenance du groupe de périphériques
Administration des paramètres du protocole SCSI pour les périphériques de stockage
Affichage du paramétrage global par défaut du protocole SCSI pour tous les périphériques de stockage
Affichage du protocole SCSI d'un seul périphérique de stockage
Modification du protocole de séparation d'un seul périphérique de stockage
Administration des systèmes de fichiers de cluster
Ajout d'un système de fichiers de cluster
Suppression d'un système de fichiers de cluster
Vérification des montages globaux dans un cluster
Administration du contrôle de chemin de disque
Contrôle d'un chemin de disque
Désactivation du contrôle d'un chemin de disque
Impression des chemins de disques défectueux
Correction d'une erreur d'état du chemin de disque
7. Administration des interconnexions de cluster et des réseaux publics
8. Ajout et suppression d'un noeud
10. Configuration du contrôle de l'utilisation de la CPU
11. Application de patchs au logiciel et au microprogramme d'Oracle Solaris Cluster
12. Sauvegarde et restauration d'un cluster
13. Administration d'Oracle Solaris Cluster avec les interfaces graphiques
L'administration DPM (Disk Path Monitoring, contrôle du chemin de disque) permet de recevoir des notifications de panne de chemin de disque secondaire. Suivez les procédures décrites dans cette section pour réaliser les tâches d'administration associées au contrôle de chemin de disque. Pour obtenir des informations conceptuelles sur le démon de contrôle de chemin de disque, reportez-vous au Chapitre 3, Key Concepts for System Administrators and Application Developers du manuel Oracle Solaris Cluster Concepts Guide. La page de manuel cldevice(1CL) décrit les options de commande et les commandes associées. Pour plus d'informations sur le réglage du démon scdpmd, reportez-vous à la page de manuel scdpmd.conf(4). Reportez-vous également à la page de manuel syslogd(1M) pour consulter les erreurs consignées par le démon.
Remarque - Lorsque vous ajoutez des périphériques d'E/S à un noeud à l'aide de la commande cddevice, des chemins de disques sont automatiquement ajoutés à la liste de contrôle. Le contrôle de chemin de disque est automatiquement désactivé lorsque des périphériques sont supprimés du noeud à l'aide des commandes Oracle Solaris Cluster.
Tableau 5-6 Liste des tâches : administration du contrôle de chemin de disque
|
Les procédures, décrites dans la section suivante, qui exécutent la commande cldevice incluent l'argument de chemin de disque. L'argument de chemin de disque se compose d'un nom de noeud et d'un nom de disque. Le nom de noeud n'est pas nécessaire et sa valeur est définie par défaut sur all sans spécification de votre part.
Procédez comme suit pour contrôler des chemins de disques dans votre cluster.
![]() | Attention - DPM n'est pas pris en charge sur les noeuds qui exécutent des versions antérieures au logiciel Sun Cluster 3.1 10/03 N'utilisez pas les commandes DPM au cours d'une mise à jour non simultanée. Après la mise à niveau de tous les noeuds, les commandes DPM peuvent uniquement être utilisées si les noeuds sont en ligne. |
L'élément phys-schost# fait référence à l'invite du cluster global. Appliquez cette procédure à un cluster global.
Cette procédure contient la forme longue des commandes d'Oracle Solaris Cluster. La plupart des commandes possèdent également des formes brèves. A l'exception de la forme du nom, ces commandes sont identiques.
# cldevice monitor -n node disk
# cldevice status device
Exemple 5-38 Contrôle d'un chemin de disque sur un seul noeud
Dans l'exemple suivant, le chemin de disque schost-1:/dev/did/rdsk/d1 est contrôlé à partir d'un seul noeud. Seul le démon DPM situé sur le noeud schost-1 contrôle le chemin d'accès au disque /dev/did/dsk/d1.
# cldevice monitor -n schost-1 /dev/did/dsk/d1 # cldevice status d1 Device Instance Node Status --------------- ---- ------ /dev/did/rdsk/d1 phys-schost-1 Ok
Exemple 5-39 Contrôle d'un chemin de disque sur tous les noeuds
Dans l'exemple suivant, le chemin de disque schost-1:/dev/did/dsk/d1 est contrôlé à partir de tous les noeuds. Le contrôle DPM démarre sur tous les noeuds pour lesquels /dev/did/dsk/d1 est un chemin valide.
# cldevice monitor /dev/did/dsk/d1 # cldevice status /dev/did/dsk/d1 Device Instance Node Status --------------- ---- ------ /dev/did/rdsk/d1 phys-schost-1 Ok
Exemple 5-40 Relecture de la configuration de disque à partir du CCR
Dans l'exemple suivant, le démon est contraint à relire la configuration de disque à partir du CCR et les chemins de disques contrôlés sont imprimés avec leur état.
# cldevice monitor + # cldevice status Device Instance Node Status --------------- ---- ------ /dev/did/rdsk/d1 schost-1 Ok /dev/did/rdsk/d2 schost-1 Ok /dev/did/rdsk/d3 schost-1 Ok schost-2 Ok /dev/did/rdsk/d4 schost-1 Ok schost-2 Ok /dev/did/rdsk/d5 schost-1 Ok schost-2 Ok /dev/did/rdsk/d6 schost-1 Ok schost-2 Ok /dev/did/rdsk/d7 schost-2 Ok /dev/did/rdsk/d8 schost-2 Ok
Procédez comme suit pour désactiver le contrôle d'un chemin de disque.
![]() | Attention - DPM n'est pas pris en charge sur les noeuds qui exécutent des versions antérieures au logiciel Sun Cluster 3.1 10/03 N'utilisez pas les commandes DPM au cours d'une mise à jour non simultanée. Après la mise à niveau de tous les noeuds, les commandes DPM peuvent uniquement être utilisées si les noeuds sont en ligne. |
L'élément phys-schost# fait référence à l'invite du cluster global. Appliquez cette procédure à un cluster global.
Cette procédure contient la forme longue des commandes d'Oracle Solaris Cluster. La plupart des commandes possèdent également des formes brèves. A l'exception de la forme du nom, ces commandes sont identiques.
# cldevice status device
# cldevice unmonitor -n node disk
Exemple 5-41 Désactivation du contrôle d'un chemin de disque
Dans l'exemple suivant, le contrôle du chemin de disque schost-2:/dev/did/rdsk/d1 est désactivé et les chemins de disques sont imprimés avec leur état pour l'ensemble du cluster.
# cldevice unmonitor -n schost2 /dev/did/rdsk/d1 # cldevice status -n schost2 /dev/did/rdsk/d1 Device Instance Node Status --------------- ---- ------ /dev/did/rdsk/d1 schost-2 Unmonitored
Procédez comme suit pour imprimer les chemins de disques défectueux d'un cluster.
![]() | Attention - DPM n'est pas pris en charge sur les noeuds qui exécutent des versions antérieures au logiciel Sun Cluster 3.1 10/03 N'utilisez pas les commandes DPM au cours d'une mise à jour non simultanée. Après la mise à niveau de tous les noeuds, les commandes DPM peuvent uniquement être utilisées si les noeuds sont en ligne. |
# cldevice status -s fail
Exemple 5-42 Impression des chemins de disques défectueux
Dans l'exemple suivant, les chemins de disques défectueux sont imprimés pour l'ensemble du cluster.
# cldevice status -s fail Device Instance Node Status --------------- ---- ------ dev/did/dsk/d4 phys-schost-1 fail
Si les événements suivants se produisent, le contrôle DPM risque de ne pas mettre à jour l'état d'un chemin défectueux lors de son retour en ligne :
L'échec d'un chemin contrôlé provoque la réinitialisation du noeud.
La reconnexion du périphérique sous le chemin DID contrôlé est tributaire de celle du noeud réinitialisé.
L'état d'un chemin de disque incorrect est signalé parce que le périphérique DID contrôlé est indisponible pendant l'initialisation et, par conséquent, l'instance DID n'est pas téléchargée dans le pilote DID. Dans ce cas, mettez manuellement à jour les informations DID.
# cldevice populate
La commande s'applique à distance sur tous les noeuds, même si elle est exécutée à partir d'un seul noeud. Pour savoir si la commande a terminé le traitement, exécutez la commande suivante sur chaque noeud du cluster.
# ps -ef | grep cldevice populate
# cldevice status disk-device Device Instance Node Status --------------- ---- ------ dev/did/dsk/dN phys-schost-1 Ok
Procédez comme suit pour activer ou désactiver le contrôle des chemins de disques à partir d'un fichier.
Pour modifier la configuration du cluster à l'aide d'un fichier, vous devez d'abord l'exporter. L'exportation génère un fichier XML que vous pouvez alors modifier afin de définir les composants de la configuration que vous changez. L'intégralité de ce processus est décrite dans la procédure suivante.
![]() | Attention - DPM n'est pas pris en charge sur les noeuds qui exécutent des versions antérieures au logiciel Sun Cluster 3.1 10/03 N'utilisez pas les commandes DPM au cours d'une mise à jour non simultanée. Après la mise à niveau de tous les noeuds, les commandes DPM peuvent uniquement être utilisées si les noeuds sont en ligne. |
L'élément phys-schost# fait référence à l'invite du cluster global. Appliquez cette procédure à un cluster global.
Cette procédure contient la forme longue des commandes d'Oracle Solaris Cluster. La plupart des commandes possèdent également des formes brèves. A l'exception de la forme du nom, ces commandes sont identiques.
# cldevice export -o configurationfile
Précisez le nom de votre fichier XML.
Recherchez les chemins de périphériques à contrôler et définissez l'attribut monitored sur true.
# cldevice monitor -i configurationfile
Précisez le nom du fichier XML modifié.
# cldevice status
Exemple 5-43 Contrôle des chemins de disques à partir d'un fichier
Dans l'exemple suivant, le chemin de périphérique entre le noeud phys-schost-2 et le périphérique d3 est contrôlé à l'aide d'un fichier XML.
La première étape consiste à exporter la configuration de cluster actuelle.
# cldevice export -o deviceconfig
Le fichier XML deviceconfig indique que le chemin entre phys-schost-2 et d3 n'est pas contrôlé.
<?xml version="1.0"?> <!DOCTYPE cluster SYSTEM "/usr/cluster/lib/xml/cluster.dtd"> <cluster name="brave_clus"> . . . <deviceList readonly="true"> <device name="d3" ctd="c1t8d0"> <devicePath nodeRef="phys-schost-1" monitored="true"/> <devicePath nodeRef="phys-schost-2" monitored="false"/> </device> </deviceList> </cluster>
Pour le contrôler, définissez l'attribut monitored sur true, comme suit.
<?xml version="1.0"?> <!DOCTYPE cluster SYSTEM "/usr/cluster/lib/xml/cluster.dtd"> <cluster name="brave_clus"> . . . <deviceList readonly="true"> <device name="d3" ctd="c1t8d0"> <devicePath nodeRef="phys-schost-1" monitored="true"/> <devicePath nodeRef="phys-schost-2" monitored="true"/> </device> </deviceList> </cluster>
Utilisez la commande cldevice pour lire le fichier et activer le contrôle.
# cldevice monitor -i deviceconfig
Utilisez la commande cldevice pour vérifier que le périphérique est maintenant contrôlé.
# cldevice status
Voir aussi
Pour plus d'informations sur l'exportation de la configuration du cluster et sa définition à l'aide du fichier XML obtenu, reportez-vous aux pages de manuel cluster(1CL) et clconfiguration(5CL).
L'activation de cette fonctionnalité entraîne la réinitialisation automatique d'un noeud lorsque les conditions suivantes sont vérifiées :
Tous les chemins contrôlés de disques partagés sur le noeud échouent.
Au moins un des disques surveillés est accessible depuis un autre noeud du cluster. Le démon scdpm utilise l'interconnexion privée pour contrôler si les disques sont accessibles à partir d'un autre noeud du cluster. Si l'interconnexion privée est désactivée, le démon scdpm ne peut pas obtenir les statuts des disques à partir d'un autre noeud.
La réinitialisation du noeud entraîne le redémarrage de tous les groupes de ressources et groupes de périphériques de ce noeud sur un autre noeud.
Si tous les chemins contrôlés des disques partagés sur le noeud restent inaccessibles après la réinitialisation automatique du noeud, le noeud n'est pas à nouveau automatiquement réinitialisé. Toutefois, si un chemin de disque devient disponible après la réinitialisation du noeud, puis échoue à nouveau, le noeud est automatiquement réinitialisé.
Lorsque vous activez la propriété reboot_on_path_failure, l'état des chemins de disques locaux n'est pas pris en compte pour déterminer si un noeud doit être réinitialisé. Seuls les disques partagés contrôlés sont concernés.
# clnode set -p reboot_on_path_failure=enabled +
Si vous désactivez cette fonctionnalité et que tous les chemins contrôlés de disques partagés sur un noeud échouent, le noeud n'est pas réinitialisé automatiquement.
# clnode set -p reboot_on_path_failure=disabled +