2009-04-22 6 views
0

J'ai besoin de traiter des fichiers d'image volumineux dans des fichiers image plus petits. Je voudrais distribuer le travail à beaucoup de serveurs «esclaves», plutôt que de charger mon serveur principal avec ceci. J'utilise Windows Server 2005/2008, C# et ASP.NET. J'ai beaucoup d'expérience de développement d'applications Web mais n'ai pas développé de systèmes distribués. J'ai eu une idée que cela pourrait être conçu de la manière suivante:Distribution du traitement d'image sur plusieurs serveurs Windows, verrouillage de fichier Q

1) Fichiers serait placé dans un lecteur réseau partagé

2) Les serveurs esclaves s'interrogent régulièrement le lecteur pour le nouveau contenu

3) Slave les serveurs renommeraient les fichiers nouvellement trouvés en quelque chose comme UNPROCESSED_appIDXXXX_jidXXXXX_photoidXXXXX.tif et commenceraient à traiter ce fichier. 4) D'autres serveurs esclaves éviteraient d'essayer de traiter les fichiers en cours en examinant le nom de fichier, c'est-à-dire si quelque chose a été nommé "NON TRAITÉ", ils ne tenteront pas de traiter.

Je me demande quelques choses:

1) Y aura-t avoir des problèmes avec deux serveurs esclaves en essayant de « saisir » et renommer le fichier à la fois, ou sera Windows Server verrouille automatiquement le fichier?

2) À votre avis, quel devrait être le meilleur mécanisme de notification du nouveau contenu à traiter? Une idée simple est d'écrire une page aspx de base sur chaque système esclave et de la faire fonctionner sur une minuterie. Une meilleure idée pourrait être d'écrire un service Windows qui utilise SystemFileWatcher et le faire fonctionner sur chaque système esclave. Une troisième idée est d'avoir un serveur central qui envoie des instructions à un serveur esclave donné pour tenter un travail de traitement, mais je ne connais pas les moyens d'invoquer ce type de communication au-delà d'une approche très hack-ish du serveur maître. message via HTTP.

J'apprécierais beaucoup les conseils que vous avez à offrir.

Cheers, -KF

Répondre

0

Si vous ne voulez pas aller tout le chemin avec un compute cluster type solution. Vous devriez envisager d'avoir un gestionnaire de travaux en cours d'exécution quelque part qui va morceler le travail. De cette façon, lorsqu'un serveur devient disponible pour travailler, il demande au gestionnaire de travaux une nouvelle tâche à effectuer. Il peut ensuite indiquer au gestionnaire de travaux qu'il est terminé et que le gestionnaire de travaux peut informer votre «client» lorsque le travail sur l'ensemble du travail est terminé. De cette façon, il est facile d'enregistrer le travail et de savoir qu'il est complet et le gestionnaire de tâches peut répartir le travail sans se soucier des conditions de course sur les renommés de fichiers. :)

+0

Bonne idée, merci. Avez-vous des mécanismes de communication suggérés sur la façon dont le «client» devrait communiquer avec le «gestionnaire d'emplois»? Une façon de procéder tout en assurant une solution relativement découplée pourrait être de conserver toutes les informations dans une seule base de données: les affectations de tâches pourraient disparaître si nécessaire, une notification de succès pourrait être notée dans la base de données. Vous pourriez même avoir de multiples "gestionnaires d'emplois" référençant les données et assignant des travaux si nécessaire ... – kendor

+0

Un db pour le gestionnaire de travaux est une bonne idée b/c qui permettra la durabilité des emplois et la traçabilité. Les travailleurs peuvent communiquer avec le gestionnaire de travaux via un service Web WCF par exemple. Mais vous devriez aussi consulter d'autres solutions de grille comme http://ngrid.sourceforge.net/. –

Questions connexes