Tag Archives: Storage

有关 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.

关于 EMC 高端存储支持 SSD

EMC_logo_large.gif

这几天存储行业比较大的一个新闻是 EMC 宣布在高端 Symmetrix 产品支持 SSD (固态盘, Solid State Drive)，注意是基于闪存(FLASH)的固态盘。不到半年前，和一些存储厂商的朋友提及 SSD 仍有人不知为何物，现在似乎一夜之间 SSD 到处都是了。EMC 虽身为市场的领先者，也敢于吃螃蟹，来者不善。

STEC.jpg

EMC 这次采用的 SSD 是 STEC 公司 Zeus-IOPS 产品线的产品。这一型号号称随机读操作的 IOPS 能达到 52000 个，采用 SLC (single-layer cell )，写也可以达到 17000 个 IOPS。只从这个数字看，单块 SSD 的性能是机械硬盘的 30 倍还多。在可靠性上，SETC 据说实现了 ECC 机制.

现有的机械硬盘的虽说在单位容量上还在不停的增加，但是性能基本上是到了瓶颈，即使用于高端存储的高速硬盘，IOPS 的能力基本上也就是 150 个左右。而 SSD 单块就能提供几万个 IOPS ，且耗电量极小，平均故障间隔时间(MTBF)又是普通硬盘的10倍之多, 这对以期得到高 IOPS 的 DBA 来说, 简直是银弹。

但是(什么都怕这个”但是”)，但是 SSD 的有它固有的缺点。其中一个就是可擦写次数(这个在几个新闻稿里面可算是一笔带过的)，尤其是基于 Flash 的 SSD。传统磁盘虽然有它的缺陷，但是可擦写次数几乎是无限次的。

听听来自竞争对手的声音或许也能让我们多点心眼。HDS 的 CTO Hu Yoshida 在 Blog 上撰文，提出了他对 SSD 能否被市场接受的三点疑问：

  • 1) 价格因素：SSD 大约是普通磁盘驱动器的 30 倍.
  • 2) 磁盘供应商多数是初创公司，主流磁盘生产厂家并没有上阵呢.
  • 3) Flash SSD 可擦写次数有限.

如果说前两条只是竞争对手的 FUD 的话，那么最后一条还是会令 EMC 销售很头疼，如何让客户消除这个疑虑是有些难度的。STEC 官方的技术参数是可擦写次数能达到 200 万次。这样看的话，在高端存储上用 SSD 还是有比较合适的应用场景：在 EMC 提倡的 “智能分层存储” 前提下由 SSD 提供密集读的操作能力。

–EOF–

37Signals 架构

如果没有 37signals ，恐怕也没有 RoR 的如此流行。37signals 对于很多 Geek 来说，是一家非常迷人的公司。他们是网络上的另类新星。

37Signals 在 Signal vs. Noise 上披露了比较详细的运营数据，Ask 37signals: Numbers?

存储数据量

截止到 2007 年 11 月，总存储量统计：

  • 5.9 T 用户上传的数据
  • 888 GB 上传文件 (900,000 请求)
  • 2 TB 文件下载 (8,500,000 请求)

这包括 Basecamp、Highrise、BackPack、Campfire总的数据统计。总的用户量其实并不多，只有 200 万。

这些数据存放在 Amazon S3 上，37Signals 用了这个服务已经一年多了，他们对此比较满意。事实上，Amazon S3 已经成为 Web 2.0 分布式存储的既定事实的解决方案。

服务器状况

37Signals 当前正在部署虚拟化软件产品，当然不用 VMware，而用开源的 Xen。当前大约有 30 台服务器，从单 CPU 的文件服务器到 8 CPU 的应用服务器都有，总共 100 颗 CPU、200GB 内存。预计 XEN 部署完毕后，服务器数量降低到 16 台，92 颗更快的 CPU、230GB 的内存量。这样做的主要目的是管理起来更方便(至于性能是否更好，我个人还是有点怀疑的–Fenng)。

关心 ROR 以及具体一些策略具体实现的朋友不防去看看那个帖子下面的留言。

之前还真的很少有听说哪家 Web 2.0 公司部署 XEN 的，37signals 的这个动作或许是个积极的信号。2007 年也是个”虚拟化”年，相信随着虚拟化的技术成熟，开源力量的壮大，会有更多的公司收益于 XEN 虚拟化架构.

–EOF–