Ce chapitre contient des notes de mise à jour qui concernent les fonctionnalités suivantes du serveur Sun Enterprise 10000 : SSP 3.5, DR (Dynamic Reconfiguration) et IDN (InterDomain Network), ainsi que l'environnement d'exploitation Solaris sur les domaines Sun Enterprise 10000.
Pour obtenir un aperçu des fonctionnalités mises à jour dans SSP 3.5, y compris les problèmes en suspens et résolus, consultez les Notes de mise à jour et le SSP 3.5 Installation Guide.
Consultez régulièrement le site Web de SunSolve pour être informé des patchs SSP disponibles pour le SSP 3.5:
http://sunsolve.Sun.com
Si vous devez installer des patchs logiciels SSP, veillez à installer les patchs à la fois sur le SSP principal et le SSP de réserve, comme indiqué dans les Notes de mise à jour et le SSP 3.5 Installation Guide.
Pour la version Solaris 8 2/02, veillez à ce que le patch SSP 112178-01 ait bien été utilisé pour le logiciel SSP 3.5. Ce patch corrige le bug 4505031, qui consiste en l'affichage répété d'une invite à configurer le système en tant que SSP pour le serveur Sun Enterprise 10000. Cette invite apparaît après l'installation de l'environnement d'exploitation Solaris. Le patch n'affecte pas la fonctionnalité de base du logiciel SSP 3.5.
Des problèmes de mémoire liés au démon machine_server peuvent se produire après des opérations hpost multiples.
Procédure : si les performances SSP sont affectées par ces problèmes de mémoire, arrêtez et relancez les démons SSP. En tant que super-utilisateur sur le SSP principal, entrez ce qui suit :
ssp# /etc/init.d/ssp stop ssp# /etc/init.d/ssp start |
Lorsque ce problème survient, la commande showdevices affiche une adresse de mémoire de base incorrecte. Voir aussi le Bug ID 4497243.
Procédure : utilisez la commande rcfgadm avec les options -av pour afficher l'adresse de mémoire de base.
Les notes de mise à jour et les autres informations techniques de cette section ne concernent que la version Solaris 8 2/02 de la fonctionnalité de reconfiguration dynamique (DR, Dynamic Reconfiguration) sur le serveur Sun Enterprise 10000.
Cette section examine des problèmes d'ordre général concernant la fonctionnalité DR sur le serveur Enterprise 10000, veuillez la lire avant d'essayer d'installer ou de configurer DR.
Dans l'environnement d'exploitation Solaris 8 2/02, DR ne sépare plus automatiquement les processus utilisateurs liés aux UC qui vont être détachées. Les utilisateurs sont à présent priés d'effectuer cette opération eux-mêmes avant de lancer une opération de détachement. L'opération de vidage échoue s'il y a des processus liés aux UC.
Une condition de panique peut survenir dans certaines circonstances, lorsque l'interface /dev/openprom accède à l'arborescence du périphérique PROM, après une déconnexion DR. Le pilote openprom met en cache les informations de nud, celles-ci pouvant ne plus être disponibles après une déconnexion DR. Par conséquent, une adresse de nud erronée peut être transmise à OpenBoot PROM.
Procédure : pour éviter cette situation, n'utilisez plus les applications, telles que prtconf, qui font appel à l'interface /dev/openprom pendant ou juste avant/après une opération de déconnexion DR. Notez que picld(1M) utilise le pilote /dev/openprom.
Après l'interruption du pilote qfe survenant au cours d'une mise au repos d'une opération DR de l'environnement d'exploitation Solaris, le pilote qfe peut se trouver en condition d'échec de reprise, ceci se traduisant par une perte de connectivité réseau. Si cette condition se produit, le domaine sera encore accessible par le biais de la console réseau à partir du SSP.
Procédure : réinitialisez le périphérique qfe en exécutant la séquence de commandes suivante à partir de la console réseau :
# ifconfig périphérique_qfe down # ifconfig périphérique_qfe up |
Où périphérique_qfe correspond au périphérique qfe concerné, p.ex. qfe0.
Si vous effectuez une mise à niveau ou une installation à partir de zéro de l'environnement d'exploitation Solaris sur un domaine avant de mettre à niveau le SSP vers SSP 3.5, le domaine ne sera pas correctement configuré pour DR 3.0.
Procédure : exécutez la commande suivante en tant que super-utilisateur sur le domaine, après la mise à niveau du SSP vers SSP 3.5. Cette procédure n'est pas nécessaire tant que DR 3.0 n'est pas activé sur le domai
# devfsadm -i ngdr |
Pour qu'un domaine puisse être intégré à un réseau IDN, toutes les cartes de ce domaine pourvues de mémoire active doivent être associées à au moins une UC active.
Cette section traite des problèmes d'ordre général, des bugs connus, des patchs et des notes qui concernent Solaris 8 2/02 sur le serveur Sun Enterprise 10000.
Alternate Pathing (AP), Dynamic Reconfiguration (DR) et InterDomain Networks sont pris en charge par Solaris 8 2/02.
Si vous envisagez d'utiliser DR model 3.0 sur un domaine Sun Enterprise 10000, vous devez installer SSP 3.5 sur votre System Service Processor avant de commencer la procédure d'installation à partir de zéro ou la mise à niveau de l'environnement d'exploitation Solaris 8 2/02 sur ce domaine. La version SSP 3.5 prend en charge l'environnement d'exploitation Solaris 8 2/02 sur les domaines Sun Enterprise 10000.
N'utilisez pas le CD d'installation Solaris 8 2/02 pour installer ou mettre à niveau l'environnement d'exploitation Solaris sur les domaines Sun Enterprise 10000. Commencez l'installation à partir du CD 1 sur 2 du logiciel Solaris 8 2/02, comme expliqué dans les Notes de mise à jour et le SSP 3.5 Installation Guide.
Si vous mettez à niveau l'environnement d'exploitation de Solaris 2.6 vers Solaris 8 2/02 et avez agencé les partitions comme suggéré dans le manuel intitulé Solaris 2.6 Guide de la plate-forme matérielle SMCC, les partitions risquent de ne pas être assez grandes pour que la mise à niveau réussisse. Par exemple, la partition /usr doit mesurer au moins 653 méga-octets. Si elle est plus petite que la taille nécessaire pour la mise à niveau, suninstall utilise le mode Dynamic Space Reallocation (DSR) pour redistribuer l'espace des partitions du disque.
Le DSR peut prévoir un agencement des partitions inacceptable sur certains systèmes. Par exemple, le DSR peut sélectionner des partitions qui lui semblent inutilisées (partitions non UFS qui peuvent contenir des données brutes ou d'autres types de systèmes de fichiers). Si le DSR sélectionne une partition déjà utilisée, cela pourrait causer la perte de données. Par conséquent, vous devez savoir l'état courant des partitions que le mode DSR veut utiliser avant de lui permettre de continuer à redistribuer les partitions de disque.
Lorsque le mode DSR présente un agencement acceptable des partitions et que vous avez choisi de poursuivre le processus de redistribution, le DSR ajuste les systèmes de fichiers concernés et la mise à niveau peut continuer. Toutefois, si vous ne pouvez pas modifier l'agencement de la mémoire en fonction de vos besoins, il vous faudra configurer manuellement le périphérique d'initialisation ou, peut-être, effectuer une nouvelle installation.
Avant d'exécuter la commande boot net à partir de l'invite OpenBoot PROM (ok), vérifiez si la variable local-mac-address? est sur false, valeur par défaut définie en usine. Si elle est sur true, assurez-vous que cette valeur est appropriée pour la configuration locale.
Si local-mac-address? est sur true, le domaine risque de ne pas réussir à s'initialiser sur le réseau.
Dans une fenêtre netcon(1M), vous pouvez utiliser la commande suivante à l'invite OpenBoot PROM pour afficher les valeurs des variables OpenBoot PROM :
ok printenv |