白皮书：使用 SIOS 保护套件保护 Amazon EC2 中的 SAP 和 SAP S/4HANA

虽然 AWS 具有确保基础设施级别可用性的规定，但 SAP 环境的业务关键型性质需要更多保护。也就是说，需要特别关注应用程序层和数据库层。有多种选项可以提供这种额外的保护。

本白皮书着眼于在 AWS 上的 Linux 发行版（包括 Oracle Linux、Red Hat、SUSE 和 CentOS）上运行 SAP 或 SAP S/4HANA 的最佳实践。

经许可转载安全操作系统

 

将 Amazon EBS 多重附加用于 Microsoft 故障转移集群的挑战

Amazon EBS 和 Microsoft 故障转移集群概述

Amazon EBS 多重附加卷和 Microsoft故障转移集群是云计算和数据管理领域的强大工具。然而，整合这两种技术可能充满挑战。这篇博文深入探讨了为什么使用 Amazon EBS Multi-Attach for Microsoft 故障转移集群通常不是最佳选择。

强大的故障转移集群的单一可用区约束

Amazon EBS 卷的一个主要限制是它们仅限于单个可用区 (AZ)。对于强大的故障转移集群，跨多个可用区部署实例是推荐的最佳实践，这是 EBS 卷无法直接支持的。

高可用性 SLA 问题

虽然 EBS 卷提供了99.9% 可用性 SLA，这低于高可用性解决方案通常预期的 99.99%。在跨多个可用区部署实例时，AWS 确实保证了更高的 SLA，但这一优势并未扩展到单可用区部署。

IO2 卷的成本影响

具有多附加 EBS 卷的 Windows 故障转移群集需要使用 IO2 卷，该卷比具有相似大小和性能的 GP3 卷贵大约九倍。这种成本差异非常显着，特别是对于大规模部署。

AWS 集群配置的复杂性

建筑AWS 中的集群节点位于同一可用区时，需要将可用区划分为多个子网，以支持Windows集群中不同的虚拟IP地址（VIP）。这种复杂性以及无法跨集群节点共享单个 VIP 增加了配置挑战。

SIOS DataKeeper：卓越的替代方案

SIOS数据管理器作为一种卓越的解决方案，它允许集群跨越子网，同时提供所需的 99.99% 可用性 SLA。它不仅提供更灵活的存储选项（包括使用 GPT3 磁盘），而且更具成本效益。使用带有 GPT3 磁盘的 SIOS DataKeeper 的集群的成本大约是基于 IO2 的类似集群的 20%，并且可用性增强。

通过 SIOS 实现卓越的高可用性

在 Microsoft 故障转移集群中使用 Amazon EBS 多附加卷带来了多项重大挑战，从有限的可用区部署选项和较低的可用性 SLA 到更高的成本和增加的配置复杂性。SIOS DataKeeper 提供了一种引人注目的替代方案，可以更有效地平衡成本、灵活性和可靠性。对于寻求高可用性和成本效率的组织来说，探索 EBS Multi-Attach 之外的选项是一个谨慎的策略。联系SIOS了解更多信息。

经许可转载安全操作系统

视频：应用程序高可用性将变得普遍 | SIOS 技术的预测

SIOS Technology 是一家高可用性 (HA) 和灾难恢复 (DR) 解决方案公司，跨 Windows 和 Linux 系统以及各种云平台为客户提供关键任务数据库、应用程序和服务的应用程序可用性。卡修斯·鲁伊SIOS Technology 客户体验副总裁分享了他对 2024 年的预测。

随着对应用程序的依赖不断增加，IT 团队面临越来越大的压力，需要为传统上被认为是非关键应用程序和关键任务应用程序提供高效的高可用性和灾难恢复。由于这种转变，我们可能会看到高可用性软件解决方案和服务的扩展来满足这一期望。

随着越来越多的公司扩展到云并跨不同的操作系统，预计会有更多的团队覆盖不同的操作系统、应用程序和云平台。团队将寻找在这些不同操作系统和云环境中保持一致的应用程序和解决方案，以降低复杂性并提高成本效率。

HA 解决方案还需要在操作系统和云环境中保持一致，我们将看到与云无关的 HA 的发展趋势。公司需要简单、自动化、快速且智能的 HA 和 DR 解决方案。随着越来越多的组织迁移到云，他们需要确保在此过程中不会丢失数据。HA 解决方案需要弥合旧系统和更现代系统之间的差距。

到 2024 年，人们将更加关注数据保留、安全访问控制和权限，促使组织将更多增强的安全措施集成到其高可用性和灾难恢复解决方案、服务和策略中。随着收集的数据量不断增加，组织还需要更多有关故障发生原因的信息。自动化和编排工具可能会在简化根本原因分析和提供智能响应方面发挥核心作用。

SIOS Technology 将在来年继续关注客户，帮助他们避免和减少停机时间，并确保他们的数据和应用程序在业务最需要时可用。该公司将继续优化其解决方案，提供额外的相邻服务以使客户受益，并帮助应用程序提供商和云提供商制定有效的HA策略。

经许可转载安全操作系统

三菱汽车利用 LifeKeeper 将关键系统转移到云端以实现高可用性保护

当三菱汽车公司使用新的基于云的系统改造其三个地点的仓库管理系统时，他们需要一种新的方法来提供高可用性，而不增加复杂性或降低性能。

“即使出现问题，LifeKeeper 也会自动从主服务器节点故障转移到辅助服务器节点系统立即启动，操作继续进行，用户不会出现任何明显的延迟，从而节省了 IT 时间并消除了客户的服务中断。”

三菱汽车全球 IT 部门业务 IT 部经理 Hiromasa Tsuboshima 说道

环境

每个三菱汽车仓库都依赖一个管理系统来处理经销商销售的汽车零部件和配件的订单和库存，例如脚垫和车顶行李架。它管理零件和用品的接收、经销商国内和国际订单的发货管理以及仓库地点内的库存管理和分配。

遗留系统运行在老化的本地服务器硬件上，这些硬件越来越容易出现问题，浪费 IT 时间进行故障排除并导致操作频繁中断。现有系统使用硬件制造商专有的冗余来减少停机时间。如果遗留系统出现问题，IT 人员必须手动停止系统并将操作切换到冗余硬件，直到问题得到解决 – 这一过程需要 IT 人员花费两到四个小时的时间。

三菱汽车必须确保在规定的验收期内订购的任何零件或配件均在第二天交付给经销商。因此，即使这些关键任务系统的停机时间很短，也可能对业务产生重大影响。

仓库管理系统在确保及时处理所有订单以满足交货计划方面发挥着关键作用。例如，为了确保下午 4:29 输入的订单次日送达，仓库管理系统必须在下午 4:40 之前处理并显示该订单，以便可以将其放入当天的最后一辆卡车或航班上。“我们需要在 10 分钟内恢复，”岩崎说。

挑战

三菱汽车公司全球 IT 部门业务 IT 部经理 Hiromasa Tsuboshima 表示：“我们六个仓库中的三个仓库的现有系统都是 2012 年开始使用的硬件。我们需要用新系统替换它们，以消除对系统的消耗。 IT 资源并减少对运营的负面影响。” 为其新的基于云的仓库系统寻找高可用性解决方案对于项目的成功至关重要。三菱汽车公司全球 IT 部门业务 IT 部成员 Satoshi Iwasaki 表示：“根据公司范围的政策，每当我们构建新系统时，我们都需要从旧的本地系统迁移到公共云。 ”

高可用性软件

在将仓库管理系统迁移到公共云时，三菱汽车咨询了一位外部 IT 顾问，后者推荐了 SIOS LifeKeeper for Linux 以实现高可用性。“根据我们过去的经验，我们总是使用硬件解决方案来实现高可用性，”Iwasaki 先生说。“我向 SIOS 代表提出了很多有关使用 HA 软件的深入问题，SIOS 提供了准确、完整的答案，这建立了我对 SIOS LifeKeeper 的信任。”

决定选择 LifeKeeper 的另一个关键因素是可选的 LifeKeeper 专业服务，它提供了根据三菱特定仓库系统要求量身定制的应用程序感知恢复套件 (ARK)。

SIOS ARK 使 LifeKeeper 能够监控整个应用程序堆栈是否存在潜在的停机问题。他们还根据最佳实践来协调应用程序故障转移，以便在辅助节点上顺利运行。“我们能够定制和开发 LifeKeeper 来满足我们的要求，并且 SIOS 能够响应我们的所有要求，”Iwasaki 先生说。

快速、自动的故障转移

“即使出现问题，LifeKeeper 也会立即自动从主服务器节点故障转移到辅助节点，并且操作会继续进行，用户不会出现任何明显的延迟。它节省了 IT 时间并消除了客户的服务中断。”Tsuboshima 先生说道。坪岛先生负责全球IT部门的部分系统的管理。在升级项目之前，他常常在夜间随时收到故障警报，需要他立即关注。如今，如果发生故障，他只需收到故障转移通知，系统即可继续运行，无需干预。SIOS 解决方案为 Tsuboshima 先生和 IT 团队的其他成员节省了许多小时的宝贵时间，并消除了服务中断。

结果

在应对 2020 年大流行时，将仓库管理系统迁移到云端，同时确保 LifeKeeper 的高可用性的好处是显而易见的。“将我们的系统置于云端，使我们能够远程管理系统。“如果我们继续使用旧的本地系统，我们将面临在 COVID-19 紧急情况期间进入办公室解决问题或管理系统的巨大额外风险，”Iwasaki 先生说。

尽管三菱汽车继续转向公共云，但其许多系统仍然使用大型机。“当我们考虑将我们的关键任务系统从这些主机系统转移到云端时，我们将寻求 LifeKeeper 的高可用性保护，”Iwasaki 先生说。未来我们会向公司推荐它。”

了解有关 Linux 版 SIOS LifeKeeper 的更多信息

学习更多关于SIOS 保护套件，包括 SIOS LifeKeeper、SIOS DataKeeper 和 SIOS 应用程序恢复套件。

经许可转载安全操作系统

如何设置 DataKeeper 集群版本（DKCE 集群）

什么是 DKCE 集群？

DKCE 是 的缩写DataKeeper集群版。DKCE 是一款 SIOS 软件，它将 DataKeeper 的使用与以下功能相结合：Windows 故障转移集群提供高可用性通过基于迁移的数据复制。

创建DKCE集群的步骤

对于此示例，我将设置一个三节点集群，其中第三个节点保持节点多数。

步骤1：您必须在 2/3 的系统上安装 DataKeeper 才能设置 DKCE 集群。单击以下链接按照我们的快速入门指南完成此安装：https://docs.us.sios.com/dkce/8.10.0/en/topic/datakeeper-cluster-edition-quick-start-guide

第2步：添加您计划在服务器管理器中管理的服务器。这需要在您计划添加到集群的所有服务器上完成。

在您的服务器上导航到服务器管理器

点击“添加其他要管理的服务器”

我在这里按服务器名称添加了服务器。为此，您需要验证主机文件中的系统名称和 IP 条目，该文件位于：C:\Windows\System32\drivers\etc\hosts

添加所有服务器后，您可以通过导航到服务器管理器中的“所有服务器”进行验证

步骤3：您可能会注意到 winRM 错误，要绕过它，请以管理员身份在 PS 中运行此命令。运行此命令将集群中的服务器添加为可信主机。该命令需要在集群中的每个系统上运行。

Set-Item WSMan:\localhost\Client\TrustedHosts -Value ‘<服务器 1 的名称>,<服务器 2 的名称>’

步骤4：安装故障转移集群

跟随安装故障转移集群的步骤。

第5步：导航到故障转移集群管理器

第6步：点击“创建集群”

第7步：接下来，添加应该在集群中的服务器，并在每个条目后单击“添加”。

步骤8：该列表应类似于下图中的列表

第9步：选择“运行所有测试”进行验证测试，然后单击“下一步”。

第10步：测试完成后，单击“完成”

第11步：命名您的集群，我将其命名为“Cluster1”，单击“下一步”

步骤12：确认“将所有符合条件的存储添加到集群”已选中，单击“下一步”

步骤13：完成第 12 步后，单击“完成”

第14步：在故障转移群集管理器中，群集最初将处于脱机状态。我将分配一个未使用的 IP 使其上线。在“集群核心资源”中右键单击 IP 地址资源并选择属性。

在属性面板中，我的子网掩码是/28，因此我将选择范围内的可用IP，12.0.0.14。点击“应用”

在“集群核心资源”中右键单击集群并选择“上线”

资源现在应该在线

第15步：导航到 DataKeeper

第16步：右键单击“作业”，然后单击“创建作业”开始创建我们的第一个镜像

为作业命名，我将作业命名为“job1”，然后单击“创建作业”

选择要从中复制数据的源和卷。我选择了 Box1 作为源，卷 D，单击“下一步”

接下来，选择要作为目标的服务器和卷。我选择了Box2，卷D。

将出现一条提示，要求您将创建的卷自动注册为 WSFC 卷，选择“是”以使该卷高度可用。

在 DataKeeper 中，您现在可以看到该卷当前正在镜像。

步骤17：在故障转移群集管理器中，导航到存储，然后导航到磁盘。您将看到您自动注册的卷是 WSFC。

第18步：让我们验证应该检查的所有者​​。右键单击该卷，然后单击“属性”

由于我需要第三个来作为见证人并维持节点多数，因此 Box3 将需要取消选中/保持取消选中状态。

步骤19：现在我们可以通过故障转移集群管理器测试迁移。导航到文件资源管理器并在当前正在镜像的卷中创建一个新的文本文件。在您的源上执行此操作。

导航到故障转移群集管理器，单击“DataKeeper Volume D”，然后从“操作”窗格中选择“移动可用存储”。

右键单击“最佳可能节点”。这应该会自动迁移到您的目标。

在故障转移集群管理器中，验证“DataKeeper Volume D”的所有者现在是目标节点

导航到 DataKeeper 以验证您的目标现在是源，反之亦然。

成功的 DKCE 集群设置

您已完成 DKCE 集群的设置。

SIOS提供资源和训练对于我们所有的产品。

经许可转载安全操作系统