包含标签:故障 的文章
  • 桌面云虚拟机卡顿故障

    问题描述 虚拟化环境出现部分虚拟机使用卡顿。在CNA上统计IO延时,发现IBM存储对应的LUN IO读写不高,但IO延时每间隔5S左右会达到1000ms以上,IO 利用率达到100%。 处理过程 1. 在卡顿虚拟机所在CNA上执行“IOSTAT”命令,发现IBM存储对应的LUN IO读写不高,但IO延时(await)每间隔5S左右会达到1000ms以上,IO 利用率(util)达到100%。此现象说明CNA到IBM储存读写延时较大,到S2600T正常。 2. 进一步排查10台CNA的系统日志,发现日志中都有 “end_request: I/O  error, dev  sdb, sector  xxx” 错误,对应的WWN为“wwn-0x600a0b800047bd1a00003eb253da0bb2”和“wwn-0x600a0b800047bd1a00003eb453da0bd0”,日志说明CNA在这两个LUN上读写数据时出现错误。 3. 在FusionCompute中查询,异常LUN在IBM存储上,对应的数据存储为“SYVIR_IBM_FC_SAS01”和“SYVIR_IBM_FC_SAS03”,IBM存储上另外一个数据存储“SYVIR_IBM_FC_SAS02”业务正常。 4. 在IBM储存管理平台上查看,异常LUN在同一个raid组中。 5. 登录S2600T和IBM正常LUN上的虚拟机进行测试,虚拟机运行正常,未出现卡顿。 以上5点可以确认,IBM存储异常导致用户虚拟机慢。 6. IBM储存一个机头挂了2个硬盘框,每个硬盘框一个raid组,其中一框正常,另外一框有异常,可以说明CNA到光交换机再到存储控制器光链路正常。 7. 收集IBM存储的日志,发现 majorEventlog.txt 中一直打印“Controller cache not enabled or was internally disabled”和“Mode select for redundant controller page 2C received”两条错误日志,在网上搜索有相应的案例,根据案例排查,异常LUN所属控制器在不停切换。通过将异常LUN绑定到IBM的B控制器上,业务恢复正常,CNA侧 “I/O   error”错误日志不再出现。 综述:虚拟机卡顿原因为IBM存储异常,导致归属A控制器的两个LUN在两个控制器间不停切换……

    SE_You 2024-10-09
    24 0 0
  • 全新NGFW ONC引流方案故障处理案例

    1、故障背景 场景拓扑 现网拓扑和业务说明如下: 整体方案采用INC ServiceChain引流方案,模式为透明模式(no sw+no ip)模式。防火墙采用路由模式虚拟连接对方法。 故障现象描述 开启INC的业务编排,对业务进行引流到防火墙后,业务不通。 2、故障排查方法 2.1故障定位 此故障为硬件问题,是由于防火墙NP芯片故障导致。 2.2故障原因分析 1、 定位故障点 防火墙进行sniffer抓包,现场并未抓取到报文,怀疑是引流交换机问题。 防火墙抓包命令:diagnose sniffer packet any  ‘host x.x.x.x’ 4 l 如果有抓到报文,但没有进行转发,可确定是防火墙问题,可结合debug功能判断是什么原因导致的丢包。 diagnose debug enable          //开启debug diagnose debug flow filter addr x.x.x.x             //过滤x.x.x.x的地址相关debug信息 diagnose debug flow trace start 10           //打印10条debug信息 如果没有抓取到报文,大概率是引流交换机方面的问题。 2、查看INC和交换机配置,并未发现问题 3、查看INC下发的流表 使用show of flow 查看流表下发情况,参数是否正确以及count值是否有变化。如果相应的count字段的数值有不断增加,说明引流成功。 获取的其中一个流表如下: {table="0", duration_sec="177", priority="1500", flags="0x0",idle_timeout="0", hard_timeout="0",   cookie="0xe51efb3520000",packet_count="10",byte_count="1298".match=oxm{in_port=“1",eth_type="0x800",ipv4_src=“30.7.0.0",ipv4_src_mask="255.255.255.0"}instructions=[apply{acts=[set_field{field:eth_src=“00:d0:f8:22:33:e5"},   set_field{field:eth_dst="1a:11:11:11:13"}, output{port=“2"}]}]} 相关字段解析: 1) duration_sec="177" 表项存在的时间 2) priority=“1500”:该流表的优先级,越大越优先。 3) ……

    SE_You 2022-06-14
    31 0 0
  • 全新NGFW-LDAP认证故障处理案例

    1、故障背景 场景拓扑 故障现象描述 背景描述:外网员工使用SSLVPN拨入内网,VPN拨号的账号密码需要到服务器上做认证,防火墙通过LDAP将客户端的账密发送到服务器验证,验证通过即可拨入VPN。 故障现象:使用本地账号密码可以认证成功,但是通过LDAP认证失败。 2、故障排查 2.1故障定位 原因:用户提供的防火墙查询账号密码错误,以及账户超期导致LDAP认证失败 2.2故障原因分析 1、对比服务器上的根,OU,containers,Group,在防火墙上设置对应属性,这些属性只能在命令行配置,配置如下图: 2、防火墙上有测试LDAP认证的命令,命令如下,如图防火墙上测试提示失败,说明防火墙的LDAP配置参数可能有误。 diagnose test authserver ldap <LDAP server_name> <username> <password> 3、通过以下命令可以查看LDAP认证过程,debug显示内容如下,标注的地方可以看出认证错误的原因分别是账号密码错误和账户超期导致认证失败。 # diagnose debug application fnbamd –1 # diagnose debug enable [1148] fnbamd_ldap_recv-Response len: 104, svr: 192.168.1.10 [829] fnbamd_ldap_parse_response-Got one MESSAGE. ID:1, type:bind [851] fnbamd_ldap_parse_response-Error 49(80090308: LdapErr: DSID-0C09042A, comment: AcceptSecurityContext error, data 52e, v3839)   <----- 这两个提示信息表示LDAP 身份认证无效,data52e一般代表账号密码错误 [864] fnbamd_ldap_parse_response-ret=49 [753] __ldap_stop-svr 'AD_LDAP' [182] fnbamd_comm_send_result-Sending result 1 (error 0, nid 0) for req 237259384 authenticate 'user1' against 'AD_LDAP' failed! [860] fnbamd_ldap_send-sending 116 bytes to 192.168.1.182 . . . [764] fnbamd_ldap_parse_response-Got one MESSAGE. ……

    SE_You 2022-06-12
    30 0 0