Publicité
+ Répondre à la discussion
Affichage des résultats 1 à 7 sur 7
  1. #1
    Membre du Club Avatar de spin0us
    Inscrit en
    février 2003
    Messages
    86
    Détails du profil
    Informations personnelles :
    Âge : 34

    Informations forums :
    Inscription : février 2003
    Messages : 86
    Points : 43
    Points
    43

    Par défaut [Monitoring Server] Archi centralisée ou distribuée

    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 ...
    Membre actif de la Pouy@geTe@m.

  2. #2
    Expert Confirmé Sénior
    Homme Profil pro
    Architecte technique
    Inscrit en
    juin 2008
    Messages
    4 748
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : Industrie

    Informations forums :
    Inscription : juin 2008
    Messages : 4 748
    Points : 7 160
    Points
    7 160

    Par défaut

    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
    Architectures Post-Modernes

  3. #3
    Membre du Club Avatar de spin0us
    Inscrit en
    février 2003
    Messages
    86
    Détails du profil
    Informations personnelles :
    Âge : 34

    Informations forums :
    Inscription : février 2003
    Messages : 86
    Points : 43
    Points
    43

    Par défaut

    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
    Membre actif de la Pouy@geTe@m.

  4. #4
    Expert Confirmé Sénior

    Inscrit en
    janvier 2007
    Messages
    10 135
    Détails du profil
    Informations personnelles :
    Âge : 56

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 135
    Points : 13 090
    Points
    13 090

    Par défaut

    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".
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  5. #5
    Expert Confirmé Sénior
    Homme Profil pro
    Architecte technique
    Inscrit en
    juin 2008
    Messages
    4 748
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : Industrie

    Informations forums :
    Inscription : juin 2008
    Messages : 4 748
    Points : 7 160
    Points
    7 160

    Par défaut

    Salut,

    Citation Envoyé par souviron34 Voir le message
    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
    Architectures Post-Modernes

  6. #6
    Membre du Club Avatar de spin0us
    Inscrit en
    février 2003
    Messages
    86
    Détails du profil
    Informations personnelles :
    Âge : 34

    Informations forums :
    Inscription : février 2003
    Messages : 86
    Points : 43
    Points
    43

    Par défaut

    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".
    Membre actif de la Pouy@geTe@m.

  7. #7
    Expert Confirmé Sénior

    Inscrit en
    janvier 2007
    Messages
    10 135
    Détails du profil
    Informations personnelles :
    Âge : 56

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 135
    Points : 13 090
    Points
    13 090

    Par défaut

    Citation Envoyé par wiztricks Voir le message
    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é)


    Citation Envoyé par spin0us Voir le message
    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..
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •