C H A P I T R E  2

Concepts DR

Ce chapitre décrit les concepts DR que vous devez assimiler avant d'utiliser le logiciel DR.

Si vous envisagez d'exécuter des opérations DR sur le contrôleur système (SC) d'un serveur haut de gamme à l'aide de commandes DR SMS, il est impératif que vous lisiez le Chapitre 5 et la section Procédures DR SMS - à partir du SC (systèmes haut de gamme uniquement). Certaines informations du présent chapitre sont expliquées également au Chapitre 5, d'un autre point de vue. La lecture des deux chapitres peut mener à une compréhension plus globale de la fonction DR.

Ce chapitre comprend les sections suivantes :



Remarque - La carte UltraSPARC IV+ contient des CPU à double noyau. Les CPU et processus mentionnés dans ce document peuvent être à noyau unique ou à double noyau. Toutes les procédures décrites s'appliquent donc à ces deux types.




Domaines système dynamiques

Le système Sun Fire peut être divisé en domaines. Chaque domaine repose sur les emplacements de cartes système qui lui sont assignés. En outre, chaque domaine est isolé électriquement en partitions matérielles, empêchant ainsi qu'une panne sur un domaine du serveur n'affecte les autres domaines.

Toutes les configurations de domaine sont déterminées dans une base de données de configuration résidant sur le SC. Cette base de données de configuration sur les systèmes haut de gamme, appelée base de données de configuration de la plate-forme (PCD, platform configuration database), contrôle le mode de partitionnement logique des emplacements de cartes système en domaines. La configuration du domaine constitue la configuration prévue. Elle comprend donc les emplacements vides et les emplacements occupés. Le domaine physique est déterminé par le domaine logique.

Le nombre d'emplacements disponibles pour un domaine donné est contrôlé par une ACL. Une ACL est une liste des composants disponibles sur les domaines de systèmes haut de gamme ou une liste de contrôle d'accès sur les domaines de systèmes milieu de gamme. Pour tous les domaines, l'ACL est conservée sur le SC. Avant de pouvoir être modifié, l'emplacement doit être disponible ou assigné à un domaine. Dès lors qu'il est assigné à un domaine, l'emplacement devient visible pour ce domaine, et invisible et indisponible pour les autres. A l'inverse, vous devez déconnecter un emplacement et annuler son assignation à un domaine avant de pouvoir l'assigner et le connecter à un autre domaine.

Le domaine logique désigne l'ensemble des emplacements assignés au domaine. Le domaine physique correspond à l'ensemble des cartes physiquement interconnectées. Un emplacement peut être membre d'un domaine logique sans appartenir à un domaine physique pour autant. Une fois le domaine démarré, vous pouvez assigner ou annuler l'assignation des cartes système et des emplacements vides à un domaine logique. Toutefois, ceux-ci ne peuvent pas faire partie du domaine physique tant que le système d'exploitation ne le demande pas. Les emplacements ou les cartes système non assignés à un domaine sont disponibles pour les autres domaines. L'administrateur de la plate-forme a la possibilité d'assigner ces cartes à un domaine. Néanmoins, il est possible de configurer une ACL sur le SC pour permettre aux utilisateurs disposant des privilèges appropriés d'assigner les cartes disponibles à un domaine.


Points d'attache

Le terme collectif point d'attache désigne une carte ou un périphérique, son emplacement et tous ses composants. Les emplacements sont parfois appelés réceptacles.

Les systèmes Sun Fire prennent en charge les points d'attache suivants :



Remarque - Pour de nombreux utilisateurs, seule la modification de l'état des cartes et des périphériques présente un intérêt. Par conséquent et pour plus de simplicité, certaines procédures de ce document font référence aux points d'attache de carte comme cartes, aux points d'attache PCI comme cartes PCI et aux points d'attache de composant comme modules CPU ou mémoire. Les véritables dénominations ne sont utilisées que lorsqu'une confusion est possible.



Le terme occupant désigne l'ensemble formé par une carte et les périphériques qui lui sont attachés, y compris tous les périphériques de stockage externes connectés par des câbles d'interface.

Les emplacements de carte peuvent être nommés d'après les numéros d'emplacement ou demeurer anonymes (dans une chaîne SCSI, par exemple).

DR reconnaît deux types de noms de point d'attache :

Pour obtenir la liste de tous les points d'attache logiques disponibles, utilisez la commande suivante sur le domaine :


# cfgadm -l

 

Classes de points d'attache

Les systèmes Sun Fire prennent en charge les classes de points d'attache suivantes : Les deux classes que les utilisateurs DR doivent connaître sont sbd et pci.

Pour afficher la liste des points d'attache et les types de cartes auxquels ils sont associés, ouvrez une session en tant que superutilisateur et entrez la commande suivante :


# cfgadm -s -a "cols=ap_id:class"

 

Points d'attache de systèmes haut de gamme

Exemples de noms de points d'attache physiques sur des systèmes haut de gamme :


/devices/pseudo/dr@0:SBx (pour une carte système à l'emplacement 0)

/devices/pseudo/dr@0:IOx (pour une carte d'E/S à l'emplacement 1)


 

0 désigne le noeud 0 (zéro), SB une carte système, IO une carte d'E/S et x le numéro de carte ou le numéro d'extension d'une carte spécifique. Les cartes système et d'E/S sont numérotées de 0 à 17.



Remarque - Les cartes système sont installées uniquement à l'emplacement 0, tandis que les cartes d'E/S et Max CPU sont insérées uniquement à l'emplacement 1.



Les points d'attache logiques des systèmes haut de gamme prennent l'une des deux formes suivantes :


SBx (cartes système)

IOx (cartes d'E/S ou MaxCPU)


 

Points d'attaches de systèmes milieu de gamme

Exemples de noms de points d'attache physiques sur des systèmes milieu de gamme :


/devices/ssm@0,0:N0.SBx (cartes système)

/devices/ssm@0,0:N0.IBx (cartes d'E/S)


 

N0 désigne le noeud 0 (zéro), SB une carte système, IB une carte d'E/S et x le numéro d'emplacement (de 0 à 5 pour une carte système et de 6 à 9 pour une carte d'E/S).

Les points d'attache logiques des systèmes milieu de gamme prennent l'une des deux formes suivantes :


N0.SBx (cartes système)

N0.IBx (cartes d'E/S)


 

Modifications de points d'attache

Vous pouvez utiliser la commande cfgadm(1M) pour modifier les points d'attache. Vous avez la possibilité d'effectuer les opérations suivantes :

Pour de plus amples informations sur les états, reportez-vous aux sections ci-après. Pour de plus amples informations sur les points d'attache, reportez-vous à la page man cfgadm(1M).


États et conditions

Cette section décrit les états et les conditions des cartes, emplacements, composants et points d'attache.

La commande cfgadm(1M) peut afficher neuf types d'états et de conditions. Pour de plus amples informations, reportez-vous aux sections États des composants et Conditions des composants.



Remarque - Les informations suivantes sur les cartes et les emplacements de cartes s'appliquent également aux cartes PCI et aux bus PCI qui les contiennent.



États des cartes et des emplacements de carte

Lorsqu'un emplacement ne contient pas de carte, son état est défini sur empty. S'il contient une carte, l'état de celle-ci est défini sur disconnected ou connected.


TABLEAU 2-1 États des cartes et des emplacements de carte

État

Description

empty

L'emplacement ne contient pas de carte.

disconnected

La carte dans l'emplacement est déconnectée du bus système. Une carte peut être déconnectée sans être mise hors tension. Cependant, une carte doit obligatoirement être déconnectée et mise hors tension pour que vous puissiez la retirer de son emplacement. L'état d'une carte nouvellement insérée est défini sur disconnected.

connected

La carte dans l'emplacement est sous tension et connectée au bus système. Vous ne pouvez visualiser les composants d'une carte que si celle-ci est connectée.


 

caution icon

Attention - Le retrait physique d'une carte à l'état connected ou d'une carte sous tension et à l'état disconnected bloque le système d'exploitation et peut causer des dommages irréversibles à la carte système.



 

Une carte à l'état connected est également à l'état configured ou unconfigured. Une carte déconnectée est toujours déconfigurée.


TABLEAU 2-2 Cartes configurées et déconfigurées

Nom

Description

configured

La carte est disponible et peut être utilisée par le logiciel Solaris.

unconfigured

La carte n'est pas disponible et ne peut pas être utilisée par le logiciel Solaris.


 

Les états suivants sont visibles uniquement à partir du SC :


TABLEAU 2-3 États de carte visibles uniquement à partir du SC

Nom

Description

Available

L'emplacement, qui contient ou non une carte, n'est assigné à aucun domaine en particulier.

Assigned

L'emplacement, qui contient ou non une carte, appartient à un domaine, mais le matériel n'a pas été configuré pour son utilisation.

Active

La carte dans l'emplacement est utilisée de façon active par le domaine auquel elle est assignée. Vous ne pouvez pas réassigner une carte active.


 

Conditions des cartes

Une carte peut être définie sur l'une des trois conditions suivantes : unknown (inconnue), ok (correcte), failed (défectueuse). Son emplacement peut être désigné comme unusable (non utilisable).


TABLEAU 2-4 Conditions des cartes et des emplacements de carte

Nom

Description

unknown

La carte n'a pas été testée.

ok

La carte est opérationnelle.

failed

Le test de la carte a échoué.

unusable

L'emplacement de la carte est inutilisable.


 

États des composants

Contraitement aux cartes, les modules CPU ou mémoire ne peuvent pas être connectés ou déconnectés séparément. Tous ces composants sont donc définis sur connected.

Les composants connectés sont soit configurés (configured), soit déconfigurés (unconfigured).


TABLEAU 2-5 Composants à l'état connected : configured ou unconfigured

Nom

Description

configured

Le composant est disponible et peût être utilisé par le SE Solaris.

unconfigured

Le composant n'est pas disponible et ne peut pas être utilisé par le SE Solaris.


 

Conditions des composants

L'état d'un module CPU ou mémoire peut être défini sur unknown, ok ou failed (inconnu, ok ou défectueux).


TABLEAU 2-6 Conditions de modules CPU ou mémoire

Nom

Description

unknown

Le composant n'a pas été testé.

ok

Le composant est opérationnel.

failed

Le test du composant a échoué.


 


Amovibilité

Un périphérique détachable respecte les règles suivantes :

Certaines cartes ne se détachent pas, car leurs ressources ne peuvent pas être déplacées. Par exemple, si un domaine est équipé d'une seule carte CPU, cette dernière ne se détache pas. Une carte d'E/S n'est pas amovible lorsqu'elle contrôle le disque d'initialisation.

Quand une carte d'E/S n'est disponible que par le biais d'un seul chemin, vous pouvez effectuer les opérations suivantes :



Remarque - Lorsque vous ne savez pas si un périphérique est détachable, consultez le représentant de service Sun.




Mémoire permanente et non permanente

Pour pouvoir supprimer une carte, le système d'exploitation doit en libérer la mémoire. Libérer une carte implique le vidage du contenu de sa mémoire non permanente dans la zone de swap et la copie du contenu de sa mémoire permanente (noyau et logiciel OpenBoottrademark PROM) sur une autre carte mémoire.

Pour déplacer une mémoire permanente, le système d'exploitation d'un domaine doit se trouver temporairement en mode quiescence. La durée de la période de quiescence dépend de la configuration des E/S du domaine et des charges de travail induite par les opérations en cours.

Le détachement d'une carte à mémoire permanente est la seule opération pendant laquelle le système d'exploitation est en mode quiescence. Par conséquent, vous devez savoir où réside la mémoire permanente de façon à ne pas trop perturber le fonctionnement du domaine. Pour afficher la taille de la mémoire permanente, utilisez la commande cfgadm(1M) avec son option -av. Pour libérer une carte équipée de mémoire permanente, le système d'exploitation doit trouver un bloc de mémoire disponible d'une taille suffisante, appelé mémoire cible, sur lequel il copie le contenu de la mémoire permanente, désignée comme la mémoire source.

Copier-renommer

Les processus utilisateur peuvent libérer de la mémoire en renvoyant la page hors du périphérique de swap. Toutefois, le noyau Solaris, qui réside dans la mémoire permanente, ne peut pas être libéré selon cette méthode. La commande cfgadm fait plutôt appel à la technique intitulée copier-renommer. Dès que le SE a identifié une carte cible adéquate, disposant d'une mémoire suffisante pour contenir la mémoire permanente déplacée, le logiciel DR exécute les étapes suivantes :

1. Vidage de la mémoire sur la carte cible en renvoyant la page hors du périphérique de swap.

2. Quiescence du système d'exploitation.

3. Copie du contenu (mémoire permanente) de la carte source vers la carte cible. Il s'agit de la partie copier de l'opération.

4. Reprogrammation du matériel pour remplacer les plages d'adresses de mémoire des cartes source et cible. Il s'agit de la partie renommer de l'opération.

5. Fin de la quiescence du système d'exploitation.

Entrelacement de la mémoire

Les cartes système ne peuvent pas être reconfigurées de manière dynamique si la mémoire système est entrelacée sur plusieurs cartes système. Il est possible de reconfigurer les cartes PCI et d'E/S de manière dynamique, que la mémoire soit entrelacée ou non.

Pour de plus amples informations sur l'entrelacement de la mémoire de systèmes haut de gamme, reportez-vous manuel Sun Fire High-End Systems Administration Manual. En ce qui concerne les systèmes milieu de gamme, reportez-vous au paramètre interleave-scope de la commande setupdomain, décrit dans les manuels Guide d'administration de plate-forme pour systèmes de milieu de gamme Sun Fire et Sun Fire Midrange System Controller Command Reference Manual.

Erreurs de mémoire corrigibles

Les erreurs de mémoire corrigibles indiquent que la mémoire d'une carte système, soit un ou plusieurs DIMM (modules de mémoire à double rangée de connexions) ou une partie des interconnexions matérielles, est défectueuse et doit être remplacée. Lorsqu'il détecte des erreurs de mémoire corrigibles, le SC initialise un vidage de type enregistrer-arrêter pour enregistrer les données de diagnostic qui peuvent interférer avec une opération DR.

En cas de vidage de type enregistrer-arrêter suite à une erreur de mémoire corrigible, initialisez l'opération DR après que le vidage est terminé.

Si les composants défectueux créent sans cesse des rapports d'erreurs de mémoire corrigibles, le SC effectue plusieurs vidages de type enregistrer-arrêter. Dans ce cas, désactivez temporairement le mécanisme de détection de vidage du SC, laissez le vidage se terminer, puis initialisez l'opération DR. Une fois cette dernière terminée, activez de nouveau la détection de vidage.


Quiescence

Pendant une opération de déconfiguration sur une carte système équipée d'une mémoire permanente (OpenBoottrademark PROM ou mémoire noyau), le système d'exploitation est brièvement interrompu. C'est ce que l'on appelle la quiescence. Toutes les activités du système d'exploitation et des périphériques du domaine doivent cesser pendant cette phase critique de l'opération.

Pour savoir rapidement si votre carte dispose d'une mémoire permanente, exécutez la commande suivante :


# cfgadm -av | grep permanent

 

Le système répond par un message similaire à l'exemple suivant, qui décrit la carte système 0 (zéro) sur un système milieu de gamme :


N0.SB0::memory connected configured ok base address 0x0, 4194304
 KBytes total, 668072 KBytes permanent

 

Si le système d'exploitation ne peut pas se mettre en mode quiescence, les raisons de cet échec sont affichées, par exemple :



Remarque - Les processus en temps réel n'empêchent pas la quiescence.



Les conditions empêchant l'interruption des processus sont généralement temporaires. Analysez les raisons de l'échec et recommencez l'opération si le système d'exploitation a échoué pour interrompre un processus.

Pendant la phase de quiescence, le système est gelé et ne répond pas aux événements externes tels que les paquets réseau. La durée de quiescence dépend de deux facteurs : le nombre de threads et de périphériques d'E/S à arrêter, et le volume de mémoire à copier. En général, c'est le premier de ces facteurs qui détermine le temps de quiescence requis, car les périphériques d'E/S doivent être interrompus puis relancés. Un état de quiescence dure habituellement plus de deux minutes.

Étant donné que la quiescence a un impact visible, la commande cfgadm demande votre confirmation avant de cette dernière mettre en oeuvre. Si vous saisissez :


# cfgadm -c unconfigure N0.SB0

 

Le système répond par une demande de confirmation :


System may be temporarily suspended, proceed (yes/no)?

 

Si vous utilisez Sun Management Center pour effectuer l'opération DR, une fenêtre contextuelle affiche le message suivant :


Saisissez Yes (Oui) pour confirmer que l'impact de la phase quiescente est acceptable, et poursuivre.

 


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

Lorsque le logiciel DR interrompt le système d'exploitation, les pilotes de périphériques rattachés au système d'exploitation doivent également être interrompus. S'il s'avère impossible d'interrompre un pilote (ou de le rétablir par la suite), l'opération DR échoue.

Un périphérique sûr en cas d'interruption n'a pas accès à la mémoire ou ne peut pas interrompre le système lorsque le système d'exploitation est en mode quiescence. Un pilote est considéré comme sûr en cas d'interruption s'il prend en charge la quiescence du système d'exploitation (interruption/reprise). Un pilote sûr en cas d'interruption garantit également que, lors de l'exécution d'une demande d'interruption, le périphérique qu'il contrôle ne tente pas d'accéder à la mémoire, même s'il est ouvert au moment de la requête.

Un périphérique non sûr en cas d'interruption autorise l'accès à la mémoire ou l'interruption du système pendant que le système d'exploitation est en mode quiescence.

Sur les systèmes haut de gamme, DR utilise la liste des pilotes non sûrs du fichier dr.conf pour empêcher les périphériques non sûrs d'accéder à la mémoire ou d'interrompre le système d'exploitation pendant une opération DR. Le fichier dr.conf se trouve dans le répertoire suivant : /platform/SUNW,Sun-Fire-numéro_modèle/kernel/drv/, où numéro_modèle désigne le nom de la machine, par exemple 15000. La liste des pilotes non sûrs est une propriété du fichier dr.conf au format suivant :


unsupported-io-drivers="pilote1","pilote2","pilote3";

 

DR lit cette liste quand il s'apprête à interrompre le système d'exploitation, afin de déconfigurer un composant de la mémoire. Si DR rencontre un pilote actif dans la liste des pilotes non sûrs, il interrompt l'opération DR et envoie un message d'erreur. Ce message inclut l'ID du pilote actif non sûr. Vous devez supprimer manuellement l'activation du périphérique en effectuant une ou plusieurs des tâches suivantes :

Vous pouvez recommencer l'opération DR après avoir interrompu l'utilisation du périphérique.



Remarque - Lorsque vous ne savez si un périphérique est sûr en cas d'interruption, consultez le représentant de service Sun.




DR sur les cartes d'E/S

Vous devez être extrêmement attentif lorsque vous ajoutez ou retirez des cartes dotées de périphériques d'E/S. Avant de retirer une carte de ce type, assurez-vous que l'ensemble des périphériques de la carte sont fermés et que tous les systèmes de fichiers sont démontés.

Si vous avez besoin de retirer temporairement une carte dotée de périphériques d'E/S d'un domaine et de la rajouter avant d'insérer une autre carte de ce type, la reconfiguration n'est pas nécessaire. Dans ce cas, en effet, les chemins d'accès aux périphériques de la carte restent inchangés. En revanche, si vous ajoutez une autre carte dotée de périphériques d'E/S après le retrait de la première, puis ajoutez de nouveau la première carte, la reconfiguration est obligatoire car les chemins d'accès aux périphériques de la première carte sont modifiés.



Remarque - Avant de vous lancer dans une opération DR sur une carte d'E/S d'un domaine, assurez-vous qu'il existe au moins deux CPU disponibles pour le domaine. En outre, veillez à ce qu'au moins une de ces CPU se trouve sur une carte système et qu'aucun processus ne lui soit lié. Pour de plus amples informations sur les processus de liaison, reportez-vous à la page man pbind(1M).



Cartes d'E/S, Golden IOSRAM, MaxCPU et hsPCI+ pour systèmes haut de gamme

Chaque carte d'E/S sur un domaine de système haut de gamme contient un périphérique IOSRAM. Toutefois, un seul périphérique IOSRAM, intitulé golden IOSRAM, est utilisé pour les connexions entre le SC et le domaine. Le périphérique golden IOSRAM contient le canal de communication entre le SC et le domaine. Étant donné que DR peut retirer des cartes d'E/S, il est parfois nécessaire d'interrompre l'utilisation du périphérique golden IOSRAM actuel et d'utiliser un autre périphérique IOSRAM comme golden IOSRAM. Ce processus s'intitule « changement de canal » et survient chaque fois que DR déconfigure le golden IOSRAM actuel. Au démarrage d'un domaine, la carte d'E/S dotée du numéro le plus faible sur le domaine est en général sélectionnée pour devenir le golden IOSRAM initial.

DR prend en charge les bus d'E/S sur la carte d'E/S d'un système haut de gamme et toutes les cartes PCI ou MaxCPU insérées dans ces bus. DR reconnaît également la reconfiguration dynamique des cartes hsPCI+. Chaque carte hsPCI+ inclut deux ASIC XMITS et quatre emplacements hsPCI+ enfichables à chaud.

Blocs d'E/S, PCI et CompactPCI pour systèmes milieu de gamme

Sur les systèmes milieu de gamme Sun Fire, DR ne prend en charge ni SAI/P (ID de bogue 4466378) ni HIPPI/P. Les versions antérieures ne prenaient pas en charge le pilote SunHSI/P, mais le bogue à l'origine de la non prise en charge (n° 449636) a été résolu dans les patchs 106922 (2.0) et 109715 (3.0). Pour de plus amples informations, reportez-vous à SunSolve et à la page man devfsadm(1M).



Remarque - Vous ne pouvez pas faire appel aux opérations de connexion et configuration de reconfiguration dynamique (DR) en vue d'ajouter une carte d'E/S à un domaine au sein d'un système de milieu de gamme à partition unique configuré avec une ou plusieurs cartes système UltraSPARC IV+. Cette restriction s'explique par l'absence d'un second domaine dan lequel la carte d'E/S pourrait être testée. Vous pouvez néanmoins utiliser la déconfiguration DR et déconnecter les commandes sur une carte d'E/S dans le système décrit. Pour plus d'informations, reportez-vous à la section Test d'une carte, ainsi qu'au Guide d'administration de plate-forme pour systèmes de milieu de gamme Sun Fire pour le microprogramme version 5.19.0.



Remarques concernant CompactPCI

Les limitations suivantes s'appliquent à la reconfiguration impliquant des blocs CompactPCI :

La déconfiguration d'une carte CompactPCI entraîne sa déconnexion automatique. Si l'autoconfiguration est activée, la carte CompactPCI est configurée au moment de sa connexion. Si tel n'est pas le cas, vous devez procéder à la configuration manuelle de la carte.


Opérations DR courantes de carte

Opération de connexion

Pendant la connexion d'une carte, DR essaie d'assigner un emplacement au domaine si la carte système de cet emplacement est disponible et ne fait partie d'aucun domaine logique. Une fois l'emplacement assigné, DR envoie une requête pour que le SC soit mis sous tension et que la carte soit testée. Après le test de la carte, DR demande au SC de connecter électroniquement la carte au système. Cette dernière fait alors partie du domaine physique. Le système d'exploitation vérifie ensuite les composants de la carte.



Remarque - Si la commande cfgadm(1M) échoue pendant une opération DR, la carte ne revient pas à son état d'origine. Si l'erreur est récupérable, exécutez de nouveau la commande. Dans le cas contraire, vous devez redémarrer le domaine pour utiliser la carte.



Les états et conditions d'un point d'attache avant l'insertion d'une carte sont les suivants :

Une fois la carte insérée, les états et conditions sont les suivants :

Une fois le point d'attache connecté de manière logique, les états et conditions sont les suivants :

Opération de configuration

Pendant l'opération de configuration, DR essaie de connecter l'emplacement de la carte si celui-ci est déconnecté. Il parcourt ensuite l'arborescence des périphériques créée pendant l'opération de connexion. (DR crée des noeuds d'arborescence des périphériques de SE Solaris et attache des pilotes de périphériques, si nécessaire).

Les CPU sont ajoutés à la liste des CPU. La mémoire est initialisée et ajoutée au pool de mémoire système. Une fois la configuration terminée, les CPU et la mémoire peuvent être utilisés.

Avant d'utiliser les périphériques d'E/S, faites appel aux commandes mount(1M) et ifconfig(1M).

Lorsque vous utilisez la commande cfgadm pour configurer une carte sur un domaine, celle-ci est automatiquement connectée et configurée.

Opération de déconnexion

Pendant une opération de déconnexion, le cadre DR communique avec le SC pour programmer l'interconnexion afin que la carte système puisse être retirée du domaine physique. Il essaie ensuite d'effectuer les tâches de déconfiguration.

Une carte peut être déconnectée sans être hors tension. Cependant, une carte doit obligatoirement être déconnectée et mise hors tension pour que vous puissiez la retirer de son emplacement.

Avant la déconnexion d'une carte, les états et conditions sont les suivants :

Après la déconnexion d'une carte, les états et conditions sont les suivants :

Opération de déconfiguration

La déconfiguration se compose d'une opération unique ou de deux opérations distinctes, selon que la carte comporte ou non une mémoire permanente. Si la carte système contient une mémoire permanente, DR déplace le contenu de cette mémoire de la carte spécifiée vers une mémoire disponible sur une carte cible du domaine et ce, avant l'opération de déconfiguration. Pour de plus amples informations sur les cartes comportant une mémoire permanente, reportez-vous à la section Mémoire permanente et non permanente.


Illustration des concepts DR

DR vous permet de déconnecter, puis de reconnecter des cartes système sans devoir arrêter le système. Vous pouvez utiliser cette fonctionnalité pour ajouter ou supprimer des ressources système pendant que le système continue à fonctionner.

L'exemple suivant utilise un système haut de gamme Sun Fire, mais le principe général s'applique également aux systèmes milieu de gamme.



Remarque - Les systèmes Sun Fire E25K et Sun Fire 15K prennent en charge jusqu'à 18 cartes système et 18 cartes d'E/S, numérotées de 0 à 17.



Le domaine A contient les cartes système 0 et 2 et la carte d'E/S 2, tandis que le domaine B inclut les cartes système 1 et 3 et les cartes d'E/S 1, 3 et 4.


FIGURE 2-1 Domaines A et B avant reconfiguration


Pour assigner la carte système 4 et la carte d'E/S 0 au domaine A, et pour déplacer la carte d'E/S 4 du domaine B au domaine A, utilisez l'IG du logiciel Sun Management Center. Ou faites appel à la commande cfgadm(1M) pour chaque domaine.

1. Utilisez la commande suivante pour déconnecter la carte d'E/S 4 du domaine B.


# cfgadm -c disconnect -o nopoweroff,unassign IO4

 

2. Utilisez la commande suivante pour assigner, connecter et configurer la carte système 4, ainsi que les cartes d'E/S 0 et 4, sur le domaine A.


# cfgadm -c configure SB4 IO0 IO4

 

La configuration système obtenue est la suivante. Seule la méthode de connexion des cartes a changé, leur disposition physique au sein du coffret est la même.


FIGURE 2-2 Domaines A et B après reconfiguration