Add secondary CSS to DR site for failover

[wilson_1234_2]

I have a CSS configured for web server failover.

We have two servers providing different fuctions that failover to backup servers at the DR site if one or the other server fails.

This is all working fine.

We want to add a second CSS at the DR site to provide access to our web servers if the Main site gets wiped out.

The DR site would also provide connectivty to the web servers if there is a loss of Internet connectivity at the main site.

How much configuration would be needed to my existing config to allow for this?

I would also have to configure the secondary CSS to be the failover unit.

Are there any examples on how to do this?

[wilson_1234_2]

1. Are there any examples that show how this is configured for the app session, and the services.

2. As far as the services go, would the DR config be pretty much the same as the Main site config, which shows the Main site servers as the primary?

3. I am thinking I can leave my services set up as they are already, and add the DNS components to the configs. Is this the case?

4. In the example above, why do I have the A records AND the NS recods in my hosted DNS?

Are the CSS devices having name querys relayed through my hosted DNS?

5. If I make these changes to my hosted DNS, what will happen to my existing client requests while this is propagating?

[acomiskey]

1. There is an example of the app command and services in this doc as well http://www.cisco.com/en/US/products/hw/contnetw/ps792/products_configuration_example09186a00801dcd75.shtml

2. Not really, the DR site config would only contain services at the DR site, the main site config would contain services at the main site. The CSS's know the status of the other site's services through the app session.

3. I wouldn't see why not but I'm no expert.

4. This is because you cannot create an NS record which points to an ip address directly, an NS record must point to a hostname. So therefore you create an NS which points to a hostname which in turn resolves by A name to an ip address. This does nothing more than direct the dns requests to the CSS's.

5. If the CSS is ready to resolve the requests when you make the changes to the hosted DNS, there shouldn't be any downtime. I would test it with a subdomain if you want to try it out...test.mydomain.com.

[wilson_1234_2]

My thought for question #2 is that if the main site Internet connectivity dies, I still want the main site servers to be the primary servers.

And allow the failover process to be the same from the DR site as with the Main site.

So, no matter which Internet connection is being used, and if the primary servers are still alive, they will be the first selected.

If the Main site is gone completely, the failover would be seemless to the secondary servers with the same DNS names.

Is this possible?

[acomiskey]

wilson, I'm sure that's possible but we'll need one of the experts here to explain the best way to do it.

I guess you have a direct connection between the two sites?

[wilson_1234_2]

acomiskey, thanks for the reply.

I think it should work, because I have the standalone CSS doing that right now from the Main site.

If the Primary server is rebooted, it will failover to the secondtary server at the DR site throguh our MPLS connection to DR.

Once the Primary server is back up and the service is active, the Primary takes over again.

The DR site would be doing the same thing really, just reversing which is the primary server in respect to the site.

[acomiskey]

You need a way to tell the backup css that if a request lands on it to prefer the main site if

1. the main server is up across primary connection

OR

2. the main server is up across secondary connection

Take a look at the acl which is written in the backup css in the doc I have been referencing.

[wilson_1234_2]

Ok,

I did look at that document and saw the ACL for that.

That brings up another question which is:

What determines which NS that I am going to add to my hosted DNS gets hit first for the web request.

Is it random, and the CSS forwards the request to the prioritized active service?

[acomiskey]

Are you asking which CSS gets hit first? I will have to test and see what happens but the whole idea is that no matter which it lands at, it will resolve to the same ip.

[wilson_1234_2]

Ok,

But if I have the DR site as a backup, there is no way for it to have the same IP correct?

I thought that was the idea was to have DNS configured to resolve the name to which IP address is active.

The CSS devices act as a DNS relay,

If the Main site is live then,

www.mycompany.com is 1.2.3.4

if the main site is dead then,

www.mycompany.com is 2.3.4.5

If the Main site is down, the name gets resolved to the DR site subnet,

correct?

If this is so, than what happens if the main site is dead and the NS1 (CSS1 in hosted DNS) cannot be contacted?

Does hosted DNS automatically direct requests to NS2 (CSS2 in hosted DNS)?

Sorry if I am not making any sense.

[acomiskey]

I'm sorry, should have been more specific.

"But if I have the DR site as a backup, there is no way for it to have the same IP correct?"

-What I was trying to say is no matter where the dns request lands, backupcss.mydomain.com or primarycss.mydomain.com, the css's will resolve the requested domain name (youdomain.com) to the same address. If the main site is up, both css's will resolve the domain name to 1.2.3.4. If the main site is down, both css's will resolve to 2.3.4.5.

You asked which css the request lands at, I was just trying to say that it doesn't matter because they will resolve the request to the same address.

"If the Main site is down, the name gets resolved to the DR site subnet, correct?"

-Yes

"If this is so, than what happens if the main site is dead and the NS1 (CSS1 in hosted DNS) cannot be contacted?"

-Yes, at least that is what I've seen. You are making sense. If you look at your primary zone configuration, you can also assign a priority to the css NS entries. Mine right now are both priority '0'. It appears that most requests land at the primary site, but some do land at the backup. My guess is it is somewhat round robin'd. I'm no dns expert so I can't say for sure. But yes, for this to work, I can completely wipe out my primary site and my requests will then land at CSS2.

[wilson_1234_2]

Whew!

I thought I was getting it all mapped out in my coconut, then suddenly I thought I had it wrong.

Sorry for all of the questions, but I like to understand as much as I can.

Where the heck is gdufour? I don't think he likes to get too involved with amatures like me.

[acomiskey]

Any progress with the zone based dns?

[wilson_1234_2]

Well, I have to go to the DR site and get the CSS.

I am going to leave the main site one alone for now since it is in service on the network/Internet.

Once I have the DR one configured, I am going to test to make sure it will handle DNS requests, then I am thinking I should be able to install the DR CSS, set up the apllication between the two and DNS on the Main site CSS.

Once I am sure the two are communicating properly in service on the Internet, I will check the DNS resolution.

If they both work, I should be able to throw the switch on the Hosted DNS config changes.

[acomiskey]

Wilson, I cannot get the dns resolution on the backup css to prefer the main site using zone based. I can only get it to round robin. Let me know if you get that far and figure it out. Setting up the zone based was a piece of cake, unfortunately it doesn't seem the acl in the backup css has any effect.

[bs6825]

I have owrked through these same issues for a client. Not easy. One item I didn't see mentioned is that clients will cache DNS records and continue to attempt to access the down site without contacting DNS for a new address. Another otion is to advertise the same IP space in both locations and use BGP to make the primary site preferable. This also has some issues with convergence and advertisements, but it seems to be working.