Hi,
what's the advantage of Hazelcast or Zookeeper compared to a filesystem
on a NAS or SAN ?
To avoid single point of failure, you have to setup multiple Hazelcast
or Zookeeper instances. If you have only one instance, it's like having
a single filesystem.
Using a SAN or NAS (it could be simply a mdadm partition on Linux with
NFS for instance), you have the same thing as multiple
Hazelcast/Zookeeper but in a more straight forward/convenient way.
Regards
JB
On 05/05/2014 04:25 PM, Jeremy Jongsma wrote:
The easiest implementation (or the least custom code) would be to block
on a distributed lock via Hazelcast or Zookeeper, both of which have
high-availability designs that mitigate any single points of failure.
When the primary dies/disappears, the lock is automatically released,
the standby gets the lock, and it takes over as primary.
I'd also recommend not caring which is primary. Treat them as identical
instances, and let the lock decide who is primary - whoever gets in
first wins. That way you don't have to worry about maintaining multiple
application configurations.
On Sun, May 4, 2014 at 3:32 PM, Achim Nierbeck <[email protected]
<mailto:[email protected]>> wrote:
Hi,
this exact scenario you've been describing is not available
out-of-the-box.
Though I think, regarding the jdbc-lock vs. an active ping-pong via
network, there is not much of a difference, in the end you rely on
the network interface for communicating either directly or via the
data-base. I'd use a database cause this is something that could be
"clustered" also and therefore be as good as a direct ping-pong.
Another alternative would be to create this on top of cellar, where
you'd use hazelcast as your shared medium containing the information
of state.
So in the end you have to "die a certain death" :)
In different environments databases are considered to be "fail-safe"
in others not, so this solely depends on the environment you working
in.
Regarding the realization, if you really think the jdbc-lock with
the default hot-stand-by mechanism isn't enough, I'd take the
clustering of Karaf with Hazelcast (that would be Karaf-Cellar) into
account. I would use the hazelcast map as a "shared" resource
instead of a ping, this way all nodes know of each other and as soon
as one is missing on adding it's timestamp the others know of the
failed node.
regards, Achim
2014-05-04 21:35 GMT+02:00 Benjamin Debeerst <[email protected]
<mailto:[email protected]>>:
Hello Karaf Users,
I was having a look into redundant setups for a Karaf container.
What I found is this documentation [1], which describes failover
configurations with locks on a file or a database.
But doesn't a lock on a single resource introduce a new single
point of failure? Or am I missing something here?
How can I setup a full-redundant setup without that single
resource lock? Can I at all? Or will I have to roll this on my
own completely?
The setup I imagine is a master-slave setup like the following:
- two instances run on (physically) separate machines
- one is dedicated (configured as) master, the other as slave
- similar to container level locking, the slave instance is on
hot standby
- master and slave hold an active connection (heartbeat or ping
pong)
- as soon as the slave doesn't see a heartbeat from the master,
it assumes the master is dead and becomes (temporary) master
- when the (original) master shows up again, the slave goes back
to standby
What do you think about such a setup? How would you realize it
with Karaf and are there maybe already existing solutions for
such a setup? Could I maybe realize this with some kind of child
instances setup?
Thanks in advance for any comments,
Benjamin
[1]
http://karaf.apache.org/manual/latest-2.3.x/users-guide/failover.html
--
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
Committer & Project Lead
blog <http://notizblog.nierbeck.de/>
Software Architect / Project Manager / Scrum Master
--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
