赞
踩
最后更新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、分区操作系统之间的通信请求大致是这样的一个过程:
基于HMC同时与FSP和分区的通信需求,HMC需要提供两个网络接口,一个接入FSP管理网段,另一个连入普通的分区网段。当然,在一些不要求安全的环境下,HMC只需要一个网络接口,通过此接口同时与FSP和分区通信。在本书中,我们仅讨论标准的连接方式。根据FSP卡的数量不同[ 每台IBM小型机至少有一个FSP,最多有两个。根据小型机机型不同,其标配的FSP数量也不同。低端小型机(p520)标配一个SFP,
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。