天涯的运维之路&&天涯运维之服务器远程操作(转)
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
早期天涯sa在批量操作服务器时，采用的是SSH公钥方式来实现远程命令操作，即在管理主机生成一对密钥文件（公私钥），然后 把公钥文件复制到受控机，直接在管理主机上远程执行命令或运行脚本，例如：
ssh root@10.20.0.54 "/bin/date"。
在服务器较多的情况下，sa先在管理主机创建服务器列表的文件，然后使用shell或python写循环执行命令的程序，在管理主机上运行。
随着产品、服务及服务器的增多，sa岗位的细分，这种手工的方式已经落后。无法满足规范化、标准化和可管理的运维方向。
因此我们在运维管理平台上开发了远程操作模块，实现了对主机批量操作的功能。
远程操作模块基于Func来进行二次开发。Func是由红帽子公司以Fedora平台统一网络控制器 Func（Fedora Unified Network Controller https://fedorahosted.org/Func），目的是为了解决这一系列统一管理监控问题而设计开发的系统管理基础框架。 能有效的简化多服务器系统管理工作的工具，易于学习，易于使用，易于扩展，而且功能强大。
Func的特点有：
1、Func可以在主控机上一次管理任意多台或任意多个服务器组。
2、Func基于Certmaster（https://fedorahosted.org/certmaster/）建立了Master-Slaves主从SSL证书管控体系，可以将证书自动分发到所有受控服务器。
3、Func命令行可以直接发送远程命令或者远程获取数据。
4、Func 开发者已经完成了大多数常用任务模块的开发，包括命令执行模块、文件传输模块、IPtables模块、查看硬件信息模块、Mount模块、进程模块、服务模块、重启系统模块等。
5、可以通过Func提供的Python API轻松编写扩展模块，以实现具体功能扩展。而且任何Func命令行能完成的工作，都能通过API编程实现。
6、Func通讯基于XMLRPC和SSL标准协议。
Python使用Func的范例如下：
import Func.overlord.client as fc
client = fc.Client("*.static.tianya.cn;*.varnish.tianya.cn")
# 安装包控制
client.yumcmd.update()
# 服务控制
client.service.start("varnish54")
# 获取硬件信息
print client.hardware.info()
Func管理主机的安装过程为：
1）使用yum安装Func包：
yum install Func
编辑/etc/certmaster/certmaster.conf，用于允许自动签署（缺省为off）。
autosign = yes
2）将certmaster服务设为自动运行
/sbin/chkconfig --level 345 certmaster on
/sbin/service certmaster start
3）添加客户机ip及主机名到/etc/hosts
安装客户端Minions
1）安装Func包
yum install Func
2）添加服务机ip及主机名到/etc/hosts
3）编辑/etc/certmaster/minion.conf，指定certmaster。
[main]
certmaster = certmaster主机
log_level = DEBUG
cert_dir = /etc/pki/certmaster
4）允许并运行Funcd服务
/sbin/chkconfig --level 345 Funcd on
/sbin/service Funcd start
在MASTER中签署KEY
1）在certmaster系统中运行
certmaster-ca --list
2）为所需系统签署keys
certmaster-ca --sign hostname
注：如果打开autosigning，以上将自动完成。
开放防火墙端口，缺省时certmaster监听51235端口，Funcd监听51234端口。
Func一些常用命令如下：
查看有多少客户机注册
certmaster-ca --list-sign
查看当前有哪些服务器注册到主控机
Func '*' ping
查看所有服务器的硬件信息
Func '*' call hardware info
查看varnish35上的系统负载
Func 'varnish35' call command run /usr/bin/uptime
启动varnish35上的httpd服务
Func 'varnish35' call service start httpd
运行脚本
Func '*' call command run "/bin/date"
('10.2.0.12', [0, 'Fri Jul 29 19:50:25 CST 2011\n', ''])
我们的远程操作模块主要由以下几个功能组成：
1、角色管理功能
创建角色，将用户添加到不同的角色中。
在角色中添加可执行的操作模块。
2、模块管理功能
对操作模块进行管理，包括模块名称，执行方法，Func模块的名称，Func的方法，命令行和执行参数。
例如，重启linux主机的操作模块为直接调用Func模块。执行方法为commandline，Func模块为RebootModule，方法为reboot。
重启resin服务的操作模块为，执行方法为运行脚本，添加执行的shell脚本。操作时系统将脚本通过Func的文件传输命令上传脚本到目标主机，在远端执行后自动删除脚本。
Python的代码为
client.local.copyfile.send(shellfile)
client.command.run("chmod +x " +shellfile) # 加执行权限
client.command.run("/bin/sh "+shellfile)
client.command.run("rm -f "+shellfile)
也可以在主机端预装shell脚本，通过模块来远程调用脚本。
3、主机认证功能
将未认证主机认证到Func中。
将已认证主机从Func中撤消认证。
还有一些其它功能，如操作日志，登陆日志，操作统计等。
远程操作模块可以调取资源中心的数据，因此可实现按产品、按功能、按机柜或按机房等对指定的一台或所有服务器进行统一的操作。
远程操作模块可以满足绝大多数服务器自动化运维的工作内容，减轻了sa的工作量，降低了操作失误的风险。同时将一部分特定的操作授权给研发团队，为研发工程师线上处理产品和服务提供了便利，也避免了线上的安全风险。
现在远程操作模块日操作数量达二百之多，按每项操作节省sa的30分钟重复工作计算，每天节约100多个工作小时，让sa能把工作重心放在更重要的工作中去。
本文出自 “私有云运维” 博客，请务必保留此出处http://millerzhou.blog.51cto.com/5275815/899680
浙公网安备 33010602011771号