应用服务器集群的伸缩性设计

核心知识点:

1.应用集群负载均衡伸缩性设计

2.负载均衡的算法

应用服务器应该设计成无状态的,即应用服务器不存储请求上下文信息,如果将部署有相同应用的服务器组成一个集群,

每次用户请求都可以发送到集群中任意一台服务器上去处理,任何一台服务器的处理结果都是相同的。

这样只要能将用户请求按照某种规则分发到集群中的不同服务器上,就可以构成一个服务器集群,

每个用户的请求都可能落在不同的服务器上。

如果HTTP请求分发装置可以感知或者可以配置集群的服务器数量,可以及时发现集群中新上线或下线的服务器,

并能向新上线的服务器分发请求,停止向已下线的服务器分发请求,那么就实现了应用服务器集群的伸缩性。

这里,这个HTTP请求分发装置被称作负载均衡服务器。

负载均衡是网站必不可少的基础技术手段,不但可以实现网站的伸缩性,同时还可改善网站的可用性。

具体的技术实现也是多种多样的,从硬件实现到软件实现,从商业产品到开源软件,应有尽有,但是实现负载均衡的基础技术不外以下几种。

1.HTTP重定向负载均衡

利用HTTP重定向协议实现负载均衡。

HTTP重定向服务器是一台普通的应用服务器,其唯一的功能就是根据用户的HTTP请求计算一台真实的Web服务器地址,

并将该Web服务器地址写入HTTP重定向响应中(响应状态码302)返回给用户浏览器。

如图所示,(假设)浏览器请求域名www.baidu.com,DNS服务器解析得到IP地址是10.0.0.10,即HTTP重定向服务器的IP地址。

然后浏览器通过IP地址10.0.0.10访问HTTP重定向负载均衡服务器,服务器通过某种负载均衡算法计算获得一台实际物理服务器的地址(10.0.0.3),

构造一个包含该实际物理服务器地址的重定向响应返回给浏览器,浏览器自动重新请求实际物理服务器的IP地址10.0.0.3,完成访问。

这种负载均衡方案的优点是比较简单。缺点是浏览器需要两次请求服务器才能完成一次访问,性能较差

重定向服务器自身的处理能力可能成为瓶颈整个集群的伸缩性规模有限;

使用HTTP302响应码重定向,有可能使搜索引擎判断为SEO作弊,降低搜索排名。因此这种方式并不是很常见。

2.DNS域名解析负载均衡

这是利用DNS处理域名请求的同时进行负载均衡处理的一种方案,与之前介绍的HTTP重定向负载均衡有些类似。

在DNS服务器中配置多个A记录,如:wwww.baidu.com IN A 10.0.0.1、wwww.baidu.com IN A 10.0.0.2、wwww.baidu.com IN A 10.0.0.3.

每次域名解析请求都会根据负载均衡算法计算一个不同的IP地址返回,这样A记录中配置的多个服务器就构成一个集群,并可以实现负载均衡。

如图所示,浏览器请求解析域名www.baidu.com,DNS根据A记录和负载均衡算法计算得到一个IP地址10.0.0.3,并返回给浏览器;

浏览器根据IP地址,访问真实物理服务器10.0.0.3,完成访问。

DNS域名解析负载均衡的优点是将是将负载均衡的工作转交给DNS,省掉了网站管理负载均衡服务器的麻烦

同时许多DNS还支持基于地理位置的域名解析,即会将域名解析成距离用户地理最近的一个服务器地址,

这样可以加快用户的访问速度,改善性能。

但是DNS域名解析负载均衡也有缺点,就是目前的DNS是多级解析,每一级DNS都可能缓存A记录

当下线某台服务器后,即使修改了DNSA记录,要使其生效也需要较长时间,这段时间DNS依然会将域名解析到已经下线的服务器,

导致用户访问失败,而且DNS负载均衡的控制权在域名服务商那里,网站无法对其做更多改善和更强大的管理。

事实上,大型网站总是部分使用DNS域名解析,利用域名解析作为第一级负载均衡手段

即域名解析得到的一组服务器并不是实际提供Web服务的物理服务器,而是同样提供负载均衡服务的内部服务器,

这组内部负载均衡服务器再进行负载均衡,将请求分发到真实的Web服务器上。

3.反向代理负载均衡

利用反向代理服务器进行负载均衡。

前面我们提到利用反向代理缓存资源,以改善网站性能。

实际上,在部署位置上,反向代理服务器处于Web服务器前面(这样才可能缓存响应,加速访问),

这个位置也正好是负载均服务器的位置,所以大多是反向代理服务器也提供负载均衡的功能,

管理一组Web服务器,将请求根据负载均衡算转发到不同的服务器。

Web服务器处理完成的响应也需要通过反向代理服务器返回给用户。

由于Web服务器不直接对外提供访问,因此Web服务器不需要使用外部IP地址,

而反向代理服务器则需要配置双网卡和内外部两套IP地址。

如图所示,浏览器访问请求的地址是反向代理服务器的地址114.100.80.10,反向代理服务器收到请求后,

根据负载均衡算法得到一台真实物理服务器的地址为10.0.0.3,并将请求转发给服务器。

10.0.0.处理完请求后将响应返回给反向代理服务器,反向代理服务器再将该响应返回给用户。

由于反向代理服务器转发请求在HTTP协议层,因此也叫应用层负载均衡。

其优点是和反向代理服务器功能集成在一起部署简单,缺点是反向代理服务器是所有请求和响应的中转站,其性能可能会成为瓶颈

4.IP负载均衡

在网络层通过修改目标地址进行负载均衡。

用户请求数据包到达负载均衡服务器114.100.80.10后,负载均衡服务器在操作系统内核进程获取网络数据包,

根据负载均衡算法计算得到一台真实Web服务器10.0.0.1,然后将数据目的IP地址修改为10.0.0.1,不需要通过用户进程处理。

真实的Web服务器处理完后,响应数据包回到负载均衡服务器,负载均衡服务器再将数据包修改为自身的IP地址(114.100.80.10)发送给用户浏览器。

这里的关键在于真实物理Web服务器响应数据包如何返回给负载均衡服务器。

一种方案是负载均衡服务器在修改目的IP地址的同时修改源地址,将数据包源地址设为自身IP,

即源地址转换(SNAT),这样Web服务器响应在回到负载均衡服务器。

另一种方案是将负载均衡服务器同时作为真实物理服务器集群的网关服务器,这样所有的响应数据都会达到负载均衡服务器。

IP负载均衡在内核进程完成数据分发,相比于反向代理负载均衡(在应用程序中分发数据)有更好的处理性能

但是所有的请求都需要经过负载均衡服务器,集群的最大响应数据吞吐量不得不受制于负载均衡服务器网卡带宽

对于提供下载服务或者视频服务等需要传输大量数据的网站而言,难以满足需求。

5.数据链路层负载均衡

数据链路层负载均衡是指在数据链路层修改mac地址进行负载均衡。

这种传输方式又叫做三角传输模式,负载均衡数据分发过程中不修改IP地址,只修改目标mac地址,

通过配置真实物理服务器集群所有机器虚拟IP和负载均衡IP地址一致,

从而达到不修改数据包的源地址和目标地址就可以进行数据分发的目的,

由于实际物理请求的真实服务器IP和数据请求目的的IP一致,不需要通过负载均衡服务器进行地址转换,

可将响应数据包直接返回给用户浏览器,避免负载均衡服务器网卡带宽成为瓶颈。这种负载均衡方式又称作直接路由方式(DR)。

如图所示,用户请求达到负载均衡服务器114.100.80.10后,负载均衡服务器将请求数据的目标mac地址修改为00:0c:29:d2,

并不修改数据包目标IP地址,由于Web服务器集群所有服务器的虚拟IP地址和负载均衡IP地址相同,

因此数据可以正常到达mac地址00:0c:29:d2对应的服务器,该服务器处理完成后发送响应数据网站的网管服务器,

网关服务器直接将数据包发送给用户浏览器(通过互联网),响应数据不需要通过负载均衡服务器。

使用三角传输模式的链路层负载均衡是目前大型网站使用最广的一种负载均衡手段,

在Linux平台上最好的链路层负载均衡产品是LVS。

6.负载均衡的算法

负载均衡服务器的实现分成两个部分:

  • 根据负载均衡算法和Web服务器列表计算得到集群中一台Web服务器的地址。
  • 将请求数据发送到该地址对应的Web服务器上。

具体的负载均衡算法通常有以下几种:

(1)轮询(Round Robin,RR)

所有请求被依次分发到每台应用服务器上,即每台服务器需要处理的请求数目都相同,使用于所有服务器硬件都相同的场景。

(2)加权轮询(Weighted Round Robin,WRR)

根据应用服务器硬件性能的情况,在轮询的基础上,按照配置权重将请求分到每个服务器,高性能的服务器能分配更多的请求。

(3)随机(Random)

请求被随机分配到各个应用服务器,在许多场合下,这种方案都很简单实用,因为好的随机数本身就很均衡。

即使应用服务器硬件配置不同,也可以使用加权随机算法。

(4)最少连接(Least Connnections)

记录每个应用服务器正在处理的连接数(请求数),将新的请求分发到最少连接的服务器上,应该说这是最符合负载均衡定义的算法。

同样最少连接算法也可以实现加权最少连接。

(5)源地址散列(Source Hashing)

根据请求来源的IP地址进行Hash计算,得到应用服务器,这样来自同一个IP地址的请求总在同一台服务器上进行处理,

该请求的上下文信息可以存储在这台服务器上,在一个会话周期内重复使用,从而实现会话粘滞。

这种算法在很多时候非常有用,比如绑定Session的时候。

原文地址:https://www.cnblogs.com/yangmingxianshen/p/8449200.html

时间: 2024-10-31 19:08:29

应用服务器集群的伸缩性设计的相关文章

大型网站技术架构,6网站的伸缩性架构之分布式缓存集群的伸缩性设计

和所有服务器都部署相同应用的应用服务器集群不同,分布式缓存服务器集群中不同的服务器中缓存的数据各不相同,缓存访问请求不可以在缓存服务器集群中的任意一台处理,必须先找到缓存有需要数据的服务器,然后才能访问. 这个特点制约了分布式缓存集群的伸缩性设计,因为新上线的缓存服务器没有缓存任何数据,而已下线的缓存服务器还缓存这网站的许多热点数据. 必须让新上线的缓存服务器对整个分布式缓存集群影响最小,也就是说新加入的缓存服务器应使整个缓存服务器集群中已经缓存的数据尽可能还被访问到,这是分布式缓存集群伸缩性设

网站伸缩性架构--数据存储服务器集群的伸缩性设计

1.分布式缓存的伸缩性设计 1.1Memcached分布式缓存集群的访问模型 1.2分布式缓存的一致性Hash算法 2.数据库存储服务器集群的伸缩性设计 数据库存储服务器集群的伸缩性设计对数据的持久性和可用性提出了更高的要求.数据存储服务器必须保证数据的可靠存储,任何情况下都必须保证数据的可用性和正确性. 2.1关系数据库集群的伸缩性设计 除了数据库主从读写分离.不同业务数据表可以部署在不同的数据库集群上,俗称数据库分库.这种方式的限制条件是跨库的表不能Join操作. 2.2NoSQL数据库的伸

数据存储服务器集群的伸缩性设计——关系型数据库

和缓存服务器集群的伸缩性设计不同,数据存储服务器集群的伸缩性对数据的持久性和可用性提出了更高的要求. 缓存的目的是加速数据读取的速度并减轻数据存储服务器的负载压力, 因此部分缓存数据的丢失不影响业务的正常处理,因为数据还可以从数据库等存储服务器上获取. 而数据存储服务器必须保证数据的可靠存储,任何情况下都必须保证数据的可用性和正确性, 因此缓存服务器集群的伸缩性架构方案不能直接适用于数据库等存储服务器.存储服务器集群的伸缩性设计相对更复杂一些. 具体来说,又可分为关系型数据库集群的伸缩性设计和N

大型网站架构演进(4)使用应用服务器集群

原文:大型网站架构演进(4)使用应用服务器集群 使用应用服务器集群是解决高并发的常用手段,当一台应用服务器的处理能力不足时,不要企图更换配置更高的服务器,对于大型网站而言,不管多么强大的服务器,都满足不了持续增长的业务需求,在这种情况下,更好的做法是增加一台应用服务器去分担原来服务器的压力.因为这样使得系统的可扩展和可伸缩性更好. 使用应用服务器集群 架构如下图: 总结: 使用应用服务器集群后,应用服务器这一层的高并发问题就解决了,但是高并发的压力就转移到数据库了,所以后面要继续优化架构去解决数

分布式(集群)文件系统的设计

 本文讲的分布式文件系统,是通过集群来实现的,因此也是集群文件系统.本文介绍下分布式文件系统中的常见问题及GFS中给出的解决方法. 设计要点: 性能 提高性能的方法就是并行,讲一个任务分解成多个任务,同一时候运行. GFS中的思路是将文件分块,每一个块是一个chunk,每一个chunk单独保存,保存chunk的节点叫chunkserver.对文件的读写,能够转成对chunk的读写,不同的chunk能够并行运行,提高效率.每一个chunk有唯一的一个chunk handle表示,chunk的大

【Liinux运维】企业集群平台架构设计与实现

LVS: LVS是Linux Virtual Server的简写,意即Linux虚拟服务器,是一个虚拟的服务器集群系统.本项目在1998年5月由章文嵩博士成立,是中国国内最早出现的自由软件项目之一. haproxy: HAProxy是一个使用C语言编写的自由及开放源代码软件[1],其提供高可用性.负载均衡,以及基于TCP和HTTP的应用程序代理. HAProxy特别适用于那些负载特大的web站点,这些站点通常又需要会话保持或七层处理.HAProxy运行在当前的硬件上,完全可以支持数以万计的并发连

【摘自大型网站技术架构书】应用服务器集群的session管理

由于负载均衡服务器可能会将请求分发到集群任何一台服务器上,所以保证每次请求能够获得正确的session比单机时复杂. 集群环境下,session管理的主要几种手段 1.session复制 session复制是早期的企业级的使用比较多的一种服务器集群session管理机制.应用服务器开启web容器的session复制功能,在集群中的几台服务器之间同步session对象,使得每台服务器上都保存所有的session信息,这样任何一台宕机都不会导致session的数据丢失,服务器使用session时,直

应用服务器集群的session管理

1.什么是session a.web应用中将这些多次请求修改使用的上下文对象称作会话(session) b.Session 对象存储特定用户会话所需的信息.这样,当用户在应用程序的 Web 页之间跳转时,存储在 Session 对象中的变量将不会丢失,而是在整个用户会话中一直存在下去. c.当用户请求来自应用程序的 Web 页时,如果该用户还没有会话,则 Web 服务器将自动创建一个 Session 对象.当会话过期或被放弃后,服务器将终止该会话 2.session的应用场景 在高可用的架构中,

解决应用服务器集群后session问题

一. 何为session 用户使用网站的服务,基本上需要浏览器和web服务器进行多次交互,web服务器如何知道哪些请求是来自哪个会话的? 具体方式为:在会话开始时,分配一个唯一的会话标识(sessionId),通过cookie把这个标识告诉浏览器,以后每次请求的时候,浏览器都会带上这个会话标识来告诉web服务器请求是属于哪个会话的.如果遇到禁用cookie的情况,一般的做法就是把这个会话标识放到url的参数中.