On 04/09/2013, at 4:26 PM, "Ulrich Windl" <ulrich.wi...@rz.uni-regensburg.de> wrote:
> Hi! > > In my experience network traffic grows somewhat linear with the size of the > CIB. At some point you probably have to change communication parameters to > keep > the cluster in a happy comminication state. Yes. Tuning corosync.conf for larger clusters is still crucial. > > Despite of the cluster internals, there may be problems if a node goes online > and hundreds of resources are started in parallel, specifically if those > resources weren't designed for it. I suspect IP addresses, MD-RAIDs, LVM > stuff, > drbd, filesystems, exportfs, etc. Thats what batch-limit is for, it slows down the flood (same 'Mb' of traffic but greater 's'). On the downside however, it slows down the flood causing recovery to take longer. > > As a note: Just recently we had a failure in MD-RAID activation with no real > reason to be found in syslog, and the cluster got quite confused. > (I had reported this to my favourite supporter (SR 10851868591), but haven't > heard anything since then...) > > Regards, > Ulrich > >>>> Andrew Beekhof <and...@beekhof.net> schrieb am 04.09.2013 um 06:16 in > Nachricht > <3ffff703-9464-458e-9024-8119c8066...@beekhof.net>: > >> On 03/09/2013, at 9:20 PM, Moullé Alain <alain.mou...@bull.net> wrote: >> >>> Hello, >>> >>> A simple question : is there a maximum number of resources (let's say > simple >> primitives) that Pacemaker can support at first at configuration of >> ressources via crm, and of course after configuration when Pacemaker has to > >> monitor all the primitives ? >> >> Simple answer: it depends >> >>> (more precisely, could we envisage around 500 or 600 primitives, or is it >> completely mad ? ;-) ) >>> >>> (I know it is dependant on node power, CPU, mem, etc., but I'm speaking >> here only of eventual Pacemaker limitations) >> >> There is no inherent limit, the policy engine can cope with many thousands. >> >> The CIB is less able to cope - for which batch-limit is useful (to throttle > >> the number of operation updates being thrown at the CIB which limits its CPU > >> usage). >> The other limit is local and cluster messaging sizes - once the compressed >> cib gets too big for either or both transports you can no longer even run >> 'cibadmin -Q' >> >> For IPC, the limit is tuneable via the environment. >> For corosync, its high (1Mb) but (I think) only tuneable at compile time. > > > _______________________________________________ > Linux-HA mailing list > Linux-HA@lists.linux-ha.org > http://lists.linux-ha.org/mailman/listinfo/linux-ha > See also: http://linux-ha.org/ReportingProblems
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Linux-HA mailing list Linux-HA@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
