<div dir="ltr">I never thought about it being like a CI cloud, but it would be very similar in usage. I should clarify that it is actually physical cores (AMD Epics) so it's 128 and 256 threads and yes at least 1TB ram per with ceph shared storage. <div><br></div><div>That 400 is actually capped out at about 415 instances per compute (same cap for 64 and 128 cpu's) where I run into kernel/libvirt issues and nfconntrack hits limits and crashes. I don't have specifics to give at the moment regarding that issue, I will have to try and recreate/reproduce that when I get my other environment freed up to allow me to test that again. I was in a hurry last time that happened to me and did not get a chance to gather all the information for a bug.</div><div><br></div><div>Switching to python binding with ovs and some tuning of mariadb, rabbit, haproxy and memcached is how I got to be able to accommodate that rate of turnover.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 3, 2021 at 9:40 AM Sean Mooney <<a href="mailto:smooney@redhat.com" target="_blank">smooney@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, 2021-02-03 at 09:05 -0500, David Ivey wrote:<br>
> I am not sure simply going off the number of compute nodes is a good<br>
> representation of scaling issues. I think it has a lot more to do with<br>
> density/networks/ports and the rate of churn in the environment, but I<br>
> could be wrong. For example, I only have 80 high density computes (64 or<br>
> 128 CPU's with ~400 instances per compute) and I run into the same scaling<br>
> issues that are described in the Large Scale Sig and have to do a lot of<br>
> tuning to keep the environment stable. My environment is also kinda unique<br>
> in the way mine gets used as I have 2k to 4k instances torn down and<br>
> rebuilt within an hour or two quite often so my API's are constantly<br>
> bombarded.<br>
actully your envionment sound like a pretty typical CI cloud<br>
where you often have short lifetimes for instance, oftten have high density<br>
and large turnover.<br>
but you are correct compute node scalse alone is not a good indictor.<br>
port,volume,instance count are deffinetly factors as is the workload profile<br>
<br>
im just assuming your cloud is a ci cloud but interms of generic workload profiles<br>
that would seam to be the closes aproximation im aware off to that type of creation<br>
and deleteion in a n hour period.<br>
<br>
400 instance per comput ewhile a lot is really not that unreasonable assuming your<br>
typical host have 1+TB of ram and you have typically less than 4-8 cores per guests<br>
with only 128 CPUs going much above that would be over subscitbing the cpus quite hevially<br>
we generally dont recommend exceeding more then about 4x oversubsiption for cpus even though<br>
the default is 16 based on legacy reason that assume effectvly website hosts type workloads<br>
where the botelneck is not on cpu but disk and network io.<br>
<br>
with 400 instance per host that also equatest to at least 400 neutrop ports<br>
if you are using ipatable thats actully at least 1200 ports on the host which definetly has<br>
scalining issues on agent restart or host reboot.<br>
<br>
usign the python binding for ovs can help a lot as well as changing to the ovs firewall driver<br>
as that removes the linux bridge and veth pair created for each nueton port when doing hybrid plug.<br>
<br>
> <br>
> On Tue, Feb 2, 2021 at 3:15 PM Erik Olof Gunnar Andersson <<br>
> <a href="mailto:eandersson@blizzard.com" target="_blank">eandersson@blizzard.com</a>> wrote:<br>
> <br>
> > > the old value of 500 nodes max has not been true for a very long time<br>
> > rabbitmq and the db still tends to be the bottelneck to scale however<br>
> > beyond 1500 nodes<br>
> > outside of the operational overhead.<br>
> > <br>
> > We manage our scale with regions as well. With 1k nodes our RabbitMQ<br>
> > isn't breaking a sweat, and no signs that the database would be hitting any<br>
> > limits. Our issues have been limited to scaling Neutron and VM scheduling<br>
> > on Nova mostly due to, NUMA pinning.<br>
> > ------------------------------<br>
> > *From:* Sean Mooney <<a href="mailto:smooney@redhat.com" target="_blank">smooney@redhat.com</a>><br>
> > *Sent:* Tuesday, February 2, 2021 9:50 AM<br>
> > *To:* <a href="mailto:openstack-discuss@lists.openstack.org" target="_blank">openstack-discuss@lists.openstack.org</a> <<br>
> > <a href="mailto:openstack-discuss@lists.openstack.org" target="_blank">openstack-discuss@lists.openstack.org</a>><br>
> > *Subject:* Re: [ops][largescale-sig] How many compute nodes in a single<br>
> > cluster ?<br>
> > <br>
> > On Tue, 2021-02-02 at 17:37 +0000, Arnaud Morin wrote:<br>
> > > Hey all,<br>
> > > <br>
> > > I will start the answers :)<br>
> > > <br>
> > > At OVH, our hard limit is around 1500 hypervisors on a region.<br>
> > > It also depends a lot on number of instances (and neutron ports).<br>
> > > The effects if we try to go above this number:<br>
> > > - load on control plane (db/rabbit) is increasing a lot<br>
> > > - "burst" load is hard to manage (e.g. restart of all neutron agent or<br>
> > >   nova computes is putting a high pressure on control plane)<br>
> > > - and of course, failure domain is bigger<br>
> > > <br>
> > > Note that we dont use cells.<br>
> > > We are deploying multiple regions, but this is painful to manage /<br>
> > > understand for our clients.<br>
> > > We are looking for a solution to unify the regions, but we did not find<br>
> > > anything which could fit our needs for now.<br>
> > <br>
> > i assume you do not see cells v2 as a replacment for multipel regions<br>
> > because they<br>
> > do not provide indepente falut domains and also because they are only a<br>
> > nova feature<br>
> > so it does not solve sclaing issue in other service like neutorn which are<br>
> > streached acrooss<br>
> > all cells.<br>
> > <br>
> > cells are a scaling mechinm but the larger the cloud the harder it is to<br>
> > upgrade and cells does not<br>
> > help with that infact by adding more contoler it hinders upgrades.<br>
> > <br>
> > seperate regoins can all be upgraded indepently and can be fault tolerant<br>
> > if you dont share serviecs<br>
> > between regjions and use fedeeration to avoid sharing keystone.<br>
> > <br>
> > <br>
> > glad to hear you can manage 1500 compute nodes by the way.<br>
> > <br>
> > the old value of 500 nodes max has not been true for a very long time<br>
> > rabbitmq and the db still tends to be the bottelneck to scale however<br>
> > beyond 1500 nodes<br>
> > outside of the operational overhead.<br>
> > <br>
> > > <br>
> > > Cheers,<br>
> > > <br>
> > <br>
> > <br>
> > <br>
> > <br>
<br>
<br>
</blockquote></div>