7月 17, 2022 |
情况说明书:BMS 高可用性情况说明书:BMS 高可用性SIOS技术使高可用性集群和复制软件,可确保关键应用程序、数据库和 BMS 系统自动从基础架构、网络和应用程序故障中恢复 – 保持您的数据受到保护、应用程序在线、满足法规要求以及用户高效工作。 轻松满足可用性 SLA 和 RTO/RPOSIOS 让您可以灵活地在物理服务器、虚拟化服务器和云中为 Windows 或 Linux 环境构建 SAN 和 SANless 集群。 您可以使用 SIOS 软件来实现高可用性或容灾。 轻松地将 Windows Server 故障转移集群迁移到云中而不会造成中断,或者轻松构建具有内置应用程序特定智能的 Linux 集群环境。 在云中,您可以跨可用区或区域配置集群以获得最大的 HA/DR 保护,或者创建混合云或多云配置来轻松满足可用性 SLA 和 RTO/RPO。 高可用性 SIOS 产品
楼宇管理系统情况说明书的 HA/DR
经授权转载西欧 |
||||||
7月 12, 2022 |
SIOS LifeKeeper – Linux 的高可用性SIOS LifeKeeper – Linux 的高可用性运行 SAP、S/4 HANA、SQL Server、MaxDB 和 Oracle 等业务关键型应用程序的企业面临两难境地。 即使是这些复杂工作负载的短暂停机时间也可能产生灾难性后果。 但传统的 HA 集群可能很复杂且成本高昂。 迁移到云端并不是答案云可用性 SLA仅涵盖硬件。 他们无法在不降低云中性能的情况下为有状态应用程序提供 HA 和 DR。 传统本地集群中使用的共享存储在某些云中不是一种选择,而在另一些云中过于复杂且成本高昂而无法实用。 许多 HA 集群解决方案无法对云区域和可用区进行故障转移——限制了它们可以提供的灾难恢复级别。 开源集群不是答案。 它需要复杂的脚本,并且容易出现人为错误和故障。 确保复杂的 ERP 或数据库故障转移所需的手动步骤可以正确离开。 IT 团队不愿执行定期维护和故障转移测试。 SIOS 有解决方案。SIOS LifeKeeper 提供高可用性和灾难恢复这可确保系统、数据库和应用程序在需要时运行。
在云中,SIOS 集群跨区域和可用区发生故障,以获得最大的 DR 保护。 对于想要部署多个集群的客户,SIOS LIfeKeeper 的克隆功能允许您使用一致的预定义设置和集成的最佳实践来创建多个相同的集群。 SIOS LIfeKeeper 包含在一个名为 SIOS Protection Suite 的捆绑包中,其中包括特定于应用程序的恢复工具包和用于 SANless 集群和 DR 的高效复制。为在本地、云或混合云环境中运行的关键 Windows 或 Linux 工作负载获得 99.99% 的可用性和灾难保护。安排演示或注册您的免费试用今天。 经授权转载西欧 |
||||||
7月 7, 2022 |
迪士尼和皮克斯灵魂的高可用性课程迪士尼和皮克斯灵魂的高可用性课程在迪士尼和皮克斯的灵魂里,主角乔·加德纳(杰米·福克斯配音)梦想成为一名专业的爵士钢琴家。然而,尽管他做了很多尝试,但令他母亲失望的是,他发现自己离梦想很远,过着“中年中学乐队教师”的生活。但随后,“由于最后一刻有机会在爵士传奇人物多萝西娅·威廉姆斯的四重奏中演出,他的梦想似乎终于要成为现实。直到“一个重大的失误把他送到了伟大的前世——一个灵魂得到他们的兴趣、个性和怪癖的地方——乔被迫与一个“22”一起工作,一个对生活在地球上没有兴趣的古老灵魂,以“在为时已晚之前以某种方式返回地球( D23.com )。”迪斯尼和皮克斯的灵魂是一部伟大的电影,其中有许多有趣和相关的角色,幽默,描述性的,有时令人不安的相关性对生活、目的和生活的看法。但是,这也是一部有钱的电影领导力课程、生活课程和更高可用性的课程。 来自迪士尼和皮克斯灵魂的关于更高可用性的七个想法。1.注意正在发生的事情在迪斯尼和皮克斯的灵魂里,乔获得了他梦想中的演出。但当乔开始走路并分享这个好消息时,他正忙着玩手机,以至于他走到街上,差点被一大堆砖头压死,然后他危险地走向一个开放但明显标记的沙井。那么更高可用性的教训是什么——注意。注意来自监控和恢复解决方案的警报和错误消息。请注意您的托管服务提供商所做的更改,尤其是来自供应商、合作伙伴和安全团队的重要通知。警报和警告的存在是有原因的,当您看到警告时未能解决它们或采取适当的措施可能会导致您陷入深渊。 2.不要掉进坑里对警告视而不见或无视警告,乔最终落入一个敞开的沙井并变成了灵魂。这立即改变了他的梦想和计划。那么,您的企业可能会陷入什么困境?您的企业发展道路上是否存在潜在漏洞,例如:覆盖漏洞、版本差距、维护计划和现实中的漏洞,甚至是供应商响应能力的黑洞?环顾您的环境,除了明显的单点故障之外,您还会陷入哪些漏洞?是否有警告表明您存在与未受保护的关键应用程序、团队之间的沟通差距,甚至是流程和危机管理中的漏洞相关的漏洞。不要掉入可能损坏甚至结束您的高可用性. 3.不要急于高可用成为灵魂后,乔开始积极尝试回到自己的身体。当他与 22 配对时,她将他带到 Moonwind,后者同意尝试帮助他找到自己的尸体,他们照做了。但乔变得太急于跳回他的身体,尽管月风很谨慎。在他的匆忙中,他和 22 都掉到了地上,但乔最终进入了一只猫的身体,而 22 最终进入了他的身体。就像乔一样,如果我们没有耐心,跳跃发生得太快,我们最终会陷入危险甚至更糟的境地。我们可能不在猫的身体里,但我们也可能远离维持 HA 所需的最佳位置。跳得太快看起来像:
4. 不要过早退出——高可用性绝非易事当年轻的长号手康妮来到她老师的公寓时,她很沮丧,想辞职。她首先告诉乔(乔的身体实际上是 22 岁)她很沮丧,她只想放弃和退出。但片刻之后,她在长号上演奏了最后一首曲子,并意识到现在退出还为时过早。在更高的可用性中,我们都非常像 Connie。 有时,困难让我们觉得自己走到了尽头,想要退出。有时,中断会让我们确信是时候认输了。 不要那么快放弃。HA 绝非易事,绝非易事!但是,放弃努力结束停机时间总是为时过早,所以像康妮一样,也许我们只需要坚持下去。这引导我进入下一课。 5. 你还没有尝试一切电影中的22是一个还没有活过的灵魂。她相信她已经尝试了所有可能的事情来给她一个火花,但是当她落入乔的身体时,她意识到有很多她没有尝试过。在创建更高可用性的解决方案时,很容易让人觉得您已经尝试了所有产品和每种产品,但很可能您还没有。全新的视角,或以全新的眼光看待挑战和问题,可能会帮助您提高系统和企业可用性。 尝试提高可用性的一些方法可能很简单,例如:
其他想法可能需要更多的工作、研究、时间和金钱,但如果你过去没有探索过它们可能是值得的。 通过更多时间和精力提高可用性的方法包括:
6. 提出更多(更好)的问题在扮演手套先生的乔不小心在头发中间剪了一条路后,手套先生和乔不得不去看看乔的理发师德兹。当乔和德兹坐在理发椅上时,他们开始谈论目的、生活、存在主义等等。理发后,22 询问 Dez 为什么他们以前从未有过这样的对话,关于 Dez 的生活。德兹回答说他以前从未问过。有时,我们可以如此专注于解决方案、云或本地方法、语言和架构,以及告诉别人我们在做什么,以至于我们忘记提出可以打开一个全新世界的问题。当乔问问题时,他对德兹和他自己有了更多的了解。也许更好的 HA 的教训是开始询问更多关于我们的解决方案、架构、业务目标和挑战、最终客户目标、我们的团队,甚至是我们在更大范围内的角色和职责的问题。 增加我们可用性的一些简单问题包括:
7. 坚持有回报“倒计时,”特里说。Terry 的任务是跟踪 The Great Beyond 的进入者,他正在仔细计算应该到达或已经到达的灵魂数量。乔绕道前世后,特里下定决心要找到失踪的灵魂并解决问题。 当他开始工作时,他正站在一条长长的文件柜走廊里,这些文件柜一直延伸到眼睛所能看到的高度。但过了一会儿,他找到了乔的档案,发现乔发现了一个漏洞,这就是计数被取消的原因。特里表现出的同样毅力也将在更高的可用性领域得到回报。面对令人生畏的不确定性、大量的日志文件和大量可能的故障场景,坚持不懈地在问题发生之前发现并解决问题,或者在问题发生后进行有效的分析和修复,这将引领我们走向更好我们想要的结果。同样,缺乏勤奋和毅力意味着同样的问题可能会在以后重新出现,即使在使用新软件的新环境中也是如此。 随着电影灵魂的结束,乔回到了伟大的过去,找到并说服 22 接受她的地球通行证并冒险。让人想起她和乔一起摔倒在地时,她又一次冒险。令我的孩子们沮丧的是,这部电影的结尾没有描述 22 对她的生活的看法或随之而来的新机会。她只是从伟大的过去中跳出来,期待接下来会发生什么。也许我们也正处于一个可以冒险的时刻……“伟大的前世”中的一个时刻,以及一个让这一年成为更高可用性的机会。 – Cassius Rhue,客户体验副总裁 |
||||||
6月 27, 2022 |
高可用性集群的新选择,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 锁定。 SCSI-3 预留保证 Azure 共享磁盘只能在持有预留的节点上写入(图 3)。 在集群节点之间失去通信的情况下,备用服务器将上线,从而导致潜在的脑裂情况。 但是,由于 SCSI-3 保留,一次只有一个节点可以访问磁盘。 这实际上防止了实际的脑裂情况。 只有一个系统会保留预订。 它将成为新的活动节点(在这种情况下,另一个将重新启动)或保持活动节点。 没有保留 Azure 共享磁盘预留的节点只会使资源处于“待机状态”状态。 仅仅因为他们无法获得预订。 链接到 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 中。 经授权转载西欧 |
||||||
6月 23, 2022 |
什么是“脑裂”以及如何避免它什么是“脑裂”以及如何避免它正如我们所讨论的,在一个高可用性集群环境中有一个活动节点和一个或多个备用节点,当活动节点发生故障或停止响应时,它们将接管服务。 在考虑节点之间的网络层之前,这听起来像是一个合理的假设。 如果节点之间的网络路径出现故障怎么办? 任何一个节点现在都不能与另一个节点通信,在这种情况下,备用服务器可能会在它认为活动节点发生故障的基础上将自己提升为活动服务器。 这导致两个节点都变得“活跃”,因为每个节点都会认为另一个节点已经死了。 结果,数据完整性和一致性受到损害,因为两个节点上的数据都会发生变化。 这被称为“裂脑” . 为避免出现脑裂情况,应在集群中安装 Quorum 节点(也称为“见证人”)。 添加仲裁节点(到由偶数个节点组成的集群)会创建奇数个节点(3、5、7 等),节点投票决定哪个应该充当集群中的活动节点。 在下面的示例中,包含节点 B 的服务器机架丢失了局域网连接性。 在这种情况下,通过在集群环境中添加第 3 个节点,系统仍然可以确定哪个节点应该是活动节点。 Quorum/Witness 功能包含在西欧保护套件。 安装时,在所有节点(不仅是仲裁节点)上选择 Quorum / Witness,并在所有节点(包括仲裁节点)之间定义通信路径。 仲裁节点不托管任何活动服务。 它的唯一作用是参与节点通信,以确定哪些是活动的,并在通信中断的情况下提供“平局投票”。 西欧也支持IO 防护和存储作为仲裁设备,在这些配置中不需要额外的仲裁节点。 经授权转载西欧
|