[Cosmo-dev] Deployment of Cosmo persistence load distribution
jared at wordzoo.com
Wed Jul 26 17:55:50 PDT 2006
Brian Moseley wrote:
> i can't even tell you what features will be in 0.5, much less beta :)
Hmmm, I don't think that's true.
> i have never seen dates associated with alpha and beta. nobody's even
> defined alpha and beta for me. i certainly have no idea what
> requirerments we have for those milestones. so forgive me if i smile
> and nod whenever anybody talks about them.
Double hmmm, I suspect other may have more to say about this. I know I've
stood up in a staff meeting and put some dates on Alpha and Beta, and more
than one PPD posting has dates.
In any case, this conversation seems a fruitful way to get to clarity on
those items for you.
Let's state Alpha as March 2007.
Beta is some number of months after that, but in 2007 as I understand it.
I propose three contraints on scheduling for us to undertake as a group:
+ No major architectural layers get added during Beta; all the layers
necessary to scale to large volumes is in place before Beta.
+ Load balancing of application and database load is in place for the Alpha,
and has been stress-tested 6 weeks before Alpha in March 2007.
+ I need 6-8 weeks to translate the final architecture into production
hardware (before that, we'll be running a dozen-odd virtual machines inside
one physical server)
To do a proof of concept for the load balancing, we'll need to have at least
these things in place:
+ Hibernate backend in Cosmo release
+ Database lookup/service locator code integrated into Cosmo
+ Central lookup database instance
+ Locking for distributed writes
+ Cosmo support for /cmp/users across all databases
+ IP sprayer and SSL-decryption
+ 3 Cosmo app servers
+ 2 MySQL database servers
Later, during Alpha but before beta, I'd like to add these things:
+ Separate, hardware-based SSL decryption layer (highly-available)
+ High availability for MySQL database servers
+ High availability for central lookup database
Let's say we do Hibernate first, and then add a locator service later (which
takes say a month; I'd advocate doing both in parallel, but hypothetically),
then does it look something like this?
March 1, 2007: Launch Alpha
6 weeks prior, January 18, 2007: Stress testing period
2 months prior, November 23, 2006: Start implementing hardware
1 month prior, October 26, 2006: Implement service locator
then we've got something like 3 months from now until the Hibernate
implementation needs to be solid enough to start solidifying around it?
Which means probably is included in a regular release?
(These dates are not intended to be rigorous, but suggestive. Corrections
to the strawman schedule calculation above welcomed.)
This sort of schedule can be the basic plan of record for the Hosted
Service, or it could be laid out otherwise. But something needs to get
incorporated into the program management for the Hosted Service so other
work items can be planned, and labor and expenses can be planned out. In
practical terms, it means we'll see as much front-loading of other service
features (ticket tracking, email integration, forums, etc) as possible,
because as soon as any aspect of load-balanced servers are available, I need
to be very focused on that.
Anything that you think can reasonably be done to get load-distribution
dependencies like database-to-use lookup earlier into Cosmo would really
help provide some flexibility in the Hosted Service schedule. I expect the
most helpful thing to do is standby patiently while the Hibernate code gets
written and we start regrouping after that.
I apologize, for what it's worth, on asking questions to which one could
reasonably say we "we just can't know yet". I'm trying to explore the
issues that we share as the Cosmo and Hosted Service teams.
More information about the cosmo-dev