01-正文
本章节下载 (5.33 MB)
目 录
3.2.1 查看DataEngine Manager HA状态
3.2.2 手动切换DataEngine Manager 主备
7.2 在DataEngine Manager中配置License
DataEngine是指H3C大数据集成管理平台,通过DataEngine Manager管理界面可以统一监控和管理集群内所有服务和服务组件、主机、告警信息以及日志等。DataEngine自带简单多样的部署方案、丰富细致的集群运维和成熟完备的服务支持,可以满足不同行业客户的个性化需求。
本手册所涉及的操作系统相关参数的调整,主要针对CentOS操作系统。
为帮助您更好的理解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等。
· 组件和实例
¡ 组件:是服务的组成部分,每个服务由一个或多个组件组成。
¡ 实例:服务中的组件被安装到服务器节点上即形成一个实例,部分组件支持在一个节点上部署多个实例。
· 背板带宽
交换机的背板带宽,是指交换机接口处理器或接口卡和数据总线间所能吞吐的最大数据量。
· 在实际部署环境中,HDP集群要求至少部署在3个节点上,MPP1集群至少部署在3个节点上。
· 若同时规划部署HDP和MPP系列集群,要求不能部署在相同的节点上。
· 本章节主要以业务集群类型区分,说明部署前的准备工作。
DataEngine部署包括部署DataEngine Manager管理界面和部署DataEngine集群两部分,DataEngine集群的部署和管理必须通过DataEngine Manager管理界面。DataEngine集群安装包包括基础包和扩展包,其中基础包可用于部署DataEngine Manager管理界面和DataEngine平台支持的主要服务,扩展包提供DataEngine平台支持的其他扩展服务。
关于DataEngine安装包(基础包)和DataEngine安装包(扩展包)分别包含的服务详情请参见10 1. DataEngine集群安装包中的服务规划。
DataEngine的部署步骤汇总如表2-1所示。
表2-1 DataEngine部署步骤汇总
序号 |
步骤 |
详细操作 |
说明 |
|
1 |
开展部署前的准备工作,以满足环境要求、集群部署规划和不同业务集群的要求等 |
必选 |
||
2 |
安装DataEngine基础包,部署DataEngine Manager |
必选 |
||
可选 |
||||
3 |
可选(推荐) |
|||
必选 |
||||
4 |
/ |
必选 |
||
5 |
部署DataEngine集群 |
根据实际情况,选择安装 |
||
根据实际情况,选择安装 |
||||
DataEngine扩展包的使用(可选) |
根据实际情况,选择安装 |
|||
6 |
可选(推荐) |
|||
必选 |
||||
7 |
/ |
必选 |
||
在生产环境中,根据业务需求不同,DataEngine集群分为多种类型,如表2-2所示。
表2-2 DataEngine集群类型
集群类型 |
业务集群 |
HDP集群 |
|
MPP系列集群 |
|
进行DataEngine集群规划时,需要关注以下内容:
· 规划集群中的节点数目以及集群中的机柜数目
· 规划每个机柜中的节点数目以及每个机柜的名称
· 规划集群中各节点的角色:管理节点、控制节点或数据节点
· 规划两个管理节点(一个作为主节点,一个作为备用节点)和访问DataEngine Manager的虚拟IP地址
· 规划每个节点所在的子网(或多个子网),以及规划每个节点的主机名和IP地址
【注意】:在两个或者多个集群中做数据备份、迁移或其他通信时,规划的主机名需要在所有集群中保证名称唯一
· 需要知道集群中用户的密码(DataEngine集群安装时要求所有节点使用的用户名和密码必须保持一致)
· 对于HDP集群,需要规划集群中安装哪些服务
部署DataEngine集群时,支持的操作系统说明如表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) |
如果对操作系统版本没有特殊要求,推荐使用Cent OS的操作系统,推荐使用Minimal模式,且不支持中文语言。
DataEngine Manager对浏览器的要求如下:
· Chrome 45及以上版本
· Firefox 18及以上版本
部署DataEngine时,需要准备的软件安装包如表2-4所示。
软件名称 |
版本 |
用途说明 |
获取方式 |
DataEngine安装包(基础包) |
DataEngine-<version>-Basic.tar.gz |
用于安装DataEngine平台的Manager和基础服务 |
由H3C提供 |
DataEngine安装包(扩展包) |
DataEngine-<version>-Extra.tar.gz |
用于安装DataEngine平台的扩展服务 |
由H3C提供 |
当前操作系统镜像 |
*.iso |
提供基础的yum源 |
由用户准备(备注:该镜像不能使用Minimal镜像) |
· 集群中各节点之间不能跨越防火墙
· 规划网络带宽和交换机背板带宽,决定交换机型号
· 规划如何连接到交换机,必须知道需要用到哪些以太网端口以及是否需要绑定
(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。
(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 |
· 隔离实时和非实时工作负载,对实时性要求比较高的负载建议采用独立集群。
· 根据业务对硬件资源的根本性差异(含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一般不占用实体进程资源,所以每个节点上都可以添加部署,这样可以使每个节点都能使用客户端程序。
服务名称 |
组件名称 |
依赖关系 |
服务组件业务部署原则 |
|
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 |
建议部署在非管理节点上 |
整体原则:管理节点与控制节点都做RAID1;数据节点做RAID0或者不做RAID;元数据路径最优是单独挂盘,并做RAID1。
因不同厂商的硬件服务器设置方式略有不同,这里仅说明部署DataEngine时配置RAID的建议,对于配置过程不做说明。
表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 |
仅从硬盘空间来考虑,集群主要分为离线计算、在线查询、全文检索。其中:离线计算主要是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 |
磁盘分区规划如下:
· 操作系统盘:OS盘,存在于所有节点,用来存放各节点操作系统,有固定的分区要求。
【注意】:如果安装操作系统时不修改默认分区配置,后续容易造成系统磁盘空间不足的问题,例如/var/log可能会占满系统分区等。
· 数据盘:缺省挂载在/opt目录下,不需要单独分区。
· 一个分区可以单独占用一个磁盘也可以是某个磁盘的一部分。当资源允许每个分区对应一个磁盘时,建议单独占用磁盘;当资源受限时,也必须要保证独立分区,以减少服务数据彼此之间的影响。
· 各类型的DataEngine集群内,所有节点的系统盘磁盘分区规划均如表2-10所示,其中仅管理节点(Manager节点)可根据实际需求单独为PostgreSQL(内置)划分分区。
· Metrics缺省使用DataEngine Manager内置数据库(PostgreSQL)做数据存储,建议PostgreSQL的单独分区容量≥300GB,否则可能将导致服务异常。
· 根据现场磁盘分区方案和挂盘方案的不同,或管理节点(Manager节点)是否单独为PostgreSQL(内置)划分了分区,部分服务组件配置项的参数值可能会受影响。因此在数据节点上安装服务时,必须检查部分服务配置项的参数值,否则可能导致服务安装失败或使用异常。关于以上情况下受影响的服务以及各服务待检查的配置项,详情请参见10 5. 根据现场磁盘分区方案和挂盘方案的不同,或管理节点(Manager节点)是否单独为PostgreSQL(内置)划分了分区,在数据节点上安装服务时,可能受影响的服务以及各服务必须检查的配置项有哪些?
硬盘容量(GB) |
硬盘用途 |
分区目录 |
文件系统类型 |
分区容量(GB) |
用途 |
≥800 |
OS |
/ |
ext4 |
剩余磁盘空间,且容量至少≥300GB |
大数据平台软件安装及操作系统使用 |
/var/log |
ext4 |
单独占用分区,建议容量≥200GB |
日志存储 |
||
PostgreSQL(DataEngine Manager内置数据库) |
/var/lib/pgsql |
ext4 |
单独占用分区,建议容量≥300GB |
存储服务组件的配置信息和管理信息 当集群节点数较多时,应适当调大该分区大小 |
根据生产环境的实际需求,不同类型的DataEngine集群均需要分别规划两个DataEngine Manager管理节点。
节点数量小于30时,Manager管理节点可以和控制节点合并部署;节点数量大于30时,建议Manager管理节点独立部署。
数据分发缓存集群要求至少安装Zookeeper、Kafka服务。
表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-12所示要求。
· 此集群管理节点和控制节点推荐服务器硬件选自NaviData 5200 G3 8SFF,数据节点推荐服务器硬件选自NaviData 5200 G3 12LFF,硬件可根据实际情况进行调整,详情请咨询H3C技术支持工程师。
节点类型 |
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个万兆网口 |
在线结构化数据集群要求至少安装HBase、HDFS、YARN、MapReduce2、Zookeeper服务。
表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-14所示要求。
· 此集群管理节点和控制节点推荐服务器硬件选自NaviData 5200 G3 8SFF,数据节点推荐服务器硬件选自NaviData 5200 G3 12LFF,硬件可根据实际情况进行调整,详情请咨询H3C技术支持工程师。
节点类型 |
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个万兆网口 |
在线非结构化数据集群要求至少安装HBase、HDFS、YARN、MapReduce2、Zookeeper服务。
表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-16所示要求。
· 此集群管理节点和控制节点推荐服务器硬件选自NaviData 5200 G3 8SFF,数据节点推荐服务器硬件选自NaviData 5200 G3 12LFF,硬件可根据实际情况进行调整,详情请咨询H3C技术支持工程师。
节点类型 |
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个万兆网口 |
全文检索ElasticSearch集群要求至少安装ElasticSearch服务。
表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个即可) |
· 为使全文检索ElasticSearch集群性能最优,推荐服务器硬件满足表2-18所示要求。
· 此集群管理节点和控制节点推荐服务器硬件选自NaviData 5200 G3 8SFF,数据节点推荐服务器硬件选自NaviData 5200 G3 25SFF,硬件可根据实际情况进行调整,详情请咨询H3C技术支持工程师。
表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个万兆网口 |
· 全文检索Solr集群要求至少安装Zookeeper、Solr服务。
· 全文检索Solr建议单独部署,DataEngine中默认为SolrCloud部署模式,此时没有严格master和data区分,只有一个overseer是由zookeeper来控制的。
表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 |
· 为使全文检索Solr集群性能最优,推荐服务器硬件满足表2-20所示要求。
· 此集群管理节点和控制节点推荐服务器硬件选自NaviData 5200 G3 8SFF,数据节点推荐服务器硬件选自NaviData 5200 G3 25SFF,硬件可根据实际情况进行调整,详情请咨询H3C技术支持工程师。
表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个万兆网口 |
实时流集群主要使用Storm服务,部署模式为独立模式,此时要求至少安装Zookeeper、Storm服务。
表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-22所示要求。
· 此集群管理节点、控制节点和数据节点推荐服务器硬件均选自NaviData 5200 G3 8SFF,硬件可根据实际情况进行调整,详情请咨询H3C技术支持工程师。
表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个万兆网口 |
Redis集群要求至少安装Redis服务。
表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台 |
· 为使Redis集群性能最优,推荐服务器硬件满足表2-24所示要求。
· 此集群管理节点和数据节点推荐服务器硬件均选自NaviData 5200 G3 8SFF,硬件可根据实际情况进行调整,详情请咨询H3C技术支持工程师。
表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个万兆网口 |
· 离线分析挖掘集群要求至少安装YARN、HDFS、MapReduce2、Zookeeper、Hive或Hive2服务。
· 本章节描述以安装Hive示例。安装Hive2时与其类似,但安装Hive2时必须在集群内安装Hive。
表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-26所示要求。
· 此集群管理节点和控制节点推荐服务器硬件选自NaviData 5200 G3 8SFF,数据节点推荐服务器硬件选自NaviData 5200 G3 12LFF,硬件可根据实际情况进行调整,详情请咨询H3C技术支持工程师。
节点类型 |
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个万兆网口 |
· 分布式内存计算集群要求至少安装YARN、HDFS、Zookeeper、Hive、Spark2或Spark服务。
· 本章节描述以安装Spark2示例,安装Spark时与其类似。
表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-28所示要求。
· 此集群管理节点和控制节点推荐服务器硬件选自NaviData 5200 G3 8SFF,数据节点推荐服务器硬件选自NaviData 5200 G3 12LFF,硬件可根据实际情况进行调整,详情请咨询H3C技术支持工程师。
节点类型 |
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个万兆网口 |
MPP1集群规划机架时需要遵循以下原则:
· 需规划两个Master节点,一个作为主Master,一个作为备用Master(Standby Master)。尽量满足两个Master节点分开放置在不同的机架上。
· 尽量满足Primary实例和其备份实例所在的数据节点分开放置在不同的机架上。
· 同一网段下建议安装一个MPP1集群,否则会影响MPP1服务的HA特性。
· 集群规模:为了充分发挥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时可使用此方案 【说明】: 一般情况下,不推荐使用此场景,若节点数量满足需求,建议将数据节点单独部署 |
· 为使MPP1集群性能最优,推荐服务器硬件满足表2-30所示要求。
· 此集群管理节点和控制节点推荐服务器硬件均选自NaviData 5200 G3 8SLFF,数据节点推荐服务器硬件均选自NaviData 5200 G3 12LFF,硬件可根据实际情况进行调整,详情请咨询H3C技术支持工程师。
表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个万兆网口 |
(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可能会占满系统分区等。
· 一个分区可以单独占用一个磁盘也可以是某个磁盘的一部分。当资源允许每个分区对应一个磁盘时,建议单独占用磁盘;当资源受限时,也必须要保证独立分区,以减少服务数据彼此之间的影响。
仅DataEngine Manager管理节点需根据实际情况单独为PostgreSQL(内置)划分分区,其他节点不需要创建此分区。
表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集群的数据目录 |
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 |
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,以保证集群运维工作的正常进行。
· 部署DataEngine Manager时会自动开启DataEngine Manager HA,且该HA无法关闭。
· 关于DataEngine Manager的主节点(Master)与备用节点(Standby)选取策略、磁盘方案等均必须完全相同。
· 若集群中部署了Log Manager服务,则当切换DataEngine Manager主备节点时,需要重启Log Manager,否则Log Manager UI将无法访问。
HDP集群中的服务在安装时,为保证服务的健康运行,会自动开启高可靠HA。表2-37中简单介绍了各服务的HA策略,关于各服务HA的详细信息请参见《H3C DataEngine 服务用户手册》。
表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-38 MPP系列高可靠性方案配置说明
组件名称 |
配置说明 |
MPP1 |
MPP1 Master默认安装2个实现高可靠,MPP1 Segment通过安装在大于等于2个节点上实现高可靠 |
MPP2 |
MPP2 Server通过安装在大于等于3个节点上实现高可靠,且每个节点默认保存两份数据,用来备份容灾 |
可部署DataEngine集群的用户包括:root用户和所有被赋予权限的非root用户。
DataEngine部署方案为定制部署,应用场景如下:
· 对于需要利用现有集群中的服务器或者需求多样的客户,这种方式可以满足客户对系统安全、组网环境、节点复用等方面的特殊需求,方便实现一些定制化功能。
· 对集群的部署可以从不同阶段入手帮助客户完成整个大数据集群的搭建。
定制部署主要包括:安装服务器操作系统、分配网络环境、部署DataEngine Manager管理界面、部署DataEngine集群四个阶段,分步执行即可。具体部署流程如下:
(1) 安装服务器操作系统:可以选择PXE自动安装操作系统,也可以手动安装操作系统或对现有操作系统进行安全加固。
(2) 分配网络环境:需要根据客户现有网络环境和网段管理,为每个节点分配指定的主机IP地址。
(3) 部署DataEngine Manager管理界面:在操作系统安装和网络分配完成后,部署DataEngine Manager管理界面,安装过程中会自动开启DataEngine Manager HA功能。
(4) 部署DataEngine(HDP/MPP1)集群:通过DataEngine Manager管理界面为各节点分配服务。
图3-1 定制部署流程图
部署DataEngine Manager的步骤如下:
在集群部署网段中规划一个IP地址作为入口IP,DataEngine Manager HA功能开启后,将通过入口IP访问DataEngine Manager管理界面。该入口IP地址要求必须是同网段内,未被使用的任一IP地址。
若规划使用非root用户启动定制部署,请务必执行本章节的配置;若规划使用root用户启动定制部署,请跳过此章节的配置步骤。
使用非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. 安装过程。
需要确保DataEngine安装包上传到的文件夹为非root用户权限,还需要确保安装文件权限为非root用户权限。
(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位 |
可选 |
· 部署DataEngine集群时,要求配置的管理节点IP(local-ip和standby_ip)和集群节点IP组(ips)处于同一网段。
· manager_port后续不支持修改。
· 集群的virtual_ip和集群内所有主机节点的IP地址一旦设定,则均不建议修改。若后续需要修改,详情请参见10 7. 如何修改HDP集群的主机IP地址?。
(4) 在解压文件夹下,启动安装,命令如下:
./install.sh
安装执行过程中,会出现相关的询问信息,请根据提示输入信息后继续执行。
(5) 检查安装结果
安装通常会在15分钟内结束,具体执行时间与机器性能和并行执行的机器数量有关。安装完成后,会出现相关提示信息,显示访问DataEngine Manager的URL地址以及缺省用户名/密码。
· 若没有出现成功的提示信息,只要提示信息中未出现Failed等字样,均可认为安装成功。
· DataEngine Manager安装成功后,可通过提示信息中的URL登录DataEngine Manager管理界面进行集群的部署。
本章节中未做说明的命令,表示在root用户和非root用户下命令相同。
登录DataEngine集群主管理节点,在安装路径下,可查看Manager HA的状态,命令如下:
./HA.sh status
如果在DataEngine Manager主节点或备用节点的安装目录下,运行./HA.sh status无法查看Manager HA状态,请检查corosync是否启动。
· 如果没启动,请运行service corosync start(非root用户下需要在命令前添加sudo)启动。
· 如果corosync无法启动,请运行/.hde/cls_rebuild_slave.sh restart_corosync(非root用户下需要在命令前添加sudo)启动,如还无法启动请检查corosync日志(目录在/var/log/corosync/corosync.log或者/var/log/cluster/corosync.log);如果corosync启动,请检查pacemaker是否运行,如果没有运行请执行service pacemaker start(非root用户下需要在命令前添加sudo)。
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数据状态不正确
如果Manager HA状态中出现以上任一种非“Started”的状态信息都表示当前资源状态不正确,请参见10 4. DataEngine Manager HA状态不正常处理方法进行处理。
图3-3 Manager HA运行正常的状态
图3-4 Manager HA运行错误的状态
在某些情况下,需要手动将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主备节点
· DataEngine Manager主备节点切换过程中,DataEngine Manager将会重启,请确保执行此操作时,Manager中没有正在运行的任务。
· DataEngine Manager主备节点切换过程中,会出现相关的询问信息,请根据提示输入信息后继续执行。
开启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
· 执行以上操作后,可能需要等待一段时间才能生效。
· 建立Manager HA时,会对PostgreSQL和ambari-server等启动顺序进行约束,必须先启动PostgreSQL资源,才能启动其它资源。
DataEngine Manager安装完成后,若安装成功,通过URL地址:https://<DataEngine Manager入口节点IP>:<manager_port>,可以访问DataEngine Manager管理界面,如图3-6所示。
首次登录DataEngine Manager时会提示部署集群,如图4-1所示,点击<进入安装向导>即可进入集群安装向导页面。
· DataEngine可部署HDP集群或MPP系列集群,不同集群内部署的服务不同,详情请参见2.2 DataEngine集群类型。
· 通过系统管理员部署集群,系统管理员缺省用户名为admin,缺省密码为admin@123。
部署HDP集群的操作步骤如下:
(1) 进入[开始]页面,输入集群名称后,点击<下一步>。
图4-2 集群名称
(2) 进入[选择版本]页面,可以展开高级选项查看安装rpm源地址。然后点击<下一步>。
(3) 进入[安装选项]页面,输入集群各节点主机名(本文以部署3节点的HDP集群示例),默认自动填充。然后点击<注册并确认>。
(4) 进入[确认主机]页面,等待DataEngine对所有节点进行注册并检查。如图4-5所示,所有注册的主机检查通过后,点击<下一步>。
(5) 进入[选择服务]页面,选择想要安装的服务(建议根据前期规划结果进行服务选择),默认勾选Metrics服务。然后点击<下一步>。
图4-6 选择服务
某些服务之间有依赖关系,必须同时安装。比如勾选Hive服务时,必须同时选择Tez,否则会弹出提示框提示“需要Tez”,此时点击<确定>,将会添加需要的服务并跳转至下一步。
(6) 进入[分配Master服务]页面,可以在下拉框中为已勾选服务的组件选择对应部署节点,也可接受默认配置。然后点击<下一步>。
图4-7 指定主服务
指定各个Master组件到不同主机上时,可能会存在某些限制。若配置出现错误,页面会弹出相关提示信息,请注意查看。示例:Spark2的Spark2 History Server组件和Spark2 Livy组件需要安装在同一个节点上。
(7) 进入[分配Slave和Client]页面,可以自定义分配从节点和客户端,也可接受默认配置。然后点击<下一步>。
图4-8 分配从节点和客户端
指定Slave和Client时,可能会存在某些限制。若配置出现错误,页面会弹出相关提示信息,请注意查看。示例:安装Yarn NodeManager 组件的节点必须安装Spark2Client 组件。
(8) 进入[定制服务]页面,可以按照规划调整服务的配置参数、设置服务认证相关的密码,也可接受默认配置。然后点击<下一步>。
此步骤点击<下一步>,可能会弹出关于服务配置的提示框,提示“有些服务配置不正确,建议检查和修改高亮配置项的值,是否继续下一步?”,此时可根据实际情况分析,点击<继续>跳转至下一步(部分提示不影响集群部署);或点击<取消>返回上一步进行配置参数的重新调整。
(9) 进入[检查]页面,需要进行HDP集群部署前的最后检查,确认无误后点击<部署>按钮开始部署。
图4-10 检查信息
(10) 进入[安装、启动和测试]页面,安装过程中会显示每个节点每项服务安装的详细进度,如图4-11所示,点击各节点上的消息可以查看安装详情。待安装结束后,点击<下一步>。
(11) 进入[概要]页面可查看安装结果和详情,点击<完成>按钮即可进入DataEngine Manager的主页。
部署MPP1集群的操作步骤如下:
(1) 进入[开始]页面,输入集群名称后,点击<下一步>。
(2) 进入[选择版本]页面,可以展开高级选项查看安装rpm源地址。然后点击<下一步>。
图4-13 选择版本
(3) 进入[安装选项]页面,输入集群各节点主机名(本文以部署3节点的MPP1集群示例),默认自动填充。然后,点击<注册并确认>。
图4-14 输入集群各节点主机名
(4) 进入[确认主机]页面,等待DataEngine对所有节点进行注册并检查,如图4-15所示,所有注册的主机检查通过后,点击<下一步>。
(5) 进入[选择服务]页面,选择安装MPP1服务,默认勾选Metrics服务。然后点击<下一步>。
图4-16 选择服务
(6) 进入[分配Master服务]页面,可以在下拉框中为已勾选服务的组件选择对应部署节点,也可接受默认配置。然后点击<下一步>。
· 部署MPP1集群时需要安装2个Master节点,一个作为主Master,一个作为备用Master(Standby Master),并且要求这2个Master分别部署在两个节点上。
· MPP1服务默认按照2个Master节点主机名称的字符排序先后顺序选择主Master。例如:两个Master节点分别安装在node1和node2节点上,因字符排序结果是先node1后node2,所以node1是主Master,node2是Standby Master。
图4-17 指定主服务
(7) 进入[分配Slave和Client]页面,可以自定义分配MPP1的Client(此时Client指MPP1 Segment,即MPP1服务的数据节点),也可接受默认配置。然后点击<下一步>。
· 当集群节点数量大于3时,要求MPP1 Segment与Master节点部署在不同的节点上,以避免数据库出错。
· 若强制将数据节点部署在Master节点,会出现错误提示,请注意查看。示例:“MPP1 Segment组件不能与MPP1 Master安装在同一节点”。
图4-18 分配从节点和客户端
(8) 进入[定制服务]页面,此时需要根据集群实际情况,手动修改以下配置项:
<定制服务>步骤的其他配置项参数为默认值,请一定不要修改。若对配置项进行了错误修改,可能将直接导致MPP1部署失败。
¡ 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处于同一网段,且未被占用,否则点击<下一步>时会报错。
· MPP1数据库的虚拟IP格式必须为“IP/子网掩码”,例如1.1.1.1/15,其中1.1.1.1为IP地址,15为子网掩码(要求与DataEngine Manager安装节点的掩码信息一致)。
· 可以通过ip add命令查看DataEngine Manager安装节点的掩码信息,如图4-19所示,红框内信息即为DataEngine Manager安装节点的IP及掩码信息。
图4-19 DataEngine Manager安装节点IP信息查看
¡ 配置项Super user passwd,用于设置操作系统用户gpadmin的密码,缺省密码为h3cDataEngine。
图4-20 定制服务
此步骤点击<下一步>,可能会弹出关于服务配置的提示框,提示“有些服务配置不正确,建议检查和修改高亮配置项的值,是否继续下一步?”,此时可根据实际情况分析,点击<继续>跳转至下一步(部分提示不影响集群部署);或点击<取消>返回上一步进行配置参数的重新调整。
(9) 进入[检查]页面,需要进行MPP1集群部署前的最后检查,确认无误后点击<部署>按钮开始部署。
图4-21 检查信息
(10) 进入[安装、启动和测试]页面,安装过程中会显示每个节点每项服务安装的详细进度,如图4-22所示,点击各节点上的消息可以查看安装详情。待安装结束后,点击<下一步>。
(11) 进入[概要]页面可查看安装结果和详情,点击<完成>按钮即可进入DataEngine Manager的主页。
如果集群只供MPP1使用,可停止除MPP1以外的其他组件。
由于DataEngine Manager仅支持通过https协议访问,所以需要为浏览器添加授权证书以保证安全访问。如果没有执行此步骤,在浏览器访问时,选择“继续前往(不安全)”,也可以访问DataEngine Manager。
如果浏览器中以前没有导入过DataEngine证书或需要更新DataEngine证书时,均需要获取最新的证书。
以FireFox浏览器为例,添加安全证书的步骤如下:
(1) 在浏览器中输入DataEngine Manager访问地址,如图5-1所示,弹出“连接不安全”提示。此时,点击<高级>按钮,展示详情信息后点击<添加例外…>按钮。
(2) 弹出<添加例外…>的对话框,如图5-2所示,然后点击<查看>按钮。
(3) 点击<查看>按钮后,出现证书的详情界面。如图5-3所示,在详细信息页面的证书结构中,选择H3C DataEngine,然后点击<导出>按钮,将证书保存至本地,供稍后安装时使用。
(4) DataEngine最新证书获取成功后,进入浏览器[菜单/选项/高级/证书/查看证书/证书机构]页面。点击<导入>按钮,选择步骤3中获取的DataEngine最新证书。
此时,若浏览器中存在以前导入的DataEngine证书,需要先将其选中,然后点击<删除或不信任(D)…>将其删除。
(5) 在本地选择DataEngine最新证书并打开,弹出如图5-5所示对话框。此时,勾选所有信任项,点击<查看>按钮,检查证书机构中的证书是否导入成功。若导入成功,则点击<确定>按钮。
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文件并保存。
DataEngine集群部署完成后,参考3.3 访问DataEngine Manager,以系统管理员(admin)身份登录DataEngine Manager,进行主机管理检查、服务组件检查、以及健康检查,以确保集群状态正常。
点击DataEngine Manager顶部导航栏中的[主机],进入主机列表页面,可以检查集群中各主机健康状况,检查范围包括:
· 检查部署的DataEngine集群中所有节点是否都在主机列表中
· 检查所有主机状态是否都正常
· 点击主机名进入,可查看各主机上的具体服务组件状况,当出现异常时可选择重启等操作
图6-1 主机健康状况
表6-1 主机健康状态说明
健康状态 |
说明 |
处理方法 |
正常/告警 |
/ |
|
Master/Slave组件停止服务 |
重启组件 |
|
心跳丢失/重新启动 |
登录到主机节点上查看主机是否存在宕机;如果没有,需要查看ambari-agent的状态,若有异常可以尝试重启ambari-agent;如果依然无法恢复,请联系H3C 技术支持工程师 |
点击DataEngine Manager顶部导航栏中[服务],在其下拉菜单中,可以查看集群中已安装的各服务健康状况。
图6-2 服务健康状况
表6-2 服务健康状态说明
健康状态 |
说明 |
处理方法 |
正常/告警 |
/ |
|
Master/Slave组件停止服务 |
重启组件 |
|
心跳丢失/重新启动 |
登录到主机节点上查看主机是否存在宕机;如果没有,需要查看ambari-agent的状态,若有异常可以尝试重启ambari-agent。如果依然无法恢复,请联系H3C 技术支持工程师 |
|
只有客户端的服务 |
/ |
在DataEngine Manager顶部导航栏中[系统管理]的下拉菜单,选择[健康检查]进入,在即时检查栏中选择需要检查的主机和服务组件,点击<开始执行>执行健康检查,用于检查集群中已安装的各服务的基本功能。如图6-3所示,待检查结束后,通过检查结果获取主机和服务的健康状态,且可以查看检查详情或者下载检查报告。
DataEngine集群的使用状态包括安全模式和非安全模式。DataEngine集群部署完成后,以系统管理员身份登录DataEngine Manager,可选择是否开启安全模式。
· DataEngine集群的安全模式仅适用于HDP集群,不适用于MPP系列集群。
· DataEngine集群部署完成后,缺省处于非安全模式。
· DataEngine集群在非安全模式下,可能存在数据暴露、任意用户均可访问/操作数据等漏洞,因此在生产环境中强烈建议为DataEngine集群开启安全模式。
· 安全模式(即Kerberos)开启之后,无法关闭/卸载。
为DataEngine集群开启安全模式的步骤如下:
(1) 在DataEngine Manager顶部导航栏中[系统管理]的下拉菜单,选择[Kerberos]进入,点击<启用Kerberos>按钮,在提示框点击<继续>进入启用Kerberos向导。
(2) 进入[开始]页面,选择使用哪种KDC。缺省选择“已有的MIT KDC”,建议不修改,勾选所有检查项后,点击<下一步>。
图6-4 开始
(3) 进入[配置Kerberos]页面,参数值不可修改,使用默认值。点击<测试KDC连接>按钮可测试KDC相关配置是否正确,其中KDC host和Kadmin host为DataEngine Manager虚拟IP。测试成功后点击<下一步>。
KDC和Kadmin的端口号支持修改,详情请参见11.1 Kerberos端口号更改操作指导。
图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) 进入[开启并测试服务]页面,此过程中会开启服务并测试服务是否可用,测试成功后点击<完成>。
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服务
· 若普通用户需要在其他节点(非票据生成节点)上连接集群使用服务,则需要将keytab票据文件拷贝至其他节点,然后为用户执行获取票据的命令即可。
· 关于安全模式下,各服务更多的操作变更,详情请参见《H3C DataEngine 服务用户手册》。
· DataEngine Manager操作变更
在安全模式下,通过DataEngine Manager执行某些操作时,操作方式可能会发生变更,示例如下:
¡ 服务安装:在安全模式下,服务安装过程中会出现提示,需要输入管理员认证主体和管理员密码(管理员认证主体:admin/admin@HDE.H3C.COM,管理员密码:Admin@123),然后继续执行即可。
¡ 主机扩容:在安全模式下,主机安装过程中会出现提示,需要输入管理员认证主体和管理员密码(管理员认证主体:admin/admin@HDE.H3C.COM,管理员密码:Admin@123),然后继续执行即可。
关于安全模式下,关于DataEngine Manager更多的操作变更,详情请参见《H3C DataEngine Manager用户手册》。
除6.2.1 2. 安全模式下的操作变更章节列出的操作变更之外,DataEngine集群在安全模式和非安全模式下关于服务的操作和DataEngine Manager的操作完全相同。
DataEngine安装完成后,可在180天内试用所有功能,超过试用期限后,需要获取License授权才能正常使用。
DataEngine的注册流程如图7-1所示。
申请License文件后,如果设备信息文件对应的服务器出现网卡变更(包括禁用网卡、新网卡启用、网卡更换或旧网卡损坏等)或CPU更换等硬件信息的变更,可能会导致License文件失效。
登录License Server,单击[License/安装]菜单项,在该页面点击<导出DID>按钮获取License Server的设备信息文件。
获取到设备信息文件后,使用该文件和授权码生成激活文件,然后在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的说明,在页面上填写相关信息。
项目 |
说明 |
授权信息 |
请填写授权信息,请直接输入授权码 |
设备信息 |
请上传此前获取到的设备信息文件 |
用户信息 |
请填写您的用户信息,其中带“*”的项目必填 |
d. 请输入验证码并勾选“已阅读并同意法律声明所述服务条款各项内容”,再点击<获取激活码(文件)>按钮,请将生成的License文件保存到本地PC待用。
(2) License扩容激活申请
a. 访问网址http://www.h3c.com/cn/License,点击“License扩容激活申请”,进入“License扩容激活申请”页面。
b. 在“产品分类”中选择产品对应的类型(示例:大数据_DataEngine HDP)。
c. 请按照表7-2的说明,在页面上填写相关信息。
项目 |
说明 |
设备信息 |
请上传此前获取到的设备信息文件 |
授权信息 |
请填写授权信息,直接输入授权码 |
用户信息 |
请填写您的用户信息,其中带“*”的项目必填 |
d. 请输入验证码并勾选“已阅读并同意法律声明所述服务条款各项内容”,再点击<获取激活码(文件)>按钮,请将生成的License文件保存到本地PC待用。
获取授权的具体步骤如下:
(1) 登录License Server,点击[License/安装]菜单项,进入激活文件管理页面。单击<安装激活文件>按钮,在弹出的对话框中单击<浏览>按钮,选择保存在本地的License文件,然后单击<确定>按钮上传选中的License文件。上传成功后在激活文件管理页面会显示获取的授权信息。
(2) 在License Server上,单击[配置/客户端]菜单项,进入配置客户端页面,单击<增加客户端>按钮,填写客户端名称、客户端密码等信息,单击<确定>按钮后完成客户端的创建。
(3) 登录DataEngine Manager管理界面配置License,详情请参见7.2 在DataEngine Manager中配置License。
DataEngine成功连接到License Server的客户端后,DataEngine可以向License Server请求授权并将请求结果展示在页面上。
在H3C DataEngine Manager顶部导航栏[系统管理]的下拉框中选择<License管理>,进入License管理页面,如图7-2所示,License管理页面左侧显示“License配置”,页面右侧显示“License状态”,下面对这两部分进行详细介绍。
License配置栏显示连接的License Server 客户端的配置信息,DataEngine通过这些配置信息连接到对应的License Server客户端。
点击License配置右上方<编辑>按钮,用户可编辑License配置信息。填写所要连接的License Server客户端的用户名、密码、IP地址(License Server客户端所在主机的IP地址)和端口(License Server的服务端口号,默认为“5555”)后,点击<保存>,即可连接到相应客户端自动获取授权信息。
· License配置时填写的用户名和密码必须为步骤7.1 3. (2)中创建的客户端的名称和密码。
· 点击<保存>后,若无法连接到License Server,会弹出错误提示信息,此时则需要检查输入是否正确或者License Server服务是否正常运行。
License状态显示当前的集群已安装及已获取授权的主机情况。
· 安装主机数:指集群中已安装的主机总数。
· 授权主机数:指DataEngine已从License Server获取授权的主机个数。
DataEngine中所有主机需要经过License授权才能使用,如果DataEngine集群中安装主机数大于授权主机数,则授权无法成功。
· 当DataEngine集群中某个节点的全部服务都处于心跳丢失状态时,请联系管理员或相关技术人员处理该节点服务器的问题,请勿在此期间对该节点上安装的服务或组件执行卸载或强制卸载操作。
· 可执行卸载操作的用户包括:root用户和所有被赋予权限的非root用户。
对于服务卸载,分为单服务整体卸载和单服务单组件卸载两种方式。如果服务本身包含服务端,在卸载之前需要先停止服务;如果服务全为客户端,则可以直接卸载。例如卸载HBase服务需要先停止服务,而卸载Tez客户端则可直接卸载。
若集群中安装了Zookeeper服务,卸载其他服务(Zookeeper除外)时,为防止卸载失败要求所有节点上的ZooKeeper均处于正常运行状态。
单服务整体卸载指针对某个服务的完整卸载,包括卸载此服务在所有节点上的组件。
单服务整体卸载时,需要考虑各服务之间的依赖关系,例如:HBase依赖Zookeeper和HDFS,因此卸载Zookeeper或者HDFS时需要首先卸载HBase。更多的服务依赖关系请参见表2-6集群中服务部署规划。
下面以HBase举例,说明单服务整体卸载的方法。
(1) 在DataEngine Manager顶部导航栏中[服务]的下拉菜单,选择[HBase]进入。
(2) 在HBase服务页面右上角的[服务操作]下拉菜单中选择<停止>。根据需要在弹出的确认框中可以选择是否为HBase开启维护模式。
(3) 待服务停止操作完成后,在[服务操作]下拉菜单中选择<卸载HBASE>,弹出卸载服务向导,如图8-1所示。卸载向导分为以下三个步骤:
a. 卸载概要,提示执行卸载操作的用户、执行卸载操作所在集群名称、待卸载的服务名称。
b. 确认卸载,卸载操作不可逆,提示输入delete进行卸载确认。
c. 卸载进度,显示卸载过程的整体进度。执行结束后,点击<完成>按钮,关闭卸载向导。
单服务单组件卸载指针对某个服务的某个组件的卸载,目前DataEngine Manager尚未支持所有服务的单组件卸载,如果某组件的操作中包含删除选项即认为是支持,否则不支持,具体请以实际界面为准。下面以卸载Storm服务的Supervisor组件举例,说明单服务单组件卸载的方法。
(1) 在DataEngine Manager顶部导航栏中[服务]的下拉菜单,选择[Storm]进入。
(2) 在Storm服务的概要页面,点击Supervisor(监管者)的链接,进入某主机上的服务列表。
(3) 在服务列表找到Supervisor组件,在组件的对应操作下拉框中先点击<停止>,停止成功后点击<删除>即可完成Supervisor组件的卸载,如图8-2所示。
图8-2 Storm的Supervisor组件卸载
对处于异常状态下的服务,可以进行强制卸载。下面以HBase举例,说明服务强制卸载的方法。
(1) 关闭HBase中处于启动状态的组件(若待卸载的异常服务中所有组件都处于异常或停止状态,跳过此步骤)
a. 在DataEngine Manager顶部导航栏中[服务]的下拉菜单,选择[HBase]进入。
b. 在HBase服务页面的概要栏查看HBase服务组件的状态。点击处于正常启动状态的组件名称进入对应主机,在主机的组件列表中找到该组件后点击<停止>。
c. 依照上述步骤,手动停止待卸载的异常服务HBase所有处于正常启动状态的组件。
(2) 执行完上述步骤以后,对异常服务进行强制卸载。
a. 在DataEngine Manager顶部导航栏中[服务]的下拉菜单,选择[HBase]进入。
b. 在HBase服务页面右上角的[服务操作]下拉菜单中选择“卸载HBase”,弹出卸载服务向导。卸载向导分为以下三个步骤:
- 卸载概要,强制卸载时需要点击<执行脚本>按钮,执行强制卸载脚本,如图8-3所示。同时页面会提示执行卸载操作的用户、执行卸载操作所在集群名称、待卸载的服务名称。
- 确认卸载,卸载操作不可逆,提示输入delete进行卸载确认。
- 卸载进度,显示卸载过程的整体进度。执行结束后,点击<完成>按钮,关闭卸载向导。
· 在生产环境中,卸载集群为高危操作,会删除集群中所有的服务和数据,且不可回退或暂停,请务必谨慎使用。
· 执行卸载集群操作前,请务必确认以下信息:集群IP、节点root及root密码、集群是否已配置免密机制、集群内服务状态是否处于停止状态、集群内所有数据是否需要删除、集群内业务数据是否已完成备份等。
· 若集群配置免密机制,则会使主机用户密码确认功能失效(比如:卸载集群时,输入错误的root用户密码依然可以卸载成功),请务必谨慎配置。
· 若集群执行了10 7. 如何修改HDP集群的主机IP地址?的操作,卸载集群功能将不可用。
对于集群卸载,卸载过程会对整体DataEngine Manager管理界面和DataEngine集群进行全部卸载。卸载步骤如下:
(1) 登录DataEngine集群主管理节点,在安装路径下,执行以下命令:
./uninstall.sh
卸载执行过程中,会出现相关的询问信息,请根据提示输入信息后继续执行。
(2) 卸载成功后,恢复到集群安装前的状态,此时在解压文件夹下执行./install.sh即可重新启动安装。
· DataEngine扩展包提供DataEngine平台支持的其他扩展服务,比如MPP2、Neo4j、Janusgraph等,关于MPP2集群的部署详情请参见部署MPP2集群。
· 部署DataEngine扩展包之前,必须已完成DataEngine Manager的部署。
安装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集群(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 |
当非管理节点出现不可修复故障时,为不影响原集群的运行,可将相同操作系统和IP的新节点重新添加进原集群,步骤如下:
(1) 检查集群节点的相关信息,包括:
a. 确认集群管理节点所有功能正常可用,包括:ambari-server、对应数据库功能、软件源功能、http服务器中共享文件可用性等。
b. 确认故障节点状态信息处于心跳丢失状态(原故障节点已隔离,新节点未接入集群建立心跳)。
c. 确认新添加进集群的节点(故障节点的替换节点)的操作系统、IP等严格与故障节点保持一致,且干净未安装任何冲突软件、未进行配置设置且网络功能正常。
(2) 若检查集群节点状态均满足要求,可启动安装,步骤如下:
a. 登录集群当前可用的管理节点,进入安装路径下,执行以下命令:
./install_agent.sh install <节点IP> <用户名> <密码>
其中:节点IP为新添加节点的IP,用户名为新添加节点的主机用户名(与原集群用户保持一致),密码为用户密码。
b. 新节点安装完成后,登录DataEngine Manager管理界面,查看该节点对应的心跳状态是否恢复正常,如已恢复,说明新节点添加成功。
新节点添加成功后,原故障节点的状态信息仍保存在集群管理节点中,此时可能导致:
· 部分服务操作异常,譬如组件安装等,请针对现场实际情况进行处理。
· 对于原节点上安装的服务组件,原安装组件可能显示“安装失败”情况,此时可重新部署,并手动启动。
当集群管理节点有一个出现不可修复故障时,为不影响原集群管理节点的高可靠,可重新添加一个新节点启动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状态章节进行检查。
对于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)。
· 查看Manager HA状态时,可能会看到之前监测到的某些资源Fail action的记录,所以当其它状态正常时,可运行crm resource cleanup {资源名字}(非root用户下需要在命令前添加sudo),清空历史记录。
· 重新开启Manager HA的过程中会重启ambari-server,所以请确保开启Manager HA时,Manager中没有正在运行的任务。
根据现场磁盘分区方案和挂盘方案的不同,或若管理节点(Manager节点)单独为PostgreSQL(内置)划分了分区时,在添加服务向导的定制服务步骤,必须按照表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 |
此目录为数据目录,检查此配置项的值时,需关注: · 不允许存在非数据目录 · 若现场数据目录是自定义的,则需要配置为对应的数据目录 |
DataEngine集群中各节点时间不同步时,可能会导致启用Kerberos失败,此时需要手动进行时间同步后,再次启用Kerberos。设置DataEngine集群时间同步的方法如下:
(1) 查看告警“DataEngine Agent NTP Service Status”,查找告警时间不同步的节点。
(2) 登录出现告警的节点,设置此节点时间与集群管理节点同步,命令如下:
ntpdate -u <masternodeIP>
hwclock –systohc
其中:masternodeIP为DataEngine集群主管理节点IP。
HDP集群部署完成后,若因机房迁移等原因网络发生变化时,可以修改集群中各主机的IP地址。
· 若执行了修改HDP集群的主机IP地址的操作,则8.2 卸载集群功能(包括卸载整体集群和单节点整体卸载)将不可用。
· 修改主机IP功能仅支持DataEngine Manager服务,不支持MPP1、MPP2服务,其他服务可能需要手动修改配置或重启等操作,请根据实际情况进行处理。
· 请确认集群中需要修改IP的节点。
· 请确认集群中需要修改IP的节点在修改前的原IP地址和修改后的目标IP地址。
· 执行修改IP的操作时,必须保证主机在初始化时不能绑定IP,否则修改操作无法成功。
HDP集群中各主机节点IP修改步骤如下:
(1) 通过服务器root用户/密码分别登录集群中待修改IP的各节点,在各节点上均执行以下操作:
a. 进入/etc/sysconfig/network-scripts/目录下,打开对应文件(一般为ifcfg-eth0,请以服务器实际网卡配置为准),修改节点IP地址。如图10-1所示,将ipaddr的参数值修改为待更换的目标IP地址。
b. 保存修改后,重启网络服务,命令如下:
service network restart
c. 重启修改IP的节点,使其上的服务处于异常状态。
集群中所有需要修改IP地址的节点上,均需要执行以上步骤。
(2) 通过服务器root用户/密码登录集群Manager管理节点(若管理节点IP修改了,请使用修改后的IP登录管理节点),进入/opt/DataEngine-<version>-Basic目录下,依次执行以下操作:
a. 进入/conf文件夹,修改配置文件change_ips.conf。如图10-2所示,修改IP格式为“源IP地址,目标IP地址”。
b. 保存修改后,运行IP修改脚本,命令如下:
./ change_ips.sh
【说明】IP修改脚本运行时,根据提示需要输入Local IP(指当前主管理节点IP),脚本运行结束后,修改IP的节点上的所有服务将自动恢复至正常状态。
· 运行IP修改脚本前,请务必保证change_ips.conf文件里的IP信息,必须为集群所有节点的IP信息(且必须包含virtual IP)。若前期已使用该配置文件修改过其他IP,请务必删除前期修改时的相关IP信息,否则会因IP地址冲突,造成修改IP脚本运行失败。
· 使用change_ips.conf文件,可以批量为集群中节点更改IP地址,可更改IP包括Manager的虚拟IP、Manager主备节点IP和HDP集群中的其他节点IP。
· 如果只选择了一个节点安装Redis,则为单机模式。
· 如果选择了3个或3个以上节点安装Redis,则为集群模式。
Redis安装不能选择2个节点。
表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) |
可能原因及解决方法:
(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版本的变化。
(1) 可能原因
Metrics服务部分采集信息是存储在内置的PostgreSQL中,所以当集群与PostgreSQL的配置不匹配时,会造成Metrics服务获取集群信息时阻塞,此时内置PostgreSQL需要根据集群进行优化。
(2) 解决方法
修改配置文件/var/lib/pgsql/9.4/data/postgresql.conf,推荐优化配置如表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 |
(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内核参数的调优方法请参考官网。
表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压力会过大 |
· 在DataEngine中安装ElasticSearch时,缺省没有配置master和data,此时所有节点既可以做master,又可以做data,即master节点通过ElasticSearch自身的选举机制产生。
· ElasticSearch client作为任务分发的节点,内部会保存元数据,但是它不会对元数据做任何修改。配置client时可以为data节点减轻一部分查询压力,对ElasticSearch内部请求做负载均衡,一般在集群规模(30以上)和数据规模较大时才单独配置。
部署全文检索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节点)。
(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
示例:以CentOS 6.5为例,可查看源文件所在路径为:/etc/yum.repos.d/。
检查步骤如下:
(1) 文件内容是否与管理节点(Manager节点)对应源文件一致。
(2) 若不一致,请重置为一致,然后使用如下命令重置yum源:
yum clean all
【说明】:其他操作系统下,请联系H3C技术支持工程师。
解决方法:因Spark2的Thrift JDBC/ODBC Serve进程或Sparrow的SparrowThriftServer进程默认会持续占用YARN资源,导致YARN资源剩余过少,所以此种情况发生时,可根据实际情况手动kill这两种进程之后再运行其他服务。
DataEngine集群开启安全模式时,KDC端口号缺省为88,Kadmin端口号缺省为749,KDC和Kadmin的端口号均支持自定义更改。
根据DataEngine集群是否已开启安全模式的场景和操作方式的不同,Kerberos端口号更改方式分为以下四种情况:
· DataEngine集群已开启安全模式时
¡ 通过脚本更改Kerberos端口号
¡ 手动更改Kerberos端口号
· DataEngine集群未开启安全模式时
¡ 通过脚本更改Kerberos端口号
¡ 手动更改Kerberos端口号
· DataEngine集群开启安全模式时,若需要更改KDC和Kadmin的端口号,请提前规划,要求:(1)新规划的KDC和Kadmin的端口号要求不能与其他服务的端口号冲突;(2)Linux系统支持的端口号范围一般为“1-65535”,请在Linux系统支持的端口号范围内进行选择。
· 更改Kerberos端口号时,必须严格按照11.1.1 DataEngine集群未开启安全模式和11.1.2 DataEngine集群已开启安全模式章节给出的步骤进行操作,顺序不能调整。
· Kerberos端口号更改功能适用于CentOS系列和RedHat系列操作系统的DataEngine集群。
· 通过脚本更改Kerberos端口号时,脚本仅支持修改后台的相关配置,Manager管理界面的相关配置仍需要手动修改。关于相关脚本请联系H3C技术支持工程师获取。
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启用即可。
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端口是否更改成功
Kerberos端口更改完成后,若Manager界面显示某些服务关闭,请根据页面提示进行重启即可。
可执行更改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
· 修改Kerberos端口号时,当前版本需要使用三个脚本,分别为:change_kerberos_ip.sh、change_kerberos_ip_next.sh和change_kerberos_ip.py,相关脚本请联系H3C技术支持工程师获取。
通过脚本更改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目录下
DataEngine Mananger管理节点缺省已开启HA,通过脚本更改Kerberos端口号时,仅需要在当前处于active状态的管理节点上执行脚本即可。
(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端口号,用户名为执行此操作的用户,密码为对应用户密码。
更改Kerberos端口号的过程中,会出现相关的询问信息,请根据提示输入信息后继续执行。
图11-5 示例:通过root用户将KDC端口号修改为21701,将Kadmin端口号修改为21702
(5) 查看KDC端口号和Kadmin端口号修改是否成功,命令如下:
./change_kerberos_ip.sh status
图11-6 查看Kerberos的端口号是否修改成功
手动更改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:端口号”。
¡ 修改/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文件中
将KDC和Kadmin服务端口号添加至/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的端口号是否修改成功
· MPP2服务在DataEngine扩展包中,部署MPP2集群之前必须已完成DataEngine基础包和扩展包的安装。
· 在实际部署环境中,MPP2集群要求至少部署在3个节点上。
· 部署MPP2集群前,需要提前准备License,并重新其命名为vlicense.dat。在3 部署DataEngine Manager之前必须将其上传到/opt/DataEngine-<version>-Basic/packages/support/mpp2/目录下。
· 可部署MPP2集群的用户包括:root用户和所有被赋予权限的非root用户。所有用户在部署MPP2集群时,均需要参见3.1 2. 操作用户权限设置章节,配置/etc/sudoers文件,包括:1)在/etc/sudoers文件末增加一行dbadmin ALL=(ALL) NOPASSWD:ALL;2)当/etc/sudoer文件中存在requiretty时,需要使用#Defaults requiretty来注释掉requiretty。
· MPP2集群中每个节点至少需要2G的Swap分区。
· 用户ID(UID)和用户组ID(GID) 3032不能被占用。
· 目前MPP2集群支持部署在CentOS 6.8/7.3和RedHat 6.8/7.3的系统上,推荐使用CentOS 6.8/RedHat6.8。
MPP2集群规划机架时需要遵循以下原则:
集群中的所有节点建议要放置在不同的机架上。如果物理资源较少,则必须满足在不同的服务器节点上。
· 在部署过程中,MPP2集群中每个节点的地位是一样的,尽量保持各个节点配置信息的一致性。
· MPP2集群建议部署在同一个子网中,集群内通过汇聚交换机互联。
· 为使MPP2集群性能最优,推荐服务器硬件满足表11-1所示要求。
· 硬件可根据实际情况进行调整,详情请咨询H3C技术支持工程师。
表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个万兆网口 |
磁盘分区规划如下:
· 操作系统盘:OS盘,存在于所有节点,用来存放各节点操作系统,有固定的分区要求。
【注意】:如果安装操作系统时不修改默认分区配置,后续容易造成系统磁盘空间不足的问题,例如/var/log可能会占满系统分区等。
· MPP2中每个Server节点之间都是对等的关系,因此在磁盘挂载过程中,应保持一致。
· 一个分区可以单独占用一个磁盘也可以是某个磁盘的一部分。当资源允许每个分区对应一个磁盘时,建议单独占用磁盘;当资源受限时,也必须要保证独立分区,以减少服务数据彼此之间的影响。
仅DataEngine Manager管理节点需根据实际情况单独为PostgreSQL(内置)划分分区,其他节点不需要创建此分区。
硬盘容量(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集群的数据目录 |
MPP2是多主的架构,每个节点的地位是相同的,可以理解为都是数据节点,在节点规划上相对比较简单。
图11-13 MPP2集群节点规划
节点类型 |
服务/组件 |
说明 |
数据节点 |
MPP2 Sever |
每个Server地位相同,需要保持一致 |
图11-14 MPP高可靠方案配置说明
组件名称 |
配置说明 |
说明 |
MPP2 |
可以通过配置ksafety值,决定数据副本的多少,默认为1,表示数据有一份数据备份 |
一个集群中ksafety的最大值与节点数之间的关系为:2*ksafety+1=节点数。 例如:三个节点的集群,ksafety最大为1,五个节点的集群,ksafety最大为2 |
详情请参见3 部署DataEngine Manager章节。
首次登录DataEngine Manager后,提示部署集群,如图11-15所示,点击<进入安装向导>即可进入创建集群向导页面。
部署MPP2集群的操作步骤如下:
(1) 进入[开始]页面,输入集群名称后,点击<下一步>。
图11-16 集群名称
(2) 进入[选择版本]页面,可以展开高级选项查看安装rpm源地址。然后,点击<下一步>。
图11-17 选择版本
(3) 进入[安装选项]页面,输入集群各节点主机名,默认自动填充。然后,点击<注册并确认>。
图11-18 输入集群各节点主机名
(4) 进入[确认主机]页面,等待DataEngine对所有节点(本文以部署3节点的MPP2集群示例)进行注册并检查,出现图11-19所示后,点击<下一步>。
(5) 进入[选择服务]页面,选择安装MPP2服务,选择默认Metrics服务。然后,点击<下一步>。
图11-20 选择服务
(6) 进入[分配Master服务]页面,可以在下拉框中为已勾选服务内组件及客户端的安装,选择对应节点,然后,点击<下一步>。
图11-21 指定主服务
在分配Master服务时,至少需要添加三台MPP2 Server。
(7) 进入[分配Slave和Client]页面,可以自定义分配MPP2集群的Client(此时Client指MPP2 Client,即MPP2的客户端)。然后,点击<下一步>。
图11-22 分配Client
建议在未安装MPP2 Server的服务器节点上安装Client。
(8) 进入[定制服务]页面,此时需要根据集群实际情况,手动修改以下两个MPP2的配置项:
¡ mpp2.database.passwd配置项,用来配置默认数据库H3C_Database的密码,该密码在后续执行登录数据库或者修改数据库等操作时会用到,需要手动填入。
¡ 配置项Super user passwd,用于设置服务器数据库用户(dbadmin)的密码,需要手动填入。
图11-23 定制服务
· 除mpp2.database.passwd和Super user passwd配置项外,建议不要修改其他配置项参数,因为对配置项进行错误的修改会直接导致MPP2部署失败。
· 由于Vertica内部限制,mpp2.database.passwd配置密码不支持包含单引号或双引号的密码,且长度不能超过32个字符。
· mpp2.database.name默认是H3C_Database(支持修改),数据库命名规则为:长度不能超过30个字符,以字母开头,且仅支持字母(大小写)、数字、下划线。
· mpp2.data.path默认是/opt/vertica/data(不建议修改),因为磁盘挂载在/opt/vertica下,所以路径必须在该目录下。
· 此步骤点击<下一步>,可能会弹出关于服务配置的提示框,提示“有些服务配置不正确,建议检查和修改高亮配置项的值,是否继续下一步?”,此时可点击<继续>跳转至下一步(不影响集群部署);也可点击<取消>返回上一步进行配置参数的重新调整。
(9) 进入[检查]页面,需要进行MPP2集群部署前的最后检查,确认无误后点击<部署>按钮开始部署。
图11-24 检查信息
(10) 进入[安装、启动和测试]页面,安装过程中会显示每个节点安装的详细进度,如图11-25所示,点击各节点上的消息可以查看安装详情。待安装结束后,点击<下一步>。
(11) 进入[概要]页面可查看安装结果和详情,点击<完成>按钮即可进入DataEngine Manager的主页。
本章节主要介绍“导入并连接到数据库”部分,关于更多信息和H3C Management Console界面中的具体含义说明,详情请参见官网https://www.vertica.com/docs/9.1.x/PDF/Vertica_9.1.x_Complete_Documentation.pdf。
添加MPP2 Management Console的操作步骤如下:
(1) 在顶部导航栏中[服务]的下拉框,选择MPP2服务进入其管理配置界面,然后在右上角[快速链接]的下拉框中,选择任一节点对应的MPP2 MC UI,进入是否同意License协议页面,如图11-26所示。
MPP2集群中每个节点都安装了Management Console,在设置过程中,只需要设置其中的任意一个,其它的作为灾备。每个节点的Management Console设置过程是相同的。
(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所示的登录页面。
(5) 进入登录Management Console页面,输入步骤2设置的登录Management Console密码,进入Management Console的主页面。
图11-31 Management Console主页面
(6) 在Management Console主页面,点击<Import a Vertica Database Cluster>按钮,导入默认创建的数据库集群。在图11-32所示页面中输入集群中任意一台服务器的IP地址。然后,点击<Next>。
(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中。
(9) 导入数据库集群完成之后,页面会自动定向到如图11-35所示页面。点击左侧“Database”页签,会弹出展示集群信息的对话框,点击<View>按钮。
(10) 点击<View>按钮,可查看集群的整体信息。
图11-36 集群信息展示
不同款型规格的资料略有差异, 详细信息请向具体销售和400咨询。H3C保留在没有任何通知或提示的情况下对资料内容进行修改的权利!