群集的规划(Cluster)

原创 2016年11月28日 10:37:29

群集的规划(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构架机能是否能够顶的住这样的意外发生。
这里写图片描述

版权声明:本文为博主原创文章,未经博主允许不得转载。

相关文章推荐

【bzoj1801】【AHOI2009】【chess中国象棋】【组合数学】

Description 在N行M列的棋盘上,放若干个炮可以是0个,使得没有任何一个炮可以攻击另一个炮。 请问有多少种放置方法,中国像棋中炮的行走方式大家应该很清楚吧. Input 一行包含两个整数...

windows2003下群集cluster详细配置过程

  • 2015年01月29日 16:23
  • 3.23MB
  • 下载

配置mongodb分片群集(sharding cluster)

来源:http://www.taobaodba.com/html/525_525.html Sharding cluster介绍 这是一种可以水平扩展的模式,在数据量很大时特给力,...
  • laiahu
  • laiahu
  • 2012年06月27日 16:37
  • 550

配置mongodb分片群集(sharding cluster)-淘宝DBA

Sharding cluster介绍这是一种可以水平扩展的模式,在数据量很大时特给力,实际大规模应用一般会采用这种架构去构建monodb系统。 要构建一个 MongoDB Sharding Clust...

配置mongodb分片群集(sharding cluster) for linux

Sharding cluster介绍 这是一种可以水平扩展的模式,在数据量很大时特给力,实际大规模应用一般会采用这种架构去构建monodb系统。 要构建一个 MongoDB Sharding Cl...

MySQL Cluster 与 MongoDB 复制群集分片设计及原理

来源:mysqlops 分布式数据库计算涉及到分布式事务、数据分布、数据收敛计算等等要求 分布式数据库能实现高安全、高性能、高可用等特征,当然也带来了高成本(固定成本及运营成本),我们通过...
  • boluobn
  • boluobn
  • 2013年04月26日 22:32
  • 483

Linux下Mongodb的分布式分片群集(sharding cluster)配置

这篇文章我是从淘宝上转载过来的, 但是经过了一些的修改: 基本上相同 http://www.taobaodba.com/html/525_525.html Shardingcluster介...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:群集的规划(Cluster)
举报原因:
原因补充:

(最多只允许输入30个字)