F5负载均衡器维护手册.docx

F5负载均衡器维护手册.docx

《F5负载均衡器维护手册.docx》由会员分享，可在线阅读，更多相关《F5负载均衡器维护手册.docx（35页珍藏版）》请在冰点文库上搜索。

F5负载均衡器维护手册

F5负载均衡器维护手册

LT

一、基本原理

1．1负载均衡器的基本原理

应用负载均衡器对外提供一个虚拟的应用服务器，接收所有的客户端请求

应用负载均衡器通过负载均衡算法处理，将客户端请求转发到后台的多个应用实例

应用负载均衡器通过应用健康检查，准确的判断应用程序的工作和服务状态，一旦发现应用不能提供服务，则将其从负载均衡组中摘除

1．2负载均衡器几要素

负载分配策略：

负载分配策略是应用负载均衡的整个核心，如何对用户的流量进行分配，使后台服务器的处理更加合理。

达到均衡负载，保证用户的最佳体验的目的，和负载分配策略具有密不可分的关系。

健康检查策略：

在一个良好设计的系统中，负载均衡器往往处于一个系统的核心位置，很多用户使用四层负载均衡的一个主要原因就是要实现应用的高可用性而非性能问题。

如何让负载均衡器能智能的检查到服务器真实的健康状态，在系统的设计中起到至关重要的作用。

会话保持策略：

就目前而言，只有很少的应用系统是专为多服务器并行处理而设计，用户的登录信息，SessionID等还是在单台服务器上存放，并没有同步到其他的服务器上，因此，会话保持策略的丰富性也是四层负载均衡一个巨大的挑战。

冗余切换策略：

在保证了后台设备的高可用性之后，出于系统核心位置的负载均衡器自身的高可用性就变得尤其重要，并且由于应用访问的不透明性，造成在紧急情况下很难对所有的应用进行迁移工作。

这时负载均衡器的冗余切换策略和手段将关系到整个系统的高可用性。

网络结构的灵活性：

对于一个横跨网络和应用的设备来说，对于网络结构和应用结构的完整支持特性变得尤其重要，网络层的基本技术如VLAN、Trunk、Spanning、Tree、IPV4/V6、静态路由、OSPF等都将成为负载均衡器的基本配置。

而另外对于应用中的各种特殊协议的支持，也决定了负载均衡器部署的范围和使用。

1．3F5BIG-IPLTM基本元素

在BIG-IPLTM中，针对应用负载均衡的应用特色和系统需求，将整个流量的处理过程按照以下方式进行定义：

VS：

VirtualServer是进入BIG-IPLTM处理流量的入口。

VS的定义包含了IP和端口和VLAN，其中，IP可以是一个IP，也可以是用掩码掩出来的一段IP，端口可以是一个固定的端口，比如80，也可以是0端口，0端口的意思就是侦听所有的端口。

VS的定义的含义就是对于发送到BIG-IPLTM上的流量，只有同时命中VS的IP和端口的流量才进行处理。

Profile：

当流量进入BIG-IPLTM之后，怎样去处理和识别进入VS的流量，就需要由Profile来定义了。

Profile分了几种类型，有协议层的Profile比如TCPprofile,UDPprofile。

有应用层的Profile比如HTTPprofile，FTPProfile。

还有SSLProfile、会话保持相关的Profile、认证的Profile和其他一些Profile类型。

所有的Profile都需要关联在VS上才能生效。

有些Profile之间是互斥的关系，比如TCP和UDP,HTTP和FTP，VS上关联了TCPprofile，就不能再关联UDPProfile了。

因为一旦关联了某个Profile，VS就会按照这个Profile的定义方式去处理流量。

所以有些Profile也是相互依存的，比如要关联HTTPProfile，就必须先关联TCPProfile。

Pool：

Pool在LTM的内部是一个逻辑概念，是指的一组相同服务的资源的组合。

Pool的作用很简单，就是根据自身定义的分发规则，对VS接收进来，并且被Profile处理之后的流量进行分发，分发到Pool内的member去。

Member:

一个应用服务，通常情况下，一个Member就是后台服务器的一个侦听进程，是由IP:

port格式组成。

Node:

Node通常用来表示后台的一个服务IP地址，一个Node上面可以有一个或多个Member。

Node不需要进行配置，在配置了Member之后自动产生，系统会根据每一个不同的MemberIP地址生成一个Node地址

iRules：

iRules相当于在整个数据包通路上进行一个监控和处理。

VS-Pool-SNAT的这一条路上，iRules可以通过事件驱动方式，在通路上的任何一个位置上对数据包进行判断和处理。

比如Client_Accepted事件就是当请求命中VS的时候被激活，poolwebpool这条指令用于指示BIG-IPLTM将流量分配到那个Pool里面去。

而iRules的事件是否能触发或者iRules能获取和处理那些信息，则都是由关联的Profile来决定的。

比如VS只关联了TCPProfile，而没关联HTTPProfile。

那即使通过VS的流量都是HTTP请求，iRules也无法去获取URI、header等信息。

只有关联了HTTPProfile之后，iRules才能触发HTTP相关事件和按照HTTP协议的相关规范对请求内容进行识别和判断。

1．4BIG-IPLTM的TMM

TMM就是一个应用程序。

TMM一旦启动，就会抢占系统的大部分内存（内存分配可以在系统Provision的时候进行分配），接管所有的业务端口流量、SSL加解密芯片和HTTP硬件压缩芯片等资源，然后根据自己的需求进行使用。

只要从BIG-IPLTM前面板的业务端口进入的流量，都会先经过TMM的处理。

当BIG-IPLTM只有单核CPU时，主要的CPU资源都优先分配给TMM进程。

在这种结构下，所有的流量处理都在TMM里直接处理，则可以到很高的性能，除了负载均衡以外，在BIG-IPLTMLTM上的SSL、RamCache、Compress、SSLVPN、WOM等功能都是在TMM内部处理的。

而一些比较大型的工作模块如GTM（GlobalTrafficManager）、WA（WebAccelerator）、ASM（ApplicationSecurityManager）和认证等一些功能则是通过其他的进程进行处理，这些进程通过内部的Plugin结构和TMM进行通讯。

多核CPU平台：

当系统中有多个CPU内核存在时，BIG-IPLTM将进入CMP（ClusterMutiProcessor）的工作模式，所谓CMP，就是在BIG-IPLTMLTM的内部，使用硬件芯片HSB（HighSpeedBridge）对进入生产端口的流量在内部进行了一次负载均衡，使流量均匀的分布到每个TMM核心上去。

而每个TMM核心占据一个CPU内核

1．5BIG-IPLTM的负载均衡算法

轮询算法（RoundRobin）：

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

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

比率算法（Ratio）：

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

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

最少连接数（LeastConnections）：

在BIG-IPLTM上对每一台服务器的当前连接数进行统计，当有新的请求进入时，将新的请求分配给当前最少连接处理的服务器。

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

最快响应速度（Fastest）：

在BIG-IPLTM上通过观察每台服务器得应用响应速度，当有新的请求进入的时候，将新的请求分配给响应最快的服务器。

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

观察模式（Observed）：

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

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

性能预测分配：

（Predictive）

由负载均衡设备收集到的应用程序和应用服务器的各项性能参数如CPU占用率，内存占用率、当前并发用户数等关键信息，并可进行加权处理。

当有新的请求进入的时候，将新的请求分配给综合性能最佳的服务器。

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

1．6BIG-IPLTM会话保持

1．6．1会话保持的需求：

以最典型的HTTP应用为例，在大多数电子商务的应用系统或者需要进行用户身份认证的在线系统中，一个客户与服务器经常经过好几次的交互过程才能完成一笔交易或者是一个请求的完成。

由于这几次交互过程是密切相关的，服务器在进行这些交互过程的某一个交互步骤时，往往需要了解上一次交互过程的处理结果，或者上几步的交互过程结果，服务器进行下一步操作时需要这就要求所有这些相关的交互过程都由一台服务器完成，而不能被负载均衡器分散到不同的服务器上。

一个典型的HTTP请求流程如下：

●客户端发起一个连接到服务器的服务端口，并在此连接中发送HTTP请求

●服务器在接收到用户请求后，在本地产生一个内部SessionID用于唯一标识该用户

●服务器将返回内容进行组织后，同时将SessionID通过Cookie返回给用户

●用户在收到回应后，将Cookie保存在内存中。

●用户下一次点击重新发起一个连接到服务器的服务端口

●用户在新建连接中发送HTTP请求，并带上Cookie进行发送。

●服务器在收到请求后，从Cookie中获得该用户的SessionID,根据此SessionID进行相关处理

1．6．2源地址会话保持：

源地址会话保持的一个基本概念就是将一个源地址认为是一个用户，凡是同一个源地发送过来的连接，则认为是同一个用户发起的多个请求，根据会话保持策略，将这些连接/请求都转发到同一台服务器。

当一个新的连接请求发送到虚拟服务后，首先查找源地址会话保持表，如果在源地址会话保持表中查询到了该请求发起的源地址对应的服务器，则直接将该请求转发到相应的服务器上，如果在源地址会话保持表中没有查询到相应的条目，则按照负载均衡算法将请求转发到相应的服务器，同时，将该请求发起的源地址和对应的服务器地址添加到源地址会话保持表中。

这样，下次同一IP地址再发起新建连接到该虚拟服务时，则在源地址会话保持表中已经存在相应的条目，新的连接则会根据源地址会话保持表的对应项转发到对应的服务器上。

源地址会话保持同时还存在有一个超时时间参数。

每次有有新建连接请求或已建立的连接中有数据在传输时，就会刷新会话保持表中的超时时间。

比如设置源IP会话保持的超时时间为300秒，则对于同一个源IP，只要有新建连接或已建连接有数据传输，则在源地址会话保持表中的超时时间一直刷新为0。

当没有新建连接或者数据传输时，该值就开始按秒进行累加，一旦超出300秒没有新建连接请求或没有数据传输。

则将其条目从源地址会话保持表中清除。

如果该IP地址在在过了超时时间之后又有新的连接请求，则以第一次连接请求按照负载均衡的算法进行处理，此时，源地址会话保持表中的超时时间又从0开始计算。

1．6．3哈希会话保持

哈希会话保持的一个基本概念就是将一个连接中的源IP和目的IP地址进行Hash计算，根据计算得到的结果并根据后台存在多少台服务器来选择将请求分配到那台服务器。

哈希会话保持的特点是在后台服务器的健康状态不发生改变的时候，每个特定的源IP地址被分配到的服务器是固定的。

并且，哈希会话保持可以没有会话保持表，而仅仅是根据计算的结果来确定一个源IP被分配到那台服务器。

哈希会话保持通常被用于一些特定场合，如要求客户端按照IP地址被固定分配的场合，或者在一些会话保持表查询的开销已经远远大于Hash计算开销的情况下，采用hash会话保持可以提高系统的处理能力和响应速度。

在实际的应用场景中，针对后台采用Cache服务器的情况，还有对URL进行Hash的处理方式，将同一个URL的请求分配到同一台Cache服务器，这样，对后台的Cache服务器群组来说，每台Cache服务器上存放的内容都是不一样的，提高Cache服务器的利用率。

1．6．4Cookie会话保持.

Cookie是在浏览器访问WEB服务器的某个资源时，由WEB服务器在HTTP响应消息头中附带传送给浏览器的一片数据，WEB服务器传送给各个客户端浏览器的数据是可以各不相同的。

浏览器可以决定是否保存这片数据，一旦WEB浏览器保存了这片数据，那么它在以后每次访问该WEB服务器时，都应在HTTP请求头中将这片数据回传给WEB服务器。

显然，Cookie最先是由WEB服务器发出的，是否发送Cookie和发送的Cookie的具体内容，完全是由WEB服务器决定的。

例如，用一个Cookie来标识访问者的姓名，有效时间等。

CookieInsert会话保持模式

因为Cookie被如此广泛的使用，特别是SessionCookie技术，基本上在所有的电子商务网站中都在使用这种技术。

因此，在BIG-IPLTM中可以通过插入自己可识别的Cookie来实现会话保持。

当客户进行第一次请求时，客户HTTP请求（不带cookie）进入BIG-IPLTM，BIG-IPLTM根据负载均衡算法策略选择后端一台服务器，并将请求发送至该服务器，后端服务器进行HTTP回复（不带cookie）被发回BIG-IPLTM，然后BIG-IPLTM插入cookie，将HTTP回复返回到客户端。

当客户请求再次发生时，客户HTTP请求（带有上次BIG-IPLTM插入的cookie）进入BIG-IPLTM，然后BIG-IPLTM读出cookie里的会话保持数值，将HTTP请求（带有与上面同样的cookie）发到指定的服务器，然后后端服务器进行请求回复，由于服务器并不写入cookie，HTTP响应将不带有cookie，服务器响应再次经过进入BIG-IPLTM时，BIG-IPLTM再次写入更新后的会话保持cookie。

1．7健康检查

健康检查是负载均衡处理中一个非常重要的环节。

负载均衡的主要作用就是将客户端的请求分配到多台服务器上，如果没有健康检查，在后台服务器发生故障的时候，部分的客户端将会被分配到故障的服务器上，从而导致用户的访问失败。

在一些情况下，甚至可能出现服务器本身还在工作，但其上运行的应用系统已经故障导致无法处理请求，都将会导致用户的请求失败。

在BIG-IPLTM上应当能检查到这些故障，并在进行负载均衡的时候将这些故障的服务器进行自动摘除，保证应用的持续性和高可用性。

1．7．1基于ICMP的健康检查

基于ICMP的健康检查属于最基本的健康检查方式，BIG-IPLTM主动给服务器发送一个ICMP（互联网控制信息协议）数据包，如果BIG-IPLTM收到了服务器的正确响应，则说明检查成功。

ICMP健康检查通常用于网关类型设备的健康检查，如防火墙、路由器等。

这些设备通常不提供其他的健康检查手段，因此ICMP属于最佳的检查方式。

另外，在一些无法使用高级健康检查手段的情况下，也只能使用ICMP健康检查手段。

1．7．2基于TCP端口的健康检查

在基于TCP协议的应用中，每个应用系统都会绑定一个TCP端口，应用通过侦听这个端口接受客户端的请求。

比如我们常见的80端口在默认情况下就是服务于HTTP服务，通常为IIS、Apache等应用系统使用，另外还有FTP（20、21）、HTTPS（443）、SMTP（25）、POP3（110）等。

判断这些应用系统是否在工作最简单的方法就是从BIG-IPLTM和对应的服务器端口做一次完整的TCP握手，如果TCP握手成功，则认为服务器正常工作，如果握手失败，在超过一定的检查次数均握手失败的情况下，BIG-IPLTM则将失败的服务器标记为Down，而将新的客户端请求都发送到其他仍然正常工作的服务器上。

在TCP健康检查中还可能出现的一种情况就是在频繁检查的情况下，健康检查的流量可能导致一些比较“脆弱”的应用系统产生故障。

通常有两种情况会出现这种故障情况：

1.服务器的Socket侦听程序不完善，对于TCP健康检查没有正确关闭连接

2.服务器对每个试图连接都进行log，最后整个应用系统的Log都被健康检查的连接所充满。

而导致磁盘空间溢出或者正常的log信息无法察看。

在这种情况下，有两种解决方式：

1.采用TCPhalfopen的方式进行健康检查，所谓TCPhalfopen就是BIG-IPLTM向服务器发送一个Syn数据包，一旦受到来自该服务的Syn-ACK数据包，则认为该服务正常工作，然后立即发送一个RESET数据包到服务。

在一些情况下，这种TCP半连接模式并不会被记录下来。

2.采用基于代理的健康检查，即在服务器上另外编写一个进程，专门用于健康检查使用，专用的健康检查进程将会负责BIG-IPLTM的健康查询，而保护主进程的不受干扰的运行。

1．7．3基于应用协议的健康检查

由于在ICMP、TCP端口和UDP端口的健康检查中，我们都不一定能确认服务器的真实工作状态。

在实际中经常有可能出现这样的情况：

●服务器IP地址还可以ping，但是应用服务已经crash了

●应用服务还在监听80端口，但是已经不接收任何请求了

●应用服务仍然接收请求，但是每次都返回503服务器内部错误

这种服务已经不正常，但是端口仍在监听的情况，在一些非关键业务上还可以容忍，但在一些关键业务的应用中就不可接受了。

以HTTP协议为例，基于HTTP协议的健康检查过程如下：

●BIG-IPLTM发起一个HTTP请求到服务器，请求特定的资源

●服务器进行回应

●BIG-IPLTM在返回的内容中查找一个关键字，如果存在该关键字，则认为Web服务器正常工作中。

HTTP协议层的健康检查通常用于应用服务器的健康检查，如WebLogic、WebSphare、Tomcat等。

和IIS、Apache服务相比，这些应用服务器出现故障的几率通常较大。

而且最容易出现端口仍然在侦听，但应用已经不工作的情况。

典型的基于应用协议的健康检查通常还有：

FTP:

由BIG-IPLTM向FTP服务器发起FTP请求，在验证用户名和密码后，下载一个文件（通常不会保存这个文件），如果文件下载成功，则认为服务器工作正常。

这样整个FTP服务器的用户认证、磁盘存储连接等服务都进行了检查。

DNS:

由BIG-IPLTM向DNS服务器发起一个DNS请求，请求特定的域名，并检查返回的结果，如果正确，则认为服务器工作正常。

HTTPS:

由BIG-IPLTM向HTTPS发起一个HTTPS请求，通常，在HTTPS的健康检查中可能还需要配置客户端证书等，在服务器响应返回后，在返回的数据中查找特定的字符串，如果匹配成功，则认为HTTPS服务器工作正常。

POP3：

由BIG-IPLTM向POP3服务器发起一个请求，并进行用户名和密码验证。

如果登陆成功，则认为POP3服务器工作正常。

SMTP：

由BIG-IPLTM向SMTP服务器发送一个标准的SMTP请求，如果服务器按照标准SMTP响应返回HELO或QUIT，则认为SMTP服务工作正常。

通常情况下，SMTP健康检查在发送请求的时候还需要指定域名。

数据库：

由BIG-IPLTM向数据库服务器发起一次数据库查询请求，然后判断数据库服务器返回的结果中是否包含特定的字符串，如果匹配成功，则认为数据库服务器工作正常。

二、F5BIG-IPLTM日常维护

2．1F5BIG-IPLTM外观

F5在设备前面板上划分明显不同的三个区域，最左侧设计有failover和console接口；中部为各种网络接口；最右侧为液晶屏幕、状态显示灯、6个控制按钮及F5的红色logo灯泡。

面板前部设计有冷风入口。

电源设计在设备的尾部以方便机架上电源线接入，设备产生的热量从尾部的热风出口散出。

1.管理口2.USB接口3.Console口4.Failover口5.10/100/1000自适应接口6.SFP接口7.指示灯8.液晶屏9.液晶屏控制按钮

1.电源模块一2.电源模块二3.散热风扇

通过LCD按键修改管理网口IP地址的方法如下：

1.按红色X按键进入Options选项；

2.在液晶面板上通过按键按以下顺序设置管理网口的网络地址：

Options->System->IPAddress/Netmask->Commit

2．2F5BIG-IPLTM配置备份和恢复

可以通过以下WEB界面进行配置的备份与修改：

进入System?

Archives，点击Create：

配置备份好后，点击设配置文件并下载到外部电脑上：

恢复系统时点击Restore

如果是需要一个完全干净的系统，建议通过重装系统来恢复到出厂设置。

如果没办法重装系统，但需要将配置清空以重新进行配置，方法如下：

从管理网口用命令行登陆BIG-IP，然后执行以下命令：

#bdballreset

#breset

#bsave

#bbasereset

#bbasesave

2．3F5BIG-IPLTM性能状态

2．3．1F5BIG-IPLTM实时连接状态

在命令行模式输入：

bconn

查看当前端口的状态

查看当前node信息

查看pool状态

查看当前VS信息

2．3．2F5BIG-IPLTM性能状态

查看当前F5性能状态

通过WEB页面，Overview选项卡中的Performance

查看当前F5BIG-IPLTM的主备状态

查看当前F5BIG-IPLTM的组件状态

命令行模式：

bplatform

查看当前F5BIG-IPLTMTOP状态

命令行模式：

bigtop

查看F5BIG-IPLTMTMM内存状态

命令行模式：

bmemoryshow

2．3．3F5BIG-IPLTM告警日志

通过WEBSystem选项中的logs

或者在命令行模式输入

more/var/log/messages查看F5系统日志

more/var/log/ltm查看member和node状态日志

收集F5BIG-IPLTM后台错误日志提交F5官方分析

命令行模式输入：

qkview–f/tmp/myqkview.tar.gz

三、F5BIG-IPLTM服务配置

3．1F5BIG-IPLTM创建用户

通过WEB界面，在System选项卡中选择Users------Create

3．2F5BIG-IPLTM开启本地服务

选择某服务，start即可

注：

ntpd服务需要在命令行模式修改vi/etc/ntp.conf中，增加ntpserver

3．3手动切换主备状态

3．4修改admin和root密码

3．5健康检查的管理和维护

根据需求选择类型

以http为例

命名规则：

类型_端口号，如http_8001

Interval：

间隔时间，即为健康检查服务向节点发送两次检查数据包的间隔时间。

Timeout：

超时时间，即为健康检查服务向节