[DRBD-user] Where to find review of DRBD vs Corosync

Bruce Wolfe, M.S.W., CIO brucew at alcoholjustice.org
Mon Aug 20 09:57:47 CEST 2012

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.

TOTALLY!!! Woo-Hoo! You're the best, Digimer. I appreciate (all of) your constant patience with us newbies. This is one of the few open source communities that is truly inviting and accepting to help promote the use of excellent product and support. 

Kudos to all!! 

Bruce M. Wolfe, M.S.W., CIO 

24 Belvedere St. 
San Rafael, CA 94901 
415/456.5692 (Main Office) 
415/257.2493 (Direct) 
415/456.0491 (Fax) 

"Most of the change we think we see in life is due to truths being in and out of favor." - Robert Frost ----- Original Message -----

| On 08/16/2012 07:38 PM, Bruce Wolfe, M.S.W., CIO wrote:

| > Thanks, Digimer, and greetings again.

| >

| > The configuration is:

| > Failover of primary to secondary.

| > Two nodes: one primary, one secondary in, as you say, a RAID 1

| > configuration.

| >

| > So, all three get used? In our current configuration, we are only
| > using

| > DRBD and Heartbeat.

| To get automatic recovery after failure, yes, you need all three.

| DRBD simply replicates raw data. That's it, nothing more. Promoting a

| secondary node to primary requires external actions, be it by the user

| or via another program.

| Heartbeat is deprecated and has no future. Anyone using it should be

| making near-term plans to get off of it. So let's take the right off
| the

| table.

| Corosync is a stand alone tool that handles cluster membership and

| message passing. It doesn't care what other programs do or how they
| use

| it's message passing capabilities. It is merely a communications tool.

| Specifically; It decided who can send and receive messages amoungst a

| group of machines. In our case, we want this so that pacemaker can

| coordinate actions.

| Pacemaker is a cluster resource manager. That is, it reacts to changes

| in cluster membership and, based on defined policies, decides to stop,

| start, migrate or otherwise act on services. It doesn't care *how*

| machines in the cluster come and go, only that they do.

| So in your use case, you would setup DRBD to replicate data. Next, you

| would configure corosync to say "these two nodes are members of
| cluster

| X". Then you tell Pacemaker; "When both nodes are available, make node

| 1's DRBD the primary and make node 2 secondary. However, if not 1
| dies,

| promote node 2 to primary. When node 1 returns, demote node 2 and

| promote noed 1."

| Make sense?

| --

| Digimer

| Papers and Projects: https://alteeve.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20120820/4b93037b/attachment.htm>

More information about the drbd-user mailing list