块存储设备
互联网越来越发达，网速越来越快（管制也越来越严），很多事情都可以通过联网解决。很多存储行业商家也get到了这个点。下图是个极简的模型，商家存储设备(黑盒子)，用户一个笔记本电脑，通过TCP/IP承载的iSCSI协议，对于Linux用户，可以看到一个块设备/dev/sdax，就像使用本地硬盘(如/dev/sda)一样，可以对其进行分区，格式化为文件系统，亦或直接裸设备读写。
对于用户，这就够了，着实方便，付钱就行。
对于一个有追求的码农，我们是有必要看看这个黑盒子里面是什么。下图是黑盒子里面的东西，再次强调，包括本文之前或之后的插图及描述，都是十分宏观的。篇幅有限不能说的太细，符合本文主旨；另外，说的太细就会和具体商家产品很像，咱不能那么干。
图9 块存储设备
抛开硬件、驱动、OS等，直接看软件逻辑，首先将系统上的硬盘组成多个RAID，如何组，组成哪种RAID，哪几块盘组成RAID等等，这些都是可以通过管理员配置。有人问了（对，还是前面问问题的那个人）：“就一个RAID行不行？”
可以，但是有风险，如果一个盘出现故障，RAID就暂时不能提供服务了，整个系统所有用户会受到影响。如果组成多个RAID，那么，仅仅有故障盘的RAID暂时无法服务，其它RAID是可以继续工作，不至于影响所有用户。套用某相声表演艺人的话说，用户就是衣食父母。
继续看图，软件对下要管理RAID，对上要为用户提供服务，它给用户提供的是LUN（全称是Logical Unit Number，也就是逻辑单元号），当然啦，用户（人）不必去理解什么是LUN，就如上面所说，顶多是一个/dev/sdax，LUN是软件、协议层面的东西。怎么理解呢？每个LUN关联了一组物理存储资源，你拥有了这个LUN，就拥有了这组物理存储资源，凡是使用物理存储资源，需要提供你的LUN ID。有过编程经验的人很容易理解，十分类似一个文件或socket句柄。客户端（这里不使用用户这个词，这里偏只程序）对LUN的读写，至少需要提供”LUN ID+R/W+Offset+Length[+data]”这些信息。
为什么需要LUN，而不是把RAID直接“丢给”用户？
图10 块存储设备内部
因为每个用户的需求是不一样。
码农李二狗，全部身家800G代码，做开发的时候谷歌一下然后复制粘贴来的。某宅男，拥有海量高清大片，4TB+不在话下。按照图10，我们可以给李二狗分配LUN 1，给某宅男分配LUN 2。软件逻辑层负责做映射，事实上，一个LUN可以映射到多个RAID，多个LUN也可以映射到一个RAID上（不常用，因为RAID故障影响多个用户），用户数据都会准确的保存到属于该LUN的物理存储资源中，不会出现张冠李戴的情况。当用户需求改变的时候，如李二狗也开始收集高清大片了，需要的空间就大了，那么可以将LUN1资源进行扩充，十分灵活。***，LUN的大小和该LUN所映射的物理存储资源大小以及用户查看/dev/sdax的大小是一致的。
带文件系统的存储设备
其实在大多数场景，用户都是将设备格式化成某个文件系统使用。那么设备厂商就对用户说：“我有一个办法，你们可以不用自己格式化，我直接提供一个文件系统，直接mount就行了，NFS，简单吧。”
“好啊！好啊！”
“不过，得加钱。”
“……”
商业上的事我们先不管，看下图。用户交好钱，被告知一个地址，直接mount到本地，确实方便。
图11 带文件系统的存储设备
这回，黑盒子里面又是什么东西呢？
图12 带文件系统的存储设备
看图之后，是不是和我一样的感觉？MMP奸商。 就多了一个文件系统层，内部格式化LUN，然后就多收了不少钱。
如果你以为只有这些就错了！
我们假设，你付费买了1TB的空间，服务商是没有真的给你预留1TB物理存储资源的，当你用的时候，再去申请物理存储资源。你很愤愤，就存满1TB，此时你以为真的消耗服务商1TB物理存储资源了？不见得！有可能只消耗了0.8TB甚至更少。
抛开商业成见，但从技术角度来看，这里有两个技术需要提到压缩 和 去重，这在文件系统层面很容易做到。
压缩（Compress）
您可能知道，文件系统在进行IO时候是以一定大小数据块(block)为单位进行的，以4KB为例。压缩也是以这个数据块为单位，在写入磁盘之前进行压缩，原本4KB的数据，压缩之后可能就变成2KB，多个压缩之后的数据块再次拼成4KB，然后保存到物理磁盘。这个操作，节省了物理资源。用户读数据的时候，如果是压缩的，需要首先解压缩，然后返回给用户。压缩、解压缩操作是纯算法的，主要消耗CPU资源，因此在系统负载很高的时候，不建议启用压缩机制。另外，数据是否压缩，需要额外的元数据（metadata）记录，这增加了系统复杂度。有的设备会将压缩、解压缩操作交给硬件去完成，减少CPU的消耗。
去重（Deduplicate）
上传一个大的高清影片到网盘，秒传，遇到过吧？这说明服务商存储系统存在了一个和你一模一样的文件，你遇到了一个志同道合的宅友。为了节省空间，系统就仅仅给你做个标记（或类似一个软链接），然后增加文件的引用计数，免得别人删除了影响到你。这个还是从文件层面的去重，也十分容易理解。我们做个极端假设，如果两个1G大小的文件，仅仅有一个字节不同，按照上面方式是不能做到去重的，还是得上传。文件的一部分一样就不能进行去重了吗？
答案是有。数据块（block）级别的去重。
图13 数据块级别去重
我们看图13说话。最初，硬盘神马都没有，文件1数据全部写入硬盘，这没什么好说的。然后，文件2，其中BEF三个块，硬盘已经存在，不必写入了，剩下的块需要写入。***再看文件3，前面3个块，XYZ不存在于硬盘中，需要写。后面的XY就不必写了，***的E也是不必写。
去重技术确实节约物理存储资源，但也存在一些问题。
比如：如何确定当前要写的块硬盘中已经存在？
不可能去硬盘中逐一比较！
一个做法是将早期写入的块进行HASH计算，将HASH值以及块信息保存到内存中，作为Cache，新预写的块计算HASH值，如果HASH值在Cache中存在，则取出Cache中块信息，做去重操作，记录信息。内存有限，Cache不能足够大到保存所有硬盘中的块信息，因此去重是有限度的，另外Cache的更新也是一个技术要点，何种Cache更新算法能够得到好的去重效率是一个值得深入研究的话题。
好了，以上简要介绍了两种存储设备。接下来……
有人问了（对，依旧是前面问问题的那个人）：
“我替码农李二狗他父亲王老爷子问个问题，是软件就有BUG，如果你这软件崩溃了，是不是所有用户都不能正常访问了？”
“没错！”
“弱爆了吧？”
在前面RAID的描述中，可以体会到一个词“冗余”，冗余起到保险、保护作用。既然说软件存在缺陷，可能挂，那么就放两份在那，两个物理独立的设备运行同样的软件，互为主备。主用设备工作时备用设备待命，主备共享系统中RAID、LUN等配置及状态，主用设备挂了，备用设备上。用户无感知。这类方案在很多领域（如通信设备）也是常见的。
图14 主备备份
“看起来有用，你这主备设备都放在哪里？”
“服务商机房或数据中心。”
“如果数据中心着火了或其它情况，这些设备就不能提供服务了吧？”
“没错!”
“弱爆了吧？”
数据中心可是个有网、有电、有空调，有外卖宅男向往的好地方，是具备基本的防火、防盗（防师兄？）等防灾害的地方，但凡事预则立不预则废，万一出现差错可就是大事了。
其实数据中心也有“备份”。一般在同城的其它地方，也会有一个数据中心，用于备份当前数据中心的数据，同城较近拉光纤，备份效率杠杠的，甚至是实时备份。
图15 数据中心
“如果城市发生较大地震，两个数据中心都损毁了，数据就丢了吧？”
“没错！”
“弱爆了吧？”
两地三中心。即生产数据中心、同城灾备中心、异地灾备中心建设方案。两个城市的三个数据中心互联，如果一个数据中心发生故障或灾难，其他数据中心可以正常运行并对核心业务或全部业务实现接管。
图16 两地三中心
“那如果两个城市都……”
“你稍等，我打个电话。”
喂，代骂公司吗？这是我的个人资产证明，帮我骂个人，骂道我破产。
……
天下无不散宴席。本次分享就到此结束了，还是那句话，能力有限水平一般，蜻蜓点水的啰嗦了这些，万一有那么一句半句勾起了您的兴趣，我就十分欣慰。
注：我们尊重对知识刨根问底的精神，以上代骂公司有关说辞纯属扯淡。
尾声
“你可吓坏我了，在看Linuxer公众号的文章呢，向大牛们学习学习，我一直觉得技术没啥长进，内心挺虚的。”
“看你体格应该不只是心虚吧？确实，这些文章质量都很高，值得学习，除了那篇《大话存储》有点打酱油。在说，学习没必要偷偷摸摸的吧？”
“习惯了，没办法，看感兴趣的东西就这样。”
“我只能呵呵了。我关注的主播要上线了，先走了，这个移动硬盘放这借你用用。”
“里面是什么?”
“当然也是你感兴趣的东西——你懂的”。
