“我们可以将现有的生产EL5服务器升级到EL6吗？”
两个环境完全不同的客户的要求听起来很简单，这提示我通常的最佳做法回答是“是，但是将需要对所有系统进行协调重建”。
由于停机和资源原因，两个客户都认为完全重建系统是不可接受的选择……当被问到为什么有必要时要完全重新安装系统，除了“就是这样...”之外，我没有一个很好的答案。
我没有试图引起有关配置管理的响应（“伪造一切”）并不总是适用）或客户应该如何更好地计划。这是一个真实的环境示例，该环境中的生产能力已经增长并蓬勃发展，但是没有清晰的方法可以迁移到其操作系统的下一版本。
环境A：
非营利组织，拥有40台Red Hat Enterprise Linux 5.4和5.5网站，数据库服务器和邮件服务器，并运行Java Web应用程序堆栈，软件负载平衡器和Postgres数据库。所有系统都在两个位于不同位置的VMWare vSphere群集上虚拟化，每个群集都具有HA，DRS等。
环境B：
具有200个CentOS 5.x系统的高频金融交易公司在多个托管场所运行生产交易业务，支持内部开发和后台功能。交易服务器在裸机商品服务器硬件上运行。它们具有大量的
sysctl.conf，rtctl，中断绑定和驱动程序调整，以降低消息传递延迟。有些具有自定义和/或实时内核。开发人员工作站也正在运行类似版本的CentOS。 在两种情况下，环境都按原样运行。升级的愿望来自对EL6中可用的更新应用程序或功能的需求。
对于非营利性公司而言，它与Apache，内核和使开发人员感到满意的某些东西联系在一起。
在贸易公司中，它是对内核，网络堆栈和GLIBC的一些增强，这将使开发人员感到满意。
这两种东西都不能在不大幅改变操作系统的情况下轻松打包或更新。
作为系统工程师，我很欣赏Red Hat建议在移动时进行全面重建在主要版本之间。一个干净的开始迫使您重构和关注配置过程。
由于对客户的业务需求敏感，我想知道为什么这需要这么繁重的任务。 RPM打包系统具有处理就地升级的能力，但它却为您提供了一些小细节：
/boot需要更多空间，新的默认文件系统，RPM可能会破坏升级中的版本，不建议使用和已淘汰的软件包... 这里的答案是什么？其他发行版（基于.deb的文件，Arch和Gentoo）似乎具有此功能或更好的方法。假设我们发现以正确的方式完成此任务所需的停机时间：
当EL7释放并稳定下来时，这些客户应该怎么做才能避免相同的问题？
还是这种情况下，人们需要每隔几年就辞职以进行全面重建？
随着企业Linux的发展，这种情况似乎变得越来越糟了……或者我只是在想这件事？
这会阻止任何人使用Red Hat和派生操作系统吗？
我认为存在配置管理角度，但是我看到的大多数Puppet安装都无法很好地转换为具有高度定制的应用程序服务器的环境（环境B可能有一个服务器，其
ifconfig输出看起来像这样）。我很高兴听到关于如何使用配置管理来帮助组织克服RHEL主要版本冲突的建议。#1 楼
（作者注：该答案涉及RHEL 6和更低版本。RHEL7现在具有从RHEL 6完全受支持的升级路径，其详细信息在末尾。）到首先，我应注意有两种方法可以进行就地升级：
放入安装DVD（或通过iLO / iDRAC使用DVD映像），然后从中启动并选择升级，例如
linux upgradeany。手动更新
redhat-release RPM，运行yum distro-sync（这有点过分简化），然后重新启动。方法1仅不受支持。方法2适用于真正的牛仔。除了推荐的全新安装，我还完成了这两项操作...
我需要支持吗？
支持在我们的世界中有两个互补的含义。首先是产品具有给定的功能（例如“ Postfix支持SMTP”）。第二个是供应商将与您讨论此事。从上下文中并不总是可以清楚地看出定义的含义。
要完成一项任务，显然您需要第一方面的支持。供应商支持的出现是为了帮助您解决问题并就需要存在或改进哪些功能向供应商提供反馈。当许多站点拥有内部专家知识来解决可能出现的任何问题时，他们会为供应商提供支持，这比供应商能够更快，甚至更便宜地付出了很多。是否购买供应商支持最终将是您要做出的商业决定（或建议管理）。
为什么不就地升级？
这是Red Hat所说的：
Red Hat不支持在Red Hat Enterprise Linux的任何主要版本之间进行就地升级。主版本由整数版本更改表示。例如，红帽企业版Linux 5和红帽企业版Linux 6都是红帽企业版Linux的主要版本。
跨主要版本的就地升级不会保留所有系统设置，服务或自定义配置。因此，在从一个主要版本升级到另一个主要版本时，Red Hat强烈建议全新安装。
他们进一步警告：
但是，请注意以下内容选择升级系统之前的限制：
由于各种配置文件格式或布局的更改，单个软件包配置文件在执行升级后可能会或可能无法工作。
如果您已经安装了Red Hat的分层产品之一（例如Cluster Suite），则在Red Hat Enterprise Linux升级完成后，可能需要手动升级。
在执行以下操作后，第三方或ISV应用程序可能无法正常工作升级。
当然，他们然后描述了如何通过方法1进行就地升级，以防万一您确实想要这样做。该功能存在，并且Red Hat投入了开发时间，因此该功能受支持。但是，如果出现问题，Red Hat会告诉您重新安装。他们不会为升级导致的故障提供供应商支持。
记录在案，我从未真正就地升级过RHEL / CentOS或Fedora的问题我无法解决自己的系统。典型的问题来自重命名的软件包，第三方存储库以及软件包的i386和x86_64体系结构之间偶尔的版本不匹配。我认为安装程序比
yum的处理能力要好一些。我应该如何升级？
我通常警告人们应该计划每3-4年进行一次维护，以将RHEL系统从一个主要版本更新到另一个主要版本。虽然升级通常进行得很顺利，但意外总会发生。
对于我的两个环境，我都希望就地升级会起作用，尽管我强烈建议您首先进行全面测试。 P2V服务器的代表性示例，并在虚拟系统上进行就地升级，以查看您将遇到的问题。然后，您可以根据对将要发生的情况的更好了解来计划实际的生产升级。
对于像此处这样的大型部署，请考虑使用Limoncelli的“一对多”方法。升级一台计算机，看看会发生什么问题，解决它们，然后在升级一小批计算机时使用已学到的经验教训，重复已学到的东西，然后当您认为自己已经解决了所有问题时，就进行大批量升级。 />
在这样的时候，我还建议您仔细研究一下您的应用程序部署过程。如果自动化程度不够高，您可以使用单个命令将其启动，并合理确定该应用程序将正确部署，那么开发人员可能需要着手进行此工作。有了这样的部署过程，可以更轻松地全新安装EL的较新版本，然后在其上进行部署。
切换发行版会有所帮助吗？
基于Debian的发行版确实具有受支持的就地升级方法，并且大多数情况下都可以运行，但是无法避免出现问题。例如，人们通过支持的方法从Ubuntu 10.04 LTS升级到12.04 LTS时遇到了很多麻烦。尚不清楚Debian或Canonical是否在“支持”此功能上投入足够的开发时间，即确保它可以正常工作。如果您希望有人牵着您，实际上您仍然必须为该发行版购买供应商支持。因此，我怀疑您从切换到这样的发行版是否会获益匪浅。
切换到Gentoo或Arch这样的滚动发行版可能会有所帮助。但是，这也不能使您不受问题困扰。这仅意味着您必须在服务器的整个生命周期内（例如，无论何时您或开发人员决定在系统上进行某些更新）连续处理升级问题，而不是在计划周到的发行升级时一次全部处理。您也没有供应商提供支持。
未来的前景如何？
Fedora项目正在开发一种改进就地升级的工具。他们有一个名为
preupgrade的工具，该工具已废弃，取而代之的是从Fedora 18开始的一个名为fedup的新工具。此工具已添加到RHEL7中，现在就地升级已获得全面支持，至少从RHEL 6到RHEL 7。我可以说，尽管fedup仍然存在一些缺陷，但它正逐渐成为一个非常有用的工具。CentOS也在尝试滚动发布类型的存储库，但它仅在次要版本之间适用（例如6.3-6.4）。
评论
新的Fedora升级工具称为fedup。对于大型升级，三到四年对我来说听起来也很激进，必须安装，我认为RHEL的10年以上生命周期将持续更多，因此，我鼓励进行更常规的次要升级。
–Dominic Cleal
2012年11月15日在18:38
对于持续需要新功能的人来说，3-4年的时间太长了。
–迈克尔·汉普顿
2012年11月15日18:39
简单的东西，例如PHP，Apache，内核修订版和GLIBC ...人们倾向于更频繁地进行这些更改。
–ewwhite
2012年11月15日19:13
Debian / Ubuntu的升级过程并不完美，但是它是首选的升级机制，而Red Hat没有官方支持的升级机制这一事实在我看来是很重要的。
– Paul Gear
2012年11月20日20:52
是否就地升级并不像显然存在的那样重要，而是各个供应商是否为其提供支持。
–迈克尔·汉普顿
2012年11月21日19:27
#2 楼
我对最后一段的看法是：我认为存在配置管理角度，但是我看到的大多数Puppet安装都无法很好地转换为具有高度定制的应用程序服务器的环境（环境B可以具有单个服务器，其ifconfig输出如下所示）。我很高兴听到关于如何使用配置管理来帮助组织克服RHEL主要版本冲突的建议。我认为配置管理系统的真正价值在于，特别是在环境B的上下文中，它们提供了独立于运行服务的服务器来构建服务的工具。如果不使用CMS创建现有服务，那么它可能对重新创建服务没有太大帮助。
我知道这并不能解决您眼前的问题，但对我而言源于组织在服务器而非服务方面的思考。在以服务为中心的思维中，只要服务继续运行，就无需维护单个服务器的个性。如果以有纪律的方式使用CMS构建整个服务，则将服务迁移到另一个系统应该相对简单，因为所有机器的个性都将由CMS构建。
P.S.我不确定在这种情况下ifconfig输出的意义是什么-它是由配置文件和一些脚本生成的（否则它将在启动时不存在），并且可以在需要时由CMS管理。 br />
评论
从一般意义上来说，您对服务与服务器是正确的。环境B具有一些与上游提供程序接口的专用服务器硬件（10GbE NIC，卸载库）。没有停机就无法实现负载平衡或轻松移动。一个非财务示例将是诸如服务器之类的服务器作为某些涉及的生产机器的控制器。特殊情况下，可能带有专用的PCIe接口卡。服务器唯一的一次性设置。在Puppet中，您是否会说：“这是该主机/角色的配置”并使用它？
–ewwhite
2012年11月20日在22:51
同意，有些事情不适合一般情况，特别是如果您的环境具有特定的硬件要求。对于木偶，尽可能多地扮演角色是很有意义的。但是最后它必须起作用，因此，如果某种不太优雅的方法可以使它起作用，那么我就忍受它的优雅。在很多时候，我们必须忍受不雅的事物，仅仅是因为我们没有时间使它们“正确”。
– Paul Gear
2012年11月21日23:52
评论
当我看到作者的名字和名字时，我打算将其标记为“非建设性的”，出于尊重，我不会这样做。我仍然认为这是一个愚蠢的问题，因为答案是“红帽认为应该如此”。通过DVD引导完全可以进行4-> 5升级，并且有使用yum将其升级到实时操作系统的过程，这在大多数情况下对我有用。我唯一的希望是，RH从付费客户那里获得了巨大的成功，因为他们决定不支持升级路径5-> 6，并将重新考虑6-> 7。就是说，您确实知道通过使用upgradeany引导时间参数从C5-> C6通过DVD引导存在一个不受支持的有效升级路径。我已经对其进行了两次测试，一次是在干净的C5安装上可以正常工作。曾经在（古老的C4升级过的）笨拙的旧版（一个测试版）上安装，但安装失败了。
我非常了解upgradeany选项，并且肯定已经使用实时RPM方法（更改存储库，*-release文件等）来强制安装。但是，本周来自客户的问题使我更多地考虑了特定版本如何使环境变得根深蒂固，并且没有出路。