Discussion :

[spin0us]

Bonjour,

Pour des besoins internes, j'ai commencé à développer un agent de monitoring serveur (CPU/mémoire/disk et autres joyeusetés). A terme, une application iphone servira à contrôler la bonne santé du parc. Deux choix s'offrent à moi :

Solution 1 : je stocke les données au niveau de l'agent (donc sur chaque serveur monitoré) et j'interroge chaque serveur depuis l'application (architecture distribuée ?)

Avantages :

• l'information est toujours disponible
• le volume de données est réparti sur l'ensemble des serveurs monitorés

Inconvénients :

• ouverture d'un port sur chaque serveur (faille sécurité)

Solution 2 : je stocke les données sur un serveur de "collecte" et l'application n'interroge que ce serveur (architecture centralisée ?)

Avantages :

• un seul serveur "frontale" pour répondre aux demandes de l'appli

Inconvénients :

• si ce serveur est planté ou est injoignable, plus aucune visibilité sur le reste du parc
• gros volume de données à gérer

Il existe surement encore d'autres avantages/inconvénients pour les deux solutions qui pourraient fortement influencer le choix de la solution. C'est pour cela que j'aurai besoin de vos lumières sur ce projet. Peut-être certain(e)s d'entre vous ont-ils(elles) déjà un expérience sur ce type de projet ?

Pour information, la structure étant relativement réduite, les moyens le sont également, donc inutile de voir grand avec des solutions "ultra-secure" à base d'architecture à X serveurs. Comme souvent, on doit faire au mieux avec le minimum ...

[wiztricks]

Salut,

Pourquoi ré-inventer la roue plutôt que de mettre en place des outils qui réalisent déjà le suivi des serveurs (Nagios, Cacti, Shinken)?

La solution doit être centralisée car vous voudrez savoir:
- ce que faisait le serveur avant de crasher,
- quels sont les serveurs les plus chargés en ce moment?
- quelle est la charge des serveurs de la messagerie?
- comment corréler incidents et activités entre les serveurs.
Ce qui passe par la construction d'agrégats qui pourront être facilement exploités.

Cordialement,
- W

[spin0us]

Pourquoi ne pas utiliser une solution de supervision existante ?
Comme le disait souvent ma prof de maths : "pourquoi prendre un tank pour ecraser une mouche". Pour l'usage qui nous concerne, il nous a semble plus judicieux de faire du leger et d'en profiter pour etendre un peu nos connaissances au passage.

En tout, merci pour le remarques

[souviron34]

Personnellement, je ne vois pas trop ce que tu entends par "avantages" dans la solution 2 :

Pour récupérer les données, il faudra bien que ce serveur interroge chaque noeud, et donc l'inconvénient de la solution 1 est transposable à la solution 2.

Moi je serais plutôt pour la solution 1, car justement l'interrogation ne se fera que lorsque on voudra se servir de l'appli, et donc les "failles potentielles" ne seront présentes qu'à ce moment-là, alors que dans l'autre cas le dialogue sera permanent entre serveur central et noeuds.. augmentant donc les "failles potentielles".

D'autre part, je suppose que l'appli pourra "tailorer" ou "limiter" ou "crconscrire" les noeuds explorés..

L'avantage de la solution 2 réside selon moi uniquement dans le temps de réponse de l'appli

Donc à mon avis le choix doit se faire dans la priorité que vous établissez entre "sécurité" et "temps de réponse".

[wiztricks]

Salut,

Moi je serais plutôt pour la solution 1, car justement l'interrogation ne se fera que lorsque on voudra se servir de l'appli, et donc les "failles potentielles" ne seront présentes qu'à ce moment-là, alors que dans l'autre cas le dialogue sera permanent entre serveur central et noeuds.. augmentant donc les "failles

Le risque est de planter le serveur de production du client et l'ajout d'une trace quelque part pour vérifier qui a fait quoi...
Si on intercale un serveur "entre", il pourra aussi planter sans conséquences côté production. De plus, les accès se faisant "via" on peut plus facilement les limiter (i.e. on ne va peut être pas autoriser rsh).

- W

[spin0us]

Juste pour replacer un peu le contexte :
- le client c'est nous, donc si notre solution de surveillance nous pète un serveur, c'est "pas grave".
- nombre de serveurs à surveiller actuellement : 2 linux et 3 stations windows qui font tourner des demons
- comme nous n'avons pas systématiquement accès à des consoles et que nous ne sommes que 2 personnes pour gérer ça, on a besoin de pouvoir surveiller l'ensemble depuis un appli iphone qu'on dev. en même temps

Donc, soit l'appli ira chercher l'info sur chacune des cibles, soit il faudra qu'on charge l'une d'elles du rôle de "collecteur".

[souviron34]

Si on intercale un serveur "entre", il pourra aussi planter sans conséquences côté production. De plus, les accès se faisant "via" on peut plus facilement les limiter (i.e. on ne va peut être pas autoriser rsh).

ben il me semble que c'est beaucoup plus facile à faire avec une architecture prévue pour être décentralisée : par exemple faire des "grappes".

Si l'architecture est prévue pour être en un seul seveur centralisé, c'est pas souple.

Dans le cas contraire, rien n'empêche de s'en servir comme centralisé si on veut, mais on n'est pas obligé. On peut mêe aisément faire de la duplication de base.. (sauvegarde/sécuité)

Donc, soit l'appli ira chercher l'info sur chacune des cibles, soit il faudra qu'on charge l'une d'elles du rôle de "collecteur".

Comme je mentionnais, il me semble que la décision est à vous en focntion de priorités.

Mais au vu du petit nombre de serveurs impliqués, je pencherais vraiment fortement pour la solution 1.. Le temps de réponse sera supportable..