以前公司seafile后端存储,根据官方支持,用了ceph

记一些相关的杂文

Docker

支持AUFS,Btrfs,Device mapper,OverlayFS,ZFS 存储驱动

没有单一的驱动适合所有的应用场景,要根据不同的场景选择合适的存储驱动,才能有效的提高Docker的性能

Btrfs

B-tree file system 针对Linux开发的一个CoW文件系统

oracle 2007年开发,2014年正式发布稳定版

目的在解决Linux文件系统中缺少池、快照、校验和以及集成的跨多设备访问等问题

规模化不仅仅是指解决存储问题,也意味着通过简洁的界面提供对存储的管控和管理能力,让大家能看到已使用的内容并使它更可靠

重要特性

  • 文件大小上限16EiB
  • 快照可写和快照只读
  • 子卷(分离内部文件系统的根)
  • 数据和元数据的校验和
  • 压缩 (gzip和LZO)
  • 整合的多设备支持
  • 文件条块化(strip)、文件镜像和文件条块化+镜像三种部署方案
  • 高效的增量备份
  • 后台消除进程支持查找和修复冗余副本上的文件错误
  • 在线文件系统碎片整理和离线文件系统检查
  • 对RAID 5/RAID 6加强支持

条带(strip)

把连续的数据,分割成相同大小的数据块,分别写到不同磁盘

将多个磁盘驱动器合并为一个卷的方法。 许多情况下,通过硬件控制器完成

多个进程同时访问一个磁盘时,可能会出现磁盘冲突

多数磁盘系统对访问次数(每秒的 I/O 操作,IOPS)和数据传输率(每秒传输的数据量,TPS)有限制。当达到这些限制时,后面需要访问磁盘的进程就需要等待,这就是磁盘冲突

避免磁盘冲突是优化 I/O 性能的一个重要目标,而 I/O 性能的优化与其他资源(如CPU和内存)的优化有着很大的区别 ,I/O 优化最有效的手段是将 I/O 最大限度的进行平衡

条带深度(stripe depth)和条带宽度(stripe width) ,在不同场景,如 oracle 等,调优很多学问

http://blog.csdn.net/jlds123/article/details/11813313

架构

Ceph集群的节点三种角色

Monitor,监控集群的健康状况,向客户端发送最新的CRUSH map(含有当前网络的拓扑结构)

OSD,维护节点上的对象,响应客户端请求,与其他OSD节点同步

MDS,提供文件的Metadata,如果不使用CephFS可以不安装

Ceph将文件分割后均匀随机地分散在各个节点上,用CRUSH算法来确定对象的存储位置,只要有当前集群的拓扑结构,Ceph客户端就能直接计算出文件的存储位置,直接跟OSD节点通信获取文件而不需要询问中心节点获得文件位置,避免了单点风险

一些对象存储的缺点

  • 最终一致性问题

没有像文件系统那样的分布式文件锁,因此谁最后写谁就是最新,在某些情况下会产生一致性偏差

  • list问题

没有inode这个东西,对象存储的遍历机制是依靠路径的前缀作为选择机制的

比如 list s3://bucket1/dir1下的对象,可能dir1的子目录只有一个sub_dir,但是对象存储会把sub_dir下的对象也遍历一遍,最后筛选出其直接子目录,也就是sub_dir

如果sub_dir下有上百万的对象,这个ls s3://bucket1/dir1会非常非常慢,甚至能让Ceph RGW无法响应

Amazon EMR是用一致性图表来解决这个问题的

HDFS适合存储大问题,ChunkSize通常64M,非常不适合小文件,比如几M大小的图片

Ceph的对象存储,减少了很多在文件系统下储存小文件的i-node开销

好的架构,必须事先明确问题、目标、策略。就像当年Google开发出三架马车一样(GFS,MapReduce,BigTable)一样

HDFS磁盘利用率差,多副本冗余的利用率是比不上对象存储的纠删码的。虽然目前HDFS也开始支持纠删码,但是成熟度有待考证