Forum Discussion

mwinstead_13706's avatar
mwinstead_13706
Icon for Nimbostratus rankNimbostratus
Nov 08, 2013

SQL LB

We have two SharePoint SQL Clusters that currently traverse through an ASA firewall to talk with the SharePoint WFEs. The ASA is getting hammered and is dropping packets because SQL is over utilizing it. What we are wanting to do is send that SQL traffic through the F5 instead. Is there a feasible solution for this? Can we LB? Honestly just routing the traffic through there would be enough for us. I am just not sure how you would do that with the two SQL clusters... Guessing make two VIP and then route traffic to each cluster IP?

 

Current Setup: SPCLUSTER1 192.168.1.1 -Node1 192.168.1.2 -Node2 192.168.1.3 SPCLUSTER2 192.168.2.1 -Node1 192.168.2.2 -Node2 192.168.2.3

 

APM
application load balancing
design
microsoft
security
sql

3 Replies

Sort By
  • What_Lies_Bene1's avatar
    What_Lies_Bene1
    Icon for Cirrostratus rankCirrostratus
    Nov 08, 2013

    I'm sure you could load balance. What do you actually want the F5 to do?

     

    Packet filters or an iRule could be used to provide some security. You could have two VIPS and use Priority Group Activation for redundancy. OneConnect might also take the load of the WFEs somewhat.

     

  • What_Lies_Bene1's avatar
    What_Lies_Bene1
    Icon for Cirrostratus rankCirrostratus
    Nov 08, 2013

    OK, want me to dive into a bit more detail (won't be till Monday, about to take a long drive home)?

     

  • What_Lies_Bene1's avatar
    What_Lies_Bene1
    Icon for Cirrostratus rankCirrostratus
    Nov 11, 2013

    I'd suggest a slightly different approach to improve redundancy. I'd build two Performance (Layer 4) Virtual Servers, one for each cluster. However, I'd use two Pools and Priority Group Activation. In each Pool, the intended cluster would be specified with a priority of two and the other cluster IP configured with a priority of one. Set minimum members to one. That way, if a cluster went down, traffic would switch to the other; but only if the 'primary' is down.

     

    As I assume there is no need for Persistence, when a failed cluster comes back up everything would revert back fairly quickly. Using OneConnect for both would also greatly reduce the number of active connections each cluster needs to deal with, probably saving a fair bit of memory usage.