JP2021119502A - Rolling resource credit for scheduling virtual computer resource - Google Patents

Abstract

To provide a method and a system which schedule a virtual computing resource.SOLUTION: A network-based virtual computing resource provider provides a virtual computing instance that implements rolling resource credits for scheduling virtual computing resources. A virtualization manager receives a work request for the virtual computing instance. A resource credit residual is determined for the virtual computing instance. The resource credit residual is stored in a rolling system and unused credits are carried over from a previous period. Thereafter, in generating a scheduling instruction, the resource credit is applied, and a physical resource for performing the work request such as a physical CPU is provided in order to increase utilization of resources according to the number of applied credits. The applied resource credit is then subtracted from the residual credit.SELECTED DRAWING: Figure 3

Description

The advent of virtualization technology for general purpose hardware benefits in managing large computing resources for a large number of customers with diverse needs, which allows different computing resources to be combined with multiple customers. Allows for more efficient and safe sharing. For example, virtualization technology provides each user with one or more virtual machines hosted by a single physical computing machine so that a single physical computing machine can be used by multiple users. Each such virtual machine can be allowed to be shared between, and each such virtual machine provides the user with the illusion that the user is the only operator and administrator of a given hardware computing resource. It is a software simulation that functions as a logical computing system, and at the same time provides application isolation and security between various virtual machines. As another example, virtualization technology allows data storage hardware to be shared among multiple users by providing each user with a virtualized data store that can be distributed across multiple data storage devices. Each such virtualized datastore acts as a separate logical datastore that provides the user with the illusion that the user is the only operator and administrator of the data storage resource.

Virtualization techniques may be used to create many different types of services on client systems or devices, or to perform different functions. For example, virtual machines may be used to implement network-based services for external customers, such as e-commerce platforms. Virtual machines may also be used to further implement services or tools for internal customers, such as information technology (IT) services that are implemented as part of a company's internal network. However, efficient utilization of these virtual resources may require flexible utilization options for many different types of virtual resource workloads. In some environments, multiple virtual machines may be hosted together on a single host, which conflicts with different virtual computing resources that can depend on the same physical computer resources. And conflicts can occur.

It is a graph which illustrates the rolling resource credit remaining amount for the virtual calculation instance which concerns on some embodiments. FIG. 3 is a block diagram illustrating a network-based virtual computing service that provides virtual computing instances that perform rolling resource credits to schedule virtual computer resources, according to some embodiments. FIG. 5 is a block diagram illustrating a virtualization host that implements rolling resource credits to schedule virtual computer resources, according to some embodiments. FIG. 5 is an explanatory diagram of an example of an interface that provides a rolling credit index for a virtual compute instance, according to some embodiments. FIG. 6 is a high-level flow diagram illustrating various methods and techniques for performing rolling computer resource credits to schedule virtual computer resources, according to some embodiments. FIG. 6 is a high-level flow diagram illustrating various methods and techniques for performing rolling computer resource credits to schedule processing resources for virtual computers, according to some embodiments. It is a high level flow diagram illustrating various methods and techniques that reduce or increase the utilization of physical computer resources according to the available resource credits for work requests to virtual computing instances, according to some embodiments. It is a high-level flow diagram illustrating various methods and techniques for recording and utilizing data indicators for virtual compute instances that implement rolling credit resources to schedule virtual computer resources, according to some embodiments. It is a block diagram which illustrates an example of the computing system which concerns on some embodiments.

Those skilled in the art will recognize that embodiments are described herein by way of example for some embodiments and illustrations, but embodiments are not limited to the embodiments or drawings described. The drawings and their detailed description are not intended to limit embodiments to the particular embodiments disclosed, and conversely, all modifications, equivalents and alternatives that fall within the spirit and scope as defined in the appended claims. Please understand that you intend to include the proposal. The headings used herein are used only for the purposes that make up the specification and are not intended to be used to limit the scope of the specification or claims. The word "may" used throughout this application is used in an acceptable sense (ie, meaning "may") rather than in an obligatory sense (ie, meaning "should"). Will be done. Similarly, the words "include", "including", and "includes" mean "include", but are not limited in scope.

The systems and methods described herein may implement rolling resource credits for scheduling virtual computing resources, according to some embodiments. Different clients implementing virtual computing resources have different resource requirements. For example, the workload of a client is unpredictable and may not make efficient use of fixed resources. Virtual compute instances that perform rolling resource credits to schedule virtual computing resources provide dynamic resource utilization without wasting unused fixed resources, providing flexible and high performance. Can be provided. Resource credits are accumulated for individual virtual compute instances. When a virtual compute instance needs to work at high performance, resource credits may be applied to the work, effectively providing full utilization of the underlying physical resources for the duration of the resource credits. .. If a virtual compute instance uses less resources than its shared resources (eg, little or no work in progress), credits may be taken and used for subsequent tasks. The resource can, in various embodiments, be any virtualized computer resource implemented or executed by a managed physical computer resource. Resources include, but are not limited to, processing resources, communication or networking resources and storage resources.

Virtual compute instances may implement rolling resource credits for scheduling virtual computing resources, providing low cost, responsiveness and high performance for a limited period of time. FIG. 1 is a graph illustrating the remaining amount of rolling resource credits for a virtual compute instance, according to some embodiments. Graph 100 illustrates both resource credit usage and resource credit remaining for a compute instance that performs rolling resource credits for scheduling. The initial resource credit balance may be provided 110 (eg, 30 credits) and may be used immediately. In some embodiments, over time, the compute instance may accumulate more credits until it reaches the rolling resource credit limit of 120. This limit can be enforced by excluding certain accumulated resource credits after a period of time (eg, 24 hours). In some embodiments, when applied, resource credits can be guaranteed for a particular time (eg, computer resource credits can be a one minute full utilization of a central processing unit (CPU), a thirty second specific networking channel, or a guarantee. It can provide full use of resources for some other period of use). Resource credits can be deducted from the remaining resource credits when used.

When resource credits are consumed, the virtual computing instance can utilize sufficient resources (eg, CPU core, network interface card function, etc.) when needed to obtain high performance. For example, the amount of credit resource used at time 5 is less than the remaining amount of resource credit at time 5. Therefore, of the current remaining resource credits, more resource credits were available for consumption than were required to perform the task, so the work performed at time 5 is the task period. It was done with full utilization over. In addition, since no further resource credit usage is shown, resource credits continue to be carried forward until the remaining amount limit of 120 is reached, and another work on another compute instance hosted on the next high usage period (or on the same virtualization host). Save additional physical resources due to the request). If there are no resource credits available to perform the task, the Baseline Utilization Guarantee may be further applied to make a work request. In some embodiments, the baseline utilization guarantee can be the amount of time a virtual compute instance can use a resource without spending any credit on the remaining credit resources.

In at least some embodiments, the baseline utilization guarantee may match the resource credit accumulation rate. For example, if the resource credits are equal to the full utilization of 1 minute per hour, the cumulative rate of 6 resource credits per hour is equal to 6 minutes out of 60 minutes, or 10% resource utilization per hour. In this example, the baseline guarantee can be 10% resource utilization per hour. However, in some embodiments, the resource credit accumulation rate may be unrelated to the baseline guarantee (eg, 12 resource credit accumulation rate per hour and 10% baseline guarantee), which causes the compute instance to: Even if a work request is sent to take advantage of the assigned baseline utilization guarantee, the resource credits can still be the remaining resource credits. It should be noted that the above examples are not intended to limit the various methods or combinations in which resource credit accumulation rates and baseline performance can be implemented.

Rolling resource credits for scheduling virtual computer resources can be performed on multiple virtual computing instances hosted on the same virtualization host (as illustrated in FIGS. 2 and 3 described below). Enforcing the rolling resource credit remaining limit 120 may prevent any one compute instance from accumulating sufficient resource credits to interfere with the performance of the work request for the other instance. For example, as illustrated in FIG. 1, when the rolling resource credit limit is set to 144 resource credits, the maximum that any one virtual compute instance can monopolize physical computer resources is 2 hours and 24 minutes ( Resource credit is equivalent to one minute of full utilization of resources).

Note that the above description provides only an example of rolling resource credit remaining and usage for compute instances and is not intended to be limiting. The accumulation rate, initial remaining amount and remaining amount limit can all vary depending on the various amounts of resource credits that can be used.

The present specification then includes a virtual computing resource provider overview, which may perform network entity registration for a network entity handle contained in a network traffic policy implemented on the provider network. Various examples of virtual computing resources are then described, which include different component / module or component / module placement that can be utilized as part of the virtual computing resource provider implementation. A number of different methods and techniques for performing network entity registration for network entity handles contained in the network traffic policy implemented on the provider network are subsequently described, some of which are illustrated in the attached flow diagram. Finally, an example description of a computing system in which various components, modules, systems, devices and / or nodes can be implemented is provided. Various examples are provided throughout the specification.

FIG. 2 is a block diagram illustrating a network-based virtual computing service that provides virtual computing instances that perform rolling resource credits for scheduling virtual computing resources, according to some embodiments. The network-based virtual computing service 200 is configured by an entity such as a company or public institution and is accessible via the Internet and / or other networks (various types of cloud-based computing). Services or storage services, etc.) may be provided to the client 202. The network-based virtual computing service 200 is a physical and / or virtualized computer server, which is required to implement and distribute the infrastructure and services provided by the network-based virtual computing service 200. It can contain a myriad of data centers that host various resource pools such as storage devices, a collection of networking devices, and so on. In some embodiments, the network-based virtual computing service 200 may provide computing resources. These computing resources may, in some embodiments, be supplied to the client in units called "instances" 234, such as virtual computing instances.

In various embodiments, the network-based virtual computing service 200 may implement a control plane 210 to manage the computing resource supply provided by the network-based virtual computing service 200 to the client 202. The control plane 210 may implement a variety of different components to manage the computing resource supply. The control plane 210 may be implemented across various servers, nodes or other computing systems or devices, such as the computing system 1000 described below with respect to FIG. It is noted that if one or more instances of a given component can be present, reference to that component in the present specification can refer to either one or more. However, the use of either form is not intended to exclude the other.

In at least some embodiments, the control plane 210 may implement the interface 212. Interface 212 may be configured to process incoming requests received over network 260 and direct the requests to the appropriate components for further processing. In at least some embodiments, the interface 212 may be a network-based interface, such as a graphical interface (eg, as part of a management control panel or website) and / or various application programming interface (API) commands. May be implemented as a programmatic interface. In various embodiments, interface 212 may be implemented as part of a front-end module or component that issues requests to various other components such as resource management 214, reservation management 216, resource monitoring 218 and billing 220. .. Client 202, in various embodiments, may not be able to directly arrange, launch, or configure resources, but is an exemplary component (or other component, function, or service not exemplified). The request may be sent to the control plane 210 so that may perform the requested action.

The control plane 210 implements the resource management module 214 to manage access to computing resources provided by the provider network, capacity of computing resources, mapping to computing resources, and other controls or instructions for computing resources. obtain. In at least some embodiments, the resource management module 214 may provide both direct sales and third party resale markets for capacity reservations (eg, reserved compute instances). For example, the resource management module 214, through interface 212, allows the client 202 to grasp and select the capacity of computing resources from either the initial sales marketplace or the resale marketplace, and purchase and / or reserve access. It may be possible to do this via a web page or via an API. For example, the resource management component may provide a list of different available compute instance types via interface 212, each with a different credit accumulation rate. Additionally, in some embodiments, the resource management module 214 is provided (via credit accumulation rate for instance type, etc.) for a specified purchase amount or scheme (eg, lump sum payment, additional recurring payment, etc.). It may be configured to provide purchase credits (in addition to the credits made). For example, the resource management module 214 may be configured to receive a credit purchase request (eg, an API request) and populate the remaining virtual instance with purchased credits. Similarly, resource management module 214 may be configured to handle requests that increase the credit accumulation rate for a particular instance. Resource management 214 may further provide and / or implement access to the interface to the client 202 via a set of flexible resource reservations, controls and interfaces 212. For example, the resource management module 214 may provide the client 202 with authentication information or permissions so that the compute instance control operation / client can interact with the computing resource in use.

In various embodiments, the booking management module 216 may be configured in various embodiments to handle different pricing schemes (at least for the initial sales marketplace) of instance 234. For example, in some embodiments, the network-based virtual computing service 200 may include, for example, period reservations (ie, reserved compute instances), on-demand resource allocation, or spot price-based resource allocation. Different purchasing modes (which may be further referred to herein as reservation modes) may be supported. With long-term reservation mode, the client makes a low-cost, one-time prepayment to a compute instance or other computing resource, reserves the compute instance for a specified period of time, such as one or three years, and that instance. You will be able to pay a low hourly rate to and your clients will be guaranteed to have reserved instances available over the booking period. On-demand mode allows clients to pay for capacity hourly (or in any suitable time unit) without long-term commitments or prepayments. In spot price mode, the client can specify the highest price per unit time that he or she wants to pay for a particular type of compute instance or other computing resource, and the client's highest price is If, at least in part, the dynamic spot price determined by supply and demand is exceeded, that type of resource will be provided to the client.

Spot prices can be much lower than prices in on-demand mode during periods when the supply of the requested resource type exceeds demand. In some implementations, if the spot price increases above the highest limit specified by the client, the resource allocation may be interrupted, that is, the resource instance previously assigned to the client is the resource management module. It may be recovered by 330 or assigned to someone else who wants to pay a higher price. Resource capacity reservations may further update the control plane datastore 222 to reflect changes in ownership, client usage, client accounts or other resource information.

In various embodiments, the control plane 210 may be implemented by the resource monitoring module 218. The resource monitoring module 218 tracks the consumption of various computing instances (eg, resource credit balance, resource credit consumption) consumed for different virtual computer resources, clients, user accounts and / or specific instances. obtain. In at least some embodiments, the resource monitoring module 218 performs various management actions to stop, resolve, manage, or otherwise respond to various different scenarios of all virtualized hosts 230 and instance 234 in a group. Can be done. The resource monitoring module 218 may further provide the client 202 (s) with management of client-configured alarms and access to various indicator data. FIG. 8, described in detail below, provides further examples of various techniques that the resource monitoring module can perform.

In various embodiments, the control plane 210 may implement the billing management module 220. The billing management module 220 sends a billing event (eg, any other factor that generates a claim for a particular date, time, usage, billing amount or a billing amount for a particular user account or a payment account linked to a user account). It can be configured to detect. In response to the detection of billing events, the billing management module may be configured to generate billing amounts for user accounts or payment accounts linked to user accounts.

The virtual compute instance 234 is, for example, a specified computing power (which may be specified by indicating the type and number of CPUs, main memory size, etc.) and a specified software stack (eg, thereby higher than the hypervisor). It may include one or more servers with a specific version of the operating system that can run on. In different embodiments, a number of different types of computing devices, including general purpose or dedicated computer servers, storage devices, network devices, etc., are used alone or in combination to implement compute instances 234 of the network-based virtual computing service 200. May be used. In some embodiments, the instance client 202 or any other user may be configured (and / or allowed) to direct network traffic to compute instance 234.

Computation Instance 234 may operate or implement a variety of different platforms, such as Application Server Instances, Java® Virtual Machines (JVM), General Purpose or Dedicated Operating Systems, Rubi, Perl, Python. , C, C ++ and other platforms that support various interpreter or compiler programming languages, or high performance computing platforms, for example, to perform client 202 applications without the need for client 202 to access instance 234. It is suitable for. There can be a variety of different types of compute instances. In at least some embodiments, there may be compute instances that perform rolling resource credit balances to schedule virtual computer resource operations. This type of instance runs on the basis of resource credits, where resource credits take advantage of the amount of time an instance can spend working on physical resources (eg, physical CPU processing time, network communication channels). Time to do, etc.). The more resource credits an instance has for computer resources, the longer the physical resources can spend doing their work (increasing performance). Resource credits may be provided at instance startup and may be defined as utilization time (eg, CPU time, such as CPU-minutes), where utilization time is the physical resource on which the virtual resources of an instance are based. Can represent the time that can be spent performing a task.

In various embodiments, resource credits may represent time or resource utilization that exceeds the baseline utilization guarantee. For example, a compute instance may have a 10% baseline utilization guarantee for resources, and therefore resource credits may be increased to exceed 10% resource utilization. Even if there are no remaining resource credits, utilization can still be guaranteed for compute instances at a 10% baseline. Credit consumption can only occur when an instance requires physical resources to do work that exceeds baseline performance. In some embodiments, credits can be renewed or accumulated in the resource credit balance, regardless of whether the compute instance sends a work request that consumes the resource's baseline utilization guarantee.

Different types of compute instances may be provided that perform rolling resource credits for scheduling computer resources. Different compute instances can have a certain number of virtual CPU cores, memory, cache, storage, networking and any other performance characteristics. The configuration of a compute instance may further include its location, in a particular data center, available zones, geography, location, etc. and (in the case of reserved compute instances) the length of the reservation period. Different compute instances may have different resource credit accumulation rates for different virtual resources, or may be a large number of resource credits accumulating in the current remaining amount of resource credits maintained for the compute instance. For example, in some embodiments, one type of compute instance may accumulate 6 credits per hour for one virtual computer resource, while another type of compute instance may accumulate the same type of virtual computer resource. You may accumulate 24 credits per hour. In another example, the resource credit accumulation rate for one resource (eg, vCPU) of the same virtual computing instance can be different from the resource credit accumulation rate for another virtual computer resource (eg, networking channel). In some embodiments, for a plurality of different virtual computer resources used by a virtual compute instance, a plurality of different resource credit balances may be maintained for that virtual compute instance. Baseline performance guarantees may be further implemented for each of the virtual computer resources, and baseline performance guarantees may be different for different instance types, as well as for each individual virtual computer resource.

Baseline performance guarantees may be included with resource credit accumulation rates in some embodiments. Thus, in one example, the instance type has a specific resource credit accumulation rate and guaranteed baseline performance for processing, as well as another specific resource credit accumulation rate and guaranteed baseline performance rate for networking channels. Can include. As such, the network-based virtual computing service 200 may provide many different types of instances with different combinations of resource credit accumulation rates and baseline guarantees for different virtual computer resources. These different configurations can be priced separately according to resource credit accumulation rates and baseline performance rates as well as various physical and / or virtual capacities. In some embodiments, the virtual compute instance may be booked and / or utilized at an hourly price. On the other hand, long-term booking instance configurations may utilize different pricing schemes, but also include credit accumulation rates and baseline performance guarantees.

As illustrated in FIG. 2, in some embodiments, the virtualization hosts 230, such as the virtualization hosts 230a, 230b-230n, may implement and / or manage a plurality of compute instances 234, with reference to FIG. 9 below. It may be one or more computing devices such as the described computing system 1000. The virtualization host 230 may include virtualization management modules 232 such as virtualization management modules 232a, 232b to 232n, and can instantiate and manage virtual machines or compute instances 234 accessible to many different clients. The virtualization management module 232 may include, for example, an operating system hypervisor and management instance, and in some implementations it may be referred to as "domain zero" or "dom0". The dom0 operating system is inaccessible to clients and instead operates compute instance 234, but with a variety of network providers, including handling network traffic directed to or from compute instance 234. Takes on the management or control plane operation instead.

Client 202 (s) may include any type of client that can be configured to send a request to the network-based virtual computing service 200. For example, a given client 202 may include a suitable version of a web browser, or a plug-in module or other configured to run within or as an extension to the execution environment provided by the web browser. May include code modules of the following types. Alternatively, the client 202 can be an application such as a dashboard application (or the user interface of the dashboard application), a media application, an office application, or any other application that may utilize the compute instance 234 to perform various actions. It may be included. In some embodiments, such applications do not necessarily implement full browser support for network-based data of any kind, but have sufficient protocol support (eg, preferred) to generate and process network-based service requests. Support for different versions of the Hypertext Transfer Protocol (HTTP)) may be included. In some embodiments, the client 202 is a representational state transfer (REST) type network-based service architecture, a document or message-based network-based service architecture, or another preferred network-based service. It may be configured to generate network-based service requests according to the architecture. In some embodiments, the client 202 (eg, compute client) leverages the compute resources provided by compute instance 324 to compute instance 234 in a manner transparent to application implementation on client 202. It may be configured to provide access.

Client 202 may transmit network-based service requests over network 260 to network-based virtual computing service 200. In various embodiments, the network 260 may include any suitable combination of networking hardware and protocols required to build network-based communication between the client 202 and the network-based virtual computing service 200. .. For example, network 260 may generally include various telecommunications networks and service providers that collectively implement the Internet. The network 260 may further include a private network such as a local area network (LAN) or wide area network (WAN), as well as a public or private wireless network. For example, both a given client 202 and a network-based virtual computing service 200 may be deployed within an enterprise, each with its own internal network. In such an embodiment, the network 260 is the hardware required to build a networking link between a given client 202 and the Internet, as well as between the Internet and the network-based virtual computing service 200 (eg, a proxy). , Routers, switches, load balancers, proxy servers, etc.) and software (eg, protocol stacks, accounting software, firewall / security software, etc.). It is noted that in some embodiments, the client 202 may use a private network rather than the public internet to communicate with the network-based virtual computing service 200.

FIG. 3 is a block diagram illustrating a virtualized host that implements rolling resource credits to schedule virtual computer resources, according to some embodiments. As described in FIG. 2 above, a virtualized host can act as a host platform for one or more virtual computing instances. These virtual computing instances can take advantage of virtualized hardware interfaces to perform a variety of tasks, functions, services and / or applications. As part of performing these tasks, virtualized computer resources are implemented on virtualized hosts to work on their respective physical computer resources for each compute instance (eg, virtualized computer resources). , A virtual central processing unit (s) (vCPU) that can function as a virtual proxy for a physical CPU (s).

FIG. 3 illustrates the virtualization host 310. The virtualization host 310 may host compute instances 330a, 330b, 330c-330n. In at least some embodiments, the compute instance 330 may be the same type of compute instance. In FIG. 3, compute instance 330 is a compute instance that performs rolling resource credits for scheduling virtual computer resources. The virtualization host 310 provides various interfaces (eg, various hardware components, processors, I / O devices, networking devices, etc.) between the virtual computing instance 330 and the physical computing resource (s) 340. A virtualization management module 320 that can be processed may be further implemented.

In FIG. 3, the virtualization management module 320 may implement the rolling resource credit remaining amount scheduler 324. The Rolling Resource Credit Remaining Scheduler 324 may act as a meta-scheduler, managing, tracking, applying, deducting, and / or otherwise processing all resource credit remaining for each compute instance 330. In various embodiments, the rolling resource credit remaining scheduler 324 may be configured to receive a virtual compute resource work request 332 from the compute instance. Each work request 332 can be directed towards the virtual computer resource corresponding to the compute instance that sent the work. For each request 332, the rolling resource credit remaining amount scheduler now determines the current resource credit remaining amount for the requesting compute instance 330 and generates a scheduling instruction to apply the resource credits when making a work request. Can be configured. In some embodiments, the rolling resource credit residual scheduler 324 executes a scheduling instruction or orders the execution of a scheduling instruction to direct a work request to the physical computing resource 340 underlying the execution target. , Or can be sent. For example, in some embodiments, different hardware queues are implemented and the rolling resource credit remaining amount scheduler 324 follows the applied resource credits (eg, queuing tasks according to the amount of time applied resource credits). , Can be used to place tasks for making work requests in queues. However, in some embodiments, the resource scheduling instruction may be sent to the virtual computing resource scheduler 322, the virtual computing resource scheduler 322 may be implemented on the virtualization host 310, such as a physical CPU (s). It may be a scheduler for various resources 340. The rolling resource credit remaining amount scheduler 324 applies the resource credits, deducts the resource credits, and / or otherwise ensures that the work request is performed according to the applied resource credits, FIGS. May be configured to perform the various techniques described below.

In some embodiments, in response to receiving a scheduling instruction, the virtual computing resource scheduler 322, in various embodiments, issues a physical scheduling instruction for work request 336, such as a physical CPU (s). Can be provided for physical computing resources. In at least some embodiments, the virtual compute resource scheduler 322 may be a credit-based scheduler for one or more CPUs.

The rolling resource credit remaining amount scheduler 324 may further report the credit remaining amount and usage index 362 to the monitoring agent 326, which in turn reports these indicators to any other host index 364 (health information). Etc.) and may be reported to the resource monitoring module 218.

As mentioned above with respect to FIG. 2, a network-based interface to a virtual computing resource provider can be graphically implemented. FIG. 4 is an explanatory diagram of an example of an interface that provides a rolling credit index for a virtual compute instance, according to some embodiments. The rolling resource credit interface 400 can be implemented as a network-based site accessible to various clients. In some embodiments, the rolling resource credit interface 400 is as a downloadable application or a locally executed application that can communicate with a network-based virtual computing resource provider via a programmatic interface such as an API. Can be implemented.

Area 410 illustrates a list of various instances in which indicator data can be displayed. Various different user interface elements such as selectors 412a, 412b, 412c, 414a, 414b and 414c may be implemented to indicate which physical resources and specific instance data should be read. Area 420 illustrates different types of indicator data that may be selected for display. For example, in some embodiments, the resource credit remaining index 422 for a particular instance and the resource credit usage 424 by the selected instance may be selected. In some embodiments, the credit renewal rate for a particular instance may be exemplified. Area 430 may represent an instance index display area. The retrieved instance indicators may be displayed in various formats, such as an exemplary line graph, diagram, table or any other diagram or text data representation technique. Area 440 may represent different user interface elements for changing the format of the displayed indicator data. For example, when display setting 444 is selected, a pop window or dialog box may open, which may allow modification of different display settings, such as the time range for displaying data. When the indicator element 442 is selected, the changes made may be made to generate or regenerate the data displayed on the instance indicator display 430. The export metric 446 element may be configured to provide various mechanisms for extracting raw metric data downloaded or stored at a location specified by the user (eg, opening a file dialog window). Tool element 448 may be selectable to perform a variety of different tools, analyzes or other recommended engines based on the indicator data. For example, a tool may be selected that recommends whether to change the instance type (eg, to a larger or smaller burst processing instance).

It should be noted that the illustrations and accompanying descriptions in FIG. 4 are intended only to provide an example of a graphical user interface. Various other configurations and interfaces may be implemented that do not include a graphical interface, and therefore the above examples are not intended to be limiting. For example, various requests for the data, metrics or other information described above may be requested by the virtual computing resource provider via a programmatic interface (API) and the raw data is returned to the requesting client. May be done. For example, if a client requests credit usage and renewal rate for a particular compute instance through the API of a virtual computing resource provider, metrics or tracking information for that client may be provided to the client.

An example of performing rolling resource credits to schedule the virtual computing resources described above with respect to FIGS. 2-4 was given for virtual computing resources provided by a network-based computing resource service. Various other types or configurations of virtual computing resources may implement these techniques, which may or may not be supplied as part of a network-based service. For example, other virtual computing resources may want to be available at a high performance level for burst processing or other burst utilization in a shorter period of time, eg, implementing rolling resource credits to schedule virtual computing resources. Can be done. FIG. 5 is a high level flow diagram illustrating various methods and techniques for performing rolling resource credits to schedule virtual computer resources, according to some embodiments. These techniques can be performed using various components of the network-based virtual computing services described above with respect to FIGS. 2-4 or other virtual computing resource hosts.

As shown in 510, work requests for one or more virtual computer resources can be received by the virtualization host for virtual computing instances. The request can identify virtual computer resources (eg, processing, networking, storage, etc.). The work request can identify the amount of work or task performed to complete the work request.

As shown in 520, the current remaining resource credits for each compute instance of the virtual computer resource can be determined. The resource credit accumulation rate can be, in various embodiments, some resource credits that are added to the current remaining amount of resource credits that are unused during the period. For example, if the resource credit accumulation rate is set to 12 resource credits per hour, then all resource credits not consumed during that time may be added to the total remaining resource credits (eg, out of 12). If 9 is not used, 9 can be added). In some embodiments, the resource credit accumulation rate may match the baseline utilization or performance guarantee for the virtual compute instance. The higher the current resource credit balance, the longer the virtual compute instance can use virtual computer resources to sustain a higher level of performance. Since a plurality of different remaining credit resources may be applied to different virtual computer resources, the determined remaining credit resources may be unique to the virtual computer resource making the work request.

In at least some embodiments, resource credit accumulation may be limited to a particular time period. Therefore, unused resource credits accumulated before the resource credit accumulation period cannot be included in the current remaining resource credits. For example, in some embodiments, the resource credit accumulation time may be 24 hours, excluding any unused resource credits accumulated prior to the 24 hours prior to a given time point. In various embodiments, at least one resource credit available for the current resource credit balance is carried forward from the period preceding the current period.

As shown in 530, the work request may be made based at least in part on generating a scheduling instruction and applying one or more resource credits. Therefore, in some embodiments, a scheduling instruction is a physical computer resource (s) that underlies a work request to or as a virtual computer resource (s). You may specify the duration in which is used. In some embodiments, the generated scheduling instructions may be implemented as tasks or hardware queues for physical computer resources (s). In some embodiments, another scheduler or virtual computer resource driver or manager may receive instructions as inputs, parameters and / or other information, as well as work requests on physical resources (s). Command the execution of. FIG. 7, described below, describes various techniques for applying resource credits available when resource credits are not available to make work requests, as well as for handling scenarios. As shown in 540, the current remaining resource credits may be updated in order to deduct the applied resource credits (s).

It should be noted that the various elements described in FIG. 5 may be repeated multiple times in some embodiments to make work requests for different virtual computer resources that depend on different physical resources. sea bream. In addition, different sorts of elements may be performed. Therefore, the examples and the above description are not intended to be limiting.

FIG. 6 illustrates an example for performing the various techniques described above with respect to FIG. 5 to process a resource. As shown in 610, work requests to one or more virtual central processing units (vCPUs) of a virtual compute instance can be received by the virtualization manager for the virtualization host that hosts the virtual compute instance. The work request may target a particular process, task or other action performed by one or more vCPUs of the virtual compute instance. For example, a particular process may be to execute one or more instructions that implement a particular program or application performed or executed by a virtual compute instance. The work request may, in some embodiments, indicate the processing load or processing amount used.

As shown in 620, the current remaining amount of resource credits for the calculation instance that accumulates resource credits for the idle vCPU period may be determined according to the resource credit accumulation rate. As mentioned above, the resource credit accumulation rate can be, in various embodiments, some resource credits that are added to the current remaining resource credits for the virtual instance that is idle during the period. For example, if the resource credit accumulation rate is set to 12 resource credits per hour, then all resource credits not consumed during that time may be added to the total remaining resource credits (eg, out of 12). If 9 is not used, 9 can be added). In some embodiments, the resource credit accumulation rate may match the baseline utilization or performance guarantee for the virtual compute instance. For example, if the baseline utilization or performance guarantee for a virtual compute instance is 10% over an hour period, then the virtual compute instance can be said to have an exclusive processing time of 6 minutes on the physical CPU (s). Let's go. If these 6 minutes are not used at all, or only a portion of these 6 minutes are used, the remaining fractions can be effectively carried over to the next period (eg, the next hour). The higher the current resource credit balance, the longer the virtual compute instance can sustain a higher level of performance, as the physical CPU can consume resource credits when performing the required work. Can be.

As shown in 630, in some embodiments, scheduling instructions may be generated to make work requests, at least in part, based on the current remaining resource credits determined. Scheduling instructions can be generated in a format that is sent to a scheduler that schedules tasks or work for one or more physical central processing units (CPUs). These CPUs (s) can actually process the work request that the virtualization host commands its own vCPUs (s), as described above. The instructions themselves may be configured to apply resource credits (if available) to increase the utilization of the physical CPU (s) for the current period. Resource credits can represent the amount of work or time that a physical CPU can be exclusively utilized by a virtual computing host. Therefore, the instruction may be configured to ensure that the scheduler schedules full utilization time equal to the applied resource credits. For example, a scheduler for a physical CPU (s) may be configured to receive different parameters that dictate how work requests for a particular virtual computing instance should be processed. These parameters may include, but are not limited to, time slices, priorities, proportional distributions, accounting periods and / or volume sizing. In at least some embodiments, the scheduler may be a credit-based scheduler that provides a proportional and equitable distribution scheduler. As described below with respect to FIG. 7, if the current resource credit remaining amount of resource credits is exhausted before the work request is completed (or not at the beginning of the work request execution), the generated instruction is based. Perform work requirements according to line performance requirements (eg, 10%, 20% or 40% CPU utilization) or gradually reduce the performance of the work requirements to equalize the baseline performance requirements after a certain period of time. Can be configured as

As shown in 640, in various embodiments, scheduling instructions may then be sent to the scheduler for the physical CPU (s). The transmission of scheduling instructions works by programmatically calling, calling, or invoking the scheduler, transmitting various parameters and / or other information in order to schedule the performance of the work request according to the generated scheduling instructions. It may include making a request. As shown in 550, the current remaining resource credits may be updated to deduct the resource credits applied when making the work request.

It should be noted that the various elements described in FIG. 6 may be repeated multiple times in some embodiments to perform different subparts of the work requirement. In addition, different sorting may be performed, such as updating the remaining resource credits before sending the scheduling instruction to the scheduler. Therefore, the examples and the above description are not intended to be limiting.

As mentioned above, resource credits can increase the amount of time a particular virtual computing instance can utilize physical resources such as one or more CPUs. Conversely, lack of resource credits can reduce the use of physical resources. FIG. 6 is a high-level flow diagram illustrating various methods and techniques for reducing or increasing the utilization of physical computer resources according to the resource credits available for work requests for virtual computing instances, according to some embodiments. be.

As shown in 610, in various embodiments, the current remaining resource credits for the virtual compute instance may be checked in order to apply the resource credits for making the work request. If there are resource credits to apply, as indicated by the positive exit from 620, the resource credits are applied, and as shown in 640, of the physical resources (s) for making work requests to the virtual compute instance. Utilization may be increased. Resource credits can provide additional time to utilize physical resources to make work requests, as previously mentioned. For example, if the baseline processing rate for a virtual compute instance is 6 minutes per hour (eg, 10% utilization), adding additional compute resource credits equivalent to an additional 1 minute can be vCPUs (s). The process utilization rate can be increased to 7 minutes per hour (eg, 11.667% utilization) for the work demands guided towards.

However, as indicated by the negative exit from 620, if there are no resource credits left to apply, the utilization of physical resources to make work requests gradually reaches the baseline utilization rate for virtual resources in the virtual compute instance. Can be reduced to. For example, the current utilization of vCPUs for virtual compute instances (eg, 25%) may spread over a specific period of time (eg, 15 minutes) and gradually decline, with a gradual decline in utilization. Thus, if the baseline utilization rate for vCPUs is 10% in a virtual compute instance, the 15% utilization can be divided into individual changes to a uniform (or nearly uniform) diffusion rate over a 15 minute period. Gradually reducing utilization can prevent virtual compute instances (and any client or system interactions with virtual compute instances) that are deficient in resource credits from facing a sharp performance degradation.

Unlike virtual compute instances, which provide exclusive resources to specific clients, the behavior or use of virtual instances that perform rolling resource credits for scheduling virtual computer resources is the utilization of allocated resources. It may need to be analyzed to determine if it fully meets the needs of a particular client who has purchased or reserved a virtual compute instance. The client or customer may wish to determine whether the client or customer has properly selected a particular type of compute instance that provides rolling resource credits. For example, a customer who has booked a virtual compute resource that provides a medium resource credit accumulation rate may find a smaller or larger virtual compute instance appropriate based on the history of credits used and / or credit balance. It can be determined whether or not. FIG. 8 is a high-level flow diagram illustrating various methods and techniques for recording and utilizing data indicators for virtual compute instances that implement rolling credit resources to schedule virtual computer resources, according to some embodiments. ..

As shown in 810, the credit balance indicator can be recorded for the current resource credit balance over time for the virtual compute instance. The current resource credit balance can be recorded at various accuracy levels. For example, in some embodiments, the current resource credit remaining amount can only be recorded when a change occurs (eg, increasing or decreasing the remaining amount). In another example, there is a very short elapsed period between recording the current resource credit balance, even if no changes occur. In some embodiments, the client, administrator or other user may be able to adjust the accuracy of the time interval in which the data is recorded. The credit balance indicator can be stored in a persistent data storage system such as a database. The data index can be stored in the database so that it can be selectively read. For example, by storing metrics in a database, a particular query retrieves a particular range of information, minimums, maximums or other more specialized or selected datasets without returning metrics for the entire dataset. Can be possible.

As shown in 820, a credit usage index for the applied resource credits may be recorded in order to make work requests to the virtual compute instance over time. Like the credit balance metric, the credit usage metric can be stored or recorded at different times, or stored or recorded in response to different events. For example, in some embodiments, usage values may be recorded each time a particular credit is applied to make a work request. Alternatively, the total usage, such as the amount of credit applied to the entire work request (eg, 30), can be expressed as a single data point. Of course, various other combinations or precisions between these two examples may be implemented (eg, 4 applicable credits out of 9 credits, which is the total cost for the work request, for a particular work request. Record the applied credits used to do some). Similar to the credit balance metric described above, the credit usage metric can be stored to be selectively maintained. For example, by storing metrics in a database, a particular query retrieves a particular range of information, minimums, maximums or other more specialized or selected datasets without returning metrics for the entire dataset. Can be possible.

The metrics recorded for the virtual compute instance can be used in a variety of ways. Live reporting or streaming of metrics can occur, for example, when recording new metrics on dashboards or other user interfaces that provide a glance of current virtual resource information. In particular, in some embodiments, indicators for credit balance and credit usage may be provided to the client on demand. For example, as shown in 830, a request for a credit balance indicator and / or a credit usage indicator for a virtual compute instance may be received via an interface. Similar to interface 212, the interface may be a network-based interface (eg, accessible via a network such as the Internet) and may provide a variety of graphical or programmatic communication methods. For example, in some embodiments, the network-based interface may be an application programming interface (API). A particular request for data may be formalized according to an API that contains various different parameters or constraints for the particular dataset returned. Similarly, a graphical interface that can be hosted or implemented for a website or other viewable application allows the user to select the particular information provided (such as that described above with respect to FIG. 4). It can be possible. In response to the request, as shown in 840, the requested metric (part of the usage metric, no usage metric at all, or all of the usage metric is via a network-based interface (eg,). , API or via a response formalized according to the diagram or textual data displayed for the requester's viewing) can be returned.

In some embodiments, metric data may be analyzed using a variety of different dynamic tools, monitors, components or other devices. In some embodiments, clients in the virtual computing resource provider network may define, modify, or configure alarms and notifications that can be triggered. As shown in 850, in various embodiments, the credit remaining amount index and the user value index for the virtual calculation instance may be monitored. For example, the current value (eg, the current resource credit balance or credit usage value) may be evaluated for a particular change or abrupt change. As shown in 860, the alarm may be triggered, for example, when resource credit usage spikes or exceeds some threshold. Long-term trends and other types of information may be collected from monitoring credit balance and / or credit usage indicators for virtual compute instances. As shown in 860, an alarm may be triggered, for example, to indicate low credit usage (or have a high current resource credit balance for a particular time percentage, such as 98%), which tends to be long-term. More generally, alarms can be configured to evaluate credit balance indicators and / or credit usage indicators in a variety of ways. As shown in the negative exit from 860, monitoring of credit balance indicators and / or usage indicators may continue if the alarm is not triggered.

As shown in the positive exit from 860, in various embodiments, when an alarm is triggered, notification of the triggered alarm may be provided, as shown in 870. For example, a messaging system (eg, voice, text, or email) was used to trigger an alarm to the owner / creator or responsible person (which may be a client / customer of a virtual computing resource provider network). You may notify the instance. In addition to providing alarm notifications, in some embodiments, automatic or programmed actions may be taken to clear or respond to the alarm. For example, if a particular virtual instance sees high resource credit utilization, a virtual compute instance that does some of the work done by the virtual instance by shifting it to another virtual instance on another virtualization host. You may increase the number of.

In addition to providing recorded resource credit remaining and / or resource credit usage metrics to clients or others on a separate virtual computer instance basis, network-based virtual computing service providers or other implementers, operators, The administrator or other control system or agent provides a comprehensive review of credit balance indicators and / or resource credit usage indicators that provide overall insight into the behavior and performance of network-based virtual computing resource providers. You can find out.

For example, in some embodiments, a system administrator, control system, or other component may perform thermal or conflict management to detect a particular virtual compute instance, which is a particular virtual compute instance. Either the service guarantee for the client cannot be met due to receiving excessive traffic, or there may be excessive conflict activity between virtual compute instances on a particular host (eg, conflict). Is. As described above for the resource monitoring module 218 of FIG. 2, the recorded data for each virtual computing instance on the virtualized host can be aggregated together. Then, management decisions regarding virtualized hosts can be made based on the aggregated indicators. For example, when usage indicators for different virtual computing instances on a virtualized host appear at similar times to request work on the vCPU, the usage indicators indicate some level of contention between the virtual instances on that virtualized host. May be shown. If the contention level exceeds some maximum contention threshold, one or more virtualized compute instances may move or resume on different virtualization hosts, freeing up computing resources and requesting the remaining virtual compute instances. It can be done with greater flexibility.

Instead of relying on reporting virtual computing instance behavior (or on its own), in some embodiments, the control plane, system administrator, health component or other system or device launches a benchmark instance. Can be run with other virtual compute instances on the virtualization host. These benchmark instances are of a particular type to test the potential impact of such a request on the performance of the work request for other virtual compute instances, such as requiring a particular size or type of workload from the vCPU. It can be configured to take action. The benchmark instance may be further configured to retrieve the test results of the benchmark instance and report directly to a reporting module or service such as the resource monitoring module 218. It should be noted that the above example is not limited and is intended to be part of many different ways in which the recovered indicators for rolling credit resources can be used.

The embodiments of the present disclosure can be described with the following provisions in mind.
1. 1. A compute node that has at least one processor and memory and implements a virtualized host.
Receiving work requests for one or more central processing units (vCPUs) from a virtual compute instance
The resource credit accumulation rate is applied to the current remaining resource credits, at least in part based on the fixed rate for each period, and at least one of the current remaining resource credits is relative to the period prior to the current period. To calculate the current remaining amount of resource credits for the virtual calculation instance of each of the vCPUs accumulated in the current remaining amount of resource credits.
The one or more scheduling instructions are generated at least in part based on the application of one or more resource credits of the current resource credit remaining amount to the virtual compute instance, and the one or more resources applied to the work request. Each of the credits schedules the work request for performance by leveraging each of the at least one processor of the compute node, correspondingly increasing the utilization of each of the at least one processor for the current period. To generate one or more of the scheduling instructions,
The virtualization host with an executable instruction configured to update the current remaining resource credits to deduct the one or more resource credits applied to make the work request. A system with and.

2. In generating the one or more scheduling instructions, the virtualization host further
After applying the one or more resource credits to the work request,
In response to the determination that the current remaining resource credits do not have any remaining resource credits to apply to the work request, at least one of the respective processors is gradually reduced to baseline utilization for the virtual compute instance. The system according to Clause 1, which is configured to constitute at least a portion of the one or more scheduling instructions.

3. 3. The virtualization host is a monitoring agent configured to track the current resource credit balance for the virtual compute instance over time and the resource credits applied for work requests for the virtual compute instance over time. With
The compute nodes are implemented as part of a plurality of compute nodes that together implement a network-based virtual computing service, and the network-based virtual computing service is a client of the network-based virtual computing service over time. It comprises a network-based interface configured to provide the current resource credit balance for the virtual compute instance and the resource credits applied for the work request for the virtual compute instance over time.
The system described in Clause 1.

4. The virtual computing instance is one of a plurality of different types of virtual computing instances supplied through the network-based virtual computing service, and each of the different types of virtual computing instances has a different resource. The system described in Clause 3 that corresponds to the credit accumulation rate.

5. With one or more computing devices
Receiving work requests for one or more computer resources of virtualized compute instances hosted on the virtualized host in the virtualization manager for the virtualized host.
The resource credit accumulation rate is applied to the current remaining resource credits, at least in part based on the fixed rate for each period, and at least one of the current remaining resource credits is relative to the period prior to the current period. Determining the current remaining resource credits for the virtual compute instance of each of the one or more computer resources accumulated in the current remaining resource credits.
The one or more scheduling instructions are generated at least partially based on the application of one or more resource credits of the current resource credit remaining amount to the virtualized computing instance, and the one or more resources applied to the work request. Each of the credits is one or more physical computer resources implemented as part of the virtualization host that correspondingly increases the utilization of the at least one physical computer resource for the current period. To generate the one or more scheduling instructions to schedule the work request for performance in
A method of updating the current remaining resource credits for the virtual compute instance in order to deduct the one or more resource credits applied to make the work request.

6. The reception, the determination, the generation and the update are made for a plurality of different work requests.
Recording the current resource credit remaining amount determined for each of the plurality of different work requests as a credit remaining amount index, and
The method of Clause 5, further comprising recording one or more of the applied resource credits as a credit usage index for each of the plurality of different work requests.

7. Receiving a request for at least a portion of the credit balance metric for the virtual compute instance through a network-based interface.
The method of Clause 6, further comprising providing at least a portion of the credit balance index for the virtual compute instance via the network-based interface in response to receiving the request.

8. Receiving a request for at least a portion of the credit usage metric for the virtual compute instance through a network-based interface.
The method of Clause 6, further comprising providing at least a portion of the credit usage metric for the virtual compute instance via the network-based interface in response to receiving the request.

9. To monitor the credit remaining amount index or the credit usage index for the virtual calculation instance.
Detecting alarm events for the virtual compute instance, at least in part, based on the monitoring.
The method of Clause 6, further comprising providing notification of the alarm event to the virtual compute instance in response to detection of the alarm event.

10. The generation of the one or more scheduling instructions for transmission to the scheduler
After applying the one or more resource credits to the work request,
Determining that the current remaining resource credits do not have any remaining resource credits to apply to the work request.
The one or more generated so that the utilization of the one or more physical computing resources is gradually reduced to the baseline utilization for the virtual compute instance in response to the determination that there are no remaining resource credits. The method of clause 5, comprising configuring at least one of the scheduling instructions.

11. The one or more computer resources are one or more virtual central processing units (vCPUs), and the one or more physical computer resources are one or more central processing units (CPUs). The method of clause 5, further comprising transmitting one or more scheduling instructions to the scheduler for the one or more physical CPUs.

12. The determination of the current resource credit remaining amount for the one virtual compute instance comprises excluding unused resource credits accumulated before the resource credit accumulation period from the current resource credit remaining amount. The method according to 5.

13. The one or more computer resources are part of a plurality of different computer resources, and each different current resource credit balance is maintained for a different computer resource of the different computer resources and another task. 5. The method of clause 5, wherein the request is received for another computer resource among the plurality of different computer resources, and the determination, generation, and update are made for the other work request.

14. When executed by one or more computing devices, the one or more computing devices
Receiving work requests for one or more computer resources of virtualized compute instances hosted on the virtualized host in the virtualization manager for the virtualized host.
The resource credit accumulation rate is applied to the current remaining resource credits, at least in part based on the fixed rate for each period, and at least one of the current remaining resource credits is relative to the period prior to the current period. Determining the current remaining resource credits for the virtual compute instance of each of the one or more virtual computer resources accumulated in the current remaining resource credits.
The one or more scheduling instructions are generated at least partially based on the application of one or more resource credits of the current resource credit remaining amount to the virtualized computing instance, and the one or more resources applied to the work request. Each of the credits is one or more physical computers implemented as part of the virtualization host that correspondingly increases the utilization of the one or more physical computer resources for the current period. To generate the one or more scheduling instructions to schedule the work request for performance in the resource.
Stores a program instruction to update the current remaining resource credits for the one virtual compute instance in order to deduct the one or more resource credits applied to make the work request. Non-temporary computer-readable storage medium.

15. The program instructions further extend to the one or more computing devices.
The reception, the determination, the generation, the transmission and the update are performed for a plurality of different work requests.
Recording the current resource credit remaining amount determined for each of the plurality of different work requests as a credit remaining amount index, and
The non-temporary computer-readable storage medium according to Clause 14, which causes each of the plurality of different work requests to record one or more applied resource credits as a credit usage index.

16. The program instruction further monitors the one or more computing devices for the credit remaining amount index or the credit usage index for the virtual computing instance.
Detecting alarm events for the virtual compute instance, at least in part, based on the monitoring.
The non-temporary computer-readable storage medium according to Clause 15, which provides notification of the alarm event to the virtual computing instance in response to detection of the alarm event.

17. The non-temporary computer-readable storage medium according to Clause 14, wherein the one or more computational resources are one or more networking resources and the one or more physical computer resources are one or more network communication devices. ..

18. In the generation of the one or more scheduling instructions to be transmitted to the scheduler, the program instructions are sent to the one or more computing devices.
After applying the one or more resource credits to the work request,
Determining that the current remaining resource credits do not have any remaining resource credits to apply to the work request.
The one or more generated schedulings so that the utilization of the one or more physical computer resources is gradually reduced to the baseline utilization for the virtual compute instance in response to the determination that there are no remaining resource credits. The non-temporary computer-readable storage medium according to Clause 14, which constitutes and enforces at least one of the instructions.

19. In the determination of the current resource credit remaining amount for the virtual computing instance, the program instruction causes the unused resource credits accumulated before the resource credit accumulation period in the one or more computing devices to the present. A non-temporary computer-readable storage medium as described in Clause 14, which enforces exclusion from the remaining resource credits of.

20. The virtualization host is implemented as part of a network-based virtual computing service, and the virtual computing instance is of a number of different types of virtual computing instances served through the network-based virtual computing service. The non-temporary computer-readable storage medium according to Clause 14, which is one and each of the different types of virtual computing instances corresponds to a different resource credit accumulation rate.

The methods described herein can be implemented in various embodiments by any combination of hardware and software. For example, in one embodiment, the method may be implemented by a computer system (eg, the computer system of FIG. 9) that includes one or more processors that execute program instructions stored in a computer-readable storage medium coupled to the processor. Program instructions are configured to perform the functionality described herein (eg, the functionality of various servers and other components that implement the network-based virtual computing resource providers described herein). obtain. The various methods illustrated in the drawings and described herein represent examples of embodiments of the method. The order of any method may be changed and various elements may be added, reordered, combined, omitted, modified, etc.

The rolling credit resource embodiment for scheduling virtual computer resources described herein may be performed on one or more computer systems, which may interact with various other devices. .. FIG. 9 is a block diagram illustrating an example of a computer system according to various embodiments. For example, computer system 1000 may be configured to implement compute clusters, distributed key-value data stores, and / or client nodes in different embodiments. The computer system 1000 includes personal computer systems, desktop computers, laptop or notebook computers, mainframe computer systems, handheld computers, workstations, network computers, consumer devices, application servers, storage devices, telephones, mobile phones, or the general public. It can be, but is not limited to, any type of device, including any type of computer device.

The computer system 1000 includes one or more processors 1010 connected to the system memory 1020 via an input / output (I / O) interface 1030 (all of these processors may include a plurality of cores, and the cores thereof). Can be single-threaded or multi-threaded). The computer system 1000 further includes a network interface 1040 coupled to an I / O interface 1030. In various embodiments, the computer system 1000 is a uniprocessor system that includes one processor 1010, or a multiprocessor system that includes several processors 1010 (eg, 2, 4, 8, or other suitable numbers). It may be. Processor 1010 may be any suitable processor capable of executing instructions. For example, in various embodiments, the processor 1010 is a general purpose processor or embedded processor that implements any of various instruction set architectures (ISA) such as x86, PowerPC, SPARC or MIPS ISA or other suitable ISA. It's okay. In a multiprocessor system, each of the processors 1010 can usually implement the same ISA, but not necessarily so. The computer system 1000 further includes one or more network communication devices (eg, network interface 1040) and communicates with other systems and / or components via a communication network (eg, internet, LAN, etc.). For example, a client application running on system 1000 uses network interface 1040 on a single server or cluster of servers that implements one or more of the components of the data warehouse system described herein. You may communicate with the server application executed by. In another example, an instance of a server application running on computer system 1000 can be implemented on another computer system (eg, computer system 1090) using network interface 1040 (or another server application). ) May communicate with other instances.

In the illustrated embodiment, the computer system 1000 further comprises one or more persistent storage devices 1060 and / or one or more I / O devices 1080. In various embodiments, the persistent storage device 1060 may accommodate disk drives, tape drives, solid state memory, other high capacity storage devices, or other persistent storage devices. The computer system 1000 (or a distributed application or operating system running on the system) may optionally store instructions and / or data in the persistent storage device 1060, requiring the stored instructions and / or data. You may search according to. For example, in some embodiments, the computer system 1000 may host a storage system server node, and the persistent storage 1060 may include an SSD attached to that server node.

The computer system 1000 includes one or more system memories 1020, which are configured to store instructions and data accessible by the processor 1010 (s). In various embodiments, the system memory 1020 comprises any suitable memory technology (eg, one or more caches, static random access memory (SRAM), DRAM, RDRAM, EDO RAM, DDR 10 RAM, synchronous dynamic RAM (eg, one or more caches, static random access memory (SRAM), DRAM, RDRAM, EDO RAM, DDR 10 RAM, synchronous dynamic RAM). It can be implemented using SRAM), Rambus RAM, EEPROM, non-volatile / flash memory, or any other type of memory. System memory 1020 may include program instructions 1025 that can be executed by processor 1010 (s) to implement the methods and techniques described herein. In various embodiments, the program instruction 1025 is a platform native binary, any interpreted language such as Java® bytecode, or any other language such as C / C ++, Java®, etc. Or it can be encoded in any combination of them. For example, in the illustrated embodiment, the program instruction 1025 includes, in different embodiments, an executable program instruction to implement the functionality of the virtual computing resource provider network. In some embodiments, program instruction 1025 may implement multiple individual clients, server nodes and / or other components.

In some embodiments, program instruction 1025 may include instructions that can be executed to implement an operating system (not shown), which operating system is UNIX®, LINUX, Solaris®. ), MacOS®, Windows®, and any other operating system. Any or all of the program instructions 1025 may be provided as computer program products or software. This computer program product or software may include a non-temporary computer-readable storage medium in which instructions are stored, and various embodiments may be made by programming a computer system (or other electronic device) using this medium. You may execute the process according to. The non-temporary computer-readable storage medium may include any mechanism for storing information in a form readable by a machine (eg, a computer) (eg, software, processing application). Generally speaking, non-temporary computer-accessible media may include computer-readable storage media or memory media. Such media include magnetic or optical media, such as a disc or DVD / CD-ROM connected to the computer system 1000 via the I / O interface 1030. The non-temporary computer-readable storage medium may also include any volatile or non-volatile medium such as RAM (eg, SDRAM, DDR SDRAM, RDRAM, SRAM, etc.), ROM, and the like. These media may be included as system memory 1020 or another type of memory in some embodiments of computer system 1000. In other embodiments, the program instruction is an optical, acoustic or other form of propagating signal (eg,) transmitted over a communication medium such as a network and / or wireless link such that it can be implemented via network interface 1040. It can be transmitted using carrier waves, infrared signals, digital signals, etc.).

In some embodiments, the system memory 1020 may include a data store 1045, which data store may be configured as described herein. In general, system memory 1020 (eg, data store 1045 in system memory 1020), persistent storage 1060 and / or remote storage 1070 is a data block, a replica of a data block, a data block and / or a meta associated with their state. Data, configuration information, and / or any other information that can be used to implement the methods and techniques described herein may be stored.

In one embodiment, the I / O interface 1030 coordinates I / O traffic between the processor 1010, system memory 1020 and any peripheral device in the system, including through network interface 1040 or other peripheral interfaces. Can be configured as In some embodiments, the I / O interface 1030 performs any required protocol conversion, timing conversion or other data conversion and configures the data signal from one component (eg, system memory 1020) into another. It can be converted into a format suitable for use by the element (eg, processor 1010). In some embodiments, the I / O interface 1030 is mounted through various types of peripheral buses, such as variants of the Peripheral Component Interconnect (PCI) bus standard or the Universal Serial Bus (USB) standard. It can also include device support. In some embodiments, the functionality of the I / O interface 1030 can be divided into two or more separate components, such as a north bridge and a south bridge. Further, in some embodiments, some or all of the functionality of the I / O interface 1030, such as an interface with the system memory 1020, may be incorporated directly into the processor 1010.

The network interface 1040 may be, for example, a computer system 1000 and another computer system 1090, which is one or more storage system server nodes, database engine head nodes and / or clients of the database systems described herein. Can be configured to exchange data with other devices attached to the network, such as. In addition, network interface 1040 may be configured to allow communication between the computer system 1000 and various I / O devices 1050 and / or remote storage 1070. The input / output device 1050, in some embodiments, is a data from one or more display terminals, a keyboard, a keypad, a touchpad, a scanning device, a voice recognition device or an optical recognition device, or one or more computer systems 1000. Other devices suitable for input or search may be included. The plurality of input / output devices 1050 may exist in the computer system 1000, or may be distributed to various nodes of the distributed system including the computer system 1000. In some embodiments, similar input / output devices may be separated from the computer system 1000 and may be connected to one or more nodes of the distributed system, including the computer system 1000, by wire or wirelessly, such as through a network interface 1040. You may interact through. The network interface 1040 may typically support one or more wireless networking protocols (eg, Wi-Fi / IEEE 802.11, or another wireless networking standard). However, in various embodiments, the network interface 1040 may support communication over any suitable wired or wireless general data network, such as other types of Ethernet networks. In addition, the network interface 1040 is via a telecommunications network / telephone network such as an analog voice network or digital fiber communication network, a storage area network such as a fiber channel SAN, or any other suitable type of network and / or protocol. Can support communication. In various embodiments, the computer system 1000 comprises more components, fewer components, or different components (eg, displays, video cards, audio cards, peripherals) than those illustrated in FIG. Other network interfaces such as devices, ATM interfaces, Ethernet interfaces, frame relay interfaces, etc.) may be included.

It is noted that any embodiment of the distributed system described herein, or any component thereof, may be implemented as one or more network-based services. For example, a computing cluster within a computing service may provide a client with a computing service and / or other type of service utilizing the distributed computing system described herein as a network-based service. In some embodiments, network-based services may be implemented by software and / or hardware systems designed to support machine-to-machine interactions that are interoperable over the network. The network-based service may have an interface described in a machine-processable format, such as a Web Services Description Language (WSDL). Other systems may interact with the network-based service in a manner defined by describing the interface of the network-based service. Again, for example, a network-based service may define different behaviors that other systems can call, and specifics that can be expected to fit when requesting different behaviors. You may define the application programming interface (API) of.

In various embodiments, network-based services may be requested or invoked through the use of messages containing parameters and / or data associated with network-based service requests. Such messages may be formalized according to a particular markup language such as XML (XML) and / or encapsulated using a protocol such as the Simple Object Access Protocol (SOAP). To make a network-based service request, the client of the network-based service assembles the message containing the request and sends the message to the addressable endpoint corresponding to the network-based service (eg, Uniform Resource Locator (URL)). ) Can be transmitted using an internet-based application layer transfer protocol such as the Hypertext Transfer Protocol (HTTP).

In some embodiments, network-based services may be performed using representational state transfer (“RESTful”) techniques rather than message-based techniques. For example, network-based services performed according to the RESTful technique can be called through parameters contained within HTTP methods such as PUT, GET, or DELETE, rather than parameters encapsulated in SOAP messages.

Although the above embodiments have been described in considerable detail, a number of modifications and modifications may be made so that once the disclosure is fully understood, those skilled in the art will appreciate it. The following claims include all such amendments and modifications, and are therefore intended to be taken as exemplary rather than restrictive.

Claims (15)

With one or more computing devices
One or more credits are allocated to the remaining resource credits for the virtual compute instance, and the credits for the remaining resource credits for the virtual compute instance are one in which the virtual compute instance implements the virtual compute instance. The allocation and the allocation that make it possible to apply the credits in order to utilize the above computer resources beyond the level of baseline utilization.
Generating one or more scheduling instructions for the virtual computing instance to schedule work requests for performance on one or more computer resources that implement the virtual computing instance, the one or more scheduling The instructions are generated, at least in part, on the application of one or more of the resource credits remaining to the virtual compute instance.
After applying the one or more resource credits, determining that the remaining resource credits of the remaining resource credits for the virtual compute instance are less than the threshold value.
In response to the determination, at least one of the one or more generated scheduling instructions is configured so that the utilization of the one or more computer resources by the virtual computing instance is reduced to the baseline utilization. ,
How to do. The generated scheduling instructions include the utilization of the one or more computer resources by the virtual computing instance in a time interval during which the utilization of the one or more computer resources is gradually reduced to the baseline utilization. The method of claim 1, wherein the method is gradually reduced by a plurality of increments diffused over the time increase of. Claim 1 or 2, wherein the one or more computer resources include one or more central processing units (CPUs), and further comprises transmitting the one or more scheduling instructions to a scheduler for the one or more CPUs. The method described in. The method of claim 3, wherein the baseline utilization comprises a guaranteed baseline for processing capacity. One or more of claims 1-4, wherein the one or more computer resources include one or more networking channels and further comprises transmitting the one or more scheduling instructions to the scheduler for the one or more networking channels. The method described in paragraph 1. The method of claim 5, wherein the baseline utilization comprises a guaranteed baseline performance rate for the networking channel. The virtual compute instance is one of a plurality of different types of virtual compute instances supplied through a network-based virtual computing service, and each of the virtual compute instances is individually updated. The method according to any one of claims 1-6, which has a remaining amount of resource credits. At least some of the virtual computing instances delivered through the network-based virtual computing service are others of the virtual computing instances served through the network-based virtual computing service. 7. The method of claim 7, which has a resource credit allocation rate different from that of. At least some of the virtual computing instances delivered through the network-based virtual computing service are others of the virtual computing instances served through the network-based virtual computing service. The method of claim 7 or 8, which has a different level of baseline utilization than. A system comprising one or more processors coupled to one or more non-transitory computer-readable storage media, wherein the computer-readable storage medium stores program instructions. When executed by the one or more processors, the system
Allocating one or more credits to the remaining resource credits for a virtual compute instance, where the remaining resource credits for the virtual compute instance are one or more computer resources that implement the virtual compute instance. The allocation and the allocation, which allows the credit to be applied in order to utilize beyond the level of baseline utilization.
Generating one or more scheduling instructions for the virtual computing instance to schedule work requests for performance on one or more computer resources that implement the virtual computing instance, the one or more scheduling The instructions are generated, at least in part, on the application of one or more of the resource credits remaining to the virtual compute instance.
After applying the one or more resource credits, determining that the remaining resource credits of the remaining resource credits for the virtual compute instance are less than the threshold value.
In response to the determination, at least one of the one or more generated scheduling instructions is configured so that the utilization of the one or more computer resources by the virtual computing instance is reduced to the baseline utilization. ,
To do,
system. The generated scheduling instructions include the utilization of the one or more computer resources by the virtual computing instance in a time interval during which the utilization of the one or more computer resources is gradually reduced to the baseline utilization. 10. The system of claim 10, wherein the system is gradually reduced by a plurality of increments diffused over the time increase of. 10. The system described in. One of claims 10-12, wherein the one or more computer resources comprises one or more networking channels and further comprises transmitting the one or more scheduling instructions to the scheduler for the one or more networking channels. The system described in paragraph 1. 13. The system of claim 13, wherein the baseline utilization comprises a guaranteed baseline for processing capacity and a guaranteed baseline performance rate for networking channels. The virtual compute instance is one of a plurality of different types of virtual compute instances supplied through a network-based virtual computing service, and each of the virtual compute instances is individually updated. The system according to any one of claims 10-14, which has a remaining amount of resource credits.

Images