ldorazio
asked on
Use Cisco CSS 11503 to load balance (or primary/secondary) MySQL databases port 3306
I'm looking for an example config, to use the Cisco CSS 11503 load balancer to send traffic TCP on port 3306 to 2 different MySQL databases. In other words, to load balance between two MySQL servers.
I'd also maybe even prefer to send all traffic to DB1 unless it's down, then send traffic to DB2 instead.
I'd also maybe even prefer to send all traffic to DB1 unless it's down, then send traffic to DB2 instead.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Nothing_Changed
doh, didnt see the other response since i was typing, sorry.
ASKER
This one with the "Sorry Server" looks like it might be perfect, I hadn't thought at all about using that....
I don't completely understand this however:
"Your database servers need to be "behind" the CSS for this to work... no network path... other than through the CSS."
My web servers are: 10.7.2.101 and 10.7.2.102
My DB servers are: 10.3.3.201 and 10.3.3.202
Currently the web servers can get to 10.3.3.x through the firewall...
I THINK it would be the VIP would be within the web server network (like 10.7.2.200) and then the services would point at 10.3.3.201 and 202, but I'm not sure?
Do I have to "turn off" access to 10.3.3.x through the firewall also?
Thanks.
Hi,
"I don't completely understand this however:
"Your database servers need to be "behind" the CSS for this to work... no network path... other than through the CSS."
It means that you have to ensure that all the traffic comes through the CSS and there is no other path for the data to take i.e. Via another router, switch etc - which will obviously negate the load balancer.
If the web server can get to the DB server through the firewall and bypass the CSS then yes you would need to prevent this and re-think the topology to prevent the data circumventing the CSS. (assuming the traffic coming from the web servers to the DB server is what you want load balanced)
"I don't completely understand this however:
"Your database servers need to be "behind" the CSS for this to work... no network path... other than through the CSS."
It means that you have to ensure that all the traffic comes through the CSS and there is no other path for the data to take i.e. Via another router, switch etc - which will obviously negate the load balancer.
If the web server can get to the DB server through the firewall and bypass the CSS then yes you would need to prevent this and re-think the topology to prevent the data circumventing the CSS. (assuming the traffic coming from the web servers to the DB server is what you want load balanced)
yep, you need to ensure that the css stays in path between your db servers and the clients or app servers using them. typically, people use the CSS as a layer three boundary (as a router essentially) between two VLANs, one that contains the servers being balanced, and the other one being either a transit to the rest of the network, or where your client nodes reside.
Reason being that the CSS balances with destination NAT. It takes a connection in and NATs it back out to one of the services configured for the content rule. If the service has another path back to the client other than thru the CSS, he will try to answer the client directly. But the client has no clue he is talking to that actual service, he thinks he is talking to a host with the IP address of the VIP in the content rule, so he ignores the response. Almost like a broken assymetrical route, sort of.
So, keeping the CSS "between" the clients and servers is the simple solution. If that's not possible, you can artificially engineer that path to be taken anyway using source groups, however that takes a lot more CPU resources on the CSS, and isn't as efficient network-wise.
Reason being that the CSS balances with destination NAT. It takes a connection in and NATs it back out to one of the services configured for the content rule. If the service has another path back to the client other than thru the CSS, he will try to answer the client directly. But the client has no clue he is talking to that actual service, he thinks he is talking to a host with the IP address of the VIP in the content rule, so he ignores the response. Almost like a broken assymetrical route, sort of.
So, keeping the CSS "between" the clients and servers is the simple solution. If that's not possible, you can artificially engineer that path to be taken anyway using source groups, however that takes a lot more CPU resources on the CSS, and isn't as efficient network-wise.
ASKER
Thank you, I will have to setup another VLAN / subnet to test this. I have the problem now that it gets to and through the CSS, but then it's going straight back to the web from DB just as you both said.
This probably won't get to be tested until next week now...
This probably won't get to be tested until next week now...
Any luck so far?