公司有八九台服务器一直由我负责运维,这些服务器的配置参次不齐,主要部署了研发的持续集成环境、测试环境、性能压测环境、maven私服等一系列支撑日常开发活动的服务器。之前的办法是在这些服务器利用KVM虚拟化技术手工创建虚拟机来满足需求,最常用到的命令可能就是qemu-img、virsh了。这种办法主要存在以下的问题:

  • 需要将每个主机上跑了哪些主机这些信息记录下来,最好形成表格,一旦有变更一定是同步更新表格
  • 虚拟机创建、销毁、迁移得手工敲命令完成,即使形成一些较通用的工具脚本,还是有不少敲命令的工作量
  • 由于公司机房安全限制,不允许机房里启动DHCP服务器,每个虚拟机镜像创建完毕之后,需要自行敲命令使用libguestfs相关命令修改虚拟机镜像文件系统中的网络配置文件,以使创建的虚拟机启动好后,自行配置好IP地址、主机名等信息。

其实早就知道针对企业内部私有云可以采用openstack,但每次一看到openstack部署那浩浩荡荡的文档就打了退堂鼓。这个周末有空,终于有时间将看过到的openstack部署过程实践一把了。我基本上是参照在CentOS7上部署openstack mitaka版的官方文档来操作的,这里就不记录详细的过程了,重点写一下安装过程中坑。

安装环境概览

为了部署的方便,我仅在一台物理上部署openstack的Identity service(keystone)、Image service(glance)、Compute service(nova)、Networking service(neutron)、Block Storage service(cinder)、Dashboard(horizon)。由于只是测试部署的过程及试用openstack的功能,并没有部署Object Storage service(swift)。同时Networking service采用的是Provider networks的方案。

整个部署还是比较简单的。

首先看一下openstack各组成部分的概览,大概理解各组成部分之间的关系,根据自身需求确定好网络方案。

然后就是按文档准备环境,这里主要就是生成安全的密码并记录下来、确定管理网络与工作网络的网络拓扑、配置时间同步服务、配置yum软件安装源、安装配置SQL数据库、安装配置NoSQL数据库、安装配置消息队列、安装配置内存缓存服务。

然后就是按照各部分的部署文档一步步部署就是了。大部分openstack组件的安装过程无非是以下几个步骤(有的组件还需要在控制节点及计算节点分别进行安装配置):

  • 创建组件对应的SQL数据库及授予访问该数据库的用户权限
  • 创建管理该组件在keystone中对应服务的用户
  • 在keystone中将该组件注册为服务,并创建服务的API访问端点(公开的、内部的、管理的)
  • 安装该组件的rpm包,修改该组件的一系列配置文件
  • 初始化组件对应的SQL数据库的表结构
  • 设置组件对应的系统服务开机自启并启动

在安装的过程中其实也慢慢对openstack中说到的Domain、Project、Role、User有一些感觉,后来看到了IBM的一篇文章,才对openstack中的授权模型及它的鉴权逻辑有进一步理解。

使用openstack

还是按照文档尝试在openstack平台上启动一个虚拟机。其实在这篇文章里的所有操作都可以通过访问dashboard来操作,而且如果只是为了使用openstack,我也建议应该使用dashboard界面操作,毕竟今后使用起来会经常创建虚拟机,早点熟悉界面操作也有益处。

创建并启动虚拟机这里有一个坑,我发现完全通过界面无法使用操作系统的安装ISO给一个虚拟机全新安装系统,每次总是报”no usable disks hava been found”,后来google后才知道现在只有两种解决方法:

  • 要么使用传统KVM虚拟化方案,装好系统后,拿到系统的镜像文件,将镜像文件上传至openstack的镜像服务,再以此镜像创建虚拟机
  • 要么下载操作系统的虚拟机镜像文件(如http://docs.openstack.org/image-guide/obtain-images.html),将镜像文件上传至openstack的镜像服务,再以此镜像创建虚拟机

使用体会

简单试用了openstack的功能后,记录一下自己的体会。

openstack作为云计算IaaS的一站式解决方案,总的来说架构还是比较清晰的,各组件之间的交互方式也比较统一(都是利用keystone这个服务注册框架来完成服务之间的交互的),各个组件在设计初也考虑了多种底层实现方案,用户可根据自己的实际情况修改配置文件来满足需求。

不过缺点也比较明显,我感觉如下:

  • 各个逻辑组成划分得比较细,如果只是搭建一个不超过10台物理机的小型私有云环境,使用openstack就会感觉逻辑组成部分过多了,增大了部署的复杂度
  • 各个组件在设计时考虑了太多底层实现方案,导致配置文件里的配置项相当多,每个配置项的取值也相当多,十分考验部署能力
  • 对虚拟机libvirt细粒度的调整能力不足,比如想调整某个虚拟机的xml定义变得很复杂。
  • 组件过多,比较消耗系统资源,如图

openstack相关进程消耗

其实这几天我一直在思考在目前研发这个环境中,最适合的私有云管理平台是什么,可以肯定openstack肯定是不太适合。经过几天的思考,大致有一个方案,接下来我会将这个方案实践一下,如果成功,我会将这个方案写出来。

参考

http://docs.openstack.org/mitaka/install-guide-rdo http://www.ibm.com/developerworks/cn/cloud/library/1506_yuwz_keystonev3/index.html