使用简单的5个步骤设置 Web服务器集群
通過在多個處理器之間分擔(dān)工作負(fù)載并采用多種軟件恢復(fù)技術(shù),能夠提供高度可用的環(huán)境并提高環(huán)境的總體 RAS(可靠性、可用性和可服務(wù)性)。可以得到的好處包括:更快地從意外中斷中恢復(fù)運行,以及將意外中斷對終端用戶的影響降至最低。
為了更好地理解這篇文章,您需要熟悉 Linux 和連網(wǎng)的基本知識,還需要配置好 Apache 服務(wù)器。本文的示例基于標(biāo)準(zhǔn)的 SUSE Linux Enterprise Server 10 (SLES10) 安裝,但是使用其他版本的明智用戶也應(yīng)該可以采用文中展示的方法。
本文展示了健壯的 Apache Web 服務(wù)器堆棧,它擁有 6 個 Apache 服務(wù)器節(jié)點(雖然 3 個節(jié)點就足以支持文中闡述的步驟),以及 3 個 Linux Virtual Server (LVS) 控制器。我們使用 6 個 Apache 服務(wù)器節(jié)點,可以在測試時實現(xiàn)更高的工作負(fù)載吞吐量,從而模擬更大型的部署。文中展示的架構(gòu)應(yīng)該可以支持更多的控制器和后端 Apache 服務(wù)器(在資源允許的情況下),但是我們并未進(jìn)行更深入的嘗試。圖 1 展示了使用 Linux Virtual Server 和 linux-ha.org 組件的實現(xiàn)。
圖 1. Linux Virtual Servers 和 Apache
如圖 1 所示,外部客戶機向單個 IP 地址發(fā)送通信量,而該 IP 地址可能存在于某個 LVS 控制器機器上。控制器機器積極地監(jiān)控接收其發(fā)送工作的 Web 服務(wù)器池。
注意,圖 1 左側(cè)的工作負(fù)載進(jìn)程指向右側(cè)。此集群的浮動資源地址在一個給定時間將位于某個 LVS 控制器實例上。可以使用一個圖形化的配置工具手動地移動服務(wù)地址,或者(這種方法更常見)自行管理服務(wù)地址,視 LVS 控制器的狀態(tài)而定。如果某個控制器變得不合格(由于連接丟失、軟件故障或類似原因),那么服務(wù)地址將自動地被重新分配給一個合格的控制器。
浮動服務(wù)地址必須跨越兩個或多個離散的硬件實例,以便在一個物理機器連接丟失的情況下繼續(xù)操作。使用本文展示的配置決策,每個 LVS 控制器都可以將包轉(zhuǎn)發(fā)給任何的實際 Apache Web 服務(wù)器,并且與服務(wù)器的物理位置或服務(wù)器與提供浮動服務(wù)地址的活動控制器的接近程度無關(guān)。本文展示了每個 LVS 控制器如何積極地監(jiān)控 Apache 服務(wù)器,以確保只向正常運作的后端服務(wù)器發(fā)送請求。
使用這種配置,技術(shù)人員可以成功地讓整個 Linux 實例失效,而且不會中斷在浮動服務(wù)地址上啟用的用戶服務(wù)(通常是 http 和 https Web 請求)。
Linux Virtual Server 術(shù)語新手必讀
LVS 控制器:Linux Virtual Server 控制器是一種系統(tǒng),該系統(tǒng)接受任意的引入通信量并將其傳遞給任意數(shù)量的 realserver。然后接受來自 realserver 的響應(yīng)并將其傳回發(fā)出請求的客戶機。控制器需要以一種透明的方式執(zhí)行任務(wù),使客戶機永遠(yuǎn)不會知道執(zhí)行實際工作負(fù)載處理的是 realserver。
LVS 控制器本身需要能夠?qū)崿F(xiàn)資源(具體而言,指的是用于偵聽引入通信量的虛擬 IP 地址)之間的浮動,從而避免單點故障。LVS 控制器實現(xiàn)浮動 IP 地址的方法是利用 LVS 的 Heartbeat 組件。這允許每個配置好的、運行 Heartbeat 的控制器確保有且只有一個控制器聲明處理引入請求的虛擬 IP 地址。
除了能夠浮動服務(wù) IP 地址外,控制器還需要能夠監(jiān)控執(zhí)行實際工作負(fù)載處理的 realserver 的狀態(tài)。控制器必須要了解哪些 realserver 可以一直用于工作負(fù)載處理。為監(jiān)控 realserver 使用了 mon 包。繼續(xù)閱讀,了解關(guān)于 配置 Heartbeat 和 配置 mon 的細(xì)節(jié)。
Realserver:這些系統(tǒng)是提供 HA 服務(wù)的真正的 Web 服務(wù)器實例。使用多個 realserver 提供 HA 所需的服務(wù)。在本文的環(huán)境中,實現(xiàn)了 6 個 realserver,但是一旦 LVS 基礎(chǔ)設(shè)施的其余部分就緒后,添加更多的 realserver 就是小事一樁了。
在本文中,假定 realserver 運行的都是 Apache Web Server,但是其他服務(wù)實現(xiàn)起來也同樣容易(實際上,作為文中展示的方法的附加測試,受支持的 SSH 服務(wù)也很容易實現(xiàn))。
使用的 realserver 是常用的 Apache Web 服務(wù)器,只有一個明顯的區(qū)別,即它們被配置為以類似 LVS 控制器的浮動 IP 地址的形式進(jìn)行響應(yīng),或以控制器使用的浮動 IP 地址所對應(yīng)的虛擬主機名的形式響應(yīng)。更改 Apache 配置文件中的一行即可完成這一操作。
您可以使用一個完全開源的軟件組合復(fù)制這些配置,該軟件組合包括,linux-ha.org 所提供的 Heartbeat 技術(shù)組件,以及通過 mon 和 Apache 進(jìn)行監(jiān)控的服務(wù)器。正如前面提到的,我們將使用 SUSE Linux Enterprise Server 測試配置。
LVS 場景中使用的所有機器都位于同一個子網(wǎng)中,使用的是 Network Address Translation (NAT) 配置。在 Linux Virtual Server Web 站點(請參閱 參考資料)上描述了很多其他網(wǎng)絡(luò)結(jié)構(gòu);為簡便起見我們使用 NAT。為了更加安全,您應(yīng)該限制穿過防火墻的通信量,只允許浮動 IP 地址在 LVS 控制器之間傳遞。
Linux Virtual Server 套件提供了幾種不同的方法以完成透明的 HA 后端基礎(chǔ)設(shè)施。每種方法都各有利弊。LVS-NAT 操作控制器服務(wù)器的方式是,獲取發(fā)往特定配置的端口的引入包,并動態(tài)地在包的頭部重寫目的地址。控制器本身并不處理包的數(shù)據(jù)內(nèi)容,而是將其傳給 realserver。包中的目的地址被重寫為指向集群中的一個給定的 realserver。然后將包放回網(wǎng)絡(luò)中以傳遞給 realserver,而 realserver 并沒有意識到發(fā)生了什么情況。對于 realserver,它只是直接從外部接收請求。接著,realserver 的回復(fù)被發(fā)回控制器,在控制器中重寫回復(fù),使其具有客戶機所指向的浮動 IP 地址的源地址,然后再發(fā)往原始客戶機。
使用 LVS-NAT 方法意味著 realserver 需要簡單的 TCP/IP 功能。LVS 操作的其他模式,即 LVS-DR 和 LVS-Tun,需要更加復(fù)雜的連網(wǎng)概念。選擇 LVS-NAT 的最主要的好處是只需對 realserver 配置做很少量的更改。實際上,最難的部分是牢記適當(dāng)?shù)卦O(shè)置路由語句。
步驟 1:構(gòu)建 realserver 圖像
以構(gòu)建 Linux 服務(wù)器實例池開始,每個實例運行 Apache Web 服務(wù)器,并確保服務(wù)器按預(yù)想的情況運作,將 Web 瀏覽器指向每個 realserver 的 IP 地址。通常,標(biāo)準(zhǔn)安裝被配置為在自己的 IP 地址上偵聽 80 端口(換言之,為每個 realserver 使用不同的 IP)。
接下來,在每個服務(wù)器上配置默認(rèn)的 Web 頁面以顯示一個靜態(tài)頁面,其中包含了為頁面提供服務(wù)的機器的主機名。這確保了您可以一直了解測試期間您所連接的機器。
為防萬一,檢查在這些系統(tǒng)上轉(zhuǎn)發(fā)的 IP 是否為 OFF,方法是發(fā)出以下命令:
# cat /proc/sys/net/ipv4/ip_forward
如果不是 OFF 并且您需要禁用它,請發(fā)出以下命令:
# echo "0" >/proc/sys/net/ipv4/ip_forward
確保每個 realserver 都正常地偵聽 http 端口 (80) 的一個簡單方法是,使用外部系統(tǒng)并執(zhí)行掃描。在一些與您的服務(wù)器連網(wǎng)的其他系統(tǒng)中,可以使用 nmap 工具以確保服務(wù)器執(zhí)行偵聽操作。
清單 1. 使用 nmap 確保服務(wù)器執(zhí)行偵聽操作
| # nmap -P0 192.168.71.92Starting nmap 3.70 ( http://www.insecure.org/nmap/ ) at 2006-01-13 16:58 EST Interesting ports on 192.168.71.92: (The 1656 ports scanned but not shown below are in state: closed) PORT STATE SERVICE 22/tcp open ssh 80/tcp filtered http 111/tcp open rpcbind 631/tcp open ipp |
?
要注意的是,某些組織不贊成使用端口掃描工具,如 nmap:在使用工具之前請獲取組織的批準(zhǔn)。
接下來,將 Web 瀏覽器指向每個 realserver 的實際 IP 地址,從而確保每個 realserver 按照預(yù)期為相應(yīng)頁面提供服務(wù)。完成此操作后請轉(zhuǎn)到步驟 2。
回頁首
步驟 2:安裝和配置 LVS 控制器
現(xiàn)在,您可以構(gòu)建所需的 3 個 LVS 控制器實例。如果您第一次為每個 LVS 控制器安裝 SUSE Linux Enterprise Server 10,在初始安裝時,請確保選擇與 heartbeat、ipvsadm 和 mon 相關(guān)的高可用性包。如果您擁有現(xiàn)有的安裝,您就可以一直使用包管理工具,如 YAST,在完成基礎(chǔ)安裝之后添加這些包。強烈建議您將每個 realserver 添加到 /etc/hosts 文件中。這將確保為引入請求提供服務(wù)時,不會產(chǎn)生 DNS 相關(guān)的延遲。
此時,再次檢查每個目錄是否都能對每個 realserver 執(zhí)行即時的 ping 操作:
清單 2. 對 realserver 執(zhí)行 Ping 操作
| # ping -c 1 $REAL_SERVER_IP_1# ping -c 1 $REAL_SERVER_IP_2# ping -c 1 $REAL_SERVER_IP_3# ping -c 1 $REAL_SERVER_IP_4# ping -c 1 $REAL_SERVER_IP_5# ping -c 1 $REAL_SERVER_IP_6 |
?
完成此操作后,從服務(wù)器中的本地包管理工具中安裝 ipvsadm、Heartbeat 和 mon。回想一下,Heartbeat 將被用于控制器內(nèi)部通信,而 mon 將被每個控制器用于維護關(guān)于每個 realserver 的狀態(tài)信息。
回頁首
步驟 3:在控制器上安裝和配置 Heartbeat
如果您以前使用過 LVS,請記住,在 SLES10 上配置 Heartbeat Version 2 與在 SLES9 上配置 Heartbeat Version 1 截然不同。其中,Heartbeat Version 1 使用的文件(haresource、ha.cf 和 authkey)存儲在 /etc/ha.d/ 目錄中,而 Version 2 使用新的基于 XML 的 Cluster Information Base (CIB)。推薦的升級方法是使用 haresource 文件生成新的 cib.xml 文件。典型的 ha.cf 文件的內(nèi)容如清單 3 所示。
我們從 SLES9 系統(tǒng)中獲取 ha.cf 文件,并且為 Version 2 添加底部的 3 行(respawn、pingd 和 crm)。如果您擁有現(xiàn)有的 version 1 配置,您也可以選擇執(zhí)行同樣的操作。如果您要使用這些指令執(zhí)行新安裝,您可以復(fù)制清單 3 并進(jìn)行修改以適應(yīng)您的生產(chǎn)環(huán)境。
清單 3. /etc/ha.d/ha.cf config 文件樣例
| # Log to syslog as facility "daemon"use_logd onlogfacility daemon# List our cluster members (the realservers)node litsha22node litsha23node litsha21# Send one heartbeat each secondkeepalive 3# Warn when heartbeats are latewarntime 5# Declare nodes dead after 10 secondsdeadtime 10# Keep resources on their "preferred" hosts - needed for active/active#auto_failback on# The cluster nodes communicate on their heartbeat lan (.68.*) interfacesucast eth1 192.168.68.201ucast eth1 192.168.68.202ucast eth1 192.168.68.203# Failover on network failures# Make the default gateway on the public interface a node to ping# (-m) -> For every connected node, add <integer> to the value set# in the CIB, * Default=1# (-d) -> How long to wait for no further changes to occur before# updating the CIB with a changed attribute# (-a) -> Name of the node attribute to set, * Default=pingdrespawn hacluster /usr/lib/heartbeat/pingd -m 100 -d 5s# Ping our router to monitor ethernet connectivityping litrout71_vip#Enable version 2 functionality supporting clusters with > 2 nodescrm yes |
?
respawn 指令在運行時指定某個程序的運行和監(jiān)控。如果此程序退出時的退出碼不是 100,程序?qū)⒆詣又貑ⅰ5谝粋€參數(shù)是運行程序的用戶 id,第二個參數(shù)是要運行的程序。-m 參數(shù)將 pingd 屬性設(shè)為從當(dāng)前機器可獲得的 ping 節(jié)點數(shù)的 100 倍,而 -d 參數(shù)在修改 CIB 中的 pingd 屬性之前將延遲 5 秒。ping 指令用于聲明 Heartbeat 的 PingNode,而 crm 指令指定了 Heartbeat 應(yīng)運行 1.x-style 集群管理器或 2.x-style 集群管理器,后者支持 2 個以上的節(jié)點。
對于所有的控制器這個文件都應(yīng)該相同。適當(dāng)?shù)卦O(shè)置權(quán)限使 hacluster 守護程序可以讀取文件也絕對重要。否則將導(dǎo)致日志文件中出現(xiàn)大量難于調(diào)試的警告。
對于某個版本的 1-style Heartbeat 集群,haresources 文件指定了節(jié)點名和連網(wǎng)信息(浮動 IP、關(guān)聯(lián)接口和廣播)。對我們而言,此文件仍然沒有變化:
litsha21 192.168.71.205/24/eth0/192.168.71.255
此文件將只用于生成 cib.xml 文件。
authkeys 文件指定了一個共享的密匙以允許控制器之間進(jìn)行通信。共享密鑰就是一個密碼,所有的 heartbeat 節(jié)點都知道這個密碼并使用它進(jìn)行相互通信。密鑰的使用避免了無關(guān)方對 heartbeat 服務(wù)器節(jié)點的影響。此文件也沒有變化:
auth 1
1 sha1 ca0e08148801f55794b23461eb4106db
接下來的幾步將向您展示如何將 version 1 的 haresources 文件轉(zhuǎn)換為 version 2 的基于 XML 的配置格式 (cib.xml)。雖然可以直接復(fù)制并使用清單 4 中的配置文件作為起點,但是強烈建議您針對自己的部署進(jìn)行配置調(diào)整。
為了將文件格式轉(zhuǎn)換為部署中使用的基于 XML 的 CIB (Cluster Information Base) 文件,請發(fā)出以下命令:
python /usr/lib64/heartbeat/haresources2cib.py /etc/ha.d/haresources > /var/lib/heartbeat/crm/test.xml
將會生成一個類似清單 4 所示的配置文件,并置于 /var/lib/heartbeat/crm/test.xml 中。
清單 4. CIB.xml 樣例文件
| <cib admin_epoch="0" have_quorum="true" num_peers="3" cib_feature_revision="1.3"generated="true" ccm_transition="7" dc_uuid="114f3ad1-f18a-4bec-9f01-7ecc4d820f6c"epoch="280" num_updates="5205" cib-last-written="Tue Apr 3 16:03:33 2007"><configuration><crm_config><cluster_property_set id="cib-bootstrap-options"><attributes><nvpair id="cib-bootstrap-options-symmetric_cluster"name="symmetric_cluster" value="true"/><nvpair id="cib-bootstrap-options-no_quorum_policy"name="no_quorum_policy" value="stop"/><nvpair id="cib-bootstrap-options-default_resource_stickiness"name="default_resource_stickiness" value="0"/><nvpair id="cib-bootstrap-options-stonith_enabled"name="stonith_enabled" value="false"/><nvpair id="cib-bootstrap-options-stop_orphan_resources"name="stop_orphan_resources" value="true"/><nvpair id="cib-bootstrap-options-stop_orphan_actions"name="stop_orphan_actions" value="true"/><nvpair id="cib-bootstrap-options-remove_after_stop"name="remove_after_stop" value="false"/><nvpair id="cib-bootstrap-options-transition_idle_timeout"name="transition_idle_timeout" value="5min"/><nvpair id="cib-bootstrap-options-is_managed_default"name="is_managed_default" value="true"/><attributes><cluster_property_set><crm_config><nodes><node uname="litsha21" type="normal" id="01ca9c3e-8876-4db5-ba33-a25cd46b72b3"><instance_attributes id="standby-01ca9c3e-8876-4db5-ba33-a25cd46b72b3"><attributes><nvpair name="standby" id="standby-01ca9c3e-8876-4db5-ba33-a25cd46b72b3"value="off"/><attributes><instance_attributes><node><node uname="litsha23" type="normal" id="dc9a784f-3325-4268-93af-96d2ab651eac"><instance_attributes id="standby-dc9a784f-3325-4268-93af-96d2ab651eac"><attributes><nvpair name="standby" id="standby-dc9a784f-3325-4268-93af-96d2ab651eac"value="off"/><attributes><instance_attributes><node><node uname="litsha22" type="normal" id="114f3ad1-f18a-4bec-9f01-7ecc4d820f6c"><instance_attributes id="standby-114f3ad1-f18a-4bec-9f01-7ecc4d820f6c"><attributes><nvpair name="standby" id="standby-114f3ad1-f18a-4bec-9f01-7ecc4d820f6c"value="off"/><attributes><instance_attributes><node><nodes><resources><primitive class="ocf" provider="heartbeat" type="IPaddr" id="IPaddr_1"><operations><op id="IPaddr_1_mon" interval="5s" name="monitor" timeout="5s"/><operations><instance_attributes id="IPaddr_1_inst_attr"><attributes><nvpair id="IPaddr_1_attr_0" name="ip" value="192.168.71.205"/><nvpair id="IPaddr_1_attr_1" name="netmask" value="24"/><nvpair id="IPaddr_1_attr_2" name="nic" value="eth0"/><nvpair id="IPaddr_1_attr_3" name="broadcast" value="192.168.71.255"/><attributes><instance_attributes><primitive><resources><constraints><rsc_location id="rsc_location_IPaddr_1" rsc="IPaddr_1"><rule id="prefered_location_IPaddr_1" score="200"><expression attribute="#uname" id="prefered_location_IPaddr_1_expr"operation="eq" value="litsha21"/><rule><rsc_location><rsc_location id="my_resource:connected" rsc="IPaddr_1"><rule id="my_resource:connected:rule" score_attribute="pingd"><expression id="my_resource:connected:expr:defined" attribute="pingd"operation="defined"/><rule><rsc_location><constraints><configuration><cib> |
?
一旦生成配置文件后,將 test.xml 移到 cib.xml 中,將所有者改為 hacluster,將組改為 haclient,然后重啟 heartbeat 進(jìn)程。
現(xiàn)已完成 heartbeat 配置,對 heartbeat 進(jìn)行設(shè)置,使其在每個控制器的引導(dǎo)階段啟動。為此,在每個控制器上發(fā)出以下命令(或相對您的發(fā)行版的等效命令):
# chkconfig heartbeat on
重啟每個 LVS 控制器以確保 heartbeat 服務(wù)在引導(dǎo)階段正常啟動。通過首先暫停保存浮動資源 IP 地址的機器,您可以等候其他 LVS Director 映像建立 quorum,然后在幾秒鐘內(nèi)實例化最新選擇的主節(jié)點上的服務(wù)地址。當(dāng)您將暫停的控制器映像重新聯(lián)機時,機器將在所有的節(jié)點間重新建立 quorum,此時浮動資源 IP 可能傳輸回來。整個過程只會耗費幾秒鐘。
另外,此時,您可能希望使用圖形化工具處理 heartbeat 進(jìn)程 hb_gui(如圖 2 所示),手動地將 IP 地址在集群中移動,方法是將各種節(jié)點設(shè)置為備用或活動狀態(tài)。多次重試這些步驟,禁用并重新啟用活動的或不活動的各種機器。因為先前選中了配置策略,只要可 以建立 quorum,并且至少有一個節(jié)點合格,那么浮動資源 IP 地址就保持正常運作。在測試期間,您可以使用簡單的 ping 確保不會發(fā)生丟失包的情況。當(dāng)您完成試驗后,應(yīng)該對配置的健壯性有一個深刻的體會。在繼續(xù)操作之前請確保浮動資源 IP 的 HA 配置適當(dāng)。
圖 2. 用于 heartbeat 進(jìn)程的圖形化配置工具 hb_gui
圖 2 展示了登錄后的圖形控制臺的外觀,上面顯示了托管資源和相關(guān)的配置選項。注意,當(dāng)您首次啟動應(yīng)用程序時,必須登錄到 hb_gui 控制臺;使用何種憑證將取決于您的部署。
注意,圖 2 中 litsha2* 系統(tǒng)集群中的每個節(jié)點都處于運行狀態(tài)。標(biāo)記為 litsha21 的系統(tǒng)目前是活動節(jié)點,如 (IPaddr_1) 正下方鋸齒狀的附加資源所示。
另外要注意標(biāo)記為 “No Quorum Policy” 的選項的值為 “stop”。這指的是任何單獨的節(jié)點將釋放它所擁有的資源。這個決策的含義是,在任何給定時間,必須有 2 個 heartbeat 節(jié)點是活動狀態(tài),以便建立 quorum(換言之,一種 “少數(shù)服從多數(shù)” 的投票規(guī)則)。即使只有一個節(jié)點是活動的,完全運行的節(jié)點也會由于網(wǎng)絡(luò)故障丟失它與同級系統(tǒng)之間的連接,或者,如果兩個非活動的同級系統(tǒng)同時暫停,資源將 被自動釋放。
回頁首
步驟 4:使用 ipvsadm 命令創(chuàng)建 LVS 規(guī)則
下一步是獲取浮動資源 IP 地址并在其上進(jìn)行構(gòu)建。因為 LVS 要求對遠(yuǎn)端 Web 瀏覽器客戶機透明,所以所有的 Web 請求都必須經(jīng)過控制器過濾并傳給一個 realserver。然后,所有結(jié)果都需要傳回控制器,后者向發(fā)出 Web 頁面請求的客戶機返回響應(yīng)。
為了完成上述的請求和響應(yīng)流程,首先配置每個 LVS 控制器,從而發(fā)出以下命令啟用 IP 轉(zhuǎn)發(fā)(因此允許將請求傳給 realserver):
# echo "1" >/proc/sys/net/ipv4/ip_forward
# cat /proc/sys/net/ipv4/ip_forward
如果所有的操作都成功,那么第二個命令將返回一個 “1” 作為終端輸出。要永久性地添加此選項,請?zhí)砑?#xff1a;
'' IP_FORWARD="yes"
到 /etc/sysconfig/sysctl 中。
接下來,要通知控制器將引入的 HTTP 請求傳遞給 HA 浮動 IP 地址,接著再傳給 realserver,使用 ipvsadm 命令。
首先,清除舊的 ipvsadm 表:
# /sbin/ipvsadm -C
在配置新表之前,您需要決定希望 LVS 控制器使用何種工作負(fù)載分配。收到來自客戶機的連接請求后,控制器根據(jù)一個 “進(jìn)度表” 將 realserver 指派給客戶機,然后使用 ipvsadm 命令設(shè)置調(diào)度程序類型。可用的調(diào)度程序包括:
- Round Robin (RR):新的引入連接被依次指派給每個 realserver。
- Weighted Round Robin (WRR):使用附加的權(quán)重因子進(jìn)行 RR 調(diào)度以補償各種 realserver 功能(如附加 CPU、更多內(nèi)存等)的差異。
- Least Connected (LC):新連接指向具有最少連接數(shù)量的 realserver。不要求是最空閑的 realserver,但是以此為方向。
- Weighted Least Connection (WLC):帶權(quán)重的 LC。
使用 RR 調(diào)度進(jìn)行測試是個不錯的方法,因為易于確認(rèn)。您可能希望將 WRR 和 LC 添加到測試?yán)讨幸源_認(rèn)它們能夠按預(yù)期運作。此處給出的示例使用 RR 調(diào)度及類似調(diào)度。
接下來,創(chuàng)建腳本以啟用轉(zhuǎn)發(fā)至 realserver 的 ipvsadm 服務(wù),并且在每個 LVS 控制器中放置一個副本。當(dāng)完成 mon 的后續(xù)配置以自動監(jiān)控活動的 realserver 后,就不需要再使用這個腳本,但在此之前它會有助于測試 ipvsadm 組件。請記住在執(zhí)行此腳本之前重新檢查網(wǎng)絡(luò)和 http/https 與每個 realserver 之間的連接是否正常。
清單 5. HA_CONFIG.sh 文件
| #!/bin/sh# The virtual address on the director which acts as a cluster addressVIRTUAL_CLUSTER_ADDRESS=192.168.71.205REAL_SERVER_IP_1=192.168.71.220REAL_SERVER_IP_2=192.168.71.150REAL_SERVER_IP_3=192.168.71.121REAL_SERVER_IP_4=192.168.71.145REAL_SERVER_IP_5=192.168.71.185REAL_SERVER_IP_6=192.168.71.186# set ip_forward ON for vs-nat director (1 on, 0 off).cat /proc/sys/net/ipv4/ip_forwardecho "1" >/proc/sys/net/ipv4/ip_forward# director acts as the gw for realservers# Turn OFF icmp redirects (1 on, 0 off), if not the realservers might be clever and# not use the director as the gateway!echo "0" >/proc/sys/net/ipv4/conf/all/send_redirectsecho "0" >/proc/sys/net/ipv4/conf/default/send_redirectsecho "0" >/proc/sys/net/ipv4/conf/eth0/send_redirects# Clear ipvsadm tables (better safe than sorry)/sbin/ipvsadm -C# We install LVS services with ipvsadm for HTTP and HTTPS connections with RR# scheduling/sbin/ipvsadm -A -t $VIRTUAL_CLUSTER_ADDRESS:http -s rr/sbin/ipvsadm -A -t $VIRTUAL_CLUSTER_ADDRESS:https -s rr# First realserver# Forward HTTP to REAL_SERVER_IP_1 using LVS-NAT (-m), with weight=1/sbin/ipvsadm -a -t $VIRTUAL_CLUSTER_ADDRESS:http -r $REAL_SERVER_IP_1:http -m -w 1/sbin/ipvsadm -a -t $VIRTUAL_CLUSTER_ADDRESS:https -r $REAL_SERVER_IP_1:https -m -w 1# Second realserver# Forward HTTP to REAL_SERVER_IP_2 using LVS-NAT (-m), with weight=1/sbin/ipvsadm -a -t $VIRTUAL_CLUSTER_ADDRESS:http -r $REAL_SERVER_IP_2:http -m -w 1/sbin/ipvsadm -a -t $VIRTUAL_CLUSTER_ADDRESS:https -r $REAL_SERVER_IP_2:https -m -w 1# Third realserver# Forward HTTP to REAL_SERVER_IP_3 using LVS-NAT (-m), with weight=1/sbin/ipvsadm -a -t $VIRTUAL_CLUSTER_ADDRESS:http -r $REAL_SERVER_IP_3:http -m -w 1/sbin/ipvsadm -a -t $VIRTUAL_CLUSTER_ADDRESS:https -r $REAL_SERVER_IP_3:https -m -w 1# Fourth realserver# Forward HTTP to REAL_SERVER_IP_4 using LVS-NAT (-m), with weight=1/sbin/ipvsadm -a -t $VIRTUAL_CLUSTER_ADDRESS:http -r $REAL_SERVER_IP_4:http -m -w 1/sbin/ipvsadm -a -t $VIRTUAL_CLUSTER_ADDRESS:https -r $REAL_SERVER_IP_4:https -m -w 1# Fifth realserver# Forward HTTP to REAL_SERVER_IP_5 using LVS-NAT (-m), with weight=1/sbin/ipvsadm -a -t $VIRTUAL_CLUSTER_ADDRESS:http -r $REAL_SERVER_IP_5:http -m -w 1/sbin/ipvsadm -a -t $VIRTUAL_CLUSTER_ADDRESS:https -r $REAL_SERVER_IP_5:https -m -w 1# Sixth realserver# Forward HTTP to REAL_SERVER_IP_6 using LVS-NAT (-m), with weight=1/sbin/ipvsadm -a -t $VIRTUAL_CLUSTER_ADDRESS:http -r $REAL_SERVER_IP_6:http -m -w 1/sbin/ipvsadm -a -t $VIRTUAL_CLUSTER_ADDRESS:https -r $REAL_SERVER_IP_6:https -m -w 1# We print the new ipvsadm table for inspectionecho "NEW IPVSADM TABLE:"/sbin/ipvsadm |
?
如清單 5 中所示,腳本只是啟用了 ipvsadm 服務(wù),然后實際上使用了相同的代碼節(jié)以便將 Web 和 SSL 請求轉(zhuǎn)發(fā)給每個單個的 realserver。我們使用了 -m 選項指定 NAT,并給每個 realserver 賦以權(quán)重 1(-w 1)。使用正常的輪循調(diào)度時,指定的權(quán)重會出現(xiàn)冗余(因為默認(rèn)的權(quán)重總是 1)。顯示此選項的惟一目的是讓您傾向于選擇加權(quán)的輪循。 為此,在關(guān)于使用輪循的注釋下的 2 個連續(xù)的行中將 rr 改為 wrr,當(dāng)然不要忘了相應(yīng)地調(diào)整權(quán)重。有關(guān)各種調(diào)度程序的更多信息,請查詢 ipvsadm 手冊。
您現(xiàn)在已經(jīng)配置了每個控制器,可以處理引入的對浮動服務(wù) IP 的 Web 和 SSL 請求,方法是重寫這些請求并連續(xù)地將工作傳遞給 realserver。但是為了從 realserver 收回通信量,并且為了在將請求返回給發(fā)出請求的客戶機之前執(zhí)行相反的過程,您需要對控制器更改幾個連網(wǎng)設(shè)置。其原因是需要在平面網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)中實現(xiàn) LVS 控制器和 realserver(即,同一子網(wǎng)上的所有組件)。我們需要執(zhí)行以下步驟以強制 Apache 通過控制器返回響應(yīng)通信量,而不是自己直接應(yīng)答:
echo "0" > /proc/sys/net/ipv4/conf/all/send_redirects
echo "0" > /proc/sys/net/ipv4/conf/default/send_redirects
echo "0" > /proc/sys/net/ipv4/conf/eth0/send_redirects
執(zhí)行此操作的目的是為了防止活動的 LVS 控制器通知 realserver 和浮動服務(wù) IP 直接相互通信,從而獲取 TCP/IP 捷徑(因為它們位于同一個子網(wǎng)中)。一般情況下,重定向是有用的,因為它們通過清除網(wǎng)絡(luò)連接中不必要的中間件提高了性能。但是此時,它可能阻礙了響應(yīng)通信 量的重寫,而這又是對客戶機透明所必需的。實際上,如果在 LVS 控制器上沒有禁用重定向,那么從 realserver 直接發(fā)往客戶機的通信量將被客戶機視為未被請求的網(wǎng)絡(luò)響應(yīng)而被丟棄。
此時,可將每個 realserver 的默認(rèn)路由設(shè)為指向服務(wù)的浮動 IP 地址,從而確保所有的響應(yīng)都被傳回控制器以進(jìn)行包重寫,然后再傳回最初發(fā)出請求的客戶機。
一旦在控制器上禁用重定向,并且 realserver 被配置為通過浮動服務(wù) IP 發(fā)送所有的通信量,那么您可能需要測試 HA LVS 環(huán)境。要測試迄今為止所做的工作,可讓一個遠(yuǎn)端客戶機上的 Web 瀏覽器指向 LVS 控制器的浮動服務(wù)地址。
為了在實驗室進(jìn)行測試,我們使用的是基于 Gecko 的瀏覽器(Mozilla),但是任何其他瀏覽器也可以滿足要求。為了確保部署成功,在瀏覽器中禁用緩存,并多次單擊刷新按鈕。在每次刷新時,您應(yīng)看見顯 示的 Web 頁面是 realserver 上配置的一個自識別頁面。如果您要使用 RR 調(diào)度,您應(yīng)可以看到連續(xù)通過每個 realserver 的頁面循環(huán)。
您是否正在思考確保 LVS 配置在引導(dǎo)時自動啟動?現(xiàn)在千萬別這樣做!還有一個步驟尚未完成(步驟 5),此步驟將執(zhí)行 realserver 的活動監(jiān)控(因此保留一個動態(tài) Apache 節(jié)點列表,其中的節(jié)點可以為工作請求提供服務(wù))。
回頁首
步驟 5:在 LVS 控制器上安裝和配置 mon
迄今為止,您已經(jīng)建立了一個高度可用的服務(wù) IP 地址,并將其綁定到 realserver 實例池。但是在任何給定時間您決不能信任任何單個的 Apache 服務(wù)器是正常運作的。通過選擇 RR 調(diào)度,如果任何給定的 realserver 被禁用,或者以一種即時的方式停止響應(yīng)網(wǎng)絡(luò)通信量,那么 1/6 的 HTTP 請求將會失敗!
因此有必要實施 realserver 對每個 LVS 控制器的監(jiān)控,以便動態(tài)地將其添加到服務(wù)池中或從中刪除。另一個著名的稱為 mon 的開源包很適合這項任務(wù)。
mon 解決方案一般用于監(jiān)控 LVS 真實節(jié)點。Mon 的配置相對容易,并且對于熟悉 shell 腳本編程的人而言可擴展性很好。讓所有組件正常運作大致分以下三個主要步驟:安裝、服務(wù)監(jiān)控配置和警報創(chuàng)建。使用包管理工具處理 mon 的安裝。完成安裝后,您只需要調(diào)整監(jiān)控配置,并創(chuàng)建一些警報腳本。當(dāng)監(jiān)視器確定 realserver 已經(jīng)脫機或恢復(fù)聯(lián)機時,將觸發(fā)警報腳本。
注意,安裝 heartbeat v2 后,監(jiān)控 realserver 可通過構(gòu)建所有的 realserver 服務(wù)資源來完成。 或者,您可以使用 Heartbeat ldirectord 包。
默認(rèn)情況下,mon 附帶了幾個可以直接使用的監(jiān)視器機制。我們修改了 /etc/mon.cf 中的樣例配置文件以使用 HTTP 服務(wù)。
在 mon 配置文件中,確保標(biāo)題可以反映正確的路徑。SLES10 是一個 64 位的 Linux 圖像,但是隨附的樣例配置用于默認(rèn)的(31 位或 32 位)位置。配置文件樣例假定警報和監(jiān)視器位于 /usr/lib 中,這對于我們的特定安裝而言并不正確。我們修改的參數(shù)如下:
alertdir = /usr/lib64/mon/alert.d
mondir = /usr/lib64/mon/mon.d
如您所見,我們只是將 lib 更改為 lib64。對于您所使用的版本可能不需要這種更改。
對配置文件的下一個更改是指定要監(jiān)控的 realserver 列表。這可以通過以下 6 個指令完成:
清單 6. 指定要監(jiān)控的 realserver
| hostgroup litstat1 192.168.71.220 # realserver 1hostgroup litstat2 192.168.71.150hostgroup litstat3 192.168.71.121hostgroup litstat4 192.168.71.145hostgroup litstat5 192.168.71.185hostgroup litstat6 192.168.71.186 # realserver 6 |
?
如果您希望添加額外的 realserver,直接在此添加額外的條目即可。
一旦您處理好所有的定義,就需要告知 mon 如何查看故障,以及如何處理故障。為此,添加以下的監(jiān)視器段(分別針對每個 realserver)。完成后,您需要將 mon 配置文件和警報置于每個 LVS heartbeat 節(jié)點之上,啟用每個 heartbeat 集群節(jié)點以獨立地監(jiān)控所有的 realserver。
清單 7. /etc/mon/mon.cf 文件
| ## global options#cfbasedir = /etc/monalertdir = /usr/lib64/mon/alert.dmondir = /usr/lib64/mon/mon.dstatedir = /var/lib/monlogdir = /var/logmaxprocs = 20histlength = 100historicfile = mon_history.lograndstart = 60s## authentication types:# getpwnam standard Unix passwd, NOT for shadow passwords# shadow Unix shadow passwords (not implemented)# userfile "mon" user file#authtype = getpwnam## downtime logging, uncomment to enable# if the server is running, don't forget to send a reset command# when you change this##dtlogfile = downtime.logdtlogging = yes## NB: hostgroup and watch entries are terminated with a blank line (or# end of file). Don't forget the blank lines between them or you lose.### group definitions (hostnames or IP addresses)# example:## hostgroup servers www mail pop server4 server5## For simplicity we monitor each individual server as if it were a "group"# so we add only the hostname and the ip address of an individual node for each.hostgroup litstat1 192.168.71.220hostgroup litstat2 192.168.71.150hostgroup litstat3 192.168.71.121hostgroup litstat4 192.168.71.145hostgroup litstat5 192.168.71.185hostgroup litstat6 192.168.71.186## Now we set identical watch definitions on each of our groups. They could be# customized to treat individual servers differently, but we have made the# configurations homogeneous here to match our homogeneous LVS configuration.#watch litstat1service httpdescription http check serversinterval 6smonitor http.monitor -p 80 -u /index.htmlallow_empty_groupperiod wd {Mon-Sun}alert dowem.down.alert -hupalert dowem.up.alert -halertevery 600salertafter 1watch litstat2service httpdescription http check serversinterval 6smonitor http.monitor -p 80 -u /index.htmlallow_empty_groupperiod wd {Mon-Sun}alert dowem.down.alert -hupalert dowem.up.alert -halertevery 600salertafter 1watch litstat3service httpdescription http check serversinterval 6smonitor http.monitor -p 80 -u /index.htmlallow_empty_groupperiod wd {Mon-Sun}alert dowem.down.alert -hupalert dowem.up.alert -halertevery 600salertafter 1watch litstat4service httpdescription http check serversinterval 6smonitor http.monitor -p 80 -u /index.htmlallow_empty_groupperiod wd {Mon-Sun}alert dowem.down.alert -hupalert dowem.up.alert -halertevery 600salertafter 1watch litstat5service httpdescription http check serversinterval 6smonitor http.monitor -p 80 -u /index.htmlallow_empty_groupperiod wd {Mon-Sun}alert dowem.down.alert -hupalert dowem.up.alert -halertevery 600salertafter 1watch litstat6service httpdescription http check serversinterval 6smonitor http.monitor -p 80 -u /index.htmlallow_empty_groupperiod wd {Mon-Sun}alert dowem.down.alert -hupalert dowem.up.alert -halertevery 600salertafter 1 |
?
清單 7 告知 mon 使用 http.monitor,默認(rèn)情況下它由 mon 附帶。另外,指定使用端口 80。清單 7 還提供了要請求的特殊頁面;您可能會選擇為 Web 服務(wù)器傳輸一小段更有效率的 html 作為操作成功的證明,而不是傳輸一個復(fù)雜的默認(rèn) html 頁面。
alert 和 upalert 行調(diào)用的腳本必須置于配置文件頂部指定的 alertdir 中。其目錄通常是發(fā)行版所默認(rèn)的目錄,比如 “/usr/lib64/mon/alert.d”。警報負(fù)責(zé)告知 LVS 將 Apache 服務(wù)器添加到合格的列表中或從中刪除(方法是調(diào)用 ipvsadm 命令,我們很快就要介紹到)。
當(dāng)一個 realserver 的 http 測試失敗時,dowem.down.alert 將由 mon 使用幾個參數(shù)自動執(zhí)行。同樣地,當(dāng)監(jiān)視器確定 realserver 已經(jīng)恢復(fù)聯(lián)機時,mon 進(jìn)程使用大量的參數(shù)自動執(zhí)行 dowem.up.alert。您可以隨意地修改警報腳本的名稱以適應(yīng)您的部署。
保存此文件,在 alertdir 中創(chuàng)建警報(使用簡單的 bash 腳本編程)。清單 8 展示了一個 bash 腳本警報,重新建立 realserver 連接時由 mon 調(diào)用。
清單 8. 簡單警報:已連接上
| #! /bin/bash# The h arg is followed by the hostname we are interested in acting on# So we skip ahead to get the -h option since we don't care about the othersREALSERVER=192.168.71.205while [ $1 != "-h" ] ;doshiftdoneADDHOST=$2# For the HTTP service/sbin/ipvsadm -a -t $REALSERVER:http -r $ADDHOST:http -m -w 1# For the HTTPS service/sbin/ipvsadm -a -t $REALSERVER:https -r $ADDHOST:https -m -w 1 |
?
清單 9 展示了一個 bash 腳本警報,當(dāng) realserver 連接丟失時由 mon 調(diào)用。
清單 9. 簡單警報:連接已丟失
| #! /bin/bash# The h arg is followed by the hostname we are interested in acting on# So we skip ahead to get the -h option since we dont care about the othersREALSERVER=192.168.71.205while [ $1 != "-h" ] ;doshiftdoneBADHOST=$2# For the HTTP service/sbin/ipvsadm -d -t $REALSERVER:http -r $BADHOST# For the HTTPS service/sbin/ipvsadm -d -t $REALSERVER:https -r $BADHOST |
?
這兩組腳本都使用 ipvsadm 命令行工具動態(tài)地將 realserver 添加到 LVS 表中或從中刪除。注意,這些腳本遠(yuǎn)談不上完美。mon 只對于簡單的 Web 請求監(jiān)控 http 端口,此處闡述的架構(gòu)在下述情形中容易受到攻擊:給定的 realserver 對于 http 請求可能正常運作,但對于 SSL 請求卻不行。在這些情況下,我們將無法從 https 備選列表中刪除有問題的 realserver。當(dāng)然,除了為 mon 配置文件中的每個 realserver 啟用另一個 https 監(jiān)視器外,構(gòu)建更多專門針對每種類型的 Web 請求的高級警報也可以輕松地解決這個問題。這可以留給讀者作為練習(xí)。
為確保監(jiān)視器已被激活,依次為每個 realserver 啟用并禁用 Apache 進(jìn)程,觀察每個控制器對事件的反應(yīng)。只有當(dāng)您確認(rèn)每個控制器正常地監(jiān)控每個 realserver 后,您才可以使用 chkconfig 命令確保 mon 進(jìn)程可以在引導(dǎo)時自動啟動。使用的特定命令為 chkconfig mon on,但是這可能隨發(fā)行版的不同而有所區(qū)別。
完成這個最后的部分后,您就已完成構(gòu)建跨系統(tǒng)的高度可用的 Web 服務(wù)器基礎(chǔ)設(shè)施的任務(wù)。當(dāng)然,您現(xiàn)在可能想要執(zhí)行一些更高級的工作。例如,您可能已經(jīng)注意到,mon 守護程序本身沒有被監(jiān)控(heartbeat 項目可以為您監(jiān)控 mon),但是最后的步驟已為此打下基礎(chǔ)。
回頁首
故障診斷
活動節(jié)點在一個 HA 集群中不能正常運作有多種原因,自愿的或非自愿的。節(jié)點可能丟失與其他節(jié)點的網(wǎng)絡(luò)連接,heartbeat 進(jìn)程可能被停止,可能出現(xiàn)任何環(huán)境事件等等。要故意地讓活動節(jié)點失效,您可以要求該節(jié)點暫停,或?qū)⑵湓O(shè)為備用模式,方法是使用 hb_gui(完全關(guān)閉)命令。如果您希望測試環(huán)境的健壯性,您可能需要一些更激進(jìn)的方式。
指示器和故障恢復(fù)
系統(tǒng)管理員可以使用兩種日志文件指示器配置 Linux HA heartbeat 系統(tǒng)。日志文件與系統(tǒng)是否為浮動資源 IP 地址的接收方有關(guān)。沒有接收浮動資源 IP 地址的集群成員的日志結(jié)果類似于:
清單 10. 落選者的日志結(jié)果
| litsha21:~ # cat /var/log/messagesJan 16 12:00:20 litsha21 heartbeat: [3057]: WARN: node litsha23: is deadJan 16 12:00:21 litsha21 cib: [3065]: info: mem_handle_event: Got an eventOC_EV_MS_NOT_PRIMARY from ccmJan 16 12:00:21 litsha21 cib: [3065]: info: mem_handle_event: instance=13, nodes=3,new=1, lost=0, n_idx=0, new_idx=3, old_idx=6Jan 16 12:00:21 litsha21 crmd: [3069]: info: mem_handle_event: Got an eventOC_EV_MS_NOT_PRIMARY from ccmJan 16 12:00:21 litsha21 crmd: [3069]: info: mem_handle_event: instance=13, nodes=3,new=1, lost=0, n_idx=0, new_idx=3, old_idx=6Jan 16 12:00:21 litsha21 crmd: [3069]: info: crmd_ccm_msg_callback:callbacks.c Quorumlost after event=NOT PRIMARY (id=13)Jan 16 12:00:21 litsha21 heartbeat: [3057]: info: Link litsha23:eth1 dead.Jan 16 12:00:38 litsha21 ccm: [3064]: debug: quorum plugin: majorityJan 16 12:00:38 litsha21 ccm: [3064]: debug: cluster:linux-ha, member_count=2,member_quorum_votes=200Jan 16 12:00:38 litsha21 ccm: [3064]: debug: total_node_count=3,total_quorum_votes=300.................. Truncated For Brevity ..................Jan 16 12:00:40 litsha21 crmd: [3069]: info: update_dc:utils.c Set DC to litsha21(1.0.6)Jan 16 12:00:41 litsha21 crmd: [3069]: info: do_state_transition:fsa.c litsha21:State transition S_INTEGRATION ->S_FINALIZE_JOIN [ input=I_INTEGRATED cause=C_FSA_INTERNALorigin=check_join_state ]Jan 16 12:00:41 litsha21 crmd: [3069]: info: do_state_transition:fsa.c All 2 clusternodes responded to the join offer.Jan 16 12:00:41 litsha21 crmd: [3069]: info: update_attrd:join_dc.c Connecting toattrd...Jan 16 12:00:41 litsha21 cib: [3065]: info: sync_our_cib:messages.c Syncing CIB toall peersJan 16 12:00:41 litsha21 attrd: [3068]: info: attrd_local_callback:attrd.c Sendingfull refresh.................. Truncated For Brevity ..................Jan 16 12:00:43 litsha21 pengine: [3112]: info: unpack_nodes:unpack.c Node litsha21is in standby-modeJan 16 12:00:43 litsha21 pengine: [3112]: info: determine_online_status:unpack.c Nodelitsha21 is onlineJan 16 12:00:43 litsha21 pengine: [3112]: info: determine_online_status:unpack.c Nodelitsha22 is onlineJan 16 12:00:43 litsha21 pengine: [3112]: info: IPaddr_1(heartbeat::ocf:IPaddr): StoppedJan 16 12:00:43 litsha21 pengine: [3112]: notice: StartRsc:native.c litsha22Start IPaddr_1Jan 16 12:00:43 litsha21 pengine: [3112]: notice: Recurring:native.c litsha22IPaddr_1_monitor_5000Jan 16 12:00:43 litsha21 pengine: [3112]: notice: stage8:stages.c Created transitiongraph 0................... Truncated For Brevity ..................Jan 16 12:00:46 litsha21 mgmtd: [3070]: debug: update cib finishedJan 16 12:00:46 litsha21 crmd: [3069]: info: do_state_transition:fsa.c litsha21:State transition S_TRANSITION_ENGINE ->S_IDLE [ input=I_TE_SUCCESS cause=C_IPC_MESSAGE origin=do_msg_route ]Jan 16 12:00:46 litsha21 cib: [3118]: info: write_cib_contents:io.c Wrote version0.53.593 of the CIB to disk (digest: 83b00c386e8b67c42d033a4141aaef90) |
?
如清單 10 所示,獲取了一份名單,有足夠的 quorum 成員可以投票。獲取投票,不需要執(zhí)行其他操作即可恢復(fù)正常運作。
相反,接收了浮動資源 IP 地址的集群成員的日志結(jié)果如下:
清單 11. 資源持有者的日志文件
| litsha22:~ # cat /var/log/messagesJan 16 12:00:06 litsha22 syslog-ng[1276]: STATS: dropped 0Jan 16 12:01:51 litsha22 heartbeat: [3892]: WARN: node litsha23: is deadJan 16 12:01:51 litsha22 heartbeat: [3892]: info: Link litsha23:eth1 dead.Jan 16 12:01:51 litsha22 cib: [3900]: info: mem_handle_event: Got an eventOC_EV_MS_NOT_PRIMARY from ccmJan 16 12:01:51 litsha22 cib: [3900]: info: mem_handle_event: instance=13, nodes=3,new=3, lost=0, n_idx=0, new_idx=0, old_idx=6Jan 16 12:01:51 litsha22 crmd: [3904]: info: mem_handle_event: Got an eventOC_EV_MS_NOT_PRIMARY from ccmJan 16 12:01:51 litsha22 crmd: [3904]: info: mem_handle_event: instance=13, nodes=3,new=3, lost=0, n_idx=0, new_idx=0, old_idx=6Jan 16 12:01:51 litsha22 crmd: [3904]: info: crmd_ccm_msg_callback:callbacks.c Quorumlost after event=NOT PRIMARY (id=13)Jan 16 12:02:09 litsha22 ccm: [3899]: debug: quorum plugin: majorityJan 16 12:02:09 litsha22 crmd: [3904]: info: do_election_count_vote:election.cElection check: vote from litsha21Jan 16 12:02:09 litsha22 ccm: [3899]: debug: cluster:linux-ha, member_count=2,member_quorum_votes=200Jan 16 12:02:09 litsha22 ccm: [3899]: debug: total_node_count=3,total_quorum_votes=300Jan 16 12:02:09 litsha22 cib: [3900]: info: mem_handle_event: Got an eventOC_EV_MS_INVALID from ccmJan 16 12:02:09 litsha22 cib: [3900]: info: mem_handle_event: no mbr_track infoJan 16 12:02:09 litsha22 cib: [3900]: info: mem_handle_event: Got an eventOC_EV_MS_NEW_MEMBERSHIP from ccmJan 16 12:02:09 litsha22 cib: [3900]: info: mem_handle_event: instance=14, nodes=2,new=0, lost=1, n_idx=0, new_idx=2, old_idx=5Jan 16 12:02:09 litsha22 cib: [3900]: info: cib_ccm_msg_callback:callbacks.cLOST: litsha23Jan 16 12:02:09 litsha22 cib: [3900]: info: cib_ccm_msg_callback:callbacks.cPEER: litsha21Jan 16 12:02:09 litsha22 cib: [3900]: info: cib_ccm_msg_callback:callbacks.cPEER: litsha22.................. Truncated For Brevity ..................Jan 16 12:02:12 litsha22 crmd: [3904]: info: update_dc:utils.c Set DC to litsha21(1.0.6)Jan 16 12:02:12 litsha22 crmd: [3904]: info: do_state_transition:fsa.c litsha22:State transition S_PENDING -> S_NOT_DC [ input=I_NOT_DC cause=C_HA_MESSAGEorigin=do_cl_join_finalize_respond ]Jan 16 12:02:12 litsha22 cib: [3900]: info: cib_diff_notify:notify.c Update (client:3069, call:25): 0.52.585 ->0.52.586 (ok).................. Truncated For Brevity ..................Jan 16 12:02:14 litsha22 IPaddr[3998]: INFO: /sbin/ifconfig eth0:0 192.168.71.205netmask 255.255.255.0 broadcast 192.168.71.255Jan 16 12:02:14 litsha22 IPaddr[3998]: INFO: Sending Gratuitous Arp for192.168.71.205 on eth0:0 [eth0]Jan 16 12:02:14 litsha22 IPaddr[3998]: INFO: /usr/lib64/heartbeat/send_arp -i 500 -r10 -p/var/run/heartbeat/rsctmp/send_arp/send_arp-192.168.71.205 eth0 192.168.71.205 auto192.168.71.205 ffffffffffffJan 16 12:02:14 litsha22 crmd: [3904]: info: process_lrm_event:lrm.c LRM operation(3) start_0 on IPaddr_1 completeJan 16 12:02:14 litsha22 kernel: send_arp uses obsolete (PF_INET,SOCK_PACKET)Jan 16 12:02:14 litsha22 kernel: klogd 1.4.1, ---------- state change ----------Jan 16 12:02:14 litsha22 kernel: NET: Registered protocol family 17Jan 16 12:02:15 litsha22 crmd: [3904]: info: do_lrm_rsc_op:lrm.c Performing opmonitor on IPaddr_1 (interval=5000ms, key=0:f9d962f0-4ed6-462d-a28d-e27b6532884c)Jan 16 12:02:15 litsha22 cib: [3900]: info: cib_diff_notify:notify.c Update (client:3904, call:18): 0.53.591 ->0.53.592(ok)Jan 16 12:02:15 litsha22 mgmtd: [3905]: debug: update cib finished |
?
如清單 11 所示,/var/log/messages 文件展示了此節(jié)點已經(jīng)獲得了浮動資源。ifconfig 行顯示將動態(tài)創(chuàng)建 eth0:0 設(shè)備以維持服務(wù)。
如清單 11 所示,獲取了一份名單,有足夠的 quorum 成員可以投票。獲取投票后,發(fā)出的 ifconfig 命令索要浮動資源 IP 地址。
另外一種指示何時發(fā)生故障的方法是,您可以登錄到任何一個集群成員并執(zhí)行 hb_gui 命令。使用這種方法,您可以通過親自查找擁有浮動資源的系統(tǒng)來確定故障發(fā)生時間。
最后,如果我們不展示一個非 quorum 情形的樣例日志文件似乎有些說不過去。如果某個單一節(jié)點無法與任何一個其他節(jié)點進(jìn)行通信,那么它就丟失了 quorum(因為在 3 個成員的投票中 2/3 是多數(shù))。在這種情況下,節(jié)點獲悉已丟失 quorum,然后調(diào)用 no quorum policy 處理程序。清單 12 展示了一個來自這類事件的日志文件示例。丟失 quorum 時,日志條目將會有所顯示。顯示此日志條目的集群節(jié)點認(rèn)為自己不具有浮動資源。ifconfig down 語句將釋放資源。
清單 12. 顯示丟失 quorum 的日志條目
| litsha22:~ # cat /var/log/messages....................Jan 16 12:06:12 litsha22 ccm: [3899]: debug: quorum plugin: majorityJan 16 12:06:12 litsha22 ccm: [3899]: debug: cluster:linux-ha, member_count=1,member_quorum_votes=100Jan 16 12:06:12 litsha22 ccm: [3899]: debug: total_node_count=3,total_quorum_votes=300.................. Truncated For Brevity ..................Jan 16 12:06:12 litsha22 crmd: [3904]: info: crmd_ccm_msg_callback:callbacks.c Quorumlost after event=INVALID (id=15)Jan 16 12:06:12 litsha22 crmd: [3904]: WARN: check_dead_member:ccm.c Our DC node(litsha21) left the cluster.................. Truncated For Brevity ..................Jan 16 12:06:14 litsha22 IPaddr[5145]: INFO: /sbin/route -n del -host 192.168.71.205Jan 16 12:06:15 litsha22 lrmd: [1619]: info: RA output: (IPaddr_1:stop:stderr)SIOCDELRT: No such processJan 16 12:06:15 litsha22 IPaddr[5145]: INFO: /sbin/ifconfig eth0:0 192.168.71.205downJan 16 12:06:15 litsha22 IPaddr[5145]: INFO: IP Address 192.168.71.205 releasedJan 16 12:06:15 litsha22 crmd: [3904]: info: process_lrm_event:lrm.c LRM operation(6) stop_0 on IPaddr_1 completeJan 16 12:06:15 litsha22 cib: [3900]: info: cib_diff_notify:notify.c Update (client:3904, call:32): 0.54.599 ->0.54.600 (ok)Jan 16 12:06:15 litsha22 mgmtd: [3905]: debug: update cib finished |
?
如清單 12 所示,當(dāng)某個給定節(jié)點丟失 quorum 時,它將放棄所有資源,因為選擇了 no quorum policy 配置。是否選擇 no quorum policy 完全取決于您自己。
Fail-back 動作和消息
正確配置的 Linux HA 系統(tǒng)的一個更有趣的含義是,您不需要執(zhí)行任何操作就可重新實例化集群成員。只需要激活 Linux 實例即可讓節(jié)點自動地重新加入其他節(jié)點。如果您配置了一個主節(jié)點(即,一個可以優(yōu)先于其他節(jié)點獲得浮動資源的節(jié)點),它將自動重新獲得浮動資源。非優(yōu)先的 系統(tǒng)將只是加入合格節(jié)點池并正常運作。
將其他的 Linux 實例往回添加到池中將使每個節(jié)點獲得通知,并且如果可能的話,重新建立 quorum。如果可以重新建立 quorum,那么將在某個節(jié)點上重新建立浮動資源。
清單 13. 重新建立 Quorum
| litsha22:~ # tail -f /var/log/messagesJan 16 12:09:02 litsha22 heartbeat: [3892]: info: Heartbeat restart on node litsha21Jan 16 12:09:02 litsha22 heartbeat: [3892]: info: Link litsha21:eth1 up.Jan 16 12:09:02 litsha22 heartbeat: [3892]: info: Status update for node litsha21:status initJan 16 12:09:02 litsha22 heartbeat: [3892]: info: Status update for node litsha21:status upJan 16 12:09:22 litsha22 heartbeat: [3892]: debug: get_delnodelist: delnodelist=Jan 16 12:09:22 litsha22 heartbeat: [3892]: info: Status update for node litsha21:status activeJan 16 12:09:22 litsha22 cib: [3900]: info: cib_client_status_callback:callbacks.cStatus update: Client litsha21/cib now has status [join]Jan 16 12:09:23 litsha22 heartbeat: [3892]: WARN: 1 lost packet(s) for [litsha21][36:38]Jan 16 12:09:23 litsha22 heartbeat: [3892]: info: No pkts missing from litsha21!Jan 16 12:09:23 litsha22 crmd: [3904]: notice:crmd_client_status_callback:callbacks.c Status update: Client litsha21/crmd now hasstatus [online]....................Jan 16 12:09:31 litsha22 crmd: [3904]: info: crmd_ccm_msg_callback:callbacks.c Quorum(re)attained after event=NEW MEMBERSHIP (id=16)Jan 16 12:09:31 litsha22 crmd: [3904]: info: ccm_event_detail:ccm.c NEW MEMBERSHIP:trans=16, nodes=2, new=1, lost=0 n_idx=0, new_idx=2, old_idx=5Jan 16 12:09:31 litsha22 crmd: [3904]: info: ccm_event_detail:ccm.c CURRENT:litsha22 [nodeid=1, born=13]Jan 16 12:09:31 litsha22 crmd: [3904]: info: ccm_event_detail:ccm.c CURRENT:litsha21 [nodeid=0, born=16]Jan 16 12:09:31 litsha22 crmd: [3904]: info: ccm_event_detail:ccm.c NEW:litsha21 [nodeid=0, born=16]Jan 16 12:09:31 litsha22 cib: [3900]: info: cib_diff_notify:notify.c Local-onlyChange (client:3904, call: 35):0.54.600 (ok)Jan 16 12:09:31 litsha22 mgmtd: [3905]: debug: update cib finished....................Jan 16 12:09:34 litsha22 crmd: [3904]: info: update_dc:utils.c Set DC to litsha22(1.0.6)Jan 16 12:09:35 litsha22 cib: [3900]: info: sync_our_cib:messages.c Syncing CIB tolitsha21Jan 16 12:09:35 litsha22 crmd: [3904]: info: do_state_transition:fsa.c litsha22:State transition S_INTEGRATION ->S_FINALIZE_JOIN [ input=I_INTEGRATED cause=C_FSA_INTERNAL origin=check_join_state ]Jan 16 12:09:35 litsha22 crmd: [3904]: info: do_state_transition:fsa.c All 2 clusternodes responded to the join offer.Jan 16 12:09:35 litsha22 attrd: [3903]: info: attrd_local_callback:attrd.c Sendingfull refreshJan 16 12:09:35 litsha22 cib: [3900]: info: sync_our_cib:messages.c Syncing CIB toall peers.........................Jan 16 12:09:37 litsha22 tengine: [5119]: info: send_rsc_command:actions.c Initiatingaction 4: IPaddr_1_start_0 on litsha22Jan 16 12:09:37 litsha22 tengine: [5119]: info: send_rsc_command:actions.c Initiatingaction 2: probe_complete on litsha21Jan 16 12:09:37 litsha22 crmd: [3904]: info: do_lrm_rsc_op:lrm.c Performing op starton IPaddr_1 (interval=0ms,key=2:c5131d14-a9d9-400c-a4b1-60d8f5fbbcce)Jan 16 12:09:37 litsha22 pengine: [5120]: info: process_pe_message:pengine.cTransition 2: PEngine Input stored in: /var/lib/heartbeat/pengine/pe-input-72.bz2Jan 16 12:09:37 litsha22 IPaddr[5196]: INFO: /sbin/ifconfig eth0:0 192.168.71.205netmask 255.255.255.0 broadcast 192.168.71.255Jan 16 12:09:37 litsha22 IPaddr[5196]: INFO: Sending Gratuitous Arp for192.168.71.205 on eth0:0 [eth0]Jan 16 12:09:37 litsha22 IPaddr[5196]: INFO: /usr/lib64/heartbeat/send_arp -i 500 -r10 -p/var/run/heartbeat/rsctmp/send_arp/send_arp-192.168.71.205 eth0 192.168.71.205 auto192.168.71.205 ffffffffffffJan 16 12:09:37 litsha22 crmd: [3904]: info: process_lrm_event:lrm.c LRM operation(7) start_0 on IPaddr_1 completeJan 16 12:09:37 litsha22 cib: [3900]: info: cib_diff_notify:notify.c Update (client:3904, call:46): 0.55.607 -> 0.55.608 (ok)Jan 16 12:09:37 litsha22 mgmtd: [3905]: debug: update cib finishedJan 16 12:09:37 litsha22 tengine: [5119]: info: te_update_diff:callbacks.c Processingdiff (cib_update): 0.55.607 -> 0.55.608Jan 16 12:09:37 litsha22 tengine: [5119]: info: match_graph_event:events.c ActionIPaddr_1_start_0 (4) confirmedJan 16 12:09:37 litsha22 tengine: [5119]: info: send_rsc_command:actions.c Initiatingaction 5: IPaddr_1_monitor_5000 on litsha22Jan 16 12:09:37 litsha22 crmd: [3904]: info: do_lrm_rsc_op:lrm.c Performing opmonitor on IPaddr_1 (interval=5000ms, key=2:c5131d14-a9d9-400c-a4b1-60d8f5fbbcce)Jan 16 12:09:37 litsha22 cib: [5268]: info: write_cib_contents:io.c Wrote version0.55.608 of the CIB to disk (digest: 98cb6685c25d14131c49a998dbbd0c35)Jan 16 12:09:37 litsha22 crmd: [3904]: info: process_lrm_event:lrm.c LRM operation(8) monitor_5000 on IPaddr_1 completeJan 16 12:09:38 litsha22 cib: [3900]: info: cib_diff_notify:notify.c Update (client:3904, call:47): 0.55.608 -> 0.55.609 (ok)Jan 16 12:09:38 litsha22 mgmtd: [3905]: debug: update cib finished |
?
在清單 13 中,您可以看見 quorum 已被重新建立。重新建立 quorum 后,執(zhí)行投票,而 litsha22 將變?yōu)榫哂懈淤Y源的活動節(jié)點。
?
結(jié)束語
高可用性被視為一系列挑戰(zhàn),本文介紹的解決方案描述了第一個步驟。從這里開始,在您的開發(fā)環(huán)境中有多種方法可以繼續(xù)操作:您可以選擇安裝冗余的網(wǎng)絡(luò)、集群文件系統(tǒng)以支持 realserver,或安裝更高級的中間件直接支持集群。
?
本文轉(zhuǎn)載自:http://www.ibm.com/developerworks/cn/linux/l-linux-ha/index.html?S_TACT=105AGX52&S_CMP=techcto
轉(zhuǎn)載于:https://www.cnblogs.com/chenqianpeng/archive/2012/03/23/2414088.html
總結(jié)
以上是生活随笔為你收集整理的使用简单的5个步骤设置 Web服务器集群的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: php函数(检查变量、函数、键是否存在)
- 下一篇: nginx 搭建http协议拖动播放 F