我目前正在使用集群configuration的应用程序，它为每个子节点本地存储所有数据。 我们遇到的问题正在扩大，并正在考虑传统的SAN和基于消息的群集configuration。
我对如何正确configuration儿童/工作者节点和单个SAN的数据访问感兴趣。 我的pipe理器节点会一次限制数据访问到一个子节点，还是所有的孩子能够同时以高性能的方式读/写SAN上的同一卷？ 似乎最好的select是通过pipe理器节点一次限制对一台机器的访问，但限制一次只能从一个孩子访问的数据; 这是难以扩展的。
这个想法是能够启动一个工作，pipe理器节点会提醒所有的孩子节点运行。 每个节点将抓取一部分数据从SAN进行处理。
我对这个领域相当陌生，对于任何和所有的反馈/回应都将不胜感激。
谢谢。
[注意：这是一个基于Windows的服务器设置。 我们正在考虑专门尝试使用Windows Server 2008 HPC，但目前尚未使用它。]
拥有直接访问SAN和某种集群文件系统的工作节点从长远来看不会扩展。 根据所讨论的文件系统，你可能能够find十几个或几十个节点，但是最终你会达到极限并被卡住。
在更典型的情况下，节点将具有某种本地存储器，他们将在他们需要处理的数据中放置它们。 然后，您将拥有f个存储节点，这些节点使用某种forms的联网文件系统（NFS，CIFS或更奇特的东西）与工作人员共享数据。 然后，工作人员将他们需要处理的数据子集复制到本地存储中，无论是在工作开始时还是在需要时，将其输出写回工作结束，或者他们正在创build它们。
你会注意到我的答案是非常一般的，因为，这种types的东西是非常特定于应用程序的。 您可能有一个分布式应用程序，它执行的I / O很less，每隔几分钟就向共享文件系统写出一点数据。 在这种情况下，您可以直接从所有节点写入共享文件系统，而不必担心性能。 另一方面，如果节点每秒产生10兆字节的数据，你肯定不希望（或能够）一次写入共享文件系统。
build立一个HPC集群是非常特定领域的，在这里肯定没有一个通用的答案。
我想这个问题的答案取决于应用程序如何处理同时写入同一位置的多个工作人员。 你不希望两个工人同时写同一个文件，你也不希望一个工人覆盖另一个工人创build的文件（至less，我不认为你会这么做）。
我无法专门为您的应用程序回答，但在数据库领域，我们通常允许多个并发读取和单个线程/访问/工作者写入访问（无论是表级，行级还是页级锁）。 ）