cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3531
Views
90
Helpful
62
Replies

Add secondary CSS to DR site for failover

wilson_1234_2
Level 3
Level 3

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?

62 Replies 62

Gilles Dufour
Cisco Employee
Cisco Employee

you can use a CSS at the DR site, but to select one site or the other, you need to act at DNS level and in this case, what you want is a GSS [global site selector].

The CSS has dns functions but we recommend to use a GSS instead.

Gilles.

this method is definitely not supported anymore.

You should go for GSS solution or zone based dns on the CSS - not rule based as shown in the old example mentioned here.

Gilles.

I have services set up on the CSS now, with VIP addresses configured for the two internal web servers.

The externally hosted DNS names resolve to the VIP addresses and then redirected to the Primary server.

If that is now I have sorryServers configured as the backup.

This works great, so my questions are:

Will config for the CSS I have working now, require a drastic change to add the second one at the DR site and implement GSS solution or zone based dns?

Where are some examples of the GSS solution or zone based dns?

Gilles,

Why is that not supported? And what exactly does it mean to not be supported anymore?

it means that if you one day encounter an issue with dns on the CSS, we might tell you to move out of this solution instead of fixing it.

This is the same for the CSM and the new loadbalancer, ACE, will not offer this feature.

So, if you have to deploy a new setup, you should definitely go for GSS.

Gilles.

I have the CSS devices at the moment and they were recently purchased, so I have to use what I have.

So, are there any configuration examples for what i want to do?

Wilson, the link I posted contains the example for what you want to do. I guess it is unsupported but that doesn't mean it won't work. I have it running myself. Let me know if you need help setting it up.

Gilles, I'm not familiar with GSS. Would this work with another CSS or do you need a pair of GSS's? Can Wilson use his existing pair of CSS and use another solution than the one referenced above?

Thanks,

I guess I have these questions:

I have the existing CSS configured and it is working as a stand alone and is redirecting web requests to the primary server using services, if that is down, it redirects to the secondary server across our MPLS to the DR site.

1. Can I just add the neccesary DNS information to my existing congig?

2. How do you have the failover to the second CSS working if your main site Internet connection is down? What redirects the client DNS request to the second CSS.

3. I guess question 2 is also how does CSS1 failover to CSS2?

1. not sure what you mean but what good would that do anyway if the css was unavailable? It can only redirect to the secondary site if it is actually reachable.

2. You will have 2 NS records and 2 A records defined at authoritative dns. Something like this...

NS mydomain.com cssprimary.mydomain.com

NS mydomain.com csssecondary.mydomain.com

A cssprimary.mydomain.com 1.1.1.1

A cssprimary.mydomain.com 2.2.2.1

Then at the CSS level each will contain an A record for the domain mydomain.com

Primary CSS - A mydomain.com 1.1.1.2

Secondary CSS - A mydomain.com 2.2.2.2

3. CSS1 and CSS2 are in constant communication with eachother through an app session. This is how each knows which services are available etc. and which address to return. If the request lands at css1 and the primary service is up, it knows to return it's local vip address. If the request lands at css2, it knows through the app session whether or not the primary service is up, if it is not and it's local service is up, it will return it's local vip address, therefore creating a backup. Hope that makes sense.

I was talking about:

Right now, the setup is only one CSS at the main site, if everything (Internet connectivity) is up and the HQ server goes down, the CSS redirects the client web requests to the secondary server.

I want to implement the solution you have in case the Internet or the building get wiped out the web requests are redirected to the DR site.

Now, another question:

1. Is this common practive the Primary secondary entries and MCI (who hosts our DNS) can do this with no problem?

2. How fast is the DNS transition to the secondary record (pretty fast I am thinking).

3. Do the CSS devices need any more configuration added to accomplish this? It looks like with this scenario, you don't.

1. I can't imagine having a problem adding/changing your dns records (A, NS, MX etc.)

2. From my experience it is very fast. I can sit next to my server and run an nslookup, and unplug the server, by the time I run another nslookup the address has changed. This of course depends on how your keepalive is setup for the service etc.

3. The only configuration needed is shown in the linked document. You also need the "Enhanced Feature Set" License to run this feature.

I see what you are saying, but I have the CSS configured with two seperate servers.

Outside DNS is resolving names to the VIP address configured. If the service that points to the local server is up, the CSS directs the request to that server.

It works great as with only the primary Internet connection in play, there is nothing configured if the the primary link goes down.

I am not sure if I can modify the existing config to implement this.

My config:

!************************** CIRCUIT **************************

circuit VLAN1

ip address 2.1.1.75 255.255.255.0

!************************** SERVICE **************************

service MCI-MCW-backupredirect

type redirect

port 80

keepalive type none

redirect-string "www.p.com"

ip address 2.1.1.73

active

service MCI-MCW-dr

ip address 2.1.1.77

protocol tcp

keepalive type http

port 80

active

service MCI-MCW-dr-443

ip address 2.1.1.77

protocol tcp

port 443

active

service MCI-MCW

ip address 2.1.1.76

protocol tcp

keepalive type http

port 80

active

service MCI-MCW-443

ip address 2.1.1.76

protocol tcp

port 443

active

service MCI-p.com-backupredirect

type redirect

port 80

keepalive type none

redirect-string "web.p.com"

ip address 2.1.1.76

active

service MCI-p.com-dr

protocol tcp

port 80

keepalive type http

keepalive uri "/index.asp"

ip address 2.1.1.74

active

service MCI-p.com

protocol tcp

port 80

keepalive type http

keepalive uri "/index.asp"

keepalive retryperiod 15

keepalive frequency 15

ip address 2.1.1.73

active

!*************************** OWNER ***************************

owner MCI-MCW

content MCI-MCW-http-rule

add service MCI-MCW

primarySorryServer MCI-MCW-dr

balance aca

secondarySorryServer MCI-MCW-backupredirect

vip address 2.1.1.70

protocol tcp

port 80

url "/*"

active

owner MCI-MCW-443

content MCI-MCW-https-rule

add service MCI-MCW-lk-443

primarySorryServer MCI-MCW-dr-443

vip address 2.1.1.70

protocol tcp

port 443

active

owner MCI-p.com

content MCI-p.com-http-rule

add service MCI-p.com

balance aca

protocol tcp

port 80

url "/*"

primarySorryServer MCI-p.com-dr

secondarySorryServer MCI-p.com-backupredirect

vip address 2.1.1.71

active

!*************************** GROUP ***************************

group MCI-MCW-http-group

add destination service MCI-MCW

add destination service MCI-MCW-dr

vip address 2.1.1.70

add destination service MCI-MCW-443

add destination service MCI-MCW-dr-443

active

group MCI-p.com-http-group

add destination service MCI-p.com

add destination service MCI-p.com-dr

vip address 2.1.1.71

active

!**************************** ACL ****************************

Hey,

What happens to the existing DNS records (and Client name resolution) when you make this change to your DNS records?

Do they loose connectivity while the name records converge?

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: