网站泛目录怎么做,宝洁公司网站建设案例,企业小程序建设公司,网站开发部职责简介#xff1a; 当前 NVMe 云盘结合了业界最先进的软硬件技术#xff0c;在云存储市场#xff0c;首创性同时实现了 NVMe 协议 共享访问 IO Fencing 技术。它在 ESSD 之上获得了高可靠、高可用、高性能#xff0c;同时基于 NVMe 协议实现了丰富的企业特性#xff0c;如…简介 当前 NVMe 云盘结合了业界最先进的软硬件技术在云存储市场首创性同时实现了 NVMe 协议 共享访问 IO Fencing 技术。它在 ESSD 之上获得了高可靠、高可用、高性能同时基于 NVMe 协议实现了丰富的企业特性如多重挂载、IO Fencing、加密、离线扩容、原生快照、异步复制等功能。本文详细介绍了云上SAN和NVMe的发展历程并做出了对未来的构想
7x24 高可用是怎样炼成的
现实世界中单点故障是常态确保故障下业务连续性是高可用系统的核心能力那么在金融、保险、政务等关键应用中如何保证业务 7*24 高可用通常来讲业务系统由计算、网络、存储组成在云上网络多路径和存储分布式确保了稳定高可用但要实现业务全链路高可用还要解决计算和业务侧单点故障。以常见的数据库为例单点故障导致业务停止对于用户难以接受那么当断电、宕机、硬件故障等导致实例不可服务时如何快速恢复业务
不同场景的解决方案有所不同MySQL 通常搭建主从/主备架构实现业务高可用主库故障时切换到备库持续对外提供服务。但实例切换后如何保证主从库数据的一致性根据业务对数据丢失的容忍度MySQL 通常采用同步或异步方式进行数据复制由此引入额外的问题部分场景下导致数据缺失、同步数据影响系统性能、业务扩容要新增整套设备并进行全量数据复制、主备切换时间较长影响业务连续性等。可以看到为了搭建高可用系统架构将变得复杂且很难兼顾可用性、可靠性、扩展性、成本、性能等那么是否有更加先进的方案兼得鱼和熊掌答案必须是Yes 图1数据库的高可用架构
通过共享存储不同数据库实例间可共享同一份数据从而通过计算实例的快速切换获得高可用图1Oracle RAC、AWS Aurora、阿里云 PolarDB 数据库就是其中的代表。这里的关键在于共享存储传统 SAN 价格高昂扩缩容麻烦机头也容易成为瓶颈其使用门槛较高对用户并不友好有没有更好、更快、更省的共享存储来解决用户的痛点呢阿里云最近推出的 NVMe 云盘和共享特性将充分满足用户的诉求接下来我们将重点介绍。这里给大家抛出一个问题在实例切换过后如果原库仍在写入数据如何保证数据正确性卖个关子读者可以先思考下。 图2主从切换场景的数据正确性问题
历史前进的车轮云上 SAN 和NVMe
我们已步入“数据石油”的数字经济时代云计算、人工智能、物联网、5G 等技术的快速发展促使数据的爆炸式增长。从 IDC 2020 年报告可以看出全球数据规模逐年增长2025 年将达到 175 ZB数据将主要集中在公共云和企业数据中心。数据的快速增长为存储的发展提供了新的动力和要求让我们回忆下块存储形态是如何一步步演进的。 图3块存储形态演进
DAS存储设备采用直连方式SCSI、SAS、FC 等协议与主机连接系统简单、易于配置管理、费用较低由于存储资源无法被充分利用和共享难以做到集中统⼀的管理和维护。
SAN通过专用网路连接存储阵列和业务主机解决了统一管理和数据共享等问题并实现高性能低延迟的数据访问不过 SAN 存储价格昂贵、运维复杂、可扩展性差提高了用户的使用门槛。
全闪底层存储介质的革命和成本的下降标志着全闪存时代的到来从此存储性能转移到软件栈迫使软件进行大规模的变革促进了用户态协议、软硬一体化、RDMA 等技术的高速发展带来了存储性能的飞越。
云盘云计算的高速发展历程中存储转移到云上云盘具有天生的优点灵活、弹性、易用、易扩展、高可靠、大容量、低成本、免运维等在数字化转型历程中成为存储坚实的底座。
云上 SAN为全方面支持存储业务取代传统的 SAN 存储云上 SAN 应时代而生它继承了云盘的诸多优势也具备了传统 SAN 存储能力包括共享存储、数据保护、同步/异步复制、极速快照等特性必将在企业存储市场持续发光发热。
另一端在存储协议的演进上NVMe 正在成为新时代的宠儿。 图4存储协议的演进
SCSI/SATA存储远古时代硬盘多为低速设备数据经过 SCSI 层和 SATA 总线传输数据性能受限于存储慢速介质如机械硬盘掩盖了 SATA 单通道和 SCSI 软件层的性能劣势。
VirtIO-BLK/VirtIO-SCSI伴随着虚拟化技术和云计算的快速发展VirtIO-BLK/VirtIO-SCSI 逐渐成为云计算的主流存储协议使得存储资源的使用更加弹性、敏捷、安全、可扩展。
NVMe/NVMe-oF闪存技术的发展和普及推动了新一代存储技术革命当存储介质不再成为性能的拦路虎软件栈成为了最大的瓶颈由此催生了 NVMe/NVMe-oF、DPDK/SPDK、用户态网络等各种高性能轻量级协议NVMe 协议族兼具高性能、高级特性和高扩展性必将引领云计算新时代。
在可遇见的未来云上 SAN 和 NVMe 必将成为未来的潮流这是大势所趋。
云盘新时代之 NVMe
闪存技术的迅速发展和普及将性能瓶颈转移到软件侧对于存储性能和功能的更多需求将 NVMe 推上了历史舞台。NVMe 专门针对高性能设备设计了数据访问协议相比传统的 SCSI 协议更加简捷轻量配合多队列技术能大幅度提升存储性能。同时 NVMe 还提供了丰富的存储特性NVMe 标准自 2011 年诞生以来通过不断完善协议规范了多 Namespace、Multi-Path、全链路数据保护 T10-DIF、Persistent Revervation 权限控制协议、原子写等众多高级功能其定义的存储新特性将持续帮助用户创造价值。 图5阿里云 NVMe 云盘
NVMe 的高性能和丰富特性为企业存储提供了坚实的基础加上协议本身具备的扩展性和成长性成为演进 NVMe 云盘的核心动力。NVMe 云盘以 ESSD 为基础它继承了 ESSD 的高可靠、高可用、高性能、原子写等能力以及 ESSD 原生快照数据保护、跨域容灾、加密、秒级性能变配等企业特性ESSD 和 NVMe 特性的融合能有效的满足企业级应用需求使大部分基于 NVMe 和 SCSI 的业务无缝上云。本文讲述的共享存储技术就是基于NVMe Persistent Reservation 标准实现作为 NVMe 云盘的附加功能之一其多重挂载和 IO Fencing 技术可以帮助用户大幅降低存储成本并有效提升业务灵活性和数据可靠性在分布式业务场景具有广泛的应用特别对于 Oracle RAC、SAP Hana 等高可用数据库系统具有重要价值。
企业存储利器共享存储
前面讲到共享存储可以有效地解决数据库高可用问题其主要依赖的能力包括多重挂载和 IO Fencing以数据库为例我们将讲述它们是如何发挥作用的。
业务高可用关键 -- 多重挂载
多重挂载允许云盘被同时挂载到多台 ECS 实例上当前最大支持 16所有实例均可读写访问该云盘图6。通过多重挂载多个节点间共享同一份数据能有效地降低存储成本。当单节点发生故障时业务可以迅速切换到健康节点该过程无需进行数据复制为故障快速恢复提供了原子能力如 Oracle RAC、SAP HANA 等高可用数据库均依赖该特性实现。需要留意的是共享存储提供了数据层的一致性和恢复能力若要达到最终业务一致性业务可能需要进行额外处理如数据库的日志 replay 等。 图6多实例挂载
通常单机文件系统不适合作为多重挂载的文件系统为了加速文件访问ext4 等文件系统会对数据和元数据进行缓存对于文件的修改信息无法及时同步到其他节点从而导致多节点间数据的不一致。元数据的不同步也会导致节点间对硬盘空间访问的冲突从而引入数据错。所以多重挂载通常要配合集群文件系统使用常见的有 OCFS2、GFS2、GPFS、Veritas CFS、Oracle ACFS 等阿里云 DBFS、PolarFS 也具备该能力。
有了多重挂载是否就可以高枕无忧了多重挂载并非万能它有自身无法解决的盲点权限管理。通常基于多重挂载的应用需要依赖集群管理系统来管理权限如 Linux Pacemaker 等但在某些场景下权限管理会失效从而导致严重问题。回忆下文章最开始抛出的问题在高可用架构下主实例发生异常后会切换到备实例如果主实例处于假死状态如网络分区、硬件故障等场景它会错误地认为自己拥有写入权限从而和备实例一起写脏数据如何规避该风险? 此时该轮到 IO Fencing 出场了。
数据正确性保证 -- IO Fencing
解决脏数据写入的可选方案之一是终止原实例的在途请求并拒绝新请求继续下发确保旧数据不再写入后切换实例。基于该思路传统的解决方案是 STONITHshoot the other node in the head即通过远程重启该故障机器来防止旧数据落盘。不过该方案存在两个问题首先重启流程过长业务切换较慢通常会导致几十秒到分钟级的业务停止。更严重的是由于云上 IO 路径较长涉及组件较多计算实例的组件故障如硬件、网络故障等都有几率导致 IO 在短时间内无法恢复所以无法 100% 保证数据的正确性。
为了从根本性解决该问题 NVMe 规范了 Persistent ReservationPR能力它定义了 NVMe 云盘的权限配置规则可以灵活地修改云盘和挂载节点权限。具体到该场景在主库发生故障后从库首先发送 PR 命令禁止主库的写入权限拒绝主库的所有在途请求此时从库可以无风险的进行数据更新图7。IO Fencing 通常可以在毫秒级别协助应用完成故障切换大幅缩短了故障恢复时间业务的平滑迁移使上层应用基本无感知相比于 STONITH 有了质的飞越。接下来我们进一步介绍 IO Fencing 的权限管理技术。 图7IO Fencing 在故障切换下的应用
权限管理的瑞士军刀 -- Persistent Reservation
NVMe Persistent Reservation (PR) 协议定义了云盘和客户端权限搭配多重挂载能力可以高效、安全、平稳地进行业务切换。在 PR 协议中挂载节点有 3 种身份分别是 Holder所有者、Registerant注册者、Non-Registrant访客从名字可以看出所有者拥有云盘全部权限注册者拥有部分权限访客只拥有读权限。同时云盘拥有 6 种共享模式可实现独占、一写多读、多写能力通过配置共享模式和角色身份可以灵活地管理各节点权限表1从而满足丰富的业务场景需求。NVMe PR 继承了 SCSI PR 的全部能力所有基于 SCSI PR 的应用可以通过少量的改动即可运行在 NVMe 共享云盘之上。 表1NVMe Persistent Reservation权限表
多重挂载配合 IO Fencing 能力可以完美搭建高可用系统除此之外NVMe 共享盘还能提供一写多读能力并广泛应用于读写分离的数据库、机器学习模型训练、流式处理等场景。另外镜像共享、心跳探活、仲裁选主、锁机制等技术可以通过共享云盘轻松实现。 图8NVMe 共享盘一写多读应用场景
NVMe 云盘技术揭秘
NVMe 云盘基于计算存储分离架构实现依托于神龙硬件平台实现了高效的 NVMe 虚拟化和极速 IO 路径以盘古2.0 存储为底座实现了高可靠、高可用、高性能计算存储通过用户态网络协议和 RDMA 互连NVMe 云盘是全栈高性能和高可用技术的结晶图9。 图9NVMe 共享盘技术架构
NVMe 硬件虚拟化以神龙 MOC 平台打造了 NVMe 硬件虚拟化技术通过 Send Queue(SQ) 和 Completion Queue(CQ) 进行数据流和控制流的高效交互简洁的 NVMe 协议加上高效的设计配合硬件卸载技术使 NVMe 虚拟化延迟降低 30%。
极速 IO 通道基于神龙 MoC 软硬一体化技术实现了极速 IO 通道有效缩短了 IO 通路进而获得极致的性能。
用户态协议NVMe 使用了全新一代 Solar-RDMA 用户态网络通信协议结合 Leap-CC 自研拥塞控制实现了数据可靠传输并降低了网络长尾延迟基于 25G 网络的 JamboFrame 实现了高效的大包传输通过数据面和控制面全面分离精简了网络软件栈并提升了性能网络多路径技术支撑了链路故障毫秒级恢复。
管控高可用以盘古 2.0 分布式高可用存储实现了 NVMe 控制中心NVMe 控制命令不再经过管控节点从而获得接近 IO 的可靠性和可用性可协助用户实现毫秒级别的业务切换基于 NVMe 控制中心实现了多客户端和多服务器间的精确流控在亚秒级内实现对于 IO 的精确分布式流控在分布式系统上实现了对于多节点的 IO Fencing 一致性通过两阶段更新使云盘分区之间权限状态保持一致有效解决了分区权限的脑裂问题。
大 IO 原子性基于分布式系统从计算、网络、存储端到端实现了大 IO 的原子写能力在 IO 不跨越相邻 128K 边界的条件下确保同一数据不会部分落盘这对于数据库等依赖原子写的应用场景具有重要作用它能有效优化数据库 double write 流程从而大幅提升数据库的写入性能。
当前现状和未来展望
可以看出当前 NVMe 云盘结合了业界最先进的软硬件技术在云存储市场首创性同时实现了 NVMe 协议 共享访问 IO Fencing 技术。它在 ESSD 之上获得了高可靠、高可用、高性能同时基于 NVMe 协议实现了丰富的企业特性如多重挂载、IO Fencing、加密、离线扩容、原生快照、异步复制等功能。 图10全球首次 NVMe 共享访问 IO Fencing 技术融合
目前 NVMe 云盘和 NVMe 共享盘已在邀测中并得到了 Oracle RAC、SAP HANA 和内部数据库团队的初步认证接下来它将进一步扩大公测范围并商业化。在可预见的未来我们会逐步围绕 NVMe 云盘持续演进以更好地支持在线扩容、全链路数据保护 T10-DIF、云盘多 namespace 等高级特性从而进化出全面的云上 SAN 能力敬请期待 Vendor 1 Vendor 2 Vendor 3 阿里云 云盘协议 SCSI SCSI NVMe NVMe 多重挂载 ✓ ✓ ✓ ✓ IO Fencing ✓ ✓ × ✓ 数据持久性 N/A 9个9 5个9 9个9 IO延迟 300 us 100~200 us 100~200 us 100 us 云盘最大IOPS 160K 128K 256K 1000K 云盘最大吞吐 2GB/s 1GB/s 4GB/s 4GB/s
表2主流云计算厂商的块存储概览
原创作品阿里云存储 阿纶
原文链接 本文为阿里云原创内容未经允许不得转载。
