均衡负载服务器部署什么地方

⑴ 如何配置Web服务器实现负载均衡

网络的负载均衡是一种动态均衡技术，通过一些工具实时地分析数据包，掌握网络中的数据流量状况，把任务合理均衡地分配出去。这种技术基于现有网络结构，提供了一种扩展服务器带宽和增加服务器吞吐量的廉价有效的方法，加强了网络数据处理能力，提高了网络的灵活性和可用性。

以四台服务器为例实现负载均衡：

安装配置LVS

1. 安装前准备：

(1)首先说明，LVS并不要求集群中的服务器规格划一，相反，可以根据服务器的不同配置和负载状况，调整负载分配策略，充分利用集群环境中的每一台服务器。如下表：

Srv Eth0 Eth0：0 Eth1 Eth1：0

vs1 10.0.0.1 10.0.0.2 192.168.10.1 192.168.10.254

vsbak 10.0.0.3 192.168.10.102

real1 192.168.10.100

real2 192.168.10.101

其中，10.0.0.2是允许用户访问的IP。

(2)这4台服务器中，vs1作为虚拟服务器(即负载平衡服务器)，负责将用户的访问请求转发到集群内部的real1，real2，然后由real1，real2分别处理。
Client为客户端测试机器，可以为任意操作系统。

(3)所有OS为redhat6.2，其中vs1 和vsbak 的核心是2.2.19， 而且patch过ipvs的包， 所有real
server的Subnet mask 都是24位， vs1和vsbak 的10.0.0. 网段是24 位。

2.理解LVS中的相关术语

(1) ipvsadm ：ipvsadm是LVS的一个用户界面。在负载均衡器上编译、安装ipvsadm。

(2) 调度算法： LVS的负载均衡器有以下几种调度规则：Round-robin，简称rr;weighted
Round-robin，简称wrr;每个新的连接被轮流指派到每个物理服务器。Least-connected，简称lc;weighted
Least-connected，简称wlc，每个新的连接被分配到负担最小的服务器。

(3) Persistent client
connection，简称pcc，(持续的客户端连接，内核2.2.10版以后才支持)。所有来自同一个IP的客户端将一直连接到同一个物理服务器。超时时间被设置为360秒。Pcc是为https和cookie服务设置的。在这处调度规则下，第一次连接后，所有以后来自相同客户端的连接(包括来自其它端口)将会发送到相同的物理服务器。但这也会带来一个问题，因为大约有25%的Internet
可能具有相同的IP地址。

(4) Persistent port
connection调度算法：在内核2.2.12版以后，pcc功能已从一个调度算法(你可以选择不同的调度算法：rr、wrr、lc、wlc、pcc)演变成为了一个开关选项(你可以让rr、
wrr、lc、wlc具备pcc的属性)。在设置时，如果你没有选择调度算法时，ipvsadm将默认为wlc算法。 在Persistent port
connection(ppc)算法下，连接的指派是基于端口的，例如，来自相同终端的80端口与443端口的请求，将被分配到不同的物理服务器上。不幸的是，如果你需要在的网站上采用cookies时将出问题，因为http是使用80端口，然而cookies需要使用443端口，这种方法下，很可能会出现cookies不正常的情况。

(5)Load Node Feature of Linux Director：让Load balancer 也可以处理users 请求。

(6)IPVS connection synchronization。

(7)ARP Problem of LVS/TUN and LVS/DR：这个问题只在LVS/DR，LVS/TUN 时存在。

3. 配置实例

(1) 需要的软件包和包的安装：

I. piranha-gui-0.4.12-2*.rpm (GUI接口cluster设定工具);

II. piranha-0.4.12-2*.rpm;

III. ipchains-1.3.9-6lp*.rpm (架设NAT)。

取得套件或mount到光盘，进入RPMS目录进行安装:

# rpm -Uvh piranha*

# rpm -Uvh ipchains*

(2) real server群：

真正提供服务的server(如web
server)，在NAT形式下是以内部虚拟网域的形式，设定如同一般虚拟网域中Client端使用网域：192.168.10.0/24
架设方式同一般使用虚拟IP之局域网络。

a. 设网卡IP

real1 ：192.168.10.100/24

real2 ：192.168.10.101/24

b.每台server均将default gateway指向192.168.10.254。
192.168.10.254为该网域唯一对外之信道，设定在virtual server上，使该网域进出均需通过virtual server 。

c.每台server均开启httpd功能供web server服务，可以在各real server上放置不同内容之网页，可由浏览器观察其对各real
server读取网页的情形。

d.每台server都开启rstatd、sshd、rwalld、ruser、rsh、rsync，并且从Vserver上面拿到相同的lvs.conf文件。

(3) virtual server：

作用在导引封包的对外主机，专职负责封包的转送，不提供服务，但因为在NAT型式下必须对进出封包进行改写，所以负担亦重。

a.IP设置：

对外eth0：IP：10.0.0.1 eth0：0 ：10.0.0.2

对内eth1：192.168.10.1 eth1：0 ：192.168.10.254

NAT形式下仅virtual server有真实IP，real server群则为透过virtual server.

b.设定NAT功能

# echo 1 >; /proc/sys/net/ipv4/ip_forward

# echo 1 >; /proc/sys/net/ipv4/ip_always_defrag

# ipchains -P forward MASQ

c.设定piranha 进入X-window中 (也可以直接编辑/etc/lvs.cf )

a).执行面板系统piranha

b).设定“整体配置”(Global Settings) 主LVS服务器主机IP：10.0.0.2， 选定网络地址翻译(预设) NAT路径名称：
192.168.10.254， NAT 路径装置： eth1：0

c).设定虚拟服务器(Virtual Servers) 添加编辑虚拟服务器部分：(Virtual
Server)名称：(任意取名);应用：http;协议： tcp;连接：80;地址：10.0..0.2;装置：eth0：0; 重入时间：180
(预设);服务延时：10 (预设);加载监控工具：ruptime (预设);调度策略：Weighted least-connections; 持续性：0
(预设); 持续性屏蔽： 255.255.255.255 (预设); 按下激活：实时服务器部分：(Real Servers); 添加编辑：名字：(任意取名);
地址： 192.168.10.100; 权重：1 (预设) 按下激活

另一架real server同上，地址：192.168.10.101。

d). 控制/监控(Controls/Monitoring)
控制：piranha功能的激活与停止，上述内容设定完成后即可按开始键激活piranha.监控器：显示ipvsadm设定之routing table内容
可立即更新或定时更新。

(4)备援主机的设定(HA)

单一virtual server的cluster架构virtual server 负担较大，提供另一主机担任备援，可避免virtual
server的故障而使对外服务工作终止;备份主机随时处于预备状态与virtual server相互侦测

a.备份主机：

eth0： IP 10.0.0.3

eth1： IP 192.168.10.102 同样需安装piranha，ipvsadm，ipchains等套件

b.开启NAT功能(同上面所述)。

c.在virtual server(10.0.0.2)主机上设定。

a).执行piranha冗余度 ;

b).按下“激活冗余度”;

冗余LVS服务器IP： 10.0.0.3;HEARTBEAT间隔(秒数)： 2 (预设)

假定在…秒后进入DEAD状态： 5 (预设);HEARTBEAT连接端口： 539 (预设)

c).按下“套用”;

d).至“控制/监控”页，按下“在当前执行层添加PULSE DEAMON” ，按下“开始”;

e).在监控器按下“自动更新”，这样可由窗口中看到ipvsadm所设定的routing table，并且动态显示real
server联机情形，若real server故障，该主机亦会从监视窗口中消失。

d.激活备份主机之pulse daemon (执行# /etc/rc.d/init.d/pulse start)。

至此，HA功能已经激活，备份主机及virtual server由pulse daemon定时相互探询，一但virtual
server故障，备份主机立刻激活代替;至virtual server 正常上线后随即将工作交还virtual server。

LVS测试

经过了上面的配置步骤，现在可以测试LVS了，步骤如下：

1. 分别在vs1，real1，real2上运行/etc/lvs/rc.lvs_dr。注意，real1，real2上面的/etc/lvs
目录是vs2输出的。如果您的NFS配置没有成功，也可以把vs1上/etc/lvs/rc.lvs_dr复制到real1，real2上，然后分别运行。确保real1，real2上面的apache已经启动并且允许telnet。

2. 测试Telnet：从client运行telnet 10.0.0.2，
如果登录后看到如下输出就说明集群已经开始工作了：(假设以guest用户身份登录)

[guest@real1 guest]$——说明已经登录到服务器real1上。

再开启一个telnet窗口，登录后会发现系统提示变为：

[guest@real2 guest]$——说明已经登录到服务器real2上。

3. 测试http：从client运行iexplore http://10.0.0.2

因为在real1 和real2 上面的测试页不同，所以登录几次之后，显示出的页面也会有所不同，这样说明real server 已经在正常工作了。

⑵ 怎么实现服务器的负载均衡

负载均衡有两种含义：第一种，单个负载的运算分担到多台节点设备上做并行处理，每个节点设备处理结束后，将结果汇总，返回给用户，系统处理能力得到大幅度提高，也就是常说的集群（clustering）技术。第二种，大量的并发访问或数据流量分担到多台节点设备上分别处理，减少用户等待响应的时间，这主要针对Web服务器、FTP服务器、企业关键应用服务器等网络应用。通常，负载均衡会根据网络的不同层次（网络七层）来划分。其中，第二层的负载均衡指将多条物理链路当作一条单一的聚合逻辑链路使用，这就是链路聚合（Trunking）技术，它不是一种独立的设备，而是交换机等网络设备的常用技术。现代负载均衡技术通常操作于网络的第四层或第七层，这是针对网络应用的负载均衡技术，它完全脱离于交换机、服务器而成为独立的技术设备。
服务器实现负载均衡有软件和硬件两种方式
软件负载均衡的方式是在一台或多台服务器相应的操作系统上安装一个或多个应用软件来实现负载均衡，如DNS Load Balance，CheckPoint Firewall-1 ConnectControl等，它的优点是基于特定环境，配置简单，使用灵活，成本低廉，可以满足一般的负载均衡需求。缺点就是服务器上的软件本身就会消耗服务器系统不定量的资源，同时操作系统本身的原因，安全方面会有影响
硬件负载均衡的方法就是直接在服务器和外部网络间安装负载均衡设备，专由门的设备完成专门的任务，独立于操作系统，整体性能得到提高，加上多样化的负载均衡策略，智能化的流量管理，可达到负载均衡需求。
负载均衡具体有三种部署方式：路由模式、桥接模式、服务直接返回模式。
路由模式部署灵活，服务器的网关设置成负载均衡机的LAN口地址，且与WAN口分署不同的逻辑网络。因此所有返回的流量也都经过负载均衡。这种方式对网络的改动小，能均衡任何下行流量。
桥接模式配置简单，不改变现有网络。负载均衡的WAN口和LAN口分别连接上行设备和下行服务器。LAN口
不需要配置IP（WAN口与LAN口是桥连接），所有的服务器与负载均衡均在同一逻辑网络中。这种安装方式容错性差，网络架构缺乏弹性，对广播风暴及其他生成树协议循环相关联的错误敏感。
服务直接返回模式这种安装方式负载均衡的LAN口不使用，WAN口与服务器在同一个网络中，互联网的客户端访问负载均衡的虚IP（VIP），虚IP对应负载均衡机的WAN口，负载均衡根据策略将流量分发到服务器上，服务器直接响应客户端的请求。因此对于客户端而言，响应他的IP不是负载均衡机的虚IP（VIP），而是服务器自身的IP地址。也就是说返回的流量是不经过负载均衡的。因此这种方式适用大流量高带宽要求的服务。

⑶ 负载均衡是怎么做的~

1、服务直接返回：这种安装方式负载均衡的LAN口不使用，WAN口与服务器在同一个网络中，互联网的客户端访问负载均衡的虚IP（VIP），虚IP对应负载均衡机的WAN口，负载均衡根据策略将流量分发到服务器上，服务器直接响应客户端的请求。

2、桥接模式：桥接模式配置简单，不改变现有网络。负载均衡的WAN口和LAN口分别连接上行设备和下行服务器。LAN口不需要配置IP（WAN口与LAN口是桥连接），所有的服务器与负载均衡均在同一逻辑网络中。

3、路由模式：路由模式的部署方式，服务器的网关必须设置成负载均衡机的LAN口地址，且与WAN口分署不同的逻辑网络。因此所有返回的流量也都经过负载均衡。这种方式对网络的改动小，能均衡任何下行流量。

(3)均衡负载服务器部署什么地方扩展阅读

负载均衡的算法:

1、随机算法：Random随机，按权重设置随机概率。在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。

2、哈希算法：一致性哈希一致性Hash，相同参数的请求总是发到同一提供者。当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。

3、URL散列：通过管理客户端请求URL信息的散列，将发送至相同URL的请求转发至同一服务器的算法。

参考资料

网络-负载均衡

⑷ 如何安装nginx负载均衡配置详解

负载均衡
先来简单了解一下什么是负载均衡，单从字面上的意思来理解就可以解释N台服务器平均分担负载，不会因为某台服务器负载高宕机而某台服务器闲置的情况。那么负载均衡的前提就是要有多台服务器才能实现，也就是两台以上即可。
测试环境
由于没有服务器，所以本次测试直接host指定域名，然后在VMware里安装了三台CentOS。
测试域名 ：a.com
A服务器IP ：192.168.5.149 （主）
B服务器IP ：192.168.5.27
C服务器IP ：192.168.5.126
部署思路
A服务器做为主服务器，域名直接解析到A服务器（192.168.5.149）上，由A服务器负载均衡到B服务器（192.168.5.27）与C服务器（192.168.5.126）上。

域名解析
由于不是真实环境，域名就随便使用一个a.com用作测试，所以a.com的解析只能在hosts文件设置。
打开：C:
在末尾添加
192.168.5.149 a.com
保存退出，然后启动命令模式ping下看看是否已设置成功

从截图上看已成功将a.com解析到192.168.5.149IP
A服务器nginx.conf设置
打开nginx.conf，文件位置在nginx安装目录的conf目录下。
在http段加入以下代码
upstream a.com {
server 192.168.5.126:80;
server 192.168.5.27:80;
}

server{
listen 80;
server_name a.com;
location / {
proxy_pass http://a.com;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
保存重启nginx
B、C服务器nginx.conf设置
打开nginx.confi，在http段加入以下代码
server{
listen 80;
server_name a.com;
index index.html;
root /data0/htdocs/www;
}
保存重启nginx
测试
当访问a.com的时候，为了区分是转向哪台服务器处理我分别在B、C服务器下写一个不同内容的index.html文件，以作区分。
打开浏览器访问a.com结果，刷新会发现所有的请求均分别被主服务器（192.168.5.149）分配到B服务器（192.168.5.27）与C服务器（192.168.5.126）上，实现了负载均衡效果。
B服务器处理页面

C服务器处理页面

假如其中一台服务器宕机会怎样？
当某台服务器宕机了，是否会影响访问呢？
我们先来看看实例，根据以上例子，假设C服务器192.168.5.126这台机子宕机了（由于无法模拟宕机，所以我就把C服务器关机）然后再来访问看看。
访问结果：

我们发现，虽然C服务器（192.168.5.126）宕机了，但不影响网站访问。这样，就不会担心在负载均衡模式下因为某台机子宕机而拖累整个站点了。
如果b.com也要设置负载均衡怎么办？
很简单，跟a.com设置一样。如下：
假设b.com的主服务器IP是192.168.5.149，负载均衡到192.168.5.150和192.168.5.151机器上
现将域名b.com解析到192.168.5.149IP上。
在主服务器(192.168.5.149)的nginx.conf加入以下代码：
upstream b.com {
server 192.168.5.150:80;
server 192.168.5.151:80;
}

server{
listen 80;
server_name b.com;
location / {
proxy_pass http://b.com;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
保存重启nginx
在192.168.5.150与192.168.5.151机器上设置nginx，打开nginx.conf在末尾添加以下代码：
server{
listen 80;
server_name b.com;
index index.html;
root /data0/htdocs/www;
}
保存重启nginx
完成以后步骤后即可实现b.com的负载均衡配置。
主服务器不能提供服务吗？
以上例子中，我们都是应用到了主服务器负载均衡到其它服务器上，那么主服务器本身能不能也加在服务器列表中，这样就不会白白浪费拿一台服务器纯当做转发功能，而是也参与到提供服务中来。
如以上案例三台服务器：
A服务器IP ：192.168.5.149 （主）
B服务器IP ：192.168.5.27
C服务器IP ：192.168.5.126
我们把域名解析到A服务器，然后由A服务器转发到B服务器与C服务器，那么A服务器只做一个转发功能，现在我们让A服务器也提供站点服务。
我们先来分析一下，如果添加主服务器到upstream中，那么可能会有以下两种情况发生：
1、主服务器转发到了其它IP上，其它IP服务器正常处理；
2、主服务器转发到了自己IP上，然后又进到主服务器分配IP那里，假如一直分配到本机，则会造成一个死循环。
怎么解决这个问题呢？因为80端口已经用来监听负载均衡的处理，那么本服务器上就不能再使用80端口来处理a.com的访问请求，得用一个新的。于是我们把主服务器的nginx.conf加入以下一段代码：
server{
listen 8080;
server_name a.com;
index index.html;
root /data0/htdocs/www;
}

重启nginx，在浏览器输入a.com:8080试试看能不能访问。结果可以正常访问

既然能正常访问，那么我们就可以把主服务器添加到upstream中，但是端口要改一下，如下代码：
upstream a.com {
server 192.168.5.126:80;
server 192.168.5.27:80;
server 127.0.0.1:8080;
}
由于这里可以添加主服务器IP192.168.5.149或者127.0.0.1均可以，都表示访问自己。
重启Nginx，然后再来访问a.com看看会不会分配到主服务器上。

⑸ 负载均衡基本介绍

【负载均衡架构部分转自】 58沈剑 [架构师之路]( https://mp.weixin.qq.com/s

负载均衡： 是分布式系统架构设计中必须考虑的因素之一，它通常是指，将请求/数据【均匀】分摊到多个操作单元上执行，负载均衡的关键在于【均匀】
常见的负载均衡方案：

【客户端层】到【反向代理层】的负载均衡，是通过“DNS轮询”实现的：DNS-server对于一个域名配置了多个解析ip，每次DNS解析请求来访问DNS-server，会轮询返回这些ip，保证每个ip的解析概率是相同的。这些ip就是nginx的外网ip，以做到每台nginx的请求分配也是均衡的。

【反向代理层】到【站点层】的负载均衡，是通过“nginx”实现的。通过修改nginx.conf，可以实现多种负载均衡策略：

【站点层】到【服务层】的负载均衡，是通过“服务连接池”实现的。
上游连接池会建立与下游服务多个连接，每次请求会“随机”选取连接来访问下游服务。（也即是rpc框架实现的）

在数据量很大的情况下，由于数据层（db，cache）涉及数据的水平切分，所以数据层的负载均衡更为复杂一些，它分为“数据的均衡”，与“请求的均衡”。
数据的均衡是指 ：水平切分后的每个服务（db，cache），数据量是差不多的。
请求的均衡是指 ：水平切分后的每个服务（db，cache），请求量是差不多的。
（1）按照range水平切分

（2）按照id哈希水平切分

[图片上传中...(-6b2508-1561902875888-0)]

常见的负载均衡系统包括 3 种：DNS 负载均衡、硬件负载均衡和软件负载均衡。

硬件负载均衡是通过单独的硬件设备来实现负载均衡功能，这类设备和路由器、交换机类似，可以理解为一个用于负载均衡的基础网络设备。比如业界非常出名的F5

缺点：
（1）价格实在非常昂贵
（2）扩展性不强

软件负载均衡通过负载均衡软件来实现负载均衡功能，常见的有 Nginx 和 LVS。

nginx和F5： https://blog.csdn.net/chabale/article/details/8956717
nginx和lvs比较： https://blog.51cto.com/hzcto/2086691
lvs： https://www.cnblogs.com/liwei0526vip/p/6370103.html
ELB： https://aws.amazon.com/cn/elasticloadbalancing/
SLB： https://help.aliyun.com/proct/27537.html

题目：日活跃用户 1000 万的论坛的负载均衡集群，该如何设计呢？
（1）评估流量
1000万DAU，换算成秒级（一天12小时），平均约等于232。
考虑每个用户操作次数，假定10，换算成平均QPS=2320。
考虑峰值是均值倍数，假定5，换算成峰值QPS=11600。
考虑静态资源、图片资源、服务拆分等，流量放大效应，假定10，QPS 10=116000。
（2）容量规划
考虑高可用、异地多活，QPS 2=232000。
考虑未来半年增长，QPS*1.5=348000。
（3）方案设计
可以用三级导流：
第一级，DNS，确定机房，以目前量级，可以不考虑。
第二级，确定集群，扩展优先，则选Haproxy/LVS，稳定优先则选F5。
第三级，Nginx+KeepAlived，确定实例。
（4）架构图

接入层技术：

缺点：

优点：

缺点：

优点：

缺点：

缺点：

nginx毕竟是软件，性能比tomcat好，但总有个上限，超出了上限，还是扛不住。lvs就不一样了，它实施在操作系统层面；f5的性能又更好了，它实施在硬件层面；它们性能比nginx好很多，例如每秒可以抗10w，这样可以利用他们来扩容。

99.9999%的公司到这一步基本就能解决接入层高可用、扩展性、负载均衡的问题。 假设还扛不住的话，就要考虑使用硬件设备f5等。如果还是扛不住，那么只有DNS来扩容了。

水平扩展，才是解决性能问题的根本方案，能够通过加机器扩充性能的方案才具备最好的扩展性。 facebook，google，的PV是不是超过80亿呢，它们的域名只对应一个ip么，终点又是起点，还是得通过DNS轮询来进行扩容：

比如购买了阿里云或者aws。那么基本会使用云厂商提供的负载均衡中间件，比如aws（elb）、阿里云（slb）。这个负载均衡软件可以认为是 lvs+keepalived的高可用负载均衡服务

后端的service有可能部署在硬件条件不同的服务器上：
1）如果对标最低配的服务器“均匀”分摊负载，高配的服务器的利用率不足；
2）如果对标最高配的服务器“均匀”分摊负载，低配的服务器可能会扛不住；

（1）通过“静态权重”标识service的处理能力

优点： 简单，能够快速的实现异构服务器的负载均衡。
缺点： 权重是固定的，无法自适应动态调整，而很多时候，服务器的处理能力是很难用一个固定的数值量化。

（2）通过“动态权重”标识service的处理能力
提问：通过什么来标识一个service的处理能力呢？
回答：其实一个service能不能处理得过来，能不能响应得过来，应该由调用方说了算。调用服务，快速处理了，处理能力跟得上；调用服务，处理超时了，处理能力很有可能跟不上了。

动态权重设计：

例如：

（1）设置一个阈值，超过阈值直接丢弃

（2）借助“动态权重”来实施过载保护
案例策略：

1）service的负载均衡、故障转移、超时处理通常是RPC-client连接池层面来实施的
2）异构服务器负载均衡，最简单的方式是静态权重法，缺点是无法自适应动态调整
3）动态权重法，可以动态的根据service的处理能力来分配负载，需要有连接池层面的微小改动
4）过载保护，是在负载过高时，service为了保护自己，保证一定处理能力的一种自救方法
5）动态权重法，还可以用做service的过载保护