如何批量控制香港多台服务器的BMC设置与状态？基于IPMItool + Ansible的自动化实践

当我们将香港多个节点部署在不同运营商的机房后，运维压力也随之提升。尤其在BMC（Baseboard Management Controller）层面，涉及批量管理电源状态、风扇转速、温度监控、BIOS配置等底层控制，若仍依赖手动使用ipmitool或登录Web界面，不仅效率低下，而且容易出现人为配置错误。

为了实现自动化、批量、标准化的BMC管理，我将ipmitool与Ansible结合，通过模块化的剧本（Playbook）来实现跨服务器的BMC控制策略。这篇文章将完整展示我在香港多台物理服务器上落地这套方案的技术细节和实践过程。

一、环境概况与前提条件

1.1 网络与权限要求

• 各香港服务器需开放BMC的IPMI端口（默认UDP 623）；
• 管理节点可访问所有BMC的带外IP地址；
• 确保每台BMC已开启IPMI over LAN，并启用用户账号；
• ipmitool版本 ≥ 1.8.18；
• Ansible ≥ 2.9。

1.2 IPMI账户统一设置（可选）
为了便于Ansible剧本复用，建议提前将各服务器的BMC账户设为统一用户名/密码。若不统一，可使用变量映射方式适配。

二、BMC清单构建与分组

我将香港服务器的BMC信息记录在一个Ansible inventory文件中：

[bmc_hk]
hk-bmc-01 ansible_host=192.168.100.11 ipmi_user=admin ipmi_pass=hkpass
hk-bmc-02 ansible_host=192.168.100.12 ipmi_user=admin ipmi_pass=hkpass
hk-bmc-03 ansible_host=192.168.100.13 ipmi_user=admin ipmi_pass=hkpass

使用ansible_connection=local配合模块化脚本方式执行，也可通过delegate_to方式集中由一台跳板机进行操作。

三、基础命令模块封装（shell + ipmitool）

我编写了一个ipmi_command.yml任务模板，使用Ansible shell模块调用ipmitool执行命令，并传入用户变量：

# tasks/ipmi_command.yml
- name: Run IPMI raw/sensor command
  shell: |
    ipmitool -I lanplus -H {{ ansible_host }} -U {{ ipmi_user }} -P {{ ipmi_pass }} {{ ipmi_cmd }}
  register: ipmi_output
  failed_when: ipmi_output.rc != 0
  changed_when: false

- name: Show IPMI output
  debug:
    var: ipmi_output.stdout_lines

四、实战用例：BMC批量管理任务

4.1 查询所有服务器当前电源状态

# playbooks/bmc_check_power.yml
- hosts: bmc_hk
  gather_facts: false
  vars:
    ipmi_cmd: chassis power status
  tasks:
    - include_tasks: ../tasks/ipmi_command.yml

执行命令：

ansible-playbook playbooks/bmc_check_power.yml

4.2 批量远程重启服务器

# playbooks/bmc_reboot.yml
- hosts: bmc_hk
  gather_facts: false
  vars:
    ipmi_cmd: chassis power cycle
  tasks:
    - include_tasks: ../tasks/ipmi_command.yml

该命令通过BMC执行电源循环，相当于“强制重启”。

4.3 读取传感器数据（温度、电压、风扇）

# playbooks/bmc_sensor_read.yml
- hosts: bmc_hk
  gather_facts: false
  vars:
    ipmi_cmd: sensor
  tasks:
    - include_tasks: ../tasks/ipmi_command.yml

该命令输出如下：

Temp1        | 35 degrees C | ok
Fan1         | 4000 RPM     | ok
...

可结合后续文本处理模块进行告警阈值监控。

五、复杂操作：批量设置风扇策略为“全速”

部分厂商的BMC支持设置风扇模式（如Supermicro），可以用以下方式实现：

# playbooks/bmc_fan_fullspeed.yml
- hosts: bmc_hk
  gather_facts: false
  vars:
    ipmi_cmd: raw 0x30 0x45 0x01 0x01
  tasks:
    - include_tasks: ../tasks/ipmi_command.yml

说明：

• 0x30 0x45 0x01 0x01：Supermicro BMC风扇设定为Full Speed；
• 0x30 0x45 0x01 0x00：恢复为自动调速。
• 实际命令需要按BMC厂商的IPMI RAW协议手册确认。

六、进阶方案：整合定时监控与故障处理

可以配合Zabbix或Prometheus监控系统，在BMC接口不可达或温度超标时自动触发Ansible剧本执行如下动作：

• 自动重启风扇模式；
• 自动拉取sensor数据并写入日志；
• 自动触发服务器重启；
• 自动发送告警通知。

例如结合cron或系统d定时器，每5分钟执行：

ansible-playbook playbooks/bmc_sensor_read.yml >> /var/log/bmc_sensor.log

七、安全加固与维护建议

• 封禁公网访问BMC：通过VLAN或VPN限制管理段访问；
• 定期变更BMC密码：可配合Ansible vault对密码加密；
• 禁止弱口令：结合密码策略工具生成强密码；
• 合理设置用户权限：不暴露admin权限给非运维用户；
• 定期更新BMC固件：修复安全漏洞，避免IPMI僵尸模块滥用。

通过将ipmitool指令模块化，并用Ansible编排批量任务，我不仅实现了香港多台物理服务器的BMC集中控制，也将底层运维纳入自动化体系之中。BMC再也不是无法统一纳管的“黑盒”，而是运维流程中可以自动化、标准化、策略化的一部分。

这一方案目前已在我们的香港运营环境中稳定运行超过六个月，极大提升了故障响应速度和批量操作效率。未来，我计划进一步整合Redfish API接口与Ansible模块，实现更细粒度的硬件资产与带外生命周期管理。