Linux集群認證

當組織添加應用程序和服務時，將認證和密碼服務集中化可以增加安全性、減少管理開銷及開發人員的負擔。但是，將所有服務聚集到單個服務器上會引起可靠性問題。對于企業認證服務，高可用性尤其關鍵，因為在許多情況中，當認證停止工作時，整個企業都將陷入停頓。

我們使用 LDAP（輕量級目錄訪問協議，Lightweight Directory Aclearcase/" target="_blank" >ccess Protocol）服務器來提供認證服務，各種應用程序都可以訂閱這些服務。為了提供高度可用的 LDAP 服務器，我們使用來自 Linux-HA（www.linux-ha.org）倡議的 heartbeat 軟件包。我們也提供一個示例，設置 Apache Web 服務器以使用 LDAP 認證。

我們使用 OpenLDAP 軟件包（ www.openldap.org），它是幾種 Linux 分發版的組成部分。它隨 RedHat 7.1 一起提供，其當前下載版本是 2.0.11。

RFC 的 2251 和 2253 中定義了 LDAP 標準。存在幾種 LDAP 的商業實現，其中包括密歇根大學（University of Michigan）的實現和 Netscape 的實現。OpenLDAP 基金會是作為“為開發健壯的、商業級別的、功能完善和開放源碼的 LDAP 應用程序與開發工具套件而協力完成的工作”創建的（請參閱 www.openldap.org）。OpenLDAP V1.0 于 1998 年 8 月發行。其當前主版本是 2.0（2000 年 8 月 31 日發布），添加了 LDAPv3 支持。

正如所有好的網絡服務一樣，LDAP 旨在跨多個服務器運行。本文使用了 LDAP 的兩個特性 — 復制（replication）和 引用（referral）。

引用機制使您能跨多服務器分割 LDAP 名稱空間，并能以層次結構的形式安排 LDAP 服務器。LDAP 在一個特定目錄名稱空間中只允許有一個主服務器。

復制由 OpenLDAP 復制守護程序 slurpd驅動。slurpd 定期醒來并檢查主服務器上的日志文件，看是否有更新。更新隨后被傳遞到從服務器。讀請求可以由任一服務器應答，但更新只能在主服務器上進行。對從服務器的更新請求會生成一個引用消息，該消息會給出主服務器的地址。跟蹤引用和重新嘗試更新是客戶機的職責。OpenLDAP 沒有內置方法來跨已復制服務器分發查詢，因此必須使用 IP 發射器（sprayer）／扇出（fanout）程序（如 balance）。

為了實現可靠性目標，我們將一對服務器以群集方式組織在一起。我們可以在服務器間使用共享存儲器，維護一個數據副本。但為了簡單起見，我們選擇進行無共享（shared-nothing）的實現。LDAP 數據庫通常很小，而且更新頻率較低（提示：如果您的 LDAP 數據集確實較大，請考慮用引用將名稱空間劃分成較小的部分）。重新啟動故障節點時，對無共享設置的確需要注意：在重新啟動之前，必須將所有新的更改添加到故障節點上的數據庫。稍后，我們將演示一個示例。

在開始之前，讓我們澄清一個細微的混淆。大多數 HA（高可用性，High Availability）群集都有一個名為“heartbeat”的系統持活（system-keepalive）功能。HA 軟件使用 heartbeat 以監控群集中節點的健康狀態。Linux-HA（ www.linux-ha.org）組提供了開放源碼群集軟件。他們軟件包的名稱是 Heartbeat（目前是 Heartbeat-0.4.9）。這可能導致一些可以理解的混淆（喔，它有時也使我糊涂）。在本文中，我們將把 Linux-HA 軟件包稱為“Heartbeat”，而把一般性的概念稱為“heartbeat”。

Linux-HA 項目作為 Linux-HA HOWTO（Harald Milz 撰寫）的產物于 1998 年啟動。該項目目前由 Alan Robertson 和其他許多志愿開發人員領導。版本 0.4.9 于 2001 年早期發布。

Heartbeat 通過通信媒介監控節點的可用狀態，媒介通常是串行線或以太網。最好有多個冗余媒介，因此我們使用了一條串行線和一個以太網鏈路。每個節點運行一個守護程序進程（名為“heartbeat”）。主守護程序派生子進程以對每個 heartbeat 媒介進行讀寫，并且派生狀態進程。當檢測到節點終止時，Heartbeat 運行 shell 腳本以在輔助節點上啟動（或停止）服務。在設計時，規定這些腳本使用與系統 init 腳本（通常位于 /etc/init.d）相同的語法。它還提供了用于文件系統、Web 服務器和虛擬 IP 故障轉移的缺省腳本。

假設有兩個匹配的 LDAP 服務器，我們可以使用幾種配置。首先，我們可以實現‘冷備用’。主節點有一個虛擬 IP 和正在運行的服務器。輔助節點處于空閑狀態。當主節點出現故障時，服務器實例和 IP 會轉移到“冷”節點。這是容易實現的，但主服務器和輔助服務器之間的數據同步卻是個問題。要解決這個問題，我們可以這樣配置群集，即在兩個節點上都配置處于運行狀態的服務器。主節點運行主 LDAP 服務器，輔助節點則運行從實例。對主服務器的更新通過 slurpd 被立即傳遞到從服務器。

主節點的故障使得輔助節點要響應查詢，但現在我們還不能更新。為了提供更新，在故障轉移時，我們要重新啟動輔助服務器并將它提升為主服務器。

這給予我們完整的 LDAP 服務，但卻增加了一個問題 — 如果向輔助服務器作出了更新，那么在允許它重新啟動之前必須修復主服務器。Heartbeat 支持‘nice failback’選項，該選項禁止有故障的節點在故障轉移后重新獲得資源，這會更令人滿意。在本文中，我們手工演示重新啟動。我們的樣本配置將使用 Heartbeat 提供的虛擬 IP 工具。如果需要支持較重的查詢負載，則會用同時向主從服務器分發查詢的 IP 發射器取代虛擬 IP。在這一情況中，對從服務器作出的更新請求會產生引用。對引用的跟蹤不是自動的；必須將該功能構建到客戶機應用程序中。除了復制偽指令外，主節點和從節點是以完全相同的方式配置的。 主服務器配置文件指明復制日志文件的位置（第 16 行），并且有一份從服務器的清單，這些從服務器是具有憑證信息的復制目標（第 34-36 行）。

34  replica host=slave5:389

35          binddn="cn=Manager,dc=lcc,dc=ibm,dc=com";

36          bindmethod=simple credentials=secret

從服務器配置文件不指明主服務器；相反，它列出復制所需的憑證信息（第 33 行）。

常規 Heartbeat 準備

有幾個較好的基本 Heartbeat 配置示例可供使用（請參閱本文的結尾部分）。以下是我們的配置中相關的內容。我們的配置非常簡單，所以沒有多少內容。缺省情況下，所有的配置文件都保存在 /etc/ha.d/中。

ha.cf包含群集的全局定義。我們對所有的超時都采用缺省值。

# Timeout intervals

keepalive 2 

# keepalive could be set to 1 second here 

deadtime 10

initdead 120

# define our communications

#       serial  serialportname ...

serial  /dev/ttyS0

baud    19200

# Ethernet information

udpport 694

udp     eth1

# and finally, our node id's 

#       node    nodename ...    -- must match uname -n

node    slave5

node    slave6

haresources該文件是配置故障轉移的地方。在文件的底部有些有趣的東西。

我們在這里指明了三件事。資源的主要所有者是節點‘slave6’（該名稱必須與您打算設為主節點機器的‘uname -n’輸出相匹配）。我們的服務地址（虛擬 IP）是‘192.168.10.51’（本示例是在專用實驗室網絡完成的，所以使用 192.168 地址）。服務腳本的名稱是‘slapd’。Hearbeat 將在 /etc/ha.d/resource.d 和 /etc/init.d 中尋找腳本。

對于簡單“冷備用”情況，我們可以不加修改地使用標準 /etc/init.d/slapd 腳本。我們希望做一些特別的事，因此我們創建了自己的 slapd 腳本，該腳本存儲在 /etc/ha.d/resource.d/中。 Heartbeat 將該目錄放置在其搜索路徑中的第一位，因此我們不必擔心會運行 /etc/init.d/slapd 腳本。但是，您應該檢查以確保引導時不再啟動 slapd（從 /etc/rc.d 樹結構除去所有 S*slapd 文件）。首先，我們在第 17 行和第 18 行指明 slapd 服務器的啟動配置文件。

該腳本遵循標準 init.d 語法，因此啟動信息包含在從第 21 行開始的 test_start() 函數中。首先，我們停止當前運行的所有 slapd 實例。在第 39 行，我們使用主服務器配置文件啟動主服務器。我們的設計將遵循這樣的規則：如果主節點和輔助節點都已啟動，則在主節點上將 slapd 作為主服務腳本啟動，在輔助節點上將 slapd 作為從服務腳本啟動，并啟動復制守護程序。如果只有一個節點啟動，則將 slapd 作為主服務腳本啟動。將虛擬 IP 綁定到 slapd 主服務腳本。要完成這一點，我們必須知道哪個節點正在執行該腳本，如果是主節點，那么我們需要知道輔助節點的狀態。重要的內容在腳本的‘start’分支中。因為我們已經在 Heartbeat 配置中指明了主節點，所以我們知道當 test_start() 函數運行時，它運行在 Heartbeat 主節點上（因為 Heartbeat 使用 /etc/init.d/ 腳本，因此所有的腳本都用參數“start|stop|restart”調用）。當調用腳本時，Heartbeat 會設置許多環境變量。下面是我們感興趣的一個：

可以使用‘HA_CURHOST’值來了解何時正在主節點（slave6）上執行以及何時處于故障轉移中（HA_CURHOST 應是‘slave5’）?，F在我們需要知道另一個節點的狀態。要了解這一點，可以“詢問” Heartbeat。我們將使用隨 Heartbeat 一同提供的 api_test.c文件，并創建一個簡單的客戶機來“詢問”節點狀態（api_test.c 文件有許多內容都與客戶機有關，我們只需除去不需要的內容，然后添加一條輸出語句）。請注意程序中執行查詢的第 31 行。

編譯后，我們將文件安裝在 /etc/ha.d/resource.d/中。程序的名稱為‘other_state’。以下是訪問完整的故障轉移腳本的鏈接，我們還是從與 Heartbeat 一同提供的示例腳本開始，并增加少許修改：

測試

我們現在可以在兩個服務器上都啟動 Heartbeat。Heartbeat 文檔包含一些有關測試基本設置的信息，所以我們將不在這里重復。在連接了兩種 heartbeat 媒介的情況下，您應該看到六個 heartbeat 進程正在運行。為了驗證故障轉移，我們做了幾種測試。為了提供測試用的客戶機，我們創建了一個簡單的 KDE 應用程序，該應用程序查詢服務器并顯示連接的狀態。真正的客戶機在這種情況下只查詢虛擬 IP，但我們查詢所有的三個 IP，以作為演示之用。為進行該測試，我們每小時發送一萬條查詢。

S6 是主 LDAP 服務器，S5 是活動的備用服務器。下面的框代表虛擬 IP。在正常狀態下，S5 和 S6 都為綠色，表明成功的查詢。

首先，我們停止主節點上的 heartbeat 進程。在此情況下，從機器在 10 秒鐘的節點超時出現后獲得資源，如日志摘錄中所示：接管過程包括啟動腳本中額外的 2 秒延遲。

Sep  7 10:28:21 slave5 heartbeat: info: Running

/etc/ha.d/rc.d/shutdone shutdone

Sep  7 10:28:32 slave5 heartbeat[3381]: WARN: node slave6: is dead

Sep  7 10:28:32 slave5 heartbeat[3381]: info: Link slave6:/dev/ttyS0 dead.

Sep  7 10:28:32 slave5 heartbeat[3381]: info: Link slave6:eth1

dead.

Sep  7 10:28:32 slave5 heartbeat: info: Running /etc/ha.d/rc.d/status status

Sep  7 10:28:32 slave5 heartbeat: info: Running /etc/ha.d/rc.d/ifstat ifstat

Sep  7 10:28:32 slave5 heartbeat: info: Running /etc/ha.d/rc.d/ifstat ifstat

Sep  7 10:28:32 slave5 heartbeat: info: Taking over resource group 192.168.10.51

Sep  7 10:28:32 slave5 heartbeat: info: Acquiring resource group: slave6 192.168.10.51 slapd

Sep  7 10:28:32 slave5 heartbeat: info: Running /etc/ha.d/resource.d/IPaddr 192.168.10.51 start

Sep  7 10:28:32 slave5 heartbeat: info: ifconfig eth0:0 192.168.10.51 netmask 255.255.255.0 \

broadcast 192.168.10.255

Sep  7 10:28:32 slave5 heartbeat: info: Sending Gratuitous Arp for 192.168.10.51 on eth0:0 [eth0]

Sep  7 10:28:32 slave5 heartbeat: info: Running /etc/ha.d/resource.d/slapd  start

Sep  7 10:28:32 slave5 heartbeat: info: /etc/ha.d/resource.d/slapd: Starting

以下是應用程序的查詢流：

主節點當機，現在由輔助節點提供虛擬 IP。S5 和虛擬 IP 顯示為綠色，服務器 S6 不可用，指示器為紅色。

重新啟動群集之后，我們通過對主節點斷電來造成一次故障。在 10 秒超時到時間以后，輔助節點再一次獲取了資源。最后，我們通過拔掉串行接口和以太網接口來模擬兩節點之間互連的完全失敗。節點間通信的失敗導致兩臺機器都試圖充當主節點。這種情形被稱為 “裂腦（split-brain）”。Heartbeat 在這種情形下的缺省行為說明了為什么 Heartbeat 需要多個使用不同媒介的互連媒介。在共享存儲器設置中，存儲器互連也可以作為 heartbeat 媒介使用，這減少了“裂腦”的機會。以下是來自 ha-log 的樣本，它顯示了關機過程：

heartbeat: 2001/09/07_14:49:46 info: mach_down takeover complete.

heartbeat: 2001/09/07_14:50:36 ERROR: TTY write timeout on [/dev/ttyS0] (no connection?)

heartbeat: 2001/09/07_14:52:53 WARN: Cluster node slave6 returning after partition

heartbeat: 2001/09/07_14:52:53 info: Heartbeat shutdown in progress.

heartbeat: 2001/09/07_14:52:53 ERROR: 105 lost packet(s) for [slave6] [191:297]

heartbeat: 2001/09/07_14:52:53 ERROR: lost a lot of packets!

heartbeat: 2001/09/07_14:52:53 info: Link slave6:eth1 up.

heartbeat: 2001/09/07_14:52:53 WARN: Late heartbeat: Node slave6: interval 211920 ms

heartbeat: 2001/09/07_14:52:53 info: Node slave6: status active

heartbeat: 2001/09/07_14:52:53 info: Giving up all HA resources.

heartbeat: 2001/09/07_14:52:53 info: Running /etc/ha.d/rc.d/status status

heartbeat: 2001/09/07_14:52:53 info: Running /etc/ha.d/rc.d/ifstat ifstat

heartbeat: 2001/09/07_14:52:53 info: Running /etc/ha.d/rc.d/shutdone shutdone

heartbeat: 2001/09/07_14:52:53 info: Releasing resource group: slave6 192.168.10.51 slapd

heartbeat: 2001/09/07_14:52:53 info: Running /etc/ha.d/resource.d/slapd  stop

heartbeat: 2001/09/07_14:52:53 info: /etc/ha.d/resource.d/slapd: Shutting down

heartbeat: 2001/09/07_14:52:53 info: Running /etc/ha.d/resource.d/IPaddr 192.168.10.51 stop

heartbeat: 2001/09/07_14:52:53 info: IP Address 192.168.10.51 released

heartbeat: 2001/09/07_14:52:54 info: All HA resources relinquished.

heartbeat: 2001/09/07_14:52:54 info: Heartbeat shutdown in progress.

heartbeat: 2001/09/07_14:52:54 info: Giving up all HA resources.

heartbeat: 2001/09/07_14:52:54 info: All HA resources relinquished.

heartbeat: 2001/09/07_14:52:55 info: Heartbeat shutdown complete.

應在選擇超時值時考慮這一問題。如果超時太短，負載繁重的系統會錯誤地觸發接管，從而產生明顯的“裂腦”關機。請參閱 Linux-ha FAQ 文檔以獲得有關這一點的更多信息。

如果當主 LDAP 服務器當機時，對 LDAP 名稱空間進行了更新，則必須在重新啟動主服務器之前重新同步 LDAP 數據庫。有兩種方法可做到這一點。如果可以中斷服務的話，可以在 LDAP 服務器停止后手工復制數據庫（缺省情況下，數據文件被放置在 /usr/local/var 中）。也可以使用 OpenLDAP 復制來恢復數據庫而無需服務中斷。首先，在以前的主節點上將 LDAP 服務器作為從服務器啟動。然后在當前主節點上啟動 slurpd 守護程序。在前主節點退出服務期間收到的更改將從新主節點“推”到原來的節點上。最后，在以前的主節點上停止從 LDAP 服務器，并啟動 Heartbeat。這將導致向原始配置進行故障回復。

這里是向 LDAP 服務器進行訂閱的應用程序示例。該應用程序是 Apache Web 服務器，使用 mod_auth_ldap 軟件包。

本文是一個非常簡單的示例，使用開放源碼軟件創建一些高度可用的基本網絡服務。網絡服務（包括 LDAP）很少需要大型服務器。由群集提供的額外可靠性以及服務器和數據文件的復制可以增加服務可用性。系統經歷了所有的測試，在所有情況下都在 15 秒內進行了故障轉移。假如對系統負載和利用率有較好的理解，可以把故障轉移時間減少到這個閾值以下。

（責任編輯：城塵）