作者文章: Fenng

云计算中的存储续

接上一篇。这其实是一篇综述文章 :)

是否该建设云存储服务?

可能有些企业已经在战略中加上了云计算这个关键字，问题是，真的需要那么多云计算么? 如果在技术上、规模化不能有效的节约成本，那么跟风建设云存储服务是缘木求鱼。更多的企业是自身的存储建设都远远不到位，大谈云存储无疑是痴人说梦。至少在国内，我们的基础建设还和国外有一段距离，而内容审查与一些政策上的限制又会增加建设、运营成本。

是否该使用云存储服务?

回答这个问题之前，我建议先看看服务提供方是否真的是云存储服务，如果只是炒炒概念，用老的架构支撑，换汤不换药，那还是谨慎为妙。企业如果不能从技术上做些本质突破而节约成本，那么成本肯定要转嫁到消费者身上，如果消费者不买单，那该服务如何能长久? 和我们现实生活中很多山寨 IDC 类比一下就知道了，动辄听到某主机托管商一夜之间蒸发，用户欲哭无泪的事情。

如果使用云存储服务，不妨和竞争对手使用同一家服务商。出问题的时候大家都出问题，保证始终处于同一起跑线。

在国内，短期内还看不到有规模的云存储服务商。由于网络的问题，企业用户也不太可能去使用国外的服务（不排除将来 Amazon S3 这样的服务能在国内提供服务）。期待在未来的一段时间能看到一些变化，但这恐怕只是乐观的想法。

云存储的潜在问题

数据安全

同样是数据存储到云存储服务商那里，如果我的隐私数据被泄露了怎么办? 业务数据被竞争对手盗用了怎么办? 消除用户的顾虑仍然需要时间。

网络带宽问题

只有数据没有网络，好比鱼儿没有水。如何保证大规模数据的有效分发与负载均衡，这也是云计算提供方与使用方都需要考虑的问题。

SLA 的问题

对于提供云计算存储服务的公司，用户很难看到他们严格执行SLA (Service level agreement) 。遇到大规模故障的时候，还做不到有效的为所有用户提供服务支持的能力。

云存储的钱途与前途

时值全球经济的寒冬，能够为用户省钱的服务相信也应该能够赚到钱。从用户的角度上看，云存储解放了自身的生产力，能够允许中小创业团队集中精力做发展业务，只要不形成恶性竞争，应该不用担心盈利的问题。

就以 Amazon的 S3 来说，基本上也很好的展示并实践了 Web 2.0 长尾理论：利用企业建设剩余的存储以及网络带宽能力而为广大中小网站提供服务，前途大好。相信 Google 推出类似服务也是指日可待的事情。但这个市场内应该不会出现过多的有力竞争者，有些存储厂商(比如 EMC) 也在进入这个领域，数据存储不是问题，但网络能力可不是那么好解决的事情。

云存储与传统存储：SAN 能否还能发挥余热?

从我们前面提到的云计算中的存储特点来看，SAN(存储区域网络)产品就暴露出一些不适合的应用场景，毕竟 SAN 是面向集中式计算的架构。另外，大家也都知道 SAN 产品一般不便宜(现在也有厂商在力推低端海量存储产品，后面会介绍)，而且，主机端如果用 HBA 卡，也会进一步提高成本；SAN 面向传统企业应用而设计的扩展能力难以满足云计算的需求。

目前尽管已经有一些企业在做集群存储然后打包出售，但相对还是在起步阶段。至少现在还看不到真正集群 SAN 产品的出现。当然，如果对云计算的存储部分不计成本的话，SAN 仍然可以在云计算中发挥一些作用，这倒是中了存储厂商的下怀。

不管怎么说，RAID 这个 SAN 中的概念在云存储中已经绝对不适合了。

集群 NAS 是否真的有机会 ?

有业界评论说集群 NAS 可能会演变成云存储的通用架构，我怀疑这是不是 Sun 公司的宣传手段，因为这事实上宣布了 ZFS 将是云存储中的一个关键点。

从现有的情形看，或许会有越来越多的在线存储服务拥抱集群 NAS 。但这不代表集群 NAS 前途光明能够在云存储大展拳脚。集群 NAS 最大的问题是海量数据的寻址是个麻烦事儿，然后是扩展性与容错性的问题，底层的容错性如果通过硬件来做，那么成本无疑会上升，这恐怕是企业不愿意接受的。

分布式文件系统

在开源领域，以 MogileFS 为代表的分布式文件系统能够用于一些相对规模较小的分布式存储场景，很多 Web 2.0 自己的分布式存储就是借鉴 MogileFS 搭建的，不过毕竟 MofileFS 的Meta 信息仍是集中存储、管理的，在更大规模恐怕有些吃力。

此外，Kosmosfs（http://kosmosfs.sourceforge.net/）、Lustre(http://www.lustre.org) 等也都在不断发展中，相信能够给有兴趣研究云存储的技术人员一些借鉴。也有一些软件厂商将其专有的分布式文件系统和存储打包在一起销售，而存储厂商也有的在结合自己的存储产品做一些尝试。目前还很少有相对成熟度的东西进入用户视野。

更多分布式文件系统列表参见维基百科的文件系统列表介绍。

分布式文件系统举例：拥抱开源 Hadoop 的 HDFS

尽管我们接触不到 Google 大名鼎鼎的 GFS （Google File System），但我们能免费获取 Hadoop 的 HDFS (Hadoop Distributed File System)。HDFS 相对上述的 ZFS 来说，属于专门针对廉价硬件设计的分布式文件系统，在软件层内置数据容错能力。Hadoop 目前的案例多数用在数据分析与并行计算上，倒是很少看到有支撑给互联网应用的数据服务，但相信随着其在开放环境中的快速成长， Hadoop 将不断壮大。

（HDFS 架构示意图. from: http://hadoop.apache.org/core/docs/current/hdfs_design.html 关于 Hadoop 也请参阅《程序员》杂志 2008年10月刊的文章。）

速成版存储方案成本评估

云计算中存储的起步容量，我们不妨按照 1PB 可用空间来准备。近年来，随着磁介质存储能力的提升，企业存储的价格也是一降再降，$2.00/GB 的底线早已突破，现在Sun 的Thumper 声称可以达到 $1.20/GB 的成本。(注：企业存储[不是个人消费品]的磁盘价格一降再降，而且有很重要的商业因素，具体的成本应该还要更低一些，只是不知道哪位朋友有更为准确的数字)

粗略估算一下，2PB 的原始容量成本大约是 250 万美元左右(List Price)。单位机柜空间密度最高的已经能够做到4U的机存储48TB的原始容量(目前能看到密度最高的了)，这样最小只需要大约 45 个 4U 的机柜空间。其他方面，加上本地的工业电力价格，大致的硬件总体开销还是可估量的。软件方面，这个存储本身是基于 Sun 的 ZFS，内置的操作系统，成本也是可以控制的。

山寨云存储方案设想

在山寨精神盛行的今天，没准儿已经有人在搭建一套山寨版的云存储方案呢。比如目标定在 1PB 可用容量，预计至少需要如下的东西:

选择廉价的刀片服务器(自己”生产”就不必了)，内置足够多的大硬盘，硬盘速度无所谓，预计每台机器预装4T容量(1T*4，坏了就整台机器替换)，大约需要 500台服务器，总容量2PB，确保每一份数据都至少冗余在另外的物理机器上，冗余后，起码能得到1PB容量(如果备份的数据启用压缩，没准儿能提供更多空间呢)。机架物理空间怕是需要 1000 U多一些，每个标准机柜是42U，怎么也要准备 25 个机架吧，再加上网络交换机什么的… 然后是电力与空调散热问题。

再弄一套 Hadoop ，定制一下跑起来 …当然，山寨与否，关键是拼技术团队，一味的拿来主义注定只能跟风。

其实，这篇文章也是一篇山寨文。

–EOF–

云计算中的存储

这是去年发在《程序员》杂志的一篇文章。当时写得比较急，现在看起来，有些观点有些武断。仅供参考。

引言, “The one that is without any tradeoff is to have the logical storage master up in the cloud” by Bill Gates.

2008 年的 IT 界，云计算是个热词。很多企业都在宣称自己提供云计算服务，很多人也都在讨论云计算(一些明显是凑热闹的，比如所谓的”云安全”)，从业界公认的几种云计算的服务能力看，都绕不开存储这个基础支撑组件，dSaaS(data-Storage-as-a-Service) 更是把存储提到了首要的位置。而从我们目前能得到的信息来看，在存储层已经解决很好的，恐怕也只有 Google 和 Amazon 两家，至于其他公司可能都还在路上，即使是微软，尽管也有自己的 Dryad ，但是实际上，仍然处于理论阶段，产品化的路还有点距离。

上面表格中的举例仅仅是为了举例，如果某家已经 “云计算了” 的公司大名不在上面，并非该公司”云”的不够彻底，应该只是笔者眼光差的原因而已。

越来越迫切的信息存储需求

根据 EMC 公司赞助 IDC 进行的研究计划 “Digital Universe” 的分析报告，在整个 2007 年，我们这个世界生成、占用的数字信息及复制总量大约是 281 Exabytes (1 Exabytes=1024 Petabytes ，1 Petabytes = 1024 TB 这里换算都按照二进制的换算)，这个数据平摊到地球上的所有人，大约是每个人 45 GB的数据；截至到笔者写稿的时候，2008年到现在整个世界已经生成了大约 374 EB 的数据（可以到 “Digital Universe” 页面查看最新的数据，也可以下载一个评估工具，看看自己产生的数据是大约如何）；到 2011 年，每年产生的数字信息大约是 1800 EB，10倍于2006 年产生的信息量。做为对比，Google 每天处理的数据大约是 20 PB 的样子，Google 的目标是要组织所有的信息，看来并非易事。

其他可参考数据：据美国国家档案馆工作人员估计，布什政府电子档案存储量大约为1亿GB，这一数字约为前总统克林顿两届政府档案总量的50倍，是国会图书馆2000万册编目图书内容总量的5倍。

每年激增如此庞大的信息量，加上已有的历史数据信息，对整个业界的数据存储、处理带来了很大的机遇与挑战。通过该研究能看出，在可用存储之间与信息生成总量之间不是严格匹配的，一方面多媒体领域信息增长过快，一方面因为不合理的存储分配、占用情形比比皆是。例如研究表明一封大约 1M 的邮件发出后，经过不同服务器的存储、备份、归档等最后总体占用空间竟然达到惊人的 50M 之多。正如云计算的初衷是为了充分发挥计算机闲置资源，提高总体使用率以便达到经济效益，云计算中的存储方面也应该能有效提高存储利用率而进一步创造价值，盲目的复制、堆积数据是没有出路的。工业界提倡节能减排，其实 IT 界应该提倡一下节约存储了。

什么是云存储 ?

其实，什么是云计算都很难有一个权威的定义，笔者在这里更愿意把”云计算中涉及的存储”简称为云存储(Cloud Storage)。云存储本身离不开云计算，更多的时候云存储是做为云计算的一个支撑组件。

云存储不是简单的在线存储或是网络硬盘，在线存储服务只是云存储能够提供的众多服务中的一种而已。

云存储的特点

云存储至少应该能够具备如下特点：

高可靠性

谈到存储，可靠性还是要排到第一位的。没有人喜欢买三天两头坏掉的硬盘，代表高科技形象的云存储可靠性也要加强。

高可用性

如果云存储服务不是针对在线用户的，那么没有什么实际意义，如果针对在线用户，不具备足够高的可用性也是没有意义的。Amazon 的 S3 服务给足够多的 Web 2.0 企业解放了在硬件存储上的压力，但是偶然的一次宕机会影响所有的 Web 2.0 用户；

低成本

云存储本质上还是规模化经济。如果成本不能有效的控制，那么云存储对厂家、对用户来说是没有意义的；

高扩展性

云存储组件应该具有足够高的扩展性，应该能够通过在线扩充存储单元进行有效的平滑线性扩展；

自动容错能力

因为低成本的，存储组件的损耗率应该很高，云存储厂商应该能在软件层做到自动容错而不是依赖硬件本身的容错；

易管理性

构建云存储系统，可管理性应该在设计之初就要考虑到，如果管理太复杂，很难做到低成本，稳定性、可靠性也会受到挑战。

去中心化

对元数据的管理不应该通过少数或者单一的管理节点来操作或者存储。

云存储的关键技术与服务形式

要建设成功的云存储系统，高扩展性、高可靠性的分布式文件系统是一个关键因素。而硬件问题反而是次要的。

云存储的服务形式见上表。

未完待续…

关于 SSD 的闲言碎语

前不久写给《程序员》的一篇文章里，个人预测在 2009 年，SSD (Solid-State Drive，固态盘) 在企业级市场能大展拳脚。上周参加了 EMC 的一个会议，提及了 SSD ，EMC 存储产品对 SSD 的引入也有一年了，做点 SSD 的科普知识应该是有必要的。

Wear Leveling

很多人对 SSD 的误解是：既然你可擦写次数有限制，比如 200 万次，那么不是没几天不久坏掉了，怎么说使用寿命还比物理硬盘长呢?

Wear Leveling 是有效提升 SSD 的 MTBF (Mean Time Between Failures)的一种技术手段。我们都知道木桶原理，对 SSD 硬盘也是这样，如果不停的对某个 Cell 擦写，那肯定很快就报废。 Wear Leveling 的基本思想就是利用算法保持所有的可擦写单位的次数是近似均匀的，这样就把写次数均匀的分散到各个 Cell 上。

Wear Leveling 翻译似乎还没有统一，有翻做均匀磨损、磨损分级、换位写入等。

对 Wear Leveling 粗略一点的描述大致是：假设更新某个数据块，假定8KB ，而可擦写块(erase block)是 256 KB，那么定位到当前数据位置后，将找个没写过或者写过次数更少的可擦写数据块写入，并不是对原来的位置反复更新。Wear Leveling 算法的效率直接影响 SSD 的寿命。

而 8K 到 256 KB 这个过程实际上是加大了 I/O 操作，称之为 Write Amplification (写放大)。当然 SSD 厂家另有其他技术尽量减少写的频率。

为什么 SSD 写入速度相对较慢?

用一句话解释：擦写块(erase block)比较大。

很明显这样做的目的是减少擦写次数，提升 SSD 寿命。但也影响了数据写入速度。

为什么 SSD 容量是 2 的幂次? 比如 32GB，64GB

这个我也不甚了了，猜测是因为 erase block 多数是 2 的幂次的缘故。物理硬盘的尺寸由来我也不甚清楚。

SSD 的擦写次数是不是致命的瓶颈 ?

这个问题太容易给用户带来疑惑。个人认为要依赖应用的特点和设计。对于合适类型的数据，基本不是问题。但对于某些特定的数据类型，那可能是灾难(比如数据库的 Redo Log)。

SSD 会给数据库应用的银弹么?

是曙光，但不会是银弹。对于密集写入的数据库应用来说，SSD 可能不会带来更多的好处。但是对于密集读的应用，那是有可能带来数量级上的性能提升。在未来若干年内，好的数据库应用仍然严重依赖于设计人员的能力和数据库管理员的优化技巧。

此外，还要期待数据库厂商针对 SSD 进行软件级别的优化。

是否从现在选择 SSD ?

典型的废话答案应该是：这取决于你的具体情况。

要看性价比，EMC 最早引入的 SSD ，性能是普通硬盘的 30 倍，价格大约也是 30 倍。而现在，在企业级市场，SSD 已经降到大约 10 倍普通硬盘的价格。如果再低一些，那绝对是比较有吸引力的。

–EOF–

其中观点仅供参考。SSD 有风险，玩家谨慎操作。而这篇文章中的有些观念有实效性，细节也可能不够准确。

Note: 这里的 SSD ，是说面向企业应用而不是面向个人消费品的。

再增加一个图：
SSD vs. HDD.png

关于移动 Web 设计的闲言碎语

前几天 3G 牌照下来，一时间 Buzz 信息很多，不过关于 3G 对 Web 技术影响的分析倒是并不多见。今天再次读了一遍这篇 2009 移动 Web设计趋势 (Mobile Web Design Trends For 2009)，加上这几天在分析使用 iPhone 上的某些 App 设计，还是记录一点笔记吧。

这篇文章提到了如下五点：

简单的可选项(Simple options) 如无必要，勿增实体。基本的、核心功能就行了。
留白(White space) 我觉得 UCWeb 针对 iPhone 的设计就很一般，完全是把 iPhone 当成小屏幕显示器设计的。堆砌的网址站看起来不方便，点击起来并不方便，倒是应该弄个 LOGO 或许更好。
少用图片(Lack of images) 这倒是和上一条矛盾。能少用就少用，而不是不用。而用了图片，如果方式不合适，还不如不用。
用子域名而不是用 .mobi 域名(Sub-domains instead of .mobi or separate domains) 精简域名长度，精简！用 “i.” 就很好，别用 “mobile. “。
内容优先(Prioritized content)

只有设计是没有用的。

我的额外建议：

可点击的目标锚点一定要大。因为你的手指肚更大 :) 如果一个手指尖范围内还有其它可点击目标，很容易误点。最简单的方式就是看看 iPhone 自己桌面菜单设计。而我之所以说 Taobao 商城 iPhone 版设计的不错，也是因为这一点考虑得很地道。Gmail for iPhone 的设计上，用户浏览邮件内容的时候，那个 “Inbox” 的按钮就设计的非常不好。很容易误点击到 “Archive” 按钮上。
分页设计 对于分页的链接，一定要隔开一些，如果”上一页”、”下一页”挨在一起，用户会很困扰。毕竟，手持设备没有鼠标，用户不可能具备”精确点击”的能力。
登录框设计 在 iPhone 上登录某些站点是非常痛苦的一件事情。可考虑的事情：如果用户 ID 是邮件地址的话，是否考虑无需用户输入”@” 字符? [iPhone 2.2 固件已经改进了许多]

另外，2009 移动 Web设计趋势 (Mobile Web Design Trends For 2009) 还提到了设计中的常见挑战以及需要慎重考虑的地方，这篇文章信息量还是挺大的。

–EOF–

唠叨完了，发现基本上是针对 iPhone 说事儿的，我还不是标准的移动互联网用户。