设为首页 收藏本站
查看: 669|回复: 0

[经验分享] LVS集群+keepalived

[复制链接]

尚未签到

发表于 2018-12-29 08:19:32 | 显示全部楼层 |阅读模式
  LVS集群:用到可能小,面试都会问
  

  linux cluster
  linux 集群
  

  把多个同样的东西组合起来,一束花,一堆计算机
  

  好多计算机为了解决某种问题某种需要而组合
  

  系统扩展的方式
  

  scale up :向上扩展(提升硬件)
  
  scale out:向外扩展(集群(负载均衡集群))
  

  【并不是随意加一台主机就能向外扩展的,如果没有关联,扩展是线性的(成倍),内部关联度越高,线性度越差】
  

  

  实现方式(分类)
  

  LB:load balancing 负载均衡集群
  把很多功能分散到多个主机上,每个都只提供一个功能,有点今天分布式应用的影子
  

  HA:high availiblity 高可用集群
  A=MBTF/(MBTF+MTTR) (0,1)之间
  平均无故障时间+平均修复时间
  高可用就是无限接近于1(95%,90%..),提高A要增大分子和减小分母
  
  缩短修复时间的方法,提供备份就好,基本上现在为了保证关键性环节出问题而不影响太大,任何地方都有冗余(备份)
  

  高可用集群就是提供自动冗余,比如说,一台主机在工作,另一台在盯着,当一个主机故障,立马替换,但也并不是说有冗余就一定能提高可用性
  
  HP:high performance 高性能集群,大量运算的时候需要,包括需要超强的IO能力,例如天气预报
  

  【www.top500.org 全球计算能力最强的计算机】
  

  【大问题解剖成小问题,放到单一主机,最后在一台主机统 一起来---分布式计算】
  

  

  

  DS: distributed system 分布式系统
  
  有总指挥的叫有中心节点的
  名称节点/跟踪节点(调度器)
      有故障的可能性
  没有总指挥的叫无中心节点的
  每一个节点都有一样的权限,每个都有协调能力,每一个新增了数据都立即通知给其他节点同步
  

  【负载均衡大多数是有中心节点的,有中心节点就有可能,单点故障,并且有可能成为性能增长的瓶颈】
  

  

  LB集群;负载均衡集群
  一台主机承载不了数据量,再加一台共同承载,叫负载均衡
  

  1.session绑定,同一用户只放在同一主机上
  2.session复制
  3.session server 专门存放session的server
  

  

  静态内容承载不了,加缓存比加服务器更好,IO承载不了加服务器
  

  需要共享又要分发,就要面临是不是与之前同一台服务器
  

  数据要是想一致:1.同步 2.共享
  

  

  

  

  LB cluster 实现
  

  1.硬件(硬件+优化后的系统:配置简单)
  
  F5:BIG-IP
  
  Citrix:Netscaler
  
  A10:A10
  

  2.软件
  
  LVS:linux Virtual Server 张文松
  

  nginx
  

  haproxy
  

  ats:apache traffic server 雅虎
  

  perlbal
  

  pound
  

  

  3.基于工作的协议层次划分(参与的层次越浅,消耗资源越小,性能越好)
  

  传输层:LVS:真传输层
  nginx/haproxy:模拟,依旧是socket
  

  

  

  应用层:http:nginx,haproxy
  fastcgi:nginx httpd
  mysql:mysql-proxy
  

  

  

  目前我们学习http/https的负载均衡
  

  

  站点访问指标
  PV:page view 页面访问量 (但是PV和你的资源请求数量或者日志中的访问条目数量并不是对应的,一个页面上是有好多资源的)
  UV:unique vistor 独立访客  单独设备(但是不区分IP地址,只要不是一个用户就好,不在乎是不是一个ip)
  IP:ip 量(这个是区分IP地址的,即便是多个访客,只要是来自一个IP地址的都只算一个)
  

  

  400w的并发(lvs的理论值)意味着什么呢,每个资源都要独立一个请求的,假设1个请求1个连接,因为是无状态的链接,每个请求在处理完成后是要断开连接的,所以,400w并发实际上是并发峰值,就是你在请求量最大的时候还没断开连接的数量,叫并发访问
  

  假设一个页面由100个资源组成(很多了),那么1秒钟的页面流量PV就是4w,有86400秒钟,1天页面访问量PV是--32亿。。
  

  百万PV理想的情况下三台服务器就可以承载,一个nginx,一个php,一个mysql
  

  

  没有保持连接只能计算并发连接峰值
  并发访问:某一状态去看的时候的并发连接数量
  

  

  LVS 集群
  

  linux virtual server
  linux real server (多个)
  

  会话保持
  

  1.session sticky 绑定,同一用户只放在同一主机上
  2.session replication 复制
  3.session server 专门存放session的server
  

  

  后端real server的健康状态检测  health check机制
  

  默认LVS(调度器)是不具备这种机制的,可以借助工具补充功能
  

  作者:章文嵩;滴滴,曾经在alibaba
  

  l4: 4层路由,或4层交换;LVS根据目标的IP+端口实现到下一站的,根据请求报文的目标IP和目标协议及端口将其调度转发至某realserver;
  挑选realserver将根据调度方法实现
  

  ipvs:依附于netfilter的INPUT链上
  

  监控请求,匹配到访问集群服务的请求,强行改变方向,转换到FORWARD上通过POSTROUTING送出
  

  lvs:
  
  ipvsadm/ipvs
  

  ipvsadm:用户空间的命令行工具,规则管理器,用于管理集群服务及realserver;
  ipvs:工作于内核空间的netfilter的INPUT钩子之上的框架,可接受ipvadm的管理命令
  

  支持基于TCP,UDP,SCTP,AH,ESP,AH_ESP进行调度,tcp/udp只是最为常见的
  

  

  

  

  lvs集群常用术语
  

  vs:virtual server
  调度器:director
  分发器:dispatcher
  均衡器:balancer
  

  rs: real server
  backend server
  upstream server
  

  

  客户端ip:cip
  向外提供服务的:vip
  与后端rs通信:dip
  每个rs的ip:rip
  

  

  CIPVIPDIPRIP
  请求响应
  

  lvs集群类型
  

  lvs-nat
  lvs-dr 【默认的类型,最优嘛】
  lvs-tun
  lvs-fullnat
  

  

  

  lvs-nat:
  多目标ip的DNAT,通过将来自客户端请求报文中的目标端口和目标地址改为某挑出的rs的rip和port实现转发
  

  工作在INPUT链上(DNAT是在PREROUTING)
  

  1.RIP和DIP必须在同一网段,且应该使用私网地址,rs网关要指向dip
  2.请求报文和相应报文都必须经由director转发;director易于成为瓶颈
  3.支持端口映射REDIRECT,VIP和rip上的端口不必是同一个
  4.vs必须是linux,rs可以使任意系统(lvs只支持linux)
  

  lvs-dr:
  director routing:直接路由
  

  通过将请求报文重新封装一个mac首部进行转发,源mac是dip接口所在接口的mac,目标mac是某挑选出的rs的rip所在接口的mac地址,源ip和目标ip都保持原状
  

  1.确保前段路由将目标ip为vip的请求报文发往director
  在前段路由绑定
  在rs上使用arptables
  在rs上修改内核参数限制通告及英大级别
  

  2.rs的rip可以使私网地址也可以是公网地址,rip与dip在同一网络
  

  3.rs跟director要在同一物理网络,实现基于mac地址的转发
  

  4.请求报文要经由director,响应报文不能经由director
  

  5.不支持端口映射
  

  6.阻断vip的解析请求
  

  7.使用linux系统
  

  

  lvs-tun:
  解决director和rs之间不能间隔太远的问题
  tunnel,隧道
  

  不常用
  

  不修改请求报文的IP首部,源ip为cip目标为vip,而是在IP报文之外在封装一个IP报文首部,源ip是dip目标是rip,将请求报文发到挑选出的目标rs
  

  1.dip vip rip应该都是公网地址
  2.rs网关必须不可能指向dip
  3.请求报文经由director,响应报文不能经由director而是直接发往cip
  4.不支持端口映射
  5.rs必须支持隧道功能
  

  

  lvs-fullnat
  请求报文的源IP地址目标IP地址全部同时修改,实现转发
  

  cipdip viprip
  

  这就使dip与rip之间可以添加路由了
  

  ipvsadm不支持fullnat规则,所以明白是什么就好
  

  

  1.vip是公网地址,rip dip是私网地址,且通常不在同一ip网络,不然直接用nat了
  2.rs收到的请求报文原地址是dip,直接相应给dip就行
  3.请求和相应必须都经过director
  4.支持端口映射
  5.不是默认支持的,要给内核打上补丁支持
  

  

  

  演示nat,dr最常用的也是这两种
  

  

  调度方法 ipvs scheduler
  
  根据其调度是是否考虑个rs当前的负载状态可分为静态方法和动态方法
  

  静态方法:根据算法本身进行调度,注重起点公平
  
  RR:roundrobin,轮询
  

  WRR:weighted,加权轮询,能者多劳
  使用与没有启用长连接的
  SH:source hash,原地址哈希,生成哈希表记录哪一个cip发到哪个rs中,那么再有请求来,先查表,实现绑定,发给哪个在hash有效期内就永远发给哪个,宕机的话只能等hash过期了,绑定力度太粗糙了
  

  DH:destination hash,目标地址哈希,有额外的正向代理服务器,在多个用户请求同一资源的时候,第一个用户访问后会存入一个缓存到这个服务器,那么以后再有访问这个的都是直接从缓存响应,哪怕是有多个缓存服务器,只要目标相同,都挑选同一个缓存服务器响应
  

  动态方法:主要根据rs当前的负载状态进行调度,注重结果公平,负载最小的就会被挑中
  

  负载计算方式
  overhead=activeconns*256+inactiveconns
  LC:least connections 最少链接
  overhead=activeconns*256+inactiveconns
  谁的小给谁,第一个就自上而下来
  

  WLC:weighted LC,加权最少连接
  overhead=(activeconns*256+inactiveconns)/weight
  适用于长连接算法
  【默认的调度方法】
  

  SED:shortest expection delay,最短期望延迟,招性能最好的响应
  overhead=(activeconns+1)*256/weight
  

  NQ:never queue ,改进的SED算法,现根据权重大小,每人分一个,然后在SED
  

  LBLC:(动态的DH;将发往同一个目标的请求是中发往一个rs)
  只影响的新的请求,以缓存的不影响
  基于本地的最少连接
  
  LBLCR:LBLC with replication;带复制的LBLC,缓存服务器中的缓存项在众多缓存服务器之间可以共享
  

  

  

  LBLCR,LBLC不常用
  

  

  

  ipvsadm 用户空间
  

  ipvs 内核 INPUT
  

  规则不会和iptables的规则一起使用
  

  规则生效位置是ipvs(内核中tcp/ip协议栈)
  

  配置之前确保那些东西都安装上了。去内核里的文件中找IPVS项
  

  

  

  ipvsadm命令
  
  -h help
  

  

  集群:
  服务:
  Service
  

  RS:real server
  

  定义集群:
  定义Service
  向Service添加RS
  

  删除集群:
  先删RS,再删Service
  

  

  ipvsadm -A|E -t|u|f service-address [-s scheduler] [-p [timeout]]
  ipvsadm -D -t|u|f service-address
  ipvsadm -C
  ipvsadm -R
  ipvsadm -S [-n]
  ipvsadm -a|e -t|u|f service-address -r server-address [options]
  ipvsadm -d -t|u|f service-address -r server-address
  ipvsadm -L|l [options]
  ipvsadm -Z [-t|u|f service-address]
  ipvsadm --set tcp tcpfin udp
  ipvsadm --start-daemon state [--mcast-interface interface] [--syncid sid]
  ipvsadm --stop-daemon state
  ipvsadm -h
  

  

  service-address
  

  -t:tcp协议 vip:port
  -u:udp协议 vip:port(udp port)
  -f:FWM 防火墙标记,结合iptables的Mark功能,将某一类人的集群服务根据ip端口打上标记,表明是集群服务请求,是16进制的证书
  

  

  

  [-s scheduler]:算法,不加默认WLC
  

  
  server-address:地址+端口 rip[:port],port种类取决于前边的-t|-u,port不加的话和前边一样,dr模型和tun模型不加port,因为不支持端口映射
  

  

  

  管理集群服务:增,删,改,查
  

  增:-A service-address [-s scheduler] [-p[timeout]]
  -E 改
  

  -D -t|u|f 删
  

  

  管理real server
  

  增,改:
  

  -a|e -t|u|f service-address -r server-address [-g|m|i] [-w weight]
  

  删:
  -d
  

  -g:gateway网关,直接路由模型,dr 默认
  -m:masquerade 地址伪装 nat
  -i:ipip 隧道 tun
  

  

  

  查看:
  

  ipvsadm -L|l [options]
  

  -n:数值格式显示ip和端口
  --exact:精确值
  

  -c:显示ipvs当前的连接
  

  --stats:统计数据,从ipvs生效开始到现在接受到的报文数量和字节总数
  

  --rate:显示ipvs的速率数据
  

  

  

  

  

  清空:
  -C:clear,清空ipvs
  

  

  保存和重载
  

  ipvsadm-save > /path/to/file
  ipvsadm-restore < /path/to/file
  

  

  保存规则并与开机时自动载入
  CENTOS6:
  

  /etc/sysconfig/ipvsadm
  

  chkconfig ipvsadm on
  

  CENTOS7:
  

  保存到/etc/sysconfig/ipvsadm
  

  systemctl enable ipvsadm
  

  
  • 记得开启核心转发功能

  •   

      负载均衡的设计要点
      

      1.会话保持要不要有,一般短连接都有,http https等
      

      2.数据共享要不要有,取决于你的集群允不允许写数据,允许就要做数据共享,不然就要做会话保持
      

      针对文件系统级别的
      

      共享存储
      NAS:nfs,cifs,访问接口是文件级别
      SAN:iSCSI,访问接口是块设备,在系统上看见是磁盘,要格式化挂载等
      DS:分布式文件,访问接口一般是文件级别,但是有些存储不支持FS,不支持挂载
      

      数据同步
      规模小的环境中使用
      rsync+inotify
      

      

      

      课外作业:博客 rsync+inotify实现数据同步
      

      

      

      lvs-nat模型
      

      设计要点
      1.rip与dip要同一网段,并且rip网关要指向dip
      2.支持端口映射
      3.是不是要会话保持看具体业务
      

      

      课外作业:博客 负载均衡一个php应用 论坛
      测试 1.是否需要会话保持
       2.是否需要共享存储
      

      

      

      

      

      lvs-dr 模型
      

      阻断rip上的vip对广播通告的响应
      

      1.前段路由 静态绑定
      2.各rs使用arptables
      3.各rs修改内核参数,限制响应参数
      

      限制响应级别 arp_ignore
      0:默认,使用本地上任意地址进行响应
      1:仅在请求的目标ip配置在本地主机的接受报文的接口的时候才响应
      

      限制通告级别 arp_announce
      0:默认,本机所有接口地址想每个网络通告
      1:尽量避免像非本网络通告
      2:总是必须避免像非本本接口网络通告
      

      /proc/sys/net/ipv4/conf/all|lo 底下的上边那三个参数都设定好
      [设定all就可以,只是为了防止all不生效又设定了lo]
      

      强制经过lo:
      使用route add -host $vip dev lo:0
      

      

      dip和rip必须在统一网关下,dip和vip可以不再同一网关下,但是这样的话rs发出的响应报文,传递vip的路由无法接受,所以,为了方便,实现要先知道另一个路由地址,或者是之前那个路由有多个接口
      

      

      

      

      上午最后一节课
      

      

      博客作业:统一布置lvs详细应用
      讲明白类型,调度方法,并给出nat和dr类型的设计及实现,同时验证
      

      

      课外作业:博客 负载均衡一个php应用 论坛
      测试 1.是否需要会话保持
       2.是否需要共享存储
      

      课外作业:博客 rsync+inotify实现数据同步
      

      

      

      

      

      

      

      FWM:防火墙标记机制
      

      用户的请求报文经过某个链的时候,可以再不动用报文的内容的情况下几个标记,来做个分类,主要为了分类,属于iptables的mangle
      

      在netfilter为某些匹配规则匹配到的报文添加标示,在mangle表上实现
      

      

      方法:iptables -t mangle -A PREROUTING -d $vip -p tcp --dport 80 -j MARK --set-mark 6(标记)
      因为ipvs只是在prerouting上的,所以链必须是prerouting
      

      基于标记定义集群服务
      ipvsadm -A -f 6 -s rr
      ipvsadm -a -f 6 -r 172....
      

      

      

      lvs persistence lvs的持久连接
      1.在一段时间内,将同一个用户的请求都发送到同一个rs,无视你的算法,是在调度算法之上的
      

      类似于sh的哈希表一样,通过持久连接模板实现,此前从没有
      

      2.端口的姻亲关系 port affinity
      每端口持久:在一段时间内将对来自于同一IP地址的访问相同服务的请求发往同一个rs
      

      $vip:port
      
      每客户端持久:从来不会用,奇葩
      
      每防火墙标记持久:一段时间内,将对绑定为同一个FWM的请求发往同一个后端rs
      
      FWM
      

      

      设定在设置ipvs的时候加上[-p[timeout]],timeout默认是300秒
      [-p[timeout]]
      

      

      一般是将http和https绑定在一起,好比在浏览淘宝,要去结账,结果结账时https,要启动新的会话,到了https一看,购物车清空了,将两个通过姻亲关系绑定到一起就解决了(只是举例,淘宝是全站https)
      

      

      

      考虑:1.director不可用,整个系统将不可用,单点故障,怎么避免
        2.某RS不可用的时候,director是否仍将请求调度给次主机,会
        完整的实现,应该周期性的对各rs的健康状态做检测
        健康:添加到RS列表,或启用此RS
        失败:从各RS中删除,或禁用此RS
      

      

      

        检测方式
        1.网络层检测
        2.传输层检测:对端口做尝试,端口扫描nmap
        3.应用层检测:请求某关进资源
      

      

      

      

      

      

      HA Cluster --keepalived
      

      A=MTBF/(MTBF+MTTR)
      A~(0,1)
      

      几个9: 99% 99.9% 99.99% 99.999%
      之间相差10倍的可用性
      

      5个9不在线时间1年估计也就有5分钟
      

      常用互联网2个9到3个9
      

      降低MTTR:冗余 redundant
      

      提供服务的三个要素
      

      IP地址,交互式程序,提供给客户端的资源
      

      备用节点要想做备用,也要提供这些要素,IP地址是要从主的地方挪过来
      

      没过多长时间,主节点会周期性的给备用节点传递一个自己还活着的信息还有自己的优先级,当备用节点3-4个周期仍旧没有收到信息就开始动手取代主节点
      

      【主节点备用节点是靠优先级划分的】
      

      关于IP地址的挪动就是指两个节点的地址都是IP地址的别名,是个服务地址,主节点宕机后,IP地址将down掉主节点别名,开启备用节点的别名
      

      节点都将连在一个电源交换机上,当备用节点准备取代主节点的时候,会想电源交互机发信号,让他将主节点电源关掉
      

      高可用服务
      高可用资源
      web service
      ip/httpd/filesystem
      

      network partition
      隔离设备:
      node级别隔离:STONITH
      资源级别隔离:fence
      

      

      HA 的实现方案
      
      vrrp协议的实现
      

      keepalived
      

      ais:完备的ha集群
      

      heartbeat
      sorosync
      

      

      

      keepalived:      9887
      

      vrrp协议:虚拟冗余路由协议,网关高可用
      

      网关地址的挪动就是指两个节点的地址都是网关地址的别名,是个服务地址,主节点宕机后,网关地址将down掉主节点别名,开启备用节点的别名
      

      【vrrp协议的存在的主要目标是完成地址转移的】
      

      

      虚拟路由:实际上由多个物理路由器构成,但是在客户端看起来像是一个路由,所以是一个虚拟路由
      

      VRID:每个路由的身份标示ID
      

      master路由器:负责转发报文
      

      backup路由器:等着取代master路由的
      

      虚拟IP地址:VIP,真正提供服务的ip,用户知道的网关地址
      

      虚拟MAC地址:局域网中是用mac地址来传递请求的,那么当节点换掉后,mac也要换,那么无法完成传递,所以会有一个像网关地址一样的虚拟MAC地址来随着网关地址挪动
      【但是,在keepalived中,并没有这么复杂,在转换节点后,路由会自问自答的将自己的MAC地址说出,客户端发现MAC地址错了,立马更新缓存】
      

      优先级:每个都有自己的优先级,表明主节点备用节点 0-255,但是可配置的优先级是1-254
      

      

      

      

      

      抢占式:主节点又好了,之后,因为优先级高,不会在乎你是不是在正常运行,直接抢过位置来,自己继续服务
      

      非抢占式:不抢了,有一个主节点就好
      

      

      

      vrrp认证方式
      1.无认证
      

      2.简单字符认证【keepalived只支持这个】
      

      3.md5验证
      

      

      为了不使有的路由器空闲,可以配置多个虚拟主机
      

      互为彼此的备用路由
      

      

      

      工作模式:
      主备模型
      主主模型:配置多个虚拟路由,每个都是主备,但是主备身份相反
      

      

      

      

      

      keepalived就是使用进程的形势实现了vrrp协议,原生设计目的就是为了高可用ipvs服务
      

      

      功能:1.实现vrrp协议,完成地址流动
        2.自动为VIP地址所在的节点生成ipvs的规则(定义在配置文件中的规则)
        3.为各rs做健康状态检测
        4.基于脚本调用接口完成其他脚本中的定义的功能
      

      

      keepalived组件
      
      控制组件:配置文件分析器
      内在组件:
      IO复用器:
      核心组件:
      vrrp stack:vrrp协议的实现
      checkers
      ipvs wrapper:创建ipvs规则的
      

      

      

      

      SMTP:提供邮件的功能,在转移地址后通过邮件方式通知管理人员
      

      watchdog:监控进程自己是不是还在线,不在了就启用起来
      【watchdog很多都是内核级别的,设置好多主机上都是硬件实现的,出故障的概率不大】
      

      

      HA 配置前提
      1.各节点时间必须同步
      ntp,chrony
      【ntp网络时间协议,太重量级,c7上呗后者取代】
      

      /etc/chrony.conf  bindcmaddress
        allow ..
      

        server 172.16.0.1 iburst
      chronyc -h host
      

      

      

      

      

      

      

      2.确保iptables和selinux不会成为阻碍
      

      3.各节点之间可通过主机名互相通信【对KA并非必须】
      

      4.各节点之间的root用户,要基于秘钥之间通信【ssh-keygen】
      

      

      

      keepalived
      
      centos7.2(6和7只有启动服务不同,其余差不多,6.4之前要编译安装)
      

      yum install keepalived -y
      

      

      

      配置文件/etc/keepalived/keepalived.conf
      程序文件
      unit file keepalived.service
      

      

      

      GLOBAL CONFIGURATION
      

      global definations
      

      notification email:地址转移后通知的对象,可以使多个
      smtp_server 127.0.0.1        # 邮件服务器IP
      smtp_connect_timeout 30      # integer, seconds
      router_id my_hostname        # 能标示就好
      identifying the machine,
       # (doesn't have to be hostname).
      vrrp_mcast_group4 224.0.0.18 # 组播地址,只修改最后一位,同一组内传播
      enable_traps                 # enable SNMP traps
      

      

      

      

      

      static routes   静态路由,一般用不到
      

      

      VRRPD CONFIGURATION
      

      vrrp synchronization groups  一般用不到
      vrrp instance
      

       vrrp_instance VI_1名称 {
      state MASTER | BACKUP
      【初始状态,一个虚拟主机只能有一个master,其余都是backup】
      

      
      interface eth0  【eno16777736,实际绑定接口】
      
      
      virtual_router_id 51
      【0-255;虚拟路由的VRID】
      
      priority 100
      【优先级;1-254】
      
      advert_int  1 【通报时间,心跳那个时间间隔】
      authentication {
      auth_type PASS  
      【认证方式】
      auth_pass 1111
      【密码】
      }
      

      }
      virtual_ipaddress {  【虚拟IP地址】
      192.168.200.16
      192.168.200.17
      192.168.200.18
      }  似乎是本机的ip
      【/ brd  dev  scope  label 】
      

      配置两个虚拟主机只要再加一段配置,然后备用机也是,但是记得主备两机的master和backup要反着配置
      

      track_interfacr {
      eth0
      eht1
      }
      监控网络端口,一旦出现故障,自动转为fault故障
      

      

      nopreempt 非抢占式路由
      preempt_delay 抢占式模式下,延迟多长时间才抢
      

      # 自定义通知的,脚本通知,主机节点状态变化触发不同脚本
      notify_master |字符串|"字符 串""中间带空格用双引号隐去来
      

      【转换成master后执行的脚本】
      

      

      notify_backup |
      

      【转换成backup的脚本】
      

      notify_fault |
      

      【转换成fault后执行的脚本】
      

      notify |
      

      【代替和三遍的三个,只要一个就好】
      

      【以上后边接脚本的路径,还有响应的参数master|backup等】
      

      smtp_alert
      }
      

      

      

      

      LVS CONFIGURATION
      

      virtual server  ip port vip的,客户端的
      fwmark FWM#  {
      

      lb_algo  rr|wrr....
      【调度算法】
      delay_loop
      【服务轮训的时间间隔,每两次健康检查间隔】
      lb_kind NAT|DR|TUN
      【lvs类型】
      persistence_timeout
      【持久连接时长】
      protocol TCP
      【服务协议只支持TCP】
      sorry_server ip port
      【所有rs都故障时,向用户道歉的主机,一般是定义在director本身,启动一个web服务,接受转发然后提供一个页面】
      real_server ip port{
      rs的,写rip
      weight
      【权重,0表示禁用】
      notify_up 。。。
      notify_down
      【状态改变通知脚本】
      HTTP_GET|SSL_GET{
      url{
      path
      【获取资源的路径】
      digest
      【资源的】
      status_code
      获取资源返回的状态码
      }
      nb_get_retry
      做健康状态检测获取失败的尝试次数
      delay_before_retry
      每次重试前的延长时间
      connect_ip port
      想那个IP地址连接做健康状态检测,默认是rip
      bindto
      指明想那个地址发请求
      bind_port
      指明使用那个端口
      connect_timeout
      连接超时时长
      fwmark
      检测连接的防火墙标记
      }
      

      keepalived配置dr模型
      

      

      1.配置rs
      

      选择相应的转发功能,配置两个IP地址,其中一个是rip,一个是vip,vip应配置在lo上,还有添加lo的路由
      

      

      

      2.配置director
      
      安装httpd/nginx来提供web服务,以便于启动sorry server
      

      两台主机都编辑一个html的sorry页面
      

      安装ipvsadm来查看规则是不是生效,keepalived其实用不到这个命令,因为keepalived是调用内核中的ipvs生成规则的,装了只是为了方便查看规则是不是生效,两个主机装一个就行
      

      配置keepalived.conf,但是千万记得配置前先备份一个,2个主机都要配置
      

      

      

      

      

      

      

      

      

      

      

      

      

      

      

      高可用一个nginx怎么做(高可用一个服务)
      
      keepalived本身不支持和这些服务相关联,不能再keepalived配置文件中直接定义,所以,可以使用keepalived的通知脚本notify脚本来实现,在脚本添加,当从主节点转到这个节点上的时候,服务启动,转走以后,服务停止
      

      

      

      

      

      keepalived调用外部辅助脚本,完成资源监控,并根据监控的结果状态来实现优先级动态调整
      

      使用vrrp_script:定义一个资源监控脚本
      vrrp_script  {
      script "脚本路径,或一个命令"  显示命令的状态回执,成功了为0
      

      interval int 每隔多长时间检测一次
      

      weight -#(负数) 失败了就让优先级减#
      

      

      

      }
      

      track_script:调用定义的资源监控脚本
      

      track_script {
      script_name name
      

      }
      

      之前每次想看看节点转换都要讲服务停掉,有了调用脚本,就可以这样做
      

      在某个目录下创建一个文件,文件存在的时候,就让优先级降低,不在就调高优先级
      

      

      定义方法
      

      vrrp_script chk_down {
      

      script "[[ -f /etc/keepalived/down ]] && exit 1 || exit 0"
      

      interval 1
      

      weight -5
      }
      

      放在instance上边,使用脚本的话,就在下边调用
      

      track_script {
      chk_down
      }
      

      

      

      killall -0 httpd
      

      探测一个服务是不是在运行,在的话 echo $?=0
      

      

      

      

      vrrp_script chk_down {
      

      script "killall -0 httpd && exit 0 || exit 1"
      

      interval 1
      

      weight -5
      }
      

      

      

      

      

      当两个都停止的时候,都减少5的优先级,但是这没有什么意义,所以,我们可以再调用的notify脚本上,写上重启服务的语句,一旦自己失败或者是转到备用了,就重启服务,然后在
      

      track_script {
      chk_down
      }
      notify ............
      ...................
      ...................
      的下边,加上notify+脚本路径来调用脚本
      

      

      

      

      

      

      

      

      

      

      

      

      

      

      

      

      





  • 运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
    2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
    3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
    4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
    5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
    6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
    7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
    8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

    所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-657025-1-1.html 上篇帖子: keepalived实现高可用 下篇帖子: lvs keepalived 资料整理
    您需要登录后才可以回帖 登录 | 立即注册

    本版积分规则

    扫码加入运维网微信交流群X

    扫码加入运维网微信交流群

    扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

    扫描微信二维码查看详情

    客服E-mail:kefu@iyunv.com 客服QQ:1061981298


    QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


    提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


    本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



    合作伙伴: 青云cloud

    快速回复 返回顶部 返回列表