使用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 點內容：

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的負債均衡，官方推薦使用四層負載均衡做數據包轉發即可：官方說明

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完成。

使用haproxy做impala的負載均衡

1. IMPALA組件概述

2. 源碼下載與解壓

3. 編譯&服務控制

4. 修改HAPROXY配置

5. HAPROXY服務啓動

6. 異常

7. kerberos

8. 總結

MySQL性能分析之show processlist及information_schema.processlist

使用haproxy做impala的負載均衡

Jenkins 分佈式-管理節點

Yearning基於Inception的開源SQL審覈平臺

老男孩 - python基礎

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結