使用簡單的 5 個步驟設置 Web 服務器集羣
經過在多個處理器之間分擔工做負載並採用多種軟件恢復技術，可以提供高度可用的環境並提升環境的整體 RAS（可靠性、可用性和可服務性）。能夠獲得的好處包括：更快地從意外中斷中恢復運行，以及將意外中斷對終端用戶的影響降至最低。html
爲了更好地理解這篇文章，您須要熟悉 Linux 和連網的基本知識，還須要配置好 Apache 服務器。本文的示例基於標準的 SUSE Linux Enterprise Server 10 (SLES10) 安裝，可是使用其餘版本的明智用戶也應該能夠採用文中展現的方法。node
本文展現了健壯的 Apache Web 服務器堆棧，它擁有 6 個 Apache 服務器節點（雖然 3 個節點就足以支持文中闡述的步驟），以及 3 個 Linux Virtual Server (LVS) 控制器。咱們使用 6 個 Apache 服務器節點，能夠在測試時實現更高的工做負載吞吐量，從而模擬更大型的部署。文中展現的架構應該能夠支持更多的控制器和後端 Apache 服務器（在資源容許的狀況下），可是咱們並未進行更深刻的嘗試。圖 1 展現了使用 Linux Virtual Server 和 linux-ha.org 組件的實現。python
圖 1. Linux Virtual Servers 和 Apache
如圖 1 所示，外部客戶機向單個 IP 地址發送通訊量，而該 IP 地址可能存在於某個 LVS 控制器機器上。控制器機器積極地監控接收其發送工做的 Web 服務器池。linux
注意，圖 1 左側的工做負載進程指向右側。此集羣的浮動資源地址在一個給定時間將位於某個 LVS 控制器實例上。可使用一個圖形化的配置工具手動地移動服務地址，或者（這種方法更常見）自行管理服務地址，視 LVS 控制器的狀態而定。若是某個控制器變得不合格（因爲鏈接丟失、軟件故障或相似緣由），那麼服務地址將自動地被從新分配給一個合格的控制器。shell
浮動服務地址必須跨越兩個或多個離散的硬件實例，以便在一個物理機器鏈接丟失的狀況下繼續操做。使用本文展現的配置決策，每一個 LVS 控制器均可以將包轉發給任何的實際 Apache Web 服務器，而且與服務器的物理位置或服務器與提供浮動服務地址的活動控制器的接近程度無關。本文展現了每一個 LVS 控制器如何積極地監控 Apache 服務器，以確保只向正常運做的後端服務器發送請求。express
使用這種配置，技術人員能夠成功地讓整個 Linux 實例失效，並且不會中斷在浮動服務地址上啓用的用戶服務（一般是 http 和 https Web 請求）。編程
您可使用一個徹底開源的軟件組合複製這些配置，該軟件組合包括，linux-ha.org 所提供的 Heartbeat 技術組件，以及經過 mon 和 Apache 進行監控的服務器。正如前面提到的，咱們將使用 SUSE Linux Enterprise Server 測試配置。
LVS 場景中使用的全部機器都位於同一個子網中，使用的是 Network Address Translation (NAT) 配置。在 Linux Virtual Server Web 站點（請參閱 參考資料）上描述了不少其餘網絡結構；爲簡便起見咱們使用 NAT。爲了更加安全，您應該限制穿過防火牆的通訊量，只容許浮動 IP 地址在 LVS 控制器之間傳遞。
Linux Virtual Server 套件提供了幾種不一樣的方法以完成透明的 HA 後端基礎設施。每種方法都各有利弊。LVS-NAT 操做控制器服務器的方式是，獲取發往特定配置的端口的引入包，並動態地在包的頭部重寫目的地址。控制器自己並不處理包的數據內容，而是將其傳給 realserver。包中的目的地址被重寫爲指向集羣中的一個給定的 realserver。而後將包放回網絡中以傳遞給 realserver，而 realserver 並無意識到發生了什麼狀況。對於 realserver，它只是直接從外部接收請求。接着，realserver 的回覆被髮回控制器，在控制器中重寫回復，使其具備客戶機所指向的浮動 IP 地址的源地址，而後再發往原始客戶機。
使用 LVS-NAT 方法意味着 realserver 須要簡單的 TCP/IP 功能。LVS 操做的其餘模式，即 LVS-DR 和 LVS-Tun，須要更加複雜的連網概念。選擇 LVS-NAT 的最主要的好處是隻需對 realserver 配置作不多量的更改。實際上，最難的部分是牢記適當地設置路由語句。
步驟 1：構建 realserver 圖像
以構建 Linux 服務器實例池開始，每一個實例運行 Apache Web 服務器，並確保服務器按預想的狀況運做，將 Web 瀏覽器指向每一個 realserver 的 IP 地址。一般，標準安裝被配置爲在本身的 IP 地址上偵聽 80 端口（換言之，爲每一個 realserver 使用不一樣的 IP）。
接下來，在每一個服務器上配置默認的 Web 頁面以顯示一個靜態頁面，其中包含了爲頁面提供服務的機器的主機名。這確保了您能夠一直了解測試期間您所鏈接的機器。
爲防萬一，檢查在這些系統上轉發的 IP 是否爲 OFF，方法是發出如下命令：
# cat /proc/sys/net/ipv4/ip_forward
若是不是 OFF 而且您須要禁用它，請發出如下命令：
# echo "0" >/proc/sys/net/ipv4/ip_forward
確保每一個 realserver 都正常地偵聽 http 端口 (80) 的一個簡單方法是，使用外部系統並執行掃描。在一些與您的服務器連網的其餘系統中，可使用 nmap 工具以確保服務器執行偵聽操做。
清單 1. 使用 nmap 確保服務器執行偵聽操做
# nmap -P0 192.168.71.92 Starting 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：在使用工具以前請獲取組織的批准。
接下來，將 Web 瀏覽器指向每一個 realserver 的實際 IP 地址，從而確保每一個 realserver 按照預期爲相應頁面提供服務。完成此操做後請轉到步驟 2。
步驟 2：安裝和配置 LVS 控制器
如今，您能夠構建所需的 3 個 LVS 控制器實例。若是您第一次爲每一個 LVS 控制器安裝 SUSE Linux Enterprise Server 10，在初始安裝時，請確保選擇與 heartbeat、ipvsadm 和 mon 相關的高可用性包。若是您擁有現有的安裝，您就能夠一直使用包管理工具，如 YAST，在完成基礎安裝以後添加這些包。強烈建議您將每一個 realserver 添加到 /etc/hosts 文件中。這將確保爲引入請求提供服務時，不會產生 DNS 相關的延遲。
此時，再次檢查每一個目錄是否都能對每一個 realserver 執行即時的 ping 操做：
清單 2. 對 realserver 執行 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
完成此操做後，從服務器中的本地包管理工具中安裝 ipvsadm、Heartbeat 和 mon。回想一下，Heartbeat 將被用於控制器內部通訊，而 mon 將被每一個控制器用於維護關於每一個 realserver 的狀態信息。
步驟 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 文件的內容如清單 3 所示。
咱們從 SLES9 系統中獲取 ha.cf 文件，而且爲 Version 2 添加底部的 3 行（respawn、pingd 和 crm）。若是您擁有現有的 version 1 配置，您也能夠選擇執行一樣的操做。若是您要使用這些指令執行新安裝，您能夠複製清單 3 並進行修改以適應您的生產環境。
清單 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
respawn 指令在運行時指定某個程序的運行和監控。若是此程序退出時的退出碼不是 100，程序將自動重啓。第一個參數是運行程序的用戶 id，第二個參數是要運行的程序。-m 參數將 pingd 屬性設爲從當前機器可得到的 ping 節點數的 100 倍，而 -d 參數在修改 CIB 中的 pingd 屬性以前將延遲 5 秒。ping 指令用於聲明 Heartbeat 的 PingNode，而 crm 指令指定了 Heartbeat 應運行 1.x-style 集羣管理器或 2.x-style 集羣管理器，後者支持 2 個以上的節點。
對於全部的控制器這個文件都應該相同。適當地設置權限使 hacluster 守護程序能夠讀取文件也絕對重要。不然將致使日誌文件中出現大量難於調試的警告。
對於某個版本的 1-style Heartbeat 集羣，haresources 文件指定了節點名和連網信息（浮動 IP、關聯接口和廣播）。對咱們而言，此文件仍然沒有變化：
litsha21 192.168.71.205/24/eth0/192.168.71.255
此文件將只用於生成 cib.xml 文件。
authkeys 文件指定了一個共享的密匙以容許控制器之間進行通訊。共享密鑰就是一個密碼，全部的 heartbeat 節點都知道這個密碼並使用它進行相互通訊。密鑰的使用避免了無關方對 heartbeat 服務器節點的影響。此文件也沒有變化：
auth 1
1 sha1 ca0e08148801f55794b23461eb4106db
接下來的幾步將向您展現如何將 version 1 的 haresources 文件轉換爲 version 2 的基於 XML 的配置格式 (cib.xml)。雖然能夠直接複製並使用清單 4 中的配置文件做爲起點，可是強烈建議您針對本身的部署進行配置調整。
爲了將文件格式轉換爲部署中使用的基於 XML 的 CIB (Cluster Information Base) 文件，請發出如下命令：
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 進程。
現已完成 heartbeat 配置，對 heartbeat 進行設置，使其在每一個控制器的引導階段啓動。爲此，在每一個控制器上發出如下命令（或相對您的發行版的等效命令）：
# chkconfig heartbeat on
重啓每一個 LVS 控制器以確保 heartbeat 服務在引導階段正常啓動。經過首先暫停保存浮動資源 IP 地址的機器，您能夠等候其餘 LVS Director 映像創建 quorum，而後在幾秒鐘內實例化最新選擇的主節點上的服務地址。當您將暫停的控制器映像從新聯機時，機器將在全部的節點間從新創建 quorum，此時浮動資源 IP 可能傳輸回來。整個過程只會耗費幾秒鐘。
另外，此時，您可能但願使用圖形化工具處理 heartbeat 進程 hb_gui（如圖 2 所示），手動地將 IP 地址在集羣中移動，方法是將各類節點設置爲備用或活動狀態。屢次重試這些步驟，禁用並從新啓用活動的或不活動的各類機器。由於先前選中了配置策略，只要能夠創建 quorum，而且至少有一個節點合格，那麼浮動資源 IP 地址就保持正常運做。在測試期間，您可使用簡單的 ping 確保不會發生丟失包的狀況。當您完成試驗後，應該對配置的健壯性有一個深入的體會。在繼續操做以前請確保浮動資源 IP 的 HA 配置適當。
圖 2. 用於 heartbeat 進程的圖形化配置工具 hb_gui
圖 2 展現了登陸後的圖形控制檯的外觀，上面顯示了託管資源和相關的配置選項。注意，當您首次啓動應用程序時，必須登陸到 hb_gui 控制檯；使用何種憑證將取決於您的部署。
注意，圖 2 中 litsha2* 系統集羣中的每一個節點都處於運行狀態。標記爲 litsha21 的系統目前是活動節點，如 (IPaddr_1) 正下方鋸齒狀的附加資源所示。
另外要注意標記爲 「No Quorum Policy」 的選項的值爲 「stop」。這指的是任何單獨的節點將釋放它所擁有的資源。這個決策的含義是，在任何給定時間，必須有 2 個 heartbeat 節點是活動狀態，以便創建 quorum（換言之，一種 「少數服從多數」 的投票規則）。即便只有一個節點是活動的，徹底運行的節點也會因爲網絡故障丟失它與同級系統之間的鏈接，或者，若是兩個非活動的同級系統同時暫停，資源將被自動釋放。
步驟 4：使用 ipvsadm 命令建立 LVS 規則
下一步是獲取浮動資源 IP 地址並在其上進行構建。由於 LVS 要求對遠端 Web 瀏覽器客戶機透明，因此全部的 Web 請求都必須通過控制器過濾並傳給一個 realserver。而後，全部結果都須要傳回控制器，後者向發出 Web 頁面請求的客戶機返回響應。
爲了完成上述的請求和響應流程，首先配置每一個 LVS 控制器，從而發出如下命令啓用 IP 轉發（所以容許將請求傳給 realserver）：
# echo "1" >/proc/sys/net/ipv4/ip_forward
# cat /proc/sys/net/ipv4/ip_forward
若是全部的操做都成功，那麼第二個命令將返回一個 「1」 做爲終端輸出。要永久性地添加此選項，請添加：
'' IP_FORWARD="yes"
到 /etc/sysconfig/sysctl 中。
接下來，要通知控制器將引入的 HTTP 請求傳遞給 HA 浮動 IP 地址，接着再傳給 realserver，使用 ipvsadm 命令。
首先，清除舊的 ipvsadm 表：
# /sbin/ipvsadm -C
在配置新表以前，您須要決定但願 LVS 控制器使用何種工做負載分配。收到來自客戶機的鏈接請求後，控制器根據一個 「進度表」 將 realserver 指派給客戶機，而後使用 ipvsadm 命令設置調度程序類型。可用的調度程序包括：
- Round Robin (RR)：新的引入鏈接被依次指派給每一個 realserver。
- Weighted Round Robin (WRR)：使用附加的權重因子進行 RR 調度以補償各類 realserver 功能（如附加 CPU、更多內存等）的差別。
- Least Connected (LC)：新鏈接指向具備最少鏈接數量的 realserver。不要求是最空閒的 realserver，可是以此爲方向。
- Weighted Least Connection (WLC)：帶權重的 LC。
使用 RR 調度進行測試是個不錯的方法，由於易於確認。您可能但願將 WRR 和 LC 添加到測試例程中以確認它們可以按預期運做。此處給出的示例使用 RR 調度及相似調度。
接下來，建立腳本以啓用轉發至 realserver 的 ipvsadm 服務，而且在每一個 LVS 控制器中放置一個副本。當完成 mon 的後續配置以自動監控活動的 realserver 後，就不須要再使用這個腳本，但在此以前它會有助於測試 ipvsadm 組件。請記住在執行此腳本以前從新檢查網絡和 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 服務，而後實際上使用了相同的代碼節以便將 Web 和 SSL 請求轉發給每一個單個的 realserver。咱們使用了 -m 選項指定 NAT，並給每一個 realserver 賦以權重 1（-w 1）。使用正常的輪循調度時，指定的權重會出現冗餘（由於默認的權重老是 1）。顯示此選項的唯一目的是讓您傾向於選擇加權的輪循。 爲此，在關於使用輪循的註釋下的 2 個連續的行中將 rr 改成 wrr，固然不要忘了相應地調整權重。有關各類調度程序的更多信息，請查詢 ipvsadm 手冊。
您如今已經配置了每一個控制器，能夠處理引入的對浮動服務 IP 的 Web 和 SSL 請求，方法是重寫這些請求並連續地將工做傳遞給 realserver。可是爲了從 realserver 收回通訊量，而且爲了在將請求返回給發出請求的客戶機以前執行相反的過程，您須要對控制器更改幾個連網設置。其緣由是須要在平面網絡拓撲結構中實現 LVS 控制器和 realserver（即，同一子網上的全部組件）。咱們須要執行如下步驟以強制 Apache 經過控制器返回響應通訊量，而不是本身直接應答：
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
執行此操做的目的是爲了防止活動的 LVS 控制器通知 realserver 和浮動服務 IP 直接相互通訊，從而獲取 TCP/IP 捷徑（由於它們位於同一個子網中）。通常狀況下，重定向是有用的，由於它們經過清除網絡鏈接中沒必要要的中間件提升了性能。可是此時，它可能阻礙了響應通訊量的重寫，而這又是對客戶機透明所必需的。實際上，若是在 LVS 控制器上沒有禁用重定向，那麼從 realserver 直接發往客戶機的通訊量將被客戶機視爲未被請求的網絡響應而被丟棄。
此時，可將每一個 realserver 的默認路由設爲指向服務的浮動 IP 地址，從而確保全部的響應都被傳回控制器以進行包重寫，而後再傳回最初發出請求的客戶機。
一旦在控制器上禁用重定向，而且 realserver 被配置爲經過浮動服務 IP 發送全部的通訊量，那麼您可能須要測試 HA LVS 環境。要測試迄今爲止所作的工做，可以讓一個遠端客戶機上的 Web 瀏覽器指向 LVS 控制器的浮動服務地址。
爲了在實驗室進行測試，咱們使用的是基於 Gecko 的瀏覽器（Mozilla），可是任何其餘瀏覽器也能夠知足要求。爲了確保部署成功，在瀏覽器中禁用緩存，並屢次單擊刷新按鈕。在每次刷新時，您應看見顯示的 Web 頁面是 realserver 上配置的一個自識別頁面。若是您要使用 RR 調度，您應能夠看到連續經過每一個 realserver 的頁面循環。
您是否正在思考確保 LVS 配置在引導時自動啓動？如今千萬別這樣作！還有一個步驟還沒有完成（步驟 5），此步驟將執行 realserver 的活動監控（所以保留一個動態 Apache 節點列表，其中的節點能夠爲工做請求提供服務）。
步驟 5：在 LVS 控制器上安裝和配置 mon
迄今爲止，您已經創建了一個高度可用的服務 IP 地址，並將其綁定到 realserver 實例池。可是在任何給定時間您決不能信任任何單個的 Apache 服務器是正常運做的。經過選擇 RR 調度，若是任何給定的 realserver 被禁用，或者以一種即時的方式中止響應網絡通訊量，那麼 1/6 的 HTTP 請求將會失敗！
所以有必要實施 realserver 對每一個 LVS 控制器的監控，以便動態地將其添加到服務池中或從中刪除。另外一個著名的稱爲 mon 的開源包很適合這項任務。
mon 解決方案通常用於監控 LVS 真實節點。Mon 的配置相對容易，而且對於熟悉 shell 腳本編程的人而言可擴展性很好。讓全部組件正常運做大體分如下三個主要步驟：安裝、服務監控配置和警報建立。使用包管理工具處理 mon 的安裝。完成安裝後，您只須要調整監控配置，並建立一些警報腳本。當監視器肯定 realserver 已經脫機或恢復聯機時，將觸發警報腳本。
注意，安裝 heartbeat v2 後，監控 realserver 可經過構建全部的 realserver 服務資源來完成。 或者，您可使用 Heartbeat ldirectord 包。
默認狀況下，mon 附帶了幾個能夠直接使用的監視器機制。咱們修改了 /etc/mon.cf 中的樣例配置文件以使用 HTTP 服務。
在 mon 配置文件中，確保標題能夠反映正確的路徑。SLES10 是一個 64 位的 Linux 圖像，可是隨附的樣例配置用於默認的（31 位或 32 位）位置。配置文件樣例假定警報和監視器位於 /usr/lib 中，這對於咱們的特定安裝而言並不正確。咱們修改的參數以下：
alertdir = /usr/lib64/mon/alert.d
mondir = /usr/lib64/mon/mon.d
如您所見，咱們只是將 lib 更改成 lib64。對於您所使用的版本可能不須要這種更改。
對配置文件的下一個更改是指定要監控的 realserver 列表。這能夠經過如下 6 個指令完成：
清單 6. 指定要監控的 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 如何查看故障，以及如何處理故障。爲此，添加如下的監視器段（分別針對每一個 realserver）。完成後，您須要將 mon 配置文件和警報置於每一個 LVS heartbeat 節點之上，啓用每一個 heartbeat 集羣節點以獨立地監控全部的 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 -hupalert 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，默認狀況下它由 mon 附帶。另外，指定使用端口 80。清單 7 還提供了要請求的特殊頁面；您可能會選擇爲 Web 服務器傳輸一小段更有效率的 html 做爲操做成功的證實，而不是傳輸一個複雜的默認 html 頁面。
alert 和 upalert 行調用的腳本必須置於配置文件頂部指定的 alertdir 中。其目錄一般是發行版所默認的目錄，好比 「/usr/lib64/mon/alert.d」。警報負責告知 LVS 將 Apache 服務器添加到合格的列表中或從中刪除（方法是調用 ipvsadm 命令，咱們很快就要介紹到）。
當一個 realserver 的 http 測試失敗時，dowem.down.alert 將由 mon 使用幾個參數自動執行。一樣地，當監視器肯定 realserver 已經恢復聯機時，mon 進程使用大量的參數自動執行 dowem.up.alert。您能夠隨意地修改警報腳本的名稱以適應您的部署。
保存此文件，在 alertdir 中建立警報（使用簡單的 bash 腳本編程）。清單 8 展現了一個 bash 腳本警報，從新創建 realserver 鏈接時由 mon 調用。
清單 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 腳本警報，當 realserver 鏈接丟失時由 mon 調用。
清單 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 命令行工具動態地將 realserver 添加到 LVS 表中或從中刪除。注意，這些腳本遠談不上完美。mon 只對於簡單的 Web 請求監控 http 端口，此處闡述的架構在下述情形中容易受到攻擊：給定的 realserver 對於 http 請求可能正常運做，但對於 SSL 請求卻不行。在這些狀況下，咱們將沒法從 https 備選列表中刪除有問題的 realserver。固然，除了爲 mon 配置文件中的每一個 realserver 啓用另外一個 https 監視器外，構建更多專門針對每種類型的 Web 請求的高級警報也能夠輕鬆地解決這個問題。這能夠留給讀者做爲練習。
爲確保監視器已被激活，依次爲每一個 realserver 啓用並禁用 Apache 進程，觀察每一個控制器對事件的反應。只有當您確認每一個控制器正常地監控每一個 realserver 後，您纔可使用 chkconfig 命令確保 mon 進程能夠在引導時自動啓動。使用的特定命令爲 chkconfig mon on，可是這可能隨發行版的不一樣而有所區別。
完成這個最後的部分後，您就已完成構建跨系統的高度可用的 Web 服務器基礎設施的任務。固然，您如今可能想要執行一些更高級的工做。例如，您可能已經注意到，mon 守護程序自己沒有被監控（heartbeat 項目能夠爲您監控 mon），可是最後的步驟已爲此打下基礎。
故障診斷
活動節點在一個 HA 集羣中不能正常運做有多種緣由，自願的或非自願的。節點可能丟失與其餘節點的網絡鏈接，heartbeat 進程可能被中止，可能出現任何環境事件等等。要故意地讓活動節點失效，您能夠要求該節點暫停，或將其設爲備用模式，方法是使用 hb_gui（徹底關閉）命令。若是您但願測試環境的健壯性，您可能須要一些更激進的方式。
指示器和故障恢復
系統管理員可使用兩種日誌文件指示器配置 Linux HA heartbeat 系統。日誌文件與系統是否爲浮動資源 IP 地址的接收方有關。沒有接收浮動資源 IP 地址的集羣成員的日誌結果相似於：
清單 10. 落選者的日誌結果
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 成員能夠投票。獲取投票，不須要執行其餘操做便可恢復正常運做。
相反，接收了浮動資源 IP 地址的集羣成員的日誌結果以下：
清單 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 文件展現了此節點已經得到了浮動資源。ifconfig 行顯示將動態建立 eth0:0 設備以維持服務。
如清單 11 所示，獲取了一份名單，有足夠的 quorum 成員能夠投票。獲取投票後，發出的 ifconfig 命令索要浮動資源 IP 地址。
另一種指示什麼時候發生故障的方法是，您能夠登陸到任何一個集羣成員並執行 hb_gui 命令。使用這種方法，您能夠經過親自查找擁有浮動資源的系統來肯定故障發生時間。
最後，若是咱們不展現一個非 quorum 情形的樣例日誌文件彷佛有些說不過去。若是某個單一節點沒法與任何一個其餘節點進行通訊，那麼它就丟失了 quorum（由於在 3 個成員的投票中 2/3 是多數）。在這種狀況下，節點獲悉已丟失 quorum，而後調用 no quorum policy 處理程序。清單 12 展現了一個來自這類事件的日誌文件示例。丟失 quorum 時，日誌條目將會有所顯示。顯示此日誌條目的集羣節點認爲本身不具備浮動資源。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 所示，當某個給定節點丟失 quorum 時，它將放棄全部資源，由於選擇了 no quorum policy 配置。是否選擇 no quorum policy 徹底取決於您本身。
Fail-back 動做和消息
正確配置的 Linux HA 系統的一個更有趣的含義是，您不須要執行任何操做就可從新實例化集羣成員。只須要激活 Linux 實例便可讓節點自動地從新加入其餘節點。若是您配置了一個主節點（即，一個能夠優先於其餘節點得到浮動資源的節點），它將自動從新得到浮動資源。非優先的系統將只是加入合格節點池並正常運做。
將其餘的 Linux 實例往回添加到池中將使每一個節點得到通知，而且若是可能的話，從新創建 quorum。若是能夠從新創建 quorum，那麼將在某個節點上從新創建浮動資源。
清單 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 後，執行投票，而 litsha22 將變爲具備浮動資源的活動節點。
- 1. 使用簡單的 5 個步驟設置 Web 服務器集羣
- 2. Samba服務器簡單配置步驟
- 3. 10臺服務器的簡單集羣
- 4. Web服務器集羣搭建關鍵步驟紀要
- 5. 理解 JSON Web Tokens (JWT) 的 5 個簡單步驟
- 6. 5個步驟給本身搭建一個簡單的GIT服務器
- 7. [譯]5個簡單的步驟去理解 JSON Web Tokens（JWT）
- 8. Apache+Tomcat服務器集羣配置詳細步驟
- 9. Keepalived+LVS-DR服務器簡單配置步驟配置
- 10. web服務器工作機制和服務器集羣簡介
- 更多相關文章...
- • 服務器上的 XML - XML 教程
- • ASP.NET Web Forms - Web 服務器控件 - ASP.NET 教程
- • Spring Cloud 微服務實戰(三) - 服務註冊與發現
- • TiDB 在摩拜單車在線數據業務的應用和實踐
-
每一个你不满意的现在，都有一个你没有努力的曾经。