GitHub's Architecture, before and after migration(anchor.com.au)
anchor.com.au
GitHub's Architecture, before and after migration
http://www.anchor.com.au/blog/2009/09/github-designing-success/
15 comments
Are we to believe that Rackspace plus outsourced system administration is still cheaper than Engine Yard? Impressive.
The move to Rackspace will bring about a new backend architecture and a lot more servers, leading to a much improved user experience for everyone. - TPW from Github
I don't believe that cost was an issue for them with EY. It was about their system's needs regarding server resources.
I don't believe that cost was an issue for them with EY. It was about their system's needs regarding server resources.
Engine Yard hosting was free. I don't think it was about cutting costs necessarily, but rather it was for improving the performance of the site and opening opportunities for scaling rapidly in the future.
EY told them if they wanted to continue to start paying and they said it was a different by a huge amount.
It's not that simple. EY's filesystem stuff is designed for read-almost-always, as you would expect for most Rails sites. GitHub does a lot of writing. Growing GitHub's setup would have been a huge undertaking for EY (from what I've read of their posts) and you just can't do that stuff for free, or you run out of money.
(This is just what I've gleaned from comments. They parted ways amicably. Don't stir up drama.)
(This is just what I've gleaned from comments. They parted ways amicably. Don't stir up drama.)
I'd argue no, at least until you have as good an idea of what your needs are as GitHub did.
I've used Anchor for web hosting (for myself & for clients) and I thoroughly recommend them. Not only is their service great they have technically competent staff. The norm in IT these days seems to be that you have to persevere/fight your way through x layers of support before you get someone who understands tech, at Anchor everytime the person who first spoke to me was able to understand and resolve the issue.
I've setup similar solutions in the past. Nowadays I don't agree with having an entire stack basically sitting idle. I prefer to get those resource involved intelligently. Looking forward to more details and possible reasons for choosing the technology (DRDB, LB software, etc )
We run 12GB of memcache on each slave file server. Hardly idle!
I was looking at http://www.anchor.com.au/blog/wp-content/uploads/2009/09/Git... which shows file server B as a failover, traffic coming into the active LB.
Does the active LB then have a pool which includes other file server B services ?
Only 1TB+ of storage for 15+ physical servers?
Congratulations for that.
And thanks for sharing this information about your architecture, this was a very interesting read.