目录：
——F5 BIG-IP LTM负载均衡策略———-
1.1 LTM VS工作模式
1.2 负载均衡策略
——F5 BIG-IP LTM会话保持———-
2.1 为什么需要会话保持
2.2 常见的会话保持
——F5 BIG-IP LTM健康检查———-
3.健康检查
3.1.健康检查有以下项目：
3.2 关联健康检查
3.3Monitor状态报告
3.4 Pool失败机制
——F5 BIG-IP LTM应用优化———-
4.BIG-IP LTM应用负载优化技术
4.1 TCP应用：（列出常用profile）
——F5 BIG-IP iRules介绍———-
5.1什么是iRules：
5.2 VS和iRules关系
——F5 BIG-IP LTM负载均衡策略———-
1.1 LTM VS工作模式
F5 BIG-IP LTM的内部对于数据包的处理方式，即是VS的工作类型，存在有四种工作模式,分别针对四层数据处理和七层数据处理；
四层处理模式有：Forwarding(IP)
Performance(Layer 4)
七层处理模式有：Standard
performance（HTTP）
1.1.1 Standard
·（首先与client建立连接，再与Pool member建立连接）
·默认工作工作在全代理模式，客户端和服务器端的TCP连接完全独立，BIG-IP维持两个不同的连接。
·在三次握手结束后，BIG-IP按照负载均衡算法选择Pool Member
·客户端和服务器端的TCP参数由TMOS和双方分别协商；
·默认情况下，以客户端源IP与后台建立连接；在打开SNAT的情况下用SNAT地址和后台建立连接。
·Standard vs的端口永远对外开放，无论后台是否有服务器在工作。
1.1.2 性能HTTP
·（首先与Pool member建立连接，再与客户端建立）
· performance HTTP VS仅用于HTTP协议，使用Fast http profile，这是一个TCP、HTTP和oneconnect profile的组合，主要用于加快Http连接速度和减少后台Http server的连接数；
· 只缓存用于分析包头的数据，没有会话保持功能，不能处理SSL，HTTPS；
· BIG-IP通过到Pool Member的TCP连接建立一个空闲的服务器端Flow；
· 当有client请求来时，通过负载均衡算法选择了此服务器，如果发现服务器端Flow是空闲的，则BIG-IP标识其为占用，并发送客户端请求到选定的服务器；
1.1.3 Performance L4模式
· Performance L4 VS基于包到包处理连接，只负责客户端连接的分配和转发，默认不改变TCP连接中的任何参数。
· 客户端和服务器自行协商TCP传输参数。
· Perforamce Layer 4 VS上只有4层的iRules可以使用（意思是这模式下，iRules只能改TCP，改不了http、https等）
· 默认状态下，TCP新建连接的第一个包必须是SYN包，如果是其他的数据报比如ACK、RST等如果不在连接表中，则全部丢弃。
· 利用epva（enhance Packet velocity Acceleration）硬件加速模式，所以叫性能L4模式
1.1.4 Forwarding（IP）=路由模式
·只能使用Fast L4 Profile，translate-address 和translate-port翻译默认为Disable；
· 按照连接处理，类似路由器，但不完全一样，在Fast L4 Profile中开启Loose Initial和Loose Close之后更为接近路由工作模式；
· 所有穿过forwarding YS的连接都将产生连接表
· 没有Pool Member，转发根据目标地址查找本地路由表完成
· 可以使用基于4层的iRules，比如做SNAT
· 无法利用ePVA
1.2 负载均衡策略
BIG-IP LTM进行四层负载均衡的最小元素为TCP连接，所有分配策略均以TCP连接为最小单位，而在七层负载均衡中，最小的元素为每一个完整的交易数据报包，如一个HTTP请求，因此以交易为最小单位进行分配。
负载分配策略主要包含以下几种：
·静态负载均衡算法：轮询，比率，优先权
·动态负载均衡算法：最少连接数，最快响应速度，观察方法，预测法，动态性能分配。
·可编程控制的负载均衡策略：通过编程控制应用流量的导向。
1.2.1.a 静态负载均衡算法;轮询
轮询算法下，以每个客户端新建连接为单位，客户端连接轮流分配到后台的服务器上。
1.2.1.b 比率算法：比率算法
比率算法下，以每个客户端新建连接为单位，将客户端请求按照比率分配到后台的服务器上
1.2.1.c 优先权算法
在正常情况下，所有的客户端请求全部发送到属于高优先级组的member上；当最高优先级群组中的健康的服务器数量小于预定值时，BIG-IP LTM才将请求发送给次优先级的服务器组。
1.2.2.a 动态负载均衡算法：最少连接数
最小连接数为最常用的负载均衡算法之一，在后台服务器处理能力均等的情况下，使用最小的连接数可以得到最为平衡的负载均衡效果。（但是BIG-IP 要维护一张并发表，上面有各个服务器的并发参数）
1.2.2.b 动态负载均衡算法：动态性能分配
前提；BIG-IP知道服务器的CPU使用率（通过健康检查）
动态性能分配通常用于一些服务器资源敏感应用，如集中计算、视频点播等。动态算法是通过BIG-IP上的健康检查来检测服务器的资源占用率，新的请求被分配到资源占用最少的服务器。
1.3 如何选择合适的负载均衡策略：
在大部分的应用场景中，都采用最小连接算法。如果系统的每秒新建连接数非常高，如果还是采用最小连接数，由于算法在计算时候不可能实时的统计后台服务器的连接数，且是有时间间隔的去进行统计。在这种情况下，可能采用轮询算法可以更为有效的实现负载均衡。
——F5 BIG-IP LTM会话保持———-
连接和会话的区别：
会话的概念要广泛一些，简单的说，一个用户登录后，则产生一个session。而这个会话是由多次连接完成。BIG-IP LTM将一个会话里的多次连接认为是同一个用户发起的，是为同一个用户服务的。
BIG-IP LTM的概念中，一个session通常就是会话保持表中的一条记录对应的所有连接。每个命中到这条记录的连接都是属于同一个session的。
2.1 为什么需要会话保持
会话保持是负载均衡设备的一种机制，用于识别客户端与服务器之间交互过程的关连性，在进行负载均衡对的同时还保证一系列相关联的访问请求会保持分配到同一台服务器上。
针对不同的业务场景需要不同的会话保持配置，并不是所有业务系统都需要会话保持性。以HTTP电子商务应用为例，
在在线应用系统中需要进行用户身份，一个客户与服务器经常经过好几次的交互过程才能完成一比较交易。由于这几次交互过程是密切相关的，服务器在进行这些交互过程才能完成一笔交易。由于这几次交互过程是密切相关的，服务器在进行这些交互过程的某一个交互步骤时，往往需要了解上一次交互过程的处理结果，或者上几步的交互过程结果。这就要求所有这些相关的交互过程由一台服务器完成，而不能被负载均衡器分散到不同的服务器上，此时需要响应的会话保持策略来保证相关的请求始终被负载到后端的一台服务器上，
2.2 常见的会话保持
<1>源地址会话保持（source persistence）
<2>Cookie会话保持
HTTP Cookie insert（插入）
HTTP Cookie passive（被动）
HTTP Cookie Rewrite（重写）
Cookie Hash
<3>SSL ID会话保持
<4>可编程控制的会话保持
将会话保持的特性的提取
将特征与后台服务器相对应
2.2.1 源地址会话保持:将一个源地址认为是一个用户，凡是同一个源地址发过来的连接，则认为是同一个用户发起的多个请求。根据会话保持策略，将这些连接/请求都转发到同一个服务器上。（BIG-IP LTM会维护一张“源地址会话保持表”）
2.2.2 Cookie会话保持
关于HTTP Cookie和Session ID，以下面一个典型的HTTP请求流程
（图）
通过HTTP流程图看到Cookie有效的改进了HTTP协议的无状态性，使原本无状态的HTTP协议变成有状态的应用协议。
Cookie的内容包括：名字，值，过期时间，路径和域。
若不设置过期时间，则表示这个Cookie的生命期为浏览器会话期间，关闭浏览器就会消失。这种生命期为浏览器会话器的cookie被称呼session cookie，一般不存储在硬盘上而是保存在内存里。
若设置了过期时间，浏览器就会把cookie保存到硬盘上。
2.2.2.a HTTP Cookie insert（插入）
（服务器端并不写入Cookie，HTTP响应不带有cookie，所有cookie信息只存在负载均衡设备上）
2.2.2.b TTP Cookie passive（被动）
（服务器写入cookie，HTTP响应里将带有更新的会话保持cookie）
2.2.2.c HTTP Cookie Rewrite（重写）
（进入服务器，服务器创建空白cookie，HTTP回复《带有空白cookie》返回BIG-IP应用负载设备）
2.2.3 SSL ID会话保持（冷门）
在用户基于SSL访问系统环境里，当SSL对话首次建立时，用户与服务器进行首次信息交换：
·交换机安全证书
·商议加密和压缩方法
·为每条对话建立session ID
——F5 BIG-IP LTM健康检查———-
3.健康检查：
定义：一个健康检查（Monitor）就是一个测试（test）
·特定的应用程序
·一个预期的回复
·在一定时间内
所有BIG-IP 共同特点：
·间隔：每个检查的时间间隔
·超时时间；这个时间在BIG-IP 标记Node不可用之前返回成功的健康检查结果。
F5 BIG-IP LTM可以使用符合Monitors，所以可使用多重健康检查：
·可以使用全部或部分的健康检查结果来标记成员的状态
3.1.健康检查有以下项目：
《1》基于icmp的健康检查；
《2》基于TCP端口的健康检查；
《3》基于UDP端口的健康检查；
《4》基于应用协议的健康健康
3.1.1 基于icmp的健康检查
原理：简单的使用ping去探测，只要服务器有回应，则认为服务器正常工作；
（基于icmp的健康检查属于最基本的健康检查方式）
3.1.2 基于TCP端口的健康检查
原理：TCP健康检查直接向member的服务器端口发起TCP连接建立请求，连接建立成功即表示服务器的服务在正常工作。
在频繁检查的情况下，健康检查的流量肯呢个导致一些比较“脆弱”的应用系统产生故障。采用TCP half open的方式，或者采用基于代理的健康检查；
3.1.3 基于UDP端口的健康检查
原理：大多数的udp应用特点是在是收到错误的请求时，没有任何响应。但UDP协议还是设计了在端口未开放时，默认系统将会回应一个Icmp unreachable数据包，以通知客户端连接错误。（只能检查端口情况，并不能代表真实的业务情况）
3.1.4 基于应用协议的健康健康
以HTPP协议为例，基于HTTP协议的健康检查过程如下：（负荷较大，几乎浮现业务）
《1》BIG-IP LTM发起一个HTTP请求到服务器，请求特定资源
《2》服务器进行回应；
《3》BIG-IP LTM在返回的内容中查找一个关键字，如果存在该关键字，则认为Web服务器正常工作。
3.2 关联健康检查
在真实的应用中，经常还可能存在有关连性应用。比如应用A是否能正常对外提供服务，还取决于它的下级服务应用B是否能给A提供需要的数据，而此时应用B不是在负载均衡的控制范围之内。
3.3Monitor状态报告
·状态基于健康检查响应及对象层次结构
虚拟服务virtural server 状态受POOL状态影响
pool状态受pool members的状态影响
一个pool的member受这个node的服务状态的影响
·当健康检查失败会发生什么？
·如果没有得到检查结果，超时时间未到
-开始怀疑这个成员member
-没有新连接到这个成员member
-现有连接被维持
·在达到了超时时间前有一个成功的检查结果
新连接发送到member
·如果达到超时时间健康检查失败
从pool中移除member
现有连接清楚
3.4 Pool失败机制
Fallback Host — 最后备份的server（适用于HTTP和HTTPS profile应用）
·当pool members 成员低于活动成员设定（？？？？回HTTP 重定向(http 302) 到客户端）？？？）
·Fallback host server设置是没有健康监控的（备份server）
Priority Group Activation激活低优先组
——F5 BIG-IP LTM应用优化———-
4.BIG-IP LTM应用负载优化技术
主要用于提高和优化下面以下三种流量：
《1》TCP应用
《2》UDP应用
《3》HTTP应用（HTTP由于广泛应用，单独设置为一分支）
4.1 TCP应用：（列出常用profile）
4.1.1 TCP Clinet-side profile
目标：提高用户体验
4.1.2 TCP Server-Side profile
目标：服务器压力卸载
F5已经内置了LAN、WAN和CELL优化的TCP profile配置。通过调整TCP profile多达70个选项；
通常情况下建议：Clinet side：推荐mptcp-mobile-optimized profile 配置模板
Server side：优先推荐tcp-wan-optimized profile
除非特别了解TCP的工作原理，否则不要调整idle timeout以外的任何参数
默认tcp profile所设置idle timeout值为300秒
4.1.3 oneconnect –TCP连接复用
实现连接聚合以降低服务器的TCP的连接总数，减少建立和关闭连接的消耗和延迟。
（图）
工作范围：
《1》前提使用VS Standard模式；
《2》oneconnect profile不是必须和HTTP Profile共用，也可以用于其他应用协议；
《3》但应用其他应用协议时须使用iRules编程来调用oneconnect
HTTP内容（忽略，附上PPT原件自己了解）
——F5 BIG-IP iRules介绍———-
5.1什么是iRules：
集成到TMOS架构的编程语言；
基于工业标准的Tool Command；
拦截、检查，修改，引导及跟踪进站和出站的应用流量；
5.2 VS和iRules关系
iRules的处理必须依赖于VS对流量的接收；
通过事件触发机制，iRules可以控制流量在VS内部处理的整个过程