群集的规划(Cluster)

群集的规划(Cluster)

分布式已是目前的主流架构，当今云端充斥着许多的平台，在不同的平台上提供着不同的资源，每种资源大都是以分布式的节点组合起来的，若没有不同的集群（Cluster-Aware）构架来组织这些资源，那这朵云会是个什么样的混乱大家可想而知。

---

群集(Cluster)类型的介绍

集群架构主要是运行在两台以上的计算机（或称为节点/成员）集合，它们协同在一起完成工作，主要分为四个类型。

集群存儲(Storage)

这是多节点针对单一存储的构架，这类的群集关系，关键的不同在于存储端架构上的组合，也就是以存储端往客户端的节点来看，是1对多的关系，且引用的文件系統是集群文件系統(Cluster-Aware Fiile System)，如紅帽的 GFS2。

如下圖顯示

集群文件系统 (Cluster-Aware FileSystem) GFS2

稱得上是是集群存儲需要同時俱備兩個條件：
1. 前端節點為多活。
2. 後端存儲的文件系統為集群文件系統(Cluster-Aware File System)如紅帽 HA+GFS2，赛门铁克 VCS+VxCFS。

高可用(High Availability)

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

负载平衡(Load Balancing)

这里指的是多活，在应用程序的负载过量时可以考虑的解决方案，虽说是横向扩展（Scale Out），但因为跨节点之间仍有沟通的成本，所以也不是可以无限制的扩展，有幸当下因为有成熟的Docker技术，可以在单一节点的构架下作横向扩展，所以依单一节点的规格来容器化，平均划分多个节点，可以比原有跨节点的扩展要更俱备规模。

高效能(High Performance)

所有节点并发运行就是高效能集群的表现，分布式架构通常就是。但大都普遍在存储的应用部份，如分布式文件系统 DFS（Distribution File System），至于并发计算部份的应用通常在学术及科学的研究上。

RPO備份 / RTO備援

备份是灾难复原DR（Disaster Recover）规划中的重要部份，我们当然希望备而不用，但不能不备份。在生产环境中份备工作执行的再完整，都还是要有备援的规划，比如高可用构架HA（Hight Available）。

我們以下面這張圖來描述一下這兩個部份：

RPO 复原时间点目标(Recovery Point Object)

备份的工作通常在离峰时段来进行，以增量的方式每日备份，持续保留历史痕迹，至于还原点若缩小到日以下的間隔，比如时分秒甚至到熱備，那就不一定要在离峰来进行，但需要考虑负载的开销尤其是不能影响到生产环境的运作。

RTO 复原时间目标(Recovery Time Object)

在灾难发生时，首当其要考虑的第一件事情就是，灾难是否可以排除，比如单一主机硬件故障（高可用方案HA）或是电力来源中断（切换不同回路，或是发电机持续供电），甚而天灾是否有异地备援。待灾难环境排除后的数据还原时间需要多久。这整个一路下来所需要花费的时间决定着整个灾难复原的能力。

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)

軟件式 (None-Fence MODE)

有些软件大厂，不依赖操作系统大厂即有的HA构架解决方案，自行完成一些高可用的解决方案来增加他们自家产品的价值，尤其是数据库供应商便是如此，数据库自家提供的HA构架方案虽然不需要依附特定的操作系统，但HA的运行多少要透过操作系统来获取资源，因此单方面是很难完全掌握运行的可靠度。虚拟构架产品供应商VMware也有HA的解决方案也许会较可靠，但是切换的效率还是没有操作系统供应商来得好，以下列举三项软件式HA的产品 。
- Oracle RAC
- Mysql Cluster
- VMware HA

硬件式 (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），如此一来，在主机上所有相依附的部件，只要有健康上的问题就会被屏蔽掉，尽快的让另一个正常的节点接手。

我們來看一下 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

---

Crash/Reboot/Fence 的差異

在高可用构架下发生节点崩溃，然后另一个节点自动接手之后有个重要的分析工作，就是崩溃的主机到底发生什么事？经过了fence机制有问题的主机可能也恢复正常了，有什么样的方式可以盘查是什么主要因素造成这台主机的重启 ，主机有着各种重开机的行为，我们有需要好好的认识这些行之间有什么不同：

崩溃(Crash)

通常发生原因是在內存部份，硬件方面有可能是内存或是硬盘的坏轨造成，软件方面通常是发生在驱动程序（Driver）的bug也有可能是病毒软件造成。
以下为 紅帽/微软 操作系统 Crash 的截图画面:

重新開機(Reboot)

Reboot 包括两个动作，一是关机（shutdown）二是（startup），全程所有的服务都是正常停用跟启用，如下截图（左边关机右边启动） ：

防护(Fence)

Fence其实就透过Fence装置，以电源信号执行强制性的关机或是重开，但这个行为跟前面说的Reboot重开机有很打的差异，最大的不同处是没有开机跟关机的动作（shutdown/startup），直接就像是在主机面板上按reset键，这个动作很粗暴，任务也很单纯，就是希望另一个节点尽快接手。

HA 基本架構說明

如下图标示例，中间单座HA的两台虚拟机都是正常运作着。

我们比对左右两座 HA，个别停用不同的 AP/DB 应用平台，之后再分别开启左右两座 HA 的 AP/DB，都会是正常的。

以 JIRA 為範例規劃 HA

高可用性備援區定義

在高可用的集群里面可化分不同的备援区域，备援区主要是对节点完成高可用机制，但有些节点本身硬件规格针对特定的资源有优化，比如ip-san之类的光线存储，如此的规格不是每个节点适合担任，也因为这样在同一个区域的节点共享高规格资源的需求是存在的，备援区也就是在定义这个部份。

備援區定義區示意圖如下：

Resource 的規劃

JIRA 的資源清單整理如下：

• 虛擬IP (Virtual IP)
• JIRA-Application (Service)
• HAproxy (Service)
• File-System (btrfs,xfs….)
• DRBD (Service)
• PostgreSQL (Service)

当决定是以什么样的群集模式来运行，那么框架内要加入什么样的资源就大概有个谱了，清查好后开始分别建立然后再整合。

單一節點設置

再开始建置时加入框架内的主要资源就是IP，当虚拟IP在建置完成后确认可以跨节点之间漂移IP，那么高可用构架的基础就算成型，这时再把其他资源一一加入，切记！加一个资源就要进行检测，不要等全部资源加入后再检测，会增加问题分析的复杂度。

JIRA 的HA規劃流程

以下是以JIRA应用程序构架成HA高可用构架为示例，来说明进行前该有什么样的考察跟规划。

完整且嚴苛的測試

建构群集构架是个复杂的工序，每个步骤再往下进行之前，一定要确认当下完成的阶段是否可靠再往下一步进行，先完成手动测试然后再行自动切换测试，完整且严苛的测试是必须的。

手動切換

HA的构架不是只设计给意外发生时使用的，在平日运维的工作中反而很依赖手动切换，比如进行一些数据库的维护，或是软件更新补丁修正，甚至硬件更新及维护也是会利用到手动的切换。

自動切換

自动切换测试，其实就算是灾难演练了，测试过程要真实的把电源切断，或是网路线拔除，制造一个灾难发生的情境来考验当下的HA构架机能是否能够顶的住这样的意外发生。