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
