如何避免 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 为关键业务应用程序提供所需的保护，并降低管理它们的复杂性，无论是在本地、云中还是在混合云环境中。 在下面的视频中了解更多关于我们的信息或联系我们了解有关业务关键应用程序的高可用性和灾难恢复的更多信息。

经授权转载西欧

如何使用 WSFC 在云中实现高可用性

如何使用 WSFC 在云中实现高可用性

Microsoft Windows Server 包括 Windows Server 故障转移群集 (WSFC) 软件，以确保关键应用程序的可用性。 在本地环境中，集群中的主节点和备用节点连接到同一个共享存储。 但是，此基础架构不能直接带到云端。 跨主系统和备用系统的共享存储在 WSFC 中必不可少，但共享存储不能与 AWS、Azure 或 Google Cloud 中的 IaaS（基础设施即服务）等公共云服务一起使用。

地理分离的共享存储对于 WSFC在云中不可用

在将本地应用程序迁移到云端时，公司更愿意将其整个基础架构（包括 WSFC）迁移到云端，而无需更改本地操作流程。 这使他们能够通过在云中应用相同的 WSFC 技能和专有技术来最大程度地减少中断。

组成集群的服务器分为主节点（应用程序运行的地方）和备用节点。 WSFC 软件监控应用程序和服务器节点以确保它们正常运行。 如果 WSFC 检测到主节点出现问题，它会在称为“故障转移”的过程中将应用程序的操作切换到备用节点。

在 WSFC 环境中，主服务器和备用服务器连接到共享存储——通常称为 SAN（存储区域网络）或 iSCSI-SAN 存储的存储。

要将操作从主服务器故障转移到备用服务器，必须切换网络链接，以便备用服务器可以读取和写入通常读取和写入主服务器的 SAN。 这样，可以在短时间内重新启动服务，让备用服务器访问与主节点相同的数据并满足低恢复点目标（RPO）。

查看相关内容：灾难恢复基础.

但是，将 WSFC 迁移到云时，没有可用的 SAN。 例如，您不能将 Amazon Web Services (AWS) 和 Microsoft Azure 链接到多个节点（服务器）以用作共享存储。 这同样适用于其他云服务的 IaaS。

可以在没有共享存储的情况下基于 WSFC 构建 HA 集群配置，但需要非常高级的技能，例如创建自己的程序来恢复备用节点上的数据。 操作复杂，事件发生时不易验证。

数据复制软件解决问题

要解决此问题，您可以安装数据复制专用于 HA 集群的软件 – 例如 SIOS DataKeeper Cluster Edition – 并在本地服务器之间同步存储。 使用基于主机的块级复制实时同步主备节点本地磁盘上的数据。 使用这种方法，您不需要共享存储。 相反，您可以使用熟悉的 WSFC 构建 HA 集群配置，而不会中断已建立的流程。

使用 DataKeeper，同步节点在 WSFC 管理屏幕（故障转移集群管理）中显示为 SAN。 如果您的运营经理使用过 WSFC，他们几乎不需要使用这种方法进行培训。

云中的高可用性超越了本地 HA使用 SIOS DataKeeper 和 WSFC

DataKeeper 集群版是与 Windows Server 故障转移群集 (WSFC) 无缝集成的软件插件，可添加性能优化的基于主机的同步或异步复制。 万一 HA 集群发生故障，WSFC 将协调操作故障转移到备用节点并访问共享存储，就像它是共享存储一样。 这种简单的机制可以在不改变现有系统操作的情况下迁移到 AWS。

在不影响熟悉的 WSFC 操作的情况下，可以使用相当于或优于本地部署的 DataKeeper 来保证云中的高可用性高可用性. 这种集群配置的优点是非常简单，可以轻松应用于任何云环境。

与 WSFC 无缝集成

SIOS DataKeeper Cluster Edition 通过提供性能优化的、基于主机的数据复制机制与 Windows Server Failover Clustering (WSFC) 无缝集成并进行了扩展。 在 WSFC 管理软件集群的同时，SIOS 执行数据复制以在共享存储集群不可能或不切实际的情况下（例如在云、虚拟和高性能存储环境中）实现灾难保护并确保零数据丢失。

经授权转载西欧

部署仲裁/见证的最佳方式

部署仲裁/见证的最佳方式

在最近的一次会议上，一位客户提出了一个关于高可用性 (HA) 和仲裁/见证可行性需求的问题。 他们的问题是，“部署法定人数/见证人的最佳方式是什么？”他们的问题的答案很简单，没有单一的最佳方式来部署仲裁。为了理解为什么，让我们从定义三个关键的东西开始：什么是见证资源、仲裁资源和裂脑场景。

什么是裂脑？

在正常的集群环境中，受保护的应用程序在集群的主节点上运行。如果该主节点的应用程序发生故障，集群软件会将应用程序操作移动到辅助节点或远程节点，该节点承担主节点的角色。 在任何给定时间，只有一个主节点。

裂脑是指集群成员之间无法相互通信，但处于运行和可操作状态，随后同时拥有公共资源的情况。 实际上，您有两个公共汽车司机在争夺方向盘。裂脑，由于其破坏性，可能导致数据丢失或数据损坏，最好通过使用围栏、仲裁、见证或集群仲裁的仲裁/见证功能来避免。

在大多数集群管理器中，在以下情况下会维持仲裁：

1. 所有服务器都能够看到所有集群对等方和见证服务器的相同状态
2. 所有服务器都能够看到所有集群对等方的相同状态，但不是见证服务器
3. 所有服务器都可以看到见证资源，尽管彼此看不到，并避免出现脑裂情况

在大多数集群管理器中，仲裁会在以下情况下丢失：

1. 服务器无法看到所有集群对等点和见证服务器
2. 服务器无法看到大多数集群对等方，即使它们可以看到见证服务器
3. 服务器无法访问或维持对仲裁资源的访问以成功仲裁仲裁成员资格和资源访问

什么是见证资源（或服务器）？

见证资源是服务器、网络端点或设备，用于在集群具有偶数个成员时实现和维护仲裁。具有奇数成员的集群，使用集群多数，不需要使用见证资源作为集群服务器的所有成员来仲裁多数成员资格。

什么是仲裁和仲裁资源？

仲裁资源是一种资源（设备、系统、块存储、文件存储、文件共享等），用作仲裁集群状态和成员资格的手段。在某些集群管理器中，仲裁是集群内的一种资源，它帮助或需要任何集群状态和集群成员资格决策。在其他集群管理器中，quorum 起到了决胜局的作用，以避免脑裂。

部署仲裁的不止一种方法

鉴于仲裁的关键性质，HA 架构必须正确部署仲裁/见证资源，并且幸运（或不幸）没有单一的，部署仲裁的最佳方式。有几个因素可能会影响您的见证和仲裁资源的行为方式。这些因素包括：

1. 您的部署是本地、云还是混合

在存在额外存储设备（例如光纤通道存储、电源控制设备或连接或传统 stonith 设备）的本地数据中心中部署将为客户提供可能不驻留在云中的仲裁和见证功能的额外选项。同样，云和混合环境在可以部署的内容以及正在部署哪些用例仲裁以防止这些方面存在差异。 此外，延迟要求和差异可能会限制可用于仲裁/见证配置的设备和资源类型。  

2. 你的恢复目标

在设计和构建仲裁和见证资源时，恢复目标也很重要。在示例两节点集群（节点 A 和节点 B）中，当节点 A 失去与节点 B 的连接时，恢复的最高优先级是什么。 如果见证/仲裁资源与节点 A 在同一网络中，这可能导致节点 A 保持在线，但与客户端断开，而节点 B 无法评估仲裁和接管。同样，如果仲裁设备仅存在于具有节点 B 的区域、数据中心或网络中，则丢失可能导致资源故障转移到已失效的网络或中心或远离功能和操作的主节点。

3. 基础架构中可用数据中心（或区域）的冗余

数据中心或区域的冗余也是具有仲裁/见证的 HA 拓扑中的一个重要因素。 如果您的数据中心只有两个级别的冗余，您必须了解将仲裁/见证节点放置在与主集群节点或备用集群节点相同的数据中心之间的权衡。 如果数据中心有两个以上的冗余层，例如第三个可用区或访问第二个区域，此选项将为集群提供更高级别的冗余。

4. 容灾要求

了解您真正的灾难恢复需求也是您设计中的一个主要因素。 如果您的集群管理器软件需要访问仲裁/见证以便从整个数据中心中断（或区域故障）中恢复，那么您需要了解这对您的设计的影响。许多高可用性软件包都有适用于这种情况的工具或方法，但如果您的软件没有，您的仲裁/见证人的设计和放置可能需要适应这一现实。

5. 集群内的成员数量及其位置

当集群包含奇数个节点时，通常不需要额外的仲裁/见证服务器。但是，如果在一个集群中只使用两个节点或部署一个并不总是可用的 DR 节点可能会改变您的架构。作为客户体验副总裁，我曾与部署了三个节点架构的客户合作，但为了节省成本，他们会自动定期关闭第三台服务器。

6.操作系统和集群管理器

关于仲裁/见证的最后一个因素是集群管理器和操作系统。在仲裁/见证的部署或仲裁状态的仲裁方面，并非所有的 HA 软件和集群管理器都是平等的。一些集群软件需要共享磁盘进行仲裁，其他更灵活地允许共享（NFS、SMB、EFS、Azure 文件和 S3）。了解您的集群管理器需要什么，以及它在仲裁方面支持的模式（简单多数、见证、文件共享等）不仅会影响您部署的内容，还会影响您的部署方式。

部署仲裁/见证服务器的唯一最佳方法是了解供应商对仲裁/见证的定义及其可用选项，了解您的要求，考虑数据中心（或云环境）提供的限制或机会并构建解决方案为您的关键系统提供最高级别的保护，防止出现裂脑、错误故障转移和停机。

-Cassius Rhue，客户体验副总裁