It's probably dead simple. Each cluster can have a db that says what apps and versions it can handle. For each app and version that it handles, it has a copy of the code in its local GFS. That gives every server in that cluster access to the code. Since this code is read-only, each server can cache.
When you deploy a new application or new version, it goes to a cluster which updates its db and local GFS. It then starts telling other clusters about the new application/version. Routing for a specific version is easy. If said router doesn't know about that version/application, it asks clusters for that application/ version until it finds one that has it and caches that information for "a while". (Note - I'm not using "router" to refer to an Internet router, but to refer to the "thingie" that figures out where to send requests for a given application.) However, routing for the "current" version is tricky - the problem is that different clusters can think that different versions are "current". (Deleting old versions can be tricky unless you can tell the routers that a version is dead. If you can, you tell all the routers that an application/version is dead, delete that version from all the clusters, and then remove the "is dead" notice from the routers.) The easy way to deal with that is to simply not let a version become current until it has been copied to all appropriate clusters. Note that the naive implementation of this idea has a race. You can move the race into the routers by telling them what version is "current". However, there's still the problem of keeping multiple routers consistent, especially if they're relying on what clusters tell them. One way is to temporarily tell all but one router to route "current" requests for a given application to said router until said router is ready to atomically perform the transition. There could be a set of dedicated routers that are used only for applications that are transitioning from one current version to another. With this scheme, a transition router owns the definition of "current" wrt a given application until the clusters' dbs definition of "current" are updated wrt that application. (Of course, the file copies and initial cluster db entries can be done before the transition starts.) When you're not doing a transition, the above allows an arbitrary number of routers and clusters. (Notice that a given version need not be on every cluster.) Of course, such routers can also spread the load for a given application/version across multiple clusters and there are some tricks to speed up the search for a cluster that has a given application/version. During an application's transition, a single router has to handle all the routing load for said application, but there are very few applications that will overwhelm a dedicated router. In fact, most applications won't strain a dedicated router, so you actually want to use a given transition router to transition multiple applications whenever possible. On Oct 30, 5:20 am, tav <t...@espians.com> wrote: > Hey App Engine team, > > I was wondering if you could share a quick high-level summary of how > the app engine deployment works internally? I've been trying to figure > out how it works so as to mimic the behaviour for my own framework... > > All the ways that I can think of are nowhere near the elegance of what > App Engine offers: > > * Using a SAN for the app code and putting the code into versioned > directories. Whilst simple, this has the downsides of cost — both in > terms of money and latency. > > * Using something like Capistrano/Fabric to do parallel updates to > many servers. But this doesn't really scale so well and requires a lot > of administrative overhead. > > * Putting the app code into a distributed data store. But this has the > downsides of having to do a datastore lookup before serving every > request — not to mention the additional time it takes to get the code > for a cold start... > > Would love to know how you guys do it — thanks! > > -- > love, tav > > plex:espians/tav | t...@espians.com | +44 (0) 7809 569 > 369http://tav.espians.com|http://twitter.com/tav| skype:tavespian --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~----------~----~----~----~------~----~------~--~---
