转载

分布式存储在云时代找到了“新方向”

云计算加速发展的势头愈演愈烈，企业IT人员聊的已经不是“我们要不要上云计算?”，而是“怎样上云?如何用好云?”那么当企业张开双臂拥抱云计算的时候，对原有的传统IT架构会造成多大冲击?原有的传统IT架构能不能满足上云的这些需求?从存储架构来说，无疑是不小的考验。

通常来讲，主流的存储类型可以分为块存储、文件存储、对象存储。当然今天主要讲的是块存储。传统SAN存储是过去人们经常在讨论的一种集中式块存储，其交付给客户的时候通常是以一种双控架构的形式出现，可理解为背板专有硬件集成了两个控制节点，紧密耦合在一起，这使得在业务部署的时候会以“成对”的形式出现，并且一对双控和另一对双控之间要互相通信，对网络环境有着较高要求，企业不同业务部门的存储系统难以发挥协同作用。

传统的集中式块存储计算能力还是主要由控制器提供，所以计算力是受限的。打个比喻，传统的绿皮火车，只有一个火车头在跑，加容量只是不停的在后面一节一节的挂火车皮，它的性能无法得到线性的增长，可能你挂的越多，最后平均下来整个系统运行的效率越慢。

此外，其需要专有的硬件设计以及专业的硬件架构，这也造成了其本身拥有的硬件成本明显高于x86服务器，运维起来也比较复杂。一般这种存储出问题的话，基本上需要专业厂商派专业的服务人员来解决。由此可以看到，传统的存储如果想适应云时代的需求，面临着比较明显的局限。

想让存储满足云时代的要求，要满足哪些特点?首先，要基于标准x86硬件、软件/硬件冗余设计，整体架构高可用，存储是数据的一个终点，要通过计算、网络最终把数据保存在存储上。其次，根据业务架构与规模进行存储架构的调整。存储能够根据业务架构的调整、业务规模的变化相应的做灵活的调整。

再有，容量和性能拥有完整的Scale Out能力，让性能和容量可以随着节点线性增长。同时，开放的API、支持与业务耦合。需要做到软件定义，需要提供开放的API，可以为不同的业务做耦合，不需要绑得那么紧。此外，统一管理、统一运维。在管理和运维方面，一定尽量简化运维人员参与的复杂度，降低运维成本，尽量让存储系统自己去运维。

对于企业的核心业务系统来讲，数据库算是典型的应用场景之一，这里面包括了传统的业务系统，比如Oracle、SQL Server、SAP，大部分的金融行业客户或者传统企业一定会用这种数据库，当然也有一些面向分布式的解决方案，比如基于MySQL的分布式数据库，MySQL是目前比较流行的或者大多数客户在新业务系统部署时候使用的开源数据库。

举个例子，某家保险巨头需要的存储系统要具备足够的稳定性、足够的性能，才放心让它支撑核心业务系统。核心业务系统里面数据库是最关键的，比如最常见的Oracle数据库，传统企业用什么跑Oracle?基本上都是国外厂商的品牌，比如EMC、IBM或者Oracle一体机来跑Oracle数据库。

为什么数据库非常关键呢?比如说这个保险客户，所有的保单，客户支付的保费、赔付的金额，都要放在这个数据库里面。如果这个数据库出现任何问题，哪怕丢一笔数据，如果这个客户要做理赔，服务商不清楚他到底缴了多少钱、需要赔付他多少钱，这个产生的问题就非常大了。银行更是一样，存一笔钱进去之后，这个数据丢了，对银行和客户都有很严重的影响。另外一个层面来讲，新的业务系统要能够基于当前较为流行的Serverless、服务网格、容器K8S，可以将新的业务系统采用最新的架构来做承载和部署。

如果剖析一些新的分布式存储架构的网络拓扑，可以看到前端的业务集群没有任何变更，数据库的服务集群，比如说三节点的Oracle RAC系统，也没有太大的变化。变化在哪?在整个万兆网络和存储服务集群。传统业务里，存储是基于FC的存储，网络是两套网络，一套网络是基于业务的传统万兆以太网络或者千兆以太网络;另一套网络是专门跑存储的FC网络。

当做了存储技术架构的变更之后，从网络层面来看就是统一架构了，基于一套万兆的以太网络来实现的。存储的网络和业务的网络整合，对运维来说复杂度降低了，因为它是同一套架构。此外，在存储服务集群上可以看到网络拓扑相对比较复杂，因为一个节点上面有四根网线来做业务的传输和网络的传输，不过网络的流量是可以做平均分配的，因为其没有一个统一的入口，不像传统的集中式存储，而是有两个存储网关，所有的流量都要通过存储网关与后端存储来做通信。

分布式存储的网络流量、业务流量是均匀分布到所有存储节点的，会将网络流量和网络压力做了平均分配，可以实现对业务流量的分担，具备很大的容量扩展和网络并发能力的。可以说，是一个比较典型的传统金融行业客户对存储和数据库的使用架构。