java - 我应该在对 hadoop 执行每个操作之前调用 ugi.checkTGTAndReloginFromKeytab() 吗？

Question

在我的服务器应用程序中，我从我的 Java 应用程序连接到 Kerberos 安全的 Hadoop 集群。我正在使用各种组件，如 HDFS 文件系统、Oozie、Hive 等。在应用程序启动时，我会调用

UserGroupInformation.loginUserFromKeytabAndReturnUGI( ... );

这让我返回 UserGroupInformation实例，我在应用程序生命周期内保留它。在执行特权操作时，我使用 ugi.doAs(action) 启动它们.

这工作正常，但我想知道我是否以及何时应该更新 UserGroupInformation 中的 kerberos 票证?我找到了一个方法 UserGroupInformation.checkTGTAndReloginFromKeytab()这似乎在接近到期时进行机票更新。我还发现此方法正在被各种 Hadoop 工具调用，例如 WebHdfsFileSystem例如。

现在，如果我希望我的服务器应用程序(可能运行数月甚至数年)永远不会遇到票证到期，最好的方法是什么？提供具体问题:

我可以依赖他们调用的各种 Hadoop 客户端吗checkTGTAndReloginFromKeytab什么时候需要？

我应该打电话吗checkTGTAndReloginFromKeytab我自己在我的代码中？

如果是这样，我应该在每次调用 ugi.doAs(...) 之前都这样做吗？或者更确切地说是设置一个计时器并定期调用它(多久一次)？

Answer 1

Hadoop 提交者在这里!这是一个很好的问题。

不幸的是，如果不深入了解应用程序的特定使用模式，就很难对此给出明确的答案。相反，我可以提供一般指南并描述 Hadoop 何时会自动为您处理票证续订或从 key 表重新登录，何时不会。

Hadoop 生态系统中 Kerberos 身份验证的主要用例是 Hadoop 的 RPC 框架，它使用 SASL 进行身份验证。 Hadoop 生态系统中的大多数守护进程通过一次性调用 UserGroupInformation#loginUserFromKeytab 来处理此问题。在进程启动时。这方面的示例包括 HDFS DataNode，它必须验证其对 NameNode 的 RPC 调用，以及 YARN NodeManager，它必须验证其对 ResourceManager 的调用。像 DataNode 这样的守护进程如何在进程启动时进行一次性登录，然后继续运行数月，远远超过典型的票证到期时间？

由于这是一个如此常见的用例，Hadoop 直接在 RPC 客户端层内部实现了自动重新登录机制。此代码在 RPC Client#handleSaslConnectionFailure 中可见方法:

          // try re-login
          if (UserGroupInformation.isLoginKeytabBased()) {
            UserGroupInformation.getLoginUser().reloginFromKeytab();
          } else if (UserGroupInformation.isLoginTicketBased()) {
            UserGroupInformation.getLoginUser().reloginFromTicketCache();
          }

您可以将其视为重新登录的“懒惰评估”。它仅重新执行登录以响应尝试的 RPC 连接上的身份验证失败。

知道了这一点，我们可以给出部分答案。如果您的应用程序的使用模式是从 key 表登录，然后执行典型的 Hadoop RPC 调用，那么您可能不需要滚动自己的重新登录代码。 RPC 客户端层将为您完成。 “典型的 Hadoop RPC”是指绝大多数用于与 Hadoop 交互的 Java API，包括 HDFS FileSystem API， YarnClient 和 MapReduce Job 提交。

但是，一些应用程序使用模式根本不涉及 Hadoop RPC。这方面的一个示例是仅与 Hadoop 的 REST API 交互的应用程序，例如 WebHDFS或 YARN REST APIs .在这种情况下，身份验证模型通过 SPNEGO 使用 Kerberos，如 Hadoop HTTP Authentication 中所述。文档。

知道了这一点，我们可以在答案中添加更多内容。如果您的应用程序的使用模式根本不使用 Hadoop RPC，而是仅使用 REST API，那么您必须推出自己的重新登录逻辑。这就是为什么 WebHdfsFileSystem calls UserGroupInformation#checkTGTAndReloginFromkeytab ，就像你注意到的那样。 WebHdfsFileSystem选择在每次操作之前拨打电话。这是一个很好的策略，因为 UserGroupInformation#checkTGTAndReloginFromkeytab only renews the ticket if it's "close" to expiration.否则，调用是空操作。

作为最后一个用例，让我们考虑一个交互式过程，不是从 key 表登录，而是要求用户运行 kinit在启动应用程序之前在外部。在绝大多数情况下，这些将是短期运行的应用程序，例如 Hadoop CLI 命令。但是，在某些情况下，这些可能是运行时间更长的进程。为了支持更长时间运行的进程，Hadoop 启动了一个后台线程来更新 Kerberos 票证“接近”到期。此逻辑在 UserGroupInformation#spawnAutoRenewalThreadForUserCreds 中可见.与 RPC 层提供的自动重新登录逻辑相比，这里有一个重要的区别。在这种情况下，Hadoop 只能更新票据并延长其生命周期。根据 Kerberos 基础结构的规定，票证具有最长的可更新生命周期。在那之后，票将不再可用。在这种情况下重新登录实际上是不可能的，因为这意味着重新提示用户输入密码，他们很可能离开了终端。这意味着如果进程在票证到期后继续运行，它将无法再进行身份验证。

同样，我们可以使用这些信息来告知我们的整体答案。如果您依赖用户通过 kinit 以交互方式登录在启动应用程序之前，如果您确信应用程序的运行时间不会超过 Kerberos 票证的最大可更新生命周期，那么您可以依靠 Hadoop 内部结构为您进行定期更新。

如果您使用的是基于 keytab 的登录，并且您只是不确定您的应用程序的使用模式是否可以依赖于 Hadoop RPC 层的自动重新登录，那么保守的方法是使用您自己的方式。 @SamsonScharfrichter 在这里给出了一个很好的答案，关于滚动你自己的。

HBase Kerberos connection renewal strategy

最后，我应该添加一个关于 API 稳定性的说明。 Apache Hadoop Compatibility 指南详细讨论了 Hadoop 开发社区对向后兼容性的 promise 。 UserGroupInformation的界面已批注 LimitedPrivate和 Evolving .从技术上讲，这意味着 UserGroupInformation 的 API不被认为是公开的，它可能以向后不兼容的方式发展。实际上，已经有很多代码依赖于 UserGroupInformation 的接口(interface)。 ，所以我们根本不可能做出突破性的改变。当然，在当前的 2.x 发行版中，我不会担心方法签名会从您身下改变并破坏您的代码。

现在我们已经掌握了所有这些背景信息，让我们重新审视您的具体问题。

Can I rely on the various Hadoop clients they call checkTGTAndReloginFromKeytab whenever it's needed?

如果您的应用程序的使用模式是调用 Hadoop 客户端，而后者又会使用 Hadoop 的 RPC 框架，那么您可以依赖它。如果您的应用程序的使用模式仅调用 Hadoop REST API，则不能依赖于此。

Should I call ever checkTGTAndReloginFromKeytab myself in my code?

如果您的应用程序的使用模式只是调用 Hadoop REST API 而不是 Hadoop RPC 调用，那么您可能需要这样做。您不会从 Hadoop 的 RPC 客户端内部实现的自动重新登录中受益。

If so should I do that before every single call to ugi.doAs(...) or rather setup a timer and call it periodically (how often)?

可以拨打 UserGroupInformation#checkTGTAndReloginFromKeytab就在需要验证的每个操作之前。如果票据未接近到期，则该方法将是空操作。如果您怀疑您的 Kerberos 基础设施运行缓慢，并且您不希望客户端操作支付重新登录的延迟成本，那么这将是在单独的后台线程中执行此操作的一个理由。只要确保比票证的实际到期时间提前一点。你可能会借用 UserGroupInformation 里面的逻辑用于确定票证是否“接近”到期。在实践中，我个人从未见过重新登录的延迟有问题。