
<html>


<head>


<meta http-equiv="Content-Type" content="text/html; charset=utf-8">


</head>


<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">


<br class="">


<div>


<blockquote type="cite" class="">


<div class="">On 20 Sep 2016, at 16:38, Sean Dague <<a href="mailto:sean@dague.net" class="">sean@dague.net</a>> wrote:</div>


<div class="">


<div class="">


<blockquote type="cite" class="">


<blockquote type="cite" class=""><font color="#5856d6" class="">...</font><br class="">


There were also general questions about what scale cells should be<br class="">


considered at.<br class="">


<br class="">


ACTION: we should make sure workarounds are advertised better<br class="">


ACTION: we should have some document about "when cells"?<br class="">


</blockquote>


<br class="">


This is a difficult question to answer because "it depends." It's akin<br class="">


to asking "how many nova-api/nova-conductor processes should I run?"<br class="">


Well, what hardware is being used, how much traffic do you get, is it<br class="">


bursty or sustained, are instances created and left alone or are they<br class="">


torn down regularly, do you prune your database, what version of rabbit<br class="">


are you using, etc...<br class="">


<br class="">


I would expect the best answer(s) to this question are going to come<br class="">


from the operators themselves. What I've seen with cellsv1 is that<br class="">


someone will decide for themselves that they should put no more than X<br class="">


computes in a cell and that information filters out to other operators.<br class="">


That provides a starting point for a new deployment to tune from.<br class="">


</blockquote>


<br class="">


I don't think we need "don't go larger than N nodes" kind of advice. But<br class="">


we should probably know what kinds of things we expect to be hot spots.<br class="">


Like mysql load, possibly indicated by system load or high level of db<br class="">


conflicts. Or rabbit mq load. Or something along those lines.<br class="">


<br class="">


Basically the things to look out for that indicate your are approaching<br class="">


a scale point where cells is going to help. That also helps in defining<br class="">


what kind of scaling issues cells won't help on, which need to be<br class="">


addressed in other ways (such as optimizations).<br class="">


<br class="">


<span class="Apple-tab-span" style="white-space:pre"></span>-Sean<br class="">


<br class="">


</div>


</div>


</blockquote>


<div><br class="">


</div>


We had an ‘interesting' experience splitting a cell which I would not recommend for others.</div>


<div><br class="">


</div>


<div>We started off letting our cells grow to about 1000 hypervisors but following discussions in the </div>


<div>large deployment team, ended up aiming for 200 or so per cell. This also allowed us to make the</div>


<div>hardware homogeneous in a cell.</div>


<div><br class="">


</div>


<div>We then split the original 1000 hypervisor cell into smaller ones which was hard work to plan.</div>


<div><br class="">


</div>


<div>Thus, I think people who think they may need cells are better adding new cells than letting their first one</div>


<div>grow until they are forced to do cells at a later stage and then do a split.</div>


<div><br class="">


</div>


<div>Tim</div>


<div><br class="">


<blockquote type="cite" class="">


<div class="">


<div class="">-- <br class="">


Sean Dague<br class="">


<a href="http://dague.net" class="">http://dague.net</a><br class="">


<br class="">


__________________________________________________________________________<br class="">


OpenStack Development Mailing List (not for usage questions)<br class="">


Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br class="">


http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br class="">


</div>


</div>


</blockquote>


</div>


<br class="">


</body>


</html>