Chapitre 1 Problèmes liés à la configuration DR

Ce chapitre explique comment configurer un domaine pour toutes les opérations et fonctions DR.

Choisissez avec soin l'emplacement dans lequel vous allez insérer une carte pour éviter la renumérotation des contrôleurs de disque. Pour plus d'informations, reportez-vous à "Reconfiguration après une opération DR".

La variable dr-max-mem

Avec les environnements d'exploitation Solaris 7 et Solaris 8, la variable dr-max-mem n'est plus utilisée. A la place, la fonctionnalité DR, et plus exactement l'opération DR de détachement, doit être autorisée en utilisant la variable kernel_cage_enable de system(4). 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 les opérations DR de détachement.

L'opération DR attach est possible quelle que soit la valeur de la variable kernel_cage_enable.

Pour activer la "cage" du noyau

1. Editez le fichier /etc/system de sorte que kernel_cage_enable soit égal à 1.

   set kernel_cage_enable=1

2. Réinitialisez le domaine.

   Après avoir réussi la réinitialisation, vous pouvez vérifier que la "cage" du noyau est activée en recherchant dans le fichier /var/adm/messages le message suivant.

   NOTICE: DR Kernel Cage is ENABLED

Configuration avant une opération DR Detach

Cette section explique comment configurer la DR avant d'effectuer une opération de détachement.

Unités E/S

L'opération DR de détachement fonctionne avec Alternate Pathing (AP) ou l'écriture miroir Solstice(TM) DiskSuite(TM) lorsque vous détachez une carte qui héberge des contrôleurs E/S rattachés à des ressources système essentielles. Si, par exemple, la partition racine (/) ou /usr se trouve sur un disque attaché à un contrôleur de la carte, la carte ne peut être détachée que s'il existe un chemin matériel alternatif d'accès au disque, si AP a été configuré pour en profiter ou si le disque a été doublé par écriture miroir. Le chemin alternatif ou les miroirs doivent être hébergés par d'autres cartes dans le domaine. La même chose s'applique aux contrôleurs réseau. La carte qui héberge le contrôleur Ethernet qui connecte le SSP à la plate-forme Sun Enterprise 10000 ne peut pas être détachée à moins qu'un chemin alternatif d'accès à un contrôleur Ethernet existe sur une autre carte pour cette connexion de réseau.

Pour activer l'interruption du périphérique pour les gestionnaires soc et pln, vous devez éditer le fichier /etc/system pour que les variables pln_enable_detach_suspend et soc_enable_detach_suspend soient programmées sur 1, comme dans l'exemple suivant :

set pln:pln_enable_detach_suspend=1
set soc:soc_enable_detach_suspend=1

La zone de swap du domaine doit être configurée en plusieurs partitions sur des disques attaché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)).

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.

Une carte qui héberge des ressources système qui ne sont pas essentielles peut être détachée, indépendamment de l'existence de chemins alternatifs d'accès aux ressources. Fermez tous les périphériques de la carte avant de la détacher ; démontez tous ses systèmes de fichiers et supprimez ses partitions de swap. Il se peut que vous ayez à arrêter les processus ayant provoqué l'ouverture de fichiers ou de périphériques ou à placer un verrou matériel sur les systèmes de fichiers (en utilisant lockfs(1M)) avant de démonter les cartes.

Tous les gestionnaires des unités E/S de la ou des cartes doivent supporter l'option DDI_DETACH au point d'entrée de détachement du gestionnaire. Cette option libère toutes les ressources système associées à ce périphérique ou cet adaptateur.

Paramètres des gestionnaires

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 d'attachement ou de détachement. Utilisez le fichier /etc/system ou driver.conf d'un gestionnaire donné pour définir des paramètres permanents.

Contraintes liées à la mémoire cible

Lorsque vous détachez une carte comportant de la mémoire non-paginable, DR doit repérer une carte de mémoire de remplacement (cible) dans laquelle copier la mémoire non-paginable. Dans la version Solaris 7 5/99, si aucune carte cible n'est trouvée, l'opération de détachement est refusée et DR affiche le message d'avertissement suivant sur la console du système :

WARNING: sfdr: sfdr_pre_release_mem: no available target for mem-unit (board.0)

Zone de swap

La configuration de swap du domaine se compose de 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 le détachement d'une carte qui contient de la mémoire. Si cela se produit, la phase de vidage de la mémoire ne peut pas être exécutée et vous êtes contraint à abandonner l'opération de détachement.

Périphériques réseau

DR met automatiquement fin à l'utilisation de toutes les interfaces réseau sur la carte qui va être détachée. Lorsque vous terminez l'opération Detach, le dr_daemon(1M) identifie toutes les interfaces configurées sur la carte qui va être détachée et émet les commandes ifconfig(1M) suivantes sur chacune de ces interfaces.

ifconfig interface down
ifconfig interface unplumb

De plus, si des interfaces de type FDDI sont détachées, la fonctionnalité DR arrête le démon de surveillance du réseau FDDI avant l'exécution de l'opération Detach et le relance après. Notez que le démon /usr/sbin/nf_snmd des périphériques nf n'est ni lancé ni arrêté lorsqu'une carte qui contient une interface FDDI est attachée.

DR n'exécute pas ces commandes sur une carte qui contient 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.)

• L'interface est le chemin alternatif actif d'un métapériphérique Alternate Pathing (AP) lorsque le métapériphérique AP est plombé. Les interfaces utilisées par AP ne doivent pas servir de chemin actif lorsque la carte est détachée. AP 2.1 effectue automatiquement la commutation ; toutefois, vous pouvez commuter manuellement le chemin actif sur une interface qui n'est pas sur la carte détachée. Si ce chemin n'existe pas, exécutez manuellement les commandes ifconfig down et ifconfig unplumb sur l'interface AP (pour commuter manuellement un chemin actif, utilisez la commande apconfig(1M)).

Le détachement des interfaces réseau peut affecter les systèmes client NFS.

Périphériques hors réseau

Tous les périphériques qui sont en dehors du réseau doivent être fermés avant d'être détachés. La fenêtre des périphériques Hostview et la liste E/S drshow(1M) comportent un champ de décompte des périphériques ouverts, qui indique combien de processus ont ouvert des périphériques particuliers. Pour savoir quels processus provoquent l'ouverture de ces périphériques, utilisez la commande fuser(1M) sur le domaine.

Vous devez effectuer certaines opérations pour les périphériques qui ne sont pas en réseau. Bien que la liste de tâches suivante implique un ordre donné, respecter cet ordre n'est pas nécessaire.

1. Si les fonctionnalités de redondance de Alternate Pathing ou d'écriture miroir Solstice DiskSuite sont utilisées pour accéder à un périphérique connecté à la carte, reconfigurez ces sous-systèmes pour que le périphérique ou le réseau soit accessible en utilisant les contrôleurs d'autres cartes système. Notez qu'avec Alternate Pathing 2.1, le système commute automatiquement les unités de disque sur une interface de remplacement s'il y en a une.

2. Démontez les systèmes de fichiers, y compris les métapériphériques Solstice DiskSuite qui comportent une partition résidant sur une carte (par exemple, umount /partit).

3. Supprimez les bases de données Alternate Pathing ou Solstice DiskSuite des partitions résidant sur la carte. L'emplacement des bases de données Alternate Pathing ou Solstice DiskSuite est explicitement choisi par l'utilisateur et peut être modifié.

4. Supprimez les régions privées utilisées par Sun Enterprise Volume Manager(TM) ou Veritas Volume Manager. Le gestionnaire de volumes utilise par défaut une région privée sur chacun des périphériques qu'il contrôle, par conséquent ces périphériques doivent être soustraits au contrôle du gestionnaire de volume avant d'être détachés.

5. Supprimez les partitions de disque de la configuration de swap en utilisant swap(1M).

6. Arrêtez 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.

7. Si un périphérique pas sûr en cas de détachement (detach-unsafe) se trouve sur la carte, fermez toutes les instances de ce périphérique et utilisez modunload(1M) pour décharger le gestionnaire.

8. Arrêtez tous les processus en temps réel qui sont ouverts si l'environnement d'exploitation doit être interrompu.

Le démontage de systèmes de fichiers partagés avec l'utilitaire share(1M) peut affecter les systèmes clients NFS.

Processus

Vous devez effectuer certaines opérations pour les processus. Bien que la liste de tâches suivante implique un ordre donné, respecter cet ordre n'est pas nécessaire.

1. Si l'environnement d'exploitation doit être interrompu, arrêtez tous les processus en temps réel ouverts.

2. Arrêtez ou déconnectez tous les processus liés aux processeurs de la carte.

   Les processus liés aux processeurs d'une carte empêchent le détachement de cette carte. Vous pouvez utiliser pbind(1M) pour les relier à d'autres processeurs.

Processeurs

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, le dr_daemon(1M) doit assigner la fonction de processeur d'initialisation à un autre processeur actif (en ligne).

Reconfiguration après une opération DR

Cette section explique comment reconfigurer le domaine après l'attachement ou le détachement d'une carte système.

Pour la version Solaris 8 GA, la reconfiguration manuelle n'est plus nécessaire. Un nouveau sous-système DDI, devfsadm, effectue l'ensemble des tâches de reconfiguration.

L'interface utilisateur DR vous permet de reconfigurer le domaine après une opération DR Attach ou DR Detach. La séquence de reconfiguration est identique à la séquence d'initialisation de reconfiguration (boot -r):

drvconfig; devlinks; disks; ports; tapes;

Lorsque vous exécutez la séquence de reconfiguration après avoir attaché une carte, les chemins des périphériques que le domaine n'a pas encore vus sont écrits sur le fichier /etc/path_to_inst. Les mêmes chemins sont également ajoutés à la hiérarchie /devices et des liens avec ces chemins sont créés dans le répertoire /dev.

A quel moment reconfigurer

Vous devez reconfigurer le domaine si l'une des conditions suivantes se présente :

• Ajout d'une carte - Lorsque vous ajoutez une carte à un domaine, vous devez exécuter la séquence de reconfiguration pour configurer les unités E/S qui sont associées à cette carte.

• Suppression d'une carte - Si vous enlevez une carte qui ne doit pas être remplacée, vous pouvez, mais n'êtes pas obligé de le faire, exécuter la séquence de reconfiguration pour effacer les liens /dev.

• Remplacement d'une carte - Si vous enlevez une carte puis la réinsérez dans un emplacement différent ou si vous remplacez une carte par une carte dont les unités E/S sont différentes, vous devez exécuter la séquence de reconfiguration pour configurer les unités E/S qui sont associées à la carte. Toutefois, si vous remplacez une carte par une carte qui héberge le même ensemble d'unités E/S et insérez la nouvelle carte dans le même emplacement, vous n'avez pas besoin d'exécuter la séquence de reconfiguration. Veillez toutefois à insérer la nouvelle carte dans l'emplacement qui a été vidé pour conserver la mise en correspondance originale des liens /dev et des noms physiques.

Unités de disque

Les contrôleurs de disque sont numérotés consécutivement à mesure qu'ils sont détectés par le programme disks(1M). Toutes les partitions de disque reçoivent un nom /dev en fonction du numéro que le programme disks(1M) assigne à chaque contrôleur. Par exemple, toutes les partitions de disque qui sont accessibles en utilisant le contrôleur de disque 1 sont nommées /dev/dsk/cXtYdZsW

où :

X correspond au numéro du contrôleur de disque,

Y, dans la plupart des cas, correspond au numéro de disque cible,

Z correspond au numéro de l'unité logique, et

W correspond au numéro de la partition.

Lorsque la séquence de reconfiguration est exécutée après le détachement d'une carte, les liens /dev de toutes les partitions de disque de cette carte sont supprimés. Les cartes restantes conservent leur numéro courant. Le premier numéro disponible suivant le numéro le plus bas est attribué par le programme disks(1M) aux contrôleurs de disque de la carte qui vient d'être insérée.

Le numéro du contrôleur de disque fait partie du nom de liaison /dev utilisé pour accéder au disque. Si ce numéro change pendant la séquence de reconfiguration, le nom de liaison /dev change aussi. Il se peut que ce changement affecte les tableaux d'un système de fichiers et le logiciel, tel que Solstice DiskSuite^TM, qui utilise les noms de liaison /dev. Mettez à jour les fichiers /etc/vfstab et exécutez les tâches administratives appropriées pour modifier les noms de liaison /dev.

Interaction des fonctionnalités DR et AP

La DR avise le sous-système AP lorsque des cartes système sont attachées, détachées ou placées en état de vidage. De plus, DR interroge AP pour savoir quels contrôleurs se trouvent dans la base de données AP et connaître leur état (actifs ou inactifs). Cette communication a lieu entre dr_daemon(1M) et ap_daemon(1M). Si ap_daemon(1M) est absent, un message d'erreur est placé dans la mémoire tampon des messages du journal système du domaine et les opérations DR se poursuivent sans erreur. Pour désactiver cette interaction, utilisez l'option -a lorsque vous sollicitez le dr_daemon(1M). Reportez-vous à la page de manuel dr_daemon(1M) dans le Sun Enterprise 10000 Dynamic Reconfiguration Reference Manual.

Si vous utilisez AP version 2.1, l'environnement d'exploitation déconnecte automatiquement les contrôleurs de disque des cartes sortantes pendant l'exécution d'une opération DR Complete Detach. Si vous utilisez AP version 2.0, vous devez déconnecter manuellement les contrôleurs de disque actifs avant de lancer l'opération DR Complete-Detach. Avec Solaris 8, vous devez effectuer une mise à niveau vers AP version 2.3. Pour plus d'informations sur l'interaction des fonctionnalités DR et AP, reportez-vous au Guide de l'utilisateur de la fonctionnalité Alternate Pathing 2.3 sur les serveurs Sun Enterprise. Pour plus d'informations sur AP et SDS, reportez-vous à RAS Companion.

Dépassement du délai imparti ou interruption de la connexion RPC

Le démon dr_daemon(1M), qui est exécuté dans chaque domaine, communique avec l'interface Hostview et l'application shell dr(1M) (exécutées toutes deux sur le SSP) au moyen d'appels RPC (Remote Procedure Calls). Si un dépassement du délai imparti ou un échec de connexion est signalé pendant une opération DR, vérifiez le domaine. Le démon doit être configuré dans le fichier /etc/inetd.conf du domaine. La ligne suivante (qui tient sur une seule ligne) doit figurer dans le fichier :

300326/4 tli rpc/tcp wait root \
/platform/SUNW,Ultra-Enterprise-10000/lib/dr_daemon/ dr_daemon

Si le démon DR est configuré dans /etc/inetd.conf, arrêtez le dr_daemon(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) :

# kill pid_démon_dr
# kill -HUP pid_inetd

Dans la première commande, pid_démon_dr est l'ID des processus du démon DR. Dans la deuxième commande, pid_inetd est l'ID des processus du démon inetd(1M). Vous pouvez vérifier dans /var/adm/messages si des messages d'erreur proviennent de inetd(1M) s'il rencontre des difficultés pour lancer dr_daemon(1M). Le fichier exécutable du démon DR devrait se trouver dans le répertoire /platform/SUNW,Ultra-Enterprise-10000/lib.

A ce stade, réessayez l'opération DR en recommençant tout depuis le début.

Mise au repos du système

Pendant une opération DR Detach sur une carte système comportant de la mémoire OBP ou noyau non-paginable, l'environnement d'exploitation est mis au repos pendant une courte durée : l'activité de l'environnement d'exploitation et des périphériques sur le "centerplane" du domaine doit cesser pendant la phase critique de l'opération. Cette mise au repos n'affecte que le domaine cible, les autres domaines du système sont épargnés.

Avant qu'il soit possible de détacher une carte, l'environnement d'exploitation doit temporairement interrompre tous les processus, processeurs et périphériques. Si l'environnement d'exploitation ne peut pas se mettre au repos, il affiche ses raisons comme, par exemple :

• Des processus en temps réel sont en cours d'exécution dans le domaine.

• Un périphérique qui ne peut pas être mis au repos par l'environnement d'exploitation (c'est-à-dire, un périphérique pas sûr en cas d'interruption) est ouvert.

Les conditions empêchant l'interruption des processus sont généralement temporaires. Vous pouvez réessayer l'opération jusqu'à ce que vous arriviez à finalement mettre le système d'exploitation au repos.

L'impossibilité de mettre le système au repos à cause de processus en temps réel ou de périphériques ouverts pas sûrs (en cas d'interruption) donne lieu à une condition que l'on appelle forcée. Vous avez le choix entre faire une nouvelle tentative ou forcer la mise au repos. Lorsque vous forcez la mise au repos, vous permettez à l'environnement d'exploitation de s'arrêter en dépit de l'existence de conditions forçables.

Utilisez l'option force avec précaution.

Si un processus en temps réel est en cours, déterminez si l'interruption du processus risque d'avoir un effet indésirable sur les fonctions du processus. Sinon, vous pouvez forcer la mise au repos de l'environnement d'exploitation. Pour forcer la mise au repos, cliquez sur le bouton Force dans Hostview comme décrit dans "Pour détacher une carte avec Hostview" dans le Guide de la fonctionnalité Dynamic Reconfiguration sur le serveur Sun Enterprise 10000, collection SSP 3.3 AnswerBook2 ou entrez la commande complete_detach(1M) avec l'option force dans l'application shell dr(1M). Sinon, abandonnez l'opération et réessayez ultérieurement.

Si un des périphériques pas sûr (en cas d'interruption) est ouvert et ne peut pas être fermé, vous pouvez manuellement couper le périphérique, puis forcer la mise au repos de l'environnement d'exploitation. Après la reprise de l'environnement d'exploitation, vous pouvez relancer manuellement le périphérique (reportez-vous à "Périphériques sûrs/pas sûrs en cas d'interruption").

Périphériques sûrs/pas sûrs en cas d'interruption

Un périphérique suspend-safe (sûr en cas d'interruption) est un périphérique qui n'a pas accès au "centerplane" du domaine (par exemple, il n'a pas accès à la mémoire ou ne peut pas interrompre le système) lorsque l'environnement d'exploitation est mis au repos. Un gestionnaire est considéré comme étant sûr (en cas d'interruption) s'il supporte la mise au repos de l'environnement d'exploitation (interruption/reprise) et garantit que lors de l'exécution d'une demande d'interruption, le périphérique qu'il contrôle n'essaiera pas d'accéder au "centerplane" du domaine, même si le périphérique est ouvert lorsque la demande d'interruption est faite. Tous les autres périphériques E/S sont suspend-unsafe (pas sûrs en cas d'interruption) lorsqu'ils sont ouverts.

Au moment de l'impression de ce document, les gestionnaires Sun Microsystems^TM suspend-safe (sûrs en cas d'interruption) connus sont les gestionnaires st, sd, isp, esp, fas, sbus, pci, pci-pci, qfe, hme (SunFastEthernet^TM), nf (NPI-FDDI), qe (Quad Ethernet), le (Lance Ethernet), les gestionnaires SSA (soc, pln et ssd) et les gestionnaires Sun StorEdge^TM A5000 (sf, socal, ses).

Pour activer l'interruption des gestionnaires soc et pln, vous devez éditer le fichier /etc/system pour que les variables pln_enable_detach_suspend et soc_enable_detach_suspend soient programmées sur 1, comme dans l'exemple suivant :

set pln:pln_enable_detach_suspend=1
set soc:soc_enable_detach_suspend=1

L'environnement d'exploitation refuse une demande de mise au repos si un périphérique pas sûr (en cas d'interruption) est ouvert. Si vous coupez manuellement le périphérique, vous pouvez forcer la mise au repos de l'environnement d'exploitation. Pour couper le périphérique manuellement, il se peut que vous ayez à le fermer en arrêtant les processus qui l'ont ouvert, demandez aux utilisateurs de ne pas utiliser le périphérique ou débranchez les câbles. 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 l'environnement 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 de l'environnement d'exploitation. Si vous ne réussissez pas à couper un périphérique pour l'empêcher d'accéder au "centerplane" du domaine, il vaut mieux ne pas forcer la mise au repos de l'environnement d'exploitation car vous risqueriez de faire échouer le domaine. Par contre, vous pouvez remettre l'opération DR à plus tard en attendant que le périphérique pas sûr (en cas d'interruption) ne soit plus ouvert.

Si vous tentez d'effectuer une mise au repos forcée lors du fonctionnement d'un périphérique pas sûr (en cas d'interruption), vous risquez de faire échouer le domaine. Toutefois, si le domaine échoue, les autres domaines exécutés sur le système Sun Enterprise 10000 ne sont pas affectés.

Gestion spéciale des unités de bande

Dans l'environnement d'exploitation Solaris 8, les unités de bande originellement prises en charge par Sun Microsystems^TM sont sûres en cas d'interruption et de détachement (consultez st(7D) pour la liste des unités originellement prises en charge). Si la carte système que vous détachez contient une unité de bande originelle prise en charge, vous pouvez détacher la carte en toute sécurité sans couper le périphérique. Si vous voulez utiliser une unité de bande qui n'est pas originellement prise en charge par Sun Microsystems, vous pouvez l'utiliser, mais faites en sorte qu'elle devienne sûre (en cas détachement). Pour vous assurer que les entrées/sorties et les opérations DR soient correctes, vous devez saisir une entrée appropriée dans /kernel/drv/st.conf comportant le repère ST_UNLOADABLE (0x0400) (reportez-vous à st(7D) pour plus d'informations). Après avoir mis à jour st.conf, vous devez réinitialiser le domaine pour traiter la nouvelle entrée.

Gestion spéciale de Sun StorEdge A3000

Sun StorEdge^TM A3000 (auparavant dénommé RSM Array 2000) comporte des chemins à double contrôleur à équilibrage de charge et reprise automatiques. Pour détacher une carte système qui contient un ou les contrôleurs StorEdge A3000, les contrôleurs de la carte que vous détachez doivent être inactifs ou hors ligne. Vous pouvez mettre ces contrôleurs hors ligne manuellement en utilisant les programmes rm6 ou rdacutil avant d'essayer de détacher la carte système.

DR et DDI

Tous les gestionnaires ne supportent pas les fonctionnalités de reconfiguration dynamique (DR) du système Sun Enterprise 10000. Pour prendre en charge la DR, un gestionnaire doit pouvoir effectuer les deux fonctions DDI/DKI (Device Driver Interface/Device Kernel Interface) de base, DDI_DETACH et DDI_SUSPEND/DDI_RESUME Ces deux fonctions influent sur la DR de diverses manières.

DR et DDI_DETACH

Vous pouvez détacher une carte système qui héberge un périphérique seulement si le gestionnaire de ce périphérique prend en charge l'interface DDI_DETACH ou s'il n'est pas couramment chargé. DDI_DETACH permet de détacher une instance particulière d'un gestionnaire sans affecter les instances qui prennent en charge d'autres périphériques. Un gestionnaire qui prend en charge DDI_DETACH est qualifié de detach-safe (sûr en cas de détachement); un gestionnaire qui ne prend pas en charge DDI_DETACH est qualifié de detach-unsafe (pas sûr en cas de détachement).

Le détachement d'un gestionnaire pas sûr (en cas de détachement) chargé implique :

• l'arrêt de l'utilisation du contrôleur du périphérique pas sûr (en cas de détachement) et de tous les autres contrôleurs du même type sur toutes les cartes du domaine.

  Etant donné que le gestionnaire pas sûr (en cas de détachement) doit être déchargé, vous devez arrêter d'utiliser ce type de contrôleur sur toutes les cartes système du domaine. Les autres contrôleurs peuvent de nouveau être utilisés après l'exécution de l'opération DR de détachement.

• L'utilisation d'interfaces standard Solaris pour fermer manuellement et décharger tous ces gestionnaires sur la carte.

  Reportez-vous à la page de manuel modunload(1M) dans le SunOS Reference Manual.

• Le détachement de la carte système se fait de manière normale.

Si vous ne pouvez pas faire ce qui précède, réinitialisez le domaine avec la carte qui est sur la liste noire (reportez-vous à blacklist(4)), afin de retirer la carte ultérieurement.

De nombreux gestionnaires d'autres marques (pas achetés chez Sun Microsystems) ne prennent pas en charge l'interface standard Solaris modunload(1M). Les conditions sollicitant les gestionnaires ne se présentent pas régulièrement dans le cadre du fonctionnement normal et les fonctionnalités requises sont parfois absentes 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 de tierce partie.

DR et DDI_SUSPEND/DDI_RESUME

Pour effectuer l'opération DR pour détacher une carte qui contient de la mémoire non paginable, mettez le domaine au repos. La mémoire ne peut être détachée qu'à partir du moment où tous les gestionnaires du domaine (pas seulement sur la carte qui va être détachée) prennent en charge l'interface de gestionnaires DDI_SUSPEND/DDI_RESUME ou s'ils sont tous fermés. Les gestionnaires qui prennent en charge les fonctions DDI sont qualifiés de sûrs en cas d'interruption (suspend-safe); les gestionnaires qui ne les prennent pas en charge sont qualifiés de pas sûrs en cas d'interruption (suspend-unsafe).

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 de l'exécuter de nouveau avec le paramètre unplumb (pour plus d'informations, reportez-vous à ifconfig(1M)).

Il devrait être possible de déplomber tous les gestionnaires de réseau. Toutefois, cette action est rarement testée dans les environnements habituels et peut provoquer des conditions d'erreur de gestionnaire. Si vous utilisez DR, Sun Microsystems suggère que vous testiez les fonctions des gestionnaires pas sûr en cas d'interruption pendant les phases de qualification et d'installation.

Si le système refuse de se mettre au repos parce qu'un gestionnaire pas sûr (en cas d'interruption) est ouvert, vous pouvez forcer la mise au repos du domaine. De cette manière, l'environnement d'exploitation est forcé d'accepter l'opération de détachement. Notez que, même s'il est possible de forcer la poursuive d'une opération de détachement lorsque des périphériques pas sûr en cas d'interruption sont ouverts dans le système, il n'est pas possible de forcer 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é.

Pour réussir à forcer la mise au repos de l'environnement d'exploitation, vous devez mettre manuellement le contrôleur au repos. Les procédures, éventuelles, permettant de le faire sont propres aux périphériques. Le périphérique ne doit pas transférer de données, de mémoire de référence ou provoquer d'interruptions pendant le fonctionnement. Veillez à tester les procédures utilisées pour mettre le contrôleur ouvert au repos avant de les exécuter sur un système de production.

L'utilisation de l'option force pour mettre l'environnement d'exploitation au repos, sans mettre tout d'abord le contrôleur au repos, risque de faire échouer le domaine et d'entraîner une réinitialisation.