企业云平台存储架构设计方案.docx

企业云平台存储架构设计方案 企业信息化转型过程中，似乎都要带上个“云”字才会显得高大上。但是似乎没有几个人能清楚描述出云平台存储到底是什么？它应该包含哪些对象、元素、技术等？彼此联系如何？企业如何设计云平台存储架构？在我们自己的企业当中，如果我们完全没有融入到公有云当中，仅仅是自身企业的私有云，那么是否有必要仿照公有云的模式实现一套大而全的云存储架构呢？个人觉得没有必要，也没有办法去完全仿照。首先，我们来看业界对云存储的不同理解。百度百科曰“云存储是一种网上在线存储的模式，即把数据存放在通常由第三方托管的多台虚拟服务器，需要数据存储托管的人，则透过向其购买或租赁存储空间的方式，来满足数据存储的需求。”阿里白皮书曰“云存储作为将储存资源放到云上供行为对象任意时间、任意地点，只要有网络连接即可存取的技术，依托其便利性和弹性按需的低成本优势伴随着云计算技术一起迅猛发展，势不可挡。”红帽曰“云存储是通过互联网对存储资源进行抽象化、汇集和共享。云存储由称为云的 IT环境推动，使云计算能够在云环境中运行工作负载。云存储有 3 种：公共云存储、私有云存储和混合云存储。”权威杂志曰“云存储是在云计算概念上延伸和发展出来的一个新的概念，是一种新兴的网络存储技术，是指通过集群应用、网络技术或分布式文件系统等功能，将网络中大量各种不同类型的存储设备通过应用软件集合起来协同工作，共同对外提供数据存储和业务访问功能的一个系统。”从以上观点来看，我们可以明确三点：1）关于云存储，众说纷纭尚无定论；2）云存储在大多数人眼里肯定不是通用产品，而是一个技术框架或体系；3）互联、伸缩、共享、软件定义、协同集成是业界认可的云存储表现出来的特点。接下来，将从不同维度探讨分析个人理解的云存储及云存储架构。首先，我们借助于公有云上的通用云存储架构开始说起对其的理解：如图1所示，通常的公有云存储资源架构从上到下会分为4-5个层面，暴露给用户的是最上面的“云存储应用资源接口层”，它会供给很多应用申请接口。图1 公有云存储通常框架图示有基础存储服务类接口：例如Block存储、文件存储、对象存储.有通用数据类存储服务接口：例如媒体存储、日志存储、图像存储、备份存储.还有一些与数据存储相关的其他服务：例如数据迁移。接下来云存储管理调度模块会将需求注册并且分配正确的存储对象实例，也就是到了“数据服务对象层”，这一层实际上并不是真正的数据存储空间，而是基于不同数据存储接口的服务实例。再下一层的“分布式文件系统层”，它是数据的底层载体，多数的公有云云存储底层的分布式文件系统都类似于GFS的Client-Master-Chrunk架构，但是各家产品在GFS的基础原理之上，优化了很多用来保障系统稳定性、安全性以及高性能的架构细节。例如将Master由单节点变为集群、元数据多副本等来保障元数据的可靠性；将数据存储索引横向分布在多个Master实例上，保障元数据读写的性能；增加以RDMA、SSD等技术为基础的软件定义功能，实现性能的量级提升。“基础功能层”实际上就是直接敷设在裸机之上的虚拟软件基础层，类似底座功能。通常它是基于通用服务器逻辑虚拟化之后形成的具备管理、调度、安全、协同等基础功能的底座软件。从以上架构的简单描述，我们可以理解到公有云通用云存储架构的几点特性：1）互联网络化：基于互联网诞生，基于高速网络技术完成海量数据的瞬间吞吐，基于网络对外提供服务，基于网络隔离技术实现租户的隔离。2）应用服务化：从传统的Block、NAS、OBJ存储资源提供模式转变为Block、NAS、OBJ、NoSQL、NewSQL的统一服务接口提供模式，并且在此基础之上抽象出特定应用场景的应用服务接口。存储资源利用越来越靠近应用层。3）分布式架构：在整个云存储架构体系当中，有太多太多的分布式元素在其中。不仅仅底层的数据载体层是纯粹的分布式架构（元数据&Chrunk数据），而且很多在其之上的存储对象也是分布式架构，尤其是NoSQL、NewSQL类的数据库类存储服务对象。4）自动化：传统模式下，需要一个非常优秀的架构师才能完成从应用需求的梳理到数据存储服务对象的选型及设计，再到合适存储卷的规划和配置，再到底座层资源数量规格的规划等一系列工作。而且架构师的能力直接关系到整体系统的可靠性和发展性。但是云存储架构体系当中融入了太多的自动化基因，使得用户只需要注册申请资源，其他的映射关系完全由云存储平台本身自动完成。最后，我们回到传统企业自身的数字化转型过程当中。在我们自己的企业当中，如果我们完全没有融入到公有云当中，仅仅是自身企业的私有云，那么是否有必要仿照公有云的模式实现一套大而全的云存储架构呢？个人觉得没有必要，也没有办法去完全仿照。一、为什么没有必要？首先，共有云上的存储服务对象有太多太多种，它的客户对象是所有的行业。而对于特定行业中的个体企业来讲，不是说所有的存储服务对象都能用得到，作为个体企业用到的可能是某一个子集。其次，个体企业所需要的存储服务需求相对稳定、简单、可预见，与其投入大量的人力才力放在大而全上，还不如把有限的经历放在小而精上。再次，与公有云相比较而言，个体企业的数据规模、节点规模、负载规模完全发挥不出来互联网式的分布式规模效应，某些为此的投入从某种意义上讲就是浪费。二、为什么没有办法？首先，从公有云的IT人力投入上讲，个体企业完全不具备条件，何以保障生产运营过程当中的快速创新、快速解决BUG、快速迭代？每一段有价值代码都是很多人的智慧和实践换来的。其次，从IT人员的技术延展性来看，公有云的IT人员侧重于纯技术的锤炼，个体企业当中的IT人员侧重于更懂自己企业的业务系统特性。这两种人究竟哪一种放在自己的企业当中从事IT工作的价值更大，我想不言而喻。再次，公有云的云存储架构是经过了互联网发展的若干年以及千万种问题场景逐步演变过来的，这里面有千万个代码的改变都是基于特殊的时间、特殊的场景、特殊的问题促成的。这个也是个体企业无法经历的。那么对于个体企业来讲，应该寻求什么样的云平台存储架构？借助于图2，我们来描述企业私有云环境下的云存储架构应该是什么样的。在这里，我们仅仅从几个需要区别或者需要做出变化的层面重点强调。图2：私有云云存储框架图示如图2所示，首先，最核心的是要选择中间的“稳定成熟的分布式存储、集中式存储产品”，我们选择的标准要看其安全性、稳定性、上层的二次开发包容性以及下层的兼容性这个需要结合企业业务系统及数据特性来从技术原理上、使用案例上、经历时间上等各方面来考量。其次，产品本身要与我们既有的或者即将选择的私有云底座平台软件有很好的兼容性。这个也需要通过各维度进行分析评估。再次，通过本身的接口以及提供的二次开发接口来实现适合企业自身的“数据服务对象层”，不需要大而全，但是一定要在自身企业IT场景当中灵活易用。陈萍春 利安人寿资深工程师：存储架构设计需要去深入理解具体存储方案的架构和实现原理，找出存储方案中的风险点，并且很有必要通过恰当的测试方案去验证。需求分析云平台存储需要符合云平台的整体设计需求，但最终还是为企业业务应用服务的。云平台存储的需求分析不能只关注与云平台的对接适配需求，还需要重点关注企业业务数据的存储需求，即数据存储分层分级需求。数据存储分层分级应在满足不同类型业务系统存储需求的基础上，降低云平台存储整体成本，结合我司业务情况分为：1）核心业务类型系统及其数据库，需要最高的存储性能和可靠性，性能更关注于IO延时；2）其他轻量级数据库，需要较高的存储性能和可靠性，需关注IO延时性能；3）数据分析类应用及其数据库，存储扩展性要求高，性能更关注于IO吞吐；4）互联网类新业务和一般业务应用，需要较好的扩展性，有一定的IO延时性能要求；5）非结构化类型业务数据，存储扩展性要求高，性能更关注于IO吞吐。架构设计方法根据需求分析阶段的数据存储分级结果，又可将核心业务应用、数据库等归类为稳态类应用场景，其更关注于存储可靠性，存储IO size小，性能更关注于IO延时；而互联网类新业务、一般业务应用和数据分析类则可归类为敏态类应用场景。针对稳态和敏态的存储架构如何设计，主要是采用两种不同的架构设计方法： 自顶向下：自顶向下是从整体架构出发，逐步求精，去分析设计云平台存储通用框架及其组成元素。该设计分析方法既需要对问题域有清晰的了解，对行业未来一段时间内的应用场景有清晰的认识，又需要能把控住求解域，对云平台存储技术发展和应用有深刻的认识。 自底向上：与自底向上方法则相反，针对实际需要解决的问题，去做存储的技术选型，逐步搭建云平台存储架构框架，从具体到抽象。整体来看，稳态类应用场景更偏向于稳定可靠的存储方案，稳态的业务量增长是规律的，容量是可预估的，系统架构稳定，有着明确的业务连续性和数据安全需求。因此稳态类应用场景是适合采用自顶向下的架构设计分析方法的，存储方案可选择更加稳定可靠的企业存储，落地前需要做好充分测试和整体存储架构规划，减少存储架构方案的不确定性，尽量避免后期存储架构的调整。而敏态类业务的起伏变化较大，系统架构从简单到复杂，要求弹性伸缩，架构可扩展。稳态类场景的存储需求就是有不确定性的，存在着较大的差异。以自顶向下的架构设计思路来看，扩展性和包容性是敏态类存储架构最需要满足的特性，这也是一个绕不开的难点，过于强调扩展性和包容性，又会带来性能、成本和复杂性的问题。但是可以改变思路，采用自底向上的架构设计分析方法，去专注考虑实际场景的确定性部分。自底向上的架构设计降低了整体规划设计的复杂性，是追求快速应用落地，根据各种敏态类业务应用场景，去评估落地适合的存储方案，在实践过程中去推进云平台存储架构框架的演进。架构权衡和风险点评估架构权衡是对需求做权衡取舍，在存储架构设计中有太多的需求，而众多需求之间往往会互相限制。比如说，存储的软硬件成本会很大程度上影响存储的可靠性和性能，高可靠性很多时候也是需要牺牲成本和性能来实现的，灵活扩展能力往往又会带来更高的架构复杂度。架构设计也是一个需求的权衡评估过程，需要适当舍弃部分非关键的需求，去优先满足那些最关键的需求。风险点评估也是需要重点关注的，也是架构设计成败的关键。存储架构设计需要去深入理解具体存储方案的架构和实现原理，找出存储方案中的风险点，并通过恰当的测试方案去验证也是很有必要的。一般来说，风险点包括：方案的成熟度和稳定性风险、性能风险、新版本风险、扩展能力不足、架构适配风险、运维风险等等。这些风险点甚至会直接关系到存储架构方案的可行性，不可谓不重要。结合企业实际业务需求，做好架构权衡和风险点评估，才能设计出更合理的存储架构。张俊禧 长安银行存储架构师：构筑企业的云平台存储可以使企业适应快速迭代创新的业务发展，在市场占得先机，可以提升企业运维管理水平，迈出上云的第一步。部署云平台存储是企业私有云建设的重要环节。云平台存储将企业内部的各种存储资源云化管理，企业的私有云管理平台调用各类接口驱动存储资源的弹性的配置，云原生的应用和传统的应用都可以在“云里”自如地获取所需的存储资源。如何将数据中心的各种存储设备“搬上云”？本文对“金融企业如何设计私有云平台存储”这一课题贡献一些思考。为金融企业设计云平台存储，首先要规划将要建设的私有云应具备哪些基本的存储服务能力，换言之，根据业务需要将具体的存储设备抽象成IaaS层哪些存储服务，这一层设计不需要考虑具体的产品形态。下图（图3）整理了金融企业典型的业务及对存储访问接口、性能和容灾能力的要求。图3：业务及对存储访问接口、性能和容灾能力的要求图中比较有代表性的是：1）关键交易型数据库通常使用块存储，对存储性能要求高，对存储容灾要求高，企业级全闪存存储满足这些要求；而内部报表分析型数据库批量处理对存储压力较大，综合投入角度考虑，也需要配置性能较好的块存储，存储的档次可以略低些。2）关键交易型应用，特别是互联网业务，多数已经采用无状态应用开发模型，特别适合使用容器形式部署，目前先进存储厂商已经在企业级存储上支持CSI接口，并且VMware及分布式存储也广泛支持容器。3）金融行业通常使用对象存储处理非结构化的数据，越来越多的应用开始支持S3接口。4）文件存储适合应用节点间需要共享数据的情况，文件也是经常用到的存储接口。总体看，金融企业业务可能会用到块、文件、容器、对象四种接口，对应云平台存储的四种基本存储服务能力。同时按照业务对性能和容灾的不同要求，四种存储能力分别在两个维度还可以细分。设计云平台存储就是要将企业内部孤立的具体的存储设备转化成云上的服务，同时把具体的存储空间从申请到销毁整个生命周期的运维操作转化成云上自助服务的流程和底层一系列自动化的操作。云平台存储是企业私有云的整体建设一个环节，通常需要通盘考虑计算、网络及业务上云。下图（图4）说明了云平台存储从物理设备直到云服务是如何被构建出来的。图4：云平台存储从物理设备直到云服务如何被构建示意图根据上图数据中心全部的云计算技术首先建立在某种Hypervisor层之上，Hypervisor安装在服务器上与存储本身关系不大。云平台存储是云管理平台软件对各种存储服务的实现，比较有代表性三种情况是：1）常见国产分布式存储（或称为软件定义存储）本质上是基于网络的集群文件系统，在此基础上再构建出块、文件及对象等存储服务，代表性的是基于Ceph开发的产品。2）以CSI和S3为代表的接口，存储设备支持相关协议，Kubernetes容器编排平台可以直接调用CSI访问存储，应用可以直接调用S3接口访问存储，这两种接口的实现几乎不需要云管理平台再对存储进行封装。3）OpenStack实现比较复杂，使用具体存储厂商的驱动和存储设备直接对接，使用Cinder子项目配置块存储服务供计算节点使用，使用Manila子项目创建文件服务接口继而对接NFS等具体文件协议最终呈现文件服务能力。4）CSI（Container Storage Interface）为容器编排引擎Kubernetes和存储系统之间建立一套标准的存储调用接口，通过这个接口为容器编排引擎提供存储服务。上文说明了云平台存储的底层逻辑。云平台存储的设计可能经历以下几个阶段：1）云平台存储应首先和企业的CMDB对接，掌握企业全部的设备信息和配置信息。云平台存储后期的管理应与CMDB联动。2）云平台存储设计的前置工作将有条件的存储先池化统一管理。企业生产环境存在不同档次的存储，部分中端磁盘阵列或者一些购置较早的设备可能不支持新的接口或者不能适配云管理平台软件。这时有条件的企业可以用具有异构其他存储的企业级存储，先将中小阵列进行统一纳管，形成虚拟存储池，中小存储降级为空间供应者，由企业级存储负责与云平台对接。3）根据存储不同的性能和容灾保护情况进行分类分级，最终形成差异的存储服务。首先分析块存储，企业级存储可靠性高性能优异，已经部署了同城双活或者同步复制，分布式存储使用副本实现冗余，当它成为云的后端设备，完全可以跨故障域存放副本，也可以实现数据双活甚至多活。云平台存储应充分发挥不同存储的优势，根据业务的特点和需要从云里选取不同的存放位置。比如核心交易数据库，追求极致性能和可靠，可以分配双活的企业级存储；而互联网交易场景已经使用容器+微服务架构开发，要求弹性高，比较适合使用分布式环境，可以为其分配分布式块存储，而且多副本也保证了数据安全。文件的情况与块类似。其次，对象可以直接被应用调用方法问，适合存放非结构化数据。由于对象存储不涉及数据一致性的问题，可以两站点甚至多站点部署。对象存储多站点部署数据使对象服务跨站点可用。第三，一些专用的接口可以直接为应用调用。例如有的厂商对象存储或分布式存储提供Hadoop HDFS接口，可以支持大数据的分析场景直接使用。4）云平台存储通过强大的编排组织串联起存储服务，实现存储运维场景化自动化。尽可能详细梳理生产环境会遇到的各种存储运维操作，将存储接口形象展示成云上丰富差异的存储服务目录，将具体的操作形成云上的流程节点，尽可能通过点选拖拽图标自助完成服务。例如，自动化的节点扩容、存储资源扩容回收、大型业务投产为各个应用匹配最精准的存储服务等。构筑企业的云平台存储可以使企业适应快速迭代创新的业务发展，在市场占得先机，可以提升企业运维管理水平，迈出上云的第一步。结束语综上所述，企业的云平台存储架构设计需要充分发挥互联网的环境优势，将服务化、动态化、敏捷化、智能化的元素融入到存储资源的管理当中。-全文完-