HA

haproxy作为一个『代理软件』如果当工作与 HTTP 模式下，所有经由haproxy的的连接的请求和响应都取决于 frondend 中配置的 『http_connection_mode』 即 haproxy 中 frontend 与 backend 的组合，而haproxy 支持 3 种连接模式： KAL keep alive: frontend 中配置为 http-keep-alive ; 这是默认模式，这也是http中的keepalive 表示所有请求和响应都得到处理，连接保持打开状态，但在响应和新请求之间处于空闲状态。 SCL server close : frontend 中配置为 http-server-close ; 接收到响应结束后，面向服务器的连接关闭，但面向客户端的连接保持打开状态 CLO close: frontend 中配置为 httpclose ；连接在响应结束后关闭，并在两个方向上附加 “Connection: close” 。 下列矩阵表示的是通过 frondend 与 backend 之间两端的代理模式，这个模式是对称的 text 1 2 3 4 5 6 7 | KAL | SCL | CLO ----+-----+-----+---- KAL | KAL | SCL | CLO ----+-----+-----+---- mode SCL | SCL | SCL | CLO ----+-----+-----+---- CLO | CLO | CLO | CLO 对于http选项的说明 选项 说明 forwardfor 这个选项同时存在于backend 与 frontend端，但backend中的优先级超过frontend 如果同时设置了这个参数，那么 backend段的子参数将优先与 frontend 一端 httpchk 启用http协议检查来检测server的健康状态，默认情况下状态检查是仅建立一个tcp连接 httpclose 这个选项代表了haproxy 对于http协议持久连接方便的配置 Reference：configuration....

haproxy1 VS haproxy2 haproxy2由 2019-06-16 被发布，对于与haproxy1版本来说，haproxy 2.0 增加了对云原生的支持，这使得haproxy 2.0 更适用于云原生环境，对比于 haproxy1.0 在2001年发布来，到 1.9.16 在 2020/07/31 最后一次更新也代表haproxy1.0的结束维护 为什么选择haproxy2.0 haproxy2.0的核心功能就是集成了云原生架构的支持。包含L7重试, Prometheus metrics, 流量镜像 (traffic shadowing), 多语言可扩展性, gRPC 。haproxy2.0 还增加 基于haproxy2.0 的 Kubernetes Ingress Controller 和强大的 HAProxy Data Plane API，这提供了用于配置和管理 HAProxy 的 REST API 安装haproxy2.0 对于 Ubuntu/Debian 来说，社区版haproxy提供了更友好的安装方式，用户直接添加对应仓库可以直接安装最新版本的haproxy Debian/Ubuntu HAProxy packages 对于 CentOS/Fedora 来说，只有Fedora 仓库提供了较为新版的haproxy，通常来在这类平台的Linux都是通过编译安装haproxy 下载haproxy2.6源码 [ haproxy下载 ] 安装依赖包 bash 1 yum install gcc pcre-devel openssl-devel tar make -y 编译程序 bash 1 2 3 4 5 6 7 8 9 tar xf haproxy-2....

haproxy 介绍 haproxy是一个开源的、高性能的基于TCP和HTTP应用代理的高可用的、负载均衡服务软件，它支持双机热备、高可用、负载均衡、虚拟主机、基于TCP和HTTP的应用代理、图形界面查看信息等功能。其配置简单、维护方便，而且拥有很好的对服务器节点的健康检查功能(相当于keepalived健康检查)，当其代理的后端服务器出现故障时，haproxy会自动的将该故障服务器摘除，当故障的服务器恢复后，haproxy还会自动将该服务器自动加入进来提供服务。 LVS/NGINX对比 haproxy 特别适用于那些高负载、访问量很大，但又需要会话保持及七层应用代理的业务应用。haproxy运行在今天的普通的服务器硬件上，几乎不需要进行任何的优化就可以支持数以万计的并发连接。并且它的运行模式使得它可以很简单、轻松、安全的整合到各种己有的网站架构中，同时，haproxy的代理模式，可以使得所有应用服务器不会暴露到公共网络上，即后面的节点服务器不需要公网IP地址。 从1.3版本起，haproxy软件引入了frontend,backend的功能，frontend (ad规则匹配)可以让运维管理人员根据任意HTTP请求头内容做规则匹配，然后把请求定向到相关的backend(这个是事先定义好的多个server pools，等待前端把请求转过来的服务器组)。通过frontend和backend，我们可以很容易的买现haproxy的各种7层应用代理功能。 haproxy代理模式 haproxy支持两种主要代理模式： 1、基于4层的tcp应用代理(例如:可用于邮件服务、内部协议通信服务器、MySQL、HTTPS服务等)。 2、基于7层的http代理。在4层tcp代理模式下，haproxy仅在客户端和服务器之间进行流量转发。但是在7层http代理模式下，haproxy会分析应用层协议，并且能通过允许、拒绝、交换、增加、修改或者删除请求(request)或者回应(response)里指定内容来控制协议。 官方网站:www.haproxy.org haproxy 解决方案拓扑图 haproxy L4负载均衡应用架构拓扑 haproxy软件的四层tcp应用代理非常优秀，且配置非常简单、方便，比LVS和Nginx的配置要简单很多，首先，配置haproxy不需要在RS端做任何特殊配置 (只要对应服务开启就OK)就可以实现应用代理，其次，haproxy的配置语法和增加虚拟主机功能等也比lvs/nginx简单。并且和商业版的NS (Netscaler)、F5, A10等负载均衡硬件的使用方法和在架构中的位置一模一样。下面是haproxy的Layer4层应用代理的拓扑结构图: 说明:由于haproxy软件采用的是类NAT模式(本质不同)的应用代理，数据包来去都会经过haproxy，因此，在流量特别大的情况下(门户级别的流量)，其效率和性能不如LVS的DR模式负载均衡。 在一般的中小型公司，建议采用haproxy做负载均衡，而不要使用LVS或Nginx。为什么强调中小型公司呢?换句话说，千万PV级别以下直接使用haproxy做负载均衡，会让我们负责维护的运维管理人员配置简单、快速、维护方便，出问题好排查。 haproxy L7负载均衡应用架构拓扑 haproxy软件的最大优势在于其7层的根据URL请求头应用过滤的功能以及sesson会话功能，在门户网站的高并发生产架构中，haproxy软件一般用在4层LVS负载均衡软件的下一层，或者像haproxy官方推荐的也可以挂在硬件负载均衡althon, NS, F5, A10下使用，其表现非常好。从2009年起taobao，京东商城的业务也大面积使用了haproxy作为7层CACHE应用代理。 安装haproxy 模拟真实环境 搭建合适的模拟环境是一个人学习能力的重要体现。例如：人类第一次上太空也没有真正的环境，但是想去太空就是要自己动手去搭建逼真的模拟环境。实验多了就是经验，自然就有解除生产环境的机会了。 名称 接口 IP 用途 MASTER eth0 10.0.0.7 外网管理IP用于WAN数据转发 eth1 172.16.1.7 内网管理IP，用于LAN数据转发 eth2 10.0.10.7 用于服务器间心跳连接（直连） VIP 10.0.0.17 用于提供应用程序A挂载服务 BACKUP eth0 10.0.0.8 外网管理IP，用于WAN数据转发 eth1 172.16.1.8 内网管理IP，用于LAN数据转发 eth2 10.0.10.8 用于服务器间心跳连接（直连） VIP 10.0.0.8 用于提供应用程序B挂载服务 下载安装haproxy 下载地址：http://www.haproxy.org/download/ 文档地址：http://www.haproxy.org/download/1.7/doc/configuration.txt 编译haproxy bash 1 2 3 4 make TARGET=linux2628 ARCH=x86_64 # <==64位编译配置 make TARGET=linux2628 ARCH=i386 # <==32位编译配置 make PREFIX=/app/haproxy-1....

Keepalived介绍 Keepalived软件起初是专为LVS负载均衡软件设计的，用来管理并监控LVS集群系统中各个服务节点的状态，后来又加入了可以实现高可用的VRRP功能。因此，Keepalived除了能够管理LVS软件外，还可以作为其他服务（例如：Nginx、Haproxy、MySQL等）的高可用解决方案软件。 Keepalived软件主要是通过VRRP协议实现高可用功能的。VRRP是Virtual Router Redundancy Protocol（虚拟路由器冗余协议）的缩写，VRRP出现的目的就是为了解决静态路由单点故障问题的，它能够保证当个别节点宕机时，整个网络可以不间断地运行。所以，Keepalived一方面具有配置管理LVS的功能，同时还具有对LVS下面节点进行健康检查的功能，另一方面也可实现系统网络服务的高可用功能。 Keepalived服务的三个重要功能 管理LVS负载均衡软件 早期的LVS软件，需要通过命令行或脚本实现管理，并且没有针对LVS节点的健康检查功能。为了解决LVS的这些使用不便的问题，Keepalived就诞生了，可以说，Keepalived软件起初是专为解决LVS的问题而诞生的。因此，Keepalived和LVS的感情很深，它们的关系如同夫妻一样，可以紧密地结合，愉快地工作。Keepalived可以通过读取自身的配置文件，实现通过更底层的接口直接管理LVS的配置以及控制服务的启动、停止等功能，这使得LVS的应用更加简单方便了。LVS和Keepalived的组合应用不是本章的内容范围。 实现对LVS集群节点健康检查功能（healthcheck） 前文已讲过，Keepalived可以通过在自身的keepalived.conf文件里配置LVS的节点IP和相关参数实现对LVS的直接管理；除此之外，当LVS集群中的某一个甚至是几个节点服务器同时发生故障无法提供服务时，Keepalived服务会自动将失效的节点服务器从LVS的正常转发队列中清除出去，并将请求调度到别的正常节点服务器上，从而保证最终用户的访问不受影响；当故障的节点服务器被修复以后，Keepalived服务又会自动地把它们加入到正常转发队列中，对客户提供服务。 作为系统网络服务的高可用功能（failover） Keepalived可以实现任意两台主机之间，例如Master和Backup主机之间的故障转移和自动切换，这个主机可以是普通的不能停机的业务服务器，也可以是LVS负载均衡、Nginx反向代理这样的服务器。 Keepalived高可用功能实现的简单原理为，两台主机同时安装好Keepalived软件并启动服务，开始正常工作时，由角色为Master的主机获得所有资源并对用户提供服务，角色为Backup的主机作为Master主机的热备；当角色为Master的主机失效或出现故障时，角色为Backup的主机将自动接管Master主机的所有工作，包括接管VIP资源及相应资源服务；而当角色为Master的主机故障修复后，又会自动接管回它原来处理的工作，角色为Backup的主机则同时释放Master主机失效时它接管的工作，此时，两台主机将恢复到最初启动时各自的原始角色及工作状态。 说明：Keepalived的高可用功能是本章的重点，后面除了讲解Keepalived高可用的功能外，还会讲解Keepalived配合Nginx反向代理负载均衡的高可用的实战案例。 Keepalived高可用故障切换转移原理 Keepalived高可用服务对之间的故障切换转移，是通过VRRP（Virtual Router Redundancy Protocol，虚拟路由器冗余协议）来实现的。 在Keepalived服务正常工作时，主Master节点会不断地向备节点发送（多播的方式）心跳消息，用以告诉备Backup节点自己还活着，当主Master节点发生故障时，就无法发送心跳消息，备节点也就因此无法继续检测到来自主Master节点的心跳了，于是调用自身的接管程序，接管主Master节点的IP资源及服务。而当主Master节点恢复时，备Backup节点又会释放主节点故障时自身接管的IP资源及服务，恢复到原来的备用角色。 什么是VRRP VRRP，全称Virtual Router Redundancy Protocol，中文名为虚拟路由冗余协议，VRRP的出现就是为了解决静态路由的单点故障问题，VRRP是通过一种竞选机制来将路由的任务交给某台VRRP路由器的。 VRRP早期是用来解决交换机、路由器等设备单点故障的，下面是交换、路由的Master和Backup切换原理描述，同样适用于Keepalived的工作原理。 在一组VRRP路由器集群中，有多台物理VRRP路由器，但是这多台物理的机器并不是同时工作的，而是由一台称为Master的机器负责路由工作，其他的机器都是Backup。Master角色并非一成不变的，VRRP会让每个VRRP路由参与竞选，最终获胜的就是Master。获胜的Master有一些特权，比如拥有虚拟路由器的IP地址等，拥有系统资源的Master负责转发发送给网关地址的包和响应ARP请求。 VRRP通过竞选机制来实现虚拟路由器的功能，所有的协议报文都是通过IP多播（Multicast）包（默认的多播地址224.0.0.18）形式发送的。虚拟路由器由VRID（范围0-255）和一组IP地址组成，对外表现为一个周知的MAC地址：00-00-5E-00-01-{VRID}。所以，在一个虚拟路由器中，不管谁是Master，对外都是相同的MAC和IP（称之为VIP）。客户端主机并不需要因Master的改变而修改自己的路由配置。对它们来说，这种切换是透明的。 在一组虚拟路由器中，只有作为Master的VRRP路由器会一直发送VRRP广播包（VRRP Advertisement messages），此时Backup不会抢占Master。当Master不可用时，Backup就收不到来自Master的广播包了，此时多台Backup中优先级最高的路由器会抢占为Master。这种抢占是非常快速的（可能只有1秒甚至更少），以保证服务的连续性。出于安全性考虑，VRRP数据包使用了加密协议进行了加密。 如果你在面试时，要你解答Keepalived的工作原理，建议用自己的话回答如下内容，以下为对面试官的表述： Keepalived高可用对之间是通过VRRP通信的： VRRP，全称Virtual Router Redundancy Protocol，中文名为虚拟路由冗余协议，VRRP的出现是为了解决静态路由的单点故障。 VRRP是通过一种竞选协议机制来将路由任务交给某台VRRP路由器的。 VRRP用IP多播的方式（默认多播地址（224.0.0.18））实现高可用对之间通信。 工作时主节点发包，备节点接包，当备节点接收不到主节点发的数据包的时候，就启动接管程序接管主节点的资源。备节点可以有多个，通过优先级竞选，但一般Keepalived系统运维工作中都是一对。 VRRP使用了加密协议加密数据，但Keepalived官方目前还是推荐用明文的方式配置认证类型和密码。 Keepalived服务的工作原理 介绍完了VRRP，接下来我再介绍一下Keepalived服务的工作原理： Keepalived高可用对之间是通过VRRP进行通信的，VRRP是通过竞选机制来确定主备的，主的优先级高于备，因此，工作时主会优先获得所有的资源，备节点处于等待状态，当主挂了的时候，备节点就会接管主节点的资源，然后顶替主节点对外提供服务。 在Keepalived服务对之间，只有作为主的服务器会一直发送VRRP广播包，告诉备它还活着，此时备不会抢占主，当主不可用时，即备监听不到主发送的广播包时，就会启动相关服务接管资源，保证业务的连续性。接管速度最快可以小于1秒。 Keepalived高可用服务搭建 安装Keepalived 通过官方地址获取Keepalived源码软件包编译安装 sh 1 2 3 4 ./configure \ --prefix=/app/keepalived-\ --mandir=/usr/local/share/man make && make install 复制命令到/usr/sbin下 sh 1 ln -s /app/keepalived-1.3.5/sbin/keepalived /usr/sbin/ keepalived默认会读取/etc/keepalived/keepalived.conf配置文件...

LVS概述 负载均衡(Load Balance)集群提供了一种廉价、有效、透明的方法，来扩展网络设备和服务器的负载、带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。 搭建负载均衡服务的需求 把单台计算机无法承受的大规模的并发访问或数据流量分担到多台节点设备上分别处理，减少用户等待响应的时间，提升用户体验. 单个重负载的运算分担到多台节点设备上做并发处理，每个节点设备处理结束后，将结果汇总，返回给用户，系统处理能力得到大幅度提高。 7*24小时服务保证，任意一个或多个有限后面节点设备宕机，要求不能影响业务。 在负载均衡集群中，所有计算机节点都应该提供相同的服务。集群负载均衡器所截获所有对该服务的入站请求。然后将这些请求尽可能的平均分配在所有集群节点上。 LVS (Linux Virtual Server)介绍 LVS是Linux Virtual Server的简写，意即Linux虚拟服务器，是一个虚拟的服务器集群系统，可在UNIX、Linux平台下实现负载均衡集群功能。该项目在1998年5月由章文嵩博士组织成立，是中国国内最早出现的自由软件项目之一 LVS项目介绍 http://www.linuxvirtualserver.org/zh/lvs1.html LVS集群的体系结构 http://www.linuxvirtualserver.org/zh/lvs2.html LVS集群中的IP负载均衡技术 http://www.linuxvirtualserver.org/zh/lvs3.html LVS集群的负载调度 http://www.linuxvirtualserver.org/zh/lvs4.html IPVS（LVS）发展史 早在2.2内核时，IPVS就已经以内核补丁的形式出现。 从2.4.23版本开始，IPVS软件就是合并到Linux内核的常用版本的内核补丁的集合。 从2.4.24以后IPVS已经成为Linux官方标准内核的一部分。 IPVS软件工作层次图 从上图可以看出，LVS负载均衡调度技术是在Linux内核中实现的，因此，被称之为Linux虚拟服务器（Linux virtual Server）。我们使用该软件配置LVS时候，不能直接配置内核中的ipvs，而需要使用ipvs的管理工具ipsadm进行管理. LVS技术点小结： 真正实现调度的工具是IPVS， 工作在Linux内核层面 LVS自导IPVS管理工具是ipvsadm keepalived实现管理IPVS及负载均衡器的高可用。 RedHat工具Piranha WEB管理实现调度的工具IPVS。 LVS体系结构与工作原理简单描述 LVS集群负载均衡器接受服务的所有入站客户端计算机请求，并根据调度算法决定那个集群几点应该处理回复请求。负载均衡器简称(LB)有时也被成为LVS Director简称Director LVS虚拟服务器的体系结构如下图所示，一组服务器通过告诉的局域网或者地理分布的广域网互相连接，在他们的前端有一个负载调度器（Load Balancer）。负载调度器能无缝地将网络请求调度到真实服务器上，从而使得服务器集群的结构对客户是透明的，客户访问集群系统提供的网络服务就像访问一台高性能、高可用的服务器一样。客户程序不收服务器集群的影响不需作任何修改。胸的伸缩性通过在服务集群中透明的加入和删除一各节点来达到，通过检测节点或服务进程故障和正确地重置系统达到高可用性。由于我们的负载调度技术是在Linux内核中实现的，我们称之为Linux虚拟服务器（Linux Virtual Server）。 LVS基本工作过程图 **LVS基本工作过程图1：带颜色的小方块代表不同的客户端请求 LVS基本工作过程图2： 不同的客户端请求小方块经过负载均衡器，通过指定的分配策略被分发到后面的机器上 LVS基本工作过程图3： LVS基本工作过程图4： LVS相关术语命名约定 名称 缩写 说明 虚拟IP地址(Virtual IP Address) VIP VIP为Direcort用于向客户端计算机提供IP地址.如www.baidu.com域名就要解析到VIP上提供服务 真实IP地址(Real Server IP Address) RIP 在集群下面节点上使用的IP地址，物理IP地址 Director的IP地址(Director IP Address) DIP Director用于连接内外网络的IP地址，物理网卡上的IP地址，是负载均衡器上的IP 客户端主机IP地址(Client IP Address) CIP 客户端用户计算机请求集群服务器的IP地址，该地址用作发送给集群的请求的源IP地址 LVS集群内部的节点称为真实服务器(Real Server)，也叫做集群节点。请求集群服务的计算机称为客户端计算机。...