[译] 企业级 OpenStack 的六大需求(第 2 部分):开放架构和混合云兼容

全文包括三部分:

在本系列的第一部分,我介绍了企业级 OpenStack 的六大需求。现在,我会着重阐述接下来的两个主要需求:开放架构和混合云兼容性。让我们马上开始吧。

需求3 - 开放架构和减少厂商锁定

我们已经讨论过构造健壮的云控制平面和云管理系统。OpenStack 吸引人的特点之一是通过使用开源代码平台来消除厂商锁定。

“无厂商锁定”是蛇油推销技巧(Snake Oil Salesmanship)

你是不是被承诺过 OpenStack 可以避免厂商锁定?完全没有厂商锁定只是个不切实际的想法 - 就是那种可以想象得很完美但是永远不会实现的东西。任何系统,都有某种形式的厂商锁定。比如说,你们部分人都应该用过 RedHat 企业版本的 Linux 系统,一个完全 100% 开源 Linux 的操作系统,来作为你企业的默认 Linux 版本。你看,RedHat 就是一种形式的锁定。RedHat 的 Linux 是为了一个特定目标而设计的特定版本的 Linux。使用它,你就会被锁定进它们的特定的参考架构、打包系统、安装/系统引导等等,即使它是开源的。

实际上,在许多客户那里,我没怎么看到对锁定的担心,而更多的是对“更多锁定”的担心。打个比方,一个客户,他要求保持匿名,基于厂商锁定的考虑,对采用我们的块存储组件有意见,即使它是 100% 开源的。进一步了解后,我发现其实是客户想继续使用他们现有的存储提供商(NetApp 和 Hitachi Data Systems)而并不想再去培训他们的 IT 团队再去使用一个新的存储系统。可以看出来,他们对厂商锁定的担心,主要是不想有更多的锁定,而不是完全想要消除锁定。

因此,更重要的是,去了解你的企业所能承担的风险。转为使用 OpenStack, 就像前面 Linux 的例子一样,意味着你通过针对新的软件培训你的IT团队,以及可以从多个厂商去获取开源软件的支持,去减少某种风险。

换句话讲,OpenStack 肯定可以减少厂商锁定,但是不是彻底消除它。因此,去寻求一个开放的架构,然后期望收获一个企业级产品吧。

锁定一直存在,特别是使用企业产品

我希望锁定不存在,但是它确实一直存在,就像你从上文中所读到的那样。这意味着,与其一味去寻求没有锁定,不如去看看你能接受什么样的锁定。一个企业级的OpenStack 版本,会通过一个开放的架构来提供一系列的选项。然而,一个真正的云操作系统和企业产品,不会提供无限的选项。为什么不能呢?因为那样的话其支持模型是不可持续的,各个产品提供商最终都会离开这个领域。即使是大型的厂商,也不会向所有用户提供所有的选项。

如果你想围绕 OpenStack 打造你自己的定制的云操作系统,你可以尽管去做,但是那不是一个产品。它需要定制化的专业服务。就像那些在一段时间内推出了自己的Linux 发行版的公司一样,他们给行业带来的是某种程度的混乱,最终对行业和用户是有害的。而且自己做也需要很多的资源。你需要有个 20-30 人的 Python 开发团队,对基础架构(计算、存储和网络)都非常熟悉,他们需要全时间投入到你自己定制的 OpenStack 上。一个团队看起来大概象:

[译] 企业级 OpenStack 的六大需求(第 2 部分):开放架构和混合云兼容

因此,最终地,如果你需要一个企业级 OpenStack 驱动的私有云方案的话,你需要选择一个厂商。

需求4 - 混合云兼容

混合云是个全新的世界。我们所交流过的大部分客户都已经意识到,他们需要向其开发人员提供最好的工具。需求不同,要求不同,想法不同,抱怨也不相同。每个企业都是独一无二的。有些企业希望从公有云开始,然后一段时间后再转移到私有云;有些希望从私有云开始,但是也缓慢的采用公有云;而有些公司在两个方向上齐头并进。RightScale 2014 年的报告对这方面有些非常好的调查数据支持:

[译] 企业级 OpenStack 的六大需求(第 2 部分):开放架构和混合云兼容

我们来看看,为什么你的企业级 OpenStack 驱动的云操作系统提供商最好有一个优秀的混合云故事可以讲。

混合云优先战略

每个公司都需要一个混合云优先战略。这个的意思是,混合云应该是你第一个的和主要的需求。然后,围绕混合云,使用一个单一的、整合的监管模型,会给你带来最好的收益。最终,根据你的应用和需求,制定一个流程,来确定每项工作需要什么类型的云。下面这个图突出了这个流程,但是你要知道,每个公司情况不同因此数据也不会相同:

[译] 企业级 OpenStack 的六大需求(第 2 部分):开放架构和混合云兼容

理解云的兼容性和企业级私有云在混合云中的角色

我做过不少兼容性方面的事情,最痛苦的莫过于 IPSec 和 VPN 之间的兼容。达到各厂商之间的兼容性是需要花成本的,往往需要大量的工作,而且往往最终很难取得一个好结果。而且不幸的是,兼容性往往被误解,特别是对于公有云/私有云/混合云。

混合云的挑战,是如何解决应用的移植性问题。如果你需要一个公有云和私有云组合而成的混合云,不管应用在某个云中被开发,还是要在两个云之间做迁移,或者从一个云到另一个云,应用的可移植性都是必须的。当你选定一个应用以及它的云原生的自动化框架,并将它们从一个云移动到另一个云中,一些关键的东西必须保持一致:

  • 性能相对平稳
  • 底层的存储、网络和计算架构保持一致或者近似
  • 你应用的自动化框架必须和两个云中的 API 都兼容
  • 每个云中,运行应用的总成本(TCO)都应该在1/2-2倍的范围之内
  • 还有行为上的兼容性,意味着非 API 功能也需要吻合
  • 支持与相关公有云 API 的兼容

下面这个表格将有助于解释这些需求:

[译] 企业级 OpenStack 的六大需求(第 2 部分):开放架构和混合云兼容

当然,当你设计你的应用的时候,你还需要考虑避免和特定云的锁定,比如避免依赖 AWS 上的 DynamoDB,VMware 上的 HA/DRS,F5 上的 iRules 等等。
如果你不能满足这些需求,是无法获得兼容性的,应用的移植肯定会失败。应用的性能可能会在不同的云上变化很大,其中一个云上会最好;某些云可能缺少一些功能特性使得你的应用不能工作;如果没有行为上的兼容,你的自动化框架可能会不能工作。打个比方,如果应用中有个定时器,它假设虚机会在 30 分钟内启动,可是在一个云上虚机过了一到两个小时才启动起来。

所有这些问题,必须通过混合云兼容来解决。

OpenStack 需要一个参考架构

Linux 内核需要一个参考架构。实际上,每个 Linux 的主发行厂商都创造了自己的参考架构,因此,我们现在有不同的 Linux 操作系统分支。比如,有RedHat/Fedora/CentOS 分支和 Debian/Ubuntu 分支。这些纯粹的 x86 操作系统都有各自的参考架构型,在每个类型内的迁移是相对不需要怎么花费力气的。但是,当 RedHat 管理员去使用 Debian 时,他可能会有些迷茫,直到他完全知晓了两者的区别。OpenStack 的情况其实也没什么不同。

OpenStack,就像它的大多数开源同胞一样,是没有参考架构的。它只是云操作系统的内核。这既是它的优势,也是它的劣势。Linux 也是一样的。你可以给你的超级计算机获得 Cray Linux,你还可以给嵌入式 ARM 设备获得 Android。两者都是Linux,但是都有不同的架构,使得应用在两者之间无法迁移。OpenStack 是类似的,总有一天,大部分的 OpenStack 云之间没有兼容性,因为每个都有自己的架构。每个云都有自己的架构,是注定要成为 OpenSnowFlake(柜台里面各种不同款式的钻戒)。

OpenStack 驱动的企业级云操作系统需要有共同的参考架构。只有这样,你才能确保每个部署的云实例,都能和其它云实例兼容。目前,这些参考架构还没有出现。然而,假设 AWS 和 GCP 有一个单一的云参考架构(我们称之为“弹性云参考架构”),我们很难想象没有任何 OpenStack 参考架构会和这种架构非常类似。

说得更清楚一点,将来肯定会有多个参考架构最终脱颖而出。我也看到了在高性能领域出现的架构,以及别的行业比如石油和天然气行业。

企业级参考架构

最终,你需要打赌 OpenStack 企业级参考架构会在哪里落地,但是目前的数据表明,前10大公有云中,只有一两个是基于 OpenStack 的。

[译] 企业级 OpenStack 的六大需求(第 2 部分):开放架构和混合云兼容

如果企业希望敏捷、灵活和多选择,看起来显而易见,OpenStack 需要支持一种企业级参考架构,该架构会致力于打造和公有云领域的终极赢家兼容的混合云。这只是我的个人意见,目前看起来象 Amazon, Google, and Microsoft。

企业级 OpenStack 意味着一个企业级的参考架构,它会保证混合云兼容性和应用移植性。

第二部分总结

设计一个提供混合云兼容性的开放架构是目前的一个结论。可能对于如何实现会有争论,但是对于实用主义者来说,可以肯定的是,公有云领域将会出现各种赢家,而且前十名的公有云已经被非OpenStack方案占据了。我们需要做相应的准备。

更重要的是,当你期望一个企业产品的时候,记得要求一个开放的架构。

  下一篇文章中,我们讲探讨为下一代应用交付一个性能优异的、可扩展的和弹性的基础架构具体是指什么。

原文:The 6 Requirements of Enterprise-grade OpenStack,Posted on Apr 28, 2014 by Randy Bias

上一篇:poj1703Find them, Catch them(并查集以及路径压缩)


下一篇:WEB-INF目录下的jsp怎么引用外部文件:js,css等