热门标签 | HotTags
当前位置:  开发笔记 > 编程语言 > 正文

分布式存储_面向核心业务的全闪分布式存储架构设计与实践

本文由编程笔记#小编为大家整理,主要介绍了面向核心业务的全闪分布式存储架构设计与实践相关的知识,希望对你有一定的参考价值。
本文由编程笔记#小编为大家整理,主要介绍了面向核心业务的全闪分布式存储架构设计与实践相关的知识,希望对你有一定的参考价值。






Q
ingStor NeonSAN 是一款面向核心业务设计的全闪分布式块存储,打破了传统存储的容量与水平扩展的瓶颈,性能可以媲美全闪中高端存储阵列,
能够很好支持 Oracle RAC 等关键应用,在金融、电力、广电、制造、测绘等行业广泛落地。







我们将在本文中揭开 NeonSAN 架构的神秘面纱,介绍她是如何做到高性能和高可靠的产品体验,并在最后详细分享一个典型案例:NeonSAN 替换 Oracle 一体机,承载某大型保险集团 OLTP 和 OLAP 系统,满足数据不断增长的互联网金融业务需求。







1







面向闪存的三种存储方案






如下图所示,目前业界基于全闪的存储方案主要有以下三种:








1. 
传统方式






因为传统的存储诞生在机械盘的时代,是面向机械盘设计的,IOPS 通常在一百左右。而当前主流 NVMe SSD 的性能已经达到百万 IOPS 级别。这两类存储介质的机制迥异。






受限于底层架构的设计,传统存储并没有针对全闪进行有效的软件改造或者优化,无法全部发挥 NVMe SSD 的性能,此类方案已经不再适合承载高速闪存介质。






2. 
全闪阵列






全闪阵列的性能相比传统方式有了很大提升。






但是,全闪阵列通常采用专有的硬件,成本高昂。另外,传统阵列一般采用双控制器互为备份,纵向扩展无法提升性能,横向扩展受限于控制器的数量。这使得全闪阵列无法灵活适应数据爆发增长的业务场景。






3. 
全闪分布式存储






分布式存储是通过网络将存储节点联系在一起,以集群的形式提供服务。






通常采用通用的 X86 硬件,使硬件标准化,可以降低 TCO。
集群中每一个节点都具备存储和计算能力,随着节点的增加集群的容量和性能得到线性扩展。
无中心设计使集群不易形成瓶颈节点,理论上可以无限扩展。
针对 NVMe SSD 进行特殊的设计和优化,性能强劲。





另外,随着 25G、100G 网络的普及和 RDMA 网络低延迟的特性,使得分布式全闪的跨节点扩展不再是瓶颈。在全闪存和高速RDMA 网络的加持下,分布式全闪架构已经成为企业核心业务的理想之选







2







企业级分布式块存储







关于 NeonSAN 名字的由来:后半部分是SAN代表了产品的形态;Neon 是元素周期表里面氖的代号,是一种惰性气体,具有极高的稳定性。所以 
NeonSAN 的名字寓意着这是一款稳定的企业级存储产品。








面向核心业务的全闪分布式存储架构设计与实践


NeonSAN 核心模块由数据层和控制层组成,此外包括前端接口与运维管理工具层。






NeonSAN 核心模块采用并行流水线技术,设计了全闪存储系统的资源调度系统、内存管理系统、元数据管理系统、RDMA 网络收发系统等,打造高可用、高可靠、高性能、扩展灵活的全闪分布式存储。






NeonSAN 提供 9 个 9 可靠性,单卷性能达到 10 万 IOPS,最小延迟小于 90 微秒。






在扩展方面,NeonSAN 可以扩至 4096 节点,容量和性能随节点的增加而线性增长。






面向核心业务的全闪分布式存储架构设计与实践






NeonSAN 的基本架构是由 Zookeeper 服务、元数据服务、管理服务、存储服务和接入服务五部分构成。








Zookeeper 提供集群的发现服务;元数据服务用来记录集群中的元数据,如节点信息、SSD 的信息、卷信息等;






管理服务提供集群的管理功能,如节点的上线、创建卷等。






数据存储服务用来给客户提供具体的  I/O,承载业务发来的  I/O 请求。
其采用对等的设计,每个存储节点的地位是相等的,都可以提供  I/O 服务。






对等设计可以保证集群的某一个节点发生故障时,其他节点能够接替故障节点继续服务,保证业务的连续性,同时为集群的容量和性能线性扩展提供基础。






接入服务,第一个模块是 QBD 内核驱动,在 Windows Server 和 Linux Server 上都有对应的版本,它可以让服务器以使用本地盘的方式使用 NeonSAN,上层业务不需要做任何改造就可以对接 NeonSAN,非常方便。






第二个模块是 QEMU,可以为虚机提供云硬盘。






第三个模块是通用的 iSCSI 接口,可以为 VMware 等虚拟化平台提供存储服务。






第四个模块是 NVMe-oF 接口,提供端到端的高速数据传输服务,具备非凡的性能。






此外,还提供 CSI 接口,为容器提供持久化的存储服务。其支持提供克隆、快照、QoS、在线扩容等高级功能。






3







如何满足网络高可靠和高可用







NeonSAN 的网络分为两部分:前端业务网络和后端互联网络,采用两个前端交换机和两个后端交换机,组建高可用网络。






每个 NenonSAN 节点配备双网卡,每张网卡有两个网口,分别连接到后端交换机和前端交换机。


面向核心业务的全闪分布式存储架构设计与实践



假如交换机 A 发生故障就会影响到 NeonSAN 1、2、3 节点的网卡 A,凡是通过这些网卡进行交互的业务也会受到影响。此时 NeonSAN 节点就会自动把网络流量切换到网卡 B 上,走交换机 B,保证整个集群网络的可用性。







4







如何满足数据高可靠和高可用






NeonSAN 的数据可靠性及可用性是通过副本机制来实现的。







在 Linux 服务下看到块设备,或者在 Windows Server 下我们看到一张盘,对应到 NeonSAN 集群里,就会把这个盘切成一片片的 Shard。





面向核心业务的全闪分布式存储架构设计与实践







如上图所示,有红、黄、绿、紫这四个片,每一片都会有三副本,分别存放在不同的节点。任何一个节点上的数据损坏,都不会导致数据的丢失。






如果节点 1 不能提供服务,节点 2 或 3 可以继续提供服务,保证整个集群的可用性。






NeonSAN 的数据写入是三个副本同时写入,保证数据间的强一致性。数据的读取是从主副本读的。数据的副本可以按卷进行灵活的配置,在一个集群中既可以有单副本的卷,也可以有两副本的卷,还可以有三副本的卷。





NeonSAN 支持精简置备和全置备,一个集群可以同时存在精简置备的卷和全置备的卷。





面向核心业务的全闪分布式存储架构设计与实践






我们通过一个例子来介绍 NeonSAN 强一致性写过程中的 I/O 路径。






首先,客户端发  I/O 给三副本的主副本节点,当主副本节点收到  I/O 请求后会同时做两件事:将  I/O 请求发给它本地的 SSD,同时也会把这个请求发给两个从副本。当两个从副本 I/O 完成以及本地的  I/O 同时完成后才会返回给客户端写成功,实现强一致三副本的写入。






5







NeonSAN 的独门秘籍






NeonSAN 是一个面向全闪的分布式存储系统,针对全闪有哪些特殊的设计?




面向核心业务的全闪分布式存储架构设计与实践







首先, NeonSAN 采用了
极短  I/O 路径
,这是可以提供卓越性能的根本。








NeonSAN 只要 3 步就可以完成一个  I/O,当客户端的  I/O 发到存储节点后,存储软件做完处理后直接发给本地的 SSD。






业界某些分布式存储,比如 Ceph,却要经历很多步骤:先经过存储软件的处理,再发给本地文件系统,还要写日志,某些系统还需要再经过缓存,最后才能落到 SSD,这个  I/O路径是非常长的。简单来说就是很慢。






NeonSAN 采用自研 SSD 管理模块直接管理本地裸设备,不依赖本地的文件系统,不需要日志,也不需要 Cache,极大精简了  I/O 路径,从而让延迟减少到最低,接近于 SSD 延迟的量级。






面向核心业务的全闪分布式存储架构设计与实践






传统机械盘只有 1 个队列,深度是 32,NVMe SSD 一般盘有 128 个队列,每个队列的深度是 128,还采用传统的软件设计,显然 NVMe 是处于饥饿的状态,无法发挥队列和深度优势。






NeonSAN 采用并行流水线,将  I/O 进行拆分,拆分成接收、调度和落盘。






举个例子,在机械盘的年代就像超市只有 1 个收银台,只能排 1 队。但是到了 NVMe SSD 时代,超市有 128 个收银台。如果我们还排 1 队就对资源造成极大的浪费,所以需要采用多个队列并行 I/O,充分发挥 NVMe SSD 本身的性能,提升 SSD 的使用率。






面向核心业务的全闪分布式存储架构设计与实践






在微秒的 SSD 时代,操作系统逐渐暴露出一些问题。比如低效 CPU 核心调度和内存资源的竞争,以及调度时的切换等带来了巨大的延迟。






在高并发的压力下,多核心 CPU 的竞争与不合理的调度成为性能的瓶颈。NeonSAN 专门设计了资源调度引擎,避免由于调度问题和内存争抢问题带来的延迟开销。






首先,在网卡上我们分配专门的接收与解析  I/O 流水线,针对  I/O 调度流水线我们给它分配了独享的 CPU,避免调度流水线来回切换产生不必要的上下文开销,做到特定的 CPU 服务专门的流水线。






在内存方面,在系统软件启动时一次申请所需内存,根据不同流水线需求的多少按需分配给接收与解析 I/O 调度、数据落盘等流水线,避免在 I/O 过程中频繁申请与释放,带来的访问页表、内存锁等额外开销及内存碎片问题。






资源调度引擎保障了 NeonSAN 在获得高效 I/O 的同时将延迟控制在很低的水平。






面向核心业务的全闪分布式存储架构设计与实践






分布式存储是依赖于网络的。NeonSAN 将业务与数据网络分离,存储网络中的  I/O 不会对业务网络造成压力,避免资源的竞争。






NeonSAN 采用端到端的 RDMA 网络设计,无论是存储内部节点之间还是存储服务和客户端之间都采用了 RDMA 网络。





RDMA 网络的内核旁路(kernel bypass)与零拷贝的特点让网络中的单个  I/O 延迟变得非常低,基于异步的消息机制能让多个 I/O 的并发显得效率更高。







6







压力和性能测试






上面介绍了 NeonSAN 的基本架构与面向全闪的特殊设计,接下来看看 NeonSAN 的真实性能表现。





面向核心业务的全闪分布式存储架构设计与实践



从 E 企研究院的测试结果可以看到:在两个客户端压力下,随着卷数量的增加,NeonSAN 集群提供的性能线性增长,延迟几乎不变。






以 4K 写为例,单个卷的 IOPS 是 13 万多,4 个卷的 IOPS 增加到 47 万,接近线性增长;单个卷的延迟是 0.943 毫秒,4 个卷的延迟基本没什么变化。







7







典型案例







面向核心业务的全闪分布式存储架构设计与实践






在采用分布式架构之前,用户采用 Oracle SuperCluster Solaris 平台,采购与维保费用昂贵,且扩容复杂,无法快速适应业务发展的需求。








于是客户把视角转到了基于 X86 计算与存储分离的分布式架构,采用三节点全闪配置的 NeonSAN 作为存储节点,配置三副本用于Oracle 数据库存储卷。






截止2020年底,用户已经完成了数次扩容,NeonSAN 整体规模已经达到了几十个节点,承载 OLTP 和 OLAP 业务,满足数据不断增长的互联网金融业务需求。






案例详情,请点击文末“相关文章推荐 -- 某大型保险集团在线财险业务系统分布式存储架构实践"。






面向核心业务的全闪分布式存储架构设计与实践






NeonSAN 分布式存储方案的优势主要体现在以下几个方面:






首先,采用计算与存储分离的全分布式架构后,海量的数据压力分散到了多个并发存储节点,系统性能、吞吐量按照线性扩展。






其次,全闪的存储节点之间采用 RDMA 互联,性能提升 100% 以上,存储系统提供负载均衡机制,有效避免单点性能瓶颈。





通过开放的 X86 平台取代了传统数据库一体机与集中式存储设备,大幅缩短了存储系统的建设与扩容周期,有效满足业务数据量激增的扩容需求,同时大幅度节省采购、维护与运营成本。







8







总结













N
eonSAN 针对全闪等新型存储介质进行的架构设计,能够提供高可靠、高可用,性能卓越的存储服务,其丰富的接口,可以承载数据库等传统应用,原生适配虚拟化、大数据、容器等多种应用生态,服务云时代高效的数据存储和管理,








NeonSAN 具备丰富的企业级特性,基于同步及异步的数据复制可以灵活构建各类灾备和双活解决方案。经过大量企业客户核心业务的长期验证,NeonSAN 是一款真正可以承载企业核心业务的全闪分布式存储产品。






本文作者:魏国武, QingStor 资深研发工程师












点击阅读原文或扫描二维码




免费试用 QingStor 企业级分布式存储



















- FIN -










相关文章推荐


















































推荐阅读
  • Spring Cloud因其强大的功能和灵活性,被誉为开发分布式系统的‘一站式’解决方案。它不仅简化了分布式系统中的常见模式实现,还被广泛应用于企业级生产环境中。本书内容详实,覆盖了从微服务基础到Spring Cloud的高级应用,适合各层次的开发者。 ... [详细]
  • 本文探讨了现代分布式架构的多样性,包括高并发、多活数据中心、容器化、微服务、高可用性和弹性架构等,并介绍了与这些架构相关的重要管理技术,如DevOps、应用监控和自动化运维。文章还深入分析了分布式系统的核心概念、主要用途及类型,同时对比了单体应用与分布式服务化的优缺点。 ... [详细]
  • 58同城的Elasticsearch应用与平台构建实践
    本文由58同城高级架构师于伯伟分享,由陈树昌编辑整理,内容源自DataFunTalk。文章探讨了Elasticsearch作为分布式搜索和分析引擎的应用,特别是在58同城的实施案例,包括集群优化、典型应用实例及自动化平台建设等方面。 ... [详细]
  • 腾讯视频 Node.js 服务国庆阅兵直播高并发实战
    本文分享了腾讯视频团队在国庆阅兵直播项目中,如何利用Node.js服务成功应对2.38亿次观看的高并发挑战。文章将从服务架构、可用性保障、缓存策略、日志与告警等方面详细解析。 ... [详细]
  • 深入解析Serverless架构模式
    本文将详细介绍Serverless架构模式的核心概念、工作原理及其优势。通过对比传统架构,探讨Serverless如何简化应用开发与运维流程,并介绍当前主流的Serverless平台。 ... [详细]
  • PostgreSQL 最新动态 —— 2022年4月6日
    了解 PostgreSQL 社区的最新进展和技术分享 ... [详细]
  • 并发编程 12—— 任务取消与关闭 之 shutdownNow 的局限性
    Java并发编程实践目录并发编程01——ThreadLocal并发编程02——ConcurrentHashMap并发编程03——阻塞队列和生产者-消费者模式并发编程04——闭锁Co ... [详细]
  • 本文深入探讨了MySQL中常见的面试问题,包括事务隔离级别、存储引擎选择、索引结构及优化等关键知识点。通过详细解析,帮助读者在面对BAT等大厂面试时更加从容。 ... [详细]
  • 本文详细介绍了如何在 Android 中使用值动画(ValueAnimator)来动态调整 ImageView 的高度,并探讨了相关的关键属性和方法,包括图片填充后的高度、原始图片高度、动画变化因子以及布局重置等。 ... [详细]
  • 全能终端工具推荐:高效、免费、易用
    介绍一款备受好评的全能型终端工具——MobaXterm,它不仅功能强大,而且完全免费,适合各类用户使用。 ... [详细]
  • 热璞数据库与云宏达成兼容性互认证,共筑数据安全屏障
    热璞数据库与云宏信息技术有限公司近期宣布完成产品兼容性互认证,旨在提升数据安全性与稳定性,支持企业数字化转型。 ... [详细]
  • 收割机|篇幅_国内最牛逼的笔记,不接受反驳!!
    收割机|篇幅_国内最牛逼的笔记,不接受反驳!! ... [详细]
  • 数据集成策略:ETL与ELT架构对比及工具选择
    随着企业信息化的深入发展,‘数据孤岛’问题日益突出,阻碍了数据的有效利用与整合。本文探讨了如何通过构建数据仓库解决这一问题,重点分析了ETL与ELT两种数据处理架构的特点及适用场景,为企业选择合适的ETL工具提供了指导。 ... [详细]
  • ElasticSearch 集群监控与优化
    本文详细介绍了如何有效地监控 ElasticSearch 集群,涵盖了关键性能指标、集群健康状况、统计信息以及内存和垃圾回收的监控方法。 ... [详细]
  • 本文详细探讨了虚拟化的基本概念,包括服务器虚拟化、网络虚拟化及其在云计算环境中的应用。特别强调了SDN技术在网络虚拟化和云计算中的关键作用,以及网络虚拟化技术如何提升资源利用效率和管理灵活性。 ... [详细]
author-avatar
时刻要有危机感01
这个家伙很懒,什么也没留下!
PHP1.CN | 中国最专业的PHP中文社区 | DevBox开发工具箱 | json解析格式化 |PHP资讯 | PHP教程 | 数据库技术 | 服务器技术 | 前端开发技术 | PHP框架 | 开发工具 | 在线工具
Copyright © 1998 - 2020 PHP1.CN. All Rights Reserved | 京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有