OpenStack实践：私有云架构设计

OpenStack是一个由NASA（美国国家航空航天局）和Rackspace于2010年合作研发并发起的，以Apache许可证授权的自由软件和开放源代码项目。根据官网（https：／／www.openstack.org／）介绍“OpenStack is a cloud operating system that controls large pools of compute，storage，and networking resources throughout a datacenter，all managed through a dashboard that gives administrators control while empowering their users to provision resources through a web interface.”OpenStack是一个云操作系统，控制了数据中心海量的计算、存储和网络资源池。所有对这些资源管控，都是通过web接口让管理员更够授权所有用户去使用这些资源。根据官网介绍，我们可以知道，OpenStack早期的目标是对标AWS，提供一套公有云的IaaS软件，然而，从2010年OpenStack出现，到2014年Rackspace突然宣布不再以纯IaaS提供商的身份进入市场，而是作为一个服务提供商去给客户做服务，说明OpenStack在和AWS的竞争中完全失败了。2015年，著名的OpenStack公司Nebula倒闭，更是给整个IaaS产业蒙上了一层阴影。目前，虽然海外包括惠普在内的大厂，都宣布放弃OpenStack，然而在国内，虽然也有一些OpenStack公司也宣布倒闭，但由于IaaS开源软件没有太多选择，仍然有部分OpenStack创业公司和一些大公司在坚守并持续推动OpenStack发展和创新。由于OpenStack目前已经发展了近10年，有大量的用户在使用，属于主流的IaaS平台，我们也对OpenStack的架构也做一个研究。

笔者相信很多人都和笔者一样，第一次看完图3-3的OpenStack的架构图，会感觉无从下手，因为整个架构图给人的第一感觉是复杂，不同的组件之间，以及组件内部，都是虚虚实实的调用关系图，让初学者没法对整个系统形成一个很清晰的概念。而且从架构上看，各个组件之间都存在依赖关系，让初学者对这些组件的关系也需要花时间去理解。

(www.xing528.com)

图3-3　OpenStack架构图

事实上，OpenStack采用了微服务架构，微服务架构有一定的灵活性，但由于OpenStack的微服务大量分散于每一个计算节点，导致整个平台的维护成为挑战管理员的难题，管理员需要时刻关注每一个微服务的运行状态，由于Openstack是采用Python写的代码，笔者曾经多次遇到某个组件通过管理节点看到状态正常，但是当云平台调用到该组件功能的时候，突然发现已经不响应了，排查到该组件所在的物理机，会发现组件的Python进程已经hung住，日志没有任何输出，只能通过重启进程服务来解决。这样的情况为运维人员带来了巨大的烦恼，因为运维人员无法知道微服务化之后的组件真实的运行状态。升级更是无法想象的困难。OpenStack由于本身是nova、cinder、glance等等组件组合一起来的一个云平台，每个组件都维护着自己的服务，通过API和其他服务之间交互，当某个组件有新版本发布的时候，只会关注组件自身的升级方式，整个平台没有一个同步升级的机制，当某一个组件升级的过程中，可能会导致其他组件和该组件之间的交互出现问题，而大量组件升级的过程本身就是一种痛苦。因此，微服务架构虽然在可伸缩性上有一定优势，但是在稳定、易用和智能灵活性上，没有很好地达到预期。