You are not logged in.
Bonjour à tous,
Je souhaiterais mettre en place un solution qui me permette d'inventorier environ 250 000 machines répartis sur environ 480 sites avec la possibilité de donné accès à une personne de ces 480 sites sur son entité
Je me suis donc pencher vers le couple OCS / GLPI avec gestion des entités
Mes problématiques sont les suivantes :
Est ce que GLPI va être capable de gérer 480 entités ?
Soit je place un OCS central avec toutes les machines qui remontent dessus et un GLPI qui pointe vers cet OCS (je risque de vite saturé les liens des 480 sites ou d'avoir une actualisation peu fréquente pour éviter la saturation)
Soit je place un OCS en local sur chaque site et je connecte GLPI sur ces 480 OCS (GLPI va t'il supporter la synchro venant de 480 sites ?)
Et enfin GLPI va t'il supporter 280 000 machines ?
Je vous avouerais qu'en plus de toutes ces problématiques je me pose la question du dimensionnement des serveurs, dans le cas d'un OCS par site pas trop de souci par contre dans le cas d'un OCS centralisé, je pense avoir un serveur dédié pour la base de données mais je ne sais pas trop de quoi il va avoir besoin en terme de RAM et CPU et disques et un serveur dédié pour la partie PHP beaucoup plus light car moins consommateur.
Je pensais mettre du SSD en RAID 5 pour la partition /var qui hébergera la base de données et mettre un Bi processeur Xeon classique et enfin 10 Go de RAM mais n'ayant pas de cas similaires je ne connais pas trop les besoins de tout ca.
Voila en résumé si vous avez des informations de retour d'expérience je suis évidemment preneur et je vous remercie pour le temps que vous prendrez à me répondre.
Fix
Last edited by f.miot (2012-11-13 17:33:27)
Offline
* Est ce que GLPI va être capable de gérer 480 entités ?
=> Oui
* OCS central ou sur chaque site ca va faire pareil en terme de charge réseau, donc autant le mettre en central
* Et enfin GLPI va t'il supporter 280 000 machines ?
=> Oui
Pour le serveur, prévoir 2 ou 3 apache en frontend pour que la charge passe
Pour la base de données, le SSD c'est bien, si tu peux mettre plutot du raid10 ça sera plus rapide que du RAID5 (environ gain de 20% mais requiert un disque de plus)
Offline
Merci beaucoup pour cette réponse rapide et qui m'apporte de bons éléments.
Pour ce qui est de la charge entre le centralisé et le déporté je me disais peut être à tort qu'avec du déporté j'aurais une charge qui serais plus canalisé car plutôt que d'avoir toutes les machines qui se connecte sur le central à tout horaire, je pourrais faire des synchro la nuit quand les lignes Internet sont non sollicités entre le GLPI et les OCS.
Pour le serveur merci, d'ailleurs tu aurais une idée de la RAM et espace disque nécessaire pour ce nombres de machines à gérer ? je n'ai trouvé aucun abaque pour le dimensionnement de serveur du genre tant de machine telle taille de base et besoin de tant de RAM ...
Par contre je n'avais pas pensé à mettre 2 ou 3 apache en front, j'avais pensé à mettre des Reverses proxy pour la sécurité mais je n'avais pas pensé à mettre plusieurs serveurs Apache ..! J'ai un peu honte mais je ne voit pas trop comment mettre les serveurs Apache en Load Balancing ? J'ai déjà fait du FailOver avec HeartBeat et DRBD mais pour le LoadBalancing je ne voit pas trop, je sais que ca sort du sujet mais si tu a des noms de modules ou paquets, je suis preneur ?
Merci pour ces infos.
Fix
Offline
Oui effectivement, tu peux faire des synchros la nuit, mais il faut aussi voir que ça sous-entend d'avoir plus de serveurs/ressources pour les synchros et autant de serveurs OCS à maintenir (mettre à jour) que tu as d'entités.
Pour moi il ne faut pas voir un seul serveur, il en faut plusieurs (genr 2 pour Apache, 1 pour MySQL uniquement). Après faut voir / calibrer)
Sous BSD (FreeBSD, OpenBSD) tu as CARP qui existe, marche superbement bien, facile à configurer (tu specifie l'ip publque + l'ip privée pour chaque machine) et ça gère le load balancing tout seul et pour aucun frais.
Offline
Super merci je vais tenter ca, je suis pas super à l'aise avec BSD j'utilise plutot Debian d'habitude mais il faut un début à tout.
Sinon pour la partie dimensionnement serveur tu aurais quelques infos pour la RAM et la taille des disques ?
Fix
----------------EDIT--------------------------
Pour ceux qui lirais ce post et qui utilise plutot Debian ou tout autre système Apache, je viens de trouver ca qui à l'air intéressant par contre je ne sais pas du tout ce que ca donne mais ca vaut le cout de tester :
http://thleclere.free.fr/cms/index.php/ … -de-charge
Utiliisation d'un module apache sur les reverse proxy qui permet de faire de la répartition de charge.
Last edited by f.miot (2012-11-13 18:20:50)
Offline
Oui excat tu peux faire le load balancing avec un reverse proxy (apache, lighttpd...). Faut juste pas que ta machine qui a le reverse proxy plante
Offline
Cooooool :-) j'avoue que je suis bien sur Debian (même si ce serais bien que je commence à toucher à BSD car apparemment plus fiable et plus stable)
Je suis désolé d'insister mais tu aurais des infos sur la RAM et les disques pour le serveur de base de données car c'est la seule info restante qui me fait un peu peur en terme de dimensionnement ....
Merci beaucoup pour toutes tes infos ca rassure car GLPI et OCS ne me font pas trop peur mais à cette échelle mieux vaut réfléchir un peu ..!
Offline
Faut juste pas que ta machine qui a le reverse proxy plante
C'est clair mais bon ça encore ça va car je pense faire en plus du FailOver avec HeartBeat et je suis à l'aise avec l'infra, j'ai déjà monté des reverse pour de grosses infra Web.
Offline
Pour la base de donnée, plusieurs centaines de Go, ça c'est sur. Pour la ram un maximum
Offline
Merci beaucoup pour ces précisions
Je pense que je vais partir sur des SSD de 500 GO en RAID 10 ce qui me fera 1 To de données.
Par contre j'avoue que le RAID 10 est un peu moins simples que du RAID 5 même si effectivement les perfs sont meilleures.
Et pour la RAM je vais tenter 10 Go et après j'étalonnerais en fonction de la montée en charge.
Je ne sais pas comment on clôture le sujet et en tout cas merci encore pour toutes ces informations.
Bonne continuation
Fix
Offline
tu a raison, prend un SSD c'est beaucoup plus rapide et tu gagnera en performance
bonne chance
Last edited by Bohanon (2012-12-17 15:59:32)
Offline
Oui mais du SSD s'altère avec le temps. Pour une base de données, je sais pas trop si c'est l'idéal.
Offline