Hi Stephen, The rest of the community can chime in, but we do see customers who use a DB replication technology from their DB vendor to create a Disaster Recovery (DR) site in case the primary production site is rendered offline – e.g. due to a natural disaster. Since the bulk of AR System powered applications store their definitions and configuration data in the DB itself, that should be sufficient – with perhaps an occasionally synch between the Operating Systems to pick up changes in the configuration files, binaries or other utilities external to AR System.
DR locations are kept offline until they are needed, though – so technically you’d not have people logging into the DR system unless the primary system goes down. So if you have folks at Site 2 that need to do work then you’d need to provide access to them outside of the DR – e.g. through the scenarios I covered. If you went with the DSO solution, you could have the two sites running at the same time with a DB in both locations and use Site 2 somewhat as a DR – i.e. if Site 1 goes down, folks can log into the Site 2 system and continue working. It’s not true DR since DSO is used to transfer a subset of data between systems (enough to continue working an issue in a follow-the-sun scenario), but would limit the disruption of the primary datacenter going offline without having a DR system sitting idle. All depends on your needs and budget, of course. -David J. Easter Manager of Product Management, Remedy Platform BMC Software, Inc. The opinions, statements, and/or suggested courses of action expressed in this E-mail do not necessarily reflect those of BMC Software, Inc. My voluntary participation in this forum is not intended to convey a role as a spokesperson, liaison or public relations representative for BMC Software, Inc. From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Stephen Bunn Sent: Tuesday, December 28, 2010 3:12 PM To: [email protected] Subject: Re: multiple ar servers connected to one database ** On Wed, Dec 29, 2010 at 1:14 AM, Easter, David <[email protected]<mailto:[email protected]>> wrote: Just to answer some of your questions. Multiple servers connecting to the same database is called “server groups”. Documentation on setting those up is in the “Configuring server groups” section of Chapter 6 in the BMC Remedy Action Request System 7.6.03 Configuration Guide<http://documents.bmc.com/supportu/documents/08/30/160830/160830.pdf>. Balancing the load between severs or Mid-Tiers, and moving users over to a running system if one of the servers or Mid-Tiers goes down, is called “load balancing”. There are some white papers and presentations on BMC DN about load balancing found here: 06-Sep-2007 Using a Hardware Load Balancer with AR System 7.1.00 PDF<http://documents.bmc.com/supportu/documents/40/92/84092/84092.pdf> http://communities.bmc.com/communities/docs/DOC-2841 Thanks for the resources. I probably missed that when scanning through the documentation because I didn't know the terminology I was looking for :) That all said, I would strongly recommend against separating two servers in a server group – even across a “high speed connection”. Network lag between the AR System server and the database (especially through a firewall) can cause significant performance issues – even leading to errors and failures as timeouts occur. If you have two sites remote from each other, you should keep all the servers in one of your data centers and then place a Mid-Tier only in the remote site. This will enable the Mid-Tier to perform local operations and caching for web clients in the remote site and reduce the traffic across the high speed connection. If you don’t wish to do that, and for whatever reason require a server in each location, do not use server groups. Instead, use the Distributed Server Option (DSO) to transfer key data from one server site to the other. You’ll need a database local to each site as well with this option, though. -David J. Easter Manager of Product Management, Remedy Platform BMC Software, Inc. The opinions, statements, and/or suggested courses of action expressed in this E-mail do not necessarily reflect those of BMC Software, Inc. My voluntary participation in this forum is not intended to convey a role as a spokesperson, liaison or public relations representative for BMC Software, Inc. This is going to be a difficult decision. Your solution sounds a lot more feasible than what I have planned, my only concern with that is this. Our two sites are VMWare clusters located in different areas. What I'm trying to avoid is one of the VMWare clusters going down and bringing our entire remedy solution down with it. Do you suggest that DSO would most likely be our best option? I wonder how feasible it would be to create some sort of coop instance in the second site, where some sort of replication happens and in the event of a primary site failure, we simply start up the AR processes in the second site and they take over. We already have an application that is basically setup that way. What outside of the DB would need to be replicated? I apologize for the noobish questions, but I'm very new to Remedy and have not been through any of the training yet. Thanks for your time. Respectfully, Stephen Bunn _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_
