在多个团队工作的过程中,我遇到了多个基础设施经理,他们制定了每周重新启动服务器的政策。作为一名开发人员,我一直反对该政策 - 似乎这是一种解决软件错误和硬件不稳定问题的黑客行为,而不是纠正它们。

人们对这项政策的看法、积极和消极的观点是什么?

有帮助吗?

解决方案

如果您偶尔重新启动服务器,则可以确定它们会恢复正常。虽然每周听起来有点大材小用,但我在正常运行时间较长的 Linux 机器上见过这个问题。

有人懒得设置一个关键服务在启动时自动启动。或者出现的服务顺序是错误的。或者有人升级了库、添加/删除了软件等。并且可执行文件不再工作(它是使用旧库启动的,并继续使用它们;现在它出现动态链接器错误)。或者事实证明服务 A 依赖于服务 B,而服务 B 又依赖于服务 A (oops)。

在某个时刻,当你 至少 如果愿意,您将重新启动。科洛会向你断电;服务器的电源将出现故障;有人会在错误的服务器上拉线/按下重置按钮;ETC。现在,当您最不能承受停机时间时,您该死的服务器将无法恢复。

就像软件一样,系统配置也需要测试。您需要多久进行一次此测试取决于您的盒子的管理方式。

其他提示

这是一个愚蠢的政策。

原因如下:

  • 如果您需要每周重新启动服务器(并且以某种方式增加了基础设施的稳定性),那么您就掩盖了服务器或其软件的真正问题。内存泄漏?一个坏司机?解决这些问题的方法是 使固定 他们,而不是用懒惰的政策来掩盖他们。

  • 服务器经常会重新启动以进行更新,至少在 Windows 世界中是这样。无论如何,都会重新启动以进行关键内核更新。

  • 数据库服务器在 RAM 中缓存大量信息。当您重新启动服务器时,该缓存会变空并且非常冷。假设您有典型的使用模式,冷的空缓存将导致用户在重新启动后尝试查询时性能降低。它 可能 还会增加执行某些类型的维护(例如备份)所需的时间,因为可能需要更多地访问磁盘。

  • 你的服务器宕机了!由于您的服务器关闭了一段非零的时间,因此您的备份和其他事情的维护窗口会缩短。您最终可能还必须告诉用户您将需要停机,具体取决于您的系统架构。

  • 假设您有某种用于警报的通知系统,您必须将其配置为忽略停机时间窗口。这可以掩盖服务器重新启动时发生的问题,并增加您需要在服务器上执行的配置量。

话虽这么说,重新启动有时是有益的,作为您不一定完全控制的资源(旧的供应商编写的软件、供应商明确规定的“黑匣子”设备等)的最后手段。但这应该根据具体情况来处理,而不是采取幼稚的一揽子政策。

很抱歉掸掉旧线程的灰尘。

我认为每个人都没有抓住重点,尤其是顽固的“重启”?我宁愿卖我的准将!尼克斯管理员。

重点是应该安排每周一次的窗口。并不意味着必须使用它,事实上,人们更倾向于不使用它,因为它不可避免地会在早上的某个被遗弃的时间出现。

但如果它在那里,您就可以使用它。

就我个人而言,我认为每季度重新启动是一个非常好的主意 - 它可以让您提前了解问题(硬件和软件),并且正如其他最具前瞻性的发帖者所指出的那样,让您意识到阻碍顺利启动的变化,这些变化只有在重启后变得明显。与其说是停电4小时后,再花2小时才把盒子拿出来,那就真的很尴尬了……

还有其他好处..

  • 它让管理层习惯了重新启动,并且当您确实需要重新启动时(例如,物理地移动它)。如果你从不重新启动一个盒子,当你说它需要在 4 年后重新启动并且没有停机时间时,你的经理会非常紧张。

  • 您自己已经习惯了重新启动,并且知道离线时可能会出现什么问题。

  • 您知道重新启动需要多长时间,因此当它重新启动并且比平常多花 10 分钟时,您将直接进入日志。

  • 如果你明天被公交车撞倒,这里有关于重启时会发生什么的当前(不是 4 年前的)文档(假设你是一个很好的管理员并把事情写下来)

  • 每季度重新启动 30 分钟完全符合 99.9% 的正常运行时间 SLA。

  • 最后,它清除了众所周知的蜘蛛网。

回答一些反对定期重启的问题。

  • 关于掩盖不良驱动程序\内存泄漏等的内容很搞笑。除非重新启动服务器,否则您如何知道这是内存泄漏\驱动程序损坏?不仅如此,如果您无法在计划的停机时间内修复它怎么办?如果您有每周安排的窗口,那没问题!你下周再试一次......

  • 通知系统 - 如果您有计划窗口,则可以设置计划例外。如果您的软件\脚本不能做到这一点,那么我建议使用现代软件\更好的脚本编写。

  • 至于计划的异常窗口隐藏“在计划的异常窗口期间发生”的问题,这简直是可笑的。如果您查看其他服务器统计信息,它们将很快显示此问题。

当然,不建议采用一揽子政策,您应该制定例外标准(例如磁盘空间超过一定大小等)

话虽如此,底线只是因为你的服务器不应该需要重新启动,认为你不应该重新启动它是非常天真的......

编辑:

我不确定我是否说得足够清楚,但重新启动不应该用来解决问题。该窗口应该每周一次,以便您反复尝试解决问题,而不是“忍受它”。

系统管理员将重新启动作为处理服务器问题的一种方法是很糟糕的。你什么也学不到,而且浪费了人们的宝贵时间,并且(正确地)降低了管理层对你的好感。

我的观点是

  • 如果没有可接受的、预定的每周维护窗口,就很难确保解决问题。
  • 通过每周的窗口,您有一个持续的机会来正确地解决问题,并避免在尽可能多的不同服务器上有六种偷工减料的解决方法的情况。

回答我自己的问题:我从策略中看到的一个好处是它应用于服务器集群,并且进程从一个节点故障转移到另一个节点。这样,所有节点都会不断测试正确的软件安装。

我们的服务器都在运行Linux服务器,我们不会重启并且没有任何问题。我同意这是一个充其量的黑客攻击,我也认为它可能与人们在支持Windows问题时常常给出的第一个响应有关:“你重启了计算机吗?”

现在,为什么它可能是有益的,你可能有应用程序进入一个奇怪的状态或有重启将解决的内存泄漏。

对我来说,一个很大的负面影响是你必须安排服务器的每周停机时间。对于一些不是问题的人,对其他人来说这是个大问题。

显然,如果问题的根源无法及时修复,则必须解决。如果可行的话,安排重新启动来修复它是一种简单的方法来保存业务。

当然,它会在精神上受到伤害而且不应该被需要,最好是反对这样的解决方案,特别是如果一个人控制有问题的软件,或者有能力抨击生产者修复或简单代替它。但如果没有..?

我记得为Citrix服务器场中的服务器执行此操作,最后每天晚上重新启动它们,使用半复杂的脚本等待用户注销,将登录锁定到特定服务器,然后重新启动免费服务器。原因是一个旧的16位4GL客户端应用程序,我们根本无法摆脱在几天的正常运行时间之后切断整体用户响应能力。

我同意,但大多数情况似乎是基于不够聪明,无法找出原因并加以解决 - 并非每个人都像我们所希望的那样精通维护或激励。

这真的是一个黑客,但它可能是最有效的黑客。这是一个80:20类型的问题,你可以用20%的努力解决80%的问题。如果您能够在停机时间或停机时间内付出的代价比实际修复根本原因要少,那么这是一个很好的解决方案。我个人不喜欢它,但这只是因为它不是一个干净的解决方案。

另一种考虑的可能性是,在某些环境中,例如一天24小时营业的零售商店,“商店关闭”等。事件,以便可以更新,备份等服务器

即使服务器需要“24x7”运行,他们每天至少都会离线几天。

这有效地使服务器每天都重新启动,即使商店在发生时仍在运行。

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top