Улей metastore, страдающий от Kerberos "Ошибка перекоса часов"

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

[libdefaults]
default_realm = EXAMPLE.COM
dns_lookup_realm = true
dns_lookup_kdc = true
ticket_lifetime = 24 часа
renew_lifetime = 7 дней
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 ОШИБКА [pool-3-thread-63797]: transport.TSaslTransport (TSaslTransport.java:open(296)) - Ошибка согласования SASL
javax.security.sasl.SaslException: сбой инициализации GSS [вызвано GSSException: сбой не определен на уровне GSS-API (уровень механизма: слишком большой перекос часов (37))]
        в com.sun.security.sasl.gsskerb.GssKrb5Server.evaluateResponse(GssKrb5Server.java:177)
        в org.apache.thrift.transport.TSaslTransport$SaslParticipant.evaluateChallengeOrResponse(TSaslTransport.java:509)
        в org.apache.thrift.transport.TSaslTransport.open(TSaslTransport.java:264)
        в org.apache.thrift.transport.TSaslServerTransport.open(TSaslServerTransport.java:41)
        в org.apache.hadoop.hive.thrift.HadoopThriftAuthBridge$HiveSaslServerTransportFactory.getTransport(HadoopThriftAuthBridge.java:172)
        в org.apache.hadoop.hive.thrift.HadoopThriftAuthBridge20S$Server$TUGIAssumingTransportFactory$1.run(HadoopThriftAuthBridge20S.java:678)
        в org.apache.hadoop.hive.thrift.HadoopThriftAuthBridge20S$Server$TUGIAssumingTransportFactory$1.run(HadoopThriftAuthBridge20S.java:675)
        at java.security.AccessController.doPrivileged(собственный метод)
        at javax.security.auth.Subject.doAs(Subject.java:356)
        в org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1536)
        в org.apache.hadoop.hive.thrift.HadoopThriftAuthBridge20S$Server$TUGIAssumingTransportFactory.getTransport(HadoopThriftAuthBridge20S.java:675)
        в org.apache.thrift.server.TThreadPoolServer$WorkerProcess.run(TThreadPoolServer.java:189)
        в java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
        в java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
        на java.lang.Thread.run(Thread.java:744)
Вызвано: GSSException: ошибка не указана на уровне GSS-API (уровень механизма: слишком большой перекос часов (37))
        в org.apache.thrift.transport.TSaslServerTransport.handleSaslStartMessage(TSaslServerTransport.java:125)
        в org.apache.thrift.transport.TSaslTransport.open(TSaslTransport.java:253)
        в org.apache.thrift.transport.TSaslServerTransport.open(TSaslServerTransport.java:41)
        в org.apache.hadoop.hive.thrift.HadoopThriftAuthBridge$HiveSaslServerTransportFactory.getTransport(HadoopThriftAuthBridge.java:172)  
        ... еще 10

ENV:

 Java-версия "1.7.0_45"
 Java HotSpot(TM) 64-разрядная серверная виртуальная машина (сборка 24.51-b03, смешанный режим)
 Улей-0.13.1.2.1.10.0-HDP

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

Источник

3 ответа

Решение

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

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

Источник

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

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

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

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

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

Источник

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

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

Источник
Другие вопросы по тегам