标准Web系统的架构分层,看看没错( 三 )


 
稳定的扩展存储容量,并且不破坏目前已存储的数据信息,不影响整个存储系统的稳定性 。
文件共享,让多台服务器能够共享存储数据,并且都可以对文件系统进行读写操作 。
要解决这两个问题,我们首先要将问题扩展到上一小节的图例中,如下图所示:
很明显图中两个问题的答案是肯定的,也就是我们将要介绍的块存储系统要解决的问题 。
块存储系统
我们先来聊一下块存储 。之前我们提到的最简单的情况就是磁盘在本地物理机上,传输的物理块I/O命令,也是通过本地物理机主板上的南桥进行的 。但是为了扩展更大的磁盘空间,并且保证数据吞吐量,我们需要将磁盘介质和本地物理机分离,并且让物理块的I/O命令在网络上进行传输:

标准Web系统的架构分层,看看没错

文章插图
 
虽然磁盘介质和本地物理机发生了分离,但是直接传输块I/O命令的本质是没有改变的 。本地南桥传输I/O命令变成了光纤传输,只在本物理机内部传输I/O命令变成了网络传输,并且I/O命令通过某种通信协议进行了规范(例如FC、SCSI等) 。
文件系统的映射却是在本地进行,而非远程的文件系统映射 。上文中我们已经提到,由于块操作的顺序性(在一个扇区进行写入的时候,是不会进行这个扇区的读取操作的),且块操作属于底层物理操作无法向上层的文件逻辑层主动反馈变化 。所以多个物理主机是无法通过这个技术进行文件共享的 。
块存储系统要解决的是大物理存储空间、高数据吞吐量、强稳定性的共存问题 。作为上层使用这个文件系统的服务器来说,它非常清楚,除了它以外没有其他的服务器能够对专属于它的这些物理块进行读写操作了 。也就是说它认为这个庞大容量的文件存储空间只是它本地物理机上的存储空间 。
当然随着技术的发展,现在已经有一些技术可以只用TCP/IP协议对标准的SCSI命令进行传输,以便减小这个块存储系统的建设成本(例如iSCSI技术) 。但是这种折中方式也是以减弱整个系统的数据吞吐量为代价的 。不同的业务需求可以根据实际情况进行技术选型 。
文件存储系统
那么如果是将文件系统从本地物理机通过网络移植到远程呢?当然可以,典型的文件存储系统包括了FTP、NFS、DAS:
标准Web系统的架构分层,看看没错

文章插图
 
文件存储系统的关键在于,文件系统并不在本机 。而是通过网络访问存在于远程的文件系统,再由远程的文件系统操作块I/O命令完成数据操作 。
一般来说诸如本地文件系统NTFS/EXT/LVM/XF等是不允许直接网络访问的,所以一般文件存储系统会进行一层网络协议封装,这就是NFS协议/FTP协议/NAS协议(注意我们说的是协议),再由协议操作文件存储系统的服务器文件系统 。
文件存储系统要解决的问题首要的文件共享,网络文件协议可以保证多台客户端共享服务器上的文件结构 。从整个架构图上可以看到文件存储系统的数据读写速度、数据吞吐量是没办法和块存储系统相比的(因为这不是文件存储系统要解决的首要问题) 。
从上面的简介中我们可以清楚的知晓,当面对大量的数据读写压力的时候,文件存储系统肯定不是我们的首要选择,而当我们需要选择块存储系统时又面临成本和运维的双重压力(SAN系统的搭建是比较复杂的,并且设备费用昂贵) 。并且在实际生产环境中我们经常遇到数据读取压力大,且需要共享文件信息的场景 。那么这个问题怎么解决呢?
对象存储系统
兼具块存储系统的高吞吐量、高稳定性和文件存储的网络共享性、廉价性的对象存储就是为了满足这样的需求出现的 。典型的对象存储系统包括:MFS、Swift、Ceph、Ozone等 。下面我们简单介绍一下对象存储系统的特点,在后面的文章中,我们将选择一款对象存储系统进行详细说明 。
对象存储系统一定是分布式文件系统 。但分布式文件系统不一定是对象存储系统
标准Web系统的架构分层,看看没错

文章插图
 
我们知道文件信息是由若干属性进行描述的,包括文件名、存储位置、文件大小、当前状态、副本数量等信息 。我们将这些属性抽离出来,专门使用服务器进行存储(元数据服务器) 。这样一来文件操作的客户端要访问某一个文件,首先会询问元数据节点这个文件的基本信息 。
由于是分布式系统,那么数据一致性、资源争夺、节点异常问题都需要进行统一的协调 。所以对象存储系统中一般会有监控/协调节点 。不同的对象存储系统,支持的元数据节点和监控/协调节点的数量是不一致的 。但总的趋势都是“去中心化” 。


推荐阅读