【IT168 技术】近几年IT技术的发展和变革使得虚拟化和云计算技术在传统IT和互联网企业日趋成熟。“互联网+”更是在诸多非IT行业激荡开来，越来越多的传统行业都期待加速IT转型，加速云计算的建设和应用，拥抱“互联网+”的春天。然而，由于传统行业专注的方向从来都不是IT技术，IT在他们的业务运营中只提供了平台和工具的能力，要想通过他们自身进行的升级发展进行完全彻底的变革，开发或实施一套稳定可靠的云计算环境，难度系数可想而知，所以越来越多的企业和公司都选择借道IT公司帮助其构建可以支持高度自动化，智能化的云计算平台，迈入“互联网+”的行列。本文通过实战向大家介绍如何通过ICM(IBM Cloud Manager)快速部署一套稳定可靠的私有云计算平台，该平台以x86服务器上运行ICM整合的Openstack和KVM为基石，实现了一键部署的能力，驱动非常好的适配，内核优化等，传承了完全开放标准的Openstack API，为企业进行自主应用的自动化开发和应用提供了更好的选择。文章包括如下主要内容。
背景介绍
项目实战
总结
1 背景介绍
云计算技术日趋成熟的今天，一提到云计算，读者多数会想到AWS和Openstack，因为绝大多数都是从AWS公有云真正感觉到了云计算的存在，Openstack一直以来追随AWS数年，只要AWS新的功能发布，在Openstack的下一个版本总会如期出现。AWS公有云是毋庸置疑的，但要让不计其数的传统行业企业把业务迁至AWS上，大多数都做不到，安全保密可靠是90%的企业都难以逾越的鸿沟。所以Openstack成了他们不二选择，很多企业不断尝试跟进Openstack的各种版本，试图搬到各自的业务场景中。然而接触过Openstack的人都知道，要通过Openstack官方文档搭起一套环境，随便一个指令或参数的错误，都会让你不堪回首。初识Openstack，不经历翻山越岭，过五关斩六将的碰撞，一睹Openstack真容都做不到，更不要说可靠性，可用性更是需要对Openstack深层次的了解才有可能实践。Openstack追随数年，一直饱受诟病，究其原因，基本上还是那几个，开发人员思维，没有足够的运维和客户参与，难以维护，没有标准统一的架构参考，不具可复制性，稳定性差，升级更新换代太过频繁，对于我们这些身在IT行业的人尚且如此，更不用说那些并不擅长IT的形形色色的传统行业了。基于此，业界出现了很多基于Openstack部署运营的初创公司，最成功的当属Mirantis。IBM这几年来一直将云计算作为其未来发展的重点，90%的业务都正在或将要基于云计算进行扩张，业务规模截至2025年将达到200亿，如此大的市场规模，没有有效的自动化方案如何得以实施。
终于，IBM推出了ICM，该方案对Openstack进行了大量封装和优化。通过ICM只需寥寥几步就可以按照你的设想部署一套可靠性高，稳定性好，性能优化的Openstack环境。为了得到更好的稳定性和性能，该方案摒弃了大量兼容性代码，对于kernel的优化也在部署过程中自动适配完成，无需用户单独配置，该方案提供用户大量模板以满足不同场景，不同规模的定制化。其包含的deployer组件还提供了大量API供客户使用，假设在一个业务场景中，云环境中的虚机量达到饱和，而硬件连接你用或不用，它都一直在那儿准备中(如公有云中的Softlayer)，这个时候用户就可以通过API申请一台服务器，将其配置添加到deployer中，再通过API触发deployer将该服务器作为compute节点添加至已经在服的Openstack环境中，所有这一切都可以结合上层业务设计为自动探测，自动完成，不再需要人为参与。这也就是人们通常所说的根据业务量自动伸缩扩展。
后续章节本人将通过项目实战，完整的演示一套Openstack从架构到部署上线，让你一睹芳容，准备好了吗，开始尖叫吧。全篇不讲废话，句句都是实打实的干货。
2 项目实战
2.1 逻辑架构
▲图1 ICM逻辑架构
ICM逻辑架构分为两个层面，一个是deployer，负责云平台的自动化部署，另一个是目标系统，deployer自动化部署的目标就是这些目标机，而部署完成之后由目标机协作运行的云平台环境才是我们的客户真正需要的Openstack平台。目标机又根据不同的角色分为不同的组件，如控制节点，计算节点，存储节点等，在本实战演示中只提到了控制节点和计算节点，基本满足了大多数要求不太高的企业用户应用场景。而对于可靠性要求较高，大数据分析或一些特定的应用，则需要根据不同的场景进行不同的调整和扩充。
2.2 网络拓扑
▲图2 ICM网络连接
通过解析ICM逻辑架构，我们将各个节点之间的连接分为5组，为了保证网络之间的互不干扰，推荐5组网络连接不同交换机，配置各自相对独立的网络。IMM网络提供系统硬件及远程Console服务，所以建议使用私网地址段，并通过架设VPN，提供administrator的紧急支持。Management网络提供云环境的各个组件之间通信交互，administrator必要的时候也会通过该网络进行日常运维，建议配置私网地址，并实施VPN可达。Public网络则是提供云环境中各虚机访问外网的能力，所有虚机访问云环境之外的网络(简称外网)或从外网访问虚机，都需要通过该网络，所以该网络需要具备用户办公区或工作区路由可达。鉴于目前Openstack支持DVR非常有限，稳定性，可靠性及性能都还未能完全满足生产环境的要求，所以图示上虽然控制节点和计算节点都有Public的连接，而计算节点只是预留，为将来升级到分布式路由做准备，实战演示只尝试了通过控制节点进出外网的场景。第4组网络则是Private网络，该网络用来提供云环境中所有虚机之间直接通信的能力。最后一组为Storage网络，通过该网络实现的分布式共享存储，可以实现虚机在各物理机之间的自由迁移，保证了业务在日常运维规划下的最大可能连续性。目前ICM4.3 FP1已经可以支持分布式存储，但还没有把分布式存储的部署集成到ICM中，所以当前需要在准备过程中先搭建好分布式存储，再通过ICM部署Openstack环境。在部署分布式存储的时候，你可以选择GPFS, GlusterFS，ceph或其他存储方案。令人欣喜的是，ICM已经在下一个版本中集成了GPFS，作为其推荐的分布式存储，万事俱备，只欠发布了，期待尽早发布，一探究竟。从网卡类型可以注意到，其中IMM，管理和外网连接都是1G网络，IMM不用说，业务量很小，而管理网络大多数流量都来自节点之间的消息控制，1G网络基本可以满足，外网很多时候会受到上联的限制，瓶颈不在服务器这端，所以即便搞个10G网络，对外网连接也不会有太大帮助。两个10G网络意义重大，其中一个是提供虚机之间的访问，大家知道，一旦云业务达到一定规模，宿主机上的虚机量可能就是30/50不等，并且会有大量的业务流量存在于虚机也即宿主机之间，所以这个也就容易理解了，另一个用来提供分布式存储的网络，所有磁盘块的文件拷贝都通过网络实现同步，这里跟虚机的流量类似，10G网络对这两个接口相对来说举足轻重。不过话说回来，如果只是做做测试，全部改为1G网络，没啥问题，就是慢点儿而已。
2.3 配置
ICM部署Openstack环境，对硬件要求更多来自业务场景，不同的业务场景有不同的硬件要求。如果只是希望体验一下，按照如下配置即可满足部署一套可复制的Openstack环境，但真正要上业务，进生产，则还需要逐一升级。Deployer没有云计算业务，主要负责环境自动化部署，升级扩容等。不过如果条件允许，建议你最好还是升级一下你的deployer，起码能保证在其中操作能顺畅一些，进程少些卡顿，或在进行自动弹性伸缩扩容的时候不受影响。Controller视规模而定，虚机量不同，compute节点数不同，跟controller之间的通信量以及在controller数据库中存储的数据量也差别较大。计算节点也一样，有的业务场景虚机数量不多，但每个虚机的size较大，我曾经遇到过16cpu，64GB内存，500GB硬盘这样的虚机，如果宿主机配置太低，这样的虚拟化云计算意义就不太大了。所以综上所述，deployer的配置可以稍稍低点儿，但controller和compute建议在一开始设计的时候就尽量力图保证上点儿档次。ICM既可以支持控制节点的standalone模式，也可以支持HA模式，为大多数企业谋福利，我选择了验证HA模式。本人在测试过程中的配置参考如下Experimental列，3个控制节点+3个计算节点，其网络连接可参考前面所提到的网络拓扑。
主要服务器列表(均采用x86硬件平台)：
软件列表
通过IBM官网，你可以申请账号，下载到最新版的ICM软件包，该包大约6GB。该软件包不但进行了大量的集成和优化工作，甚至不同的硬件要自动适配最优的运行方式等等，还将deployer安装工具和Openstack及其依赖包整合其中，它可以保证在客户私网环境，不需要连接外网也能安装，这很好的解决了很多企业对外网的限制跟Openstack官网安装方式的冲突。
2.4 环境部署
万事俱备，我们接下来就可以执行ICM部署了。其实ICM的部署非常简单，简单到你想都不敢想，以至于本文如果只介绍部署过程，那真是没啥可说的，也就30%的篇幅吧，要知道，全篇才不过区区数页。闲话少说，看完再论。
2.4.1. 部署deployer
将之前拿到的ICM软件包存放到已经安装好redhat7.1的deployer系统中，执行如下指令。等待大约30分钟之后，deployer便可安装完成，安装过程中可以参考cmwo-installer.log。
[root@deployer ~]# ./cmwo430_xlinux_install.bin
安装成功，输出会按如图3 ICM安装日志：
▲图3 ICM安装日志输出
2.4.2. 部署Openstack
ICM的自动化部署通过chef实现，了解chef的人都知道，chef可以支持两种方式，一种是yaml，它将所有配置说明都在一个文件中解释和定义，跟Openstack中的conf文件类似。另一种则是json，json将环境和拓扑分为两个不同的文件，环境主要定义版本，端口，地址，部署方式等，这些都是无论规模大小，基本不变;拓扑则是根据不同的用户需求规模，定义节点数和节点角色等。使用json的好处就是效率高，毕竟在json文件中没有废话，全都是有效配置，开发人员比较推崇这种方式，不过就是可读性较差，如果习惯了这种方式，其实也还不错，我的测试调研中也选择了这种方式，编辑环境配置文件和拓扑配置文件。详细的参数配置说明，可以参考链接http://www-01.ibm.com/support/knowledgecenter/SST55W/welcome。在链接中可以找到拓扑配置文件的参考，而环境配置文件则可以在deployer中通过命令行方式生成，不同的版本生成的环境配置文件不一样，如果都是通过下载的方式，万一使用了不同版本的文件，部署可就不一定成功了，这也是可以理解的。
1. 编辑hosts文件，ICM使用dns解析并部署Openstack环境。
2. 生成配置文件：
[root@deployer ~]# knife environment show example-ibm-os-ha-controller-n-compute -d -Fjson > env.json
3. 根据自己的架构编辑特定的配置env.json和topo.json。
Env.json参考如下：
{
"name": "test",
"description": "Example environment for the IBM OpenStack HA controller + n compute topology",
"cookbook_versions": {
"apache2": "~> 3.0.0",
"apt": "~> 2.6.1",
"aws": "~> 1.0.0",
................
Topo.json参考如下：
{
"name": "test",
"description": "test",
"environment": "test",
"secret_file": "/opt/ibm/cmwo/chef-repo/data_bags/example_data_bag_secret",
"run_sequentially": false,
"orchestration": "ha_controller_n_compute",
"nodes": [
{
"fqdn": "ctrl-1.test.com",
"description": "Cloud HA controller node",
"password": "xxxxxx",
"quit_on_error": true,
"run_order_number": 1,
"runlist": [
"role[ibm-os-ha-controller-node]"
]
},
{
"fqdn": "ctrl-2.test.com",
"description": "Cloud HA controller node",
"password": "xxxxxx",
............
4. 更新deployer环境：
[root@deployer ~]# knife environment from file env.json
5. 部署Openstack环境：
[root@deployer ~]# knife os manage deploy topo.json
部署完成之后，你将看到如图4所示结束信息，标明ICM部署过程已经全部并正常完成。
▲图5 ICM部署结束日志
在我这样的配置模式下，大约2个小时之后，一套全新的Openstack环境即可部署完成。不同的节点数，所需时间长短不一，controller节点由于上面的业务繁多，大约需要半小时，而compute节点则基本只需要10分钟即可完成。就是这么简单，仅仅5步便可部署一套Openstack标准环境，相比Openstack官网那纷繁复杂的配置和命令行，你还有什么理由不支持呢?
另外为了最大限度的进行自动化部署，我们推荐使用cobbler进行OS的自动化安装。目前cobbler还不能支持多节点并行安装，所以如果你的节点数量巨大，这个安装虽然人工干预较少，但等待的时间却是无法避免。对于ICM的部署过程也一样，一旦开始部署，在topo.json中定义的节点就无法更改，并且也只能一个一个顺序安装，即便是同时在通过cobbler进行新节点的OS安装，也只能等到ICM部署完成之后，通过添加节点的方式，将之后的节点追加到整个云环境中。从整个文章可以看出，其实部署的步骤参与很少，出错的几率也就更少了，所以建议读者尽量把重点放在部署之前的规划和架构，配置文件的准确编辑上，尽可能的对一些特殊的参数进行详实的解读和研究。
2.5 测试验证
同样的，你可以在deployer中输入knife os manage services status --topology-file topo.json检查你已经部署成功的Openstack环境状态。假设环境配置文件中关于VIP的设置：192.168.1.100，通过火狐浏览器登录云环境https://192.168.1.100/，缺省用户名密码为admin/openstack1。登录之后出现如图5所示ICM管理界面，你会发现其跟Openstack的功能基本一样，只是界面风格不太相同，你可以在该管理界面中进行Openstack的业务操作，如创建网络，上传镜像，启动虚机等等。更多Openstack管理和用户使用指导，建议参考Openstack官方文档，这里不再赘述。
▲图5 ICM登录界面
▲图6 ICM管理界面
3 总结
本文开篇也说了，不讲废话，即便是总结也要总结点儿有价值的东东。通过本篇文章的介绍，你可以从中学习到在部署一个Openstack云环境的时候所涉及到的关于架构选择，拓扑规划，硬件选型及软件准备等相关工作流。如果你选择Openstack社区，部署的环节将花费你大量的精力，而现在有了ICM这个自动化部署产品，你可以将你的精力集中在架构设计和规划上，其他的过程只要参照本文，再结合ICM的官方文档对各种配置的解释，即可完成一套高可靠高可用的Openstack云环境部署和运营。ICM的部署就是这么简单，而它9月中发布的版本已经整合了GPFS分布式存储，这就意味着你无需单独部署GPFS，只要在环境或拓扑文件中定义好GPFS的能力，所有优化和非常好的实践都将自动完成。本人也会持续关注这个版本，期待其会有比较好的表现。当然，灵活性是很少有的，即便是你对GPFS可能心存芥蒂，你也可以禁掉GPFS选项，通过部署ceph或其他存储方案进行你的生产环境实践。目前Openstack支持的HA主要探讨的是controller，ICM也不例外。在ICM的部署模式中，一旦你选择了HA的方式，最少的controller节点需要3个，而ICM支持的自动伸缩能力提供你在部署了3个节点之后，根据业务需要进行无业务影响的平滑扩容和缩容，目前ICM4.3 FP1支持的最大节点数为10个。事实上，compute也可以通过controller的HA原理配置为1+1备份方式，完成compute的HA，然而compute节点跟controller节点的功能完全不同，在一个云环境中，占90%以上的节点都是compute，要是都使用这种模式，那就意味着至少50%的资源完全处于闲置状态，同时还要一并对其做足日常运维以保证切换的时候不会出现故障，恐怕没几个企业愿意承担这样的投资。而当前无论使用存储产品还是分布式存储，compute节点都可以通过共享存储达到按需自由迁移，这已经很大程度上保证了业务的连续性和最小影响。所以，推荐读者，使用共享存储实现计算节点的可靠性实施，才是上上之策。另外，ICM还提供了Power平台的支持，集成了多个厂家的存储驱动，SDN方案，为将来的平滑升级提供了最大的可行性。ICM包含了自动化部署和Openstack非常好的实践，所以在用户的业务场景中你可以直接使用标准的Openstack API，不用担心你之前对Openstack所编写API的积累。ICM能力一句两句也说不完，你不妨自己亲自体验和总结，会有更多的惊喜等着你。IBM作为Openstack社区少有的几个白金会员，其对Openstack的支持力度和业务模型，你懂的!
参考资料
1. http://www-01.ibm.com/support/knowledgecenter/SST55W/welcome
作者简介：
李飞 云架构设计工程师
任职于某大型外资IT企业，从事企业云架构设计，具有丰富的IT架构和虚拟化经验，熟悉主流的虚拟化和云计算技术，熟悉IBM的服务器和存储产品。
