gpu服务器IDC运维

# 了解 Zabbix 监控”，那用 Zabbix 监控 GPU 服务器的显存使用率，需要怎么做？具体步骤说清楚。

“用 Zabbix 监控 GPU 显存使用率的步骤：

1. 被监控机安装 Zabbix Agent，并确保nvidia-smi命令可执行；
2. 在 Agent 端编写脚本（如gpu_memory.sh），通过nvidia-smi --query-gpu=memory.used --format=csv,noheader,nounits提取显存使用值；
3. 在 zabbix_agentd.conf 中添加UserParameter=gpu.memory.used,/path/to/gpu_memory.sh；
4. 重启 Zabbix Agent 使配置生效；
5. Zabbix Server 端创建监控项（键值为 gpu.memory.used，类型为 Zabbix 客户端）；
6. 设置触发器（如当使用率 > 90% 时告警）；7. 创建图形关联该监控项，实现可视化展示。”

# “参与过 IDC 机房设备上架”，那你说一下服务器上架前需要做哪些检查？上架时的操作规范是什么？

“服务器上架前检查：

• 1. 外观检查（机身无磕碰、接口无损坏、螺丝无松动）；
• 2. 资产核对（SN 号、配置参数与工单一致）；
• 3. 功能预检测（BMC 管理口 ping 通、硬盘 / 内存通过预启动检测工具验证、电源模块测试）；
• 4. 机柜适配性检查（服务器尺寸与机柜 U 位匹配、PDU 功率满足设备功耗需求、导轨型号兼容）。

上架操作规范

• 1. 双人协作（一人托举服务器保持水平，一人引导入导轨，禁止单手拎拽）；
• 2. 固定规范（用指定规格螺丝对角锁紧服务器与导轨，扭矩符合要求）；
• 3. 布线要求（强弱电分离走槽，线缆标签朝向一致，不遮挡服务器散热孔，冗余线缆捆扎整齐）；
• 4. 电源规范（双电源分别接入不同 PDU 回路，确保冗余）；
• 5. 上架后验证（上电检查指示灯状态，通过 BMC 确认硬件识别正常，登记资产到 CMDB 系统）。

# 用 Ansible 批量升级 NVIDIA 驱动的 playbook，核心模块和任务是什么？至少 3 个关键任务。

# 核心模块

• apt / dnf（包管理）
• systemd（服务管理）
• command / shell（执行驱动校验）

# 关键任务（3 个）

1. 停止图形 / 显卡相关服务，卸载旧驱动
2. 安装指定版本 NVIDIA 驱动及 DKMS 依赖
3. 加载 nvidia 内核模块，验证 nvidia-smi 正常

标准答案：“Ansible playbook 批量升级 NVIDIA 驱动的核心模块包括
yum/apt（依赖安装）、
copy（传输驱动包）、
command（执行驱动安装命令）、
systemd（管理服务）。

关键任务：

1. 禁用 nouveau 驱动（用lineinfile模块修改黑名单配置，command模块执行dracut -f更新 initramfs）；
2. 卸载旧驱动（command模块执行nvidia-uninstall --silent）；
3. 3. 安装依赖（yum模块安装gcc、kernel-devel、dkms）；
4. 4. 安装新驱动（command模块执行sh NVIDIA-Linux-x86_64-xxx.xx.run --silent）；
5. 5. 验证驱动（command模块执行nvidia-smi，检查输出的驱动版本是否正确）。”

# 岗位要求里提到需要 “处理简单的突发故障”，如果 IDC 机房某机柜突然断电，你的第一反应和处理步骤是什么？

# 第一反应

立即确认是单柜空开跳闸还是上游配电柜 / 市电故障，禁止盲目合闸。

# 处理步骤

1. 先检查机柜有无焦糊味、短路、打火，排除硬件故障
2. 查看 PDU、列头柜空开状态，确认非设备短路后再试合闸
3. 上电后逐台启动服务器，避免瞬间大电流再次跳闸
4. 检查业务、BMC、网络连通性，同步上报故障与恢复情况
5. 收尾：记录断电原因、处理时长、受影响设备和业务，同步书面上报给主管，协助分析跳闸根本原因（如是否因设备过载、线缆老化等）。

# 你简历里写 “了解常见网络协议（TCP/IP, HTTP, DNS 等）”，那你说一下 TCP 三次握手的具体过程，以及为什么需要三次而不是两次？

# 一、TCP 三次握手过程

1. 第一次（SYN）：客户端向服务器发送连接请求，报文标志位SYN=1，并生成一个初始序列号ISN，客户端进入SYN_SENT状态。
2. 第二次（SYN+ACK）：服务器收到请求后，确认收到（ACK=1，确认号 = ISN+1），同时也发送连接请求（SYN=1），生成自己的ISN，服务器进入SYN_RCVD状态。
3. 第三次（ACK）：客户端收到服务器的确认与请求，发送确认报文（ACK=1，确认号 = 服务器 ISN+1），客户端进入ESTABLISHED；服务器收到确认后也进入ESTABLISHED，连接建立。

# 二、为什么需要三次而不是两次？

核心是防止失效的连接请求报文段被服务器接收，导致建立错误连接。

若只用两次：

• 若客户端的连接请求因网络延迟滞留（未丢失），延迟到达服务器时，服务器会误建立连接，而客户端已废弃该请求，造成资源浪费与连接异常。
• 三次握手通过双向确认，既能建立双方可靠的发送与接收能力，又能避免这种历史无效请求导致的误连接。

# 假设你负责维护的某台服务器突然出现 CPU 占用率持续 100% 的情况，且暂时无法重启，你会分步骤怎么做来排查和缓解这个问题？

• 用 top 定位占用最高的进程与 PID
• 查看进程详情 ps -fp PID，判断是否为异常 / 恶意进程
• 查看线程 / IO / 网络情况，确认是计算密集还是死循环
• 必要时 kill 或 kill -STOP 暂停异常进程缓解 CPU
• 查看日志 / 应用状态，定位业务逻辑死循环或漏洞
• 观察负载回落，确认业务影响范围并上报

# 假设现在需要你排查一台服务器的网络故障：ping 网关不通，但本机网卡灯亮着，网线也插紧了。你会按什么步骤排查？从硬件到软件，说清楚每一步的操作和判断依据。

• 检查网卡状态：ip addr
  看网卡是否 UP、IP 是否正确配置
• 检查路由：ip route
  确认默认网关存在且正确
• 检查 ARP：arp -n 或 ip neigh
  看能否解析网关 MAC，不能则二层不通
• 检查端口配置：确认交换机端口未 shutdown、未错配 VLAN、速率双工不协商异常
• 检查防火墙：iptables -L / firewall-cmd --list-all
  看是否禁 ICMP 或拦截出站，因为ping依赖icmp
• 测试链路：用其它设备接同网线 / 同端口，判断是服务器问题还是线路 / 交换机问题

# 你在联通实习的时候，负责过网络设备巡检，那巡检服务器的时候，你怎么判断服务器硬件有没有故障？别废话，直接说步骤。

标准答案是：服务器硬件巡检要按 “先远程监控、后本地检查” 的流程来：

1. 先通过 IPMI/BMC 系统查看硬件监控数据：包括 CPU / 内存 / 硬盘的健康状态、电源模块冗余状态、风扇转速与温度阈值、硬盘 SMART 信息（坏道 / 掉线）；
2. 查看系统日志（如 dmesg）中是否有硬件报错（比如 PCI 设备异常、硬盘 IO 错误）；
3. 本地巡检时检查机箱物理状态：电源指示灯是否正常、有无异响 / 异味、散热口温度是否过高、线缆连接是否松动。

# 你简历里写了 “处理过高中校园网故障”，当时 2 小时内恢复了全网，那你排查网络故障的第一步是做什么？别再扯没用的。

标准答案是：整网中断故障排查第一步是 “确认故障影响范围 + 验证网络出口连通性”：

1. 先通过终端设备（比如随便找个学生电脑）ping 网关、ping 外网 DNS，判断是内网故障还是出口故障；
2. 再检查机房核心设备的物理状态（电源灯、运行灯是否正常），排除硬件宕机的情况；
3. 最后才是登录核心交换机查看端口状态、VLAN 配置、链路聚合是否异常。

# 你简历里写了 “熟悉 Linux Shell 脚本”，那你写过批量检查服务器硬盘状态的 Shell 脚本吗？脚本里核心命令用什么？别告诉我你没写过。

标准答案是：批量检查服务器硬盘状态的 Shell 脚本，核心命令分两类：

1. 查看硬盘物理健康状态：用smartctl -a /dev/sdX（获取 SMART 信息）；
2. 查看 RAID 阵列状态（如果有）：用对应阵列卡工具，比如 LSI 的megacli64 -LDInfo -Lall -aALL，或者 HPE 的hpssacli controller all show config。

# 再问你：招聘要求里要做 GPU 服务器部署，你知道安装 NVIDIA 驱动前，需要先禁用 Linux 系统里的哪个默认驱动吗？说全称，别缩写。

需要禁用 nouveau 驱动。

步骤是：

1. 编辑/etc/modprobe.d/blacklist.conf，添加blacklist nouveau和options nouveau modeset=0；
2. 重建 initramfs 镜像（比如dracut -f或update-initramfs -u）；
3. 重启系统后，用lsmod | grep nouveau确认驱动已禁用。

# 再问你：IDC 驻场时服务器上架，你知道机柜里服务器的安装顺序有什么要求吗？别跟我说随便装。

标准答案是：服务器上架核心原则是 “安全第一、散热优先”：

1. 按重量分层：下部放重型设备，上部放轻型设备，且单柜承重不超过机柜额定负载；
2. 按散热布局：设备间距预留至少 1U 空间，前方对应冷通道、后方对应热通道，避免阻挡气流；
3. 按线缆规划：先固定机柜 PDU 电源，再安装设备，确保电源线、网线从机柜两侧理线架走，避免缠绕。

# 再问你：用 Prometheus 监控 GPU 服务器时，需要部署什么 exporter？它采集的核心指标有哪些？别想蒙混过关

1. 首先，监控的是NVIDIA GPU，用的是 NVIDIA 官方的dcgm-exporter
2. dcgm-exporter 采集的 GPU 核心指标包括：GPU 利用率、显存使用率、显存带宽、GPU 温度、功耗、ECC 错误计数等

# 再问你：用 Ansible 批量给 100 台 GPU 服务器安装 NVIDIA 驱动，需要写哪些核心模块？步骤是什么？别再东拉西扯。

正确的核心模块和步骤是：

1. 用yum或apt模块安装依赖（如 gcc、kernel-devel）；
2. 用copy模块上传 NVIDIA 驱动.run 文件到目标服务器；
3. 用command或shell模块执行驱动安装命令（需添加--silent等参数实现无交互安装）；
4. 用modprobe模块加载nvidia内核模块；
5. 用shell模块执行nvidia-smi命令验证驱动是否安装成功；
6. 若需重启，用reboot模块

# 最后问你：IDC 机房里，服务器突然出现频繁掉电，你第一步要排查什么？说不出来就直接走人。

标准答案是：

1. 第一时间冲到 UPS 机柜，查看 上层供电UPS 是否报警、指示灯状态（市电是否中断、电池是否在放电）；检查上层UPS可以瞬间判断是单台还是系统性风险
2. 检查总 PDU 输入空开是否跳闸，排除供电链路故障；
3. 若 UPS 正常，再排查单台服务器的 PDU 端口和电源模块；
4. 全程同步通知业务团队，优先通过备用机切换保业务，而非傻等着查原因。

# 你简历写 “参与过 Linux 服务器系统安装”，那安装 CentOS 7 时，如何通过 kickstart 文件实现自动化分区？要求根分区 50G，swap 分区 8G，剩余空间给 /data 分区。写关键配置段，别漏参数

# 清除旧分区，初始化磁盘 
clearpart --all --initlabel 
# 分区配置 
part /boot --fstype=xfs --size=1024 
part swap --size=8192 
part / --fstype=xfs --size=51200 
part /data --fstype=xfs --grow

# 下一个问题，在 GPU 服务器上进行 CUDA 安装，安装完成后如何验证 CUDA 是否成功安装并能正常使用？要说出具体命令和验证要点。别答错，再给你一次机会，这都答不好就真没机会了。

# 1. 查看 CUDA 版本
nvcc -V

# 2. 查看 GPU 状态和驱动版本
nvidia-smi

# 3. 运行官方样例测试
cd /usr/local/cuda/samples/1_Utilities/deviceQuery
make
./deviceQuery

# 4. 带宽测试（可选）
cd ../bandwidthTest
make
./bandwidthTest

检查项	通过标准
nvcc -V	显示 CUDA 版本号，无报错
nvidia-smi	显示 GPU 型号、驱动版本、温度、功耗，无 ERR!
deviceQuery	最后一行显示 Result = PASS
bandwidthTest	显示 Result = PASS，带宽数值符合预期

关键细节

• nvidia-smi 正常但 nvcc -V 报错 → CUDA Toolkit 未正确安装或环境变量未配（PATH 需包含 /usr/local/cuda/bin）
• deviceQuery 失败 → 驱动与 CUDA 版本不匹配，或 GPU 未识别
• 多 GPU 环境：检查 nvidia-smi 是否列出全部卡

# 下一个问题，在 GPU 服务器的运维中，当发现 GPU 利用率长时间过高，且显存也几乎占满，你从软件层面会如何排查原因？要说出至少三个排查方向和具体操作。这次一定要回答好，别再掉链子。

# 排查方向一：定位占用进程

# 查看具体进程占用
nvidia-smi pmon -s um -o T

# 或详细模式
nvidia-smi -q -d PIDS | grep -A 5 "Process ID"

# 获取 PID 后查进程详情
ps -ef | grep <PID>
lsof -p <PID> | head -20

# 排查方向二：分析显存泄漏

# 实时监控显存变化（每秒刷新）
watch -n 1 nvidia-smi

# Python 程序用 torch 查显存分配
python -c "
import torch
print(f'Allocated: {torch.cuda.memory_allocated()/1024**3:.2f} GB')
print(f'Reserved:  {torch.cuda.memory_reserved()/1024**3:.2f} GB')
print(f'Max:       {torch.cuda.max_memory_allocated()/1024**3:.2f} GB')
"

# 启用显存分析（针对 PyTorch）
export PYTORCH_CUDA_ALLOC_CONF=max_split_size_mb:51200

# 排查方向三：检查任务调度与并发

# 查看是否有多个任务挤占单卡
nvidia-smi --query-compute-apps=pid,process_name,used_memory --format=csv

# 检查容器/K8s 资源限制
docker stats --no-stream | grep <container_id>
kubectl top pod <pod_name> --containers

# 查看任务是否超发
cat /proc/<PID>/cgroup | grep gpu

# 再问一个实际操作题：你们团队在维护 GPU 服务器时，突然收到告警，某台机器的 GPU 温度飙升至 95℃，且显存占用异常，同时 ssh 连接频繁断开。请分步骤说明排查思路和解决措施。

1. 保连接：IPMI/iLO 带外登录，绕过 SSH，确认非网络问题

2. 看现场：nvidia-smi -q -d TEMPERATURE 确认真实温度，查风扇转速是否归零

3. 杀进程：nvidia-smi pmon 定位高显存占用 PID，kill -9 强制终止，降温优先

4. 查根因：

   • 风扇故障 → 报硬件更换
   • 散热片堵塞 → 清灰
   • 程序死循环 → 查代码日志

5. 防复现：临时降频 nvidia-smi -pl 200（限制功耗），迁移业务到备用机

一句话：带外保命，杀进程降温，查风扇/散热/代码，降频迁移保业务。

# 假设现在你负责的 GPU 服务器集群突然出现批量进程无响应，监控面板显示 GPU 显存占用为 0 但节点状态为 "忙碌"，同时机房反馈部分机柜电源指示灯闪烁。结合之前的操作经验，从硬件到软件，分步骤说明你的排查逻辑，以及每一步的核心命令或操作依据。

1. 硬件：IPMI 查电源日志 ipmitool sel list，机房确认 PDU 波动
2. 总线：lspci | grep nvidia 验 GPU 是否掉卡，dmesg 看 PCIe 报错
3. 驱动：nvidia-smi 空白则 modprobe nvidia 重载，或重装驱动
4. 进程：ps aux | awk '$8~/D/' 抓 D 态僵死进程，kill -9 清理

# 最后问你：IDC 机房巡检时，发现某机柜温湿度超标，你的处理流程是什么？这次再答不出来，直接淘汰。

1. 确认范围：确认是是不是传感器异常，然后再排查单柜超标还是整列超标，看相邻机柜传感器数据
2. 定位热源：该机柜哪台设备温度最高，ipmitool sensor list 查服务器进风/出风温度
3. 应急降温：临时调高冷通道空调出风量，打开机柜盲板疏通气流，高热设备关机或迁移
4. 查根因：空调故障？冷热通道封闭失效？设备超配密度过高？
5. 同步记录：报工单给设施团队，并说明紧急程度。持续监控直到恢复正常阈值

一句话：定范围、找热源、应急降温、查根因、报工单盯恢复。

# 现在请你回答：在 GPU 服务器运维中，若通过命令行发现某块 GPU 持续高负载（超过 90%）但无实际任务运行，可能的原因有哪些？应如何排查处理？

可能原因

• 僵尸进程：任务已退出但驱动未释放 GPU 上下文
• 驱动异常：内核模块卡住，GPU 处于忙等状态
• 硬件故障：GPU 内部错误导致 SM 持续占用
• 挖矿木马：隐藏进程占用算力

---

排查步骤

1. 查进程：nvidia-smi pmon -s um 和 fuser -v /dev/nvidia* 确认无 PID 占用，但 nvidia-smi 显示高负载 → 僵尸/驱动问题
2. 查显存：nvidia-smi 显存占用为 0 但利用率 90% → 典型驱动卡死
3. 查日志：dmesg | grep -i nvidia 看 Xid 错误，/var/log/nvidia-installer.log 查驱动报错cps aux | grep -E "miner|xmr|pool"，netstat -tulnp 看异常外连
4. 重置 GPU：nvidia-smi -r -i <GPU_ID> 热重置，或 rmmod nvidia; modprobe nvidia 重装驱动
5. 硬件隔离：重置无效则 nvidia-smi drain -p <PCI_BUS> 标记不可用，迁移业务后换卡

一句话：无进程高负载 = 僵尸/驱动/硬件/木马，先查 PID 和显存，再扫日志和隐藏进程，重置无效换硬件。

# 你简历里写 “掌握 RHCSA 级核心技能”，那 RHCSA 里配置 iptables 规则时，怎么限制特定 IP 的 SSH 访问？别给我背命令，要讲实际操作中怎么验证规则生效了！

配置思路：默认拒绝，仅允许白名单IP。

验证规则生效的方法：

1. 本地验证：iptables -L -n -v看规则是否加载，计数器是否有流量（pkts/bytes非0说明命中）
2. 对端测试：从允许IP SSH连接应成功，从拒绝IP连接应超时或拒绝（Connection refused/timeout）
3. 抓包确认：tcpdump -i eth0 port 22看被拒绝IP的请求是否到达本机但被丢弃
4. 日志追踪：开iptables -A INPUT -j LOG看/var/log/messages记录DROP行为
5. 保存验证：service iptables save后重启服务，确认规则持久化未丢失