<div dir="ltr"><div>Thank you for the info,<br><br></div>Do we need detailed configuring like the workload partitioning (allocation of polling resources to individual agents). Or just mention the backend_url with tooz setup? and rest of the thins taken care of automatically.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 9, 2015 at 11:52 PM, Chris Dent <span dir="ltr"><<a href="mailto:chdent@redhat.com" target="_blank">chdent@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Sat, 7 Mar 2015, Vijaya Bhaskar wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I know it is possible to have all the ceilometer services in<br>
active-active, however the ceilometer-agent-central service is run<br>
only in active-passive as far as I have researched. What are the<br>
consequences of running multiple ceilometer-agent-central<br>
services(that is in active-active). If there are serious consequences,<br>
is there any way to run it in active-active mode.<br>
</blockquote>
<br></div></div>
I'm not sure if I've quite grasped the gist of your inquiry, but:<br>
<br>
Since Juno, multiple instances of the central polling agent can be run,<br>
each polling a partition of the resources that get polled. Each<br>
agent does discovery of resource on each polling cycle and then does<br>
only some of them based on the partitioning. The partitioning is<br>
coordinated via tooz[1] though group membership. Depending on the<br>
driver used, tooz itself can be highly available.<br>
<br>
The upshot of this is that you can distribute N central agents<br>
across a bunch of machines and they will coordinate to each do a<br>
subset of resources. Each agent runs a heartbeat, if it fails to<br>
send a heartbeat, group membership will be managed, and the<br>
remaining agents will pick up the slack. When the failed agent<br>
rejoins the group, grouping will be adjusted.<br>
<br>
I've played with this a fair bit and it is quite cool.<br>
<br>
The compute-agent and impi-agent can do this too, although it makes<br>
a bit less sense.<br>
<br>
In Kilo all three agent types have been merged under an umbrella<br>
which supports namespaces: ipmi, central, compute. Each running<br>
agent can support one, some or all namespaces, each one using<br>
coordinated partitioning.<br>
<br>
I hope that's useful.<br>
<br>
[1] <a href="http://docs.openstack.org/developer/tooz/" target="_blank">http://docs.openstack.org/<u></u>developer/tooz/</a><span class="HOEnZb"><font color="#888888"><br>
-- <br>
Chris Dent tw:@anticdent freenode:cdent<br>
<a href="https://tank.peermore.com/tanks/cdent" target="_blank">https://tank.peermore.com/<u></u>tanks/cdent</a><br>
</font></span></blockquote></div><br></div>