Je me demandais quelle etait la tendance quant au passage de patches sur
un serveur UNIX. Si on suit strictement les READMEs (je suis sous
Solaris), certains patches *doivent* etre passes en single-user avec
reboot immediat. Mon but etant de minimiser l'arret de production sur
mes serveurs, j'aimerais avoir votre avis sur les risques encourus a
transgresser effrontement ces "lois".
Par exemple, que risque-je a passer un (ou plusieurs) patch kernel ou
libthread en mode multi user, sans prevenir personne, en planifiant de
rebooter quand j'aurais le temps ?
Le serveur est-il stable entre l'application des patches "critiques" et
le reboot ?
Et avec 200 patches ?
Je sais que beaucoup d'admins passent leurs patches a la volee, les
accumulent, et rebootent longtemps apres. C'est evidemment tres pratique
et ca augmente l'uptime, mais est-ce vraiment risque ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Rakotomandimby Mihamina
Swaz wrote:
Bonjour,
Bonjour Je te donne mon contexte : Je suis encore un petit etudiant, et bon ... bref l'obligation de disponibilite d'un serveur a 99.999% , je ne l'ai pas .
Le serveur est-il stable entre l'application des patches "critiques" et le reboot ?
patches critiques , a mon avis oui ... mais tout depends de ce qu'on appelle critique .
Et avec 200 patches ?
c'est carrement une mise a jour de tout le systeme la ...
Tant que je sache , certains binaires sont charges en RAM pour ne plus y etre deloges ... si tu applique les patches, c'est a leur copie situee sur le disque dur .... il y a des chances pour que ce patche ne soit pas pris en compte .
Si ton patch fais varier la taille du binaire ( ce qui est quasiment sur ) le systeme peut ne pas etre au courant du changement de taille dudit binaire , et donc peut planter en tentant de le charger Si au boot precedent le systeme s'est informe de la taille de ce fichier et que tu le patche Et que le systeme m'en est pas informe ...
Je sais que beaucoup d'admins passent leurs patches a la volee, les accumulent, et rebootent longtemps apres. C'est evidemment tres pratique et ca augmente l'uptime, mais est-ce vraiment risque ?
Il y a un risque qui evidemment est tres relatif. Ton serveur est vraiment tres sollicite 24/24 ?
Bonjour
Je te donne mon contexte : Je suis encore un petit etudiant, et bon ...
bref l'obligation de disponibilite d'un serveur a 99.999% , je ne l'ai pas .
Le serveur est-il stable entre l'application des patches "critiques" et
le reboot ?
patches critiques , a mon avis oui ... mais tout depends de ce qu'on
appelle critique .
Et avec 200 patches ?
c'est carrement une mise a jour de tout le systeme la ...
Tant que je sache , certains binaires sont charges en RAM pour ne plus y
etre deloges ... si tu applique les patches, c'est a leur copie situee
sur le disque dur .... il y a des chances pour que ce patche ne soit pas
pris en compte .
Si ton patch fais varier la taille du binaire ( ce qui est quasiment sur
) le systeme peut ne pas etre au courant du changement de taille dudit
binaire , et donc peut planter en tentant de le charger
Si au boot precedent le systeme s'est informe de la taille de ce fichier
et que tu le patche
Et que le systeme m'en est pas informe ...
Je sais que beaucoup d'admins passent leurs patches a la volee, les
accumulent, et rebootent longtemps apres. C'est evidemment tres pratique
et ca augmente l'uptime, mais est-ce vraiment risque ?
Il y a un risque qui evidemment est tres relatif.
Ton serveur est vraiment tres sollicite 24/24 ?
Bonjour Je te donne mon contexte : Je suis encore un petit etudiant, et bon ... bref l'obligation de disponibilite d'un serveur a 99.999% , je ne l'ai pas .
Le serveur est-il stable entre l'application des patches "critiques" et le reboot ?
patches critiques , a mon avis oui ... mais tout depends de ce qu'on appelle critique .
Et avec 200 patches ?
c'est carrement une mise a jour de tout le systeme la ...
Tant que je sache , certains binaires sont charges en RAM pour ne plus y etre deloges ... si tu applique les patches, c'est a leur copie situee sur le disque dur .... il y a des chances pour que ce patche ne soit pas pris en compte .
Si ton patch fais varier la taille du binaire ( ce qui est quasiment sur ) le systeme peut ne pas etre au courant du changement de taille dudit binaire , et donc peut planter en tentant de le charger Si au boot precedent le systeme s'est informe de la taille de ce fichier et que tu le patche Et que le systeme m'en est pas informe ...
Je sais que beaucoup d'admins passent leurs patches a la volee, les accumulent, et rebootent longtemps apres. C'est evidemment tres pratique et ca augmente l'uptime, mais est-ce vraiment risque ?
Il y a un risque qui evidemment est tres relatif. Ton serveur est vraiment tres sollicite 24/24 ?
OoO Lors de la soirée naissante du lundi 19 avril 2004, vers 18:15, Rakotomandimby Mihamina disait:
Si ton patch fais varier la taille du binaire ( ce qui est quasiment sur ) le systeme peut ne pas etre au courant du changement de taille dudit binaire , et donc peut planter en tentant de le charger Si au boot precedent le systeme s'est informe de la taille de ce fichier et que tu le patche Et que le systeme m'en est pas informe ...
Cela ne fonctionne pas comme ça. Si le fichier original n'existe plus sur le disque, son contenu est conservé en mémoire. Il y a donc juste une hausse de consommation mémoire puisque l'on doit parfois conserver le nouveau et l'ancien en mémoire (cas des librairies par exemple). -- panic("Lucy in the sky...."); 2.2.16 /usr/src/linux/arch/sparc64/kernel/starfire.c
OoO Lors de la soirée naissante du lundi 19 avril 2004, vers 18:15,
Rakotomandimby Mihamina <rktmb.tontolo@wanadoo.fr> disait:
Si ton patch fais varier la taille du binaire ( ce qui est quasiment
sur ) le systeme peut ne pas etre au courant du changement de taille
dudit binaire , et donc peut planter en tentant de le charger
Si au boot precedent le systeme s'est informe de la taille de ce
fichier et que tu le patche
Et que le systeme m'en est pas informe ...
Cela ne fonctionne pas comme ça. Si le fichier original n'existe plus
sur le disque, son contenu est conservé en mémoire. Il y a donc juste
une hausse de consommation mémoire puisque l'on doit parfois conserver
le nouveau et l'ancien en mémoire (cas des librairies par exemple).
--
panic("Lucy in the sky....");
2.2.16 /usr/src/linux/arch/sparc64/kernel/starfire.c
OoO Lors de la soirée naissante du lundi 19 avril 2004, vers 18:15, Rakotomandimby Mihamina disait:
Si ton patch fais varier la taille du binaire ( ce qui est quasiment sur ) le systeme peut ne pas etre au courant du changement de taille dudit binaire , et donc peut planter en tentant de le charger Si au boot precedent le systeme s'est informe de la taille de ce fichier et que tu le patche Et que le systeme m'en est pas informe ...
Cela ne fonctionne pas comme ça. Si le fichier original n'existe plus sur le disque, son contenu est conservé en mémoire. Il y a donc juste une hausse de consommation mémoire puisque l'on doit parfois conserver le nouveau et l'ancien en mémoire (cas des librairies par exemple). -- panic("Lucy in the sky...."); 2.2.16 /usr/src/linux/arch/sparc64/kernel/starfire.c
Laurent Wacrenier
Swaz écrit:
Par exemple, que risque-je a passer un (ou plusieurs) patch kernel ou libthread en mode multi user, sans prevenir personne, en planifiant de rebooter quand j'aurais le temps ?
Heu.. ça ne sert à rien de faire un patch noyau et de ne pas rebooter. Pour une librairie, les applications déjà lancées n'en bénéficieront pas. Il faut donc les relancer à la main ou escompter qu'elles vont terminer bientôt normalement.
En général, tout peut arriver. Il se par exemple peut que des applis plantent toutes seules si le système est inconsistant.
Je sais que beaucoup d'admins passent leurs patches a la volee, les accumulent, et rebootent longtemps apres. C'est evidemment tres pratique et ca augmente l'uptime, mais est-ce vraiment risque ?
Installez donc un patch pour mettre l'uptime à ce que vous voulez.
Le gros problème en retardant le reboot après des palanquées de patchs, c'est qu'on est pas sûr que ça redémarre proprement après un arrêt brutal.
Swaz <seb.wazzup@libertysurf.fr> écrit:
Par exemple, que risque-je a passer un (ou plusieurs) patch kernel ou
libthread en mode multi user, sans prevenir personne, en planifiant de
rebooter quand j'aurais le temps ?
Heu.. ça ne sert à rien de faire un patch noyau et de ne pas rebooter.
Pour une librairie, les applications déjà lancées n'en bénéficieront
pas. Il faut donc les relancer à la main ou escompter qu'elles vont
terminer bientôt normalement.
En général, tout peut arriver. Il se par exemple peut que des applis
plantent toutes seules si le système est inconsistant.
Je sais que beaucoup d'admins passent leurs patches a la volee, les
accumulent, et rebootent longtemps apres. C'est evidemment tres pratique
et ca augmente l'uptime, mais est-ce vraiment risque ?
Installez donc un patch pour mettre l'uptime à ce que vous voulez.
Le gros problème en retardant le reboot après des palanquées de
patchs, c'est qu'on est pas sûr que ça redémarre proprement après un
arrêt brutal.
Par exemple, que risque-je a passer un (ou plusieurs) patch kernel ou libthread en mode multi user, sans prevenir personne, en planifiant de rebooter quand j'aurais le temps ?
Heu.. ça ne sert à rien de faire un patch noyau et de ne pas rebooter. Pour une librairie, les applications déjà lancées n'en bénéficieront pas. Il faut donc les relancer à la main ou escompter qu'elles vont terminer bientôt normalement.
En général, tout peut arriver. Il se par exemple peut que des applis plantent toutes seules si le système est inconsistant.
Je sais que beaucoup d'admins passent leurs patches a la volee, les accumulent, et rebootent longtemps apres. C'est evidemment tres pratique et ca augmente l'uptime, mais est-ce vraiment risque ?
Installez donc un patch pour mettre l'uptime à ce que vous voulez.
Le gros problème en retardant le reboot après des palanquées de patchs, c'est qu'on est pas sûr que ça redémarre proprement après un arrêt brutal.
Fabrice..Bacchella
On Mon, 19 Apr 2004 18:15:54 +0200, Rakotomandimby Mihamina wrote:
Swaz wrote:
Bonjour,
Bonjour Je te donne mon contexte : Je suis encore un petit etudiant, et bon ... bref l'obligation de disponibilite d'un serveur a 99.999% , je ne l'ai pas .
Le serveur est-il stable entre l'application des patches "critiques" et le reboot ?
patches critiques , a mon avis oui ... mais tout depends de ce qu'on appelle critique .
Et avec 200 patches ?
c'est carrement une mise a jour de tout le systeme la ...
Tant que je sache , certains binaires sont charges en RAM pour ne plus y etre deloges ... si tu applique les patches, c'est a leur copie situee sur le disque dur .... il y a des chances pour que ce patche ne soit pas pris en compte .
Si ton patch fais varier la taille du binaire ( ce qui est quasiment sur ) le systeme peut ne pas etre au courant du changement de taille dudit binaire , et donc peut planter en tentant de le charger Si au boot precedent le systeme s'est informe de la taille de ce fichier et que tu le patche Et que le systeme m'en est pas informe ...
Sous Unix, quand un fichier est ouvert, il reste accessible par le programme qui l'utilise, même s'il est effacé. Si un fichier est modifié, l'OS va s'en rendre compte et l'image mémoire sera mise à jour. S'il s'agit d'un exécutable, clairement on part alors dans l'inconnu le plus total : le code ne correspond plus.
Contrairement à ce qui a été dit dans un autre message, ce n'est pas la consommation mémoire qui est doublé, mais la consommation disque. Les deux fichiers sont conservés sur le disque. L'un accessible normalement. L'autre uniquement par le processus l'ayant ouvert ou éventuellement par son inode. Dès que le file descriptor est fermé, l'ancien fichier disparaît, son inode est libéré, il devient totalement inaccessible.
Aussi bien dans une librairie que dans un binaire, un fichier est caché en mémoire par page de taille fixe, généralement 4ko ou 8ko. Seul les pages actives de la dernière version du fichier sont présentes en mémoire. Donc il y n'y a pas un usage double de la mémoire mais un doublon sur certaines pages du code qui sont présentes deux fois au lieu d'une. Car effectivement les pages de codes sont partagés entre processus. Par contre, jamais le contenu d'un fichier effacé n'est conservé en mémoire.
Donc une procédure de patch bien faite va d'abord effacer un fichier avant de le patcher pour éviter le problème que vous décrivez. Je pense que c'est la procédure appliquée par Sun. En effet certains patches impliquant la mise à jour de librairies, comme les librairies C++, ne nécessitent aucune précaution particulière.
Bonjour
Je te donne mon contexte : Je suis encore un petit etudiant, et bon ...
bref l'obligation de disponibilite d'un serveur a 99.999% , je ne l'ai pas .
Le serveur est-il stable entre l'application des patches "critiques" et
le reboot ?
patches critiques , a mon avis oui ... mais tout depends de ce qu'on
appelle critique .
Et avec 200 patches ?
c'est carrement une mise a jour de tout le systeme la ...
Tant que je sache , certains binaires sont charges en RAM pour ne plus y
etre deloges ... si tu applique les patches, c'est a leur copie situee
sur le disque dur .... il y a des chances pour que ce patche ne soit pas
pris en compte .
Si ton patch fais varier la taille du binaire ( ce qui est quasiment sur
) le systeme peut ne pas etre au courant du changement de taille dudit
binaire , et donc peut planter en tentant de le charger
Si au boot precedent le systeme s'est informe de la taille de ce fichier
et que tu le patche
Et que le systeme m'en est pas informe ...
Sous Unix, quand un fichier est ouvert, il reste accessible par le
programme qui l'utilise, même s'il est effacé.
Si un fichier est modifié, l'OS va s'en rendre compte et l'image
mémoire sera mise à jour. S'il s'agit d'un exécutable, clairement on
part alors dans l'inconnu le plus total : le code ne correspond plus.
Contrairement à ce qui a été dit dans un autre message, ce n'est pas
la consommation mémoire qui est doublé, mais la consommation disque.
Les deux fichiers sont conservés sur le disque. L'un accessible
normalement. L'autre uniquement par le processus l'ayant ouvert ou
éventuellement par son inode. Dès que le file descriptor est fermé,
l'ancien fichier disparaît, son inode est libéré, il devient
totalement inaccessible.
Aussi bien dans une librairie que dans un binaire, un fichier est
caché en mémoire par page de taille fixe, généralement 4ko ou 8ko.
Seul les pages actives de la dernière version du fichier sont
présentes en mémoire. Donc il y n'y a pas un usage double de la
mémoire mais un doublon sur certaines pages du code qui sont présentes
deux fois au lieu d'une. Car effectivement les pages de codes sont
partagés entre processus. Par contre, jamais le contenu d'un fichier
effacé n'est conservé en mémoire.
Donc une procédure de patch bien faite va d'abord effacer un fichier
avant de le patcher pour éviter le problème que vous décrivez.
Je pense que c'est la procédure appliquée par Sun. En effet certains
patches impliquant la mise à jour de librairies, comme les librairies
C++, ne nécessitent aucune précaution particulière.
On Mon, 19 Apr 2004 18:15:54 +0200, Rakotomandimby Mihamina wrote:
Swaz wrote:
Bonjour,
Bonjour Je te donne mon contexte : Je suis encore un petit etudiant, et bon ... bref l'obligation de disponibilite d'un serveur a 99.999% , je ne l'ai pas .
Le serveur est-il stable entre l'application des patches "critiques" et le reboot ?
patches critiques , a mon avis oui ... mais tout depends de ce qu'on appelle critique .
Et avec 200 patches ?
c'est carrement une mise a jour de tout le systeme la ...
Tant que je sache , certains binaires sont charges en RAM pour ne plus y etre deloges ... si tu applique les patches, c'est a leur copie situee sur le disque dur .... il y a des chances pour que ce patche ne soit pas pris en compte .
Si ton patch fais varier la taille du binaire ( ce qui est quasiment sur ) le systeme peut ne pas etre au courant du changement de taille dudit binaire , et donc peut planter en tentant de le charger Si au boot precedent le systeme s'est informe de la taille de ce fichier et que tu le patche Et que le systeme m'en est pas informe ...
Sous Unix, quand un fichier est ouvert, il reste accessible par le programme qui l'utilise, même s'il est effacé. Si un fichier est modifié, l'OS va s'en rendre compte et l'image mémoire sera mise à jour. S'il s'agit d'un exécutable, clairement on part alors dans l'inconnu le plus total : le code ne correspond plus.
Contrairement à ce qui a été dit dans un autre message, ce n'est pas la consommation mémoire qui est doublé, mais la consommation disque. Les deux fichiers sont conservés sur le disque. L'un accessible normalement. L'autre uniquement par le processus l'ayant ouvert ou éventuellement par son inode. Dès que le file descriptor est fermé, l'ancien fichier disparaît, son inode est libéré, il devient totalement inaccessible.
Aussi bien dans une librairie que dans un binaire, un fichier est caché en mémoire par page de taille fixe, généralement 4ko ou 8ko. Seul les pages actives de la dernière version du fichier sont présentes en mémoire. Donc il y n'y a pas un usage double de la mémoire mais un doublon sur certaines pages du code qui sont présentes deux fois au lieu d'une. Car effectivement les pages de codes sont partagés entre processus. Par contre, jamais le contenu d'un fichier effacé n'est conservé en mémoire.
Donc une procédure de patch bien faite va d'abord effacer un fichier avant de le patcher pour éviter le problème que vous décrivez. Je pense que c'est la procédure appliquée par Sun. En effet certains patches impliquant la mise à jour de librairies, comme les librairies C++, ne nécessitent aucune précaution particulière.
--- http://fba.homeip.net
Vincent Bernat
OoO En cette nuit nuageuse du mardi 20 avril 2004, vers 00:16, Fabrice..Bacchella disait:
Contrairement à ce qui a été dit dans un autre message, ce n'est pas la consommation mémoire qui est doublé, mais la consommation disque. Les deux fichiers sont conservés sur le disque. L'un accessible normalement. L'autre uniquement par le processus l'ayant ouvert ou éventuellement par son inode. Dès que le file descriptor est fermé, l'ancien fichier disparaît, son inode est libéré, il devient totalement inaccessible.
Exact, je me suis mélangé les pinceaux. -- I WILL NOT PLEDGE ALLEGIANCE TO BART I WILL NOT PLEDGE ALLEGIANCE TO BART I WILL NOT PLEDGE ALLEGIANCE TO BART -+- Bart Simpson on chalkboard in episode 7F09
OoO En cette nuit nuageuse du mardi 20 avril 2004, vers 00:16,
Fabrice..Bacchella <nobody@worldonline.france> disait:
Contrairement à ce qui a été dit dans un autre message, ce n'est pas
la consommation mémoire qui est doublé, mais la consommation disque.
Les deux fichiers sont conservés sur le disque. L'un accessible
normalement. L'autre uniquement par le processus l'ayant ouvert ou
éventuellement par son inode. Dès que le file descriptor est fermé,
l'ancien fichier disparaît, son inode est libéré, il devient
totalement inaccessible.
Exact, je me suis mélangé les pinceaux.
--
I WILL NOT PLEDGE ALLEGIANCE TO BART
I WILL NOT PLEDGE ALLEGIANCE TO BART
I WILL NOT PLEDGE ALLEGIANCE TO BART
-+- Bart Simpson on chalkboard in episode 7F09
OoO En cette nuit nuageuse du mardi 20 avril 2004, vers 00:16, Fabrice..Bacchella disait:
Contrairement à ce qui a été dit dans un autre message, ce n'est pas la consommation mémoire qui est doublé, mais la consommation disque. Les deux fichiers sont conservés sur le disque. L'un accessible normalement. L'autre uniquement par le processus l'ayant ouvert ou éventuellement par son inode. Dès que le file descriptor est fermé, l'ancien fichier disparaît, son inode est libéré, il devient totalement inaccessible.
Exact, je me suis mélangé les pinceaux. -- I WILL NOT PLEDGE ALLEGIANCE TO BART I WILL NOT PLEDGE ALLEGIANCE TO BART I WILL NOT PLEDGE ALLEGIANCE TO BART -+- Bart Simpson on chalkboard in episode 7F09
Swaz
Laurent Wacrenier tint à peu près ce langage :
Installez donc un patch pour mettre l'uptime à ce que vous voulez. :) et j'expliquerais ensuite a mes utilisateurs que, l'uptime faisant
foi, leur deconnection pour cause de reboot etait une hallucination.
Plus serieusement, que penser particulierement des reboots multiples lors de l'application des patches ? Certains READMEs recommandent un reboot *immediatement* apres l'application du patch, ce qui sur un cluster important peur mener a un nombre consequent de reboots.
Est-ce vraiment risque de ne rebooter qu'une fois le cluster entier passe ? On n'a de toute facon *que* ce choix quand on applique les clusters de Sun. Et comme ca peut prendre 2 bonnes heures, ca fait un laps de temps pendant lequel le systeme est dans un etat imprevisible.
J'ai egalement plusieurs patches (d'un cluster maison) qui demandent un boot -r, un seul boot -r a la fin du cluster est-il suffisant ?
Merci pour vos remarques pertinentes et humoristiques, passees et a venir.
Seb.
Laurent Wacrenier tint à peu près ce langage :
Installez donc un patch pour mettre l'uptime à ce que vous voulez.
:) et j'expliquerais ensuite a mes utilisateurs que, l'uptime faisant
foi, leur deconnection pour cause de reboot etait une hallucination.
Plus serieusement, que penser particulierement des reboots multiples
lors de l'application des patches ? Certains READMEs recommandent un
reboot *immediatement* apres l'application du patch, ce qui sur un
cluster important peur mener a un nombre consequent de reboots.
Est-ce vraiment risque de ne rebooter qu'une fois le cluster entier
passe ? On n'a de toute facon *que* ce choix quand on applique les
clusters de Sun. Et comme ca peut prendre 2 bonnes heures, ca fait un
laps de temps pendant lequel le systeme est dans un etat imprevisible.
J'ai egalement plusieurs patches (d'un cluster maison) qui demandent un
boot -r, un seul boot -r a la fin du cluster est-il suffisant ?
Merci pour vos remarques pertinentes et humoristiques, passees et a
venir.
Installez donc un patch pour mettre l'uptime à ce que vous voulez. :) et j'expliquerais ensuite a mes utilisateurs que, l'uptime faisant
foi, leur deconnection pour cause de reboot etait une hallucination.
Plus serieusement, que penser particulierement des reboots multiples lors de l'application des patches ? Certains READMEs recommandent un reboot *immediatement* apres l'application du patch, ce qui sur un cluster important peur mener a un nombre consequent de reboots.
Est-ce vraiment risque de ne rebooter qu'une fois le cluster entier passe ? On n'a de toute facon *que* ce choix quand on applique les clusters de Sun. Et comme ca peut prendre 2 bonnes heures, ca fait un laps de temps pendant lequel le systeme est dans un etat imprevisible.
J'ai egalement plusieurs patches (d'un cluster maison) qui demandent un boot -r, un seul boot -r a la fin du cluster est-il suffisant ?
Merci pour vos remarques pertinentes et humoristiques, passees et a venir.
Seb.
Laurent Wacrenier
Swaz écrit:
Installez donc un patch pour mettre l'uptime à ce que vous voulez. :) et j'expliquerais ensuite a mes utilisateurs que, l'uptime faisant
foi, leur deconnection pour cause de reboot etait une hallucination.
Prévoyez un jour de maintenance fixe dans la semaine, annoncez le, et ne faites vos maintenances lourdes que ce jour là.
Plus serieusement, que penser particulierement des reboots multiples lors de l'application des patches ? Certains READMEs recommandent un reboot *immediatement* apres l'application du patch, ce qui sur un cluster important peur mener a un nombre consequent de reboots.
L'arrêt n'est pas toujours nessessaire et bien souvent les arrêts devraients pouvoir être regroupés. C'est selon le patch, vos applications, et votre capacité à gérer plusieurs choses en parallele.
Par exemple, s'il y a un patch de sécurité sur une application qui ne sert jamais, appliquez le patch mais inutile de rebooter (regardez quand même quels fichiers sont patchés).
Est-ce vraiment risque de ne rebooter qu'une fois le cluster entier passe ? On n'a de toute facon *que* ce choix quand on applique les clusters de Sun. Et comme ca peut prendre 2 bonnes heures, ca fait un laps de temps pendant lequel le systeme est dans un etat imprevisible.
J'ai egalement plusieurs patches (d'un cluster maison) qui demandent un boot -r, un seul boot -r a la fin du cluster est-il suffisant ?
En mode mono utilisateur, la résulat est déterministe, c'est l'interêt principal. Pour avoir cette propriété sur un cluster, je présume qu'il faut arreter et patcher tous les serveurs les uns après les autres et redamarrer le tout.
Swaz <seb.wazzup@libertysurf.fr> écrit:
Installez donc un patch pour mettre l'uptime à ce que vous voulez.
:) et j'expliquerais ensuite a mes utilisateurs que, l'uptime faisant
foi, leur deconnection pour cause de reboot etait une hallucination.
Prévoyez un jour de maintenance fixe dans la semaine, annoncez le, et
ne faites vos maintenances lourdes que ce jour là.
Plus serieusement, que penser particulierement des reboots multiples
lors de l'application des patches ? Certains READMEs recommandent un
reboot *immediatement* apres l'application du patch, ce qui sur un
cluster important peur mener a un nombre consequent de reboots.
L'arrêt n'est pas toujours nessessaire et bien souvent les arrêts
devraients pouvoir être regroupés. C'est selon le patch, vos
applications, et votre capacité à gérer plusieurs choses en parallele.
Par exemple, s'il y a un patch de sécurité sur une application qui ne
sert jamais, appliquez le patch mais inutile de rebooter (regardez
quand même quels fichiers sont patchés).
Est-ce vraiment risque de ne rebooter qu'une fois le cluster entier
passe ? On n'a de toute facon *que* ce choix quand on applique les
clusters de Sun. Et comme ca peut prendre 2 bonnes heures, ca fait un
laps de temps pendant lequel le systeme est dans un etat imprevisible.
J'ai egalement plusieurs patches (d'un cluster maison) qui demandent un
boot -r, un seul boot -r a la fin du cluster est-il suffisant ?
En mode mono utilisateur, la résulat est déterministe, c'est l'interêt
principal. Pour avoir cette propriété sur un cluster, je présume qu'il
faut arreter et patcher tous les serveurs les uns après les autres et
redamarrer le tout.
Installez donc un patch pour mettre l'uptime à ce que vous voulez. :) et j'expliquerais ensuite a mes utilisateurs que, l'uptime faisant
foi, leur deconnection pour cause de reboot etait une hallucination.
Prévoyez un jour de maintenance fixe dans la semaine, annoncez le, et ne faites vos maintenances lourdes que ce jour là.
Plus serieusement, que penser particulierement des reboots multiples lors de l'application des patches ? Certains READMEs recommandent un reboot *immediatement* apres l'application du patch, ce qui sur un cluster important peur mener a un nombre consequent de reboots.
L'arrêt n'est pas toujours nessessaire et bien souvent les arrêts devraients pouvoir être regroupés. C'est selon le patch, vos applications, et votre capacité à gérer plusieurs choses en parallele.
Par exemple, s'il y a un patch de sécurité sur une application qui ne sert jamais, appliquez le patch mais inutile de rebooter (regardez quand même quels fichiers sont patchés).
Est-ce vraiment risque de ne rebooter qu'une fois le cluster entier passe ? On n'a de toute facon *que* ce choix quand on applique les clusters de Sun. Et comme ca peut prendre 2 bonnes heures, ca fait un laps de temps pendant lequel le systeme est dans un etat imprevisible.
J'ai egalement plusieurs patches (d'un cluster maison) qui demandent un boot -r, un seul boot -r a la fin du cluster est-il suffisant ?
En mode mono utilisateur, la résulat est déterministe, c'est l'interêt principal. Pour avoir cette propriété sur un cluster, je présume qu'il faut arreter et patcher tous les serveurs les uns après les autres et redamarrer le tout.
Ollivier Robert
[copie de cet article par courrier électronique]
Dans l'article , Swaz disait :
Plus serieusement, que penser particulierement des reboots multiples lors de l'application des patches ? Certains READMEs recommandent un reboot *immediatement* apres l'application du patch, ce qui sur un cluster important peur mener a un nombre consequent de reboots.
Mon expérience HP-UX montre que lors de l'installation d'un « bundle » de patches, il va refaire son noyau plusieurs fois mais ne redémarrer qu'une seule fois à la fin.
Ce qui est le « bon » comportement à mon avis, à moins qu'il y ait un changement tel dans un patch noyau qu'il faille redémarrer de suite. C'est plutôt rare.
J'ai egalement plusieurs patches (d'un cluster maison) qui demandent un boot -r, un seul boot -r a la fin du cluster est-il suffisant ?
boot -r étant pour rebâtir /devices, ça devrait suffire. -- Ollivier ROBERT -=- Eurocontrol EEC -=- FreeBSD : <URL:http://www.FreeBSD.org/> The Power to Serve!
[copie de cet article par courrier électronique]
Dans l'article <20040420100826.363acf29@pascal.infobiogen.fr>,
Swaz <seb.wazzup@libertysurf.fr> disait :
Plus serieusement, que penser particulierement des reboots multiples
lors de l'application des patches ? Certains READMEs recommandent un
reboot *immediatement* apres l'application du patch, ce qui sur un
cluster important peur mener a un nombre consequent de reboots.
Mon expérience HP-UX montre que lors de l'installation d'un « bundle » de
patches, il va refaire son noyau plusieurs fois mais ne redémarrer qu'une
seule fois à la fin.
Ce qui est le « bon » comportement à mon avis, à moins qu'il y ait un
changement tel dans un patch noyau qu'il faille redémarrer de suite. C'est
plutôt rare.
J'ai egalement plusieurs patches (d'un cluster maison) qui demandent un
boot -r, un seul boot -r a la fin du cluster est-il suffisant ?
boot -r étant pour rebâtir /devices, ça devrait suffire.
--
Ollivier ROBERT -=- Eurocontrol EEC -=- ollivier.robert@eurocontrol.int
FreeBSD : <URL:http://www.FreeBSD.org/> The Power to Serve!
Plus serieusement, que penser particulierement des reboots multiples lors de l'application des patches ? Certains READMEs recommandent un reboot *immediatement* apres l'application du patch, ce qui sur un cluster important peur mener a un nombre consequent de reboots.
Mon expérience HP-UX montre que lors de l'installation d'un « bundle » de patches, il va refaire son noyau plusieurs fois mais ne redémarrer qu'une seule fois à la fin.
Ce qui est le « bon » comportement à mon avis, à moins qu'il y ait un changement tel dans un patch noyau qu'il faille redémarrer de suite. C'est plutôt rare.
J'ai egalement plusieurs patches (d'un cluster maison) qui demandent un boot -r, un seul boot -r a la fin du cluster est-il suffisant ?
boot -r étant pour rebâtir /devices, ça devrait suffire. -- Ollivier ROBERT -=- Eurocontrol EEC -=- FreeBSD : <URL:http://www.FreeBSD.org/> The Power to Serve!
manu
Swaz wrote:
Je me demandais quelle etait la tendance quant au passage de patches sur un serveur UNIX. Si on suit strictement les READMEs (je suis sous Solaris), certains patches *doivent* etre passes en single-user avec reboot immediat. Mon but etant de minimiser l'arret de production sur mes serveurs, j'aimerais avoir votre avis sur les risques encourus a transgresser effrontement ces "lois".
Disons qu'en passant tout d'un coup en single-user suivi d'un eventuel reboot, ca doit plutot bien se passer.
Mais bon... le nombre de patches qu'il faut appliquer sur cers systèmes est absolument hallucinant. C'est pas aussi délirant que Windows, mais quand même...
-- Emmanuel Dreyfus Un bouquin en français sur BSD: http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
Swaz <seb.wazzup@libertysurf.fr> wrote:
Je me demandais quelle etait la tendance quant au passage de patches sur
un serveur UNIX. Si on suit strictement les READMEs (je suis sous
Solaris), certains patches *doivent* etre passes en single-user avec
reboot immediat. Mon but etant de minimiser l'arret de production sur
mes serveurs, j'aimerais avoir votre avis sur les risques encourus a
transgresser effrontement ces "lois".
Disons qu'en passant tout d'un coup en single-user suivi d'un eventuel
reboot, ca doit plutot bien se passer.
Mais bon... le nombre de patches qu'il faut appliquer sur cers systèmes
est absolument hallucinant. C'est pas aussi délirant que Windows, mais
quand même...
--
Emmanuel Dreyfus
Un bouquin en français sur BSD:
http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
manu@netbsd.org
Je me demandais quelle etait la tendance quant au passage de patches sur un serveur UNIX. Si on suit strictement les READMEs (je suis sous Solaris), certains patches *doivent* etre passes en single-user avec reboot immediat. Mon but etant de minimiser l'arret de production sur mes serveurs, j'aimerais avoir votre avis sur les risques encourus a transgresser effrontement ces "lois".
Disons qu'en passant tout d'un coup en single-user suivi d'un eventuel reboot, ca doit plutot bien se passer.
Mais bon... le nombre de patches qu'il faut appliquer sur cers systèmes est absolument hallucinant. C'est pas aussi délirant que Windows, mais quand même...
-- Emmanuel Dreyfus Un bouquin en français sur BSD: http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
