Red Hat Certified Architect–Cluster篇
High Availability MySQL on RHCS 5.1 (上)
文／林彥明

此篇文章便是要介紹如何在RHCS 5.1上組態MySQL資料庫，架構High Availability MySQL Solution。

---

就筆者所接觸的客戶，通常企業的資料庫伺服器都會採用備援機制。因為資料庫通常是企業內最重要的服務，一旦資料庫伺服器因硬體或其它原因停止服務，會造成莫大的損失。所以資料庫伺服大多會採用High Availability架構，當原來的資料庫伺服器無法提供服務時，備援的伺服器會馬上接管(take over)資料庫服務。

RHCS基本理論
在介紹如何建罝MySQL on RHCS之前，先概述RHCS的基本理論。凡事起頭難，如果一開始便陷入深奧的理論，讀者必然興趣缺缺。所以筆者一直在想如何用淺顯易懂的方式讓大家先對RHCS的專有名詞及架構有基本的瞭解。

圖1 RHCS Failover Domain示意圖。(圖片來源：www.redhat.com)

Red Hat官方文件中有三張圖(圖1~圖3)可說是整個RHCS架構的精髓，圖1中有Cluster Nodes、Failover Domain、Service三個重要名詞，以下分敘之。

Cluster Nodes
Cluster Nodes就是Cluster的成員，就是一台台伺服器。以前筆者也提過：Cluster是什麼？一般的定義，「所謂Cluster就是由一台以上的機器，為了某種特定需求所組成的架構」，根據不同的需求，可將Cluster分為以下三種，並對應Red Hat由何種軟體提供相關功能。
1.High availability cluster：增加伺服器和以網路為基礎的應用程式的高可用性及備援性；由Cluster Suite中的Cluster Manager技術提供。
2.Load Balancing cluster：將服務需求分派給多台伺服器，可視系統負載隨時彈性增加伺服器；由Cluster Suite中的Linux Virtual Server(Piranha)技術提供。
3.High performance cluster(HPC)－提供同步運算及平行處理的能力；Cluster Suite不提供(另外有lam、pvm套件，規劃由WS擔綱)。例如IBM Cluster 1350便是一種HPC解決方案。
此篇文章所介紹的Cluster是屬於「High availability cluster」，這裏有一點需要跟讀者特別強調的，一般的High availability cluster，通常用兩台機器組成High availability cluster(例如IBM HACMP解決方案)，主要伺服器停止服務時，備援伺服器便會馬上接手主要伺服器的service。但Red Hat所提供「High availability cluster」解決方案，最好用三台以上的伺服器組成High availability cluster。如果只用兩台伺服器組成High availability cluster，則拔除傳遞heartbeat的網路線時，會發生split-brain(裂腦)的問題，Red Hat可利用quorum disk的技術來解決這個問題，不過這個部份理論較複雜，此篇文章先不討論此種作法，後面實作的部份，筆者會用3個nodes來組成Cluster，其目的是為了避免split-brain問題。

Failover Domain
「Failover Domain」這個名詞比較難理解，先看看Red Hat官方文件的定義：「A failover domain is a subset of cluster nodes that are eligible to run a particular cluster service.」
簡單來說，「Failover Domain」就是Cluster的子集(subset)，就是Cluster的部份。由圖1可以得知：
‧Cluster Nodes為nodeA、nodeB、nodeC、nodeD及nodeE。
‧nodeA和nodeB組成Failover Domain 1。
‧nodeB、nodeC及nodeD組成Failover Domain 2。
‧nodeC、nodeD及nodeE組成Failover Domain 3。
這樣照字面解釋完後，我想讀者一定還有疑問，那為什麼要分「Failover Domain」？還記得筆者在「Single Point of Failure」文章內所提過——「"failover"機制指的是如果一台伺服器停機或故障，另一台伺服器可以接手(takeover)故障伺服器所提供的服務。」
OK！我們再回頭看圖1，Failover Domain1後緊接著Service X、Failover Domain2後緊接著Service Y、Failover Domain1後緊接著Service Z。
所以Failover Domain的目的是指定Service X只能在Failover Domain1內移轉，也就是Service X可在nodeA和nodeB或上執行。同理Service Y在Failover Domain2內移轉，也就是Service Y可在nodeB、nodeC或nodeD或上執行。
再提醒大家一件事，這是「High availability cluster」，最主要是提供備援機制，Service同時間只能在某一個node上啟動，以Failover Domain1而言，ServiceX只能在nodeA或nodeB上執行，假設一開始是在nodeA上執行，當nodeA掛掉時，ServiceX就會自動移轉至nodeB上。

Service
那什麼是Service？Service很容易讓大家誤以為就是/etc/init.d/httpd這類應用程式，在RHCS中的Service其實是一堆Resource的組合。各位想想，如果主要的WWW伺服器掛掉，另一台備援的伺服器要接管WWW服務，只需啟動/etc/init.d/httpd嗎？不對吧！應該還要把原來Client所連接的IP(常稱service IP)移轉到備援伺服器，還有要把原來的網頁檔案系統(應該要在share disk)掛載起來，最後才是執行/etc/init.d/httpd start。經過以上講解，再看圖2，就會豁然開朗，圖2中content service 是由IP resource(service ip)、Application resource(/etc/inti.d/httpd)及File system resource(網頁檔案系統)所組成。

圖2 Web Server Cluster Service Example。（圖片來源：www.redhat.com）


Fencing Device
圖3中，有個奇怪的裝置「Fencing Device」，「Fencing Device」可能是大家最陌生的，因為其它Unix的HA Solution並不需要此裝置。先不要管Fence中文意義是什麼「柵欄、籬笆」，等一下筆者再解釋為什麼叫Fencing Device。RHCS中提到的Fencing Device，是一種可以直接對伺服器做電源Power ON/Power OFF的裝置，注意筆者說的是「電源」，不是去執行作業系統的開關機指令。RHCS支援的Fencing Device很多，不過有些並不常見，例如有種電源延長線，你可以用telnet指令，對某一個插座做Power ON/Power OFF的動作，那麼接在這個位置上的伺服器不管作業系統是否完全無反應(有時伺服器loading過重，會連ssh也無法登入)都會重開機，這種電源延長線有時我們稱作NPS(Network Power Switch)。不過NPS，在台灣使用的人很少，就筆者所接觸的案子，客戶通常是採購本身有支援IPMI的伺服器，直接用伺服器IPMI的功能，或是額外購買IBM RSAII卡或是HP iLO卡。
說了那麼多，還是沒解釋為什麼要「Fencing Device」，別急，也看一下原廠文件的說明——「Fencing is the disconnection of a node from the cluster's shared storage. Fencing cuts off I/O from shared storage, thus ensuring data integrity. 」 為什麼RHCS需要「Fencing Device」，最主要是避免一種情況發生，什麼情況呢？實務上，尤其是資料庫伺服器可能會遇到這種情況，就是伺服器loading過重，完全無反應，連heartbeat也無法傳遞，但此時伺服器可能不是真的掛掉，筆者開玩笑的說法是「假死」，經過一段時間，loading沒那麼重時，又會活過來，heartbeat又可以傳遞。但是RHCS的機制，只要發現主要伺服器的heartbeat不通，讀者可以把heartbeat想成備援伺服器每隔時間就會ping主要伺服器(實際上RHCS並不是用ping的指令)，就像是去聆聽心跳，如果沒有回應(Missed too many heartbeats)，就判斷主要伺服器死了，那麼備援伺服器便會著手接管Service。但是萬一主要伺服器是假死，但Service中有包含File system resource ，那麼可能會造成兩台伺服器同時掛載File system，就會造成檔案系統資料不一致，嚴重的話可能會毀損整個檔案系統。
RHCS為了避免這種情況，想出了一個辦法，就是「Fencing Device」，當RHCS發現主要伺服器的heartbeat不通(Missed too many heartbeats)，第一件事不是著手接管Service，而是利用「Fencing Device」將主要伺服器重開機Power ON/Power OFF，筆者常開玩笑說，這樣一來，假死就變成真死了，也不可能發生主要伺服器還掛載File system resource的情況。
現在，讀者應該可以體會為什麼要稱為「Fencing Device」，Fencing有隔離/圍起來的意思，就是當伺服器假死或是無法umount File system 時，就把它隔離起來(power reboot)讓它無法存取File system resource (share storage)。

圖3 cluster config flowchart。（圖片來源：www.redhat.com）


iSCSI規劃及建置
基於大家可能很難接觸Fiber Storage，筆者這篇文章利用iSCSI target server提供share storage，並在VMware的環境下測試，所以讀者不需昂貴的設備就可練習High Availability MySQL on RHCS 5.1的建置。
表1 iSCSI環境規劃表



讀者可參考之前「RHEL 5上的iSCSI環境」，並根據表1建置所需的Share Storage，設定完成後，不管在那一個node應該都可以Share Disk /dev/sdb及/dev/sdc，並用fdisk切割/dev/sdb, 然後再格式化，此塊空間未來是要用來存放MySQL的資料庫。










圖4 檢查node1上的iSCSI Share Storage。

(待續)