为什么在Red Hat和CentOS的主要版本之间进行升级如此困难？
“我们可以将现有的生产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主要版本冲突的建议。