womax/nova
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Deprecate ironic.peer_list

Browse Source 
As part of the move to using Ironic shards, we document that the best
practice for scaling Ironic and Nova deployments is to shard Ironic
nodes between nova-compute processes, rather than attempting to
user the peer_list.

Currently, we only allow users to do this using conductor groups.
This works well for those wanting a conductor group per L2 network
domain. But in general, conductor groups per nova-compute are
a very poor trade off in terms of ironic deployment complexity.
Futher patches will look to enable the use of ironic shards,
alongside conductor groups, to more easily shard your ironic nodes
between nova-compute processes.

To avoid confusion, we rename the partition_key configuration
value to conductor_group.

blueprint ironic-shards

Change-Id: Ia2e23a59dbd2f13c6f74ca975c249751bebf54b2
This commit is contained in:
John Garbutt
2023-05-17 11:26:53 +01:00
committed by John Garbutt
parent 4490c8bc84
commit cbf400df1d
5 changed files with 76 additions and 30 deletions
Download Patch File Download Diff File Expand all files Collapse all files
doc/source/admin/configuration/hypervisor-ironic.rst
+19 -2
View File
@@ -40,11 +40,28 @@ Configuration
Scaling and performance issues
------------------------------
- It is typical for a single nova-compute process to support several
hundred Ironic nodes. There are known issues when you attempt to
support more than 1000 Ironic nodes associated with a single
nova-compute process, even though Ironic is able to scale out
a single conductor group to much larger sizes. There are many
other factors that can affect what is the maximum practical size of
a conductor group within your deployment.
- The ``update_available_resource`` periodic task reports all the resources
managed by Ironic. Depending the number of nodes, it can take a lot of time.
The nova-compute will not perform any other operations when this task is
running. You can use conductor groups to help scale, by setting
:oslo.config:option:`ironic.partition_key`.
running. You can use conductor groups to help shard your deployment
between multiple nova-compute processes by setting
:oslo.config:option:`ironic.conductor_group`.
- The nova-compute process using the Ironic driver can be moved between
different physical servers using active/passive failover. But when doing
this failover, you must ensure :oslo.config:option:`host` is the same
no matter where the nova-compute process is running. Similarly you must
ensure there are at most one nova-compute processes running for each
conductor group.
- Running multiple nova-compute processes that point at the same
conductor group is now deprecated. Please never have more than one
host in the peer list: :oslo.config:option:`ironic.peer_list`
Known limitations / Missing features