从临危授命到扭转乾坤，天天拍车运维架构演进及实践(3)

内存与CPU严格匹配,当时我们有一些服务器,内存频率是比较高的,但是与之对应的CPU并不支持那么高,你虽然插上去可以用,但是系统一直提示报错.为了防止以后不应该出现的奇葩问题,所以我们是把内存跟CPU进行了试配.

3、操作系统

操作系统这一块儿我们做的是非常多,我们做了订制化,而且深度订制化.

• Kernel统一使用精简过且重新生成的rpm包

第一就是我们kernel,我们把内核使用了2.6.32-431.29.2的内核,对内核重新做了调整.把一些服务器上用不到的驱动模块全都进行剔除,比如说WIFI、红外、蓝牙、用不着的网卡驱动全都剔除,做一个精减,精减完了以后重新做成内核的安装包.

• KickStart高度定制(网络部分)

因为要实现自动化安装,所以必然要做KickStart,这块我们也做高度订制化.我们已实现了自动去配网卡,如果你看过红帽官方的文档,KickStart里面的章节是31章节,你就可以知道网卡直接可以配置成bond模式.

我们还在Kickstart里面对SSH配置,还有DNS的配置,还有对于网卡硬件的配置.我们可以修改网卡的参数,发送和接收都是可以更改的,我们也是在KickStart里面做脚本自动修改.

• 优化TCP/IP协议栈(TW、sysctl.conf)

优化TCP/IP的协议栈主要是窗口还有大小,调整TCP各种连接的超时时间.如果没有经过内核的订制,一般做架构或者你的应用访问时服务器上会产生TW连接,一般内核里面默认是60秒的时间才会进行释放.如果你的网站是高并发访问量非常大的话,那你的连接基本上是释放不干净的.所以我们做了一套直接修改内核的定义.从60秒修改成5秒.这样可以让自身的服务器对外始终只有少量的TW连接.

• 默认关闭不必要的服务,关闭无关端口

把不必要的服务全部关掉,因为关闭了不必要的服务大部分端口也就被你关闭掉了.

• 剔除不需要的rpm包,保留性能分析工具、编译工具

再接下来是删除不需要的rpm.如果你们有仔细订制过的话,就会发现有时候也挺坑的,会给你安装很多用不到的软件在系统里,而且还给你开放一些端口.

• 所有开源组件定制化,动态链接库不依赖操作系统(绿色版)

• 软件安装目录、配置文件目录、日志目录、PID目录标准化

再下面是所有的开源组件进行订制化,我们的安装目录、配置目录、PID文件目录、启动脚本都是做了定制的.需要你把软件安装到下面,方便管理.自己有源服务器,会在上面把源码进行定制化的翻译,再做成绿色软件.不依赖于操作系统,我的软件包如果是rpm包,只要是以rpm包管理的系统上随便安装,不依赖于动态软件库.

4、开源组件

这边是开源组件做的升级还有引用的其他东西,我们每一个开源组件的变更都是有原因的.

• 4层负载均衡：LVS–àHaproxy

其中第一个负载均衡把LVS换成了Haproxy,大家去网上查的话应该有很多人写过差别.当时换LVS是为什么呢?第一,LVS虽然是非常高性能的转发,网上人家说可以转发100万、200万,这都是扯淡的.因为这些人在写的时候并没有告诉你他的网卡的带宽,他测试时后端真实响应的数据多大.LVS在部署时它的机器的IP地址必须是同一网段的.如果你的公司业务非常大的话,你就要消耗非常非常多的公网IP,唯品会就是这样做的.

LVS除了刚才说的原因,还有一个原因是不能灵活地进行配置,配置我们的虚拟主机,不能把CPU按照不同的业务运营的负载高低进行分配.LVS不能做什么事情呢?不能动态地对配置进行修改,如果你要添加新的集群的话你得修改配置文件.再往大了说,如果用LVS跟OSPF配合使用的话,RealServer上就需要维护脚本,进入51汽车时运维经常在配置脚本时忘记执行,所以鉴于这些原因,当然还有一些其它的原因,使用起来并不符合我们的要求.

换成了Haproxy以后,可以根据业务的压力不同,将CPU分配给压力大的业务,有的人可能会用Haproxy,但是它就一个问题,不能将我们用户真实的IP传到后端.很多人会使用Haproxy的透明代理模式Tproxy模式,把用户的真实IP上传到后端,这跟LVS的机制几乎是类似的.但是我们更换到Haproxy的1.5版本以后这上面默认之了proxy协议,我不再使用透明代理上传客户端的真实IP,使用varnish写在日志里面做分析.

• 页面缓存：Varnish 3.0 —à? Varnish 4.1

页面缓存原来用的是varnish3.0的版本,后来升级到varnish4.1.因为它在做数据连接时很容易产生CLOSE-WAIT连接,它连接的释放是有问题,你的内存有多大就一直消耗.大家知道做TCP连接的内存是不可交换的内存,不能使用交换分区.

• 反向代理：Nginx–àTengine–àOpenResty

早期反向代理用的很多版本后来我们使用Tengine,为了统一技术体系就使用了它.但是在去年下半年时我们发现Tengine的很多公司已经跟不上Nginx了,很多技术Tengine虽然支持但是有很多问题.后来用下来,包括日志的过滤,相信大家有很多这种需求,比如说你的网站,你主要的运维下面可能会加一些JS、CSS,如果你不开始过滤的话会希望把访问日志全部写到日志里面,不方便你去进行日志的分析.如果我只去过滤我主要的请求,那我就需要使用日志过滤,而那个时候Tengine2.1.2里面根本没有,只能使用第三方的模块.第三方的模块功能我要去用时,我发现Nginx早就实现了,可以做一些变量的映射,应用到我们的指令里面就可以进行过滤,非常方便.我们更换了Opneresty,更换它的原因还有什么呢?因为微博开发了一个模块是Opneresty,可以进行增加和产出,而Tengine不支持模块,所以没有办法,我们只能更换Opneresty.而且Opneresty又支持别的模块所以我们就直接更换了.

• 虚拟化技术：VMWare —à?Proxmox(kvm)

虚拟化技术把vmware更换为KVM,直接使用了开源的Proxmox,目前小的互联网公司也在用.做虚拟化非常简单,运维开发时可以进行系统研发.

• 对象缓存：Memcached–àRedis

（编辑：ASP站长网）