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管理方案,这个有待继续研究实现,敬请期待!
阅读全文
好文推荐

企业互联网+转型实战:如何进行PB级别数据的架构变迁

随着DT时代的来临,数据对于企业经营决策的价值日益凸显,而企业在进行互联网+转型的过程中,如何让数据架构平滑迁移到大数据平台,对于传统业务的转型升级至关重要。企业IT部门该如何进行PB级别大数据平台的迁移规划呢,请看云智慧运维总监张克琛带来的经验分享。 提到PB级别的大数据解决方案市面上有很多,比较火的有Hadoop、Spark、Kafka等等,如果是一个新上线的系统,相信大家都能找到适合自己的方案。但“大数据”在09年才逐渐成为互联网信息技术的流行词汇,一个较老的系统如何平滑迁移到PB级数据架构呢? 云智慧的第一款产品监控宝是08年启动的,在设计之初缓存使用的是Redis, 数据库使用的是MySQL,随着业务的高速发展和全球分布式监控点的陆续建立,数据量也从开始的GB级迅速发展到PB级,大数据成为必然的选择。面对PB级别数据存储,云智慧一路走来也踩过很多坑,下面就给大家分享一下监控宝系统架构变迁的几个比较重要的点。 一、Redis的扩展 我们面临的第一个的问题是Redis的扩展,Redis进程无法使用多核,云智慧监控宝当时的Redis进程并发1.5W,单core  CPU占用率95%,偶发会达到100%,监控宝的任务调度会出现延迟现象,我们做了三套方案: 方案1:改程序逻辑,基于任务ID的一致性hash支持Redis多实例,但由于研发忙于产品功能,没空修改,此方案只能放弃; 方案2:Redis Cluster,看到官方架构图,我就直接将此方案放弃了。监控宝有大量的写操作,如果每个点都同步写操作,理论上瓶颈无法解决,不适合我们的使用场景,而且生产环境用这个的好像也不多。 方案3:Codis, Twemproxy. 最终我们选择了Codis,目前线上稳定运行一年多,从未出现任何问题。QPS 已经达到每秒15万次。整个架构每一层都支持扩展,并且无单点,架构图如下: Codis有很多优点,而我们选择的理由如下: 平滑迁移:Codis提供了迁移工具,比较容易操作。我们生产环境已经验证,从redis迁到codis 对业务影响为0,不过redis有些命令是不支持的,迁移之前还是要仔细读下codis的文档,是否适合自己的生产环境。 扩展容易:Codis将数据默认分了1024个slot,看到这个当时就很开心,以后基本不用担心数据量的问题了。理论上是可以扩展到1024个redis实例,扩展的时候先把新的redis实例加入到集群中,再将部分slot迁移至新的实例中就可以了,包括后面将要提到的Mycat 2.0 也会采用这种设计。 友好的管理页面:扩展的操作直接就可以通过管理页面做了。 下面是迁移管理图: 而上面这几点Twemproxy是不具备的,Codis唯一的缺点就是稍稍复杂一些,入门的时候稍需要多花些时间,但相比其优点这些都微不足道了。 二、使用MySQL处理PB级别的数据存储 我们面临的第二个问题是PB级别的数据存储,就拿监控宝的网站监控功能来说,云智慧在全球分布有200+个监测点,这些监测点按用户设置的频率访问指定的网站页面,监测数据传到我们的数据中心。这个服务目前有30多万用户在使用,平均数据日增量在1TB以上。 这部分数据类似于日志数据,使用MySQL来存这些数据并不是什么高大上的做法,如果大家使用过ELK的话,会推荐我们使用elasticsearch来存储这些日志数据吧。的确是这样,我们的新产品透视宝、压测宝都在用elasticsearch,也用到了hadoop、spark、suro、kafka、druid等大数据相关的框架应用,直接使用文件来存储也是可以的。 但老系统的问题必须要解决。 使用MySQL做大量数据存储很容易就想到分库分表,提到分库分表自然就会想到MySQL的中间件,大家在网站可以查到一些常用的分库分表的中间件,包括大家比较熟悉的Atlas、Mycat(cobar)、TDDL 、HEISENBERG、OCEANUS、VITESS、ONEPORXY、DRDS 等,先不谈这些中间件之间的区别,他们共有一个特性,只能在一个维度上对数据进行拆分或者说只能对数据进行一次拆分。 切分数据库分为垂直切分和水平切分,先介绍一个比较简单的垂直切分场景: 有几个数据库在同一个MySQL实例中,但因数据库A 的IO相对较高,希望将其单独拉到另外一台服务器上,又不想让研发改动代码。 以前一直以为Mycat只能做水平切分,其实也可以垂直切分,很实用,配置也很简单,因各种原因希望将原来一个MySQL实例中的多个库分布到多个实例中,直接使用Mycat就可以做到,对应用程序来看还是同一个实例,在拆分过程可以通过主从同步实现平滑迁移。 接下来介绍水平切分,水平切分是指将某个表按照某个字段的某种规则来分散到多个表之中,每个表中包含一部分数据。 常用的根据主键或非主键的分片规则: 1、枚举法: 比如数据是按照地区省份来保存的,用户通过多级别划分的,本规则适用于这些特定的场景。 2、求模: 如果分片字段为数字,对分片字段进行十进制/百进制求模运算,数据可以均匀落在各分片内。也见过网友分享的对字符串hash取模,支持存在符号字母的字段的分片。 3、范围约定 对分片字段约定一个范围,比如ID 100001~200000为一个分片,ID 200001~300000为一个分片 4、按日期 可以按月,按天,按小时分片 5、一致性hash 一致性hash算法有效解决了分布式数据的扩容问题。这个大家可以查下具体的算法实现。 以上是常用的几种方式,也有一些分片方式是根据上面5种变化得来,比如对日期字段hash再分片的。 单独使用一种分片规则是很难支撑大量数据的存储,哪怕使用一致性hash在生产环境中也是很麻烦的事情,光是数据迁移就是一件让运维头疼的事了,这时候我们需同时采用垂直分片和水平分片,甚至多次水平分片,下面聊一下我们在实际生产中如何使用这些分片规则的。 以监控宝API监控为例,先介绍下应用场景,现在我们手机里安装的是各种APP,其架构中必然存在大量的API,我们的用户不但要监控单个API请求,还要监控连续请求构成的事务, 监控宝API监控的正确性是以断言来判断的,每个监测点都会对用户的API做出请求,请求数据及断言的结果都将被存储到数据中心。 我们借助于cobar, 对数据做了两次分片,分片逻辑图如下: a、 首先我们是通过cobar ,采用枚举法按监测点ID对DB这层进行了数据分片,这样做的话物理上同一个监测点的数据在一起,业务上也是好理解的。 b、在程序逻辑中按天对表进行了分片。每天都会有脚本将一月之内的表都创建好。 从上图中大家可以看到,这里扩展上是存在问题的。我们一共有200多个监测点,在第一阶段,数据量没有那么大的时候,为了节约成本,我们仅使用了10台机器做存储,一台机器存有多个监测点的数据。 随着数据量增大,发展到第二阶段,当某台机器硬盘快存满的时候,我需要将一些监测点的数据迁移至新增进集群的机器中,按这个架构,最多我们可以扩展到200+台机器。 在生产环境中用户对北上广的监测点是最有兴趣的,所以这些监测点的数据量是最大的。 这样就会发展到第三阶段,部分监测点的数据量大到单台机器的硬盘存不下了。 这时候如何解决问题呢,我们来分析一下数据,单个数据库中是按日期来分表的,而大于3个月的历史数据较少有人查询,用户也可以接受历史数据查询时间稍长一些,于是我们选用了TokuDB来压缩历史数据,基本上1T的数据压缩之后在100G左右。1:10的压缩例,即使这样,理论上最多也只能存储4P左右的数据(数据放在UCLOUD上,云主机支持的最大硬盘为2T)。 我们在网站监控的数据分库中解决了这个问题,逻辑图如下,我们从4个维度对数据进行了分片 1、按日期为第一维度对数据库分片,必须按日期做第一次分片,并且分片时间点可以在配置文件中自定义。 2、按监测点ID为第二维度对数据库分片 3、按实际分片数量对任务ID动态取模为第三维度对数据库分片 4、对任务ID 100取模为第四维度对数据表分片。 创建后的数据库类名似于db-201501-monitor01-01、 db-201501-monitor01-02 ……  每个库是有100张表。这样可以的好处: 1、冷热数据自然分离 2、可以根据日期无限次分片 3、在同一个时间段里实际分片数可以自定义。理论上可以无限次分片。每次分片服务器的数量是可控的,并且下次分片的时间也变的可预期。可以在最大程度是节约成本。 4、数据无需迁移我 细心的同学会发现这样对数据分片造成一个小问题,我们对任务ID做了两次取模,会造成部分实例中的某些表中数据是空的,不过并不影响应用。 以上就是云智慧在过去几年里从传统数据架构向大数据迁移过程中的一些经验,希望为大家的数据架构迁移提供参考。
阅读全文
资源分享

GOPS2016全球运维大会•深圳站自动化、云计算、老王专场精彩PPT分享

GOPS全球运维大会是什么,我就不多说了,相信干运维这行的朋友都有所耳闻。 最近,GOPS在深圳站举行了盛大的运维大会,遗憾的是我没有翘班去现场沐浴一下各类运维大牛的指导。不过“高效运维”微信公众号把深圳站相关PPT都整理分享了出来,张戈博客在这就当一次搬运工,在博客转发分享下,希望运维同行能有所收获! 当然,大家可以微信关注“高效运维”公众号获得更多学习知识! 2016年3月31日,已补全深圳站所有精彩PPT!  
阅读全文
WEB应用

php5编译安装常见错误和解决办法集锦

最近在给开发同事折腾开发测试环境,其中就有php的编译安装。由于每个人的需求不一致,所以也接触到了各种模块编译和集成,中间不乏各种编译依赖报错。 正好,搜了几次都是下面2篇文章内容,干脆就转到自己博客,以备后用,后续有相关内容再继续补充。   checking for BZip2 support… yes checking for BZip2 in default path… not found configure: error: Please reinstall the BZip2 distribution 解决办法:yum install bzip2-devel checking for cURL support… yes checking if we should use cURL for url streams… no checking for cURL in default path… not found configure: error: Please reinstall the libcurl distribution – easy.h should be in/include/curl/ 解决办法: yum install curl-devel   checking for curl_multi_strerror in -lcurl… yes checking for QDBM support… no checking for GDBM support… no checking for NDBM support… no configure: error: DBA: Could not find necessary header file(s). 解决办法: yum install db4-devel...
阅读全文
脚本编程

zabbix agentd客户端插件Shell一键自动安装脚本

这次生产环境上线了多台Linux服务器,需要全部纳入Zabbix监控范畴,一台一台的去装Zabbix Agentd插件那就太苦逼了,所幸Zabbix客户端插件是支持绿色安装的,就写了个简单的一键安装脚本,然后配合 Secure CRT 的多窗口交互命令一次性就可以搞定了。 正常启动Zabbix客户端服务其实只需要2个文件: zabbix_agentd 和 zabbix_agentd.conf,需要特别说明的是:zabbix_agentd 最好是和 Zabbix_Server 一同编译所得,保证版本和配置文件的路径是一致的,否则可能无法使用Linux系统的 service 服务启动模式。 一、准备工作 Zabbix 主机肯定搭建了WEB服务,所以正好可以将所需放置到WEB目录,方便下载。 客户端插件 zabbix_agentd 位于 Zabbix 安装目录下的 sbin 目录,比如:/usr/local/zabbix/sbin/zabbix_agentd 服务控制脚本 zabbix_agentd 位于 zabbix 源码编译目录下的 misc/init.d/fedora/core/zabbix_agentd 我们要做的就是将这些文件拷贝到 WEB目录即可,比如 /var/www/html/zabbix_agent/ ,根据系统版本的不同,我们可以准备64和32位的 zabbix_agentd,方便后续不同系统下的安装。 拷贝后,手工验证下文件是否可以下载: 客户端插件:http://192.168.1.40/zabbix_agent/64/zabbix_agentd 服务控制脚本:http://192.168.1.40/zabbix_agent/init.d/zabbix_agentd 二、编写脚本 ①、将以下代码保存为 zabbix_agentd.sh ,上传到第一步中的 zabbix_agent 目录。 ②、Service 服务控制脚本 为了方便没找到 zabbix agent 服务控制脚本的朋友,额外提供服务控制代码。将代码保存为zabbix_agentd,上传到第一步的 zabbixz_agent/init.d/ 目录备用。 三、使用方法 登录到客户端系统,运行如下命令即可一键安装: ①、使用默认 zabbix_server 的IP地址: ②、后面添加IP参数可指定到其他 zabbix_server 或 zabbix_proxy: Secure CRT多会话交互执行: 其他说明:此脚本中的 zabbix_agentd 编译路径(prefix)为 /usr/local/zabbix,如果编译的时候不是这个路径,则需要根据实际情况修改脚本里面相关路径,否则注册的zabbix_agentd服务将无法启动,就只能通过命令行启动了!
阅读全文