SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

通过高可用性实现 IT 弹性

by Leave a Comment

通过高可用性实现 IT 弹性

通过高可用性实现 IT 弹性

什么是 IT 弹性？

IT 弹性是组织在业务运营、关键流程或 IT 生态系统中断时保持可接受的服务水平的能力。 在这个数字时代，高可用性对您组织的成功至关重要。 您的客户不会容忍被关闭的网站。 而且，您也无法承受瘫痪的 ERP、CRM 或其他关键业务系统。 这是哪里高可用性进来。

您的组织必须“勾选”许多不同的技术和解决方案，以确保 IT 弹性——其中最重要的是确保您至少拥有备份、灾难恢复、网络弹性和高可用性解决方案。 出于本文的目的，我们将讨论高可用性 (HA) 作为确保 IT 弹性所需的关键要素之一。

什么是高可用性？

当您的系统、应用程序和网络出现故障时，高可用性系统可确保业务运营继续进行——对客户和用户完全透明。 HA 是技术系统的一个组成部分，可消除单点故障以确保长时间的连续运行或正常运行。 高可用性系统包含五个设计原则：自动故障转移、自动检测应用程序级故障、无数据丢失、自动快速故障转移到冗余组件，以及用于计划维护的按钮式故障转移和故障恢复。

———————————————————————————————————————————————

IT 弹性和高可用性——非示例！

去年 8 月，日产集团位于丹佛的数据中心因停电而崩溃。 受影响的系统在内部称为 NNANet。 它是一种 Nissan 解决方案，供员工订购汽车/零件、管理产品折扣销售、获取车辆召回信息、提交定价和开始服务工作所需的保修索赔以及获取融资信息。NNANet 被描述为 Nissan 的命脉，因为 Nissan 所做的一切都通过 NNANet。

该系统持续停机四天，影响了许多零售商的运营和两家工厂的生产系统。 该公司、其零售商和客户都受到了影响。

影响

显然，这是一个正确配置、正确定位的高可用性系统本可以节省时间或至少将崩溃的影响降到最低的例子。 对于“消费者、零售商、分销网络、制造工厂和金融公司之间的贸易”而言，高可用性实际上变成了一场灾难。都受到了四天的影响。[1]由于车祸，日产将当月的经销商销售目标重置了 10%。 日产及其经销商/零售商/合作伙伴的总体财务影响仍有待观察。

IT 弹性——一个真实的例子！

Cayan™ 是支付技术的领先供应商，其 Genius Customer Engagement Platform® 将当前和未来所有可能的交易技术、支付类型和客户计划聚合并集成到一个平台中。 Genius 平台以及 Cayan 的其他关键任务应用程序都在 SQL Server 上运行。

Cayan 的客户包括一些世界上最大的在线零售商，这些公司对停机时间没有容忍度。 Cayan 首席技术官 Paul Vienneau 表示：“我们的首要任务是确保我们的客户可以每周 7 天、每天 24 小时不间断地完成交易。

Cayan 需要高可用性和灾难恢复用于他们的 SQL Server 数据库的系统。 该公司考虑使用传统的共享存储集群，但 SAN 解决方案成本高、管理复杂，并且会带来与单点故障相关的风险。

出于这些原因，Cayan IT 员工决定使用 SIOS #SANLess 集群。 SANLess 集群使用本地存储，因此性能开销最小，应用程序响应时间快。 SIOS 软件 SIOS DataKeeper 与 Windows Server 故障转移群集 (WSFC) 集成。 SIOS 使用高效、实时、数据复制同步主集群节点和远程集群节点中的本地存储，使它们在 WSFC 中表现为虚拟 SAN。

影响

自从部署 SIOS SANless 集群以来，Cayan 没有遇到任何停机或数据丢失。 首席技术官 Paul Vienneau 评论道：“我们对 SIOS DataKeeper 软件非常满意。 它达到或超出了我们的预期。 实施和持续管理很容易，自从我们实施 SIOS SANLess 集群以来，我们的停机时间为零。”没有要报告的客户满意度问题，没有收入损失，没有无效率的员工，没有业务中断。

———————————————————————————————————————

SIOS：通过高可用性实现 IT 弹性

SIOS DataKeeper™ 使用高效的块级复制来保持本地存储同步，使集群中的辅助节点能够在故障转移后继续运行并访问最新数据。

SIOS 产品独特地保护在物理、虚拟、云或混合云环境以及站点或灾难恢复场景的任意组合中运行的任何基于 Windows 或 Linux 的应用程序，为 SAP S/4HANA 和数据库等应用程序实现高可用性和灾难恢复，包括 Oracle、SQL Server、DB2 等。 SIOS 产品的“开箱即用”简单性、配置灵活性、可靠性、性能和成本效益使其与其他集群软件区别开来。

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

在 Linux 环境中，SIOS LifeKeeper™ 和 SIOS DataKeeper for Linux 提供了高可用性的紧密集成组合故障转移集群、持续的应用程序监控、数据复制和可配置的恢复策略，保护您的关键业务应用程序免受停机和灾难的影响。

无论您是在 Windows 还是 Linux 环境中，SIOS 产品都可以将您的 IT 团队从创建和管理高可用性计算基础架构的复杂性和挑战中解放出来。 它们提供了 IT 经理保护关键业务应用程序免于停机或数据丢失所需的智能、自动化、灵活性、高可用性和易用性。

SIOS = 具有 HA + DR 的 IT 弹性

备份、高可用性、灾难恢复和网络弹性都是实现 IT 弹性的重要因素。 借助 SIOS 解决方案，您可以“勾选”高可用性和灾难恢复——两种解决方案合二为一。 通过复制到多个目标的能力，您可以配置一个多节点故障转移集群，节点位于多个位置，以保护您的系统免受故障和灾难的影响。

欲了解更多信息，并确保IT弹性为您的组织，获得免费演示今天的 SIOS。

参考：

经授权转载SIOS

如何通过集群实现高可用性

by Leave a Comment

 

如何通过集群实现高可用性

什么是高可用性？

高可用性(HA) 是技术系统的一个组成部分，可消除单点故障以确保长时间的连续运行或正常运行。 高可用性集群是支持需要最少停机时间和持续可用性的关键业务应用程序的服务器组。

所有组织都使用各种关键业务数据库和应用程序，例如数据仓库、电子商务应用程序、客户关系管理系统 (CRM)、财务系统、供应链管理和商业智能系统。 当系统、数据库或应用程序出现故障时，这些组织需要高可用性保护来保持系统正常运行，并将收入损失、员工效率低下和客户不满的风险降至最低。

高可用集群包含五个设计原则：

  • 当活动组件出现故障时，它们会自动故障转移到冗余系统以进行操作。 这消除了单点故障。
  • 无论原因如何，它们都可以在发生应用程序级故障时自动检测它们。
  • 它们确保在系统故障期间不会丢失大量数据。
  • 它们会自动快速地故障转移到冗余组件，以最大限度地减少停机时间。
  • 它们提供手动故障转移和故障恢复的能力，以最大限度地减少计划维护期间的停机时间。

TechTarget 将 HA 定义为“一个系统或组件，可以持续运行很长时间。 可以相对于“100% 运行”或“永不失败”来衡量可用性。一个广泛持有但难以实现的系统或产品可用性标准被称为‘五个 9’ (99.999%) 的可用性。”但让我们用简单的术语定义高可用性：

高可用性可确保您的系统、数据库和应用程序在需要时运行。

“何时”考虑了应用程序必须启动和运行的时间百分比。 “根据需要”考虑了系统、数据库和/或应用程序的正常运行，不会丢失数据。

根据系统和/或应用程序，高可用性会有所不同。 例如，对于关键任务应用程序，例如您的电子商务系统，四个 9 (99.99%) 的可用性被视为行业标准。 凭借 99.99% 的可用性，您预计每年的停机时间不会超过 52.60 分钟或每天的停机时间不超过 8.64 秒。 但是，对于非关键应用程序和系统，例如单个桌面故障，高可用性可能是两个 9 (99%)，这相当于每年 8.77 小时的停机时间或每天 1.44 分钟的停机时间。 在衡量可接受的停机时间时，重要的是要考虑：

  • 计划外停机（例如，硬件或软件故障）
  • 日常硬件和软件维护所需的计划停机时间
  • 数据库和应用程序级别的正常运行时间

您对高可用性的选择取决于许多因素，包括应用程序对业务的重要性、客户是否受到影响、应用程序运行的频率、受影响的用户数量、数据库或应用程序必须以多快的速度故障转移到冗余系统，以及可以容忍的数据丢失量。

高可用性指标：RTO 和 RPO

通常用于评估 HA（以及灾难恢复 (DR)）的两个指标是恢复时间目标 (RTO) 和恢复点目标 (RPO)。

  • RTO 是任何中断的最大可容忍持续时间。 在线事务处理应用程序通常具有最低的 RTO，而那些关键任务的 RTO 通常只有几秒钟。
  • RPO 是发生故障时可以容忍的最大数据丢失量。 对于 HA，RPO 通常为零，以指定在所有故障情况下都应为零数据丢失。

但是，您可以实现哪些 RTO 和 RPO 来支持高可用性与灾难恢复. 有了 HA，数据复制可以是同步的，因为您的冗余组件位于您的 LAN 环境中。 活动和备用数据库可以同时更新，从而实现完全、自动、实时的恢复，可以满足最苛刻的 RTO 和 RPO。 因此，您的备用实例是“热的”并且与您的活动实例同步，因此它可以在发生故障时立即接管。

但是，要在发生灾难时恢复系统、软件和数据，需要在广域网 (WAN) 上安装冗余组件。 这很重要，因为您必须将冗余组件保留在远离活动实例的地理位置。 但是对于 WAN，数据复制是异步的，以避免对吞吐量性能产生负面影响。 这意味着对备用实例的更新将滞后于对活动实例的更新，从而导致恢复过程的延迟。 由于灾难很少发生，一些延迟可能是可以容忍的，并且取决于 (a) 实现尽可能低的 RTO 和 RPO 对您的业务有多重要，以及 (b) 您可以分配多少预算来实现最佳 RTO 和 RPO。

SIOS 如何帮助您实现高可用性

SIOS 提供单一解决方案来满足各种操作系统、基础架构环境和应用程序的高可用性和灾难恢复需求，包括 SAP、SQL Server、Oracle 和其他运行在基于 SAN 的共享存储配置或 SAN 的环境中，本地数据存储配置。

  • 视窗环境：当添加到 Windows Server 故障转移群集 (WSFC) 环境时，SIOS DataKeeper 允许您创建无 SAN 群集，其中共享存储群集是不可能或不切实际的，或者在基于 SAN 的 Windows 群集中添加复制以进行灾难保护。 快速、高效的基于主机的复制同步本地和远程集群节点上的本地存储，在物理、虚拟或云环境的任意组合中创建无 SAN 集群。
  • Linux 环境：适用于 Linux 的 SIOS 保护套件是一个打包的聚类软件使用 SIOS LifeKeeper 和 SIOS DataKeeper 提供高可用性故障转移集群、持续应用程序监控、数据复制和可配置恢复策略的紧密集成组合的解决方案，以保护您的业务关键应用程序和数据免受停机和灾难的影响。 SIOS 保护套件让您可以使用各种存储设备（包括直连存储、iSCSI 和光纤通道）构建 SAN 或 SANLess 集群。 SIOS Protection Suite for Linux 支持所有主要的 Linux 发行版，包括 Red Hat Enterprise Linux、SUSE Linux Enterprise Server、CentOS 和 Oracle Linux。

使用 SIOS 解决方案，RPO 始终为零，而 RTO 取决于应用程序，但对于某些应用程序，通常为 30 秒到几分钟。 让我们来讨论一位客户在瑞士最大的零售公司中使用 HA 集群的“SIOS in action”案例研究。

Migros 通过 SIOS 高可用性解决方案实现其 POS 系统的关键业务连续性

Migros 是瑞士最大的零售公司、最大的连锁超市以及拥有超过 100,000 名员工的最大雇主。 它也是世界上最大的四十家零售商之一。 Migros 与总部位于瑞士的 IT 服务提供商和 SIOS 解决方案经销商 Realstuff Informatik AG 合作，希望将其销售点 (POS) 系统替换为一个新平台，该平台运行效率更高，并且可以最大限度地减少停机威胁。

新的 POS 系统在 Migros 的 650 家商店中提供价格和产品分类信息，零售商需要一个高可用性解决方案来支持日常销售。 如果没有 HA 系统，员工将无法在系统出现故障时为产品定价或称重货物，从而导致运营陷入停顿。 在评估选项后，Migros 决定需要一个开源服务器环境，提供高可用性和持续数据保护，独立于虚拟环境，并且可以由公司的 IT 员工内部操作。 为了满足这些要求，该团队选择了 SIOS Protection Suite for Linux 进行复制以保护 POS 数据。

在系统设计、客户培训和母语支持方面，Realstuff 与位于德国德累斯顿并由 Computer Concept 运营的中欧和东欧 SIOS 能力和支持中心合作。 对于 Migros 来说，在区域办公时间内从能力和支持中心获得 24x7x365 的支持非常重要。

Realstuff 实施了 SIOS Protection Suite 高可用性解决方案，以持续监控 POS 服务器并复制数据。 在每个商店位置，使用两台服务器来确保持续的数据保护。 如果一台服务器出现故障，第二个实例会立即接管工作。 此外，两台服务器都在监控系统上镜像数据资产。在此处阅读完整的 Migros 案例研究。

最后的想法

区域能力和支持中心与 Realstuff 协商，为实施和启动提供见解和指导，并举办了为期三天的培训研讨会来培训 Migros 团队。 Realstuff 经理兼执行委员会成员 Richard Huber 在部署后评论说，SIOS 高可用性解决方案的优势在于其灵活性、可靠性、易用性以及数据始终保持同步的保证。

如今，Migros 已通过 SIOS 易于使用的解决方案满足其对 HA 的要求，该解决方案提供对服务器、存储、应用程序、数据库和网络连接的持续监控，以检测故障点、减少停机时间、保持客户端连接并提供不间断的数据访问。

有关 SIOS 解决方案以及 SIOS 如何帮助您在 SQL Server 环境中实现 HA 的更多信息，您可以阅读“为什么要为 SQL Server 高可用性建立集群”在这里。

 

转载自SIOS

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

by Leave a Comment

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

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

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

 

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

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

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

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

  • 性能优化

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

  • 高可用优化

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 锁定故障转移的最佳实践。

  • DR避免

假设您有两个数据中心：City Alpha 和 City Beta，它们相距约 70 英里，您的大多数客户都位于它们之间的中心。 但是，由于最近内部组织的变化、合并/关闭和收购以及治理要求，您的 IT 团队必须添加位于 City Gamma 的第三个数据中心，距离 Alpha 和 Beta 大约 350 英里。现在主要在 Alpha 和 Beta 中保护的资源也扩展到 Gamma 位置。鉴于大多数用户和团队都在 Alpha 和 Beta 位置附近，即使是最极端的用户也位于邻近城市，您的团队需要避免故障转移到 Gamma 位置。 与其他策略一样，DR 避免寻求通过避免 DR 节点来优化性能、输入/输出区域数据成本、延迟和客户端访问，如果任一区域内只有一个节点发生故障。它还可以确保即使两个节点在不同的时间后都发生故障，在转移到 DR 之前，故障转移总是发生在集群或数据中心中的另一个节点上。

那么，您如何部署回避策略呢？

许多提供程序具有可以配置的关联规则，而其他提供程序使用服务器优先级或手动步骤的组合。对于适用于 Linux 的 SIOS 保护套件，您可以使用多种内置方法，包括：

  • 资源优先级

如果发生故障，资源将故障转移到剩余优先级最低的服务器，并级联到任何其他服务器（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）允许用户为每个服务器和资源组合指定优先级。

  • 策略或关联规则

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

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

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’ 脚本。

转载自SIOS

 

集群简介 – 第 2 部分

by Leave a Comment

集群简介 - 第 2 部分

集群简介 – 第 2 部分

有哪些类型的集群以及它们如何工作？

HA 集群和负载均衡集群概述

集群通过创建冗余来补偿不可预见的系统故障，有助于提高软件和硬件系统的可靠性和性能。 如果系统因硬件或软件故障或自然灾害而中断，这可能会对业务和收入产生重大影响，浪费关键的时间和费用来恢复和运行。

这是哪里聚类进来。 集群解决方案主要分为三种类型——HA集群、负载均衡集群和HPC集群。 哪种类型最能提高您企业的系统可用性和性能？ 下面让我们更详细地看一下这三种聚类解决方案。

什么是 HA 集群？

高可用性集群，也称为 HA 集群，对于需要近乎连续可用性的任务关键型业务应用程序、ERP 系统和数据库（例如 SQL Server SAP 和 Oracle）非常有效。

HA集群可以分为两种类型，“主动-主动”配置和主动-被动配置。

下面我们来看看这两种HA集群类型的区别。

HA 集群类型 1：双活配置

在双活配置中，处理是在集群中的所有节点上进行的。 例如，在双节点集群的情况下，两个节点都处于活动状态。 如果一个节点停止，处理将被另一个节点接管。

但是，如果每个节点都以接近 100% 的速度运行而一个节点停止运行，则另一个节点将难以承担额外的处理负载。 因此，有余量的容量规划对于 HA 集群很重要。

HA 集群类型 2：主备配置

让我们再次使用我们的双节点示例。 在主备配置中，一个节点配置为主节点，另一个节点配置为备节点。 主用节点和备用节点交换称为“心跳”的信号，以不断检查它们是否正常运行。

如果备节点无法接收到主节点的心跳，则备节点判断主节点已经停止，将接管主节点的处理。 这种机制称为“故障转移”。 相反，恢复停止的操作节点并将处理传输回恢复的活动节点的机制称为“故障回复”。在主备配置中，当发生故障时，从主节点到备节点的简单切换使得恢复相对容易。 但是要考虑到，当运行节点正常运行时，备用节点的资源会被浪费掉。

HA 集群的两个组成部分：应用程序和存储

要使 HA 集群有效，需要解决两个方面的问题：应用程序编排和存储保护。 集群软件监控受保护应用程序的健康状况，如果检测到问题，则将该应用程序的操作转移到备用节点。 备用节点需要访问最新版本的数据——最好与主节点在事件发生前访问的数据相同。 这可以通过两种方式实现：共享存储、无共享存储。 在共享存储模型中，两个集群节点访问相同的存储——通常是 SAN。 在无共享（又名 SANless）配置中，所有节点上的本地存储都使用复制软件进行镜像。

集群软件产品在监控和检测可能导致应用程序故障的问题的能力以及可靠地协调故障转移的能力方面差异很大。 许多集群产品只检测应用服务器是否正常运行，而没有检测到广泛的软件、服务、网络和其他可能导致应用故障的问题。

应用程序意识是必不可少的

同样，复杂的 ERP 和数据库应用程序有多个组件，它们必须存储在正确的服务器或实例上，以正确的顺序启动，并根据复杂的最佳实践上线。 选择带有称为应用程序恢复工具包的专用软件的集群软件，这些软件专为维护应用程序/数据库特定要求的最佳实践而设计。

有多种方式可以配置 HA 集群：

具有共享存储的传统双节点集群

 

两台服务器通过共享存储集群。

两节点 SANless 集群

可以使用本地 LAN 和高速同步块级复制来配置集群。

实时复制可用于将主服务器上的存储与位于同一数据中心、灾难恢复站点或两者中的备用服务器上的存储同步。 这使您可以灵活地构建高可用性和容灾配置；两节点或多节点 SIOS 块级复制针对性能进行了高度优化。 您甚至可以在物理服务器上使用超快速、高速的本地连接存储，例如 PCIe 闪存类型的存储设备，以实现极低成本、高性能、高可用性的配置。您的数据在闪存设备和您的应用程序上也受到保护。

带有第三个节点的基于 SAN 的集群

防灾第三节点

此配置使用基于 SAN 的集群，并将第三个 SANless 节点添加到远程数据中心或云中，并实现全面的灾难恢复保护。在发生灾难时，备用远程物理服务器会自动投入使用，不会丢失数据，从而消除了从备份介质恢复所需的时间。

什么是负载均衡集群？

负载均衡集群是一种通过使用负载均衡器将处理分布到多个节点以通过分布处理来提高性能的机制，可以用作单个系统。 虽然它可以隔离故障节点以防止节点故障影响整个系统，但负载均衡器是一个关键的单点故障风险和不是高可用性选项. 它仅对诸如 Web 服务器负载平衡之类的应用程序有效。 如果负载均衡器本身出现故障，整个系统停止。

什么是 HPC 集群？

您还可以使用集群来提高性能而不是高可用性. 高性能计算集群或 HPC 集群结合了多个（有时是数千个节点）的处理能力，以获得 CPU 密集型环境（例如需要大规模模拟、CAE 分析和并行处理的科技环境）所需的 CPU 性能.

您准备好为您的企业寻找合适的 HA 集群解决方案了吗？

了解有关 SIOS 高可用性集群的更多信息这里.

 

集群简介 – 第 1 部分

by Leave a Comment

集群简介 – 第 1 部分

集群简介 – 第 1 部分

首先什么是聚类？

集群技术是一种允许您连接多个服务器以充当单个功能单元的技术。

聚类类型

你可以簇服务器用于多种用途。 例如，您可以组合多个小型服务器的处理能力以获得高性能。 您还可以使用负载平衡器将处理工作分发到多个节点以提高效率。

高可用性 (HA) 集群是一个组合服务器节点以保护重要应用程序免受停机和数据丢失的过程。

集群简介
在传统的共享存储故障转移集群中，主节点和辅助或远程节点共享相同的存储。

高可用性集群

高可用性 (HA) 集群是一种通过消除单点故障 (SPOF) 来减少停机时间的机制。 在 HA 集群中，重要的应用程序运行在连接到集群中一个或多个辅助或远程节点的主节点上。 集群软件监控应用程序、服务器和网络的健康状况。 如果主节点出现故障，它会在称为故障转移的过程中将应用程序操作转移到辅助节点，在该过程中操作继续。

高可用性

应用程序高可用性衡量给定年份中应用程序可用和运行的时间。 一般来说， HA集群在给定的一年中提供 99.99%（四个 9）的可用性或略多于 52 分钟的停机时间。

需要注意的是，在传统的 HA 集群中，所有集群节点都连接到同一个共享存储——通常是 SAN。 这样，在故障转移后，辅助节点访问与主节点相同的数据，操作可以继续。

集群简介
SANless 集群使用基于主机的块级复制来同步本地存储。

SANless 集群

但是，出于多种原因，许多公司更喜欢使用 SANless 集群。 首先，共享存储代表了一个关键的单点故障。 其次，共享存储在公共云环境中通常不是一种选择。 第三，SAN 有时会妨碍数据库应用程序的性能，例如 SQL Server、Oracle 和 SAP。

这些公司不使用共享存储，而是使用高效的、基于主机的、块级复制来同步所有集群节点上的本地存储。 如果发生故障转移，辅助节点将连接到本地存储，并具有与主存储相同的副本。 这不仅消除了 SAN SPOF 风险，而且还支持将快速磁盘 (SSD) 添加到本地本地存储，以实现经济高效的高性能。 SANless 集群还使公司能够以最少的工作量或对正在进行的业务流程的中断，将本地 HA 环境迁移到云。

转载自SIOS