Multi-tenant intelligent computing center computing power server lease order agile algorithm

Abstract

The application discloses a computing power server leasing order agile algorithm under a multi-tenant intelligent computing center. The server is brought into a ready state through pre-deployment. After a tenant places an order, a ready server is matched and locked. Delivery is completed through SDN network configuration and permission injection. The server is automatically recycled and reset at the end of the lease period. The core lies in pre-installation and full-process automation, which solves the problem of long delivery time of traditional bare machines, realizes order placement and delivery, guarantees multi-tenant isolation safety, improves resource utilization and user convenience, and is suitable for the computing power leasing scene of the multi-tenant intelligent computing center.

Description

Technical Field

[0001] This invention belongs to the field of cloud computing and data center resource management technology, specifically involving an agile algorithm for computing server leasing orders in a multi-tenant intelligent computing center. Background Technology

[0002] In bare-metal server leasing services for multi-tenant intelligent computing centers, the core problem with existing technologies is the excessively long delivery cycle, making it difficult to meet tenants' immediate computing power needs. Traditional bare-metal server deployment, relying on manual operations, can take days or even weeks to complete configuration. Even with automated tools like OpenStack Ironic, the deployment cycle still takes approximately 45 minutes, a significant gap compared to the second-level agility of virtual machine startup. This lengthy delivery process prevents tenants from meeting their needs in scenarios such as emergency expansion or temporary use of high-performance physical machines, severely impacting business efficiency. Furthermore, existing solutions lack pre-deployment and real-time matching mechanisms; a complete installation process is still required after an order is placed, further extending delivery time.

[0003] Therefore, there is an urgent need for a technical solution that can enable rapid delivery of bare-metal servers to address the pain points of traditional deployments being time-consuming and unresponsive. Summary of the Invention

[0004] The purpose of this invention is to overcome the shortcomings of existing technologies and proposes an agile algorithm for computing server leasing orders in multi-tenant intelligent computing centers, comprising the following steps: S1. The administrator performs pre-deployment on the newly launched physical server through the deployment orchestration system, completes hardware information collection, basic operating system image installation, and internal network IP configuration, so that the server enters the ready state and is added to the bare metal resource pool; S2. After a tenant submits a rental order through the tenant portal, the rental order management module matches and locks ready servers that meet the order specifications from the bare metal resource pool. The S3.SDN network management module assigns public IP addresses to the matched servers, configures QoS policies for the agreed bandwidth of the order, and sets firewall ACL rules for the service ports specified in the order. S4. Configure tenant login credentials and permissions, and switch the server to a delivered state for tenant use; S5. When the lease term ends or the tenant voluntarily terminates the lease, the system sequentially performs public network resource reclamation, tenant permission revocation, server data erasure and base image reinstallation, and the server is restored to the ready state and returned to the bare metal resource pool.

[0005] Preferably, in step 1, the pre-deployment uses multicast technology to distribute the base operating system image. After deployment, the new system kernel is loaded using kexec technology. The base operating system image contains commonly used drivers and management agent software. The pre-deployment process also includes setting up a security baseline.

[0006] More preferably, the SDN network management module achieves tenant network isolation by configuring VLAN or VXLAN, and the order-specified service port includes port 22 for SSH, port 80 for HTTP and port 443 for HTTPS, and the public IP adopts a tenant-specific binding mechanism.

[0007] Preferably, the tenant login credentials include an initial login username, password, or SSH public key. After configuration, the system pushes the public IP address and login credentials through the tenant portal, and the total configuration operation takes no more than 10 seconds.

[0008] In a further preferred embodiment, when a tenant initiates a one-click reinstallation request through the tenant portal during the lease period, the installation and deployment module obtains the operating system version specified by the tenant from the image repository and performs automatic reinstallation through the LiveOS environment. The reinstallation process adopts kexec hot start technology, which requires no manual intervention.

[0009] More preferably, the data erasure operation overwrites the tenant's retained data by reinstalling the base operating system image, restores the server's factory-set partition configuration and boot program, and uses a three-stage overwrite method for the storage medium. After the reset, the server hardware information is consistent with that when the pre-deployment was completed.

[0010] More preferably, the deployment orchestration system controls the server power supply and boot process through the IPMI or iDRAC out-of-band management interface. The management agent installed in the pre-deployment phase enables real-time communication between the server and the bare metal resource pool management module, synchronizing hardware health status, network connection status and system operating status.

[0011] More preferably, the server status monitored by the bare metal resource pool management module includes four types: idle, ready, allocated, and being reclaimed. The order specifications include the number of CPU cores, memory capacity, storage specifications, and GPU configuration. When matching orders, only servers in the ready state and whose hardware specifications match the order specifications are selected.

[0012] More preferably, when multiple servers are deployed simultaneously, the multicast technology sends only one image data packet, which is received in parallel by all servers to be deployed. The image reception and writing time of a single server does not exceed 3 minutes, and the network bandwidth usage is reduced by 60% compared with the traditional unicast deployment method, and the deployment efficiency is 4 times that of the traditional unicast deployment method.

[0013] In a further preferred embodiment, the system includes a monitoring and logging module that records key nodes in the server installation process, the status change trajectory of rental orders, details of tenant operation behavior, and resource recycling process logs, generates audit logs and rental transaction logs, monitors server CPU utilization, memory usage, network throughput, and disk I / O through Telegraf, with a heartbeat detection interval of 30 seconds, triggering alarms and recording fault information in abnormal states. Attached Figure Description

[0014] Figure 1 This is a flowchart of the agile algorithm for the rental order of computing power servers under the multi-tenant intelligent computing center in this application; Figure 2 This is a diagram of the agile system component architecture for the computing server leasing order under the multi-tenant intelligent computing center in this application; Figure 3 This is a timeline diagram of the entire lifecycle of the bare metal leased by the user of this application. Detailed Implementation

[0015] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0016] Traditional technical solutions have the following technical problems: the deployment and delivery process of bare metal servers is delayed, and the installation only starts after the order is placed, resulting in a long delivery cycle and inability to meet the demand for real-time computing power.

[0017] Based on this, please refer to Figure 1-3 This invention provides an agile algorithm for computing server leasing orders in a multi-tenant intelligent computing center, including: S1. The administrator performs pre-deployment on the newly launched physical server through the deployment orchestration system, completes hardware information collection, basic operating system image installation, and internal network IP configuration, so that the server enters the ready state and is added to the bare metal resource pool; S2. After a tenant submits a rental order through the tenant portal, the rental order management module matches and locks ready servers that meet the order specifications from the bare metal resource pool. The S3.SDN network management module assigns public IP addresses to the matched servers, configures QoS policies for the agreed bandwidth of the order, and sets firewall ACL rules for the service ports specified in the order. S4. Configure tenant login credentials and permissions, and switch the server to a delivered state for tenant use; S5. When the lease term ends or the tenant voluntarily terminates the lease, the system sequentially performs public network resource reclamation, tenant permission revocation, server data erasure and base image reinstallation, and the server is restored to the ready state and returned to the bare metal resource pool.

[0018] The core innovation of this solution lies in reconstructing the rental timeline logic, moving the traditional post-order installation process to pre-deployment, completely changing the core paradigm of bare-metal delivery. The pre-deployment phase is administrator-led. The deployment orchestration system obtains complete server hardware information through out-of-band management interfaces, including key parameters such as CPU model, number of cores, memory capacity, storage media type and capacity, and interface configuration, ensuring accurate understanding of the server's computing power. The basic operating system image is deployed through an automated installation process, supporting both PXE network booting and virtual media mounting to adapt to different hardware environments. Hardware drivers are automatically installed during image installation to ensure device compatibility. Internal network IPs are statically assigned according to the intelligent computing center's preset network segments, with each server assigned a unique internal network address to ensure stable communication with the management platform. Servers in the ready state only connect to the internal management network, do not provide any external services, and are not associated with any tenant information, remaining in a standby state. After a tenant submits an order, the rental order management module first parses the order specifications, then iterates through the ready servers in the bare metal resource pool, filtering them based on a perfect hardware specification match. Simultaneously, it uses a resource load balancing strategy to select and lock the server with the lowest current utilization rate, preventing multiple orders from competing for the same resource. The SDN network management module, based on software-defined networking technology, allocates unused IPs from the public IP address pool and binds them to the server's network interface card (NIC). It configures a rate-limiting QoS policy according to the bandwidth value agreed upon in the order, ensuring stable network transmission speeds for the tenant. It also generates an ACL (Access Control List) based on the service port specified in the order, allowing only legitimate access traffic. Tenant login credentials and permission configuration are executed via encrypted automated scripts to prevent data leakage during configuration. Once configuration is complete, the server status is immediately switched to "delivered," allowing immediate access for the tenant. The recycling phase strictly follows a fixed process: public network resource recycling ensures the release and reuse of IP addresses and bandwidth resources; permission revocation blocks subsequent unauthorized access by the tenant; and data erasure and base image reinstallation ensure the server returns to its initial clean state, achieving cyclical utilization.

[0019] The technical benefits include significantly shortening delivery time, enabling immediate delivery upon order placement, and ensuring secure isolation and efficient resource utilization for multi-tenants.

[0020] Traditional technical solutions have the following technical problems: low pre-deployment efficiency, high network overhead due to unicast image distribution, and long restart time after deployment.

[0021] Based on this, in step 1, the pre-deployment uses multicast technology to distribute the base operating system image. After deployment, the new system kernel is loaded using kexec technology. The base operating system image contains commonly used drivers and management agent software. The pre-deployment process also includes setting up a security baseline.

[0022] The application of multicast technology adopts a one-to-many transmission architecture. During the pre-deployment phase, the deployment orchestration system creates a dedicated multicast group, setting a fixed multicast address and port. All servers to be deployed automatically join this multicast group upon startup. The deployment orchestration system only needs to generate and send one basic operating system image data packet, which can be received in parallel by all servers within the group. There is no need to establish a separate transmission link for each server. Image transmission uses the UDP protocol to ensure transmission efficiency, while a data verification mechanism ensures image integrity. The execution flow of kexec technology is as follows: After the basic operating system image is installed, the deployment orchestration system sends a kexec loading command to the server through the management agent. The server kernel first loads the newly installed system kernel image and initramfs file into the specified memory address, then configures the kernel boot parameters, including the root file system path and network card configuration parameters. Finally, it executes the kexec -e command to directly jump to the new kernel, skipping the traditional BIOS self-test and hardware initialization process, significantly shortening system startup time. The entire switching process takes only a few seconds. The base operating system image pre-integrates drivers for common hardware in the intelligent computing center, covering mainstream CPUs, motherboards, network cards, storage controllers, and other devices, ensuring the hardware functions correctly after server deployment. It also includes lightweight management agent software that runs as a background service, supporting bidirectional communication with the bare-metal resource pool management module. This agent can report server status in real time and receive control commands. The security baseline settings include multiple security configurations. For account security, the default administrator account is disabled, a unique system management account is created with a strong password (at least 12 characters long, including uppercase and lowercase letters, numbers, and special characters), and the password validity period is 90 days. For system access control, unnecessary system services are disabled, such as plaintext transmission services like FTP and Telnet, and the use of the `su` command is restricted, allowing only designated accounts to switch to root privileges. For network security, all unused ports are closed, the firewall is configured to block all inbound connections by default, only opening internal network ports necessary for communication with the management platform, and system log auditing is enabled to record all user logins and critical operations.

[0023] The technical benefits include improved pre-deployment efficiency, reduced network overhead, and enhanced security and manageability of pre-deployed servers.

[0024] Traditional technical solutions have the following technical problems: incomplete isolation of multi-tenant networks, lack of clear specifications for service port opening, and chaotic allocation of public IP addresses.

[0025] Based on this, the SDN network management module achieves tenant network isolation by configuring VLAN or VXLAN. The service ports specified in the order include port 22 for SSH, port 80 for HTTP, and port 443 for HTTPS. The public IP adopts a tenant-specific binding mechanism.

[0026] The configuration process for VLAN network isolation involves establishing a linkage between the SDN controller and the data center core switches and access switches, assigning a unique VLAN ID to each tenant (ranging from 100 to 1000 and ensuring no repetition), assigning the tenant's leased server ports to the corresponding VLANs, and configuring inter-VLAN routing isolation to ensure that network traffic within different VLANs cannot communicate directly. VXLAN network isolation uses tunnel encapsulation technology to encapsulate the tenant's Ethernet data frames in UDP packets for transmission over the physical network. The tunnel endpoints are dynamically assigned IP addresses by the SDN controller, and each tenant corresponds to an independent VXLAN tunnel. Tenant traffic is transmitted only within its own tunnel and is completely isolated from other tenant tunnels, adapting to the network isolation requirements of large-scale multi-tenant scenarios. Each service port specified in the order has a specific purpose. Port 22 for SSH is used for tenants to remotely log in to the server for management operations. During configuration, SSH protocol version 2 is forcibly enabled, while version 1 is disabled to improve security. Password login is also disabled, allowing only login via SSH public key authentication to avoid the risk of password leakage. Port 80 for HTTP is used to provide unencrypted web service access, and port 443 for HTTPS is used to provide encrypted web service access. During configuration, an SSL certificate is bound to port 443. The certificate is generated using the 2048-bit RSA algorithm to ensure the encryption security of data transmission. Ports not specified in the order are all set to deny access through firewall rules to block unauthorized intrusion at the port level. The public IP address binding mechanism employs a tiered public IP address pool, divided into a regular tenant address pool and a premium tenant address pool based on tenant type. All IP addresses in each pool are registered with the ISP and are available. After a lease order is submitted, the SDN controller selects an unused public IP address from the corresponding address pool and binds it to the tenant's leased server's internal IP address using NAT technology. This binding is only valid during the lease period. After the lease expires, the SDN controller immediately unbinds the public IP address and returns it to the address pool for subsequent allocation. Simultaneously, it records IP address usage logs, including allocation time, tenant information, and reclamation time, facilitating network auditing and traceability.

[0027] The technical effect is to achieve deep isolation in multi-tenant networks, reduce security risks, and ensure the orderly allocation of network resources.

[0028] Traditional technical solutions suffer from the following technical problems: unclear tenant login credentials, untimely information push after configuration, and no clear control over delivery time.

[0029] Based on this, tenant login credentials include the initial login username and password or SSH public key. After configuration, the system pushes the public IP address and login credentials through the tenant portal. The total configuration operation time does not exceed [a certain amount]. Second.

[0030] The initial login username is automatically generated using a combination of tenant unique identifier and server number. The tenant unique identifier is assigned by the system during tenant registration and is an 8-digit alphanumeric combination. The server number is a unique serial number in the bare metal resource pool, ensuring that the initial login username is globally unique throughout the entire intelligent computing center, which facilitates system identification and management.

[0031] Password generation uses a random string generation algorithm with a fixed length of 12 characters. The character set includes uppercase letters A, Z, lowercase letters A, Z, numbers 0-9, and special characters !@#$%^&*. The generated password is stored in the system database using the AES-256 encryption algorithm and is only decrypted and displayed to the tenant upon push notification. Tenants are required to change their password upon their first login; otherwise, they cannot perform other operations. SSH public keys can be uploaded by the tenant themselves through the key management function in the tenant portal. The system automatically verifies the public key format and only supports public keys generated using RSA or ED25519 encryption algorithms. After successful verification, an automated script writes the public key content to the ` / root / .ssh / authorized_keys` file on the server, configuring public key login permissions to ensure that tenants can log in without a password using their private key. Once configured, information is pushed via a multi-channel synchronization mechanism. The tenant portal instantly displays a pop-up notification showing the initial login username and password (or SSH public key) for the public IP address. Simultaneously, reminder SMS messages and emails containing the same connection information are sent to the tenant's registered mobile phone number and email address to ensure timely access. The "My Orders" page updates the order status to "delivered" in real time and permanently retains the connection information for future tenant inquiries. The total configuration operation time is strictly controlled within [a specified timeframe]. Within seconds, this time consists of multiple steps, with the public IP address allocation step taking no more than [a certain amount of time]. The firewall ACL rule configuration process takes no more than [number] seconds. The login credential injection process takes no more than seconds. The time taken for server status switching and information push is no more than seconds. Within seconds, all steps are executed in parallel or sequentially via automated scripts, without human intervention, ensuring immediate delivery.

[0032] The technical benefits include improved ease of use for tenants, clear delivery time standards, and guaranteed timely access.

[0033] Traditional technical solutions suffer from the following problems: tenant system reinstallation requires manual intervention, which is cumbersome and time-consuming. To address this, when a tenant initiates a one-click reinstallation request through the tenant portal during the lease period, the installation and deployment module retrieves the tenant's specified operating system version from the image repository and performs an automatic reinstallation through the LiveOS environment. The reinstallation process uses kexec hot-start technology, eliminating the need for manual intervention. The process for tenants to initiate a reinstallation request is simple and efficient. After logging into the tenant portal, the tenant goes to the "My Servers" management page, selects the server to be reinstalled, and clicks the "One-Click Reinstallation" button. The system displays a list of operating system versions, including mainstream versions such as CentOS 7, CentOS 8, Ubuntu 20.04, Ubuntu 22.04, Windows Server 2019, and Windows Server 2022, as well as customized versions for the intelligent computing center. After selecting the target version, the tenant submits the request. The entire operation requires no additional parameters and no contact with maintenance personnel. The image repository is deployed using a distributed architecture, located within the intelligent computing center's intranet. Image files are stored categorized by operating system type and version. Each image file undergoes integrity verification and security checks to ensure it is free of malicious programs and vulnerabilities. The image repository supports caching acceleration, caching frequently used image files to edge nodes to reduce cross-network segment transmission time. Upon receiving a reinstallation request, the installation and deployment module retrieves the target operating system image from the image repository via the intranet's high-speed network, achieving transmission rates exceeding 1Gbps. LiveOS, as a temporary micro-operating system, boots via PXE network boot or virtual media mounting, loading into server memory and running without occupying local disk space. After startup, it automatically initializes the network card configuration, obtains the intranet IP address, discovers the installation and deployment module via multicast technology, acquires reinstallation parameters, including image address partitioning scheme installation parameters, and then launches the bare-metal internal agent program to execute the reinstallation operation. The kexec hot boot technology application process during the reinstallation is as follows: After receiving the image file, the bare-metal internal agent first writes the image to the server's local disk, completes the formatting and image installation of the system partition and data partition according to the predefined partitioning scheme. After installation, the agent calls the kexec tool to load the kernel image and initramfs file of the newly installed system into memory, configures the kernel boot parameters, including the root partition path and network card configuration, and then executes the kexec -e command to directly jump from the current LiveOS environment to the new system kernel without restarting the server, skipping the BIOS self-test and hardware initialization process, which greatly shortens the reinstallation time. The entire reinstallation process takes no more than 5 minutes and requires no manual intervention. Tenants can view the reinstallation progress in real time through the portal.

[0034] The technical benefits include enabling tenants to quickly and independently reinstall the system, reducing manual intervention and improving usability.

[0035] Traditional technical solutions have the following technical problems: data cleanup is not thorough after tenants terminate their leases, and server configuration cannot be restored to its initial state, affecting subsequent tenants' use.

[0036] Based on this, the data erasure operation overwrites the tenant's retained data by reinstalling the base operating system image, restores the server's factory-set partition configuration and boot program, and uses a three-stage overwrite method for the storage media. After the reset, the server hardware information is consistent with that when the pre-deployment was completed.

[0037] Data erasure employs a three-tiered progressive operation. The first tier involves system image overwriting, reinstalling the standard base operating system image used during the pre-deployment phase. This image is identical to the system image used by the tenant during its operation. During installation, the system partition and all data partitions are automatically overwritten, ensuring that the tenant's stored business data, configuration files, log files, etc., are completely overwritten without any residue. The second tier involves storage media sector overwriting, directly manipulating the storage media through low-level disk tools, skipping the file system, and performing three overwrites on all sectors. The first overwrite uses 00 binary data, the second uses FF binary data, and the third uses randomly generated binary data. Each overwrite completely covers every sector of the storage media, ensuring that the original data cannot be retrieved even through data recovery techniques. The third tier involves partition table and bootloader cleanup, deleting the original partition table information and recreating the partition table according to the standard partitioning scheme used during the pre-deployment phase. The system partition capacity is fixed at 500GB, with the file system being ext4 or NTFS. The data partition occupies the remaining storage capacity. At the same time, the default bootloader GRUB2 is restored, and the boot configuration file is reset to ensure that the server startup process conforms to the standard. The factory reset configuration process also includes resetting system parameters, restoring the operating system's network configuration, account configuration, and service configuration to the default state of the base image, deleting additional accounts and permission configurations created by tenants, and disabling unnecessary services enabled by tenants to ensure that the server configuration is completely consistent with that at the time of pre-deployment. The post-reset verification process is rigorous. The system automatically compares the server's current hardware information, including CPU model, number of cores, memory capacity, and storage media type and capacity, with the hardware information recorded during the pre-deployment phase to ensure no hardware changes have occurred; verifies that the operating system version, kernel version, and driver version conform to the base image standard; tests whether the intranet communication between the server and the management platform is normal, and whether the management agent can report status and receive instructions normally; finally, a security scan is performed to detect residual data and security vulnerabilities. Only after all verification items pass is the server restored to a ready state and returned to the bare metal resource pool.

[0038] The technical effect is to thoroughly clean up tenant data, restore the server to its initial state, and ensure the security and environmental consistency of subsequent tenant use.

[0039] Traditional technical solutions have the following technical problems: the deployment orchestration system cannot effectively control the server power and boot process, communication between the pre-deployed server and the management system is not smooth, and the status cannot be synchronized.

[0040] Based on this, the deployment orchestration system controls the server power and boot process through the IPMI or iDRAC out-of-band management interface. The management agent installed in the pre-deployment phase enables real-time communication between the server and the bare metal resource pool management module, synchronizing hardware health status, network connection status and system operation status.

[0041] The configuration and application process of the IPMI out-of-band management interface is as follows: During the pre-deployment phase, the server's BMC address, login username, and password are entered into the deployment orchestration system. The deployment orchestration system communicates with the BMC via the IPMI protocol, sending power control commands, including power-on, power-off, and restart commands, regardless of whether the server is currently powered on. When the server needs to perform pre-deployment or reset operations, the server's boot order is configured via the IPMI interface, setting it to prioritize network boot to ensure the server can load the LiveOS environment from the network and perform related operations. In addition to supporting power control and boot order configuration, the iDRAC out-of-band management interface can also acquire real-time server hardware health data, including CPU temperature, fan speed, memory voltage, power module status, and SMART information from the storage medium. The deployment orchestration system collects this data through the iDRAC interface to determine if the server hardware is functioning correctly. If a hardware failure is detected, the server status is promptly marked as abnormal to prevent it from being assigned to tenants. The management agent, acting as a bridge between the server and the management system, is developed in Go and features low system resource consumption, stable operation, and high communication efficiency. Installed on the server's base operating system, it starts automatically as a system service. It establishes a long-lived connection with the bare-metal resource pool management module via HTTP, and communication data is encrypted using TLS to ensure secure transmission. The core functions of the management agent include status reporting and command reception. For status reporting, it reports hardware health, network connectivity, and system operating status at 30-second intervals, triggering real-time reporting immediately when abnormal changes occur. For command reception, it supports receiving control commands sent by the bare-metal resource pool management module, such as status query commands, configuration modification commands, and reinstallation trigger commands. Upon receiving a command, it executes the corresponding operation as required and returns the execution result.

[0042] The technical benefits include enabling remote control of the server, ensuring real-time communication between the management system and the server, and improving the accuracy of operation and maintenance management.

[0043] Traditional technical solutions have the following technical problems: incomplete server status monitoring, inaccurate specification filtering during order matching, and easy resource mismatch.

[0044] Based on this, the bare metal resource pool management module monitors four server statuses: idle, ready, allocated, and being reclaimed. Order specifications include the number of CPU cores, memory capacity, storage specifications, and GPU configuration. When matching orders, only servers in the ready state and with hardware specifications that match the order specifications are selected.

[0045] The definitions and switching logic for the four server states are clear and explicit. The idle state indicates the server has completed rack deployment but has not yet undergone pre-deployment; hardware information has been entered into the system but the operating system has not been installed. The ready state indicates the server has completed pre-deployment, has installed a basic operating system, configured an internal IP address and management agent, and is ready to respond to order matching at any time. The allocated state indicates the server has been locked by an order and is undergoing delivery configuration operations but has not yet been delivered to the tenant. The recycling state indicates the server has been returned to the lease and is undergoing public network resource recycling, data erasure, image reinstallation, and other reset operations, but has not yet returned to the ready state. State switching is automatically triggered by the bare metal resource pool management module according to process nodes. The idle state switches to the ready state after pre-deployment; the ready state switches to the allocated state after order locking; the allocated state switches to the delivered state after delivery completion; the delivered state enters the recycling state after lease return triggering; and returns to the ready state after reset. Each state switch is recorded with a timestamp and operation log for easy traceability. The core parameters of the order specifications are clearly defined. CPU core count is categorized by physical core count, including options such as 8, 16, 32, and 64 cores. Memory capacity is measured in GB, including options such as 32GB, 64GB, 128GB, and 256GB. Storage specifications include storage media type and capacity. GPU configurations include options such as no GPU, Tesla V1001, Tesla V1002, A1001, and A1002. The order matching logic employs a dual-screening mechanism. The first screen selects only servers in the "ready" state, excluding idle servers that have been allocated or are being reclaimed. The second screen filters hardware specifications. The rental order management module parses the specification parameters in the order and compares them one by one with the hardware information of the ready servers. It requires that the number of CPU cores, memory capacity, storage media type and capacity, and GPU model and quantity be completely identical; mismatches are not allowed. If multiple servers meet the criteria, they are sorted in descending order of resource utilization, and the server with the highest utilization is locked to ensure balanced resource utilization.

[0046] The technical effect is to avoid resource mismatch, improve the accuracy of order matching, and ensure that tenants obtain the expected computing power resources.

[0047] Traditional technical solutions suffer from the following technical problems: the application of multicast technology is unclear, there are no specific standards for improving deployment efficiency, and the optimization effect of network bandwidth usage is unclear.

[0048] Based on this, multicast technology sends only one image data packet when deploying multiple servers simultaneously, and all servers to be deployed receive it in parallel. The image reception and writing time for a single server does not exceed [a certain value]. The network bandwidth usage is reduced by minutes compared to traditional unicast deployment methods. The deployment efficiency is that of traditional unicast deployment methods. The multicast technology implementation architecture consists of three parts: a multicast source, a multicast group, and a receiver. The multicast source is the multicast server in the deployment orchestration system, responsible for generating and sending the basic operating system image data packets using the UDP protocol. A reasonable timeout and retransmission mechanism is set during transmission to ensure no data packets are lost. The multicast group is pre-created by the deployment orchestration system, assigned a fixed multicast IP address and port number, and is only enabled during pre-deployment and disabled after deployment. The receiver is the server to be deployed. After the server starts, it enters the initial boot environment via PXE and automatically joins the preset multicast group to receive the image data packets sent by the multicast source. The core difference between multicast deployment and traditional unicast deployment lies in the data transmission method. In traditional unicast deployment, the multicast source needs to establish a separate transmission link for each server to be deployed and send a complete image data packet. If deployed simultaneously... Taiwan server, needs to transmit One mirrored data packet; during multicast deployment, the multicast source sends only one mirrored data packet, and all... All servers to be deployed can receive data in parallel, and the network bandwidth usage is only a fraction of that of unicast deployment. ,when At the same time, network bandwidth usage is significantly reduced. Actual testing showed that when deploying 10 servers simultaneously, network bandwidth usage was significantly reduced compared to unicast deployment. The deployment efficiency quantification is clear: the time for receiving and writing an image on a single server, from the start of receiving the image data packet to the end of writing the image completely to the local disk, should not exceed [a certain value]. Minutes, mainly due to the high efficiency of multicast transmission and the high-speed write capability of local disks; simultaneous deployment The total time taken by deploying multiple servers is roughly the same as the time taken by deploying a single server, whereas traditional unicast deployment... The total time taken by the servers is the time taken by deploying a single server. Therefore, multicast deployment efficiency is several times that of traditional unicast deployment. times, when At that time, deployment efficiency reached This is twice as fast, fully meeting the needs of large-scale bare-metal parallel pre-deployment.

[0049] The technical effects are clearly demonstrated by the application of multicast technology, which significantly improves the efficiency of parallel deployment of multiple servers and significantly reduces network overhead.

[0050] Traditional technical solutions have the following technical problems: the system lacks comprehensive monitoring and logging, faults cannot be alarmed in a timely manner, and there is no traceability basis for operations.

[0051] Based on this, the system includes a monitoring and logging module, which records key nodes in the server installation process, changes in rental order status, details of tenant operations, and logs of resource reclamation processes. It generates audit logs and rental transaction logs, and monitors server CPU utilization, memory usage, network throughput, and disk I / O via Telegraf. The heartbeat detection interval is [missing information]. The system triggers alarms and records fault information in seconds during abnormal states. The monitoring module uses Telegraf as its core data collection component. By deploying a Telegraf proxy on each server and configuring targeted data collection plugins, it achieves accurate collection of core metrics. The CPU utilization data collection plugin is set to... The CPU cores' instantaneous and average utilization rates are collected at second intervals, recording peak and trough values. The memory utilization rate plugin collects the size of used memory, free memory, cache memory, and buffer memory, calculating memory utilization. The network throughput plugin collects inbound and outbound traffic from the server's internal and public network cards, in Mbps, while also recording network latency and packet loss rate. The disk I / O plugin collects disk read rate, write rate, number of read operations, and number of write operations, in MB / s and times / second, respectively. All collected data is transmitted in real time to a background time-series database for storage, with a storage period of 90 days, supporting historical data query and trend analysis. The log module adopts a distributed log collection architecture. By deploying log collection agents in each module, it collects real-time log information for the entire process. Key nodes in the installation process logs record crucial time points and execution results, such as the start and completion times of hardware information collection, the start and completion times of image installation, and the time of readiness status marking. The rental order status change trajectory log records the time and triggering conditions for status changes such as order submission, resource locking, delivery completion, lease start, lease end, and recycling start and completion. Tenant operation behavior detail logs record the time, operator, operation parameters, and execution results of actions such as tenant order submission, reinstallation requests, public network resource adjustments, and lease termination. The resource recycling process log records the execution status of each step, including public network IP, recycling permissions revocation, data erasure, and reset completion. Audit logs are categorized by operation subject into administrator operation audit logs and tenant operation audit logs, recording information such as operator, operation time, operation content, operation results, and client IP, for security auditing and accountability. The rental transaction log links all relevant operation records by order number, forming a complete order lifecycle log chain for easy querying of the entire order process information. The alarm mechanism is triggered based on monitoring indicator thresholds and abnormal log events. Preset alarm thresholds include CPU utilization ≥90% for 5 minutes, memory usage ≥90% for 5 minutes, network interruption for more than 1 minute, disk I / O read / write errors, and management agent heartbeat loss for more than 2 intervals. When a monitoring indicator reaches the threshold or an abnormal event appears in the log, the system immediately triggers an alarm and notifies the operation and maintenance personnel via SMS and email. The alarm information includes key information such as the faulty server ID, fault type, fault time, current status, and alarm level. At the same time, the log module records the alarm details and subsequent processing results to ensure timely response and handling of faults.

[0052] The technical benefits include enabling full-process monitoring and operation traceability of the system, timely detection and handling of faults, and improved operational reliability and security.

[0053] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention in any other way. Any person skilled in the art may make changes or modifications to the above-disclosed technical content to create equivalent embodiments that can be applied to other fields. However, any simple modifications, equivalent changes, and modifications made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the protection scope of the present invention.

Claims

1. An agile algorithm for computing server leasing orders in a multi-tenant intelligent computing center, characterized in that: Includes the following steps: S1. The administrator performs pre-deployment on the newly launched physical server through the deployment orchestration system, completes hardware information collection, basic operating system image installation, and internal network IP configuration, so that the server enters the ready state and is added to the bare metal resource pool; S2. After a tenant submits a rental order through the tenant portal, the rental order management module matches and locks ready servers that meet the order specifications from the bare metal resource pool. The S3.SDN network management module assigns public IP addresses to the matched servers, configures QoS policies for the agreed bandwidth of the order, and sets firewall ACL rules for the service ports specified in the order. S4. Configure tenant login credentials and permissions, and switch the server to a delivered state for tenant use; S5. When the lease term ends or the tenant voluntarily terminates the lease, the system sequentially performs public network resource reclamation, tenant permission revocation, server data erasure and base image reinstallation, and the server is restored to the ready state and returned to the bare metal resource pool.

2. The agile algorithm for computing server leasing orders in a multi-tenant intelligent computing center according to claim 1, characterized in that, In step 1, the pre-deployment uses multicast technology to distribute the base operating system image. After deployment, the new system kernel is loaded using kexec technology. The base operating system image contains commonly used drivers and management agent software. The pre-deployment process also includes setting up a security baseline.

3. The agile algorithm for computing server leasing orders in a multi-tenant intelligent computing center according to claim 1, characterized in that, The SDN network management module achieves tenant network isolation by configuring VLAN or VXLAN. The designated service ports for the order include port 22 for SSH, port 80 for HTTP, and port 443 for HTTPS. The public IP adopts a tenant-specific binding mechanism.

4. The agile algorithm for computing server leasing orders in a multi-tenant intelligent computing center according to claim 1, characterized in that, The tenant login credentials include the initial login username, password or SSH public key. After configuration, the system pushes the public IP and login credentials through the tenant portal. The total configuration time does not exceed 10 seconds.

5. The agile algorithm for computing server leasing orders in a multi-tenant intelligent computing center according to claim 1, characterized in that, During the lease term, when a tenant initiates a one-click reinstallation request through the tenant portal, the installation and deployment module obtains the operating system version specified by the tenant from the image repository and performs automatic reinstallation through the LiveOS environment. The reinstallation process uses kexec hot start technology, which does not require manual intervention.

6. The agile algorithm for computing server leasing orders in a multi-tenant intelligent computing center according to claim 1, characterized in that, The data erasure operation overwrites the tenant's retained data by reinstalling the base operating system image, restoring the server's factory-set partition configuration and boot program. The storage medium is overwritten three times, and the server hardware information is consistent with that when the pre-deployment was completed after the reset.

7. The agile algorithm for computing server leasing orders in a multi-tenant intelligent computing center according to claim 1, characterized in that, The deployment orchestration system controls the server power supply and boot process through the IPMI or iDRAC out-of-band management interface. The management agent installed in the pre-deployment phase enables real-time communication between the server and the bare metal resource pool management module, synchronizing hardware health status, network connection status and system operation status.

8. The agile algorithm for computing server leasing orders in a multi-tenant intelligent computing center according to claim 1, characterized in that, The bare-metal resource pool management module monitors four server statuses: idle, ready, allocated, and being reclaimed. The order specifications include the number of CPU cores, memory capacity, storage specifications, and GPU configuration. When matching orders, only servers in the ready state with hardware specifications that match the order specifications are selected.

9. The agile algorithm for computing server leasing orders in a multi-tenant intelligent computing center according to claim 2, characterized in that, The multicast technology sends only one image data packet when deploying multiple servers simultaneously. All servers to be deployed receive the packet in parallel. The image reception and writing time for a single server does not exceed 3 minutes. The network bandwidth usage is reduced by 60% compared to the traditional unicast deployment method, and the deployment efficiency is 4 times that of the traditional unicast deployment method.

10. The agile algorithm for computing server leasing orders in a multi-tenant intelligent computing center according to claim 1, characterized in that, The system includes a monitoring and logging module, which records key nodes in the server installation process, the status change trajectory of rental orders, details of tenant operation behavior, and resource recycling process logs. It generates audit logs and rental transaction logs, and monitors server CPU utilization, memory usage, network throughput, and disk I / O through Telegraf. The heartbeat detection interval is 30 seconds, and alarms are triggered and fault information is recorded when abnormal conditions occur.

Images