|
开发测试云平台介绍
随着互联网技术的飞速发展和广泛应用，互联网公司对于产品迭代和技术升级的要求都更为迫切。相应地，研发测试人员对于机器的使用需求量也上了一个台阶。传统的虚拟化解决方案存在大量的问题和弊端，已经无法满足企业内部用户按需取用虚拟机资源的需求，运维人员和开发测试人员在虚拟机的使用管理上存在着很大的耦合性和关联性。探索更为自动化、快捷的虚拟资源使用分配方式已经成为无法回避的问题。
经过充分调研需求，我们在企业内部实现了一套基于 OpenStack 的虚拟机资源管理平台(VMMS)，能够动态、实时地响应全公司开发测试人员申请、续借和其他日常使用虚拟机的请求。系统的架构设计如下所示：
图 1.系统架构图
用户通过客户端请求虚拟机时，VMMS 虚拟机资源管理系统会立即响应用户的请求，按照用户的具体需求分配一台配置合理的虚拟机。通过维护一个动态变化的虚拟机资源池空间，对于虚拟机资源的各种请求做到了秒级响应。而且，为了保证虚拟机资源的动态伸缩，系统中还加入了时间管理模块；另外，虚拟机的正常运行工作通过状态管理模块来负责。全部的虚拟机资源都是通过底层的
OpenStack 云平台提供，VMMS Server 以一定频率和 OpenStack 云平台进行通信，保证资源的可用性和请求的及时响应。
VMMS 的设计哲学是在平台硬件资源有限的前提下，优先满足用户对虚拟机的各种操作需求，保证虚拟机资源平台的可用性和稳定性，对用户的申请操作和虚拟机资源配额、资源池大小都做了强限制。具体来说，VMMS
的开发管理策略主要体现在以下几方面：
虚拟机配置策略
58 同城是为用户提供本地生活信息的平台，主要提供覆盖广泛、定位精准的各类
Web 服务。使用虚拟资源的用户因为业务和具体场景的不同，对虚拟机的需求也不尽相同。应对普通的 Web
服务开发测试，例如快速接口调整、嵌入新的管理推广模块、页面样式变更等灵动项目的调整与测试，使用接近 PC
机配置的虚拟机就可以达到较好的响应效果，必要时可以通过横向增加机器数量的方法应对业务大规模推广测试和版本迭代；应对核心业务线的优化和部分基础服务就需要使用高配置的机器，这类业务大都具有
CPU 密集型和内存密集型的特点。典型的场景有信息管理中心索引重建、Redis 集群测试等，都需要分配多核
CPU 高内存配置的虚拟机。我们将虚拟机用户的潜在需求大致分为几类，并为之相应准备了配置适宜的虚拟机镜像和云主机类型。用户在申请时，只需要在用途和欲申请虚拟机配置标注，提单后系统就会匹配相应的虚拟机给用户使用。另外，还在部分镜像加入了集中配置和测试部署环境打通的相关配置，有利于减少用户重复配置安装的工作量。
请求响应策略
为了从根本上改善过去虚拟化服务资源分配效率低下的问题，VMMS 系统会在用户操作请求提交后瞬间响应用户的申请。这是基于一个自适应变化的虚拟机资源池实现的。系统初始化时会创建
n 台虚拟机作为原始虚拟机资源池，用户申请后资源分配模块会从已有资源中匹配然后响应用户，系统在后台会根据虚拟机申请周期和频率从全局上调整补全虚拟机资源的速度。VMMS
系统在平台总虚拟机数量 m 和当前维持可用的虚拟机数量 n 都做了一定的限制，为的是保证对虚拟机资源分配平台负载的有效控制。在局部时间内如果用户申请虚拟机操作的并发量超过了设定的阈值，系统会根据并发量调整
m 至 1.5 倍或 2 倍不等。相应地，资源池虚拟机数量 n 也得到了提升，优先保证用户正常进行各种虚拟机请求操作。在用户申请虚拟机操作请求频率回落后，VMMS
会再次将 m 和 n 的值收敛到正常范围。
资源控制策略
私有云平台受限于规模，所能够使用的硬件资源比较有限。为了及时有效地回收不在使用状态的虚拟机，VMMS
系统的时间管理模块会根据每台虚拟机的初始申请周期对在用虚拟机列表中机器进行定时扫描。查找到虚拟机使用周期已到而用户并没有后续的续借行为，系统会自动回收该虚拟机，释放物理资源。用户在申请虚拟机时有虚拟机重要性的可选字段，可根据业务和场景的具体情况给出重要性数值。针对工作数据和日志信息比较关键的虚拟机实例，如果到达指定时间还未收到续借请求，VMMS
会首先对虚拟机做停机处理，告知用户需要续借，没有后续操作的话虚拟机会在三天内回收。
虚拟机稳定性策略
状态管理模块会定时扫描每台在用虚拟机的状态，对不处于可工作状态的虚拟机首先尝试恢复，不成功则启用虚拟机重建和迁移策略来保证虚拟机的可用性。
虚拟机生成策略
为了减少人为干预，虚拟机的生成采用了完全自动化的策略。虚拟机从启动到划分所属网络、绑定浮动
IP、修改初始密码到进行业务上的初始化部署做到了完全借助系统本身流程进行。
借助 VMMS 虚拟机资源管理平台，开发测试人员能够自由便捷地按需取用虚拟机，在业务开发与测试环境的准备工作上提高了效率。VMMS
响应用户的各类虚拟机请求操作达到了每天上百次，简化了传统虚拟化解决方案下用户提单、运维审批，创建虚拟机再交付用户使用的流程，在无需人干预的情况下取得了较过去投入大量运维人力更好的体验；虚拟机的使用迭代周期相比过去大大缩短，每隔
10-15 天虚拟机资源池中的机器就会完整更新一遍，用户随用随取、不用归还，避免了资源的长期占有和浪费；在相同的硬件资源条件下能够管理和提供的虚拟机数量也较过去有了大幅提升。
OpenStack 云平台部署方案介绍
在实现了公司内部供开发测试人员使用的私有云平台后，需要将目光转向公司 Web
服务的虚拟化实现上来。与之对应，就需要部署一套企业级的 OpenStack 云平台环境。
网络方面根据平台需要，分别采用了 vlan 和 flatDHCP 模式，以项目为单位作为租户，进行网络的规划和设计；实现了多网络节点的
OpenStack 环境，保证了网络服务的高可用性。
存储上针对业务的访问特点，实现了基于本地存储、NFS 共享存储和 glusterfs
分布式文件系统共享存储的混合存储方案。将虚拟机的 disk 文件存储在宿主机本地硬盘上，数据盘即工作区间挂载分布式共享存储的卷。
方案上针对企业级生产环境可能遇到的问题实现了虚拟机在线迁移和物理机宕机迁移等功能。虚拟机在线迁移做到对用户基本透明，迁移过程不影响业务运行；物理机宕机迁移做到了虚拟机所在宿主机宕机后（硬盘损毁，网络不通，电源中断）能够在分钟级内迅速恢复虚拟机的正常使用，将由环境问题导致的事故风险降到最低。
经过实践和线上环境的使用统计，基于 OpenStack 的虚拟化解决方案相对于传统的虚拟化解决方案在主要性能上有了明显提升，下图是性能对比：
图 2.性能对比
高可用配置与平台性能优化
OpenStack 云管理平台部署后，在存储和扩展性上还存在诸多问题。例如，虚拟机的操作系统永久损毁或者宕机后，如何快速恢复虚拟机运行对外提供服务，业务负载高了以后如何在很短的时间内添加物理节点均衡线上压力，如何保证存储的
I/O 性能，避免操作系统 I/O 和数据业务 I/O 争夺资源。针对以上问题，做了以下几方面的高可用配置和优化工作：
1.虚拟机在线迁移和物理机宕机迁移实现；
2.glusterfs 支持的分布式块存储功能实现；
3.OpenStack 本地仓库的搭建。
虚拟机在线迁移和物理机宕机迁移
基于 NFS 共享存储的配置部署
1.在存储集群上安装 NFS 服务；
2.计算节点挂载 NFS 服务器的目录；
3.配置计算节点使其能够免密码 ssh 登录；
4.修改 nova.conf 文件；
5.配置 libvirt 的相关文件；
6.添加 iptables 的相关规则。
部署过程中需要注意一些细节：
1、挂载点是有要求的，一定要挂载在 nova.conf 配置文件中指向的
instances 创建目录下。各计算节点上，这个路径要完全一样，通常情况下可以使用默认路径/var/lib/nova/instances。如果
NFS 的客户端即计算节点没有选择这个挂载点，也可以顺利创建虚拟机，但是迁移时会发生错误。
2、确保计算节点有挂载目录的执行和查找权限。
chmod o+x /var/lib/nova/instances |
3、修改 nova 和 libvirt 的配置，使 vncserver
监听 0.0.0.0 而不是计算节点的 IP；同时设置 libvirt 监听 tcp。
更改以下配置项的值：
listen_tls=0
listen_tcp=1
auth_tcp="none" |
4、在计算节点添加 iptables 规则，确保试图途径 16509 端口的
TCP 连接可以顺利通过。16509 端口是 libvirt 专门用于虚拟机迁移的端口，在线迁移依赖于共享存储和
libvirt 工具在线迁移的配置。在各宿主机上添加如下的 iptables 规则：
iptables -I INPUT 3 -p tcp --dport 16509 -j ACCEPT
iptables -I OUTPUT 3 -p tcp --dport 16509 -j ACCEPT |
在线迁移和宕机迁移
1.在线迁移
OpenStack 云平台环境上线运行后，考虑数据中心服务器的负载均衡和容灾的需要，经常需要在不停机的状态下完成虚拟机跨物理机和跨数据中心的迁移。实现了共享存储后，可以利用下面的方法进行虚拟机的在线迁移。
nova live-migration vmId computeNode |
其中 vmId 为待迁移的虚拟机 Id，computeNode 为目的宿主机。整个迁移过程很快，用户几乎感知不到迁移过程的影响。
2.宕机迁移
在虚拟机所在的宿主机因为各种原因宕机后，即便虚拟化服务和虚拟机本身没有出问题，也不能对外正常提供服务，可以借助物理机宕机迁移的策略恢复虚拟机的工作。迁移操作如下所示：
nova evacuate --on-shared-storage vmId computeNode |
物理机宕机迁移操作需要在共享存储的支持下进行，迁移过程需要指定 on-shared-storage
共享存储参数，vmId 是待迁移的虚拟机 Id，computeNode 是目的宿主机。通过物理机宕机迁移，可以在新的宿主机上迅速恢复受影响虚拟机的工作状态。迁移后，有时会出现虚拟机访问不到的情况，这是迁移过程丢失网络信息造成的，解除该虚拟机浮动
Ip 的绑定，然后重新绑定原 Ip 即可。
需要指出的是，基于 NFS 实现的共享存储适合于物理节点规模较小的环境，可以考虑将并发量不高、网络压力较小的业务部署在这样的环境中。当生产环境要求较好的横向扩展性和高负载性支撑时，可以考虑基于
glusterfs 文件系统提供共享存储功能。
glusterfs 分布式块存储功能实现
配置 glusterfs 集群
在两台以上物理机安装 glusterfs 服务端，进一步提高稳定性，可以多部署几台
glusterfs 服务端，通过增加数据冗余率来保证安全性。
安装 glusterfs-fuse 模块。
利用 FUSE（File system in User Space）模块将
glusterfs 挂载到本地文件系统之上，实现 POSIX 兼容的方式来访问系统数据。
在服务端上添加物理节点，查看节点状态。
服务端上添加 glusterfs 的 volume，并启动。
配置 glusterfs 客户端
安装客户端 glusterfs-client。
创建挂载点。
挂载 glusterfs 服务端的卷到本地挂载点。
配置 glusterfs 作为 cinder 的后端存储
安装 glusterfs-fuse 模块。
配置 cinder 服务，使用 glusterfs 支撑后端存储。
修改/etc/cinder/cinder.conf，进行下面的相关配置：
glusterfs_mount_point_base = /var/lib/cinder/volumes
glusterfs_shares_config = /etc/cinder/shares.conf
volume_driver=cinder.volume.drivers.glusterfs.GlusterfsDriver |
shares.conf 文件需要新创建。
创建客户端 volume 使用列表。
编辑 shares.conf 文件，将需要使用的 glusterfs volume
加入其中。
重启 cinder 服务，完成部署。
glusterfs 使用调整
glusterfs 作为 PB 级的分布式文件系统优势在于有良好的横向扩展性，存储节点可以达到数百个，支撑的客户端能够达到上万的数量。扩展增加存储节点的数量，不需要中断系统服务即可进行。另外，通过条带卷
stripe 和镜像卷 replica，可以实现类似于 RAID0 和 RAID1 的功能。配置条带卷，可以将文件以数据块为单位分散到不同的
brick storage 节点上；配置镜像卷，可以将相同的数据冗余存储到不同的 brick storage
节点上。两者结合，综合提高文件系统的并发性能和可用性。在创建存储集群时，可以通过如下的配置创建分布式的
RAID10 卷，通过实现软 RAID 提高文件系统性能。
gluster volume create ecloud stripe 2 replica 2 server01:/var/block_space01 \
server02:/var/block_space01 server01:/var/block_space02 server02:/var/block_space02 force. |
采取这样的配置，虚拟机数据被分放在 4 个位置，2 个位置组成一份完整的数据，另外冗余一份数据。修改条带卷和镜像卷的配置值，可以灵活改变数据冗余的份数和
glusterfs 的并发读写能力。具体取用什么值，可以根据业务场景和性能要求来实践决定。
另一方面，glusterfs 和文件系统的默认配置在 I/O 性能和小文件读写上存在一定问题，可以尝试从以下方面来提高性能：
1.调整读写的块大小，得到选定文件系统下最适宜的数值，提升底层文件系统的
I/O 效率；
2.本地文件系统的性能优化；
3.根据具体业务调整每文件的读写 cache 达到最优效果，配合 glusterfs
固有的 cache 机制；
4.在保证数据安全性和系统稳定的前提下，尽量减少数据冗余的份数，这样可以极大缓解
glusterfs 在查询多个节点时的时间损耗。
基于 glusterfs 实现的共享存储与前面介绍过的基于 NFS 实现大致相似，这里不再赘述。
OpenStack 本地仓库的搭建：
采用离线部署主要是规避安装过程中国外源的超时问题，从而较大地提升安装部署效率。借助自动化的安装脚本
RDO 或者 devStack 安装也很便捷，但是如果网络不稳定或者国外的源出了问题，安装会很麻烦。
下载各安装源到本地
1.下载 CentOS 源
安装是在 CentOS 发行版下进行，所以首先将 CentOS 最新版
6.5 版本的源拿到本地。定位到放置源的本地路径，使用如下命令进行操作：
wget -S -c -r -np -L http://mirrors.sohu.com/centos/6.5/
CentOS 官方会定期进行版本升级和部分安装依赖包的更新，我们还需要定期检查相关依赖包的变化，及时将升级的包同步到本地仓库中，与现有环境进行合并。这个工作建议每半个月进行一次，大版本发布时再集中完整更新一次。
接下来，依次下载用于搭建 OpenStack 环境的各种依赖包：
2.下载 OpenStack-Icehouse 版本的包
wget -c -r -np http://repos.fedorapeople.org/repos/openstack/openstack-icehouse/ |
3.下载 foreman 插件包
wget -S -c -r -np -L http://yum.theforeman.org/plugins/1.3/el6/ . |
4.下载 epel 包
wget -S -c -r -np -L http://dl.fedoraproject.org/pub/epel/6/ . |
5.下载 puppet 包
wget -S -c -r -np -L https://yum.puppetlabs.com/el/6/ . |
6.下载 epel test 相关包
wget -S -c -r -np -L http://dl.fedoraproject.org/pub/epel/testing/6/ . |
以上介绍的本地仓库搭建是通过完整地下载各依赖包集合实现，我们也可以通过分析
OpenStack 安装日志和官方的项目依赖说明获得更加准确的依赖关系，得到最精简的本地仓库依赖包集合。这样有利于本地仓库迁移和多节点系统的快速恢复。
建立本地源
以 CentOS 源为例，介绍本地源的建立
定位到/var/ftp/centos-sohu 目录下，执行 createrepo
.完成本地源的建立。
接下来创建 repo 文件，设置本地源。
同样以 CentOS 源为例，repo 文件的设置如下所示：
[local]
name=local_yum
baseurl=file:/var/ftp/centos-sohu
gpgcheck=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6
enabled=1 |
其他挂载本地源的宿主机源配置如下：
[local]
name=CentOS-$releasever - Base
baseurl=ftp://$ftpServerIp/centos-sohu
gpgcheck=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6
enable=1 |
物理节点共享使用本地源和本地仓库时，可以使用 ftp 访问的方式，也可以使用
nginx 来发布本地源供其他机器下载使用。这个可以根据节点规模和安装环境具体情况进行灵活调整。一般规模的多节点环境，使用
ftp 来发布本地源完全可以满足需求，而且搭建也更容易。
经过测试，使用本地源部署规模为 4 个物理节点的多节点环境只需要 6-8
分钟，而使用外网的源至少需要 30-40 分钟，在超时和反复安装的情况下时间成本会更大。随着节点规模增大安装效率的优势会愈发明显，本地仓库的搭建在很大程度上有利于多节点、大规模环境的安装
结语
本文简要介绍了 OpenStack 在私有云平台中的一个应用，基于 OpenStack
实现了企业内部的虚拟机资源分配管理平台。同时给出了一个 OpenStack 企业级的云平台部署方案，在存储和网络上的探索和性能优化使得
OpenStack 较好地满足了企业对外提供 Web 服务的需要。本文只是对 OpenStack 企业级使用的一些初步探索，进一步深入研究使用请参考
OpenStack 存储和网络原理获取更多信息。
|
