尽管 Linux 以其极高的系统稳定性而闻名，但标准 PC 硬件并非如此可靠的事实不容忽视。我维护 Linux 服务器已经很长时间了，在大多数系统故障的情况下，都是由于服务器硬件故障造成的。UNIX 在商业领域以其良好的集群和高可用性 (HA) 技术而闻名。

在我目前的公司 Electec，我们严重依赖电子邮件（Sendmail 和 IMAP4）、Windows 文件共享（Samba）、FTP 和拨号身份验证 (radius) 服务，每天 24 小时与位于不同时区的供应商、员工和客户进行沟通。直到最近，所有这些服务都整合在一台 Linux 服务器上。这个系统为我们提供了非常好的服务。然而，硬件故障迟早会发生，这将导致我们的生产力和收入损失。

随着我们在业务中越来越依赖计算机，高可用性变得越来越重要。我决定为我们的关键业务需求设计和实施一种廉价的高可用性解决方案，而无需使用昂贵的额外硬件或软件。本文涵盖了该解决方案的设计方面、陷阱和实施经验。

服务器高可用性存在许多不同的方法和方法的组合。一种方法是使用具有冗余电源、RAID、环境监控、风扇、网络接口卡等的单台容错服务器。另一种方法是使用多台非冗余硬件单元组成集群，以便集群中的每个节点（或服务器）都能够接管任何伙伴节点的故障。容错服务器方法的优点是操作系统、应用程序配置和操作与使用简单的廉价服务器相同。对于集群，应用程序和操作系统配置可能会变得非常复杂，并且需要进行大量高级规划。

使用容错服务器，故障处理方式是客户端不会注意到任何停机时间——恢复是无缝的。理想情况下，集群中的节点故障也应该是这种情况。在许多情况下，集群的硬件成本远低于单台容错服务器的硬件成本，特别是当您不必为商业集群软件产品花费大量资金时。

成本与客户端中断/停机时间之间存在权衡。您必须问问自己，您和您的用户可以容忍多少停机时间。较短的停机时间通常需要更复杂或更昂贵的解决方案。在我们的案例中，我决定我们可以忍受发生故障时大约五分钟的停机时间；因此，我选择使用集群而不是单台容错服务器。

UNIX 市场上有许多集群解决方案可用，这些解决方案可以通过会话和网络连接接管来提供几乎为零的节点接管停机时间。这些解决方案大多价格昂贵，通常需要使用外部共享存储硬件。在我们的案例中，我们可以允许会话和连接丢失。这简化了实现高可用性集群的任务。

在实施 HA 集群时，有些人建议使用共享存储设备，例如双端口 RAID 盒。但是，可以通过为集群中的每个节点使用单独的存储设备并在必要时镜像存储设备来解决此问题。每种方法都有其自身的优点。共享存储方法的优点是永远不需要在集群节点之间进行任何软件数据镜像，从而节省宝贵的 CPU、I/O 和网络资源。共享也是有益的，因为可以从另一个集群节点访问的数据始终是最新的。镜像方法使用单独的存储设备，其优点是集群节点不必位于同一地理位置，因此在灾难恢复场景中更有用。实际上，如果镜像数据被压缩，则可以通过 WAN 连接将其发送到远程节点。

RAID 系统是可用的，它允许磁盘在地理上分布，并且需要通过光纤互连；然而，这些系统相当昂贵。两组简单的存储设备比容量相似的双端口 RAID 盒便宜。在某些情况下，双端口 RAID 盒可能会在集群中引入单点故障。如果 RAID 文件系统在某种程度上损坏到无法恢复，则会导致严重的集群停机时间。大多数 RAID 系统在设备级别镜像数据，而不考虑正在使用的文件系统。基于软件的系统可以在用户空间中镜像文件，因此如果一个节点上的文件变得不可读，则不一定会将相同的文件系统损坏复制到另一个节点。由于此优势和成本因素，我决定在集群中的每个节点上使用单独的存储设备。应该注意的是，即使使用了双端口存储设备，集群中的两个节点也绝不应同时以读/写方式挂载同一分区。

将工作负载均匀地分布在集群中的节点上比让一个节点完成所有工作直到它发生故障，然后让另一个节点接管更好。这种情况的术语是 热备 系统。

负载均衡可以采取多种形式，具体取决于所讨论的服务。对于提供简单静态页面且通常为只读的 Web 服务器，循环 DNS 解决方案可能非常有效。不幸的是，对于读/写或事务类型的服务（如电子邮件或数据库访问），除非一个节点上的服务的连接和会话信息可以被其他节点共享和使用，否则很难在集群上提供无缝负载均衡。这也将要求磁盘镜像接近瞬时，并使用大量的分布式锁定技术，而大多数守护程序在没有复杂修改的情况下不支持这些技术。为了避免这些缺点，我决定使用一种介于热备和网络级负载均衡之间的更简单的方法。

在我的双节点集群中，我将一半所需的服务放在节点“A”（serv1）上，另一半放在节点“B”（serv2）上。采用了相互故障转移配置，以便如果节点 A 发生故障，节点 B 将接管其所有服务，反之亦然。

我们必须决定哪些服务需要在整个集群上运行。这涉及到相对评估每项服务将消耗多少计算资源。对于我们之前的 Linux 服务器，我们发现 Samba 和 Cyrus IMAP4 是资源消耗最多的服务，其次是 FTP、httpd 和 Sendmail。必须仔细考虑哪些服务适合在两个或多个节点上同时运行。此类服务的示例包括 Sendmail（仅用于发送邮件或作为中继）、bind、httpd、ftpd（仅下载）和 radius。无法以这种方式运行的服务的示例包括 Cyrus IMAP4、ftpd（上传）和 Samba。Samba 不能在两台服务器上同时运行，因为这会导致两台服务器在同一 LAN 上广播相同的 netbios 名称。使用当前稳定版本的 Samba 尚无法实现 PDC/BDC（主域控制器和备份域控制器）安排。另一方面，简单网站上的页面不会经常更改。因此，镜像非常有效，并且并行 Web 服务器可以非常愉快地运行而不会出现重大问题。服务器配置为每个服务器主要负责一组特定的服务。我将 Samba 放在 serv1 上，将 Cyrus IMAP4 放在 serv2 上。其他服务以类似的方式共享；httpd、bind 和 radius 在两个节点上同时运行。

在发生节点故障时，另一个节点会接管故障节点的所有服务，从而最大限度地减少对网络用户的中断。这是通过使用 IP（互联网协议）和 MAC（强制访问控制）地址接管从故障节点到接管节点上未使用的以太网卡来实现的。实际上，该节点对于网络用户而言将同时显示为 serv1 和 serv2。

首选使用 MAC 地址接管，以避免客户端的 ARP（地址解析协议）缓存仍然将旧 MAC 地址与 IP 地址关联的潜在问题。在我看来，MAC 地址接管比仅 IP 接管更简洁、更无缝，但不幸的是，它有一些可扩展性限制。

在考虑 HA 网络设置时，消除所有可能的单点故障非常重要。我们之前的服务器有许多单点故障；机器本身、网线、以太网集线器、UPS 等。不胜枚举。网络的设计旨在经济高效且可靠，如图 1 所示。

图 1. 我们的两个节点的网络图

网络图显示了每台服务器中的三个网络接口卡 (NIC)。每台服务器中的第一个 NIC 用于客户端的主要 LAN 访问。每个节点都插入单独的以太网交换机或集线器，以便在交换机锁定或故障时提供冗余。（这种情况不久前实际上发生在我们身上。）第二个 NIC 用于使用简单的交叉 100BaseTX 全双工以太网电缆创建专用节点间网络。交叉电缆比插入以太网集线器或交换机的两条电缆更不容易发生故障。此链路主要用于磁盘镜像流量和集群心跳。它还有助于减轻主接口的网络流量负载，并在节点之间提供冗余网络路径。第三个 NIC 是冗余 LAN 访问卡，用于在集群中发生远程节点故障时进行 MAC 和 IP 地址接管。同样，它们也插入不同的以太网交换机或集线器，以提高网络可用性。

如果节点以某种方式发生故障，则至关重要的是只有一个节点执行 IP 和 MAC 地址接管。确定集群中哪个节点发生故障说起来容易做起来难。如果在使用简单接管算法时心跳网络发生故障，则两个节点都将错误地执行 MAC、IP 和应用程序接管，并且集群将被分区。这将在任何 LAN 上造成重大问题，并可能导致某种网络和服务器死锁。防止这种情况发生的一种方法是使首先检测到远程节点故障的节点远程登录到该远程节点的每个接口，并将其置于待机运行级别（例如，单用户模式）。此运行级别将阻止故障节点尝试重新启动自身，从而停止无休止的故障恢复循环。此方法存在问题。如果节点 A（具有故障 NIC）认为节点 B 没有响应，然后远程将节点 B 置于单用户模式怎么办？最终您将没有服务器可用于 LAN。必须有一种机制来决定哪个节点实际上发生了故障。在双节点集群上执行此操作的少数方法之一是依赖第三方。我实现此方法的方式是使用可以在 LAN 上 ping 通的本地可访问设备列表。通过仲裁过程，检测到无法访问设备数量最多的节点将优雅地放弃并进入待机运行级别。如图 2 所示。

图 2. 显示集群守护程序算法概述的流程图

为了以最小的数据丢失风险实施此解决方案，必须不断镜像两台服务器上的数据。理想情况下，写入 serv1 的数据应同时写入 serv2，反之亦然。实际上，近乎完美的镜像需要大量的内核实现，并且沿途存在许多障碍，例如文件系统性能和分布式锁管理。一种方法是实现使用来自不同节点的磁盘的 RAID 镜像：集群文件系统。据推测，在 2.1 的更高版本中，可能在 2.2 内核中，通过使用 md、NFS 和网络块设备来实现这一点。另一种解决方案（也有待评估）是使用 CODA 分布式文件系统。

在每个节点上拥有数据镜像的一种实用方法是允许管理员预定义文件镜像的频率，不仅针对节点，而且针对每个文件或目录。通过这种细粒度的控制级别，特定文件、目录或应用程序的数据易失性特征可以反映在镜像到集群中另一个节点的频率中。例如，快速变化的数据（如 IMAP4 电子邮件假脱机），用户不断移动、阅读和删除电子邮件，可以每分钟镜像一次，而变化缓慢的数据（如公司的大多数静态网页）可以每小时镜像一次。

以这种方式镜像数据时，必须考虑权衡。一个主要的权衡是镜像完整性与 CPU 和 I/O 资源消耗。如果我可以每秒镜像一次我的 IMAP4 邮件假脱机，那就太好了。实际上，这是行不通的，因为服务器每次同步此假脱机需要 15 秒。CPU 和磁盘 I/O 使用率可能非常高，以至于服务会明显减速。这似乎有悖于高可用性的目标。即使 CPU 有资源在不到一秒的时间内读取磁盘，由于网络吞吐量瓶颈，在节点之间传输数据更改可能仍然存在问题。

这种镜像方法确实存在缺陷。如果文件保存到 serv1 上的 Samba 文件共享中，并且 serv1 在镜像之前发生故障，则该文件将保持不可用状态，直到 serv1 完全恢复。在最坏的情况下，serv1 文件系统将被损坏，并且文件将永远丢失。但是，与使用备份磁带的单台服务器相比，这种情况的风险较小，因为传统备份的频率远低于集群中的镜像频率。当然，集群不能替代传统备份，传统备份对于许多其他原因仍然至关重要。

一个主要的设计因素是在故障节点恢复后重新同步（镜像回）文件。必须采用可靠的程序，以便在故障期间在故障转移节点上已更改的数据镜像回原始节点，并且不会丢失，因为原始节点会在恢复过程中覆盖或删除它。重新同步程序的实施应确保在一个节点接管其服务时，该节点无法执行任何镜像。此外，在原始节点上重新启动服务之前，必须将与其关联的所有文件完全镜像回此原始节点。必须在两个节点上的服务都处于脱机状态时完成此操作，以防止服务写入正在恢复的文件。未能防止这种情况可能会导致数据损坏和丢失。

使用此解决方案的主要问题是 IMAP4 和 pop3 邮件假脱机。如果收到电子邮件并将其传送到 serv2，并且 serv2 在镜像发生之前发生故障，则 serv1 将接管邮件服务。后续邮件消息将到达 serv1 的邮件假脱机中。当 serv2 恢复时，在故障发生前收到的任何电子邮件都将被 serv1 上收到的新邮件覆盖。解决此问题的最佳方法是将 Sendmail 配置为将其邮件副本排队以传送到接管节点。如果接管节点脱机，则邮件将保留在 Sendmail 队列中。一旦故障节点恢复，电子邮件消息将成功传送。此方法不需要镜像邮件假脱机和队列。但是，有必要在两个节点上都有两个可用的 Sendmail 配置：一个配置用于正常操作，另一个配置用于节点接管操作。这将防止邮件在两台服务器之间来回弹跳。

我不是 Sendmail 专家。如果您知道如何配置双队列 Sendmail 传递，请告诉我。这部分仍在进行中。作为临时措施，我在重新同步邮件假脱机时创建备份文件，并在节点恢复时进行手动检查，这非常耗时。我还通过尽可能频繁地镜像邮件假脱机来防止此类困难。这有一个不幸的临时副作用，即使我的硬盘超负荷工作。在集群数据库服务时也会遇到类似的问题。但是，一些大型 UNIX 数据库供应商现在正在提供其产品的 并行 版本，这使得能够在集群中的多个节点上同时运行。

节点可能因各种原因而发生故障，从导致挂起或重新启动的操作系统崩溃到可能导致节点进入待机模式的硬件故障。如果系统处于待机模式，则不会自动恢复。管理员必须手动删除待机锁定文件并在故障节点上启动运行级别 5，以向集群的其余部分确认问题已解决。如果操作系统挂起，这将与待机运行级别具有相同的效果；但是，如果按下复位按钮或系统重新启动，节点将尝试重新加入集群，因为不会存在待机锁定文件。当节点尝试重新加入集群时，另一个节点将检测到恢复并停止所有集群服务，同时进行磁盘的重新同步。完成此操作后，将重新启动集群服务，并且集群将再次完全运行。

我选择的 Linux 发行版是 Intel 平台上的 Red Hat 5.1。但是，没有理由不能将其应用于其他 Linux 发行版。该实现纯粹在用户空间中。不需要特殊的驱动程序。为了有效地部署此系统，需要一些基本先决条件

我的系统由两台 Dell PowerEdge 2300 服务器组成，每台服务器都配备

图 3. 双节点集群的照片

管理员可以通过在配置目录中创建小的镜像描述文件来配置一起镜像的文件组。请注意，目录条目必须以正斜杠 (/) 结尾。以下是我的 lpd 镜像的描述文件，/etc/cluster.d/serv1/Flpd

/var/spool/lpd/
/etc/printcap

然后，镜像频率由 /etc/crontab 文件中的条目控制。每个条目都执行 sync-app 程序，该程序检查指定的服务镜像描述文件并将内容镜像到指定的服务器 IP 地址。在此示例中，指定的服务器地址是 serv2 上的交叉电缆 IP 地址。lpd 系统的镜像每小时完成一次。这些 crontab 条目来自 serv1

0,5,10,15,20,25,30,35,40,45,50,55 * * * * root \
/usr/local/bin/sync-app /etc/cluster.d/serv1/Fsmbd \
serv2-hb
0 * * * * root /usr/local/bin/sync-app \
/etc/cluster.d/serv1/Flpd serv2-hb

系统的核心在于集群守护程序 clusterd。这是用 Bourne shell 编写的，很快将用 C 重写。算法概要以流程图形式显示在图 2 中。

clusterd 持续监控集群中另一个节点的 ICMP（互联网控制消息协议）可达性，以及通常可以从每个节点访问的主机列表。它使用简单的 ping 机制和超时来执行此操作。如果另一个节点变得甚至部分无法访问，clusterd 将通过计算每个节点可以访问的列表中的主机数量来确定哪个节点实际发生故障。可以访问最少主机的节点是进入待机模式的节点。clusterd 然后将在工作节点上启动故障转移和接管过程。然后，此节点继续监控故障节点是否恢复。当它确实恢复时，clusterd 控制重新同步过程。clusterd 在每个节点上作为以下项调用

clusterd <local-nodename> <remote-nodename>

它必须知道哪些应用程序和服务在每个节点上运行，以便它知道在故障转移和接管时启动和停止哪些应用程序和服务。这在与前面讨论的服务镜像描述文件相同的配置目录中定义。每个节点中的配置目录是相同的，并且在整个集群中镜像。这使集群管理员的生活更轻松，因为他可以从单个指定节点配置集群。在 /etc/cluster.d/ 目录中，每个集群节点都存在 nodename.conf 文件和 nodename 目录。reachlist 文件包含 LAN 上可访问的外部主机列表。我的 /etc/cluster.d 目录的内容如下所示

[root@serv1 /root]# ls -al /etc/cluster.d/
total 8
drwxr-xr-x  4 root root 1024 Nov 15 22:39 .
drwxr-xr-x 23 root root 3072 Nov 22 14:27 ..
drwxr-xr-x  2 root root 1024 Nov  4 20:30 serv1
-rw-r--r--  1 root root  213 Nov  5 18:49 serv1.conf
drwxr-xr-x  2 root root 1024 Nov  8 20:29 serv2
-rw-r--r--  1 root root  222 Nov 22 22:39 serv2.conf
-rw-r--r--  1 root root   40 Nov 12 22:19 reachlist

以字母 F 开头的文件是服务镜像描述文件。以 S 和 K 开头的文件链接到 SysVinit 启动/停止脚本，其行为方式类似于 SysVinit 运行级别中的文件。当节点 serv1 处于正常运行时，启动 S 服务。当节点 serv1 停止服务时，终止 K 服务。S 和 K 后面的数字确定启动和停止服务的顺序。clusterd，在节点 serv2 上运行，使用相同的 /etc/cluster.d/serv1/ 目录来决定在节点 serv1 发生故障时在 serv2 上启动哪些服务。它还使用 serv1 服务镜像描述文件（那些以 F 开头的文件）来确定在 serv1 恢复后需要镜像回（重新同步）哪些文件和目录。

节点 serv2 的配置目录包含 Fftpd、Fhttpd、Fimapd、Fsendmail、K60sendmail、K80httpd、K85named、K90inetd、S10inetd、S15named、S20httpd 和 S40sendmail。如您所见，serv2 节点通常运行 Sendmail、named、httpd、IMAP4 和 ftpd。

每当需要启动或关闭网络接口时，我都使用了 Red Hat 提供的 ifup 和 ifdown 脚本。这使得网络接口配置与 GUI 网络配置工具更紧密地集成。节点配置文件 /etc/cluster.d/nodename.conf 允许您指定每个集群节点上的以太网 NIC 及其用途。我的两个节点配置文件如列表 1 和 2 所示。

列表 1. serv1 配置文件

列表 2. serv2 配置文件

为了实现 MAC 地址接管，必须对 Red Hat 以太网配置文件进行一项重要补充。您必须在 /etc/sysconfig/network-scripts/ifcfg-eth2 文件中添加一行来设置 MAC 地址。在我的示例中，eth2 是冗余接口，因此我需要它接管集群中另一个节点上主服务接口的 MAC 地址。换句话说，serv2 上 eth2 的 MAC 地址必须与 serv1 上 eth0 的 MAC 地址相同。行“MACADDR=00:10:4B:63:1C:08”已附加到节点 serv2 上的此文件中。Red Hat ifup 命令将在启动接口时使用此变量。必须对每个节点进行类似的修改。

如果您使用以太网交换机（而不是集线器），则有必要将 MAC 地址缓存超时设置为合适的期限，以避免在 MAC 地址接管后集群失去与 LAN 客户端的通信。我将直接连接到节点的端口的超时设置为 20 秒。如果您需要有关如何执行此操作的信息，请查阅您的交换机手册或供应商。通常可以通过控制台电缆完成此操作。

我为 /etc/hosts、passwd/group 文件和整个 /etc/clusterd/ 目录创建了服务镜像描述文件和 crontab 条目，以便我可以从单个节点管理集群。这大大简化了集群配置。为了避免混淆，我发现为集群上使用的每个服务创建一个 DNS 别名很有帮助，该别名指向该服务的主节点。因此，当我需要配置 Samba 时，我需要做的就是远程登录到 samba.yourdomainname.com。如果错误地配置了服务的辅助节点，则在主节点发生故障之前，任何更改都将被忽略。

目前，对于我的系统，集群中只能有两个节点。将此扩展到两个以上节点的集群应该不难，尽管由于大型集群需要大量 NIC，因此可能必须使用不同的方法而不是 MAC 地址接管。

几个有用的实用程序使我能够进行高效的镜像。rsync 是一个非常宝贵的实用程序，它使用 rsync 算法。此程序将查找文件中的更改，并且仅镜像已更改的部分，而不是整个文件。它还会通过检查修改日期和文件大小来检查文件是否已更新，然后再进行任何进一步的比较。ssh（安全外壳）也可以在节点之间与 rsync 结合使用，以便通过加密和身份验证的连接发送镜像数据。或者，如果您愿意，可以使用 rsh。

当 rsync 进行文件比较时，它使用文件的日期和时间；因此，至关重要的是，所有节点都同意同一时间。我选择每小时从 cron 运行 netdate 实用程序。节点使用受信任的远程时间源列表。为了确保故障节点以正确的时间启动，CMOS PC 时钟在运行 netdate 后更新。

rsync 经过配置，可以删除源目录中目标目录不存在的文件。此行为对于避免目标节点上累积和过度磁盘使用是必要的。 如果不使用此设置，连接到 Samba 文件共享的用户实际上将无法删除镜像节点上的任何文件。 几乎所有应用程序的情况都是如此。clusterd 配置为在重新同步过程进行时创建已删除或已更改文件的备份。 这有助于最大程度地降低在节点接管之前镜像发生故障时数据丢失的风险。 后续删除备份文件将需要一些人工干预，这将在确认文件或数据在节点恢复后未丢失之后进行。 这是使用 rsync 2.2.1 版本的 --backup 选项完成的。 您可能会发现关闭 rsync 算法并完全镜像已更改的文件而不是镜像更改内容效率更高； 但是，这将占用更多网络带宽。

重新同步（反向镜像）过程是使用 rsync 实现的，rsync 使用锁定文件来禁止在检测到节点故障时镜像到另一个节点。 在镜像任何文件之前，sync-app 会检查锁定文件是否存在。 这可以防止节点 A 镜像到节点 B，而节点 B 同时将相同的文件镜像到节点 A。

如果需要，clusterd 可以与共享和/或分布式存储设备一起使用，方法是删除重新同步功能并且不使用 sync-app，尽管我没有尝试过。

为了测试服务器故障，我必须模拟集群上每个接口的故障。 在每种情况下，集群都采取了预期的操作并关闭了正确的服务器。 在节点间/心跳网络发生故障的情况下，节点只是继续正常运行并通知管理员故障。 在这种性质的点对点网络上，几乎不可能确定哪个 NIC 出现故障。 我模拟了各种网络交换机故障和电源故障。 结果均如预期。 在节点进入待机（单用户）模式后，我必须手动删除待机锁定文件才能完全启动节点。 如果节点在待机锁定文件仍然存在的情况下恢复并进入网络运行级别，则远程节点会立即将该节点放回待机模式，以防止 LAN 上出现 IP 和 MAC 地址冲突。

镜像经过了几个月的测试，我发现节点通常可以在不到 45 秒的时间内比较大约 50,000 个文件中的 6GB 未更改数据。

在灾难性节点故障（我拔掉了 UPS 的电源插头）之后，节点的恢复时间约为 10 到 15 分钟用于 fsck 磁盘检查，磁盘重新同步时间约为三分钟（9GB 数据）。 这表示集群服务对 LAN 客户端的停机时间约为三分钟。

从节点发生故障到远程节点完全接管的故障转移延迟通常为 60 到 80 秒。 对用户的影响取决于服务：Sendmail、IMAP4、http 和 FTP 只是在持续时间内拒绝用户的连接，而 Samba 有时会在文件在故障点打开时短暂锁定 Windows PC 应用程序。radius 和 dhcpd 没有引起客户端锁定，可能是因为它们的 UDP 实现。

总的来说，该集群为我们提供了更好的系统可用性。 与单服务器相比，这是一个巨大的改进，因为我们现在可以在工作时间内进行服务器维护和升级。 我们的新型戴尔服务器尚未发生任何灾难性故障，但测试结果表明，节点接管时的最短停机时间不到两分钟。 通过实施简单的高可用性集群，而无需昂贵的专用硬件（如双端口 RAID），我们节省了大量资金。

这种集群解决方案当然不如某些商业集群先进，也不如某些即将推出的开源 Linux-HA 项目提案那样彻底； 但是，它确实充分满足了我们的需求。

该系统自 1998 年 9 月以来一直在全职生产运行。我们有超过 30 个 LAN 客户端将该集群用作其主要“服务器”。 该系统已被证明是可靠的。 公司将该服务器视为业务关键型系统，我们已经实现了高可用性的目标。