Hardware Architecture Example (geographical level mapping of servers)

I have put down my thoughts in the architecture discussed in the blog. Although I have done substantial research to understand how things should work before deciding this architecture but I will be requiring huge amount of inputs from everyone to come to an architecture decision. Hardware entities which were thought while designing the entities are:
1. Master Web Server which will map different users to web servers placed in different geographical locations. (will prefer storing a mapping table in RAM)
2. Web Servers
3. Application Servers
4. Master Database Servers (to implement entity wise look up sharding)
5. Slave Database Servers.

Will really appreciate if some good inputs of using Cloud Computing are given and how to go about it against or in addition to the given architecture. Would like to in fact know people's view on when to decide using cloud computing techniques. Looking forward for inputs from the community.

Comments

[Mike Babineau]

Parag,

I read through your post and, assuming your application truly requires the sort of architecture you've outlined, I have a few suggestions from my own experience building a geographically distributed, EC2-hosted architecure:
-Move geo-routing to the DNS layer (Akamai GTM, etc.) so users don't have a slow initial connection
-Offload static content serving to a CDN (much closer to your users, easier to manage, etc)
-DB servers are memory-constrained - move memcache to the app servers or dedicated (low-cpu, high mem) boxes
-Shard at the app layer, and do so algorithmically instead of referencing a golden map table for every lookup.

These are pretty general recommendations that may not map well to your application. Feel free to drop me a line if you have any specific questions.

Best of luck,
Mike
http://twitter.com/mikebabineau

[paragarora]

@mike, thanks a lot for your useful suggestions. I will redo a basic research and will come up again with thoughts based upon your advices. Would twitter be good to interact with you or should I keep posting here only?

Parag Arora
www.paragarora.com

[andy.song]

Hi Parag,

I read your interesting documents, and saw one issue "user moved from one place to other place". I had one thought for you reference but maybe not fulfill your requirement.

#First, let's assume we have multiple deployments for different countries. And each countries maintain the user registered within that country. And after user registered, we will flush the information to memcached layer.

#Second, our architecture will design the cache as several layers. And different countries will do the geo-replication with user information (here I thought only need sharding information)

#Third, after the replication finished. Each country within our architecture will share almost same user sharding information.

#Fourth, so if user moved from his registered country to other country. He will almost 90% be recognized by local country user sharding backup database (Not 100% due to the latency).

Here I did saw some company did like this, so that will be pragmatical way but need some carefully design.

Don't know that will be one solution for you. We can detail discussed if you want.

Best Regard
Andy Song