Service Virtualization

Expand all | Collapse all

Load balance multiple VSEs using F5

Jump to Best Answer
  • 1.  Load balance multiple VSEs using F5

    Posted 12-09-2016 12:01 PM

    Hi All,

     

    I have a requirement to load balance VSEs using F5.  Does anyone has any idea on what are the VSE URLs do I need to configure in F5 for health check ?

     

    FYI :I dont want to configure failover Registry. Only VSEs.

     

    Thanks.

    Aniket



  • 2.  Re: Load balance multiple VSEs using F5
    Best Answer

    Posted 12-13-2016 07:59 AM

    A VSE is not load-balancer aware, and virtual services are not intended to share state in the manner that operation behind a load balancer requires. 

     

    For these reasons, we do not support the use of VSEs behind load balancers. 



  • 3.  Re: Load balance multiple VSEs using F5

    Posted 12-13-2016 09:34 AM

    I agree with Dave.  Use this approach with an amount of caution and ensure a deep understanding of your infrastructure and what the VSEs and deployed services are intended to provide.  As Dave states, we do not support the use of VSEs behind load balancers.  There are things to consider if you move forward with this approach.

    For example: 

    1. If all of your virtual services are stateless, it is possible to place multiple VSEs behind the F5 -- develop a thorough understanding of the reasoning and requirements before implementing this approach.  
    2. Keep in mind that your Registry and VSE components need to communicate with one another using their actual IP addresses not the 'virtual' IP address exposed by the F5.  You will bump into issues if the actual IP address of the Registry and VSEs are not accessible due to firewall rules or security policies.  Forcing internal DevTest components, including Workstation and Portal, to talk through the IP exposed by the F5 is very likely to cause serious and impactful issues.
    3. Workstation and Portal users must access and deploy to the IP address of the servers running VSE, not the IP of the F5.  The F5 is exposing the virtual IP endpoint to the SUT not DevTest.  The F5 should not be used to manage the endpoints exposed by the underlying DevTest components as this causes internal communications issues.  For example, trying to connect Workstation to the F5 to achieve a single service deployment to all VSEs under the F5 simply will not work.
    4. Your systems under test (SUTs) will point to the F5's virtual IP endpoint and the F5 will redirect to the service calls to the VSEs on the basis of rules you create on the F5.  DevTest does not control the creation and management of these F5 rules.  A team within your organization will be responsible for managing those rules.
    5. Attempting to run stateful services behind an F5 adds a reasonable amount complexity because the F5 may need rules that pin all subsequent requests from the SUT to the VSE that started the conversation.  If you manually control state in the virtual services, you might be able to use the Persistent Model Map but care should be taken during the implementation.  I would strongly recommend against attempting to run stateful services across VSEs even without a load balancer.
    6. You also have to be careful to ensure that services are deployed to all VSEs running behind the F5 or the F5 must have the necessary iRules to take care of the routing to a single VSE under the F5; otherwise, you will start seeing connection refused / endpoint unavailable exceptions because the F5 is routing requests to a VSE where the service has not been deployed.  
    7. Lastly, do not expect exponential throughput improvements just because you are load balancing.  If one performance VSE is scaled to push 4,000 TPS.  This does not imply that two performance VSEs behind an F5 will push 8,000 TPS.  Similarly, attempting to subvert the functional VSE limitation of approximately 10 TPS by using a load balancer does not necessary increase overall throughput on the services. 

    In the sample graphic below, think of the blue line as a line of demarcation.  All development and deployment activities are occurring below the line.  Development and internal communications never flow through the F5.  The DevTest components are connected to and controlled using their actual IP addresses.  Ports and firewalls need to be open to allow the communications flow.  From above the line, SUTs are invoking services using the endpoint (virtual IP) exposed by the F5.  If for some reason, services need to perform Live Invocation (Red Line out of VSEs), firewalls and ports must be open to allow those communications to occur.