一种兼顾成本与性能的应用高可用部署架构

来源:互联网 发布:淘宝游戏专营类目 编辑:程序博客网 时间:2024/06/05 05:57

在实际的生产环境应用部署中经常遇到的问题是性能和服务的高可用。而成本支出又让前面的问题在解决起来阻力重重。本文就是根据实际工作经验总结和设计的一种兼顾成本、性能和服务高可用的应用部署架构。


1、本高可用部署架构使用的资源

共计4台设备,以下仅供参考:

  • PC服务器:2*cpu, 8*16GB内存,8*600GB 10k磁盘,iDRAC企业版,双电,品牌:DELL,型号:R630,数量:2台
  • 防火墙:双电,品牌:juniper,型号:srx550,数量:1台
  • 交换机:双电,品牌:华为,型号:5720-36c-ei-ac,数量:1台;


2、基于以上资源实现的高可用部署架构如下图所示



3、架构高可用技术分析

3.1 网络配置高可用

      采用动态链路聚合方式(mode=4),将每个主机的物理网卡em1和em2配置为bond0。

       动态链路聚合负载均衡方式在主机端需要配置物理网卡bond,并运行在mode=4模式下。在交换机侧也需要为支持该负载均衡功能做相应的配置。在该网口负载均衡模式下,bond0可以获得2000Mbps的网络吞吐能力,且任一个网卡断开连接时,主机会自动通过bond0的另一个物理网卡继续正常工作。

       基于网卡bond0创建桥接网卡br0,在物理主机上创建的每一个KVM虚机的网卡eth0都默认设置为使用该桥接网卡br0接入网络。该网卡用于业务生产网络。

      采用动态链路聚合方式(mode=4),将每个主机的物理网卡em3和em4配置为bond1。

      基于网卡bond1创建桥接网卡br1,在物理主机上创建的KVM虚机中,只有运行redis服务和mysql服务的虚机才会设置为使用桥接网卡br1接入网络,在虚机系统中配置为网卡eth1。该网卡配置为数据同步专用网络。最高网络吞吐能力为2000Mbps。任一个网卡断开连接时,主机会自动通过bond1的另一个物理网卡继续正常工作。

      在该部署方案中,redis配置为一主、一从,并使用3个哨兵进程对redis主从服务做自动切换管理。Redis主从间的数据同步网络,该网卡配置为10.0.0.0/24网段,不设网关,用于局域网内的数据同步网络。哨兵进程使用的监控网络均配置为虚机eth0网卡(通过br0接入网络),该网络有意与主从同步网络分隔开,以获得最好的监控效果。

      在该部署方案中,mysql配置为heartbeat+drbd高可用,mysql主备机之间的DRBD网络RAID1功能所使用的数据同步网络为虚机eth1网卡(通过br1接入网络)。


3.2 LVS负载均衡 vip

在每个物理主机上各创建一个LVS虚机,部署LVS+Keepalived,配置vip,提供负载均衡服务。LVS主、备机间通过vrrp协议交换心跳数据。

本架构中部署的应用均接入LVS进行负载均衡或失效转移。


3.3 MySql vip

在每个物理主机上各创建一个mysql虚机,部署heartbeat+drbd+mysql高可用服务。应用通过mysql vip地址访问数据库。

很多关于mysql的高可用方案中都是基于主从数据同步实现的,这个技术是有使用限制的,那就是除非数据库的数据量很小且对实时性要求不高。对于一个单表数据量过亿的库来讲,主从复制的方案想都不用想。本方案中使用的是DRBD网络raid1,实测在降低一点mysql性能的条件下(因双机间需通过网络同步数据,但效率很高),可以实现双机间的数据库服务高可用。

3.4 redis主从+哨兵

redis部署主、从两个节点,其中master节点关闭数据持久化。主从节点的切换交给三个redis 哨兵进程,共部署3个哨兵,配置为2票表决通过时可以切换redis主从间的角色。

3.5 iDRAC远程管理卡网络
所有主机均需要配置企业版iDRAC远程管理卡功能,需要预先或在主机上架时配置并接入好iDRAC远程管理卡的网络地址。该地址将作为远程管理地址,供系统管理员从公司远程登录和管理主机。


4、压测

一切没有压测数据证明的架构方案,都是在耍流氓。

磁盘IOPS测试:
(1)6*600GB 10K raid10  划分832GB磁盘 配置双机drbd
测试随机读:998 iops
fio -filename=/dev/drbd0 -direct=1 -iodepth 1 -thread -rw=randread -ioengine=psync -bs=16k -size=200G -numjobs=10 -runtime=300 -group_reporting -name=mytest
测试随机写: 1638 iops
fio -filename=/dev/drbd0 -direct=1 -iodepth 1 -thread -rw=randwrite -ioengine=psync -bs=16k -size=200G -numjobs=30 -runtime=300 -group_reporting -name=mytest
顺序写 bw=113262KB/s, iops=7078
fio -filename=/dev/drbd0 -direct=1 -iodepth 1 -thread -rw=write -ioengine=psync -bs=16k -size=200G -numjobs=30 -runtime=300 -group_reporting -name=mytest
注:顺序写测试中观测到网卡吞吐量达到了900Mbps以上,因为双机间drbd需使用网卡同步数据,所以网卡通信成为磁盘写能力的瓶颈,观测到双虚拟机的磁盘IO使用率约60%,双物理宿主机的磁盘IO使用率约25%。

(2)6*600GB 10K raid10 对照组1 划分scsi 300GB磁盘直接挂到物理机
随机读:1008 iops
fio -filename=/dev/sdb1 -direct=1 -iodepth 1 -thread -rw=randread -ioengine=psync -bs=16k -size=200G -numjobs=10 -runtime=300 -group_reporting -name=mytest
随机写:1709   iops
fio -filename=/dev/sdb1 -direct=1 -iodepth 1 -thread -rw=randwrite -ioengine=psync -bs=16k -size=200G -numjobs=30 -runtime=300 -group_reporting -name=mytest
顺序写:bw=1461.3MB/s, iops=93522
fio -filename=/dev/sdb1 -direct=1 -iodepth 1 -thread -rw=write -ioengine=psync -bs=16k -size=200G -numjobs=30 -runtime=300 -group_reporting -name=mytest

从以上两个测试可以看到,drbd的数据同步效率很高,给磁盘IO读写性能带来的下降非常有限。
而从另一个角度看,如果一个主机上对DRBD磁盘有高负载的写压力时,双物理机间的网卡通信能力一定会成为新的天花板。因为双物理机间使用的千兆网卡通信同步数据,所以可以计算出系统写drbd共享磁盘的最大写盘能力不会超过120MB/S 。
(3)8*300GB 10k raid10  对照组2 
/dev/sda3分区 1.1tb  随机读:iops=1322
fio -filename=/dev/sda3 -direct=1 -iodepth 1 -thread -rw=randread -ioengine=psync -bs=16k -size=200G -numjobs=10 -runtime=300 -group_reporting -name=mytest

Mysql tpcc测试:
(1)使用上文磁盘iops测试1中的drbd磁盘作为mysql数据磁盘,mysql开启binlog输出时 
[transaction percentage]
        Payment: 43.48% (>=43.0%) [OK]
   Order-Status: 4.35% (>= 4.0%) [OK]
       Delivery: 4.35% (>= 4.0%) [OK]
    Stock-Level: 4.35% (>= 4.0%) [OK]
 [response time (at least 90% passed)]
      New-Order: 100.00%  [OK]
        Payment: 100.00%  [OK]
   Order-Status: 100.00%  [OK]
       Delivery: 100.00%  [OK]
    Stock-Level: 100.00%  [OK]

<TpmC>
                 5875.967 TpmC
(2)使用上文磁盘iops测试1中的drbd磁盘作为mysql数据磁盘,mysql关闭binlog输出时 
 [response time (at least 90% passed)]
      New-Order: 100.00%  [OK]
        Payment: 100.00%  [OK]
   Order-Status: 100.00%  [OK]
       Delivery: 100.00%  [OK]
    Stock-Level: 100.00%  [OK]

<TpmC>
                 6557.833 TpmC

mysql tpcc压测期间,运行mysql服务进程的虚机节点1上,/dev/drbd0共享磁盘IO使用率保持在100%,同一时间在drbd网络磁盘的另一个虚机节点2上其drbd数据同步产生的磁盘IO保持小于20%。
在压测期间,运行虚机节点1的物理机1,观测到其用于划分drbd共享磁盘存储空间的本地磁盘IO资源使用率也是保持在100%,同一时间的另一个物理主机2上的磁盘IO资源使用率小于5%。

(3)使用上文磁盘iops测试2中的300GB磁盘直接分配给mysql虚机,mysql关闭binlog输出时
 [transaction percentage]
        Payment: 43.48% (>=43.0%) [OK]
   Order-Status: 4.35% (>= 4.0%) [OK]
       Delivery: 4.35% (>= 4.0%) [OK]
    Stock-Level: 4.35% (>= 4.0%) [OK]
 [response time (at least 90% passed)]
      New-Order: 100.00%  [OK]
        Payment: 100.00%  [OK]
   Order-Status: 100.00%  [OK]
       Delivery: 100.00%  [OK]
    Stock-Level: 100.00%  [OK]

<TpmC>
                 7656.833 TpmC

从压测期间观测到的结果,还看到另一个现象,就是KVM虚机默认是不对虚机使用磁盘IO进行限制的。因为我们一般多是把KVM虚机使用的系统磁盘或数据磁盘都是放在一个共同的存储资源池中的,也就是说如果一个虚机导致自己的磁盘使用率达到100%时,意未着整个存储资源池的IO使用率也是100%,其它虚机的磁盘读写会受影响。
正常情况下,很少会有以上极端情况发生,我们也不会去限制每个KVM虚机的磁盘IO使用。

压测总结:可以看到mysql binlog日志输出会带来一定的mysql服务性能下降,同时启用drbd网络raid1也会带来一些性能下降。在保留服务高可用的同时,兼顾性能的一个选择是:继续使用drbd共享磁盘功能,但建议把binlog日志输出到别的地方去,或者在允许的情况下关闭binlog输出。



0 0
原创粉丝点击