效劳器操纵体系该当挑选 DebianUbuntu 仍是 CentOS?

你维护的是一个购买自其他厂商的不开源的商业软件,这个软件是在 RedHat 系统下面开发的,厂商表示没有测试过其他系统下面的执行情况

你维护的产品只能支持 MySQL 4, 不能支持新版本的 MySQL,开发人员早就离职了找不到人改了

这些场景下面选择的操作系统能一样吗?啥场景都能用某一个操作系统搞定,那其他操作系统为什么不去死?

对于很多问题,回答的时候都是决定脑袋的(无贬义)。比方说,在系统选择问题上,SA跟开发者一定会持有不同观点。

如果你是系统管理员,保证服务器的稳定是你的第一要务,这是你的选择倾向。为了这一点可以牺牲其他的东西。

如果你是开发者,保证你的开发的应用能够稳定方便的部署到服务器才是最重要的,为了这一点也可以牺牲其他的东西。

系统管理员一定会推荐选择 CentOS,甚至是 RHEL,原因嘛,自然因为他们自身最熟悉,而且理论上更稳定。即便这本身会给开发者带来额外的麻烦,反正与自己无关。

不过,开发者会尽自己所能说服系统管理员不要选择 CentOS,而是选择 Ubuntu/Debian,原因嘛毕竟跨发行版部署常常会是个很蛋疼的事,在十多年工作生涯中我遇到过各种各样层出不穷的事情,其原因当然都是因为服务器选择了一个蛋疼的发行版,而服务器发行版通常而言对开发都不友好,因为两者的目的矛盾冲突。

我能够建议的就是:如果你自己是开发者,如果你自己买了一台 VPS 自己搭服务器用。选 Ubuntu/Debian 挺好。当然如果你觉得自己闲工夫实在多得没处花,可以隔三差五的就到服务器上做升级更新,用 ArchLinux 也无不可。

如果你是系统管理员,上面的程序不需要你亲自开发,那么用 CentOS 最好不过了!至于不方便的地方让开发自己去克服,反正自己维护只要稳定就行。还可以不失时机的责备几句:「你连 CentOS 都适配不了搞个什么开发」,「自己技术不行不要怪服务器版本!」,「不要指望发行版提供的包,需要什么新版本全部自己下载了重新编译就好了!」,微微一笑,深藏功与名。

================================================

他们进货,去机房装系统,配置网络结构,加入运维管理系统,添加监控,交付。除去采购外,整个一套流程大概是一周。

结果今年上半年的某一段时间,一周一个机柜的事情持续了两个月。运维同学辛辛苦苦装好一个机柜,周末打算轻松一下。被老大通知,又来客户了,机柜又不够用了,下周继续。

是的,我们现在20个机柜不止。机房有多少机柜我不知道,不过照这个趋势来看,我们快把机房包下来了。现在我们的带宽已经没有限制了,每个月月底按照合同秋后算账。

我们有一些有三年历史的服务器,台数不多。现在来看,性能已经远远不够。CPU不够快,也没有SSD,硬盘读写次数也太多。这些机器的下场,多数会被换下来折旧卖掉,或者作为测试服务器,搬去测试机房。而现在机房里面大半机器,都是两年以下历史的。而且至少一半服务器历史不超过半年(。。。)。从现状上看,把老服务器留在机房,其性价比并不合算。因为机房有机架密度问题,限制着我们的单机房极限,这相当于变相的租金。

比我们更极端的是页游。他们的一组服务器生命周期一般是半年。半年内,要赚钱的也赚完了,不赚钱的也死完了。所以他们甚至不会新采购硬件服务器,而是直接使用虚拟机。

RH系的提供10年级别的维护性,我换个说法,也就是最近的软件在RH的官方库里面找不到。当然,装最新的RH是有的,但是在安装了三年的一个系统上?肯定没戏。

我们的”数据“,都是装载在磁盘上的。而换”系统“并不需要更新这些数据,只要把系统盘擦掉重部署一遍,然后配置好deploy系统就OK。在开发之初,”环境“,”程序“和”数据“分离,就是一项基本原则。而且即使是”数据“,丢掉一台机器上的所有”数据“也不会构成问题。这应当是运维基础中的基础。只有少数几台服务器,既不能直接更换也不能停机。这些机器我们做特别的管理。

很简单。因为最初的开发希望在Linux上进行。直接在Linux上开发和测试,对于startup的快速开发是非常重要的。而开发用什么版本,服务器跟什么版本,这是最省事和好办的。如果你硬要和我争,说开发在Mac上,跑在Linux上一点事都没有。或者说开发一个发行,服务器一个发行也OK。

我至少得说这对于golang和python都不是事实。除非不用cgo,也不用python的C扩展。

先不提Mac下和Linux下的差异。我们今年在升14.04的时候就发现,12.04和14.04的编译互不通行。所以现在12.04的编译可以程序员自己编译了本地测,14.04的就必须在测试环境里干。一帮程序员远程tcpdump出结果,拷回本地wireshark一把。。。

当然,这也有个问题。就是上面”我们不喜欢三年以上的系统“。所以呢。明年我们的系统大概会轮换重装,14.04。。。

那要看和谁比。这里有HeartBleed事件的统计。虽然不普遍,但是我觉得这种大漏洞比较有代表性。

如果和RH比,Debian的修复速度是不及格,但是和CentOS比。。。怎么说呢?6个小时对10个小时,有种五十步笑百步的味道?

libc的依赖早就满足到不能再满足了。直到今天为止,openssl在debian上的升级还不需要你强制跟随升级libc6。而kernel根本没有依赖。

Debian是由社区维护,这没错。但是选包并不是社区组织。Debian中,如果没有特定理由(例如dfsg)阻止你打一个包,那么只要有maintainer,就可以打包。哪怕这个包的用户其实不是很多(很多包甚至统计上只有1X个用户),这也是Debian那么一大堆包的原因。

Debian包的管理方式是,先进入unstable(是的,除了少数情况,一般不是进入experimental)。在一周后,看看没问题,就进入testing。没问题的指标是,这个包和依赖的包没有RC bug,就是致命性bug。

所以很多在unstable里面有的东西,testing里面反而没有。因为unstable里面的某个基础依赖包的RC bug并没有被修复。而且testing修漏洞的速度是最慢的。因为一出问题,unstable会直接引入新的版本。而stable会要求maintainer修复。可怜的testing只能等一个礼拜。。。

那什么时候进入stable?他不会随着你的循环进入stable。而是每1.5-2年(预期1.5年,但是RC冻结周期往往会超标,根据历史数据统计,一般两年)做一次发布,这个发布会冻结所有新包,并修正RC bug。等大家觉得差不多稳定了,OK,原本的testing就成为stable,而原本的unstable就fork出新的unstable和testing。

所以现在的testing代号就会成为下一个stable代号,而每次fork的时候,我们都是决定testing代号——就是下个发行的发行代号。

所以你看BTS的追踪,会发现每1.5年有一段时间,RC bug的数量会锐减,而新包的数量也锐减。这不是大家都冬眠了,只是新发行周期而已。

但是如果新老版本差异太大,老版本又拒绝提供补丁,那么逼不得已的情况下,需要评估是不是能升。例如某一段时间,mysql的版本号是5.0XXreal5.5XXX(这个是听本厂DD说的)。至于原本的兼容性问题,我也不知道他们是怎么想的,大概是认为mysql server没啥依赖性问题吧。

但是这种情况下,RH一般也没办法吧——除非他们自己出程序员给老版本做一遍补丁。不过如果这样的话,oracle一般会merge back回去,debian就跟着沾光了。

Debian和Debian基础的系统,主要的发行方式是网络。光盘只是给你个安装的机会。这点debian更加明显——他有种光盘叫做netinst。里面只有基础包的安装包。在不联网的情况下,你只能装出一个用于联网升级的系统。没有gui,没有openssh,啥都没有。

一旦一个程序基本成型,就一定会形成”接口“。API是接口,调用的程序,参数,顺序,环境变量,一样是接口。有接口就有接口兼容性。如果不考虑兼容性,一律使用最新版本的话。。。

不要以为这很扯,我在实际里多次碰到这种问题。python-mongo多次修改接口,sqlalchemy0.6时写的程序,经我反复修改终于上到了0.7,却死也上不到0.8。至于docker,也是个版本号刚刚过1.0的家伙。在1.0前面,我们就作大死的做了二次开发。结果惨不忍睹。

所以我们用一种被称为“发行”的方案。即一段时间,将稳定的代码固定下来,形成某个版本的发行。例如linux-kernel-3.2.0。而后新功能在3.3上面渐进,原本使用3.2的并不受到干扰。

这本来挺完美,可惜有一个问题。bug并不一定出在最新版上面,他有可能在14年前就已经存在了。这样会使得bug横跨多个版本。而这个bug又不能不修的时候——例如安全漏洞。

上游会修多少个发行的漏洞?如果上游不修,这个发行的漏洞怎么办?大部分漏洞只是几行就可以完成修正,但是有些发行甚至要动架构,怎么办?

可惜,三者一般都需要。有些很古典的程序已经进入了2的情况,例如TeX。至于大部分互联网公司线。但是大部分发行版内的包,可是要三者都满足的。

其实还是很大的。RH的开发是真的开发。Debian的”Developer”,其实只管开发debian打包用脚本,维护版本,补丁,仓库。而RH的开发,别的不说,你就看内核补丁贡献数吧。

这也是社区和公司不同取向的差别。社区不管商业能处理的一些问题,而且他们也管不了。先不提RH有多少人,Debian社区有多少人。我就吐槽一下中国DD数量吧。我查询了一下,总共8个(db)。其中我认识5个,超过一半。某次emfox来开会,lidaobing和zigo也在。我们开玩笑说,这次会议集中了中国近一半的DD。。。其实整个会场里面人数都没超过20。。。

也只有RH这种级别的公司,才有大量人力去折腾内核,驱动之类的事情。因为debian就算想折腾,也折腾不动啊。从某种意义上说,所有linux发行的蓬勃发展,都得益于RH的大量收入。

所以真想支持开源的,不全买,买一套RHEL也好啊。别老叫着CentOS免费,免费还说个JB的支持开源。

至于什么叫做“明白自己在干什么”,其实没一个统一的标准。很多时候选择开发版有点“如人饮水,冷暖自知”。例如我们选Ubuntu,解决了发布同环境问题,却引入了运维滚动升级问题。但是经过权衡,发布和调试环境不同会导致研发效率的大幅下降,而我们的研发是不能靠花钱招的(广告:长期招聘靠谱golang研发),但是我们的运维是可以靠花钱招的。这个时候痛苦也得滚动着上了。当然,也许若干年后,发现其实我们错了。可是错的理由我们现在看不到也想不到。当然,像我们,或者页游这种奇葩公司,也不总是出现。所以大部分情况下,用RHEL都是对的(当然,原作者说的太绝对化了一点)。

所以debian的衍生发行一点都不比RH逊色(Linux发行版列表)。最大的就是得益于dfsg规定,凡是允许进入debian。

未经允许不得转载:主机宝贝 » 效劳器操纵体系该当挑选 DebianUbuntu 仍是 CentOS?

评论 抢沙发

评论前必须登录!