零售

零售

保护零售商免受停机和灾难的影响

信息是每个零售企业的命脉——与销售点相关的采购、销售和库存信息或有关客户偏好的实时信息。SIOS 集群软件为所有对零售企业重要的关键应用程序提供 HA/DR 保护。

跨所有环境的可靠应用程序保护

SIOS 为本地、云和混合云环境中运行的系统提供简单、经济高效的保护。我们的系统具有应用感知能力，可确保快速、可靠的集群故障转移，符合特定于应用程序的最佳实践。

SIOS 技术可保护您最重要的应用程序、数据库和操作系统免受计划外基础设施、网络和应用程序故障的影响。

零停机维护

对您的应用程序服务器进行持续维护，而不会中断您的业务。

经许可转载安全操作系统

制造的高可用性

制造的高可用性

SIOS 了解制造商在多大程度上依赖复杂的应用程序、ERP 和数据库来维护生产计划、管理供应链、控制仓库库存、协调运输以及执行各种其他重要业务运营。这些系统的停机每小时可能造成数千美元的损失，并导致运输延误、客户服务问题、安全问题、产品损失、生产力损失和供应链中断。SIOS 集群软件提供可靠、经​​济高效的高可用性和灾难保护，为在本地、云、混合云或多云环境中的 Windows 和 Linux 环境中运行的关键应用程序、ERP 和数据库提供 99.99% 的正常运行时间。

20 年工业制造 HA 经验

20 多年来，SIOS 帮助制造商为关键业务应用程序部署高可用性。我们屡获殊荣的客户服务团队对制造业特定的应用环境和要求拥有丰富的经验。

消除服务中断

与仅监控虚拟机或服务器操作的其他解决方案不同，SIOS 集群软件监控整个应用程序环境 – 网络、存储、操作系统、服务器和应用程序，以确保关键业务系统正常运行且可用。如果检测到问题，SIOS Protection Suite 软件会自动重新启动应用程序，从而加快恢复时间并消除 70% 以上的故障转移需求。如有必要，SIOS 软件会自动协调故障转移，完全符合特定于应用程序的最佳实践。

云、混合云和多云环境

将关键系统迁移到 Microsoft Azure、Amazon EC2 或 Google Cloud Platform，而无需牺牲高可用性或灾难恢复保护。将 SIOS DataKeeper 软件添加到 Windows Server 故障转移群集 (WSFC)，以创建 SANless 群集环境，而无需共享存储的成本和复杂性。使用适用于 Linux 的 SIOS Protection Suite 在 Linux 环境中实现完整的 SAN 或 SANLess 集群保护。

可靠、无差错集群的应用程序感知

SIOS 应用程序恢复套件 (ARK) 使 LifeKeeper 能够监控整个应用程序堆栈 – 网络、存储、操作系统、应用程序和服务器。他们还根据特定于应用程序的最佳实践来协调故障转移，以便在辅助节点上快速、可靠地运行。

SAP S/4HANA 认证

我们的产品经过 SAP 认证，并配备适用于 SAP 和 HANA 的独特应用程序恢复套件 (ARK)，以确保完全符合 SAP 最佳实践的可靠故障转移。强大的自动化和输入验证速度可实现无差错的集群配置，速度比基于 Pacemaker 的解决方案快五倍。

SIOS 拥有适用于 Windows 和 Linux 环境的集群解决方案 – 实现行业领先的 HA 配置灵活性。使用 SIOS 产品在同一配置中保护 Windows 上的 SAP ERS、ASCS 和其他服务以及 Linux 上的 SAP 和 HANA。

保护关键数据库 – SQL Server、Oracle、MaxDB

SIOS 集群软件为您提供运行关键业务数据库所需的高可用性保护，无论您在何处以何种方式运行这些数据库 – 在云或混合云环境中的 SQL Server、Oracle、MaxDB、MySQL。

经许可转载安全操作系统

医疗保健的高可用性

医疗保健的高可用性

保护医疗保健和生命科学的关键应用

医疗保健信息系统、ERS 和 EHS

SIOS 高可用性集群和复制软件可确保关键应用程序、数据库和 EHS 系统从基础设施、网络和应用程序故障中自动恢复，从而保持关键患者记录和其他数据受到保护、应用程序在线、满足法规要求以及用户高效工作。

本地、云、混合云

SIOS 使您能够灵活地在物理服务器、虚拟化服务器和云中为 Windows 或 Linux 环境构建 SAN 和 SANless 集群。在本地或灵活、可扩展的云环境（例如 Amazon Web Services (AWS)、Microsoft Azure 和 Google Cloud Platform）中运行业务关键型 EHR 应用程序，而无需牺牲性能或 HA/DR 保护。

轻松满足可用性 SLA 和 RTO/RPO

轻松地将受 Windows Server 故障转移群集保护的本地应用程序迁移到云端，而无需中断，或构建内置特定于应用程序的智能的 Linux 群集环境。跨云可用区或区域配置集群以实现最大程度的 HA/DR 保护，或创建混合云或多云配置以轻松满足可用性 SLA 和 RTO/RPO。

为关键 EHS 系统提供 HA

SIOS 产品可保护运行电子健康记录 (EHR) 应用程序的关键数据库免遭停机和数据丢失。Athena Health、Cerner Corporation、eClinicalWorks、Epic Systems、GE Healthcare、Greenway Health、Kareo、MEDITECH、McKesson、Xtelligent 等。

保护 Windows 应用程序和数据库

将 SIOS DataKeeper 添加到 Windows Server 故障转移群集环境中，以创建传统共享存储群集不可能或不切实际的 SANless 群集，例如云和混合云环境。快速、高效的基于主机的复制可同步所有集群节点上的本地存储，以实现最大的配置灵活性。或者，将复制添加到现有的基于 SAN 的 Windows 集群以进行灾难恢复。

使用 SIOS DataKeeper Cluster Edition 软件在物理、虚拟或云环境中保护您的业务关键型 Windows 应用程序和 EHR 系统及其运行的数据库，包括 Microsoft SQL Server、Oracle。

• 配置灵活性 – 保护所有服务器工作负载。在单个站点内或跨数据中心进行复制。
• 节省成本 – 高级集群，无需昂贵的应用程序升级（例如 SQL Server 企业版）
• 降低复杂性 – 将本地 WSFC 迁移到云而不造成中断

保护 Linux 应用程序中的应用程序

SIOS 集群跨云区域或可用区进行独特的故障转移，以实现真正的 HA 保护。SIOS Protection Suite 包括适用于领先应用程序、ERP 和数据库的强大应用程序恢复套件，可自动执行手动任务、监控整个应用程序堆栈并确保故障转移维持特定于应用程序的最佳实践。

• 高级自动化 – 自动验证的用户输入消除了对昂贵的专业技能的需求以及手动脚本固有的风险，以在复杂的 EHR 环境中配置和管理集群
• 深度应用监控——监控整个应用环境
• 应用程序感知的自动故障转移 – 保持符合应用程序最佳实践，以实现可靠的故障转移，不会出现意外。

经许可转载安全操作系统

为什么 SIOS HANA 多目标自动化比您想象的更重要

为什么 SIOS HANA 多目标自动化比您想象的更重要

Larry（化名）是一位 SIOS 客户，过去曾部署过用于高可用性和灾难恢复 (HA/DR) 的复制解决方案。当他启动 PoC 来测试 Linux 的双节点复制解决方案时，使用SIOS 生命守护者和DataKeeper复制一样，他的首要任务是保护数据完整性。Larry 的 PoC 测试清单包括标准项目，其中包括：数据库启动/停止、将数据库迁移到备份节点、维护活动和服务器故障转移等等。Larry 坚信该解决方案能够实现快速服务器切换（即优雅的迁移）和快速故障转移（即突然强制迁移）应用程序、数据库、存储和服务从一台服务器到另一台服务器的迁移。但是，他更加强烈和热情地认为此类活动不应导致数据丢失。

通过避免脑裂来保护数据完整性

除了这些标准测试之外，拉里还添加了特定测试来试图强制“裂脑“ 设想。脑裂是指当集群成员无法相互通信，但处于运行和可操作状态，并随后同时获得公共资源的所有权时，就会发生这种情况。实际上，两名公交车司机正在争夺方向盘。由于其破坏性，脑裂可能会导致数据丢失或数据损坏，最好通过使用一种机制来确定哪个节点应保持活动状态（驱动总线）以及哪个节点应停止写入磁盘来避免。

虽然在部署使用仲裁和仲裁加见证功能的集群中，裂脑场景相对不常见，但随着每个节点添加到集群配置，解决裂脑问题的难度呈指数级增加。在具有三个或更多节点的多目标配置中，集群软件不仅必须协调故障转移到正确的节点，还必须自动将复制从新的主节点切换到第三节点，以维持灾难恢复保护，同时确保在不同节点之间进行正确仲裁。节点。在其他集群解决方案中，必须手动编写这些复杂的操作脚本，并在发生故障转移时手动更新以恢复正常操作，并且当发生脑裂时，只会变得更加困难。

由于 SIOS LifeKeeper 的功能和改进以及SAP HANA 应用程序恢复套件（方舟），拉里很难引入裂脑场景。然而，当他最终设计出一款产品时，他因了解 SIOS 产品用于保护数据的逻辑而受益匪浅。Larry 认识到 SIOS 集群软件提供的数据保护设计的高度复杂性。他选择了 SIOS LifeKeeper。

SIOS HANA 多目标自动化差异

像 Larry 这样的场景只是 SIOS 的 HANA 多目标自动化比您想象的更重要的九个原因之一。以下是全部九个：

1. 增强保护
   SIOS 的解决方案简化了多目标场景中 HANA 数据库资源的保护。基于向导的选项可快速检测当前配置并将信息精确添加到 LifeKeeper 配置中。错误检测既简洁又信息丰富，可以帮助用户解决任何问题并随后节省时间。
2. 简化管理
   Natalie（化名）负责 HANA 多节点配置。当服务器出现故障或需要维护时，Natalie 利用不同的脚本和工具来执行所需的操作。然而，这是不可扩展的。迁移到 SIOS LifeKeeper 后，Natalie 和团队有一个简单的 UI 来执行所有核心任务，例如停止和重新启动 HANA 和 HANA 系统复制。此外，如果发生灾难，团队可以使用单一、简化的 SIOS UI，而无需搜索最新的运行手册、查找正确脚本的副本或在凌晨 2 点致电 Natalie。。
3. 简化监控
   SIOS UI 中直观的状态报告为团队提供了一种快速的方法来确定复制地位。与使用监控板和自制脚本的集合相比，使用单一工具可以简化管理并节省时间。
4. 自动恢复
   某些 HANA HSR 解决方案能够在这两个节点之间执行 HANA 复制的故障转移。然而，管理员通常必须在系统故障转移后重新注册复制。如果有三个或更多节点，管理员是否了解如何更新第三个或第四个节点上的注册？他们会记得正确使用同步和异步吗？SIOS 解决方案能够处理三个甚至四个节点的多目标复制，并在出现故障后无缝地自动注册目标节点。
5. 灵活性和可扩展性
   通过两个、三个或四个节点组合来保护 HANA 集群的能力意味着客户可以灵活地提高可用性和灾难恢复级别。具有法定人数的两个节点客户能够提供针对灾难的可用性保护，并利用具有握手功能的 HANA 接管，以接近零停机时间处理维护活动。部署三个节点的客户可以通过在不同的数据中心或区域中部署具有异步复制功能的第三个节点来获得额外的灾难恢复功能。为了获得更多好处，三节点客户可以部署具有存储仲裁的第四个节点，以启用高可用性和灾难恢复如果整个数据中心丢失。
6. 数据保护
   让我们回到拉里的问题。他在主节点 A 上运行 HANA，并向节点 B 和 C 进行多目标复制。当您的手动工作以灾难告终时会发生什么？哪个节点是主节点？当节点 A 崩溃时，一切是否同步？如何避免出现错误的节点？除了在多目标 HSR 配置中添加对三个或更多节点的支持之外，新的 HANA ARK 还包括额外的管理工具，可在发生灾难或不幸的脑裂事件时提供帮助。

   HANA_DATA_OUT_OF_SYNC_<tag> 标志可防止用户意外在错误的系统上恢复数据库。HANA_LAST_OWNER_<tag> 标志可帮助管理员了解在备用节点不同步的情况下何时对主系统执行了操作。该标志告诉管理员该节点是最后一个所有者，并且应该在其中恢复复制。当备用数据库之间的所有通信暂时丢失然后恢复时，HANA_DATA_CONSISTENCY_UNKNOWN_<tag> 帮助 SIOS 自动解决并恢复复制。当与最佳实践、仲裁部署和适当的调整结合使用时，这些工具可以让像 Larry 这样的管理员避免脑裂，并在发生脑裂时安全地恢复。

7. 报告、性能和灾难恢复
   当然，多目标的真正好处在于额外的节点以及这些节点解锁的功能。在同一数据中心使用三个节点可以通过 logreplay_readaccess 参数释放更多报告的潜力，同时仍然在灾难恢复站点维护一个节点。此外，SIOS 对不同复制模式的支持使用户可以选择拥有同步节点和异步节点，以便跨数据中心（或区域）获得更好的性能。
8. 持续测试
   您的团队多久测试一次自制脚本？您的运行手册中有关配置、管理和凌晨 2 点场景的审核频率如何。HANA 多目标解决方案不仅经过 SIOS 工程师、QA 和客户体验专家的持续测试，而且还针对每个版本和更新的 HANA 故障转移和恢复流程持续进行测试和验证。
9. 广泛的文档
   不久前，我们的团队与一位客户合作进行集群管理。虽然他的前任对他们的环境非常了解，但员工晋升和重组让许多 IT 人员负责他们知之甚少的系统。当被问及其配置的操作手册和文档时，客户无法从以前的团队或以前的管理员那里找到详细信息。除了坚如磐石的自动化、管理、监控、恢复和数据保护之外，SIOS 多目标解决方案还包括有关由 LifeKeeper 控制的 HANA 多目标系统的实施、操作和管理的详细且易于使用的文档。

利用 SIOS 的整体解决方案意味着客户可以受益于一致、及时的监控和检测、快速、可靠和高效的恢复，以及保证高可用性和灾难恢复保护的全自动解决方案。联系我们有关 SAP HANA 多目标自动化的更多信息。

-Cassius Rhue，客户体验副总裁

经许可转载安全操作系统

在不花费大量资金的情况下实现 SQL Server 的 HA/DR

在不花费大量资金的情况下实现 SQL Server 的 HA/DR

高可用性和灾难恢复 (HA/DR) 是所有数据库环境的基本要求，尤其是关键任务数据库环境。然而，许多企业面临着在不大幅增加成本的情况下实现 HA/DR 的挑战。如果您正在努力解决这些问题，本文将为您提供有效的解决方案。

SQL Server 标准版被广泛使用，但它有一定的局限性：它仅支持集群中的两个节点。但是，通过利用 SIOS DataKeeper Cluster Edition 的功能，您可以克服此限制，从而能够将数据复制到第三个节点以进行灾难恢复。

此策略允许您使用 SQL Server 标准版创建 SANLess SQL Server 故障转移群集实例 (FCI)，而不是升级到 SQL Server 企业版并使用 Always On 可用性组，从而为您节省 70% 以上的 SQL Server 许可费用。

本博文旨在指导您完成使用 SIOS DataKeeper 在不属于集群的第三个节点上进行数据恢复的过程。

配置您的节点

在此场景中，我们假设您在集群中配置了两个节点，即 DataKeeper-1 和 DataKeeper-2。这些节点的 E 驱动器相互复制。此外，DataKeeper-1 正在复制到第三个节点 DataKeeper-3，该节点不属于集群。需要注意的是，对于 SQL Server Standard Edition，第三个节点永远不能成为群集的一部分。

准备第三个节点

首先，确保 DataKeeper-3 与集群分离。这样，您现在就有了一个双节点集群（DataKeeper-1 和 DataKeeper-2），其中 SQL Server 配置为故障转移集群实例，但仍使用复制到第三个节点 DataKeeper-3SIOS数据管理器。

引导灾难恢复过程

那么，这在实际灾难中会如何发挥作用呢？以下是您需要遵循的步骤：

1. 模拟灾难：在本例中，为了模拟灾难，我们使 SQL Server 在集群（DataKeeper 1 和 2）上脱机。
2. 切换到 DataKeeper 3：当 SQL Server 离线时，我们切换到 DataKeeper-3。然而，DataKeeper 3 上的卷 E 最初无法访问。
3. 解锁音量：要解锁 DataKeeper-3 上的卷，您需要执行名为“emcmd”的教程视频中所示的命令行操作。切换量’
4. 附加数据库：在真正的灾难中，您需要在 DataKeeper-3 上运行一个独立的 SQL Server 实例。然后，您可以从此独立实例附加用户定义的数据库。
5. 复制回集群：DataKeeper-3 上写入的数据将复制回 DataKeeper-1 和 DataKeeper-2。这可以使用 SIOS DataKeeper 界面进行验证。

灾后恢复

灾难解决后，您可以使用类似的过程将卷切换回原始源。

通过利用 SIOS DataKeeper Cluster Edition，您可以实施稳健、经济高效且高效的解决方案高可用性/灾难恢复适用于您的 SQL Server 环境的策略。此过程不仅无需升级到 SQL Server Enterprise Edition，从而有助于节省大量成本，而且还可以确保灾难期间的数据可用性和快速恢复。

查看这个视频了解该过程的完整演练，并确保您的 SQL Server 保持弹性，而无需花费太多。

经许可转载安全操作系统