DPU-Based Bare Metal Management and Control Solution

Requirements Bare metal deployment is a method of running operating systems and applications directly on physical hardware, which provides an effective solution for high-performance computing (HPC) and large-scale data processing tasks. However, traditional bare metal deployment faces challenges such as inflexible resource management and poor resource utilization, where each bare metal server typically runs only a single application. OpenStack can effectively manage and allocate computing, storage, and network resources in data centers. Through its Ironic subproject, OpenStack manages bare metal servers. Ironic offers an API framework and task orchestration services for operations like bare metal server provisioning, power management, and rebooting. It can be deployed independently or integrated with other OpenStack services (e.g., Nova, Neutron, Glance), enabling seamless integration of bare metal servers into existing cloud platforms while delivering a unified user experience equivalent to virtual machine (VM) services. Leveraging its data processing capabilities, the DPU provides optimized support for OpenStack bare metal services and network management. The DPU enables diskless boot, hot-swappable cloud storage, and storage management for bare metal servers. Simultaneously, it offloads and integrates network configuration and protocol processing tasks within OpenStack networks. This simplifies network topology, enhances flexibility, reduces costs, and strengthens security and isolation, thereby delivering robust guarantees for OpenStack’s efficient operation and resource management. The DPU addresses the following critical requirements for efficient resource management:

In bare metal scenarios, traditional NICs cannot support remote cloud disk mounting before the host operating system boots, thus failing to enable diskless boot and requiring each bare metal server to have a local system disk; when deploying bare metal servers via PXE installation, critical information such as BMC IP addresses, usernames, and passwords must be pre-registered; furthermore, the ports and network configurations connecting bare metal servers to external switches demand prior planning, resulting in inflexibility where bare metal servers cannot be interchanged with virtual machine (VM) servers during elastic deployments, preventing unified pool management of bare metal, VM, and container resources while significantly prolonging deployment cycles—all of which can be resolved by a DPU-based solution that leverages external storage as boot disks with preconfigured image parameters to enable on-demand provisioning.
Essentially, the DPU is a dedicated processor designed to provide data-centric infrastructure virtualization services, including network, storage, security, and management functions for data centers. The DPU's specialized processing units resolve performance bottlenecks caused by generalized infrastructure virtualization. # Architecture Design

Component Offloading Strategy The Nova-compute, Cinder-volume, Neutron, and other components of OpenStack were originally deployed on the host machines of compute nodes. With the introduction of DPUs, OpenStack now requires additional operations to manage DPUs, leading to multiple system management strategies. All components installed on compute nodes, such as Nova, Cinder, and Neutron, need to be offloaded and managed directly on the DPUs. The overall architecture involves inserting DPUs into bare-metal physical servers of cloud-based products via PCIe. In OpenStack, the management components for bare-metal servers are directly offloaded and deployed from the servers to the DPUs, forming the cloud resource scheduling and management components (as illustrated in the diagram). Leveraging the data plane acceleration capabilities of FPGA or ASIC-based hardware on the DPUs, data forwarding is accelerated, and these components are unified under DPU management. Under this architecture, all computing resources and network devices are managed directly by the DPUs. OpenStack perceives the scheduled bare-metal devices as native DPU-managed resources. Control operations, such as creating or deleting bare-metal instances, are issued by OpenStack to the DPUs. The DPUs then directly manage these operations on the compute node's host machines and external storage system images for device creation or deletion.

Management Integration Plan Bare-Metal Adaptation in OpenStack: To enable bare-metal registration in OpenStack and provide an upper-layer management system with a resource view of bare-metal types, the mounting of compute, network, and storage resources must be implemented for bare-metal scenarios.

Compute Mounting Mount CPU resources from bare-metal servers to OpenStack bare-metal instances. OpenStack requests CPU resources from bare-metal nodes. Based on the request, the bare-metal nodes select an appropriate node. OpenStack then loads the selected bare-metal node's information into the instance, completing CPU allocation to the instance.

Network Mounting Create virtual NICs (Network Interface Cards) on servers and mount them to OpenStack bare-metal instances. Step 1: Create virtual NICs and Open vSwitch ports. Servers create virtual NICs based on physical or virtual network devices. Open vSwitch ports are then configured on the DPUs to enable communication with the external LAN. The virtual NICs are connected to these ports to ensure network connectivity for the bare-metal instance. Step 2: Mount virtual NICs to bare-metal instances. OpenStack retrieves virtual NIC information via the Neutron component, injects this information into the bare-metal instance, and notifies the DPU. The instance can then detect and utilize the virtual NIC, completing the mounting process.

Storage Mounting DPUs create virtual disks and mount them to OpenStack bare-metal instances. Step 1: Create virtual disks. The DPU sends a request via the storage client to the storage server to create a physical disk, retrieves basic hardware configuration details, and establishes a virtual disk using SPDK (Storage Performance Development Kit) technology. By maintaining metadata linking the virtual disk to the physical disk, the DPU ensures seamless integration. Step 2: Mount virtual disks to bare-metal instances. Substep 1: Use the Cinder component to create virtual disk metadata in OpenStack. Substep 2: OpenStack retrieves virtual disk information from the DPU via the Nova component, binding the metadata to the DPU's virtual disk. Substep 3: Inject the virtual disk information into the bare-metal instance, finalizing the mounting process

Components and Relationships The management platform includes nova-api, cinder-api, and neutron-api, while the cloud resource scheduling and management components include Nova-compute, Cinder, Neutron agent, and BM Agent.

Management Platform nova-api: Receives requests to create bare-metal instances and invokes nova-scheduler to allocate an ironic node. cinder-api: Receives requests to create/delete storage devices for bare-metal instances and schedules the creation/deletion of virtio-blk devices on the ironic node. neutron-api: Receives requests to create/delete network devices for bare-metal instances and schedules the creation/deletion of virtio-net devices on the ironic node.

Cloud Resource Scheduling and Management Components nova-compute: Uses a specified disk image to instruct Cinder to create a system disk volume. Cinder clones the image volume via snapshots (not full copies) on the backend storage, which is completed rapidly, typically within seconds. Cinder: Manages storage devices based on commands from the control node. Neutron agent: Manages network devices and handles flow table distribution for virtual switches according to control node instructions. BM Agent: Runs on the DPU SoC and communicates with ironic-conductor via RPC. It manages storage and network resources for bare-metal instances on the local node. During deployment, it receives deployment commands from ironic-conductor, connects cloud disks within the DPU, and mounts them to the host. During runtime, it dynamically adds or removes disks/NICs for the host based on commands from ironic-conductor.