集团云数据中心计算资源池-规划设计
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
集团云数据中心计算资源池详细规划设计
目录
1前言 (2)
1.1背景 (2)
1.2文档目的 (2)
1.3适用范围 (2)
1.4参考文档 (2)
2设计综述 (3)
2.1设计原则 (3)
2.2设计思路 (5)
2.3建设目标 (7)
3集团云计算规划 (8)
3.1整体架构规划 (8)
3.2资源池规划 (8)
3.2.1计算资源池 (9)
1前言
1.1背景
集团信息中心中心引入日趋成熟的云计算技术,建设面向全院及国网相关单位提供云计算服务的电力科研云,支撑全院各个单位的资源供给、数据共享、技术创新等需求。
实现云计算中心资源的统一管理及云计算服务统一提供;完成云计算中心的模块化设计,逐渐完善云运营、云管理、云运维及云安全等模块的标准化、流程化、可视化的建设;是本次咨询规划的主要考虑。
1.2文档目的
本文档为集团云计算咨询项目的咨询设计方案,将作为集团信息中心云计算建设的指导性文件和依据。
1.3适用范围
本文档资料主要面向负责集团信息中心云计算建设的负责人、项目经理、设计人员、维护人员、工程师等,以便通过参考本文档资料指导集团云计算数据中心的具体建设。
1.4参考文档
《集团云计算咨询项目访谈纪要》
《信息安全技术信息系统安全等级保护基本要求》(GB/T 22239-2008)
《信息系统灾难恢复规范》(GB/T20988-2007)
《OpenStack Administrator Guide》(/)
《OpenStack High Availability Guide》(/)
《OpenStack Operations Guide》(/)
《OpenStack Architecture Design Guide》(/)
2设计综述
2.1设计原则
结合集团当前的实际现状及未来三年业务发展需求,此次云计算规划的考虑原则如下:
1、关注IT能力的快速提升
IT能力包括业务服务能力和运维能力上。
业务服务能力上,从技术层面来说,包括物理硬件资源、云计算资源抽象层、统一的应用平台以及应用软件。
运维能力则包括了人员、流程、工具等各个方面。
图1 IT能力组成示意
对于云计算技术的选择以及运维工具的选择上,在技术对比之外,更应关注于选择本身是否能给集团带来业务服务能力以及运维能力的快速提升上,并以此作为评判的基本原则。
2、采用开放的架构
开放本身有两个含义:源代码开放和标准开放。
源代码开放,允许集团可以拥有完全的掌控,可以修改或则增加新的功能满足集团自身的需要;标准开放意味着集团可以通过各种符合标准的产品构成自己的云计算方案
图2 开放架构的两方面含义
对于集团而言,标准开放比源代码开放更重要。
源代码开放虽然能够让集团拥有完全的掌控,但由于人力的持续投入,以及业务重心的考虑,所谓的“完全的掌控”并不一定能够获得;而标准开放可以避免受单个实体控制(使单个实体受益),这是集团更应关注的。
3、关注资源的弹性
资源的弹性来自于集团的业务需求,也是重要的设计原则。
资源的弹性体现在各个层面。
硬件层面更多的表现为资源可以线性扩展,可以快速部署;IAAS平台层面则需要能够支撑管控规模的线性扩展;云资源层面则真正实现资源的弹性,可以随着业务量的增多而弹性增加,也可以随着业务量的萎缩而弹性收缩;应用层面的弹性则更多的体现在灵活的部署上。
4、其他通用原则
除去上述集团应该特别关注的原则外,整个规划设计还需要考虑下述通用原则:
图3 其他通用原则汇总
◼高可用性:结构的高可用性,资源的冗余部署,逻辑关系的松耦合设计,不会因为任何一个模块发生故障而影响业务的开展。
具体来说,包括物
理网络、云计算资源、云计算平台、业务应用自身等各个层面的高可用。
◼安全性:安全区域合理规划,安全策略精细化部署,安全策略进行统一的管理,能够满足未来业务发展对安全的需求。
◼灵活性:满足业务与应用系统灵活多变的资源分配及部署需求。
◼可管理性:结构简单、健壮,易于管理和维护,满足监管要求及日常运维的需求,并提供及时发现和排除故障的能力。
◼性能:采用的技术应带来性能的提升,至少本身不会带来性能的大幅下降。
2.2设计思路
集团云计算的服务对象包括业务及科研体系、运维体系、管理层,未来则可能面向集团,甚至其他企业提供服务。
每个服务对象对云计算的关注和诉求均存在不同。
具体分析各个对象的需求,可以发现:
◼自有业务体系:能够方便、快速的获得所需IT资源,不愿介入IT本身的管理维护,业务系统不中断;
◼其他业务体系:对云内隔离的疑虑,对云内安全的需求,对可靠性保证的担忧;
◼管理层:关注投资收益比,能方便的获得投资决策数据,包括业务的经营数据,IT的运营数据;
◼运维体系:平台可靠,易于管理,业务快速自愈能力,弹性扩展能力,运维工作量低,完善的安全防护;
◼建设者:建设者和运维体系可以是一个实体,但基于对象考虑它有其独特的需求。
初始能够快速建设,后续能够快速的扩容,建设周期短,人
员投入少,建设质量有保证;
针对各个对象需求分析总结,云计算的规划思路主要在于标准化模块化、资源池化、资源服务化、云容量的可视化、运维部署自动化、资源高可用、云安全服务、运维场景化这些方面,具体分析见下面的表格。
表1
对前面的规划思路进行归纳分类,云计算的规划主要需要考虑下面的六点:◼物理资源的模块化、标准化;
◼资源池化;
◼统一管理平台(统一平台的资源服务化、云容量的可视化、运维部署自动化);
◼业务连续性;
◼云安全服务;
◼运维场景化;
后面针对每一点分别进行具体分析。
2.3建设目标
结合集团IT架构现状和未来业务发展的需求,我们给出的解决建议有采用标准化硬件基础设施建设;建设云计算高可用架构的统一资源池;建设统一的云管理平台;构建统一的PaaS平台;构建运维体系、流程和工具;建设基于等保的安全体系,最终达到IT资源统一云化、科研环境平台化、业务应用服务化、运维管理自动化的云计算建设目标。
3集团云计算规划
3.1整体架构规划
日前,集团发布信息通信新技术推动智能电网和“一强三优”现代公司创新发展行动计划(以下简称行动计划),推进大数据、云计算、物联网和移动互联等新技术在智能电网和“一强三优”现代公司建设中的创新应用。
集团未来三年云计算整体蓝图,需要构建多中心的“科研云”,全面提升集团未来的业务创新能力,保障业务快速安全交付。
对于其中同城云数据中心内的建设,则可以划分为物理资源层、虚拟化平台层、云服务层,以及贯穿各个层面的运维管理层
整个科研云涵盖IaaS、PaaS、SaaS服务,提供完整的云计算服务;同时科院云是符合等保三级和集团合规要求的安全可靠的云;同时建设统一的运营、运维管理体系贯穿整个科研云各个层面;构建集团统一的云服务门户,通过云服务门户统一对内对外提供云服务,支持科研各应用领域:
3.2资源池规划
针对集团此次云计算的建设,从基础网络、云网络、计算、存储、云平台、安全、运维和容灾八个领域对云计算进行规划设计,基于开源的高可用的商用云
计算架构,各组件松耦合、模块化、标准化,实现云计算的灵活性,最终实现统一的资源池化、统一资源管理和统一资源交付的目标。
3.2.1 计算资源池
3.2.1.1计算资源池设计目标
目前调研来看集团大部分的业务系统都是适合虚拟化的,并且目前正在进行业务云化的工作;但大数据平台等高性能计算、高IO的系统应该部署在物理服务器上,以减少虚拟化平台的资源争用。
因此,集团计算资源池建设目标:将虚拟化、裸金属、高性能计算、大数据资源的统一池化,通过统一的云平台,实现对各种异构资源的统一整合管理,同时针对不同的业务需求,实现亲和性的多资源池智能调度。
3.2.1.2 虚拟化资源池规划设计
在云计算体系中,x86架构服务器是计算资源池的核心。
将相同或者相似类型的服务器组合在一起,通过安装虚拟化软件,实现服务器的软硬解耦,屏蔽物理设备的差异,统一管理和调度,从而形成统一的计算资源池。
完整的虚拟化系统逻辑架构如下图所示:
在虚拟化系统架构中,虚拟化软件应该包括两个部分,即虚拟化内核和虚拟化管理系统。
◼ 虚拟化内核
☐ 运行在物理服务器和上层操作系统之间的“元”操作系统,用于协调
上层操作系统对底层硬件资源的访问,减轻软件对硬件设备以及驱动
的依赖性,同时对虚拟化运行环境中的硬件兼容性、高可靠性、高可
用性、可扩展性、性能优化等问题进行处理和优化。
☐ 结合集团未来云规划,虚拟化集群应该选择KVM 内核架构,并且兼
容现有的虚拟化平台。
◼ 虚拟化管理系统
☐ 实现对数据中心内的计算、网络和存储等硬件资源和虚拟资源的统一
管理和调度,形成虚拟资源池;
☐ 虚拟化管理系统对上层应用提供自动化服务,包括:虚拟计算、虚拟虚拟化系统逻辑架构
虚拟化管理系统虚拟化内核
服务器服务器
网络、虚拟存储、高可靠性( HA)、动态资源调度( DRS)、虚拟机
容灾与备份、虚拟机模板管理、集群文件系统、虚拟交换机策略等。
为了对外提供差异化的服务质量,我们应该按照不同应用场景,对计算资源进行分组,从而在逻辑上形成多个不同的计算资源区。
每个计算资源区用于某些预定义的应用群组,内由多个同类型服务器构成。
通过选择不同的服务器型号和数量,高可用架构(HA,负载均衡),来满足不同应用分组在高可用性和性能方面的不同需求。
在云计算资源区中,对计算资源采用分层管理的模型可以有效的降低管理复杂度,提高管理效率。
在分层管理模型中,从顶层到底层一般分为云资源、主机池、集群、宿主机和虚拟机等;其中云资源、主机池和集群属于逻辑组件,宿主机和虚拟机属于物理组件。
共享存储
◼云资源
✧分层管理模型中的顶层资源,涵盖虚拟化系统可管理范围内所有的硬
件基础设施,包括服务器、存储和网络。
◼主机池
✧一系列主机和集群的集合体,主机可纳入集群中,也可以单独存在。
没有加入集群的主机全部在主机池中进行管理。
◼集群
✧一系列主机的集合,系统通过对集群内主机和虚拟机状态的监控,可
以实现虚拟机的高可用性、资源动态调度等特性
◼主机
✧物理服务器,即虚拟化宿主机,为虚拟机提供硬件环境;
◼虚拟机
✧由运行在宿主机上的虚拟化内核模拟形成,每台虚拟机都是一个完整
的系统
使用虚拟化集群的目的是克服单机虚拟化的局限性,利用技术手段提高虚拟机的可用性,最终达到业务不中断或减少业务中断时间,确保业务数据更安全的目标。
虚拟化平台应具备如下功能架构,目前集团已经建成计算资源池,但是在虚拟化的高可靠、资源动态调度需要优化,资源弹性伸缩和虚机备份上有待建设。
虚拟化资源池建设时应遵循以下规范,才能发挥虚拟化的可靠性和最大性能:(1)虚拟化管理平台
管理平台应部署双机集群,支持高可用性,作为全局虚拟化的管理中心;(2)主机池
在内网二级、三级业务、开发测试区和外网的二级系统区分别构建资源池,同一个二层网络的主机应规划在同一个主机池中;
(3)集群
从主机池中选择适当数量的服务器(建议14~20台服务器),组成一个集群,如业务集群1 ,同一个集群具有HA的属性。
同一集群的主机应该在同一个POD里面,因此建议4U服务器15台组成一个集群;
每个集群符合N+1原则,更具可靠性;同时避免只有2台物理机的资源池的相关可能潜在的问题;
(4)网络
从安全隔离、性能和可靠性角度,网络可根据承载流量的不同,按功能划分为业务、管理和存储网络,并独立部署;
(5)存储
对物理层提供的存储设备进行统一的整合与池化,为虚拟机提供统一的存储资源池,是高可用、资源弹性调度等特性的基础;
建议每个LUN大小在12~15T,但不能超过虚拟化平台支持的最大值;
各应用系统对计算能力的需求不同,为了能够快速的为业务部门交付计算资源,我们需要设计一系列不同规格的虚拟机模板,以满足不同应用、不同时期的需求,同时对虚机模板进行统一的加固和配置,简化运维。
根据实际应用需要,定制不同规格虚拟机模板,匹配不同的用户需求,内存应该是CPU核数的1~4倍;
虚拟机的模板需要做系统加固、打上必要的补丁、安装VMM Tools、开启监控协议、安装备份和防病毒的客户端,并经常性维护更新。
3.2.1.3裸金属资源池建设规划
裸金属资源池规划目标:
(1)自动化批量部署高性能物理服务器,运维管理便捷;
(2)服务器与云内其它虚拟机、容器等资源互连互通,融合管理;
(3)可以通过云平台定制开发实现物理服务器的管理,如通过OpenStack ironic组件来实现,但要注意服务器的兼容性;
3.2.1.4高性能计算资源池建设规划
在高性能计算区规划2U、4U、带GPU的物理服务器,用来部署大数据、GIG等系统,并且建设HPC池满足高性能计算的业务要求;高性能计算区采用40G互联网络,保证东西向内部互访的需求;与云平台集成,统一管理。
3.2.1.5大数据资源池建设规划
大数据应部署在物理服务器上,推荐集群规划如下:
➢Hadoop集群
–建议20台及以上物理服务器,Hadoop集群管理节点和数据
节点使用不同的物理服务器
–但是建议根据未来业务发展情况进行提前规划,避免后期扩
容需要平衡数据;
➢MPP集群
–建议选择3个节点为1个safegroup,推荐配置6台及以上服务器
组网如下图所示:
部署大数据的服务器配置推荐如下:
◼不推荐使用虚拟内存
◼建议使用更多块硬盘,2块1T硬盘性能优于1块2T硬盘。
◼建议单数据节点容量最大不超过24TB,否则节点失效后造成大量数据复本的复制。
◼不建议使用SSD,Hadoop的磁盘IO多为顺序读写,不能完全发挥适用于随机读写的SSD的性能优势,同样的采购投入可以通过多
个HDD提高并发量提高性能。
硬盘RAID配置推荐如下:
注意:共享存储系统不适用于集群数据存储,单点存储是大数据集群的运算性能瓶颈。
大数据各节点安装核心组件推荐如下:
企业在构建大数据平台时一般都是循序渐进式的建设,随着数据量的高速增长和数据分析业务的逐渐复杂,大数据平台面临经常扩容和参数调整的问题,为了减低运维难度,建议采用商业化的大数据集群管理软件,其优点如下:
◼一键部署,动态扩容;
◼动态参数调整;
◼集群管理
◼主机管理
◼服务管理
◼用户管理
◼告警监控,多维度监控
◼丰富的BI展示
3.2.1.6集团计算规划路线规划
集团计算资源池规划路线分三个阶段进行建设:
第一阶段:根据业务等保要求构建不同的资源池;大数据迁移至物理服务器上形成大数据资源池;
第二阶段:构建完善的高性能计算资源池;
第三阶段:构建开发测试资源池:
20。