Recommandation du cadre nécessaire on.NET ou JAVA pour l'informatique volontaire (nœuds Internet)
Je veux que les machines clientes sur Internet qui s'abonnent à mon serveur fassent don de leurs cycles cpu inactifs.(Comme SETI @ Home)
Ils prennent des tâches(unités de travail) du serveur au processus et renvoient les résultats au serveur. (C'est la description la plus simple). Le cadre j'ai besoin devrait me permettre de définir une tâche. Le reste des choses comme la communication, l'exécution/le suivi des tâches, la mise à jour des binaires clients, etc. devrait être géré par le cadre.
J'ai évalué Alchemi.NET un peu, mais ce n'est pas activement entretenu, semble à moitié cuit.
BOINC a une API en C, mais je veux un framework.NET ou JAVA.
Je regarde ANEKA de Manjrasoft, mais cela semble fonctionner uniquement pour les nuages LAN.
Il doit y avoir de tels cadres disponibles. J'ai besoin de recommandations d'experts!
4 answers
Je ne suis pas un expert mais j'ai un peu d'expérience avec le calcul distribué utilisant MPI (avec C). Ce dont vous parlez ne ressemble pas à du grid computing, plutôt à un système maître/esclave. C'est-à-dire que votre serveur est le maître et qu'il dirige tous les clients (esclaves).
Je sais très peu de choses sur la programmation.net, donc je vais parler en général.
Il y a beaucoup de web frame fonctionne là-bas et probablement la plupart ont les installations dont vous aurez besoin. C'est à dire que votre client pourra pour télécharger des fichiers avec le contenu qu'ils ont rassemblé (ou ils pourraient simplement utiliser http get/post), car vous n'avez pas à vous soucier des problèmes d'interface utilisateur, vous pouvez tout gérer probablement via une action (en supposant un framework Web basé sur l'action). Ensuite, le serveur peut renvoyer une réponse via JSON ou XML que le client peut utiliser pour prendre d'autres directions. JSON est le bon choix si le système est très simple, et probablement un bon choix pour le prototypage.
Pour la mise à niveau de l'application, je considérerais c'est un problème distinct (bien qu'il devrait être simple pour le serveur de le renvoyer au client).
BOINC est le framework qui répond le plus naturellement à vos besoins en informatique volontaire, et il est stable et hautement évolutif I je m'assurerais que vous l'avez complètement considéré avant de l'exclure.
Si vous devez livrer quelque chose dans un délai court, j'envisagerais de créer un modèle de superviseur (ou de planificateur) - travailleur simple, juste pour lancer l'application. Le superviseur serait responsable du morcellement des données et de leur mise à disposition via http. Les travailleurs (votre application cliente) se connecteraient à un serveur de superviseur, téléchargeraient un morceau de travail, compléteraient le morceau et téléchargeraient les résultats sur le superviseur.
L'astuce principale consiste à éliminer correctement la machine d'état, de sorte que vous puissiez suivre avec précision l'état dans lequel se trouve chaque bloc de travail. J'aurais l'état de persistance du superviseur dans une base de données en arrière-plan.
Votre première version doit-elle être interne ou est-elle destinée à la consommation publique?
Pendant que ça marche, j'obtiendrais nous avons commencé à nous familiariser avec BOINC et à planifier une migration.
Ma recommandation
Travail dist:
- Avoir un récepteur de requêtes, qui place les messages dans une file d'attente de messages, comme rabbit mq
- Avoir une foule de travailleurs, écouter la même file d'attente, prendre le travail de celui-ci et acking une fois terminé.
- Une fois terminé, envoyez un message sur une autre file d'attente, contenant un URI à un emplacement connu, tel que votre lecteur réseau. La cible est vos données analysées.
- Le récepteur écoute ces messages "complétés". Récupère les données à partir de la URI.
Terminé.
RabbitMQ est livré avec grandes API CLR.
Le même raisonnement fonctionne bien avec Microsoft Azure et leur file d'attente AbbFabric. Un avantage est que les échelles sont extrêmement bien.
Version à chaud
Il donne un dossier où vous pouvez déposer des binaires, qui sont ensuite exécutés. Il gère la gestion des versions de ceux-ci ainsi que leur exécution en tant que services Windows.
Déploiement
Vous pouvez déployer les fichiers binaires avec robocopy/xcopy et "net use Q: pwd \serveur\partage", "net supprimer Q:"
Intégration Continue
Après avoir beaucoup travaillé avec MSBuild, je recommanderais de le scripter avec psake et d'exécuter la construction avec PowerShell. Si vous êtes avancé avec PowerShell, vous avez également WinRM à votre disposition à partir de vos scripts de construction, ce qui est vraiment fluide.
Utilisez le numéro de commit git/subversion comme 0.0.0.x, x dans le numéro de version précédent, et vous aurez une version automatique "partagée" entre les versions "Debug"/"Production".
La façon Azure
Travail dist:
Identique à ce qui précède mais avec la file d'attente AppFabric au lieu de RabbitMQ.
Version à chaud
En échangeant des instances "Staging" et "Production", vous évitez les temps d'arrêt.
Déploiement
Vous pouvez soit exploiter les outils Azure pour les tâches MSBuild de Visual Studio, comme on peut le lire ici ou vous pouvez utiliser PowerShell AzureSnapIns avec une configuration similaire à celle ci-dessus pour une intégration continue.
Intégration Continue
Identique à ce qui précède.
Que diriez-vous du programme d'installation ClickOnce de.net pour gérer les binaires clients mis à jour automatiquement. http://msdn.microsoft.com/en-us/library/t71a733d.aspx
Je ne suis pas sûr d'un "cadre de travail" par exemple, mais le cadre de synchronisation de Microsoft pour prendre en charge la synchronisation de vos propres travaux avec les clients?