1.什么是主机高可用

高可用性H.A.（High Availability）指的是通过尽量缩短因日常维护操作（计划）和突发的系统崩溃（非计划）所导致的停机时间，以提高系统和应用的可用性。它与被认为是不间断操作的容错技术有所不同。HA系统是目前企业防止核心计算机系统因故障停机的最有效手段。

随着IT信息系统的不断发展，数据在企业的应用越来越广，如何提高IT系统的高可用性成为建设稳健的计算机系统的首要任务之一。构成计算机网络系统的三大要素是：网络系统，服务器系统，存储系统。网络系统包括防火墙，路由器等网络设备，服务器系统主要指用户使用的各种服务器系统，存储系统，则是用户最主要的数据存储放的地点。
因此IT系统的高可用建设应包括网络设备高可用性，服务器设备高可用性，及存储设备的高可用性三个方面。

今天在这里我们主要来聊聊主机高可用解决方案，主机高可用主要使用的服务器集群软和高可用软件来实现。目前市场上主流的主机HA解决方案产品有：如IBM PowerHA，HP的SG，RedHAT的RHCS ，SUSE HA,ROSEHA，赛门铁克VCS，LanderCluster 等。

希望通过本篇小文可以让大家了解什么是主机HA，目前主流HA产品有哪些，主机HA应该有哪些核心组成，能够做到那些方面的高可用，在实施和维护方面有哪些经验和教训以及希望主机HA能够在那些方面加强和新需求等等。希望对这些知识点的梳理，让运维和管理人员在选择响应产品时可以有一个借鉴和参考，给大家尽一点微薄之力。

2.主机高可用主流解决方案

接触过基础平台的工作人员应该对主机高可用解决方案不陌生，因为主机的高可用解决方案主要是通过集群或者高可用软件来完成的。目前市场上常见的HA架构的软件有以下几种：

• 微软MSCS
• 虚拟化平台HA(如VMWARE)
• IBM的PowerHA
• 惠普的SG(Service Guard)
• 红帽的RHCS
• Novell的SUSE HA
• ROSE HA
• 赛门铁克VCS
• Landercluster
• Fujitsu PRIMECLUSTER
• F5
• ……

主机HA 软件有很多，有大厂商也有小公司，每个软件的都有相应的应用场景和局限性，目前还没有那款软件可以通吃所有的平台，这可能跟研发能力和成本以及后续的更新有很大关系。往往软件做的小巧灵活，稳定性高反而更加有市场，比如linux的lvs ，操作系统自带集成在，软件很小，效果非常的不错。

3.主机HA 能做什么

记得第一次接触PowerHA的时候，感觉这个软件应该具备很多功能，基本上你能想象的功能它应该都具备，可实际上不是这个样子的，它也是仅仅能检测几项故障类型：

1. 节点失效
2. 网卡失效
3. 网络失效
4. 应用异常

所以说它不是万能的，只是适合这几种类型的场景而已，对于应用监控配置，PowerHA 软件实施配置的时候很少，由于PowerHA在各版本软件对此支持的不是很好，有的时候正常，有时候就不是你想象的那个样子，所以很少有人去配置或配置的好，有很多因素，所以干脆不用。
我这里并不是说哪款HA软件不好，只是指出某款软件不太好的地方，主机HA软件是各有所长，希望主机HA软件做的及稳定又效率，让工作更加容易。

小技巧：
只用对的不用贵的(实施人员的水平基本上决了主机HA的架构的健壮性，选择有经验的实施人员有时候比选择软件本身更重要)。

以前第一次接触SUSE HA,然后就用PowerHA的工作方式去理解，因为都是HA软件工作的方式应该差不多，当时我问了实施人员一个问题(主备模式，没有网卡聚合)，如果主节点第一块网关故障了，服务IP如何切换? 工程师说：切换到另外一个主机上啊，很正常啊。

相比较而言，PowerHA在这一块还是做的不错的，如果服务ip在网卡1上，这时网卡1故障了，ip会切换到网卡2上，而不进行资源切换到备份节点，当然也可以通过网卡聚合，保证网卡1故障了，不切换资源，但是毕竟增加了投入。
这里我贴一个PowerHA 使用IP 地址切换方式（别名方式）

4.主机HA高可用定义和切换流程

高可用性 (High Available), 是通过系统的可靠性(reliability)和可维护性(maintainability)来度量的。通常用平均无故障时间(MTTF)来度量系统的可靠性,用平均维修时间（MTTR）来度量系统的可维护性。故：HA=MTTF/(MTTF+MTTR)*100%

具体HA衡量标准:

• 99% 一年宕机时间不超过4天
• 99.9% 一年宕机时间不超过10小时
• 99.99% 一年宕机时间不超过1小时
• 99.999% 一年宕机时间不超过6分钟

现在越来越多的业务系统要求更高或苛刻的业务连续性，首先在这里需要明确的一点，主机HA是不能解决所有所有的业务问题的，对于苛刻的业务系统，不要选择主机HA解决方案来支撑，据实际来讲主机HA软件都需要分钟级别的业务中断，配置不合理业务中断时间会更长，一个配置合理的主机HA解决方案，一般需要2-3分钟左右的业务切换时间。

举例：
主机HA+Oracle或者DB2，共享存储的场景，主备模式

切换流程：

1. 主节点异常(集群软件检测，耗时较短)
2. 主节点资源(ip,db,共享卷组)关闭（此过程中db资源关闭时间耗时较长，ip和共享卷组切换耗时较短）
3. 备节点资源(ip,db,共享卷组)开启（此过程中db资源启动时间耗时较长，ip和共享卷组切换耗时较短）
4. 主机ha软件检测同步，保证集群状态一致(此过程耗时较短)

所以一个HA切换的过程就是应用启停的过程，耗时均在分钟级别，如果一年来个1-2次，5个9 是很难保障的。所以对于苛刻的应用应该选择其他方式的高可用解决方案，如应用级别，db级别，多副本，容错，灾备等其他方案。
绝大多数的主机HA软件的切换都是以资源组为单位进行切换，资源组主要包括：
IP，application，共享存储

资源组的切换方式按照资源切换策略控制，主要有三种方式：

1. Online
2. FallOver
3. Fallback

具体的每个含义就不在此做详细的解释，有需要的直接度娘，下面在着这里主要描述一下以上三种策略下的具体资源切换流程，以PowerHA为例：
参考链接：
https://wenku.baidu.com/view/fae710f2f90f76c661371a36.html

场景1：

资源组：online on home node noly

其资源组切换模式：

场景2：

资源组：Online on First Available Node

其资源组切换模式：

场景3：

资源组：Online on ALL Available Nodes

其资源组切换模式：

以上三种场景和策略配置基本上包括了所有HA主机软件的工作模式，无外乎资源组启动的在哪些节点上，异常后资源组如何切换到其他节点上，待故障节点恢复后资源组是否可以回切已经如何回切的策略。
掌握了主机HA软件的切换模式以后基本上就了解了主机HA软件的工作切换流程，是否可以满足企业需求，那就看情况选择就好了。

5.HA经典三种工作方式

上面是典型的两节点PowerHA 拓扑结构示意图，经常使用主机HA的工作方式有以下三种：

（1）主从方式 （非对称方式）
工作原理：主机工作，备机处于监控准备状况；当主机宕机时，备机接管主机的一切工作，待主机恢复正常后，按使用者的设定以自动或手动方式将服务切换到主机上运行，数据的一致性通过共享存储系统解决。
（2）、双机双工方式（互备互援）
工作原理：两台主机同时运行各自的服务工作且相互监测情况，当任一台主机宕机时，另一台主机立即接管它的一切工作，保证工作实时，应用服务系统的关键数据存放在共享存储系统中。
（3）、集群工作方式（多服务器互备方式）
工作原理：多台主机一起工作，各自运行一个或几个服务，各为服务定义一个或多个备用主机，当某个主机故障时，运行在其上的服务就可以被其它主机接管。

参考链接：
http://7250365.blog.51cto.com/7240365/1408109

6.主机HA的核心组件和实现原理

我们还用上面这张图来说明一个两节点的主机HA环境物理组成有哪几部分

组件：

1. IP 网络（用于提供业务通讯p和心跳检测）
2. 主机(X86或者小型机，一般情况下有双网卡或更多网卡，光纤卡)
3. 共享存储（用途提供可切换的fs或共享fs，磁盘心跳，防止脑裂）
4. 总裁方式（有很多种，串口心跳，磁盘心跳，stonith管理网口直接poweroff等防脑裂）

由于是高可用方式，这些基本上都要求冗余，才保证在物理上达到高可用。

主机HA软件构成

1.信息层(Messaging)
也叫底层基础架构层,主要用于节点之间传递心跳信息，也称为心跳层。节点之间传递心跳信息可以通过广播，组播，单播等方式。
心跳信息：集群中每一台服务器都不停的将自己在线的信息通告给集群中的其他主机。
心跳信息的传递是基于套接字通信的，通过软件提供服务监听套接字，实现数据发送、请求。必须安装软件，并开启服务，这是实现高可用集群的基础。

2.成员层（Membership）
这层最重要的作用是通过Cluster Consensus Menbership Service（CCM)这种服务由Messaging层提供的信息，来产生一个完整的成员关系。
CCM 组件（Cluster Consensus Menbership Service）：作用，承上启下，监听底层接受的心跳信息，当监听不到心跳信息的时候就重新计算整个集群的票数和收敛状态信息，并将结果转递给上层，让上层做出决定采取怎样的措施。CCM 还能够生成一个各节点状态的拓扑结构概览图，以本节点做为视角，保证该节点在特殊情况下能够采取对应的动作。
Messaging & Membership一般由同一软件实现。

3.资源分配层(Resource Allocation)
也叫资源管理器层，真正实现集群服务的层。包含CRM(集群资源管理器,cluster Resource Manager），CIB（集群信息基库，Cluster Infonation Base）,PE（策略引擎，Policy Engine）,TE（实施引擎,Transition Engine）, LRM（Local Resource Manager，本地资源管理器）。

CRM组件：核心组件，实现资源的分配和管理。每个节点上的CRM都维护一个CIB用来定义资源特定的属性，哪些资源定义在同一个节点上。主节点上的CRM被选举为DC(Designated Coordinator指定协调员，主节点挂掉会选出新的DC)，成为管理者，它的工作是决策和管理集群中的所有资源。

任何DC上会额外运行两个进程，一个叫PE，；一个叫TE。
•PE ：定义资源转移的一整套转移方式，但只做策略，并不亲自来参加资源转移的过程，而是让TE来执行自己的策略。
•TE : 就是来执行PE做出的策略的并且只有DC上才运行PE和TE。

CIB组件：XML格式的配置文件，工作的时候常驻内存，只有DC才能对CIB进行修改，其他节点上的复制DC上的CIB而来。集群的所有信息都会反馈在CIB中。

LRM组件：是执行CRM传递过来的在本地执行某个资源的执行和停止的具体执行人。

资源(补充)：
在集群中构成一个完整服务的每一部分都叫资源，都需要配置和管理。
以web应用为例：vip是资源，web服务器是资源，存储也是资源。不同的服务的资源也不尽相同，其中存储资源的选择、配置、管理是高可用集群中的难点问题。

4.资源代理层（Resource Agents）
集群资源代理,能够管理本节点上的属于集群资源的某一资源的启动，停止和状态信息的脚本，资源代理分为：LSB（/etc/init.d/*）,OCF(比LSB更专业，更加通用)。

任何资源代理都要使用同一种风格，接收四个参数：{start|stop|restart|status}，每个种资源的代理都要完成这四个参数据的输出。

工作机制：PE根据CIB获取资源的配置信息(集群上的所有信息都会收集到DC的CIB，同步到其它节点)，而后做出决策，一旦做得决策就会进行资源的管理。PE借助于本地的CCM通知给其它节点CIB来实现对某些资源管理信息的传递，比如说通告其它CRM要启动某一资源了，收到信息后CRM并不负责启动，转由LRM(Local Resource Manager本地资源管理)启动，而并发资源又借助于RA(Resource Agent资源代理)实现资源管理。

上面这张图和各个专业术语的解释，很多也很详尽，对于没有接触过主机HA的人来说，真是云里雾里，都是底层细节，各种模块和作用。理解起来还是需要一定的功力。

结合着上面图示我们这里浅显说一下主机HA应该具备的模块和实现原理。

1. 首先要有网络（IP和非IP网络），这个是HA软件多节点通讯的基础，只有网络畅通才各个模块才可以发现，协作，心跳等
2. 要有一个配置库，说白了要有一个记录配置集群各个方面配置信息的信息库，记录着目各个组件的构成和配置，如果某个节点的配置发生了变化，有据可查，需要保证集群配置的一致性，要不然集群切换回异常。
3. 要有一个事件采集器，或者认为是监控代理，说的其中某个节点或者集群中发生了什么事件集群管理器要清楚，统一掌控全局，触发什么事件执行什么策略。
4. 资源管理器，一般是集群的核心组件，派发资源和策略，维护配置等等中央首长职能。
5. 资源组：集群都是以资源组为单位进行切换，资源组包括：ip，app，共享磁盘 等

这些就是集群中的主要构成，了解这些就大致掌握了HA 软件的结构和实现原理，具体到每款软件的实现及详细工作原理，请查看相应的技术手册。

7.那些场景不适合主机HA

主机HA可以解决很多高可用的问题，为企业带来便利，但是同时我们也应该清楚哪些场景不适用主机HA解决方案。

下面几种情况均不适合服务器主机HA解决方案：

1. 服务器和网络环境是不安全的
2. 服务器管理比较随意
3. 不能忍受任何的（应用系统）中断
4. 应用系统还不稳定
5. 应用系统需要人工该有才能恢复

同时我们也应该了解一下主机HA和容灾的区别，场景不能混淆。有的个别企业想使用主机HA来达到容灾的效果，往往不达目的，其实很简单，只需要了解本片小文的第三部分（主机HA能做什么）就清楚了，有针对性的选择高可用解决方案。
下面附一张主机HA和容灾的区别：

8.主机HA高可用选择参考

这里分享一下社区会员对主机高可用解决方案的一些心得和体会，希望可以在方案选择方面起到一点参考作用。

分享一：

首先需要明确一点，主流的主机HA高可用解决方案和OS有比较紧密的关系。选择哪款软件差不多也就选择什么样的系统，这里我先分享一点经验。

1. PowerHA 功能强大，配置灵活，切换和回切都很方便。支持命令行和smitty 方式进行，应用监控选项很多时候不启用，有些版本有些问题。。。
2. ServiceGuard 配置复杂，切换方便，曾经配置一个群集需要2day，配置完成了很方便，支持gui界面，很不错。
3. F5 基本上只是能够做到虚拟一个ip，然后进行轮训，当然可以设置权值以及会话选项，可以通过测试页面验证应用是否Ok。不能做到支持集群共享模式的环境，自动执行什么脚本进行切换。
4. RoseHA 支持节点数量2个，不知道后续产品可以支持更多节点。。。
5. SUSE HA 也是一个不错的产品，命令行crm load 配置文件也可图形界面。图形界面感觉比较繁琐。监控和管理使用还是不错的。

分享二：

PowerHA 使用多些，感觉好用；roseha 最不好用（问题多）；ServiceGuard是HP的还可以，Linux RHCS自带的没使用过。

分享三：

不同的操作系统平台会有各自的高可用套件。我一开学习HA的知识就是PowerHA，当时叫做HACMP，诚如LS说的功能强大，配置灵活，配置逻辑清晰；一般搞清楚PowerHA里头的配置概念就足以完成配置。

分享四：

Bug一般的ha软件都会存在，只不过触发这个bug需要一定的条件，简单的方法就是升级补丁或者其他方法去修复这类的bug，防止bug发生！工程师会慢慢积累一些稳定版本的补丁，比如安装HA 6.1，我习惯吧SP16补丁打上，是目前很多苏皖客户使用的稳定版本。

分享五：

主机HA避免脑裂的常见方法：
1.节点数量为计数，quorum法则
2.串口心跳
3.磁盘心跳
4.管理口stnoith，直接资源隔离

社区的会员积极的分享了在主机HA使用和选择方面的一些经验，希望对大家有所帮助，随着IT的发展，我们有了更多的方案可以去选择，没有最好的方案，只有适合的场景的解决办法，切勿为了简单问题复杂化，统一规划，适合就好。要不然就是画蛇添足，有卖弄技术和推销产品的嫌疑，对解决问题有害无利。

X86的快速发展给大家提供了更多的选择，什么一体机，超融合，分布式，大数据，云等这些概念和产品都一一落地，不是说以前就没有这些东西，而是说在有了X86的快速发展的背景下，这些产品有了更好的发展。现在很多的解决方案都是基于X86环境，我们选择相应解决方案更应该统一考虑，切勿人云亦云。主机HA方案的选择亦是如此。

主机HA高可用解决方案参考：

1. 选择主机HA成熟产品
2. 选择主流稳定版本和补丁版本
3. 选择易于管理维护，易于后期扩展的产品
4. 选择符合企业整体规划，切勿太多产品，太多版本，资源相对较多的产品

9．Oracle高可用场景的解决方案探讨分享

应用场景: Oracle 数据库的高可用方案选择？
企业C由于业务开展的比较好，近些年IT基础平台也在大力的建设，该企业有一个重要业务系统，数据库平台使用oracle，由于地域和容量太等特点选择了使用多个数据库分别独立支撑不同该业务系统一部分，共计5个db，各个系统相互独立，如果每个db都搭建主机ha或集群的情况下，那将也是一笔不小的开支，该企业由于以前使用IBM的小型机平台，对PowerHA解决方案比较熟悉，所以他们对主机平台选择小型机还是有所倾向，在X86 平台日益成熟的背景下，你选择X86还是选择小型机平台，该企业的DB高可用方案你有哪些方面的考虑和想法，欢迎大家积极探讨。

方案1：

选择X86平台的LINUX，各系统分别独立物理机，成本比小型机只低不高，而且也能满足现状，甚至未来三到五年的发展，Oracle RAC+ADG+每天全备或者增量备+异地灾备（看需求，没有特殊需求，基本不用），这样基本不会断业务，除非自然灾害。

方案2：

因为是单库，分别独立，其实用主机ha解决，使用一备多的模式也是可以的，主机的数量也只是需要多一台设备就好，从硬件成本来考虑X86应该是首选，使用rac+adg的模式，因为是独立数据库架构有点复杂，投入感觉还是很大的，维护起来也是不那么容易。当然这些都是参考方案。

方案3：

1：个人在规划中得出的结论：所有想靠一套方案实现容灾、高可用的想法都是有瑕疵的，
2：在考虑数据库授权的前提下。在软件成本上来说POWER HA要比Oracle RAC费用稍低，但硬件成本上说PPC平台远高于X86平台（利旧情况除外），
3：针对于你说的这个C企业，因为不是很具体明了业务架构，比较常见的x86平台容灾方式就是本地中心的RAC+同城DG+实时备份+定时备份，PPC平台也同时也可以采用这一套方案或者用HACMP来代替RAC
4：具体规划的容灾或者双活的时候，主要会考虑2个问题。主要从权威性进行考虑，例如设计到钱，必须需求这个数据‘准确无误’，比如财务系统、比如进销存、比如供应链的设计到财务的部分，这部分由于设计到从业务逻辑上就需要对数据的权威性、一致性有较高要求， 在设计的时候就会考虑到，在主节点配置高性能、多节点、高安全性的RAC来完成写入（如需，可能配置DG做读均衡），在第二、第三中心可以使用DG、GG、实时备份、定时备份等手段保证安全。
5：如果这套系统对数据权威性要求并不是那么高、比如工艺研发、生产数据收集等，那完全可以使用更加简单的GLSB+stateless模式来做多活和容灾，
6：针对于你说到C企业中的有5个DB放在不同位置的物理位置，其实这是一个综合考虑成本事情了。比如在4与5里面说道的 比如业务对数据权威要求很高，推荐的做法包含了每个DB的本地业务中心和异地容灾中心，在小数据量传输的情况下甚至可以选择数据集中一个中心使用VPN来走数据。；如果要求不高、可以用OGG实现一个中心5个分支stateless，配合GLSB选路完成容灾；

方案4：

预算够是土豪，那么使用硬件的高可用加上oracle的rac。
例如，vplex呀，vmware的vmotion呀，还可以分布式存储爽一把呀，多的数不清。
主要看预算

方案5：

可以参考一下oracle12.2 Oracle Domain Services Cluster，从更大层面来做oracle db和App的高可用方案，包括了异地多站点的HA，这样X86平台足够了

总结：

以上几种方案都是基于不同的考虑作出的，也都有一定的理由，作为吃瓜群众，我们是否也有也有一些切实可行的方案呢。这里有一点小小的体会：

1. 任何解决方案都要也解决实际问题为出发点。
2. 综合了解企业实际，统一规划，选择适合自身，且扩展性和延续性方面应该有所考虑。
3. 在以上两点的基础上尽量减少成本的投入。
4. 切勿人云亦云，画蛇添足，任何技术都要立足于需求。