BigAdmin System Administration Portal
Article de fond
Print-friendly VersionPrint-friendly Version

Fonction de mise à jour de zones lors du rattachement et application de patch sur le système d'exploitation Solaris 10

Enda O'Connor River, juin 2009

Présentation

Depuis le système d'exploitation Solaris 10 5/08, les administrateurs système peuvent détacher et attacher des zones, d'un système à un autre. La fonctionnalité initiale s'accompagnait de certaines restrictions exigeant que les systèmes source et cible, auxquels était attachée la zone non globale, devaient avoir le même niveau logiciel, c'est-à-dire la même version de package, le même niveau de patch et la même architecture. En d'autres termes, vous ne pouviez pas déplacer une zone à partir d'un système sun4v vers un système sun4u ou à partir d'une version antérieure de Solaris vers la version actuelle de Solaris.

Dans la version Solaris 10 10/08, une nouvelle fonctionnalité peut être utilisée via la commande "update on attach" : l'argument -u de zoneadm attach.

Cet article décrit la fonctionnalité de mise à jour lors du rattachement et aborde les sujets suivants :

Critères de détermination des packages mis à jour

Lorsque vous utilisez la mise à jour lors du rattachement, la zone attachée est mise à jour au même niveau logiciel que celui de la zone globale selon la logique suivante (qui détermine les packages mis à jour) :

  1. Si un package de la zone non globale porte le paramètre SUNW_PKG_ALLZONES=true, il est sélectionné pour la mise à jour.
  2. Si un package fournit des bits à un répertoire de packages hérité, il est sélectionné pour la mise à jour. Le terme "répertoire de packages hérité" fait référence à un répertoire qui est hérité par la zone non globale à partir de la zone globale. Une zone fragmentée hérite par défaut de /usr, /lib, /platform et /sbin. Tout répertoire ajouté via la sous-commande add inherit-pkg-dir de la commande zonecfg est un répertoire de packages hérité.
  3. Tout package remplissant la condition du point 1 ou 2 ci-dessus est également mis à jour, quel que soit son paramètre SUNW_PKG_ALLZONES et qu'il fournisse ou non des bits à un répertoire de packages hérité.

Une fois qu'un package est sélectionné pour la mise à jour, le même processus ayant installé le package lors de la première installation de la zone est utilisé pour effectuer les opérations suivantes :

  • Suppression du package de la zone non globale en cours de mise à jour
  • Installation du package mis en spool depuis la zone globale où se produit le rattachement à la zone non globale étant attachée

Par exemple, pour la mise à jour de SUNWcsr, le répertoire /var/sadm/pkg/SUNWcsr/save/pspool/SUNWcsr/ de la zone globale est utilisé pour fournir le package SUNWcsr mis à jour dans la zone non globale attachée au système. Ce répertoire est utilisé pour fournir un nouveau package SUNWcsr de la zone non globale pendant l'exécution d'une commande zoneadm install.

Exemple du point 3 ci-dessus : lorsqu'un package A présente le paramètre SUNW_PKG_ALLZONES=true, il est sélectionné pour la mise à jour. Le package A dépend du package B. Le package B n'a pas de paramètre SUNW_PKG_ALLZONES=true et fournit des bits au répertoire /etc (afin de ne pas répondre aux critères des points 1 et 2 ci-dessus). Cependant, étant donné que le package A dépend du package B, ce dernier est également sélectionné pour la mise à jour.

Les critères de sélection constituent un facteur important lorsque vous prenez en compte les répertoires de packages hérités utilisés par la zone non globale. Dans le cas d'une zone non globale whole root, il n'existe aucun répertoire de packages hérité. Par conséquent, moins de packages sont sélectionnés pour la mise à jour que pour une zone fragmentée exécutée au même niveau logiciel.

Il est également intéressant de savoir que tout package de la zone globale comportant le paramètre SUNW_PKG_THISZONE=true est automatiquement ignoré ; c'est-à-dire que si le package existe dans la zone non globale, il n'est pas mis à jour.

Mise à jour lors du rattachement ou mise à niveau régulière

Avant de poursuivre, il est bon de comprendre la différence entre une mise à niveau standard à l'aide d'un des mécanismes de mise à niveau pris en charge et l'utilisation de la mise à jour lors du rattachement. Lorsque vous procédez à une mise à niveau standard, toutes les zones non globales natives Solaris sont mises à niveau, c'est-à-dire qu'elles reçoivent les nouveaux packages et les nouvelles fonctions disponibles dans le cadre de la mise à niveau, les packages obsolètes sont supprimés, et les zones non globales et la zone globale sont au même niveau logiciel quant aux versions de patchs et de packages fournies dans la mise à jour.

En d'autres termes, l'image de mise à jour est appliquée à la zone globale et à toutes les zones non globales. Aucune vérification de dépendance n'est effectuée par rapport à la zone globale et aux zones non globales au cours d'une mise à niveau et tous les packages faisant partie de l'image sont répartis dans toutes les zones, y compris dans la zone globale.

En revanche, si vous utilisez la mise à jour lors du rattachement, un inventaire logiciel de la zone globale et de la zone non globale mise à jour est dressé. Puis, à l'aide des trois critères décrits précédemment, zoneadm détermine les packages à mettre à jour dans la zone non globale.

Ainsi, si vous détachez toutes les zones non globales d'un système pour ensuite effectuer une mise à niveau standard vers une version de mise à jour ultérieure sur la zone globale, puis si vous utilisez la mise à jour lors du rattachement avec les zones non globales, les résultats ne sont pas les mêmes que si vous choisissez une mise à niveau standard du système dans son ensemble avec les zones attachées au moment de la mise à niveau. Tout nouveau package fourni avec la mise à jour n'est pas propagé vers les zones non globales attachées, sauf si au moins l'une des conditions suivantes se vérifie :

  • Les packages présentent le paramètre SUNW_PKG_ALLZONES=true.
  • Les packages fournissent des bits à un répertoire de packages hérité.
  • Un package qui présente le paramètre ALLZONES=true, qui est envoyé à un répertoire de packages hérité ou qui répond à ces deux conditions, dépend du nouveau package.

Les packages obsolètes ne sont pas supprimés, à moins qu'ils présentent le paramètre ALLZONES=true ou qu'ils soient déposés dans un répertoire de packages hérité.

La principale utilisation de la mise à jour lors du rattachement vise à migrer des zones non globales d'un système à l'autre avec une intervention minimale de l'utilisateur. Avant la version Solaris 10 10/08, les utilisateurs devaient s'assurer que la zone non globale attachée se trouvait au même niveau logiciel que le système où cette zone non globale était attachée. Grâce à la mise à jour de zones lors du rattachement, les administrateurs système peuvent désormais attacher une zone ayant un niveau de patch inférieur. La zone est automatiquement mise à jour au même niveau que les patchs de la zone globale à laquelle elle est attachée. En outre, les utilisateurs peuvent désormais migrer une zone non globale à partir d'un système sun4v vers un système sun4u ou à partir d'un système sun4u vers un système sun4v.

L'une des principales utilisations de la mise à jour lors du rattachement est la migration simple et rapide de conteneurs Solaris entre plusieurs systèmes (un conteneur est l'association d'une zone non globale et de contrôles de ressources). Exemple d'utilisation : un serveur Sun Fire T2000 exécute cinq conteneurs, chaque conteneur exécute à son tour une base de données particulière et la taille de l'une de ces bases de données augmente plus que prévu. Cela peut entraîner des problèmes de performances si les ressources système viennent à s'épuiser. S'il est impossible de migrer le conteneur affecté vers un système plus puissant, l'utilisateur final doit répliquer le conteneur, son logiciel et la configuration logicielle sur un autre système, puis basculer de l'ancien conteneur vers le nouveau. Toutefois, grâce à la migration de zone, cette tâche devient beaucoup plus simple, car le conteneur affecté peut désormais être déplacé, avec sa base de données, sa configuration et la charge de travail associée, vers un nouveau système, ce qui permet d'accroître les ressources disponibles pour ce conteneur et les quatre autres conteneurs de l'ancien système.

Application de patch et mise à jour de zones lors du rattachement

La possibilité d'utiliser la mise à jour lors du rattachement pour mettre les zones non globales au même niveau de patch que la zone globale a suscité beaucoup d'intérêt. Voici un exemple : avant d'appliquer un ensemble de patchs, un administrateur système pouvait détacher toutes les zones non globales, puis appliquer cet ensemble de patchs à la zone globale et enfin, une fois l'ensemble appliqué et le système réinitialisé, utiliser la commande de zone zoneadm -z <nomzone> attach -u pour mettre les zones non globales au même niveau de patch que la zone globale.

La mise à jour lors du rattachement est donc bien plus rapide que l'application de patchs en série sur des zones. De plus, plusieurs commandes zoneadm attach peuvent être lancées. Le principal problème est que selon les patchs appliqués dans la zone globale et selon la configuration des zones non globales par rapport aux répertoires de packages hérités, l'utilisation de la mise à jour lors du rattachement peut produire un résultat différent de celui obtenu si vous appliquez des patchs à la zone globale et aux zones non globales à l'aide de la commande patchadd lorsque toutes les zones non globales sont attachées.

Un exemple, bien qu'artificiel, peut s'avérer utile pour expliquer comment cela peut se produire. Si l'une des zones non globales est une zone whole root, et l'un des patchs en cours d'application est appliqué à Mozilla Firefox, par exemple le patch 125539-05, ce dernier sera alors appliqué à la zone globale, mais la mise à jour de zones lors du rattachement ne mettra pas à jour SUNWfirefox dans la zone non globale. Le patch 125539-05 ne sera pas appliqué dans la zone non globale.

En revanche, si vous utilisez patchadd avec la zone attachée, le patch 125539-05 sera appliqué à la zone non globale par patchadd. Cela est dû au fait que la migration d'une zone implique une planification différente de celle de la mise à niveau d'une zone. La décision de mettre à niveau les logiciels au niveau de l'application (dont SUNWfirefox est un exemple) revient uniquement à l'administrateur système. Par conséquent, la mise à jour de zones lors du rattachement ne met pas à jour les logiciels au niveau de l'application sans que l'administrateur système l'ait préalablement décidé. Par contre, une mise à niveau traditionnelle met à niveau tous les logiciels présents sur le support.

En outre, les packages fournis par le correctif des utilitaires de patch ne sont pas mis à jour dans une zone non globale whole root, à moins que SUNWupdatemgru ne soit installé. Dans les faits, sauf si SUNWupdatemgru est installé dans la zone non globale whole root, cela signifie que la zone risque d'être désynchronisée de la zone globale par rapport au correctif des utilitaires de patch 110254/119255 si une révision ultérieure venait à être installée sur cette zone globale.

Cela est dû au fait que les patches 119254/119255 sont appliqués aux packages SUNWswmt, SUNWinstall-patch-utils-root et SUNWpkgcmdsu, qui présentent tous le paramètre SUNW_PKG_ALLZONES=false. De plus, étant donné qu'il n'existe aucun répertoire de packages hérité dans une zone whole root, ces packages ne sont pas sélectionnés pour la mise à jour à moins que SUNWupdatemgru ne soit installé, car SUNWupdatemgru contient le paramètre SUNW_PKG_ALLZONES=true et dépend de SUNWswmt, qui à son tour dépend de SUNWinstall-patch-utils-root et de SUNWpkgcmds.

Par conséquent, SUNWswmt, SUNWinstall-patch-utils-root et SUNWpkgcmds sont sélectionnés, car SUNWupdatemgru dépend de SUNWswmt, qui à son tour dépend de SUNWinstall-patch-utils-root et de SUNWpkgcmds.

Normalement, SUNWupdatemgru se trouve dans le même métacluster d'installation que SUNWzoner et SUNWzoneu. Il est donc installé dans n'importe quelle zone non globale. Toutefois, si le système a été fourni en installant le métacluster minimum et les packages de zones ont été ajoutés par la suite, les packages des utilitaires de patch placés dans n'importe quelle zone non globale whole root ne sont pas mis à jour lors du rattachement, car SUNWupdatemgru n'est pas installé.

Tous les packages mis à jour sont d'abord supprimés d'une zone non globale, puis réinstallés à partir de la zone globale à l'aide de la même fonctionnalité que celle utilisée pour installer la zone pour la première fois. Cette fonctionnalité doit être modifiée dans une prochaine version de mise à jour de CR 6818813. Une fois le CR 6818813 résolu, tous les packages sélectionnés pour la mise à jour, dont la version correspond à celle du package installé dans la zone globale, ne sont pas supprimés et le package présent dans la zone non globale est simplement remplacé. Ceci devrait également accélérer les performances de mise à jour lors du rattachement.

Ainsi, la fonctionnalité utilisée pour l'installation initiale des zones sert également à la mise à jour lors du rattachement. Dans le cas de packages mis à jour, tous les packages undo.Z de patch sont hérités de la zone globale et déplacés vers la zone non globale attachée. Si de nombreux patchs ont été appliqués à la zone globale, cela peut entraîner l'augmentation de la taille de l'empreinte de l'espace sur la zone non globale attachée si celle-ci a été détachée d'un système auquel peu de patchs ont été appliqués (ou auquel aucun patch n'a été appliqué).

Si un utilisateur final a utilisé patchadd pour appliquer un patch à la zone globale et à toutes les zones non globales, undo.Z est généré au sein de chaque zone non globale en cours de mise à jour et contient uniquement les fichiers qui ont été remplacés dans cette zone non globale. Dans le cas d'une zone fragmentée, cela signifie que undo.Z, créé par patchadd, ne contient aucun fichier résidant sur /lib, /platform, /bin ou /sbin. Il est donc moins volumineux que undo.Z provenant de la zone globale héritée à l'aide de la fonctionnalité de mise à jour lors du rattachement.

Zone whole root ou zone sparse root

L'utilisation de la mise à jour lors du rattachement pour mettre à jour une zone sparse root, et non une zone whole root (ces deux zones ayant été fournies en même temps, sur le même système et possédant donc le même package et le même niveau de patch), entraîne une mise à jour différente pour ces deux zones en fonction du nombre de packages choisis pour la mise à jour. Ainsi, dans une zone sparse root créée sur le système d'exploitation Solaris 10 5/08 et mise à jour vers la version Solaris 10 10/08, 505 packages sont sélectionnés pour être mis à jour, alors que dans une zone whole root, 311 sont sélectionnés pour être mis à jour.

Avant d'utiliser la mise à jour de zones lors du rattachement pour accélérer l'application de patchs, vous devez d'abord connaître les différences entre l'utilisation de cette méthode de mise à jour pour mettre une zone non globale au même niveau de patch que la zone globale et l'utilisation de patchadd comportant toutes les zones non globales attachées et disponibles pour l'application des patchs.

Présence de patchs IDR (Interim Diagnostic Relief) et de patchs spéciaux

Si des patchs IDR fournis par Sun sont installés sur la zone non globale attachée, vous devez appliquer le même IDR à la zone globale cible ou le supprimer de la zone non globale source avant de détacher cette dernière. Pour résoudre ce problème et supprimer l'IDR lorsque la zone non globale est attachée, le système d'exploitation 10 5/09 utilise l'argument -b envoyé à la commande zoneadm attach.

En outre, la présence de patchs dits "spéciaux", car ils sont utilisés uniquement lors de la création d'images de la mise à jour de Solaris 10 et ne sont pas publiés, doit être résolue. Les patchs spéciaux sont traités par le CR 6743776 dans le patch de version actuel 140197. Une solution permanente de la gestion de ces patchs spéciaux est proposée dans le CR 6791625, qui est fourni dans les systèmes d'exploitation Solaris 10 5/09 dans le patch 139555-08.

Étapes pour l'exécution de la mise à jour lors du rattachement

1. Sur le système source, exécutez zoneadm -z <nomzone> detach. Remarque : la fonctionnalité de détachement (detach) a été introduite dans les systèmes d'exploitation Solaris 10 5/08.

2. Modifiez et orientez le chemin de la zone vers le système cible.

3. Si la zone globale cible ne se trouve pas au niveau de patch du noyau 139555 (Solaris 5/09 ou niveau de mise à jour ultérieure), exécutez la commande suivante pour entraîner la regénération des packages de zones non globales sources. Le CR concerné est le 6685069.

#rm <zonepath>/SUNWdetached.xml

4. Reconfigurez la zone en utilisant zonecfg sur le système cible.

5. Enfin, exécutez la commande suivante :

#zoneadm -z <zonename> attach -u

Veuillez consulter la section How to Migrate A Non-Global Zone (Migration d'une zone non globale) pour une description complète des étapes requises pour la migration d'une zone.

Les rapports d'erreurs dans Solaris 10 5/09 ont également été améliorés. Pour un package considéré comme rétrogradé (lorsque sa version dans la zone non globale attachée était supérieure à celle de la zone globale source à laquelle elle était attachée), les versions antérieures envoyaient un rapport pour chaque instance, individuellement. En d'autres termes, zoneadm attach -u ne signalait qu'une seule erreur à la fois. Dans la version du système d'exploitation Solaris 10 5/09, la première commande zoneadm attach -u envoie un rapport contenant toutes les erreurs.

Pour en savoir plus

Voici quelques ressources supplémentaires :


Comments (latest comments first)

Discuss and comment on this resource in the BigAdmin Wiki

Unless otherwise licensed, code in all technical manuals herein (including articles, FAQs, samples) is provided under this License.


BigAdmin