test

Notes de version de Sun Cluster 3.0

Problèmes connus de la documentation

Cette section décrit les erreurs de documentation que vous risquez de rencontrer et la procédure à suivre pour rectifier les problèmes.

Guide d'installation

Le Guide d'installation de Sun Cluster 3.0 contient les erreurs suivantes :

Guide du matériel

Dans le document Sun Cluster 3.0 Hardware Guide, les procédures suivantes sont incorrectes ou absentes :

Transfert d'un câble de disque sur une autre carte

Pour transférer un câble de disque sur une nouvelle carte d'un noeud, procédez comme indiqué ci-après.

  1. Arrêtez progressivement toutes les E/S du ou des disques affectés.

  2. Débranchez le câble de l'ancienne carte.

  3. Exécutez la commande cfgadm(1M) sur le noeud local pour annuler la configuration de tous les disques affectés par le transfert.

    Vous pouvez également réinitialiser le noeud à l'aide de la commande suivante : 


    # reboot -- -r

  4. Exécutez la commande devfsadm -C sur le noeud local pour effacer le lien de périphérique Solaris.

  5. Exécutez la commande scdidadm -C sur le noeud local pour effacer le chemin de périphérique DID.

  6. Connectez le câble à la nouvelle carte.

  7. Exécutez la commande cfgadm sur le noeud local pour configurer les périphériques dans leur nouvel emplacement.

    Vous pouvez également réinitialiser le noeud à l'aide de la commande suivante : 


    # reboot -- -r

  8. Exécutez la commande scgdevs pour ajouter le nouveau chemin de périphérique DID.

Transfert d'un câble de disque d'un noeud vers un autre

Pour transférer un câble de disque d'un noeud vers un autre, procédez comme indiqué ci-après.

  1. Supprimez toutes les références au chemin à supprimer dans toutes les configurations de gestionnaires de volumes et de services de données.

  2. Arrêtez progressivement toutes les E/S du ou des disques affectés.

  3. Débranchez le câble de l'ancien noeud.

  4. Exécutez la commande cfgadm sur l'ancien noeud pour annuler la configuration de tous les disques affectés par le transfert.

    Vous pouvez également réinitialiser le noeud à l'aide de la commande suivante : 


    # reboot -- -r

  5. Exécutez la commande devfsadm -C sur l'ancien noeud pour effacer le lien de périphérique Solaris.

  6. Exécutez la commande scdidadm -C sur l'ancien noeud pour effacer le chemin de périphérique DID.

  7. Connectez le câble au nouveau noeud.

  8. Exécutez la commande cfgadm sur le nouveau noeud pour configurer les périphériques dans leur nouvel emplacement.

    Vous pouvez également réinitialiser le noeud à l'aide de la commande suivante : 


    # reboot -- -r

  9. Exécutez la commande devfsadm sur le nouveau noeud pour créer les nouveaux liens de périphérique Solaris.

  10. Exécutez la commande scgdevs sur le nouveau noeud pour ajouter le nouveau chemin de périphérique DID.

  11. Ajoutez, sur le nouveau noeud, le chemin vers les configurations de gestionnaire de volumes et de service de données requises.

    Lorsque vous configurez les services de données, vérifiez que les préférences de reprise de noeud reflètent bien la nouvelle configuration.

Mise à jour du logiciel de cluster avec la configuration correcte des périphériques

Si les procédures ci-dessus ne sont pas exécutées correctement, une erreur risque de se produire lors de l'exécution suivante de la commande scdidadm -r ou scgdevs. Pour mettre à jour le logiciel de cluster avec la configuration des périphériques correcte, procédez comme indiqué ci-après.

  1. Vérifiez que la configuration du câble est correcte. Vérifiez que le câble est déconnecté de l'ancien noeud.

  2. Vérifiez que l'ancien noeud a été supprimé dans les configurations de gestionnaire de volumes ou de service de données appropriées.

  3. Exécutez la commande cfgadm sur l'ancien noeud pour annuler la configuration de tous les disques affectés par le transfert.

    Vous pouvez également réinitialiser le noeud à l'aide de la commande suivante : 


    # reboot -- -r

  4. Exécutez la commande devfsadm -C sur le noeud dont vous avez déconnecté le câble.

  5. Exécutez la commande scdidadm -C sur le noeud dont vous avez déconnecté le câble.

  6. Exécutez la commande cfgadm sur le nouveau noeud pour configurer les périphériques dans leur nouvel emplacement.

    Vous pouvez également réinitialiser le noeud à l'aide de la commande suivante : 


    # reboot -- -r

  7. Exécutez la commande scgdevs sur le nouveau noeud pour ajouter le nouveau chemin de périphérique DID.

  8. Exécutez la commande scdidadm -R périphérique sur le nouveau noeud pour vous assurer que l'état des réservations SCSI est correct.

Guide de développement de service de données

L'exemple de code fourni dans l'annexe B du document Sun Cluster 3.0 Data Services Developers' Guide contient deux problèmes connus :

Guide des concepts

Concernant le document Sun Cluster 3.0 Concepts, notez que :

Utilisation de l'interconnexion de cluster pour le trafic applicatif

Les noeuds d'un cluster doivent être reliés par de multiples connexions, constituant l'interconnexion du cluster. Pour des raisons de haute disponibilité et de performances, le logiciel de cluster utilise de nombreuses interconnexions. Pour le trafic interne (par exemple, les données de fichiers système ou les données de services évolutifs), les messages sont répartis sur toutes les interconnexions disponibles à tour de rôle.

L'interconnexion de cluster est également mise à la disposition des applications pour offrir une communication haute disponibilité entre les noeuds. Par exemple, les composants d'une application distribuée peuvent s'exécuter sur différents noeuds et avoir besoin de communiquer les uns avec les autres. En utilisant l'interconnexion de cluster plutôt que l'interconnexion publique, ces connexions peuvent tolérer une défaillance sur une liaison individuelle.

Pour utiliser l'interconnexion de cluster pour ses communications, l'application doit adopter les noms d'hosts privés configurés lors de l'installation du cluster. Par exemple, si le nom d'host privé du noeud 1 est clusternode1-priv, utilisez ce nom pour communiquer sur l'interconnexion de cluster avec le noeud 1. Les sockets TCP ouverts à l'aide de ce nom sont acheminés sur l'interconnexion de cluster et peuvent être redirigés de manière totalement transparente en cas de défaillance du réseau.

Notez que, comme les noms d'host privés peuvent être configurés durant l'installation, l'interconnexion de cluster peut utiliser n'importe quel nom choisi à ce moment là. Le nom réel peut être obtenu à l'aide de la commande scha_cluster_get(3HA) suivie de l'argument scha_privatelink_hostname_node.

Pour utiliser l'interconnexion de cluster au niveau de l'application, une simple interconnexion est établie entre deux noeuds, mais des interconnexions distinctes sont utilisées entre les différentes paires de noeuds dans la mesure du possible. Supposons par exemple qu'une application exécutée sur trois noeuds communique sur l'interconnexion de cluster. La communication entre les noeuds 1 et 2 peut avoir lieu sur l'interface hme0 et la communication entre les noeuds 1 et 3 sur l'interface qfe1. Autrement dit, les communications de l'application entre deux noeuds sont limitées à une simple interconnexion, tandis que les communications internes du cluster sont réparties sur toutes les interconnexions.

Notez que l'application partage l'interconnexion avec le trafic interne du cluster et, de ce fait, que la bande passante à la disposition de l'application dépend de la bande passante utilisée par le reste du trafic. En cas de défaillance, le trafic interne est acheminé tour à tour sur les autres interconnexions, tandis que les connexions d'application sur une interconnexion défaillante peuvent être réacheminées sur une interconnexion en bon état de fonctionnement.

Deux types d'adresses supportent l'interconnexion de cluster et la commande gethostbyname(3N) exécutée sur un nom d'host privé renvoie normalement deux adresses IP. La première adresse est appelée adresse de paire logique et la seconde adresse "par noeud" logique.

Une adresse de paire logique distincte est attribuée à chaque paire de noeuds. Ce petit réseau logique prend en charge la reprise sur panne des connexions. Chaque noeud se voit également attribuer une adresse "par noeud" fixe. Autrement dit, l'adresse de paire logique de clusternode1-priv est différente pour chaque noeud, tandis que l'adresse "par noeud" logique de clusternode1-priv est la même pour chaque noeud. Un noeud ne comporte toutefois pas d'adresse de paire logique le désignant et, de ce fait, la commande gethostbyname(clusternoeud1-priv) exécutée sur le noeud 1 renvoie uniquement l'adresse "par noeud" logique.

Notez que les applications qui acceptent des connexions sur l'interconnexion du cluster et vérifient ensuite l'adresse IP pour des raisons de sécurité doivent procéder à une nouvelle vérification de toutes les adresses IP renvoyées par la commande gethostbyname, et non pas simplement la première.

Si votre application requiert des adresses IP permanentes pour tous les points, configurez-la pour qu'elle se lie à l'adresse "par noeud" du côté client et du côté serveur de sorte que toutes les connexions semblent provenir de et se diriger vers cette adresse "par noeud".

Guide d'installation et de configuration des services de données

Le chapitre 5, "Installing and Configuring Sun Cluster HA for Apache", du document Sun Cluster 3.0 Data Services Installation and Configuration Guide décrit la procédure à suivre pour installer le serveur Web Apache à partir du site Web Apache (http://www.apache.org). Vous avez également la possibilité d'installer le serveur Web Apache à partir du CD-ROM de l'environnement d'exploitation Solaris 8.

Les fichiers binaires Apache sont fournis dans trois modules (SUNWapchr, SUNWapchu et SUNWapchd) qui constituent le métacluster SUNWCapache. Vous devez installer SUNWapchr avant SUNWapchu.

Placez les binaires du serveur Web dans le système de fichiers local de chacun des noeuds de votre cluster ou dans un système de fichiers de cluster.

Installation d'Apache à partir du CD-ROM Solaris 8

Cette procédure décrit les étapes à suivre pour utiliser le service de données Sun Cluster HA for Apache avec la version du serveur Web Apache disponible sur le CD-ROM de l'environnement d'exploitation Solaris 8.

  1. Installez les modules Apache SUNWapchr, SUNWapchu et SUNWapchd, si ce n'est pas encore fait.

    Utilisez la commande pkginfo(1) pour vérifier si les modules sont déjà installés.


    # pkgadd -d Solaris 8 Product directory SUNWapchr SUNWapchu SUNWapchd
...
Installing Apache Web Server (root) as SUNWapchr
...
[ verifying class initd ]
/etc/rc0.d/K16apache linked pathname
/etc/rc1.d/K16apache linked pathname
/etc/rc2.d/K16apache linked pathname
/etc/rc3.d/S50apache linked pathname
/etc/rcS.d/K16apache linked pathname
...

  2. Désactivez les scripts de contrôle de début et de fin qui viennent d'être installés avec le module SUNWapchr.

    Il est nécessaire de désactiver ces scripts parce que le service de données Sun Cluster HA for Apache démarre et arrête l'application Apache après la configuration du service de données. Exécutez les étapes suivantes :

    1. Répertoriez les scripts de contrôle d'exécution Apache.

    2. Renommez les scripts de contrôle d'exécution Apache.

    3. Vérifiez que tous les scripts associés à Apache ont été renommés.

    Remarque :

    l'exemple suivant convertit la première lettre du nom du script de contrôle d'exécution en minuscule. Vous pouvez toutefois renommer les scripts selon une procédure correspondant à vos habitudes administratives.


    # <userinput>ls -1 /etc/rc?.d/*apache</userinput>
/etc/rc0.d/K16apache
/etc/rc1.d/K16apache
/etc/rc2.d/K16apache
/etc/rc3.d/S50apache
/etc/rcS.d/K16apache

# <userinput>mv /etc/rc0.d/K16apache  /etc/rc0.d/k16apache

</userinput># <userinput>mv /etc/rc1.d/K16apache  /etc/rc1.d/k16apache</userinput>

# <userinput>mv /etc/rc2.d/K16apache  /etc/rc2.d/k16apache</userinput>

# <userinput>mv /etc/rc3.d/S50apache  /etc/rc3.d/s50apache</userinput>

# <userinput>mv /etc/rcS.d/K16apache  /etc/rcS.d/k16apache</userinput>



# <userinput>ls -1 /etc/rc?.d/*apache

</userinput>
/etc/rc0.d/k16apache/etc/rc1.d/k16apache/etc/rc2.d/k16apache/etc/rc3.d/s50apache/etc/rcS.d/k16apache

Pages de manuel

De nouvelles pages de manuel sont incluses pour chaque service de données fourni avec le logiciel Sun Cluster 3.0. Les nouvelles pages de manuel des services de données sont les suivantes : SUNW.apache(5), SUNW.dns(5), SUNW.iws(5), SUNW.nfs(5), SUNW.nsldap(5), SUNW.oracle_listener(5), SUNW.oracle_server(5), SUNW.HAStorage(5) et scalable_service(5). Ces pages décrivent les propriétés standard ou étendues utilisées par ces services de données.