介紹

LDAP是一個常見的目錄信息源；該協議的第一個版本是在1993年編纂的。它通常用于各種應用，包括管理Linux實例的用戶/組信息，以及控制VPN和傳統應用的認證。

傳統上，公司的LDAP服務器是在內部運行的；通常是微軟的ActiveDirectory的一部分，或者是開放源碼OpenLDAP項目的一個部署?，F在，SaaS供應商可以提供LDAP支持；包括Foxpass，它是第一個從頭開始建立一個多用戶、以云為中心的LDAP實施的云LDAP供應商。

簡單介紹一下：LDAP通常有以下基元：綁定、搜索、比較和添加。在創建一個TCP連接后，應用程序首先需要通過發送一個用戶名和密碼進行綁定。一旦綁定成功，客戶端將向LDAP服務器發出命令；通常是與過濾器一起的搜索命令。TCP連接一直保持到客戶端或服務器斷開連接。

Foxpass的LDAP

在Foxpass，我們的LDAP服務是在Twisted之上編寫的，Twisted是一種流行的基于事件的Python服務框架。該服務托管在 AWS的ECS平臺上，運行在數十個容器（節點）上。由于 LDAP連接是持久的，因此集群必須能夠同時維護數十萬個TCP會話。

我們將客戶的數據保存在RAM中。這樣做的原因是多方面的。首先，數據集相對較小，即使對于大客戶也是如此。其次，LDAP查詢語言允許搜索任意字段（這很重要，因為Foxpass允許自定義字段）。這意味著傳統的 RDBMS系統將無法構建有效的索引，我們必須將數據轉換為不同的內存表示形式。第三，將數據保存在 RAM中可以實現最快的響應時間：延遲通常在100毫秒左右（見圖a）。

圖a：“搜索”命令的第95個百分位響應時間

這種方法的一個缺點是緩存失效。當客戶的數據發生變化時（例如，添加或刪除用戶），LDAP節點必須從我們的主RDBMS刷新它們的數據。在我們之前的架構中，這是一個相對昂貴的操作；當每個節點刷新同一家公司的數據時，它可能會導致LDAP延遲和后備存儲負載出現明顯的峰值。

延遲敏感性挑戰

如上所述，由于延遲要求，每個容器都將所有客戶的數據存儲在內存中（見圖a）。當請求到達一個節點時（如果它尚未存在），數據將按需獲取，然后只要來自該客戶的至少一個連接存在，數據就會一直存在。

由于傳入的連接請求可以到達任何容器（通過負載均衡器），因此提供查詢的容器也會加載和存儲客戶的所有數據。隨后，容器向 redispubsub 服務注冊以接收失效消息。當公司數據發生更新時，將廣播無效信號，接收節點會清除該公司的數據緩存，并轉到數據庫重新獲取公司數據。隨著我們不斷發展并將新客戶添加到我們的系統中，這對擴展我們的LDAP服務提出了以下挑戰：

跨所有節點(N)的客戶(M)的所有數據都需要在失效時重新加載。盡管實際上并非每個節點都承載來自每個客戶的連接，但在最壞的情況下，會對數據庫進行MxN次調用以刷新數據。隨著更多客戶的添加 (M)，數據庫提取的數量會增加N倍。這也意味著，為了不讓數據庫機器不堪重負，需要額外的數據庫讀取器實例來處理請求的激增。

由于跨客戶(M)的所有數據都存儲在跨多個節點(N)的內存中，因此所有節點的內存繼續增加，并與客戶數量(M)成比例。這也意味著容器的內存需求必須增長以容納內存中的所有數據，這反過來又增加了整體基礎設施成本。

上述挑戰非常明顯，讓我們傾向于跨節點分布客戶數據，而不是在每個節點上復制所有客戶的數據。這使我們找到了分布式緩存管理解決方案。

圖a

分布式緩存管理

我們在LDAP服務中引入了一個智能路由層，如果連接所在的容器未托管數據，該層會將請求轉發到托管客戶數據的節點。為實現這一目標，我們縮小了路由層的以下設計要求：

客戶需要在添加時動態分布在節點之間。

客戶的數據需要隨著節點收縮、擴展和節點故障而動態分布

能夠增加和減少特定客戶的分區數量，以便流量不平衡不會壓倒任何單個節點。

我們引入了ApacheHelix，它可以跨實例分配資源。Helix控制器是helix生態系統的大腦。當添加或刪除節點或客戶時，它會跨節點做出資源分配決策。我們對 ApacheHelix 控制器、Rest服務器進行了docker化，并將其部署在ECS上。Helix控制器依賴于Zookeeper來監聽集群的變化。我們實施了一種在 ECS上部署Zookeeper的可靠方法。Helix和Zookeeper的整個基礎架構都運行在ECS上。

每個LDAP節點都與Zookeeper交互以注冊自己以加入集群。每個 LDAP實例作為Helix參與者出現，參與集群以由Helix控制器進行客戶到節點的分配。當 LDAP節點動態創建新客戶時，該客戶的分區數（每個分區代表一個托管數據的節點）根據用戶數確定。通過這種集成，我們的 LDAP節點可以了解集群中發生的事件，即添加新客戶或可用節點集發生變化時。

有了這種集群意識，我們LDAP服務中的路由層提供了節點和客戶之間的映射?，F在每個傳入連接都將通過路由層來決定連接必須路由到哪個節點。這樣，客戶的數據就會分配給特定的節點（見圖 b）。

圖b

路由層托管一個緩存，其中包含客戶和節點的路由信息。路由層監視任何客戶到節點的分配更改，并在檢測到更改時立即更新。這樣，每個 LDAP節點都會在客戶到節點的更改發生時立即意識到它們。通過上述緩存管理解決方案，解決了延遲敏感性挑戰部分中提到的可擴展性挑戰：

我們現在的客戶分布在各個節點上。每個節點將僅托管一部分客戶，并負責在收到 pubsub無效時僅獲取一部分客戶數據。這顯著減少了對數據庫的讀取次數，無需添加數據庫讀取器節點來處理大量數據庫讀取。LDAP集群現在比以前減少了75%的數據庫讀取。

我們還提高了內存效率，因為我們沒有將所有客戶(M)數據存儲在所有節點(N)的內存中。這種架構提供了水平擴展的能力，而無需增加實例大小。每個 LDAP節點現在消耗的內存比以前減少了40%。

當前的挑戰

對于上述實現，挑戰之一是節點接收到不相等數量的TCP連接。與其他節點相比，這種分布不平衡會導致某些節點（熱節點）上的CPU使用率更高。但是與以前相比，節點間的平均整體 CPU利用率仍然保持不變。

審核編輯：劉清