La salle serveur de mon entreprise bénéficie d'une alimentation électrique et d'une climatisation totalement indépendantes du reste des bureaux.
L'alimentation électrique est déjà régulée et filtrée en amont, contrairement au reste du batiment.

Mais, en cas de coupure électrique, seul un onduleur général est capable d'assurer le relais.
Il s'agit d'un onduleur de marque SOCOMEC SICON, d'une puissance de 14.000 VA qui alimente toute la salle serveur et mon bureau.
Dans la salle serveur se trouve le rack où sont empilés 5 serveurs critiques pour l'entreprise. En dehors du rack, on trouve 1 autre serveur moins critique (antivirus réseau, TrendMicro Client/serveur), la baie de brassage comprenant 6 switches de 16 à 48 ports 10/100 Mbits, les différents routeurs permettant la connexion à nos usines et à Internet, le module de GTB, le PABX et quelques PC's destinés à l'administration.
Dans mon bureau, suivant les périodes et les arrivées de matériel neuf et/ou de matériel à dépanner, il y a entre 2 et parfois 12 PC connectés ...
Voilà pourquoi une telle puissance est nécessaire, afin de pouvoir conserver une autonomie d'au moins 30 minutes.

Lors de la dernière coupure EDF, il y a quelques mois, je me suis rendu compte grâce au système de monitoring et de supervision de l'onduleur, Net Vision, je me suis rendu compte que lors de la coupure l'autonomie annoncée était légèrement supérieure à 30 minutes, puis au bout de 3/4 minutes descendait en flèche .... :hein:
Les batteries ayant 3 ans, cette autonomie se situait en fait maintenant entre 7 et 10 minutes, alors que la charge de l'onduleur est comprise entre 20 et 30 % suivant le nombre d'appareils connectés ...

Il a donc fallu se décider à procéder au remplacement des batteries incorporées à cet onduleur. Mais pour cela, il fallait éteindre tous les serveurs et toute la baie de brassage.
Chose impossible à faire en temps normal, lorsque que les 120/130 PC's du Siège Social et les 13 usines de production sont en service ... Cela équivaudrait à mettre au chômage technique presque 440 personnes (330 pour mon entreprise et 110 pour notre partenaire qui est interconnecté sur notre réseau de même que ses 3 usines ... plus d'infos concernant notre partenariat sur ce billet)

L'avantage dans les métiers du bâtiment, c'est que les congés sont toujours à période fixe (au mois d'Août et entre Noël et le 1er de l'An) et entrainent la fermeture complète des locaux. Ce qui me facilite la tâche ... mais me fait perdre un peu de mes congés si précieux :P
Avant de passer à l'acte, j'ai donc prévenu par mail tous les utilisateurs susceptibles de se connecter au réseau que ce soit par modem, par ADSL/SDSL ou par carte GPRS/UMTS.



J'ai donc sacrifié ma matinée pour me rendre au bureau, arrêter toute la machinerie et procéder au remplacement de ces fameuses 30 batteries ...

Avant d'arrêter tous les serveurs se trouvant dans le rack ainsi que tout le reste du matériel, j'ai jeté un oeil sur leur uptime, le temps qui s'est écoulé depuis leur dernier re-démarrage ...



La photo ci-dessus n'est pas à jour, les 2 serveurs du bas ayant été remplacés fin 2004 (ce billet, celui-ci et celui-là) et un de ceux-ci ayant atterri chez moi (ce billet et ce billet) ...

Je n'ai pas fait de copies d'écrans par manque de temps et surtout parce qu'à ce moment-là je pensais à autre chose qu'à faire un billet sur le sujet, il faudra donc croire ce que je dis ci-dessous sur parole ... ;-)

Sur les 6 serveurs présents dans la salle (controleur de domaine et DNS primaire, serveur de fichiers et DNS secondaire, serveur Exchange, serveur SQL et IIS du module de gestion de production, serveur SQL du module de comptabilité/achats Adonix et serveur Antivirus), trois étaient en service sans aucune interruption depuis le ... 11 Novembre 2004 ! Date à laquelle j'avais procédé à un reboot à distance mais dont je ne souviens plus la raison :cache: .

Si mes calculs sont bons, l'uptime du controleur de domaine, du serveur de fichiers et du serveur Antivirus avant l'arrêt complet de ce matin était de ... 274 jours, soit 9 mois tout rond :-)

Comme quoi et malgré ce qu'il se dit sur les OS de Microsoft, avec des bons serveurs (au niveau matériel), avec des systèmes d'exploitation Windows 2000 bien réglés sur lesquels on ne fait pas de bidouilles tous les jours et bien protégés (physiquement et logiciellement), on arrive à avoir des uptimes dignes d'autres systèmes Unix, Linux ou autre ....
Ne voyez pas de troll dans cette affirmation, mais juste une constatation !
J'ai notamment en mémoire qu'un de ces serveurs a eu un uptime encore supérieur car dépassant l'année complète (je ne me souviens plus du chiffre exact). En effet, entre ma date d'embauche dans l'entreprise et le reboot du controleur de domaine s'était écoulé plus d'un an ... (A croire sur parole également ;-) )

Si je n'avais pas eu à intervenir sur cet onduleur, je pense que ces 3 serveurs auraient pu continuer à tourner encore de longs mois sans aucun soucis. Pour étayer cela, j'ai vérifié l'état de l'occupation mémoire, des différents processus et services, ainsi que les journaux d'évènements et je peux vous assurer qu'aucune erreur ne s'était produite sur ces trois serveurs depuis longtemps ...
Les quelques problèmes ayant survenus étant réglés par un re-démarrage du/des service(s) incrimé(s).

En écrivant ce billet, je me souviens pourquoi avoir rebooté tous les serveurs le 11 Novembre 2004 : il s'agissait d'une mise à jour majeure de la partie Protection Serveurs de l'antivirus TrendMicro effectuée la veille au soir et nécessitant ce reboot. Je l'avais effectué à distance un jour férié afin de ne déranger personne ...

Pour finir, vous allez surement me demander : pourquoi seulement 3 serveurs sur 6 ?
Tout simplement, car comme je l'ai dit plus haut deux autres serveurs ont été remplacés en décembre dernier et la phase de mise au point à mis assez de temps. Elle a été suivie, pour l'un des deux, par des mises à jours logicielles fréquentes nécessitant un re-boot et pour l'autre à cause de soucis avec une vieille application ASP sur IIS entrainant certains effets néfastes, réglables par la gestion des services de Windows, mais en cas d'abscence de ma part (déplacement ou autre), la solution adoptée a été de faire re-booter ce serveur par une personne autorisée.
Quand au troisième serveur, il s'agit du serveur Exchange, pour lequel j'ai procédé récemment un compactage de la base de données et procédé à un re-boot afin de m'assurer que tout était OK ...

Avant de conclure, je dois avouer que si j'utilisais Windows Update pour mettre à jour régulièrement ces serveurs, je serais obligé de les re-booter au moins une fois tous les deux mois, réduisant presque à néant ces beaux uptimes. Mais ceux-ci étant bien protégés derrière un firewall (sous Linux :cache: , si si c'est bien vrai ! Mais ce serveur ne se trouvant pas nos locaux, ce n'est pas moi qui le gère, je me contente d'en exploiter les logs ;-) ), les mises à jour fréquentes par WU ne s'avèrent pas nécessaires.

Pour terminer et pour ceux que les uptimes intéressent, il existe un site qui affichant des estimations d'uptimes de nombreux serveurs Web : Netcraft Uptime Survey (http://uptime.netcraft.com).
En cliquant, par exemple, sur Longest Uptimes, vous afficherez la liste des sites Web surveillés ayant le plus grand uptime. A l'heure où j'écris ce billet, le premier serveur Windows se trouve en 15ème position (un serveur appartenant à Nec Corporation), ce qui n'est déjà pas si mal :P
Vous y trouverez mon serveur, avec notamment sa première date de mise en service (ancien serveur) le 28 Avril 2005 et la mise en place du nouveau affichée au 24 Mai 2005 (alors qu'elle a eu lieu le 18 ...): http://uptime.netcraft.com/up/graph?site=www.thierrynardoux.com

Thierry.

P.S. : S'il vous plait amis Nunuxiens :P ou utilisateurs d'autres OS, ne lancez pas de troll à ce sujet ! Je parle simplement de ce que je connais ;-) Si toutefois, vous avez des infos intéressantes sur les uptimes de votre OS préféré, elles auront bonne place dans les commentaires de ce billet :-) On est pas là pour faire la guerre du meilleur uptime, mais simplement pour échanger des avis ou informations pouvant intéresser le plus grand monde.
Merci d'avance.
P.S. 2 : Comme promis en début de billet, en utilisant la définition exacte du terme uptime, voici un exemple d'uptime, pris sur mon ordinateur portable. Il s'agit là donc bien du cumul de temps de fonctionnement entre deux dates. En l'occurence entre le jour où j'ai vidé le journal des évènements et le moment où j'ai effectué la mesure :



Si l'on regarde bien cette capture, le temps de fonctionnement (l'uptime tel que je l'ai utilisé tout au long de ce billet) est de 03h55m36s et que l'uptime réél est de 13j 09h50m45s (temps total de fonctionnement entre le dernier vidage du journal et la prise de mesure).
Les 279 jours, soit 9 mois, cités dans mon billet sont bien entendu à rapprocher du premier cas. Si l'on partait sur le deuxième cas, l'uptime des serveurs auraient été de plus de 3 ans, date à laquelle ont été démarrés ces serveurs pour la première fois et date depuis laquelle les journaux n'ont pas été vidés.

C'est clair ? :hein: Si ce n'est pas le cas ... dites-le :P !

P.S. 3 : Vous désirez mesurer votre uptime (cumulé ou non) ? Par défaut, aucun outil n'est fourni avec Windows. Les courageux se lanceront dans des calculs de dates savants avec le journal des évènements ... les plus flemmards, comme moi :P , téléchargeront ce petit outil (45 Ko) du Kit de Ressources Techniques de Windows NT 4.0 (sic !) sur le site de Microsoft.

P.S. 4 : Plus de P.S. ... ce billet est bien assez long ! :rigole: