xxxx应用负载均衡设计方案v1.docx

xxxx应用负载均衡设计方案v1.docx

《xxxx应用负载均衡设计方案v1.docx》由会员分享，可在线阅读，更多相关《xxxx应用负载均衡设计方案v1.docx（46页珍藏版）》请在冰点文库上搜索。

xxxx应用负载均衡设计方案v1

XXXX

应用负载均衡设计方案建议

2006-1

一、XXXX应用交付现有问题分析

随着XXXX的业务量的增加，XXXX的业务网站的访问量也以几何级的速度增长。

业务网站的应用交付遇到了以下的问题：

1．需要有支持应用的负载均衡产品，具备多种负载均衡算法。

2．能够做到根据各个Web服务器的性能，合理地分配服务器群中的每台机器所要处理的请求。

3．能够及时的发现群中的某台机器当掉，从而不对此机器发送请求。

当掉机器恢复正常后，自动进行业务处理。

4．可以应对大量的服务访问；至少2,000,000条的TCP同时并发连接，至少每秒建立100,000条连接。

5．有效直观的监控统计界面，包含当前时刻、过去一段时间的请求数量统计、性能统计、会话时间统计。

6．为个人业务提供SSL加密服务，可以将服务器SSL加/解密前移，并提供高效的https加/解密性能。

7．能够提供有效的机制缓解后台应用中间键服务器压力，提高业务的访问量。

二、方案建议

针对上一节提出的需求分析，F5公司充分考虑XXXX现有的实际状况，结合F5公司在国际上网络优化案例的经验，总结出以下应用交付优化设计方案。

方案采用F5公司的新一代LTM应用交换机BIGIP3400,提供后台Web服务器集群的负载均衡；同时，采用另两台BIGIP3400设备提供后台中间键服务器负载均衡，并减轻中间键服务器的压力。

在负责实现Web服务器负载均衡的BIG-IP3400上设置两个Vlan,分别是ExternalVlan负责连接外部的防火墙系统,InternalVlan负责连接内部Web服务器集群。

并且在该对BIG-IP3400上，分别采用SSL加速模块帮助后台Web服务器实现业务的加密处理；还采用了动态智能压缩模块帮助XXXX在有限的带宽下实现访问速度的提高和访问量的增大。

在负责实现内部中间键服务器负载均衡的BIG-IP3400也设置两个Vlan，分别是ExternalVlan负责连接外部的Web服务器集群,InternalVlan负责连接内部中间键服务器集群。

并且在该对BIG-IP3400上，采用One-Connection技术降低后台中间键服务器集群的负载。

BIG-IP3400提供所有应用的负载均衡，并实时监控各台服务器的状态，自动屏蔽故障服务器，从而确保系统稳定工作。

同时，由于采用F5特有的动态攻击防御系统，BIP-IP3400对恶意的海量攻击具有很强的抵御能力，确保了服务器和服务的正常运作。

1.服务器负载均衡

BIG/IP利用虚拟IP地址（VIP由IP地址和TCP/UDP应用的端口组成，它是一个地址）来为用户的一个或多个目标服务器（称为节点：

目标服务器的IP地址和TCP/UDP应用的端口组成，它可以是internet的私网地址）提供服务。

因此，它能够为大量的基于TCP/IP的网络应用提供服务器负载均衡服务。

BIG/IP连续地对目标服务器进行L4到L7合理性检查，当用户通过VIP请求目标服务器服务时，BIG/IP根椐目标服务器之间性能和网络健康情况，选择性能最佳的服务器响应用户的请求。

如果能够充分利用所有的服务器资源，将所有流量均衡的分配到各个服务器，我们就可以有效地避免“不平衡”现象的发生。

BIGIP是一台对流量和内容进行管理分配的设备。

它提供12种灵活的算法将数据流有效地转发到它所连接的服务器群。

而面对用户，只是一台虚拟服务器。

用户此时只须记住一台服务器，即虚拟服务器。

但他们的数据流却被BIGIP灵活地均衡到所有的服务器。

这12种算法包括：

●轮询（RoundRobin）：

顺序循环将请求一次顺序循环地连接每个服务器。

当其中某个服务器发生第二到第7层的故障，BIG/IP就把其从顺序循环队列中拿出，不参加下一次的轮询，直到其恢复正常。

●比率（Ratio）：

给每个服务器分配一个加权值为比例，根椐这个比例，把用户的请求分配到每个服务器。

当其中某个服务器发生第二到第7层的故障，BIG/IP就把其从服务器队列中拿出，不参加下一次的用户请求的分配，直到其恢复正常。

●优先权（Priority）：

给所有服务器分组，给每个组定义优先权，BIG/IP用户的请求，分配给优先级最高的服务器组（在同一组内，采用轮询或比率算法，分配用户的请求）；当最高优先级中所有服务器出现故障，BIG/IP才将请求送给次优先级的服务器组。

这种方式，实际为用户提供一种热备份的方式。

●最少的连接方式（LeastConnection）：

传递新的连接给那些进行最少连接处理的服务器。

当其中某个服务器发生第二到第7层的故障，BIG/IP就把其从服务器队列中拿出，不参加下一次的用户请求的分配，直到其恢复正常。

●最快模式（Fastest）：

传递连接给那些响应最快的服务器。

当其中某个服务器发生第二到第7层的故障，BIG/IP就把其从服务器队列中拿出，不参加下一次的用户请求的分配，直到其恢复正常。

●观察模式（Observed）：

连接数目和响应时间以这两项的最佳平衡为依据为新的请求选择服务器。

当其中某个服务器发生第二到第7层的故障，BIG/IP就把其从服务器队列中拿出，不参加下一次的用户请求的分配，直到其恢复正常。

●预测模式（Predictive）：

BIG/IP利用收集到的服务器当前的性能指标，进行预测分析，选择一台服务器在下一个时间片内，其性能将达到最佳的服务器相应用户的请求。

（被big/IP进行检测）

●动态性能分配（DynamicRatio-APM）:

BIG/IP收集到的应用程序和应用服务器的各项性能参数，动态调整流量分配。

●动态服务器补充（DynamicServerAct.）:

当主服务器群中因故障导致数量减少时，动态地将备份服务器补充至主服务器群。

●服务质量（QoS）：

按不同的优先级对数据流进行分配。

●服务类型（ToS）：

按不同的服务类型（在TypeofField中标识）对数据流进行分配。

●规则模式：

针对不同的数据流设置导向规则，用户可自行编辑流量分配规则，BIG/IP利用这些规则对通过的数据流实施导向控制。

当出现流量“峰值”时，如果能调配所有服务器的资源同时提供服务，所谓的“峰值堵塞”压力就会由于系统性能的大大提高而明显减弱。

由于BIGIP优秀的负载均衡能力，所有流量会被均衡的转发到各个服务器，即组织所有服务器提供服务。

这时，系统性能等于所有服务器性能的总和，远大于流量“峰值”。

这样，即缓解了“峰值堵塞”的压力，又降低了为调整系统性能而增加的投资。

BIG/IP®提供了基于应用的七层交换技术,可以根据任意制订的规则将用户的访问导向到不同的服务器群组,例如,IP地址,TCPport,Cookies,Httpheader中的任何标识（IEversion,domain,httpURI,filetype,langrage）.

2.服务器健康检查

BIG-IP®控制器将标准的第二层至第三层网络技术与创新的第四层至第七层流量管理结合在一起，从而大幅度提高了现有web服务器和网络的容量。

支持OSI模型二到七层的healthchecking。

特别是EAV和ECV功能：

基础网络检查Ping

四层应用检查TCP/UDPport

扩展内容查证ECV

ECV是一种非常复杂的服务检查，主要用于确认应用程序能否对请求返回对应的数据。

如果一个应用对该服务检查做出响应并返回对应的数据，则BIG/IP®控制器将该服务器标识为工作良好。

如果服务器不能返回相应的数据，则将该服务器标识为宕机。

宕机一旦修复，BIG/IP®就会自动查证应用已能对客户请求作出正确响应并恢复向该服务器传送。

该功能使BIG/IP®可以将保护延伸到后端应用,如Web内容及数据库。

BIG/IP®的ECV功能允许您向Web服务器、防火墙、缓存服务器、代理服务器和其它透明设备发送查询，然后检查返回的响应。

这将有助于确认您为客户提供的内容正是其所需要的。

扩展应用验证EAV

EAV是另一种服务检查，用于确认运行在某个服务器上的应用能否对客户请求作出响应。

为完成这种检查，BIG/IP®控制器使用一个被称作外部服务检查者的客户程序，该程序为BIG/IP®提供完全客户化的服务检查功能，但它位于BIG/IP®控制器的外部。

例如，该外部服务检查者可以查证一个Internet或Intranet上的从后台数据库中取出数据,并在HTML网页上显示的应用能否正常工作。

EAV是BIG/IP®提供的非常独特的功能，它提供管理者将BIG/IP®客户化后访问各种各样应用的能力，该功能使BIG/IP®在提供标准的可用性查证之外能获得服务器、应用及内容可用性等最重要的反馈。

该功能对于电子商务和其它应用至关重要,它用于从客户的角度测试您的站点。

例如，您可以模拟客户完成交易所需的所有步骤－连接到站点、从目录中选择项目以及验证交易使用的信用卡。

一旦BIG/IP®掌握了该“可用性”信息，即可利用负载平衡使资源达到最高的可用性。

BIG/IP®已经为测试Internet服务的健康情况和状态，预定义的扩展应用验证（EAV），它有二种用户界面：

浏览器和CLI配置。

BIG/IP®预定义的应用检查：

FTP、NNTP、SMTP、POP3和MSSQL。

3.与应用紧密结合的会话保持

BIG/IP控制器经过专门设计，可以为关键业务站点提供高可用性和智能负载平衡。

除这些能力外，它经过配置还可以识别用户固定访问特定服务器的要求，以支持用户重新建立到特定服务器的连接。

在这些条件下，BIG/IP控制器会放弃负载平衡算法以支持对话持续性。

在大多数厂商只能提供非SSL持续性时，F5Networks已经可以提供6种持续性模式：

源、服务器、VIP、SSL、Cookie持续性和目的地址相似性。

凭借这些选项，BIG/IP可以随时准备满足您特殊的网络要求。

以下是对各种模式的简要说明。

●源持续性模式

最终用户请求

连接到：

BIG-IP应用交换机的任务：

1）虚拟服务器#1

VIP1：

80

BIG-IP应用交换机将为该虚拟服务器选择一台可用的服务器。

来自源地址的VIP1：

80流量将流至该服务器，直到计时停止为止。

2）虚拟服务器#2

VIP2：

21（FTP）

BIG-IP应用交换机将为该虚拟服务器选择一台可用的服务器。

来自源地址的VIP2：

21流量将流至该服务器，直到计时停止为止。

3）虚拟服务器#3

VIP3：

80

BIG-IP应用交换机将为该虚拟服务器选择一台可用的服务器（不一定是与VIP1：

80相同的那台服务器）。

来自源地址的VIP3：

80流量将流至该服务器，直到计时停止为止。

VIP1：

80流量将继续流至其它服务器。

在这一模式下，只要持续性计数器尚未到时，指定流向某虚拟服务器的特定用户流量就会持续流向同一台服务器。

每条连接都有其各自的持续性计数器。

VIP1：

80的计数器独立于VIP3：

80的计数器。

●服务器持续性模式

最终用户请求

连接到：

BIG-IP应用交换机的任务：

1）虚拟服务器#1

VIP1:

80

BIG-IP应用交换机将为该虚拟服务器选择一台可用的服务器。

来自该源地址的流量将流至该服务器，直到计时停止为止。

2）虚拟服务器#2

VIP2:

21（FTP）

BIG-IP应用交换机将试着将用户连接到步骤#1中所用的那台服务器上。

3）虚拟服务器#3

VIP3:

8001

如果持续性计数器尚未到时，该服务器被定义为虚拟服务器#3的服务器，那么无论来自哪个虚拟地址，用户都将被连接至同一台服务器。

在该模式下，无论使用哪一台虚拟服务器，特定用户流量都将流向同一台服务器，除非持续性计时器到时，以前被连接到某台服务器上的用户将被连接到一台不包含该特定服务器的新虚拟服务器上。

这时，BIG-IP应用交换机将为这台新的虚拟服务器发送一条到达可用服务器的连接。

最终用户请求

连接到：

BIG-IP应用交换机的任务：

1）虚拟服务器#1

VIP1:

80

BIG-IP应用交换机将为该虚拟服务器选择一台可用的服务器。

从该源地址流向VIP1上任何端口的流量将流至该服务器，直到计时停止为止。

2）虚拟服务器#2

VIP2:

21（FTP）

因为此时用户已经连接到VIP2上，BIG-IP应用交换机将为VIP2选择一个可用的服务器，并将流量从源地址引导到被定义为虚拟服务器#2的服务器。

只要持续性计时器还没到时，BIG-IP应用交换机都会把流向VIP2上任一端口的用户流量引导至该服务器上。

3）虚拟服务器#3

VIP1:

8001

用户现已连接到VIP3，端口80上。

如果持续性计时器还没到时，用户将被连接到VIP1端口80连接所用的同一台服务器上。

●VIP持续性模式

在该模式下，无论使用哪个端口，某用户指定流向某VIP的流量都将流向同一台服务器，除非：

∙持续性计时器到时

∙服务器不再可用。

在这种情形中，BIG-IP应用交换机将发送一条到该虚拟服务器的其它可用服务器的连接。

●SSL持续性模式

最终用户请求

连接到：

BIG-IP应用交换机的任务

1）用户1连接到虚拟服务器#1。

服务器#1

确定唯一的SSL对话ID，并使用它来实现流量的持续性

2）用户2连接到虚拟服务器#2。

服务器#2

确定唯一的SSL对话ID，并使用它来实现流量的持续性

3）用户1连接到虚拟服务器#1。

服务器#1

确定唯一的SSL对话ID，并使用它来实现流量的持续性

●Cookie持续性模式

Cookie持续性利用客户机存储的coockie信息来把客户机连接到合适的服务器上。

BIG-IP应用交换机提供4种不同的Cookie持续性模式以适应任何应用的要求：

重写模式、插入模式、被动模式和散列模式。

在Cookie重写模式下，服务器将插入一个cookie，然后BIG-IP应用交换机将对其进行重写：

首次命中

HTTP请求（不带有cookie）进入BIG-IP应用交换机

BIG-IP应用交换机任选一台服务器，将请求发送至该服务器

来自该服务器的HTTP回复此时包括一个空白的cookie

BIG-IP应用交换机重写cookie，并在粘贴一个特殊的cookie后将HTTP回复发送回去。

再次命中

HTTP请求（带有与上面同样的cookie）进入BIG-IP应用交换机

BIG-IP应用交换机借助cookie信息确定合适的服务器

HTTP请求（带有与上面同样的cookie）进入服务器

HTTP回复（带有空白cookie）返回BIG-IP应用交换机，后者将向客户机提供更新后的cookie。

CookiePersistenceRewriteMode

Cookie持续性重写模式

首次命中

HTTP请求（不带cookie）进入BIG-IP应用交换机

BIG-IP应用交换机任选一台服务器，将请求发送至该服务器

HTTP回复（不带cookie）被发回BIG-IP应用交换机

BIG-IP应用交换机插入cookie，将HTTP回复返回到客户机

再次命中

HTTP请求（带有与上面同样的cookie）进入BIG-IP应用交换机

Cookie指定合适的服务器

HTTP请求（带有与上面同样的cookie）进入服务器

HTTP回复（不带有cookie）进入BIG-IP应用交换机，后者将为客户机提供更新后的cookie。

在被动模式下，服务器使用特定信息来设置cookie：

首次命中

HTTP请求（不带有cookie）进入BIG-IP应用交换机

BIG-IP应用交换机任选一台服务器，将请求发送至该服务器

HTTP回复（带有特定cookie）返回至BIG-IP应用交换机

BIG-IP应用交换机将HTTP回复（带有特定cookie）发回客户机。

再次命中

发送HTTP请求（带有与上面同样的cookie）

Cookie指定合适的服务器

HTTP请求（带有与上面同样的cookie）进入服务器

HTTP回复（带有特定cookie）返回至BIG-IP应用交换机，后者将HTTP回复（带有特定cookie）发送回客户机。

BIG-IP应用交换机Cookie持续性模式与SSL持续性模式之间的主要区别在于：

对于Cookie持续性而言，数据存储在客户机上，而不是BIG-IP应用交换机上，因此可充分使用客户机上的无限资源。

即Cookie持续性体现在HTTPCookie上，而信息则存储于客户机的磁盘驱动器上。

Cookie持续性散列模式

该模式只能在BIG－IPHA控制器和企业上使用。

散列模式使您可以通过设定cookie中一定字节数的信息来确定连接的目的地。

该模式用于将cookie值映射到节点上，之后该值这将用于连接含该cookie的客户机，从而实现了节点的持续性。

目标地址相关性

目标地址相关性适用于BIG-IP应用交换机被用于对高速缓存进行负载平衡的情形。

在这种情形中，BIG-IP应用交换机把向相同内容的请求重发到同一高速缓存上，从而实现高速缓存的高效利用，并减少服务器阵列中的冗余数据量，后者可降低整个站点的运行性能。

举一个简单的例子，用户2从内部网络通过互联网进入Y网站。

高速缓存扮演Y网站的“存储箱”角色。

此时用户1决定访问E，于是高速缓存1存储了E的内容。

随后当用户1决定访问Yahoo时，因为高速缓存上已经存储了所需的信息，因此就实现了更加快速和高效的访问。

带有对话ID的SSL持续性的优势

当SSL对话首次建立时，用户与服务器进行首次信息交换以：

1}交换安全证书，2）商议加密和压缩方法，3）为每条对话建立对话ID。

该对话ID可能会再次用到。

当用户想与该服务器再次建立连接时，它可以通过提供上次会话中的对话ID来随意指定希望继续以前的某条SSL对话。

在服务器同意之后，双方即可跳过信息交换建立起新的会话，该会话将使用与上次会话同样的加密方法，并继续上次的数据包排序，就好象上次会话从未结束一样。

通常情况下，服务器将某条SSL对话的详细资料存储一段给定的时限，之后，服务器将删除这些对话信息。

例如，用户可以建立一条到旅游景点网站的SSL连接并预订房间。

旅游景点站点可以将用户的预订信息保存一段时间（如60分钟），从而使用户无需重新输入预订信息即可再次连接到站点上以预付订金。

如果旅游景点的网站仅将用户信息存储在进行初始对话的服务器上而不是后端数据库中，那么BIG-IP应用交换机的持续性设置将覆盖负载平衡设置，将用户再次发送到最初的服务器上。

如果用户尝试重新建立一条已被遗弃的对话，那么服务器将忽略此请求而仅提供一个新的对话ID，新的对话也将要求进行新的信息交换。

改善总体吞吐能力

延续先前的SSL对话使服务器无需再次对用户进行鉴权，而这一处理是一项计算密集型任务，执行的次数越多，服务器的总体吞吐能力下降幅度就越大。

如果能够跳过SSL信息交换，消除网络流量上的额外负载，那么吞吐能力也将因为持续性而大为提高。

这将为诸如HTTP等协议带来显著改进，它们往往需要向同一台服务器几次建立连接就只是为了传输一个网页。

因此，SSL持续性将通过避免单台服务器过载而使您的网络大为受益。

需要SSL持续性的环境

乍一看来，源持续性似乎与SSL持续性的有着相容的工作模式。

但是，当用户希望与同一台服务器重新建立会话，但两次连接中用户的IP地址又有所不同时，情况就不一样了。

在这种情形中，BIG-IP应用交换机将没有所需的信息以将流量引导至合适的服务器。

您可能会发出疑问：

那么我们为什么一定要讨论在与同一台服务器进行的两次会话中用户IP地址发生变化的情形呢？

许多网络都会定期更改用户的IP地址，当用户与BIG-IP应用交换机之间部署有防火墙时更是如此。

当用户的IP地址发生变化时

许多防火墙都会将网络所用的网络地址转换为一个或多个由防火墙管理的IP地址。

使用这种方式，防火墙可以在不暴露网络内部实际使用的IP地址的前提下将流量引导至互联网，这时流量上的返回地址就是防火墙地址。

反之，防火墙也可把地址转回用户地址，然后发送回受保护网络。

同时再通过端口号转换，防火墙即可以在多个用户之间使用相同的IP地址了。

这有时被称为地址重载，可支持网络（位于防火墙之后）使用一个IP地址与互联网建立上千条连接。

然而，在大型网络中，防火墙可能需要多个IP地址来分配流量。

在使用一个以上防火墙来处理网络流量的情形中，每个防火墙都可以为通过的流量分配一个不同的IP地址。

在这种情形中，防火墙或防火墙阵列可将用户IP地址转换为针对各条TCP对话的不同地址。

在需要持续性的情形中，地址重载会引发各种问题。

如果持续性仅由源地址决定，那么许多个人用户将被引导至一台服务器上，从而导致流量汇集在一台服务器上而不是分散到多台服务器上。

最终结果就是一台服务器过载而其它服务器未得到充分利用，最终用户得到极差的响应体验。

使用SSL对话ID持续性可以确保流量的平均分配，即使流量源使用IP地址重载也同样如此。

SSL对话ID持续性的实现可以确保用户从关键SSL流量上得到最佳的响应。

总之，源持续性不适用于用户IP地址改变的使用情形，例如在用户与互联网间部署有使用多个IP地址的服务器或服务器阵列。

使用带有源持续性的SSL持续性

您可以同时使用SSL持续性和基于IP地址的源持续性，因为SSL持续性比基于IP地址的持续性拥有更高的优先级。

当自上一次连接后过去的时间超过SSL持续性的时限时，BIG-IP应用交换机可能会删除该SSL对话ID。

或者，也许用户的客户机没有对话ID记忆机制，也删除了该ID。

在这些情形中，BIG-IP应用交换机仍可根据基于用户IP地址的源持续性来将用户引导至同一台服务器。

在这种模式中，源持续性用作SSL持续性的后备。

4.动态安全体系防御攻击

F5在硬件平台上运行的BIG-IP®应用流量管理软件可为所有基于IP的应用和Web服务提供原来只有Web应用才能享有的流量管理功能。

在任何网络环境下，BIG-IP都能通过其功能强大的通用扩展应用检测EAV和扩展内容检测ECV对服务器进行仔细检测，自动屏蔽故障服务器，以便准确、安全、经济高效地创建和提供所有基于IP的应用或Web服务。

∙确保所有IP应用的高可用性和正常运行时间

∙创建一个可控的执行点以对所有流量进行前瞻性安全控制

∙使服务器和应用能够及时准确地做出响应

∙无需额外硬件、软件或其它IT资源

∙轻松适应未来不断变化的业务需求

当大数据流DoS/DDoS攻击进入的时候，服务器可能由于在瞬间接受超过服务器吞吐能力的数据流而直接导致系统崩溃，甚至导致数据丢失或客户资料遗失。

而采用F5的BIG-IP保护服务器，通过EAV/ECV精确探测服务器的处理能力，从而在服务器处理能力饱和之前自动屏蔽新建链接。

超过服务器吞吐能力的链接将在F5上处于waiting状态，直至有服务器空闲或TCPtimeout。

与此同时，为进一步防止服务器遭受攻击过载，F5利用“iControl”技术可以帮助服务器通知网络，“此时忙，暂停服务”，然后，网络将停止再向它转发客户请求，而将客户请求继续转发至其它服务器，继续对客户应用请求提供服务。

并且，服务器会同时通知3DNS，这个中心可用服务器数量减少一台，应相应减少对这个中心的客户服务请求量。

当这台服务器完成所有数据记录的备份后，服务器又会通知