5

> 1. 引言

“大数据”与“云计算”都是当前炙手可热的话题。大数据解决了应用层海量数据分析与计算的问题,将应用系统从传统的“查Excel”(小数量规模下的有关系型数据库的增删改查),演进到关联分析、基于图计算、有智慧、并提供精准营销的应用。

“云计算”解决大型数据中心的资源利用率提升和自动化运维管理,它管理的对象中显然包括需要使用大量计算资源的“大数据”系统。因此从层次上讲,“云计算”技术为“大数据”技术提供基础资源,云计算是基础设施能力(IaaS),大数据是云计算的一种服务能力(PaaS)。

6大数据与云计算的上下层关系

大数据集群都将是一个由近30种角色组成的庞大的应用部署群,一般会分为部署节点、管理节点、计算节点、流计算节点、数据复制节点等。典型的这些节点部署的角色如下:

1496827013(1)

这些节点中只有计算节点因为承载了HDFS的海量数据持久化而建议物理机部署外,其它节点都可以进行虚拟化部署,从而使大数据集群可以部署在云数据中心中统一管理,最终实现大数据服务的资源共享、统一管理、按需分配、动态调度。目前相关的技术与解决方案也处于蓬勃的发展过程中并逐步走向成熟。

OpenStack是目前规模最大、社区最活跃的开源云计算技术,最有可能成为未来私有云的事实标准。OpenStack提供功能完善、高效稳定、灵巧开放的大数据服务和集中管控能力,实现对大数据基础服务的彻底云化,同时实现对于其他异构、分布系统的系统集中管控,帮助企业实现面向服务的应用基础架构转型,构筑更加灵活、敏捷的应用环境。本文探讨基于OpenStack技术的云数据中心中大数据集群的落地方案。

>2.  Sahara大数据服务

Sahara是基于OpenStack的开源BDaaS(BigData-as-a-Service)项目,Sahara的目标是为用户提供简单部署Hadoop、Spark、Storm集群的能力。用户可通过提供简单的参数,如:版本信息、集群结构、节点硬件信息等,Sahara可以在数分钟之内将集群部署起来,同时也支持集群的按需扩容和缩容。

2.1  Sahara介绍

1)Sahara功能特性

OpenStack的标准组件之一,因此能够和OpenStack其他服务无缝集成;

1. 支持通过REST API管理集群;

2. 支持多种大数据计算框架,包括但不限于:Hadoop、Spark、Storm;

3. 多种Hadoop厂商发行版,比如CDH、HDP、MapR等;

4. 可插除的Hadoop安装引擎,Liberty版之后默认使用Heat引擎;

5. 集成厂商的管理工具,如ApacheAmbari 和ClouderaManager;

6. 可集成其他外部监控工具,比如Nagios、Zabbix,支持同时监控多个Hadoop集群;

7. 支持json/yaml配置模板;

8. 支持节点动态扩展。

2)Sahara应用场景

Sahara应用场景包括:

1. 提供在OpenStack上快速配置和部署大数据集群的能力;

2. 充分利用OpenStack IaaS层的计算能力;

3. 提供分析即服务(Analyticsas a Service,AaaS)的数据分析业务。

3)Sahara部署大数据集群

先介绍Sahara进行如何部署大数据集群,相关工作流程如下图所示:

7

使用Saraha部署大数据平台

1. 选择Hadoop或其它框架的版本;

2. 选择基础镜像,可选预安装的大数据框架服务(如果镜像中没有预安装大数据框架,Sahara也支持后续通过安装插件进行大数据软件安装);

3. 设置集群的参数,包括集群规模、拓扑、配置参数,并提供标准模版;

4. 创建集群:Sahara会进行虚拟机的安装和集群服务的配置;

5. 大数据集群管理:包括添加或者删除节点;

6. 若集群不再需要,可进行删除。

4)Sahara大数据分析服务

接下来介绍Sahara如何进行大数据分析服务,相关工作流程如下图所示:

8

Sahara的大数据分析服务

1. 通过图形界面选择一个预定义的大数据框架版本;

2. 编辑任务参数:

a) 选择任务类型:pig、hive、jar-file等;

b) 提供任务的脚本地址或者jar包的位置;

c) 选择输入输出数据的位置;

3. 设置作业类型的集群;

4. 通过插件(VendorsPlugins)启动大数据服务,通过EDP(ElasticData Processing)调度大数据分析任务,集群创建和任务执行过程对最终用户是不可见的;

5. 获取任务执行结果。

2.2  部署方案

大数据作业通常分为IO密集型(离线数据分析)、计算密集型(在线数据分析)和流计算(实时数据分析)三种。IO密集型指以IO处理为核心作业对象的作业,例如日志分析,数据仓库等,通常使用Map/Reduce、YARN框架;计算密集型指以内存数据的处理为核心作业对象的作业,例如仿真计算、人工智能等,通常使用Spark框架;流计算通常使用Storm框架对实时数据流进行处理。

Sahara的成熟方案是在虚拟机上部署大数据集群。在虚拟的大数据集群中,计算的性能损失较少,理论数据少于5%。存储使用虚拟机的系统磁盘或者为虚拟机配备独立的数据磁盘,这种模式下虚拟使用的磁盘不是本地磁盘,很多场景下是Ceph分布式存储提供的三副本的高可用数据卷,HDFS集群的性能损失较多。

社区有上两种技术来解决:一种是将Cinder分配的数据磁盘创建在虚拟机所在的计算节点上,实现某种程度的数据本地化;一种是建议使用计算密集型和流计算作业的应用,并使用Swift对象存储作为作业的输入输出源,减少对HDFS存储的读写。建议对计算密集型和流计算作业的应用场景采用如下的Sahara部署方案。

9

Sahara在虚拟机上部署大数据集群原理示意图

Sahara支持在物理机上自动部署大数据集群。该方案将规避虚拟机部署中的性能损耗问题,支持IO密集型作业。

10

Sahara在物理机上部署大数据集群原理示意图

另外,Sahara也支持半虚半实的大数据集群的部署。大数据集群节点中的管理节点、流计算节点对IO的需求量不大,可以使用虚拟机方式进行部署,而计算节点对IO需求大,保留物理部署模式。

11

Sahara在半虚半实环境中部署大数据集群原理示意图

Sahara的自动化也让客户的多集群环境成为可能。即根据大数据的业务容量规划建设长期的多项目共享的半虚半实的大数据环境,同时在虚拟机中部署临时的大数据集群,在大数据业务波峰时,通过临时集群来弹性增加处理能力,分担共享大数据集群的数据处理压力。

12

由Sahara管理的Big Data Burst架构示意图

3. 其它技术方案

Sahara大数据服务对于新建的OpenStack数据中心来说是最佳选项,但企业数据中心的现状往往比较复杂,下面介绍的几个方案各有特色,适用于不同的小众场景。

3.1  物理机托管方案

适用场景:

企业数据中心有存量的大数据集群,并大量使用离线数据分析类业务。

方案细节:

OpenStack可以为大数据集群提供:

1. 将现有大数据集群纳入到OpenStack的裸机集群,提供资源层的性能监控。

2. 基于OpenStack的应用监控系统,实现对大数据集群的应用层的性能监控。并与资源层的性能监控组成完整的监控体系,方便快速定位大数据集群故障,以及运行中的性能瓶颈。

3. 在大数据集群扩容时,使用OpenStack的裸机管理技术自动推送“Big Data Ready”的操作系统镜像,后续由大数据集群推送大数据的服务角色,缩短了大数据集群的扩容周期。

OpenStack的裸机集群的管理技术是Ironic。Ironic通过PXE和IPMI进行物理服务器的控制管理,实现了物理服务器的自动化运维。

13

OpenStack Ironic托管大数据集群的示意图

3.2  虚拟化迁移方案

本方案在物理机托管方案的基础上,进一步优化了服务器资源的使用。

适用场景:

企业数据中心有存量的大数据集群,并大量使用在线数据分析业务和流计算业务。

方案细节:

大数据集群节点中的管理节点、流计算节点对IO的需求量不大,建议通过P2V、业务迁移等方案转为虚拟机部署,而计算节点对IO需求大,保留物理部署模式。

本方案很适用于现有大数据集群的升级改造,通过将旧集群中低资源利用率的节点回收,并进行虚拟化部署,初步达到了提升资源利用率,并实现对大数据集群部分节点的云化管理。

本方案目前在国内已经有落地的案例,将一个31节点的大数据集群中的14个非计算节点进行虚拟化迁移,同时基于OpenStack的应用监控体系,实现了对大数据集群与云基础资源的统一监控,在充分利用物理机资源的同时也实现了虚拟化节点的弹性伸缩,向大数据集群的云化迈出了坚实的一步。

14

虚拟化迁移后的大数据集群部署示意图

3.3  节点融合方案

本方案将每一个虚拟化服务器绑定一个大数据的计算节点,并将本地硬盘独享给这个虚拟机。以牺牲虚拟机的灵活性为代价,通过硬件资源独享设计保障了计算节点的IO效率。

本方案中大数据集群的部署需要手工参与,资源利用率比单纯物理机托管有所提升。

本方案适用于企业自建的混合式数据中心。我方测试的数据显示,采用这种方案部署的大数据集群,在运行Spark作业时性能损失仅为12.8%。

本方案虽然对系统资源有部分损失,同时大数据集群的计算节点动态调度性稍差,但实现了大数据集群的集中管控、资源的集中共享,基本实现了大数据集群的云化诉求。

15

虚拟化节点与大数据计算节点融合部署原理示意图

3.4   容器部署方案

在容器中部署大数据环境是目前呼声比较高的大数据解决方案。容器化大数据是基于容器技术对于大数据集群的节点进行容器化封装,从而实现大数据集群的便捷部署。

容器技术解决了大数据集群的快速部署问题。但容器集群只适用于小规模的临时集群作业,因为它受到了两个限制条件:

a. 容器受Linux cgroup机制的限制,在大量计算面前很容易因为资源超标而被强制退出;

b. 容器使用持久化网络、持久化存储的能力较弱,HDFS数据的存储是个大问题:当有容器宕机,系统重新生成新容器时,会产生大量的数据重平衡工作,与作业的高负载的波峰重叠,直接导致集群的阻塞。

容器技术仅仅解决了大数据集群的快速部署问题,但稳定性与性能还需要生产环境的验证,同时,由于多容器对于磁盘IO的共享,容器化大数据集群不适合IO密集型作业。

16容器大数据系统示意图

3.5  方案对比

下面对大数据云化的各类方案的优劣势进行综合分析如下:

图片16

4. 大数据云化是未来数据中心发展的关键

在数据爆炸的时代,数据将是企业的核心竞争力,而数据中心在企业中的地位将越来越重要。随着移动互联网、云计算、大数据、人工智能、物联网等技术的发展,未来的数据中心一定会沿着IT到DT的技术方向发展演化。

17

未来数据中心演进方向

IT时代以基础设施能力为核心构建数据中心,DT时代以数据能力为核心构建数据中心。在DT时代,数据的存储与加工处理成为数据中心的设计灵魂,而IT则会扁平化成分布式架构,在数据中心的整体设计中折叠起来。

下图是作者预测的未来数据中心的基础模型。IT层已经弱化为分布式资源池(计算池、存储池、网络池),展现为逻辑上的三个中心:应用中心、智慧中心、数据中心。

18

DT时代的云数据中心逻辑架构图

应用中心由现在的云计算资源池发展而来,负责通用计算部分;智慧中心由现在的大数据资源池发展而来,负责并行计算部分;数据中心则合并了云计算资源池与大数据资源池的数据,实现了全局数据中心。

全局数据中心是DT时代的数据中心的灵魂。随着移动互联网、LoT、VR、人工智能等新技术的迸发,全局数据中心迎来了数以百计的新的数据源,产生了海量的大数据,因此传统上“搬数据”模式下ETL、数据复制必定会成为DT时代被淘汰的技术。

全局数据中心保证了应用数据的唯一性,应用中心与智慧中心通过消息机制来保障分布式协同,维护数据存储与加工处理的一致性。

作者简介:

6年的云与虚拟化咨询、研发、建设和运维经验;专注于OpenStack企业云建设与应用落地实践;熟悉商业产品与解决方案,拥有Citrix CCA & VMWare VCP认证;为Adobe、Citrix、华为、中国移动、首信、中航工业、国家电网等数十家大型企业提供过云服务。