《太阳的后羿》的热播掀起了一股新韩流。KakaoTalk是一款来自韩国的聊天和IP电话应用，这款应用的热度正在席卷整个韩国，同时也在许多其他国家吸引了大量的用户。

KakaoTalk由Kakao公司在2012年推出，其最大股东为腾讯。截止2015年12月，该应用的用户数量已经达到了2亿。目前该应用已经推出了15国语言的版本，可爱的贴图和活泼的表情符号为喧闹的消息应用市场带来了一股新风。

OpenStack.org的Superuser频道近日独家采访了KakaoTalk的云计算部门主管Andrew Kong，了解了他们在一开始就选择OpenStack的原因，以及他们是如何通过只有两名成员的团队来管理5000台虚拟机的。

KakaoTalk是如何开始OpenStack之旅的？

我们是从2013年开始使用OpenStack的。OpenStack一开始是在我们工程师自我管理的开发环境中作为一个试验项目。我们的公司领导希望拥有可扩展的监测、标准的/托管的/自动化的资源配置、自动化的应用部署、可自我扩展的资源管理、自动化的故障/错误侦测，以及可自动修复的资源。

我们查找了能够让我们实现这一目标的技术。当时我们并没有找到太多的选项。我们虽然拥有专业的知识和优秀的工程师，但是资金有限。我们最终决定使用开源的云软件。我们为此做了一些研究，但是也没有找到太多选择。

我们测试了OpenNebula、OpenStack和CloudStack，在当时并没有很多关于项目的文档。OpenStack拥有优秀的潜力，并且针对可扩展环境进行了精心设计。Charlie Choe不仅领导了Kakao OpenStack云的最初设计和开发工作，同时还是OpenStack 韩国社区的协调人。他将这一云命名为Krane，即Kakao + crane。这是Kakao OpenStack云的最初阶段。

目前你们正在OpenStack上运行什么类型的应用或工作负载？

我们的OpenStack云最初的目标仅仅是进行内部开发和测试。我们的开发人员选择了他们想要使用OpenStack云所处理的东西——大数据解决方案、网络应用、数据库，甚至是在OpenStack云上进行实时分析。

随着时间的发展，我们的开发人员看到了OpenStack在稳定性和速度方面的优势。他们开始询问：“我们也是否能够使用针对公共和外部服务的虚拟计算资源？”在我们这么做之前，我们的监控系统和配置数据库管理系统在管理虚拟资源方面遇到了一个问题。我们为此重建了监控系统，以在物理资源和虚拟资源方面拥有相同的监控/管理体验。在这一改变之后，我们的OpenStack云已经为承载生产级别的工作负载做好了准备。

Kakao公司数据中心

你们正在管理着5000台虚拟机，其中一些为生产级的虚拟机。那么你们管理这些虚拟机的团队在规模上有多大呢？

对于管理升级、漏洞补丁、新功能，我们只有两名专职人员来负责照顾这5000多台虚拟机。正如我在前面提到的那样，我们的部分虚拟机运行着生产级服务。不过这些虚拟机得到了基础设施团队的充分支持，例如自动故障报警、针对该公共服务的质量的系统工程支持和网络工程支持等。我们经常告诉我们的开发人员，要为出现错误做好准备。他们的应用应该具有容错能力，数据应该进行备份（我们通过Glance和Cinder提供了对象存储和容量），并且为可快速扩展的自动化部署和重新部署做好准备。

Kakao 的OpenStack“Dynamic Duo”（活力二人组，韩国著名的嘻哈二人组合）：Al (Eohyung lee) 和 Raymon (Hyun Ha)，他们管理着5000多台虚拟机。

像你们这么小的团队正在面临着哪些挑战？

尽管这两个人非常优秀，但是我们还是会感到缺乏照顾如此庞大计算资源的相关资源。这是一个挑战。为了让这一工作变得更为容易，我们研发了一个针对OpenStack的自动化开发、测试和部署系统，我们将这个系统称为“kfiled”，整个工作主要是由Andrew Kong开发完成的。

我们尝试着让所有的例行工作都实现自动化，但是目前这实际上是有难度的。除了计算节点上的OpenStack及其网络，其他团队也在照顾着计算节点上的服务虚拟机或网络。因此，整个基础设施团队（服务器、网络、数据库和安全）在OpenStack发生了问题后也会照顾它们。

Kakao的整个云服务团队

什么是你们通过OpenStack取得成功的关键？

我并不认为我们的案例是成功的或是失败的，但是OpenStack的成功有三大关键因素。

第一个关键因素是优秀的人才。如果你让他们干工作，你不用担心任何事情。

第二个关键因素是与现有计算资源匹配，让OpenStack资源能够遵循相同的规则/策略/身份认证。人们通常会用“陈旧的”这个术语来称呼它们，但是我不会使用这一术语，因为对于我们来说，OpenStack也正在逐步变得陈旧。对于所有的计算资源，我们拥有一个简单的策略，这让我们可以减少OpenStack云开发的工作量，但是这仍然是一项庞大的工作。

第三个关键因素是协作。我们不想建立起一个庞大的孤立系统，这只会让事情变得更糟糕，后续发展将变得更为困难。我们是OpenStack专家，我们也不得不成为OpenStack专家。我们的基础设施团队中的其他成员也都是他们领域内的专家，我们尊敬他们的知识、观点和经验。没有他们的帮助，这个云就无法工作。

你们的重大里程碑是什么？

三大重要技术正在进入我们的OpenStack云。

一个是数据中心级资源生命周期管理系统。它能够通过与模板比较（这个项目被称为CUOTA，即“自动将持续未被充分使用的项目扔入垃圾筒，continuous under-used object intotrash automatically”的缩写），发现哪些计算资源未被充分使用。内部统一计量信息中心（代号CROW）将对分析提供支持，分析结果将会把资源规模调整得更小。

其次是自动化的资源生产周期管理系统（代号Kengine）。它可以自动为某一服务增加或删除资源。

第三个是容器管理系统。它将融入到以我们的OpenStack云经验和技术为基础的公有云服务中。

在OpenStack day Korea，KakaoTalk在小组讨论会中的幻灯片。

是否还有其他关于运营/开发OpenStack的体验与大家分享？

开发是一回事，升级则是另外一回事。许多工具能够帮助“一键”部署OpenStack。但是当你尝试着对它们进行升级时，除了你自己的身体和头脑之外，没有工具能够帮助你。即便如此，对于升级还是有许多好的建议。

我建议：备份好你的数据库！然后对OpenStack数据库进行迁移测试——这可能会解决许多在升级中遇到的问题。例如，这个代码：(https://github.com/OpenStack/neutron/commit/73900fd0f4c1a343c880d8529aff4f51dd071d4b )会为Havana版Neutron增加一个新的表单。它们会增加关于哪个端口在Havana中的哪个管理程序上的信息，并将这些信息添加到在Havana版本中创建的虚拟机上。从Grizzly版本升级至Havana版本并不会导致任何问题，但是从Havana版本升级至Icehouse版本，如果这一信息是空的，那么虚拟机将会丢失Neutron网络，我们就丢失了在Havana版本之前创建的虚拟机。

我们从中汲取的宝贵教训是：备份，备份，再备份。

尝试着让简化你的基础设施资源管理，这将让自动化、云和OpenStack变得更为容易。

编者注：本文编译自superuser.openstack.org，作者为Nicole Matinelli，编译者Frank Chan。