“我们可以将现有的生产 EL5 服务器升级到 EL6 吗？”
两个客户提出了一个看似简单的请求完全地不同的环境促使我按照惯例回答“是的，但需要协调重建所有系统“……”
两位客户都认为，由于停机和资源原因，完全重建系统是不可接受的选择......当被问到为什么需要完全重新安装系统时，我除了“就是这样的......”之外没有其他好的答案。
我并不是想引出关于配置管理的回应（“Puppetize一切“并不总是适用) 或客户应该如何更好地规划。这是一个真实的例子，环境在生产能力上已经发展壮大，但没有看到迁移到下一个版本的操作系统的清晰路径。
环境A：
非营利组织40 x Red Hat Enterprise Linux 5.4 和 5.5web、数据库服务器和邮件服务器，运行 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 及之前的版本。RHEL 7 现在具有从 RHEL 6 完全支持的升级路径，详细信息在最后。）
首先，我要指出的是两种方式进行就地升级：
- 放入安装 DVD（或通过 iLO/iDRAC 使用 DVD 映像），从中启动并选择升级，例如
linux upgradeany。 - 手动更新
redhat-releaseRPM，运行yum distro-sync（这有点过于简单）并重新启动。
方法 1 完全不受支持。方法 2 适用于 Real Cowboys。除了推荐的全新安装外，我还进行了这两种操作...
我需要支持吗？
支持在我们的世界中，有两个互补的含义。第一个是产品具有给定的功能（例如“Postfix 支持 SMTP”）。第二个是供应商会与您谈论它。从上下文来看，到底是指哪个定义并不总是很清楚。
要完成一项任务，您显然首先需要支持。供应商支持的作用是帮助您解决问题，并向供应商反馈哪些功能需要存在或改进。许多网站在拥有内部专业知识来解决可能出现的任何问题时会花大价钱购买供应商支持，而且比供应商更快、更便宜。是否购买供应商支持最终是您必须做出的业务决策（或向管理层提供建议）。
为什么不进行就地升级？
Red Hat 不支持 Red Hat Enterprise 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 项目正在开发一种改进就地升级的工具。他们有一个名为preupgrade被遗弃并替换为一个名为从 Fedora 18 开始的 fedup。这已添加到 RHEL7，现在就地升级得到全面支持， 至少从 RHEL 6 升级到 RHEL 7.根据我自己的经验，我可以说，虽然fedup仍有一些问题，它正在成为一种非常有用的工具。
CentOS 也在尝试滚动发布类型的存储库，但仅适用于小版本之间（例如 6.3-6.4）。
答案2
我对你最后一段的看法是：
我认为存在配置管理角度，但我看到的大多数 Puppet 安装都不能很好地转换为具有高度定制的应用程序服务器的环境（环境 B 可以有一个服务器，其 ifconfig 输出如下所示）。不过，我很想听听关于如何使用配置管理来帮助组织克服 RHEL 主要版本升级的建议。
我认为配置管理系统的真正价值（尤其是在环境 B 的背景下）在于它们提供了独立于运行该服务的服务器构建服务的工具。如果没有使用 CMS 来创建现有服务，那么它在重新创建服务方面可能没有太大帮助。
我知道这并不能解决您当前的问题，但对我来说，这源于组织以服务器而非服务为思维方式。在以服务为中心的思维方式中，只要服务继续运行，就无需维护单个服务器的个性。如果以规范的方式使用 CMS 来构建整个服务，那么将该服务移动到另一个系统应该相对简单，因为所有机器的个性都将由 CMS 构建。
PS 我不太清楚在这个上下文中 ifconfig 输出有什么意义 - 它是由一个配置文件和一些脚本生成的（否则它在启动时不会出现），如果需要的话，这些可以由 CMS 进行管理。