负载均衡软件实现与硬件实现方案.docVIP

该文档是word2003—word2007兼容版

软件、硬件负载均衡部署方案

目录

TOC\o1-3\h\z\u1、硬件负载均衡之F5部署方案 2

网络拓扑结构 2

反向代理部署方式 3

2软件负载均衡方案 5

负载均衡软件实现方式之一-URL重定向方式 5

负载均衡软件实现方式之二-基于DNS 6

负载均衡软件实现方式之三-LVS 8

负载均衡软件实现方式之四-专业负载均衡软件 16

总结： 17

1、硬件负载均衡之F5部署方案

对于所有的对外效劳的效劳器，均可以在BIG-IP上配置VirtualServer实现负载均衡，同时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将流量导向到相应的效劳器。

网络拓扑结构

网络拓扑结构如下图：

网络拓扑结构

下列图为集群效劳器的硬件负载均衡详细架构图，由一台F5虚拟机分别对多台效劳器进行负载分配。

①如图，假设域名oiinfo被解析到F5的外网/公网虚拟IP：〔vs_squid〕，该虚拟IP下有一个效劳器池〔pool_squid〕，该效劳器池下包含两台真实的Squid效劳器〔1和2〕。

②、如果Squid缓存未命中，那么会请求F5的内网虚拟IP：〔vs_apache〕，该虚拟IP下有一个默认效劳器池〔pool_apache_default〕，该效劳器池下包含两台真实的Apache效劳器〔1和2〕，当该虚拟IP匹配iRules规那么时，那么会访问另外一个效劳器池〔pool_apache_irules〕，该效劳器池下同样包含两台真实的Apache效劳器〔3和4〕。

③、另外，所有真实效劳器的默认网关指向F5的自身内网IP，即。

④、所有的真实效劳器通过SNATIP地址访问互联网。

2软件负载均衡方案

负载均衡软件实现方式之一-URL重定向方式

有一种用软件实现负载均衡的方式,是基于URL重定向的.

先看看什么是URL重定向:

简单的说，如果一个网站有正规的URL和别名URL，对别名URL进行重定向到正规URL，访问同一个网址，或者网站改换成了新的域名那么把旧的域名重定向到新的域名，都叫URL重定向

(://xdidc/service/host_faq.php)

很多网络协议都支持“重定向”功能，例如在协议中支持Location指令，接收到这个指令的浏览器将自动重定向到Location指明的另一个URL上。

(://sysapp.xdidc/art/200604/25388.htm)

这种方式,对于简单的网站,如果网站是自己开发的,也在一定程度上可行.但是它存在着较多的问题:

1、“例如一台效劳器如何能保证它重定向过的效劳器是比拟空闲的，并且不会再次发送Location指令，Location指令和浏览器都没有这方面的支持能力，这样很容易在浏览器上形成一种死循环。”

2、在哪里放LOCATION，也是一个问题。很有可能用户会访问系统的很多个不同URL，这个时候做起来会非常麻烦。并且，对URL的访问，有的时候是直接过来的，可以被重定向，有的时候是带着SESSION之类的，重定向就可能会出问题。并且，这种做法，将负载均衡这个系统级的问题放到了应用层，结果可能是麻烦多多。

3、这种方式一般只适用于方式，但是实际上有太多情况不仅仅是方式了，特别是用户如果在应用里面插一点流媒体之类的。

4、重定向的方式，效率远低于IP隧道。

5、这种方式，有的时候会伴以对效劳器状态的检测，但往往也是在应用层面实现，从而实时性大打折扣