Resource Topology Generation for a Computer System

Abstract

A virtual topology is provided in response to a partitioning request. The virtual topology is a synchronous subgraph of the physical topology. The synchronous subgraph virtual topology mirrors the physical topology in terms of a tree structure. However, simply sharing the physical topology with users / customers is not feasible because it may expose additional infrastructure details such as MAC addresses, IP addresses, and the like, thereby compromising security and / or exposing multi-tenant operation to risks. The disclosed embodiments create a virtual topology structure with obfuscated node data such that important data such as physical IP addresses and / or MAC addresses are hidden from end users. Therefore, the disclosed embodiments provide the benefits of performance improvement resulting from sharing the topology without the drawback of compromising security by exposing physical topology details.

Description

Technical Field

[0001] The present invention generally relates to computer systems, and more specifically, to resource topology generation for computer systems.

Background Art

[0002] Today's enterprise organizations have increasingly relied on cloud-based infrastructure, platforms, and applications to provide highly important capabilities and services to the organization and its customers. Cloud computing helps IT organizations operate more efficiently by reducing initial capital costs while providing flexible capabilities for data storage, processing, and other functions.

[0003] As organizations migrate existing applications to the cloud and develop new capabilities that rely on cloud-based infrastructure, effective management of cloud-based resources has become an increasingly challenging problem for enterprises of all sizes. Cloud orchestration is a class of software tools designed to enable on-demand resource allocation by helping to distribute resources such as containers, virtual machines, and other resources to specific execution tasks.

Summary of the Invention

[0004] In one embodiment, a computer-implemented method for scheduling a set of computing resources, wherein the organizational structure of the computing resources is represented by a physical topology, the method comprising: receiving a distribution request for a virtual cluster, wherein the virtual cluster includes a plurality of virtual server instances and the distribution request includes at least one placement constraint; identifying at least one physical computing resource from the physical topology for distributing the virtual cluster; constructing a virtual topology of the virtual cluster, wherein the virtual topology is a synchronous subgraph of the physical topology; and providing placement information for the plurality of virtual server instances based on the virtual topology and the at least one placement constraint.

[0005] In another embodiment, an electronic computing device comprising: a processor; and a memory coupled to the processor, the memory storing instructions that, when executed by the processor, schedule a set of computing resources, wherein the organizational structure of the computing resources is represented by a set of physical computing resources arranged in a physical topology, the instructions causing the electronic computing device to perform procedures for: receiving a distribution request for a virtual cluster, wherein the virtual cluster includes a plurality of virtual server instances and the distribution request includes at least one placement constraint; identifying at least one physical computing resource from the physical topology for distributing the virtual cluster; constructing a virtual topology of the virtual cluster, wherein the virtual topology is a synchronous subgraph of the physical topology; and providing placement information for the plurality of virtual server instances based on the virtual topology and the at least one placement constraint.

[0006] In another embodiment, there is provided a computer program product for an electronic computing device comprising a computer-readable storage medium embodying program instructions, the program instructions causing the electronic computing device to perform procedures for: receiving a distribution request for a virtual cluster, where the virtual cluster includes a plurality of virtual server instances and the distribution request includes at least one placement constraint; identifying at least one physical computing resource from a physical topology for distributing the virtual cluster; constructing a virtual topology for the virtual cluster, where the virtual topology is a synchronous subgraph of the physical topology; and providing placement information for the plurality of virtual server instances based on the virtual topology and the at least one placement constraint, the procedures being executable by a processor.

Brief Description of the Drawings

[0007]

Figure 1

[0008]

Figure 2

[0009]

Figure 3

[0010]

Figure 4

[0011]

Figure 5

[0012] The drawings are not necessarily to scale. The drawings are merely illustrative and are not necessarily intended to depict specific parameters of the invention. The drawings are intended to depict only exemplary embodiments of the invention and should therefore not be regarded as limiting the scope. In the drawings, like reference numerals may represent like elements. Further, certain elements in some of the figures may be omitted or not shown to scale for clarity of illustration.

Best Mode for Carrying Out the Invention

[0013] The disclosed embodiments provide techniques for scheduling a set of computing resources where the organizational structure of the computing resources is represented by a physical topology. These techniques include receiving a distribution request for a virtual cluster, identifying one or more physical computing resources from the physical topology to distribute the virtual cluster, and constructing a virtual topology of the virtual cluster, where the virtual topology is a synchronous subgraph of the physical topology.

[0014] When tasks / processes are not placed correctly, an application may suffer performance degradation. As an example, when a user / customer deploys a virtual private cloud (VPC), the user / customer may run a wide variety of applications. If an application has performance constraints, it may be beneficial to have knowledge of where virtual server instances (VSIs) in the VPC are actually placed so that the user / customer can run their workload as efficiently as possible.

[0015] The configuration group aims to give the customer the possibility to create a VPC with a VSI configuration in mind. Due to multi-tenancy, there may be cases where the cloud provider cannot place the exact number of VSIs in the exact way the customer requests, and thus a sub-optimal solution is necessarily found. Assuming that the placement may be sub-optimal, it is even more important for the customer to actually know how the VSIs are placed in order to plan how to run their workloads in the most efficient mode possible. Embodiments can include providing placement information for a plurality of virtual server instances based on a virtual topology and at least one placement constraint. The placement information can be used to enable applications to run more efficiently by leveraging affinities within a virtual cluster. Jobs and tasks that benefit from affinities can be scheduled on the most suitable virtual instances based on the provided placement information.

[0016] The disclosed embodiments provide a virtual topology in response to a distribution request. The virtual topology is a synchronous subgraph of a physical topology. The virtual topology synchronous subgraph mirrors the physical topology in terms of a tree structure. As an example, to fulfill a distribution request, if the physical topology includes six servers in use on a first rack and three servers in use on a second rack, the virtual topology also shows six servers on the first rack and three servers on the second rack. However, simply sharing the physical topology with a user / customer is not feasible because it may expose additional infrastructure details such as MAC addresses, IP addresses, and the like, thereby compromising security and / or exposing multi-tenant operations to risk. The disclosed embodiments create a virtual topology structure with obfuscated node data such that important data such as physical IP addresses and / or MAC addresses are hidden from end users. The virtual topology is a subgraph of the physical topology that holds an organizational layer to form a connected topology. Therefore, the disclosed embodiments provide the benefits of performance improvement resulting from sharing the topology without the drawback of compromising security by exposing physical topology details.

[0017] References throughout this specification to "one embodiment," "an embodiment," "some embodiments," or similar language mean that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, appearances of the phrases "in one embodiment," "in an embodiment," "in some embodiments," and similar language throughout this specification are not necessarily all referring to the same embodiment.

[0018] Furthermore, the features, structures, or characteristics described in the present invention may be combined in any suitable manner in one or more embodiments. It will be apparent to those skilled in the art that various changes and modifications can be made to the present invention without departing from the scope and purpose of the present invention. Therefore, the present invention is intended to encompass such changes and modifications as long as they fall within the scope of the appended claims and their equivalents. Here, reference will be made in detail to the preferred embodiments of the present invention.

[0019] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the present disclosure. As used herein, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly dictates otherwise. Furthermore, the use of terms such as "a" and "an" does not indicate a limitation of quantity, but rather indicates the presence of at least one of the items being referred to. The term "set" is intended to mean at least one quantity. It will be further understood that the terms "comprises", "comprising", "includes", "including", "has", and "having", when used herein, specify the presence of the features, regions, integers, steps, operations, elements, and / or components referred to, but do not preclude the presence or addition of one or more other features, regions, or elements.

[0020] The disclosed embodiments can be used in cloud computing, but it should be understood that the implementation of the teachings described herein is not limited to a cloud computing environment. Rather, embodiments of the present invention can be implemented in combination with any other type of computing environment now known or later developed.

[0021] Cloud computing is a service delivery model that enables convenient on-demand network access to a shared pool of configurable computing resources (such as networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal management effort or interaction with a service provider. This cloud model can include at least five characteristics, at least three service models, and at least four deployment models.

[0022] The characteristics are as follows.

[0023] On-demand self-service: A cloud consumer can unilaterally provision computing capabilities such as server time and network storage automatically as needed, without requiring human interaction with the service provider.

[0024] Broad network access: The capabilities are available over the network and accessed through standard mechanisms that promote use by heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, and PDAs).

[0025] Resource pooling: The provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned according to demand. Consumers generally have no control or knowledge over the exact location of the provided resources, but location independence exists in that it may be possible to specify location at a higher level of abstraction (e.g., country, state, or data center).

[0026] Rapid elasticity: The ability can provision quickly and elastically, and in some cases automatically, scale out urgently, and release quickly to scale in urgently. For consumers, in many cases, the available capacity for provisioning seems unlimited and can be purchased in any amount at any time.

[0027] Measured services: Cloud systems automatically control and optimize resource usage by leveraging measurement capabilities at an appropriate level of abstraction for service types (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency to both the providers and consumers of the services utilized.

[0028] The service model is as follows.

[0029] Software as a Service (SaaS): The ability provided to consumers is to use the provider's applications running on the cloud infrastructure. The applications are accessible from various client devices through a client interface such as a web browser (e.g., web-based email). Consumers do not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, storage, or even the individual application capabilities, except for limited user-specific application configuration settings as possible exceptions.

[0030] Platform as a Service (PaaS): The capabilities provided to consumers are to deploy applications created or acquired by consumers, which are created using programming languages and tools supported by the provider on a cloud infrastructure. Consumers do not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, or storage, but control the deployed applications and, in some cases, the application host environment configuration.

[0031] Infrastructure as a Service (IaaS): The capabilities provided to consumers are to provision processing, storage, networks, and other basic computing resources, where consumers can deploy and run any software that can include operating systems and applications. Consumers do not manage or control the underlying cloud infrastructure, but control the operating systems, storage, deployed applications, and, in some cases, limited control over selected networked components (e.g., host firewalls).

[0032] The deployment models are as follows.

[0033] Private cloud: This cloud infrastructure operates only for a certain organization. It may be managed by that organization or a third party and can exist on-premises or off-premises.

[0034] Community Cloud: This cloud infrastructure is shared by several organizations and supports a specific community with shared concerns (e.g., mission, security requirements, policies, and compliance considerations). It may be managed by these organizations or a third party and can exist on-premises or off-premises.

[0035] Public Cloud: This cloud infrastructure is made available to the general public or a large industry group and is owned by an organization that sells cloud services.

[0036] Hybrid Cloud: This cloud infrastructure is a composite of two or more clouds (private, community, or public), where the two or more clouds remain separate entities but are joined together by standard or proprietary technologies that enable data and application portability (e.g., cloud bursting for load balancing between clouds).

[0037] The cloud computing environment is service-oriented, focusing on statelessness, loose coupling, modularity, and semantic interoperability. At the core of cloud computing is an infrastructure that includes a network of interconnected nodes.

[0038] FIG. 1 is an environment 100 for an embodiment of the present invention. A Computer Resource Allocation System (CRAS) 102 includes a processor 140, a memory 142 coupled to the processor 140, and a storage 144. The system 102 is an electronic computing device. The memory 142 stores program instructions 147 that, when executed by the processor 140, execute the processes, techniques, and implementations of the disclosed embodiments. The memory 142 may include dynamic random-access memory (DRAM), static random-access memory (SRAM), magnetic storage, and / or read-only memory, such as flash, EEPROM, optical storage, or other suitable memory, and should not be construed as being the transient signals themselves. In some embodiments, the storage 144 may include one or more magnetic storage devices, such as a hard disk drive (HDD). The storage 144 may additionally include one or more solid state drives (SSD). The CRAS 102 is configured to interact with other elements of the environment 100. The CRAS 102 is connected to a network 124, which may be the Internet, a wide area network, a local area network, or other suitable network.

[0039] The environment 100 may include one or more client devices shown as 116. The client device 116 may include a laptop computer, a desktop computer, a tablet computer, a smartphone, or other suitable computing device. The client device 116 may be used to configure the CRAS 102.

[0040] Four computers implementing a cluster of nodes are also shown as being connected to the network. These computers are Host 1 120, Host 2 130, Host 3, 139, and Host N 150. Host 1 120, Host 2 130, Host 3, 139, and Host N 150 are computer systems (host machines) that can include one or more containers, one or more virtual machines (VMs), a Graphics Processing Unit (GPU), and / or one or more natively-executed applications thereon. These host machines typically include a processor (or processors), memory, and instructions thereon and are self-sufficient. The processor can store multiple cores. Host 1 120, Host 2 130, Host 3, 139, and Host N 150 are each computers that implement the cluster together.

[0041] Host 1 includes instances of three containers: Container 1 122, Container 2 124, and Container 3 126. A container image is a lightweight, stand-alone executable package of software that includes everything needed to execute a role that includes one or more tasks. A container can include code, a runtime library, system tools, system libraries, and / or configuration settings. Containerized software operates with a certain degree of independence from the host machine / environment. Therefore, a container functions to isolate software from its surroundings. Container 1 122 and Container 2 124 are running within virtual machine 131. Container 3 126 is running within virtual machine 133.

[0042] Host 2 130 includes instances of virtual machines that are running containers. The containers are Container 1 138, Container 2 142, and Container 3 144. The virtual machines are VM2 132 and VM1 134. Container 3 144 is running within virtual machine 134. Container 1 138 and Container 2 142 are running within virtual machine 132.

[0043] Host 3 is running native 1 application 136. Application 136 is a native application, operating system, native instruction set, or other native program that is specifically implemented for a particular model of computer or microprocessor, rather than in emulation or compatibility mode.

[0044] Host N includes instances of four virtual machines: VM2 154, VM1 152, VM3 156, and VM4 158. A virtual machine (VM) is an operating system or application environment installed as software that emulates dedicated hardware. By emulating dedicated hardware, the virtual machine provides the end user with an experience on the virtual machine that is the same as what would be obtained on dedicated hardware.

[0045] Host N further includes GPU1 shown as 171 and GPU2 shown as 173. GPUs are used in a wide range of applications, including graphics and video rendering. GPUs are also becoming more popular for use in creative production and artificial intelligence (AI).

[0046] In some embodiments, the host can include only a single type of environment, such as a container, a virtual machine, or a native application. Alternatively, the host can include multiple such things, as in the example of Host 2. In some cases, instances of containers, virtual machines, or native applications can be replicated on more than one host. This is shown here as the first instances of Container 1 122, Container 2 124, and Container 3 126 on Host 1 120, and the second instances of each are Container 1 138, Container 2 142, and Container 3 144 on Host 2. Additionally, the first instances of VM2 132 and VM1 134 are on Host 2 130, and the second instances of VM2 154 and VM1 152 are on Host N 150.

[0047] The computing resources shown in this example are managed by CRAS102. CRAS102 can use one or more programs to deploy, scale, and manage machines and software in a cluster as an orchestration environment. Non-limiting examples of such programs / systems are Kubernetes, Apache Hadoop, and Docker. Applications operating on such systems can include database applications such as the Oracle database system that utilizes a structured query language (SQL) database. Note that the terms "KUBERNETES," "ORACLE," "APACHE," "HADOOP," and "DOCKER" can each be the subject of trademark rights in various jurisdictions around the world. Here, each is used only with reference to the products or services appropriately designated by the marks to the extent that such trademark rights may exist.

[0048] In an embodiment, the CRAS may receive a distribution request for resources. Various attributes and / or metadata can be associated with the distribution request. The attributes can include, but are not limited to, the number of virtual units (VUs), the affinity type for one or more levels within the physical topology, and / or the virtual unit type. In an embodiment, a VU can include, but is not limited to, a virtual machine (VM), a container, a graphics processing unit (GPU), and / or a native machine (NM). In a native machine and / or a GPU instance, an application can execute "bare metal" without a virtual machine or a container and instead operate directly on the physical topology hardware. In an embodiment, computing resources include at least one of a virtual machine, a container, a native machine, and a graphics processing unit (GPU).

[0049] In some embodiments, the distribution request may include a flexibility attribute. In an embodiment, the flexibility attribute can have a hard or soft value. A hard value indicates that the request must be fulfilled as specified in order to be accepted. As an example, if a distribution request has four virtual units with rack-level pack affinity and specifies a hard flexibility, the requirements for the request to be accepted must be met. Conversely, if a distribution request has four virtual units with rack-level pack affinity and specifies a soft flexibility, a sub-optimal request may be accepted. With soft flexibility, even if a distribution request specifies four virtual units with rack-level pack affinity, an actual distribution with three virtual units with rack-level pack affinity and one virtual unit on another rack may be accepted.

[0050] Figure 2 shows a flowchart 200 for an embodiment of the present invention. At 202, an infrastructure topology is obtained. This can include querying the physical infrastructure via SNMP or other suitable management protocols to determine available computer resources. At 204, a physical topology is created. This can include indicating each level of the hierarchy for given resources such as rooms, racks, servers, and the like. At 206, the current resource allocation is determined. This can include querying resources via SNMP and / or other APIs to determine the utilization rate of given computer resources. At 208, an available physical topology is created. The available physical topology can be based on the topology obtained at 202, except that the resource counter is changed to indicate available resources. Steps 202-208 are preprocessing steps that are executed prior to receiving a distribution request.

[0051] At 220, a distribution request is received. The distribution request can include placement constraints, level constraints, affinity settings, and flexibility options, VU quantity, and other information. Other constraints may be included in the distribution request. Additional constraints may be related to performance and resource imbalance, for example, in the scheduling for nodes having different types of CPUs, memory, accelerators, and bandwidth, etc. Other constraints can include, for example, software license granting conditions for applications where only certain types of nodes, or only a part of the infrastructure, are eligible to execute a particular software package.

[0052] At 222, tasks are assigned to physical resources. These can include servers, GPUs, and / or specific cores within a server. At 224, a virtual topology synchronization sub-graph is constructed. The virtual topology synchronization sub-graph is a virtual topology that mirrors the physical topology in terms of affinity and the overall tree hierarchy. At 226, the virtual topology synchronization sub-graph is sent to the requester. In an embodiment, the virtual topology synchronization sub-graph is sent as a graph description language file, e.g., a DOT language file, or other suitable representation for a tree topology. The requester can accept or reject the request. The requester can utilize the virtual topology synchronization sub-graph for performing optimizations during execution. For example, by knowing that a set of n computing nodes are closer to each other from a network perspective, those n computing nodes can be a better fit for applications with latency constraints. Therefore, the disclosed embodiments improve the technical field of computing by enabling optimizations for applications with latency constraints, thereby reducing execution time and saving computer resources.

[0053] Figure 3 shows a tree structure 300 for a physical topology according to an embodiment of the present invention. The tree structure 300 has levels indicated by column 331. Column 333 indicates the ordinal numbers assigned to each level. Generally, the highest level is shown as the root. Below the root at level 4 are zones at level 3. A zone can be a geographical area, a specific data center, or other area storing a plurality of computing resources. Below the zones at level 3 are rooms at level 2. In an embodiment, the room level can represent a specific room or section of a data center. Below the rooms at level 2 are racks at level 1. A rack can represent a specific rack within a data center. A rack can be an open frame structure or a cabinet. In an embodiment, a rack is sized to store 19-inch (48.26 cm) rack-mountable equipment of standard size using 1.75-inch (4.445 cm) standard rack units (RU). In some embodiments, a rack has a height of 42RU at 73.5 inches (186.69 cm). Below the racks at level 1 are servers at level 0. A server represents a physical computing device installed within a rack. A server stores one or more processors. A server can directly execute an application on one or more of its processors. A server can execute an application within a virtual machine and / or container running on the server. Although five levels are shown in the tree structure 300, other embodiments may include more, fewer, and / or different levels. For example, some embodiments may include a level -1 representing cores within a server. The physical topology can be arranged in a sufficient number of levels to provide an appropriate granularity for scheduling computing tasks.

[0054] Figure 4 shows a tree structure for a virtual topology according to an embodiment of the present invention. The tree structure shown in Figure 4 is best understood with reference to legend 420. The nodes of the tree structure are represented as circles. Inside each circle, a node name 424 is shown. The number of available resources (slots) within a particular node is shown using a number directed towards the upper right vicinity of the circle.

[0055] The tree structure 400 represents a physical topology. The physical topology represents the amount of available physical resources. As can be seen from the tree structure 400, zone Z-0 includes nine computing resources (slots) stored within racks R-0 and R-1. Rack R-0 stores six computing resources. Rack R-1 stores three computing resources. Rack R-0 includes three servers shown as servers S-0, S-1, and S-2. Server S-0 has one computing resource, server S-2 has two computing resources, and server S-3 has three computing resources. Referring now to rack R-1, server S-3 has two computing resources and server S-4 has one computing resource (slot). In an embodiment, a slot refers to an amount of available CPU cycles, memory, and / or other computing resources required to support virtual units such as virtual machines, containers, or the like.

[0056] The disclosed embodiments create an updated physical topology and a virtual topology synchronization subgraph in response to a distribution request. An example of a distribution request for a virtual cluster is shown at 417. The distribution request 417 can include a size field indicating the number of requested computing resources (VUs) at 441. The embodiments allocate one VU to one slot to satisfy the distribution request. Therefore, in the embodiments, there is a one-to-one relationship between virtual units and slots.

[0057] The allocation request 417 can include, at 444, a level field indicating the level to which the constraint applies. In the example shown in FIG. 4, the level indicated in field 444 is a rack. The allocation request 417 can include, at field 445, an affinity related to the level specified in field 444. In the example shown in FIG. 4, the affinity in field 445 is set to a pack, which indicates a pack affinity at the rack level. The allocation request 417 can include, at 446, another level field indicating the level to which the constraint applies. In the example shown in FIG. 4, the level indicated in field 446 is a server. The allocation request 417 can include, at field 447, an affinity related to the level specified in field 446. In the example shown in FIG. 4, the affinity in field 447 is set to a pack, which indicates a pack affinity at the server level. The exemplary allocation request 417 shown in FIG. 4 shows constraints for two levels, but in practice, there may be constraints for more or fewer levels. In an embodiment, the placement constraint is defined as a set of level constraints and may include either a spread or a pack policy at a particular level.

[0058] Pack affinity implies that computing resources preferably be as close to each other as possible. In some cases, this may be for performance reasons, for example, to minimize latency in communication and data sharing among computing resources. In an embodiment, to process a pack affinity request, the algorithm implemented by CRAS102 (FIG. 1) traverses the nodes of the tree structure 400 in order of most available resources. In the example of FIG. 4, this is represented at node S-2 within the tree structure 400, which has three available slots. The size at 441 specifies four resources. CRAS allocates three available slots on S-2. One resource from the request still needs to be placed. CRAS then identifies the next node with the most available resources, which is S-1 having two resources. CRAS allocates one of those resources to the request. CRAS then creates the updated physical topology at 450.

[0059] Referring now to tree 450, the root Z-0 shows five available slots here, and the rack R-0 shows two available slots. Servers S-1 and S-2 are drawn as shaded circles indicating the placement of the requested computing resources. Based on fulfilling the allocation request 417, server S-1 shows one available slot and server S-2 shows zero available slots.

[0060] Next, CRAS102 (FIG. 1) generates a virtual topology synchronization subgraph 470. The virtual topology synchronization subgraph 470 is obfuscated node data that mirrors the topology of the allocated resources shown in tree 450. Referring to tree 450 here, node Q-0 represents a zone, similar to zone Z-0. Node Y-0 represents a rack, similar to rack R-0. Server X-1 represents a server, similar to server S-1 in tree 450. Server X-2 represents a server, similar to server S-2 in tree 450. The node data can be obfuscated to avoid disclosing proprietary information about physical computing resources. As an example, the MAC address may be changed or edited to avoid disclosing details about vendor equipment, and the IP address may be changed or edited to avoid disclosing details about location and / or other information that may adversely affect cybersecurity. In this way, the underlying topology is provided to the requester without disclosing proprietary details. This provides the requester with an opportunity to optimize jobs or programs for execution on the provided resources. As an example, processes that share large amounts of data with each other can be deployed on virtual machines VM0, VM1, and VM2, while other processes with lower I / O intensity can be deployed on VM3. In this way, the overall performance of program execution can be improved using the disclosed embodiments of the present invention.

[0061] In an embodiment, the allocation request includes one or more placement constraints. In an embodiment, the one or more placement constraints include affinity. In an embodiment, the one or more placement constraints include rack-level constraints. In an embodiment, the one or more placement constraints include server-level constraints. In an embodiment, the virtual topology stores obfuscated node data. In an embodiment, the virtual topology is generated by processing nodes in order of most available resources. In an embodiment, at least one placement constraint includes room-level constraints. In an embodiment, at least one placement constraint includes zone-level constraints. Zone-level constraints can be useful in certain applications, such as financial applications, that benefit from low latency based on servers physically located in a particular area.

[0062] FIG. 5 shows a tree structure for a virtual topology according to an additional embodiment of the present invention. The tree structure shown in FIG. 5 is best understood with reference to legend 520. The nodes of the tree structure are represented as circles. A node name 524 is shown inside each circle. The number of free resources (slots) 522 within a particular node is shown using a number directed towards the upper right side of the circle.

[0063] The tree structure 500 represents a physical topology. The physical topology represents the amount of available physical resources. As can be seen from the tree structure 500, zone Z-0 includes nine computing resources (slots) stored within racks R-0 and R-1. Rack R-0 stores six computing resources. Rack R-1 stores three servers. Rack R-0 includes three servers shown as servers S-0, S-1, and S-2. Server S-0 has one computing resource, server S-2 has two computing resources, and server S-3 has three computing resources. Referring now to rack R-1, server S-3 has two computing resources and server S-4 has one computing resource.

[0064] The disclosed embodiments create an updated physical topology and a virtual topology synchronization subgraph in response to a distribution request. An example of a distribution request for a virtual cluster is shown at 517. The distribution request 517 can include a size field indicating the number of requested computing resources (VUs) at 541. The distribution request 517 can include a level field indicating the level to which the constraint applies at 544. In the example shown in FIG. 5, the level indicated in field 544 is a rack. The distribution request 517 can include an affinity related to the level specified in field 544 in field 545. In the example shown in FIG. 5, the affinity in field 545 is set to a pack, which indicates a pack affinity at the rack level. This implies that it is desired to execute all processes of request 517 within the same rack. Hard or soft flexibility parameters can be used to determine whether a sub-optimal distribution is acceptable. Generally, this is application-dependent and is selected by the requester based on the context of the application.

[0065] The distribution request 517 can include another level field indicating the level to which the constraint applies at 546. In the example shown in FIG. 5, the level indicated in field 546 is a server. The distribution request 517 can include an affinity related to the level specified in field 546 in field 547. In the example shown in FIG. 5, the affinity in field 547 is set to spread, which indicates a spread affinity at the server level. In the present disclosure, the spread affinity can also be referred to as an anti-affinity. The exemplary distribution request 517 shown in FIG. 5 shows constraints for two levels, but in practice, there can be constraints for more or fewer levels.

[0066] Spread affinity implies that computing resources should be distributed as much as possible within the specified level. In some cases, this may be for reasons of redundancy, for example, to continue operation in the event that a server fails. In an embodiment, to process a server affinity request, the algorithm implemented by CRAS102 (Figure 1) traverses the nodes of the tree structure 500 in order of least available resources. In the example of Figure 5, this is represented at node S-0 within the tree structure 500, which has one available slot. The size at 541 specifies four resources. CRAS places the first resource on server S-0. Three resources from the request still need to be placed. CRAS then identifies the next node with the least available resources, which is S-1 having two resources. CRAS allocates two of those resources to the request. CRAS then identifies the next node with the least available resources, which is S-2 having three resources. CRAS allocates one of those resources to the request. CRAS then creates an updated physical topology at 450.

[0067] Referring now to tree 550, the root Z-0 shows five available slots here, and the rack R-0 shows two available slots. Servers S-0, S-1, and S-2 are drawn as shaded circles indicating the placement of the requested computing resources. Based on fulfilling the allocation request 517, server S-0 and server S-1 show zero available slots, and server S-2 shows two available slots.

[0068] Next, CRAS102 (Figure 1) generates a virtual topology synchronization subgraph 570. The virtual topology synchronization subgraph 570 is obfuscated node data that mirrors the topology of the allocated resources shown in tree 550. Referring to tree 550 here, node Q-0 represents a zone, similar to zone Z-0. Node Y-0 represents a rack, similar to rack R-0. Server X-0 represents a server, similar to server S-0 in tree 550. Server X-1 represents a server, similar to server S-1 in tree 550. Server X-2 represents a server, similar to server S-2 in tree 550. The node data can be obfuscated to avoid revealing proprietary information about the physical computing resources. As an example, the MAC address may be changed or edited to avoid revealing details about the vendor device, and the IP address may be changed or edited to avoid revealing details about the location and / or other information that may adversely affect cybersecurity. In this way, the underlying topology is provided to the requester without revealing proprietary details. This provides the requester with an opportunity to optimize jobs or programs for execution on the provided resources. As an example, a process that guarantees redundancy can be deployed on virtual machines VM0, VM1, and VM3 hosted on all different physical servers, while other processes that do not have redundancy requirements can be deployed on VM2. In this way, the overall robustness and availability of a program or service can be improved using the disclosed embodiments of the present invention. In an embodiment, one or more placement constraints include anti-affinity. In an embodiment, the virtual topology is generated by processing nodes in order of least available resources.

[0069] When comparing the virtual topology synchronization sub-graph 570 in FIG. 5 with the virtual topology synchronization sub-graph 470 in FIG. 4, it can be seen that in the virtual topology synchronization sub-graph 470 with pack affinity at the server level, the four virtual machines VM0 to VM3 are distributed among the two servers shown as X-1 and X-2. In contrast, when using the virtual topology synchronization sub-graph 570 in FIG. 5 that utilizes spread affinity (anti-affinity) at the server level, it can be seen that the four virtual machines VM0 to VM3 are distributed among the three servers shown as X-1, X-2, and X-3.

[0070] As will be understood here, the disclosed embodiments provide improvements in the technical field of computer systems, particularly in the allocation of computer resources. The disclosed embodiments can process requests for virtual clusters of resources, where a virtual cluster includes a plurality of resources. The resources can include, but are not limited to, virtual machines, containers, GPUs, virtual GPUs, and / or other resources. Further, the disclosed embodiments provide a specific sorting mechanism for determining the order of access to descendant sub-trees for placement based on affinity or anti-affinity constraints within the allocation request. The disclosed embodiments generate and return the virtual topology of the virtual resources that are (or will be) placed. This feature is particularly important as it is shared with the specific user to enable optimization of the execution of the specific user's workload / application based on the virtual topology. The virtual topology is based on a hierarchical representation of the physical system. In addition, the disclosed embodiments support both hard and soft constraints. Therefore, the disclosed embodiments enable more efficient use of computer resources, thereby improving overall system utilization and efficiency.

[0071] The present invention may be a system, method, and / or computer program product at any possible technical detail level of integration. The computer program product may include a computer-readable storage medium (or media) having computer-readable program instructions for causing a processor to execute aspects of the present invention.

[0072] The computer-readable storage medium can be a tangible device that can hold and store instructions for use by an instruction execution device. The computer-readable storage medium can be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer-readable storage medium includes: portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital versatile disk (DVD), memory stick, floppy disk, mechanically encoded devices such as punch cards or raised structures in grooves recording instructions, and any suitable combination of the foregoing. The computer-readable storage medium should not be construed as being a transient signal per se, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., an optical pulse passing through an optical fiber cable), or an electrical signal transmitted through a wire.

[0073] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to respective computing / processing devices or to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network can include copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and transfers the computer-readable program instructions for storage on a computer-readable storage medium in each respective computing / processing device.

[0074] The computer-readable program instructions for carrying out the operation of the present invention may be in any combination of assembly instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, configuration data for integrated circuits, or source code or object code written in any combination of one or more programming languages, the one or more programming languages including object-oriented programming languages such as Smalltalk, C++, or the like, and procedural programming languages such as the "C" programming language or the like. The computer-readable program instructions may be executed entirely on the user's computer, may be executed partially on the user's computer as a stand-alone software package, may be executed partially on the user's computer and partially on a remote computer, or may be executed entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, for example, an electronic circuit including a programmable logic circuit, a field-programmable gate array (FPGA), or a programmable logic array (PLA) may execute the computer-readable program instructions by utilizing the state information of the computer-readable program instructions to personalize the electronic circuit in order to carry out aspects of the present invention.

[0075] Aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0076] These computer-readable program instructions can be provided to a computer, or other programmable data processing apparatus's processor to produce a machine, such that the instructions executed via the computer or other programmable data processing apparatus's processor create means for implementing the functions / acts specified in the flowchart and / or one or more blocks of the block diagram. Also, these computer-readable program instructions can be stored in a computer-readable storage medium, which can direct a computer, programmable data processing apparatus, and / or other devices to function in a particular manner, such that the computer-readable storage medium storing the instructions contains a product including instructions for implementing the aspects of the functions / acts specified in the flowchart and / or one or more blocks of the block diagram.

[0077] Alternatively, the computer-readable program instructions can be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus, or other device to produce a computer-implemented process, such that the instructions executed on the computer, other programmable apparatus, or other device implement the functions / acts specified in the flowchart and / or one or more blocks of the block diagram.

[0078] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagram may represent a module, segment, or portion of instructions that include one or more executable instructions for implementing the specified logical function. In some alternative implementations, the functions described in the blocks may be performed in an order different from that shown in the figures. For example, two blocks shown in succession may, in fact, be accomplished as one step, or may be executed at the same time, substantially simultaneously, in a partially or wholly temporally overlapping manner, or the blocks may be executed in the reverse order, depending on the functionality involved. It should also be noted that each block of the block diagrams and / or flowchart diagrams, and combinations of blocks in the block diagrams and / or flowchart diagrams, can be implemented by a dedicated hardware-based system that performs the specified functions or operations, or by a combination of dedicated hardware and computer instructions.

[0079] The description of the various embodiments of the present invention has been presented for purposes of illustration and is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope of the described embodiments. The terminology used herein was chosen in order to best explain the principles of the embodiments, the practical application, or a technical improvement over technologies found in the marketplace, or to enable other ordinary skill in the art to understand the embodiments disclosed herein.

Claims

1. A computer-implemented method for scheduling a set of computing resources, wherein the organizational structure of the computing resources is represented by a physical topology, the method comprising: receiving a distribution request for a virtual cluster, wherein the virtual cluster includes a plurality of virtual server instances, and the distribution request includes at least one placement constraint; identifying at least one physical computing resource from the physical topology for distributing the virtual cluster; and constructing a virtual topology of the virtual cluster, wherein the virtual topology is a synchronous subgraph of the physical topology; and providing placement information for the plurality of virtual server instances based on the virtual topology and the at least one placement constraint A method comprising.

2. The method according to claim 1, wherein the at least one placement constraint includes a room-level constraint.

3. The method according to claim 1, wherein the at least one placement constraint includes an affinity.

4. The method according to claim 1, wherein the at least one placement constraint includes an anti-affinity.

5. The method according to claim 1, wherein the at least one placement constraint includes a rack-level constraint.

6. The method according to claim 1, wherein the at least one placement constraint includes a server-level constraint.

7. The method according to claim 1, wherein the virtual topology obfuscates node data.

8. The method according to claim 3, wherein the virtual topology is generated by processing nodes in order of most available resources.

9. The method according to claim 4, wherein the virtual topology is generated by processing nodes in order of least available resources.

10. The method according to claim 1, wherein the computing resources include at least one of a virtual machine, a container, a native machine, and a graphics processing unit (GPU).

11. An electronic computing device comprising: a processor; a memory coupled to the processor Comprising. When executed by the processor, the memory stores instructions for scheduling a set of computing resources, where the organizational structure of the computing resources is represented by a set of physical computing resources arranged in a physical topology, and the instructions cause the electronic computing device to receive a distribution request for a virtual cluster, where the virtual cluster includes a plurality of virtual server instances and the distribution request includes at least one placement constraint; identify at least one physical computing resource from the physical topology for distributing the virtual cluster; construct a virtual topology of the virtual cluster, where the virtual topology is a synchronous subgraph of the physical topology; and provide placement information for the plurality of virtual server instances based on the virtual topology and the at least one placement constraint An electronic computing device that causes the above to be performed.

12. The electronic computing device according to claim 11, wherein the at least one placement constraint includes a room-level constraint.

13. The electronic computing device according to claim 11, wherein the at least one placement constraint includes affinity.

14. The electronic computing device according to claim 11, wherein the at least one placement constraint includes anti-affinity.

15. The electronic computing device according to claim 11, wherein the at least one placement constraint includes a rack-level constraint.

16. The electronic computing device according to claim 11, wherein the at least one placement constraint includes a server-level constraint.

17. The electronic computing device according to claim 13, wherein when executed by the processor, the memory further comprises instructions for causing the electronic computing device to generate the virtual topology by processing nodes in order of most available resources.

18. The electronic computing device according to claim 14, wherein when executed by the processor, the memory further comprises instructions for causing the electronic computing device to generate the virtual topology by processing nodes in order of least available resources.

19. A computer program product for an electronic computing device comprising a computer-readable storage medium embodying program instructions, the program instructions causing the electronic computing device to receive a distribution request for a virtual cluster, where the virtual cluster includes a plurality of virtual server instances, and the distribution request includes at least one placement constraint; identify at least one physical computing resource from a physical topology for distributing the virtual cluster; construct a virtual topology of the virtual cluster, where the virtual topology is a synchronous subgraph of the physical topology; and provide placement information for the plurality of virtual server instances based on the virtual topology and the at least one placement constraint is executable by a processor to cause the steps to be performed. A computer program product. **Claim 20** The computer-readable storage medium of claim 19, comprising program instructions executable by a processor to cause the electronic computing device to generate the virtual topology by processing nodes in order of most available resources.

Images