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.
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. 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 <[email protected]> schrieb am 04.09.2013 um 06:16 in Nachricht <[email protected]>: > On 03/09/2013, at 9:20 PM, Moullé Alain <[email protected]> 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 [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
