为高可用性和灾难恢复而设计

为高可用性和灾难恢复而设计

IT 基础设施中的设计驱动型创建、工具和冲突设计模式

当设计驱动创造时，成果便易于沟通。以设计为先导的理念能够创造出便于个人有效培训的解决方案。运用设计原则来传达目标，可以带来易于维护和改进的解决方案。当然，当解决方案基于工具构建时，工具的设计使用方式必须与它所支持的解决方案的设计结合起来考虑。

所选工具会将它们的设计假设强加于使用它们的项目中。正如之前的相关博客文章所述设计理念和目标一致是创建易于理解的解决方案的第一步。当然，项目中使用的工具可能包含与项目设计理念格格不入的模式。

初始设计与所用工具之间的冲突会造成复杂性，并降低解决方案的有效性。因此，必须选择合适的工具，使其使用与项目设计保持一致。当工具与设计协调一致时，复杂性就会降低。在高可用性和灾难恢复的背景下，设计与所用工具协调一致的影响尤为显著。

高可用性和灾难恢复设计被认为是一项复杂的工作。

高可用性和灾难恢复设计通常预设了复杂性。IT基础设施设计模式为了满足高可用性和灾难恢复固有的高标准，各个基础设施组件越来越需要尝试在各自的范围内实施相应的模式。

各个组成部分共同努力解决以下问题：高可用性和灾后恢复就其作用而言，由于组件采用不同的设计原则来解决高可用性和灾难恢复问题，环境必然会变得臃肿。

基础设施通常需要采用多种设计模式

工具不断发展，并可能形成相互竞争的设计原则，然而，环境需要的是具有凝聚力的设计。随着原本互不相关的工具开始相互干扰，复杂性也渗透到基础设施中。随着IT系统在用途和可用性标准方面的不断提升，遵循凝聚力设计并实现互补工具的基础设施的重要性也日益凸显。技术进步为实现高可用性和灾难恢复提供了多种策略，IT基础设施也在不断发展，以适应针对其他用例量身定制的设计模式。只需看看……常见的云设计模式微软在其文档中发布了这些模式。每种模式的适用性显而易见，但模式之间也可能存在冲突。模式重叠难以处理，这会使IT基础设施的设计过程变得复杂。基础设施通常需要采用多种设计模式，因此，越来越需要那些“互不干扰”的模式。

作者：Philip Merry – SIOS 软件工程师

经许可转载SIOS

高可用性环境中合理内存分配的重要性

高可用性环境中合理内存分配的重要性

合理的内存分配是任何系统中都至关重要但却常常被忽视的组成部分。高可用性 (HA) 环境当服务器出现内存分配问题时，其影响会波及整个集群，导致应用程序性能下降、复制速度减慢，甚至故障转移失败。在更严重的情况下，内存耗尽可能会中断 SIOS 工具，例如……DataKeeper 和 LifeKeeper这进一步增加了发生不可预测和意外行为的风险。了解内存对高可用性环境的影响是维持系统稳定性、性能和可预测故障转移行为的关键。

下面，我们将探讨为什么合理的内存分配至关重要，需要注意哪些症状，以及内存相关问题如何影响系统的可靠性。簇在 LifeKeeper/DataKeeper 环境中。

内存分配问题的常见症状

1. 复制停滞或意外镜像挂起/应用程序终止

内存不足最显著的影响之一是复制性能下降。诸如此类的产品数据保管员DataKeeper 依赖于对系统内存的持续访问来缓冲写入操作。当内存受限时，队列开始填充，复制速度减慢，在某些情况下，镜像可能因资源耗尽而挂起。这会导致重新同步操作耗时远超预期，尤其是在高写入速率的环境中。此外，DataKeeper 应用程序的非正常终止会导致某些进程未被监控/处理，从而在再次“启动”DataKeeper 服务时出现意外行为。

2. 应用程序响应缓慢或服务延迟

当系统内存不足时，操作系统可能会开始对活动进程进行分页或交换。在运行诸如以下应用程序的高可用性环境中：SQL Server这会导致查询速度变慢、响应延迟以及磁盘活动频繁，因为内存页需要不断移动。这些延迟通常会加剧故障转移时间，因为在故障转移事件期间，服务需要更长时间才能优雅地停止或重启。

3. 错误故障转移风险增加

高可用性解决方案依赖于节点间及时的心跳通信。当内存耗尽时，负责发送或处理心跳消息的线程可能会延迟。即使是很小的延迟也会导致原本健康的节点看起来无响应，从而造成不必要的资源浪费。故障转移或者，在最糟糕的情况下，裂脑事件。

4. 内核或系统日志显示内存压力

内存不足通常会导致特定的系统消息（Windows 或 Linux）。这些消息可能包括可用内存不足的警告、页面调度活动激增，或者操作系统终止进程以回收内存。对于运行复制驱动程序或高可用性 (HA) 服务的系统，这些警告通常预示着更严重的问题即将出现。

5. 虚拟或云环境中的性能不可预测

在虚拟化环境中，即使虚拟机报告“可用”内存，也可能出现内存问题。像虚拟机管理程序这样的VMware，Hyper-V， 或者云平台可能会通过诸如内存气球或过度分配等技术来限制内存访问。这会悄无声息地影响虚拟机性能，导致复制延迟、心跳问题等，且难以找到问题的根本原因。

用于诊断高可用性环境中内存分配问题的工具

• 性能监视器/任务管理器（Windows）可用于识别内存压力、页面调度活动和进程级内存消耗。重点关注：高度已提交内存值。
  • 大量页面文件使用
  • 进程占用过多内存
• 使用事件查看器（Windows）或 journalctl / dmesg（Linux）查看系统日志，内存压力通常会在系统日志中留下线索。请注意以下信息：
  • “内存不足”警告
  • 内存分配失败
  • 复制驱动程序警告，表明资源已耗尽
• top、htop 或 free（Linux）这些工具可以揭示内存饱和度、交换空间使用情况以及使用不成比例的 RAM 的服务。
• Hypervisor 工具（vSphere (VMware) / Hyper-V Manager (Hyper-V) / Cloud Platform Managers）这些工具可以识别因缺乏可用但所需的内存而导致的内存膨胀、交换、主机级争用或过度分配。

何时重新评估内存分配？

在以下情况下，您可能需要增加或调整内存分配：

• 复制过程经常进入暂停状态或在高负载下挂起。
• 在工作负载高峰期，分页或交换成为一种常见的模式。
• 您的应用程序服务器（例如 SQL Server）经常占用大部分可用内存。
• 集群会间歇性地发生故障转移，但没有出现底层硬件故障。
• 您当前在云端或虚拟环境中运行，可能会出现主机争用。
• 您在系统中看到了“资源耗尽”事件日志。
• 关键服务意外终止

在 HA 环境中，内存不仅仅用于提升性能；它还有助​​于确保可预测的故障转移行为，并防止级联服务中断。

为什么合理的内存分配是高可用性可靠性的关键

内存压力几乎会对高可用性 (HA) 环境的每一层都产生负面影响，从复制驱动程序到应用程序性能和故障转移时间。合理的内存分配有助于确保可预测的性能、稳定的集群通信以及故障转移发生时的可靠恢复。通过主动监控和规划内存使用情况，组织可以……避免不必要的停机时间并维持其系统所需的高可用性。如果内存分配问题影响了高可用性性能或故障转移行为，申请SIOS演示看看我们如何才能帮助提高可靠性。

作者：Aidan Macklen，SIOS Technology Corp. 的助理产品支持专家。

经许可转载SIOS

企业采用灾难恢复即服务 (DRaaS) 解决方案的主要原因

在当今快节奏的数字化环境中，企业高度依赖数据和技术来维持运营顺畅。然而，随着威胁的日益增加，网络攻击、硬件故障和自然灾害如今，企业面临的停机和数据丢失风险从未如此之大。为了更好地应对这些挑战，许多公司正在转向灾难恢复即服务 (DRaaS) 解决方案。

什么是灾难恢复即服务 (DRaaS)？

您可能想知道，DRaaS 究竟是什么？其实，顾名思义，它是一种基于云的服务，允许企业将数据和应用程序备份到第三方提供商。DRaaS 与备份即服务 (BaaS) 的一个关键区别在于：DRaaS 包含完整的底层架构，可以快速故障转移到云环境，而传统的 BaaS 仅备份数据本身。

企业为何转向灾难恢复即服务 (DRaaS) 解决方案

那么，为什么企业要采用这种方法呢？灾难恢复其中一个最重要的原因是成本。传统的灾难恢复方案通常需要对备用数据中心或硬件进行大量投资，以及相应的维护费用。而灾难恢复即服务 (DRaaS) 通过提供基于云的订阅模式，消除了这些支出，使企业只需为所需的资源付费。这使得企业级灾难恢复更具成本效益，即使对于中小企业而言也是如此。

采用灾难恢复即服务 (DRaaS) 的主要优势

推动企业采用灾难恢复即服务 (DRaaS) 的另一个主要因素是其可扩展性和灵活性。随着企业发展壮大、业务转型以及数据需求不断变化，DRaaS 解决方案能够帮助企业轻松地扩展或缩减资源，而无需进行重大的基础设施变更。这种适应性确保了恢复计划能够随着业务目标的实现而不断演进。

灾难恢复即服务 (DRaaS) 还提供更快的恢复时间。最大限度减少停机时间通过自动故障转移和持续数据复制，可以快速恢复运行，减少潜在的经济损失，并将声誉损失降至最低。

此外，增强的安全性和合规性使灾难恢复即服务 (DRaaS) 成为极具吸引力的选择。领先的 DRaaS 提供商会实施先进的安全措施，例如严格的加密、监控和更新，以保护数据并符合行业标准。随着勒索软件和其他网络威胁的日益猖獗，DRaaS 增加了一层至关重要的保护，即使在遭受网络攻击后也能恢复数据。

灾难恢复即服务 (DRaaS) 解决方案如何支持业务连续性和恢复力

归根结底，采用灾难恢复即服务 (DRaaS) 不仅仅是为了灾难恢复，更是为了构建韧性。投资 DRaaS 的公司展现了其积极主动地保护数据、维护客户信任以及确保业务不间断运行的决心，无论面临何种挑战。

SIOS Technology 提供的灾难恢复即服务 (DRaaS) 和高可用性解决方案

在SIOS 技术我们深知，每一分钟的停机时间都可能对业务造成持久影响。我们功能强大的云就绪型灾难恢复和高可用性解决方案旨在实现无缝保护、快速恢复，并让您完全安心。无论是在云端、本地还是混合环境中运行关键工作负载，SIOS 都能提供所需的可靠性和性能，确保关键业务持续运行，不受任何突发情况的影响。

申请演示今天就来了解 SIOS 如何加强您的灾难恢复即服务 (DRaaS) 策略并保护您的关键系统。

作者：Cassy Hendricks-Sinke，SIOS首席软件工程师

经许可转载SIOS

使用 SIOS LifeKeeper 对非集群感知应用程序进行集群化

使用 SIOS LifeKeeper 对非集群感知应用程序进行集群化

并非所有应用程序都是用这种方法构建的。聚类牢记这一点。事实上，大多数人并没有。但这并不意味着他们无法从中受益。高可用性由……提供的保护SIOS LifeKeeper如果你的应用程序可以停止、启动并在另一台服务器上运行，那么很有可能可以对其进行集群部署。

在着手实施之前，有一些关键的考虑因素，这些因素将决定集群实施是成功还是令人沮丧的反复试验。

1. 将动态数据迁移到共享或复制存储

应用程序通常将日志、数据库、缓存和其他应用程序数据等动态数据存储在本地存储中。但在集群环境中，这种方式行不通。故障转移备用节点必须能够访问相同的数据，以便应用程序可以从上次中断的地方继续运行。

解决方案是将所有动态数据迁移到 SAN 环境中的共享磁盘或使用时的复制卷。SIOS 数据保管器静态文件（例如可执行文件）可以保留在本地，但任何在运行时发生变化的内容都应该存储在所有集群节点都可以访问的存储位置。

2. 更新集群环境中的应用程序主机引用

许多应用程序通过名称、FQDN 或 IP 地址来引用本地系统。这在独立配置中没有问题，但在集群中，应用程序需要绑定到集群的虚拟 IP (VIP) 或通过其进行通信。

如果应用程序或其配置文件引用了：

• 本地主机
• 节点的主机名或完全限定域名
• 节点的静态 IP 地址

您可能需要更改对 VIP 或解析到 VIP 的主机名的引用。通常需要检查的位置包括注册表项、配置文件以及应用程序用于连接自身或其他服务的任何连接字符串。

3. 编写自定义启动、停止和监控脚本

集群感知型应用程序包含指示集群如何启动、停止和监控服务的逻辑。非集群感知型应用程序则不包含。这就是 SIOS LifeKeeper 应用程序恢复工具包 (ARK) 的用武之地。

如果你的应用程序没有现成的脚本，你可以创建自定义脚本：

• 开始服务或流程
• 停止切换前将其清理干净
• 监视器例如，通过检查端口、日志文件或进程来评估其健康状况。

在某些情况下，保护应用程序就像启动和停止服务一样简单。针对这种情况，LifeKeeper 提供了快速服务保护 (QSP) 恢复工具包。使用 QSP，您只需选择要保护的服务，无需编写任何代码。LifeKeeper 将自动处理该服务的启动、停止和监控操作。

这些选项使得保护各种应用程序变得轻松便捷，从简单的应用程序到复杂的应用程序。视窗或者Linux在同一集群框架内，为复杂的多组件系统提供服务。

4. 在所有集群节点上正确处理加密密钥

如果您的应用程序对静态数据进行加密，则集群中的每个节点都必须能够解密这些数据。这意味着加密密钥必须在所有节点上都可访问且保持一致。根据您的设置，这可能需要同步本地密钥库或使用集中式密钥管理解决方案。

关键在于，每个节点在激活时都必须能够安全且持续地访问加密密钥。否则，应用程序可能启动，但在故障转移后却无法访问其数据。

5. 考虑故障转移后客户端如何重新连接

当应用程序从一个节点故障转移到另一个节点时，会有一个短暂的中断，因为新的活动节点需要接管 IP 地址并启动应用程序。对于连接到该服务的客户端，其行为完全取决于它们如何处理连接丢失。

如果客户端内置了重试逻辑，用户可能根本不会注意到中断。一旦VIP和服务恢复可用，客户端将自动重新连接。

如果客户端没有包含重试逻辑，用户在故障转移后可能需要手动刷新或重新启动连接。

了解客户端的行为方式并测试其在故障转移期间的响应至关重要。有时，只需添加一个简单的连接重试循环或调整连接超时设置，即可实现流畅的用户体验。

6. 验证集群部署的应用程序许可要求

一个常被忽视的步骤是许可。当应用程序集群化时，它会安装在集群中的每个节点上，但一次只能运行一个实例，即活动实例。一些供应商提供专门的活动/被动集群许可，而另一些供应商则要求每个已安装的实例都需要一个许可。

部署前务必先咨询应用程序供应商。事先进行简短沟通可以避免日后花费大量时间处理许可问题。

7. 对所有应用程序和集群组件进行全面测试

测试是任何集群项目中最重要但又最容易被忽视的环节之一。

不要只测试故障转移。在应用程序受到保护的情况下，测试其所有功能。这包括：

• 启动和关闭顺序
• 所有必需的服务和后台任务
• 任何读取、写入或缓存数据的组件
• 任何依赖于服务依赖项的进程
• 故障转移前、故障转移期间和故障转移后的客户端行为

如果应用程序使用自定义脚本或快速服务流程 (QSP)，请确保每个步骤在负载下都能正常运行。这不仅能及早发现问题，还能确保解决方案在实际事件中能够正确运行。

为非集群感知应用实现高可用性

使用 SIOS LifeKeeper 对非集群感知应用程序进行集群化并不难，但确实需要一些规划。将数据迁移到共享或复制存储，将所有节点指向集群的虚拟 IP 地址 (VIP)，编写启动、停止和监控逻辑脚本（或在适当情况下使用 QSP），确保所有节点上都可用加密密钥，并确认许可要求。

不要忘记测试您的客户端对故障转移的响应情况，因为真正的高可用性意味着您的服务器和用户始终保持连接。

按照这些步骤操作，您会发现即使是最“独立”的应用程序也能实现企业级高可用性。立即申请演示了解 SIOS LifeKeeper 如何为非集群感知应用程序带来可靠的高可用性。

作者：David Bermingham，SIOS 高级技术推广专家

经许可转载SIOS

99.99% 正常运行时间：平衡高可用性和维护

99.99% 正常运行时间：平衡高可用性和维护

“99.99% 正常运行时间”，通常被称为“四个九”，代表系统 99.99% 的时间都可用，每年仅允许约 52 分钟的停机时间。对于任何规模的组织而言，这都是一个“黄金”标准，旨在提供可靠的服务，最大限度地减少对用户的干扰。

达到四个九（99.99%）表明在该领域持续投入高可用性这对于电子商务等行业至关重要。卫生保健， 和金融停机可能会导致重大经济损失或客户信心受损。

然而，要维持这种级别的可靠性，核心挑战在于：如何在保证高可用性的同时，兼顾“强制性”的系统维护。系统需要更新，修补为了保持安全和持续运行，需要进行升级，但这些活动通常需要停机。

组织必须努力维持冗余等策略，故障转移/切换并通过滚动更新进行维护，确保正常运行时间不受影响。在这种平衡下，对于在竞争激烈的市场中维持客户信任和提供稳定可靠的服务至关重要。

什么是 99.99% 正常运行时间？为什么它如此重要？

作者：Alexus Gore，SIOS Technology 的客户体验软件工程师

正常运行时间正常运行时间代表服务可用且功能正常的时长。正常运行时间为 99.9% 的服务每年平均会有 8.77 小时的停机时间。如果一家医院的正常运行时间为 99.95%，这意味着每年将有 4.38 小时无法访问患者数据，从而延误患者的治疗，这显然不是理想的情况。

99.99% 的正常运行时间是金融、医疗保健、SaaS 等行业的常见基准，这些行业理想情况下每年停机时间不超过 52.60 分钟。这一正常运行时间值也更容易实现，并且是成本可承受的最高正常运行时间。考虑到停机可能带来的风险，99.99% 的正常运行时间是确保停机时间最短的理想选择。

一个99.99% 服务水平协议保证每年停机时间不会超过最低停机时间。确保履行此协议有助于建立客户信任，因为这样可以保证服务随时可用。反过来，这将有助于维护客户群并确保业务连续性。

高可用性 (HA) 在实现 99.99% 正常运行时间中的作用

作者：比尔·达内尔，SIOS Technology公司高级产品支持工程师

高可用性是一种系统设计方法，旨在确保应用程序和服务始终可访问，目标是实现 99.99% 的正常运行时间。它基于冗余硬件、分布式软件和弹性网络配置等关键组件构建而成。其目标是消除单点故障，即使主服务器发生故障，也能确保业务持续运行。

SIOS软件通过使用以下方式实现HA簇（多台服务器）中，每个节点都能执行相同的功能。这些服务器通过两条或多条通信路径连接。这创建了一个容错环境，从而确保服务的连续性。LifeKeeper 通过持续检查服务器、应用程序和服务是否存在故障来监控系统健康状况。如果一台服务器或节点发生故障，LifeKeeper 会自动将操作转移到备用服务器，最大限度地减少停机时间。

SIOS 支持数据库保护（SQL Server，甲骨文，SAP HANA）、文件系统和自定义应用程序。

正常运行时间的隐性成本：为什么维护至关重要

作者：Cassy Hendricks-Sinke，SIOS Technology公司客户体验首席软件工程师

为了追求最大限度的正常运行时间，许多组织会延迟或跳过例行维护，这种做法可能目光短浅，甚至造成危险。忽略更新或补丁会使系统面临严重的安全漏洞，降低性能效率，并增加违规风险。每次延迟更新都会使公司更容易受到攻击，并累积难以长期管理的“技术债务”。

然而，真正的挑战在于平衡正常运行时间和必要的维护。企业往往害怕停机，却没有意识到忽视更新会导致更大的破坏，例如数据泄露或大规模停机。解决这个问题的关键在于积极主动的规划！滚动更新采用冗余策略，以及采用允许热修补或零停机时间部署的工具，都是应对或最大限度减少关键维护造成的停机时间的方法。

真正的正常运行时间不仅仅是保持“在线”状态；它还包括保持安全、高效和合规。投资于智能维护策略，不仅能确保系统可用，还能确保其具有弹性和可靠性。

平衡 99.99% 正常运行时间和维护的策略

作者：Philip Merry，SIOS Technology公司客户体验软件工程师

通常，系统维护需要停机，以便不间断地执行维护活动。显然，追求高正常运行时间与安排停机维护窗口之间存在冲突。为了满足正常运行时间的要求，延迟或批量进行维护可能会导致系统长时间处于故障状态，而频繁的维护窗口则会大幅降低系统可用性指标。尽管存在这些冲突，但可以通过采用高可用性策略来平衡这些考量。

SIOS LifeKeeper 是一款高可用性工具，它允许在执行工作负载的系统之间实现冗余。当一个系统正在积极执行工作负载并运行业务应用程序时，另一个系统可以作为备用系统，在发生故障时接管工作负载。这种“主备”高可用性模型提供了一种简便的方法来应对维护和更新，同时确保业务应用程序的连续性。

在 LifeKeeper 这类高可用性工具的背景下，平衡正常运行时间和维护工作，无论从概念上还是实践上都非常简单。首先对备用系统进行维护。维护完成后，让活动系统和备用系统切换角色。此时，活动系统已完成必要的维护，并正在运行业务应用程序。之后，可以再次对备用系统进行维护。维护完成后，所有系统都已完成维护，并且在维护期间工作负载仍然可用。LifeKeeper 实现的这种“高可用性更新”策略，使得系统能够在保持维护和可用性的同时，避免任何一方的损失。

支持正常运行时间和维护的工具和技术

作者：Connor Toohey，SIOS Technology 高级产品支持工程师

实现高可用性和零停机部署需要战略性地组合多种技术以达到最佳性能。SIOS LifeKeeper 和 DataKeeper 是关键解决方案，可提供强大的故障转移集群和实时性。数据复制为了确保应用程序和数据在云端、混合环境和本地环境中的可用性，Kubernetes 通过容器编排和自动滚动更新实现零停机部署。Azure 负载均衡器和 AWS 弹性负载均衡器等负载均衡器能够高效地分配流量，从而降低服务中断的风险。

Dynatrace 或 Moogsoft 等 AIOps 平台利用 AI 驱动的异常检测和自动化问题修复功能，增强了运维稳定性。Rancher、Red Hat Satellite 或 WSUS 等工具支持服务器补丁的滚动更新，从而实现零停机维护。Prometheus、Grafana、Datadog 和 Splunk 等监控和日志平台则提供对系统正常运行时间和性能的实时可见性。这些技术共同构建了一个弹性基础设施，确保不间断、可靠的服务交付。

保持 99.99% 正常运行时间的最佳实践

作者：Aidan Macklen，SIOS Technology公司助理产品支持工程师

要实现 99.99% 的正常运行时间，需要采取积极主动的系统管理方法。我们不应在问题发生后才被动应对，而应着重于在潜在风险影响服务可用性之前识别并解决它们。主动维护，例如定期查看日志、进行容量规划和硬件检查，可以确保小问题不会演变成服务中断。

在部署任何更新或配置更改之前，务必在受控的测试环境中进行测试。这有助于在模拟生产条件下验证兼容性、稳定性和性能，从而降低计划外停机的风险。同样重要的是，要维护清晰且文档完善的事件响应和回滚计划，以便在发生事件时能够高效地恢复正常运行。

高可用性系统也受益于持续优化。定期审核系统性能、故障转移效率和冗余配置，以确保所有组件均按预期运行。随着时间的推移，这些审核可以发现可能影响正常运行时间的瓶颈、配置偏差或性能不佳的节点。

通过优先考虑预防、严格的测试和结构化的恢复计划，组织可以维持 99.99% 的正常运行时间基准，并提供用户期望从现代高可用性环境中获得的可靠性。

99.99% 正常运行时间解决方案，助力持续运营

作者：Trey Isaac，SIOS Technology 高级产品支持工程师

每一分钟的停机都会造成企业收入损失、声誉受损，并削弱客户信任。虽然 99.99% 的正常运行时间是一个至关重要的基准，但这却是一场与必要的维护、补丁和更新需求的持续斗争。关键不在于仅仅追求一个运行时间数字，而在于构建智能弹性，以确保您的业务持续稳定运行。

SIOS 正是在此方面助力您实现运营转型。我们的高可用性和灾难恢复解决方案旨在保护您最关键的应用程序，包括 SQL Server、Oracle 和 SAP。SIOS 采用自动化、应用感知型故障转移和实时数据复制技术，确保您的业务在突发故障、意外中断和计划内维护等各种情况下都能保持全面运行。

无论您的基础架构位于本地、云端还是混合环境中，SIOS 都能提供您所需的无缝保护。告别被动应对停机，主动保障业务持续运营、客户信心不减、生产力永不停歇。

摘要：实现并保持 99.99% 的正常运行时间

作者：Matthew Pollard，SIOS Technology 高级客户体验软件工程师，业余卡祖笛演奏家

无论您从事何种业务，或依赖哪些应用程序，高可用性都是确保业务持续运行的通用理念。力争达到 99.99% 的正常运行时间，是提升基础设施可靠性的有效途径，进而赢得客户的高度信任。然而，实现如此高的正常运行时间并非易事，因此关键在于做好调研，并与经验丰富的 HA 解决方案供应商（例如 SIOS）合作，以满足您的需求。SIOS LifeKeeper 能够保护您的企业级关键业务应用程序（例如 SAP、Oracle、SQL Server 等）免受计划外中断和停机的影响，同时最大限度地减少例行补丁或维护活动所需的停机时间。从简单的备用节点恢复到更强大的灾难恢复配置，SIOS 解决方案为您提供所需的一切工具。

不要等到系统宕机或故障频发才开始寻找高可用性解决方案；要积极主动！我们的专家随时准备帮助您构建更安全、更强大的环境，轻松应对各种挑战。您的 IT 团队、业务领导、合作伙伴和客户都会为此感谢您。立即申请演示了解 SIOS 如何帮助您实现正常运行时间目标。

经许可转载SIOS