serveur de serveurs ?

serveur de serveurs ? - SQL/NoSQL - Programmation

Marsh Posté le 01-04-2004 à 15:07:21    

Bonjour ma question n'est pas d'ordre développement mais analytique.
Pour un certain organisme je dois créer une application qui fait des statistiques sur plein de serveurs distants.
Le truc c'est que je sais pas qu'elle est la/les meileur(s) manière(s) d'aborder ce problème.
Ce que je peux faire c'est que l'organisme mère n'a pas de serveur et va questionner tous les serveurs auxiliaires mais ca risque de prendre du temps.

Reply

Marsh Posté le 01-04-2004 à 15:07:21   

Reply

Marsh Posté le 01-04-2004 à 15:32:50    

Qu'est ce qui t'empèche de faire une application qui fait des requetes sur tout ces serveurs, qu'entends tu par plusieurs serveurs au juste ? nombre ?
 
Est ce que c'est interactif, ou à périodes fixe ?
 
Si c'est à période fixe, et si il à un probleme de requete très longue, alors tu peux programmer les requetes sur chaque serveur, soit à lancer coté serveur ou coté applicatif, en ensuite prévoir dans le planning la requete qui te donne le résultat final...
 
Bref il faudrait commencer :
- par bien analyser le besoin : interactif/infocentre ou batch ?
- les requetes se font rapidement (auquel cas pas de prob) ou prennent beaucoup de temps (auquel cas organiser un planning de production des traitements batch)
 
Commence par faire un cahier des charges et fait un premier  test pour avoir une estimation de la durée d'éxécution des requetes


Message édité par Vazkor le 01-04-2004 à 15:33:39
Reply

Marsh Posté le 01-04-2004 à 15:47:05    

merci de ta réponse et en fait j'avais donnée toutes les info que tu me demande mais le copier coller du message n'a pas pris la fin et j'avais pas remarqué.
je te donne des infos suplémentaires
Alors le nombre de serveurs auxilaires va dépacer les 200 ce qui n'est pas rien. Et les données dans ces serveurs sont déjà conséquand, plusieurs milliers de lignes dans plusiseurs tables.
bref sa rique de prendre un certain temps, le prob c'est que j'aurai du mal à estimer la monté en charge.
 
 
Les statistiques doivent être relativement à jour donc la mise à jour du serveur (s'il y en a un ) doit se faire souvent. Une fois par semaine au minimum.
 
Sinon je ne connais pas les termes infocentre et batch.  
Je suis en train de créer le cahier des charges mais vu les plusieurs solutions qui s'offre à moi, j'essaye d'envisager la meilleur solution tout de suite.
 
a++ et merci de ton attention
 

Reply

Marsh Posté le 01-04-2004 à 17:43:54    

Une fois par semaine, ou une fois par jours c'est du batch, pas de l'infocentre/interactif.
 
Tu doit prévoir un planning de production avec une requete auto pour chacun des serveurs, lancé à une période données, et qui envoi les données sur un serveur quelque part.
 
Ensuite tu as plus qu'à lancer, ou à faire lancer en auto la requete qui va te faire la rapport final à partir de toutes les données.
 
 
 

Reply

Marsh Posté le 02-04-2004 à 08:35:56    

désolé mais j'ai pas capté grand chose la
le truc que je vais surment faire c'est que le serveur pricipal envera une requete aux autres serveurs pour qu'ils activent eux, les requetes pour envoyer les infos au serveur principal

Reply

Marsh Posté le 02-04-2004 à 09:55:29    

Si les volumes sont assez importants, je pense qu'il vaut mieux que les serveurs fassent eux même un maximum de travail (préparation des données). Ensuite, à période définie (1 fois par jour par exemple), le serveur principal vient chercher ces données :)  
 
Par contre, ca oblige à prévoir le cas où les données ne sont pas prêtes (serveur indisponible, préparation qui ne s'est pas faite).
 
Un planning pourrait avoir cette forme :
5 h 00 : chaque serveur prépare ses données
6 h 00 : le serveur principal vient les chercher
Ensuite, le serveur principal réessaie périodiquement d'accéder aux serveurs qui n'avaient de données disponibles.
Prévoir aussi la possibilité d'un rechargement "à la demande" (données fausses à recharger ...).


Message édité par mrbebert le 02-04-2004 à 09:59:24
Reply

Marsh Posté le 02-04-2004 à 10:21:14    

ouais cette solution me plait beaucoup, je vais l'examiner de plus près.
 
J'ai penser aussi à faire un autre style de mises à jour.
Elle consiste à donnée la main à tour de rôle à chacun des serveurs. Ainsi j'aurai des données encore plus précise.
Je m'explique:
On peut envisager une pseudo mise à jour en continue, c?est à dire qu?un processus tournera en boucle infinie du côté serveur principal. Il question le premier serveur auxiliaire, reçoit les informations, fait la mise à jour dans la table et question ensuite le deuxième serveur auxilaire, effectue les mêmes opérations que pour le  premier serveur et passe au troisième. ,?etc. Enfin arrivé au dernier il recommence toutes les opérations en partant du premier.  
Dans ce cas, il faut prévoir un partage des ressources c?est à dire que le processeur ne doit pas utiliser toutes ces capacités pour rechercher les valeurs, il faut aussi pouvoir les traiter, afficher dans un temps correct pour l?utilisateur.
Le truc c'est que j'ai quand même peur que ce procedé prenne trop de ressource, j'aimerai faire des tests mais la pour l'instant c'est pas possible sniff, puis en finalité je sais pas du tut si cette méthode à des chances de fonctionner ou non.
 

Reply

Marsh Posté le 02-04-2004 à 11:41:43    

Ca dépend aussi du type de données traitées et de la fréquence de rafraichissement désirée. Si ce sont des stats qui portent sur une journée complète, ce n'est pas la peine d'aller les chercher plusieurs fois par jour.

Reply

Marsh Posté le 02-04-2004 à 11:48:25    

moi perso je pense qu'une fois par semaine serai soufissant mais le client lui pense autrement alors que c'est que des statistique, il n'y a aucun traitement de données juste de l'affichage.
Mais comme on dit le client est roi et souvent malheuresuement il est exgigent. Le pire c'est que les statistiques qui seront archiver seront archiver une seule fois dans le mois,....
 
alors bon on m'ordonne et j'execute lol

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed