你可以通过在架构的每一层中构建冗余，来设计一个高可用服务器集群。高可用性能够让你的应用即使在基础设施部分组件发生故障时，也依然保持可访问和响应迅速。当某个组件失效时，冗余组件会立即接管；而多可用区部署则能帮助你抵御局部区域故障。灾难恢复方案则让你能够在发生重大中断时快速恢复服务。在开始之前，你需要先评估应用的需求，并选择合适的基础设施形态，无论是云环境、裸金属，还是边缘部署。

高可用架构原则

什么是高可用性？

你希望应用即使在出现问题时也能持续在线。高可用性意味着即便部分组件失效，系统仍然能够持续运行。在高可用服务器集群中，你要尽可能消除单点故障。这种方式能够确保用户始终可以访问你的服务。大多数组织都会将全年至少达到 99.99% 的可用性作为目标。你可以从下表看出，不同可用性级别对停机时间的影响：

  • 高可用性的核心在于持续运行和尽可能高的在线率。
  • 四个 9（99.99%）意味着每年大约只有 52 分钟的停机时间。
  • 五个 9（99.999%）意味着每年仅允许约 5 分钟的停机时间。
  • 100% 在线是理想目标，但几乎不可能真正实现。

为什么高可用性对应用至关重要

停机会损害你的业务，也会让用户感到沮丧。你需要一套高可用策略来保护应用，避免常见宕机场景。这些原因包括人为失误、硬件故障、网络攻击以及网络问题。下表展示了最常见的停机原因：

原因说明
人为失误43% 的非计划停机源于配置错误等人为操作失误。
硬件故障电力问题或硬件部件损坏都可能导致服务器停止运行。
网络攻击（DDoS）攻击者可能利用海量虚假流量淹没你的服务器。
DNS 故障DNS 问题会导致网站无法访问。
数据库瓶颈数据库响应缓慢会让应用看起来像是已经宕机。
网络基础设施问题网络组件损坏可能会切断用户对服务的访问。

强健的高可用架构能够帮助你避免这些问题。你需要构建冗余、使用多个集群，并为快速恢复做好规划。

关键指标与 SLA

你需要使用明确的指标和服务级别协议（SLA）来衡量高可用性。下表展示了不同可用性水平下预期的停机时间：

可用性百分比“几个 9”级别每年停机时间
99%两个 93.65 天
99.9%三个 98.77 小时
99.99%四个 952.60 分钟
99.999%五个 95.26 分钟

你还应当跟踪 RTO（恢复时间目标）和 RPO（恢复点目标）。RTO 指系统最长可接受的停机时间；RPO 指你最多可以接受的数据丢失量。对于高可用设计而言，这两个数值都应该尽可能低。云服务提供商通常承诺 99.9% 的可用性，而真正的高可用方案通常会追求 99.99% 甚至更高。

设计高可用服务器集群

服务器集群中的冗余设计

要实现高可用服务器环境，你必须在服务器集群中构建冗余。冗余意味着当某一部分发生故障时，你已经准备好了可以立即接管的备用系统。这种方法能够保障应用持续运行，并减少用户感知到的停机。

集群中的常见故障点包括：电力中断、网络硬件故障、磁盘损坏、内存问题、软件缺陷，甚至人为失误。下表列出了一些典型风险：

故障点说明
电力故障停电会让节点离线，并在重启完成前中断集群服务。
网络硬件故障交换机、路由器或网卡故障如果没有冗余，会导致节点性能异常甚至不可用。
磁盘故障硬盘可能因老化磨损而损坏，从而影响集群功能。
内存问题数据损坏或 RAM 故障可能导致服务器关机，或影响堆栈中的其他组件。
软件兼容性问题冲突的软件指令会扰乱节点运行，导致性能不一致。
安全漏洞应用中的弱点可能被攻击者利用，导致服务器关闭或无法访问。
软件缺陷软件中的错误可能引发异常行为，甚至导致服务器完全失效。
资源耗尽不合理的网络设置可能使节点过载并最终宕机。
延迟过高的延迟会使节点失去响应，破坏集群功能。
网络分区集群部分区域彼此隔离时，即使节点本身正常，也可能触发系统故障。
环境因素与人为失误环境事故和操作错误都可能严重扰乱服务器集群的工作流程。

为了应对这些风险，你应采用 3 节点或 5 节点拓扑。这种部署方式具有较高冗余度，能够帮助集群在多种故障场景下继续运转。当某个节点失效时，自动故障转移会把工作负载迁移到健康节点上，从而保持服务可用和稳定。

构建高可用集群时，常见的冗余策略包括：

  • 同时采用主动-主动（Active-Active）与主动-被动（Active-Passive）配置，以平衡流量并提供备份。
  • 在不同节点上维护关键资源的多个副本。
  • 配置自动故障转移，在节点失效时快速迁移工作负载。
  • 妥善管理仲裁（quorum），防止出现“脑裂”问题，即集群两部分各自独立运行。
  • 持续监控资源和应用，尽早发现问题。

多可用区集群部署

通过跨多个可用区部署集群，你可以显著提升在线率和整体韧性。每个可用区都拥有独立的电力、制冷和网络资源。这种隔离能够降低单一事件拖垮整个部署的风险。

下表说明了多可用区部署如何增强你的高可用策略：

方面说明
冗余即使某个可用区发生故障，应用也能依靠冗余和故障转移机制继续保持可用。
基础设施独立性各可用区拥有独立的电力、制冷和网络资源，可减少同时发生大面积故障的概率。
容量分布工作负载分散在独立故障域中，因此某一个可用区失效时，只会影响部分容量。

当你将多个虚拟机或容器分布到不同可用区时，通常可以获得更高等级的在线率 SLA。区域冗余架构能够帮助你的服务抵御本地故障、极端天气事件或数据中心故障。Kubernetes 可以帮助你更轻松地管理跨可用区集群。你可以借助 Kubernetes 在不同可用区之间调度 Pod、平衡工作负载并自动执行故障转移。这种方式有助于打造更具韧性的集群架构，确保应用持续在线。

容错策略

容错意味着即使部分组件失效，集群也能够继续工作。你需要为不同故障场景提前做好规划，并确保恢复步骤清晰、简洁、可执行。要打造稳健的高可用设计，请遵循以下最佳实践：

  1. 梳理所有关键服务及其依赖关系。
  2. 根据对业务的影响程度，对可能的故障场景进行排序。
  3. 优先对最高风险区域实施控制措施。
  4. 通过故障模拟或在计划维护期间测试故障转移。
  5. 持续监控集群，并根据真实运行情况调整阈值。
  6. 用简洁明了的语言为值班团队记录恢复步骤。

定期测试至关重要。通过模拟故障，你可以提前发现集群中的薄弱环节，并在它们引发真实事故之前完成修复。Kubernetes 可以自动完成许多这类任务。它能够重启失败的 Pod、重新调度工作负载，并维持你设定的目标状态。你还可以利用 Kubernetes 的健康检查机制尽早发现问题，并触发自愈动作。

高可用服务器集群离不开稳健的高可用策略、审慎的架构设计以及合适的工具。Kubernetes 为现代高可用集群提供了所需的自动化与编排能力。当你将冗余、多可用区部署和容错策略结合起来时，就能构建出能够持续支撑应用运行、提升用户满意度的集群。

架构层与 Kubernetes 集成

高可用服务器集群依赖三大核心架构层。要构建稳健方案，你需要理解每一层如何发挥作用。下表列出了关键层级及其职责：

架构层说明
计算层高可用性通过将多台服务器组成集群来实现，这些服务器共享工作负载并相互监控健康状态。一旦某台服务器失效，工作负载就会迁移到其他服务器上，从而保证应用持续运行。
存储层高可用性通过将数据分布到多个存储节点来实现。即使某个存储设备发生故障，数据依然可以访问，这对应用性能至关重要。
网络层高可用性通过多条网络路径实现，依赖冗余交换机、防火墙、路由器和链路。当某条路径失效时，流量可以重新路由，从而避免连接中断。

计算层冗余

你可以通过将多台服务器组成集群来实现计算层冗余。这种方法允许你在多台服务器之间共享工作负载并监控每台服务器的健康状态。如果某台服务器失效，系统会自动将工作负载转移到健康服务器上，从而确保应用不中断运行。为了获得更好的韧性，你应当至少使用三个节点。

  • 将多台服务器组成集群
  • 在服务器之间共享工作负载
  • 监控服务器健康状态
  • 启用自动工作负载迁移

存储层高可用

你必须保护好数据，才能确保应用持续可用。存储层的高可用意味着你要将数据分布到不同的存储节点上。这样即使某个设备故障，数据依然可以访问。像 SIOS DataKeeper 和 DxEnterprise 这样的技术可以帮助你实现存储冗余管理。SIOS DataKeeper 无需共享存储，并支持灾难恢复，但它更适合 Windows 环境。DxEnterprise 则支持跨平台集群，也能很好地适配 kubernetes 集群。它还提供面向 kubernetes 的原生编排能力，使管理更加容易。

技术优势局限
SIOS DataKeeper无需共享存储，支持灾难恢复主要面向 Windows，且需要额外的管理工作
DxEnterprise跨平台，原生支持 kubernetes对部分团队来说，可能需要建立新的运维流程

网络层韧性

你需要保证网络层具备足够的韧性，以防止因网络故障导致的停机。使用冗余交换机、路由器和网络路径，可以在某一路径失效时自动改道流量。启用 IPv4、IPv6 和链路层发现等特性，也有助于维持连接可靠性。下表列出了一些重要的网络设置：

网络特性设置
Microsoft 网络客户端启用
QoS 数据包计划程序可选
文件和打印机共享启用
IPv6启用
IPv4启用
链路层发现映射器启用
链路层发现响应器启用

Kubernetes 用于集群编排

Kubernetes 为高可用和编排提供了强大的工具。你可以部署多个控制平面节点，并使用外部 etcd 数据库来提升可靠性。Kubernetes 通过复制和冗余机制，确保即使部分组件失效，集群仍能持续运行。例如，你可以在负载均衡器后部署多个 kube-apiserver 副本。这样能够分散 API 请求，避免单点故障。

Kubernetes 还可以通过 node ports、Ingress 和 LoadBalancer 服务来管理流量。这些功能能够在整个部署中分发流量，并实现快速故障转移。如果某个节点或 Pod 失效，kubernetes 会重新路由流量，确保应用持续在线。你可以依赖 kubernetes 自动执行恢复，并维持目标状态。这种方式能让架构更加稳健，也更易于管理。

负载均衡与应用可用性

负载均衡器配置

为了让高可用服务器集群平稳运行，你需要一个强健的负载均衡器配置。负载均衡会将流量分散到多个节点上，避免单台服务器被压垮。这种方式既提高了资源利用效率，也支撑了你的高可用策略。你可以使用不同算法来分配流量。下表列出了常见方法：

负载均衡方法说明
轮询（Round Robin）按顺序将请求分发到各台服务器。
最少连接（Least Connections）将新请求路由到当前活动会话最少的服务器。
基于健康状态的路由（Health-based Routing）自动将不健康目标移出服务池。

主动-主动集群通常会使用专门的 loadbalancer 来分发流量。你可以根据架构需求选择加权轮询（Weighted Round Robin）或随机（Random）等算法。Kubernetes 支持这些方法，并能帮助你为应用自动实现负载均衡。

流量路由与会话管理

为了维持应用可用性，你必须高效地进行流量路由。良好的会话管理能够保证用户数据安全，并带来顺畅体验。下表说明了不同因素如何影响应用可用性：

方面对应用可用性的影响
会话管理在各项服务之间维持用户状态，提供平滑体验。
负载均衡防止瓶颈和单点故障。
容错能力在故障期间保持会话不中断，从而提升可靠性。
可扩展性允许你在扩展服务时仍然保持会话完整。
安全性保护会话数据，降低影响可用性的安全风险。

Kubernetes 的 Ingress 和 Service 对象可以帮助你管理流量路由和会话保持。你可以使用 Source IP Hash 算法，让用户会话持续落在同一个节点上。这种方式有助于支撑高可用方案，并提升服务稳定性。

数据库高可用

你需要一个高可用数据库来保护数据，并保持应用在线。高可用数据存储通常依赖集群、复制和自动故障转移。下表列出了主要策略：

策略说明
故障转移当某个节点失效时，将服务迁移到健康节点。
健康检查监控系统健康状态，以便快速检测故障。
集群使用多台服务器，在节点故障时保持服务不中断。
负载均衡分散请求，防止系统过载。
复制在多个系统之间复制数据，以提升可用性。
消除单点故障通过冗余设计，避免依赖单一组件。

你应当消除单点故障、快速检测问题并实现自动故障转移。还要定期测试高可用策略和恢复路径。Kubernetes Operator 可以帮助你管理有状态工作负载和存储，从而支撑高可用服务器集群。

监控、恢复与灾难规划

健康检查与监控

你必须持续监控高可用服务器集群，才能让应用稳定运行。持续性的健康检查可以帮助你快速发现故障。你应重点跟踪节点健康、应用响应、存储延迟、CPU 压力、内存使用、复制延迟以及网络丢包情况。

以下是你应实现的关键健康检查：

健康检查项说明
验证集群资源确保所有资源都按预期工作。
时间同步确认已配置 NTP，避免时钟漂移。
运行集群验证使用工具检查存储、网络和配置是否正常。
监控服务故障关注服务崩溃等常见问题。
检查 CSV、仲裁盘或见证磁盘检查关键磁盘的运行状态。
运行 chkdsk 并查看诊断信息执行磁盘检查并分析健康报告。
验证证书确保所有证书有效且未过期。

自动故障转移与自愈

自动故障转移和自愈能力可以让你的集群更具韧性。你可以使用 kubernetes 来重启失败的 Pod，并重新调度工作负载。像 Netflix 这样的公司会使用混沌工程，通过主动注入故障来验证恢复能力。Google 的系统能够自动重启失败容器并回滚部署。AWS 则会在故障发生时将实例迁移到健康硬件上。这些策略可以帮助你在面对流量激增和意外宕机时，无需人工干预也能保持服务稳定。

  • 借助 kubernetes 重启失败的 Pod 和容器
  • 使用混沌工程工具测试恢复能力
  • 使用自动扩缩容应对突发流量变化

备份与灾难恢复

你需要一套强健的备份与灾难恢复方案来保护数据和服务。请遵循以下最佳实践：

最佳实践说明
备份频率根据数据变化的频率进行调整。
保留策略规划同时满足短期和长期的备份保留需求。
统一命名与归档为备份使用清晰的命名方式，避免恢复时出错。
3-2-1 原则保留三份数据副本，存放于两种不同介质上，并确保其中一份异地保存。
空气隔离副本离线存储一份备份，以防御网络攻击等安全威胁。
灾难恢复架构设计服务恢复方案，包括故障转移流程和数据依赖关系。

常见的灾难恢复场景包括多站点集群和主动-被动架构。多站点集群会在不同地理位置部署一个次级站点，以便在主站点发生区域级故障时维持服务运行。主动-被动架构则允许你在需要时切换到备用系统。你应该经常测试备份恢复流程，并明确设定恢复时间目标和恢复点目标。

高可用检查清单

你可以使用下列清单来检查你的高可用部署是否完善：

检查项说明
人员配置确保有足够且训练有素的人员来管理系统。
变更管理控制更新和补丁发布，降低风险。
访问控制建立分级账号权限，阻止未授权人员执行关键命令。
测试流程在预生产环境中测试，执行备份，并定期演练灾难恢复。

你可以按照以下步骤设计高可用服务器集群：

  1. 在真正需要之前就先完成故障转移测试。
  2. 以实现应用 99.99% 的在线率为目标。
  3. 让架构设计与你的在线率目标保持一致。
  4. 消除单点故障。
  5. 使用可靠的故障转移机制。

常见问题

高可用服务器集群的主要目标是什么？

你的目标是在发生故障时，依然让应用保持在线。其核心目标就是尽可能减少停机时间，并让服务持续对用户可用。

Kubernetes 如何帮助实现高可用？

Kubernetes 能自动执行故障转移和工作负载分配。你可以利用它来重启失败的 Pod、重新调度工作负载，并维持期望状态。

冗余和容错有什么区别？

冗余容错
备用系统在组件失效时进行替换接管。即使发生故障，系统仍能持续运行。

灾难恢复计划应该多久测试一次？

你应至少每半年测试一次灾难恢复计划。定期测试能够帮助你发现薄弱环节，并持续优化响应流程。