《OpenStack实战》是曼宁新近出版的一本旨在为读者介绍用于云计算(IaaS)的OpenStack平台。InfoQ 借新书发布的机会采访了本书的作者：V. K. Cody Bumgardner。
OpenStack 是用于公有或私有的云计算平台。OpenStack 并非是又一个虚拟化工具，相反，它是一个框架，有效利用现有的虚拟化工具来构建和管理云。OpenStack 的应用程序接口在物理或虚拟的硬件和软件资源之上提供了一个通用的抽象层，而且，反过来再通过它们来管理。
本书的目标读者是开发者、架构师和系统管理员。本书提供了部署云计算解决方案的详细指南，需要特别提醒的是，这本书是一种渐进的方式描述如何使用 OpenStack 来构建一个云平台。其第一步，是在单个节点环境下自动部署来搭建开发环境。然后，开始了细节的描述，告诉读者如何的去手动部署、一步一步的、在多节点环境下的情况。接下来是使用自动化的部署和管理工具来部署一个具有生产质量的 OpenStack 环境。但是据 Bumgardner 称，书中所描述的架构并不能适合所有的生产环境，只是取了较为大众化的例子。
部署 OpenStack 能够带来的其中一个好处就是防止软、硬件的厂商锁定，这得归功于使用 OpenStack 来管理资源，而不是直接使用厂商所提供的组件，这也就是意味着厂商的组件随时都可以被替换掉，OpenStack 的这种做法的不好的地方就在于仅支持一些通用的、必须的特性，而损失了使用厂商组件的特定功能。
但是话说回来，注意厂商锁定这个含义的背后，亦不应被忽视。由于云平台现在还缺乏一个公认的标准，使用 OpenStack 也就是被锁定了 OpenStack 本身，目前来说并不能保证能够迁移到其它的云框架中。
本书个章节的大体概览：
第一章介绍了OpenStack，以及 OpenStack 能为公司带来什么；
第二章则是介绍了使用 OpenStack 图形界面程序来部署一台单节点的 OpenStack 系统；在第三章，做和第二章同样的事情，不过就是开始使用命令行罢了。
第五章～第八章，进一步为读者手动部署多节点的 OpenStack 云平台提供向导指南，每一章都对应了特定的主要组件，包括计算、存储、以及网络。书中描述了读者应该如何为这些组件管理相应的服务（Nova、Neutron、Cinder 等等），并且还提供了这些组件之间的交互和其背后的技术的细节，如内核空间、OVS、LVM等等；
其余的章节则介绍了 OpenStack 使用到的自动化工具和其它额外的组件，有用于存储的 Ceph、用于部署的 Fuel、以及用于云编排的 Heat 和 Ubuntu Juju。
OpenStack 是一个复杂的系统，其子项目实在是太多了，很难用一本书来描述它们全部的内容。更何况，《OpenStack 实战》对于内容的定位就是为读者构建自己的私有云平台部署提供最为基本的理解和开启这段旅程的基础知识。
InfoQ 就这本书的内容采访了 V. K. Cody Bumgardner，希望能够更加深入的了解这本书。
InfoQ: 您能解释下写此书背后的动力是什么？为什么认为有必要写这样的一本书？
Bumgardner:在 OpenStack 还是 Grizzly 的时候，我开始渐渐的相信 OpenStack 在一些方面是可以使用到生产环境中的了，至少对于一些应用来说可以。几年下来，我组织了很多场 OpenStack 的研讨会，尝试来解释 OpenStack 组件，以及在企业内部该如何利用它来部署私有云平台，在我们早期的研讨会上，让我渐渐明白了一些事情，让传统的 IT 部门去放弃他们所控制的资源是一件非常困难的事情，而且对于基础设施的管理的传统思维也是非常难以改变的。我写这本书是那些99%的未来被迫使用云的企业，而不是已经开始使用大型云环境的企业。
InfoQ: 请您以简短的形式描述下你在 OpenStack 项目和普遍的云计算技术的背景和经验。
Bumgardner:我本人从事 IT 行业20多年，涉及的角色有：策略规划、技术、领导者，以及各个岗位：IT 架构师、软件开发、网络、研究、系统和安全。我目前在一家大型的公共综合院校做首席技术架构师，也是一名计算机科学的博士生，研究方向是分布式系统的优化。我开始使用 OpenStack 是在2012年它的 Essex 版本发布时，从此一发不可收拾，直到现在。
InfoQ: 有超过500家公司加入到此项目中来，OpenStack 到底承诺了什么？为什么大家这么关注它？
Bumgardner:我以为 OpenStack 对于基础设施所做的事情，犹如高级编程语言所做的事情那样，在应用程序的可移植性和开发时间上有巨大优势。在开销上的，如软／硬件相关的、以及资源利用和部署的时间，若使用得当，OpenStack 是可以帮助用户节省不少钱的。OpenStack 是作为一个“云操作系统”这样一个角色，在不关心底层物理环境的情况下，为用户提供友好的接口。
InfoQ: 来自 OpenStack 的哪一个应用是您最为偏爱的并从中受益？OpenStack 的关键特性是？
Bumgardner:从 OpenStack 的角度来描述应用程序的类型是一件非常容易的事情，因为它非常的稀有。举例来说，那些非共享的、静态的、或者是高度专业化的基础设施很难从 OpenStack 受益。然而,这些应用程序是少之又少,甚至这样专业化的技术原因就更加的少了。
InfoQ: OpenStack 能够被大多数厂商所接受，其最为重要的标准是什么？在这方面您是如何评估 OpenStack 成熟度的？
Bumgardner:对于供应商来说，放弃竞争商业管理环境是非正常现象，所以我无法确定你将会看到采用大量的供应商驱动的场景。事实上，我认为我们要避免看到厂商支持的软件定义网络（SDN）的情形，他们经常会搞出一些仅实现标准的一小部分，然后会和你说“是的，我们就是这么做的。” 站在供应商社区之外是 OpenStack 之所以存在的战略优势，对于供应商来说只能利用一些技术作为他们产品的一部分。
InfoQ: OpenStack 是一系列的不同的组件的总称。在书中，您对于介绍这些组件作了出色的工作，且描述了如何使用它们，但是构建一个基于 OpenStack 的系统仍然是一个艰巨的任务。在学习如何使用 OpenStack 过程中那些关键点是应该时刻记住的？
Bumgardner:你在使用计算器的时候，是毋需证明数学定理的。但是你最好还是有一点数学知识的基础。 我以为 OpenStack 也是同样的道理，你不一定非得是网络、系统或者是自动化的专家才能去使用 OpenStack，你个人的水平决定了去选择什么样的途径。我自己的经历，我看到很多来自各个领域的研究专家将 OpenStack 的代码克隆下来去部署，也有一些缺少或没有经验的（或者说没有时间的）人们使用了有商业支持的自动化部署工具。
InfoQ: 请你描述一下从传统 IT 管理转换为让 OpenStack 接管的变化？OpenStack 能够提供什么样的优势？
Bumgardner:颠覆性的技术让人精神为之振奋，但随之而来的是对于改变的恐惧。高效的 IT 团队会评估新的技术，并尝试去理解它们的战略价值，而这都会在供应商出现之前就开始做了。这个时候，你可以选择引领变化，或者是选择让变化去引领你，后者的滋味可能不太好受。而对于 OpenStack 的采用，对于公司来说其实是掌握了引领趋势的巨大优势。正如我在书中所讨论的一样，如果你仅仅是将 OpenStack 视为虚拟服务器的一个替代的话，那你就会错过太多。IT 组织应该转换他们的思维方式了，从考虑如何提供基础设施向成为一个资源的代理的转变，当然这是我个人的一己之见。
InfoQ: 对于开发者从传统的开发模式转向到为 OpenStack 开发应用程序来说有哪些挑战？为什么开发者应将它们的应用移入OpenStack？
Bumgardner:如果说哪个团队能从 OpenStack 获益最多，那一定是开发和测试。重构基础设施的能力，对于在生产环境中的测试是无价的。“软件定义”基础设施的能力，以及软件依赖、乃至于应用程序大大减少部署时间。以及所有那些无须通过请求 IT 部门就可以随意完成的能力......简直是让人垂涎三尺。
InfoQ: 你认为目前的 OpenStack 有哪些局限性和复杂性？
Bumgardner:任何系统（计算、治理、原始）的强大和软肋之处都在于其各个组件的产品及其安排。集中的控制，可以得到快速的响应，但是在扩展上会遇到问题。完美的分布式系统等同于分布式的控制提供了优秀的扩展能力，那么就会缺少控制。
我非常的幸运，亲历了Linux从 .99版本到成熟的整个阶段，所谓的 Linux，就是大家称之为内核，今天看到有一千八百万行代码的庞然大“物”，几乎运行在所有可能的领域的设备中。Linux 今天的成功，是因为它有着强有力的中心愿景和领导力（linus），至少部分是这样。那么，OpenStack 基金会则是采用了另外一种方法，广阔的分布式和随时间变化的治理。OpenStack 的强大之处同时也是它的软肋，如过于分散的注意力、愿景的散乱、控制的分布等。
InfoQ: 和大家分享下您对于 OpenStack 未来开发的一些想法吧？哪些新的功能是您最想看到的？有没有你认为非常必要的，但是 OpenStack 的功能列表中没有开发计划的？
Bumgardner:我个人可能会非常的偏向于我所研究的领域。我认为应该将注意力放在对于所有 OpenStack 组件的流监控和测量上。另外，我也非常的希望看到资源调度方面的努力，哪怕是一个调度驱动器了。当然，我最为愿意向大家极力推进定是——OpenStack 的社区之美。
本文转载自infoQ
