Note: This is based on my experience and was valid for us up until at least ARS
7.1 patch 003, I think.
E-mail processing is considered a back-end process that is processed by a
single AR server at a time within a server group. I agree that for regular
client operations, you would want all communications to the AR server to go
through a load balancer. However, for backend processes that are only
processed on one AR server at a time such as this, having them connect to the
AR server through the load balancer does not give you a guarantee that the
e-mail engine will connect to the correct AR server, so you can't even
guarantee that e-mail processing will happen, because if the e-mail engine gets
directed to one of the secondary servers, it will effectively put itself to
sleep until the server it connected to becomes the primary. That doesn't give
you a correct failover scenario.
For the purposes of this discussion, I think it would be more appropriate to
think of the e-mail engine as a component of an AR server rather than a client
of it. While it can technically run anywhere, for failover processing to work
correctly, you should have a separate e-mail engine dedicated to each AR server
unless you can guarantee that your _single_ e-mail engine is _always_ directed
to your current primary AR server. If you have an e-mail engine for each AR
server in the group, and each e-mail engine is dedicated to one AR server
(regardless of whether or not it runs on the same host), then you have a true
failover scenario for e-mail. Once the primary AR server goes down, the next
server in the server group ranking will realize that it is now the primary
server for this type of operations, and the associated e-mail engine will take
over the task of processing e-mails. The load balancer doesn't come into the
equation for this type of failover.
Just in case I'm not making sense, let me try and illustrate this differently.
Look at two scenarios:
Scenario 1
Users ------------\ /- Server A*
E-mail Engine ----- LB ---- Server B
[Email Engine 2] -/ \- Server C
Scenario 2
/- Server A* -- Email Engine A
Users -- LB --- Server B --- Email Engine B
\- Server C --- Email Engine B
*Primary server for e-mail operations
In Scenario 1, your e-mail engine goes through the load balancer just like all
other clients. In this scenario, you don't know which AR Server the e-mail
engine will connect to. If it connects to Server A, you're fine, because
Server A is the one handling e-mail processing. However, if it connects to
Server B or C, the e-mail engine will connect and realize that the server it
connected to is not doing e-mail processing and will go to sleep (at least,
that has been my experience). No e-mail processing will happen, unless Server
A realizes that it doesn't have an e-mail engine connected to it and relegates
that responsibility to the another server that does have an e-mail engine
attached to it. It used to be that AR Server wasn't smart enough to notice
that, and so if the e-mail engine wasn't connected to the primary host, no
processing was done. If that has been fixed, then this scenario may be fine,
although you would probably only want a single e-mail engine running at a time,
since you wouldn't be able to guarantee that the other e-mail engine(s) doesn't
connect to the same host.
In Scenario 1, each instance of the e-mail engine is attached to a single AR
server and doesn't go through the load balancer. Each e-mail engine connects
to its assigned AR server, and if that server isn't the primary for e-mail
processing, it sleeps. So long as Server A is up, e-mail processing will be
handled by Email Engine A. If Server A goes down, the next server in the
ranking order will take over. For example, if B is next in line, e-mail
processing will then be handled by Email Engine B on Server B. In this
scenario, the load balancer handles the failover scenario for users when a
server goes down, but the backend processing failover is handled entirely by
server ranking. In this scenario you still have a complete failover scenario
and is guaranteed to work for both user and back-end processing.
As I noted before, my experience has been that if Email Engine A is down or
otherwise non-functional, but Server A is up, the system did not note this and
cause e-mail processing to fail over to Server B. Server A actually had to be
down before it would properly fail over. We opened a case with BMC and told
that it _was_ supposed to fail over if Email Engine A was down, and I believe a
defect was entered for that. I don't know if it has been fixed. If it hasn't
been fixed, or if you're on a version of the AR Server where it wasn't fixed,
then Scenario 1 may not work, and if it does, it may do so only intermittently
depending on whether or not the e-mail engine connected to the primary server
or not. Scenario 2 is more likely to work consistently regardless of which
version or patch level of the AR server you are on.
I hope that makes more sense.
Lyle
-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:[email protected]] On Behalf Of Richard Copits
Sent: Thursday, March 19, 2009 12:11 PM
To: [email protected]
Subject: Re: Installing Secondary Server in Server Group
I'd have to agree....if you don't have two identical setups front-ended by a
load
Balancer then you won't have a true complete failover if one fails. A well
designed
System should provide total transparency to users in case of the failure of
one....
I would like to see BMC come out with a more complete white paper or
documentation
On what has to be done in detail though....
-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:[email protected]] On Behalf Of Ramey, Anne
Sent: Thursday, March 19, 2009 1:58 PM
To: [email protected]
Subject: Re: Installing Secondary Server in Server Group
Actually, that could cause problems if one server goes down. The other won't
be able to correctly pick up the work for those items where you've specifically
set up the down server. We use the server group/load balancer name for email
and flashboards as well as web services, etc. and it all works fine.
Anne Ramey
***********************************
E-mail correspondence to and from this address may be subject to the North
Carolina Public Records Law and may be disclosed to third parties only by an
authorized State Official.
-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:[email protected]] On Behalf Of Lyle Taylor
Sent: Thursday, March 19, 2009 1:04 PM
To: [email protected]
Subject: Re: Installing Secondary Server in Server Group
I'm not sure about the documentation, but I will share one thing that I
learned. While all of the servers will have a common alias that outside
clients will use to connect to the server group (hopefully), you don't want the
flashboards and e-mail services hitting the alias. When you install those, you
should point them to the specific AR server that you want them working with.
So, for example, if your server group alias is Remedy, and it is comprised of
the servers ServerA and ServerB, the e-mail engine installed on ServerA should
be configured to point to ServerA and not Remedy. Same for flashboards.
Lyle
-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:[email protected]] On Behalf Of bruce sisk
Sent: Thursday, March 19, 2009 9:42 AM
To: [email protected]
Subject: Installing Secondary Server in Server Group
Good morning,
I am beginning to set up the second server that will then be configured in a
server group. The primary server is up and running as follows:
Windows 2003 Server
Oracle 10 DB (remote)
ARS 7.1 P6 - including email, approval, assignment, flashboards
CMDB 2.1 P4
AIE 7.1 P4
ITSM 7.0.3 P7
SLM 7.1 P1
I have successfully installed ARS 7.1 P6 (server only) on the secondary server
using the shared DB option. This is working as well.
My next steps are the various other components: email, approval, etc. Sadly,
I have found very little in the way of instructions on this. Some components
have more than others...very inconsistent.
My question is...does BMC or somebody have a comprehensive white paper or
instruction set that addresses installation of the other components like email.
Thanks,
Bruce Sisk
BFS Enterprises
________________________________________
PeoplePC Online
A better way to Internet
http://www.peoplepc.com
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are"
NOTICE: This email message is for the sole use of the intended recipient(s)
and may contain confidential and privileged information. Any unauthorized
review, use, disclosure or distribution is prohibited. If you are not the
intended recipient, please contact the sender by reply email and destroy all
copies of the original message.
Portions of this message may be confidential under an exemption to Ohio's
public records law or under a legal privilege. If you have received this
message in error or due to an unauthorized transmission or interception, please
delete all copies from your system without disclosing, copying, or transmitting
this message.
