通常,对Ubuntu的软件更新需要重新启动(这可能会带来诸如停机等副作用)。
我看到Ubuntu具有https://www.ubuntu.com/livepatch,它允许内核更新而无需重新启动,但是,这是一项付费服务。也有ksplice。
是否存在Linux发行版/进程,其中升级/修补程序从不需要重启?
(我知道设置高可用性(HA)服务器和使用一次性服务器是最佳做法-因此,我不是在问要保持服务状态,而是在实际服务器上。)
通常,对Ubuntu的软件更新需要重新启动(这可能会带来诸如停机等副作用)。
我看到Ubuntu具有https://www.ubuntu.com/livepatch,它允许内核更新而无需重新启动,但是,这是一项付费服务。也有ksplice。
是否存在Linux发行版/进程,其中升级/修补程序从不需要重启?
(我知道设置高可用性(HA)服务器和使用一次性服务器是最佳做法-因此,我不是在问要保持服务状态,而是在实际服务器上。)
Answers:
对于您的问题,“是否存在Linux发行版/进程中的升级/修补程序永远不需要重新启动?”,我一无所知,而且我非常怀疑是否有任何真正不需要重新启动的程序。除了迈克尔·汉普顿(Michael Hampton)的评论为何为何实时补丁在任何地方都不是开箱即用的体验之外,实时补丁也无法获得与重新启动相同的结果。
一个说明这一点的轶事:我最近调查了一个问题,其中一个特定的实用程序已开始在大量机器上进行段故障处理。我尝试查看它用来查看最近升级的任何东西是否损坏了共享库;ldd表示它不是可执行文件(即使当我将同一个二进制文件放到笔记本电脑上时,ldd仍可以看到共享库的依赖关系)。我尝试在gdb中逐步解决问题;在到达第一条指令之前就断断续续。
查看故障发生的时间,我发现最近已应用了Ksplice补丁。我退出了补丁,二进制文件没有进行分段错误,然后将其重新添加,然后再次开始分段错误。重新启动到等效补丁程序的内核上运行良好。事实证明,这是一个32位支持的补丁,Ksplice的人们并未正确应用。值得称赞的是,他们在几个小时内发布了一个固定补丁,该补丁已恢复正常运行,无需干预。
另一个例子:Meltdown / Spectre补丁是如此具有侵入性,以至于Ubuntu内核团队认为实时补丁是不切实际的,并要求人们在重新接收实时补丁之前将系统重新启动到固定内核中。
我们在工作中运行着大量的物理和虚拟服务器,其中包含大量的Ksplice和Canonical Livepatch系统。它们都比许多其他软件可靠得多,但是我仍然希望我们的服务采用易于重启的体系结构设计,而不是依赖于内核实时补丁。
使服务高度可用与使单个计算机高度可用之间存在重要区别。
在大多数情况下,目标是使服务具有更高的可用性,而单个计算机的可用性只是实现该目标的一种手段。但是,通过提高单个计算机的可用性可以达到目标的程度是有限的。
即使由于需要更新软件而可以消除所有停机时间,单个计算机仍将无法100%可用。因此,要将服务的可用性提高到单个计算机的可用性之上,您必须在更高级别上设计冗余。问题的最后一句话表明,至少在原则上您知道这一点。
如果您确实设计了一种服务,使其比单个计算机所能提供的可用性更高,那么就不再有压力实现单个计算机的高可用性。因此,对于高可用性服务,无需避免重新启动。取而代之的是,您可以牺牲某些机器的可靠性来节省成本,这些成本可以用于其他方面,从而在可靠性方面获得更高的收益。
一旦将高级系统设计为在单个硬件组件失败的情况下可靠,内核的实时修补就会从优势转变为风险。
这是有风险的,因为实时修补的计算机和使用最新内核版本启动的计算机的行为之间可能存在细微的差异。这可能会引入潜在的错误,下次重启计算机时可能会导致中断。通过重新启动以获得干净的状态,可以将这种风险放大,这被视为减轻某些故障的一种方法。
有一天您可能会断电,重新启动计算机可能会有所帮助。但是,当您重新启动计算机时,潜在的错误会阻止您的计算机恢复到所需的状态,从而给您带来麻烦。实时修补不是发生这种潜在错误的唯一方式,它也可能是由于手动启用了一项平凡的服务而从未配置为在启动过程中启动,或者配置为启动得太早而导致这种潜在错误的发生由于不满意的依赖关系而无法出现。
出于这些原因,通过以足够慢的速度定期重新启动各个计算机,实际上可能更容易获得高可用性的服务,以便您可以检测到问题并在出现问题后暂停重新启动的顺序。