settingsLogin | Registersettings

[Openstack] Ceilometer high availability in active-active

0 votes

Hi Guys,

I know it is possible to have all the ceilometer services in
active-active, however the ceilometer-agent-central service is run
only in active-passive as far as I have researched. What are the
consequences of running multiple ceilometer-agent-central
services(that is in active-active). If there are serious consequences,
is there any way to run it in active-active mode.

Please help.


Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
asked Mar 7, 2015 in openstack by Vijaya_Bhaskar (680 points)   1 2 3
retagged Apr 14, 2015 by admin

13 Responses

0 votes

On Sat, 7 Mar 2015, Vijaya Bhaskar wrote:

I know it is possible to have all the ceilometer services in
active-active, however the ceilometer-agent-central service is run
only in active-passive as far as I have researched. What are the
consequences of running multiple ceilometer-agent-central
services(that is in active-active). If there are serious consequences,
is there any way to run it in active-active mode.

I'm not sure if I've quite grasped the gist of your inquiry, but:

Since Juno, multiple instances of the central polling agent can be run,
each polling a partition of the resources that get polled. Each
agent does discovery of resource on each polling cycle and then does
only some of them based on the partitioning. The partitioning is
coordinated via tooz[1] though group membership. Depending on the
driver used, tooz itself can be highly available.

The upshot of this is that you can distribute N central agents
across a bunch of machines and they will coordinate to each do a
subset of resources. Each agent runs a heartbeat, if it fails to
send a heartbeat, group membership will be managed, and the
remaining agents will pick up the slack. When the failed agent
rejoins the group, grouping will be adjusted.

I've played with this a fair bit and it is quite cool.

The compute-agent and impi-agent can do this too, although it makes
a bit less sense.

In Kilo all three agent types have been merged under an umbrella
which supports namespaces: ipmi, central, compute. Each running
agent can support one, some or all namespaces, each one using
coordinated partitioning.

I hope that's useful.

[1] http://docs.openstack.org/developer/tooz/
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent

responded Mar 9, 2015 by Chris_Dent (7,940 points)   1 4 6
0 votes

Thank you for the info,

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.

On Mon, Mar 9, 2015 at 11:52 PM, Chris Dent chdent@redhat.com wrote:

On Sat, 7 Mar 2015, Vijaya Bhaskar wrote:

I know it is possible to have all the ceilometer services in

active-active, however the ceilometer-agent-central service is run
only in active-passive as far as I have researched. What are the
consequences of running multiple ceilometer-agent-central
services(that is in active-active). If there are serious consequences,
is there any way to run it in active-active mode.

I'm not sure if I've quite grasped the gist of your inquiry, but:

Since Juno, multiple instances of the central polling agent can be run,
each polling a partition of the resources that get polled. Each
agent does discovery of resource on each polling cycle and then does
only some of them based on the partitioning. The partitioning is
coordinated via tooz[1] though group membership. Depending on the
driver used, tooz itself can be highly available.

The upshot of this is that you can distribute N central agents
across a bunch of machines and they will coordinate to each do a
subset of resources. Each agent runs a heartbeat, if it fails to
send a heartbeat, group membership will be managed, and the
remaining agents will pick up the slack. When the failed agent
rejoins the group, grouping will be adjusted.

I've played with this a fair bit and it is quite cool.

The compute-agent and impi-agent can do this too, although it makes
a bit less sense.

In Kilo all three agent types have been merged under an umbrella
which supports namespaces: ipmi, central, compute. Each running
agent can support one, some or all namespaces, each one using
coordinated partitioning.

I hope that's useful.

[1] http://docs.openstack.org/developer/tooz/
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent


Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
responded Mar 10, 2015 by Vijaya_Bhaskar (680 points)   1 2 3
0 votes

On Tue, 10 Mar 2015, Vijaya Bhaskar wrote:

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.

The partitioning is automatic. Setting backend_url in configuration
will "turn on" the feature. The backend will need to be set up, but
for many of them it's just a matter of turning the service (redis,
memcached, whatever) on and making it reachable.

--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent


Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
responded Mar 10, 2015 by Chris_Dent (7,940 points)   1 4 6
0 votes

Thank you , that is all I need.

On Tue, Mar 10, 2015 at 4:44 PM, Chris Dent chdent@redhat.com wrote:

On Tue, 10 Mar 2015, Vijaya Bhaskar wrote:

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.

The partitioning is automatic. Setting backend_url in configuration
will "turn on" the feature. The backend will need to be set up, but
for many of them it's just a matter of turning the service (redis,
memcached, whatever) on and making it reachable.

--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent


Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
responded Mar 11, 2015 by Vijaya_Bhaskar (680 points)   1 2 3
0 votes

We kown that:
backendurl',
default=None,
help='The backend URL to use for distributed coordination. If '
'left empty, per-deployment central agent and per-host '
'compute agent won\'t do workload '
'partitioning and will only function correctly if a '
'single instance of that service is running.'),
But how to set the ‘backend
url’?

Thank you!

发件人: Vijaya Bhaskar [mailto:vijayabhaskar@sparksupport.com]
发送时间: 2015年3月11日 12:32
收件人: Chris Dent
抄送: openstack
主题: Re: [Openstack] Ceilometer high availability in active-active

Thank you , that is all I need.

On Tue, Mar 10, 2015 at 4:44 PM, Chris Dent chdent@redhat.com wrote:
On Tue, 10 Mar 2015, Vijaya Bhaskar wrote:
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.

The partitioning is automatic. Setting backend_url in configuration
will "turn on" the feature. The backend will need to be set up, but
for many of them it's just a matter of turning the service (redis,
memcached, whatever) on and making it reachable.

--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent


Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
responded Mar 11, 2015 by Pan,_Fengyun (380 points)   1 2

we know ceilometer use tooz to implement ha, so we can found the answer in tooz

  • First, tooz will parse the backendurl by netutils.urlsplit:
    > parsedurl = netutils.urlsplit(backendurl)

  • Then, backend driver will be found by the url scheme, for example in my situation, memcached
    driver.DriverManager( namespace=TOOZ_BACKENDS_NAMESPACE, name=parsed_url.scheme, invoke_on_load=True, invoke_args=(member_id, parsed_url, options)).driver

  • Finally , the MemcachedDriver will be initialed as below
    def __init__(self, member_id, parsed_url, options): super(MemcachedDriver, self).__init__() options = utils.collapse(options) self._options = options self._member_id = member_id self._joined_groups = set() self._executor = utils.ProxyExecutor.build("Memcached", options) self.host = (parsed_url.hostname or "localhost", parsed_url.port or 11211) default_timeout = options.get('timeout', self.DEFAULT_TIMEOUT) self.timeout = int(default_timeout) self.membership_timeout = int(options.get( 'membership_timeout', default_timeout)) self.lock_timeout = int(options.get( 'lock_timeout', default_timeout)) self.leader_timeout = int(options.get( 'leader_timeout', default_timeout)) max_pool_size = options.get('max_pool_size', None) if max_pool_size is not None: self.max_pool_size = int(max_pool_size) else: self.max_pool_size = None self._acquired_locks = []

So, I set the backendurl as "memcached://127.0.0.1:11211"
You can find your answer here: tooz backend driver code

Hope this will help you!

0 votes

On Wed, 11 Mar 2015, Pan, Fengyun wrote:

We kown that:
backendurl',
default=None,
help='The backend URL to use for distributed coordination. If '
'left empty, per-deployment central agent and per-host '
'compute agent won\'t do workload '
'partitioning and will only function correctly if a '
'single instance of that service is running.'),
But how to set the ‘backend
url’?

This appears to be an oversight in the documentation. The main
starting point is here:

http://docs.openstack.org/admin-guide-cloud/content/section_telemetry-cetral-compute-agent-ha.html

but nothing there nor what it links to actually says what should go as
the value of the setting. It's entirely dependent on the backend being
used and how that backend is being configured. Each of the tooz
drivers has some information on some of the options, but again, it is
not fully documented yet.

For reference, what I use in my own testing is redis as follows:

redis://localhost:6379

This uses a single redis server, so introduces another single point of
failure. It's possible to use sentinel to improve upon this situation:

http://docs.openstack.org/developer/tooz/developers.html#redis

The other drivers work in similar ways with their own unique
arguments.

I'm sorry I'm not able to point to more complete information but I can
say that it is in the process of being improved.

--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent_______________________________________________
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

responded Mar 11, 2015 by Chris_Dent (7,940 points)   1 4 6
0 votes

Thank you very much.

When I use "redis://localhost:6379", find other problem as follow:

2015-03-12 18:19:19.513 20863 INFO ceilometer.coordination [-] backendurl:redis://localhost:6379
2015-03-12 18:19:19.513 20863 INFO tooz.coordination [-] backend
url:redis://localhost:6379
2015-03-12 18:19:19.513 20863 INFO tooz.coordination [-] parsedurl:SplitResult(scheme='redis', netloc='localhost:6379', path='', query='', fragment='')***parsedqs:{}
2015-03-12 18:19:19.515 20863 ERROR ceilometer.openstack.common.threadgroup [-] No module named concurrent
2015-03-12 18:19:19.515 20863 TRACE ceilometer.openstack.common.threadgroup Traceback (most recent call last):
2015-03-12 18:19:19.515 20863 TRACE ceilometer.openstack.common.threadgroup File "/usr/lib/python2.7/site-packages/ceilometer/openstack/common/threadgroup.py", line 143, in wait
2015-03-12 18:19:19.515 20863 TRACE ceilometer.openstack.common.threadgroup x.wait()
2015-03-12 18:19:19.515 20863 TRACE ceilometer.openstack.common.threadgroup File "/usr/lib/python2.7/site-packages/ceilometer/openstack/common/threadgroup.py", line 47, in wait
2015-03-12 18:19:19.515 20863 TRACE ceilometer.openstack.common.threadgroup return self.thread.wait()
2015-03-12 18:19:19.515 20863 TRACE ceilometer.openstack.common.threadgroup File "/usr/lib/python2.7/site-packages/eventlet/greenthread.py", line 173, in wait
2015-03-12 18:19:19.515 20863 TRACE ceilometer.openstack.common.threadgroup return self.exitevent.wait()
2015-03-12 18:19:19.515 20863 TRACE ceilometer.openstack.common.threadgroup File "/usr/lib/python2.7/site-packages/eventlet/event.py", line 121, in wait
2015-03-12 18:19:19.515 20863 TRACE ceilometer.openstack.common.threadgroup return hubs.get_hub().switch()
2015-03-12 18:19:19.515 20863 TRACE ceilometer.openstack.common.threadgroup File "/usr/lib/python2.7/site-packages/eventlet/hubs/hub.py", line 293, in switch
2015-03-12 18:19:19.515 20863 TRACE ceilometer.openstack.common.threadgroup return self.greenlet.switch()
2015-03-12 18:19:19.515 20863 TRACE ceilometer.openstack.common.threadgroup File "/usr/lib/python2.7/site-packages/eventlet/greenthread.py", line 212, in main
2015-03-12 18:19:19.515 20863 TRACE ceilometer.openstack.common.threadgroup result = function(*args, **kwargs)
2015-03-12 18:19:19.515 20863 TRACE ceilometer.openstack.common.threadgroup File "/usr/lib/python2.7/site-packages/ceilometer/openstack/common/service.py", line 500, in run_service
2015-03-12 18:19:19.515 20863 TRACE ceilometer.openstack.common.threadgroup service.start()
2015-03-12 18:19:19.515 20863 TRACE ceilometer.openstack.common.threadgroup File "/usr/lib/python2.7/site-packages/ceilometer/agent.py", line 195, in start
2015-03-12 18:19:19.515 20863 TRACE ceilometer.openstack.common.threadgroup self.partition_coordinator.start()
2015-03-12 18:19:19.515 20863 TRACE ceilometer.openstack.common.threadgroup File "/usr/lib/python2.7/site-packages/ceilometer/coordination.py", line 71, in start
2015-03-12 18:19:19.515 20863 TRACE ceilometer.openstack.common.threadgroup backend_url, self._my_id)
2015-03-12 18:19:19.515 20863 TRACE ceilometer.openstack.common.threadgroup File "/usr/lib/python2.7/site-packages/tooz/coordination.py", line 365, in get_coordinator
2015-03-12 18:19:19.515 20863 TRACE ceilometer.openstack.common.threadgroup invoke_args=(member_id, parsed_url, parsed_qs)).driver
2015-03-12 18:19:19.515 20863 TRACE ceilometer.openstack.common.threadgroup File "/usr/lib/python2.7/site-packages/stevedore/driver.py", line 45, in __init__
2015-03-12 18:19:19.515 20863 TRACE ceilometer.openstack.common.threadgroup verify_requirements=verify_requirements,
2015-03-12 18:19:19.515 20863 TRACE ceilometer.openstack.common.threadgroup File "/usr/lib/python2.7/site-packages/stevedore/named.py", line 55, in __init__
2015-03-12 18:19:19.515 20863 TRACE ceilometer.openstack.common.threadgroup verify_requirements)
2015-03-12 18:19:19.515 20863 TRACE ceilometer.openstack.common.threadgroup File "/usr/lib/python2.7/site-packages/stevedore/extension.py", line 170, in _load_plugins
2015-03-12 18:19:19.515 20863 TRACE ceilometer.openstack.common.threadgroup self._on_load_failure_callback(self, ep, err)
2015-03-12 18:19:19.515 20863 TRACE ceilometer.openstack.common.threadgroup File "/usr/lib/python2.7/site-packages/stevedore/driver.py", line 50, in _default_on_load_failure
2015-03-12 18:19:19.515 20863 TRACE ceilometer.openstack.common.threadgroup raise err
2015-03-12 18:19:19.515 20863 TRACE ceilometer.openstack.common.threadgroup ImportError: No module named concurrent
2015-03-12 18:19:19.515 20863 TRACE ceilometer.openstack.common.threadgroup


-----邮件原件-----
发件人: Chris Dent [mailto:chdent@redhat.com]
发送时间: 2015年3月11日 21:08
收件人: Pan, Fengyun/潘 风云
抄送: Vijaya Bhaskar; openstack
主题: Re: 答复: [Openstack] Ceilometer high availability in active-active

On Wed, 11 Mar 2015, Pan, Fengyun wrote:

We kown that:
backendurl',
default=None,
help='The backend URL to use for distributed coordination. If '
'left empty, per-deployment central agent and per-host '
'compute agent won\'t do workload '
'partitioning and will only function correctly if a '
'single instance of that service is running.'), But
how to set the ‘backend
url’?

This appears to be an oversight in the documentation. The main starting point is here:

http://docs.openstack.org/admin-guide-cloud/content/section_telemetry-cetral-compute-agent-ha.html

but nothing there nor what it links to actually says what should go as the value of the setting. It's entirely dependent on the backend being used and how that backend is being configured. Each of the tooz drivers has some information on some of the options, but again, it is not fully documented yet.

For reference, what I use in my own testing is redis as follows:

redis://localhost:6379

This uses a single redis server, so introduces another single point of failure. It's possible to use sentinel to improve upon this situation:

http://docs.openstack.org/developer/tooz/developers.html#redis

The other drivers work in similar ways with their own unique arguments.

I'm sorry I'm not able to point to more complete information but I can say that it is in the process of being improved.

--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent


Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
responded Mar 12, 2015 by Pan,_Fengyun (380 points)   1 2
0 votes

On Thu, 12 Mar 2015, Pan, Fengyun wrote:

When I use "redis://localhost:6379", find other problem as follow:

2015-03-12 18:19:19.515 20863 TRACE ceilometer.openstack.common.threadgroup ImportError: No module named concurrent

Make sure you have installed the latest versions of tooz, the redis
python client, and other relevant python packages.

If it still doesn't work after that you'll need to share more
information about how you are doing your install and your setup.

--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent


Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
responded Mar 12, 2015 by Chris_Dent (7,940 points)   1 4 6
0 votes

Thank you !

I have set the backendurl of compute node and controller node as follows:
backend
url=redis://193.168.196.246:6379
the ip of my compute node is "193.168.196.246".
And compute node have installed redis.
# rpm -qa | grep redis
redis-2.8.15-2.el7ost.x8664
python-redis-2.10.3-1.el7ost.noarch
so running ceilometer-agent-central service on compute node , it can connect to redis service successfully.
But when running ceilometer-agent-central service on controller onde, we will get the log as follows:
2015-03-18 18:48:05.948 16236 ERROR ceilometer.coordination [-] Error connecting to coordination backend.
2015-03-18 18:48:05.948 16236 TRACE ceilometer.coordination Traceback (most recent call last):
2015-03-18 18:48:05.948 16236 TRACE ceilometer.coordination File "/usr/lib/python2.7/site-packages/ceilometer/coordination.py", line 70, in start
2015-03-18 18:48:05.948 16236 TRACE ceilometer.coordination self.
coordinator.start()
2015-03-18 18:48:05.948 16236 TRACE ceilometer.coordination File "/usr/lib/python2.7/site-packages/tooz/coordination.py", line 182, in start
2015-03-18 18:48:05.948 16236 TRACE ceilometer.coordination self.start()
2015-03-18 18:48:05.948 16236 TRACE ceilometer.coordination File "/usr/lib/python2.7/site-packages/tooz/drivers/redis.py", line 354, in _start
2015-03-18 18:48:05.948 16236 TRACE ceilometer.coordination self.
serverinfo = self.client.info()
2015-03-18 18:48:05.948 16236 TRACE ceilometer.coordination File "/usr/lib64/python2.7/contextlib.py", line 35, in exit
2015-03-18 18:48:05.948 16236 TRACE ceilometer.coordination self.gen.throw(type, value, traceback)
2015-03-18 18:48:05.948 16236 TRACE ceilometer.coordination File "/usr/lib/python2.7/site-packages/tooz/drivers/redis.py", line 78, in translatefailures
2015-03-18 18:48:05.948 16236 TRACE ceilometer.coordination raise coordination.ToozConnectionError(utils.exceptionmessage(e))
2015-03-18 18:48:05.948 16236 TRACE ceilometer.coordination ToozConnectionError: Error 113 connecting to 193.168.196.246:6379. EHOSTUNREACH.
2015-03-18 18:48:05.948 16236 TRACE ceilometer.coordination
2015-03-18 18:48:36.953 16236 ERROR ceilometer.coordination [-] Error sending a heartbeat to coordination backend.
2015-03-18 18:48:36.953 16236 TRACE ceilometer.coordination Traceback (most recent call last):
2015-03-18 18:48:36.953 16236 TRACE ceilometer.coordination File "/usr/lib/python2.7/site-packages/ceilometer/coordination.py", line 86, in heartbeat
2015-03-18 18:48:36.953 16236 TRACE ceilometer.coordination self.
coordinator.heartbeat()
2015-03-18 18:48:36.953 16236 TRACE ceilometer.coordination File "/usr/lib/python2.7/site-packages/tooz/drivers/redis.py", line 408, in heartbeat
2015-03-18 18:48:36.953 16236 TRACE ceilometer.coordination value=b"Not dead!")
2015-03-18 18:48:36.953 16236 TRACE ceilometer.coordination File "/usr/lib64/python2.7/contextlib.py", line 35, in exit
2015-03-18 18:48:36.953 16236 TRACE ceilometer.coordination self.gen.throw(type, value, traceback)
2015-03-18 18:48:36.953 16236 TRACE ceilometer.coordination File "/usr/lib/python2.7/site-packages/tooz/drivers/redis.py", line 78, in translatefailures
2015-03-18 18:48:36.953 16236 TRACE ceilometer.coordination raise coordination.ToozConnectionError(utils.exception_message(e))
2015-03-18 18:48:36.953 16236 TRACE ceilometer.coordination ToozConnectionError: Error connecting to 193.168.196.246:6379. timed out.
2015-03-18 18:48:36.953 16236 TRACE ceilometer.coordination


Why is it timed out ?
Is there some trouble in my configuration?

-----邮件原件-----
发件人: Chris Dent [mailto:chdent@redhat.com]
发送时间: 2015年3月11日 21:08
收件人: Pan, Fengyun/潘 风云
抄送: Vijaya Bhaskar; openstack
主题: Re: 答复: [Openstack] Ceilometer high availability in active-active

On Wed, 11 Mar 2015, Pan, Fengyun wrote:

We kown that:
backendurl',
default=None,
help='The backend URL to use for distributed coordination. If '
'left empty, per-deployment central agent and per-host '
'compute agent won\'t do workload '
'partitioning and will only function correctly if a '
'single instance of that service is running.'), But
how to set the ‘backend
url’?

This appears to be an oversight in the documentation. The main starting point is here:

http://docs.openstack.org/admin-guide-cloud/content/section_telemetry-cetral-compute-agent-ha.html

but nothing there nor what it links to actually says what should go as the value of the setting. It's entirely dependent on the backend being used and how that backend is being configured. Each of the tooz drivers has some information on some of the options, but again, it is not fully documented yet.

For reference, what I use in my own testing is redis as follows:

redis://localhost:6379

This uses a single redis server, so introduces another single point of failure. It's possible to use sentinel to improve upon this situation:

http://docs.openstack.org/developer/tooz/developers.html#redis

The other drivers work in similar ways with their own unique arguments.

I'm sorry I'm not able to point to more complete information but I can say that it is in the process of being improved.

--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent


Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
responded Mar 18, 2015 by Pan,_Fengyun (380 points)   1 2
0 votes

I have some questions at the html which as follows:
http://docs.openstack.org/admin-guide-cloud/content/section_telemetry-cetral-compute-agent-ha.html
At this html, is "Without the backend_url option being set only one instance of both the central and compute agent service is able to run and function correctly." right?

There are two node at my openstack environment:
Compute node: installed ceilometer-agent-compute and ceilometer-agent-central
Controller node: installed ceilometer-agent-compute 、ceilometer-agent-central and other services.
Without the backendurl option being set, running ceilometer-agent-central at compute node and controller node, they can work correctly.
[root@controller ceilometer(keystone
admin)]# ceilometer sample-list -m storage.containers.objects | head -19
+------------------------------------------------+----------------------------+-------+--------+--------+---------------------+
| Resource ID | Name | Type | Volume | Unit | Timestamp |
+------------------------------------------------+----------------------------+-------+--------+--------+---------------------+
| ba28a506cfd344c383fcbc3540559222/jick | storage.containers.objects | gauge | 0.0 | object | 2015-03-18T14:56:34 |
| ba28a506cfd344c383fcbc3540559222/wx | storage.containers.objects | gauge | 1.0 | object | 2015-03-18T14:56:34 |
| ba28a506cfd344c383fcbc3540559222/volumebackups | storage.containers.objects | gauge | 0.0 | object | 2015-03-18T14:56:34 |
| cd84533ff083463ab18b1dc15236732b/glance | storage.containers.objects | gauge | 0.0 | object | 2015-03-18T14:56:34 |
| ba28a506cfd344c383fcbc3540559222/jick | storage.containers.objects | gauge | 0.0 | object | 2015-03-18T14:56:31 |
| ba28a506cfd344c383fcbc3540559222/wx | storage.containers.objects | gauge | 1.0 | object | 2015-03-18T14:56:31 |
| ba28a506cfd344c383fcbc3540559222/volumebackups | storage.containers.objects | gauge | 0.0 | object | 2015-03-18T14:56:31 |
| cd84533ff083463ab18b1dc15236732b/glance | storage.containers.objects | gauge | 0.0 | object | 2015-03-18T14:56:31 |
| ba28a506cfd344c383fcbc3540559222/jick | storage.containers.objects | gauge | 0.0 | object | 2015-03-18T14:46:41 |
| cd84533ff083463ab18b1dc15236732b/glance | storage.containers.objects | gauge | 0.0 | object | 2015-03-18T14:46:41 |
| ba28a506cfd344c383fcbc3540559222/wx | storage.containers.objects | gauge | 1.0 | object | 2015-03-18T14:46:41 |
| ba28a506cfd344c383fcbc3540559222/volumebackups | storage.containers.objects | gauge | 0.0 | object | 2015-03-18T14:46:41 |
| cd84533ff083463ab18b1dc15236732b/glance | storage.containers.objects | gauge | 0.0 | object | 2015-03-18T14:46:32 |
| ba28a506cfd344c383fcbc3540559222/wx | storage.containers.objects | gauge | 1.0 | object | 2015-03-18T14:46:32 |
| ba28a506cfd344c383fcbc3540559222/volumebackups | storage.containers.objects | gauge | 0.0 | object | 2015-03-18T14:46:32 |
| ba28a506cfd344c383fcbc3540559222/jick | storage.containers.objects | gauge | 0.0 | object | 2015-03-18T14:46:32 |


There are 4 storage.containers.objects, the ceilometer-agent-central of compute node can get 4 samples,the ceilomter-agent-central of controller node can get 4 samples too.
Is it right?

-----邮件原件-----
发件人: Chris Dent [mailto:chdent@redhat.com]
发送时间: 2015年3月11日 21:08
收件人: Pan, Fengyun/潘 风云
抄送: Vijaya Bhaskar; openstack
主题: Re: 答复: [Openstack] Ceilometer high availability in active-active

On Wed, 11 Mar 2015, Pan, Fengyun wrote:

We kown that:
backendurl',
default=None,
help='The backend URL to use for distributed coordination. If '
'left empty, per-deployment central agent and per-host '
'compute agent won\'t do workload '
'partitioning and will only function correctly if a '
'single instance of that service is running.'), But
how to set the ‘backend
url’?

This appears to be an oversight in the documentation. The main starting point is here:

http://docs.openstack.org/admin-guide-cloud/content/section_telemetry-cetral-compute-agent-ha.html

but nothing there nor what it links to actually says what should go as the value of the setting. It's entirely dependent on the backend being used and how that backend is being configured. Each of the tooz drivers has some information on some of the options, but again, it is not fully documented yet.

For reference, what I use in my own testing is redis as follows:

redis://localhost:6379

This uses a single redis server, so introduces another single point of failure. It's possible to use sentinel to improve upon this situation:

http://docs.openstack.org/developer/tooz/developers.html#redis

The other drivers work in similar ways with their own unique arguments.

I'm sorry I'm not able to point to more complete information but I can say that it is in the process of being improved.

--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent


Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
responded Mar 18, 2015 by Pan,_Fengyun (380 points)   1 2
...