> -----Original Message----- > From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On > Behalf Of Michael MacIsaac > Sent: Friday, September 02, 2005 11:05 AM > To: [email protected] > Subject: How to do a planned DR test? > > > Hello list, > > Has anyone addressed the issue of how to do a planned DR > test? Here are > the assumptions: > -) There is a production z/VM+Linux LPAR at the primary data center. > -) There is a DR site where the production LPAR volumes, etc. are > replicated. > -) A planned DR test is necessary. > > In a real disaster, the DR site will use the same IP/DNS as > the production > site which by definition is down. However, to do a planned DR test, > different networking information is required so as to not > conflict with > the primary site. So how do you tell: > (1) z/VM - bring up TCPIP with this alternate networking > information, and > (2) Each Linux to come up with alternate networking information. > Then the DR site can be tested. > > The contingency of a real disaster occuring during the DR test must be > addressed. At that time the DR test must be abandoned and the > DR site must > be brought online with the real network information (so modifying the > Linux networking info in the DR site file systems is not a > good option). > > I can see how you can address (1) - maintain a second TCPIP service > machine - say TCPIP2. Bring up z/VM without AUTOLOG and > manually bring up > TCPIP2. But how to address (2)? Is anyone doing this? > > "Mike MacIsaac" <[EMAIL PROTECTED]> (845) 433-7061 >
Literally ALL of our IP addresses used by all our machines are "private" (10.a.b.c). Those IP addresses which are visable to the outside actually reside in our Cisco PIX firewall. It has "rules" that any specific incoming IP address is translated to the "inside" address and passed along. This is rather simple to accomplish with the PIX. During a DR test, all the servers retain their normal, private, IP addresses. The firewall which connects us to the Internet at DR is given a set of public "test" IP addresses (by the DR provider), which are translated by the PIX to the appropriate internal address. This is done by our LAN people. It is not really very difficult. Outside users use these "test" public IP addresses (not the "live" production IP addresses) during their testing. I think this is called a "transparent proxy" or some such thing. The same for outgoing. The PIX translates the internal IP address to the appropriate external IP address. For non-servers, such as desktops, or servers which are not in the DMZ, access to the internet is via the same PIX, but uses the "NAT" capability of the PIX so that all desktops appear to have the same IP address to the outside world. I think that in the case of a real disaster occurring during a DR test, we would have Iron Mountain pull our "ODR1" vault and ship it to the DR site. We would then restart the DR recovery using these more current tapes. Or we might just do a forward recovery of the application data, since it is likely that the OSes did not change much (our test tapes are usually only a couple of weeks old). As far as the IP addresses go, I don't know if the PIX would be updated to start using our production public IP addresses, or if we would send out DNS changes to use the vendor supplied public IP addresses. I'm not in the IP recovery area. -- John McKown Senior Systems Programmer UICI Insurance Center Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its' content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
