LOCATION-BASED VIRTUALIZATION WORKLOAD PLACEMENT

Abstract

A procedure that includes the following: by a computer virtualization scheduler that can be operated to use network proximity to select nodes from a multitude of nodes of a virtualization equipment within a data center on which one or more virtualized resources are to be run, to obtain information about the network location for the virtualization equipment that specifies a physical topology of the virtualization equipment, including rack commonality or rack proximity; to obtain network utilization information for the virtualization equipment through the computer virtualization scheduler, indicating the available network bandwidth and network latency on paths that connect the multitude of nodes of the virtualization equipment through a network; Eliminate, by the computer virtualization scheduler, one or more nodes from the plurality of nodes, based on at least one physical location of each node of the plurality of nodes compared to other nodes of the plurality of nodes; Prioritizing the remaining nodes from the multitude of nodes by the computer virtualization scheduler based on a network locality setting that specifies a requested network locality between the nodes on which the one or more virtualized resources are located; and Maximizing available network bandwidth and minimizing network latency between virtualization equipment by determining, through the computer virtualization scheduler and based on received network location and network utilization information, a virtualization workload placement for the one or more virtualized resources that use one or more of the remaining nodes.

Description

BACKGROUND

[0001] Cloud computing has significantly impacted the way information technology ("IT") infrastructure is used. Virtualization technology makes it possible to deploy workloads across a variety of virtual infrastructures, ranging from public cloud environments to on-premises data centers based on local hardware. New workloads for applications against such virtual infrastructure are constantly being created, deployed, and consumed. US 9 130 844 B1 describes systems and methods for exploiting excess computing capacity across different computing domains. US 2016 / 0 217 050 A1 describes implementations that enable automated container migration in a Platform-as-a-Service (PaaS) system.US 2017 / 0 237 647 A1 describes a provisioning system for virtualized network functions (VNF), which comprises a plurality of computing devices provided in a physical topology and coupled to a network. WO 2014 / 100 558 A1 describes methods, techniques, and systems for dynamically assigning graphics processors to virtual machines. It is an object of the invention to propose a method, a non-transitory, machine-readable storage medium, and a system for location-based virtualization workload placement. This object is achieved by an inventive method according to claim 1, an inventive, non-transitory, machine-readable storage medium according to claim 11, and a system according to claim 16. BRIEF DESCRIPTION OF THE DRAWINGS Fig. 1 is a flowchart for a method according to an example. Fig. Figure 2 is an illustration of an example “default” network location setting. Fig. Figure 3 is an illustration of an example “local” network locality setting. Fig. Figure 4 is an illustration of an example of setting “neighboring” network locations. Fig. Figure 5 is an illustration of an example of “direct” setting of a network locality. Fig. 6 is a diagram of a computer system according to an example. Fig. 7 is a schematic of a machine-readable storage medium according to an example. DETAILED DESCRIPTION

[0002] The following discussion is directed to various examples of the disclosure. Although one or more of these examples may be preferred, the examples disclosed herein should not be interpreted or otherwise used to limit the scope of the disclosure, including the claims. Furthermore, the following description has broad application, and discussion of an example is intended to be descriptive of that example only and not to suggest that the scope of the disclosure, including the claims, is limited to that example. Furthermore, the term "including," as used herein, means including, but not limited to. The term "based on" means based at least in part on.

[0003] Virtual machines ("VMs") are a popular mechanism for deploying cloud computing application infrastructures. In some implementations, multiple instances of a VM may share the same physical hardware, and each application VM may have its own set of operating systems, networking, and storage. Under certain circumstances, it may be preferable to deploy an application workload using virtualized containers rather than VMs. As used here, the term "container" can, for example, refer to operating system-level virtualization in which a kernel or other mechanism enables multiple isolated user-space instances. Such instances may, for example, be referred to as containers, partitions, virtualization machines ("VEs"), jails, or another appropriate term. Such instances may, for example, be designed to resemble real computers from the perspective of the programs running within them.Compared to a traditional computer program, where all resources (e.g., attached devices, files and folders, network shares, central processing unit ("CPU") power, quantifiable hardware capabilities) of the computer on which the program runs are visible, programs running within a container can be designed so that visibility is limited to the contents of the container and certain devices assigned to the container. Such containers, in some implementations, may contain additional isolation mechanisms that provide resource management capabilities to limit the impact of one container's activities on other containers.

[0004] Containerized infrastructure is one of the fastest-growing markets in IT today. Kubernetes has become the de facto standard for managing container clusters and orchestrating workloads, yet its network topology and utilization remain completely unknown. This means that, unlike CPU / memory and storage, the network—the third pillar of DevOps' IT infrastructure—is completely absent from workload scheduling and placement. It is therefore possible, even likely, that application capsules will be randomly distributed across nodes (e.g., servers) distributed throughout the cluster, potentially with higher than necessary or desired network latency between multiple containers implementing a particular microservice or application. This can, for example, reduce the overall efficiency of networks and data centers and drive the industry toward over-engineered network designs.Existing approaches to node proximity are available with affinity constraints. However, these restrict scheduling to the exact same node, rather than to a node directly connected to the same network switch(es) as existing application pods. Other approaches use manual node and pod labels to identify the location for proximity scheduling. None of these approaches are automated or automatable, nor can they incorporate network utilization criteria.

[0005] Workload placement is a critical issue in managing data center efficiency. Certain implementations of the present disclosure are directed toward location-based virtualization workload placement. In some implementations, a method may include, for example: (a) receiving, with a computer virtualization scheduler, network locality information for virtualization equipment; (b) receiving, with the computer virtualization scheduler, network utilization information for virtualization equipment; and (c) determining, with the computer virtualization scheduler and based on the received network locality information and the received network utilization information, virtualization workload placement to maximize available network bandwidth and minimize network latency between virtualization equipment.Certain implementations of this disclosure are designed to introduce network awareness and automation into Kubernetes container pod scheduling and detail implementations for OpenShift and native Kubernetes. Such an approach may, in some situations, lead to improved resource efficiency of OpenShift with Kubernetes scheduler extensions for network localization on compute nodes and composable structures.

[0006] As used here, "composable fabric" and related terms can refer, for example, to a software-defined network fabric specifically designed for workload-dependent performance and scaling. Such a fabric can, for example, address issues at the data plane, the control plane, and the integration plane. At the data plane, for example, rack connectivity modules can form a composable network fabric or data plane that provides physical connectivity, topology, and data / packet forwarding. In such a fabric, for example, connectivity and routing can be combined into a single building block without the need for dedicated spine switches.In such a fabric, for example, the control and management plane can complement the embedded protocols used in the data plane and provide a single point of management for the network, while also providing APIs for directly manipulating network state and objects from external systems.

[0007] Certain implementations of the present disclosure provide for an application or workload orchestration system to be capable of querying the network for workload placement inputs.

[0008] Certain implementations of the present disclosure can leverage network proximity when scheduling containerized applications to reduce latency and increase overall network efficiency. Certain implementations of the present disclosure enable the orchestration system to query the network and obtain a set of resources that meet specific performance-related requirements. Using this information, the orchestration system can, for example, fine-tune workload placement to meet resource availability and performance requirements. Further benefits of the implementations presented here will become apparent upon review of the description and figures.

[0009] Fig. 1 illustrates a flowchart for an example method 100 related to location-based placement of virtualization workloads. In some implementations, the method 100 may be implemented by using executable instructions that reside on a storage resource (e.g., the storage resource of the computing device of Fig. 6) are stored, executable machine-readable instructions embodied on a storage medium (e.g. the medium of Fig. 7) stored, implemented, or otherwise executed in the form of an electronic circuit (e.g., on an application-specific integrated circuit (ASIC)) and / or other suitable form. Although the description of method 100 herein primarily refers to steps performed on a server for illustrative purposes, it is appreciated that in some implementations, method 100 may be executed on another computing device within a networked environment or during data communication within a networked environment. In some implementations, method 100 may be executed in parallel on network devices (e.g., in a distributed computing environment).

[0010] Method 100 includes receiving (at block 102) with a computer virtualization scheduler, network locality information for virtualization equipment. The computer virtualization scheduler may be, for example, a containerized application scheduler or a container application pod scheduler, as further described herein. The term "virtualization equipment" and related terms as used herein may refer to, for example, any equipment suitable for virtualization, such as certain servers, network switches, storage devices, etc.

[0011] The term "network location information" and related terms used herein can refer, for example, to information about the physical topology of virtualization devices within a single rack and / or multiple racks of a data center. Further examples of such network location information are provided here. In some implementations, the network location information is entered by a network administrator via labels. In some implementations, the network location information is entered automatically based on the configured network topology information.

[0012] Method 100 includes receiving (at block 104) with the computer virtualization scheduler network utilization information for virtualization equipment. As used herein, the term "network utilization information" and related terms may refer to, for example, latency levels, bandwidth levels, and / or switch connectivity information. Further examples of such network utilization information are provided herein with respect to specific example implementations of the present disclosure.

[0013] Method 100 includes determining (at block 106), with the computer virtualization scheduler and based on the received network location information and the received network utilization information, the placement of the virtualization workload to maximize available network bandwidth and minimize network latency between the virtualization devices. The term "workload placement" and related terms used herein may refer, for example, to the selection of a plurality of servers for executing a virtualized resource, such as a containerized microservice or application.

[0014] For example, the placement of the workload of block 106 may be determined by a number of suitable factors beyond those explicitly mentioned above. In some implementations, it may be based on factors such as CPU, memory, and storage utilization. In some implementations, the workload placement is determined to minimize the number of network switch transits (or "hops") between the nodes of the virtualization equipment.

[0015] The placement of the workload of block 106 may be determined, for example, by prioritizing and / or ranking certain nodes based on certain factors described above or other suitable factors. In some implementations, for example, workload placement enables ranking the group of potential containerization nodes to optimize for low latency, high bandwidth, and / or direct switch connectivity. In some implementations, determining virtualization workload placement includes prioritizing nodes based on the network environment. In some implementations, workload placement is determined by prioritizing virtualization equipment, resulting in a reduction in the number of hops for a containerized application.In some implementations, workload placement is determined by prioritizing high-bandwidth connections between nodes in a data center. In some implementations, workload placement is determined by ranking available nodes in a data center based in part on location and bandwidth. In some implementations, workload placement is determined by ranking a set of potential containerization nodes based on the nodes' network utilization. In some implementations, workload placement enables the ranking of potential containerization nodes while allowing application-specific customization of the ranked set of potential containerization nodes.

[0016] In some implementations, various predetermined configurations may be provided for determining the workstation position. Some example configurations are listed below:

[0017] Default (see Fig. 2) • Filter - No adjustment • Prioritize - Add network / factory usage to existing CPU / Mem / Disk criteria

[0018] Local (see Fig. 3) • Filter - Nodes that are more than one switch hop away from existing project / application nodes • Prioritize - Add network utilization criteria; sort by fabric utilization

[0019] Opposite (see Fig. 4) • Filter - Remove nodes that are more than one rack away from existing project / application nodes • Prioritize - Add network utilization criteria; sort by fabric utilization

[0020] Direct (see Fig. 5) • Filter - Remove nodes that are not located in one or more racks already used by the project / application • Prioritize - Add network utilization to existing CPU / Mem / Disk criteria

[0021] It is appreciated that one or more operations of method 100 may be performed periodically. For example, in some implementations, one or more of blocks 102, 104, and 106 (or other operations described herein) may be performed periodically. The different period times for blocks 102, 104, and 106 (or other operations described herein) may be the same or different times. For example, in some implementations, the period of block 102 is every 1 minute and the period of block 104 is every 2 minutes. It is further appreciated that the period for a particular block may be regular (e.g., every 1 minute) or irregular (e.g., every 2 minutes during a first condition and every 3 minutes during a second network condition).In some implementations, one or more of blocks 102, 104, and 106 (or other operations described herein) may be non-periodic and may be triggered by some network or other event.

[0022] Although the flowchart of Fig. 1 shows a particular order of execution, it is appreciated that this order can be converted to another suitable order, executed concurrently or partially concurrently, or in a combination thereof. Likewise, suitable additional and / or comparable steps can be added to method 100 or other methods described herein to achieve the same or comparable functionality. In some implementations, one or more steps are omitted. For example, in some implementations, block 104 of receiving network utilization information in method 100 can be omitted or performed by a different device. It is appreciated that blocks corresponding to additional or alternative functionality of other implementations described herein can be included in method 100.For example, blocks corresponding to the functionality of various aspects of implementations described elsewhere herein may be included in Method 100, even if that functionality is not explicitly identified here as a block in Method 100.

[0023] Various example implementations for the present disclosure will now be described. It is appreciated that these examples may include or refer to certain aspects of other implementations described herein (and vice versa), but they are not intended to be limiting to other implementations described herein. Furthermore, it is appreciated that certain aspects of these implementations may be applied to other implementations described herein.

[0024] In some implementations of the present disclosure, data about the data center's network topology and location data are added to the Kubernetes infrastructure via existing mechanisms (labels and / or annotations). A network-topology-aware pod scheduling engine interfaces with the existing Kubernetes scheduler extension framework to add scheduling modules for filtering and prioritizing nodes for pod scheduling using network data. These extensions can, for example, extend Kubernetes' cluster scheduling capabilities to account for network proximity and data center constraints. Constraints on network-proximity scheduling can, for example, be optimized for low latency, high bandwidth, or direct switch connectivity and can include identifying existing running pods for the respective microservice or application.

[0025] It is estimated that the network topology of a data center, for example, can be built in several phases. The first phase, implemented on the server nodes, consists of capturing the physical network configuration of each server and annotating the Kubernetes Application Programming Interface ("API") entry for that server node with the physical network configuration, specifically the Media Access Control ("MAC") address of each physical network interface controller ("NIC"). The second phase, implemented on the data center network controller, uses connection data (peering) from the data center switches, which indicates all internal connections between the data center switches. This data can be used to create a connectivity map between the data center switches, including the potentially available bandwidth between the peer switches.The server node's network adapters can then be mapped to the data center's network topology using network proximity advertisements (Link Layer Discovery Protocol ("LLDP" packets)) or direct MAC address lookup from the data center switches. This creates a complete map of the network topology, including the data center switches and server nodes, including all available connection paths and the available bandwidth on each connection path.

[0026] According to certain implementations of the present disclosure, Kubernetes pod scheduling can be enhanced with network-aware filtering and prioritization methods through existing scheduler extension mechanisms. For example, the filtering method can eliminate candidate nodes that do not match the desired network locality. A prioritization method used by certain implementations of the present disclosure can, for example, assign the remaining nodes (after filtering) in order of available fabric bandwidth to / from each remaining node.

[0027] In certain implementations, a number of network location settings can be requested, including directly ( Fig. 5), adjacent ( Fig. 4), local ( Fig. 3), Standard ( Fig. 2) or disabled. Each setting can be cluster-wide or application-specific. For example, such a "direct" local setting may request that the container pods of a specific application / project / namespace (hereinafter just "application") be scheduled on nodes that are all connected to the same data center switch(es). Such a "neighborly" location setting may request, for example, that application container pods be scheduled on nodes connected to switches that are a single hop away (no intermediate switches), with the highest available bandwidth between those switches. Such a "local" location setting may, for example,Request that application container pods be scheduled on nodes connected to switches a single hop away (no intervening switches), regardless of the available bandwidth between those switches. Such a "default" location setting can, for example, allow placement on any node in the cluster. Such a "disabled" location setting can, for example, completely remove network considerations from Kubernetes' scheduling process. In all of the above cases (except for disabling them in some implementations), available candidate nodes can be prioritized based on, for example, available bandwidth.

[0028] Some of the proposed implementations can, for example, provide Kubernetes with a cluster-wide default scheduling algorithm, as well as customizable overrides per application or for specific container pods within an application. These customizable overrides can be easily achieved by using existing tagging mechanisms in the Kubernetes API with defined tag names and values.

[0029] It is estimated that certain implementations of the present disclosure may focus on a single layer—the data center network—and the optimization of a location within that structure, including non-hierarchical network topologies. Certain existing solutions refer to the concept of node proximity for scheduling around fault domain proximity. Such solutions attempt to prevent too many application container pods from being scheduled within a given fault domain. The present disclosure complements this work by focusing on entities beyond a single node but within the fault domain of a single structure. Both solutions could coexist in a single environment, with one set of scheduling extensions pushing the pods further apart relative to the defined boundaries and the other pods closer together within the boundaries.

[0030] Certain existing solutions address scheduling individual containers rather than the collection of application containers. Such a solution is likely to randomly select a first node. If this node is deemed unsuitable, a "second" node is selected from the matrix. Certain implementations of the present disclosure incorporate a cooperative approach, incorporating network locality attributes (e.g., latency and / or bandwidth "distance") into a larger node selection process that includes, among other factors, CPU load, memory load, disk utilization, and affinity / anti-affinity in a holistic scheduling process.

[0031] Fig. 6 is a diagram of a computing device 108 that may serve, for example, as a containerized application planning system in accordance with the present disclosure. Computing device 108 may be, for example, in the form of a server or other suitable computing device within a network environment or in communication with a network environment or its equipment. As described in more detail below, computing device 108 includes a processing resource 110 and a storage resource 114 that stores machine-readable instructions 116 and 118. For illustrative purposes, reference is made throughout the description of computing device 108 to various aspects of certain diagrams, methods, and other specific implementations. However, it is appreciated that computing device 108 may include additional, alternative, or fewer aspects, features, etc.than the implementations described elsewhere herein, and is not intended to be limited by the disclosure thereof.

[0032] Instruction 116 stored on storage resource 114, when executed by processing resource 110, is intended to cause processing resource 110 to rank a set of potential containerization nodes within a data center based, in part, on each node's physical location relative to other nodes within the data center. Instruction 116 may include one or more aspects of blocks of method 100 or any other suitable aspect of other implementations described herein (and vice versa). For example, in some implementations, instruction 116 is intended to cause the processing resource to rank the set of potential containerization nodes based on the nodes' network utilization.Instruction 118 stored on storage resource 114, when executed by processing resource 110, is intended to cause processing resource 110 to select nodes to execute a containerized application based on the ranking of the nodes. Instruction 116 may include one or more aspects of blocks of method 100 or any other suitable aspect of other implementations described herein (and vice versa).

[0033] The processing resource 110 of the computing device 108 may, for example, be in the form of a central processing unit (CPU), a semiconductor-based microprocessor, a digital signal processor (DSP), such as a digital image processing unit, other hardware devices or processing elements capable of fetching and executing instructions stored in the memory resource 114, or suitable combinations thereof. The processing resource 110 may, for example, include single or multiple cores on a chip, multiple cores across multiple chips, multiple cores across multiple devices, or suitable combinations thereof. The processing resource 110 may function to fetch, decode, and execute instructions as described herein.Alternatively or in addition to fetching and executing instructions, the processing resource 110 may, for example, comprise at least one integrated circuit (IC), other control logic, other electronic circuitry, or a suitable combination thereof, including a series of electronic components for executing the functionality of instructions stored on the memory resource 114. The term "logic" may, in some implementations, be an alternative or additional processing resource for performing a particular action and / or function described herein, etc., which may include hardware, e.g., various forms of transistor logic, application-specific integrated circuits (ASICs), etc., as opposed to machine-executable instructions, e.g., software firmware, etc., stored in memory and executable by a processor. The processing resource 110 may, for example,be implemented across multiple processing units, and instructions may be implemented by different processing units in different areas of the computing device 108.

[0034] The storage resource 114 of the computing device 108 may, for example, take the form of a non-transitory machine-readable storage medium, such as a suitable electronic, magnetic, optical, or other physical storage device for containing or storing information such as the machine-readable instructions 116 and 118. Such instructions may be operable to perform one or more functions described herein, such as those described herein with respect to method 100 or other methods described herein. The storage resource 114 may, for example, be housed within the same enclosure as the processing resource 110 for the computing device 108, such as within a chassis for the computing device 108 (in implementations where the computing device 108 is housed within a chassis for the computer tower). In some implementations, the storage resource 114 and the processing resource 110 are housed in different enclosures.The term "machine-readable storage medium" as used herein may include, for example, random access memory (RAM), flash memory, a storage drive (e.g., a hard disk), any type of storage disk (e.g., a compact disc read-only memory (CD-ROM), any other type of compact disc, a DVD, etc.), and the like, or a combination thereof. In some implementations, the storage resource 114 may correspond to memory that includes main memory, such as random access memory (RAM), in which the software may reside during runtime, and secondary storage. The secondary storage may, for example, include non-volatile memory that stores a copy of machine-readable instructions.It is estimated that both machine-readable instructions and related data can be stored on storage media and that multiple media can be treated as a single medium for description purposes.

[0035] The storage resource 114 may be connected to the processing resource 110 via a communication link 112. Each communication link 112 may be local or remote to a machine (e.g., a computing device) connected to the processing resource 110. Examples of a local communication link 112 may include an electronic bus within a machine (e.g., a computing device), where the storage resource 114 is a volatile, non-volatile, fixed, and / or removable storage medium that communicates with the processing resource 110 via the electronic bus.

[0036] In some implementations, one or more aspects of computing device 108 may be in the form of functional modules, which may, for example, be operative to perform one or more processes of instructions 116 or 118 or other functions described herein with respect to other implementations of the disclosure. As used herein, the term "module" refers to a combination of hardware (e.g., a processor, such as an integrated circuit or other circuit) and software (e.g., machine- or processor-executable instructions, commands, or code, such as firmware, programming, or object code). A combination of hardware and software may include only hardware (e.g., a hardware element with no software elements), software hosted on hardware (e.g., software stored in memory and executed or interpreted on a processor), or hardware and software hosted on hardware.It is further appreciated that the term "module" is intended to refer additionally to one or more modules or a combination of modules. Each module of computing unit 108 may include, for example, one or more machine-readable storage media and one or more computer processors.

[0037] In view of the above, it is appreciated that the various instructions of the computing system 108 described above may correspond to separate and / or combined functional modules. For example, instruction 116 may correspond to a "ranking module" for ranking a set of potential containerization nodes within a data center based, in part, on the physical location of each node relative to other nodes within the data center. Likewise, instruction 118 may correspond to a "node selection module" for selecting nodes for executing a containerized application based on the ranking of the nodes. It is further appreciated that a particular module may be used for multiple functions. As just one example: In some implementations, a single module may be responsible for both ranking potential containerization nodes (e.g.,according to the functionality of instruction 116) as well as for the selection of nodes (e.g. according to the functionality of instruction 118).

[0038] One or more implementations of the present disclosure may further include a suitable communication module to enable networked communication between network devices. Such a communication module may, for example, include a network interface controller having an Ethernet port and / or a Fibre Channel port. In some implementations, such a communication module may include a wired or wireless communication interface, and in some implementations, may provide virtual network ports. In some implementations, such a communication module includes hardware in the form of a hard disk, associated firmware, and other software that enables the hard disk to operatively communicate with other network devices. The communication module may, for example, include machine-readable instructions for use with the communication of the communication module, such asFirmware for implementing physical or virtual network connections.

[0039] Fig.7 shows a machine-readable storage medium 120 having various instructions executable by a computer processor or other processing resource. In some implementations, the medium 120 may be located in a server, on another computing device within a network environment, or in a local or remote wired or wireless data communication system within a network environment. For illustrative purposes, the description of the machine-readable storage medium 120 herein refers to various aspects of the computing device 108 (e.g., processing resource 110) and other implementations of the disclosure (e.g., method 100).Although one or more aspects of computing device 108 (as well as instructions such as instructions 116 and 118) may be applied to or otherwise incorporated into medium 120, it will be appreciated that in some implementations, medium 120 may be stored or housed separately from such a system. For example, in some implementations, medium 120 may be in the form of random access memory (RAM), flash memory, a storage drive (e.g., a hard disk), any type of storage disk (e.g., a compact disc read-only memory (CD-ROM), any other type of compact disc, a DVD, etc.), and the like, or a combination thereof.

[0040] Medium 120 contains machine-readable instructions 122 stored thereon for causing processing resource 110 to determine the containerization of the application workload based on information about the location of the equipment within a common data center. For example, instruction 116 may include one or more aspects of block 106 of method 100 or any other suitable aspect of other implementations described herein (and vice versa). For example, in some implementations, the placement of the workload is determined to minimize the number of hops between nodes of the virtualization equipment.

[0041] Medium 120 contains machine-readable instructions 124 stored thereon for causing processing resource 110 to assign a workload to virtualization equipment within the data center based on the information about the equipment's location to improve overall network utilization. Instructions 118 may, for example, include one or more aspects of block 106 of method 100 or any other suitable aspect of other implementations described herein (and vice versa).

[0042] While specific implementations have been shown and described above, various changes in form and details may be made. For example, some features described with respect to one implementation and / or process may be related to other implementations. In other words, processes, features, components, and / or properties described with respect to one implementation may be useful in other implementations. Furthermore, it should be understood that the systems and methods described herein may include various combinations and / or subcombinations of the components and / or properties of the various described implementations. Thus, features described with respect to one or more implementations may be combined with other implementations described herein.

[0043] As used herein, "logic" is an alternative or additional processing resource for performing a particular action and / or function, etc., described herein, including hardware, e.g., various forms of transistor logic, application-specific integrated circuits (ASICs), etc., as opposed to machine-executable instructions, e.g., software firmware, etc., stored in memory and executable by a processor. Further, as used herein, "a" or "a number of" something may refer to one or more such things. For example, "a number of widgets" may refer to one or more widgets. Also, as used herein, "a plurality of" something may refer to more than one of these things.

Claims

[1] A process comprising: by a computer virtualization scheduler operable to utilize network proximity to select nodes from a plurality of nodes of virtualization equipment within a data center on which to run one or more virtualized resources, obtaining network location information for the virtualization equipment indicating a physical topology of the virtualization equipment, including rack commonality or rack adjacency; obtain, by the computer virtualization scheduler, network utilization information for the virtualization equipment indicating available network bandwidth and network latency on paths interconnecting the plurality of nodes of the virtualization equipment through a network; Eliminating, by the computer virtualization scheduler, one or more nodes from the plurality of nodes based on at least a physical location of each node of the plurality of nodes relative to other nodes of the plurality of nodes; Prioritizing, by the computer virtualization scheduler, the remaining nodes of the plurality of nodes based on a network locality setting that indicates a requested network locality between the nodes on which the one or more virtualized resources are located; and Maximizing available network bandwidth and minimizing network latency between the virtualization equipment by determining, by the computer virtualization scheduler and based on the received network location information and the received network utilization information, a virtualization workload placement for the one or more virtualized resources using one or more of the remaining nodes. [2] The method of claim 1, wherein the computer virtualization scheduler is a containerized application scheduler. [3] The method of claim 1, wherein the computer virtualization scheduler is a pod scheduler for containerized applications. [4] The method of claim 1, wherein the virtualization equipment comprises servers for executing containerized applications. [5] The method of claim 1, wherein the determination of virtualization workload placement is further based on other factors, including central processing unit (CPU), memory, and storage utilization. [6] The method of claim 1, wherein the physical topology comprises information indicating a rack within a plurality of racks of a data center within which the virtualization equipment is located. [7] The method of claim 1, wherein the physical topology comprises information indicating a single rack of the data center within which the virtualization equipment is located. [8] The method of claim 1, wherein the determined virtualization workload placement comprises selecting a plurality of servers to execute a containerized microservice or application. [9] A method according to claim 1, wherein the location information of the network is entered by a network administrator via labels. [10] The method of claim 1, wherein the network locality setting comprises at least one of a direct locality setting, a neighbor locality setting, a default locality setting, or a disabled locality setting. [11] Non-transitory machine-readable storage medium having stored thereon machine-readable instructions that cause a computer processor to: Receiving, by a containerized application scheduler operable to utilize network proximity to select nodes from a plurality of nodes of virtualization equipment within a common data center on which to execute one or more virtualized resources, equipment locality information for the virtualization equipment indicative of a physical topology of the virtualization equipment, including rack commonality or rack adjacency; Eliminating, by the containerized application scheduler, one or more nodes from the plurality of nodes based on at least one physical location of each node of the plurality of nodes relative to other nodes of the plurality of nodes; Prioritizing, by the containerized application scheduler, the remaining nodes of the plurality of nodes based on an equipment locality setting that specifies a requested equipment locality between nodes on which the one or more virtualized resources are located; Determining, by the containerized application scheduler, the placement of the containerized application workload based on information about the location of the equipment; and Improving the overall network utilization of available bandwidth on paths interconnecting a plurality of nodes of the virtualization equipment over a network by assigning a workload to a node of the plurality of nodes based on the locality information of the equipment. [12] The medium of claim 11, wherein the placement of the workload is determined to minimize a number of hops between the plurality of nodes of the virtualization equipment. [13] The medium of claim 11, wherein the placement of the workload is determined by prioritizing the nodes from the plurality of nodes of the virtualization equipment that result in a reduction in the number of hops for a containerized application. [14] The medium of claim 12, wherein the placement of the workload is determined by prioritizing high bandwidth connections between the plurality of nodes. [15] The medium of claim 12, wherein the placement of the workload is determined by a ranking of the available nodes of the plurality of nodes based in part on their respective locations in the physical topology and the available bandwidth. [16] System comprising: a processing resource; and a storage resource that stores machine-readable instructions that cause the processing resource to: Receiving network locality information for a virtualization equipment indicating a physical topology of the virtualization equipment within a data center, including rack commonality or rack adjacency; Receiving network utilization information for the virtualization equipment indicating the available network bandwidth and network latency on the paths that connect the nodes of the virtualization equipment over a network; Eliminating one or more nodes from the plurality of nodes based on at least one physical location of each node of the plurality of nodes relative to other nodes of the plurality of nodes; Prioritizing the remaining nodes of the plurality of nodes based on a network locality setting that specifies a requested network locality between nodes on which the one or more virtualized resources are located; and Maximizing available network bandwidth and minimizing network latency between the virtualization devices by determining, based on the received network locality information and the received network utilization information, a virtualization workload placement for the one or more virtualized resources using one or more of the remaining nodes. [17] The system of claim 16, wherein the instructions further cause the processing resource to: rank a set of potential containerization nodes within the virtualization suite based, in part, on the physical location of each node in the set of potential containerization nodes relative to other nodes in the set of potential containerization nodes; and select a subset of the set of potential containerization nodes to run a containerized application based on the ranking of the potential containerization nodes. [18] The system of claim 17, wherein the instructions are further to cause the processing resource to rank the set of potential containerization nodes based on the network utilization of each node in the set of potential containerization nodes. [19] The system of claim 17, wherein the instructions further cause the processing resource to provide a standard approach to ranking the set of potential containerization nodes while allowing application-specific customization of the ranking of the potential containerization nodes. [20] The system of claim 17, wherein the instructions further cause the processing resource to optimize at least one of low latency, high bandwidth, and / or direct switch connectivity. [21] The system of claim 16, wherein the network locality setting comprises at least one of a direct locality setting, a neighbor locality setting, a default locality setting, or a disabled locality setting.

Images