[openstack-dev] [Openstack-operators][nova] Couple of CellsV2 questions
mriedemos at gmail.com
Mon Jul 23 21:57:16 UTC 2018
I'll try to help a bit inline. Also cross-posting to openstack-dev and
tagging with [nova] to highlight it.
On 7/23/2018 10:43 AM, Jonathan Mills wrote:
> I am looking at implementing CellsV2 with multiple cells, and there's a
> few things I'm seeking clarification on:
> 1) How does a superconductor know that it is a superconductor? Is its
> operation different in any fundamental way? Is there any explicit
> configuration or a setting in the database required? Or does it simply
> not care one way or another?
It's a topology term, not really anything in config or the database that
distinguishes the "super" conductor. I assume you've gone over the
service layout in the docs:
There are also some summit talks from Dan about the topology linked here:
The superconductor is the conductor service at the "top" of the tree
which interacts with the API and scheduler (controller) services and
routes operations to the cell. Then once in a cell, the operation should
ideally be confined there. So, for example, reschedules during a build
would be confined to the cell. The cell conductor doesn't go back "up"
to the scheduler to get a new set of hosts for scheduling. This of
course depends on which release you're using and your configuration, see
the caveats section in the cellsv2-layout doc.
> 2) When I ran the command "nova-manage cell_v2 create_cell --name=cell1
> --verbose", the entry created for cell1 in the api database includes
> only one rabbitmq server, but I have three of them as an HA cluster.
> Does it only support talking to one rabbitmq server in this
> configuration? Or can I just update the cell1 transport_url in the
> database to point to all three? Is that a supported configuration?
First, don't update stuff directly in the database if you don't have to.
:) What you set on the transport_url should be whatever oslo.messaging
There is at least one reported bug for this but I'm not sure I fully
grok it or what its status is at this point:
> 3) Is there anything wrong with having one cell share the amqp bus with
> your control plane, while having additional cells use their own amqp
> buses? Certainly I realize that the point of CellsV2 is to shard the
> amqp bus for greater horizontal scalability. But in my case, my first
> cell is on the smaller side, and happens to be colocated with the
> control plane hardware (whereas other cells will be in other parts of
> the datacenter, or in other datacenters with high-speed links). I was
> thinking of just pointing that first cell back at the same rabbitmq
> servers used by the control plane, but perhaps directing them at their
> own rabbitmq vhost. Is that a terrible idea?
Would need to get input from operators and/or Dan Smith's opinion on
this one, but I'd say it's no worse than having a flat single cell
deployment. However, if you're going to do multi-cell long-term anyway,
then it would be best to get in the mindset and discipline of not
relying on shared MQ between the controller services and the cells. In
other words, just do the right thing from the start rather than have to
worry about maybe changing the deployment / configuration for that one
cell down the road when it's harder.
More information about the OpenStack-dev