在服務器應用程序中，我正在從Java應用程序連接到Kerberos安全的Hadoop群集。我正在使用HDFS文件系統，Oozie，Hive等各種組件。在應用程序啟動時，我確實打電話給UserGroupInformation.loginUserFromKeytabAndReturnUGI( ... );這將返回我的UserGroupInformation實例，并在應用程序生存期內保留它。當執行特權操作時，我使用啟動它們ugi.doAs(action)。這可以正常工作，但是我想知道是否以及何時更新kerberos票UserGroupInformation？我發現了一種UserGroupInformation.checkTGTAndReloginFromKeytab()似乎在快要到期時都會進行票證更新的方法。我還發現，WebHdfsFileSystem例如各種Hadoop工具都在調用此方法?，F在，如果我希望我的服務器應用程序（可能運行數月甚至數年）從未經歷過票證到期，那么最好的方法是什么？提供具體問題：是否可以在checkTGTAndReloginFromKeytab需要時依賴它們調用的各種Hadoop客戶端？我應該checkTGTAndReloginFromKeytab在代碼中稱呼自己嗎？如果是這樣，我應該在每次調用ugi.doAs(...)一個計時器之前進行設置，還是設置一個計時器并定期（多久一次）調用一次？
1 回答
回首憶惘然
TA貢獻1847條經驗 獲得超11個贊
Hadoop提交者在這里！這是一個很好的問題。
不幸的是，如果不深入研究應用程序的特定使用模式，很難給出明確的答案。相反，我可以提供一般準則，并描述Hadoop何時為您自動處理票證更新或從keytab重新登錄，以及何時不這樣做。
Hadoop生態系統中Kerberos身份驗證的主要用例是Hadoop的RPC框架，該框架使用SASL進行身份驗證。Hadoop生態系統中的大多數守護進程都通過UserGroupInformation#loginUserFromKeytab在進程啟動時進行一次一次性調用來處理此問題。這樣的示例包括HDFS DataNode和YARN NodeManager，該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連接時由于身份驗證失敗而重新執行登錄。
知道這一點，我們可以給出部分答案。如果您的應用程序的使用模式是從密鑰表登錄，然后執行典型的Hadoop RPC調用，那么您可能不需要滾動自己的重新登錄代碼。RPC客戶端層將為您完成此任務?！暗湫偷腍adoop RPC”表示用于與Hadoop交互的絕大多數Java API，包括HDFS FileSystemAPI，YarnClient和MapReduce Job提交。
但是，某些應用程序使用模式根本不涉及Hadoop RPC。這樣的一個示例是僅與Hadoop的REST API（例如WebHDFS或YARN REST API）交互的應用程序。在這種情況下，身份驗證模型會通過Hadoop HTTP身份驗證文檔中所述通過SPNEGO使用Kerberos 。
知道這一點，我們可以在答案中添加更多內容。如果您的應用程序的使用模式根本不使用Hadoop RPC，而是僅使用REST API，那么您必須滾動自己的重新登錄邏輯。正如您所注意到的，這就是為什么WebHdfsFileSystem打電話的UserGroupInformation#checkTGTAndReloginFromkeytab原因。 WebHdfsFileSystem選擇在每次操作前立即撥打電話。這是一個不錯的策略，因為UserGroupInformation#checkTGTAndReloginFromkeytab僅在“接近”到期時更新票證。 否則，該呼叫為無人操作。
作為最終用例，讓我們考慮一個交互式過程，而不是從keytab登錄，而是要求用戶kinit在啟動應用程序之前在外部運行。在大多數情況下，它們將是短期運行的應用程序，例如Hadoop CLI命令。但是，在某些情況下，這些過程可能是運行時間更長的過程。為了支持運行時間更長的流程，Hadoop啟動了一個后臺線程來將Kerberos票證“關閉”更新為到期。該邏輯在UserGroupInformation#spawnAutoRenewalThreadForUserCreds。與RPC層中提供的自動重新登錄邏輯相比，這里有一個重要的區別。在這種情況下，Hadoop僅具有續簽和延長其壽命的功能。根據Kerberos基礎結構的規定，票證具有最大的可再生壽命。之后，該票將不再可用。在這種情況下，重新登錄實際上是不可能的，因為這將暗示重新提示用戶輸入密碼，并且他們很可能已離開終端。這意味著，如果該進程持續運行到票證到期之后，它將無法再進行身份驗證。
同樣，我們可以使用此信息來告知我們的總體答案。如果您kinit在啟動應用程序之前依靠用戶以交互方式登錄，并且您確信該應用程序的運行時間不會超過Kerberos票證的最大可再生壽命，那么您可以依靠Hadoop內部構件來為您進行定期更新。
如果您使用的是基于keytab的登錄，并且只是不確定應用程序的使用模式是否可以依賴Hadoop RPC層的自動重新登錄，那么保守的方法是自行滾動。@SamsonScharfrichter在這里給自己一個很好的答案。
HBase Kerberos連接更新策略
最后，我應該添加有關API穩定性的注釋。該Apache Hadoop Compatibility指南詳細討論了Hadoop開發社區對向后兼容的承諾。的接口UserGroupInformation帶有LimitedPrivate和Evolving。從技術上講，這意味著的API UserGroupInformation不被認為是公共的，并且可能以向后不兼容的方式發展。實際上，已經有很多代碼取決于的接口UserGroupInformation，因此對我們來說，做出重大更改根本不可行。當然，在當前的2.x發行版中，我不會擔心方法簽名會從您的下方更改并破壞您的代碼。
現在，我們已經掌握了所有這些背景信息，讓我們重新討論您的具體問題。
是否可以在需要時依賴它們調用checkTGTAndReloginFromKeytab的各種Hadoop客戶端？
如果您的應用程序的使用模式是調用Hadoop客戶端，那么您可以依靠它，而Hadoop客戶端又利用Hadoop的RPC框架。如果您的應用程序的使用模式僅調用Hadoop REST API，則您不能依靠它。
我應該在自己的代碼中自稱checkTGTAndReloginFromKeytab嗎？
如果您的應用程序的使用模式僅是調用Hadoop REST API而不是Hadoop RPC調用，則可能需要執行此操作。您將無法從Hadoop的RPC客戶端內部實現的自動重新登錄中受益。
如果是這樣，我應該在每次調用ugi.doAs（...）之前執行此操作，還是設置一個計時器并定期（多長時間一次）調用一次？
可以UserGroupInformation#checkTGTAndReloginFromKeytab在需要驗證的每個操作之前立即進行調用。如果票證即將到期，則該方法將為無操作。如果您懷疑Kerberos基礎結構緩慢，并且您不希望客戶端操作支付重新登錄的延遲成本，那么這就是在單獨的后臺線程中進行此操作的原因。只要確保在機票的實際到期時間之前提前一點時間即可。您可以借用內部邏輯UserGroupInformation來確定票證是否“接近”到期。在實踐中，我從未親自看到重新登錄的延遲有問題。
-
Joey_yxy厲害厲害！所以是ugi傳遞yarn客戶端的用戶信息到hdfs系統上么，可以大致描述一下這個過程么
添加回答
舉報
0/150
提交
取消