提高服务器响应能力的方法
scale on 在原有服务器的基础上进行升级或者直接换一台新的性能更高的服务器。
scale out 横向扩展，将多台服务器并发向外响应客户端的请求。优点：成本低，扩展架构比较简单。
集群（Cluster），通俗地讲就是按照某种组织方式将几台电脑组织起来完成某种特定任务的这样一种架构。
三种集群类型：
LB，Load Balancing 负载均衡：在一定程度上能够实现高可用的目的。
HA，High Availability 高可用：实时在线，能够及时响应客户端请求，企业应用要求达到
7*24小时，99.999%时间在线。
HP，High Performance 高性能提供大量超级运算能力的集群。
LB 负载均衡架构：
Director（dispatcher）：负责接收客户端请求，并将请求按照某种算法分发到后台真正提供服务的服务器上。既可以基于硬件（F5）来实现，也可以基于软件来实现。基于软件实现的又分为四层交换：基于IP地址和端口号组合起来对服务做重定向（LVS）。七层交换：通常指的是反向代理（proxy），例如：squid。
LVS：Linux Virtual Server
类似于iptables的架构，在内核中有一段代码用于实时监听数据包来源的请求，当数据包到达端口时做一次重定向。这一系列的工作必须在内核中实现。在内核中实现数据包请求处理的代码叫做ipvs。ipvs仅仅提供了功能框架，还需要自己手动定义是数据对哪个服务的请求，
而这种定义需要通过写规则来实现，写规则的工具就称为ipvsadm。
应用场景
高吞吐量（higher throughput）
冗余（redundancy）
适应性（adaptability）
LVS负载均衡架构
Virtual IP（VIP）address：Director用来向客户端提供服务的IP地址
Real IP （RIP） address：集群节点（后台真正提供服务的服务器）所使用的IP地址
Director's IP (DIP) address：Director用来和D/RIP 进行联系的地址
Client computer's IP (CIP) address：公网IP，客户端使用的IP。
根据前端Director和后台Real Server的通信方式将LVS分为三类：
Network Address Translation（LVS-NAT）
目标地址转换所有客户端的请求都被Director根据访问请求和算法被定向到后台的Real Server 上。数据包地址转换过程：
S:CIP D:VIP------->Director------>S:CIP D:RIP------>Real Server------>
----->S:RIP D:CIP----->Director----->S:VIP D:CIP Director和Real Server必须在同一个网段中；
一般情况下，RIP是私有地址，只用于集群内部节点间通信；
Director 会响应所有的请求在客户端和Real Server之间，所承担的负载较大；
所有的Real IP 网关必须指向DIP以响应客户端请求；
Director可以重映射网络端口，即前端使用标准端口，后端可以使用非标准端口；
后台的Real Server可以使用任何操作系统；
Director可能会成为系统瓶颈。
Director routing （LVS-DR ）
直接路由客户端请求经过Director，Real Server直接回应客户端
数据包地址转换过程：
S:CIP D:VIP----->Director--->S:CIP D:RIP -----> Real Server---> S:VIP D:CIP
Real Server 上必须配置VIP切需要隐藏起来，只有在响应客户端请求时才使用VIP作为源地址，除此之外并不使用此VIP。
集群节点和Director必须在同一个网络中；
RIP不要求为私有地址；
Director仅处理所有进来的请求；
Real Server 不能以DIP作为网关，而是以公网上的某台路由器作为网关；
Director 不能再使用端口重映射；
大多数操作系统可以被用来作为Real Server，windows除外；
LVS-DR模式可以处理比LVS-NAT更多的请求。
实际生产环境中最常用的一种方式，优点:
RIP 为公网地址，管理员可以远程连接Real Server来查看工作状态；
一旦Director 宕机，可以通过修改DNS记录将A记录指向RIP 继续向外提供服务；
IP tunneling (LVS-TUN )
与DR的网络结构一样，但Director和Real Server可以在不同的网络当中，可以实现异地容灾的功能。DIP----->VIP 基于隧道来传输，在数据包外层额外封装了S:DIP D :RIP 的地址。
Director和Real Server 必须在同一个物理网络中；
RIP一定不能是私有地址；
Director只负责处理进来的数据包；
Real Server直接将数据包返回给客户端，所以Real Server默认网关不能是DIP，必须是公网上某个路由器的地址；Director不能做端口重映射；
只有支持隧道协议的操作系统才能作为Real Server。
分发时所采用的算法
固定调度算法：按照某种既定的算法，不考虑实时的连接数予以分配。
Round-robin（RR）轮询：当新请求到达时候，从服务列表中选择一个Real Server，将请求重定向给这台Real Server。Weighted round-robin（WRR）加权轮询：给每台Real Server分配一个权重/位列，权重越大，分到的请求数越多。Destination hashing （DH）目标散列：来自于同一个IP地址的请求都被重定向到同一台Real Server上（保证目标地址不变）。
Source hashing（SH）源地址散列：Director必须确保响应的数据包必须通过请求数据包所经过的路由器或者防火墙（保证原地址不变）。
动态调度算法：通过检查服务器上当前连接的活动状态来重新决定下一步调度方式该如何实现。
Lease Connection （LC）最少连接哪一个Real Server上的连接数少就将下一个连接请求定向到那台Real Server 上去。【算法：连接数=活动连接数*256+非活动连接数】
Weight Least-Connection（WLC）加权最少连接在最少连接的基础上给每台Real Server分配一个权重。【算法：连接数=（活动连接数*256+非活动连接数）÷权重】一种比较理想的算法。
Shortest Expected Delay (SED) 最短期望延迟不再考虑非活动连接数
【算法：连接数=(活动连接数+1) *256 ÷权重】
Never Queue (NQ) 永不排队算法，对SED的改进，当新请求过来的时候不仅要取决于SED算法所得到的值，还要取决于Real Server上是否有活动连接。
Locality-Based Least-Connection (LBLC) 基于本地状态的最少连接，在DH算法的基础上还要考虑服务器上的活动连接数。
Locality-Based Least-Connection with Replication Scheduling (LBLCR) 带复制的基于本地的最少连接 LBLC 算法的改进
下面我们就来做一个基于LVS-NAT的负载均衡实验：
实验环境搭建：
Director ：VIP192.168.0.127 桥接
DIP192.168.10.1 仅主机
Real Server 1：RIP 192.168.10.2 仅主机网关指向：192.168.10.1
Real Server 2：RIP 192.168.10.3 仅主机网关指向：192.168.10.1
Client：192.168.0.1 物理机
每台Real Server上分别安装有http服务。我们这里为了演示效果，每个http服务的页面不同。Real Server 1
[root@station39 html]# ifconfig eth0 192.168.10.2
[root@station39 html]# route add default gw 192.168.10.1
Real Server 2
[root@station26 html]# ifconfig eth0 192.168.10.3
[root@station26 html]# route add default gw 192.168.10.1
Director ：
[root@server27 ~]# ifconfig eth1 192.168.10.1
打开内核路由功能
[root@server27 ~]# echo 1 > /proc/sys/net/ipv4/ip_forward
确保永久有效：
[root@server27 ~]# vim /etc/sysctl.conf
# Controls IP packet forwarding
net.ipv4.ip_forward = 1
[root@server27 ~]# sysctl -p
net.ipv4.ip_forward = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
kernel.sysrq = 0
kernel.core_uses_pid = 1
net.ipv4.tcp_syncookies = 1
kernel.msgmnb = 65536
kernel.msgmax = 65536
kernel.shmmax = 4294967295
kernel.shmall = 268435456
OK，准备工作已经就绪，下面开始实验的关键步骤：
[root@server27 ~]# yum install ipvsadm -y
使用步骤：1.定义服务 2 .为服务定义Real Server
[root@server27 ~]# ipvsadm -A -t 192.168.0.127:80 -s rr
[root@server27 ~]# ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.0.127:80 rr
[root@server27 ~]# ipvsadm -a -t 192.168.0.127:80 -r 192.168.10.2 -m -w 2
[root@server27 ~]# ipvsadm -a -t 192.168.0.127:80 -r 192.168.10.3 -m -w 5
-g, --gatewaying Use gatewaying (direct routing). This is the default.
-i, --ipip Use ipip encapsulation (tunneling).
-m, --masquerading Use masquerading (network access transla-tion, or NAT).
PS：在这里设定的权重对于RR算法来说并没有什么意义，我们只是为后面的实验而设定的。[root@server27 ~]# ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.0.127:80 rr
-> 192.168.10.3:80 Masq 5 0 16
-> 192.168.10.2:80 Masq 2 0 15
此时，我们使用物理机访问192.168.0.127就会发现页面交替变化，这是由RR算法的特性决定的。我们改变为WRR算法试试：
[root@server27 ~]# ipvsadm -E -t 192.168.0.127:80 -s wrr
[root@server27 ~]# ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.0.127:80 wrr
-> 192.168.10.3:80 Masq 5 0 86
-> 192.168.10.2:80 Masq 2 0 43
改变为LBLC算法试试：
LBLC：基于本地状态的最少连接，在DH算法的基础上还要考虑服务器上的活动连接数。
[root@server27 ~]# ipvsadm -E -t 192.168.0.127:80 -s lblc
[root@server27 ~]# ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.0.127:80 lblc
-> 192.168.10.3:80 Masq 5 0 112
-> 192.168.10.2:80 Masq 2 0 41
此时无论客户端怎么刷新，访问页面都不会改变。
保存规则：
ipvsadm -S >>/etc/sysconfig/ipvs-config == ipvsadm-save
ipvsadm -R < /etc/sysconfig/ipvs-config == ipvsadm-restore
Director routing （LVS-DR ）
PS:Director分发到Real Server的过程中，数据包的源地址和目标地址都没有发生改变，Director仅仅是将目标mac 地址转换成某台Real Server的mac地址，源mac地址改为Director内网网卡的mac地址。
两个技术难题
1 Real Server要避免对客户端发来的对VIP的arp地址解析请求；
解决方法
1) 修改内核的两个参数：arp_announce, arp_ignore。
arp_announce ：定义不同级别：当ARP请求通过某个端口进来是否利用这个接口来回应。
0 - (default) Use any local address, configured on any interface.
利用本地的任何地址，不管配置在哪个接口上去响应ARP请求；
1 - Try to avoid local addresses that are not in the target's subnet for this interface.
避免使用另外一个接口上的mac地址去响应ARP请求；
2 - Always use the best local address for this target.
尽可能使用能够匹配到ARP请求的最佳地址。
arp_ignore：当ARP请求发过来后发现自己正是请求的地址是否响应；
0 - (default): reply for any local target IP address, configured on any interface
利用本地的任何地址，不管配置在哪个接口上去响应ARP请求；
1 - reply only if the target IP address is local address configured on the incoming
interface.
哪个接口上接受ARP请求，就从哪个端口上回应。
PS：对linux来说IP地址属于系统而不属于某个接口。
2) Red Hat 提供了arptables工具，利用arp防火墙也可以实现。
2 当Real Server内网网卡响应客户端请求时，要以VIP作为源地址，不能以RIP作为源地址。
解决方法
添加一条路由：route add -host 192.168.0.127 dev lo:0使客户端访问VIP，就让VIP来响应客户端。这样避免了使用RIP作为源地址。
Director：VIP：响应客户端请求；
DIP：与RIP彼此间实现arp解析，并将客户端的请求转发给Real Server。
实验环境搭建：
Director ：eth0:0 VIP192.168.0.127
eth0 DIP192.168.0.10 桥接
Real Server 1： eth0 RIP 192.168.0.12 桥接
lo:0 VIP 192.168.0.127
Real Server 2： eth0 RIP 192.168.0.13 桥接
lo:0 VIP 192.168.0.127
Client：192.168.0.1 物理机
Real Server 1
[root@station39 ~]# vim /etc/sysctl.conf
net.ipv4.conf.lo.arp_ignore = 1
net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.lo.arp_announce = 2
net.ipv4.conf.all.arp_announce = 2
[root@station39 ~]# sysctl -p
[root@station39 ~]# ifconfig eth0 192.168.0.12/24
[root@station39 ~]# ifconfig lo:0 192.168.0.127 broadcast 192.168.0.127 netmask 255.255.255.255 [root@station39 ~]# route add -host 192.168.0.127 dev lo:0
Real Server 2
[root@station26 ~]# vim /etc/sysctl.conf
net.ipv4.conf.lo.arp_ignore = 1
net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.lo.arp_announce = 2
net.ipv4.conf.all.arp_announce = 2
[root@station26 ~]# sysctl -p
[root@station26 ~]# ifconfig eth0 192.168.0.13/24
[root@station26 ~]# ifconfig lo:0 192.168.0.127 broadcast 192.168.0.127 netmask 255.255.255.255
[root@station26 ~]# route add -host 192.168.0.127 dev lo:0
Director
[root@server27 ~]# ifconfig eth0 192.168.0.10/24
[root@server27 ~]# ifconfig eth0:0 192.168.0.127 broadcast 192.168.0.127 netmask 255.255.255.255
[root@server27 ~]# route add -host 192.168.0.127 dev eth0:0
[root@server27 ~]# echo 1 > /proc/sys/net/ipv4/ip_forward
[root@server27 ~]# ipvsadm -C
[root@server27 ~]# ipvsadm -A -t 192.168.0.127:80 -s wlc
[root@server27 ~]# ipvsadm -a -t 192.168.0.127:80 -r 192.168.0.12 -g -w 5
[root@server27 ~]# ipvsadm -a -t 192.168.0.127:80 -r 192.168.0.13 -g -w 8
[root@server27 ~]# ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.0.127:80 wlc
-> 192.168.0.13:80 Route 8 0 18
-> 192.168.0.12:80 Route 5 0 11
PS：如果要保持访问的页面一致，我们可以另外准备一台服务器专门用来存放网页文件，然后通过NFS共享的方式挂载到Real Server的网页目录下，就可以实现真正的负载均衡了。
实现持久连接：
[root@server27 ~]# ipvsadm -E -t 192.168.0.127:80 -s wlc -p 3600
[root@server27 ~]# ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.0.127:80 wlc persistent 3600
-> 192.168.0.13:80 Route 8 0 62
-> 192.168.0.12:80 Route 5 0 0
此时，你会发现无论访问页面怎么刷新都不会再改变，这就是LVS持久性。
LVS Persistence 持久性
尽管我们选择了LVS的分发方法，但是大多时候我们要保证返回给客户端的所有响应请求必须来自于同一台Real Server，这里我们就要用到LVS Persistence（持久性）。
当使用SSL会话的时候，我们常常期望只交换一次密钥就可以建立永久连接，因此，LVS持久性在SSL会话中经常被用到。
当使用LVS持久性的时候，Director在内部使用一个连接根据记录称之为“持久连接模板”来确保所有来自同一个客户端的请求被分发到同一台Real Server上。
LVS 持久性类型：PCC PPC PNMP 混合类型。
Persistent client connections (PCC), cause all services a client is accessing to persist. (Also called zero port connections.)
来自同一客户端所有服务的请求都被重定向到同一台Real Server上，以IP地址为准。
PCC是一个虚拟服务没有端口号（或者端口号为0），以"-p" 来标识服务。
缺陷：定向所有服务，期望访问不同的Real Server无法实现。
假设一个用户在访问购物网站时同时使用HTTP（80）和HTTPS（443）两种协议，就需要这样定义：
ipvsadm -A -t 192.168.0.220:0 -s rr -p
ipvsadm -a -t 192.168.0.220.3:0 -r 192.168.10.11 -m
ipvsadm -a -t 192.168.0.220:0 -r 192.168.10.11 -m
Persistent port connections (PPC), which cause a single service to persist.
来自同一服务的请求都被重定向到同一台Real Server上，以端口号为准。
例如：client---->LVS(80,22)------>RS1 client----->LVS(23)----->RS2
缺陷：期望访问不同的端口到同一台RS上，无法实现。
Persistent Netfilter Marked Packet persistence, which causes packets that have been marked with the iptables utility to persist.
根据iptables 的规则，将对于某类服务/几个不同端口的访问定义为一类。
先对某一特定类型的数据包打上标记，然后再将基于某一类标记的服务送到后台的Real Server上去，后台的Real Server 并不识别这些标记。
PS：在LVS-NAT的环境下做这个实验，由于前边的DR模型使用了网卡别名，所以并不适合这个实验。
[root@server27 ~]# iptables -t mangle -A PREROUTING -i eth0 -d 192.168.0.127 -p tcp --dport 80 -j MARK --set-mark 2
[root@server27 ~]# ipvsadm -A -f 2 -s wlc -p 3600
[root@server27 ~]# ipvsadm -a -f 2 -r 192.168.10.2 -m -w 2
[root@server27 ~]# ipvsadm -a -f 2 -r 192.168.10.3 -m -w 5
将持久和防火墙标记结合起来就能够实现端口姻亲功能，只要是来自某一客户端的对某一特定服务（需要不同的端口）的访问都定义到同一台Real Server上去。
假设这样一种场景：一个用户在访问购物网站时同时使用HTTP（80）和HTTPS（443）两种协议，我们需要将其定义到同一台Real Server上，而其他的服务不受限制，我们可以这样做：
实验基于LVS-NAT的环境。
先做一个自签名的证书
Real Server 1：
[root@station39 ~]# cd /etc/pki/tls/certs/
[root@station39 ~]# cd /etc/pki/tls/certs/
[root@station39 certs]# make httpd.pem
[root@station39 certs]# mv httpd.pem /etc/httpd/
[root@station39 httpd]# yum install mod_ssl -y
[root@station39 httpd]# cd conf.d/
[root@station39 conf.d]# vim ssl.conf
SSLCertificateFile /etc/httpd/httpd.pem //** line 112
SSLCertificateKeyFile /etc/httpd/httpd.pem //** line 119
重启httpd 服务。
[root@station39 ~]# vim /etc/hosts
192.168.10.2 https://www.doczj.com/doc/9912553846.html, web1
Real Server 2 ：
[root@station26 ~]# yum install mod_ssl -y
[root@station26 certs]# cd /etc/httpd
[root@station26 httpd]# make -C /etc/pki/tls/certs httpd.pem
[root@station26 httpd]# mv /etc/pki/tls/certs/httpd.pem ./
[root@station26 httpd]# cd conf.d/
[root@station26 conf.d]# vim ssl.conf
SSLCertificateFile /etc/httpd/httpd.pem //** line 112
SSLCertificateKeyFile /etc/httpd/httpd.pem //** line 119
重启httpd 服务。
[root@station26 ~]# vim /etc/hosts
192.168.10.3 https://www.doczj.com/doc/9912553846.html, web2
Director：
[root@server27 ~]# iptables -t mangle -A PREROUTING -i eth0 -d 192.168.0.127 -p tcp --dport 80 -j MARK --set-mark 5
[root@server27 ~]# iptables -t mangle -A PREROUTING -i eth0 -d 192.168.0.127 -p tcp --dport 443 -j MARK --set-mark 5
[root@server27 ~]# ipvsadm -A -f 5 -s wlc -p
[root@server27 ~]# ipvsadm -a -f 5 -r 192.168.10.2 -m -w 2
[root@server27 ~]# ipvsadm -a -f 5 -r 192.168.10.3 -m -w 5
OK，修改windows客户端的C:\WINDOWS\system32\drivers\etc\hosts 文件，添加两条名称解析记录：
192.168.0.127 https://www.doczj.com/doc/9912553846.html,
192.168.0.127 https://www.doczj.com/doc/9912553846.html,
此时物理机访问192.168.0.127无论是http还是https 服务都会被定义到同一台Real Server上去。
这里我们是为了演示实验的效果，使用的不同的证书，不同的页面。真实的生产环境中要求这些必须是一致的。
FTP connections (FTP connections require careful handling due to the complex nature of FTP connections). PS：指定一个范围，将范围内的端口打上标记。然后使VSFTPD在被动模式下不再使用随机端口，而是使用范围内的随机端口，从而实现FTP的负载均衡。
1 Limiting the port range for passive connections, you must also configure the VSFTP server to use a matching port range:
vim /etc/vsftpd.conf:
pasv_min_port=10000
pasv_max_port=20000
2 You must also control the address that the server displays to the client for passive FTP connections. In
a NAT routed LVS system, add the following line to /etc/vsftpd.conf to override the real server IP address to the VIP, which is what the client sees upon connection. For example:
pasv_address=n.n.n.n
3 iptables定义端口姻亲：
iptables -t mangle -A PREROUTING -p tcp -d n.n.n.n/32 --dport 21 -j MARK --set-mark 21
iptables -t mangle -A PREROUTING -p tcp -d n.n.n.n/32 --dport 10000:20000 -j MARK --set-mark 21
Expired persistence, which is used internally by the Director to expire connection tracking entries when the persistent connection template expires.
LVS+Keepalived实现高可用集群 一、基础介绍 (2) 二、搭建配置LVS-NA T模式 (2) 三、搭建配置LVS-DR模式 (4) 四、另外一种脚本方式实现上面LVS-DR模式 (6) 五、keepalived + LVS(DR模式) 高可用 (8) 六、Keepalived 配置文件详细介绍 (11)
一、基础介绍 (一)根据业务目标分成三类： High Availability 高可用 Load Balancing 负载均衡 High Performance 高性能 (二)实现集群产品： HA类： rhcs、heartbeat、keepalived LB类： haproxy、lvs、nginx、f5、piranha HPC类： https://www.doczj.com/doc/9912553846.html,/index/downfile/infor_id/42 (三)LVS 负载均衡有三种模式： LVS-DR模式（direct router）直接路由模式 进必须经过分发器，出就直接出 LVS-NAT模式（network address translation） 进出必须都经过分发器 LVS-TUN模式（ip tunneling）IP隧道模式 服务器可以放到全国各地 二、搭建配置LVS-NAT模式 1 、服务器IP规划： DR服务器添加一张网卡eth1，一个网卡做DIP，一个网口做VIP。 设置DIP、VIP IP地址: DIP的eth1和所有RIP相连同一个网段 CIP和DIP的eth0(Vip)相连同一个网段 Vip eth0 192.168.50.200 Dip eth1 192.168.58.4 客户机IP： Cip 192.168.50.3
实用标准文案 NLB 、HA、HPC集群、双机、负载均衡、 1.1什么是集群）就是一组计算机，它们作为一个整体向用户cluster 简单的说，集群（）。一提供一组网络资源。这些单个的计算机系统就是集群的节点（node她们看/个理想的集群是，用户从来不会意识到集群系统底层的节点，在他来，集群是一个系统，而非多个计算机系统。并且集群系统的管理员可以随意增加和删改集群系统的节点。集群系统的主要优点：1.2 高可扩展性：(1)：集群中的一个节点失效，它的任务可传递给其他节点。可高可用性HA(2) 以有效防止单点失效。 高性能：负载平衡集群允许系统同时接入更多的用户。(3) 高性价比：可以采用廉价的符合工业标准的硬件构造高性能的系统。(4) 集群系统的分类2.1 虽然，根据集群系统的不同特征可以有多种分类方法，但是一般把集群系统 分为两类：集群。,、高可用(High Availability)集群简称HA(1) 这类集群致力于提供高度可靠的服务。就是利用集群系统的容错性对外提供 小时不间断的服务，如高可用的文件服务器、数据库服务等关键应用。7*24负载均衡集群：使任务可以在集群中尽可能平均地分摊不同的计算机进行处 精彩文档． 实用标准文案 理，充分利用集群的处理能力，提高对任务的处理效率。以提供更加高效稳
定的服务。在实际应用中这几种集群类型可能会混合使用， 高就会包含高可用的网络文件系统、如在一个使用的网络流量负载均衡集群中，可用的网络服务。集群，也HPC(High Perfermance Computing)集群，简称(2)、性能计算称为科学计算集群。 在这种集群上运行的是专门开发的并行应用程序，它可以把一个问题的数据 从而可以分布到多台的计算机上，利用这些计算机的共同资源来完成计算任务，解决单机不能胜任的工作（如问题规模太大，单机计算速度太慢）。 如天气预报、这类集群致力于提供单个计算机所不能提供的强大的计算能力。石油勘探与油藏模拟、分子模拟、生物计算等。(HA) 3.1 什么是高可用性和可维护(reliability)计算机系统的可用性(availability)是通过系统的可靠性 来度量系统(MTTF)来度量的。工程上通常用平均无故障时间性(maintainability)于是可用性被定义）来度量系统的可维护性。,用平均维修时间（MTTR的可靠性MTTF/ (MTTF+MTTR)*100% 为：负载均衡服务器的高可用性主服务器和备份机上都需要建立一个备份机。为了屏蔽负载均衡服务器的失效，”这样的信息来监I am alive监控程序，通过传送诸如“运行High Availability它就接管当备份机不能在一定的时间内收到这样的信息时，控对方的运行状况。I am 并继续提供服务；当备份管理器又从主管理器收到“主服务器的服务IP精彩文档．实用标准文案 地址，这样的主管理器就开开始再次进IPalive”这样的信息是，它就释放服务行集群管理的工作了。为在主服务器失效的情况下系统能正常工作，我们在主、备份机之间实现负载集群系统配置信息的同步与备份，保持二者系统的基本一
利用LVS+Keepalived 实现高性能高可用负载均衡 作者：NetSeek 网站: https://www.doczj.com/doc/9912553846.html, 背景: 随着你的网站业务量的增长你网站的服务器压力越来越大？需要负载均衡方案！商业的硬件如F5又太贵，你们又是创业型互联公司如何有效节约成本，节省不必要的浪费？同时实现商业硬件一样的高性能高可用的功能？有什么好的负载均衡可伸张可扩展的方案吗？答案是肯定的！有！我们利用LVS+Keepalived基于完整开源软件的架构可以为你提供一个负载均衡及高可用的服务器。 一．L VS+Keepalived 介绍 1.LVS LVS是Linux Virtual Server的简写，意即Linux虚拟服务器，是一个虚拟的服务器集群系统。本项目在1998年5月由章文嵩博士成立，是中国国内最早出现的自由软件项目之一。目前有三种IP负载均衡技术（VS/NA T、VS/TUN和VS/DR）； 八种调度算法（rr,wrr,lc,wlc,lblc,lblcr,dh,sh）。 2.Keepalvied Keepalived在这里主要用作RealServer的健康状态检查以及LoadBalance主机和BackUP主机之间failover的实现 二. 网站负载均衡拓朴图 . IP信息列表： 名称IP LVS-DR-Master 61.164.122.6 LVS-DR-BACKUP 61.164.122.7 LVS-DR-VIP 61.164.122.8 WEB1-Realserver 61.164.122.9 WEB2-Realserver 61.164.122.10 GateWay 61.164.122.1
Tomcat集群与负载均衡（转载） 在单一的服务器上执行WEB应用程序有一些重大的问题，当网站成功建成并开始接受大量请求时，单一服务器终究无法满足需要处理的负荷量，所以就有点显得有点力不从心了。另外一个常见的问题是会产生单点故障，如果该服务器坏掉，那么网站就立刻无法运作了。不论是因为要有较佳的扩充性还是容错能力，我们都会想在一台以上的服务器计算机上执行WEB应用程序。所以，这时候我们就需要用到集群这一门技术了。 在进入集群系统架构探讨之前，先定义一些专门术语： 1. 集群(Cluster)：是一组独立的计算机系统构成一个松耦合的多处理器系统，它们之间通过网络实现进程间的通信。应用程序可以通过网络共享内存进行消息传送，实现分布式计算机。 2. 负载均衡(Load Balance)：先得从集群讲起，集群就是一组连在一起的计算机，从外部看它是一个系统，各节点可以是不同的操作系统或不同硬件构成的计算机。如一个提供Web服务的集群，对外界来看是一个大Web服务器。不过集群的节点也可以单独提供服务。 3. 特点：在现有网络结构之上，负载均衡提供了一种廉价有效的方法扩展服务器带宽和增加吞吐量，加强网络数据处理能力，提高网络的灵活性和可用性。集群系统(Cluster)主要解决下面几个问题： 高可靠性（HA）：利用集群管理软件，当主服务器故障时，备份服务器能够自动接管主服务器的工作，并及时切换过去，以实现对用户的不间断服务。 高性能计算（HP）：即充分利用集群中的每一台计算机的资源，实现复杂运算的并行处理，通常用于科学计算领域，比如基因分析，化学分析等。 负载平衡：即把负载压力根据某种算法合理分配到集群中的每一台计算机上，以减轻主服务器的压力，降低对主服务器的硬件和软件要求。 目前比较常用的负载均衡技术主要有： 1. 基于DNS的负载均衡 通过DNS服务中的随机名字解析来实现负载均衡，在DNS服务器中，可以为多个不同的地址配置同一个名字，而最终查询这个名字的客户机将在解析这个名字时得到其中一个地址。因此，对于同一个名字，不同的客户机会得到不同的地址，他们也就访问不同地址上的Web服务器，从而达到负载均衡的目的。 2. 反向代理负载均衡（如Apache+JK2+Tomcat这种组合） 使用代理服务器可以将请求转发给内部的Web服务器，让代理服务器将请求均匀地转发给多台内部Web服务器之一上，从而达到负载均衡的目的。这种代理方式与普通的代理方式有所不同，标准代理方式是客户使用代理访问多个外部Web服务器，而这种代理方式是多个客户使用它访问内部Web服务器，因此也被称为反向代理模式。 3. 基于NAT（Network Address Translation）的负载均衡技术（如Linux Virtual Server，简称LVS）
LVS+Keepalived 介绍 LVS LVS是Linux Virtual Server的简写，意即Linux虚拟服务器，是一个虚拟的服务器集群系统。本项目在1998年5月由章文嵩博士成立，是中国国内最早出现的自由软件项目之一。目前有三种IP负载均衡技术（VS/NAT、VS/TUN和VS/DR）； 十种调度算法（rrr|wrr|lc|wlc|lblc|lblcr|dh|sh|sed|nq）。 Keepalvied Keepalived在这里主要用作RealServer的健康状态检查以及LoadBalance主机和BackUP 主机之间failover的实现 二. 网站负载均衡拓朴图 IP信息列表： 名称 IP LVS-DR-Master 61.164.122.6 ? LVS-DR-BACKUP 61.164.122.7 ? LVS-DR-VIP 61.164.122.8 ? WEB1-Realserver 61.164.122.9 ? WEB2-Realserver 61.164.122.10 ? GateWay 61.164.122.1 复制代码 三. 安装LVS和Keepalvied软件包 1. 下载相关软件包 #mkdir /usr/local/src/lvs ? #cd /usr/local/src/lvs ? #wget https://www.doczj.com/doc/9912553846.html,/software/kernel-2.6/ipvsadm-1.24.tar.gz ? #wget https://www.doczj.com/doc/9912553846.html,/software/keepalived-1.1.15.tar.gz 复制代码 2. 安装LVS和Keepalived #lsmod |grep ip_vs ? #uname -r ? 2.6.18-53.el5PAE ? #ln -s /usr/src/kernels/2.6.18-53.el5PAE-i686/ /usr/src/linux ? ? #tar zxvf ipvsadm-1.24.tar.gz ? #cd ipvsadm-1.24 ? #make && make install ? #find / -name ipvsadm # 查看ipvsadm的位置 ? ? #tar zxvf keepalived-1.1.15.tar.gz ? #cd keepalived-1.1.15 ? #./configure && make && make install
双节点数据库负载均衡解决方案 问题的提出？ 在SQL Server数据库平台上，企业的数据库系统存在的形式主要有单机模式和集群模式（为了保证数据库的可用性或实现备份）如：失败转移集群（MSCS）、镜像（Mirror）、第三方的高可用（HA）集群或备份软件等。伴随着企业的发展，企业的数据量和访问量也会迅猛增加，此时数据库就会面临很大的负载和压力，意味着数据库会成为整个信息系统的瓶颈。这些“集群”技术能解决这类问题吗？SQL Server数据库上传统的集群技术 Microsoft Cluster Server(MSCS) 相对于单点来说Microsoft Cluster Server(MSCS)是一个可以提升可用性的技术，属于高可用集群，Microsoft称之为失败转移集群。 MSCS 从硬件连接上看，很像Oracle的RAC，两个节点，通过网络连接，共享磁盘；事实上SQL Server 数据库只运行在一个节点上，当出现故障时，另一个节点只是作为这个节点的备份； 因为始终只有一个节点在运行，在性能上也得不到提升,系统也就不具备扩展的能力。当现有的服务器不能满足应用的负载时只能更换更高配置的服务器。 Mirror 镜像是SQL Server 2005中的一个主要特点，目的是为了提高可用性，和MSCS相比，用户实现数据库的高可用更容易了，不需要共享磁盘柜，也不受地域的限制。共设了三个服务器，第一是工作数据库（Principal Datebase），第二个是镜像数据库（Mirror），第三个是监视服务器（Witness Server，在可用性方面有了一些保证，但仍然是单服务器工作；在扩展和性能的提升上依旧没有什么帮助。
1、安装LVS软件 （1）安装前准备 操作系统：统一采用Centos5.3版本，地址规划如下： 更详细的信息如下图所示： 图中的VIP指的是虚拟IP地址，还可以叫做LVS集群的服务IP，在DR、TUN模式中，数据包是直接返回给用户的，所以，在Director Server上以及集群的每个节点上都需要设置这个地址。此IP在Real Server上一般绑定在回环地址上，例如lo:0，同样，在Director Server 上，虚拟IP绑定在真实的网络接口设备上，例如eth0:0。 各个Real Server可以是在同一个网段内，也可以是相互独立的网段，还可以是分布在internet上的多个服务器.
（2）安装操作系统需要注意的事项 Centos5.3版本的Linux，内核默认支持LVS功能，为了方便编译安装IPVS管理软件，在安装操作系统时，建议选择如下这些安装包：l 桌面环境：xwindows system、GNOME desktop environment。 l 开发工具：development tools、x software development、gnome software、development、kde software development。 系统安装完毕，可以通过如下命令检查kernel是否已经支持LVS的ipvs模块： [root@localhost ~]#modprobe -l |grep ipvs /lib/modules/2.6.18-194.11.1.el5/kernel/net/ipv4/ipvs/ip_vs.ko /lib/modules/2.6.18-194.11.1.el5/kernel/net/ipv4/ipvs/ip_vs_dh.ko 如果有类似上面的输出，表明系统内核已经默认支持了IPVS模块。接着就可以安装IPVS管理软件了。
轻松实现Apache,Tomcat集群和负载均衡 作者:罗代均 ldj_work#https://www.doczj.com/doc/9912553846.html,,转载请保持完整性 0，环境说明 Apache :apache_2.0.55 1 个 Tomcat: apache-tomcat-5.5.17 (zip版) 2个 mod_jk:: mod_jk-apache-2.0.55.so 1个 第一部分：负载均衡 负载均衡，就是apache将客户请求均衡的分给tomcat1,tomcat2....去处理 1.安装apche,tomcat https://www.doczj.com/doc/9912553846.html,/下载Apache 2.0.55 https://www.doczj.com/doc/9912553846.html,/download-55.cgi下载tomcat5.5 zip版本（解压即可，绿色版） https://www.doczj.com/doc/9912553846.html,/tomcat/tomcat-connectors/jk/binaries/win32/jk-1.2.15/下载mod_jk,注意和 apache版本匹配 按照jdk,我的路径为:E:\ide\apache\Apache2 解压两份Tomcat, 路径分别为 E:\ide\tomcat1,E:\ide\tomcat2
下载mod_jk
2.修改Apache配置文件http.conf 在apache安装目录下conf目录中找到http.conf 在文件最后加上下面一句话就可以了 include "E:\ide\apache\Apache2\conf\mod_jk.conf"
2. http.conf 同目录下新建mod_jk.conf文件，内容如下 #加载mod_jk Module LoadModule jk_module modules/mod_jk-apache-2.0.55.so #指定 workers.properties文件路径 JkWorkersFile conf/workers.properties #指定那些请求交给tomcat处理,"controller"为在workers.propertise里指定的负载分配控制器JkMount /*.jsp controller 3.在http.conf同目录下新建 workers.properties文件，内容如下 worker.list = controller,tomcat1,tomcat2 #server 列表 #========tomcat1======== worker.tomcat1.port=8009 #ajp13 端口号，在tomcat下server.xml配置,默认8009 worker.tomcat1.host=localhost #tomcat的主机地址，如不为本机，请填写ip地址 worker.tomcat1.type=ajp13 worker.tomcat1.lbfactor = 1 #server的加权比重，值越高，分得的请求越多 #========tomcat2======== worker.tomcat2.port=9009 #ajp13 端口号，在tomcat下server.xml配置,默认8009 worker.tomcat2.host=localhost #tomcat的主机地址，如不为本机，请填写ip地址 worker.tomcat2.type=ajp13 worker.tomcat2.lbfactor = 1 #server的加权比重，值越高，分得的请求越多
LVS FULLNAT 模式安装 By 清风徐来 605612253@https://www.doczj.com/doc/9912553846.html,
1 部署规划
依照淘宝开源的 FULLNAT 模式 LVS，规划使用版本信息： Linux 内核：2.6.32-220.23.1.el6 LVS 版本：version 1.2.1 Keepalived 版本：v1.2.2 序号 主机 IP 域名 作用 备注 1 10.142.67.121 TEST-DEV-121 Master 编译内核+LVS+keepalived 2 10.142.67.122 TEST-DEV-122 Backup 编译内核+LVS+keepalived 3 10.142.78.74 TEST-BDD-074 Hiveserver2 编译内核+hiveserver2 4 10.142.78.76 TEST-BDD-076 Hiveserver2 编译内核+hiveserver2
2 LVS 安装
2.1 内核编译
内核编译需要在 master 和 backup 节点都执行，以下以 master 节点为例 安装脚本：
compilekerna-LVSmaster.sh
由于不能上外网，所以提前把对应的安装包下好 下载的暂时放在家目录 [op@TEST-DEV-121 ~]$ ls compilekerna-LVSmaster.sh kernel-2.6.32-220.23.1.el6.src.rpm Lvs-fullnat-synproxy.tar.gz 安装 此处由于是编译内核，使用 root 用户来执行，以免遇到各种权限问题 [op@TEST-DEV-121 ~]$ sudo chmod +x compilekerna-LVSmaster.sh
集群的负载均衡技术综述 摘要：当今世界，无论在机构内部的局域网还是在广域网如Internet上，信息处理量的增长都远远超出了过去最乐观的估计，即使按照当时最优配置建设的网络，也很快会感到吃不消。如何在完成同样功能的多个网络设备之间实现合理的业务量分配，使之不致于出现一台设备过忙、而别的设备却未充分发挥处理能力的情况，负载均衡机制因此应运而生。本组在课堂上讲解了《集群监控与调度》这一课题，本人在小组内负责负载均衡部分内容，以及PPT的制作。 关键词：负载均衡集群网络计算机 一、前言 负载均衡建立在现有网络结构之上，它提供了一种廉价有效的方法扩展服务器带宽和增加吞吐量，加强网络数据处理能力，提高网络的灵活性和可用性。它主要完成以下任务：解决网络拥塞问题，服务就近提供，实现地理位置无关性；为用户提供更好的访问质量；提高服务器响应速度；提高服务器及其他资源的利用效率；避免了网络关键部位出现单点失效。 其实，负载均衡并非传统意义上的“均衡”，一般来说，它只是把有可能拥塞于一个地方的负载交给多个地方分担。如果将其改称为“负载分担”，也许更好懂一些。说得通俗一点，负载均衡在网络中的作用就像轮流值日制度，把任务分给大家来完成，以免让一个人累死累活。不过，这种意义上的均衡一般是静态的，也就是事先确定的“轮值”策略。 与轮流值日制度不同的是，动态负载均衡通过一些工具实时地分析数据包，掌握网络中的数据流量状况，把任务合理分配出去。结构上分为本地负载均衡和地域负载均衡(全局负载均衡)，前一种是指对本地的服务器集群做负载均衡，后一种是指对分别放置在不同的地理位置、在不同的网络及服务器群集之间作负载均衡。 服务器群集中每个服务结点运行一个所需服务器程序的独立拷贝，诸如Web、FTP、Telnet或e-mail服务器程序。对于某些服务（如运行在Web服务器上的那些服务）而言，程序的一个拷贝运行在群集内所有的主机上，而网络负载均衡则将工作负载在这些主机间进行分配。对于其他服务（例如e-mail），只有一台主机处理工作负载，针对这些服务，网络负载均衡允许网络通讯量流到一个主机上，并在该主机发生故障时将通讯量移至其他主机。 二、负载均衡技术实现结构 在现有网络结构之上，负载均衡提供了一种廉价有效的方法扩展服务器带宽和增加吞吐量，加强网络数据处理能力，提高网络的灵活性和可用性。它主要完成以下任务： 1.解决网络拥塞问题，服务就近提供，实现地理位置无关性 2.为用户提供更好的访问质量 3.提高服务器响应速度
高可用Lvs集群搭建和测试报告 Lvs（Linux Virtual Server）是Linux下的负载均衡器，支持LVS-NA T、 LVS-DR、LVS-TUNL三种不同的方式，NA T用的不是很多，主要用的是DR、TUNL方式。DR方式适合所有的RealServer在同一网段下，即接在同一个交换机上。TUNL方式不限制RealServer 的位置，完全可以跨地域、空间，只要系统支持Tunnel就可以。 运行Lvs的前端调度器，目前只能为Linux，针对FreeBSD刚刚出来，性能不是很好。可以针对Web、MySQL、Ftp等服务做load balances。后端的RealServer则可以为各类系统，Linux、Solaris、Aix、BSD、Windows都可。 下面主要针对DR方式下的Web、MySQL负载均衡，以及Lvs + HA做功能性的验证和性能方面的测试。 1.集群系统拓扑
2.环境搭建说明 1.前端Load Balancer、Backup为虚拟机Linux系统，后端两台Real Server为纯Linux系 统。 2.192.168.6.229为前端负载均衡调度器，虚拟IP为192.168.6.111，安装并配置了ipvsadm （负载均衡）、ldirectord（健康监控）服务。 3.192.168.6.230为调度器的备份，采用heartbeat实现。 4.192.168.6.240、192.168.6.241为两台提供服务的真实Server。 3.功能性验证 首先在Load Balancer上安装ipvsadm、ldirectord、heartbeat服务，备机上也相同，可以用YUM进行安装，安装完成后需要将ha.cf、haresources、authkeys、ldirectord.cf文件拷贝到/etc/ha.d/ 目录下。 3.1. 验证Apache负载均衡。 3.1.1.配置 1.配置Load Balancer的ipvsadm，脚本内容如下：
1、Linux集群主要分成三大类( 高可用集群，负载均衡集群，科学计算集群)（下面只介绍负载均衡集群） 负载均衡集群(Load Balance Cluster) 负载均衡系统：集群中所有的节点都处于活动状态，它们分摊系统的工作负载。一般Web服务器集群、数据库集群和应用服务器集群都属于这种类型。 负载均衡集群一般用于相应网络请求的网页服务器，数据库服务器。这种集群可以在接到请求时，检查接受请求较少，不繁忙的服务器，并把请求转到这些服务器上。从检查其他服务器状态这一点上看，负载均衡和容错集群很接近，不同之处是数量上更多。 2、负载均衡系统：负载均衡又有DNS负载均衡（比较常用）、IP负载均衡、反向代理负载均衡等，也就是在集群中有服务器A、B、C，它们都是互不影响，互不相干的，任何一台的机器宕了，都不会影响其他机器的运行，当用户来一个请求，有负载均衡器的算法决定由哪台机器来处理，假如你的算法是采用round算法，有用户a、b、c，那么分别由服务器A、B、C来处理； 3、分布式是指将不同的业务分布在不同的地方。 而集群指的是将几台服务器集中在一起，实现同一业务。 分布式中的每一个节点，都可以做集群。 而集群并不一定就是分布式的。 举例：就比如新浪网，访问的人多了，他可以做一个群集，前面放一个响应服务器，后面几台服务器完成同一业务，如果有业务访问的时候，响应服务器看哪台服务器的负载不是很重，就将给哪一台去完成。 而分布式，从窄意上理解，也跟集群差不多，但是它的组织比较松散，不像集群，有一个组织性，一台服务器垮了，其它的服务器可以顶上来。 分布式的每一个节点，都完成不同的业务，一个节点垮了，哪这个业务就不可访问了。
PS：Nginx/LVS/HAProxy是目前使用最广泛的三种负载均衡软件，本人都在多个项目中实施过，参考了一些资料，结合自己的一些使用经验，总结一下。 一般对负载均衡的使用是随着网站规模的提升根据不同的阶段来使用不同的技术。具体的应用需求还得具体分析，如果是中小型的Web应用，比如日PV小于1000万，用Nginx就完全可以了；如果机器不少，可以用DNS轮询，LVS所耗费的机器还是比较多的；大型网站或重要的服务，且服务器比较多时，可以考虑用LVS。一种是通过硬件来进行进行，常见的硬件有比较昂贵的F5和Array等商用的负载均衡器，它的优点就是有专业的维护团队来对这些服务进行维护、缺点就是花销太大，所以对于规模较小的网络服务来说暂时还没有需要使用；另外一种就是类似于Nginx/LVS/HAProxy的基于Linux的开源免费的负载均衡软件，这些都是通过软件级别来实现，所以费用非常低廉。 目前关于网站架构一般比较合理流行的架构方案：Web前端采用 Nginx/HAProxy+Keepalived作负载均衡器；后端采用MySQL数据库一主多从和读写分离，采用LVS+Keepalived的架构。当然要根据项目具体需求制定方案。 下面说说各自的特点和适用场合。 一、Nginx Nginx的优点是： 1、工作在网络的7层之上，可以针对http应用做一些分流的策略，比如针对域名、目录结构，它的正则规则比HAProxy更为强大和灵活，这也是它目前广泛流行的主要原因之一，Nginx单凭这点可利用的场合就远多于LVS了。 2、Nginx对网络稳定性的依赖非常小，理论上能ping通就就能进行负载功能，这个也是它的优势之一；相反LVS对网络稳定性依赖比较大，这点本人深有体会； 3、Nginx安装和配置比较简单，测试起来比较方便，它基本能把错误用日志打印出来。LVS的配置、测试就要花比较长的时间了，LVS对网络依赖比较大。 3、可以承担高负载压力且稳定，在硬件不差的情况下一般能支撑几万次的并发量，负载度比LVS相对小些。 4、Nginx可以通过端口检测到服务器内部的故障，比如根据服务器处理网页返回的状态码、超时等等，并且会把返回错误的请求重新提交到另一个节点，不过其中缺点就是不支持url来检测。比如用户正在上传一个文件，而处理该上传的节点刚好在上传过程中出现故障，Nginx会把上传切到另一台服务器重新处理，而LVS就直接断掉了，如果是上传一个很大的文件或者很重要的文件的话，用户可能会因此而不满。 5、Nginx不仅仅是一款优秀的负载均衡器/反向代理软件，它同时也是功能强大的Web应用服务器。LNMP也是近几年非常流行的web架构，在高流量的环境中稳定性也很好。 6、Nginx现在作为Web反向加速缓存越来越成熟了，速度比传统的Squid服务器更快，可以考虑用其作为反向代理加速器。 7、Nginx可作为中层反向代理使用，这一层面Nginx基本上无对手，唯一可以对比
集群和负载均衡的概念 什么是集群(Cluster) 所谓集群是指一组独立的计算机系统构成的多处理器系统，每台服务器都具有等价的地位，它们之间通过网络实现进程间的通信。应用程序可以通过网络共享内存进行消息传送，实现分布式计算机。集群也是指多台计算机共同协作运行一个应用。 可分为以下几种： （1）高可靠性（HA）。利用集群管理软件，当主服务器故障时，备份服务器能够自动接管主服务器的工作，并及时切换过去，以实现对用户的不间断服务。 （2）高性能计算（HP）。即充分利用集群中的每一台计算机的资源，实现复杂运算的并行处理，通常用于科学计算领域。 （3）负载平衡（Load Balance）。负载均衡就是集群功能其中的一种。即把负载压力根据某种算法合理分配到集群中的每一台计算机上，以减轻主服务器的压力，降低对主服务器的硬件和软件要求。 负载均衡是指将计算请求分配到集群中以使集群中的计算机的计算负载均衡。 负载均衡有两方面的含义： 1：大量的并发访问或数据流量分担到多台节点设备上分别处理，减少用户等待响应的时间。 2：单个重负载的运算分担到多台节点设备上做并行处理，每个节点设备处理结束后，将结果汇总，返回给用户，系统处理能力得到大幅度提高。实现起来可分为： （1）基于服务器软件的集群负载均衡。（在服务器上实现。） （2）NAT的集群负载均衡（在放火墙上，或在交换机上实现。） （3）基于DNS的集群负载均衡（在DNS服务器上实现。） （4）也可以用ISA放火墙实现集群负载均衡,但是需要有ISA服务器本人认为可行性不大。 基于服务器软件的集群负载均衡 microsoft的产品4种集群技术： 1：microsoft 集群服务(MSCS) 2：网络负载均衡（NLB） 3：组件负载均衡（CLB） 4：application center（应用负载均衡） linux 的集群技术：LVS(Linux VirtualServer) LVS对Linux的kernel进行了修改和增加所以要重新编译linux 内核。包名linux-2.4.20-ipvs-*.*.*.patch.gz 基与nat的集群负载均衡（在放火墙上，或在交换机上实现。） NAT（Network Address Translation 网络地址转换）简单地说就是将一个IP地址转换为另一个IP地址。一般用于内部地址与合法的转换。适用于解决Internet IP地址紧张、不想让网络外部知道内部网络结构等的场合下。 NAT负载均衡将一个外部IP地址映射为多个内部IP地址，对每次连接请求动态地转换为一个内部服务器的地址，将外部连接请求引到转换得到地址的那个服务器上，从而达到负载均衡的目的。 基于DNS的集群负载均衡（在DNS服务器上实现。） DNS负载均衡技术是在DNS服务器中为同一个主机名配置多个IP地址，在应答DNS查询时，DNS服务器对每个查询将以DNS文件中主机记录的IP地址按顺序返回不同的解析结果，将客户端的访问引导到不同的机器上去，使得不同的客户端访问不同的服务器，从而达到负载均衡的目的。
用双机高可用集群还是使用负载均衡集群 北京麒麟博峰科技有限公司 2010年11月 1
目录 第一章问题描述 (1) 第二章基本的技术知识 (1) 2.1.HA高可用集群 (1) 2.2.Load Balance负载均衡集群 (2) 第三章该使用哪种集群 (3) I
第一章问题描述 系统工程师通常会对如何使用HA高可用集群，即“双机”，和负载均衡集群，比如KYLIN Netsphere等负载均衡设备，产生疑惑不解，通常在构筑服务器集群的时候，不合理的设计造成系统的整体效率不高、设备浪费或者维护的不便利，本文试图用最简单的方式解惑。 要解决这些问题，不惑者需要正确自我解答以下问题： 1.系统的并发是否是考虑的主要问题之一？ 2.以后并发用户会不会急剧增长？ 3.运营的软件是否是一个标准的三级架构或者多级架构（N-Tier）？ 4.运营的软件的端口是否对应不同的业务？ 5.不同的业务软件是否运行在不同的服务器设备上？ 6.资金是否成为问题？ 第二章基本的技术知识 2.1 HA高可用集群 HA（单字母发音， H A 不是“哈”）高可用集群主要是为了“保护”“特定资源”所开发的一种集群技术，这里所说的“特定资源”包含以下内容： 1)进程； 如果进程被杀死，即从系统角度上看，该进程没有了，那么，HA可以及时发现，并在 另外一个地方将部署好的进程启动；如果该进程僵死，即不工作了，可能由于软件设计 的不好，出现了死循环或者其他原因，但该进程还存在，这时HA是不能发现的，所以，有时候即使进程不响应了，HA并没有切换； 解决这个问题，只能依靠应用软件提供监控接口，并将该接口公布给HA开发商。我们 在市场中发现有些厂商的基于数据库的特别好使，有些公司的产品出现同样状况时却像 傻子一样，这个可能是不同的HA厂商和数据库厂商合作的深浅度有关。 2)网卡； 如果网卡完全挂掉，HA是可以发现并采用行动，但是工作的不正常，这种情况HA可 能不能发现，尤其是抖动的情况发生； 3)存储； 1
Web服务器集群负载均衡技术的应用与研究 侯秀杰祝永志孔令鑫 (曲阜师范大学计算机科学学院，山东日照 276826 ) 摘要为了提高集群系统对用户的快速响应与整体吞吐量，必须采取一定的策略将Web访问均衡地分配到集群中的每一个服务器。基于此思想本文针对传统的单机思想给出了一种多机三层结构的负载均衡系统。实验结果表明了它在负载均衡方面的优越性。 关键词负载均衡；均衡策略；调度算法；Web服务器集群模型 1 引言 Internet的快速增长，特别是电子商务应用的发展，使Web应用成为目前最重要最广泛的应用，Web 服务器动态内容越来越流行。目前，网上信息交换量几乎呈指数增长，需要更高性能的Web服务器提供更多用户的Web服务，因此，Web服务器面临着访问量急剧增加的压力，对其处理能力和响应能力等带来更高的要求，如果Web 服务器无法满足大量Web访问服务，将无法为用户提供稳定、良好的网络应用服务。 由于客观存在的服务器物理内存、CPU 处理速度和操作系统等方面的影响因素，当大量突发的数据到达时，Web服务器无法完全及时处理所有的请求，造成应答滞后、请求丢失等，严重的导致一些数据包因延时而重发，使传输线路和服务器的负担再次增加。传统的方法是提高Web 服务器的CPU 处理速度和增加内存容量等硬件办法但无论如何增加Web 服务器硬件性能，均无法满足日益增加的对用户的访问服务能力。 面对日渐增加的Web 访问服务要求，必须对Web 服务器按一定策略进行负载分配。利用负载均衡[1]的技术，按照一定策略将Web 访问服务分配到几台服务器上，负载处理对用户透明，整体上对外如同一台Web 服务器为用户提供Web服务。 2 Web负载均衡结构 2.1 负载均衡 负载是一个抽象的概念，是表示系统繁忙程度，系统在一段时间空闲，该系统负载轻，系统在一段时间空忙，该系统负载重，影响系统负载的各种因数较多如果存在很多的数据包同时通过网络连向一台Web 服务器，也就是网络的速度比网络所连接的设备速度快的情况下，系统负载不断增加，直到最大。 目前提高Web 服务器性能，使其具有较强负载能力，主要有两种处理思想[2]： 1)单机思想 不断升级服务器硬件性能，每当负载增加，服务器随之升级。这随之将带来一些问题，首先，服务器向高档升级，花费资金较多；其次，升级频繁，机器切换造成服务中断，可能会导致整个服务中断；最后，每种架构的服务器升级总有一个极限限制。 2)多机思想 使用多台服务器提供服务，通过一定机制使它们共同分担系统负载，对单一的服务器没有太高的性能要求，系统负载增加，可以多增加服务器来分担。对用户而言，整个系统仿佛是一台单一的逻辑服务器，这样的系统能够提供较强的可扩展性和较好的吞吐性能。 为了适应当前急剧增长的Web访问，有别于传统的单机思想，解决单机思想带来的一系列问题，本文提出了一种基于权值的策略分配负载。 2.2 负载均衡实现设备[2]
LVS负载均衡DR模式—直接路由模式 Virtual server via direct routing (vs/dr) DR模式是通过改写请求报文的目标MAC地址，将请求发给真实服务器的，而真实服务器响应后的处理结果直接返回给客户端用户。同TUN模式一样，DR模式可以极大的提高集群系统的伸缩性。而且DR模式没有IP隧道的开销，对集群中的真实服务器也没有必要必须支持IP隧道协议的要求。但是要求调度器LB与真实服务器RS都有一块网卡连接到同一物理网段上，必须在同一个局域网环境。 DR模式是互联网使用比较多的一种模式。 DR模式原理图： DR模式原理过程简述： VS/DR模式的工作流程图如上图所示，它的连接调度和管理与NAT和TUN中的一样，它的报文转发方法和前两种不同。DR模式将报文直接路由给目标真实服务器。在DR模式中，调度器根据各个真实服务器的负载情况，连接数多少等，动态地选择一台服务器，不修改目标IP地址和目标端口，也不封装IP报文，而是将请求报文的数据帧的目标MAC地址改为真实服务器的MAC
地址。然后再将修改的数据帧在服务器组的局域网上发送。因为数据帧的MAC地址是真实服务器的MAC地址，并且又在同一个局域网。那么根据局域网的通讯原理，真实复位是一定能够收到由LB发出的数据包。真实服务器接收到请求数据包的时候，解开IP包头查看到的目标IP是VIP。（此时只有自己的IP符合目标IP才会接收进来，所以我们需要在本地的回环借口上面配置VIP。另：由于网络接口都会进行ARP广播响应，但集群的其他机器都有这个VIP的lo接口，都响应就会冲突。所以我们需要把真实服务器的lo接口的ARP响应关闭掉。）然后真实服务器做成请求响应，之后根据自己的路由信息将这个响应数据包发送回给客户，并且源IP地址还是VIP。 DR模式小结： 1、通过在调度器LB上修改数据包的目的MAC地址实现转发。注意源地址仍然是CIP，目的地址仍然是VIP地址。 2、请求的报文经过调度器，而RS响应处理后的报文无需经过调度器LB，因此并发访问量大时使用效率很高（和NAT模式比） 3、因为DR模式是通过MAC地址改写机制实现转发，因此所有RS节点和调度器LB只能在一个局域网里面 4、RS主机需要绑定VIP地址在LO接口上，并且需要配置ARP抑制。 5、RS节点的默认网关不需要配置成LB，而是直接配置为上级路由的网关，能让RS直接出网就可以。 6、由于DR模式的调度器仅做MAC地址的改写，所以调度器LB就不能改写目标端口，那么RS服务器就得使用和VIP相同的端口提供服务。 测试拓扑图：
集群、双机、负载均衡、HA、HPC、NLB 1.1什么是集群 简单的说，集群（cluster）就是一组计算机，它们作为一个整体向用户提供一组网络资源。这些单个的计算机系统就是集群的节点（node）。 一个理想的集群是，用户从来不会意识到集群系统底层的节点，在他/她们看来，集群是一个系统，而非多个计算机系统。并且集群系统的管理员可以随意增加和删改集群系统的节点。 1.2 集群系统的主要优点： (1)高可扩展性： (2)高可用性HA：集群中的一个节点失效，它的任务可传递给其他节点。可以有效防止单点失效。 (3)高性能：负载平衡集群允许系统同时接入更多的用户。 (4)高性价比：可以采用廉价的符合工业标准的硬件构造高性能的系统。 2.1 集群系统的分类 虽然，根据集群系统的不同特征可以有多种分类方法，但是一般把集群系统分为两类： (1)、高可用(High Availability)集群,简称HA集群。 这类集群致力于提供高度可靠的服务。就是利用集群系统的容错性对外提供7*24小时不间断的服务，如高可用的文件服务器、数据库服务等关键应用。 负载均衡集群：使任务可以在集群中尽可能平均地分摊不同的计算机进行处理，充分利用集群的处理能力，提高对任务的处理效率。 在实际应用中这几种集群类型可能会混合使用，以提供更加高效稳定的服务。如在一个使用的网络流量负载均衡集群中，就会包含高可用的网络文件系统、高可用的网络服务。 (2)、性能计算(High Perfermance Computing)集群，简称HPC集群，也称为科学计算集群。 在这种集群上运行的是专门开发的并行应用程序，它可以把一个问题的