This is pretty much what I was thinking made the most sense, with the fewest configuration changes on the production server. I've been wanting to gain some first-hand knowledge about server groups anyway. There was a recent conversation on the list about tar'ing up the arinstalldir and copying it over. I might try that instead of running through the installs.
Question (after only a cursory glance at the docs): Can a server group alias be the same as the AR server name? Thanks for the advice everyone. Thad On Thu, Jun 9, 2011 at 8:16 PM, patchsk <vamsi...@gmail.com> wrote: > Another way is you can create a servergroup with the production > servers. > 1.Configure your DR Server to look at the production db and add it as > another server in the server group > 2.Make sure your load balancer rules also direct the traffic to DR > ARServer. > 3.Test all the components, you can play a little bit by making DR > ARServer as the primary server. > 4. Make sure everything is working, turn off the DR ARServer change > the DR ar.conf to look at DR database. > > With this method during the DR mode all you need to do is > 1.Stop ARServer, midtier webservers on production. > 2. Have the DBA make DR db as primary > 3. Restart DR Arserver. > You do not have to make any DNS changes, less moving parts. > > On Jun 9, 8:14 pm, "Shellman, David" <dave.shell...@te.com> wrote: > > Thad, > > > > We do something similar to what you describe you want to do. It's easier > now than it was a few versions ago. What makes it easier is the fixed, > floating licenses are stored in the data base. > > > > Anyway what you do is create a DNS alias for your production server. You > configure desktop clients and any MidTier servers to connect using the > alias. Any internal connections like the email engine should also use the > alias. Make sure everything works right. > > > > Install the second server to the DB instance. Make sure you do the > installation as an upgrade. Like with the production server make sure that > internal connections use the alias. Apply any server license while you have > the fail over up and running. (You can get a hot stand by server license at > no cost but you do have to renew it each year). > > > > If you need to switch to the fail over server, you shut down the > production. Change DNS alias. Start up the fail over. Desktop clients may > need to flush their DNS cache. > > > > In our case we also have several MidTier instances that are running on > separate servers around the world. Users connect to the MidTier servers > using a DNS alias defined with in the regional zone. > > > > The big thing is to test the stand by configuration at least once a year. > You will be surprised at the little things hiding in config files that you > forgot to change. > > Dave > > ------------------------- > > dave.shell...@tycoelectronics.com > > (Wireless) > > > > From: Thad Esser [mailto:thad.es...@gmail.com] > > Sent: Thursday, June 09, 2011 07:25 PM > > To: arsl...@arslist.org <arsl...@arslist.org> > > Subject: Looking for white paper on disaster recovery configurations > > > > ** > > > > Hello, > > > > I thought I had recently seen a white paper on disaster recovery for ARS, > but I can't seem to find it now, either by searching the arslist archives or > BMC's website. I found the white paper on load balancer configurations, but > that doesn't cover what I'm looking for. Basically, we are setting up a > secondary site to function as a failover (ARS stays down until needed), and > I'm looking for the best way to configure ARS. We already have a mid-tier > and replicated database set up, and now I need to put the AR server in > place. In particular, I'm thinking about server names and how best to > manage the configurations of those between the two servers (prod and > failover). > > > > That's a vague question I know, (I'm just starting down this path) so a > link to the white paper or any general advice is appreciated. > > > > Thanks, > > Thad > > ARS 7.1 on AIX > > ITSM 7.0.3 (all apps) > > Oracle 10g > > > > _attend WWRUG11www.wwrug.comARSlist: "Where the Answers Are"_ > > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are" > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
