Home > IT Answers > Storage > To have unique server names and IP addresses ...
Lightmike
245 pts.
 To have unique server names and IP addresses in secondary dedicated warm site, or not?
Disaster Recovery, Network design, IP addressing
I'm not sure which is the lesser of two evils. To go with recovery to a secondary site that emulates production (including exact domains, server names and IP addresses), or to have sedcondary site systems that have unique IP addresses and server names all on the same domain. Anyone know of resources available that discuss pros and cons?
ASKED: Aug 28, 2008  3:54 PM GMT
UPDATED: September 10, 2008  3:54:26 PM GMT
RELATED QUESTIONS
Lightmike
245 pts.
Answer Wiki:
It can be tricky to have the same address range across a WAN, in 2 distinct locations.
Will you be recovering ALL your servers in one fell swoop, or possibly just some of them?
Would you then plan to migrate back to the original (or a new) data center, again phased for at once?
Do most things work properly through DNS or WINS, or are there static IP addresses all over system scripts?


Snapper70,

Thanks for your reply. Neither of the two possible outcomes would have same IP addresses on a single WAN. We would either have 1) a WAN that had production AND secondary sites for failover when primary site is down, without duplicate IP Addresses, or 2) a WAN for production, and a physically segregated WAN for testing that could mimic production server names and IP addresses.

I keep hearing that we have been following DNS practices but then we run into an instance where there is a IP address imbedded in an application component.

I want the benefit of having a single WAN that all sites can persist on simultaneously, so we can test DR systems on the network we would use at time of disaster, but wish to avoid all the pre-test analysis and preparation that would be required to prevent potential enterprise transaction traffic/file transfers from bleeding from test into production systems.

Does anyone know of any white papers or industry best practices documentation that discusses this issue?

Mike
Last Wiki Answer Submitted:  Sep 2, 2008  1:18 PM (GMT)  by  Lightmike   245 pts.
Latest Answer Wiki Contributors:  Snapper70   920 pts.
To see other answers submitted to the Answer Wiki View Answer History.
RSS - Discussions Help
Discuss This Question:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _



 

Hi Mike,

May be I’m not understanding what you need to accomplish, but if you have private IPs, you can setup a NAT gate between main and secondary sites and have same IPs in both - the gate will take care to translate IPs when you synchronize sites, or connect from one site to another. About the DNS - if you split internal from external services, I don’t see why you’ll have any problems with the naming too…

If you have real IPs it’s also possible to use NAT scenario. You have to make sure, however, that you external DNS can promptly manage to resolve to the new IPs in a case of accident which requires use of the secondary site (or that your ISPs for both sites can promptly arrange the routing change).

BR,

Petko

Petkoa
 3,060 pts.
 

I dont know what tecnology you use for replicating data to the remote site,.

Supose you have disc mirroring over a WAN to you DR site and you have identical hardware (servers, mainframe) on both sites.
With servers booting from the SAN, you’d have identical IPS, DNS names etc on the DR site.
If you want to do a full DR test, all that has to be done is to stop the disc replica, enabling the remote discs, isolating the LAN on the DR site and power on the servers. This would enable you to conduct DR tests without impact on production site. When the test is over, powerdown the servers, enable the replica and test is over.

This really cuts down recovery time in an emergency and simplifies DR tests. It also allows you to recover a single server or group of servers in case of a failure in production site.

RPRG

Rprg
 10 pts.