GitHub 的 Rails/Git 架构
2009年10月24日 | 标签: architecture, scalability
GitHub 上个月宣布把所有服务器转移到 Rackspace,他们原先在 Engine Yard 使用的是云计算和虚拟机 10 VMs/39 VCPUs/54GB RAM,移到 Rackspace 后使用的物理服务器配置为 16 Servers/128 Cores/288GB RAM. GitHub 在最近的一篇博客:How We Made GitHub Fast 中分享了他们的架构和经验。
Load Balancer
GitHub 使用了一对 Xen 虚拟机(lb1a 和 lb1b)做 load balancer,运行的是 ldirectord.
前端服务器
Load balancer 把请求发给4台前端服务器中的1台,每台服务器配置为 8 cores/16GB RAM,运行 Nginx,前端(frontend)服务器分别命名 fe1, …, fe4. 在 Nginx 接受到连接请求后转发给 Unix domain socket,并由 16个 Unicorn worker 进程进行处理,其中的某个 worker 会取得请求后开始运行 rails 代码。每个前端服务器还运行4个 ProxyMachine instances,由 HAProxy 来路由。
数据库服务器
MySQL 数据库运行在2台 8 cores/32GB RAM/15000 RPM SAS drivers 的服务器上,命名为 db1a 和 db1b. 其中一台做 Master,另一台做 slave,MySQL 由 DRBD 来做 replication. GitHub 还在数据库服务器上运行 Redis 来保存一些信息。
文件服务器
目前有4对文件服务器,每台配置为 8 core/16GB RAM /6× 300GB 15000 RPM SAS drives/RAID 10,命名为 fs1a, fs1b, …, fs4a, fs4b. 任何时候每对服务器里面都有一台是 active 的,另一台在一旁等候,随时准备接手。每对服务器的数据同步也是通过 DRBD 来实现的。每个文件服务器还运行2个 Ernie RPC 服务,由 HAProxy 来路由,每个 Ernie 运行 15个 ruby works 来响应 RPC 调用。
Memcache 服务器
上面每对文件服务器里面都有1个 master (active) 和1个 slave,多数时候 slave 都很空闲,所以 GitHub 巧妙的利用了这些空闲资源,在每台 slave 文件服务器上拿出 12GB RAM 做分布式 memcache 服务器,服务器别名为 memcache1, …, memcache4.