| Guide de configuration DR d'un domaine Sun Enterprise 10000 |
|
| Guide de configuration DR d'un domaine Sun Enterprise 10000 |
|
| C H A P I T R E 1 |
Configuration DR |
Ce chapitre décrit la fonctionnalité de reconfiguration dynamique (DR, Dynamic Reconfiguration) et vous guide à travers les étapes de la configuration DR. Il contient les sujets suivants :
Informations sur les modèles DR ;
Détails sur la manière de lancer la configuration DR ;
Présentation des tâches de configuration DR ;
Tâches à effectuer avant une opération DR de détachement ;
Détails sur les changements de configuration qui se produisent pendant les opérations DR Detach et manière de contrôler certaines conditions pendant l'exécution d'une opération Detach.
Deux modèles DR différents sont pris en charge par les domaines Sun Enterprise 10000. Le modèle DR 2.0 est parfois appelé "legacy DR" (DR héritée) et le modèle DR 3.0 "next generation DR" (DR de la nouvelle génération). Le tableau suivant indique les différentes versions du système d'exploitation Solaris et du logiciel SSP utilisées avec les modèles DR 2.0 et 3.0 :
Les domaines qui exécutent la version 9 du logiciel Solaris ne prennent en charge que le modèle DR 3.0, la version 3.5 du logiciel SSP est nécessaire.
Un seul modèle de DR peut être exécuté à un moment donné au sein d'un domaine. Pour contrôler la version de DR en cours d'exécution, utilisez la commande domain_status avec son option -m (disponibles uniquement sur les domaines qui exécutent la version 3.5 du logiciel SSP). Veillez à vérifier le modèle DR avant d'exécuter toute commande DR. Voici un exemple de la sortie de domain_status(1M). La colonne DR-MODEL indique le modèle qui est activé.
D'après cette sortie, le domaine A exécute le logiciel Solaris version 8 (OS 5.8) avec le modèle DR 2.0 activé ; le domaine B exécute le logiciel Solaris version 8 avec le modèle DR 3.0 activé ; le domaine C exécute le logiciel Solaris version 7 (OS 5.7) avec le modèle DR 2.0 activé ; et le domaine D exécute le logiciel Solaris version 9 (OS 5.9) avec le modèle DR 3.0 activé.
Seules certaines commandes sont disponibles dans chaque modèle et si vous exécutez une commande qui n'est pas prise en charge, un message d'erreur s'affiche sur la console.
Pour plus d'informations sur l'utilisation de DR 2.0, consultez le Sun Enterprise 10000 Dynamic Reconfiguration (DR) User Guide (référence n° 806-7616-10). Pour plus d'informations sur l'utilisation de DR 3.0, consultez le Sun Enterprise 10000 Dynamic Reconfiguration (DR) User Guide (référence n° 816-3627-10).
Le modèle DR 3.0 bénéficie des améliorations suivantes par rapport au DR 2.0 :
Le DR 3.0 a une structure qui offre une meilleure intégration avec les applications, par le biais du Reconfiguration Coordination Manager.
Le DR 3.0 prend en charge le multi-acheminement réseau en utilisant IPMP.
Vous pouvez exécuter les commandes DR de deux emplacements au choix : depuis le SSP (system service processor) au moyen des commandes du SSP — addboard(1M), moveboard(1M), deleteboard(1M), rcfgadm(1M) et showdevices(1M) ; ou depuis le domaine en utilisant la commande cfgadm(1M).
Pour utiliser le multi-acheminement dans les domaines mettant en oeuvre le modèle DR 3.0, exécutez IPMP (le logiciel de multi-acheminement IP fourni dans le système d'exploitation Solaris 8) et le logiciel MPxIO, inclus dans les fichiers correctifs de mise à jour du noyau n°111412-02, 111413-02, 111095-02, 111096-02 et 111097-02.
Avant de pouvoir exécuter des opérations DR sur votre domaine, vous devez :
Vous familiariser avec la manière de configurer les périphériques avant toute opération DR Detach, comme expliqué dans Conditions préalables des périphériques.
Vérifier que la zone de swap de votre domaine est suffisante.
Pour plus d'informations, reportez-vous à Attribution d'une zone de swap suffisante.
Qualifier les gestionnaires de périphériques d'autres marques, comme indiqué dans Qualification des gestionnaires de périphériques tiers.
La fonctionnalité DR nécessite que les gestionnaires des périphériques se trouvant sur des cartes associées aux opérations DR Detach soient à la fois :
Sûrs en cas de détachement ou ne soient pas couramment chargés
Un gestionnaire sûr en cas de détachement prend en charge l'interface du gestionnaire de périphérique (DDI, device driver interface) DDI_DETACH. Cette fonction permet de détacher une instance de gestionnaire particulière sans affecter les autres instances qui prennent en charge d'autres périphériques.
Un gestionnaire pas sûr en cas de détachement ne prend pas en charge l'interface DDI_DETACH. Si un gestionnaire pas sûr en cas de détachement est chargé, vous devez le décharger avant d'effectuer une opération DR Detach. Pour plus d'informations sur le déchargement d'un périphérique pas sûr en cas de détachement, reportez-vous à Préparation des opérations DR Detach.
Sûrs en cas d'interruption ou fermés
Un gestionnaire sûr en cas d'interruption prend en charge la mise au repos du système d'exploitation Solaris pendant le détachement d'une carte comportant de la mémoire OBP ou mémoire noyau non-paginable. Pour qu'une opération DR Detach puisse être effectuée et qu'il soit possible de déconfigurer la mémoire, le système d'exploitation doit temporairement interrompre tous les processus, processeurs et périphériques.
Un périphérique sûr en cas d'interruption prend en charge la fonction DDI_SUSPEND/DDI_RESUME. Cette fonction permet d'interrompre un périphérique pendant la mise au repos du système et de le relancer ensuite. Le périphérique géré par le gestionnaire ne tentera pas d'accéder au "centerplane" du domaine (par exemple, il n'accédera pas à la mémoire ni n'interrompra pas le système), même si le périphérique est ouvert lorsque l'interruption est demandée. La mise au repos n'affecte que le domaine cible, les autres domaines du système sont épargnés.
Si un gestionnaire ne prend pas en charge la fonction DDI_SUSPEND/DDI_RESUME, le périphérique est considéré comme n'étant pas sûr en cas d'interruption parce que le système d'exploitation ne peut pas être mis au repos tant qu'un périphérique de ce genre est présent. Si la mise au repos d'un système est requise pour une opération DR Detach, vous devez manuellement interrompre le périphérique pas sûr en cas d'interruption pour que la mise au repos soit possible. Pour plus d'informations, reportez-vous à Interruption manuelle d'un périphérique pas sûr en cas d'interruption.
L a configuration de swap du domaine se compose des périphériques de swap et de swapfs (mémoire). Le domaine doit contenir une zone de swap suffisante pour pouvoir vider la mémoire paginable. Par exemple, si vous voulez retirer 1 gigaoctet de mémoire d'un domaine de 2 gigaoctets, il vous faut 1 gigaoctet de zone de swap, en fonction de la charge. Une zone de swap insuffisante empêche la fonctionnalité DR d'exécuter tout type d'opération DR.
La zone de swap du domaine doit être configurée en plusieurs partitions sur des disques rattachés à des contrôleurs hébergés par différentes cartes. Avec ce type de configuration, une partition de swap donnée n'est pas une ressource essentielle car il est possible d'en ajouter et d'en supprimer dynamiquement (pour plus d'informations, reportez-vous à swap(1M)).
| Remarque - Lorsque la mémoire (swapfs) ou la zone de swap d'un disque est détachée, il doit rester suffisamment de mémoire ou de zone de swap dans le domaine pour les programmes en cours. |
De nombreux gestionnaires d'autres marques (pas achetés chez Sun Microsystems) ne prennent pas en charge l'interface standard Solaris modunload(1M), qui est utilisée pour décharger les gestionnaires de périphériques pas sûrs en cas de détachement ou pas sûrs en cas d'interruption. Les conditions sollicitant les gestionnaires ne se présentent pas régulièrement dans le cadre du fonctionnement normal et les fonctionnalités font parfois défaut ou fonctionnent mal. Sun Microsystems suggère que vous testiez les fonctions des gestionnaires pendant les phases de qualification et d'installation de périphériques tiers.
Cette section indique les différentes tâches de configuration à effectuer avant d'exécuter des opérations DR sur des domaines Solaris 9 (qui ne prennent en charge que le modèle DR 3.0). Veuillez noter qu'il n'est peut-être pas nécessaire d'effectuer toutes les tâches décrites dans cette section, en fonction des types de périphériques existant sur vos cartes système et du type d'opérations DR à effectuer.
Après avoir configuré la fonctionnalité DR ou chaque fois que vous modifiez la configuration DR, vous devez réinitialiser votre domaine. Si vous voulez réduire au minimum le nombre des réinitialisations à effectuer, déterminez les tâches de configuration qui s'appliquent à votre environnement DR puis effectuez la série de tâches appropriées avant de réinitialiser votre domaine.
Si vous comptez effectuer des opérations DR Detach, activez la "cage" du noyau, comme expliqué dans la section Activation de la "cage" du noyau.
Pour les périphériques, faites ce qui suit :
Si vous définissez manuellement les paramètres de configuration du réseau, rendez-les permanents, comme décrit dans la section Définition des paramètres permanents des gestionnaires de réseau.
Si vous possédez des périphériques soc et pln, activez l'interruption des gestionnaires, comme décrit dans la section Activation de l'interruption des gestionnaires des périphériques soc et pln.
Si vous possédez des périphériques pas sûrs en cas d'interruption, spécifiez leur nom dans la liste des gestionnaires pas sûrs, qui bloque l'activation de la mise au repos.
Pour plus d'informations, reportez-vous à Spécification d'une liste de gestionnaires pas sûrs.
Si vous possédez des unités de bande qui ne sont pas prises en charge par Sun Microsystems, rendez ces périphériques sûrs en cas de détachement.
Pour plus d'informations, reportez-vous à Transformation d'une unité de bande pas prise en charge en périphérique sûr en cas de détachement.
Si vous utilisez le multi-acheminement, configurez votre domaine en fonction et exécutez le logiciel de multi-acheminement approprié sur le domaine.
Réinitialisez le domaine pour activer les changements de configuration.
Après avoir réussi la réinitialisation, vous pouvez vérifier les messages de changement de configuration DR dans le fichier /var/adm/messages.
Par exemple, si vous avez activé la "cage" du noyau, le message suivant s'affiche :
Un noyau "en cage" limite la mémoire non-paginable à un petit nombre de cartes système (à une en général). Par défaut la "cage" du noyau est désactivée, empêchant toute opération DR Detach. Si vous projetez d'effectuer des opérations DR Detach, vous devez activer la cage du noyau en utilisant la variable system(4), kernel_cage_enable, comme expliqué dans la procédure suivante.
Il faut que vous sachiez que les opérations DR Attach ou addboard (ajouter carte) sont activées par défaut, indépendamment de la valeur de la variable kernel_cage_enable.
1. Au moyen d`un éditeur de texte, éditez le fichier /etc/system du domaine pour que kernel_cage_enable soit égal à 1.
2. Lorsque toutes les tâches de configuration DR sont terminées, veillez à réinitialiser le domaine pour valider la configuration.
3. Vérifiez ce changement de configuration dans le fichier /var/adm/messages.
L'exemple suivant fait partie d'un fichier messages, qui indique que la "cage" du noyau a été activée :
Si vous utilisez la commande ndd(1M) pour programmer les paramètres de configuration des gestionnaires de réseau, les paramètres risquent de ne pas persister après une opération DR.
Utilisez le fichier /etc/system ou driver.conf d'un gestionnaire donné pour définir des paramètres permanents.
|
|
Si vos cartes système contiennent les périphériques soc et pln, procédez comme suit pour que ces périphériques deviennent sûrs en cas d'interruption.
1. Avec un éditeur de texte, éditez le fichier /etc/system pour que les variables pln_enable_detach_suspend et soc_enable_detach_suspend soient réglées sur 1, comme dans l'exemple suivant :
2. Lorsque toutes les tâches de configuration DR sont terminées, réinitialisez le domaine pour valider la configuration.
Vous pouvez fournir au système d'exploitation Solaris des informations concernant les périphériques pas sûrs (en cas d'interruption) dans le système en spécifiant une liste de gestionnaires pas sûrs dans le fichier dr.conf.
La fonctionnalité DR lit cette liste quand elle se prépare à interrompre le système d'exploitation afin qu'une carte contenant de la mémoire non-paginable puisse être détachée. Si la DR trouve un gestionnaire actif dans la liste des gestionnaires pas sûrs, elle abandonne l'opération et retourne un message d'erreur. Le message identifie le gestionnaire actif qui n'est pas sûr. Vous devez interrompre manuellement le périphérique pour que l'opération DR puisse être effectuée.
1. Au moyen d'un éditeur de texte, éditez le fichier /platform/SUNW,Ultra-Enterprise-10000/kernel/drv/ngdr.conf spécifiez les gestionnaires de périphériques pas sûrs en cas d'interruption comme indiqué ci-dessous :
où gestionnairex correspond à chacun des gestionnaires de périphériques pas sûrs en cas d'interruption.
2. Lorsque toutes les tâches de configuration DR sont terminées, réinitialisez le domaine pour que la configuration soit appliquée.
|
|
Dans le système d'exploitation Solaris 9, les unités de bande qui sont originellement prise en charge par Sun Microsystems sont sûres en cas d'interruption et de détachement. Pour obtenir la liste des unités originellement prises en charge, consultez la page de manuel st(7D). Si la carte système que vous détachez contient une unité de bande originellement prise en charge, vous pouvez détacher cette carte en toute sécurité sans interrompre le périphérique.
Toutefois, si vous voulez utiliser une unité de bande qui n'est pas originellement prise en charge par Sun Microsystems, vous pouvez l'utiliser mais devez faire en sorte qu'elle devienne sûre (en cas de détachement) en procédant comme suit.
1. Editez le fichier /kernel/drv/st.conf en saisissant une entrée appropriée comportant le repère ST_UNLOADABLE (0x0400). Pour plus d'informations, reportez-vous à la page de manuel st(7D).
2. Lorsque toutes les tâches de configuration DR sont terminées, réinitialisez le domaine pour valider la configuration.
Vous devez préparer une carte pour les opérations DR Detach en suivant les étapes décrites ci-après. Bien que la liste de tâches suivantes implique un ordre donné, respecter cet ordre n'est pas nécessaire. Ces étapes concernent les cartes contenant des E/S ou des périphériques hors réseau.
Démontez les systèmes de fichiers.
Par exemple, si vous utilisez des métapériphériques Solstice DiskSuite, vous devez démonter le système de fichiers des métapériphériques qui comportent une partition résidant sur une carte (par exemple, umount /partit).
Si vous possédez des périphériques pas sûrs (en cas d'interruption) qui gèrent des systèmes de fichiers, démontez ces systèmes de fichiers avant toute opération de détachement. Si vous devez manuellement interrompre des périphériques pas sûrs (en cas d'interruption) qui gèrent des systèmes de fichiers, verrouillez ceux-ci en utilisant la commande lockfs(1M) avant d'interrompre manuellement les périphériques pas sûrs.
 |
Attention - Démonter des systèmes de fichiers partagés avec l'utilitaire share(1M) peut avoir des conséquences au niveau des systèmes clients NFS. |
Supprimez les partitions de disques de la configuration de swap en utilisant swap(1M).
Si vous voulez détacher une carte qui héberge des contrôleurs Sun StorEdge A3000, désactivez ces contrôleurs ou mettez-les manuellement hors ligne en utilisant les programmes rm6 ou rdacutil.
La baie Sun StorEdge A3000 (auparavant dénommée RSM Array 2000) comporte des chemins de contrôleur doubles avec équilibrage de charge et reprise automatiques.
Fermez tous les périphériques hors réseau en procédant comme suit :
Fermez toutes les instances d'un périphérique en arrêtant les processus qui ouvrent directement un périphérique ou une partition brute, ou demandez-leur de fermer le périphérique ouvert sur la carte.
Exécutez modunload(1M) pour décharger chaque gestionnaire pas sûr (en cas de détachement) ou gestionnaire chargé.
Les processus liés aux processeurs d'une carte empêchent le détachement de la carte. Vous pouvez utiliser pbind(1M) pour les relier à d'autres processeurs.
Comment contrôler les conditions forcées qui affectent la mise au repos d'un système lors d'une opération DR Detach.
Les divers changements de configuration effectués par la fonctionnalité DR lors d'opérations DR Detach.
Si le système d'exploitation Solaris ne parvient pas à se mettre au repos lors d'une opération DR Detach impliquant une carte dotée d'une mémoire non-paginable, il en affiche les raisons. Par exemple, la présence d'un périphérique pas sûr en cas d'interruption ouvert ne pouvant pas être mis au repos par le système d'exploitation.
L'impossibilité de mettre le système au repos, à cause de périphériques ouverts pas sûrs (en cas d'interruption), est ce l'on appelle une condition forcée. Vous avez le choix entre faire une nouvelle tentative ou tenter d'imposer la mise au repos. Les conditions qui font que les processus ne s'interrompent pas sont généralement temporaires. Vous pouvez réessayer l'opération jusqu'à ce que la mise au repos réussisse.
Lorsque vous essayez d'imposer la mise au repos, vous permettez au système d'exploitation de s'arrêter en dépit de l'existence de conditions forcées. De cette manière, le système d'exploitation est forcé d'accepter l'opération de détachement. Notez que, même s'il est possible d'imposer la poursuite d'une opération de détachement lorsque des périphériques pas sûrs en cas d'interruption sont ouverts dans le système, il n'est pas possible d'imposer ce genre d'opération lorsqu'un périphérique pas sûr en cas de détachement réside sur la carte et que son gestionnaire est chargé.
| Remarque - Les processus en temps réel n'empêchent pas le système d'exploitation de se mettre au repos. |
La façon la plus directe de mettre le domaine au repos consiste à fermer tous les périphériques pas sûrs en cas d'interruption. Pour chaque gestionnaire de réseau vous devez exécuter la commande ifconfig(1M) avec le paramètre down, puis l'exécuter de nouveau avec le paramètre unplumb (pour plus d'informations, reportez-vous à ifconfig(1M)).
Si un périphérique pas sûr en cas d'interruption est ouvert et ne peut pas être fermé, vous pouvez interrompre manuellement le périphérique, puis imposer la mise au repos du système d'exploitation. Après la reprise du système d'exploitation, vous pouvez manuellement, relancez le périphérique comme expliqué ci-dessous.
|
|
1. Mettez fin à l'utilisation du périphérique en effectuant au moins une des opérations suivantes :
a. Fermez le périphérique en arrêtant les processus qui l'ont ouvert.
b. Demandez aux utilisateurs de ne pas utiliser le périphérique.
c. Débranchez les câbles du périphérique.
Par exemple, si un périphérique qui permet une entrée asynchrone qui n'est pas sollicitée est ouvert, vous pouvez débrancher ses câbles avant de mettre le système d'exploitation au repos, en empêchant que le trafic arrive au périphérique et que celui-ci accède au "centerplane" du domaine. Vous pouvez rebrancher les câbles après la reprise du système d'exploitation.
d. Déchargez le gestionnaire du périphérique en utilisant la commande modunload(1M).
2. Effectuez de nouveau l'opération DR.
a. Rechargez le périphérique en utilisant la commande modload(1M).
b. Rebranchez les câbles sur le périphérique.
c. Informez les utilisateurs que le périphérique peut de nouveau être utilisé.
Pour les opérations Solaris 9 (modèle DR 3.0), exécutez la commande deleteboard(1M) ou moveboard(1M) avec l'option -f.
Lorsque vous détachez une carte comportant de la mémoire non-paginable, DR repère une carte de mémoire de remplacement (cible) dans laquelle copier la mémoire non-paginable.
Si aucune carte cible n'est trouvée pour une opération copier-renommer, les commandes deleteboard(1M) et moveboard(1M) affichent les messages d'erreur suivants, dans l'ordre :
Le processeur d'initialisation est responsable de l'entretien du tampon BBSRAM netcon.
Avant de détacher une carte hébergeant un processeur d'initialisation, DR doit assigner la fonction de processeur d'initialisation à un autre processeur actif (en ligne).
Une opération Detach échouera s'il y a sur la carte ne serait-ce qu'une interface réseau remplissant au moins l'une des conditions suivantes. Dans ces cas, l'opération Detach échoue et la DR affiche un message d'erreur.
L'interface est l'interface réseau primaire du domaine ;
c.-à-d.,
l'interface dont l'adresse IP correspond au nom de l'interface réseau
contenu
dans le fichier
/etc/nodename.
Notez que le fait de désactiver l'interface réseau primaire du domaine empêche les services de noms d'information réseau de fonctionner, il s'ensuit qu'il devient impossible d'établir des connexions réseau avec des hôtes distants en utilisant des applications telles que ftp(1), rsh(1), rcp(1), rlogin(1). Les opérations serveur et client NFS sont aussi affectées.
L'interface est sur le même sous-réseau que l'hôte SSP du
système ; c.-à-d., le sous-réseau de l'adresse IP qui
correspond au nom de l'hôte SSP trouvé dans
/etc/ssphostname.
Le fait de désactiver cette interface interrompt la communication entre l'hôte et le SSP. Etant donné que les opérations DR sont lancées sur le SSP, vous risqueriez de perdre le contrôle de l'opération de détachement. Notez que le fichier /etc/ssphostname contient le nom du SSP qui contrôle l'hôte ; par conséquent, si vous renommez le SSP, /etc/ssphostname doit être manuellement mis à jour.
 |
Attention - Le détachement des interfaces réseau peut affecter les systèmes client NFS. |
Dans les domaines Solaris 9, le serveur de configuration du domaine, dcs(1M), contrôle les opérations DR.
 | Résolution d'un problème d'interruption de la connexion pendant une opération (DR modèle 3.0) Solaris 9 |
dcs(1M) doit être configuré dans le fichier /etc/inetd.conf du domaine. Les lignes suivantes doivent figurer dans le fichier :
2. Si le démon dcs est configuré dans /etc/inetd.conf, arrêtez dcs(1M) s'il est en cours d'exécution. Envoyez aussi un signal HUP au démon inetd(1M) pour qu'il relise le fichier de configuration inetd.conf(4) :
Où idp_dcs est l'ID de processus du démon dcs(1M) et idp_inetd l'ID de processus du démon inetd(1M).
3. Vérifiez dans le fichier /var/adm/messages si des messages d'erreur proviennent de inetd(1M) s'il rencontre des difficultés pour lancer dcs(1M).
Le fichier exécutable du démon dcs(1M) devrait se trouver dans le répertoire /usr/lib.
4. A ce stade, réessayez l'opération DR en recommençant tout depuis le début.
| Guide de configuration DR d'un domaine Sun Enterprise 10000 | 816-4656-10 |
|
