[Pacemaker] Question: How many nodes can join a cluster?

[Bernd Schubert]

On Monday, October 18, 2010, Pavlos Parissis wrote:
> On 18 October 2010 10:52, Florian Haas <florian.haas at linbit.com> wrote:
> > ----- Original Message -----
> > 
> > > From: "Andreas Vogelsang" <a.vogelsang at uni-muenster.de>
> > > To: pacemaker at oss.clusterlabs.org
> > > Sent: Monday, October 18, 2010 9:46:12 AM
> > > Subject: [Pacemaker] Question: How many nodes can join a cluster?
> > > Hello,
> > > 
> > > 
> > > 
> > > I’m creating a presentation about a virtual Linux-HA Cluster. I just
> > > asked me how many nodes pacemaker can handle. Mr. Schwartzkopff wrote
> > > in his Book that Linux-HA version 2 can handle up to 16 Nodes. Is this
> > > also true for pacemaker?
> 
> I have been asked the same question and I said to them, let's say it is
> 126, what is the use of having 126 nodes in the cluster?
> Can someone imagine himself going through the logs to find why the
> resource-XXX failed while there are 200 resources?!!
> 
> The only use of having 126 nodes is if you want to have HPC, but HPC is
> total different story than high available clusters.

No, not entirely. Pacemaker managed Lustre systems are quite common. And 
although 126 nodes is a rather high number, it is still possible for large 
sites. It also makes sense to manage Lustre in a global configuration, 
although usually for Lustre a subset of two pairs forms an OSS or MDS Lustre 
fail-over system. The reason is that Lustre requires an ordered shutdown 
sequence (MDT first). While I already wrote scripts to that with the 
traditional heartbeat pair setup, it is really far more complex than to do it 
with pacemaker.
So our scripts generate a set of constraints that only pairs can run MDS/OSS  
resources, but still everything is in global pacemaker setup.
We also have syslog-ng rules and a patched logd (patches sent to this list, 
need to update them again) to filter out all pacemaker debug logs, so that we 
can easily see messages from the lustre RA in syslogs.


Cheers,
Bernd

-- 
Bernd Schubert
DataDirect Networks