美團點評資料平臺Kerberos優化實戰

美團技術團隊發表於2018-05-23

背景

Kerberos 是一種網路認證協議，其設計目標是通過金鑰系統為客戶端、伺服器端的應用程式提供強大的認證服務。作為一種可信任的第三方認證服務，Kerberos是通過傳統的密碼技術（如：共享金鑰）執行認證服務的，被Client和Server同時信任。KDC是對該協議中第三方認證服務的一種具體實現，一直以來都是美團點評資料平臺的核心服務之一，在Hive、HDFS、YARN等開源元件的許可權認證方面有著廣泛的應用。該服務將認證的金鑰事先部署在叢集的節點上，叢集或者新節點啟動時，相應節點使用金鑰得到認證。只有被認證過節點才能被叢集所接納。企圖冒充的節點由於沒有相關金鑰資訊，無法與叢集內部的節點通訊，從而有效的確保了資料的安全性、節點的可信賴性。

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

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

表1 專業名詞解釋

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

圖1 KDC主體流程圖

KDC原理介紹

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

圖2 KDC原理圖

A.Client和AS的互動

1.使用者以明文的形式傳送自己的資訊、以及想要申請的TGT Principal（預設為KDC的TGT：krbtgt/REALM@REALM）等資訊給AS服務；

2.AS服務驗證該使用者資訊存在資料庫中後，給客戶端返回兩大塊資訊：
* 1）使用使用者的金鑰加密其申請的TGT和一個Session Key返回使用者,使用者得到加密資訊後，使用自己金鑰解密得到其申請的TGT和Session Key（後續都簡稱 SKCandK）。
* 2）以KDC自身金鑰加密使用者申請的TGT、SKCandK、使用者自己資訊等；簡稱{TGT}Ktgs，該部分資訊被Client儲存在本地。

B.Client和TGS的互動

1.Client訪問TGS獲取訪問網路中某一Server的ticket請求。Client端會把第一部分中儲存在本地的{TGT}Ktgs和用SKCandK加密的客戶端資訊傳送KDC的TGS模組；

2.TGS收到請求後，檢查請求Server存在資料庫中後，用自己的金鑰解密得到TGT中的SKCandK，然後便可以解密得到使用者的資訊並驗證其合法性；通過後，TGS會生成一個新的Session Key，簡稱SKCandS；同時返回兩部分資訊：1）用SKCandK加密的SKCandS、能夠訪問Service的ticket等資訊。2）用Service金鑰加密的Client info、SKCandS等資訊，簡稱{ TService }KService。

C.Client和Server的互動

Client拿到訪問Service的ticket後，向Service發起請求，同時將兩部分資訊傳送給Server：1）通過SKCandS加密的Client info等資訊。2）第二部分TGS返回客戶端的{ TService }KService；
Server端收到Client的請求資訊後，用自己的金鑰解密獲取到TService資訊，就能夠解密SKCandS加密的客戶端資訊，和TService中的客戶端資訊進行對比，通過後，整個KDC認證過程結束，Client和Service進行正常的服務通訊。

主要優化工作

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

優化之前，線上KDC服務啟動的單程式；為最低風險的完成美團和點評資料的融合，KDC中keytab都開啟了PREAUTH屬性；承載KDC服務的部分伺服器沒有做RAID。KDC服務出現故障時，機器整體資源空閒，懷疑是單程式的處理能力達到上限；PREAUTH屬性進一步保證提升了KDC服務的安全性，但可能帶來一定的效能開銷；如果線上伺服器只載入了少量的keytab資訊，那麼沒有被載入到記憶體的資料必然讀取磁碟，從而帶來一定的IO損耗。因此本文中，對以下三個條件進行變動，分別進行了測試：1. 對承載KDC服務的物理機型是否做RAID10；2. 請求的keytab在庫中是否帶有PRAUTH屬性；3. KDC是否啟動多程式（多程式設定數目和物理機核數一致）。（實際測試工作中進行了多次測試）

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

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

表2 AS壓測

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

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

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

圖3 單程式KDC打滿某一CPU

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

圖4 AS處理能力和Client壓力模型

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所示。

圖5 庫中keytab有無preauth屬性的區別

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所示。

圖6 無RAID多KDC程式伺服器磁碟IO

圖7 美團點評KDC快取命中率

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

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

圖8 40程式有PREAUTH，AS對CPU資源的使用情況

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

表3為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的處理邏輯幾乎沒有影響，壓測的資料結果從實際角度驗證了這一點。

圖9 TGS壓測，IO資源的使用情況

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所示：

圖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.設計上的權衡

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

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

圖11 KDC監控設計的整體架構

B.程式的可擴充套件性

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

整個修改過程簡單明瞭，因此，該KDC監控程式的設計具有非常好的擴充套件性。圖12為監控指標的羅列和註釋。

圖12 KDC監控指標及含義

C.介面工具kstat的設計

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

1.獲取當前每個KDC程式對各個指標的累積值，該功能是為了和新美大的監控平臺Falcon結合，方便實現指標的上報實現累加值和分鐘級別速率值的處理；
2.獲取制定次數在制定時間間隔內每個程式監控指標的瞬時速率，最小統計間隔可達秒級，方便運維人員登陸機器無延遲的檢視當前KDC的服務情況，使其在公司監控系統不可用的情況下分析服務的當前問題。具體使用見圖13 。