本人于2009年12月迁移至独立BLOG。
1、欢迎光临运维进行时,希望认识更多志向相同的朋友!
2、本站部分资源来源于网络,如有侵权请及时与我联系!
3、强烈建议使用Firefox、Opera、Safari及IE7以上的浏览器访问,以获得最佳浏览质量!
4、请勿发表与中华人民共和国法律、法规相抵触的言论,谢谢合作!
5、本人发布的文章与评论内容仅代表本人观点。
1、欢迎光临运维进行时,希望认识更多志向相同的朋友!
2、本站部分资源来源于网络,如有侵权请及时与我联系!
3、强烈建议使用Firefox、Opera、Safari及IE7以上的浏览器访问,以获得最佳浏览质量!
4、请勿发表与中华人民共和国法律、法规相抵触的言论,谢谢合作!
5、本人发布的文章与评论内容仅代表本人观点。
【IT168 专稿】2012年的春运潮造就了中国铁路客户服务中心12306网络购票系统一夜蹿红,从传统购票方式到电子商务,2012年1月1日开通的12306网络购票系统成为了铁道部改革的重要一步。
但是随着12306系统的上线,各种关于12306系统的抱怨声也层出不穷,不少人抱怨网上订票系统十分“龟速” 网络运行奇慢,网页不时“崩溃”,平均刷新500次才能购到一张票,而且订票过程十分繁琐,从用户注册到支付成功,要13道“工序”,让人晕头转向等等。
本来为了让每个归家的人更方便地买到火车票,而12306网上订票系统这个号称斥数千万元巨资建立的电商的表现却难以让人信服,并引发了一些讨论和思考,应该如何建设类似12306网上订票系统这种大型高并发高性能网站呢?IT168记者采访了腾讯架构平台部刘天斯,对于大型高并发高性能网站的建设和优化,他给出了自己的建议。
12306订票网站存在哪些需求特点和挑战?
12306订票网站具有分时段、分区域、高并发等特点,如何确保在高峰时段正常提供服务是一个非常大的挑战,放眼春运期间网上订票系统,表现为页面访问延时大、登录异常、支付失败等问题。这其中存在一定客观因素,也不排除对流量预估不准确、架构设计不合理等情况。官方公布日均PV达10亿,在高峰时段有千万PV的访问量,应对如此高的流量需要从带宽、服务器、网络、应用及业务逻辑等进行优化。
国内的大型网站还包括淘宝、京东、新浪等,12306的访问模式和淘宝、京东存在哪些异同?
相同点都可以理解成电子商务网站,无论是业务逻辑还是应用特点都非常相似,唯一的差别是12306的流量因时段、区域更为集中,有人说像淘宝、京东搞促销,比如”秒杀”。但”秒杀”的对象往往比较固定,后端可以通过缓存机制或静态化来缓解数据库I/O压力,而12306需要每隔10分钟更新票务信息,同时还要保持与集团其它业务系统对接,这点处理起来更为棘手。
淘宝、TMall、京东也曾经遭遇宕机事件,这些宕机事件和12306网站崩溃有何异同?
此类宕机事件原因都是相似的,无非是宽带吃紧或服务器性能出现瓶颈(应用故障、高I/O或业务逻辑异常等)。差异点只有体现在业务层面上,促销活动可以推迟或重新组织,但12306订票系统不行。反之,12306有其它辅助的补救、缓解方案,如电话预定、代售点等,传统的电子商务平台则没有。
12306订票网站在哪些方面可能存在问题?在以上谈到的问题上是否都有一些相应的优化建议呢?
个人认为更有价值是体现在数据分析上,如得到宽带数据、用户流量、区域分布、请求特点、应用瓶颈点、服务器的性能指标等等,这些数据对优化、改良现有架构非常有帮助。抛开宽带因素,以下是对12306平台系统架构的几点建议:
一、前端优化
具体参考:yahoo前端优化34条规则,针对12306平台,个人建议在没有多运营商链路接入(如BGP)的情况下继续使用CDN进行加速。动、静态应用分离,静态业务使用非12306.cn域名可以减少无用cookie带来的流量。任何一个小细节在高并发下都会被无限放大(截止目前发现平台还是以dynamic.12306.cn域名做静态引用)。查询页面的结果是通过Ajax异步返回填充iframe框架来实现,这对动态CDN加速是一个挑战,因为CDN节点并没有真正缓存页面中主要加速的内容。另外提高验证码的复杂度及多样性,可以缓解刷票机给平台带来的压力。
二、运用缓存
缓存最大的好处是减少后端数据存储的I/O压力,从一个普通用户订票轨迹来看,查询读往往是入库写的好几倍,如何减少数据库的读I/O对提高平台的整体性能至关重要,比较流行的缓存技术有针对页面及数据级,页面级缓存有varnish、squid等,如使用CDN,页面级的缓存可以不用考虑,重点将精力放在数据级的缓存规划上,技术方面可以用Nosql来实现,比较成熟的Nosql有memcached、redis、mongodb等。可以根据班次、出发与目的地ID组合或出发日期进行hash分区,这样可以很好地提高缓存命中率,减少后端数据库的压力。
三、代理层
引入代理层的目的是拆分业务,目前平台绝大部分功能都共用一组WEB服务器(从域名及URI结构猜测,不一定准确)来对外提供服务,比如登录、注册、车票查询、余票查询、列车时刻表查询、正晚点查询、订单管理等等,只要其中一个功能模块出现堵塞,影响必定是全局性的。一个好的方法是优化、规范各业务URI,在代理层实现业务的划分,可用的技术有Haproxy、Nginx等,如将/otsweb/regitNote/映射到注册组WEB服务器,/otsweb/AppQuery/映射到查询组WEB服务器,/otsweb/Pay/映射到支付组WEB服务器等等,如此一来,当查询业务出现延时堵塞时不会影响到用户支付。
四、数据库层
之前接触过一些政府行业的业务,数据库服务器往往都使用一台高端的硬件,比如小型机,在互联网行业,尤其是类似于12306订票系统,这往往是最致命的,理由很简单,在大流量并发下处理能力再强的服务器也吐不出数据,因为受网络I/O、磁盘I/O、业务逻辑等方面的限制,所以必须将数据打散,方案有进行读写分离、分区、分片。主从模式可以很好实现读写分离,大部分数据库都支持这点,除此之外还建议使用分区模式,分区策略可以根据业务特点进行,按地域进行分区是一个好主意,因为每个区域都是一个大分区,还可以从业务层面对它做二级甚至三级的"扩展分区"。需要在细化拆分与运营成本上做好平衡。另外I/O密集的点尽量使用SSD代替。
五、负载均衡层
保障一个业务平台的高可用性,采用负载均衡策略必不可少,即使是提供给CDN的源服务器。目前有商用的F5、NetScaler、Radware等,也有开源的LVS,看成本的投入来选择,此处不详细展开讨论。
六、业务层
此次12306网站瘫痪事件,业务层面有无优化的空间?12306网站平台是铁道集团在互联网上对外服务的窗口,与电话订票、代售点都是平级的,后端肯定还关联着很多复杂的业务系统,在没有对整个集团业务系统做扩容的前提下(短期内估计不能实现),可以将网站业务平台剥离出来,当然,完全剥离也不太实际,至少可以延长同步、一致性校验的时间。时间的长短随班次的发车时间成正比,因为大部分的用户都是提前一周以上就着手预定车票。
从百万级、到千万级并发PV的网站,在构架和部署方面会存在哪些差异?
百万PV到千万是一个级别的提升,设计得再好的架构也很难一步到位,也是随着业务的高速增长,不断积累经验、优化、改良的过程。12306的流量达到千万PV 级,但平台的支撑能力远远没有达到预期。
一个大型的高并发高性能网站架构需要从哪些层面去考虑?服务器/存储部署方面需要注意哪些问题?哪些技术能够保证整体系统的高并发与高性能?
设计一个大型高并发网站的架构,首先必须以了解业务特点作为出发点,架构的目的是支撑业务,需要考虑互联互通、负载均衡、网络、开发、缓存、存储、数据库等层面,这些层面看似一个整体,任何一个环节出问题都可能导致整个网站崩溃,所以一个高可用、高并发的平台还少不了监控、开发、运维等角色通力协作。
部署大型的高并发高性能网站架构需要注意哪些问题?存在哪些挑战?高峰期和低谷期的资源和投入如何平衡?
部署大型的高并发高性能网站架构需要注意整体的扩展性与健壮性,解决未来海量数据的存储与处理、密集的数据I/O、互联互通、应用的不断迭代、重构以及缓存机制等问题,对于考验一个成功的架构提出了更高的要求,也是未来面临最大的挑战。对于平衡高峰期和低谷期的资源投入,我想云计算的伸缩性更适合解决该问题。
有人建议使用云计算平台(类似于Amazon之类的)来搭建这类网站,以便提高资源利用率节省成本,您是如何看待的?
云计算是未来一个趋势,优点不多说,它具有动态伸缩、灵活性强等特点,可以让资源利用最大化,可以更好节约成本,非常适用于12306平台。
虚拟化(不局限于服务器虚拟化,也可以包括网络虚拟化等)在这类型大型高并发网站建设过程中可以起到什么作用?
虚拟化是云计算的基石,可以降低企业运营成本,提高资源利用率,个人建议将一些运算量及I/O要求不高的业务迁移到虚拟化,比如web、缓存、代理、中间件服务等应用。在低流量时段可以销毁节点,使物理实体机处于低功耗状态下运行,绿色环保,高峰来临时可以迅速部署上线来提供服务。
原文:http://server.it168.com/a2012/0208/1309/000001309060_all.shtml
但是随着12306系统的上线,各种关于12306系统的抱怨声也层出不穷,不少人抱怨网上订票系统十分“龟速” 网络运行奇慢,网页不时“崩溃”,平均刷新500次才能购到一张票,而且订票过程十分繁琐,从用户注册到支付成功,要13道“工序”,让人晕头转向等等。
本来为了让每个归家的人更方便地买到火车票,而12306网上订票系统这个号称斥数千万元巨资建立的电商的表现却难以让人信服,并引发了一些讨论和思考,应该如何建设类似12306网上订票系统这种大型高并发高性能网站呢?IT168记者采访了腾讯架构平台部刘天斯,对于大型高并发高性能网站的建设和优化,他给出了自己的建议。
12306订票网站存在哪些需求特点和挑战?
12306订票网站具有分时段、分区域、高并发等特点,如何确保在高峰时段正常提供服务是一个非常大的挑战,放眼春运期间网上订票系统,表现为页面访问延时大、登录异常、支付失败等问题。这其中存在一定客观因素,也不排除对流量预估不准确、架构设计不合理等情况。官方公布日均PV达10亿,在高峰时段有千万PV的访问量,应对如此高的流量需要从带宽、服务器、网络、应用及业务逻辑等进行优化。
国内的大型网站还包括淘宝、京东、新浪等,12306的访问模式和淘宝、京东存在哪些异同?
相同点都可以理解成电子商务网站,无论是业务逻辑还是应用特点都非常相似,唯一的差别是12306的流量因时段、区域更为集中,有人说像淘宝、京东搞促销,比如”秒杀”。但”秒杀”的对象往往比较固定,后端可以通过缓存机制或静态化来缓解数据库I/O压力,而12306需要每隔10分钟更新票务信息,同时还要保持与集团其它业务系统对接,这点处理起来更为棘手。
淘宝、TMall、京东也曾经遭遇宕机事件,这些宕机事件和12306网站崩溃有何异同?
此类宕机事件原因都是相似的,无非是宽带吃紧或服务器性能出现瓶颈(应用故障、高I/O或业务逻辑异常等)。差异点只有体现在业务层面上,促销活动可以推迟或重新组织,但12306订票系统不行。反之,12306有其它辅助的补救、缓解方案,如电话预定、代售点等,传统的电子商务平台则没有。
12306订票网站在哪些方面可能存在问题?在以上谈到的问题上是否都有一些相应的优化建议呢?
个人认为更有价值是体现在数据分析上,如得到宽带数据、用户流量、区域分布、请求特点、应用瓶颈点、服务器的性能指标等等,这些数据对优化、改良现有架构非常有帮助。抛开宽带因素,以下是对12306平台系统架构的几点建议:
一、前端优化
具体参考:yahoo前端优化34条规则,针对12306平台,个人建议在没有多运营商链路接入(如BGP)的情况下继续使用CDN进行加速。动、静态应用分离,静态业务使用非12306.cn域名可以减少无用cookie带来的流量。任何一个小细节在高并发下都会被无限放大(截止目前发现平台还是以dynamic.12306.cn域名做静态引用)。查询页面的结果是通过Ajax异步返回填充iframe框架来实现,这对动态CDN加速是一个挑战,因为CDN节点并没有真正缓存页面中主要加速的内容。另外提高验证码的复杂度及多样性,可以缓解刷票机给平台带来的压力。
二、运用缓存
缓存最大的好处是减少后端数据存储的I/O压力,从一个普通用户订票轨迹来看,查询读往往是入库写的好几倍,如何减少数据库的读I/O对提高平台的整体性能至关重要,比较流行的缓存技术有针对页面及数据级,页面级缓存有varnish、squid等,如使用CDN,页面级的缓存可以不用考虑,重点将精力放在数据级的缓存规划上,技术方面可以用Nosql来实现,比较成熟的Nosql有memcached、redis、mongodb等。可以根据班次、出发与目的地ID组合或出发日期进行hash分区,这样可以很好地提高缓存命中率,减少后端数据库的压力。
三、代理层
引入代理层的目的是拆分业务,目前平台绝大部分功能都共用一组WEB服务器(从域名及URI结构猜测,不一定准确)来对外提供服务,比如登录、注册、车票查询、余票查询、列车时刻表查询、正晚点查询、订单管理等等,只要其中一个功能模块出现堵塞,影响必定是全局性的。一个好的方法是优化、规范各业务URI,在代理层实现业务的划分,可用的技术有Haproxy、Nginx等,如将/otsweb/regitNote/映射到注册组WEB服务器,/otsweb/AppQuery/映射到查询组WEB服务器,/otsweb/Pay/映射到支付组WEB服务器等等,如此一来,当查询业务出现延时堵塞时不会影响到用户支付。
四、数据库层
之前接触过一些政府行业的业务,数据库服务器往往都使用一台高端的硬件,比如小型机,在互联网行业,尤其是类似于12306订票系统,这往往是最致命的,理由很简单,在大流量并发下处理能力再强的服务器也吐不出数据,因为受网络I/O、磁盘I/O、业务逻辑等方面的限制,所以必须将数据打散,方案有进行读写分离、分区、分片。主从模式可以很好实现读写分离,大部分数据库都支持这点,除此之外还建议使用分区模式,分区策略可以根据业务特点进行,按地域进行分区是一个好主意,因为每个区域都是一个大分区,还可以从业务层面对它做二级甚至三级的"扩展分区"。需要在细化拆分与运营成本上做好平衡。另外I/O密集的点尽量使用SSD代替。
五、负载均衡层
保障一个业务平台的高可用性,采用负载均衡策略必不可少,即使是提供给CDN的源服务器。目前有商用的F5、NetScaler、Radware等,也有开源的LVS,看成本的投入来选择,此处不详细展开讨论。
六、业务层
此次12306网站瘫痪事件,业务层面有无优化的空间?12306网站平台是铁道集团在互联网上对外服务的窗口,与电话订票、代售点都是平级的,后端肯定还关联着很多复杂的业务系统,在没有对整个集团业务系统做扩容的前提下(短期内估计不能实现),可以将网站业务平台剥离出来,当然,完全剥离也不太实际,至少可以延长同步、一致性校验的时间。时间的长短随班次的发车时间成正比,因为大部分的用户都是提前一周以上就着手预定车票。
从百万级、到千万级并发PV的网站,在构架和部署方面会存在哪些差异?
百万PV到千万是一个级别的提升,设计得再好的架构也很难一步到位,也是随着业务的高速增长,不断积累经验、优化、改良的过程。12306的流量达到千万PV 级,但平台的支撑能力远远没有达到预期。
一个大型的高并发高性能网站架构需要从哪些层面去考虑?服务器/存储部署方面需要注意哪些问题?哪些技术能够保证整体系统的高并发与高性能?
设计一个大型高并发网站的架构,首先必须以了解业务特点作为出发点,架构的目的是支撑业务,需要考虑互联互通、负载均衡、网络、开发、缓存、存储、数据库等层面,这些层面看似一个整体,任何一个环节出问题都可能导致整个网站崩溃,所以一个高可用、高并发的平台还少不了监控、开发、运维等角色通力协作。
部署大型的高并发高性能网站架构需要注意哪些问题?存在哪些挑战?高峰期和低谷期的资源和投入如何平衡?
部署大型的高并发高性能网站架构需要注意整体的扩展性与健壮性,解决未来海量数据的存储与处理、密集的数据I/O、互联互通、应用的不断迭代、重构以及缓存机制等问题,对于考验一个成功的架构提出了更高的要求,也是未来面临最大的挑战。对于平衡高峰期和低谷期的资源投入,我想云计算的伸缩性更适合解决该问题。
有人建议使用云计算平台(类似于Amazon之类的)来搭建这类网站,以便提高资源利用率节省成本,您是如何看待的?
云计算是未来一个趋势,优点不多说,它具有动态伸缩、灵活性强等特点,可以让资源利用最大化,可以更好节约成本,非常适用于12306平台。
虚拟化(不局限于服务器虚拟化,也可以包括网络虚拟化等)在这类型大型高并发网站建设过程中可以起到什么作用?
虚拟化是云计算的基石,可以降低企业运营成本,提高资源利用率,个人建议将一些运算量及I/O要求不高的业务迁移到虚拟化,比如web、缓存、代理、中间件服务等应用。在低流量时段可以销毁节点,使物理实体机处于低功耗状态下运行,绿色环保,高峰来临时可以迅速部署上线来提供服务。
原文:http://server.it168.com/a2012/0208/1309/000001309060_all.shtml
受CU管理员的邀请参考“千万级pv高性能高并发网站架构与设计交流探讨帖”主题的交流,发表了一案例与大家分享。
一个支撑千万级PV的网站是非常考验一个架构是否成熟、健壮(本文不涉及软件架构的层面,有兴趣也可以讨论)。现抛出一个系统层面的架构,不保证是最优的方案,但也许适合你。理由是再优秀的架构都不具备通用性,需要根据每种应用特点针对性来设计。希望起到抛砖引玉的作用,大家多多参与,发表意见。
(点击放大)
架构说明:
1)架构中直接引入软件名称的模块,是个人推荐使用的,如Haproxy、Hadoop等;
2)关于全局负载均衡,看成本投入情况,可以使用商业的产品,如F5-GTM,开源方案便是自搭智能DNS;
3)本地负载均衡方案,可以考虑F5-LTM或成熟的开源解决方案LVS;
4)代理层为什么推荐大家使用Haproxy?Haproxy是一个非常优秀的反向代理软件,十分高效、稳定。国内top 10的互联网公司都有在使用;
5)缓存层可以使用Squid或Varnish,个人更倾向Varnish。配置灵活、运行稳定,提供非常便利的管理接口。为啥在缓存层前面加一层代理?优点非常多,列举如下:
- 根据应用配置URI路由规则,集中热点来提高后端缓存的命中率;
- 轻松划分网站频道、版块,更好对应用进步组织、规划;
- 对URI进行一般性安全过滤,抵御注入攻击;
- 弹性调配硬件资源,应对突发事件产生大流量;
- 可回收宝贵的公网IP资源;
6)应用层开源技术方案非常多且成熟,在此不详细描述;
7)数据库层主流开源解决方案Mysql是首选,主从复制(一主对多从)是目前比较靠谱的模式;
8)关于Nosql,应用场景不多说,可参考“给部门做的Mongodb技术交流PPT”文章,redis、memcached等作为热点数据存储、数据库缓存都非常理想;
9)内网DNS扮演的角色非常重要,一定要消灭code中出现的内网IP地址,很大程度减少因IP变更、服务器故障而修改源码的情况,同时也便于维护;
10)内网LB适用在内部WEB接口、多台数据库Slave、多台Nosql Slave、公共服务等应用的负载均衡,可以使用LVS、Haproxy来实现,可用性要求不高的应用可行直接使用Localhost DNS轮询;
11)hadoop适合海量数据的存储与处理,如做网站日志分析、用户数据挖掘等;
12)管理集群,平台的核心,运维的阵地;
以上粗略介绍了架构的几个组成部分,如大家有对哪块有疑问或感兴趣都可以展开来讨论,也可以通过weibo与我交流:http://t.qq.com/yorkoliu
书名:构建高可用Linux服务器
ISBN:9787111359423
作者:余洪春
定价:79.00元
出版时间:2011年10月
出版社:机械工业出版社 订书页面
编辑推荐:
基于实际生产环境,从Linux虚拟化、集群、服务器故障诊断与排除、系统安全性等多角度阐述构建高可用Linux服务器的最佳实践
资深Linux/Unix系统管理专家兼架构师多年一线工作经验结晶,51CTO和ChinaUnix等知名社区联袂推荐
内容简介:
资深Linux/Unix系统管理专家兼架构师多年一线工作经验结晶,51CTO和ChinaUnix等知名社区联袂推荐。结合实际生产环境,从Linux虚拟化、集群、服务器故障诊断与排除、系统安全性等多角度阐述构建高可用Linux服务器的最佳实践。本书实践性非常强,包含大量企业级的应用案例及相应的解决方案,读者可以直接用这些方案解决在实际工作中遇到的问题。
全书一共10章。第1章以作者的项目实践为基础,以RHEL和Centos为平台,有针对性地讲解了构建高性能Linux服务器的应该掌握的核心知识,包括硬件、网络配置、日志管理、性能优化、监控等重要内容;第2章十分详尽地讲解了FreeBSD8.1在企业中的部署与应用,这是目前第一手关于FreeBSD8.1的宝贵资料;第3章讲解了Linux服务器的虚拟化,主要包括VMware和XEN两大虚拟机在Windows Server 2003和Centos系统下的使用方法和工作原理,同时还介绍了Citrix XenServer的使用方法;第4章探讨了生产环境下各种棘手的服务器故障的诊断与排除方法;第5章介绍了生产环境下的SHELL脚本,这些脚本都经过实践验证,读者可以直接在实际工作中使用;第6章首先讲解了构建高可用Linux集群的理论知识,然后以作者的实际项目为例详细演示了构建高可用Linux集群环境的方法(附有项目施工图);最后还探讨了MySQL数据库性能优化方面的话题;第7章以理论与案例相结合的方式讲解了VPN在企业中的部署与应用,包括VPN技术的分类和选择、IPsec VPN的不足和OpenVPN的应用范畴、OpenVPN的部署案例和部署时的注意事项;第8章全面讲解了Linux防火墙及系统安全方面的内容,其中iptables相关的知识是重点,讲解非常详细,很多脚本都可以直接使用;第9章介绍了构建免费开源的企业级邮件系统的完整过程,这也来自于作者在实际工作中的实践;第10章针对系统管理员的学习、工作以及职业规划给出了一些宝贵的建议,对新人尤为有帮助。
RedBridge 是一款基于redis 的 HTTP API。 使用LUA 直接跟redis 交互。(类似数据库的存储过程) 高效的实现复杂的业务逻辑。
项目网址:http://code.google.com/p/redbridge/
使用环境:Linux 2.6
软件作者:七夜(李锦星)
RedBridge 具有以下特征:
1. 使用C+epoll 编写的Web Server,支持HTTP GET操作
2. 连接池,连接句柄复用,提高跟redis连接效率
3. 部分类库使用Redis的代码,更加的稳定
4. 使用LUA直接调用Redis命令,实现一次性数据交互实现 复杂的业务逻辑。不需要多次数据交互
5. 服务模型采用单进程,双线程模式
6. 配置文件采用Lua 语法, 容易读取和书写
7. RedBridge发布前,还没有类似的开源项目
项目网址:http://code.google.com/p/redbridge/
使用环境:Linux 2.6
软件作者:七夜(李锦星)
RedBridge 具有以下特征:
1. 使用C+epoll 编写的Web Server,支持HTTP GET操作
2. 连接池,连接句柄复用,提高跟redis连接效率
3. 部分类库使用Redis的代码,更加的稳定
4. 使用LUA直接调用Redis命令,实现一次性数据交互实现 复杂的业务逻辑。不需要多次数据交互
5. 服务模型采用单进程,双线程模式
6. 配置文件采用Lua 语法, 容易读取和书写
7. RedBridge发布前,还没有类似的开源项目
这个盛夏迎来你的480天
烈日炎炎,你给我们的小家带来一阵阵清凉
你成长的一点一滴都是我们热议的话题
你的发呆、欢笑、闹闹、好奇、大叫都那么轻易引起关注
每天你学会说不同的话
每天你在你的世界里都是那么的忙,搬玩具、拆家具、丢衣服、玩弄碗筷、戏水、摔手机... ...
每天带着疲惫的身躯回家,听到你响亮而清晰的一声-爸爸、妈妈
身上的疲惫仿佛已经烟消云散,袭来的是一股股暖流
同时,更多的还有责任
愿幸福、健康、快乐永远伴随你
在我们日常运维工作中,经常会碰到负载均衡器后端应用代码更新、临时剔除后端服务器、排查一主机应用故障等,往往我们会选择比较粗鲁的做法,直接停止或重启应用服务,让负载均衡器探测服务不可用将其剔除。这样带来的坏处是用户与服务器已经建立的连接会被中止,开发人员无法对已经停止服务的主机进行调试。现介绍一种较为温柔的做法,即通过禁用/启用成员的方式来达到目的。本文针对目前最为流行的负载均衡器逐一进行介绍。包括LVS、Haproxy、F5在命令行模式下的实现(方便与其它管理平台对接,实现自动化维护)。当然,Haproxy与F5都提供了人性化管理界面,不过只依赖手工来进行操作。
一、LVS负载均衡器
原理
使用LVS自带的管理工具来实现。
环境说明
Disable VIP:192.168.100.11:80
Disable REAL SERVER:192.168.100.78
实施步骤
1、初始状态
[devuser@lvsserver ~]# ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.100.11:80 rr persistent 60
-> 192.168.100.74:80 Route 3 462 464
-> 192.168.100.75:80 Route 3 420 440
-> 192.168.100.76:80 Route 3 431 400
-> 192.168.100.77:80 Route 3 430 432
-> 192.168.100.78:80 Route 3 435 438
2、禁用成员
[devuser@lvsserver ~]# ipvsadm -d -t 192.168.100.11:80 -r 192.168.100.78
3、当前状态
[devuser@lvsserver ~]# ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.100.11:80 rr persistent 60
-> 192.168.100.74:80 Route 3 462 464
-> 192.168.100.75:80 Route 3 420 440
-> 192.168.100.76:80 Route 3 431 400
-> 192.168.100.77:80 Route 3 430 432
4、启用成员
[devuser@lvsserver ~]#ipvsadm -a -t 192.168.100.11:80 -r 192.168.100.78
5、当前状态
[devuser@lvsserver ~]# ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.100.11:80 rr persistent 60
-> 192.168.100.74:80 Route 3 462 464
-> 192.168.100.75:80 Route 3 420 440
-> 192.168.100.76:80 Route 3 431 400
-> 192.168.100.77:80 Route 3 430 432
-> 192.168.100.78:80 Route 3 435 438
二、Haproxy负载均衡器
原理
使用Haproxy的socket admin通道来实现。
环境说明
Disable backend:test.tianya.cn
Disable REAL SERVER:192.168.100.78
实施步骤
1、修改haproxy.cfg配置
#vi /usr/local/haproxy/etc/haproxy.cfg
在global域添加socket admin支持并重启Haproxy服务
global
... ...
stats socket /usr/local/haproxy/HaproxySocket level admin
... ...
#service haproxy restart
2、安装socat(在任意的两个socket管道之间建立一个通道,在该通道中交换两端的数据。)
wget http://www.dest-unreach.org/socat/download/socat-2.0.0-b3.tar.gz
./configure --disable-fips
make;make install
注:disable OpenSSL FIPS support "--disable-fips",在没有安装fips包的情况下make时会提示:
FIPSLD_CC=gcc fipsld -O -D_GNU_SOURCE -Wall -Wno-parentheses -DHAVE_CONFIG_H -I. -I. -c -o socat.o socat.c
/bin/sh: fipsld: command not found
make: *** [socat.o] Error 127
3、禁用成员
#echo "disable server test.tianya.cn/192.168.100.78" | socat stdio /usr/local/haproxy/HaproxySocket

4、启用成员
#echo "enable server test.tianya.cn/192.168.100.78" | socat stdio /usr/local/haproxy/HaproxySocket

三、F5-LTM负载均衡器
一、LVS负载均衡器
原理
使用LVS自带的管理工具来实现。
环境说明
Disable VIP:192.168.100.11:80
Disable REAL SERVER:192.168.100.78
实施步骤
1、初始状态
[devuser@lvsserver ~]# ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.100.11:80 rr persistent 60
-> 192.168.100.74:80 Route 3 462 464
-> 192.168.100.75:80 Route 3 420 440
-> 192.168.100.76:80 Route 3 431 400
-> 192.168.100.77:80 Route 3 430 432
-> 192.168.100.78:80 Route 3 435 438
2、禁用成员
[devuser@lvsserver ~]# ipvsadm -d -t 192.168.100.11:80 -r 192.168.100.78
3、当前状态
[devuser@lvsserver ~]# ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.100.11:80 rr persistent 60
-> 192.168.100.74:80 Route 3 462 464
-> 192.168.100.75:80 Route 3 420 440
-> 192.168.100.76:80 Route 3 431 400
-> 192.168.100.77:80 Route 3 430 432
4、启用成员
[devuser@lvsserver ~]#ipvsadm -a -t 192.168.100.11:80 -r 192.168.100.78
5、当前状态
[devuser@lvsserver ~]# ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.100.11:80 rr persistent 60
-> 192.168.100.74:80 Route 3 462 464
-> 192.168.100.75:80 Route 3 420 440
-> 192.168.100.76:80 Route 3 431 400
-> 192.168.100.77:80 Route 3 430 432
-> 192.168.100.78:80 Route 3 435 438
二、Haproxy负载均衡器
原理
使用Haproxy的socket admin通道来实现。
环境说明
Disable backend:test.tianya.cn
Disable REAL SERVER:192.168.100.78
实施步骤
1、修改haproxy.cfg配置
#vi /usr/local/haproxy/etc/haproxy.cfg
在global域添加socket admin支持并重启Haproxy服务
global
... ...
stats socket /usr/local/haproxy/HaproxySocket level admin
... ...
2、安装socat(在任意的两个socket管道之间建立一个通道,在该通道中交换两端的数据。)
wget http://www.dest-unreach.org/socat/download/socat-2.0.0-b3.tar.gz
./configure --disable-fips
make;make install
注:disable OpenSSL FIPS support "--disable-fips",在没有安装fips包的情况下make时会提示:
FIPSLD_CC=gcc fipsld -O -D_GNU_SOURCE -Wall -Wno-parentheses -DHAVE_CONFIG_H -I. -I. -c -o socat.o socat.c
/bin/sh: fipsld: command not found
make: *** [socat.o] Error 127
3、禁用成员
#echo "disable server test.tianya.cn/192.168.100.78" | socat stdio /usr/local/haproxy/HaproxySocket
4、启用成员
#echo "enable server test.tianya.cn/192.168.100.78" | socat stdio /usr/local/haproxy/HaproxySocket
三、F5-LTM负载均衡器
受邀担任2011年海南省高职高专职业技能大赛“华汉” 杯网页设计与制作技能竞赛评委,此次竞赛有来自海南各高职院校的16支代表队48名选手参加,算是规格比较高的赛事。整理了大赛点滴与大家分享。
一、大赛宗旨
基于“发展网络文化,建立和谐校园”的宗旨,构建一个校园社交网站。目的是提供学生一个展示自我的平台,缓解学习和生活压力,帮助学生扩大社交网络圈子,为发展海南高校的校园文化做出贡献。
二、大赛要求
1. 网站提供学生登录、注册的功能。
2. 网页能动态提供校园新闻、网站公告、交友信息等内容的链接,用户可点击链接查看详情。(相关操作数据由组委会提供)
3. 网页提供学生个人主页、博客或微博等内容的链接。
4. 主页风格不限,但必须体现合理的布局和色彩搭配。
5. 恰当使用页面设计及动画、视频设计等技术,充实页面内容。
6. 原则上不提供图像和动画素材,若有需要须自行处理。
三、大赛留影

--评委聘书--
一、大赛宗旨
基于“发展网络文化,建立和谐校园”的宗旨,构建一个校园社交网站。目的是提供学生一个展示自我的平台,缓解学习和生活压力,帮助学生扩大社交网络圈子,为发展海南高校的校园文化做出贡献。
二、大赛要求
1. 网站提供学生登录、注册的功能。
2. 网页能动态提供校园新闻、网站公告、交友信息等内容的链接,用户可点击链接查看详情。(相关操作数据由组委会提供)
3. 网页提供学生个人主页、博客或微博等内容的链接。
4. 主页风格不限,但必须体现合理的布局和色彩搭配。
5. 恰当使用页面设计及动画、视频设计等技术,充实页面内容。
6. 原则上不提供图像和动画素材,若有需要须自行处理。
三、大赛留影
--评委聘书--






















