最近在折騰hadoop+kerberos,由於線上使用的元件比較多,遇到不少問題,記錄下來,碰到同樣問題的同學可以參考下。
在hdfs+mapred+kerberos執行正常後,開始嘗試整合impala.
其中statestore的引數:
export IMPALA_STATE_STORE_ARGS=${IMPALA_STATE_STORE_ARGS:- -log_dir=${IMPALA_LOG_DIR} 
    -state_store_port=${IMPALA_STATE_STORE_PORT} -kerberos_reinit_interval=60 -principal=impala/xxxxxx@KERBEROS_HADOOP -keytab_file=/etc/impala/conf.dist/impala.keytab}
impala-server的引數:
export IMPALA_SERVER_ARGS=${IMPALA_SERVER_ARGS:- -log_dir=${IMPALA_LOG_DIR} 
  -state_store_port=${IMPALA_STATE_STORE_PORT} -use_statestore -state_store_host=${IMPALA_STATE_STORE_HOST} 
  -be_port=${IMPALA_BACKEND_PORT} -statestore_subscriber_timeout_seconds=${STATESTORE_SUBSCRIBER_TIMEOUT_SECONDS} -mem_limit=50% 
    -kerberos_reinit_interval=60 -principal=impala/xxxxx@KERBEROS_HADOOP -keytab_file=/etc/impala/conf.dist/impala.keytab}

啟動statestore沒有異常,因為在impala 1.1.1版本中,statestore只是做一個監控impala-server程式的作用,不涉及和hadoop的通訊,而在啟動impala-server時,發現程式執行一段時間之後就會crash,通過設定impala的日誌級別export GLOG_v=3,可以在日誌中觀察到下面的錯誤:

E0305 17:29:06.696974 12551 UserGroupInformation.java:1411] PriviledgedActionException as:impala/datanode@KERBEROS_HADOOP (auth:KERBEROS)
cause:java.io.IOException: Couldn`t setup connection for impala/gd6g12s103-hadooptest-datanode.idc.vipshop.com@KERBEROS_HADOOP to hdfs/namenode@KERBEROS_HADOOP
E0305 17:29:06.699252 12551 impala-server.cc:339] Could not read the HDFS root directory at hdfs://bipcluster. Error was:
Failed on local exception: java.io.IOException: Couldn`t setup connection for impala/gdatanode@KERBEROS_HADOOP to
hdfs/namenode@KERBEROS_HADOOP; Host Details : local host is: "datanode/ip";
destination host is: "namenode":8020;
E0305 17:29:06.699296 12551 impala-server.cc:341] Aborting Impala Server startup due to improper configuration

可以看到確實再用kerbers做驗證登陸,但是在datanode和namenode通訊時出現錯誤,因為線上用了namenode的ha,在日誌中發現有ha的報錯,因為懷疑是ha的問題,在關閉ha後,問題仍然存在。
日誌中還有tgt相關的報錯:
Caused by: javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt)]
但是手動通過kinit驗證,是可以獲取tgt的,說明tgt的驗證是ok的。
在datanode端,執行hadoop fs -ls 的命令時,報錯。通過export HADOOP_ROOT_LOGGER=DEBUG,console 設定hadoop命令的日誌級別,發現也是同樣報了tgt相關的錯誤。
在通過klist檢視tgt的cache,發現tgt竟然過期了,而且不能進行kinit -R.
klist
Ticket cache: FILE:/tmp/krb5cc_501
Default principal: hdfs/namenode@KERBEROS_HADOOP
Valid starting     Expires            Service principal
03/11/14 18:45:52  03/12/14 18:45:52  krbtgt/KERBEROS_HADOOP@KERBEROS_HADOOP
        renew until 03/11/14 18:45:56
這是由於renew expires導致,kerberos中有兩個時間比較重要:
max_list,tgt的有效時間,max_renewable_life ,renew的時間,在max_renewable_life 時間內,過期的tgt可以renew,如果時間超過max_renewable_life就不能renew了。。
檢視線上的設定:
max_life = 25h
max_renewable_life = 4w
而實際renew 的最大時間卻是4s(03/11/14 18:45:56-03/11/14 18:45:52),看來w不是week的意思。。不知道算不算bug,修正下,改成30d,重新kinit,就正常了。。
後面如果報Kerberos: Couldn`t find mech GSSAPI 說明是cyrus-sasl-gssapi的相關包沒有安裝。
啟動正常後驗證:
impala-shell -i  ip -k  -s impala
Starting Impala Shell in secure mode (using Kerberos)
[10.19.111.106:21000] > use cdnlog;
Query: use cdnlog
[10.19.111.106:21000] > select count(1) from dd_log;
Query: select count(1) from dd_log
Query finished, fetching results ...
+----------+
| count(1) |
+----------+
| 5000000  |
+----------+
可以看到已經正常跑了,自己對kerberos的瞭解還是太少了,在解決kerberos的相關問題的時候,第一步就應該用klist驗證。。