服务器 Gind.cn

服务器问题集锦,包括 Linux(Ubuntu, Centos,Debian等)和Windows Server服务器

为什么在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.conf , rtctl ,中断绑定和驱动程序调整,以降低邮件延迟。 一些有定制和/或实时内核。 开发者工作站也运行类似的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议。