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.

上周在 Linux 上配置和简单测试了一下 Sun Ray Server Software (SRSS 4.2) ，并摸清了一些 Sun Ray 服务器的硬件配置要求后，这周开始把 Sun Ray Server 引入生产环境，在用户生产应用以前 VPSee 觉得还是需要再测一下，模拟大量用户终端登录，看看服务器、客户端的效果以及 Linux 下的 SRSS 会不会出问题。

如何模拟多个用户登录呢？在 Windows 上可以使用 Sun Desktop Access Client (SDAC) 软件来连接 SunRay Server，SDAC 实际上是 SunRay 瘦客户端的软件实现，其功能和 SunRay 瘦客户端基本一样。现在的问题就是如何在一个 Windows 上建立50-100个 SDAC 连接以便模拟出50-100个瘦客户端用户。

配置 SunRay 服务器软件

1、首先需要配置 policy，否则的话 SunRay 客户端软件（SDAC）会报错，错误号：47 Access for Sun Desktop Access Clients is disabled by default：

# /opt/SUNWut/sbin/utpolicy -a -g -z both -u pseudo
# /opt/SUNWut/sbin/utrestart

配置 SunRay 客户端软件

2、下载和安装 SDAC，SDAC 目前只有 Windows 版本，登录服务器后界面如下：

3、在 Windows 上（这里用的是 Vista）修改 C:\Users\VPSee\AppData\Roaming\Sun\SDAC\default，删除以 DSAKey= 开头的一行，如：DSAKey=zFWoaDJPBLeCBXspye05KH5x0W，保存文件。

4、运行 cmd.exe，进入 C:\Users\VPSee\AppData\Roaming\Sun\SDAC 目录后拷贝50个文件：

FOR /L %i in (0,1,50) DO copy default SDAC%i.txt

测试

5、使用刚才创建的50个配置文件启动 SDAC 并连接 SunRay Server，需要注意的是每个 SDAC 连接大约消耗 15MB 左右的内存，2GB 内存的机器可以尝试创建100个配置文件、建立100个连接。进入 C:\Program Files\Sun\Sun Desktop Access Client 目录后运行：

FOR /L %i in (0,1,50) DO SDAC.exe --profile SDAC%i.txt 172.16.38.1

6、手动一个个登录，每个终端都启动几个应用程序看一下，并查看服务器状况。

可以在服务器上看看有多少客户端连进来：

# /opt/SUNWut/bin/utwho -Hac

37signals 是除了 Twitter 以外的又一个高流量 Ruby on Rails 架构的示例。

数据

数据来源（2007）：Ask 37signals: Numbers?

约30台服务器组成的 cluster，从 1 CPU 的文件服务器到 8 CPU 的应用服务器，加起来大慨 100 CPUs 和 200GB 内存（正计划把服务器数量减到16台，92 CPUs 和 230GB 内存，性能更高，架构更简单更易管理）。
客户总共上传约 5.9TB 的数据

Stack

以下是 37signals 用到的一些 stack：

Apache
HAProxy
Ruby on Rails
Mongrel
Memcached
MySQL
Xen
Amazon S3

值得注意的是用到了 Xen 虚拟技术和 Amazon S3 云存储。Memcached 现在已是高访问量网站的标准配置了，就不介绍了。有意思的是，DHH 在 Interview with David Heinemeier Hansson 提到，随着技术的发展，硬件越来越便宜，如果能用硬件解决问题就尽量用硬件，除非绝对必要，否则 shard 数据库来分载流量很痛苦。所以 37signals 不太赞成随便 shard，他们现在的主程序就跑在1台 128GB 的主服务器上，然后有多个备份服务器支持，主服务器不久会扩充到 256GB。VPSee 推测他们的 load balancing 是 Xen 之间的 load balancing，不是物理服务器之间的分载。

继续阅读 »

Wikipedia.org 是个标准的运行在 LAMP 上的高流量网站，看看能从 Brion Vibber （CTO, Wikimedia Founation）的这篇讲义：Scaling and Managing LAMP at Wikimedia 学到些什么。（图片资源来自：Scaling and Managing LAMP at Wikimedia）

数据

每个月100亿 PV
高峰时后每秒达 50000 http requests
约400台 x86 服务器，约250台是 Web Server，剩下的基本上是 MySQL Server
只有7个工程师维护
每个月35000美元的带宽和 hosting 费用

LAMP

Wikipedia 是架在标准 LAMP 上的一个非常好的示例，以下是 Wikipedia.org 用到的一些 stack：

多个不同版本的 Linux，Ubuntu，Debian 等
Apache
PHP
MySQL

Cache

缓存就不用说了，从前端的 web cache，中间的 opcode cache，到后端的 database cache 都需要。Wikipedia 用 Squid + APC + memcached 来完成 cache 工作。Squid 对 wiki 这种内容为主，不经常变化的相对静态的 web 应用很有效。Wikipedia 还用 Squid 做 geographic load balancing，根据不同地理位置访问各地的服务器。只要用到 PHP　的地方就应该用到 opcode cache，Wikipedia.org 选择了 APC，good choice!，VPSee.com 也用 APC：）。memcached 用来缓存数据库的临时 object，不用反复从数据库读取，而且 memcached 可以做成缓存服务器供网上 share object，其他的服务器可以直接读取，比起从磁盘重新读取数据库，网络读取的延迟要小多了。现在大家都用 cache，送礼就送 cache（cash？）！

继续阅读 »