mysql+mycat压力测试一例 |
您所在的位置：网站首页 › sysbench原理 › mysql+mycat压力测试一例 |
mysql+mycat压力测试一例
|
前言 Mycat是业内知名mysql数据库中间件,其功能在各种mysql中间件中是比较丰富的.而mycat相关组件由java语言编写,部署方便.他的功能有:不透明代理,读写分离,负载均衡,数据分片等.而且因为其底层连接方式是用java的jdbc组件来连接数据库的,所以理论上是支持sql server,oracle,pgsql的,但是功能上主要集中在mysql上. 优点:部署简单,功能强大,灵活性高,弥补mysql的一些功能缺失 缺点:功能开发不算十分完善,需要注意踩坑 如果按原理来说,mycat如果不做分片,纯粹只是代理的话,他所做的事情,其实更多的是数据转发,而这个转发能力,当然就是看他能有多强. 既然理论上转发能力很强,那么是不是就可以忽略不计呢,当然不是,所以需要用直连mysql的测试数据来做对比. 测试前准备 服务器配置为32核cpu(虚拟化后的数值,算上超线程),120G内存,16000iops的存储设备,具体分配情况: 10.21.128.156:mycat1.6.5,sysbench0.4 10.21.128.157:mysql5.7.20主库 10.21.128.158:mysql5.7.20从库1 10.21.128.159:mysql5.7.20从库2 简单说明拓扑关系:
第一步当然是安装好mysql,这里就不详细介绍怎么安装了,但是,my.cnf的参数是有些变化的,主要原因是要适应高并发压测环境,不然就被参数限制,然后程序退出.当然了,如果你想尽量模拟线上环境,那这些限制你得思考在内,更改就需要谨慎一些,我这里只是给出一例来参考. #首先,就是要把系统的连接数和打开文件数搞起来 ulimit -SHn 65535 #想永久生效就要这样 echo " * soft nofile 65535 * hard nofile 65535 root soft nofile 65535 root hard nofile 65535 " >> /etc/security/limits.conf然后,更改mysql配置文件参数,其他buffer_pool什么的就不列出来了,请各自看情况设置,这里只说明涉及压测相关的参数. #打开配置文件 vim /usr/local/mysql/my.cnf #其他参数我们暂时忽略,只看这些关乎压测的参数 [mysqld] #每台机都需要不一样的ID,主从环境下 server-id = 128157 #全局最大打开文件数,不可以超过系统设定的最大文件数,不然无效 open_files_limit = 65530 #innodb引擎限制一次打开表空间文件.ibd的文件描述符数量 innodb_open_files = 65530 #允许存到缓存里的表的句柄数量,压测自然要打开很多表,设大一点就对了,受系统limit和上面两个参数一起限制 table_open_cache = 65000 #实例可用最大连接数,必须设置足够大,不然连接数超出限制,测着报错不通就麻烦了,最少也比你实际要用到的多三分一 max_connections=30000 #最大每用户连接数,限制每个用户最大连接数,一定要比上面少一点 max_user_connections=20000 #最大数据包大小,做压测改大一点还是有必要 max_allowed_packet = 128M #限制了同一时间在mysqld上所有session中prepared 语句的上限,平时不用理这个参数,但是压测就需要调大一点 max_prepared_stmt_count=100000其他参数我就不一一列举,自己看情况来设置就行,然后,重启生效待命. 软件安装 先说说压测工具的选择问题,在MySQL协议上Mycat不兼容tpcc，所以放弃tpcc。然后sysbench1.0对mycat兼容也比较欠佳,不明原因压测失败次数多,所以也只能放弃. 最后选定sysbench0.4和0.5来使用,可以顺利测出结果,而且从压测的原理来说也比较客观. 所以,我们需要安装的软件有:mysql(默认已装),mycat,sysbench0.4或0.5 mysql怎么安装和授权什么的,这里就不细说了,还请各位自己搭建好,配置文件就上面提到的要加上一下. 安装mycat: 1)搭建jdk环境 由于mycat是java程序,所以需要安装JDK,版本至少要jdk1.6以上, 下载java语言程序包, Java的下载地址一直在变,所以最好自己上去看着来下载 http://download.oracle.com/otn-pub/java/jdk/8u151-b12/e758a0de34e24606bca991d704f6dcbf/jdk-8u151-linux-x64.tar.gz?AuthParam=1513326216_bcf60226458d67751e1d8d1bbe6689b4 #下载好安装包后,解压创建软连接 tar xf jdk-8u144-linux-x64.tar.gz mv jdk1.8.0_144/ /usr/local/ ln -sf jdk1.8.0_144/ jdk #创建环境变量 vim /etc/profile.d/java.sh export JAVA_HOME=/usr/local/jdk export JRE_HOME=/usr/local/jdk/jre export CLASSPATH=.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar:$JRE_HOME/lib export PATH=$PATH:$JAVA_HOME/bin #重载环境变量 source /etc/profile #验证安装 java -version java version "1.8.0_144" Java(TM) SE Runtime Environment (build 1.8.0_144-b01) Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)安装完成,可以使用.
2)安装配置mycat 了解java程序的同学应该知道,java程序只要配置好,直接启动就能用,所以没有安装的概念,直接将mycat配置做好就可以用. 我们下载mycat1.6.5的版本,这是最新正式版 http://dl.mycat.io/1.6.5/Mycat-server-1.6.5-release-20180122220033-linux.tar.gz #解压安装包 tar xf Mycat-server-1.6.5-release-20180122220033-linux.tar.gz #移到目的位置 mv mycat1.6.5 /usr/local/ #创建软连接 ln -sf mycat1.6.5/ mycat #把命令也做软连接 ln -sf /usr/local/mycat/bin/* /usr/bin/然后就可以开始改配置文件了 这里sysbench的测试没有涉及分库分表,所以mycat只需要设置server.xml和schema.xml即可,具体mycat存放路径没规定,我将他放在/usr/local了. ==============================分割线开始============================== 有的人可能会疑惑,mycat支持分库分表,那么压测可不可以针对分库分表进行呢?其实理论上是可行的,有意向做分库分表压测的就要把数据做一些处理,按照sysbench原理来说是可行的,他测试的表的数量是可控的,你把带数字编号的表通过逻辑库处理可以集合成一个新的逻辑表. ==================分割线结束========================================== 先看基本环境设置server.xml,大部分设置都可以不动,注意添加修改的是标签下面配置就可以了,每创建一个用户是要另外起标签: vim /usr/local/mycat/conf/server.xml 2880000 134217728 utf8 2 600 mycat123 sbtest,testppp sb123 sbtest test sbtest true设置了一些相关压测的项目参数,和创建了三个用户root,sysbench,test.这三个用户和数据库的用户没有关联,是独立的,即使这个用户密码被破解,数据库的密码依然安全.其中root有完全控制权限,sysbench只能控制sbtest库,test也只能控制sbtest库,而且限制了读写权限. 然后设置逻辑库配置文件schema.xml,这里改动比较多,所以直接贴上整个文件: select user()设置了两个逻辑库sbtest和testppp(和真实库同名,其实可以不同),指向的真实数据库的主从环境dn1和dn2,里面有一主两从三台真实服务器地址,并开启读写分离.但是要注意的是,事务只走主库,所以读写分离最优方案还是由程序做好一点,用中间件做难免就有点鸡肋了,毕竟现在很多开发框架都走事务的. mycat开启读写分离很简单,只要配置好writehost和readhost,然后配置读写分离参数balance就可以. balance=0，不开启读写分离，所有读操作都发生在当前的writeHost上 balance=1，所有读操作都随机发送到当前的writeHost对应的readHost和备用的writeHost balance=2，所有的读操作都随机发送到所有的writeHost,readHost上 balance=3，所有的读操作都只发送到writeHost的readHost上 3) 启动mycat, #启动mycat Mycat start #重启mycat Mycat restart #关闭mycat Mycat stop #而Mycat默认的连接端口是8066,管理端口是9066,可以在server.xml修改. ss -ntplu |grep java tcp LISTEN 0 100 :::9066 :::* users:(("java",pid=115779,fd=168)) tcp LISTEN 0 100 :::8066 :::* users:(("java",pid=115779,fd=172)) #看到端口起来了,就可以使用了,因为mycat支持mysql原生协议,所以连上8066端口是不会和一般mysql有什么区别,直接就能使用了. #如果更改了任何配置文件,可以登录进管理端口执行下列命令实时热刷新配置,相当方便. mysql -uroot -pmycat123 -h10.21.128.156 -P9066 #更改server的配置可以 Mysql>reload @@config #如果改了schema的配置,需要这个命令 Mysql>reload @@config_all加载完成就可以使用新配置了,哪怕是改了登录用户名也能热加载. 搭建sysbench 下载下来后,只要有c运行库就能编译安装,但是要创建mysql库文件的软连接,不然会报错找不到库文件, #先安装依赖包 yum install -y automake libtool #先创建mysql库文件的软连接,不然编译会报错的 ln -sf /usr/local/mysql/lib/libmysql* /usr/lib64 ln -sf /usr/local/mysql/lib/libmysqlclient.so /usr/lib64/libmysqlclient_r.so #然后执行: tar xf sysbench-0.4.12-1.1.tgz cd sysbench-0.4.12-1.1 ./autogen.sh ./configure --with-mysql-includes=/usr/local/mysql/include --with-mysql-libs=/usr/local/mysql/lib Make #如果 make 没有报错，就会在 sysbench 目录下生成二进制命令行工具 sysbench cd /tmp/sysbench-0.4.12-1.1/sysbench ls -l sysbench -rwxr-xr-x 1 root root 3293186 Sep 21 16:24 sysbench在此,环境就搭建完毕了. 开始测试 环境准备好了,就开始测试了,测试前要先准备测试数据,需要使用命令来制造出来,要比较长的时间(可能大半天),重点是要关注硬盘空间是否足够: #避免不必要的错误,直连数据库操作 mysql -uroot -p128157 -h10.21.128.157 -P3306 #创建测试数据库,sysbench默认测试库名是sbtest,也可以指定库名 mysql> create database sbtest; #进入sysbench程序目录 cd /tmp/sysbench-0.4.12-1.1/sysbench #开始造数据, ./sysbench --mysql-host=10.21.128.157 --mysql-port=3306 --mysql-user=root --mysql-password=128157 --test=tests/db/oltp.lua --oltp_tables_count=15 --oltp-table-size=40000000 --mysql-table-engine=innodb --rand-init=on prepare #再次强调,时间可能很长,需要耐心等待参数解析: --test=tests/db/oltp.lua 表示调用 tests/db/oltp.lua 脚本进行 oltp 模式测试,oltp是啥就不解析了--oltp_tables_count=15 表示会生成 15 个测试表,数量越多,自然花费时间越长--oltp-table-size=40000000 表示每个测试表填充数据量为 40000000行 ,数量越多也是越时间长--rand-init=on 表示每个测试表都是用随机数据来填充的,这样才客观 --mysql-table-engine=innodb 表示表的引擎是innodb prepare 用于准备测试需要的数据，准备完后执行run来测试，测试完成后如果需要清理数据就用cleanup来清除测试数据 =====================分割线开始=================================== 所以这里创造了15个表,里面每个表有4000万行的数据,数据为随机输入,这个数据量大概需要150G硬盘空间,估计可以涵盖大部分情况了吧,当然,你也可以创建更多数据. 数据结构大致是这样的,仅供参考: mysql> show tables; +------------------+ | Tables_in_sbtest | +------------------+ | sbtest1 | | sbtest2 | | sbtest3 | . . . | sbtest15 | +------------------+ 5 rows in set (0.00 sec) mysql> select * from sbtest1 limit 1; +----+---------+-------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------+ | id | k | c | pad | +----+---------+-------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------+ | 1 | 2507308 | 68487932199-96439406143-93774651418-41631865787-96406072701-20604855487-25459966574-28203206787-41238978918-19503783441 | 22195207048-70116052123-74140395089-76317954521-98694025897 | +----+---------+-------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------+ 1 row in set (0.01 sec)=============分割线结束======================================== 然后就可以进行正式测试了,我们先进行测试普通主从架构: #进入sysbench程序目录 cd /tmp/sysbench-0.4.12-1.1/sysbench #执行测试命令 ./sysbench --mysql-host=10.21.128.157 --mysql-port=3306 --mysql-user=root --mysql-password=128157 --test=tests/db/oltp.lua --oltp_tables_count=15 --oltp-table-size=40000000 --mysql-table-engine=innodb --num-threads=1024 --oltp-read-only=off --report-interval=10 --rand-type=uniform --max-time=3600 --max-requests=0 --percentile=99 run >> /tmp/sysbench_oltpX_32_20171113-1.log #我们设定的是3600秒,在此之前终止,也就是测试失败,需要分析报错参数解析: --num-threads=1024 表示发起1024个并发连接--oltp-read-only=off 表示不要进行只读测试，也就是会采用读写混合模式测试--report-interval=10 表示每10秒输出一次测试进度报告--rand-type=uniform 表示随机类型为固定模式，其他几个可选随机模式：uniform(固定),gaussian(高斯),special(特定的),pareto(帕累托)--max-time=3600 表示最大执行时长为3600秒,测试将在这个时间后结束--max-requests=0 表示总请求数为 0，因为上面已经定义了总执行时长，所以总请求数可以设定为 0；也可以只设定总请求数，不设定最大执行时长--percentile=99 表示设定采样比例，默认是 95%，即丢弃1%的长请求，在剩余的99%里取最大值 根据上面的解析,最后输出到一个文件,毕竟需要记录下来. 然后到mycat代理环境: ./sysbench --mysql-host=10.21.128.156 --mysql-port=8066 --mysql-user=sysbench --mysql-password=sb123 --test=tests/db/oltp.lua --oltp_tables_count=15 --oltp-table-size=40000000 --mysql-table-engine=innodb --num-threads=1024 --oltp-read-only=off --report-interval=10 --rand-type=uniform --max-time=3600 --max-requests=40000000 --percentile=99 run >> /home/logs/sysbench_oltpX_32_20171113-2.log和上面一样,设定了并发为1024个线程,测试时间为3600秒即1小时,同时也是用到刚才制造出来的15个4000万行的表,设定取值采样平均值为99%的数据,输出到另一个log文件. 阅读测试报告 测试完了,就来看结果了,我们拿其中一个结果来解析说一下: #忽略掉一些每10秒统计值,只看最后的统计值 vim /tmp/sysbench_oltpX_32_20171113-1.log sysbench 0.5: multi-threaded system evaluation benchmark Running the test with following options: Number of threads: 1024 Report intermediate results every 10 second(s) Random number generator seed is 0 and will be ignored Threads started! -- 每10秒钟报告一次测试结果，tps、每秒读、每秒写、99%以上的响应时长统计 [ 10s] threads: 1024, tps: 364.69, reads/s: 6324.66, writes/s: 1765.66, response time: 4292.46ms (99%) [ 20s] threads: 1024, tps: 475.80, reads/s: 6037.91, writes/s: 1640.10, response time: 4088.05ms (99%) [ 30s] threads: 1024, tps: 439.40, reads/s: 6349.45, writes/s: 1808.89, response time: 3248.44ms (99%) [ 40s] threads: 1024, tps: 487.70, reads/s: 6438.46, writes/s: 1879.72, response time: 4385.98ms (99%) [ 50s] threads: 1024, tps: 395.70, reads/s: 6498.99, writes/s: 1849.00, response time: 3845.88ms (99%) . . . [3560s] threads: 1024, tps: 385.80, reads/s: 4949.60, writes/s: 1503.80, response time: 19827.73ms (99%) [3570s] threads: 1024, tps: 249.70, reads/s: 3679.90, writes/s: 1009.40, response time: 12016.58ms (99%) [3580s] threads: 1024, tps: 328.90, reads/s: 4511.40, writes/s: 1301.40, response time: 7419.06ms (99%) [3590s] threads: 1024, tps: 196.40, reads/s: 3058.90, writes/s: 815.30, response time: 12092.35ms (99%) [3600s] threads: 1024, tps: 386.60, reads/s: 5282.74, writes/s: 1537.78, response time: 13614.18ms (99%) OLTP test statistics: queries performed: read: 16913554 -- 读总数 write: 4832444 -- 写总数 other: 2416222 -- 其他操作总数(SELECT、INSERT、UPDATE、DELETE之外的操作，例如COMMIT等) total: 24162220 -- 全部总数 transactions: 1208111 (335.29 per sec.) -- 总事务数(每秒事务数) deadlocks: 0 (0.00 per sec.) -- 发生死锁总数 read/write requests: 21745998 (6035.29 per sec.) -- 读写总数(每秒读写次数) other operations: 2416222 (670.59 per sec.) -- 其他操作总数(每秒其他操作次数) General statistics: total time: 3603.1388s -- 总耗时 total number of events: 1208111 -- 共发生多少事务数 total time taken by event execution: 3688348.3797s -- 所有事务耗时相加(不考虑并行因素) response time: min: 28.41ms -- 最小耗时 avg: 3052.99ms -- 平均耗时 max: 48667.93ms -- 最长耗时 approx. 99 percentile: 12708.40ms -- 超过99%平均耗时 Threads fairness: events (avg/stddev): 1179.7959/29.07 execution time (avg/stddev): 3601.9027/1.01所以,每秒事务数Tps达335.29,每秒查询数Qps达6035.29,平均延时3052.99ms. 看完解析,来看结果,下面是直接测主从环境的结果: OLTP test statistics: queries performed: read: 19215238 write: 5490068 other: 2745034 total: 27450340 transactions: 1372517 (381.03 per sec.) deadlocks: 0 (0.00 per sec.) read/write requests: 24705306 (6858.48 per sec.) other operations: 2745034 (762.05 per sec.) General statistics: total time: 3602.1538s total number of events: 1372517 total time taken by event execution: 3688254.2686s response time: min: 18.33ms avg: 2687.22ms max: 55386.15ms approx. 99 percentile: 12444.89ms Threads fairness: events (avg/stddev): 1340.3486/33.85 execution time (avg/stddev): 3601.8108/0.44每秒事务数Tps达381.03,每秒查询数Qps达6858.48,平均耗时2687.22ms,毕竟总数据量是6亿,还是应该要接受. 下面是通过mycat代理的结果 OLTP test statistics: queries performed: read: 18078326 write: 5165236 other: 2582618 total: 25826180 transactions: 1291309 (358.40 per sec.) deadlocks: 0 (0.00 per sec.) read/write requests: 23243562 (6451.19 per sec.) other operations: 2582618 (716.80 per sec.) General statistics: total time: 3602.9883s total number of events: 1291309 total time taken by event execution: 3687715.5739s response time: min: 22.45ms avg: 2855.80ms max: 50326.08ms approx. 99 percentile: 13264.21ms Threads fairness: events (avg/stddev): 1261.0439/33.56 execution time (avg/stddev): 3601.2847/0.96每秒事务数Tps达358.40,每秒查询数Qps达6451.19,平均耗时2855.80ms,同样是总数据量6亿. 从结果对比计算,使用mycat后,tps,qps,和耗时都损耗了6%-7%,在我个人看来还是可以接受,因为使用了mycat做代理层,可以很方便的管理后端数据库,任何切换都可以手动来秒切,使用上触发脚本后就是一个HA框架了. 题外说明 测试结果示例说明的例子,其实是加上了高可用keepalived的测试结果,每秒事务数Tps达335.29,每秒查询数Qps达6035.29,平均延时3052.99ms,总的来说算好,也还只是比纯mysql主从损耗10%范围内,可以接受,毕竟可用性高了很多,而且后续压力增大也可以随时增加mycat数量来填补. 功能多了,机器也要多了一些,需要特别说明的是,因为涉及网络数据包转发关系,keepalived和后端mycat不能在同一台服务器,所以就必须独立开来. 10.21.128.208:keepalived主 10.21.128.209:keepalived备 10.21.128.200:mycat1 10.21.128.201:mycat2 10.21.128.199:vip 简单说明拓扑关系:
需要多搭建一个mycat,不过这里就不细说了,直接复制一份配置到其他机器再启动就ok了. 然后搭建一套keepalived集群: 大多数情况下,大伙使用keepalived只做HA功能,而LVS功能则交给其他软件实现.但是实际上keepalived+ipvsadm既能实现HA功能,也能实现LVS功能,非常方便. 我们在10.21.128.208和10.21.128.209上安装keepalived和修改配置. 个人不想纠结功能和版本问题,而这些也是比较常态功能性的软件,绝大部分yum源都配备,所以直接用yum安装就很方便,有额外兴趣的可以慢慢编译 #安装需要的软件 yum install -y keepalived ipvsadm nc rsync telnet tcpdump wget安装很快,我们直接看配置,yum安装默认的配置文件在/etc/keepalived/ #修改配置文件,注意注释位置 vim /etc/keepalived/keepalived.conf ! Configuration File for keepalived #全局配置 global_defs { notification_email { #定义收件人邮件地址 root@localhost } #定义发件人 notification_email_from root@localhost #如果要使用第三方smtp服务器，在现实中几乎没有意义（需要验证的原因）,设为本地就可以了 smtp_server 127.0.0.1 #smtp超时时间 smtp_connect_timeout 30 #此服务器keepalived的ID,随便改,注意不同服务器不一样就行 router_id LVS_HA_MYCAT1 } #vrrp配置(HA配置) #定义虚拟路由，VI_1 为虚拟路由的标示符，自己定义名称 vrrp_instance VI_1 { #指定当前节点为主节点 备用节点上设置为BACKUP即可 state MASTER #绑定虚拟IP的网络接口,注意内外网 interface eth0 #VRRP组名，两个节点的设置必须一样，以指明各个节点属于同一VRRP组,0-255随便你用,这个ID也是虚拟MAC最后一段的来源 virtual_router_id 19 #初始优先级,取值1-254之间,主节点一定要最大,其他从节点则看情况减少 priority 100 #组播信息发送间隔，两个节点设置必须一样 advert_int 1 #设置验证信息，两个节点必须一致 authentication { auth_type PASS auth_pass 199200 } #指定VIP,两个节点设置必须一样,虚拟ip最好和真实ip在同一网段。 virtual_ipaddress { 10.21.128.199 } } #负载均衡配置(LVS配置) #指定VIP和端口,vip就是上面设置那个 virtual_server 10.21.128.199 8066 { #延迟多少个周期再启动服务，做服务检测 delay_loop 6 #负载均衡调度算法,下面有详细说明 lb_algo rr #负载均衡类型选择,可选DR|NAT|TUN,DR性能比较高 lb_kind DR #vip的掩码 nat_mask 255.255.255.0 #会话保持时间,在设置的这个时间之内无论用户有无响,下一次用户请求时都发去同一个路由,超过这个时间则需重新路由,短连接应用设为0,长连接应用需要按需. persistence_timeout 0 #使用的协议,一般就TCP protocol TCP #定义后端realserver的真实服务器属性,ip和端口 real_server 10.21.128.200 8066 { #负载均衡权重,数值越大,就负担更多连接 weight 1 #定义心跳检测的方法,因为不是web,而且用tcp_check健康检测后面的mycat会报错,所以需要misc_check的方式做心跳检测 MISC_CHECK { #自定义心跳检测shell脚本的路径、检测的服务器ip、检测的端口。(引号必须要) misc_path"/etc/keepalived/shell/check_mycat_status.sh 10.21.128.200 8066" #脚本执行超时时间 misc_timeout 3 } } #同上 real_server 10.21.128.201 8066 { weight 2 MISC_CHECK { misc_path"/etc/keepalived/shell/check_mycat_status.sh 10.21.128.201 8066" misc_timeout 3 } } #同上 real_server 10.21.128.156 8066 { weight 2 MISC_CHECK { misc_path"/etc/keepalived/shell/check_mycat_status.sh 10.21.128.156 8066" misc_timeout 3 } } }特别说明一下负载均衡调度算法参数lb_algo,因为不同的算法有不同的效果,想要架构稳定,就要找到最适合自己的算法. rr:轮循调度（Round Robin）算法,不管服务器上实际的连接数和系统负载,把连接轮流的发放到每一个real_server上.优点是必然每个real_server都有操作,缺点是长短连接容易分配不均衡. wrr:加权轮循调度(Weighted Round Robin)算法,大体和rr一样,但是规则上多了一个权重判断,通过参数weight判断那个real_server分发多一些任务,优缺点和rr也一致. lc:最小连接调度算法,把新的连接请求分配到当前连接数最小的real_server上.优点是能相对平均分配连接请求,缺点是可能出现局部大量短连接打到一个节点上的情况. wlc:加权最小连接调度算法,大体和lc一致,优缺点也一致,规则上多了一个权重判断,通过参数weight判断那个real_server分发多一些任务. lblc:基于局部性的最少链接调度算法,在负载基本相对平衡情况下,将相同目标IP地址的请求调度到同一台服务器.优点是能提高缓存命中率,缺点是意义不大,因为不平衡就是失效. lblcr:带复制的基于局部性最少链接,它与LBLC算法基本相同,但是算法更复杂,以达到缓存可用性更高,缺点是对于热数据意义不大,一般很少用这种算法. dh:目标地址散列调度,通过静态映射算法,散列(Hash)函数将一个目标IP地址映射到real_server上,优点是一个IP地址会长期固定连接一台服务器,缺点是容易使请求不平衡. 注意1:LVS+DR模式中，只支持IP的转发，不支持端口转发，也就是说在keepalived.conf的virtual_server和real_server的配置节点中端口必须一样。 注意2:配置负载均衡模式强烈建议VIP和后端真实服务器IP同网段,不然会出现一些奇葩情况,得不偿失. 里面涉及一个检测心跳的脚本,如下所示: cat /etc/keepalived/shell/check_mycat_status.sh #!/bin/bash result=`nc -v -z $1 $2` flag="succeeded" if [[ $result =~ $flag ]] then exit 0 else; exit 1 fi #记得要给该脚本赋予执行权限： chmod 755 check_mycat_status.sh意思很简单,就是通过nc命令检测真实服务器的mycat的端口通不通,如果不通的话,keepalived就把这个mycat剔除出集群. 然后,在后端真实服务器上需要做一个操作,绑定vip创建ipvs规则: 在10.21.128.200,10.21.128.201,10.21.128.156上创建并执行下面的脚本, #创建规则脚本 vim /shell/realserver #!/bin/bash SNS_VIP=10.21.128.199 #/etc/rc.d/init.d/functions case "$1" in start) ifconfig lo:0 $SNS_VIP broadcast $SNS_VIP netmask 255.255.255.255 up sleep 5 /sbin/route add ${SNS_VIP}/32 dev lo:0 echo "1">/proc/sys/net/ipv4/conf/lo/arp_ignore echo "2">/proc/sys/net/ipv4/conf/lo/arp_announce echo "1" >/proc/sys/net/ipv4/conf/all/arp_ignore echo "2">/proc/sys/net/ipv4/conf/all/arp_announce sysctl -p >/dev/null 2>&1 echo "RealServer Start OK" ;; stop) ifconfig lo:0 down /sbin/route del -net $SNS_VIP netmask 255.255.255.255 dev lo:0 echo "0" >/proc/sys/net/ipv4/conf/lo/arp_ignore echo "0">/proc/sys/net/ipv4/conf/lo/arp_announce echo "0">/proc/sys/net/ipv4/conf/all/arp_ignore echo "0">/proc/sys/net/ipv4/conf/all/arp_announce echo "RealServer Stoped" ;; restart) /sbin/route del -net $SNS_VIP netmask 255.255.255.255 dev lo:0 /sbin/route add ${SNS_VIP}/32 dev lo:0 ;; *) echo "Usage: $0 {start|stop|restart}" exit 1 esac exit 0 #赋予执行权限 chmod 755 /shell/realserver #执行一下 /shell/realserver start #然后查看下网卡状态 ifconfig lo:0 lo:0 Link encap:Local Loopback inet addr:10.21.128.199 Mask:255.255.255.255 UP LOOPBACK RUNNING MTU:16436 Metric:1需要注意,每次服务器重启都必须启动这个绑定,不然lvs就不生效了,例如把他放到/etc/rc.d/rc.local echo "/shell/realserver start" >>/etc/rc.d/rc.local万事俱备,只欠东风,那就启动keepalived吧. 在10.21.128.208和10.21.128.209上执行 #因为是yum安装,所以有linux服务 /etc/init.d/keepalived start Starting keepalived: [ OK ] --------------------------------------------------------------------- #如果是centos7或者是ubuntu14以上的系统,就需要以下的命令 systemctl start keepalived systemctl status keepalived systemctl stop keepalived systemctl reload keepalived --------------------------------------------------------------------- #看看vip,因为主是208,所以vip只会在208出现,除非208挂了 ip addr 1: lo: mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 22:87:35:77:ef:38 brd ff:ff:ff:ff:ff:ff inet 10.21.128.208/24 brd 10.21.128.255 scope global eth0 inet 10.21.128.199/32 scope global eth0 #-------VIP在这 inet6 fe80::2087:35ff:fe77:ef38/64 scope link valid_lft forever preferred_lft forever #然后看看当前LVS状态 ipvsadm -L IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 10.21.128.199:8066 rr -> 10.21.128.156:8066 Route 2 0 0 -> 10.21.128.200:8066 Route 1 0 0 -> 10.21.128.201:8066 Route 2 0 0注意:如果是检测不正常的IP和端口,在ipvsadm -L命令下是看不到IP地址的,因为被keepalived主动下线了,这个时候你要检查相关IP和端口为什么检测不通过的原因. 如果要看连接进来的IP地址和状态,可以用下面的命令. ipvsadm -Lnc IPVS connection entries pro expire state source virtual destination TCP 14:54 ESTABLISHED 10.237.140.90:31472 10.21.128.199:8066 10.21.128.200:8066 TCP 01:27 FIN_WAIT 10.237.140.90:31468 10.21.128.199:8066 10.21.128.201:8066看state的值可以知道这个连接的状态. NONE:如果用户配置了持久化时间persistence_timeout，当客户端的请求到达LB后，IPVS会在记录表里添加一条state为NONE的连接记录。该连接记录的源IP为客户端IP，端口为0，超时时间为上面所说的持久化时间persistence_timeout，会逐步减小。当NONE的超时时间减到0时，如果IPVS记录中还存在ESTABLISHED或FIN_WAIT状态的连接，则persistence_timeout值会刷新为初始值。在该NONE状态的连接记录存在的期间，同一客户端IP的消息都会被调度到同一个RS节点。 ESTABLISHED:前面的超时时间就是tcp|tcpfin|udp中的tcp的值。该值表示一条TCP连接记录的空闲释放时间。如果客户端和服务端建立了连接，则IPVS中会出现一条ESTABLISHED的记录。每当客户端和服务端的连接中有信息交互时，该超时时间都会刷新为初始值。如果连接处于空闲状态，即一直没有信息交互，则等到该值超时后，ESTABLISHED的记录会直接消失（这种情况下IPVS记录不会进入FIN_WAIT），实际上TCP连接还是存在的，并没有中断，但是由于持久化时间到了，后续同一客户端（IP+Port）过来的请求会重新调度。所以长连接业务场景需要注意根据业务需要设置好这个TCP空闲连接的超时时间。 FIN_WAIT:前面的超时时间就是tcp|tcpfin|udp中的tcpfin的值。在IPVS记录的每一条连接中，如果客户端发起了FIN断连，则IPVS中记录的连接状态会从ESTABLISHED变为FIN_WAIT。该值超时后，FIN_WAIT状态的记录直接消失。 如果应用都用tcp或者http的长连接，因为建立tcp连接或者http连接开销比较大，而应用端其实是需要频繁跟server端通讯的，这时候保持长连接无疑是非常合适的。经过摸索， lvs & keepalived 长连接的配置主要在三个地方： 一,client端的SoTimeout, 就java来说就是java.net.Socket的setSoTimeout方法设置的， setSoTimeout(0)就是表明超时时间无限大。这个值是为读取阻塞设置超时的。 二,lvs的设置： #查看是ipvsadm --list --timeout,配置tcp/tcpfin/udp超时时间： ipvsadm --list --timeout Timeout (tcp tcpfin udp): 900 120 300 #现在我要设置tcp session的timeout时间是7200秒。设置timeout： ipvsadm --set 7200 120 300这个值如果设置太小，你的client将会收到 connection reset by peer此类的错误提示。 三,keepalived的配置：就是virtual_server的persistence_timeout，意思就是在这个一定时间内会讲来自同一用户（根据ip来判断的）route到同一个real server。对于长连接类的应用，你肯定需要这么做。配置值最好跟lvs的配置的timeout一致。 virtual_server 172.25.31.119 8066 { delay_loop 2 lb_algo rr lb_kind DR persistence_timeout 7200 protocol TCP至于短连接,我个人认为还是设置为0比较好,毕竟要考虑集群平衡负载,有些时候可能会某些特定IP连接数异常多,某些IP连接数非常少. 一切都正常,那么,我们可以压测了. #和之前命令差不多,只是ip不一样 ./sysbench --mysql-host=10.21.128.199 --mysql-port=8066 --mysql-user=sysbench --mysql-password=sb123 --test=tests/db/oltp.lua --oltp_tables_count=15 --oltp-table-size=40000000 --mysql-table-engine=innodb --num-threads=1024 --oltp-read-only=off --report-interval=10 --rand-type=uniform --max-time=3600 --max-requests=40000000 --percentile=99 run >> /home/logs/sysbench_oltpX_32_20171128-3.log我们来看看lvs状态 #查看链接状态 ipvsadm -L IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 10.21.128.199:8066 rr -> 10.21.128.156:8066 Route 2 341 340 -> 10.21.128.200:8066 Route 1 341 340 -> 10.21.128.201:8066 Route 2 342 340 #加多一个--stats参数,就可以看到流量数据 ipvsadm -L --stats IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Conns InPkts OutPkts InBytes OutBytes -> RemoteAddress:Port TCP 10.21.128.199:8066 2045 3658545 0 326481K 0 -> 10.21.128.156:8066 682 1131691 0 114278K 0 -> 10.21.128.200:8066 681 1266405 0 106344K 0 -> 10.21.128.201:8066 682 1260449 0 105858K 0为什么会没有out?是不是很奇怪?因为我们负载均衡类型选择的是DR模式,这个模式的特点就是当客户端和真实服务器建立链接后,真实服务器会直接把数据发送给客户端,不再需要keepalived来中转,所以就没有out的流量了,也就是为什么说效率就更高的原因了. 然后来看看压测的结果如何? OLTP test statistics: queries performed: read: 17043978 write: 4869708 other: 2434854 total: 24348540 transactions: 1217427 (338.00 per sec.) deadlocks: 0 (0.00 per sec.) read/write requests: 21913686 (6084.05 per sec.) other operations: 2434854 (676.01 per sec.) General statistics: total time: 3601.8265s total number of events: 1217427 total time taken by event execution: 3687506.3802s response time: min: 30.17ms avg: 3028.93ms max: 75102.41ms approx. 99 percentile: 13757.56ms Threads fairness: events (avg/stddev): 1188.8936/33.40 execution time (avg/stddev): 3601.0804/0.40每秒事务数Tps达338.00,每秒查询数Qps达6084.05,平均延时3028.93ms,和一开始相差无几,基本符合现实. |
【本文地址】
今日新闻 |
推荐新闻 |