Compte rendu de la réunion de paris.

jm.cierniewski · 2006-01-11 16:33:38

J’ai eu à présenter la solution GLPI aux responsables « parisiens» de mon entreprise dans le cadre de l’utilisation possible de cette solution.

Présentation de l’entreprise

Je travail pour une entreprise , très connue, de taille européenne. La gestion de parc informatique ne concernerait que les serveurs. Au nombre d’un millier, ces serveurs sont répartis en « pôles » sur tout le territoire français. Avec un gros pôle parisien.

L’administration informatique est de type centralisée. C’est à dire que les administrateurs sont tous regroupés ensembles sur les sites principaux. Sur les sites de plus petites tailles, des correspondants locaux sont chargés des opérations de maintenances « mécaniques » des serveurs( reboot de serveurs, mettre un CD dans le lecteur…) .
L’administration se fait donc en terminal serveur et grâce à des cartes de remote management.

Comme dans la majorité des grandes entreprises, le service informatique est une « bisness unit » autrement dit une entreprise à part entière, qui à comme clients les autres services de l’entreprise. Il y a donc facturation des actes.

A l’heure actuelle, la gestion de parc informatique ce fait sur une base notes. Cette base à été développée au fil de l’eau et est devenu un « monstre » très au point. Cette base ne concerne actuellement que l’infrastructure d’une seule région ( paris).

Suite à réorganisation interne et à une fusion des régions, la question c’est posée de la pérennité de la base.

Cette base, à en effet quelques défauts.
1) elle est assez agressive visuellement parlant.
2) C’est une base notes, donc moins souple qu’une base de type mysql.
3) Elle ne possède pas de système de remonté automatique des éléments hard et soft des serveurs.

J’ai donc été amené à présenter la solution GLPI/OCS .

Cette solution à beaucoup plu, notamment par ça facilité d’utilisation, son ergonomie, son look, et son automatisme. Toute fois, après 4 heures de réunion, et malgré la volonté même des responsables de la base notes de passer sous GLPI, il apparaît que GLPI n’est pas encore prêt à remplacer celle ci. Une utilisation conjointe des deux va sans doute être mise en place. Il pourrait ètre envisagé de transformer la base lotus pour la porter sur Web, et créer des passerelles en direction de GLPI .Mais ceci est un autre débat.

L’objectif de ce rapport est de présenter les besoins en gestion de parc d’une très grosse structure afin de vous donner une idée des évolutions possibles.

Les points forts de GLPI. L’inventaire hard et soft
Les points faibles de GLPI, pas de gestion « fonctionnel » des serveurs. Une gestion de mails trop sommaire par rapport aux besoins.

Voici les éléments qui sont gérés et nécessaires dans mon entreprise et qui n'existent pas ( ou trop peut) sur GLPI

Fiche serveur : En plus de ce que propose GLPI

A) Dans l’onglet « généralités du serveur »

1) Description brève de la fonction du serveur.
2) Champ permettant de noter les fonctions du serveur
a. Fonction principale :exemple, serveur d’impression
b. Service réseau principal : exemple 02-Stockage de fichiers > Serveur Stockage (NAS / ) FTP* (User Data - DATA CAO/DAO - ….)

3) Serveur Virtuel, Oui, non, si oui, sur quel serveur est il hébergé
4) Eligible serveur virtuel : Est ce que se serveur peut être virtualisé ?
5) Configuration haute disponibilité, cluster ou autre.
6) Détermination de la criticité des serveurs.
a. Cette criticité aura un rôle lors de la détermination des destinataires de mails , ainsi que pour la
gestion de l’arrêt des salles serveurs ( voir plus loin mails et salles serveurs

7) Entité cliente et Service au profit duquel le serveur produit.
a. Les interventions étant facturés au service en question, il est nécessaire de savoir à qui envoyer la note…

B) Dans l’onglet « statut du serveur »

1) un planning rappelant les indisponibilités ou interventions prévues pour ce serveur.

C) Dans l’onglet « Fonction du serveur »
1) une vue des rôles du serveur dans les applications . Attention , ne pas confondre application et logiciels. ( voir inventaire applicatif)
2) Divers éléments, points particuliers à savoir. ( fiche blabla)

D) Dans l’onglet « localisation »
Une localisation très complète du serveur, allant jusqu’à l’emplacement dans la baie.

Pourquoi une telle précision. Etant décentralisée, l’administration s’appuie sur des correspondants locaux qui servent de « petites mains » sur place. Il faut donc étre en mesure de désigner par téléphone l’emplacement exacte du serveur à rebooter manuellement par exemple.
Cette localisation est reprise ensuite dans un onglet spécial de la fiche « Gestion des salles serveurs » ou apparaît une représentation graphique de l’emplacement des serveurs dans les baies.

E) Dans l’onglet « virtualisation »
Si c’est un serveur hébergeant des ôtes virtuels, une vue de ces ôtes.
Si c’est un serveur pouvant être virtualisé, les prés requis pour cette virtualisation. ( nombres de processeurs, Ram, ESX, GSX, divers)

F) Onglet « Rationalisation »
Quel est l’avenir du serveur. Statut si renouvellement ,arret envisagé, consolidation envisagée… Personne suivant cet aspect des choses.

G) Onglet « administration système et réseau »
En plus de la configuration réseau standard, une vue sur les possibilités de prise de main à distance, Configuration des cartes RAC. Vue sur les différentes possibilités de prise de mains à distance ( VNC, Terminal serveur, autre)
Information sur les politiques de sauvegarde. Ce serveur est il sauvegardé, si oui par quoi.

H) Configuration physiques des serveurs.
En plus de ce que fait GLPI, information sur les liens vers les baie de disques.

I) Onglet « maintenance »
Gestion de la location ( loueur, date prévue de fin de location, reprise prévue…)
Maintenance, Délais d’intervention, délais de réparation contractuel
Historique matériel ( BL, upgrade matériel, maintenance, garantie)

J) onglet « environnement »
Dimensions du serveur (H,L,l), Poids, nombres d’alimentations électriques, puissances électrique consommée .
Toutes ces informations seront exploitées au niveau de l’onglet « salle serveur » Cela permet de calculer le poids total de la salle, pour des raisons de structures plancher, ou pour les déménagements ( qui sont fréquents chez nous) . Cela permet de calculer les emplacements disponibles dans les racks ( n’oubliez pas que nous ne sommes pas sur place), la consommation électrique Max, la puissance nécessaire de la climatisation ainsi que le dimensionnement des onduleurs, groupes électrogènes de secours.

K) Onglet « SAN »
Si la machine est un SAN, nous avons des informations sur le nombre de slots utilisés, libres, le nombre de disques en hot-spare. La taille totale de stockage disponible.

L) Onglet « Procédure d’arrêt , redémarrage, y compris électrique »
1) Date de validation des informations de cet onglet.
2) Matériel à prendre en compte lors des arrêts électriques des salles (oui/non)
3) Liens vers les procédures d’arrêt et les contacts à prévenir
4) Possibilité de créer une procédure d’arrêt spécifique pour ce serveur.
Toute ces informations seront exploitées dans l’onglet « Gestion de Salle serveur » Dans cet onglet , on pourra imprimer une procédure reprenant l’ordre d’arrêt de tout les applicatifs, et de tout les serveur. ( cette procédure est crée dynamiquement grâce à la gestion des priorité des serveurs et des applications.)

Inventaire « applicatif »

Dans notre jargon, une application n’est pas un logiciel. C’est un ensemble de trucs qui au final produit quelque chose. Bref, une application c’est un certain nombre de serveurs, avec un certain nombre de logiciel qui au final donne l’application.
Exemple, l’application OCS/GLPI, c’est : Deux serveurs trucmush, 2 Apache, 2 mysql , et les « logiciels » ocs et glpi.

Dans cette fiche, on a donc une vue des composants de l’application, on va aussi gérer l’arret et le redémarrage de l’application avec des niveaux de priorités. Que doit on arrêter en premier ( apache ou mysql), quel serveur en premier… qui prévenir. Toutes ces informations, seront bien sur repris au niveau des procédures de l’arrêt de la salle serveur.

Gestion des salles serveur
La fameuse gestion des salles serveurs.
On y retrouve donc une description précise de l’occupation de la salle, ( occupation des baies, places libres) de la consommation électrique , du poids par m2, de la consommation électrique et comme on a le volume de la salle on peut en déduire la production thermique.

La gestion de l’arrêt électrique de la salle.
En reprenant les éléments « procédure d’arrêt » de tout les serveurs, la base nous donne la liste des logiciels/serveurs à arrêter, avec l’ordre d’arrêt . Comme pour chaqu’un de ces éléments il existe des champs « personne à prévenir en cas d’arrêt » le logiciel nous donne la liste de tout les gens à prévenir ( Dans une salle serveur il y a des serveurs appartenant à plusieurs clients et tout les serveur d’un client ne sont pas dans la même salle)

Gestion des interventions.
Cette gestion est à but interne, les tickets d’incidents passant par un outils gérant l’aspect commercial de la chose ( nos utilisateurs sont des clients)
La solution glpi pèche pour l’instant au niveau de l’envoie des mails.
Pour chaque intervention, un niveau de criticité est donné, qui prévient par mail les personnes « hors service informatique » ( responsables des applications, utilisateurs…) . Il faut dire que le fait de fonctionner sous lotus aide considérablement l’aspect « mail »

Enfin les logs.
Il existe une fonctionnalité de logs très étendu.
Chaque fiche serveur possède son « journal d’événement » ou est logé tout ce qui a été fait sur les fiches liée à ce serveur . Ces logs sont éditables, et des commentaires ou de la documentation peut y étre lier.

Bien évidement tout ces éléments sont liés entre eux, avec possibilité de documentation attachée de partout, et une documentation contextuelle ( exemple: prés des champs "criticité" des serveurs ou application, un bouton permet d'ouvrir la fiche expliquant comment déterminer cette criticité...)

Il reste encore pas mal de choses que je n'ai pas évoqué, mais j'ai voulu resté à l'essentiel.

En tout cas cela vous fait quelques pistes pour les versions 2-3-4 de GLPI

Bon code

Jm0u · 2006-01-11 17:08:58

jm je viens de lire ton compte rendu.
Dans ce que tu remonte de cette réunion il y à deux trois truc qui serait sympa à ammener à GLPI, par contre le reste je pense qu'il est spécifique à ton entreprise à moin que dans GLPI on sépare les PC et serveur en deux inventaire séparer dans ce cas la tout ce que tu dis est possible.

Donc à tes lignes de code jm

Merci du retour car je pense que les dev vont aprécier.

Jm0u

jm.cierniewski · 2006-01-11 17:30:28

J'ai travaillé dans plusieurs grosses, trés grosses entreprises. 500 voir 1000 serveurs, + de 11000 utilisateurs....
et dans ces organisations, tout est très structuré. Ce n'est pas le mème service qui gére les problématiques "workstations" et "Serveurs". Il n'est donc pas abérant de concevoir un glpi pour la gestion de chaqu'un de ces éléments.
Dans le mantis de GLPI et dans les divers post que l'on peut trouver ici ou la, on apprend que GLPI à pour but d'étre utilisé pour des "structures" ayant plus de 100000 posts.....
Dans ces grosses , gigantesques structures, les workstations ne sont pas un problème. En effet, les workstations sont "fabriquées" par imagerie, par une équipe qui ne fait que cela ( imagerie à base de "masters" validées par un commité de validation...) Les applications, patchs, poussées par stratégies de groupes ou outils tiers de déploiement... Donc en gros on sait tout sur les workstations et GLPI est presque trop évolué pour elles.
La ou il y a un grand vide, ce sont les SERVEURS. Les rois de l'archi informatique ce sont eux. une workstation hs,,, on la jette et on en prend une autre, un master et c'est parti. Un serveur mal géré, qui tombe en panne, ce sont des disaines d'utilisateurs qui peuvent rentrer chez eux. J'ai connu une grande boite qui fonctionne avec des serveurs citrix. une panne de la baie serveur et c'est 200 agences réparties sur tout le territoire qui arrétent de travailler, un manque à gagner économique énorme...

Donc tout dépend de ce que l'on attend de GLPI.
Si c'est un outil qui à pour cible la PME, encore quelques amélioration et c'est parfait.
Si c'est pour un emploi "corporate" il faut penser "corporate"

Et j'ai souhaité donné un chti coup de pouce aux dev de glpi en donnant une vue exaustive des éléments qui nous sont nécessaire.

Jm0u · 2006-01-11 17:44:22

totalement daccord avec toi.
Donc si l'on veux que GLPI devienne corporate il faut séparrer les serveurs des workstations avec deux inventaire différent:
L'inventaire des workstations est actuellement dans GLPI nickel à mon gout et comme tu dis deux ou trois amélioration mineur et tout est OK.
Concernant l'inventaire des serveurs, il faut à mon avis reposser le probléme sur la table avec les dev pour savoir si il veulent sorienter sur cette voie.
Si on sépare les workstations des serveurs, le module d'inventaire des serveurs et à creer de D à Z sachant que certaine chose sont dèjà dispo pour l'inventaire des serveurs.
Apres il y à l'autre discution qui va etre ' l'intégration d'OCS NG' dans glpi.
Comment faire pour importer les dit " serveur " dans le module serveur ?
Bref il ne faut pas refaire GLPI mais poser le problème selon le desire des dev, mais si les dev veulent que GLPI devienne corporate il faut, je suis de ton avis , une parti inventaire pour les serveurs.

Voilà, maintenant il faut attendre le ressenti des dev.

Jm0u

jm.cierniewski · 2006-01-11 17:54:16

Je pense que le fait d'avoir deux archi ocs/glpi complétement autonome n'est pas un probléme.
Dans ces grosses structure, si il y a un besoin clairement identifié, l'achat de matériel n'est pas un probléme.
Sinon, au pire au niveau d'OCS il y a la gestion des tags, et puis encore on pourrait filtrer au niveau des OS.
Mais vu le nombre de machines, et le fait de l'autonomie des différents services, je connais déja la réponse de mes responsables. Un systéme autonome pour chaque type: workstation et serveurs.

Jm0u · 2006-01-11 18:00:24

ok donc si je comprend bien la chose, il te faudrai carrement un deuxiéme GLPI pour gérer uniquement les serveurs.
Tu prend un glpi actuel et tu modifie les fichiers computers pour mettre tout les choses que tu voulas.

Dans ce cas la je pense plutot que un glpi uniquement oriénté serveur ne viendrai que d'un contribution d'un membre de la communauté et non pas de celle des dev, enfin je pense.

Sinon faut voir si c'est possible de l'intégrer directement dans glpi.
A discuter

jm.cierniewski · 2006-01-11 19:24:26

Il peut très bien y avoir deux versions de glpi, la première, "glpi pme" serait orientée workstations et une version "corporate" orientée grand groupes. Pour ma part je considére que la version 0.65, voire la 0.7 pourrait tout à fait étre la version finale de "Glpi Pme" On peut en effet y gérer toute les problématiques workstations, et un parc serveur standard pour une pme ( - de 30 serveurs)

Pour la version "corporate" d'autres problématiques entrent en ligne de compte. On n'administre pas du tout de la méme maniére une pme et un grand groupe.

J'ai eu l'opportunité de travailler dans les deux.

Etant dans une petite SSII je croyais avoir tout vu quand j'ai découvert pour la premiére fois la salle serveur d'une pme... la , devant moi, 15 serveurs assemblés et une baie avec deux serveurs de marque, tout beaux , tout nouveaux.... managé par des admins qui font tout et courent partout...

Le jours ou je suis entré dans la salle serveur du netcenter européen d'un grand groupe, j'y ai vu 5 rangée de 10 baies, contenant 10 serveurs chaqu'une, des robots de sauvegardes gérant 300 bandes, ( avec bras mécanisé et tout et tout) une baie de disque de 2m de haut, gérant plusieurs disaines de Tera. Le tout administré par 80 personnes, chaqu'une ayant son propre role "responsable sécurité" " responsable sauvegarde" " responsable hardware" "chef de projets" " responsable des utilisateurs, autrement dit des clients"..... le tout travaillant constament en mode projet... l'application d'un patch étant considéré comme un projet à part entière, avec commité de validation , réunions, étude des risque de l'application du patch, test, procédures de retour arrière...

Bref dans un cas, peut de personnes qui font tout dans le stress, mais qui connaissent par coeur une infrastructure informatique assez simple.
Dans l'autre cas, beaucoup de personnes très spécialisées, qui ne connaissent que leur propre domaine, le tout dans une infrastructure informatique ultra complexe.

Bref, un autre monde, une autre façon de travailler, d'autres besoins, d'autres outils.

JMD · 2006-01-12 00:18:14

Promis je lirai mais pas ce soir, trop fatigué.

jm.cierniewski · 2006-01-12 09:20:54

lol

Jm0u · 2006-01-12 09:31:34

jm sur le fait qu'il y est deux version de GLPI me plaie assez.
Je suis encore dacc avec toi pour dire que la version 0.65 ou 0.7 de glpi peux etre une version pour PME.
Rien nous empeche en parallele des dev de devellopée une version corporate de glpi enfin si ceux-ci sont daccord bien sur

Attendons maintenant le point de vue des dev

Jm0u

MoYo · 2006-01-12 09:38:13

Je repond juste sur les 2 versions.

On a deja du mal a maintenir et a faire avancer 1 version je vois pas trop comment en faire 2 en parallele avec aussi peu de bras qui developpent et autant de gens qui demandent des choses.

jm.cierniewski · 2006-01-12 09:52:36

oula,, alors, moi chui assez rapide pour taper au clavier, je sais faire des réunions, donner des idées ,mais alors coder .... c'est pas du tout mon métier.... je dirais pas ma spécialité ici, ça donnerai des boutons à tout les linuxiens qui lirai le post, avec pour résultat une hausse du déficite de la sécu, et un ralentissement du dev de glpi...
non non non, jveu pas ca moi...

en fait vu la dynamique que prend glpi, l'acceleration du projet, l'engouement qu'il y a autour, mon sentiment est qu'il n'y aurra qu'un seul projet glpi ( et c'est préférable) . Il pourrai y avoir peut ètre un systéme permettant l'activation ou non de fonctionnalité plus évoluées. Il etait prévu, je l'ai lue je ne sais ou, la possibilité, plus tard, de paramètrer l'affichage et donc de masquer des choses dans glpi.
Bon, pour la version corporate, le glpi 0.65+ fait une très bonne base. il n'y manque que de nouveaux onglets plus spécifique "métier, organisationnel, fonctionnalité..."... (onglets qui seront renseignés à la main de toute façon)
Pour l'instant.
le systéme de recherche est fonctionnel, donc pas de changement à ce niveau la... Le systéme de mail est à approfondir largement... mais c'est à peut prés tout...
Pour ce qui est d'ocs, dans les grosses entreprises, les serveurs sont tous de la mème marque du méme model ( enfin, par bloc quoi :50 de trucmush, 70 de bidule) donc l'inventaire technique est assez vite fait, il suffit au pire de regarder la doc... donc un plugin ocs / glpi un chouilla amélioré ( entre autre la possibilité de regrouper les logiciels ayant des versions différentes ) et c'est ok...

Franchement, je pense, qu'il faudra plus de temps pour réfléchir aux nouveaux modules à ajouter qu'à les créer réellement... enfin c'est mon sentiment.
A pluche

jm.cierniewski · 2006-01-12 09:54:31

a moyo ma doublé,,, voila ce que c'est de poster des trucs trop longs lol

Jm0u · 2006-01-12 16:46:35

C'est clair que bon je suis dacc avec ce que tu dis MoYo.

jm.cierniewski · 2006-01-28 20:33:07

hum hum...Moyo avait donné son opinion sur le fait qu'il serait trop difficile de gérer deux versions , l'une pme et l'autre corporate, et je suis parfaitement d'accord avec lui.
Par contre, concernant les "fonctionnalités , roles, métiers" des serveurs qui à mon gout manquent à glpi, j'ai po eu le sentiment des developpeurs...
Z'en penssez quoi messieurs ?

JMD · 2006-01-29 01:54:08

Ca va vous surprendre mais on a pas encore disposé du temps nécessaire pour en discuter tous ensemble sereinement.

C'est pas perdu, c'est là et on l'oublie pas.

jm.cierniewski · 2006-01-29 12:04:00

OKIIIIII tant que c'est po perdu, chui content.... faite comme moi, des post'it sur le frigot

Forum GLPI-Project

Announcement

#1 2006-01-11 16:33:38

Compte rendu de la réunion de paris.

#2 2006-01-11 17:08:58

Re: Compte rendu de la réunion de paris.

#3 2006-01-11 17:30:28

Re: Compte rendu de la réunion de paris.

#4 2006-01-11 17:44:22

Re: Compte rendu de la réunion de paris.

#5 2006-01-11 17:54:16

Re: Compte rendu de la réunion de paris.

#6 2006-01-11 18:00:24

Re: Compte rendu de la réunion de paris.

#7 2006-01-11 19:24:26

Re: Compte rendu de la réunion de paris.

#8 2006-01-12 00:18:14

Re: Compte rendu de la réunion de paris.

#9 2006-01-12 09:20:54

Re: Compte rendu de la réunion de paris.

#10 2006-01-12 09:31:34

Re: Compte rendu de la réunion de paris.

#11 2006-01-12 09:38:13

Re: Compte rendu de la réunion de paris.

#12 2006-01-12 09:52:36

Re: Compte rendu de la réunion de paris.

#13 2006-01-12 09:54:31

Re: Compte rendu de la réunion de paris.

#14 2006-01-12 16:46:35

Re: Compte rendu de la réunion de paris.

#15 2006-01-28 20:33:07

Re: Compte rendu de la réunion de paris.

#16 2006-01-29 01:54:08

Re: Compte rendu de la réunion de paris.

#17 2006-01-29 12:04:00

Re: Compte rendu de la réunion de paris.

Board footer