码迷,mamicode.com
首页 > 其他好文 > 详细

Neutron:LBaaS v2——ipvsadm实现LVS

时间:2019-06-22 10:57:04      阅读:102      评论:0      收藏:0      [点我收藏+]

标签:dip   进化   信息   意思   keep   via   local   文件类型   lin   

LBaaS v2

Neutron 包含负载均衡服务,即LBaaS。负载均衡器可以将用户的访问流量通过算法均摊到多台主机实例上,实现以 Scale-out的方式扩容应用的性能。Neutron LBaaS 包含以下核心的概念:

  • 服务器池 Pool:服务器池内包含了多个服务器成员,同一个池内的服务器至少包含一种统一的对外服务。
  • 服务器成员 Member:服务器成员,包含服务器的IP和端口。
  • 监听器 Listener:监听器将持续监听指定的端口上的连接请求。一个负载均衡器中允许存在多个监听器,同时通过共享服务器池,多个监听器也可以关联到同一个服务器池。
  • 健康监控 Health monitor:检查服务器池中成员的状态,以及服务器的加入、离开。

 技术图片

 之所以称之为 lbaas v2,是因为Neutron的负载均衡的模型有过一次如上图的进化,在v2的版本中,neutron 对负载均衡的架构有了一次非常大的调整,v2版本变得更符合行业标准,且驱动和功能扩展变得更为简单,除此之外新版本还允许一个负载均衡器下添加多组 Listener 监听服务,以及加入了TLS。Lbaas v2无法和lbaas v1同时运行,开启lbaas v2需要停止lbaas v1。

改进后的LBaaS v2经过了更为全面的测试,并且加入了更多的HTTP层代理的特性。并开始支持Active-Standby部署模式,后续版本中将进一部支持Active-Active。新版可以说是负载均衡架构和功能的一次飞跃。

负载均衡概念

技术图片

 服务器池 Pool

服务器池即后端一组提供服务的实例,每个成员都是一个IP地址+4层的端口。例如,常见的提供web服务的实例,在服务器池中表示为:192.168.1.1:80。提供的服务不同则端口号也不相同。池内的服务器都统一对外提供某一种服务。例如:

服务器 1:192.168.1.1:80

服务器 2:192.168.1.3:80

服务器 3:192.168.1.4:80

 技术图片

负载均衡器通过 VIP 统一对前端提供服务,用户向虚拟IP发起连接请求,监听器监听到对应端口的请求后,通过负载均衡算法将请求转发到后端服务池中的一个成员上。然后成员对用户请求的资源进行响应,这样整个过程对于用户来说是透明的。包括后端服务器的增加、减少以应对用户规模的增缩,都不会对已经建立的连接产生影响。

 

监听器 Listener

监听器即一个不断在端口上检查连接请求的进程,一旦发现客户端的连接请求,则会按照你设定的规则将连接请求转发给后端的服务器池。一个监听器关联一个端口,如:HTTP(80)、HTTPS(443),当使用HTTPS,则需要上传用于https 加密和解密的证书到监听器中。

L7 转发策略  l7 policy

 技术图片

 l7策略转发流程

LBaaS v2 支持L7的转发策略,每个监听器上都可以配置多条转发策略(L7 Policy)。策略由由规则(rule)和操作组成,类似 if…then…的条件语句,当有流量匹配了 rule 的条件时,就按照策略中的操作转发。否则就继续向下匹配。规则可以匹配HTTP请求中的特殊字段或URL,这给业务带来了极大的灵活性。

rule 支持的匹配项包括:

  • Hostname,L7 rule 支持匹配HTTP/1.1 请求中的host字段
  • path,HTTP URI 中路径的部分
  • file_type,请求的文件类型
  • header,HTTP 头中其他字段
  • cookie,cookie的值

需要注意的是,同一个policy下的rule是“与”的关系,即策略下的所有rule都匹配的情况下,才会按照策略的操作转发。其中任何一条不匹配都会跳过该策略向下匹配。

匹配的算法包括:

  • regex,正则表达式,非的意思
  • starts_with,字符串开头
  • ends_with,字符串结尾
  • contains,字符串中包含的值
  • equal_to,等于

L7 policy 的操作支持:

  • block,请求将直接被拒绝;
  • redirect_to_url,重定向用户的url;
  • redirect_to_pool,重定向到后端特定的主机池内。

 技术图片

 

例如:可以在监听器上添加两条rule,一条匹配HTTP请求中 file_type 包含:jgp、png、gif、zip、txt 的请求转发给 image pool。另一条一条匹配URI中 path 以“*/login”开头的请求转发给APP pool。

这样就简单的实现了网站上静态内容(图片)与动态内容(用户登录)的分流处理,这能在不改变应用架构的情况下,减轻web服务的负载。对于云原生应用来说,这样的功能非常重要。

 

L7策略配置示例如下:

  • neutron --policy policy1 lbaas-create-l7policy --name "policy1" --description "My Description" --listener "listener1" --action redirect_to_pool --pool "pool1" --position 1 (创建L7策略,命名为“policy1”描述为“lb策略”,并关联 “listener 1”,策略的动作是将匹配的流量转发到“pool1”)
  • neutron lbaas-create-l7rule rule1 --rule-type path --compare-type starts_with --value "/api" --policy policy  (在“policy 1”下添加一条规则,匹配所有URL中以 “/api”开头的请求)

可见到 LBaaS v2可根据业务需求制定出非常灵活的7层转发策略。

 

负载均衡算法 Algorithms

本身Neutron支持的负载均衡算法包括:轮询、最少连接、源IP。

  • 轮询 Round robin,是最普遍的算法,每当有一个新的请求来临,负载均衡器都会按顺序选择服务器池中的一台设备来响应。有点类似音乐播放软件的列表循环。这种模式下服务器池中的每一个服务器都能均匀地分配到相同的访问请求数,而不会管服务器繁忙程度、服务器配置的高低。比较适用于服务器池内的服务器配置相同、用户访问习惯相同的业务。加权轮询是改进的负载均衡算法,当后端服务器池中设备配置高低不一时,可根据服务器处理能力的高低分配服务器的权值,权值高的服务器会被分配更多的用户请求。
  • 最少连接算法 Least connections,负载均衡器收到新的请求时,都会从当前服务器池中挑选一个当前并发连接数最少的服务器来负责。最少连接算法考虑的服务器的实时负载情况,尽量保证了任务分配的平均,防止单个服务器超出负载,但是当后端服务器池中存在高处理能力的服务器时,这个处理能力高的设备始终无法获得更多的工作负载,存在性能的浪费。最少连接算法有优化后的加权最小连接算法
  • IP hash,负载均衡器在收到主机的连接请求后,会根据数据包的源IP地址字段的hash值,同时按照轮询的方式为客户端分配主机,当负载均衡器再次收到同一IP的请求时,则会按照之前的记录为客户端分配上次建立连接的主机。这样保证了当同一个IP的用户,多次独立的访问都能由同一台服务器来处理,适用于服务器需要临时记录或保存客户信息的应用中。

 

健康监测 Monitor

健康检测的机制是指是负载均衡器通过定期的心跳信号检测服务器池中的服务器运行状态,从而排除掉后端故障的主机,保证服务整体正常。

Neutron支持的健康检测方式包括 ICMP、TCP、HTTP几种。

  • ICMP是最简单的,通过ping 和echo的方式,看根据服务器是否响应。只要服务器操作系统TCP/IP协议栈运行正常,网卡不出问题,服务器到负载均衡之间的网络正常,ICMP的方式都起到良好的作用,但以上情况都不能代表服务器上面运行的应用是正常的。
  • TCP是4层的检测方式,相比ICMP、TCP会请求主机的特定端口,看特定的端口能否正常响应。
  • HTTP的方式则更进一筹,会通过get特定的页面,根据HTTP的返回代码来判断应用是否正常。

健康监测的指标越精确,越能反映服务的实际响应情况,如果是web服务,最好是使用HTTP的方式,这样检测结果更可信。

 

会话保持 Session persistence

会话保持功能常用于有状态的服务中,比如服务器通过session来维护用户连接的状态,因为session保存在服务器本地,如果不断地通过网络来在服务器池中同步session的话,会消耗服务器的带宽和处理能力,所以这时会选择使用负载均衡器的会话保持功能。它能保证同一个用户的请求会被发送到同一台服务器。

 

Lbaas v2支持的会话保持的类型为:

  • 源IP:源IP即IP hash 算法,根据IP地址来识别客户。负载均衡器在收到请求后会计算数据包头源IP地址的hash值,并按照轮询的方式给该客户端分配一个服务器,同时将两者的对应关系记录到表中,当再次收到同一源IP发来的请求时,则查找到之前的服务器进行转发。但是当客户端通过NAT、或代理的方式上网时,源IP的方式就可能导致多个客户端被分配到同一个主机。顺便一提,去年在公司用12306在高峰期抢车票时,刚打开网站就被提示“您的操作频率过快”,即很有可能12306后端也是判断同一个IP提交的访问请求过多,从而误把新接入用户当作了已访问过的用户。
  • HTTP_cookie:该模式下会根据浏览器中缓存的cookie来识别用户,cookie里面一般都缓存了计算机信息和浏览器的信息以及用户认证的信息。Lbaas v2中负载均衡器会在服务器第一次返回给客户端的回应中插入“SRV”的cookie值,标识了回复的服务器。当再次收到客户端发起的HTTP请求时,lbaas v2会找出 cookie中的"SRV"字段,并剥离掉后转发给之前回复的服务器。HTTP_cookie 的问题在于,有可能一些用户会禁用掉浏览器上的cookies,这种情况下基于cookies的会话保持就将失效了。
  • App_cookie:该模式下需要在负载均衡器中预先定义各个后端中设置的cookie,并将对应关系存储到表中,当收到客户端的请求时,检查请求中是否有预先定义的cookie,如果有,则转发到对应的服务器。

 

虽然当今互联网应用中通过token来实现用户的识别和鉴权已经比较常见了,但负载均衡的会话保持能够很好弥补通过 seesion 识别用户的应用的不足。但是基于cookie的会话保持无法支持服务器直接返回的部署模式,即服务器返回给用户的流量不经过负载均衡器,而是直接上行转发出去。所以在某些大流量的应用中,负载均衡器可能成为性能的瓶颈。

 技术图片

非对称流量中,服务器直接返回到客户端,上行流量不经过负载均衡器,LBaaS v2 暂时还不支持这种部署模式。

 

实现

Neutron中 LBaaS v2有两种实现方式,

一是:使用HAproxy作为负载均衡器,在网络节点上运行LBaaS agent,agent会完成节点上的Haproxy 的创建和配置工作。这也是目前较为成熟的使用方式。

二是:使用Octavia 作为负载均衡器,Octavia是在LBaaS v2中加入到openstack中的,官方对它的定位不是要代替HAproxy在neutron中的地位,而是作为一个可选开源的LB服务提供者,类似LVS+F5等。Octavia的架构是全新设计的,而且在一开始就立志成为运营级的负载均衡解决方案。只是目前Octavia还是远谈不上成熟,官方推荐只在Devstack中使用。

 技术图片

HAproxy + keepalive

比较常用的开源负载均衡器有LVS、Nginx、HAproxy,其中LVS只能做到四层的负载均衡,即只能依据IP+端口的方式进行转发,不支持L7的转发策略,Nginx不仅能做Web服务器,同时也能作为负载均衡器使用;HAproxy 和Nginx都能基于L7策略进行转发。LVS也经常和HAproxy、Nginx混用,在大流量的集群中,先由LVS将流量分摊到不同的Nginx/HAproxy集群,再由Nginx/HAproxy做L7转发。除此之外Neutron也支持Ctrix、F5、Radware等公司的插件,从而通过专用的负载均衡硬件来实现。

 技术图片

LBaaS v2的经典实现方式就是在网络节点上部署HAproxy+Keepalive 实现负载均衡服务。 其中HAproxy提供L7的负载均衡,Keepalive用于实现高可用方案。

HAproxy

HAproxy能够为服务器池提供7层的负载均衡功能,即能根据HTTP请求头中的内容来执行负载均衡算法。而且作为开源软件,被广泛使用。

技术图片
1.启用lbaas v2首先需要修改neutron的配置文件,加入插件:

/etc/neutron/neutron.conf

service_plugins = [existing service plugins],neutron_lbaas.services.loadbalancer.plugin.LoadBalancerPluginv2

 

2.在lbaas的配置文件中添加lbaas v2:

/etc/neutron/neutron_lbaas.conf

service_provider = LOADBALANCERV2:Haproxy:neutron_lbaas.drivers.haproxy.plugin_driver.HaproxyOnHostPluginDriver:default

 

3.选择2层设备的驱动:

/etc/neutron/lbaas_agent.ini

[DEFAULT]
interface_driver = openvswitch

根据实际,选择 ovs 或者 linux bridge,需要与节点上的2层设备类型匹配。

 

4.开启数据库迁移

neutron-db-manage --subproject neutron-lbaas upgrade head

 

5.启动 lbaas v2 agent。

neutron-lbaasv2-agent --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/lbaas_agent.ini

来自 <https://docs.openstack.org/ocata/networking-guide/config-lbaas.html#configuring-lbaas-v2-with-octavia>

技术图片

 

随后即可以创建负载均衡器:

技术图片
1.创建负载平衡器,指定负载平衡的名称和关联的子网名。需指定与虚拟机所在的子网。

neutron lbaas-loadbalancer-create --name my-lb  private-subnet


2.为新负载平衡器创建侦听器。

neutron lbaas-listener-create \    //添加监听器
--loadbalancer my-lb \   //关联之前创建的负载均衡器
--protocol HTTP  \     //选择监听器协议,TCP\HTTP\HTTPS
--protocol-port  80 \     //选择监听器对外监听的端口(即向用户开放的端口)
--name webservice-listener \    //设置监听器名称



3.创建 LBaaS 服务器池。

neutron lbaas-pool-create --lb-algorithm  ROUND_ROBIN \  //选择负载均衡算法,支持上文中提到的轮询、最少连接、IP hash等
--listener LISTENER_1_NAME \     //关联监听器
--protocol HTTP \     //服务器池使用的协议
--name LB_POOL_1      //服务器名称
 

4.将服务器实例添加到创建的 LBaaS 池中。

neutron lbaas-member-create  --subnet <subnet-id> --address <server 1 IP> \    //将后端服务器添加到地址池中
--protocol-port 80 <pool name>       //后端服务器上服务所使用的端口,可以与前端的端口不一致

neutron lbaas-member-create  \   
--subnet <subnet-id> --address <server 2 IP> --protocol-port 80 <pool name>


5.设置Health monitor指标。

neutron lbaas-healthmonitor-create --delay DELAY_IN_SECONDS     //设置心跳检测发送到服务器成员的周期,单位为秒。需避免过于频繁的心跳检测,以及检测不及时的情况出现,达到平衡。对可用性要求高可以设置为3~5秒,

--type [HTTP | TCP]       //选择心跳检测的协议,如果TCP则只检测服务器上端口是否开启,HTTP则支持检测web服务的状态。当选择HTTP时,可以指定http的方法,默认是 get 一个特定的页面。同时还能指定服务器正常响应对应的HTTP状态码,如返回200时,代表web服务正常,200以外的值,如404、408等则代表异常。可通过 expected_codes  设置。url_path 则用来指定health monitor 请求的页面。

--max-retries NUMBER \      //设置在改变服务器可用状态之前,等待服务器的应答的次数。假设为n,如果是n次未响应,则切换为inactive,之后如果n次正常响应,则切换为active。推荐为 3
--timeout TIMEOUT_IN_SECONDS     //设置超时的时长,当超过该时长服务器都没有回应,则认为服务器此次心跳监测为故障。

--pool LBAAS_POOL       //将健康监测配置关联到服务器池。
一个服务器从出现故障,到负载均衡器发现并标记为不可用,不再为其分配流量,这其中需要的时间为:Time = delay *(max-retries -1) + timeout (*忽略从服务器发生故障到下一次健康监测中间的延时),在这个时间段内,负载均衡器都会为服务器分配流量。 6.分配浮动IP,为负载均衡器分配浮动IP与为云主机分配浮动IP是一样的,都是在fip的命名空间中为指定一个公网地址到内网地址的映射。这样外部的用户就可以通过公网地址直接访问到服务器池内的主机。如果作为内部使用的负载均衡器,则不需要分配浮动ip。 neutron floatingip-associate FLOATINGIP_ID LOAD_BALANCER_PORT_ID
技术图片

 

 

最后不要忘记设置防火墙和安全组,允许外部流量访问负载均衡器的VIP和开启的listener端口。

 

Keepalive

HAproxy的 Active/Standby 部署模式就是通过keepalive 来实现的。keepalive的核心是vrrp,openstack的HA中大量使用了vrrp协议来提供高可用,包括之前L3中提到的路由器的高可用。负载均衡器的vip将会配置在vrrp的 vip上,对外提供服务。同时vrrp会通过心跳检测负载均衡主备设备运行的状态,并实现vip的切换。

Octavia中还有一个假主备模式,即负载均衡在实际中为单节点部署,不过Octavia Controller内的Health manager会频繁检测负载均衡节点的运行状态,一旦发现负载均衡器故障,则从备用的负载均衡器中选一个代替故障的设备,并套用原来的配置。

 

Octavia

Octavia项目是在 Liberty 版本中随着LBaaS v2一同发布,其amphorea模块是实现负载均衡功能的模块,支持部署在虚拟机、容器、裸机上,为云上的租户提供负载均衡服务。

技术图片

上图是Octavia的架构,neutron原生集成了Octavia的驱动,可以直接通过Neutron的接口来完成Octavia的管理。同时Octavia也支持独立工作,其拥有独立的数据库,租户的配置信息不仅会保存在Neutron的数据库中,也会保存在Octavia的独立数据库中。(同时按照网上的部署经验,octavia和neutron的数据库同步是一个较大的问题)

 

Octavia 0.8版本中的amphorae 镜像是一台运行了HAproxy的ubuntu虚拟机,已经支持RH Linux、Centos、Fedora。未来还将支持以容器和裸金属的方式部署。

除此之外是Octavia的核心Controller,它包含4个组件:

  • API Controller:运行Octavia 的API,并接受外部的调用申请,然后通过消息总线传送给worker。
  • Controller Worker:负责执行API的各种操作,包括对nova、neutron接口的调用,以实现amphorae虚拟机的生命周期管理、创建端口、创建外部网络等资源,除此之外还有SSL证书、工作流等等功能管理。都由worker来一一实现。
  • Health manager:用于监控amphorae的运行状态,并执行amphorae的故障切换。
  • Housekeeping manager:用于删除无用的数据库记录,管理备用池和安全证书等。

 

用户在openstack环境中创建负载均衡服务时,创建amphorea虚拟机、端口、安全组等操作,这些都是由Octavia Controller自动完成,用户不可见,用户能见到的只有部署完成之后的Octavia的配置项和对应的网络端口。

service_provider = LOADBALANCERV2:Octavia:neutron_lbaas.drivers.octavia.driver.OctaviaDriver:default

 

 

 技术图片

Octavia的创建和配置命令与创建HAproxy的命令是完全一样的,配置好插件后 Octavia API Controller 将执行neutron指令,并完成amphorae的创建和配置等工作。

可见到Octavia项目目标是搭建一个完善的本地负载均衡管理平台,目前它是以虚拟机的方式提供服务,将来计划能够对云主机、容器、甚至裸机部署负载均衡服务,并支持Active、Active部署方式。

 

更多内容可以参考以下文章

https://docs.openstack.org/octavia/latest/reference/introduction.html

http://lingxiankong.github.io/blog/2016/03/30/octavia/

http://502245466.blog.51cto.com/7559397/1303506

 

Load Balancing as a Service : Liberty and Beyond

负载均衡本身的技术并不复杂,也发展得较为成熟,但如今负载均衡在各种云上扮演着非常重要的角色,各个云上与部署解决方案中都能看到它的身影。究其原因是其给租户的应用带来的弹性和可用性。云的租户可以在前端用户完全无感知的情况下,按负载增删后台服务器的数量,并实现服务的高可用,这非常符合云“按需使用”“分布式高可用服务”的理念。所以当服务的弹性伸缩和高可用性成为云计算的基本属性时,负载均衡器就开始在云上扮演不可替代的角色,可以说,不支持负载均衡的云不能称之为云。而传统的硬件负载均衡器无论是在可靠性、扩展性、可编程性、成本等方面都无法满足云供应商的需求。

 技术图片技术图片

 

Otavia的加入也可以说是openstack社区很清楚地看到了这一趋势,并立志将负载均衡单独拿出neutron作为一个重要项目来对待。从Octavia支持的部署模式就能看出这一项目的野心。或许它未来将成为一个跨虚拟机、容器、裸机的统一负载均衡服务。

 

 

负载均衡:

建立在现有的网络之上,提供了一种廉价、有效、透明的方法来扩大网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力,以及提高网络的灵活性和可用性。通过负载均衡器,可以实现N台廉价的Linux服务器并行处理,从面达到小型机或大型机的计算能力。单台负载均衡器位于网站的最前端,它起着分流客户请求的作用,相当于整个网站或系统的入口。由于IPv4中IP地址日益紧张以及出于安全方面的才虑,很多网络使用保留IP地址(如10.0.0.0/255.0.0.0、172.16.0.0/255.128.0.0、和192.168.0.0/255.255.0.0).这些不在Internet上使用,而是专门为内部网络预留的。当内部网络中的主机要访问Internet或被Internet访问时,就需要进行网络地址转换(Network Address Translation,NAT),NAT方法就是交不同IP地址的并行网络服务变成一个在同一IP地址上的虚拟服务。

以LVS(Linux Virtual Server)作为负载均衡器:    

LVS类型:

     NAT-->(DNAT)

     DR

     TUN

     FULLNAT(貌似没有)

技术图片

LVS的常见名词解释

CIP<-->VIP--DIP<-->RIP
Direct Routing:直接路由
负载均衡层(Loader Balancer),它就是我们所说的的Director
RS real server :真实提供服务的计算机
VIP:Virtual IP(VIP)address:Director用来向客户端提供服务的IP地址
RIP:Real IP (RIP) address:集群节点(后台真正提供服务的服务器)所使用的IP地址
DIP:Director‘s IP (DIP) address:Director用来和D/RIP 进行联系的地址
CIP:Client computer‘s IP (CIP) address:公网IP,客户端使用的IP

 

LVS NAT的特性

1.RS应该使用私有地址
2.RS的网关必须指向DIP
3.RIP和DIP必须在同一网段内
4.请求和响应的报文都得经过Director,在高负载场景中,Director很可能成为性能瓶颈
5.支持端口映射
6.RS可以使用任意支持集群服务的OS

LVS DR类型

技术图片

1.让前段路由将请求发往VIP时,只能是Dirctor上的VIP
解决方案
1.静态地址绑定
未必有路由器的配置权限
Director调用时静态地址绑定将难以使用
   2.arptables
   3.修改linux内核参数,将RS上的VIP配置在lo接口的别名上,限制linux仅对对应接口的ARP请求做相应

 Session持久机制
1.Session绑定:始终将统一请求者的连接定向至统一RS(第一次请求时仍有调度选择):没有容错能力,有损均衡效果
2.session复制:在RS之间同步session,因此,每个RS持集群中所有的session;对于大规模集群环境不适用
3.session服务器:利用单独部署的服务器来统一管理session

LVS的集群服务:
四层交换,四层路由
根据请求目标套接字(包括端口的协议类型tcp,udp)来实现转发

 

 

LVS DR类型的特性

1.RS可以使用私有地址,还可以使用公网地址,此时可以直接通过互联网连入RS,以实现配置、监控等
2.RS的网关一定不能指向DIP
3.RS跟Dirctory要在同一物理网络内(不能有路由器分隔)
4.请求报文经过Directory,但响应报文一定不经过Director
5.不支持端口映射
6.RS可以使用大多数的操作系统


LVS TUN类型:IP隧道
  1.RIP,DIP,VIP都得是公网地址
  2.RS的网关不会指向也不可能指向DIP
  3.请求报文经过Directory,但响应报文一定不经过Director
  4.不支持端口映射
  5.RS的OS必须得支持隧道功能

 

 

 VS/NAT的体系结构比较简单:在一组服务器前有一个调度器,它们是通过Switch/HUB相连接的,这些服务器提供相同的网络服务、相同的服务内容,即不管请求被发送到哪一台服务器,执行结果都是一样的。服务的内容可以复制到每一台服务器的本地硬盘上,可能通过网络文件系统共享,也可以通过一个分布式文件系统来提供。

 

LVS NAT的特性:

1、RS应该使用私有地址;

2、RS的网关的必须指向DIP;

3、RIP和DIP必须在同一网段内;

4、请求和响应的报文都得经过Director;在高负载场景中,Director很可能成为系统性能瓶颈;

5、支持端口映射;

6、RS可以使用任意支持集群服务的OS;

 

   VS/DR或VS/TUN应用的一种模型中(所有机器都在同一个物理网络),所有机器(包括Director和RealServer)都使用了一个额外的IP地址,即VIP。当一个客户端向VIP发出一个连接请求时,此请求必须要连接至Director的VIP,而不能是RealServer的。因为,LVS的主要目标就是要Director负责调度这些连接请求至RealServer的。

因此,在Client发出至VIP的连接请求后,只能由Director将其MAC地址响应给客户端(也可能是直接与Director连接的路由设备),而Director则会相应的更新其ipvsadm table以追踪此连接,而后将其转发至后端的RealServer之一。

  如果Client在请求建立至VIP的连接时由某RealServer响应了其请求,则Client会在其MAC table中建立起一个VIP至RealServer的对就关系,并以至进行后面的通信。此时,在Client看来只有一个RealServer而无法意识到其它服务器的存在。

为了解决此问题,可以通过在路由器上设置其转发规则来实现。当然,如果没有权限访问路由器并做出相应的设置,则只能通过传统的本地方式来解决此问题了。这些方法包括:

1、禁止RealServer响应对VIP的ARP请求;

2、在RealServer上隐藏VIP,以使得它们无法获知网络上的ARP请求;

3、基于“透明代理(Transparent Proxy)”或者“fwmark (firewall mark)”;

4、禁止ARP请求发往RealServers;

  

LVS DR类型的特性:

1、RS可以使用私有地址;但也可以使用公网地址,此时可以直接通过互联网连入RS以实现配置、监控等;

2、RS的网关一定不能指向DIP;

3、RS跟Dirctory要在同一物理网络内(不能由路由器分隔);

4、请求报文经过Directory,但响应报文一定不经过Director

5、不支持端口映射;

6、RS可以使用大多数的操作系统;

 

LVS TUN类型:IP隧道

1、RIP、DIP、VIP都得是公网地址;

2、RS的网关不会指向也不可能指向DIP;

3、请求报文经过Directory,但响应报文一定不经过Director;

4、不支持端口映射;

5、RS的OS必须得支持隧道功能;

 

LVS Scheduling Method LVS的调度方法:
技术图片

1.Fixed Scheduling Method  静态调服方法

(1).RR     轮询
(2).WRR    加权轮询
(3).DH     目标地址hash
(4).SH     源地址hash
2.Dynamic Scheduling Method 动态调服方法
(1).LC     最少连接
(2).WLC    加权最少连接
(3).SED    最少期望延迟
(4).NQ     从不排队调度方法
(5).LBLC   基于本地的最少连接
(6).LBLCR  带复制的基于本地的最少连接
 
ipvsadm组件定义规则的格式:
1.定义集群服务格式:
(1).添加集群服务:
ipvsadm -A|E -t|u|f service-address [-s scheduler]
              [-p [timeout]] [-M netmask]
-A:                  表示添加一个新的集群服务
-E:                  编辑一个集群服务
-t:                  表示tcp协议
-u:                  表示udp协议
-f:                  表示firewall-Mark,防火墙标记
service-address:     集群服务的IP地址,即VIP
-s                    指定调度算法
-p                    持久连接时长,如#ipvsadm -Lcn ,查看持久连接状态
-M                    定义掩码
 
ipvsadm -D -t|u|f service-address      删除一个集群服务
ipvsadm -C                             清空所有的规则
ipvsadm -R                             重新载入规则
ipvsadm -S [-n]                        保存规则
 
2.向集群服务添加RealServer规则:
(1).添加RealServer规则
ipvsadm -a|e -t|u|f service-address -r server-address
              [-g|i|m] [-w weight]
-a                 添加一个新的realserver规则
-e                 编辑realserver规则
-t                 tcp协议
-u                 udp协议
-f                 firewall-Mark,防火墙标记
service-address    realserver的IP地址
-g                 表示定义为LVS-DR模型
-i                 表示定义为LVS-TUN模型
-m                 表示定义为LVS-NAT模型
-w                 定义权重,后面跟具体的权值
ipvsadm -d -t|u|f service-address -r server-address          --删除一个realserver
ipvsadm -L|l [options]                                       --查看定义的规则
如:#ipvsadm -L -n  
ipvsadm -Z [-t|u|f service-address]                          --清空计数器
 
LVS-NAT 模型实例 

打开路由间转发功能

[root@mgm-net0 ~]# sysctl -a | grep net.ipv4.ip_forward
sysctl: reading key "net.ipv6.conf.all.stable_secret"
net.ipv4.ip_forward = 1

若为0,设置为1:

echo 1 > /proc/sys/net/ipv4/ip_forward

sysctl  -p      //立即生效

 

查看ipvs支持功能

[root@mgm-net0 ~]# grep -E -i "ipvs|IP_VS" /boot/config-3.10.0-862.11.6.el7.x86_64
CONFIG_NETFILTER_XT_MATCH_IPVS=m
CONFIG_IP_VS=m
CONFIG_IP_VS_IPV6=y
# CONFIG_IP_VS_DEBUG is not set
CONFIG_IP_VS_TAB_BITS=12
# IPVS transport protocol load balancing support
CONFIG_IP_VS_PROTO_TCP=y
CONFIG_IP_VS_PROTO_UDP=y
CONFIG_IP_VS_PROTO_AH_ESP=y
CONFIG_IP_VS_PROTO_ESP=y
CONFIG_IP_VS_PROTO_AH=y
CONFIG_IP_VS_PROTO_SCTP=y
# IPVS scheduler
CONFIG_IP_VS_RR=m
CONFIG_IP_VS_WRR=m
CONFIG_IP_VS_LC=m
CONFIG_IP_VS_WLC=m
CONFIG_IP_VS_LBLC=m
CONFIG_IP_VS_LBLCR=m
CONFIG_IP_VS_DH=m
CONFIG_IP_VS_SH=m
CONFIG_IP_VS_SED=m
CONFIG_IP_VS_NQ=m
# IPVS SH scheduler
CONFIG_IP_VS_SH_TAB_BITS=8
# IPVS application helper
CONFIG_IP_VS_FTP=m
CONFIG_IP_VS_NFCT=y
CONFIG_IP_VS_PE_SIP=m

查看速率信息

  1. [root@lvs-server ~]# ipvsadm -Ln --rate  
  2. IP Virtual Server version 1.2.1 (size=4096)
  3. Prot LocalAddress:Port                 CPS    InPPS   OutPPS    InBPS   OutBPS
  4.   -> RemoteAddress:Port
  5. TCP  10.0.0.50:80                             1        5           5           449       550
  6.   -> 192.168.1.51:80                       0         3           2           228       275
  7.   -> 192.168.1.52:8080                   0         3           2           221       275
  8. CPS:每秒的连接数
  9. InPPS:每秒流入包个数
  10. OutPPS:每秒流出包个数
  11. InBPS:每秒进入流量(字节)
  12. OutBPS:每秒流出流量(字节)

 

在配置完规则之后需要保存和重载,规则保存在/etc/sysconfig/ipvsadm文件中

 
  1. #保存ipvsadm规则至/etc/sysconfig/ipvsadm文件中
  2. [root@lvs-server ~]# ipvsadm -S >/etc/sysconfig/ipvsadm  
  3. [root@lvs-server ~]# cat /etc/sysconfig/ipvsadm 

#从文件中重载所有规则

[root@lvs-server ~]# ipvsadm -R </etc/sysconfig/ipvsadm

修改集群服务10.0.0.50:80中的调度算法为sh

[root@lvs-server ~]# ipvsadm -E -t 10.0.0.50:80 -s sh  

查看当前的IPVS连接

[root@lvs-server ~]# ipvsadm -lnc  

清空、保存和重载命令

  1. 清空所有规则:ipvsadm -C  
  2. 保存所有规则:ipvsadm -S [-n]  
  3. 重载所有规则:ipvsadm -R  

neutron-lbaas-lvs

Neutron LBaaS应该支持LVS。

LVS优于HAProxy的一个优点是LVS支持客户端的透明性(即不要SNAT)。

用例

1)制作一个处理LBaaS并连接两个内部端口的路由器,一个是池的子网,一个是vip的子网。请注意,路由器也用作普通路由器。

技术图片

2)创建一个池和一个vip,并指定路由器id为‘router_id‘属性。请注意‘router_id‘属性是通过‘routed-service-insertion‘扩展名添加的。

就这样。

请注意,浮动可以附加到贵宾。

技术图片

lbaas-lvs实现:namespace lvs-xxx下

底层代码实现:

class LvsDriver(agent_device_driver.AgentDeviceDriver):

[root@node0 ~]# ipvsadm -C

[root@node0 ~]# ipvsadm -ln --stats

IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Conns InPkts OutPkts InBytes OutBytes
-> RemoteAddress:Port
[root@node0 ~]# ipvsadm -A -u 10.33.46.64:9999 -s sh -p 120
[root@node0 ~]# ipvsadm -ln --stats
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Conns InPkts OutPkts InBytes OutBytes
-> RemoteAddress:Port
UDP 10.33.46.64:9999 0 0 0 0 0
[root@node0 ~]# ipvsadm -a -u 10.33.46.64:9999 -r 10.33.46.68:9999 -m -w 1
[root@node0 ~]# ipvsadm -ln --stats
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Conns InPkts OutPkts InBytes OutBytes
-> RemoteAddress:Port
UDP 10.33.46.64:9999 0 0 0 0 0
-> 10.33.46.68:9999 0 0 0 0 0
[root@node0 ~]# arping -c 1 10.33.46.68
ARPING 10.33.46.68 from 10.33.46.64 tap85d707e7-35
Unicast reply from 10.33.46.68 [FA:16:3E:0D:A6:AB] 1.310ms
Sent 1 probes (1 broadcast(s))
Received 1 response(s)
[root@node0 ~]# netcat -uvz -w 1 10.33.46.68 9999
[root@node0 ~]# netcat -uvz -w 1 10.33.46.64 9999
Warning: Host 10.33.46.64 isn‘t authoritative! (direct lookup mismatch)
10.33.46.64 -> mgm-net0 BUT mgm-net0 -> 172.30.65.2
[root@node0 ~]# netcat -uvz -w 1 10.33.46.68 9990
[root@node0 ~]# ipvsadm -ln --stats
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Conns InPkts OutPkts InBytes OutBytes
-> RemoteAddress:Port
UDP 10.33.46.64:9999 2 2 0 64 0
-> 10.33.46.68:9999 2 2 0 64 0
[root@node0 ~]# ipvsadm -ln --stats
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Conns InPkts OutPkts InBytes OutBytes
-> RemoteAddress:Port
UDP 10.33.46.64:9999 2 3 0 111 0
-> 10.33.46.68:9999 2 3 0 111 0
[root@node0 ~]# ipvsadm -ln --stats
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Conns InPkts OutPkts InBytes OutBytes
-> RemoteAddress:Port
UDP 10.33.46.64:9999 2 4 0 142 0
-> 10.33.46.68:9999 2 4 0 142 0

测试:

负载均衡器的成员虚机上,server监听端口

[root@host-10-33-46-68 ~]# nc -ul  10.33.46.68 9999

[root@node0 ~]# ipvsadm -Z       ====清空统计数据
[root@node0 ~]# ipvsadm -ln --stats     ==查看统计
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Conns InPkts OutPkts InBytes OutBytes
-> RemoteAddress:Port
UDP 10.33.46.64:9999 0 0 0 0 0
-> 10.33.46.68:9999 0 0 0 0 0

client发包

[root@node2 ~]# echo "hello word"|nc -nuv 10.33.46.64 9999

Ncat: Version 7.50 ( https://nmap.org/ncat )
Ncat: Connected to 10.33.46.64:9999.
Ncat: 11 bytes sent, 0 bytes received in 0.02 seconds.

server端收到数据

[root@host-10-33-46-68 ~]# nc -ul 10.33.46.68 9999
hello word

[root@node0 ~]# ipvsadm -ln --stats

IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Conns InPkts OutPkts InBytes OutBytes
-> RemoteAddress:Port
UDP 10.33.46.64:9999 1 1 0 39 0
-> 10.33.46.68:9999 1 1 0 39 0

 

 

部署LVS-DR集群
3.1 问题
使用LVS实现DR模式的集群调度服务器,为用户提供Web服务:

路由器对外公网IP地址为202.114.106.20

路由器内网IP地址为192.168.0.254

路由是需要设置SNAT及DNAT功能

LVS调度器真实IP地址为192.168.0.10

LVS调度器VIP地址设置为192.168.0.253

真实Web服务器地址分别为192.168.0.1、192.168.0.2

使用加权轮询调度算法,真实服务器权重与其IP地址末尾数一致

3.2 方案
使用4台虚拟机,1台作为Linux路由器、1台作为Director调度器、2台作为Real Server、物理机作为客户端,拓扑结构如图-2所示。


 https://blog.csdn.net/qq_27384769/article/details/81291622

 

 https://www.cnblogs.com/pmyewei/p/7376921.html

 

 

 

 

 

 

Neutron:LBaaS v2——ipvsadm实现LVS

标签:dip   进化   信息   意思   keep   via   local   文件类型   lin   

原文地址:https://www.cnblogs.com/liuhongru/p/11067678.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!