<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<tt>This is getting really interesting !!<br>
I really hope to see the new Zones code merged into Essex, since
we are really planning a production implementation on Essex, as
soon as it is marked as a release ( nova, keystone, glance &
swift, wich also we got it working on a big lab environment with
Milestone 2 )<br>
As the expectation, because we mainly use Cactus into production
and because of the network layer we inherit, today we are using 1
zone per VLAN (thats about 16 hosts of 96GB of RAM each, enough to
fill the VLAN with the flavors we use), so yes, the limitation
here is the networking.<br>
<br>
Thats why we are testing Essex with Quantum, cause we really want
to increase the capacity of a zone ( +50 hosts ) by assigning
a/several network/s to a project on any zone, and the new
MultiZone code, to be able to spread the instances across
datacenters (and inside the datacenter also at the same time), we
are thinking also (maybe this out of the scope of the subject)
that the parent zone might be an instance with no compute nodes
but with all the zones loaded into the db, and many nova-api
spawning on different ports, being load balanced at the same time
just to handle the request for the cloud management.<br>
<br>
Just to add a little of our metrics if it helps.<br>
<br>
PS: Is the plan to commit the new Zones code into Milestone 3 ?
that would be fantastic news !<br>
<br>
Cheers !<br>
</tt>
<div class="moz-signature">
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<title></title>
</div>
<br>
On 01/26/2012 01:40 PM, Sandy Walsh wrote:
<blockquote
cite="mid:60A3427EF882A54BA0A1971AE6EF03881E15817E@ORD1EXD02.RACKSPACE.CORP"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<style id="owaParaStyle" type="text/css">P {margin-top:0;margin-bottom:0;}</style>
<div style="direction: ltr;font-family: Courier New;color:
#000000;font-size: 10pt;">
Thanks Blake ... all very valid points.<br>
<br>
Based on our discussions yesterday (the ink is still wet on the
whiteboard) we've been kicking around numbers in the following
ranges:<br>
<br>
500-1000 hosts per zone (zone = single nova deployment. 1 db, 1
rabbit)<br>
25-100 instances per host (minimum flavor)<br>
3s api response time fully loaded (over that would be considered
a failure). 'nova list' being the command that can bring down
the house. But also 'nova boot' is another concern. We're always
trying to get more async operations in there.<br>
<br>
Hosts per zone is a tricky one because we run into so many
issues around network architecture, so your mileage may vary.
Network is the limiting factor in this regard.<br>
<br>
All of our design decisions are being made with these metrics in
mind. <br>
<br>
That said, we'd love to get more feedback on realistic metric
expectations to ensure we're in the right church.<br>
<br>
Hope this is what you're looking for?<br>
<br>
-S<br>
<br>
<br>
<div style="font-family: Times New Roman; color: rgb(0, 0, 0);
font-size: 16px;">
<hr tabindex="-1">
<div style="direction: ltr;" id="divRpF552983"><font
color="#000000" face="Tahoma" size="2"><b>From:</b> Blake
Yeager [<a class="moz-txt-link-abbreviated" href="mailto:blake.yeager@gmail.com">blake.yeager@gmail.com</a>]<br>
<b>Sent:</b> Thursday, January 26, 2012 12:13 PM<br>
<b>To:</b> Sandy Walsh<br>
<b>Cc:</b> <a class="moz-txt-link-abbreviated" href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
<b>Subject:</b> Re: [Openstack] [Scaling][Orchestration]
Zone changes. WAS: [Question #185840]: Multi-Zone finally
working on ESSEX but cant "nova list" (KeyError: 'uuid') +
doubts<br>
</font><br>
</div>
<div>Sandy,
<div><br>
</div>
<div>I am excited to hear about the work that is going on
around communication between trusted zones and look
forward to seeing what you have created.</div>
<div><br>
</div>
<div>In general, the scalability of Nova is an area where I
think we need to put additional emphasis. Rackspace has
done a lot of work on zones, but they don't seem to
be receiving a lot of support from the rest of the
community.</div>
<div><br>
</div>
<div>The OpenStack mission statement indicates the mission
of the project is<strong style="background-color: rgb(255,
255, 255); font-family: sans-serif; line-height: 18px;">:</strong><font
face="arial, helvetica, sans-serif"><span
style="background-color: rgb(255, 255, 255);
line-height: 18px;"> "</span><span class="anchor"
id="line-4" style="background-color: rgb(255, 255,
255); line-height: 18px;"></span><span
style="background-color: rgb(255, 255, 255);
line-height: 18px;">To produce the ubiquitous Open
Source cloud computing platform that will meet the
needs of public and private cloud providers regardless
of size, by being simple to implement and massively
scalable."</span></font></div>
<div><font face="arial, helvetica, sans-serif"><span
style="background-color: rgb(255, 255, 255);
line-height: 18px;"><br>
</span></font></div>
<div><font face="arial, helvetica, sans-serif"><span
style="background-color: rgb(255, 255, 255);
line-height: 18px;">I would challenge the community to
ensure that scale is being given the appropriate focus
in upcoming releases, especially Nova. Perhaps we
need to start by setting very specific scale targets
for a single Nova zone in terms of nodes, instances,
volumes, etc. I did a quick search of the wiki but I
didn't find anything about scale targets. Does anyone
know if something exists and I am just missing it?
Obviously scale will depend a lot on your specific
hardware and configuration but we could start by
saying with this minimum hardware spec and this
configuration we want to be able to hit this scale.
Likewise it would be nice to publish some statistics
about the scale that we believe a given release can
operate at safely. This would tie into some of the
QA/Testing work that Jay & team are working on.</span></font></div>
<div><font face="arial, helvetica, sans-serif"><span
style="background-color: rgb(255, 255, 255);
line-height: 18px;"><br>
</span></font></div>
<div><font face="arial, helvetica, sans-serif"><span
style="line-height: 18px;">Does anyone have other
thoughts about how we ensure we are all working toward
building a massively scalable system?</span></font></div>
<div><font face="arial, helvetica, sans-serif"><span
style="line-height: 18px;"><br>
</span></font></div>
<div><font face="arial, helvetica, sans-serif"><span
style="line-height: 18px;">-Blake</span></font></div>
<div><font face="arial, helvetica, sans-serif"><span
style="line-height: 18px;"><br>
</span></font></div>
<div>
<div class="gmail_quote">On Thu, Jan 26, 2012 at 9:20 AM,
Sandy Walsh <span dir="ltr">
<<a moz-do-not-send="true"
href="mailto:sandy.walsh@rackspace.com"
target="_blank">sandy.walsh@rackspace.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt
0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
Zones is going through some radical changes currently.<br>
<br>
Specifically, we're planning to use direct
Rabbit-to-Rabbit communication between trusted Zones
to avoid the complication of changes to OS API,
Keystone and novaclient.<br>
<br>
To the user deploying Nova not much will change, there
may be a new service to deploy (a Zones service), but
that would be all. To a developer, the code in OS API
will greatly simplify and the Distributed Scheduler
will be able to focus on single zone scheduling (vs
doing both zone and host scheduling as it does today).<br>
<br>
We'll have more details soon, but we aren't planning
on introducing the new stuff until we have a working
replacement in place. The default Essex Scheduler now
will largely be the same and the filters/weight
functions will still carry forward, so any investments
there won't be lost.<br>
<br>
Stay tuned, we're hoping to get all this in a new
blueprint soon.<br>
<br>
Hope it helps,<br>
Sandy<br>
<br>
________________________________________<br>
From: <a moz-do-not-send="true"
href="mailto:bounces@canonical.com" target="_blank">bounces@canonical.com</a>
[<a moz-do-not-send="true"
href="mailto:bounces@canonical.com" target="_blank">bounces@canonical.com</a>]
on behalf of Alejandro Comisario [<a
moz-do-not-send="true"
href="mailto:question185840@answers.launchpad.net"
target="_blank">question185840@answers.launchpad.net</a>]<br>
Sent: Thursday, January 26, 2012 8:50 AM<br>
To: Sandy Walsh<br>
Subject: Re: [Question #185840]: Multi-Zone finally
working on ESSEX but cant "nova list" (KeyError:
'uuid') + doubts<br>
<br>
Question #185840 on OpenStack Compute (nova) changed:<br>
<a moz-do-not-send="true"
href="https://answers.launchpad.net/nova/+question/185840"
target="_blank">https://answers.launchpad.net/nova/+question/185840</a><br>
<br>
Status: Answered => Open<br>
<br>
Alejandro Comisario is still having a problem:<br>
Sandy, Vish !<br>
<br>
Thanks for the replies ! let me get to the relevant
points.<br>
<br>
#1 I totally agree with you guys, the policy for
spawning instances<br>
maybe very special of each company strategy, but, as
you can pass from<br>
"Fill First" to "Spread First" just adding a
"reverse=True" on<br>
nova.scheduler.least_cost.weighted_sum" and<br>
"nova.scheduler.distributed_scheduler._schedule" maybe
its a harmless<br>
addition to manipulate (since we are going to have a
lot of zones across<br>
datacenters, and many different departments are going
to create many<br>
instances to load-balance their applications, we
really preffer<br>
SpreadFirst to make sure hight availability of the
pools )<br>
<br>
#2 As we are going to test essex-3, i would like if
you can tell me if<br>
the zones code from Chris Behrens is going to be added
on Final Essex /<br>
Milestone 4, so we can keep testing other features, or
you preffer us to<br>
load this as a bug to be fixed since maybe the code
that broke is not<br>
going to have major changes.<br>
<br>
Kindest regards !<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
You received this question notification because
you are a member of Nova<br>
Core, which is an answer contact for OpenStack
Compute (nova).<br>
<br>
_______________________________________________<br>
Mailing list: <a moz-do-not-send="true"
href="https://launchpad.net/%7Eopenstack"
target="_blank">https://launchpad.net/~openstack</a><br>
Post to : <a moz-do-not-send="true"
href="mailto:openstack@lists.launchpad.net"
target="_blank">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a moz-do-not-send="true"
href="https://launchpad.net/%7Eopenstack"
target="_blank">https://launchpad.net/~openstack</a><br>
More help : <a moz-do-not-send="true"
href="https://help.launchpad.net/ListHelp"
target="_blank">https://help.launchpad.net/ListHelp</a><br>
</font></span></blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Mailing list: <a class="moz-txt-link-freetext" href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a>
Post to : <a class="moz-txt-link-abbreviated" href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a>
Unsubscribe : <a class="moz-txt-link-freetext" href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a>
More help : <a class="moz-txt-link-freetext" href="https://help.launchpad.net/ListHelp">https://help.launchpad.net/ListHelp</a>
</pre>
</blockquote>
</body>
</html>