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

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 存储价格昂贵、运维复杂、可扩展性差࿰