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

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

来自两个完全不同环境的客户提出的一个简单的要求促使我回答“是的,但需要协调重build所有系统 ”。

这两个客户都觉得,对系统进行彻底的重build对于停机和资源的原因来说是不可接受的select。当被问及为什么有必要完全重装系统时,我没有一个好的答案,“这就是……”

我并不是想引起关于configurationpipe理的反应(“木偶一切 ” 并不总是适用 ),或者客户应该如何计划好。 这是一个现实世界的例子,在生产能力上已经发展壮大,但是没有看到转向下一个版本操作系统的干净path。

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

环境B:
拥有200个CentOS 5.x系统的高频金融交易公司,在多个同地点设施中进行生产交易操作,支持内部开发和后台function。 交易服务器在裸机商品服务器硬件上运行。 他们有许多sysctl.confrtctl ,中断绑定和驱动程序调整,以降低邮件延迟。 一些有定制和/或实时内核。 开发者工作站也运行类似的CentOS版本。


在这两种情况下,环境运行良好。 升级的愿望来自对EL6中新的应用程序或function的需求。

  • 对于非盈利公司来说,它与Apache,内核以及一些能够让开发者感到高兴的东西联系在一起。
  • 在交易公司,这是关于内核,networking堆栈和GLIBC的一些增强,这将使开发人员高兴。

如果不彻底改变操作系统 ,两者都不能轻易打包或更新。

作为系统工程师,我很欣赏红帽build议在主要版本之间移动时进行完整的重build。 一个干净的开始迫使你重构并注意一路上的configuration。

对于客户的业务需求敏感,我想知道为什么这需要这么艰巨的任务 。 RPM打包系统不仅能处理就地升级,而且还有一点点细节让你: /boot需要更多的空间,新的默认文件系统,RPM可能会打破升级中,不推荐使用和不使用的软件包。

这里的答案是什么? 其他发行版(基于.deb,Arch和Gentoo)似乎具有这种能力或更好的path。 比方说,我们find了以正确的方式完成这项任务的停机时间:

  • 当EL7发布并稳定时,这些客户应该做些什么来避免相同的问题呢?
  • 还是这样的情况是每隔几年人们需要辞职去重build?
  • 这似乎已经变得更糟,因为企业Linux已经演变…或者我只是想象呢?
  • 这是否阻止了任何人使用红帽和衍生操作系统?

我想有configurationpipe理的angular度,但是我所看到的大多数Puppet安装并不能很好地转化为具有高度自定义的应用程序服务器的环境环境B可能有一个服务器,其ifconfig输出如下所示 )。 不过,我很乐意听到关于如何使用configurationpipe理来帮助组织跨越RHEL主要版本的build议。

    (作者注意:这个答案指的是RHEL 6和以前的版本,RHEL 7现在有一个从RHEL 6完全支持的升级path,详细信息在最后)。


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

    1. 放入安装DVD(或通过iLO / iDRAC使用DVD映像),从中启动并select升级(例如, linux upgradeany
    2. 手动更新redhat-release RPM,运行yum distro-sync (稍微简化一下)然后重启。

    方法1仅仅是不受支持的。 方法2适用于真牛仔。 除了推荐的全新安装,我已经完成了这两个…


    我需要支持吗?

    支持在我们的世界中有两个互补的含义。 首先是产品有一个特定的function(例如“Postfix支持SMTP”)。 第二个是供应商会和你谈谈。 从上下文来看,哪个定义并不总是很清楚。

    要完成一项任务,显然需要第一个意义上的支持。 供应商支持来帮助您解决问题,并向供应商反馈哪些function需要存在或得到改进。 许多网站在拥有内部专业知识来解决任何可能出现的问题时,都会为供应商提供支持,比供应商可以更快,甚至更便宜。 是否购买供应商支持最终是您必须作出的商业决策(或者build议pipe理层)。


    为什么不进行就地升级?

    这就是红帽所说的 :

    红帽不支持Red Hat Enterprise Linux的任何主要版本之间的原地升级。 主要版本由整数版本更改表示。 例如,红帽企业Linux 5和红帽企业Linux 6都是红帽企业Linux的主要版本。

    跨主要版本的就地升级不保留所有系统设置,服务或自定义configuration。 因此,从一个主要版本升级到另一个主要版本时,红帽强烈build议重新安装。

    他们进一步警告说:

    但是,在select升级系统之前,请注意以下限制:

    • 执行升级后,由于各种configuration文件格式或布局的变化,单个程序包configuration文件可能会也可能不会运行。
    • 如果您安装了Red Hat的分层产品(如Cluster Suite),则可能需要在Red Hat Enterprise Linux升级完成后手动升级。
    • 升级后,第三方或ISV应用程序可能无法正常工作。

    当然,他们会介绍如何通过方法1进行就地升级,以防万一您真的想要这样做。 这个function是存在的,红帽把开发时间放在里面,所以这个function是支持的。 但如果出现问题,红帽会告诉你安装新鲜的; 他们不会提供供应商支持的事情,因为升级而中断。

    为了logging,我从来没有真正遇到RHEL / CentOS或Fedora系统就地升级的问题,我无法自己解决。 典型的问题来自于重命名软件包,第三方软件库以及软件包的i386和x86_64体系结构之间偶尔的版本不匹配。 我想,安装程序在处理这些问题上要好一些。


    我应该如何升级?

    我通常会提醒人们,他们应该每隔3 – 4年就要维护一次,以便将RHEL系统从一个主要版本升级到另一个版本。 虽然升级一般顺利,但意外事件总会发生。

    对于您的两种环境,我都希望能够进行就地升级,但我强烈build议您首先彻底进行testing。 P2V是服务器的一个有代表性的示例,并通过就地升级在虚拟系统上运行,以查看您将要遇到的问题。 然后,您可以根据对发生的事情有更好的了解来计划实际的生产升级。

    对于像这样的大型部署,可以考虑使用Limoncelli的“一对多”方法。 升级一台机器,看看出现了什么问题,解决它们,然后利用升级一小批机器时学到的经验教训,重复吸取经验教训的事情,然后当你相信你有所有的纠结,升级大批量的。

    在这样的时刻,我也build议您长时间仔细观察应用程序的部署过程。 如果它不够自动化,你可以用一个命令来启动它,并合理地确信应用程序将正确部署,那么开发人员可能需要开展工作。 进行这样的部署过程将使得更新版本的EL的全新安装变得容易,然后部署到其上。


    切换分配有帮助吗?

    基于Debian的发行版确实有一个支持就地升级的方法,它大部分都能正常工作,但是它不能解决问题。 例如,通过支持的方法, 从Ubuntu 10.04 LTS升级到12.04 LTS的用户就遭受了很多打击 。 目前尚不清楚Debian或Canonical是否将足够的开发时间投入到“支持”这个function,即确保它能够正常工作。 如果你想要别人牵着你的手,你实际上还得购买厂商支持这个发行版。 所以我怀疑你会从切换到这样的分配获得很多。

    您可以通过切换到诸如Gentoo或Arch之类的滚动发布版本来获得收益。 但是,这也不能让你免于问题; 这意味着您必须在服务器的整个生命周期内(例如,无论何时您或开发人员决定更新系统上的某些内容)连续处理升级问题,而不是一次性按计划完善的分发升级时间。 您也没有供应商提供支持。


    未来该何去何从?

    Fedora项目正在开发一种工具来改善就地升级。 他们有一个名为preupgrade的工具,被放弃了,并用一个名为fedup的新工具取代, 从Fedora 18开始 。 这已经添加到RHEL7,现在就地升级已经完全支持 ,至less从RHEL 6到RHEL 7 。 根据我自己的经验,我可以说,虽然fedup仍然有一些fedup ,它正在成为一个非常有用的工具。

    CentOS也在尝试使用滚动释放types的存储库 ,但它只适用于较小的版本(例如6.3-6.4)。

    我接受你最后一段:

    我想有configurationpipe理的angular度,但是我所看到的大多数Puppet安装并不能很好地转化为具有高度自定义的应用程序服务器的环境(环境B可能有一个服务器,其ifconfig输出如下所示)。 不过,我很乐意听到关于如何使用configurationpipe理来帮助组织跨越RHEL主要版本的build议。

    我认为configurationpipe理系统的真正价值,尤其是在环境B的背景下,是他们提供了独立于运行服务器的服务来构build服务的工具。 如果不使用CMS来创build现有服务,那么在重新创build服务时可能无济于事。

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

    PS我不太清楚在这种情况下ifconfig输出的重要性 – 它是由一个configuration文件和一些脚本产生的(否则它不会在启动时出现),如果需要,可以由CMSpipe理。