Cloud Native应用交付

  • 首页
  • 关于本站
  • 个人介绍
  • Downloads
  • Repo
    • Github
    • Container
  • F5
    • F5 Python SDK
    • F5-container
    • F5-LBaaS
  • 社交
    • 联系我
    • 微信/微博
    • 公众号
    • 打赏赞助
行至水穷处 坐看云起时
Cloud Native Application Services: cnadn.net
  1. 首页
  2. F5-Tech tips
  3. 正文

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

2014年09月17日 18425点热度 1人点赞 0条评论

 

在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

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

 

mycisco@ubuntu-jmeter:/var/tmp$ cat httpresponse.py

#!/usr/bin/python

import socket

import sys

import time

import random

from thread import *

HOST = ''   # Symbolic name meaning all available interfaces

PORT = 8888 # Arbitrary non-privileged port

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

print 'Socket created'

#Bind socket to local host and port

try:

s.bind((HOST, PORT))

except socket.error , msg:

print 'Bind failed. Error Code : ' + str(msg[0]) + ' Message ' + msg[1]

sys.exit()

 

print 'Socket bind complete'

#Start listening on socket

s.listen(10)

print 'Socket now listening'

#Function for handling connections. This will be used to create threads

def clientthread(conn):

#Sending message to connected client

#conn.send('Welcome to the server. Type something and hit enter\n') #send only takes string

 

#infinite loop so that function do not terminate and thread do not end.

while True:

 

#Receiving from client

data = conn.recv(1024)

reply = 'HTTP/1.1 200 OK\nContent-Type: text/html\nContent-Length: 4\n\nf5up'

if not data:

break

# delay 10s before sending response.

time.sleep(10)

#if you want to use random sleep,comment the above and use below

#delaytime = random.randint(1,9)

#time.sleep(delaytime)

conn.sendall(reply)

 

#came out of loop

conn.close()

#now keep talking with the client

while 1:

#wait to accept a connection - blocking call

conn, addr = s.accept()

print 'Connected with ' + addr[0] + ':' + str(addr[1])

 

#start new thread takes 1st argument as a function name to be run, second is the tuple of arguments to the function.

start_new_thread(clientthread ,(conn,))

s.close()

相关文章

  • openstack heat模板之配置基本LB到F5 BIGIP
  • F5常见log日志解释
  • F5 TMOS系统操作手册
  • BIGIP DNS (GTM)V12变化速览
  • TMOS/LTM V12.0 行为变化列表 (Release notes)
本作品采用 知识共享署名-非商业性使用 4.0 国际许可协议 进行许可
标签: F5 monitor TCP
最后更新:2016年01月22日

纳米

linjing.io

打赏 点赞
< 上一篇
下一篇 >
页面AI聊天助手

纳米

linjing.io

☁️迈向Cloud Native ADC ☁️

认证获得:
TOGAF: ID 152743
Kubernetes: CKA #664
Microsoft: MCSE MCDBA
Cisco: CCNP
Juniper: JNCIS
F5:
F5 Certified Solution Expert, Security
F5 Certified Technology Specialist, LTM/GTM/APM/ASM
F5 Certified BIG-IP Administrator
  • 点击查看本博技术要素列表
  • 归档
    分类
    • AI
    • Automation
    • Avi Networks
    • Cisco ACI
    • CISCO资源
    • F5 with ELK
    • F5-Tech tips
    • F5技术
    • Juniper
    • Linux
    • NGINX
    • SDN
    • ServiceMesh
    • WEB编程
    • WINDOWS相关
    • 业界文章
    • 交换机技术
    • 化云为雨/Openstack
    • 协议原理
    • 容器/k8s
    • 我的工作
    • 我的生活
    • 网站技术
    • 路由器技术
    • 项目案例
    标签聚合
    flannel network F5 openstack irule docker DNS bigip nginx neutron istio api gtm k8s envoy
    最近评论
    汤姆 发布于 8 个月前(09月10日) 嗨,楼主,里面的json怎么下载啊,怎么收费啊?
    汤姆 发布于 8 个月前(09月09日) 大佬,kib的页面可以分享下吗?谢谢
    zhangsha 发布于 1 年前(05月12日) 资料发给我下,谢谢纳米同志!!!!lyx895@qq.com
    李成才 发布于 1 年前(01月02日) 麻烦了,谢谢大佬
    纳米 发布于 1 年前(01月02日) 你好。是的,因为以前下载系统插件在一次升级后将所有的下载生成信息全弄丢了。所以不少文件无法下载。DN...
    浏览次数
    • Downloads - 183,764 views
    • 联系我 - 118,966 views
    • 迄今为止最全最深入的BIGIP-DNS/GTM原理及培训资料 - 116,497 views
    • Github - 103,653 views
    • F5常见log日志解释 - 79,774 views
    • 从传统ADC迈向CLOUD NATIVE ADC - 下载 - 74,623 views
    • Sniffer Pro 4 70 530抓包软件 中文版+视频教程 - 74,320 views
    • 迄今为止最全最深入的BIGIP-DNS/GTM原理及培训资料 - 67,770 views
    • 关于本站 - 60,905 views
    • 这篇文档您是否感兴趣 - 55,493 views
    链接表
    • F5SE创新
    • Jimmy Song‘s Blog
    • SDNlab
    • Service Mesh社区
    • 三斗室
    • 个人profile
    • 云原生社区

    COPYRIGHT © 2023 Cloud Native 应用交付. ALL RIGHTS RESERVED.

    Theme Kratos Made By Seaton Jiang

    京ICP备14048088号-1

    京公网安备 11010502041506号