场地
|
描述
|
IP地址
|
输入一个新的虚拟 IP 地址,作为访问真实服务器的目标入口。这个IP是用户或应用程序访问负载均衡应用程序的指向。
|
子网掩码/前缀
|
这个字段是与ADC所在的网络有关的子网掩码。
|
港口
|
访问VIP时使用的入口端口。如果你使用反向代理,这个值不一定要与真实服务器相同。
|
服务名称
|
服务名称是VIP的目的的文本表示。它是可选的,但我们建议你提供它以使之清晰。
|
服务类型
|
有许多不同的服务类型供你选择。第4层服务类型不能使用flightPATH技术。
|
场地
|
描述
|
活动
|
活动字段可以用来显示和改变负载平衡的真实服务器的状态。
在线 - 表示服务器处于活动状态,正在接收负载平衡的请求。
离线 - 服务器处于离线状态,没有收到请求
Drain - 服务器已被置于drain模式,以便持久性可以冲刷,并将服务器转移到离线状态而不影响用户。
待机 - 服务器已被置于待机状态
|
IP地址
|
这个值是Real服务器的IP地址。它必须是准确的,不应该是DHCP地址。
|
港口
|
真实服务器上的目标访问端口。当使用反向代理时,这可能与VIP上指定的入口端口不同。
|
加权
|
这个设置通常是由ADC自动配置的。如果你想改变优先权的权重,你可以改变这个。
|
选项
|
描述
|
群体
|
群集是ADC在安装时的默认角色,Primary/Mode列将显示它当前运行的模式。当你的数据中心有一对ADC设备的HA时,其中一个会显示主动,另一个显示被动
|
手册
|
手动角色允许ADC对不同的虚拟IP地址以主动-主动模式运行。在这种情况下,Primary列将包含一个方框,在每个独特的虚拟IP旁边,可以勾选主动,或不勾选被动。
|
单独的
|
ADC是作为一个独立的设备,不在高可用性模式下。因此,Primary(主要)一栏将显示Stand-alone(独立)。
|
LED
|
意义
|
l
|
在线
|
l
|
故障转移-待机。这个虚拟服务是热备用的
|
l
|
表示 "次要的 "正在为 "主要的 "拖后腿。
|
l
|
服务需要注意。该指示可能是由于Real服务器未能通过健康监测检查或被手动改为离线。流量将继续流动,但真实服务器的容量会减少。
|
l
|
离线。内容服务器无法到达,或没有启用内容服务器
|
l
|
查找情况
|
l
|
未被许可或被许可的虚拟IP数量超过了
|
服务类型
|
端口/协议
|
服务层
|
评论
|
第4层TCP
|
任何TCP端口
|
第4层
|
ADC不会改变数据流中的任何信息,并将根据负载平衡策略执行标准的负载平衡流量。
|
第4层UDP
|
任何UDP端口
|
第4层
|
与第4层TCP一样,ADC不会改变数据流中的任何信息,并将根据负载平衡策略执行标准的负载平衡流量。
|
第四层TCP/UDP
|
任何TCP或UDP端口
|
第4层
|
如果你的服务有一个主要的协议,如UDP,但会回落到TCP,这是理想的。ADC不会改变数据流中的任何信息,并将根据负载平衡策略执行标准的负载平衡流量。
|
HTTP
|
HTTP或HTTPS协议
|
第7层
|
ADC可以使用flightPATH进行交互,操作和修改数据流。
|
FTP
|
文件传输协议协议
|
第7层
|
在客户端和服务器之间使用单独的控制和数据连接
|
SMTP
|
简单邮件传输协议
|
第4层
|
在负载平衡邮件服务器时使用
|
POP3
|
邮局礼仪
|
第4层
|
在负载平衡邮件服务器时使用
|
IMAP
|
互联网信息访问协议
|
第4层
|
在负载平衡邮件服务器时使用
|
RDP
|
远程桌面协议
|
第4层
|
在负载平衡终端服务服务器时使用
|
RPC
|
远程程序调用
|
第4层
|
在使用RPC调用的负载平衡系统时使用
|
RPC/ADS
|
Exchange 2010通讯录服务的静态RPC
|
第4层
|
在负载平衡Exchange服务器时使用
|
RPC/CA/PF
|
客户端访问和公共文件夹的Exchange 2010静态RPC
|
第4层
|
在负载平衡Exchange服务器时使用
|
DICOM
|
医学中的数字成像和通信
|
第4层
|
在使用DICOM协议的服务器进行负载平衡时使用
|
LED
|
意义
|
l
|
已连接
|
£
|
不受监控
|
l
|
排水
|
l
|
离线
|
l
|
待机
|
l
|
未连接
|
l
|
调查情况
|
l
|
未经许可或许可的真实服务器超过了
|
选项
|
描述
|
在线
|
所有在线分配的真实服务器将根据基本选项卡内设置的负载平衡策略接收流量。
|
沥水
|
所有被指定为排空的真实服务器将继续为现有连接提供服务,但不接受任何新的连接。在排水过程中,状态灯将闪烁绿色/蓝色。一旦现有的连接自然关闭,真实服务器将离线,状态灯将是纯蓝色。你也可以通过浏览导航>监控>状态部分来查看这些连接。
|
离线
|
所有被设置为 "离线 "的真实服务器将立即下线,不会收到任何流量。
|
待机
|
所有设置为待机的真实服务器将保持离线,直到所有在线组的服务器不能通过其服务器健康监控检查。当这种情况发生时,流量将由待机组按照负载平衡策略接收。如果在线组中的一个服务器通过了服务器健康监控检查,这个在线服务器将接收所有的流量,而待机组将停止接收流量。
|
选项
|
描述
|
最快的
|
最快的负载均衡策略自动计算每台服务器所有请求的响应时间,并对时间进行平滑处理。计算权重栏包含自动计算的值。只有在使用这个负载平衡策略时,才可以手动输入。
|
循环赛
|
Round Robin通常用于防火墙和基本的负载平衡器,是最简单的方法。每个真实服务器依次接收一个新的请求。这种方法只有在你需要均匀地对服务器进行负载平衡的时候才合适;一个例子是查询网络服务器。然而,当你需要根据应用负载或服务器负载进行负载平衡时,甚至需要确保你在会话中使用同一台服务器时,Round Robin方法就不合适了。
|
最少的连接
|
负载平衡器将跟踪每个Real服务器的当前连接数。连接数最少的Real服务器会收到后续的新请求。
|
第三层会话亲和性/持久性--IP绑定
|
在这种模式下,客户的IP地址构成了选择哪个Real服务器将接收请求的基础。这个动作提供了持久性。HTTP和第4层协议可以使用这种模式。这种方法对于网络拓扑结构已知的内部网络很有帮助,而且你可以确信上游没有 "超级代理"。有了第四层和代理,所有的请求看起来都像是来自一个客户端,因此,负载不会是均匀的。有了HTTP,头信息(X-Forwarder-For)在出现时被用来应对代理。
|
第三层会话亲和性/持久性 - 基于IP列表
|
与Real服务器的连接使用 "最小连接 "启动,然后根据客户的IP地址实现会话亲和性。默认情况下,列表保持2小时,但这可以用jetPACK来改变。
|
第7层会话亲和性/持久性--ALB会话Cookie
|
这种模式是HTTP负载均衡中最流行的持久性方法。在这种模式下,ADC对每个第一个请求使用基于IP列表的负载均衡。它在第一个HTTP响应的头文件中插入一个cookie。此后,ADC使用客户端cookie将流量路由到同一后端服务器。当客户端每次都需要去同一个后端服务器时,这个cookie被用于持久性。一旦会话关闭,该cookie就会过期。
|
第7层会话亲和性/持久性 - ALB持久性Cookie
|
基于IP列表的负载平衡模式用于每个第一次请求。ADC在第一个HTTP响应的头文件中插入一个cookie。此后,ADC使用客户端cookie将流量路由到同一后端服务器。当客户端每次都必须去同一个后端服务器时,这个cookie用于持久性。该cookie将在2小时后过期,并且连接将根据基于IP列表的算法进行负载平衡。这个过期时间可通过jetPACK进行配置。
|
Session Cookie - 经典ASP Session Cookie
|
Active Server Pages(ASP)是微软的一项服务器端技术。选择这个选项后,如果检测到ASP cookie并在其已知的cookie列表中找到,ADC将保持会话持久性到同一服务器。在检测到一个新的ASP cookie时,它将使用最小连接算法进行负载平衡。
|
Session Cookie - ASP.NET Session Cookie
|
这种模式适用于ASP.net。选择这种模式后,如果检测到ASP.NET cookie并在其已知cookie列表中找到,ADC将保持对同一服务器的会话持久性。在检测到一个新的ASP cookie时,它将使用最小连接算法进行负载平衡。
|
Session Cookie - JSP Session Cookie
|
Java服务器页面(JSP)是一种Oracle服务器端技术。选择这种模式后,如果检测到一个JSP cookie并在其已知的cookie列表中找到,ADC将保持对同一服务器的会话持久性。在检测到一个新的JSP cookie时,它将使用最小连接算法进行负载平衡。
|
Session Cookie - JAX-WS Session Cookie
|
Java网络服务(JAX-WS)是一项Oracle服务器端技术。选择这种模式后,如果检测到JAX-WS cookie并在其已知cookie列表中找到,ADC将保持对同一服务器的会话持久性。在检测到一个新的JAX-WS cookie时,它将使用最小连接算法进行负载平衡。
|
Session Cookie--PHP Session Cookie
|
个人主页(PHP)是一种开源的服务器端技术。选择这种模式后,当检测到PHP cookie时,ADC将保持会话持久性到同一服务器。
|
Session Cookie - RDP Cookie的持久性
|
这种负载平衡方法使用微软创建的基于用户名/域名的RDP Cookie来提供对服务器的持久性。这种方法的优点是,即使客户端的IP地址发生变化,也可以保持与服务器的连接。
|
基于Cookie-ID
|
一个非常像 "PhpCookieBased "和其他负载平衡方法的新方法,但使用CookieIDBased和cookie RegEx h=[^;]+
这个方法将使用Real Server的注释字段 "ID=X; "中设置的值作为cookie值来识别服务器。因此,这意味着它是一种类似于CookieListBased的方法,但使用不同的cookie名称,并存储一个独特的cookie值,不是加扰的IP,而是来自真实服务器的ID(在加载时读入。
默认值是CookieIDName="h";但是,如果在虚拟服务器的高级设置配置中有一个覆盖值,就用这个值代替。注意:如果设置了这个值,我们会覆盖上面的cookie表达式,用新的值替换h=。
最后一点是,如果一个未知的cookie值到达并与真实服务器ID
之一相匹配,就应该选择该服务器;否则,使用下一个方法(委托。
|
选项
|
描述
|
无
|
在这种模式下,Real服务器不被监控,并且总是正确地启动和运行。无设置对于监控使服务器不安的情况和不应该加入ADC的故障转移行动的服务是有帮助的。它是托管不可靠的或遗留的系统的路线,这些系统对H/A操作并不主要。对任何服务类型使用这种监控方法。
|
平/ICMP回声
|
在这种模式下,ADC向内容服务器的IP发送一个ICMP回波请求。如果收到一个有效的回波响应,ADC认为真实服务器已经启动并运行,到服务器的流量吞吐量继续。它还会在H/A对上保持服务的可用性。这种监控方法可用于任何服务类型。
|
TCP连接
|
在这种模式下,一个TCP连接被建立到Real服务器上,并立即中断,不发送任何数据。如果连接成功,ADC就认为Real服务器已经启动并运行。这种监控方法可用于任何服务类型。UDP服务是目前唯一不适合于TCP连接监控的服务。
|
ICMP无法到达
|
ADC将向服务器发送一个UDP健康检查,如果它收到一个ICMP端口不可达消息,就将Real服务器标记为不可用。当你需要检查服务器上的UDP服务端口是否可用时,这种方法会很有帮助,例如DNS端口53。
|
RDP
|
在这种模式下,一个TCP连接初始化,就像ICMP不可到达方法中解释的那样。在连接初始化之后,请求一个第7层的RDP连接。如果该连接被确认,ADC认为Real服务器已经启动并运行。这种监控方法可用于任何微软终端服务器。
|
200 OK
|
在这种方法中,一个TCP连接初始化到Real服务器上。连接成功后,ADC向Real Server发送一个HTTP请求。等待一个HTTP响应并检查 "200 OK "响应代码。如果收到 "200 OK "响应代码,ADC认为Real Server已经启动并运行。如果ADC由于任何原因没有收到 "200 OK "响应代码,包括超时、连接失败和其他原因,ADC会将Real Server标记为不可用。这种监控方法只适用于HTTP和加速的HTTP服务类型。如果HTTP服务器使用的是第4层服务类型,如果SSL没有在真实服务器上使用,或者被 "内容SSL "设施适当处理,它是可以使用的。
|
DICOM
|
一个TCP连接在DICOM模式下初始化到Real服务器,并在连接时向Real服务器提出Echoscu "关联请求"。包括来自内容服务器的 "关联接受 "的对话,少量数据的传输,然后是 "释放请求 "和 "释放响应",成功地结束了监测。如果由于任何原因,监控没有成功完成,那么真实服务器将被视为停机。
|
用户定义的
|
任何在真实服务器监控部分配置的监视器都会出现在列表中。
|
选项
|
描述
|
作者:主持人
|
每个主机的缓存是基于每个主机名的应用。每个域名/主机名会有一个单独的缓存。这种模式对于可以根据域名为多个网站提供服务的网络服务器来说非常理想。
|
通过虚拟服务
|
当你选择这个选项时,每个虚拟服务的缓存是可用的。对于通过虚拟服务的所有域名/主机名,将只存在一个缓存。这个选项是一个专业设置,用于一个网站的多个克隆。
|
选项
|
描述
|
关闭
|
关闭虚拟服务的压缩功能
|
压缩
|
当选择时,该选项开启了对所选虚拟服务的压缩。ADC会根据请求动态地压缩数据流到客户端。这个过程只适用于包含content-encoding: gzip头的对象。示例内容包括HTML、CSS或Javascript。你也可以使用 "全局排除 "部分排除某些内容类型。
|
选项
|
描述
|
没有SSL
|
从源头到ADC的流量是不加密的。
|
默认情况下
|
该选项的结果是将本地创建的名为 "默认 "的证书应用到通道的浏览器端。当没有创建或导入SSL时,使用该选项来测试SSL。
|
用户导入的SSL证书
|
你已经导入ADC的任何证书都将显示在这里。
|
选项
|
描述
|
没有SSL
|
从ADC到真实服务器的流量是不加密的。在浏览器端选择证书意味着可以在客户端选择 "无SSL "来提供所谓的 "SSL卸载"。
|
任何
|
ADC作为一个客户,将接受Real Server提供的任何证书。当选择该选项时,从ADC到真实服务器的流量是加密的。当在虚拟服务端指定一个证书时,使用 "任何 "选项,提供所谓的 "SSL桥接 "或 "SSL再加密"。
|
SNI
|
ADC作为一个客户,将接受Real Server提供的任何证书。如果选择了这个选项,从ADC到真实服务器的流量是加密的。当在虚拟服务端指定一个证书时,使用 "任何 "选项,提供所谓的 "SSL桥接 "或 "SSL再加密"。选择该选项可以在服务器端启用SNI。
|
用户导入的SSL证书
|
你已经导入ADC的任何证书都会出现在这里。
|
选项
|
描述
|
反向代理
|
反向代理是默认值,在第七层工作,有压缩和缓存。而在第四层则没有缓存或压缩。在这种模式下,你的ADC作为一个反向代理,成为真实服务器看到的源地址。
|
直接服务器返回
|
直接服务器返回或DSR(在某些圈子里称为DR-直接路由)允许负载均衡器后面的服务器绕过响应的ADC直接响应客户端。DSR只适合用于第4层的负载平衡。因此,选择这个选项时,缓存和压缩是不可用的。
第7层的负载平衡不能与这个DSR一起工作。另外,除了基于IP列表外,没有持久性支持。用这种方法进行SSL/TLS负载均衡并不理想,因为源IP持久性支持是唯一可用的类型。DSR还需要对Real Server进行修改。请参考真实服务器变更部分。
|
闸门
|
网关模式允许你通过ADC路由所有流量,允许来自Real Servers的流量通过ADC的虚拟机或硬件接口被路由到其他网络。在多接口模式下运行时,将该设备作为Real服务器的网关设备是非常理想的。
使用这种方法的第7层负载平衡不起作用,因为除了基于IP列表外,没有持久性支持。这种方法要求Real服务器将其默认网关设置为ADC的本地接口地址(eth0、eth1等)。请参考Real Server变更部分。
|