METHODS AND SYSTEMS FOR DETECTING, LOCATING AND REMEDIATING A CONGESTED RESOURCE OR FLOW IN A VIRTUAL INFRASTRUCTURE

• US 20140215077A1
• Filed: 01/24/2014
• Published: 07/31/2014
• Est. Priority Date: 01/26/2013
• Status: Abandoned Application

• Current Assignee: F5 Networks, Inc. (F5 Incorporated)
• Original Assignee: Lyatiss, Inc. (Lyatiss SAS)
• Inventors: VICAT-BLANC, Pascale, SOUDAN, Sebastien, GUILLIER, Romaric, LE BORGNE, Marion
• Application Number:
  US14/163,312
• Publication Number:
  US 20140215077A1
• Time in Patent Office: Days
• US Class Current: 709/226
• CPC Class Codes: H04L 47/11 Identifying congestion
• CPC Class Codes: H04L 47/193 at the transport layer, e.g. TCP related
• CPC Class Codes: H04L 47/27 Evaluation or update of window size, e.g. using information derived from acknowledged [ACK] packets
• CPC Class Codes: H04L 47/74 measures in reaction to resource unavailability
• CPC Class Codes: H04L 47/822 Collecting or measuring resource availability data

Abstract

Once a potential bottleneck is identified, the system provides a methodology for locating the bottleneck. The methodology involves checking in order each of the application, transport and network layers of a sender and receiver nodes for performance problems. Conditions are defined for each of the layers at the sender and receiver nodes that are indicative of a particular type of bottleneck. When the conditions are met in any one of the layers, the system can be configured to stop the checking process and output a message indicating the presence of a bottleneck in the layer and its location. In addition, the system can be configured to generate and output a remedial action for eliminating the bottleneck. The system can be configured to perform the action automatically or after receiving a confirmation from the user.

Claims

1. A method in an electronic device including a processor and a memory, the method comprising:

identifying in the processor virtual resources associated with an execution of a user'"'"'s applications in a resource configuration, including virtual or physical machines, network services, and storage, wherein the resource configuration is a cloud or distributed resource configuration;

generating a plurality of performance metrics associated with the execution of the user'"'"'s applications in the resource configuration;

generating in the processor a visual representation of the resource configuration including the virtual or physical machines and the performance metrics;

outputting under control of the processor a user interface including the visual representation;

determining in the processor that there is possibly a bottleneck involving a sender and a receiver of the virtual or physical machines based on the performance metrics;

checking serially in the processor for a problem indicating a presence of the bottleneck in each of an application layer, transport layer, and network layer of the sender and the receiver;

when a check indicates the problem is in one of the application layer, transport layer, or network layer of the sender or the receiver, stopping in the processor the checking and outputting a message to the user interface indicating a location of the bottleneck is in the sender or receiver and a recommendation for a remedial action for alleviating the bottleneck; and

when the checks indicate the problem is not located in any of the application layer, transport layer, or network layer of the sender or the receiver, outputting by the processor a message to the user interface indicating the location of the bottleneck is in an external path between the sender and the receiver and a recommendation for a remedial action for alleviating the bottleneck in the external path or there is no problem.

2. The method of claim 1, wherein checking comprises checking a CPU usage, memory usage, disk usage, and/or latency metric of the receiver or sender.

3. The method of claim 2, wherein checking further comprises checking one or more metrics pertaining to the receiver or the sender:

a total CPU usage, percentage of CPU that is reclaimed, percentage of CPU spent waiting for I/O, disk I/O usage, NetIn/NetOut usage, capacity at an interface of the receiver or sender interfaces to a virtual network, and a transmit queue drop at the interface of the receiver or sender to the virtual network.

4. The method of claim 2, wherein checking further comprises checking one or more flow metrics of one or more flows between the receiver and the sender:

an amount of data transported by a plurality of connections within the one or more flows, a duration of the connections within the one or more flows, a total number of connections in the one or more flows, a flow packet size, a count of the number of retransmissions, flow retransmission time outs, a size of a send queue of a socket corresponding to the connections, a size of a receive queue of the socket corresponding to the connections, and an amount of bandwidth used by the one or more flows.

5. The method of claim 4, wherein the one or more flow metrics further comprise a flow activity metric, wherein one or more flow metrics vary over time.

6. The method of claim 1, further comprising:

collecting the user'"'"'s input for remediating the bottleneck; and

providing a knowledge database based on the collected user input and the problem, wherein the knowledge database is user searchable to allow the user to determine whether a system in a similar configuration has experienced a same problem.

7. The method of claim 1, wherein the resource configuration includes an opaque network that includes the external path between an output port of the sender and an output port of the receiver from which performance metrics cannot be determined, wherein the performance metrics upon which the determining of the bottleneck is based include a data output capacity of the sender and a data input capacity of the receiver, and wherein checking comprises:

if the data output capacity of the sender is below the data input capacity of the receiver, defining the output capacity of the sender as a maximum data path capacity for a flow of data from the sender to the receiver;

if the data input capacity of the receiver is less than the data output capacity of the sender, defining the input capacity of the receiver as a maximum data path capacity for a flow of data from the sender to the receiver; and

if a data usage by a flow of data from the sender to the receiver is below a predefined fraction of the maximum path capacity, determining the problem is located between an application module of the sender and an application module of the receiver.

8. The method of claim 7, wherein the performance metrics upon which the determining of the bottleneck is based include an indicator of a CPU, memory, and/or I/O capacity of both the receiver and sender, and wherein checking further comprises:

if the indicator indicates that the CPU, memory, and/or I/O capacity of the receiver is insufficient to receive data when the sender is ready to send data to the receiver, determining the problem is located in the receiver; and

if the indicator indicates that the CPU, memory, and/or I/O capacity of the sender is insufficient to send data to the receiver, determining the problem is located in the sender.

9. The method of claim 1, wherein checking further comprises:

if a particular one or more of the performance metrics indicate that a CPU usage, memory usage, I/O usage, or a disk usage of the receiver is above a predefined threshold, determining whether the problem is in the application layer of the receiver; and

if it is determined that the problem is in the application layer of the receiver, stopping the checking of the transport and network layer of the receiver and sender and outputting a message indicating a location of the bottleneck in the receiver in the form of a communication bottleneck and also indicating a recommendation for changing a receiver instance type.

10. The method of claim 9, wherein it is determined that the problem is in the application layer in the receiver if a value of a receive queue of a network stack of the receiver denotes that an application of the receiver is not able to consume arriving data.

11. The method of claim 9, wherein the checking further comprises:

if it is determined that the problem is not in the application layer of the receiver, checking whether the problem is a load balancer problem; and

if it is determined that the problem is a load balancer problem, stopping the checking of the transport and network layer of the receiver and sender and outputting a message indicating a location of the bottleneck in the receiver in the form of a processing bottleneck and also indicating a recommendation for adding another load balancer or change a receiver instance.

12. The method of claim 10, wherein the checking further comprises:

if it is determined that the problem is not a load balancer problem, checking whether the problem is another load balancing problem in another load balancing target, other than the receiver;

if it is determined that the problem is another load balancing problem, stopping the checking of the transport and network layer of the receiver and sender and outputting a message indicating a location of the bottleneck in the receiver in the form of a processing bottleneck and also indicating a recommendation for balancing load; and

if it is determined that the problem is not in another load balancing problem, stopping the checking of the transport and network layer of the receiver and sender and outputting a message indicating a location of the bottleneck in the receiver in the form of a processing bottleneck and also indicating a recommendation for reconfiguring a load balancer.

13. The method of claim 12, wherein it is determined that the problem is another load balancing problem if a one or more of the performance metrics indicate that a CPU usage, memory usage, I/O usage, or a disk usage of the receiver is above a predefined threshold.

14. The method of claim 9, wherein the checking further comprises:

if it is determined that the problem is not in the application layer of the receiver and if a particular one or more of the performance metrics indicate that a CPU usage, memory usage, I/O usage, or a disk usage of the sender is above a predefined threshold, determining whether the problem is in the application layer of the sender;

if it is determined that the problem is in the application layer of the sender, stopping the checking of the transport and network layer of the receiver and sender and outputting a message indicating a location of the bottleneck in the sender in the form of a communication bottleneck and also indicating a recommendation for changing a sender instance type; and

if it is determined that the problem is not in the application layer of the sender, stopping the checking of the transport and network layer of the receiver and sender and outputting a message indicating a location of the bottleneck in the sender in the form of a processing bottleneck and also indicating a recommendation for adding a load balancer or changing a sender instance type.

15. The method of claim 14, wherein the checking further comprises:

if a particular one or more of the performance metrics indicate that a CPU usage, memory usage, I/O usage, or a disk usage of the sender is not above a predefined threshold, checking whether the problem is in the transport layer of the receiver and the sender to determine if the transport layer protocol of the receiver or sender is misconfigured;

if it is determined that the transport layer protocol of the receiver is misconfigured, stopping the checking of the transport and network layer of the receiver and sender and outputting a message indicating a location of the bottleneck in the receiver in the form of a communication bottleneck and also indicating a recommendation for reconfiguring the transport layer of the receiver; and

if it is determined that the transport layer protocol of the sender is misconfigured, stopping the checking of the transport and network layer of the receiver and sender and outputting a message indicating a location of the bottleneck in the sender in the form of a communication bottleneck and also indicating a recommendation for reconfiguring the transport layer of the sender.

16. The method of claim 15, wherein the transport layer protocol of the receiver is misconfigured based on the receive buffer size, and wherein the transport layer protocol of the sender is misconfigured if a socket buffer size of the sender is not sized in relation with a path capacity and path latency of the external path.

17. The method of claim 14, wherein the checking of the transport layer protocol of the receiver is checked before checking the transport layer protocol of the sender and the checking of the transport layer protocol of the sender is only performed if it is determined the problem is not in the transport layer protocol of the receiver.

18. The method of claim 14, wherein the checking further comprises:

(a) if it is determined that transport layer protocol of the receiver or sender is not misconfigured, checking whether the problem is in the transport layer of the sender;

(b) if it is determined that the problem is not in the transport layer of the sender, checking whether the problem is in the network layer of the sender;

(c) if it is determined that the problem is in the network layer of the sender and not in the transport layer of the sender, stopping the checking of the transport and network layer of the receiver and sender and outputting a message indicating a location of the bottleneck in the network layer of the sender and also indicating a recommendation for changing a sender instance type;

(d) if it is determined that the problem is not in the network layer of the sender and not in the transport layer of the sender, checking whether the problem is a latency problem in the external path;

(e) if it is determined that the problem is not a latency problem in the external path, outputting a message indicating that there is no problem;

(f) if it is determined that the problem is a latency problem in the external path, stopping the checking of the transport and network layer of the receiver and sender and outputting a message indicating a location of the bottleneck in the external path in the form of a latency problem and also indicating a recommendation for moving the receiver and sender;

(g) if it is determined that the problem is in the network layer and the transport layer of the sender, determining if the sender is a load balancer;

(h) if it is determined that the problem is in the network layer and the transport layer of the sender and it is determined that the sender is a load balancer, stopping the checking of the transport and network layer of the receiver and sender and outputting a message indicating a location of the bottleneck in the receiver in the form of a communication and congestion bottleneck and also indicating a recommendation for changing the load balancer configuration;

(i) if it is determined that the problem is in the network layer and the transport layer of the sender and it is determined that the sender is not a load balancer, stopping the checking of the transport and network layer of the receiver and sender and outputting a message indicating a location of the bottleneck in the receiver in the form of a communication and congestion bottleneck and also indicating a recommendation for adding a load balancer or changing an instance type;

(j) if it is determined that the problem is not in the network layer and the transport layer of the sender, determining whether the problem is in the application layer of the sender;

(k) if it is determined that the problem is not in the network layer and the transport layer of the sender and it is determined that the problem is in the application layer of the sender, stopping the checking of the transport and network layer of the receiver and sender and outputting a message indicating a location of the bottleneck in the receiver in the form of an application bottleneck; and

(l) if it is determined that the problem is not in the network layer and the transport layer of the sender and it is determined that the problem is not in the application layer of the sender, checking whether the problem is a congestion problem in the external path;

if it is determined that the problem is not a congestion problem in the external path, repeating operation (d)˜

(f);

if it is determined that the problem is a congestion problem in the external path, checking whether the problem is in the network layer of the receiver;

if it is determined that the problem is in the network layer of the receiver, stopping the checking of the transport and network layer of the receiver and sender and outputting a message indicating a location of the bottleneck in the sender in the form of a communication and congestion bottleneck and also indicating a recommendation for changing an instance type; and

if it is determined that the problem is not in the network layer of the receiver, stopping the checking of the transport and network layer of the receiver and sender and outputting a message indicating a location of the bottleneck in the external path in the form of a communication and congestion bottleneck and also indicating a recommendation for moving the sender.

19. The method of claim 1, wherein the message indicating a location of the bottleneck or the message indicating the location of the bottleneck is in the external path is output with respect to the visual representation.

20. The method of claim 1, wherein a bottleneck in the sender or receiver or a bottleneck in the external path prevents the resource configuration from operating at a particular threshold of full capacity.

21. An apparatus for cloud or distributed computing resource management, the apparatus formed from one or more electronic devices that are configured to perform the following operations:

identifying virtual resources associated with an execution of a user'"'"'s applications in a resource configuration, including virtual or physical machines, network services, and storage, wherein the resource configuration is a cloud or distributed resource configuration;

generating a plurality of performance metrics associated with the execution of the user'"'"'s applications in the resource configuration;

generating a visual representation of the resource configuration including the virtual or physical machines and the performance metrics;

outputting under control a user interface including the visual representation;

determining that there is possibly a bottleneck involving a sender and a receiver of the virtual or physical machines based on the performance metrics;

checking serially for a problem indicating a presence of the bottleneck in each of an application layer, transport layer, and network layer of the sender and the receiver;

when a check indicates the problem is in one of the application layer, transport layer, or network layer of the sender or the receiver, stopping the checking and outputting a message to the user interface indicating a location of the bottleneck is in the sender or receiver and a recommendation for a remedial action for alleviating the bottleneck; and

when the checks indicate the problem is not located in any of the application layer, transport layer, or network layer of the sender or the receiver, outputting a message to the user interface indicating the location of the bottleneck is in an external path between the sender and the receiver and a recommendation for a remedial action for alleviating the bottleneck in the external path or there is no problem.

22. At least one computer readable storage medium having computer program instructions stored thereon that are arranged to perform the following operations:

identifying in a processor virtual resources associated with an execution of a user'"'"'s applications in a resource configuration, including virtual or physical machines, network services, and storage, wherein the resource configuration is a cloud or distributed resource configuration;

generating a plurality of performance metrics associated with the execution of the user'"'"'s applications in the resource configuration;

generating in the processor a visual representation of the resource configuration including the virtual or physical machines and the performance metrics;

outputting under control of the processor a user interface including the visual representation;

determining in the processor that there is possibly a bottleneck involving a sender and a receiver of the virtual or physical machines based on the performance metrics;

checking serially in the processor for a problem indicating a presence of the bottleneck in each of an application layer, transport layer, and network layer of the sender and the receiver;

when a check indicates the problem is in one of the application layer, transport layer, or network layer of the sender or the receiver, stopping in the processor the checking and outputting a message to the user interface indicating a location of the bottleneck is in the sender or receiver and a recommendation for a remedial action for alleviating the bottleneck; and

when the checks indicate the problem is not located in any of the application layer, transport layer, or network layer of the sender or the receiver, outputting by the processor a message to the user interface indicating the location of the bottleneck is in an external path between the sender and the receiver and a recommendation for a remedial action for alleviating the bottleneck in the external path or there is no problem.