“我们可以将现有的生产EL5服务器升级到EL6吗？”

来自两个完全不同环境的客户的简单要求使我通常的最佳实践回答是“是，但是这将要求协调重建所有系统 ”。

出于停机和资源原因，两个客户都认为完全重建他们的系统是不可接受的选择……当被问到为什么必须完全重新安装系统时，我没有一个很好的答案，“就是这样...”

我不是要引起有关配置管理（“伪造一切 ” 并不总是适用）或客户端应该如何计划更好的响应。这是一个现实的环境示例，该环境中的生产能力已经增长并蓬勃发展，但是没有一个干净的方法可以迁移到其下一代操作系统。

环境A：
具有40个Red Hat Enterprise Linux 5.4和5.5 Web，数据库服务器和邮件服务器，运行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释放并稳定下来时，这些客户应该怎么做才能避免相同的问题？
• 还是这种情况下，人们需要每几年辞职以进行全面重建？
• 随着Enterprise Linux的发展，这种情况似乎变得更糟了。
• 这是否阻止了任何人使用Red Hat和派生操作系统？

我想这里是配置管理的角度，但是我看到的大多数Puppet安装都无法很好地转换为具有高度定制的应用程序服务器的环境（环境B可能只有一个服务器，其ifconfig输出如下所示）。我会很感兴趣地听到关于如何使用配置管理来帮助组织克服RHEL主要版本冲突的建议。

（作者注：该答案涉及RHEL 6和更低版本。RHEL7现在具有从RHEL 6完全受支持的升级路径，其详细信息在结尾。）

首先，我应注意有两种方式进行就地升级：

1. 放入安装DVD（或通过iLO / iDRAC使用DVD映像），从中启动并选择Upgrade，例如linux upgradeany。
2. redhat-release手动更新RPM，运行yum distro-sync（略微简化）并重新启动。

方法1仅不受支持。方法2适用于真正的牛仔。除了推荐的全新安装，我还完成了这两项...

我需要支持吗？

支持在我们的世界中具有两个互补的含义。首先是产品具有给定的功能（例如“ Postfix支持SMTP”）。第二是供应商将与您讨论此事。从上下文出发，并不总是清楚是什么意思。

要完成一项任务，您显然需要第一方面的支持。供应商支持的出现是为了帮助您解决问题并就需要存在或改进哪些功能向供应商提供反馈。当许多站点拥有内部专家知识来解决可能出现的任何问题时，他们会为供应商提供支持，这比供应商可以更快，甚至更便宜。是否购买供应商支持最终将是您必须做出的业务决定（或向管理层提出建议）。

为什么不就地升级？

这就是Red Hat所说的：

红帽不支持在任何主要版本的红帽企业Linux之间进行就地升级。主版本由整数版本更改表示。例如，Red Hat Enterprise Linux 5和Red Hat Enterprise Linux 6都是Red Hat Enterprise 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项目正在开发一种工具，以改善就地升级。他们使用了一个名为Fedora 18的preupgrade废弃工具，取而代之的是一个名为fedup的新工具。这已添加到RHEL7中，现在就地升级已完全支持，至少从RHEL 6 升级到RHEL 7。根据我自己的经验，我可以说虽然fedup仍然存在一些缺陷，但它正在逐渐成为一个非常有用的工具。

CentOS也正在试验滚动发布类型的存储库，但它仅适用于次要版本（例如6.3-6.4）之间。

我对你的最后一段：

我想这里是配置管理的角度，但是我看到的大多数Puppet安装都无法很好地转换为具有高度定制的应用程序服务器的环境（环境B可能只有一个服务器，其ifconfig输出看起来像这样）。我会很感兴趣地听到关于如何使用配置管理来帮助组织克服RHEL主要版本冲突的建议。

我认为配置管理系统的真正价值，尤其是在环境B的环境中，是它们提供了独立于运行服务的服务器来构建服务的工具。如果不使用CMS创建现有服务，则在重新创建服务方面可能不会有很大帮助。

我知道这并不能解决您眼前的问题，但对我而言，这源于组织在服务器而非服务方面的思考。在以服务为中心的思维中，只要服务继续运行，就不需要维护单个服务器的个性。如果以有纪律的方式使用CMS构建整个服务，则将服务迁移到另一个系统应该相对简单，因为所有机器的个性都将由CMS构建。

PS：我不确定在这种情况下ifconfig输出的意义是什么-它是由配置文件和一些脚本生成的（否则它将在启动时不存在），并且可以在需要时由CMS管理。