| 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 时为您提供保护。
经授权转载西欧
如何避免 IO 瓶颈：Windows 云部署的 DataKeeper 意图日志放置指南
如何避免 IO 瓶颈：Windows 云部署的 DataKeeper 意图日志放置指南
为了确保最佳的应用程序性能，在部署时SIOS 数据保持器重要的是放置意图日志（位图文件）在可用的最低延迟磁盘上，避免 IO 瓶颈。 在 AWS、GCP 和 Azure 中，可用的最低延迟磁盘是临时驱动器。 但是，在 Azure 中，使用临时驱动器与高级 SSD 之间的差异很小，因此在 Azure 中运行 DataKeeper 时没有必要使用临时驱动器。 然而，在 AWS 和 GCP 中，必须将意图日志重新定位到临时驱动器，否则写入吞吐量将受到显着影响。
在为位图文件使用临时磁盘时，需要进行权衡。 临时驱动器的本质是不能保证存储在其上的数据是持久的。 事实上，如果从控制台停止云实例，则附加到该实例的临时驱动器将被丢弃，并为该实例附加一个新驱动器。 在此过程中，位图文件将被丢弃，并在其位置上放置一个新的空位图文件。
在某些情况下，如果位图文件丢失，则会发生完全重新同步。 例如，如果一个主服务器SANless 集群r 从控制台关闭会发生故障转移，但是当服务器重新联机时，将从镜像的新源到旧源进行完全重新同步。 这会自动发生，因此用户无需执行任何操作，并且活动节点在此重新同步期间保持在线。
在其他情况下，位图文件的放置也会影响性能。 例如，如果您要复制 NVMe 驱动器，您将需要在 NVMe 驱动器上划出一个小分区来保存位图文件。 一般的经验法则是位图文件应该位于实例上最快、最低延迟的磁盘上。 它还应该位于不会对其他 IO 操作过度征税的磁盘上。
有关如何重新定位意图日志的信息，请参阅DataKeeper 文档. 有关如何使用意图日志的其他信息，请参阅DataKeeper 文档.
经授权转载西欧
领先的媒体平台保护 AWS EC2 云中的关键 SAP S/4 HANA
领先的媒体平台保护 AWS EC2 云中的关键 SAP S/4 HANA
基于 SAP、Amazon Web Services 和 Red Hat Linux 的认证和验证选择 SIOS
这家领先的媒体机构每周都会接触到新加坡几乎所有的成年人。通过该国最广泛的媒体平台，包括数字、电视、广播、印刷和户外媒体以及四种语言（英语、普通话、马来语和泰米尔语）的 50 多个产品和品牌。
环境
该公司使用一个SAP S/4 HANA 应用程序和HANA 数据库为整个组织的运营提供动力，统一多个部门的运营。 他们在本地数据中心的 Red Hat Linux 环境中运行这些关键应用程序和数据库。 保护这些基本系统免受停机和灾难的影响是该组织 IT 团队的首要任务。
挑战
该媒体组织的 IT 团队认识到，他们可以通过将其 SAP 应用程序和 HANA 数据库迁移到 AWS EC2 云中来显着节省成本。 但是，为了成功迁移，他们需要一个高可用性 (HA) 和灾难恢复 (DR) 解决方案，该解决方案可以在不中断现有 SAP 环境的情况下“升级并转移”到 AWS。
评价
该公司的 IT 团队需要一个他们可以依赖的 HA/DR 解决方案来满足其在云中 99.99% 的可用性 SLA。 该解决方案需要通过 SAP 和 AWS 的认证并支持 Red Hat Linux 操作系统。 最后，为了确保他们能够为这些关键工作负载提供完整的 DR 保护，他们需要一个能够跨多个 AWS 可用区 (AZ) 进行故障转移的集群解决方案。 AWS 解决方案架构师建议该组织使用 SIOS LifeKeeper for Linux 集群软件。 该公司的 IT 团队完成该项目的时间很短，需要选择一个既能满足他们的要求又不妨碍他们进展的 HA 供应商。
解决方案
他们之所以选择 SIOS LifeKeeper，是因为它不仅符合我们的所有标准，还因为 SIOS 团队组织得非常迅速，使他们能够按计划进行云迁移项目。 SIOS Lifekeeper 已通过 AWS 和 SAP 认证，可在 Red Hat 和 AWS EC2 云环境中实现高可用性。 SIOS 解决方案还满足另一个关键标准，因为它能够跨 AWS 可用区域进行复制和提供冗余 SIOS 的专门本地支持团队给组织的 IT 团队留下了深刻的印象，他们可以 7 天、每天 24 小时回答问题并提供支持一周。 该组织目前有五对故障转移集群，使用 SIOS LifeKeeper for Linux 来保护在 AWS EC2 中跨多个可用区运行的 S/4 HANA 和 SAP HANA 应用程序。
结果
可用性一直很可靠，自从使用该软件以来，我们没有任何延长的停机时间通过使该客户能够将这些重要的工作负载迁移到云而不牺牲 HA/DR 或应用程序性能，SIOS 使我们能够实现显着的成本节约，”他说。 SIOS LifeKeeper 的 Mediacorp 易用性通过最大限度地减少 IT 管理时间节省了更多。
经授权转载西欧
保护系统免于停机
保护系统免于停机
在当今的业务环境中，组织依赖于应用程序、数据库和 ERP 系统，例如 SAP、SQL Server、Oracle 等。 这些应用程序统一并简化了您最关键的业务运营。 当他们失败时，他们花费的不仅仅是金钱。 保护这些复杂系统免于停机至关重要。
经验证的高可用性和灾难恢复
SIOS 在以下领域拥有 20 多年的经验高可用性和灾难恢复.SIOS 知道没有一种万能的解决方案。 当今的数据系统是本地、公共云、混合云和多云环境的组合。 应用程序本身可以创造更多的复杂性。 但是配置开源集群软件可能很费时费力，而且容易出现人为错误。
SIOS 拥有为关键应用程序提供高可用性和灾难恢复的解决方案。 这些解决方案是根据我们在不同行业和用例中的实际经验开发的。 我们的产品包括适用于 Windows 的 SIOS DataKeeper 集群版和适用于 Linux 的 SIOS LifeKeeper或窗户。 这些强大的应用程序提供故障转移保护。 LifeKeeper 随附的应用程序恢复工具包通过自动配置和验证输入来加快应用程序配置时间。
本地、云端或混合环境中的系统保护
SIOS 为关键业务应用程序提供所需的保护，并降低管理它们的复杂性，无论是在本地、云中还是在混合云环境中。 在下面的视频中了解更多关于我们的信息或联系我们了解有关业务关键应用程序的高可用性和灾难恢复的更多信息。
经授权转载西欧