3.1 HMC管理功能

最后更新2021/08/07

本节只介绍基础HMC相关的概念、连接、操作方式和功能实现原理，具体每项动作、功能内容见后续介绍。

IBM的设计一如既往地可用性优先，IBM POWER小型机无论高低端都支持双HMC管理，每台小型机至少有一块Firmware Service Processor（FSP）微码服务控制卡，FSP卡都有两个网络端口，可以分别接驳一台HMC。如果是中高端小型机，更安装有两个FSP卡，即使一个管理控制卡出问题，HMC还是可以通过另一个管理控制卡进行管理。

HMC的本质功能是提供管理工作的人机接口一边接受管理员发布的命令，先进行基本校验，确保命令合理、合法，再发送给FSP卡执行底层动作；底层操作完成后，HMC还要与上层各个分区上运行的操作系统通信，通知其底层已经给变，由操作系统执行动态配置命令“接受、识别”底层的变化。因此HMC，既要能够与小型机的FSP卡通信，同时也要与小型机的分区通信。由于FSP卡至关重要，并且在整个过程中只需要与HMC通信，所以HMC与FSP卡之间的连接通常设置在非公开的网段里，而HMC与分区通信则通过普通的开放网段。

为什么不让FSP直接把底层变化直接推送给操作系统呢？这样就可以省略了HMC与各分区之间的连接，岂不是更简单可靠？这是在分析了实现的复杂性和安全等问题之后综合考虑的结果。无论是FSP还是HMC告知分区操作系统底层发生改变，总是需要有机制实现设备变化识别这一功能。即使Windows所谓的“即插即用”也不过是在操作系统有一个后台进程不断进行硬件扫描（与硬件微码通信），发现设备变化之后进行相应的操作系统配置。在用户终端设备，为了减少用户操作，可以以牺牲性能的方式“轮询”设备变化，而在高端企业级设备，这种“奢侈”的性能牺牲显然无法接受，更何况如果“轮询”中间出现严重问题，有造成机器死机（内核崩溃）的可能，所以一般可靠性要求高的系统都采用中断、通知的方案。再者，如果由FSP直接去通知操作系统，必然需要把FSP与操作系统之间的通信协议固化到FSP的程序中，由于FSP属于“硬件微码”，其升级、维护比HMC更为复杂，需要更加稳定的版本控制。因此，实现同样的“告知”功能，如果要增加新功能、变化通信协议，还是HMC更为灵活方便。况且HMC的运行硬件是PC Server，比FSP单板机的性能要好得多，程序容量也不是问题。

因此综合考虑，IBM采用了由HMC去“通知”分区操作系统的方案，尽管这个方案在实际实施中，遇到了很多HMC与分区之间“通信不畅”的问题，需要人工干预解决。HMC、FSP、分区操作系统之间的通信请求大致是这样的一个过程：

1. FSP如果使用HMC DHCP功能获得IP地址，则HMC和FSP自动通过DHCP的交互信息，找到对方地址，进行通信。如果FSP采用固定IP地址，则需要手工在HMC输入FSP的IP，由HMC主动连接FSP，此既2.5.1 HMC扫描小型机过程。
2. 当分区启动的时候，操作系统会去读取（虚拟化之后的）硬件配置信息，这些信息由FSP提供，其中就包括了当前HMC的IP地址。分区操作系统利用读取到的地址主动连接HMC，建立连接。这样HMC、FSP、分区之间的管理链就建立起来了。由于读取动作只在启动初始化的时候执行，因此如果分区运行过程中如果更换了HMC的地址，分区操作系统很可能就会失去与HMC的连接。之所以不是100%丢失连接，这是由于在更改HMC地址之前，如果HMC和分区已经建立好了连接，HMC可以通知各个分区自己的新地址，但这个过程不一定可靠。如果发生分区与HMC通信问题，比较简单的解决方案是重启分区的操作系统。

基于HMC同时与FSP和分区的通信需求，HMC需要提供两个网络接口，一个接入FSP管理网段，另一个连入普通的分区网段。当然，在一些不要求安全的环境下，HMC只需要一个网络接口，通过此接口同时与FSP和分区通信。在本书中，我们仅讨论标准的连接方式。根据FSP卡的数量不同[ 每台IBM小型机至少有一个FSP，最多有两个。根据小型机机型不同，其标配的FSP数量也不同。低端小型机（p520）标配一个SFP，