Hi Andrew and all!

> On 05 Jan 2015, at 22:05, Andrew Woodward <xar...@gmail.com> wrote:
> On Tue, Nov 25, 2014 at 5:21 AM, Bartosz Kupidura
> <bkupid...@mirantis.com> wrote:
>> Hello All,
>> Im working on Zabbix implementation which include HA support.
>> Zabbix server should be deployed on all controllers in HA mode.
> This needs to be discouraged as much as putting mongo-db on the controllers.

We know that, and we can use UI warning for that. For the reasons Mike provided 
our users need it. 

>> When zabbix component is enabled, we will install zabbix-server on all 
>> controllers
>> in active-backup mode (pacemaker+haproxy).
> Again, not forced on controllers, this is very bad.
> Controllers:
> While there is development use cases to deploy monitoring on combined
> controllers, and it can make use of the already existing pacemaker
> cluster, this is the wrong direction to point users. There are many
> reasons this is bad: for one, monitoring can become quite loaded, and
> as we've seen secondary load on the controllers can collapse the
> entire control plane. Secondly running monitoring on the cluster may
> also result in the monitoring going offline if the cluster does, from
> my own experience, not being able to see your monitoring is nearly
> worse than having everything down and leads to lost precious moments
> of downtime SLA.
> HA Scaling:
> Just like with controllers, our other HA components need to support a
> scale of 1 to N. This is important as a cluster will need to scale, or
> as the operator moves from POC to Production, they can deploy more
> hardware. This also helps alleviate some of the not enough nodes
> issues mentioned in the thread already

Your concenrs are 100% valid and I agree with them. But what about small 
instalaltions, where only 4 physical machines are available? We are already 
wasting one for Fuel node, and 3 for controllers. There is hardware with 
similar setup and it seems to be very popular. This is what we are trying to 

Tomasz 'Zen' Napierala
Sr. OpenStack Engineer

OpenStack-dev mailing list

Reply via email to