SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

  • Home
  • 产品
    • SIOS DataKeeper for Windows
    • SIOS Protection Suite for Linux
  • 新闻与活动
  • 服务器集群简单化
  • 成功案例
  • 联系我们
  • English
  • 中文 (中国)
  • 中文 (台灣)
  • 한국어
  • Bahasa Indonesia
  • ไทย

情况说明书:BMS 高可用性

7月 17, 2022 by Jason Aw Leave a Comment

情况说明书 BMS 高可用性

情况说明书:BMS 高可用性

SIOS技术使高可用性集群和复制软件,可确保关键应用程序、数据库和 BMS 系统自动从基础架构、网络和应用程序故障中恢复 – 保持您的数据受到保护、应用程序在线、满足法规要求以及用户高效工作。

轻松满足可用性 SLA 和 RTO/RPO

SIOS 让您可以灵活地在物理服务器、虚拟化服务器和云中为 Windows 或 Linux 环境构建 SAN 和 SANless 集群。 您可以使用 SIOS 软件来实现高可用性或容灾。 轻松地将 Windows Server 故障转移集群迁移到云中而不会造成中断,或者轻松构建具有内置应用程序特定智能的 Linux 集群环境。 在云中,您可以跨可用区或区域配置集群以获得最大的 HA/DR 保护,或者创建混合云或多云配置来轻松满足可用性 SLA 和 RTO/RPO。

高可用性 SIOS 产品

SIOS 数据保持器

将 SIOS DataKeeper 添加到 Windows Server Failover Clustering 环境中,以创建传统共享存储集群不可能或不切实际的 SANless 集群,例如云和混合云环境。 快速、高效的基于主机的复制可同步所有集群节点上的本地存储,以实现最大的配置灵活性。 或者,将复制添加到现有的基于 SAN 的 Windows 群集以进行 DR。使用 SIOS DataKeeper Cluster Edition 软件在物理、虚拟或云环境中保护您的业务关键型 Windows 应用程序和 BMS 系统及其运行的数据库,包括 Microsoft SQL Server、Oracle。

  • 配置灵活性——保护所有服务器工作负载。 在单个站点内或跨数据中心复制。
  • 节省成本 – 无需昂贵的应用程序升级的高级集群(例如 SQL Server 企业版)
  • 降低复杂性 – 将本地 WSFC 迁移到云而不中断

SIOS 保护套件

适用于 Linux 的 SIOS 保护套件可让您在本地或灵活、可扩展的云环境(例如 Amazon Web Services (AWS) 和 Microsoft Azure)中运行业务关键型 EHR 应用程序,而不会牺牲性能或 HA/DR 保护。 SIOS 集群可跨云区域或可用区进行独特的故障转移,以实现真正的 HA 保护。
SIOS 保护套件包括强大的应用程序恢复套件,用于领先的 BMS 应用程序和数据库,可自动执行手动任务、监控整个应用程序堆栈并确保故障转移保持特定于应用程序的最佳实践。

  • 高级自动化——自动验证的用户输入消除了对昂贵的专业技能的需求以及手动脚本在复杂 BMS 环境中配置和管理集群所固有的风险
  • 深度应用监控——监控整个应用环境
  • 应用程序感知自动故障转移——保持与应用程序最佳实践的合规性,以实现可靠的故障转移而不会发生意外。

楼宇管理系统情况说明书的 HA/DR

BMS 系统受保护

SIOS 产品保护运行构建维护系统的关键应用程序和数据库免于停机和数据丢失。

开利、伊顿、霍尼韦尔、江森自控、施耐德电气、西门子等等。

受保护的环境和平台

Microsoft Azure 云、AWS EC2、谷歌云平台、混合云、VMware、Hyper-V、本地

受保护的操作系统

视窗、SUSE Linux、红帽

受保护的数据库和 ERP

SQL Server、SAP、SAP S/4HANA、甲骨文、SharePoint

学到更多

 

医疗保健案例研究

Chris O'Brien Lifehouse 癌症治疗中心、Allyn 医院、Carroll 医院、领先的医疗保健提供商。

学到更多

情况说明书:BMS 高可用性
与传统的共享存储集群不同,SIOS 在无 SAN 配置中同步本地存储,从而在物理、虚拟、云和混合云环境中启用故障转移集群。
  • 免费试用 SIOS 高可用性和灾难恢复集群软件
  • 了解有关 SIOS DataKeeper 的更多信息
  • 下载情况说明书 PDF

经授权转载西欧

Filed Under: 服务器集群简单化

SIOS LifeKeeper – Linux 的高可用性

7月 12, 2022 by Jason Aw Leave a Comment

SIOS LifeKeeper – Linux 的高可用性

SIOS LifeKeeper – Linux 的高可用性

运行 SAP、S/4 HANA、SQL Server、MaxDB 和 Oracle 等业务关键型应用程序的企业面临两难境地。 即使是这些复杂工作负载的短暂停机时间也可能产生灾难性后果。 但传统的 HA 集群可能很复杂且成本高昂。 迁移到云端并不是答案云可用性 SLA仅涵盖硬件。 他们无法在不降低云中性能的情况下为有状态应用程序提供 HA 和 DR。 传统本地集群中使用的共享存储在某些云中不是一种选择,而在另一些云中过于复杂且成本高昂而无法实用。 许多 HA 集群解决方案无法对云区域和可用区进行故障转移——限制了它们可以提供的灾难恢复级别。 开源集群不是答案。 它需要复杂的脚本,并且容易出现人为错误和故障。 确保复杂的 ERP 或数据库故障转移所需的手动步骤可以正确离开。 IT 团队不愿执行定期维护和故障转移测试。

SIOS 有解决方案。

SIOS LifeKeeper 提供高可用性和灾难恢复这可确保系统、数据库和应用程序在需要时运行。

  • 独特的应用感知恢复套件使在 SAP、S/4 HANA、SQL Server、MaxDB 和 Oracle 等复杂环境中创建和管理高可用性集群变得简单且无错误。
  • 全程监控,与仅监控服务器操作的 HA 解决方案不同,SIOS LifeKeeper 监控应用程序堆栈网络、存储、操作系统和应用程序。
  • 先进的应用感知技术自动化配置和验证输入——实现准确配置的速度比开源集群软件快五倍,并确保故障转移可靠并维护应用程序最佳实践。

在云中,SIOS 集群跨区域和可用区发生故障,以获得最大的 DR 保护。 对于想要部署多个集群的客户,SIOS LIfeKeeper 的克隆功能允许您使用一致的预定义设置和集成的最佳实践来创建多个相同的集群。 SIOS LIfeKeeper 包含在一个名为 SIOS Protection Suite 的捆绑包中,其中包括特定于应用程序的恢复工具包和用于 SANless 集群和 DR 的高效复制。为在本地、云或混合云环境中运行的关键 Windows 或 Linux 工作负载获得 99.99% 的可用性和灾难保护。安排演示或注册您的免费试用今天。

经授权转载西欧

Filed Under: 服务器集群简单化

迪士尼和皮克斯灵魂的高可用性课程

7月 7, 2022 by Jason Aw Leave a Comment

迪士尼和皮克斯灵魂的高可用性课程 (1)

迪士尼和皮克斯灵魂的高可用性课程

在迪士尼和皮克斯的灵魂里,主角乔·加德纳(杰米·福克斯配音)梦想成为一名专业的爵士钢琴家。然而,尽管他做了很多尝试,但令他母亲失望的是,他发现自己离梦想很远,过着“中年中学乐队教师”的生活。但随后,“由于最后一刻有机会在爵士传奇人物多萝西娅·威廉姆斯的四重奏中演出,他的梦想似乎终于要成为现实。直到“一个重大的失误把他送到了伟大的前世——一个灵魂得到他们的兴趣、个性和怪癖的地方——乔被迫与一个“22”一起工作,一个对生活在地球上没有兴趣的古老灵魂,以“在为时已晚之前以某种方式返回地球( D23.com )。”迪斯尼和皮克斯的灵魂是一部伟大的电影,其中有许多有趣和相关的角色,幽默,描述性的,有时令人不安的相关性对生活、目的和生活的看法。但是,这也是一部有钱的电影领导力课程、生活课程和更高可用性的课程。

来自迪士尼和皮克斯灵魂的关于更高可用性的七个想法。

1.注意正在发生的事情

在迪斯尼和皮克斯的灵魂里,乔获得了他梦想中的演出。但当乔开始走路并分享这个好消息时,他正忙着玩手机,以至于他走到街上,差点被一大堆砖头压死,然后他危险地走向一个开放但明显标记的沙井。那么更高可用性的教训是什么——注意。注意来自监控和恢复解决方案的警报和错误消息。请注意您的托管服务提供商所做的更改,尤其是来自供应商、合作伙伴和安全团队的重要通知。警报和警告的存在是有原因的,当您看到警告时未能解决它们或采取适当的措施可能会导致您陷入深渊。

2.不要掉进坑里

对警告视而不见或无视警告,乔最终落入一个敞开的沙井并变成了灵魂。这立即改变了他的梦想和计划。那么,您的企业可能会陷入什么困境?您的企业发展道路上是否存在潜在漏洞,例如:覆盖漏洞、版本差距、维护计划和现实中的漏洞,甚至是供应商响应能力的黑洞?环顾您的环境,除了明显的单点故障之外,您还会陷入哪些漏洞?是否有警告表明您存在与未受保护的关键应用程序、团队之间的沟通差距,甚至是流程和危机管理中的漏洞相关的漏洞。不要掉入可能损坏甚至结束您的高可用性.

3.不要急于高可用

成为灵魂后,乔开始积极尝试回到自己的身体。当他与 22 配对时,她将他带到 Moonwind,后者同意尝试帮助他找到自己的尸体,他们照做了。但乔变得太急于跳回他的身体,尽管月风很谨慎。在他的匆忙中,他和 22 都掉到了地上,但乔最终进入了一只猫的身体,而 22 最终进入了他的身体。就像乔一样,如果我们没有耐心,跳跃发生得太快,我们最终会陷入危险甚至更糟的境地。我们可能不在猫的身体里,但我们也可能远离维持 HA 所需的最佳位置。跳得太快看起来像:

  1. 在没有架构或整体解决方案的情况下部署软件
  2. 无需在 QA 中测试即可在生产中部署
  3. 在不了解云或云对 HA 意味着什么的情况下部署到云中
  4. 根据时间线部署到生产环境中并且未完成验收测试
  5. 在没有专门构建的商业级应用程序监控和编排解决方案的情况下进行部署

4. 不要过早退出——高可用性绝非易事

当年轻的长号手康妮来到她老师的公寓时,她很沮丧,想辞职。她首先告诉乔(乔的身体实际上是 22 岁)她很沮丧,她只想放弃和退出。但片刻之后,她在长号上演奏了最后一首曲子,并意识到现在退出还为时过早。在更高的可用性中,我们都非常像 Connie。 有时,困难让我们觉得自己走到了尽头,想要退出。有时,中断会让我们确信是时候认输了。 不要那么快放弃。HA 绝非易事,绝非易事!但是,放弃努力结束停机时间总是为时过早,所以像康妮一样,也许我们只需要坚持下去。这引导我进入下一课。

5. 你还没有尝试一切

电影中的22是一个还没有活过的灵魂。她相信她已经尝试了所有可能的事情来给她一个火花,但是当她落入乔的身体时,她意识到有很多她没有尝试过。在创建更高可用性的解决方案时,很容易让人觉得您已经尝试了所有产品和每种产品,但很可能您还没有。全新的视角,或以全新的眼光看待挑战和问题,可能会帮助您提高系统和企业可用性。

尝试提高可用性的一些方法可能很简单,例如:

  1. 为关键监控指标设置附加警报
  2. 添加分析。
  3. 执行定期维护(补丁、更新、安全修复)
  4. 记录您的流程
  5. 记录您的操作手册
  6. 改善您的沟通渠道
  7. 进行定期维护

其他想法可能需要更多的工作、研究、时间和金钱,但如果你过去没有探索过它们可能是值得的。

通过更多时间和精力提高可用性的方法包括:

  1. 删除黑客和解决方法。
  2. 创建可靠的可重复解决方案架构
  3. 商业化和专门建造
  4. 聘请顾问
  5. 审核并记录您的架构
  6. 升级你的虚拟机; CPU、内存和 IOP
  7. 在区域或区域级别添加额外的冗余

6. 提出更多(更好)的问题

在扮演手套先生的乔不小心在头发中间剪了一条路后,手套先生和乔不得不去看看乔的理发师德兹。当乔和德兹坐在理发椅上时,他们开始谈论目的、生活、存在主义等等。理发后,22 询问 Dez 为什么他们以前从未有过这样的对话,关于 Dez 的生活。德兹回答说他以前从未问过。有时,我们可以如此专注于解决方案、云或本地方法、语言和架构,以及告诉别人我们在做什么,以至于我们忘记提出可以打开一个全新世界的问题。当乔问问题时,他对德兹和他自己有了更多的了解。也许更好的 HA 的教训是开始询问更多关于我们的解决方案、架构、业务目标和挑战、最终客户目标、我们的团队,甚至是我们在更大范围内的角色和职责的问题。

增加我们可用性的一些简单问题包括:

  1. 如果明天发生灾难,原因是什么系统、流程、产品或解决方案?
  2. 要保护的最重要的事情是什么?应用程序、数据、元数据,所有这些?
  3. 我们的应用程序和数据库可以容忍什么 RPO?
  4. 我们的客户不能容忍什么?
  5. 我错过了什么?
  6. 我们在哪里记录了这个架构?
  7. 我不明白什么?

7. 坚持有回报

“倒计时,”特里说。Terry 的任务是跟踪 The Great Beyond 的进入者,他正在仔细计算应该到达或已经到达的灵魂数量。乔绕道前世后,特里下定决心要找到失踪的灵魂并解决问题。 当他开始工作时,他正站在一条长长的文件柜走廊里,这些文件柜一直延伸到眼睛所能看到的高度。但过了一会儿,他找到了乔的档案,发现乔发现了一个漏洞,这就是计数被取消的原因。特里表现出的同样毅力也将在更高的可用性领域得到回报。面对令人生畏的不确定性、大量的日志文件和大量可能的故障场景,坚持不懈地在问题发生之前发现并解决问题,或者在问题发生后进行有效的分析和修复,这将引领我们走向更好我们想要的结果。同样,缺乏勤奋和毅力意味着同样的问题可能会在以后重新出现,即使在使用新软件的新环境中也是如此。

随着电影灵魂的结束,乔回到了伟大的过去,找到并说服 22 接受她的地球通行证并冒险。让人想起她和乔一起摔倒在地时,她又一次冒险。令我的孩子们沮丧的是,这部电影的结尾没有描述 22 对她的生活的看法或随之而来的新机会。她只是从伟大的过去中跳出来,期待接下来会发生什么。也许我们也正处于一个可以冒险的时刻……“伟大的前世”中的一个时刻,以及一个让这一年成为更高可用性的机会。

– Cassius Rhue,客户体验副总裁

经授权转载西欧

Filed Under: 服务器集群简单化

高可用性集群的新选择,SIOS 巩固了对 Microsoft Azure 共享磁盘的支持

6月 27, 2022 by Jason Aw Leave a Comment

高可用性集群的新选择,SIOS 巩固了对 Microsoft Azure 共享磁盘的支持

高可用性集群的新选择,SIOS 巩固了对 Microsoft Azure 共享磁盘的支持

微软推出Azure 共享磁盘在 2022 年第一季度。 共享磁盘允许您将托管磁盘附加到多个主机。 实际上,这意味着 Azure 现在拥有相当于 SAN 存储的功能,能够高度可用集群使用云中的共享磁盘!

将 Azure 共享磁盘与 SIOS Lifekeeper 群集层次结构结合使用的一个主要优点是,您将不再需要拥有存储仲裁或见证节点。 这样你就可以避免所谓的脑裂– 当节点之间的通信丢失并且几个节点可能同时更改数据时会发生这种情况。 更少的节点意味着更少的成本和复杂性。

LifeKeeper SCSI-3 Persistent Reservations (SCSI3) 恢复套件

SIOS 推出了一个应用程序恢复工具包 (ARK)用于我们的 LifeKeeper for Linux 产品。 这称为 LifeKeeper SCSI-3 Persistent Reservations (SCSI3) 恢复套件。 这允许将 Azure 共享磁盘与 SCSI-3 预留结合使用。 ARK 保证共享磁盘只能从当前在该磁盘上保留 SCSI-3 保留的节点写入。

安装 SIOS Lifekeeper 时,安装程序将检测到它正在 Microsoft Azure EC2 中运行。 它将自动安装 LifeKeeper SCSI-3 Persistent Reservations (SCSI3) 恢复工具包以支持 Azure 共享磁盘。

Lifekeeper 中的资源创建简单明了(图 1)。 Azure 共享磁盘只需在本地安装后作为文件系统类型资源添加到 Lifekeeper。 Lifekeeper 将为其分配一个 ID(图 2)并自动管理 SCSI-3 锁定。

图1。 在 LifeKeeper 中创建 SAP 实例(sapinst)
图 2:创建 扩展至两个节点。

SCSI-3 预留保证 Azure 共享磁盘只能在持有预留的节点上写入(图 3)。 在集群节点之间失去通信的情况下,备用服务器将上线,从而导致潜在的脑裂情况。 但是,由于 SCSI-3 保留,一次只有一个节点可以访问磁盘。 这实际上防止了实际的脑裂情况。 只有一个系统会保留预订。 它将成为新的活动节点(在这种情况下,另一个将重新启动)或保持活动节点。 没有保留 Azure 共享磁盘预留的节点只会使资源处于“待机状态”状态。 仅仅因为他们无法获得预订。

图 3 – 尝试挂载已保留的磁盘时 Lifekeeper 日志的输出。

链接到 Microsoft 对 Azure 共享磁盘的定义https://docs.microsoft.com/en-us/azure/virtual-machines/disks-shared

你可以期待什么

目前,SIOS 支持本地冗余存储 (LRS)。我们正在与 Microsoft 合作测试和支持区域冗余存储 (ZRS)。 理想情况下,我们想知道 ZRS 何时发生故障,以便我们可以将资源层次结构故障转移到活动存储的最本地节点。 SIOS 预计 Azure 共享磁盘支持将出现在其下一版本的 Lifekeeper 9.6.2 for Linux 中。

经授权转载西欧

Filed Under: 服务器集群简单化

什么是“脑裂”以及如何避免它

6月 23, 2022 by Jason Aw Leave a Comment

什么是“脑裂”以及如何避免它

什么是“脑裂”以及如何避免它

正如我们所讨论的,在一个高可用性集群环境中有一个活动节点和一个或多个备用节点,当活动节点发生故障或停止响应时,它们将接管服务。

在考虑节点之间的网络层之前,这听起来像是一个合理的假设。 如果节点之间的网络路径出现故障怎么办?

任何一个节点现在都不能与另一个节点通信,在这种情况下,备用服务器可能会在它认为活动节点发生故障的基础上将自己提升为活动服务器。 这导致两个节点都变得“活跃”,因为每个节点都会认为另一个节点已经死了。 结果,数据完整性和一致性受到损害,因为两个节点上的数据都会发生变化。 这被称为“裂脑” .

为避免出现脑裂情况,应在集群中安装 Quorum 节点(也称为“见证人”)。 添加仲裁节点(到由偶数个节点组成的集群)会创建奇数个节点(3、5、7 等),节点投票决定哪个应该充当集群中的活动节点。

在下面的示例中,包含节点 B 的服务器机架丢失了局域网连接性。 在这种情况下,通过在集群环境中添加第 3 个节点,系统仍然可以确定哪个节点应该是活动节点。

Quorum/Witness 功能包含在西欧保护套件。 安装时,在所有节点(不仅是仲裁节点)上选择 Quorum / Witness,并在所有节点(包括仲裁节点)之间定义通信路径。

仲裁节点不托管任何活动服务。 它的唯一作用是参与节点通信,以确定哪些是活动的,并在通信中断的情况下提供“平局投票”。

西欧也支持IO 防护和存储作为仲裁设备,在这些配置中不需要额外的仲裁节点。

经授权转载西欧

Filed Under: 服务器集群简单化

  • « Previous Page
  • 1
  • …
  • 31
  • 32
  • 33
  • 34
  • 35
  • …
  • 100
  • Next Page »

最近的帖子

  • 如何评估我的网卡是否需要更换
  • 与高可用性相关的应用程序智能
  • 在 Nutanix 环境中选择高可用性解决方案的 10 个注意事项
  • 我的服务器是一次性的吗?高可用性软件如何融入云最佳实践
  • 灾难频发世界的数据恢复策略

最热门的帖子

加入我们的邮件列表

Copyright © 2025 · Enterprise Pro Theme on Genesis Framework · WordPress · Log in