近年云计算存储发展中颠覆认知的新趋势解析
云计算技术浪潮奔涌向前，以云原生为代表的新秩序将带来企业IT系统架构的重构。如何建设云平台存储实现业务稳定与创新并举？最近笔者通读了《迈向YB数据时代》夏季刊关于“云平台存储”相关的内容，有感而发。
下文是笔者对“近年云计算存储技术发展趋势”的解读与洞察，也希望能带给读者朋友一些灵感启发，共同交流！
当提到云计算存储时大家首先想到的是什么？分布式，软硬解耦，通用硬件，甚至是去IOE后无存储？云计算“创世纪”时，这些特征是存在的，但随着近年需求和技术的发展云存储已经变得“面目全非”。本文试图理清一些重要变化，为大家的工作提供一些参考。本人“身在此山中”，未必识得庐山真面目，仅以自己了解的一些信息，供朋友们打开新思路。
近年“云存储”颠覆了哪些认知 “企业存储”反攻上云
云计算、大数据、互联网应用架构火热之后，普遍认为随着以互联网为代表的新型IT架构的出现，高性能、高可靠但高成本的企业存储的需求会逐渐消失，同时“集中式存储”或称“企业存储”成为了落后架构，承载未来IT系统的云计算中的云存储应是分布式存储的天下。这使得企业存储已死的声音不绝于耳。然而近几年以AWS为代表的公有云厂商却以行动推翻了这些观点。
高可用、低时延、高性能密度仍是高端云存储的追赶目标
2020年底AWS推出块存储IO2 Express预览版，号称首个云上SAN存储，无论是口号还是技术指标都从SAN存储已死变成SAN存储真香我要成为它。伴随产品对标对象从服务器磁盘到企业存储的转变，IO2 Express的持久性、最大IOPS/GiB、时延三个关键指标都有数量级的提升，业务范围也从本地盘替代转向商业数据库、内存数据库等企业级存储应用：
|
卷类型 |
EBS发布时 |
通用型SSD GP2 |
IO1发布时 |
IO1 |
IO2 |
IO2 Express |
|
持久性 |
|
99.8%-99.9% |
|
99.8%-99.9% |
99.999% |
99.999% |
|
最大IOPS/GiB |
|
|
|
50 |
500 |
1,000 |
|
时延 |
|
个位数毫秒 |
|
个位数毫秒 |
个位数毫秒 |
亚毫秒 |
|
单卷最大IOPS |
|
16,000 |
|
64,000 |
64,000 |
256,000 |
|
单卷最大吞吐量MB/S(16K块） |
|
250 |
|
1,000 |
1,000 |
4,000 |
|
每实例最大IOPS |
|
26,000 |
|
26,000 |
16,000 |
26,000 |
|
单实例最大吞吐量 |
|
7,500 |
|
7,500 |
4,750 |
7,500 |
“云存储”不但参数的“面子”越来越像企业存储，架构的“里子”也是如此。AWS自2012年推出 IO1后8年没有新产品，但收购存储厂商E8 Storage获得其硬件能力并将其CEO任命为块存储研发总监后1年多时间就推出了IO2和IO2 Express2。以下为被AWS收购的E8 Storage存储架构，关于云存储架构与企业存储的趋同趋势分析详见"浓眉大眼的叛变"一节：
企业级NAS存储被直接搬上云
如果云上SAN存储还是AWS“自研”（实为收购），那么企业级文件存储则干脆把老牌NAS存储厂.NETApp的产品搬上了云。2021年9月AWS存储日大会宣布与NETAPP合作推出OTNAP文件服务，成为与AWS自有FSx并列的4种托管文件服务之一，这一合作由AWS直接面向客户提供服务，比此前NETAPP与AWS、微软和谷歌的存储软硬件合作更为深入。有人认为这是存储厂商向云低头，但反过来AWS在已经有了多个文件服务的情况下与NETAPP合作又何尝不是为了市场而向存储厂商低头呢？
AWS与NetApp合作的文件存储服务
大数据存算分离成主流
大数据相关技术从被google三驾马车和其开源实现HADOOP带火开始就是去存储化的架构。但近十年来，AWS从EMR到数据湖（并不是业务视角的数据湖）不断推动大数据存算分离理念。如今数据共享、灵活按量使用、高可靠性的存算分离数据湖理念已被所有主流云厂商接受，存储已是云上数据湖的“中心”。
AWS数据湖围绕S3存储构建
阿里云数据湖，同样围绕存储构建
甚至不仅叫卖基础设施的云厂商，将服务构建于云上的Snowflake也采用公有云对象存储以存算分离架构构建数据仓库服务：
Snowflake架构，使用各种公有云对象存储持久化数据
云原生数据库回归IOE架构
与前面两个同时发生的是分布式数据库中存储的回归，领头的叒是AWS，以下是AWS的Aurora数据库架构：
蓝色为计算节点，绿色为共享存储，S3用于备份数据
最初我把这个架构拿给一个资深DBA同事时，他说这个架构和ORACLE的一体机架构很像。当时我有点诧异AWS怎么走回头路了？但看到更多的业界类似观点后证明同事的判断是正确的。在AWS带动下，阿里，华为，腾讯都出现同架构的称为云原生数据库的产品，共同点都是利用存算分离架构的可靠性与灵活性优势和将大量利用存储成熟能力解决数据库难题来提升数据库整体能力。如果说数据库是IT业最难解的题，那么云原生数据库与IOE架构的解题思路就是一样的。由于AWS用Aurora实现亚马逊内部业务去O（交易类业务），可以说是用魔法（IOE架构）打败魔法（IOE产品）。
云存储的“架构变异” 去除架构色彩回归云服务本质
IT业只有事实标准，大量的概念是约定俗成的，会随时间发生变化。比如现的“集中式存储”概念本不存在，分布式存储概念火起来后，原先的磁盘阵列才“变”成了集中式存储。因为磁盘阵列代表产品Symmetrix存储系统之父莫西·雅奈同时是最早的分布式存储XIV的创始人，集中式存储和分布式不但同父异母，架构上也都继承了Symmetrix中分布式的特征。“集中式存储”的典型特征不是集中式，而是双/多控架构：
Ceph存储架构
华为高端企业存储内部架构
云存储的概念也是多样的，世界第一个云服务就是存储服务——AWS的S3。所以云存储本来应是云上的存储。由于是存储服务，云存储又可以理解为存储云服务。但由于早期的云厂商一般采用自研存储软件+通用服务器来构建存储，且多为分布式架构，因此也会把软硬解耦/分布式与云存储等同起来。由于某一时期云的热度要大于分布式，一些厂商会把具有分布式架构的产品以云存储的概念来宣传，就显得更为混乱。
在业务范围发生巨大变化的同时，云计算存储系统的架构已经不能再简单和分布式、通用服务器、软硬解耦等关联了。除了引入普遍认为应该是“集中式存储的NetApp这种公然投敌行为外，自研存储也向架构融合，软硬协同方向发展了。因此再审视云存储概念时，架构的色彩已逐渐褪去，回归到它云服务的本质。
“浓眉大眼的叛变” 融合“集中式存储”架构
再次对比一下典型的分布式存储Ceph、被AWS收购的E8 Storage和被认为是”集中式存储“的华为Dorado架构：
Ceph组网架构
被AWS收购的E8全闪存组网及节点内双控架构
华为高端企业存储内部架构
很明显分布式架构是分布式存储、云存储、集中式高端存储的共同点，区别在于“头”（控制器架构）。
E8 Storage是介于典型分布式存储和磁盘阵列之间的形态：它采用了和高端存储类似的双控架构，因而更容易实现低时延和高性能密度。但它的双控制器只和24块硬盘固定组成一台物理机，相对高端企业存储实现简单，但灵活性不足。
除此之外，在缓存技术、高速网络等方面云存储也越来越多使用与磁盘阵列类似的技术，只是不那么显眼而已，这里就不一一分析了。
软硬协同
自研硬件并和自研存储软件紧耦合则更早出现。定制服务器、自研芯片早已广泛用于各类存储服务器。虽然没有自己生产，但这更多是从产业分工的经济性上的考虑，实际上大型云厂商的存储软硬一体化已经是很普遍的情况，换成普通服务器可能软件都无法安装。
软硬协同最早可能是出于成本考虑，现在则主要是为提升性能和可靠性，是实现支撑云存储向企业存储能力发展，支撑大数据，数据库等业务需求的需要。公有云是封闭全栈模式，存储软件多为自研或深度魔改开源版本，软硬协同反倒是效率最高的模式。
探寻颠覆性变化的根因
如果把云存储的现状与之前尤其是去IOE火热时云厂商的宣传对比一下可能会觉得有点魔幻。正面来看看这些转变的根本原因。
不改造上云的需求驱动
由于AWS、阿里等云厂商都是以支撑自身互联网业务来构建最初的云计算能力，所以云并不完美适配所有业务，需要改造才能上云。由于互联网架构有其先进性，部分业务改造综合收益还是不错的，改造难度也不大。
但即使传统业务要使用互联网的应用架构也面临大量的改造，比如亚马逊到2019年才完成去O，还用的是IOE架构的Aurora数据库。对互联网企业来说，云架构就是为自己的业务量身设计的，改造投入已被消化，云的研发成本还能变现赚钱，但普通用户就只能自己承担改造成本和风险。最终结果就是：好改造或不需要改造的应用，很早就上云了，而难以改造的业务则一直动不了。
另一方面很多业务改造是甩锅游戏。以容器化改造为例，首先要做的是应用“无状态”改造，简单理解最主要是数据与应用解耦。但解耦后的数据还是要放到文件存储，消息或数据库之类数据服务中，当这部分数据服务要上云时会发现要么没有好的存储能力很难实现，如数据库、NAS；要么是要做存算分离否则无法发挥云计算/容器的效率优势，比如大数据。最终还得存储接锅。
当容易上云的业务都吃差不多后，那些高价值（如核心业务）或数据量大（如大数据）业务就被盯上了。既然客户没法改造业务，那我就做业务能用的存储呗，至于怎么做到无所谓，毕竟“赚钱嘛，生意，不寒碜”。
存算分离是最优解
除了直接给客户提供存储，云厂商通过多年的去IOE实践也发现，有些问题用IOE架构来解决才是最优的。以当前火热的云原生为例，其五大代表技术中一项为“不可变基础设施”，要求部署服务之后决不会被修改，上文容器无状态改造就是要达到类似的效果。这一架构避免因故障切换或扩缩容的服务启停、增减时需要搬迁数据而无法快速完成的问题。但数据层的大数据、数据库不可能再通过“甩锅”的方式解决问题，只能让存储“回来”。
所以虽然数据库、大数据等云服务并不直接向用户提供存储，但云厂商都选择主推存算分离架构——为自己省钱省事就是多赚钱。
长大后我就成了你
那么为什么云厂商一开始不这样做，而非要现在推翻一部分原来的理念呢？
一来互联网作为新兴业务有必要做新尝试，并不是所有东西都能预先想到，掉坑也很正常；而最重要的是，云厂商也要追求自主可控，而这需要很长的过程进行能力积累。
云厂商的自主可控更多是从商业上的考虑，一方面要摆脱自身业务对IOE垄断厂商的依赖获得议价权，二来需要通过自己的业务磨练产品。互联网出身的AWS、阿里最早的存储产品都是对象存储，与互联网结合紧密，技术门槛比较低，非常适合一边支撑业务一边变现一边提升技术能力。之后他们都经历了十多年的积累，甚至最终通过收购等手段才有了前文分析的产品能力。手中有自主可控的产品，即使能力差一些，也从当年求着厂商变成了厂商求着自己。这时再与传统存储厂商合作也与当初大不相同了。
虽然路径是必然的，但在自己产品能力还比较弱时，当然希望用户改造业务来适应产品能力了；现在产品虽然还在追赶，至少有模有样了，那么各位觉得如果是你会怎么宣传呢？
用户视角看云存储的规划与构建
我既做过几年乙方，更做过十几年的半个甲方，在从厂商视角做完趋势分析后，最后以用户视角分析一下在当前趋势下如何规划与建设云（主要是私有云）中的存储系统的想法。
回归到以需求指导选型
经过多年的实践，很多企业容易上云的业务已经迁到云上了。当前云存储最迫切要解决的不是已经成熟的可上云业务的存储需求，而是核心业务以及一些新业务新技术如大数据、容器的上云存储需求。
核心业务改造难度大、风险高，少改造平移上云是最好选择。云厂商的种种转变就是受此驱动。核心业务存储的关键能力的要求是叠加核心业务对存储的原有可靠性、性能需求和云服务化的使用、管理需求，前者是要重点解决的问题。
相对于原来就使用存储的核心业务，部分新业务原来不使用存储，那么需要直接从业务需求的角度，甚至是更上层业务角度考虑使用存储后是否能保证业务能力不下降以及能带来哪些新价值。与核心业务类似，不改或少改，尽量在平台层而非应用层改造是最佳选择。
过去选型中经常会以某一架构或部署形态来作为产品分档和选型依据。但从公有云的发展来看，我们传统的云存储应是“分布式”、“通用”、“软硬解耦”等观念已经被云厂商自己推翻了，仍以这些为依据划圈圈很可能无法选择到满足业务需求的存储，需要打破原有的观念条框。当然这在实操中可能面临很多困难，在首先坚持需求导向的前提下，可以考虑一些变通手段。比如把分布式由分类变为特性，把单一分类维度变为多维度，通过量化需求指标引导厂商等。
利用成熟存储能力
通过AWS收购和直接引入企业存储厂商能力的案例可以看到，面对云存储与业务需求间的较大差距，拿来主义是一条捷径。在企业云存储规划中，将可满足业务需求的成熟产存储直接上云同样是一条捷径：一来简化了选型，毕竟核心业务的需求有时只可意会，不可言传（量化），二来也解决了传统云存储能力不足的问题。
实现平台集成与服务化
各种云常被说成XaaS，这个不变的S就是服务，是云的基本特征。当我们淡化架构之争，并试图引入成熟存储能力时，可能会面临像NetApp的问题，即传统存储资源管理、配置分发和运维需要适应云的服务化模式。
首先是解决集成和对接问题。传统的块和文件基本能力绝大多数存储都提供了OpenStack，K8S等标准接口，比较有挑战的是一些新技术和存储特性功能的对接：如大数据存储、FC网络替代技术、存储快照特性等面临重新开发或扩展原有接口，以及打通云全流程的问题。对于体量较小的用户，可以选择有多厂家配套集成的方案，对于金融、运营商等IT能力比较强的用户，则可以考虑牵引各厂商集成适配。
另外要注意的是传统存储不是服务化的，借鉴云服务化SLA量化和设计服务对精准规划有很大帮助。例如数据库典型特点是峰值IOPS高，数据有热点，对时延极敏感，因此常常一个数据库总共只使用了几万IOPS，但大部分集中在热点数据，峰值IOPS则是平时的几倍，而选型时如果对存储IOPS的评估不限制时延就会有虚高的IOPS能力。AWS的IO系列存储可以对IOPS能力进行保底来应对峰值，而其将最大IOPS/GiB作为承诺SLA则使用户可以按热点数据的IO需求选择合适的存储。除此之外，像快照、容灾等存储特性虽在云上广泛使用，但也都是以备份、容灾等服务形式提供，需要端到端而非段到段的模式。在云存储规划构建中，需要围绕服务化考虑几点：
-
选型中要考虑存储对多租户、SLA精细化管理的基本能力；
-
要构建云与存储间的服务化的接口能力，如多租户能力，云对快照、容灾的调用能力；
-
要由云构建服务提供给用户使用，如快照以备份服务、迁移服务形式提供，QoS以租户SLA能力供用户选择；
-
要借机量化业务对性能、可靠性和可靠性的需求，如对IOPS需求量化到单位容量，时延要分档等
关注新场景
从公有云存储发展过程看，无论是进军大数据等新业务还是尝试核心业务替代，都是在扩大云的边界。从业务角度，上云可能带来意想不到的价值：比如新的业务形势下，一部分稳态业务也需要有一定的业务弹性，那么结合新的云存储能力和容器化等多种技术组合有可能实现“稳态业务敏捷上云”，利用云来解决资源弹性伸缩和管理问题。而大数据往往不仅业务和数据是孤岛，在云上的资源也是孤岛，实现存算分离的弹性上云后，不仅数据共享更方便，资源利用也更高效，甚至能实现与交易业务的“混部”为业务提供更多资源保障。在解决现有业务问题之外，未来可关注以下新场景对云存储的需求：
-
容器化中存储需求：这既包括以有状态容器实现“稳态业务敏捷上云”需要的符合稳态业务高性能、高可靠要求的存储技术，也包括容器数据服务如消息、搜索引擎、数据库、大数据等有状态应用对存储的需求；
-
大数据/数据湖：虽然大数据/数据湖上云往往使用容器化技术，但容器不是唯一方式，同时数据湖对成本、性能、可靠性有独特要求，因此单独列出；
-
核心交易数据库：IOE架构的成功，O在前台，IE在幕后，缺一不可。云原生数据库架构的出现说明云厂商已意识到存算解耦的架构以及向存储做能力下沉来增强数据库能力对最终实现数据库替代的重要性。云原生数据库架构对存储的要求是最高的，但其业务价值也是巨大的，值得关注与尝试。
