IP调度服务器是啥东西

㈠ LVS四种工作模式原理

LVS 是 Linux Virtual Server ：Linux 虚拟服务器；是一个虚拟的服务器集群【多台机器 LB IP】。

负载调度器(load balancer) ：它是整个LVS 集群对外的前端机器，负责将client请前孙求发送到一组服务器[多台LB IP]上执行，而client端认为是返回来一个同一个IP【通常把这个IP 称为虚拟IP/VIP】
服务器池(server pool) ：一组真正执行client 请求的服务器，一般是我们的web服务器；除了web，还有FTP，MAIL，DNS
共享存储(shared stored) ：它为 server pool 提供了一个共享的存储区，很容易让服务器池拥有相同的内容，提供相同的服务

常用术语

VS：Virtual Server #虚拟服务，一个抽象的服务，用于最开始接收 web 请求的服务
Director, Balancer #负载均衡器、分发器
RS：Real Server # 真正提供服务的服务器
CIP: Client IP #用户端IP，发起请求的客户端 IP，一般是公网 IP
VIP：Director Virtual IP #负载均衡器虚拟IP
DIP：Director IP #负载均衡器IP
RIP：Real Server IP #真正提供 web 服务的服务器的 IP

（1）直接路由模式（LVS-DR）
互联网使用比较多的一种模式
DR模式是通过改写请求报文的目标MAC地址，将请求发给真实服务器的，而真实服务器响应后的处理结果直接返回给客户端用户。同TUN模式一样，DR模式可以极大的提高集群系统的伸缩性。而且DR模式没有IP隧道的开销，对集群中的真实服务器也没有必要必须支持IP隧道协议的要求。但是要求调度器LB与真实服务器RS都有一块网卡连接到同一物理网脊烂段上，必须在同一个局域网环境。

DR模式特点
优点：和TUN（隧道模式）一样，负载均衡器也只是分发请求，应答包通过单独的路由方法返回给客户端。与VS-TUN相比，VS-DR这种实现方式不需要隧道结构，因此可以使用大多数操作系统做为物理服务器。
缺点：（不能说缺点，只能说是不足）要求负载均衡器的网卡必须与物理网卡在一个物理段上。

（2）NAT模式（LVS-NAT）
NAT模式是通过网络地址转换的方法来实现调度的。首先调度器(LB)接收到客户的请求数据包时（请求的目的IP为VIP），根据调度算法决定将请求发送给哪个后端的真实服务器（RS）。然后调度就把客户端发送的请求数据包的目标IP地址及端口改成后端真实服务器的IP地址（RIP）,这样真实服务器（RS）就能够接收到客户的请求数据包了。真实服务器响应完请求后，查看默认路由（NAT模式下我们需要把RS的默认路由设置为LB服务器。）把响应后的数据包发送给LB,LB再接收到响应包后，把包的源慧野链地址改成虚拟地址（VIP）然后发送回给客户端。

NAT模式特点：
1、NAT技术将请求的报文和响应的报文都需要通过LB进行地址改写，因此网站访问量比较大的时候LB负载均衡调度器有比较大的瓶颈，一般要求最多之能10-20台节点
2、只需要在LB上配置一个公网IP地址就可以了。
3、每台内部的节点服务器的网关地址必须是调度器LB的内网地址。
4、NAT模式支持对IP地址和端口进行转换。即用户请求的端口和真实服务器的端口可以不一致。

（3）Full NAT模式（LVS-FullNAT）
客户端对VIP发起请求，Director接过请求发现是请求后端服务。Direcrot对请求报文做full-nat，把源ip改为Dip，把目标ip转换为任意后端RS的rip，然后发往后端，rs接到请求后，进行响应，响应源ip为Rip，目标ip还是DIP，又内部路由路由到Director,Director接到响应报文，进行full-nat。将源地址为VIP，目标地址改为CIP
请求使用DNAT，响应使用SNAT

Full NAT模式特点：
FULL NAT 模式也不需要 LBIP 和realserver ip 在同一个网段；
full nat 跟nat 相比的优点是：保证RS回包一定能够回到LVS；因为源地址就是LVS==> 不确定
full nat 因为要更新sorce ip 所以性能正常比nat 模式下降 10%

(4）IP隧道模式（LVS-Tunnel）
采用NAT模式时，由于请求和响应的报文必须通过调度器地址重写，当客户请求越来越多时，调度器处理能力将成为瓶颈。为了解决这个问题，调度器把请求的报文通过IP隧道转发到真实的服务器。真实的服务器将响应处理后的数据直接返回给客户端。这样调度器就只处理请求入站报文，由于一般网络服务应答数据比请求报文大很多，采用VS/TUN模式后，集群系统的最大吞吐量可以提高10倍。
它和NAT模式不同的是，它在LB和RS之间的传输不用改写IP地址。而是把客户请求包封装在一个IP tunnel里面，然后发送给RS节点服务器，节点服务器接收到之后解开IP tunnel后，进行响应处理。并且直接把包通过自己的外网地址发送给客户不用经过LB服务器。

ip隧道模式特点：
负载均衡器只负责将请求包分发给后端节点服务器，而RS将应答包直接发给用户。所以，减少了负载均衡器的大量数据流动，负载均衡器不再是系统的瓶颈，就能处理很巨大的请求量，这种方式，一台负载均衡器能够为很多RS进行分发。而且跑在公网上就能进行不同地域的分发。
隧道模式的RS节点需要合法IP，这种方式需要所有的服务器支持”IP Tunneling”(IP Encapsulation)协议，服务器可能只局限在部分Linux系统上。

四种模式性能比较：
因为DR模式 IP TUNELL 模式都是在package in 时经过LVS ，在package out是直接返回给client，所以二者的性能比NAT 模式高，但IP TUNNEL 因为是TUNNEL 模式比较复杂，其性能不如DR模式；
FULL NAT 模式因为不仅要更换 DST IP 还更换 SOURCE IP 所以性能比NAT 下降10%
4种模式的性能如下：DR ==> IP TUNNEL ==>NAT ==>FULL NAT

㈡ ip地址调度规则列表

本质上讲，网络负载平衡是分布式作业调度系统的一种实现。平衡器作为网络请求分配的控制者，要根据集群节点的当前处理能力，采用集中或分布策略对网络服务请求进行调配，并且在每个服务请求的生命周期里监控各个节点的有效状态。一般的说，平衡器对请求的调度具备以下的特征：

网络服务请求必须是可管理的
请求的分配对用户是透明的
最好能够提供异构系统的支持
能够依据集群节点的资源情况进行动态分配和调整
负载平衡器在集群的各个服务节点中分配工作负载或网络流量。可以静态预先设置或根据当前的网络状态来决定负载分发到哪个特定的节点，节点在集群内部可以互相连接，但它们必须与平衡器直接或间接相连。
网络平衡器可以认为是网络层次上的作业调度系统，大多数网络负载平衡器能够在网络的相应层次上实现单一系统映像，整个集群能够体现为一个单一的IP地址被用户访问，而具体服务的节点对用户而言是透明的。这里，平衡器可静态或动态配置，用一种或多种算法决定哪个节点获得下一个网络服务请求。

2．网络平衡原理

在TCP/IP协议中，数据包含有必要的网络信息，因而在网络缓存或网络平衡的具体实现算法里，数据包的信息很重要。但由于数据包是面向分组的（IP）和面向连接的（TCP），且经常被分片，没有与应用有关的完整信息，特别是和连接会话相关的状态信息。因此必须从连接的角度看待数据包——从源地址的端口建立到目的地址端口的连接。

平衡考虑的另一个要素就是节点的资源使用状态。由于负载平衡是这类系统的最终目的，那么及时、准确的把握节点负载状况，并根据各个节点当前的资源使用状态动态调整负载平衡的任务分布，是网络动态负载平衡集群系统考虑的另一关键问题。

一般情况下，集群的服务节点可以提供诸如处理器负载，应用系统负载、活跃用户数、可用的网络协议缓存以及其他的资源信息。信息通过高效的消息机制传给平衡器，平衡器监视所有处理节点的状态，主动决定下个任务传给谁。平衡器可以是单个设备，也可以使一组平行或树状分布的设备。

3．基本的网络负载平衡算法

平衡算法设计的好坏直接决定了集群在负载均衡上的表现，设计不好的算法，会导致集群的负载失衡。一般的平衡算法主要任务是决定如何选择下一个集群节点，然后将新的服务请求转发给它。有些简单平衡方法可以独立使用，有些必须和其它简单或高级方法组合使用。而一个好的负载均衡算法也并不是万能的，它一般只在某些特殊的应用环境下才能发挥最大效用。因此在考察负载均衡算法的同时，也要注意算法本身的适用面，并在采取集群部署的时候根据集群自身的特点进行综合考虑，把不同的算法和技术结合起来使用。

3．1 轮转法：

轮转算法是所有调度算法中最简单也最容易实现的一种方法。在一个任务队列里，队列的每个成员（节点）都具有相同的地位，轮转法简单的在这组成员中顺序轮转选择。在负载平衡环境中，均衡器将新的请求轮流发给节点队列中的下一节点，如此连续、周而复始，每个集群的节点都在相等的地位下被轮流选择。这个算法在DNS域名轮询中被广泛使用。

轮转法的活动是可预知的，每个节点被选择的机会是1/N，因此很容易计算出节点的负载分布。轮转法典型的适用于集群中所有节点的处理能力和性能均相同的情况，在实际应用中，一般将它与其他简单方法联合使用时比较有效。

3．2 散列法

散列法也叫哈希法（HASH），通过单射不可逆的HASH函数，按照某种规则将网络请求发往集群节点。哈希法在其他几类平衡算法不是很有效时会显示出特别的威力。例如，在前面提到的UDP会话的情况下，由于轮转法和其他几类基于连接信息的算法，无法识别出会话的起止标记，会引起应用混乱。

而采取基于数据包源地址的哈希映射可以在一定程度上解决这个问题：将具有相同源地址的数据包发给同一服务器节点，这使得基于高层会话的事务可以以适当的方式运行。相对称的是，基于目的地址的哈希调度算法可以用在Web Cache集群中，指向同一个目标站点的访问请求都被负载平衡器发送到同一个Cache服务节点上，以避免页面缺失而带来的更新Cache问题。

3．3 最少连接法

在最少连接法中，平衡器纪录目前所有活跃连接，把下一个新的请求发给当前含有最少连接数的节点。这种算法针对TCP连接进行，但由于不同应用对系统资源的消耗可能差异很大，而连接数无法反映出真实的应用负载，因此在使用重型Web服务器作为集群节点服务时（例如Apache服务器），该算法在平衡负载的效果上要打个折扣。为了减少这个不利的影响，可以对每个节点设置最大的连接数上限（通过阈值设定体现）。

3．4 最低缺失法

在最低缺失法中，平衡器长期纪录到各节点的请求情况，把下个请求发给历史上处理请求最少的节点。与最少连接法不同的是，最低缺失记录过去的连接数而不是当前的连接数。

3．5 最快响应法

平衡器记录自身到每一个集群节点的网络响应时间，并将下一个到达的连接请求分配给响应时间最短的节点，这种方法要求使用ICMP包或基于UDP包的专用技术来主动探测各节点。

在大多数基于LAN的集群中，最快响应算法工作的并不是很好，因为LAN中的ICMP包基本上都在10ms内完成回应，体现不出节点之间的差异；如果在WAN上进行平衡的话，响应时间对于用户就近选择服务器而言还是具有现实意义的；而且集群的拓扑越分散这种方法越能体现出效果来。这种方法是高级平衡基于拓扑结构重定向用到的主要方法。

3．6 加权法

加权方法只能与其他方法合用，是它们的一个很好的补充。加权算法根据节点的优先级或当前的负载状况（即权值）来构成负载平衡的多优先级队列，队列中的每个等待处理的连接都具有相同处理等级，这样在同一个队列里可以按照前面的轮转法或者最少连接法进行均衡，而队列之间按照优先级的先后顺序进行均衡处理。在这里权值是基于各节点能力的一个估计值。

4、动态反馈负载均衡

当客户访问集群资源时，提交的任务所需的时间和所要消耗的计算资源是千差万别的，它依赖于很多因素。例如：任务请求的服务类型、当前网络带宽的情况、以及当前服务器资源利用的情况等等。一些负载比较重的任务需要进行计算密集的查询、数据库访问、很长响应数据流；而负载比较轻的任务请求往往只需要读一个小文件或者进行很简单的计算。

对任务请求处理时间的不同可能会导致处理结点利用率的倾斜（Skew），即处理结点的负载不平衡。有可能存在这样情况，有些结点已经超负荷运行，而其他结点基本是闲置着。同时，有些结点已经忙不过来，有很长的请求队列，还不断地收到新的请求。反过来说，这会导致客户长时间的等待，而集群整体的服务质量下降。因此，有必要采用一种机制，使得平衡器能够实时地了解各个结点的负载状况，并能根据负载的变化做出调整。

具体的做法上采用了基于负反馈机制的动态负载均衡算法，该算法考虑每一个结点的实时负载和响应能力，不断调整任务分布的比例，来避免有些结点超载时依然收到大量请求，从而提高单一集群的整体吞吐率。

在集群内，负载均衡器上运行服务端监控进程，监控进程负责监视和收集集群内各个结点的负载信息；而每个结点上运行客户端进程，负责定时向均衡器报告自身的负载状况。监控进程根据收到的全部结点的负载信息来进行同步操作，既对将要分配的任务按照权值得比例重新进行分布。权值得计算主要根据各个结点的CPU利用率、可用内存以及磁盘I/O状况计算出新的权值，若新权值和当前权值的差值大于设定的阀值，监控器采用新的权值对集群范围内的任务重新进行分布，直到下一次的负载信息同步到来之前。均衡器可以配合动态权值，采用加权轮询算法来对接受的网络服务请求进行调度。

4．1 加权轮询调度

加权轮询调度（Weighted Round-Robin Scheling）算法用相应的权值表示结点的处理性能。该算法根据权值的高低顺序并按照轮询的方式将任务请求分配到各结点。权值高的结点比权值低的结点处理更多的任务请求，相同权值的结点处理相同份额的请求。加权轮询的基本原理可描述为：

假设某集群内有一组结点N = {N0, N1, …, Nn-1}，W(Ni)表示结点Ni的权值，
一个指示变量i表示上一次选择的服务器，T（Ni）表示结点Ni当前所分配的任务量。

∑T(Ni) 表示当前同步周期需要处理的任务总量。

∑W(Ni) 表示结点的权值总和。

则： W(Ni)/ ∑W(Ni)= T(Ni)/ ∑T(Ni)
表示任务的分配是按照各个结点权值占权值总数的比例来进行分配。

4.2 权值计算

当集群的结点初次投入系统中使用时，系统管理员根据结点的硬件配置情况对每个结点都设定一个初始权值DW（Ni）（通常根据结点的硬件配置来定义，硬件配置越高的结点默认值越高），在负载均衡器上也先使用这个权值。然后，随着结点负载的变化，均衡器对权值进行调整。

动态权值是由结点运行时各方面的参数计算出来的。我们在实验中选取了最重要几项，包括：CPU资源，内存资源，当前进程数，响应时间等信息作为计算公式的因子。结合每个结点当前的权值，可以计算出新的权值的大小。动态权值目的是要正确反映结点负载的状况，以预测结点将来可能的负载变化。对于不同类型的系统应用，各个参数的重要程度也有所不同。典型的Web应用环境下，可用内存资源和响应时间就非常重要；如果用户以长的数据库事务为主，则CPU使用率和可用内存就相对重要一些。为了方便在系统运行过程中针对不同的应用对各个参数的比例进行适当调整，我们为每一个参数设定一个常量系数 Ri ，用来来表示各个负载参数的重要程度，其中∑ Ri = 1。因此，任何一个结点Ni的权值公式就可以描述为：

LOAD(Ni)=R1*Lcpu(Ni)+R2*Lmemory(Ni)+R3*Lio(Ni)+R4*Lprocess(Ni)+R5*Lresponse(Ni)

其中Lf(Ni) 表示结点Ni 当前某一项参数的负载值，

上述公式中依次表示为：CPU使用率、内存使用率、
磁盘I/O访问率、进程总数以及响应时间。

例如，在WEB服务器集群中，我们采用以系数{0.1, 0.4, 0.1, 0.1, 0.3}，这里认为服务器的内存和请求响应时间较其他参数重要一些。若当前的系数Ri不能很好地反映应用的负载，系统管理员可以对系数不断地修正，直到找到贴近当前应用的一组系数。

另外，关于采集权值的周期置，虽然很短的周期可以更确切地反映各个结点的负载，但是很频繁地采集（如1秒1次或者多次）会给均衡器和结点带来负担，也可能增加不必要的网络负荷。另外，由于采集器是在采集时刻进行负载计算的，经实验证明，均衡器反映出来各个结点的负载信息会出现剧烈的抖动，均衡器无法准确捕捉结点真实的负载变化趋势。因此解决这些问题，一方面要适当地调整采集负载信息的周期，一般在5～10秒；另一方面，可以使用移动平均线或者是滑动窗口来避免抖动，使得均衡器收集到的负载信息表现为平滑曲线，这样在负反馈机制的调整效果上就会比较好。

均衡器的动态权值采集程序周期性地运行，若缺省权值不为零，则查询该结点的各负载参数，并计算出动态权值LOAD(Ni) 。我们引入以下权值计算公式，结合结点的初始权值和采集的动态权值来计算最终的权值结果。

Wi = A*DW(Ni)+B*(LOAD(Ni)-DW(Ni))1/3

在公式中，如果动态权值恰好等于初始权值，最终权值不变，则说明系统的负载状况刚好达到理想状况，等于初始权值DW(Ni)。如果动态权值计算结果高于初始权值，最终权值变高，则说明系统负载很轻，均衡器将会增加分配给该结点的任务比率。如果动态权值低于初始权值，最终权值变低，说明系统开始处于重载状况，均衡器将会减少对该结点分配的任务。在实际使用中，若发现所有结点的权值都小于他们的DW(Ni)，则说明当前个集群处于超载状态，这时需要加入新的结点到集群中来处理部分负载；反之，若所有结点的权值大大高于DW(Ni)，则说明当前系统的负载都比较轻。

5、总结

网络负载平衡是集群作业调度系统的具体实现。由于其处理的作业单元是TCP/IP协议下的网络连接，因此可以采用面向网络连接的集中基本调度算法。考虑集群负载不平衡的可能，采取了动态获取服务节点的权值并使用负反馈机制调整平衡器对网络服务请求的分布，以适应服务节点在运行过程中资源的变化。笔者也在LVS集群系统的基础上，配合原有的轮询算法对其进行改进，增加了采集动态权值的程序并实时反馈到负载平衡器的调度系统上。实践证明，采用动态平衡在集群系统的整体吞吐量方面有所提高，特别是在集群各个节点性能不一，集群提供的网络服务程序所访问的资源多样化的情况下，负反馈机制的效果尤其明显。在其他类型的集群中，负反馈机制的动态负载平衡也能够得到很好的应用，只是平衡器所处理的作业单元不同于网络连接，而具体的负载算法上也将有所不同。

㈢ Nginx做负载均衡，调度是使用ip_hash 我用不同机器每次都登陆的是同一个服务器请问是什么问题

这个是很正常的，ip_hash的负载均衡是以客户端的ip地址作为hash错作的key进而计算hash值得。这种策略能保证一个ip访问到的永远是同一台机器。
（1）但是有一种情况就是多个ip的hash值是相同的，在这种情况下，这几个不同的ip访问到的就是同一台机器了。
（2）还有一种情况就是，虽然你每次用不同的机器，但是这些机器都是通过一个相同的出口ip来访问服务器，这时，你访问到的也永远是一台服务器。