介紹

LDAP是一個(gè)常見的目錄信息源；該協(xié)議的第一個(gè)版本是在1993年編纂的。它通常用于各種應(yīng)用，包括管理Linux實(shí)例的用戶/組信息，以及控制VPN和傳統(tǒng)應(yīng)用的認(rèn)證。

傳統(tǒng)上，公司的LDAP服務(wù)器是在內(nèi)部運(yùn)行的；通常是微軟的ActiveDirectory的一部分，或者是開放源碼OpenLDAP項(xiàng)目的一個(gè)部署。現(xiàn)在，SaaS供應(yīng)商可以提供LDAP支持；包括Foxpass，它是第一個(gè)從頭開始建立一個(gè)多用戶、以云為中心的LDAP實(shí)施的云LDAP供應(yīng)商。

簡(jiǎn)單介紹一下：LDAP通常有以下基元：綁定、搜索、比較和添加。在創(chuàng)建一個(gè)TCP連接后，應(yīng)用程序首先需要通過(guò)發(fā)送一個(gè)用戶名和密碼進(jìn)行綁定。一旦綁定成功，客戶端將向LDAP服務(wù)器發(fā)出命令；通常是與過(guò)濾器一起的搜索命令。TCP連接一直保持到客戶端或服務(wù)器斷開連接。

Foxpass的LDAP

在Foxpass，我們的LDAP服務(wù)是在Twisted之上編寫的，Twisted是一種流行的基于事件的Python服務(wù)框架。該服務(wù)托管在 AWS的ECS平臺(tái)上，運(yùn)行在數(shù)十個(gè)容器（節(jié)點(diǎn)）上。由于 LDAP連接是持久的，因此集群必須能夠同時(shí)維護(hù)數(shù)十萬(wàn)個(gè)TCP會(huì)話。

我們將客戶的數(shù)據(jù)保存在RAM中。這樣做的原因是多方面的。首先，數(shù)據(jù)集相對(duì)較小，即使對(duì)于大客戶也是如此。其次，LDAP查詢語(yǔ)言允許搜索任意字段（這很重要，因?yàn)镕oxpass允許自定義字段）。這意味著傳統(tǒng)的 RDBMS系統(tǒng)將無(wú)法構(gòu)建有效的索引，我們必須將數(shù)據(jù)轉(zhuǎn)換為不同的內(nèi)存表示形式。第三，將數(shù)據(jù)保存在 RAM中可以實(shí)現(xiàn)最快的響應(yīng)時(shí)間：延遲通常在100毫秒左右（見圖a）。

圖a：“搜索”命令的第95個(gè)百分位響應(yīng)時(shí)間

這種方法的一個(gè)缺點(diǎn)是緩存失效。當(dāng)客戶的數(shù)據(jù)發(fā)生變化時(shí)（例如，添加或刪除用戶），LDAP節(jié)點(diǎn)必須從我們的主RDBMS刷新它們的數(shù)據(jù)。在我們之前的架構(gòu)中，這是一個(gè)相對(duì)昂貴的操作；當(dāng)每個(gè)節(jié)點(diǎn)刷新同一家公司的數(shù)據(jù)時(shí)，它可能會(huì)導(dǎo)致LDAP延遲和后備存儲(chǔ)負(fù)載出現(xiàn)明顯的峰值。

延遲敏感性挑戰(zhàn)

如上所述，由于延遲要求，每個(gè)容器都將所有客戶的數(shù)據(jù)存儲(chǔ)在內(nèi)存中（見圖a）。當(dāng)請(qǐng)求到達(dá)一個(gè)節(jié)點(diǎn)時(shí)（如果它尚未存在），數(shù)據(jù)將按需獲取，然后只要來(lái)自該客戶的至少一個(gè)連接存在，數(shù)據(jù)就會(huì)一直存在。

由于傳入的連接請(qǐng)求可以到達(dá)任何容器（通過(guò)負(fù)載均衡器），因此提供查詢的容器也會(huì)加載和存儲(chǔ)客戶的所有數(shù)據(jù)。隨后，容器向 redispubsub 服務(wù)注冊(cè)以接收失效消息。當(dāng)公司數(shù)據(jù)發(fā)生更新時(shí)，將廣播無(wú)效信號(hào)，接收節(jié)點(diǎn)會(huì)清除該公司的數(shù)據(jù)緩存，并轉(zhuǎn)到數(shù)據(jù)庫(kù)重新獲取公司數(shù)據(jù)。隨著我們不斷發(fā)展并將新客戶添加到我們的系統(tǒng)中，這對(duì)擴(kuò)展我們的LDAP服務(wù)提出了以下挑戰(zhàn)：

跨所有節(jié)點(diǎn)(N)的客戶(M)的所有數(shù)據(jù)都需要在失效時(shí)重新加載。盡管實(shí)際上并非每個(gè)節(jié)點(diǎn)都承載來(lái)自每個(gè)客戶的連接，但在最壞的情況下，會(huì)對(duì)數(shù)據(jù)庫(kù)進(jìn)行MxN次調(diào)用以刷新數(shù)據(jù)。隨著更多客戶的添加 (M)，數(shù)據(jù)庫(kù)提取的數(shù)量會(huì)增加N倍。這也意味著，為了不讓數(shù)據(jù)庫(kù)機(jī)器不堪重負(fù)，需要額外的數(shù)據(jù)庫(kù)讀取器實(shí)例來(lái)處理請(qǐng)求的激增。

由于跨客戶(M)的所有數(shù)據(jù)都存儲(chǔ)在跨多個(gè)節(jié)點(diǎn)(N)的內(nèi)存中，因此所有節(jié)點(diǎn)的內(nèi)存繼續(xù)增加，并與客戶數(shù)量(M)成比例。這也意味著容器的內(nèi)存需求必須增長(zhǎng)以容納內(nèi)存中的所有數(shù)據(jù)，這反過(guò)來(lái)又增加了整體基礎(chǔ)設(shè)施成本。

上述挑戰(zhàn)非常明顯，讓我們傾向于跨節(jié)點(diǎn)分布客戶數(shù)據(jù)，而不是在每個(gè)節(jié)點(diǎn)上復(fù)制所有客戶的數(shù)據(jù)。這使我們找到了分布式緩存管理解決方案。

圖a

分布式緩存管理

我們?cè)贚DAP服務(wù)中引入了一個(gè)智能路由層，如果連接所在的容器未托管數(shù)據(jù)，該層會(huì)將請(qǐng)求轉(zhuǎn)發(fā)到托管客戶數(shù)據(jù)的節(jié)點(diǎn)。為實(shí)現(xiàn)這一目標(biāo)，我們縮小了路由層的以下設(shè)計(jì)要求：

客戶需要在添加時(shí)動(dòng)態(tài)分布在節(jié)點(diǎn)之間。

客戶的數(shù)據(jù)需要隨著節(jié)點(diǎn)收縮、擴(kuò)展和節(jié)點(diǎn)故障而動(dòng)態(tài)分布

能夠增加和減少特定客戶的分區(qū)數(shù)量，以便流量不平衡不會(huì)壓倒任何單個(gè)節(jié)點(diǎn)。

我們引入了ApacheHelix，它可以跨實(shí)例分配資源。Helix控制器是helix生態(tài)系統(tǒng)的大腦。當(dāng)添加或刪除節(jié)點(diǎn)或客戶時(shí)，它會(huì)跨節(jié)點(diǎn)做出資源分配決策。我們對(duì) ApacheHelix 控制器、Rest服務(wù)器進(jìn)行了docker化，并將其部署在ECS上。Helix控制器依賴于Zookeeper來(lái)監(jiān)聽集群的變化。我們實(shí)施了一種在 ECS上部署Zookeeper的可靠方法。Helix和Zookeeper的整個(gè)基礎(chǔ)架構(gòu)都運(yùn)行在ECS上。

每個(gè)LDAP節(jié)點(diǎn)都與Zookeeper交互以注冊(cè)自己以加入集群。每個(gè) LDAP實(shí)例作為Helix參與者出現(xiàn)，參與集群以由Helix控制器進(jìn)行客戶到節(jié)點(diǎn)的分配。當(dāng) LDAP節(jié)點(diǎn)動(dòng)態(tài)創(chuàng)建新客戶時(shí)，該客戶的分區(qū)數(shù)（每個(gè)分區(qū)代表一個(gè)托管數(shù)據(jù)的節(jié)點(diǎn)）根據(jù)用戶數(shù)確定。通過(guò)這種集成，我們的 LDAP節(jié)點(diǎn)可以了解集群中發(fā)生的事件，即添加新客戶或可用節(jié)點(diǎn)集發(fā)生變化時(shí)。

有了這種集群意識(shí)，我們LDAP服務(wù)中的路由層提供了節(jié)點(diǎn)和客戶之間的映射。現(xiàn)在每個(gè)傳入連接都將通過(guò)路由層來(lái)決定連接必須路由到哪個(gè)節(jié)點(diǎn)。這樣，客戶的數(shù)據(jù)就會(huì)分配給特定的節(jié)點(diǎn)（見圖 b）。

圖b

路由層托管一個(gè)緩存，其中包含客戶和節(jié)點(diǎn)的路由信息。路由層監(jiān)視任何客戶到節(jié)點(diǎn)的分配更改，并在檢測(cè)到更改時(shí)立即更新。這樣，每個(gè) LDAP節(jié)點(diǎn)都會(huì)在客戶到節(jié)點(diǎn)的更改發(fā)生時(shí)立即意識(shí)到它們。通過(guò)上述緩存管理解決方案，解決了延遲敏感性挑戰(zhàn)部分中提到的可擴(kuò)展性挑戰(zhàn)：

我們現(xiàn)在的客戶分布在各個(gè)節(jié)點(diǎn)上。每個(gè)節(jié)點(diǎn)將僅托管一部分客戶，并負(fù)責(zé)在收到 pubsub無(wú)效時(shí)僅獲取一部分客戶數(shù)據(jù)。這顯著減少了對(duì)數(shù)據(jù)庫(kù)的讀取次數(shù)，無(wú)需添加數(shù)據(jù)庫(kù)讀取器節(jié)點(diǎn)來(lái)處理大量數(shù)據(jù)庫(kù)讀取。LDAP集群現(xiàn)在比以前減少了75%的數(shù)據(jù)庫(kù)讀取。

我們還提高了內(nèi)存效率，因?yàn)槲覀儧](méi)有將所有客戶(M)數(shù)據(jù)存儲(chǔ)在所有節(jié)點(diǎn)(N)的內(nèi)存中。這種架構(gòu)提供了水平擴(kuò)展的能力，而無(wú)需增加實(shí)例大小。每個(gè) LDAP節(jié)點(diǎn)現(xiàn)在消耗的內(nèi)存比以前減少了40%。

當(dāng)前的挑戰(zhàn)

對(duì)于上述實(shí)現(xiàn)，挑戰(zhàn)之一是節(jié)點(diǎn)接收到不相等數(shù)量的TCP連接。與其他節(jié)點(diǎn)相比，這種分布不平衡會(huì)導(dǎo)致某些節(jié)點(diǎn)（熱節(jié)點(diǎn)）上的CPU使用率更高。但是與以前相比，節(jié)點(diǎn)間的平均整體 CPU利用率仍然保持不變。

審核編輯：劉清