<br />高可用集群介绍<br /> keepalived<br /> 一开始就是为了补充lvs负载均衡以及高可用的一个组件，被开发出来。监控各个节点的工作状态。DR，RS。集成vrrp协议所提供的的功能，以实现高可用的机制。<br /> VRRP协议，网络供应商提供<br /> 虚拟路由冗余协议<br /> 虚拟路由器(虚拟主机)<br /> 是由真实的路由器组组成，有一个MASTER,其余的BACKUP，对于外网或者是内网都是透明的<br /> VRID<br /> 虚拟路由器唯一识别码，在同一个虚拟路由器中的所有真实路由器都具有相同的识别码<br /> VIP<br /> 虚拟路由器中所有真实路由器，共享的资源<br /> 优先级当谁拥有了VIP，谁就是master确定谁是MASTER<br /> 抢占模式和非抢占模式<br /> master会以组播的形式不断地向BACKUP发送自己的心跳报文，一旦buckup在规定时间内没能收到master的心跳，backup就会抢占之前由master占有的资源，这就是抢占模式。只有在master故障之后，backup才会占有资源，通过优先级的判定，当master再次上线之后，会将资源交还给master。 <br /> keepalived服务的三大功能：<br /> 1管理lvs负载均衡(在配置文件中有一段可以设置)<br /> 2实现LVS集群节点的健康检测<br /> 3作为系统网络的高可用保障<br /> keepalived高可用的原理<br /> 当ka服务正常工作时，主MASTER节点会不断地向BACKUP节点发送心跳信息，告知BACKUP节点自己很健康；当master故障时，backup在固定周期内没有收到心跳信息时，抢占master的资源接管ka提供的服务。<br /> 假设 master节点 每隔5秒钟向backup发送心跳。<br /> backup，会经过若干次5秒钟，才会去抢占资源。<br /> 对于RS节点，会在MASTER上定时检测RS的健康状态。<br /> web服务，port为80，就会在ka的配置文件中某段下指定定时监测的功能。若探测不到RS的响应。MASTER就会主动的将lvs设置中的这个没响应的RS给剔除掉。<br /> <br /> lvs被集成在linux内核中，ipvsadm只是管理工具。<br /> keepalived被收集到官方的安装镜像里。<br /> 资源被争夺，<br /> lvs(DR)+keepalived<br /> 虚拟机 NAT 192.168.2.0/24<br /> VIP 192.168.2.188<br /> DR1 192.168.2.150<br /> DR2<br /> 先在DR1上编写keepalived的主配置文件<br /> [root@localhost ~]# cd /etc/keepalived/<br /> [root@localhost keepalived]# ls<br /> keepalived.conf<br /> 主配文件下：<br /> 1全局设置 global_defs<br /> 主要是通知邮件设定以及route_id的设置<br /> routeid的设置要求每一个真实路由器(DR)都不一样。<br /> 2 IP地址和路由设置 static_ipaddress,static_routes<br /> 由于本机已经设置了ip地址和路由地址<br /> 3 vrrp_script 通过vrrp协议执行的检测脚本设置<br /> 4 vrrp_instance vrrp实例<br /> state高可用集群的角色定位<br /> interface网络接口名<br /> virtual_route_id虚拟服务器组的id号<br /> 同一个组内的id相同<br /> priority优先级 0-255<br /> advert_int设定周期，定时以组播的形式发送心跳<br /> virtual_ipaddress vip<br /> lvs-dr一张网卡<br /> 5 virtual_server lvs设置段<br /> vip<br /> delay_loop在DR中设置健康检查周期<br /> persistence_timeout会话持续时长<br /> 以上设置的是lvs的service<br /> ipvsadm -A<br /> real_server设置就是ipvsadm -a<br /> 权重<br /> TCP_CHECK{<br /> connect_port 80<br /> connect_timeout 3<br /> nb_get_retry 3<br /> delay_before_retry 3<br /> }<br /> <br /> 两台DR,分别配置完keepalived之后，实现vip的漂移功能。<br /> 保证在LVS的DR模式下，DR的高可用。<br /> 配置文件的man手册<br /> [root@localhost etc]# man keepalived.conf<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> HAProxy是免费、极速且可靠的用于为TCP和基于HTTP应用程序提供高可用、负载均衡和代理服务的解决方案，尤其适用于高负载且需要持久连接或7层处理机制的web站点。<br /> <br />HAProxy目前主要有两个版本：<br /> <br />使用1.5 集成了1.3和1.4的优点<br /> <br />1.4——提供较好的弹性：衍生于1.2版本，并提供了额外的新特性，其中大多数是期待已久的。<br /> 客户端侧的长连接(client-side keep-alive)<br /> TCP加速(TCP speedups)<br /> 响应池(response buffering)<br /> RDP协议<br /> 基于源的粘性(source-based stickiness)<br /> 更好的统计数据接口(a much better stats interfaces)<br /> 更详细的健康状态检测机制(more verbose health checks)<br /> 基于流量的健康评估机制(traffic-based health)<br /> 支持HTTP认证<br /> 服务器管理命令行接口(server management from the CLI)<br /> 基于ACL的持久性(ACL-based persistence)<br /> 日志分析器<br /> <br />1.3——内容交换和超强负载：衍生于1.2版本，并提供了额外的新特性。<br /> 内容交换(content switching)：基于任何请求标准挑选服务器池；<br /> ACL：编写内容交换规则；<br /> 负载均衡算法(load-balancing algorithms)：更多的算法支持；<br /> 内容探测(content inspection)：阻止非授权协议；<br /> 透明代理(transparent proxy)：在Linux系统上允许使用客户端IP直接连入服务器；<br /> 内核TCP拼接(kernel TCP splicing)：无copy方式在客户端和服务端之间转发数据以实现数G级别的数据速率；<br /> 分层设计(layered design)：分别实现套接字、TCP、HTTP处理以提供更好的健壮性、更快的处理机制及便捷的演进能力；<br /> 快速、公平调度器(fast and fair scheduler)：为某些任务指定优先级可实现理好的QoS；<br /> 会话速率限制(session rate limiting)：适用于托管环境；<br /> <br />性能<br /> HAProxy借助于OS上几种常见的技术来实现性能的最大化。<br /> 单进程、事件驱动模型显著降低了上下文切换的开销及内存占用。<br /> O(1)事件检查器(event checker)允许其在高并发连接中对任何连接的任何事件实现即时探测。<br /> 在任何可用的情况下，单缓冲(single buffering)机制能以不复制任何数据的方式完成读写操作，这会节约大量的CPU时钟周期及内存带宽；<br /> 借助于Linux 2.6 (>= 2.6.27.19)上的splice()系统调用，HAProxy可以实现零复制转发(Zero-copy forwarding)，在Linux 3.5及以上的OS中还可以实现零复制启动(zero-starting)；<br /> MRU内存分配器在固定大小的内存池中可实现即时内存分配，这能够显著减少创建一个会话的时长；<br /> 树型存储：侧重于使用作者多年前开发的弹性二叉树，实现了以O(log(N))的低开销来保持计时器命令、保持运行队列命令及管理轮询及最少连接队列；<br /> 优化的HTTP首部分析：优化的首部分析功能避免了在HTTP首部分析过程中重读任何内存区域；<br /> 精心地降低了昂贵的系统调用，大部分工作都在用户空间完成，如时间读取、缓冲聚合及文件描述符的启用和禁用等；<br /> <br /> 所有的这些细微之处的优化实现了在中等规模负载之上依然有着相当低的CPU负载，甚至于在非常高的负载场景中，5%的用户空间占用率和95%的系统空间占用率也是非常普遍的现象，这意味着HAProxy进程消耗比系统空间消耗低20倍以上。因此，对OS进行性能调优是非常重要的。即使用户空间的占用率提高一倍，其CPU占用率也仅为10%，这也解释了为何7层处理对性能影响有限这一现象。由此，在高端系统上HAProxy的7层性能可轻易超过硬件负载均衡设备。<br /> <br /> 在生产环境中，在7层处理上使用HAProxy作为昂贵的高端硬件负载均衡设备故障故障时的紧急解决方案也时长可见。硬件负载均衡设备在“报文”级别处理请求，这在支持跨报文请求(request across multiple packets)有着较高的难度，并且它们不缓冲任何数据，因此有着较长的响应时间。对应地，软件负载均衡设备使用TCP缓冲，可建立极长的请求，且有着较大的响应时间。<br /> <br />配置HAProxy<br /> <br />配置文件格式<br /> <br /> HAProxy的配置处理3类来主要参数来源：<br /> ——最优先处理的命令行参数，<br /> ——“global”配置段，用于设定全局配置参数；<br /> ——proxy相关配置段，如“defaults”、“listen”、“frontend”和“backend”； <br /> 回顾对比nginx反代的配置文件：其实也分为接收请求、处理请求<br /> nginx：<br /> server {<br /> location ~* \.php$ {<br /> proxy_pass ## location匹配定位 实现动静分离<br /> ## proxy_pass 实现请求转发上游服务器 (类比haproxy中的backend)<br /> }<br /> <br /> location / {<br /> <br /> }<br /> }<br /> <br /> upstream {<br /> leastconn<br /> server<br /> server<br /> }<br /> <br /> haproxy:<br /> frontend<br /> use_backend<br /> default_backend<br /> backend<br /> balancer<br /> server<br /> server<br /> <br /> listen:<br /> server<br /> <br /> default<br /> <br /> 配置：/etc/haproxy/haproxy.cfg<br /> /usr/sbin/haproxy<br /> <br /> CentOS 6: /etc/rc.d/init.d/haproxy<br /> CentOS 7: haproxy.service<br /> <br /> 配置分为两段：<br /> global<br /> 配置参数：log, maxconn, ...<br /> proxies<br /> defaults, frontend, backend, listen<br /> <br /> 示例：<br /> frontend main *:80<br /> default_backend websrvs<br /> <br /> backend websrvs<br /> balance roundrobin<br /> server web1 172.16.100.68 check<br /> server web2 172.16.100.69 check<br /> <br /> 代理参数：<br /> balance:指明调度算法；<br /> 动态：权重可动态调整，服务器自动调整<br /> 静态：调整权重不会实时生效，重启才能生效<br /> <br /> roundrobin:加权轮询，动态算法<br /> 通过计算后端服务器的处理时间并使其保持均匀分布，看上去最为公平<br /> 每个后端主机最多支持4128个连接<br /> 服务器需要额外对加权值调整进行实时跟踪和记录，开销大<br /> static-rr:加权轮询，静态算法，每个后端主机支持的数量无上限；<br /> leastconn:根据后端主机的负载数量进行调度；仅适用长连接的会话；动态；<br /> source:会话保持<br /> 将请求的源地址进行hash运算，并由后端服务器的权重总数相除后派发至某匹配的服务器<br /> 例 后端 3台ABC 权重分别是1+2+3（C相当于3台A）<br /> 可简单理解为取余之后，0 发给 A ;1 2发给B ; 3 4 5 发给C 由此保持会话的一致性<br /> 但因权重变化之后，会导致会话无法保持，但权重是否会变化<br /> 有下面的属性决定：<br /> hash-type:(默认静态)(过于复杂)<br /> map-based：取模法；静态；看上去好，但存在服务器宕机权重即使不变化也无法保持回话<br /> consistent：一致性哈希法；动态；<br /> map-based：hash表是一个包含了所有在线服务器的静态数组。其hash值将会非常平滑，会将权重考虑在列，但其为静态方法，对在线服务器的权重进行调整将不会生效，这意味着其不支持慢速启动。此外，挑选服务器是根据其在数组中的位置进行的，因此，当一台服务器宕机或添加了一台新的服务器时，大多数连接将会被重新派发至一个与此前不同的服务器上，对于缓存服务器的工作场景来说，此方法不甚适用。<br /> consistent：hash表是一个由各服务器填充而成的树状结构；基于hash键在hash树中查找相应的服务器时，最近的服务器将被选中。此方法是动态的，支持在运行时修改服务器权重，因此兼容慢速启动的特性。添加一个新的服务器时，仅会对一小部分请求产生影响，因此，尤其适用于后端服务器为cache的场景。不过，此算法不甚平滑，派发至各服务器的请求未必能达到理想的均衡效果，因此，可能需要不时的调整服务器的权重以获得更好的均衡性。<br /> uri:(有用)默认静态<br /> 整个URI进行hash运算，并由服务器的总权重相除后派发至某匹配的服务器；这可以使得对同一个URI的请求总是被派发至某特定的服务器，此算法常用于代理缓存以提高缓存的命中率。<br /> URI是什么?一般指域名后，请求地址的路径<br /> http://host[:port]/path;params?query#frag<br /> hash-type<br /> map-based:<br /> consistent:<br /> 测试 可以分别生成多个页面 在rs1 和rs2上 同名 内容不一样<br /> 只要第一次请求到rs1上的某页面 之后的请求就一直被调度到rs1上的这个页面<br /> rs1<br /> for i in {1..10}; do echo "<h1>Page $i on Web1</h1>" > /var/www/html/test$i.html;done<br /> rs2<br /> for i in {1..10}; do echo "<h1>Page $i on Web2</h1>" > /var/www/html/test$i.html;done<br /> <br /> url_param:根据url中的指定的参数的值进行调度；把值做hash计算，并除以总权重；<br /> 场景 可以根据用户请求，将不同用户(登录或是非登陆)分别调度导不同的服务器（会员非会员体验不一样^_^）<br /> hash-type<br /> map-based:<br /> consistent:<br /> hdr(<name>) ：根据请求报文中指定的header(如use_agent, referer, hostname)进行调度；把指定的header的值做hash计算；<br /> hash-type<br /> map-based:<br /> consistent:<br /> 测试<br /> balance hdr(User-Agent) ## 对于请求的浏览器种类进行调度<br /> <br /> curl -A ‘浏览器类型’ http://ipaddr/testX.html<br /> <br /> bind：<br /> 只能用于frontend, listen; <br /> 可以监听在多端口上<br /> 每一个bind占一行<br /> <br /> <br /> mode:<br /> HAProxy的工作模式；默认为tcp；<br /> tcp, http, health<br /> 要求前后端模式要一致<br /> 默认的tcp模式兼容性更好<br /> <br /> log:<br /> 配置文件中启动haproxy日志管理<br /> 需要开启rsyslog服务中udp514端口<br /> 以及按配置文件默认的local2日志级别进行记录<br /> <br /> maxconn:<br /> 可在全局中进行定义，表示全局最大连接数<br /> 也可以在frontend和listen中进行定义，若有多个前端<br /> 多个前端的最大连接数总和不要超过全局<br /> <br /> 设定一个前端的最大并发连接数，因此，其不能用于backend区段。对于大型站点来说，可以尽可能提高此值以便让haproxy管理连接队列，从而避免无法应答用户请求。当然，此最大值不能超出“global”段中的定义。此外，需要留心的是，haproxy会为每个连接维持两个缓冲，每个缓冲的大小为8KB，再加上其它的数据，每个连接将大约占用17KB的RAM空间。这意味着经过适当优化后，有着1GB的可用RAM空间时将能维护40000-50000并发连接。<br /> <br /> 如果为<conns>指定了一个过大值，极端场景下，其最终占据的空间可能会超出当前主机的可用内存，这可能会带来意想不到的结果；因此，将其设定了一个可接受值方为明智决定。其默认为2000。<br /> <br /> <br /> default_backend:<br /> 为frontend指明使用的默认后端；<br /> <br /> use_backend:条件式后端调用；<br /> 例<br /> use_backend dynamic if url_dyn ## url_dyn是后需要讲的acl规则<br /> use_backend static if url_css url_img extension_img<br /> default_backend dynamic ## 匹配不到上述的acl规则 将调度到defaultbackend上<br /> <br /> server:<br /> <br /> server <name> <addr>[:port] [param*]<br /> backup:设定当前server为backup server；当其他的server全部宕机之后，sorryserver才上线<br /> check:健康状态检测；<br /> inter <delay>：检测时间间隔；单位为ms, 默认为2000;<br /> 正常态到非正常态：<br /> fall: up --> down, soft state, soft state, hard state; 默认是3次<br /> rise：down --> up, 同上<br /> cookie <value>：<br /> 为指定server设定cookie值，此处指定的值将在请求入站时被检查，第一次为此值挑选的server将在后续的请求中被选中，其目的在于实现持久连接的功能；<br /> maxconn:此服务接受的并发连接的最大数量；<br /> maxqueue:请求队列的最大长度；<br /> observe:根据流量判断后端server的健康状态；<br /> weight:指定权重，默认为1，最大为256；0表示不被调度；<br /> redir <prefix>: 重定向；所有发往此服务器的请求均以302响应；<br /> <br /> <br /> 基于浏览器cookie实现session sticky：<br /> backend websrvs<br /> balance roundrobin<br /> cookie SERVERID insert nocache indirect<br /> server web1 172.16.100.68:80 check weight 1 cookie websrv1<br /> server web2 172.16.100.69:80 check weight 3 cookie websrv2<br /> <br /> 要点：<br /> (1)每个server有自己惟一的cookie标识；<br /> (2)在backend中定义为用户请求调度完成后操纵其cookie<br /> <br /> ACL<br /> haproxy的acl用于实现基于请求报文的首部，响应报文的内容或者其他的环境状态信息哎做出转发决策。<br /> 大大增强了其配置弹性，通常量不适用acl规则<br /> 1定义acl规则，定义一个测试条件<br /> 2满足条件时执行某特定的动作，如阻止请求护着转发至某特定后端<br /> <br /> 定义语法：<br /> acl <aclname> <criterion> [flags] [operator] <value> ...<br /> aclname:定义名称<br /> criterion：测试标准，对什么信息发起测试<br /> flags：标志位 常用的有2个<br /> -i忽略大小写<br /> -f从指定的文件中加载规则<br /> value：测试条件支持的值<br /> 整数或者整数范围<br /> 字符串<br /> regexp<br /> 网络地址<br /> 同一个acl中可以指定多个测试条件，需要使用到逻辑运算符指定条件之间的关系 与(默认)或(||)非(|)<br /> <br /> 常用测试标准<br /> 1 be_sess_rate(backend) <integer><br /> 用于测试指定的后端或者当前后端上会话创建速率是否满足指定的条件：常用于在指定后端上会话速率过高时，将用户的请求转发至另外的后端，活用于组织攻击行为。<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br />
若有收获，就点个赞吧
0 人点赞
