标签：
全文包括三部分：
企业级的内容很丰富。过去，企业级往往和高可靠、高扩展和高性能的高质量系统相关。渐渐地，企业级的含义开始演变为 ”云级（coud-grade）“ 或者 ”网络级规模（web-scale）“。我想表达的是，随着 IT 时代向下一代应用演进，以及企业纷纷采用新的 IT 模型，交付一个高质量系统的需求也发生了很大的变化。
我喜欢的一个例子是 Hadoop。随 Hadoop 而来的是它的一个参考架构，包括使用商用服务器、商用磁盘、不使用 RAID。上次你看到一个企业基础架构方案没有使用硬件级的数据保护还是什么时候呢？当然，尽管我也看到过，我们是没有必要在连接光纤存储网络的高级刀片服务器上运行 Hadoop 的。甚至微软 Exchange 也开始推荐从 RAID 向 JBOD 演进，他们转而依赖应用软件层去容错。
我们来具体看看企业级 OpenStack 的三大需求。
扩展性是系统能够满足不断增长的系统规模和负载需求的一个特性。性能是系统内单个资源而不是系统本身的吞吐量的维度。也许亚马逊的CTO Werner Vogels 说的最好：
”当我们在系统中增加资源后，其性能会按照所增加资源的某种比例增加时，我们就可以说其服务是可扩展的。“
从多方面看，OpenStack 自身就是个高扩展性的系统。它被设计为松耦合、基于消息通信的架构 - 这些技术在已经在各种中级到高级扩展的系统中得到应用和验证，它们也可以适应小规模的部署。问题在于当你配置和部署 OpenStack 时所做的设计上的决定。一部分默认的配置，以及许多厂商的插件和方案在设计时并没有考虑扩展性。从前面的文章中你会了解到，一个参考架构对于部署混合云是非常的关键。你需要确定的是，你所选择的企业级产品的参考架构在选择它的各种组件和配置项时就已经考虑到了扩展性和性能。
一个完整的规模和性能测试超出了了本文所讨论的范畴；然而，我们需要注意到大多数用户会碰到的头号问题：网络性能和扩展性。
OpenStack 计算（Nova）有三种内在的默认网络模型：flat，single_host 和 multi_host。这三种网络模式对大多数企业来说都是无法接受的。除了这些默认的网络模型，你还可以部署 OpenStack 网络（Neutron），它使用一种高度插件式架构，支持若干不同的厂商插件去管理物理网络设备以及网络虚拟设备（所谓的软件定义网络 SDN）。
接下来我会依次介绍 Nova 默认的网络模型。我会尽量地简单，但是如果在将来有机会需要更详细地阐述，我也会很乐意去做。flat 和 multi_host 网络模型中所有的浮动 IP 地址需要一个共享的 VLAN。这就要求你的物理网络使用 STP 协议，而它是一个在你需要高速网络时非常有名的危险办法。我在多次会议上问过与会者：“多少人认为 STP 很恶劣？”，然后几乎会议室内的所有人都举手了。
也许更重要的，flat 和 multi_host 网络模型要求网络流量从你的公共 IP 地址经过你网络的边界路由到 Hypervisor 节点。这在任何现代企业中都是不可接受的。下面是 multi_host 的示意图：
当你使用 multil_host 网络模型时，你需要能够将代码部署到 Hypervisor 上，有时候这也许没什么，但是在 ESXi 或者 Hyper-V 平台上你就没那么幸运了。
相对地，single_host 模型的问题在于，它将一个x86服务器作为核心网络的中心（hub），所有 VLAN 和 Internet 之间的网络流量都得经过它。基本上，你可以将你高性能交换机扔进垃圾桶了，因为你的网络最大带宽将取决于那个 Linux 服务器。同样，这不是一个对网络来说能够接受的方式。但是公平地说，OpenStack 的竞争对手们也是用一个类似的方式。下面是 single_host 模型的示意图：
所有这些方法都有基础性的扩展性和性能问题。这也是为什么后来有了Neutron。
直到2013年9月，就像在 Argonne National Labs (ANL) 的 Scott Devoid 发给 OpenStack 运维人员的邮件列表中描述的那样，看起来 Neutron 仍然有严重的问题。在我写这篇文章的时候，Neutron 支持 single_host 和 flat 模式，但是不支持 multi_host 模式。显然，我们会在 Juno 版本中看到 multi_host 模式的替代者（译者注：应该是指 DVR - 分布式虚拟路由器），尽管这个功能已经缺位很久了。
应该说，Neutron 已经有了长足的进步，实事求是地讲，如今报出的很多问题都是来源于那些编程实现不佳的插件。也意味着，要想成功地使用 Neutron，你需要使用Neutron 核心功能加上那些在设计时就考虑了扩展性和性能的插件。再加上，你的云操作系统的供应商应该拥有的一些被证明了的大规模的部署方式，以及使用一些穷尽式测试框架去尽可能地排除网络中的一些潜在问题。
关于企业级OpenStack驱动的产品的性能和扩展性，我可以说得更多。然而，上面这些应该能够让你清楚，你需要跟你的供应商确认好他们已经了解并解决了这些问题。
更重要的是，不管你用哪家供应商，他们都必须能够提供一个详细的多机柜式的参考网络架构。如果没有这种架构，你要从一个机柜开始扩展的话，就会完全依赖于你的供应商那些有效或者无效的所谓保证了。
基础架构从来没有真正的弹性过，可是它的特性能支持弹性的应用在它上面运行。一个弹性云，需要被设计为每个资源，比如虚机、块存储和对象存储，其成本尽可能的低。这和杰文斯悖论（ Jevon’s Paradox）直接相关，他说随着技术的进步，效率的提升将会带来该技术被采用速度的提升。
简单地说，随着系统中各组件相对成本不断下降，应用不仅可以使用更多的资源来保证容错性，而且为了按需扩展而可以使用更多的资源。实质上，如果每个组件和资源的成本尽可能地低，你可以让资源池变得很大，以及购买更多的容量。主要的弹性云，象 Google、亚马逊 和微软已经在提供这种特性，而这些正是你需要在你企业内为了实现混合云而所需要的。
企业级 OpenStack 会通过同时支持弹性应用、扩展性和性能来引领你走向未来。小心那些需要让你使用光纤存储网络和刀片服务器的 OpenStack 驱动的云操作系统。那个时代已经过去了，就象我们在 Hadoop 上看到的那样。
假设你的企业是个全球性企业，计划在你的私有云、公有云和混合云上交付 7*24 小时运行的下一代云原生应用，那么你将需要这样的供应商，他们能够支持你全球性的业务，有国际性运作经验，以及能够支持 24x7x365 的环境。
IT 管理员正在转型为云管理员。这是在企业内部一个深层次的和持续性的变革。他们需要学习一系列全新的技术，以及其它技能，来适应新的云时代。当你评估企业级私有云供应商时，你需要找一个家有出色培训能力的公司，他们不仅要在 OpenStack 层面，还要在其它的特定云操作系统产品层面有相应能力。最重要的是，当评估一家可以帮助你升级你团队技术的供应商时，请注意确认他们不只是来给你看看如何在 OpenStack 上做开发或者安装 OpenStack 的。
真正需要的运维为中心的培训应该聚焦在：
不管你的 IT 团队如何优秀，你都需要一个值得信赖的支持团队 - 一个可以端到端完整支持你整个系统的团队。请确认你的供应商之前有过支持高事务 24*7 环境的经验。请确认他们有“全栈”的支持能力。他们有调试定位 Linux 内核问题的能力吗？他们有帮助做 Hypervisor 选型、解决网络架构和性能问题的能力吗？他们深入地理解存储吗？云是整合的系统，其中计算、存储和网络都非常基础性地互相整合。你的供应商需要比如何配置和开发 OpenStack 知道得多得多。他们必须是云全栈专家。你一定要向他们提出这个要求。
通过全球服务来交付云，不管规模小还是大，都不是简单的事情。这种交付比只是部署要求的多得多。它需要了解各地的文化，需要能够了解每个地区独特的要求。打个比方，你知道大多数数据中心中对电力的担心大于对空间的担心，而在日本情况是相反的吗？在那里，能使用尽量小的空间是一个主要的优势。他们这种对空间的需求是非常独特的。
你的云操作系统供应商需要有过国际交付的记录，以及有一个全球合作伙伴网络，他们可以在特定区域提供帮助。
OpenStack 是一个令人激动的可扩展的打造下一代弹性云的基础架构，但是它还不是完美的。所有和它差不多的开源产品都不是完美的。相反，每一个产品都是一种云操作系统的内核，都可以用来交付一个更加完整的、经得起检验的企业级云操作系统（CloudOS）。你需要一个有经验的企业供应商，来交付你的云操作系统，不管是使用 OpenStack 还是其它方案，我都希望你把这些需求放在心上。
我希望你们会喜欢这个系列文章。最后小结一下，我们谈到了六大需求：
当你们在评估各家供应商时，请确认你已经很清楚他们到底可以满足这些需求中的多少。
原文：The 6 Requirements of Enterprise-grade OpenStack, Part 3，Posted on May 6, 2014 by
[译] 企业级 OpenStack 的六大需求（第 3 部分）：弹性架构、全球交付
标签：
原文地址：http://www.cnblogs.com/sammyliu/p/5060464.html
