负载均衡软件实现与硬件实现方案
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
该文档是word2003—word2007兼容版
软件、硬件负载均衡部署方案
目录
1、硬件负载均衡之F5部署方案 (2)
1.1网络拓扑结构 (2)
1.2反向代理部署方式 (3)
2软件负载均衡方案 (4)
2.1负载均衡软件实现方式之一- URL重定向方式 (4)
2.2负载均衡软件实现方式之二- 基于DNS (5)
2.3负载均衡软件实现方式之三- LVS (8)
2.4负载均衡软件实现方式之四- 专业负载均衡软件 (16)
总结: (16)
1、硬件负载均衡之F5部署方案
对于所有的对外服务的服务器,均可以在BIG-IP上配置Virtual Server实现负载均衡,同时BIG-IP可持续检查服务器的健康状态,一旦发现故障服务器,则将其从负载均衡组中摘除。
BIG-IP利用虚拟IP地址(VIP由IP地址和TCP/UDP应用的端口组成,它是一个地址)来为用户的一个或多个目标服务器(称为节点:目标服务器的IP地址和TCP/UDP应用的端口组成,它可以是internet的私网地址)提供服务。因此,它能够为大量的基于TCP/IP的网络应用提供服务器负载均衡服务。根据服务类型不同分别定义服务器群组,可以根据不同服务端口将流量导向到相应的服务器。BIG-IP连续地对目标服务器进行L4到L7合理性检查,当用户通过VIP请求目标服务器服务时,BIG-IP根椐目标服务器之间性能和网络健康情况,选择性能最佳的服务器响应用户的请求。如果能够充分利用所有的服务器资源,将所有流量均衡的分配到各个服务器,我们就可以有效地避免“不平衡”现象的发生。
利用UIE+iRules可以将TCP/UDP数据包打开,并搜索其中的特征数据,之后根据搜索到的特征数据作相应的规则处理。因此可以根据用户访问内容的不同将流量导向到相应的服务器,例如:根据用户访问请求的URL将流量导向到相应的服务器。
1.1网络拓扑结构
网络拓扑结构如图所示:
网络拓扑结构
1.2反向代理部署方式
下图为集群服务器的硬件负载均衡详细架构图,由一台F5虚拟机分别对多台服务器进行负载分配。
①如图,假设域名被解析到F5的外网/公网虚拟IP:61.1.1.3(vs_squid),该虚拟IP下有一个服务器池(pool_squid),该服务器池下包含两台真实的Squid服务器(192.168.1.11和192.168.1.12)。
②、如果Squid缓存未命中,则会请求F5的内网虚拟IP:192.168.1.3(vs_apache),该虚拟IP下有一个默认服务器池(pool_apache_default),该服务器池下包含两台真实的Apache服务器(192.168.1.21和192.168.1.22),当该虚拟IP匹配iRules规则时,则会访问另外一个服务器池(pool_apache_irules),该服务器池下同样包含两台真实的Apache服务器(192.168.1.23和192.168.1.24)。
③、另外,所有真实服务器的默认网关指向F5的自身内网IP,即192.168.1.2。
④、所有的真实服务器通过SNAT IP地址61.1.1.4访问互联网。
2软件负载均衡方案
2.1负载均衡软件实现方式之一- URL重定向方式
有一种用软件实现负载均衡的方式,是基于"URL重定向"的.
先看看什么是URL重定向:
"简单的说,如果一个网站有正规的URL和别名URL,对别名URL进行重定向到正规URL,访问同一个网址,或者网站改换成了新的域名则把旧的域名重定向到新的域名,都叫URL重定向"
(/service/host_faq.php)
"很多网络协议都支持“重定向”功能,例如在HTTP协议中支持Location 指令,接收到这个指令的浏览器将自动重定向到Location指明的另一个URL上。"
(/art/200604/25388.htm)
这种方式,对于简单的网站,如果网站是自己开发的,也在一定程度上可行.但是它存在着较多的问题:
1、“例如一台服务器如何能保证它重定向过的服务器是比较空闲的,并且不会再次发送Location指令,Location指令和浏览器都没有这方面的支持能力,这样很容易在浏览器上形成一种死循环。”
2、在哪里放LOCATION,也是一个问题。很有可能用户会访问系统的很多个不同URL,这个时候做起来会非常麻烦。并且,对URL的访问,有的时候是直接过来的,可以被重定向,有的时候是带着SESSION之类的,重定向就可能会出问题。并且,这种做法,将负载均衡这个系统级的问题放到了应用层,结果可能是麻烦多多。
3、这种方式一般只适用于HTTP方式,但是实际上有太多情况不仅仅是HTTP 方式了,特别是用户如果在应用里面插一点流媒体之类的。
4、重定向的方式,效率远低于IP隧道。
5、这种方式,有的时候会伴以对服务器状态的检测,但往往也是在应用层面实现,从而实时性大打折扣。
实际上,这种方式是一种“对付”的解决方法,并不能真正用于企业级的负载均衡应用(这里企业级是指稍微复杂一点的应用系统)可以看一下专业的负载均衡软件是如何来实现的:/pcl/pcl_sis_theory.htm 对比一下可以发现,专业的负载均衡软件要更适用于正规应用,而重定向方式则比较适用于一些简单的网站应用。
2.2负载均衡软件实现方式之二- 基于DNS
负载均衡集群网络拓扑图
讲到负载均衡,几乎所有地方都必须要讲一下基于DNS的方式,因为这实在是最基本、最简单的方式了。当然,也几乎所有地方都说到这种方式的种种缺点,不过,既然很基本,就还是要说明一下。
下面这段讲得很清楚:
最早的负载均衡技术是通过DNS来实现的,在DNS中为多个地址配置同一个名字,因而查询这个名字的客户机将得到其中一个地址,从而使得不同的客户访问不同的服务器,达到负载均衡的目的。
DNS负载均衡是一种简单而有效的方法,但是它不能区分服务器的差异,也不能反映服务器的当前运行状态。当使用DNS负载均衡的时候,必须尽量保证不同的客户计算机能均匀获得不同的地址。由于DNS数据具备刷新时间标志,一