Michael Lum wrote:
On 03/01/05 15:39, Marcel Ruff wrote:
Principally your configuration should be possible.
Why do you need the mirrored master? For fail over (HA)?
Yes, high-availability is the primary reason.
OK.
The other reason is that
I also have applications that would publish directly to the masters. So
the masters would be receiving messages from the slaves, as well as
messages directly from clients, but the subscribers could be on any of
two machines for HA purposes.
Here our master/slave approach should be sufficient.
Unfortenately, for master mirroring a plugin is not enough:
xmlBlaster/src/java/org/xmlBlaster/engine/cluster/ClusterManager.java:369
does for example forwardPublish().
This calls getConnection() which is implemented on line 627.
If you change the return type to return an array (or a Set)
of "NodeDomainInfo" (which is the found master or the stratum nearer
to the master)
instances instead of only one
you could address two or more masters.
You would need to remove the "break;" on line 698 and
than handle multiple higher priority masters in all follow up code.
OR probably a better approach is that the message is only routed
to its single master and when the master is reached this one mirrors it
to neighbour masters (what about fail over in this case?).
It seems like the first option sound reasonable for HA purposes -- since
you probably want to have a server deliver messages to 1) its cluster
peers, and 2) its masters. The tradeoff is additional performance
overhead due to the additional network traffic and possible redundant
messages, but you gain the HA capability. It's probably something that
should be configurable, since if one wanted to only deliver to a 'site
master' that then mirrored to its peers, you could probably achieve that
with a master-slave relationship.
Yes, this certainly must be configurable.
This discussion is probably more for xmlblaster-devel, but if I specify
multiple forwardPublish() destinations, AND am using asynchronous
delivery (for example if one of the cluster members is down), will
messages be delivered using separate threads to each of the servers I
need to forward messages to? When XB is in synchronous delivery mode,
it is easy, since we deliver all messages to the servers that are listed
as authoritative for that domain, however, if a cluster member is down,
you want to queue up messages bound for that member, but still deliver
to the other members that are up. Does this work out-of-the-box?
Yes, forwarding of messages to another node uses the normal
xmlBlaster client library with queuing support, fail over support etc.
Everything is configurable here.
Regards,
Marcel
Just play a bit in those code sections and report your
success.
Please use the current code from svn for this so we can
easily add your patch.
best regards
Marcel
Thanks
Mike
On 03/01/05 12:48, Marcel Ruff wrote:
Michael Lum wrote:
Hello,
I couldn't figure this out from the reference book and didn't find
anything on the mailing list --
How can I setup two nodes in a cluster to be peers? I'd like to
put two machines behind a load balancer, so that any client could
publish a message, but it might end up on one of the two machines
depending on where the load balancer sends it. Also, subscribers
would connect via the load balancer, so any subscriber might end up
on one of the two machines. But, I need any message published to
any of the two machines to be receieved by all subscribers, so if a
client connects publishes to server 'A', subscribers on server 'A'
AND on server 'B' get copies of the message.
Finally, if possible, I'd like these two nodes to be slaves to a
pair of masters, so that both the two slaves that are peered AND
the two masters (also peered) are getting copies of messages.
Thanks...
Mike
Mike,
these are nice features which are not available yet,
but xmlBlaster should definitely support such scenarios
in the near future.
1. load balancer
I could imagine that the load balancer initially chooses
an IP of one of the xmlBlaster slaves and the client sticks
to it until it is finished or until the connected xmlBlaster
server stops.
If the load balancer shall intercept each publish call
you need to have sort of a proxy running on the load balancer.
In the simplest case this is a xmlBlaster slave itself
or a sligthly extended SOCKET protocol plugin ...
2. master slave operation
This is available already.
3. master mirroring
I believe you need this feature of having two masters
to have high availability (HA) support.
This is currently not supported directly by xmlBlaster
but we are not far away of it.
Probably it can be handled by a master/slave operation
of the two backends and by a dynamic reconfiguration
from slave to master when the original master breaks away.
Here the typical cluster reconfiguration logic applies,
they need a heart beat and a solid decision which of the
remaining sub clusters takes over control in case of problems.
-> Depending on your exact use case the existing
master / slave could be sufficient
Sorry, no out-of-the-box solution yet,
regards,
Marcel
------------------------------------------------------------------------
--
http://www.xmlBlaster.org
