《Squid3.0反向代理DNS轮询实现负载均衡》由会员分享，可在线阅读，更多相关《Squid3.0反向代理DNS轮询实现负载均衡（9页珍藏版）》请在金锄头文库上搜索。
1、wordSquid3.0反向代理+DNS轮询实现负载均衡系统拓朴图:一台 DNS 服务器：操作系统 Freebsd，软件 BIND 9.5，IP 192.168.76.222 ； 三台 Squid 服务器：操作系统 Linux AS 4，软件 Squid 3.0，相应的 IP 如下： Squid1：192.168.76.223 Squid2：192.168.76.224 Squid3：192.168.76.225 三台 WEB 服务器：操作系统 Linux AS 4，应用软件 Tomcat 5.0+Mysql，相应的 IP 地址如下： webServer1：210.82.118.195 web
2、Server2：192.168.76.226 webServer1：192.168.76.227 应用软件的安装和配置配置 DNS 服务器软件利用 Freebsd 自带的 bind 9.5 。然后针对该系统配置 bind，首先修改 bind 的配置文件 /etc/namedb/named.conf，在文件中添加zone cache.ibm. type master; file master/ cache.ibm. ; ; 再在 /etc/namedb/master 目录下添加 cache.ibm. 文件，该文件的内容如下：$TTL 3600 IN SOA search. ibm. root.
3、ibm. ( 20080807 ; Serial 3600 ; Refresh 900 ; Retry 3600000 ; Expire 3600 ) ; Minimum IN NS search.ibm. 1 IN PTR localhost.ibm. wenjin IN A 192.168.76.223 wenjin IN A 192.168.76.224 wenjin IN A 192.168.76.225 这样当用户请求的时候，DNS 通过轮询机制将 wenjin.cache.ibm. 的域名解析为 192.168.76.223、192.168.76.224 和 192.168.76.
4、225 其中之一。配置完成后，运行 rndc star t 启动 bind 服务。用 ps A |grep named 查看 bind 服务是否起来；用 nslookup wenjin.cache.ibm. 测试 bind 服务是否正常运行。配置 Squid1 服务器下载 squid-3.0.STABLE8.tar.gz 源码包，将其放在 /home 目录下 解压缩：tar zxvf squid-3.0.STABLE8.tar.gz 设置配置参数：cd squid-3.0.STABLE10 ./configure prefix=/usr/local/squid 将 squid 安装在 /usr
5、/local 目录下 编译安装：Makemake install安装完以后会在 /usr/local 目录下看见 squid 目录。 配置 squid 配置文件编辑 squid.conf 文件，cache_effective_user squid cache_effective_group squid # 设定 squid 的主机名 , 如无此项 squid 将无法启动visible_hostname squid1.nlc.gov. # 配置 squid 为加速模式 # _port 80 accel vhost vport icp_port 3130 # 配置 squid2、squid3 为其
6、邻居，当 squid1 在其缓存中没有找到请求的资源时，通过 ICP 查询去其邻居中取得缓存cache_peer squid2.ibm. sibling 80 3130 cache_peer squid3.ibm. sibling 80 3130 # squid1 的三个父节点，originserver 参数指明是源服务器，round-robin 参数指明 squid 通过轮询方式将请求分发到其中一台父节点；squid 同时会对这些父节点的健康状态进展检查，如果父节点 down 了，那么 squid 会从剩余的 origin 服务器中抓取数据cache_peer 210.82.118.195
7、parent 8080 0 no-query originserver round-robin name=webServer1cache_peer 192.168.76.226 parent 8080 0 no-query originserver round-robin name=webServer2 cache_peer 192.168.76.227 parent 8080 0 no-query originserver round-robin name=webServer3# 将 wenjin.cache.ibm. 域的请求通过 RR 轮询方式转发到三个父节点中的一个cache_peer
8、_domain webServer1 wenjin.cache.ibm.cache_peer_domain webServer2 wenjin.cache.ibm.cache_peer_domain webServer3 wenjin.cache.ibm.cache_peer_domain webServer1 webServer2 webServer3 wenjin.cache.ibm. (上面三行也可以写成一行)# 下面是一些访问控制、日志和缓存目录的设置acl localnet src 192.168.76.223 192.168.76.224 192.168.76.225 _acces
9、s allow all icp_access allow localnet cache_log /usr/local/squid/var/logs/cache.log access_log /usr/local/squid/var/logs/access.log squid cache_dir ufs /usr/local/squid/var/cache/ 1000 16 256 # 对 squid 的一些优化 # maximum_object_size 10240 KB # 能缓存的最大对象为 10M maximum_object_size_in_memory 512 KB # 内存中缓存的
10、最大对象 512K cache_mem 256 MB #squid 用于缓存的内存量 保存后 :wq 退出。在 /etc/hosts 文件中添加192.168.76.223 squid1.ibm. 192.168.76.224 squid2.ibm. 192.168.76.225 squid3.ibm. 保存后 : wq 退出。检查 squid 配置文件正确与否：/usr/local/squid/sbin/squid k parse/reconfigure (-k -help 可以查看)生成缓存目录：/usr/local/squid/sbin/squid z启动squid：/usr/local
11、/squid/sbin/squid -D配置 squid2 和 squid3 服务器squid2 和 squid3 服务器的配置方法和配置参数和 squid1 一样，配置完成后，分别启动这两个服务器上的 squid 服务。在 squid 的日志文件 cache.log 中，出现如下日志信息如此说明三台 squid 之间成功配置为 sibling，且配置了三个父代理。2008/11/17 10:08:47| Configuring Sibling squid1.ibm./80/3130 2008/11/17 10:08:47| Configuring Sibling squid3.ibm./80
12、/3130 2008/11/17 10:08:47| Ready to serve requests. 测试测试之前，保证 DNS 服务、三台 squid 服务和三台 web 服务都正常起来。在客户端输入wenjin.cache.ibm.，如此正确的显示该网页。服务器端的响应对客户端是透明的，客户端不知道请求是由哪台 WEB 服务器处理的；而且其中某台 Squid 服务器或 WEB 服务器发生故障，也不影响服务的正常运行。总结Squid 是一个开源的软件，利用它的反向代理技术可以提高系统的访问速度。本文在真实的网络环境下，利用三台 squid 反向代理服务器加速了的性能，同时结合 DNS 轮询
13、技术实现了的负载均衡。经过一段时间的测试和试运行，该的访问速度和可用性方面都有很大的提高，从未出现过服务中断情况。但DNS轮询具有明显的缺点：一旦某个服务器出现故障，即使与时修改了DNS设置，还是要等待足够的时间刷新时间才能发挥作用，在此期间，保存了故障服务器地址的客户计算机将不能正常访问服务器。缺点：第一，域名服务器是一个分布式系统，是按照一定的层次结构组织的。当用户将域名解析请求提交给本地的域名服务器，它会因不能直接解析而向上一级域名服务器提交，上一级域名服务器再依次向上提交，直到RR-DNS 域名服务器把这个域名解析到其中一台服务器的IP 地址。可见，从用户到RR-DNS 间存在多台域名
14、服务器，而它们都会缓冲已解析的名字到IP 地址的映射,这会导致该域名服务器组下所有用户都会访问同一Web 服务器，出现不同Web 服务器间的负载不平衡。为了保证在域名服务器中域名到IP 地址的映射不被长久缓冲，RR-DNS 在域名到IP 地址的映射上设置一个TTL(Time To Live)值，过了这一段时间，域名服务器将这个映射从缓冲中淘汰。当用户请求，它会再向上一级域名服务器提交请求并进展重新映射。这就涉与到如何设置这个TTL值，假如这个值太大，在这个TTL 期间，很多请求会被映射到同一台Web 服务器上，同样会导致负载不平衡。假如这个值太小，例如是，会导致本地域名服务器频繁地向RR-DNS提交请求，增加了域名解析的网络流量，同样会使RR-DNS 成为系统中一个新的瓶颈。第二，用户机器会缓冲从名字到IP 地址的映射，而不受TTL 值的影响，用户的访问请求会被送到同一台Web 服务器上。由于用户访问请求的突发性和访问方式不同，例如有的人访问一下就离开了，而有的人访问可长达几
