为什么需要业务连续性计划

Facebook、Instagram 和 WhatsApp 刚刚度过了一个非常糟糕的星期一

东海岸的工作日结束了，我看到 Facebook 仍然不可用。 Facebook 在以下两条推文中承认了这个问题。

虽然我们不知道停机的确切原因，也不知道是用户错误、恶意攻击还是意外灾难性的错误，但我们可以在这一点上了解一些有关此停机的信息。

停机时间很昂贵

虽然我们可能永远不知道今天所经历的停机时间的确切成本，但有一些成本已经可以衡量。 截至撰写本文时，Facebook 股价今天下跌 4.89%。 这是在 Facebook 和其他科技股本已残酷的 9 月之上。

但公司的真正成本是多少？ 随着许多品牌将社交媒体作为其营销推广的重要组成部分，这种中断将如何影响未来的广告支出？ 如果广告商还没有调查其他社交媒体平台，我至少希望他们调查一下。 只有时间会证明一切，但即使在这次中断之前，我们已经看到来自其他平台的营销支出竞争更加激烈，例如滴答声.

为最坏的情况做计划

事情发生了，我们知道这一点并为此做好计划。 业务连续性计划（BCP）应写入地址任何可能的灾难。 同样，我们不知道这场特殊灾难的确切原因，但我必须想象一下，5 小时以上的 RTO 没有写入 Facebook、Instagram 或 WhatsApp 货架上的任何 BCP。

你的 BCP 里有什么？ 你有没有想过任何可能的灾难？ 您是否衡量了停机时间的影响并为您的业务的每个组成部分定义了足够的恢复时间目标 (RTO) 和恢复点目标 (RPO)？ 我敢说，不可能为所有可能出错的事情做好计划。 但是，我建议每个人定期重新访问您的 BCP 并对其进行更新，以包括您上次查看 BCP 时可能没有注意到的灾难。 您的 BCP 是否有全球流行病？ 如果没有，您可能已经忙于适应“在家工作”的劳动力。 关键是，做最坏的打算，抱最好的希望。

灾难中的通讯

发生灾难时的通信应该是您 BCP 中的一章。

一名 Facebook 员工告诉路透社，所有内部工具都已关闭。 追踪此事的人士表示，Facebook 的回应变得更加困难，因为员工在关闭期间无法使用自己的一些工具。

多名员工表示，他们没有被告知出了什么问题。

https://www.reuters.com/technology/facebook-instagram-down-thousands-users-downdetectorcom-2021-10-04/

一个真正强大的 BCP 必须包括多种备用通信方式。 随着您的业务分布在多个建筑物、地区或国家/地区，这一点变得更加重要。 想想你的团队今天是如何沟通的。 电话、短信、电子邮件、Slack 可能是你的前四名。 但是，如果它们都不可用，您将如何联系您的团队呢？ 如果您不知道，您可能想开始研究其他选项。 您可能不需要短波收音机和一群信鸽，但我敢肯定，有一个政府机构可以将这两样东西放在手边，以应对“紧急情况下的碎玻璃”情况。

概括

您对您自己、您的客户和您的投资者有责任确保您对您的业务的可用性采取一切预防措施。 确保您在创建 BCP 时投入了足够的资源，并且负责业务连续性的团队拥有他们需要的工具，以确保他们能够在满足 BCP 中定义的 RTO 和 RPO 方面发挥自己的作用。

修复您的云之旅

在某种程度上，2020 年和 2021 年改变世界的事件几乎重塑了我们所知道的一切，高可用性也不例外。 尽管关闭和限制，许多 IT 团队还是将本地数据中心换成了云。许多人都在问，“现在怎么办？”以下是解决 2022 年云之旅的五件事。

1. 添加高可用性

   在推动云计算的过程中，许多 IT 和业务领导者发现自己急于将服务和应用程序从因 COVID-19 而关闭的数据中心迁移到云中。 其他人涌向云端，不是因为数据中心关闭，而是为了应对需求爆炸的浪潮。 对于一些人来说，云之旅是如此之快，以至于 HA 不包括在内，现在他们发现了应用程序仍然在云中崩溃的艰难方式，意外中断和计划外停机仍然是 AWS、Azure 和GCP 与以前的数据中心一样多。

   修复云之旅的第一步是添加一个C . 这对您的企业意味着几件事：

   • 设计和构建高可用性和冗余架构
   • 选择将保护关键组件和应用程序的软件和服务
   • 定义和记录相关的流程和程序，以及至少最低限度的治理
   • 为质量保证、程序测试和混沌测试部署生产副本

2. 扩展以提高灾难恢复的可用性

   当然，并不是每个人都在不考虑某种形式的 HA 的情况下迁移到云。 一些 IT 团队有先见之明，不会将 HA 留在本地，但在急于上云的过程中，他们将所有关键服务器都移到了同一个云可用区。 虽然拥有一些 HA 保护比完整的漏洞要好，但如果您只将服务器和应用程序部署在单个可用区 (AZ) 中，现在是时候为备用集群节点扩展到多可用区，甚至内置通过在不同区域部署第三个节点进行灾难恢复。 SIOS 已帮助数十家客户规划多可用区架构并添加灾难恢复解决方案。

3. 建立你的团队

   一夜之间，一些公司及其 IT 团队从完全本地化转变为与 Cloud Formation 模板、快速入门指南、IAM 角色、内部负载均衡器、覆盖 IP 以及破译 VM 大小的确切含义有关。现在是组建团队来支持云之旅的时候了。这将意味着几件事：

   • 增加容量。除非您能够完成一个完整的提升和转变，否则您可能会拥有相同的员工来管理云和本地应用程序。传统解决方案以喜怒无常而著称，需要大量工作才能保持稳定和可用。要驾驭未来的云之旅，您需要能够满足可用性要求、了解云架构并为企业需求规划前进方向的能力。
   • 通过培训提高技能。为您的团队提供云培训。要管理和规划课程，请通过有关云解决方案、架构、最佳实践和权衡的额外培训，寻找方法来增强组织内的 IT 卓越性。训练有素的员工不仅会在提高可用性方面获得红利，而且还会通过以经济、可扩展和合乎逻辑的方式解决可用性、维护和增长问题，从而获得红利。翻译：他们会在构建云基础架构的其余部分时避免浪费金钱。

4. 集成自动化和分析

   作为 SIOS Technology Corp. 的客户体验副总裁。 我曾与几家公司合作，这些公司在 2021 年迁移到云，而没有牺牲 HA、DR 或他们的团队。如果您认真对待达到所需的正常运行时间数（99.99%）并且制定灾难计划是不可协商的，那么是时候增加分析和额外监控的严格性了。 确保您的可用性解决方案具有应用程序感知自动化和编排功能，以便在发生灾难或计划外停机时进行恢复。 添加分析和自动化以巩固您的解决方案，并使您的云迁移从被动故障转移到主动通知和故障发生前的缓解。想象一下，如果应用程序性能不佳，或者延迟增加、错误或 VM 无响应行为及时得到通知，以避免在业务高峰期出现停机。 分析也很重要，因为它们可以揭示可能已经逃离原始可用性架构的系统和应用程序。

5. 更新流程和治理

   我们认为失败的许多事情都植根于过程的失败。 确保您组织的流程是最新的、有据可查的、适当的沟通和遵守。 这些流程应包含与谁、什么、何时、何地以及如何与客户相关的业务战略、目标和组织需求相关的一些关键最低要求。

   确保您的新云环境的所有权和签核流程有据可查。 对于从获取基础架构的硬件团队转移到云团队的客户，我亲眼目睹了来自冲突、冲突或未解决的角色和责任的挫败感。 在迁移中糊涂是一组痛点，在没有明确治理的情况下从灾难中挖掘出来是一个更大、成本更高的问题。

   如果您已经实现了向云的飞跃，那么留在那里并使其为您工作是旅程的下一部分。如果您的云之旅突然或崎岖不平，请考虑这五点来修复您的云之旅，并了解 SIOS 技术不仅可以帮助您提高云中的高可用性，还可以帮助您提高在云中运行的流程。

经授权转载西欧

如何安装 SIOS DataKeeper Cluster Edition 许可证密钥

一旦你安装了SIOS DataKeeper 集群版软件并已激活您的许可证，您需要先安装许可证密钥，然后才能开始。 这个 4 分钟的视频将回顾如何安装 SIOS DataKeeper Cluster Edition 软件并演示如何激活您的许可证以开始保护您的关键应用程序。

观看 SIOS 支持代表演示安装 SIOS 许可证所需的三个关键先决条件中的每一个：确保您拥有 SIOS DataKeeper 软件的最新版本和更新；使用我们简单的许可证密钥管理器来验证您的激活的许可证从购买的权利，下载并应用许可证密钥并开始您的SIOS DataKeeper 软件.

该视频还介绍了访问我们的过程SIOS 文档门户，您可以在其中找到详细说明 SIOS DataKeeper Cluster Edition 的发行说明、安装指南、技术文档和信息，以及有关 SIOS 的各种主题。

查看有关如何快速简单地完成步骤的提示和方便的见解。现在您开始使用 SIOS DataKeeper 集群软件保护您的关键应用程序

 

提高集群弹性、性能和结果的四种避免策略

在 SIOS Protection Suite 集群环境中部署的简单步骤

避免某些事情——我们以前都做过。我们在与配偶散步时在商店里看到的旧情人，在我们“不准备购买”时看到的销售人员，甚至在我们“度假”时看到的老板。当我是一个开发团队的经理时，我瞥见了一个直接报告在他们应该不在办公室的时候在商店里浏览。他们躲在衣架之间，匆匆跑下下一个过道，匆匆离开。我们以前都这样做过，在某些情况下，出于心理健康、身体健康或隐私和个人原因，我们都需要采取一些避免措施。即使在 HA。那么，您如何为您的高可用性环境添加规避功能，为什么？

在高可用性中使用回避策略的四个理由

1. 更好的性能（最小化服务器过载）

在 HA 中使用避免策略的原因之一是提高应用程序和服务器性能。考虑运行生产工作负载的三台服务器的情况，我们称它们为 Server Alpha、Server Beta 和 Server Gamma。服务器 Alpha 和 Beta 运行由数据库支持的关键应用程序，而服务器 Gamma 运行报告和数据转换作业。如果 Server Alpha 出现故障，通常会发生故障转移到 Server Beta。但是，由于服务器 Beta 已经在运行大量工作负载，因此产生的额外应用程序负载可能会导致服务器过载和两个应用程序的性能不佳。因此，部署避免策略以确保选择 Server Gamma 作为故障转移目标可能是明智之举。

2. 性能优化

再次考虑三个服务器的场景，Alpha、Beta 和 Gamma。服务器 Alpha 和 Beta 可扩展以处理峰值工作负载，而服务器 Gamma 是成本优化的服务器。如果 Server Alpha 和 Server Beta 出现故障，则会发生故障转移到成本优化的服务器 Gamma。但是，此服务器无法扩展以处理峰值工作负载，也无法同时处理 Server Alpha 和 Server Beta 的工作负载。在这种情况下，可以使用避免策略通过在另一台主机可用时立即从 Server Gamma 自动移动一个或两个工作负载来优化性能。

3. 高可用优化

HA 优化是另一种部署回避策略的场景。 与性能优化策略一样，HA 优化用于确保您的环境能够承受大多数故障情况，并且您的应用程序经过优化以在任何时间点提供最高级别的可用性。HA 优化对于具有复制入队进程的 SAP 等应用程序很重要。在任何 SAP 环境中，您都不希望 ASCS（ABAP SAP 中央服务）和 ERS（入队复制服务）实例长时间驻留在同一服务器上，因为存在丢失锁定和取消作业的风险。 为了防止这种情况发生，您可以使用避免策略，使 ERS 和 ASCS 实例始终在相对的集群节点上运行。考虑运行生产工作负载的三台服务器的情况，我们将它们称为服务器 Alpha、Beta 和 Gamma。Server Alpha 正在运行 ASCS 实例，而 Server Beta 正在运行 ERS 实例。服务器 Gamma 用作服务器 Beta (ERS) 和服务器 Alpha (ASCS) 故障转移的第三个节点。如果 Beta 崩溃，您不希望 ERS 资源与 ASCS 实例在同一节点上运行。为确保此操作，您可以部署避免策略，首先自动检查并确保两个应用程序位于不同的服务器上，并维护 SAP ASCS/ERS 锁定故障转移的最佳实践。

4. DR 避免

假设您有两个数据中心：City Alpha 和 City Beta，它们相距大约 70 英里，您的大多数客户都位于它们之间的中心。 但是，由于最近内部组织的变化、合并/关闭和收购以及治理要求，您的 IT 团队必须添加位于 City Gamma 的第三个数据中心，距离 Alpha 和 Beta 大约 350 英里。现在主要在 Alpha 和 Beta 中受到保护的资源也扩展到了 Gamma 位置。鉴于大多数用户和团队都在 Alpha 和 Beta 位置附近，即使是最极端的用户也位于邻近城市，您的团队需要避免故障转移到 Gamma 位置。 与其他策略一样，DR 避免寻求通过避免 DR 节点来优化性能、输入/输出区域数据成本、延迟和客户端访问，如果任一区域内只有一个节点发生故障。它还可以确保即使两个节点在不同的时间后都发生故障，在转移到 DR 之前，故障转移总是发生在集群或数据中心中的另一个节点上。那么，您如何部署回避策略呢？许多提供程序具有可以配置的关联规则，而其他提供程序使用服务器优先级或手动步骤的组合。对于适用于 Linux 的 SIOS 保护套件，您可以使用多种内置方法，包括：

1. 资源优先级

如果发生故障，资源将故障转移到它们具有最低剩余优先级的服务器并级联到任何其他服务器（Alpha、Beta 和 Gamma）。Server Alpha 是Resource.HR 的主服务器，Server Beta 是Resource.MFG 的主服务器，Server Gamma 是所有资源/服务器的备份服务器。使用资源优先级，Resource.HR 在服务器 Alpha 上的优先级为一 (1)，在服务器 Gamma 上的优先级为二 (2)。而 Resource.MFG 在服务器 Beta 上的优先级为一 (1)，在服务器 Gamma 上的优先级为二 (2)。如果客户想要优化环境的使用，那么 Resource.HR 在 Server Beta 上的优先级可以是三 (3)，Resource.MFG 在 Server Alpha 上的优先级可以是三 (3)。如果服务器 Alpha 发生故障，资源 Resource.HR 将首先失败到服务器 Gamma，然后再尝试在服务器 Alpha 上投入使用（恢复）。

适用于 Linux 的 SIOS 保护套件（UI 和 CLI）允许用户为每个服务器和资源组合指定优先级。

2. 策略或关联规则

策略规则还可用于防止在给定服务器上发生资源恢复，从而允许资源避开可能正在运行更关键或资源密集型工作负载的指定服务器。典型的政策包括：

• • • • • • 默认情况下将阻止来自特定服务器的应用程序的约束策略。
          • 将阻止应用程序来自没有足够资源的服务器的资源策略
          • 定义允许或禁止资源进入系统的时间段的临时策略
          • 定义首选服务器或集群内可能的应用程序所有权能力的自定义策略。

SIOS Protection for Linux CLI 允许用户指定策略规则，这些规则可以禁用故障转移到指定服务器的特定资源、提供保护故障的临时策略、禁用特定应用程序类型的故障、约束策略和自定义策略。

• 特定规避资源

建立资源避免策略的最细粒度的方法是在每个层次结构中部署特定的避免脚本。这种方法将允许用户配置特定的应用程序（例如 app1 和 app2），尽可能避免彼此，同时允许其他应用程序不受限制地运行。在我们的三个服务器（Alpha、Beta 和 Gamma）以及三个资源 app1、app2 和 app3 的情况下，此方法将提供最大的灵活性。在这个例子中，app1 和 app2 将在服务器出现故障时寻求避免搭配，但 app3 将根据优先级失败到下一个可用节点，没有任何搭配限制。

有关避免策略和资源的其他示例，请考虑适用于 Linux 的 SIOS 保护套件文件.如果客户有两个应用程序 app1 和 app2，他们需要尽可能在不同的节点上运行，则客户可以使用 SIOS Protection Suite for Linux gen/app 资源和 '/opt/LifeKeeper /lkadm/bin/avoid_restore' 脚本。

– 客户体验副总裁 Cassius Rhue

转载自SIOS

Windows 集群

Windows 集群

如何在 Windows 中实现高可用性

为减少系统停机时间并确保 Windows 的高可用性，IT 最佳实践建议您将服务器（或节点）集群化，以便在一个节点出现故障时，一个或多个其他节点自动接管处理。 这也称为 Windows 群集。

需要集群软件来监控主节点的健康状况并在检测到问题时启动恢复操作。 HA 集群还需要一种方法来确保在发生故障时辅助节点访问存储中数据的最新版本。在大多数情况下，这是通过将集群的所有节点连接到同一个共享存储来实现的。 集群节点应该在地理上分开，以保护应用程序免受站点范围和区域性灾难的影响。

在 Windows Server 环境中，Microsoft 在 Windows Server 平台中包含了 Windows Server 故障转移群集 (WSFC)。

什么是 Windows Server 故障转移群集？

使用 WSFC，每个活动节点都有一个具有相同硬件规格并共享相同存储的备用节点。 第三个节点通常配置为“见证”服务器，其唯一目的是确保主节点正常运行，如果检测到问题，则向备用节点发出故障转移操作的需要。

除了监控集群的健康状况外，WSFC 中的节点还协同工作，共同提供：[1]

• 资源管理 –单个节点提供物理资源，例如 SAN 和网络接口。 托管的应用程序注册为集群资源，并且可以配置对其他资源的启动和运行状况依赖性。
• 故障转移协调——每个资源都托管在一个主节点上，可以自动或手动转移到一个或多个辅助节点。 发生故障转移时会通知节点和托管应用程序，以便它们能够做出适当的反应。 WSFC 与 Microsoft Always On 可用性组和 Always On 故障转移群集协同工作以协调 Microsoft SQL Server 环境中的故障转移。

SIOS DataKeeper 如何补充 WSFC

WSFC 需要共享存储以确保所有集群节点在发生故障转移时访问最新数据。 通常，公司使用昂贵的 SAN 硬件来确保数据冗余。 SAN 代表单点故障风险。 而且，如果您想在具有相同 Windows Server 故障转移群集保护的云中运行您的应用程序，则没有可用的 SAN。

SIOS DataKeeper 集群版通过消除对共享存储的需求，无缝集成并扩展 WSFC 和 SQL Server Always On Failover 群集。 它提供性能优化的、基于主机的复制，以同步所有集群节点中的本地存储，创建无 SAN 集群。 当 WSFC 管理集群时，SIOS DataKeeper 执行存储的同步或异步复制，让备用节点在发生故障转移时立即访问最新数据。 SIOS DataKeeper 不仅消除了 SAN 的成本、复杂性和单点故障风险，还允许您在本地存储中使用最新的快速 PCIe 闪存和 SSD，以单一成本实现性能和保护 -有效的解决方案。

使用 SIOS DataKeeper，您还可以平衡每个应用程序的网络带宽和 CPU 利用率。

• 如果快速复制至关重要，SIOS DataKeeper 可以实现 90% 以上的带宽利用率以加速数据同步。
• 如果最小化网络影响是您的首要任务，SIOS DataKeeper 提供集成的压缩和带宽限制。

此外，SIOS DataKeeper 的目标快照功能让您可以从辅助节点运行时间点报告，以卸载可能影响主节点性能的工作负载。 这使您可以更快地查询和运行报告并做出更快的决策。

与 WSFC 配合使用，SIOS DataKeeper Cluster Edition 使用您选择的行业标准硬件和本地附加存储在“无共享”或无 SAN 配置。[2] SIOS DataKeeper 还为云环境中的关键业务应用程序提供高可用性和灾难恢复保护，例如 Amazon Web Services (AWS)、Microsoft Azure 和 Google Cloud Services，而不会牺牲性能。

SIOS 保护套件 – 在没有 WSFC 的情况下保护 Windows 环境

适用于 Windows 的 SIOS 保护套件包括 DataKeeper、SIOS LifeKeeper 和可选的应用程序恢复工具包，用于领先的应用程序和基础设施操作。 它是一个紧密集成的集群解决方案，结合了高可用性故障转移集群、连续应用程序监控、数据复制和可配置的恢复策略，以保护您的业务关键应用程序和数据免受停机和灾难的影响。

分布式元数据和通知

WSFC 服务和节点的元数据/状态托管在集群中的每个节点上。 当任何节点上发生更改时，更新的信息会自动传播到所有其他节点。

SIOS 保护套件不需要 WSFC，因为 SIOS 会监控应用程序环境（包括服务器、操作系统和数据库）的健康状况。 它可以在本地和同一站点或其他位置的另一个集群服务器上停止和重新启动应用程序。 当检测到问题时，SIOS 保护套件会自动执行恢复操作并自动管理级联和优先级故障转移。

借助 SIOS 保护套件，您可以使用您选择的 SAN 或 SANless 集群，使用各种存储设备，包括直连存储、iSCSI、光纤通道等。

SIOS Protection Suite for Windows 可以满足您的高可用性和灾难恢复需要在单个站点内和跨多个站点。

流行的 SIOS Windows 集群解决方案

下面将更详细地讨论一些最流行的 SIOS Windows 集群解决方案——适用于 SQL Server、SAP 和基于云的环境。

适用于 SQL Server、SAP、S/4HANA 和 Oracle 的 Windows 集群

SIOS 为应用程序和数据提供全面的 SAP 认证保护，包括高可用性、数据复制和灾难恢复。 为了在 Windows 环境中保护 SAP，SIOS 保护套件包括 SIOS LifeKeeper，它可以监控整个应用程序堆栈。 无论您是将其与 SAP 一起使用还是运行独立的 Oracle 应用程序，SIOS 都会保护您的 Oracle 数据库——您只需选择与您的配置相匹配的应用程序恢复工具包。

云中的 Windows 集群

无论您是需要 SIOS DataKeeper 在云中启用 Windows Server 故障转移群集，还是需要 SIOS Protection Suite for Windows 进行应用程序监控和故障转移编排，以及高效的块级数据复制，SIOS 都能提供完整的配置灵活性。 SIOS 允许您在物理、虚拟、云或混合云基础架构的任意组合中创建集群。 例如，使用 WSFC，SIOS DataKeeper 可以：

• 将关键的本地或混合业务应用程序保护到 AWS、Azure 或 Google Cloud 中的高可用性 Windows 环境。
• 通过在 AWS、Azure 或 Google Cloud 中创建 Windows 集群来保护云应用程序，例如 SQL Server 和 SAP。
• 通过跨云可用性区域或区域故障转移应用程序实例，提供站点范围、本地或区域的高可用性和灾难恢复保护。

SIOS DataKeeper Cluster Edition 可以提供跨云的高可用性集群保护

结论

SIOS 提供支持广泛的应用程序、操作系统和基础架构环境的产品，提供可以处理所有高可用性需求的单一解决方案。 以下只是展示 SIOS 强大功能的几个示例。

• 西澳大利亚的珀斯体育场实施了带有 WSFC 的 SIOS DataKeeper，为其 Hyper-V 虚拟机提供高可用性。
• 支付宝 ( paygoutilities.com )，总部位于美国，使用 WSFC 实施 SIOS DataKeeper，为 AWS 上的 SQL Server 提供高可用性。
• 总部位于日本的 Toyo Gosei 使用 WSFC 实施了 SIOS DataKeeper，为他们在 Azure 上的 SAP 应用程序提供高可用性和灾难恢复。

有关支持 Windows 环境的高可用性/灾难恢复解决方案的更多信息，请单击此处[TM(1].

参考https://www.techopedia.com/definition/24358/windows-clustering https://searchwindowsserver.techtarget.com/definition/Windows-Server-failover-clustering https://docs.microsoft.com/en-us/sql/sql-server/failover-clusters/windows/windows-server-failover-clustering-wsfc-with-sql-server?view=sql-server-ver15[1] https://docs.microsoft.com/en-us/sql/sql-server/failover-clusters/windows/windows-server-failover-clustering-wsfc-with-sql-server?view=sql-server-ver15[2]无共享架构 (SN) 是一种分布式计算架构，其中每个更新请求都由单个节点（处理器/内存/存储单元）满足。 https://en.wikipedia.org/wiki/Shared-nothing_architecture转载自SIOS