概述

Impala分為是三個元件，statestored/catalogd和impalad，其中statestored和catalogd是單點的，沒有高可用的需求，因為這兩個例項是無狀態的，本身不儲存任何資料，例如catalogd的資料儲存在第三方資料庫(例如mysql中)，statestore的資料全都儲存在記憶體中，可以通過簡單的主備的方式來實現高可用，本文最後會提到。正常情況下只有master提供服務，slave只是執行狀態但是不接受任何請求，當master出現問題之後再slave提升為master提供服務。

而對於impalad節點，每一個節點都可以提供jdbc和thrift等服務，並且對於連線到該impalad的查詢作為coordinator節點（需要消耗一定的記憶體和CPU）存在，為了保證每一個節點的負載的平衡需要對於這些impalad做一下均衡，負載均衡分為四層負載均衡和七層負載均衡，前者是針對運輸層的，後者是針對應用層的，區別在於前者不需要了解應用協議，只需要對傳輸層收到的IP資料包進行轉發，而後者需要了解應用協議的，而對於impalad這種SQL伺服器，就需要使用SQL協議的代理，所以七層代理對於impalad是有點不切實際的。

下面以haproxy作為四層代理伺服器來說明如何對impalad節點進行load balance。官方推薦的代理方案參見該文件。

除了本文件提到的使用 load-balancing proxy server外，最簡單的方案莫過於使用DNS做負載均衡，但是DNS的效能一般，所以這裡我們按照官方的建議使用haproxy實現四層的負載均衡，相對於通常的負載均衡的實現，這裡我們還需要拷貝kerberos的支援。

impalad負載均衡

make TARGET=generic

構建完成之後會在當前目錄下生成haproxy可執行檔案，然後關鍵的是對haproxy進行配置，可以參考如下配置檔案：

cat etc/haproxy.cfg
global
    log 127.0.0.1 local0
    uid 71488
    gid 1003
    deamon
    pidfile /path/to/haproxy/pid/haproxy.pid
    maxconn 65536

defaults
    backlog 2048
    balance roundrobin
    log global
    mode tcp
    stats enable
    stats refresh 5s
    retries 3
    timeout connect 120s
    timeout client 600s
    timeout server 600s

listen impala_ha
    bind 0.0.0.0:8006
    mode tcp 

    balance roundrobin
    server impala1 hadoop461.lt.server.org:21050 check
    server impala2 hadoop462.lt.server.org:21050 check
    server impala3 hadoop463.lt.server.org:21050 check
    server impala4 hadoop464.lt.server.org:21050 check
    server impala5 hadoop465.lt.server.org:21050 check
 

這裡只配置了一個負載均衡代理impala的hs2服務，監聽在本機的8006埠，代理模式為tcp，也就是四層代理，使用roundrobin的方式輪詢後端伺服器，這裡使用了五臺後端impalad節點，分別轉發到impalad的hive server服務，除了對這個服務進行負載均衡，還可以對其他的服務進行負載均衡，只需要新增一個listen配置就可以了。還需要注意的是uid和gid分別是當前的使用者id和組id。

配置好配置檔案之後，啟直接啟動haproxy：

./haproxy -f ./etc/haproxy.cfg 

此時haproxy如果沒出現什麼問題就會以daemon的方式啟動，此時通過beline或者jdbc程式碼就可以通過訪問haproxy_host:8006來訪問impala了。

kerberos配置

但是對於配置了kerberos認證的叢集，還需要額外的處理，因為對於開啟kerberos的impala使用的url格式為：jdbc:hive2://haproxy_host:8006/default;principal=impala/${hostname}@realm;而一般情況下不同的impalad節點使用相同的impala.keytab，但是使用不同的impala principal，例如 hadoop461.lt.server.org使用的principal是impala/[email protected]，而hadoop462.lt.server.org使用的principal是impala/[email protected]，由於在建立impala連線的時候只能在url中指定一個principal的配置，這樣就導致建立連線的時候會出現null異常（應該是空指標了）。

所以我們需要做的是如果將不同的impalad識別的principal設定成相同的，在impalad的引數中存在兩個關於principal的：-principal和-be_principal，前者設定的是外部連線使用的principal，也就是url中需要填的，後者是impalad和其它節點通訊使用的principal，因此可以通過如下的處理方式修改principal：

• 建立一個新的proxy.keytab，假設它的principal是proxy/[email protected]

• 執行如下操作分別將不同impalad使用的的impala.keytab合併成一個keytab，這樣使用同一個keytab可以對應兩個principal，分別是：proxy/[email protected]和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/[email protected]
  --keytab_file=path_to_proxy_impala.keytab
  

重新建立到proxy伺服器的jdbc連線，It works！

總結

最後，haproxy本身又是一個單點服務，可以在它之上再做一個高可用配置，類似於statestored和catalogd服務，他們的需求都是主備配置，所有的服務由主節點提供，當主節點掛了之後備節點提升為主節點服務，這種工作通常使用keepalived完成。

本文介紹了impala叢集所有服務的高可用方案，尤其是impalad配置高可用服務的流程。