Bonjour,
Je suis en train de regarder le gros travail fait sur la partie réseau pour
la 0.84. Déjà, bravo :)
J'ai quelques interrogations qui arrive peut être un peu tard.
= La situation 0.84 =
Voila ce que j'ai compris, et je peux me planter :
- glpi_netpoints est une prise "murale"
- glpi_networkports est une prise côté équipement (un port de l'équipement)
- glpi_networkportethernets hérite de glpi_networkports et représente un
port Ethernet
_ il a une vitesse
_ et un type de lien (pair torsadée, fibre optique, etc)
= Réflexion =
Avec ces solutions il n'est pas possible de définir un câble en détail
et glpi_networkportethernets hérite d'une partie de la définition du câble.
Cette situation est problématique car dans un datacenter, l'infrastructure
filaire entre dans les
budgets informatiques. De plus, les connexions vers l'exterieur ont un coût
et peuvent être
concernées par des tickets.
= Proposition =
Je pense que cette seconde partie relative au câble devrait être sur un
nouvel objet que j'appelle "glpi_networkmedia". Ainsi
glpi_networkportethernets devrait
1) plutôt parler de la négotiation faite sur par la carte réseau (1000
Mbps Full Duplex,
les DB du signal pour du wifi, etc),
2) avoir une relation vers un netpoint qui lui aurait des informations sur
la nature de la prise (RJ11, RJ45).
3) enfin, qui lui pointerait vers un glpi_networkmedia*
(glpi_networkmediawired, glpi_networkmediawireless)
glpi_networkmediawired devrait permettre de connaître de définir :
- la nature du media
- la longueur
- si il est dédoublé
- un débit max
- le type de fibre (monomode ou multimode/cuivre)
- la référence constructeur si possible
- la couleur
- ses contrats dans le cas où le lien est sous traité (connexion WAN, ...)
- avoir une dénomination ou un numéro
- éventuellement une couleur
- les x glpi_netpoints associés (x > 2 a cause des câbles dédoublés)
- et sûrement d'autres choses
glpi_networkmediawireless devrait permettre de connaître de définir :
- la nature du media
- le type Wifi
- ses contrats dans le cas de liens sous traité
- avoir une dénomination (ESSID pour du wifi)
- les glpi_networkports associés
= Exemples =
Le cas d'un ordinateur
Ordinateur →
glpi_networkports (glpi_networkportethernets) →
glpi_netpoints (RJ45) →
glpi_networklinks (câble cuibre rouge) →
glpi_netpoints (RJ45) →
Equipement passif (bandeau de brassage) →
glpi_netpoints (port numéro 4)
Le cas d'une connexion ADSL
Modem ADSL →
glpi_networkports (le paramétrage de la connexion) →
glpi_netpoints (RJ11) →
glpi_networklinks (une ligne téléphonique, avec le contrat
téléphonique)
= Cas des prises de courant =
Je suis depuis quelques jours en discutions avec Arnaud Quette de 'nut'
( http://www.networkupstools.org/ ) pour intégrer le support des UPC dans
FusionInventory. Un concept nouveau qui est apparu est la notion de câble
électrique qui est importantes dans un datacenter.
En effet, l'onduleur peut remonter la consommation électrique de ces
prises, il
faut alors pouvoir connaître l'équipement associé.
Je me demande donc si on ne peut pas étendre les concepts liés au réseau
pour prendre en compte ce point car on reste
très proche :
Voici un exemple de configuration d'un onduleur.
Equipement 1 →
prise électrique →
câble électrique →
Prise électrique 1 →
Onduleur
Equipement 2 →
prise →
câble électrique →
Prise →
Onduleur
Équipement "superviseur" qui remonte les informations à GLPI avec la sonde
USB →
prise USB →
câble USB →
Prise USB →
Onduleur
Cordialement,
--
Gonéri Le Bouder
_______________________________________________
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev
