人们喜欢 OpenStack 吗？它容易使用吗？
当我们着手回答这些问题时，我们发现了 Praveen Yalagandula 在本月 OpenStack 东京峰会 上关于 OpenStack API 的优点、缺点和不足：应用开发者的视角 的颇具争议的演讲。在本次采访中，Praveen 分享了 Avi Networks 如何为其客户交付 OpenStack 解决方案，并带来了从业者的视角。事实证明，这次演讲富有洞察力，对 OpenStack 的应用及其企业就绪状态提出了实用的观点。
请您介绍一下您的角色以及您在使用 OpenStack 方面的经验。
作为 Avi Networks 工程团队的一员，我的职责之一是设计和开发 Avi 的下一代 ADC 与 OpenStack 组件的集成。我们的架构基于 SDN 原则：逻辑上集中的 Avi 控制器协调快速高效的数据平面工作器，我们称之为服务引擎。
就实现弹性而言，OpenStack 坚实的内核 API（在计算和网络资源配置方面，即 Nova 和 Neutron）对我们来说非常有效：当工作负载很高时，Avi 控制器可以轻松创建更多数据平面 VM 并将其插入正确的网络；当负载下降时，它也可以按比例缩小以减少资源消耗。OpenStack API 的另一个优点是对多租户的支持，这使我们能够轻松地在我们的产品中提供租户隔离——每个租户都可以拥有自己的一组或多组服务引擎，管理员可以让用户以他们想要的任何方式配置负载均衡器。这对于基于硬件的负载均衡解决方案来说是不可能实现的。
另一方面，在 OpenStack 中为我们的解决方案实现高可用性和高性能并非一帆风顺。例如，由于 OpenStack 服务缺乏通过 API 提供的良好通知支持，我们不得不求助于定期检查。此外，由于缺乏 API 支持来关闭虚拟机监控程序上网络堆栈中完成的某些检查，因此使用参考实现实现高性能并非易事。不过，随着 OpenStack 本身正在成熟，这些方面中的许多方面都在变得更好。
您认为 OpenStack 是否已为企业做好准备？您能否与我们分享一下哪些类型的企业选择 OpenStack 以及它们的典型用例？当有许多易于使用的公有云可用时，为什么有人应该选择 OpenStack？
我会说它正在接近，但尚未完全就绪。当我们大约一年半前开始研究 OpenStack 集成时，虽然许多企业正在考虑和试验它，但真正成功的企业是那些拥有完全投入的转型为 DevOps 团队的工程师的企业。在其他地方，我们不得不花费更多的时间来调试实际的 OpenStack 部署，然后才能在其环境中部署 Avi Networks 解决方案。但是，随着 OpenStack 稳定性的提高，我们现在看到更广泛的应用和更稳定的安装，我们可以在不到一小时的时间内轻松实现企业级 LBaaS。
这些部署正在运行的应用类型无处不在——从内部 IT 应用到面向公众的网站。这些部署的关键驱动因素是通过全栈自动化实现自助服务配置。大多数企业都希望在本地私有云中实现类似 Amazon AWS 的弹性和运营简便性。与公有云相关的安全和监管问题是推动 OpenStack 私有云应用的原因之一。企业将其应用迁移到 OpenStack 而不是迁移到公有云的另一个重要原因是，这些（遗留）应用所需的更改要少得多——他们可以根据需要塑造他们的 OpenStack 安装。例如，他们可以使用 VLAN 作为底层网络，从而连接到 OpenStack 外部的现有数据库服务器，同时使用 OpenStack VM 来实现应用逻辑。
从另一个角度来看用例，为什么有人不应该选择 OpenStack？您见过的 OpenStack 的一些反模式或失败案例是什么？当 OpenStack 不适用时，可以使用哪些其他开源工具？
虽然虚拟化在具有不同操作系统要求的不同应用之间复用资源方面非常出色，但虚拟化的开销非常高。最近兴起的另一种模式是基于容器的生态系统，其中虚拟化开销非常低。据我了解，对于基于 Linux 的分布式应用来说，这是一个很好的环境，但它还没有像 OpenStack 那样强大的多租户方面（尤其是隔离）的原语。
设置 OpenStack 并不容易。企业如何正确估算其 OpenStack 需求并衡量 OpenStack 应用的投资回报率？
我同意设置它并不容易，特别是如果您只是从开源组件开始。您可以构建自己的 Chef/Puppet 工具链，但这会增加成本。您可以使用第三方免费工具，但它们都带有对其支持的部署类型或 OpenStack 版本的限制。企业需要拥有一支敬业、资源充足的团队，该团队既要了解内部应用需求，又要了解设置 OpenStack 云的复杂性。我的建议是架构一个站点/区域蓝图，然后根据需要多次复制它以进行扩展。
您 阐述了 您对 OpenStack API 优缺点和不足的看法。解决痛点和缺失 API 的正确方法是什么？企业应该尝试自行解决问题，还是与社区合作将其纳入官方版本？
理想情况下，答案是与社区合作，致力于修复和将其纳入官方版本。在我们的案例中，我们一直在修复错误并提出更改建议，以使 API 更好。但是由于我们正在构建的应用类型（高性能网络服务），我们遇到的某些 API 问题是由于 API 的某些不太常用的功能在其他应用中没有得到太多使用。因此，普通社区对修复它们的兴趣有限。我们对此的解决方案是绕过一些问题，并找到其他方法来克服它们。
您认为 OpenStack 在文档、社区支持和客户变更请求方面是否对企业友好？我们在这方面还能做些什么？
我会说开发人员的文档非常糟糕。例如，很难找到不同服务支持的所有 API 的语义——这也导致了这样一个事实，即不同的插件可以以他们想要的任何方式实现 API，因为 API 指南没有规定任何内容。因此，作为一个社区，我们可以做的一件事是规定每个 API 预期发生的事情。也许我们可以开发一个基准测试套件，全面覆盖包含所有选项的 API，并确保任何插件只有在可以成功运行该基准测试套件时才能声明为 OpenStack API 兼容。事实上，OpenStack 基金会可以资助这项工作（因为大多数工程师不会觉得它足够吸引人去贡献），并向供应商收取认证费用。
演讲者访谈
本文是 OpenStack 东京峰会 的演讲者访谈系列的一部分，OpenStack 东京峰会是面向 OpenStack 云软件开发人员、用户和管理员为期四天的会议.
1 条评论