Ce chapitre fournit les informations et procédures suivantes pour mettre à niveau une configuration Sun Cluster 3.0 ou 3.1 vers le logiciel Sun Cluster 3.2 :
Exécution d'une mise à niveau à partition double vers Sun Cluster 3.2
Exécution d'une mise à niveau en direct vers Sun Cluster 3.2
Respectez les instructions ci-dessous de prise en charge lors de la mise à niveau vers Sun Cluster 3.2 :
Mise à niveau des systèmes x86 : sur les systèmes x86, vous ne pouvez pas procéder à une mise à niveau à partir du SE Solaris 9 vers le SE Solaris 10. Vous devez réinstaller le cluster en réinstallant le SE Solaris 10 et le logiciel Sun Cluster 3.2 pour les systèmes x86. Suivez les procédures du Chapitre 2, Installation du logiciel sur le cluster.
Version minimale du logiciel Sun Cluster : le logiciel Sun Cluster 3.2 prend en charge les chemins de mise à niveau directs suivants :
SPARC : À partir de la version 3.0 avec les versions de mise à jour vers la version 3.2 : utilisez la méthode de mise à niveau standard uniquement.
SPARC : À partir de la version 3.1, 3.1 10/03, 3.1 4/04 ou 3.1 9/04 vers la version 3.2 : utilisez la méthode standard, à partition double ou en direct.
À partir de la version 3.1 8/05 vers la version 3.2 : utilisez la méthode standard, à partition double ou en direct.
Pour connaître les détails des exigences supplémentaires et des restrictions de chaque méthode, reportez-vous à la section Choix d'une méthode de mise à niveau Sun Cluster.
Système d'exploitation Solaris minimum : le cluster doit être exécuté ou mis à niveau avec au moins Logiciel Solaris 9 9/05 ou Solaris 10 11/06, y compris avec les derniers patchs requis. Le système d'exploitation Solaris 9 est uniquement pris en charge sur les plates-formes SPARC.
Matériel pris en charge : le logiciel Sun Cluster 3.2 doit pouvoir prendre en charge la configuration du matériel de cluster. Contactez votre représentant Sun pour obtenir des informations sur les configurations Sun Cluster actuellement prises en charge.
Changements d'architecture lors de la mise à niveau : le logiciel Sun Cluster 3.2 ne prend pas en charge la mise à niveau d'architectures.
Migration logicielle : n'effectuez pas de migration depuis un type de logiciel vers un autre pendant la mise à niveau de Sun Cluster. Par exemple, la migration à partir de jeux de disques Solaris Volume Manager vers des groupes de disques VxVM ou à partir de systèmes de fichiers UFS vers des systèmes de fichiers VxFS n'est pas prise en charge pendant la mise à niveau de Sun Cluster. Effectuez uniquement les changements de configuration logicielle indiqués par les procédures de mise à niveau d'un logiciel installé.
Taille de partition des périphériques globaux : si la taille de votre partition /global/.devices/node@nodeid est inférieure à 512 Mo, mais que cela représente un espace suffisant pour les nœuds de périphériques existants, il n'est pas nécessaire de modifier la taille du système de fichiers. Le minimum de 512 Mo s'applique aux nouvelles installations de Sun Cluster 3.2. Cependant, vous devez tout de même vous assurer que le système de fichiers de périphériques globaux dispose d'un espace et d'une capacité d'inode amplement suffisants pour les périphériques existants et tous les nouveaux périphériques que vous prévoyez de configurer. Certains changements de configuration, comme l'ajout de disques, de volumes de disques ou de métapériphériques, peuvent exiger une augmentation de la taille de la partition afin de fournir des inodes supplémentaires suffisants.
Services de données : vous devez procéder à la mise à niveau de toutes les données de service Sun Cluster vers la version 3.2 et migrer les ressources vers la nouvelle version de type de ressources. Les services de données Sun Cluster 3.0 et 3.1 ne sont pas pris en charge par le logiciel Sun Cluster 3.2.
Mise à niveau vers une version compatible : vous devez mettre à niveau tous les logiciels des nœuds du cluster vers une version prise en charge par Sun Cluster 3.2. Par exemple, si une version d'un service de données est prise en charge par Sun Cluster, mais pas par Sun Cluster 3.2, vous devez mettre à niveau ce service de données vers la version prise en charge par Sun Cluster 3.2, si une telle version existe. Pour de plus amples informations sur les produits pris en charge, reportez-vous à la rubrique Produits pris en charge du Notes de version de Sun Cluster 3.2 pour SE Solaris.
Conversion à partir de groupes NAFO vers des groupes IPMP : pour une mise à niveau à partir de Sun Cluster 3.0, ayez à disposition les adresses IP de test à utiliser avec vos adaptateurs de réseau public lorsque des groupes NAFO sont convertis en groupes Multiacheminement sur réseau IP. L'utilitaire scinstall de mise à niveau vous invite à indiquer une adresse IP de test pour chaque adaptateur réseau public du cluster. L'adresse IP de test doit se trouver sur le même sous-réseau que l'adresse IP principale pour l'adaptateur.
Reportez-vous au IPMP, du System Administration Guide: IP Services (Solaris 9 ou Solaris 10) pour plus d'informations sur les adresses IP de test des groupes IPMP.
Mise à niveau inférieur : Sun Cluster 3.2 ne prend pas en charge la mise à niveau inférieur de Sun Cluster.
Limitation de scinstall sur les mises à niveau de services de données : l'utilitaire scinstall met à niveau uniquement les services de données fournis avec le logiciel Sun Cluster 3.2. Vous devez manuellement mettre à niveau tous les services de données personnalisés ou de fournisseurs tiers.
Pour mettre à niveau votre cluster vers Sun Cluster 3.2, optez pour l'une des méthodes suivantes :
Mise à niveau standard : dans une mise à niveau standard, vous devez arrêter le cluster avant de procéder à la mise à niveau des nœuds du cluster. Le cluster retrouve ses fonctions une fois la totalité des noeuds mise à niveau. Utilisez cette méthode si vous procédez à la mise à niveau à partir de Sun Cluster 3.0.
Mise à niveau à partition double : dans une mise à niveau à partition double, vous devez diviser le cluster en deux groupes de nœuds. Vous devez abaisser un groupe de nœuds et mettre à niveau ces nœuds. L'autre groupe de nœuds continue à fournir les services. Après avoir terminé la mise à niveau du premier groupe de nœuds, vous devez basculer les services vers les nœuds mis à niveau. Vous devez ensuite mettre à niveau les nœuds restants et les initialiser dans le reste du cluster. Le temps d'interruption du cluster est limité au temps nécessaire pour que le cluster bascule les services vers la partition mise à niveau.
Observez les exigences et les restrictions supplémentaires suivantes pour la méthode de mise à niveau à partition double :
Sun Cluster HA pour Sun Java System Application Server EE (HADB) : si vous exécutez le service de données Sun Cluster HA pour Sun Java System Application Server EE (HADB) avec Sun Java System Application Server EE (HADB) version 4.4 ou supérieure, vous devez arrêter la base de données avant de commencer la mise à niveau à partition double. La base de données HADB ne tolère pas la perte d'appartenance susceptible de se produire lorsqu'une partition de nœuds est arrêtée pour mise à niveau. Cette exigence ne s'applique pas aux versions antérieures à la version 4.4.
Changements de formats de données : n'utilisez pas la méthode de mise à niveau à partition double si vous prévoyez de mettre à niveau une application qui nécessite de modifier son format de données au cours de la mise à niveau de l'application. La méthode de mise à niveau à partition double n'est pas compatible avec l'indisponibilité étendue nécessaire pour effectuer une transformation de données.
Emplacement du logiciel de l'application : les applications doivent être installées sur une zone de stockage non partagée. Une partition en mode non cluster ne peut pas accéder au stockage partagé. Il n'est donc pas possible de mettre à niveau un logiciel situé sur un stockage partagé.
Division du stockage : chaque périphérique de stockage partagé doit être connecté à un nœud dans chaque groupe.
Clusters mononœuds : la mise à niveau à partition double n'est pas disponible pour la mise à niveau d'un cluster mononœud. Utilisez plutôt la mise à niveau standard ou la mise à niveau en direct.
Version minimale de Sun Cluster : le cluster doit exécuter la version Sun Cluster 3.1 avant que vous ne puissiez commencer la mise à niveau à partition double.
Changements de configuration : ne procédez à aucun changement de configuration de cluster autres que ceux indiqués dans les procédures de mise à niveau. Ces changements peuvent ne pas être propagés dans la configuration de cluster finale. De plus, les tentatives de validation de ces changements risquent d'échouer car il n'est pas possible d'atteindre tous les nœuds lors d'une mise à niveau à partition double.
Mise à niveau en direct : une mise à niveau en direct conserve votre configuration de cluster précédente jusqu'à la mise à niveau de tous les nœuds et la validation vers la mise à niveau. Si la configuration mise à niveau génère un problème, vous pouvez rétablir la configuration de cluster précédente jusqu'à ce que le problème soit corrigé.
Observez les exigences et les restrictions supplémentaires suivantes pour la méthode de mise à niveau en direct :
Version minimale de Sun Cluster : le cluster doit exécuter la version Sun Cluster 3.1 avant que vous ne puissiez commencer la mise à niveau à partition double.
Version minimale du logiciel Live Upgrade : pour utiliser la méthode de mise à niveau en direct, vous devez utiliser les packages Solaris Live Upgrade Solaris 9 9/04 ou Solaris 10 au minimum. Cette exigence s'applique aux clusters exécutés sous toutes les versions du système d'exploitation Solaris, y compris Solaris 8. Les procédures de mise à niveau en direct fournissent des instructions de mise à niveau de ces packages.
Mise à niveau à partition double : la méthode de mise à niveau en direct ne peut pas être utilisée en association avec une mise à niveau à partition double.
Zones non globales : la méthode de mise à niveau en direct ne prend pas en charge la mise à niveau des clusters possédant des zones non globales configurées sur l'un des nœuds du cluster. Utilisez plutôt la méthode de mise à niveau standard ou à partition double.
Espace disque : pour utiliser la méthode de mise à niveau en direct, vous devez disposer d'un espace disque disponible suffisant pour effectuer une copie de l'environnement d'initialisation de chaque nœud. Vous récupérez cet espace disque lorsque la mise à niveau est terminée, vérifiée et validée. Pour obtenir des informations sur l'espace requis pour un environnement d'initialisation inactif, reportez-vous à la rubrique Solaris Live Upgrade Disk Space Requirements du Solaris 9 9/04 Installation Guide ou à la rubrique Allocation d’espace disque et de swap du Guide d’installation de Solaris 10 : Solaris Live Upgrade et planification de la mise à niveau.
Pour obtenir des informations générales sur la planification de votre configuration Sun Cluster 3.2, reportez-vous au Chapitre 1, Planification de la configuration Sun Cluster.
Cette section fournit les informations suivantes nécessaires à la mise à niveau vers Sun Cluster 3.2 à l'aide de la méthode de mise à niveau standard :
Le tableau suivant répertorie les tâches à effectuer pour procéder à la mise à niveau depuis le logiciel Sun Cluster 3.1 vers le logiciel Sun Cluster 3.2. Vous pouvez également effectuer ces tâches pour mettre à niveau uniquement la version du SE Solaris. Si vous procédez à la mise à niveau du SE Solaris depuis Solaris 9 vers Solaris 10, vous devez également mettre à niveau le logiciel Sun Cluster et les logiciels de dépendance vers une version compatible avec la nouvelle version du SE Solaris.
Tableau 8–1 Liste des tâches : Exécution d'une mise à niveau standard vers Sun Cluster 3.2
Tâche |
Instructions |
---|---|
1. Lire les exigences et restrictions de la mise à niveau. Déterminer la méthode de mise à niveau appropriée pour votre configuration et vos besoins. | |
2. Désactiver le cluster et sauvegarder les données partagées. | |
3. Si nécessaire, mettre à niveau le logiciel Solaris vers une version de mise à jour Solaris prise en charge. Si le cluster utilise des médiateurs à deux chaînes pour Solaris Volume Manager, annuler leur configuration. Selon les besoins, mettre à niveau VERITAS Volume Manager (VxVM) et VERITAS File System (VxFS). Le logiciel Solaris Volume Manager est automatiquement mis à niveau avec le système d'exploitation Solaris. |
Mise à niveau du système d'exploitation Solaris et du logiciel Volume Manager (standard) |
4. Mettre à niveau vers une structure Sun Cluster 3.2 et un logiciel de service de données. Si nécessaire, mettre à niveau des applications. Si le cluster utilise des médiateurs à deux chaînes et que vous mettez à niveau le système d'exploitation Solaris, reconfigurer les médiateurs. Si VxVM a été mis à niveau, mettre à niveau les groupes de disques. | |
5. Vérifier le bon déroulement de la mise à niveau vers Sun Cluster 3.2. | |
6. Activer les ressources et connecter leur groupe. Migrer les ressources existantes vers de nouveaux types de ressources. | |
7. (Facultatif) SPARC : si nécessaire, mettre à niveau le module Sun Cluster pour Sun Management Center. |
SPARC : Mise à niveau du module Sun Cluster pour Sun Management Center |
Effectuez cette procédure pour supprimer le cluster de la production avant d'effectuer une mise à niveau standard. Sur Solaris 10, effectuez toutes les étapes à partir de la zone globale uniquement.
Effectuez les tâches suivantes :
Assurez-vous que la configuration respecte les conditions de mise à niveau. Reportez-vous à la rubrique Prise en charge liée à la mise à niveau.
Ayez à disposition les supports d'installation, la documentation et les patchs de tous les logiciels en cours de mise à niveau, notamment les logiciels suivants :
Les SE Solaris
Structure Sun Cluster 3.2
Services de données Sun Cluster 3.2 (agents)
Applications gérées par les services de données de Sun Cluster 3.2
VERITAS Volume Manager, le cas échéant
Pour connaître l'emplacement des patchs et les instructions d'installation, reportez-vous à la section Patchs et niveaux des micrologiciels requis du Notes de version de Sun Cluster 3.2 pour SE Solaris.
Si vous utilisez le contrôle d'accès basé sur les rôles (RBAC) au lieu du superutilisateur pour accéder aux nœuds du cluster, vérifiez que vous pouvez disposer d'un rôle RBAC fournissant une autorisation pour toutes les commandes Sun Cluster. Cette série de procédures de mise à niveau requiert les autorisations RBAC Sun Cluster suivantes si l'utilisateur n'est pas un superutilisateur :
solaris.cluster.modify
solaris.cluster.admin
solaris.cluster.read
Reportez-vous à la rubrique Role-Based Access Control (Overview) du System Administration Guide: Security Services pour plus d'informations sur l'utilisation des rôles RBAC. Reportez-vous aux pages de manuel Sun Cluster pour connaître l'autorisation RBAC nécessaire à chaque sous-commande Sun Cluster.
Vérifiez que le cluster fonctionne normalement.
Affichez le statut actuel du cluster en exécutant la commande suivante à partir de n'importe quel nœud.
phys-schost% scstat |
Reportez-vous à la page de manuel scstat(1M) pour obtenir plus d'informations.
Recherchez le journal /var/adm/messages sur chaque noeud pour obtenir les erreurs non résolues et les messages d'avertissement.
Vérifiez l'état du gestionnaire de volumes.
Informez les utilisateurs de l'indisponibilité des services du cluster au cours de la mise à niveau.
Devenez superutilisateur sur un noeud du cluster.
Mettez chaque groupe de ressources hors ligne et désactivez toutes les ressources.
Mettez hors ligne tous les groupes de ressources du cluster, y compris ceux qui se trouvent dans les zones non globales. Ensuite, désactivez toutes les ressources pour éviter que le cluster ne remette les ressources en ligne automatiquement si un nœud est réinitialisé en mode cluster par erreur.
Si vous procédez à une mise à niveau à partir de Sun Cluster 3.1 et que vous souhaitez utiliser l'utilitaire scsetup, effectuez les étapes suivantes :
Lancez l'utilitaire scsetup.
phys-schost# scsetup |
Le menu principal scsetup s'affiche.
Saisissez le numéro correspondant à l'option des groupes de ressources, puis appuyez sur la touche Retour.
Le menu du groupe de ressources apparaît.
Saisissez le numéro correspondant à l'option en ligne/hors ligne ou la commutation d'un groupe de ressources, puis appuyez sur la touche Retour.
Suivez les instructions pour désactiver tous les groupes de ressources et les placer en mode sans gestion.
Une fois tous les groupes de ressources désactivés, entrez q pour revenir au menu Groupe de ressources.
Quittez l'utilitaire scsetup.
Entrez q pour sortir de chaque sous-menu ou appuyez sur Ctrl+C.
Pour utiliser la ligne de commande, effectuez les étapes suivantes :
Mettez la ressource hors ligne.
phys-schost# scswitch -F -g resource-group |
Bascule un groupe de ressources hors ligne.
Indique le nom du groupe de ressources à mettre hors ligne.
À partir d'un nœud, dressez la liste de toutes les ressources activées dans le cluster.
phys-schost# scrgadm -pv | grep "Res enabled" (resource-group:resource) Res enabled: True |
Identifiez les ressources dépendant d'autres ressources.
Vous devez d'abord désactiver les ressources dépendantes avant de désactiver celles dont elles dépendent.
Désactivez chaque ressource activée dans le cluster.
phys-schost# scswitch -n -j resource |
Désactive.
Indique la ressource.
Reportez-vous à la page de manuel scswitch(1M) pour obtenir plus d'informations.
Assurez-vous que toutes les ressources sont désactivées.
phys-schost# scrgadm -pv | grep "Res enabled" (resource-group:resource) Res enabled: False |
Basculez l'état de chaque groupe de ressources sur sans gestion.
phys-schost# scswitch -u -g resource-group |
Bascule le groupe de ressources spécifié en mode sans gestion.
Spécifie le nom du groupe de ressources à basculer en mode sans gestion.
Vérifiez que les ressources de tous les nœuds sont déconnectées et que tous les groupes de ressources sont en mode sans gestion.
phys-schost# scstat |
Pour un cluster à deux nœuds qui utilise le logiciel Sun StorEdge Availability Suite ou le logiciel Sun StorageTekTM Availability Suite, vérifiez que les données de configuration pour les services de disponibilité résident sur le disque de quorum.
Les données de configuration doivent résider sur le disque de quorum pour garantir le fonctionnement correct d'Availability Suite après la mise à niveau du logiciel de cluster.
Devenez superutilisateur d'un nœud de cluster qui exécute le logiciel Availability Suite.
Identifiez l'ID de périphérique et la tranche utilisés par le fichier de configuration de Availability Suite.
phys-schost# /usr/opt/SUNWscm/sbin/dscfg /dev/did/rdsk/dNsS |
Dans cet exemple, N correspond à l'ID du périphérique et T à la tranche du périphérique N.
Identifiez le périphérique de quorum existant.
phys-schost# scstat -q -- Quorum Votes by Device -- Device Name Present Possible Status ----------- ------- -------- ------ Device votes: /dev/did/rdsk/dQsS 1 1 Online |
Dans cet exemple, dQsS correspond au périphérique de quorum existant.
Si le périphérique de quorum n'est pas le périphérique de données de configuration de Availability Suite, déplacez les données de configuration vers une tranche disponible du périphérique de quorum.
phys-schost# dd if=`/usr/opt/SUNWesm/sbin/dscfg` of=/dev/did/rdsk/dQsS |
Vous devez utiliser le nom du périphérique DID en mode caractère, /dev/did/rdsk/, et non celui du périphérique DID en mode bloc, /dev/did/dsk/.
Si vous avez déplacé les données de configuration, configurez Availability Suite pour qu'il utilise le nouvel emplacement.
En tant que superutilisateur, exécutez la commande suivante sur chaque nœud exécutant le logiciel Availability Suite.
phys-schost# /usr/opt/SUNWesm/sbin/dscfg -s /dev/did/rdsk/dQsS |
(Facultatif) Si vous procédez à la mise à niveau depuis une version du logiciel Sun Cluster 3.0 et ne souhaitez pas que votre fichier ntp.conf soit renommé en ntp.conf.cluster, créez un fichier ntp.conf.cluster.
Sur chaque nœud, copiez /etc/inet/ntp.cluster sous le nom ntp.conf.cluster.
phys-schost# cp /etc/inet/ntp.cluster /etc/inet/ntp.conf.cluster |
L'existence d'un fichier ntp.conf.cluster empêche le processus de mise à niveau de renommer le fichier ntp.conf. Le fichier ntp.conf sera toujours utilisé pour synchroniser NTP entre les nœuds du cluster.
Fermez toutes les applications ouvertes sur chaque noeud du cluster.
Assurez-vous que toutes les données partagées sont sauvegardées.
Si vous prévoyez de mettre à niveau le SE Solaris et que votre cluster utilise des médiateurs à deux chaînes pour le logiciel Solaris Volume Manager, annulez la configuration de vos médiateurs.
Pour de plus amples informations sur les médiateurs, reportez-vous à la rubrique Configuration de médiateurs à deux chaînes.
Exécutez la commande suivante pour vérifier l'absence de problèmes de données du médiateur.
phys-schost# medstat -s setname |
Spécifie le nom du jeu de disques.
Si le champ Statut affiche la valeur Incorrect, réparez l'hôte médiateur affecté. Suivez la procédure de la rubrique Correction des données incorrectes du médiateur.
Répertoriez tous les médiateurs.
Enregistrez ces informations pour les cas où vous devez restaurer les médiateurs pendant la procédure de la section Finition de la mise à niveau vers Sun Cluster 3.2.
Lorsqu'un jeu de disques utilise des médiateurs, devenez propriétaire du jeu si aucun nœud n'en est propriétaire.
phys-schost# scswitch -z -D setname -h node |
Change de maître.
Indique le nom du jeu de disques.
Indique le nom du nœud que vous voulez convertir en nœud principal du jeu de disques.
Annulez la configuration de tous les médiateurs du jeu de disques.
phys-schost# metaset -s setname -d -m mediator-host-list |
Spécifie le nom du jeu de disques.
Supprime du jeu de disques.
Indique le nom du nœud à supprimer en tant qu'hôte médiateur du jeu de disques.
Reportez-vous à la page de manuel mediator(7D) afin d'obtenir plus d'informations sur les options spécifiques du médiateur pour la commande metaset.
Répétez de l'étape c à l'étape d pour chaque jeu de disques restant qui utilise des médiateurs.
Arrêtez le cluster depuis un noeud.
# scshutdown -g0 -y |
Reportez-vous à la page de manuel scshutdown(1M) pour plus d'informations.
Réinitialisez chaque noeud en mode non cluster.
Sur les systèmes SPARC, exécutez la commande suivante :
ok boot -x |
Sur les systèmes x86, exécutez les commandes suivantes :
Dans le menu GRUB, utilisez les touches fléchées pour sélectionner l'entrée Solaris appropriée, puis saisissez e pour modifier ses commandes.
Le menu GRUB qui s'affiche est similaire à ce qui suit :
GNU GRUB version 0.95 (631K lower / 2095488K upper memory) +-------------------------------------------------------------------------+ | Solaris 10 /sol_10_x86 | | Solaris failsafe | | | +-------------------------------------------------------------------------+ Use the ^ and v keys to select which entry is highlighted. Press enter to boot the selected OS, 'e' to edit the commands before booting, or 'c' for a command-line. |
Pour plus d'informations sur l'initialisation GRUB, reportez-vous au Chapitre 11, GRUB Based Booting (Tasks) du System Administration Guide: Basic Administration.
Sur l'écran des paramètres d'initialisation, utilisez les touches fléchées pour sélectionner l'entrée kernel et saisissez e pour modifier l'entrée.
L'écran des paramètres d'initialisation GRUB qui s'affiche est similaire à ce qui suit :
GNU GRUB version 0.95 (615K lower / 2095552K upper memory) +----------------------------------------------------------------------+ | root (hd0,0,a) | | kernel /platform/i86pc/multiboot | | module /platform/i86pc/boot_archive | +----------------------------------------------------------------------+ Use the ^ and v keys to select which entry is highlighted. Press 'b' to boot, 'e' to edit the selected command in the boot sequence, 'c' for a command-line, 'o' to open a new line after ('O' for before) the selected line, 'd' to remove the selected line, or escape to go back to the main menu. |
Ajoutez -x à la commande pour spécifier l'initialisation du système en mode non cluster.
[ Minimal BASH-like line editing is supported. For the first word, TAB lists possible command completions. Anywhere else TAB lists the possible completions of a device/filename. ESC at any time exits. ] grub edit> kernel /platform/i86pc/multiboot -x |
Appuyez sur Entrée pour accepter la modification et retourner à l'écran des paramètres d'initialisation.
L'écran affiche la commande modifiée.
GNU GRUB version 0.95 (615K lower / 2095552K upper memory) +----------------------------------------------------------------------+ | root (hd0,0,a) | | kernel /platform/i86pc/multiboot -x | | module /platform/i86pc/boot_archive | +----------------------------------------------------------------------+ Use the ^ and v keys to select which entry is highlighted. Press 'b' to boot, 'e' to edit the selected command in the boot sequence, 'c' for a command-line, 'o' to open a new line after ('O' for before) the selected line, 'd' to remove the selected line, or escape to go back to the main menu.- |
Saisissez b pour initialiser le nœud en mode non cluster.
Cette modification apportée à la commande du paramètre d'initialisation du noyau n'est pas conservée après l'initialisation du système. La prochaine réinitialisation du nœud se fera donc en mode cluster. Pour effectuer un démarrage en mode non-cluster, exécutez à nouveau ces étapes pour ajouter l'option -x à la commande du paramètre d'initialisation du noyau.
Assurez-vous que chaque disque système est sauvegardé.
Mettez à niveau le logiciel sur chaque nœud.
Pour mettre à niveau le logiciel Solaris avant de procéder à la mise à niveau de Sun Cluster, reportez-vous à la section Mise à niveau du système d'exploitation Solaris et du logiciel Volume Manager (standard).
Vous devez mettre à niveau le logiciel Solaris vers une version prise en charge si Sun Cluster 3.2 ne prend pas en charge la version du système d'exploitation Solaris sur lequel votre cluster est actuellement exécuté. Pour de plus amples informations, reportez-vous à la rubrique « Produits pris en charge » des Notes de version de Sun Cluster 3.2 pour SE Solaris.
En revanche, si Sun Cluster 3.2 prend en charge la version de Solaris exécutée sur le cluster, il n'est pas nécessaire d'effectuer la mise à niveau de Solaris.
Dans le cas contraire, procédez à la mise à niveau vers Sun Cluster 3.2. Reportez-vous à la section Mise à niveau de Sun Cluster 3.2 (standard).
Effectuez cette procédure sur chaque noeud du cluster pour mettre à niveau le système d'exploitation Solaris. Sur Solaris 10, effectuez toutes les étapes à partir de la zone globale uniquement.Si le cluster fonctionne déjà avec une version de Solaris prenant en charge Sun Cluster 3.2, il n'est pas nécessaire de mettre Solaris à niveau. Si vous ne prévoyez pas de mettre à niveau le système d'exploitation Solaris, reportez-vous à la rubrique Mise à niveau de Sun Cluster 3.2 (standard).
Le cluster doit déjà fonctionner avec, ou être mis à niveau vers, au moins le niveau minimum requis du système d'exploitation Solaris pour prendre en charge la mise à niveau vers Sun Cluster 3.2. Pour de plus amples informations, reportez-vous à la rubrique « Produits pris en charge » des Notes de version de Sun Cluster 3.2 pour SE Solaris.
Assurez-vous d'avoir suivi toutes les étapes de la rubrique Préparation du cluster pour la mise à niveau (standard).
Devenez superutilisateur du nœud de cluster à mettre à niveau.
Si vous effectuez une mise à niveau à partition double, le nœud doit être un membre de la partition en mode non cluster.
Si le logiciel Sun Cluster Geographic Edition est installé, désinstallez-le.
Pour connaître les procédures de désinstallation, reportez-vous à la documentation correspondant à votre version de Sun Cluster Geographic Edition.
Déterminez si les scripts suivants de contrôle d'exécution Apache sont présents et activés :
/etc/rc0.d/K16apache /etc/rc1.d/K16apache /etc/rc2.d/K16apache /etc/rc3.d/S50apache /etc/rcS.d/K16apache |
Certaines applications, telles que Sun Cluster HA pour Apache, nécessitent la désactivation des scripts de contrôle d'exécution Apache.
Si ces scripts existent et contiennent un K ou un S en majuscule dans le nom de fichier, ils sont activés. Ils ne nécessitent aucune autre intervention.
Si ces scripts n'existent pas, vous devez vérifier à l'Étape 8 que ceux installés lors de la mise à niveau du système d'exploitation Solaris sont désactivés.
Si ces scripts existent et contiennent un k ou un s en minuscule, ils sont désactivés. À l'Étape 8, vous devez vous assurer de la désactivation des scripts de contrôle d'exécution Apache installés lors de la mise à niveau du système d'exploitation Solaris.
Commentez toutes les entrées des systèmes de fichiers montés globalement dans le fichier /etc/vfstab du nœud.
Notez toutes les entrées faisant déjà l'objet d'un commentaire afin de pouvoir vous y reporter ultérieurement.
Mettez en commentaire provisoirement toutes les entrées des systèmes de fichiers montés globalement dans le fichier/etc/vfstab.
Ces entrées contiennent l'option de montage global. En les mettant en commentaire, vous empêchez la mise à niveau de Solaris de monter les périphériques globaux.
Déterminez la procédure à suivre pour mettre à niveau le système d'exploitation Solaris.
Gestionnaire de volumes |
Procédure |
Emplacement des instructions |
---|---|---|
Solaris Volume Manager |
Toute méthode de mise à niveau de Solaris à l'exception de la méthode Live Upgrade. |
Documentation d'installation de Solaris |
VERITAS Volume Manager |
“Mise à niveau de VxVM et de Solaris” |
Documentation d'installation de VERITAS Volume Manager |
Si VxVM est installé sur votre cluster, vous devez réinstaller le logiciel VxVM existant ou effectuer une mise à niveau vers la version Solaris 9 ou 10 dans le cadre de la mise à niveau Solaris.
En fonction du choix opéré à l'Étape 5, mettez à niveau Solaris.
Ne suivez pas l'instruction finale de réinitialisation lors de la mise à niveau de Solaris. Procédez donc comme suit :
Pour terminer la mise à niveau de Solaris, effectuez la réinitialisation en mode non cluster à l'Étape 9.
Lorsque vous y êtes invité, choisissez l'option de réinitialisation manuelle.
Si vous êtes invité à réinitialiser un nœud lors de la mise à niveau, effectuez toujoursl'opération en mode non cluster. À la commande boot ou reboot, ajoutez l'option -x. L'option -x vous assure que le nœud est réinitialisé en mode non cluster. Par exemple, les deux commandes suivantes initialisent un noeud en mode monoutilisateur non cluster :
Sur les systèmes SPARC, exécutez l'une des commandes suivantes :
phys-schost# reboot -- -xs or ok boot -xs |
Si vous êtes invité à exécuter init S, utilisez plutôt la commande reboot -- -xs.
Sur les systèmes x86 exécutés sous Solaris 9, exécutez l'une des commandes suivantes :
phys-schost# reboot -- -xs or ... <<< Current Boot Parameters >>> Boot path: /pci@0,0/pci-ide@7,1/ata@1/cmdk@0,0:b Boot args: Type b [file-name] [boot-flags] <ENTER> to boot with options or i <ENTER> to enter boot interpreter or <ENTER> to boot with defaults <<< timeout in 5 seconds >>> Select (b)oot or (i)nterpreter: b -xs |
Sur les systèmes x86 exécutés sous Solaris 10, exécutez la commande suivante :
phys-schost# shutdown -g -y -i0Press any key to continue |
Dans le menu GRUB, utilisez les touches fléchées pour sélectionner l'entrée Solaris appropriée, puis saisissez e pour modifier ses commandes.
Le menu GRUB qui s'affiche est similaire à ce qui suit :
GNU GRUB version 0.95 (631K lower / 2095488K upper memory) +-------------------------------------------------------------------------+ | Solaris 10 /sol_10_x86 | | Solaris failsafe | | | +-------------------------------------------------------------------------+ Use the ^ and v keys to select which entry is highlighted. Press enter to boot the selected OS, 'e' to edit the commands before booting, or 'c' for a command-line. |
Pour plus d'informations sur l'initialisation GRUB, reportez-vous au Chapitre 11, GRUB Based Booting (Tasks) du System Administration Guide: Basic Administration.
Sur l'écran des paramètres d'initialisation, utilisez les touches fléchées pour sélectionner l'entrée kernel et saisissez e pour modifier l'entrée.
L'écran des paramètres d'initialisation GRUB qui s'affiche est similaire à ce qui suit :
GNU GRUB version 0.95 (615K lower / 2095552K upper memory) +----------------------------------------------------------------------+ | root (hd0,0,a) | | kernel /platform/i86pc/multiboot | | module /platform/i86pc/boot_archive | +----------------------------------------------------------------------+ Use the ^ and v keys to select which entry is highlighted. Press 'b' to boot, 'e' to edit the selected command in the boot sequence, 'c' for a command-line, 'o' to open a new line after ('O' for before) the selected line, 'd' to remove the selected line, or escape to go back to the main menu. |
Ajoutez -x à la commande pour spécifier l'initialisation du système en mode non cluster.
[ Minimal BASH-like line editing is supported. For the first word, TAB lists possible command completions. Anywhere else TAB lists the possible completions of a device/filename. ESC at any time exits. ] grub edit> kernel /platform/i86pc/multiboot -x |
Appuyez sur Entrée pour accepter la modification et retourner à l'écran des paramètres d'initialisation.
L'écran affiche la commande modifiée.
GNU GRUB version 0.95 (615K lower / 2095552K upper memory) +----------------------------------------------------------------------+ | root (hd0,0,a) | | kernel /platform/i86pc/multiboot -x | | module /platform/i86pc/boot_archive | +----------------------------------------------------------------------+ Use the ^ and v keys to select which entry is highlighted. Press 'b' to boot, 'e' to edit the selected command in the boot sequence, 'c' for a command-line, 'o' to open a new line after ('O' for before) the selected line, 'd' to remove the selected line, or escape to go back to the main menu.- |
Saisissez b pour initialiser le nœud en mode non cluster.
Cette modification apportée à la commande du paramètre d'initialisation du noyau n'est pas conservée après l'initialisation du système. La prochaine réinitialisation du nœud se fera donc en mode cluster. Pour effectuer un démarrage en mode non cluster, exécutez à nouveau ces étapes pour ajouter l'option -x à la commande du paramètre d'initialisation du noyau.
Si l'instruction vous indique d'exécuter la commande init S, arrêtez le système, puis modifiez plutôt la commande d'initialisation de noyau GRUB sur /platform/i86pc/multiboot -sx.
Dans le fichier /a/etc/vfstab, retirez les commentaires de l' Étape 4 sur les entrées des systèmes de fichiers montés globalement.
Si les scripts de contrôle d'exécution Apache étaient désactivés ou n'existaient pas avant la mise à niveau du système d'exploitation Solaris, vérifiez que les scripts installés au cours de la mise à niveau de Solaris sont désactivés.
Pour désactiver les scripts de contrôle d'exécution Apache, utilisez les commandes suivantes pour renommer les fichiers avec un k ou un s minuscule.
phys-schost# mv /a/etc/rc0.d/K16apache /a/etc/rc0.d/k16apache phys-schost# mv /a/etc/rc1.d/K16apache /a/etc/rc1.d/k16apache phys-schost# mv /a/etc/rc2.d/K16apache /a/etc/rc2.d/k16apache phys-schost# mv /a/etc/rc3.d/S50apache /a/etc/rc3.d/s50apache phys-schost# mv /a/etc/rcS.d/K16apache /a/etc/rcS.d/k16apache |
Vous pouvez alternativement renommer les scripts conformément à vos pratiques administratives.
Réinitialisez le noeud en mode non cluster.
Insérez un double tiret (--) dans la commande suivante :
phys-schost# reboot -- -x |
Si votre cluster exécute VxVM, suivez les étapes restantes de la procédure « Mise à niveau de VxVM et du logiciel Solaris » pour réinstaller ou mettre à niveau VxVM.
Apportez les changements suivants à la procédure :
Une fois la mise à niveau de VxVM terminée, mais avant de procéder à la réinitialisation, vérifiez les entrées du fichier /etc/vfstab.
Si des commentaires d'entrée n'ont pas été retirés à l'Étape 7 réessayez.
Si VxVM vous invite à effectuer une reconfiguration finale après réinitialisation, n'utilisez pas l'option -r seule. Utilisez plutôt les options -rx pour effectuer une réinitialisation en mode non cluster.
Sur les systèmes SPARC, exécutez la commande suivante :
phys-schost# reboot -- -rx |
Sur les systèmes x86, effectuez les procédures d'arrêt et d'initialisation décrites dans l'Étape 6, mais ajoutez -rx à la commande d'initialisation du noyau au lieu de -sx.
Si un message similaire à celui-ci s'affiche, entrez le mot de passe racine pour continuer la mise à niveau. N'exécutez pas la commande fsck et n'appuyez pas sur Ctrl+D.
WARNING - Unable to repair the /global/.devices/node@1 filesystem. Run fsck manually (fsck -F ufs /dev/vx/rdsk/rootdisk_13vol). Exit the shell when done to continue the boot process. Type control-d to proceed with normal startup, (or give root password for system maintenance): Type the root password |
(Facultatif) SPARC : mettez à niveau VxFS.
Suivez les instructions des procédures fournies dans la documentation VxFS.
Installez tous les patchs du logiciel Solaris ainsi que les patchs matériels, puis téléchargez tous les microprogrammes des patchs matériels dont vous pourriez avoir besoin.
n'effectuez aucune réinitialisation après l'ajout des patchs. Attendez la fin de la mise à niveau du logiciel Sun Cluster pour réinitialiser le nœud.
Pour connaître l'emplacement des patchs et les instructions d'installation, reportez-vous à la section Patchs et niveaux des micrologiciels requis du Notes de version de Sun Cluster 3.2 pour SE Solaris.
Mise à niveau vers le logiciel Sun Cluster 3.2 Reportez-vous à la section Mise à niveau de Sun Cluster 3.2 (standard).
Si vous procédez à la mise à niveau du système d'exploitation Solaris vers une nouvelle version marketing, par exemple à partir de Solaris 8 vers Solaris 10, vous devez également mettre à niveau le logiciel Sun Cluster et les logiciels de dépendance vers une version compatible avec la nouvelle version du système d'exploitation Solaris.
Effectuez cette procédure afin de mettre à niveau chacun des nœuds du cluster vers Sun Cluster 3.2. Cette procédure met également à niveau les composants Sun Java Enterprise System requis.
Vous devez également effectuer cette procédure après la mise à niveau vers une version marketing différente du système d'exploitation Solaris, notamment à partir de Solaris 8 vers Solaris 10.
Sur Solaris 10, effectuez toutes les étapes à partir de la zone globale uniquement.
vous pouvez effectuer cette procédure sur plusieurs nœuds simultanément.
Effectuez les tâches suivantes :
Assurez-vous d'avoir suivi toutes les étapes de la rubrique Préparation du cluster pour la mise à niveau (standard).
Si vous avez procédé à une mise à niveau vers une nouvelle version marketing du système d'exploitation Solaris, par exemple à partir de Solaris 8 vers Solaris 10, assurez-vous que toutes les étapes de la section Mise à niveau du système d'exploitation Solaris et du logiciel Volume Manager (standard) sont appliquées.
Assurez-vous d'avoir installé tous les patchs requis du logiciel Solaris ainsi que les patchs matériels.
Devenez superutilisateur sur un noeud du cluster.
Vérifiez que le répertoire /usr/java/ est un lien symbolique vers la version minimum ou la dernière version du logiciel Java.
Le logiciel Sun Cluster requiert au minimum la version 1.5.0_06 du logiciel Java. Si vous avez procédé à la mise à niveau vers une version de Solaris qui installe une version antérieure de Java, il se peut que la mise à niveau ait modifié le lien symbolique pour pointer vers une version de Java ne correspondant pas au minimum requis pour le logiciel Sun Cluster 3.2.
Identifiez le répertoire auquel /usr/java/ est associé par lien symbolique.
phys-schost# ls -l /usr/java lrwxrwxrwx 1 root other 9 Apr 19 14:05 /usr/java -> /usr/j2se/ |
Identifiez la ou les versions installées du logiciel Java.
L'exemple suivant présente les commandes que vous pouvez utiliser pour afficher les versions connexes du logiciel Java.
phys-schost# /usr/j2se/bin/java -version phys-schost# /usr/java1.2/bin/java -version phys-schost# /usr/jdk/jdk1.5.0_06/bin/java -version |
Si le répertoire /usr/java/ n'est pas associé par un lien symbolique à une version prise en charge du logiciel Java, recréez le lien symbolique.
L'exemple suivant présente la création d'un lien symbolique vers le répertoire /usr/j2se/ contenant le logiciel Java 1.5.0_06.
phys-schost# rm /usr/java phys-schost# ln -s /usr/j2se /usr/java |
Chargez le DVD-ROM Sun Java Availability Suite dans le lecteur DVD-ROM\~;.
Si le démon de gestion de volumes vold(1M) est en cours d'exécution et qu'il est configuré pour gérer les périphériques de CD-ROM ou de DVD, il monte automatiquement le support sur le répertoire /cdrom/cdrom0/.
Déplacez-vous sur le répertoire assistant d'installation du DVD-ROM\~;.
Si vous installez les packages du logiciel sur une plate-forme SPARC, exécutez la commande suivante :
phys-schost# cd /cdrom/cdrom0//Solaris_sparc |
Si vous installez les packages du logiciel sur une plate-forme x86, exécutez la commande suivante :
phys-schost# cd /cdrom/cdrom0//Solaris_x86 |
Démarrez le programme assistant d'installation.
phys-schost# ./installer |
Suivez les instructions qui apparaissent à l'écran pour sélectionner et mettre à niveau les packages des composants partagés sur le nœud.
N'utilisez pas l'assistant d'installation pour mettre à niveau les packages Sun Cluster.
Le programme assistant d'installation affiche l'état de l'installation. Une fois l'installation terminée, le programme affiche un récapitulatif et l'installation démarre.
Quittez le programme assistant d'installation.
Déplacez-vous sur le répertoire RépertoireSolaris_arch/Product/sun_cluster/Solaris_ver/Tools/ , où arch est sparc ou x86 (Solaris 10 uniquement) et où ver est 9 pour Solaris 9 ou 10 pour Solaris 10 .
phys-schost# cd /cdrom/cdrom0/Solaris_arch/Product/sun_cluster/Solaris_ver/Tools |
Lancer l'utilitaire scinstall.
phys-schost# ./scinstall |
n'utilisez pas la commande /usr/cluster/bin/scinstall déjà installée sur le noeud. Vous devez utiliser la commande scinstall située sur le DVD-ROM Sun Java Availability Suite.
Le menu principal scinstall s'affiche.
Saisissez le numéro correspondant à l'option de mise à niveau de ce nœud de cluster, puis appuyez sur la touche Retour.
*** Main Menu *** Please select from one of the following (*) options: * 1) Create a new cluster or add a cluster node 2) Configure a cluster to be JumpStarted from this install server * 3) Manage a dual-partition upgrade * 4) Upgrade this cluster node * 5) Print release information for this cluster node * ?) Help with menu options * q) Quit Option: 4 |
Le menu de mise à niveau s'affiche.
Saisissez le numéro correspondant à l'option de mise à niveau de la structure Sun Cluster sur ce nœud de cluster, puis appuyez sur la touche Retour.
Suivez les instructions pour mettre à niveau la structure du cluster.
Lors de la mise à niveau de Sun Cluster, scinstall risque d'apporter le(s) changement(s) de configuration suivant(s) :
Convertissez les groupes NAFO en groupes IPMP, mais conservez le nom du groupe NAFO de départ.
Reportez-vous à l'un des manuels suivants afin d'obtenir des informations sur les adresses de test pour IPMP :
Configuration des adresses de test de la rubrique Administering Multipathing Groups With Multiple Physical Interfaces du System Administration Guide: IP Services (Solaris 9)
Test Addresses du System Administration Guide: IP Services (Solaris 10)
Reportez-vous à la page de manuel scinstall(1M) pour obtenir plus d'informations sur la conversion de groupes NAFO en ensembles IPMP lors de la mise à niveau de Sun Cluster.
Renommez le fichier ntp.conf en ntp.conf.cluster, si ce dernier n'existe pas déjà.
Si nécessaire, définissez la variable local-mac-address? sur true.
La mise à niveau de la structure Sun Cluster est terminée lorsque le système affiche un message de confirmation et vous invite à appuyer sur la touche entrée.
Fermez l'utilitaire scinstall.
Retirez le DVD-ROM Sun Java Availability Suite du lecteur DVD-ROM\~;.
Mettez à niveau les packages de services de données.
Vous devez mettre à niveau tous les services de données vers la version 3.2 de Sun Cluster.
Pour Sun Cluster HA pour SAP Web Application Server, si vous utilisez une ressource de moteur J2EE ou une ressource de composant serveur d'application Web, ou les deux, vous devez supprimer la ressource et la recréer avec la nouvelle ressource de composant serveur d'application Web. Les modifications apportées à la nouvelle ressource de composant serveur d'application Web incluent l'intégration de la fonctionnalité J2EE. Pour plus d'informations, reportez-vous au manuel Sun Cluster Data Service for SAP Web Application Server Guide for Solaris OS.
Lancez l'utilitaire scinstall interactif mis à niveau.
phys-schost# /usr/cluster/bin/scinstall |
N'utilisez pas l'utilitaire scinstall se trouvant sur le support d'installation pour mettre à niveau les packages de services de données.
Le menu principal scinstall s'affiche.
Saisissez le numéro correspondant à l'option de mise à niveau de ce nœud de cluster, puis appuyez sur la touche Retour.
Le menu de mise à niveau s'affiche.
Saisissez le numéro correspondant à l'option de mise à niveau des agents de services de données Sun Cluster sur ce nœud, puis appuyez sur la touche Retour.
Suivez les instructions pour mettre à niveau les agents de services de données Sun Cluster installés sur le nœud.
Vous pouvez choisir de mettre à niveau tous les services de données installés ou une partie des éléments répertoriés.
La mise à niveau est terminée lorsque le système affiche un message de confirmation signalant que la mise à niveau des agents de services de données a été effectuée avec succès et vous invite à appuyer sur la touche Entrée pour continuer.
Appuyez sur Entr\'e9e.
Le menu de mise à niveau s'affiche.
Fermez l'utilitaire scinstall.
Si Sun Cluster HA pour NFS est configuré sur un système de fichiers local à forte disponibilité, assurez-vous que le système de fichiers loopback (LOFS) est désactivé.
Si des zones non globales sont configurées, le LOFS doit rester activé. Pour obtenir des directives sur l'utilisation du LOFS et les possibilités de le désactiver, reportez-vous à la section Systèmes de fichiers de grappe.
À partir de la version 3.2 de Sun Cluster, le LOFS n'est plus désactivé par défaut au cours de l'installation ou de la mise à niveau de Sun Cluster. Pour désactiver le LOFS, assurez-vous que le ficher /etc/system contient l'entrée suivante :
exclude:lofs |
Ce changement est pris en compte à la prochaine réinitialisation du système.
En fonction des besoins, mettez à niveau manuellement les services de données personnalisés non disponibles sur le support produit.
Vérifiez que chaque mise à jour des services de données est correctement installée.
Consultez le journal de la mise à niveau, référencé à la fin des messages émis en cours de mise à niveau.
Installez les patchs du logiciel de service de données et de l'architecture de Sun Cluster 3.2.
Pour connaître l'emplacement des patchs et les instructions d'installation, reportez-vous à la section Patchs et niveaux des micrologiciels requis du Notes de version de Sun Cluster 3.2 pour SE Solaris.
Mettez à niveau les applications du logiciel installées sur le cluster.
Assurez-vous que les niveaux des applications sont compatibles avec les versions actuelles de Sun Cluster et du logiciel Solaris. Reportez-vous à la documentation de l'application pour les instructions d'installation.
(Facultatif) Reconfigurez la plage d'adresses du réseau privé.
Effectuez cette étape si vous souhaitez augmenter ou réduire la taille de la plage d'adresses IP utilisée par l'interconnexion privée. La plage d'adresses IP configurée doit au minimum prendre en charge le nombre de nœuds et de réseaux privés du cluster. Pour de plus amples informations, reportez-vous à la section Réseau privé.
À partir d'un nœud, lancez l'utilitaire clsetup.
S'il est exécuté en mode non cluster, l'utilitaire clsetup affiche le menu principal pour les opérations en mode non cluster.
Saisissez le numéro correspondant à l'option de modification de la plage d'adresses IP, puis appuyez sur la touche Retour.
L'utilitaire clsetup affiche la configuration de réseau privé actuelle, puis vous demande si vous souhaitez modifier cette configuration.
Pour modifier l'adresse IP de réseau privé ou la plage d'adresses IP, tapez oui, puis appuyez sur la touche Retour.
L'utilitaire clsetup affiche l'adresse IP de réseau privé par défaut, 172.16.0.0, puis vous demande si vous acceptez cette valeur par défaut.
Modifiez ou acceptez l'adresse IP de réseau privé.
Pour accepter l'adresse IP de réseau privé par défaut et continuer en modifiant la plage d'adresses IP, saisissez oui, puis appuyez sur la touche Retour.
L'utilitaire clsetup vous demande si vous souhaitez accepter le masque de réseau par défaut. Passez à l'étape suivante pour entrer votre réponse.
Pour modifier l'adresse IP de réseau privé par défaut, effectuez les sous-étapes suivantes.
Saisissez non en réponse à la question de l'utilitaire clsetup portant sur l'acceptation de l'adresse par défaut, puis appuyez sur la touche Retour.
L'utilitaire clsetup vous invite à saisir la nouvelle adresse IP de réseau privé.
Saisissez la nouvelle adresse IP, puis appuyez sur la touche Retour.
L'utilitaire clsetup affiche le masque de réseau par défaut, puis vous demande si vous acceptez le masque de réseau par défaut.
Modifiez ou acceptez la plage d'adresses IP de réseau privé par défaut.
Le masque de réseau par défaut est le 255.255.248.0. Cette plage d'adresses IP par défaut prend en charge un maximum de 64 nœuds et de 10 réseaux privés dans le cluster.
Pour accepter la plage d'adresses IP par défaut, saisissez oui, puis appuyez sur la touche Retour.
Passez ensuite à l'étape suivante.
Pour modifier la plage d'adresses IP, effectuez les sous-étapes suivantes.
Saisissez non en réponse à la question de l'utilitaire clsetup portant sur l'acceptation de la plage d'adresses par défaut, puis appuyez sur la touche Retour.
Lorsque vous refusez le masque de réseau par défaut, l'utilitaire clsetup vous invite à saisir le nombre de nœuds et de réseaux privés que vous prévoyez de configurer dans le cluster.
Saisissez le nombre de nœuds et de réseaux privés que vous prévoyez de configurer dans le cluster.
À partir de ces chiffres, l'utilitaire clsetup calcule deux masques de réseau proposés :
Le premier masque de réseau est le masque de réseau minimum pour assurer la prise en charge des nœuds et réseaux privés spécifiés.
Le second masque de réseau prend en charge deux fois plus de nœuds et de réseaux privés que ce que vous avez indiqué afin de permettre une éventuelle augmentation ultérieure.
Indiquez l'un des masques de réseau calculés ou indiquez un masque de réseau différent prenant en charge le nombre de nœuds et de réseaux privés souhaités.
Saisissez oui lorsque l'utilitaire clsetup vous demande de continuer avec la mise à jour.
Une fois l'opération terminée, quittez l'utilitaire clsetup.
Lorsque tous les nœuds sont mis à niveau, réinitialisez les nœuds mis à niveau.
Arrêtez tous les noeuds.
phys-schost# shutdown -g0 -y |
Initialisez chaque nœud en mode cluster.
Sur les systèmes SPARC, procédez comme suit :
ok boot |
Sur les systèmes x86, procédez comme suit :
Lorsque le menu GRUB s'affiche, sélectionnez l'entrée Solaris appropriée, puis appuyez sur Entrée. Le menu GRUB qui s'affiche est similaire à ce qui suit :
GNU GRUB version 0.95 (631K lower / 2095488K upper memory) +-------------------------------------------------------------------------+ | Solaris 10 /sol_10_x86 | | Solaris failsafe | | | +-------------------------------------------------------------------------+ Use the ^ and v keys to select which entry is highlighted. Press enter to boot the selected OS, 'e' to edit the commands before booting, or 'c' for a command-line. |
Pour plus d'informations sur l'initialisation GRUB, reportez-vous au Chapitre 11, GRUB Based Booting (Tasks) du System Administration Guide: Basic Administration.
Reportez-vous à la section Vérification de la mise à niveau de Sun Cluster 3.2.
Cette section fournit les informations suivantes pour mettre à niveau à partir de Sun Cluster 3.1 ; vers Sun Cluster 3.2 à l'aide de la méthode de mise à niveau à partition double :
Préparation du cluster pour la mise à niveau (partition double)
Mise à niveau du système d'exploitation Solaris et de Volume Manager Software (partition double)
Le tableau suivant répertorie les tâches à effectuer pour procéder à la mise à niveau depuis le logiciel Sun Cluster 3.1 vers le logiciel Sun Cluster 3.2. Vous pouvez également effectuer ces tâches pour mettre à niveau uniquement la version du SE Solaris. Si vous procédez à la mise à niveau du SE Solaris depuis Solaris 9 vers Solaris 10, vous devez également mettre à niveau le logiciel Sun Cluster et les logiciels de dépendance vers une version compatible avec la nouvelle version du SE Solaris.
Tableau 8–2 Liste des tâches : Exécution d'une mise à niveau à partition double vers Sun Cluster 3.2
Tâche |
Instructions |
---|---|
1. Lire les exigences et restrictions de la mise à niveau. Déterminer la méthode de mise à niveau appropriée pour votre configuration et vos besoins. | |
2. Partitionner le cluster en deux groupes de nœuds. |
Préparation du cluster pour la mise à niveau (partition double) |
3. Si nécessaire, mettre à niveau le logiciel Solaris vers une version de mise à jour Solaris prise en charge. Si le cluster utilise des médiateurs à deux chaînes pour Solaris Volume Manager, annuler leur configuration. Selon les besoins, mettre à niveau VERITAS Volume Manager (VxVM) et VERITAS File System (VxFS). Le logiciel Solaris Volume Manager est automatiquement mis à niveau avec le système d'exploitation Solaris. |
Mise à niveau du système d'exploitation Solaris et de Volume Manager Software (partition double) |
4. Mettre à niveau vers une structure Sun Cluster 3.2 et un logiciel de service de données. Si nécessaire, mettre à niveau des applications. Si le cluster utilise des médiateurs à deux chaînes et que vous mettez à niveau le système d'exploitation Solaris, reconfigurer les médiateurs. Si VxVM a été mis à niveau, mettre à niveau les groupes de disques. | |
5. Vérifier le bon déroulement de la mise à niveau vers Sun Cluster 3.2. | |
6. Activer les ressources et connecter leur groupe. (Facultatif) Migrer les ressources existantes vers de nouveaux types de ressources. | |
7. (Facultatif) SPARC : si nécessaire, mettre à niveau le module Sun Cluster pour Sun Management Center. |
SPARC : Mise à niveau du module Sun Cluster pour Sun Management Center |
Effectuez cette procédure pour préparer le cluster à une mise à niveau à partition double. Ces procédures font référence aux deux groupes de nœuds en tant que première partition et deuxième partition. Les nœuds affectés à la deuxième partition assurent la continuité des services du cluster pendant la mise à niveau des nœuds de la première partition. Lorsque tous les nœuds de la première partition sont mis à niveau, vous devez basculer les services du cluster vers la première partition et mettre à niveau la deuxième partition. Lorsque tous les nœuds de la deuxième partition sont mis à niveau, vous devez initialiser les nœuds en mode cluster pour rejoindre les nœuds de la première partition.
Si vous mettez à niveau un cluster mononœud, n'utilisez pas cette méthode de mise à niveau. Reportez-vous plutôt à la section Préparation du cluster pour la mise à niveau (standard) ou à la section Préparation du cluster pour la mise à niveau (en direct).
Sur Solaris 10, effectuez toutes les étapes à partir de la zone globale uniquement.
Effectuez les tâches suivantes :
Assurez-vous que la configuration respecte les conditions de mise à niveau. Reportez-vous à la rubrique Prise en charge liée à la mise à niveau.
Ayez à disposition les supports d'installation, la documentation et les patchs de tous les logiciels en cours de mise à niveau, notamment les logiciels suivants :
Les SE Solaris
Structure Sun Cluster 3.2
Services de données Sun Cluster 3.2 (agents)
Applications gérées par les services de données de Sun Cluster 3.2
VERITAS Volume Manager, le cas échéant
Pour connaître l'emplacement des patchs et les instructions d'installation, reportez-vous à la section Patchs et niveaux des micrologiciels requis du Notes de version de Sun Cluster 3.2 pour SE Solaris.
Si vous utilisez le contrôle d'accès basé sur les rôles (RBAC) au lieu du superutilisateur pour accéder aux nœuds du cluster, vérifiez que vous pouvez disposer d'un rôle RBAC fournissant une autorisation pour toutes les commandes Sun Cluster. Cette série de procédures de mise à niveau requiert les autorisations RBAC Sun Cluster suivantes si l'utilisateur n'est pas un superutilisateur :
solaris.cluster.modify
solaris.cluster.admin
solaris.cluster.read
Reportez-vous à la rubrique Role-Based Access Control (Overview) du System Administration Guide: Security Services pour plus d'informations sur l'utilisation des rôles RBAC. Reportez-vous aux pages de manuel Sun Cluster pour connaître l'autorisation RBAC nécessaire à chaque sous-commande Sun Cluster.
Vérifiez que le cluster fonctionne normalement.
Affichez le statut actuel du cluster en exécutant la commande suivante à partir de n'importe quel nœud.
% scstat |
Reportez-vous à la page de manuel scstat(1M) pour obtenir plus d'informations.
Recherchez le journal /var/adm/messages sur chaque noeud pour obtenir les erreurs non résolues et les messages d'avertissement.
Vérifiez l'état du gestionnaire de volumes.
Si nécessaire, informez les utilisateurs que les services du cluster seront temporairement interrompus pendant la mise à niveau.
L'interruption du service correspond approximativement au temps habituellement nécessaire pour que votre cluster bascule les services vers un autre nœud.
Devenez superutilisateur sur un noeud du cluster.
Pour un cluster à deux nœuds qui utilise le logiciel Sun StorEdge Availability Suite ou le logiciel Sun StorageTek Availability Suite, vérifiez que les données de configuration pour les services de disponibilité résident sur le disque de quorum.
Les données de configuration doivent résider sur le disque de quorum pour garantir le fonctionnement correct d'Availability Suite après la mise à niveau du logiciel de cluster.
Devenez superutilisateur d'un nœud de cluster qui exécute le logiciel Availability Suite.
Identifiez l'ID de périphérique et la tranche utilisés par le fichier de configuration de Availability Suite.
phys-schost# /usr/opt/SUNWscm/sbin/dscfg /dev/did/rdsk/dNsS |
Dans cet exemple, N correspond à l'ID du périphérique et T à la tranche du périphérique N.
Identifiez le périphérique de quorum existant.
phys-schost# scstat -q -- Quorum Votes by Device -- Device Name Present Possible Status ----------- ------- -------- ------ Device votes: /dev/did/rdsk/dQsS 1 1 Online |
Dans cet exemple, dQsS correspond au périphérique de quorum existant.
Si le périphérique de quorum n'est pas le périphérique de données de configuration de Availability Suite, déplacez les données de configuration vers une tranche disponible du périphérique de quorum.
phys-schost# dd if=`/usr/opt/SUNWesm/sbin/dscfg` of=/dev/did/rdsk/dQsS |
Vous devez utiliser le nom du périphérique DID en mode caractère, /dev/did/rdsk/, et non celui du périphérique DID en mode bloc, /dev/did/dsk/.
Si vous avez déplacé les données de configuration, configurez Availability Suite pour qu'il utilise le nouvel emplacement.
En tant que superutilisateur, exécutez la commande suivante sur chaque nœud exécutant le logiciel Availability Suite.
phys-schost# /usr/opt/SUNWesm/sbin/dscfg -s /dev/did/rdsk/dQsS |
Si vous prévoyez de mettre à niveau le SE Solaris et que votre cluster utilise des médiateurs à deux chaînes pour le logiciel Solaris Volume Manager, annulez la configuration de vos médiateurs.
Pour de plus amples informations sur les médiateurs, reportez-vous à la rubrique Configuration de médiateurs à deux chaînes.
Exécutez la commande suivante pour vérifier l'absence de problèmes de données du médiateur.
phys-schost# medstat -s setname |
Spécifie le nom du jeu de disques.
Si le champ Statut affiche la valeur Incorrect, réparez l'hôte médiateur affecté. Suivez la procédure de la rubrique Correction des données incorrectes du médiateur.
Répertoriez tous les médiateurs.
Enregistrez ces informations pour les cas où vous devez restaurer les médiateurs pendant la procédure de la section Finition de la mise à niveau vers Sun Cluster 3.2.
Lorsqu'un jeu de disques utilise des médiateurs, devenez propriétaire du jeu si aucun nœud n'en est propriétaire.
phys-schost# scswitch -z -D setname -h node |
Change de maître.
Indique le nom du jeu de disques.
Indique le nom du nœud que vous voulez convertir en nœud principal du jeu de disques.
Annulez la configuration de tous les médiateurs du jeu de disques.
phys-schost# metaset -s setname -d -m mediator-host-list |
Spécifie le nom du jeu de disques.
Supprime du jeu de disques.
Indique le nom du nœud à supprimer en tant qu'hôte médiateur du jeu de disques.
Reportez-vous à la page de manuel mediator(7D) afin d'obtenir plus d'informations sur les options spécifiques du médiateur pour la commande metaset.
Répétez de l'étape c à l'étape d pour chaque jeu de disques restant qui utilise des médiateurs.
Si vous exécutez le service de données Sun Cluster HA pour Sun Java System Application Server EE (HADB) avec le logiciel Sun Java System Application Server EE (HADB) version 4.4 ou ultérieure, désactivez la ressource HADB et arrêtez la base de données HADB.
Si vous exécutez une version de Sun Java System Application Server EE (HADB) antérieure à la 4.4, vous pouvez ignorer cette étape.
Lorsqu'une partition du cluster est hors service au cours de la mise à niveau, les nœuds de la partition active ne sont pas suffisants pour respecter les exigences d'appartenance HADB. Vous devez donc arrêter la base de données HADB et désactiver la ressource HADB avant de commencer la partition du cluster.
phys-schost# hadbm stop database-name phys-schost# scswitch -n -j hadb-resource |
Pour de plus amples informations, reportez-vous à la page de manuel hadbm(1m).
Si vous mettez à niveau un cluster à deux nœuds, passez à l'Étape 16.
Dans le cas contraire, passez à l'Étape 8 pour déterminer le schéma de partitionnement à utiliser. Vous devez déterminer les nœuds que chaque partition doit contenir, mais interrompre le processus de partitionnement. Ensuite, vous devez comparer les listes de nœuds de tous les groupes de ressources par rapport aux membres de nœuds de chaque partition du schéma utilisé. Si un groupe de ressources ne contient pas un membre de chaque partition, vous devez modifier la liste de nœuds.
Chargez le DVD-ROM Sun Java Availability Suite dans le lecteur DVD-ROM\~;.
Si le démon de gestion de volumes vold(1M) est en cours d'exécution et qu'il est configuré pour gérer les périphériques de CD-ROM ou de DVD, il monte automatiquement le support sur le répertoire /cdrom/cdrom0/.
Déplacez-vous sur le répertoire RépertoireSolaris_arch/Product/sun_cluster/Solaris_ver/Tools/ , où arch est sparc ou x86 (Solaris 10 uniquement) et où ver est 9 pour Solaris 9 ou 10 pour Solaris 10 .
phys-schost# cd /cdrom/cdrom0/Solaris_arch/Product/sun_cluster/Solaris_ver/Tools |
Lancez l'utilitaire scinstall en mode interactif.
phys-schost# ./scinstall |
n'utilisez pas la commande /usr/cluster/bin/scinstall déjà installée sur le noeud. Vous devez utiliser la commande scinstall sur le DVD-ROM Sun Java Availability Suite.
Le menu principal scinstall s'affiche.
Saisissez le numéro correspondant à l'option de gestion d'une mise à niveau à partition double, puis appuyez sur la touche Retour.
*** Main Menu *** Please select from one of the following (*) options: 1) Create a new cluster or add a cluster node 2) Configure a cluster to be JumpStarted from this install server * 3) Manage a dual-partition upgrade * 4) Upgrade this cluster node * 5) Print release information for this cluster node * ?) Help with menu options * q) Quit Option: 3 |
Le menu de gestion d'une mise à niveau à partition double s'affiche.
Saisissez le numéro correspondant à l'option d'affichage et de sélection des schémas de partitionnement possibles, puis appuyez sur la touche Retour.
Suivez les invites pour effectuer les tâches suivantes :
Affichez les schémas de partitionnement possibles pour votre cluster.
Choisissez un schéma de partitionnement.
Choisissez la partition à mettre à niveau en premier.
Arrêtez et ne répondez pas encore à l'invite qui s'affiche Voulez-vous commencer la mise à niveau à partition double ?, mais ne quittez pas l'utilitaire scinstall. Vous répondrez à cette invite à l'Étape 18 de cette procédure.
Souvenez-vous des nœuds appartenant à chaque partition dans le schéma de partitionnement.
Sur un autre nœud du cluster, devenez superutilisateur.
Assurez-vous que les services de données critiques peuvent basculer entre les partitions.
Pour un cluster à deux nœuds, chaque nœud est le seul de sa partition.
Lorsque les nœuds d'une partition sont arrêtés en préparation de la mise à niveau à partition double, les groupes de ressources hébergés sur ces nœuds basculent vers un nœud de l'autre partition. Si un groupe de ressources ne contient pas de nœud de chaque partition dans sa liste des nœuds, le groupe de ressources ne peut pas basculer. Pour être certain que le basculement de tous les services de données soit réussi, vérifiez que la liste des nœuds des groupes de ressources liés contient un membre de chaque partition de mise à niveau.
Affichez la liste des nœuds de chaque groupe de ressources devant rester en service au cours de l'intégralité de la mise à niveau.
phys-schost# scrgadm -pv -g resourcegroup | grep "Res Group Nodelist" |
Affiche les informations de configuration.
Affiche en mode détaillé.
Indique le nom du groupe de ressources.
Si la liste des nœuds d'un groupe de ressources ne contient pas au minimum un membre de chaque partition, redéfinissez la liste des nœuds pour inclure un membre de chaque partition en tant que nœud principal potentiel.
phys-schost# scrgadm -a -g resourcegroup -h nodelist |
Ajoute une nouvelle configuration.
Indique une liste des noms de nœuds séparés par des virgules.
Déterminez l'étape suivante.
Si vous mettez à niveau un cluster à deux nœuds, répétez de l'Étape 8 à l'Étape 13 pour désigner votre schéma de partitionnement et votre ordre de mise à niveau.
Lorsque vous atteignez l'invite Voulez-vous commencer la mise à niveau à partition double ?, passez à l'Étape 18.
Si vous mettez à niveau un cluster possédant trois nœuds ou plus, retournez au nœud exécutant l'utilitaire scinstall interactif.
Passez à l'Étape 18.
À l'invite Voulez-vous commencer la mise à niveau à partition double ? de l'utilitaire scinstall interactif, saisissez Yes.
La commande vérifie qu'une méthode d'installation à distance est disponible.
Lorsque vous y êtes invité, appuyez sur Entrée pour continuer chaque étape de la préparation pour la mise à niveau à partition double.
La commande bascule les groupes de ressources vers les nœuds de la deuxième partition, puis arrête chaque nœud de la première partition.
Lorsque tous les nœuds de la première partition sont arrêtés, initialisez chaque nœud de cette partition en mode non cluster.
Sur les systèmes SPARC, exécutez la commande suivante :
ok boot -x |
Sur les systèmes x86 exécutés sous Solaris 9, exécutez l'une des commandes suivantes :
phys-schost# reboot -- -xs or ... <<< Current Boot Parameters >>> Boot path: /pci@0,0/pci-ide@7,1/ata@1/cmdk@0,0:b Boot args: Type b [file-name] [boot-flags] <ENTER> to boot with options or i <ENTER> to enter boot interpreter or <ENTER> to boot with defaults <<< timeout in 5 seconds >>> Select (b)oot or (i)nterpreter: b -xs |
Sur les systèmes x86 exécutés sous Solaris 10, exécutez les commandes suivantes :
Dans le menu GRUB, utilisez les touches fléchées pour sélectionner l'entrée Solaris appropriée, puis saisissez e pour modifier ses commandes.
Le menu GRUB qui s'affiche est similaire à ce qui suit :
GNU GRUB version 0.95 (631K lower / 2095488K upper memory) +-------------------------------------------------------------------------+ | Solaris 10 /sol_10_x86 | | Solaris failsafe | | | +-------------------------------------------------------------------------+ Use the ^ and v keys to select which entry is highlighted. Press enter to boot the selected OS, 'e' to edit the commands before booting, or 'c' for a command-line. |
Pour plus d'informations sur l'initialisation GRUB, reportez-vous au Chapitre 11, GRUB Based Booting (Tasks) du System Administration Guide: Basic Administration.
Sur l'écran des paramètres d'initialisation, utilisez les touches fléchées pour sélectionner l'entrée kernel et saisissez e pour modifier l'entrée.
L'écran des paramètres d'initialisation GRUB qui s'affiche est similaire à ce qui suit :
GNU GRUB version 0.95 (615K lower / 2095552K upper memory) +----------------------------------------------------------------------+ | root (hd0,0,a) | | kernel /platform/i86pc/multiboot | | module /platform/i86pc/boot_archive | +----------------------------------------------------------------------+ Use the ^ and v keys to select which entry is highlighted. Press 'b' to boot, 'e' to edit the selected command in the boot sequence, 'c' for a command-line, 'o' to open a new line after ('O' for before) the selected line, 'd' to remove the selected line, or escape to go back to the main menu. |
Ajoutez -x à la commande pour spécifier l'initialisation du système en mode non cluster.
[ Minimal BASH-like line editing is supported. For the first word, TAB lists possible command completions. Anywhere else TAB lists the possible completions of a device/filename. ESC at any time exits. ] grub edit> kernel /platform/i86pc/multiboot -x |
Appuyez sur Entrée pour accepter la modification et retourner à l'écran des paramètres d'initialisation.
L'écran affiche la commande modifiée.
GNU GRUB version 0.95 (615K lower / 2095552K upper memory) +----------------------------------------------------------------------+ | root (hd0,0,a) | | kernel /platform/i86pc/multiboot -x | | module /platform/i86pc/boot_archive | +----------------------------------------------------------------------+ Use the ^ and v keys to select which entry is highlighted. Press 'b' to boot, 'e' to edit the selected command in the boot sequence, 'c' for a command-line, 'o' to open a new line after ('O' for before) the selected line, 'd' to remove the selected line, or escape to go back to the main menu.- |
Saisissez b pour initialiser le nœud en mode non cluster.
Cette modification apportée à la commande du paramètre d'initialisation du noyau n'est pas conservée après l'initialisation du système. La prochaine réinitialisation du nœud se fera donc en mode cluster. Pour effectuer un démarrage en mode non cluster, exécutez à nouveau ces étapes pour ajouter l'option -x à la commande du paramètre d'initialisation du noyau.
Si des applications exécutées dans la deuxième partition ne sont pas contrôlées par Gestionnaire du groupe de ressources (RGM), créez des scripts qui suspendent les applications avant de commencer la mise à niveau de ces nœuds.
Au cours de la mise à niveau à partition double, ces scripts sont appelés pour arrêter les applications telles que Oracle RAC avant que les nœuds de la deuxième partition ne soient suspendus.
Créez les scripts nécessaires pour arrêter les applications non contrôlées par RGM.
Créez des scripts séparés pour les applications qui doivent être arrêtées avant les applications contrôlées par RGM ainsi que pour les applications qui doivent être arrêtées par la suite.
Pour arrêter les applications exécutées sur plusieurs nœuds de la partition, écrivez les scripts en conséquence.
Utilisez un nom et un chemin de répertoire de votre choix pour vos scripts.
Assurez-vous que chaque nœud du cluster possède sa propre copie de vos scripts.
Sur chaque nœud, modifiez les scripts Sun Cluster suivants pour appeler les scripts placés sur ce nœud.
/etc/cluster/ql/cluster_pre_halt_apps : utilisez ce fichier pour appeler les scripts à exécuter avant que les applications contrôlées par RGM ne soient arrêtées.
/etc/cluster/ql/cluster_post_halt_apps : utilisez ce fichier pour appeler les scripts à exécuter après que les applications contrôlées par RGM sont arrêtées.
Les scripts Sun Cluster sont émis à partir d'un nœud arbitraire de la partition pendant le traitement suivant la mise à niveau de la partition. Pour cette raison, assurez-vous que les scripts d'un nœud de la partition effectuent les actions nécessaires pour tous les nœuds de la partition.
Mettez à niveau le logiciel sur chaque nœud de la première partition.
Pour mettre à niveau le logiciel Solaris avant d'effectuer une mise à niveau de Sun Cluster, reportez-vous à la section Mise à niveau du système d'exploitation Solaris et de Volume Manager Software (partition double).
Si le logiciel Sun Cluster 3.2 ne prend pas en charge la version du système d'exploitation Solaris exécutée sur le cluster, vous devez mettre le logiciel Solaris à niveau vers une version prise en charge. Pour de plus amples informations, reportez-vous à la rubrique « Produits pris en charge » des Notes de version de Sun Cluster 3.2 pour SE Solaris.
En revanche, si Sun Cluster 3.2 prend en charge la version de Solaris exécutée sur le cluster, il n'est pas nécessaire d'effectuer la mise à niveau de Solaris.
Dans le cas contraire, procédez à la mise à niveau vers Sun Cluster 3.2. Reportez-vous à la section Mise à niveau de Sun Cluster 3.2 (partition double).
Effectuez cette procédure sur chaque noeud du cluster pour mettre à niveau le système d'exploitation Solaris 10. Sur Solaris 10, effectuez toutes les étapes à partir de la zone globale uniquement.Si le cluster fonctionne déjà avec une version de Solaris prenant en charge Sun Cluster 3.2, il n'est pas nécessaire de mettre Solaris à niveau. Si vous ne prévoyez pas de mettre à niveau le système d'exploitation Solaris, reportez-vous à la rubrique Mise à niveau de Sun Cluster 3.2 (standard).
Le cluster doit déjà fonctionner avec, ou être mis à niveau vers, au moins le niveau minimum requis du système d'exploitation Solaris pour prendre en charge la mise à niveau vers Sun Cluster 3.2. Pour de plus amples informations, reportez-vous à la rubrique « Produits pris en charge » des Notes de version de Sun Cluster 3.2 pour SE Solaris.
Assurez-vous d'avoir suivi toutes les étapes de la rubrique Préparation du cluster pour la mise à niveau (standard).
Devenez superutilisateur du nœud de cluster à mettre à niveau.
Le nœud doit être un membre de la partition en mode non cluster.
Si le logiciel Sun Cluster Geographic Edition est installé, désinstallez-le.
Pour connaître les procédures de désinstallation, reportez-vous à la documentation correspondant à votre version de Sun Cluster Geographic Edition.
Déterminez si les scripts suivants de contrôle d'exécution Apache sont présents et activés :
/etc/rc0.d/K16apache /etc/rc1.d/K16apache /etc/rc2.d/K16apache /etc/rc3.d/S50apache /etc/rcS.d/K16apache |
Certaines applications, telles que Sun Cluster HA pour Apache, nécessitent la désactivation des scripts de contrôle d'exécution Apache.
Si ces scripts existent et contiennent un K ou un S en majuscule dans le nom de fichier, ils sont activés. Ils ne nécessitent aucune autre intervention.
Si ces scripts n'existent pas, vous devez vérifier à l'Étape 8 que ceux installés lors de la mise à niveau du système d'exploitation Solaris sont désactivés.
Si ces scripts existent et contiennent un k ou un s en minuscule, ils sont désactivés. À l'Étape 8, vous devez vous assurer de la désactivation des scripts de contrôle d'exécution Apache installés lors de la mise à niveau du système d'exploitation Solaris.
Commentez toutes les entrées des systèmes de fichiers montés globalement dans le fichier /etc/vfstab du nœud.
Notez toutes les entrées faisant déjà l'objet d'un commentaire afin de pouvoir vous y reporter ultérieurement.
Mettez en commentaire provisoirement toutes les entrées des systèmes de fichiers montés globalement dans le fichier /etc/vfstab.
Ces entrées contiennent l'option de montage global. En les mettant en commentaire, vous empêchez la mise à niveau de Solaris de monter les périphériques globaux.
Déterminez la procédure à suivre pour mettre à niveau le système d'exploitation Solaris.
Gestionnaire de volumes |
Procédure |
Emplacement des instructions |
---|---|---|
Solaris Volume Manager |
Toute méthode de mise à niveau de Solaris à l'exception de la méthode Live Upgrade. |
Documentation d'installation de Solaris |
VERITAS Volume Manager |
“Mise à niveau de VxVM et de Solaris” |
Documentation d'installation de VERITAS Volume Manager |
Si VxVM est installé sur votre cluster, vous devez réinstaller le logiciel VxVM existant ou effectuer une mise à niveau vers la version Solaris 9 ou 10 dans le cadre de la mise à niveau Solaris.
Mettez à niveau Solaris en suivant la procédure choisie à l'Étape 5.
Lorsque vous y êtes invité, choisissez l'option de réinitialisation manuelle.
Lorsque vous êtes invité à réinitialiser, réinitialisez toujours en mode non cluster.
Ne suivez pas l'instruction finale de réinitialisation lors de la mise à niveau de Solaris. Procédez donc comme suit :
Retournez à cette procédure pour effectuer l'Étape 7 et l'Étape 8.
Pour terminer la mise à niveau de Solaris, effectuez la réinitialisation en mode non cluster à l'Étape 9.
Exécutez les commandes suivantes pour initialiser un nœud en mode non cluster au cours d'une mise à niveau de Solaris :
Sur les systèmes SPARC, exécutez l'une des commandes suivantes :
phys-schost# reboot -- -xs or ok boot -xs |
Si vous êtes invité à exécuter init S, utilisez plutôt la commande reboot -- -xs.
Sur les systèmes x86, effectuez la commande suivante :
phys-schost# shutdown -g -y -i0 Press any key to continue |
Dans le menu GRUB, utilisez les touches fléchées pour sélectionner l'entrée Solaris appropriée, puis saisissez e pour modifier ses commandes.
Le menu GRUB qui s'affiche est similaire à ce qui suit :
GNU GRUB version 0.95 (631K lower / 2095488K upper memory) +-------------------------------------------------------------------------+ | Solaris 10 /sol_10_x86 | | Solaris failsafe | | | +-------------------------------------------------------------------------+ Use the ^ and v keys to select which entry is highlighted. Press enter to boot the selected OS, 'e' to edit the commands before booting, or 'c' for a command-line. |
Pour plus d'informations sur l'initialisation GRUB, reportez-vous au Chapitre 11, GRUB Based Booting (Tasks) du System Administration Guide: Basic Administration.
Sur l'écran des paramètres d'initialisation, utilisez les touches fléchées pour sélectionner l'entrée kernel et saisissez e pour modifier l'entrée.
L'écran des paramètres d'initialisation GRUB qui s'affiche est similaire à ce qui suit :
GNU GRUB version 0.95 (615K lower / 2095552K upper memory) +----------------------------------------------------------------------+ | root (hd0,0,a) | | kernel /platform/i86pc/multiboot | | module /platform/i86pc/boot_archive | +----------------------------------------------------------------------+ Use the ^ and v keys to select which entry is highlighted. Press 'b' to boot, 'e' to edit the selected command in the boot sequence, 'c' for a command-line, 'o' to open a new line after ('O' for before) the selected line, 'd' to remove the selected line, or escape to go back to the main menu. |
Ajoutez -x à la commande pour spécifier l'initialisation du système en mode non cluster.
[ Minimal BASH-like line editing is supported. For the first word, TAB lists possible command completions. Anywhere else TAB lists the possible completions of a device/filename. ESC at any time exits. ] grub edit> kernel /platform/i86pc/multiboot -x |
Appuyez sur Entrée pour accepter la modification et retourner à l'écran des paramètres d'initialisation.
L'écran affiche la commande modifiée.
GNU GRUB version 0.95 (615K lower / 2095552K upper memory) +----------------------------------------------------------------------+ | root (hd0,0,a) | | kernel /platform/i86pc/multiboot -x | | module /platform/i86pc/boot_archive | +----------------------------------------------------------------------+ Use the ^ and v keys to select which entry is highlighted. Press 'b' to boot, 'e' to edit the selected command in the boot sequence, 'c' for a command-line, 'o' to open a new line after ('O' for before) the selected line, 'd' to remove the selected line, or escape to go back to the main menu.- |
Saisissez b pour initialiser le nœud en mode non cluster.
Cette modification apportée à la commande du paramètre d'initialisation du noyau n'est pas conservée après l'initialisation du système. La prochaine réinitialisation du nœud se fera donc en mode cluster. Pour effectuer un démarrage en mode non cluster, exécutez à nouveau ces étapes pour ajouter l'option -x à la commande du paramètre d'initialisation du noyau.
Si l'instruction vous indique d'exécuter la commande init S, arrêtez le système, puis modifiez plutôt la commande d'initialisation de noyau GRUB sur /platform/i86pc/multiboot -sx.
Dans le fichier /a/etc/vfstab, retirez les commentaires de l' sur les entrées des systèmes de fichiers montés globalement.
Si les scripts de contrôle d'exécution Apache étaient désactivés ou absents avant la mise à niveau de Solaris, assurez-vous de la non-exécution de ceux installés lors de l'opération.
Pour désactiver les scripts de contrôle d'exécution Apache, utilisez les commandes suivantes pour renommer les fichiers avec un k ou un s minuscule.
phys-schost# mv /a/etc/rc0.d/K16apache /a/etc/rc0.d/k16apache phys-schost# mv /a/etc/rc1.d/K16apache /a/etc/rc1.d/k16apache phys-schost# mv /a/etc/rc2.d/K16apache /a/etc/rc2.d/k16apache phys-schost# mv /a/etc/rc3.d/S50apache /a/etc/rc3.d/s50apache phys-schost# mv /a/etc/rcS.d/K16apache /a/etc/rcS.d/k16apache |
Vous pouvez alternativement renommer les scripts conformément à vos pratiques administratives.
Réinitialisez le noeud en mode non cluster.
Sur les systèmes SPARC, exécutez la commande suivante.
Insérez un double tiret (--) dans la commande :
phys-schost# reboot -- -x |
Sur les systèmes x86, effectuez les procédures d'arrêt et d'initialisation décrites dans l'Étape 6, mais ajoutez -x à la commande d'initialisation du noyau au lieu de -sx.
Si votre cluster exécute VxVM, suivez les étapes restantes de la procédure « Mise à niveau de VxVM et du logiciel Solaris » pour réinstaller ou mettre à niveau VxVM.
Apportez les changements suivants à la procédure :
Une fois la mise à niveau de VxVM terminée, mais avant de procéder à la réinitialisation, vérifiez les entrées du fichier /etc/vfstab.
Si des commentaires d'entrée n'ont pas été retirés à l'Étape 7, réessayez.
Si VxVM vous invite à effectuer une reconfiguration finale après réinitialisation, n'utilisez pas l'option -r seule. Utilisez plutôt les options -rx pour effectuer une réinitialisation en mode non cluster.
Sur les systèmes SPARC, exécutez la commande suivante :
phys-schost# reboot -- -rx |
Sur les systèmes x86, effectuez les procédures d'arrêt et d'initialisation décrites dans l'Étape 6, mais ajoutez -rx à la commande d'initialisation du noyau au lieu de -sx.
Si un message similaire à celui-ci s'affiche, entrez le mot de passe racine pour continuer la mise à niveau. N'exécutez pas la commande fsck et n'appuyez pas sur Ctrl+D.
WARNING - Unable to repair the /global/.devices/node@1 filesystem. Run fsck manually (fsck -F ufs /dev/vx/rdsk/rootdisk_13vol). Exit the shell when done to continue the boot process. Type control-d to proceed with normal startup, (or give root password for system maintenance): Type the root password |
(Facultatif) SPARC : mettez à niveau VxFS.
Suivez les instructions des procédures fournies dans la documentation VxFS.
Installez tous les patchs du logiciel Solaris ainsi que les patchs matériels, puis téléchargez tous les microprogrammes des patchs matériels dont vous pourriez avoir besoin.
n'effectuez aucune réinitialisation après l'ajout des patchs. Attendez la fin de la mise à niveau du logiciel Sun Cluster pour réinitialiser le nœud.
Pour connaître l'emplacement des patchs et les instructions d'installation, reportez-vous à la section Patchs et niveaux des micrologiciels requis du Notes de version de Sun Cluster 3.2 pour SE Solaris.
Mise à niveau vers le logiciel Sun Cluster 3.2 Reportez-vous à la section Mise à niveau de Sun Cluster 3.2 (partition double).
Si vous procédez à la mise à niveau du système d'exploitation Solaris vers une nouvelle version marketing, par exemple à partir de Solaris 9 vers Solaris 10, vous devez également mettre à niveau le logiciel Sun Cluster et les logiciels de dépendance vers une version compatible avec la nouvelle version du système d'exploitation Solaris.
Effectuez cette procédure afin de mettre à niveau chacun des nœuds du cluster vers Sun Cluster 3.2. Cette procédure met également à niveau les composants Sun Java Enterprise System requis. Vous devez également effectuer cette procédure après avoir procédé à une mise à niveau vers une version marketing différente du système d'exploitation Solaris, notamment à partir de Solaris 9 vers Solaris 10.
Sur Solaris 10, effectuez toutes les étapes à partir de la zone globale uniquement.
Vous pouvez effectuer cette procédure sur plusieurs nœuds de la partition simultanément.
Effectuez les tâches suivantes :
Assurez-vous d'avoir suivi toutes les étapes de la rubrique Préparation du cluster pour la mise à niveau (partition double).
Assurez-vous que le nœud que vous mettez à niveau appartient à la partition qui n'est pas active dans le cluster et que le nœud est en mode non cluster.
Si vous avez mis à niveau vers une nouvelle version marketing du système d'exploitation Solaris, par exemple à partir de Solaris 9 vers Solaris 10, assurez-vous d'avoir suivi toutes les étapes de la section Mise à niveau du système d'exploitation Solaris et de Volume Manager Software (partition double).
Assurez-vous d'avoir installé tous les patchs requis du logiciel Solaris ainsi que les patchs matériels.
Devenez superutilisateur sur un nœud membre de la partition en mode non cluster.
Vérifiez que le répertoire /usr/java/ est un lien symbolique vers la version minimum ou la dernière version du logiciel Java.
Le logiciel Sun Cluster requiert au minimum la version 1.5.0_06 du logiciel Java. Si vous avez procédé à la mise à niveau vers une version de Solaris qui installe une version antérieure de Java, il se peut que la mise à niveau ait modifié le lien symbolique pour pointer vers une version de Java ne correspondant pas au minimum requis pour le logiciel Sun Cluster 3.2.
Identifiez le répertoire auquel /usr/java/ est associé par lien symbolique.
phys-schost# ls -l /usr/java lrwxrwxrwx 1 root other 9 Apr 19 14:05 /usr/java -> /usr/j2se/ |
Identifiez la ou les versions installées du logiciel Java.
L'exemple suivant présente les commandes que vous pouvez utiliser pour afficher les versions connexes du logiciel Java.
phys-schost# /usr/j2se/bin/java -version phys-schost# /usr/java1.2/bin/java -version phys-schost# /usr/jdk/jdk1.5.0_06/bin/java -version |
Si le répertoire /usr/java/ n'est pas associé par un lien symbolique à une version prise en charge du logiciel Java, recréez le lien symbolique.
L'exemple suivant présente la création d'un lien symbolique vers le répertoire /usr/j2se/ contenant le logiciel Java 1.5.0_06.
phys-schost# rm /usr/java phys-schost# ln -s /usr/j2se /usr/java |
Chargez le DVD-ROM Sun Java Availability Suite dans le lecteur DVD-ROM\~;.
Si le démon de gestion de volumes vold(1M) est en cours d'exécution et qu'il est configuré pour gérer les périphériques de CD-ROM ou de DVD, il monte automatiquement le support sur le répertoire /cdrom/cdrom0/.
Déplacez-vous sur le répertoire assistant d'installation du DVD-ROM\~;.
Si vous installez les packages du logiciel sur une plate-forme SPARC, exécutez la commande suivante :
phys-schost# cd /cdrom/cdrom0//Solaris_sparc |
Si vous installez les packages du logiciel sur une plate-forme x86, exécutez la commande suivante :
phys-schost# cd /cdrom/cdrom0//Solaris_x86 |
Démarrez le programme assistant d'installation.
phys-schost# ./installer |
Suivez les instructions qui apparaissent à l'écran pour sélectionner et mettre à niveau les packages des composants partagés sur le nœud.
N'utilisez pas l'assistant d'installation pour mettre à niveau les packages Sun Cluster.
Le programme assistant d'installation affiche l'état de l'installation. Une fois l'installation terminée, le programme affiche un récapitulatif et l'installation démarre.
Quittez le programme assistant d'installation.
Déplacez-vous sur le répertoire RépertoireSolaris_arch/Product/sun_cluster/Solaris_ver/Tools/ , où arch est sparc ou x86 (Solaris 10 uniquement) et où ver est 9 pour Solaris 9 ou 10 pour Solaris 10 .
phys-schost# cd /cdrom/cdrom0/Solaris_arch/Product/sun_cluster/Solaris_ver/Tools |
Lancer l'utilitaire scinstall.
phys-schost# ./scinstall |
n'utilisez pas la commande /usr/cluster/bin/scinstall déjà installée sur le noeud. Vous devez utiliser la commande scinstall située sur le DVD-ROM Sun Java Availability Suite.
Le menu principal scinstall s'affiche.
Saisissez le numéro correspondant à l'option de mise à niveau de ce nœud de cluster, puis appuyez sur la touche Retour.
*** Main Menu *** Please select from one of the following (*) options: * 1) Create a new cluster or add a cluster node 2) Configure a cluster to be JumpStarted from this install server * 3) Manage a dual-partition upgrade * 4) Upgrade this cluster node * 5) Print release information for this cluster node * ?) Help with menu options * q) Quit Option: 4 |
Le menu de mise à niveau s'affiche.
Saisissez le numéro correspondant à l'option de mise à niveau de la structure Sun Cluster sur ce nœud de cluster, puis appuyez sur la touche Retour.
Suivez les instructions pour mettre à niveau la structure du cluster.
Lors de la mise à niveau de Sun Cluster, scinstall risque d'apporter le(s) changement(s) de configuration suivant(s) :
Convertissez les groupes NAFO en groupes IPMP, mais conservez le nom du groupe NAFO de départ.
Reportez-vous à l'un des manuels suivants afin d'obtenir des informations sur les adresses de test pour IPMP :
Configuration des adresses de test de la rubrique Administering Multipathing Groups With Multiple Physical Interfaces du System Administration Guide: IP Services (Solaris 9)
Test Addresses du System Administration Guide: IP Services (Solaris 10)
Reportez-vous à la page de manuel scinstall(1M) pour obtenir plus d'informations sur la conversion de groupes NAFO en ensembles IPMP lors de la mise à niveau de Sun Cluster.
Renommez le fichier ntp.conf en ntp.conf.cluster, si ce dernier n'existe pas déjà.
Si nécessaire, définissez la variable local-mac-address? sur true.
La mise à niveau de la structure Sun Cluster est terminée lorsque le système affiche un message de confirmation et vous invite à appuyer sur la touche entrée.
Fermez l'utilitaire scinstall.
Retirez le DVD-ROM Sun Java Availability Suite du lecteur DVD-ROM\~;.
Mettez à niveau les packages de services de données.
Vous devez mettre à niveau tous les services de données vers la version 3.2 de Sun Cluster.
Pour Sun Cluster HA pour SAP Web Application Server, si vous utilisez une ressource de moteur J2EE ou une ressource de composant serveur d'application Web, ou les deux, vous devez supprimer la ressource et la recréer avec la nouvelle ressource de composant serveur d'application Web. Les modifications apportées à la nouvelle ressource de composant serveur d'application Web incluent l'intégration de la fonctionnalité J2EE. Pour plus d'informations, reportez-vous au manuel Sun Cluster Data Service for SAP Web Application Server Guide for Solaris OS.
Lancez l'utilitaire scinstall interactif mis à niveau.
phys-schost# /usr/cluster/bin/scinstall |
N'utilisez pas l'utilitaire scinstall se trouvant sur le support d'installation pour mettre à niveau les packages de services de données.
Le menu principal scinstall s'affiche.
Saisissez le numéro correspondant à l'option de mise à niveau de ce nœud de cluster, puis appuyez sur la touche Retour.
Le menu de mise à niveau s'affiche.
Saisissez le numéro correspondant à l'option de mise à niveau des agents de services de données Sun Cluster sur ce nœud, puis appuyez sur la touche Retour.
Suivez les instructions pour mettre à niveau les agents de services de données Sun Cluster installés sur le nœud.
Vous pouvez choisir de mettre à niveau tous les services de données installés ou une partie des éléments répertoriés.
La mise à niveau est terminée lorsque le système affiche un message de confirmation signalant que la mise à niveau des agents de services de données a été effectuée avec succès et vous invite à appuyer sur la touche Entrée pour continuer.
Appuyez sur Entr\'e9e.
Le menu de mise à niveau s'affiche.
Fermez l'utilitaire scinstall.
Si Sun Cluster HA pour NFS est configuré sur un système de fichiers local à haute disponibilité, assurez-vous que le système de fichiers loopback (LOFS) est désactivé.
Si des zones non globales sont configurées, le LOFS doit rester activé. Pour obtenir des directives sur l'utilisation du LOFS et les possibilités de le désactiver, reportez-vous à la section Systèmes de fichiers de grappe.
À partir de la version 3.2 de Sun Cluster, le LOFS n'est plus désactivé par défaut au cours de l'installation ou de la mise à niveau de Sun Cluster. Pour désactiver le LOFS, assurez-vous que le ficher /etc/system contient l'entrée suivante :
exclude:lofs |
Ce changement est pris en compte à la prochaine réinitialisation du système.
En fonction des besoins, mettez à niveau manuellement les services de données personnalisés non disponibles sur le support produit.
Vérifiez que chaque mise à jour des services de données est correctement installée.
Consultez le journal de la mise à niveau, référencé à la fin des messages émis en cours de mise à niveau.
Installez les patchs du logiciel de service de données et de l'architecture de Sun Cluster 3.2.
Pour connaître l'emplacement des patchs et les instructions d'installation, reportez-vous à la section Patchs et niveaux des micrologiciels requis du Notes de version de Sun Cluster 3.2 pour SE Solaris.
Mettez à niveau les applications du logiciel installées sur le cluster.
Assurez-vous que les niveaux des applications sont compatibles avec les versions actuelles de Sun Cluster et du logiciel Solaris. Reportez-vous à la documentation de l'application pour les instructions d'installation.
Lorsque tous les nœuds d'une partition sont mis à niveau, appliquez les changements de la mise à niveau.
À partir d'un nœud de la partition que vous mettez à niveau, lancez l'utilitaire scinstall interactif.
phys-schost# /usr/cluster/bin/scinstall |
N'utilisez pas la commande scinstall située sur le support d'installation. Utilisez uniquement la commande scinstall située sur le nœud du cluster.
Le menu principal scinstall s'affiche.
Saisissez le numéro correspondant à l'option d'application des changements de la mise à niveau à partition double à la partition, puis appuyez sur la touche Retour.
Suivez les invites pour continuer chaque étape du traitement de la mise à niveau.
La commande effectue les tâches suivantes, en fonction de la partition à partir de laquelle la commande est exécutée :
Première partition : la commande interrompt chaque nœud de la deuxième partition, un nœud à la fois. Lorsqu'un nœud est interrompu, les services de ce nœud sont automatiquement basculés vers un nœud de la première partition, à condition que la liste des nœuds du groupe de ressources lié contienne un nœud dans la première partition. Lorsque tous les nœuds de la deuxième partition sont interrompus, les nœuds de la première partition sont initialisés en mode cluster et reprennent les services du cluster.
Deuxième partition : la commande initialise les nœuds de la deuxième partition en mode cluster pour rejoindre le cluster actif formé par la première partition. Lorsque tous les nœuds ont rejoint le cluster, la commande effectue un traitement final et établit des rapports sur le statut de la mise à niveau.
Quittez l'utilitaire scinstall, s'il est toujours exécuté.
Si vous terminez la mise à niveau de la première partition, effectuez les sous-étapes suivantes afin de préparer la deuxième partition pour la mise à niveau.
Dans le cas contraire, si vous terminez la mise à niveau de la deuxième partition, passez à la rubrique Vérification de la mise à niveau de Sun Cluster 3.2.
Initialisez chaque nœud de la deuxième partition en mode non cluster.
Sur les systèmes SPARC, exécutez la commande suivante :
ok boot -x |
Sur les systèmes x86, exécutez les commandes suivantes :
Dans le menu GRUB, utilisez les touches fléchées pour sélectionner l'entrée Solaris appropriée, puis saisissez e pour modifier ses commandes.
Le menu GRUB qui s'affiche est similaire à ce qui suit :
GNU GRUB version 0.95 (631K lower / 2095488K upper memory) +-------------------------------------------------------------------------+ | Solaris 10 /sol_10_x86 | | Solaris failsafe | | | +-------------------------------------------------------------------------+ Use the ^ and v keys to select which entry is highlighted. Press enter to boot the selected OS, 'e' to edit the commands before booting, or 'c' for a command-line. |
Pour plus d'informations sur l'initialisation GRUB, reportez-vous au Chapitre 11, GRUB Based Booting (Tasks) du System Administration Guide: Basic Administration.
Sur l'écran des paramètres d'initialisation, utilisez les touches fléchées pour sélectionner l'entrée kernel et saisissez e pour modifier l'entrée.
L'écran des paramètres d'initialisation GRUB qui s'affiche est similaire à ce qui suit :
GNU GRUB version 0.95 (615K lower / 2095552K upper memory) +----------------------------------------------------------------------+ | root (hd0,0,a) | | kernel /platform/i86pc/multiboot | | module /platform/i86pc/boot_archive | +----------------------------------------------------------------------+ Use the ^ and v keys to select which entry is highlighted. Press 'b' to boot, 'e' to edit the selected command in the boot sequence, 'c' for a command-line, 'o' to open a new line after ('O' for before) the selected line, 'd' to remove the selected line, or escape to go back to the main menu. |
Ajoutez -x à la commande pour spécifier l'initialisation du système en mode non cluster.
[ Minimal BASH-like line editing is supported. For the first word, TAB lists possible command completions. Anywhere else TAB lists the possible completions of a device/filename. ESC at any time exits. ] grub edit> kernel /platform/i86pc/multiboot -x |
Appuyez sur Entrée pour accepter la modification et retourner à l'écran des paramètres d'initialisation.
L'écran affiche la commande modifiée.
GNU GRUB version 0.95 (615K lower / 2095552K upper memory) +----------------------------------------------------------------------+ | root (hd0,0,a) | | kernel /platform/i86pc/multiboot -x | | module /platform/i86pc/boot_archive | +----------------------------------------------------------------------+ Use the ^ and v keys to select which entry is highlighted. Press 'b' to boot, 'e' to edit the selected command in the boot sequence, 'c' for a command-line, 'o' to open a new line after ('O' for before) the selected line, 'd' to remove the selected line, or escape to go back to the main menu.- |
Saisissez b pour initialiser le nœud en mode non cluster.
Cette modification apportée à la commande du paramètre d'initialisation du noyau n'est pas conservée après l'initialisation du système. La prochaine réinitialisation du nœud se fera donc en mode cluster. Pour effectuer un démarrage en mode non-cluster, exécutez à nouveau ces étapes pour ajouter l'option -x à la commande du paramètre d'initialisation du noyau.
Mettez à niveau les nœuds de la deuxième partition.
Pour mettre à niveau le logiciel Solaris avant d'effectuer une mise à niveau de Sun Cluster, reportez-vous à la section Mise à niveau du système d'exploitation Solaris et de Volume Manager Software (partition double).
Dans le cas contraire, mettez à niveau Sun Cluster dans la deuxième partition. Retournez à l'Étape 1.
Reportez-vous à la section Vérification de la mise à niveau de Sun Cluster 3.2.
Si vous rencontrez une erreur irrécupérable au cours de la mise à niveau à partition double, effectuez les procédures de récupération de la rubrique Récupération suite à l'échec d'une mise à niveau à partition double.
Cette section fournit les informations suivantes pour mettre à niveau à partir de Sun Cluster 3.1 ; vers Sun Cluster 3.2 à l'aide de la méthode de mise à niveau en direct :
Le tableau suivant répertorie les tâches à effectuer pour procéder à la mise à niveau depuis le logiciel Sun Cluster 3.1 vers le logiciel Sun Cluster 3.2. Vous pouvez également effectuer ces tâches pour mettre à niveau uniquement la version du SE Solaris. Si vous procédez à la mise à niveau du SE Solaris depuis Solaris 9 vers Solaris 10, vous devez également mettre à niveau le logiciel Sun Cluster et les logiciels de dépendance vers une version compatible avec la nouvelle version du SE Solaris.
Tableau 8–3 Liste des tâches : Exécution d'une mise à niveau en direct vers Sun Cluster 3.2
Tâche |
Instructions |
---|---|
1. Lire les exigences et restrictions de la mise à niveau. Déterminer la méthode de mise à niveau appropriée pour votre configuration et vos besoins. | |
2. Mettre le cluster hors service, désactiver les ressources et sauvegarder les données partagées et le contenu des disques système. Si le cluster utilise des médiateurs à deux chaînes pour Solaris Volume Manager, annuler leur configuration. | |
3. Si nécessaire, mettre à niveau le logiciel Solaris vers une version de mise à jour Solaris prise en charge. Mettre à niveau vers une structure Sun Cluster 3.2 et un logiciel de service de données. Si nécessaire, mettre à niveau des applications. Si le cluster utilise des médiateurs à deux chaînes, les reconfigurer. Selon vos besoins, mettez à niveau le logiciel et les groupes de disques VERITAS Volume Manager (VxVM) ainsi que VERITAS File System (VxFS). | |
4. Vérifier le bon déroulement de la mise à niveau vers Sun Cluster 3.2. | |
5. Activer les ressources et mettre les groupes de ressources en ligne. Migrer les ressources existantes vers de nouveaux types de ressources. | |
6. (Facultatif) SPARC : mettre à niveau le module Sun Cluster pour Sun Management Center, si nécessaire. |
SPARC : Mise à niveau du module Sun Cluster pour Sun Management Center |
Effectuez cette procédure pour préparer un cluster à une mise à niveau en direct.
Effectuez les tâches suivantes :
Assurez-vous que la configuration respecte les conditions de mise à niveau. Reportez-vous à la rubrique Prise en charge liée à la mise à niveau.
Ayez à disposition les supports d'installation, la documentation et les patchs de tous les logiciels en cours de mise à niveau, notamment les logiciels suivants :
Les SE Solaris
Structure Sun Cluster 3.2
Services de données Sun Cluster 3.2 (agents)
Applications gérées par les services de données de Sun Cluster 3.2
VERITAS Volume Manager, le cas échéant
Pour connaître l'emplacement des patchs et les instructions d'installation, reportez-vous à la section Patchs et niveaux des micrologiciels requis du Notes de version de Sun Cluster 3.2 pour SE Solaris.
Si vous utilisez le contrôle d'accès basé sur les rôles (RBAC) au lieu du superutilisateur pour accéder aux nœuds du cluster, vérifiez que vous pouvez disposer d'un rôle RBAC fournissant une autorisation pour toutes les commandes Sun Cluster. Cette série de procédures de mise à niveau requiert les autorisations RBAC Sun Cluster suivantes si l'utilisateur n'est pas un superutilisateur :
solaris.cluster.modify
solaris.cluster.admin
solaris.cluster.read
Reportez-vous à la rubrique Role-Based Access Control (Overview) du System Administration Guide: Security Services pour plus d'informations sur l'utilisation des rôles RBAC. Reportez-vous aux pages de manuel Sun Cluster pour connaître l'autorisation RBAC nécessaire à chaque sous-commande Sun Cluster.
Vérifiez que le cluster fonctionne normalement.
Affichez le statut actuel du cluster en exécutant la commande suivante à partir de n'importe quel nœud.
phys-schost% scstat |
Reportez-vous à la page de manuel scstat(1M) pour obtenir plus d'informations.
Recherchez le journal /var/adm/messages sur chaque noeud pour obtenir les erreurs non résolues et les messages d'avertissement.
Vérifiez l'état du gestionnaire de volumes.
Si nécessaire, informez les utilisateurs que les services du cluster sont susceptibles d'être temporairement interrompus pendant la mise à niveau.
L'interruption du service correspond approximativement au temps habituellement nécessaire pour que votre cluster bascule les services vers un autre nœud.
Devenez superutilisateur sur un noeud du cluster.
Si le logiciel Sun Cluster Geographic Edition est installé, désinstallez-le.
Pour connaître les procédures de désinstallation, reportez-vous à la documentation correspondant à votre version de Sun Cluster Geographic Edition.
Pour un cluster à deux nœuds qui utilise le logiciel Sun StorEdge Availability Suite ou le logiciel Sun StorageTek Availability Suite, vérifiez que les données de configuration pour les services de disponibilité résident sur le disque de quorum.
Les données de configuration doivent résider sur le disque de quorum pour garantir le fonctionnement correct d'Availability Suite après la mise à niveau du logiciel de cluster.
Devenez superutilisateur d'un nœud de cluster qui exécute le logiciel Availability Suite.
Identifiez l'ID de périphérique et la tranche utilisés par le fichier de configuration de Availability Suite.
phys-schost# /usr/opt/SUNWscm/sbin/dscfg /dev/did/rdsk/dNsS |
Dans cet exemple, N correspond à l'ID du périphérique et T à la tranche du périphérique N.
Identifiez le périphérique de quorum existant.
phys-schost# scstat -q -- Quorum Votes by Device -- Device Name Present Possible Status ----------- ------- -------- ------ Device votes: /dev/did/rdsk/dQsS 1 1 Online |
Dans cet exemple, dQsS correspond au périphérique de quorum existant.
Si le périphérique de quorum n'est pas le périphérique de données de configuration de Availability Suite, déplacez les données de configuration vers une tranche disponible du périphérique de quorum.
phys-schost# dd if=`/usr/opt/SUNWesm/sbin/dscfg` of=/dev/did/rdsk/dQsS |
Vous devez utiliser le nom du périphérique DID en mode caractère, /dev/did/rdsk/, et non celui du périphérique DID en mode bloc, /dev/did/dsk/.
Si vous avez déplacé les données de configuration, configurez Availability Suite pour qu'il utilise le nouvel emplacement.
En tant que superutilisateur, exécutez la commande suivante sur chaque nœud exécutant le logiciel Availability Suite.
phys-schost# /usr/opt/SUNWesm/sbin/dscfg -s /dev/did/rdsk/dQsS |
Assurez-vous que toutes les données partagées sont sauvegardées.
Assurez-vous que chaque disque système est sauvegardé.
Effectuez une mise à niveau en direct du système d'exploitation Solaris, de Sun Cluster 3.2 et d'autres logiciels. Reportez-vous à la section Mise à niveau du système d'exploitation Solaris et du logiciel Sun Cluster 3.2 (mise à niveau en direct).
Effectuez cette procédure pour mettre à niveau le système d'exploitation Solaris, les composants partagés Java ES, le logiciel de gestionnaire de volumes et le logiciel Sun Cluster à l'aide de la méthode de mise à niveau en direct. La méthode de mise à niveau en direct de Sun Cluster utilise la fonction Solaris Live Upgrade. Pour obtenir des informations sur la mise à niveau en direct du système d'exploitation Solaris, reportez-vous à la documentation de la version Solaris que vous utilisez :
Chapitre 32, Solaris Live Upgrade (Topics) du Solaris 9 9/04 Installation Guide
Guide d’installation de Solaris 10 : Solaris Live Upgrade et planification de la mise à niveau
Le cluster doit déjà fonctionner avec, ou être mis à niveau vers, au moins le niveau minimum requis du système d'exploitation Solaris pour prendre en charge la mise à niveau vers Sun Cluster 3.2. Pour de plus amples informations, reportez-vous à la rubrique « Produits pris en charge » des Notes de version de Sun Cluster 3.2 pour SE Solaris.
Suivez cette procédure sur chaque noeud du cluster.
Vous pouvez utiliser l'utilitaire cconsole pour effectuer cette procédure sur tous les nœuds simultanément. Pour de plus amples informations, reportez-vous à la section Procédure d'installation du logiciel Cluster Control Panel sur une console administrative.
Assurez-vous d'avoir suivi toutes les étapes de la rubrique Préparation du cluster pour la mise à niveau (en direct).
Assurez-vous qu'une version prise en charge du logiciel Solaris Live Upgrade est installée sur chaque nœud.
Si votre système d'exploitation est déjà mis à niveau vers Logiciel Solaris 9 9/05 ou Solaris 10 11/06, vous disposez de la version correcte de Solaris Live Upgrade. Si votre système d'exploitation est une version antérieure, effectuez les étapes suivantes :
Insérez le support Logiciel Solaris 9 9/05 ou Solaris 10 11/06.
Prenez le rôle de superutilisateur.
Installez les packages SUNWluu et SUNWlur.
phys-schost# pkgadd -d path SUNWluu SUNWlur |
Spécifie le chemin absolu vers les packages.
Vérifiez que les packages ont été installés.
phys-schost# pkgchk -v SUNWluu SUNWlur |
Si vous prévoyez de mettre à niveau le SE Solaris et que votre cluster utilise des médiateurs à deux chaînes pour le logiciel Solaris Volume Manager, annulez la configuration de vos médiateurs.
Pour de plus amples informations sur les médiateurs, reportez-vous à la rubrique Configuration de médiateurs à deux chaînes.
Exécutez la commande suivante pour vérifier l'absence de problèmes de données du médiateur.
phys-schost# medstat -s setname |
Spécifie le nom du jeu de disques.
Si le champ Statut affiche la valeur Incorrect, réparez l'hôte médiateur affecté. Suivez la procédure de la rubrique Correction des données incorrectes du médiateur.
Répertoriez tous les médiateurs.
Enregistrez ces informations pour les cas où vous devez restaurer les médiateurs pendant la procédure de la section Finition de la mise à niveau vers Sun Cluster 3.2.
Lorsqu'un jeu de disques utilise des médiateurs, devenez propriétaire du jeu si aucun nœud n'en est propriétaire.
phys-schost# scswitch -z -D setname -h node |
Change de maître.
Indique le nom du jeu de disques.
Indique le nom du nœud que vous voulez convertir en nœud principal du jeu de disques.
Annulez la configuration de tous les médiateurs du jeu de disques.
phys-schost# metaset -s setname -d -m mediator-host-list |
Spécifie le nom du jeu de disques.
Supprime du jeu de disques.
Indique le nom du nœud à supprimer en tant qu'hôte médiateur du jeu de disques.
Reportez-vous à la page de manuel mediator(7D) afin d'obtenir plus d'informations sur les options spécifiques du médiateur pour la commande metaset.
Répétez de l'étape c à l'étape d pour chaque jeu de disques restant qui utilise des médiateurs.
Créez un environnement d'initialisation (EI) inactif.
phys-schost# lucreate options-n BE-name |
Indique le nom de l'environnement d'initialisation que vous souhaitez mettre à niveau.
Pour de plus amples informations sur les options importantes de la commande lucreate, reportez-vous au Guide d’installation de Solaris 10 : Solaris Live Upgrade et planification de la mise à niveau et à la page de manuel lucreate(1M).
Le cas échéant, mettez à niveau le système d'exploitation Solaris de votre EI inactif.
Si le cluster s'exécute déjà sur une version possédant les patchs requis du système d'exploitation Solaris prenant en charge Sun Cluster 3.2, cette étape est facultative.
Si vous utilisez le logiciel Solaris Volume Manager, exécutez la commande suivante :
phys-schost# luupgrade -u -n BE-name -s os-image-path |
Met à niveau une image de système d'exploitation sur un environnement d'initialisation.
Indique le chemin d'accès au répertoire comportant une image du système d'exploitation.
Si vous utilisez VERITAS Volume Manager, suivez les procédures de mise à niveau en direct de la documentation d'installation de VxVM.
Montez votre EI inactif à l'aide de la commande lumount.
phys-schost# lumount -n BE-name -m BE-mount-point |
Indique le point de montage de BE-name.
Pour de plus amples informations, reportez-vous au Guide d’installation de Solaris 10 : Solaris Live Upgrade et planification de la mise à niveau et à la page de manuel lumount(1M).
Assurez-vous que le répertoire /BE-mount-point/usr/java/ est un lien symbolique vers la version minimale ou la version la plus à jour du logiciel Java.
Le logiciel Sun Cluster requiert au minimum la version 1.5.0_06 du logiciel Java. Si vous avez procédé à la mise à niveau vers une version de Solaris qui installe une version antérieure de Java, il se peut que la mise à niveau ait modifié le lien symbolique pour pointer vers une version de Java ne correspondant pas au minimum requis pour le logiciel Sun Cluster 3.2.
Déterminez le répertoire vers lequel le répertoire /BE-mount-point/usr/java/ est symboliquement lié.
phys-schost# ls -l /BE-mount-point/usr/java lrwxrwxrwx 1 root other 9 Apr 19 14:05 /BE-mount-point/usr/java -> /BE-mount-point/usr/j2se/ |
Identifiez la ou les versions installées du logiciel Java.
L'exemple suivant présente les commandes que vous pouvez utiliser pour afficher les versions connexes du logiciel Java.
phys-schost# /BE-mount-point/usr/j2se/bin/java -version phys-schost# /BE-mount-point/usr/java1.2/bin/java -version phys-schost# /BE-mount-point/usr/jdk/jdk1.5.0_06/bin/java -version |
Si le répertoire /BE-mount-point/usr/java/ n'est pas symboliquement lié à une version prise en charge du logiciel Java, recréez le lien symbolique vers une version prise en charge de Java.
L'exemple suivant présente la création d'un lien symbolique vers le répertoire /usr/j2se/ contenant le logiciel Java 1.5.0_06.
phys-schost# rm /BE-mount-point/usr/java phys-schost# cd /mnt/usr phys-schost# ln -s j2se java |
Appliquez les patchs Solaris nécessaires.
Il se peut que vous deviez appliquer un patch à votre logiciel Solaris pour utiliser la fonctionnalité Live Upgrade. Pour obtenir des détails sur les patchs requis par le système d'exploitation Solaris et l'endroit où les télécharger, reportez-vous à la rubrique Managing Packages and Patches With Solaris Live Upgrade du Solaris 9 9/04 Installation Guide ou à la rubrique Mise à niveau d’un système à l’aide de packages ou de patchs du Guide d’installation de Solaris 10 : Solaris Live Upgrade et planification de la mise à niveau.
Si nécessaire, et si votre version de VERITAS Volume Manager (VxVM) le prend en charge, mettez à niveau votre logiciel VxVM.
Reportez-vous à la documentation de votre logiciel VxVM pour déterminer si votre version de VxVM peut utiliser la méthode de mise à niveau en direct.
(Facultatif) SPARC : mettez à niveau VxFS.
Suivez les instructions des procédures fournies dans la documentation VxFS.
Si votre cluster héberge des applications logicielles qui requièrent une mise à niveau et que vous pouvez procéder à une mise à niveau à l'aide de la méthode de mise à niveau en direct, mettez à niveau ces applications logicielles.
Si votre cluster héberge des applications logicielles qui ne peuvent pas utiliser la méthode de mise à niveau en direct, vous pourrez les mettre à niveau ultérieurement dans l'Étape 25.
Chargez le DVD-ROM Sun Java Availability Suite dans le lecteur DVD-ROM\~;.
Si le démon de gestion de volumes vold(1M) est en cours d'exécution et qu'il est configuré pour gérer les périphériques de CD-ROM ou de DVD, il monte automatiquement le support sur le répertoire /cdrom/cdrom0/.
Déplacez-vous sur le répertoire assistant d'installation du DVD-ROM\~;.
Si vous installez les packages du logiciel sur une plate-forme SPARC, exécutez la commande suivante :
phys-schost# cd /cdrom/cdrom0/Solaris_sparc |
Si vous installez les packages du logiciel sur une plate-forme x86, exécutez la commande suivante :
phys-schost# cd /cdrom/cdrom0/Solaris_x86 |
Lancez le programme assistant d'installation pour diriger la sortie vers un fichier d'état.
Indiquez le nom à attribuer au fichier d'état ainsi que le chemin absolu ou relatif où le fichier doit être créé.
Pour créer un fichier d'état à l'aide de l'interface graphique, utilisez la commande suivante :
phys-schost# ./installer -no -saveState statefile |
Pour créer un fichier d'état à l'aide de l'interface texte, utilisez la commande suivante :
phys-schost# ./installer -no -nodisplay -saveState statefile |
Pour de plus amples informations, reportez-vous à la rubrique Generating the Initial State File du Sun Java Enterprise System 5 Installation Guide for UNIX.
Suivez les instructions qui apparaissent à l'écran pour sélectionner et mettre à niveau les packages des composants partagés sur le nœud.
Le programme assistant d'installation affiche l'état de l'installation. Une fois l'installation terminée, le programme affiche un récapitulatif et l'installation démarre.
Quittez le programme assistant d'installation.
Exécutez le programme installer en mode Silencieux et dirigez l'installation vers l'environnement d'initialisation secondaire.
Le programme installer doit être de la même version que celle utilisée pour créer le fichier d'état.
phys-schost# ./installer -nodisplay -noconsole -state statefile -altroot BE-mount-point |
Pour de plus amples informations, reportez-vous à la rubrique To Run the Installer in Silent Mode du Sun Java Enterprise System 5 Installation Guide for UNIX.
Déplacez-vous sur le répertoire RépertoireSolaris_arch/Product/sun_cluster/Solaris_ver/Tools/ , où arch est sparc ou x86 (Solaris 10 uniquement) et où ver est 9 pour Solaris 9 ou 10 pour Solaris 10 .
phys-schost# cd /cdrom/cdrom0/Solaris_arch/Product/sun_cluster/Solaris_ver/Tools |
Procédez à la mise à niveau de votre logiciel Sun Cluster à l'aide de la commande scinstall.
phys-schost# ./scinstall -u update -R BE-mount-point |
Indique que vous procédez à une mise à niveau du logiciel Sun Cluster.
Indique le point de montage pour votre environnement d'initialisation secondaire.
Pour de plus amples informations, reportez-vous à la page du manuel scinstall(1M).
Procédez à la mise à niveau de vos services de données à l'aide de la commande scinstall.
phys-schost# BE-mount-point/usr/cluster/bin/scinstall -u update -s all \ -d /cdrom/cdrom0/Solaris_arch/Product/sun_cluster_agents -R BE-mount-point |
Retirez le DVD-ROM Sun Java Availability Suite du lecteur DVD-ROM\~;.
Annulez le montage de l'EI inactif.
phys-schost# luumount -n BE-name |
Activez l'EI inactif mis à niveau.
phys-schost# luactivate BE-name |
Nom de l'EI secondaire créé à l'Étape 3.
Répétez de l'Étape 1 à l'Étape 22 pour chaque nœud du cluster.
Ne réinitialisez aucun nœud tant que tous les nœuds du cluster n'ont pas été mis à niveau sur leur EI inactif.
Redémarrer tous les noeuds.
phys-schost# shutdown -y -g0 -i6 |
N'utilisez pas la commande reboot, ni la commande halt. Ces commandes n'activent pas un nouvel EI. Utilisez uniquement shutdown ou init pour réinitialiser dans un nouvel EI.
Les nœuds se réinitialisent en mode cluster à l'aide du nouvel EI mis à niveau.
(Facultatif) Si votre cluster héberge des applications logicielles qui requièrent une mise à niveau pour laquelle vous ne pouvez pas utiliser la méthode de mise à niveau en direct, effectuez les étapes suivantes.
Tout au long du processus de mise à niveau de l'application, réinitialisez toujours en mode non cluster jusqu'à ce que toutes les mises à niveau soient terminées.
Arrêtez le nœud.
phys-schost# shutdown -y -g0 -i0 |
Réinitialisez chaque noeud en mode non cluster.
Sur les systèmes SPARC, exécutez la commande suivante :
ok boot -x |
Sur les systèmes x86, exécutez les commandes suivantes :
Dans le menu GRUB, utilisez les touches fléchées pour sélectionner l'entrée Solaris appropriée, puis saisissez e pour modifier ses commandes.
Le menu GRUB qui s'affiche est similaire à ce qui suit :
GNU GRUB version 0.95 (631K lower / 2095488K upper memory) +-------------------------------------------------------------------------+ | Solaris 10 /sol_10_x86 | | Solaris failsafe | | | +-------------------------------------------------------------------------+ Use the ^ and v keys to select which entry is highlighted. Press enter to boot the selected OS, 'e' to edit the commands before booting, or 'c' for a command-line. |
Pour plus d'informations sur l'initialisation GRUB, reportez-vous au Chapitre 11, GRUB Based Booting (Tasks) du System Administration Guide: Basic Administration.
Sur l'écran des paramètres d'initialisation, utilisez les touches fléchées pour sélectionner l'entrée kernel et saisissez e pour modifier l'entrée.
L'écran des paramètres d'initialisation GRUB qui s'affiche est similaire à ce qui suit :
GNU GRUB version 0.95 (615K lower / 2095552K upper memory) +----------------------------------------------------------------------+ | root (hd0,0,a) | | kernel /platform/i86pc/multiboot | | module /platform/i86pc/boot_archive | +----------------------------------------------------------------------+ Use the ^ and v keys to select which entry is highlighted. Press 'b' to boot, 'e' to edit the selected command in the boot sequence, 'c' for a command-line, 'o' to open a new line after ('O' for before) the selected line, 'd' to remove the selected line, or escape to go back to the main menu. |
Ajoutez -x à la commande pour spécifier l'initialisation du système en mode non cluster.
[ Minimal BASH-like line editing is supported. For the first word, TAB lists possible command completions. Anywhere else TAB lists the possible completions of a device/filename. ESC at any time exits. ] grub edit> kernel /platform/i86pc/multiboot -x |
Appuyez sur Entrée pour accepter la modification et retourner à l'écran des paramètres d'initialisation.
L'écran affiche la commande modifiée.
GNU GRUB version 0.95 (615K lower / 2095552K upper memory) +----------------------------------------------------------------------+ | root (hd0,0,a) | | kernel /platform/i86pc/multiboot -x | | module /platform/i86pc/boot_archive | +----------------------------------------------------------------------+ Use the ^ and v keys to select which entry is highlighted. Press 'b' to boot, 'e' to edit the selected command in the boot sequence, 'c' for a command-line, 'o' to open a new line after ('O' for before) the selected line, 'd' to remove the selected line, or escape to go back to the main menu.- |
Saisissez b pour initialiser le nœud en mode non cluster.
Cette modification apportée à la commande du paramètre d'initialisation du noyau n'est pas conservée après l'initialisation du système. La prochaine réinitialisation du nœud se fera donc en mode cluster. Pour effectuer un démarrage en mode non cluster, exécutez à nouveau ces étapes pour ajouter l'option -x à la commande du paramètre d'initialisation du noyau.
Si l'instruction vous indique d'exécuter la commande init S, arrêtez le système, puis modifiez plutôt la commande d'initialisation de noyau GRUB sur /platform/i86pc/multiboot -sx.
Mettez à niveau chaque application logicielle qui requiert une mise à niveau.
Pensez à initialiser en mode non cluster s'il vous est demandé de réinitialiser, et ce jusqu'à ce que toutes les applications aient été mises à niveau.
Initialisez chaque nœud en mode cluster.
Sur les systèmes SPARC, exécutez la commande suivante :
ok boot |
Sur les systèmes x86, exécutez les commandes suivantes :
Lorsque le menu GRUB s'affiche, sélectionnez l'entrée Solaris appropriée, puis appuyez sur Entrée. Le menu GRUB qui s'affiche est similaire à ce qui suit :
GNU GRUB version 0.95 (631K lower / 2095488K upper memory) +-------------------------------------------------------------------------+ | Solaris 10 /sol_10_x86 | | Solaris failsafe | | | +-------------------------------------------------------------------------+ Use the ^ and v keys to select which entry is highlighted. Press enter to boot the selected OS, 'e' to edit the commands before booting, or 'c' for a command-line. |
Cet exemple présente une mise à niveau en direct d'un nœud de cluster. Cet exemple permet de mettre à niveau le nœud SPARC vers le système d'exploitation Solaris 10, la structure Sun Cluster 3.2 et tous les services de données Sun Cluster prenant en charge la méthode de mise à niveau en direct. Dans cet exemple, sc31u2 est l'environnement d'initialisation (EI) d'origine. Le nouvel EI mis à niveau possède le nom sc32 et utilise le point de montage /sc32. Le répertoire /net/installmachine/export/solaris10/OS_image/ contient une image du système d'exploitation Solaris 10. Le fichier d'état du programme d'installation de Java ES possède le nom sc32state.
Les commandes suivantes produisent généralement un résultat abondant. Ce résultat est présenté uniquement lorsque cela est nécessaire pour la clarté.
phys-schost# lucreate sc31u2 -m /:/dev/dsk/c0t4d0s0:ufs -n sc32 … lucreate: Creation of Boot Environment sc32 successful. phys-schost# luupgrade -u -n sc32 -s /net/installmachine/export/solaris10/OS_image/ The Solaris upgrade of the boot environment sc32 is complete. Apply patches phys-schost# lumount sc32 /sc32 phys-schost# ls -l /sc32/usr/java lrwxrwxrwx 1 root other 9 Apr 19 14:05 /sc32/usr/java -> /sc32/usr/j2se/ Insert the DVD-ROM Sun Java Availability Suite. phys-schost# cd /cdrom/cdrom0/Solaris_sparc phys-schost# ./installer -no -saveState sc32state phys-schost# ./installer -nodisplay -noconsole -state sc32state -altroot /sc32 phys-schost# cd /cdrom/cdrom0/Solaris_sparc/sun_cluster/Sol_9/Tools phys-schost# ./scinstall -u update -R /sc32 phys-schost# /sc32/usr/cluster/bin/scinstall -u update -s all -d /cdrom/cdrom0 -R /sc32 phys-schost# cd / phys-schost# eject cdrom phys-schost# luumount sc32 phys-schost# luactivate sc32 Activation of boot environment sc32 successful. Upgrade all other nodes Boot all nodes phys-schost# shutdown -y -g0 -i6 ok boot |
À ce stade, vous pouvez mettre à niveau les applications de service de données qui ne peuvent pas utiliser la méthode de mise à niveau en direct avant de réinitialiser en mode cluster.
Erreurs de noms des périphériques DID : au cours de la création de l'EI inactif, si vous avez reçu une erreur précisant qu'un système de fichiers que vous avez indiqué avec son nom de périphérique DID /dev/dsk/did/dNsX, n'existe pas, alors que le nom du périphérique existe bien, vous devez indiquer le périphérique par son nom de périphérique physique. Changez ensuite l'entrée vfstab sur l'EI secondaire pour utiliser le nom de périphérique DID. Procédez comme suit :
1) Pour tous les périphériques DID non reconnus, indiquez les noms des périphériques physiques correspondants en tant qu'arguments de l'option -m ou -M de la commande lucreate. Par exemple, si /global/.devices/node@nodeid est monté sur un périphérique DID, utilisez lucreate -m /global/.devices/node@nodeid:/dev/dsk/cNtXdYsZ:ufs [-m…] -n BE-name pour créer l'EI.
2) Montez l'EI inactif à l'aide de la commande lumount -n BE-name -m BE-mount-point.
3) Modifiez le fichier /BE-name/etc/vfstab pour convertir le nom de périphérique physique, /dev/dsk/cNtXdYsZ, en nom de périphérique DID, /dev/dsk/did/dNsX.
Erreurs de point de montage : au cours de la création de l'environnement d'initialisation inactif, si vous recevez une erreur indiquant que le point de montage indiqué n'est pas monté, montez ce point de montage et réexécutez la commande lucreate.
Nouvelles erreurs d'initialisation BE : si vous rencontrez des problèmes lorsque vous initialisez l'environnement nouvellement mis à niveau, vous pouvez rétablir le BE d'origine. Pour obtenir des informations spécifiques, reportez-vous à la rubrique Failure Recovery: Falling Back to the Original Boot Environment (Command-Line Interface) du Solaris 9 9/04 Installation Guide ou au Chapitre 10, Reprise sur panne : restauration de l’environnement d’initialisation d’origine (Tâches) du Guide d’installation de Solaris 10 : Solaris Live Upgrade et planification de la mise à niveau.
Erreurs de système de fichiers de périphériques globaux : après la mise à niveau d'un cluster sur lequel le disque racine est encapsulé, l'un des messages d'erreur suivants est susceptible de s'afficher sur la console du cluster lors de la première réinitialisation du BE mis à niveau.
mount: /dev/vx/dsk/bootdg/node@1 is already mounted or /global/.devices/node@1 is busy Trying to remount /global/.devices/node@1 mount: /dev/vx/dsk/bootdg/node@1 is already mounted or /global/.devices/node@1 is busy |
WARNING - Unable to mount one or more of the following filesystem(s): /global/.devices/node@1 If this is not repaired, global devices will be unavailable. Run mount manually (mount filesystem...). After the problems are corrected, please clear the maintenance flag on globaldevices by running the following command: /usr/sbin/svcadm clear svc:/system/cluster/globaldevices:default |
Dec 6 12:17:23 svc.startd[8]: svc:/system/cluster/globaldevices:default: Method "/usr/cluster/lib/svc/method/globaldevices start" failed with exit status 96. [ system/cluster/globaldevices:default misconfigured (see 'svcs -x' for details) ] Dec 6 12:17:25 Cluster.CCR: /usr/cluster/bin/scgdevs: Filesystem /global/.devices/node@1 is not available in /etc/mnttab. Dec 6 12:17:25 Cluster.CCR: /usr/cluster/bin/scgdevs: Filesystem /global/.devices/node@1 is not available in /etc/mnttab. |
Ces messages signalent que le numéro mineur vxio est identique sur chaque nœud de cluster. Minorez à nouveau le groupe de disques racine sur chaque nœud afin que chaque numéro soit unique dans le cluster. Reportez-vous à la rubrique Affectation d'un nouveau code mineur à un groupe de périphériques.
Reportez-vous à la section Vérification de la mise à niveau de Sun Cluster 3.2.
Vous pouvez choisir de conserver votre environnement d'initialisation original, et désormais inactif, tant que vous le souhaitez. Lorsque vous êtes satisfait de votre mise à niveau et que vous la considérez acceptable, vous pouvez choisir de supprimer l'ancien environnement ou de le conserver et d'en assurer la maintenance.
Si vous avez utilisé un volume non mis en miroir pour votre EI inactif, supprimez les anciens fichiers d'EI. Pour obtenir des informations spécifiques, reportez-vous à la rubrique Deleting an Inactive Boot Environment du Solaris 9 9/04 Installation Guide ou à la rubrique Suppression d’un environnement d’initialisation inactif du Guide d’installation de Solaris 10 : Solaris Live Upgrade et planification de la mise à niveau.
Si vous avez séparé un plex à utiliser en tant qu'EI inactif, refusionnez-le et synchronisez les miroirs. Pour de plus amples informations sur l'utilisation d'un plex, reportez-vous à la rubrique Example of Detaching and Upgrading One Side of a RAID 1 Volume (Mirror) (Command-Line Interface) du Solaris 9 9/04 Installation Guide ou à la rubrique Exemple de séparation et de mise à niveau d’une face d’un volume RAID-1 (miroir) (interface de ligne de commande) du Guide d’installation de Solaris 10 : Solaris Live Upgrade et planification de la mise à niveau.
Vous pouvez également assurer la maintenance de l'EI inactif. Pour obtenir des informations sur la façon de maintenir l'environnement, reportez-vous au Chapitre 37, Maintaining Solaris Live Upgrade Boot Environments (Tasks) du Solaris 9 9/04 Installation Guide ou au Chapitre 11, Maintenance des environnements d’initialisation de Solaris Live Upgrade – Tâches du Guide d’installation de Solaris 10 : Solaris Live Upgrade et planification de la mise à niveau.
Cette section fournit les informations suivantes pour finaliser toutes les méthodes de mise à niveau de Sun Cluster 3.2 :
Cette procédure permet de s'assurer de la mise à niveau du cluster vers Sun Cluster 3.2. Sur Solaris 10, effectuez toutes les étapes à partir de la zone globale uniquement.
Cette procédure fournit les formes longues des commandes Sun Cluster. La plupart des commandes ont également une forme courte. À l'exception des formes des noms de commandes, les commandes sont identiques. Pour obtenir la liste des commandes et leurs formes courtes, reportez-vous à l'Annexe A, Sun Cluster Object-Oriented Commands du Sun Cluster System Administration Guide for Solaris OS.
Assurez-vous que toutes les procédures de mise à niveau ont été effectuées pour tous les nœuds du cluster mis à niveau.
Sur chaque nœud, devenez superutilisateur.
Sur chaque nœud mis à niveau, affichez la version de Sun Cluster.
phys-schost# clnode show-rev -v |
La première ligne du résultat indique la version de Sun Cluster actuellement utilisée par le nœud. Elle doit correspondre à celle de la mise à niveau.
À partir d'un nœud, vérifiez que tous les nœuds du cluster mis à niveau sont exécutés en mode cluster (En ligne).
phys-schost# clnode status |
Pour de plus amples informations sur l'affichage du statut du cluster, reportez-vous à la page de manuel clnode(1CL).
SPARC : Si vous avez mis à niveau à partir de Solaris 8 vers Solaris 9, vérifiez la cohérence de la configuration du stockage.
Sur chacun des nœuds, exécutez la commande ci-dessous afin de vérifier la cohérence de la configuration de stockage.
phys-schost# cldevice check |
Avant de passer à l'Étape b, vous devez exécuter la vérification de la cohérence de la configuration. À défaut, vous risquez d'observer des erreurs d'identification de périphérique et une corruption des données.
Le tableau suivant répertorie le résultat possible à partir de la commande cldevice check et l'action à entreprendre, le cas échéant.
Exemple de message |
Action |
---|---|
L'identificateur de périphérique pour 'phys-schost-1:/dev/rdsk/c1t3d0' ne correspond pas à l'identificateur du périphérique physique, le périphérique a peut-être été remplacé |
Reportez-vous à la section Récupération suite à une mise à niveau incomplète et effectuez la procédure de réparation appropriée. |
device id for 'phys-schost-1:/dev/rdsk/c0t0d0' needs to be updated, run cldevice repair to update |
Aucune. Vous mettez à jour cet ID de périphérique à l'Étape b. |
Aucun message de sortie |
Aucune. |
Reportez-vous à la page de manuel cldevice(1CL) pour plus d'informations.
Sur chaque nœud, migrez la base de données de stockage Sun Cluster vers les ID de périphériques Solaris 9.
phys-schost# cldevice repair |
Sur chacun des nœuds, exécutez la commande ci-dessous afin de vérifier que la migration de la base de données de stockage vers les ID de périphériques de Solaris 9 a été correctement effectuée.
phys-schost# cldevice check |
Si la commande cldevice affiche un message, revenez à l'Étape a pour apporter de nouvelles corrections à la configuration ou à la base de données de stockage.
Si elle n'affiche aucun message, cela signifie que la migration des ID de périphériques a été réalisée avec succès. Lorsque la migration des ID de périphériques est vérifiée sur tous les nœuds du cluster, passez à la section Finition de la mise à niveau vers Sun Cluster 3.2.
L'exemple suivant présente les commandes utilisées pour vérifier la mise à niveau d'un cluster à deux nœuds vers Sun Cluster 3.2. Les nœuds du cluster s'appellent phys-schost-1 et phys-schost-2.
phys-schost# clnode show-rev -v 3.2 … phys-schost# clnode status === Cluster Nodes === --- Node Status --- Node Name Status --------- ------ phys-schost-1 Online phys-schost-2 Online |
Reportez-vous à la section Finition de la mise à niveau vers Sun Cluster 3.2.
Effectuez cette procédure pour terminer la mise à niveau de Sun Cluster. Sur Solaris 10, effectuez toutes les étapes à partir de la zone globale uniquement. Réenregistrez tout d'abord tous les types de ressources ayant bénéficié d'une nouvelle version dans le cadre de la mise à niveau. Modifiez ensuite les ressources concernées de sorte qu'elles puissent utiliser la nouvelle version du type de ressources. Réactivez les ressources et mettez en ligne les groupes de ressources.
Assurez-vous que toutes les étapes de la section Vérification de la mise à niveau de Sun Cluster 3.2 ont été appliquées.
Copiez les fichiers de sécurité de conteneur d'agents communs dans tous les nœuds du cluster.
Ainsi, ces fichiers seront identiques sur tous les nœuds de cluster, et les fichiers copiés disposeront des autorisations de fichier correctes.
Sur chaque nœud, arrêtez l'agent Sun Java Web Console.
phys-schost# /usr/sbin/smcwebserver stop |
Sur chaque nœud, arrêtez l'agent de fichiers de sécurité.
phys-schost# /usr/sbin/cacaoadm stop |
Sur un nœud, déplacez-vous sur le répertoire /etc/cacao/instances/default/.
phys-schost-1# cd /etc/cacao/instances/default/ |
Créez un fichier tar du répertoire /etc/opt/SUNWcacao/security/.
phys-schost-1# tar cf /tmp/SECURITY.tar security |
Copiez le fichier /tmp/SECURITY.tar vers chacun des autres nœuds du cluster.
Sur chaque nœud vers lequel le fichier /tmp/SECURITY.tar a été copié, procédez à l'extraction des fichiers de sécurité.
Les fichiers de sécurité existants et présents dans le répertoire /etc/cacao/instances/default/ sont écrasés.
phys-schost-2# cd /etc/cacao/instances/default/ phys-schost-2# tar xf /tmp/SECURITY.tar |
Supprimez le fichier /tmp/SECURITY.tar de chaque nœud du cluster.
Vous devez supprimer chaque copie du fichier tar pour éviter tout problème de sécurité.
phys-schost-1# rm /tmp/SECURITY.tar phys-schost-2# rm /tmp/SECURITY.tar |
Sur chaque nœud, lancez l'agent de fichiers de sécurité.
phys-schost# /usr/sbin/cacaoadm start |
Sur chaque nœud, démarrez l'agent Sun Java Web Console.
phys-schost# /usr/sbin/smcwebserver start |
Si vous avez mis à niveau des services de données non disponibles sur le support produit, enregistrez leurs nouveaux types de ressources.
Suivez la documentation qui accompagne les services de données.
Si vous avez procédé à une mise à niveau de Sun Cluster HA pour SAP liveCache à partir de Sun Cluster version 3.0 ou 3.1 vers Sun Cluster version 3.2, modifiez le fichier de configuration /opt/SUNWsclc/livecache/bin/lccluster.
Connectez-vous en tant que superutilisateur sur le nœud qui hébergera la ressource liveCache.
Copiez le nouveau fichier /opt/SUNWsclc/livecache/bin/lccluster dans le répertoire /sapdb/LC_NAME/db/sap/.
Remplacez le fichier lccluster créé lors de la configuration précédente du service de données.
Configurez ce fichier /sapdb/LC_NAME/db/sap/lccluster selon les instructions de la section How to Register and Configure Sun Cluster HA for SAP liveCache du Sun Cluster Data Service for SAP liveCache Guide for Solaris OS.
Si vous avez mis à niveau le système d'exploitation Solaris et que votre configuration utilise des médiateurs à deux chaînes pour Solaris Volume Manager, restaurez les configurations de médiateur.
Identifiez le nœud propriétaire du jeu de disques auquel vous souhaitez ajouter les hôtes médiateurs.
phys-schost# metaset -s setname |
Spécifie le nom du jeu de disques.
Sur le nœud qui contrôle ou contrôlera le jeu de disques, devenez superutilisateur.
Si aucun nœud n'est propriétaire, devenez propriétaire du jeu de disques.
phys-schost# cldevicegroup switch -n node devicegroup |
Indique le nom du nœud que vous voulez convertir en nœud principal du jeu de disques.
Indique le nom du jeu de disques.
Recréez les médiateurs.
phys-schost# metaset -s setname -a -m mediator-host-list |
Ajoute le nœud au jeu de disques.
Indique le nom des nœuds à ajouter en tant qu'hôtes médiateurs du jeu de disques.
Répétez ces étapes pour chaque jeu de disques du cluster utilisant des médiateurs.
Si vous avez mis à niveau VxVM, mettez à niveau tous les groupes de disques.
Connectez un jeu de disques à mettre à niveau et devenez-en propriétaire.
phys-schost# cldevicegroup switch -n node devicegroup |
Exécutez les commandes suivantes pour mettre à niveau un jeu de disques en fonction de la version VxVM installée.
phys-schost# vxdg upgrade dgname |
Reportez-vous au manuel de l'administrateur de VxVM pour de plus amples informations sur la mise à niveau des groupes de disques.
Répétez la procédure pour les autres jeux de disques VxVM du cluster.
Migrez les ressources vers la nouvelle version des types de ressources.
Vous devez faire migrer toutes les ressources vers la version de type de ressource Sun Cluster 3.2.
Pour Sun Cluster HA pour SAP Web Application Server, si vous utilisez une ressource de moteur J2EE ou une ressource de composant serveur d'application Web, ou les deux, vous devez supprimer la ressource et la recréer avec la nouvelle ressource de composant serveur d'application Web. Les modifications apportées à la nouvelle ressource de composant serveur d'application Web incluent l'intégration de la fonctionnalité J2EE. Pour plus d'informations, reportez-vous au manuel Sun Cluster Data Service for SAP Web Application Server Guide for Solaris OS.
Pour de plus amples informations sur les procédures utilisant la ligne de commande, reportez-vous à la rubrique Upgrading a Resource Type du Sun Cluster Data Services Planning and Administration Guide for Solaris OS. Si vous préférez, vous pouvez également effectuer les mêmes tâches en utilisant le menu Groupe de ressources de l'utilitaire clsetup. Le processus implique la réalisation des tâches suivantes :
Enregistrement du nouveau type de ressources
Migration de la ressource éligible vers la nouvelle version de son type de ressource
Modification des propriétés de l'extension du type de ressource comme spécifié dans les Notes de version de Sun Cluster 3.2 pour SE Solaris
La version 3.2 de Sun Cluster introduit de nouvelles valeurs par défaut pour certaines propriétés d'extension, notamment la propriété Retry_interval. Ces modifications affectent le comportement des ressources existantes qui utilisent les valeurs par défaut de ces propriétés. Si vous avez besoin de la valeur par défaut précédente d'une ressource, modifiez la ressource migrée pour définir la propriété sur la valeur par défaut précédente.
Si votre cluster exécute le service de données Sun Cluster HA pour Sun Java System Application Server EE (HADB) et que vous arrêtez la base de données HADB avant de commencer une mise à niveau à partition double, réactivez la ressource et démarrez la base de données.
phys-schost# clresource enable hadb-resource phys-schost# hadbm start database-name |
Pour de plus amples informations, reportez-vous à la page de manuel hadbm(1m).
Si vous avez mis à niveau vers le système d'exploitation Solaris 10 et que le fichier httpd.conf Apache est situé sur un système de fichiers de cluster, assurez-vous que l'entrée HTTPD du script de contrôle Apache pointe toujours vers cet emplacement.
Affichez l'entrée HTTPD dans le fichier /usr/apache/bin/apchectl.
L'exemple suivant présente le fichier httpd.conf situé sur le système de fichiers du cluster /global.
phys-schost# cat /usr/apache/bin/apchectl | grep HTTPD=/usr HTTPD="/usr/apache/bin/httpd -f /global/web/conf/httpd.conf" |
Si le fichier ne présente pas l'entrée HTTPD correcte, mettez le fichier à jour.
phys-schost# vi /usr/apache/bin/apchectl #HTTPD=/usr/apache/bin/httpd HTTPD="/usr/apache/bin/httpd -f /global/web/conf/httpd.conf" |
À partir d'un nœud, lancez l'utilitaire clsetup.
phys-schost# clsetup |
Le menu principal clsetup s'affiche.
Réactivez toutes les ressources désactivées.
Saisissez le numéro correspondant à l'option des groupes de ressources, puis appuyez sur la touche Retour.
Le menu du groupe de ressources apparaît.
Saisissez le numéro correspondant à l'option d'activation/désactivation d'une ressource, puis appuyez sur la touche Retour.
Choisissez une ressource à activer, puis suivez les directives fournies.
Répétez l'Étape c pour chaque ressource désactivée.
Une fois que toutes les ressources sont réactivées, entrez q pour revenir au menu Groupe de ressources.
Remettez en ligne tous les groupes de ressources.
Cette étape inclut la mise en ligne de groupes de ressources dans des zones non globales.
Une fois tous les groupes de ressources remis en ligne, quittez l'utilitaire clsetup.
Entrez q pour sortir de chaque sous-menu ou appuyez sur Ctrl-C.
Si, avant la mise à niveau, vous aviez activé la réinitialisation de nœud automatique dans le cas de l'échec de tous les chemins de disque surveillés, assurez-vous que cette fonctionnalité est toujours activée.
Effectuez également cette tâche si vous souhaitez configurer une réinitialisation automatique pour la première fois.
Déterminez si la fonctionnalité de réinitialisation automatique est activée ou désactivée.
phys-schost# clnode show |
Activez la fonctionnalité de réinitialisation automatique.
phys-schost# clnode set -p reboot_on_path_failure=enabled |
Indique la propriété à définir.
Indique que le nœud est réinitialisé si tous les chemins de disque contrôlés échouent, à condition qu'au moins l'un des disques soit accessible à partir d'un autre nœud du cluster.
Vérifiez que la réinitialisation automatique en cas d'échec du chemin de disque est activée.
phys-schost# clnode show === Cluster Nodes === Node Name: node … reboot_on_path_failure: enabled … |
(Facultatif) Capturez les informations de partitionnement du disque pour toute référence ultérieure.
phys-schost# prtvtoc /dev/rdsk/cNtXdYsZ > filename |
Stockez le fichier dans un emplacement extérieur au cluster. Si vous modifiez la configuration du disque, exécutez de nouveau cette commande pour capturer la configuration modifiée. Si un disque est en panne et doit être remplacé, vous pouvez utiliser ces informations pour restaurer la configuration de la partition du disque. Pour de plus amples informations, reportez-vous à la page de manuel prtvtoc(1M).
(Facultatif) Procédez à la sauvegarde de votre configuration de cluster.
Si vous effectuez une sauvegarde archivée de votre configuration de cluster, vous pourrez la récupérer plus facilement en cas de problème.
Pour plus d'informations, reportez-vous à la section How to Back Up the Cluster Configuration du Sun Cluster System Administration Guide for Solaris OS.
Échec de migration du type de ressource : généralement, vous migrez des ressources vers un nouveau type de ressource lorsque la ressource est hors ligne. Cependant, certaines ressources doivent être en ligne pour qu'une migration du type de ressource soit réussie. Si une migration de type de ressource échoue pour cette raison, des messages d'erreur similaires à ce qui suit s'affichent :
phys-schost - Resource depends on a SUNW.HAStoragePlus type resource that is not online anywhere. (C189917) VALIDATE on resource nfsrs, resource group rg, exited with non-zero exit status. (C720144) Validation of resource nfsrs in resource group rg on node phys-schost failed.
Si une migration de type de ressource échoue parce que la ressource est hors ligne, utilisez l'utilitaire clsetup pour réactiver la ressource, puis mettez son groupe de ressources lié en ligne. Répétez ensuite les procédures de migration pour la ressource.
Changement de l'emplacement des binaires Java : si l'emplacement des binaires Java a changé au cours de la mise à niveau des composants partagés, il se peut que des messages d'erreur similaires à ce qui suit s'affichent lorsque vous essayez d'exécuter la commande cacaoadm start ou smcwebserver start :
# /opt/SUNWcacao/bin/cacaoadm startNo suitable Java runtime found. Java 1.4.2_03 or higher is required.Jan 3 17:10:26 ppups3 cacao: No suitable Java runtime found. Java 1.4.2_03 or higher is required.Cannot locate all the dependencies
# smcwebserver start/usr/sbin/smcwebserver: /usr/jdk/jdk1.5.0_04/bin/java: not found
Ces erreurs sont générées parce que les commandes de démarrage ne parviennent pas à trouver l'emplacement actuel des binaires Java. La propriété JAVA_HOME pointe toujours vers le répertoire où se trouve la version précédente de Java, mais cette version précédente a été supprimée au cours de la mise à niveau.
Pour corriger ce problème, modifiez le paramètre de JAVA_HOME dans les fichiers de configuration suivants pour utiliser le répertoire Java actuel :
/etc/webconsole/console/config.properties/etc/opt/SUNWcacao/cacao.properties
Si vous disposez d'un système SPARC et si vous utilisez Sun Management Center pour surveiller le cluster, reportez-vous à la rubrique SPARC : Mise à niveau du module Sun Cluster pour Sun Management Center.
Pour installer ou terminer la mise à niveau de Sun Cluster Geographic Edition 3.2, reportez-vous au Sun Cluster Geographic Edition Installation Guide.
Dans le cas contraire, la mise à niveau du cluster est terminée.
Cette section fournit les informations suivantes pour récupérer à la suite de certains types de mises à niveau incomplètes :
Récupération suite à l'échec d'une mise à niveau à partition double
SPARC : Récupération à partir d'une mise à niveau à partition double partiellement terminée
SPARC : Récupération à partir d'une mise à niveau à partition double partiellement terminée
Récupération après les modifications de configuration du stockage lors de la mise à niveau
Si une erreur irrécupérable se produit au cours d'une mise à niveau, effectuez cette procédure pour rétablir la mise à niveau.
Vous ne pouvez pas redémarrer une mise à niveau à partition double après qu'une mise à niveau a rencontré une erreur irrécupérable.
Connectez-vous en tant que superutilisateur sur chaque noeud de la grappe.
Réinitialisez chaque noeud en mode non cluster.
Sur les systèmes SPARC, exécutez la commande suivante :
ok boot -x |
Sur les systèmes x86, exécutez les commandes suivantes :
Dans le menu GRUB, utilisez les touches fléchées pour sélectionner l'entrée Solaris appropriée, puis saisissez e pour modifier ses commandes.
Le menu GRUB qui s'affiche est similaire à ce qui suit :
GNU GRUB version 0.95 (631K lower / 2095488K upper memory) +-------------------------------------------------------------------------+ | Solaris 10 /sol_10_x86 | | Solaris failsafe | | | +-------------------------------------------------------------------------+ Use the ^ and v keys to select which entry is highlighted. Press enter to boot the selected OS, 'e' to edit the commands before booting, or 'c' for a command-line. |
Pour plus d'informations sur l'initialisation GRUB, reportez-vous au Chapitre 11, GRUB Based Booting (Tasks) du System Administration Guide: Basic Administration.
Sur l'écran des paramètres d'initialisation, utilisez les touches fléchées pour sélectionner l'entrée kernel et saisissez e pour modifier l'entrée.
L'écran des paramètres d'initialisation GRUB qui s'affiche est similaire à ce qui suit :
GNU GRUB version 0.95 (615K lower / 2095552K upper memory) +----------------------------------------------------------------------+ | root (hd0,0,a) | | kernel /platform/i86pc/multiboot | | module /platform/i86pc/boot_archive | +----------------------------------------------------------------------+ Use the ^ and v keys to select which entry is highlighted. Press 'b' to boot, 'e' to edit the selected command in the boot sequence, 'c' for a command-line, 'o' to open a new line after ('O' for before) the selected line, 'd' to remove the selected line, or escape to go back to the main menu. |
Ajoutez -x à la commande pour spécifier l'initialisation du système en mode non cluster.
[ Minimal BASH-like line editing is supported. For the first word, TAB lists possible command completions. Anywhere else TAB lists the possible completions of a device/filename. ESC at any time exits. ] grub edit> kernel /platform/i86pc/multiboot -x |
Appuyez sur Entrée pour accepter la modification et retourner à l'écran des paramètres d'initialisation.
L'écran affiche la commande modifiée.
GNU GRUB version 0.95 (615K lower / 2095552K upper memory) +----------------------------------------------------------------------+ | root (hd0,0,a) | | kernel /platform/i86pc/multiboot -x | | module /platform/i86pc/boot_archive | +----------------------------------------------------------------------+ Use the ^ and v keys to select which entry is highlighted. Press 'b' to boot, 'e' to edit the selected command in the boot sequence, 'c' for a command-line, 'o' to open a new line after ('O' for before) the selected line, 'd' to remove the selected line, or escape to go back to the main menu.- |
Saisissez b pour initialiser le nœud en mode non cluster.
Cette modification apportée à la commande du paramètre d'initialisation du noyau n'est pas conservée après l'initialisation du système. La prochaine réinitialisation du nœud se fera donc en mode cluster. Pour effectuer un démarrage en mode non-cluster, exécutez à nouveau ces étapes pour ajouter l'option -x à la commande du paramètre d'initialisation du noyau.
Sur chaque nœud, exécutez le script de récupération de mise à niveau à partir du support d'installation.
Si le nœud a été correctement mis à niveau vers Sun Cluster 3.2, vous pouvez également exécuter la commande scinstall à partir du répertoire /usr/cluster/bin.
phys-schost# cd /cdrom/cdrom0/Solaris_arch/Product/sun_cluster/Solaris_ver/Tools phys-schost# ./scinstall -u recover |
Spécifie la mise à niveau.
Restaure le fichier /etc/vfstab et la base de données de référentiel de configuration du cluster à leur état d'origine avant le début de la mise à niveau à partition double.
Le processus de récupération laisse les nœuds du cluster en mode non cluster. N'essayez pas de réinitialiser les nœuds en mode cluster.
Pour de plus amples informations, reportez-vous à la page du manuel scinstall(1M).
Effectuez l'une des tâches suivantes :
Restaurez l'ancien logiciel à partir d'une sauvegarde pour rétablir l'état d'origine du cluster.
Continuez à mettre à niveau les logiciels du cluster à l'aide de la méthode de mise à niveau standard.
Cette méthode requiert que tous les nœuds du cluster restent en mode non cluster au cours de la mise à niveau. Reportez-vous à la liste des tâches de la mise à niveau standard, Tableau 8–1. Vous pouvez reprendre la mise à niveau à la dernière tâche ou étape des procédures de mise à niveau standard correctement terminées avant l'échec de la mise à niveau à partition double.
Exécutez cette procédure si une mise à niveau à partition double échoue et si l'état du cluster remplit tous les critères suivants :
Les nœuds de la première partition ont été mis à niveau.
Aucun nœud de la seconde partition n'a encore été mis à niveau.
Aucun nœud de la seconde partition n'est en mode cluster.
Vous pouvez également exécuter cette procédure si la mise à niveau sur la première partition a abouti et que vous souhaitez sortir de ce processus.
En revanche, n'exécutez pas cette procédure si la mise à niveau a commencé sur la seconde partition. À la place, exécutez la procédure Récupération suite à l'échec d'une mise à niveau à partition double.
Avant de commencer, vérifiez que tous les nœuds de la seconde partition sont arrêtés. Ceux de la première partition peuvent être arrêtés ou en cours d'exécution en mode non cluster.
Exécutez toutes les étapes en tant que superutilisateur.
Initialisez chaque nœud de la deuxième partition en mode non cluster.
# ok boot -x |
Sur chaque nœud de la seconde partition, exécutez la commande scinstall -u recover.
# /usr/cluster/bin/scinstall -u recover |
La commande restaure les informations CCR d'origine, le fichier /etc/vfstab d'origine et élimine les modifications pour le démarrage.
Démarrez chaque nœud de la seconde partition en mode cluster.
# shutdown -g0 -y -i6 |
Lorsque les nœuds de la seconde partition s'affichent, cette seconde partition reprend la prise en charge des services de données du cluster tout en exécutant l'ancien logiciel dans sa configuration d'origine.
Restaurez les données du logiciel et de configuration d'origine du support de sauvegarde vers les nœuds de la première partition.
Démarrez chaque nœud de la première partition en mode cluster.
# shutdown -g0 -y -i6 |
Les nœuds rejoignent le cluster.
Exécutez cette procédure si une mise à niveau à partition double échoue et si l'état du cluster remplit tous les critères suivants :
Les nœuds de la première partition ont été mis à niveau.
Aucun nœud de la seconde partition n'a encore été mis à niveau.
Aucun nœud de la seconde partition n'est en mode cluster.
Vous pouvez également exécuter cette procédure si la mise à niveau sur la première partition a abouti et que vous souhaitez sortir de ce processus.
En revanche, n'exécutez pas cette procédure si la mise à niveau a commencé sur la seconde partition. À la place, exécutez la procédure Récupération suite à l'échec d'une mise à niveau à partition double.
Avant de commencer, vérifiez que tous les nœuds de la seconde partition sont arrêtés. Ceux de la première partition peuvent être arrêtés ou en cours d'exécution en mode non cluster.
Exécutez toutes les étapes en tant que superutilisateur.
Démarrez chaque nœud de la seconde partition en mode non cluster en exécutant les étapes suivantes.
Dans le menu GRUB, utilisez les touches de direction pour sélectionner l'entrée Solaris appropriée, puis tapez e pour modifier ses commandes.
Le menu GRUB qui s'affiche est similaire à ce qui suit :
GNU GRUB version 0.95 (631K lower / 2095488K upper memory) +-------------------------------------------------------------------------+ | Solaris 10 /sol_10_x86 | | Solaris failsafe | | | +-------------------------------------------------------------------------+ Use the ^ and v keys to select which entry is highlighted. Press enter to boot the selected OS, 'e' to edit the commands before booting, or 'c' for a command-line. |
Pour plus d'informations sur l'initialisation GRUB, reportez-vous au Chapitre 11, GRUB Based Booting (Tasks) du System Administration Guide: Basic Administration.
Dans l'écran des paramètres d'initialisation, utilisez les touches de direction pour sélectionner l'entrée du noyau, puis tapez e pour modifier l'entrée.
L'écran des paramètres d'initialisation GRUB qui s'affiche est similaire à ce qui suit :
GNU GRUB version 0.95 (615K lower / 2095552K upper memory) +----------------------------------------------------------------------+ | root (hd0,0,a) | | kernel /platform/i86pc/multiboot | | module /platform/i86pc/boot_archive | +----------------------------------------------------------------------+ Use the ^ and v keys to select which entry is highlighted. Press 'b' to boot, 'e' to edit the selected command in the boot sequence, 'c' for a command-line, 'o' to open a new line after ('O' for before) the selected line, 'd' to remove the selected line, or escape to go back to the main menu. |
Ajoutez l'option -x à la commande pour spécifier le démarrage du système en mode non cluster.
Minimal BASH-like line editing is supported. For the first word, TAB lists possible command completions. Anywhere else TAB lists the possible completions of a device/filename. ESC at any time exits. |
# grub edit> kernel /platform/i86pc/multiboot -x |
Appuyez sur Entrée pour accepter la modification et retourner à l'écran des paramètres d'initialisation.
L'écran affiche la commande modifiée.
GNU GRUB version 0.95 (615K lower / 2095552K upper memory) +----------------------------------------------------------------------+ | root (hd0,0,a) | | kernel /platform/i86pc/multiboot -x | | module /platform/i86pc/boot_archive | +----------------------------------------------------------------------+ Use the ^ and v keys to select which entry is highlighted. Press 'b' to boot, 'e' to edit the selected command in the boot sequence, 'c' for a command-line, 'o' to open a new line after ('O' for before) the selected line, 'd' to remove the selected line, or escape to go back to the main menu.- |
Tapez b pour démarrer le nœud en mode non cluster.
Cette modification apportée à la commande du paramètre d'initialisation du noyau n'est pas conservée après l'initialisation du système. La prochaine réinitialisation du nœud se fera donc en mode cluster. Pour effectuer un démarrage en mode non cluster, exécutez à nouveau ces étapes pour ajouter l'option -x à la commande du paramètre d'initialisation du noyau.
Sur chaque nœud de la seconde partition, exécutez la commande scinstall -u recover.
# /usr/cluster/bin/scinstall -u recover |
La commande restaure les informations CCR d'origine, le fichier /etc/vfstab d'origine et élimine les modifications pour le démarrage.
Démarrez chaque nœud de la seconde partition en mode cluster.
# shutdown -g0 -y -i6 |
Lorsque les nœuds de la seconde partition s'affichent, cette seconde partition reprend la prise en charge des services de données du cluster tout en exécutant l'ancien logiciel dans sa configuration d'origine.
Restaurez les données du logiciel et de configuration d'origine du support de sauvegarde vers les nœuds de la première partition.
Démarrez chaque nœud de la première partition en mode cluster.
# shutdown -g0 -y -i6 |
Les nœuds rejoignent le cluster.
Cette rubrique fournit les procédures de réparation suivantes à suivre en cas de modification accidentelle de la configuration du stockage lors de la mise à niveau :
Toute modification de la topologie du stockage, y compris l'exécution des commandes de Sun Cluster, doit être terminée avant la mise à niveau vers le logiciel Solaris 9 ou Solaris 10. Cependant, si les modifications interviennent pendant la mise à niveau, suivez la procédure indiquée ci-après. Elle garantit que la nouvelle configuration du stockage est correcte et que le stockage existant non reconfiguré n'a pas subi d'altération par erreur.
Cette procédure fournit les formes longues des commandes Sun Cluster. La plupart des commandes ont également une forme courte. À l'exception des formes des noms de commandes, les commandes sont identiques. Pour obtenir la liste des commandes et leurs formes courtes, reportez-vous à l'Annexe A, Sun Cluster Object-Oriented Commands du Sun Cluster System Administration Guide for Solaris OS.
Assurez-vous que la topologie du stockage est correcte. Vérifiez si les périphériques marqués comme étant éventuellement remplacés ont été effectivement remplacés. S'ils n'ont pas été remplacés, vérifiez et corrigez les modifications de configuration accidentels éventuels, telles qu'un câblage incorrect.
Sur un nœud connecté à un périphérique non contrôlé, devenez superutilisateur.
Mettez à jour manuellement le périphérique non vérifié.
phys-schost# cldevice repair device |
Reportez-vous à la page de manuel cldevice(1CL) pour plus d'informations.
Mettez le pilote IDP à jour.
phys-schost# scdidadm -ui phys-schost# scdidadm -r |
Charge la table de configuration des ID de périphérique dans le noyau.
Initialise le pilote DID.
Reconfigure la base de données.
Répétez l'Étape 2 et l'Étape 3 sur tous les nœuds connectés au périphérique non contrôlé.
Revenez aux tâches de mise à niveau restantes. Rendez-vous à l'Étape 4 de la section Mise à niveau de Sun Cluster 3.2 (standard).
Si des modifications accidentelles interviennent au niveau du câblage du stockage au cours de la mise à niveau, exécutez la procédure suivante pour rétablir l'état approprié de la configuration du stockage.
cette procédure suppose qu'aucun stockage physique n'a été effectivement modifié. Si les périphériques de stockage physiques ou logiques ont été modifiés ou remplacés, suivez les procédures de la rubrique Reconfiguration du stockage pendant une mise à niveau.
Restaurez la configuration initiale de la topologie de stockage. Vérifiez la configuration des périphériques marqués comme étant éventuellement remplacés, y compris le câblage.
Sur chaque nœud du cluster, devez superutilisateur.
Mettez à jour le pilote DID sur chaque nœud du cluster.
phys-schost# scdidadm -ui phys-schost# scdidadm -r |
Charge le tableau de configuration des ID de périphériques dans le noyau.
Initialise le pilote DID.
Reconfigure la base de données.
Reportez-vous à la page de manuel scdidadm(1M) pour obtenir plus d'informations.
Si la commande scdidadm a renvoyé un message d'erreur lors de l'Étape 2, procédez aux autres modifications nécessaires pour corriger la configuration du stockage, puis répétez l'Étape 2.
Revenez aux tâches de mise à niveau restantes. Rendez-vous à l'Étape 4 de la section Mise à niveau de Sun Cluster 3.2 (standard).