亚马逊的弹性计算云(EC2)在高性能计算方面越来越受欢迎。它现在可以运行许多之前需要建立大型高性能计算集群或租用超级计算中心才能完成的应用。但也许正如你所想的，亚马逊EC2并不能完全取代一个传统的超级计算中心。
需要超高速互联的科学应用仍然需要使用IBM的Blue Genes和Cray超级计算机。然而，亚马逊通过万兆以太网连接其高端集群计算机提升了EC2的作用。
我们之前报道过，亚马逊的云为现实世界的科学应用使用的集群有30000个甚至是50000个核心。值得注意的是，这些往往是“棘手的并行”应用，在其中互联速度并不重要，因为每次计算都是独立运行的。
即使你用了亚马逊的万兆以太网连接，你仍然是在使用着彼此距离单个地球的服务器。亚马逊的客户薛定谔，制作模拟软件用于生物制药研究，对它来说，这个距离对上述50000个核心的集群来讲并不重要。薛定谔把亚马逊的资源铺开至四个大洲的所有七个亚马逊的数据中心地区，使这个集群尽可能的大。
但亚马逊的方案会减慢需要在服务器间大量通信的应用的速度，即使是在很小的规模。薛定谔总裁Ramy Farid告诉我们，在一个案子中他的公司在两台8核心亚马逊机器上开展工作，效果很不理想。
“某些类型的并行应用似乎还不太适合运行在亚马逊的云上”，Farid说，“我们已经成功地在八核心服务器上运行了许多并行工作，但当我们试图加入更多核心时，就会得到槽糕的结果。事实上，在一个案例中，同样的工作，运行在16核心上比运行在8核心上花费了更多的运行时间。”
Farid用的是亚马逊的八核心服务器，因此运行在16核心上的工作就同时需要两个八核心机器，他解释道。(然而，亚马逊实际上也提供16核心集群计算。)“在两个分开的机器间降低了连接速度确实成了一个很严重的问题”，他说，“这些双八核心机器甚至可能都不在同一个地区。”
曾为薛定谔建立过50000个核心的亚马逊集群，Cycle Computing的***执行官Jason Stowe指出，用来衡量世界上最快的超级计算机的Linpack测试是“面向1%”的高性能计算应用，不适用于像亚马逊这样的通常意义的服务。
“需要超强的超级计算机才能运行的那1%可能不会在亚马逊的设备上运行”，Stowe说，“如果你需要的有疯狂互联性的玩意儿，那肯定不能运行在万兆以太网连接上。虽然可以运行，但是肯定会很慢。”
亚马逊跻身前50，但仍落后于InfiniBand集群
Stowe表示，亚马逊已经明确其基础设施就是面向那众所周知的“99%”的。不过，亚马逊正试图使其集群计算实例逐步接近那1%，这些集群可以单独使用英特尔芯片或是与NVIDIA GPU的组合。
以下就是亚马逊所谓的Cluster Compute Eight Extra Large的规格：
·60.5GB内存
·两个英特尔至强E5-2670 Sandy Bridge处理器，每个八核心
·3,370GB存储容量
·10千兆以太网连接
集群计算“Quadruple Extra Large”机器使用两块四核心Nehalem处理器，而且使用了多出一半的内存和存储容量。集群GPU机器同样使用两块四核心Nehalem处理器，但还有两个带有extra boost的NVIDIA Tesla M2050 GPU。这三种亚马逊集群都使用万兆以太网，与标准的EC2的千兆以太网有所不同。
在***的世界最快的超级计算机500强排名中，***端的集群主要使用InfiniBand连接技术，或一个为高性能计算度身订造的定制或专有连接技术。以太网连接实际上在排名前500的系统中只占224个，还有210个使用每秒千兆的连接而不是10千兆。这使得以太网连接整体上领先于InfiniBand，但InfiniBand主宰头几名，排名前五的最快系统中占据两台，前十强中占有五台。
使用万兆以太网连接的排名***的集群实际上是由亚马逊为展示其实力在自己的云上建立的。亚马逊的使用英特尔至强处理器的17000核心的集群240万亿次的浮点运算速度在全世界排名第42位。亚马逊把整个集群集中在一个单独的数据中心区域，这肯定比用户建立的跨越洲际的多个亚马逊数据中心的集群要快得多。
50000核心集群方面，Stowe指出亚马逊美国东部数据中心区域就有40000个核心，但把亚马逊的资源向纵深铺开才能迎合应用的处理需要。
R Systems的高性能计算系统工程师Adam DeConinck表示，亚马逊的EC2并不完全符合为最复杂的科学应用而特出设计的超级计算集群的性能表现，这不足为奇。公司提供超过10000个核心，能够胜任高性能计算客户所需的计算能力。
在R Systems为客户所建的集群中，DeConinck普遍看好InfiniBand，因其高带宽和低延迟，但也会使用以太网。“InfiniBand为运行科学计算做了非常好的优化而且有高速存储”，他说。
虽然亚马逊确实能够提供专门针对高性能计算的集群，但这不是它们的生存之道。
与亚马逊EC2不同，“我们不做网页寄存服务。我们也不做MySQL数据库”，DeConinck说，“我们只做高性能计算。让我们做类似于EC2这样的模式所需的调整就好像是要它们想出一个专用的高性能计算方案一样。”
互连速度和输入/输出性能往往成为亚马逊云的限制因素，使用InfiniBand问题就能解决，他说。亚马逊提供了R Systems和一些超级计算中心没有的东西——有信用卡和网页浏览器就能够即时访问。但这种便利不总是值得的。
“EC2对于棘手的并行应用做得很好，因为它让访问大量计算核心变得更容易，因此一个较大问题的局部过程完全可以独立工作”，DeConinck解释道，“互联速度并不十分重要，因为很多情况下，它们只在工作的一开始或结束，它们提交数据或返回结果时才真正使用到网络。”
然而，许多应用程序需要使用的消息传递接口(MPI)进行大量进程间通信。“计算流体力学是这种问题的一个很好的例子——给定任务的每个进程都与其他一大堆进程联系着，因为它们要模拟像风力涡轮机周围的气流这样的特定的点”，DeConinck说，“它们往往非常依赖进程间的通信以致于网络延迟成为性能上的主要限制因素。在其他情况下，所有进程需要访问一个巨大地共享数据存储区，有时属于百万兆字节一类的，因此带宽就成了障碍。”
R Systems使用俄亥俄州的一个MPI基准测试显示了在一个使用InfiniBand连接技术的集群中传输简短信息(***4KB)的延迟在1.4到1.6微妙之间。相比之下，亚马逊的万兆以太网连接产生的延迟为100到111微妙。对于传输更大的信息(4MB)，使用InfiniBand每秒带宽高达3031M，而亚马逊每秒只有484M。
DeConinck提醒说这些测试的运行没有对集群做任何网络调整，但它们硬件的基本性能的表现确实不错。
亚马逊用InfiniBand? 现在还不行
亚马逊上周在波士顿主办了一次题为“云上的大数据与高性能计算”的会议，在会上我见到了亚马逊EC2的主要产品经理Deepak Singh。他不愿意透露亚马逊是否会加入InfiniBand支持。
“我们有兴趣从客户那里得知他们想要什么，然后就给他们提供这些功能”，Singh说。
亚马逊一直在优化其10千兆位以太网连接，这个工作在500强超级计算机排名上已见成效，他说。至于50000个核心的集群，Singh指出，从传统的超级计算中心那里要想获得50000个核心可不容易，而且在许多网络中这种集群都能胜任客户交给它的工作。
Singh指出，在GPU帮助下，亚马逊几乎可以从一个计算节点上提供一个浮点运算的性能。但他承认，亚马逊不准备在每一个实例上都取代传统的超级计算机。
“有某些专门的应用需要非常专门的硬件”，他说，“这就像一个人在某个秘密的国家实验室里使用它一样。”
但为了迎合那1%的需要而调整云计算，这不是亚马逊的风格。而且对于大多数客户来说，它完全不重要。
外文链接：http://www.wired.com/cloudline/2012/05/amazon-hpc-cloud/
