asdf-asdf
作者asdf-asdf·2018-04-20 13:55
研究学者·cloudstone

数据中心虚拟化实践探讨

字数 5241阅读 5522评论 3赞 11

背景

2013年建设银行总行数据中心云计算管理平台正式上线,进行生产管理计算资源整合后,各个金融企业经过了4到5年的技术考察期和业务试用期,各个金融数据中心希望尽快部署云管理平台对已有的云平台进行资源的统一管理、计量和计费。已经规划和实施部署的云平台有也希望纳入未来建设的云管理平台中, 这种大型数据中心资源管理平台的规划和实施过程中需要考虑很多因素,包括网络连接、与已有虚拟化产品整合、平台自动化等方面。

原部署硬件设备方式

1 机房管理员规划业务设备部署位置、分析电力负载和承重,不达标还需进行改造
2 设备入场并加电测试,正常则放入机房上架并加电
3 网络和存储光纤或者电缆根据需求布线
4 网络部门根据要求分配IP地址、防火墙策略和访问方式
5 系统管理员部署OS系统、数据库和中间件等通用平台软件
6 业务人员部署业务系统并测试
7 业务应用正式上线
整个部署过程多部门参与多人参与,业务流程复杂而冗长,部署时间多为两周以上。

虚拟化技术使用后流程

1 机房管理员规划业务设备部署位置,分析电力负载和承重,不达标还需进行改造
2 设备入场并加电测试,正常则放入机房上架并加电
3 网络和存储光纤或者电缆根据需求布线
4 网络部门根据要求分配IP地址、防火墙策略和访问方式
5 建立各类虚拟资源池,包括服务器资源池、网络资源池和存储资源池
6 根据业务需求,新建虚拟机、安装操作系统并分配相关的ip地址,告知业务方
7 系统管理员部署数据库和中间件等通用平台软件
8 业务人员部署业务系统并测试
9 业务应用正式上线

以上步骤是数据中心业务应用上线的基本流程,在使用虚拟化云平台后业务流程变得更加冗长,但很多工作用户发现是前期规划不完善而导致的部署工作复杂业务流程冗余.

使用虚拟化前后的对比如下
QQ截图20180420113617.png

QQ截图20180420113617.png

云管理平台方式的模块化部署云计算底层硬件

x86+vmware部署模块

1.选定采购的虚拟化服务器型号,这里以x86为例
高配 48C 256G 4U 服务器
中配 24C 128G 2U 服务器

2.规范好机柜部署设备模板

  • 故障域为一个机柜里面所有设备
  • 故障域定义为三个故障域且互为备份
  • 单个故障域逻辑限制分配cpu不能超过70%,强制限制在90%分配上限
  • 如果单个故障域中设备故障,会优先在本故障域启动设备
  • 如果整个故障域失效切换到其他故障域完成业务启动
  • 故障域底部包含双路电源插排
  • 故障域顶部包含双路万兆双链路生产网络交换机和单路千兆带管交换机
  • 故障域顶部包含双链路FC存储交换机
  • 高配8台设备部署在一个故障域
  • 中配16台设备部署在一个故障域
    (提示: 这些规划和根据用户自己需求进行调整)

3.规范的故障域(机柜)布线

  • 故障域布线申请单可根据故障域模板自动生成
  • 高配故障域线路部署以及中配故障域线路部署是完全规范化的部署方式
  • 网络施工人员了解到故障域高或者中配就可提前部署线路等待设备上架
  • x86设备实施人员可添加故障域模板一次完成设备上架实施和线路连接

4.设备完成硬件部署后虚拟化技术的部署

  • 通过远程ilo口完成设备的虚拟化软件自动化安装
  • 这里经验是需要有个设备上线的统一台账,我们采用了设备序列号为主键
  • 设备加电启动后部署一个bootOS获取sn号码后再PXE中生成设备需要的部署脚本
  • 设备再次重启动后从pxe中获取自动化配置信息,安装虚拟层部署相关插件或驱动
  • 最后运行配置脚本把配置参数配置到虚拟化层中完成部署

5.pxe完成部署后发送指令给云管理平台业务接口
获取相关信息后云管理平台调用指定虚拟化管理平台把该物理设备加入到虚拟化管理平台.列入到相关故障域中,整个故障域完成部署后,可进行业务部署

6.虚拟机自动化的ip分配设计

  • 通过对业务申请中打标签来完成ip的规范分配
  • 每个故障域中的ip 按照最大规格进行分配保留
  • 在虚拟机申请时在本故障域的ip资源池中完成分配

7.虚拟机的OS和中间件等非业务系统软件统一化管理

  • 制作规格化的虚拟机模板
  • OS标准化模板
  • OS+中间件模板,was,oracle,weblogic,tomcat等等(多个版本等)
  • 所有模板中包括自动化agent和业务初始化通用部署脚本(OS自动化管理软件和部署业务软件的通用脚本)

在根据自己业务完成上面硬件实施规划后实施流程变化为:

  • 机房管理员管理故障域数量(根据目前业务增长度推断采购设备清单)
  • 故障域部署(网络和机柜电力等)
  • 设备部署(完成虚拟化基础上线)
  • 业务人员申请虚拟机
  • 自动化的ip地址和设备位置分配
  • 自动化的虚拟机镜像模板部署和配置
  • 预制部署脚本根据业务申请单下载指定业务war包或者数据库名称等参数创建业务
  • 业务管理员完成业务调试上线

通过规范的故障域规划和业务上线自动化标准确立等一系列标准化推荐工作完成后,业务上线速度在一周之内完成(5个工作日).如果排除业务上线调试时间.虚拟机交付上线时间为1个工作日.从而大大提高基础架构的交付能力.
具体部署方法可参考下图:
1.png

1.png

单机连接模式
2.png

2.png

故障域连接模式 这里展示了六个故障域,每两个故障域为一个组,完成高可用切换

Powervc+hmc+powervm+san部署模块

  • 定义高低配故障域
  • 高配两个power880设备组成 (vioc安装算力分配1c2g的倍数完成分配)
  • 中配两个power850设备组成
  • 网络和FC线路参考vios实施规范进行故障域模板制作
  • 规定每个故障域做多的rac或者ha的分配套数从而对于业务软件需要部署 ha或者rac的特殊要求对ip进行完全保留方式避免ip地址池中ip不够的情况出现
  • 完成上面规划后部署硬件设备包括故障域(机柜加交换设备以及线路),物理机,手工完成powervm配置vios的相关创建和安装部署
  • powervc 需要部署到linux上ppc或者x86版本按照需求完成powervc安装
  • HMC要纳管道powervc中
  • vios需要一个ip地址与HMC进行数据通信
  • brocade的san交换机需要纳管道powervc中
  • 存储 EMC的VMAX需要纳管道powervc中
  • 通过powervc管理页面纳管 hmc上的powervm设备, san switch和vmax。

在power设备上手动创建第一个vioc过程。

  1. 在powervc上存储管理部分创建一个启动卷,
  2. 在镜像部分用该卷创建镜像,
  3. 手动创建san switch的zone,分配该卷给 vioc,
  4. 部署AIX系统和其他软件,
  5. 部署cloud-init软件.
  6. 完成后软件部署后捕获为模板,

通过上面方法制作多个指定版本的模板包括 was, weblogic, rac, ha, db2等镜像方便后面进行基础平台供给使用.

配置powervc的各种组内容包括主机组,vios可配置数据量,并制规则等使部署出来的vioc符合生产环境需求.网络环境的部署目前多使用sea共享网卡进行.把物理网卡链接的交换机端口配置为trunk方式。使用mkvdev –sea entX –default entXX –defaulted 100,创建sea卡。

完成所有powervc的配置后,把powervc中的主机组同步到云管理平台数据库中,并通知业务开发部署人员在云管理平台申请vioc资源,云管理平台处理资源申请,并通过powervc的api接口对接powervc,调用创建接口完成vioc的创建(创建接口会传递vioc规格,链接组,存储组,存储模板,ip地址,网络信息等)通过存储的lunx复制完成aix以及其他软件的部署,最后交付给业务人员完成业务部署。

x86 + Openstack部署模块

openstack目前部署生产环境需要12台服务器完成部署。

3个控制节点,3个计算节点(可扩展),6个存储节点(分布式存储),SDN网络设备需要单独硬件完成,软件sdn不建议上生产使用。

目前能对openstack进行金融生产级别运维开发的公司实力相对强的有华为和华三,其他企业的openstack的开发能力和软件维护能力相对薄弱。

与华为的openstack接口对接和集成是目前项目实施中经常遇到的事情。
华为openstack平台是开源版本上的高度制定版本,封装和优化了很多特殊功能来符合金融基本的技术性能指标要.

Openstack平台的一些基本技术不再这里讨论了,只说明下SDN的引入会造成什么样的运维影响.

Openstack设计就是为多租户的运营平台准备的,网络部署把网络区域进行了虚拟化规划.每个租户有一个网络区域(vpc)每个网络区域可创建多个子网,而子网通讯需要通过虚拟路由器进行(可有多个虚拟路由器),运维人员对这样复杂的网络设计非常难以理解而网络又是必须清晰明确的.所以在openstack实施过程中建议大家先详细学习下sdn网络部署方法和相关思路.方便部署设备时能清晰网络链接情况。对错误排查和网络访问申请能有清晰的意识。

Openstack的自身计算节点的增删等操作在管理页面有详细的操作方法无需特殊学习。

人员

为了适应未来数据中心的运维运营模式.相关的基础平台技术维护人员也需要进行相应的角色转换.我们在项目实施中经常需要定义相关人员角色,包括:

虚拟化管理人员:
完成相关的虚拟化平台业务管理,包括powervm运维、vmware运维、openstack运维,而在这些技术人员中需要进行一些衍生工作,如各个系统的镜像封装以及版本管理,其中包括AIX、Linux、Windows 等OS版本镜像和OS+中间件版本镜像、自动化部署脚本维护,镜像内部通用脚本维护,从而提高单体人员的核心技术竞争能力和适应未来DevOps方式的运维管理模式;
基础平台运维人员:
从单一的基础技术运维方式转换为以业务自动化软件开发为基础的软件运维模式.

人员职能按技术运营分为:

  1. 基础硬件实施人员(原IT环境部署人员):
    负责设备上架下架,机房设备实施,设备硬件运维
  2. 云管平台运维人员:
    Vmware运维人员
    Openstack运维人员
    Powervc运维人员
  3. 存储设备运维人员:
    负责配合云管平台人员完成存储对接各个虚拟化平台
  4. 网络运维人员(SDN和传统网络):
    负责网络的构建和ip分配,已经所有网络部署
  5. 云平台image和业务软件构造人员:
    负责各种虚拟化 os image的构建和业务软件在 image上的构建
    包括所有自动化部署业务和通用补丁修复
  6. 云管理平台运营人员:
    负责平台的业务审批流程和IT操作支持
  7. 云管理平台流程管理人员:
    负责整体业务流程优化和新流程创建部署
    加快业务上线和与各部门沟通完成业务流程梳理
  8. 云管理平台开发人员:
    按照实际业务需求梳理,完成相关业务开发

云管理平台的运营

  • 物理资源完成虚拟化后再次池化进入云管理平台后,计算资源会在持续的运营周期完成分配,使用,回收,再分配等循环使用直到资源下电.
  • 这个周期在计费模块上尤其能体现,可看到各个阶段的资源使用费用.并以各种维度精确计算出相关人员或部门或设备的费用使用情况,包括网络,ip,存储等资源.
  • 给数据中心一个整体的运营情况财务收敛表.为未来财务预算做出精确的推算.

云管理平台的开发经验

轻度集成和重度集成对用户的需求:
大型金融数据中心对多虚拟化云平台进行集成,从而出现云管理平台。
而在云管理平台开发中会出现集成设计方向问题,高度统一化集成所有其他云平台所有功能适合有自主开发能力的运维团队,根据具体业务确定下面接口优先级进行云管理平台的功能开发和使用。
而无开发能力的运维团队建议购买成熟的产品进行云管理平台的建设,并进行简单的二次业务功能开发,挑选下面常用接口进行功能测试。

讨论下各个平台包括 vmware, powervc, openstack 这三个常用的云平台软件的集成方案.

为了业务快速上线金融数据中心目前的运维模式和业务模式情况下个人建议进行轻度业务功能集成.

集成的通用几个接口为:

  • VM或VIOC创建
  • VM或VIOC删除
  • VM或VIOC计算资源管理(cpu和内存加减)
  • 其他附加功能和业务接口:
  • VM或VIOC的迁移
  • VM或VIOC网卡添加
  • VM或VIOC磁盘扩容
  • VM或VIOC远程控制
  • VM或VIOC生命周期管理
  • VM或VIOC计费管理

这些附加功能可根据自己的业务情况进行选择.
资源的统一管理在云管理平台上应和底层云平台进行数据同步完成资源规划和分配.

管理员继续使用云平台来对计算资源做硬件容量配置和运维操作。

云管理平台为资源统一展示和资源分配平台。对已存在资源进行统一的资源展示和优化的资源分配。

在云管理平台开发中详细调研自身业务运作模式,按照制定模式开发各个组件接口,完成对各种虚拟化资源的调度。

总结:

云管理平台是金融数据中心在运营层面上最佳的统一资源管理实践.
对资源的统一分配,回收,规划等自动化的技术引入使数据中心技术运维人员大幅减少,运维人力成本会逐年下降.而业务上线速度反而比大规模人力运维减少数十倍时间.
这样统一的资源运维方式是未来保证企业在竞争中业务快速上线的必须手段.

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

11

添加新评论3 条评论

aixkevinaixkevin存储工程师某公司
2018-09-02 22:00
谢谢分享
wuwenpinwuwenpin软件开发工程师南京
2018-04-26 18:01
非常不错的资料,谢谢分享!
郑金辉郑金辉技术总监某公司
2018-04-26 16:04
请教几个问题: 1、在贵单位的实践过程中,云管对与虚拟资源、物理资源的自动化部署和资源发放能实现到什么程度? 2、金融客户对于异构资源的统一纳管是否是强需求,强到什么程度 3、跨资源池的负载调度现在可以如何实现,如果不考虑网络负载均衡的方式 谢谢!
Ctrl+Enter 发表

本文隶属于专栏

最佳实践
不同的领域,都有先行者,实践者,用他们的最佳实践来加速更多企业的建设项目落地。

作者其他文章

  • 数据中心虚拟化实践讨论总结
    评论 0 · 赞 2
  • 用hmc完成vios的配置
    评论 0 · 赞 3
  • 全新开始
    评论 0 · 赞 0
  • 相关文章

    相关问题

    相关资料

    X社区推广