本文转载自我的公众号《红松鼠的IT窝》
作为一个IT从业者，我销售存储的时间只有两年多，而使用存储的时间却有快二十年了。在短暂的销售存储的时间里，能让产品具有吸引力，最好的办法不是讲业界领先的技术与指标，而是告诉客户怎样使用存储、能解决哪些问题。现在就让我回归到存储使用者的位置，通过对近二十年来如何使用存储的回顾，来回答为什么要使用存储，存储存在的价值是什么，为规划设计存储产品做一参考。
20年以来，我们为什么用存储
共享数据
我最早接触的共享存储，并不是像NAS这类用于应用间共享数据的存储，而是用做集群心跳。大概是2001年，第一次使用Sun小型机。那时分布式应用还很少，可靠性都是用服务器集群（一般一个集群就两台服务器，所以也常叫作双机）切换来实现的。SUN的服务器集群叫Cluster，配置Cluster的话需要同一个Cluster中的所有服务器连接一个磁盘阵列，并通过共享的存储盘来判断集群中的服务器是否能正常工作，这个盘就是心跳盘。如果没有磁盘阵列的话，也可以在两台机器上共同连接一个硬盘框当作共享存储，这是我使用得最早的共享存储了。小型机时代，磁盘心跳是几乎所有HA系统支持的功能，而且多数把它作为必选项，Oracle数据库在10G之后的版本也使用磁盘心跳作为判断集群状态的必选配置。要说原因，可能是因为磁盘心跳相对网络心跳更精确更灵敏吧。其实不只是IOE架构，像Zookeeper这样的分布式集群管理组件，也采用了类似的共享存储方式在集群中同步节点状态。
NAS也是我很早就接触的共享存储。使用NAS存储有几种情况：
一种是数据要在处理流程中流转。比如一个批量开户的操作，先要上传一个批量数据文件。这个操作一般是在Web前端完成的。之后后端的应用要拿这个文件定时执行批处理任务。这个流程比较简单，如果还要把数据复制到后端本地存储的话，比较麻烦，不如直接存放到一个共享存储上，后台任务直接处理这些文件就可以了。
另一种情况是分布式应用间的数据共享。这种共享往往是随着单机应用向着多机分布式发展相伴相生的。开始的应用都是单机部署的，只是为了保证可靠性会像上面提到的用Cluster集群做主备切换。这种架构下，双机间还不需要共享数据。后来一台机器的处理能力不够用了，需要多台机器共同处理业务。这就要求数据也要在多台服务器间共享。通过共享文件系统共享数据是个非常简单的方案，否则让应用去改造来处理数据共享虽然也许效率更高，但如果有更简单的解决方式的话。没人愿意去动应用的。习惯的力量是强大的，共享文件系统这种使用方法在云计算和大数据时代仍然被广泛应用。代表分别是S3和HDFS（虽然HADOOP设计是遵循Local Disk架构的，但HDFS却是按共享文件系统的方式来使用的）。
数据永不丢，随时可访问
再回到双机来，双机上常见的应用像数据库最早只在一台服务器上运行。如果数据存储在服务器本地的硬盘上，服务器发生了故障，双机切换后数据就无法使用了。如果是一些小型应用或生成的数据不影响应用的启动使用，可以忽略这个问题，但数据库和其它大型应用肯定不行。解决的办法就是把数据存储到外置存储上，当双机切换时，存储在另一台服务器上加载，此时只要把数据库重新启动就又可以使用了。
HA这种架构虽然古老，但却老当益壮，在云计算中，也能看到类似的架构。比如在阿里云RDS的基础服务中，采用了外置存储存储数据，故障时计算节点（虚拟机）可实现故障热迁移。由于只需要一份存储，成本较低，而且省去了主从节点间的数据同步，性能反而优于其它RDS服务。
现实中，大家可能对营业厅停业一天甚至两天还能忍，但绝对不能忍自己的手机没用完的话费不见了。也就是说在IT系统中，应用可以中断，但数据绝对不能丢失。使用外置存储的双机架构解决了因服务器故障可能无法使用甚至丢失数据的问题，但更加要求存储必须持久可靠，不能丢失数据，并且可以持续提供服务。当时使用的外置存储之所以能达到这个要求，是因为它们使用了大型机的理念，所有关键部件都是冗余的，比如控制器，电源，坏多个都不会停止工作，而磁盘通过RAID实现保护保证不丢失数据。后来在可靠性上存储厂商又琢磨出很多新花样来：
可防删库跑路的Clone/快照：2003年，有个局点的数据库坏了，由于是数据库逻辑故障，在数据库彻底崩溃前，没有发现问题，但其实数据早就损坏了，所以崩溃后数据库再也无法启动，导致业务中断了几天。事后存储厂家推荐了一个叫BCV的技术（存储Clone）来实现逻辑故障的及早发现和快速恢复。我们每天对生产库做两份Clone，然后启动其中一份的数据库 ，如果能正常启动，说明数据库没发生逻辑故障。另一份数据则作为备份数据转天再覆盖。因为是存储内部进行复制，备份恢复操作要比磁带快得多的多的多。删库跑路也是一种逻辑故障，也是可以用Clone来恢复的。有了Clone之后，我们常用它来查询恢复因为“手抖”做的误操作，比如Update或Delete条件写错了，或是在数据库升级这类可能造成数据库损坏的操作前做数据库备份，这种备份可以在升级出问题时在几分钟内恢复数据，甚至有足够时间再升级一次，如果用磁带因为恢复时间太长不但没时间重做，连数据都很难在窗口期恢复完，只能报事故了。云时代这种备份恢复方案更进一步升级了，在下一章节云计算的变与不变中我们再看。
容灾：2006年移动集团公司觉得BOSS系统的可靠性还是不够，说要有容灾，于是就有了容灾。那时大家都不懂容灾怎么搞，就请IBM，EMC这些企业来做咨询，建立自己的DRP（灾难恢复计划）体系，大部分容灾技术选型都用了存储复制的方案。因为存储复制的方案确实好用，维护和使用都比较容易，这么多年，它仍然是最常使用的容灾技术，只是增加了像双活之类的新花样，以及延申到云这些新场景中去了。
灵活的配置
云计算的一些关键技术，比如虚拟化，二十年前我们在小型机上其实已经大量使用了。当时我们会把一台小型机划分为多个分区，每个分区就是一台逻辑服务器，可以有自己独享的硬盘，IO卡等设备。因为一台小型机内的硬盘不可能太多，所以一般一个分区只会分配两块硬盘，否则能分的分区数就要减少。如果一个应用需要存放的数据量比较大，不得不给所在的分区增加额外的硬盘时，经常出现明明CPU/内存还够，却因为没有硬盘装不了分区了。
还有个问题是小型机上的硬盘，只能按硬盘大小为单位来分配，当时使用的有36G，73g以及后来的146g和300G的硬盘。但是你的需求可能是370G，可能只有20G，不是多了就是少了。
解决这个问题就是把数据存储在外置存储上。像数据库这种数据量很大的应用必然是放到存储上了，一些数据量大的应用，像话单处理也早被放到了存储上。而一些数据量小性能要求低的应用，后来放到了NAS存储上。到后来，我们连操作系统也装到外置存储上，彻底不受本地硬盘数量和配置的限制了，还意外使得操作系统的安装可以借助存储Clone（上节中备份数据用的那个）快速复制和安装，分区还可以在不同的小型机间迁移了。
现在X86/ARM的虚拟化无论是服务器还是存储技术，都是使用的同样的架构。而同样基于虚拟化的云计算解决类似问题的思路自然也差不多，比如上文提到的阿里RDS。
提升性能
这里可能大家会有疑问：存储的性能如果比本地盘还要快，那为什么当初Hadoop要用本地盘？其实这里边有一些误解。
首先，基于FC网络的磁盘阵列相机性能是要优于同时代SCSI接口的本地磁盘的。因为一来FC的速度就很快，二来FC是串行协议。解决了SCSI的并发问题，可以用更多的盘分散处理数据达到更高的性能，加上磁盘阵列还有缓存等加速手段，性能要比本地盘快。但是fc网络和磁盘阵列太贵了，如果用来处理大数据这种海量的数据。实在是“地主家也没有余粮”。
而当时以太网的速度又太慢太不稳定，以至于虽然2004年基于以太网的分布式存储就出现了，但长时间无法普及。所以当时Google和Vertica才选择了本地盘的方案构建大数据与MPP数据库。如今网络的速度和成本问题解决了，基于共享存储的Hadoop、数据湖方案又成了云服务的首选，以至于现在AWS、阿里提到数据湖时必然要强调它们采用的是计算和存储架构。
言归正传，当年我在刚开始工作的时候，存储确实比本地盘要快。而且存储会想一些招数进一步优化性能。比如百年老店十（Ｉ）八（Ｂ）摸（Ｍ）有一个gpfs方案（因为缩写被戏称为狗屁文件系统）本来是用在HPC上的，后来被用在数据库上，号称用它比使用裸设备还要快。后来我们在处理话单文件的应用出现了性能问题解决不了的时候。换上GPFS文件系统。性能也能提升不少，于是GPFS就成了话单处理应用的标配。
成年人总是我全都要
实际的应用需求往往是多样的，可能既要共享数据，又要性能好，还要灵活又省钱。可靠性没提到？那个还用说吗？数据丢了客户不吃了你老板也得拍死你。因此实际使用时，也往往是先满足了一个需求，然后发现还能用来做点别的事情。这方面Oracle是最典型的，开始是本地盘存不下数据也不能满足可靠性，就把数据放到外置存储上，正好双机切换需要共享存储，这个功能外置存储也能提供，就一起搞了。后来估计ORACLE觉得共享这个法子用来做数据库集群提升性能和可靠性也不错，就搞了个Share Disk的RAC架构。再后来Oracle觉得让Cluster和自己一起来管理可靠性是脱裤子放屁，就把存储管理和集群管理都拿过来了，不过方法还是磁盘心跳+网络心跳的老套路。
大部分的传统应用都有类似的情况。一个应用是因为最初在服务器的磁盘上放不下了，还是为了确保可靠性而使用了外围存储，多数已经无从考证，但现在往往是多个需求同时存在，而且可能用得久了，共享应用数据，提升性能的需求也会在存储上慢慢“生长”出来。
云计算和大数据时代的变与不变
我开始接触和使用存储是在运营商支撑业务初创期，硬件是小型机+磁盘阵列，软件则是应用＋商业关系数据库，也就是有名的IOE架构。随着云计算和大数据的兴起，以阿里为代表的互联网厂商展开了去IOE。在这种技术导向下，经常听到一种观点，认为使用存储代表着架构的落后。那么在当下，存储是否还有存在的必要，使用外置存储是否代表着落后？
最早大力倡导去IOE的阿里已经给出了答案。作为支撑阿里双十五交易业务的核心数据库polardb，正是采用了外置存储。在这个架构中，存储起到了数据共享（一个读写节点和最多15个只读节点共享一份数据），强大的可靠性（存储三副本，分离架构服务器故障恢复时不需要重新同步数据），高性能（存储本身高性能，特定IO优化和架构带来的IO量减少）及低成本（计算、存储按需分配）。当下对计算和存储分离方案最大的布道者正是云计算领域的大佬像AWS，阿里们。正如前文所说，云计算的主要技术是从小型机继承的，所以一切还是熟悉的配方，熟悉的味道。不过不变中也包含着很多变化。让我们重新看一下原来我们使用存储的几个原因，有什么变与不变。
共享：少搬动数据节省时间和成本
随着应用组件和应用系统越来越多越来越复杂，以及数据量的爆炸增长，数据在各个应用系统间的流动变得越来越多越来越困难，需求却越来越迫切。以至有了烟囱化，数据孤岛等多种形容这种困境的名词。此时一种叫做数据湖的解决方案出现了。我们来看一下阿里和AWS的数据湖，他们都强调了数据的共享，试图用统一的共享存储来存储数据，数据在数据湖中是唯一的，由于数据湖是Schema-on-read的架构，并且保存了全量数据，各平台可以直接自己的需要定义数据结构和使用数据湖中的数据，不需要再进行数据的迁移。下面的架构图可以看出云原生数据湖是所有组件围绕着共享存储的架构：
为了说明如何通过数据湖的数据共享能力来简化数据分析，AWS用了一个气象数据气象分析的示例。气象分析需要有可信、海量、及时更新的观测数据。传统的处理方式，需要数据使用者自己每天更新下载数据并进行加工。而在这个示例中，用户可以直接使用美国国家环境信息中心在AWS S3上的每日数据快照，通过AWS的Athena和QuickSight就可以实现气象数据的可视化分析。由于数据的Schema是在使用时定义的，也就是数据湖典型的Schema On Read，因此一份原始数据可以支撑各种数据分析的需要。有兴趣可看一下使用Amazon Athena和 Amazon QuickSight进行天气数据可视化分析或搜索同名文章。
随着数据共享的需求越来越多，连内存数据都在考虑共享了。在Apache开源社区有一个项目Arrow（参见Apache Arrow：跨平台的内存数据交换格式），它定义了统一的内存数据格式，从而使不同系统间的内存数据共享成为可能。由于内存数据的传输和转换需要消耗大量的CPU和时间，采用统一格式，RDMA传输和共享内存存储的方式，可以节省大量的CPU和时间。这项技术目前已经在Spark中应用。
数据永不丢：甚至连系统降级也不允许
数据永不丢失是从大型机时代开始的。而到了云时代。他又被赋予了新的含义。在AWS的可靠性理念中，服务器是可以生发故障的，甚至可以停机节省成本。而存储必须持续工作，亚马逊甚至认为，在大型环境中，降级也是不可接受的。因为在大型系统中最终降级的概率会接近1。因此在其OLTP数据库设计中，存储在3个可用区保存6个副本，通过4/6仲裁机制，可以在一个可用区+任意可用区的一个故障的情况下，正常提供服务。这个数据可靠性相当于同城双活系统的可靠性能力。在这个架构中AWS把系统亚健康也归为故障来进行应对，这使得系统的整体可靠性和小型机时代没有差别。而备份与前文所说的Clone类似，是用S3存储的快照功能实现的，相比Clone，快照更节省成本，还可以保存更多的副本。
其实Auora肩负了亚马逊去O的任务，它承载的业务对可靠性的要求并没有因上云而降低。如果对Aurrora感兴趣可以看下我的他山之石（二）：从AWS Aurora和阿里PolarDB数据库看“去O”中，存储的回归和“智能”化
灵活的配置：云与大数据的刚需
大数据是最早把存储一脚踢开的。但随着云计算的发展，各大云厂商在提供大数据服务时，都推出了计算和存储分离的架构，没错，就是数据湖中的架构。大家选择这个架构，一方面是因为当初选择Local Disk的一些技术难题已经解决了，另一个原因就是成本。无论是云厂商还是互联网大厂，都有巨大的系统规模，如果能节省哪怕一点点成本也是非常可观的。而使用外置存储一方面可以解决固定配置往往CPU或存储存在浪费的问题，另一方面可以使用纠删码技术降低三副本的成本。对于大数据计算和存储分离的架构分析，可参考他山之石（一）：对FaceBook下一代HADOOP数据仓库存储方案的初步解读和他山之石（二）：从AWS Aurora和阿里PolarDB数据库看“去O”中，存储的回归和“智能”化。
提升性能：老办法新招数一起上
说到提升性能，老办法有几种，一种是堆硬件，这种方式在云上自然很容易，不过有点Low，另外一种是用高速介质，这方面SSD很早就被用在第一波去IOE中了，如今更是把SCM这类技术用了起来；除了介质，还有一个方法是提升传输接口速率。当初就是因为传输太慢太贵，大数据才选了Local Disk，现在这个问题已经不是问题了，看看云厂家和像FaceBook这样的互联网厂商，25GE甚至40、100GE都用起来了，网络直接搞成无阻塞转发的，RDMA，ROCE目前用得也不少了，可以参考它山之石（一）中关于技术拐点的分析以及它山之石（二）中阿里的实践。
而一些“新”办法也在不断发展中，之所以打上引号，是因为其实这些技术出现的时间也不短了，现在通过新硬件或算法的加持，以及应用领域的增加，变的更常见了。
这其中“可计算存储”其实在Oracle的一体机中早已有offloading功能，Smart Scan就是其中的代表。如今AWS的Aurora数据库也采用了类似的架构，它的数据页生成就是放到存储上实现的，只不过没有明确包装成概念。在对象存储中，将一部分对数据的处理放到对象存储的分布式节点上的方式也是一种常见的可计算存储。不过这些都是在特定的厂商内部实现的封闭架构。随着这一架构被越来越多的应用和一些初创厂商的进入，未来很可能出现开放架构的可计算存储解决方案。目前这是一个新的技术热点，阿里数据库公众号最近也转发了可计算存储方面的文章。
旧瓶装新酒也是常用的套路。比如对缓存命中率高显然能提升性能，那么就用AI来提高命中率。冷热数据分级可以加速热数据的处理，那么把自动化甚至智能化的存储分级用到大数据等领域，在提升性能的同时降低运维工作量、节省成本。
存储向何处去
讲到这里，似乎已经很明确了，存储就要在数据共享、不丢数据与可靠性增强、灵活的配置、提升系统性能等方面寻找应用场景，发挥自己的优势。当然这里还有一个隐含项，就是成本。要么在同等成本的情况下，存储能把这些事做得更好，要么通过做这些事，能节省成本，这就是存储存在的价值。如果您看完本文觉得哪些事让存储做能带来收益，或需要存储做哪些事来解决一些问题，欢迎留言讨论。
