
今天我梳理了之前的运维管理资料,发现了一个我自己梳理的刀片服务器(vmware虚拟化技术在运营中)安全事故的解决步骤,于是我把它记录为备忘录。
一、恶性事件的应对方式
14:10接到机房运维技术工程师通知,说Opmanager视频监控系统出现了几个宕机情况,而且都是vm虚拟机。
14:12通知机房运维技术工程师检查HP刀片服务器是否有告警,远程登录vcenter检查。远程控制查询在ESX04(10.203.11.64)中发现一个告警,告警信息如下图所示:
14时15分,技术工程师ESX04被告知有警报,然后确定刀片服务器是否有电,并前往主机室确定机器设备上的硬件配置是否有警报。
14:16检查逻辑网线端口是否异常。
如下图所示,发现有两个网口离线。
14:18检查其他刀头,发现ESXI02的匹配网口正常。
14:20登录惠普工具头管理方法控制面板查询,没有发现网络服务器的报警信息。
14:19参考其他EXSI,尝试改变vmnic6和vmnic7的模式,实际 *** 作失败。
更改网络端口模式不起作用。
14时27分,在ESX04中进行vm到另一台服务器的手动转移,转移不成功。
14:58,ESX04服务器上的所有vm虚拟机都处于待机状态。
5:20,ESXI服务器重启,HA自动将打开的vm转移到另一台EXSI服务器上启动。
5:30,ESX04服务器启动成功后,vsphereHA尝试将vm虚拟机自动转移回esx04服务器,但未成功。
15:50,手动将一些vm虚拟机转移回ESX04服务器以观察 *** 作。
二。日志分析
1.远程登录ESXI的cmd,查询vmkernel的日志:
表示由于esxi4使用utc时间,日志中显示的信息将比时间晚8[/s2/]小时
/var/log # cat /var/log/vmkernel.log | grep '2014-12-18' 2014-12-18T03:27:49.106Zcpu46:6396479)WARNING: ScsiDeviceIO: 1211: Devicenaa.60014380064900f30000800000e40000 performance hasdeteriorated. I/O latency increased from average value of 3303 microseconds to68755 microseconds. 2014-12-18T03:31:54.595Zcpu8:16392)ScsiDeviceIO: 1191: Device naa.60014380064900f30000800000e40000performance has improved. I/O latency reduced from 68755 microseconds to 13691microseconds. 2014-12-18T03:32:32.643Zcpu12:17017)MigrateNet: vm 17017: 2061: Accepted connection from <10.203.11.100> 2014-12-18T03:32:32.643Zcpu12:17017)MigrateNet: vm 17017: 2131: dataSocket 0x4100253292f0 receivebuffer size is 563560 2014-12-18T03:32:32.644Z cpu12:17017)WARNING:Migrate: 262: Invalid message type for new connection: 542393671. Expecting message如上面的日志所示:13:27,服务器的特性刚开始降低,I/O延迟时间变得非常大。
2.查询10.203.11.100,查看是否有任何报警:
如图所示,提醒esx04服务器网络端口不正确。
3.其他收集的日志如下,没有异常。
所有的处理方式都是以此为基础,所有的刀片服务器,也就是这个有时候会排气,没有明显的特点。
欢迎分享,转载请注明来源:内存溢出
微信扫一扫
支付宝扫一扫
评论列表(0条)