适用于 Linux 的 SIOS 保护套件/LifeKeeper 的优势

• 西欧软件支持多种操作系统版本和风格（Linux 和 Windows）。
  • 无论操作系统如何，都可以提供一致的用户体验来保护关键任务资源。
• 西欧为多种环境提供高可用性解决方案，包括本地、虚拟化 (VMware) 和云环境，包括来自AWS 、Azure、Google Cloud 以及私有托管的云环境。 相同的工具可以在不同的环境中使用。
  • 还支持混合环境。 可以将本地节点配置为主要位置，辅助节点托管在私有云中，第三个节点位于公共云平台上，提供额外的 DR（灾难恢复）选项。

• 西欧提供应用感知保护机制，包括应用恢复工具包（方舟s)，可供全球领先的企业应用程序和数据库提供商使用。
  • 我们的综合图书馆方舟s 保护最广泛的“现成”应用。
  • 可以使用内置的“GenApp”保护其他“非标准”或遗留应用程序方舟或通过开发自定义方舟无论是内部还是与合作西欧工程师。

• 与开源工具（强制用户提前手动建立环境参数，然后键入一组复杂的命令行参数）不同，一系列基于向导的安装和配置屏幕可以直观地选择需要保护的资源并帮助选择要提供的保护类型和程度。
  • 向导扫描系统和环境以识别要保护的资源。 在大多数情况下，操作员只需确认默认选择并输入唯一的特定于环境的主机 ID 等即可完成安装。
  • 这降低了 HA 解决方案配置错误的可能性以及由于系统或应用程序故障而不可避免的意外停机。
• 西欧提供全面的技术支持选项，包括 24×7 关键支持，提供针对可用预算、系统复杂性或需要高可用性的应用程序的关键性量身定制的支持选项。

经授权转载西欧

适用于 Linux 的 SIOS 保护套件/LifeKeeper – 集成组件

西欧Protection Suite 包括以下软件组件，用于保护组织的关键任务系统。

西欧救生员

西欧LifeKeeper 提供了一个完全的容错软件解决方案实现服务器、文件系统、应用程序和进程的高可用性。 LifeKeeper 不需要任何定制的容错硬件。 LifeKeeper 只需将两个或多个系统组合在一个网络中，然后创建特定于站点的配置数据以提供自动故障检测和恢复.

在发生故障的情况下，LifeKeeper 将受保护的资源从故障服务器迁移到指定的备用服务器。 用户在实际切换过程中会遇到短暂的中断。 但是，LifeKeeper 无需操作员干预即可恢复备用服务器上的操作。

西欧数据守护者

西欧DataKeeper 为 LifeKeeper 环境提供集成的数据复制功能。 此功能使 LifeKeeper 资源能够在共享和非共享存储环境.

应用程序恢复工具包 (方舟s)

应用程序恢复工具包 (方舟s) 包括允许 LifeKeeper 管理和控制特定应用程序或服务的工具和实用程序。 当一个方舟为特定应用程序安装后，LifeKeeper 能够监控应用程序的健康状况，并在应用程序失败时自动恢复应用程序。 这些恢复工具包是非侵入性的，不需要在应用程序中进行任何更改，即可受到 LifeKeeper 的保护。

有一个全面的“现成”应用程序恢复套件库，作为西欧保护套件产品组合。 种类和数量方舟提供的 s 因版本而异西欧已购买保护套件。

经授权转载西欧

适用于 AWS 云环境的 SIOS Protection Suite for Linux 评估指南

开始在 AWS 中评估适用于 Linux 的 SIOS 保护套件

使用此分步指南在 AWS 中配置和测试双节点集群，以保护 Oracle、SQL Server、PostgreSQL、NFS、SAP 和 SAP HANA 等资源。

开始评估之前

在 AWS 中开始您的故障转移集群项目之前，请查看这些链接以了解您需要的关键概念。

• 高可用性， RTO ， 和RPO – 清楚了解 HA 的基本概念。

• 西欧适用于 Linux 的保护套件 – 集成组件– 了解 SIOS 保护套件中包含的组件：SIOS LifeKeeper、DataKeeper 和应用程序恢复工具包/

• 的好处西欧Linux 保护套件– 了解 SIOS Protection Suite for Linux 如何提供卓越的数据保护

• 迁移到云环境时应如何分配工作负载– 与本地环境不同，公共云产品在部署工作负载时为您提供了广泛的地理区域可用区供您选择。 了解为云选择工作负载分配策略的最佳实践。

• 公有云平台及其网络结构差异– 公共云提供商有自己的网络结构。 了解这些结构如何影响您的集群配置的基础知识。

• 客户端如何连接到活动节点– 了解检测和管理对应用程序故障的响应的关键集群机制。

• 节点之间的数据复制如何工作？– 确保存储冗余至关重要。 了解 SIOS DataKeeper 如何在节点之间高效复制数据。

• 什么是“脑裂”以及如何避免它了解如何确保即使网络连接失败，您也能维持一个活动节点和一个或多个备用节点。

配置网络组件

本节概述了每个节点所需的计算资源、网络结构以及配置这些组件所需的过程。

• 了解如何为故障转移群集配置网络组件
• 本教程中使用的网络结构
• 本教程中使用的计算资源

创建一个实例AWS从零开始的 EC2

• 从头开始在 AWS 上创建实例
• 在之间切换AWS服务
• 决定一个AWS地区
• 创建专有网络
• 创建子网
• 创建 Internet 网关并将其分配给专有网络
• 创建路由表
• 创建安全组
• 创建第一个 EC2 实例
• 创建第二个和第三个实例

配置 Linux 节点以运行适用于 Linux 的 SIOS 保护套件

• 配置 Linux 节点以运行适用于 Linux 的 SIOS 保护套件

安装适用于 Linux 的 SIOS 保护套件

• 安装适用于 Linux 的 SIOS 保护套件

登录和基本配置

• 登录和基本配置

保护关键资源

• 在网络中创建 IP 资源本地环境
• 在节点之间切换云环境

一旦 IP 资源受到保护，启动切换（“备用”节点变为“活动”节点）以测试功能。

• 如何切换到备用节点以确认切换正常
• 保护 Oracle 资源
• 保护微软SQL使用快速服务保护
• 保护 PostgreSQL 资源
• 保护一个NFS资源
• 保护树液资源
• 保护树液汉娜资源

经授权转载西欧

具有区域冗余存储 (ZRS) 的 Azure 共享磁盘的性能

2021 年 9 月 9 日，微软宣布的普遍可用性Azure 磁盘存储的区域冗余存储 (ZRS) ，包括 Azure 共享磁盘。

有趣的是，您现在可以构建跨可用区 (AZ) 的基于共享存储的故障转移集群实例。由于集群节点位于不同的 AZ，用户现在可以获得 99.99% 的可用性 SLA。 在支持区域冗余存储之前，Azure 共享磁盘仅支持本地冗余存储 (LRS)，将集群部署限制在单个 AZ，如果 AZ 脱机，用户很容易受到中断的影响。

但是，使用 ZRS 部署 Azure 共享磁盘时需要注意一些限制。

• 仅支持高级固态驱动器 (SSD) 和标准 SSD。 不支持 Azure 超级磁盘。
• 带有 ZRS 的 Azure 共享磁盘目前仅在美国西部 2、西欧、北欧和法国中部区域可用
• 高级 SSD Azure 共享磁盘不支持读取和写入磁盘缓存
• 磁盘突发不适用于高级 SSD
• Azure Site Recovery 支持尚不可用。
• Azure 备份仅可通过 Azure 磁盘备份获得。
• 仅支持服务器端加密，目前不支持 Azure 磁盘加密。

我还发现了一个有趣的注释文件.

“除了更多的写入延迟之外，使用 ZRS 的磁盘与使用 LRS 的磁盘相同，它们具有相同的扩展目标。 对磁盘进行基准测试以模拟应用程序的工作负载并比较 LRS 和 ZRS 磁盘之间的延迟。”虽然文档表明 ZRS 会产生一些额外的写入延迟，但由用户决定他们可以预期多少额外的延迟。 一个链接磁盘基准提供文档以帮助指导您进行性能测试。

按照文档中的指导，我使用 DiskSpd 来测量您可能遇到的额外写入延迟。 当然，结果会因工作负载、磁盘类型、实例大小等而异，但这是我的结果。

	本地冗余存储 (LRS)	区域冗余存储 (ZRS)
写 IOPS	5099.82	4994.63
平均延迟	7.830	7.998

我运行的 DiskSpd 测试使用了以下参数。

diskspd -c200G -w100 -b8K -F8 -r -o5 -W30 -d10 -Sh -L testfile.dat 我写到一个带有 ZRS 的 P30 磁盘和一个带有 LRS 的 P30 连接到标准 DS3 v2（4 vcpus，14 GiB 内存) 实例类型。 共享 ZRS P30 还附加到不同 AZ 中的相同实例，并作为共享存储添加到空集群应用程序。

2% 的开销似乎是让您的数据在两个 AZ 上同步分布的合理价格。 但是，我确实想知道如果您将集群应用程序移动到远程节点会发生什么，有效地将您的磁盘放在一个 AZ 中，而将您的实例放在另一个 AZ 中。

这是结果。

	本地冗余存储 (LRS)	区域冗余存储 (ZRS)	从远程 AZ 写入时的 ZRS
写 IOPS	5099.82	4994.63	4079.72
平均延迟	7.830	7.998	9.800

在那种情况下，我测量了 25% 的写入延迟增加。 如果您遇到 AZ 完全故障，存储和实例都将故障转移到辅助 AZ，您根本不应该遇到这种延迟增加。 但是，其他不属于 AZ 范围的故障场景很可能让您的集群应用程序在一个 AZ 中运行，而您的 Azure 共享磁盘在另一个 AZ 中运行。 在这些情况下，您需要尽快将集群工作负载移回与存储位于同一可用区的节点，以避免额外的开销。

微软文档如何启动存储帐户故障转移使用 GRS 时到不同的区域，但在使用区域冗余存储时无法手动启动存储帐户到不同 AZ 的故障转移。 您应该监控您的故障转移集群实例，以确保在集群工作负载移动到其他服务器时收到警报，并计划在安全的情况下尽快将其移回。

您可能会意外地发现自己处于这种情况，但在您执行滚动更新时，在集群应用程序服务器的计划维护期间肯定也会发生这种情况。 意识是帮助您最大限度地减少存储在降级状态下执行的时间的关键。

我希望将来微软允许用户像使用 GRS 一样启动 ZRS 磁盘的手动故障转移。 他们向 GRS 添加该功能的原因是将权力交到用户手中，以防自动故障转移没有按预期发生。 在区域冗余存储的情况下，我可以看到人们希望尝试将存储和应用程序捆绑在一起，确保它们始终在同一个 AZ 中运行，类似于 SIOS DataKeeper 等基于主机的复制解决方案的做法。