RHEL High-Availability Solution 由於網際網絡及電子商務的盛行改變了企業Business Model，現在企業的顧客巳不是局限在Local 的客戶。全世界都有可能是您的客戶，加上人們生活型態改變，所以全年365 天24 小時隨時都可能有商機產生。 當信息系統發生無可預期的停機事件時，除了企業損失生產力、客戶與收入。還可能遭遇到進一步受罰、訴訟、聲譽不良的影響。此外，擁有一個永不打烊( High Availability )的運作模式，更是一個不容忽視的競爭優勢和服務關鍵。所以現在許多企業除了要求伺服系統能在上班時間提供可靠與連續運轉的服務，更希望能對客戶提供24 X 7 全年無休的服務。
簡介 在商業的 Unix 市場中，高可用性 ( High Availability ) 是銷售Unix 服務器解決方案的關鍵。事實上每個 Unix 供貨商都有他們自己的高可用性軟件解決方案，例如IBM 的高可用性叢集軟件解決方案，就是 AIX 上的HACMP ( High Availability Cluster Multi-Processing ） 。其它主要的 Unix 供貨商像 HP，Sun，DEC 和其它的供貨商有許多類似的軟件解決方案可用。 High Availability 是現今銷售Unix 給許多企業的關鍵。特別對於需要web-based 和其它必須一整年，每周七天，每天 24 小時可用的服務器。至於新竄起的網格運算市場而言更是如此。但是在Linux 一直沒有很成熟的HA 解決方案，即便是RedHat 在Advanced Server 2.1 上提出的HA 解決方案和其他的Unix 廠商的HA 解決方案也有一段不小的差距。 不過，隨著RedHat Enterprise 3.0 的推出，Red Hat 在其上推出一個重量級企業應用軟件「RedHat Cluster Suite」，使得情況有所改觀。Cluster Suite 包含兩個技術：Cluster Manager 和 Linux Virtual Server。Cluster Manager 是HA 的最佳解決方案，只要兩台服務器和共享的外接儲存設備，透過Cluster Manager 來控制服務器所執行的服務，就可輕松達成HA 的目的。不過Red Hat Cluster Suite 不包含在RHEL 3.0 中，它必須額外購買。而且只支持 RHEL AS 和 ES 版。(圖1) 點擊查看大圖 圖1：RedHat 產品架構圖 筆者一直認為Linux 要成為企業重要關鍵的服務器，甚至取代高階Unix 的服務器，穩定可靠的HA 的解決方案是不可或缺的。但 RedHat 一直沒有推出筆者認為足以媲美 AIX HACMP 的產品。總算隨著RedHat Enterprise 3.0 的上市，也推出了Red Hat Cluster Suite。它比之前AS 2.1 穩定性更高，而且也較容易設定。本篇文章先為讀者介紹 Cluster、HA 等相關技術及觀念，下一篇文章筆者將利用RedHat Cluster Suite 實作HA 解決方案。
Clustering 分類 筆者有時遇到客戶或學生詢問Cluster 叢集系統及High Availability 相關問題，總覺得Cluster、HA、High performance 這幾個名詞常讓人混洧。就筆者的看法，「所謂Cluster 就是由一台以上的機器為了某種特定需求所組成的架構」，根據不同的需求我們可將Cluster 分為以下三種，並對應RedHat 由何種軟件提供相關功能。 High availability clusters 增加服務器和以網絡為基礎的應用程序的高可用性及備援性。由 Cluster Suite 中的Cluster Manager 技術提供 Load Balancing clusters 將服務需求分派給多台服務器，可視系統負載隨時彈性增加服務器由 Cluster Suite 中的 Linux Virtual Server (Piranha) 技術提供 High performance clusters (HPC) 提供同步運算及平行處理的能力 Cluster Suite 不提供 (另外有 lam、pvm 套件，規劃由WS 擔綱) 本篇文章最主要介紹有關「High availability cluster」相關技術，其它兩種 Cluster 不在此次探討范圍內。RedHat Cluster Manager 是以 open source Kimberlite cluster project 為基礎來發展而來，讀者可參考下列網址得到相關的信息http://oss.missioncriticallinux.com/kimberlite/。 一個完善的HA 解決方案必須具備下列特性： Reliability (可靠性) Availability (可用性) Scalability (擴充性)
High availability clusters 功能 HA Cluster 通常必須提供下列功能： 具備Hardware redundancy for fault tolerance 功能 「Redundancy」筆者看到有些文章譯成「冗余、冗、過多、多余、贅..」真的是很怪，其實Redundancy 的意義就是「備援」。至於fault tolerance 是指「容錯」，所謂「容錯」代表當系統能夠響應非預期性的故障時，可在容許狀況及范圍之下仍然可以繼續運作，無須做任何的的切換或轉移。在HA Cluser 中「Hardware redundancy for fault tolerance」相關解決方法可參考表１。 表1：HA Hardware redundancy for fault tolerance 解決方法 「SPOF」 ( Single Points Of Failure ) HA 的基本准則是硬件都必需使用具有Redundancy 的硬設備，例如RAID、Dual Power。最主要原因是為了避免造成「SPOF」 ( Single Points Of Failure ) 的情形發生。什麼是「SPOF」? 所謂「SPOF」是指當某個零件故障會造成整個系統無法正當運作，那麼這個零件就是整個系統中的Single Points Of Failure。 例如在 Client/Server 環境中，一個服務器系統中的單一網絡卡即為這個服務器的 SPOF。同樣的，連接到外部儲存系統的單一 SCSI 配接卡是 SPOF。 如果一群服務器中的一整個服務器故障，並且這個故障的服務器不能被輕易且快速的由其它服務器置換，那麼對這個服務器群組或叢集而言，這個服務器就是一個 SPOF 。 這個解決方法十分簡單：配接卡只要借著在一個服務器中設置兩張卡，並確認主要配接卡失效時備援配接卡會成為 active ，就可以達成備援( redundancy )。 提供 “failover”機制 如果一台服務器停機或故障, 另一台服務器可以接手( takeover )激活應用程序 以及以下情況發生時仍可以讓應用程序正常運作 硬件故障 系統維護及升級 一個典型的High availability clusters 的架構應如圖2，這兩台服務器彼此如何溝通，還有常見Share Disk Storage 又有那些?接下來筆者便為各位介紹這些相關技術。 圖2：High availability clusters 架構圖
High availability clusters 中的通訊機制 Clusters 內部的通訊機制來確保資料的完整性以及當發生Cluster 成員故障情況時能及正修正Cluster 的行為，Cluster 使用這些機制來做以下的事情： 控制系統何時能成為一部Cluster 成員 決定Cluster 系統的狀態 當問題發生時，控制Cluster 的行為 RedHat HA Cluster 相關通訊機制如下： Ethernet 的 heartbeats 「heartbeats」這個名詞在各家HA 解決方案中可都是少不了他的身影，「heartbeats」是「心跳」的意義，筆者覺得老外用這個字真的是非常貼切，所 謂「heartbeats」的機制就是用來檢查另一台服務器是否仍正常運作的機制。是不是很像人類利用有無心跳來判斷一個人是否還活著。 Cluster 成員之間是由點對點的Ethernet 網絡線來聯機的，每一部成員將會定期地向這些網絡線發出 heartbeats ( ping ) 訊號，Linux-HA 使用這個信息來幫助找出成員的狀態，並且確保正確地Linux-HA 操作。 共享的(quorum)分割區 在 Linux-HA 中每一部服務器將會定期地寫入一個時間戳記( time-stamp )與系統狀態到 primary 與 shadow 的共享分割區，也就是位於Share Disk Storage中的某塊空間 ( raw partition ) 。 每一部成員將讀取由其它成員所寫入的系統狀態與時間戳記( time-stamp )，以找出它們 的狀態是否更新。 成員將會試著從 primary 共享分割區讀取信息。 假如該分割區已毀損，成員將會從 shadow共享分割區讀取信息，並且同時修復 primary 分割區。 將透過錯誤檢查(checksums) 維護資料一致性， 而且分割區間的任何不一致性都會自動地修正。 遠程的電源開關監視 Cluster 中的成員將會定期地監視遠程電源開關（假如有的話）聯機的使用狀況，成員使用這個信息來幫助找出 其它Cluster 成員的狀態，電源開關通訊機制的完全失效並不會自動導致failover，假如電源開關無法 power-cycle 一部當機的系統，將不會執行任何的failover，因為Cluster 的基礎架構無法保證成員目前的狀態。 假如一部成員發現來自另一成員的時間戳記( time-stamp )並沒有實時更新，它將會檢查 heartbeat 的狀態，假如向其它成員發出 heartbeat 訊號的動作仍在執行中，Cluster 管理程序將不會采取任何動作。 假如一部成員在一段時間後都沒有更新它的時間戳記( time-stamp )，而且也不響應 heartbeat pings 的訊號，該部成員將被認定已停止運作。 只要有一部服務器可以寫入共享的分割區，實時所有其它的通訊機制都失效了，叢集仍將維持運作的狀態。 請注意，在某些兩部成員的設定中，共享的分割區只被用來當作一個備援，網絡成員的算法是對Cluster 成員 是否正在使用中的主要決定因素。 在這個設定中，不更新時間戳記( time-stamp )的一部成員絕不會failover 的發生， 除非clumembd 回報該成員已停止運作。
Share Disk Storage 常見的Share Disk Storage 技術有下列三種：SCSI、SSA、Fibre SCSI ( Setting Up a Single-initiator SCSI Bus ) 如果您的Share Disk Storage 要采用SCSI 的裝置，必須選擇有支持多主機通道（Multi-Host），其常見的架構如圖3。兩個 single-initiator 的 SCSI 總線在一個單一控制卡 RAID 數組的阻絕器，一個 Single-initiator SCSI 總線只允許一個成員連接到它，並且提供主機的分離與比一個 multi-initiator 總線更佳的效能表現。 Single-initiator 的總線確保每 一個成員都能免於由於其它成員的系統負載初始或修復所引起的干擾。 圖3：連接到 single-initiator 的 SCSI 總線的單一控制卡 RAID 數組示意圖 SSA ( Serial Storage Architecture ) 串行式儲存架構（ SSA ）是由 X3 授權標准委員會的 X3T10 技術委員會中的 X3T10.1 工作群組所正在發展的高效能串行式計算機與外圍接口。最初由 IBM發展， 現今 SSA 是由 SSA 工業協會 推廣的開放技術。 SSA 基本上是一個執行於 SCSI-2 軟件協議的串行式技術。意思是 SSA 配接卡的裝置驅動程序應該可以很容易地整合到現有的 Linux SCSI 子系統。底線是，資料是透過以 200 MBit/s 全雙工傳輸的雙絞電纜來傳送，而這比 68 Pin的平行 Wide SCSI 技術更易於處理。 SSA 和 SCSI 相較之下，有下列優點： 1)它更易於設定和接線 ( 它不需要終端電阻)。 2)它內建了 HA 特征。SSA Loop 架構（相對於SCSI 總線）沒有 SPOF（參考圖4）。如果部份的Loop 失效，裝置驅動程序將自動並透明地重新自我設定以確保所有的 SSA 裝置可被存取而沒有任何明顯的中斷。 3)它不是使用 SCSI ID 尋址，意指設定配接卡毫無困難。 4)相對於 SCSI ， SSA 沒有使用總線裁決。而是使用類似網絡的設計。資料以 128 字節的封包被送出和接收，而且循環上的所有裝置可以獨立的請求 time slots 。反過來 SCSI 需要總線裁決，如果 initiator 沒有及時釋放總線可能導致效能死結。 5)SSA 允許每兩個裝置間相距 25 公尺。再者，有允許資料穿過 50 微米的光纖電纜傳送達 2.4 公裡的距離的光纖延伸器。如果設定適當的話，會使得它甚至合適於站台災難回復。 6)大部分的 SSA 配接卡支持兩個獨立的循環，使得連結鏡射的磁盤到不同循環以提高可用性成為可能。 7)SSA 循環是對稱的，雙絞線，自由電位的。沒有 TERMPWR 電位移的問題。 點擊查看大圖 圖4： SSA 示意圖 SSA 是一個比SCSI 優良的技術，不過很可惜地，SSA 磁盤只能從 IBM 購買，取得成本太高，這些磁盤價格遠高一般的 SCSI 磁盤價格。而且至今在Linux上仍沒有夠成熟的SSA Driver。 Fibre Channel Interconnect Fibre 是筆者最喜歡的解決方案，也是筆者認為是比較有擴展性且適合大型企業的架構。較簡單經濟的架構便如圖5 所示，兩個主機連接端口的一個單一控制卡RAID 數組，沒有使用Fibre Hub 或Switch，主機連接端口配接卡直接聯機至 RAID控制卡。當您使用這種類型的 single-initiator 光纖信道聯機，您的RAID 控制器必須擁有分開的主機連接端口給每一部Cluster 成員。 圖5：連接到 single-initiator 的 SCSI 總線的單一控制卡 RAID 數組示意圖 IP Address Takeover 最後筆者要介紹IP Address Takeover 技術，通常客戶端機器和應用程序無法在運作時，從幾個 IP Address 中選擇一個IP Address 來存取服務器。所以主要的服務器無法提供服務時，接管的節點必須在重新激活應用程序之前取原來提供服務的IP (well-known IP Address )。這個程序稱之為 IP Address Takeover（ IPAT ）。它的基本運作原理如下： HA Clusters 的成員在有兩個網絡接口，一個是Service IP Interface、一個是Standby IP Interface。如果它是具有較高優先權的節點或是主要節點 ( Primary Node )，一旦這個節點取得資源群組，Service IP Interface 將會變成這個對外提供的服務IP Address。 例如在Linux HA 激活前，Primary Node 與 Secondary Node 上的IP Address配置如下表： 表2：Linux HA 激活前的IP 配置表 表2 是Linux-HA 被激活之前的情形。 兩個服務接口都位於它們個別配置的啟動地址上。備援接口位於它們的備援地址上。假設整個Clusters 對外服務的IPAddress ( 也就是Client 連至Clusters 的IP address )為”192.168.10.11”。當Linux-HA 被激活於兩個節點時，由於Node 1 是主要節點，它將取得對外服務地址。 表3：Linux HA 激活後的IP 配置表 假設主要節點的服務( Service ) 網卡故障，則備援( Standby )配接卡將接管服務地址 ( 192.168.10.11 )，如表4。 表4：主要節點的服務網卡故障後的IP 配置表 假設主要節點Node 1 故障，Node 2 將取得包括於資源群組中的服務地址，如表5。 由以上這個簡單的例子中，我們也可以移動192.168.10.11 到節點2 的服務配接卡，但是移動到備援配接卡較為適合。 首先，備援配接卡就不再需要了，也就是Node 2 的備援配接卡也有Client 連線，並提服務，而不是聞置在那兒做備援。 其次，節點 2 也可能正在執行一個資源群組（相互接管）。如果服務 IP Address總是移動到存活節點的相同的（即備援）配接卡，那麼移動”對外服務IP Address”的邏輯就得較為簡單。 讀者看到HA 利用四張網卡來提供一個對外服務的IP，一定會覺得麻煩又眼花瞭亂。雖然我們也可以每個節點只使用一張配接卡於。但是有兩個原因不建議這樣做。 首先，如果一個節點的配接卡失效，無法判斷是只有配接卡或整個實體網絡失效。 其次，如果我們加入邏輯來判斷是否是配接卡或是網絡失效，我們可能必須立即執行節點的failover，而這要花費比本地端配接卡failover 還要更長的時間。
後記 筆者一直希望RedHat 能推出一套可靠好用Linux HA 解決方案，看到Cluster Suit 的推出真是令人雀躍。這期文章筆者先介紹HA 解決方案中常見的技術及觀念，下期我們再來卷起袖管打造全年無休的RedHat High Availability Cluster。
