linux系统下对网站实施负载均衡+高可用集群需要考虑的几点

Posted 2020-08-17 散尽浮华

 

当下Linux运维技术越来越受到企业的关注和追捧, 在某些企业, 尤其是牵涉到电子商务和电子广告类的网站，通常会要求作负载均衡和高可用的Linux集群方案。那么如何实施Llinux集群架构，才能既有效保证网站健康运行，又能节省运维成本呢？以下是根据本人几年的运维经历，简单梳理下自己的一点感悟。

1) 机房的选择
如果有自己公司的机房那是再好不过的了；如果没有，建议放在BGP机房内托管，如果有选择的话，最好是选择带有硬件防火墙的机房，这样在安全方面也有保障；

网站如若是放在IDC机房托管，而机房最前面也没有硬件防火墙防护时，要尽量做好流量监控的工作（尤其是nginx/Haproxy负载机的流量），一般选用Zabbix监控软件.服务器的选择一切以稳定为前提和原则，在价格能得到公司接受的情况下，可以选择像IBM和DELL的品牌服务器，质量有保障。在服务器资源紧张的情况下，可以部署openstack虚拟化，虚拟机可以充当test机器，beta机器以及对内业务部署机，充分利用机器资源。

2）负载均衡+高可用集群方案的选择
负载均衡实施
2.1) 一种是通过硬件来实施
常见硬件有比较昂贵的NetScaler、F5、Radware和Array等商用负载均衡器，优点是有专业团队维护，缺点是花销太大，对于网络规模较小的企业网站来说没有必要；
2.2) 一种是通过开源免费负载均衡软件策略实施
常用的是LVS、HAProxy、Nginx负载均衡,这些都是通过软件级别来实现，费用非常低廉，对于中小企业来说，鉴于成本问题，选择这一种比较靠谱。

高可用实施
首推是Nginx/Haproxy+Keepalived的架构，那么为什么不选择基于LVS+Keepalived的集群方案呢？
因为我们部署的网站一般都会涉及到动静分离、正则分发的需求，如果网站最前面选用LVS+Keepliaved架构，那么至少又要在中间加一层二级负载均衡的机器，这样比较耗机器，无形中也会增加整个网站的成本；

有人会认为Nginx/Haproxy+Keepalived的稳定性不如LVS+Keepalived，其实这是个误解！
通过近几年的观察期，加上十几个项目的成功实施，发现Nginx/HAProxy+Keepalived的负载均衡器的稳定性很好，尤其是Haproxy+keepalive在高并发的情况下宕机可能性微乎其微。一个朋友的公司在近段时间实施的一个商业网站用的是HAProxy+Keepalived，在亿/日高并发流量的冲击下，HAProxy稳如磐石。LVS在性能方面是公认最好的，尤其是后面的节点(如Web或mysql数据库服务器)超过10台时，它的性能是最优异的。中小公司的并发和流量一般不是特别大，每日pv持续在百万之内的，推荐使用Nginx/Haproxy+Keepalived。

负载均衡+高可用方案在节省成本的提前下，一般需要多少台服务器？
一般来说，中小网站采用2+2+2架构即可。最前面是2台Nginx/Haproxy+Keeplaived机器，后面是2台配置比较好的web机器；数据库2台，一主一从方式。

服务器之间的数据同步采用Rsync+Inotify实时同步方案。如果时效性不是那么高，可以采用纯Rsync方式，结合Crontab进行定时同步。

如果对文件服务器有更高要求比如图片类型，可以考虑再增加2台服务器，做成DRBD+Heartbeat+NFS方式；
如果有海量文件需要存储的话，还可以考虑用MFS，当然这样也是比较耗机器的。

3）集群架构中同步session问题
中小型网站可以采用Nginx的ip_hash和Haproxy的balance source机制，它们的原理比较类似，都会让某一客户机在相当长的一段时间内只访问固定的后端的某台真实的Web服务器，这样会话就会得以保持，我们在网站页面进行login的时候，就不会在后面的web服务器之间跳来跳去了，自然也不会出现登陆一次后网站又提醒你没有登陆需要重新登陆的情况；

如果是大型项目或网站可以考虑用Memcached的方式。
session共享问题可以参考：http://www.cnblogs.com/kevingrace/p/6031356.html

4）web服务选择Apache or Nginx
在网站流量和并发不大的环境下，完全可以选择Apache作为Web服务，虽然它的抗并发能力不高，但它的稳定性是最好的，许多电子商务网站都是基于Apache；
如果网站是大流量大并发的环境下，强烈推荐Nginx作为web服务。

5）数据库方案:Master-Slave
中小型企业网站，Mysql数据库采用一主一从方案即可满足业务需求，然后看起来比较单一，但是事实证明，这种设计的稳定性也是非常靠谱的！经验证，采用mysql一主一从方案好多年的网站，很少没有因为数据库的故障发生过丢数据现象。网站上线的前期阶段，可以通过php程序，把后台的查询功能的入口选择Slave机器，这样可以大大减少主数据库的压力；Slave机器并非仅仅只起一个备份和备机的作用，完全可以通过Php程序将后台的复杂查询转到从MySQL机器上。

==========================运维场景中web高可用架构方式=========================

Keepalived和Heartbeat都是用来提高高可用性的工具，避免单点故障。那么它们有什么区别呢？又是怎么搭配的呢?
1) 二者区别
LVS 是通过VRRP协议进行数据包转发的，提供的是四层的负载均衡, 特点是效率高，只要服务器网卡抗的住就不是问题。
Haproxy 可以提供四层或七层的数据转发服务，能做到七层的好处是可以根据服务所处的状态等进行负载。

2) 搭配方式
以上两者只是实现了负载均衡，但是他们本身是明显的单点故障，因此需要使用双机软件做热备，来保证高可用性。
Keepalived可以通过检测VRRP数据包来切换，因此Keepalived更适合与LVS搭配; Heartbeat更适于和Haproxy搭配。
正常情况下, LVS+Keepalived 和 Haproxy+Heartbeat 这两个搭配方式是运维场景中运用比较多也比较经典的负载均衡高可用性方案了。
此外, Nginx + Keepalived 和 Haproxy + Keepalived搭配方式也是常见的一种负载均衡高可用方案.

四层负载均衡: 从第四层"传输层"开始, 基于tcp协议, 使用"ip+port"接收请求，再转发到对应的机器; 四层负载均衡比较灵活, 可以做任何基于tcp/ip协议的软件的负载均衡。
七层负载均衡: 从第七层"应用层"开始, 基于http协议, 根据虚拟的url或IP，主机名接收请求，再转向相应的处理服务器。七层负载均衡适用于web服务器的负载均衡。

总的来说:
-  LVS  提供四层负载均衡 ;
-  Haproxy  提供七层负载均衡, 但它比较灵活, 四层负载均衡也可以做 ;
-  Nginx  一般提供的是七层负载均衡, 但是从Nginx1.9.0版本后, 可以通过stream模块做四层负载均衡 ;
-  这三种负载均衡都提供健康检查,故障转移, 自动切换机制; 负载均衡层发生故障时, 通过漂移VIP资源来实现故障无感知切换, 待故障修复后再接回自己的VIP资源(这个具体要根据配置中的策略而定); 后端节点发生故障后,会自动被踢出集群环境, 待故障修复后再回到集群环境中.
-  负载均衡层必须和后端节点之间要能正常通信, 如果负载均衡层只有一个网卡设备, 比如eth0, 则心跳线功能(Keepalive和Heartbeat)和与后端节点通信都走这个eth0网卡(VIP地址也是eth0网段); 如果负载均衡层有两个网卡设备, 比如eth0(内网)和eth1(外网), 则eth0网卡用于和后端节点(也是eth0)通信, eth1网卡用于心跳线功能(VIP地址是eth1网段);

下面是运维场景中web网站常用的几种高可用架构图, 简单展示下:
1)  LVS+Keepalived+Tomcat/Nginx/其他web服务

2) Haproxy+Heartbeat+Tomcat/Nginx/其他web服务

3) Haproxy+Keepalived+Tomcat/Nginx/其他web服务

4) Nginx+Keepalived+Tomcat/Nginx/其他web服务

当然, 除了上面常用的几种搭配方式, 其他搭配也是可以的, 比如 LVS+Heartbeat也是可以的.; 其他应用也可以使用这些部署高可用, 比如LVS+Keepalive+Mysql, Heartbeat+haproxy+MySQL, Redis+Keepalived等.

实现高可用的目的: 一是防止单点故障，另一个是实现负载均衡。当然负载均衡也可以防止单点故障，但负载均衡器本来就会产生单点故障，用一个产生问题的方法解决产生的问题，那这个问题怎么解决? 其实真正从源头上解决单点故障这个问题, 需要使用如上所示Keepalived或Heartbeat, 它们两个可以解决单点故障问题（双机热备, VIP漂移）却不会引出新的单点故障问题; 然后再使用Haproxy, Nginx 或LVS做负载均衡，后端再跟web服务或其他应用服务多节点, 这样即可做成负载均衡高可用方案了。