使用haproxy做impala的负载均衡

1. IMPALA组件概述

Impala组件包含3个子模块(Impala Catalog ServerImpala StateStoreImpala Daemon),如图所示:

在这里插入图片描述

在这里插入图片描述

其中Impala Catalog ServerImpala 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 ServerImpala StateStore安装到Hive Metastore所在的同一个节点中,且该节点尽可能避免安装Impala Daemon模块

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

2. 源码下载与解压

在这里插入图片描述

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完成。
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章