WEB应用

Haproxy进阶管理:命令行控制后端节点上下线

很多业务系统都用到了Haproxy这个高性能反向代理负载均衡器。在日常运维当中,Haproxy后端节点的上(接入)、下(剔除)线操作绝对是家常便饭,而且人工重启的时候经常有胆颤心惊的感觉。 下面分享一种命令行操作Haproxy后端节点平滑上下线的技巧。 一、新增配置 Haproxy自带了一个非常实用的管理页面,我们可以在harpxoy.cfg新增如下配置,开启Haproxy监控管理页面功能: 配置后,重启Haproxy,访问 http://ipaddress:8080/admin,使用admin/admin登陆之后就能看到管理页面了: 二、管理功能 因为我们还配置了管理功能,所以在各个backend都能看到如下管理功能: 我们在左侧勾选好对应的后端节点,选择需要转换的状态点击Apply就能完成后端节点的状态切换。 三、平滑发布 对于平滑发布来说,这里用得比较多的2个选项是READY(就绪状态)和MAINT(维护状态)。 READY 表示被勾选的节点已经完成维护,Apply进入就绪状态后,Haproxy会自动发起健康检查,如果检查通过,这些节点将进入映射状态,接受映射请求了。 MAINT 表示被勾选的节点需要进行维护,Apply进入维护状态后,Haproxy将会停止往这些节点转发请求,并等待已有的请求结束连接。 通过这个功能,我们就能对业务进行从容发布了,比如我们有一个业务有2个节点,我们可以先将其中一个节点改为MAINT状态,刷新Haproxy管理页面,当看到Session里面的Cur(当前连接)为0个时,我们就可以从容的对这个节点进行发布、重启等维护操作,完成维护后我们在将这个节点改为READY状态即可。接着,我们同样操作剩下节点即可(节点剔除后带来的性能下降问题,这里就不展开了讨论了)。 四、命令行操作 很明显,这个功能非常实用,但是并不方便,因为需要手工操作,没法嵌入到自动化发布流程当中。不过通过分析POST请求,可以得出curl命令行操作方法: s 表示后端标签名 action 表示状态 b 表示backend标签名 通过测试,得出curl发起请求格式如下: 比如,如果Haproxy有一个后端如下配置: 那么,业务系统发布之前,我们将192.168.1.1这个节点改为维护状态,则如下发起请求即可: Ps:要注意的是,这个POST参数必须URL转码,比如存在冒号【:】,需要转换为 %3A才行。 业务系统发布之后,我们再发起node1上线请求: 后面我们只需要重复操作node2节点的上下线即可完成无损发布了。这一整套动作就可以整合到自动化发布流程当中,不再需要人工介入。 五、小结 本文介绍了Haproxy开启管理功能的配置方法以及命令行操作后端上下线的技巧,为程序平滑部署、系统自动化运维提供了一种更加简单的解决方案。 拓展:在复杂的业务场景中,可能用到了etcd+confd + haproxy的统一配置管理方案,原理是通过更改Haproxy配置,然后热重启Haproxy(-st 指令)来上下线节点,是非常不错的方案!不过,根据我个人经验,在高频业务场景中,剔除后端节点再热重启Haproxy,可能出现业务请求异常问题。
阅读全文
WEB应用

Haproxy安装部署文档及多配置文件管理方案

最近我在负责一个统一接入层的建设项目,涉及到Haproxy和ospf的运维部署,本文分享一下我在部署Haproxy之后整理的运维部署规范,并实现了Haproxy的多配置文件管理方案。 一、部署安装 1、下载源码包 最新stable版本下载地址:http://www.haproxy.org/download/1.7/src/haproxy-1.7.9.tar.gz 2、编译安装 3、创建目录 二、软件配置 熟悉Nginx和Apache的朋友都知道,这两个Webservice都支持include加载多个配置文件的语法,但是Haproxy并不支持!如果现网映射规则非常多,那么haproxy.cfg这个配置文件就跟臭袜子一样,又臭又长! 因此,我也是翻遍了国外的各种论坛帖子,终于发现一种变相实现Haproxy多配置文件的方案。其实,Hparoxy是支持多配置文件的,但是不是include语法,而是在启动的时候多次使用-f 拼接配置文件,比如: 因此,我们可以在配置文件目录以及启动脚本上做点改变,让Haproxy支持多配置文件。 1、路径约定: 待上线的 tcp 映射规则存放目录:/usr/local/haproxy/conf/ready/tcp 待上线的 http 映射规则存放目录:/usr/local/haproxy/conf/ready/http 已上线的 tcp 映射规则存放目录:/usr/local/haproxy/conf/enabled/tcp 已上线的 http 映射规则存放目录:/usr/local/haproxy/conf/enabled/http Ps:本文为多配置模式,enabled 里面的配置为软链接形式,软链接至ready对应配置文件,方便管理。 2、配置模板 ①、主配置:haproxy.cfg ②、http 扩展配置文件模板 ③、tcp 扩展配置文件模板 Ps:多配置模式中,多个frontend必须绑定不同的IP或者端口,否则数据会串,导致映射到不同的后端而报错。因此,同一个IP+端口下的映射务必配置到同一个frontend模块内。 三、系统服务 1、服务脚本 对比已有的Haproxy脚本,我编写的时候新增了如下实用功能: 支持配置文件语法测试 支持进程的监控(自拉起)功能 重启之前会先检测配置语法,规避因配置错误导致重启后进程挂掉 支持多配置文件模式(按照前文约定目录存放拓展配置,脚本将自动识别) 下面是服务脚本代码: 保存为 /usr/local/haproxy/sbin/ctrl.sh,赋可执行权限,如下注册系统服务: 服务控制: 2、配置自拉起 全部完成后,最终目录结构如下: 四、日志配置 配置rsyslog 五、小结 以上内容就是我对Haproxy部署规范的整理,并通过拼接方式变相实现了Haproxy的多配置文件管理。当然,略遗憾的是未能实现Haproxy的WEB管理方案,这个有待继续研究实现,敬请期待!
阅读全文
WEB应用

libmemcached编译安装报错解决记录

我负责的几个公司内部网站,仅集成了php原生memcache组件,不支持memcached分片存储的自动容灾方案,近期出现过几例因memcache服务器故障引起WEB爆卡的尴尬事,所以接到了一个给现网php集成memcached模块的需求。 内部的个别系统有多老、多难用我就不吐槽了,slackware、suse用过的人都知道。。。不说了,总之老老实实的编译安装吧。 memcached这个php模块依赖于libmemcached,所以集成前先要编译安装libmemcached。 按照常规编译方法,对libmemcached进行编译安装,结果如下报错: error: cinttypes: No such file or directory 查了下资料,发现是因为gcc版本过低,看了下系统当前的gcc版本,是4.1.2,决定升级之。 简单记录下gcc编译过程: 1、安装gmp 2、安装mpfr 4、安装mpc 5、安装gcc 对于这种老掉牙的服务器、程序,编译安装gcc的时候也不敢直接全局覆盖安装(编译不指定路径),于是将gcc-4.5.1安装到/usr/local/gcc-4.5.1 Ps:更多可选参数请参考官方文档。gcc编译安装必须注意依赖包的顺序,可谓环环相扣。 编译安装后,由于是指定的安装路径,所以系统用的依然是原来的gcc,所以为了本次编译libmemcached,需要将新版本软链过去,暂时使用(简单方案) 进入libmemcached源码目录继续编译,结果如下报错: error: bits/c++0x_warning.h: No such file or directory error: cstdint: No such file or directory error: tr1_impl/cinttypes: No such file or directory 真是醉人,明明都升级了还报错!没办法,继续耐着性子看信息,发现libmemcached在configure之后有如下统计信息: 赫然发现了图中还有个c++显示是4.1.2的老版本!!!于是,原来把c++给漏了,顺手补之: 再去编译安装,就行云流水,再无报错!后面编译memcached就不多说了,不会的可以参考前文教程。最后,记得取消gcc和c++的软链接,还原到4.1.2版本即可(当然,若无异常也可以继续保留)。
阅读全文
WEB应用

修改Apache的超时设置,解决长连接请求超时问题

某日,组内后台开发找到我,问我们的WEB服务器超时设置是多少。他反馈的问题是,有一个VLAN切换任务cgi接口经常返回504网关超时错误,要我分析解决下。 我问了一下,得知这个请求遇到网络设备对象较多的时候,需要小半个小时才能完成,也就是要用到长连接才行。 老规矩,从开发那拿到接口地址,得到接入层服务器IP,是一台Haproxy代理,看了一下Haproxy的超时设置: 各种1小时超时,所以排除Haproxy的影响,继续往下看。 Haproxy 代理的是2台Apache,也就是部署了cgi接口的服务器。第一时间查看了 httpd.conf 和 httpd-vhost.conf 中的配置,居然没找到超时设置。 于是,搜索了下相关教程,发现原来藏在了 httpd-default.conf 当中: 看了下,这些是Apache的默认配置,Apache也没有include到httpd.conf当中。因此,编辑 httpd.conf,找到如下参数: 去掉注释,保存文件。然后再编辑 /usr/local/apache2/conf/extra/httpd-default.conf 文件,将Timeout的值修改为符合生产环境要求的1800秒,最后执行Apache平滑重启命令即可: Ps:我之前一直以为只有Nginx有一个平滑reload命令,后面才知道Apache、Haproxy都支持平滑重启名称,这个非常棒! 重载之后,就不会出现504网关超时设置了。
阅读全文
网站建设

WordPress集成PHP缩略图,并开启Nginx缓存的方法

之前张戈博客分享过一篇给 WordPress 开启 Nginx 缩略图的教程,用着确实不错!但是总感觉清晰度不敢恭维,就算将裁剪质量调到90依然失真严重,于是想另辟蹊径。 想起之前帮一个站长做CC防御的时候,发现他的网站就算被纯静态化,被攻击时CPU依然狂飙。最后分析请求日志发现,所有的压力来自网站的 PHP 缩略图功能。这个 PHP 缩略图虽然可以将实时生成的图片缓存成文件,但是第二次被请求,PHP 依然需要进行一些很简单的判断,比如这个缩略图是否被缓存、缓存文件是否过期等。在海量IP的请求下,这些简单的PHP动态判断就成为了拖沓大户了! 这也就不难理解 WP-Super-Cache 的 php 缓存模式比 Mod_Rewrite 模式要慢的原因了!所以,静态缓存最终都要完全抛弃掉任何简单计算才能算是淋漓尽致! 好了,扯得有点远了。虽然这位站长同学后来抛弃了这个 PHP 缩略图功能,但是张戈却记忆深刻。当  Nginx 缩略图不给力时,我第一时间就想到了它。 这玩意在访问量过大时是个拖沓大户,但如果我想办法去掉其中的 PHP 动态判断呢?自然就能发挥到淋漓尽致了! 下面简单分享下张戈的做法。 一、加速思路 我顺藤摸瓜(之前那位站长朋友用的就是倡萌的 Wdone 主题),自然就在倡萌那找到了这个 PHP 缩略图的使用方法: 可以看到,这种传参肯定是存在动态判断的,所以要完全静态化,我首先就要修改这个缩略图形式。 很简单,延续之前分享的 Nginx 缩略图思路,把上面的 url 改成在图片地址最后带参数的模式,然后伪静态重写为上面的形式,最后通过 Nginx 实现纯静态缓存。 二、部署方法 ①、PHP代码 下载后解压得到 thumb 文件夹,编辑里面的 timthumb-config.php,按照注释修改下(可选)。 然后将整个文件夹上传到网站根目录,现在按照倡萌给出的 url 形式肯定就可以看到缩略图了。 ②、Nginx规则 第①步能够正常看到缩略图效果后,我们接着部署Nginx规则。 在网站原有的Nginx规则中插入如下规则: 这样还只是重写了缩略图的 URL 形式,如果需要开启缓存,则需要用到 Nginx 的 fastcgi 缓存,还不熟悉的朋友请先参考张戈博客之前的分享: 《Nginx开启fastcgi_cache缓存加速,支持html伪静态页面》 按照之前的文章部署 fastcgi 缓存规则后,这个缩略图就被 Nginx 缓存了(在F12开发者模式中查看network头部信息即可看到 HIT from yourdomain.com),加载速度自然也就上来了! 三、主题修改 做完上述操作之后,还只是具备了这个缩略图功能,而实际应用到博客文章,总不能手工一个一个输入图片带上尺寸吧?而且还有一堆老文章也不可能人工修改一遍吧? 实际解决很简单,请参考如下代码: 修改原理: ①、将老文章中带尺寸的图片改成完整图片路径,我之前用的是300大小的图片缩略图,所以这里需要将高或宽300的全部去掉,变成完整尺寸图片路径; ②、最后将文章中所有图片路径上带上适合本文分享的尺寸规则,比如上述代码是?w=480,即图片缩略图统一改为480px大小。 好了,就分享这么多,有需求的朋友可以参考上面的代码,根据实际情况修改后加入到主题functions.php即可完美实现文章缩略图了。
阅读全文
WEB应用

php平滑重启nginx,彻底清除WordPress的静态缓存

每一次分享技术文章,都是基于自己的痛点,基于自己的需求。这次也一样,所以分享具体方法之前,我先说一下我这次的需求与痛点: 一、需求痛点 在博客集成了代码版缓存功能之后,为了方便在前台清理页面缓存,我特意写了ajax清理缓存的功能(相关文章)。这个功能写好之后确实可以正常工作。 但是,为了让网站加载速度提升到极致,我还在nginx里面加了类似于WP Super Cache的mod_rewrite机制:当存在页面缓存时,会绕过PHP解析,而直接调取缓存在前台展示。 这样就发现了一个问题:当我在前台点击缓存清理后,后台的页面缓存文件确实是删除了,但是nginx却在内存里面缓存了一份!!从而导致一段时间内怎么刷新页面,展示的依然是缓存内容!这样一来,不管是我还是用户,点击前台这个清理按钮根本就不能实时看到效果,明显就鸡肋了! 我发现这个问题的做法是,点击按钮删除缓存,然后进入Linux系统去reload一下nginx,才能彻底刷新缓存!我勒个去,每次我调试代码的时候,真心能把人累死(虽然我可以关闭缓存功能,但是我就是要享受一下自己写的清理功能嘛!)。 需求都有了,怎能让技术成为瓶颈? 所以,根据以上需求,很容易得出一个解决方案:当点击前台清理按钮时,php先删除缓存文件,然后reload平滑重启nginx就可以实现彻底清除缓存了! 测试了半天,发现难点是php如何才能执行Linux命令。经过不断测试,终于搞定这个问题,下面开始分享! 二、执行权限 php执行Linux命令有几个前提条件: ①、php必须开放一些执行外部命令的函数,比如exec()、system()等; ②、必须赋予WEB启动帐号(比如www帐号)执行特殊命令(比如 .../nginx -s reload)的权限。 对于问题 ①: i. 修改php配置文件php.ini,先找到safe_mode配置,确认safe_mode=off,即关闭php安全模式(lnmp一键安装包默认已经是关闭的了); ii. 继续找到disable_functions配置,将其中的 exec 删除,即允许执行exec()函数; ii. 最后重载php-fpm或php即可生效,比如lnmp环境可以执行 service php-fpm reload命令。 Ps:开启exec函数存在被恶意注入的风险,不过我这种小博客就没什么好惧怕的,况且我的备份及防护都很完善! 对于问题②: 我们需要在Linux中赋予WEB帐号使用sudo执行指定命令的权限,在这个需求中,我们可以这样做: Ps:操作vim需要一定的Linux基础知识,不会的童鞋先脑补一下吧! 三、部署代码 ①、新增平滑重启nginx的脚本 ②、PHP代码 php执行这个脚本的代码很简单: Ps:实际上,使用 exec(/opt/reload_nginx.sh"") ; 也是完全可以的。多套了一层EscapeShellCmd是为了安全考虑(其实这里貌似没啥必要,算是掩耳盗铃吧!)。 既然知道php代码了,那么只要修改上次分享的缓存清理代码,如下新增26行和33行即可: Ps:若对以上代码有任何疑问,请务必参考上一篇相关文章。 全部完成之后,现在在前台使用缓存清理功能,将会先删除缓存文件,然后平滑重启nginx,从而真正实现在纯静态的前台实时清理缓存,显示最新内容! 四、写在最后 这篇教程算是我这种强迫症&发骚友学习实验之作,而且整个教程并未过多考虑安全问题。所以,如果不是和我这种既不在意被人攻击,又清楚个中原理的人,还是不建议做这种强迫症设置(实际上也就是解禁了exec函数存在隐患而已)! 总之,这篇文章分享的方案,还是有一定的参考价值的,根据本文思路,就可以实现在WEB界面任意操作服务器了,其实也就和大部分站长用的Linux系统面板差不多,希望能给有需要的人提供一些参考,有任何相关问题记得给我留言。
阅读全文