【.com快译】大家认同OpenStack吗？这种开源云技术好用吗？各种争论。在本月OpenStack东京峰会上PraveenYalagandula的主题演讲中，Praveen描述了AviNetworks如何为其客户提供OpenStack解决方案，并引导他们从从业者的角度看问题。感兴趣的朋友不妨点这里（英文原版）查看这篇名为《OpenStack API中好的、坏的与丑的：一位应用程序开发者的观点》的演讲，其中包含了很多关于OpenStack采用和企业实践的真知灼见。接下来，我们将以访谈的形式探讨其主题。请介绍一下您在OpenStack技术方面的职能角色和实践经验。作为AviNetworks工程团队的一员，我的职责之一是设计和开发将Avi的下一代ADC与OpenStack组件相结合的解决方案。我们的架构基于SDN原则：以逻辑形式集中的AviController可以快速高效地编排数据平面工作单元，我们称之为服务引擎。OpenStack固有的核心API在与计算和网络资源配置方案（如Nova、Neutron）对接后，可以给我们带来理想的弹性效果：当工作负载较高时，AviController可以轻松创建更多的Dataplane虚拟机，并将它们连接起来到相应的网络；而在负载趋于缓和后，AviController可以通过缩放的形式减少资源消耗。OpenStackAPI的另一个优势是可以支持多租户机制，这让我们可以很容易地在产品内部隔离不同的租户——每个租户都有自己的一套或多套服务引擎，Administrators允许用户配置负载均衡机制根据实际需要。这种效果在基于硬件的负载均衡方案中是完全达不到的。但另一方面，我们在使用OpenStack技术来保证方案的高可用和高性能时遇到了困难。例如，由于OpenStack服务缺乏良好的API通知支持，我们不得不求助于定期检查。同时，OpenStack还没有API来关闭hypervisor之上的网络堆栈中的某些检查，这意味着很难通过纯粹的参考实现来实现高性能。不过随着OpenStack项目本身的成熟，上述大部分问题都得到了很好的解决。您认为OpenStack是否已准备好进入企业业务环境？能和我们分享一下有哪些企业选择了OpenStack，他们的典型用例是什么？为什么有这么多易用性突出的公有云？在提供服务的前提下，还有一些企业更愿意优先选择OpenStack？可以说，OpenStack距离全面进入企业业务环境的目标已经不远了，只是还差了点。我们在大约一年半前开始尝试集成OpenStack，但是很多公司已经开始对其进行检验和试验，而真正在OpenStack项目中取得成功的是那些真正完成了向DevOps方向发展的工程团队。转型企业。除此之外，像我们这样的企业在将AviNetworks解决方案添加到他们的环境之前，会花费大量时间调试OpenStack部署。但是，由于OpenStack已经相当成熟和稳定，我们现在看到它更广泛的普及和更稳定的运行状态，这意味着我们现在可以在不到一个小时的时间内从头开始一个企业。级LBaaS解决方案。此类部署托管的应用程序无处不在——从内部IT应用程序到面向公众的网站。这些部署场景中的关键驱动因素是整个堆栈的自助式自动配置。大多数企业都希望在内部私有云系统上达到与亚马逊AWS同等水平的弹性和易运维性。安全和监管方面的考虑是许多企业客户倾向于选择OpenStack私有云解决方案而不是公共云服务的主要原因。还有一个重要的原因是，企业客户在将应用迁移到OpenStack时，几乎不需要对这些遗留应用做太多的改动和调整，因为他们可以根据实际情况直接配置OpenStack安装环境——相比之下，迁移到公有云往往会对应用本身产生巨大的影响，并带来相当大的调整工作。例如，企业可以使用VLAN作为底层网络，在此基础上，可以使用OpenStack虚拟机作为应用逻辑，同时与OpenStack环境外已有的DB服务器连接。那我们换个角度来看这个问题。为什么不少企业不选择OpenStack？你见过任何反例或OpenStack失败的案例吗？如果OpenStack不足以解决问题，是否有其他开源工具可以作为补充？虽然虚拟化技术可以在不同操作系统的要求下，为不同的应用提供出色的资源复用效果，但必须承认，虚拟化本身也会带来相当大的负载强度。最近刚刚兴起的一大发展趋势是基于容器的生态系统，其最突出的卖点是将虚拟化技术的通用资源开销控制在极低的水平。据我了解，这个环境非常适合基于Linux发行版的应用程序，但不能真正服务于更复杂的多租户环境，如OpenStack（尤其是如果租户彼此隔离）。OpenStack解决方案的配置工作相当困难。那么企业如何正确评估其OpenStack需求，衡量OpenStack部署带来的投资回报水平呢？这点我很认同，OpenStack环境的配置过程确实不容易，尤其是大家都是从开源组件入手的时候。向下。您可以构建自己的Chef/Puppet工具链，但这也会带来更高的成本。你可以使用第三方的免费工具，但是它们或多或少的限制了我们可以选择的OpenStack版本或者我们提供的支持能力。企业需要组建专门的团队，资源配额大，既要了解内部应用需求，又要了解构建OpenStack云系统的复杂因素。我个人的建议是首先构建一组站点/区域蓝图，然后通过多次复制将它们扩展到所需的规模级别。谈到OpenStackAPI的优缺点，您认为企业解决相关痛点和缺失API的正确方式是什么？企业应该尝试自己解决问题，还是应该尝试与社区合作创建在正式版本中获取解决方案？理想情况下，最好的答案是与技术社区合作解决问题并将其纳入正式版本。根据我自己的经验，我们修复了一些错误并在许多方面提出了可以提高API质量的更改。但考虑到我们正在构建的应用程序类型——高性能Web服务——我们遇到的API问题实际上非常罕见，因为API中的功能很少用于其他应用程序。所以技术界当然对解决这些不起眼的问题不感兴趣。这种情况下，我们的解决办法就是自己动手，想办法克服这些困难。您认为OpenStack技术在文档、技术社区支持、客户变更请求等方面是否达到了“企业友好”的标准？在这方面我们能做些什么？我可以向你保证，OpenStack提供的面向开发人员的文档非常差。例如，我们很难找到所有不同服务可以支持的API语义——这直接导致不同类型的插件根据开发者的具体理解来选择API实现方向，因为API使用指南并没有提供任何信息。提供足够的描述信息。或许我们可以开发一个基准套件，其中包含完整的API选项列表，并确保所有插件都必须声明它们如何使用OpenStackAPI，以便在基准套件下正常运行。事实上，OpenStack基金会可以加大这方面的投入（不然很多工程技术人员根本不知道如何为项目做贡献），同时以认证的形式向各个厂商收费。关于OpenStackOpenStack是由NASA（美国国家航空航天局）和Rackspace共同开发发起的开源云计算管理平台项目。它由几个主要组件组成，完成特定的工作。OpenStack支持几乎所有类型的云环境。该项目的目标是提供一个易于实施、可扩展、丰富和标准化的云计算管理平台。OpenStack除了得到Rackspace和NASA的大力支持外，还有Dell、Citrix、Cisco、Canonical等重量级公司的贡献和支持。它致力于简化云部署过程并为其带来良好的可扩展性。原标题：OpenStackAPIs：好的、坏的和丑陋的
