A Method and System for Implementing a Bare Metal Server Based on an Intelligent Network Card

Abstract

This invention provides a method for implementing a bare metal server based on a Smart NIC (Smart Network Interface Card). The method includes the following steps: providing a fully automated process for bare metal server deployment and Smart NIC preparation, preparing remote storage within the environment, and creating hot-swappable network / storage devices with the Smart NIC. The proposed Smart NIC-based bare metal server implementation method and system unifies the management of virtual machines and physical machines on a cloud platform, transforming the cloud platform's computing resources into a unified computing pool. Users only need to consider their own business needs, regardless of the differences between virtual machines and physical machines.

Description

Technical Field

[0001] The present invention relates to the technical field of cloud computing modules, and in particular to a method and system for implementing a bare metal server based on a smart network card. Background Art

[0002] Traditional bare metal servers provide users with complete physical machine resources, connected to the cloud platform's unified resource management platform, and offer limited functionality such as VPC networking and SAN storage. However, in actual use, these resources differ significantly from those used by cloud platform virtual machines.

[0003] like:

[0004] 1. Differences in VPC networks: Traditional bare metal servers require control of an L2 switch to complete network configuration. The OpenStack community supports VLAN networks by default. Based on this, the switch's hardware VxLAN tunnel function can provide access to the VxLAN network. However, this solution requires an additional switch and the configuration and deployment process is complex. Furthermore, traditional bare metal servers cannot use the full security group function and can only issue ACL rules on the switch and add some outbound rules to the switch port.

[0005] 2. Differences in EBS cloud disks: Traditional bare metal can only connect to FC-SAN / IP-SAN SAN storage. FC-SAN requires a SAN storage server and a physical host bus adapter (HBA), making deployment difficult and costly. IP-SAN cannot guarantee platform network security and may pose security risks. Cloud platforms typically use Ceph as a backend for distributed storage, and current bare metal products cannot provide support for distributed storage that balances high performance and security.

[0006] 3. Differences in backup and migration functions: Traditional bare metal systems provide users with local storage disks as system disks by default, which makes system image backup and migration difficult. Operations and maintenance personnel are required to log in to the tenant's operating system and manually create system disk images, which does not meet the requirements of cloud platform automated management.

[0007] In view of the above core issues, we urgently need a unified management method for virtual machines / physical machines that is adapted to the cloud platform architecture to solve the problems we encounter. Summary of the Invention

[0008] The purpose of the present invention is to provide a method and system for implementing a bare metal server based on a smart network card to solve the problems raised in the above background technology.

[0009] To achieve the above objectives, the present invention provides the following technical solution: a method and system for implementing a bare metal server based on a smart network card, comprising the following steps:

[0010] Each physical machine is equipped with two Smart NICs: Smart NIC A and Smart NIC B. Each Smart NIC provides one Gigabit Ethernet port and two 10 Gigabit Ethernet ports, allowing connections to different networks based on business needs.

[0011] Provides a complete automated process for bare metal racking and SmartNIC preparation:

[0012] a. Complete the physical machine installation and pre-installation of the Smart NIC;

[0013] b. Build a Preboot Execute Environment (PXE) in the environment, providing boot binary files, Grub menu, kernel, and initrd based on the Smart NIC and physical machine chip architecture.

[0014] c. Complete the Smart NIC preparation process, use the IPMI management tool to enable the Smart NIC to enter the PXE boot state, and boot into the temporary memory file system (initrd). Execute the custom init script in initrd to complete the firmware update and modify the PCI BAR parameters. Then, use OpenvSwitch to create a temporary bridge and connect it to the physical machine network device (PF, or Physical Function). (hereinafter referred to as PF) and the external network are connected to the temporary OVS bridge.

[0015] d. Continue to complete the subsequent physical machine deployment process. Since the physical machine is now connected to the external network, follow the above process to complete the PCI hardware device update of the physical machine and the bare metal node reporting environment tasks;

[0016] e. After the bare metal server node is successfully registered in the environment, the identification preparation process is completed;

[0017] Prepare remote storage in the environment. The storage backend can be Ceph, iSCSI, NFS, or NVME-of. Write the system image to the remote storage volume and record the volume's unique identifier. Then, power on the Smart NIC node and create the uniquely identified remote storage volume as an SPDK backend device. Within the Smart NIC node, create the storage device based on the backend device's identifier and configure the PCI BAR base address register to create a PCI PF (Physical Function) device of the specified type. After completing these steps, power on the physical machine, which loads the boot file from the uniquely identified remote storage volume, completing the remote volume boot process.

[0018] The Smart NIC creates a hot-swappable network / storage device, modifies the PCI Broadband (PCI PF) configuration space based on the required device type, and dynamically adds or removes PCI PF devices from the physical machine, thereby achieving elastic expansion of the bare metal server. The cloud platform initiates a request to mount the elastic network card / block storage to the bare metal instance. The request should include the unique MAC identifier of the elastic network card and the unique UUID identifier of the block storage. After the cloud platform service is associated with the PF device, the kernel driver of the corresponding device type is loaded in the bare metal server, which can discover and use the device to complete the elastic expansion of the bare metal server.

[0019] Preferably, Smart NIC A manages bare metal network devices and connects to VPC network services, internally running the virtual switch OpenvSwitch and network device simulation services net-controller, Neutron-OpenvSwitch-Agent, etc.; Smart NIC B manages bare metal storage devices and connects to EBS cloud disk services, internally running the storage component SPDK and storage device simulation service snap, etc.

[0020] Preferably, if the created PF device is a static device, the physical machine is booted from the local disk. Generally, the driver type of the static PF device is NVME. The physical machine can automatically load the NVME driver when the BIOS hardware starts, making the static PF device a local disk of the physical machine.

[0021] Preferably, if the created PF device is a dynamic device, the physical machine is switched to the network card PXE boot, the dynamic storage device driver can be virtio_blk or NVME, the internal PF of the smart network card provides the PXE function of the physical machine, and then in the temporary file system initrd loaded by the physical machine, the customized remote volume loading logic is executed, such as the virtio_blk virtual disk needs to load the virtio_blk and virtio_pci drivers, and then the operating system discovers the virtio_blk disk and uses it as the / dev / vda block device; modify the grub configuration, specify that the physical machine operating system control is transferred to the virtio_blk disk, and the physical machine switches the root directory to the / dev / vda disk.

[0022] Preferably, for a bare metal instance, the mount request is routed to different smart network card nodes according to the request type; if the mount request carries the unique identifier MAC of the elastic network card, the request is routed to smart network card A; if it carries the unique identifier UUID of the block storage, the request is routed to smart network card node B; according to the request, smart network card A creates a network PF device, modifies the device type to virtio_net, and then mounts the PF device on the Ovs bridge. The network agent deployed on smart network card A completes the flow table delivery and Ovs port management, and the network packet processing and forwarding are completed by OpenvSwitch; according to the request, smart network card B creates a storage PF device, modifies the device type to virtio_blk, and then the storage component deployed by smart network card B associates the remote block storage with the PF device one by one, and the network packet and storage protocol processing are completed jointly by the hardware and CPU of smart network card B.

[0023] A bare metal server implementation system based on smart network cards, including a metal server architecture module, a smart network card preparation module, a deployment module, and a cloud platform access module;

[0024] The smart network card preparation module provides a complete automated process for the metal server architecture module and smart network card preparation. The deployment module provides multiple deployment methods for the metal server architecture module. The cloud platform access module connects the smart network card-based metal server architecture module to the cloud platform service.

[0025] Preferably, the metal server architecture module is used to configure two smart network card devices for each physical machine, namely smart network card A and smart network card B. Each smart network card provides one gigabit network port and two 10 gigabit network ports, which are connected to different networks according to business needs; smart network card A manages bare metal network devices and accesses VPC network services, and runs virtual switches OpenvSwitch and network device simulation services net-controller, Neutron-OpenvSwitch-Agent, etc. internally; smart network card B manages bare metal storage devices and accesses EBS cloud disk services, and runs storage components SPDK and storage device simulation services snap, etc. internally.

[0026] Preferably, the smart network card preparation module is used to provide a complete automated process for bare metal racking and smart network card preparation:

[0027] a. Complete the physical machine installation and pre-installation of the Smart NIC;

[0028] b. Build a Preboot Execute Environment (PXE) in the environment, providing boot binary files, Grub menu, kernel, and initrd based on the Smart NIC and physical machine chip architecture.

[0029] c. Complete the Smart NIC preparation process, use the IPMI management tool to enable the Smart NIC to enter the PXE boot state, and boot into the temporary memory file system (initrd). Execute the custom init script in initrd to complete the firmware update and modify the PCI BAR parameters. Then, use OpenvSwitch to create a temporary bridge and connect it to the physical machine network device (PF, or Physical Function). (hereinafter referred to as PF) and the external network are connected to the temporary OVS bridge.

[0030] d. Continue to complete the subsequent physical machine deployment process. Since the physical machine is now connected to the external network, follow the above process to complete the PCI hardware device update of the physical machine and the bare metal node reporting environment tasks;

[0031] e. After the bare metal server node is successfully registered in the environment, the identity preparation process is complete.

[0032] Preferably, the deployment module is used to prepare remote storage in the environment. The storage backend can be ceph, iSCSI, NFS, or NVME-of. The system image is written to the remote storage volume and the unique identifier of the volume is recorded. Subsequently, the smart network card node is powered on and the remote storage volume with the unique identifier is created as an SPDK backend device. Within the smart network card node, the storage device is created according to the identifier of the backend device, and a PCI PF (Physical Function) device of a specified type is created by configuring the PCI BAR base address register. After the above steps are completed, the physical machine can be started, and the physical machine loads the startup file from the uniquely identified remote storage volume to complete the remote volume startup process.

[0033] If the created PF device is a static device, the physical machine is booted from the local disk. Generally, the driver type of the static PF device is NVME. The physical machine can automatically load the NVME driver when the BIOS hardware starts, making the static PF device a local disk of the physical machine.

[0034] If the created PF device is a dynamic device, the physical machine switches to the network card PXE boot. The dynamic storage device driver can be virtio_blk or NVME. The internal PF of the smart network card provides the PXE function of the physical machine. Then, in the temporary file system initrd loaded on the physical machine, the customized remote volume loading logic is executed. For example, the virtio_blk virtual disk needs to load the virtio_blk and virtio_pci drivers. The operating system then discovers the virtio_blk disk and uses it as the / dev / vda block device. Modify the grub configuration to specify that the physical machine operating system control is transferred to the virtio_blk disk, and the physical machine switches the root directory to the / dev / vda disk.

[0035] Preferably, the cloud platform access module is used to create hot-swappable network / storage devices for the smart network card, modify the PCI BAR configuration space according to the required device type, and dynamically add or delete PCI PF devices for the physical machine, thereby realizing elastic expansion of the bare metal server; the cloud platform initiates a request to mount the elastic network card / block storage on the bare metal instance, and the request should contain the unique identifier MAC of the elastic network card and the unique identifier UUID of the block storage; after the cloud platform service is associated with the PF device, the kernel driver of the corresponding device type is loaded in the bare metal server, and the device can be discovered and used to complete the elastic expansion of the bare metal server;

[0036] For a bare metal instance, the mount request is routed to different Smart NIC nodes based on the request type. If the mount request contains the unique identifier MAC of the elastic network card, the request is routed to Smart NIC A. If it contains the unique identifier UUID of the block storage, the request is routed to Smart NIC node B. Based on the request, Smart NIC A creates a network PF device, changes the device type to virtio_net, and then attaches the PF device to the Ovs bridge. The network agent deployed on Smart NIC A completes the flow table delivery and Ovs port management, and network packet processing and forwarding are completed by OpenvSwitch. Based on the request, Smart NIC B creates a storage PF device, changes the device type to virtio_blk, and then the storage component deployed by Smart NIC B associates the remote block storage with the PF device one by one. The network packet and storage protocol processing are completed jointly by the hardware and CPU of Smart NIC B.

[0037] Compared with the prior art, the present invention has the following beneficial effects:

[0038] The Smart NIC-based bare metal server implementation method and system proposed in this invention unify the management methods of virtual machines and physical machines on a cloud platform, making the computing resources of the cloud platform a unified computing pool. Users only need to consider their own business needs without having to consider the differences between virtual machines and physical machines.

[0039] It greatly enriches the network capabilities of bare metal servers. Based on OpenvSwitch, it provides a variety of advanced network functions for bare metal servers, such as Ovs bond, VxLAN overlay network, Ovs+Linux Contrack security group, Ovs+Linux TC hardware offload, Ovs+DPDK offload, etc. At the same time, network management of bare metal servers no longer requires the participation of L2 switches, but is placed on the Smart NIC node, avoiding many network isolation and security issues.

[0040] The bare metal server's elastic block storage interface provides on-demand capacity expansion, data security, flexible backup, and high-performance computing for physical machines. It can also connect to different storage backend types as needed, regardless of hardware differences, significantly improving the availability of bare metal servers.

[0041] Only two smart network cards are needed to meet the needs of bare metal servers with multiple network cards and storage expansion on demand. There is no need to purchase additional hardware such as 10G network cards, SATA / SSD hard drives, RAID controller cards, HBA cards, etc. This greatly reduces the cost of use and deployment difficulty, while also meeting the general needs of users. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] Figure 1 This is a diagram showing the relationship between the Smart NIC and the bare metal server.

[0043] Figure 2 Prepare flow charts for bare metal servers;

[0044] Figure 3 Start a flow chart for remote volumes on bare metal servers;

[0045] Figure 4 Flowchart for connecting bare metal servers to cloud platform services. DETAILED DESCRIPTION

[0046] In order to clearly and completely describe the objectives and technical solutions of the present invention and make the advantages more clearly understood, the embodiments of the present invention are further described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are part of the embodiments of the present invention, not all of them, and are only used to explain the embodiments of the present invention, not to limit the embodiments of the present invention. All other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the present invention.

[0047] In the description of the present invention, it should be noted that the terms "center," "middle," "upper," "lower," "left," "right," "inner," "outer," "top," "bottom," "side," "vertical," "horizontal," and the like, indicating positions or location relationships, are based on the positions or location relationships shown in the accompanying drawings and are intended only to facilitate the description of the present invention and simplify the description. They are not intended to indicate or imply that the devices or components referred to must have a specific orientation, be constructed, or operate in a specific orientation. Therefore, they should not be construed as limiting the present invention. Furthermore, the terms "one," "first," "second," "third," "fourth," "fifth," and "sixth" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0048] In the description of the present invention, it should be noted that, unless otherwise expressly specified or limited, the terms "mounted," "connected," and "connected" should be understood in a broad sense. For example, they may refer to fixed, detachable, or integral connections; mechanical or electrical connections; direct or indirect connections through an intermediate medium; and internal communication between two components. Those skilled in the art will understand the specific meanings of the above terms in the present invention based on the specific circumstances.

[0049] For the purpose of simplicity and illustration, the principles of the embodiments are described primarily with reference to examples. In the following description, many specific details are provided to provide a thorough understanding of the embodiments. However, it will be apparent to those skilled in the art that these embodiments may not be limited to these specific details in practice. In some instances, well-known methods and structures are not described in detail to avoid unnecessarily obscuring the understanding of these embodiments. In addition, all embodiments may be used in combination with each other.

[0050] See also Figures 1 to 4 The present invention provides a technical solution: a method for implementing a bare metal server based on a smart network card, comprising the following steps:

[0051] Each physical machine is configured with two Smart NICs: Smart NIC A and Smart NIC B. Each Smart NIC provides one Gigabit Ethernet port and two 10 Gigabit Ethernet ports, connecting to different networks based on business needs. Smart NIC A manages bare metal network devices and accesses VPC network services. It internally runs the virtual switch OpenvSwitch, the network device simulation service net-controller, and Neutron-OpenvSwitch-Agent. Smart NIC B manages bare metal storage devices and accesses EBS cloud disk services. It internally runs the storage component SPDK and the storage device simulation service snap.

[0052] Provides a complete automated process for bare metal racking and SmartNIC preparation:

[0053] a. Complete the physical machine installation and pre-installation of the Smart NIC;

[0054] b. Build a Preboot Execute Environment (PXE) in the environment, providing boot binary files, Grub menu, kernel, and initrd based on the Smart NIC and physical machine chip architecture.

[0055] c. Complete the Smart NIC preparation process, use the IPMI management tool to enable the Smart NIC to enter the PXE boot state, and boot into the temporary memory file system (initrd). Execute the custom init script in initrd to complete the firmware update and modify the PCI BAR parameters. Then, use OpenvSwitch to create a temporary bridge and connect it to the physical machine network device (PF, or Physical Function). (hereinafter referred to as PF) and the external network are connected to the temporary OVS bridge.

[0056] d. Continue to complete the subsequent physical machine deployment process. Since the physical machine is now connected to the external network, follow the above process to complete the PCI hardware device update of the physical machine and the bare metal node reporting environment tasks;

[0057] e. After the bare metal server node is successfully registered in the environment, the identification preparation process is completed;

[0058] Prepare remote storage in the environment. The storage backend can be Ceph, iSCSI, NFS, or NVME-of. Write the system image to the remote storage volume and record the unique identifier of the volume. Then, start the Smart NIC node and create the uniquely identified remote storage volume as an SPDK backend device. Within the Smart NIC node, create the storage device based on the backend device identifier and create a specified type of PCI PF (Physical Function) device by configuring the PCI BAR base address register. After completing the above steps, start the physical machine, which loads the startup file from the uniquely identified remote storage volume to complete the remote volume startup process. If the created PF device is a static device, let the physical machine boot from the local disk. Generally, the driver type of a static PF device is NVME. The physical machine can automatically load the NVME driver when the BIOS hardware is started, making the static PF device a local disk of the physical machine. If the created PF device is a dynamic device, the physical machine is switched to the network card PXE boot. The dynamic storage device driver can be virtio_blk or NVME. The internal PF of the smart network card provides the PXE function of the physical machine. Then, in the temporary file system initrd loaded by the physical machine, the customized remote volume loading logic is executed. For example, the virtio_blk virtual disk needs to load the virtio_blk and virtio_pci drivers. Then, the operating system discovers the virtio_blk disk and uses it as the / dev / vda block device. Modify the grub configuration to specify that the physical machine operating system control is transferred to the virtio_blk disk, and the physical machine switches the root directory to the / dev / vda disk.

[0059] The smart network card creates a hot-swappable network / storage device, modifies the PCIBAR configuration space according to the required device type, and dynamically adds or deletes PCI PF devices for the physical machine, thereby achieving elastic expansion of the bare metal server; the cloud platform initiates a request to mount the elastic network card / block storage on the bare metal instance, and the request should contain the unique identifier MAC of the elastic network card and the unique identifier UUID of the block storage; after the cloud platform service is associated with the PF device, the kernel driver of the corresponding device type is loaded in the bare metal server, and the device can be discovered and used to complete the elastic expansion of the bare metal server; for a bare metal instance, the mounting request is routed to different smart network card nodes according to the request type; if the mounting request contains the unique identifier MAC of the elastic network card, the request is routed to smart network card A; if it contains the unique identifier UUID of the block storage, the request is routed to smart network card node B; according to the request, smart network card A creates a network PF device, modifies the device type to virtio_net, and then mounts the PF device on the Ovs bridge, and the network agent deployed on smart network card A completes the delivery of the flow table and Ovs OpenvSwitch performs port management, network packet processing, and forwarding. Based on the request, SmartNIC B creates a storage PF device and changes the device type to virtio_blk. The storage component deployed on SmartNIC B then associates the remote block storage with the PF device. Network packet and storage protocol processing are performed jointly by SmartNIC B's hardware and CPU.

[0060] A bare metal server implementation system based on smart network cards, including a metal server architecture module, a smart network card preparation module, a deployment module, and a cloud platform access module;

[0061] The smart network card preparation module provides a complete automated process for the metal server architecture module and smart network card preparation. The deployment module provides multiple deployment methods for the metal server architecture module. The cloud platform access module connects the smart network card-based metal server architecture module to the cloud platform service.

[0062] The metal server architecture module is used to configure two smart network card devices for each physical machine, namely Smart Network Card A and Smart Network Card B. Each Smart Network Card provides one Gigabit network port and two 10 Gigabit network ports, which are connected to different networks according to business needs; Smart Network Card A manages bare metal network devices and accesses VPC network services, and runs the virtual switch OpenvSwitch and network device simulation services net-controller and Neutron-OpenvSwitch-Agent internally; Smart Network Card B manages bare metal storage devices and accesses EBS cloud disk services, and runs the storage component SPDK and storage device simulation service snap internally.

[0063] The SmartNIC provisioning module provides a complete automated process for bare metal racking and SmartNIC provisioning:

[0064] a. Complete the physical machine installation and pre-installation of the Smart NIC;

[0065] b. Build a Preboot Execute Environment (PXE) in the environment, providing boot binary files, Grub menu, kernel, and initrd based on the Smart NIC and physical machine chip architecture.

[0066] c. Complete the Smart NIC preparation process, use the IPMI management tool to enable the Smart NIC to enter the PXE boot state, and boot into the temporary memory file system (initrd). Execute the custom init script in initrd to complete the firmware update and modify the PCI BAR parameters. Then, use OpenvSwitch to create a temporary bridge and connect it to the physical machine network device (PF, or Physical Function). (hereinafter referred to as PF) and the external network are connected to the temporary OVS bridge.

[0067] d. Continue to complete the subsequent physical machine deployment process. Since the physical machine is now connected to the external network, follow the above process to complete the PCI hardware device update of the physical machine and the bare metal node reporting environment tasks;

[0068] e. After the bare metal server node is successfully registered in the environment, the identity preparation process is complete.

[0069] The deployment module is used to prepare remote storage in the environment. The storage backend can be Ceph, iSCSI, NFS, or NVME-of. The system image is written to the remote storage volume and the unique identifier of the volume is recorded. The Smart NIC node is then powered on and the uniquely identified remote storage volume is created as an SPDK backend device. Within the Smart NIC node, the storage device is created based on the backend device identifier and a PCI PF (Physical Function) device of the specified type is created by configuring the PCI BAR base address register. After completing the above steps, the physical machine can be powered on and load the boot file from the uniquely identified remote storage volume, completing the remote volume boot process.

[0070] If the created PF device is a static device, the physical machine is booted from the local disk. Generally, the driver type of the static PF device is NVME. The physical machine can automatically load the NVME driver when the BIOS hardware starts, making the static PF device a local disk of the physical machine.

[0071] If the created PF device is a dynamic device, the physical machine switches to the network card PXE boot. The dynamic storage device driver can be virtio_blk or NVME. The internal PF of the smart network card provides the PXE function of the physical machine. Then, in the temporary file system initrd loaded on the physical machine, the customized remote volume loading logic is executed. For example, the virtio_blk virtual disk needs to load the virtio_blk and virtio_pci drivers. The operating system then discovers the virtio_blk disk and uses it as the / dev / vda block device. Modify the grub configuration to specify that the physical machine operating system control is transferred to the virtio_blk disk, and the physical machine switches the root directory to the / dev / vda disk.

[0072] The cloud platform access module is used to create hot-swappable network / storage devices using smart network cards. It modifies the PCI Broadcast (PCI) Buffer (AR) configuration space based on the required device type, dynamically adding or removing PCI PF devices from physical machines, thereby enabling elastic expansion of bare metal servers. The cloud platform initiates a request to mount an elastic network card / block storage device on a bare metal instance. The request should include the elastic network card's unique identifier (MAC) and the block storage device's unique identifier (UUID). After the cloud platform service is associated with the PF device, it loads the kernel driver for the corresponding device type on the bare metal server, enabling discovery and use of the device, thereby completing elastic expansion of the bare metal server.

[0073] For a bare metal instance, the mount request is routed to different Smart NIC nodes based on the request type. If the mount request contains the unique identifier MAC of the elastic network card, the request is routed to Smart NIC A. If it contains the unique identifier UUID of the block storage, the request is routed to Smart NIC node B. Based on the request, Smart NIC A creates a network PF device, changes the device type to virtio_net, and then attaches the PF device to the Ovs bridge. The network agent deployed on Smart NIC A completes the flow table delivery and Ovs port management, and network packet processing and forwarding are completed by OpenvSwitch. Based on the request, Smart NIC B creates a storage PF device, changes the device type to virtio_blk, and then the storage component deployed by Smart NIC B associates the remote block storage with the PF device one by one. The network packet and storage protocol processing are completed jointly by the hardware and CPU of Smart NIC B.

[0074] While embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes, modifications, substitutions, and variations may be made to these embodiments without departing from the principles and spirit of the invention, and that the scope of the invention is defined by the appended claims and their equivalents.

Claims

1. A method for implementing a bare metal server based on an intelligent network card, characterized in that: The following steps are involved: Each physical machine is equipped with two Smart NICs: Smart NIC A and Smart NIC B. Each Smart NIC provides one Gigabit Ethernet port and two 10 Gigabit Ethernet ports, allowing connections to different networks based on business needs. Provides a complete automated process for bare metal racking and SmartNIC preparation: a. Complete the physical machine installation and pre-installation of the Smart NIC; b. Build a Preboot Execute Environment (PXE) in the environment, providing boot binary files, Grub menu, kernel, and initrd based on the Smart NIC and physical machine chip architecture. c. Complete the Smart NIC preparation process, use the IPMI management tool to enable the Smart NIC to enter the PXE boot state, and boot to the temporary memory file system initrd; Execute the custom init script in initrd to complete the firmware update and modify the PCIBAR parameters. Then, create a temporary bridge through OpenvSwitch and connect it to the physical machine network device PF (Physical Function) and the external network at the same time to the temporary OVS bridge. d. Continue to complete the subsequent physical machine deployment process. Since the physical machine is now connected to the external network, follow the above process to complete the PCI hardware device update of the physical machine and the bare metal node reporting environment tasks; e. After the bare metal server node is successfully registered in the environment, the identification preparation process is completed; Prepare remote storage in the environment, using Ceph, iSCSI, NFS, or NVME-of as the storage backend. Write the system image to the remote storage volume and record the volume's unique identifier. Then, power on the SmartNIC node and create the uniquely identified remote storage volume as an SPDK backend device. Within the SmartNIC node, create a storage device based on the backend device's identifier and create a specified type of PCIPF (Physical Function) device by configuring the PCI BAR base address register. After completing the above steps, you can start the physical machine, and the physical machine loads the startup file from the uniquely identified remote storage volume to complete the remote volume startup process; The Smart NIC creates a hot-swappable network / storage device, modifies the PCIBAR configuration space based on the required device type, and dynamically adds or removes PCIPF devices from the physical machine, thereby achieving elastic expansion of the bare metal server. The cloud platform initiates a request to mount the elastic network card / block storage to the bare metal instance. The request should include the unique MAC identifier of the elastic network card and the unique UUID identifier of the block storage. After the cloud platform service is associated with the PF device, the kernel driver of the corresponding device type is loaded in the bare metal server, which can discover and use the device, completing the elastic expansion of the bare metal server. Smart NIC A manages bare metal network devices and connects to VPC network services. It runs the virtual switch OpenvSwitch, the network device simulation service net-controller, and Neutron-OpenvSwitch-Agent. Smart NIC B manages bare metal storage devices and connects to the EBS cloud disk service. It runs the storage component SPDK and the storage device simulation service snap internally. If the created PF device is a static device, the physical machine is booted from the local disk. The driver type of the static PF device is NVME. The physical machine can automatically load the NVME driver when the BIOS hardware starts, making the static PF device a local disk of the physical machine. If the created PF device is a dynamic device, the physical machine switches to the network card PXE boot. The dynamic storage device driver can be virtio_blk or NVME. The internal PF of the smart network card provides the PXE function of the physical machine. Then, in the temporary file system initrd loaded on the physical machine, the customized remote volume loading logic is executed. The virtio_blk virtual disk needs to load the virtio_blk and virtio_pci drivers. The operating system then discovers the virtio_blk disk and uses it as the / dev / vda block device. Modify the grub configuration to specify that the physical machine operating system control is transferred to the virtio_blk disk, and the physical machine switches the root directory to the / dev / vda disk. For a bare metal instance, mount requests are routed to different SmartNIC nodes based on the request type. If the mount request contains the unique MAC address of the ENI, the request is routed to Smart NIC A. If the block storage's unique identifier UUID is present, the request is routed to Smart NIC node B. Based on the request, Smart NIC A creates a network PF device, changes the device type to virtio_net, and then attaches the PF device to the Ovs bridge. The network agent deployed on Smart NIC A completes flow table delivery and Ovs port management, while network packet processing and forwarding are performed by OpenvSwitch. Based on the request, Smart NIC B creates a storage PF device, changes the device type to virtio_blk, and then the storage component deployed on Smart NIC B associates the remote block storage with the PF device one by one. Network packet and storage protocol processing are jointly performed by the hardware and CPU of Smart NIC B.

2. A bare metal server implementation system based on a smart network card, characterized by: It includes metal server architecture module, smart network card preparation module, deployment module and cloud platform access module; The Smart NIC preparation module provides a complete automated process for the metal server architecture module and Smart NIC preparation. The deployment module provides multiple deployment methods for the metal server architecture module. The cloud platform access module connects the Smart NIC-based metal server architecture module to the cloud platform service. The metal server architecture module is used to configure two smart network card devices for each physical machine, namely smart network card A and smart network card B. Each smart network card provides one Gigabit network port and two 10 Gigabit network ports, which are connected to different networks according to business needs. Smart network card A manages bare metal network devices and accesses VPC network services. It runs the virtual switch OpenvSwitch and the network device simulation service net-controller and Neutron-OpenvSwitch-Agent internally. Smart NIC B manages bare metal storage devices and connects to the EBS cloud disk service. It runs the storage component SPDK and the storage device simulation service snap internally. The Smart NIC preparation module is used to provide a complete automated process for bare metal racking and Smart NIC preparation: a. Complete the physical machine installation and pre-installation of the Smart NIC; b. Build a Preboot Execute Environment (PXE) in the environment, providing boot binary files, Grub menu, kernel, and initrd based on the Smart NIC and physical machine chip architecture. c. Complete the Smart NIC preparation process, use the IPMI management tool to enable the Smart NIC to enter the PXE boot state, and boot to the temporary memory file system initrd; Execute the custom init script in initrd to complete the firmware update and modify the PCIBAR parameters. Then, create a temporary bridge through OpenvSwitch and connect it to the physical machine network device PF (Physical Function) and the external network at the same time to the temporary OVS bridge. d. Continue to complete the subsequent physical machine deployment process. Since the physical machine is now connected to the external network, follow the above process to complete the PCI hardware device update of the physical machine and the bare metal node reporting environment tasks; e. After the bare metal server node is successfully registered in the environment, the identification preparation process is completed; the deployment module is used to prepare remote storage in the environment. The storage backend can be ceph, iSCSI, NFS, or NVME-of, write the system image to the remote storage volume, and record the unique identifier of the volume; then the smart network card node is powered on, and the uniquely identified remote storage volume is created as an SPDKbackend device; within the smart network card node, the storage device is created according to the identifier of the backend device, and a specified type of PCIPF, namely Physical Function device, is created by configuring the PCI BAR base address register; after the above steps are completed, the physical machine can be started, and the physical machine loads the startup file from the uniquely identified remote storage volume, completing the remote volume startup process; If the created PF device is a static device, the physical machine is booted from the local disk. The driver type of the static PF device is NVME. The physical machine can automatically load the NVME driver when the BIOS hardware starts, making the static PF device a local disk of the physical machine. If the created PF device is a dynamic device, the physical machine switches to the network card PXE boot. The dynamic storage device driver can be virtio_blk or NVME. The internal PF of the smart network card provides the PXE function of the physical machine. Then, in the temporary file system initrd loaded on the physical machine, the customized remote volume loading logic is executed. The virtio_blk virtual disk needs to load the virtio_blk and virtio_pci drivers. The operating system then discovers the virtio_blk disk and uses it as the / dev / vda block device. Modify the grub configuration to specify that the physical machine operating system control is transferred to the virtio_blk disk, and the physical machine switches the root directory to the / dev / vda disk. The cloud platform access module is used to create hot-swappable network / storage devices for the smart network card, modify the PCIBAR configuration space according to the required device type, and dynamically add or delete PCIPF devices for the physical machine, thereby realizing elastic expansion of the bare metal server; the cloud platform initiates a request to mount the elastic network card / block storage on the bare metal instance, and the request should contain the unique identifier MAC of the elastic network card and the unique identifier UUID of the block storage; after the cloud platform service is associated with the PF device, the kernel driver of the corresponding device type is loaded in the bare metal server, and the device can be discovered and used to complete the elastic expansion of the bare metal server; For a bare metal instance, mount requests are routed to different SmartNIC nodes based on the request type. If the mount request contains the unique MAC address of the ENI, the request is routed to Smart NIC A. If the block storage's unique identifier UUID is present, the request is routed to Smart NIC node B. Based on the request, Smart NIC A creates a network PF device, changes the device type to virtio_net, and then attaches the PF device to the Ovs bridge. The network agent deployed on Smart NIC A completes flow table delivery and Ovs port management, while network packet processing and forwarding are performed by OpenvSwitch. Based on the request, Smart NIC B creates a storage PF device, changes the device type to virtio_blk, and then the storage component deployed on Smart NIC B associates the remote block storage with the PF device one by one. Network packet and storage protocol processing are jointly performed by the hardware and CPU of Smart NIC B.

Images