[xmlblaster] RE: [xmlblaster] Mirrored Masters?

2009-12-08 Thread Craig McIlwee
Thanks Marcel.  What we are looking for is nowhere near as elegant of a 
solution as you've outlined below.  Quoting the same page as David, we are most 
interested in

Messages which are published are sent to all masters.

Because we really just want a second master node that stays in sync with the 
primary master.   In our scenario we don't need any type of smart failover or 
load balancing, we want to make sure that 2 nodes are receiving and persisting 
the same information.  In normal usage, the primary node will always receive 
messages.  In a catastrophic situation where the primary node fails (hardware 
error, etc) we need to be able to switch to the secondary node that should be 
in sync with the primary, and manual reconfiguration is acceptable.

So from your mail below, I take it that persisting at 2 nodes is not 
implemented yet?  If not, it sounds like you recommend mirroring at the 
database level?

Thanks,
Craig

-Original Message-
From: owner-xmlblas...@server.xmlblaster.org 
[mailto:owner-xmlblas...@server.xmlblaster.org] On Behalf Of Marcel Ruff
Sent: Tuesday, December 08, 2009 4:41 AM
To: xmlblaster@server.xmlBlaster.org
Subject: Re: [xmlblaster] Mirrored Masters?

Hi David,

multi master is not implemented.

The I_LoadBalancer#getClusterNode() returns one node (NodeMasterInfo) which
is used to forward messages to the next node, but only to one.

If you need mirroring you could, depending if you need failover or
load balancing,
consider following:

1) Change the xmlBlaster cluster code to handle multiple masters
You need to decide in this case if the multiple masters are informed
in a transaction (sync) or not (async). Clients need to be coded
to choose a master depending on current load or failure.
- failover and load balancing

2) You could create an extended I_Queue and I_Map plugin which
duplicates the data to two DBs
- failover

3) You could do low-level DB mirroring (DRDB, Linux HA et al)
xmlBlaster gets on startup all information to re-establish its state.
In this case the mirrored xmlBlaster is started on failure of the first,
clients automatically find the mirrored as the IP is change (standard HA
behaviour)
- failover

4) Master/Slave operation (exists already, one master with many salves)
- load balancing

5) Combination of 3) and 4) should work out of the box
- failover and load balancing


It depends on what you want to achieve,

best regards
Michele
Marcel


David R Robison schrieb:
 In the discussion on clustering in the reference manual it talks about
 mirrored masters:

 /An xmlBlaster cluster allows to have more than one master server
 for a specific message domain. The master nodes are //mirrored
 instances for those messages. Published messages reach all master
 nodes. Subscribed messages are retrieved using a load balance
 algorithm.
 /


 However, the discussion says that it has not been implemented. Has any
 work been done on this? Any suggestions on how to achieve this?
 Thanks, David
 --

 David R Robison
 Open Roads Consulting, Inc.
 103 Watson Road, Chesapeake, VA 23320
 phone: (757) 546-3401
 e-mail: drrobi...@openroadsconsulting.com
 web: http://openroadsconsulting.com
 blog: http://therobe.blogspot.com
 book: http://www.xulonpress.com/bookstore/bookdetail.php?PB_ISBN=9781597816526

 This e-mail communication (including any attachments) may contain 
 confidential and/or privileged material intended solely for the individual or 
 entity to which it is addressed.  If you are not the intended recipient, you 
 should immediately stop reading this message and delete it from all computers 
 that it resides on. Any unauthorized reading, distribution, copying or other 
 use of this communication (or its attachments) is strictly prohibited.  If 
 you have received this communication in error, please notify us immediately.



--
Marcel Ruff
http://www.xmlBlaster.org
http://watchee.net
Phone: +49 7551 309371





Re: [xmlblaster] RE: [xmlblaster] Mirrored Masters?

2009-12-08 Thread Marcel Ruff

Craig McIlwee schrieb:

Thanks Marcel.  What we are looking for is nowhere near as elegant of a 
solution as you've outlined below.  Quoting the same page as David, we are most 
interested in

Messages which are published are sent to all masters.

Because we really just want a second master node that stays in sync with the 
primary master.   In our scenario we don't need any type of smart failover or 
load balancing, we want to make sure that 2 nodes are receiving and persisting 
the same information.  In normal usage, the primary node will always receive 
messages.  In a catastrophic situation where the primary node fails (hardware 
error, etc) we need to be able to switch to the secondary node that should be 
in sync with the primary, and manual reconfiguration is acceptable.

So from your mail below, I take it that persisting at 2 nodes is not 
implemented yet?

No this is not implemented.

  If not, it sounds like you recommend mirroring at the database level?
  
Yes. And I would recommend to go from the beginning the Linux HA 
(bonding,DRDB,Heartbeat etc, HP-ServiceGuard ...) way,
as all the failover problems will arise over time anyhow, so I suggest 
doing it right from beginning.


regards
Marcel

Thanks,
Craig

-Original Message-
From: owner-xmlblas...@server.xmlblaster.org 
[mailto:owner-xmlblas...@server.xmlblaster.org] On Behalf Of Marcel Ruff
Sent: Tuesday, December 08, 2009 4:41 AM
To: xmlblaster@server.xmlBlaster.org
Subject: Re: [xmlblaster] Mirrored Masters?

Hi David,

multi master is not implemented.

The I_LoadBalancer#getClusterNode() returns one node (NodeMasterInfo) which
is used to forward messages to the next node, but only to one.

If you need mirroring you could, depending if you need failover or 
load balancing,

consider following:

1) Change the xmlBlaster cluster code to handle multiple masters
You need to decide in this case if the multiple masters are informed
in a transaction (sync) or not (async). Clients need to be coded
to choose a master depending on current load or failure.
- failover and load balancing

2) You could create an extended I_Queue and I_Map plugin which
duplicates the data to two DBs
- failover

3) You could do low-level DB mirroring (DRDB, Linux HA et al)
xmlBlaster gets on startup all information to re-establish its state.
In this case the mirrored xmlBlaster is started on failure of the first,
clients automatically find the mirrored as the IP is change (standard HA 
behaviour)

- failover

4) Master/Slave operation (exists already, one master with many salves)
- load balancing

5) Combination of 3) and 4) should work out of the box
- failover and load balancing


It depends on what you want to achieve,

best regards
Michele
Marcel


David R Robison schrieb:
  
In the discussion on clustering in the reference manual it talks about 
mirrored masters:


/An xmlBlaster cluster allows to have more than one master server
for a specific message domain. The master nodes are //mirrored
instances for those messages. Published messages reach all master
nodes. Subscribed messages are retrieved using a load balance
algorithm.
/


However, the discussion says that it has not been implemented. Has any 
work been done on this? Any suggestions on how to achieve this?

Thanks, David


--
Marcel Ruff
http://www.xmlBlaster.org
http://gpsvision.biz




RE: [xmlblaster] RE: [xmlblaster] RE: [xmlblaster] Mirrored Masters?

2009-12-08 Thread Sanjeev Dhiman
Yes Craig, that is exactly what I meant, i.e. a plugin that would subscribe to 
the primary and publish to secondary.


-Original Message-
From: owner-xmlblas...@server.xmlblaster.org on behalf of Craig McIlwee
Sent: Tue 12/8/2009 10:13 PM
To: xmlblaster@server.xmlBlaster.org
Subject: [xmlblaster] RE: [xmlblaster] RE: [xmlblaster] Mirrored Masters?
 
We have considered this approach also, but not as master/slave because the 
slaves don't persist topics/messages, only masters do this.  In this case we 
would have 2 masters for a domain but they won't be configured with any 
knowledge of each other, i.e. no cluster setup.  In the primary master we would 
have a plugin that does have hostname, port, etc information about secondary 
master.  The plugin will subscribe to the primary master and publish to the 
secondary master.  I haven't fleshed out all of the details of this approach 
yet, but it seems like it would work.

The Linux HA suggested by Marcel is unfortunately out of the question in our 
scenario.  We have an existing Windows environment that we won't be able to 
rebuild on linux, we also have no experience with Linux HA.  If we do go the DB 
replication route I imagine we will try to take advantage of PostgresSQL's 
Slony-I features.

Craig

-Original Message-
From: Sanjeev Dhiman [mailto:sanje...@brickred.com] 
Sent: Tuesday, December 08, 2009 11:17 AM
To: xmlblaster@server.xmlBlaster.org
Cc: craig.mcil...@openroadsconsulting.com
Subject: RE: [xmlblaster] RE: [xmlblaster] Mirrored Masters?

Hi Craig,

If that is the case, does it make sense for you to implement a master
slave configuration since you just need the secondary to be in sync with
the primary? If yes, you could just make a subscriber that subscribes to
the primary node and continues to publish to the secondary.

Thanks,
Sanjeev

-Original Message-
From: owner-xmlblas...@server.xmlblaster.org
[mailto:owner-xmlblas...@server.xmlblaster.org] On Behalf Of Marcel Ruff
Sent: Tuesday, December 08, 2009 9:39 PM
To: xmlblaster@server.xmlBlaster.org
Cc: craig.mcil...@openroadsconsulting.com
Subject: Re: [xmlblaster] RE: [xmlblaster] Mirrored Masters?

Craig McIlwee schrieb:
 Thanks Marcel.  What we are looking for is nowhere near as elegant of
a solution as you've outlined below.  Quoting the same page as David, we
are most interested in

 Messages which are published are sent to all masters.

 Because we really just want a second master node that stays in sync
with the primary master.   In our scenario we don't need any type of
smart failover or load balancing, we want to make sure that 2 nodes are
receiving and persisting the same information.  In normal usage, the
primary node will always receive messages.  In a catastrophic situation
where the primary node fails (hardware error, etc) we need to be able to
switch to the secondary node that should be in sync with the primary,
and manual reconfiguration is acceptable.

 So from your mail below, I take it that persisting at 2 nodes is not
implemented yet?
No this is not implemented.
   If not, it sounds like you recommend mirroring at the database
level?
   
Yes. And I would recommend to go from the beginning the Linux HA 
(bonding,DRDB,Heartbeat etc, HP-ServiceGuard ...) way,
as all the failover problems will arise over time anyhow, so I suggest 
doing it right from beginning.

regards
Marcel
 Thanks,
 Craig

 -Original Message-
 From: owner-xmlblas...@server.xmlblaster.org
[mailto:owner-xmlblas...@server.xmlblaster.org] On Behalf Of Marcel Ruff
 Sent: Tuesday, December 08, 2009 4:41 AM
 To: xmlblaster@server.xmlBlaster.org
 Subject: Re: [xmlblaster] Mirrored Masters?

 Hi David,

 multi master is not implemented.

 The I_LoadBalancer#getClusterNode() returns one node (NodeMasterInfo)
which
 is used to forward messages to the next node, but only to one.

 If you need mirroring you could, depending if you need failover or 
 load balancing,
 consider following:

 1) Change the xmlBlaster cluster code to handle multiple masters
 You need to decide in this case if the multiple masters are informed
 in a transaction (sync) or not (async). Clients need to be coded
 to choose a master depending on current load or failure.
 - failover and load balancing

 2) You could create an extended I_Queue and I_Map plugin which
 duplicates the data to two DBs
 - failover

 3) You could do low-level DB mirroring (DRDB, Linux HA et al)
 xmlBlaster gets on startup all information to re-establish its state.
 In this case the mirrored xmlBlaster is started on failure of the
first,
 clients automatically find the mirrored as the IP is change (standard
HA 
 behaviour)
 - failover

 4) Master/Slave operation (exists already, one master with many
salves)
 - load balancing

 5) Combination of 3) and 4) should work out of the box
 - failover and load balancing


 It depends on what you want to achieve,

 best regards
 Michele
 Marcel


 David R Robison schrieb:
   
 In the discussion