VMware 与 OpenStack 如何最佳整合？

在过去12个月中，“OpenStack 目前已经在风口浪尖之上” 这句话我们已经从运营商或分析师口中听到了?可事实上，很多公司仍在评估OpenStack并且试图确定如何将OpenStack与公司的IT策略整合。这也符合云计算等前沿技术的发展规律，个人的观点是：OpenStack正在经历由技术创新、实践向主流应用普及的发展过程。

hybrid-vsphere.2

我也和很多在早期就开始评估或在小型项目中应用OpenStack的公司谈过，他们的大多数如今还是VMware的忠实客户，并且运行的也都是传统应用，他们非常明白OpenStack不可忽视，但是他们很难真正理解OpenStack的真正价值，也很难理解它是如何影响他们的vSphere环境的。我们谈话中最常出现的问题如下：

OpenStack作为一个开源的虚拟机管理器，它能否替代我当前的ESXi 服务器么？
在OpenStack和vSphere之间，有没有一些特色功能的差异？如高可用性、vMotion，分布式资源调度等。
我们能否或者应否将OpenStack与vSphere混合使用？
有没有一些原因让我们同时运行OpenStack和vSphere？
我对于这些问题的答案通常从三个方面来说明问题的答案：

传统应用和云应用的区别
传统应用型架构与云应用消费型架构的不同
对使用OpenStack与vSphere过程中的一些选项进行具体说明
虚拟化和云计算
hybrid-vsphere.3

最开始对于我个人来说，当我与客户谈起vSphere和OpenStack时，重点要强调的就是传统应用架构与云计算架构的设计理念的不同。在这里，我想把重点放在基于虚拟化技术的传统应用架构上来，如ESX虚拟机管理器和vSphere，他们作为虚拟化技术的突出代表，可以在少数大型服务器之上虚拟化出很多小型服务器。这种工作机制在应用是单一架构时表现得相当不错，如Oracle或者Microsoft Exchange。今天，每一个这种传统类型应用都包裹在一个单独的虚拟机之中，只能通过ESXi虚拟机管理器扩展应用规模。在传统架构下，高可用的实现可以通过集群应用来实现，比如Oracle的Real Application Clusters；然而这同时也是非常复杂且昂贵的，并且大多数应用不支持集群式部署。大多数VMware用户则会选择将应用服务器作为虚拟机运行在vSphere集群之上，依赖于vSphere的高可用性和vMotion来提供基础架构的恢复和冗余。诚然这些解决办法都可以实现高可用，但是他们都需要特定的部署架构，如依赖共享存储等，这也一定程度地给架构的扩展性带来挑战。

云计算，较比传统虚拟化技术而言，更加适合不同类型的应用，如MongoDB和Hadoop。 像OpenStack这样的云平台，在最初就被设计成适应分布式应用的架构，应用的组件在OpenStack平台中跨越了多个物理或虚拟设备。这些类型的应用也被设计成随着规模的增加，可以通过添加应用实例或者重新平衡应用实例间的负载；另一个云计算平台背后的设计原则是，鉴于应用的分布式特性，应用弹性控制权是掌握在应用自身手里而不在底层基础架构平台手中。OpenStack这种设计常常被VMware领域的同学们所误解为是它的确定或者不成熟的地方，“缺乏”如vSphere 高可用这种功能被看作是OpenStack还没有在生产级领域准备好。

但是，这是传统应用架构与云计算架构的设计理念不同所带来的误解。在云上运行的分布式应用（业内称此类型应用为“原生云应用”）已经降低了应用部署花费和可用性的门槛。通过将应用的弹性化需求转移，云平台不再需要共享所有资源的架构如应用共享存储。这种改变促进了用户对构建高可扩展性云平台的需求，不单单是基础架构层，架构需要设计成包含多层以更加适合下一代大规模应用的部署。

消费模式
一旦客户了解了以上两种架构设计原则的不同，我们就可以开始讨论不同架构的消费模式问题了。这里也将区分这两种消费模式的不同。比如：

legacy models

除了在我们自己的数据中心上运行裸机服务器和虚拟化技术，公司可以应用主机托管产品，如Rackspace的专用vCenter产品或在VMware的vCloud混合云产品。这两者都是建立在VMware技术基础之上，为用户提供虚拟化解决方案。两者的设计架构都较适用于那些不需要块数部署的、不依赖虚拟化基础设施提供弹性和可扩展性的传统型应用。

hybrid-vsphere.7

相比之下，云计算型架构的消费模式通常开始于公有云的使用，将来向私有云部署上扩展。在这里，我们关注的重点仍是通过常用商用硬件能够实现快速资源供给、高可扩展、适应下一代应用的云架构。

vSphere与OpenStack整合
到目前为止我们应该很清楚了，VMware vSphere与OpenStack两者任何一个都无法满足多种应用类型。Rackspace就有一些用户，由于他们应用的分布式本质，用户已经将应用放到基于OpenStack的共有云或私有云之上了。相反，大多数用户都运营着传统型应用，这些应用通常运行在裸机或在虚拟化架构之上，并且它们并不那么容易地去迁移到如OpenStack这样的云架构之上。对于这些用户，共存、非替代可能是应用OpenStack的正确之道。这条混合之路通常伴随三种解决方案，如下：

孤岛型解决方案

hybrid-vsphere.8

孤岛型架构是用户选择最多的。通常，这种方案涉及到保存在vSphere上的现有遗留传统应用和在独立OpenStack云上建立新应用的抉择。虽然这是最最无痛的融合OpenStack的解决方案，但是它保持了IT基础架构的孤岛劣势，并且增加了运维和复杂性，通常我们需要两个独立团队去维护这两套独立系统，这也会带来额外的开销。

多虚拟机管理器集成解决方案

hybrid-vsphere.9

另一种解决方案是基于VMware已完成的工作将vSphere与OpenStack相集成。这种方案类似于孤岛型解决方案，传统型应用仍然运行在vSphere之上，而新的下一代应用则运行在新的虚拟机管理器之上，如KVM或在XEN。在这种情况下，OpenStack成为多虚拟机管理器的控制平台，它将允许新创建的应用被分配到最适合他们的虚拟机管理平台之上。这种架构的主要缺点是vSphere与OpenStack整合这种方案非常新，这带来了很多问题，比如两平台的整合边缘过于粗糙仍需改进，比如平台的资源如何调度等问题仍然需要解决。

Rackspace的混合实践方案

hybrid-vsphere.10

上图是Rackspace给出的OpenStack与vSphere混合解决方案。在分离管理平台这方面，这种架构非常像孤岛型架构，此外，它还保证不同类型应用可以被部署到合适的虚拟机管理平台之上。

这里的目标是保持架构的独立，整合两个环境的运维团队使他们可以共同工作来打造一个集成的平台。这其中的一个关键是应用技术，如Rackspace的RackConnect把这些基础架构连接起来，使每个架构都可以与其他架构协同工作。这里举一个例子，一个应用运行在基于OpenStack的Rackspace私有云之上，通过RackConnect与运行在vSphere集群上的Oracle数据库相连接。
作者：jackychen
参考链接：http://www.rackspace.com/blog/go ... here-and-openstack/