Réflexions sur la problématique de gestion des serveurs dans GLPI

- Gestion des Blades
- Gestion des racks par 1/3 de U : positionnement de tout type d'élément dans un rack
- Gestion des serveurs virtuels
- Définition Serveurs : flag simple : OUI / NON -> pas nécessaire en fait. le type existe déjà
- Gestion liaison serveurs : contenu / contenant

Gestion de la virtualisation

Voir : http://www.glpi-project.org/forum/viewtopic.php?pid=30551#p30551
- scénarii :
- machines virtuelles : des machines virtuelles sont rattachées à une machines physiques
- cluster : une machines virtuelle est l'agregation de plusieurs machines physiques

A noter :
  • dans la cas de la virtualisation, il existe une machine hôte et une ou plusieurs machines virtuelles.
  • dans le cas du partitionnement (gros systèmes Unix), il n'y a pas de machine hôte, juste des machines virtuelles.
    => EmpereurZorg : du point de vue glpi, les deux hôtes existent bien : date d'achat, garantie, composants matériels, etc... . Il n'y a en réalité que le système d'exploitation de l'hôte qui "n'existe pas" sur les gros systèmes (il existe mais plus transparent, comme VMWare ESX qui n'est qu'un Linux light). Donc à mon sens cette note n'a aucun impact, si ce n'est avec OCS : machine hôte liée à une remontée OCS, ou non.
On peut aller plus loin dans ce type de scenario :
  • une machine virtuelle sur plusieurs machines physiques (ou un « pool » de machines physique) cas qu'on retrouve par exemple dans vmware infrastructure
    => doum : pas exactement, dans vmware infra, une machine peut appartenir a un cluster de serveur ESX, mais à un instant T elle n'est rattaché qu'a un ESX, celui qui la fait tourner. Elle peut cependant en changer "à chaud". Avec vsphere 4 vmware introduit le "vmware fault tolerance", qui consiste en fait a avoir un clone d'une vm qui tourne sur un autre hote physique et se replique en temps reel. Si un ESX crash la réplique prend le relai instantanément. Maintenant comment ce sera vu par fusion c'est a voir. J'aurai bientot du vsphere on pourra tester
  • cas d'un système sur plusieurs machines physiques (grid computing, cloud computing) : avec des OS distribués notamment.

Il faudrait pouvoir gérer de manière générique l'héritage entre des entités GLPI (séparer le système du matériel par exemple, ou créer des méta-matériels auquels on associe un système).

gestion documentaire des disques

Voir : DriveAndDiskUsage

Gestion des racks

Un rack est composé de :
- un nom (texte)
- un fabricant (référence à la liste)
- une taille (nombre de U) (texte)
- éventuellement un modèle (texte ou référence à la liste)
- éventuellement des informations financières
- un emplacement précis (texte) (par exemple, on à dans les lieux "Batiment 2 > salle 23" on peut ajouter rangé 3, dalle 5).
- une liste d'équipements (serveurs + équipement réseau) (référence à la liste)

Pour les équipements du rack, il faut :
- le nom (référence à la liste)
- l'emplacement dans le rack (texte)
- éventuellement le nombre de U (texte)
- La/les voie(s) électrique sur laquelle il est branché