Fonction de mise à jour de zones lors du rattachement et application de patch sur le système d'exploitation Solaris 10Enda O'Connor River, juin 2009 PrésentationDepuis 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 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 à jourLorsque 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) :
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 :
Par exemple, pour la mise à jour de Exemple du point 3 ci-dessus : lorsqu'un package A présente le paramètre 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 Mise à jour lors du rattachement ou mise à niveau régulièreAvant 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, 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 obsolètes ne sont pas supprimés, à moins qu'ils présentent le paramètre 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 rattachementLa 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 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 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 En revanche, si vous utilisez 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 Cela est dû au fait que les patches 119254/119255 sont appliqués aux packages Par conséquent, Normalement, 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 Si un utilisateur final a utilisé Zone whole root ou zone sparse rootL'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 Présence de patchs IDR (Interim Diagnostic Relief) et de patchs spéciauxSi 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 rattachement1. Sur le système source, exécutez 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 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, Pour en savoir plusVoici 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 SubscriptionsBigAdmin Areas
BigAdmin Sun Center
BigAdmin Topics | ||||