A method and device for sharing and scheduling intelligent computing resources based on non-invasive technology

Abstract

The application relates to the technical field of intelligent computing resource sharing, and discloses an intelligent computing resource sharing scheduling method and device based on a non-invasive technology. The method comprises the following steps: receiving a GPU resource pool creation request and obtaining an available GPU list, distributing GPUs in the available GPU list to a GPU resource pool detail table to obtain a resource pool identifier; receiving a container creation request containing the resource pool identifier, establishing an SSH session for each physical machine and uploading a container control script to a preset script directory to obtain an SSH session of a deployed script; detecting the computing power card type of the physical machine through the SSH session, generating a container creation command and remotely executing the container control script to obtain a container record, and writing the container record and the resource pool identifier into a container resource pool association table to complete cross-physical-machine container scheduling. Through the non-invasive architecture based on the SSH remote management technology, the cross-physical-machine GPU resource pooling and container scheduling are completed under the premise of zero component installation and zero configuration modification.

Description

Technical Field

[0001] This invention relates to the field of intelligent computing resource sharing technology, and in particular to an intelligent computing resource sharing scheduling method and apparatus based on non-intrusive technology. Background Technology

[0002] With the rapid growth in demand for artificial intelligence and big data computing, the efficient management and scheduling of computing resources such as GPUs has become a core issue in the cloud computing field. Current mainstream container cluster management solutions are based on Kubernetes to achieve GPU resource pooling and container scheduling. However, this solution has significant invasiveness issues: it requires installing numerous components such as kubelet, container runtime, network plugins, and GPU device plugins on each physical machine, and modifying system kernel parameters, network configurations, and firewall rules. The deployment cycle can take days or even weeks, requiring the shutdown of existing user services. This high technical threshold necessitates professional operations and maintenance personnel.

[0003] When users need to aggregate the computing resources of multiple heterogeneous or homogeneous GPU servers into a unified resource pool, traditional solutions face the dilemma of environmental uniformity: different servers have different system configurations, some servers are running services that cannot be interrupted, and network configurations vary. These factors make it difficult to quickly implement Kubernetes solutions, and users cannot accept the disruption to their existing environment and the long-term interruption of their services. Existing technologies lack a technical solution to achieve cross-physical machine GPU resource pooling and unified scheduling of containerized applications while maintaining the integrity of the user's physical host environment and without installing heavyweight container orchestration components. There is an urgent need for a non-intrusive intelligent computing resource sharing and scheduling method that can quickly achieve GPU resource pooling management and cross-machine deployment of containers without affecting the user's existing business and system configuration. Summary of the Invention

[0004] The main objective of this invention is to provide a method and apparatus for intelligent computing resource sharing and scheduling based on non-intrusive technology. This invention achieves cross-physical machine GPU resource pooling and container scheduling with zero component installation and zero configuration modification through a non-intrusive architecture based on SSH remote management technology.

[0005] To achieve the above objectives, this invention provides a non-intrusive intelligent computing resource sharing and scheduling method, comprising the following steps:

[0006] Receive a GPU resource pool creation request and obtain a list of available GPUs, allocate the GPUs in the list of available GPUs to the GPU resource pool details table, and obtain the resource pool identifier;

[0007] Receive a container creation request containing the resource pool identifier, obtain GPUs from the GPU resource pool details table and group them by physical machine, establish an SSH session for each physical machine and upload the container control script to a preset script directory to obtain an SSH session with deployed scripts;

[0008] The SSH session detects the computing card type of the physical machine, generates a container creation command based on the computing card type and GPU device number string, remotely executes the container control script to obtain a container record, and writes the container record and the resource pool identifier into the container resource pool association table to complete cross-physical machine container scheduling.

[0009] Optionally, in a first implementation of the first aspect of the present invention, receiving a GPU resource pool creation request and obtaining a list of available GPUs, allocating the GPUs in the list of available GPUs to a GPU resource pool details table, and obtaining a resource pool identifier includes:

[0010] Receive a GPU resource pool creation request, query the cluster configuration table based on the cluster identifier in the GPU resource pool creation request, determine whether the isomorphic mode field is true, and if so, extract the cluster identifier;

[0011] Based on the cluster identifier, query the cluster-physical machine association table to obtain the physical machine identifier list, and then query the GPU table based on the physical machine identifier list to obtain the cluster GPU list;

[0012] Based on the GPU identifiers in the cluster GPU list, the GPU resource pool details table is queried, the assigned GPU identifiers are filtered and excluded from the cluster GPU list, and the available GPU list is obtained.

[0013] Based on the available GPU list, a resource pool record is created in the GPU resource pool table, and the GPUs in the available GPU list are allocated to the GPU resource pool details table to obtain the resource pool identifier.

[0014] Optionally, in a second implementation of the first aspect of the present invention, a resource pool record is created in the GPU resource pool table based on the available GPU list, and GPUs in the available GPU list are allocated to the GPU resource pool details table to obtain a resource pool identifier, including:

[0015] Query the GPU resource pool table to verify the uniqueness of the resource pool name, insert a resource pool record containing the resource pool name and an initial value of "unused" in the usage status field into the GPU resource pool table, and obtain the resource pool identifier generated by the database auto-incrementing.

[0016] Initialize the remaining GPU count counter to the number of GPUs in the GPU resource pool creation request, traverse the available GPU list, extract the GPU identifier and combine it with the resource pool identifier to insert into the GPU resource pool details table, decrement the remaining GPU count counter until it reaches zero, and establish the association between the resource pool identifier and the GPU identifier;

[0017] By querying the GPU table through the GPU identifier in the GPU resource pool details table, the physical machine identifier field is obtained, and a three-layer mapping relationship is established from the resource pool identifier to the GPU identifier to the physical machine identifier.

[0018] Optionally, in a third implementation of the first aspect of the present invention, the physical machine identifier field is obtained by querying the GPU table through the GPU identifier in the GPU resource pool details table, and a three-layer mapping relationship from the resource pool identifier to the GPU identifier to the physical machine identifier is established, including:

[0019] Extract all records containing the resource pool identifier from the GPU resource pool details table, obtain the GPU identifier field from each record, and form a GPU identifier list;

[0020] The GPU identifier list is used as a query condition to retrieve data from the GPU table. The physical machine identifier field of the record corresponding to each GPU identifier is extracted to form a correspondence between GPU identifiers and physical machine identifiers.

[0021] Based on the association between the resource pool identifier and the GPU identifier in the GPU resource pool details table, and combined with the correspondence between the GPU identifier and the physical machine identifier, a three-layer mapping relationship is established from the resource pool identifier to the physical machine identifier through the GPU identifier.

[0022] Optionally, in a fourth implementation of the first aspect of the present invention, receiving a container creation request containing the resource pool identifier, obtaining GPUs from the GPU resource pool details table and grouping them by physical machine, establishing an SSH session for each physical machine and uploading the container control script to a preset script directory to obtain an SSH session with deployed scripts, includes:

[0023] Based on the resource pool identifier in the container creation request, query the GPU resource pool table, extract the usage status field of the resource pool record, determine whether the value of the usage status field is unused, and verify the exclusive status of the resource pool.

[0024] Based on the resource pool identifier, query the GPU resource pool details table to obtain the GPU identifier list. Based on the GPU identifier list, query the GPU table to obtain the physical machine identifier field. Traverse the GPU records and group them by physical machine identifier. Store each physical machine identifier as a key and the corresponding GPU identifier list as a value in the mapping data structure to obtain the mapping table between physical machines and GPUs.

[0025] The mapping table between physical machines and GPUs is traversed, an SSH session is established for each physical machine, and the container control script is uploaded to the preset script directory to obtain the SSH session with the deployed script.

[0026] Optionally, in the fifth implementation of the first aspect of the present invention, the mapping table between the physical machines and GPUs is traversed, an SSH session is established for each physical machine, and the container control script is uploaded to a preset script directory to obtain an SSH session with deployed scripts, including:

[0027] Traverse the mapping table between physical machines and GPUs to extract the lists of physical machine identifiers and GPU identifiers. Query the physical machine table to obtain the IP address, SSH port, username, and password of the physical machine. Generate a unique container name based on the number of physical machine identifiers and GPU identifiers in the lists. Create an SSH session object and set connection parameters to establish an SSH connection with the physical machine.

[0028] The SFTP file transfer channel is opened through the SSH connection, the container control script is uploaded to the preset script directory of the physical machine, the command to set the script execution permissions is executed, and an SSH session with the deployed script is obtained.

[0029] Optionally, in the sixth implementation of the first aspect of the present invention, the computing card type of the physical machine is detected through the SSH session, a container creation command is generated based on the computing card type and GPU device number string, and the container control script is remotely executed to obtain a container record. The container record and the resource pool identifier are then written into a container resource pool association table to complete cross-physical machine container scheduling, including:

[0030] Traverse the GPU identifier list, query the GPU table to obtain the device number field, and connect them with commas to form a GPU device number string. Execute the computing card detection command through the SSH session and determine the computing card type based on the command exit code.

[0031] Based on the computing card type and GPU device number string, a container creation command containing container configuration parameters is constructed. The container control script is remotely executed through the SSH session to generate a container configuration file and start the container. The command exit code is parsed to verify successful container creation. The container configuration information is inserted into the container table to obtain the container record.

[0032] The usage status field of the resource pool record is updated to "used", and the container record and the resource pool identifier are written into the container resource pool association table to complete cross-physical machine container scheduling.

[0033] Optionally, in the seventh implementation of the first aspect of the present invention, a container creation command containing container configuration parameters is constructed based on the computing power card type and GPU device number string; the container control script is remotely executed through the SSH session to generate a container configuration file and start the container; the command exit code is parsed to verify successful container creation; and the container configuration information is inserted into the container table to obtain a container record, including:

[0034] Extract the image name, number of CPU cores, memory size, and disk space parameters from the container creation request, and combine them with the computing card type, GPU device number string, container name, and physical machine password to construct a container creation command string containing script path, operation parameters, and all configuration parameters;

[0035] The container creation command string is executed through the SSH session. The container control script generates a container configuration file containing resource limits and GPU device mapping according to the computing card type and calls the container orchestration command to start the container. The command standard output stream and error output stream are read, the command exit code is extracted to determine whether it is a success status, and the container name, image, resource configuration and physical machine information are inserted into the container table to obtain the container record.

[0036] Optionally, in the eighth implementation of the first aspect of the present invention, the usage status field of the resource pool record is updated to the used status, and the container record and the resource pool identifier are written into the container resource pool association table to complete cross-physical machine container scheduling, including:

[0037] Verify that the container creation status of all physical machines in the mapping table between physical machines and GPUs is successful. Query the GPU resource pool table through the resource pool identifier to obtain the resource pool record object. Call the status field setting method of the resource pool record object to update the usage status field value from unused to used. Perform a database update operation to persist the usage status field to prevent the resource pool from being reused by other container creation requests.

[0038] Iterate through the list of successfully created container names, parse the physical machine identifier from each container name, query the container table based on the container name and physical machine IP address to obtain the container identifier of the container record, construct a container resource pool association record containing the container identifier, the resource pool identifier and the current timestamp, insert the container resource pool association record into the container resource pool association table, and establish a many-to-one association between the container and the resource pool to support the resource pool release operation when the container is deleted.

[0039] The present invention also provides an intelligent computing resource sharing and scheduling device based on non-intrusive technology, comprising:

[0040] The receiving module is used to receive a GPU resource pool creation request and obtain a list of available GPUs, allocate the GPUs in the list of available GPUs to the GPU resource pool details table, and obtain the resource pool identifier.

[0041] The deployment module is used to receive a container creation request containing the resource pool identifier, obtain GPUs from the GPU resource pool details table and group them by physical machine, establish an SSH session for each physical machine and upload the container control script to a preset script directory to obtain an SSH session with deployed scripts;

[0042] The scheduling module is used to detect the computing card type of the physical machine through the SSH session, generate a container creation command based on the computing card type and GPU device number string, remotely execute the container control script to obtain a container record, and write the container record and the resource pool identifier into the container resource pool association table to complete cross-physical machine container scheduling.

[0043] In summary, this invention, through a non-intrusive architecture based on SSH remote management technology, achieves cross-physical machine GPU resource pooling and container scheduling with zero component installation and zero configuration modification, offering advantages over traditional Kubernetes solutions. By establishing a homogeneous cluster verification mechanism and a GPU resource pool details table to create a three-layer mapping relationship from resource pool identifier to GPU identifier to physical machine identifier, it achieves logical aggregation of cross-physical machine GPU resources, avoiding the complex architecture of Kubernetes that relies on etcd distributed storage and the API Server scheduler. It replaces Kubernetes' continuous inter-component communication mechanism with a one-time operation process of SSH session establishment, SFTP script upload, and remote command execution. Only the container control script needs to be uploaded to a preset directory and executed remotely; no additional components such as kubelet, network plugins, or GPU device plugins need to be installed on the physical machine, completely maintaining the integrity of the user's system environment. Through atomic updates of the resource pool usage status field and the establishment of a container resource pool association table, it achieves exclusive state management of the GPU resource pool, ensuring that the same resource pool is not reused by multiple container groups, guaranteeing the accuracy and consistency of resource allocation under the non-intrusive scheduling mechanism. This invention takes only minutes from resource pool creation and container deployment to establishing relationships. Compared to the traditional 3-7 day deployment cycle, it significantly reduces time costs and technical barriers, and achieves plug-and-play rapid deployment capabilities. This allows users to complete the shared scheduling of intelligent computing resources without stopping existing business, without a unified server environment, and without the intervention of professional operation and maintenance personnel. Attached Figure Description

[0044] Figure 1 This is a schematic diagram of the steps of an intelligent computing resource sharing and scheduling method based on non-intrusive technology in one embodiment of the present invention;

[0045] Figure 2 This is a structural block diagram of an intelligent computing resource sharing and scheduling device based on non-intrusive technology in an embodiment of the present invention.

[0046] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0047] 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.

[0048] Reference Figure 1 This embodiment provides a non-intrusive intelligent computing resource sharing and scheduling method, including the following steps:

[0049] S1: Receive the GPU resource pool creation request and obtain the list of available GPUs. Allocate the GPUs in the list of available GPUs to the GPU resource pool details table and obtain the resource pool identifier.

[0050] S2, receive a container creation request containing a resource pool identifier, obtain GPUs from the GPU resource pool details table and group them by physical machine, establish an SSH session for each physical machine and upload the container control script to the preset script directory, and obtain the SSH session with deployed scripts;

[0051] S3 detects the computing card type of the physical machine through an SSH session, generates a container creation command based on the computing card type and GPU device number string, remotely executes the container control script, obtains the container record, and writes the container record and resource pool identifier into the container resource pool association table to complete cross-physical machine container scheduling.

[0052] In one example, a GPU resource pool creation request is received and a list of available GPUs is obtained. The GPUs in the available GPU list are then assigned to the GPU resource pool details table, and the resource pool identifier is obtained, including:

[0053] Receive a GPU resource pool creation request, query the cluster configuration table based on the cluster identifier in the GPU resource pool creation request, determine whether the homogeneous mode field is true, and if so, extract the cluster identifier.

[0054] Based on the cluster identifier, query the cluster-physical machine association table to obtain the list of physical machine identifiers, and then query the GPU table based on the list of physical machine identifiers to obtain the list of cluster GPUs;

[0055] Based on the GPU identifiers in the cluster GPU list, query the GPU resource pool details table, filter the allocated GPU identifiers and exclude them from the cluster GPU list to obtain the list of available GPUs;

[0056] Based on the list of available GPUs, a resource pool record is created in the GPU resource pool table. The GPUs in the list of available GPUs are then assigned to the GPU resource pool details table to obtain the resource pool identifier.

[0057] In this example, after the management and control platform receives the GPU resource pool creation request, it extracts the cluster identifier field from the request parameters. Based on the cluster identifier, it accesses the cluster configuration table and calls the cluster configuration interface to query the corresponding cluster's operating mode. It then checks the `is_homogeneous` field (a boolean field) to determine if the current cluster is in homogeneous mode. If the result is true, meaning all physical machines in the cluster have the same GPU model, performance, driver version, and other parameters, and meet the resource pool scheduling requirements, the system confirms that the cluster has the foundation for building a unified GPU resource pool, and thus extracts the current cluster identifier. Based on the confirmed cluster identifier, it accesses the cluster-physical machine association table. The physical machine association table establishes a mapping relationship between cluster IDs and physical machine IDs. Based on the query results, it extracts a list of all physical machine identifiers included in the cluster. Using this as input, it queries the GPU resource table to obtain information on all GPU resources mounted on these physical machines, forming a set of GPU entities within the current cluster—the cluster GPU list. To exclude GPU resources already occupied by other resource pools, the GPU resource pool details table is accessed based on the unique identifier of each GPU in the GPU list. The table checks if all GPU identifiers are already bound to a resource pool. If a GPU identifier has a corresponding record in the resource pool details table, it indicates that the GPU is occupied by another resource pool, and this GPU is considered allocated resources and needs to be removed from the current cluster GPU list. GPUs not appearing in the resource pool details table are considered idle resources and are retained to form the final available GPU list. After the available GPU list is built, the resource pool creation process is executed. A new resource pool record is inserted into the GPU resource pool master table. The record includes the user-specified resource pool name, creation time, cluster identifier, and current status flag field, where the status field is initially set to "unused". For each GPU resource in the available GPU list, a one-to-one mapping relationship is established between its GPU identifier and the generated resource pool identifier. This mapping is written to the GPU resource pool details table, recording the correspondence between the current resource pool and each physical GPU device, forming a logical resource pool. The system-generated resource pool primary key is used as the resource pool identifier. The entire process is wrapped in a database transaction mechanism, which enables the operation to be rolled back if an exception occurs or a data constraint conflict occurs in any intermediate step, thus avoiding the problem of inconsistent system state caused by writing partial resource pool information.

[0058] Before creating the GPU resource pool, the cluster homogeneity mode is verified, and the exclusive status of the resource pool is verified when the container is created. This includes: querying the cluster configuration table to obtain the homogeneity mode field and GPU model field corresponding to the cluster identifier; determining whether the homogeneity mode field value is true; if false, the creation of the resource pool is rejected and an error message is returned; if true, the GPU model field value is extracted as the standard for allowed GPU models in the resource pool; the model field of each GPU record in the cluster GPU list is traversed to verify whether all GPU models are completely consistent with the GPU model standard, ensuring the homogeneity of GPU types within the resource pool; adding a usage status field and an occupation timestamp field to the resource pool record in the GPU resource pool table; the initial value of the usage status field is set to the integer value corresponding to the unused state; when a container creation request is received, the usage status field of the resource pool record is queried to determine whether it is in an unused state; if it is in a used state, the occupation timestamp field is extracted and compared with the current time to calculate the resource pool occupation time, and an error message indicating that the resource pool is occupied and the estimated release time are returned, realizing the exclusive status verification of the resource pool; adding a database row-level locking mechanism to the resource pool usage status field update operation, using SELECT FOR The UPDATE statement locks the resource pool record, preventing other concurrent requests from accessing the same resource pool before the transaction is committed. It performs an atomic update of the usage status field from unused to used, and records the occupied timestamp field with the current system time. After the transaction is committed, it releases the row-level lock to prevent multiple container creation requests from using the same resource pool at the same time, which could lead to GPU resource allocation conflicts.

[0059] In one example, a resource pool record is created in the GPU resource pool table based on the list of available GPUs. The GPUs in the available GPU list are then assigned to the GPU resource pool details table to obtain the resource pool identifier, including:

[0060] Query the GPU resource pool table to verify the uniqueness of the resource pool name, insert a resource pool record in the GPU resource pool table containing the resource pool name and the initial value of the usage status field as unused, and obtain the resource pool identifier generated by the database auto-incrementing.

[0061] Initialize the remaining GPU count counter to the number of GPUs in the GPU resource pool creation request, traverse the list of available GPUs, extract the GPU identifier and combine it with the resource pool identifier to insert into the GPU resource pool details table, decrement the remaining GPU count counter until it reaches zero, and establish the association between the resource pool identifier and the GPU identifier;

[0062] By querying the GPU table through the GPU identifier in the GPU resource pool details table to obtain the physical machine identifier field, a three-layer mapping relationship is established from the resource pool identifier to the GPU identifier to the physical machine identifier.

[0063] In this example, a creation request containing the resource pool name and the required number of GPUs is received. Based on the resource pool name field in the request, a query is constructed to access the GPU resource pool main table. An equality query is used to verify whether the resource pool name already exists in an existing resource pool, ensuring the global uniqueness of the resource pool name. If the query result is empty, it means the name is not occupied. The resource pool creation logic continues, and a new record is inserted into the GPU resource pool table. This record contains the resource pool name field and the initial values ​​of the usage status field, where the usage status is set to unused to indicate that the resource pool has not yet been allocated to any container group. The insertion operation triggers the database's auto-incrementing primary key mechanism, and MyBatis automatically backfills the generated resource pool identifier. An integer variable is initialized as a counter for the remaining GPU quantity. The initial value of the remaining GPU quantity counter is set to the value of the GPU quantity field in the user request, used to control the number of iterations in the GPU allocation process. Each GPU entity in the available GPU list is traversed. In each loop, the unique identifier of the current GPU is extracted as `gpu_id`. This `gpu_id` is then combined with the previously obtained resource pool identifier `pool_id` to construct an insertion record in the GPU resource pool details table. After insertion, a counter for the remaining GPU quantity is decremented until it reaches zero, indicating that all requested GPU resources have been bound. This process generates multiple resource pool details records, each corresponding to a binding relationship between a GPU and that resource pool. After the resource pool details are inserted, all GPU identifiers in the GPU resource pool details table are used as indexes to batch query the GPU resource table to obtain the physical machine identifier field of the corresponding GPU device. The physical machine identifier field is then used to establish a connection between the current resource pool identifier and the physical machine identifier of the physical GPU device, forming a three-layer mapping structure from resource pool identifier to physical machine identifier via GPU identifier.

[0064] In one example, the physical machine identifier field is obtained by querying the GPU table through the GPU identifier in the GPU resource pool details table. A three-layer mapping relationship is established from the resource pool identifier to the GPU identifier and then to the physical machine identifier, including:

[0065] Extract all records containing resource pool identifiers from the GPU resource pool details table, and obtain the GPU identifier field from each record to form a GPU identifier list;

[0066] The GPU identifier list is used as a query condition to retrieve data from the GPU table. The physical machine identifier field of the record corresponding to each GPU identifier is extracted to form a correspondence between GPU identifiers and physical machine identifiers.

[0067] Based on the association between the resource pool identifier and the GPU identifier in the GPU resource pool details table, and combined with the correspondence between the GPU identifier and the physical machine identifier, a three-layer mapping relationship is established from the resource pool identifier to the physical machine identifier through the GPU identifier.

[0068] In this example, all records matching a specified resource pool identifier are extracted from the GPU resource pool details table. A query condition is constructed, setting the resource pool identifier field to equal the primary key value of the resource pool currently being scheduled or queried. All records meeting the condition are retrieved from the GPU resource pool details table. The GPU identifier field of each record is extracted, constructing a GPU identifier list where each element represents the physical GPU device identifier actually bound to the current resource pool. Using the GPU identifier list as input, the GPU resource information table is accessed, and a batch query operation is constructed. Using the IN semantics, all GPU identifiers are used as query keys. For each retrieved GPU record, the associated physical machine identifier field is extracted, i.e., the physical server number or primary key ID bound to the GPU. A one-to-one mapping relationship between GPU identifiers and physical machine identifiers is constructed, forming a GPU-to-physical machine mapping table. Based on the existing binding relationship between resource pool identifier and GPU identifier in the GPU resource pool details table, and combined with the query results from GPU identifier to physical machine identifier, a two-layer mapping is used to generate a three-layer mapping structure that starts from the resource pool identifier, passes through the intermediate GPU identifier, and finally points to the physical machine identifier. In form, it is: resource pool ID → GPU ID → physical machine ID, where each layer is a one-way mapping, forming an indirect mapping channel between the resource pool and the physical machine.

[0069] This process involves generating a mapping table between physical machines and GPUs based on the GPU resource pool details table and performing cross-physical machine container distributed orchestration. The process includes: querying the GPU resource pool details table based on the resource pool identifier to obtain all records containing both the resource pool identifier and GPU identifier fields; extracting the GPU identifier field from the records to form a GPU identifier list; using the GPU identifier list as an IN query condition to batch retrieve corresponding GPU records from the GPU table. Each GPU record contains a GPU identifier field, a physical machine identifier field, and a device number field. A HashMap data structure is created as the mapping table between physical machines and GPUs. The GPU record list is traversed, and for each GPU record, the physical machine identifier field value and the GPU identifier field value are extracted. The `computeIfAbsent` method of the HashMap is called to establish a mapping relationship using the physical machine identifier as the key and the GPU identifier list as the value. If the key does not exist, a new ArrayList is created to add the current GPU identifier; if the key already exists, the current GPU identifier is appended to the existing list. This completes the construction of the mapping table for GPUs grouped by physical machine. Upon successful initialization, a container name list is created to record the container orchestration results. Each key-value pair entry in the physical machine-GPU mapping table is traversed, and the physical machine identifier and the corresponding GPU identifier are extracted from the key-value pair. The system identifies the list of GPU identifiers, counts the number of elements in the GPU identifier list to determine the number of GPUs allocated to the physical machine, and concatenates the original container name, physical machine identifier, number of GPUs, and GPU suffix string to generate a unique container name. This unique container name format ensures that container names from the same resource pool do not conflict on different physical machines. A new container creation data transfer object is then constructed, copying common parameters from the original container creation request, such as image, CPU, memory, disk, and start / end time. The container name is set to a unique container name, the GPU identifier list is set to the current physical machine's GPU identifier list, and the physical machine IP is set to the IP address corresponding to the current physical machine identifier. The container... The system creates a data transfer object and physical machine information, which is then passed to the container creation execution method. For each physical machine, exception handling and status verification are performed during container creation. If container creation fails on any physical machine, the overall orchestration task is marked as failed and a transaction rollback is triggered. All successfully created container records and resource pool records are deleted. If container creation succeeds on all physical machines, the system verifies that the number of successfully created container names equals the number of physical machines in the mapping table, confirming the completion of cross-physical machine container distributed orchestration. Each container in the container group runs independently on different physical machines and uses its allocated GPU resources, achieving logically unified management through resource pool identifiers.

[0070] In one example, a container creation request containing a resource pool identifier is received. GPUs are retrieved from the GPU resource pool details table and grouped by physical machine. An SSH session is established for each physical machine, and the container control script is uploaded to a preset script directory, resulting in an SSH session with deployed scripts, including:

[0071] Query the GPU resource pool table based on the resource pool identifier in the container creation request, extract the usage status field of the resource pool record, determine whether the usage status field value is unused, and verify the exclusive status of the resource pool.

[0072] The GPU resource pool details table is queried based on the resource pool identifier to obtain the list of GPU identifiers. The GPU table is then queried based on the list of GPU identifiers to obtain the physical machine identifier field. The GPU records are traversed and grouped by physical machine identifier. Each physical machine identifier is used as the key and the corresponding list of GPU identifiers is used as the value to store in the mapping data structure to obtain the mapping table between physical machines and GPUs.

[0073] Traverse the mapping table between physical machines and GPUs, establish an SSH session for each physical machine and upload the container control script to the preset script directory to obtain the SSH session with the deployed script.

[0074] In this example, the GPU resource pool identifier is extracted from the container creation request, and the GPU resource pool main table is accessed using the GPU resource pool identifier as a query condition. The corresponding resource pool record is retrieved by matching the primary key field. The value of the usage status field is read from the query results. This field is represented by an integer, where a value of 0 indicates that the resource pool is currently unused, and a value of 1 indicates that the resource pool is occupied. To ensure the effectiveness of the exclusive scheduling mechanism of the resource pool, a logical judgment is performed on the usage status field. The container deployment process is allowed to continue only when the status value is 0. If the status value is 1, the current deployment process is immediately aborted, and an error message is returned indicating that the resource pool has been occupied by another container group, avoiding conflicts caused by multiple containers repeatedly scheduling the same GPU resource. After confirming that the resource pool is unused, a query condition is constructed to access the GPU resource pool details table using the resource pool identifier as the key. All GPU records bound to this resource pool are filtered, and the GPU identifier field is extracted from each record to construct a GPU identifier list. The GPU identifier list is used as a query index to retrieve the corresponding GPU record in the GPU information table, and the physical machine identifier field of each record is read, which represents the physical server ID to which the GPU belongs. To facilitate container orchestration by physical dimension, a key-value mapping data structure, such as a HashMap, is initialized at this stage. The physical machine identifier field serves as the mapping key, and a list of all GPU identifiers allocated to that physical machine is used as the mapping value. When traversing each GPU record, it checks if the current physical machine identifier already exists in the mapping structure. If it does, the current GPU identifier is appended to its value list; otherwise, a new key-value pair is created and inserted into the structure, forming a many-to-one mapping between physical machines and GPU resources. This mapping table serves as the structural basis for deployment command distribution, mapping the logical GPU set in the resource pool to a physically deployable node set, providing a physical dimension for multi-node concurrent deployment. An iterative operation is performed on each key-value pair in the mapping table. In each iteration, the current physical machine identifier is extracted, and the physical machine information table or cache structure is accessed using the physical machine identifier to obtain the corresponding IP address, SSH port number, login username, and password, etc. Subsequently, an SSH connection session to the physical machine is established using an SSH client tool such as JSch. After a successful session establishment, the container control script file is uploaded to a preset script directory path via the SFTP channel, such as / usr / local / containSH / . After uploading, the script execution permissions must be set using the chmod command on the remote machine to ensure that subsequent scheduling commands can execute the script remotely to complete the container deployment. This process is executed sequentially on each physical machine, building a collection of SSH session objects containing multiple deployed scripts.

[0075] The process involves obtaining GPU device IDs and verifying device availability based on a physical machine-to-GPU mapping table. This includes: traversing the GPU identifier list corresponding to each physical machine in the mapping table; querying the GPU table for each GPU identifier to obtain GPU records containing a device ID field and a device status field; verifying the device status field value to indicate availability; returning an error message if an unavailable GPU exists; and extracting the device ID field value to form a physical machine device ID list if all GPUs are available; sorting the device IDs in the physical machine device ID list; checking the continuity of the device ID sequence and whether the starting number is zero; logging warnings if device IDs are not consecutive or the starting number is not zero; concatenating the sorted device ID list with commas to form a GPU device ID string, ensuring the string format conforms to the container runtime device specification; and associating the GPU device ID string with the physical machine identifier in the device ID mapping table, establishing a mapping relationship between physical machine identifiers and GPU device ID strings. This mapping relationship is used for subsequent parameter construction in container creation commands and generation of device mapping configuration in container configuration files.

[0076] In one example, the mapping table between physical machines and GPUs is traversed, an SSH session is established for each physical machine, and the container control script is uploaded to a preset script directory, resulting in an SSH session with deployed scripts, including:

[0077] Traverse the mapping table between physical machines and GPUs to extract the lists of physical machine identifiers and GPU identifiers. Query the physical machine table to obtain the IP address, SSH port, username, and password of the physical machine. Generate a unique container name based on the number of physical machine identifiers and GPU identifiers in the lists. Create an SSH session object and set the connection parameters to establish an SSH connection with the physical machine.

[0078] Open an SFTP file transfer channel via SSH connection, upload the container control script to the preset script directory on the physical machine, execute the command to set the script execution permissions, and obtain an SSH session for the deployed script.

[0079] In this example, each key-value pair in the physical machine-GPU mapping table is traversed sequentially, and the deployment preparation work of the container control script is executed for each physical machine. During the traversal, the physical machine identifier and the corresponding GPU identifier list are extracted from the current key-value pair, where the physical machine identifier is used as the server primary key field to access the physical machine information table. The physical machine table is accessed based on the physical machine identifier, and the corresponding record is retrieved by matching the primary key field. The network connection parameters of the physical machine are extracted from it, including the IP address field, SSH connection port field, remote login username field, and authentication password field. A unique container name is generated by combining the base container name provided in the container creation request with the current physical machine identifier field and its corresponding GPU quantity field. The naming method can adopt the format "container prefix-physical machine ID-GPU quantity (GPUs)". In a multi-node deployment scenario, the container instance name on each node is unique in the namespace, which facilitates the scheduler to track and allocate resources. Initialize an SSH session object using JSch or an equivalent SSH client tool, and call the relevant interfaces to set session parameters. Set the physical machine's IP address to the target host address, the port field to the SSH connection port, and the username to the remote login account. Simultaneously, write the extracted password field as authentication credentials into the session configuration, and disable host key checking through configuration parameters to meet automated deployment requirements. After parameter settings are complete, call the `connect` method to start the SSH connection establishment process, and save the session object for use by the command and file channels after a successful connection. After the SSH connection is successfully established, call the `openChannel` method based on this session, specifying the channel type as "SFTP," to open the file transfer channel, and activate SFTP channel communication through the `connect` interface. Ensure that the target remote path " / usr / local / containSH / " exists using `cd` or `mkdir` operations, and prepare to receive the local container control script file. Read the script file content from the local disk or cache, and execute the `put` method through the SFTP channel to upload the script file to the remote path. After successful upload, close the file input stream and release local resources. To ensure the script can be executed remotely, the exec type channel is reopened, and the remote execution command is set to grant the uploaded script executable permissions by calling the chmod command with sudo privileges. The command format can be echo <password>| sudo -S chmod +x / usr / local / containSH / docker_controller.sh. This command uses a pipe to pass the password to the sudo command, avoiding the need for user interaction.Upon successful execution, the channel is closed and the current SSH session object is returned. The SSH session object contains the complete connection context and the status of the deployed scripts, indicating that the script deployment on the current physical machine is complete and ready to receive subsequent container scheduling instructions. This operation will complete the initialization of the deployment environment after traversing all physical machines.

[0080] Uploading container control scripts and executing parameterized container creation commands via an SSH session includes: pre-setting container control script files in the local storage path of the management control platform; the container control scripts support four operation parameters: createAndstart (create and start), stop (stop), restart (restart), and delete (delete); creating an SFTP file transfer channel object via SSH connection; calling the directory switching method of the SFTP channel object to switch to the preset script directory on the physical machine (if the preset script directory does not exist, it is created by calling the directory creation method); opening the input stream of the local container control script file; calling the file upload method of the SFTP channel object to transfer the input stream content to the preset script directory on the remote physical machine; and closing the input stream and SFTP channel; constructing a script permission setting command string, which includes the physical machine password via an echo pipe, the sudo privilege escalation command, the chmod executable permission setting command, and the full script path; creating a command execution channel object via SSH session; and calling the command setting method of the command execution channel object to pass the command... The script sets the permission command string, connects to and executes the command channel, waits for the command to complete, obtains the exit code to verify successful permission settings, disconnects the command execution channel, and ensures that the container control script has executable permissions. It then constructs a container creation command string, which is arranged in a fixed parameter order and includes the physical machine password, preset script directory path, container control script filename, createAndstart operation parameters, container name parameters, image name parameters, CPU core count parameters, memory size parameters with unit suffix, GPU device ID string parameters, computing card type parameters, Harbor image repository address parameters, host machine export port parameters, and physical machine IP address parameters. A new command execution channel object is created via an SSH session, the container creation command string is set as the command to be executed, and the command channel is connected to begin remote execution of the container control script. After receiving the parameters, the container control script calls its internal container creation function according to the createAndstart operation parameters to generate the container configuration file and start the container, achieving non-intrusive container management based on parameterized script execution.

[0081] In one example, the physical machine's compute card type is detected via an SSH session. Based on the compute card type and GPU device ID string, a container creation command is generated and the container control script is executed remotely to obtain a container record. This container record, along with the resource pool identifier, is written to a container resource pool association table, completing cross-physical machine container scheduling, including:

[0082] Iterate through the GPU identifier list, query the GPU table to obtain the device number field, and concatenate them with commas to form a GPU device number string. Execute the computing card detection command through the SSH session and determine the computing card type based on the command exit code.

[0083] A container creation command containing container configuration parameters is constructed based on the computing card type and GPU device number string. The container control script is remotely executed via SSH session to generate the container configuration file and start the container. The command exit code is parsed to verify successful container creation. The container configuration information is inserted into the container table to obtain the container record.

[0084] Update the usage status field of the resource pool record to the used status, and write the container record and resource pool identifier into the container resource pool association table to complete cross-physical machine container scheduling.

[0085] In this example, the list of GPU identifiers associated with the physical machine is traversed, and for each GPU identifier, the GPU information table query interface is called to extract its corresponding device number field. The device number field is used to identify the index position of the GPU in the physical machine, such as 0, 1, 2, 3, etc. The device numbers are concatenated with commas in their original order to generate a device number string, which is used as the parameter string for device binding in the container deployment command. A remote command execution channel is opened based on the SSH session object corresponding to the current physical machine, and the preset computing card detection commands are executed. The nvidia-smi command is executed first to determine whether it is an NVIDIA computing card. If the command returns an exit code of 0, it is determined that the physical machine has NVIDIA GPU resources; if it returns a non-zero exit code, it continues to try to execute Huawei Ascend series detection commands such as npu-smi info. If it returns 0, it indicates that it is a Huawei Ascend environment; if all preset commands fail to detect, it is set to "auto" to allow subsequent scripts to adapt automatically. After determining the computing card type, the system constructs a container creation command based on the basic configuration parameters included in the container deployment request, such as container name, image name, number of CPU cores, memory capacity, and disk capacity, combined with the device ID string and the determined computing card type. This command calls the pre-deployed `docker_controller.sh` script, passing the `createAndstart` parameter, and appends specific parameter fields such as container name, image path, number of CPU cores, memory size, GPU ID string, computing card type identifier, Harbor private repository address, dynamic port mapping information, and physical machine IP address. This script command is executed via an SSH session, and the system receives command output and error output streams in real time, while also listening for command exit codes. When the exit code returns 0, it indicates that the container has been successfully created. The system then builds a container record data object locally and persists it into the container information table. The record includes the container name, deployment physical machine IP, image information, resource configuration, creation time, and status. After insertion, a unique container identifier automatically generated by the database is obtained. After a container is successfully created, the status flag field of the GPU resource pool is updated from 0 to 1, indicating that the resource pool is currently occupied. This prevents other containers from repeatedly scheduling GPU resources in this resource pool, ensuring the exclusivity of GPU usage and isolation of scheduling conflicts. A new resource binding relationship record is constructed by combining the newly inserted container record with the corresponding resource pool identifier and inserted into the container resource pool association table. The container resource pool association table uses bidirectional references between the container ID and the GPU resource pool ID to complete the logical binding between the container and the resource pool. This forms a complete four-level mapping link in the scheduling system: "Resource Pool → GPU → Physical Machine → Container," enabling unified scheduling and deployment of container resources across physical machines.

[0086] The container control script generates a container configuration file containing resource limits and GPU device mappings based on the computing card type. This includes: determining if the computing card type is NVIDIA; if so, setting the `runtime` field to `nvidia` in the container configuration file to enable NVIDIA container runtime; adding a `reservations` node under the `deploy` resource configuration node; adding a `devices` array under the `reservations` node and setting the `driver` field to `nvidia` and the `capabilities` field to `gpu`; and setting the `NVIDIA_VISIBLE_DEVICES` field to the GPU device ID string via the `environment` environment variable node to achieve NVIDIA... Precise GPU device allocation; determine if the computing card type is Huawei Ascend; if so, iterate through each device number in the GPU device number string, construct a device file path in the format / dev / davinci plus the device number, add the mapping configuration from the host device file path to the container's device file path in the device mapping node of the container configuration file, and implement file system-level mounting of Huawei Ascend NPU devices; set the cpus field value to the number of CPU cores in the container creation request and the mem_limit field value to the memory size parameter in the resource limit node of the container configuration file, add the mapping configuration from the host exported port to the container's service port in the ports mapping node, add the mounting configuration from the host data directory to the container working directory in the volumes mount node, and generate the container configuration file.

[0087] In one example, a container creation command containing container configuration parameters is constructed based on the computing card type and GPU device number string. The container control script is remotely executed via an SSH session to generate the container configuration file and start the container. The command exit code is parsed to verify successful container creation. The container configuration information is then inserted into the container table to obtain the container record, including:

[0088] Extract the image name, number of CPU cores, memory size, and disk space parameters from the container creation request. Combine these parameters with the computing card type, GPU device number string, container name, and physical machine password to construct a container creation command string that includes the script path, operation parameters, and all configuration parameters.

[0089] The container creation command string is executed through an SSH session. The container control script generates a container configuration file containing resource limits and GPU device mapping based on the computing card type, and calls the container orchestration command to start the container. It reads the command's standard output stream and error output stream, extracts the command exit code to determine whether it is a success status, and inserts the container name, image, resource configuration, and physical machine information into the container table to obtain the container record.

[0090] In this example, parameters included in the container creation request data structure are extracted, including the image name, number of CPU cores, memory capacity, and disk space. Simultaneously, the compute card type and GPU device ID string obtained from the GPU resource pool allocation process, along with the unique container name generated in the preceding steps, and the remote host login password associated with the current physical machine's SSH session, are used to construct a container creation command string with complete context information. The command string is centered around a bash call to the container control script `docker_controller.sh`. Additional parameters include the operation type `createAndstart`, container name, image name, number of CPU cores (in cores), memory capacity (in gigabytes), GPU ID string (e.g., "0,1,2,3"), compute card type, Harbor image repository address, container export port, and the current physical machine's IP address. Furthermore, the physical machine password is injected into the command prefix using `echo password| sudo -S` to grant sudo privileges, allowing the script to execute on the remote host. The command string is sent to the physical machine via an SSH session object created using JSch. On the remote host, the `docker_controller.sh` script automatically parses the received parameters and automatically selects the appropriate configuration branch based on the computing card type to generate a suitable container configuration file. For example, when an NVIDIA GPU is identified, the `runtime: nvidia` configuration item is automatically inserted, along with the corresponding GPU device mapping field and environment variable configuration. When a Huawei Ascend device is identified, the corresponding device node mount path and driver parameters are added, along with the container resource limitation section, including CPU and memory limitation instructions. After generating the configuration file, the script calls a container orchestration command (such as `docker-compose up -d`) to start the container instance in background mode. During the execution of this command, the standard output stream and error output stream of the command are continuously read through the SSH channel. Each line of log read is cached and recorded in the scheduling system log component. After the command execution is complete, its exit code is obtained. If the exit code is equal to 0, it is determined that the current container has been successfully deployed, and the process enters the result registration stage. Construct a container record data structure, populate the container data object with fields such as container name, image name, number of CPU cores, memory capacity, disk space, deployment physical machine IP address, computing card type, GPU number string, and deployment timestamp, and call the data persistence interface to write it to the container information table. The container information table serves as the main index storage structure for the container scheduling status. After successful writing, the primary key identifier of the container record generated by the database is automatically returned.If the exit code of the command execution is not equal to 0, the container creation is determined to have failed. The error output is written to the deployment exception log, the current deployment process is interrupted, and the transaction manager is notified to roll back all related record writes and resource occupancy flags to ensure the consistency of system state and the atomicity of resource usage. During batch multi-physical machine deployment, the above logic is executed one by one until all mapped physical machines have completed the construction, distribution, and execution of the container creation command.

[0091] When container creation fails on any physical machine in the physical machine-GPU mapping table, a rollback operation is performed, including: monitoring the exit code of the container creation command for each physical machine in the physical machine-GPU mapping table; when an exit code for any physical machine is not in a successful state, marking the current transaction as a rollback state; extracting all successfully created container names and their corresponding physical machine IP addresses from the list of successfully created container names; traversing the list of successfully created container names, re-establishing an SSH session with the corresponding physical machine for each container name, constructing a container deletion command string including the container control script path, delete operation parameters, and container name; executing the container deletion command string through the SSH session; calling the container orchestration command to stop and delete the container; verifying the deletion command exit code to confirm successful container deletion; deleting the resource pool record corresponding to the resource pool identifier in the GPU resource pool table; deleting all GPU allocation records associated with the resource pool identifier in the GPU resource pool details table; deleting all inserted container records in the container table; ensuring consistency between the database state and the physical machine container state; returning an error message indicating container creation failure and terminating the process.

[0092] In one example, the usage status field of the resource pool record is updated to "used," and the container record and resource pool identifier are written to the container resource pool association table to complete cross-physical machine container scheduling, including:

[0093] Verify that the container creation status of all physical machines in the mapping table between physical machines and GPUs is successful. Query the GPU resource pool table by resource pool identifier to obtain the resource pool record object. Call the status field setting method of the resource pool record object to update the usage status field value from unused to used. Perform a database update operation to persist the usage status field and prevent the resource pool from being reused by other container creation requests.

[0094] Iterate through the list of successfully created container names, parse the physical machine identifier from each container name, query the container table based on the container name and physical machine IP address to obtain the container identifier of the container record, construct a container resource pool association record containing the container identifier, resource pool identifier and current timestamp, insert the container resource pool association record into the container resource pool association table, and establish a many-to-one association between containers and resource pools to support the resource pool release operation when a container is deleted.

[0095] In this example, the mapping table between physical machines and GPUs is verified. Each physical machine's container creation result is checked to ensure it is in a successful state. The judgment criteria are based on the command exit code returned by the container control script during deployment and the success flag indicating the insertion of the container record into the container information table. Only when all physical machines return successful deployment results without any abnormal interruption is the container creation process confirmed to be complete globally, and the process proceeds to resource pool status update and container binding information registration. Using the resource pool identifier field passed in the container creation request as the primary key parameter, the GPU resource pool master table is accessed to retrieve the corresponding resource pool record object. After the record object is loaded, its status field setting method is called to update the usage status field value from the original "unused" state (e.g., 0) to the "used" state (e.g., 1) to indicate that the resource pool is occupied. After updating the field value, a database update interface is called, such as the `updateById` method in the Mapper layer, to synchronously persist the updated record to the database with the current resource pool object as the parameter. This achieves synchronous updates of resource occupancy status at the database level, ensuring data consistency and scheduling exclusivity. After updating the resource pool status, the system continues to iterate through the list of successfully created container names. This list was recorded during the deployment phase in the order of container names generated for each physical machine. For each container name in the list, a string parsing operation is performed. For example, using a minus sign "-" as a separator, the physical machine identifier field contained in the naming format is extracted. This physical machine identifier field corresponds to the primary key number of the physical machine used when deploying the container. Combining the parsed physical machine identifier and container name fields, a query condition is constructed to access the container information table. Using the `container_name` and `machine_ip` fields as a composite primary key constraint, the system retrieves the complete container record object corresponding to the container and extracts the unique identifier field `container_id` as the container's logical index. A container resource pool association record data structure is constructed, containing three key fields: the container identifier field `container_id`, the resource pool identifier field `gpu_pool_id`, and the creation timestamp field `create_time`. The timestamp can be obtained from the current system time and is used to record the time when the container and resource pool binding relationship was established. Call the insertion interface of the container resource pool association table to write the constructed association record into the table, completing a binding registration operation between the container and the GPU resource pool. This operation will be repeated on each successfully created container object until all container and resource pool binding records are inserted, establishing a many-to-one logical reference relationship between the container and the resource pool.The many-to-one logical reference relationship plays a role in the container deletion process. When the system receives a container deletion request, it accesses the container resource pool association table based on the container ID to query the associated resource pool identifier and counts whether there are other containers bound to the current resource pool. If there are no remaining associated containers, it performs a reverse update operation on the resource pool status field, restoring it from the "used" state to the "unused" state and releasing the GPU resource pool.

[0096] Reference Figure 2 This embodiment provides a smart computing resource sharing and scheduling device based on non-intrusive technology, including:

[0097] Receive module 1 is used to receive GPU resource pool creation requests and obtain a list of available GPUs, allocate the GPUs in the list of available GPUs to the GPU resource pool details table, and obtain the resource pool identifier;

[0098] Deployment module 2 is used to receive container creation requests containing resource pool identifiers, obtain GPUs from the GPU resource pool details table and group them by physical machine, establish SSH sessions for each physical machine and upload container control scripts to a preset script directory, and obtain SSH sessions with deployed scripts;

[0099] The scheduling module 3 is used to detect the computing card type of the physical machine through the SSH session, generate a container creation command based on the computing card type and GPU device number string, remotely execute the container control script, obtain the container record, and write the container record and resource pool identifier into the container resource pool association table to complete cross-physical machine container scheduling.

[0100] In this embodiment, the specific implementation of each unit in the above device embodiment is described in the above method embodiment, and will not be repeated here.

[0101] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, apparatus, article, or method that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, apparatus, article, or method. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, apparatus, article, or method that includes that element.

[0102] The above description is only a preferred embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent structural or procedural transformations made based on the content of the present invention specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A method for intelligent computing resource sharing and scheduling based on non-intrusive technology, characterized in that, include: Receive a GPU resource pool creation request and obtain a list of available GPUs, allocate the GPUs in the list of available GPUs to the GPU resource pool details table, and obtain the resource pool identifier; The process involves receiving a container creation request containing the resource pool identifier, retrieving GPUs from the GPU resource pool details table and grouping them by physical machine, establishing an SSH session for each physical machine, and uploading the container control script to a preset script directory to obtain an SSH session with deployed scripts. Specifically, this includes: querying the GPU resource pool table based on the resource pool identifier in the container creation request, extracting the usage status field of the resource pool record, determining whether the usage status field value is unused, and verifying the exclusive status of the resource pool; querying the GPU resource pool details table based on the resource pool identifier to obtain a list of GPU identifiers, querying the GPU table based on the GPU identifier list to obtain the physical machine identifier field, traversing the GPU records and grouping them by physical machine identifier, storing each physical machine identifier as a key and the corresponding list of GPU identifiers as a value in a mapping data structure to obtain a mapping table between physical machines and GPUs; traversing the mapping table between physical machines and GPUs, establishing an SSH session for each physical machine, and uploading the container control script to a preset script directory to obtain an SSH session with deployed scripts. The SSH session detects the computing card type of the physical machine, generates a container creation command based on the computing card type and GPU device number string, remotely executes the container control script to obtain a container record, and writes the container record and the resource pool identifier into the container resource pool association table to complete cross-physical machine container scheduling.

2. The intelligent computing resource sharing and scheduling method based on non-intrusive technology according to claim 1, characterized in that, Receive a GPU resource pool creation request and obtain a list of available GPUs. Allocate the GPUs in the list to the GPU resource pool details table to obtain the resource pool identifier, including: Receive a GPU resource pool creation request, query the cluster configuration table based on the cluster identifier in the GPU resource pool creation request, determine whether the isomorphic mode field is true, and if so, extract the cluster identifier; Based on the cluster identifier, query the cluster-physical machine association table to obtain the physical machine identifier list, and then query the GPU table based on the physical machine identifier list to obtain the cluster GPU list; Based on the GPU identifiers in the cluster GPU list, the GPU resource pool details table is queried, the assigned GPU identifiers are filtered and excluded from the cluster GPU list, and the available GPU list is obtained. Based on the available GPU list, a resource pool record is created in the GPU resource pool table, and the GPUs in the available GPU list are allocated to the GPU resource pool details table to obtain the resource pool identifier.

3. The intelligent computing resource sharing and scheduling method based on non-intrusive technology according to claim 2, characterized in that, Based on the available GPU list, a resource pool record is created in the GPU resource pool table. The GPUs in the available GPU list are then allocated to the GPU resource pool details table to obtain the resource pool identifier, including: Query the GPU resource pool table to verify the uniqueness of the resource pool name, insert a resource pool record containing the resource pool name and an initial value of "unused" in the usage status field into the GPU resource pool table, and obtain the resource pool identifier generated by the database auto-incrementing. Initialize the remaining GPU count counter to the number of GPUs in the GPU resource pool creation request, traverse the available GPU list, extract the GPU identifier and combine it with the resource pool identifier to insert into the GPU resource pool details table, decrement the remaining GPU count counter until it reaches zero, and establish the association between the resource pool identifier and the GPU identifier; By querying the GPU table through the GPU identifier in the GPU resource pool details table, the physical machine identifier field is obtained, and a three-layer mapping relationship is established from the resource pool identifier to the GPU identifier to the physical machine identifier.

4. The intelligent computing resource sharing and scheduling method based on non-intrusive technology according to claim 3, characterized in that, The physical machine identifier field is obtained by querying the GPU table through the GPU identifier in the GPU resource pool details table, and a three-layer mapping relationship is established from the resource pool identifier to the GPU identifier to the physical machine identifier, including: Extract all records containing the resource pool identifier from the GPU resource pool details table, obtain the GPU identifier field from each record, and form a GPU identifier list; The GPU identifier list is used as a query condition to retrieve data from the GPU table. The physical machine identifier field of the record corresponding to each GPU identifier is extracted to form a correspondence between GPU identifiers and physical machine identifiers. Based on the association between the resource pool identifier and the GPU identifier in the GPU resource pool details table, and combined with the correspondence between the GPU identifier and the physical machine identifier, a three-layer mapping relationship is established from the resource pool identifier to the physical machine identifier through the GPU identifier.

5. The intelligent computing resource sharing and scheduling method based on non-intrusive technology according to claim 1, characterized in that, Iterate through the mapping table between physical machines and GPUs, establish an SSH session for each physical machine, and upload the container control script to a preset script directory to obtain the SSH session with deployed scripts, including: Traverse the mapping table between physical machines and GPUs to extract the lists of physical machine identifiers and GPU identifiers. Query the physical machine table to obtain the IP address, SSH port, username, and password of the physical machine. Generate a unique container name based on the number of physical machine identifiers and GPU identifiers in the lists. Create an SSH session object and set connection parameters to establish an SSH connection with the physical machine. The SFTP file transfer channel is opened through the SSH connection, the container control script is uploaded to the preset script directory of the physical machine, the command to set the script execution permissions is executed, and an SSH session with the deployed script is obtained.

6. The intelligent computing resource sharing and scheduling method based on non-intrusive technology according to claim 5, characterized in that, The SSH session detects the physical machine's compute card type, generates a container creation command based on the compute card type and GPU device ID string, remotely executes the container control script to obtain a container record, and writes the container record and resource pool identifier into a container resource pool association table to complete cross-physical machine container scheduling, including: Traverse the GPU identifier list, query the GPU table to obtain the device number field, and connect them with commas to form a GPU device number string. Execute the computing card detection command through the SSH session and determine the computing card type based on the command exit code. Based on the computing card type and GPU device number string, a container creation command containing container configuration parameters is constructed. The container control script is remotely executed through the SSH session to generate a container configuration file and start the container. The command exit code is parsed to verify successful container creation. The container configuration information is inserted into the container table to obtain the container record. The usage status field of the resource pool record is updated to "used", and the container record and the resource pool identifier are written into the container resource pool association table to complete cross-physical machine container scheduling.

7. The intelligent computing resource sharing and scheduling method based on non-intrusive technology according to claim 6, characterized in that, Based on the computing card type and GPU device number string, a container creation command containing container configuration parameters is constructed. The container control script is remotely executed via the SSH session to generate a container configuration file and start the container. The command exit code is parsed to verify successful container creation. The container configuration information is inserted into the container table to obtain a container record, including: Extract the image name, number of CPU cores, memory size, and disk space parameters from the container creation request, and combine them with the computing card type, GPU device number string, container name, and physical machine password to construct a container creation command string containing script path, operation parameters, and all configuration parameters; The container creation command string is executed through the SSH session. The container control script generates a container configuration file containing resource limits and GPU device mapping according to the computing card type and calls the container orchestration command to start the container. The command standard output stream and error output stream are read, the command exit code is extracted to determine whether it is a success status, and the container name, image, resource configuration and physical machine information are inserted into the container table to obtain the container record.

8. The intelligent computing resource sharing and scheduling method based on non-intrusive technology according to claim 7, characterized in that, The usage status field of the resource pool record is updated to "used," and the container record and the resource pool identifier are written into the container resource pool association table to complete cross-physical machine container scheduling, including: Verify that the container creation status of all physical machines in the mapping table between physical machines and GPUs is successful. Query the GPU resource pool table through the resource pool identifier to obtain the resource pool record object. Call the status field setting method of the resource pool record object to update the usage status field value from unused to used. Perform a database update operation to persist the usage status field to prevent the resource pool from being reused by other container creation requests. Iterate through the list of successfully created container names, parse the physical machine identifier from each container name, query the container table based on the container name and physical machine IP address to obtain the container identifier of the container record, construct a container resource pool association record containing the container identifier, the resource pool identifier and the current timestamp, insert the container resource pool association record into the container resource pool association table, and establish a many-to-one association between the container and the resource pool to support the resource pool release operation when the container is deleted.

9. A smart computing resource sharing and scheduling device based on non-intrusive technology, characterized in that, The steps for implementing the intelligent computing resource sharing and scheduling method based on non-intrusive technology as described in any one of claims 1 to 8 include: The receiving module is used to receive a GPU resource pool creation request and obtain a list of available GPUs, allocate the GPUs in the list of available GPUs to the GPU resource pool details table, and obtain the resource pool identifier. The deployment module is used to receive a container creation request containing the resource pool identifier, obtain GPUs from the GPU resource pool details table and group them by physical machine, establish an SSH session for each physical machine and upload the container control script to a preset script directory to obtain an SSH session with deployed scripts; The scheduling module is used to detect the computing card type of the physical machine through the SSH session, generate a container creation command based on the computing card type and GPU device number string, remotely execute the container control script to obtain a container record, and write the container record and the resource pool identifier into the container resource pool association table to complete cross-physical machine container scheduling.

Images