学习 Flickr 的 基于 LAMP 的容量规划经验

作者: Fenng | 可以转载, 但必须以超链接形式标明文章原始出处和作者信息及版权声明

网址: http://www.dbanotes.net/web/flickr_lamp_capacity_planning.html

好久没怎么正式更新 Blog 了，快荒芜了，长满了 Spam 的荒草。

最近其实发现了不少可以和大家一起学习的好内容。Flickr 的 John Allspaw 在 MySQL Conf 2007 作了一个题为 Capacity planning for LAMP (下载PDF文件) 的技术报告，说起容量规划，多少有点空对空的意思，不过这个 PPT 还是介绍了不少 Flickr 的网站运维经验。

Flickr 的数据量的确越来越惊人了，根据文档中透漏的数据：

Squid Cache 中共有 3500 万张图片；
在 Squid RAM 中有 200 万张图片；
4.7亿的图片，每张图片有4到5种尺寸；
每秒钟 38000 个到 memcached 的请求;
2 PB 裸存储容量(周日需要消耗1.5T 的空间)

三个主要步骤：

计划

基于实际业务，而不是抽象的理论。John Allspaw 认为基准测试(Benchmark) 作用并不大，这一点我也很赞同。在业务频繁变化的环境中，Benchmark 根本不能与实际业务情况匹配。

部署

Flickr 使用SystemImager/SystemConfigurator(自动化安装、软件分发)，CVSup(网络中的文件分发、更新)，Subcon(配置管理工具)提高部署效率。

度量(图形化展现)

Flickr 使用了 Ganglia 来进行容量数据的展现。Ganglia 最初设计是用于高性能集群计算的监控上面，也是以 RRDTool 为基础来进行图形展示。Ganglia 最主要的优点还是管理的方便性: Client/Server 结构, 各自跑 Demon 进行数据交互(XML形式)。相比起来， Cacti + Collectd 需要进行很多手工配置，在面对大量需要监控的主机的时候的确不那么方便。

 

Web 2.0 站点的运维似乎大家都在摸索着走。期望这次阿里巴巴组织的侠客行大会上也有有朋友坐下来聊聊这个话题(Flickr 的架构师本来可以来的，因为时间的问题不能成行，挺遗憾的)。

相关文章：

• Flickr Stats 功能的设计经验
• 再跟 Flickr 学习网站运维经验
• LAMP 与 LAOP
• 从 Flickr 的 DB 服务器配置说起 Swap
• Flickr 测试