(转)天涯的运维之路

  1. 云栖社区>
  2. 博客>
  3. 正文

(转)天涯的运维之路

ap0581w9c 2012-11-23 11:37:00 浏览496
展开阅读全文
原创作品,允许转载,转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明。否则将追究法律责任。http://millerzhou.blog.51cto.com/5275815/896938

 

天涯社区是一个典型的中型互联网公司,目前的现状为:
1、千台服务器规模,近10G的流量,日PV亿级,每秒用户会话几千;
2、2个数据中心,1个主机房,1个分时数据备份;还没有实现双机房冗余,即应用和数据的实时同步;
3、运维团队规模不大,人员流动性大,要求运维工程师多面手;
4、业务繁杂,产品运维支持困难,产品变动大,服务器经常在不同的产品间相互变更。


2002年我进入天涯,02年的天涯仅十多台服务器,1名sa。当时运维团队的重点是创收,所以运维团队的工作中,运维仅是一小部分。运维部门的重点工作是做项目搞创收。几年以来实施的项目有系统集成、网站开发和托管、机房建设等工程。

比如海南省某银行的机房工程项目,从方案设计到机房施工,包括布线、装修、消防、空调、新风、强电、防雷等几百平方米机房建设项目,全部由我们这支廖廖数人的队伍完成。

我们实施的网站开发与托管累计有数百个,运维团队和技术团队共同在天涯运营最困难的时候,保住了天涯顺利渡过互联网寒冬时期。

几年后,随着互联网复苏,天涯流量不断翻番,运维部门逐渐从系统集成项目抽身而退,工作重心转移到天涯网站的架构扩展及运维之上。

在天涯网站调整发展时,国内的互联网无论在网站架构或是运维上资料极少,不象现在这么丰富。所以我们只能是边摸索边测试边实践。

最早期的天涯是ASP+MSSQL Server的二层结构,应用层通过ODBC直接访问后台数据库。产品功能设计非常简单,缺乏基础产品,例如没有搜索产品,标题搜索直接用like来匹配标题字段。这样的程序实现在访问量一大时马上把数据库堵死。

这个时期的运维团队仅有2个人(最早的sa因待遇太低,跳槽去了省级报社),面对访问量一大就崩溃的天涯网站,我们开始和技术团队一起开始了天涯运维的第一阶段,架构扩展阶段。

天涯是个动态内容网站,所有的内容直接从数据库生成,也就是说,用户每访问一个帖子,都会在应用服务器逻辑计算一次,在数据库后端生成一次事务,一天上百万的PV就是上百万的数据库事务,对应用和数据库压力非常之大。

我们当时参考了车东等网上技术大牛的博客,用squid在前端做了被动内容缓存,应用层用ASP函数生成HTTP过期标记。帖子页面过期时间为5分钟。

squid初上线时的命中率为45%左右,不算高,于是我们又在squid的前端加了一层反向代理haproxy,使用haproxy通过url hash将指定的url由统一一组squid来支持。通过这样的策略,命中率提升到70%多。

数据库扩展方面,我们用最简单的办法,分库。原来的版块是一张表,分库后每一个版块是一个独立的库,访问量大的版块甚至由一组独立的数据库服务器承载。早期的数据库平台是MSSQL Server,我们用日志复制的方式来做双机,发布和分发服务器是主,订阅服务器是从。

后期迁移到Mysql后就更简单了,一组服务器由一台/二台master和多台slave组成。master负责写,slave负责读。目前架构设计正在考虑通过NOSQL的架构重新将所有版块库组成一个更大的,支持更高水平扩展的分布式虚拟数据库。

面对早期的windows服务器,运维团队很难对其进行自动化运维,所以当时sa最烦的事情就是软件部署、补丁升级、服务器重启及配置管理等重复劳动的工作。当时的运维基本上靠手工和一些简单的运维工具。

随着天涯应用架构从ASP转向JSP,原来的IIS+MSSQL+Windows平台也转向Resin+MySQL+Linux,此时的运维团队开始天涯运维的第二个阶段,平台转型阶段。

原来整个运维团队仅四五人,每个工程师均负责网络、数据库和系统职能。新阶段人员按职能组建成3个组,分别负责系统、网络和数据库。每个组由各组主管负责本组工作。简单的运维流程和管理规范也随之成熟规范起来。

天涯网络和应用架构在运维团队及技术团队的努力下已经成熟稳定,前端是智能DNS和双线接入,本地负载均衡采用F5-LTM 6400和LVS,反向代理采用Haproxy,页面内容缓存使用varnish替换了squid,应用层为Nginx+esin,静态资源采用Varnish+Nginx,数据级缓存采用Memcached,数据库为MySQL,中间层使用ICE和MQ。

这个时候的运维工具主要由sa手工来搭建。因工程师人力不足,sa的日常工作重点是产品运维和排障,所以大家都是通过晚上和周末见缝搜针地学习、开发和部署运维工具。

我们用cacti来做性能监控,nagios做主机监控,用PHP+ssh实现远程管理,用ASP+MSSQL自己写资产管理系统等。

2009年,运维团队开始天涯运维的第三个阶段,运维平台。

2009年运维团队开始组建内部独立的运维开发组,专门负责运维平台的规划和开发。运维开发组将早期零散的运维工具和资源统一起来,重新开发一套平台化的天涯运维系统。

已完成的天涯运维系统有资源中心、监控中心、数据库信息管理、网络设备管理、性能监控、容量规划、远程操作、应用发布、LVS管理、Puppet配置管理、虚拟机管理、Haproxy管理等功能模块。

正在开发及计划开发的有软件包管理、应用和业务监控、流程管理、工单管理、数据库管理等功能模块。在运维管理平台的开发上,我们借鉴了大互联网公司的运维平台,同时结合天涯本身的业务和产品特点,量身定制,走一条适合自己的路。

为了提升硬件的使用效率,解决产品快速扩容及缩容的问题,加快服务器部署时间,提升sa对产品的快速支持,2009年运维团队开始尝试使用虚拟化技术。在经过测试和实践后,我们使用了XEN来实施虚拟化,并使用性价比最高的服务器硬件方案来实施虚拟化,即双路4核CPU,64G内存,6块SATA硬盘。

每个VM的实例为单核CPU、8G内存、100G磁盘空间、100M网卡。我们没有使用统一存储,经过计算这样的性价比不高。VM的容错我们通过将VM部署在不同的物理服务器实现。至于应用集群则通过前端负载均衡解决。

经过二年多的虚拟化实践,虚拟化技术很好地解决了天涯对各产品的快速支撑需求,特别是在仅有几名sa的运维团队中,支持了天涯几十个产品,上百个应用的在线运行,为业务的扩展提供了便利。

虚拟化实践经历过一些挑战,比如2011年数据中心UPS掉电,一个楼层的服务器全部当机,虚拟化平台中有多台VM没有自动启动,后来由sa手工修改了启动参数后才顺利启动VM,但虚拟化平台没有发生大规模故障,经受住了挑战。

天涯在虚拟化的过程中,主要问题集中在网卡上。例如某台VM网络流量过大时,会影响其上的其它VM,表现为网络有延迟或丢包。因此在新的服务器硬件上我们采取了新的策略,采用多队列网卡应对VM在网络方面的瓶颈。

随着天涯虚拟化的不断深入,天涯的虚拟化应用越来越广泛,目前天涯的VM已经占了天涯服务器总数的四成以上。现在天涯的虚拟化正从XEN迁移到KVM。

未来的天涯运维方向将重点在公司私有云的技术实现和运维上。我所理解的私有云由虚拟化+虚拟存储+大二层网络+分布式数据库+自动化运维几个重要构件组成。这需要在云计算方面投入研发资源,同时在开源平台上进行二次开发。

私有云的实践对运维工程师提出了更高的要求和挑战,运维工程师要达到devops的境界,并且更深入地理解私有云架构才能实现对私有云的运维能力。

所以我们的运维团队首先是学习型团队,团队成员的成长是我们最看重的团队目标。每个工程师必须有自己清晰的职业生涯规划,不断在职业成长中实现个人的近中远期目标。
 

本文出自 “私有云运维” 博客,请务必保留此出处http://millerzhou.blog.51cto.com/5275815/896938

网友评论

登录后评论
0/500
评论
ap0581w9c
+ 关注