Bonjour,

J'ai un petit peu bossé sur l'évolution de la partie réseau pour la 0.84. Il y a eu quelques petits changements par rapport aux spécifications sur le wiki (d'ailleurs, je vais devoir les mettre à jours) : Le Netpoint est, effectivement, une prise "murale". Mais cela peut contenir, également, le numéro de port sur le bandeau de brassage. Le NetworkPort doit être vu comme un port physique ou logique (trunk) au sein d'un équipement Le NetworkPortEthernet (comme le NetworkPortWifi, le NetworkPortAggregate, ...) est une classe qui vient spécialiser le NetworkPort (même ID que le NetworkPort). Le NetworkPortEthernet contient, en plus, l'adresse MAC et la connexion à la carte réseau physique qu'il utilise. Ces évolutions ont eu lieu car le NetworkPort doit rester le point de passage unique entre l'équipement et le réseau. Sinon, le nombre de requète nécessaire à l'obtention des connexions réseaux augmente avec le nombre de type de port réseau.

Ce que vous proposez est intéressant.

Mais, plutôt que de parler de media, je parlerais de lien (NetworkLink). En effet, la notion de medium est très fortement liée au matériau (fibre, cuivre, onde électromagnétique, ...). À l'opposé, un lien est plus abstrait et supporterait beaucoup d'autres choses (les mediums, ainsi que le connexions au travers de prises murales, ou entre jarretières, sur un WAN, ...). Un Link relierait deux ports entre eux (ou un port et une patte en l'air pour les connexion sortantes). Intrinsèquement, il contiendrait les caractéristiques décrites (la nature, la longueur, le débit max, ...). On lui "attacherait", une ou des prises réseau, des fibres entre bâtiment ou entre salles, ... Chaque élément qu'on lui attache contient un numéro d'ordre à partir de l'une des deux extrémitées. Cette solution me semble plus appropriée que le fait de décrire la chaine dans sa globalité. En effet, rechercher l'équipement à l'autre bout du NetworkLink se résume à une requête SQL. Alors que si l'on a une chaine, il faut suivre les éléments un à un (avec le problème de la multiplicité des types intermédiaires : prise réseau, fibre ) jusqu'à l'autre bout.

Shéma : équipement terminal (ordinateur, switch, téléphone, ...) <- NetworkPort (NetworkPortEthernet) <- NetworkLink -> NetworkPort (NetworkPortEthernet) -> équipement terminal Les Netpoints auraient divers éléments, chacun avec son numéro d'ordre sur le NetworkLink.

Pour commencer, le NetworkLink serait un renommage du NetworkPort_NetworkPort. Ensuite, il faudrait rediriger les Netpoint vers cette nouvelle classe.

La 0.84 propose le WifiNetwork qui contient l'ESSID et le mode de gestion (ad-hoc, avec access point). Les NetworkPortWifi s'y "connectent". On peut l'étendre en ajoutant la version Wifi (a, a/b, a/b/g, ...), le type de clef de sécurité, le canal, ... Si c'est nécessaire, nous pourrions ajouter les contrats dans le NetworkPortWifi ou un plugin qui vient s'y ajouter.

Concernant les onduleurs, l'intégration dans FusionInventory, puis dans GLPI serait une bonne chose (mais ne pas oublier les alimentations redondantes dont tient compte NUT). Une solution similaire à celle du NetworkLink (PowerLink ?) serait réalisable ...

Je pourrai filer un coup de main. Reste à avoir l'aval des développeurs du coeur de GLPI.

Damien
On 07/12/2011 18:14, Gonéri Le Bouder wrote:
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

_______________________________________________
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Reply via email to