1. SAN共享架构
1.1 SAN介绍
目前常用三种存储架构:直连式存储(DAS)、存储区域网络(SAN)、网络接入存储(NAS)。其中SAN(Storage Area Network)存储局域网络,它是一种通过光纤集线器、光纤路由器、光纤交换机等连接设备将磁盘阵列、磁带等存储设备与相关服务器连接起来的高速专用子网。SAN 架构主要包含:高速网络 (LAN)、Servers 服务器群、高度整合的储域管理软件、高容量及高速存储设备、SAN Devices(包括Hub、Switch、将Servers与Storage device整合为存储资源环境)。整体架构主要分为计算节点和IO节点,如下图所示:
IO节点作为一个整体通过IP网络为所有计算节点(应用服务器)提供数据存储服务,且IO节点之间一般采用节点间共享的FC-SAN存储,另外需配置SAN共享(文件系统)软件。
SAN(存储区域网络)的优点是具备大容量存储设备的数据共享、低时延高吞吐、灵活的存储设备配置、数据的可靠性和安全性高等。当然缺点也非常明显:
- 不是整体统一的解决方案,一般至少需要配置SAN共享软件、IO节点服务器、光纤交换机、FC磁盘阵列,搭建系统和后期管理维护成本较高。
- 扩展容量时比较复杂,需要重新做LUN规划,绑定映射等动作,为了保证访问速度,需要同时增加IO节点服务器和FC磁盘阵列,扩容成本较高。另外不支持在线不停业务扩容以及扩容后数据负载均匀迁移到各磁盘阵列,导致各磁盘阵列负载不均衡。
- FC磁盘阵列采用传统RAID数据保护机制,数据重建速度慢,同时支持的硬盘损坏数有限,而且RAID信息有丢失风险。
- FC磁盘阵列设备本身如果有故障,会导致整个系统瘫痪甚至数据丢失。
- FC与IP协议转换效率低,IO节点服务器之间无并行性,即一个IO请求只能有一个IO节点服务器来处理,不能有多个IO节点同时处理。
近十年随着各行各业市场的快速增长,带来数据规模的空前发展,对存储的容量弹性,易用性,安全性等提出了非常高的要求,同时用户对存储成本的控制更加趋于敏感。传统SAN的架构复杂,成本高,部署周期长,运维成本高等问题就变得更加的突出。近年云计算的兴起,尤其是RDMA、NVMe等硬件技术的发展,时延大幅降低,基于大规模网络构建并且支持多点挂载的共享云盘,成为下一代的低时延共享存储,来取代传统的SAN存储成为可能。
1.2 基于SAN的构建
结合SAN技术特性及其在众多行业的成功应用,在具有以下业务数据特性的企业环境中适宜采用SAN技术,大体分布如下:
典型行业 |
典型业务 |
特点 |
电信、金融和证券 |
计费 |
对数据安全性要求很高的企业 |
电视台、交通部门和测绘部门 |
音频/视频、石油测绘和地理信息系统等 |
对数据存储性能要求高的企业 |
各中大型企业 |
ERP系统、CRM系统和决策支持系统 |
在系统级方面具有很强的容量(动态)可扩展性和灵活性的企业 |
图书馆、博物馆、税务和石油 |
资料中心和历史资料库 |
具有超大型海量存储特性的企业 |
银行、证券和电信 |
银行的业务集中和移动通信的运营支撑系统(BOSS)集中 |
具有本质上物理集中、逻辑上又彼此独立的数据管理特点的企业 |
各行各业 |
企业各分支机构数据的集中处理 |
实现对分散数据高速集中备份的企业 |
商业网站和金融 |
电子商务 |
数据在线性要求高的企业 |
大型企业 |
数据中心 |
实现与主机无关的容灾的企业 |
从以上各行业来看,互联网及电子商务的数据字化与云原生化程度最高,因其行业较新可直接采用云原生架构进行。其它行业,因构建于传统的SAN存储,而云端尚没有与之相匹配的共享块存储,云化率比较低,因此存在着巨大的市场机会。
从上层软件上划分,主要为集群数据库、中间件以及其它集群应用软件等。如下图所示:
无论是上层的数据库,还是中间件及SaaS应用软件,都需要基于SAN的共享文件系统来实现集群多节点间的读写高可用。
1.3 SAN共享文件系统
SAN共享文件系统,顾名思义就是基于SAN构建的共享文件系统,它有几个显著的特点:
- 文件语义,是一个文件系统,一般实现POSIX文件协议。
- 共享读写,多个节点可以同时读写一份存于SAN的数据。
- I/O Fence,能够快速处理共享节点的故障,确保数据的读写正确性。
一般这种文件系统业界统称为集群文件系统,因为构建于其上的数据库或者应用都是一个集群系统。数据库的叫数据库集群,如Oracle RAC集群。应用的叫应用集群,如Web Logic等。
2. 集群文件系统
2.1 现状分析
集群文件系统,目前商业化较成功产品,如Veritas Cluster File System、阿里云的数据库文件存储DBFS企业版等。开源的产品,如OCFS2、GFS2等。当传统的SAN被共享云盘(如阿里云共享ESSD等)取代后,而其共享存储文件系统也逐渐被云原生的集群文件系统所取代,如阿里云的数据库文件存储DBFS文件系统。
2.2 竞品分析
对下对各个集群文件系统进行分析:
比较项 |
OCFS2/GFS2 |
ACFS |
Veritas FS |
DBFS |
文件语义 |
兼容POSIX |
部分兼容 |
兼容POSIX |
兼容POSIX |
容量弹性 |
一般小于1TB。 不支持在线扩容。 |
一般小于10TB。 不支持在线扩容。 |
一般小于10TB。 不支持在线扩容。 |
百TB级。 在线扩容。 |
易用性 |
部署复杂 |
部署复杂 |
部署复杂 |
挂载即用 |
生态 |
开源生态。 |
一般仅用于Oracle数据库。商用。 |
商用。 |
商用。 |
高可用 |
分钟级 |
分钟级 |
分钟级 |
20秒 |
性能 |
较差。 |
较好。 |
较好。 |
优秀。针对数据库场景优化。 |
成本 |
免费 |
license授权 |
license授权 |
收费 |
3. 数据库最佳实践
3.1 Oracle RAC on DBFS
在传统数据库领域,以Oracle RAC在DBFS上的部署为例。
DBFS相比于ASM,有以下优势:
比较项 |
Oracle ASM |
DBFS(数据库文件存储) |
容量 |
10TB级。扩容需要加盘,rebalance的过程中将影响业务I/O,通常需要额外安排系统维护的时间窗口。 |
支持百TB级。在线扩容,对用户透明。 |
文件类型 |
支持Voting Disk。不支持存放Oracle Home及Oracle Grid的二进制文件。 |
支持所有文件。支持存放Oracle Home及Oracle Grid的二进制文件,数据文件,控制文件,redo文件,OCR及Voting Disk等。 |
易用性 |
感知底层磁盘,需要配置Disk Group及冗余度。 |
持载即用。 |
性能 |
性能好,接近RAW I/O。 |
性能好,接近RAW I/O。针对数据库优化。 |
通用性 |
一般仅使用于Oracle数据库场景。 |
支持POSIX协议的通用数据库文件系统。不仅适用于数据库,也可适用于传统其它基于SAN构建的应用集群。 数据库场景:传统数据库如Oracle,SAP HANA等;开源数据库如MySQL,PostgreSQL,MongoDB等。 应用场景:中间件高可用集群及Oracle EBS套件。 |
具体部署细节,请查看“https://help.aliyun.com/document_detail/402340.html”。
3.2 MySQL on DBFS
基于共享存储实现双机高可用,基于一份数据之上实现无数据丢失的主备库分钟级切换,实现数据库计算节点的serverless。RPO=0,RTO分钟级。对于MySQL数据库,可关闭binary log进一步提升性能。这种部署形态,会还有以下几个收益:
- 高成本
数据库构建于一主一备两份数据的模式下,存储成本高。
- 数据不一致
异步或半同步模式下,主库crash后存在主备数据不一致风险。
- 性能差
日志强同步模式下,不但增加网络带宽资源使用,而且影响主库性能。
- 部署与切换复杂
主备同步配置与部署繁锁,切换复杂;另外,需保证其它额外组件的高可用。
具体部署细节,请查看“https://help.aliyun.com/document_detail/149749.html”。
除此之外,通过数据库文件存储DBFS实现的原子写,用户态IO、共享读写等特性,以低成本方式实现高性能。存储计算分离后,彻底免除了数据丢失风险,还会有以下几个收益:
- 高性能
对数据库关键IO的加速提升TPS。通过用户态技术,避免ext4等传统kernel态文件系统因核内外数据拷贝而影响数据库性能。
- 按需扩容
按实际业务需要申请存储空间,数据增长后在线动态扩容,从使用周期上降低存储成本。
- 原子写
避免数据库因ext4等文件系统不支持原子写而引入写缺页保护措施导致的IO争用和性能影响。例如,MySQL的DoubleWriteBuffer等。
了解更多关于数据库文件存储DBFS企业版的产品信息,欢迎访问https://www.aliyun.com/product/dbfs
如果您对数据库文件存储DBFS企业版有任何问题,欢迎钉钉扫描以下二维码加入数据库文件存储DBFS技术交流群。