背景

Kerberos 是一種網絡認證協議，其設計目標是通過密鑰系統為客戶端、服務器端的應用程序提供強大的認證服務。

作為一種可信任的第三方認證服務，Kerberos是通過傳統的密碼技術（如：共享密鑰）執行認證服務的，被Client和Server同時信任。KDC是對該協議中第三方認證服務的一種具體實現，一直以來都是美團數據平臺的核心服務之一，在Hive、HDFS、YARN等開源組件的權限認證方面有著廣泛的應用。該服務將認證的密鑰事先部署在集群的節點上，集群或者新節點啟動時，相應節點使用密鑰得到認證。只有被認證過節點才能被集群所接納。企圖冒充的節點由于沒有相關密鑰信息，無法與集群內部的節點通信，從而有效的確保了數據的安全性、節點的可信賴性。

但隨著平臺業務的快速增長，當前線上KDC的處理能力不足和不能可靠監控的問題被凸顯的日益嚴重：線上單臺KDC服務器最大承受QPS是多少？哪臺KDC的服務即將出現壓力過大的問題？為什么機器的資源非常空閑，KDC的壓力卻會過大？如何優化？優化后瓶頸在哪兒？如何保證監控指標的全面性、可靠性和準確性？這都是本文需要回答的問題。從本次優化工作達成的最終結果上來看，單臺服務器每秒的處理性能提升16倍左右，另外通過共享內存的方式設計了一個獲取KDC各項核心指標的接口，使得服務的可用性進一步提升。

為方便大家，表1總結并解釋了本文中后續會涉及到一些專業名詞的簡稱：

圖1為美團數據平臺KDC當前服務架構，目前整個KDC服務部署在同一個IDC。

KDC原理介紹

Client、 KDC和Server在認證階段主要有Client和KDC的AS、Client和KDC的TGS以及Client和Server的交互三個過程，下文將詳細介紹三個過程的交互，其中圖2中的步驟1和2、3和4、5和6分別對應下文的A、B、C三部分：

A. Client和AS的交互

用戶以明文的形式發送自己的信息、以及想要申請的TGT Principal（默認為KDC的TGT：krbtgt/REALM@REALM）等信息給AS服務；

AS服務驗證該用戶信息存在數據庫中后，給客戶端返回兩大塊信息：

• 使用用戶的密鑰加密其申請的TGT和一個Session Key返回用戶,用戶得到加密信息后，使用自己密鑰解密得到其申請的TGT和Session Key（后續都簡稱 SK_CandK）。
• 以KDC自身密鑰加密用戶申請的TGT、SK_CandK、用戶自己信息等；簡稱{TGT}K_tgs，該部分信息被Client保存在本地。

B. Client和TGS的交互

Client訪問TGS獲取訪問網路中某一Server的ticket請求。Client端會把第一部分中保存在本地的{TGT}K_tgs和用SK_CandK加密的客戶端信息發送KDC的TGS模塊；

TGS收到請求后，檢查請求Server存在數據庫中后，用自己的密鑰解密得到TGT中的SK_CandK，然后便可以解密得到用戶的信息并驗證其合法性；通過后，TGS會生成一個新的Session Key，簡稱SK_CandS；同時返回兩部分信息：

• 用SK_CandK加密的SK_CandS、能夠訪問Service的ticket等信息。
• 用Service密鑰加密的Client info、SK_CandS等信息，簡稱{ T_Service }K_Service。

C. Client和Server的交互

Client拿到訪問Service的ticket后，向Service發起請求，同時將兩部分信息發送給Server：1）通過SK_CandS加密的Client info等信息。2）第二部分TGS返回客戶端的{ T_Service }K _Service； =1>

Server端收到Client的請求信息后，用自己的密鑰解密獲取到T_Service信息，就能夠解密SK_CandS加密的客戶端信息，和T_Service中的客戶端信息進行對比，通過后，整個KDC認證過程結束，Client和Service進行正常的服務通信。

主要優化工作

通過對KDC原理的分析，很容易判斷只有前兩部分才可能直接給KDC服務帶來壓力，因此本文涉及到的工作都將圍繞上一部分的前兩個環節展開分析。本次優化工作采用Grinder這一開源壓測工具，分別對AS、TGS兩個請求過程，采用相同機型（保證硬件的一致性）在不同場景下進行了壓力測試。

優化之前，線上KDC服務啟動的單進程；為最低風險的完成美團和點評數據的融合，KDC中keytab都開啟了PREAUTH屬性；承載KDC服務的部分服務器沒有做RAID。KDC服務出現故障時，機器整體資源空閑，懷疑是單進程的處理能力達到上限；PREAUTH屬性進一步保證提升了KDC服務的安全性，但可能帶來一定的性能開銷；如果線上服務器只加載了少量的keytab信息，那么沒有被加載到內存的數據必然讀取磁盤，從而帶來一定的IO損耗。

因此本文中，對以下三個條件進行變動，分別進行了測試：

對承載KDC服務的物理機型是否做RAID10；

請求的keytab在庫中是否帶有PRAUTH屬性；

KDC是否啟動多進程（多進程設置數目和物理機核數一致）。（實際測試工作中進行了多次測試）

A. Client和AS交互過程的壓測

表2為AS壓測的一組平均水平的測試數據，使用的物理機有40核，因此多進程測試啟動40個進程。

分析表2中的數據，很容易提出如下問題從而需要進一步探索：

1. 比較表2中第一行和第二行、第三行和第四行，主機做不做RAID為什么對結果幾乎無影響？

該四組（測試結果為49、53、100和104所在表2中的行）數據均在達到處理能力上限一段時間后產生認證失敗，分析機器的性能數據，內存、網卡、磁盤資源均沒有成為系統的瓶頸，CPU資源除了某個CPU偶爾被打滿，其他均很空閑。分析客戶端和服務端的認證日志，服務端未見明顯異常，但是客戶端發現大量的Socket Timeout錯誤（測試設置的Socket超時時間為30s）。由于測試過程中，客戶端輸出的壓力始終大于KDC的最大處理能力，導致KDC端的AS始終處于滿負荷狀態，暫時處理不了的請求必然導致排隊；當排隊的請求等待時間超過設置的30s后便會開始超時從而認證出錯，且伴隨機器某一CPU被打滿（如圖3）。 顯然KDC單進程服務的處理能力已經達到瓶頸且瓶頸存在單核CPU的處理能力，從而決定向多進程方向進行優化測試。

圖4為本次壓力測試的一個通用模型，假設KDC單位時間內的最大處理能力是A，來自客戶端的請求速率穩定為B且 B>A ；圖中黃色區域為排隊的請求數，當某一請求排隊超過30s，便會導致Socket Timedout錯誤。

2. 比較表2中第1和3行、第2和4行、第7和8行相比，為什么有PREAUTH屬性的認證QPS大致是無該屬性處理能力的一半？

如果Client的keytab在KDC的庫中不帶有PREAUTH這一屬性，Client發送請求，KDC的AS模塊驗證其合法性之后返回正確的結果；整個過程只需要兩次建立鏈接進行交互便可完成。如果帶有PREAUTH屬性，意味著該keytab的認證啟動了Kerberos 5協議中的 pre-authentication概念：當AS模塊收到Client的請求信息后；故意給Client返回一個錯誤的請求包，Client會“領悟到”這是KDC的AS端需要進行提前認證；從而Client獲取自己服務器的時間戳并用自己的密鑰加密發送KDC，KDC解密后和自身所在服務器的時間進行對比，如果誤差在能容忍的范圍內；返回給Client正確的TGT響應包；過程如圖5所示。

3. 根據對問題2的分析，表2中第5和7行的值的比例應該近似為1:2，為什么第5行的值只有115，結果和理論差距如此之大？

KDC的庫中對客戶端的keytab開啟PREAUTH屬性，客戶端每認證一次，KDC需要將該次認證的時間戳等信息寫到本次磁盤的BDB數據庫的Log中；而關閉PREAUTH屬性后，每次認證只需要從庫中讀取數據，只要給BDB數據庫分配的內存足夠大，就可以最大程度的減少和本次磁盤的交互。KDC40進程且開啟PRAUTH，其AS處理能力的QPS只有115，分析機器性能的相關指標，發現瓶頸果然是單盤的IO，如圖6所示。使用BDB提供的工具，查看美團數據平臺KDC服務的BDB緩存命中率為99%，如圖7所示：

4. KDC AS處理能力在多進程做RAID條件下，有無preauth屬性，KDC服務是否有瓶頸？如果有在哪里？

經多次實驗，KDC的AS處理能力受目前物理機CPU處理能力的限制，圖8為有PREAUTH屬性的CPU使用情況截圖，無PREAUTH結果一致。

B. Client和TGS交互過程的壓測

表3為TGS壓測的一組平均水平的測試數據：

分析表3中的數據，可以發現KDC對TGS請求的處理能力和主機是否做RAID無關,結合KDC中TGS的請求原理，就較容易理解在BDB緩存命中率足夠高的條件下，TGS的請求不需要和本次磁盤交互；進一步做實驗，也充分驗證了這一點，機器的磁盤IO在整個測試過程中，沒有大的變化，如圖9所示，操作系統本身偶爾產生的IO完全構不成KDC的服務瓶頸。KDC單進程多進程的對比，其處理瓶頸和AS一致，均受到CPU處理能力的限制（單進程打滿某一CPU，多進程幾乎占用整臺機器的CPU資源）。從Kerberos的設計原理分析，很容易理解，無論KDC庫中的keytab是否帶有PREAUTH屬性，對TGS的處理邏輯幾乎沒有影響，壓測的數據結果從實際角度驗證了這一點。

C. 其他問題

Client和KDC的交互，支持TCP和UDP兩種協議。在網絡環境良好的情況下，兩種協議的KDC的測試結果理論上和實際中幾乎一致。但是在原生代碼中，使用TCP協議，在客戶端給KDC造成一定壓力持續6s左右，客戶端開始認證出錯，在遠未達到超時時限的情況下，Client出現了socket reset類的錯誤。KDC查看內核日志，發現大量possible SYN flooding on port 8089(KDC的服務端口). Sending cookies，且通過netstat -s發現機器的xxxx times the listen queue of a socket overflowed異常增高，種種現象表明可能是服務端的半連接隊列、全連接隊列中的一個或者全部被打滿。主要原理如圖10所示：

發現KDC服務所在服務器：半隊列/proc/sys/net/ipv4/tcp_max_syn_backlog為2048。

全隊列：1）系統參數/proc/sys/net/core/somaxconn＝65535，查看代碼listen()函數的傳入值為5。

故而判斷TCP的瓶頸在于全隊列，因此目標為將listen函數的第二個backlog參數變成可控可傳入。

KDC可監控的設計和實現

開源社區對Kerberos實現的KDC完全沒有對外暴露可監控的接口，最初線上的場景主要通過檢索Log進行相關指標的監控，在統計服務QPS、各種錯誤的監控等方面，存在準確準確監控難的尷尬局面。為了實現對KDC準確、較全面的監控，對KDC進行了二次開發，設計一個獲取監控指標的接口。對監控的設計，主要從以下三個方面進行了考慮和設計。

A. 設計上的權衡

監控的設計無論在什么場景下，都應該盡可能的不去或者最小程度的影響線上的服務，本文最終采用建立一塊共享內存的方式，記錄各個KDC進程的打點信息，實現的架構如圖11所示。每個KDC進程對應共享內存中的一塊區域，通過n個數組來存儲KDC n個進程的服務指標：當某個KDC進程處理一個請求后，該請求對監控指標的影響會直接打點更新到其對應的Slot 數組中。更新的過程不受鎖等待更新的影響，KDC對監控打點的調用僅僅是內存塊中的更新，對服務的影響幾乎可以忽略不計。相比其他方式，在實現上也更加簡單、易理解。

紀錄每個KDC進程的服務情況，便于準確查看每個進程的對請求的處理情況，有助于定位問題多種情況下出現的異常，縮短故障的定位時間。例如：能夠準確的反應出每個進程的請求分布是否均勻、請求處理出現異常能夠定位到具體是某個進程出現異常還是整體均有異常。

B. 程序的可擴展性

任何指標的采集都是隨著需求進行變更的，如果程序設計上不具有良好的擴展性，會后續的指標擴展帶來很大的困擾。第一版KDC監控指標的采集只區分請求的成功與失敗兩種類型，美團數據平臺KDC庫中所有的keytab都具有PREAUTH屬性。根據上文可知，去掉PREAUTH屬性后，AS請求的QPS能夠提升一倍。后續隨著服務規模的進一步增長，如果AS請求的處理能力逐步成為瓶頸，會考慮去掉PREAUTH屬性。為了準確監控去掉PREAUTH屬性這一過程是否有、有多少請求出現錯誤，需要擴展一個監控指標，因此有了KDC監控的第二版。整個過程只需要修改三個地方，完成兩個功能的實現：

添加指標 ；

打點邏輯的添加。

整個修改過程簡單明了，因此，該KDC監控程序的設計具有非常好的擴展性。圖12為監控指標的羅列和注釋：

C. 接口工具kstat的設計

獲取KDC監控指標的接口工具主要分為兩種：

獲取當前每個KDC進程對各個指標的累積值，該功能是為了和新美大的監控平臺Falcon結合，方便實現指標的上報實現累加值和分鐘級別速率值的處理；

獲取制定次數在制定時間間隔內每個進程監控指標的瞬時速率，最小統計間隔可達秒級，方便運維人員登陸機器無延遲的查看當前KDC的服務情況，使其在公司監控系統不可用的情況下分析服務的當前問題。具體使用見圖13 。

總結

通過本次對KDC服務的壓測實驗和分析，總結出KDC最優性能的調整方案為：

KDC服務本身需要開啟多進程和以充分利用多核機器的CPU資源，同時確保BDB的內存資源足夠，保證其緩存命中率達到一定比例（越高越好，否則查詢庫會帶來大量的磁盤讀IO）；

選擇的物理機要做RAID，否則在庫中keytab帶有PREAUTH屬性的條件下，會帶來大量的寫，容易導致磁盤成為KDC的性能瓶頸。通過建立一塊共享內存無鎖的實現了KDC多進程指標的收集，加上其良好的擴展性和數據的精確性，極大的提高了KDC服務的可靠性。

相比原來線上單進程的處理能力，目前單臺服務器的處理性能提升10+倍以上。本次工作沒有詳細的論述TCP協議中半隊列、全隊列的相關參數應該如何設定才能達到最優，和服務本身結合到一起，每個參數的變更帶來的影響具體是啥？考慮到TCP本身的復雜性，我們將在未來的文章中詳細討論這個問題。

參考文檔

• http://blog.csdn.net/m1213642578/article/details/52370705
• http://grinder.sourceforge.net/
• http://www.cnblogs.com/Orgliny/p/5780796.html
• http://www.zeroshell.org/kerberos/Kerberos-operation/
• http://blog.csdn.net/wulantian/article/details/42418231

作者簡介

• 鵬飛，美團基礎數據部數據平臺大數據SRE組，離線計算組SRE負責人，2015年11月加入美團。

招聘信息

如果你對如何保證海量數據服務的穩定性、海量服務器大規模運維感興趣，想親歷互聯網大數據的爆發式增長，請和我們一起。歡迎加入美團數據平臺大數據SRE組。有興趣的同學可以發送簡歷到：chenpengfei#meituan.com。

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的美团数据平台Kerberos优化实战的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。