Notes de version de Sun Cluster 3.2 pour SE Solaris

Mise à niveau

Le script vxlufinish renvoie une erreur lorsque le disque racine est encapsulé (6448341)

Problème : ce problème est observé si le disque d'origine est un disque racine encapsulé et qu'une mise à niveau en ligne est tentée de VxVM 3.5 sur SE Solaris 9 8/03 vers VxVM 5.0 sur SE Solaris 10 6/06. Le script vxlufinish échoue avec l'erreur suivante.


#./vslufinish -u 5.10

    VERITAS Volume Manager VxVM 5.0
    Live Upgrade finish on the Solairs release <5.10>

    Enter the name of the alternate root diskgroup: altrootdg
ld.so.1: vxparms: fatal: libvxscsi.so: open failed: No such file or directory
ld.so.1: vxparms: fatal: libvxscsi.so: open failed: No such file or directory
Killed
ld.so.1: ugettxt: fatal: libvxscsi.so: open failed: No such file or directory
ERROR:vxlufinish Failed: /altroot.5.10/usr/lib/vxvm/bin/vxencap -d -C 10176
-c -p 5555 -g
    -g altrootdg rootdisk=c0t1d0s2
    Please install, if 5.0 or higher version of VxVM is not installed
    on alternate bootdisk.

Solution : utilisez plutôt la mise à niveau standard ou la mise à niveau sur deux partitions.

Contactez le support technique Sun ou votre représentant Sun pour savoir si la prise en charge de Sun Cluster 3.2 Live Upgrade sera bientôt disponible pour VxVM 5.0.

Live Upgrade doit prendre en charge le montage de périphériques globaux à partir du disque d'initialisation (6433728)

Problème : pendant une mise à niveau directe, les commandes lucreate et luupgrade ne permettent pas de modifier les noms DID dans l'autre environnement d'initialisation correspondant à l'entrée /global/.devices/node@N.

Solution : effectuez les étapes suivantes sur chaque nœud de cluster avant de lancer la mise à niveau directe.

  1. Prenez le rôle de superutilisateur.

  2. Sauvegardez le fichier /etc/vfstab.


    # cp /etc/vfstab /etc/vfstab.old
    
  3. Ouvrez le fichier /etc/vfstab pour le modifier.

  4. Recherchez la ligne correspondant à /global/.device/node@N.

  5. Modifiez l'entrée de périphérique global.

    • Remplacez les noms DID par les noms physiques.

      Remplacez /dev/did/{r}dsk/dYsZ par /dev/{r}dsk/cNtXdYs Z.

    • Supprimez global de l'entrée.

    L'exemple suivant indique le nom d'un périphérique DID d3s3 correspondant à /global/.devices/node@s, remplacé par le nom de périphérique physique et dans lequel l'entrée global est supprimée :


    Original:
    /dev/did/dsk/d3s3    /dev/did/rdsk/d3s3    /global/.devices/node@2   ufs   2   no   global
    
    Changed:
    dev/dsk/c0t0d0s3     /dev/rdsk/c0t0d0s3    /global/.devices/node@2   ufs   2   no   -
  6. Une fois le fichier /etc/vfstab modifié sur tous les nœuds de cluster, procédez à une mise à niveau directe du cluster mais arrêtez-la avant de réinitialiser à partir de l'autre environnement d'initialisation mis à niveau.

  7. Sur chaque nœud, sur l'environnement d'initialisation en cours et non mis à niveau, restaurez le fichier /etc/vfstab d'origine.


    # cp /etc/vstab.old /etc/vfstab
    
  8. Sur l'autre environnement d'initialisation, ouvrez le fichier /etc/vfstab pour le modifier.

  9. Recherchez la ligne correspondant à /global/.devices/node@N et remplacez le tiret (-) à la fin de l'entrée par le mot global.


    /dev/dsk/cNtXdYsZ    /dev/rdsk/cNtXdYsZ    /global/.devices/node@N   ufs   2   no   global
    
  10. Réinitialisez le nœud à partir de l'autre environnement d'initialisation mis à niveau.

    Les noms DID sont remplacés automatiquement dans le fichier /etc/vfstab.

Le script vxlustart ne peut pas créer l'autre environnement de démarrage lors d'une mise à niveau en ligne (6445430)

Problème : ce problème est observé lors de la mise à niveau de VERITAS Volume Manager (VxVM) pendant une mise à niveau en ligne de Sun Cluster. Le script vxlustart permet de mettre à niveau SE Solaris et VxVM à partir de la version précédente. Le script échoue et renvoie les messages d'erreur semblables aux suivants :


# ./vxlustart -u 5.10 -d c0t1d0 -s OSimage

   VERITAS Volume Manager VxVM 5.0.
   Live Upgrade is now upgrading from 5.9 to <5.10>
…
ERROR: Unable to copy file systems from boot environment &lt;sorce.8876> to BE &lt;dest.8876>.
ERROR: Unable to populate file systems on boot environment &lt;dest.8876>.
ERROR: Cannot make file systems for boot environment &lt;dest.8876>.
ERROR: vxlustart: Failed: lucreate -c sorce.8876 -C /dev/dsk/c0t0d0s2 
-m -:/dev/dsk/c0t1d0s1:swap -m /:/dev/dsk/c0t1d0s0:ufs 
-m /globaldevices:/dev/dsk/c0t1d0s3:ufs -m /mc_metadb:/dev/dsk/c0t1d0s7:ufs 
-m /space:/dev/dsk/c0t1d0s4:ufs -n dest.8876

Solution : utilisez la mise à niveau standard ou la mise à niveau sur deux partitions si vous mettez à niveau le cluster vers VxVM 5.0.

Contactez le support technique Sun ou votre représentant Sun pour savoir si la prise en charge de Sun Cluster 3.2 Live Upgrade sera bientôt disponible pour VxVM 5.0.

Les numéros majeurs de vxio sont différents entre les nœuds lorsque le disque racine est encapsulé (6445917)

Problème : pour les clusters exécutant VERITAS Volume Manager (VxVM), une mise à niveau standard ou une mise à niveau sur deux partitions de l'un des logiciels suivants échoue si le disque racine est encapsulé :

De graves erreurs de nœuds se produisent et le nœud ne peut pas démarrer après la mise à niveau. Cela est dû aux changements des numéros majeurs ou mineurs apportés par VxVM lors de la mise à niveau.

Solution : désencapsulez le disque racine avant de commencer la mise à niveau.


Attention – Attention –

Si la procédure décrite ci-dessus n'est pas suivie correctement, vous pouvez connaître de sérieux problèmes inattendus sur tous les nœuds en cours de mise à niveau. La désencapsulation et l'encapsulation du disque racine entraînent également un redémarrage automatique supplémentaire (chaque fois) du nœud, augmentant le nombre des redémarrages requis lors de la mise à niveau.


Impossible d'utiliser des zones suite à une mise à niveau directe de Sun Cluster Version 3.1 sur Solaris 9 à la Version 3.2 sur Solaris 10 (6509958)

Problème : après une mise à niveau directe de Sun Cluster version 3.1 sur Solaris 9 à la version 3.2 sur Solaris 10, des zones ne peuvent pas être utilisées avec le logiciel du cluster. Le problème réside dans le fait que les données pspool ne sont pas créées pour les packages Sun Cluster. Les packages qui doivent être distribués aux zones non globales, comme SUNWsczu, ne sont pas distribués correctement.

Solution : après la mise à niveau des packages Sun Cluster à l'aide de la commande scinstall -R et avant l'initialisation du cluster en mode cluster, exécutez le script suivant deux fois :

ProcedureInstructions d'utilisation du script

Avant de commencer

Préparez et exécutez ce script de l'une des manières suivantes :

  1. Prenez le rôle de superutilisateur.

  2. Créez un script avec le contenu ci-dessous.

    #!/bin/ksh
    
    typeset PLATFORM=${PLATFORM:-`uname -p`}
    typeset PATHNAME=${PATHNAME:-/cdrom/cdrom0/Solaris_${PLATFORM}/Product/sun_cluster/Solaris_10/Packages}
    typeset BASEDIR=${BASEDIR:-/}
    
    cd $PATHNAME
    for i in *
    do
    	if pkginfo -R ${BASEDIR} $i >/dev/null 2>&1
    	then
    		mkdir -p ${BASEDIR}/var/sadm/pkg/$i/save/pspool
    		pkgadd -d . -R ${BASEDIR} -s ${BASEDIR}/var/sadm/pkg/$i/save/pspool $i
    	fi
    done
  3. Définissez les variables PLATFORM, PATHNAME et BASEDIR.

    Définissez ces variables en tant que variables d'environnement ou modifiez les valeurs directement dans le script.

    PLATFORM

    Nom de la plate-forme. Par exemple, sparc ou x86. Par défaut, la variable PLATFORM est définie sur le résultat de la commande uname -p.

    PATHNAME

    Chemin d'accès au périphérique à partir duquel les packages de structure ou de service de données Sun Cluster peuvent être installés. Cette valeur correspond à l'option -d de la commande pkgadd.

    Par exemple, pour des packages de structure Sun Cluster, cette valeur pourrait se présenter comme suit :


    /cdrom/cdrom0/Solaris_${PLATFORM}/Product/sun_cluster/Solaris_10/Packages

    Pour les packages de service de données, cette valeur pourrait se présenter comme suit :


    /cdrom/cdrom0/Solaris_${PLATFORM}/Product/sun_cluster_agents/Solaris_10/Packages
    BASEDIR

    Chemin d'accès complet à un répertoire à utiliser en tant que chemin d'accès racine et qui correspond à l'option -R de la commande pkgadd. Pour une mise à niveau directe, définissez cette valeur sur le chemin d'accès racine utilisé avec l'option -R de la commande scinstall. Par défaut, la variable BASEDIR est définie sur le système de fichiers racine (/).

  4. Exécutez le script, une fois pour les packages de structure Sun Cluster et une fois pour les packages de service de données.

    Une fois le script exécuté, le message suivant doit s'afficher à l'invite de commande de chaque package :


    Transferring pkgname package instance

    Remarque –

    Si le répertoire pspool existe déjà pour un package ou si le script est exécuté deux fois pour le même ensemble de packages, l'erreur suivante s'affiche à l'invite de commande :


    Transferring pkgname package instance
    pkgadd: ERROR: unable to complete package transfer
        - identical version of pkgname already exists on destination device

    Ce message est sans conséquence et peut être ignoré.


  5. Une fois le script exécuté pour les packages de structure et de service de données, initialisez les nœuds en mode cluster.

Impossible d'ajouter un nœud à un cluster de patch Sun Cluster 3.2 existant sans ajouter le patch principal Sun Cluster 3.2 au nœud (6554107)

Problème : l'ajout d'un nouveau nœud de cluster sans s'assurer que celui-ci comporte les mêmes patchs que les nœuds de cluster existants peut entraîner un dysfonctionnement des nœuds de cluster.

Solution : avant d'ajouter un nœud au cluster, vérifiez qu'il dispose des patchs de même niveau que les nœuds de cluster existants. Sinon les nœuds de cluster peuvent connaître un dysfonctionnement.