做服务器运维的人对“带外管理”这四个字应该都不陌生。以前管理一台物理服务器要么接显示器进BIOS要么开IPMI的KVM命令行敲完之后还得给机柜打电话。后来有了iDRAC、iLO这些厂商工具远程能干的活变多了但每家的界面、命令、API都不一样写脚本的时候特别痛苦。Redfish就是为解决这个问题而生的。简单点说它是一套基于HTTPS的RESTful接口标准让你可以通过统一的HTTP请求去管理服务器硬件——查状态、改启动项、看传感器、控制电源甚至升级固件。而Postman是我调试这些接口时最顺手的工具没有之一。这篇文章我会从Redfish的资源模型讲起然后完整演示如何用Postman做Redfish接口调试把登录鉴权、查询信息、修改配置、批量操作、导入导出这些环节全部走一遍。搞运维的同事、做硬件管理的开发、刚接触带外管理的同学都能从这里找到可以直接抄作业的内容。1. Redfish到底是什么1.1 一个把服务器管理“HTTP化”的标准Redfish由DMTF组织维护2015年正式发布设计目标就一句话用现代Web技术去管理服务器硬件。它借鉴了RESTful架构的所有特性使用HTTPS作为传输协议数据格式用JSON接口风格完全遵循HTTP动词的语义GET用来查询资源POST用来执行动作或创建资源PATCH用来部分更新资源DELETE用来删除资源PUT用来整体替换资源这种设计放在今天可能觉得理所当然但对比老一代的IPMI简直是从石器时代到工业革命的区别。IPMI走的是RMCP/UDP协议数据是二进制编码没有加密工具链还极其碎片化。Redfish则是纯Web技术任何一个能发HTTP请求的工具都能玩转它。我最早接触Redfish是在机房扩容的时候Dell、HPE、Lenovo几家的服务器混在一起厂商各自的接口只能管各自的设备。Redfish的好处就是不管背后是哪家的iDRAC还是iLO只要支持RedfishAPI的调用方式就是同一套。写一个脚本理论上可以管遍整个机房的服务器。1.2 Redfish的核心技术特征Redfish从底层设计上有几个值得注意的点基于HTTPS的加密传输。Redfish强制要求对敏感通信使用TLS加密。实际就是走443端口用证书做服务端身份验证。这一点比IPMI裸奔式的UDP通信要安全得多。生产环境建议用私有CA签发的证书或者至少使用自签名证书加密通道绝不允许明文HTTP在生产环境调试。JSON数据格式。所有响应都是合法的JSON结构清晰机器可读性极强。你甚至不用专门文档就能看懂大部分字段含义。Health: OK就是一目了然的状态。标准化的资源模型。Redfish把服务器管理拆成几个核心资源集合System、Chassis、Manager。每个集合下再细分。这种树状结构很直观你从根节点出发一层层就能找到所有管理入口。Session机制。官方推荐的鉴权方式是创建Session拿到X-Auth-Token后续请求带着这个Token走。不同厂商也支持Basic Auth但Session更安全也便于审计。动作(Action)与任务(Task)机制。有些操作不是马上返回结果的比如固件升级、批量配置Redfish定义了Task机制返回一个Task资源让你轮询进度。这个设计很实用。我在实际使用中感觉Redfish的普及速度比想象中快。现在主流服务器厂商的BMC都实现了Redfish接口而且大部分做了扩展兼容性已经很成熟。如果你管理的设备还只支持IPMI建议尽早推动升级Redfish这套东西用习惯了真的回不去。2. Redfish的资源模型先认识这棵树要做接口调试第一步不是打开Postman而是理解Redfish的URL是怎么组织的。不知道资源长什么样发什么请求都是白搭。2.1 根入口ServiceRootRedfish所有请求的起点都是根入口https://BMC地址/redfish/v1/这个路径返回的JSON是整个资源树的根会把下面所有顶级集合列出来包括Systems、Chassis、Managers、SessionService、AccountService、TaskService、UpdateService等。Systems: { odata.id: /redfish/v1/Systems }, Chassis: { odata.id: /redfish/v1/Chassis }, Managers: { odata.id: /redfish/v1/Managers }, SessionService: { odata.id: /redfish/v1/SessionService }, UpdateService: { odata.id: /redfish/v1/UpdateService }这里面藏着Redfish最核心的设计思路所有资源通过odata.id进行引用。你不需要死记硬背每个资源的完整路径只需要从根节点逐层导航拿到odata.id去请求就对了。这个思路和RESTful API的HATEOAS概念很像。2.2 三个关键节点Systems、Chassis、ManagersRedfish的树状模型里有三个节点必须搞明白它们分工完全不同Systems代表的是逻辑上的服务器也就是一台“主机”。它包含CPU信息、内存配置、BIOS属性、网卡、存储控制器、启动顺序这些跟服务器计算相关的东西。查询服务器配置主要就是请求这个集合。GET /redfish/v1/Systems/1Chassis代表的是物理机箱或物理硬件。它包含电源、温度传感器、风扇转速、硬件指示灯这些物理层面的信息。做机房巡检、查看硬件健康度重点看这里的传感器数据。GET /redfish/v1/Chassis/1/ThermalManagers代表的是BMC管理控制器本身。它包含固件版本、网络配置管理口IP、NTP设置、日志服务这些管理面信息。要升级BMC固件、改管理IP就是操作这个节点。GET /redfish/v1/Managers/1三者的关系可以这么理解Manager是管硬件的人Chassis是物理外壳Systems是这台机器对外展示的“逻辑形象”。实际操作中很多问题都要同时查这几个节点才能定位。比如服务器突然重启先看Systems的PowerState再看Chassis的ResetReason去Managers的日志里翻记录。2.3 其他常用资源除了上面三个核心节点实际使用中还经常用到这几个AccountService账号管理。创建新的管理账号、修改密码、查看权限级别。做安全加固时必用。SessionServiceSession管理。登录、登出、查看活动会话就是动这里的接口。UpdateService固件升级入口。上传固件、触发升级任务、查询升级进度都在这里。TaskService任务管理。异步操作的执行状态和进度记录都挂在这个服务下面。另外值得一提的是Redfish还有一个Oem扩展区。Dell、HPE、Lenovo这些厂商在标准模型基础上都会在Oem字段里提供自己独有的管理能力。比如戴尔有Oem.Dell里放着很多PowerEdge特有的设置。做兼容性管理时标准字段优先厂商扩展字段按需使用前提是你知道自己在干什么。理解了这棵树的组织结构后面的操作就有了地图。接下来进入正题把Postman准备好。3. Postman准备工具装得顺手才谈得上调试3.1 下载、安装与版本选择Postman有桌面客户端和Web版两种形态。我个人的建议是做Redfish这类长会话接口调试认准桌面客户端。原因有几个桌面端环境变量管理更顺手支持Script脚本执行还能离线工作。Web版虽然方便但调用本地资源还是需要额外装Agent多一层转发就多一层故障可能。下载直接去官网Windows、macOS、Linux都有对应版本。Linux下除了AppImage还有Ubuntu的deb包直接下载安装即可。如果你所在环境不允许注册账号又确实需要客户端可以安装历史版本使用但有一个风险需要自己权衡老版本缺少最新的漏洞修复安全性略差。也可以考虑一些开源的API调试工具作为备选功能上差距不大只是插件和生态系统还没有Postman成熟。Postman目前是英文界面为主官方一直没做官方汉化市面上有社区汉化包可以打补丁但安全性未知。我的建议是直接用英文版Postman界面词汇量不大Settings、Collections、Environments、Tests这几个高频词记住就够了。真不习惯的用浏览器翻译插件做网页翻译就行不建议给客户端打来路不明的汉化补丁。3.2 界面布局与环境变量配置Postman左侧是侧边栏包含Collections、APIs、Environments、Mock Servers等中间是请求构建区可以在这里设置Method、URL、Headers、Body底部是状态栏和响应查看区。整个布局逻辑很直观左边组织中间构建底部看结果。环境变量是Redfish调试中的核心工具。BMC地址、账号、Token这些信息总不会每次手动填一遍用环境变量统一管理是常规做法。点击右上角的Environment配置入口新建一个环境比如命名为BMC_Prod然后添加变量变量名初始值当前值说明base_urlhttps://192.168.1.100https://192.168.1.100BMC的管理口地址usernameadminadmin登录账号password你的密码你的密码登录密码token空空登录后自动写入在请求中使用变量时用双花括号包裹比如{{base_url}}/redfish/v1/Systems/1。Postman在发起请求前会自动替换变量值。这个习惯一定要养成后面做集合、批量操作时效率差距立刻拉大。3.3 集合管理把接口按场景归档Postman的Collection集合功能很适合Redfish调试。你可以把Redfish所有相关请求整理成一个Collection按业务场景分组认证、系统信息、电源管理、固件升级、日志管理。这样用过的请求不需要重复输入请求的执行顺序可以编排可以配合环境变量一键切换不同BMC环境后续用Runner做批量测试用Newman做持续集成都是基于Collection创建Collection很简单Collections区域点“”号命名后就能往里面加请求。注意在Collection级别定义好通用的Headers和Pre-request Script这样所有子请求会自动继承不用每个请求单独配置一遍。4. 用Postman实操Redfish这个部分是整篇文章的核心。我会从最基础的登录认证开始一步一步演示完整流程每一步会解释为什么这么操作以及踩过哪些坑。4.1 登录并获取X-Auth-TokenRedfish的Session登录流程是标准的先向SessionService发送POST请求携带用户名和密码成功后在响应Headers里拿到X-Auth-Token后续所有请求都在Headers里带上这个Token。用Postman操作步骤如下新建请求Method选择POSTURL填{{base_url}}/redfish/v1/SessionService/SessionsBody选择raw格式选JSON填入{ UserName: {{username}}, Password: {{password}} }点击Send。如果账号密码正确响应状态码应该是201 Created响应头里能看到X-Auth-Token。我把这个值存在环境变量里用Pre-request Script自动写入而不是手动复制在Collection级别的Scripts里加一段测试脚本const token pm.response.headers.get(X-Auth-Token); if (token) { pm.environment.set(token, token); }这样每次登录成功后环境变量token会被自动更新。后续所有请求只需要在Headers里加一行X-Auth-Token: {{token}}踩坑提示Redfish对Token的刷新机制是滑动式的长时间不活动会失效。写脚本时建议设置合理的重试逻辑遇到401就重新登录一次再取新Token。Postman的Tests选项卡里可以判断响应码配置自动重试逻辑实现半自动的Token维护。4.2 查询服务器概况登录成功后第一件事通常是看服务器整体状态。请求Systems集合GET {{base_url}}/redfish/v1/Systems正常情况下会返回一个包含多个System实例的列表每台服务器对应一个成员。取其中的odata.id接着请求具体实例GET {{base_url}}/redfish/v1/Systems/1响应里信息量非常大我一般重点看这几个字段PowerState当前电源状态On/OffProcessorSummary.CountCPU颗数MemorySummary.TotalSystemMemoryGiB总内存大小Boot.BootSourceOverrideTarget当前引导来源Status.Health整体健康度OK表示正常这些字段在标准里都有明确定义不同厂商返回略有差异但核心字段都一样。我个人习惯在Postman的Tests里写一段简短的断言把关键信息打印出来这样看结果更直观const jsonData pm.response.json(); console.log(PowerState: jsonData.PowerState); console.log(CPU Count: jsonData.ProcessorSummary.Count); console.log(Memory GiB: jsonData.MemorySummary.TotalSystemMemoryGiB); console.log(Health: jsonData.Status.Health);4.3 修改BIOS启动项接下来演示一个常用操作修改启动顺序或临时从某块启动设备引导。Redfish用PATCH方法修改System资源属性。假设要从PXE网卡引导启动目标设置BootSourceOverrideTarget为PxePATCH {{base_url}}/redfish/v1/Systems/1Headers里除了X-Auth-Token别忘了加Content-Type: application/json。Body{ Boot: { BootSourceOverrideTarget: Pxe, BootSourceOverrideEnabled: Once } }BootSourceOverrideEnabled有三个可选值Once表示仅下次启动生效Continuous表示每次启动生效Disabled用来取消覆盖。注意有些厂商默认只支持Once的语义写Continuous可能会被拒绝或忽略具体要看产品文档。响应状态码一般是200 OK或204 No Content。修改之后最好再GET一次确认值真的变了有些BMC校验不严格PATCH返回成功但内部没生效的情况确实存在。另外一个细节BootSourceOverrideTarget的合法值包括None、Pxe、Hdd、Cd、Usb、BiosSetup、UefiShell等。具体的支持情况还是要以Redfish元数据为准。Postman可以直接请求以下路径查元数据GET {{base_url}}/redfish/v1/Systems/1/Boot返回值要比直接看文档直观得多。4.4 电源控制电源控制是常见的带状操作。Redfish统一封装成Power子资源下的Reset动作。要把服务器重启就往Reset动作的URL发POST请求POST {{base_url}}/redfish/v1/Systems/1/Actions/ComputerSystem.ResetBody{ ResetType: GracefulRestart }ResetType的合法值我整理成一个表格方便查阅ResetType含义使用场景On开机服务器处于关机状态直接上电ForceOff立即关机系统卡死需要强制断电GracefulShutdown优雅关机让操作系统正常关机流程走完GracefulRestart优雅重启希望OS正常重启服务PowerCycle断电重新上电部分设备支持等效拔电再插ForceRestart强制重启不优雅但很快慎用电源操作属于高危操作建议在Postman里做二次确认。可以在Tests里对响应做校验但更可靠的做法是在操作之前手动确认一次服务器当前状态确认无误再执行。自动化场景里我习惯在脚本里加一个“确认电源状态”的前置步骤确保操作的确实是自己想动的设备。4.5 批量循环操作Runner与数据驱动Redfish经常需要批量执行同一类操作比如给10台服务器同时开机、查所有设备健康状态。手动一个个发请求太累Postman Collection Runner可以解决这个问题。把需要执行的请求放在Collection里点击Collection右侧的Runner按钮选择环境点击Run Collection。Runner会按请求顺序依次执行并展示每个请求的响应状态、耗时和断言结果。如果想要按不同环境跑同样的请求可以数据驱动。准备一个CSV文件每一行是一组参数server_id,expect_state 1,On 2,On 3,OffRunner配置里选择这个CSV文件请求URL里用{{server_id}}占位运行时Postman会逐行读取数据自动替换参数。Team协作场景下Collection可以导出为JSON文件团队内部共享。通过版本控制来管理JSON文件之后Redfish的操作流程就成了可以审阅、可以回滚的“代码资产”这比口头传达命令可靠多了。Runner跑完之后Postman会生成一个测试报告包含每个请求的通过/失败状态。做巡检类操作时我都是把报告导出成HTML作为巡检记录留档。这个习惯在季度维护、故障复盘时特别有用。5. 自动化与持续集成的延伸5.1 Postman脚本断言与数据驱动Collection Runner解决了批量执行的问题但只靠它还不算完整的自动化。真正的自动化要有断言有结果判定能跟现有CI/CD流程集成。Postman的Tests选项卡支持JavaScript脚本。我给Redfish请求配置断言时的常用写法// 验证响应状态码 pm.test(响应状态码为200, function () { pm.response.to.have.status(200); }); // 验证Token存在 pm.test(获取到X-Auth-Token, function () { pm.expect(pm.response.headers.get(X-Auth-Token)).to.not.be.empty; }); // 验证服务器健康 pm.test(服务器健康状态为OK, function () { const jsonData pm.response.json(); pm.expect(jsonData.Status.Health).to.eql(OK); }); // 验证传感器温度值在安全范围(仅示例) pm.test(CPU温度低于80度, function () { const jsonData pm.response.json(); if (jsonData.Temperatures jsonData.Temperatures.length 0) { const cpuTemp jsonData.Temperatures.find(function(t) { return t.Name t.Name.includes(CPU); }); if (cpuTemp) { pm.expect(cpuTemp.ReadingCelsius).to.be.below(80); } } });上面的断言逻辑很简单状态码要对Token要有健康度要是OK传感器温度不超限。每个断言失败时Runner报告会直接标红定位问题很快。5.2 导出Curl、导出集合、Newman与CI集成Postman支持把请求导出为curl命令。在请求面板右侧打开代码生成器选择cURL复制出来就是一条完整命令行curl --location https://192.168.1.100/redfish/v1/Systems/1 \ --header X-Auth-Token: {{token}} \ --data 这个功能对没有Postman环境的目标机器特别方便也可以放入Shell脚本里封装备用。更进一步把Collection导出为JSON文件用Newman在命令行执行newman run Redfish_BMC_Collection.json -e BMC_Prod.postman_environment.json --reporters cli,htmlNewman是Postman官方提供的Collection命令行运行器支持所有Postman的脚本和断言逻辑。这意味着你编写的测试逻辑可以脱离Postman客户端独立运行。持续集成是另一个重要场景。Redfish的接口测试完全可以嵌入到Jenkins或GitLab CI里。以Jenkins为例流水线里增加一个阶段stage(硬件管理API测试) { steps { sh newman run Redfish_BMC_Collection.json -e BMC_Test.postman_environment.json --reporters junit } }Newman生成JUnit格式的报告Jenkins能直接解析把测试结果展示到构建页面。服务器上架的登记验证、固件升级后的健康巡检、重要变更后的回归测试都可以通过这种方式自动完成。我把这些操作写成一个流水线每次设备到货上架后自动跑一轮Redfish接口测试配置没达标直接拦截上报。这个方案在我这里跑了半年多比人工巡检可靠得多。6. 常见问题与排查技巧实际调试Redfish的时候问题主要集中在几个方面。我把高频问题整理成表格方便对照排查常见问题可能原因解决思路请求报SSL证书错误BMC默认证书是自签名不受客户端信任Postman关闭SSL验证脚本里加上忽略证书校验参数登录返回401账号密码错误或账号被锁定先用Web后台确认账号可用检查是否有登录失败锁定策略带Token的请求返回401Token过期或者Token未正确传入重新登录查看Headers中变量是否被正确替换请求返回404路径不对或该BMC不支持该资源先GET父级资源检查返回的odata.id再导航PATCH请求返回405该资源不支持PATCH或请求方法不对查询该资源的Allow头部确认支持的操作类型POST动作返回503BMC繁忙正在处理其他任务稍后重试或查看TaskService是否有进行中任务响应JSON格式不合法BMC固件版本过旧或响应被截断升级BMC固件用更稳定的网络连接6.1 SSL证书报错这是最常见的问题。BMC出厂自带的证书都是自签名的Postman默认会校验证书合法性所以第一次请求大概率会报错。调试阶段可以直接关闭签名校验Postman设置里找到SSL certificate verification关掉它。要注意生产环境自动化脚本里更稳妥的方案是把BMC证书加入本地信任库保留TLS加密的同时也保留服务端身份验证。6.2 Token过期与并发Redfish的Token有明显的生命周期常见的是30分钟无操作后失效。排查401问题时先看是不是Token过期。还有一个容易忽略的坑并发请求共享同一个Token时容易出问题比如同时在多个Postman标签页操作前面退出登录了后续请求就会401。运维脚本里建议用独立的Session操作完再主动删除。6.3 资源路径不对很多BMC对Redfish的实现并非完全一致同一个资源在不同厂商设备上路径可能不同。排查方案是我前面反复强调的不要死记硬背先从根节点导航按返回的odata.id层层往后走。实在找不到某个资源尝试请求一下元数据服务GET {{base_url}}/redfish/v1/$metadata这里会列出所有支持的实体和属性定义比看任何文档都准。6.4 操作不生效PATCH返回200了GET一看还是老值这种情况我遇到过好几次。可能是操作确实没有真正触发也可能是缓存问题。先等几秒再重新GET用Cache-Control: no-cache头试试。如果确认不生效去Managers的事件日志里找对应记录看有没有具体报错原因。另有一个常见场景是PATCH时带了多个属性其中某一个被拒绝但响应状态依然显示成功。Redfish标准对这类情况的要求是基本原子性但部分厂商实现不严格实际结果可能是部分配置生效了。我的经验是修改配置尽量一次只改一个属性改完马上GET确认再改下一个。宁可多请求几次不要一次改一大堆然后排查半天。7. 顺手分享几个个人技巧最后再分享几个实际使用中的小经验都是文档里没有的东西。第一个是关于Postman环境变量管理的。很多人喜欢把BMC密码直接写在环境变量里这是隐患。建议环境变量里写变量引用而不是明文密码。比如密码单独放在一个私密环境里测试环境只继承引用避免导出Collection时把密码带出去。第二个是断言的规范性。Redfish的响应字段很多不要把断言写得太脆。比如Status.Health字段有些老固件版本根本不会返回这个字段直接用PM断言就会误报。写断言之前先确认目标设备的实际返回结构再决定断言哪些字段。第三个是关于操作审计。Redfish本身有事件订阅机制可以设置EventService把关键操作推送到接收端。我建议在正式环境配一套这个硬件操作改了什么都会留痕。Postman调Redfish的时候也方便配合事件推送验证操作是否真正触达BMC。第四个是跟同一类工具的配合。Postman调Redfish非常直观但如果你打算把流程沉淀成循环执行的自动化任务还是要配合Newman、Python脚本或者Ansible这类工具一起用。Postman负责设计验证和交互式调试真正的定时任务交给Newman或者代码脚本两个人各司其职配合起来效率最高。我在实际使用Redfish的过程中最大的感受是标准化的威力远大于某个工具本身。Redfish把碎片化的硬件管理收敛成了一棵清晰可控的API树Postman则把这棵树变成了可视化、可编排、可自动化的操作界面。两者放在一起服务器管理从“打电话让机房师傅看一眼”变成了“发几个HTTP请求”的事这个变化给日常运维带来的便利是实打实的。希望这篇文章能帮你在自己的环境里快速上手这套流程。
Redfish与Postman实战：统一接口管理服务器硬件
做服务器运维的人对“带外管理”这四个字应该都不陌生。以前管理一台物理服务器要么接显示器进BIOS要么开IPMI的KVM命令行敲完之后还得给机柜打电话。后来有了iDRAC、iLO这些厂商工具远程能干的活变多了但每家的界面、命令、API都不一样写脚本的时候特别痛苦。Redfish就是为解决这个问题而生的。简单点说它是一套基于HTTPS的RESTful接口标准让你可以通过统一的HTTP请求去管理服务器硬件——查状态、改启动项、看传感器、控制电源甚至升级固件。而Postman是我调试这些接口时最顺手的工具没有之一。这篇文章我会从Redfish的资源模型讲起然后完整演示如何用Postman做Redfish接口调试把登录鉴权、查询信息、修改配置、批量操作、导入导出这些环节全部走一遍。搞运维的同事、做硬件管理的开发、刚接触带外管理的同学都能从这里找到可以直接抄作业的内容。1. Redfish到底是什么1.1 一个把服务器管理“HTTP化”的标准Redfish由DMTF组织维护2015年正式发布设计目标就一句话用现代Web技术去管理服务器硬件。它借鉴了RESTful架构的所有特性使用HTTPS作为传输协议数据格式用JSON接口风格完全遵循HTTP动词的语义GET用来查询资源POST用来执行动作或创建资源PATCH用来部分更新资源DELETE用来删除资源PUT用来整体替换资源这种设计放在今天可能觉得理所当然但对比老一代的IPMI简直是从石器时代到工业革命的区别。IPMI走的是RMCP/UDP协议数据是二进制编码没有加密工具链还极其碎片化。Redfish则是纯Web技术任何一个能发HTTP请求的工具都能玩转它。我最早接触Redfish是在机房扩容的时候Dell、HPE、Lenovo几家的服务器混在一起厂商各自的接口只能管各自的设备。Redfish的好处就是不管背后是哪家的iDRAC还是iLO只要支持RedfishAPI的调用方式就是同一套。写一个脚本理论上可以管遍整个机房的服务器。1.2 Redfish的核心技术特征Redfish从底层设计上有几个值得注意的点基于HTTPS的加密传输。Redfish强制要求对敏感通信使用TLS加密。实际就是走443端口用证书做服务端身份验证。这一点比IPMI裸奔式的UDP通信要安全得多。生产环境建议用私有CA签发的证书或者至少使用自签名证书加密通道绝不允许明文HTTP在生产环境调试。JSON数据格式。所有响应都是合法的JSON结构清晰机器可读性极强。你甚至不用专门文档就能看懂大部分字段含义。Health: OK就是一目了然的状态。标准化的资源模型。Redfish把服务器管理拆成几个核心资源集合System、Chassis、Manager。每个集合下再细分。这种树状结构很直观你从根节点出发一层层就能找到所有管理入口。Session机制。官方推荐的鉴权方式是创建Session拿到X-Auth-Token后续请求带着这个Token走。不同厂商也支持Basic Auth但Session更安全也便于审计。动作(Action)与任务(Task)机制。有些操作不是马上返回结果的比如固件升级、批量配置Redfish定义了Task机制返回一个Task资源让你轮询进度。这个设计很实用。我在实际使用中感觉Redfish的普及速度比想象中快。现在主流服务器厂商的BMC都实现了Redfish接口而且大部分做了扩展兼容性已经很成熟。如果你管理的设备还只支持IPMI建议尽早推动升级Redfish这套东西用习惯了真的回不去。2. Redfish的资源模型先认识这棵树要做接口调试第一步不是打开Postman而是理解Redfish的URL是怎么组织的。不知道资源长什么样发什么请求都是白搭。2.1 根入口ServiceRootRedfish所有请求的起点都是根入口https://BMC地址/redfish/v1/这个路径返回的JSON是整个资源树的根会把下面所有顶级集合列出来包括Systems、Chassis、Managers、SessionService、AccountService、TaskService、UpdateService等。Systems: { odata.id: /redfish/v1/Systems }, Chassis: { odata.id: /redfish/v1/Chassis }, Managers: { odata.id: /redfish/v1/Managers }, SessionService: { odata.id: /redfish/v1/SessionService }, UpdateService: { odata.id: /redfish/v1/UpdateService }这里面藏着Redfish最核心的设计思路所有资源通过odata.id进行引用。你不需要死记硬背每个资源的完整路径只需要从根节点逐层导航拿到odata.id去请求就对了。这个思路和RESTful API的HATEOAS概念很像。2.2 三个关键节点Systems、Chassis、ManagersRedfish的树状模型里有三个节点必须搞明白它们分工完全不同Systems代表的是逻辑上的服务器也就是一台“主机”。它包含CPU信息、内存配置、BIOS属性、网卡、存储控制器、启动顺序这些跟服务器计算相关的东西。查询服务器配置主要就是请求这个集合。GET /redfish/v1/Systems/1Chassis代表的是物理机箱或物理硬件。它包含电源、温度传感器、风扇转速、硬件指示灯这些物理层面的信息。做机房巡检、查看硬件健康度重点看这里的传感器数据。GET /redfish/v1/Chassis/1/ThermalManagers代表的是BMC管理控制器本身。它包含固件版本、网络配置管理口IP、NTP设置、日志服务这些管理面信息。要升级BMC固件、改管理IP就是操作这个节点。GET /redfish/v1/Managers/1三者的关系可以这么理解Manager是管硬件的人Chassis是物理外壳Systems是这台机器对外展示的“逻辑形象”。实际操作中很多问题都要同时查这几个节点才能定位。比如服务器突然重启先看Systems的PowerState再看Chassis的ResetReason去Managers的日志里翻记录。2.3 其他常用资源除了上面三个核心节点实际使用中还经常用到这几个AccountService账号管理。创建新的管理账号、修改密码、查看权限级别。做安全加固时必用。SessionServiceSession管理。登录、登出、查看活动会话就是动这里的接口。UpdateService固件升级入口。上传固件、触发升级任务、查询升级进度都在这里。TaskService任务管理。异步操作的执行状态和进度记录都挂在这个服务下面。另外值得一提的是Redfish还有一个Oem扩展区。Dell、HPE、Lenovo这些厂商在标准模型基础上都会在Oem字段里提供自己独有的管理能力。比如戴尔有Oem.Dell里放着很多PowerEdge特有的设置。做兼容性管理时标准字段优先厂商扩展字段按需使用前提是你知道自己在干什么。理解了这棵树的组织结构后面的操作就有了地图。接下来进入正题把Postman准备好。3. Postman准备工具装得顺手才谈得上调试3.1 下载、安装与版本选择Postman有桌面客户端和Web版两种形态。我个人的建议是做Redfish这类长会话接口调试认准桌面客户端。原因有几个桌面端环境变量管理更顺手支持Script脚本执行还能离线工作。Web版虽然方便但调用本地资源还是需要额外装Agent多一层转发就多一层故障可能。下载直接去官网Windows、macOS、Linux都有对应版本。Linux下除了AppImage还有Ubuntu的deb包直接下载安装即可。如果你所在环境不允许注册账号又确实需要客户端可以安装历史版本使用但有一个风险需要自己权衡老版本缺少最新的漏洞修复安全性略差。也可以考虑一些开源的API调试工具作为备选功能上差距不大只是插件和生态系统还没有Postman成熟。Postman目前是英文界面为主官方一直没做官方汉化市面上有社区汉化包可以打补丁但安全性未知。我的建议是直接用英文版Postman界面词汇量不大Settings、Collections、Environments、Tests这几个高频词记住就够了。真不习惯的用浏览器翻译插件做网页翻译就行不建议给客户端打来路不明的汉化补丁。3.2 界面布局与环境变量配置Postman左侧是侧边栏包含Collections、APIs、Environments、Mock Servers等中间是请求构建区可以在这里设置Method、URL、Headers、Body底部是状态栏和响应查看区。整个布局逻辑很直观左边组织中间构建底部看结果。环境变量是Redfish调试中的核心工具。BMC地址、账号、Token这些信息总不会每次手动填一遍用环境变量统一管理是常规做法。点击右上角的Environment配置入口新建一个环境比如命名为BMC_Prod然后添加变量变量名初始值当前值说明base_urlhttps://192.168.1.100https://192.168.1.100BMC的管理口地址usernameadminadmin登录账号password你的密码你的密码登录密码token空空登录后自动写入在请求中使用变量时用双花括号包裹比如{{base_url}}/redfish/v1/Systems/1。Postman在发起请求前会自动替换变量值。这个习惯一定要养成后面做集合、批量操作时效率差距立刻拉大。3.3 集合管理把接口按场景归档Postman的Collection集合功能很适合Redfish调试。你可以把Redfish所有相关请求整理成一个Collection按业务场景分组认证、系统信息、电源管理、固件升级、日志管理。这样用过的请求不需要重复输入请求的执行顺序可以编排可以配合环境变量一键切换不同BMC环境后续用Runner做批量测试用Newman做持续集成都是基于Collection创建Collection很简单Collections区域点“”号命名后就能往里面加请求。注意在Collection级别定义好通用的Headers和Pre-request Script这样所有子请求会自动继承不用每个请求单独配置一遍。4. 用Postman实操Redfish这个部分是整篇文章的核心。我会从最基础的登录认证开始一步一步演示完整流程每一步会解释为什么这么操作以及踩过哪些坑。4.1 登录并获取X-Auth-TokenRedfish的Session登录流程是标准的先向SessionService发送POST请求携带用户名和密码成功后在响应Headers里拿到X-Auth-Token后续所有请求都在Headers里带上这个Token。用Postman操作步骤如下新建请求Method选择POSTURL填{{base_url}}/redfish/v1/SessionService/SessionsBody选择raw格式选JSON填入{ UserName: {{username}}, Password: {{password}} }点击Send。如果账号密码正确响应状态码应该是201 Created响应头里能看到X-Auth-Token。我把这个值存在环境变量里用Pre-request Script自动写入而不是手动复制在Collection级别的Scripts里加一段测试脚本const token pm.response.headers.get(X-Auth-Token); if (token) { pm.environment.set(token, token); }这样每次登录成功后环境变量token会被自动更新。后续所有请求只需要在Headers里加一行X-Auth-Token: {{token}}踩坑提示Redfish对Token的刷新机制是滑动式的长时间不活动会失效。写脚本时建议设置合理的重试逻辑遇到401就重新登录一次再取新Token。Postman的Tests选项卡里可以判断响应码配置自动重试逻辑实现半自动的Token维护。4.2 查询服务器概况登录成功后第一件事通常是看服务器整体状态。请求Systems集合GET {{base_url}}/redfish/v1/Systems正常情况下会返回一个包含多个System实例的列表每台服务器对应一个成员。取其中的odata.id接着请求具体实例GET {{base_url}}/redfish/v1/Systems/1响应里信息量非常大我一般重点看这几个字段PowerState当前电源状态On/OffProcessorSummary.CountCPU颗数MemorySummary.TotalSystemMemoryGiB总内存大小Boot.BootSourceOverrideTarget当前引导来源Status.Health整体健康度OK表示正常这些字段在标准里都有明确定义不同厂商返回略有差异但核心字段都一样。我个人习惯在Postman的Tests里写一段简短的断言把关键信息打印出来这样看结果更直观const jsonData pm.response.json(); console.log(PowerState: jsonData.PowerState); console.log(CPU Count: jsonData.ProcessorSummary.Count); console.log(Memory GiB: jsonData.MemorySummary.TotalSystemMemoryGiB); console.log(Health: jsonData.Status.Health);4.3 修改BIOS启动项接下来演示一个常用操作修改启动顺序或临时从某块启动设备引导。Redfish用PATCH方法修改System资源属性。假设要从PXE网卡引导启动目标设置BootSourceOverrideTarget为PxePATCH {{base_url}}/redfish/v1/Systems/1Headers里除了X-Auth-Token别忘了加Content-Type: application/json。Body{ Boot: { BootSourceOverrideTarget: Pxe, BootSourceOverrideEnabled: Once } }BootSourceOverrideEnabled有三个可选值Once表示仅下次启动生效Continuous表示每次启动生效Disabled用来取消覆盖。注意有些厂商默认只支持Once的语义写Continuous可能会被拒绝或忽略具体要看产品文档。响应状态码一般是200 OK或204 No Content。修改之后最好再GET一次确认值真的变了有些BMC校验不严格PATCH返回成功但内部没生效的情况确实存在。另外一个细节BootSourceOverrideTarget的合法值包括None、Pxe、Hdd、Cd、Usb、BiosSetup、UefiShell等。具体的支持情况还是要以Redfish元数据为准。Postman可以直接请求以下路径查元数据GET {{base_url}}/redfish/v1/Systems/1/Boot返回值要比直接看文档直观得多。4.4 电源控制电源控制是常见的带状操作。Redfish统一封装成Power子资源下的Reset动作。要把服务器重启就往Reset动作的URL发POST请求POST {{base_url}}/redfish/v1/Systems/1/Actions/ComputerSystem.ResetBody{ ResetType: GracefulRestart }ResetType的合法值我整理成一个表格方便查阅ResetType含义使用场景On开机服务器处于关机状态直接上电ForceOff立即关机系统卡死需要强制断电GracefulShutdown优雅关机让操作系统正常关机流程走完GracefulRestart优雅重启希望OS正常重启服务PowerCycle断电重新上电部分设备支持等效拔电再插ForceRestart强制重启不优雅但很快慎用电源操作属于高危操作建议在Postman里做二次确认。可以在Tests里对响应做校验但更可靠的做法是在操作之前手动确认一次服务器当前状态确认无误再执行。自动化场景里我习惯在脚本里加一个“确认电源状态”的前置步骤确保操作的确实是自己想动的设备。4.5 批量循环操作Runner与数据驱动Redfish经常需要批量执行同一类操作比如给10台服务器同时开机、查所有设备健康状态。手动一个个发请求太累Postman Collection Runner可以解决这个问题。把需要执行的请求放在Collection里点击Collection右侧的Runner按钮选择环境点击Run Collection。Runner会按请求顺序依次执行并展示每个请求的响应状态、耗时和断言结果。如果想要按不同环境跑同样的请求可以数据驱动。准备一个CSV文件每一行是一组参数server_id,expect_state 1,On 2,On 3,OffRunner配置里选择这个CSV文件请求URL里用{{server_id}}占位运行时Postman会逐行读取数据自动替换参数。Team协作场景下Collection可以导出为JSON文件团队内部共享。通过版本控制来管理JSON文件之后Redfish的操作流程就成了可以审阅、可以回滚的“代码资产”这比口头传达命令可靠多了。Runner跑完之后Postman会生成一个测试报告包含每个请求的通过/失败状态。做巡检类操作时我都是把报告导出成HTML作为巡检记录留档。这个习惯在季度维护、故障复盘时特别有用。5. 自动化与持续集成的延伸5.1 Postman脚本断言与数据驱动Collection Runner解决了批量执行的问题但只靠它还不算完整的自动化。真正的自动化要有断言有结果判定能跟现有CI/CD流程集成。Postman的Tests选项卡支持JavaScript脚本。我给Redfish请求配置断言时的常用写法// 验证响应状态码 pm.test(响应状态码为200, function () { pm.response.to.have.status(200); }); // 验证Token存在 pm.test(获取到X-Auth-Token, function () { pm.expect(pm.response.headers.get(X-Auth-Token)).to.not.be.empty; }); // 验证服务器健康 pm.test(服务器健康状态为OK, function () { const jsonData pm.response.json(); pm.expect(jsonData.Status.Health).to.eql(OK); }); // 验证传感器温度值在安全范围(仅示例) pm.test(CPU温度低于80度, function () { const jsonData pm.response.json(); if (jsonData.Temperatures jsonData.Temperatures.length 0) { const cpuTemp jsonData.Temperatures.find(function(t) { return t.Name t.Name.includes(CPU); }); if (cpuTemp) { pm.expect(cpuTemp.ReadingCelsius).to.be.below(80); } } });上面的断言逻辑很简单状态码要对Token要有健康度要是OK传感器温度不超限。每个断言失败时Runner报告会直接标红定位问题很快。5.2 导出Curl、导出集合、Newman与CI集成Postman支持把请求导出为curl命令。在请求面板右侧打开代码生成器选择cURL复制出来就是一条完整命令行curl --location https://192.168.1.100/redfish/v1/Systems/1 \ --header X-Auth-Token: {{token}} \ --data 这个功能对没有Postman环境的目标机器特别方便也可以放入Shell脚本里封装备用。更进一步把Collection导出为JSON文件用Newman在命令行执行newman run Redfish_BMC_Collection.json -e BMC_Prod.postman_environment.json --reporters cli,htmlNewman是Postman官方提供的Collection命令行运行器支持所有Postman的脚本和断言逻辑。这意味着你编写的测试逻辑可以脱离Postman客户端独立运行。持续集成是另一个重要场景。Redfish的接口测试完全可以嵌入到Jenkins或GitLab CI里。以Jenkins为例流水线里增加一个阶段stage(硬件管理API测试) { steps { sh newman run Redfish_BMC_Collection.json -e BMC_Test.postman_environment.json --reporters junit } }Newman生成JUnit格式的报告Jenkins能直接解析把测试结果展示到构建页面。服务器上架的登记验证、固件升级后的健康巡检、重要变更后的回归测试都可以通过这种方式自动完成。我把这些操作写成一个流水线每次设备到货上架后自动跑一轮Redfish接口测试配置没达标直接拦截上报。这个方案在我这里跑了半年多比人工巡检可靠得多。6. 常见问题与排查技巧实际调试Redfish的时候问题主要集中在几个方面。我把高频问题整理成表格方便对照排查常见问题可能原因解决思路请求报SSL证书错误BMC默认证书是自签名不受客户端信任Postman关闭SSL验证脚本里加上忽略证书校验参数登录返回401账号密码错误或账号被锁定先用Web后台确认账号可用检查是否有登录失败锁定策略带Token的请求返回401Token过期或者Token未正确传入重新登录查看Headers中变量是否被正确替换请求返回404路径不对或该BMC不支持该资源先GET父级资源检查返回的odata.id再导航PATCH请求返回405该资源不支持PATCH或请求方法不对查询该资源的Allow头部确认支持的操作类型POST动作返回503BMC繁忙正在处理其他任务稍后重试或查看TaskService是否有进行中任务响应JSON格式不合法BMC固件版本过旧或响应被截断升级BMC固件用更稳定的网络连接6.1 SSL证书报错这是最常见的问题。BMC出厂自带的证书都是自签名的Postman默认会校验证书合法性所以第一次请求大概率会报错。调试阶段可以直接关闭签名校验Postman设置里找到SSL certificate verification关掉它。要注意生产环境自动化脚本里更稳妥的方案是把BMC证书加入本地信任库保留TLS加密的同时也保留服务端身份验证。6.2 Token过期与并发Redfish的Token有明显的生命周期常见的是30分钟无操作后失效。排查401问题时先看是不是Token过期。还有一个容易忽略的坑并发请求共享同一个Token时容易出问题比如同时在多个Postman标签页操作前面退出登录了后续请求就会401。运维脚本里建议用独立的Session操作完再主动删除。6.3 资源路径不对很多BMC对Redfish的实现并非完全一致同一个资源在不同厂商设备上路径可能不同。排查方案是我前面反复强调的不要死记硬背先从根节点导航按返回的odata.id层层往后走。实在找不到某个资源尝试请求一下元数据服务GET {{base_url}}/redfish/v1/$metadata这里会列出所有支持的实体和属性定义比看任何文档都准。6.4 操作不生效PATCH返回200了GET一看还是老值这种情况我遇到过好几次。可能是操作确实没有真正触发也可能是缓存问题。先等几秒再重新GET用Cache-Control: no-cache头试试。如果确认不生效去Managers的事件日志里找对应记录看有没有具体报错原因。另有一个常见场景是PATCH时带了多个属性其中某一个被拒绝但响应状态依然显示成功。Redfish标准对这类情况的要求是基本原子性但部分厂商实现不严格实际结果可能是部分配置生效了。我的经验是修改配置尽量一次只改一个属性改完马上GET确认再改下一个。宁可多请求几次不要一次改一大堆然后排查半天。7. 顺手分享几个个人技巧最后再分享几个实际使用中的小经验都是文档里没有的东西。第一个是关于Postman环境变量管理的。很多人喜欢把BMC密码直接写在环境变量里这是隐患。建议环境变量里写变量引用而不是明文密码。比如密码单独放在一个私密环境里测试环境只继承引用避免导出Collection时把密码带出去。第二个是断言的规范性。Redfish的响应字段很多不要把断言写得太脆。比如Status.Health字段有些老固件版本根本不会返回这个字段直接用PM断言就会误报。写断言之前先确认目标设备的实际返回结构再决定断言哪些字段。第三个是关于操作审计。Redfish本身有事件订阅机制可以设置EventService把关键操作推送到接收端。我建议在正式环境配一套这个硬件操作改了什么都会留痕。Postman调Redfish的时候也方便配合事件推送验证操作是否真正触达BMC。第四个是跟同一类工具的配合。Postman调Redfish非常直观但如果你打算把流程沉淀成循环执行的自动化任务还是要配合Newman、Python脚本或者Ansible这类工具一起用。Postman负责设计验证和交互式调试真正的定时任务交给Newman或者代码脚本两个人各司其职配合起来效率最高。我在实际使用Redfish的过程中最大的感受是标准化的威力远大于某个工具本身。Redfish把碎片化的硬件管理收敛成了一棵清晰可控的API树Postman则把这棵树变成了可视化、可编排、可自动化的操作界面。两者放在一起服务器管理从“打电话让机房师傅看一眼”变成了“发几个HTTP请求”的事这个变化给日常运维带来的便利是实打实的。希望这篇文章能帮你在自己的环境里快速上手这套流程。
