企业级利器，阿里云 NVMe 盘和共享存储

互推小编 2023-07-24

7x24 高可用是怎样炼成的？

现实世界中单点故障是常态，确保故障下业务连续性是高可用系统的核心能力，那么在金融、保险、政务等关键应用中，如何保证业务 7*24 高可用？通常来讲，业务系统由计算、网络、存储组成，在云上，网络多路径和存储分布式确保了稳定高可用，但要实现业务全链路高可用，还要解决计算和业务侧单点故障。以常见的数据库为例，单点故障导致业务停止对于用户难以接受，那么，当断电、宕机、硬件故障等导致实例不可服务时，如何快速恢复业务？

不同场景的解决方案有所不同，MySQL 通常搭建主从/主备架构实现业务高可用，主库故障时切换到备库持续对外提供服务。但实例切换后，如何保证主从库数据的一致性？根据业务对数据丢失的容忍度，MySQL 通常采用同步或异步方式进行数据复制，由此引入额外的问题：部分场景下导致数据缺失、同步数据影响系统性能、业务扩容要新增整套设备并进行全量数据复制、主备切换时间较长影响业务连续性等。可以看到，为了搭建高可用系统，架构将变得复杂，且很难兼顾可用性、可靠性、扩展性、成本、性能等，那么是否有更加先进的方案，兼得鱼和熊掌？答案必须是：Yes！

图1：数据库的高可用架构

通过共享存储，不同数据库实例间可共享同一份数据，从而通过计算实例的快速切换获得高可用（图1），Oracle 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

解决脏数据写入的可选方案之一是：终止原实例的在途请求，并拒绝新请求继续下发，确保旧数据不再写入后切换实例。基于该思路，传统的解决方案是 STONITH（shoot the other node in the head），即通过远程重启该故障机器来防止旧数据落盘。不过该方案存在两个问题，首先，重启流程过长，业务切换较慢，通常会导致几十秒到分钟级的业务停止。更严重的是，由于云上 IO 路径较长，涉及组件较多，计算实例的组件故障（如硬件、网络故障等）都有几率导致 IO 在短时间内无法恢复，所以无法 100% 保证数据的正确性。

为了从根本性解决该问题， NVMe 规范了 Persistent Reservation（PR）能力，它定义了 NVMe 云盘的权限配置规则，可以灵活地修改云盘和挂载节点权限。具体到该场景，在主库发生故障后，从库首先发送 PR 命令禁止主库的写入权限，拒绝主库的所有在途请求，此时从库可以无风险的进行数据更新（图7）。IO Fencing 通常可以在毫秒级别协助应用完成故障切换，大幅缩短了故障恢复时间，业务的平滑迁移使上层应用基本无感知，相比于 STONITH 有了质的飞越。接下来我们进一步介绍 IO Fencing 的权限管理技术。

图7：IO Fencing 在故障切换下的应用

权限管理的瑞士军刀 -- Persistent Reservation

NVMe Persistent Reservation (PR) 协议定义了云盘和客户端权限，搭配多重挂载能力，可以高效、安全、平稳地进行业务切换。在 PR 协议中，挂载节点有 3 种身份，分别是 Holder（所有者）、Registerant（注册者）、Non-Registrant（访客），从名字可以看出，所有者拥有云盘全部权限，注册者拥有部分权限，访客只拥有读权限。同时，云盘拥有 6 种共享模式，可实现独占、一写多读、多写能力，通过配置共享模式和角色身份，可以灵活地管理各节点权限（表1），从而满足丰富的业务场景需求。NVMe PR 继承了 SCSI PR 的全部能力，所有基于 SCSI PR 的应用可以通过少量的改动即可运行在 NVMe 共享云盘之上。

表1：NVMe Persistent Reservation权限表

多重挂载配合 IO Fencing 能力，可以完美搭建高可用系统，除此之外，NVMe 共享盘还能提供一写多读能力，并广泛应用于读写分离的数据库、机器学习模型训练、流式处理等场景。另外，镜像共享、心跳探活、仲裁选主、锁机制等技术可以通过共享云盘轻松实现。

图8：NVMe 共享盘一写多读应用场景

NVMe 云盘技术揭秘

NVMe 云盘基于计算存储分离架构实现，依托于神龙硬件平台实现了高效的 NVMe 虚拟化和极速 IO 路径，以盘古2.0 存储为底座实现了高可靠、高可用、高性能，计算存储通过用户态网络协议和 RDMA 互连，NVMe 云盘是全栈高性能和高可用技术的结晶（图9）。

图9：NVMe 共享盘技术架构

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