LTM设备的运行维护-应急处理-技术支持流程

LTM设备的运行维护运维常用命令介绍列举运维过程中的常用命令，方便速查。详见附件。F5设备日常检查日常监控：对设备performance数据，syslog告警，主备状态，网络状态等设置监控事件处理：对特殊事件及时告警并及时正确收集数据定期巡检：〔模板见附件〕使用ihealth工具进行设备巡检〔v10〕检查设备根本配置是否符合总行有关要求。检查负载均衡设备CPU、内存等性能参数是否正常。检查负载均衡设备硬盘空间、连接数等性能参数是否正常检查负载均衡设备系统运行及日志是否正常。检查设备上是否有异常事件和告警信息。检查ihealth工具是否有风险报告，并及时更正。对主备设备的非同步配置进行比照〔bigip_base.conf等〕系统安装方法及流程系统初始安装的流程，详见附件。软件版本升级方法及流程软件版本升级的流程，详见附件。常见故障现象-硬件故障告警/现象原因处理建议

设备产生如下日志，并无法启动：

WARNING:CPUencountered255single-bitSDRAMECCerrors(corrected)

WARNING:CPUencountered255single-bitSDRAMECCerrors(corrected)

WARNING:CPUencountered255single-bitSDRAMECCerrors(corrected)

内存问题联系技术支持RMADamon日志中：Mar2006:43:00local/blu-f89-abch-3acritsmartd[4550]:Device:/dev/sda,3Currentlyunreadable(pending)sectors

Mar2007:13:00local/blu-f89-abch-3acritsmartd[4550]:Device:/dev/sda,3Currentlyunreadable(pending)sectors

Mar2007:43:00local/blu-f89-abch-3acritsmartd[4550]:Device:/dev/sda,3Currentlyunreadable(pending)sectors

Kern日志中发现：

Oct510:05:21local/NF39SL01-F3errkernel:ata1.00:status:{DRDYERR}Oct510:05:21local/NF39SL01-F3errkernel:ata1.00:error:{IDNF}Oct510:05:21local/NF39SL01-F3warningkernel:Oct510:05:21local/NF39SL01-F3warningkernel:end_request:I/Oerror,devsda,sector160014091Oct510:05:21local/NF39SL01-F3errkernel:BufferI/Oerrorondevicedm-17,logicalblock25160Oct510:05:21local/NF39SL01-F3warningkernel:lostpagewriteduetoI/Oerrorondm-17

可能为硬盘坏道，也可能为ID405839引起误报警联系技术支持确认

设备产生如下日志，

Oct100:24:01NF68SL08-B5system_check[18039]:010d0006:0:Chassispowersupply101isnotsupplyingpower(status:0):makesureitispluggedin.

一般为电源故障联系技术支持确认并RMA设备console无输出

分析方法：

观察前面板灯是否亮起，如果无灯，更换电源等部件。如亮起，检查Console线，如确认Console线无问题，但设备仍无输出

联系技术支持RMA排错方法—软件、告警、网络等问题软件，告警，网络等问题重启,切换，进程重启等，可以查看进程状态〔bigstartstatus)，日志/var/log/ltm及tmm等。发生performance问题，及时抓取top等performance等信息也很关键网络，业务问题一定要抓取Tcpdump。常见告警-软件故障告警/现象版本结论及处理建议管理界面显示:errorpage"nocontentpagetodisplay",

/var/log/httpd日志显示

Oct10,20124:02:12AMmon.ChannelSocketinitINFO:JK2:ajp13listeningonlocalhost/:8009

Oct10,20124:02:12AMorg.apache.jk.server.JkMainstartINFO:JkrunningID=0time=0/32config=/usr/local/tomcat4/conf/perties

2012-10-1013:47:44,691ERROR[Thread-21]controller.TilesInterceptor:getDefinitionUrl-FailedduringaTilesdefinitionlook-up

2012-10-1013:47:50,690ERROR[Thread-20]v9Java及httpd问题。

重启tomcat4及httpd进程可以解决。

Syslog事件：

1NF39SL02-F2mcpd[3960]:01070408:5:Deletingabandonedsubscriberconnectionforreflector_Subscriber12-10-174:02:0412-10-17v10.2.4

logrotation时的安全日志,可安全忽略Jan1300:40:01tmmtmm[1220]:011f0007:3:http_process_state_parse_header-InvalidactionEV_BODY_COMPLETEduringST_HTTP_PARSE_HEADERS

Jan1300:40:01tmmtmm[1220]:011f0008:3:http_process_state_parse_header-InvalidstatetransitiontoST_HTTP_ABORTED系统收到不规范的（non-RFC）Request或者异常POST会出现这个errmessage

但是这个不会影响其他正常的业务数据流。如果长期出现建议抓包分析ltm日志

Inetportexhaustionon1to5:9000

all此类告警说明snat地址1的端口已经用完，这时会引起新的链接被丢弃，无法正常链接，此时需要添加snatpool增加snat地址及总的端口数。LTM日志

011e0002:4:sweeper_update:aggressivemodeactivated.

all此类告警说明日志发生时大量的内存被耗尽，导致memory使用超过阀值导致生成此日志，一般可能为突然大量的链接（ddos）造成，RAMcache大量使用，或者内存泄露，如日志长时不消失，此时应该引起注意，查看相应的performance并采取相应应对措施。

/var/log/ltm出现如下日志：

tmmtmm[1609]:011e0001:4:LimitingclosedportRSTresponsefrom299to250packets/sec或

tmmtmm[1609]:011e0001:4:Limitingicmpunreachresponsefrom299to250packets/secall此类告警说明日志发生时，LTM因收到无法match连接表的tcp或icmp连接而发送的RST已经超过了阈值，这一般可能为网络异常，如ddos等，需要引起注意。

一般这个阀值为250

一般故障现场需要收集的信息(1)抓包文件：使用tcpdump在F5上抓包，如果有可能在backendserver/clientmachine同时抓包或同时在浏览器运行watch，抓包命令如下：

#tcpdump–nni0.0:nnn–s0–w/var/tmp/xxxx.caphost<clientIP>orhost<VIP>orhost<poolmemberIP1>orhost<poolmemberIP2>

*由于F5采用的是full-proxy模式，抓客户IP和VIP只能抓到客户端的traffic，不能抓到server端的，请进行抓包时多加考虑，添加适宜的IP地址不支持F5自带的：nnn，在上可以去掉，只写0.0〔表示所有进出traffic〕*可以针对vlan或者interface抓包，针对mgmt抓包，一般情况下mgmt是eth0，可以在F5上通过ifconfig查看*可以添加端口号或协议名抓取特定的数据包*可以加-c抓取一定数量的包，针对业务流量大的情况下*如果抓包文件是关于ssl流量的，请用ssldump命令在F5上解开tcpdump，解成明文，然后将解密的明文和tcpdump一起提交给support，便于查看：

一般故障现场需要收集的信息(2)

抓取qkview：qkview尽量在故障的时候抓取，重启之后抓取的qkview十分干净，几乎看不出来任何信息。命令如下：#qkview,thentakeout$HOSTNAME.tech.outfrom/var/tmp/抓取log日志，这个一定要抓取，qkview中的log不全。命令如下：#tarzcvf/var/tmp/$HOSTNAME-logs.tar.gz/var/log/*,thentakeout$HOSTNAME-logs.tar.gzfrom/var/tmp/抓取

RRDdatatarball：#tarzcvf/var/tmp/$HOSTNAME-rrd.tar.gz/var/rrd/*,thentakeout$HOSTNAME-rdd.tar.gzfrom/var/tmp/抓取SCCPlogtarball：#sshsccp"tarczvf-/var/log/">/var/tmp/$HOSTNAME-sccp-logs.tar.gz,thentakeout$HOSTNAME-sccp-logs.tar.gzfrom/var/tmp/一般故障现场需要收集的信息(3)抓取故障截图，在客户端是什么表现？网页打不开？效劳能否登录？客户收到了什么样的报错信息？

开case的时候，尽量说明出问题的VS或者给出对应的IP地址，以方便support查询，节省时间。

如果疑心硬件问题，尽快安排时间做EUD。运行EUD的时候请拔下所有的网线，连好console，留存consoleoutput，和EUDreport一起提交给support以节省时间。

有效收集信息-对收集信息进行检查信息类型检查方法TCPdump是否包括客户端和服务器端两方向的包信息（SNAT很容易影响数据包收集）是否能反映出问题出现的现象，需要在提交时指出问题stream

序列号SSLdump

是否包含已解密的应用数据Coredump必须使用md5sum在机器上检查，并且在提交前在PC上进行检查Qkview,log生成时间是否正确，是否可以正确解压缩，尽量提供V10的ihealth链接Debug是否为问题出现时收集，并指出问题出现时间点和收集方法Policy是否为问题VS所使用UCS是否可以正确解压缩其他按NSE提供方法检查，并提供准确详细的测试步骤一键故障采集工具实现功能：

一键收集所有开CASE需要的资料，包括var/log日志，tcpdump，qkview，UCS，打包上传到指定效劳器目的：快速收集故障现场资料，减少和support之间的来回资料收集请求，可用于自动排障脚本中的前置脚本实现语言：SHdate_tag=`date+%Y%m%d%H%M`/usr/sbin/tcpdump-ni0.0-s0-nnn-c3000-w/var/tmp/$HOSTNAME-$date_tag-tcpdump.captarzcvf/var/tmp/$HOSTNAME-$date_tag-logs.tgz/var/log/*/var/core/*tmshsavesysucs/var/tmp/$HOSTNAME-$date_tag-ucsqkview-f/var/tmp/$HOSTNAME-$date_tag-qkview.tgzcd/var/tmptarzcvf/var/tmp/CASE-$HOSTNAME-$date_tag.tgz$HOSTNAME-$date_tag-tcpdump.cap$HOSTNAME-$date_tag-logs.tgz$HOSTNAME-$date_tag-ucs.ucs$HOSTNAME-$date_tag-qkview.tgzecho""echo"========Notice========"echo"pleasesendthefile/var/tmp/CASE-$HOSTNAME-$date_tag.tgztoF5support"LTM设备的应急处理场景一：某台效劳器对外效劳不可用具表达象：应用部门反响某业务对外效劳不稳定，局部客户端请求无法回复，查看相关效劳器后发现有一台或者几台效劳器的应用程序发生故障，但不完全影响该业务对外效劳。启动依据：由应用部门通知。影响范围：影响当前F5分配到该〔几〕台效劳器上的业务。处理方案：1.应用部门通知网络部在F5上隔离该效劳器。2.登陆相关F5，将相关节点效劳器隔离。3、待该效劳器应用程序恢复正常后，由应用部门通知网络部门重启启用该节点。登陆相关F5，将相关节点效劳器恢复。验证方案：应用部门登陆恢复效劳器，检查应用状态是否正常，是否有连接分配。场景二：两台F5设备均为ACTIVE状态具表达象：两台F5设备均为ACTIVE状态影响范围：不对业务造成影响，但存在隐患。处理方案：1．确认两台active状态的F5设备中，哪一台是当前在用的，通过以下两种方式进行确认，正常情况下，因为冗余连接失效，当前在用的F5设备应该是原先备用的那一台。1〕使用s登录到两台F5设备的sharedip，查看是哪一台设备；2〕在核心交换机上查看arp表中，以cisco交换机命令为例，showiparp“sharedip〞，确认对应的是哪一台F5设备的MAC地址。2.检查心跳线连接，排除由于心跳线松动造成冗余连接失败的情况。3.心跳线连接恢复正常后，对当前处在备用状态的F5设备进行重启操作〔应该是原先主用的那台F5设备〕。这时网络中会恢复为只有一台主用F5设备的情况〔重启备机不会影响业务〕。验证方案：以V9|V10版本下命令为例，登陆F5设备通过命令:bfailovershow，确认F5主备关系是否恢复正常。场景三：主用F5设备发生故障具表达象：主用F5上所有业务受到影响。影响范围：该套F5上所有业务。处理方案：1．SSH方式登陆F5设备，以V9|V10版本下命令为例，通过命令：bfailoverstandby行进行主备切换,检测是否切换成功。2、如果失败,那么通过下电方式关闭主用故障F5。3、SSH方式登陆备机，以V9|V10版本下命令为例，通过命令：bfailovershow判断备机状态是否已经变为active。验证方案：1、登陆F5设备，以V9|V10版本下命令为例，通过命令:bfailovershow，确认F5主备切换是否成功。2、应用部门通过登陆方式作技术验证。场景四：两台F5设备同时出现故障具表达象：两台F5设备同时不可用，该套F5上所有业务受到影响。影响范围：该套F5上所有业务。处理方案：1、强制切换，关闭原先主用的F5设备，检测是否切换成功。2、如果仍然故障，那么关闭原先备用的F5设备，下电重启原先主用设备后，检测系统状态。3、仍不能恢复正常的话，采用冷备设备作为应急。验证方案：1、通过SSH方式登陆F5设备，以V9|V10版本下命令为例，通过命令:bfailovershow，确认F5主备切换是否成功。2、应用部门通过登陆方式作技术验证。场景五：客户端异常行为导致F5性能容量耗尽具表达象：主用F5设备出现CPU或内存利用率持续超警戒阀值〔警戒阀值的具体值可根据该套F5所承载的应用数量及性能状况等因素来设定〕。网络部监控到F5产生如下告警：InetportexhaustiononX.X.X.XtoA.B.C.D:X(proto6)。平安部监控到分行某个客户端向此套F5设备上的某个访问地址大量发异常数据包。影响范围：该套F5上所有业务。处理方案：1、通过SSH方式登录F5设备，以V9|V10版本下命令为例，通过命令:bconnclientX.X.X.X,确认分行客户端是否与此套F5设备上的某个访问地址大量建立连接。2.登录相应与F5互联的交换机，将客户端进行隔离3.以V9|V10版本下命令为例，通过命令行:top或网管proviso系统确认此台F5设备性能容量是否恢复正常〔CPU及内存利用率均处于30%以下〕。

验证方案：1、SSH方式登陆F5设备，通过命令行:top或网管proviso系统确认此台F5设备性能容量是否恢复正常〔CPU及内存利用率均处于30%以下〕。场景六：F5并发连接数超阀值具表达象：网络部监控发现F5并发连接数超阀值，且持续时间较长。影响范围：该套F5上业务均受到不同程度影响。处理方案：1、HTTPS方式登陆F5，以V9|V10版本下操作为例，依次点击“VirtualServer〞->“Statistics〞，确认当前访问量最高的3个应用；2、临时躲避方法为在F5上限制这3个应用的并发连接数，由于会影响到正常访问，需征求相关部室意见；3、登陆相关F5，以V9|V10版本下操作为例，点击进入相应VirtualServer,临时将connectionlimit设置为XXX〔一般为效劳器台数*100〕，待F5并发连接数恢复正常后，再商开发中心、应用部门逐步调大connectionlimit限制；4、网络尽快确定方案，利用备机，完成F5扩容，彻底解决F5并发连接数高对设备造成冲击，届时再取消connectionlimit限制。验证方案：SSH方式登陆F5设备，以V9|V10版本下命令为例，通过命令:bconn|wc-l，确认F5并发连接数下降至阀值以下，且设备运行正常。场景七：某台F5CPU利用率超阀值具表达象：网络监控发现F5CPU利用率超阀值，且持续时间较长，业务人员反映局部业务访问缓慢。影响范围：该套F5上业务均受到不同程度的影响。处理方案：1、正常情况下F5的CPU利用率达100%后，F5会自动主备切换。2、假设未自动主备切换，那么改为手动主备切换〔以V9|V10版本下命令为例，使用命令:bfailoverstandby〕，再次确认由备用转为主用状态的F5CPU利用率是否超阀值，假设CPU利用率转为正常，那么问题躲避解决，后续再排查已转为备用状态的问题F5设备；假设主备切换后问题还是不能得以解决，那么参照场景四排查问题。验证方案：以V9|V10版本下命令为例，SSH方式登陆F5设备通过命令:top，确认F5CPU利用率下降至阀值以下，且设备运行正常。F5技术支持流程新case的提交步骤一确认机器SN确认机器服务类型确认case联系人，电话及邮件，联系人建议为现场服务商工程师步骤二获取问题背景（如配置更改，网络环境变化等）确认问题具体现象，问题严重性步骤三获取产品信息（激活模块），版本收集相应日志等步骤四通过F5support提交case提交case的三种途径及如何加快响应使用已经开通的websupport账号在线websupport.f5开case，等待工程师响应如果紧急开完case后联系TAM并发送case号技术支持直接开case对于Sev1/2的case可以直接要求转至产品NSE处理Sev3以下case将回电响应邮件

开case响应方式同websupport.Web

邮件开case时一定要准备好前面一页所提到的所有信息，如果之前开过case，可以提供之前的case号，以便客服更快的找到你的联系信息技术支持中心：开通websupportRegisteringforaccesstotheWebSupportportalToregisterforaccesstotheWebSupportportal,performthefollowingprocedure:Loginto.BelowtheOtherSitesYouMayApplyForheading,intheWebSupportsection,clicktheclickherelink.Completetheregistrationpage.Youwillbenotifiedbyemailwith