为 实时更新 配置资源
配置以下资源,以便成功完成AIX实时更新操作:CPU、内存、存储、I/O 和 "lvupdate.data文件。
- CPU 和内存
实时更新操作过程中使用的额外 CPU 和内存资源,相当于逻辑分区当前使用的资源,而逻辑分区必须使用安装的任何临时修复程序进行更新。 在启动实时更新操作时,这些 CPU 和内存资源必须在同一帧上可用,并在实时更新操作完成后释放。 以下方法可减少此需求的影响:
- 在Hardware Management Console(HMC) 管理的主机上执行AIX实时更新操作期间,启用按需容量CoD) 资源。
如果满足以下条件,"实时更新功能会自动激活企业资源库 "CoD资源,直到完成 "实时更新操作:
服务器上有足够的未授权和停用资源,逻辑分区必须更新。 企业资源库CoD资源可在以下情况下获取:
- 根据 CoD 许可协议,池的合规性状态不得为
out of compliance。 - 如果激活了更多资源,那么已激活的企业池 CoD 资源总数不得超过授权的企业池 CoD 资源数的两倍。
注意:如果看到 ""1430-187 WARNING: Couldn't release the unreturned mobile CoD resources generated on CEC 'hostname'.",请检查企业资源池的配置,并更新资源分配。 - 根据 CoD 许可协议,池的合规性状态不得为
- 在 实时更新 操作之前,使用动态逻辑分区 (DLPAR) 将 CPU 和内存资源减少一半,然后在 实时更新 操作完成时再次增加这些资源。 此方法会在 实时更新 操作期间影响分区的性能,但它允许在没有额外资源的情况下完成此操作。
- 配置 实时更新 以允许 实时更新 操作在另一个主机上运行。 只有在IBM®Power® 虚拟化中心PowerSC) 管理的主机上才能使用此过程。 使用 lvupdate.data 文件来指示如果初始主机上的 CPU 或内存资源不足,那么可以在另一主机上运行 实时更新 操作。 要实现此过程,将使用 PowerVC 实时更新 操作自动迁移分区。 此迁移过程是临时的。 您可以使用 lvupdate.data 文件中的 force_migration 选项来强制 实时更新 在另一个主机上运行,即使本地主机上有足够的 CPU 和内存资源可用也是如此。
- 在Hardware Management Console(HMC) 管理的主机上执行AIX实时更新操作期间,启用按需容量CoD) 资源。
- 存储器
实时更新 操作至少需要 2 个额外磁盘。 第一个磁盘(或一组磁盘)用于代理分区的初始启动磁盘。 使用 "lspv命令时,该磁盘显示为 "
lvup_rootvg,在下一次 "实时更新操作后或系统重启后才能重新使用。 作为实时更新操作的一部分,会在 "/etc/inittab文件中添加一个条目,以删除磁盘(或磁盘组)上的 "lvup_rootvg标签。 重新启动后,磁盘将可供一般使用。 如果不重启系统,随后在不同磁盘上进行的实时更新操作会删除先前使用过的磁盘上的 "lvup_rootvg标签,然后该磁盘就可以正常使用了。 第二个磁盘(或一组磁盘)用于创建根卷组的额外镜像。如果 实时更新 操作仅包含临时修订,那么不会更新此新镜像,并在 实时更新 操作完成时将其重命名为
old_rootvg。 在这种情况下,可以在 "实时更新 "操作后使用该镜像副本,必要时通过从该 "old_rootvg镜像重新启动分区,将系统移回到上一级。 如果使用 实时更新 操作应用了任何更新,那么新镜像将包含这些更新,并且不名为old_rootvg。 在这种情况下,如果要将系统移回到先前级别,那么最好在启动 实时更新 操作之前创建 rootvg 的备份。对于 PowerVC 受管分区, 实时更新 操作不会创建
old_rootvg镜像。 在这种情况下,如果要将系统移回到先前级别,那么可以在启动 实时更新 操作之前备份 rootvg。此磁盘也可以复用于其他用途。 根据系统配置,可能需要更多临时磁盘。 如果调页空间存在于非 rootvg 磁盘上,或者如果内存转储设备存在于非 rootvg 磁盘上,那么必须提供两组磁盘。 原始分区的一组磁盘和代理分区的另一组磁盘。 提供的两组磁盘必须具有足够的容量用于这些调页空间和内存转储设备。 实时更新操作的预览模式可以计算所需空间的大小。 当 实时更新 操作完成时,这些磁盘可供复用。
如果要更新 HMC 管理的 LPAR,必须在 "lvupdate.data文件的 "
disk节中指定必要的存储设备。 对于 PowerVC 受管 LPAR , PowerVC 管理存储设备,并且未指定磁盘名称。如果 实时更新 操作失败,那么它会将信息记录在 /var/adm/ras/liveupdate/logs 目录中。 这些信息可用于服务支持。 将在此目录中创建新的日志文件以及后续 实时更新 操作,并且旧的日志文件将重命名为在其名称中包含时间戳记。 如有必要,可以删除这些旧日志文件,以腾出一些空间。
/var/adm/ras/liveupdate 目录中提供了与 实时更新 操作关联的可靠性,可用性和可维护性 (RAS) 信息。 组件跟踪在 ct_dump 目录中可用,轻量级内存跟踪在 lmt_dump 目录中可用。 如果启用了 实时更新 跟踪,那么 trcfile_orig 文件将包含原始节点的跟踪,而 trcfile_surr 文件将包含代理节点的跟踪。 实时更新操作期间的实时内存转储收集在 "/var/adm/ras/livedump目录中。
如果实时更新操作出现任何服务问题,"snap -U命令会为支持团队收集所有信息。
- I/O
对于 实时更新 操作,必须通过 Virtual I/O Server (VIOS) 对所有 I/O 进行虚拟化。 在 实时更新 操作完成时, VIOS 服务器和客户机上的所有 VIOS 插槽号都相同。 必须至少存在两个指向所有磁盘的路径。 在"实时更新 "操作过程中,原始分区中的一半路径被移除,代用分区中的路径被使用。 在实时更新操作完成之前,所有路径都会移动到代理分区。 实时更新操作可与以下多路径解决方案配合使用:IBM AIX®Multipath I/O 和IBM子系统设备驱动程序路径控制模块 (SDDPCM)。
某些设备对象数据管理器ODM) 属性可以更改,但新值在下次系统重启前不会生效。 由于 "实时更新 "操作相当于系统重启,因此任何此类属性都会在"实时更新 "操作后生效。
- lvupdate.data 文件
执行实时更新操作时,"geninstall命令会搜索位于 "/var/adm/ras/liveupdate路径下的名为 "lvupdate.data的 stanza 文件。 lvupdate.data文件包含实时更新操作的相关输入数据。 /var/adm/ras/liveupdate/lvupdate.template文件包含实时更新操作所有可能字段的最新说明。 下面的示例是一个包含基本字段说明的 "lvupdate.template文件示例:
# IBM_PROLOG_BEGIN_TAG # This is an automatically generated prolog. # # bos73F src/bos/usr/sbin/liveupdate/lvupdate.template/lvupdate.template 1.35 # # Licensed Materials - Property of IBM # # COPYRIGHT International Business Machines Corp. 2014,2024 # All Rights Reserved # # US Government Users Restricted Rights - Use, duplication or # disclosure restricted by GSA ADP Schedule Contract with IBM Corp. # # IBM_PROLOG_END_TAG # # The lvupdate.template file can be used to create the # /var/adm/ras/liveupdate/lvupdate.data file, which is # required for Live Update (geninstall -k ... ). # If the LPAR that you want to update is managed by HMC, the pvc stanza # does not apply and it must not be specified. # If the LPAR that you want to update is managed by PowerVC, the disks and hmc # stanzas do not apply and these stanzas must not be specified. # All fields in the disks stanza can be one disk or a comma-separated # list of disks. # # If preview is entered as part of the geninstall command_line or # in the SMIT menus, then no lvupdate.data file is required. If one is # provided, and the disks stanza completed, then size checking on the # disks will be performed. # # general: # kext_check = <yes | no> Blank defaults to yes. If no, the live update # operation will be attempted regardless as to whether all the loaded # kernel extensions are determined to be safe or not. # cpu_reduction = <yes | no> Blank or omitted defaults to no. If yes, the # live update operation will, in the absence of sufficient processing # capacity to create and boot the surrogate normally, determine whether # removing some capacity from the original would result in sufficient # available capacity, and if so, will automatically remove # the capacity from the original (later to restore the surrogate to full # capacity once the original is deleted). # ipsec_auto_migrate = <yes | no> Blank defaults to no. If yes, the # live update operation will be attempted with IPSEC enabled. # If no, preview check will be done for IPSEC, and if IPSEC is enabled, # lku will fail . # disable_wallmsg = <yes | no> Blank or omitted defaults no. # If this option is chosen as yes LKU broadcast will be disabled # audit_stream_check = <yes | no> Blank or omitted defaults to no. If yes, the # live update operation will perform a preview check if auditing in stream mode # is in progress and it will fail. If no, the preview check will be skipped and # live update operation will be attempted. # disable_ras_artex = <yes | no> When set to yes, LKU will skip restoring # the RAS settings. To disable this, we have to set this to no # # disks: # nhdisk = <disk1,disk2,...> The names of disks to be used to make a copy # of the original rootvg which will be used to boot the Surrogate # (surr-boot-rootvg). The required size needs to match the total size # of the original rootvg logical volumes except for an unmounted jfs2 # logical volume which is not included in the required size calculation. # (If previewing, size checking will be performed.) # mhdisk = <disk1,disk2,...> The names of disks to be used to temporarily # mirror rootvg on the Original LPAR. The mirror will be split, with # the original rootvg moved to the Surrogate LPAR and the newly created # mirror staying on the Original LPAR. After the live update, the mhdisk # disk(s) will be available for re-use. If previewing, size checking will # be performed. # alt_nhdisk = <disk1,disk2,...> The names of disks to be used if the disks # specified for the nhdisk attribute are not currently available # to be used by Live Update. The capacity requirements are # the same as nhdisk. Useful for doing multiple Live Updates. # tohdisk = <disk1,disk2,...> The names of disks to be used as temporary # storage for the Original. This is only required if the Original # is using paging space or dump devices on non-rootvg volume groups. The # capacity needs to match the total capacity of paging spaces and dump # devices defined on non-rootvg volume groups for the original # partition. (If previewing, size checking will be performed.) # tshdisk = <disk1,disk2,...> The names of disks to be used as temporary # storage for the Surrogate. This is only required if the Original is # using paging space or dump devices on non-rootvg volume groups. It # must have the same capacity as tohdisk. (If previewing, size checking # will be performed.) # # hmc: # lpar_id = <lpar id> Indicates the desired partition id for the # Surrogate. # alt_lpar_id = <lpar id> Indicates an alternate partition ID for the # Surrogate. If the value specified for the 'lpar_id' attribute is already in use, # Live Update will use this alternate ID if it is not in use. Useful # for doing multiple Live Updates. # management_console = <HMC IP Address> # user = <HMC user> This is the user id to be used for access to the HMC. # clone_from_hmc_profile = <yes|no> # If "yes", read the lastActivatedProfile and update the surrogate # resources with those values read from profile while LKU is attempted. # Only increasing of resource values is allowed. # Please make sure to set this attribute to no or leave this blank or # remove this attribute, If you don't want to use this feature, # in order to avoid LKU modifying system configuration using HMC profile. # Values in profile should be given in such a way that, # Desired values from current configuration should fit within # Max and Min values, given in profile # User can modify the required values of resources in HMC's # lastActivatedProfile. # Changing Processor mode from dedicated to shared or # vice-versa in lastActivatedProfile is not allowed # in order to use this feature. # Only memory and processor configuration values from profile are # considered for surrogate lpar creation. # If "no" or blank, this feature won't be enabled. # Only below parameters are taken into consideration while modifying # system configuration from Profile. # # Memory related # ============== # Minimum memory # Maximum memory # # Below are applicable for Dedicated processor configuration. # ============================================================ # Minimum dedicated processors # Maximum dedicated processors # # Below are applicable for Shared processor configuration. # ========================================================== # Minimum shared processing units # Maximum shared processing units # Minimum virtual processors # Maximum virtual processors # # pvc: # management_console = <hostname or IP Address of the server hosting # the PowerVC identity service> # user = <PowerVC user> This is the user ID to be used to access PowerVC. # project = <PowerVC project> This is the project to be used to access # PowerVC. If the attribute is not specified, "ibm-default" is used. # storage_template_override = <storage template name> Indicates the name # of the storage template used for the boot volume of the surrogate. # This parameter is optional. # The storage template is defined as follow: # 1. use this parameter if specified, or # 2. use the storage template of the original rootvg if any, or # 3. use the default storage template of the rootvg storage provider. # destination = < PowerVC host name | ANY > This attribute is used to # specify the host on which the Live Update operation will be executed # if the resources are insufficient on the local host, or if the # force_migration attribute is specified with a value equals to yes. # If the attribute is set to ANY, the destination will be selected # according to the placement policy of the host group in PowerVC. # If this parameter or its value is not specified, the Live Update # operation is executed locally. # force_migration = < yes | no > When set to yes, the Live Update # operation is executed on the host specified by the destination # attribute even if the resources are sufficient locally. # This parameter is optional and can be set to yes only when a # destination is specified. # pvc_disable_storage_model_check = < yes | no > When set to yes, the # Live Update operation will disable the storage provider validatioin # for pluggable and integrated type. This parameter is optional and can # be set to yes only when user want to disable storage provider check. # pvc_disable_moveadapter = < yes | no > When set to yes, the # Live Update operation will not use the move adapter feature to do LKU # in PowerVC managed system. It will use disk attach mechanism. # pvc_rootvg_clone = < yes | no > When set to yes, the LKU will use # PowerVC based rootvg clone. When set to no, the clone operation will # use the old approach. # # trace: # trc_option = <trace command options> This can be a hook id # with -j hookid1,... or any other trace option. # If specified, the live update commands will be traced using # the specified options. One or more can be specified. # If the stanza is present in the lvupdate.data file, # with a blank trc_option field, the default parameters # "-a -U -C and -o" are used to trace the live update commands. # Users need not provide redundant options such as "-a -U -C and -o" # in the trc_option field for trace stanza. # Do not add a trace stanza to the lvupdate.data file unless you # want the live update commands to be traced. # # llvupdate: # llu = <yes | no> Blank defaults to no. If yes, the live library update # operation will be attempted at the end of the live update. # retries = <Number of retries> The amount of retries the live library # operation will do before the operation is abandoned. This parameter # is optional and if no value is specified the default will be used. # timeout = <Number of seconds> The amount of seconds for the process # performing a live library update operation to complete. When the time # expires the live library update operation will be abandoned for that # process. This parameter is optional and if no value is specified the # default will be used. # general: kext_check = disks: nhdisk = mhdisk = tohdisk = tshdisk = hmc: lpar_id = management_console = user =