块存储,简单来说就是提供了块设备存储的接口。通过向内核注册块设备信息,在Linux中通过lsblk可以得到当前主机上块设备信息列表。
下面会先介绍常见的单机块设备工具来建立Common Base。
Contents
首先一个硬盘是一个块设备,内核检测到硬盘然后在/dev/下会看到/dev/sda/,因为我们需要利用一个硬盘来得到不同的分区来做不同的事,通过fdisk工具得到/dev/sda1, /dev/sda2等,这种方式通过直接写入分区表来规定和切分硬盘,是最死板的分区方式。
LVM是一种逻辑卷管理器,通过LVM来对硬盘创建逻辑卷组和得到逻辑卷来完成目的比fdisk方式更加弹性,如果你目前对LVM用途还不熟悉或者不大清楚,请参考以下链接:
Device-mapper是一种支持逻辑卷管理的通用设备映射机制,为存储资源管理的块设备驱动提供了一个高度模块化的内核架构。LVM是基于Device-mapper的用户程序实现,以下链接对Device-mapper架构进行了极好的说明:
在接触了单机下的逻辑卷管理后,你需要了解SAN,目前主流的企业级存储方式。
大部分SAN使用SCSI协议在服务器和存储设备之间传输和沟通,通过在SCSI之上建立不同镜像层,可以实现存储网络的连接。常见的有iSCSI,FCP,Fibre Channel over Ethernet等。
SAN通常需要在专用存储设备中建立,而iSCSI是基于TCP/IP的SCSI映射,通过iSCSI协议和Linux iSCSI项目我们可以在常见的PC机上建立SAN存储。。
如何建立在PC机上的SAN可以参考:
这篇文章的iSCSI target管理方式不太方便,通常利用targetcli管理target是及其方便的。targetcli可以直接建立和管理不同backstone类型的逻辑卷和不同的export方式,如建立ramdisk并且通过iSCSI export非常方便,操作方式见targetcli screencast Part 2 of 3: ISCSI – YouTube。
以上都是common-base,接下来才开始本文的正式分享内容,包括公共云技术服务提供的块存储服务,开源的块存储框架和实现以及各大Startup目前对块存储的定义和支持。
在面对极具弹性的存储需求和性能要求下,单机或者独立的SAN越来越不能满足企业的需要。如同数据库系统一样,块存储在scale up的瓶颈下也面临着scale out的需要。我们可以用以下几个特点来描述分布式块存储系统的概念:
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差的太远,阿里云磁盘目前仅支持在创建云主机的时候绑定云磁盘或者在升级云主机的进行云磁盘扩容,这从根本上就是传统的虚拟主机的特点而不是所谓的“云磁盘”。
从目前的阿里云磁盘的限制:
从阿里云磁盘目前的使用分析,阿里云磁盘系统目前还很不成熟,以下是我对阿里云磁盘实现的推测
从演讲回顾:阿里云存储技术的演进,以及云服务用例最佳实践中了解到阿里云是基于自家的“盘古”系统,那么从实际使用来说,远没达到一般的分布式块存储系统的要求。
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是开源实现的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的文档可以参考以下链接:
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作为块存储项目的几个问题需要考虑:
Sheepdog是另一个分布式块存储系统,它与Ceph相比,最大优势就是代码短小好维护和hack的成本很小。Sheepdog也有很多Ceph不支持的特性,比如说Multi-Disk, cluster-wide snapshot等。
Sheepdog主要有两部分,一个是集群管理,另一个是存储服务。集群管理目前使用Corosync或者Zookper来完成,存储服务的特点是在client和存储host有Cache的实现可以大大减小数据流量。
目前Sheepdog只在QEMU端提供Drive,而缺少library支持,这是Sheepdog目前最主要的问题。但是社区已经有相关的blueprint在讨论这个问题。
了解Sheepdog通过以下链接:
目前Taobao是Sheepdog主要用户和社区贡献者。
目前存储领域Startup主要是集中在SSD对存储集群的利用,VDI存储设计,计算存储一体机等方面。
下面举几个我了解的关于块设备和存储的典型厂商:
Nimble: Nimble Storage是09年成立的一家存储服务商,其核心是利用Cache Accelerated Sequential Layout (CASL™) 专利技术架构了一个完备的存储体系栈,包括应用级缓存、第一级存储、第二级缓存和灾备。它主要解决当前虚拟化进程越来越快而导致对存储要求的演变,Nimble致力于简化企业建造自己的IT虚拟化平台对存储 的要求,提供一系列打包的存储设备和软件。并且希望打造一个与顶级vendor协作的生态系统,面对目前企业对 VDI的 需求,Nimble为Microsoft、Vmware等等虚拟化厂商提供有力并且整合的存储保证。
Tegile: Tegile也是一家VDI存储服务商,为中小型企业提供高性能、空间高效利用并且廉价的存储阵列。
Tintri:Tintri VMstore是一个与VMware vCenter Server整合的数据存储和监控平台,通过收集每个 VM和每个虚拟硬盘的统计数据来智能的进行存储资源的分配,并且对读写请求进行集中调度来得到 更好的性能。
Nutanix:Nutanix提供的Cluster Unit借鉴了Amazon、Google、Facebook的数据中心设计, 重新将存储和计算放在一个单元里,每一个VM都会尽可能采用DAS的方式连接并得到 高性能的IO能力。通过额外的控制服务来管理众多Cluster Unit并将每一个Unit的 本地存储复制到其他Unit来保证数据安全性。
StorSimple:StorSimple提供的硬件用于公共云与企业本地存储整合,通过StorSimple,为公共 云数据提供本地加速、备份和灾难恢复。StorSimple主要将SSD、SAS和Cloud三种类型的存储类型进行整合,SSD提供最“热” 的数据缓存、SAS也就是本地的硬盘级存储提供较“热”的存储,云端存储“冷”数据。 通过三种性能差异较大的类型进行智能切换和支持上层的IO优化来加速企业应用。除 此之外,StorSimple也提供数据去重、Thin Provision、压缩和快照等基本功能。
Nexenta:Nexenta是一家04年成立的Software-defined-Storage服务商,提供运行于ZFS的 企业级NAS、SAN解决方案。NexentaStor建立在开放的Nexenta Core Platform(NCP) 上,NCP是基于OpenSolaris内核和Ubuntu用户空间的一系列命令行接口和Web UI界面。 在NexentaStor出现之前,企业级NAS和SAN供应商要求客户从供应商处购买存储硬件。 但大多数供应商的磁盘格式是专有技术――因此,要从这些供应商管理下的磁盘中取出 数据的唯一途径就是使用该供应商的解决方案。如果供应商中断对特定硬件系列的支持 ,用户将不得不 进行升级或实施难度更大的迁移,从传统硬件集迁移到另一个硬件集。 目前为获得企业级性能和数据完整性已不再需要这一级别的供应商锁定。 NexentaStor 运行于适当配置的x86服务器上,将传统存储系统升级为统一的存储解决方案,以提供 SAN和NAS性能以及最高级别的端对端数据完整性检查,通过检查可发现并校正数据损坏。
EMC ViPR: 使用OpenStack组件打造开源版EMC ViPR
本来想多写一些个人的观点和研究分享,但因为这个标题实在有点大,为了避免写一篇太空文章,还是要多写一些Prerequisite,但是很多内容其他文章已经非常好了,因此就直接引用了。内容范围定的太大导致很大东西写太多不太合适,写少了只能写一些简单的介绍,最后还是将其定位于Overview级别的文章吧。。。