RH436 (Red Hat High Availability Clustering) 課程 Part1

什麼是cluster叢集?

一個叢集就是多個電腦彼此工作於一個工作。

 

High-availability clusters高可用叢集:又被稱作HA Cluster或failover Cluster，叢集盡可能保持服務一直運作，主要達成的動作就是有高可用的叢集會去監控其他的節點是否失敗，如果失敗並轉移服務到其他被認為健康的節點，高可用叢集可以被歸為下列兩個群組(見Pacemaker):

Active-active high-availability clusters主動-主動 高可用叢集:服務運作在多個節點，因此可以縮短容錯移轉的時間。

Active-passive high-availability clusters主動-被動 高可用叢集:服務在同時間只運作在單一節點。

在企業中高可用叢集總是使用在非常重要且必須的服務。

Storage Clusters儲存叢集:在儲存叢集中，所有的成員提供一個單一的檔案系統其可以被不同系統的伺服器存取，其提供的檔案系統可以被同時間讀取寫入資料，這非常有用於高可用的application data應用資料，像是網頁的內容，並不需要將同個資訊multiple redundant copies多重冗餘的複製。在Red hat Resilient Storage Add-on 中提供GFS2 叢集檔案系統。

高可用叢集要有什麼目標?

高可用叢集最主要的目標是當單點故障並排除瓶頸使保持服務盡可能的可用，有很多不同的策略可以達到單一機器盡可能長時間的運作，但是這並不是重要的，主要是探討上面跑的服務如何達到高可用。

Resources and resource groups資源和資源群組

在叢集的術語中，最基本的運作單元叫做資源，像是一個IP位址、一個檔案系統、一個資料庫等等均被認為是一個資源。通常這些服務因其相關聯性而被定義為一個使用者面向的服務。最常用的方式就是把這些一連串的服務結合成一個群組，更詳細的說就是在群組中的所有資源彼此都會跑在同一台節點上並建立一個固定(線性)的開始和結束順序。舉個例子，為了建立一個提供網頁服務的叢集，其網頁的程序、資料、IP都會在同一個高可用的節點上監聽。

Failover容錯移轉

高可用叢集嘗試保持服務可用，當叢集偵測到原本的執行的服務無回應時，移轉資源到其他節點。

Fencing隔離

隔離是一種機制確保一個故障的叢集結點不會造成錯誤，所以其資源可以被安全的回復到其他節點。這是必要的因為我們不能確保一個無法回應的節點是被確實的關掉。隔離是藉由關閉故障的節點完成，因為如此一來這個死亡的節點就會沒有資源並無法做任何事情，另外的方式是斷開其連結，像是使網路無法到達會是資料無法寫入儲存裝置中。

Share Storage共享儲存

很多高可用叢集形式需要共享儲存，就是此儲存可以被多個節點存取，共享儲存提供相同的應用資料到多節點叢集中，這些資料可能被連續、同時地被一個叢集上的應用程式存取。一個高可用的叢集必續確保資料健全的存在共享儲存，資料的健全性可以用隔離性來確保。

Quorum仲裁

仲裁描述一個投票系統可以保持叢集系統的健全，每個叢集成員都會被分派一些票數，預設是一票。根據叢集的設定，叢集仲裁的實現是藉由不是得到一半的票數就是超過一半的票數。叢集成員故障無法與其他成員通訊而且不能送出他們的得票，因為他們如預期被隔離了。一個普通的叢集需要仲裁去操作，如果叢集遺失或未建立仲裁，預設上是不會有資源或資源群組被開啟運作，而是關閉，因為要確保資料的健全。

何時要使用高可用叢集?

當計劃一個高可用叢集，有一個很重要的問題:將要放哪個服務到高可用叢集而提高它的可用性?

這個問題的答案是重要的，可以知道哪些服務較相容而且如何去設定它。

某些服務像是DNS和LDAP就有內建容錯移轉和負載平衡並不適用於高可用。DNS和LDAP服務可以被使用在多個伺服器上利用master\slave或multimaster方式。這些服務在主伺服器和備伺服器之間都有被設定成資料複寫。對DNS和LDAP來說客戶端可以使用多個服務器，在master\slave或multimaster架構中不會有一些容錯移轉的延遲，所以高可用叢集不會增加其可用性。然而，在Openstack 平台將RabbitMQ和Galera放入高可用叢集中可能會有利的。另外，某些服務沒有內建容錯移轉或負載平衡是有利於放入高可用叢集，像是NFS和Samba。並不是所有的高可用問題都可以用高可用叢集解決，像是網路問題或是應用程式故障(這裡指的是應用程式的bug)等等。

硬體架構

軟體

Pacemaker 是什麼

1.Pacemaker 簡單說明

pacemaker(直譯：心臟起搏器)，是一個群集資源管理器。它實現最大可用性群集服務（亦稱資源管理）的節點和資源級故障檢測和恢復使用您的首選集群基礎設施（OpenAIS的或Heaerbeat）提供的消息和成員能力。 它可以做乎任何規模的集群，並配備了一個強大的依賴模型，使管理員能夠準確地表達群集資源之間的關係（包括順序和位置）。幾乎任何可以編寫腳本，可以管理作為心臟起搏器集群的一部分。Pacemaker是個資源管理器，不提供心跳資訊。

2.Pacemaker由來  (參考www.alteeve.com)

SA Forum和AIS: Service Availability Forum（SA Forum）服務可用性論壇是一個開放性論壇，它開發並發佈這些免費規範。使用AIS規範的應用程式介面（API），可以減少應用程式的複雜性和縮短應用程式的開發時間，這些規範的主要目的就是為了提高中間元件可攜性和應用程式的高可用性。SAF AIS是一個開放性工程，在不斷更新中。

OpenAIS: OpenAIS專案是實作  SA Forum的AIS(應用程式介面的規範) API，這些應用程序作为中間層為應用服務提供一種開放、高移植性的程續接口。在2008年Redhat和SUSE的開發者在布拉格開了一個會，並合作重新使用彼此的程式碼，Redhat開始注意到並有興趣於Pacemaker和OpenAIS。在此之前OpenAIS移除了一些不需要的主函式只保留HA叢集的部分並創建了一個新的專案叫做Corosync，第一版公開於2009年，Corosync是一個OpenAIS的選擇插件，實作於AIS API。

一直到Heartbeat2.1.3版本，CRM(HeartbeatV2的叢集資源管理器)和Heartbeat仍然有緊密的結合，並遵循Heartbeat發行的版本循環，一直到2007年，Heartbeat決定將CRM拆分出來，並叫做”Pacemaker”，對叢集成員之間的聯繫它延伸了支援原本的Heartbeat和OpenAIS，其套件含有Heartbeat的資源代理、fence代理和stonith程序，這些元件是獨立於Heartbeat，Quorun是其插件，並運作於OpenAIS之上。

Heartbeat 到了V3版本後，拆分為多個項目，其中pacemaker就是拆分出來的資源管理器。

• Heartbeat 3.0拆分之後的組成部分：
• Heartbeat：將原來的消息通信層獨立為heartbeat專案，新的heartbeat只負責維護集群各節點的資訊以及它們之前通信；
• Cluster Glue：相當於一個中間層，它用來將heartbeat和pacemaker關聯起來，主要包含2個部分，即為LRM和STONITH。
• Resource Agent：用來控制服務啟停，監控服務狀態的腳本集合，這些腳本將被LRM調用從而實現各種資源啟動、停止、監控等等。
• Pacemaker: 也就是Cluster Resource Manager （簡稱CRM），用來管理整個HA的控制中心，用戶端通過pacemaker來配置管理監控整個集群。

Red Hat Enterprise Linux 6.0 介紹了 Red Hat cluster services 版本 3. RHCS 變成了 RHEL 的選擇的訂閱叫做 “High-Availability Add-On”.它拆分  GFS2 變成另一個訂閱叫做 “Resilient Storage Add-On”。

在2010年Pacemaker放入cman裡，利用cman准許Pacemaker仲裁和管理叢集成員，Pacemaker因其彈性和易用的優勢慢慢變成最受歡迎的資源管理套件，並支援於眾多的Linux發行版本。Redhat原本的rgmanager儘管很穩定但是因其不夠彈性而漸漸少人使用。cman和rgmanaer將會隨著RHEL6將於2020年停止支援而中止。

在RHEL6.0 – 6.4版本 Pacemaker 還是預覽版本，在此之間開發者快速地對Pacemaker做開發，使其支援多個Redhat fence agent且Redhat resource agent以Heartbeat專案為基礎而得到一些優勢。在RHEL6.5版(Pacemaker 1.1.10)增加支援Redhat隔離機制和隔離順序。在RHEL7版本高可用叢集將會更為簡單，只基於Pacemaker和Corosync。

Redhat Cluster 各版本比較

                                                         Pacemaker Stack

3.Pacemaker主要元件

• Cluster Information Base (CIB): 這是使用XML格式顯示出叢集的資炫包含設定和所有成員的狀態。由Pacemaker選出一個叢集的節點作為designated controller (DC)，儲存叢集和資源的狀態、設定，並同步於叢集中所有活著的節點。
• Cluster Resource Management daemon (CRMd) 叢集資源管理守護程序: CRMd是協調和發出資源開始、停止等狀態的查詢到叢集上所有節點的LRMd。LRMd 從CRMd接收行動並傳遞到resouce agent資源代理。
• Local Resource Management daemon (LRMd)本地資源管理守護程序: LRMd 的責任就是監聽來自PEngine的指示。
• Policy Engine (PEngine or PE)政策引擎: PEngine使用CIB 檔案去決定叢集的狀態，當異常發生時重新計算最佳節點及資源如何到達。
• Shoot The Other Node In The Head(STONITHd)將其他節點一槍暴頭: Stonith提供隔離機制，當隔離發生時，基於CIB檔的設定做相應的操作，發送請求給隔離的設備。

4.Pacemaker的特點：

1. 主機和應用程式級別的故障檢測和恢復
2. 支援最大32個節點最小兩個節點
3. 幾乎支援任何冗餘配置
4. 同時支援多種集群配置模式
5. 可以撰寫script自訂義叢集資源
6. 支援應用啟動/關機順序
7. 支援必須在同一台機器上運行的應用程式
8. 支援多種模式的應用程式如主/從
9. 支援stonith 確保資料健全
10. 現在最主流的資源管理器，可script其管理工具，易於管理。

Corosync

Pacemaker 使用 Corosync的架構處理叢集個個節點的通信，Corosync 也是Pacemaker成員和仲裁資訊的源頭。

Pacemaker軟體元件架構圖

5.Pacemaker 叢集的類型

Active/Passive clusters主動/被動叢集

                                                 Active/Passive Redundancy

Active/Active clusters 主動主動叢集

                                                        N to N Redundancy

pcs指令

pcs 指令只在類redhat的發行版中，不支援ubuntu等其他的發行版，pcs指令提供一個命令提示的介面，讓我們可以去設定Pacemaker\Corosync叢集；pcsd提供了一個網頁介面的圖形化服務可以檢視、設定Pacemaker\Corosync。

防火牆

在私有網路上，確認以下Ports是開的。

• For TCP: Ports 2224, 3121, 21064
• For UDP: Ports 5405, 在某些情況下5404也有可能用到
• For DLM (if using the DLM lock manager with clvm/GFS2): Port 21064

SELinux 支援

設定為Enforcing模式是可以完全被支援的。