关于 “高可用集群” 的从业经验漫谈-Toy模板网

这篇具有很好参考价值的文章主要介绍了关于 “高可用集群” 的从业经验漫谈。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

关于高可用集群

PART 1 高可用的概念

高可用（High Availability）是高可用集群（High Availability Cluster）的简称，至少由2台服务器组成，一般指的是应用服务对客户端的持续可用。高可用集群可以借助多种技术手段实现，构建服务器集群是实现高可用集群的流行做法。

借助 LVS、Nginx、HAProxy等负载均衡软件可以实现集群中的故障检修与业务切换自动化。从实践技术上讲，服务器集群的负载均衡策略对实现集群中应用服务的持续可用起着核心性质的控制作用。

PART 2 应用服务高可用的衡量标准

一般通过应用服务系统的可靠性（Reliability）和可维护性（Maintainability）来衡量当前应用服务系统的高可用程度。可靠性一般用应用服务系统平均无故障时间进行度量；可维护性一般用应用服务系统平均维护时间进行度量。一个应用服务系统在某个时间段内的高可用程度即为应用服务系统平均无故障时间与应用服务系统存续时间的比值。指标化的表示公式为：

高可用程度=平均无故障时间/（平均无故障时间+平均维护时间）

PART 3 高可用集群的逻辑架构

关于 “高可用集群” 的从业经验漫谈,java,大数据,开发语言

PART 4不同业务分类场景下高可用集群实现方案

甲存储方向的高可用集群实现

核心思想：数据副本冗余与数据副本被就近访问。

甲一借助网路把数据复制传送到多台存储设备上，实现存储数据的高可用

通过Rsync、scp、ftp、sftp等工具对存储的数据进行复制传输，常见于多个小型、异地数据中心之间进行数据备份与灾难恢复。

甲二使用直接附加存储（DAS）设备在多个硬件设备上，实现存储数据的高可用

面对小型简单存储需求可使用磁盘 RAID 0+1 方案，对RAID阵列进行模式0和模式1的组合操作实现；面对大型复杂环境的数据存储需求则可以使用NAS（网络附加存储）方案，NFS是一种典型的NAS实现方式；在超大型核心数据中心数据存储许晴的场景下，则建议使用iSCSI-SAN（iSCSI-存储区域网络）方案，常见的实现方式是 FC-SAN和 IP-SAN。

甲三借助分布式结构的实现存储数据的高可用

在云计算、大数据场景下，可以借助SDN方案实现数据的冗余存储与快速读取。当前受众比较广泛、实践中使用较多的分布式SDN实现产品主要是 Gluster FS 、MinIO FS、HDFS、Oracle开源的ocfs2 FS、 Ceph FS、Linux-Kernel级别的Distributed ReplicatedBlock Device（DRBD）。当前，基于 RedHat 系列产品构建的业务平台使用Gluster FS 较多、整合开源产品构建的业务平台使用 Ceph FS 较多。

乙故障转移方向的高可用集群实现

核心思想：快速识别业务服务器状态、快速启用备用业务服务器，让终端用户对应用服务状态变化无感知。

乙一借助硬件热插拔技术快速切换故障

一般在IAAS平台中，物理服务器发生了部分硬件故障（比如NIC），可以借助硬件厂商提供的热插拔技术快速修复故障。同样，在基于 KVM-QUME 模拟的硬件发生故障后也可以借助虚拟化热插拔技术快速更换指定的虚拟部件。

乙二借助虚拟IP快速切换故障

通过将提供服务的主机和 Virtual IP 进行绑定，可以在终端用户毫无知觉的状态下下更换提供目标应用服务的主机。

丙负载均衡（Load Balance）方向的高可用集群实现

核心思想：各应用服务节点合理担负负载压力，提供服务冗余。

丙一局域网内的负载均衡高可用实现

借助负载均衡套件实现，有两个实现方向：服务端代理调度和客户端正向调度。客户端正向调度又分为两种情况：一是客户端统一调度、二是客户端负载调度。客户端统一调度的常见场景是将某一类请求（比如来自手机APP的请求和来自浏览器的WEB请求）统一调度到某一个或某几个目标服务器上进行业务处理。客户端负载调度一般是基于客户端的的链接监测程序获取目标后端的全部应用服务器的负载状况、并由客户端自主选择合适的目标服务器进行业务处理。

服务端代理调度是应用服务提供方重点关注的实现方向。对于应用服务提供方而言，实现负载均衡调度的最佳选择就是提供可伸缩的虚拟服务，让虚拟服务时刻保持客户端可访问。此方案的开源实现套件主要有LVS（Linux Virtual Server）、HAProxy、Nginx-upstream、Keepalived、Squid cache、Google 开源的Seesaw和Maglev、Heartbeat 3、Kubernetes提供的kube-proxy、大众点评为F 5开源的Camel、UCloud的Vortex等。此外还有系统集成厂商提供的针对特定业务场景的商业负载均衡高可用套件，如 F5 BIG-IP 、Citrix NetScaler、RedHat Cluster Suite、中兴Newstart HA、Novell Cluster Service、Steeleye Lifekeeper for Linux、深信服AD的CDN负载均衡、各公有云厂商提供的Elastic Load Balance等。

负载均衡调度策略大体上可分为静态调度侧率与动态调度策略两类，开源套件中常见的负载均衡调度策略有：轮询、随机、最小链接、最小负载、最短响应时间、权重、活跃粘度、HASH、FAIR、IP、TCP/UDP流量等。

在使用负载调度策略时应考虑C/S交互中的会话一致性，保证同一个长链接会话粘滞到同一个应用服务器上，因此需要结合应用服务器的健康检查实现会话流出的负载下线业务场景，典型的场景是应用服务器节点的计划性维护下线。

丙二跨地域的负载均衡高可用实现

和DNS（Domain Name System）解析分布式数据结合实现。DNS服务默认的轮询策略会把一个域名轮流解析到一组IP上、从而实现业务负载分摊。

丙三基于硬件的负载均衡高可用实现

主要代表是 F5 、A 10、中兴等系统集成厂商提供的硬件负载均衡设备。硬件厂商的设备一般能提供强劲的服务，稳定性较高，性能较好，能支持百万级别的并发量，但价格十分昂贵，一般在一个数据中心最多使用两个此类硬件设备，以主备的形式构建高可用。

丁分布式结构方向的高可用集群实现

核心思想：解耦组件间的强依赖关系，利用消息堆栈联通组件进程工作流。

丁一拆分业务系统组件进行模块化分离部署

把业务系统的部件进行拆分组模后分离部署，这糅杂了微服务业务系统架构和分布式系统思想，需要对当前业务系统的单体应用进行拆分和模块化打包，运维架构的工作量相当大。但在业务快速增长的场景下或者敏捷开发与发布的场景下，这是个最优选择方向，结合蓝绿发布策略，既可以保证应用服务的高可用、又可以实现软件代码版本迭代的实时更新。

这种业务系统改造和运维系统架构完全是定制化的，实施成功与否严重依赖运维架构团队自身的知识深度和广度积累、及其对目标业务系统运转流程的熟悉程度，几乎没有可以直接克隆使用的案例。

丁二对业务系统组件进行抽取并改造构建公共服务

对业务系统抽取服务组件并构建为公共服务中间件，借鉴了“中台”思想。一般一个复杂的应用服务系统会涉及多种通用服务（比如数据存储，典型的是数据库服务），可能每个组件对这一类服务的要求略有差异（比如消息队列存储和集群配置信息存储的差异），此时可以考虑抽象出一个数据公共服务层，借助分布式共享存储和容器技术构建数据服务及数据共享存储。

对此，我本人在实验环境下搭建过一个学生信息全息平台，通过数据可视化面板可以展示出和一个学号关联的全部校务信息，在数据存储方面我就抽象了一个数据公共服务，它由一个MinIO数据池和一个Kubernetes集群上运行的MySQL、Redis、ElasticSearch和DataEasy容器吊舱组成。MinIO数据池存储着全部的结构化与非结构化数据，MySQL、Redis、ElasticSearch引擎负责接收客户端数据请求和存储池中的数据存储，DataEasy负责通过 Web UI界面展示可视化报表。

唯一的缺憾是，这个实验室产物没有进行大量数据验证，但它证明了“构建公共服务层”联通业务流转的上下游这个思路是可行的。文章来源地址https://www.toymoban.com/news/detail-728250.html

到了这里，关于关于 “高可用集群” 的从业经验漫谈的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！