Forum Discussion
rhallbrook_7710
Nimbostratus
NimbostratusLoad Balancing DB backend
What is the most efficient and lowest latency configuration to LB a Webserver with SQL backend? Lets say for simplicity sake the LTM is configured with 3 VLAN's:
- External VLAN
- WWW VLAN
- SQL VLAN
The IP configuration is:
- External 10.10.0.x/24
- WWW 10.10.100.x/24
- SQL 10.10.200.x/24
The physical architecture is:
------------
-External -
------------
|
|
----------- ------------ --------------
- LTM -===Trunk===- Switch --------------- WWW -
----------- ------------ --------------
|
|
-----------
- SQL -
-----------
My goal is to LB the webservers and the SQL servers and have the VIP's that resolve via DNS reside on the External VLAN. https://www.mycompany.com resolves to 10.10.0.100 and the self IP for that VLAN is 10.10.0.10. The webservers have listening instances with IP's of 10.10.100.200, 10.10.100.201, 10.10.100.202 and SQL has instances of 10.10.200.200, 10.10.200.201 and 10.10.200.202 and a VIP of 10.10.200.100. I think I got everything...
Questions:
1. I have a pool of WWW servers and a pool of SQL servers. Whats the best way to LB the WWW connection to the SQL servers?
2. Is there a way to achieve this goal without SNATing?
3. In the past I have always recommended a direct connection to the SQL backend for lower latency and security. Is there any benefit to LBing the SQL servers in their own pool, with their own VIP?
4. Which type of persistence would you recommend?
5. What are the drawbacks?
6. What if I need uri-a to go to SQL server-a, b or c? Do you have a canned iRule?
7. Do you recommend a different architecture?
Thanks!!! Looking forward to your response. :)
RHally
rhallbrook_7710Anyone? Anyone? Bueller...Bueller...Bueller?
HamishCirrocumulus
1. The best way to load balance will probably depend on your actual configurations... Assuming that your client isn't pool aware (i.e. Not something like a RAC aware client) and you need a VS for it, make the VS as simple as possible. If you LB at the TCP level and do no L7 inspection etc, you should be able to run in accelerated mode (Using the ASIC in older hardware, or the FPGA in newer hardware)
2. Yes. If the SQL servers and the WWW servers use the F5 as a gateway back to the 'client'. (You can either set that with a default gateway, OR policy routing).
3. Control... If you have >1 SQL backend, it's easier on the client to let the F5 do the load balancing. You can do things like dispatching to the fastest SQL server, dedicate one to lower SLA/response time clients etc.
4. For the SQL. By IP address is easy. For the WWW traffic, I always recommend session cookies. However you could also implement something a bit more complex with iRUles if you really want.
5. The more you do at the F5, the more you need someone with F5 experience to diagnose problems. Generally however it's easier to perform a lot of diagnostics AT the F5 when it's present (That may be a consequence of having people who understand a lot of different things though as well).
6. Nope... But you could write one...
7. Yep. Where's your firewall?
Generally I'd recommend external---firewall---F5---backendservers. The 'backendservers' can be multiple VLAN's and you can force the direct (i.e. non-loadbalanced) traffic BETWEEN vlans via the firewall if required. (Or even something more complex where SOME traffic can go direct. All by using network VS's, or iRules).
Remember these are general suggestions... YMMV.
hooleylistCirrostratus
1. I agree with Hamish. You should be able to use a Performance Layer 4 VS with a FastL4 profile for most efficient processing of the traffic.
3. Again, I agree with Hamish. Source IP persistence is going to be the simplest and lightest weight option for persistence. You should avoid trying to parse the layer 7 traffic unless you really need to. It will add a lot of complexity and overhead compared with layer 4 load balancing.
6. As with 3, avoid this if you can as it will add complexity and higher cpu/memory costs.
Aaron