在商業服務的Rails HTTP Cluster觀念及測試中，我提到了failover也是cluster的其中一個觀念。幾年前我用heartbeat，只是單純架設 pgcluster的load balancer，那個時候也是簡單的active / standby。在那個時候，有這樣的架構已經減輕大部分人所遇到的問題：有一台掛掉另一台可以馬上取代其服務，讓維護者有時間可以救，使用者不會罵，已 經是很偷笑的事情了。不然一般的維護者可能要急得像熱鍋上的螞蟻，拼命地輸入指令試著想要拯救資料或服務，而在數小時的工作後，服務還是救不起來，使用者 罵聲四起。但是其實對我而言，這些比起硬體的方案，還是多多少少嫌不方便。

參考這個網頁，可以瞭解有那些failover的方式。 http://www.ukingdom.com.tw/pro/lifekeeper/lifekeeper.htm

先不管後面的階層化或是多方向failover，其中提到的active/active及active/standby，為啥要有這些分別呢？我來一個一個介紹。

Failover的種類

active/standby

對於一般架設LAMP來建置phpbb論壇，或是一些簡單Web服務(如wiki)的管理者，在經費拮据的情況下，通常都是先跑一台，在想辦法生另 一台。這時進行active/standby的好處是，原理單純設定簡單，兩台跑同樣的OS同樣的服務，一台掛了另一台頂替。但缺點就會造成 standby的那一台會浪費CPU資源，所以在很久以前的小論壇都沒有問題，但是到現在，要應付可能會日漸成長的web 2.0社群式的論壇，可能一開始就不能考量這樣玩了。

active/active

另一種作法是兩台主機都維持上線的狀態，也就是可以說有主站，也有個副站。而一旦任何一方掛了，另一方就可以直接抓下對方的IP，就當作是一樣的服 務了。當然這樣還是可以讓管理者有時間可以去處理。然而在商用服務的狀況下，通常使用者會比較難接受有兩個以上的IP或是URL，這個算是缺點之一。但優 點就是相對地如果使用者可以接受副站的情況之下，就會有效地疏散流量及CPU負載。

以上就是1.0版的時候提供的功能。有關heartbeat 1.0可以參考舊文章 http://kiwi.csie.chu.edu.tw/blog/archives/48

Cluster Resource Management

而在heartbeat 2.0中已經引進了資源管理的觀念，意思就是將一個服務程式或是一個IP視作一種資源，而這個資源可以任意在cluster裡的任意的node中 migrate(遷移)。當然與上述兩種不同的是，在這種情況下node就可以是兩個以上了。這並不是 process migration(行程遷移)，還沒有那樣進步連程式或設定檔都可以自己搬走。所有node要拿來當作資源的服務，一開始就必須全部自行建置好在完全正 常的狀態。當進行遷移的時候，heartbeat還是會以service {服務名稱} start/stop的方式來完成這樣的工作。其實這個方式基本上是和active/standby一樣，不過重要的是搭配cluster的load balance機制，也就是像下圖一樣。因為本來就要做load balance，每個node預設將apache啟動，而需要遷移的資源也頂多只有ip和haproxy，就不需要浪費時間啟動較慢的apache。

另一點是資源的群組，數量，相依性，啟動順序，甚至限制在哪些node上跑，全部都可以調整。也因此如果要做active/active那樣主站副站的作法也完全可行。

如這兩張圖，假設有一個 cluster有四個node，在正常的情況下，使用者會透過Virtual Server的IP連到Real Server的真實服務，這個我們在之前的文章已經談過。然而套用heartbeat 2.0的觀念，我們將virtual server ip及haproxy設定為資源，接著這個資源就可以進行手動或自動的遷移。手動遷移就像是，當你點下移往第二台的按鈕後，第一台就會停止服務，而第二台 就會開啟服務。自動遷移會發生在整個cluster的服務被斷定為無法使用的情況下，其他node自動地挑出下一個Quorum(服務候選人)，並且將該 候選人的服務喚起，來完成資源遷移。根據硬體執行完服務的速度，遷移大概會在10秒到30間完成，像haproxy是個小程式，整個遷移的動作在10秒內 就完成了。而當cluster上所有node偵測到原本斷線的node回復，又會自動將資源遷移回第一個node，這個是因為heartbeat執行的演 算法必須要維持一致性的關係。

儘管heartbeat 2.0多個了這個他稱為CRM(Cluster Resource Management)的技術，卻像是以plugin的方式掛上，核心設定還是沒有啥改變，只要加上crm yes選項就可以啟動了。此外也有附上另一個做的不錯的GUI介面，讓資源建立，監控和操作更為順暢。

此外在閱讀過後heartbeat的wiki後，我確實覺得他們的編排有點「偷懶」，就是提到了2.0版更新的部分，然後讓你把1.0的說明和2.0的說明混在一起看。其實這樣子並沒有辦法好好解釋2.0的觀念。

實做

安裝

在所有linux平台上，包括fedora 6、7， CentOS 5，SuSE Enterprise 10，Ubuntu，Gentoo上都可以找到heartbeat的蹤跡。在這裡就只提到redhat系列平台基本上是採用yum，所以打yum install heartbeat就可以了。不過如果要安裝heartbeat_gui，請確定要有XWindow或是VNC，然後打yum install heartbeat_gui。

兩個設定檔

以下兩個步驟和heartbeat 1.0一樣，先從/usr/share/doc/heartbeat-{version} /複製ha.cf, authkeys兩個檔案至/etc/ha.d/ 編輯ha.cf，在node設定的部分，依照你的主機名稱，依序打上。請注意這些名稱一定要符合在該主機上打uname -n所顯示的值

node web01
node web02
node web03
...
crm yes

接著編輯authkeys，使用以下設定即可。如果你的網路環境沒有啥防火牆，建議使用md5或是sha1

auth 1
1 crc

接著在其他主機也依此安裝，也順手裝好你想要當作資源的服務，就可以service heartbeat start來啟動。

與1.0不相同的是，接著可以參考這段影片，瞭解heartbeat gui怎樣操作。

http://www.linux-ha.org/Education/Newbie/IPaddrScreencast

那我稍微解釋各張投影片在說啥：

  1. 這邊最主要是介紹，與打指令啟動hb_gui
  2. 這邊要提示你，本來在安裝的時候就有新增了一個群組叫haclient，你可以編輯/etc/group然後把你想要的帳號加進去
  3. 這邊可以看到主畫面，如果點選linux-ha，也就是cluster的名字，可以看見其設定。Status會顯示with quorum或是without quorum，表示是否能夠找的到服務候選人。記住要是沒有服務候選人的話(通常是只有一台的情形)，是無法儲存設定的，服務基本上也不會啟動。畫面右邊可以看見cluster的屬性，這些都可以在ha.cf修改。
  4. 將nodes展開後，可以看見有標著DC的node，這個表示協調者目前是位於哪一個node。以他的設計，協調者也會遷移的，無須擔心。
  5. 這邊可以點+圖示來新增資源
  6. 資源視窗裡，可以看見現在可以使用資源種類的列表。注意到class/provider會有lsb或是osf，表示是從/etc/init.d讀取到的，或是heartbeat自己提供的。
  7. 接著他在名稱裡就打了our_ipaddr，名稱當然是取的看得懂就好。此外旁邊group最好也要填，讓接著要加入的資源也填同一個group 的名字。基本上IP當然跟服務綁在同一個群組裡，除非你是想要做active/active。選好填好之後，可以自己刪除或新增parameters，一般來說lsb的通常都可以把parameters全刪了。然後在這裡你可以看見他填入ip address。
  8. 如果資源還沒啟動，就按播放圖示吧！
  9. 接著因為target_role本來是表示資源啟動的狀態，但因為使用GUI本來就可以看得到，怕會讓自己搞混，就刪了吧
 10. 接著只是單純展示資源可以停止，或是可以增加額外的parameters。我在這邊在多解釋一個功能是，可以在任何一個 node上點右選standby來模擬該node斷線，或是點上下的箭頭圖示來遷移資源，這就讓大家自己玩了。

結論

要測試其實很簡單，把網路線拔掉就可以了。不過要注意的是，拔拔插插的動作不要太頻繁，會導致反應很慢；但因為CRM所使用的演算法在node有兩 個以上，不修改預設設定的情況下，是不會產生死結的，算是可以放心試。此外也不一定要使用hb_gui來監控，在文字介面下有一個crm_mon指令，可 以監控而不會像gui有時候會卡住不更新。

初學者還是要注意，千萬別將load balance和failover所用的程式搞混了。Linux上有名的ip load balance程式為ipvsadm與ldirectord，儘管heartbeat有附資源script來操作ldirectord，但其執行檔還是要 自己用RPM裝的。