负载平衡服务器简单相关

文章链接:http://www.cnblogs.com/loveis715/p/4547968.html

解决方案:

1、基于DNS的负载平衡:

当通过在浏览器的地址栏中键入域名来访问某个网站时,浏览器会首先查找本地的DNS缓存是否拥有该域名对应的IP地址。

如果有,那么浏览器将尝试直接使用该IP地址访问网址的内容。

如果本地DNS缓存中没有该域名所对应的IP地址,那么它将向DNS发送一个请求,以获得该域名对应的IP并添加到本地DNS缓存中。

在DNS中,一个域名可能和多个IP地址绑定,这种情况下,DNS响应将会按照Round Robin(轮询)方式返回这些IP地址的列表。

2、L3/4负载平衡,即基于网络层的负载平衡:

指的是负载平衡服务器会根据OSI模型中的第三层网络层和第四层传输层所包含的数据来进行负载平衡操作。

在这种负载平衡服务器中,这些数据主要包含数据包的IP头和TCP、UDP等协议的协议头。

工作原理:在数据到达时,负载平衡服务器将根据自身算法以及OSI模型三四层所包含的数据决定需要处理该数据的服务实例并将其转发。

运行包含三方面内容:

(1)负载平衡服务器需要知道当前有效的服务实例有哪些;

负载平衡服务器需要周期性的发送状态查询请求以探测到底哪些服务实例正在有效的工作。

如果服务实例崩溃但是承载它的OS正常工作,那么该OS仍会响应负载平衡服务器所发出的Ping命令,只是TCP连接会失败;

如果服务实例没有崩溃只是挂起,仍可以接受TCP连接,只是无法收到HTTP请求。

一旦负载平衡服务器发现其所管理的某个服务实例不再有效,那么它就不会再将任何数据转发给该服务实例,直至该服务实例回归正常状态。

(2)根据自身分派算法来决定需要处理数据的服务实例;

Round Robin是最常用也是表现最好的负载平衡算法。

如果各个服务实例的容量不同,那么负载均衡服务器会使用Weighted Round Robin算法,即根据各个服务实例的实际能力来按比例分配负载。

如果单纯使用Round Robin算法,那么具有关联关系的各个请求可能被分配到不同的服务实例上。因此很多负载平衡服务器允许根据数据的特定特征对这些负载进行分配,如使用一种哈希算法对用户所在的IP进行计算,并根据计算结果决定需要分配到的服务实例。

如果某个服务器失效,那么哈希算法中的哈希值空间将会发生变化,进而导致原本的的服务实例分配结果将不再有效。这种情况下,所有请求将重新分配服务器实例。

(3)根据分派算法的计算结果将数据发送到目标服务实例上。

三种转发方式:

A、Direct Routing:负载平衡服务器和各服务实例必须在同一个网段上并使用同一个IP。

在收到数据后,将直接对这些数据包进行转发。

各服务实例在在处理完数据包之后可以将相应返回给负载平衡服务器,也可以选择将响应直接发送给用户,而不需要再经过负载平衡服务器。

在该过程,负载平衡服务器和各个服务实例都不需要对IP层数据进行任何更改就可以对其进行转发。这种转发方式的吞吐量非常高。

B、Tunnelling:与A类似,唯一的不同是在负载平衡服务器和各个服务之间建立了一系列通道。

C、IP Address Translation:用户连接的目标地址是虚拟地址(VIP,Virtual IP)。

而负载平衡服务器在连接到请求时,将目标地址转化为服务实例所在的实际地址(RIP,real IP),并将原地址更改为Load Balancer所在的地址。

请求处理完毕后,服务实例将会把响应发送到负载平衡服务器,此时服务器再将响应的地址更改为VIP,并将该响应返回给用户。

3、L7负载平衡,即基于应用层的负载平衡:

主要通过OSI模型中的第七层应用层中的数据决定如何分发负载。

运行时,L7负载平衡服务器上的OS会将接收到的各个数据包组织成为用户请求,并根据在请求中多包含的数据决定由哪个服务实例来对该请求进行处理。




你可能感兴趣的:(阴差阳错的架构,架构模型)