-
鲲鹏服务器 raid卡9560-8i频繁通讯丢失告警问题
问题描述 客户运维管理平台近期多次出现服务器bmc告警同类型告警，提示raid卡通讯连接丢失告警。 Communication between the iBMC and PCIe card 2 (9560-8i) failed。 且大部分通过重启后均可恢复。 处理过程 1、通过客户收集的多份bmc sel日志中，均发现相同的报错信息。 2、查看RAID卡日志，均为多次reset 硬盘后出现BMC与raid卡通信失败告警。 3、检查硬盘smart信息，均为正常，无故障。 4、以上现象及日志信息显示和博通RAID卡控制卡复位故障硬盘导致TM 资源耗尽导致RAID卡挂死的问题一致，为博通RAID卡共性问题。 5、通过开启RAID卡OCR (Online Controller Reset)开关完成自愈，检查客户raid配置显示OCR是关闭状态. 根因 博通RAID卡复位 IO超时不响应的硬盘时，有一定概率触发了TM资源耗尽是博通RAID卡共性问题，该问题触发后，可以通过开启了RAID卡OCR (Online Controller Reset)开关，RAID控制卡则会通过重新加载FW进行恢复。由于客户的机器OCR开关未开启，不能完成自愈，最终导致现场告警机器，需要重启解决（重启相当于重新加载FW）。 解决方案 1、开启raid卡ocr自愈功能，开启自愈功能后，恢复时间在30s-60s之间，对上层应用影响较小，恢复后服务器bmc界面的告警信息会自动消除。 ocr开启方法：使用博通raid的工具storcli64，命令行为：./storcli64 /c0 set ocr=on 2、定期对服务器硬盘进行深度巡检，提前巡检排查出存在硬件故障的硬盘。
SE_Gao 2025-11-24
30 0 0 -
鲲鹏服务器raid卡电容反复上线问题
问题描述 陆续收到客户报修设备日志中多次打印The PCIe card 3 (9560-8i) BBU is present 。 告警信息 The PCIe card 3 (9560-8i) BBU is present 。 处理过程 1、在客户提供的日志信息中，raid卡日志发现设备运行过程中存在多次的BBU 的disabled 和enabled状态。如此在WB和WT两个模式下反复切换，会影响设备磁盘读写性能及稳定性。 2、查看raid卡及电容BBU的固件版本。 根因 1、通过查询存在相关通告，PSOC版本为异常版本，建议升级。 结合以上信息，PSOC异常导致9560-8i RAID卡搭配电容时，会出现BBU反复掉线、上线的现象。 解决方案 1、按照要求更新配套的PSOC和FW的固件版本。
22 0 0 -
鲲鹏服务器组建ceph群集顺序写性能问题
问题描述 客户使用12台鲲鹏服务器搭建ceph群集，群集规模： 12个服务器节点，每个节点12块盘，public平面带宽 50000Mb/s，cluster平面带宽50000Mb/s 12台客户端，前11台客户端每台7个卷,最后1台客户端1个卷，共计78个卷 预期结果:12*50000/(3-1)*0.8/8=30000MB/S 而多次都未达到理论值的70%:30000*0.7=21000MB/S 实际测试结果:18977.07MB/S ，不达标无法正式上线。 处理过程 1、检查CPU负载情况 2、通过服务器网卡打流，检查网卡打流结果均正常； 3、修改服务器numa，由4numa改为2numa，后重新测试依旧无效果； 4、通过修改加大测试脚本的线程数，测试略有提升但不明显。 5、通过与客户沟通了解到ceph群集组网情况，发现服务器存在跨交换机组网的情况，建议联系网络人员查看一下网络侧的性能情况。通过对交换机接口性能检查发现，互联端口收发负载不平衡。 根因 分析得出ceph群集跨交换机组网，因配置问题产生网络瓶颈，导致ceph群集性能下降。 解决方案 网络工程师对交换机配置检查后，通过优化网络配置后，上联端口负载平衡后，ceph群集再次测试顺序读写性能提升，达到指标值。 建议与总结 在构建ceph群集系统时建议尽可能不要跨交换机组网，如果无法避免时，一定要做好网络规划和配置检查，减少网络瓶颈对性能的影响。
13 0 0 -
2288V5服务器报错“the disk DISK0 failure
2288V5服务器报错“the disk DISK0 failure （1）前期验证 1）客户现场配置与合同配置一样，没有差异。 2）客户采用3008 IT RAID卡。 3）出现告警后，客户将2框DISK0硬盘交换后，故障服务器故障现象依旧。交叉验证结果表明，故障现象与硬盘无关。 （2）日志分析 iBMC一键收集日志，分析发现DISK告警与RAID卡相关。 告警原因： 3008IT RAID卡接直通背板时，Enclosure ID分配为0xffff，该ID与Hdd对象中配置的默认无效ID相同。 在硬盘和RAID卡点灯确认对应关系后，在OS重启或者硬盘插拔重新识别时，由于已经保存的识别信息中Enclosure ID为0xffff，被认为是无效值，因此会继续识别。 而在后面识别过程中，识别函数会动态检查是否有对应关系建立，这里只会判断RAID卡PD List中的值是否和保存的相等，不区分是否为0xffff，这里会判断为已经识别，所以识别过程直接略过，所以函数最终返回的识别状态仍然为默认的不成功状态。这样导致硬盘Missing告警产生。 解决方法： 在SML lib层修改 get_pd_list接口，对于硬盘Eid为0xffff的情况，将该ID转换成另外一个非0xffff的值，并且保证与PD List中的其他Eid不重复 结论： V5服务器配置3008 IT时，概率性出现BMC误报disk failure现象。 解决方案： V5服务器配置3008 IT时，概率性出现BMC误报disk failure现象。 解决方案： 3008 IT卡升级FW解决。
SE_Zhang 2025-11-14
97 0 0 -
机房供电异常导致服务器电源频繁产生AC Lost告警
机房供电异常导致服务器电源频繁产生AC Lost告警 问题现象描述 问题现象： 某局点多台RH2288 V2（配置750W金牌电源）反复出现电源AC lost告警产生与恢复事件，如图5-94所示，业务运行正常。 图5-94 电源AC lost告警产生与恢复 关键过程、根本原因分析 关键过程： 管理软件iMana读取到电源寄存器0X04信息为input loss，如图5-95所示，对外上报AC LOST，以提示用户排查设备供电环境是否正常。 通过示波器接入客户现场供电环境进行检测，组网示意图如图5-96所示。 通过分析捕获到的电源波形，如图5-97所示，发现两个问题： L-N输入电压的波形畸变比较严重，超过了电源能承受的10%的规格范围。 N-PE线之间的电压峰峰值达到20.6V，说明零线与地线电压差畸变极大（即机房接地条件差），导致电源0x04寄存器状态频繁检测到input loss，触发iMana AC lost告警， 结论、解决方案及效果 定位结论： 机房电源输入端零线和地线电压差畸变过大导致电源AC Lost告警。 解决方案: 优化机房接地，确保零线和地线电压差稳定在2V以内。 经验总结、预防措施和规范建议 排除iMana误告警的情况下，需要排查供电环境，包括但不限于电源线缆、PDU插座、UPS等供电部件。
75 0 0 -
RAID 1主盘有坏块导致重构失败
RAID 1主盘有坏块导致重构失败 问题现象描述 硬件配置： RH2285服务器+LSISAS1078卡+300G SAS*2。 问题现象： 两块盘做RAID1，有块硬盘故障，申请新盘替换，重构失败，新更换硬盘亮黄灯。 关键过程、根本原因分析 关键过程： 使用megacli工具收集RAID卡日志信息，发现重构的时候报错： 2218: 14-07-02,02:08:12 Info:State change on PD 03(e0xfc/s3) from HOT SPARE(2) to REBUILD(14) 2219: 14-07-02,02:09:36 Info:Unexpected sense: PD 00(e0xfc/s0) Path 5000cca043200d71, CDB: 28 00 01 c9 3f 00 00 00 80 00, Sense: F0 00 03 01 C9 3F 0C 18 00 00 00 00 11 14 00 80 00 8A 00 00 F7 CC 00 00 00 19 AA 01 08 B6 00 00 2220: 14-07-02,02:09:36 FATAL:Unrecoverable medium error during rebuild on PD 00(e0xfc/s0) at 1c93f0c 2221: 14-07-02,02:09:36 FATAL:Puncturing bad block on PD 03(e0xfc/s3) at 1c93f0c 2257: 14-07-02,02:10:41 WARNING:Error on PD 03(e0xfc/s3) (Error 02) 2258: 14-07-02,02:10:41 Info:State change on PD 03(e0xfc/s3) from REBUILD(14) to FAILED(11) 2259: 14-07-02,02:10:41 CRITICAL:Rebuild failed on PD 03(e0xfc/s3) due to target drive error 根本原因分析： 分析日志，发现在重构失败的时候，系统报主盘有坏块，导致重构失败。 结论、解决方案及效果 解决方案： 这种情况可以有两种处理方式： 把数据备份，然后重新申请两块硬盘做RAID1，之后把数据拷贝回去，缺点是需要重新安装操作系统以及应用软件。 使用dd或者DiskGenius等工具，直接把整个盘数据拷贝到新的RAID组里面，优点是不需要再重新安装操作系统以及软件。 经验总结、预防措施和规范建议 和1078卡或者2208卡相关问题，一定要使用megacli工具收集RAID……
92 0 0 -
关于3650m4memory battery problems were detected的问题
关于3650m4memory battery problems were detected的问题 第一种输入：windows按回车 ESC推出 第二种 操作前，建议把机器的重要数据做好备份。 具体解决办法—— ※对于已经做好系统的机器，为了防止数据丢失，以下步骤中的第1,2,7,8步尤其重要 关机，拔掉机器的电源线，让机器保持在断电的状态。 拔掉机器所有的硬盘，记住硬盘原来所在的槽位。（做好阵列的硬盘，槽位一定不能打乱！） 开机，在开机自检的时候按ctrl+H，进入webbios的界面 选择配置向导的选项： 选择清楚配置信息： 退出webbios的界面 关机，拔掉机器的电源线，让机器保持在断电的状态。 按原槽位把机器的所有硬盘接回，重启机器即可。
36 0 0 -
查看服务器硬盘型号，raid配置
查看服务器硬盘型号，raid配置 有些情况下系统不是自己装的，raid也不是自己配置的，远程登录系统后可能就不知道系统是否有做raid，raid级别？因此稍微总结一下Linux下查看软、硬raid信息的方法。 软件raid：只能通过Linux系统本身来查看 cat /proc/mdstat 可以看到raid级别，状态等信息。 依靠Linux本身的话一般是两种方式： # dmesg |grep -i raid # cat /proc/scsi/scsi 上面这两个命令很有用哦！ 个人比较倾向于用cat /proc/scsi/scsi + fdisk –l 来查看硬盘信息 第二行显示raid级别为5 Model: ST3600057SS 显示硬盘型号，查后得知为希捷15K 600G硬盘 一共4块，组成raid后总容量应该（4-1）*600=1.8T 我们验证下 执行fdisk –l 结果显示和我之前的判断一致。 还可以用hdparm -i /dev/sda 命令来显示硬盘信息
54 0 0 -
哪些方法可以提高DNS服务器的性能
提高 DNS 服务器性能的核心在于减少查询延迟、降低重复解析压力和优化资源利用，除了配置转发器，还有以下实用方法（以 CentOS/RHEL 上的 BIND 服务为例）： 一、启用并优化 DNS 缓存（最有效） DNS 缓存能存储已解析的域名结果，避免重复向外部服务器查询，直接返回本地缓存，大幅提升响应速度。 确认 BIND 默认缓存机制BIND 默认启用缓存，缓存文件路径在/etc/named.conf的options区块中定义： ini options { // 缓存文件路径（默认已配置） dump-file "/var/named/data/cache_dump.db"; // 缓存大小限制（默认无上限，建议设置） max-cache-size 100m; // 限制缓存最大100MB }; 优化缓存相关参数在options中添加以下参数，延长缓存有效期（根据业务调整）： ini // 最小缓存时间（秒），低于此值的TTL会被强制提升 min-cache-ttl 300; // 5分钟 // 最大缓存时间（秒），超过此值强制失效 max-cache-ttl 86400; // 24小时 验证缓存效果连续两次查询同一域名，第二次响应时间应显著缩短： bash # 第一次查询（无缓存） time dig example.com @127.0.0.1 # 第二次查询（命中缓存） time dig example.com @127.0.0.1 二、合理配置 TTL（生存时间） TTL 决定域名记录在缓存中的保留时间，优化 TTL 可减少无效查询，平衡 “实时性” 和 “缓存效率”。 全局默认 TTL：在named.conf中设置默认 TTL（适用于未指定 TTL 的记录）： ini options { default-ttl 3600; // 默认为1小时 }; 针对记录类型调整： 静态记录（如企业官网）：TTL 设为86400（24 小时），减少重复解析。 动态记录（如电商活动域名）：TTL 设为300（5 分钟），保证及时更新。 三、……
SE_Yang 2025-10-31
201 0 0 -
如何在CentOS/RHEL系列服务器中配置DNS服务器的转发器
在 CentOS/RHEL 系列服务器中配置 DNS 服务器（BIND 服务）的转发器，主要是通过修改 BIND 的主配置文件，指定当本地 DNS 无法解析域名时，将查询请求转发到其他 DNS 服务器的规则。以下是详细操作步骤： 一、环境准备 安装 BIND 服务（若未安装）： bash # 安装BIND主程序和工具 yum install -y bind bind-utils 确认 BIND 服务状态： bash # 检查服务是否运行 systemctl status named # 若未运行，启动服务 systemctl start named # 设置开机自启 systemctl enable named 二、配置 DNS 转发器（核心步骤） BIND 的转发器配置通过主配置文件/etc/named.conf实现，该文件定义了 DNS 服务的全局规则。 1. 备份配置文件（重要） bash cp /etc/named.conf /etc/named.conf.bak 2. 编辑主配置文件 bash vi /etc/named.conf 3. 配置转发规则 在配置文件的options区块中，添加或修改forwarders（转发目标）和forward（转发模式）参数： ini options { # 监听的IP地址（添加服务器本地IP，允许外部查询） listen-on port 53 { 127.0.0.1; 192.168.1.100; }; # 替换为实际IP # 允许查询的客户端网段（如本地局域网） allow-query { localhost; 192.168.1.0/24; }; # 替换为实际网段 # 配置转发器（目标DNS服务器列表，按优先级排序） forwarders { 8.8.8.8; # 谷歌公共DNS 114.114.114.114; # 国内公共DNS 223.5.5.5; # 阿里云DNS }; # 转发模式（二选一） forward only; # 仅转发：本地不解析，完全依赖转发器（推荐纯转发场景） # forward first; # 优先转发：……
19 0 0
服务器
