12-07-2010 01:04 AM
Hi,
assume we have a serverfarm with three realservers. But one of them is very slow, and therefore it should only get active when “both” other two servers fail.
I have found the following options, and would like to ask you to confirm if these configuration examples are correct.
1. backup serverfarm
Configuring a second serverfarm, put the slow server in there, and configure this SF as a backup sorry-serverfarm.
real SERVER1-MAIN
address 10.10.10.101
inservice
real SERVER2-MAIN
address 10.10.10.102
inservice
real SERVER3-BACK
address 10.10.10.103
inservice
!
serverfarm FARM1-MAIN
real name SERVER1-MAIN
inservice
real name SERVER2-MAIN
inservice
!
serverfarm FARM2-BACK
real name SERVER3-BACK
inservice
!
vserver SERVICE1
serverfarm FARM1-MAIN backup FARM2-BACK
Alternatively I can use a policy between the vserver and the two serverfarms.
policy SERVICE1-POLICY
serverfarm FARM1-MAIN backup FARM2-BACK
!
vserver SERVICE1
no serverfarm
slb-policy SERVICE1-POLICY
The backup serverfarm would take over in the case both realservers in the primary serverfarm fail. The primary serverfarm would take over back the service, if one of the two primary servers get back inservice.
This would meet the requirement, is that right and is this configuration example correct?
2. weight zero
Configuring a single serverfarm and use weight values to prioritize both active realsververs.
serverfarm FARM1-Main
real name SERVER1-MAIN
inservice
weight 50
real name SERVER2-MAIN
inservice
weight 50
real name SERVER3-BACK
inservice
weight 0
As long as there is a realserver with a weight above zero in that farm, the third realserver would not get any connection. If there is no other server inservice in that farm (servers 1 and 2 fail), the third server is getting the connections, as long as there is no other server inservice with a higher weight.
Because I have not found any “official” configuration example on Cisco doc, I would like to ask you, if this really is functional? Because for my understanding, a weight of zero would not give any request to that server, whatever value or status the other servers in that farm are. But I might be wrong. Therefore:
This would also meet the requirement, is that right and is this configuration example correct an functional?
Do I have to consider anything else?
This configuration would only work with the “predictor leastconns” or the “predictor roundrobin” in the serverfarm configuration part, is that right?
3. backup real server / inservice standby
As far as I know, this option would not be a solution, because the backup server would already get active if one of both primary fails:
serverfarm FARM1-Main
real name SERVER1-Main
backup real SERVER3-BACK
inservice
real name SERVER2-Main
backup real SERVER3-BACK
inservice
real name SERVER3-BACK
inservice standby
Thanks in advance
Hakan
12-07-2010 07:15 AM
Hi Hakan,
Whenever the primary serverfarm is down (all its vservers have failed or are down), the CSM will start using the sorry serverfarm servers to serve requests to the vserver.
new connection will use the backup serverfarm but existing active connection will try to use the old serverfarm.
You need to configure a 'failaction [purge|reassign]' to change this behavior.
The CSM only allow 1 backup server. When a client is connected to a server, it stays connected to that server even if a new server goes up. Only new connections from the client would be sent to a different server.
Also make sure that the client/server vlans exist on both chasis and are trunked between two chassis.
Don't forget to add probes to your serverfarms to detect failures.
As you have already created 2 serverfarms. One for the active server and one for the standby.
Then under the vserver do the following :
'serverfarm
So in case if the primary serverfarm fails the vserver will switch to the backup serverfarm and will stay in service. ie the vserver does not go out of service.
Also there is a way to limit the number of connections allowed and if that limit is exceeded then send users to a different server with a "application busy" type error page.
You can configure a maxconns limit under the vserver config and that limit is reached does it then use a defined backup serverfarm.
So in case if the maxconns is reached and the CSM uses the backup serverfarm, are the real servers marked as out-of-service. If so presumably they are put back in service once the number of connections falls below the maxconns limit.
Each server that will reach the maxconn will be put out-of-service until the number of connections drop.
If no more servers are active, than a backup serverfarm will be used if it has been configured.
Connections active with a server are not affected when this server goes out-of-service.
This is the only way to achieve what you want.
You Should use the following config so that if both of the two real servers in the serverfarm fails then only the backupserver farm realsever will work.
real SERVER1-MAIN
address 10.10.10.101
inservice
real SERVER2-MAIN
address 10.10.10.102
inservice
real SERVER3-BACK
address 10.10.10.103
inservice
!
serverfarm FARM1-MAIN
predictor abcd....
failaction reassign
health retries 30 failed 60
real name SERVER1-MAIN
inservice
real name SERVER2-MAIN
inservice
!
serverfarm FARM2-BACK
predictor efgh....
failaction reassign
health retries 30 failed 60
real name SERVER3-BACK
inservice
!
vserver SERVICE1
serverfarm FARM1-MAIN backup FARM2-BACK
Alternatively I can use a policy between the vserver and the two serverfarms.
policy SERVICE1-POLICY
serverfarm FARM1-MAIN backup FARM2-BACK
!
vserver SERVICE1
no serverfarm
slb-policy SERVICE1-POLICY
inservice
real name SERVER2-MAIN
inservice
!
serverfarm FARM2-BACK
real name SERVER3-BACK
inservice
!
vserver SERVICE1
serverfarm FARM1-MAIN backup FARM2-BACK
Alternatively I can use a policy between the vserver and the two serverfarms.
policy SERVICE1-POLICY
serverfarm FARM1-MAIN backup FARM2-BACK
!
vserver SERVICE1
no serverfarm
slb-policy SERVICE1-POLICY
----
You can add the following config and then try and replace/modify some of the vserver in your above config :
vserver vs-FARM2-BACK
virtual 10.10.10.103 any
advertise active
sticky 1
persistent rebalance
slb-policy FARM2-BACK
inservice
where slb-policy pl-FARM2-BACK has the following configuration:
policy pl-FARM2-BACK
serverfarm FARM1-MAIN backup FARM2-BACK threshold inservice 2 outservice 2
From the above configuration we were expecting the following:
-serverfarm FARM2-BACK would be used in case less then 2 reals were available on the server farm SERVER1-MAIN.
-server farm FARM1-MAIN would be RE-used in case at least 2 real were available.
--
See the output of the following commands:
Cat6509#show mod csm 6 serverfarms name FARM1-Main detail
This server farm (FARM1-Main) is your main server farm. Change the csm module 6 with your module number
Cat6509#show mod csm 6 serverfarms name FARM1-BACK detail
Cat6509#show mod csm 6 vservers name vs-FARM2-BACK detail
Cat6509#show mod csm 6 policy name pl-FARM2-BACK
Please write further your queries in this regard and i would try to answer those.
HTH to answer few of your question.
Please rate if you find this information useful to you.
Kind Regards,
Sachin Garg
12-08-2010 12:54 AM
Hi Sachin,
thanks, you wrote very useful information.
I think the option with with the backup serverfarm is clear so far now. If we choose this option, I merely had to check some of your additional configuration suggestions.
But do you have also experience with the single serverfarm and "weight 0" on the backup realserver scenario?
If this works, it would also be interesting, because it would need to configure only one serverfarm.
Thanks
Hakan
12-08-2010 01:23 AM
Hi Hakan,
A weight of 0 is now allowed for graceful shutdown of existing connections. The backup real command can be used in these situations where a server farm is specified:
•Directly under a virtual server.
•In a policy and then associated to a virtual server.
This example shows how to enable a real server:
Cat6k-2(config-slb-real)# backup real 10.2.2.1 3
Cat6k-2(config-slb-real)#
Kindly check the below mentioned URL for more options.
http://www.ciscopress.com/articles/article.asp?p=1355228
HTH
Sachin Garg
12-08-2010 03:30 AM
Hi Sachin,
thanks again, but this does not clear my question. Because I have heard, that you can set a realserver inside a single serverfarm in a backup state for all other servers with a weight greater than zero.
E.g. see this previous discussion:
csm setup for active/backup sql server
https://supportforums.cisco.com/message/445700
[...]1. The csm should direct all traffics to server1. When server1 is down, it should direct to server2 and stay with server2.[...]
[...]someone suggested me to use 'backup real' command. I could not make it work, so I used weight 0.
Is there any problem with this weight 0 command?[...]
Unfortunately this discussion does not lead to a definitively answer. Therefore I tried to clear it again. The relevant configuration could be as following, but I dont know if this ist valid:
serverfarm FARM1-Main
real name SERVER1-MAIN
inservice
weight 50
real name SERVER2-MAIN
inservice
weight 50
real name SERVER3-BACK <<< should only get active when both server1 and 2 fail ???
inservice
weight 0
If you, or someone else has an idea, please let me know.
Thanks
Hakan
12-08-2010 05:42 AM
Hi Hakan,
Is there any specific reason for putting the 3 rserver in the same serverfarm, rather then putting it in a different serverfarm and then make it the backup serverfarm. In your scenario you should use "inservice standby" command for your backup rserver if you have configured the sticky as well.
In general the 'inservice standby' is actually the prefered solution for the CSM.
The 'weight 0' is the CSS equivalent.
"no inservice" and "inservice standby" are used to gracefully shutdown the real servers. "Inservice standby" is used for shutting down (taking out of LB logic) a real server when stickiness is configured.
As per my knowledge the weight could be anything between 1 to 200 and default is 8.
So even if you give weight 0 it will take at least 1.
You can check this by using show ip slb reals
Sachin
12-08-2010 08:45 AM
Hi Sachin,
well, now I have configured a test vserver and could confirm, that the 'weight 0' idea is actually not functioning.
When configuring a realserver with a 'weight 0' the server ist announced as "DFP_THROTTLED" (DFP_THROTTLED—The Dynamic Feedback Protocol (DFP) agent sent a weight of 0 for this real server (send no further connections to this real server) - found on cco). If this is the only rserver in a farm, then the whole vserver is out of service.
Therefore, if you configure a 'weight 0', the server takes that weight as well and does not service new connections.
As a conclusion: the only way to build the requested backup scenario seems to configure the second backup serverfarm with the slow server.
Thanks again.
Kind regards
Hakan
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide