| 5月 29, 2022 |
适用于 Linux 的 SIOS 保护套件/LifeKeeper – 集成组件 |
|||||||||||||||||||||
| 5月 25, 2022 |
高可用性、RTO 和 RPO |
|||||||||||||||||||||
| 5月 21, 2022 |
适用于 AWS 云环境的 SIOS Protection Suite for Linux 评估指南 |
|||||||||||||||||||||
| 5月 16, 2022 |
具有区域冗余存储 (ZRS) 的 Azure 共享磁盘的性能 |
| 本地冗余存储 (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 等基于主机的复制解决方案的做法。
可用性 SLA：FT、高可用性和灾难恢复——从哪里开始
可用性 SLA：FT、高可用性和灾难恢复——从哪里开始
可以公平地说，在这个我们生活的许多方面都由技术驱动的现代时代，我们生活在一个瞬息万变的世界中。例如，只需单击一个按钮，我们每周的杂货订单就会送到我们家门口。我们可以立即购买活动或旅行的门票。甚至这些天，订购一辆全新的汽车，而不必去展厅附近的任何地方和一个咄咄逼人的销售人员打交道。 我们被这个便利的世界宠坏了。
但是，让我们想想必须支持这种服务水平的所有供应商和服务提供商。他们必须保持高水平的投资，以确保他们的底层基础设施（特别是他们的 IT 基础设施）的构建和运营方式能够支持这种“永远在线”的期望。应用程序和数据库必须始终运行，以满足客户需求并最大限度地提高公司的生产力和收入。IT 业务连续性的重要性与以往一样重要。
许多 IT 可用性概念都在流传，例如容错 (FT) ,高可用性（哈）和灾难恢复（博士） .但这可能会引发更多问题。这些可用性概念之间有什么区别？其中哪一个适合我的基础架构？它们可以组合或互换吗？ 任何可用性计划的第一步也是最重要的一步是建立明确的应用程序/数据库可用性服务级别协议 (SLA)。然后，这定义了最合适的可用性方法。
什么是 SLA？
在某种程度上，我们都知道 SLA 是什么，但对于本次讨论，让我们确保我们都在同一个波长上。 可用性 SLA 是服务提供商与其最终用户之间的合同，它定义了供应商要确保的应用程序/数据库正常运行时间和可访问性的预期水平，并概述了如果商定的服务水平不符合所涉及的处罚（通常是财务）遇见了。在 IT 世界中，SLA 是根据对业务的两个关键性衡量标准制定的——恢复时间目标 (RTO) 和恢复点目标 (RPO)。非常简单，RTO 定义了在发生故障时我们需要多快恢复应用程序操作。 RPO 定义了在发生恢复情况时我们的数据需要达到的最新程度。 一旦您可以为您的应用程序和数据库确定这些指标，这将定义您的 SLA。SLA 以百分比来衡量，因此，例如，您可能会遇到诸如 99.9% 或 99.99% 可用等术语。这些是 IT 将在给定年份为应用程序保证多少分钟的正常运行时间和可用性的度量。 一般来说，更多的保护意味着更多的成本。 因此，估算应用程序或数据库停机一小时的成本并将此 SLA 用作选择具有良好业务意义的解决方案的工具至关重要。
一旦我们有了 SLA，我们就可以就哪种类型的解决方案（FT、HA、DR 或它们的组合）做出最适合我们可用性需求的方法的业务决策。
什么是容错 (FT)？
FT 提供了令人印象深刻的可用性 SLA，达到 99.999%。在现实世界中，FT 解决方案将保证一年内不超过 5.25 分钟的停机时间。本质上，两台相同的服务器彼此并行运行，在所谓的“锁步”过程中以主动-主动配置同时处理两台服务器上的事务。 如果主服务器出现故障，辅助服务器将继续处理，不会中断应用程序或丢失任何数据。最终用户会很高兴地没有意识到发生了服务器故障。
这听起来太棒了！这听起来棒极了！为什么我们还需要其他东西？但是等等……就像 FT 在纸上听起来一样棒，有一些警告需要考虑。
“锁步”过程是一头奇怪的野兽。它可以运行的服务器硬件类型非常挑剔，特别是在处理器方面。这个有限的硬件兼容性列表迫使 FT 解决方案位于成本范围的较高端，当您考虑两个或更多具有相关支持和服务的 FT 集群时，成本可能高达数十万美元。
软件错误漏洞
FT 解决方案在设计时也考虑到了硬件容错，不会过多关注任何潜在的应用程序错误。请记住，FT 解决方案同时运行相同的事务和进程，因此如果主服务器上出现应用程序错误，这也会在辅助服务器上得到复制。
什么是高可用性 (HA)？
对于大多数 SLA，对于普通用例来说，购买和管理 FT 的成本太高了。在大多数情况下，HA 解决方案是更好的选择。 它们以很少的成本提供几乎相同级别的保护。HA 解决方案通过以 Active-Standby 方式部署，可提供 99.99% 的 SLA，相当于一年内停机约 52 分钟。引入了降低的 SLA，因为在恢复操作之前活动服务器必须切换到备用服务器的一小段停机时间。好吧，这不像 FT 解决方案那样令人印象深刻，但对于大多数 IT 要求，HA 满足 SLA，即使对于 CRM 和 ERP 系统等超关键应用程序也是如此。
同样重要的是，高可用性解决方案与应用程序无关，并且还可以在应用程序故障以及硬件或操作系统故障时管理服务器的故障转移。 它们还允许更多的配置灵活性。没有类似 FT 的硬件兼容性列表需要处理，因为在大多数情况下，它们将在任何支持底层操作系统的平台上运行。
灾难恢复 (DR) 如何融入其中？
与 FT 和 HA 一样，DR 也可用于支持关键业务功能。 但是，DR 可以与 FT 和 HA 结合使用。容错和高可用性专注于维护本地级别的正常运行时间，例如在数据中心（或云可用性区域）内。灾难恢复提供冗余站点或数据中心以在灾难袭击主数据中心时进行故障转移。
这是什么意思呢？
归根结底，没有错误或正确的可用性方法可供选择。它归结为您试图保护的业务流程的重要性以及解决方案的基本经济性。在某些情况下，这是不费吹灰之力的。例如，如果您正在运行核电站，我会觉得关键操作受到 FT 系统的保护会更舒服。 让我们面对现实吧，您可能不希望那里的服务有任何中断。但对于大多数 IT 环境，关键的正常运行时间也可以通过 HA 以更易于消化的价格提供。
如何选择：FT、HA和DR？
- 首先，详细了解您的业务运营并确定停机成本。
- 建立 SLA 后，权衡选择的可用性解决方案的成本与任何潜在停机时间的成本。
- 在选择可用性解决方案时，请考虑易于部署和易于使用，因为这些也会影响可用性解决方案的总体 TCO。
IT 系统很强大，但在最不方便的时候它们可能会出错。 FT、HA 和 DR 是您的保险单，可在这个以即时和便利为主导的世界中向客户提供 SLA 时为您提供保护。
经授权转载西欧