Метахранилище Hive страдает от ошибки Kerberos Clock skew too big

В последнее время мы сталкиваемся с проблемой, как описано в заголовке один раз в месяц. На узле хранилища метаданных мы установили и запустили службу ntpd для синхронизации времени с сервером kerberos. krb5.conf на узле выглядит так:

[libdefaults]
default_realm = EXAMPLE.COM
dns_lookup_realm = true
dns_lookup_kdc = true
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true

Таким образом, маловероятно, что время в хранилище метаданных не синхронизировано с сервером kerberos (>=5 минут) в результате проблемы или из-за сетевой блокировки.
Судя по журналу хранилища метаданных, регистрируется исключение "Слишком большой перекос часов". время вышло из строя, например,

2016-01-16 18:18:48,071 ОШИБКА [pool-3-thread-63735]
2016-01-16 19:07:03,699 ОШИБКА [pool-3-thread-63798]
2016- 01-16 19:06:55,998 ОШИБКА [pool-3-thread-63796]
2016-01-16 19:06:41,653 ОШИБКА [pool-3-thread-63812]
2016-01- 16 19:04:28,659 ОШИБКА [pool-3-thread-63806]
2016-01-16 19:04:13,937 ОШИБКА [pool-3-thread-63804]
2016-01-16 19 :02:19,312 ОШИБКА [pool-3-thread-63809]
2016-01-16 19:02:13,115 ОШИБКА [pool-3-thread-63794]
2016-01-16 19:02 :06,028 ОШИБКА [pool-3-thread-63800]
2016-01-16 19:01:50,767 ОШИБКА [pool-3-thread-63795]
2016-01-16 18:59:36,926 ОШИБКА [pool-3-thread-63810]
2016-01-16 18:59:36,394 ОШИБКА [pool-3-thread-63797]

Стек исключений:

2016-01-16 18:59:36,394 ERROR [pool-3-thread-63797]: transport.TSaslTransport (TSaslTransport.java:open(296)) - SASL negotiation failure
javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: Failure unspecified at GSS-API level (Mechanism level: Clock skew too great (37))]
        at com.sun.security.sasl.gsskerb.GssKrb5Server.evaluateResponse(GssKrb5Server.java:177)
        at org.apache.thrift.transport.TSaslTransport$SaslParticipant.evaluateChallengeOrResponse(TSaslTransport.java:509)
        at org.apache.thrift.transport.TSaslTransport.open(TSaslTransport.java:264)
        at org.apache.thrift.transport.TSaslServerTransport.open(TSaslServerTransport.java:41)
        at org.apache.hadoop.hive.thrift.HadoopThriftAuthBridge$HiveSaslServerTransportFactory.getTransport(HadoopThriftAuthBridge.java:172)
        at org.apache.hadoop.hive.thrift.HadoopThriftAuthBridge20S$Server$TUGIAssumingTransportFactory$1.run(HadoopThriftAuthBridge20S.java:678)
        at org.apache.hadoop.hive.thrift.HadoopThriftAuthBridge20S$Server$TUGIAssumingTransportFactory$1.run(HadoopThriftAuthBridge20S.java:675)
        at java.security.AccessController.doPrivileged(Native Method)
        at javax.security.auth.Subject.doAs(Subject.java:356)
        at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1536)
        at org.apache.hadoop.hive.thrift.HadoopThriftAuthBridge20S$Server$TUGIAssumingTransportFactory.getTransport(HadoopThriftAuthBridge20S.java:675)
        at org.apache.thrift.server.TThreadPoolServer$WorkerProcess.run(TThreadPoolServer.java:189)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
        at java.lang.Thread.run(Thread.java:744)
Caused by: GSSException: Failure unspecified at GSS-API level (Mechanism level: Clock skew too great (37))
        at org.apache.thrift.transport.TSaslServerTransport.handleSaslStartMessage(TSaslServerTransport.java:125)
        at org.apache.thrift.transport.TSaslTransport.open(TSaslTransport.java:253)
        at org.apache.thrift.transport.TSaslServerTransport.open(TSaslServerTransport.java:41)
        at org.apache.hadoop.hive.thrift.HadoopThriftAuthBridge$HiveSaslServerTransportFactory.getTransport(HadoopThriftAuthBridge.java:172)  
        ... 10 more

среда:

 java version "1.7.0_45"
 Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)
 hive-0.13.1.2.1.10.0-hdp

Итак, что мне делать, если я хочу выяснить первопричину? Какие-либо предложения? Большое спасибо.


java hive kerberos metastore
person Dengzh    schedule 30.03.2016    source источник
comment
Вы пробовали везде синхронизировать время с NTP   -  person Konstantin V. Salikhov    schedule 30.03.2016
comment
Да, мы уже пробовали. Когда возникает исключение, оказывается, что хранилище метаданных слишком занято, чтобы ответить на запрос. Мы должны перезапустить его.   -  person Dengzh    schedule 30.03.2016
comment
Проверяли ли вы NecronoKerberoMicon, т.е. (на наличие распространенных сообщений об ошибках) steveloughran.gitbooks.io/ kerberos_and_hadoop/content/sections/ и (для отладки) steveloughran.gitbooks .io/kerberos_and_hadoop/content/sections/   -  person Samson Scharfrichter    schedule 30.03.2016
comment
Большое спасибо. Проверено из журнала метахранилищ, слишком большой перекос часов меня очень удивляет, это означает, что текущий запрос аутентификации содержит отметку времени на 5 минут позже или вперед по сравнению с сервером kerberos. К сожалению, мы пока не получили информацию об отладке kerberos, пока в следующий раз не возникнет та же проблема. Сейчас я пытаюсь выяснить потенциальные причины и воссоздать проблему.   -  person Dengzh    schedule 30.03.2016
comment
Спасибо @Konstantin V. Salikhov и Samson Scharfrichter, проблема может быть связана с тем, что некоторые другие пользователи кластера пытаются подключить хранилище метаданных.   -  person Dengzh    schedule 07.04.2016

Ответы (3)


arrow_upward
3
arrow_downward

Я тоже видел эту ошибку, и в моем случае основная причина не имела ничего общего с Kerberos. Если вы используете базу данных MySql в качестве хранилища данных, существует довольно серьезная утечка памяти, https://issues.apache.org/jira/browse/HIVE-15551, который был представлен в версии 0.13 и не исправлялся до версии Hive 1.3.0. По сути, тот, кто первоначально написал код, либо забыл, либо не понял, что вы должны явно закрывать операторы JDBC, и это приводит к чрезмерной сборке мусора, когда ваш процесс достигает своего предела памяти. Как только это происходит, все в процессе становится все медленнее, до такой степени, что вы начинаете видеть эти ошибки смещения часов.

Вы можете определить, является ли это вашей проблемой, запустив живую гистограмму jmap в процессе хранилища метаданных. Если вы видите объекты JDBC вверху списка (в моем случае это были com.mysql.jdbc.JDBC42ResultSet и com.mysql.jdbc.StatementImpl), скорее всего, вы столкнулись с этой проблемой. Я рекомендую вам либо применить исправление, либо обновиться до Hive 1.3.0, либо использовать обходной путь, упомянутый в проблеме, чтобы посмотреть, прояснит ли это ситуацию.

person Jeff X Mink    schedule 03.05.2017

arrow_upward
1
arrow_downward

Используйте команду kdestroy, а затем kinit.

Команда kdestroy уничтожает активные билеты авторизации Kerberos пользователя и удаляет содержащий их кэш учетных данных.

kinit используется для получения и кэширования билетов на выдачу билетов Kerberos.

Удаление кеша и повторное «кинирование» могут решить вашу проблему. Если кеша нет, kdestroy вернет «kdestroy: Кэш учетных данных не найден при уничтожении кеша».

Документацию по kdestroy можно найти здесь.

person Cena    schedule 15.08.2019

arrow_upward
0
arrow_downward

Запустите эту команду, чтобы синхронизировать ваши часы с KDC:

/sbin/служба ntpd стоп; /usr/sbin/ntpdate IP-адрес_сервера_KDC_server; /sbin/запуск службы ntpd

person utkarsh    schedule 30.01.2021