使用haproxy做impala的负载均衡

1. IMPALA组件概述

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 点内容：

1. Impala Catalog Server作为Impala组件的元数据网关，从Hive Metastore等外部catalog中获取元数据信息，放到impala自己的catalog结构中。当impalad执行命令时，通过catalogd由其代为执行，该更新则由statestored广播。

2. Impala StateStore并不是必须的，它只是在Impala集群中有节点出错时才起作用，而如果Impala StateStore未启动或者不能提供服务，并不影响Impala集群中其他节点正常工作，而Impala集群顶多是变得不可靠。当StateStore恢复在线，它将重建与其他节点的通讯，并恢复它的监控功能。

3. 为提升impala组件的性能，将Impala Catalog Server与Impala StateStore安装到Hive Metastore所在的同一个节点中，且该节点尽可能避免安装Impala Daemon模块

4. 负载均衡分为四层负载均衡和七层负载均衡，前者是针对运输层的，后者是针对应用层的。区别在于前者不需要了解应用协议，只需要对传输层收到的IP数据包进行转发，而后者需要了解应用协议的。对于Impala Daemon的负债均衡，官方推荐使用四层负载均衡做数据包转发即可：官方说明

2. 源码下载与解压

• 下载链接：http://www.haproxy.org/download/1.9/src/

3. 编译&服务控制

# 解压源码包
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

4. 修改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 对应配置文件。

5. HAPROXY服务启动

• 需要在***修改HAPROXY配置***后进行，否则报错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

6. 异常

• cannot find user id for ‘haproxy’

# 新增haproxy用户
useradd haproxy

7. kerberos

​ 对于配置了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：

• 创建一个新的proxy.keytab，假设它的principal是proxy/haproxy_host@realm.
• 执行如下操作分别将不同impalad使用的的impala.keytab合并成一个keytab，这样使用同一个keytab可以对应两个principal，分别是：proxy/haproxy_host@realm和impala/${hostname}@realm

ktutil 
ktutil:  rkt proxy.keytab 
ktutil:  rkt impala.keytab 
ktutil:  wkt proxy_impala.keytab
ktutil:  quit

• 然后将合并之后的proxy_impala.keytab分别拷贝到对应的impalad机器上，通常需要将其设置为400，只有当前用户可读，防止其他用户使用该keytab非法访问。
• 分别重启每一个impalad节点，使用如下的kerberos配置参数：

--principal=impala/${hostname}@realm
--be_principal=proxy/haproxy_host@realm
--keytab_file=path_to_proxy_impala.keytab

• 重新创建到proxy服务器的jdbc连接即可。

8. 总结

• haproxy 是一个单点服务，可以再做一个高可用配置，通常使用keepalived完成。