6月 3, 2022 |
适用于 Linux 的 SIOS 保护套件/LifeKeeper 的优势适用于 Linux 的 SIOS 保护套件/LifeKeeper 的优势
经授权转载西欧 |
|||||||||||||||||||||
5月 29, 2022 |
适用于 Linux 的 SIOS 保护套件/LifeKeeper – 集成组件适用于 Linux 的 SIOS 保护套件/LifeKeeper – 集成组件西欧Protection Suite 包括以下软件组件,用于保护组织的关键任务系统。 西欧救生员西欧LifeKeeper 提供了一个完全的容错软件解决方案实现服务器、文件系统、应用程序和进程的高可用性。 LifeKeeper 不需要任何定制的容错硬件。 LifeKeeper 只需将两个或多个系统组合在一个网络中,然后创建特定于站点的配置数据以提供自动故障检测和恢复. 在发生故障的情况下,LifeKeeper 将受保护的资源从故障服务器迁移到指定的备用服务器。 用户在实际切换过程中会遇到短暂的中断。 但是,LifeKeeper 无需操作员干预即可恢复备用服务器上的操作。 西欧数据守护者西欧DataKeeper 为 LifeKeeper 环境提供集成的数据复制功能。 此功能使 LifeKeeper 资源能够在共享和非共享存储环境. 应用程序恢复工具包 (方舟s)应用程序恢复工具包 (方舟s) 包括允许 LifeKeeper 管理和控制特定应用程序或服务的工具和实用程序。 当一个方舟为特定应用程序安装后,LifeKeeper 能够监控应用程序的健康状况,并在应用程序失败时自动恢复应用程序。 这些恢复工具包是非侵入性的,不需要在应用程序中进行任何更改,即可受到 LifeKeeper 的保护。 有一个全面的“现成”应用程序恢复套件库,作为西欧保护套件产品组合。 种类和数量方舟提供的 s 因版本而异西欧已购买保护套件。 经授权转载西欧 |
|||||||||||||||||||||
5月 25, 2022 |
高可用性、RTO 和 RPO高可用性、RTO 和 RPO高可用性 (HA) 是一个信息技术术语,指的是在超过 99.99% 的时间内可运行且可用的计算机软件或组件。 应用程序或系统的最终用户每年的服务中断时间少于 52.5 分钟。 这种可用性级别通常是通过使用高可用性集群来实现的,这种配置通过使用冗余服务器、网络、存储和软件消除单点故障来减少应用程序停机时间。 什么是恢复时间目标( RTO ) 和恢复点目标 ( RPO )?除了 99.99% 的可用时间,高可用性环境还满足严格的恢复时间和恢复点目标。 恢复时间目标( RTO ) 是从应用程序故障到恢复应用程序操作和可用性所用时间的度量。 这是衡量公司可以承受多长时间关闭该应用程序的指标。 恢复点目标( RPO ) 衡量在停机问题后应用程序可用性恢复时数据的最新程度。 它通常被描述为发生故障时可以容忍的最大数据丢失量。西欧高可用性集群提供了一个RPO零和一个RTO分钟。 什么是高可用性集群?在高可用性集群中,重要的应用程序运行在一个主服务器节点上,该节点连接到一个或多个辅助节点以实现冗余。 集群软件,如西欧LifeKeeper,监控集群应用程序和依赖资源,以确保它们在活动节点上运行。 系统级监控是通过集群节点之间的间隔心跳来完成的。 如果主服务器出现故障,则在超过心跳超时时间间隔后,从服务器启动恢复。 对于应用程序级故障,集群软件检测到应用程序在活动节点上不可用。 然后,它将应用程序和相关资源在称为故障转移的过程中移动到辅助节点,在该过程中继续运行并满足严格的要求RTO s。 在传统的故障转移集群中,集群中的所有节点都连接到同一个共享存储,通常是一个存储区域网络( SAN )。 故障转移后,辅助节点被授予访问共享存储的权限,使其能够满足严格的RPO s。 经授权转载西欧
|
|||||||||||||||||||||
5月 21, 2022 |
适用于 AWS 云环境的 SIOS Protection Suite for Linux 评估指南适用于 AWS 云环境的 SIOS Protection Suite for Linux 评估指南开始在 AWS 中评估适用于 Linux 的 SIOS 保护套件使用此分步指南在 AWS 中配置和测试双节点集群,以保护 Oracle、SQL Server、PostgreSQL、NFS、SAP 和 SAP HANA 等资源。 开始评估之前在 AWS 中开始您的故障转移集群项目之前,请查看这些链接以了解您需要的关键概念。
配置网络组件本节概述了每个节点所需的计算资源、网络结构以及配置这些组件所需的过程。 创建一个实例AWS从零开始的 EC2
配置 Linux 节点以运行适用于 Linux 的 SIOS 保护套件安装适用于 Linux 的 SIOS 保护套件登录和基本配置保护关键资源一旦 IP 资源受到保护,启动切换(“备用”节点变为“活动”节点)以测试功能。 |
|||||||||||||||||||||
5月 16, 2022 |
具有区域冗余存储 (ZRS) 的 Azure 共享磁盘的性能具有区域冗余存储 (ZRS) 的 Azure 共享磁盘的性能2021 年 9 月 9 日,微软宣布的普遍可用性Azure 磁盘存储的区域冗余存储 (ZRS) ,包括 Azure 共享磁盘。 有趣的是,您现在可以构建跨可用区 (AZ) 的基于共享存储的故障转移集群实例。由于集群节点位于不同的 AZ,用户现在可以获得 99.99% 的可用性 SLA。 在支持区域冗余存储之前,Azure 共享磁盘仅支持本地冗余存储 (LRS),将集群部署限制在单个 AZ,如果 AZ 脱机,用户很容易受到中断的影响。 但是,使用 ZRS 部署 Azure 共享磁盘时需要注意一些限制。
我还发现了一个有趣的注释文件. “除了更多的写入延迟之外,使用 ZRS 的磁盘与使用 LRS 的磁盘相同,它们具有相同的扩展目标。 对磁盘进行基准测试以模拟应用程序的工作负载并比较 LRS 和 ZRS 磁盘之间的延迟。”虽然文档表明 ZRS 会产生一些额外的写入延迟,但由用户决定他们可以预期多少额外的延迟。 一个链接磁盘基准提供文档以帮助指导您进行性能测试。 按照文档中的指导,我使用 DiskSpd 来测量您可能遇到的额外写入延迟。 当然,结果会因工作负载、磁盘类型、实例大小等而异,但这是我的结果。
我运行的 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 中。 这是结果。
在那种情况下,我测量了 25% 的写入延迟增加。 如果您遇到 AZ 完全故障,存储和实例都将故障转移到辅助 AZ,您根本不应该遇到这种延迟增加。 但是,其他不属于 AZ 范围的故障场景很可能让您的集群应用程序在一个 AZ 中运行,而您的 Azure 共享磁盘在另一个 AZ 中运行。 在这些情况下,您需要尽快将集群工作负载移回与存储位于同一可用区的节点,以避免额外的开销。 微软文档如何启动存储帐户故障转移使用 GRS 时到不同的区域,但在使用区域冗余存储时无法手动启动存储帐户到不同 AZ 的故障转移。 您应该监控您的故障转移集群实例,以确保在集群工作负载移动到其他服务器时收到警报,并计划在安全的情况下尽快将其移回。 您可能会意外地发现自己处于这种情况,但在您执行滚动更新时,在集群应用程序服务器的计划维护期间肯定也会发生这种情况。 意识是帮助您最大限度地减少存储在降级状态下执行的时间的关键。 我希望将来微软允许用户像使用 GRS 一样启动 ZRS 磁盘的手动故障转移。 他们向 GRS 添加该功能的原因是将权力交到用户手中,以防自动故障转移没有按预期发生。 在区域冗余存储的情况下,我可以看到人们希望尝试将存储和应用程序捆绑在一起,确保它们始终在同一个 AZ 中运行,类似于 SIOS DataKeeper 等基于主机的复制解决方案的做法。 |