看“软硬兼施”的负载均衡如何突破性能瓶颈

　负载均衡遭遇业务新挑战

　　仅仅一个新浪微博，就有超过5亿的用户。访问量早就成为了天文数字。为改善使用体验、提升网络性能，新浪于2004年左右在国内最早使用负载均衡设备NetScaler，2007年新浪与F5公司达成全方位战略合作。但是，随着新浪微博等新兴应用的推出商业设备的性价比和供货时间长无法满足业务的快速部署。而且当微博等线上业务出现访问异常或故障时，单纯依靠成本高昂的专业负载均衡设备提供的CPU、内存、连接数等统计信息，并不足以让工程师掌握服务器及应用状态，不能满足现代互联网发展对低成本、大并发的要求。

　　像新浪这样一个24小时运转的互联网企业，面对在没有专门运维时间、停机升级时间的情况下，如何能够突破负载均衡器的性能瓶颈，保证网络流量处理能力，保障数据传输的可靠性、实时性，成为新浪在业务发展过程中迫切需要解决的问题。

　　软硬联合 突破性能瓶颈

　　在互联网行业，软件定义赋予了用户极大业务灵活性和自主能力。由于自己开发软件在节省成本的同时能够更加切合公司的业务，提高故障响应度，并有效解决大规模部署的问题，因此从2006年开始，新浪尝试向基于x86架构的开源负载均衡软件转移，即在Linux操作系统下，通过Haproxy实现对七层负载均衡的优化。

　　使用初期，机房中的灵活部署以及每年1100万-2000万元的成本节省让新浪真切的感受到了Haproxy实际优势。由于负载均衡软件的性能与服务器CPU、网卡等硬件直接相关，而英特尔提供的硬件产品，可以结合新浪的需求，增添、去掉其中的一些功能，与新浪“灵活方便”的需求不谋而合，因此，在专注于软件开发的同时，新浪也与英特尔展开了紧密的合作。“英特尔为我们提供了相关的设备和万兆网卡，让我们在英特尔-新浪联合实验室中做了相关测试。除了产品层面，在CPU及网卡的参数和使用上，英特尔也为我们提供了技术上的帮助，”新浪高级架构师林晓峰说道“英特尔的同事会根据我们提出的问题，在全球集团、公司去

可以实现，就用win2003的负载平衡就可以。我的空间有做负载平衡的文章，你去看看吧。

http://hibaiducom/laojiangjun/blog/category/%B8%BA%D4%D8%BE%F9%BA%E2/index/0

看你的要求应该是检测两个服务器，如果a服务器出现问题，可以切换到b服务器，原理来说就是服务器A、B的双网卡负载均衡，然后两台服务器在做双机互备。第一步应该是把两个服务器的双网卡负载均衡，然后再配置keepalived 做双机互备。给你个百度文库参考吧

http://wenkubaiducom/view/06e497868762caaedd33d469html

比如你弄一网站假设你有能力购买2台服务器作为WEB服务暂时我们认为服务器本身不存在性能问题一台托管在北方的网通机房一台托管在南方的电信机房2台服务器内容互为同步则通过智能的DNS解析设备将网通的用户定位到北方网通的服务器上将电信的用户定位到南方电信的服务器上这就是最基础的CDN我的理解是 ---广域网的负载均衡

2台服务器放置问题我不想多谈有钱就行2台服务器内容同步的方式很多我也不想多谈今天主要是要谈一下如何实现让网通的用户去访问放置在网通的服务器电信的用户去访问放置在电信的服务器

即如今很多服务提供商所谓的智能DNS解析也就是互联网链路的负载均衡

电信/网通2条链路的负载均衡我们先来谈谈这个因为这个是访问者最直观的体验

既然CDN的目的是为了提高用户访问网站的响应速度最直接的方法就是做互联网链路的智能导向

当然CDN也涉及多台服务器负载均衡应用的负载均衡包括中间件的应用负载均衡因为时间关系暂且不表

当我们将 wwwBlueideacom 输入IE地址栏敲回车后首先要去你的Local DNS做解析什么是Local DNS就是你本机网卡所设置的DNS服务器比如我的是: 2029612868如果Local DNS没有 wwwBluieideacom 的Cache记录则Local DNS会询问上级DNS服务器注意DNS的查询结构是树状的最后查询的DNS为root即为root DNS或者称为根DNS根DNS在全世界只有13台中国境内没有当root DNS接受到请求后通过查询获得的结果一般是: Blueideacom这个域的解析服务器为ns1chinadnscom要求你去询问ns1chinadnscom去做解析ns1chinadnscom是哪里来的当然是你申请注册域名的机构自己的DNS服务器也就是你Blueideacom这个域名的隶属DNS隶属DNS获得了你域名解析的请求则查询A记录返回Blueideacom的IP地址给最初的PC Client端完成了一次域名解析为IP地址的全部过程

虽然很绕但是如果能搞明白那才能理解下面的关于智能DNS的技术原理

上述DNS查询的常规流程基本上就是如下图:

PC -> Local DNS -> Root DNS -> ns1chinadnscom -> IP -> 返回给PC

智能DNS的工作原理即是在ns1chinadnscom这一步工作流程如下:

PC -> Local DNS -> Root DNS -> 智能DNS解析 -> 返回IP地址 -> 返回给PC

注意上述的返回IP地址这一步其实是根据PC的来源智能的返回电信或者网通的IP地址即如果请求解析的PC是电信线路的则返回托管在南方电信机房的服务器的电信IP地址反之则返回托管在北方网通机房的网通的IP地址

看到这里出现了一个问题如何判断这个请求DNS的PC他是电信线路还是网通线路呢

有2个方法一个聪明的一个笨的我们先说笨的方法如果智能DNS有一张庞大的IP地址分配表表里面有所有的电信IP地址段和所有的网通地址段则可以通过查询这个IP地址表来判断请求的PC是属于哪个线路上的这个方法是最直接最高效最稳妥的方法虽然的确是笨了点但是请各位注意往往笨的方法就代表着稳定代表着高可用性所以我很遗憾的告诉大家基本上银行证券金融这些重要部门都是使用的这种笨的方法

另外一个聪明的方法则是通过智能的动态检测的方法在智能DNS解析设备接受到PC的DNS请求的时候将使用电信/网通的2条线路分别发送一个探测包发送目标可以为目标PC的IP地址不过更多的发送目标为Local DNS这个包可能是ICMP的PING包也可能是反向DNS查询的DNS包(TCP 53)当2个包有回应后比较2个包的时间戳延迟小的则判定为优先解析的链路

1、本机到服务器之间路由跳数过多。由于光/电的传输速度非常快，他们在物理介质中的传播时间几乎可以忽略不计，但是路由器转发数据包的处理时间是不可忽略的。当本机到服务器链路中有太多路由转发处理时，网络延时就会很明显。

2、网络带宽不够。排除其它因素，如果客户端和服务器端直接通过一个路由器连接，但带宽只有10Kbps，却同时有多个应用需要传输远超带宽的数据量200Kbps，这时候会造成大量数据丢失，从而表现为响应延时。

3、处理带宽不够。排除其它因素，如果客户端和服务器端直接通过一个路由器连接，且带宽足够，但服务器端处理能力不足，也会造成响应延时。

解决方法：

1、提升WAN性能

企业可以细致控制LAN内的应用程序性能，但这种控制能力无法延伸到广域网上。WAN通常会有多个可选的服务提供商，他们经营着运营商级的顶级骨干基础设施。通过选择较短和更有效率的路由路径、部署低延迟的交换机和路由设备、主动避免网络设备停机时间，WAN运营商也可以对降低延迟作出贡献。

增加WAN带宽能提高应用程序的性能，但带宽并不便宜，通常也不必这么干。在实践中，运用能够更有效利用现有WAN带宽的各种技术同样可以提升WAN应用程序的性能。这些技术被统称为广域网加速器。加速器的功能通过减少数据有效负载和更有效地利用现有的WAN带宽来实现。

2、修复LAN上应用性能

如果一个刚安装或修改过设置的应用程序出现了本地网络性能问题，请尝试核查该应用程序的设置、系统兼容性和软件状态；另外也应审查安装和设置文档。硬件兼容性也会影响局域网效率。在某些情况下，更新或补丁程序可能逆转原本很糟糕的性能表现。

3、工作负载均衡，在服务器之间移动虚拟机，优化每个物理主机的应用程序工作负载和带宽需求。

数据中心还可以考虑将服务器的网卡换成10千兆或者更快速的型号，或为陷入困境的高带宽应用单独安装专用的网络适配器。当然，更快的NIC可能非常昂贵，安装物理部件的过程要求服务器脱机，并且通常还会增加局域网交换基础设施的配套成本。

扩展资料

网络延迟程度：（网络延迟PING值越低速度越快）

1~30ms：极快，几乎察觉不出有延迟，玩任何游戏速度都特别顺畅；

31~50ms：良好，可以正常游戏，没有明显的延迟情况；

51~100ms：普通，对抗类游戏在一定水平以上能感觉出延迟，偶尔感觉到停顿；

100ms~200ms：较差，无法正常游玩对抗类游戏，有明显卡顿，偶尔出现丢包和掉线现象；

200ms~500ms：很差，访问网页有明显的延迟和卡顿，经常出现丢包或无法访问；

>500ms：极差，难以接受的延迟和丢包，甚至无法访问网页；

>1000ms：基本无法访问；

计算方法：1秒=1000毫秒（例：30ms为003秒）。

-网络延迟

-网络延时

你说的ETH1流量很小是多小，如果是多少K肯定不对，如果有几M，几十兆的话应该没什么问题。你想看到bond0这个汇聚口的IP的话，你可以试一下CACTI等监控软件，但是我也不知道这种汇聚口能否读出来。

CentOS双网卡绑定的模式一共有7种（即mode=0、1、2、3、4、5、6）：

0 （balance-rr模式）网卡的负载均衡模式。特点：（1）所有链 路处于负载均衡状态，轮询方式往每条链路发送报文，基于per packet方式发送。服务上ping 一个相同地址：1111 双网卡的两个网卡都有流量发出。负载到两条链路上，说明是基于per packet方式 ，进行轮询发送。（2）这模式的特点增加了带宽，同时支持容错能力，当有链路出问题，会把流量切换到正常的链路上。

1 （active-backup模式）网卡的容错模式。 特点：一个端口处于主状态 ，一个处于从状态，所有流量都在主链路上处理，从不会有任何流量。当主端口down掉时，从端口接手主状态。

2 （balance-xor模式）需要交换机支持。特点：该模式将限定 流量，以保证到达特定对端的流量总是从同一个接口上发出。既然目的地是通过MAC地址来决定的，因此该模式在“本地”网络配置下可以工作得很好。如果所有 流量是通过单个路由器（比如 “网关”型网络配置，只有一个网关时，源和目标mac都固定了，那么这个算法算出的线路就一直是同一条，那么这种模式就没有多少意义了。），那该模式就不 是最好的选择。和balance-rr一样，交换机端口需要能配置为“port channel”。这模式是通过源和目标mac做hash因子来做xor算法来选路的。

3 （broadcast模式）。特点:这种模式的特点是一个报文会复制两份往bond下的两个接口分别发送出去,当有对端交换机失效，我们感觉不到任何downtime,但此法过于浪费资源;不过这种模式有很好的容错机制。此模式适用于金融行业，因为他们需要高可靠性的网络，不允许出现任何问题。

4 （IEEE 8023ad动态链路聚合模式）需要交换机支持。特 点：8023ad模式是IEEE标准，因此所有实现了8023ad的对端都可以很好的互操作。8023ad 协议包括聚合的自动配置，因此只需要很少的对交换机的手动配置（要指出的是，只有某些设备才能使用8023ad）。8023ad标准也要求帧按顺序 （一定程度上）传递，因此通常单个连接不会看到包的乱序。8023ad也有些缺点：标准要求所有设备在聚合操作时，要在同样的速率和双工模式，而且，和 除了balance-rr模式外的其它bonding负载均衡模式一样，任何连接都不能使用多于一个接口的带宽。此外，linux bonding的8023ad实现通过对端来分发流量（通过MAC地址的XOR值），因此在“网关”型配置下，所有外出（Outgoing）流量将使用 同一个设备。进入（Incoming）的流量也可能在同一个设备上终止，这依赖于对端8023ad实现里的均衡策略。在“本地”型配置下，路两将通过 bond里的设备进行分发。

5 自适应传输负载均衡模式。特 点：balance-tlb模式通过对端均衡外出（outgoing）流量。既然它是根据MAC地址进行均衡，在“网关”型配置（如上文所述）下，该模式 会通过单个设备来发送所有流量，然而，在“本地”型网络配置下，该模式以相对智能的方式（不是balance-xor或8023ad模式里提及的XOR 方式）来均衡多个本地网络对端，因此那些数字不幸的MAC地址（比如XOR得到同样值）不会聚集到同一个接口上。

不像8023ad，该模式的接口可以有不同的速率，而且不需要特别的交换机配置。不利的一面在于，该模式下所有进入的（incoming）流量会到达同一个接口；该模式要求slave接口的网络设备驱动有某种ethtool支持；而且ARP监控不可用。

6 网卡虚拟化方式。特点：该模式包含了balance-tlb模式，同时加上针对IPV4流量的接收负载均衡(receive load balance, rlb)，而且不需要任何switch(交换机)的支持。接收负载均衡是通过ARP协商实现的。bonding驱动截获本机发送的ARP应答，并把源硬件 地址改写为bond中某个slave的唯一硬件地址，从而使得不同的对端使用不同的硬件地址进行通信。所有端口都会收到对端的arp请求报文，回复arp 回时，bond驱动模块会截获所发的arp回复报文，根据算法算到相应端口，这时会把arp回复报文的源mac，send源mac都改成相应端口mac。 从抓包情况分析回复报文是第一个从端口1发，第二个从端口2发。以此类推。

具体选择哪种要根据自己需要和交换机情况定，一般Mode=0和Mode=1比较常见；Mode=6负载均衡方式，两块网卡都工作，不需要交换机支持，也常用