私有云平台下的存储架构规划设计

一、引言相对于其他云计算技术来讲，私有云平台应该算是最早进入企业的IT基础架构。越来越多的私有云平台开始支持各类存储架构，如何选择可以融入私有云平台的存储架构成为关键问题。二、总体规划设计思路存储本身是用来承载数据，对于存储架构的设计，必然离不开数据的分析。所以在企业私有云平台下对存储架构的规划和设计也同样需要一个以数据分析为起点的整体规划思路。总结下来，笔者认为从数据分析到技术架构分析的完整闭环思路，如图1所示：图1：数据分析到技术架构分析完整闭环思路图按照图1所示，存储架构的规划需要分三个步骤进行。首先，需要从企业内部业务数据层面进行梳理和分析，包括业务数据的数据类型、数据当前的规模以及膨胀的速度、数据读写分布的比例以及随机顺序的相关特征、数据访问的并发量问题、数据重要性分级以及数据保存的安全性要求等；其次，根据数据梳理的结果进一步分析存储架构的规划设计，在通过对数据的结构类型、数据规模、并发需求、读写特点综合分析之后可以确定分布式架构和集中式架构的选型和拓扑规模，对数据分级和安全需求进行综合分析之后，可以决定架构当中的冗余性设计策略和备份归档策略，读写特点和并发量的分析又可以定位架构当中存储介质以及性能平衡的一些策略；最后，我们通过对底层架构选型和规划分析，再结合管理维度所需要达到的目标，来确定应用接口层、中间功能层以及运维层面需要达到的一系列对数据的使用、监控、加工、分析、报告等各方面的存储管理指标。三、数据业务梳理分析1.按照业务维度为前提的原则存储是私有云当中核心的三大资源之一，存储资源的分配需要秉承着以合适合理的性价比原则进行分配。而对于企业来讲，所有的业务系统是有着重要性、安全性等业务方面的区分的，而这些属性维度的判断是与每一个业务系统精密绑定的，因此数据分析的第一步就是要根据应用系统的业务特性需求进行分级划分，并且针对每一个业务系统进行其他维度的梳理和细分。例如，在银行业当中，企业的所有应用系统会参照银监局以及人民银行的相关要求（业务连续性、数据安全、数据审核等）并且结合自己企业的实际业务需求情况（核心、交易、渠道系统）进行细化分级，这些细化分级之后的标准是进行数据梳理分析的前提条件。2.数据梳理常规指标在明确了企业数据业务分级标准的前提下，我们在对企业存量数据和未来数据进行梳理和分析的时候，需要对所进行分析的业务系统数据定义一系列梳理的指标，包括数据类型、规模、读写特点、最大并发、访问要求等。就金融行业而言，笔者认为有以下几个必须要采集分析的指标：1）类型：企业存量数据都有哪些类型？这里的类型从广义上看是指结构化和非结构化类型，具体分析的时候针对结构化和非结构化进行细分，比如非结构化的又可以按照数据的功能维度区分为日志、备份、图片、视频、镜像等等，那么日志又分为账务日志、业务日志、运维日志等。划分的越细，后续的基础架构匹配就会越契合。2）规模：规模是指数据存量规模以及膨胀的规模，不仅仅需要判断目前的情况，还需要预测未来的发展，所以这个指标的分析是要分两部分（存量和未来）来进行的。3）重要性：重要性主要是根据前边我们对数据业务分级标准制定的。4）读写分布：这个指标主要是希望明确数据业务的读写类型和比例，它是指导我们进行存储技术架构选型的重要指标。具体细分可以分为顺序读、顺序写、随机读、随机写，同时分析出各自的大概比例。5）性能要求：性能要求体现在业务层面对客户层的反馈快慢需求上，比如银行的交易系统对性能的要求非常高，同样映射到数据访问的要求也必须是高性能的读写。6）事务性：事务性主要是业务对数据的完整性和一致性要求。例如银行的交易系统和账务系统要求的是数据的强一致性，不允许任何脏读、脏写，而电子商务类的购物车数据要求的是弱一致性，可以包容某些程度的脏读。四、存储架构选型思路1.分布式与集中式的选择其实每一种存储技术架构最初的诞生和应用都是与契合它的业务场景密不可分的，互联网企业在特定业务场景下对业务需求使得互联网企业在存储架构的选择中，最终选择了分布式架构。不是集中式架构长得不漂亮，互联网企业才最终拥抱了分布式架构，而是集中式在互联网的特定业务场景下无法解决其业务需求，互联网企业才最终选择了分布式，这个拥抱过程一定融入了太多的无奈。所以我们金融行业企业今天选择存储技术架构的初衷和源动力也应该从业务场景需求出发。接下来，我们来看看对各种主流存储技术架构特性的概括性描述：集中式架构最大的优点在于其对业务事务性的保护和其稳定的架构，这也是它长期在金融行业交易业务场景下占据核心存储架构地位的主要原因。但是它的不足在于它对大规模并发支持显得无能为力，无论它的控制器扩展能力如何，毕竟是有限的，这也是互联网企业放弃它的主要原因。恰恰相反，分布式架构对大规模海量数据的并发访问有很好的契合性，但同样有着对业务的强烈的事务性保护不够或者需要付出很大的代价等不足之处。看看业内对特定存储技术产品的评价，例如“GFS是一种适合大文件，尤其是GB级别的大文件存储场景的分布式存储系统”、“GFS非常适合对数据访问延迟不敏感的搜索引擎服务”、“GlusterFS是可以代替NAS的通用分布式文件系统存储技术，可配置性较强”、“对于并发读写操作的性能稳定性上，Ceph远胜于Swift”，“在4K-128K数据大小的范围内，Ceph和Swift的读性能表现都是最佳的”、“对于并发写操作，Ceph的并发量越高其性能表现越接近Swift，并发量越少其性能表现会明显逊色于Swift”。从以上摘录的一些对特定产品的分析来看，每一种存储技术架构都有其特定的优势和劣势。我们不仅仅需要根据数据梳理分析的结果确定什么样的数据放在集中式架构上，什么样的数据需要放在分布式架构上，我们更需要根据这些架构的优劣分析确定应该放在什么样的集中式和什么样的分布式上。2.存储资源类型的选择存储资源类型包括Object、Block、FS这些资源类型，如何将这些资源匹配到合适的场景上？可能对于Block来讲，大家比较容易做判断，一般会把企业业务系统当中关系数据库的结构化数据放在Block资源上，根据业务性能需求在Block资源上再做个细分。例如我们根据数据梳理结果当中的性能要求、并发访问、重要性等方面的综合分级与Block资源池当中的性能分级对应并做分别对应。同时，我们需要考虑其中的变化因素，因为数据业务访问的指标是动态的，原有的匹配很可能会与实际的变化产生冲突，这个时候就需要缓冲资源的设计以及自动化平衡策略的利用，例如集中式存储当中的分层策略。对于Object和FS来讲，可能有些人容易混淆。比如对于图片数据，似乎放在FS资源池和Object资源池没有太大区别。对于小规模的数据量来讲，如果应用接口没有限制，那么确实底层存储资源池类型的选择没有那么清晰。但是如果考虑到存量和未来的数据量规模、数据平均大小、数据访问特点等因素，就需要做一个准确的判断了。FS存储资源的访问是要依赖树状的索引，而Object存储资源的访问是靠哈希计算的支持。当数据量到达一定规模之后，索引的扫描显然要差于哈希的计算。从访问特点适应性来看，索引的随机性也会差于哈希的随机性。因此，虽然很多存储架构可以在上层进行接口的整合，比如Ceph可以基于Object实现Block和FS，但是从技术架构的选择上来讲，准确直接更有效。五、存储资源管理设计1.数据应用接口说到数据应用接口，其实主要是借用公有云思维的产物。无论是腾讯云还是阿里云，几乎都可以看到公有云上的一些特殊存储产品，它们是基于特定应用场景数据设计出来的优化存储服务产品。比如针对云盘、备份数据、视频数据、图片数据、镜像数据等专门设计的存储资源服务。用户不再需要关心底层基础架构的规划、配置、优化等方面的事宜，因为这些事情已经被整合到存储资源池的设计当中了。作为企业来讲，其实是有一些特定场景下的数据可以如此设计的，尤其是对一些书库类型单一、数据膨胀速度较快、数据量规模较大的场景：比如金融企业的影像平台数据，可以考虑将对象存储资源和文档数据库整合形成一个完整的闭环存储资源服务接口。2.云化管理思维虽然存储技术架构会有精准的选型匹配要求，但是基于未来膨胀式的数据发展规模以及不断变化的基于互联网模式的业务革新，对于数据的管理也不可能依靠有限技术工程师的精准管理了，需要在资源管理、配置优化、运维管理等方面实现相应的标准化、自动化以及智能化。这一点也需要向公有云借鉴。首先，从资源的注册请求、创建配置、分配发布到资源的注册销毁、对象消除、回收控制都需要基于统一的平台接口实现应用标准化调用，我们只需要在管理应用中定义符合企业标准的资源管理流程；其次，从动态性管理来讲，无论是虚拟资源的增加减少以及物理资源的拓扑变化，都应该以运维数据为支撑建立自动化的控制标准，同样以管理应用调用的方式来实现全自动化，而不是传统虚拟化模式下的半自动化。再有，从运维角度来看，一方面运维采集的数据不再应该是设备日志了，采集的数据应该扩展到外部访问和内部系统变化相关的系列数据体系上，不仅仅