Applying policies to schedule network bandwidth among virtual machines

• US 8,477,610 B2
• Filed: 05/31/2010
• Issued: 07/02/2013
• Est. Priority Date: 05/31/2010
• Status: Active Grant

• Current Assignee: Microsoft Technology Licensing LLC (Microsoft Corporation)
• Original Assignee: Microsoft Corporation
• Inventors: Zuo, Yue, Chau, HoYuen, Vo, Hoi Huu, Arafeh, Samer N., Divakara, Vivek P., Deng, Yimin, Foltz, Forrest Curtis, Bhanu, Vivek
• Primary Examiner(s): Wong, Warner
• Application Number:
  US12/790,981
• Publication Number:
  US 20110292792A1
• Time in Patent Office: 1,128 Days
• Field of Search: 370/230, 370/235, 370/235.1, 370/237, 370254-255, 370/395.4, 709/201, 709/225, 709/226, 709/248
• US Class Current: 370/230
• CPC Class Codes: G06F 9/45533 Hypervisors; Virtual machine monitors
• CPC Class Codes: H04L 41/0896 Bandwidth or capacity management, i.e. automatically increasing or decreasing capacities flow or congestion control using dynamic resource allocation, e.g. in-call renegotiation, H04L47/76
• CPC Class Codes: H04L 41/0897 by horizontal or vertical scaling of resources, or by migrating entities, e.g. virtual resources or entities
• CPC Class Codes: H04L 47/20 Traffic policing
• CPC Class Codes: H04L 47/215 using token-bucket
• CPC Class Codes: H04L 65/80 Responding to QoS

Abstract

Computerized methods, systems, and computer-storage media for allowing virtual machines (VMs) residing on a common physical node to fairly share network bandwidth are provided. Restrictions on resource consumption are implemented to ameliorate stressing the network bandwidth or adversely affecting the quality of service (QoS) guaranteed to tenants of the physical node. The restrictions involves providing a scheduler that dynamically controls networking bandwidth allocated to each of the VMs as a function of QoS policies. These QoS policies are enforced by controlling a volume of traffic being sent from the VMs. Controlling traffic includes depositing tokens into token-bucket queues assigned to the VMs, respectively. The tokens are consumed as packets pass through the token-bucket queues. Upon consumption, packets are held until sufficient tokens are reloaded to the token-bucket queues.

Claims

1. One or more computer-storage memory having computer-executable instructions embodied thereon that, when executed, perform a method for metering various data flows of packets originating from a plurality of virtual machines (VMs) instantiated on a single physical node, the method comprising:

inspecting one or more quality of service (QoS) policies written to a contract, wherein the contract governs allocation of network resources to a first client;

depositing tokens into a first token-bucket queue based, in part, on the one or more QoS policies of the first-client contract, wherein the first token-bucket queue is assigned to a first VM instantiated on the physical node;

detecting the first VM is in an active state based on a depletion of the deposited tokens from the first token-bucket queue, wherein a portion of the deposited tokens are withdrawn from the first token-bucket queue as a function of a rate of the data flow from the first VM;

reloading tokens into the first token-bucket queue based, in part, on the one or more QoS policies and a portion of the deposited tokens remaining in the first token-bucket queue

detecting the first VM is in an idle state based on a lack of usage of the deposited tokens from the first token-bucket queue, wherein the deposited tokens are not withdrawn from the first token-bucket queue when the first VM ceases transmitting packets therefrom; and

abstaining from reloading tokens into the first token-bucket queue based, in part, on the idle state of the first VM, wherein inspecting one or more QoS policies written to a contract comprises determining a minimal amount of tokens to reserve for the first token-bucket queue when the first VM has assumed the idle state.

2. The one or more computer-storage memory of claim 1, the method further comprising:

inspecting one or more QoS policies written to a second-client contract that governs allocation of network resources to a second VM instantiated on the physical node; and

depositing tokens into a second token-bucket queue based, in part, on the one or more QoS policies of the second-client contract, wherein the second token-bucket queue is assigned to the second VM.

3. The one or more computer-storage memory of claim 2, wherein depositing tokens into a first token-bucket queue comprises depositing a first amount of tokens into the first token-bucket queue, wherein depositing tokens into a second token-bucket queue comprises depositing a second amount of tokens into the second token-bucket queue, and wherein the first amount and the second amount of tokens differ in value.

4. The one or more computer-storage memory of claim 2, wherein the first amount is an absolute value of network bandwidth that is allocated to the first VM as specified by the first-client contract.

5. The one or more computer-storage memory of claim 3, wherein the first amount is based upon a first weighting associated with the first VM relative to, at least, a second weighting associated with the second VM, and wherein first weighting and the second weighting are specified by the first-client contract and the second client contract, respectively.

6. The one or more computer-storage memory of claim 3, the method further comprising:

identifying network bandwidth currently available at a network interface component, wherein the network interface component functions to control a volume of traffic from the physical node to a network; and

utilizing the available network bandwidth to determine the first amount of tokens to be deposited into the first token-bucket queue.

7. The one or more computer-storage memory of claim 6, the method further comprising:

utilizing the one or more QoS policies written to the first-client to determine a maximum amount of tokens to deposit into the first token-bucket queue; and

capping the rate of data flow from the first VM upon the first token-bucket queue withdrawing the maximum amount of tokens.

8. The one or more computer-storage memory of claim 7, wherein the maximum amount of tokens is deposited into the first token-bucket queue when the first VM has assumed an active state and sufficient network bandwidth is identified as being currently available at the network interface component.

9. A computer system capable of metering a rate at which packets from a virtual machine are injected into a network utilizing one or more policies specified by tenants of a data center, the computer system comprising a computer storage medium having a plurality of computer software components embodied thereon, the computer software components comprising:

a first VM instantiated on a physical node;

a second VM instantiated on the physical node;

a first token-bucket queue assigned to the first VM;

a second token-bucket queue assigned to the second VM, wherein the first token-bucket queue and the second token-bucket queue represent distinct memory buffers located on the physical node; and

a scheduler that reads a first-client contract and a second-client contract associated with the first VM and the second VM, respectively, that deposits a first amount of tokens into the first token-bucket queue as a function of the one or more policies within the first-client contract, and that deposits a second amount of tokens into the second token-bucket queue as a function of the one or more policies within the second-client contract,

wherein the first amount of tokens and the second amount of tokens each represent a portion of network bandwidth that is allocated to the first VM and the second VM, respectively,

wherein the first amount and the second amount of tokens differ in value,

wherein the first VM transmits a first data flow of packets to the first token-bucket queue prior to the packets of the first data flow being released from the physical node,

wherein the second VM transmits a second data flow of packets to the second token-bucket queue prior to the packets of the second data flow being released from the physical node,

wherein, upon receiving the first data flow, the first token-bucket queue deducts a prescribed amount of tokens deposited therein for each packet within the first data flow,

wherein, upon receiving the second data flow, the second token-bucket queue deducts a prescribed amount of tokens deposited therein for each packet within the second data flow; and

a routing component that accesses a mapping between the first VM and the first token-bucket queue when the first VM is attempting to transmit the first data flow to an endpoint external to the physical node, and that routes the first data flow to the first token-bucket queue based on the mapping, wherein the routing component routes the first data flow from first VM to the second VM without passing through the first token-bucket queue when the first VM is attempting to transmit the first data flow directly to the second VM.

10. The computer system of claim 9, the computer software components further comprising a network interface controller (NIC) queue that meters the first data flow from the first token-bucket queue in conjunction with the second data flow from the second token-bucket queue.

11. The computer system of claim 10, the computer software components further comprising a network interface component that receives the metered first data flow and the metered second data flow from the NIC queue and releases from the physical node a controlled volume of traffic comprising the packets within the metered first data flow and the metered second data flow.

12. The computer system of claim 9, wherein the first token-bucket queue includes a token component that periodically receives the deposited first amount of tokens and consumes the tokens maintained therein according to a rate of the first data flow.

13. The computer system of claim 12, wherein the first token-bucket queue includes a queue component that internally enqueues packets transmitted within the first data flow that are received thereby when the token component maintains an insufficient quantity of tokens for consumption.

14. A computerized method for imposing a limit on a rate of data flowing from a subject virtual machine (VM), the method comprising:

accepting a first deposit of tokens from a scheduler, wherein an amount of tokens provided within the first deposit is based on determining whether the subject VM is in an active state, based on a depletion of the first deposit of tokens, or an idle state, based on a lack of usage of the first deposit of tokens, wherein, when in the active state, a token-bucket queue of the subject VM is reloaded as a function of a portion of the first deposit of tokens remaining in the first token-bucket queue, and wherein, when in the idle state, the token-bucket queue is reloaded with a minimal amount of tokens reserved for the subject VM;

consuming the tokens according to a rate of the data flow from the subject VM; and

dynamically metering the data-flow rate upon substantially depleting the tokens, wherein metering comprises;

(a) forwarding to a network interface component packets within the data flow that are received prior to the tokens being substantially depleted from the token-bucket queue;

(b) enqueueing packets within the data flow that are received subsequent to the tokens being substantially depleted from the token-bucket queue; and

(c) forwarding the enqueued packets to the network interface component upon the token-bucket queue accepting a second deposit of tokens from the scheduler.