（转）天涯的运维之路

天涯的运维之路 2012-06-13 09:13:32

标签： 互联网 虚拟化 IT运维

原创作品，允许转载，转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明。否则将追究法律责任。 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