AUTOMATIC EVALUATION OF THE DATA PROCESSING PERFORMANCE OF VIRTUAL MACHINES

Abstract

A method (200) for estimating the use of computing resources, comprising: Providing (205) a set of virtual machines (125A, 125B, 125C) on a hypervisor (120); Performing one or more local surveys on each virtual machine to generate data (240) on the use of computing resources (210); generating (215) a first stability factor comprising a metric related to consistency of resource usage in response to receiving data about hypervisor resource usage from the hypervisor; Determining (220), based on computing resource usage data, hypervisor resource usage data, and the first stability factor, that a standard usage metric of the computing resources exceeds a threshold, wherein the standard usage metric reflects an average of historical computing resource usage data and the threshold defines a reasonable range for the standard usage metric; generating (225) a customized computing resource usage metric to be used instead of the standard usage metric based on at least the computing resource usage data in response to the determining; and Informing (230) a user about the tailored usage metric.

Description

BACKGROUND

[0001] The present disclosure relates generally to the field of computing resource utilization and, more particularly, to estimating computing resource utilization.

[0002] Virtual machines and hypervisors are commonly used in cloud computing environments. Monitoring the use of computing resources allows a cloud service provider to measure efficiency and allows a user to decide whether to expand or reduce their cloud operations.

[0003] US 2016 / 0147550 A1 discloses monitoring resource utilization in a virtualized environment, particularly with the physical processors used by virtual machines or applications. US 10409642 B1 discloses notifications about application environments with multiple resource types and their scaling. US 10992542 B2 discloses a system for creating, using, and distributing information about network entities using a façade processing system for network and computer system management. SUMMARY

[0004] Embodiments of the present disclosure include a method, a computer program product, and a system for estimating the utilization of computing resources.

[0005] A set of virtual machines is deployed on a hypervisor. One or more local probes are performed on each virtual machine to generate a set of data about computing resource usage. In response to receiving a set of data about hypervisor resource usage, a stability factor is generated. Based on the set of resource usage data, the set of hypervisor resource usage data, and the stability factor, a determination is made that a standard usage metric exceeds a threshold. In response to the determination, a tailored usage metric is generated based on at least the set of data about computing resource usage. A user is notified of the tailored usage metric.

[0006] The foregoing summary is not intended to describe every illustrated embodiment or every implementation of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] The drawings included in this disclosure are incorporated in and constitute a part of the specification. They illustrate embodiments of the present disclosure and, together with the description, serve to explain the principles of the disclosure. The drawings merely illustrate typical embodiments and do not limit the disclosure. Fig. 1 illustrates an example network environment for estimating computing resource utilization in accordance with embodiments of the present disclosure. Fig. 2 illustrates an exemplary method for estimating the utilization of computing resources according to embodiments of the present disclosure. Fig. 3 shows a cloud computing environment according to an embodiment of the present disclosure. Fig. 4 depicts abstraction model layers according to an embodiment of the present disclosure. Fig. 5 shows a high-level block diagram of an example computer system that may be used in implementing embodiments of the present disclosure.

[0008] While the embodiments described herein are susceptible to various modifications and alternative forms, the drawings show, by way of example, and will describe in detail the details thereof. It should be understood, however, that the particular embodiments described are not intended to be limiting. On the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the disclosure. DETAILED DESCRIPTION

[0009] Aspects of the present disclosure generally relate to the field of computing resource utilization, and more particularly, to estimating computing resource utilization. While the present disclosure is not necessarily limited to such applications, various aspects of the disclosure may be understood by discussing various examples using this context.

[0010] Virtual machines and hypervisors are commonly used in cloud computing environments. Monitoring the use of computing resources allows a cloud service provider to measure efficiency and allows a user to decide whether to expand or reduce their cloud operations.

[0011] When licensing cloud computing resources to users, companies typically use data collected by the hypervisors on which the virtual machines are deployed, typically through application programming interfaces (APIs). The data collected in this way can be merged with data collected during investigations of individual virtual machines. This merged data can include, for example, metrics related to the use of processors, graphics processing units (GPUs), memory caches, network bandwidth, power consumption, the number of calculations performed, the duration of an application's execution, the priority of a particular application and / or virtual machine, the use of encryption, the type of encryption, the availability and utilization of storage space, and so on.

[0012] However, when a virtual machine is first deployed, there may be little or no such data, and any data that does exist may be irregular and not characteristic of normal operational metrics. For example, the utilization of computing resources may increase significantly while applications are being installed and tested. Alternatively, network bandwidth may be significantly reduced before an application is made available for public use. In such scenarios, it may be difficult to determine an appropriate licensing fee for the use of the cloud computing resources associated with a particular hypervisor or virtual machine. In some cases, a standard calculation based on expected / estimated usage may be used to determine usage and, consequently, a licensing fee.This can result in a user being overcharged or undercharged.

[0013] Obtaining a more accurate estimate of the computing resources utilized typically requires coordination between teams of professionals, including: 1) the team responsible for provisioning the virtual machine(s), 2) the team managing a license metrics tool (e.g., IBM LICENSE METRIC TOOL), and 3) the team managing the virtual hosting environment (e.g., VMWARE). The first team is often led by a consuming entity, while the second and third teams may or may not belong to the same entity. In some situations, coordinating three teams across three different entities can consume a significant number of man-hours and time.

[0014] Embodiments of the present disclosure contemplate collecting data from hypervisors once a connection to a client / user is operational (e.g., data about hypervisor resource usage), combining this data with information obtained from local investigations of the virtual machine(s) (e.g., data about computing resource usage), and adding a stability factor (e.g., a metric reflecting both historical license capacity usage and real-time usage data from the entire infrastructure). Default usage values ​​(e.g., a default usage metric) that may be higher than a user expects can be corrected as needed and reported to a license administrator, user, etc., to obtain a more accurate picture of the overall usage of the licensed resources.

[0015] In some embodiments, the data collected from the local scans of the virtual machine(s) may be captured by a monitoring program and / or stored in a database. In some embodiments, this local scan data may be compared with data retrieved from the hypervisor. However, in some embodiments, this comparison may be inaccurate or unavailable—in such cases, default values ​​may be used for a usage report, and the data may be flagged. Once enough data has been collected to perform the comparison, a usage calculation may be repeated using the more accurate information, and the usage report may be updated.

[0016] For example, assume that local scans of a set of virtual machines were performed on the first day, but the data was not received from the hypervisor or was unavailable for other reasons. In such a case, a standard usage metric can be introduced to estimate total usage. Delays in obtaining data on hypervisor resource usage can include incorrect firewall configurations, data processing schedules, errors, manual interventions, quirks, etc.

[0017] Furthermore, assume that data on hypervisor resource usage is received on the third day. At this point, the total usage estimate can be verified. Local investigations of the virtual machine(s) can be used to determine if there has been any change or unexpected deviation in the local environment.

[0018] Together with local investigations, the hypervisor resource utilization data can be used in some embodiments to determine a stability factor for the environment. At this point, it can be determined whether the actual total utilization matches the expectations / estimates and whether the stability of the environment has been relatively consistent (e.g., nominal total utilization with periods of high traffic / high usage can be treated differently than nominal total utilization with constant traffic / constant usage).

[0019] In some embodiments, a customized usage metric may be created based on the actual total usage and the stability factor if the total usage and / or the stability factor indicate that the default usage metric is outside a reasonable range. In such embodiments, the administrator and / or user may be notified of the correction and the reasons for using the customized usage metric.

[0020] Embodiments of the present disclosure may provide both a cloud software provider and a user with a way to protect themselves from unexpected / undesirable peaks and valleys at the beginning of a license monitoring cycle. This may prevent poor cost / benefit scenarios for both the provider and the user, further resulting in fewer support requests and negative customer service reports.

[0021] With reference to Fig. 1 illustrates an exemplary network environment 100 for estimating computing resource usage according to some embodiments of the present disclosure. The network environment 100 may include, for example, a licensee entity 140, a cloud 110, a hypervisor 120, and a license usage counter 130. In some embodiments, certain functions of the licensee entity 140, the hypervisor 120, and the license usage counter 130 may be implemented in a different location than shown in the figure.

[0022] According to embodiments, the licensee unit 140, the cloud 110, the hypervisor 120, and the license usage counter 130 may consist of computer systems (e.g., they may include the same or similar components as the computer system 501). The licensee unit 140, the cloud 110, the hypervisor 120, and the license usage counter 130 may be configured to communicate with each other via an internal or external network interface (not shown). The network interfaces may, for example, be modems, wireless network adapters, Ethernet adapters, etc. The licensee unit 140, the cloud 110, the hypervisor 120, and the license usage counter 130 may further be equipped with displays or screens (not shown). In addition, the licensee unit 140, the cloud 110, the hypervisor 120, and the license usage counter 130 may include optional input devices (e.g.,a keyboard, a mouse, a scanner, or other input device) and / or any commercially available or custom software (e.g., image processing software, object identification software, etc.). In some embodiments, the licensee device 140, the cloud 110, the hypervisor 120, and the license usage counter 130 may include additional servers, desktops, laptops, Internet of Things (IoT) devices, or handheld devices.

[0023] The licensee unit 140, the cloud 110, the hypervisor 120, and the license usage counter 130 may further include additional storage (e.g., a storage interface 514). The storage may include, for example, virtualized hard disk drives, physical hard disk drives, solid-state storage disks, or any other suitable storage medium. In some embodiments, workload data and metadata may be stored temporarily or permanently.

[0024] The licensee entity 140, the cloud 110, the hypervisor 120, and the license usage counter 130 may be remote from each other and communicate over a network (not shown). In embodiments, the cloud 110 may be a central hub from which the licensee entity 140, the hypervisor 120, and the license usage counter 130 may establish a data transmission connection, such as in a client-server network model. In other embodiments, the license usage counter 130 may serve as such a hub for the hypervisor 120 and the licensee entity 140. In some embodiments, the licensee entity 140, the cloud 110, the hypervisor 120, and the license usage counter 130 may be configured in any other suitable network relationship (e.g., in a peer-to-peer configuration or using another network topology).

[0025] In embodiments, the connections between the components of network environment 100 may be implemented using any number of suitable communications media. For example, a wide area network (WAN), a local area network (LAN), the Internet, or an intranet. In certain embodiments, licensee device 140, cloud 110, hypervisor 120, and license usage meter 130 may be local to each other and communicate via any suitable local communications medium. For example, licensee device 140, cloud 110, hypervisor 120, and license usage meter 130 may communicate using a local area network (LAN), one or more wired connections, a wireless connection, a router, or an intranet.In some embodiments, the licensee device 140, the cloud 110, the hypervisor 120, the license usage meter 130, and any other devices may be connected using a combination of one or more networks and / or one or more local connections for data exchange.

[0026] In some embodiments, the network environment 100 may be implemented within or as part of a cloud computing environment, as depicted. In accordance with various embodiments, a cloud computing environment may include a network-based, distributed computing system that provides one or more cloud computing services. Furthermore, a cloud computing environment may include many computers (e.g., hundreds or thousands of computers or more) located within one or more data centers and configured to share resources over a network. Further details regarding cloud computing are provided with respect to Fig. 3 & Fig. 4 described.

[0027] According to embodiments, the licensee device 140 may comprise, for example, an enterprise server, a client device, or any other suitable device from which a user or other user may interact with the license usage counter 130 and from which such user / user may provision virtual machines, such as virtual machines 125A-C.

[0028] For example, cloud 110 may include hypervisor 120 and license usage counter 130. Hypervisor 120 may include a layer of hardware resources / components on which a virtual machine (e.g., virtual machines 125A-C) may be deployed. Hypervisor 120 may be a Type 1 or Type 2 hypervisor, according to embodiments.

[0029] Hypervisor 120, in some embodiments, may include virtual machines 125A-C and a virtual machine monitor 127. Virtual machines 125A-C may be provided, for example, by the owner of licensee device 140. Virtual machines 125A-C may be customized to serve a specific purpose or may be generalized to serve multiple purposes. In some embodiments, virtual machines 125A-C may represent any number of virtual machines.

[0030] Virtual machine monitor 127 may, according to embodiments, perform local investigations of virtual machines 125A-C to generate data about computing resource utilization, as described herein. In some embodiments, virtual machine monitor 127 may further monitor hypervisor 120 to generate or contribute data about hypervisor resource utilization.

[0031] Local investigations of the virtual machines 125A-C may include determining the amount of processor resources utilized, memory resources utilized, network traffic bandwidth utilized, in-memory computations performed, any hypervisor underlying hardware units dedicated to a particular virtual machine, etc.

[0032] The license usage counter 130 may include a hypervisor monitor 135 and a stability factor generator 137. The hypervisor monitor 135 may retrieve or receive data about the usage of hypervisor resources from the hypervisor 120, as described herein.

[0033] Stability factor generator 137 may generate a stability factor based on historical and real-time data about hypervisor resource usage. In some embodiments, the stability factor generator may further consider a portion of data about computing resource usage from one or more of virtual machines 125A-C. In some embodiments, stability factor generator 137 may further consider the overall stability of cloud 110 outside of hypervisor 120 and license usage counter 130, both historical and real-time.

[0034] In some embodiments, the license usage counter 130 may employ a standard usage metric when determining total computing resource usage or, as discussed herein, generate a customized usage metric when appropriate. In some embodiments, the license usage counter 130 may be employed as an interface between the hypervisor 120 and the licensee device 140. In other embodiments, the license usage counter 130 may be integrated directly into the licensee device 140, for example, as a condition for using the hypervisor 120 and / or deploying the virtual machines 125A-C.

[0035] It is pointed out that Fig. 1 is intended to illustrate the characteristic main components of an exemplary network environment 100. However, in some embodiments, individual components may have a higher or lower complexity than in Fig. 1; other than those shown in Fig. 1 or additional components may be present, and the number, type, and configuration of such components may vary.

[0036] With reference to Fig. Figure 2 illustrates an example method 200 for estimating computing resource utilization according to some embodiments of the present disclosure. The example method 200 may begin at 205, where a set of virtual machines is deployed on a hypervisor (e.g., hypervisor 120), as discussed herein.

[0037] At 210, data about the utilization of computing resources is generated. For example, virtual machine monitor 127 may perform local investigations of the deployed virtual machines (e.g., virtual machines 125A through C) to determine the amount and type of computing resources utilized.

[0038] At 215, a stability factor is generated. The stability factor may consider the computing resource utilization data generated at 210, as well as the hypervisor resource utilization data 240. Components of the computing resource utilization data and / or the hypervisor resource utilization data may be weighted in generating the stability factor. For example, in embodiments where in-memory computations are possible, memory utilization metrics may be weighted because the in-memory computations may reduce traditional processor utilization. The stability factor may further reflect, in some embodiments, the amount of scaling up and down performed for a particular virtual machine or group of virtual machines.

[0039] As described herein, data about hypervisor resource usage and data about compute resource usage may include both historical and real-time data. In some embodiments, real-time data may be weighted compared to historical data. According to embodiments, the historical data about compute resource usage and the historical data about hypervisor resource usage may each reflect averages. The averages may be determined for the lifetime of the respective virtual machine(s) and / or hypervisor, or may be determined for a specific period of time (e.g., a period of time during which historical averages appear similar to current real-time values).

[0040] At 220, it is determined whether a standard usage metric exceeds a threshold. The standard usage metric indicates the total usage expected based on the historical data on computing resource usage and the historical data on hypervisor resource usage. The threshold may, for example, include a ratio between the stability factor and the standard usage metric, according to embodiments.

[0041] For example, if it is determined at 220 that the standard usage metric has not exceeded the threshold, it can be assumed that the standard usage metric reflects total usage, and a user / administrator can be notified of the standard usage metric at 235. The notification can include, for example, a report on license usage.

[0042] However, if it is determined at 220 that the standard usage metric exceeds the threshold, a customized usage metric is generated at 225, as described herein. The customized usage metric 225 may, in some embodiments, give greater weight to real-time usage data collected from the virtual machine(s) and / or the hypervisor, for example. In some embodiments, the customized usage metric may reflect the average total resource usage for a historical set of stabilized data about computing resource usage (e.g., a usage metric reflecting similar virtual machines for which customized usage metrics have been created).

[0043] At 230, the user and / or administrator are informed of the customized usage metric. In some embodiments, this may include, for example, a report on license usage and may refer to the standard usage metric and a justification for using the customized usage metric.

[0044] It should be understood at the outset that, although this disclosure includes a detailed description of cloud computing, the implementation of the teachings herein is not limited to a cloud computing environment. Rather, some embodiments of the present invention may be practiced in conjunction with any type of computing environment now known or later invented.

[0045] Cloud computing is a service delivery model for enabling seamless, on-demand network access to a shared pool of configurable computing resources (e.g., 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 implementation models. The properties are as follows:

[0046] On-demand self-service: A cloud user can unilaterally and automatically provision data processing functions such as server time and network storage as needed, without requiring human interaction with the service provider.

[0047] Broad Network Access: Functions are available over a network and accessed through standard mechanisms that support use by heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, and PDAs).

[0048] Resource pooling: The provider's computing resources are pooled to serve multiple users using a multi-tenant model, with various physical and virtual resources dynamically allocated and reassigned as needed. There is a perceived location independence, as the user generally has no control or knowledge over the exact location of the provided resources, but may be able to specify a location at a higher level of abstraction (e.g., country, state, or data center).

[0049] Rapid Elasticity: Features can be deployed quickly and elastically for rapid horizontal scaling out, in some cases automatically, and released quickly for rapid scale-in. To the user, the features available for deployment often appear unlimited, and they can be purchased in any quantity at any time.

[0050] Measured Service: Cloud systems automatically control and optimize resource usage by leveraging a measurement function at a certain level of abstraction appropriate for the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, creating transparency for both the provider and the user of the service. The service models are as follows:

[0051] Software as a Service (SaaS): The functionality provided to the user is to use the provider's applications running on a cloud infrastructure. The applications are accessible from various client devices via a thin client interface such as a web browser (e.g., web-based email). The user does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, storage, or even individual application functions, with the possible exception of limited user-specific application configuration settings.

[0052] Platform as a Service (PaaS): The functionality provided to the user is to deploy applications created or obtained by the user, using programming languages ​​and tools supported by the provider, into the cloud infrastructure. The user does not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, or storage, but has control over the deployed applications and possibly over configurations of the application hosting environment.

[0053] Infrastructure as a Service (IaaS): The functionality provided to the user consists of providing processing, storage, networking, and other basic computing resources, allowing the user to deploy and run any software, including operating systems and applications. The user does not manage or control the underlying cloud infrastructure, but has control over operating systems, storage, deployed applications, and possibly limited control over selected network components (e.g., host firewalls). The deployment models are as follows:

[0054] Private Cloud: The cloud infrastructure is operated solely for an organization. It can be managed by the organization or a third party and can be located on its own premises or on a third-party site.

[0055] Community Cloud: The cloud infrastructure is shared by multiple organizations and supports a specific user community with common concerns (e.g., mission, security requirements, policies, and compliance considerations). It can be managed by the organizations or a third party and can be located on their own premises or on someone else's premises.

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

[0057] Hybrid Cloud: Cloud infrastructure is a composition of two or more clouds (private, community, or public) that remain separate entities but are interconnected by a standardized or proprietary technology that enables data and application portability (e.g., cloud targeting for load balancing between clouds).

[0058] A cloud computing environment is service-oriented with a focus on state independence, low coupling, modularity, and semantic interoperability. At the heart of cloud computing lies an infrastructure comprising a network of interconnected nodes.

[0059] With reference to Fig. 3, an illustrative cloud computing environment 50 is depicted. As shown, the cloud computing environment 50 includes one or more cloud computing nodes 10 with which local computing devices used by cloud users, such as a personal digital assistant (PDA) or mobile phone 54A, a desktop computer 54B, a laptop computer 54C, and / or an automotive computer system 54N, can communicate. The nodes 10 can communicate with each other. They can be physically or virtually grouped into one or more networks such as private, community, public, or hybrid clouds (not shown), as described above, or a combination thereof. This enables the cloud computing environment 50 to offer infrastructure, platforms, and / or software as a service for which a cloud user does not need to maintain resources on a local computing device.It should be noted that the types of computing devices 54A through N shown in FIG. 4 are merely illustrative, and that the computing nodes 10 and the cloud computing environment 50 may communicate with any type of computer-based device via any type of network and / or via any type of network-accessible connection (e.g., using a web browser).

[0060] With reference to Fig. 4 shows a set of functional abstraction layers used by the cloud computing environment 50 ( Fig. 3) are provided. It should be clear from the outset that the Fig. The components, layers, and functions shown in Figure 4 are intended to be illustrative only, and some embodiments of the invention are not limited thereto. As shown, the following layers and corresponding functions are provided:

[0061] A hardware and software layer 60 includes hardware and software components. Examples of hardware components include: mainframe computers 61; Reduced Instruction Set Computer (RISC) architecture-based servers 62; servers 63; blade servers 64; storage units 65; and networks and network components 66. In some embodiments, software components include network application server software 67 and database software 68.

[0062] A virtualization layer 70 provides an abstraction layer from which the following examples of virtual entities can be deployed: virtual servers 71, virtual storage 72, virtual networks 73, including virtual private networks, virtual applications and operating systems 74; and virtual clients 75.

[0063] In one example, the management layer 80 may provide the functions described below. Resource provisioning 81 provides for the dynamic procurement of computing resources and other resources used to perform tasks within the cloud computing environment. Metering and pricing 82 provides cost tracking when using resources within the cloud computing environment, as well as billing or invoicing for the consumption of those resources. In one example, these resources may include application software licenses. Security provides identity verification for cloud users and tasks, as well as protection for data and other resources. A user portal 83 provides users and system administrators with access to the cloud computing environment.Service level management 84 provides the allocation and management of cloud computing resources so that the required service objectives are met. Service level agreement (SLA) planning and fulfillment 85 provides the pre-arranging and procurement of cloud computing resources for which future requirements are anticipated, in accordance with an SLA.

[0064] A workload layer 90 provides examples of the functionality for which the cloud computing environment can be used. Examples of workloads and functions that can be provided by this layer include: mapping and navigation 91; software development and lifecycle management 92; providing education in virtual classrooms 93; data analytics processing 94; transaction processing 95; and estimating computing resource consumption 96.

[0065] With reference to Fig. 5 is a high-level block diagram of an exemplary computer system 501 that may be configured to perform various aspects of the present disclosure, including, for example, the Fig. 2. The exemplary computer system 501 may be used to implement one or more of the methods or modules described herein and any associated functions or operations (e.g., using one or more processor circuits or computer processors of the computer) in accordance with embodiments of the present disclosure. In some embodiments, the illustrative components of the computer system 501 may include one or more CPUs 502, a memory subsystem 504, a terminal interface 512, a storage interface 514, an I / O (input / output) device interface 516, and a network interface 518, all of which may be interconnected for data exchange directly or indirectly via a memory bus 503, an I / O bus 508, and an I / O bus interface unit 510 for data transfer between the components.

[0066] The computer system 501 may include one or more programmable, multi-purpose, central processing units (CPUs) 502A, 502B, 502C, and 502D, referred to generally herein as CPU 502. In some embodiments, the computer system 501 may include multiple processors, as is typical for a relatively large system; however, in other embodiments, the computer system 501 may alternatively consist of a single CPU system. Each CPU 502 may execute instructions stored in the memory subsystem 504 and may have one or more levels of integrated cache. The memory subsystem 504 may include instructions 506 that, when executed by the processor 502, cause the processor 502 to perform some or all of the operations described above with respect to Fig. 2 described functions.

[0067] In some embodiments, memory subsystem 504 may include a semiconductor random access memory, a storage device, or a storage medium (either volatile or non-volatile) for storing data and programs. In some embodiments, memory subsystem 504 may represent all virtual memory of computer system 501 and may also include the virtual memory of other computer systems coupled to computer system 501 or connected via a network. While memory subsystem 504 may conceptually be a single monolithic unit, in some embodiments, memory subsystem 504 may be a more complex arrangement, such as a hierarchy of caches and other storage devices.For example, the memory may be present in multiple levels of caches, and these caches may further be divided by function, so that one cache stores instructions while another stores non-instruction data used by the processor or processors. The memory may further be distributed and associated with different CPUs or groups of CPUs, as is known in any of various so-called NUMA (Non-Uniform Memory Access) computer architectures. In some embodiments, main memory or memory subsystem 504 may include elements for controlling and scheduling the memory used by CPU 502. This may include a memory controller 505.

[0068] Although the memory bus 503 in Fig. 5 as a single bus structure providing a direct data transmission path between CPUs 502, memory subsystem 504, and I / O bus interface 510, in some embodiments, memory bus 503 may comprise multiple different buses or data transmission paths arranged in any number of different forms, such as point-to-point connections in hierarchical, star, or mesh configurations, multiple hierarchical buses, parallel and redundant paths, or any other suitable type of configuration. Furthermore, while I / O bus interface 510 and I / O bus 508 are shown as a single respective unit, in some embodiments, computer system 501 may include multiple I / O bus interface units 510, multiple I / O buses 508, or both.Furthermore, while multiple I / O interface units are shown separating the I / O bus 508 from various data transmission paths leading to the various I / O units, in other embodiments, some or all of the I / O units may be directly connected to one or more system I / O buses.

[0069] In some embodiments, computer system 501 may be a multi-user mainframe computer system, a single-user system, or a server computer or similar device that has little or no direct user interface but receives requests from other computer systems (clients). Furthermore, in some embodiments, computer system 501 may be implemented as a desktop computer, portable computer, laptop or notebook computer, tablet computer, handheld computer, telephone, smartphone, mobile device, or any other suitable type of electronic device.

[0070] It is pointed out that Fig. 5 is intended to illustrate the characteristic exemplary components of the exemplary computer system 501. However, in some embodiments, individual components may have a higher or lower complexity than in Fig. 5 is shown, other than those shown in Fig. 5 or additional components may be present, and the number, type, and configuration of such components may vary.

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

[0072] The computer-readable storage medium may be any physical device that can retain and store instructions for use by an instruction-executing system. The computer-readable storage medium may 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 thereof. A non-exhaustive list of more specific examples of the computer-readable storage medium includes the following: a removable computer diskette, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM).Flash memory), static random access memory (SRAM), removable compact disk read-only memory (CD-ROM), digital versatile disc (DVD), memory stick, floppy disk, mechanically encoded device such as punched cards or raised structures in a groove on which instructions are stored, and any suitable combination thereof. A computer-readable storage medium, as used herein, shall not be construed as carrying transient signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., pulses of light traveling through fiber optic cables), or electrical signals carried through a wire.

[0073] Computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to respective computing / processing units or to an external computer or storage unit via a network such as the Internet, a local area network, a wide area network, and / or a wireless network. The network may include copper transmission cables, fiber optic transmission lines, wireless transmission, routers, firewalls, switching units, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing unit receives computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium within the respective computing / processing unit.

[0074] Computer-readable program instructions for performing operations of the present invention may be assembly language instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, or either source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, or the like, as well as conventional procedural programming languages ​​such as the C programming language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on the remote computer or server.In the latter case, the remote computer may be connected to the user's computer through 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 (for example, over the Internet using an Internet service provider). In some embodiments, electronic circuits, including, for example, programmable logic circuits, field programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), may execute the computer-readable program instructions by utilizing state information of the computer-readable program instructions to personalize the electronic circuits to perform aspects of the present invention.

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

[0076] These computer-readable program instructions may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that the instructions, executed by the processor of the computer or other programmable data processing apparatus, produce a means for implementing the functions / steps defined in the flowchart block(s) and / or block diagrams.These computer-readable program instructions may also be stored on a computer-readable storage medium that can direct a computer, a programmable data processing apparatus, and / or other devices to function in a particular manner, such that the computer-readable storage medium having instructions stored thereon comprises an article of manufacture, including instructions that implement aspects of the function / step specified in the flowchart block(s) and / or block diagrams.

[0077] The computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of process steps to be performed on the computer, other programmable apparatus, or other device to produce a computer-executable process such that the instructions executing on the computer, other programmable apparatus, or other device implement the functions / steps defined in the block(s) of flowcharts and / or block diagrams.

[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 flowcharts or block diagrams may represent a module, segment, or portion of instructions comprising one or more executable instructions for performing the particular logical function(s). In some alternative implementations, the functions specified in the block may occur in a different order than shown in the figures. For example, two blocks shown in succession may actually execute substantially concurrently, or the blocks may sometimes execute in reverse order depending on the corresponding functionality.It should also be noted that each block of the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented by special purpose hardware-based systems that perform the specified functions or steps, or by combinations of special purpose hardware and computer instructions.

[0079] The descriptions of the various embodiments of the present invention have been presented for the purpose of illustration, but are not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein has been chosen to best explain the principles of the embodiments, practical application, or technical improvement over technologies found in the marketplace, or to enable others skilled in the art to understand the embodiments presented herein.

Claims

[1] A method (200) for estimating the use of computing resources, comprising: Providing (205) a set of virtual machines (125A, 125B, 125C) on a hypervisor (120); Performing one or more local surveys on each virtual machine to generate data (240) on the use of computing resources (210); generating (215) a first stability factor comprising a metric related to consistency of resource usage in response to receiving data about hypervisor resource usage from the hypervisor; Determining (220), based on computing resource usage data, hypervisor resource usage data, and the first stability factor, that a standard usage metric of the computing resources exceeds a threshold, wherein the standard usage metric reflects an average of historical computing resource usage data and the threshold defines a reasonable range for the standard usage metric; generating (225) a customized computing resource usage metric to be used instead of the standard usage metric based on at least the computing resource usage data in response to the determining; and Informing (230) a user about the tailored usage metric. [2] The method of claim 1, wherein the tailored usage metric reflects an average for a historical set of stabilized data on the usage of computing resources. [3] The method of claim 1, wherein the tailored usage metric is further based on the set of hypervisor resource usage data. [4] The method of claim 1, further comprising: Determining, based on a second set of data about the utilization of computing resources, a second set of data about the utilization of hypervisor resources, and a second stability factor, that the standard utilization metric does not exceed the threshold; and Inform the user of the default usage metric in response to the non-exceedance. [5] The method of claim 4, wherein the second stability factor comprises a set of historical license capacity usage metrics and a set of real-time license capacity usage metrics. [6] The method of claim 5, wherein software is provided as a service to generate the customized usage metric. [7] A computer program product for estimating the use of computing resources, the computer program product comprising a computer-readable storage medium having program instructions (506) thereon, the program instructions being executable by a device to cause the device to: Providing (205) a set of virtual machines (125A, 125B, 125C) on a hypervisor (120); Performing one or more local surveys on each virtual machine to generate data (240) on the use of computing resources (210); generating (215) a first stability factor comprising a metric related to consistency of resource usage in response to receiving data about hypervisor resource usage from the hypervisor; Determining (220), based on the computing resource usage data, hypervisor resource usage data, and the first stability factor, that a standard usage metric of the computing resources exceeds a threshold, wherein the standard usage metric reflects an average of historical computing resource usage data and the threshold defines a reasonable range for the standard usage metric; generating (225) a customized computing resource usage metric to be used instead of the standard usage metric based on at least the first set of computing resource usage data in response to the determining; and Informing (230) a user about the tailored usage metric. [8] System (501) for estimating the use of computing resources, the system comprising: a memory subsystem (504) containing program instructions (506); and a processor (502) communicating with the memory subsystem, wherein the program instructions cause the processor to: Providing (205) a set of virtual machines (125A, 125B, 125C) on a hypervisor (120); Performing one or more local investigations on each virtual machine to obtain data (240) on the use of to generate data processing resources (210); generating (215) a first stability factor comprising a metric related to consistency of resource usage in response to receiving data about hypervisor resource usage from the hypervisor; Determining (220), based on data about the usage of computing resources, data about the usage of hypervisor resources, and the first stability factor, that a standard usage metric of the computing resources exceeds a threshold, wherein the standard usage metric reflects an average of historical data about the usage of computing resources and the threshold defines a reasonable range for the standard usage metric; generating (224) a customized computing resource usage metric to be used in place of the standard usage metric based on at least the first set of computing resource usage data in response to the determining; and Informing (230) a user about the tailored usage metric.

Images