SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

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

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

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: 服务器集群简单化

节点之间的数据复制如何工作?

6月 19, 2022 by Jason Aw Leave a Comment

节点之间的数据复制如何工作?

节点之间的数据复制如何工作?

在传统的数据中心场景中,数据通常存储在存储区域网络中( SAN )。 云环境通常不支持共享存储。

西欧DataKeeper 使用复制技术提供“共享”存储,以创建当前活动数据的副本。 它创建一个作为 RAID1 设备工作的 NetRAID 设备(跨设备镜像数据)。

数据更改从镜像源(活动节点上的磁盘设备 – 下图中的节点 A)复制到镜像目标(备用节点上的磁盘设备 – 下图中的节点 B)。

为了保证两个设备之间数据的一致性,只有活动节点对复制的设备(下例中的 /datakeeper 挂载点)具有写访问权限。 当它是镜像目标(即,在备用节点上)时,不允许访问复制设备(/datakeeper 挂载点)。

经授权转载西欧

Filed Under: 服务器集群简单化

客户端如何连接到活动节点

6月 15, 2022 by Jason Aw Leave a Comment

客户端如何连接到活动节点

客户端如何连接到活动节点

如前所述,一旦高可用性集群已配置,两个或多个节点同时运行并且用户连接到“活动”节点. 当活动节点上出现问题时,会发生“故障转移”情况,“备用”节点将成为新的“活动”节点。 当发生故障转移时,必须有一种机制允许客户端检测故障转移条件并重新连接,或者将用户的活动客户端会话无缝传输到活动节点。

虚拟 IP 地址

通常在配置集群并且客户端与活动节点使用虚拟 IP 地址。 发生故障转移时,虚拟 IP 地址会重新分配给新的活动节点,并且客户端会重新连接到相同的虚拟 IP 地址。

例如,假设有两个节点 A 和 B,其 IP 地址为10.20.1.10和10.20.2.10 . 在此示例中,我们将定义一个虚拟 IP 地址 10.20.0.10,应将其视为分配给当前活动节点。

这类似于为一个节点上的一个网络接口卡分配第二个 IP 地址。 如果命令ipa在活动节点上输入,两个 IP 地址都会出现(如本 Linux 示例中的第 10 行和第 12 行):

这ARP协议

当客户端尝试使用 IP 地址查找服务器时,客户端通常使用ARP (地址解析协议)找到苹果电脑(媒体访问控制)目标机器的地址。

一旦客户端广播一条消息以找到目标 IP 地址,活动节点就会用它的苹果电脑地址和客户端解析请求并连接到它。

ARP云环境的替代方案

但是,在云环境中,无法使用以下方法识别活动节点ARP在虚拟环境中抽象了尽可能多的层。 可能需要基于在特定云环境中使用的网络基础设施的替代方法。 通常有几个选项,应从以下列表中进行选择。

  • AWS路由表场景
  • AWS弹性IP场景
  • AWS Route53 场景
  • Azure 内部负载均衡器方案
  • Google Cloud 内部负载均衡器方案
经授权转载西欧

Filed Under: 服务器集群简单化

  • « Previous Page
  • 1
  • 2
  • 3
  • 4
  • …
  • 69
  • Next Page »

最近的帖子

  • 白皮书:多云架构解释——用例、风险和最佳实践
  • 介绍适用于 SIOS LifeKeeper 和 Microsoft Azure 的通用负载平衡器套件
  • 解决方案简介:SAP S4/HANA 的高可用性
  • 情况说明书:BMS 高可用性
  • SIOS LifeKeeper – Linux 的高可用性

最热门的帖子

Maximise replication performance for Linux Clustering with Fusion-io
Failover Clustering with VMware High Availability
create A 2-Node MySQL Cluster Without Shared Storage
create A 2-Node MySQL Cluster Without Shared Storage
SAP for High Availability Solutions For Linux
Bandwidth To Support Real-Time Replication
The Availability Equation – High Availability Solutions.jpg
Choosing Platforms To Replicate Data - Host-Based Or Storage-Based?
Guide To Connect To An iSCSI Target Using Open-iSCSI Initiator Software
Best Practices to Eliminate SPoF In Cluster Architecture
Step-By-Step How To Configure A Linux Failover Cluster In Microsoft Azure IaaS Without Shared Storage azure sanless
Take Action Before SQL Server 20082008 R2 Support Expires
How To Cluster MaxDB On Windows In The Cloud

加入我们的邮件列表

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