搜索内容

包含标签：异常 的文章

  • 禁用FC接口账号导致FA调用虚拟机异常

    问题描述 客户反馈通过FA，执行虚拟机的关机操作失败及在FA上监控不到虚拟机的硬件信息。如图： 告警信息 FA告警FusionCompute服务器异常，如图： 处理过程 将该接口用户解锁定，FA上即可正常操作。 根因 1. 登陆到FC查看各项状态均正常。 2. 通过ITApingVRM地址，均可以ping通。 3. 查看vdesktop日志发现，有如下报错信息：通过报错信息，可以看出，账号被锁定导致无法连接到后端的FC。如下图： 4.登陆到FC查看用户权限发现该账号被人工锁定。 建议与总结   经和客户确认，其认为该账号没用，就手动将该账号禁用了。建议后续开局时给客户说明默认的账号不要进行锁定等操作。 原文

    SE_You 2024-10-29
    17 0 0

  • 虚拟化平台物理交换机VLAN配置错误导致FusionCompute网络通信异常

    问题描述 虚拟化平台搭建完成后，在FusionCompute上部署业务虚拟机，为其配置IP及网关地址，测试网络时无法ping通网关地址。 告警信息 无 处理过程 1、在FusionCompute上确认分布式虚拟交换机端口绑定是否有错误，确认无错误； 2、检查S5700物理交换机端口的配置，发现对应端口没有配置好VLAN信息； 3、修改S5700物理交换机对应端口配置： undo port hybrid vlan 1 port hybrid tagged vlan X（业务VLAN号） 4、再次进行ping网关地址测试，问题解决。 根因 同一网段IP地址无法ping通，可能得原因为： 1、分布式交换机业务平面绑定端口错误； 2、物理交换机S5700对应端口或VLAN配置错误。 建议与总结 虚拟平台基于物理平台完成网络通信，搭建虚拟平台前要确保物理交换机配置正确。

    SE_You 2024-07-19
    11 0 0

  • FusionCompute 登录升级工具显示后台服务异常

    问题描述 工程师对FusionCompute进行升级，登录升级工具显示后台服务异常   告警信息 处理过程 先执行下stop.bat停止服务，再到pasql目录下执行dbstop.bat，再执行dbstart.bat，再重新执行start.bat启动服务，如果还是不行，就只有重启下电脑了 解决方案   免责声明：本案例仅供参考不提供专业意见。

    SE_Meng 2023-03-09
    5 0 0

  • iBMC硬盘告警异常问题解决案例

    问题描述 客户在系统下电的情况下将配置在RAID组里硬盘拔出以后，在上电以后将硬盘插入，在整个过程中iBMC都没有告警。 告警信息 客户在系统下电的情况下将配置在RAID组里硬盘拔出以后，在上电以后将硬盘插入，在整个过程中iBMC都没有告警。 处理过程 （1）在系统Power OFF 的情况下拔出RAID组中的硬盘，通过前置面板的电源键对系统上电，在RAID卡完成初始化之前插入硬盘，查看iBMC告警和事件日志。 （2）在iBMC没有硬盘相关告警，硬盘处于RAID组重构过程中。 （3）在系统Power OFF 的情况下拔出RAID组中的硬盘，通过前置面板的电源键对系统上电，在RAID卡完成初始化以后插入硬盘，查看iBMC告警和事件日志。 （4）在iBMC中有“In Failed Array”告警。 根因 通过上述对照实验可以发现，只有在RAID卡完成初始化以后才能检测到RAID组中有硬盘丢失，iBMC中才会显示相应的告警。如果下电状态下拔出的RAID组硬盘在上电以后并且RAID卡尚未完成初始化时插入就会出现RAID卡检测不到RAID组丢失硬盘的情况，从而iBMC也没有相关的告警。 解决方案 RAID卡只有在完成初始化以后才能检测到RAID组中有硬盘丢失，iBMC中才会显示相应的告警。如果下电状态下拔出的RAID组硬盘在上电以后，RAID卡尚未完成初始化时插入就会出现RAID卡检测不到RAID组丢失硬盘的情况，从而iBMC也没有相关的告警。 建议与总结 （1）对于RAID组里的硬盘：只有在RAID卡完成初始化以后拔出RAID组里的硬盘，RAID卡才能检测到RAID组中有硬盘丢失，iBMC中才会显示相应的告警。 （2）对于未配置RAID组的硬盘：硬盘拔出时iBMC无告警。   免责声明：本案例仅供参考不提供专业意见。

    SE_Meng 2022-12-18
    15 0 0

  • Atlas 500 异常重启现象

    问题描述 多台Atlas 500智能小站发生异常重启现象，影响现场业务运行。 处理过程 一线人员反馈现场3台设备出现异常重启现象，收集日志后，首先通过MCU日志确定系统重启的时间（MCU侧时间慢8小时，与OS日志对应时，加上8小时）； 对应OS_Drivers下的kbox日志，系统重启时间与kbox记录时间吻合； 查看重启时的kbox日志，都存在out_of_memory+0x210/0x530以及oom stack堆栈相关记录，meminfo中可用内存为0Kb，确认重启原因为内存耗尽； 根据kbox日志，可确认内存溢出时的top 10进程，如下所示，其中红框标示的数据为重启时进程占用物理内存的数值，单位为pages，数据x4Kb便可计算出重启时进程占用内存的大小： xbull () ./xbull : 632146 *4Kb=2.41G java () /usr/jdk/bin/java : 77560*4Kb=0.3G mysqld ():49544 *4Kb=0.19G java () /usr/jdk/bin/java -Xms256M : 62186*4Kb=0.24G java () /usr/jdk/bin/java : 49718*4Kb=0.19G 经计算可知，以上用户的业务程序，占用了大量的物理内存（总内存4G），约3.4G； 日志中total_top_10_rss=916805(pages)表示当前top10 进程总的内存使用页（pages），乘以4Kb可换算出已使用的内存，916805*4Kb=3.5G，而total_rss_all=942163(pages)表示系统可用总页数，942163*4Kb=3.6G，可以内存基本已占用完。 另外两台设备kbox日志记录同样的问题，由此可确定，异常重启的原因是客户相关业务进程占用了内存过多导致系统内存不足，触发复位。 根因 用户运行的程序或者业务进程占用内存过大，剩余系统内存不够导致系统重启 解决方案 建议用户排查业务、分析内存占用率高的相关进程，降低内存消耗，修复内存泄漏问题 免责声明：本案例仅供参考不提供专业意见。

    SE_You 2022-07-11
    18 0 0