|
Nirvana servers can be clustered
together to form part of a single logical namespace.
This can then be used to achieve dynamic data routing
between realms, clustering, HA (High Availability) etc.
For example if you want to set up a cluster running
across two different machines with Realm1 running
on host1.my-Channels.com and Realm2 running
on host2.my-Channels.com.
Firstly, you add Realm2 to namespace of Realm1. This
will allow all channels, queues and services on Realm2
to be accessible from a session with Realm1.
Step 1: Adding a Nirvana Realm into another
Realm's namespace
This can all be acheived in one of three ways
1) using the nAddRealm
sample application
2) using the
RealmManager GUI
3) Programatically
using the Nirvana Client API
For the purposes of this FAQ the nAddRealm sample program
is used however it may be more convenient to add realms
using the Realm
Manger GUI :
There are a number of paramters you need to provide
for the naddrealm sample app:
naddrealm <realm name> <realm details>
[mount point]
The realm name is the <realm name>
of the Realm you are adding to this namespace. It appears
in the realm manager at the top of the namespace tree
beside the globe icon. It default is 'Nirvana' from
the installation). * This must be specified
exactly as it appears in the realm manager of the realm
you are adding. If both Realms have been installed using
the default Realm Name then the nserver.lax file can
be edited to change the Realm on the next restart. Change
the -DRealm property to the new name. Alternatively
at install chose the sutome install option and give
the Realm a custom name.
The <realm details> is the RNAME
that you wish the realms to communicate using, this
can be any interface that is defined within the realm
you are adding.
The [mount point] is an optional symbolic
name by which the realm you are adding will be referencable,
if left out, the <realm name> is used as the mount
point.
For example from within a Nirvana client environment
on host1, Realm2 can be added to the Realm1 namespace
under the /uk folder you would type the following: (assuming
that Realm2 has a Nirvana HTTP interface
(nhp) running on port 80):
naddrealm Nirvana nhp://host2.my-Channels.com.com:80
/uk
Simalarly, to add Realm1 to the Realm2 namespace under
say the /us folder, you would type the following command
in Realm2 client environment: (Again assuming that Realm1
Nirvana socket interface running on port 9000).
naddrealm Nirvana nsp://host1.my-Channels.com:9000
/us
The next step is to join the channels from realm1 to
the channels on realm2 and vice versa.
Step 2: Joining the channels across different
Nirvana Realms
By joining channels, all events that are published
to the source channel will also be published to the
destination channel. Except when a filter is applied
to a join in which case only events that match the filter
will be propagated over the join.
Channels can be joined in one of three ways:
using the nMakeChanJoin
sample application
using the RealmManager
Programatically
using the Nirvana Client API
For the purposes of this FAQ the nMakeChannelJoin sample
is used, however it may be more convenient to use add
joins using the Nirana
Realm Manager GUI:
nmakechanjoin <sourceChannel> <destinationChannel>
So to join a channel called sales on Realm1 to a channel
called sales on Realm2 you type the following from a
Realm1 client command
prompt.:
nmakechanjoin /sales /uk/sales
similarly to join the sales channel on Realm2 to the
sales channel on Realm1 you type the following.:
nmakechanjoin /uk/sales /sales
This ensures that any events published to the Realm1
sales channel will also appear on Realm2 sales channel,
and any events published to Realm2 sales channels will
also appear on Realm1 sales channel.
If Realm1 was in the UK and Realm2 was in the US, and
there were 1000 clients connected to Realm1 in the UK
who also needed to consume data from Realm2 in the US,
rather than having those 1000 clients connect from the
UK to the US channel directly and each event be delivered
across the WAN 1000 times, by using joins, each event
is only delivered once from the US to the UK channel
and the 1000 clients consume the data from the local
UK channel. This conserves critical bandwidth and ultimately
provides better scalability and performance.
Step3: Setting up failover configurations for
publishers and subscribers
When you initialise a client session
with a Nirvana server you provide an array of RNAME
urls as the argument to the nSessionAttributes object.
This ensures that if you lose the connection to a particular
Nirvana Realm, the session will be automatically reconnected
to the next realm in the RNAME array.
Using the configuration above where channels have the
same name on each Realm, disconnected clients will automatically
continue publishing/subscribing to the channel on the
newly connected realm.
For example, to use the two Realms described above
for failover you would use the following as your RNAME
value using a comma separated list of individual RNAMES
RNAME=nhp://host1.my-Channels.com:80,nsp://host2.my-Channels.com:9000
If all subscribers and publishers are configured in
this way then failover is provided in each of the following
scenarios. Note in a failover scenario it may make sense
to have publishers publish separately to channels on
respective Realms and forego the use of joins. Under
that configuration subscribers failover but publishers
do not.
scenario: subscriber loses connection to
a Realm
if a subscriber is consuming data from the sales channel
on Realm1 and loses its connection it will automatically
attempt to connect to its additional RNAMES (in this
case nsp://host2.yourdomain:9000) and resume consuming
from where it left off.
scenario: publisher loses connection to a
Realm
If a publisher loses a connection to its Realm it will
automatically reconnect to the alternative realm and
continiue publishing there. Because the channels on
Realm1 and Realm2 are joined to each other in both directions
then events will be passed over to the alternative channel.
In a production scenario it is important to consider
carefully whether publishers should failover. If the
publish rate is very high it may be better to use multiple
publishers to separate realms rather than employing
realms. For more information on HA configuration options
please contact the my-Channels
support team who will be happy to outline the pros
and cons of the various HA configurations available.
scenario: publisher and subscriber are connected
to different realms.
As channels on Realm1 and Realm2 are joined to each
other in both directions then events published to a
sales channels on either Realm will be passed to sales
channel on the other realm. As long as subscribers are
consuming from a sales channel on one of the realms
they will receive all events. Thus full guaranteed delivery
is provided even if the publisher is publishing to Realm1
and subscribers are consuming from Realm2.
Please see the Nirvana FAQ for content
filtering to see how joins can be used to provide
guaranteed data routing based on content.
Multiple channels can be joined together from multiple
realms, with each event being guaranteed to be delivered
once and once only to each subscriber regardless of
where it was published to originally. For example a
channel may be joined to 10 other channels running on
10 different realms, there is no limit to the number
of joins a channel may have.
|
