A bare metal server instance management method, system, storage medium and program product

Abstract

The application provides a bare metal server instance management method, system, storage medium and program product, relates to the technical field of cloud computing, and the method comprises the following steps: obtaining the out-of-band management address of a target bare metal server, obtaining the hardware manufacturer identifier according to the out-of-band management address, and determining a target virtual local area network; injecting a hardware driver set matched with the hardware manufacturer identifier into an operating system image associated with a machine installation template to generate a target deployment image; allocating a temporary boot IP address in the target virtual local area network and configuring a pre-boot network parameter through a substrate out-of-band interface; controlling the target bare metal server to obtain the target deployment image according to the pre-boot network parameter to install the operating system; adjusting the computing resource quota to a target resource quota through a management and control agent program during the operation of the operating system; and when a storage expansion request is received, creating a target storage volume according to a target physical disk identifier through the management and control agent program and mounting the target storage volume to a target mounting point.

Description

Technical Field

[0001] This application relates to the field of cloud computing technology, and in particular to a bare metal server instance management method, system, storage medium, and program product. Background Technology

[0002] With the rapid development of cloud computing and edge computing, data centers have an increasing demand for automated delivery and lifecycle management of bare metal servers. Bare metal servers can provide physical-grade performance without virtualization loss and play an important role in scenarios such as high-performance computing, big data analytics, and core databases.

[0003] In related technologies, a bare metal server management approach based on the Ironic framework is typically adopted. Specifically, DHCP and TFTP service topologies are pre-configured in the out-of-band management network to establish a boot environment based on the PXE protocol. An instance specification template with a fixed number of CPU cores and memory capacity, as well as a storage mount template with fixed disk partition information, are pre-created in the cloud platform control terminal. During actual deployment and operation, the cloud platform control terminal boots the bare metal node via the PXE protocol and distributes the operating system image to the bare metal node. After the bare metal node boots, its hardware resource information is collected through the out-of-band network, and the collected hardware resource information is matched with the pre-created instance specification template to complete the allocation of computing resources. Subsequently, the cloud platform control terminal, based on the pre-created storage mount template, controls the bare metal node to complete the formatting and mounting of local disks during the operating system initialization phase. Once the bare metal node completes system deployment and enters the running state, it connects to the dedicated graphics card or the vendor's proprietary out-of-band remote management console by calling the server vendor's baseboard management controller to establish a KVM remote session channel, thereby achieving remote operation and maintenance management of the bare metal node.

[0004] However, the bare metal server management method based on the Ironic framework described above suffers from several drawbacks. Firstly, the deployment process is tightly coupled to the DHCP+TFTP service topology, and secondly, instance specifications and storage configurations are fixed during the initialization phase. Thirdly, in actual cross-VLAN deployments and mixed operation of multiple vendor devices, hardware driver compatibility issues and network topology limitations can easily interfere with the underlying communication and resource configuration processes. This results in a high PXE remote restart failure rate and significant image distribution delays. Consequently, the cloud platform control terminal struggles to flexibly adjust computing and storage resource configurations based on continuously changing business needs during instance operation. Ultimately, this leads to low lifecycle management efficiency for bare metal servers in cross-VLAN and mixed-vendor device environments. Summary of the Invention

[0005] This application provides a bare metal server instance management method, system, storage medium, and program product to improve the lifecycle management efficiency of bare metal servers in mixed environments with cross-VLAN and multi-vendor devices.

[0006] Firstly, this application provides a bare metal server instance management method, applied to a bare metal server instance management system. The method includes: obtaining the out-of-band management address of a target bare metal server; obtaining the hardware vendor identifier of the target bare metal server based on the out-of-band management address; and determining the target virtual local area network (VLAN) to which the target bare metal server belongs; adding a hardware driver set matching the hardware vendor identifier to an operating system image associated with an installation template to generate a target deployment image; allocating a temporary boot IP address to the target bare metal server within the target VLAN; and calling the baseboard out-of-band interface of the target bare metal server to configure the temporary boot IP address as the pre-boot address of the target bare metal server. The system controls the target bare metal server to obtain the target deployment image based on the pre-boot network parameters and install the operating system on the target bare metal server based on the target deployment image. During the operation of the operating system on the target bare metal server, the system sends resource adjustment instructions to the management agent program within the operating system, so that the management agent program adjusts the computing resource quota of the target bare metal server to the target resource quota according to the resource adjustment instructions. When a storage expansion request carrying the target physical disk identifier and the target mount point is received, a storage expansion instruction is sent to the management agent program, so that the management agent program creates the target storage volume according to the target physical disk identifier and mounts the target storage volume to the target mount point.

[0007] By adopting the above technical solution, hardware vendors are automatically identified and virtual LANs are determined through out-of-band management addresses. Customized driver injection and dynamic configuration of pre-boot network parameters via the baseboard's out-of-band interface avoid strong dependence on fixed DHCP / TFTP service topologies, improving installation success rates and deployment efficiency in multi-vendor, cross-VLAN environments. Furthermore, during the operating system runtime phase of the target bare metal server, a management agent dynamically adjusts computing resource quotas and expands storage volumes, achieving elastic resource scaling throughout the bare metal server's lifecycle without interrupting operating system operation. This solves the technical problem of low lifecycle management efficiency for bare metal servers in cross-VLAN and multi-vendor mixed operating environments, achieving the technical effect of improving lifecycle management efficiency for bare metal servers in such environments.

[0008] Optionally, before adding the set of hardware drivers matching the hardware vendor identifier to the operating system image associated with the installation template, the method further includes: querying a set of candidate driver packages associated with the hardware vendor identifier from a local driver package repository, each candidate driver package in the set carrying an operating system kernel version range and a hardware component type; obtaining the target kernel version number of the operating system image and performing range matching between the target kernel version number and the operating system kernel version range to obtain a set of version-matching driver packages; obtaining the digital signature certificate of each version-matching driver package in the set of version-matching driver packages, and obtaining the digital signature certificate associated with the hardware vendor identifier. The system involves: establishing a pre-set trust certificate chain; performing security verification on the digital signature certificate based on the pre-set trust certificate chain to obtain the security verification result; removing version-matching driver packages that fail security verification from the version-matching driver package set based on the security verification result to obtain the target driver package set; classifying and grouping the target driver package set according to hardware component type to generate a categorized driver list; querying hardware assets by calling the substrate hardware list interface of the target bare metal server through the out-of-band management address to obtain the list of hardware component types actually installed on the target bare metal server; comparing and filtering the hardware component type list with the categorized driver list to obtain the hardware driver set.

[0009] By adopting the above technical solution, through kernel version range matching and security verification of digital signature certificates, and by accurately comparing the actual hardware assets obtained from the baseboard hardware manifest interface, incompatible or tampered malicious driver packages can be effectively filtered out. This ensures the security, accuracy, and absolute compatibility of the hardware driver set injected into the operating system image with the underlying hardware, thereby reducing the risk of operating system kernel crashes caused by driver anomalies.

[0010] Optionally, the hardware driver set matching the hardware vendor's identifier is added to the operating system image associated with the installation template to generate the target deployment image. This includes: mounting the root file system partition of the operating system image to a temporary working directory according to a preset read / write method; determining the kernel module storage path corresponding to the target kernel version number in the root file system partition based on the target kernel version number, and creating a driver loading staging area under the kernel module storage path; determining the system boot dependency level of the hardware driver set based on the hardware component types recorded in the categorized driver list; decompressing the hardware driver set according to the system boot dependency level to obtain multiple driver module files, and writing the multiple driver module files into the driver loading staging area; determining the module dependency relationships of the multiple driver module files in the driver loading staging area; registering the module dependency relationships to the module dependency relationship file of the root file system partition, and performing mount and unmount operations on the root file system partition; and image packaging the successfully mounted and unmounted root file system partition to generate the target deployment image.

[0011] By adopting the above technical solution, the driver modules are decompressed in an orderly manner according to the system boot dependency hierarchy, and the module dependencies are automatically resolved and registered in the root file system. This ensures that the operating system can load core hardware drivers (such as storage controller drivers) in the correct dependency order during the boot process, avoiding system boot failures caused by incorrect driver loading order, and further improving the boot reliability of customized deployment images.

[0012] Optionally, after querying the set of candidate driver packages associated with the hardware vendor identifier from the local driver package repository, the method further includes: calling the substrate firmware manifest interface of the target bare metal server through an out-of-band management address to obtain the firmware version information of the hardware component cluster actually mounted on the target bare metal server; comparing the firmware version information with the compatible firmware version requirements corresponding to each candidate driver package to determine the first firmware version that does not meet the compatible firmware version requirements; determining the target hardware component that matches the first firmware version from the hardware component cluster; obtaining a firmware upgrade package that matches the component model of the target hardware component, wherein the second firmware version of the firmware upgrade package meets the compatible firmware version requirements; calling the substrate firmware update interface of the target bare metal server through an out-of-band management address to push the firmware upgrade package to the target hardware component to trigger the target hardware component to perform a firmware online flashing operation; and marking the candidate driver packages in the candidate driver package set that match the hardware component type of the target hardware component as firmware compatible when the target hardware component completes the firmware online flashing operation and the first firmware version has been updated to the second firmware version.

[0013] By adopting the above technical solution, a compatibility detection mechanism for the underlying hardware firmware version is introduced during the driver matching process. When the firmware version is found to be too low, the firmware online flashing operation is automatically triggered through the baseboard firmware update interface, thereby realizing the automated collaborative upgrade of the hardware firmware and the upper-level driver version and eliminating the potential risks of hardware performance degradation or instability caused by firmware and driver version mismatch.

[0014] Optionally, a temporary boot IP address is allocated to the target bare metal server within the target virtual LAN, and the baseboard out-of-band interface of the target bare metal server is invoked to configure the temporary boot IP address as the pre-boot network parameters of the target bare metal server. This includes: selecting an idle candidate boot address from the address pool associated with the target virtual LAN and marking the candidate boot address as temporarily occupied in the address pool; obtaining the subnet mask, default gateway address, and domain name resolution server address of the target virtual LAN according to the network topology configuration of the target virtual LAN; and configuring the subnet mask, default gateway address, and domain name resolution server address with the candidate... The boot addresses are combined to generate pre-boot network parameters; the network configuration endpoint of the substrate's out-of-band interface is called through the out-of-band management address to write the pre-boot network parameters into the network boot configuration register of the target bare metal server; a boot device sequence setting instruction is sent to the substrate's out-of-band interface to set the preferred boot device of the target bare metal server as the network interface card, so that the target bare metal server will prioritize the network boot process on the next boot; after the target bare metal server completes the operating system installation, a network configuration clear instruction is sent to the substrate's out-of-band interface; candidate boot addresses are released and updated to an idle state in the address pool.

[0015] By adopting the above technical solution, network parameters such as temporary boot IP addresses are written into the network boot configuration register by directly calling the baseboard's out-of-band interface, and the boot device order is dynamically modified. This enables bare metal servers to accurately establish PXE boot connections in stateless, cross-VLAN complex network environments. After installation, the network configuration is automatically cleaned up and the IP address is released, realizing on-demand access and secure recycling of network resources, further improving the network configuration efficiency of automated installation.

[0016] Optionally, a resource adjustment instruction is sent to the management agent within the operating system, causing the management agent to adjust the computing resource quota of the target bare metal server to the target resource quota according to the resource adjustment instruction. This includes: upon receiving a resource quota adjustment request, determining the target resource quota based on the resource quota adjustment request, whereby the target resource quota includes the target number of CPU cores and the target memory capacity; sending a resource adjustment instruction carrying the target resource quota to the management agent, causing the management agent to perform the following operations upon receiving the resource adjustment instruction: the management agent reads the current physical CPU topology information of the target bare metal server and determines the current number of physical CPU cores in the online state based on the current physical CPU topology information; the management agent reads the current memory status information of the target bare metal server and determines the current available memory capacity of the target bare metal server based on the current memory status information; and the management agent performs a resource status adjustment operation on the target bare metal server based on the target number of CPU cores, the target memory capacity, the current number of physical CPU cores, and the current available memory capacity.

[0017] By adopting the above technical solution, when a resource quota adjustment request is received, the management agent program reads the underlying physical CPU topology information and memory status information in real time to obtain the true current physical resource status, providing accurate real-time data support for subsequent resource status adjustments and avoiding resource allocation conflicts caused by inconsistencies between the status recorded by the cloud platform control terminal and the actual underlying physical status.

[0018] Optionally, the management agent performs resource status adjustment operations on the target bare metal server based on the target number of CPU cores, target memory capacity, current physical CPU cores, and current available memory capacity. This includes: when the management agent determines that the target number of CPU cores is greater than the current number of physical CPU cores, it adjusts the first physical CPU core in the target bare metal server that is offline to online via the operating system's CPU hot-swap interface, so that the current number of physical CPU cores equals the target number of CPU cores; when the management agent determines that the target number of CPU cores is less than the current number of physical CPU cores, it adjusts the first physical CPU core in the target bare metal server that is offline to online via the CPU hot-swap interface. The second physical CPU core in the online state is adjusted to an offline state so that the current number of physical CPU cores equals the target number of CPU cores; when the management agent determines that the target memory capacity is less than the current available memory capacity, it sets the first physical memory segment in the target bare metal server that is in the online state to an offline state through the operating system's memory node control interface so that the current available memory capacity equals the target memory capacity; when the management agent determines that the target memory capacity is greater than the current available memory capacity, it adjusts the second physical memory segment in the target bare metal server that is in the offline state to an online state through the operating system's memory node control interface so that the current available memory capacity equals the target memory capacity.

[0019] By adopting the above technical solution, and utilizing the CPU hot-swappable interface and memory node control interface of the operating system, the online and offline status switching of physical CPU cores and physical memory segments can be precisely controlled according to the difference between the target resource quota and the current actual physical resource status, thereby improving resource utilization and business response flexibility.

[0020] Secondly, embodiments of this application provide a bare metal server instance management system, which includes: one or more processors and a memory; the memory is coupled to one or more processors, and the memory is used to store computer program code, the computer program code including computer instructions, and the one or more processors call the computer instructions to cause the bare metal server instance management system to perform the method described in the first aspect and any possible implementation thereof.

[0021] Thirdly, embodiments of this application provide a computer-readable storage medium including program instructions that, when executed on a bare metal server instance management system, cause the bare metal server instance management system to perform the method described in the first aspect and any possible implementation thereof.

[0022] Fourthly, embodiments of this application provide a computer program product containing instructions that, when the computer program product is run on a bare metal server instance management system, cause the bare metal server instance management system to execute the method described in the first aspect and any possible implementation thereof.

[0023] By adopting the above technical solution, hardware vendors are automatically identified and virtual LANs are determined through out-of-band management addresses. Customized driver injection and dynamic configuration of pre-boot network parameters via the baseboard's out-of-band interface avoid strong dependence on fixed DHCP / TFTP service topologies, improving installation success rates and deployment efficiency in multi-vendor, cross-VLAN environments. Furthermore, during the operating system runtime phase of the target bare metal server, a management agent dynamically adjusts computing resource quotas and expands storage volumes, achieving elastic resource scaling throughout the bare metal server's lifecycle without interrupting operating system operation. This solves the technical problem of low lifecycle management efficiency for bare metal servers in cross-VLAN and multi-vendor mixed operating environments, achieving the technical effect of improving lifecycle management efficiency for bare metal servers in such environments. Attached Figure Description

[0024] Figure 1 This is a flowchart illustrating a bare metal server instance management method in an embodiment of this application;

[0025] Figure 2 This is a schematic diagram of the physical device structure of a bare metal server instance management system in this application embodiment. Detailed Implementation

[0026] The terminology used in the following embodiments of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. As used in the specification and appended claims of this application, the singular expressions “a,” “an,” “the,” “the,” “the,” and “this” are intended to include the plural expressions as well, unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in this application refers to any or all possible combinations including one or more of the listed items.

[0027] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature, and in the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more.

[0028] This application provides a method for managing bare metal server instances, see [link / reference]. Figure 1 , Figure 1 This is a flowchart illustrating a bare metal server instance management method in an embodiment of this application, including the following steps:

[0029] Step S101: Obtain the out-of-band management address of the target bare metal server, obtain the hardware vendor identifier of the target bare metal server based on the out-of-band management address, and determine the target virtual LAN to which the target bare metal server belongs.

[0030] Step S102: Add the hardware driver set that matches the hardware vendor identifier to the operating system image associated with the installation template to generate the target deployment image;

[0031] Step S103: Assign a temporary boot IP address to the target bare metal server within the target virtual LAN, and call the baseboard out-of-band interface of the target bare metal server to configure the temporary boot IP address as the pre-boot network parameter of the target bare metal server.

[0032] Step S104: Control the target bare metal server to obtain the target deployment image according to the pre-boot network parameters, and install the operating system on the target bare metal server according to the target deployment image;

[0033] Step S105: During the operation of the operating system on the target bare metal server, a resource adjustment instruction is sent to the management agent program within the operating system, so that the management agent program adjusts the computing resource quota of the target bare metal server to the target resource quota according to the resource adjustment instruction.

[0034] Step S106: Upon receiving a storage expansion request carrying the target physical disk identifier and the target mount point, a storage expansion instruction is sent to the management agent program, so that the management agent program creates a target storage volume based on the target physical disk identifier and mounts the target storage volume to the target mount point.

[0035] The target bare metal server refers to the physical server that needs to perform instance management operations. This physical server is not encapsulated by a virtualization layer and can directly provide physical-level computing resources to upper-layer applications. The out-of-band management address is the independent network access address corresponding to the Baseboard Management Controller (BMC) of the target bare metal server. This address is independent of the target bare metal server's business data network address and is used to remotely manage the target bare metal server even when it is powered off or the operating system has not yet started. The hardware vendor identifier is the identification information read from the Baseboard Management Controller of the target bare metal server through the out-of-band management address, used to uniquely identify the hardware manufacturer to which the target bare metal server belongs. The target virtual LAN refers to the VLAN (Virtual Local Area Network) to which the target bare metal server belongs in the network topology, used for logical isolation and traffic segmentation of the physical network within the data center. The installation template refers to a predefined automated operating system installation configuration file, containing disk partitioning schemes, network configuration parameters, and pre-built initialization scripts, among other installation configuration information. An operating system image refers to a complete operating system installation file associated with an installation template, including the operating system kernel file, root file system, and basic software packages.

[0036] The hardware driver set refers to a collection of driver files, determined through matching and filtering, that correspond to the actual hardware components mounted on the target bare metal server. The target deployment image is a customized image file generated after injecting the hardware driver set into the operating system image; it can be directly used for operating system deployment on the target bare metal server. The temporary boot IP address is a network address temporarily allocated to the target bare metal server from the address pool of the target virtual LAN. It is used only during the PXE network boot phase and is released and recycled after the operating system installation is complete. The baseboard out-of-band interface refers to the management interface (usually a Redfish RESTful API or IPMI protocol interface) exposed by the baseboard management controller of the target bare metal server, used to perform out-of-band management operations such as remote power control, network configuration, and boot device sequence settings. Pre-boot network parameters are a set of network configuration data written to the network boot configuration register of the target bare metal server, including the temporary boot IP address, subnet mask, default gateway address, and domain name resolution server address, used by the target bare metal server to establish network connections during the PXE boot phase. The management agent program refers to a resident agent service process deployed inside the operating system of the target bare metal server. It is responsible for receiving management instructions from the bare metal server instance management system and performing operations such as adjusting computing resource quotas and creating and mounting storage volumes within the operating system.

[0037] The resource adjustment instruction refers to the management instruction sent by the bare metal server instance management system to the management agent, carrying target resource quota information. The computing resource quota refers to the current configuration of the number of CPU cores and memory capacity available to upper-layer applications on the target bare metal server. The target resource quota refers to the target value to which the computing resource quota of the target bare metal server needs to be adjusted. The storage expansion request refers to a request sent by a user or upper-layer business system to the bare metal server instance management system, carrying the target physical disk identifier and the target mount point. The target physical disk identifier is the unique identifier of the physical disk on the target bare metal server that needs to be used to create the storage volume. The target mount point is the directory path in the operating system's file system used to mount the target storage volume. The storage expansion instruction refers to the management instruction sent by the bare metal server instance management system to the management agent to create a storage volume and perform the mount operation. The target storage volume refers to the LVM (Logical Volume Manager) logical volume created by the management agent on the physical disk based on the target physical disk identifier.

[0038] In the above embodiments, this application involves a bare metal server instance management system, a target bare metal server, and an operating system running on the target bare metal server. Communication between the three includes two methods: The first is management communication via an out-of-band management network, where the bare metal server instance management system accesses the baseboard management controller through the out-of-band management address of the target bare metal server for operations such as hardware information query, network boot configuration, and power control. The second is business communication via a data network, where the bare metal server instance management system establishes a communication connection with a management agent program running within the target bare metal server's operating system for operations such as resource quota adjustment and storage volume management. The bare metal server instance management system, as the executing entity of the method, is responsible for the unified orchestration and lifecycle management of multiple physical servers within the data center. This management system maintains a driver package repository locally and possesses management functions such as image customization, network configuration, and resource scheduling. The target bare metal server refers to the physical server hardware that currently needs to perform instance management operations. This physical server includes hardware components such as a baseboard management controller, physical CPU cores, physical memory modules, physical disks, network interface cards, and storage controllers. In step S104, the operating system is installed on the local disk of the target bare metal server. It manages hardware resources and provides a runtime environment for upper-layer applications. The operating system image contains a pre-installed management agent, which runs automatically as a background service process after the operating system starts. This agent establishes a communication connection with the bare metal server instance management system, receives instructions from the management system, and calls the system interfaces provided by the operating system to perform corresponding operations. The bare metal server's lifecycle management is divided into deployment and operation phases: In the deployment phase (corresponding to steps S101 to S104), the bare metal server instance management system accesses the baseboard management controller of the target bare metal server through the out-of-band management network to complete hardware information acquisition, hardware driver adaptation, network boot configuration, and controls the target bare metal server to obtain the target deployment image via the PXE protocol and complete the operating system installation; In the operation phase (corresponding to steps S105 to S106), after the operating system starts, the management agent registers with the bare metal server instance management system. Subsequently, the bare metal server instance management system sends management instructions to the management agent through the data network, and the management agent performs operations such as dynamic adjustment of computing resource quotas and online expansion of storage volumes within the operating system.

[0039] In the above embodiment, a scenario is illustrated using a data center comprising bare metal servers from multiple hardware vendors, and the data center's network topology is divided into multiple VLANs. After receiving an instance deployment request for a target bare metal server, the bare metal server instance management system first obtains the out-of-band management address of the target bare metal server from pre-entered device asset information, for example, ABCD (where ABCD is a valid address within the out-of-band management network segment). Then, it sends a hardware information query request to the baseboard management controller of the target bare metal server via this out-of-band management address. The system information returned by the baseboard management controller extracts the manufacturer field value, determining the hardware vendor identifier as the first hardware vendor identifier. Based on the mapping relationship between the physical switch port and VLAN configuration of the target bare metal server recorded in the device asset information, the target virtual LAN to which the target bare metal server belongs is determined to be the first target virtual LAN. A hardware driver set matching the first hardware vendor identifier is selected from the local driver package repository, and this hardware driver set is injected into the operating system image associated with the user-selected installation template, generating a target deployment image containing customized hardware drivers corresponding to the first hardware vendor identifier. Select an idle address from the address pool associated with the first target virtual LAN as a temporary boot IP address, and call the network configuration endpoint of the baseboard out-of-band interface of the target bare metal server through the out-of-band management address. Write the temporary boot IP address, subnet mask, default gateway address and domain name resolution server address as pre-boot network parameters into the network boot configuration register of the target bare metal server, and set the preferred boot device to the network interface card.

[0040] In the above embodiment, a restart command is sent to the baseboard out-of-band interface of the target bare metal server. After restarting, the target bare metal server obtains the target deployment image from the image distribution service of the bare metal server instance management system via the PXE protocol according to the pre-boot network parameters, and completes the automated installation of the operating system according to the disk partitioning scheme defined in the installation template. After the operating system is installed and started, the management agent program pre-installed in the operating system automatically registers with the bare metal server instance management system and establishes a long connection channel. When a user submits a resource quota adjustment request through the management console (for example, adjusting the number of available CPU cores from N cores to M cores, and the available memory capacity from P GB to Q GB, where M is less than N and Q is less than P), a resource adjustment command carrying the target resource quota is sent to the management agent program. The management agent program sets the excess (NM) physical CPU cores to offline status through the CPU hot-swap interface and sets the excess (PQ) GB physical memory segments to offline status through the memory node control interface, thereby realizing the online shrinkage of computing resource quota. When a user submits a storage expansion request through the management console (e.g., specifying the target physical disk as the second physical disk on the target bare metal server and the target mount point as the specified data directory path), a storage expansion instruction is sent to the management agent. The management agent creates a physical volume based on the second physical disk, then creates a volume group and creates a logical volume on the volume group as the target storage volume. Finally, the target storage volume is formatted to the target file system format and mounted to the specified data directory path.

[0041] Through the above steps, hardware vendors are automatically identified and virtual LANs are determined via out-of-band management addresses. Customized driver injection and dynamic configuration of pre-boot network parameters using the baseboard's out-of-band interface avoid strong dependence on fixed DHCP / TFTP service topologies, improving installation success rates and deployment efficiency in multi-vendor, cross-VLAN environments. Then, during the operating system runtime phase on the target bare metal server, a management agent dynamically adjusts computing resource quotas and expands storage volumes, achieving elastic resource scaling throughout the bare metal server's lifecycle without interrupting operating system operation. This solves the technical problem of low lifecycle management efficiency for bare metal servers in cross-VLAN and multi-vendor mixed operating environments, achieving the technical effect of improving lifecycle management efficiency for bare metal servers in such environments.

[0042] The entity performing the above steps can be a system, such as a bare metal server instance management system, or a device, or a controller or processor in a system or platform, or a separate controller or processor, or other processing devices or processing units with similar processing functions, but is not limited to these.

[0043] In an optional embodiment, before adding the set of hardware drivers matching the hardware vendor identifier to the operating system image associated with the installation template, the method further includes: querying a set of candidate driver packages associated with the hardware vendor identifier from a local driver package repository, each candidate driver package in the set carrying an operating system kernel version range and a hardware component type; obtaining the target kernel version number of the operating system image and performing range matching between the target kernel version number and the operating system kernel version range to obtain a version-matching driver package set; obtaining the digital signature certificate for each version-matching driver package in the version-matching driver package set, and obtaining the digital signature certificate associated with the hardware vendor identifier. The process involves identifying the corresponding pre-set trust certificate chain; performing security verification on the digital signature certificate based on the pre-set trust certificate chain to obtain the security verification result; removing version-matching driver packages that fail security verification from the version-matching driver package set based on the security verification result to obtain the target driver package set; classifying and grouping the target driver package set according to hardware component type to generate a categorized driver list; querying hardware assets by calling the substrate hardware list interface of the target bare metal server through the out-of-band management address to obtain the list of hardware component types actually installed on the target bare metal server; comparing and filtering the hardware component type list with the categorized driver list to obtain the hardware driver set.

[0044] The local driver package repository refers to the driver file repository maintained locally by the bare metal server instance management system. This repository categorizes and stores driver packages according to hardware vendor identifiers, with each driver package corresponding to a specific hardware component. The candidate driver package set refers to the collection of all driver packages associated with the hardware vendor identifier of the target bare metal server, retrieved from the local driver package repository. The operating system kernel version range is a metadata field carried by each candidate driver package, identifying the upper and lower limits of the operating system kernel versions that the driver package is compatible with, such as XYZ-AAAA to XYZ-NNNN. The hardware component type refers to the functional category of the hardware component corresponding to each candidate driver package, such as network interface card driver, storage controller driver, GPU computing card driver, etc. The target kernel version number refers to the specific version number of the operating system kernel contained in the operating system image associated with the installation template, such as XYZ-NNNN. The version-matching driver package set refers to the subset of driver packages in the candidate driver package set whose operating system kernel version range covers the target kernel version number.

[0045] The digital signature certificate refers to the code signing certificate issued by the hardware manufacturer and attached to each version-matching driver package. It is used to verify the integrity and legality of the driver package file. The pre-configured trust certificate chain refers to the root certificate and intermediate certificate chain pre-configured in the bare metal server instance management system, corresponding to a specific hardware manufacturer identifier. It is used to verify the trust chain of the driver package's digital signature certificate. The security verification result refers to the judgment result obtained after verifying the certificate chain and signature integrity of the digital signature certificate based on the pre-configured trust certificate chain. The result is either verification passed or verification failed. The target driver package set refers to the compliant driver package set obtained by removing driver packages that failed the security verification from the version-matching driver package set. The categorized driver list is a structured list generated after grouping the target driver package set according to hardware component type. This categorized driver list includes multiple driver groups, each identified by the hardware component type. Each driver group records the driver package identifier and storage path of one or more target driver packages belonging to that hardware component type. The substrate hardware manifest interface refers to the hardware asset query interface (e.g., a hardware asset information endpoint based on the Redfish specification) provided by the substrate management controller of the target bare metal server. This interface allows access to a list of the hardware components actually installed on the target bare metal server. The hardware component type list refers to the list of all hardware component types actually installed on the target bare metal server, obtained through the substrate hardware manifest interface query, including entries such as the first network interface card and the first storage controller.

[0046] In the above embodiment, a scenario is described using the hardware vendor identifier as the first hardware vendor identifier and the target kernel version number of the operating system image as XYZ-NNNN as an example. A set of candidate driver packages associated with the first hardware vendor identifier is queried from the local driver package repository. This set of candidate driver packages contains 12 candidate driver packages, each carrying an operating system kernel version range (e.g., the operating system kernel version range of candidate driver package A is XYZ-AAAA to XYZ-NNNN) and a hardware component type (e.g., the hardware component type of candidate driver package A is a network interface card driver). The target kernel version number of the operating system image is obtained as XYZ-NNNN. The target kernel version number is then matched against the operating system kernel version range of each candidate driver package to obtain a version-matching driver package set, which includes 8 version-matching driver packages. Subsequently, the digital signature certificates of each of the 8 version-matching driver packages are obtained, and a pre-configured trust certificate chain (including the root CA certificate and intermediate CA certificate for code signing of the hardware vendor) corresponding to the first hardware vendor identifier is obtained from the configuration of the bare metal server instance management system.

[0047] In the above embodiment, a pre-built trust certificate chain is used to verify the integrity of the certificate chain and verify the signature hash of the digital signature certificate of each version matching driver package. It is determined that the security verification result of 6 version matching driver packages passes, while the security verification result of 2 version matching driver packages fails because their digital signature certificates have expired. The 2 version matching driver packages that fail the security verification are removed, resulting in a target driver package set including 6 driver packages. The target driver package set is classified and grouped according to hardware component type to generate a categorized driver list. This categorized driver list includes three driver groups: a network interface card driver group (2 driver packages), a storage controller driver group (2 driver packages), and a management controller driver group (2 driver packages). The baseboard hardware list interface of the target bare metal server is called through the out-of-band management address to obtain a list of hardware component types actually installed on the target bare metal server. This hardware component type list records two types of hardware components: the first network interface card and the first storage controller. By comparing and filtering the list of hardware component types with the list of categorized drivers, the network interface card driver group corresponding to the first network interface card and the storage controller driver group corresponding to the first storage controller are determined, thereby obtaining a hardware driver set consisting of two driver packages: one driver package in the network interface card driver group that matches the first network interface card and one driver package in the storage controller driver group that matches the first storage controller.

[0048] In an optional embodiment, a set of hardware drivers matching the hardware vendor identifier is added to the operating system image associated with the installation template to generate a target deployment image. This includes: mounting the root file system partition of the operating system image to a temporary working directory according to a preset read / write method; determining the kernel module storage path corresponding to the target kernel version number in the root file system partition based on the target kernel version number, and creating a driver loading staging area under the kernel module storage path; determining the system boot dependency level of the hardware driver set based on the hardware component types recorded in the categorized driver list; decompressing the hardware driver set according to the system boot dependency level to obtain multiple driver module files, and writing the multiple driver module files into the driver loading staging area; determining the module dependency relationships of the multiple driver module files in the driver loading staging area; registering the module dependency relationships to the module dependency relationship file of the root file system partition, and performing a mount / unmount operation on the root file system partition; and image packaging the successfully mounted / unmounted root file system partition to generate the target deployment image.

[0049] The default read / write mode refers to mounting partitions in the operating system image to the file system in read / write mode, allowing modification of files within the partitions. The root file system partition is the main partition in the operating system image that includes a complete file system directory structure (such as / , / usr, / lib, etc.). The temporary working directory is a temporary file system mount point directory (e.g., / tmp / image_mount_workspace) created by the bare metal server instance management system during image customization operations. The kernel module storage path is the standard directory path in the root file system partition used to store loadable kernel module files, with the format / lib / modules / <kernel version number> / , for example, / lib / modules / XYZ-NNNN / . The driver loading staging area is a subdirectory created under the kernel module storage path to temporarily store driver module files to be injected (e.g., / lib / modules / XYZ-NNNN / extra / custom_drivers / ).

[0050] The system boot dependency hierarchy refers to the driver loading priority hierarchy based on hardware component type. For example, storage controller drivers are required for system boot (must be loaded first during system startup to identify the root disk), while network interface card drivers are not required (can be loaded after system startup). Driver module files are Linux kernel loadable module files with the .ko (kernel object) suffix, extracted from the driver package. Module dependencies refer to the loading dependencies between multiple driver module files; that is, a driver module needs to load its dependent modules before it can be loaded. The module dependency file is an index file (i.e., modules.dep file) in the root file system partition that records the dependencies between all kernel modules. The operating system reads this file to determine the module loading order when loading kernel modules. Mount / unmount operations refer to performing a umount operation on the root file system partition previously mounted to the temporary working directory to release the mount relationship. Image packaging refers to repackaging the root file system partition after driver injection and configuration modifications to generate a complete image file that can be used for network distribution.

[0051] In the above embodiments, after obtaining the hardware driver set including two driver packages, the following target deployment image generation process is executed. The root file system partition of the operating system image is mounted to the temporary working directory using a preset read / write method. Based on the target kernel version number XYZ-NNNN, the kernel module storage path in the root file system partition is determined to be the / lib / modules / XYZ-NNNN / directory under the temporary working directory, and a driver loading temporary storage subdirectory is created under this kernel module storage path. Based on the hardware component types recorded in the categorized driver list, the system boot dependency level of the hardware driver set is determined: the storage controller driver module file corresponding to the first storage controller belongs to the system boot essential level (must be loaded first during system startup to identify the root disk), and the network interface card driver module file corresponding to the first network interface card belongs to the system boot non-essential level (can be loaded after system startup). Following the system boot dependency priority order (first decompressing driver packages for essential system boot layers, then decompressing driver packages for non-essential system boot layers), the two driver packages in the hardware driver set are decompressed to obtain the first driver module file corresponding to the first storage controller and the second driver module file corresponding to the first network interface card. These first and second driver module files are then written to a subdirectory of the driver loading staging area. A module dependency analysis command is executed to scan the dependencies of the first and second driver module files in the driver loading staging area, determining module dependencies (e.g., the first driver module file depends on an existing SCSI transport layer module in the operating system image), and updating and registering these dependencies in the module dependency file of the root file system partition. After completing the module dependency registration, a mount / unmount operation is performed on the root file system partition to release the mount relationship. The successfully unmounted root file system partition is then image-encapsulated and repackaged into a complete image file suitable for network distribution, generating the target deployment image.

[0052] In an optional embodiment, after querying the set of candidate driver packages associated with the hardware vendor identifier from the local driver package repository, the method further includes: calling the substrate firmware manifest interface of the target bare metal server through an out-of-band management address to obtain the firmware version information of the hardware component cluster actually mounted on the target bare metal server; comparing the firmware version information with the compatible firmware version requirements corresponding to each candidate driver package to determine the first firmware version that does not meet the compatible firmware version requirements; determining the target hardware component that matches the first firmware version from the hardware component cluster; obtaining a firmware upgrade package that matches the component model of the target hardware component, wherein the second firmware version of the firmware upgrade package meets the compatible firmware version requirements; calling the substrate firmware update interface of the target bare metal server through an out-of-band management address to push the firmware upgrade package to the target hardware component to trigger the target hardware component to perform a firmware online flashing operation; and marking the candidate driver packages in the candidate driver package set that match the hardware component type of the target hardware component as firmware compatible when the target hardware component completes the firmware online flashing operation and the first firmware version has been updated to the second firmware version.

[0053] The "Baseboard Firmware Manifestation Interface" refers to the management interface (e.g., a Redfish-based firmware asset query endpoint) provided by the baseboard management controller of the target bare metal server for querying firmware version information of hardware components. This interface allows access to the currently running firmware version number of each hardware component on the target bare metal server. The "Hardware Component Cluster" refers to the collection of all hardware components on the target bare metal server that require firmware support. "Firmware Version Information" refers to the list of current firmware version numbers for each hardware component returned by the Baseboard Firmware Manifestation Interface. "Compatible Firmware Version Requirement" refers to the minimum firmware version number of the corresponding hardware component required for the normal operation of each candidate driver package, as indicated in its metadata. "First Firmware Version" refers to the current firmware version number of a hardware component on the target bare metal server, where this current firmware version number is lower than the minimum compatible firmware version number required by the corresponding candidate driver package.

[0054] In this context, "target hardware component" refers to a specific hardware component in the hardware component cluster whose firmware version does not meet the compatibility firmware version requirements. "Firmware upgrade package" refers to a firmware update file package obtained from the firmware update repository that matches the component model of the target hardware component. "Second firmware version" refers to the target firmware version number contained in the firmware upgrade package, which meets the compatibility firmware version requirements of the candidate driver package. "Baseboard firmware update interface" refers to the management interface (e.g., a Redfish-based firmware update operation endpoint) provided by the baseboard management controller of the target bare metal server for performing hardware component firmware updates. "Firmware online flashing operation" refers to the operation where the target hardware component, after receiving the firmware upgrade package, updates its own firmware from the first firmware version to the second firmware version without shutting down the target bare metal server. "Firmware compatibility status" refers to the status value marked on the candidate driver package after the corresponding hardware component completes the firmware upgrade, indicating that the candidate driver package meets the compatibility requirements with the firmware version of the corresponding hardware component on the target bare metal server.

[0055] In the above embodiment, after retrieving the candidate driver package set of 12 candidate driver packages associated with the first hardware vendor identifier from the local driver package repository, a firmware compatibility detection process is further executed. The firmware version information of the hardware component cluster actually mounted on the target bare metal server is obtained by calling the baseboard firmware manifest interface of the target bare metal server through an out-of-band management address. This firmware version information includes, for example, the current firmware version of the first network interface card being version V1 and the current firmware version of the first storage controller being version V2. The firmware version information is compared with the compatible firmware version requirements corresponding to each candidate driver package in the candidate driver package set. For example, the candidate driver package corresponding to the first network interface card requires the network interface card firmware version to be no lower than version V3. The comparison determines that the current firmware version V1 of the first network interface card does not meet the compatible firmware version requirement V3 (i.e., V1 is lower than V3), and this firmware version V1 is the first firmware version. The target hardware component matching the first firmware version V1 is determined from the hardware component cluster as the first network interface card. A firmware upgrade package matching the component model of the first network interface card is retrieved from the firmware update repository. The second firmware version of this upgrade package is version V4, meeting the firmware version compatibility requirement (i.e., V4 is not lower than V3). The firmware upgrade package is pushed to the first network interface card by calling the baseboard firmware update interface of the target bare metal server through the out-of-band management address, triggering the target hardware component to perform an online firmware flashing operation. The firmware version number of the first network interface card is continuously polled through the baseboard firmware manifest interface. After confirming that the first firmware version V1 has been updated to the second firmware version V4, the candidate driver packages in the candidate driver package set that match the hardware component type (i.e., network interface card driver) of the first network interface card are marked as firmware compatible.

[0056] In the above embodiments, a candidate driver package marked as firmware compatible indicates that its corresponding hardware component has completed the firmware upgrade, and the compatibility constraint between the candidate driver package and the firmware version of the corresponding hardware component on the target bare metal server has been met. During subsequent version matching, digital signature certificate security verification, and hardware component type list comparison and filtering processes, the candidate driver package marked as firmware compatible participates in the matching and filtering operations at each stage in the same manner as other candidate driver packages. That is, the firmware compatibility mark only indicates that the firmware-level compatibility verification has passed; it does not affect the normal participation and filtering of the candidate driver package in the operating system kernel version range matching, digital signature certificate security verification, and hardware component type comparison and filtering stages.

[0057] In an optional embodiment, a temporary boot IP address is allocated to the target bare metal server within the target virtual LAN, and the baseboard out-of-band interface of the target bare metal server is invoked to configure the temporary boot IP address as a pre-boot network parameter of the target bare metal server. This includes: selecting an idle candidate boot address from an address pool associated with the target virtual LAN and marking the candidate boot address as temporarily occupied in the address pool; obtaining the subnet mask, default gateway address, and domain name resolution server address of the target virtual LAN according to the network topology configuration of the target virtual LAN; and configuring the subnet mask, default gateway address, and domain name resolution server address... The system combines the address and candidate boot addresses to generate pre-boot network parameters; it calls the network configuration endpoint of the substrate's out-of-band interface through the out-of-band management address to write the pre-boot network parameters into the network boot configuration register of the target bare metal server; it sends a boot device sequence setting instruction to the substrate's out-of-band interface to set the preferred boot device of the target bare metal server as the network interface card, so that the target bare metal server will prioritize the network boot process on the next boot; after the target bare metal server completes the operating system installation, it sends a network configuration clear instruction to the substrate's out-of-band interface; it releases the candidate boot address and updates the candidate boot address in the address pool to an idle state.

[0058] The address pool refers to the IP address range associated with the target VLAN, uniformly managed by the bare metal server instance management system. Each IP address in the address pool has a status marker such as idle or temporarily occupied. A candidate boot address is an idle IP address selected from the address pool, used as a temporary IP address by the target bare metal server during the PXE network boot phase. Temporarily occupied status refers to the status marked in the address pool after a candidate boot address is assigned to the target bare metal server, indicating that the address is currently occupied and only used temporarily during the boot phase. Network topology configuration refers to the network parameter configuration information about the target VLAN stored in the bare metal server instance management system, including the subnet mask, default gateway address, and domain name resolution server address. The subnet mask is the mask value used in the target VLAN to identify the boundary between network addresses and host addresses. The default gateway address is the interface address of the Layer 3 switch or router in the target VLAN used to forward traffic to other network segments.

[0059] In this context, the Domain Name Resolution Server address refers to the IP address of the server in the target virtual LAN that provides DNS domain name resolution services. The Network Configuration Endpoint refers to the specific API endpoint (e.g., a Redfish-based network interface configuration endpoint) in the baseboard out-of-band interface used to set the PXE boot network parameters of the target bare metal server. The Network Boot Configuration Register is a non-volatile storage area in the baseboard management controller of the target bare metal server used to store network configuration parameters during the PXE boot phase. The Boot Device Sequence Setting Command is a management command sent to the baseboard management controller of the target bare metal server via the baseboard out-of-band interface to modify the boot device priority order. The Network Interface Card refers to the physical network adapter on the target bare metal server used for network communication; when it is set as the preferred boot device, the target bare metal server will prioritize executing the PXE network boot process through the network interface card during startup. The Network Configuration Clear Command is a management command sent to the baseboard out-of-band interface after the operating system installation is complete to clear previously written temporary pre-boot network parameters.

[0060] In the above embodiment, after determining that the target virtual local area network (VLAN) to which the target bare metal server belongs is the first target VLAN, the following temporary boot IP address allocation and pre-boot network parameter configuration process is executed. The address pool associated with the first target VLAN is queried (the available address range of this address pool is a continuous IP address segment from the start address to the end address). A candidate boot address in an idle state is selected from the address pool, and the status flag of the candidate boot address is updated from idle to temporarily occupied in the address pool management database. The subnet mask, default gateway address, and domain name resolution server address are obtained according to the pre-configured network topology of the first target VLAN. The subnet mask, default gateway address, domain name resolution server address, and candidate boot address are combined to generate pre-boot network parameters. The network configuration endpoint of the baseboard's out-of-band interface is called through the out-of-band management address, and a parameter write request is sent to this network configuration endpoint to write the pre-boot network parameters into the network boot configuration register of the target bare metal server. After successful writing, a boot device sequence setting instruction is sent to the baseboard's out-of-band interface to set the preferred boot device of the target bare metal server as the network interface card, so that the target bare metal server will prioritize the network boot process upon the next boot. After the target bare-metal server restarts, it establishes a network connection using pre-boot network parameters and completes PXE booting and operating system installation. Once the target bare-metal server has successfully installed and booted the operating system, a network configuration clear command is sent to the substrate out-of-band interface to clear the temporary pre-boot network parameters in the network boot configuration register. The candidate boot address is released in the address pool management database, and its status flag is updated from temporarily occupied to free.

[0061] In an optional embodiment, a resource adjustment instruction is sent to a management agent within the operating system, causing the management agent to adjust the computing resource quota of the target bare metal server to a target resource quota according to the resource adjustment instruction. This includes: upon receiving a resource quota adjustment request, determining a target resource quota based on the resource quota adjustment request, the target resource quota including a target number of CPU cores and a target memory capacity; sending a resource adjustment instruction carrying the target resource quota to the management agent, causing the management agent to perform the following operations upon receiving the resource adjustment instruction: the management agent reads the current physical CPU topology information of the target bare metal server and determines the current number of physical CPU cores in the online state based on the current physical CPU topology information; the management agent reads the current memory status information of the target bare metal server and determines the current available memory capacity of the target bare metal server based on the current memory status information; and the management agent performs a resource status adjustment operation on the target bare metal server based on the target number of CPU cores, the target memory capacity, the current number of physical CPU cores, and the current available memory capacity.

[0062] The resource quota adjustment request refers to a management request sent by a user or the upper-layer scheduling system to the bare metal server instance management system to change the available computing resource specifications of the target bare metal server. This request carries the desired target number of CPU cores and target memory capacity. The target number of CPU cores refers to the number of physical CPU cores that the target bare metal server should be online and available after the adjustment, as specified in the resource quota adjustment request. The target memory capacity refers to the total physical memory capacity that the target bare metal server should be online and available after the adjustment, as specified in the resource quota adjustment request. The current physical CPU topology information refers to the information obtained by the management agent program through reading the operating system's CPU information interface (e.g., the / sys / devices / system / cpu / directory in Linux systems), including the IDs, online / offline status, and topology affiliation of all physical CPU cores on the target bare metal server.

[0063] The current number of physical CPU cores refers to the total number of physical CPU cores currently online, as determined by the current physical CPU topology information. The current memory status information refers to the information obtained by the management agent program from the operating system's memory information interface (e.g., the ` / sys / devices / system / memory / ` directory in Linux), including the number and online / offline status of all physical memory segments on the target bare metal server. The current available memory capacity refers to the total capacity of physical memory segments currently online, determined by the current memory status information. Resource status adjustment operations refer to the operations performed by the management agent program, based on the difference between the target resource quota and the current resource quota, through the CPU hot-plug interface and memory node control interface provided by the operating system, to switch the online or offline status of physical CPU cores and physical memory segments.

[0064] In the above embodiment, the scenario is illustrated by the user needing to adjust the available computing resources to 32 CPU cores and 128GB of memory, where the target bare metal server is currently configured with 64 physical CPU cores (all online) and 256GB of physical memory (all online). The user submits a resource quota adjustment request through the management console. Upon receiving the request, the bare metal server instance management system parses the parameters in the request and determines the target resource quota as: target CPU core count = 32, target memory capacity = 128GB. A resource adjustment instruction carrying the target resource quota (target CPU core count = 32, target memory capacity = 128GB) is sent to the management agent via a long-lived connection. Upon receiving the resource adjustment instruction, the management agent reads the online files of each CPU core in the / sys / devices / system / cpu / directory of the operating system to obtain the current physical CPU topology information of the target bare metal server. Based on this topology information, it counts the currently online physical CPU cores as cpu0 to cpu63, a total of 64, and determines the current physical CPU core count to be 64. The management agent reads the state files of each memory segment in the ` / sys / devices / system / memory / ` directory of the operating system to obtain the current memory status information of the target bare metal server. Based on this status information, it calculates the total capacity of the currently online physical memory segments to be 256GB, determining that the currently available memory capacity is 256GB. The management agent compares the target CPU core count (32) with the current physical CPU core count (64), determining that 32 physical CPU cores need to be adjusted from online to offline status; it also compares the target memory capacity (128GB) with the current available memory capacity (256GB), determining that 128GB of physical memory segments need to be adjusted from online to offline status. The management agent then performs resource status adjustment operations on the target bare metal server based on the target CPU core count, target memory capacity, current physical CPU core count, and current available memory capacity.

[0065] In an optional embodiment, the management agent performs resource status adjustment operations on the target bare metal server based on the target number of CPU cores, target memory capacity, current physical CPU cores, and current available memory capacity. This includes: when the management agent determines that the target number of CPU cores is greater than the current number of physical CPU cores, it adjusts the first physical CPU core in the target bare metal server that is currently offline to an online state via the operating system's CPU hot-swappable interface, so that the current number of physical CPU cores equals the target number of CPU cores; when the management agent determines that the target number of CPU cores is less than the current number of physical CPU cores, it adjusts the target bare metal server's memory status based on the CPU hot-swappable interface. The second physical CPU core in the target bare metal server is adjusted from online to offline to make the current number of physical CPU cores equal to the target number of CPU cores. When the management agent determines that the target memory capacity is less than the current available memory capacity, it sets the first physical memory segment in the target bare metal server from online to offline through the operating system's memory node control interface to make the current available memory capacity equal to the target memory capacity. When the management agent determines that the target memory capacity is greater than the current available memory capacity, it adjusts the second physical memory segment in the target bare metal server from offline to online through the operating system's memory node control interface to make the current available memory capacity equal to the target memory capacity.

[0066] The CPU hot-swap interface refers to the kernel interface provided by the Linux operating system for dynamically enabling or disabling physical CPU cores at runtime. Specifically, it switches the online or offline status of the corresponding physical CPU core by writing 1 (enabling) or 0 (disabling) to the ` / sys / devices / system / cpu / cpuN / online` file. The first physical CPU core refers to the physical CPU core in the target bare-metal server that is offline and needs to be adjusted to an online state when the target number of CPU cores is greater than the current number of physical CPU cores. The second physical CPU core refers to the physical CPU core in the target bare-metal server that is online and needs to be adjusted to an offline state when the target number of CPU cores is less than the current number of physical CPU cores. The memory node control interface refers to the system interface provided by the Linux operating system kernel for dynamically enabling or disabling physical memory segments at runtime. Specifically, it switches the online or offline status of the corresponding physical memory segment by writing `online` (enabling) or `offline` (disabling) to the ` / sys / devices / system / memory / memoryN / state` file. The first physical memory segment refers to the physical memory segment in the target bare metal server that is currently online but needs to be set to offline status when the target memory capacity is less than the currently available memory capacity. The second physical memory segment refers to the physical memory segment in the target bare metal server that is currently offline but needs to be adjusted to online status when the target memory capacity is greater than the currently available memory capacity.

[0067] In the above embodiment, the target CPU core count is 32, the target memory capacity is 128GB, the current physical CPU core count is 64, and the current available memory capacity is 256GB. The specific process of the management agent program performing resource status adjustment operations is as follows: The management agent program first compares the target CPU core count (32) with the current physical CPU core count (64), determining that the target CPU core count is less than the current physical CPU core count, and therefore 32 physical CPU cores need to be adjusted from online to offline. The management agent program selects 32 online physical CPU cores numbered cpu32 to cpu63 as the second physical CPU cores, and sequentially writes 0 to the files / sys / devices / system / cpu / cpu32 / online to / sys / devices / system / cpu / cpu63 / online through the operating system's CPU hot-swap interface, adjusting these 32 second physical CPU cores to offline status. After the adjustment, the target bare metal server has 32 online physical CPU cores, from cpu0 to cpu31, and the current physical CPU core count is equal to the target CPU core count (32). Subsequently, the management agent compares the target memory capacity of 128GB with the current available memory capacity of 256GB. Determining that the target memory capacity is smaller than the current available memory capacity, the 128GB physical memory segment needs to be set from online to offline. The target bare-metal server's physical memory is divided into 2048 physical memory segments (memory0 to memory2047) in 128MB increments. The management agent selects 1024 online physical memory segments (memory1024 to memory2047) as the first physical memory segment (totaling 128GB). Through the operating system's memory node control interface, it sequentially writes "offline" to the files / sys / devices / system / memory / memory1024 / state to / sys / devices / system / memory / memory2047 / state, setting these 1024 first physical memory segments to offline status. After the adjustment, the physical memory segments of the target bare metal server that are online are memory0 to memory1023, totaling 128GB, and the current available memory capacity is equal to the target memory capacity of 128GB.If the workload increases subsequently and the user submits a new resource quota adjustment request, increasing the target number of CPU cores to 48 and the target memory capacity to 192GB, the management agent program determines that the target number of CPU cores (48) is greater than the current number of physical CPU cores (32). It selects 16 offline physical CPU cores (numbered cpu32 to cpu47) as the first physical CPU cores and writes "1" to the corresponding online file through the CPU hot-swap interface to bring them online. At the same time, it determines that the target memory capacity (192GB) is greater than the current available memory capacity (128GB). It selects 512 offline physical memory segments (64GB in total) (numbered memory1024 to memory1535) and writes "online" to the corresponding state file through the memory node control interface to bring these 512 offline second physical memory segments online.

[0068] It should be noted that the examples of all the specific values ​​mentioned above are merely exemplary embodiments, and the specific values ​​are not limited to the examples mentioned above.

[0069] Through the embodiments of this application, driver matching, digital signature security verification, and firmware compatibility upgrades can be automatically completed based on the hardware vendor identifier of the target bare metal server in a multi-vendor equipment mixed operation environment to eliminate hardware driver adaptation gaps. By directly allocating temporary boot IP addresses within the target virtual LAN and accurately configuring pre-boot network parameters via the baseboard out-of-band interface, the cross-VLAN communication restrictions of traditional DHCP and TFTP service topologies can be bypassed. By utilizing the CPU hot-swappable interface and memory node control interface of the operating system through the management agent program, runtime online bidirectional elastic scaling of computing resources can be achieved. By implementing storage expansion instructions, runtime creation and mounting of storage volumes can be achieved. This allows the bare metal server to dynamically adjust the computing and storage resource configuration according to business needs throughout its entire lifecycle, improving the lifecycle management efficiency of bare metal servers in cross-VLAN and multi-vendor equipment mixed operation environments.

[0070] The bare metal server instance management system in the embodiments of this invention is described below from the perspective of hardware processing. (See attached document.) Figure 2 , Figure 2 This is a schematic diagram of the physical device structure of a bare metal server instance management system in this application embodiment.

[0071] It should be noted that, Figure 2 The structure of the bare metal server instance management system shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0072] like Figure 2As shown, the bare metal server instance management system includes a Central Processing Unit (CPU) 201, which can perform various appropriate actions and processes based on programs stored in Read-Only Memory (ROM) 202 or programs loaded from storage section 208 into Random Access Memory (RAM) 203, such as executing the methods described in the above embodiments. The RAM 203 also stores various programs and data required for platform operation. The CPU 201, ROM 202, and RAM 203 are interconnected via bus 204. An I / O interface 205 is also connected to bus 204. The following components are connected to the I / O interface 205: an input section 206 including audio input devices, push-button switches, etc.; an output section 207 including a Liquid Crystal Display (LCD) and audio output devices, indicator lights, etc.; a storage section 208 including a hard disk, etc.; and a communication section 209 including network interface cards such as LAN (Local Area Network) cards, modems, etc. The communication section 209 performs communication processing via a network such as the Internet. The drive 210 is also connected to the I / O interface 205 as needed. Removable media 211, such as disks, optical disks, magneto-optical disks, semiconductor memories, etc., are installed on the drive 210 as needed so that computer programs read from them can be installed into the storage section 208 as needed.

[0073] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing computer programs for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 209, and / or installed from removable medium 211. When the computer program is executed by central processing unit (CPU) 201, it performs the various functions defined in the present invention.

[0074] It should be noted that specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution platform, apparatus, or device.

[0075] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of platforms, methods, and computer program products according to various embodiments of the present invention. Each block in a flowchart or block diagram may represent a module, program segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those shown in the drawings.

[0076] Specifically, the bare metal server instance management system of this embodiment includes a processor and a memory. The memory stores a computer program. When the computer program is executed by the processor, it implements the bare metal server instance management method provided in the above embodiment.

[0077] In another aspect, the present invention also provides a computer-readable storage medium, which may be included in the bare metal server instance management system described in the above embodiments; or it may exist independently and not assembled into the bare metal server instance management system. The storage medium carries one or more computer programs, which, when executed by a processor of the bare metal server instance management system, cause the bare metal server instance management system to implement the bare metal server instance management method provided in the above embodiments.

[0078] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

[0079] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or random access memory (RAM), magnetic disks, or optical disks.

Claims

1. A method for managing bare metal server instances, characterized in that, include: Obtain the out-of-band management address of the target bare metal server, obtain the hardware vendor identifier of the target bare metal server based on the out-of-band management address, and determine the target virtual LAN to which the target bare metal server belongs; Add the set of hardware drivers that match the hardware vendor identifier to the operating system image associated with the installation template to generate the target deployment image; Within the target virtual LAN, a temporary boot IP address is assigned to the target bare metal server, and the baseboard out-of-band interface of the target bare metal server is invoked to configure the temporary boot IP address as the pre-boot network parameter of the target bare metal server; The target bare metal server is controlled to obtain the target deployment image according to the pre-boot network parameters, and to install an operating system on the target bare metal server according to the target deployment image; During the operation of the operating system on the target bare metal server, a resource adjustment instruction is sent to the management agent program within the operating system, so that the management agent program adjusts the computing resource quota of the target bare metal server to the target resource quota according to the resource adjustment instruction; Upon receiving a storage expansion request carrying the target physical disk identifier and the target mount point, a storage expansion instruction is sent to the management agent program, so that the management agent program creates a target storage volume based on the target physical disk identifier and mounts the target storage volume to the target mount point; The method further includes, prior to adding the hardware driver set matching the hardware vendor identifier to the operating system image associated with the installation template: Query the local driver package repository for a set of candidate driver packages associated with the hardware vendor identifier, where each candidate driver package carries an operating system kernel version range and a hardware component type. Obtain the target kernel version number of the operating system image, and perform range matching between the target kernel version number and the operating system kernel version range to obtain a set of version-matched driver packages; Obtain the digital signature certificate for each version-matching driver package in the version-matching driver package set, and obtain the pre-set trust certificate chain corresponding to the hardware manufacturer identifier; The digital signature certificate is security verified based on a pre-set trust certificate chain to obtain a security verification result. Based on the security verification result, remove the version matching driver packages that fail the security verification from the version matching driver package set to obtain the target driver package set; The target driver package set is classified and grouped according to the hardware component type to generate a classified driver list; The hardware asset query is performed by calling the substrate hardware manifest interface of the target bare metal server through the out-of-band management address to obtain the list of hardware component types actually installed in the target bare metal server. The hardware component type list is compared and filtered with the categorized driver list to obtain the hardware driver set.

2. The method according to claim 1, characterized in that, The step of adding the hardware driver set matching the hardware vendor identifier to the operating system image associated with the installation template to generate the target deployment image includes: Mount the root file system partition of the operating system image to the temporary working directory according to the preset read / write method; Based on the target kernel version number, determine the kernel module storage path in the root file system partition corresponding to the target kernel version number, and create a driver loading temporary storage area under the kernel module storage path; The system boot dependency level of the hardware driver set is determined based on the hardware component types recorded in the classified driver list; The hardware driver set is decompressed according to the system boot dependency hierarchy to obtain multiple driver module files, and the multiple driver module files are written into the driver loading temporary storage area; Determine the module dependencies of the multiple driver module files in the driver loading temporary storage area; Register the module dependencies to the module dependency file of the root file system partition, and perform mount and unmount operations on the root file system partition; The root file system partition that was successfully unmounted is image-encapsulated to generate the target deployment image.

3. The method according to claim 1, characterized in that, After querying the set of candidate driver packages associated with the hardware vendor identifier from the local driver package repository, the method further includes: By calling the baseboard firmware manifest interface of the target bare metal server through the out-of-band management address, the firmware version information of the hardware component cluster actually installed on the target bare metal server can be obtained. The firmware version information is compared with the compatible firmware version requirements corresponding to each candidate driver package to determine the first firmware version in the firmware version information that does not meet the compatible firmware version requirements. Determine the target hardware component from the hardware component cluster that matches the first firmware version; Obtain a firmware upgrade package that matches the component model of the target hardware component, wherein the second firmware version of the firmware upgrade package meets the compatibility firmware version requirements; The target bare metal server's substrate firmware update interface is called through the out-of-band management address to push the firmware upgrade package to the target hardware component, thereby triggering the target hardware component to perform an online firmware flashing operation. When the target hardware component completes the firmware online flashing operation and the first firmware version has been updated to the second firmware version, the candidate driver package in the candidate driver package set that matches the hardware component type of the target hardware component is marked as firmware compatible.

4. The method according to claim 1, characterized in that, The step of allocating a temporary boot IP address to the target bare metal server within the target virtual LAN and calling the baseboard out-of-band interface of the target bare metal server to configure the temporary boot IP address as the pre-boot network parameter of the target bare metal server includes: Select an idle candidate boot address from the address pool associated with the target virtual LAN, and mark the candidate boot address as temporarily occupied in the address pool; Obtain the subnet mask, default gateway address, and domain name resolution server address of the target virtual local area network based on the network topology configuration of the target virtual local area network; The subnet mask, the default gateway address, the domain name resolution server address, and the candidate boot address are combined to generate the pre-boot network parameters; The network configuration endpoint of the substrate's out-of-band interface is invoked through the out-of-band management address, and the pre-boot network parameters are written into the network boot configuration register of the target bare metal server. Send a boot device sequence setting command to the substrate's external interface to set the preferred boot device of the target bare metal server as the network interface card, so that the target bare metal server will prioritize the network boot process upon the next startup. After the target bare metal server completes the installation of the operating system, it sends a network configuration clear command to the out-of-band interface of the substrate. Release the candidate boot address and update the candidate boot address to the idle state in the address pool.

5. The method according to claim 1, characterized in that, Sending a resource adjustment instruction to the management agent program within the operating system, so that the management agent program adjusts the computing resource quota of the target bare metal server to the target resource quota according to the resource adjustment instruction, includes: Upon receiving a resource quota adjustment request, a target resource quota is determined based on the resource quota adjustment request. The target resource quota includes the target number of CPU cores and the target memory capacity. Send a resource adjustment instruction carrying the target resource quota to the control agent, so that the control agent performs the following operations upon receiving the resource adjustment instruction: The control agent program reads the current physical CPU topology information of the target bare metal server and determines the number of physical CPU cores that are currently online based on the current physical CPU topology information. The management agent program reads the current memory status information of the target bare metal server and determines the current available memory capacity of the target bare metal server based on the current memory status information; The management agent program performs resource status adjustment operations on the target bare metal server based on the target number of CPU cores, the target memory capacity, the current number of physical CPU cores, and the current available memory capacity.

6. The method according to claim 5, characterized in that, The management agent program performs resource status adjustment operations on the target bare metal server based on the target number of CPU cores, the target memory capacity, the current number of physical CPU cores, and the current available memory capacity, including: When the control agent program determines that the target number of CPU cores is greater than the current number of physical CPU cores, it uses the CPU hot-swap interface of the operating system to adjust the first physical CPU core in the target bare metal server that is offline to online, so that the current number of physical CPU cores is equal to the target number of CPU cores. When the control agent determines that the target number of CPU cores is less than the current number of physical CPU cores, the control agent adjusts the second physical CPU core in the target bare metal server that is in an online state to an offline state through the CPU hot-swap interface, so that the current number of physical CPU cores is equal to the target number of CPU cores. When the management agent determines that the target memory capacity is less than the current available memory capacity, it sets the first physical memory segment in the target bare metal server that is online to offline through the memory node control interface of the operating system, so that the current available memory capacity is equal to the target memory capacity. When the management agent determines that the target memory capacity is greater than the current available memory capacity, it adjusts the second physical memory segment in the target bare metal server that is offline to an online state through the memory node control interface of the operating system, so that the current available memory capacity is equal to the target memory capacity.

7. A bare-metal server instance management system, characterized in that, The bare metal server instance management system includes: one or more processors and a memory; the memory is coupled to the one or more processors, the memory is used to store computer program code, the computer program code including computer instructions, and the one or more processors call the computer instructions to cause the bare metal server instance management system to perform the method as described in any one of claims 1-6.

8. A computer-readable storage medium comprising program instructions, characterized in that, When the program instructions are run on the bare metal server instance management system, the bare metal server instance management system performs the method as described in any one of claims 1-6.

9. A computer program product, characterized in that, When the computer program product is run on the bare metal server instance management system, the bare metal server instance management system performs the method as described in any one of claims 1-6.

Images