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

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

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

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

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

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

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

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

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

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

经许可转载SIOS

LifeKeeper 通用应用程序，用于高可用性和灾难恢复

LifeKeeper 通用应用程序，用于高可用性和灾难恢复

保护业务关键型应用程序的成功关键

高可用性和灾难恢复必须涵盖广泛的应用场景。应用场景的数量与组织的数量一样多，远远超出任何单一解决方案的能力范围。高可用性和灾难恢复该解决方案旨在为各种场景提供开箱即用的支持。虽然许多常见应用程序都有丰富的可用高可用性和灾难恢复解决方案，但更具体的用例会限制可用于保护业务关键型应用程序的方案选择。

当然，LifeKeeper 无法开箱即用地涵盖所有用例。然而，LifeKeeper 提供了一个通用且灵活的框架，可以适应各种用例，从而弥补这一不足。虽然功能强大，但对于外行来说，这个框架可能显得复杂。本博客旨在帮助您在为特定用例构思通用应用程序恢复工具包时获得一些帮助。

相关博客和背景阅读推荐

本博客假定读者已熟悉 LifeKeeper 资源层级框架和 LifeKeeper 集群。如需了解这些主题的背景知识，请参阅下方列出的博客。此外，本博客还基于之前一篇关于如何利用 LifeKeeper 中的“快速服务保护应用程序恢复工具包”（QSP ARK）来弥合潜在用例与支持的保护机制之间差距的博客（链接如下）。

• Linux集群/Windows 集群（本文由SIOS全球销售与市场营销副总裁霍格兰女士及SIOS市场营销团队撰写）

• 应用智能与高可用性（本文由SIOS高级软件工程师Hendricks-Sinke女士撰写）
• 资源行动和背景通用应用程序恢复工具包（本文由高级技术推广专家伯明翰先生撰写）
• 在 GenApp 和 QSP 之间进行选择：为您的关键应用程序量身定制高可用性（本文由 SIOS 高级软件工程师 Hendricks-Sinke 女士撰写）。

然而，本博客将探讨当 QSP ARK 无法满足特定应用程序或用例的高可用性和灾难恢复需求时可用的选项。

应用概念化和方法定义

询问有关应用程序健康状况的最细微的问题

系统管理和软件工程都是非常注重细节的领域。一个问题背后可能包含诸多因素，因此很难找到一个简单直接的答案。在日常对话中，这很容易理解。但在代码中，复杂的答案却难以实现。提出“最小问题”的做法，就是将问题聚焦到尽可能小的层面，同时确保答案符合明确的标准。

“应用程序是否正在运行？”这是一个“大”问题，可能需要详细的回答。应用程序确实在运行，但没有响应。应用程序确实在运行，但它运行在另一个系统上，而不是你正在讨论的这个系统上。答案的标准很模糊，而且答案本身也很微妙——开发人员通常都不愿意处理这种细节。

“应用程序进程是否正在运行？应用程序是否正在积极响应查询？”

虽然表述起来更冗长，但这却是一个更小的问题。它清晰地定义了答案为“是”或“否”的条件。尽管这一改变有所改进，但它还不是“最小”的问题。之前的问题同样陷入了“X 和 Y 是否都为真？”的陷阱。“是”或“否”的答案无法提供足够的细节来独立判断 X 和 Y 的真假。最小的问题需要具体性；它必须能够全面洞察整体中最小元素的状态。“应用程序的进程是否在目标系统上运行？”这是一个小问题——在本例中，这就是最小的问题。请记住，可能存在多个“最小”的问题——在本例中，“应用程序是否响应查询”也符合条件。

虽然问题几乎可以无限细分，但还是存在一个限度。“最小的问题？”这句话的含义是“提出一个能够提供有用/可操作信息的最小问题”。问“我是否在去费城的火车上？”就足够了；进一步问“我是否在去费城的火车上，费城是哪个方向？”可以提供更多信息——但这并不能提供可操作的信息。我无法改变火车的行驶方向。我只能从“我是否在去费城的火车上？”这个问题的答案中判断是否需要打电话通知老板我会迟到。

虽然在这个例子中这一点很明显，但在开发通用应用程序时就不那么显而易见了。在保护通用应用程序的整个过程中，仍然需要着眼于全局。这和其他任何事情一样，都是一项技能——通过实践和协作，就能判断出哪些问题是最根本的问题，哪些细微之处不再能提供更多有用的信息。

通用应用程序恢复工具包的构建基础是将宽泛的问题分解为针对各个组成部分的更小、更具体、更有针对性的问题。每个“大问题”都可以通过对其中涉及的各个组成部分的解答综合起来得到解答。

一旦将问题分解成最小的组成部分，需要传递的信息就会变得清晰得多。了解了所需信息后，开发通用应用程序恢复工具包的剩余工作就变成了如何从现有信息中提取所需信息。必须利用已有的信息进行工作。

使用应用程序 API 和 LifeKeeper API

应用程序通常会提供图形用户界面 (GUI) 来显示信息或应用程序发生的更改。虽然这对于人为操作来说非常方便，但当管理工作由应用程序执行时，这种方式就显得不太实用。GUI 是供人使用的，而应用程序（为了避免大量的编程工作和不必要的复杂性）并不具备像人一样与另一个应用程序的 GUI 进行交互的能力。对于 LifeKeeper 和通用应用程序资源而言，通用应用程序恢复工具包的操作脚本与受保护的应用程序之间的信息交换必须通过应用程序编程接口 (API) 来完成。

LifeKeeper 提供自己的 API，用于与 LifeKeeper 本身、其层级结构以及层级结构中的资源进行交互。对于 LifeKeeper 的 API，产品内置的命令行实用程序在通用应用程序中最易于使用。一般建议仅使用 LifeKeeper 产品文档中概述的命令行实用程序（Linux 命令文档/Windows 命令文档应该使用这些命令。即使有了这项建议，使用这些命令时也应谨慎细致，以确保不会产生意外后果。

当然，LifeKeeper并非通用应用程序保护的唯一要素。受保护的应用程序还需要提供API，以便操作脚本能够利用该API实现预期结果。开发通用应用程序恢复工具包确实需要了解受保护应用程序的API，以及如何在构成该工具包的操作脚本中使用该API。

在恢复脚本中使用返回码和输出流

无论是 LifeKeeper 的 API 还是受保护的应用程序，信息主要以两种方式输出：

• 返回代码
• 输出流（有时称为“STDOUT/STDERR 输出”或简称“终端输出”）

返回码如何帮助判断成功或失败

从广义上讲，返回码提供了一种快速判断实用程序是否成功的方法。通常（在 shell 环境中），返回码 0 表示成功，而非零返回码表示失败。

根据应用场景的不同，返回码的具体值可以提供更多关于所遇到错误的信息。通常，只需检查返回码即可推断通过应用 API 执行的操作的结果。

在一些更复杂的情况下，返回码可能仅仅用于告知程序在调用应用程序 API 后应采取何种操作。当处理与底层元素状态相关的实用程序时，返回码尤其有用。

输出流如何提供更详细的应用程序信息

输出流虽然在程序中使用起来比较复杂，但有时对于信息交换或验证结果来说是必不可少的。例如，如果运行一个实用程序来获取系统主机名，仅凭返回码无法确定主机名是什么，除非该实用程序成功获取了主机名。在某些情况下，即使 API 实用程序已获取到请求的信息，它也可能返回成功返回码，但该信息的有效性仍需根据具体情况进行评估。

无论使用返回码还是输出流，开发通用应用程序都需要利用现有信息。在思考如何实现资源操作（下一节将详细介绍）或确定应用程序或 LifeKeeper 资源的相关信息时，请尝试从返回码和输出流的角度思考，而不是从图形用户界面 (GUI) 的角度思考。想象一下通过电话传递信息会很有帮助。也就是说，当实用程序的输入和输出能够准确地作为输入或输出进行报告时，信息传递、操作定义和场景处理才能达到最佳效果。

构建通用应用程序保护的基础

本节主要侧重于策略的概念性阐述。这些策略为思考应用程序奠定了基础，其核心在于如何通过对应用程序提出的问题和采取的操作的响应来进行分析。接下来，我们将更具体地探讨 LifeKeeper 以及通用应用程序恢复工具包的创建过程。同时，这些策略与其他技能一样，需要通过实践来提升。无论是在技术交流、编写流程文档，还是其他任何工作中，练习这些概念化策略不仅能带来短期益处，更能带来长期的益处。

需要帮助保护不符合标准高可用性模型的关键业务应用程序吗？SIOS 可以帮助您评估环境并确定合适的 LifeKeeper 方法。申请演示今天。

作者：Philip Merry，SIOS Technology Corp. 的 L3 支持工程师

经许可转载SIOS

SIOS 企业支持指南：您的计划涵盖哪些内容

SIOS 企业支持指南：您的计划涵盖哪些内容

您的 SIOS 企业支持计划包含哪些内容？

以下是一些关于企业级支持涵盖范围和不涵盖范围的快速提示，以及根据三种常见场景，从哪里获取更多信息。

全天候支持关键系统停机

场景 1：下班后系统宕机

琼的团队：现在是美国东部时间周日晚上7点。SIOS LifeKeeper集群节点之间的例行切换原本应该很简单，但意外情况发生了，导致切换失败。尽管团队尽了最大努力解决问题，集群仍然处于宕机状态。琼需要帮助，但她不确定自己的SIOS技术支持计划是否涵盖周末，也不知道需要多久才能联系到技术支持人员。

在事件发生前已购买（或续订）企业级支持服务的客户，可享受每周 7 天、每天 24 小时全天候支持服务。此支持服务包括周末和节假日，以解决关键问题。关键问题是指生产系统或应用程序宕机，导致客户数据无法通过 SIOS 程序访问。对于所有优先级 1（关键）问题，即正常运行导致无法访问生产数据的问题，SIOS 承诺在 2 小时内响应。

如果 Joan 拥有有效的企业支持，她就可以联系 SIOS 支持团队，她的非工作时间问题将得到解决。

安装和配置支持

场景二：需要安装协助

斯科特的团队：现在是周四下午4点（美国东部时间）。新基础设施项目的审批已经完成，包括关键应用程序和数据所需的高可用性配置。在启动会议上，利益相关者推迟了上线日期。因此，团队需要尽快完成系统安装和配置，以避免服务中断。斯科特的团队知道如何配置应用程序和服务器，但他们希望确保高可用性解决方案安装正确。他们需要帮助，但斯科特不确定他们的支持计划是否涵盖安装错误方面的帮助。

由于 Scott 的团队正处于部署阶段，新的基础设施项目涉及的系统尚未经过验证或成功投入生产。如果 Scott 的团队拥有有效的 SIOS 企业级支持，他将可以访问 SIOS 产品文档和安装指南。但是，Scott 的企业级支持不包含安装和配置方面的协助，但他可以联系 SIOS 销售代表安排付费的专业服务安装。这项服务将确保 Scott 的团队获得正确安装、配置和验证集群所需的帮助。SIOS 提供广泛的……专业服务旨在帮助客户快速、经济高效地实施、管理和维护其高可用性环境。

故障转移后的根本原因分析 (RCA)

场景 3：故障转移后根本原因分析支持

阿莫尔的团队：现在是周二凌晨2点（美国东部时间）。AjaxBjax公司的所有应用团队都收到了警报。保护公司最关键应用系统的集群正在进行故障转移。阿莫尔查看了应用控制面板，发现故障转移成功，所有应用都在正常运行。然而，阿莫尔知道管理层会要求一些解释和保证。阿莫尔想确保所有应用服务都已启动并正常运行，但他不确定他们的支持计划是否涵盖这种情况。

Amol 的团队正在寻求根本原因分析 (RCA)，并确保他们的系统能够持续运行。Amol 的数据可以访问，他的应用程序功能齐全。他的系统并非关键的生产服务器宕机，也不是 P1 级问题。但是，如果 AjaxBjax 公司为其集群购买了有效的企业级支持，他们就可以联系 SIOS 支持团队，获得周一至周五（美国东部时间）全天候的 RCA 问题指导。Amol 凌晨 2 点的来电将被转接到 SIOS 经验丰富的支持中心，该中心的团队将立即开始与 Amol 合作。

关于联系 SIOS 支持的其他问题

Amol 和 Joan 通过企业支持热线（美国：877.457.5113；国际：+1.803.808.4270）联系到了技术支持。Scott 则通过购买配置和安装协助服务而非直接联系技术支持团队获得了所需的帮助。但对于其他情况呢？Scott、Amol、Joan 和其他用户如何才能了解更多关于他们的支持级别和支持详情的信息？或者他们的产品是否已进入维护或扩展支持阶段？

当您需要了解有关支持协议的更多信息时，可以查阅随每份订单提供的 SIOS 技术支持协议 (TSA)。您也可以在我们的网站上轻松找到 TSA。下载站点您可以通过发送电子邮件至 SIOS 支持团队提出请求。support@us.sios.com此外，产品时间表和支持级别信息可在网上找到，网址为：产品生命周期页。

如果客户已经了解其计划涵盖的内容，但需要帮助解决问题、解答一般性问题、进行根本原因分析、获取最新软件或获取更多信息，可以通过以下方式提交新案例：支持门户可通过网站或发送电子邮件至支持收件箱support@us.sios.com一旦您的案件创建完成，团队将努力提供及时的回复和解决方案。

作者：卡修斯·鲁，客户体验副总裁

经许可转载SIOS

为什么沙箱环境对高可用性至关重要

为什么沙箱环境对高可用性至关重要

说服管理层投资非生产基础设施

说服管理层投资非生产基础设施并非易事。如果处理不当，关于增设测试集群或沙箱环境的讨论很快就会演变成抱怨要为环境（基础设施、软件、IT资源、应用程序和许可证）支付双倍费用，以及指责测试人员。集群“不产生任何收入”。关于成本的讨论逐渐演变成各种断言，例如备份、DevOps 和软件运行手册已经使测试环境过时。

然而，如果没有与生产环境完全相同的测试环境，其成本通常会比额外搭建一个测试集群的成本高出指数级。这些额外成本往往以计划外停机、数据损坏、紧急修复以及工程团队压力过大等形式隐藏起来。

10 个问题有助于论证沙盒环境的必要性

如果您在为建立合适的沙盒环境争取预算审批方面遇到困难，不妨向您的领导团队提出以下 10 个问题。这些问题能将讨论的重点从重复集群的成本转移到确保业务免受损失的价值上。

1. 停机时间究竟会给我们的组织造成多大的损失？

首先要考虑的是最终结果。如果部署失败，生产高可用性集群宕机，会对组织造成多大的损失？每小时损失多少？我们公司每个业务部门的资源消耗率是多少？

这个问题将讨论从模糊的说法引向了更具体的层面，例如每分钟的收入损失、停机期间员工闲置的工资，以及更难以量化的声誉损失。如果生产中断每小时造成 30 万美元的损失，那么每年只需避免一次 4 小时的停机，就能节省 120 万美元。有了这些切实可行的商业数据，实施沙箱系统以降低高成本停机风险的投资回报率就一目了然了。

2. 我们每个月执行多少次维护活动？

很简单：频率等于风险敞口。风险敞口等于额外成本。如果您每周都部署更新、补丁或配置更改，那么一年下来您就相当于掷骰子 52 次。回顾问题 1：由于补丁更新失败导致的停机一小时会给组织造成多少损失？现在，将这个损失乘以您的维护频率。

正如SIOS的副软件工程师Tristan Allen提醒客户的那样，一个与生产环境完全相同的沙箱提供了一个宝贵的环境，“可以在其中对新功能、配置变更和补丁进行全面测试。除了功能测试之外，QA环境还允许进行流程验证、性能基准测试、负载测试和安全验证。这些对于识别瓶颈至关重要。”漏洞或者，在集成问题有机会影响最终用户或损害您的环境之前就将其解决。”

发布和维护更新的速度加快，使得安全保障机制变得尤为必要。

3. 我们对部署到生产环境有多大信心？

每次更新到生产环境时，团队是否都提心吊胆？我们听过多少次“只是改了一行代码而已”这种说法？哪怕只是一行代码的偏差或空指针错误，都可能造成严重的宕机。您对团队确保新部署的软件包不存在编码错误、逻辑缺陷、架构问题、第三方兼容性问题或排序错误的能力有多大信心？

您的团队对您的健康状况有多大信心？生产环境如果您的生产环境不稳定，沙箱集群可以让您验证部署过程本身，从而显著降低紧急回滚的成本和压力，并可以预先验证修复方案。

4. 我们对直接在生产环境中应用安全补丁的风险承受能力如何？

安全补丁不容商榷，但有时它们会与现有库或配置冲突。直接在生产环境中应用内核补丁或数据库更新是一种冒险行为。

作为客户体验副总裁，我们直接与客户合作，回滚了直接应用于生产环境的内核更新。虽然该更新修复了一个问题，但却产生了意想不到的副作用，严重影响了存储层，导致死锁、应用程序崩溃和其他瓶颈。

如果您难以证明部署完整QA集群的必要性，不妨问问您的管理团队：我们是否愿意为了应用一个安全补丁而冒着影响关键业务应用程序的风险？沙箱环境允许您先在完全相同的环境中应用这些补丁，确保“修复”安全漏洞不会“破坏”业务。除了补丁之外，它还允许您部署新的应用程序和更新，以探索可能出现的任何安全漏洞或风险。

5. 数据损坏会对财务和运营造成哪些影响？

停机是暂时的，但数据丢失可能是永久性的。底层存储的不兼容变更、应用程序逻辑错误或设备驱动程序问题都可能悄无声息地损坏数据，而这种损坏往往不易察觉。您是否希望在生产环境中发现，备份工具的更新导致您无法再备份或恢复关键应用程序数据？

当你意识到生产环境中的错误时，可能已经造成数周的数据损坏。或者，你可能会遇到危机，发现备份数据无法在新更新的软件上恢复。沙箱环境允许你针对真实数据的副本运行数据完整性测试、数据迁移、模式更新、驱动程序更改，甚至复制软件场景，从而确保即使数据丢失或损坏，也发生在安全的环境中，而不是在向客户计费的环境中。

6. 我们能否承受第三方集成悄无声息地失败？

您的应用程序可能依赖于 API、第三方身份验证、第三方应用程序或其他形式的依赖项。这些依赖项在高负载下，尤其是在集群环境中，行为会有所不同。

不兼容的变更通常并非源于代码本身，而是源于代码与基础设施的交互方式。如果一项变更在开发人员的笔记本电脑上运行正常，但在分布到三个节点上时却失败了，那么这将导致业务中断。沙箱环境可以在这些“在我机器上运行正常”的错误影响到客户之前将其捕获。

7. 我们为真正的灾难恢复场景做好了多少准备？

大多数组织都有灾难恢复 (DR) 计划纸面上的计划固然美好，但未经测试的计划仅仅是假设。验证灾难恢复策略的唯一方法是执行它，模拟整个站点故障或数据损坏事件。如果没有沙箱集群，测试灾难恢复计划就只能针对生产环境。这会带来风险、成本、危险的物流以及停机时间。

如果没有沙箱集群，您必须故意将产生收益的系统离线，以验证它们能否重新上线。这需要网络、存储、数据库和应用团队之间进行大量的协调。在生产环境中进行这种操作的成本，就像在漏水的系统中安装一个不断运转的水表一样。

除了停机时间之外，在生产环境中测试灾难恢复场景本身就会带来风险和复杂性。风险在于需要处理实时数据，并确保严格遵守所有数据保护步骤。复杂性通常不在于故障转移本身，而在于恢复。一旦成功故障转移到备用站点或备份节点，将生产集群恢复到其原始状态（故障恢复）就是一个复杂且高风险的操作。

提醒管理层，沙盒环境的成本可以让团队在工作时间内模拟灾难性故障并执行完整的恢复流程，而不会影响用户。团队可以协作完善“运行手册”，安全地查找并解决流程缺陷，并进行充分的演练，这样，当真正的灾难来临时，团队就能执行一套精心设计的流程，而不是进行一次危险的首次尝试。

9. 我们如何引入新供应商并培训现有团队？

卓越的组织会为新团队成员、供应商和服务提供商制定完善的IT入职流程。这些组织深知，结构化的入职框架对新团队成员至关重要。他们重视并优先创建学习管理系统，并营造资源丰富的企业文化，帮助新员工了解他们将要管理、维护和更新的关键高可用性环境。他们也深谙持续学习的价值，并积极主动地保持团队技能的精湛。

如果没有与生产环境直接相同的沙箱系统，您的 IT 入职培训就必须利用您的生产集群。这意味着新毕业的大学生要学习如何运行……补丁管理在公司最重要的业务机器上，高可用性 (HA) 环境下的安全软件和应用程序更新至关重要。如果操作人员遇到运行手册中不清楚或恰巧缺失的环节，对生产力造成的损失以及对自身和企业声誉造成的损害风险可能是毁灭性的。

在倡导建立沙盒环境时，应强调持续引入供应商、合作伙伴和托管服务提供商的重要性，以及缺乏让他们了解业务或探索流程的环境所带来的风险。如果您的组织没有沙盒系统，不妨向领导层提出以下几个问题：

• 我们的新团队成员将去哪里了解他们将要管理、维护和更新的环境？
• 他们将如何保持技能与时俱进？
• 必要时，我们会使用哪些系统来妥善安排下一批团队成员的入职？

10. HA工具保险的费用是否比灾害造成的损失更便宜？

最后，让我们来谈谈最棘手的问题：工具和硬件的成本。

高可用性聚类软件相关的计算成本并非免费。然而，请将沙箱许可和基础设施的年度成本与一次重大停机、回滚或数据丢失事件的成本进行比较。几乎在所有情况下，预防成本都远低于补救成本。

沙盒环境是一项业务连续性投资

正如SIOS的副软件工程师Tristan Allen在他的博客中总结的那样：

质量保证和生产环境在确保系统平稳运行方面发挥着至关重要的作用。通过隔离环境、进行全面测试以及谨慎管理部署，IT 团队可以减少停机时间、保持高可用性，并实现无缝更新过渡。

如果您的管理团队难以理解完整沙盒环境的优势，不妨尝试向他们提出以下几个问题。通过这些问题，您可以将讨论从过于简单的成本问题引向更聚焦的对话，从而更好地理解沙盒环境的益处。业务连续性这使得管理层更容易批准该预算项目。沙盒集群并非奢侈品，而是企业降低风险的宝贵资产。

申请演示了解 SIOS 如何通过弹性高可用性和灾难恢复解决方案帮助您降低停机风险。

作者：Cassius Rhue，SIOS客户体验副总裁

经许可转载SIOS

继承 DataKeeper

继承 DataKeeper

继承 DataKeeper 环境意味着什么

继承的概念通常让人联想到资产从一个人传给另一个人。韦氏词典和其他词典对继承的定义是：

遗产是指逝者留下的资产、财产，有时还包括债务，通过遗嘱、信托或州无遗嘱继承法分配给受益人。遗产通常包括现金、房地产、股票、债券、个人物品（珠宝、汽车）和商业权益。

在IT领域，继承的概念带上了数字化的色彩。当系统管理员继承一个使用诸如以下工具的集群时：数据保管员他们处理的不是珠宝或房地产之类的有形资产，而是数字资源——想想配置、角色和关键容量资源。虽然我们希望这笔遗产是某人从公司退休或获得应有的晋升的结果，但我们还是祈祷它不是因为有人去了“天上的巨型数据中心”。（没错，幽默是IT专业人士的一种应对机制！）

所以，如果您有幸获得一个现有的 1×1 集群，其中包含 SQL Server 角色和相关的 DataKeeper 卷资源，那么您该从哪里开始呢？您应该采取哪些步骤来确保顺利完成入职和知识转移过程？

为了帮助指导这一过渡，以下是一些你应该问自己或你的管理团队的关键问题：

账户管理问题

客户经理详情

• 目前负责该账户的客户经理是谁？
  • 他们的联系方式是什么（电子邮件、电话等）？

许可信息

• 您的许可协议、合同和续签情况如何？
• 有哪些即将到期或需要续期的许可证需要注意？
• 我可以在哪里访问许可门户？我是否拥有必要的凭证？

DataKeeper 管理问题

了解环境

• 评估现有基础设施，包括Windows Server故障转移群集设置、服务器、存储等。
• DataKeeper目前正在保护哪些工作负载和应用程序？

配置和管理

• 熟悉DataKeeper配置。
  • 目前使用的异步和同步镜像类型有哪些？
  • 集群节点是如何设置的？
  • 涉及哪些存储措施？

维护和软件更新

• 如何及时了解 DataKeeper 的新版本、补丁和更新？

测试故障转移和恢复

• 偶尔测试故障转移，以确保高可用性和灾难恢复配置按预期工作。
• 发生灾难时，镜像数据是否一致且可恢复？

了解资源所有权和依赖关系

一旦你尽可能多地了解了你的遗产，下一步就是开始照管你所继承的财产，正如上图所示。当你“继承”了某项财产的所有权时，SQL Server 集群因此，识别并与所有受集群管理影响的跨职能团队进行沟通至关重要。由于涉及的领域众多，以下是一些需要重点关注的关键领域：

SQL Server 或应用程序团队

• 主动接收有关 SQL Server 名称或实例任何计划更改的通知
• 获悉可能影响集群性能的大型 SQL 插入或操作
• 请提供数据库文件、备份和快照的具体位置信息。

网络团队

• 沟通将 SQL 角色或相关资源迁移到不同网络的计划。
• 分享有关新 IP 地址或其他可能影响集群运行的网络相关变更的信息

存储团队

• 对于这些，在更改源卷和目标卷（例如，调整大小、格式化或添加分区）时要谨慎，因为这可能会对 DataKeeper 复制产生影响。
• 现有镜像服务器的带宽是否足够？
  • 您能否与网络团队合作，确保带宽充足，并与其他应用程序隔离以避免瓶颈？

为什么运行手册在 DataKeeper 环境中如此重要：

运行手册是确保系统平稳运行的关键组成部分，为使用 DataKeeper 的环境、集群管理员及相关技术提供了有效的解决方案。理想情况下，一份精心编写的运行手册应该是一份“动态文档”，随着时间的推移不断更新，反映基础设施、工作流程和最佳实践的变化。如果之前的管理员已经尽职尽责地做好了准备工作，那么您的运行手册应该全面涵盖以下方面：

• 故障/修复：解决已知问题，这些问题可能出现在“堆栈”中的任何位置，例如，从物理层一直到应用层。
• 工作流程：部署软件和管理日常集群操作
• 维护：怎么样补丁管理执行数据库备份等操作
• 供应商支持：如何到达 SIOS微软、AWS 和其他提供商
  • 最重要的是，何时“主动联系”他们？

继承 DataKeeper 的关键要点

这篇博客重点讨论了在进行此类转型时需要考虑的几个重要方面，包括账户管理、资源所有权、跨职能协作以及运行手册的价值。**然而，需要注意的是，这些只是众多考量因素中的一部分，还有一些因素可能超出本文的讨论范围。每个环境都是独一无二的，成功的集群管理需要对具体的基础设施、依赖关系和工作流程有透彻的了解。

好好享受你的“遗产”吧……

不要一次性把钱全部花光……

申请演示了解 SIOS DataKeeper 如何帮助简化集群管理并支持高可用性。

作者：Greg Tucker，SIOS 高级产品支持工程师

经许可转载SIOS