Hi Dow
dow-yung yang wrote:
> Hi,
> I plan to use Shoalfor my HA(high availability) design in a project.
Very glad to know of this project. :)
We are here to help with any questions/issues/enhancements from the
Shoal perspective.
> The Active-Standby HA architecture is used for one of the servers. The
> other servers have to know which one is playing the active role. So
> the active node and the standby node will be the core members of the
> Shoal group and the other servers will be the spectators.
Let me understand this with an example. Assume A, B, C and D are nodes
in a cluster. A is an active node while B is its standby. C and D are
spectators. Would C be an active member and its D stand by, while A and
B are spectators ? Would B, or D ever an active member ?
Or would it be such that only A is an active member with B as its
standby and C and D only function as a spectator never becoming active
or standby?
What happens when B fails? Would C become a standby and by extension D
when C fails?
> I thinktheactive nodecorresponds to the master node in the Shoal
> group. So if Shoal can addthe MasterNodeChangeNotification signal, the
> servers that play the spectator role will get
> MasterNodeChangeNotification signal when the switch over occurrs
> between the active node and standby node.
We are almost there thanks to community member Bongjae Chang's efforts.
He has coded the GroupLeadershipNotificationSignal which notified
changes to group leadership. We are reviewing and it should be available
in a week or so.
> However, I found that even the server that plays the spectator role in
> a Shoal group can become the Master Node of the group in current Shoal
> implementation, which is an undesirable situation in my application.
Yes, the notion of Spectator or Core type membership is an artifact of
Shoal GMS while group leadersihp is an artifact of group communication
providers. The Shoal group comm provider based on Jxta employs the
notion of a master node, while other frameworks such as JGroups or Appia
employ coordinator or other nomenclatures for such a role.
Given our goal that membership to a Shoal group cannot be restricted to
only cluster members but also to allow non cluster members such as an
administrative or monitoring client to be observing the core cluster, we
had to employ a member type for role provisioning and the underlying
comm provider's semantics of leadership succession had to be distinct
from Shoal's notion of member types. As a result, a Shoal spectator role
member can be a group leader given that the underlying group comm
provider does not really understand member roles/types.
> Or could you give me suggestions about how the Shoal could be used for
> my HA design as described above? Thanks.
I suspect that depending on the answers to the questions above, your
architecture might have to adapt to a different approach or employ a
mechanism to dynamically or deterministically select members as standby
or spectators. For instance, a change in architecture could mean that
you employ an active-active approach, where every node is at the same
time an active capable of processing requests while also serving as a
standby for another instance. This will obviate the need to depend on a
leader algorithm and help you scale up significantly.
hth
Shreedhar
> Regards,
> Dow