如何使用网格计算安排任务 [英] how tasks are scheduled using grid computing

问题描述

raja;
谁能在c#上建议我如何使用网格计算计划任务".

感谢

raja;
can any one suggest me "how tasks are scheduled using grid computing" on c#.

thanks

推荐答案

对于初学者来说，您可以在CP上阅读此文章:

For starters you could read this article here on CP: Grid Computing Using C# Script and .NET Remoting[^].

Cheers!

—MRB

据我所知，框架中没有内置用于网格计算的功能.因此，您将不得不使用别人构建的库，或者自己编写框架.

网格计算通常遵循与任何形式的并行计算相同的模式:您需要将问题分解为独立的任务，然后将这些任务传递给单独的执行上下文，然后收集结果并检查何时需要完成所有操作实际完成了.这确实是在考虑使应用程序成为线程时需要进行的问题拆分，但是对于网格而言，启动新任务的成本，尤其是与网格节点之间来回发送数据的成本要高得多(因为您必须通过网络传输内容).因此，就执行复杂性和处理周期而言，任务的大小应更大，并且还应限制任务所需或产生的数据量(就纯大小而言).

一个标准网格将具有一个控制器节点，该节点维护一排要移植到网格中的任务队列(如果适用)，将结果汇总或取中间结果并将其推回到队列中，并提供一个或多个执行者节点一个任务，运行它并返回结果.由于责任失衡，他们有时也被称为主人和奴隶.如果主节点出现故障，此设置很容易遭受完全故障的破坏；这通常不是问题，因为外部世界希望通过一台机器与网格进行接口，因此您可以将主机放在上面.

但是，如果您的应用程序是非常关键的，并且您需要对此加以保护，则可以设置多个智能节点，这些节点知道队列的状态，以便它们可以在主要主节点出现故障的情况下接管.显然，在这种情况下，您需要一些动态DNS，该DNS可以将接口请求转发到新的主服务器"，必须使执行者知道切换，并且(不太明显)任务必须完全独立且可以正常工作(无副作用)，因为在切换过程中，您可能会重新启动部分完成的任务.我不会在多个主网格上进行详细介绍，因为很有可能您不需要一个来解决问题.

要从技术上将网格组合在一起，您需要使用工作环境所提供的通信机制，以及用于将有关任务和数据的信息从主服务器来回传递的协议.我个人非常喜欢使用TCP(好的，消息化TCP，类似于我的Sockets文章中的协议)，并发明了特定于应用的协议，因为这样可以减少网络字节，并且这可能是分布式系统中最昂贵的东西应用.但是您也可以使用.Net远程处理(假设您可以从中获取异步事件，我想可以)或类似的方法.如果要使用Web服务，则需要使整个任务成为异步服务调用，而且我不确定同时进行多个异步调用对性能和资源有何影响.

这很含糊，因为您的问题是相同的，但是希望那里有足够的内容供您理解原理.

As far as I''m aware, there is no facility for grid computing built into the Framework. So you will have to either use a library that someone else has constructed, or write a framework yourself.

Grid computing generally follows the same patterns as any form of parallel computing: you need to split your problem up into independent tasks which can then be passed to separate execution contexts, and then gather up the results and check when everything you want to be done is actually done. This is exactly the problem splitting that you need to do when you are considering making an application threaded, but with a grid, the cost of starting a new task and in particular the cost of sending data to and from a grid node is much higher (because you have to transmit stuff across the network). Thus the size of the task should be larger, in terms of execution complexity and processing cycles, and tasks should also be restricted in the amount of data they require or produce (in terms of pure size).

A standard grid will have one controller node, which maintains a queue of tasks to be farmed out to the grid and (if applicable) aggregate results or take intermediate results and push them back onto the queue, and one or more executer nodes which are given a task, run it and return the result. Because of the imbalance of responsibility they are sometimes also known as master and slave. This setup is obviously vulnerable to complete failure if the master node goes down; this normally isn''t a problem as the outside world expects to interface to the grid through one machine so you can put the master on that.

However, if your application is super-critical and you need to protect against that, you can set up multiple intelligent nodes which know the state of the queue so that they can take over in the case of the primary master going down. Obviously in this case you need some dynamic DNS that can forward interface requests to the new ''master'', executers must be made aware of the switch, and (less obviously) tasks must be completely independent and functional (no side effects), as during the switchover you could have partially complete tasks restarted. I won''t go into detail on a multiple master grid because there''s a very, very high probability that you don''t need one for your problem.

To technically put a grid together, you need to use a communication mechanism that''s provided by the environment you''re working in, and a protocol for passing information about tasks and data back and forth from master to slave. I am personally a big fan of using TCP (okay, messaged TCP, similar to the protocol in my Sockets article) and inventing an app-specific protocol, because that reduces network bytes and that''s probably the most expensive thing in a distributed application. But you can also use .Net remoting (assuming you can get asynchronous events back from it, I think you can) or something similar. If you want to use web services then you''d need to make the whole task an asynchronous service call, and I''m not sure what the implications of having several asynchronous calls all out at the same time is on performance and resources.

That is quite vague because your question is the same way, but hopefully there is enough there for you to understand the principles.

这篇关于如何使用网格计算安排任务的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！