Impala组件包含3
个子模块(Impala Catalog Server
、Impala StateStore
、Impala Daemon
),如图所示:
其中Impala Catalog Server
与Impala StateStore
是无数据
、无状态
的模块,没有高可用的需求更不需要做负载均衡;Impala Daemon
模块的每一个节点都可以提供jdbc和thrift服务(作为coordinator需要消耗CPU与内存等资源),为保证每个节点的资源消耗相差不大需要做资源的负载均衡。
Impala Catalog Server
,数据存储于 Oracle / MySQL 等第三方数据库。Impala StateStore
,是Impalad守护进程,数据全部缓存在 内存
中。若Impala集群中某个节点因为各种原因离线,Impala StateStore
会及时通知Impala集群其他节点,避免之后的查询会落到这些离线节点。Impala Daemon
,接收client、jdbc 或者odbc的请求,执行并返回给impalad子节点上的守护进程,负责向statestore 保持通信,汇报工作。请注意如下 4
点内容:
Impala Catalog Server
作为Impala组件的元数据网关,从Hive Metastore等外部catalog中获取元数据信息,放到impala自己的catalog结构中。当impalad执行命令时,通过catalogd由其代为执行,该更新则由statestored广播。
Impala StateStore
并不是必须的,它只是在Impala集群中有节点出错时才起作用,而如果Impala StateStore
未启动或者不能提供服务,并不影响Impala集群中其他节点正常工作,而Impala集群顶多是变得不可靠。当StateStore恢复在线,它将重建与其他节点的通讯,并恢复它的监控功能。
为提升impala组件的性能,将Impala Catalog Server
与Impala StateStore
安装到Hive Metastore
所在的同一个节点中,且该节点尽可能避免安装Impala Daemon
模块
负载均衡分为四层负载均衡和七层负载均衡,前者是针对运输层的,后者是针对应用层的。区别在于前者不需要了解应用协议,只需要对传输层收到的IP数据包进行转发,而后者需要了解应用协议的。对于Impala Daemon
的负债均衡,官方推荐使用四层负载均衡做数据包转发即可:官方说明
# 解压源码包
tar -xzvf haproxy-1.9.6.tar.gz
# 安装编译工具
yum install -y gcc make
# 查看操作系统内核
uname -r
# 查看安装说明
cat /root/haproxy-1.9.6/INSTALL
要构建haproxy,必须在上面操作系统中选择目标操作系统,并将其分配给TARGET变量: 我的内核是3.10.0,选择linux2628
# 切换至 haproxy 源文件根目录
cd /root/haproxy-1.9.6
# TARGET指定内核版本,ARCH指定CPU架构,PREFIX指haprxoy的安装路径
make TARGET=linux2628 ARCH=x86_64 prefix=/usr/local/haproxy
# 安装
make install PREFIX=/usr/local/haproxy
# 拷贝模板
cp -a /root/haproxy-1.9.6/examples /usr/local/haproxy/
# 新增配置及日志目录
mkdir -pv /usr/local/haproxy/{conf,logs}
mkdir -pv /etc/haproxy
mkdir -pv /usr/share/haproxy/
ln -s /usr/local/haproxy/conf/haproxy.cfg /etc/haproxy/haproxy.cfg
# 添加服务并做开机启动
cp /usr/local/haproxy/examples/haproxy.init /etc/init.d/haproxy
chmod 755 /etc/init.d/haproxy
chkconfig --level 2345 haproxy on
chkconfig --list haproxy
ln -s /usr/local/haproxy/sbin/haproxy /usr/sbin/haproxy
参照HAPROXY官网文档: HAPROXY官方文档
参照CLOUDERA官方文档:CLOUDERA官方文档
http为7层代理,tcp是4层代理,Impala Daemon
的负载均衡使用4层代理。
下面简述一下haproxy代理工具支持的 9 种算法:
算法 | 简介 |
---|---|
roundrobin | 基于权重进行轮叫,在服务器的处理时间保持均匀分布时,这是最平衡、最公平的算法。此算法是动态的,这表示其权重可以在运行时进行调整,不过,在设计上,每个后端服务器仅能最多接受4128个连接; |
static-rr | 基于权重进行轮叫,与roundrobin类似,但是为静态方法,在运行时调整其服务器权重不会生效;不过,其在后端服务器连接数上没有限制; |
leastconn | 新的连接请求被派发至具有最少连接数目的后端服务器;在有着较长时间会话的场景中推荐使用此算法,如LDAP、SQL等,其并不太适用于较短会话的应用层协议,如HTTP;此算法是动态的,可以在运行时调整其权重; |
first | 其会匹配server的id,id值设置低的先进行连接,直到达到该服务器的maxconn,再使用第二台。比较适用于RDP、IMAP、HTTP等长连接及云环境下; |
source | 将请求的源地址进行hash运算,并由后端服务器的权重总数相除后派发至某匹配的服务器;这可以使得同一个客户端IP的请求始终被派发至某特定的服务器;不过,当服务器权重总数发生变化时,如某服务器宕机或添加了新的服务器,许多客户端的请求可能会被派发至与此前请求不同的服务器;常用于负载均衡无cookie功能的基于TCP的协议;其默认为静态,不过也可以使用hash-type修改此特性; |
uri | 对URI的左半部分(“问题”标记之前的部分)或整个URI进行hash运算,并由服务器的总权重相除后派发至某匹配的服务器;这可以使得对同一个URI的请求总是被派发至某特定的服务器,除非服务器的权重总数发生了变化;此算法常用于代理缓存或反病毒代理以提高缓存的命中率;需要注意的是,此算法仅应用于HTTP后端服务器场景;其默认为静态算法,不过也可以使用hash-type修改此特性; |
uri-param | 通过为URL指定的参数在每个HTTP GET请求中将会被检索;如果找到了指定的参数且其通过等于号“=”被赋予了一个值,那么此值将被执行hash运算并被服务器的总权重相除后派发至某匹配的服务器;此算法可以通过追踪请求中的用户标识进而确保同一个用户ID的请求将被送往同一个特定的服务器,除非服务器的总权重发生了变化;如果某请求中没有出现指定的参数或其没有有效值,则使用轮叫算法对相应请求进行调度;此算法默认为静态的,不过其也可以使用hash-type修改此特性; |
hdr(name) | 对于每个HTTP请求,通过指定的HTTP首部将会被检索;如果相应的首部没有出现或其没有有效值,则使用轮叫算法对相应请求进行调度;其有一个可选选项“use_domain_only”,可在指定检索类似Host类的首部时仅计算域名部分(比如通过www.google.com来说,仅计算361way字符串的hash值)以降低hash算法的运算量;此算法默认为静态的,不过其也可以使用hash-type修改此特性; |
rdp-cookie | 其将looked up and hashed每个近入的TCP连接,并将该请求和之前的策略作匹配,这样对于同一个用户发来的请求,可以发往后端同一台realserver上,如果cookie not found,其将使用roundrobin 代替。 |
# 创建配置文件
vim /usr/local/haproxy/conf/haproxy.cfg
# 将如下配置内容写入配置文件,并保存
global
chroot /usr/share/haproxy
log 127.0.0.1 local0
log 127.0.0.1 local1 notice
pidfile /var/run/haproxy.pid
maxconn 4000
user haproxy
group haproxy
daemon
defaults
log global
mode http
retries 3
maxconn 3000
timeout connect 120s
timeout client 3600s
timeout server 3600s
listen stats
bind *:25002
mode http
stats enable
stats auth admin:admin123
stats uri /stats
listen impala_shell
bind *:25003
mode tcp
option tcplog
balance leastconn
server impala62 cdh62:21000 check
server impala63 cdh63:21000 check
server impala64 cdh64:21000 check
server impala65 cdh65:21000 check
listen impala_jdbc
bind *:25004
mode tcp
balance roundrobin
server impala62 cdh62:21050 check
server impala63 cdh63:21050 check
server impala64 cdh64:21050 check
server impala65 cdh65:21050 check
Nginx 和 Apache 均支持 include 加载多个配置文件,但是 Haproxy 不支持,若规则太多,则 haproxy.cfg 配置文件会非常臃肿,这种状况可以通过启动 haproxy 加入 -f 命令 来拼接配置文件解决,如下:
# 创建目录
mkdir -pv /usr/local/haproxy/conf/ready/{tcp,http}
mkdir -pv /usr/local/haproxy/conf/enabled/{tcp,http}
# 使用多配置文件方式启动haproxy
cd /usr/local/haproxy/sbin
./haproxy -f ../conf/haproxy.cfg -f ../conf/ext1.cfg -f ../conf/ext2.cfg
因此可以通过配置文件目录
以及启动脚本
的改变,完成方案的实现,例如约定路径如下:
待上线的 tcp 映射规则存放目录:/usr/local/haproxy/conf/ready/tcp
待上线的 http 映射规则存放目录:/usr/local/haproxy/conf/ready/http
已上线的 tcp 映射规则存放目录:/usr/local/haproxy/conf/enabled/tcp
已上线的 http 映射规则存放目录:/usr/local/haproxy/conf/enabled/http
Ps:enabled 里面的配置软链接至 ready 对应配置文件。
Errors found in configuration file, check it with 'haproxy check'
# Redhat6.X
service haproxy {start|stop|restart|status|test}
# Redhat7.X
systemctl {start|stop|restart|status|test} haproxy
# 新增haproxy用户
useradd haproxy
对于配置了kerberos认证的集群,还需要额外的处理,参照官方网址
开启kerberos的impala使用的url格式为:jdbc:hive2://haproxy_host:25004/default;principal=impala/${hostname}@realm;
一般情况下不同的impalad节点使用相同的impala.keytab,但是使用不同的impala principal,例如 cdh62使用的principal是impala/cdh62@realm,而cdh63使用的principal是impala/cdh63@realm,由于在创建impala连接的时候只能在url中指定一个principal的配置,这样就导致创建连接异常。需要做的是如果将不同的impalad识别的principal设置成相同的,在impalad的参数中存在两个关于principal的:-principal和-be_principal,前者设置的是外部连接使用的principal,也就是url中需要填的,后者是impalad和其它节点通信使用的principal,因此可以通过如下的处理方式修改principal:
ktutil
ktutil: rkt proxy.keytab
ktutil: rkt impala.keytab
ktutil: wkt proxy_impala.keytab
ktutil: quit
--principal=impala/${hostname}@realm
--be_principal=proxy/haproxy_host@realm
--keytab_file=path_to_proxy_impala.keytab