SAP灾难恢复：技术和最佳实践

SAP灾难恢复：技术和最佳实践

在《企业时报》文章SIOS 合作伙伴联盟总监 Harry Aujla 探讨了为何灾难恢复 (DR) 在保护 SAP 环境和确保业务连续性方面应与高可用性 (HA) 同等重要。他阐明了 HA 和 DR 之间的区别，强调 HA 旨在确保系统在局部故障期间持续运行，而 DR 则侧重于在网络攻击或自然灾害等重大事件发生后恢复业务运营。

本文概述了灾难恢复投入不足所带来的业务、财务和监管风险，并引导读者了解两种核心恢复模型：站点级恢复和应用级恢复，重点介绍了每种模型的优势、权衡取舍和成本考量。Aujla 总结道，SAP 灾难恢复没有一成不变的模式，他敦促各组织根据业务优先级、服务级别要求和停机容忍度来制定策略，从而构建一个具有弹性和实用性的恢复计划。

经许可转载SIOS

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

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

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