Exactly, that's why my still most preferred solution would be to use a Database. Cause to my knowledge database systems usually are regarded to be "fail-safe" within the company setup. Besides that I fully agree with Jeremy that one shouldn't treat one node to be the primary, and go back to it when it is up and running again. I'd keep it as backup then.
regards, Achim 2014-05-05 17:09 GMT+02:00 Jean-Baptiste Onofré <[email protected]>: > 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 > -- 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
