-
FusionCompute VRM和CNA节点通信异常，9527 端口不通
问题描述 1、版本：FusionCompute R3C00SPC300； 2、VRM未主备部署 3、FusionCompute VRM和CNA节点通信异常，VRM cluster 9527 端口不通； 告警信息 VRM cluster 9527 端口不通 处理过程 1、通过Putty登陆VRM主节点； 2、执行service pmcd restart和service cepd restart重启pmc和cep进程； 根因 1、9527为 监控PMC模块对PMA提供的发送数据服务的端口 ，若故障，影响监控数据从CNA上报到VRM； 2、问题原因为监控系统在进行RPC连接后PMC端未及时释放已有连接导致PMC挂死，致使监控信息不能上报。 建议与总结 目前该问题可通过重启pmc和cep进程规避，后续会通过版本实现。
SE_You
2024-06-11
22 0 0 -
Fusioncompute V100R003C10SPC100无法收集CNA节点CPU/内存/磁盘等信息
问题描述 Fusioncopute运行正常，但是通过FusionCopute无法获取CAN01节点的硬件信息，包括CPU/内存/磁盘等硬件信息，查看CNA节点上的Guest OS运行正常，网络ping运行正常，CNA网络运行正常； 告警信息 无 处理过程 1. 先使用putty登录CN A 节点。 su - root 切换成root用户。 2. 使用 service pmad status 查询监控进程是否正常。 返回结果为：unused; 正常情况返回结果是：running 3. 使用 service monitord status 查询监控进程是否正常。 返回结果为:unused 基本可以确认为服务异常关闭； 辅助命令： Chkconfig pmad Chkconfig fmad 4. 检查服务安装情况： rpm –qa|grep G 服务已正常安装； 5. Chkconfig monitord on Sevice monitord start Service monitor status Service cron status 问题解决，FC可以正常查看CAN节点的物理资源了。 还可获取 /var/log/galaxenginelog/pma/pma.log 查看相关日志信息； 根因 CNA节点上的monitor服务异常停止，Fusioncompute无法调用其进行信息收集； 建议与总结 无。
SE_You
2024-06-07
21 0 0 -
FC Portal告警 – 光纤链路闪断
问题描述 R3C00SPC20，FusionCompute portal界面出现主机光纤中断告警，用户虚拟机HA，如果是VRM虚拟机所在的主机出现此问题，则VRM会主备倒换，同时主机会重启。 告警信息 FusionCompute portal界面出现主机光纤中断告警 处理过程 1、 修改brocade的交换机在8G模式时的端口fill word改为1 2、 升级驱动LPFC驱动至8.3.7.18版本。 根因 1、 所有主机与FCSAN A控相连的2条逻辑链路均无法扫描到，只有与B控相连的两条链路工作，但物理链路是正常的。怀疑可能是brocade交换机端口速率为8G时与qlogic交换板之间存在硬件兼容性问题，其不兼容的原因是：brocade的交换机在8G模式时会使用IDLE作为fill word，这是一个不符合标准的行为。所以通过在brocade交换机上将连接主机侧端口的fill word改为1来修改该不兼容问题。 2、 hba卡的LPFC驱动存在bug，需要升级驱动LPFC驱动至8.3.7.18版本。 建议与总结 无
SE_You
2024-06-06
22 0 0 -
FusionCompute R3C00站点如何修改虚拟机起始id
问题描述 由于FusionCompute站点的虚拟机id都是从i-0000001顺序新增； 多个FusionCompute站点对接一个FusionAccess或者FusionManager系统，会出现虚拟机id重复的现象； 为了方便运维，涉及多个站点的场景，需要手工修改虚拟机id起始顺序 注：FusionCompute Portal不支持修改虚拟机id起始顺序 告警信息 无 处理过程 1、通过root账号登陆VRM主节点； 2、执行psql -U galax vrm登陆VRM数据库，执行select setval('vm_vm_id_seq',50000); 50000为设置的虚拟机的起始值，如下图所示 根因 无 建议与总结 FusionCompute站点的虚拟机id为16进制，需要根据各个站点虚拟机数量，合理规划虚拟机id段
SE_You
2024-06-05
14 0 0 -
FusionCompute 升级后X6000服务器重启
问题描述 某局点升级后X6000服务器重启 告警信息 无 处理过程 1、升级R3C00版本时，升级X6000服务器的BMC版本至2.16以上。 2、通过关闭硬件狗方式规避，和异构服务器场景保持一致。 根因 在suse5.4版本中， ipmi模块在不需要轮询的时候，就不执行定时器函数smi_timeout()；因此再下一条指令发送的时候就会有可能导致，time_diff的值大于1000ms，这个值超出了KCS模块的超时上限，因此OS会误判断为超时，会进入KCS异常，导致BMC不响应OS，导致看门狗超时复位。 UVP R3是内核版本为2.6.32.36 升级到 3.0.58-0.6.6 ，正好在2.6.32.54 内核修改范畴内。R3版本相对R2版本的IPMI消息大幅增加（统计impi驱动对BMC寄存器的操作次数，1个半小时，R3：1699841200；R2：611230500)。在服务器压力较高时在R3C00版本且BMC版本为2.15及以下时会触发服务器重启。 建议与总结 无
SE_You
2024-06-04
20 0 0 -
FusionCompute CNA节点无法扫描到SAN存储设备
问题描述 CNA节点无法扫描到SAN存储设备 告警信息 无 处理过程 一、首先排查是否是由于存储配置错误导致扫描不到存储设备 1、使用“PuTTY”，登录当前扫描的CNA节点。以“gandalf”用户，通过管理平面IP地址登录。 2、 执行以下命令，按提示输入“root”用户的密码，切换至“root”用户。 su - root 3、 执行以下命令，防止“PuTTY”超时退出。 TMOUT=0 4、 执行以下命令，进入/dev/disk/by-id/目录 cd /dev/disk/by-id/ 5、 执行命令 ll | grep 60022a11000926270035e9fd0000000a 查找分配给我们环境的LUN是否在CNA上可以发现，其中60022a11000926270035e9fd0000000a为LUN的WWN号(此处只是举例说明，需要具体问题具体对待) 如该命令执行结果回显为空，则说明CNA上发现不了该LUN，执行6 如该命令执行结果回显不为空，如下图： 则说明CNA上已经可以发现该LUN，那么说明SAN存储上的配置没有问题，该LUN已经添加映射，并且CNA的启动器也已添加，由于存储配置错误导致扫描不到存储设备的怀疑点可以排除。需要排查该LUN是否由于存在分区而导致无法被扫描到，执行步骤7。 6、检查SAN设备上配置是否正确，CNA的启动器是否添加给主机且是否将LUN映射给主机（具体方法请参考当前使用的SAN设备的指导手册） 配置正确？ 是：联系华为技术支持 否：按照SAN设备指导说明重新配置，配置完后重新扫描 二、检查存储设备是否存在分区 7、 执行命令 cd /dev/disk/by-id 在该目录下执行命令：ll | grep scsi-360022a11000926270035e9fd0000000a a) 如执行结果如下图1所示， 图1： 图2： 表明LUN 60022a11000926270035e9fd0000000a有一个分区part1，且 LUN 60022a11000926270035e9fd0000000a 对应的盘符为dm-5. b) 如执行结果如图2所示,表明LUN 60022a11000926270035e9fd0000000a没有分区 有------------------执行步骤8 ……
SE_You
2024-06-03
44 0 0 -
FusionAccess R3C00，虚拟机之间业务IP互ping丢包严重
问题描述 FusionAccess R3C00 虚拟机之间业务IP互ping丢包严重 1. 同一PortGroup内，用户虚拟机不能互通，但都可分别ping通网关； 2. 基础架构虚拟机之间互ping，总会有1%~3%的丢包; 3. 迁移至同一台CNA，问题依旧。 告警信息 无 处理过程 可能问题点检查如下： 1. 检查服务器物理连线——正常； 2. 交换机配置错误——使用两个笔记本直连交换机网口，相互之间可以正常ping通； 3. 虚拟机所属Portgroup——创建的用户虚拟机，基础架构虚拟机的业务平面同属Portgroup_102； 4. 虚拟机PVdriver驱动异常——检查Xen网卡驱动状态正常，重新安装问题依旧。 5. 虚拟机防火墙未关闭——检查发现已关闭； 6. 把问题虚拟机迁移到同一台CNA上，以上问题依旧； 7. 在交换机上ping问题VM也不通——此时发现问题虚拟机的MAC有漂移现象（infocenter enable后，可以看到有端口down或up，对应的MAC是问题VM的），即发现VM MAC的port在变化，推测网口绑定错误导致。 FusionCompute GPI手册，“操作与维护—>主机和集群管理—>系统接口管理—>绑定网口”章节，注意： 在轮询模式和基于源目的MAC负荷分担模式下，需要在交换机上做端口汇聚配置，即将主机待绑定的网口在对端交换机上的端口配置到同一个Eth-trunk，否则会导致网络通信闪断。 8. 检查发现服务器eth4和eth5（即业务平面网口）绑定关系为轮询，但是上联交换机的端口并未配置Eth-trunk。将该绑定模式改为主备，再次检查互ping，则通信正常。 9. 为什么当虚拟机在同一台CNA上也会发生丢包或ping不同呢？VM的通信不是在CNA内部吗，与上层交换机何关？ a. CNA中的虚拟机交换机 （OVS）也内部也有MAC_PORT 表，并有老化时间。 b. 如果端口绑定轮询，而对端没有配置Eth-Trunk ，会导致虚拟机内部的广播报文在绑定的2个网卡中的一个发出，而从另外一个网卡又收到该报文。 c. 第2……
SE_You
2024-05-31
48 0 0 -
桌面云FC扩容新存储关联失败
问题描述 FC关联异构存储（HP4730）时，主机上已经将存储的业务IP（50.50.50.100）加入iSCSI，存储添加了主机的iqn，网络是通的，但FC管理界面上仍然关联失败。 告警信息 存储关联失败。 处理过程 根据日志分析，存储的IP与主机之间会话没有建立成功，如下图所示。 从存储的物理端口上配置IP确实也是50.50.50.100，如下图所示。 存储与主机之间是直连关系，没有通过交换机，该IP可以在主机上ping通。 经了解，此物理IP功能是即跑管理，也跑业务，但不是专用于跑业务的，跑业务使用的主要是虚拟IP，即在该端口上配置的虚拟IP址（50.50.50.200）； 在FC存储管理内，重新配置存储的虚拟IP，并在主机上重新注册存储的虚拟IP后，关联成功。 根因 存储HP4730的物理端口上的IP地址，即可以作管理，也可以跑业务，但关联存储时需要虚拟IP地址，而非管理地址。 建议与总结 区分存储业务和管理，FC在关联存储时，必须以业务IP链接，才可以关联成功。
SE_You
2024-05-30
8 0 0 -
FusionCompute R3C00创建Win7虚拟机，安装PVdriver时无法开启testsigning功能
问题描述 在使用bcdedit -set testsigning on命令开启testsigning功能时，提示：The boot configuration data store could not be opened. Access is denied. 告警信息 无 处理过程 参照微软社区官方解答发现，该操作需要Administrator帐号来操作： http://answers.microsoft.com/en-us/windows/forum/windows_7-system/error-the-boot-configuration-data-store-could-not/9e995bc8-141c-4ed0-9b17-2dbe92369202 解决方法：在运行cmd时，右键选择“Run as administrator”即可 根因 win7虚拟机损坏，或操作用户权限不够。 建议与总结 开启testsigning和安装PVdriver，都需要“以管理员身份运行”，否则将不成功。 而Win7操作系统安装完成后，一般默认禁用Administrator账户，建议先开启Administrator账户后，再进行相关操作。
SE_You
2024-05-29
11 0 0 -
FC导入License失败
问题描述 客户来电反馈在FC上导入新申请的License时，提示资源不足。 告警信息 如下： 处理过程 1.收集FC的License日志文件分析，目录为： LMS日志：/var/log/galaxenginelog/oms/lms.log LMC日志：/var/log/galaxenginelog/oms/lmc.log 2.收到日志后，查看并分析。 [2013-11-28 14:48:40,603] [INFO ] [tomcat-exec-107] [LoadLicenseService:checkLicenseResourceNumber 1204] licenseNumber=24, currentNumber=40 ////申请的License CPU个数为24，但当前CPU数量为40 [2013-11-28 14:48:40,604] [ERROR] [tomcat-exec-107] [LicenseServerServiceImpl:loadLicense 174] resource is over load.licenseInfoBean=LicenseInfoBean [commonInfo=CommonInfoBean [licenseName=LicenseFile, loadTime=1385621320596, description=null, context=null, licenseNo=LIC2013112706JK60, creator=Huawei Technologies Co., Ltd., createTime=1385621320596, country=UNKONWN, custom=??????????????????????????????, office=UNKONWN, serviceAuthType=COMM, serviceSwmTime=, serviceHwmTime=, serviceSfupdateTime=1480118400000], fileInfo=FileServerBean [licenseName=LICFusionComputeV100R003_2013112706JK60.dat, loadTime=1385621320596, description=, licenseContext=Huawei Technologies Co.,Ltd. All rights reserved. 根因 由于当前CPU个数为40个，申请的License CPU使用数量只有24个，从而导致导入失败。 建议与总结 申请License文件之前，先规划好需要使用的CPU个数。
SE_You
2024-05-28
16 0 0
FusionCompute
