为什么在 Red Hat 和 CentOS 的主要版本之间升级如此困难？

Question

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

来自环境完全不同的两个客户的一个听起来简单的请求促使我通常的最佳实践回答“是的，但它需要协调重建您的所有系统”......

两位客户都认为，出于停机时间和资源原因，完全重建他们的系统是不可接受的选择... ……”

我不是要引出关于配置管理的回应（“Puppetize一切”并不总是适用）或客户应该如何更好地计划。这是环境在生产能力中不断发展壮大的一个真实示例，但没有看到迁移到其操作系统下一个版本的干净路径。

环境 A：
非营利组织，拥有40 个 Red Hat Enterprise Linux 5.4 和 5.5 Web、数据库服务器和邮件服务器，运行 Java Web 应用程序堆栈、软件负载平衡器和 Postgres 数据库。所有系统都在不同位置的两个 VMWare vSphere 集群上进行虚拟化，每个集群都具有 HA、DRS 等。

环境 B：
高频金融交易公司，在多个托管设施中配备200 x CentOS 5.x系统，运行生产交易业务，支持内部开发和后台功能。交易服务器在裸机商品服务器硬件上运行。他们有许多sysctl.conf，rtctl，中断到位约束力和驱动程序的调整，以降低消息传送等待时间。有些具有自定义和/或实时内核。开发人员工作站也运行类似版本的 CentOS。

---

在这两种情况下，环境都按原样运行良好。升级的愿望来自对 EL6 中可用的更新应用程序或功能的需求。

• 对于非盈利公司来说，它与 Apache、内核和一些会让开发人员感到高兴的东西有关。
• 在贸易公司，它是关于内核、网络堆栈和 GLIBC 的一些增强，这将使开发人员感到高兴。

两者都不能在不彻底改变操作系统的情况下轻松打包或更新。

作为系统工程师，我很欣赏红帽建议在主要版本之间移动时进行完全重建。一个干净的开始迫使你重构并在此过程中注意配置。

对客户的业务需求很敏感，我想知道为什么这需要如此繁重的任务。RPM 打包系统不仅能够处理就地升级，但它是让您/boot受益的小细节：需要更多空间、新的默认文件系统、RPM 可能会在升级过程中中断、已弃用和已失效的软件包......

这里的答案是什么？其他发行版（基于 .deb、Arch 和 Gentoo）似乎具有这种能力或更好的途径。假设我们找到了以正确方式完成此任务的停机时间：

• EL7 发布稳定后，这些客户端应该怎么做才能避免同样的问题呢？
• 或者这是人们每隔几年就需要辞职以进行全面重建的情况？
• 随着 Enterprise Linux 的发展，情况似乎变得更糟了……还是我只是在想象？
• 这是否阻止了任何人使用 Red Hat 和衍生操作系统？

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

Answer 1

（作者注：此答案针对 RHEL 6 及之前的版本。RHEL 7 现在具有完全支持的 RHEL 6 升级路径，其详细信息在最后。）

首先，我应该注意到有两种方法可以进行就地升级：

1. 放入安装 DVD（或通过 iLO/iDRAC 使用 DVD 映像），从中引导并选择升级，例如linux upgradeany。
2. redhat-release手动更新RPM，运行yum distro-sync（这有点过于简单了）并重新启动。

方法 1 只是不受支持。方法 2 适用于真正的牛仔。除了推荐的全新安装之外，我已经完成了这两个......

我需要支持吗？

支持在我们的世界中有两个互补的含义。第一个是产品具有给定的功能（例如“Postfix 支持 SMTP”）。第二个是供应商会和你谈谈。从上下文来看，这意味着哪个定义并不总是很清楚。

要完成一项任务，您显然需要第一种意义上的支持。供应商支持的作用在于帮助您解决问题，并就需要存在或改进的功能向供应商提供反馈。当许多站点拥有内部专业知识来解决可能出现的任何问题时，他们会为供应商支持支付一大笔费用，而且速度比供应商更快，甚至更便宜。是否购买供应商支持最终是您必须做出的业务决策（或建议管理层）。

为什么不进行就地升级？

Red Hat是这样说的：

红帽不支持在红帽企业 Linux 的任何主要版本之间进行就地升级。主要版本由整数版本更改表示。例如，红帽企业 Linux 5 和红帽企业 Linux 6 都是红帽企业 Linux 的主要版本。

跨主要版本的就地升级不会保留所有系统设置、服务或自定义配置。因此，红帽强烈建议在从一个主要版本升级到另一个主要版本时进行全新安装。

他们进一步警告：

但是，在选择升级系统之前，请注意以下限制：

• 由于各种配置文件格式或布局的变化，单个包配置文件在执行升级后可能会或可能不会工作。
• 如果您安装了 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）。

Answer 2

我对你最后一段的看法：

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

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

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

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