云计算的三种服务模式：IaaS，PaaS和SaaS
云的分层
任何一个在互联网上提供其服务的公司都可以叫做云计算公司。其实云计算分几层的，分别是Infrastructure（基础设施）-as-a-Service，Platform（平台）-as-a-Service，Software（软件）-as-a-Service。基础设施在最下端，平台在中间，软件在顶端。别的一些“软”的层可以在这些层上面添加。
IaaS: Infrastructure-as-a-Service（基础设施即服务）
第一层叫做IaaS，有时候也叫做Hardware-as-a-Service，也就是提供整机的服务器服务，比如Amazon的Amazon EC2和阿里云的虚拟机服务器等等，但是mysql和tomcat这些服务需要自己安装。
Iaas 属于基础设施，比如网络光纤，服务器，存储设备等。
PaaS: Platform-as-a-Service（平台即服务）
平台即服务, 有时候也叫中间件，是面向软件开发者的服务, 云计算平台提供硬件, OS, 编程语言, 开发库, 部署工具, 帮助软件开发者更快的开发软件服务. 比如Google的GAE.
Paas 是在Issa上的一层集成的操作系统，服务器程序，数据库等。
SaaS: Software-as-a-Service（软件即服务）
软件即服务, 是面向软件消费者的, 用户无需安装, 通过标准的Internet工具(比如浏览器), 即可使用云计算平台提供的软件, 比如Salesforce的CRM管理系统, Google的Gmail.
SaaS 是将软件当成服务来提供的方式，不再作为产品来销售。
例子
例子一
如果你是一个网站站长，想要建立一个网站。 不采用云服务，你所需要的投入大概是：买服务器，安装服务器软件，编写网站程序。 采用流行的云计算，如果你采用IaaS服务，那么意味着你就不用自己买服务器了，随便在哪家购买虚拟机，但是还是需要自己装服务器软件 而如果你采用PaaS的服务，那么意味着你既不需要买服务器，也不需要自己装服务器软件，只需要自己开发网站程序，然后部署上去即可。 如果你再进一步，购买某些在线论坛或者在线网店的服务,这意味着你也不用自己开发网站程序，只需要使用它们开发好的程序，而且他们会负责程序的升级、维护、增加服务器等，而你只需要专运营即可，此即为SaaS。
例子二
Iaas是卖笔记本电脑的，Paas是卖操作系统的（比如windows），Saas是卖应用程序的（比如Office等办公软件，普通小白用户能直接用的东西）
Iaas和Paas之间的比较
PaaS的主要作用是将一个开发和运行平台作为服务提供给用户，而IaaS的主要作用是提供虚拟机或者其他资源作为服务提供给用户。接下来，将在七个方面对PaaS和IaaS进行比较：
1) 开发环境：PaaS基本都会给开发者提供一整套包括IDE在内的开发和测试环境，而IaaS方面用户主要还是沿用之前比较熟悉那套开发环境，但是因为之前那套开发环境在和云的整合方面比较欠缺，所以使用起来不是很方便。 2) 支持的应用：因为IaaS主要是提供虚拟机，而且普通的虚拟机能支持多种操作系统，所以IaaS支持的应用的范围是非常广泛的。但如果要让一个应用能跑在某个PaaS平台不是一件轻松的事，因为不仅需要确保这个应用是基于这个平台所支持的语言，而且也要确保这个应用只能调用这个平台所支持的API，如果这个应用调用了平台所不支持的API，那么就需要对这个应用进行修改。 3) 开放标准：虽然很多IaaS平台都存在一定的私有功能，但是由于OVF等协议的存在，使得IaaS在跨平台和避免被供应商锁定这两面是稳步前进的。而PaaS平台的情况则不容乐观，因为不论是Google的App Engine，还是Salesforce的Force.com都存在一定的私有API。 4) 可伸缩性：PaaS平台会自动调整资源来帮助运行于其上的应用更好地应对突发流量。而IaaS平台则需要开发人员手动对资源进行调整才能应对。 5) 整合率和经济性： PaaS平台整合率是非常高，比如PaaS的代表Google App Engine能在一台服务器上承载成千上万的应用，而普通的IaaS平台的整合率最多也不会超过100，而且普遍在10左右，使得IaaS的经济性不如PaaS。 6) 计费和监管：因为PaaS平台在计费和监管这两方面不仅达到了IaaS平台所能企及的操作系统层面，比如，CPU和内存的使用量等，而且还能做到应用层面，比如，应用的反应时间（Response Time）或者应用所消耗的事务多少等，这将提高计费和管理的精确性。 7) 学习难度：因为在IaaS上面开发和管理应用和现有的方式比较接近，而PaaS上面开发则有可能需要学一门新的语言或者新的框架，所以IaaS学习难度更低。
存储相关的协议和名称：S3，RPC,TCP/IP，hdfs，ATA，PATA，SATA，SCSI，FC，iSCSI，SAS，PCI，PCIe，IDE，NFS，CIFS，SMB，XFS，ext4
S3协议(Simple Storage Service简单存储服务协议)
Amazon S3 是一种面向 Internet 的存储服务。它是一种简单存储服务，以很低的成本为软件开发人员提供高度可扩展的、可靠的、低延迟的存储基础设施。
s3协议是专门针对Amazon S3而产生的，在URL中，指定一个Amazon S3桶的位置以及用来读写该桶中文件的前缀。用户可以定义只读外部表使用S3桶中现有的数据文件作为表数据，或者创建可写外部表将来自于INSERT操作的数据存储到S3桶中的文件
通俗的话，S3协议可以通过特定的url格式基于HTTP协议的RESTful Web API，使用HTTP请求中的PUT和GET等操作进行存储系统中文件的上传即写入和下载即读取，通过DELETE操作删除文件和其他扩展操作
Ceph 支持 REST 风格的 API ，它与亚马逊 S3 API 的基本数据访问模型兼容。
RPC协议
RPC(Remote Procedure Call Protocol)–远程过程调用协议，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。RPC协议假定某些传输协议的存在，如TCP或UDP，为通信程序之间携带信息数据。在OSI网络通信模型中，RPC跨越了传输层和应用层。RPC使得开发包括网络分布式多程序在内的应用程序更加容易。
RPC采用客户机/服务器模式。请求程序就是一个客户机，而服务提供程序就是一个服务器。首先，客户机调用进程发送一个有进程参数的调用信息到服务进程，然后等待应答信息。在服务器端，进程保持睡眠状态直到调用信息的到达为止。当一个调用信息到达，服务器获得进程参数，计算结果，发送答复信息，然后等待下一个调用信息，最后，客户端调用进程接收答复信息，获得进程结果，然后调用执行继续进行。
TCP/IP 协议
TCP/IP 协议栈是一系列网络协议的总和，是构成网络通信的核心骨架，它定义了电子设备如何连入因特网，以及数据如何在它们之间进行传输。TCP/IP 协议采用4层结构，分别是应用层、传输层、网络层和链路层，每一层都呼叫它的下一层所提供的协议来完成自己的需求。由于我们大部分时间都工作在应用层，下层的事情不用我们操心；其次网络协议体系本身就很复杂庞大，入门门槛高，因此很难搞清楚TCP/IP的工作原理，通俗一点讲就是，一个主机的数据要经过哪些过程才能发送到对方的主机上。
TCP/IP协议栈分为四层，每一层都由特定的协议与对方进行通信，而协议之间的通信最终都要转化为 0 和 1 的电信号，通过物理介质进行传输才能到达对方的电脑，因此物理介质是网络通信的基石。
hdfs协议
Hadoop的通信是建立在RPC的基础上，所有HDFS 通信协议都构建于TCP/IP 协议之上，是自己实现的一套访问逻辑，所以在访问hdfs文件时，需要带上hdfs命令，如果要将hdfs mount为linux本地文件系统可以参考使用Webdav组件或者FUSE。 Webdav协议介绍: WebDAV（Web-based Distributed Authoring and Versioning）是基于 HTTP 1.1 的一个通信协议。它为 HTTP 1.1 添加了一些扩展（就是在 GET、POST、HEAD 等几个 HTTP 标准方法以外添加了一些新的方法），使得应用程序可以直接将文件写到 Web Server 上，并且在写文件时候可以对文件加锁，写完后对文件解锁，还可以支持对文件所做的版本控制。 本项目是一个hadoop namenode server的webdav协议访问代理,实现 client => hdfs-webdav proxy => hadoop namenode server的中间层. 项目修改自tomcat的WebdavServlet,实现了WebDAV level 2协议.
用户空间中的文件系统，即FUSE，是一种允许开发人员在用户空间中实现可挂载文件系统的系统。也就是说，不需要对内核模块进行开发。这不仅更简单，因为开发人员可以在熟悉的环境中使用标准库，而且它也更安全，因为开发人员的错误不一定会导致内核恐慌。 Apache Hadoop和CDH都支持FUSE HDFS，正如您可能已经猜到的那样，它允许您像任何其他设备一样安装Hadoop分布式文件系统。这使得遗留应用程序和系统能够继续在由HDFS支持的Linux服务器上读写文件到一个常规目录。虽然这很有用，但并不是万能药。HDFS的所有属性仍然存在:没有对文件进行修改，相对较高的延迟，糟糕的随机访问性能，对大型流媒体操作的优化，以及巨大的规模。需要明确的是，FUSE并不使HDFS成为一个posix兼容的文件系统。它只是一个兼容层，可以将HDFS暴露给只执行基本文件操作的应用程序。
挂载HDFS CDH5包含一个HDFS的接口FUSE（用户空间文件系统），FUSE能让你写一个正常的用户空间应用程序作为一个传统文件系统接口。hadoop-hdfs-fuse包使您能够使用HDFS集群就好像它是一个传统的文件系统在Linux上。假设你有一个工作HDFS集群和知道你的NameNode暴露的主机名和端口。(翻译) 简单总结：意思就是你可以把hdfs作为一个本次挂载的磁盘，进行交换。
开机自动挂载hdfs文件系统，在/etc/fstab中加入挂载命令即可
ATA
AT attachment 是IDE(Integrated Drive Electronics)硬盘的接口标准。包括PIO(Programming I/O)和DMA(Direct Memory Access) 两种传输模式。ATA本身可以支持串行或并行。
PATA
Paralle ATA。并行协议，基于ATA。
SATA
Serial ATA。 串行协议，基于ATA。
SCSI
SCSI是小型计算机系统接口（Small Computer System Interface）的简称，于1979首次提出，是为小型机研制的一种接口技术，现在已完全普及到了小型机，高低端服务器以及普通PC上。跟ATA/IDE不兼容，相对于ATA硬盘的接口支持数量更多
SCSI可以划分为SCSI-1、SCSI-2、SCSI-3，最新的为SCSI-3，也是目前应用最广泛的SCSI版本。 1、SCSI-1：1979年提出，支持同步和异步SCSI外围设备；支持7台8位的外围设备，最大数据传输速度为5MB/s。 2、SCSI-2：1992年提出，也称为Fast SCSI，数据传输率提高到20MB/s。 3、SCSI-3：1995年提出，Ultra SCSI（Fast-20）。Ultra 2 SCSI（Fast-40）出现于1997年，最高传输速率可达80MB/s。1998年9月，Ultra 3 SCSI（Utra 160 SCSI）正式发布，最高数据传输率为160MB/s。Ultra 320 SCSI的最高数据传输率已经达到了320MB/s。
FC（光纤通道）
FC光纤通道：Fiber Channel。是基于Fabric Channel环路协议基础上的串行技术，通过给后端磁盘提供带宽2.0Gbit/s或者4.0Gbit/s的FC环路来进行磁盘的连接。本来FC是给网络系统开发的，FC线缆的连接距离远，比较容易扩展。因为存储系统对速度要求高，所以也用在多硬盘系统的通信中。用于计算机设备之间数据传输，传输率达到2G（将来会达到4G）。光纤通道用于服务器共享存储设备的连接，存储控制器和驱动器之间的内部连接。
协议基本架构：
FC-4 Upper Layer Protocol:SCSI,HIPPI,SBCCS,802.2,ATM,VI,IP
FC-3 common service
FC-2 Framing Protocol /Flow Control
FC-1 Encode/Decode
FC-0 Media:Optical or copper,100MB/sec to 1.062GB/sec
协议层说明：
FC-0：物理层，定制了不同介质，传输距离，信号机制标准，也定义了光纤和铜线接口
以及电缆指标
FC-1：定义编码和解码的标准
FC-2：定义了帧、流控制、和服务质量等
FC-3：定义了常用服务，如数据加密和压缩
FC-4：协议映射层，定义了光纤通道和上层应用之间的接口，上层应用比如：串行SCSI 协 议，HBA 的驱动提供了FC-4 的接口函数，FC-4 支持多协议，如：FCP-SCSI, FC-IP,FC-VI
协议简介： FCP-SCSI：是将SCSI并行接口转化为串行接口方式的协议，应用于存储系统和服务器之间的数据传输。新的ANSI T10 标准，支持SAN 上存储系统之间通过数据迁移应用来直接移动数据。 FCP-SCSI 提供200MB/s（全双工独占带宽）的传输速率，每连接最远达10 公里，最大16000000 个节点。FCP-SCSI 使用帧传输取代块传输。帧传输以大数据流传输方式传输短的小的事务数据。
iSCSI
iSCSI（互联网小型计算机系统接口）是一种在TCP/IP上进行数据块传输的标准。它是由Cisco和IBM两家发起的，并且得到了各大存储厂商的大力支持。iSCSI可以实现在IP网络上运行SCSI协议，使其能够在诸如高速千兆以太网上进行快速的数据存取备份操作。
iSCSI标准在2003年2月11日由IETF（互联网工程任务组）认证通过。iSCSI继承了两大最传统技术：SCSI和TCP/IP协议。这为iSCSI的发展奠定了坚实的基础。基于iSCSI的存储系统只需要不多的投资便可实现SAN存储功能，甚至直接利用现有的TCP/IP网络。相对于以往的网络存储技术，它解决了开放性、容量、传输速度、兼容性、安全性等问题，其优越的性能使其备受始关注与青睐。
工作流程： iSCSI系统由SCSI适配器发送一个SCSI命令。 命令封装到TCP/IP包中并送入到以太网络。 接收方从TCP/IP包中抽取SCSI命令并执行相关操作。 把返回的SCSI命令和数据封装到TCP/IP包中，将它们发回到发送方。 系统提取出数据或命令，并把它们传回SCSI子系统。
安全性描述：
iSCSI协议本身提供了QoS及安全特性。
可以限制initiator仅向target列表中的目标发登录请求，再由target确认并返回响应，之后才允许通信。
通过IPSec将数据包加密之后传输，包括数据完整性、确定性及机密性检测等。
iSCSI的优势：
（1）广泛分布的以太网为iSCSI的部署提供了基础。
（2）千兆/万兆以太网的普及为iSCSI提供了更大的运行带宽。
（3）以太网知识的普及为基于iSCSI技术的存储技术提供了大量的管理人才。
（4）由于基于TCP/IP网络，完全解决数据远程复制（Data Replication）及灾难恢复（Disaster Recover）等传输距离上的难题。
（5）得益于以太网设备的价格优势和TCP/IP网络的开放性和便利的管理性，设备扩充和应用调整的成本付出小。
iSCSI和FC的比较
从传输层看，光纤通道的传输采用其FC协议，iSCSI采用TCP/IP协议。
FC协议与现有的以太网是完全异构的，两者不能相互接驳。因此光纤通道是具有封闭性的，而且不仅与现有的企业内部网络（以太网）接入，也与其他不同厂商的光纤通道网络接入（由于厂家对FC标准的理解的异样，FC设备的兼容性是一个巨大的难题）。因此，对于以后存储网络的扩展由于兼容性的问题而成为了难题。而且，FC协议由于其协议特性，网络建完后，加入新的存储子网时，必须要重新配置整个网络，这也是FC网络扩展的障碍。
iSCSI基于的TCP/IP协议，它本身就运行于以太网之上，因此可以和现有的企业内部以太网无缝结合。TCP/IP网络设备之间的兼容性已经无需讨论，迅猛发展的internent网上运行着全球无数家网络设备厂商提供的网络设备，这是一个最好的佐证。 从网络管理的角度看，运行FC协议的光网络，其技术难度相当之大。其管理采用了专有的软件，因此需要专门的管理人员，且其培训费用高昂。TCP/IP网络的知识通过这些年的普及，已有大量的网络管理人才，并且，由于支持TCP/IP的设备对协议的支持一致性好，即使是不同厂家的设备，其网络管理方法也是基本一致的。
FC运行于光网络之上，其速度是非常快的，现在已经达到了2G的带宽，这也是它的主要优势所在。下一代的FC标准正在制定当中，其速度可以达到4G，今天的千兆以太网已经在普及当中，这也是基于TCP/IP的iSCSI协议进入实用的保证。得益于优秀的设计，以太网从诞生到现在，遍及了所有有网络的地方，到现在依然表现出非凡的生命力，在全球无数网络厂商的共同努力下，以太网的速度稳步提升，千兆网络已经实际应用，万兆网络呼之欲出，以太网的主要部件交换机路由器均已有万兆级别的产品。随着产品的不断丰富，以及设备厂商间的剧烈竞争，其建设成本在不断下降，万兆网络的普及已日益临近。当iSCSI以10Gb的高速传输数据时，基于iSCSI协议的存储技术将无可争议的成为网络存储的王者。
SAS
Serial Attached SCSI。串行协议，基于SCSI，又可以向下兼容SATA。
PCI
Peripheral Component Interconnect。是在CPU和原来系统总线内部插入的一级总线。主要用于电脑内部主板的扩展插槽，连接显卡，声卡，网卡和Modem等设备。PCI总线只有133MB/s 的带宽。注意它不是硬盘接口。
PCIe
PCI Express。向下兼容PCI，串行协议。PCIe 2.0为例，每秒5GT（Gigatransfer）原始数据传输率，编码方式为8b/10b（每10个位元只有8个有效数据），即有效频宽为4Gb/s = 500MByte/s。PCIe可以用于SSD的接口，但不用于机械硬盘的接口，因为机械硬盘的读写速度达不到这么高，没有必要用PCIe。
IDE
（并行传输ATA） 控制电路，盘片，磁头放在一个容器中
NFS（Network File System）
NFS是NetworkFileSystem的简写,即网络文件系统,网络文件系统是FreeBSD支持的文件系统中的一种，由 Linux 、 UNIX 及其他类似操作系统使用的互联网标准协议. NFS允许一个系统在网络上与它人共享目录和文件。通过使用NFS，用户和程序可以像访问本地文件一样访问远端系统上的文件。 它是一种活动扩展之下的开放标准 , 可支持本地 Linux 权限和文件系统功能
CIFS（Common Internet File System）
CIFS 是针对 Microsoft Windows 操作系统的本地网络文件系统。 Linux 系统可以挂载和访问 CIFS 文件共享 , 如同常见的网络文件系统一样。然而 , 由于 CIFS 是基于 NTFS 文件系统权限模型及其自身的身份验证系统来构建的 , 因而 CIFS 协议中的所有内容并不能很好地映射到 Linux 中 CIFS的前身是SMB协议
SMB
SMB（ServerMessage Block）通信协议是微软（Microsoft）和英特尔(Intel)在1987年制定的协议，主要是作为Microsoft网络的通讯协议。SMB 是在会话层（session layer）和表示层（presentation layer）以及小部分应用层（application layer）的协议。SMB使用了NetBIOS的应用程序接口 （Application Program Interface，简称API），一般端口使用为139，445。另外，它是一个开放性的协议，允许了协议扩展——使得它变得更大而且复杂；大约有65个最上层的作业，而每个作业都超过120个函数，甚至Windows NT也没有全部支持到，最近微软又把 SMB 改名为 CIFS（CommonInternet File System），并且加入了许多新的特色。
XFS
XFS，一种高性能的日志文件系统，最早于1993年，由Silicon Graphics为他们的IRIX操作系统而开发，是IRIX 5.3版的默认文件系统。2000年5月，Silicon Graphics以GNU通用公共许可证发布这套系统的源代码，之后被移植到Linux内核上。XFS特别擅长处理大文件，同时提供平滑的数据传输。目前CentOS 7也将XFS+LVM作为默认的文件系统。
ext4
第四代扩展文件系统（英语：Fourth extended filesystem，缩写为ext4）是Linux系统下的日志文件系统，是ext3文件系统的后继版本。
POSIX
POSIX表示可移植操作系统接口（Portable Operating System Interface of UNIX，缩写为 POSIX ），POSIX标准定义了操作系统应该为应用程序提供的接口标准，是IEEE为要在各种UNIX操作系统上运行的软件而定义的一系列API标准的总称，其正式称呼为IEEE 1003，而国际标准名称为ISO/IEC 9945。
linux操作系统中，实现了两类对文件IO的管理，一类是遵循POSIX标准，linux操作系统自身提供的IO系统调用，如open、close、read等函数；另一类是由ANSI标准提供的标准IO库函数，这些函数是对直接IO系统调用的封装，其在访问文件时根据需要设置了不同类型的缓冲区，从而减少了直接IO系统调用的次数，提高访问效率。
完成同一功能，不同内核提供的系统调用（也就是一个函数）是不同的，例如创建进程，linux下是fork函数，windows下是creatprocess函数。好，我现在在linux下写一个程序，用到fork函数，那么这个程序该怎么往windows上移植？我需要把源代码里的fork通通改成creatprocess，然后重新编译…
posix标准的出现就是为了解决这个问题。linux和windows都要实现基本的posix标准，linux把fork函数封装成posix_fork（随便说的），windows把creatprocess函数也封装成posix_fork，都声明在unistd.h里。这样，程序员编写普通应用时候，只用包含unistd.h，调用posix_fork函数，程序就在源代码级别可移植了。
符合posix标准的程序意味着 可以同时在 支持posix的系统中无缝移植和运行，包括linux和unix以及windows系统等等。
历史背景 20世纪60年代是大型、复杂操作系统盛行的年代，比如IBM的OS/360和Honeywell的Multics系统。OS/360是历史上最成功的软件项目之一，而 Multics虽然持续存在了多年，却从来没有被广泛应用过。贝尔实验室曾经是Multics项目的最初参与者，但是因为考虑到该项目的复杂性和缺乏进展而于1969年退出。鉴于Mutics项目不愉快的经历，一群贝尔实验室的研究人员Ken Thompson、 Dennis Ritchie、 Doug Mcllroy和 Joe Ossanna，从1969年开始在DEC PDP-7计算机上完全用机器语言编写了一个简单得多的操作系统。这个新系统中的很多思想，比如层次文件系统、作为用户级进程的 shell概念，都是来自于 Multics，只不过在一个更小、更简单的程序包里实现。1970年，Brian Kernighan给新系统命名为“Unix”，这也是一个双关语，暗指“Multics”的复杂性。1973年用C重新编写其内核，1974年，Unix开始正式对外发布。
贝尔实验室以慷慨的条件向学校提供源代码，所以Unix在大专院校里获得了很多支持并得以持续发展。最有影响的工作发生在20世纪70年代晚期到80年代早期，在美国加州大学伯克利分校，研究人员在一系列发布版本中增加了虚拟内存和Internet协议，称为Unix4.xBSD(Berkeley Software Distribution)。与此同时，贝尔实验室也在发布自己的版本，称为System V Unix。其他厂商的版本，比如Sun Microsystems的Solaris系统,则是从这些原始的BSD和System V版本中衍生而来。
20世纪80年代中期，Unix厂商试图通过加入新的、往往不兼容的特性来使它们的程序与众不同，麻烦也就随之而来了。为了阻止这种趋势，IEEE(电气和电子工程师协会)开始努力标准化Unix的开发，后来由 Richard Stallman命名为“Posix”。结果就得到了一系列的标准，称作Posix标准。这套标准涵盖了很多方面，比如Unix系统调用的C语言接口、shell程序和工具、线程及网络编程。最近，一个被称为“标准Unix规范”的独立标准化工作已经与Posix一起创建了统一的Unix系统标准。这些标准化工作的结果是Unix版本之间的差异已经基本消失。
如果存储系统做了POSIX兼容则可以支持posix协议的系统上运行，包括linux，unix，windows等，也就是实现了跨平台，类似java的jvm。
云存储的三种类型：对象存储 块存储 文件存储
分布式存储的应用场景相对于其存储接口，现在流行分为三种:
对象存储
也就是通常意义的键值存储，对象存储的接口是REST风格的，通常是基于HTTP协议的RESTful Web API，通过HTTP请求中的PUT和GET等操作进行文件的上传即写入和下载即读取，通过DELETE操作删除文件和其他扩展操作，如七牛、又拍、Swift、S3,还有Ceph的底层RADOS（Reliable Autonomous Distributed Object Store），适合在云环境中进行大规模的非结构化数据存储使用。
总体上来讲，对象存储同兼具SAN高速直接访问磁盘特点及NAS的分布式共享特点。
核心是将数据通路（数据读或写）和控制通路（元数据）分离，并且基于对象存储设备（Object-based Storage Device，OSD）构建存储系统，每个对象存储设备具有一定的智能，能够自动管理其上的数据分布。 对象存储结构组成部分（对象、对象存储设备、元数据服务器、对象存储系统的客户端）
块存储
我们简单的理解就是一块一块的硬盘，直接挂载在主机上，在主机上我们能够看到的就是一块块的硬盘以及硬盘分区。从存储架构的角度而言，块存储又分为DAS存储（Direct-Attached Storage，直连式存储）和SAN存储（Storage Area Network，存储区域网络）。
主要指能够模拟或表现为计算机裸盘，能够被计算主机当做硬盘使用的存储形式。这种接口通常以QEMU Driver或者Kernel Module的方式存在，这种接口需要实现Linux的Block Device的接口或者QEMU提供的Block Driver接口，如Sheepdog，AWS的EBS，青云的云硬盘和阿里云的盘古系统，还有Ceph的RBD（RBD是Ceph面向块存储的接口）
块存储，简单来说就是提供了块设备存储的接口。通过向内核注册块设备信息,在Linux中通过lsblk可以得到当前主机上块设备信息列表。
首先一个硬盘是一个块设备，内核检测到硬盘然后在/dev/下会看到/dev/sda/，因为我们需要利用一个硬盘来得到不同的分区来做不同的事，通过fdisk工具得到/dev/sda1, /dev/sda2等，这种方式通过直接写入分区表来规定和切分硬盘,是最死板的分区方式。
LVM是一种逻辑卷管理器，通过LVM来对硬盘创建逻辑卷组和得到逻辑卷来完成目的比fdisk方式更加弹性。Device-mapper是一种支持逻辑卷管理的通用设备映射机制，为存储资源管理的块设备驱动提供了一个高度模块化的内核架构。 LVM是基于Device-mapper的用户程序实现。
在接触了单机下的逻辑卷管理后，你需要了解SAN，目前主流的企业级存储方式。
大部分SAN使用SCSI协议在服务器和存储设备之间传输和沟通，通过在SCSI之上建立不同镜像层，可以实现存储网络的连接。常见的有iSCSI，FCP，Fibre Channel over Ethernet等。
SAN通常需要在专用存储设备中建立，而iSCSI是基于TCP/IP的SCSI映射，通过iSCSI协议和Linux iSCSI项目我们可以在常见的PC机上建立SAN存储。
在面对极具弹性的存储需求和性能要求下，单机或者独立的SAN越来越不能满足企业的需要。如同数据库系统一样，块存储在scale up的瓶颈下也面临着scale out的需要。所以需要分布式块存储，我们可以用以下几个特点来描述分布式块存储系统的概念:
分布式块存储可以为任何物理机或者虚拟机提供持久化的块存储设备 分布式块存储系统管理块设备的创建、删除和attach/deattach。 分布式块存储支持强大的快照功能，快照可以用来恢复或者创建新的块设备 分布式存储系统能够提供不同IO性能要求的块设备
通常来讲，所有磁盘阵列都是基于Block块的模式。
介绍这两种传统的存储类型，以下列出的两种存储方式都是块存储类型：
1） DAS（Direct Attach STorage）：是直接连接于主机服务器的一种储存方式，每一台主机服务器有独立的储存设备，每台主机服务器的储存设备无法互通，需要跨主机存取资料时，必须经过相对复杂的设定，若主机服务器分属不同的操作系统，要存取彼此的资料，更是复杂，有些系统甚至不能存取。通常用在单一网络环境下且数据交换量不大，性能要求不高的环境下，可以说是一种应用较为早的技术实现。
2）SAN（Storage Area Network）：是一种用高速（光纤）网络联接专业主机服务器的一种储存方式，此系统会位于主机群的后端，它使用高速I/O 联结方式， 如 SCSI, ESCON 及 Fibre- Channels。一般而言，SAN应用在对网络速度要求高、对数据的可靠性和安全性要求高、对数据共享的性能要求高的应用环境中，特点是代价高，性能好。例如电信、银行的大数据量关键应用。它采用SCSI 块I/O的命令集，通过在磁盘或FC（Fiber Channel）级的数据访问提供高性能的随机I/O和数据吞吐率，它具有高带宽、低延迟的优势，在高性能计算中占有一席之地，但是由于SAN系统的价格较高，且可扩展性较差，已不能满足成千上万个CPU规模的系统。
介绍分布式块存储类型 Ceph
文件存储
我们指的是在文件系统上的存储，也就是主机操作系统中的文件系统。我们知道，文件系统中有分区，有文件夹，子文件夹，形成一个自上而下的文件结构；文件系统下的文件，用户可以通过操作系统中的应用程序进行打开、修改等操作，如打开word、编辑word。从架构上来说，文件存储提供一种NAS（Network Attached Storage，网络附属存储）架构，使得主机的文件系统不仅限于本地的文件系统，还可以连接基于局域网的共享文件系统。
通常意义是支持POSIX接口，它跟传统的文件系统如Ext4是一个类型的。对于大多数文件系统来说，尤其是POSIX兼容的文件系统，提供open、close、read、write和lseek等接口。但区别在于分布式存储提供了并行化的能力，如Ceph的CephFS(CephFS是Ceph面向文件存储的接口)，但是有时候又会把GFS，HDFS这种非POSIX接口的类文件存储接口归入此类。
通常，NAS产品都是文件级存储。 NAS（Network Attached Storage）：是一套网络储存设备，通常是直接连在网络上并提供资料存取服务，一套 NAS 储存设备就如同一个提供数据文件服务的系统，特点是性价比高。例如教育、政府、企业等数据存储应用。
它采用NFS或CIFS命令集访问数据，以文件为传输协议，通过TCP/IP实现网络化存储，可扩展性好、价格便宜、用户易管理，如目前在集群计算中应用较多的NFS文件系统，但由于NAS的协议开销高、带宽低、延迟大，不利于在高性能集群中应用。
针对Linux集群对存储系统高性能和数据共享的需求，国际上已开始研究全新的存储架构和新型文件系统，希望能有效结合SAN和NAS系统的优点，支持直接访问磁盘以提高性能，通过共享的文件和元数据以简化管理，目前对象存储系统已成为Linux集群系统高性能存储系统的研究热点，如Panasas公司的Object Base Storage Cluster System系统和Cluster File Systems公司的Lustre等。
Hadoop DFS 不是对象存储，它是一个改造的文件存储系统。
DAS、NAS、SAN三种技术进行比较和分析：
块存储，文件存储，对象存储的层次关系
对象存储中，OSD（Object-based Storage Device)是对象存储设备，MDS(Metadata Server)是元数据服务器。
我们从底层往上看，最底层就是硬盘，多个硬盘可以做成RAID组，无论是单个硬盘还是RAID组，都可以做成PV，多个PV物理卷捏在一起构成VG卷组，这就做成一块大蛋糕了。接下来，可以从蛋糕上切下很多块LV逻辑卷，这就到了存储用户最熟悉的卷这层。到这一层为止，数据一直都是以Block块的形式存在的，这时候提供出来的服务就是块存储服务。你可以通过FC协议或者iSCSI协议对卷访问，映射到主机端本地，成为一个裸设备。在主机端可以直接在上面安装数据库，也可以格式化成文件系统后交给应用程序使用，这时候就是一个标准的SAN存储设备的访问模式，网络间传送的是块。 如果不急着访问，也可以在本地做文件系统，之后以NFS/CIFS协议挂载，映射到本地目录，直接以文件形式访问，这就成了NAS访问的模式，在网络间传送的是文件。 如果不走NAS，在本地文件系统上面部署OSD服务端，把整个设备做成一个OSD，这样的节点多来几个，再加上必要的MDS节点，互联网另一端的应用程序再通过HTTP协议直接进行访问，这就变成了对象存储的访问模式。当然对象存储通常不需要专业的存储设备，前面那些LV/VG/PV层也可以统统不要，直接在硬盘上做本地文件系统，之后再做成OSD，这种才是对象存储的标准模式，对象存储的硬件设备通常就用大盘位的服务器。
从系统层级上来说，这三种存储是按照块->文件->对象逐级向上的。文件一定是基于块上面去做，不管是远端还是本地。而对象存储的底层或者说后端存储通常是基于一个本地文件系统（XFS/Ext4..）。这样做是比较合理顺畅的架构。但是大家想法很多，还有各种特异的产品出现，我们逐个来看看： 对象存储除了基于文件，可以直接基于块，但是做这个实现的很少，毕竟你还是得把文件系统的活给干了，自己实现一套元数据管理，也挺麻烦的，目前我只看到Nutanix宣称支持。另外对象存储还能基于对象存储，这就有点尴尬了，就是转一下，何必呢？但是这都不算最奇怪的，最奇怪的是把对象存储放在最底层，那就是这两年大红的Ceph。
Ceph是个开源的分布式存储，相信类似的架构图大家都见过，我把底层细节也画出来，方便分析。
底层是RADOS，这是个标准的对象存储。以RADOS为基础，Ceph 能够提供文件，块和对象三种存储服务。其中通过RBD提供出来的块存储是比较有价值的地方，毕竟因为市面上开源的分布式块存储少见嘛（以前倒是有个sheepdog，但是现在不当红了）。当然它也通过CephFS模块和相应的私有Client提供了文件服务，这也是很多人认为Ceph是个文件系统的原因。另外它自己原生的对象存储可以通过RadosGW存储网关模块向外提供对象存储服务，并且和对象存储的事实标准Amazon S3以及Swift兼容。所以能看出来这其实是个大一统解决方案，啥都齐全。 上面讲的大家或多或少都有所了解，但底层的RADOS的细节可能会忽略，RADOS也是个标准对象存储，里面也有MDS的元数据管理和OSD的数据存储，而OSD本身是可以基于一个本地文件系统的，比如XFS/EXT4/Brtfs。在早期版本，你在部署Ceph的时候，是不是要给OSD创建数据目录啊？这一步其实就已经在本地文件系统上做操作了（现在的版本Ceph可以直接使用硬盘）。
现在我们来看数据访问路径，如果看Ceph的文件接口，自底层向上，经过了硬盘（块）->文件->对象->文件的路径；如果看RBD的块存储服务，则经过了硬盘（块）->文件->对象->块，也可能是硬盘（块）->对象->块的路径；再看看对象接口（虽然用的不多），则是经过了硬盘（块）->文件->对象或者硬盘（块）->对象的路径。 是不是各种组合差不多齐全了？如果你觉得只有Ceph一个这么玩，再给你介绍另一个狠角色，老牌的开源分布式文件系统GlusterFS最近也宣布要支持对象存储。它打算使用swift的上层PUT、GET等接口，支持对象存储。这是文件存储去兼容对象存储。对象存储Swift也没闲着，有人在研究Swift和hadoop的兼容性，要知道MapReduce标准是用原生的HDFS做存储的，这相当是对象存储去兼容文件存储，看来混搭真是潮流啊。
虽说现在大家都这么随便结合，但是这三种存储本质上还是有不同的，我们回到计算机的基础课程，从数据结构来看，这三种存储有着根本不同。块存储的数据结构是数组，而文件存储是二叉树（B,B-,B+,B*各种树），对象存储基本上都是哈希表。
数组和二叉树都是老生常谈，没有太多值得说的，而对象存储使用的哈希表也就是常听说的键值（KeyVaule型）存储的核心数据结构，每个对象找一个UID（所谓的“键”KEY），算哈希值（所谓的“值Vaule”）以后和目标对应。找了一个哈希表例子如下：
键值对应关系简单粗暴，毕竟算个hash值是很快的，这种扁平化组织形式可以做得非常大，避免了二叉树的深度，对于真.海量的数据存储和大规模访问都能给力支持。所以不仅是对象存储，很多NoSQL的分布式数据库都会使用它，比如Redis，MongoDB，Cassandra 还有Dynamo等等。顺便说一句，这类NoSQL的出现有点打破了数据库和文件存储的天然屏障，原本关系数据库里面是不会存放太大的数据的，但是现在像MongoDB这种NoSQL都支持直接往里扔大个的“文档”数据，所以从应用角度上，有时候会把对象存储，分布式文件系统，分布式数据库放到一个台面上来比较，这才是混搭。
当然实际上几个开源对象存储比如swift和ceph都是用的一致性哈希，进阶版，最后变成了一个环，首首尾相接，避免了节点故障时大量数据迁移的尴尬
对象存储与块存储的比较
我们将一盘硬盘连续的地址划分成等大小的若干小块，然后我们将每个小块等同为对象存储的一个对象，那么是不是说多个对象就能构建一个块呢？的确，在当前的分布式块存储中一般是采用分布式对象存储为基础的，如VMware的VSAN、华为的FusionStorage都是使用这样的方式，而开源的Ceph更是将其底层的统一对象存储平台Rados作为其基础，在上面封装有块、文件和对象三种接口。
对象存储与文件系统的比较
对象存储与文件系统的区别
对象存储和文件系统在接口上的本质区别是对象存储不支持和fread和fwrite类似的随机位置读写操作，即一个文件PUT到对象存储里以后，如果要读取，只能GET整个文件，如果要修改一个对象，只能重新PUT一个新的到对象存储里，覆盖之前的对象或者形成一个新的版本。 如果结合平时使用云盘的经验，就不难理解这个特点了，用户会上传文件到云盘或者从云盘下载文件。如果要修改一个文件，会把文件下载下来，修改以后重新上传，替换之前的版本。实际上几乎所有的互联网应用，都是用这种存储方式读写数据的，比如微信，在朋友圈里发照片是上传图像、收取别人发的照片是下载图像，也可以从朋友圈中删除以前发送的内容；微博也是如此，通过微博API我们可以了解到，微博客户端的每一张图片都是通过REST风格的HTTP请求从服务端获取的，而我们要发微博的话，也是通过HTTP请求将数据包括图片传上去的。在没有对象存储以前，开发者需要自己为客户端提供HTTP的数据读写接口，并通过程序代码转换为对文件系统的读写操作。
扁平的数据组织结构
对比文件系统，对象存储的第二个特点是没有嵌套的文件夹，而是采用扁平的数据组织结构，往往是两层或者三层，例如AWS S3和华为的UDS，每个用户可以把它的存储空间划分为“容器”（Bucket），然后往每个容器里放对象，对象不能直接放到租户的根存储空间里，必须放到某个容器下面，而不能嵌套，也就是说，容器下面不能再放一层容器，只能放对象。OpenStack Swift也类似 这就是所谓“扁平数据组织结构”，因为它和文件夹可以一级一级嵌套不同，层次关系是固定的，而且只有两到三级，是扁平的。每一级的每个元素，例如S3中的某个容器或者某个对象，在系统中都有唯一的标识，用户通过这个标识来访问容器或者对象，所以，对象存储提供的是一种K/V的访问方式。
文件系统和对象存储系统的优劣和发展趋势分析
上述分析了对象存储的特点并与文件系统做了比较，接下来就不得不回答一个问题：文件系统是不是没有生命力了？答案当然是否定的。对象存储打破了文件系统一统天下的局面，给我们带来了更多的选择，并不意味着我们就要否定文件系统。 而对于一些场景，比如虚拟机活动镜像的存储，或者说虚拟机硬盘文件的存储，还有大数据处理等场景，对象存储就显得捉襟见肘了。而文件系统在这些领域有突出的表现，比如Nutanix的NDFS（Nutanix Distributed Filesystem）和VMware的VMFS（VMware Filesystem）在虚拟机镜像存储方面表现很出色，Google文件系统GFS及其开源实现HDFS被广泛用于支撑基于MapReduce模型的大数据处理支持得很好，而且能够很好地支持百GB级、TB级甚至更大文件的存储。 由此看来文件系统将来的发展趋势更多的是专用文件系统，而不再是以前一套Filesystem一统天下的做法，更有一些部分要让位于对象存储或者其他存储形态。 从另一个角度来看，现代对象存储系统的“甜区”在哪里：1. 互联网和类似互联网的应用场景，这不仅仅是因为REST风格的HTTP的接口，而且还因为大多数对象存储系统在设计上能够非常方便地进行横向扩展以适应大量用户高并发访问的场景；2. 海量十KB级到GB级对象/文件的存储，小于10KB的数据更适用于使用K/V数据库，而大于10GB的文件最好将其分割为多个对象并行写入对象存储系统中，多数对象存储系统都有单个对象大小上限的限制。所以，如果应用具有上述两种特点，对象存储是首选。 也有人在对象存储上做出进一步的开发或者改进，使其能够很好地支持归档备份、MapReduce大数据处理等场景，甚至将对象存储的接口转为文件系统接口；反之，OpenStack Swift等对象存储系统也支持使用GlusterFS等通用文件系统作为存储后端。人们为什么会在这些对象存储和文件系统相互转换的技术上进行人力和资金的投入？这些做法的意义何在？应该在什么时候使用这些技术？ 说明它们在不同的应用场景下还是有各自的优劣势的。
不管是哪一种存储方案，都有特定的场景。能解决用户需求的，能节约资金的，能帮助实现业务价值的，就是好的存储。我们不能一概而论。而现在看，对象存储，毕竟更适合互联网场景下。
因为现在的文件系统成为瓶颈——文件数在千万以上，或者单个卷在百TB以上，文件系统就难以处理；同时企业需要更灵活地共享和访问数据，需要存储系统能够支持大规模并发、随时访问，并且能够实现跨数据中心的分布式存储。采用集中式的块和文件系统存储已经无法满足目前的需求。
所以 即使是使用块和文件存储，大方向上还是例如Ceph的基于对象存储原理上实现的分布式块存储和文件存储，而不会再是集中式的块存储和文件存储。
市场上的分布式块存储
Amazon EBS & 阿里云磁盘
Amazon作为领先的IAAS服务商，其API目前是IAAS的事实标准。Amazon EC2目前仍然一骑绝尘，在大多数方面远超其他IAAS服务商。通过Amazon EC2的产品介绍是快速了解Amazon EC2的捷径。
而EBS是Amazon提供的块存储服务，通过EBS，用户可以随时增删迁移volume和快照操作。
Amazon EC2实例可以将根设备数据存储在Amazon EBS或者本地实例存储上。使用 Amazon EBS时，根设备中的数据将独立于实例的生命周期保留下来，使得在停止实例后仍可以重新启动使用，与笔记本电脑关机并在再次需要时重新启动相似。另一方面，本地实例存储仅在实例的生命周期内保留。这是启动实例的一种经济方式，因为数据没有存储到根设备中。
Amazon EBS提供两种类型的卷，即标准卷和预配置IOPS卷。它们的性能特点和价格不同，可以根据应用程序的要求和预算定制所需的存储性能。
标准卷可为要求有适度或突发式I/O的应用程序提供存储。这些卷平均可以提供大约 100 IOPS，最多可突增至数百 IOPS。标准卷也非常适合用作引导卷，其突发能力可提供快速的实例启动时间(通常十几秒)。
预配置 IOPS 卷旨在为数据库等 I/O 密集型随机读写工作负载提供可预计的高性能。创建一个卷时，利用预置 IOPS 为卷确定 IOPS 速率，随之 Amazon EBS 在该卷的生命周期内提供该速率。Amazon EBS 目前支持每预配置 IOPS 卷最多 4000 个IOPS。您可以将多个条带式卷组合在一起，为您的应程程序提供每个Amazon EC2数千IOPS的能力。
EBS可以在卷连接和使用期间实时拍摄快照。不过，快照只能捕获已写入Amazon EBS 卷的数据，不包含应用程序或操作系统已在本地缓存的数据。如果需要确保能为实例连接的卷获得一致的快照，需要先彻底地断开卷连接，再发出快照命令，然后重新连接卷。
EBS快照目前可以跨regions增量备份，意味着EBS快照时间会大大缩短，从另一面增加了EBS使用的安全性。
总的来说，Amazon EBS是目前IAAS服务商最引入注目的服务之一，目前的OpenStack、CloudStack等等其他开源框架都无法提供Amazon EBS对于的如此弹性和强大的服务。了解和使用Amazon EBS是学习IAAS块存储的最好手段。
阿里云
阿里云是国内的公共云计算服务商，不过这里阿里云目前的块存储服务较于Amazon EBS差的太远，阿里云磁盘目前仅支持在创建云主机的时候绑定云磁盘或者在升级云主机的进行云磁盘扩容，这从根本上就是传统的虚拟主机的特点而不是所谓的“云磁盘”。
从目前的阿里云磁盘的限制:
无法快速创建或删除volume，在进行扩容时需要升级云主机才能达到，而升级云主机只有在下月云主机套餐到期时才能生效(想起了中国移动套餐) 一个云主机最多只能绑定3个云磁盘 从阿里云磁盘目前的使用分析，阿里云磁盘系统目前还很不成熟，以下是我对阿里云磁盘实现的推测
阿里云主机是跟磁盘绑定的，这意味着阿里云的云磁盘是local volume(因此性能还是挺可观的)。如果用户需要扩容、减少都是需要下个月更说明了这点，整个主机在扩容时去调度合适的有足够存储空间的host，然后进行扩容。 阿里云磁盘是分布式块存储系统，但是由于其QoS无法保证和其他资源调度原因无法提供足够的块存储支持。 从演讲回顾：阿里云存储技术的演进，以及云服务用例最佳实践中了解到阿里云是基于自家的“盘古”系统，那么从实际使用来说，远没达到一般的分布式块存储系统的要求。
Cinder
OpenStack是目前流行的IAAS框架，提供了AWS类似的服务并且兼容其API。OpenStack Nova是计算服务，Swift是对象存储服务，Quantum是网络服务，Glance是镜像服务，Cinder是块存储服务，Keystone是身份认证服务，Horizon是Dashboard，另外还有Heat、Oslo、Ceilometer、Ironic等等项目。
Cinder是OpenStack中提供类似于EBS块存储服务的API框架，它并没有实现对块设备的管理和实际服务提供，用来为后端不同的存储结构提供统一的接口与OpenStack进行整合，不同的块设备服务厂商在Cinder中实现其驱动支持。后端的存储可以是DAS，NAS，SAN，对象存储或者分布式文件系统。也就是说，Cinder的块存储数据完整性，可用性保障是由后端存储提供的。在CinderSupportMatrix中可以看到众多存储厂商如NetAPP、IBM、SolidFire、EMC和众多开源快存储系统对Cinder的支持，在这里我们也可以看到OpenStack是非常受欢迎的。
Cinder只是提供了一层抽象，然后通过其后段支持的driver实现来发出命令来得到回应。关于块存储的分配信息以及选项配置等会被保存到OpenStack统一的DB中。
Ceph & Sheepdog
Ceph是开源实现的PB级分布式文件系统，通过其分布式对象存储机制为上层提供了文件接口、块存储接口和对象存储接口。Inktank是Ceph的主要支持商，Ceph的团队目前主要来自Inktankcom。
Ceph目前是OpenStack支持的开源块存储实现系统(即Cinder项目backend driver之一)，其实现分为三个部分: OSD, Monitor, MDS。OSD是底层对象存储系统，Monitor是集群管理系统，MDS是用来支持POSIX文件接口的Metadata Server。从Ceph的原始论文(Ceph: Reliable, Scalable, and High-Performance Distributed Storage)来看，Ceph专注于扩展性，高可用性和容错性。Ceph放弃了传统的Metadata查表方式(HDFS)而改用算法(CRUSH)去定位具体的block。
利用Ceph提供的RULES可以弹性地制订存储策略和Pool选择，Monitor作为集群管理系统掌握了全部的Cluster Map，Client在没有Map的情况下需要先向Monitor请求得到，然后通过Object id计算相应的OSD Server。
Ceph支持传统的POSIX文件接口，因此需要额外的MDS(Meatadata Server)支持文件元信息(Ceph的块存储和对象存储支持不需要MDS服务)。Ceph将data和metadata分离到两个服务上，跟传统的分布式系统如Lustre相比可以大大增强扩展性。在小文件读写上，Ceph读写文件会有[RTT*2]，在每次open时，会先去Metadata server查询一次，然后再去object server。除了open操作外，Ceph在delete上也有问题，它需要到Metadata Server擦除对应的metadata，是n(2)复杂度。Ceph在Metadata上并非只有坏处，通过Metadata Server，像目录列表等目录操作为非常快速，远超GlusterFS等实现。
关于Ceph作为块存储项目的几个问题需要考虑:
Ceph在读写上不太稳定（有btrfs的原因），目前Ceph官方推荐XFS作为底层文件系统 Ceph的扩展性较难，如果需要介入Ceph，需要较长时间 Ceph的部署和集群不够稳定 Sheepdog
Sheepdog是另一个分布式块存储系统，它与Ceph相比，最大优势就是代码短小好维护和hack的成本很小。Sheepdog也有很多Ceph不支持的特性，比如说Multi-Disk, cluster-wide snapshot等。
Sheepdog主要有两部分，一个是集群管理，另一个是存储服务。集群管理目前使用Corosync或者Zookper来完成，存储服务的特点是在client和存储host有Cache的实现可以大大减小数据流量。
目前Sheepdog只在QEMU端提供Drive，而缺少library支持，这是Sheepdog目前最主要的问题。但是社区已经有相关的blueprint在讨论这个问题。
目前Taobao是Sheepdog主要用户和社区贡献者。
块存储，文件存储，对象存储优缺点
先说说块存储吧，典型代表–SAN。对于用户来说，SAN好比是一块大磁盘，用户可以根据需要随意将SAN格式化成想要的文件系统来使用。SAN在网络中通过iSCSI（IPSAN）协议连接，属block及存储，但可扩展性较差。
再说说文件集存储，典型代表–NAS。对于用户来说，NAS好比是一个共享文件夹，文件系统已经存在，用户可以直接将自己的数据存放在NAS上。NAS以文件为传输协议，开销很大，不利于在高性能集群中使用。
而所谓对象存储，就是每个数据对应着一个唯一的id，在面向对象存储中，不再有类似文件系统的目录层级结构，完全扁平化存储，即可以根据对象的id直接定位到数据的位置，这一点类似SAN，而每个数据对象即包含元数据又包括存储数据，含有文件的概念，这一点类似NAS。除此之外，用户不必关系数据对象的安全性，数据恢复，自动负载平衡等等问题，这些均由对象存储系统自身完成。而且，面向对象存储还解决了SAN面临的有限扩充和NAS传输性能开销大问题，能够实现海量数据存储。
存储方式 技术实现 优势 劣势 代表作
块存储 裸盘上划分逻辑卷，逻辑卷格式化成任意文件系统 支持多种文件系统，传输速度快，提供硬件容错机制 无法实现网络共享 FC-SAN，iSCSI
文件存储 在格式化的磁盘上存储文件 提供网络共享 网络传输速度制约读写速度，分层目录结构限制可扩展性 NFS，FAT，EXT3
对象存储 以灵活可定制的对象为存储单元，元数据服务器提供快速并发寻址 读写速度较快的同时支持网络共享，对象灵活定义 管理软件的购买、使用和运维成本高 Swift
一、【块存储】
典型设备：磁盘阵列，硬盘
块存储主要是将裸磁盘空间整个映射给主机使用的，就是说例如磁盘阵列里面有5块硬盘（为方便说明，假设每个硬盘1G），然后可以通过划逻辑盘、做Raid、或者LVM（逻辑卷）等种种方式逻辑划分出N个逻辑的硬盘。（假设划分完的逻辑盘也是5个，每个也是1G，但是这5个1G的逻辑盘已经于原来的5个物理硬盘意义完全不同了。例如第一个逻辑硬盘A里面，可能第一个200M是来自物理硬盘1，第二个200M是来自物理硬盘2，所以逻辑硬盘A是由多个物理硬盘逻辑虚构出来的硬盘。）
接着块存储会采用映射的方式将这几个逻辑盘映射给主机，主机上面的操作系统会识别到有5块硬盘，但是操作系统是区分不出到底是逻辑还是物理的，它一概就认为只是5块裸的物理硬盘而已，跟直接拿一块物理硬盘挂载到操作系统没有区别的，至少操作系统感知上没有区别。
此种方式下，操作系统还需要对挂载的裸硬盘进行分区、格式化后，才能使用，与平常主机内置硬盘的方式完全无异。
优点：
1、 这种方式的好处当然是因为通过了Raid与LVM等手段，对数据提供了保护。
2、 另外也可以将多块廉价的硬盘组合起来，成为一个大容量的逻辑盘对外提供服务，提高了容量。
3、 写入数据的时候，由于是多块磁盘组合出来的逻辑盘，所以几块磁盘可以并行写入的，提升了读写效率。
4、 很多时候块存储采用SAN架构组网，传输速率以及封装协议的原因，使得传输速度与读写速率得到提升。
缺点：
1、采用SAN架构组网时，需要额外为主机购买光纤通道卡，还要买光纤交换机，造价成本高。
2、主机之间的数据无法共享，在服务器不做集群的情况下，块存储裸盘映射给主机，再格式化使用后，对于主机来说相当于本地盘，那么主机A的本地盘根本不能给主机B去使用，无法共享数据。
3、不利于不同操作系统主机间的数据共享：另外一个原因是因为操作系统使用不同的文件系统，格式化完之后，不同文件系统间的数据是共享不了的。例如一台装了WIN7/XP，文件系统是FAT32/NTFS，而Linux是EXT4，EXT4是无法识别NTFS的文件系统的。就像一只NTFS格式的U盘，插进Linux的笔记本，根本无法识别出来。所以不利于文件共享。
二、【文件存储】
典型设备：FTP、NFS服务器
为了克服上述文件无法共享的问题，所以有了文件存储。
文件存储也有软硬一体化的设备，但是其实普通拿一台服务器/笔记本，只要装上合适的操作系统与软件，就可以架设FTP与NFS服务了，架上该类服务之后的服务器，就是文件存储的一种了。
主机A可以直接对文件存储进行文件的上传下载，与块存储不同，主机A是不需要再对文件存储进行格式化的，因为文件管理功能已经由文件存储自己搞定了。
优点：
1、造价交低：随便一台机器就可以了，另外普通以太网就可以，根本不需要专用的SAN网络，所以造价低。
2、方便文件共享：例如主机A（WIN7，NTFS文件系统），主机B（Linux，EXT4文件系统），想互拷一部电影，本来不行。加了个主机C（NFS服务器），然后可以先A拷到C，再C拷到B就OK了。（例子比较肤浅，请见谅……）
缺点：
读写速率低，传输速率慢：以太网，上传下载速度较慢，另外所有读写都要1台服务器里面的硬盘来承担，相比起磁盘阵列动不动就几十上百块硬盘同时读写，速率慢了许多。
三、【对象存储】
典型设备：内置大容量硬盘的分布式服务器
对象存储最常用的方案，就是多台服务器内置大容量硬盘，再装上对象存储软件，然后再额外搞几台服务作为管理节点，安装上对象存储管理软件。管理节点可以管理其他服务器对外提供读写访问功能。
之所以出现了对象存储这种东西，是为了克服块存储与文件存储各自的缺点，发扬它俩各自的优点。简单来说块存储读写快，不利于共享，文件存储读写慢，利于共享。能否弄一个读写快，利 于共享的出来呢。于是就有了对象存储。
首先，一个文件包含了了属性（术语叫metadata，元数据，例如该文件的大小、修改时间、存储路径等）以及内容（以下简称数据）。
以往像FAT32这种文件系统，是直接将一份文件的数据与metadata一起存储的，存储过程先将文件按照文件系统的最小块大小来打散（如4M的文件，假设文件系统要求一个块4K，那么就将文件打散成为1000个小块），再写进硬盘里面，过程中没有区分数据/metadata的。而每个块最后会告知你下一个要读取的块的地址，然后一直这样顺序地按图索骥，最后完成整份文件的所有块的读取。
这种情况下读写速率很慢，因为就算你有100个机械手臂在读写，但是由于你只有读取到第一个块，才能知道下一个块在哪里，其实相当于只能有1个机械手臂在实际工作。
而对象存储则将元数据独立了出来，控制节点叫元数据服务器（服务器+对象存储管理软件），里面主要负责存储对象的属性（主要是对象的数据被打散存放到了那几台分布式服务器中的信息），而其他负责存储数据的分布式服务器叫做OSD，主要负责存储文件的数据部分。当用户访问对象，会先访问元数据服务器，元数据服务器只负责反馈对象存储在哪些OSD，假设反馈文件A存储在B、C、D三台OSD，那么用户就会再次直接访问3台OSD服务器去读取数据。
这时候由于是3台OSD同时对外传输数据，所以传输的速度就加快了。当OSD服务器数量越多，这种读写速度的提升就越大，通过此种方式，实现了读写快的目的。
另一方面，对象存储软件是有专门的文件系统的，所以OSD对外又相当于文件服务器，那么就不存在文件共享方面的困难了，也解决了文件共享方面的问题。
所以对象存储的出现，很好地结合了块存储与文件存储的优点。
最后为什么对象存储兼具块存储与文件存储的好处，还要使用块存储或文件存储呢？
1、有一类应用是需要存储直接裸盘映射的，例如数据库。因为数据库需要存储裸盘映射给自己后，再根据自己的数据库文件系统来对裸盘进行格式化的，所以是不能够采用其他已经被格式化为某种文件系统的存储的。此类应用更适合使用块存储。
2、对象存储的成本比起普通的文件存储还是较高，需要购买专门的对象存储软件以及大容量硬盘。如果对数据量要求不是海量，只是为了做文件共享的时候，直接用文件存储的形式好了，性价比高。
作者：张小凡vip 来源：CSDN 原文：https://blog.csdn.net/zzq900503/article/details/79919324 版权声明：本文为博主原创文章，转载请附上博文链接！
