人们对OpenStack是不是认同?这一开源云技术又是不是易于使用?

　　在我们回答上述问题之前，首先不妨看看人们对于OpenStack API的种种争议。在Praveen Yalagandula本月在OpenStack东京峰会上发表的主题演讲当中，Praveen介绍了Avi Networks公司怎样向其客户提供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提供的面向开发人员的说明文档十分差劲。举例来说，我们很难从中找到不同服务所能够支持的全部API语义——这也直接导致不同类型的插件随心所欲地根据开发者的具体理解选择API实现方向，因为API使用指南当中根本就没给出充分的说明信息。也许我们可开发出一套基准测试套件，在其中纳入完整的API选项清单，并确保所有插件都必须在声明其OpenStack API使用方式后才能在该基准套件的引导下正常运行。事实上，OpenStack基金会完全可在这方面加大投入(否则很多工程技术人员根本不知道该怎样为项目做出贡献)，同时以认证方式向各厂商收取费用。

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

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

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

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

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

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