代码之家  ›  专栏  ›  技术社区  ›  Lars D

如何创建一个包含1500台服务器的系统,即时交付结果?

  •  4
  • Lars D  · 技术社区  · 15 年前

    我想创建一个系统,在100毫秒内提供用户界面响应,但需要几分钟的计算。幸运的是,我可以把它分成非常小的部分,这样我就可以把它分发到很多服务器,比如说1500台服务器。查询将被传递到其中一个服务器,然后再分发到10-100个其他服务器,然后再进行重新分发,等等。在计算之后,结果会再次传播回来,并由单个服务器返回。换句话说,类似于谷歌搜索。

    问题是,我应该使用什么技术?云计算听起来很明显,但1500台服务器需要通过提供特定于任务的数据来为其任务做好准备。这可以通过现有的云计算平台实现吗?或者我应该创建1500个不同的云计算应用程序并将它们全部上传?

    编辑:专用物理服务器没有意义,因为平均负载将非常非常小。因此,我们自己运行服务器也是没有意义的——它需要是外部提供商的某种共享服务器。

    Edit2:我基本上想要总共购买30分钟的CPU,我愿意在上面花费3000美元,相当于每天144000美元。唯一的标准是,这30分钟的CPU时间分布在1500台响应迅速的服务器上。

    Edit3:我希望解决方案类似于“使用谷歌应用程序,创建1500个应用程序并部署它们”或“联系XYZ并编写一个asp.net脚本,他们的服务可以部署,你根据你使用的CPU时间向他们支付费用”之类的东西。

    Edit4:一家低端网络服务提供商,提供asp。净价为每月1美元实际上可以解决这个问题(!)-我可以创建1500个帐户,延迟还可以(我检查过),一切都可以——除了我需要1500个帐户在不同的服务器上,我不知道有哪个提供商有足够的服务器可以在不同的服务器上分发我的帐户。我完全知道,不同服务器的延迟会有所不同,有些可能不可靠,但这可以通过在不同服务器上重试在软件中解决。

    Edit5:我刚刚试过,并将一家低端网络服务提供商的基准定为每月1美元。如果预先加载,他们可以在15毫秒内完成节点计算并将结果发送到我的笔记本电脑。预加载可以通过在需要实际性能之前不久发出请求来完成。如果一个节点在15毫秒内没有响应,则该节点的任务部分可以分发到多个其他服务器,其中一个服务器最有可能在15毫秒内响应。不幸的是,他们没有1500台服务器,这就是为什么我在这里问。

    12 回复  |  直到 15 年前
        1
  •  8
  •   BenMorel mehmet cinar    11 年前

    [提前向小组致歉,因为他们将部分响应空间用于类似元的事情]

    从行动中,拉尔斯·D:
    我不认为这个答案是对这个问题的回答,因为它并不能使我更接近于解决方案。我知道云计算是什么,我知道如果需要,该算法可以完美地拆分为30多万台服务器,尽管由于网络延迟,额外的成本不会带来太多额外的性能。

    拉尔斯,
    我真诚地道歉,因为我以一种幼稚和一般的方式阅读并回答了你的问题。我希望你们能看到,问题本身缺乏具体性,尤其是其原始形式,以及问题(1)有些不同寻常的性质,将促使我以同样的方式回答这个问题。这一点,以及这样的问题通常来自于那些对这个过程几乎没有思考和研究的人的假设,是我相信自己的借口,我是一个非实践者 大量地 分布式系统可以帮助你完成任务。许多类似的回答(其中一些得益于您提供的额外见解)以及向您提出的许多评论和其他问题表明,我并不是唯一一个有这种心态的人。

    (1) 非实际问题:一个[显然]主要是计算过程(没有提及分布式/复制存储结构),高度并行(1500台服务器),进入50毫秒大小的任务,这些任务共同提供亚秒响应(?供人类消费?)。然而,这一过程只需要(每天……?)几次。

    别再回头看了!
    在里面 实用术语 您可以考虑以下几个问题 为了改善这个问题 (或转移到其他问题/备选问题),从而培养 该领域的专家 .

    • 作为一个独特(更具体)的问题重新发布。事实上,可能有几个问题:例如,mapreduce进程的延迟和/或开销[可能]很差,以及当前的价格(例如 具体的 TOS和卷详细信息),各供应商对分布式流程的机架感知等。
    • 改名
    • 添加你手头的流程的详细信息(请参阅问题和许多回答的注释中的许多问题)
    • 在一些问题中,添加特定于特定供应商或技术的标签(EC2、Azure…)由于这可能不是完全不买账,但仍然有帮助,来自这些公司的代理商的评论
    • 表明你明白你的任务有点艰巨
    • 明确说明你希望底层技术的有效实践者做出回应(可能也包括那些对这些技术“沾沾自喜”的人,因为除了物理/高能等传统上使用集群而非云的人之外,许多技术和实践都相对较新)

    此外,我很乐意接受你的暗示(本页其他人暗示不否决),删除我的回复,如果你发现这样做有助于促进更好的回复。

    --最初的答复--

    警告: 并不是所有的过程或数学计算都可以很容易地分割成单独的部分,然后可以并行运行。。。

    也许你可以在网上查看维基百科的条目 Cloud Computing 理解云计算并不是唯一允许并行计算的架构。

    如果你的过程/计算可以有效地分成可并行的部分,也许你可以研究 Hadoop ,或 MapReduce ,以便对这些并行过程有一个大致的了解。此外,(我相信使用相同或类似的算法),也存在商业上可用的框架,例如 EC2 从…起 amazon .

    然而,请注意,上述系统并不特别适合快速响应时间。它们在长达一小时(然后是一些)的数据/数字处理和类似的工作中表现得更好,而不是像你希望并行化的那种长达一分钟的计算,因此它能在1/10秒内提供结果。

    上述框架是通用的,从某种意义上说,它们可以运行大多数任何性质的流程(同样,这些流程至少可以部分分块),但也有针对特定应用程序的各种服务,如搜索或DNA匹配等。搜索应用程序的响应时间特别短(例如,比照谷歌),顺便说一句,这在一定程度上与这样一个事实有关,即这样的工作可以非常容易、快速地分块进行并行处理。

        2
  •  5
  •   MSalters    15 年前

    抱歉,你期望太高了。

    问题是,您只需要支付处理能力的费用。然而,您的主要限制是延迟,您希望这是免费的。那是行不通的。你需要弄清楚你的延迟预算是多少。

    仅仅是从多个计算服务器聚合数据,每个级别需要几毫秒的时间。这里将有一个高斯分布,因此对于1500台服务器,最慢的服务器将在3分钟后响应。因为需要一个层次结构,第二层有40台服务器,在这里您将再次等待最慢的服务器。

    互联网上的往返也迅速增加;这也需要20到30毫秒的延迟预算。

    另一个考虑因素是,这些假设的服务器将花费大量空闲时间。这意味着它们已经通电,既能用电,又不能产生收入。任何一个有这么多空闲服务器的派对都会关掉它们,或者至少在睡眠模式下只是为了省电。

        3
  •  2
  •   Fred Simon    15 年前

    MapReduce不是解决方案!Map Reduce在Google、Yahoo和Microsoft中用于从海量数据(整个Web!)中创建索引他们的磁盘上有。这项任务非常艰巨,Map Reduce的设计目的是让它在几小时内完成,而不是几年,但启动Map Reduce的主控制器已经是2秒了,所以对于你的100毫秒来说,这不是一个选项。

    现在,通过Hadoop,您可以从分布式文件系统中获得优势。它可能允许您将任务分发到靠近数据物理位置的位置,但仅此而已。顺便说一句:设置和管理Hadoop分布式文件系统意味着控制1500台服务器!

    坦率地说,在你的预算中,我没有看到任何“云”服务可以让你租用1500台服务器。唯一可行的解决方案是在Sun和IBM提供的网格计算解决方案上租用时间,但他们希望您按照我所知的时间投入数小时的CPU。

    顺便说一句:在Amazon EC2上,你需要在几分钟内安装一台新服务器,至少需要保留一个小时!

    希望你能找到解决办法!

        4
  •  2
  •   eglasius    15 年前

    我不明白你为什么要这么做,只是因为“我们的用户界面通常旨在在不到100毫秒的时间内完成所有操作,这一标准也应该适用于此”。

    首先,“瞄准”!='不得不承认,这是一个指导方针,为什么你会因为这个而引入这些大规模的过程。考虑1500毫秒x=150秒秒=2.5分钟。将2.5分钟缩短为几秒钟是一个更健康的目标。还有一个地方可以放“我们正在处理您的请求”和一个动画。

    所以我的答案是——发布一个有合理目标的问题的修改版本:几秒钟,30-50台服务器。我不知道这个问题的答案,但是我觉得这个问题是错的。甚至可能是6-8台多处理器服务器。

        5
  •  1
  •   Robert Harvey    15 年前

    谷歌通过拥有一个庞大的小型Linux服务器群来实现这一点,这些服务器联网在一起。他们使用的是一种Linux风格,他们为自己的搜索算法定制了这种风格。成本包括软件开发和廉价PC。

        6
  •  1
  •   Tuure Laurinolli    15 年前

    看起来,你确实期望将工作分配到多台计算机上的速度至少提高1000倍。也许可以。不过,您的延迟要求似乎很棘手。

    您是否考虑过分配工作时固有的延迟?基本上,这些计算机必须靠得相当近,才能避免遇到光速问题。此外,机器所在的数据中心也必须非常靠近您的客户,这样您就可以在不到100毫秒的时间内将请求发送给他们并返回。至少在同一个大陆上。

    还要注意,任何额外的延迟都需要系统中有更多的节点。将50%的可用计算时间浪费在延迟或任何其他无法并行化的情况下,需要将并行部分的计算能力提高一倍,以跟上速度。

    我怀疑云计算系统是否最适合解决这样的问题。至少我的印象是,云计算的支持者宁愿不告诉你机器在哪里。当然,我还没有看到任何延迟术语 SLAs 那是 available.

        7
  •  1
  •   sdtom    15 年前

    你有相互冲突的要求。您对100ms延迟的要求与您只偶尔运行程序的愿望直接不符。

    您在问题中提到的谷歌搜索类型方法的一个特点是,集群的延迟取决于 最慢的 节点。因此,您可以让1499台计算机在不到100毫秒的时间内做出响应,但如果一台计算机需要更长的时间,比如1s——无论是因为重试,还是因为需要向您的应用程序发送页面,或者是连接不良——您的整个集群都需要1s才能生成响应。这种方法是不可避免的。

    实现您所寻求的延迟类型的唯一方法是让集群中的所有计算机始终将您的程序以及它所需的所有数据加载到RAM中。必须从磁盘加载程序,甚至必须从磁盘将其分页,这将需要超过100毫秒的时间。一旦你的一台服务器必须点击磁盘,你的100毫秒延迟要求就结束了。

    在共享服务器环境中,考虑到您的成本限制,这就是我们在这里讨论的,几乎可以肯定的是,您的1500台服务器中至少有一台需要点击磁盘才能激活您的应用程序。

    所以你要么要花足够的钱说服别人让你的程序始终处于活动状态并在内存中,要么就必须放宽延迟要求。

        8
  •  1
  •   posipiet    15 年前

    两种思路:

    a) 如果这些限制真的、绝对的、真正地建立在常识基础上,并且以你在第n次编辑中提出的方式可行,那么预先应用的数据似乎并不庞大。那么,用存储来换取时间上的预计算怎么样。桌子有多大?太字节太便宜了!

    b) 这听起来很像是雇主/客户的要求,在常识上没有充分的依据。(根据我的经验)

    假设一个核的计算时间为15分钟。我猜你是这么说的。 只要花费合理的钱,你就可以买到一个有16个合适的、32个超线程内核和48 GB内存的系统。

    这将使我们进入30秒的范围。 添加十几TB的存储和一些预计算。 也许在那里可以达到10倍的增长。 3秒。 3秒太慢了吗?如果是,为什么?

        9
  •  0
  •   Mitch Wheat    15 年前
        10
  •  0
  •   Kristoffer Bohmann    15 年前

    退房 并行计算 以及这篇维基百科文章中的相关文章——“并发编程语言、库、API和并行编程模型都是为并行计算机编程而创建的。”。。。 http://en.wikipedia.org/wiki/Parallel_computing

        11
  •  0
  •   sebastiangeiger    15 年前

    虽然云计算是一个很酷的新概念,但你的场景听起来更像是需要一个 cluster ,即如何使用并行性在较短时间内解决问题。 我的解决方案是:

    1. 要明白,如果一个问题可以在一个cpu上以n个时间步解决,并不保证它可以在m个cpu上以n/m的方式解决。实际上n/m是理论下限。并行性通常会迫使你进行更多的交流,因此你很难达到这个极限。
    2. 并行你的顺序算法,确保它仍然是正确的,你没有得到任何竞争条件
    3. 找一个提供商,看看他能在编程语言/API方面为你提供什么(没有这方面的经验)
        12
  •  0
  •   Nick Johnson    15 年前

    你所要求的并不存在,原因很简单,这样做需要1500台机器上有1500个应用程序实例(可能有大量内存数据)空闲,这会消耗所有机器上的资源。现有的云计算产品都没有这样的基础。App Engine和Azure等平台无法让你直接控制应用程序的分发方式,而亚马逊EC2等平台则按实例小时收费,每天的费用超过2000美元。