Coming back from a long break and getting back up to speed.<div><br></div><div>I believe Sandy and I spoke about this at decent length before, the proposal that I understood we both walked away happy with was this:</div><div>
<br></div><div>1. As a first step, implement it with a single db, because that is what we already have and what is the easiest first step. Zones are an additional column or join table and implemented as a filter on the query for instances and the like. Zones in this case being used largely to mean "grouping of servers with some common, possibly distinct, property." We only support a single level of 'zones' for the moment, no arbitrary nesting.</div>
<div>2. See whether that works, it probably will for the current scaling targets and use cases.</div><div>3. To implement bursting/hybrid stuff, we then work on a data abstraction for aggregating the results of remote calls, understanding that we expect remote calls to have lower performance.</div>
<div><br></div><div>The blueprint as it stands (<a href="http://wiki.openstack.org/MultiClusterZones">http://wiki.openstack.org/MultiClusterZones</a>) is following a 'turtles all the way down' approach that probably isn't really appropriate for real world usage. In reality there are things that are global level, things that are region level and things that are cluster level. </div>
<div> * A global service will be in charge of specific requests that need to be global and have very specific and constrained scaling properties, perhaps global dns management.</div><div> * A region represents the largest unit of scaling, the maximum number of nodes and services that can managed at time while meeting SLAs, including the public endpoints, most things above region level need to be managed client side: one does not expect to list all instances across all regions in a single call, one expects to make three requests to the three regions one's instances are in.</div>
<div> * A cluster represents a grouping unit with common properties, either rack commonality, capability commonality, or simply special case customers. Subgroupings here may still be interesting or useful but are unlikely to be necessary. Clusters are likely to share many things at the region level as well as have individual cluster level concerns.</div>
<div><br></div><div>This design handles the needs of plenty of large organizations already and is easy to move to piecemeal from our current codebase, the first step being that zones are clusters and can share a regional registry (database) and public endpoint while still having per-zone services (scheduler, et al).</div>
<div><br></div><div>--andy</div><div><br><div class="gmail_quote">On Wed, Mar 16, 2011 at 4:51 PM, Sandy Walsh <span dir="ltr"><<a href="mailto:sandy.walsh@rackspace.com">sandy.walsh@rackspace.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word;color:rgb(0, 0, 0)">
<div style="direction:ltr;font-family:Tahoma;color:#000000;font-size:10pt">
<div>Yup, that's a fair assessment. </div>
<div><br>
</div>
<div>That said, even without SDB and caching it's going to be tight for Cactus anyway. There are lots of little issues that are cropping up once I got down to 100'. </div>
<div><br>
</div>
<div>-S</div>
<br>
<div style="color:rgb(0, 0, 0)">
<hr style="font-family:'Times New Roman';font-size:16px"><div class="im">
<div style="direction:ltr;font-family:'Times New Roman';font-size:16px">
<span style="font-size:15px;font-family:Calibri"><span style="font-weight:bold">From:
</span>Justin Santa Barbara <<a href="mailto:justin@fathomdb.com" target="_blank">justin@fathomdb.com</a>></span></div>
</div><div><span>
<blockquote style="border-left-color:rgb(181, 196, 223);border-left-width:5px;border-left-style:solid;padding-top:0px;padding-right:0px;padding-bottom:0px;padding-left:5px;margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:5px">
<div>
<div style="text-align:left"><font face="Calibri"><span style="font-size:15px"><b><br>
</b></span></font></div><div class="im">
<div style="font-family:'Times New Roman';font-size:16px">Sandy: Have I got the wrong end of the stick here? Are these our choices?</div>
<div style="font-family:'Times New Roman';font-size:16px"><br>
</div>
<div style="font-family:'Times New Roman';font-size:16px">Justin<br>
</div>
</div></div>
<font face="'Times New Roman'" size="3"><br>
</font></blockquote>
</span></div>
</div>
</div><div class="im">
<pre>Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace.
Any dissemination, distribution or copying of the enclosed material is prohibited.
If you receive this transmission in error, please notify us immediately by e-mail
at <a href="mailto:abuse@rackspace.com" target="_blank">abuse@rackspace.com</a>, and delete the original message.
Your cooperation is appreciated.
</pre></div></div>
<br>_______________________________________________<br>
Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
Post to : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
More help : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
<br></blockquote></div><br></div>