test

Guide de l'utilisateur de la fonctionnalité Dynamic Reconfiguration sur le serveur Sun Enterprise 10000

Chapitre 2 Configuration de la fonctionnalité DR

Ce chapitre explique comment configurer un domaine pour toutes les opérations et fonctionnalités DR. Dans l'environnement d'exploitation Solaris 2.5.1 et Solaris 2.6 5/98, la fonctionnalité DR n'est activée que lorsque la variable OpenBoot(TM) PROM (OBP), dr-max-mem, est programmée sur une valeur différente de zéro. Dans la version Solaris 7 5/99, la variable dr-max-mem n'est plus utilisée.

Attention : Attention :

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

Mémoire : dr-max-mem

La valeur de dr-max-mem dépend de la version de l'environnement d'exploitation Solaris (2.5.1, 2.6 ou 2.7) utilisée dans le domaine.

Remarque :

Dans Solaris 2.5.1 et Solaris 2.6 5/98, la fonctionnalité DR est désactivée sur des domaines qui disposent de moins de 512 Mo de mémoire. Cette limite de mémoire n'existe pas avec Solaris 7 5/99.

La variable dr-max-mem avec Solaris 7 5/99

Avec Solaris 7 5/99, la variable dr-max-mem n'est plus utilisée. Par contre, la fonctionnalité DR, notamment l'opération DR de détachement, doit être activée en utilisant la variable system(4), kernel_cage_enable. Un noyau en "cage" limite la mémoire non paginable à un petit nombre de cartes système (à un en général). Par défaut, la "cage" du noyau est désactivée, empêchant les opérations DR de détachement.

Remarque :

L'opération DR Attach est activée quelle que soit la valeur de la variable kernel_cage_enable.

Pour activer la "cage" du noyau

  1. Editez le fichier /etc/system pour 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 attaché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 que 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 de 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.

Remarque :

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.

L'espace de swap du domaine doit être configuré 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)).

Remarque :

Lorsque la mémoire (swapfs) ou l'espace de swap d'un disque est détaché, il doit rester suffisamment de mémoire ou d'espace de swap dans le domaine pour l'accueil des 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.

Mémoire

Si vous utilisez l'entrelacement de mémoire entre les cartes système, ces cartes système ne peuvent pas être détachées car la fonctionnalité DR ne prend pas encore en charge l'entrelacement des cartes. Par défaut, hpost(1M) n'installe pas de cartes à mémoire entrelacée. Dans le fichier hpost(1M), .postrc, (reportez-vous à postrc(4)) recherchez la ligne suivante : 

mem_board_interleave_ok

Si mem_board_interleave_ok est présent, il se peut que vous ne puissiez pas détacher une carte qui utilise l'entrelacement de mémoire.

Remarque :

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 pour qu'un gestionnaire spécifique définisse des paramètres permanents.

Mémoire paginable et non paginable

Avant de détacher une carte, laissez le système d'exploitation vider la mémoire de cette carte. Vider une carte signifie transférer sa mémoire paginable sur un espace de swap et copier sa mémoire non paginable (c.-à-d., noyau et mémoire OBP) sur une autre carte mémoire. Pour transférer une mémoire non paginable, l'environnement d'exploitation d'un domaine doit être temporairement interrompu, ou mis au repos. La durée de l'interruption dépend de la configuration des E/S du domaine et des charges de travail en cours. L'environnement d'exploitation n'est interrompu qu'à l'occasion du détachement d'une carte à mémoire non paginable ; par conséquent, vous devez savoir où se trouve la mémoire non paginable, pour éviter de perturber le fonctionnement du domaine. Lorsque la carte contient une mémoire permanente, l'environnement d'exploitation doit trouver une autre mémoire pour la copier.

Vous pouvez utilisez la commande dr(1M), drshow(1M), pour savoir si la mémoire d'une carte est paginable ou non : 

% dr
dr> drshow board_number mem

De même, vous pouvez savoir si la mémoire d'une carte est paginable en regardant la fenêtre Configuration de la mémoire DR, qui s'affiche lorsque vous effectuez une opération de détachement dans Hostview. La fenêtre de configuration de la mémoire DR est décrite dans "Visualisation des informations relatives au domaine".

Avec Solaris 7 5/99, le noyau et la variable OBP se chargent dans l'espace d'adresse physique le plus élevé, c'est-à-dire l'espace qui se trouve en général sur la carte système qui porte le numéro le plus élevé dans le domaine. Il existe des exceptions à cette règle, vous devriez donc toujours utiliser la commande drshow(1M) pour contrôler la mémoire disponible sur la carte.

Contraintes liées à la mémoire cible

Lorsqu'une mémoire permanente est détachée, la DR choisit une zone de mémoire cible pour y copier la mémoire. La fonctionnalité DR vérifie automatiquement si cette zone correspond parfaitement à la quantité de mémoire à copier. La mémoire ne sera pas copiée si la fonctionnalité DR ne peut pas vérifier que l'espace disponible correspond bien au besoin. L'opération DR de mémoire peut être désactivée pour les raisons suivantes :

Dans la version 7 5/99 de Solaris, si aucune carte cible n'est trouvée, l'opération de détachement est refusée et la DR affiche sur la console le message d'avertissement suivant : 

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

Erreurs de mémoire corrigibles

Les erreurs de mémoire corrigibles indiquent que la mémoire d'une carte système (c.-à-d., un ou plusieurs de ses modules de mémoire à double rangée de connexions (DIMM, Dual Inline Memory Modules) ou portions de l'interconnexion matérielle) est défectueuse et doit être remplacée. Lorsque le SSP détecte des erreurs de mémoire corrigibles, il lance un vidage de type enregistrement-arrêt (record-stop) pour sauvegarder les données de diagnostic qui peuvent interférer avec une opération DR de détachement. Par conséquent, Sun Microsystems suggère que lorsqu'un enregistrement-arrêt se produit à partir d'une erreur de mémoire corrigible, vous laissiez le vidage de type enregistrement-arrêt se terminer avant de lancer une opération DR de détachement.

Si le composant défectueux provoque la signalisation répétée d'erreurs de mémoire corrigibles, le SSP effectue plusieurs vidages de type enregistrement-arrêt. Si cela se produit, désactivez temporairement le mécanisme de détection de vidage du SSP, laissez se terminer le vidage courant, puis lancez l'opération DR de détachement. Lorsque cette opération est terminée, réactivez le mécanisme de détection du vidage.

Pour réactiver la détection du vidage

  1. Connectez-vous au SSP en tant qu'utilisateur ssp.

  2. Désactivez la détection du vidage de type enregistrement-arrêt : 

    SSP% edd_cmd -x stop

    Cette commande interrompt la détection de tous les événements sur tous les domaines.

  3. Surveiller le vidage de type enregistrement-arrêt en cours : 

    SSP% ps -ef | grep hpost

    Dans la sortie grep(1), l'option -D de hpost indique qu'un vidage de type enregistrement-arrêt est en cours.

  4. Effectuez l'opération DR Detach.

  5. Activez la détection des événements : 

    SSP% edd_cmd -x start

Espace de Swap

La configuration swap du domaine se compose de périphériques de swap et d'une mémoire, swapfs. Le domaine doit contenir suffisamment d'espace de swap 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 d'espace de swap, en fonction de la charge. Un espace de swap insuffisant 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, vous devez donc abandonner l'opération de détachement.

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.

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 la 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 devriez reconfigurer le domaine si l'une des conditions suivantes se présente :

Unités de disque

Les contrôleurs de disque sont numérotés consécutivement à mesure que le programme disks(1M) les détecte. 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.

Remarque :

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, 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 dans l'état de vidage. De plus, DR interroge AP pour savoir quels contrôleurs se trouvent dans la base de données AP et 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 7 5/99, vous devez effectuer une mise à niveau vers AP version 2.2. 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.2 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 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 exister dans le fichier : 

300326/4 tli rpc/tcp wait root \
/platform/SUNW,Ultra-Enterprise-10000/lib/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 dr_daemon_pid
# kill -HUP inetd_pid

Dans la première commande, dr_daemon_pid est l'ID des processus du démon DR. Dans la deuxième commande, inetd_pid 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 avec noyau ou mémoire OBP non paginable, l'environnement d'exploitation est mis au repos pendant une courte durée; c'est-à-dire que 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. La mise au repos n'affecte que le domaine cible ; les autres domaines du système étant épargnés.

Avant de se mettre au repos, 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 :

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 forcées.

Attention : Attention :

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" ou entrez la commande complete_detach avec l'option force dans l'application shell dr(1M). Sinon, abandonnez l'opération et reéssayez 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").

Si l'environnement d'exploitation ne réussit pas à se mettre au repos, faites particulièrement attention aux raisons de cet échec. Si une condition passagère se présente et, par exemple, empêche l'environnement d'exploitation d'arrêter un processus--vous pouvez reéssayer l'opération. Si, toutefois, la ou les conditions nécessitent votre approbation (par exemple, un processus en temps réel est en cours d'exécution) ou votre intervention (par exemple, un périphérique pas sûr en cas d'interruption (suspend-unsafe) est ouvert, vous pouvez forcer la mise au repos de l'environnement d'exploitation.

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.

Remarque :

Au moment de l'impression de ce document, les gestionnaires Sun MicrosystemsTM suspend-safe (sûrs en cas d'interruption) connus sont les gestionnaires st, sd, isp, esp, fas, sbus, pci, pei-pci, qfe, hme (SunFastEthernetTM), nf (NPI-FDDI), qe (Quad Ethernet), le (Lance Ethernet), les gestionnaires SSA (soc, pln et ssd) et les gestionnaires Sun StorEdgeTM 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.

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 rebranchez 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.

Attention : Attention :

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 7 5/99, les unités de bande originellement prises en charge par Sun MicrosystemsTM sont sûres en cas d'interruption et de détachement (reportez-vous à st(7D) pour consulter 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étachez la carte en toute sécurité sans couper le périphérique. Si vous voulez utilisez 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 StorEdgeTM 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

Les gestionnaires ne supportent pas tous 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. Le gestionnaire DR vérifie que les points d'entrée sont pris en charge dans les gestionnaires E/S en contrôlant l'existence du bit D_HOTPLUG dans le champ des repères de cb_ops des gestionnaires d'E/S.

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 :

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.

Remarque :

De nombreux gestionnaires de tierce partie (achetés à d'autres fournisseurs plutôt qu'à Sun Microsystems) ne prennent pas en charge l'interface standard Solaris modunload(1M). Les conditions sollicitant les gestionnaires se présentent rarement lors du fonctionnement normal et les fonctionnalités nécessaires 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 de tout le 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 suspend-safe (sûrs en cas d'interruption); les gestionnaires qui ne les prennent pas en charge sont qualifiés de suspend-unsafe (pas sûrs en cas d'interruption).

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)).

Remarque :

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 manuellement mettre 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.

Attention : Attention :

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.