如何评估我的网卡是否需要更换

如何评估我的网卡是否需要更换

网络接口卡 (NIC)，通常称为网卡，是任何服务器基础设施的重要组成部分。它使集群中的系统能够相互通信并与外界通信。如果您的 NIC 出现问题，可能会危及您的服务器的正常运行。簇导致虚假节点故障，或增加脑裂风险。及早识别网卡故障迹象可以节省时间，减少停机时间并保持高可用性。

在此博客中，我们将探讨如何评估您的网卡是否需要更换、需要注意的症状以及可以帮助您诊断问题的工具。

NIC 故障的常见症状

1. 间歇性连接

NIC 故障的首要迹象之一是连接不稳定或断断续续。您可能会注意到丢包、高延迟或难以访问外部主机。这些问题可能会导致节点生命守护者集群暂时失去连接并触发不必要的故障转移。

2. 网络速度下降

如果系统在执行网络相关任务时表现不佳，例如复制速度慢、应用程序响应迟缓或心跳通信延迟，则可能是由于网卡故障，导致其不再以额定速度运行（例如，1 Gbps 与 10 Gbps）。在集群环境中，复制速度慢尤其令人担忧，因为它会延迟节点之间的数据同步。这不仅会增加故障转移时的恢复时间，还会增加数据丢失或系统状态不一致的风险（如果在复制完成之前发生完全故障）。

3.系统日志显示网络错误

如果内核或系统日志中频繁出现与网卡驱动程序或接口相关的消息，例如“链路断开”、“网卡重置”或“设备无响应”，则表明操作系统在硬件或驱动程序层面与网卡通信存在问题。

4. 异常发热或物理损坏

虽然并不常见，但物理检查可能会发现诸如烧焦痕迹或过热等损坏。这种级别的硬件问题可能会迅速降低性能甚至导致彻底故障，这在任何环境下都是不可取的。

5.虚拟或云环境中的问题

在虚拟化和云环境中，网卡行为不仅会受到底层硬件的影响，还会受到虚拟机管理程序或虚拟网络层配置的影响。例如，如果使用不兼容/过时的驱动程序，或者即使为虚拟机分配了未针对所需工作负载进行优化的适配器类型，通过 VMware 或 Hyper-V 分配的虚拟网卡的性能也可能会下降。

适用于 Windows 和 Linux 的网卡故障排除工具

尽早诊断 NIC 问题有助于最大限度地减少停机时间并避免不必要的故障转移。以下是识别硬件或驱动程序相关 NIC 问题的重要工具，包括适用于 Linux 和 Windows 环境的选项：

• ethtool (Linux)：使用此工具查看网卡统计信息、驱动程序信息和最新链路状态。大量的发送/接收错误、丢包或自动协商失败可能表明网卡性能下降。
• PowerShell cmdlet（Windows）：Get-NetAdapter 和 Get-NetAdapterStatistics 允许您检查 Windows 系统上的链接状态、速度和适配器健康状况。结合 Get-NetEventSession，您还可以跟踪与 NIC 行为相关的事件日志。
• dmesg / journalctl（Linux）或事件查看器（Windows）：这些工具有助于发现系统或内核级别的警报。查找诸如“网卡重置”、“链路断开”或“设备无响应”之类的消息。在 Windows 中，这些消息可能出现在“系统”或“应用程序”日志中，指示驱动程序崩溃或硬件无响应。
• ping / iperf（跨平台）：用于测试基本的连接和吞吐量。如果测试过程中出现丢包、抖动或意外的延迟峰值，则可能表明硬件或线缆存在故障。
• 网络绑定故障转移行为：使用绑定或组合接口实现冗余时，请观察是否有一个接口比其他接口更频繁地触发故障转移事件。这可能意味着即使没有报告系统错误，故障网卡的性能也会悄无声息地下降。

何时更换 NIC？

如果出现以下情况，则可能需要更换 NIC：

• 您观察到上述症状持续存在或恶化。
• 日志和工具确认在驱动程序更新或固件重新安装后仍然存在的硬件或驱动程序问题。
• 当 NIC 移动到另一个系统（如果可移动）时，问题就会随之出现。
• 该卡已过时，并且不受当前操作系统或集群工具支持。
• 您处于高可用性 (HA) 环境中，服务的连续性至关重要。在这种情况下，最佳做法是在故障排除的同时主动将服务或资源迁移到已验证网卡状态正常的节点，以避免出现故障转移延迟或意外停机的风险。

避免网卡故障的预防措施

为了避免与 NIC 相关的故障：

• 使用冗余：跨多个 NIC 实现绑定或组合。
• 保持固件更新：定期检查硬件供应商提供的驱动程序和固件更新。
• 主动监控：使用工具和第三方网络监控来捕捉 NIC 性能下降的早期迹象。
• 定期测试：作为定期集群健康检查的一部分，验证链接速度和延迟。

关于维护网络接口卡健康的最终思考

网卡可能并非最引人注目的硬件，但它的健康状况对于稳定、高可用性环境至关重要。了解何时以及如何评估网卡的性能有助于防止意外停机，确保无缝的故障转移行为，并保持集群通信的弹性。

SIOS 技术公司提供高可用性集群软件通过集群管理来保护和优化 IT 基础设施，以适应您最重要的应用程序。立即申请演示。

作者：Aidan Macklen，SIOS Technology Corp. 客户体验工程师实习生

经许可转载SIOS

与高可用性相关的应用程序智能

与高可用性相关的应用程序智能

高可用性 (HA) 背景下的应用程序智能是指系统实时了解应用程序的行为和健康状况并做出智能响应以保持持续服务可用性的能力。

什么是应用智能？

那么，什么是应用智能？应用智能涉及监控、分析和响应多种因素。这些因素包括应用程序状态，例如应用程序处于启动状态还是关闭状态。性能指标包括响应时间、错误率、吞吐量和内存使用情况。应用程序依赖项，例如数据库或外部服务。最后，他们会关注用户行为或模式。使用应用程序智能可以更全面地了解应用程序。它使用各种数据点来对应用程序本身的状态（而不仅仅是基础设施）做出明智的决策。让我们以 Web 服务器为例；仅仅知道服务器是否正在运行是不够的，还要知道网站是否可以无错误地访问？响应速度是否很慢？用户是否需要多次刷新才能访问？网站所依赖的数据库是否也正常运行且可访问？以上所有都是应用程序智能衡量成功的因素示例。

LifeKeeper 如何使用应用程序智能

那么，生命守护者如何使用应用智能来增强关键应用的高可用性？让我们来详细分析一下。LifeKeeper 使用特定于应用程序的恢复工具包 (ARK)包含每个应用程序的知识（树液，SQL，PostgreSQL，甲骨文等）。这使得 LifeKeeper 能够处理每个应用程序的启动/关闭过程，监控应用程序及其依赖项的健康状况，并在不损坏任何数据的情况下协调智能故障转移/故障恢复操作。用户可以在 LifeKeeper 中将相关资源按层次结构组合在一起，这使得 LifeKeeper 能够理解不同应用程序组件之间的依赖关系（例如，当服务依赖于 IP 或数据库时）。这确保了 LifeKeeper发生故障转移按照正确的顺序和恢复操作不会破坏应用程序或使其处于不一致或损坏的状态。

此外，LifeKeeper 还会进行深度健康检查，不仅确定服务器是否正常运行，还会进行更详细的检查，例如数据库是否正在接受连接，或者 Web 服务是否返回预期响应。它甚至可以监控某些预期的后台进程是否正在运行。LifeKeeper 还使用特定于应用程序的配置文件来确保跨节点的数据配置一致性，并确保应用程序设置得到正确保存或恢复。最后，LifeKeeper 能够使用自定义脚本进一步微调这些深度检查，以智能地支持不太常见或自主开发的应用程序。

PostgreSQL ARK：应用程序智能的真实示例

为了更深入地了解，我们可以看看 PostgreSQL ARK 如何使用应用程序智能。PostgreSQL ARK 通过了解特定的 PostgreSQL 启动和关闭命令、了解 postgresql.conf 和 pg_hba.conf 等关键配置文件，以及理解数据目录布局和锁定文件行为，使用特定的逻辑来监控、启动、停止和故障转移 PostgreSQL。

PostgreSQL 的智能监控和有序故障转移

此外，它不仅检查 PostgreSQL 是否正在运行，还会检查数据库是否响应查询、正确的数据目录是否可访问以及事务日志中是否存在任何损坏。它使用依赖项跟踪来确保 PostgreSQL 经常依赖的资源可用，例如用于客户端连接的虚拟 IP 以及用于其数据目录的已挂载存储。这确保了 LifeKeeper 在发生故障转移时能够按正确的顺序启动资源，例如先挂载磁盘，启动 IP，然后启动 PostgreSQL，最后验证服务健康状况。

防止裂脑并确保数据完整性

最后，LifeKeeper 使用应用程序智能来避免裂脑（一种多个节点认为自己是“主”节点的现象）场景，避免启动两个具有相同数据目录的活动 PostgreSQL 服务器，并通过在写入仍在进行时不进行故障转移来避免数据损坏。这些都是 LifeKeeper 和各种 ARK 实现应用程序智能的不同方式的示例，旨在使组合产品尽可能具有弹性。

通过智能高可用性增强应用程序的弹性

总之，LifeKeeper 的内置应用程序智能通过了解应用程序的行为方式及其正确运行所需的条件，实现了精确、快速和可靠的故障转移和恢复。

确保应用程序的弹性和不间断的服务—请求演示或者开始免费试用今天体验 SIOS LifeKeeper 如何使用应用程序智能来保护您的关键工作负载。

作者: Cassy Hendricks-Sinke，首席软件工程师，团队负责人

经许可转载SIOS

在 Nutanix 环境中选择高可用性解决方案的 10 个注意事项

从 VMware 过渡到 Nutanix

在 Nutanix 环境中选择高可用性解决方案的 10 个注意事项

如果您计划从 VMware 迁移到 Nutanix，那么确保关键应用程序保持正常运行应是您的首要任务。虽然 Nutanix 提供了简化管理和提升性能等诸多优势，但其内置的高可用性仅涵盖虚拟机，而非应用程序本身。本文分享了十个关键见解，帮助您提前规划，避免迁移期间和迁移后出现停机。您将获得实用指导，了解如何为 Windows 和 Linux 选择合适的集群解决方案、如何在 Nutanix 中处理共享存储，以及在运行混合操作系统时需要考虑的事项。无论您是迁移到 Nutanix AHV，还是管理混合环境，都可以了解如何简化高可用性策略、降低风险并保护最重要的系统。

经许可转载SIOS

我的服务器是一次性的吗？高可用性软件如何融入云最佳实践

我的服务器是一次性的吗？高可用性软件如何融入云最佳实践

在这VMblog 文章《我的服务器是一次性的吗？高可用性软件如何融入云最佳实践》探讨了云计算的转变如何改变了服务器在现代 IT 环境中的角色和认知。随着自动化和基础设施即代码的兴起，服务器变得越来越可抛弃，易于创建、销毁和更换，这与 AWS 完善架构框架中概述的云最佳实践相一致。然而，Merry 强调，虽然基础设施可以视为临时的，但在其上运行的应用程序仍然至关重要，必须持续可用。为了弥补这一差距，高可用性 (HA) 软件发挥着至关重要的作用，它通过将应用程序连续性与底层服务器硬件分离，使 IT 团队能够保持正常运行时间和可靠性。这种方法使组织能够充分利用云环境的灵活性，同时又不损害其关键应用程序的稳定性和性能。

作者：Beth Winkowski，SIOS Technology Corp. 公共关系

经许可转载SIOS

灾难频发世界的数据恢复策略

灾难频发世界的数据恢复策略

从事软件工程、系统管理和客户支持等工作，能够让你有机会接触各种配置和各种问题。此外，这样的职位还能让你深入了解用户的各种需求、痛点和顾虑，而纯工程岗位的从业者可能无法接触到这些。

在支持团队工作近五年，我注意到与我共事的各个团队都存在一些模式。此外，当我被要求协助处理各种配置时，我有机会比较不同的用例和根本原因。因此，我希望在开始与新团队合作时，能够确保打下基础。打下这个基础意味着确保管理实践能够与 HA/DR 套件完美协作，确保团队了解如何进行高可用性设计，以及如何利用系统上软件以外的实用程序来取得成功。这个基础对于确保团队了解如何达到或超越其运营标准至关重要。总结一下常见问题以及他们的答案，为那些对实施高可用性解决方案或者只是想改用新的高可用性解决方案。无论您是刚开始学习系统管理/系统工程的学生，还是被要求扩展职责范围以涵盖系统架构规划的资深软件工程师，以下几点都可以帮助您充分利用高可用性/灾难恢复套件。

不用多说，下面的问题总结了我在我的工作中看到的常见谈话要点，并将帮助您更轻松地理解关键概念并找到合适的解决方案。

什么是灾难恢复？它包含哪些内容？

灾难恢复，当与高可用性致力于优化恢复时间目标 (RTO)（服务恢复前无法访问的时间）和恢复点目标 (RPO)（从备份恢复时可以承受的数据丢失）。恢复时间目标描述系统在停机状态下仍能保持运行标准的时间长度。通常，此指标以百分比表示——常见的“五个九的正常运行时间”指的是 99.999% 的正常运行时间，或者每年最多停机 5 分钟左右。恢复点目标稍微复杂一些，它描述了在符合运行标准的情况下可以丢失的数据量。例如，如果系统在灾难发生后不会丢失任何数据，则称为“零 RPO”。将系统想象成一条时间轴，并将恢复点目标视为以下问题的答案会很有帮助：“如果系统遭遇灾难，您可以‘回溯’系统时间轴的多久，同时仍然满足运行标准？”

灾难恢复与传统的应对中断的方法有何不同？

传统上，如果没有高可用性的基础设施，灾难发生后的环境可能需要很长的恢复时间。系统需要恢复，问题需要解决，应用程序需要管理员启动。根据问题的严重程度，可能需要数小时甚至更长时间才能恢复正常运行。团队必须高效工作，保持紧密沟通，以确保服务无误地恢复，以免再次延迟恢复运营。此外，此类中断期间的数据丢失可能非常严重。如果最近没有备份，或者无法访问最新数据的副本，那么团队可能会依赖已经“过时”的数据，并因关键数据的丢失而遭受组织范围内的运营挫折。从客户的角度来看，当您需要在线服务时，您愿意等待多长时间才能获得访问权限？作为客户，如果在线商店丢失了您的交易记录，您能接受吗？

引入高可用性基础架构、镜像存储方法以及协调高可用性的方法后，影响 RTO 和 RPO 的因素均会得到优化，从而能够更从容地应对灾难。高可用性基础架构具备冗余性，因此可以使用备用系统接管运行。此外，协调器（用于管理集群环境的软件）能够系统地在备用系统上启动服务，其响应速度、可靠性和效率远高于手动干预。因此，恢复时间目标得以缩短，灾难恢复时间可能只需几分钟甚至更短，而非数小时。

高可用性基础设施的另一个方面是数据冗余。磁盘可以“镜像”，连接到不同系统的磁盘都可以实时接收完全相同的数据。因此，上述备用系统上可用的数据可以是精确的副本，从而有效地维护灾难发生前的数据备份。反过来，当服务恢复时，应用程序将以接近零的恢复点目标运行，从而在编排器将操作移至备用系统时，将恢复点目标保持在尽可能最新的运行状态。

组织在设计高可用性灾难恢复 (HADR) 策略时最常犯的错误是什么？如何避免这些错误？

最常见的失误之一是缺乏 QA/测试环境。SIOS 客户体验团队已经处理过多个此类案例，这些案例中，组织试图在应用程序/操作系统上修补/升级或者仅仅是由于规划不足或某种不幸的不兼容而导致的日常维护和体验问题。然后，停机时间环境发生故障，维护过程变成了恢复过程。这会导致生产环境中出现延迟、复杂性以及螺旋式问题的可能性。

到目前为止，能给组织提供的最大建议是创建一个以质量保证能力运行的生产环境一对一副本。生产中需要执行的每个流程都应首先在 QA 环境中进行“彩排”。这使组织能够自由地执行计划中的操作并进行改进，而不会危及基础设施的生产能力。在安全、低风险的环境中进行操作练习，可确保团队随时准备在生产环境中运行，避免遇到意外问题的风险，也不必在压力下“脱稿”快速正确地做出响应。如果 QA 环境中出现问题，则可以联系支持团队，并在确保问题不会影响业务运营的前提下进行调查。这可以极大地提高以可控、有计划且有效的方式找到解决方案并将其应用于运营的可能性。

上述 QA 环境的优势对任何组织都至关重要；然而，随着组织采用更复杂的维护策略，此测试环境的存在也变得更加重要。使用此测试环境不仅可以促进更顺畅的升级流程，还能帮助公司在采用引入复杂性的维护模型时降低风险，从而在维护活动期间提高系统可用性。​​在任何情况下，在 QA 环境中测试维护计划，根据“预演”的结果改进计划，并利用从实践中获得的经验，使组织能够管理生产系统，同时最大限度地降低遇到问题的风险。

消除单点故障的重要性是什么？

团队可能遇到的另一个常见障碍是架构中存在“最薄弱的环节”，而该环节无法从环境其他方面所获得的规划程度中获益。最好用一个例子来描述这一点。SIOS 客户体验团队曾经与一位客户合作，该客户在设计过程中围绕如何保持SAP 应用程序在其环境中运行的服务器，并很好地避免了影响运行 SAP 应用程序的系统的问题。遗憾的是，该客户投入了大量的规划精力来保护其应用程序，而没有投入同样的精力来规划其环境的其他方面。结果，所有系统都依赖于一个单一的内部 DNS 系统来解析其私有网络内的主机。尽管在保护方面付出了巨大的努力，树液当他们的 DNS 系统出现问题时，整个环境都会面临严重的问题，因为名称解析不再可用。实际上，他们为保护 SAP 应用程序所做的努力并没有帮助他们的环境渡过难关，因为 DNS 是所有其他系统正常运行所依赖的“薄弱环节”。在规划环境时，务必退一步，放眼全局——关注架构中出现的最薄弱环节。改进最薄弱的环节可以提升整个环境抵御灾难的可能性。

对于严重依赖云服务的组织，他们如何防范区域或地区范围的灾难？

只需按地理位置分配资源即可防范区域或地区范围的灾难。例如，有人可能将其主应用服务器托管在美国东部地区。然后，为了防止影响美国东部地区的中断，在远离美国东部地区（可能是美国西部地区）的“灾难恢复站点”中托管备用系统。虽然这确实引入了一些额外的步骤来确保跨区域通信，但这种努力是无价的，因为它可以防范区域和地区范围的灾难。通过在美国西部地区运行应用程序，可以承受云提供商美国东部地区全面中断。针对特定区域发生的中断的防护不需要很复杂，并且确保存在灾难恢复站点来承担运营将提高生产环境中的应用程序可用性和数据冗余。

您建议组织如何平衡实施强大的 HA/DR 策略的复杂性和成本与业务敏捷性的需求？

人们普遍认为高可用性/灾难恢复 (HA/DR) 解决方案要么复杂，要么昂贵，或者两者兼而有之。基于这一假设，我们必须密切关注眼前的风险。系统是为了某些业务目的而运行的，而这又会转化为收入。当系统因中断而宕机时，其成本远不止收入损失。如果没有 HA/DR 策略，中断需要员工积极地排除故障，这会产生员工工时成本，并将其计入停机成本中，甚至可能在员工休息不足、无法全力以赴工作的时间进行。此外，当员工不得不将任务切换到解决生产问题，然后再切换回正常工作时，常规工作中断以及延迟/缓慢，也会产生持续的附带成本。此外，声誉成本可能会导致无法识别创收机会。例如，如果您想到“CrowdStrike”？即使这不会立即带来问题和相关的负面报道CrowdStrike 在 2024 年 7 月经历了类似的困境，但在撰写本文时（2025 年 3 月 25 日），其股价才刚刚恢复到 2024 年 7 月 19 日发行股票之前的水平。考虑到配置 HA/DR 解决方案的机会成本，上述因素可能会极大地改变分析结果。SIOS 客户通常会发现，从长远来看，实施 HA/DR 解决方案可以节省成本。此外，凭借 SIOS Technology 数十年来对 HA/DR 产品不断改进和迭代的支持，配置此类解决方案的复杂性比以往任何时候都更加易于理解和简化。如果您仍然担心将 HA/DR 解决方案引入生产环境的复杂性，SIOS Technology 提供的专业服务可以帮助您培训团队、执行安装和配置活动，或者只是验证现有配置。凭借这些机会，将高可用性引入​​系统架构不仅比以往任何时候都更简单，而且实施速度也比以往任何时候都更快。最后，对于那些担心独特配置带来的复杂性，或希望最大限度地发挥 HA/DR 解决方案效用的组织，我们世界一流的支持团队随时准备提供帮助，充分发挥任何实施方案的潜力。

SIOS 技术的解决方案如何帮助组织实施您所倡导的灾难恢复方法？

SIOS Technology 的解决方案可以满足前面提到的所有方面，以下列举其中的一些：

我们采用现代灾难恢复方法LifeKeeper 和 DataKeeper 产品，我们统称为SIOS 保护套件无论在 Linux 还是 Windows 上，这些产品均可提供集群范围的资源编排，确保快速高效地应对灾难，同时确保数据在备用系统上复制并可用。LifeKeeper 监控应用程序故障并在节点之间通信，以确保系统是应用程序恢复的有效目标。Datakeeper 实时复制数据，确保备用系统能够在出现问题时继承应用程序，并继续使用最新的可用数据运行。这些产品协同工作，最大限度地缩短应用程序停机时间，并在灾难发生时最大限度地减少数据丢失。

这些产品还能与您的环境完全集成。它们提供高效的网络控制机制，使客户端始终能够解析与应用服务器的连接。这些解决方案不仅可以监控应用程序或系统的特定组件，还可以监控整个系统和环境。通过使用“仲裁”功能，可以在“全局”层面监控环境，确保应用程序在正确的系统上恢复，并保护数据。SIOS Protection Suite 针对各种灾难场景提供保护措施，因此能够做出适当的响应。

SIOS Protection Suite 还能够跨区域运行，提供我们之前讨论过的针对区域级或区域级灾难的保护。应用程序可以跨区域迁移，数据可以像在同一区域内复制一样轻松地跨区域复制。此外，环境可以多层级。主区域中可以托管多个节点，并充当活动系统或备用系统，从而快速响应系统级问题，同时还可以维护位于不同区域的灾难恢复站点，以确保以相同的速度和保护效率抵御区域级灾难。

最后，SIOS Protection Suite 产品受益于数十年的实际应用。它已在各种场景和部署配置中历经考验，并受益于多年来不断改进的易用性。因此，它是一款灵活、易于部署且可无缝融入生产环境的解决方案。采用 SIOS Protection Suite，可以避免设计和配置 HA/DR 解决方案的复杂性，并享受其丰富的开发历史和无数的改进，以及世界一流的支持团队，随时准备为您解决任何疑问或担忧。除此之外，您还有机会参与 SIOS Protection Suite 产品的协作安装或验证程序，确保您的环境能够应对各种挑战。最后，对于需要经验丰富的员工并希望最大限度地利用 SIOS Protection Suite 及其组件的团队，SIOS 提供培训活动，团队可以与我们的员工合作，了解正在发挥作用的组件，并进行积极的讨论，以促进深入的理解，确保员工能够立即掌握实施解决方案所需的所有信息，以最大限度地发挥其潜力。

保护您的业务免遭停机和数据丢失——请求演示或者开始免费试用看看 SIOS 的实际运行情况。

作者：Philip Merry，CX – SIOS Technology Corp. 软件工程师

经许可转载SIOS