|
<!--START RESERVED FOR FUTURE USE INCLUDE FILES--><!-- this content will be automatically generated across all content areas -->
<!--END RESERVED FOR FUTURE USE INCLUDE FILES-->
|
級別： 中級
Eli Dow
(
emdow@us.ibm.com
), 軟件工程師, IBM Linux Test and Integration Center
Frank LeFevre
(
lefevre@us.ibm.com
), 高級軟件工程師, IBM
2007 年 9 月 17 日
使用 Linux Virtual Server 和 Heartbeat v2，分 5 個步驟跨越多個物理或虛擬 Linux? 服務(wù)器輕松構(gòu)建高度可用的 Apache Web 服務(wù)器集群。
<!--START RESERVED FOR FUTURE USE INCLUDE FILES--><!-- include java script once we verify teams wants to use this and it will work on dbcs and cyrillic characters --><!--END RESERVED FOR FUTURE USE INCLUDE FILES-->
通過在多個處理器之間分擔(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ù)器（在資源允許的情況下），但是我們并未進行更深入的嘗試。圖 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ù)載進程指向右側(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ù)，使客戶機永遠不會知道執(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 地址的形式進行響應(yīng)，或以控制器使用的浮動 IP 地址所對應(yīng)的虛擬主機名的形式響應(yīng)。更改 Apache 配置文件中的一行即可完成這一操作。
|
|
您可以使用一個完全開源的軟件組合復(fù)制這些配置，該軟件組合包括，linux-ha.org 所提供的 Heartbeat 技術(shù)組件，以及通過 mon 和 Apache 進行監(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 ESTInteresting ports on 192.168.71.92:(The 1656 ports scanned but not shown below are in state: closed)PORT STATE SERVICE22/tcp open ssh80/tcp filtered http111/tcp open rpcbind631/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 并進行修改以適應(yīng)您的生產(chǎn)環(huán)境。
清單 3. /etc/ha.d/ha.cf config 文件樣例
# Log to syslog as facility "daemon" use_logd on logfacility daemon # List our cluster members (the realservers) node litsha22 node litsha23 node litsha21 # Send one heartbeat each second keepalive 3 # Warn when heartbeats are late warntime 5 # Declare nodes dead after 10 seconds deadtime 10 # Keep resources on their "preferred" hosts - needed for active/active #auto_failback on # The cluster nodes communicate on their heartbeat lan (.68.*) interfaces ucast eth1 192.168.68.201 ucast eth1 192.168.68.202 ucast 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=pingd respawn hacluster /usr/lib/heartbeat/pingd -m 100 -d 5s # Ping our router to monitor ethernet connectivity ping litrout71_vip #Enable version 2 functionality supporting clusters with > 2 nodes crm yes</integer>
|
respawn
指令在運行時指定某個程序的運行和監(jiān)控。如果此程序退出時的退出碼不是 100，程序?qū)⒆詣又貑ⅰ５谝粋€參數(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 文件指定了一個共享的密匙以允許控制器之間進行通信。共享密鑰就是一個密碼，所有的 heartbeat 節(jié)點都知道這個密碼并使用它進行相互通信。密鑰的使用避免了無關(guān)方對 heartbeat 服務(wù)器節(jié)點的影響。此文件也沒有變化：
auth 1
1 sha1 ca0e08148801f55794b23461eb4106db
接下來的幾步將向您展示如何將 version 1 的 haresources 文件轉(zhuǎn)換為 version 2 的基于 XML 的配置格式 (cib.xml)。雖然可以直接復(fù)制并使用清單 4 中的配置文件作為起點，但是強烈建議您針對自己的部署進行配置調(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><nvpair id="cib-bootstrap-options-no_quorum_policy" name="no_quorum_policy" value="stop"></nvpair><nvpair id="cib-bootstrap-options-default_resource_stickiness" name="default_resource_stickiness" value="0"></nvpair><nvpair id="cib-bootstrap-options-stonith_enabled" name="stonith_enabled" value="false"></nvpair><nvpair id="cib-bootstrap-options-stop_orphan_resources" name="stop_orphan_resources" value="true"></nvpair><nvpair id="cib-bootstrap-options-stop_orphan_actions" name="stop_orphan_actions" value="true"></nvpair><nvpair id="cib-bootstrap-options-remove_after_stop" name="remove_after_stop" value="false"></nvpair><nvpair id="cib-bootstrap-options-transition_idle_timeout" name="transition_idle_timeout" value="5min"></nvpair><nvpair id="cib-bootstrap-options-is_managed_default" name="is_managed_default" value="true"></nvpair><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"></nvpair><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"></nvpair><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"></nvpair><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"></op><operations><instance_attributes id="IPaddr_1_inst_attr"><attributes><nvpair id="IPaddr_1_attr_0" name="ip" value="192.168.71.205"></nvpair><nvpair id="IPaddr_1_attr_1" name="netmask" value="24"></nvpair><nvpair id="IPaddr_1_attr_2" name="nic" value="eth0"></nvpair><nvpair id="IPaddr_1_attr_3" name="broadcast" value="192.168.71.255"></nvpair><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"></expression><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"></expression><rule><rsc_location><constraints><configuration><cib></cib></configuration></constraints></rsc_location></rule></rule></rsc_location></rsc_location></rule></rule></rsc_location></constraints></resources></primitive></instance_attributes></attributes></attributes></instance_attributes></operations></operations></primitive></resources></nodes></node></instance_attributes></attributes></attributes></instance_attributes></node></node></instance_attributes></attributes></attributes></instance_attributes></node></node></instance_attributes></attributes></attributes></instance_attributes></node></nodes></crm_config></cluster_property_set></attributes></attributes></cluster_property_set></crm_config></configuration></cib>
|
一旦生成配置文件后，將 test.xml 移到 cib.xml 中，將所有者改為 hacluster，將組改為 haclient，然后重啟 heartbeat 進程。
現(xiàn)已完成 heartbeat 配置，對 heartbeat 進行設(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 進程 hb_gui（如圖 2 所示），手動地將 IP 地址在集群中移動，方法是將各種節(jié)點設(shè)置為備用或活動狀態(tài)。多次重試這些步驟，禁用并重新啟用活動的或不活動的各種機器。因為先前選中了配置策略，只要可以建立 quorum，并且至少有一個節(jié)點合格，那么浮動資源 IP 地址就保持正常運作。在測試期間，您可以使用簡單的 ping 確保不會發(fā)生丟失包的情況。當(dāng)您完成試驗后，應(yīng)該對配置的健壯性有一個深刻的體會。在繼續(xù)操作之前請確保浮動資源 IP 的 HA 配置適當(dāng)。
圖 2. 用于 heartbeat 進程的圖形化配置工具 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 地址并在其上進行構(gòu)建。因為 LVS 要求對遠端 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í)砑樱?
'' IP_FORWARD="yes"
到 /etc/sysconfig/sysctl 中。
接下來，要通知控制器將引入的 HTTP 請求傳遞給 HA 浮動 IP 地址，接著再傳給 realserver，使用
ipvsadm
命令。
首先，清除舊的 ipvsadm 表：
# /sbin/ipvsadm -C
在配置新表之前，您需要決定希望 LVS 控制器使用何種工作負(fù)載分配。收到來自客戶機的連接請求后，控制器根據(jù)一個 “進度表” 將 realserver 指派給客戶機，然后使用
ipvsadm
命令設(shè)置調(diào)度程序類型。可用的調(diào)度程序包括：
-
Round Robin (RR)
：新的引入連接被依次指派給每個 realserver。
-
Weighted Round Robin (WRR)
：使用附加的權(quán)重因子進行 RR 調(diào)度以補償各種 realserver 功能（如附加 CPU、更多內(nèi)存等）的差異。
-
Least Connected (LC)
：新連接指向具有最少連接數(shù)量的 realserver。不要求是最空閑的 realserver，但是以此為方向。
-
Weighted Least Connection
(WLC)：帶權(quán)重的 LC。
使用 RR 調(diào)度進行測試是個不錯的方法，因為易于確認(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 address VIRTUAL_CLUSTER_ADDRESS=192.168.71.205 REAL_SERVER_IP_1=192.168.71.220 REAL_SERVER_IP_2=192.168.71.150 REAL_SERVER_IP_3=192.168.71.121 REAL_SERVER_IP_4=192.168.71.145 REAL_SERVER_IP_5=192.168.71.185 REAL_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_forward echo "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_redirects echo "0" >/proc/sys/net/ipv4/conf/default/send_redirects echo "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 inspection echo "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)都被傳回控制器以進行包重寫，然后再傳回最初發(fā)出請求的客戶機。
一旦在控制器上禁用重定向，并且 realserver 被配置為通過浮動服務(wù) IP 發(fā)送所有的通信量，那么您可能需要測試 HA LVS 環(huán)境。要測試迄今為止所做的工作，可讓一個遠端客戶機上的 Web 瀏覽器指向 LVS 控制器的浮動服務(wù)地址。
為了在實驗室進行測試，我們使用的是基于 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 1 hostgroup litstat2 192.168.71.150 hostgroup litstat3 192.168.71.121 hostgroup litstat4 192.168.71.145 hostgroup litstat5 192.168.71.185 hostgroup 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/mon
alertdir = /usr/lib64/mon/alert.d
mondir = /usr/lib64/mon/mon.d statedir = /var/lib/mon logdir = /var/log maxprocs = 20 histlength = 100 historicfile = mon_history.log randstart = 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.log dtlogging = 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.220 hostgroup litstat2 192.168.71.150 hostgroup litstat3 192.168.71.121 hostgroup litstat4 192.168.71.145 hostgroup litstat5 192.168.71.185 hostgroup 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 litstat1 service http description http check servers interval 6s
monitor http.monitor -p 80 -u /index.html
allow_empty_group period wd {Mon-Sun}
alert dowem.down.alert -h
upalert dowem.up.alert -h
alertevery 600s alertafter 1 watch litstat2 service http description http check servers interval 6s monitor http.monitor -p 80 -u /index.html allow_empty_group period wd {Mon-Sun} alert dowem.down.alert -h upalert dowem.up.alert -h alertevery 600s alertafter 1 watch litstat3 service http description http check servers interval 6s monitor http.monitor -p 80 -u /index.html allow_empty_group period wd {Mon-Sun} alert dowem.down.alert -h upalert dowem.up.alert -h alertevery 600s alertafter 1 watch litstat4 service http description http check servers interval 6s monitor http.monitor -p 80 -u /index.html allow_empty_group period wd {Mon-Sun} alert dowem.down.alert -h upalert dowem.up.alert -h alertevery 600s alertafter 1 watch litstat5 service http description http check servers interval 6s monitor http.monitor -p 80 -u /index.html allow_empty_group period wd {Mon-Sun} alert dowem.down.alert -h upalert dowem.up.alert -h alertevery 600s alertafter 1 watch litstat6 service http description http check servers interval 6s monitor http.monitor -p 80 -u /index.html allow_empty_group period wd {Mon-Sun} alert dowem.down.alert -h upalert dowem.up.alert -h alertevery 600s alertafter 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 進程使用大量的參數(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 others REALSERVER=192.168.71.205 while [ $1 != "-h" ] ; do shift done ADDHOST=$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 others REALSERVER=192.168.71.205 while [ $1 != "-h" ] ; do shift done BADHOST=$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 表中或從中刪除。注意，這些腳本遠談不上完美。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 進程，觀察每個控制器對事件的反應(yīng)。只有當(dāng)您確認(rèn)每個控制器正常地監(jiān)控每個 realserver 后，您才可以使用
chkconfig
命令確保 mon 進程可以在引導(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 進程可能被停止，可能出現(xiàn)任何環(huán)境事件等等。要故意地讓活動節(jié)點失效，您可以要求該節(jié)點暫停，或?qū)⑵湓O(shè)為備用模式，方法是使用
hb_gui
（完全關(guān)閉）命令。如果您希望測試環(huán)境的健壯性，您可能需要一些更激進的方式。
指示器和故障恢復(fù)
系統(tǒng)管理員可以使用兩種日志文件指示器配置 Linux HA heartbeat 系統(tǒng)。日志文件與系統(tǒng)是否為浮動資源 IP 地址的接收方有關(guān)。沒有接收浮動資源 IP 地址的集群成員的日志結(jié)果類似于：
清單 10. 落選者的日志結(jié)果
litsha21:~ # cat /var/log/messages Jan 16 12:00:20 litsha21 heartbeat: [3057]: WARN: node litsha23: is dead Jan 16 12:00:21 litsha21 cib: [3065]: info: mem_handle_event: Got an event OC_EV_MS_NOT_PRIMARY from ccm Jan 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=6 Jan 16 12:00:21 litsha21 crmd: [3069]: info: mem_handle_event: Got an event OC_EV_MS_NOT_PRIMARY from ccm Jan 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=6 Jan 16 12:00:21 litsha21 crmd: [3069]: info: crmd_ccm_msg_callback:callbacks.c Quorum lost 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: majority Jan 16 12:00:38 litsha21 ccm: [3064]: debug: cluster:linux-ha, member_count=2, member_quorum_votes=200 Jan 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_INTERNAL origin=check_join_state ] Jan 16 12:00:41 litsha21 crmd: [3069]: info: do_state_transition:fsa.c All 2 cluster nodes responded to the join offer. Jan 16 12:00:41 litsha21 crmd: [3069]: info: update_attrd:join_dc.c Connecting to attrd... Jan 16 12:00:41 litsha21 cib: [3065]: info: sync_our_cib:messages.c Syncing CIB to all peers Jan 16 12:00:41 litsha21 attrd: [3068]: info: attrd_local_callback:attrd.c Sending full refresh .................. Truncated For Brevity .................. Jan 16 12:00:43 litsha21 pengine: [3112]: info: unpack_nodes:unpack.c Node litsha21 is in standby-mode Jan 16 12:00:43 litsha21 pengine: [3112]: info: determine_online_status:unpack.c Node litsha21 is online Jan 16 12:00:43 litsha21 pengine: [3112]: info: determine_online_status:unpack.c Node litsha22 is online Jan 16 12:00:43 litsha21 pengine: [3112]: info: IPaddr_1 (heartbeat::ocf:IPaddr): Stopped Jan 16 12:00:43 litsha21 pengine: [3112]: notice: StartRsc:native.c litsha22 Start IPaddr_1 Jan 16 12:00:43 litsha21 pengine: [3112]: notice: Recurring:native.c litsha22 IPaddr_1_monitor_5000 Jan 16 12:00:43 litsha21 pengine: [3112]: notice: stage8:stages.c Created transition graph 0. .................. Truncated For Brevity .................. Jan 16 12:00:46 litsha21 mgmtd: [3070]: debug: update cib finished Jan 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 version 0.53.593 of the CIB to disk (digest: 83b00c386e8b67c42d033a4141aaef90)
|
如清單 10 所示，獲取了一份名單，有足夠的 quorum 成員可以投票。獲取投票，不需要執(zhí)行其他操作即可恢復(fù)正常運作。
相反，接收了浮動資源 IP 地址的集群成員的日志結(jié)果如下：
清單 11. 資源持有者的日志文件
litsha22:~ # cat /var/log/messages Jan 16 12:00:06 litsha22 syslog-ng[1276]: STATS: dropped 0 Jan 16 12:01:51 litsha22 heartbeat: [3892]: WARN: node litsha23: is dead Jan 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 event OC_EV_MS_NOT_PRIMARY from ccm Jan 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=6 Jan 16 12:01:51 litsha22 crmd: [3904]: info: mem_handle_event: Got an event OC_EV_MS_NOT_PRIMARY from ccm Jan 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=6 Jan 16 12:01:51 litsha22 crmd: [3904]: info: crmd_ccm_msg_callback:callbacks.c Quorum lost after event=NOT PRIMARY (id=13) Jan 16 12:02:09 litsha22 ccm: [3899]: debug: quorum plugin: majority Jan 16 12:02:09 litsha22 crmd: [3904]: info: do_election_count_vote:election.c Election check: vote from litsha21 Jan 16 12:02:09 litsha22 ccm: [3899]: debug: cluster:linux-ha, member_count=2, member_quorum_votes=200 Jan 16 12:02:09 litsha22 ccm: [3899]: debug: total_node_count=3, total_quorum_votes=300 Jan 16 12:02:09 litsha22 cib: [3900]: info: mem_handle_event: Got an event OC_EV_MS_INVALID from ccm Jan 16 12:02:09 litsha22 cib: [3900]: info: mem_handle_event: no mbr_track info Jan 16 12:02:09 litsha22 cib: [3900]: info: mem_handle_event: Got an event OC_EV_MS_NEW_MEMBERSHIP from ccm Jan 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=5 Jan 16 12:02:09 litsha22 cib: [3900]: info: cib_ccm_msg_callback:callbacks.c LOST: litsha23 Jan 16 12:02:09 litsha22 cib: [3900]: info: cib_ccm_msg_callback:callbacks.c PEER: litsha21 Jan 16 12:02:09 litsha22 cib: [3900]: info: cib_ccm_msg_callback:callbacks.c PEER: 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_MESSAGE origin=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.205 netmask 255.255.255.0 broadcast 192.168.71.255 Jan 16 12:02:14 litsha22 IPaddr[3998]: INFO: Sending Gratuitous Arp for 192.168.71.205 on eth0:0 [eth0] Jan 16 12:02:14 litsha22 IPaddr[3998]: INFO: /usr/lib64/heartbeat/send_arp -i 500 -r 10 -p /var/run/heartbeat/rsctmp/send_arp/send_arp-192.168.71.205 eth0 192.168.71.205 auto 192.168.71.205 ffffffffffff Jan 16 12:02:14 litsha22 crmd: [3904]: info: process_lrm_event:lrm.c LRM operation (3) start_0 on IPaddr_1 complete Jan 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 17 Jan 16 12:02:15 litsha22 crmd: [3904]: info: do_lrm_rsc_op:lrm.c Performing op monitor 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é)點進行通信，那么它就丟失了 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: majority Jan 16 12:06:12 litsha22 ccm: [3899]: debug: cluster:linux-ha, member_count=1, member_quorum_votes=100 Jan 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 Quorum lost 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.205 Jan 16 12:06:15 litsha22 lrmd: [1619]: info: RA output: (IPaddr_1:stop:stderr) SIOCDELRT: No such process Jan 16 12:06:15 litsha22 IPaddr[5145]: INFO: /sbin/ifconfig eth0:0 192.168.71.205 down Jan 16 12:06:15 litsha22 IPaddr[5145]: INFO: IP Address 192.168.71.205 released Jan 16 12:06:15 litsha22 crmd: [3904]: info: process_lrm_event:lrm.c LRM operation (6) stop_0 on IPaddr_1 complete Jan 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/messages Jan 16 12:09:02 litsha22 heartbeat: [3892]: info: Heartbeat restart on node litsha21 Jan 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 init Jan 16 12:09:02 litsha22 heartbeat: [3892]: info: Status update for node litsha21: status up Jan 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 active Jan 16 12:09:22 litsha22 cib: [3900]: info: cib_client_status_callback:callbacks.c Status 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 has status [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=5 Jan 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-only Change (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 to litsha21 Jan 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 cluster nodes responded to the join offer. Jan 16 12:09:35 litsha22 attrd: [3903]: info: attrd_local_callback:attrd.c Sending full refresh Jan 16 12:09:35 litsha22 cib: [3900]: info: sync_our_cib:messages.c Syncing CIB to all peers ......................... Jan 16 12:09:37 litsha22 tengine: [5119]: info: send_rsc_command:actions.c Initiating action 4: IPaddr_1_start_0 on litsha22 Jan 16 12:09:37 litsha22 tengine: [5119]: info: send_rsc_command:actions.c Initiating action 2: probe_complete on litsha21 Jan 16 12:09:37 litsha22 crmd: [3904]: info: do_lrm_rsc_op:lrm.c Performing op start on IPaddr_1 (interval=0ms, key=2:c5131d14-a9d9-400c-a4b1-60d8f5fbbcce) Jan 16 12:09:37 litsha22 pengine: [5120]: info: process_pe_message:pengine.c Transition 2: PEngine Input stored in: /var/lib/heartbeat/pengine/pe-input-72.bz2 Jan 16 12:09:37 litsha22 IPaddr[5196]: INFO: /sbin/ifconfig eth0:0 192.168.71.205 netmask 255.255.255.0 broadcast 192.168.71.255 Jan 16 12:09:37 litsha22 IPaddr[5196]: INFO: Sending Gratuitous Arp for 192.168.71.205 on eth0:0 [eth0] Jan 16 12:09:37 litsha22 IPaddr[5196]: INFO: /usr/lib64/heartbeat/send_arp -i 500 -r 10 -p /var/run/heartbeat/rsctmp/send_arp/send_arp-192.168.71.205 eth0 192.168.71.205 auto 192.168.71.205 ffffffffffff Jan 16 12:09:37 litsha22 crmd: [3904]: info: process_lrm_event:lrm.c LRM operation (7) start_0 on IPaddr_1 complete Jan 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 finished Jan 16 12:09:37 litsha22 tengine: [5119]: info: te_update_diff:callbacks.c Processing diff (cib_update): 0.55.607 -> 0.55.608 Jan 16 12:09:37 litsha22 tengine: [5119]: info: match_graph_event:events.c Action IPaddr_1_start_0 (4) confirmed Jan 16 12:09:37 litsha22 tengine: [5119]: info: send_rsc_command:actions.c Initiating action 5: IPaddr_1_monitor_5000 on litsha22 Jan 16 12:09:37 litsha22 crmd: [3904]: info: do_lrm_rsc_op:lrm.c Performing op monitor 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 version 0.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 complete Jan 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，或安裝更高級的中間件直接支持集群。
|
