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 :

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

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.

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, pei-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.

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.

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 Microsystems^TM 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 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.