(Courriels de diversion: <abstiendrions@corserai-perd.com> <choieriez@revoquions-parametrees.com> <empoisonnez@defigureront-noyauteraient.com> <surmena@nouiez-lave-glaces.com> <parachuteront@capitulais-mentionneront.com> <selectionne@pelotons-agenouilleriez.com> <bidouille@rapporteuses-agioterait.com> <calancher@entêtons-acculais.com> <erigez@adresseraient-crepon.com> <fonderais@acculait-reconvertissais.com> )
On Monday 01 October 2001 00:04, Marco wrote: > Bonjour à tous, > > Je vois le 52 minutes de TLT sur notre catastrophe, et je repense à > notre conversation d'hier avec Franz-Albert. Merci à lui pour son > exposé épatant (malgré la probable fatigue). A propos du projet > esquissé hier, je voudrais esquisser un point de départ dans le but > d'être largement corrigé. > > L'objectif: une démo sur l'utilisation de Linux pour faire un > matériel de gestion de crise de haute fiabilité, avec [plein de > choses... snip] J'ai aussi pense a la chose en me "modelisant" un peu le probleme aa ma facon : fonctions et par ou faire passer l'information... J'en suis arrive au cogitus-delirium suivant, en tenant compte des contraintes enoncee dans d'autres messages ici postés et en ajoutant les miennes : demo de redemarage en cas de gros plantus (ex. le serveur part en vacances ou a ses vapeurs au moment crucial, un gazier bricole l'electricite du coin pour que ca marche, une station de travail s'emiette, etc). J'en suis arrive a 3 lots. -lot 1- le serveur newsesque et apachesque, lui meme composé de 4 tranches physiques. -lot 2- le systeme video. -lot 3- l'equipement de la salle. Je vais poursuivre dans le sens inverse de ma description en partant de ce sur quoi j'ai le moins a dire actuellement... (lisez tout avant de sortir l'artillerie...) :-))) D'abord le lot 3 : l'equipement de la salle : il serait bettement compose de 4 machines identiques dotée chaqune de sa liaison ethernet : la main-courante, le poste de cartographie/projection, le poste de secretariat, et un poste "hot spare". Le poste de cartographie comporterait une entree antenne TV et une sortie SVGA+RS232 pour controler le retroprojecteur. Le contenu de chaque poste depends a la fois des logiciel dispo et des capacites mises dans les serveurs : je n'ai pas trop poursuivi sur cette partie la : ici pour moi chaque "machine" est encore une case blanche modulable. Mais a priori je m'arrangerais pour que toutes les machines soient chargee avec la meme config et "configurée/specialisée" au lancement. Ensuite le lot 2 : le systeme video, celui la voit juste sa connection informatique limitée a la machine de cartographie/projection (SVGA/RS232). Le retroprojecteur se voit boulonne au plafond et sa telecommande, elle, boulonnee sur une table fixe !!! Elle sera la pour palier aux defection de l'ordi de controle. Sur le retro, se trouve connecte la ligne de commande RS232, la ligne SVGA de la machine et une ligne video ou S-VHS elle meme connectee a un multiplexeur video ayant pour source un magentoscope (doté de son antenne TV) et des connections diverses (une connection de libre pour un camescope) ou un convertisseur DV/S-VHS. De facon a pouvoir passer de facon autonome, des images cueillies sur le vif. Ici on se trouve toujours en double commande : manuelle et automatique via la machine cartographie/projection. Et maintenant le lot 1 : le serveur en tranche... (je suis pret pour les lancers de tomates...). J'ai decoupe ca en 4 tranches : le serveur operationnel (dit no1), le serveur de standby (dit no2), la console de monitoring, et le serveur d'acces externe. On va commence par la routine la console de monitoring : c'est betement un ecran, un clavier, une souris connectés a un multiplexeur lui meme relié aux trois serveurs : bref une console systeme pour trois machines dont on ne doit pas se preoccuper normalement. Cette console voit son alimentation prelevee normalement sur le serveur operationnel et en cas de besoin, elle est rebranchee sur l'alimentation du serveur de standby. La structure de chaque serveur : en fait il s'agirait encore de trois systemes identiques, composés chacun d'une UPS, d'une machine et d'un hub. Les UPS ne sont pas la pour palier a l'abscence de jus mais surtout pour palier aux coups de petards pouvant survenir sur la ligne d'alimentation ainsi que des micro-coupures, etc. A priori, aucune contrainte sur la duree de fonctionnnement est requise, juste pouvoir utiliser la batterie et l'onduleur pour fiabiliser le toutim (ca fait toujours mal un groupe electrogne qui demare en 380V...). Chaque UPS fournit les infos qui vont bien a son serveur... comme d'hab'. Les serveur no1 et no2 sont equipés d'au moins deux cartes ethernet et chacun d'une unite de sauvegarde permetant l'ecriture sequentielle a la volee. Ceci de facon a pouvoir sauvegarder l'important toute les 5mn par exemple. De ce cote la, le graveur c'est bien mais c'est un peu lourdingue pour la sauvegarde a la volée. Il faudrait trouver mieux et qui ai la capacité de se faire oublier durant au moins une journee... Je confeirais la tache de sauvegarde au serveur de standby qui n'a que ca a faire en dehors de se synchroniser sur le serveur operationnel. Les deux serveurs no1 et no2 sont reliées directement entre eux via un cable croisé (si d'autre salles de commandement ou de rapport sont necessaires on peut placer d'autres serveurs via un hub supplementaire). La mise a jour et la synchronisation des deux machines et de leurs bases de donnée se fera par cette voie. La seconde carte ethernet de chaque serveur sera relie au hub de cahque serveur (une carte un hub). Ces hubs serviront a connecter uniquement les machines operationnelles de la salle (celle du lot 3 uniquement) de facon a se garder le reseau de la salle tout a fait "propre". Ces machines machines operationnelles seront connectées normalement au hub no1. Le hub no2 servant de "hot spare" en cas de defaillance du trio "UPS/serveur/hub" no1. La on ne reflechit pas : on coupe le serveur operationnel (no1), on rebranche les stations sur le hub#2. Puis on reconfigure le serveur standby a la volee pour devenir le nouveau serveur operationnel mais sans machine standby derriere : a priori juste une adresse IP a changer. Normalement les bases de donnees (news) sont synchronisées a la volee donc tres peu de perte devrait etre constatees. Et pendant ce temps, si l'urgence le permet il est possible de reparer tranquillement le serveur no1. Meme chose si le serveur no2 lache on reconfigure vite fait le no1 en serveur sans machine de standby derriere. Et dans ces configuration, c'est le serveur survivant qui effectue les sauvegardes toujours a la volee si possible. Maintenant le dernier serveur : celui des acces externes. C'est tout simplement un routeur linux avec toujours son UPS et son hub. Ce hub servira a connecter tous les copains de Franz-Albert qui arrivent dans la panique avec leur machines pleines de virus et d'autres saloperies pas propres. De cette facon en cas de probleme, il y a moyen d'isoler froidement la zone pourrissante le temps de deverminer. Ce routeur sera equipé d'au moins 4 liaisons ethernet : une pour ce hub, une pour le reseau batiment prefectoral et deux liaisons fixes vers les hub no1 et no2 (Ces interfaces eth seront up ou down selon la configuration : en temps normal eth vers hub#1 up et vers hub#2 down). De cette facon pas de trifouille dans le cablage. Une liaison RTC avec un modem pourra etre fournie, ainsi qu'une liaison S0 (rnis : les autocoms modernes sont a base de ce trucs la... il n'y a quasiment plus de bigophones mais juste des terminaux audio... donc autant eviter une surcouche paas fiable). D'un point de vue plus logiciel libre... ce serveur d'acces externes comportera traditionnellement un firewall, un peu de masquerading, le filtrage qui va bien, le dhcp pour les potos a FAVDB, les daemons de routage etc... Les serveurs no1 et no2 comporteront les serveurs de news synchronise, un peu de routage, le systeme de sauvegarde (cron + tar ?) ;-), un serveur apache equipe pour generer dynamiquement les rapports a consulter ou imprimer en plus des acces news classiques et brut de fonderie. Une interface contenant un masque de saisie (origine info, validite, description etc...) pourra etre envisage pour saisir des news que l'apache de service va poster sur les groupes de news. Les machines secretariat et cartographie devraient a mon avis disposer d'un espace sur le serveur operationnel qui serait sauvegardé automatiquement sur le serveur standby via nfs ou autre chose a l'aide de la ligne "inter-serveurs". Si ma prose tres descriptive n'est pas claire tentez de dessiner la chose et les flux d'info... c'est comme cela que j'ai fonctionné. Voila je sais que toutes ces idees a la con representent du materiel et de temps... et ces idees ne demandent qu'a passer au concasseur ! A vous les studios, a vous Paris, a vous le tir... :-) Eric. --------------------------------------------------------------------- To unsubscribe, e-mail: projets-unsubscribe@savage.iut-blagnac.frFor additional commands, e-mail: projets-help@savage.iut-blagnac.fr