叢集-Cluster

分散式已是目前的主流架構,當今雲端充斥著許多的平台,在不同的平台上提供著不同的資源,每種資源大都是以分散式的節點組合起來的,若沒有不同的叢集(Cluster- Aware)架構來組織這些資源,那這朵雲會是個什麼樣的混亂,大家可想而知。

•    叢集的规划Cluster

•    叢集Cluster类型的介绍 

      •    叢集存儲Storage

      •    如下圖顯示

      •    高可用High Availability

      •    负载平衡Load Balancing

      •    高效能High Performance

•    RPO備份 RTO備援

     •    RPO 复原时间点目标Recovery Point Object

     •    RTO 复原时间目标Recovery Time Object

•    HA 的模式 no-fencefenceo   

      •    軟件式 None-Fence MODE

      •    硬件式 Fence MODE 虛擬模式物理模式

      •    我們來看一下 Fence-agents 的種類

•    CrashRebootFence 的差異

       •   崩溃Crasho    

       •   重新開機Rebooto  

       •   防护Fence

•    HA 基本架構說明

•    以 JIRA 為範例規劃 HA

      •    高可用性備援區定義

      •    Resource 的規劃

      •    JIRA 的資源清單整理如下

      •    單一節點設置

      •    JIRA 的HA規劃流程

•    完整且嚴苛的測試o   

      •    手動切換

      •    自動切換

  1. 叢集(Cluster)類型的介紹叢集架構主要是運行在兩台以上的計算機(或稱為節點/成員)集合,它們協同在一起完成工作,主要分為四個類型。

  2. 叢集存儲(Storage)這是多節點針對單一存儲的構架,這類的叢集關係,關鍵的不同在於存儲端架構上的組合,也就是以存儲端往客戶端的節點來看,是1對多的關係,且引用的文件系統是叢集文件系統(Cluster-Aware Fiile System),如紅帽的GFS2。

  3. 如下圖顯示叢集文件系統 (Cluster-Aware FileSystem) GFS2 稱得上是是叢集存儲需要同時俱備兩個條件: 1. 前端節點為多活。 2. 後端存儲的文件系統為叢集文件系統(Cluster-Aware File System)如紅帽 HA+GFS2,賽門鐵克 VCS+VxCFS。

  4. 高可用(High Availability)一般指的是單活,也就是主備模式,這是主要的特徵,若只有強調高可用,會跟負載均衡混淆,因為負載均衡也有高可用的機制,但因為多活,所以延伸的存儲技術引用,需要考慮到並發讀寫及效能的問題。

  5. 負載平衡(Load Balancing)這裡指的是多活,在應用程序的負載過量時可以考慮的解決方案,雖說是橫向擴展(Scale Out),但因為跨節點之間仍有溝通的成本,所以也不是可以無限制的擴展,有幸當下因為有成熟的Docker技術,可以在單一節點的構架下作橫向擴展,所以依單一節點的規格來容器化,平均劃分多個節點,可以比原有跨節點的擴展要更俱備規模。

  6. 高效能(High Performance)所有節點並發運行就是高效能集群的表現,分佈式架構通常就是。但大都普遍在存儲的應用部份,如分佈式文件系統 DFS(Distribution File System),至於並發計算部份的應用通常在學術及科學的研究上。

  7. RPO備份 / RTO備援備份是災難復原DR(Disaster Recover)規劃中的重要部份,我們當然希望備而不用,但不能不備份。在生產環境中份備工作執行的再完整,都還是要有備援的規劃,比如高可用構架HA(Hight Available)。

  8. 我們以下面這張圖來描述一下這兩個部份: RPO 復原時間點目標(Recovery Point Object)備份的工作通常在離峰時段來進行,以增量的方式每日備份,持續保留歷史痕跡,至於還原點若縮小到日以下的間隔,比如時分秒甚至到熱備,那就不一定要在離峰來進行,但需要考慮負載的開銷尤其是不能影響到生產環境的運作。

  9. RTO 復原時間目標(Recovery Time Object)在災難發生時,首當其要考慮的第一件事情就是,災難是否可以排除,比如單一主機硬件故障(高可用方案HA)或是電力來源中斷(切換不同迴路,或是發電機持續供電),甚而天災是否有異地備援。待災難環境排除後的數據還原時間需要多久。這整個一路下來所需要花費的時間決定著整個災難復原的能力。

  10. HA 的模式(no-fence/fence)fence是個非常不錯的構架守護者,在關鍵部件發生不正常時,立馬就協助應用程序切換到另一個迴路繼續工作,是個非常可靠的解決方案,但因為實施的成本較高,各大廠也有非fence方式的其他選擇,比如Oracle_RAC/Mysql_Cluster/VMware_HA/Docker_Swarm ..等等。但是軟件式的HA也就是no-fence,有較不穩定的使用經驗,在實務上常常因為軟件式HA 架構上的卡死,造成服務終斷無法恢復,也就失去了當初建置高可用的價值。 fence 的機制緊密的把HA(高可用)的成員跟硬件或是虛擬構架結合在一起,讓構架的任何一個模塊如果故障,可以馬上切換到另一個迴路,讓工作繼續進行。 • RHCS (RedHat Cluster Site)• Pacemake/Corosync(High Availiable Add On)

  11. 軟件式(None-Fence MODE)有些軟件大廠,不依賴操作系統大廠即有的HA構架解決方案,自行完成一些高可用的解決方案來增加他們自家產品的價值,尤其是數據庫供應商便是如此,數據庫自家提供的HA構架方案雖然不需要依附特定的操作系統,但HA的運行多少要透過操作系統來獲取資源,因此單方面是很難完全掌握運行的可靠度。虛擬構架產品供應商VMware也有HA的解決方案也許會較可靠,但是切換的效率還是沒有操作系統供應商來得好,以下列舉三項軟件式HA的產品 。 - Oracle RAC - Mysql Cluster - VMware HA

  12. 硬件式 (Fence MODE) 虛擬模式/物理模式我們以Pacemaker的一張堆棧圖型來了解一下,關於群集的一個基>礎框架。最上層是依附的一些集群式文件系統技術,這一部份可以讓應用程序省去一些有關協同運作的鎖定管理工作(Cluster Lock Manager),中間層就是有關資源管理(Resource Manager)的Pacemaker,從舊版本到目前為,除了底層的低階構架有多出了個CoroSync以外,上層除了性能及管控的資源優化外,框架都沒有太大的改變。我們再來看看Pacemaker內部的模塊組合。我們注意看綠色部份,這一組是Linux-HA發起的項目,也是目前生產環境中HA主要的應用框架,未來在雲端上建置跨節點的HA構架,不建議再用綠色部份這一系列的方式佈署,有佈署過人員清楚,這一系列有著太多網絡上的限制,比如組播/單播(multicasting/unicasting)的管制,很多不管是公有云或是私有云基於安全的考察都是關閉著的,今後CoroSync應該是Hearbeat任務擔任的主流項目,往後應該會朝著這個主要的方向前進。在我們了解硬件式的群集構架之前,我們需要先了解fence這個機制,才可以更透徹的清楚到何謂虛擬模式跟物理模式的分別。我們先來看看fence到底擔任著一個什麼樣的任務,圖標中顯示集群中有一個節點的網絡卡發生故障,這時fence機制會發生作用,集群構架的機制會把有網絡問題的節點屏蔽掉,讓正常運行的節點接手,這是有關網絡的硬件部份,我們再看下一張電源模塊故障的部份。如下是另一個情境,也是硬件故障問題,不同的是發生在電源供應器停止供電的情況下,一般如果在沒有fence機制的HA集群,常常就這麼卡住死鎖而不作切換。又是網絡卡又是電源供應器,有沒有一個單一的fence幫忙監控所有部件的健康狀況來幫忙決定是否屏蔽掉有問題的節點。有的! IPMI是一個溝通的標準協定(由Intel提出的標準),運行在各大廠的主機母板內部(HP的iLO IBM的iMM),如此一來,在主機上所有相依附的部件,只要有健康上的問題就會被屏蔽掉,盡快的讓另一個正常的節點接手。

  13. 我們來看一下Fence-agents 的種類:San/Storage-base(non-power based)• fence_scsi(meta provides=unfencing)Power based fencing agents• fence_apc• fence_ilo• fence_imm• fence_ipmilan(針對虛擬架構的fence 沒有直接跟帶電的部件接觸) Virtualization fencing agents• fence_virsh• fence_rhevm• fence_xvm• fence_vmware_soap_

  14. Crash/Reboot/Fence 的差異在高可用構架下發生節點崩潰,然後另一個節點自動接手之後有個重要的分析工作,就是崩潰的主機到底發生什麼事?經過了fence機制有問題的主機可能也恢復正常了,有什麼樣的方式可以盤查是什麼主要因素造成這台主機的重啟,主機有著各種重開機的行為,我們有需要好好的認識這些行之間有什麼不同:

  15. 崩潰(Crash)通常發生原因是在內存部份,硬件方面有可能是內存或是硬盤的壞軌造成,軟件方面通常是發生在驅動程序(Driver)的bug也有可能是病毒軟件造成。以下為紅帽/微軟操作系統Crash 的截圖畫面:

  16. 重新開機(Reboot)Reboot 包括兩個動作,一是關機(shutdown)二是(startup),全程所有的服務都是正常停用跟啟用,如下截圖(左邊關機右邊啟動) :

  17. 防護(Fence)Fence其實就透過Fence裝置,以電源信號執行強制性的關機或是重開,但這個行為跟前面說的Reboot重開機有很打的差異,最大的不同處是沒有開機跟關機的動作(shutdown/startup),直接就像是在主機面板上按reset鍵,這個動作很粗暴,任務也很單純,就是希望另一個節點盡快接手。

  18. HA 基本架構說明如下圖標示例,中間單座HA的兩台虛擬機都是正常運作著。我們比對左右兩座 HA,個別停用不同的 AP/DB 應用平台,之後再分別開啟左右兩座 HA 的 AP/DB,都會是正常的。

  19. 以JIRA 為範例規劃HA高可用性備援區定義在高可用的集群裡面可化分不同的備援區域,備援區主要是對節點完成高可用機制,但有些節點本身硬件規格針對特定的資源有優化,比如ip-san之類的光線存儲,如此的規格不是每個節點適合擔任,也因為這樣在同一個區域的節點共享高規格資源的需求是存在的,備援區也就是在定義這個部份。備援區定義區示意圖如下: Resource 的規劃JIRA 的資源清單整理如下:• 虛擬IP (Virtual IP)• JIRA-Application (Service)• HAproxy (Service)• File-System (btrfs,xfs….)• DRBD (Service)• PostgreSQL (Service)當決定是以什麼樣的群集模式來運行,那麼框架內要加入什麼樣的資源就大概有個譜了,清查好後開始分別建立然後再整合。

  20. 單一節點設置再開始建置時加入框架內的主要資源就是IP,當虛擬IP在建置完成後確認可以跨節點之間漂移IP,那麼高可用構架的基礎就算成型,這時再把其他資源一一加入,切記!加一個資源就要進行檢測,不要等全部資源加入後再檢測,會增加問題分析的複雜度。

  21. JIRA 的HA規劃流程以下是以JIRA應用程序構架成HA高可用構架為示例,來說明進行前該有什麼樣的考察跟規劃。

  22. 完整且嚴苛的測試建構群集構架是個複雜的工序,每個步驟再往下進行之前,一定要確認當下完成的階段是否可靠再往下一步進行,先完成手動測試然後再行自動切換測試,完整且嚴苛的測試是必須的。

  23. 手動切換HA的構架不是只設計給意外發生時使用的,在平日運維的工作中反而很依賴手動切換,比如進行一些數據庫的維護,或是軟件更新補丁修正,甚至硬件更新及維護也是會利用到手動的切換。

  24. 自動切換自動切換測試,其實就算是災難演練了,測試過程要真實的把電源切斷,或是網路線拔除,製造一個災難發生的情境來考驗當下的HA構架機能是否能夠頂的住這樣的意外發生。