Tag Archives: Arch

闲谈 Web 图片服务器

现在很多中小网站(尤其是 Web 2.0 站点) 都允许用户上传图片，如果前期没有很好的规划，那么随着图片文件的增多，无论是管理还是性能上都带来很多问题。就自己的一点理解，抛砖引玉，以期能引出更具价值的信息。

事关图片的存储

把图片存储到什么介质上? 如果有足够的资金购买专用的图片服务器硬件或者 NAS 设备，那么简单的很；如果有能力自己开发单独存储图片的文件系统，那么也不用接着往下看了。

如果上述条件不具备，只想在普通的硬盘上存储，首先还是要考虑一下物理硬盘的实际处理能力。是 7200 转的还是 15000 转的，实际表现差别就很大。是选择 ReiserFS 还是 Ext3 ，怎么也要测试一下吧? 创建文件系统的时候 Inode 问题也要加以考虑，选择合适大小的 inode size ，在空间和速度上做取舍，同时防患于未然，注意单个文件系统下文件个数别达到极限。

独立，独立的服务器

无论从管理上，还是从性能上看，只要有可能，尽量部署独立的图片服务器。这几乎成为常识了(不过在我做过面向 Web 的项目之前就这个问题也被人笑话过)。具备独立的图片服务器或者服务器集群后，在 Web 服务器上就可以有针对性的进行配置优化。比如采用传说中更有效率的 Lighttpd 。

如果不想在几台机器间同步所有图片，只用 NFS 模式共享一下即可。注意软、硬连接可能带来的问题，以及 NFS 特定的传输速度。

独立，独立的域名

如果大部分 Web 页面必须要载入很多图片，那么需要注意 IE 浏览器的连接数问题(参见对该问题的测试)。

前几天有个朋友在线上问我，”一些大网站，图片服务器为什么都用另外一个域名? 比如yahoo.com 图片服务器用了 yimg.com 的域名?” ，粗糙一点的答案：除了管理方便，便于CDN 同步处理，上面说的 IE 连接数限制也是个考虑因素吧(其他原因我也不知，有请 Yahoo！的同学发言) 【还有一个我没考虑到的是 Cookie 的因素，参加楼下高春辉的留言】

雅虎 Web 优化 14 条

关于雅虎 YSlow 工具倡导的 优化 14 条规则，建议每个 Web 维护人员必须倒背如流，当然也应该辩证来看–介绍这 14 条规则的页面本身也只能得到 70 多分…其中的第九条和上面说的独立域名之间多少有些矛盾。实际情况要根据自己的 Benchmark 与具体需求而确定了。

有效利用客户端 Cache

很多网站的 UI 设计人员为了达到某些视觉效果，会在一些用户需要频繁访问的页面模块上应用大量的图片。这样的情况，研究表明，对于用户粘度比较高的站点， 在Web 服务器上对这一类对象设置 Expires Header 就是十分有必要的，大量带宽就这么节省下来，费用也节省了下来。顺便说一下，对于验证码这样的东西，要加个简单的规则过滤掉。

服务器端的 Cache

在国内，CDN 也是有钱才能玩得起。而类似 Amazon S3 这样的一揽子存储服务，国内还没有出现。所以，充分利用服务器端的 Cache 也是有必要的。Squid 作为反向代理服务器，缓冲图片效果应该说尚可，新浪技术团队贡献的 Ncache 据评测，效果更佳。

服务器端做Cache的好处是显而易见的，一个数据对象的请求时间会控制在 100ms 以内，否则的话，至少要几百个 ms 甚至更长。

高解析图片问题

如果网站存在大量高解析度的图片，那么有必要考虑部署 IIPImage 或者类似的软件。

运营问题

很多比较有规模的网站对于用户上传的图片不做任何处理，结果页面上还能看到很多 BMP 格式的图片(个人觉得任何网站出现 BMP 格式的图片都是可耻的)…这完全是运营上的策略之误了。找个程序员投入一点时间写个图片处理模块，对那些”截屏”得来的图片做个转换，投入成本可能远比存储上的开销小，而用户再访问该图片，质量未必能有什么损失，浏览速度无疑好多了。哪种处理方式更让人接受，不言而喻。

–EOF–

图片处理工具的选择

可能大多数网站都是选择 ImageMagick 做为基础库，不过这里也有一篇 GraphicsMagick 1.2 vs ImageMagick 6.3.6 Benchmark Report，如果图片处理量巨大，性能问题又怎能不考虑?

Lighttpd 的 ModCache 模块非常值得推荐。

Updated: 对于创业团队来说，推荐又拍云服务，用了都说好。

有关 Alexa 与 AOL 部署集群文件系统

这两天关注了一下基于 SAN/NAS 的集群文件系统的产品。找到了关于 Alexa 的一则旧闻，之后又发现了一篇关于 AOL 部署 SAN 文件系统的文章。

Alexa 的相关数据

Alexa 超过 1000 台 Linux 服务器 Farm，每半年增长 300T 新数据。经过了同类产品的选型后，最后选择了 Ibrix 融合文件系统。

SAN 使用的是 HP Modular Smart Array (MSA1000) ，最大支持 12T ，Cache I/O 最大 3 万个，算是个中低端的阵列。Amazon 没有透漏这套系统的吞吐能力，只是说 Ibrix 这套系统能达到 1T 的 I/O 聚合能力，单个 NameSpace 可达 16PB 容量。

不过从现在的一些迹象上来看，Amazon 对存储层重新做了改造。这套解决方案被替换掉了也说不定.

AOL 的相关数据

原有状况：3000 台主机通过 10000 多个光纤通道端口连接到传统的 SAN 上。其中有 8PB 的非结构化数据，分布在大约 1000 台 文件服务器上。管理维护的复杂度可想而知。

解决方案：文件服务器采用直连的磁盘，每个 12 块 700GB 的 ATA 磁盘，然后通过 Ibrix 融合文件系统进行集群化。

看起来，Ibrix 提供的解决方案很有竞争力。现在一些比较大的用户对于存储层的集群的需求越来越多，快成为趋势，一揽子解决方案还是有必要的，毕竟不是每家技术能力都强如 Amazon、Google ，有的时候用第三方的成本是能小于自己动手 DIY 的。

–EOF–

eBay 的存储一瞥

前年在帖子里介绍过 eBay 数据量超过 2PB，这么大的数据量管理和规划是需要一些艺术的，可惜网络上能得到的信息太少。最近又找到一篇关于 eBay 存储的介绍，这篇文章通过访问 William Crosby-Lundin (这位老兄现在已经跳槽到 SalesForce了)披露了一些数据，虽然该文距离现在有一年了，还是对我有不少参考价值。

eBay 存储团队当时 12 个人，管理 13 套存储，总容量 2PB 左右(不要刻舟求剑，现在超过 8 PB，2008-08-04） 了，8000 个左右光纤口，可用性 99.94%，工作量肯定不小。每周要起用 10TB 存储，这些存储有 75 个 LUN(也就说平均每个 LUN 135GB 左右，这个数据有些怪异)。连接到 SAN 环境的主机大约有 1000 台，数据库集群有 600 个左右，据我所知，这里的集群应该只是指 Data Guard。

这么多的数据库，I/O 开销肯定不小，如何消除存储热点呢? 该文只是笼统的说通过存储层与主机层的数据分片达到的。如果应用上 I/O 均衡做的好一些，可能存储热点问题不会成为瓶颈。

这个存储环境的部署应该有好几年了。所以最近一两年比较火爆的存储虚拟化与 Provisioning 技术都没有大规模起用。个人觉得 eBay 这么大的数据量， Provisioning 技术对于 eBay 的环境会是比较适合的。

有的时候，盲人摸象也是一种乐趣呀。

补充一下，超过 140 套集群。另外，提醒一下，这些数据是随着时间而变化的。切莫刻舟求剑。

–EOF–

Refer :

Our systems process in excess of 20 billion newly added records per day, 40TB being added every 24h, serving thousands of users and delivering hundreds of millions of queries per month in a true global 24×7 operation with distributed teams around the globe on systems over 8 PB in size (largest cluster >3PB), processing more than 30 PB of data per day.

Yupoo! 的网站技术架构

又有机会爆料国内 Web 2.0 网站的架构了。这次是 Yupoo! 。非正式的采访了一下 Yupoo!(又拍网) 的创建人之一的 阿华（沈志华）同学，了解了一些小道消息。

作为国内最大的图片服务提供商之一，Yupoo! 的 Alexa 排名大约在 5300 左右。同时收集到的一些数据如下：

带宽：4000M/S (参考)
服务器数量：60 台左右
Web服务器：Lighttpd, Apache, nginx
应用服务器：Tomcat
其他：Python, Java, MogileFS 、ImageMagick 等

首先看一下网站的架构图：

Yupoo_Arch.jpg

该架构图给出了很好的概览(点击可以查看在 Yupoo！ 上的大图和原图，请注意该图版权信息)。

关于 Squid 与 Tomcat

Squid 与 Tomcat 似乎在 Web 2.0 站点的架构中较少看到。我首先是对 Squid 有点疑问，对此阿华的解释是”目前暂时还没找到效率比 Squid 高的缓存系统，原来命中率的确很差，后来在 Squid 前又装了层 Lighttpd, 基于 url 做 hash, 同一个图片始终会到同一台 squid 去，所以命中率彻底提高了”

对于应用服务器层的 Tomcat，现在 Yupoo! 技术人员也在逐渐用其他轻量级的东西替代，而 YPWS/YPFS 现在已经用 Python 进行开发了。

名次解释：

  • YPWS–Yupoo Web Server YPWS 是用 Python开发的一个小型 Web 服务器，提供基本的 Web 服务外，可以增加针对用户、图片、外链网站显示的逻辑判断，可以安装于任何有空闲资源的服务器中，遇到性能瓶颈时方便横向扩展。
  • YPFS–Yupoo File System 与 YPWS 类似，YPFS 也是基于这个 Web 服务器上开发的图片上传服务器。

【Updated: 有网友留言质疑 Python 的效率，Yupoo 老大刘平阳在 del.icio.us 上写到 “YPWS用Python自己写的，每台机器每秒可以处理294个请求, 现在压力几乎都在10％以下”】

图片处理层

接下来的 Image Process Server 负责处理用户上传的图片。使用的软件包也是 ImageMagick，在上次存储升级的同时，对于锐化的比率也调整过了(我个人感觉，效果的确好了很多)。”Magickd“ 是图像处理的一个远程接口服务，可以安装在任何有空闲 CPU资源的机器上，类似 Memcached的服务方式。

我们知道 Flickr 的缩略图功能原来是用 ImageMagick 软件包的，后来被雅虎收购后出于版权原因而不用了（?）；EXIF 与 IPTC Flicke 是用 Perl 抽取的，我是非常建议 Yupoo! 针对 EXIF 做些文章，这也是潜在产生受益的一个重点。

图片存储层

原来 Yupoo! 的存储采用了磁盘阵列柜，基于 NFS 方式的，随着数据量的增大，”Yupoo! 开发部从07年6月份就开始着手研究一套大容量的、能满足 Yupoo! 今后发展需要的、安全可靠的存储系统“，看来 Yupoo! 系统比较有信心，也是满怀期待的，毕竟这要支撑以 TB 计算的海量图片的存储和管理。我们知道，一张图片除了原图外，还有不同尺寸的，这些图片统一存储在 MogileFS 中。

对于其他部分，常见的 Web 2.0 网站必须软件都能看到，如 MySQL、Memcached 、Lighttpd 等。Yupoo! 一方面采用不少相对比较成熟的开源软件，一方面也在自行开发定制适合自己的架构组件。这也是一个 Web 2.0 公司所必需要走的一个途径。

非常感谢一下 Yupoo! 阿华对于技术信息的分享，技术是共通的。下一个能爆料是哪家?

–EOF–