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