OpenStack作为目前发展的最为红火的开源云平台项目,已经成功形成了自己的生态圈,得到了各大厂商的关注和支持,笔者从两年前关注OpenStack并尝试手动搭建OpenStack,期间经历了各种部署问题,并最终找到了RDO这样的快速部署工具,得以窥见OpenStack的全貌。从笔者来看,OpenStack虽然正在博得整个云计算技术圈的关注,但从公有云生态圈来说,OpenStack落地过程也不尽如人意:2015年10月,作为OpenStack的创始机构之一,Rackspace宣布与AWS合作,而合作的重点竟然是为AWS提供运营支持,这与Rackspace当年建立OpenStack时提出“成为和AWS一样的公有云平台”落差甚大;很快,2016年1月,惠普也宣布关闭基于OpenStack的公有云服务Helion,决定专注私有云市场。OpenStack虽然已经被证明不适合大规模的公有云市场,但也未必适合私有云。 首先,选择开源私有云平台的大多是中小企业,中小企业的特点是希望能够以最低的成本得到最高的回报,而OpenStack拿来作为私有云,体量太大,学习成本较高,对企业本身的IT管理员有较高的技术水平要求;其次,OpenStack升级较为困难,这使得企业无法获得业务迁移到云平台后的持续技术回报;最后,OpenStack的稳定性现在还存在问题,企业需要有专业的OpenStack运维人员才能保证业务跑在云平台上不出问题。 近日,一个新的云平台项目: ZStack正在快速发展壮大,在其官方主页上宣称只需要5分钟即可完成一个云平台的搭建,支持云平台无缝升级,并且从架构上解决了云平台稳定性和易用性的难题。ZStack宣告已经从架构层面解决了云平台面临的各种问题无疑对云计算领域的技术人员充满了吸引力。作为新技术的爱好者,笔者决定先对两个云平台的部署做一次实战对比。 OpenStack部署Liberty版本首先,笔者在自己的机器上使用RDO实战部署一个最新版本的OpenStack,虽然之前已经使用过RDO部署过OpenStack,但已经是一年多前的事情,并且版本也比较老,当时是基于Juno版本部署的,看到RDO官网上现在的版本已经支持到Liberty,那正好体验一下新版本的新功能。 系统环境:
- Centos 7.2
- 硬件环境:
- 8核 CPU
- 16 GB 内存
- 200 GB硬盘 - sudo yum install -y https://www.rdoproject.org/repos/rdo-release.rpm
- sudo yum update -y
- sudo yum install -y openstack-packstack
复制代码
安装过程: 之后是使用默认生成的answer-file配置文件来安装,为了更好的了解安装部署的配置,这里我们可以手动通过以下命令先生成一个部署文件: - packstack —gen-answer-file=deploy.conf
复制代码
用户可以根据自己的需要修改其中的配置内容,包括数据库密码,默认密码,安装哪些组件,计算节点和管理节点的IP地址等。我这里主要修改了默认密码,计算节点和管理节点默认使用本机IP。 配置好部署文件后,在当前目录下直接使用以下命令部署: - packstack —answer-file=deploy.conf
复制代码
后面按照RDO官方文档的描述,只需要等待就可以了。
然而,笔者等待半个多小时后部署程序就停止工作了,报错如下:
根据提示,应该是下载python-OpenStackclient出错,这种情况的处理方法是重跑一遍puppet部署脚本,重试下载过程:- packstack —answer-file=deploy.conf
复制代码
等待一个小时后,出现如下报错: 根据报错提示,网络速度太慢,这种情况在OpenStack下载过程中显得很常见,根本问题是RDO相关的yum源和机器默认的yum源都在国外服务器,笔者这里建议用户可以自己搭建一个私有yum源或者配置一些国内提供的yum源来解决经常性部署时候的速度问题。
再次重跑packstack来部署: - packstack —answer-file=deploy.conf
复制代码
很快,又碰到一个新的问题: 提示很清晰,Delta RPM 没有安装,这里不知道为什么yum没有自己解析依赖并安装,这个问题的解决方法也很简单,手动安装一下即可:
安装完后手动再跑一次packstack部署程序: - packstack —answer-file=deploy.conf
复制代码
解决方法和前面一样,再次重跑packstack部署程序: - packstack —answer-file=deploy.conf
复制代码
又遇到同样的问题: 再次重跑packstack部署程序: - packstack —answer-file=deploy.conf
复制代码
经过几个小时的安装排错过程,终于安装完毕:
部署完毕以后,需要新增一个br-ex,把原先的默认网卡eth0作为bridge的一个端口,配置如下:
之后就可以登录Horizon来体验一下新版的OpenStack功能,但是一登录就发现有问题,界面右上角会有以下错误提示:
立刻到后台看了一下,cinder的log会有以下报错:- Caught error: Not enough information to determine URL. Provide either auth_url or endpoint
复制代码
Google了一下,找到了问题的原因: 这个是RDO的bug导致,没有在cinder的配置文件里增加keystone相关的信息,导致cinder如法认证。
解决这个问题后,使用如下命令重启OpenStack - OpenStack-service restart
复制代码
奇怪的事情发生了,keystone无法认证了,horizon登陆不进去,又用OpenStack service看了一下,果然,keystone停掉了: Keystone重启没有成功,再去看一下keystone 的log: 会发现Address already in use,那就需要看一下到底是哪个进程抢占了keystone 的端口: 解决的办法也很简单,在/etc/httpd/conf/ports.conf注释掉httpd预留的5000 and 35357端口就可以了。 至此,liberty版本的OpenStack终于安装完毕! 整个安装过程总的来说,实现了自动化,RDO默认是用puppet来作为部署工具,无需人工干预,但由于国内网络环境的质量,在安装过程中出现了几次下载失败,但不是什么大问题,重新跑部署脚本即可解决,笔者所在的公司通过维护一个长期使用的版本的内部源能够很好的解决下载的问题。另外,RDO本身在社区被大家多次遇到的问题却没有很好的解决,这是RDO可以改进的地方,好在OpenStack社区发展的比较好,Google最终还是能找到问题的答案。另外,部署完后用户需要手动配置一个bridge方便后期的调试。整个安装部署过程和排错过程大约花费了我三四个小时时间,相比原来手动安装部署动辄好几天的时间,不得不夸赞RDO在这方面解放了许多运维人员,并且RDO也提供了添加计算节点的方法,让运维变的更加简单。 ZStack部署1.0.2版本下面笔者也尝试了一下Iaas领域的新项目:ZStack安装部署的过程: - 系统环境:
- Centos 7.2
- 硬件环境:
- 8核 CPU
- 16 GB 内存
- 200 GB硬盘
ZStack的官网下载安装包速度很快,但是很快也出现了一个报错,好在官网的安装说明上已经说明了这个问题,这是国内DNS劫持导致的,用户需要做如下操作: 再次安装(会提示目录已存在,删除老的安装目录): 由于ZStack提供了通过阿里云安装的参数,所以整个安装过程显得非常快,在等待几分钟后,命令行出现如下提示:
根据我设置的time标识,整个安装过程大约用了8分多钟,这和OpenStack部署的过程比起来确实快了很多。上图就是ZStack登陆后的Dashboard 总的来说,ZStack的安装部署过程非常简洁,作为一个轻量级云平台,ZStack没有提供给用户过多的组件选择,可以通过以下的命令来看到ZStack提供的一些部署设置: - bash ZStack-installer-1.0.1.bin --help
复制代码
并且,ZStack的官网提供了非常完善的部署文档,也提供了QQ群,微信群等本地化的社区支持,用户可以在遇到疑难问题时非常方便的参与到社区讨论并及时得到反馈。 总结以上是笔者实战记录最新版的OpenStack和ZStack部署过程,从这两个云平台的部署体验来看,ZStack由于是针对国内市场,对国内用户提供了很好的用户体验,OpenStack使用RDO官方默认的部署方法,还存在一些bug,需要部署人员在部署的过程中不断排错才能完成部署。但从云平台本身的组件数目来说,OpenStack生态圈已经非常成熟,提供了更多的选择。
从社区来说,OpenStack可以通过邮件列表,ask.openstack.org来获得帮助,而ZStack提供了本地化的QQ群和微信群来提供给用户帮助,并且社区的活跃度很高,有大量志愿者在社区解答大家遇到的各种问题。总之,两者各有优势,用户可以根据自己公司的业务特点,云平台规模,运维能力来决定使用哪个云平台,但笔者的建议是实践出真知,通过部署试用,来选择最适合自己的私有云平台。 作者简介:梅磊,某国企集团云计算工程师,OpenStack 用户。研究生期间开始接触 Linux,后参与过嵌入式 Linux 构建系统 Yocto的开发工作;SIP 通信协议栈的优化工作;基buildroot的嵌入式 Linux 系统的定制工作,智能照明管理系统服务器端的开发等工作。
|