分类目录F5技术

F5 monitor行为细节分析(有data tcp,HTTP)

 

在F5的monitor中我们总会看到两个计时器选项interval和timeout,通俗的讲就是每隔interval时间执行探测一次,如果timeout时间之内没有应答(回复),则认为失败。

$N0HNH7TW(N1V8U@2[J)S[C

但这里面有不少细节,这里的timeout到底是指的什么,是指每一次探测所要等待的时间还是总时间,如果针对第一次的探测响应在第二次探测发出后才回来,会是什么结果?应用层的行为是否会反过来影响探测?

事实上monitor用两个维度来看待上述两个计时器,当0s monitor开始工作时,系统将开始维持两个监控状态,一个是interval的,一个是timeout的。 系统不管每次的探测成功与否,都会按照interval的间隔触发每一次的探测;而timeout从monitor开始工作时候启动计时,并在探测成功时或超时时间到达时被重置,每次被重置后将随着下一次探测的启动开始进行新的timeout计时:

0s——————-5s——————-10s——————-15s—-16s—————20s

探测:    发 ——————-发——————-发———————-发————————–发

timeout:成功则重置——-成功0s———-成功0s—————–成功0s——————成功0s

timeout:   不成功则持续计时——————————————->直到第16s,记探测失败

timeout:                                                                                                                         新计时

若上表结构错乱,请看下图:
monitor——timer

1. 在系统缺省状态下(bigd.reusesocket enable),对于有data发送的TCPmonitor,或者HTTP monitor 在一个timeout计时时间之内,系统始终维持一个连接TCP连接,并在此连接之内重复发送探测数据,这timeout时间之内任意一次探测得到了正确 结果,则将标记结果为UP,并关闭连接,待下一个interval时间到达后开始一次新的tcp连接,并开始新的timeout计时。若timeout时 间之内没有任何回复,则在timeout时间到达时标记结果为down,在等到下一个interval到达时,开始新的 timeout计时, 系统在执行三次重复探测后关闭连接并在下一次探测时重新建立连接。

如果是纯端口的没有实际数据发送的monitor,则每个间隔的三次握手后关闭。

设想一个情形,系统内置的http monitor默认使用HTTP 0.9发送GET请求,假设当前服务器的响应延迟每次都大于interval时间,会导致什么结果?
—由于系统在每个interval到达时,服务器都无法响应response,因此从服务器角度看,服务器将从同一个tcp通道中的每interval时间收到一个0.9的GET请求,而服务器的http server会认为这不是一个合法的pipeline请求,因此导致服务器始终不给与回复,从而导致monitor最终在timeout时间内无法收到响应。因此建议对http的monitor我们使用HTTP/1.1版本,详细见 https://support.f5.com/kb/en-us/solutions/public/2000/100/sol2167.html?sr=40355086

2. 若将bigd.reusesocket 这个db key的值设置为 disable,那么将改变monitor对socket的使用行为,disable后,monitor在每一次interval发起探测时候都会新建一个tcp连接,之前的tcp连接将被关闭。timeout与interval之间的关系保持上图不变。 所以,若服务器始终无法在下一次(interval时间)探测到来之前回复的话,将导致monitor在timeout时间到达后标记结果为down。

关于为什么要改变reusesocket,请移步https://support.f5.com/kb/en-us/solutions/public/13000/800/sol13820.html?sr=40355414

下面这个脚本可以用来模拟服务器延迟响应:

阅读更多

F5 v11.6 ASM 新特性

1.增加了violation rating

ASM管理员在策略设定过程中需要不断的查看和学习各种violations,判断是否是一个真的violation,以设定正确的策略,但是往往由于管理人员不是开发人员,因而对管理员要求较高,violation rating功能是F5引入的一个业界创新功能,系统可以自动的对所触发的violations基于各个request进行rating,等级的分为1-5, 数字越大表示是真实violation的可能性越大,管理员可以参考系统给出的评分进行策略判断。

violation rating功能存在于两个方面:

1).系统的 event-applications-requests 界面,这里可以按照rating等级过滤系统的requests,若绝大部分requests的rating都很低,说明系统策略的误报率较高。

2).系统的 manual traffic learning 的violation界面,当点击“recent incidents”后,可以看到类似于如下界面,显示触发了该violation的各个requests的violation rating<code srcset=VO$GC]R(BDC3@1UGDAQF67″ width=”300″ height=”125″ />

同时系统还可以在此界面给出该violation的vating 直方图,帮助管理员清晰的判断该violation对不同requests的准确性,若这里绝大部分都是较低分值,说明这个violation对应的策略容易产生误报。

}E33V9}[ECE~7Z5BBITFMGC

阅读更多

最近看到一个江湖故事,留给大家看看

关公战秦琼 T-Force成功登陆北京电力公司
2014-08-26 太一星晨

IMG_3062.JPG
留给看官您自己评论。我不语。

关公者,关羽也,三国时期蜀之大将,一把青龙偃月刀舞得虎虎生威日月无光;

秦琼者,秦叔宝也,隋末唐初知名大将,上马长枪下马短锏练就一身超然本事。

两位隔代豪杰,却因为一段相声而发生了一段穿越时空的实力比拼,捧腹之余不禁赞一个侯老的超前穿越意识。

虽然如此娱乐节目轻松了大众的神经,但是,在刚刚过去的盛夏时节里,一场真正的关公战秦琼剧倒是在北京电力公司里上演了,其过程之紧张、其结局之精彩,丝毫不输各类穿越大戏。

难点极高的主备切换

话说北京电力公司,是为北京地区的所有用电客户提供电力供应的一特大型现代电力企业,其中所部署的电网统一视频监控平台,则是“智能电网”的一个重要组成部分,它实现了不同视频监控设备的平滑接入,为北京电力公司提供了统一的视频监控信息服务。

最近,为了防患于未然,北京电力公司准备对此视频监控平台升级,打算通过负载均衡实现主备配置间的正常切换。但是,因为系统本身比较复杂,在实现主备切换的时候,必须先对各种业务进行精准的智能判断,才能完成主备间的相互切换,因此,北京电力公司对此是慎之又慎。

缘于此,南京电科院这位好兄弟二话不说立即就朝北京电力公司伸出了援手。为了保证在北京部署的负载均衡系统能够一次上线成功,遂于金陵搭环境、做模拟系统、进行测试,让厂商先在这里练练手,再北上挑战帝都的电力生命线。

当时蛰伏于南京电科院的,正是那世界知名ADC厂商F5。经历了几番波折,可算是试验成功,此西洋厂商遂志得意满准备勇闯帝都。

哪成想,北京电力公司系统比金陵城里的更为错综复杂,F5在金陵使的招数到了帝都就不好使了。

虽然急得是汗流浃背上蹿下跳的,但是连着上了两次,即使是在测试环境中将vs类型改为了standard模式关联UDP的profile以触发irules中的事件,也依然无法实现主系统切换到备份系统后再重新切换回主系统,F5最终得出结论,当前版本无法完成主备配置的切换,遂泪洒沙场败走帝都。

当此紧急关头,谁能挑此重任?!

阅读更多