在传统基础设施中维持高可用性的三大挑战

对于依赖持续访问应用程序、服务和数据的组织而言，高可用性 (HA) 至关重要。无论是支持面向客户的平台还是内部业务运营，停机都可能迅速导致经济损失、生产力下降和声誉损害。尽管许多公司由于成本、兼容性或业务需求而继续使用传统基础设施，但随着时间的推移，在旧环境中维护高可用性变得越来越困难。传统 IT 系统通常会引入现代平台旨在避免的技术限制和运营风险。

传统基础设施最常见的问题之一是软件包、库和系统组件之间日益增长的不兼容性。老旧技术通常基于多年前设计的紧密耦合依赖关系构建，当时解耦理念尚未真正得到实践应用。随着时间的推移，这些系统变得难以更新，因为软件已经发生了巨大变化，或者不再维护。

以下是一些使用老旧基础设施时可能遇到的问题示例：

• 更新一个软件包或库可能会无意中破坏依赖于旧版本的其他组件。我以前就遇到过这种情况，一个依赖项导致另一个依赖项，如此循环往复，结果几个小时就过去了，因为你得重新编译十几个软件包！
• 缺乏关于服务如何交互的文档可能会使升级变得困难。
• 最后，现代监控、安全或自动化工具可能无法与过时的系统无缝集成。在高可用性环境中，即使是微小的兼容性问题也可能引发重大中断。

将基础设施现代化规划纳入您的高可用性战略。

保持高可用性老旧的基础设施会带来技术和运营方面的挑战。软件包不兼容、供应商支持有限以及内部专业技术水平下降都可能威胁系统稳定性，并增加停机风险。

尽管传统系统可能继续发挥重要的业务功能，但企业应积极规划基础设施现代化，改进文档编写规范，并投资于知识转移，以免关键专业技能流失。强大的高可用性策略旨在确保未来长期可靠性、安全性和运营弹性。

作者：Cassy Hendricks-Sinke，SIOS IT 运维高级系统工程师

经许可转载SIOS

本地数据中心的高可用性

实现本地数据中心高可用性的三个要素

对于运行本地数据中心的组织而言，保持强大的高可用性实践对于保持关键系统在线至关重要。

尽管云基础设施持续扩展，但许多组织仍然依赖于自己的基础设施。根据……Uptime Institute约 48% 的北美公司继续运营自建数据中心。

对于这些组织而言，投资于高可用性对于维持业务连续性、保障收入以及为用户提供可靠的服务而言，高可用性至关重要。无论您是构建新的基础设施还是管理现有系统，以下三个方面都是实现高可用性的关键：

• 保护物理数据中心
• 设计具有韧性的基础设施
• 使用合适的操作工具

确保高可用性的物理数据中心安全

在讨论高可用性时，物理环境往往被忽视。然而，基础设施的可靠性始于保护设施本身。

各组织应采取措施防止因停电、环境问题或未经授权的访问而造成的业务中断。常见的安全措施包括：

• 安全摄像头和访问控制
• 备用电源系统，例如发电机和不间断电源（UPS）单元
• 像FM-200这样的灭火系统
• 环境监测温度和湿度

这些保护措施有助于确保系统保持稳定运行。

确保持续正常运行的弹性基础设施

高可用性取决于消除单点故障。通过构建冗余建立基础设施后，即使系统发生故障，组织也能继续运营。

常用策略包括故障转移集群、冗余网络路径、RAID 存储和异地数据复制。灾后恢复一些组织还会采用混合云或多云架构，以减少对单一提供商的依赖。

如果使用备用数据中心，则不应与主数据中心共用同一电力基础设施。灾难恢复和业务连续性计划还应包括本地备份和异地备份。

高可用性运维工具和集群

运维工具帮助 IT 团队监控系统、应对突发事件并维持服务连续性。

许多组织首先采用 IT 运维管理平台来发现网络资产并维护配置管理数据库 (CMDB)。然后，应用性能监控 (APM) 工具可以提供更深入的系统运行状况洞察，帮助团队做出更明智的运维决策。

另一个关键组成部分是聚类。高可用性集群当发生故障时，自动将应用程序和服务迁移到辅助节点。这些集群可以使用共享存储或基于软件的无SAN架构。

如今，许多组织更倾向于……无SAN集群因为它们具备与传统SAN集群相同的故障转移能力，同时又提供了更高的灵活性和更低的成本。它们还支持本地部署、云部署和混合部署，包括用于灾难恢复的地理分布式环境。

保持本地数据中心服务的可用性

尽管IT环境不断发展演变，但有一项优先事项始终不变：最大限度减少停机时间并保持服务的可用性。

通过关注物理安全、弹性架构和有效的运营工具，企业可以增强其本地数据中心的可靠性，并确保关键应用程序保持在线状态。

准备好增强本地环境的高可用性了吗？立即申请 SIOS 演示了解我们的集群解决方案如何帮助您保持关键应用程序的在线状态。

经过：戴夫·伯明翰

经许可转载SIOS

博通/VMware：是时候将高可用性与虚拟机管理程序解耦了

如果您是 IT 架构师、管理员或站点可靠性工程师 (SRE)在 VMware 上管理关键工作负载2026 年伊始，你的系统更新问题可能就让你头疼不已。自从被博通收购后，“博通税”就成了众所周知的成本。从取消永久许可、强制转向大规模订阅套餐，到苛刻的 72 核最低配置要求，“采用 VMware”实际上已经变成了一种强制过度配置。

但还有比价格上涨更大的风险：应用程序停机造成的损失。

“虚拟机重启”谬误：为什么 VMware HA 并非真正的高可用性

多年来，业界一直将“VMware HA”误认为是真正的高可用性。如果主机发生故障，VMware 会在另一台服务器上重启虚拟机。虽然这种重启速度很快，但它并非真正的高可用性。

VMware HA 仅监控物理服务器的“心跳”信号，以确定主机是否正常运行。它无法感知虚拟机内部的情况。因此，它无法检测到挂起的数据库、死锁的应用程序服务或不可用的存储。

当今的关键任务生态系统——SAP HANA，SQL Server，甲骨文而人工智能驱动的GPU系统——仅仅依靠“断电重启”是不够的，它们需要应用层面的保护。

SIOS LifeKeeper：通过应用感知智能实现真正的高可用性

SIOS LifeKeeper 提供对应用程序环境的全面可视性，涵盖网络、存储、操作系统和数据库层。它确保快速、应用感知的故障转移，并遵循特定应用程序的最佳实践，从而提供可靠的正常运行时间，而不仅仅是快速重启。

博通的许可模式实际上会限制您的增长，并将您束缚在其生态系统中，而SIOS则提供了真正的架构自由。我们与平台无关的许可模式允许您将工作负载迁移到AWS、Azure或其他虚拟机管理程序，而不会损失高可用性保护。使用SIOS，您购买的不仅仅是软件，更是摆脱供应商锁定的可靠退出策略。

VMware 价格调整后如何大幅降低总体拥有成本：保护应用程序，而非虚拟机管理程序

Broadcom 不仅要求您购买订阅许可证，而且通常还要求您升级整个 VMware 堆栈或购买臃肿的订阅级别，才能访问单个 Tier-1 应用程序所需的 HA 功能。

为什么要为了保护一个 SQL Server 或 SAP 实例而升级整个基础架构许可证？SIOS 提供企业级高可用性无论 VMware 采用哪种“捆绑”方式来满足 Broadcom 的要求，SIOS 都能与您的应用程序无缝集成。此外，SIOS 还允许您灵活选择购买订阅许可证或永久许可证。

消除SAN和vSAN依赖项的成本和复杂性

许多新的 VMware 套件都在向客户推广 vSAN，在那些每一毫秒都至关重要的环境中，这种趋势尤为明显。SIOS 数据保管器它允许您使用本地高性能 NVMe 存储构建集群。您既能获得集群的保护，又无需承担虚拟 SAN 的专有复杂性或“存储成本”。

SIOS 提供诸如高级数据复制等功能，而这些功能通常被 VMware 限制在其最昂贵的版本中。通过将高可用性与虚拟机管理程序分离，您可以使用更经济的 VMware 许可证来保持世界一流的正常运行时间，从而在下次续订时节省六位数甚至七位数的费用。

VMware HA 与 SIOS LifeKeeper 和 DataKeeper 的比较

特征	VMware HA（vSphere Foundation）	SIOS LifeKeeper 和 DataKeeper
故障转移触发器	仅限主机/硬件故障。	应用程序、操作系统、存储或网络故障。
应用智能	没有。这是一次“黑匣子”式的重启。	SAP、SQL、Oracle 等系统的恢复工具包。
云灵活性	需要特定的 VMware 云堆栈。	原生支持 AWS、Azure、GCP 或混合环境。
存储模型	依赖于 vSAN 或共享存储。	通过本地 NVMe/SSD 构建无 SAN 集群。
许可	复杂、基于核心、捆绑包较多。	可预测、便携、以应用为中心。您可以选择永久使用权或订阅制。

利用应用级高可用性，重获基础设施自由

SIOS 让您可以灵活地按照自己的方式保持高可用性，同时评估您与博通的长期合作关系。

选择 SIOS，您即可自由地在不同平台之间迁移工作负载。VMware，Nutanix或者，无需重写脚本或重新培训团队即可使用公有云。正常运行时间取决于应用程序环境的健康状况，而不仅仅是服务器的电源指示灯。

如果您感觉即将续约陷入僵局，那么是时候将高可用性从虚拟机管理程序转移到应用程序层了。

立即申请演示了解 SIOS 如何在 VMware、云和混合环境中提供应用级高可用性。

作者：Margaret Hoagland，SIOS全球销售和市场营销副总裁

经许可转载SIOS

如何提高技术支持中的客户满意度

我们的客户遍布全球。我们说着不同的语言，身处不同的时区，分布在不同的国家。但在技术支持方面，我们有很多共同之处。我们都希望在遇到问题需要帮助时获得最佳支持。那么，我们究竟想要并期待获得最佳支持，这究竟意味着什么呢？支持实际上是指IT团队吗？

6 客户对技术支持团队的期望

以下是我们的客户告诉我们他们对技术支持团队的期望。

倾听客户的声音

客户（和其他人一样）都希望被倾听。与客户沟通时，重要的是让客户描述问题。作为支持工程师，请做好笔记，认真倾听客户的描述，并提出后续问题以收集重要信息。不要在客户说话时打断他们。为了确认您理解了客户的陈述，请总结客户所说内容。概括行动方案，确保每个人都理解一致。不要在客户描述问题之前就自以为知道问题所在。

与真人交谈

顾客仍然更喜欢与“真人”交谈而不是自动语音/人工智能/聊天机器人。客户喜欢直接与了解产品的客服人员对话，而不是听从脚本。没有什么比打电话寻求帮助时，却不得不经历多个自动化流程才能联系到“真人”更令人沮丧的了。很多时候，你最终会原地打转，回到最初的问题！宝贵的时间可能就这样白白浪费在试图联系到“真人”客服人员上。   顾客来电寻求帮助我们强烈建议您通过视频会议与支持团队实时沟通问题。一图胜千言！根据我们的经验，如果无法提供直观的视觉信息，也无法让客户实时提问，那么解决问题所需的时间将会大大延长。

全天候24小时服务

我们的客户遍布全球，他们希望随时联系客服。我们提供每周7天、每天24小时全天候支持。为了满足这一需求，我们在全球各地设有多个团队，全天候24小时提供服务。客户需要我们的时候，我们随时待命。我们制定了相关流程，以便在我们的团队成员需要紧急协助时，及时升级处理案例。关键停机问题这会影响客户的业务。我们的客户使用我们的高可用性和灾难恢复软件，而我们的技术支持团队随时准备提供帮助，从而强化了这一目标。

经验丰富的支持工程师

客户没有时间跟无法提供帮助、需要把电话转接给其他人的客服人员通话。客户希望直接与能够解答他们疑问、解决问题的支持工程师沟通。SIOS我们始终致力于确保客户能够快速联系到我们经验丰富的技术支持团队成员，以便尽快解决问题。根据我们的客户调查，客户对我们的技术支持团队非常满意！我们的支持团队平均拥有16年的支持经验；这种专业技能使我们能够快速有效地解决各种问题。问题能够迅速得到解决，通常无需升级案件。转至另一组客户。客户很欣赏那些经验丰富的员工，他们可以通过视频会议提供基于多年经验的实时帮助。

保持透明

客户重视透明度，他们想了解真相。不要做出无法兑现的承诺。务必确保客户明白您将采取哪些措施来帮助他们解决问题，以及您何时会再次与他们联系。在推进过程中，向客户解释需要执行的步骤，并确保在执行任何步骤之前都已获得客户的批准。许多客户在对其系统进行更改之前都需要获得预先批准。系统为了保持透明度，及时向客户提供支持流程的最新进展至关重要。即使你的更新内容只是“我们仍在分析日志”，也要告知客户，让他们了解最新情况。不要说他们想听的话，要告诉他们真相。

客户调查

对于客户提交的每一个技术支持案例，案例结束后我们都会向客户发送一份调查问卷。这让客户有机会提供反馈，以便我们的团队能够持续改进产品、文档和支持服务。我们的支持团队每周至少查看一次客户填写的调查问卷，并回复客户的疑问、想法和改进建议，告知他们我们针对这些反馈采取了哪些措施。客户经常感谢我们快速解决他们的问题，并感谢我们认真对待他们在案例结束后留下的反馈，展现了我们对他们成功的承诺。

客户对全天候高可用性/灾难恢复技术支持团队的期望

客户联系技术支持HA/DR产品他们希望听到的是真人而非机器人的声音。他们期待与经验丰富的客服人员沟通，这些客服人员不仅能够解决他们的问题，而且在整个过程中都保持透明。通过提供全天候24小时的人工服务，我们向客户表明，无论何时何地，只要他们需要帮助，我们都会随时待命。如今的技术支持不仅仅是解决工单，更重要的是建立信任、倾听客户的需求，并在客户需要帮助时始终保持可靠和诚实。

正在寻找了解高可用性/灾难恢复 (HA/DR) 的技术支持团队？安排时间与SIOS HA专家会面了解我们如何实现高可用性、自动恢复和可靠的集群部署。

作者：桑迪·汉密尔顿SIOS产品支持工程总监

经许可转载SIOS

 

使用 SIOS LifeKeeper 对非集群感知应用程序进行集群化

并非所有应用程序都是用这种方法构建的。聚类牢记这一点。事实上，大多数人并没有。但这并不意味着他们无法从中受益。高可用性由……提供的保护SIOS LifeKeeper如果你的应用程序可以停止、启动并在另一台服务器上运行，那么很有可能可以对其进行集群部署。

在着手实施之前，有一些关键的考虑因素，这些因素将决定集群实施是成功还是令人沮丧的反复试验。

1. 将动态数据迁移到共享或复制存储

应用程序通常将日志、数据库、缓存和其他应用程序数据等动态数据存储在本地存储中。但在集群环境中，这种方式行不通。故障转移备用节点必须能够访问相同的数据，以便应用程序可以从上次中断的地方继续运行。

解决方案是将所有动态数据迁移到 SAN 环境中的共享磁盘或使用时的复制卷。SIOS 数据保管器静态文件（例如可执行文件）可以保留在本地，但任何在运行时发生变化的内容都应该存储在所有集群节点都可以访问的存储位置。

2. 更新集群环境中的应用程序主机引用

许多应用程序通过名称、FQDN 或 IP 地址来引用本地系统。这在独立配置中没有问题，但在集群中，应用程序需要绑定到集群的虚拟 IP (VIP) 或通过其进行通信。

如果应用程序或其配置文件引用了：

• 本地主机
• 节点的主机名或完全限定域名
• 节点的静态 IP 地址

您可能需要更改对 VIP 或解析到 VIP 的主机名的引用。通常需要检查的位置包括注册表项、配置文件以及应用程序用于连接自身或其他服务的任何连接字符串。

3. 编写自定义启动、停止和监控脚本

集群感知型应用程序包含指示集群如何启动、停止和监控服务的逻辑。非集群感知型应用程序则不包含。这就是 SIOS LifeKeeper 应用程序恢复工具包 (ARK) 的用武之地。

如果你的应用程序没有现成的脚本，你可以创建自定义脚本：

• 开始服务或流程
• 停止切换前将其清理干净
• 监视器例如，通过检查端口、日志文件或进程来评估其健康状况。

在某些情况下，保护应用程序就像启动和停止服务一样简单。针对这种情况，LifeKeeper 提供了快速服务保护 (QSP) 恢复工具包。使用 QSP，您只需选择要保护的服务，无需编写任何代码。LifeKeeper 将自动处理该服务的启动、停止和监控操作。

这些选项使得保护各种应用程序变得轻松便捷，从简单的应用程序到复杂的应用程序。视窗或者Linux在同一集群框架内，为复杂的多组件系统提供服务。

4. 在所有集群节点上正确处理加密密钥

如果您的应用程序对静态数据进行加密，则集群中的每个节点都必须能够解密这些数据。这意味着加密密钥必须在所有节点上都可访问且保持一致。根据您的设置，这可能需要同步本地密钥库或使用集中式密钥管理解决方案。

关键在于，每个节点在激活时都必须能够安全且持续地访问加密密钥。否则，应用程序可能启动，但在故障转移后却无法访问其数据。

5. 考虑故障转移后客户端如何重新连接

当应用程序从一个节点故障转移到另一个节点时，会有一个短暂的中断，因为新的活动节点需要接管 IP 地址并启动应用程序。对于连接到该服务的客户端，其行为完全取决于它们如何处理连接丢失。

如果客户端内置了重试逻辑，用户可能根本不会注意到中断。一旦VIP和服务恢复可用，客户端将自动重新连接。

如果客户端没有包含重试逻辑，用户在故障转移后可能需要手动刷新或重新启动连接。

了解客户端的行为方式并测试其在故障转移期间的响应至关重要。有时，只需添加一个简单的连接重试循环或调整连接超时设置，即可实现流畅的用户体验。

6. 验证集群部署的应用程序许可要求

一个常被忽视的步骤是许可。当应用程序集群化时，它会安装在集群中的每个节点上，但一次只能运行一个实例，即活动实例。一些供应商提供专门的活动/被动集群许可，而另一些供应商则要求每个已安装的实例都需要一个许可。

部署前务必先咨询应用程序供应商。事先进行简短沟通可以避免日后花费大量时间处理许可问题。

7. 对所有应用程序和集群组件进行全面测试

测试是任何集群项目中最重要但又最容易被忽视的环节之一。

不要只测试故障转移。在应用程序受到保护的情况下，测试其所有功能。这包括：

• 启动和关闭顺序
• 所有必需的服务和后台任务
• 任何读取、写入或缓存数据的组件
• 任何依赖于服务依赖项的进程
• 故障转移前、故障转移期间和故障转移后的客户端行为

如果应用程序使用自定义脚本或快速服务流程 (QSP)，请确保每个步骤在负载下都能正常运行。这不仅能及早发现问题，还能确保解决方案在实际事件中能够正确运行。

为非集群感知应用实现高可用性

使用 SIOS LifeKeeper 对非集群感知应用程序进行集群化并不难，但确实需要一些规划。将数据迁移到共享或复制存储，将所有节点指向集群的虚拟 IP 地址 (VIP)，编写启动、停止和监控逻辑脚本（或在适当情况下使用 QSP），确保所有节点上都可用加密密钥，并确认许可要求。

不要忘记测试您的客户端对故障转移的响应情况，因为真正的高可用性意味着您的服务器和用户始终保持连接。

按照这些步骤操作，您会发现即使是最“独立”的应用程序也能实现企业级高可用性。立即申请演示了解 SIOS LifeKeeper 如何为非集群感知应用程序带来可靠的高可用性。

作者：David Bermingham，SIOS 高级技术推广专家

经许可转载SIOS