[Openstack] Instance IDs and Multiple Zones
Justin Santa Barbara
justin at fathomdb.com
Tue Mar 22 17:48:09 UTC 2011
I think _if_ we want to stick with straight numbers, the following are the
1) "Skipping" - so zone1 would allocate numbers 1,3,5, zone2 numbers 2,4,6.
Requires that you know in advance how many zones there are.
2) Prefixing - so zone0 would get 0xxxxxxx, zone1 1xxxxxx.
3) Central allocation - each zone would request an ID from a central pool.
This might not be a bad thing, if you do want to have a quick lookup table
of ID -> zone. Doesn't work if the zones aren't under the same
4) Block allocation - a refinement of #3, where you get a bunch of IDs.
Effectively amortizes the cost of the RPC. Probably not worth the effort
(If you want central allocation without a shared database, that's also
possible, but requires some trickier protocols.)
However, I agree with Monsyne: numeric IDs have got to go. Suppose I'm a
customer of Rackspace CloudServers once it is running on OpenStack, and I
also have a private cloud that the new Rackspace Cloud Business unit has
built for me. I like both, and then I want to do cloud bursting in between
them, by putting an aggregating zone in front of them. I think at that
stage, we're screwed unless we figure this out now. And this scenario only
has one provider (Rackspace) involved!
We can square the circle however - if we want numbers, let's use UUIDs -
they're 128 bit numbers, and won't in practice collide. I'd still prefer
On Tue, Mar 22, 2011 at 9:40 AM, Ed Leafe <ed at leafe.com> wrote:
> I want to get some input from all of you on what you think is the
> best way to approach this problem: the RS API requires that every instance
> have a unique ID, and we are currently creating these IDs by use of an
> auto-increment field in the instances table. The introduction of zones
> complicates this, as each zone has its own database.
> The two obvious solutions are a) a single, shared database and b)
> using a UUID instead of an integer for the ID. Both of these approaches have
> been discussed and rejected, so let's not bring them back up now.
> Given integer IDs and separate databases, the only obvious choice is
> partitioning the numeric space so that each zone starts its
> auto-incrementing at a different point, with enough room between starting
> ranges to ensure that they would never overlap. This would require some
> assumptions be made about the maximum number of instances that would ever be
> created in a single zone in order to determine how much numeric space that
> zone would need. I'm looking to get some feedback on what would seem to be
> reasonable guesses to these partition sizes.
> The other concern is more aesthetic than technical: we can make the
> numeric spaces big enough to avoid overlap, but then we'll have very large
> ID values; e.g., 10 or more digits for an instance. Computers won't care,
> but people might, so I thought I'd at least bring up this potential
> -- Ed Leafe
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openstack