Impala負載均衡方案

概述

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負載均衡

首先下載下傳haproxy：http://www.haproxy.org/download/1.6/src/haproxy-1.6.10.tar.gz，這裡下載下傳的源碼，安裝非常友善，使用如下指令：

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配置高可用服務的流程。