转载

开发者对OpenStack API 的种种争议

在我们回答上述问题之前，首先不妨看看人们对于OpenStack API的种种争议。在Praveen Yalagandula本月在OpenStack东京峰会上发表的主题演讲当中，Praveen介绍了Avi Networks公司如何向其客户提供OpenStack解决方案并引导其从实践者的角度出发看待问题。感兴趣的朋友不妨点击此处(英文原文)查看这篇题为《OpenStack API中好的、坏的与丑的：一位应用程序开发者的观点》发言材料，其中包含大量与OpenStack采纳以及企业实践方面的透彻见解。而接下来，我们将以访谈的形式就其主旨进行探索。

请您介绍一下自己的职能角色以及在OpenStack技术方面的实践经验。

作为Avi Networks公司工程技术团队的成员之一，我的一大职能定位在于设计并开发出对应解决方案，从而将Avi公司的下一代ADC同OpenStack组件加以结合。我们的架构基于SDN原则：以逻辑形式进行集中的Avi Controller能够快速且高效地对数据平面工作单元进行编排，我们将其称为服务引擎。

OpenStack的固有核心API在与计算及网络资源配置方案(例如Nova以及Neutron)相对接后能够为我们带来非常理想的弹性成效：当工作负载处于高强度水平时，Avi Controller能够轻松创建出更多数据平面虚拟机，并将它们接入对应的网络当中; 而在负载趋于缓和后，Avi Controller又能够以规模伸缩的形式降低资源消耗。OpenStack API的另一大优势在于能够支持多租户机制，而这就使我们得以轻松在产品内部将不同租户彼此隔离开来——每位租户都拥有自己的一套或者多套服务引擎集，而管理员们则允许用户根据实际需求对负载均衡机制加以配置。这种效果在基于硬件的负载均衡解决方案当中根本无法实现。

但在另一方面，我们在利用OpenStack技术保障解决方案具备高可用性与高性能表现时则遇到了难题。举例来说，由于OpenStack服务缺乏通过API实现的良好通知支持能力，因此我们不得不采取定期检查的方式。与此同时，OpenStack还不具备能够对虚拟机管理程序之上网络堆栈内的某些检查进行关闭的API，这就意味着单纯利用参考实现手段很难切实带来高水平的性能表现。不过随着OpenStack项目自身的日趋成熟，大多数上述问题已经得到了很好的解决。

您认为OpenStack是否已经做好了入驻企业业务环境的准备?您是否能同我们分享目前有哪些企业已经选择了OpenStack，他们的典型用例又是什么?为什么在拥有众多易用性拔群的公有云服务的前提之下，仍有一些企业倾向于优先选择OpenStack呢?

可以说OpenStack距离全面入驻企业业务环境的目标已经不远了，但确实还差那么一点。我们当初开始尝试OpenStack整合工作是在大约一年半之前，不过很多企业当时已经开始对其进行审视与实验了，而真正能够在OpenStack项目中取得成功的是那些切实完成了工程技术团队向DevOps方向转型的企业。除此之外，像我们这样的企业需要耗费大量时间对OpenStack部署工作进行调试，而后才能将Avi Networks解决方案添加到其环境当中。不过由于OpenStack已经拥有相当成熟的稳定性，因此我们现在已经看到其愈发广泛的普及度以及更为稳定的运行状态，这意味着如今我们可以在一个小时之内从零开始启动一套企业级LBaaS方案。

这类部署方案所承载的应用程序可谓无处不在——从内部IT应用程序到面向公共的网站皆在其中。在这类部署场景当中，最为关键的驱动性因素在于以自助服务方式对整套堆栈进行自动化配置。大多数企业希望能够在内部私有云体系中实现与Amazon AWS相对等的弹性水平以及运维简便性。对于安全以及监管的考量正是众多企业客户倾向于选择OpenStack私有云方案而非公有云服务的主要理由。另一大重要原因在于，企业客户在将应用程序向OpenStack进行迁移时，其几乎不需要对这些遗留应用做出太多变更及调整，因为他们能够直接根据实际情况对OpenStack安装环境进行配置——相比之下，面向公有云的迁移则往往会给应用本身造成巨大影响并带来可观的调整工作量。举例来说，企业可以利用VLAN作为底层网络，并以此为基础在与OpenStack环境之外的现有DB服务器进行对接的同时，利用OpenStack虚拟机作为应用逻辑。

那么我们再从另一个角度审视这个问题，为什么相当一部分企业没有选择OpenStack?您是否见到过反例或者OpenStack故障?如果OpenStack不足以解决问题，是否还有其它开源工具能够作为补充?

虽然虚拟化技术能够在不同操作系统要求之下为不同应用程序提供非常出色的资源复用效果，但必须承认虚拟化本身也会带来相当可观的负载强度。最近刚刚兴起的一大发展趋势正是基于容器的生态系统，其最为显著的卖点就是将虚拟化技术的常规资源开销控制在极低水平。根据我的理解，这套环境对于基于Linux分发的应用程序来说非常理想，不过尚不能真正服务于OpenStack这类更为复杂的多租户环境(特别是在租户彼此隔离的条件下)。

OpenStack方案的配置工作颇具难度。那么一家企业该如何正确评估其OpenStack要求，并衡量OpenStack部署所带来的投资回报水平?

我认同这一点，OpenStack环境的配置过程确实不太容易，特别是在大家以开源组件作为起步的情况之下。大家可以建立自己的Chef/Puppet工具链，但这也会带来更为高昂的成本支出。大家可以利用第三方免费工具，但它们或多或少都会在我们所能够选择的OpenStack版本或者提供的支持能力方面有所局限。企业需要建立一支专门且拥有大量资源配额的团队，他们必须同时了解内部应用程序要求以及建立OpenStack云体系的复杂因素。我个人的建议是，大家首先构建一套站点/区域蓝图，而后通过多次复制来将其扩展至所需要的规模水平。

说到OpenStack API当中好的、坏的与丑的方面，您认为企业应该采取怎样的正确方式来解决相关痛点以及API缺失问题?企业是否应该尝试自行修复问题，还是应当尽量同社区配合从而在新的官方版本当中得到解决方案?

在理想情况下，最好的答案肯定是同技术社区开展合作来修复问题，并将其纳入官方版本当中。从我的亲身经历出发，我们曾经修复过一些bug并提出了能够提升API质量的多面变更建议。不过考虑到我们所构建的应用程序类型——一项高性能网络服务——我们在API当中所遇到的问题其实非常罕见，因为API中的此类功能在其它应用中几乎不会被用到。因此技术社区当然提不起兴趣来解决这些不起眼的问题。在这种状况下，我们的解决思路是亲自动手，找到办法克服这些难关。

那您认为OpenStack技术在说明文档、技术社区支持以及客户变更请求方面是否达到了“企业友善”这一标准?我们在这方面还能做出哪些努力。

我可以拍着胸脯向你保证，OpenStack提供的面向开发人员的说明文档非常差劲。举例来说，我们很难从中找到不同服务所能够支持的全部API语义——这也直接导致不同类型的插件随心所欲地根据开发者的具体理解选择API实现方向，因为API使用指南当中根本就没有给出充分的说明信息。也许我们可以开发出一套基准测试套件，在其中纳入完整的API选项清单，并确保所有插件都必须在声明其OpenStack API使用方式后才能在该基准套件的引导下正常运行。事实上，OpenStack基金会完全可以在这方面加大投入(否则很多工程技术人员根本不知道该如何为项目做出贡献)，同时以认证方式向各厂商收取费用。

正文到此结束