三高2
JSESSIONID的简单说明
原文地址：http://blog.csdn.net/chunqiuwei/article/details/23461995
1）第一次访问服务器的时候，会在响应头里面看到Set-Cookie信息（只有在首次访问服务器的时候才会在响应头中出现该信息）
。
上面的图JSESSIONID=ghco9xdnaco31gmafukxchph;Path=/acr，
浏览器会根据响应头的set-cookie信息设置浏览器的cookie并保存之
注意此cookie由于没有设置cookie有效日期，所以在关闭浏览器的情况下会丢失掉这个cookie。
2）当再次请求的时候（非首次请求），浏览器会在请求头里将cookie发送给服务器(每次请求都是这样)
（JSESSIONID=ghco9xdnaco31gmafukxchph）
不难发现这个的jsessionid和上面的jsessionid是一样的
3）为什么除了首次请求之外每次请求都会发送这个cookie呢（在这里确切地说是发送这个jsessionid）？
事实上当用户访问服务器的时候会为每一个用户开启一个session，浏览器是怎么判断这个session到底是属于哪个用户呢？jsessionid的作用就体现出来了：jsessionid就是用来判断当前用户对应于哪个session。换句话说服务器识别session的方法是通过jsessionid来告诉服务器该客户端的session在内存的什么地方。
事实上jsessionid ==request.getSession().getId()
4)总结，jsessionid的工作流程可以简单用下面的图表示：
性负载均衡（Elastic Load Balance，ELB）
https://support.huaweicloud.com/elb/index.html
弹性负载均衡（Elastic Load Balance，ELB）是将访问流量根据转发策略分发到后端多台弹性云服务器的流量分发控制服务，可以通过流量分发扩展应用系统对外的服务能力，提高应用程序的容错能力。
弹性负载均衡（Elastic Load Balance，简称ELB）是将访问流量根据转发策略分发到后端多台 服务器 的流量分发控制服务。弹性负载均衡可以通过流量分发扩展应用系统对外的服务能力，通过消除单点故障提升应用系统的可用性。
弹性负载均衡具有以下优势：
- 高性能
集群支持最高1亿并发连接，满足用户的海量业务访问需求。
- 高可用
采用集群化部署，支持多可用区的同城双活容灾，无缝实时切换。
- 灵活扩展
根据应用流量自动完成分发，与弹性伸缩服务无缝集成，灵活扩展用户应用的对外服务能力。
- 简单易用
快速部署ELB，实时生效，支持多种协议、多种调度算法可选，用户可以高效地管理和调整分发策略。
- 可靠性
仅增强型负载均衡具有，公网私网均支持跨可用区双活容灾，支持一致性Hash，流量分发更均衡。
- 运维
仅增强型负载均衡具有，支持按监听器粒度监控性能指标，更方便客户业务统计。
弹性负载均衡的类型
弹性负载均衡支持经典型、增强型两种负载均衡。
- 经典型负载均衡：适用于访问量较小，应用模型简单的web业务。
- 增强型负载均衡：适用于访问量较大的web业务，提供基于域名和URL的路由均衡能力，实现更加灵活的业务转发。
两者的详细区别请参见 增强型与经典型负载均衡的功能区别 。
弹性负载均衡的组件
弹性负载均衡器接受来自客户端的传入流量并将请求转发到一个或多个可用区中的后端 服务器 。
您可以向您的弹性负载均衡器添加一个或多个监听器。监听器使用您配置的协议和端口检查来自客户端的连接请求，并根据您定义的转发策略将请求转发到一个后端服务器组里的后端 服务器 。
每个后端 服务器 组使用您指定的协议和端口号将请求转发到一个或多个后端 服务器 。
您可以开启健康检查功能，对每个后端服务器组配置运行状况检查。当后端某台 服务器 健康检查出现异常时，弹性负载均衡会自动将新的请求分发到其它健康检查正常的后端 服务器 上；而当该后端 服务器 恢复正常运行时，弹性负载均衡会将其自动恢复到弹性负载均衡服务中。
如何访问弹性负载均衡
可以使用以下方式访问和管理弹性负载均衡：
- 管理控制台
请使用管理控制台方式访问弹性负载均衡。可直接登录管理控制台，从主页选择“弹性负载均衡”。
- 查询API
通过调用API的方式访问弹性负载均衡，具体操作请参见 《弹性负载均衡API参考》 。
弹性负载均衡是如何工作的
您可以在弹性负载均衡服务中创建一个负载均衡器。该负载均衡器会接收来自客户端的请求，并将请求转发到一个或多个可用区的后端 服务器 中进行处理。请求的流量分发与负载均衡器配置的分配策略类型相关。
增强型负载均衡算法，支持以下三种调度算法：
- 加权轮询算法：根据后端服务器的权重，按顺序依次将请求分发给不同的服务器。它用相应的权重表示服务器的处理性能，按照权重的高低以及轮询方式将请求分配给各服务器，相同权重的服务器处理相同数目的连接数。常用于短连接服务，例如HTTP等服务。
- 加权最少连接：最少连接是通过当前活跃的连接数来估计服务器负载情况的一种动态调度算法。加权最少连接就是在最少连接数的基础上，根据服务器的不同处理能力，给每个服务器分配不同的权重，使其能够接受相应权值数的服务请求。常用于长连接服务，例如数据库连接等服务。
- 源IP算法：将请求的源IP地址进行Hash运算，得到一个具体的数值，同时对后端服务器进行编号，按照运算结果将请求分发到对应编号的服务器上。这可以使得对不同源IP的访问进行负载分发，同时使得同一个客户端IP的请求始终被派发至某特定的服务器。该方式适合负载均衡无cookie功能的TCP协议。
- 轮询算法：按顺序把每个新的连接请求分配给下一个服务器，最终把所有请求平分给所有的服务器。常用于短连接服务，例如HTTP等服务。
- 最少连接：通过当前活跃的连接数来估计服务器负载情况的一种动态调度算法，系统把新的连接请求分配给当前连接数目最少的服务器。常用于长连接服务，例如数据库连接等服务。
- 源IP算法：将请求的源IP地址进行Hash运算，得到一个具体的数值，同时对后端服务器进行编号，按照运算结果将请求分发到对应编号的服务器上。这可以使得对不同源IP的访问进行负载分发，同时使得同一个客户端IP的请求始终被派发至某特定的服务器。该方式适合负载均衡无cookie功能的TCP协议。
图1 展示弹性负载均衡器使用加权轮询算法的流量分发流程。假设可用区内有4台权重相同的后端 服务器 ，负载均衡器节点会将25%的客户端流量分发到其可用区中的每一台后端 服务器 。
增强型与经典型负载均衡的功能区别
弹性负载均衡有两种不同的负载均衡，分别是增强型负载均衡和经典型负载均衡，便于用户根据不同的应用场景和功能需求选择合适的负载均衡器类型。
- 经典型负载均衡：适用于访问量较小，应用模型简单的web业务。
- 增强型负载均衡：适用于访问量较大的web业务，提供基于域名和URL的路由均衡能力，实现更加灵活的业务转发。
增强型负载均衡对比经典型负载均衡，提供了更丰富的HTTP和HTTPS转发能力，同时在转发性能和稳定性上也有较大提升。两者具体的功能差异如 表1 所示。（“√”表示支持，“—”表示不支持。）
|
功能 |
经典型负载均衡 |
增强型负载均衡 |
|---|---|---|
|
支持公网和私网负载均衡 |
√ |
√ |
|
支持四层（TCP/UDP）和七层负载均衡（HTTP/HTTPS） |
√（私网类型不支持UDP协议） |
√ |
|
支持轮询 /最少连接/源IP |
√ |
√ |
|
支持会话保持 |
√ |
√ |
|
支持WebSocket协议 |
√ |
√ |
|
支持按域名和URL转发 |
— |
√ |
|
支持HTTP/2 |
— |
√ |
|
支持后端服务器为ECS |
√ |
√ |
|
支持访问控制（白名单） |
— |
√ |
|
支持标准OpenStack API |
— |
√ |
|
支持后端服务器为裸机 |
— |
√ |
|
支持SNI多证书特性 |
— |
√ |
|
支持SSL协议/加密算法可选 |
√ |
— |
|
支持访问日志 |
— |
√ |
|
支持权重 |
— |
√ |
|
支持修改证书内容 |
— |
√ |
|
支持双向认证 |
— |
√ |
|
支持HTTP重定向 |
— |
√ |
|
支持获取弹性公网IP |
— |
√ |
应用场景
- 使用ELB为高访问量业务进行流量分发
对于业务量访问较大的业务，可以通过ELB设置相应的转发策略，将访问量均匀的分到多个后端处理。例如大型门户网站，移动应用市场等。
同时您还可以开启会话保持功能，保证同一个客户请求转发到同一个后端，从而提升访问效率，如 图1 所示。
图1 会话保持流量分发
- 使用ELB和AS为潮汐业务弹性分发流量
对于存在潮汐效应的业务，结合弹性伸缩服务，可以随时在ELB上添加和移除后端，更好的提升业务的灵活扩展能力，如 图2 所示。例如电商，手游，直播网站等。
图2 灵活扩展
- 使用ELB消除单点故障
对于可靠性有较高要求的业务，可以在负载均衡器上添加多个后端 云服务器 。负载均衡器会通过健康检查及时发现并屏蔽有故障的 云服务器 ，并将流量转发到其他正常运行的后端 云服务器 ，确保业务不中断，如 图3 所示。
例如官网，计费业务，Web业务等。
图3 消除单点故障
- 使用ELB跨可用区特性实现业务容灾部署
对于可靠性和容灾有很高要求的业务，弹性负载均衡可将流量跨可用区进行分发，建立实时的业务容灾部署。即使出现某个可用区网络故障，负载均衡器仍可将流量转发到其他可用区的后端 云服务器 进行处理，如 图4 所示。
例如银行业务，警务业务，大型应用系统等。
图4 多可用区部署
与其他服务关系
|
交互功能 |
服务名称 |
相关内容 |
|---|---|---|
|
创建ELB时需要使用虚拟私有云服务创建的弹性公网IP、带宽。 |
虚拟私有云（Virtual Private Cloud，VPC） |
|
|
当配置了负载均衡服务后，弹性伸缩在添加和移除云服务器时，自动在负载均衡服务中添加和移除云服务器。 |
弹性伸缩（Auto Scaling，AS） |
|
|
需要统一身份认证提供鉴权。 |
统一身份认证服务（Identity and Access Management, IAM） |
|
|
使用云审计服务记录弹性负载均衡服务的资源操作。 |
云审计服务（Cloud Trace Service，CTS） |
|
|
当用户开通了弹性负载均衡服务后，无需额外安装其他插件，即可在云监控查看对应服务的实例状态。 |
云监控服务（Cloud Eye Service） |
|
|
当用户购买了Anti-DDoS服务后，配置了负载均衡器的公网IP，确保了弹性负载均衡服务免受外部攻击，提高安全可靠性。 |
Anti-DDoS流量清洗服务（Anti-DDoS） |
|
|
配置访问日志时需要您对接云日志服务，查看和分析对七层负载均衡HTTP和HTTPS进行请求的详细访问日志记录。 |
云日志服务（Log Tank Service，LTS） |
Keepalived原理
https://blog.csdn.net/qq_24336773/article/details/82143367
Keepalived简介
Keepalived是Linux下一个轻量级别的高可用解决方案。高可用：广义来讲，是指整个系统的高可用行；狭义的来讲就是主机的冗余和接管。
它与HeartBeat实现类似的功能，都可以实现服务或者网络的高可用，但是又有差别，HeartBeat是一个专业的、功能完善的高可用软件，它提供HA软件所需的基本功能，比如：心跳检测、资源接管，检测集群中的服务，在集群节点转移共享IP地址的所有者等等。HeartBeat功能强大，但是部署和使用相对比较麻烦，与HeartBeat相比，Keepalived主要是通过虚拟路由冗余来实现高可用功能，虽然它没有HeartBeat功能强大，但是Keepalived部署和使用非常的简单，所有配置只需要一个配置文件即可以完成。
Keepalived是什么？
Keepalived起初是为LVS设计的，专门用来监控集群系统中各个服务节点的状态，它根据TCP/IP参考模型的第三、第四层、第五层交换机制检测每个服务节点的状态，如果某个服务器节点出现异常，或者工作出现故障，Keepalived将检测到，并将出现的故障的服务器节点从集群系统中剔除，这些工作全部是自动完成的，不需要人工干涉，需要人工完成的只是修复出现故障的服务节点。
后来Keepalived又加入了VRRP的功能，VRRP（VritrualRouterRedundancyProtocol,虚拟路由冗余协议)出现的目的是解决静态路由出现的单点故障问题，通过VRRP可以实现网络不间断稳定运行，因此Keepalived一方面具有服务器状态检测和故障隔离功能，另外一方面也有HAcluster功能。
健康检查和失败切换是keepalived的两大核心功能。所谓的健康检查，就是采用tcp三次握手，icmp请求，http请求，udp echo请求等方式对负载均衡器后面的实际的服务器(通常是承载真实业务的服务器)进行保活；而失败切换主要是应用于配置了主备模式的负载均衡器，利用VRRP维持主备负载均衡器的心跳，当主负载均衡器出现问题时，由备负载均衡器承载对应的业务，从而在最大限度上减少流量损失，并提供服务的稳定性。
VRRP协议与工作原理
在现实的网络环境中。主机之间的通信都是通过配置静态路由或者(默认网关)来完成的，而主机之间的路由器一旦发生故障，通信就会失效，因此这种通信模式当中，路由器就成了一个单点瓶颈，为了解决这个问题，就引入了VRRP协议。
VRRP协议是一种容错的主备模式的协议，保证当主机的下一跳路由出现故障时，由另一台路由器来代替出现故障的路由器进行工作，通过VRRP可以在网络发生故障时透明的进行设备切换而不影响主机之间的数据通信。
虚拟路由器：虚拟路由器是VRRP备份组中所有路由器的集合，它是一个逻辑概念，并不是正真存在的。从备份组外面看备份组中的路由器，感觉组中的所有路由器就像一个 一样，可以理解为在一个组中： 主路由器+所有备份路由器=虚拟路由器。虚拟路由器有一个虚拟的IP地址和MAC地址。主机将虚拟路由器当作默认网关。虚拟MAC地址的格式为00-00-5E-00-01-{VRID}。通常情况下，虚拟路由器回应ARP请求使用的是虚拟MAC地址，只有虚拟路由器做特殊配置的时候，才回应接口的真实MAC地址。
主路由器（MASTER）：虚拟路由器通过虚拟IP对外提供服务，而在虚拟路由器内部同一时间只有一台物理路由器对外提供服务，这台提供服务的物理路由器被称为主路由器。一般情况下Master是由选举算法产生，它拥有对外服务的虚拟IP，提供各种网络功能，如：ARP请求，ICMP数据转发等。
备份路由器（BACKUP）：虚拟路由器中的其他物理路由器不拥有对外的虚拟IP，也不对外提供网络功能，仅接受MASTER的VRRP状态通告信息，这些路由器被称为备份路由器。当主路由器失败时，处于BACKUP角色的备份路由器将重新进行选举，产生一个新的主路由器进入MASTER角色，继续提供对外服务，整个切换对用户来说是完全透明的。
VRRP选举机制
VRRP路由器在运行过程中有三种状态：
1. Initialize状态： 系统启动后就进入Initialize，此状态下路由器不对VRRP报文做任何处理；
2. Master状态；
3. Backup状态；
一般主路由器处于Master状态，备份路由器处于Backup状态。
VRRP使用选举机制来确定路由器的状态，优先级选举：
1.VRRP组中IP拥有者。如果虚拟IP地址与VRRP组中的某台VRRP路由器IP地址相同，则此路由器为IP地址拥有者，这台路由器将被定位主路由器。
2.比较优先级。如果没有IP地址拥有者，则比较路由器的优先级，优先级的范围是0~255，优先级大的作为主路由器
3.比较IP地址。在没有Ip地址拥有者和优先级相同的情况下，IP地址大的作为主路由器。
如下图所示，虚拟IP为10.1.1.254，在VRRP组中没有IP地址拥有者，则比较优先级，很明显RB和RA的优先级要大于RC，则比较RA和RB的IP地址，RB的IP地址大。所以RB为组中的主路由器。
工作过程
路由器使用VRRP 功能后，会根据优先级确定自己在备份组中的角色。优先级高的路由器成为Master 路由器，优先级低的成为Backup 路由器。Master 拥有对外服务的虚拟IP，提供各种网络功能，并定期发送VRRP 报文，通知备份组内的其他设备自己工作正常；Backup 路由器只接收Master 发来的报文信息，用来监控Master 的运行状态。当Master 失效时，Backup 路由器进行选举，优先级高的Backup 将成为新的Master 。
在抢占方式下，当Backup 路由器收到VRRP 报文后，会将自己的优先级与报文中的优先级进行比较。如果大于通告报文中的优先级，则成为Master 路由器；否则将保持Backup状态；
在非抢占方式下，只要Master 路由器没有出现故障，备份组中的路由器始终保持Master 或Backup 状态，Backup 路由器即使随后被配置了更高的优先级也不会成为Master 路由器；
如果Backup 路由器的定时器超时后仍未收到Master 路由器发送来的VRRP报文，则认为Master 路由器已经无法正常工作，此时Backup 路由器会认为自己是Master 路由器，并对外发送VRRP报文。备份组内的路由器根据优先级选举出Master 路由 器，承担报文的转发功能。
Keepalived的工作原理
Keepalived对服务器运行状态和故障隔离的工作原理：
Keepalived工作在TCP/IP参考模型的三层、四层、五层（物理层，链路层）：
网络层（3）：Keepalived通过ICMP协议向服务器集群中的每一个节点发送一个ICMP数据包(有点类似与Ping的功能)，如果某个节点没有返回响应数据包，那么认为该节点发生了故障，Keepalived将报告这个节点失效，并从服务器集群中剔除故障节点。
传输层（4）：Keepalived在传输层里利用了TCP协议的端口连接和扫描技术来判断集群节点的端口是否正常，比如对于常见的WEB服务器80端口。或者SSH服务22端口，Keepalived一旦在传输层探测到这些端口号没有数据响应和数据返回，就认为这些端口发生异常，然后强制将这些端口所对应的节点从服务器集群中剔除掉。
应用层（5）：，Keepalived的运行方式也更加全面化和复杂化，用户可以通过自定义Keepalived工作方式，例如：可以通过编写程序或者脚本来运行Keepalived，而Keepalived将根据用户的设定参数检测各种程序或者服务是否允许正常，如果Keepalived的检测结果和用户设定的不一致时，Keepalived将把对应的服务器从服务器集群中剔除。
Keepalived体系结构
Keepalived起初是为LVS设计的，由于Keeplalived可以实现对集群节点的状态检测，而IPVS可以实现负载均衡功能，因此,Keepalived借助于第三方模块IPVS就可以很方便地搭建一套负载均衡系统。在Keepalived当中IPVS模块是可配置的，如果需要负载均衡功能，可以在编译Keepalived时开打负载均衡功能，也可以通过编译参数关闭。
SchedulerI/OMultiplexer是一个I/O复用分发调度器，它负载安排Keepalived所有内部的任务请求；
Memory Mngt是一个内存管理机制，这个框架提供了访问内存的一些通用方法；
Control Plane 是keepalived的控制版面，可以实现对配置文件编译和解析；
Core componets 这部分主要包含了5个部分；
- Watchdog：是计算机可靠领域中极为简单又非常有效的检测工具，Keepalived正是通过它监控Checkers和VRRP进程的。
- Checkers:这是Keepalived最基础的功能，也是最主要的功能，可以实现对服务器运行状态检测和故障隔离。
- VRRP Stack:这是keepalived后来引用VRRP功能，可以实现HA集群中失败切换功能。负责负载均衡器之间的失败切换FailOver；
- IPVS wrapper:这个是IPVS功能的一个实现，IPVSwarrper模块将可以设置好的IPVS规则发送的内核空间并且提供给IPVS模块，最终实现IPVS模块的负载功能。
- Netlink Reflector：用来实现高可用集群Failover时虚拟IP(VIP)的设置和切换，
keepalived运行时，会启动3个进程，分别为：core(核心进程)，check和vrrp
- core：负责主进程的启动，维护和全局配置文件的加载；
- check：负责健康检查
- vrrp：用来实现vrrp协议
与heartbeat/corosync等比较
Heartbeat、Corosync、Keepalived这三个集群组件我们到底选哪个好，Heartbeat、Corosync是属于同一类型，Keepalived与Heartbeat、Corosync，根本不是同一类型的。Keepalived使用的vrrp虚拟路由冗余协议方式；Heartbeat或Corosync是基于主机或网络服务的高可用方式；简单的说就是，Keepalived的目的是模拟路由器的高可用，Heartbeat或Corosync的目的是实现Service的高可用。
所以一般Keepalived是实现前端高可用，常用的前端高可用的组合有，就是我们常见的LVS+Keepalived、Nginx+Keepalived、HAproxy+Keepalived。而Heartbeat或Corosync是实现服务的高可用，常见的组合有Heartbeat v3(Corosync)+Pacemaker+NFS+Httpd 实现Web服务器的高可用、Heartbeat v3(Corosync)+Pacemaker+NFS+MySQL 实现MySQL服务器的高可用。总结一下，Keepalived中实现轻量级的高可用，一般用于前端高可用，且不需要共享存储，一般常用于两个节点的高可用。而Heartbeat(或Corosync)一般用于服务的高可用，且需要共享存储，一般用于多节点的高可用。
Keepalived简介
Keepalived是Linux下一个轻量级别的高可用解决方案。高可用：广义来讲，是指整个系统的高可用行；狭义的来讲就是主机的冗余和接管。
它与HeartBeat实现类似的功能，都可以实现服务或者网络的高可用，但是又有差别，HeartBeat是一个专业的、功能完善的高可用软件，它提供HA软件所需的基本功能，比如：心跳检测、资源接管，检测集群中的服务，在集群节点转移共享IP地址的所有者等等。HeartBeat功能强大，但是部署和使用相对比较麻烦，与HeartBeat相比，Keepalived主要是通过虚拟路由冗余来实现高可用功能，虽然它没有HeartBeat功能强大，但是Keepalived部署和使用非常的简单，所有配置只需要一个配置文件即可以完成。
Keepalived是什么？
Keepalived起初是为LVS设计的，专门用来监控集群系统中各个服务节点的状态，它根据TCP/IP参考模型的第三、第四层、第五层交换机制检测每个服务节点的状态，如果某个服务器节点出现异常，或者工作出现故障，Keepalived将检测到，并将出现的故障的服务器节点从集群系统中剔除，这些工作全部是自动完成的，不需要人工干涉，需要人工完成的只是修复出现故障的服务节点。
后来Keepalived又加入了VRRP的功能，VRRP（VritrualRouterRedundancyProtocol,虚拟路由冗余协议)出现的目的是解决静态路由出现的单点故障问题，通过VRRP可以实现网络不间断稳定运行，因此Keepalived一方面具有服务器状态检测和故障隔离功能，另外一方面也有HAcluster功能。
健康检查和失败切换是keepalived的两大核心功能。所谓的健康检查，就是采用tcp三次握手，icmp请求，http请求，udp echo请求等方式对负载均衡器后面的实际的服务器(通常是承载真实业务的服务器)进行保活；而失败切换主要是应用于配置了主备模式的负载均衡器，利用VRRP维持主备负载均衡器的心跳，当主负载均衡器出现问题时，由备负载均衡器承载对应的业务，从而在最大限度上减少流量损失，并提供服务的稳定性。
VRRP协议与工作原理
在现实的网络环境中。主机之间的通信都是通过配置静态路由或者(默认网关)来完成的，而主机之间的路由器一旦发生故障，通信就会失效，因此这种通信模式当中，路由器就成了一个单点瓶颈，为了解决这个问题，就引入了VRRP协议。
VRRP协议是一种容错的主备模式的协议，保证当主机的下一跳路由出现故障时，由另一台路由器来代替出现故障的路由器进行工作，通过VRRP可以在网络发生故障时透明的进行设备切换而不影响主机之间的数据通信。
虚拟路由器：虚拟路由器是VRRP备份组中所有路由器的集合，它是一个逻辑概念，并不是正真存在的。从备份组外面看备份组中的路由器，感觉组中的所有路由器就像一个 一样，可以理解为在一个组中： 主路由器+所有备份路由器=虚拟路由器。虚拟路由器有一个虚拟的IP地址和MAC地址。主机将虚拟路由器当作默认网关。虚拟MAC地址的格式为00-00-5E-00-01-{VRID}。通常情况下，虚拟路由器回应ARP请求使用的是虚拟MAC地址，只有虚拟路由器做特殊配置的时候，才回应接口的真实MAC地址。
主路由器（MASTER）：虚拟路由器通过虚拟IP对外提供服务，而在虚拟路由器内部同一时间只有一台物理路由器对外提供服务，这台提供服务的物理路由器被称为主路由器。一般情况下Master是由选举算法产生，它拥有对外服务的虚拟IP，提供各种网络功能，如：ARP请求，ICMP数据转发等。
备份路由器（BACKUP）：虚拟路由器中的其他物理路由器不拥有对外的虚拟IP，也不对外提供网络功能，仅接受MASTER的VRRP状态通告信息，这些路由器被称为备份路由器。当主路由器失败时，处于BACKUP角色的备份路由器将重新进行选举，产生一个新的主路由器进入MASTER角色，继续提供对外服务，整个切换对用户来说是完全透明的。
VRRP选举机制
VRRP路由器在运行过程中有三种状态：
1. Initialize状态： 系统启动后就进入Initialize，此状态下路由器不对VRRP报文做任何处理；
2. Master状态；
3. Backup状态；
一般主路由器处于Master状态，备份路由器处于Backup状态。
VRRP使用选举机制来确定路由器的状态，优先级选举：
1.VRRP组中IP拥有者。如果虚拟IP地址与VRRP组中的某台VRRP路由器IP地址相同，则此路由器为IP地址拥有者，这台路由器将被定位主路由器。
2.比较优先级。如果没有IP地址拥有者，则比较路由器的优先级，优先级的范围是0~255，优先级大的作为主路由器
3.比较IP地址。在没有Ip地址拥有者和优先级相同的情况下，IP地址大的作为主路由器。
如下图所示，虚拟IP为10.1.1.254，在VRRP组中没有IP地址拥有者，则比较优先级，很明显RB和RA的优先级要大于RC，则比较RA和RB的IP地址，RB的IP地址大。所以RB为组中的主路由器。
工作过程
路由器使用VRRP 功能后，会根据优先级确定自己在备份组中的角色。优先级高的路由器成为Master 路由器，优先级低的成为Backup 路由器。Master 拥有对外服务的虚拟IP，提供各种网络功能，并定期发送VRRP 报文，通知备份组内的其他设备自己工作正常；Backup 路由器只接收Master 发来的报文信息，用来监控Master 的运行状态。当Master 失效时，Backup 路由器进行选举，优先级高的Backup 将成为新的Master 。
在抢占方式下，当Backup 路由器收到VRRP 报文后，会将自己的优先级与报文中的优先级进行比较。如果大于通告报文中的优先级，则成为Master 路由器；否则将保持Backup状态；
在非抢占方式下，只要Master 路由器没有出现故障，备份组中的路由器始终保持Master 或Backup 状态，Backup 路由器即使随后被配置了更高的优先级也不会成为Master 路由器；
如果Backup 路由器的定时器超时后仍未收到Master 路由器发送来的VRRP报文，则认为Master 路由器已经无法正常工作，此时Backup 路由器会认为自己是Master 路由器，并对外发送VRRP报文。备份组内的路由器根据优先级选举出Master 路由 器，承担报文的转发功能。
Keepalived的工作原理
Keepalived对服务器运行状态和故障隔离的工作原理：
Keepalived工作在TCP/IP参考模型的三层、四层、五层（物理层，链路层）：
网络层（3）：Keepalived通过ICMP协议向服务器集群中的每一个节点发送一个ICMP数据包(有点类似与Ping的功能)，如果某个节点没有返回响应数据包，那么认为该节点发生了故障，Keepalived将报告这个节点失效，并从服务器集群中剔除故障节点。
传输层（4）：Keepalived在传输层里利用了TCP协议的端口连接和扫描技术来判断集群节点的端口是否正常，比如对于常见的WEB服务器80端口。或者SSH服务22端口，Keepalived一旦在传输层探测到这些端口号没有数据响应和数据返回，就认为这些端口发生异常，然后强制将这些端口所对应的节点从服务器集群中剔除掉。
应用层（5）：，Keepalived的运行方式也更加全面化和复杂化，用户可以通过自定义Keepalived工作方式，例如：可以通过编写程序或者脚本来运行Keepalived，而Keepalived将根据用户的设定参数检测各种程序或者服务是否允许正常，如果Keepalived的检测结果和用户设定的不一致时，Keepalived将把对应的服务器从服务器集群中剔除。
Keepalived体系结构
Keepalived起初是为LVS设计的，由于Keeplalived可以实现对集群节点的状态检测，而IPVS可以实现负载均衡功能，因此,Keepalived借助于第三方模块IPVS就可以很方便地搭建一套负载均衡系统。在Keepalived当中IPVS模块是可配置的，如果需要负载均衡功能，可以在编译Keepalived时开打负载均衡功能，也可以通过编译参数关闭。
SchedulerI/OMultiplexer是一个I/O复用分发调度器，它负载安排Keepalived所有内部的任务请求；
Memory Mngt是一个内存管理机制，这个框架提供了访问内存的一些通用方法；
Control Plane 是keepalived的控制版面，可以实现对配置文件编译和解析；
Core componets 这部分主要包含了5个部分；
- Watchdog：是计算机可靠领域中极为简单又非常有效的检测工具，Keepalived正是通过它监控Checkers和VRRP进程的。
- Checkers:这是Keepalived最基础的功能，也是最主要的功能，可以实现对服务器运行状态检测和故障隔离。
- VRRP Stack:这是keepalived后来引用VRRP功能，可以实现HA集群中失败切换功能。负责负载均衡器之间的失败切换FailOver；
- IPVS wrapper:这个是IPVS功能的一个实现，IPVSwarrper模块将可以设置好的IPVS规则发送的内核空间并且提供给IPVS模块，最终实现IPVS模块的负载功能。
- Netlink Reflector：用来实现高可用集群Failover时虚拟IP(VIP)的设置和切换，
keepalived运行时，会启动3个进程，分别为：core(核心进程)，check和vrrp
- core：负责主进程的启动，维护和全局配置文件的加载；
- check：负责健康检查
- vrrp：用来实现vrrp协议
与heartbeat/corosync等比较
Heartbeat、Corosync、Keepalived这三个集群组件我们到底选哪个好，Heartbeat、Corosync是属于同一类型，Keepalived与Heartbeat、Corosync，根本不是同一类型的。Keepalived使用的vrrp虚拟路由冗余协议方式；Heartbeat或Corosync是基于主机或网络服务的高可用方式；简单的说就是，Keepalived的目的是模拟路由器的高可用，Heartbeat或Corosync的目的是实现Service的高可用。
所以一般Keepalived是实现前端高可用，常用的前端高可用的组合有，就是我们常见的LVS+Keepalived、Nginx+Keepalived、HAproxy+Keepalived。而Heartbeat或Corosync是实现服务的高可用，常见的组合有Heartbeat v3(Corosync)+Pacemaker+NFS+Httpd 实现Web服务器的高可用、Heartbeat v3(Corosync)+Pacemaker+NFS+MySQL 实现MySQL服务器的高可用。总结一下，Keepalived中实现轻量级的高可用，一般用于前端高可用，且不需要共享存储，一般常用于两个节点的高可用。而Heartbeat(或Corosync)一般用于服务的高可用，且需要共享存储，一般用于多节点的高可用。
