Guide d'administration du système Solaris Resource Manager 1.3

Reprise après une panne

La défaillance d'un système Solaris est source de nombreuses préoccupations pour l'administrateur, et d'autres facteurs doivent être considérés lorsqu'un système Solaris Resource Manager est utilisé, à savoir :

Les sections ci-après traitent de ces sujets en détail et fournissent des suggestions pour corriger la situation.

Base de données des limites endommagée

Les fonctions de maintenance de la base de données des limites de Solaris Resource Manager sont très robustes et les dommages sont peu probables. Cependant, si cela se produit, il s'agit d'un problème important, car cette base de données est essentielle au fonctionnement de Solaris Resource Manager. Tout dommage potentiel doit faire l'objet d'une recherche minutieuse et être réparé s'il est confirmé.

Symptômes

Aucun symptôme ne permet de déterminer avec certitude si la base de données des limites a été endommagée, mais certains indices peuvent indiquer une telle situation :

Lorsque l'administrateur soupçonne que la base de données des limites a été endommagée, la façon la plus sûre de le savoir consiste à exécuter limreport et de demander la liste des noeuds limites ayant des attributs dont les valeurs ne se situent pas dans une plage de valeurs connue. Si des valeurs figurant à l'extérieur de cette plage sont signalées, une altération a eu lieu. limreport peut également servir à dresser la listes des noeuds limites dont l'attribut flag.real est désactivé, ce qui indique la présence, dans la table des mots de passe, de comptes n'ayant pas de noeud limite.

Correction

Si des dommages sont détectés, l'administrateur doit restaurer une version valide de la base de données des limites. Si les dommages sont limités à une partie restreinte de la base de données, l'administrateur peut parvenir à enregistrer le contenu de tous les autres noeuds limites, puis les restaurer dans une nouvelle base de données des limites à l'aide des commandes limreport et limadm. Si une copie récente de la base de données n'est pas disponible, cela est préférable, puisque la nouvelle base de données des limites contiendrait les attributs d'utilisation et attributs cumulatifs les plus récents. Pour connaître la procédure de sauvegarde et de restauration de la base de données des limites, consultez la rubrique Chapitre 5. Pour les cas simples de noeuds limites manquants, il peut être suffisant de simplement les recréer à l'aide la commande limadm.

Perte de temps de connexion par limdaemon

Si limdaemon est interrompu, peu importe la raison, tous les utilisateurs en session ne sont plus facturés pour leur temps de connexion. En outre, lorsque limdaemon est redémarré, les utilisateurs en session continuent à utiliser leur terminal gratuitement. Cela s'explique par le fait que le démon utilise les avis d'ouverture de session fournis par login pour établir un relevé de session Solaris Resource Manager depuis les structures internes utilisées pour calculer les frais de temps de connexion. Par conséquent, chaque fois que le démon démarre, aucune session Solaris Resource Manager n'est établie avant la réception du premier avis.

Cela n'est habituellement pas un problème si l'interruption de limdaemon est causée par une panne du système, celle-ci entraînant également l'arrêt des autres processus. Aucune session ne peut donc reprendre avant le redémarrage du système.

Si limdaemon est arrêté pour une autre raison, deux possibilités s'offrent à l'administrateur :

  1. Redémarrer le démon immédiatement et ne pas tenir compte des pertes de facturation du temps de connexion au terminal des utilisateurs déjà connectés, auquel cas un utilisateur pourrait utiliser gratuitement un terminal jusqu'à ce qu'il soit détecté et que sa session soit fermée.

  2. Mettre le système en mode mono-utilisateur, puis de nouveau en mode multi-utilisateur, ce qui met fin à toutes les sessions en cours et empêche les utilisateurs de rouvrir une session avant le redémarrage du démon.