[ClusterLabs] NFS in different subnets

Digimer lists at alteeve.ca
Fri Apr 17 15:38:01 EDT 2020


On 2020-04-17 3:20 p.m., Daniel Smith wrote:
> Thank you digimer, and I apologize for getting the wrong email.
> 
>  
> 
> Booth was the piece I was missing.  Have been researching setting that
> up and finding a third location for quorum. From what I have found, I
> believe I will need to setup single node pacemaker clusters at each

No, each sites needs to be a proper cluster (2 nodes minimum). The idea
is that, if the link to the building is lost, the cluster at the lost
site will shut down. With only one node, a hung node (that might recover
later) could recover and think it could still do things before it
realized it shouldn't. Booth is "a cluster of clusters".

The nodes at each site should be on different hardware, for the same
reason. It is very much NOT a waste of resources (and, of course, use
proper, tested STONITH/fencing).

> datacenter to use with booth. Since we have ESX clusters at each site
> which has its own redundancies built in, building redundant nodes at
> each site is pretty much a waste of resources imho. I have 2 questions
> about this setup though:
> 
> 1.       If I setup pacemaker with a single node an no virtual IP, is
> there any problems I need to be aware of?

Yes, see above.

> 2.       Is drbd the best tool for the data sync between the sites? I’ve
> looked at drbd proxy, but I get the sense that it’s not open source, or
> would rsync with incrond be a better option?

DRBD would work, but you have to make a choice; If you run synchronous
so that data is never lost (writes are confirmed when they hit both
sites), then your disk latency/bandwidth is your network
latency/bandwidth. Otherwise, you run asychronous but you'll lose any
data that didn't get transmitted before a site is lost.

As for proxy; Yes, it's a commercial add-on. If protocol A (async)
replication can't buffer the data to be transmitted (because the data is
changing faster than it can be flushed out), DRBD proxy provides a
system to have a MUCH larger send cache. It's specifically designed for
long-throw asynchronous replication.

> I already made a script that executes with the network startup that
> updates DNS using nsupdate so that should be easy to create a resource
> based on it I would think.

Yes, RAs are fairly simple to write. See:

https://github.com/ClusterLabs/OCF-spec/blob/master/ra/1.0/resource-agent-api.md

digimer


-- 
Digimer
Papers and Projects: https://alteeve.com/w/
"I am, somehow, less interested in the weight and convolutions of
Einstein’s brain than in the near certainty that people of equal talent
have lived and died in cotton fields and sweatshops." - Stephen Jay Gould


More information about the Users mailing list