Forum Discussion

Tim_a_willis_92's avatar
Tim_a_willis_92
Icon for Nimbostratus rankNimbostratus
Sep 12, 2013

Load balancing read only SQL 2008R2 servers

We have everything setup in the LTM and everything is working right. Traffic is getting balanced equally between our MS SQL server (read only). But the issue we are seeing happens when a server goes out for maintenance. We have a health monitor setup to query a DB and the LTM knows when the SQl server it down. But it seems the web servers connections to the SQL servers are keeping the connection alive.

 

Here is a copy of the error that is recieved: System.Data.SqlClient.SqlException: A transport-level error has occurred when sending the request to the server. (provider: TCP Provider,error: 0 - An existing connection was forcibly closed by the remote host.)

 

After this happens, the web servers then move over to the next available node.

 

the VIP is setup for performance layer 4, web servers are server 2003, and our SQL servers are server 2008R2 setup with n-path.

 

15 Replies

  • Well, I imagine that even if reselect works, the previous server still believes it has a valid connection to the client and that eventually times out and is reset. Do you know why you're using nPath?

     

  • Our LTM is shared with many businesses within our company. And our hosting services within our company thought it might have too much of a load on LTM load balancing the SQL servers.

     

  • Hmmm, what model? What's the CPU and memory usage like? How many concurrent connections?

     

  • The models used in this instance is the BIG-IP Virtual Edition, there are 4 of them in active/active/active/standby

     

    Here is screen shot of the dashboard from the LTM hosting the SQL:

     

    DashBoard

     

    And thank you for your help with this!

     

    • What_Lies_Bene1's avatar
      What_Lies_Bene1
      Icon for Cirrostratus rankCirrostratus
      You're welcome and thanks for the picture. I don't see why sending the return traffic back would be an issue performance wise, things look pretty low and as it's a performance L4 VS it's going to add very little overhead (and very little extra latency). Of course, testing is always advised.