Results tagged “Storage”

Western Digital 在推进一项技术变革，Advanced Format(PDF)，将延续近30年的硬盘传统的512字节扇区变更为4K大小。

传统的格式如下图，绿色部分为 ECC (Error Correcting Code)区域。一般来说，每存储1000位(bit)的数据就会有产生一个物理错误，所以必须要有一个可靠的校验机制。这也是 ECC 必不可少的原因。

每 512 字节用一个 ECC 区，占用 40 字节做错误矫正代码，这在需要存储大数据量的时候，显而易见是比较大的物理空间开销。而将扇区扩大，使用一个相对比较大的 ECC 区也是同样可以达到安全存储的目的。

如果使用 4K 的扇区，则大约需要 100 个字节的 ECC 区域就行了。空间收益大约是 7-11% 。对于存储工业来说，这是惊人的。当初设计硬盘规格的时候，估计研发者是无法预见到信息如此迅速膨胀的今天的，512 字节已经不太适应现在一个平均 I/O 的大小。

值得注意的是，这个变更更多是在空间上的收益，在性能上的收益还不确定，当然不会变得更差，至于是否有提高，能提高多少，要看具体的场景。另外，也不会提高硬盘的可靠性，每 12.5TB 的数据依然会有一个不可恢复的读错误。(refer) 。4K 扇区其实在数年前就被提出来，只是最近 Western Digital 才真正的推动，估计是因为磁盘容量要保证每年的增长率带来的压力。

使用该技术对或许企业级服务器用户并不会有什么太大的风险，Western Digital 同时也在固件层提供对传统的 512 byte 扇区的模拟方式。另外，也可以下载这个官方校正工具。对于个人用户来说，多少还是有点影响的，尤其是使用克隆软件安装 Windows XP (Windows 5.x )以及更低版本的操作系统的用户可能要注意一下。

4K 是个有趣的数字，还记得 4K偏移量的问题么？

未完，待补充 ...

延伸阅读：

• How to 4k Align Flash on Solaris x86

对于国内存储市场来说，3PAR 是不折不扣的后来者。也是个相对陌生的存储产品，以至于其竞争对手的人员甚至都不知道这家公司已经杀入中国市场。

3PAR 在 1999 年成立，几个创始人主要出自 Sun ，前身叫作 3PARdata ， 2008 年上市。要知道在存储技术领域竞争还是比较激烈的，EMC / HDS 等控制着高端存储的主要市场，3PAR 能突破技术壁垒并最后成功上市，没两把刷子那是绝对做不到的。

InSpire 硬件结构

3PAR 背板采用全网状的连接结构，每个控制器节点之间高速直连。因为是全网状的，所以基本上一个链路坏掉只影响直连的两个节点的通信，对其它节点无影响。每个控制器节点内置一块硬盘，用于操作系统安装。控制器节点最多可以扩展到 8 个，是 3PAR 存储最核心的组件。

相比之下，HDS 架构采用全光线交换方式（Universal Star Network），而 EMC 是采用直连矩阵方式(新一代产品采用虚拟矩阵架构--Virtual Matrix ，其实已经放弃了直连矩阵架构了)。这些连接方式的孰优孰劣历来是厂商攻击竞争对手的着眼点，能否最大限度发挥性能是用户最需要关心的。

3PAR 针对 I/O 指令和数据移动使用不同的计算芯片。I/O 指令(元数据/控制Cache)用 Intel 的芯片，而 数据移动/Cache 则使用专门设计的 ASIC 芯片来完成。

因为有专门的硬件 ASIC 芯片用于 RAID 5 XOR 校验，3PAR 号称有了其第三代 ASIC 芯片，实现的 RAID 5 是业界最快的，甚至 SATA 盘也能有不错的性能表现。(从 Oracle 公司测试的数据来看，和 RAID 10 速度的确相差无几。)

InForm 操作系统软件与虚拟化

3PAR 的操作系统叫 InForm，最初就是面向层次化的设计。与其他存储不同的是，3PAR 所有磁盘被分成 256MB 统一大小的小盘(Chunklet)，可以根据需要用多个 Chunklet 组成 RAIDlet(逻辑磁盘)。因为这个独特的设计方式，3PAR 是可以很容易做到不同容量的磁盘混用，同一个 RAID 组里都可以有不同大小、不同转速的磁盘混用，这是其他存储做不到的。而且，所有的磁盘都可以利用，因为Hotspare Chunklet 以更小的单位分散在不同的磁盘上，也不再需要单独留热备盘。空间利用率可以更充分一些。　

多说一句，有这个冗余机制，3PAR 更换磁盘也是与众不同：直接抽磁盘盒子(一个盒子可是四块磁盘啊)，我当初看到 3PAR 技术人员这么操作真是着实吓了一跳。

因为固定大小的 Chunklet 的存在，可以将 I/O 更为均匀的分散到多个磁盘上。

对于熟悉Oracle 的朋友来说，会发现这和 ASM 的思想非常接近。因而也可以和 Oracle 数据库进行无缝集成：

因为软件做得非常具有易用性，日常管理与维护远远没有其他高端存储那么复杂，新增磁盘这种事情，都是一行命令之后底层自动处理。其实在 Thin Provisioning 方面 3PAR 也是很值得一说的，比一些厂商的伪 Thin Provisioning 具体多了。限于篇幅，不赘述。

3PAR 在美国有很多金融证券行业的客户，也有 Web 2.0 行业的客户--MySpace 。在保证 I/O 响应在 10ms 以内的前提下，3PAR 的 IOPS 能力非常优异(这才是卖点，不难理解其客户多集中在证券、金融领域)。虽然有些厂商号称能得到更高的 IOPS ，但那是在 I/O 响应时间很差的情况下的数据。要说明的是，现在随着一些存储厂商在高端服务器上也支持 SSD ，未来几年如何还要再看。

前两年 3PAR 推行所谓 Utility Storage(功用存储) 理念，现在貌似改成敏捷存储了。说实话，我觉得敏捷存储真的挺适合的，3PAR 命令行批量创建 LUN 真的很让人感觉舒服。当然，也在宣传云存储和绿色存储的理念，那是题外话了。

3PAR 原来只做中高端市场，只有 T 这一个系列，现在也开始关注中低端市场了，推出了 F 系列的产品。软硬件体系基本没变，倒是没仔细看过。

(Note: 相关图片主要来自 3PAR 公开资料.)

--EOF--

此为《程序员》杂志投稿。应该刊登在 2009 年第二期。

"预测"不是件容易的事儿，"回顾"就好操作的多。2008 年发生了很多大事，相比之下，数据库技术领域的这些事儿多少有些微不足道。

0) Sun 收购 MySQL

2008 年初第一笔业界大并购，在上一波.com 大潮中 Sun 赚得盆满钵满，在这一波 Web 2.0 大潮中，Sun 还要做 Web 2.0 中的这个"点"(Dot)? 我个人对此并不看好。

这是今年数据库领域的最大的事件，但也仅此而已，一年下来，MySQL 联合创始人 David Axmark 都因为"痛恨每天都要遵守的各种制度"从而离开了 Sun ，而到目前为止也没看到 Sun 针对 MySQL有什么新东西拿出来，倒是狂推预装了各项软件的硬件盒子。前不久发布的 MySQL 5.1 GA 质量更无法让人满意，很多 MySQL 旧将纷纷抱怨，连著名的 MySQL Performance Blog 也不失时机的抛出"MySQL 质量将不再如昔"的论断，大浇冷水。

1) Amazon 推出 SimpleDB

云计算喊了一整年， Amazon 也没闲着，不停地推出新服务。SimpleDB 服务让Jeff Bezos 把手伸向数据库服务，现在仍看不到该服务有大行其道的趋势，但是"提供数据索引与查询的核心数据库功能的 Web 服务" 无疑会逐渐吸引更多潜在的用户。到了年底，Amazon 干脆打出了在一段时间内 SimpleDB 免费的服务来招徕用户，用心良苦。

最近若干分析家下了论断 "未来网络产业将仅剩亚马逊与 Google 两强相争"，的确，Amazon 的技术实力不容小视，在 2009 年相信有更多精彩。

2) 主流存储厂商试水 SSD

让人没料到的是 EMC 作为业界存储领头羊，会率先推出支持 固态硬盘(Solid-State Drives, SSD) 的存储设备，Sun 、HP 等厂商也都不甘落后，纷纷宣布将拥抱 SSD。确实，SSD 的某些特性表现是如此抢眼，很多 DBA 都等着它来解决或者缓解 I/O 问题呢，毕竟这是近年来能看到的最大的硬件领域的突破。"钱能解决的问题就不是技术问题"，可惜，目前光有钱，买回来的 SSD 可能还是解决不了问题。SSD 的可擦写次数问题仍然让很多用户心下狐疑。

相信2009 年会是 SSD 爆发的一年，主流存储厂商都会纷纷推出支持 SSD 的产品。假以时日，SSD 应该不负众望。

3) Oracle 联手 HP 进军硬件领域

今年 Oracle 整体在 DB 方面实在没什么亮点，如果非要说有，那么在 Open World 上亮相的 Exadata Storage Server 倒是值得一提。

微软和 IBM 这一年来尽管都有升级产品推出，但实际上也就是升级产品推出而已，仍看不出什么新生机。其实很多用户已经非常厌倦不停地增加新功能的软件新版本，每发布一个版本不失时机的宣布打破什么 TPC-C 记录之类的事情已经难以引起用户兴奋。如何在廉价硬件上实现大规模平滑扩展是所有的数据库厂商必须要面对的问题。

4）面向列存储的数据库技术

面向列的数据库(Column-Oriented Database)这不是什么新技术，但是非常适合某些数据分析或者统计类的应用需求。常见的RDBMS 都是面向行（Row-Oriented Database）存储的，在对某一列汇总计算的时候几乎不可避免的要进行额外的 I/O 寻址扫描，而面向列存储的DB 能够连续进行 I/O 操作，减少了 I/O 开销，从而达到数量级上的性能提升。

其实在 Google BigTable / Hadoop HBase 中很早就看到这一思想的运用，在过去这一年中，列存储数据库也更多的引起了重视。

5) GreenPlum= MapReduce + SQL

MapReduce ，让很多面向数据分析的 DBA 还是挺眼馋的，GreenPlum 的出现把 MapReduce 和 SQL 有机的衔接起来，给海量数据分析能力带来了新的可能。年末的时候， GreenPlum 又宣布进军中国市场，不知道用户实际接受程度如何。

顺便说一下，GreenPlum 背后的大东家是 Sun。

6) 从 Drizzle 到 Percona XtraDB 存储引擎

MySQL 的生命力不在大公司手中，而是来自开源技术、Web 2.0 网站的需求上。Drizzle 这个"精简 MySQL" 版本的出现多少证明了这一点。Percona XtraDB 存储引擎的推出也值得 MySQL DBA 惊喜。

除此之外，DRBD、MySQL Proxy 与 Memcached 等 MySQL 相关组件的灵活搭配与定制，给用户解决超大规模应用上带来了更大的可能。数据库市场不可能不受经济危机的影响，商业数据库厂商日子要吃紧是可以想见的事情。

7）Hadoop 的生命力

Yahoo! 公司在 2008 年表现不佳，但是 Yahoo! 支持的 Hadoop 项目可是左右逢源，再一次让我们认识到开放带来的生命力。Facebook、Amazon、AOL、阿里巴巴等公司（当然也包括 Yahoo!）都在纷纷构建 Hadoop 集群来解决大规模数据处理与分析问题!。期待在 2009 年 Doug Cutting，这位 Hadoop 项目的带头人不要被 Google 挖角。

N）2009 年会怎么样? 谁知道呢。

--EOF--

后记：这算是 2008 年末的时候数据库技术小观察吧。因为投稿的缘故，现在才发出来。在过去这短时间里，自己一些观点可能也有所变化。如有时间，再做补充或者修订。请注意该文的时效性。

补充：对于 SSD，最近一件重要的事件是 Steve Wozniak 加入了 SSD 厂商 Fusion-IO

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

是否该建设云存储服务?

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

是否该使用云存储服务?

回答这个问题之前，我建议先看看服务提供方是否真的是云存储服务，如果只是炒炒概念，用老的架构支撑，换汤不换药，那还是谨慎为妙。企业如果不能从技术上做些本质突破而节约成本，那么成本肯定要转嫁到消费者身上，如果消费者不买单，那该服务如何能长久? 和我们现实生活中很多山寨 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--