目  录

1 概述

1.1 DataEngine简介

1.2 本手册适用范围

1.3 相关术语

2 部署前准备工作

2.1 DataEngine部署总述

2.2 DataEngine集群类型

2.3 环境要求

2.3.1 操作系统环境要求

2.3.2 浏览器与软件要求

2.3.3 网络规划

2.3.4 组网方案

2.4 集群部署规划

2.4.1 集群部署整体原则

2.4.2 HDP集群各服务部署规划

2.4.3 HDP集群服务所在节点磁盘方案

2.5 HDP集群部署场景

2.5.1 数据分发缓存集群

2.5.2 在线结构化数据集群

2.5.3 在线非结构化数据集群

2.5.4 全文检索ElasticSearch集群

2.5.5 全文检索Solr集群

2.5.6 实时流集群

2.5.7 Redis集群

2.5.8 离线分析挖掘集群

2.5.9 分布式内存计算集群

2.6 MPP1集群

2.7 DataEngine高可靠方案

2.7.1 DataEngine Manager高可靠

2.7.2 HDP集群高可靠

2.7.3 MPP系列集群

3 部署DataEngine Manager

3.1 部署DataEngine Manager的步骤

3.2 DataEngine Manager HA相关操作

3.2.1 查看DataEngine Manager HA状态

3.2.2 手动切换DataEngine Manager 主备

3.2.3 管理节点上软件的操作方法

3.3 访问DataEngine Manager

4 部署HDP或MPP1集群

4.1 部署HDP集群

4.2 部署MPP1集群

5 客户端配置

5.1 添加浏览器安全证书

5.2 修改本地hosts文件

6 访问集群主页

6.1 安装后检查

6.1.1 主机管理检查

6.1.2 服务组件检查

6.1.3 健康检查

6.2 是否开启安全模式

6.2.1 安全模式

6.2.2 非安全模式

7 DataEngine的License配置

7.1 软件注册

7.2 在DataEngine Manager中配置License

8 卸载

8.1 卸载服务

8.1.1 单服务整体卸载

8.1.2 单服务单组件卸载

8.1.3 服务强制卸载

8.2 卸载集群

9 DataEngine扩展包的使用

10 常见问题解答

11 附录

11.1 Kerberos端口号更改操作指导

11.1.1 DataEngine集群未开启安全模式

11.1.2 DataEngine集群已开启安全模式

11.1.3 修改后台的相关配置

11.2 部署MPP2集群

11.2.1 MPP2集群部署前准备

11.2.2 MPP2集群高可靠方案

11.2.3 MPP2集群部署流程

 

1 概述

1.1  DataEngine简介

DataEngine是指H3C大数据集成管理平台，通过DataEngine Manager管理界面可以统一监控和管理集群内所有服务和服务组件、主机、告警信息以及日志等。DataEngine自带简单多样的部署方案、丰富细致的集群运维和成熟完备的服务支持，可以满足不同行业客户的个性化需求。

1.2  本手册适用范围

本手册所涉及的操作系统相关参数的调整，主要针对CentOS操作系统。

1.3  相关术语

为帮助您更好的理解DataEngine，下面对本手册中涉及到的术语进行简单介绍。

·     HDP集群

HDP（Hadoop Data Platform），指DataEngine中包含的所有服务的集合，主要包括HDFS、MapReduce、YARN、ZooKeeper、Spark等服务，是大数据处理的基础平台。

·     MPP系列集群

MPP（Massive Parallel Processing，大规模并行计算），是数据库集群架构中的一种，其基本特征是：由多个主机通过节点互联而成，每个节点只访问自己的本地资源（内存、存储等），是一种完全无共享（Share Nothing）结构。MPP架构扩展能力较高，理论上可以无限扩展，目前的技术可实现数百个节点互联，支持数千个CPU。

·     节点类型

DataEngine中主要包括以下三类节点：

¡     管理节点（Management Node，简称MN），安装DataEngine集群的管理系统（即DataEngine Manager）。DataEngine Manager提供统一的访问入口，对部署在集群中的所有节点及服务进行集中管理。

¡     控制节点（Control Node，简称CN），控制和监控数据节点上执行存储数据、接收数据、发送进程等过程的状态，是服务的中枢节点。例如：HBase的Master、HDFS的NameNode等。

¡     数据节点（Data Node，简称DN），执行控制节点发出的指示（上报任务状态、存储数据等），例如：HBase的RegionServer、HDFS的DataNode等。

·     服务

大数据集群中的应用服务，对外提供某种业务功能，例如：HDFS、YARN、Spark等。

·     组件和实例

¡     组件：是服务的组成部分，每个服务由一个或多个组件组成。

¡     实例：服务中的组件被安装到服务器节点上即形成一个实例，部分组件支持在一个节点上部署多个实例。

·     背板带宽

交换机的背板带宽，是指交换机接口处理器或接口卡和数据总线间所能吞吐的最大数据量。

 

2 部署前准备工作

 

2.1  DataEngine部署总述

DataEngine部署包括部署DataEngine Manager管理界面和部署DataEngine集群两部分，DataEngine集群的部署和管理必须通过DataEngine Manager管理界面。DataEngine集群安装包包括基础包和扩展包，其中基础包可用于部署DataEngine Manager管理界面和DataEngine平台支持的主要服务，扩展包提供DataEngine平台支持的其他扩展服务。

 

DataEngine的部署步骤汇总如表2-1所示。

表2-1 DataEngine部署步骤汇总

序号	步骤	详细操作		说明
1	选择DataEngine集群类型	开展部署前的准备工作，以满足环境要求、集群部署规划和不同业务集群的要求等		必选
2	安装DataEngine基础包，部署DataEngine Manager	部署DataEngine Manager的步骤		必选
		DataEngine Manager HA相关操作		可选
3	客户端配置	添加浏览器安全证书		可选（推荐）
		修改本地hosts文件		必选
4	访问DataEngine Manager	/		必选
5	部署DataEngine集群	部署HDP集群		根据实际情况，选择安装
		部署MPP1集群		根据实际情况，选择安装
		DataEngine扩展包的使用（可选）	部署MPP2集群	根据实际情况，选择安装
6	访问集群主页	安装后检查		可选（推荐）
		是否开启安全模式		必选
7	DataEngine的License配置	/		必选

 

2.2  DataEngine集群类型

在生产环境中，根据业务需求不同，DataEngine集群分为多种类型，如表2-2所示。

表2-2 DataEngine集群类型

集群类型	业务集群
HDP集群	数据分发缓存集群
	在线结构化数据集群
	在线非结构化数据集群
	全文检索ElasticSearch集群
	全文检索Solr集群
	实时流集群
	Redis集群
	离线分析挖掘集群
	分布式内存计算集群
MPP系列集群	MPP1集群
	部署MPP2集群

 

进行DataEngine集群规划时，需要关注以下内容：

·     规划集群中的节点数目以及集群中的机柜数目

·     规划每个机柜中的节点数目以及每个机柜的名称

·     规划集群中各节点的角色：管理节点、控制节点或数据节点

·     规划两个管理节点（一个作为主节点，一个作为备用节点）和访问DataEngine Manager的虚拟IP地址

·     规划每个节点所在的子网（或多个子网），以及规划每个节点的主机名和IP地址

【注意】：在两个或者多个集群中做数据备份、迁移或其他通信时，规划的主机名需要在所有集群中保证名称唯一

·     需要知道集群中用户的密码（DataEngine集群安装时要求所有节点使用的用户名和密码必须保持一致）

·     对于HDP集群，需要规划集群中安装哪些服务

2.3  环境要求

2.3.1  操作系统环境要求

部署DataEngine集群时，支持的操作系统说明如表2-3所示。

表2-3 操作系统说明

操作系统	版本说明
Red Hat Enterprise	推荐：RedHat-7.3-x86_64（RedHat 7.3） 可用：RedHat-6.8-x86_64（RedHat 6.8）
CentOS	推荐： CentOS-7.3-x86_64（CentOS 7.3）、CentOS-7.6-x86_64（CentOS 7.6） 可用：CentOS-6.8-x86_64（CentOS 6.8）

 

 

2.3.2  浏览器与软件要求

1. 浏览器要求

DataEngine Manager对浏览器的要求如下：

·     Chrome 45及以上版本

·     Firefox 18及以上版本

2. 软件要求

部署DataEngine时，需要准备的软件安装包如表2-4所示。

表2-4 软件列表

软件名称	版本	用途说明	获取方式
DataEngine安装包（基础包）	DataEngine-<version>-Basic.tar.gz	用于安装DataEngine平台的Manager和基础服务	由H3C提供
DataEngine安装包（扩展包）	DataEngine-<version>-Extra.tar.gz	用于安装DataEngine平台的扩展服务	由H3C提供
当前操作系统镜像	*.iso	提供基础的yum源	由用户准备（备注：该镜像不能使用Minimal镜像）

 

2.3.3  网络规划

·     集群中各节点之间不能跨越防火墙

·     规划网络带宽和交换机背板带宽，决定交换机型号

·     规划如何连接到交换机，必须知道需要用到哪些以太网端口以及是否需要绑定

2.3.4  组网方案

1. 带宽确定

(1)     流量统计模型

DataEngine所需汇聚交换机带宽=m*n*k*i/h，其中参数说明如下：

¡     m：数据节点数，是一对汇聚交换机下接入的主机数据节点数量，分布在不同的机架中。

¡     n：每节点业务网卡端口数，一般是2个或多个网卡绑定。

¡     k：网卡端口带宽，推荐10GE网卡。

¡     i：节点带宽占用率，根据不同业务模型选择，也可以取不同业务平衡值。

¡     h：接入汇聚网络带宽收敛比，根据不同业务模型选择，也可以取不同业务平衡值。

特例：Storm所需汇聚带宽=m*TPS * pkgSize，其中参数说明如下：

¡     m：数据节点数，是一对汇聚交换机下接入的主机数据节点数量，分布在不同的机架中。

¡     TPS：每秒处理消息数。

¡     pkgSize：最大消息大小。

(2)     节点带宽规划

根据上述DataEngine典型的流量模型，为了让节点间的交换带宽不影响系统性能，推荐DataEngine产品采用10GE网卡。

(3)     接入-汇聚带宽规划

根据上述DataEngine典型的流量模型：一个接入交换机下挂m节点，每个数据节点两个10GE网卡绑定接入到机架交换机，则建议汇聚带宽为：m*n *k*i/h，单位为Gbps。

例如：m=20，业务模型接入汇聚带宽收敛比h为2:1，每节点2个10GE网卡绑定连接接入交换机，节点带宽占用率为40%，则汇聚带宽为：20*2*10*40%/2 = 80Gbps。如果接入交换机每台引出4 条10GE 接入到汇聚交换机，则总共带宽为：2（接入交换机数量）*4（上行端口数量）*10Gbps（端口速率为10GE）=80Gbps。

(4)     接入交换机堆叠带宽规划

正常情况下，节点与双接入交换机之间、双接入交换机与汇聚交换之间都是全互联。考虑到可能出现一个接入交换机的上行链路全故障的异常场景，可以安全接入交换机堆叠。堆叠线之间只有控制流量，而并没有业务流量。此时该交换机的所有上行流量都必须通过堆叠线经另一个交换机上行，堆叠线上流量为总上行流量的一半。

例如，上例汇聚带宽为80Gbps，则堆叠带宽建议配置为40GE。

2. 集群组网

(1)     组网要求

¡     实现网络冗余，增加网络可靠性。

¡     多机架实现数据分组备份，增加数据安全性、可靠性。

¡     汇聚交换可线性扩展，使集群具有良好的横向扩展能力。

¡     分组网络在并行数据加载和计算下可实现网络的均衡负载，提高集群整体性能。

¡     分层网络保证大数据集群的网络安全性，同时可根据业务需要与其他网络搭配混合组网。

(2)     主机端口配置

表2-5 端口配置建议

交换机配置	交换机端口配置	节点端口配置	可用带宽 （示例）	说明	配置建议
堆叠	负载均衡Trunk	负载均衡Bond	2M	Bond模式：mode=4 采用IEEE802.3ad，动态链路聚合模式，需要交换机支持。网络流量在Bond的两个子端口上均衡分配	推荐
	主备Trunk	主备Bond	1M	Bond模式：mode=1 采用主备（activebackup）策略。网络流量只在主端口上	-
不堆叠	无Trunk	主备Bond	1M	Bond模式：mode=1，primary=port1 采用主备（activebackup）策略，同时将所有节点的缺省主用端口设置为同一接入交换机的端口，避免不必要的汇聚流量。网络流量只在主端口上	推荐
	无Trunk	适应性负载均衡Bond	2M	Bond模式：mode=6 采用自适应负载策略（balancealbrlb Adaptive Load balancing）。网络流量Bond在两个子端口上均衡分配。汇聚流量较大	-
单接入交换机	无Trunk	主备Bond	1M	Bond模式：mode=1，primary=port1 采用主备（activebackup）策略，同时将所有节点的缺省主用端口设置为同一接入交换机的端口，避免不必要的汇聚流量。网络流量只在主端口上	-
	负载均衡Trunk	负载均衡Bond	2M	Bond模式：mode=4 采用IEEE802.3ad，动态链路聚合模式，需要交换机支持。网络流量在Bond的两个子端口上均衡分配	推荐
	主备Trunk	主备Bond	1M	Bond模式：mode=1 采用主备（activebackup）策略。网络流量只在主端口上	-

 

(3)     多网卡绑定设置

网卡Bond指通过多个网卡绑定为一个逻辑网卡的操作，实现本地网卡的冗余，带宽扩容和负载均衡，所以建议在生产环境中使用。网卡的绑定和操作系统有关，不同操作系统下网卡绑定的设置不同。本手册以CentOS 6.8操作系统为例，说明一个双网卡绑定的案例，多网卡绑定与双网卡绑定设置类似。

CentOS 6.8操作系统下双网卡绑定设置步骤如下：

a.     识别网卡名称和对应的设备位置。

b.     安装操作系统完毕后，操作系统会识别出主机的网卡名称，例如一台主机包含两块网卡，接口名称分别为eth1和eth2。

c.     使用命令ethtool -p eth1查看相应设备名称对应的设备位置，执行该命令后，与eth1相对应的网卡接口旁边的指示灯将会闪烁，这样就能查看eth1网卡对应的位置。其余网卡位置的判定方法相同。

d.     确定绑定方式：

eth1和eth2网卡绑定为bond0。

e.     进行bond0的配置。

切换目录到/etc/sysconfig/network-scripts下，使用root用户进行如下操作：

-     新建ifcfg-bond0文件，编写内容如下：

#cd /etc/sysconfig/network-scripts #vi ifcfg-bond0 DEVICE=bond0 ONBOOT=yes BONDING_OPTS="mode=4 miimon=100" BOOTPROTO=static TYPE=Ethernet USERCTL=no IPADDR=192.168.103.88 NETMASK=255.255.255.0 NM_CONTROLLED=no

 

-     修改ifcfg-eth1文件，修改后内容如下：

#cd /etc/sysconfig/network-scripts #vi ifcfg-eth1 DEVICE=eth1 ONBOOT=yes BOOTPROTO=none TYPE=Ethernet MASTER=bond0 SLAVE=yes USERCTL=no NM_CONTROLLED=no

 

-     修改ifcfg-eth2文件，修改后内容如下：

#cd /etc/sysconfig/network-scripts #vi ifcfg-eth2 DEVICE=eth2 ONBOOT=yes BOOTPROTO=none TYPE=Ethernet MASTER=bond0 SLAVE=yes USERCTL=no NM_CONTROLLED=no

 

f.     加载绑定模块。

在/etc/modprobe.d/dist.conf这个文件的末尾加入如下内容：

alias bond0 bonding

g.     将绑定设置为开机自动加载方式。

在/etc/rc.d/rc.local这个文件的倒数第2行加入如下内容：

ifenslave bond0 eth1 eth2

ifup bond0

h.     重启操作系统，验证配置正确性。

重启操作系统后，在root用户下使用命令ifconfig验证配置是否正确，验证如下情况：

-     bond0虚拟网卡能被操作系统识别，并且配置的IP地址正确无误。

-     eth1、eth2网卡不显示IP地址。

-     bond0的MAC地址与eth1、eth2的其中一个相同（bond0与哪个网卡的MAC地址相同，则那个网卡为现在启用的网卡）。

使用命令ifconfig验证上面三点的方法：

# ifconfig bond0     Link encap:Ethernet  HWaddr 90:B1:1C:2F:FB:BF      inet addr:192.168.103.88  Bcast:192.168.255.255  Mask:255.255.255.0     inet6 addr: fe80::92b1:1cff:fe2f:fbbf/64 Scope:Link     UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1     RX packets:735202 errors:0 dropped:0 overruns:0 frame:0     TX packets:13 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0      RX bytes:562057464 (536.0 MiB)  TX bytes:1016 (1016.0 b)   eth1      Link encap:Ethernet  HWaddr 90:B1:1C:2F:FB:BF    UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1   RX packets:735202 errors:0 dropped:0 overruns:0 frame:0   TX packets:13 errors:0 dropped:0 overruns:0 carrier:0         collisions:0 txqueuelen:1000   RX bytes:562057464 (536.0 MiB)  TX bytes:1016 (1016.0 b)   Interrupt:34

 

2.4  集群部署规划

2.4.1  集群部署整体原则

·     隔离实时和非实时工作负载，对实时性要求比较高的负载建议采用独立集群。

·     根据业务对硬件资源的根本性差异（含CPU/内存/磁盘/网络），建议按照SLA等级，将不同业务拆分部署。例如：MapReduce通常是磁盘密集型应用、Spark通常是CPU/内存密集型应用、冷数据归档一般需要高密存储、混合负载的基础分析集群则需要具备分级存储和标签调度能力等。

·     根据客户的业务管理需要（如安全/备份策略要求、业务数据源归属、故障隔离要求等），可进一步切分集群，比如分割数据平台和应用集群。

·     若集群中资源充足，三种节点建议独立部署，即每个节点上所部署的服务进程属于同一类型；若集群资源不充足时，以上三类节点需要合设到一个服务器上，该服务器则同时具备了两种或三种角色功能。

·     若资源紧张，需要管理节点与集群内其他节点合并部署时，要求这些节点上均不能安装LADP，否则会失败。

·     管理节点与控制节点合并部署的节点，主要需要综合考虑控制组件的均衡部署，以及有关联关系的组件必须同步部署两个因素。

·     集群中各服务之间可能存在依赖或者关联的关系，分别说明如下：

¡     A依赖于B，表示若集群中部署A服务，需要提前或同时部署B服务。A与B可以不部署在相同的节点上。

¡     A与B关联，表示若集群中部署A服务，需要同时部署B服务。A与B需要部署在相同的节点上。

·     对于有多个版本的服务，例如Hive与Hive2、ElasticSearch与ElasticSearch5、Spark与Spark2对应的进程建议不要部署在同一节点上，以避免不同版本上所使用的配置相同后出现端口冲突等问题。

·     只有Standalone模式的服务，例如PostgreSQL、Sqoop、Flume和HUE等可以根据节点实际情况选择部署，主要考虑资源剩余情况。

·     ZooKeeper、JournalNode建议在每个控制节点上部署，控制节点的个数需随着集群规模的扩大适当扩大。

·     服务的Client端需要结合实际情况，因为Client一般不占用实体进程资源，所以每个节点上都可以添加部署，这样可以使每个节点都能使用客户端程序。

2.4.2  HDP集群各服务部署规划

表2-6 集群中服务部署规划

服务名称	组件名称		依赖关系	服务组件业务部署原则
DataEngine Manager	Manager Server		-	默认部署在2个管理节点上
	LDAP与内置PostgreSQL		-	LDAP Server与内置PostgreSQL均部署在管理节点上
	Kerberos	Kerberos Admin	Kerberos Server依赖于LDAP Server，Kerberos Server与Kerberos Admin关联	部署在管理节点上，与Kerberos Server部署在相同的节点上
		Kerberos Server		部署在管理节点上，与Kerberos Admin部署在相同的节点上
ZooKeeper	Zookeeper Server		-	每个集群内最少配置3个在控制节点上。如需扩展，请保持数量为奇数个，最多支持9个节点
	Zookeeper Clients			建议非管理节点上全部部署
HDFS	NameNode		NameNode开启HA后，依赖于ZooKeeper	默认部署在2个控制节点上
	ZKFC（ZKFailoverController）			部署在2个控制节点上，且ZKFC要与NameNode安装在相同节点上
	DataNodes			至少部署3个，建议部署在数据节点上
	JournalNode			至少部署在3个节点上，且要求个数为奇数个
	NFS网关			可部署0～n个，与DataNode部署在相同的节点上
YARN	Resource Manager		依赖于HDFS和ZooKeeper	默认部署在2个控制节点上，主备配置
	Node Manager			部署在数据节点上，与HDFS的DataNode保持一致
	App Timeline Server			一个集群中只能部署在一个控制节点上
	YARN Client			建议非管理节点全部部署
MapReduce2	History Server		依赖于YARN、HDFS和ZooKeeper	默认部署在2个节点上，提高服务稳定性
	MapReduce2 Clients			建议非管理节点全部部署
Hive	Hive Server2		依赖于DataEngine内置的PostgreSQL、MapReduce2、HDFS、YARN、ZooKeeper和TEZ	默认部署在2个控制节点上，提供高可用
	Hive Metastore			默认部署在2个控制节点上，负荷分担
	WebHCat Server			默认部署在2个控制节点上，负荷分担
	Hcat Client			与NodeManager部署在相同节点上
	Hive Client			与NodeManager部署在相同节点上
HBase	HBase Master		依赖于HDFS、ZooKeeper、YARN	默认部署在2个控制节点上，主备配置
	Region Servers			部署在数据节点上，与HDFS的DataNode保持一致
	Phoenix Query Server			默认部署2个。若Phoenix Query Server访问HBase延时不能满足用户需求的时候，可部署多个在控制节点或数据节点上
Flume	Flume		依赖于HDFS和ZooKeeper	建议单独部署，不建议Flume和DataNode部署在同一节点，否则会存在数据不均衡的风险
Kafka	Kafka Broker		依赖于ZooKeeper	至少部署在2个数据节点上。若每天产生的数据量超过2TB，建议部署在多个数据节点上
Oozie	Oozie Server		依赖于YARN、HDFS和MapReduce2	默认部署在2个控制节点上
Solr	Solr (N=1~5)		依赖于ZooKeeper 说明： Solr数据选择保存在本地磁盘	每个节点可以配置5个实例。建议配置3个以上的节点，且每个节点上的实例个数均匀分布 说明： ·     Solr数据优先选择保存到HDFS，每个节点部署三个Solr实例 ·     单节点实时索引速度在2MB/s以上的，建议部署到本地磁盘。示例：每个节点Solr实例部署5个，存储在HDFS相比本地磁盘性能下降30%～50% ·     SolrServerAdmin与SolrServer相互关联，凡是部署SolrServer的节点同时也部署SolrServerAdmin
HBase Indexer	-		依赖于HBase、HDFS和ZooKeeper 说明： 一般不需要部署，除非需要使用HBase Indexer功能	默认部署在2个节点上
Storm	DRPC Server		依赖ZooKeeper	默认部署一个在非管理节点上
	Supervisor			至少部署在1个数据节点上，如需提供大量计算能力，可部署多个，建议部署在独立节点上。主要负责管理工作进程（Worker）、工作进程数量、内存配置，对资源占用较大 说明： Supervisor部署数目可根据公式进行计算，即需要的Supervisor数=拓扑数×每个拓扑要求的Worker数/Supervisor配置的Worker数 其中：拓扑数和每个拓扑要求的Worker数为客户自行规划项，Supervisor配置的Worker 数默认为4
	Storm UI Server			根据Nimbus的部署情况进行规划，和Nimbus是联动关系，每个部署Nimbus的节点也有Storm UI Server 【注意】：Storm UI Server不能部署在管理节点上
	Nimbus			分别部署在2个控制节点上，主备配置，和Storm UI Server是联动关系 【注意】：Nimbus不能部署在管理节点上
Redis	RedisNodes		-	单Master模式Redis至少部署在1个数据节点上；如需部署Redis集群，则至少要部署到3个数据节点上
	Redis Cluster Manager		-	与RedisNodes关联，需部署到RedisNodes其中的两个节点上，主备部署
	Redis Live		-	与RedisNodes关联，需部署到RedisNodes其中的两个节点上，主备部署 【注意】：Redis Live与Redis Cluster Manager需要部署在相同节点上
PostgreSQL	PostgreSQL Server		-	默认部署在2个控制节点上
Tez	Tez Client		-	建议部署在非管理节点上
Log Manager	Log Manager Server		依赖Infra Solr和ZooKeeper	默认部署在2个，可部署多个
Metrics	Metrics Collector		-	一个集群中只能部署在一个控制节点上 【注意】：Metrics Collector不能部署在管理节点上
Hive2	Hive2 Metastore		依赖Hive	默认部署在2个控制节点上
	Hive2server2			默认部署在2个控制节点上，根据实际情况可部署多个，主要用于连接分流
	Hive2 Clients			部署在数据节点上
Sqoop	Sqoop Clients		-	部署在数据节点上
ElasticSearch5	ElasticSearch5		-	每个节点可以配置3个实例。建议配置3个以上节点，每个节点上的实例个数均匀分布
Spark2	Spark2 History Server		依赖Hive	默认部署在2个控制节点上
	Spark2 Livy			默认部署在2个，对外提供Restful 接口
	Spark2 Thrift Server			默认部署在2个控制节点上，根据实际情况可部署多个，用于连接分流
	Spark2 Clients			部署在数据节点上，所有数据节点均需部署
Infra Solr	Infra Solr Instance		依赖ZooKeeper	默认部署在3个控制节点上
	Infra Solr Clients			部署在数据节点上
Sparrow	Sparrow History Server		依赖Hive	默认部署在2个控制节点上
	Sparrow Thrift Server			默认部署在2个控制节点上，根据实际情况可部署多个，用于连接分流
	Sparrow Clients			建议部署在数据节点上，所有数据节点均部署
Flink	Flink Clients		依赖ZooKeeper、HDFS和YARN	建议部署在非管理节点上

 

2.4.3  HDP集群服务所在节点磁盘方案

1. 磁盘RAID方案

整体原则：管理节点与控制节点都做RAID1；数据节点做RAID0或者不做RAID；元数据路径最优是单独挂盘，并做RAID1。

 

表2-7 各服务所在节点的RAID设置推荐（MN、CN、DN均单独部署时）

服务名称	组件名称	RAID配置推荐
操作系统OS	-	RAID1
DataEngine Manager	LDAP与PostgreSQL	RAID1
	WEB Service	RAID1
	Kerberos Admin 与Kerberos Server	RAID1
HDFS	NameNode	RAID1
	Standby NameNode	RAID1
	ZKFC	RAID1
	JournalNode	RAID1
	NFS网关	RAID0或者RAID1
	DataNode	RAID0
Zookeeper	Zookeeper Server	RAID1
YARN	Resource Manager	RAID1
	App Timeline Server	RAID1
	NodeManager	RAID0
MapReduce2	History Server	RAID1
Hive	HiveServer2	RAID1
	Hive MetaStore	RAID1
	WebHCat Server	RAID1
HBase	HBase Master	RAID1
	HRegionServer	RAID0
	Phoenix Query Server	RAID0或者RAID1
Flume	Flume	RAID0
Kafka	Kafka Broker	RAID0
Oozie	-	RAID1
Solr	SolrServerN(N=1~5)	RAID5
	SolrServerAdmin	RAID5
HBase Indexer	-	RAID0
Storm	DRPC Server	RAID1
	Supervisor	RAID0
	Storm UI Server	RAID1
	Nimbus	RAID1
Redis	Redis Nodes	RAID5
	Redis Live	RAID5
	Redis Cluster Manager	RAID5
PostgreSQL	-	RAID0
Tez	-	RAID0
Log Manager	Log Manager Server	RAID1
	Log Feeder	RAID0或者RAID1
Metrics	Metrics Collector	RAID1
	Metrics Monitor	RAID0或者RAID1
ElasticSearch5	Elasticsearch5	RAID0
Sqoop	-	不涉及RAID
Hive2	Hive2Server2	RAID1
	Hive2 MetaStore	RAID1
Infra Solr	-	RAID5
Spark2	Spark2 History Server	RAID1
	Spark2 Thrift Server	RAID1
	Spark2 Livy	RAID1
Sparrow	Sparrow History Server	RAID1
	Sparrow Thrift Server	RAID1
Flink	-	不涉及RAID

 

2. 磁盘空间规划

仅从硬盘空间来考虑，集群主要分为离线计算、在线查询、全文检索。其中：离线计算主要是MapReduce2/Spark/Hive集群针对HDFS文件的运行计算；在线查询主要是对HBase的操作及查询；全文检索主要是针对ElasticSearch或Solr的操作及查询。

·     离线计算与在线查询都是基于HDFS的操作，所以磁盘规划的原则是一致的。按照以下公式计算集群节点规模：

 

表2-8 基于HDFS的磁盘空间规划计算示例

配置项	配置值
集群总数据量（TB）	100
HDFS副本数量	3
应用层数据压缩率	1
数据膨胀率	1.2
单硬盘大小（TB）	1.8
单节点硬盘数量	25
磁盘利用率	70%
磁盘格式化率	1.093
集群数据节点数	13

 

·     全文检索的磁盘规划主要基于Solr或ElasticSearch，按照以下公式计算集群节点规模：

 

表2-9 基于ElasticSearch的磁盘空间规划计算示例

配置项	配置值
集群总数据量（TB）	100
Solr或者ElasticSearch副本数量	2
单条数据大小（KB）	0.2
单节点数据条目（亿条）	200
集群数据节点数	50

 

3. 磁盘分区方案

磁盘分区规划如下：

·     操作系统盘：OS盘，存在于所有节点，用来存放各节点操作系统，有固定的分区要求。

【注意】：如果安装操作系统时不修改默认分区配置，后续容易造成系统磁盘空间不足的问题，例如/var/log可能会占满系统分区等。

·     数据盘：缺省挂载在/opt目录下，不需要单独分区。

·     一个分区可以单独占用一个磁盘也可以是某个磁盘的一部分。当资源允许每个分区对应一个磁盘时，建议单独占用磁盘；当资源受限时，也必须要保证独立分区，以减少服务数据彼此之间的影响。

 

表2-10 系统盘磁盘的分区要求

硬盘容量(GB)	硬盘用途	分区目录	文件系统类型	分区容量(GB)	用途
≥800	OS	/	ext4	剩余磁盘空间，且容量至少≥300GB	大数据平台软件安装及操作系统使用
		/var/log	ext4	单独占用分区，建议容量≥200GB	日志存储
	PostgreSQL（DataEngine Manager内置数据库）	/var/lib/pgsql	ext4	单独占用分区，建议容量≥300GB	存储服务组件的配置信息和管理信息 当集群节点数较多时，应适当调大该分区大小

 

2.5  HDP集群部署场景

根据生产环境的实际需求，不同类型的DataEngine集群均需要分别规划两个DataEngine Manager管理节点。

 

2.5.1  数据分发缓存集群

 

1. 节点规划

表2-11 数据分发缓存集群节点规划

节点类型	服务/组件	说明
管理节点	DataEngine Manager	安装DataEngine Manager管理界面，可以单独安装，也可以和集群中其他节点共用 【说明】需规划两个管理节点：一个作为主节点，一个作为备用节点
控制节点	ZooKeeper Server	Zookeeper节点数量规划如下： ·     集群节点规模为3~9时（集群节点规模至少为3），需要3个控制节点，Zookeeper安装3个，但均无需预留节点单独安装Zookeeper ·     集群节点规模为10~29时，需要3个控制节点，Zookeeper安装3个，且此时建议预留节点单独安装Zookeeper ·     集群节点规模为30~100时，需要5个控制节点，Zookeeper安装5个，且此时建议预留节点单独安装Zookeeper ·     集群节点规模为100~300时，建议7个控制节点，Zookeeper安装7个，且此时建议预留节点单独安装Zookeeper
数据节点	Kafka Broker	主要安装数据分发缓存Kafka，节点数量规划说明如下： ·     Kafka Broker至少安装在2个节点上 ·     根据实际生产环境的数据量，调整Kafka Broker节点数量，数据存储周期在一周以内时，计算公式：节点数量=结构化数据每天原始文件数据量/单节点处理能力 【示例】：此章节配置下的公安场景，Kafka缓存数据存储周期在一周以内时，单节点数据处理能力为原始文件数据量1.2TB/天 【说明】：Kafka缓存数据周期不建议超过7天，若存储周期超过7天，则数据节点计算方式详情请咨询H3C技术支持工程师

 

2. 节点硬件要求

 

表2-12 数据分发缓存集群服务器硬件要求

节点类型	RAID配置	服务器硬件要求
管理节点	RAID1	CPU：2路10核，推荐5115 内存：256GB 硬盘：8块600GB SAS硬盘 RAID卡：1GB Raid0/5卡（带超级电容） 网口：2个千兆网口，2个万兆网口
控制节点	RAID1	CPU：2路10核，推荐5115 内存：256GB 硬盘：8块600GB SAS硬盘 RAID卡：1GB Raid0/5卡（带超级电容） 网口：2个千兆网口，2个万兆网口
数据节点	RAID0	CPU：2路10核，推荐5115 内存：256GB 硬盘：2块600GB SAS硬盘、12块4TB SATA硬盘 RAID卡：1GB Raid0/5卡（带超级电容） 网口：2个千兆网口，2个万兆网口

 

2.5.2  在线结构化数据集群

 

1. 节点规划

表2-13 在线结构化数据集群节点规划

节点类型	服务/组件	说明
管理节点	DataEngine Manager	安装DataEngine Manager管理界面，可以单独安装，也可以和集群中其他节点共用 【说明】需规划两个管理节点：一个作为主节点，一个作为备用节点
控制节点	Zookeeper Server、NameNode、SnameNode、Resource Manager、App Timeline Server、History Server、HBase Master	其中Zookeeper节点数量规划如下： ·     集群节点规模小于300时（集群节点规模至少为3），需要3个控制节点，Zookeeper安装3个，此时可不预留节点单独安装Zookeeper（即其中2个Zookeeper与NameNode共同安装） ·     集群节点规模大于300时，需要5个控制节点，Zookeeper安装5个，建议预留节点单独安装Zookeeper
数据节点	DataNodes、NFSGateway、Node Manager、Region Servers、Phoenix Query Server	前提： ·     磁盘空间需预留30%，即实际磁盘容量=磁盘总容量*70% ·     入库数据与原始数据量比例为2.3:1 则根据实际生产环境的数据量，调整数据节点数量，计算公式：节点数量=结构化数据每天的原始文件数据量（TB）*2.3*天数/单节点可用容量 【示例】：此章节配置下的公安场景，数据入库速率为30MB每秒单节点（按照24小时实时入库计算，如果是白天12小时实时入库，可以按照一半的节点进行计算）

 

2. 节点硬件要求

 

表2-14 在线结构化数据集群服务器硬件要求

节点类型	RAID配置	服务器硬件要求
管理节点	RAID1	CPU：2路10核，2.0GHz，推荐5115 内存：256GB 硬盘：2块480GB SATA硬盘，6块1.2TB SAS硬盘 RAID卡：1GB Raid0/5卡（带超级电容） 网口：2个千兆网口，2个万兆网口
控制节点	RAID1	CPU：2路10核，2.0GHz，推荐5115 内存：256GB 硬盘：2块480GB SSD硬盘，6块1.2TB SAS硬盘 RAID卡：1GB Raid0/5卡（带超级电容） 网口：2个千兆网口，2个万兆网口
数据节点	RAID0	CPU：2路10核，2.0GHz，推荐5115 内存：256GB 硬盘：2块600GB SAS硬盘，12块4TB SATA硬盘 RAID卡：1GB Raid0/5卡（带超级电容） 网口：2个千兆网口，2个万兆网口

 

2.5.3  在线非结构化数据集群

 

1. 节点规划

表2-15 在线非结构化数据集群节点规划

节点类型		服务/组件	说明
管理节点		DataEngine Manager	安装DataEngine Manager管理界面，可以单独安装，也可以和集群中其他节点共用 【说明】需规划两个管理节点：一个作为主节点，一个作为备用节点
控制节点		Zookeeper Server、NameNode、SnameNode、Resource Manager、App Timeline Server、History Server、HBase Master	其中Zookeeper节点数量规划如下： ·     集群节点规模为3~9时（集群节点规模至少为3），需要3个控制节点，Zookeeper安装3个，但均无需预留节点单独安装Zookeeper（即其中2个Zookeeper与NameNode共同安装） ·     集群节点规模为10~29时，需要3个控制节点，Zookeeper安装3个，且此时建议预留节点单独安装Zookeeper ·     集群节点规模为30~100时，需要5个控制节点，Zookeeper安装5个，且此时建议预留节点单独安装Zookeeper ·     集群节点规模大于100时，建议7个控制节点，Zookeeper安装7个，且此时建议预留节点单独安装Zookeeper
数据节点（数据节点数量需满足计算能力和存储能力两方面的需求，取较大值）	按照计算能力计算	DataNodes、NFSGateway、Node Manager、Region Servers、Phoenix Query Server	根据实际生产环境的数据量，调整数据节点数量，计算公式：节点数量=非结构化数据每天实体文件数据量/单节点处理能力 【示例】：此章节配置下的公安场景，单节点处理能力为1TB/天
	按照存储能力计算		配置原则： ·     考虑（1+1）备份，存储膨胀率是2倍磁盘空间 ·     需预留30%，即实际磁盘容量=磁盘总容量*70% 【示例】：此章节配置下的公安场景，每台节点裸容量48T（Raid0，12*4T），即单节点可用容量是12*4*0.7

 

2. 节点硬件要求

 

表2-16 在线非结构化数据集群服务器硬件要求

节点类型	RAID配置	服务器硬件要求
管理节点	RAID1	CPU：2路10核，推荐5115 内存：256GB 硬盘：8块600GB SAS硬盘 RAID卡：1GB Raid0/5卡（带超级电容） 网口：2个千兆网口，2个万兆网口
控制节点	RAID1	CPU：2路10核，推荐5115 内存：256GB 硬盘：8块600GB SAS硬盘 RAID卡：1GB Raid0/5卡（带超级电容） 网口：2个千兆网口，2个万兆网口
数据节点	RAID0	CPU：2路10核，推荐5115 内存：256GB 硬盘：2块600GB SAS硬盘，12块4TB SATA硬盘 RAID卡：1GB Raid0/5卡（带超级电容） 网口：2个千兆网口，2个万兆网口

 

2.5.4  全文检索ElasticSearch集群

 

1. 节点规划

表2-17 全文检索ElasticSearch集群节点规划

节点类型		服务/组件	说明
管理节点		DataEngine Manager	安装DataEngine Manager管理界面，可以单独安装，也可以和集群中其他节点共用 【说明】需规划两个管理节点：一个作为主节点，一个作为备用节点
控制节点		ElasticSearch master	·     集群节点规模小于等于5时，不需要单独配置ElasticSearch master ·     集群节点规模大于5时，需要配置3个独立的ElasticSearch master 【说明】在DataEngine Manager中配置ElasticSearch Master的方法请参见10 14. 如何在DataEngine Manager中配置ElasticSearch master/data/client？
数据节点（此时也称为：计算节点，节点数量需满足计算能力和存储能力两方面的需求，取较大值）	按照计算能力计算	ElasticSearch data	根据实际生产环境的数据量，调整数据节点数量，计算公式：节点数量=每天结构化数据量/单节点处理能力 【说明】：在满足性能的基础上，可根据需要存储的天数对每台服务器上的磁盘数进行调整 【示例】：此章节配置下的公安场景，单节点处理能力为400GB/天
	按照存储能力计算		配置原则： ·     考虑（1+1）备份，存储膨胀率是2倍磁盘空间 ·     需预留15%，即实际磁盘容量=磁盘总容量*85% 【示例】：此章节配置下的公安场景，每台节点裸容量28.8T（1.2*24T），即单节点可用容量是1.2*24*0.85
Client节点		ElasticSearch client	集群节点规模大于30时，建议配置ElasticSearch client node（一般配置1个即可）

 

2. 节点硬件要求

 

表2-18 全文检索ElasticSearch集群服务器硬件要求

节点类型	RAID配置	服务器硬件要求
管理节点	RAID1	CPU：2路10核，推荐5115 内存：256GB 硬盘：8块600GB SAS硬盘 RAID卡：1GB Raid0/5卡（带超级电容） 网口：2个千兆网口，2个万兆网口
控制节点	RAID1	CPU：2路10核，推荐5115 内存：256GB 硬盘：8块600GB SAS硬盘 RAID卡：1GB Raid0/5卡（带超级电容） 网口：2个千兆网口，2个万兆网口
数据节点	RAID0	CPU：2路10核，推荐5115 内存：256GB 硬盘：2块600GB SAS硬盘，24块1.2TB SAS硬盘 RAID卡：1GB Raid0/5卡（带超级电容） 网口：2个千兆网口，2个万兆网口
Client节点	RAID0	CPU：2路10核，推荐5115 内存：512GB 硬盘：8块600GB SAS硬盘 RAID卡：1GB Raid0/5卡（带超级电容） 网口：2个千兆网口，2个万兆网口

 

2.5.5  全文检索Solr集群

 

1. 节点规划

表2-19 全文检索Solr集群节点规划

节点类型		服务/组件	说明
管理节点		DataEngine Manager	安装DataEngine Manager管理界面，可以单独安装，也可以和集群中其他节点共用 【说明】需规划两个管理节点：一个作为主节点，一个作为备用节点
控制节点		ZooKeeper Server	Zookeeper节点数量规划如下： ·     集群节点规模为3~29时，需要3个控制节点，Zookeeper安装3个，且此时建议预留节点单独安装Zookeeper ·     集群节点规模为30~100时，需要5个控制节点，Zookeeper安装5个，且此时建议预留节点单独安装Zookeeper ·     集群节点规模为100~300时，建议7个控制节点，Zookeeper安装7个，且此时建议预留节点单独安装Zookeeper
数据节点（此时也称为：计算节点，节点数量需满足计算能力和存储能力两方面的需求，取较大值）	按照计算能力计算	Solr Data	根据实际生产环境的数据量，调整数据节点数量，计算公式：节点数量=每天结构化数据量/单节点处理能力 【说明】：在满足性能的基础上，可根据需要存储的天数对每台服务器上的磁盘数进行调整 【示例】：此章节配置下的公安场景，单节点处理能力为400GB/天
	按照存储能力计算		配置原则： ·     考虑（1+1）备份，存储膨胀率是2倍磁盘空间 ·     需预留15%，即实际磁盘容量=磁盘总容量*85% 【示例】：此章节配置下的公安场景，每台节点裸容量28.8T（1.2*24T），即单节点可用容量是1.2*24*0.85

 

2. 节点硬件要求

 

表2-20 全文检索Solr集群服务器硬件要求

节点类型	RAID配置	服务器硬件要求
管理节点	RAID1	CPU：2路10核，推荐5115 内存：256GB 硬盘：8块600GB SAS硬盘 RAID卡：1GB Raid0/5卡（带超级电容） 网口：2个千兆网口，2个万兆网口
控制节点	RAID1	CPU：2路10核，推荐5115 内存：256GB 硬盘：8块600GB SAS硬盘 RAID卡：1GB Raid0/5卡（带超级电容） 网口：2个千兆网口，2个万兆网口
数据节点	RAID5	CPU：2路10核，推荐5115 内存：256GB 硬盘：2块600GB SAS硬盘，24块1.2TB SAS硬盘 RAID卡：1GB Raid0/5卡（带超级电容） 网口：2个千兆网口，2个万兆网口

 

2.5.6  实时流集群

 

1. 节点规划

表2-21 实时流集群节点规划

节点类型	服务/组件	说明
管理节点	DataEngine Manager	安装DataEngine Manager管理界面，可以单独安装，也可以和集群中其他节点共用 【说明】需规划两个管理节点：一个作为主节点，一个作为备用节点
控制节点	ZooKeeper Server、Nimbus、DRPC Server、Storm UI Server	Zookeeper节点数量规划如下： ·     集群节点规模为3~9时（集群节点规模至少为3），需要3个控制节点，Zookeeper安装3个，但均无需预留节点单独安装Zookeeper ·     集群节点规模为10~29时，需要3个控制节点，Zookeeper安装3个，且此时建议预留节点单独安装Zookeeper ·     集群节点规模为30~100时，需要5个控制节点，Zookeeper安装5个，且此时建议预留节点单独安装Zookeeper ·     集群节点规模大于100时，建议7个控制节点，Zookeeper安装7个，且此时建议预留节点单独安装Zookeeper
数据节点（此时也称为：计算节点）	Supervisor	根据实际生产环境的数据量，调整数据节点数量，计算公式：节点数量=原始数据量/单节点每天能够稳定处理的数据量 【示例】：此章节配置下的公安场景，单节点每天能够稳定处理的数据量为300GB。数据量较大时，可按比例计算集群所需的节点数量，例如某省每天总数据量为2TB，则所需服务器台数为：2048/300=7台

 

2. 节点硬件要求

 

表2-22 实时流集群服务器硬件要求

节点类型	RAID配置	服务器硬件要求
管理节点	RAID1	CPU：2路10核，推荐5115 内存：256GB 硬盘：8块600GB SAS硬盘 RAID卡：1GB Raid0/5卡（带超级电容） 网口：2个千兆网口，2个万兆网口
控制节点	RAID1	CPU：2路10核，推荐5115 内存：256GB 硬盘：8块600GB SAS硬盘 RAID卡：1GB Raid0/5卡（带超级电容） 网口：2个千兆网口，2个万兆网口
数据节点	RAID0	CPU：2路10核，推荐5115 内存：256GB 硬盘：8块600GB SAS硬盘 RAID卡：1GB Raid0/5卡（带超级电容） 网口：2个千兆网口，2个万兆网口

 

2.5.7  Redis集群

 

1. 节点规划

表2-23 Redis集群节点规划

节点类型	服务/组件	说明
管理节点	DataEngine Manager	安装DataEngine Manager管理界面，可以单独安装，也可以和集群中其他节点共用 【说明】需规划两个管理节点：一个作为主节点，一个作为备用节点
数据节点	Redis Live、Redis Cluster Manager、RedisNodes	【说明】 ·     集群节点规模至少为3 ·     根据实际生产环境的数据量，调整数据节点数量，配置原则：实际业务预估内存使用量= (每个节点内存大小 * 节点个数) / (2 * Redis副本数 ) 【示例】：此章节配置下的公安场景，每1000万在线用户量(DW\DC\PS)需要1台服务器。例如某省在线用户为3000万，则所需服务器台数为：3000/1000=3台

 

2. 节点硬件要求

 

表2-24 Redis集群服务器硬件要求

节点类型	RAID配置	服务器硬件要求
管理节点	RAID1	CPU：2路10核，推荐5115 内存：256GB 硬盘：8块600GB SAS硬盘 RAID卡：1GB Raid0/5卡（带超级电容） 网口：2个千兆网口，2个万兆网口
数据节点	RAID5	CPU：2路10核，推荐5115 内存：256GB 硬盘：8块600GB SAS硬盘 RAID卡：1GB Raid0/5卡（带超级电容） 网口：2个千兆网口，2个万兆网口

 

2.5.8  离线分析挖掘集群

 

1. 节点规划

表2-25 离线分析挖掘集群节点规划

节点类型		服务/组件	说明
管理节点		DataEngine Manager	安装DataEngine Manager管理界面，可以单独安装，也可以和集群中其他节点共用 【说明】需规划两个管理节点：一个作为主节点，一个作为备用节点
控制节点		Zookeeper Server、NameNode、SnameNode、Resource Manager、App Timeline Server、History Server、Hive Metastore、WebHCat Server、HiveServer2	Zookeeper节点数量规划如下： ·     集群节点规模为3~9时（集群节点规模至少为3），需要3个控制节点，Zookeeper安装3个，但均无需预留节点单独安装Zookeeper ·     集群节点规模为10~29时，需要3个控制节点，Zookeeper安装3个，且此时建议预留节点单独安装Zookeeper ·     集群节点规模为30~100时，需要5个控制节点，Zookeeper安装5个，且此时建议预留节点单独安装Zookeeper ·     集群节点规模大于100时，建议7个控制节点，Zookeeper安装7个，且此时建议预留节点单独安装Zookeeper
数据节点（此时也称为：计算节点，节点数量需满足计算能力和存储能力两方面的需求，取较大值）	按照计算能力计算	DataNodes、NFSGateway、Node Manager	根据实际生产环境的数据量，调整数据节点数量，计算公式：节点数量=结构化数据每天原始文件数据量GB/单节点每天能够稳定处理的数据量 【示例】：此章节配置下的公安场景，主要承载八大要素库和标签计算的业务应用，每台服务器每天处理240GB结构化数据，因此节点数量=DW\DC\PS结构化数据每天原始文件数据量GB/240
	按照存储能力计算		【示例】：此章节配置下的公安场景，根据90天原始数据量+365天专题数据的总容量（采用JBOD模式，2副本存储，存储膨胀比1.5，专题数据按结构化数据5%计算)，如果使用12*4TB的SATA盘配置，可用容量48T，按每天2TB结构化数据量评估则需要台数为：(2TB*90+2TB*365/20)*1.5/（48TB*0.7）

 

2. 节点硬件要求

 

表2-26 离线分析挖掘集群服务器硬件要求

节点类型	RAID配置	服务器硬件要求
管理节点	RAID1	CPU：2路10核，推荐5115 内存：256GB 硬盘：8块600GB SAS硬盘 RAID卡：1GB Raid0/5卡（带超级电容） 网口：2个千兆网口，2个万兆网口
控制节点	RAID1	CPU：2路10核，推荐5115 内存：256GB 硬盘：8块600GB SAS硬盘 RAID卡：1GB Raid0/5卡（带超级电容） 网口：2个千兆网口，2个万兆网口
数据节点	RAID0	CPU：2路10核，推荐5115 内存：256GB 硬盘：2块600GB SAS硬盘，12块4TB SATA硬盘 RAID卡：1GB Raid0/5卡（带超级电容） 网口：2个千兆网口，2个万兆网口

 

2.5.9  分布式内存计算集群

 

1. 节点规划

表2-27 分布式内存计算集群节点规划

节点类型	服务/组件	说明
管理节点	DataEngine Manager	安装DataEngine Manager管理界面，可以单独安装，也可以和集群中其他节点共用 【说明】需规划两个管理节点：一个作为主节点，一个作为备用节点
控制节点	Zookeeper Server、NameNode、SnameNode、Resource Manager、App Timeline Server、History Server、Hive Metastore、WebHCat Server、HiveServer2、Spark2 History Servier、Spark2 Livy、Spark2 Thrift Server	Zookeeper节点数量规划如下： ·     集群节点规模为3~9时（集群节点规模至少为3），需要3个控制节点，Zookeeper安装3个，但均无需预留节点单独安装Zookeeper ·     集群节点规模为10~29时，需要3个控制节点，Zookeeper安装3个，且此时建议预留节点单独安装Zookeeper ·     集群节点规模为30~100时，需要5个控制节点，Zookeeper安装5个，且此时建议预留节点单独安装Zookeeper ·     集群节点规模大于100时，建议7个控制节点，Zookeeper安装7个，且此时建议预留节点单独安装Zookeeper
数据节点（此时也称为：计算节点）	DataNodes、NFSGateway、Node Manager	根据实际生产环境的数据量，调整数据节点数量，计算公式：节点数量=(规划数据量 * 副本数 * 数据压缩率 * 数据膨胀率) / (磁盘总容量 * 磁盘利用率 / 磁盘格式化率)

 

2. 节点硬件要求

 

表2-28 分布式内存计算集群服务器硬件要求

节点类型	RAID配置	服务器硬件要求
管理节点	RAID1	CPU：2路10核，推荐5115 内存：256GB 硬盘：8块600GB SAS硬盘 RAID卡：1GB Raid0/5卡（带超级电容） 网口：2个千兆网口，2个万兆网口
控制节点	RAID1	CPU：2路10核，推荐5115 内存：256GB 硬盘：8块600GB SAS硬盘 RAID卡：1GB Raid0/5卡（带超级电容） 网口：2个千兆网口，2个万兆网口
数据节点	RAID0	CPU：2路10核，推荐5115 内存：256GB 硬盘：2块600GB SAS硬盘，12块4TB SATA硬盘 RAID卡：1GB Raid0/5卡（带超级电容） 网口：2个千兆网口，2个万兆网口

 

2.6  MPP1集群

1. 机架要求

MPP1集群规划机架时需要遵循以下原则：

·     需规划两个Master节点，一个作为主Master，一个作为备用Master（Standby Master）。尽量满足两个Master节点分开放置在不同的机架上。

·     尽量满足Primary实例和其备份实例所在的数据节点分开放置在不同的机架上。

·     同一网段下建议安装一个MPP1集群，否则会影响MPP1服务的HA特性。

2. MPP1集群部署说明

·     集群规模：为了充分发挥MPP1的性能优势，适合的集群规模为6~100台。当集群规模不满足上述要求时，集群整体性能将不能达到最优状态。

·     规则说明：

¡     MPP1的主Master节点禁止和数据节点部署在同一个节点上。当集群中节点数目大于6时，建议主Master、Standby Master和Segment均分开部署，否则会造成硬件资源抢占问题。

¡     如果Standby Master节点跟数据节点部署在同一个节点上，该服务器配置请参见2.6  4. MPP1集群磁盘方案。

表2-29 MPP1集群节点部署方案

节点部署方案	组网规则	适用场景
Master节点、Standby Master节点、Segment分开部署	集群内节点部署在同一子网，集群内通过汇聚交换机二层互联	（推荐）集群节点数目为7~100时使用此方案
Standby Master节点和Segment共用一个节点	集群内节点部署在同一子网，集群内通过汇聚交换机二层互联	集群节点数目小于6时可使用此方案 【说明】： 一般情况下，不推荐使用此场景，若节点数量满足需求，建议将数据节点单独部署

 

3. MPP1集群节点硬件要求

 

表2-30 MPP1集群服务器硬件要求

节点类型	服务器硬件要求
管理节点	CPU：2路10核，推荐5115 内存：256GB 硬盘：2块600GB SAS硬盘，不少于6块1.2T SAS硬盘 RAID卡：1GB Raid0/5卡（带超级电容） 网口：2个千兆网口，2个万兆网口
控制节点	CPU：2路10核，推荐5115（注意：为提高整个集群的性能，应尽量使用主频高性能好的CPU） 内存：256GB 硬盘：2块600GB SAS硬盘，不少于6块1.2T SAS硬盘 RAID卡：1GB Raid0/5卡（带超级电容） 网口：2个千兆网口，2个万兆网口
数据节点（也称为：计算节点）	CPU：2路10核，推荐5115 内存：256GB 硬盘：2块600GB SAS硬盘、不少于12块1.2TB SAS硬盘（注意：硬盘总量相同时，建议使用更多块硬盘） RAID卡：1GB Raid0/5卡（带超级电容） 网口：2个千兆网口，2个万兆网口

 

4. MPP1集群磁盘方案

(1)     磁盘Raid方案

Master和Standby Master节点主要存储元数据信息，对于数据容量要求不高，可以使用小容量的磁盘作为数据挂载磁盘，但是原则上容量也不能低于1T。

表2-31 节点RAID配置方案

节点类型	配置方案	RAID配置和挂载点说明	配置说明
Master	配置1	单独分配数据磁盘并做RAID5，挂载点为/opt/MPP1/	单独配置RAID5时，磁盘性能要优于操作系统盘，也能防止操作系统盘容量到达限额影响MPP1数据库
	配置2	不单独分配数据磁盘，数据盘跟操作系统盘共用，直接创建/opt/MPP1/目录即可（或者单独分区挂载到/opt/MPP1/） 【说明】：操作系统盘容量建议大于1T	为了节省成本可以不单独分配磁盘给Master节点，但是操作系统盘使用RAID1会使性能受到一些影响
Standby Master	配置1	单独分配数据磁盘并做RAID5，挂载点为/opt/MPP1/	单独配置RAID5时，磁盘性能要优于操作系统盘，也能防止操作系统盘容量到达限额影响MPP1数据库
	配置2	不单独分配数据磁盘，Standby Master的数据盘使用操作系统盘，单个分区并挂载到/opt/MPP1/目录 【说明】：操作系统盘容量建议大于1T	为了节省成本可以不单独分配磁盘给Master节点，但是操作系统盘使用RAID1会使性能受到一些影响
Segment	配置1	数据盘做一个RAID5，并将磁盘挂载到/opt/MPP1/上	磁盘数量小于8块时
	配置2	将磁盘分两组分别做两个RAID5，并分别挂载到/opt/MPP1/disk1和/opt/MPP1/disk2上	磁盘数量大于8块时
Standby Master + Segment（不推荐）	配置1	数据盘做一个RAID5，并将磁盘挂载到/opt/MPP1/上	磁盘数量小于8块时
	配置2	分别做3组RAID5，并将磁盘分别挂载到/opt/MPP1/disk、/opt/MPP1/disk1、/opt/MPP1/disk2 示例：当前共有15块磁盘，可以用12块磁盘做两个RAID5，并分别挂载到/opt/MPP1/disk1、/opt/MPP1/disk2。剩下3块磁盘做一个RAID5给Standby Master的数据盘并挂载到/opt/MPP1/disk	磁盘数量大于11块时
	配置3	将磁盘分两组分别做两个RAID5，并分别挂载到/opt/MPP1/disk1和/opt/MPP1/disk2上。Standby Master的数据盘使用操作系统盘，单个分区并挂载到/opt/MPP1/目录	磁盘数量大于8块时，Standby Master的数据盘使用操作系统盘单个分区

 

(2)     磁盘分区方案

磁盘分区规划如下：

·     操作系统盘：OS盘，存在于所有节点，用来存放各节点操作系统，有固定的分区要求。

【注意】：如果安装操作系统时不修改默认分区配置，后续容易造成系统磁盘空间不足的问题，例如/var/log可能会占满系统分区等。

·     一个分区可以单独占用一个磁盘也可以是某个磁盘的一部分。当资源允许每个分区对应一个磁盘时，建议单独占用磁盘；当资源受限时，也必须要保证独立分区，以减少服务数据彼此之间的影响。

 

表2-32 磁盘分区和空间划分

硬盘容量(GB)	RAID类型	硬盘用途	分区目录	文件系统类型	分区容量 (GB)	用途
≥800	RAID1	OS	/	ext4	剩余磁盘空间，且容量至少≥200GB	大数据平台软件安装及操作系统使用
			/var/log	ext4	单独占用分区，建议容量≥200GB	日志存储
			-	swap	内存大小的10%	swap分区，当系统物理内存不够时，临时使用
		PostgreSQL（DataEngine Manager内置数据库）	/var/lib/pgsql	ext4	单独占用分区，建议容量≥200GB	存储服务组件的配置信息和管理信息。 当集群节点数较多时，应适当调大该分区大小
≥1024	RAID5	Master/Standby Master节点	/opt/MPP1/disk	xfs	单独占用分区，建议容量≥1024GB	存储元数据信息
≥1024	RAID5	Segment节点	/opt/MPP1/disk1 /opt/MPP1/disk2	xfs	单独占用分区，建议容量≥1024GB	MPP1集群的数据目录

 

5. MPP1集群节点规划

MPP1集群包括Master节点、Standby Master节点和Segment节点（数据节点）。

表2-33 MPP1集群节点规划

节点类型	服务/组件	说明
管理节点	DataEngine Manager	安装DataEngine Manager管理界面 【说明】需规划两个管理节点：一个作为主节点，一个作为备用节点
控制节点	MPP1 Master、MPP1 Standby Master	Master与Standby Master不能部署在同一节点上 【说明】Master与Segment必须分开部署，Standby Master与Segment可以合并部署
数据节点	MPP1 Segment	建议Master、Standby Master和Segment均分开部署，否则会造成硬件资源抢占问题

 

下面以不同规模的集群进行部署举例：

(1)     节点数目为2~3的集群部署方案

表2-34 MPP1集群节点部署规划（一）

节点数目	部署方案	部署细节	建议与说明
2	方案1	node1：Master node2：Standby Master + Segment	2台集群规模不建议使用MPP1集群，性能不如单台的PostgreSQL
3	方案1	node1：Master node2：Standby Master + Segment node3：Segment	3台集群规模部署数据盘只能做单个Raid5，并挂载在/opt/MPP1/目录下。

 

(2)     节点数目为4~6的集群部署方案

表2-35 MPP1集群节点部署规划（二）

节点数目	部署方案	部署细节	建议与说明
4	方案1	node1：Master node2：Standby Master node3：Segment node4：Segment	数据存储和计算大部分都在Segment节点上，Master和Standby Master占用两个节点对于资源利用率不高
	方案2	node1：Master node2：Segment node3：Standby Master+ Segment node4：Segment	提高了集群服务器利用率，增加Segment节点相当于增加MPP1集群的性能
5	方案1	node1：Master node2：Standby Master node3：Segment node4：Segment node5：Segment	数据存储和计算大部分都在Segment节点上，Master和Standby Master占用两个节点对于资源利用率不高
	方案2	node1：Master node2：Segment node3：Standby Master + Segment node4：Segment node5：Segment	提高了集群服务器利用率，增加Segment节点相当于增加MPP1集群的性能
6	方案1	node1：Master node2：Standby Master node3：Segment node4：Segment node5：Segment node6：Segment	数据存储和计算大部分都在Segment节点上，Master和Standby Master占用两个节点对于资源利用率不高
	方案2	node1：Master node2：Standby Master + Segment node3：Segment node4：Segment node5：Segment node6：Segment	提高了集群服务器利用率，增加Segment节点相当于增加MPP1集群的性能

 

(3)     节点数目大于等于7的集群部署方案（推荐）

表2-36 MPP1集群节点部署规划（三）

节点数目	部署方案	部署细节	建议与说明
7及以上	方案	node1：Master node2：Standby Master node3：Segment node4：Segment node5：Segment node6：Segment node7：Segment node8：Segment node9：Segment node10：Segment node11：Segment node12：Segment …	Master和Standby Master单独使用一个节点，剩余节点全部做Segment

 

2.7  DataEngine高可靠方案

2.7.1  DataEngine Manager高可靠

DataEngine Manager高可靠方案采用Linux HA流行的corosync + pacemaker方案，其中corosync负责两个HA主机之间心跳等信息的交互，pacemaker负责将虚拟IP、PostgreSQL数据库、Manager Server等当作资源来统一管理（启动、停止等），PostgreSQL数据库通过本身的主从流复制实现数据的同步备份。

开启DataEngine Manager HA后，会在集群中的另一个节点上启动备用的DataEngine Manager，通过主节点（Master）与备用节点（Standby）之间的互相备份，以防止发生单点故障。当DataEngine集群中主节点的DataEngine Manager出现故障无法访问时，会自动激活备用节点上的DataEngine Manager，以保证集群运维工作的正常进行。

 

2.7.2  HDP集群高可靠

 

表2-37 HDP服务高可靠方案说明

服务	配置说明
HDFS	安装时默认开启NameNode HA（默认安装两个NameNode），DataNode通过安装在大于等于3个节点上实现高可靠 【注意】：Namenode的备份服务器需要与主服务器的硬件配置相同
YARN	安装时默认开启ResourceManager HA（默认安装两个ResourceManager）
MapReduce2	History Server默认安装在2个节点上实现高可靠
ZooKeeper	ZooKeeper Server通过安装在大于等于3个节点上实现高可靠
ElasticSearch5	通过安装在大于等于3个节点上，并在使用层面设置副本数量实现高可靠
Solr	通过安装在大于等于3个节点上实现高可靠
HBase	HBase Master、RegionServer通过安装在大于等于2个节点上实现高可靠
Hive	Hive Metastore、WebHCat Server、Hive Server2默认安装在2个节点上实现高可靠
Hive2	Hive2 Metastore默认安装在2个节点上实现高可靠，Hive2 Server2通过安装在大于等于2个节点上实现高可靠
Redis	Redis Nodes默认安装1个，此时为单实例模式，无HA；当Redis Nodes安装在大于等于3个节点上，此时为集群模式，有HA Redis Cluster Manager、Redis Live默认安装在2个节点上实现高可靠
Spark2	Spark2 HistoryServer、Spark2 Livy默认安装在2个节点上实现高可靠，Spark2 ThriftServer通过安装在大于等于2个节点上实现高可靠
Sparrow	Sparrow HistoryServer默认安装在2个节点上实现高可靠，Sparrow ThriftServer通过安装在大于等于2个节点上实现高可靠
Storm	Nimbus通过安装在大于等于2个节点上实现高可靠，Storm UI Server默认安装在2个节点上实现高可靠
Flink	Flink服务无独立进程，默认跑在YARN模式下，内部保证作业的HA，安装时无特殊要求
Kafka	Kafka Broker通过安装在大于等于2个节点上实现高可靠
Oozie	Oozie Server通过安装在大于等于2个节点上实现高可靠
Tez	/
Sqoop	/
Flume	/
Log Manager	Log Manager Server通过安装在大于等于2个节点上实现高可靠
HBase Indexer	HBase Indexer通过安装在大于等于2个节点上实现高可靠
PostgreSQL	PostgreSQL默认安装在2个节点上实现高可靠
Infra Solr	Infra Solr Instance通过安装在大于等于3个节点上实现高可靠
Janusgraph	/
Neo4I	/
HUE	HUE Server默认安装在2个节点上实现高可靠
ElasticSearch	通过安装在大于等于3个节点上，并在使用层面设置副本数量实现高可靠
Spark	/

 

2.7.3  MPP系列集群

表2-38 MPP系列高可靠性方案配置说明

组件名称	配置说明
MPP1	MPP1 Master默认安装2个实现高可靠，MPP1 Segment通过安装在大于等于2个节点上实现高可靠
MPP2	MPP2 Server通过安装在大于等于3个节点上实现高可靠，且每个节点默认保存两份数据，用来备份容灾

 

3 部署DataEngine Manager

 

DataEngine部署方案为定制部署，应用场景如下：

·     对于需要利用现有集群中的服务器或者需求多样的客户，这种方式可以满足客户对系统安全、组网环境、节点复用等方面的特殊需求，方便实现一些定制化功能。

·     对集群的部署可以从不同阶段入手帮助客户完成整个大数据集群的搭建。

定制部署主要包括：安装服务器操作系统、分配网络环境、部署DataEngine Manager管理界面、部署DataEngine集群四个阶段，分步执行即可。具体部署流程如下：

(1)     安装服务器操作系统：可以选择PXE自动安装操作系统，也可以手动安装操作系统或对现有操作系统进行安全加固。

(2)     分配网络环境：需要根据客户现有网络环境和网段管理，为每个节点分配指定的主机IP地址。

(3)     部署DataEngine Manager管理界面：在操作系统安装和网络分配完成后，部署DataEngine Manager管理界面，安装过程中会自动开启DataEngine Manager HA功能。

(4)     部署DataEngine（HDP/MPP1）集群：通过DataEngine Manager管理界面为各节点分配服务。

图3-1 定制部署流程图

 

3.1  部署DataEngine Manager的步骤

部署DataEngine Manager的步骤如下：

1. 入口网络规划

在集群部署网段中规划一个IP地址作为入口IP，DataEngine Manager HA功能开启后，将通过入口IP访问DataEngine Manager管理界面。该入口IP地址要求必须是同网段内，未被使用的任一IP地址。

2. 操作用户权限设置

 

使用非root用户启动定制部署时，务必要为DataEngine集群中所有节点的非root用户配置sudo权限，配置步骤如下：

(1)     在DataEngine集群中所有节点上创建相同的非root用户，并设置相同的密码（本章节以bigdata用户进行示例说明）。

(2)     为DataEngine集群中所有节点的bigdata用户配置sudo权限，操作如下：

a.     以root用户赋予/etc/sudoers文件写权限

b.     以root用户在/etc/sudoers文件中root    ALL=(ALL)       ALL后面添加如下内容：

bigdata ALL=(root)       NOPASSWD:/opt/DataEngine-<version>-Basic/script/manager.sh      #这里由于需要填绝对路径，因此需要根据实际情况动态修改为DataEngine安装包的解压路径位置

bigdata    ALL=(root)       NOPASSWD:/.hde/nodes_script.sh

bigdata    ALL=(root)       NOPASSWD:/bin/chmod

bigdata    ALL=(root)       NOPASSWD:/usr/bin/curl

bigdata    ALL=(root)       NOPASSWD:/usr/bin/wget

bigdata    ALL=(root)       NOPASSWD:/bin/mkdir

bigdata    ALL=(root)       NOPASSWD:/usr/bin/tee

bigdata    ALL=(root)       NOPASSWD:/usr/sbin/useradd

bigdata    ALL=(root)       NOPASSWD:/usr/sbin/ambari-agent

bigdata    ALL=(root)       NOPASSWD:/usr/sbin/ambari-server

bigdata    ALL=(root)       NOPASSWD:/usr/bin/nohup

bigdata    ALL=(root)       NOPASSWD:/usr/bin/scp

 

bigdata    ALL=(root)       NOPASSWD:/bin/su - postgres *

bigdata    ALL=(root)       NOPASSWD:/bin/su hdfs *

bigdata    ALL=(root)       NOPASSWD:/bin/su hbase *

bigdata    ALL=(root)       NOPASSWD:/bin/rm

bigdata    ALL=(root)       NOPASSWD:/bin/mv

bigdata    ALL=(root)       NOPASSWD:/usr/bin/python

bigdata    ALL=(root)       NOPASSWD:/bin/cp

bigdata    ALL=(root)       NOPASSWD:/usr/bin/yum

bigdata    ALL=(root)       NOPASSWD:/bin/cat

bigdata    ALL=(root)       NOPASSWD:/usr/bin/service-register

 

bigdata    ALL=(root)       NOPASSWD:/opt/DataEngine-<version>-Basic/HA.sh      #这里由于需要填绝对路径，因此需要根据实际情况动态修改为DataEngine安装包的解压路径位置

bigdata    ALL=(root)       NOPASSWD:/opt/DataEngine-<version>-Basic/HA_next.sh      #这里由于需要填绝对路径，因此需要根据实际情况动态修改为DataEngine安装包的解压路径位置

bigdata    ALL=(root)       NOPASSWD:/opt/DataEngine-<version>-Basic/script/manager_ha.py      #这里由于需要填绝对路径，因此需要根据实际情况动态修改为DataEngine安装包的解压路径位置

 

bigdata    ALL=(root)       NOPASSWD:/.hde/HA_conf/rsync_client.pass

bigdata    ALL=(root)       NOPASSWD:/.hde/ldap.sh

bigdata    ALL=(root)       NOPASSWD:/opt/DataEngine/HA_next.sh

bigdata    ALL=(root)       NOPASSWD:/.hde/HA_next.sh

bigdata    ALL=(root)       NOPASSWD:/.hde/sync_next.sh

bigdata    ALL=(root)       NOPASSWD:/var/lib/ambari-server/ambari-env.sh

bigdata    ALL=(root)       NOPASSWD:/usr/bin/crm

bigdata    ALL=(root)       NOPASSWD:/.hde/HA.sh

bigdata    ALL=(root)       NOPASSWD:/.hde/manager_ha.py

bigdata    ALL=(root)       NOPASSWD:/.hde/sync.sh

bigdata    ALL=(root)       NOPASSWD:/usr/bin/python

bigdata    ALL=(root)       NOPASSWD:/.hde/HA_conf/rsync_client.pass

bigdata    ALL=(root)       NOPASSWD:/opt/DataEngine/HA.sh

bigdata    ALL=(root)       NOPASSWD:/bin/sleep

bigdata    ALL=(root)       NOPASSWD:/bin/echo

bigdata    ALL=(root)       NOPASSWD:/.hde/HA_conf/.ha_nodes

bigdata    ALL=(root)       NOPASSWD:/.hde/cls_rebuild_slave.sh

bigdata    ALL=(root)       NOPASSWD:/sbin/service

bigdata    ALL=(root)       NOPASSWD:/bin/sed

bigdata    ALL=(root)       NOPASSWD:/.hde/cls_rebuild_slave.sh

(3)     配置完成后，即可使用非root用户进行DataEngine安装包的上传及解压操作，详情请参见3.1  3. 安装过程。

 

3. 安装过程

(1)     上传并解压DataEngine安装包

登录集群规划中的主管理节点（Master节点），上传DataEngine安装包至/opt目录下（推荐使用/opt目录，若使用其他目录可能会导致安装失败），解压安装包，命令如下：

tar -xvzf DataEngine-<version>-Basic.tar.gz

解压完成后，当前目录/opt中出现DataEngine-<version>-Basic文件夹。

(2)     拷贝系统镜像文件

将准备的操作系统镜像文件（*.iso）拷贝到解压后DataEngine-<version>-Basic文件夹的/iso目录中。

(3)     通过配置文件安装

进入解压文件夹DataEngine-<version>-Basic中，修改配置文件conf/config。

图3-2 配置文件config内容

 

表3-1 配置文件修改说明

参数	描述	说明
local_ip	修改为DataEngine安装包所在的节点IP，即规划的DataEngine Manager主节点IP地址	必选
manager_port	DataEngine Manager的端口号，默认为8443	必选
standby_ip	修改为规划的DataEngine Manager备用节点的IP地址	必选
virtual_ip	修改为规划的DataEngine Manager的入口IP地址（虚拟IP）	必选
ips	修改为规划的DataEngine集群节点IP组。支持“，；|”三种分隔符，也支持正则表达	必选
prefix	修改为DataEngine集群中各主机的主机名前缀 【注意】：主机名前缀只能包含小写字母或数字，且末尾一位不能是数字（建议末尾两位均不为数字），完整主机名总长度不能超过64位	可选
postfix	修改为DataEngine集群中各主机的主机名后缀 【注意】：主机名后缀不能包含“_”、“*”和“&”等特殊字符，且完整主机名总长度不能超过64位	可选

 

 

(4)     在解压文件夹下，启动安装，命令如下：

./install.sh

 

(5)     检查安装结果

安装通常会在15分钟内结束，具体执行时间与机器性能和并行执行的机器数量有关。安装完成后，会出现相关提示信息，显示访问DataEngine Manager的URL地址以及缺省用户名/密码。

 

3.2  DataEngine Manager HA相关操作

 

3.2.1  查看DataEngine Manager HA状态

登录DataEngine集群主管理节点，在安装路径下，可查看Manager HA的状态，命令如下：

./HA.sh status

 

Manager HA运行正常的状态如图3-3所示，运行错误的状态示例如图3-4所示。其中：

·     关于Manager HA管理资源说明如下：

¡     vip-master代表虚拟IP对应的资源名字

¡     master-server代表ambari-server对应的资源名字

¡     tomcat代表tomcat对应的资源名字

¡     master-krb5kdc代表krb5kdc对应的资源名字

¡     master-kadmin代表kadmin对应的资源名字

¡     msPostgresql代表PostgreSQL数据库对应的资源名字

¡     Master/Slave表示资源是主从资源

¡     Masters代表当前主从资源中的主节点

¡     Slaves代表当前主从资源中的从节点

·     关于资源状态的说明如下：

¡     Started表示资源状态正确，其后面的主机名字字符串表示当前资源在哪个主机上运行

¡     如果状态信息中出现“Stoped”字符串表示资源状态不正确，管理资源已停止

¡     如果状态信息中出现“Failed Actions”字符串也表示资源状态不正确，“Failed Actions”后面跟的内容表示哪些资源的哪些操作不正常

¡     如果状态信息中出现“pgsql data status is not healthy”表示PostgreSQL数据状态不正确

 

图3-3 Manager HA运行正常的状态

 

图3-4 Manager HA运行错误的状态

 

3.2.2  手动切换DataEngine Manager 主备

在某些情况下，需要手动将DataEngine Manager的Standby节点激活成为Master角色提供服务，此时原Master节点将自动切换成Standby角色。操作步骤如下：

(1)     进入安装目录执行./HA.sh status命令查看当前集群状态是否正常，如果正常则可进行主备切换，如果状态不正确请先进行处理。

(2)     登录DataEngine Manager HA备用节点，进入/opt/DataEngine目录（此处的/opt仅为DataEngine安装包在安装节点上对应的路径，请根据实际情况修改）下，执行以下命令：

./HA.sh promote

图3-5 手动切换DataEngine Manager主备节点

 

 

3.2.3  管理节点上软件的操作方法

开启DataEngine Manager HA后，ambari-server、tomcat、kadmin、krb5kdc、PostgreSQL等资源的操作都将受pacemaker管理，不建议人工干预。特殊情况下，如果需要执行停止、启动或重启的操作，命令将发生变更，请务必按照以下说明进行：

(1)     进入安装目录执行./HA.sh status命令查看当前集群状态是否正常，如果状态不正确请先进行处理。

(2)     集群状态正常时，操作命令变更后如下所示：

a.     ambari-server操作命令（非root用户下需要在命令前添加sudo）

停止：crm resource stop master-server

启动：crm resource start master-server

重启：crm resource restart master-server

b.     tomcat操作命令（非root用户下需要在命令前添加sudo）

停止：crm resource stop tomcat

启动：crm resource start tomcat

重启：crm resource restart tomcat

c.     kadmin操作命令（非root用户下需要在命令前添加sudo）

停止：crm resource stop master-kadmin

启动：crm resource start master-kadmin

重启：crm resource restart master-kadmin

d.     krb5kdc操作命令（非root用户下需要在命令前添加sudo）

停止：crm resource stop master-krb5kdc

启动：crm resource start master-krb5kdc

重启：crm resource restart master-krb5kdc

e.     postgresql操作命令（非root用户下需要在命令前添加sudo）

停止：crm resource stop msPostgresql

启动：crm resource start msPostgresql

重启：crm resource restart msPostgresql

 

3.3  访问DataEngine Manager

DataEngine Manager安装完成后，若安装成功，通过URL地址：https://<DataEngine Manager入口节点IP>:<manager_port>，可以访问DataEngine Manager管理界面，如图3-6所示。

图3-6 DataEngine Manager登录界面

 

4 部署HDP或MPP1集群

首次登录DataEngine Manager时会提示部署集群，如图4-1所示，点击<进入安装向导>即可进入集群安装向导页面。

 

图4-1 创建集群

 

4.1  部署HDP集群

部署HDP集群的操作步骤如下：

(1)     进入[开始]页面，输入集群名称后，点击<下一步>。

图4-2 集群名称

 

(2)     进入[选择版本]页面，可以展开高级选项查看安装rpm源地址。然后点击<下一步>。

图4-3 选择版本

 

(3)     进入[安装选项]页面，输入集群各节点主机名（本文以部署3节点的HDP集群示例），默认自动填充。然后点击<注册并确认>。

图4-4 输入集群各节点主机名

 

(4)     进入[确认主机]页面，等待DataEngine对所有节点进行注册并检查。如图4-5所示，所有注册的主机检查通过后，点击<下一步>。

图4-5 确认主机

 

(5)     进入[选择服务]页面，选择想要安装的服务（建议根据前期规划结果进行服务选择），默认勾选Metrics服务。然后点击<下一步>。

图4-6 选择服务

 

 

(6)     进入[分配Master服务]页面，可以在下拉框中为已勾选服务的组件选择对应部署节点，也可接受默认配置。然后点击<下一步>。

图4-7 指定主服务

 

 

(7)     进入[分配Slave和Client]页面，可以自定义分配从节点和客户端，也可接受默认配置。然后点击<下一步>。

图4-8 分配从节点和客户端

 

 

(8)     进入[定制服务]页面，可以按照规划调整服务的配置参数、设置服务认证相关的密码，也可接受默认配置。然后点击<下一步>。

图4-9 定制服务

 

 

(9)     进入[检查]页面，需要进行HDP集群部署前的最后检查，确认无误后点击<部署>按钮开始部署。

图4-10 检查信息

 

(10)     进入[安装、启动和测试]页面，安装过程中会显示每个节点每项服务安装的详细进度，如图4-11所示，点击各节点上的消息可以查看安装详情。待安装结束后，点击<下一步>。

图4-11 服务安装

 

(11)     进入[概要]页面可查看安装结果和详情，点击<完成>按钮即可进入DataEngine Manager的主页。

4.2  部署MPP1集群

部署MPP1集群的操作步骤如下：

(1)     进入[开始]页面，输入集群名称后，点击<下一步>。

图4-12 集群名称

 

(2)     进入[选择版本]页面，可以展开高级选项查看安装rpm源地址。然后点击<下一步>。

图4-13 选择版本

 

(3)     进入[安装选项]页面，输入集群各节点主机名（本文以部署3节点的MPP1集群示例），默认自动填充。然后，点击<注册并确认>。

图4-14 输入集群各节点主机名

 

(4)     进入[确认主机]页面，等待DataEngine对所有节点进行注册并检查，如图4-15所示，所有注册的主机检查通过后，点击<下一步>。

图4-15 确认主机

 

(5)     进入[选择服务]页面，选择安装MPP1服务，默认勾选Metrics服务。然后点击<下一步>。

图4-16 选择服务

 

(6)     进入[分配Master服务]页面，可以在下拉框中为已勾选服务的组件选择对应部署节点，也可接受默认配置。然后点击<下一步>。

 

图4-17 指定主服务

 

(7)     进入[分配Slave和Client]页面，可以自定义分配MPP1的Client（此时Client指MPP1 Segment，即MPP1服务的数据节点），也可接受默认配置。然后点击<下一步>。

 

图4-18 分配从节点和客户端

 

(8)     进入[定制服务]页面，此时需要根据集群实际情况，手动修改以下配置项：

 

¡     mpp1.instances.per.node配置项，用来配置每台数据节点服务器上运行的实例个数，该参数必须根据具体的物理服务器配置综合考虑。因为目前服务器硬件资源较大，所以此配置项可主要根据服务器的内存大小来决定，实例个数要求为偶数，且最大不能超过8个。参考配置值如表4-1所示。

表4-1 服务器内存与mpp1.instances.per.node配置项的推荐对应关系

服务器内存大小	单个节点配置实例数量（个）
128G	4
256G	6
512G	8

 

¡     mpp1.virtual.ip配置项，用来配置访问MPP1数据库的虚拟IP。该IP要求必须与DataEngine Manager安装节点的IP处于同一网段，且未被占用，否则点击<下一步>时会报错。

 

图4-19 DataEngine  Manager安装节点IP信息查看

 

¡     配置项Super user passwd，用于设置操作系统用户gpadmin的密码，缺省密码为h3cDataEngine。

图4-20 定制服务

 

 

(9)     进入[检查]页面，需要进行MPP1集群部署前的最后检查，确认无误后点击<部署>按钮开始部署。

图4-21 检查信息

 

(10)     进入[安装、启动和测试]页面，安装过程中会显示每个节点每项服务安装的详细进度，如图4-22所示，点击各节点上的消息可以查看安装详情。待安装结束后，点击<下一步>。

图4-22 服务安装

 

(11)     进入[概要]页面可查看安装结果和详情，点击<完成>按钮即可进入DataEngine Manager的主页。

 

5 客户端配置

 

5.1  添加浏览器安全证书

如果浏览器中以前没有导入过DataEngine证书或需要更新DataEngine证书时，均需要获取最新的证书。

以FireFox浏览器为例，添加安全证书的步骤如下：

(1)     在浏览器中输入DataEngine Manager访问地址，如图5-1所示，弹出“连接不安全”提示。此时，点击<高级>按钮，展示详情信息后点击<添加例外…>按钮。

图5-1 浏览器访问不安全提示

 

(2)     弹出<添加例外…>的对话框，如图5-2所示，然后点击<查看>按钮。

图5-2 添加安全例外

 

(3)     点击<查看>按钮后，出现证书的详情界面。如图5-3所示，在详细信息页面的证书结构中，选择H3C DataEngine，然后点击<导出>按钮，将证书保存至本地，供稍后安装时使用。

图5-3 查看证书详细信息

 

(4)     DataEngine最新证书获取成功后，进入浏览器[菜单/选项/高级/证书/查看证书/证书机构]页面。点击<导入>按钮，选择步骤3中获取的DataEngine最新证书。

 

图5-4 浏览器证书机构

 

(5)     在本地选择DataEngine最新证书并打开，弹出如图5-5所示对话框。此时，勾选所有信任项，点击<查看>按钮，检查证书机构中的证书是否导入成功。若导入成功，则点击<确定>按钮。

图5-5 完成证书导入

 

5.2  修改本地hosts文件

DataEngine安装完成后，需要修改集群本地hosts文件，用以确保点击DataEngine Manager管理界面中的各页面时，用域名访问能够顺利跳转。修改集群本地hosts文件的方法如下：

(1)     登录DataEngine集群中任意一节点，查看当前集群的hosts文件（如果集群是CentOS系统，则位置为/etc/hosts）。

图5-6 查看DataEngine集群hosts文件

 

(2)     将图5-6中的集群节点信息添加到本地hosts文件中。若本地电脑是Windows 7.x版本，则hosts文件位于C:\Windows\System32\drivers\etc\hosts，修改该hosts文件并保存。

 

6 访问集群主页

6.1  安装后检查

DataEngine集群部署完成后，参考3.3  访问DataEngine Manager，以系统管理员（admin）身份登录DataEngine Manager，进行主机管理检查、服务组件检查、以及健康检查，以确保集群状态正常。

6.1.1  主机管理检查

点击DataEngine Manager顶部导航栏中的[主机]，进入主机列表页面，可以检查集群中各主机健康状况，检查范围包括：

·     检查部署的DataEngine集群中所有节点是否都在主机列表中

·     检查所有主机状态是否都正常

·     点击主机名进入，可查看各主机上的具体服务组件状况，当出现异常时可选择重启等操作

图6-1 主机健康状况

 

表6-1 主机健康状态说明

健康状态	说明	处理方法
/	正常/告警	/
/	Master/Slave组件停止服务	重启组件
/	心跳丢失/重新启动	登录到主机节点上查看主机是否存在宕机；如果没有，需要查看ambari-agent的状态，若有异常可以尝试重启ambari-agent；如果依然无法恢复，请联系H3C 技术支持工程师

 

6.1.2  服务组件检查

点击DataEngine Manager顶部导航栏中[服务]，在其下拉菜单中，可以查看集群中已安装的各服务健康状况。

图6-2 服务健康状况

 

 

表6-2 服务健康状态说明

健康状态	说明	处理方法
/	正常/告警	/
/	Master/Slave组件停止服务	重启组件
/	心跳丢失/重新启动	登录到主机节点上查看主机是否存在宕机；如果没有，需要查看ambari-agent的状态，若有异常可以尝试重启ambari-agent。如果依然无法恢复，请联系H3C 技术支持工程师
	只有客户端的服务	/

 

6.1.3  健康检查

在DataEngine Manager顶部导航栏中[系统管理]的下拉菜单，选择[健康检查]进入，在即时检查栏中选择需要检查的主机和服务组件，点击<开始执行>执行健康检查，用于检查集群中已安装的各服务的基本功能。如图6-3所示，待检查结束后，通过检查结果获取主机和服务的健康状态，且可以查看检查详情或者下载检查报告。

图6-3 健康检查

 

6.2  是否开启安全模式

DataEngine集群的使用状态包括安全模式和非安全模式。DataEngine集群部署完成后，以系统管理员身份登录DataEngine Manager，可选择是否开启安全模式。

 

6.2.1  安全模式

1. 启动安全模式

为DataEngine集群开启安全模式的步骤如下：

(1)     在DataEngine Manager顶部导航栏中[系统管理]的下拉菜单，选择[Kerberos]进入，点击<启用Kerberos>按钮，在提示框点击<继续>进入启用Kerberos向导。

(2)     进入[开始]页面，选择使用哪种KDC。缺省选择“已有的MIT KDC”，建议不修改，勾选所有检查项后，点击<下一步>。

图6-4 开始

 

(3)     进入[配置Kerberos]页面，参数值不可修改，使用默认值。点击<测试KDC连接>按钮可测试KDC相关配置是否正确，其中KDC host和Kadmin host为DataEngine Manager虚拟IP。测试成功后点击<下一步>。

 

图6-5 配置Kerberos

 

(4)     进入[安装并测试Kerberos Client]页面，安装成功后点击<下一步>。

图6-6 安装并测试Kerberos Client

 

(5)     进入[配置身份]页面，参数值不可修改，使用默认值。点击<下一步>。

图6-7 配置身份

 

(6)     进入[确认配置]页面，检查配置文件。在此步骤可下载CSV，查看DataEngine Manager自动创建的主体和密钥列表（待Kerberos启动以后，可登录集群在/etc/security/keytabs路径下查看DataEngine Manager自动创建的主体和密钥的相关信息）。检查完成后，点击<下一步>。

图6-8 确认配置

 

(7)     进入[停止服务]页面，服务成功停止后，点击<下一步>。

图6-9 停止服务

 

(8)     进入[Kerberize集群]页面，此过程中会完成创建Keytab、分发Keytab、更新配置等操作，待Kerberos成功启动后，点击<下一步>。

图6-10 Kerberize集群

 

(9)     进入[开启并测试服务]页面，此过程中会开启服务并测试服务是否可用，测试成功后点击<完成>。

 

2. 安全模式下的操作变更

DataEngine集群处于安全模式下时，某些操作会发生变更，主要包括以下方面：

·     服务的操作变更

普通用户（示例user01用户）连接集群使用服务时，需要申请Kerberos票据，步骤如下：

a.     使用安全管理员（security）登录DataEngine Manager创建普通用户user01。

b.     登录集群，进入/etc/security/keytabs路径下为用户user01生成秘钥，命令如下：

cd /etc/security/keytabs

kadmin.local

ktadd -k user01.keytab user01

图6-11 为用户user01生成秘钥

 

c.     修改user01.keytab文件所有者为user01，命令如下：

chown user01 user01.keytab

图6-12 修改user01.keytab文件所有者为user01

 

d.     为用户user01获取票据，获取成功后用户user01即可正常连接集群并使用服务。示例：通过用户user01访问HDFS服务，命令如下：

su user01

kinit -kt /etc/security/keytabs/user01.keytab user01

图6-13 使用user01访问HDFS服务

 

 

·     DataEngine Manager操作变更

在安全模式下，通过DataEngine Manager执行某些操作时，操作方式可能会发生变更，示例如下：

¡     服务安装：在安全模式下，服务安装过程中会出现提示，需要输入管理员认证主体和管理员密码（管理员认证主体：admin/[email protected]，管理员密码：Admin@123），然后继续执行即可。

¡     主机扩容：在安全模式下，主机安装过程中会出现提示，需要输入管理员认证主体和管理员密码（管理员认证主体：admin/[email protected]，管理员密码：Admin@123），然后继续执行即可。

 

6.2.2  非安全模式

除6.2.1  2. 安全模式下的操作变更章节列出的操作变更之外，DataEngine集群在安全模式和非安全模式下关于服务的操作和DataEngine Manager的操作完全相同。

7 DataEngine的License配置

7.1  软件注册

DataEngine安装完成后，可在180天内试用所有功能，超过试用期限后，需要获取License授权才能正常使用。

DataEngine的注册流程如图7-1所示。

图7-1 软件注册流程

 

 

1. 获取设备信息文件

登录License Server，单击[License/安装]菜单项，在该页面点击<导出DID>按钮获取License Server的设备信息文件。

2. 申请License文件

获取到设备信息文件后，使用该文件和授权码生成激活文件，然后在License Server上安装激活文件。请登录H3C中文网站获取License激活文件：

·     如果是首次申请License文件，具体步骤请查看“(1)License首次激活申请”。

·     如果此前已申请过License文件，又需要对License进行扩容，具体步骤请查看“(2)License扩容激活申请”。

申请License文件分为以下两种情况：

(1)     License首次激活申请

a.     访问网址http://www.h3c.com/cn/License，进入“License首次激活申请”页面。

b.     在“产品分类”中选择产品对应的类型（示例：大数据_DataEngine HDP）。

c.     请按照表7-1的说明，在页面上填写相关信息。

表7-1 相关信息说明

项目	说明
授权信息	请填写授权信息，请直接输入授权码
设备信息	请上传此前获取到的设备信息文件
用户信息	请填写您的用户信息，其中带“*”的项目必填

 

d.     请输入验证码并勾选“已阅读并同意法律声明所述服务条款各项内容”，再点击<获取激活码（文件）>按钮，请将生成的License文件保存到本地PC待用。

(2)     License扩容激活申请

a.     访问网址http://www.h3c.com/cn/License，点击“License扩容激活申请”，进入“License扩容激活申请”页面。

b.     在“产品分类”中选择产品对应的类型（示例：大数据_DataEngine HDP）。

c.     请按照表7-2的说明，在页面上填写相关信息。

表7-2 相关信息说明

项目	说明
设备信息	请上传此前获取到的设备信息文件
授权信息	请填写授权信息，直接输入授权码
用户信息	请填写您的用户信息，其中带“*”的项目必填

 

d.     请输入验证码并勾选“已阅读并同意法律声明所述服务条款各项内容”，再点击<获取激活码（文件）>按钮，请将生成的License文件保存到本地PC待用。

3. 获取License授权

获取授权的具体步骤如下：

(1)     登录License Server，点击[License/安装]菜单项，进入激活文件管理页面。单击<安装激活文件>按钮，在弹出的对话框中单击<浏览>按钮，选择保存在本地的License文件，然后单击<确定>按钮上传选中的License文件。上传成功后在激活文件管理页面会显示获取的授权信息。

(2)     在License Server上，单击[配置/客户端]菜单项，进入配置客户端页面，单击<增加客户端>按钮，填写客户端名称、客户端密码等信息，单击<确定>按钮后完成客户端的创建。

(3)     登录DataEngine Manager管理界面配置License，详情请参见7.2  在DataEngine Manager中配置License。

7.2  在DataEngine Manager中配置License

DataEngine成功连接到License Server的客户端后，DataEngine可以向License Server请求授权并将请求结果展示在页面上。

在H3C DataEngine Manager顶部导航栏[系统管理]的下拉框中选择<License管理>，进入License管理页面，如图7-2所示，License管理页面左侧显示“License配置”，页面右侧显示“License状态”，下面对这两部分进行详细介绍。

图7-2 License管理

 

1. License配置

License配置栏显示连接的License Server 客户端的配置信息，DataEngine通过这些配置信息连接到对应的License Server客户端。

点击License配置右上方<编辑>按钮，用户可编辑License配置信息。填写所要连接的License Server客户端的用户名、密码、IP地址（License Server客户端所在主机的IP地址）和端口（License Server的服务端口号，默认为“5555”）后，点击<保存>，即可连接到相应客户端自动获取授权信息。

 

2. License状态

License状态显示当前的集群已安装及已获取授权的主机情况。

·     安装主机数：指集群中已安装的主机总数。

·     授权主机数：指DataEngine已从License Server获取授权的主机个数。

 

8 卸载

 

8.1  卸载服务

对于服务卸载，分为单服务整体卸载和单服务单组件卸载两种方式。如果服务本身包含服务端，在卸载之前需要先停止服务；如果服务全为客户端，则可以直接卸载。例如卸载HBase服务需要先停止服务，而卸载Tez客户端则可直接卸载。

 

8.1.1  单服务整体卸载

单服务整体卸载指针对某个服务的完整卸载，包括卸载此服务在所有节点上的组件。

 

下面以HBase举例，说明单服务整体卸载的方法。

(1)     在DataEngine Manager顶部导航栏中[服务]的下拉菜单，选择[HBase]进入。

(2)     在HBase服务页面右上角的[服务操作]下拉菜单中选择<停止>。根据需要在弹出的确认框中可以选择是否为HBase开启维护模式。

(3)     待服务停止操作完成后，在[服务操作]下拉菜单中选择<卸载HBASE>，弹出卸载服务向导，如图8-1所示。卸载向导分为以下三个步骤：

a.     卸载概要，提示执行卸载操作的用户、执行卸载操作所在集群名称、待卸载的服务名称。

b.     确认卸载，卸载操作不可逆，提示输入delete进行卸载确认。

c.     卸载进度，显示卸载过程的整体进度。执行结束后，点击<完成>按钮，关闭卸载向导。

图8-1 卸载服务向导

 

8.1.2  单服务单组件卸载

单服务单组件卸载指针对某个服务的某个组件的卸载，目前DataEngine Manager尚未支持所有服务的单组件卸载，如果某组件的操作中包含删除选项即认为是支持，否则不支持，具体请以实际界面为准。下面以卸载Storm服务的Supervisor组件举例，说明单服务单组件卸载的方法。

(1)     在DataEngine Manager顶部导航栏中[服务]的下拉菜单，选择[Storm]进入。

(2)     在Storm服务的概要页面，点击Supervisor（监管者）的链接，进入某主机上的服务列表。

(3)     在服务列表找到Supervisor组件，在组件的对应操作下拉框中先点击<停止>，停止成功后点击<删除>即可完成Supervisor组件的卸载，如图8-2所示。

图8-2 Storm的Supervisor组件卸载

 

8.1.3  服务强制卸载

对处于异常状态下的服务，可以进行强制卸载。下面以HBase举例，说明服务强制卸载的方法。

(1)     关闭HBase中处于启动状态的组件（若待卸载的异常服务中所有组件都处于异常或停止状态，跳过此步骤）

a.     在DataEngine Manager顶部导航栏中[服务]的下拉菜单，选择[HBase]进入。

b.     在HBase服务页面的概要栏查看HBase服务组件的状态。点击处于正常启动状态的组件名称进入对应主机，在主机的组件列表中找到该组件后点击<停止>。

c.     依照上述步骤，手动停止待卸载的异常服务HBase所有处于正常启动状态的组件。

(2)     执行完上述步骤以后，对异常服务进行强制卸载。

a.     在DataEngine Manager顶部导航栏中[服务]的下拉菜单，选择[HBase]进入。

b.     在HBase服务页面右上角的[服务操作]下拉菜单中选择“卸载HBase”，弹出卸载服务向导。卸载向导分为以下三个步骤：

-     卸载概要，强制卸载时需要点击<执行脚本>按钮，执行强制卸载脚本，如图8-3所示。同时页面会提示执行卸载操作的用户、执行卸载操作所在集群名称、待卸载的服务名称。

-     确认卸载，卸载操作不可逆，提示输入delete进行卸载确认。

-     卸载进度，显示卸载过程的整体进度。执行结束后，点击<完成>按钮，关闭卸载向导。

图8-3 强制卸载服务向导

 

8.2  卸载集群

 

对于集群卸载，卸载过程会对整体DataEngine Manager管理界面和DataEngine集群进行全部卸载。卸载步骤如下：

(1)     登录DataEngine集群主管理节点，在安装路径下，执行以下命令：

./uninstall.sh

 

(2)     卸载成功后，恢复到集群安装前的状态，此时在解压文件夹下执行./install.sh即可重新启动安装。

 

9 DataEngine扩展包的使用

 

安装DataEngine扩展包的步骤如下：

 

(1)     上传并解压DataEngine扩展安装包（必须在两个管理节点上分别执行）

分别登录DataEngine集群的两个管理节点（即有ambari-server进程的节点），上传DataEngine扩展安装包至/opt目录下（推荐使用/opt目录，若使用其他目录可能会导致安装失败），解压安装包，命令如下：

tar xvzf DataEngine-<version>-Extra.tar.gz

解压完成后，当前目录/opt中出现DataEngine-<version>-Extra文件夹。

(2)     将解压目录中的服务包拷贝到/var/lib/ambari-server/resources/common-services目录下（必须在两个管理节点上分别执行）

a.     单独拷贝一个服务，命令如下：

cp -r /opt/DataEngine-<version>-Extra/服务名 /var/lib/ambari-server/resources/common-services

b.     拷贝所有服务，命令如下：

cp -r /opt/DataEngine-<version>-Extra/* /var/lib/ambari-server/resources/common-services

(3)     注册服务（必须在两个管理节点上分别执行）

a.     注册所有服务，命令（非root用户下需要在命令前添加sudo）如下：

service-register -a

b.     单独注册一个服务，命令（非root用户下需要在命令前添加sudo）如下：

service-register 服务名 服务版本号

(4)     重启ambari-server（任选一个管理节点上执行即可），命令（非root用户下需要在命令前添加sudo）如下：

crm resource restart master-server

(5)     查看已注册的服务是否在DataEngine集群的添加服务列表中。关于扩展服务安装的方式与DataEngine基础服务相同，详情请参见《H3C DataEngine Manager用户手册》。

10 常见问题解答

1. DataEngine集群安装包中的服务规划

表10-1 DataEngine集群（E0107）安装包中的服务

服务名	版本号
DataEngine安装包（基础包）
HDFS	2.7.1
MapReduce2	2.7.1
YARN	2.7.1
ZooKeeper	3.4.6
Metrics	0.1.0
Tez	0.7.0
Hive	1.2.1
Hive2	2.3.0
HBase	1.1.2
Sqoop	1.4.6
Oozie	4.2.0
Storm	1.1.1
Flume	1.8.0
Flink	1.6.0
ElasticSearch5	5.4.1
HBase_Indexer	3.0.0
Kafka	0.10.1.2
Kerberos	1.10.3.10
PostgreSQL	9.4.5（CentOS 6.X）、9.4.11（CentOS 7.X）
Redis	3.2.2
Solr	6.6.1
Spark2	2.1.2
Log Manager	0.5.0
Infra Solr	0.1.0
Sparrow	1.0.0
MPP1	5.0.0
DataEngine安装包（扩展包）
Janusgraph	0.2.0
Neo4J	3.3.4
ElasticSearch	2.4.1
Spark	1.6.3
HUE	4.1.0
MPP2	9.1.1

 

2. DataEngine集群中的非管理节点发生故障后，如何重新加入？

当非管理节点出现不可修复故障时，为不影响原集群的运行，可将相同操作系统和IP的新节点重新添加进原集群，步骤如下：

(1)     检查集群节点的相关信息，包括：

a.     确认集群管理节点所有功能正常可用，包括：ambari-server、对应数据库功能、软件源功能、http服务器中共享文件可用性等。

b.     确认故障节点状态信息处于心跳丢失状态（原故障节点已隔离，新节点未接入集群建立心跳）。

c.     确认新添加进集群的节点（故障节点的替换节点）的操作系统、IP等严格与故障节点保持一致，且干净未安装任何冲突软件、未进行配置设置且网络功能正常。

(2)     若检查集群节点状态均满足要求，可启动安装，步骤如下：

a.     登录集群当前可用的管理节点，进入安装路径下，执行以下命令：

./install_agent.sh install <节点IP> <用户名> <密码>

其中：节点IP为新添加节点的IP，用户名为新添加节点的主机用户名（与原集群用户保持一致），密码为用户密码。

b.     新节点安装完成后，登录DataEngine Manager管理界面，查看该节点对应的心跳状态是否恢复正常，如已恢复，说明新节点添加成功。

 

3. DataEngine集群的管理节点有一个发生故障后，如何重新添加一个?

当集群管理节点有一个出现不可修复故障时，为不影响原集群管理节点的高可靠，可重新添加一个新节点启动DataEngine Manager HA，步骤如下：

(1)     选取一个新节点作为管理节点的备用节点，管理节点的主节点（Master）与备用节点（Standby）选取策略、磁盘方案、操作系统等均完全相同。

(2)     重新启动DataEngine Manager HA，步骤如下：

a.     登录集群当前可用的管理节点，进入安装路径下，执行如下命令：

./HA.sh init_ha <masterIP> <slaveIP> <virtualIP> <username> <password>

其中：masterIP为当前集群管理节点IP，slaveIP为新添加管理节点的备用节点IP，virtualIP为集群部署时规划的入口IP，username为集群主机用户名，password为集群主机用户名密码。

b.     DataEngine Manager HA启动完成后，请参见3.2.1  查看DataEngine Manager HA状态章节进行检查。

4. DataEngine Manager HA状态不正常处理方法

对于Manager HA的维护，建议定期检查Manager HA状态以及DataEngine Manager管理界面关于Manager HA备用节点的告警信息。当状态信息中出现Stopped、Failed Action、pgsql data status is not healthy或DataEngine Manager管理界面出现Manager HA备用节点的告警信息时，表示Manager HA状态不正常（不正常判断条件：第一次查看时不正常，间隔2-3分钟再次查看时仍然不正常），此时务必及时进行处理，处理方法主要分为以下两种情况：

(1)     对于能正常访问DataEngine Manager管理界面，但提示备用节点PostgreSQL数据库告警（比如：提示“DataEngine Server HA standby alert”告警）的情况，处理方法如下：

a.     首先根据实际情况修复备用节点出现的故障，例如关机、网络故障等。

b.     当备用节点可以正常启动且网络正常时，检查Manager HA状态，查看pingCheck状态是否异常。如有异常，请先执行crm resource cleanup pingCheck（非root用户下需要在命令前添加sudo），然后再查看pingCheck状态，如仍然异常请检查当前的网络是否正常。

c.     在备用节点上运行修复脚本/.hde/cls_rebuild_slave.sh masterIP（非root用户下需要在命令前添加sudo）重新建立PostgreSQL主从流复制基础备份，其中masterIP为Manager当前主节点IP地址。然后检查Manager HA状态，查看PostgreSQL是否修复。如果没有修复，请检查PostgreSQL日志，最后查看master-server、tomcat、master-kadmin或master-krb5kdc等状态是否异常，如果异常请执行crm resource cleanup {资源名字}（非root用户下需要在命令前添加sudo）。

(2)     对于不能正常登录Manager的情况（主备节点都发生故障），处理方法如下：

a.     首先根据实际情况修复主备节点出现的故障，例如关机、网络故障等。

b.     当主备节点都可以正常启动且网络正常时，然后检查Manager HA状态是否正常，如果不正常，请根据实际情况，按照以下内容操作：

首先检查pingCheck资源是否异常，如有异常，请执行crm resource cleanup pingCheck（非root用户下需要在命令前添加sudo）后再次查看pingCheck状态，如仍然异常请检查当前的网络是否正常。

然后检查PostgreSQL的状态，如有异常，主要分为以下三种情况：

-     第一种情况：PostgreSQL数据库的master和slave都处于Stopped状态，请先确认主从节点上/var/lib/pgsql/tmp/PGSQL.lock文件是否删除，如果没有请先删除。然后请执行crm resource cleanup pgsql（非root用户下需要在命令前添加sudo），等待3-5分钟，再次查看PostgreSQL当前状态，根据当前状态再进行后续处理。

-     第二种情况：PostgreSQL数据库的slave处于停止状态或者提示PostgreSQL数据状态不健康，master处于正常状态时，此时请在备节点上运行修复脚本/.hde/cls_rebuild_slave.sh masterIP（非root用户下需要在命令前添加sudo）重新建立PostgreSQL主从流复制基础备份，其中masterIP为Manager当前主节点IP地址。

-     第三种情况：PostgreSQL数据库没有master节点，请执行crm resource cleanup pgsql（非root用户下需要在命令前添加sudo），等待3-5分钟，再次查看PostgreSQL当前状态，根据当前状态再进行后续处理。

最后检查master-server、tomcat、master-kadmin和master-krb5kdc等的状态，如有异常，请执行crm resource cleanup {资源名字}（非root用户下需要在命令前添加sudo）。

c.     当只有一个主机可以正常启动且网络正常时，处理方法如下：

首先检查pingCheck资源是否异常，如有异常，请执行crm resource cleanup pingCheck（非root用户下需要在命令前添加sudo）后再次查看pingCheck状态，如仍然异常请检查当前的网络是否正常。

然后检查当前Manager可用节点的PostgreSQL状态是否是master，若不是请将其设置为master，执行crm resource cleanup pgsql（非root用户下需要在命令前添加sudo）后等待3-5分钟，再次查看PostgreSQL当前状态，若无法通过上述方式将其设置为master，可执行以下命令将其强制提升为master，命令如下（非root用户下需要在下述命令前添加sudo）：

crm resource stop pgsql

crm_attribute -l forever -N [当前可用节点主机名] -n "pgsql-data-status" -D

crm_attribute -l forever -N [不可用节点主机名] -n "pgsql-data-status" -D

crm_attribute --type crm_config --name pgsql_REPL_INFO -s pgsql_replication –D

crm resource start pgsql

最后检查master-server、tomcat、master-kadmin和master-krb5kdc等的状态，如有异常，请执行crm resource cleanup {资源名字}（非root用户下需要在命令前添加sudo）。

 

5. 根据现场磁盘分区方案和挂盘方案的不同，或管理节点（Manager节点）是否单独为PostgreSQL（内置）划分了分区，在数据节点上安装服务时，可能受影响的服务以及各服务必须检查的配置项有哪些？

根据现场磁盘分区方案和挂盘方案的不同，或若管理节点（Manager节点）单独为PostgreSQL（内置）划分了分区时，在添加服务向导的定制服务步骤，必须按照表10-2所示要求进行检查，否则服务可能会安装失败或使用异常。

表10-2 安装服务时需要检查的配置项

服务	是否需要检查	被影响的配置项	如何解决
HDFS	是（配置项的参数值默认使用全部挂载路径）	NameNode directories	此目录为数据目录，检查此配置项的值时，需关注： ·     不允许存在非数据目录 ·     若现场数据目录是自定义的，则需要配置为对应的数据目录
		DataNode directories
	是（配置项的参数值默认使用某一个挂载路径）	JournalNode Edits directory	此目录为数据目录，检查此配置项的值时，需关注： ·     不允许存在非数据目录 ·     若现场数据目录是自定义的，则需要配置为对应的数据目录
YARN	是（配置项的参数值默认使用全部挂载路径）	yarn.nodemanager.local-dirs	此目录为数据目录，用于存放应用程序的运行依赖包等信息。检查此配置项的值时，需关注： ·     不允许存在非数据目录 ·     若现场数据目录是自定义的，则需要配置为对应的数据目录
		yarn.nodemanager.log-dirs
	是（配置项的参数值默认使用某一个挂载路径）	yarn.timeline-service.levelldb-timeline-store.path	此目录为数据目录，用于记录应用程序运行状态等信息。检查此配置项的值时，需关注： ·     不允许存在非数据目录 ·     若现场数据目录是自定义的，则需要配置为对应的数据目录
		yarn.timeline-service.leveldb-state.path
Kafka	是（配置项的参数值默认使用全部挂载路径）	log.dir	此目录为数据目录，检查此配置项的值时，需关注： ·     不允许存在非数据目录 ·     若现场数据目录是自定义的，则需要配置为对应的数据目录
ElasticSearch	是（配置项的参数值默认使用全部挂载路径）	es.path.data	此目录为数据目录，检查此配置项的值时，需关注： ·     不允许存在非数据目录 ·     若现场数据目录是自定义的，则需要配置为对应的数据目录
ElasticSearch5	是（配置项的参数值默认使用全部挂载路径）	es.path.data	此目录为数据目录，检查此配置项的值时，需关注： ·     不允许存在非数据目录 ·     若现场数据目录是自定义的，则需要配置为对应的数据目录
Zookeeper	是（配置项的参数值默认使用某一个挂载路径）	ZooKeeper directory	此目录为数据目录，检查此配置项的值时，需关注： ·     不允许存在非数据目录 ·     若现场数据目录是自定义的，则需要配置为对应的数据目录
Storm	是（配置项的参数值默认使用某一个挂载路径）	storm.local.dir	此目录为Storm使用的本地文件系统目录，用于保存少量状态信息。检查此配置项的值时，需关注： ·     不允许存在非数据目录 ·     若现场数据目录是自定义的，则需要配置为对应的数据目录 ·     建议此目录为Storm服务独立使用。如果该目录同时被其他服务使用，需手动修改为其他路径
Solr	是（配置项的参数值默认使用某一个挂载路径）	solr.datadir	此目录为数据目录，检查此配置项的值时，需关注： ·     不允许存在非数据目录 ·     若现场数据目录是自定义的，则需要配置为对应的数据目录
Redis	是（配置项的参数值默认使用某一个挂载路径）	redis.dir	此目录为数据目录，检查此配置项的值时，需关注： ·     不允许存在非数据目录 ·     若现场数据目录是自定义的，则需要配置为对应的数据目录
Oozie	是（配置项的参数值默认使用某一个挂载路径）	Oozie Data Dir	此目录为数据目录，检查此配置项的值时，需关注： ·     不允许存在非数据目录 ·     若现场数据目录是自定义的，则需要配置为对应的数据目录
Infra Solr	是（配置项的参数值默认使用某一个挂载路径）	Infra Solr data dir	此目录为数据目录，检查此配置项的值时，需关注： ·     不允许存在非数据目录 ·     若现场数据目录是自定义的，则需要配置为对应的数据目录

 

6. 为DataEngine集群开启安全模式（启用Kerberos）失败，报警“DataEngine Agent NTP Service Status”，如何解决？

DataEngine集群中各节点时间不同步时，可能会导致启用Kerberos失败，此时需要手动进行时间同步后，再次启用Kerberos。设置DataEngine集群时间同步的方法如下：

(1)     查看告警“DataEngine Agent NTP Service Status”，查找告警时间不同步的节点。

(2)     登录出现告警的节点，设置此节点时间与集群管理节点同步，命令如下：

ntpdate -u <masternodeIP>

hwclock –systohc

其中：masternodeIP为DataEngine集群主管理节点IP。

7. 如何修改HDP集群的主机IP地址？

HDP集群部署完成后，若因机房迁移等原因网络发生变化时，可以修改集群中各主机的IP地址。

 

HDP集群中各主机节点IP修改步骤如下：

(1)     通过服务器root用户/密码分别登录集群中待修改IP的各节点，在各节点上均执行以下操作：

a.     进入/etc/sysconfig/network-scripts/目录下，打开对应文件（一般为ifcfg-eth0，请以服务器实际网卡配置为准），修改节点IP地址。如图10-1所示，将ipaddr的参数值修改为待更换的目标IP地址。

图10-1 修改节点IP

 

b.     保存修改后，重启网络服务，命令如下：

service network restart

c.     重启修改IP的节点，使其上的服务处于异常状态。

 

(2)     通过服务器root用户/密码登录集群Manager管理节点（若管理节点IP修改了，请使用修改后的IP登录管理节点），进入/opt/DataEngine-<version>-Basic目录下，依次执行以下操作：

a.     进入/conf文件夹，修改配置文件change_ips.conf。如图10-2所示，修改IP格式为“源IP地址，目标IP地址”。

图10-2 修改配置文件change_ips.conf

 

b.     保存修改后，运行IP修改脚本，命令如下：

./ change_ips.sh

【说明】IP修改脚本运行时，根据提示需要输入Local IP（指当前主管理节点IP），脚本运行结束后，修改IP的节点上的所有服务将自动恢复至正常状态。

 

8. Redis安装单机版和集群版

·     如果只选择了一个节点安装Redis，则为单机模式。

·     如果选择了3个或3个以上节点安装Redis，则为集群模式。

 

9. 查看服务的日志信息

表10-3 服务日志路径说明

服务	日志路径
HDFS	/var/log/hadoop/hdfs
MapReduce2	/var/log/hadoop-mapreduce/mapred
YARN	/var/log/hadoop-yarn/yarn 【说明】：上述的日志是YARN服务本身的日志。而执行在YARN上的应用日志可以通过YARN的UI界面查看，日志文件实际存储位置默认是在HDFS服务上， 默认路径是/app-logs。 如果日志不聚合，可以配置yarn.log-aggregation.enabled为false
Spark2	/var/log/spark2
Storm	/var/log/storm
Hive	/var/log/hive
Hive2	/var/log/hive2
HBase	/var/log/hbase
Hbase Indexer	/var/log/hbase-indexer
Solr	/var/log/solr/solr.log
ElasticSearch5	/var/log/elasticsearch5
Kafka	/var/log/kafka
Flume	/var/log/flume
ZooKeeper	/var/log/zookeeper
Sparrow	/var/log/sparrow
Flink	·     服务日志路径为/var/log/flink ·     业务日志需要通过YARN的UI界面查看
Sqoop	/var/log/sqoop
Infra Solr	/var/log/infra-solr
Metrics	/var/log//ambari-metrics-monitor
Oozie	/var/log/oozie
Kerberos	/var/log/krb5kdc.log /var/log/kadmin.log
PostgreSQL`	/var/lib/pgsql/9.4/initdb.log
MPP1	/opt/MPP1/disk*/master(slave)/gpseg-*/pg_log
Redis	/var/log/redis/redis_（端口号）.log
Tez	/var/log/tez
Log Manager	/var/log/ambari-logsearch-logfeeder、/var/log/ambari-logsearch-portal
ElasticSearch	/var/log/elasticsearch
Spark	/var/log/spark
MPP	/var/log/mpp-monitor
Neo4J	/var/log/neo4j
Janusgraph	/var/log/janusgraph
HUE	/usr/local/hue/logs
MPP2	·     安装Vertica日志路径为/opt/vertica/log/install.log ·     安装/操作数据库的日志路径为/opt/vertica/log/adminTools.log ·     启动过程日志信息路径为/opt/vertica/data/H3C_Database/dbLog ·     启动之后服务进程相关日志信息路径为/opt/vertica/data/H3C_Database/v_h3c_database_node000x_catalog/vertica.log ·     用户自定义函数相关的日志信息路径为/opt/vertica/data/H3C_Database/v_h3c_database_node000x_catalog/UDxLogs/ （其中v_h3c_database_node000x_catalog中的x表示第几个节点，比如第一个节点就是v_h3c_database_node0001_catalog）

 

10. DataEngine Manager安装后无法访问的可能原因和排查方法

可能原因及解决方法：

(1)     登录DataEngine管理节点运行./HA.sh status查看HA状态。若为Tomcat服务没有正常启动，此时执行crm resource cleanup tomcat（非root用户下需要在命令前添加sudo）重新启动tomcat，如果依然不成功则需要查看日志（日志/var/log/tomcat/ catalina.log为tomcat的服务启动日志），如果其它资源状态不正常，请参见10 4. DataEngine Manager HA状态不正常处理方法进行处理。

(2)     检查是否有授权证书。

(3)     检查确保访问方式是https。

(4)     检查确保https的8443端口没有被防火墙阻止。

(5)     检查是否有OpenJDK版本的变化。

11. 页面上各项指标显示的比较慢的可能原因和排查方法

(1)     可能原因

Metrics服务部分采集信息是存储在内置的PostgreSQL中，所以当集群与PostgreSQL的配置不匹配时，会造成Metrics服务获取集群信息时阻塞，此时内置PostgreSQL需要根据集群进行优化。

(2)     解决方法

修改配置文件/var/lib/pgsql/9.4/data/postgresql.conf，推荐优化配置如表10-4所示。

表10-4 配置优化方案

配置项	优化说明
max_connections	默认值100偏小，例如：以500台集群估算，建议增加至500个最大连接
fsync	为保证数据安全性，需要设置为true，但这在一定程度上会降低I/O性能
shared_buffers	生产环境内存一般比较大，该参数可以适当增大，建议该参数配置为1G 【注意】：该参数过大会增大checkpoint的压力
work_mem	用来声明内部排序和哈希操作可使用的工作内存大小，建议该值为10M 【说明】：增加work_mem有助于提高排序的速度，通常设置时可以逐渐调大。但是该内存在每个连接都会新建一份，所以当并发连接较多时，该值不宜过大
effective_cache_size	可设置为空闲内存的1/4，默认推荐2G
maintenance_work_mem	只在create index，vacuum时用到的内存资源，推荐配置为512M
wal_buffer	根据shared_buffers的设置自动调整为shared_buffers的3%，最大限制为XLOG的segment_size。默认配置为16M
checkpoint_segments	每隔checkpoint_segments个日志段后创建一个checkpoint检查点。此值越大则表示允许shared_buffers中的被频繁访问的缓存数据存储的更久，这在一定程度上可以提高数据库性能。 【注意】：若此值太大会导致在数据库发生checkpoint时，处理更多的数据，带来长时间的I/O开销。若此值太小则导致会产生更多的WAL文件。推荐设置为64
checkpoint_timeout	效果与参数checkpoint_segments一样，触发条件为时间。默认配置为5min
checkpoint_completion_target	checkpoint完成时间，增大后会降低平均写入的开销。默认配置为0.9
commit_delay	一次处理多个事务，减少I/O，提高性能。默认配置为10
commit_siblings	触发commit_delay的并发事务数，最佳配置为并发执行增删改操作的平均连接数。默认配置为10

 

12. 通过优化Linux的内核参数可以提高服务器的并发处理能力，优化的方式主要有哪些？

(1)     释放TCP连接中TIME_WAIT状态占用的系统资源

Linux系统下，TCP连接断开后，会先以TIME_WAIT状态保留一定时间，然后再释放端口。所以当并发请求过多时，会产生大量TIME_WAIT状态的连接，此时若无法及时断开，则TIME_WAIT状态的连接会占用大量的端口资源和服务器资源。因此，可以优化TCP的内核参数，及时清理TIME_WAIT状态的端口。针对大量TIME_WAIT状态的连接导致系统资源浪费时，可通过以下操作进行优化：

a.     通netstat命令判断是否有大量TIME_WAIT状态的连接，查看当前连接数的命令如下：

netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'

示例查询结果如下，可以看到TIME_WAIT状态的数量较多，此时通过调整Linux的TCP内核参数，可以让系统更快的释放TIME_WAIT连接。

[root@node2 ~]# netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}' TIME_WAIT 15821 CLOSE_WAIT 5 ESTABLISHED 50

 

b.     修改/etc/sysctl.conf文件，释放TIME_WAIT连接

打开配置文件，命令如下：

vim /etc/sysctl.conf

需要在此文件中添加如下内容：

net.ipv4.tcp_syncookies = 1 net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_tw_recycle = 1 net.ipv4.tcp_fin_timeout = 30

 

表10-5 参数说明

参数	说明
net.ipv4.tcp_syncookies	表示开启SYN Cookies。当出现SYN等待队列溢出时，启用cookies来处理，可防范少量SYN攻击 默认为0，表示关闭
net.ipv4.tcp_tw_reuse	表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接 默认为0，表示关闭
net.ipv4.tcp_tw_recycle	表示开启TCP连接中TIME-WAIT sockets的快速回收 默认为0，表示关闭
net.ipv4.tcp_fin_timeout	修改系統默认的 TIMEOUT 时间

 

c.     执行sysctl -p命令，使内核参数修改生效

(2)     优化TCP连接参数

如果当前环境中TCP连接数较多，则可通过调整TCP参数，进一步提升服务器的并发能力，操作如下：

a.     打开配置文件，命令如下：

vim /etc/sysctl.conf

需要在此文件中添加如下内容：

net.ipv4.tcp_keepalive_time = 1200 net.ipv4.ip_local_port_range = 10000 65000 net.ipv4.tcp_max_syn_backlog = 8192 net.ipv4.tcp_max_tw_buckets = 5000

 

表10-6 参数说明

参数	说明
net.ipv4.tcp_keepalive_time	表示当keepalive启用时，TCP发送keepalive消息的频度 默认为2小时，建议修改为20分钟
net.ipv4.ip_local_port_range	表示用于向外连接的端口范围 缺省情况下为32768到61000（设置范围很小），建议修改为10000到65000（注意：此时端口设置最低值不要太小，否则可能会占用正常端口）
net.ipv4.tcp_max_syn_backlog	表示SYN队列的长度 默认为1024，建议加大队列长度为8192，用以容纳更多等待连接的网络连接
net.ipv4.tcp_max_tw_buckets	表示系统同时保持TIME_WAIT的最大数量，如果超过这个数字，TIME_WAIT将立刻被清除并打印警告信息 默 认为180000，建议修改为6000。（说明：对于Apache、Nginx等服务器，上述几个参数就可以很好地减少TIME_WAIT套接字数量；但是对于Squid，却主要由此参数控制TIME_WAIT的最大数量，以避免大量的TIME_WAIT影响Squid服务器性能）

 

b.     执行sysctl -p命令，使内核参数修改生效

(3)     关于Linux内核参数的其他调优方法

除上述两种方法外，其他关于Linux内核参数的调优方法请参考官网。

13. 常用服务组件存放位置在哪里？

表10-7 组件数据存放位置

服务组件	存放位置	说明
ZooKeeper	配置项dataDir的值	存放ZooKeeper数据
HDFS-JournalNode	配置项dfs.journalnode.edits.dir的值	存放HDFS的JournalNode数据
HDFS-NameNode	配置项dfs.namenode.name.dir的值	存放HDFS的NameNode数据
HDFS-DataNode	配置项dfs.namenode.data.dir的值	1，推荐把每个物理磁盘挂载在/opt/disknn（nn为1至2位的数字）上不同的挂载点 2，存放HDFS的DataNode数据以及MapReduce2中间数据
Storm	配置项storm.local.dir的值	存放Supervisor和Workers数据。其中Nimbus元数据存储到ZooKeeper中，如果元数据比较大的话，可以增大ZooKeeper的数据磁盘大小
Kafka	配置项log.dirs的值	存放Kafka的数据目录
Solr	配置项solr.dir的值	1，基于性能考虑，Solr的索引数据可以存放在本地磁盘：每个Solr实例将各自的solrhome目录放置到独立磁盘上，用以存放Core的元数据和索引数据 2，Solr的索引数据和元数据存放在HDFS：通过设定solr.in.sh的配置参数的值来决定是否存放在HDFS 上，默认不存放。如选择存放在HDFS中，则Solr会依赖HDFS，否则不依赖。在此场景下，Solr无需配置数据盘
Redis	配置项redis.dir的值	1，根据节点CPU核数计算可以安装的Redis实例数：CPU核数–2 2，根据数据盘数计算每个盘需要支持的实例数（即分区数）：Redis 实例数/盘数向上取整 3，单块物理磁盘上划分分区数不要超过5个
PostgreSQL （集群中独立安装的PostgreSQL）	配置项dataDir的值	存放PostgreSQL数据
Elasticsearch5	配置项es.path.data的值	建议使用SSD，不要使用NAS，并且每个分区下的大小要相等，否则盘剩余空间较大的I/O压力会过大

 

14. 如何在DataEngine Manager中配置ElasticSearch master/data/client？

 

部署全文检索ElasticSearch集群时，

·     集群节点规模小于等于5时，不需要单独配置ElasticSearch master，接受安装ElasticSearch时的缺省配置即可。

·     集群节点规模大于5时，需要配置3个独立的ElasticSearch master。此时可通过配置组实现上述需求。

配置ElasticSearch master/data/client步骤如下：

(1)     通过系统管理员（admin）登录DataEngine Manager管理界面，ElasticSearch安装完成后，在顶部导航栏中[服务]的下拉菜单选择ElasticSearch进入其[配置]页面。

(2)     点击<管理配置组>按钮，新增设置ElasticSearch master配置组和ElasticSearch data配置组两个配置组，如图10-3所示（示例ElasticSearch集群规模为10节点）。

图10-3 新增ElasticSearch配置组

 

(3)     按照配置组ElasticSearch master配置3个控制节点为master，方式如下：

a.     选择ElasticSearch Default配置组，拷贝其高级 elasticsearch5-config下的content中的内容

b.     选择ElasticSearch master配置组，在其高级 elasticsearch5-config下的content中点击图标，在新窗口中粘贴上一步骤中拷贝的内容，并在末尾新增添加如下内容：

discovery.zen.minimum_master_nodes: 2

node.master: true

node.data: false

(4)     按照配置组ElasticSearch data配置其余数据节点为data，方式如下：

a.     选择ElasticSearch Default配置组，拷贝其高级 elasticsearch5-config下的content中的内容

b.     选择ElasticSearch data配置组，在其高级 elasticsearch5-config下的content中点击图标，在新窗口中粘贴上一步骤中拷贝的内容，并在末尾新增添加如下内容：

discovery.zen.minimum_master_nodes: 2

node.master: false

node.data: true

(5)     （可选）按照配置组ElasticSearch client配置一个节点为client node，方式如下：

a.     新增一个ElasticSearch client配置组

b.     选择ElasticSearch Default配置组，拷贝其高级 elasticsearch5-config下的content中的内容

c.     选择ElasticSearch client配置组，在其高级 elasticsearch5-config下的content中点击图标，在新窗口中粘贴上一步骤中拷贝的内容，并在末尾新增添加如下内容：

discovery.zen.minimum_master_nodes: 2

node.master: false

node.data: false

15. 异常情况：添加服务失败，若提示缺少yum文件或是相关软件源问题时，请注意查看源文件是否齐全以及源地址是否可用。

示例：以CentOS 6.5为例，可查看源文件所在路径为：/etc/yum.repos.d/。

检查步骤如下：

(1)     文件内容是否与管理节点（Manager节点）对应源文件一致。

(2)     若不一致，请重置为一致，然后使用如下命令重置yum源：

yum clean all

【说明】：其他操作系统下，请联系H3C技术支持工程师。

16. 安装了Spark2或Sparrow的集群，因YARN资源不足出现集群中其他服务无法正常运行时，如何解决？

解决方法：因Spark2的Thrift JDBC/ODBC Serve进程或Sparrow的SparrowThriftServer进程默认会持续占用YARN资源，导致YARN资源剩余过少，所以此种情况发生时，可根据实际情况手动kill这两种进程之后再运行其他服务。

11 附录

11.1  Kerberos端口号更改操作指导

DataEngine集群开启安全模式时，KDC端口号缺省为88，Kadmin端口号缺省为749，KDC和Kadmin的端口号均支持自定义更改。

根据DataEngine集群是否已开启安全模式的场景和操作方式的不同，Kerberos端口号更改方式分为以下四种情况：

·     DataEngine集群已开启安全模式时

¡     通过脚本更改Kerberos端口号

¡     手动更改Kerberos端口号

·     DataEngine集群未开启安全模式时

¡     通过脚本更改Kerberos端口号

¡     手动更改Kerberos端口号

 

11.1.1  DataEngine集群未开启安全模式

DataEngine集群未开启安全模式时，更改Kerberos端口号的步骤如下：

(1)     首先，需要进行后台的相关配置，以下两种方法，任选其一即可：

¡     若通过脚本更改后台配置，详情请参见11.1.3  1. 通过脚本更改Kerberos端口号。

¡     若直接手动更改后台配置，详情请参见11.1.3  2. 手动更改Kerberos端口号。

(2)     KDC端口号和Kadmin端口号在后台修改成功后，还需要在Manager管理界面进行以下操作：

a.     在DataEngine Manager顶部导航栏中[系统管理]的下拉菜单，选择[Kerberos]进入，点击<启用Kerberos>按钮，进入启用Kerberos向导。

b.     进入[开始]页面，选择使用哪种KDC。缺省选择“已有的MIT KDC”，建议不修改，勾选所有检查项后，点击<下一步>。进入[配置Kerberos]页面，此时可通过修改KDC host和Kadmin host配置项的值来实现为KDC和Kadmin更改端口号，如图11-1所示，在KDC host和Kadmin host配置的IP后面直接添加“：端口号”，即格式为“IP：端口号”。然后点击<测试KDC连接>按钮进行检查，测试通过后根据提示信息继续完成Kerberos启用即可。

图11-1 配置Kerberos

 

11.1.2  DataEngine集群已开启安全模式

DataEngine集群已开启安全模式时，更改Kerberos端口号的步骤如下：

(1)     首先，需要在Manager管理界面进行以下操作：

a.     在DataEngine Manager顶部导航栏中[服务]的下拉菜单中，选择Kerberos进入。

b.     在Kerberos的配置页面可通过修改KDC host和Kadmin host配置项的值来实现为KDC和Kadmin更改端口号，如图11-2所示，在KDC host和Kadmin host配置的IP后面直接添加“：端口号”，即格式为“IP：端口号”。修改完成后，暂不需要点击<测试KDC连接>按钮，直接点击<保存>按钮，然后务必根据页面提示重启Kerberos服务。

图11-2 Kerberos配置页面

 

(2)     KDC端口号和Kadmin端口号在Manager管理界面修改成功后，还需要进行后台的相关配置，以下两种方法，任选其一即可：

¡     若通过脚本更改后台配置，详情请参见11.1.3  1. 通过脚本更改Kerberos端口号。

¡     若直接手动更改后台配置，详情请参见11.1.3  2. 手动更改Kerberos端口号。

(3)     再次登录Manager管理界面，在Kerberos的配置页面，点击<测试KDC连接>按钮可验证Kerberos端口是否更改成功。

图11-3 验证Kerberos端口是否更改成功

 

 

11.1.3  修改后台的相关配置

可执行更改Kerberos端口号后台操作的用户包括：root用户和所有被赋予权限的非root用户。其中：

·     使用root用户更改Kerberos端口号时，直接执行配置操作即可。

·     使用非root用户更改Kerberos端口号时，务必要执行以下操作：

¡     为DataEngine集群中所有节点的非root用户配置sudo权限，即为/etc/init.d/krb5kdc  restart和/etc/init.d/kadmin  restart命令进行执行权限的配置。操作详情参加3.1  2. 操作用户权限设置章节，配置方式说明如下：

-     在DataEngine集群中所有节点上创建相同的非root用户，并设置相同的密码（本章节以bigdata用户进行示例说明）。

-     以root用户在/etc/sudoers文件中root    ALL=(ALL)       ALL后面添加如下内容：

bigdata    ALL=(root)       NOPASSWD: /etc/rc.d/init.d/kadmin

bigdata    ALL=(root)       NOPASSWD: /etc/rc.d/init.d/krb5kdc

¡     通过root用户为/etc/krb5.conf、/var/kerberos/krb5kdc/kdc.conf、/etc/sysctl.conf、/usr/local/tomcat/webapps/user/genkeytab.sh四个文件配置“其他用户的写权限”权限（比如646），命令如下：

chmod 646 /etc/krb5.conf

chmod 646 /var/kerberos/krb5kdc/kdc.conf

chmod 646 /etc/sysctl.conf

chmod 646 /usr/local/tomcat/webapps/user/genkeytab.sh

1. 通过脚本更改Kerberos端口号

 

通过脚本更改Kerberos端口号时，后台的相关配置的操作步骤如下：

(1)     将change_kerberos_ip.sh、change_kerberos_ip_next.sh、change_kerberos_ip.py三个脚本分别上传至集群当前管理节点的安装目录（示例/opt/DataEngine-<version>-Basic）下，其中：

¡     将change_kerberos_ip.sh、change_kerberos_ip_next.sh脚本上传至/opt/DataEngine-<version>-Basic目录下

¡     将change_kerberos_ip.py脚本上传至/opt/DataEngine-<version>-Basic/script目录下

 

(2)     分别为3个脚本赋予执行权限，命令如下：

chmod +x change_kerberos_ip.sh

chmod +x change_kerberos_ip_next.sh

chmod +x script/change_kerberos_ip.py

(3)     进入DataEngine安装目录，查看当前Kerberos的端口号情况，命令如下：

./change_kerberos_ip.sh status

图11-4 查看当前Kerberos的端口号

 

(4)     更改Kerberos的端口号，在DataEngine安装目录下执行以下命令：

./change_kerberos_ip.sh restore [kdc端口号] [kadmin端口号] [用户名] [密码]

其中：[kdc端口号]为新规划的KDC端口号，[kadmin端口号]为新规划的Kadmin端口号，用户名为执行此操作的用户，密码为对应用户密码。

 

图11-5 示例：通过root用户将KDC端口号修改为21701，将Kadmin端口号修改为21702

 

(5)     查看KDC端口号和Kadmin端口号修改是否成功，命令如下：

./change_kerberos_ip.sh status

图11-6 查看Kerberos的端口号是否修改成功

 

2. 手动更改Kerberos端口号

 

手动更改Kerberos端口号时，后台的相关配置的操作步骤如下：

(1)     进入DataEngine安装目录（示例/opt/DataEngine-<version>-Basic），查看当前Kerberos的端口号情况，命令如下：

netstat -tunlp | grep -w 88

netstat -tunlp | grep -w 749

图11-7 查看当前Kerberos的端口号

 

(2)     分别在Manager的主备管理节点上修改KDC和Kadmin的配置文件（示例：将KDC端口号修改为21701，将Kadmin端口号修改为21702），修改内容如下：

¡     修改/etc/krb5.conf文件，如图11-8所示，在[realms]中kdc和admin_server对应IP后面分别添加新规划的端口号，格式为“IP：端口号”。

图11-8 修改/etc/krb5.conf文件

 

¡     修改/var/kerberos/krb5kdc/kdc.conf文件，如图11-9所示，将KDC默认端口号（88）更改为新规划的端口号。

图11-9 修改/var/kerberos/krb5kdc/kdc.conf文件

 

(3)     分别在Manager的主备管理节点上重启KDC和Kadmin服务，查看端口号是否已更改成功，重启命令如下：

¡     集群当前（active）管理节点重启命令：

crm resource restart master-krb5kdc

crm resource restart master-kadmin

¡     集群备用（standby）管理节点重启命令（注意：若操作系统不支持restart，比如CentOS7.6的操作系统，则需要先stop再start）：

/etc/init.d/krb5kdc restart

/etc/init.d/kadmin restart

(4)     在DataEngine集群的所有节点上，如图11-10所示，分别将KDC和Kadmin服务新规划的端口号添加至/etc/sysctl.conf文件中

 

图11-10 修改/etc/sysctl.conf文件

 

(5)     分别在Manager的主备管理节点上，修改/usr/local/tomcat/webapps/user/genkeytab.sh文件，如图11-11所示，将[realms]中的kdc和admin_server缺省端口号修改为新规划的端口号。

图11-11 修改/usr/local/tomcat/webapps/user/genkeytab.sh文件

 

(6)     查看KDC端口号和Kadmin端口号修改是否成功，命令如下：

netstat -tunlp | grep -w 21701

netstat -tunlp | grep -w 21702

图11-12 查看Kerberos的端口号是否修改成功

 

11.2  部署MPP2集群

11.2.1  MPP2集群部署前准备

 

1. 机架要求

MPP2集群规划机架时需要遵循以下原则：

集群中的所有节点建议要放置在不同的机架上。如果物理资源较少，则必须满足在不同的服务器节点上。

2. MPP2集群部署说明

·     在部署过程中，MPP2集群中每个节点的地位是一样的，尽量保持各个节点配置信息的一致性。

·     MPP2集群建议部署在同一个子网中，集群内通过汇聚交换机互联。

3. MPP2集群节点硬件要求

 

表11-1 MPP2集群服务器硬件要求

节点类型	服务器硬件要求
管理节点	CPU：2路10核，推荐5115（注意：为提高整个集群的性能，应尽量使用主频高性能好的CPU） 内存：256GB 硬盘：2块600GB SAS硬盘，不少于6块1.2T SAS硬盘 RAID卡：1GB Raid0/5卡（带超级电容） 网口：2个千兆网口，2个万兆网口
MPP2 Server节点	CPU：2路10核，推荐5115 内存：256GB 硬盘：2块600GB SAS硬盘、不少于12块1.2TB SAS硬盘（注意：硬盘总量相同时，建议使用更多块硬盘） RAID卡：1GB Raid0/5卡（带超级电容） 网口：2个千兆网口，2个万兆网口

 

4. MPP2集群磁盘分区方案

磁盘分区规划如下：

·     操作系统盘：OS盘，存在于所有节点，用来存放各节点操作系统，有固定的分区要求。

【注意】：如果安装操作系统时不修改默认分区配置，后续容易造成系统磁盘空间不足的问题，例如/var/log可能会占满系统分区等。

·     MPP2中每个Server节点之间都是对等的关系，因此在磁盘挂载过程中，应保持一致。

·     一个分区可以单独占用一个磁盘也可以是某个磁盘的一部分。当资源允许每个分区对应一个磁盘时，建议单独占用磁盘；当资源受限时，也必须要保证独立分区，以减少服务数据彼此之间的影响。

 

表11-2 磁盘分区和空间划分

硬盘容量(GB)	RAID 类型	硬盘用途	分区目录	文件系统类型	分区容量 (GB)	用途
≥800	RAID1	OS	/	ext4	剩余磁盘空间，且容量至少≥200GB	大数据平台软件安装及操作系统使用
			/var/log	ext4	单独占用分区，建议容量≥200GB	日志存储
			-	swap	内存大小的10%	swap分区，当系统物理内存不够时，临时使用
		PostgreSQL（DataEngine Manager内置数据库）	/var/lib/pgsql	ext4	单独占用分区，建议容量≥200GB	存储服务组件的配置信息和管理信息。 当集群节点数较多时，应适当调大该分区大小
≥1024	RAID5	MPP2 Server节点	/opt/vertica	ext4	建议容量≥1024GB	MPP2集群的数据目录

 

5. MPP2集群节点规划

MPP2是多主的架构，每个节点的地位是相同的，可以理解为都是数据节点，在节点规划上相对比较简单。

图11-13 MPP2集群节点规划

节点类型	服务/组件	说明
数据节点	MPP2 Sever	每个Server地位相同，需要保持一致

 

11.2.2  MPP2集群高可靠方案

图11-14 MPP高可靠方案配置说明

组件名称	配置说明	说明
MPP2	可以通过配置ksafety值，决定数据副本的多少，默认为1，表示数据有一份数据备份	一个集群中ksafety的最大值与节点数之间的关系为：2*ksafety+1=节点数。 例如：三个节点的集群，ksafety最大为1，五个节点的集群，ksafety最大为2

 

11.2.3  MPP2集群部署流程

1. 访问DataEngine Manager

详情请参见3 部署DataEngine Manager章节。

2. 部署MPP2集群

首次登录DataEngine Manager后，提示部署集群，如图11-15所示，点击<进入安装向导>即可进入创建集群向导页面。

图11-15 创建集群

 

部署MPP2集群的操作步骤如下：

(1)     进入[开始]页面，输入集群名称后，点击<下一步>。

图11-16 集群名称

 

(2)     进入[选择版本]页面，可以展开高级选项查看安装rpm源地址。然后，点击<下一步>。

图11-17 选择版本

 

(3)     进入[安装选项]页面，输入集群各节点主机名，默认自动填充。然后，点击<注册并确认>。

图11-18 输入集群各节点主机名

 

(4)     进入[确认主机]页面，等待DataEngine对所有节点（本文以部署3节点的MPP2集群示例）进行注册并检查，出现图11-19所示后，点击<下一步>。

图11-19 确认主机

 

(5)     进入[选择服务]页面，选择安装MPP2服务，选择默认Metrics服务。然后，点击<下一步>。

图11-20 选择服务

 

(6)     进入[分配Master服务]页面，可以在下拉框中为已勾选服务内组件及客户端的安装，选择对应节点，然后，点击<下一步>。

图11-21 指定主服务

 

 

(7)     进入[分配Slave和Client]页面，可以自定义分配MPP2集群的Client（此时Client指MPP2  Client，即MPP2的客户端）。然后，点击<下一步>。

图11-22 分配Client

 

 

(8)     进入[定制服务]页面，此时需要根据集群实际情况，手动修改以下两个MPP2的配置项：

¡     mpp2.database.passwd配置项，用来配置默认数据库H3C_Database的密码，该密码在后续执行登录数据库或者修改数据库等操作时会用到，需要手动填入。

¡     配置项Super user passwd，用于设置服务器数据库用户（dbadmin）的密码，需要手动填入。

图11-23 定制服务

 

 

(9)     进入[检查]页面，需要进行MPP2集群部署前的最后检查，确认无误后点击<部署>按钮开始部署。

图11-24 检查信息

 

(10)     进入[安装、启动和测试]页面，安装过程中会显示每个节点安装的详细进度，如图11-25所示，点击各节点上的消息可以查看安装详情。待安装结束后，点击<下一步>。

图11-25 启动安装

 

(11)     进入[概要]页面可查看安装结果和详情，点击<完成>按钮即可进入DataEngine Manager的主页。

3. MPP2 Management Console添加流程

 

添加MPP2 Management Console的操作步骤如下：

(1)     在顶部导航栏中[服务]的下拉框，选择MPP2服务进入其管理配置界面，然后在右上角[快速链接]的下拉框中，选择任一节点对应的MPP2 MC UI，进入是否同意License协议页面，如图11-26所示。

 

图11-26 同意License协议

 

(2)     同意License协议之后，会进入Configure Management Console页面。设置Management Console的用户名和密码以及对应的用户组和端口号，此处的密码是后续登录Management Console时在页面上输入的密码，此外Management Console端口号可以设置为其他端口，但是需要能够正常访问。

图11-27 配置MC信息

 

(3)     点击<Next>按钮，进入Configure页面。需要指定连接数据库的数据和日志文件路径，该配置可以在安装完成Management Console之后，再次修改。

图11-28 配置存储路径

 

图11-29 配置认证方式

 

(4)     在配置完成以上Management Console信息之后，不用刷新页面，等待2~3分钟左右，待Management Console后台数据库重启之后，会重定向到如图11-30所示的登录页面。

图11-30 Management Console登录页面

 

(5)     进入登录Management Console页面，输入步骤2设置的登录Management Console密码，进入Management Console的主页面。

图11-31 Management Console主页面

 

(6)     在Management Console主页面，点击<Import a Vertica Database Cluster>按钮，导入默认创建的数据库集群。在图11-32所示页面中输入集群中任意一台服务器的IP地址。然后，点击<Next>。

图11-32 输入IP地址

 

(7)     为了保证数据库的安全，在导入数据库集群的过程中，需要输入集群的API Key，该密钥默认存储在集群中每一台的/opt/vertica/config/apikeys.dat文件中。

图11-33 导入API Key

 

(8)     导入API Key后，进入如图11-34所示页面，此时需要输入数据库集群的用户名和密码。默认的用户名是dbadmin，密码是安装MPP2服务时，设置的mpp2.database.passwd。填写完成之后，点击<Import>按钮，此时会将数据库集群信息导入到Management Console中。

图11-34 输入集群用户名和密码

 

(9)     导入数据库集群完成之后，页面会自动定向到如图11-35所示页面。点击左侧“Database”页签，会弹出展示集群信息的对话框，点击<View>按钮。

图11-35 导入集群信息

 

(10)     点击<View>按钮，可查看集群的整体信息。

图11-36 集群信息展示