Measuring responsiveness of a load-balancing system

Abstract

In various embodiments, methods and systems for measuring load-balancer responsiveness in a cloud computing infrastructure are provided. A plurality of requests is transmitted to a data center virtual IP (VIP), where the data center VIP is configured to receive inbound traffic for a service. A load-balancing component associated with the VIP distributes the requests to a DIP pool comprised of one or more machines, each associated with a private direct IP (DIP). Each of the machines includes a DIP node-monitoring component including a keep-alive URL for receiving keep-alive probes and a dummy service URL for receiving the plurality of requests. A latency of exclusion or inclusion of a first DIP of a first machine in the DIP pool is determined based on at least some of the requests received by the DIP node-monitoring component from the load-balancing component.

What is claimed is: 
     
         1 . A system having a processor, and memory with computer-executable instructions embodied thereon that, when executed by the processor, performs a method for measuring load-balancer responsiveness, the system comprising:
 a traffic generator component configured for:
 generating a plurality of incoming requests that are communicated to a virtual Internet Protocol (VIP) associated with a load-balancing component; 
   the load-balancing component configured for:
 receiving the plurality of incoming requests; 
 communicating to one or more direct Internet Protocol (DIP) instances associated with the VIP the plurality of incoming requests received at the load-balancing component, wherein the plurality of incoming requests are communicated using the load-balancing component; and 
   a DIP instance having a DIP instance monitoring component configured for:
 initializing a keep-alive listening component and a dummy listening component, wherein the DIP instance in an on-state responds to incoming keep-alive probes on the keep-alive listening component and responds to the plurality of incoming requests on the dummy listening component, and wherein the DIP instance in an off-state responds to the plurality of incoming requests on the dummy listening component; 
 determining a DIP exclusion latency for the DIP instance; 
 determining a DIP inclusion latency for the DIP instance; and communicating at least one of the exclusion latency and the inclusion latency as an indicator of a responsiveness measurement of a corresponding load-balancing component to facilitate configuration of the load-balancing component. 
   
     
     
         2 . The system of  claim 1 , wherein the traffic-generator component is configured to communicate the plurality of incoming requests to the load-balancing component such that the plurality of incoming requests simulate an external source of incoming traffic, wherein the plurality of incoming requests are communicated at a predetermined rate. 
     
     
         3 . The system of  claim 2 , wherein the VIP is a public IP address that is associated with a plurality of virtual machines (VM) each corresponding to a DIP, wherein the VIP and the plurality of VMs support a service in a cloud computing infrastructure, wherein the VIP is used to receive the plurality of incoming requests and the external source of incoming traffic contemporaneously. 
     
     
         4 . The system of  claim 1 , wherein the load-balancing component comprises a keep-alive monitoring component that is configured to identify the one or more DIP instances as belonging to a pool of active DIP instances based on:
 communicating a predetermined number of keep-alive probes to a monitored DIP instance;   determining that the monitored DIP instance is active when responses are received for each of the predetermined number of keep-alive probes;   determining that the monitored DIP instance is inactive when responses are not received for each of the predetermined number of keep-alive probes; and   identifying the pool of active DIP instances to the VIP for load-balancing incoming requests to the pool of active DIP instances.   
     
     
         5 . The system of  claim 1 , wherein the DIP exclusion latency is determined based on:
 determining that the DIP instance is switched to the off-state;   capturing an exclusion first-time, wherein the exclusion first-time indicates when the DIP instance is switched to the off-state;   capturing an exclusion second-time, wherein the exclusion second-time indicates a latest time an incoming request is received at the dummy listening component; and   determining the DIP exclusion latency based on the exclusion first-time and the exclusion second-time, wherein the DIP exclusion latency specifies a latency time that indicates a period between when the DIP instance is in an off-state and when the DIP instance stops receiving incoming requests.   
     
     
         6 . The system of  claim 1 , wherein the DIP inclusion latency is determined based on:
 determining that the DIP instance is switched to the on-state;   capturing an inclusion first-time, wherein the inclusion first-time indicates when the DIP instance is switched to the on-state;   capturing an inclusion second-time, wherein the inclusion second-time indicates an earliest time an incoming request is received at the dummy listening component; and   determining the DIP inclusion latency based on the inclusion first-time and the inclusion second-time, wherein the DIP inclusion latency specifies a latency time that indicates a period between when the DIP instance is in an on-state and when the DIP instance starts receiving incoming requests.   
     
     
         7 . The system of  claim 1 , wherein the keep-alive listening component and the dummy listening component are configured to listen to a keep-alive URL and a dummy URL, respectively, on the same port and protocol, wherein the dummy URL is affixed with the name of the VIP such that the exclusion latency and the inclusion latency are captured for the corresponding VIP. 
     
     
         8 . The system of  claim 1 , further comprising a state switching component configured for:
 controlling a number of DIP instances that are set to the off-state or on-state, for responsive measurements, based on one of the following state switching routines:
 referencing a duration period at the start a specific state, wherein the duration period is randomly drawn from a configured range; and 
 configuring a probability mechanism for determining the next state as either the on-state or off-state, wherein when an existing state is selected a corresponding duration period of the existing state is extended. 
   
     
     
         9 . The system of  claim 1 , further comprising:
 a performance component configured for:
 referencing at least one of the exclusion latency or the inclusion latency to perform at least one of the performance remedial operations, the performance remedial operations comprising: 
 communicating an indication to perform a partitioning operation on a cluster comprising the load-balancing component to improve a load-balancing load of the load-balancing component; 
 communicating alarms based on the exclusion latency or the inclusion latency exceeding defined thresholds values; and 
 communicating to an interface component one or more monitoring health reports based on the exclusion latency or the inclusion latency, wherein the one or more health report indicate an issue with the load-balancing component. 
   
     
     
         10 . One or more computer storage media having computer-executable instructions embodied thereon that, when executed, by one or more processors, causes the one or more processors to perform a method for measuring load-balancer responsiveness, the method comprising:
 determining that a direct Internet Protocol (DIP) instance is switched to an off-state, wherein the DIP instance in an on-state responds to keep-alive probes on a keep-alive listening component and responds to incoming requests on a dummy listening component, and wherein the DIP instance in an off-state responds to incoming requests on the dummy listening component;   capturing an exclusion first-time, wherein the exclusion first-time indicates when the DIP instance is switched to the off-state;   capturing an exclusion second-time, wherein the exclusion second-time indicates a latest time an incoming request is received at the dummy listening component;   determining a DIP exclusion latency based on the exclusion first-time and the exclusion second-time, wherein the DIP exclusion latency specifies a latency time that indicates a period between when the DIP instance is in an off-state and when the DIP instance stops receiving incoming requests,   communicating the exclusion latency as an indicator of a responsiveness measurement of a corresponding load-balancing component to facilitate configuration of the load-balancing component.   
     
     
         11 . The media of  claim 10 , wherein the DIP instance comprises a machine, wherein the machine is one of a plurality of machines supporting a service in a cloud computing infrastructure, and wherein the DIP instance corresponds to a virtual IP (VIP) that is associated with the service. 
     
     
         12 . The media of  claim 10 , wherein the DIP instance is switched to the off-state when for a predetermined duration period when measuring responsiveness of a load-balancing component. 
     
     
         13 . The media of  claim 10 , wherein the DIP instance is determined to be inactive by a keep-alive component after failing a predetermined number of keep-alive probes. 
     
     
         14 . The media of  claim 10 , wherein the dummy listening component continuously receives incoming requests after the DIP instance is switched to the off-state in order to capture the exclusion second-time, and wherein the keep alive component stops responding to keep-alive probes when the DIP instance is in an off-state. 
     
     
         15 . The media of  claim 10 , further comprising:
 determining that the exclusion latency exceeds a threshold value, wherein the threshold value is based on published numbers for the load-balancing component of the DIP instance, wherein published numbers are predetermined latency values that are expected for the load-balancing component; and   communicating an indication that the load-balancing component is black-holing traffic.   
     
     
         16 . A computer-implemented method for measuring load-balancer responsiveness, the method comprising:
 determining that a direct Internet Protocol (DIP) instance is switched to an on-state, wherein the DIP instance in the on-state responds to keep-alive probes on a keep-alive listening component and responds to incoming requests on a dummy listening component, and wherein the DIP instance in an off-state responds to incoming requests on the dummy listening component;   capturing an inclusion first-time, wherein the inclusion first-time indicates when the DIP instance is switched to an on-state;   capturing an inclusion second-time, wherein the inclusion second-time indicates an earliest time an incoming request is received at the dummy listening component;   determining a DIP inclusion latency based on the inclusion first-time and the inclusion second-time, wherein the DIP inclusion latency indicates a latency time that indicates a period between when the DIP instance is in an on-state and when the DIP instance starts receiving incoming requests; and   communicating the DIP inclusion latency as an indicator of an inclusion latency responsiveness measurement of a corresponding load-balancing component to facilitate configuration of the load-balancing component.   
     
     
         17 . The method of  claim 16 , wherein the DIP instance is switched to the on-state when for a predetermined duration period when measuring responsiveness of a load-balancing component. 
     
     
         18 . The method of  claim 16 , wherein the DIP instance is determined to be active by a keep-alive component after responding to a predetermined number of keep-alive probes. 
     
     
         19 . The media of  claim 10 , wherein the keep-alive listening component and dummy listening component contemporaneously receive incoming requests after the DIP instance is switched to the on-state in order to capture the inclusion second-time. 
     
     
         20 . The method of  claim 17 , further comprising:
 determining that the inclusion latency exceeds a threshold value, wherein the threshold value is based on published numbers for the load-balancing component of the DIP instance, wherein published numbers are predetermined latency values that are expected for the load-balancing component; and   communicating an indication that the load-balancing component is not maximizing available resources.