部署仲裁/见证的最佳方式

在最近的一次会议上，一位客户提出了一个关于高可用性 (HA) 和仲裁/见证可行性需求的问题。 他们的问题是，“部署法定人数/见证人的最佳方式是什么？”他们的问题的答案很简单，没有单一的最佳方式来部署仲裁。为了理解为什么，让我们从定义三个关键的东西开始：什么是见证资源、仲裁资源和裂脑场景。

什么是裂脑？

在正常的集群环境中，受保护的应用程序在集群的主节点上运行。如果该主节点的应用程序发生故障，集群软件会将应用程序操作移动到辅助节点或远程节点，该节点承担主节点的角色。 在任何给定时间，只有一个主节点。

裂脑是指集群成员之间无法相互通信，但处于运行和可操作状态，随后同时拥有公共资源的情况。 实际上，您有两个公共汽车司机在争夺方向盘。裂脑，由于其破坏性，可能导致数据丢失或数据损坏，最好通过使用围栏、仲裁、见证或集群仲裁的仲裁/见证功能来避免。

在大多数集群管理器中，在以下情况下会维持仲裁：

1. 所有服务器都能够看到所有集群对等方和见证服务器的相同状态
2. 所有服务器都能够看到所有集群对等方的相同状态，但不是见证服务器
3. 所有服务器都可以看到见证资源，尽管彼此看不到，并避免出现脑裂情况

在大多数集群管理器中，仲裁会在以下情况下丢失：

1. 服务器无法看到所有集群对等点和见证服务器
2. 服务器无法看到大多数集群对等方，即使它们可以看到见证服务器
3. 服务器无法访问或维持对仲裁资源的访问以成功仲裁仲裁成员资格和资源访问

什么是见证资源（或服务器）？

见证资源是服务器、网络端点或设备，用于在集群具有偶数个成员时实现和维护仲裁。具有奇数成员的集群，使用集群多数，不需要使用见证资源作为集群服务器的所有成员来仲裁多数成员资格。

什么是仲裁和仲裁资源？

仲裁资源是一种资源（设备、系统、块存储、文件存储、文件共享等），用作仲裁集群状态和成员资格的手段。在某些集群管理器中，仲裁是集群内的一种资源，它帮助或需要任何集群状态和集群成员资格决策。在其他集群管理器中，quorum 起到了决胜局的作用，以避免脑裂。

部署仲裁的不止一种方法

鉴于仲裁的关键性质，HA 架构必须正确部署仲裁/见证资源，并且幸运（或不幸）没有单一的，部署仲裁的最佳方式。有几个因素可能会影响您的见证和仲裁资源的行为方式。这些因素包括：

1. 您的部署是本地、云还是混合

在存在额外存储设备（例如光纤通道存储、电源控制设备或连接或传统 stonith 设备）的本地数据中心中部署将为客户提供可能不驻留在云中的仲裁和见证功能的额外选项。同样，云和混合环境在可以部署的内容以及正在部署哪些用例仲裁以防止这些方面存在差异。 此外，延迟要求和差异可能会限制可用于仲裁/见证配置的设备和资源类型。  

2. 你的恢复目标

在设计和构建仲裁和见证资源时，恢复目标也很重要。在示例两节点集群（节点 A 和节点 B）中，当节点 A 失去与节点 B 的连接时，恢复的最高优先级是什么。 如果见证/仲裁资源与节点 A 在同一网络中，这可能导致节点 A 保持在线，但与客户端断开，而节点 B 无法评估仲裁和接管。同样，如果仲裁设备仅存在于具有节点 B 的区域、数据中心或网络中，则丢失可能导致资源故障转移到已失效的网络或中心或远离功能和操作的主节点。

3. 基础架构中可用数据中心（或区域）的冗余

数据中心或区域的冗余也是具有仲裁/见证的 HA 拓扑中的一个重要因素。 如果您的数据中心只有两个级别的冗余，您必须了解将仲裁/见证节点放置在与主集群节点或备用集群节点相同的数据中心之间的权衡。 如果数据中心有两个以上的冗余层，例如第三个可用区或访问第二个区域，此选项将为集群提供更高级别的冗余。

4. 容灾要求

了解您真正的灾难恢复需求也是您设计中的一个主要因素。 如果您的集群管理器软件需要访问仲裁/见证以便从整个数据中心中断（或区域故障）中恢复，那么您需要了解这对您的设计的影响。许多高可用性软件包都有适用于这种情况的工具或方法，但如果您的软件没有，您的仲裁/见证人的设计和放置可能需要适应这一现实。

5. 集群内的成员数量及其位置

当集群包含奇数个节点时，通常不需要额外的仲裁/见证服务器。但是，如果在一个集群中只使用两个节点或部署一个并不总是可用的 DR 节点可能会改变您的架构。作为客户体验副总裁，我曾与部署了三个节点架构的客户合作，但为了节省成本，他们会自动定期关闭第三台服务器。

6.操作系统和集群管理器

关于仲裁/见证的最后一个因素是集群管理器和操作系统。在仲裁/见证的部署或仲裁状态的仲裁方面，并非所有的 HA 软件和集群管理器都是平等的。一些集群软件需要共享磁盘进行仲裁，其他更灵活地允许共享（NFS、SMB、EFS、Azure 文件和 S3）。了解您的集群管理器需要什么，以及它在仲裁方面支持的模式（简单多数、见证、文件共享等）不仅会影响您部署的内容，还会影响您的部署方式。

部署仲裁/见证服务器的唯一最佳方法是了解供应商对仲裁/见证的定义及其可用选项，了解您的要求，考虑数据中心（或云环境）提供的限制或机会并构建解决方案为您的关键系统提供最高级别的保护，防止出现裂脑、错误故障转移和停机。

-Cassius Rhue，客户体验副总裁

使用 SIOS DataKeeper for Windows 测量和提高 GCP 上的写入吞吐量性能

背景

这篇文章用于记录我在 GCP 中关于将性能写入复制到 GCP 的磁盘的发现。 但首先，一些背景信息。 一位客户表示担心，在同一区域的 Google 区域之间使用同步镜像进行测试时，DataKeeper 会为其写入性能增加大量开销。 他们执行的原始测试是使用 C 驱动器上的位图文件，这是一个持久的 SSD。 在这种配置中，他们只推动了大约 70 MBps。 他们尝试将位图重新定位到一个极端的 GCP 磁盘，但性能并没有提高。

将位图移动到本地 SSD

我建议他们将位图移动到本地 SSD，但他们犹豫不决，因为他们认为他们用于位图的极端磁盘的延迟和吞吐量与本地 SSD 一样好或更好，因此他们怀疑它是否会不同之处。 此外，添加本地 SSD 并非易事，因为它只能在最初配置 VM 时添加。

选择实例类型

当我着手完成我的任务时，我发现的第一件事是并非所有实例类型都支持本地 SSD。 例如，E2-Standard-8 不支持本地 SSD。 在我的第一个测试中，我选择了一种 C2-Standard-8 实例类型，它被认为是“计算优化的”。 我连接了一个 500 GB 的持久 SSD 并开始运行一些写入性能测试，很快发现我只能让磁盘以大约 140MBps 的速度写入，而不是最大速度 240MBps。 客户确认他们看到了同样的东西。 这很令人困惑，但我们决定继续尝试不同的实例类型。

我们选择的第二种实例类型是 N2-Standard-8。 使用这种实例类型，我们能够在不复制磁盘时将磁盘推到其最大吞吐速度 240 MBps。 我将位图移动到我已配置的本地 SSD 并在同步镜像（DataKeeper v8.8.2）上重复相同的测试，并得到如下所示的结果。

结果

Diskspd测试参数diskspd.exe -c96G -d10 -r -w100 -t8 -o3 -b64K -Sh -LD:data.dat diskspd.exe -c96G -d10 -r -w100 -t8 -o3 -b8K -Sh -LD:data .dat diskspd.exe -c96G -d10 -r -w100 -t8 -o3 -b4K -Sh -LD:data.dat

MBps

数据

写入大小	MB/s	MBps 开销百分比
64k-镜子	240.01	0.00%
64k-无镜	240.02
8k-镜子	58.87	39.18%
8k-无镜	96.8
4k-镜子	29.34	21.84%
4k-无镜	37.54

 

写入大小	平均纬度	平均开销
64k-镜子	6.247	-0.02%
64k-无镜	6.248
8k-镜子	3.183	39.21%
8k-无镜	1.935
4k-镜子	3.194	21.88%
4k-无镜	2.495

结论

64k 和 4k 写入大小都会产生开销，这对于同步复制来说是“可接受的”。 尽管 3.183 毫秒的平均延迟仍然相当低，但 8k 写入大小似乎会产生更大的开销。

-Dave Bermingham，客户成功总监 经许可转载西欧

COVID-19 如何影响高可用性

与朋友、家人和需要治疗、住院或重症监护的人相比，我的 COVID 症状较轻。 这可能是健康状况良好的结果，包括两剂疫苗、加强注射以及早期发现和治疗。而且，我向在这场大流行的任何方面失去亲人的每个家庭，以及所有失去机会和特殊时刻的人表示衷心的感谢。随着我和我们 SIOS 团队的几位成员从 COVId-19 中恢复过来，我们想分享您的 IT 团队在应对 COVID 和企业停机时可能正在处理的五件事，以及您可以做的五件事来帮助他们。

IT 团队面临的五个 COVID 问题

1. 个人和家庭的担忧和恐惧

   最初，我的症状几乎不明显，喉咙有轻微刺激，还有一点鼻窦引流，我自我诊断为季节性过敏。但是当问题恶化时，伴随着剧烈的咳嗽，我开始担心。当然，我们都愿意认为我们的工作绩效和职责保持不变，但现实可能更难评估。 尽管最初的测试结果为阴性，但我继续出现症状，最终影响了我的工作能力，增加了我的个人健康问题，并引发了一些恐惧。 如果您的团队直接受到 COVID-19 的影响，请了解除了可能影响其日程安排、任务和活动的真正健康挑战之外，他们可能还要处理个人担忧、恐惧和担忧。每个团队成员可能还处理更大的问题，即对家庭的担忧。在我生病期间，谢天谢地，我的孩子们都很好。然而，我的妻子就没有那么幸运了。她在我出现症状三天后病了，病的时间更长，症状和挫折也更严重。虽然我们有一个大家庭单位、一名有执照的青少年司机和一辆不是由 COVID 阳性父母驾驶的额外汽车的好处，但您的团队可能没有这些奢侈品。即使他们这样做了，也不会让他们免于担忧，也不会减少他们为家庭消毒、让孩子上学和健康、处理法规、授权和密切接触所需的时间和精力问题。更不用说对收入和支出的担忧了。面临个人和家庭问题的团队成员可能会难以集中注意力、脾气暴躁，以及难以满足最后期限和时间表。

2. FODO——害怕让别人失望

   即使没有 COVID-19 疾病，世界各地的企业也感受到了劳动力减少的影响。被恰当地描述为“大转变”、“大辞职”或“大洗牌”的事件已经极大地重塑了劳动力，包括那些与 HA 打交道的员工，使执行关键任务的人更少的团队。 团队成员的这种不足可能会导致那些患有 COVID 的人与害怕他人失望 (FODO) 作斗争。生病的团队成员可能会出于对团队的忠诚或害怕让老板、同事或利益相关者失望而继续努力工作。这种 FODO 经常导致已经在压力环境中工作的工人（参见上面的 #1 和 2）试图保持 COVID 之前的活动水平。 虽然英勇，但它也对个人和职业恢复适得其反。

3. 疲劳

   当我继续处理 COVID-19 症状时，我继续面临的最大问题之一是疲劳。最初，由 FODO 引起的疲劳使我无法得到充分的休息和恢复。因为我已经看到我们的团队是多么的人手不足，并且目睹了其他人试图冒着疾病来跟上需求，所以我也尝试做同样的事情。但是，没有任何警告，我发现自己精疲力竭，不是在一天结束时，而是在一天中的一段时间内。对我来说，从早上 5 点前开始，继续专注于工作、任务、策略和人事事务 8 到 12 小时是正常的。（我们可以稍后讨论这是否健康）。 现在有些人想在早上 8 点之前攀登珠穆朗玛峰。我收到的最好建议来自一位朋友和同事，他说：“不要抗拒。 当你的身体说休息时，休息吧！”

4. 脑雾

   大约在我开始感到不适的同时，一位同事分享说，在出现 COVID 症状后，他们感觉自己就像是一头雾水。 像我一样，他们完全接种了疫苗，症状和持续时间都很轻微。 事实上，他们实际上从未测试过阳性。尽管如此，他们还是在我们都称之为“脑雾”的情况下度过了几天。我们将这种体验描述为回忆细节的缓慢，一种知道答案的感觉，但缺乏某种不同于身体疲劳和精神疲劳的精神敏锐度。在某些情况下，它表现为对问题的响应较慢、击键暂停或房间灯亮起延迟。

5. 恢复失败

   感染新冠病毒五天后，我从早睡中醒来，感觉比以往任何时候都好。 我跳进了我的日常生活，到中午发现我还没有完全康复。相反，我正在耗尽前一天晚上睡得好所获得的一小部分能量。试图克服这种疲惫给我的康复带来了新的挫折。第二天我感觉比以前更糟了。恢复失败的痛苦和对如何避免更多挫折的担忧加重了我的疲劳和迷茫。

因此，当 IT 团队遇到 COVID-19 问题时，IT 团队领导、利益相关者和经理应该怎么做。

帮助 IT 团队对抗 COVID 的五种方法

1. 练习同理心

   请注意，COVID 对每个人和家庭的影响不同。您的一些同事和管理员会遇到小问题，没有症状，也没有并发症。而其他人，单亲家庭，多代家庭，或有孩子或弱势群体的家庭将有更多的问题和担忧。知道病毒也会对每个人产生独特的影响。即使在我自己的家庭中，我的症状和我妻子的症状也不同。当我感到更疲劳时，她却经历了更多的头痛。 对可能正在处理脑雾、兼顾工作日程、照顾生病的亲人或处理与 COVID 相关的无数问题的同事要有耐心。

2. 评估需求

   与流感或普通感冒不同，COVID 的恢复是不规则的。 一位团队成员可能有一天会出现在工作中，感觉好多了，但第二天就生病待在家里。 您的企业仍有高可用性和灾难恢复的技术需求和要求。但是，对于因疾病而进出的人员，请务必了解团队中当前所需的角色和职责。当一个人生病时，一定要评估他们的角色、他们对团队的影响、他们对基础设施的责任程度等。您可能还需要评估团队或组织内的哪些人可以在发生严重停机事件时提供保障。

3. 优先处理问题

   通过确定关键问题的优先级来帮助您的团队。在正常情况下，您的 IT 团队正在平衡从琐碎（USB 键盘）到关键（与停机时间、安全威胁或存储问题相关的问题）的数十个请求。虽然这对您和团队来说可能很明显，但其他利益相关者可能需要了解 IT 团队的状态以及如何处理运营，直到恢复到更“正常”的人员配备。

4. 确保您的流程是最新的

   随着团队成员的进出，保持 IT 维护和管理流程保持最新状态至关重要。这些流程将帮助团队中的每个成员在执行不属于他们正常职责的任务时有效且高效地为您的企业服务。 它还将减少每个团队成员在同事康复期间研究他们所覆盖的系统状态所需的时间。

5. 给人们时间

   我已经比我应该更多地匆忙回到日常生活中，只是在第二天遭受挫折和更大的疲劳的后果。作为团队的领导者或个人贡献者，一定要给自己和团队时间“恢复正常”。

随着大流行的继续，我们都希望未来与常态非常相似，包括减少疾病、恐惧和担忧。同时，更多地了解您的团队成员在 COVID 疾病和康复期间所面临的问题将极大地帮助您积极准备和度过当前的风暴。此外，从这次大流行中吸取的关键经验教训可以应用于许多其他组织、员工生活和全球问题。

经授权转载西欧

如何充分利用您的技术支持电话

技术支持专家分享他们关于如何快速解决问题的技巧

SIOS 为我们客户最关键的应用程序、数据库和 ERP 提供高可用性保护。 当我们的客户致电技术支持时，没有时间可以浪费。 我们的 HA/DR 专业知识和卓越支持赢得了声誉（和多个奖项）。

我们已要求我们的技术支持团队分享以下五个问题，这些问题可以帮助您快速解决问题。

快速、准确的诊断

全面而准确的技术支持类似于诊断疾病。 想象一下让你的医生治疗头痛。 人体是多个系统的复杂相互作用。 你的问题的根源可能并不明显，甚至在你的脑海中。 为了诊断问题并推荐治疗，您的医生通常会从旨在确定导致您症状的情况的问题开始。

故障转移集群还涉及 IT 基础架构每一层的多个系统——网络、存储、操作系统、应用程序、数据库和服务器。 就像你真正的头疼一样，你的 HA 问题通常是由与你的 HA 集群软件无关的东西引起的。 像您的医生一样，优秀的支持专业人员会提出各种问题来描述您的问题。 您可以提供的有关支持问题的信息越多，诊断和解决问题的速度和效率就越快。

快速解决问题

作为 IT 最佳实践，将记录关键信息和系统更改视为一项持续的业务活动。 通过将以下关键问题的答案放在您的指尖，此过程将加快诊断和快速解决问题。 （它还可以帮助您从一开始就防止问题发生）。

1. 你能描述你收到的错误吗？ 您所看到的引起关注的确切症状是什么？
2. 它是什么时候发生的（时间，你所在的时区？）一种典型的诊断方法是检查有问题的机器的日志文件。 日志文件可以是数百行消息字符串或命令输出。 通过跟踪您注意到问题症状的准确时间，我们可以显着缩小日志文件检查范围。
3. 你有或者你能上传日志吗？
   提供错误的解释和描述以及错误发生的时间范围对诊断有很大帮助，前提是可以将日志上传到支持票证。在某些 IT 环境中，上传日志需要使用公司批准的文件共享，而黑暗站点不需要系统日志的电子分发。如果无法从外部提供日志，请确保捕获并存档完整日志以供参考，并在案件进展时与支持代理一起审查。 应用程序和系统，尤其是那些受到胁迫的应用程序和系统，可能会产生详尽而广泛的日志，这些日志可能会覆盖关键信息。
4. 当时哪个系统是主集群节点？
   鉴于集群的相互关联性，重要的是通知您的技术支持代表您所调用的集群节点在问题发生时是作为主节点还是辅助节点运行。
5. 您尝试采取什么措施来解决此问题？
   伟大的医生知道他们的患者在就诊前可能已经尝试过家庭疗法或非处方药。 了解这些信息有助于诊断和治疗。这同样适用于出色的支持技术人员。不仅分享您在问题发生时尝试做的事情，还分享您尝试解决错误的方式，可以帮助他们制定更好的治疗和恢复计划，并确保他们的恢复建议保护您的关键数据和应用程序。

20 多年来，SIOS 客户体验团队一直在帮助企业客户实施适用于各种用例的 HA/DR 解决方案。 我们重视客户，并鼓励他们在对 HA/DR 有任何疑问时与我们联系。

 

两个真相和一个谎言：了解可用性的真实情况

几年前的一次公司活动中，我们玩了两个真相和一个谎言。 游戏涉及提出两个真实的陈述和一个不真实的陈述，看看你是否能愚弄大多数人。 获胜者提出的想法似乎可信或不可信，这取决于你自己的个人经历。 以下是所说的：

1. 在成长过程中，我的家乡没有红绿灯。
2. 我的祖父母在二年级时相识，并在他们十几岁时结婚。
3. 毕业后，我就读于佐治亚州一所著名的外州大学，然后转回家乡就读于一所州内大学。

我在一个没有红绿灯的小社区长大，所以这似乎是可能的，但我持怀疑态度。 我听说过一些人的故事，他们在很小的时候就认识了，十几岁就结婚了，所以这是可能的，但也是我可能想要指出的。 第三个似乎也是正确的，但我想知道谁会从一所著名的州外大学转回没有红绿灯的家乡去就读州内大学。 整个团队似乎有很长一段时间都在推理和思考这三个陈述中的哪一个是谎言。而且，似乎没有人能发现它。 我们中的几个人推理，如果家乡没有红绿灯，那它真的也有大学吗？一些人认为，考虑到他的年龄、在公司工作的年限和多个学位，他不太可能就读于著名的州外大学。经过最后的审议，判决出来了，两个真理是第一和第二。谎言排在第三位。

随着所有的信息围绕高可用性，您可能会觉得自己在玩“两个真理和一个谎言”的游戏。根据您的观察，您可能会发现关于可用性的陈述似乎可信，但当您深入挖掘时，并不完全正确。例如，以下被广泛接受的陈述实际上并不正确：

1. 存储可用性是高可用性所需的全部

   应用程序需要访问数据才能有效和高效。如果您要成功运行您的企业，您的数据库将需要访问存储。您的其他企业应用程序同样必须能够访问配置文件、数据存储以及事务和错误日志目录才能使用。但是，虽然可靠、易于访问和高性能的存储对于所有企业系统、网站、数据库、应用程序和互连都是必不可少的，但单独可用的存储并不是高可用性所需的全部。除了存储之外，还有更多的组件构成了一个健全、可靠、有弹性的高可用性架构。

2. 平台可用性是高可用性所需的全部

   随着云计算的不断发展壮大，很多追求高可用性的企业都被平台可用性的概念所迷惑。平台可用性，有时称为系统可用性或基础设施可用性，与平台（硬件、网络、操作系统和相关组件）可访问并交付其预期 IT 服务的时间有关。应用程序和数据库绝对需要计算、内存、存储和网络资源才能正常有效地运行。数据中心的每个服务或功能都需要一个可靠的地方来执行其逻辑，没有底层平台，这些操作是不可能的。因此，许多人认为平台可用性是高可用性所需要的全部。 作为客户体验副总裁，我帮助客户和合作伙伴了解可用平台与可用应用程序、数据库和客户端连接之间的差距。在这些对话中，我们讨论了显示没有停机或服务问题的平台的真实示例，同时由于非平台问题，在该数据中心或云基础设施中运行的企业应用程序不可用、不稳定或无法被客户访问。

那么真正的真相是什么？

当我们的同事分享他的三个陈述时，我们都错了。他的家乡是一个小社区，它的边界被带有红绿灯的大城镇缓冲，但他自己的城镇没有自己的城镇。 事实证明，他早早毕业，去了乔治亚州那所著名的州外理工学院，然后想家了，转学到家乡的一所州内大学。所以谎言是关于他的祖父母的。虽然他们可能在很小的时候就见过面，也可能没有见过面，但他们肯定在二年级时就没有见过面。

关于高可用性的事实是，仅靠存储可用性和平台或基础设施可用性是不够的。为了创建最强大、可用、弹性和可靠的高可用性基础架构，您还必须包含一个商业级解决方案，以提供应用程序感知监控、警报和恢复。您还希望该解决方案了解您的存储的高可用性功能，对基础架构的细微差别和差距有深刻的认识，并能够利用整个架构中的最佳实践来帮助您的应用程序、数据库和服务实现您的业务目标。