We support High Availability within Notifications
a couple of different ways. Now, out of the box, all
copies of Notifications support the behavior
of these two processes that we discussed earlier.
This Analytics Scheduler, which is essentially
the thing that triggers that we will start evaluating
the logic in a Notification either based on a calendar
or based on some kind of activity of
PI Tag, just gets a new value, and then the Processor
that actually executes the logic and
handles all the events of the Notification. So,
what happens if this Processor
process fails? Well, if that fails, then the Analytics Sched...
Analytics Scheduler will simply go ahead
and start up a new copy of this process. So there is
a, a bit of redundancy built into the system, you know, just
from the start by the activity of this Analytics Scheduler
kicking off new processes, if necessary.
Now, also, do you remember
we talked about there's a Configuration File here
that you could use for kind of
dividing up the Notifications responsibilities
for one AF Server among different copies of Notifications?
What I mentioned earlier is that,
you know, by specifying the same
AF Database, but different target databases,
you know, within different
copies of Notifications, then,
you know, you could have one copy of
Notifications working on, say, half of the databases,
and the other copy of Notifications working on the other
half of databases for that same AF Server.
Now that's what happens if you have configure them so that they have
different target databases. If they have the same target
databases, then what you are doing really is setting
up a redundant architecture. You are specifying
that both of them are supposed to do calculations --
essentially the same Notifications.
And, for example, if you use this
two double quotes, that indicates all databases.
If I had two copies of Notifications set up, both
pointing to the same AF Server, and both pointing
to this, you know, this, all databases,
then only one of them is actually going to
execute calculations, and it's going to be identified as a Primary.
The other is going to be a Secondary,
and it's only going to execute if the Primary fails.
Now, how that fail over occurs really kind of
depends on how the Notifications stopped on the other machine.
Let's bring up our illustration again and just kind of make the point.
So, in the event that you have, you have got this configured --
let's say you have got a second -- as I said before, he's
got a second machine configured
to run Notifications. That's connected
to the same AF Server. So, if they are both,
both of these boxes -- this Notification machine here and this
Notification machine over here -- are both
configured to point to all the Notifications
in all the databases, then only one is going to be the Primary.
Now, if this one fails
gracefully -- in other words, it kind of, you know,
winds down gracefully, then this is just going to
go ahead and start up if it's been the, the backup
or the Secondary, it's going to go ahead and start up and doing, doing those
Notifications right away. Now, if it does not
fail gracefully, if what, instead, you have is that
this, this right here, just crashes.
You know, this machine right here is just not available.
At that point we are going to wait for that timeout interval.
So, let's go back to here. Yeah, there is a
specific timeout interval that you will see --
this timeout interval specified right here, or this fail over
interval. Yeah, when that fail over interval
is met after a crash on the other -- the Primary --
then the Secondary's going to go ahead and take over.
Now you can take a look at how all this is configured on each
copy of Notifications by going into the System
Explorer. It's using Tools, Notifications Settings.
And if you go into the Service Option, you can see which
is the Primary and which is the Secondary. As I said, if you have
configured them both, you know, through this
file here, if you have configured them to be looking
at the same databases for the same AF System,
System, essentially what you have got is a system that's going
to fail over for you. You know, in, in general,
the rule of thumb there is two configure... or two
Notification Servers configured to look at the same
Notifications, well, only one of them is actually going to be doing the
processing. The other's going to be
on the ready to go ahead and fail over to -- if the
first instance fails for some reason.
Now, if you are interested in learning more about the redundancy and the High
Availability Options, if you take a look in your PI Notifications
User Guide, you will find this section here called Set Up
Redundant Server Instances. It's around Page 122, in the current
release. And then, if you go down a little bit, you will find a section
specifically on High Availability. That's where you can learn more about
this.