当公有云中的高IO工作负载成本节节高升时，媒体公司Ooyala将目光投向了OpenStack托管私有云。

虽然OpenStack在云采纳者行家中获得了大量的关注和人气，但要在数据中心里建立及管理它远不是件容易的事。当Ooyala，一家媒体公司，为某些世界最大的广播公司提供视频技术，想要将他们的高IO工作负载转移回本地时，他们的团队找到了OpenStack私有云。但他们并不是单打独斗。

SearchCloudComputing.com访问了Ooyala的基础架构和可靠性工程经理Ilan Rabinovitch，了解有关这家公司在大约三年前转向OpenStack的决策，公司如何在多云环境下运维以及与此相关的一些奇事。

为什么你们会找上OpenStack？第一次的实施是怎样的？

Rabinovitch：Ooyala是在云中诞生的。作为一个云供应商，我们从2007年以来就一直使用AWS。我们的联合创始人是第一届AWS创业挑战的冠军，所以云和自动化是一直在我们的DNA里面。当我们想要使用自己的本地数据中心时，我们早已经被AWS之类的服务API的易用性宠坏了。有太多我们能够实现的有助于加速工作的自动化。我们不想后退回去扩展自己的数据中心。所以OpenStack是个很自然的选择。我们想要获得AWS和其他云供应商一样的易用性和自动化。

你们回归数据中心的理由是什么？

Rabinovitch：总的来说，在很多与我们合作的云供应商中，我们发现IO的成本相当高。而且对于很多的大数据分析需求来说，IO在我们的工作负载中非常关键，回归数据中心可以让我们在那些方面获得更大的成功。

你们的团队成员有许多都是开源社区的贡献者。这种开源的背景对使用OpenStack有什么影响吗？

Rabinovitch：我们想要成为开源社区的积极参与者，有时候我们会跟MetaCloud和Cisco之类的供应商合作，作为一种消除业障的方式，当我们没有足够的能力贡献但又很想使用某些技术时。同Cisco/MetaCloud合作的好处之一是，我们可以对待自己的数据中心就有如我们对待AWS和Azure一样。我们是OpenStack服务的消费者，只是它恰好是在我们自己的数据中心和我们喜欢的硬件上运行。我们不需要成为OpenStack大大小小的细节专家。OpenStack是个很复杂的框架，如果回到两三年前，想要将所有这些不同的部分组成一个可用的私有云是一个相当艰巨的任务。在Ooyala内部可能就需要一支完整的团队。

那现在将这些部件组合起来有变得更容易吗？

Rabinovitch：我认为有几个OpenStack的发布版本已经走到了一起。我把它比作Linux的发布；你可以从无到有构建你自己的版本，但大部分情况下，这没什么意义。你要跟某个已经为你预打包好所有组件的人合作。OpenStack，总的来说是一个非常开放的框架。你可以有好几种方法来搭建它。

有考虑过其他的私有云平台吗？

Rabinovitch：那段时间我们考虑过一些其他的OpenStack厂商。我们也研究过CloudStack和Eucalyptus。只是看到了OpenStack所有的势头，我们就知道那就是我们想要走的方向。在其他厂商那边，有几家组织会介入并成为OpenStack咨询商。他们会来这里并替我们架设OpenStack然后他们会交给我们继续运行。这跟托管服务完全不同。如果OpenStack有什么问题的话，我们就打电话给MetaCloud。这跟某些当时的咨询商是完全不同的状况。这个，加上MetaCloud的团队背景是来自很多大型Web运维，使得我们很相信他们的能力。

Ooyala还使用了那些其他的云供应商？如何使用？

Rabinovitch：我们除了OpenStack也使用AWS和Azure。我们在每个环境中都混合了各种工作负载。不同的云适合不同的工作负载。比如说，我们有些高IO的工作负载就比较适合我们数据中心里的OpenStack环境。虽然是这样，我们靠OpenStack也有了一些国际业务，在那个时候有些云厂商在国际上还没有提供业务，所以我们就跟MetaCloud一起打造了些业务。

你们如何管理这个多云环境？你们是使用第三方的工具还是使用每个供应商提供的自有工具？

Rabinovitch：都有。我们内部也开发了不少自己的工具。当中有很多是当我们还是纯EC2或主要是EC2的时期开发的。现在我们也使用别的云，不管是我们内部的OpenStack或是自带API的Azure，我们拓展了这些工具来使用这些云。有很多很好的库可以做到这一点。我们对于Chef Provisioning或HashiCorp的Terraform之类的工具感到很兴奋，它们使得跨云之间的资源可以使用同样的语言这点变得更直接了一些。

AWS有CloudFormations而OpenStack也有跟Heat配合的后续功能；我们可以用这些来搭建，但我们每次都要为每一种云搭建一套完全相同的东西。我们希望未来可以看到这些框架归总到一起，提供一个跨厂商的统一API。

作为一个多云企业最大的挑战是什么？

Rabinovitch：在很多情况下，在云厂商提供的技术和服务方面，我们都只能有效使用到最低的最大公约数。我不知道这算不算是一个挑战；我只能说它是一个很有意思的怪现象。许多公司，当你刚开始使用EC2或Azure或OpenStack时，你就立刻跳跃到使用CloudFormations和弹性负载平衡（ELB）和Auto Scaling Group。如果你要使用多云时，你很早就必须决定这是你要长期使用的选择，不可以让某些工作负载被某个服务绑死。或者你必须要将这种弹性建立在你的应用上，这样才能与DynamoDB和Azure的相应数据存储互换配合。这是个很大的问题。

另一个问题是工具的使用。有很长一段时间，许多工具厂商只选择支持一种云，或者是在报表上或者是自动化上。这种情况正在开始改变，但实际上，我们不得不自己构造很多这样的工具，取决于我们多早在这些项目上用到。我觉得这对我们来说是很大的困扰，发现自己处在这样一种状况中，内部自行开发很多的自动化和编排/工具，而没有一个特定的可供我们采用的工具。如果你看看现在大多数的云管理厂商，他们都支持所有或很多种的云，尤其是AWS，OpenStack和Azure。在未来一年左右，你会看到工具会简化成为一家多云公司的进程。