Centralized scheduling architecture of large-scale data center network

Abstract

The invention relates to the technical field of data center scheduling, in particular to a centralized scheduling architecture of a large-scale data center network. The invention provides a two-stage scheduling framework which is divided into a local scheduler and a global scheduler, in each Pod, one local scheduler is responsible for the allocation of local link resources, in addition, one global scheduler is responsible for the allocation of global links, all servers need to send requests to the local scheduler in the Pod before sending data packets, and all the servers need to send the requests to the local scheduler in the Pod after sending the data packets. After the permission information of the local scheduler is received, the data packet can be sent according to the time slot and path information in the permission information; according to the invention, the complex large-scale network traffic scheduling task is allocated to a plurality of schedulers, and the cooperative control logic among the schedulers is designed, so that the complex scheduling task can be effectively completed in a large-scale data center network; the problem that the network scale is limited due to the fact that the computing power of a single scheduler is limited in a centralized scheduling type'zero queue 'data center network is effectively solved.

Description

Technical Field

[0001] The present invention relates to the technical field of data center scheduling, and in particular to a centralized scheduling architecture for large-scale data center networks. Background Art

[0002] In recent years, with the rapid development of cloud computing, artificial intelligence, and big data technologies, data centers, the infrastructure supporting these technologies, have seen rapid growth in scale and complexity. However, due to the large scale of networks and the bursty nature of data center traffic, packet paths often conflict, leading to long queues in switches. Packets experience long wait times in switches, resulting in long end-to-end latency.

[0003] To solve this problem, the academic community has proposed introducing a centralized scheduler to perform global scheduling and uniformly plan the transmission timing and transmission paths of all data packets to ensure that the transmission paths of all data packets do not conflict with each other, thereby ensuring that there is no queue accumulation in the switch, avoiding queuing, and thus reducing the end-to-end delay of the data packet.

[0004] Figure 1 This is a centralized scheduling architecture, a two-layer Leaf-Spine architecture. Before transmitting data, the server must request a centralized scheduler. The centralized scheduler then plans the transmission time and path, allowing the server to send data packets according to the planned time and path.

[0005] However, the existing architecture has limited scalability and cannot support the three-tier Fat-tree architecture commonly used in data centers.

[0006] FastPass: A Centralized “Zero-Queue” Datacenter Network is a technical solution that introduces a centralized scheduler into a data center network to achieve “zero queue” in switches. The centralized scheduler controls the packet transmission time and path, including the time slot allocation algorithm and the path selection algorithm.

[0007] FastPass divides time into time slots of equal length. The time slot allocation algorithm selects a set of sending-receiving server pairs from a large number of servers in each time slot, allowing these server pairs to communicate within the time slot. Fastpass uses a method similar to the greedy algorithm. When processing demands, as long as allocating a source-destination pair will not cause a conflict, the scheduler will allocate it. When all demands are processed, a maximum match is obtained, that is, any unallocated demands at this time cannot be allocated. In order to improve processing efficiency, Fastpass uses a pipelined allocator, such as Figure 3Each allocator receives the remaining demand after the previous allocator processes it and calculates the allocation match and the remaining demand for the current time slot.

[0008] Fastpass uses the graph edge coloring algorithm to implement path selection, such as Figure 4 Specifically, the network is modeled as a bipartite graph, where vertices are ToR switches, edges represent packets with assigned time slots, and colors represent core switches or paths. An edge coloring algorithm is used to assign a color to each edge in the graph, ensuring that adjacent edges (i.e., edges connecting the same vertex) have different colors. This ensures that no two packets in the same time slot are assigned to the same core switch or path, thus avoiding link congestion.

[0009] Due to the limited computing power of a single scheduler, the scheduling architecture used by FastPass faces scalability issues, meaning the network's maximum scale is limited. As the number of servers increases, the scheduler's processing power struggles to keep up with the massive volume of transmission requests and routing tasks it must handle, making it unable to effectively address network congestion.

[0010] In summary, the scheduling architecture adopted by existing solutions relies on a single scheduler handling all transmission task requests across the entire network. However, the capacity of a single scheduler is limited, which restricts the scalability of data centers. The maximum number of servers a single scheduler can schedule is in the thousands. Therefore, the data center scalability problem (scalability issue) caused by centralized scheduling solutions is currently an unresolved issue. Summary of the Invention

[0011] Therefore, the technical problem to be solved by the present invention is to overcome the problem in the prior art that the centralized scheduling architecture causes the data center network scale to be limited.

[0012] To solve the above technical problems, the present invention provides a centralized scheduling architecture for a large-scale data center network, including:

[0013] Multiple local schedulers that communicate with each other are distributed in each pod in the data center network. Each local scheduler is responsible for performing link allocation operations within the pod based on traffic requests received from the server or other local schedulers, sending traffic requests to other local schedulers or the global scheduler to perform link allocation operations outside the pod, and finally returning the scheduling results to the server.

[0014] The global scheduler communicates with multiple local schedulers and is used to perform link allocation operations between global Pods based on the traffic requests received from the local schedulers.

[0015] Preferably, the multiple local schedulers communicate with each other through a control plane switch.

[0016] Preferably, the global scheduler and each local scheduler communicate with each other through a control plane switch.

[0017] Preferably, each local scheduler is used to perform link allocation operations within the Pod based on traffic requests received from the server or other local schedulers, and send traffic requests to other local schedulers or the global scheduler to perform link allocation operations outside the Pod, and finally return the scheduling results to the server, including:

[0018] Each local scheduler is used to:

[0019] When the local scheduler of the source Pod receives the traffic request sent by the server, it updates the traffic information table, allocates time slots and uplinks to the traffic demand according to the priority policy, updates the link status, and sends a cross-Pod request to the local scheduler of the destination Pod;

[0020] When the destination Pod's local scheduler receives the cross-Pod request from the source Pod's local scheduler, it queries the link availability based on the cross-Pod request, allocates a downlink link, updates the link status, and sends a core link request to the global scheduler.

[0021] After the local scheduler of the source Pod receives the global inter-Pod link allocation information sent by the global scheduler, it assembles the complete path information, encapsulates the complete path information and time slot information in a control packet, and sends it to the server.

[0022] Preferably, the global scheduler is used to perform link allocation operations between global Pods based on the traffic request received from the local scheduler:

[0023] The global scheduler is used to:

[0024] After receiving the core link request sent by the local scheduler of the destination Pod, it selects the core switch, queries the link availability according to the core link request, allocates global inter-Pod links, updates the link status, and sends the global inter-Pod link allocation information to the local scheduler of the source Pod.

[0025] Preferably, the traffic request sent by the server includes a source address, a destination address and a data size;

[0026] The cross-Pod request sent by the local scheduler of the source Pod includes the requested time slot, source address, destination address and upload link;

[0027] The core link request sent by the local scheduling of the destination Pod includes the requested time slot, source address, destination address, uplink and downlink;

[0028] The global inter-Pod link allocation information sent by the global scheduler to the local scheduler of the source Pod includes time slot information, source address, destination address, uplink, downlink and core switch.

[0029] Preferably, the data center network is a Fat-tree topology data center network.

[0030] Preferably, the uplink is server->edge switch->selected source Pod aggregation switch.

[0031] Preferably, the downlink is a selected destination Pod aggregation switch->edge switch->server.

[0032] Preferably, the complete path information is server->edge switch->selected source Pod aggregation switch->core switch->selected destination Pod aggregation switch->edge switch->server.

[0033] The above technical solution of the present invention has the following advantages over the prior art:

[0034] The centralized scheduling architecture of the large-scale data center network described in the present invention proposes a two-level scheduling framework, which is divided into a local scheduler and a global scheduler. The two schedulers work together to complete complex conflict-free scheduling tasks to ensure that there is no queue accumulation in the switch; each Pod has a local scheduler responsible for the allocation of local link resources, and in addition, there is a global scheduler responsible for the allocation of global links. Before sending data packets, all servers need to send a request to the local scheduler in the Pod. Only after receiving the permission information from the local scheduler can they send data packets according to the time slot and path information in the permission information; the present invention distributes the complex large-scale network traffic scheduling tasks to multiple schedulers, and designs the control logic for the collaboration between these schedulers, which can effectively complete complex scheduling tasks in large-scale data center networks, and effectively solves the problem of limited network scale caused by the limited computing power of a single scheduler in the centralized scheduling "zero queue" data center network. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] In order to make the content of the present invention more clearly understood, the present invention is further described in detail below based on specific embodiments of the present invention in conjunction with the accompanying drawings, wherein:

[0036] Figure 1 It is a schematic diagram of the centralized scheduling structure;

[0037] Figure 2 It is a structural diagram of the centralized scheduler;

[0038] Figure 3 It is a schematic diagram of pipeline time slot allocation;

[0039] Figure 4 Implementing a path selection diagram for the edge coloring algorithm;

[0040] Figure 5 This is a schematic diagram of a centralized scheduling architecture for a large-scale data center network provided by the present invention;

[0041] Figure 6 This is a control flow diagram of two-level scheduling;

[0042] Figure 7 This is a schematic diagram of the Fat-tree topology data center network architecture. DETAILED DESCRIPTION

[0043] The core of the present invention is to provide a centralized scheduling architecture for large-scale data center networks, which effectively solves the problem of limited network scale caused by the limited computing power of a single scheduler in a centralized scheduling "zero queue" data center network.

[0044] In order to enable those skilled in the art to better understand the present invention, the present invention is further described in detail below with reference to the accompanying drawings and specific embodiments. Obviously, the embodiments described are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present invention.

[0045] Please refer to Figure 5 , Figure 5 This is a schematic diagram of a centralized scheduling architecture for a large-scale data center network provided by the present invention; specifically, it includes:

[0046] Multiple communicating local schedulers (LSs) are distributed in each Pod (resource module) of the data center network. Each local scheduler is used to perform link allocation operations within the Pod based on traffic requests received from the server or other local schedulers, send traffic requests to other local schedulers or the global scheduler to perform link allocation operations outside the Pod, and finally return the scheduling results to the server.

[0047] The global scheduler GS communicates with multiple local schedulers and is used to perform link allocation operations between global Pods based on the traffic requests received from the local schedulers.

[0048] The multiple local schedulers communicate with each other through a control plane switch; the global scheduler and each local scheduler communicate with each other through the control plane switch.

[0049] This invention breaks down a complete scheduling task into multiple subtasks, distributing the computational load across multiple LSs and a single GS. Compared to a single-scheduler solution, the multi-scheduler two-level scheduling solution significantly reduces the scheduler load, thus better supporting network expansion.

[0050] When this invention is implemented, existing servers and switches in the data center need to be modified, and multiple centralized schedulers need to be added. Modules for sending requests and receiving permissions need to be added to the server. Switches need to be able to forward packets based on the path information stored in the packet header. The local scheduler needs to receive requests from the server, receive requests from other local schedulers, perform scheduling, and send permission information (scheduling results) to the server; the global scheduler needs to receive requests from local schedulers, allocate global links, and send them to the local schedulers.

[0051] Based on the above embodiment, the control flow of the two-level scheduling is as follows: Figure 6 shown. Specifically:

[0052] When the local scheduler of the source Pod receives the traffic request sent by the server, it updates the traffic information table, allocates time slots and uplinks to the traffic demand according to the priority policy, updates the link status, and sends a cross-Pod request to the local scheduler of the destination Pod;

[0053] When the destination Pod's local scheduler receives the cross-Pod request from the source Pod's local scheduler, it queries the link availability based on the cross-Pod request, allocates a downlink link, updates the link status, and sends a core link request to the global scheduler.

[0054] After receiving the core link request from the local scheduler of the destination Pod, it selects a core switch, queries link availability based on the core link request, allocates global inter-Pod links, updates the link status, and sends the global inter-Pod link allocation information to the local scheduler of the source Pod;

[0055] After the local scheduler of the source Pod receives the global inter-Pod link allocation information sent by the global scheduler, it assembles the complete path information, encapsulates the complete path information and time slot information in a control packet, and sends it to the server.

[0056] Based on the above embodiment, the traffic request sent by the server includes the source address, the destination address and the data size (in bytes);

[0057] The cross-Pod request sent by the local scheduler of the source Pod includes the requested time slot, source address, destination address and upload link;

[0058] The core link request sent by the local scheduling of the destination Pod includes the requested time slot, source address, destination address, uplink and downlink;

[0059] The global inter-Pod link allocation information sent by the global scheduler to the local scheduler of the source Pod includes time slot information, source address, destination address, uplink, downlink and core switch.

[0060] The centralized scheduling architecture of large-scale data center networks proposed in this invention can be applied to the most common Fat-tree topology in data center networks, such as Figure 7 shown; specifically:

[0061] Multiple local schedulers that communicate with each other are distributed in each pod of the fat-tree topology data center network. Each local scheduler is used to perform link allocation operations within the pod based on traffic requests received from the server or other local schedulers, send traffic requests to other local schedulers or the global scheduler to perform link allocation operations outside the pod, and finally return the scheduling results to the server.

[0062] The global scheduler communicates with multiple local schedulers and is used to perform link allocation operations between global Pods based on the traffic requests received from the local schedulers.

[0063] When the source Pod's local scheduler receives the traffic request (including source / destination addresses and data size) from the server, it updates the traffic information table and allocates an available time slot for the traffic demand based on the priority policy (the link from server to edge switch must be available under this time slot). It then allocates an available aggregation switch based on the time slot, obtains the uplink (server to edge switch to the selected source Pod aggregation switch), updates the link state, and sends a cross-Pod request (including the requested time slot, source / destination addresses, and the selected source Pod aggregation switch) to the destination Pod's local scheduler.

[0064] When the destination pod's local scheduler receives the cross-pod request from the source pod's local scheduler, it queries link availability based on the cross-pod request (checking whether the edge switch -> server link is available in the requested time slot). It then allocates an available aggregation switch based on the time slot, obtains the downlink link (selecting the destination pod's aggregation switch -> edge switch -> server), updates the link status, and sends a core link request to the global scheduler.

[0065] After receiving the core link request (requested time slot, source / destination address, and aggregation switch assigned to the source / destination Pod) from the local scheduler of the destination Pod, the core switch is selected based on the source / destination aggregation switch. Link availability is checked based on the core link request (checking whether the inter-Pod link from the source aggregation switch to the core switch to the destination aggregation switch is available in the requested time slot). A global inter-Pod link is allocated, the link status is updated, and the global inter-Pod link allocation information (time slot, source / destination address, source / destination Pod aggregation switch, and core switch) is sent to the local scheduler of the source Pod.

[0066] When the local scheduler of the source Pod receives the global inter-Pod link allocation information sent by the global scheduler, it assembles the complete path information (server->edge switch->selected source Pod aggregation switch->core switch->selected destination Pod aggregation switch->edge switch->server), encapsulates the complete path information and time slot information in a control packet, updates the flow table, and finally sends the control packet to the server.

[0067] To address the scalability challenges faced by traditional centralized data center scheduling due to the limited computing power of a single scheduler, this paper designs a two-level scheduling scheme: a local scheduler and a centralized scheduler. Local schedulers are responsible for local link resource allocation, while a global scheduler handles global link resource allocation. This offloads complex global scheduling tasks to multiple schedulers, effectively reducing the load on a single scheduler. This allows for network scalability and achieves "zero queue" switching within a three-tier network architecture like a fat-tree.

[0068] Unlike existing technologies, where a single scheduler plans the time and path for global traffic, thus only supporting small-scale (two-tier networks) data centers, this invention distributes global traffic scheduling tasks among multiple schedulers. Specifically, it employs a two-level scheduling structure consisting of multiple local schedulers and a global scheduler, and incorporates practical interactive control logic. After several defined steps, traffic can be sent without conflict across the entire network, achieving "zero queues" in large-scale (three-tier) networks.

[0069] This paper designs a two-level scheduling architecture for large-scale "zero-queue" data center networks. In this architecture, each pod has a local scheduler that collects traffic information, distributes authorization information, allocates link resources within the pod, and interacts with other local schedulers and the global scheduler. A global scheduler allocates global links and interacts with all local schedulers. The paper also designs a complete and effective control flow: server -> local scheduler 1 -> local scheduler 2 -> global scheduler -> local scheduler 1 -> server, forming a complete control logic. This control flow completes the planning of global traffic transmission time and path.

[0070] To address the limited network scale caused by the limited computing power of a single scheduler in a centralized "zero-queue" data center network, this paper designs a two-level scheduling structure that collaborates with a local scheduler and a global scheduler. This structure distributes the complex large-scale network traffic scheduling tasks across multiple schedulers, and designs control logic for the collaboration between these schedulers. This effectively completes complex scheduling tasks in a large-scale three-layer fat-tree network. As a result, the scheduler is no longer the bottleneck of centralized "zero-queue" data center networks, allowing the scale of such data center networks to be expanded.

[0071] While designed for packet switches, this invention can also be applied to optical switching networks. The corresponding changes involve sending the control packet sent by the scheduler to the server to the optical switch controller to control the optical path changes of the optical switch. Furthermore, the time slots must be determined based on the reconfiguration delay of the optical switch.

[0072] The present invention can also be used in other three-layer topologies, such as Dragonfly+, and global link resources only need to be allocated according to the connection mode between the aggregation switches in Dragonfly+.

[0073] Obviously, the above embodiments are merely examples for clarity of explanation and are not intended to limit the implementation methods. Those skilled in the art will appreciate that other variations or modifications can be made based on the above description. It is not necessary and impossible to enumerate all implementation methods here. Obvious variations or modifications arising therefrom remain within the scope of protection of the present invention.

Claims

1. A centralized scheduling architecture for a large-scale data center network, characterized in that: include: Multiple local schedulers that communicate with each other are distributed in each pod in the data center network. Each local scheduler is responsible for performing link allocation operations within the pod based on traffic requests received from the server or other local schedulers, sending traffic requests to other local schedulers or the global scheduler to perform link allocation operations outside the pod, and finally returning the scheduling results to the server. The global scheduler communicates with multiple local schedulers and is used to perform link allocation operations between global Pods based on the traffic requests received from the local schedulers.

2. The centralized scheduling architecture for large-scale data center networks according to claim 1, characterized in that: The multiple local schedulers communicate with each other through a control plane switch.

3. The centralized scheduling architecture for large-scale data center networks according to claim 1, characterized in that: The global scheduler and each local scheduler communicate with each other through a control plane switch.

4. The centralized scheduling architecture for large-scale data center networks according to claim 1, characterized in that: Each local scheduler is used to perform link allocation operations within the Pod based on traffic requests received from the server or other local schedulers, and send traffic requests to other local schedulers or the global scheduler to perform link allocation operations outside the Pod. Finally, the scheduling results returned to the server include: Each local scheduler is used to: When the local scheduler of the source Pod receives the traffic request sent by the server, it updates the traffic information table, allocates time slots and uplinks to the traffic demand according to the priority policy, updates the link status, and sends a cross-Pod request to the local scheduler of the destination Pod; When the destination Pod's local scheduler receives the cross-Pod request from the source Pod's local scheduler, it queries the link availability based on the cross-Pod request, allocates a downlink link, updates the link status, and sends a core link request to the global scheduler. After the local scheduler of the source Pod receives the global inter-Pod link allocation information sent by the global scheduler, it assembles the complete path information, encapsulates the complete path information and time slot information in a control packet, and sends it to the server.

5. The centralized scheduling architecture for large-scale data center networks according to claim 4, characterized in that: The global scheduler is used to perform link allocation operations between global Pods based on the traffic requests received from the local scheduler: The global scheduler is used to: After receiving the core link request sent by the local scheduler of the destination Pod, it selects the core switch, queries the link availability according to the core link request, allocates global inter-Pod links, updates the link status, and sends the global inter-Pod link allocation information to the local scheduler of the source Pod.

6. The centralized scheduling architecture for large-scale data center networks according to claim 5, characterized in that: The traffic request sent by the server includes a source address, a destination address and a data size; The cross-Pod request sent by the local scheduler of the source Pod includes the requested time slot, source address, destination address and upload link; The core link request sent by the local scheduling of the destination Pod includes the requested time slot, source address, destination address, uplink and downlink; The global inter-Pod link allocation information sent by the global scheduler to the local scheduler of the source Pod includes time slot information, source address, destination address, uplink, downlink and core switch.

7. The centralized scheduling architecture for large-scale data center networks according to claim 6, characterized in that: The data center network is a Fat-tree topology data center network.

8. The centralized scheduling architecture for large-scale data center networks according to claim 7, characterized in that: The uplink is server->edge switch->selected source Pod aggregation switch.

9. The centralized scheduling architecture for large-scale data center networks according to claim 8, characterized in that: The downlink is the selected destination Pod aggregation switch -> edge switch -> server.

10. The centralized scheduling architecture for large-scale data center networks according to claim 9, characterized in that: The complete path information is server->edge switch->selected source Pod aggregation switch->core switch->selected destination Pod aggregation switch->edge switch->server.

Images