On Wed, Dec 29, 2010 at 1:14 AM, Easter, David <[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 :)



>  <http://communities.bmc.com/communities/docs/DOC-2841>
>
>
>
> 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

_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

Reply via email to