[Openstack-operators] [openstack-dev] [nova] deployment question consultation
Matt Riedemann
mriedemos at gmail.com
Sun Aug 19 03:21:03 UTC 2018
+ops list
On 8/18/2018 10:20 PM, Matt Riedemann wrote:
> On 8/13/2018 9:30 PM, Rambo wrote:
>> 1.Only in one region situation,what will happen in the cloud
>> as expansion of cluster size?Then how solve it?If have the limit
>> physical node number under the one region situation?How many nodes
>> would be the best in one regione?
>
> This question seems a bit too open-ended and completely subjective.
>
>> 2.When to use cellV2 is most suitable in cloud?
>
> When this has been asked in the past, the best answer I've heard is,
> "whatever your current DB and MQ limits are for nova". So if that's
> about 200 hosts before the DB/MQ are struggling, then that could a cell.
> For reference, CERN has 70 cells with ~200 hosts per cell. However, at
> least one public cloud is approaching cells with fewer cells and
> thousands of hosts per cell. So it varies based on where your
> limitations lie. Also note that cells do not have to be defined by DB/MQ
> limits, they can also be used as a way to shard hardware and instance
> (flavor) types. For example, generation 1 hardware in cell1, gen2
> hardware in cell2, etc.
>
>> 3.How to shorten the time of batch creation of instance?
>
> This again is completely subjective. It would depend on the
> configuration, size of nova deployment, size of hardware, available
> capacity, etc. Have you done profiling to point out *specific* problem
> areas during multi-create, for example, are you packing VMs onto as few
> hosts as possible to reduce costs? And if so, are you hitting problems
> with that due to rescheduling the server build because you have multiple
> scheduler workers picking the same host(s) for a subset of the VMs in
> the request? Or are you hitting RPC timeouts during select_destinations?
> If so, that might be related to the problem described in [1].
>
> [1] https://review.openstack.org/#/c/510235/
>
--
Thanks,
Matt
More information about the OpenStack-operators
mailing list