Linux Enterprise Cluster NOtes — Ch9 Stonith and IPFail

1. 本章詳細介紹stonith，當兩台伺服器都嘗試要去接管資源的時候，就會出現split-brain的情況，當“心跳線”出現問題的時候，最容易出現這 種情況。這種情況是很致命的，他可能導致服務無法正常運行，更壞的是，有可能導致資料遭破壞，因為此時兩台伺服器都可能對一個資料來源進行讀寫，這就很有可 能導致問題，就算兩台伺服器都只會寫各自的存放裝置，但也會導致兩台伺服器的儲存內容不一致，所以這種情況要盡量避免，heartbeat給出的解決方案 就是－－stonith

2. stonith要能正常執行，需要一定的硬體裝置。該裝置具有這樣的特性，他可以串連在HA的兩台伺服器上（或串連在一台上也可），而且能通過軟體命令的 方式給這個裝置發送指令，然後該裝置直接將被控制的伺服器重啟或斷電，通過這種方式，快速的重啟或關閉一台伺服器，從而避免split-brain的情況 發生。

3. 本節開始介紹一個實際例子。該例子不是很常見，而且有一定的局限性，原因就在於這個例子中只使用了一個stonith裝置，該裝置串連了一台伺服器，換言 之，如果stonith裝置串連了primary server，那麼，在該例子中，只能由backup server發送命令，讓primary server重啟，primary server無法讓backup server重啟或關閉。

4. OK，該例子的硬體串連圖如下：附件1

5. 從附件的圖上可以看出，本例有如下兩點局限性：(1)所有的resource只能跑在primary server上 (2)failover只能從primary server -> backup server，因為一旦failover發生，backup server會發送命令讓primary server關閉或重啟以保證不會發生split-brain的情況

6. OK，在這種架構下，如果failover發生，那麼，會變成這種樣子，見附件2

7.畫的很清楚了，當heartbeat消失（可能是primary server down了，也可能是心跳線出現了問題），backup server通過stonith device發送reset的命令，從而將primary server強行重啟，如果auto_failback是配置成on的話，那麼，有可能在primary server重啟完成後，重新取回資源的控制權，但是通過這種方式，有效避免了split-brain情況的發生。

8. 然後給出目前heartbeat支援的一部分stonith裝置的清單：見附件1

9. 除了上面那些真實裝置之外，heartbeat還支援一些fake的device，通過這些device，可以讓我們類比情況來debug stonith是否能正常工作。見附件2

10. 在我們安裝了heartbeat的stonith的package之後，可以通過這個命令來查看當前heartbeat支援的stonith device列表：/usr/sbin/stonith -L

11. 下面開始講解Meatware device。這是一個fake的stonith device，但是可以用來給我們調試stonith。當我們配置了一個meatware的stonith device之後，stonith不會去發送什麼command給stonith device，然後簡單的發布一個operator alert（一般可以在heartbeat的日誌中查看到這條資訊），通過這種方式，可以讓我們測試一下stonith。

12. 通過以下命令建立一個meatware device:

#/usr/sbin/stonith -t meatware -p "" chilly

這個命令表示為host chilly建立一個meatware type的stonith device，parameter為空白。

執行完這個命令後，查看/var/log/messages檔案，會發現：

STONITH: OPERATOR INTERVENTION REQUIRED to reset test.
STONITH: Run "meatclient -c test" AFTER power-cycling the machine.

這表示STONITH讓我們運行meatclient -c chilly這個命令，從而對重啟chilly這台機器做一次測試。如果我們真的有chilly這台機器，那麼就需要手動將這台機器重啟一下，然後執行 meatclient -c chilly這個命令將這條stonith的event清除掉。由於我們沒有chilly這台機器，所以直接執行：meatclient -c chilly，將這條event清除。執行這條命令或，會出現：

WARNING!
If server "chilly" has not been manually power-cycled or disconnected from all shared resources and networks, data on shared disks may become corrupted and migrated services might not work as expected.
Please verify that the name or address above corresponds to the server you just rebooted.
PROCEED? [yN]

按下y之後，出現：

Meatware_client: reset confirmed.

13. 這樣，一個meatware device建立完成了，然後我們就可以在ha.cf中配置了，在兩台伺服器的/etc/ha.d/ha.cf中都添加這樣一行：

stonith_host * meatware

OK了，第二個參數的作用是告訴heartbeat哪台伺服器是串連在stonith device上的，這裡用了一個*，表示兩台伺服器都物理串連在了stonith device上，stonith可以對任何一台都做reset這樣的動作，因為我們用的是meatware，所以當然可以這樣寫，如果是真實裝置，那麼， 按照具體的來寫。

14. 這樣就OK了，把兩台伺服器的heartbeat都啟動起來，然後用kill -9將primary server的heartbeat進程殺掉（注意不要用service heartbeat stop這樣的命令哦，因為這個命令會將primary server上的資源安全卸載，backup server順利接收，從而構不成split-brain的情況，只有強行殺掉，類比伺服器失效的情境），此時觀察backup server的/var/log/messages：

backupserver heartbeat[835]: info: **************************
backupserver heartbeat[835]: info: Configuration validated. Starting heartbeat <version>
backupserver heartbeat[836]: info: heartbeat: version <version>
backupserver heartbeat[836]: info: Heartbeat generation: 3
backupserver heartbeat[836]: info: UDP Broadcast heartbeat started on port 694 (694) interface eth0
backupserver heartbeat[841]: info: Status update for server backupserver: status up
backupserver heartbeat: info: Running /etc/ha.d/rc.d/status status
backupserver heartbeat[841]: info: Link backupserver:eth0 up.
backupserver heartbeat[841]: WARN: server primaryserver: is dead
backupserver heartbeat[841]: info: Status update for server backupserver: status active
backupserver heartbeat[847]: info: Resetting server primaryserver with [Meatware Stonith device]
backupserver heartbeat[847]: OPERATOR INTERVENTION REQUIRED to reset primaryserver.
backupserver heartbeat[847]: Run "meatclient -c primaryserver" AFTER power-cycling the machine.
backupserver heartbeat: info: Running /usr/local/etc/ha.d/rc.d/status status
backupserver heartbeat[852]: info: No local resources [/usr/local/lib/heartbeat/ResourceManager listkeys backupserver]
backupserver heartbeat[852]: info: Resource acquisition completed.

從上面的log資訊可以看到，backup server並沒有馬上把sendmail服務啟動（sendmail是本例中的resource），而是在等待我們清除meatware stonith event，這表示我們要手動重啟primary server，然後用meatclient -c這樣的命令清除event，這樣heartbeat才會認為OK, primary server重啟了，backup server可以安全的啟動sendmail了，:)

15. 好的，那我們就開始清除這個event：

backupserver> meatclient -c primaryserver

此時，backup server的log如下：

backupserver heartbeat[847]: server primaryserver Meatware-reset.backupserver heartbeat[847]: info: server primaryserver now reset.
backupserver heartbeat[841]: info: Resources being acquired from primaryserver.
backupserver heartbeat: info: Running /usr/local/etc/ha.d/rc.d/stonith STONITH
backupserver heartbeat: info: Running /usr/local/etc/ha.d/rc.d/status status
backupserver heartbeat: stonith complete
backupserver heartbeat: info: Taking over resource group sendmail
backupserver heartbeat: info: Acquiring resource group: primaryserver sendmail
backupserver heartbeat: info: Running /etc/init.d/sendmail start

OK，backup server將sendmail啟動起來了。

16. 使用一個real的stonith device。很顯然，每個stonith device都有各自不同的配置，執行命令stonith -help可以看到如何配置這些device，配置一個real的stonith device的文法是這樣的：

STONITH: Config file syntax: <serial_device> <server> <outlet> [ <server> <outlet> [...] ]

比如：

STONITH_host backupserver rps10 /dev/ttyS0 primaryserver.mydomain.com 0

這個配置表示: backup server可以通過stonith device控制primary server，stonith device通過/dev/ttyS0串連在backup server上（串口線），primary server是串連在名為rps10的stonith device的0號outlet（插口）上。

還是比較簡單的，注意現在很多stonith device都是通過網線和伺服器串連，此時的配置有可能還要配置登入的使用者名稱和密碼（增強安全性，防止駭客輕鬆重啟這些伺服器），而且在很多大廠的裝置 中，比如hp，stonith device直接就整合在伺服器內部也是有可能的。

17. 避免多次stonith event，如果我們將auto_failback配置成on，而且stonith是重啟伺服器而不是關閉，那麼就有可能發生迴圈stonith的情況， 比如primary server down了，stonith device重啟了他，當primary server起來後，接管回資源後又down了，那麼又重複上述過程，這就是多次stonith，解決這種問題很簡單，直接power off primary server，而不是reset他即可，要做到這樣有兩種辦法，第一，修改heartbeat的source code（好誇張哦）：

rc = s->s_ops->reset_req(s, ST_GENERIC_RESET, nodename);

修改成：

rc = s->s_ops->reset_req(s, ST_POWEROFF, nodename);

或者是第二種辦法，修改primary server的BIOS設定，很多機器的BIOS中可以設定reset訊號收到時執行關機的動作而不是reset。

17. network failures. 到目前為止，我們已經做了很多努力來避免單點故障的情況，但是還不夠，比如本節說到的network failure。這種情況是這樣的，我們都知道，伺服器通過網路對外提供服務，如果這個服務網路出現問題怎麼辦？（心跳線沒有問題），此時clients 無法通過網路和primary server通訊，那麼，服務就暫停了。對於這樣的問題，我們有兩種解決方案：

(1)運行一個第三方的監控程式，監控primary server是否能正常訪問網路，如果發現通訊異常，該監控程式將shutdown primary server上的heartbeat daemon，此時failover發生，backup server接管服務。
(2)使用heartbeat內建的ipfail plug-in，通過這個ipfail，我們可以在heartbeat中配置讓ipfail定時的去ping一批伺服器，如果ping發生異 常，ipfail會詢問backup server "你的網路正常嗎？"，如果backup server能正常訪問網路，那麼failover發生。

本節描述第二種方法：

respawn hacluster /usr/lib/heartbeat/ipfail
ping 10.1.1.254 10.1.1.253
auto_failback off

從上可以看出，首先我們以hacluster使用者的名義啟動了ipfail這個daemon，然後ping 10.1.1.254和10.1.1.253兩台伺服器。這些配置可以添加在/etc/ha.d/ha.cf檔案中最後部分（寫在server配置的前面）

18. watchdog and softdog. watchdog分為硬體和軟體兩種，硬體就是專門的硬體狗了，當發現OS異常，就會重啟機器；軟體dog指的是linux kernel內建的一個softdog daemon，如果kernel不支援，那就要重新編譯kernel了，一般我們用的redhat這些這個feature kernel都是有的，大不了是一個module。

19. 本節只講softdog，用modprobe可以掛載softdog模組，掛載上了之後，當發現系統異常，softdog就會將系統置於一個kernel panic的狀態，但是我們希望的是重啟系統，而不是panic系統，這可以通過這樣的配置來解決：

(1)修改lilo或grub的啟動參數，在image=...這個之前加入：append="panic=60"

(2)這種方法更簡便，如下：#echo 60 > /proc/sys/kernel/panic ，預設的panic時間是0，修改成60後，就會重啟系統了。

20. heartbeat也支援watchdog，在/etc/ha.d/ha.cf檔案中加入：

watchdog /dev/watchdog

這樣dog就會監控heartbeat進程，如果我們kill了heartbeat的進程，那麼，系統就會重啟（因為軟體狗在起作用）

21. heartbeat已經全部講解完畢了，後面就會開始講LVS了。這裡有個總結，如何測試我們的heartbeat配置，書中給了一些建議，還不錯，這裡將內容提綱列在這裡，詳細的請參考書的內容：

(1)unplug the power cord on the primary server
(2)test the behavior of the hb_standby command
(3)unplug the production network cable on the primary server
(4)remove one of the heartbeat paths between the two servers
(5)remove all of the heartbeat paths between the two servers
(6)kill the heartbeat daemon on the primary server
(7)kill the resource daemons on the primary server（如果我們用了cl_respawn，那麼heartbeat會自動重啟resource，當發現resource script的status指令碼不返回OK的時候）
(8)reboot both servers