For the HA-module proposed in this chapter, we should opt for a membership service that
ensures view synchrony (Birman & Joseph, 1987; Moser et al., 1994), a service that is optimized
for a small number and pre-configured set of nodes, where partition support would
be required (at least for WAN installations), and where networks should be considered as
unreliable.
Fortunately, there are many stable implementations of such a service. The best known are
possibly JGroups (Ban, 1998), Appia (Miranda, Pinto, & Rodrigues, 2001) or Spread (Amir
& Stanton, 1998). They provide implementations of membership services altogether with
implementations of group communication systems, which will be mentioned in the next
subsection.
Inside the HA-module architecture, the group membership system interacts with the rest of
the components as shown in Figure 5. It is clearly shown that every other component receives
notifications from this service. Particularly, all of them will be interested in receiving the
view changes events as they are installed by the group membership system. This way, the
request manager, the group communication system, and the recovery manager will be able
to execute ???code??? to react on each view change so that they will be able to reconfigure their
state to reflect the new replica set, removing data related to failed nodes, and including data
to manage the newly-joined replicas.
Pages:
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565