主题：【半原创】Flickr 网站架构研究（1） -- 西电鲁丁

对于Flickr这样运行几百台甚至上千台服务器，以及网络和存储设备的大型网站来说，有效的监视整个系统各部分的运行状况，及时发现并处理故障和潜在的问题，是保障网站平稳和可持续运营的关键。

以系统监控和网络管理为主要目的的软件通常称之为“网管软件”，商用软件中以IBM Tivoli, HP OpenView，和CA Unicenter TNG为主流，开源社区则以OpenNMS和Nagios为代表，Flickr采用的是Nagios。传统上定义的网络管理有五大功能：故障管理、配置管理、性能管理、安全管理、计费管理。近些年随着”全面管理“概念的引入，这类软件一般更多的自称为“企业基础架构管理软件”。

　　SNMP即“Simple Network Management Protocol”是目前最常用的网络管理协议，目前几乎所有的网络设备和主流操作系统都实现了对SNMP的支持。它提供了一种从网络上的设备中收集网络管理信息的方法，也为设备向网络管理工作站报告问题和错误提供了一种方法。

SNMP的最初版本1.0只定义了5种报文：Get,GetNext,getResponse,Set,Trap（这也是它称之为“简单”的原因，而事实上SNMP报文的编解码较为复杂。），示意图如下：

SNMP采用UDP作为传输协议，Get,GetNext,用于NMS Manager（一般即网管主机）以轮询（Polling）的方式向SNMP Agent（一般运行在网络设备或服务器上）发出获取MIB（Management Information Base）节点信息的请求，GetResponse则是SNMP Agent的回应,Set用于写操作（实际中很少使用），这4个报文都通过161端口传输；当SNMP Agent端发现所监控的对象（MIB节点）出现故障，则主动向NMS Manager的162端口发出Trap告警。（详细的SNMP协议介绍不在本文内容之内，有兴趣的话可以另贴讨论）

SNMP的协议特点使得"网管软件"能够及时地被动接收网络上的各种告警(Trap)信息,并根据告警信息的内容和级别触发响应的程序进行处理。例如Nagios提供了超过50个各类插件（plugin）用于监控常用的网络设备，服务器系统资源，后台服务进程和软件等，也可以根据需要自行开发相应的客户化插件用于监控特定的资源和事件。

Flickr将告警分为以下几类：

1）Up/Down,例如定期检查Apache Server和一些后台服务的状态，发现响应失败则自动重起服务进程，并通知管理员(根据级别采用事后邮件或实时短信、寻呼等)。对于一些服务或应用，有必要检查每一个子进程或服务的Up/Down的状态；而对另一些服务和应用，则可能需要“整体”来看，比如，几十台Web Server中的一台故障，一般不需要马上处理，而MySQL Master Server故障，则要马上通知DBA。

2）资源不足，例如硬盘空间或网络带宽不足时邮件提醒管理员考虑购买新的硬盘或增加网络带宽。

3）超过或低于阀值，例如CPU利用率，DISK I/O长时间过高等；或者某台Web Server处理的交易请求突然大幅度降低等。

一开始困难往往在于不知道哪些事件需要告警，哪些则可以忽略。Flickr的经验是先定义尽可能多的事件，然后随着运营的稳定和经验数据的积累再逐步减少。另外，定义完善的告警级别和上报流程也有助于减少不必要的人工和尽快排除故障。

网管软件的功能当然不只是“告警”，性能管理和“趋势”管理也越来越成为“企业基础架构管理”的重要组成部分。不过尽管网管软件可以通过扩展来提供一定程度上的此类功能，但SNMP协议本身的效率并不高，而且当网络达到了一定规模时，主动轮询的方式也限制了它的扩展性和采集大量的数据，一般常见的轮询间隔往往只能限定为10－15分钟甚至更长，这样的采样颗粒度有时很难满足精度和精确分析的要求，因而在大型网络环境下，人们通常更倾向于专门的“数据采集和趋势分析“软件，而这其中的佼佼者就是大名鼎鼎的Ganglia

Ganglia诞生于著名的伯克利大学，最早专用于高性能计算（HPC）环境中的cluster和Grid的监控，经过精心设计的数据结构和算法，使得Ganglia能够以较小的开销同时监视数千台节点。

Ganglia的数据流如下图：

gmond进程,运行在各个节点负责收集数据，并通过multicast或unicast向运行于后台服务端的gmetd进程发送数据，gmetd汇聚数据并存入RRDTool所管理的Round Robin Database.

Round Robin Database是一种特殊的数据库，它对于存储于其中的数据根据时间的远近而保存不同的数据“分辨率”，比如对于较近时间段数据保存每分钟一个采样点，而对于一年以前的数据则只保留每天一个采样点，超过用户指定的期限如几年则自动将过期数据删除。RRD的理论出发点是人们一般较关心近期数据的精确性，而对于长期数据，则只关心大的趋势。RRD的特点使得它能够将数据库的规模限制在一定大小，而不是随着时间的持续而无限增长，这就解决了在相对长的时间内保存大量趋势数据的关键问题，因而在数据采集和趋势分析软件中得到了广泛的应用。

虽然gmond本身可以采集操作系统一级的大量系统信息，如CPU，内存，硬盘和网络I/O等，但光有这些信息是远远不够的，对于一个网站来说，更重要的是了解这些系统信息所代表或对应的业务信息的含义，比如CPU利用率40％时，网站的平均响应时间是多少，网站同时能够支持的并发用户是多少。这些信息更多的来自于应用或基础构件（如MySQL，Web Server,Memcache,Squid等），而Ganglia提供的另一个程序gmetric，则可以通过cron定期调用script的方式来采集这些客户化的应用层数据并发送到gmetd。例如下面的代码分别用于获取disk util和memcache的命中率,

#!/bin/sh

/usr/bin/iostat -x 4 2 sda | grep -v ^$ | tail -4 > /tmp/

disk-io.tmp

UTIL=`grep sda /tmp/disk-io.tmp | awk '{print $14}'`

/usr/bin/gmetric -t uint16 -n disk-util -v$UTIL -u '%'

。。。。。。

/usr/bin/gmetric -t uint32 -n memcachced_hitratio -v$HITRATIO -u ’%’

Apache,MySQL,Memcache,Squid等一般都可以某种方式提供一定程度上的实时统计信息，通过对这些数据的定期采样（如每分钟），可以很清楚的显示整个系统近乎实时的运营情况，找出各个数据相互之间的关系及其规律，并以此作为容量规划的依据。下面是Flickr的运营主管在一次会议上展示的Flickr的Ganglia系统。

除了这些子系统本身提供的一些实时的统计数据外，Web Server的Access Log是另一个重要的统计和性能数据来源。一行典型的Access Log包括：用户的IP地址，访问时间，执行时间（time-taken),网页的URL，HTTP的响应码，数据包大小等。通过对这些Log的分析，我们可以得到很多有用的信息。一个最常见的困难是，如何按照时间顺序汇总几十台甚至数百台Web Server的Log。传统的手工COPY和处理不仅费时，而且COPY的时候占用网络资源较大。所幸的是Spread Toolkit帮我们解决了这个问题，采用Spread toolkit进行开发,我们可以将多台Web Server的Log以multicast的方式实时传输到一台或几台（用于Fail-over）集中的Log Server。特别的对于Apache,可以直接下载和使用一个基于Spread的现成模块mod_log_spread，采用mod_log_spread,Apache避免了本地Log的读写，据说可以提高运行效率20-30%。 对于Log的分析，网上虽然有很多软件，如Report Magic等，但这些软件并不懂你的应用，只能做一些基本的分析，Flickr对于这些Log进行了基于应用的分析和处理，并将结果也导入Ganglia。

Access Log的分析是基于Web页面的，Flickr的技术团队认为这还不足够，因而进一步对于页面的每个task进行计数，比如总共有多少访问是memcache的，多少是直接调用数据库的。最常见的想法是利用数据库，每次访问则更新数据库的记录，这对于每秒访问量成千上万的繁忙网站来说基本上是不可行的，因为连接和更新数据库的开销太大。Flickr使用的是UDP，PHP的相关代码如下：

$fp = fsockopen("udp://$server", $port, $errno, $errstr);

if ($fp){

fwrite($fp, "$value\n");

fclose($fp);

}

$value即是所要计数的counter的名称。一个后台的Perl进程每收到一个counter,就在相应的counter的计数上加1，并定期存入RRD。

计数之外，Flickr还对一些任务计时。一些后台程序定期执行这些特定任务并记录这些任务所花费的时间。

由于环境的影响，每次计时可能都会不同，获得标准偏差比简单的取平均值更要有意义。例如下图：

此项示例任务平均时间为250ms，75%的任务时间大约340ms，25%的任务在 190ms以内，最下面的浅绿线则是剩下的25%。

Flickr公开了这段代码，有兴趣的可以在这里下载。

最后简单讲一下Flickr如何确定系统的“边界”，即在可接受的性能条件下的最大负载。Flickr并不太看重在测试系统所作的benchmark或者是压力测试。在大多数情况下，测试环境很难完全100%的模拟真实的投产环境，即使软硬件环境完全一致，并完全复制投产系统的数据，因为大量用户的行为是无法完全模拟的。虽然有一些Log replay软件（如Httperf，Siege）可以根据Web Access Log作一定程度的模拟，但一般来说Access Log不包括HTTP POST的请求参数，无法replay,而且replay软件也无法模拟由于地理位置和网络不同而造成的网络迟延等问题。Flickr采用的是“controlled production load testing"，即直接在投产系统测试来取得特定配置下Server的最大负载。这其中的关键是Load Balancer,通过调节Load Balancer的负载分配，逐渐增加指定Server的访问量，直到达到临界值为止。

推荐一本书《The Art of Capacity Planning》,这是Flickr运营主管写的一本关于大型网站容量规划的书，书中没有什么高深的数学公式，完全从实战的角度出发，值得一看。

祝大家新年快乐，虎年吉祥。

　最后来说一说"Stoage Manager"。最早的Flickr系统是没有这一层的，Web/PHP Server在收到用户上载的照片后直接通过NFS协议将照片文件写入后台的NetApp存储。这样带来的问题是：

　　１。NFS协议的“文件传输”效率成为瓶颈。高效网络文件传输的要点在于使用尽可能大的数据报文和尽量减少传输控制报文的开销，不幸的是，NFS在这两点上都差强人意。

　　早期的NFS version 2.0使用UDP作为传输协议，但一次最大只能传输8KB.NFS version 3.0消除了这个8KB的限制，并引入了“异步写”的概念，理论上可以将多个小的“写”缓存在“cache”中再合并成一个大的写操作而提高效率，但在实际中往往要看协议的实现情况和操作系统内核的支持，比如至少在早期的LINUX实现中并不理想。

　　2004年初，University of Massachusetts & IBM Almaden Research Center & University of California联合做了一项关于比较NFS和iSCSI应用于IP存储性能的研究，“A Performance Comparison of NFS and iSCSI　for IP-Networked Storage”。在这份研究中，其中一项是在网络协议层比较两者“顺序和随机读写“的效率，结果见下图

　我们看到NFSv3的“读”效率和iSCSI基本相当，但在写效率上则有数量级上的差距。从网络协议报文的数量上看，iSCSI远远小于NFSv3，这是因为iSCSI能够以较大的数据包（大约128KB）执行异步写操作，而NFSv3的平均数据包只有4.7KB，其原因是NFSv3在Linux上的实现受到了Linux 内核2.4 cache最大“pending write"数量的限制因而不能充分利用异步写所带来的好处。

　在另一项应用层的测试中，研究人员使用PostMark测试了两者在创建，删除，读和附加(append)文件的效率，结果如下：

Completion time (s) Messages

　Files NFSv3 iSCSI NFS v3 iSCSI

1,000 146 12 　　371,963 101

5,000 201 35 　　451,415 276

25,000 516 208 　　639,128 66,965

　这项测试表明NFSv3协议在文件相关操作中有非常高的"meta-data related overhead",研究人员在分析上面的测试结果发现这一类message占全部message数量的65%。

　　同样是在2004年，一些操作系统包括Linux等开始部分支持NFSv4。NFSv4除了采用了TCP之外，引入了一些新的特性，其中之一是“Compound RPCs"，即可以一次发送多个RFC请求并取得结果，这样无疑可以大大减少"meta-data"相关的开销，显著的提高协议的总体效率。另一方面，随着Linux内核2.6的成熟并得到逐步采用,Linux在NFS的实现上也有了很大的提高，例如消除了"pending write" 数量的限制等。

　　然而不幸的是，这些提高对于Flickr所需的“大文件传输”并没有帮助。根据“NFSv4 Test Project”的测试结果

　　在异步模式下，对于小于512KB的文件，NFSv4(红线)大约是NFSv3 (绿线)效率的３倍,但对于大文件和同步模式，则几乎相当或略有提高。

　　另一项2008年的测试表明，在File Creation操作上，NFSv4甚至要慢于NFSv3.

　　究其原因，NFS是以支持"文件共享"为主要目的，侧重于多路并发访问条件下文件内的修改和同步控制。但是对于"文件传输"为主要目的的应用来说，这些额外的同步和锁机制就成为多余和不必要的开销。

　　那么Flickr为什么不用ＦＴＰ呢？FTP的主要问题是FTP需要两个端口，一个用于传输实际的文件，另一个用于传输控制命令。我们知道一台机器的端口（0-65535）是有限的，除去保留的系统端口外，真正能用的不过6万３千多个，而在一个高负载的，每秒成千上万访问的环境中，操作系统很容易出现“端口耗尽“的情况而拒绝新的连接。笔者曾经作过一个测试，在200个线程并发访问，每个线程平均５-10秒一笔交易下，30分钟左右,一台缺省配置的Windows 2003 Server就提示端口用尽。虽然可以通过调整Windows注册表或UNIX内核参数即减少tcp wait time的值来加快tcp端口的释放，但毕竟不如只用一个端口。

　　２。Web/PHP Server直连NetApp的另一个坏处我想大家都应该想到了，那就是应用层和存储管理层绑定的太紧。在直连的情况下，每一台Server都要Mount全部的NFS卷，而任一个NFS卷的故障都可能会影响到所有的Web服务器，或者至少每一个服务器在写操作之前，都要检查目标卷是否可用，如果标记为故障的话要选择并写到另一个卷；而且还要监控所有卷的使用情况，在卷剩余空间小于阀值或者文件数多于阀值时报警并将此卷置为”只读“等。

　　这些最终导致了专门负责存储管理和写操作的Storage Manager层的出现。Flickr为Web/PHP Server和Storage Manager之间专门设计了”轻量文件传输协议“。协议的主要编码规则如下：

　　请求：

　　|STORE|number files|{file1}|{file2}|{file3}|...

每一个{file}块的格式：

　　　　|filename|leading byte|file content byte length|file content|

leading byte的值是”file content byte length"字符串的长度。例如１MB的文件，file content byte length 是1048576,则leading byte的值是"1048576"的长度７.

　　响应：

　　|OK|volume number of where the file store| or

|Failed|the reason of failed|

协议本身是非常简单的，而且可以在一个报文里传输多个文件。而接受程序则根据文件长度直接截取文件内容，省去了诸如base64等编解码的开销。整个协议代码约600行PHP,包括opening，closing sockets, hot failover to redundant servers, and safe read and writes等.

　Web/PHP端的调用示例如下：

function store_file($storage_hosts, $filename){

shuffle($storage_hosts);

foreach($storage_hosts as $host){

$result = store_file_2($host, $filename);

if ($result){ return $result; }

}

return 0;

}

function store_file_2($host, $filename){

...

if ($connection_failed){

return 0;

}

...

if ($operation_failed){

return 0;

}

return $result;

}

　　代码中的storage_hosts既是Farm中的几台Storage Manager,和前面介绍过的db_query一样，上述代码也实现了简单而有效的load balance.

　　Storage Manager接受到文件后，将文件放入Offline Queue队列，再由专门的图像处理服务器进行整理，压缩和格式转化（如果需要的话），生成不同尺寸大小的文件，并通过NFS写入NetApp存储。虽然这一步仍然要通过NFS,但此时的操作已是非实时，效率的影响已经不大了。

　　应当指出，除非不得已，在绝大多数情况下，放弃成熟的公共协议而构建自己的私有协议并非上策。而笔者在文中列出的NFS和FTP的不足，也只是说明当前版本的NFS和FTP不适合于Flickr的特殊应用要求而已。 （NFS的优化不在本文讨论范围内，有兴趣的读者可以参考以下连接：[URL=http://media.netapp.com/documents/tr-3183.pdf

]NetApp的关于NFS Linux白皮书[/URL]和NFS-HOWTO）

　　那么有没有协议可以满足此类要求呢？个人认为值得关注的有：一。NFS4.1：NFS4.1版本将支持pNFS，即并行NFS,pNFS是近20年来NFS首次在性能上的重大升级,将可能成为高性能、共享文件存储的未来；另一个是SAN+Cluster FileSystem（如RedHat的Global File System和IBM的General Parallel File System)。传统上的SAN协议不直接支持多路并发写，而Cluster FS则弥补了这一缺陷为底层的共享块设备在文件系统级别提供并发的读写功能，因此更能发挥SAN存储架构的协议性能优势。有兴趣的话，大家可以看看这篇文章Red Hat GFS vs. NFS: Improving performance and scalability