On 07/06/2017 03:51 AM, mlb_1 wrote:
> thanks for your solution.
>
> Is anybody can officially reply this topic ?
Digimer is correct, the Red Hat and SuSE limits are their own chosen
limits for technical support, not enforced by the code. There are no
hard limits in the code, but practically
thanks for your solution.
Is anybody can officially reply this topic ?
At 2017-07-06 11:45:05, "Digimer" wrote:
>I'm not employed by Red Hat, so I can't speak authoritatively.
>
>My understanding, however, is that they do not distinguish as corosync
>on its own doesn't
I'm not employed by Red Hat, so I can't speak authoritatively.
My understanding, however, is that they do not distinguish as corosync
on its own doesn't do much. The complexity comes from corosync traffic
though, but it gets more of a concern when you add in pacemaker traffic
and/or the CIB grows
Is RedHat limit node's number, or corosync's code?
At 2017-07-06 11:11:39, "Digimer" wrote:
>On 2017-07-05 09:03 PM, mlb_1 wrote:
>> Hi:
>> I heard corosync-node's number limit to 16? It's true? And Why?
>> Thanks for anyone's answer.
>>
>>
>>
>>
On 2017-07-05 09:03 PM, mlb_1 wrote:
> Hi:
> I heard corosync-node's number limit to 16? It's true? And Why?
> Thanks for anyone's answer.
>
>
>
> https://specs.openstack.org/openstack/fuel-specs/specs/6.0/pacemaker-improvements.html
>
>
>
> * Corosync 2.0 has a lot of
Hi:
I heard corosync-node's number limit to 16? It's true? And Why?
Thanks for anyone's answer.
https://specs.openstack.org/openstack/fuel-specs/specs/6.0/pacemaker-improvements.html
Corosync 2.0 has a lot of improvements that allow to have up to 100
Controllers.