大約一年來,我們一直在伺服器openldap
上使用它來驗證大約 20 個 IT 用戶的身份,一切都運作良好(LDAP 伺服器上的操作基本上僅限於使用以下命令建立/刪除使用者)ubuntu
10.04LTS
阿帕契目錄工作室)。
最近(6 個月前),我們也開始實施openldap
(openldap-2.4.21/debian) 作為我們網站的外部身份驗證系統,該系統正在從外部 CMS 遷移到我們內部使用Drupal CMS
.我們有一個 45K 用戶的資料庫,但事情進展得併不順利。我們遇到的問題是:
-備份恢復後 ldap 崩潰,需要恢復。
-LDAP復原工具在某些情況下無法復原LDAP資料庫
-slapd 消耗 100% CPU,同時網站上沒有身分驗證活動。
由於內部缺乏資源和知識,到目前為止我們所做的只是找到保持 LDAP 運行的方法,而沒有真正調查任何這些問題(使用monit
在崩潰時重新啟動它,db_recover
在需要時恢復資料庫,並slapcat
重新創建失敗時從頭開始資料庫db_recover
)。
最近,我們進行了一輪面試,聘請一位資深基礎設施工程師來協助我們處理所有各種基礎設施。我們遇到的問題。幾位候選人證實,他們曾經遇到或聽說過openldap
大型生產環境中的問題,但從未設法提出一個穩定的獨立openldap
伺服器,而是不得不提出冗餘部署(複製、負載平衡、自動恢復/重新啟動例程) )以保持 ldap 運作。一些候選人甚至表示,openldap
這不適合生產環境,相反,使用諸如此類的替代方案Novel eDirectory
是必要的。
Q:如果您有在擁有數千名用戶的生產環境中處理 ldap 的經驗,您是否有事實可以分享,這些事實往往證明這種openldap
設定確實不穩定,並且確實建議使用其他 ldap 伺服器?
答案1
我使用 OpenLDAP 支援大約 10,000 名活躍用戶的用戶群,他們整天都依賴它來完成所有事情。問題很少見。許多服務都依賴它來進行身份驗證和其他操作。
然而,我們在負載平衡器、隱藏主控和熱備用主控後面有 4 個唯讀副本(從屬/消費者)。曾經有 2 台前端伺服器,但我們在某些高峰時段遇到了負載問題(當時有 4,000 名左右的用戶拼命地試圖在同一秒鐘訪問它)。對 LDAP 的所有寫入存取都是透過我們的程式碼進行的。
該設備和作業系統都很舊,我們正在努力用新的設定替換它,該設定將返回到只有 2 個副本(不做太多其他事情)和一對主設備之間的“鏡像模式”複製HA配置。同樣,問題很少。
我們曾經遇到過一些複製失敗的問題,但這主要是因為我們使用 slurpd 而不是syncrepl 時造成的。此外,伺服器的不正常關閉可能會損壞資料。
根據我的經驗,在大規模生產環境中運行 OpenLDAP 的關鍵是:
- 了解 LDAP 和 OpenLDAP 的人出色地。最好是不只一個人。
- 很好地了解基礎設施的所有其他直接相關部分的人。
- 一個明白如何做的人OpenLDAP 複製作品。
- 合理的認識BerkeleyDB 選項(或您正在使用的任何後端),因為預設值不太正確。
- 高可用從站。不只 1. 更好:真正實現負載平衡。
- **主動-被動主控(主動-主動主控複製本質上很棘手)
- 我們將 LDAP 資料備份到LDIF 每小時一次並在磁碟上保留幾天的內容。 (整個伺服器每晚都會備份)
- 我們有腳本快點把一個破碎的奴隸帶回來到乾淨的當前資料副本
- 我們有腳本快點恢復破碎的主人來自 LDIF 備份(透過 slapadd)
- 我們可以快速切換到備用主站。 (腳本)
- 我們監控複製連線是否處於活動狀態
- 我們監控所有從站上的複製 ID 是否是最新的
- 我們(不太頻繁地)監視從站的全部內容是否與主站相符。
但基本上,如果它是您的基礎設施的關鍵部分,那麼您團隊中的某個人應該真正理解它。
附錄:根據請求,DB_CONFIG
來自我的 openldap DB 目錄的檔案。看著http://docs.oracle.com/cd/E17076_02/html/api_reference/C/configuration_reference.html了解詳情。
set_cachesize 0 536870912 1
set_flags DB_TXN_NOSYNC
set_flags DB_TXN_WRITE_NOSYNC
set_lg_regionmax 268435456
set_lg_max 536870912
set_lg_bsize 134217728