转载：理解Ceph的三种存储接口:块设备、文件系统、对象存储
 
一. Ceph的块设备存储接口
 
首先，什么是块设备？
 
块设备是i/o设备中的一类，是将信息存储在固定大小的块中，每个块都有自己的地址，还可以在设备的任意位置读取一定长度的数据。
 
看不懂？那就暂且认为块设备就是硬盘或虚拟磁盘。
 
查看下Linux环境中的设备：
 
#  lsblk
 
 
上面的/dev/sda、/dev/sdb和/dev/hda都是块设备文件，这些文件是怎么出现的呢？
 
当给计算机连接块设备（硬盘）后，系统检测的有新的块设备，该类型块设备的驱动程序就在/dev/下创建个对应的块设备设备文件，用户就可以通过设备文件使用该块设备了。
 
它们怎么有的叫 sda？有的叫 sdb？有的叫 hda？
 
以sd开头的块设备文件对应的是SATA接口的硬盘，而以hd开头的块设备文件对应的是IDE接口的硬盘。
 
那SATA接口的硬盘跟IDE接口的硬盘有啥区别？你只需要知道，IDE接口硬盘已经很少见到了，逐渐被淘汰中，而SATA接口的硬盘是目前的主流。而sda和sdb的区别呢？当系统检测到多个SATA硬盘时，会根据检测到的顺序对硬盘设备进行字母顺序的命名。
 
怎么还有的叫 rbd1 和 rbd2 呢?
 
被你发现了，rbd就是我们压轴主角了。rbd就是由Ceph集群提供出来的块设备。可以这样理解，sda和hda都是通过数据线连接到了真实的硬盘，而rbd是通过网络连接到了Ceph集群中的一块存储区域，往rbd设备文件写入数据，最终会被存储到Ceph集群的这块区域中。
 
那么块设备怎么用呢？
 
我们打个比方，一个块设备是一个粮仓，数据就是粮食。农民伯伯可以存粮食（写数据）了，需要存100斤玉米，粮仓（块设备）这么大放哪里呢，就挨着放（顺序写），又需要存1000斤花生，还是挨着放。又需要存……后来，农民伯伯来提粮食（读数据）了，他当时存了1000斤小麦，哎呀妈呀，粮仓这么大，小麦在哪里啊？仓库管理员找啊找，然后哭晕在了厕所！
 
新管理员到任后，想了个法子来解决这个问题，用油漆把仓库划分成了方格状，并且编了号，在仓库门口的方格那挂了个黑板，当农民伯伯来存粮食时，管理员在黑板记录，张三存了1000斤小麦在xx方格处。后来，农民伯伯张三来取粮食时，仓库管理员根据小黑板的记录很快提取了粮食。
 
故事到此为止了，没有方格和黑板的仓库（块设备）称为裸设备。由上例可见，裸设备对于用户使用是很不友好的，直接导致了旧仓库管理员的狗带。例子中划分方格和挂黑板的过程其实是在块设备上构建文件系统的过程，文件系统可以帮助块设备对存储空间进行条理的组织和管理，于是新管理员通过文件系统（格子和黑板）迅速找到了用户（农民伯伯张三）存储的数据（1000斤小麦）。
 
针对多种多样的使用场景，衍生出了很多的文件系统，有的文件系统能够提供更好的读性能，有的文件系统能提供更好的写性能。我们平时常用的文件系统如xfs、ext4是读写性能等各方面比较均衡的通用文件系统。
 
能否直接使用不含有文件系统块设备呢？
 
可以的，xfs和ext4等通用的文件系统旨在满足大多数用户的存储需求，所以在数据存储的各方面的性能比较均衡。然而，很多应用往往并不需要这种均衡，而需要突出某一方面的性能，如小文件的存储性能。此时，xfs、ext4等通用文件系统如果不能满足应用的需求，应用往往会在裸设备上实现自己的数据组织和管理方式。简单的说，就是应用为了强化某种存储特性而实现自己定制的数据组织和管理方式，而不使用通用的文件系统。
 
Ceph块设备接口怎么使用？
 
在Ceph集群中创建块设备：
 
 
总结一下，块设备可理解成一块硬盘，用户可以直接使用不含文件系统的块设备，也可以将其格式化成特定的文件系统，由文件系统来组织管理存储空间，从而为用户提供丰富而友好的数据操作支持。
 
 
 
二. Ceph的文件系统存储接口
 
什么是Ceph的文件系统接口？
 
还记得上面说的块设备上的文件系统吗，用户可以在块设备上创建xfs文件系统，也可以创建ext4等其他文件系统。
 
如图1，Ceph集群实现了自己的文件系统来组织管理集群的存储空间，用户可以直接将Ceph集群的文件系统挂载到用户机上使用。
 
 
Ceph有了块设备接口，在块设备上完全可以构建一个文件系统，那么Ceph为什么还需要文件系统接口呢？
 
主要是因为应用场景的不同，Ceph的块设备具有优异的读写性能，但不能多处挂载同时读写，目前主要用在OpenStack上作为虚拟磁盘，而Ceph的文件系统接口读写性能较块设备接口差，但具有优异的共享性。
 
想了解更多？快去查查SAN和NAS。
 
一文看懂：NAS网络存储与SAN、DAS的区别
 
What is a SAN and how does it differ from NAS?
 
 
 
 
 
 
 
为什么Ceph的块设备接口不具有共享性，而Ceph的文件系统接口具有呢？
 
对于Ceph的块设备接口，如图2，文件系统的结构状态是维护在各用户机内存中的，假设Ceph块设备同时挂载到了用户机1和用户机2，当在用户机1上的文件系统中写入数据后，更新了用户机1的内存中文件系统状态，最终数据存储到了Ceph集群中，但是此时用户机2内存中的文件系统并不能得知底层Ceph集群数据已经变化而维持数据结构不变，因此用户无法从用户机2上读取用户机1上新写入的数据。
 
对于Ceph的文件系统接口，如图3，文件系统的结构状态是维护在远端Ceph集群中的，Ceph文件系统同时挂载到了用户机1和用户机2，当往用户机1的挂载点写入数据后，远端Ceph集群中的文件系统状态结构随之更新，当从用户机2的挂载点访问数据时会去远端Ceph集群取数据，由于远端Ceph集群已更新，所有用户机2能够获取最新的数据。
 
 
 
 
 
Ceph的文件系统接口使用方式？
 
将Ceph的文件系统挂载到用户机目录
 
 

 总结一下，Ceph的文件系统接口弥补了Ceph的块设备接口在共享性方面的不足，Ceph的文件系统接口符合POSIX标准，用户可以像使用本地存储目录一样使用Ceph的文件系统的挂载目录。还是不懂？这样理解吧，无需修改你的程序，就可以将程序的底层存储换成空间无限并可多处共享读写的Ceph集群文件系统。
 
 
 
三. Ceph的对象存储接口
 
首先，通过图4来看下对象存储接口是怎么用的？
 
简单了说，使用方式就是通过http协议上传下载删除对象（文件即对象）。
 
 
 
 
老问题来了，有了块设备接口存储和文件系统接口存储，为什么还整个对象存储呢?
 
往简单了说，Ceph的块设备存储具有优异的存储性能但不具有共享性，而Ceph的文件系统具有共享性然而性能较块设备存储差，为什么不权衡一下存储性能和共享性，整个具有共享性而存储性能好于文件系统存储的存储呢，对象存储就这样出现了。
 
对象存储为什么性能会比文件系统好？
 
原因是多方面的，主要原因是对象存储组织数据的方式相对简单，只有bucket和对象两个层次（对象存储在bucket中），对对象的操作也相对简单。而文件系统存储具有复杂的数据组织方式，目录和文件层次可具有无限深度，对目录和文件的操作也复杂的多，因此文件系统存储在维护文件系统的结构数据时会更加繁杂，从而导致文件系统的存储性能偏低。
 
Ceph的对象存储接口怎么用呢？
 
Ceph的对象接口符合亚马逊S3接口标准和OpenStack的Swift接口标准，可以自行学习这两种接口。
 
Amazon S3 简介
 
 
 
Openstack Swift 原理、架构与 API 介绍
 
 
 
 
 
 
 
总结一下，文件系统存储具有复杂的数据组织结构，能够提供给用户更加丰富的数据操作接口，而对象存储精简了数据组织结构，提供给用户有限的数据操作接口，以换取更好的存储性能。对象接口提供了REST API，非常适用于作为web应用的存储。
 
 
 
四. 总结
 
概括一下，块设备速度快，对存储的数据没有进行组织管理，但在大多数场景下，用户数据读写不方便（以块设备位置offset + 数据的length来记录数据位置，读写数据）。而在块设备上构建了文件系统后，文件系统帮助块设备组织管理数据，数据存储对用户更加友好（以文件名来读写数据）。Ceph文件系统接口解决了“Ceph块设备+本地文件系统”不支持多客户端共享读写的问题，但由于文件系统结构的复杂性导致了存储性能较Ceph块设备差。对象存储接口是一种折中，保证一定的存储性能，同时支持多客户端共享读写。
 
 
 
五、参考
 
 
 
理解Ceph的三种存储接口
 
 
 
虚拟座谈会：有关分布式存储的三个基本问题
 
 
 
玩转 Ceph 的正确姿势
 
作者：MissHandsome
 链接：https://www.jianshu.com/p/7656fe528488
 来源：简书
 简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。
 
 
 


  
 
 

从来没接触过对象存储的可能有点蒙，对象存储是啥，使用场景是啥，还有没有文件系统POSIX哪些接口？
 
公有云厂商对对象存储的定义
 
AWS S3
 
 
 
Amazon Simple Storage Service (Amazon S3) 是一种对象存储服务，提供行业领先的可扩展性、数据可用性、安全性和性能。这意味着各种规模和行业的客户都可以使用它来存储和保护各种用例（如网站、移动应用程序、备份和还原、存档、企业应用程序、IoT 设备和大数据分析）的任意数量的数据。
 AWS
 
 
腾讯云
 
 
 
对象存储（Cloud Object Storage，COS）是由腾讯云推出的无目录层次结构、无数据格式限制，可容纳海量数据且支持 HTTP/HTTPS 协议访问的分布式存储服务。
 COS
 
 
阿里云
 
 
 
对象存储服务（Object Storage Service，OSS）是一种海量、安全、低成本、高可靠的云存储服务，适合存放任意类型的文件。容量和处理能力弹性扩展，多种存储类型供选择，全面优化存储成本。
 OSS
 
 
七牛云
 
 
 
七牛云海量存储系统（KODO）是自主研发的非结构化数据存储管理平台，支持中心和边缘存储。平台经过多年大规模用户验证已跻身先进技术行列，并广泛应用于海量数据管理的各类场景。
 KODO
 
 
 
对象存储特点
 
对象存储是由AWS首先推出的一个存储产品形态，AWS的S3协议也成为对象存储事实标准，各个云存储厂商的云存储服务协议都兼容S3。从国内外这四个公有云厂商对象存储的描述，我们就能看出对象存储的几个特点：
 
海量数据，无论对文件大小，文件数量，都是海量
无文件系统的目录结构，采取的是平坦的层次结构
易扩展，相对低成本
 
具体更详细的描述呢，可以网上自我搜索。对象存储的特点，有没有一点更形象化的描述呢？下面白话文说下自己的理解：
 
海量存储
 
一般块存储来说（公有云形态为云盘）体量如果能达到PB级别，我们都觉得挺大了，但是对象存储的体量，PB就不够看了，至少都是EB的支持。国内公有云的对象存储体量基本上EB级别体量（旁白：PB不够看，EB是常态）。
 
层次结构
 
对象存储是完全不同于文件系统和块存储的存储形态。对外体现的层次概念是：桶（bucket），对象（key），没有目录结构。
 
那么有些小白可能迷惑了，我在腾讯云，阿里云，或者其他的S3客户端还是能看到对象以目录层次组织？
 
其实那个只是一个客户端的可视化显示而已，你的key名包含 “/” 的时候，有些会帮你显示成目录的样子，但这个跟对象存储本身无关（旁白：无目录，无目录，无目录）。也就是说，你存储对象存储使用的标识是（bucket，key），下载这个对象存储也只是使用：（bucket，key），除此之外，无其他标识。
 
易扩展，低成本
 
对象存储对外服务是可以宣称做到空间无限的，用户不用担心空间不够的问题，你有多少，我就能存多少（旁白：你有多少，我有多大）。
 
对象存储产品还可以细分成标准存储，归档存储，低频存储等。不同的产品适用于不同的场景，那么就允许使用特定的软硬件方案来限定成本。
 
比如归档存储，这种存储很有可能是写下去1年，都不读一次的，那么数据所在磁盘机器平时都可以直接下电的（旁白：其实这个说的简单，实现起来技术含量是很高的，国内应该还没有这种配合硬件的真正的归档存储，而只是产品上做个区分，抢占用户）
比如数据冗余除了多副本，可以使用纠删码等技术降低数据冗余度，从而保证相等可靠性的情况相对降低成本（旁白：纠删码是个好东西，我们也用这个）
 
接口协议
 
对象存储的事实协议标准是S3，是基于http之上的应用协议，核心接口极其简单（旁白：之前做块存储，刚接触这个，想“对象存储写偏移1M的位置写数据，怎么搞？” 后来发现根本就没有块存储对应的“改”的语义）。对象存储对外只提供两个抽象概念：桶，对象。这两个对象有哪些接口，下面列举最主要的几个：
 
桶（bucket）
 
CREATE：创建桶
LIST：列举桶
DELETE：删除桶
 
对象（object）
 
PUT：上传对象
GET：下载对象
DELETE：删除对象
 
 
对象存储使用场景
 
基本上互联网的产品服务都使用了对象存储； 
  
海量短视频：比如抖音，快手的音视频数据就非常适用于对象存储
静态网站，图床等
 
大数据，AI数据这些数据也非常适合对象存储
监控视频，海量日志，等归档数据，流式数据
国内公有云厂商一般还会添加附加价值，比如多媒体数据处理
 
 
后续会对对象存储的各种公共细节的理解，架构理解，前沿资讯，一些分享。
 
$坚持思考，方向比努力更重要。$
 关注公众号：奇伢云存储
 

MinIO创始者是Anand Babu Periasamy, Harshavardhana（戒日王）等人， Anand是GlusterFS的初始开发者、Gluster公司的创始人与CTO，Harshavardhana曾经是GlusterFS的开发人员，直到2011年红帽收购了Gluster公司。MinIO在设计上汲取了GlusterFS的相关经验与教训，系统复杂度上作了大量简化。
  
 
一、MinIO简介
 
01.概述
 
     MinIO对象存储系统是为海量数据存储、人工智能、大数据分析而设计，基于Apache License v2.0开源协议的对象存储系统，它完全兼容Amazon S3接口，单个对象最大可达5TB，适合存储海量图片、视频、日志文件、备份数据和容器/虚拟机镜像等。MinIO主要采用Golang语言实现，整个系统都运行在操作系统的用户态空间，客户端与存储服务器之间采用http/https通信协议。
 
02.设计哲学
 
     极简理念——采用尽可以简单可靠的集群管理方案，摒弃复杂的大规模集群调度管理，减少风险因素与性能瓶颈，聚焦产品的核心功能，打造高可靠的集群、灵活的扩展能力以及超高的性能；
 
    积木式扩展——建立众多的中小规模、易管理的集群，支持跨数据中心将多个集群聚合成超大资源池，而非直接采用大规模、统一管理的分布式集群。
 
03.设计原则
 
 
 
 
04.产品特点
 
 
 
 
05.高级特性
 
 
 
 
二、技术架构
 
01 数据组织结构
 
       NAS系统把整个存储资源组织为目录树的形式。与此不同，对象存储系统把存储资源组织为租户-桶-对象的形式。数据结构组织见下图：
 
 
对象：类似于hash表中的表项：它的名字相当于关键字，它的内容相当于“值”。
 
桶：是若干个对象的逻辑抽象，是盛装对象的容器。
 
租户：用于隔离存储资源。在租户之下可以建立桶、存储对象。
 
用户：在租户下面创建的用于访问不同桶的账号。可以使用MinIO提供的mc命令设置不用用户访问各个桶的权限。
 
 
 
02 数据分布与均衡
 
1 去中心化架构
 
    MinIO采用去中心化的无共享架构，对象数据被打散存放在不同节点的多块硬盘，对外提供统一命名空间访问，并通过Web负载均衡器或DNS轮询（DNS round-robin）在各服务器之间实现负载均衡。 
 
 
 
 
2 统一命名空间
 
      MinIO对象存储系统主要有两种部署方式，一种是常见的本地分布式集群部署，一种是联盟模式部署。本地分布式集群部署方式即在多个本地服务器节点部署MinIO软件，并将其组件成单套分布式存储集群，并提供统一命名空间和标准S3访问接口。联盟部署模式即将多个MinIO集群在逻辑上组成了统一命名空间，实现近乎无限的扩展与海量的数据规模管理，这些集群可以都在本地，或分布在不同地域的数据中心。
 
       如下图所示，4个服务器节点组成一个MinIO集群，每个服务器节点中会选择相同数据的硬盘创建一个纠删组，某个桶的数据会根据MinIO的分布式算法，切片分散存储到对应的纠删组中（详见纠删码相关内容）。
 
 
 
 
3 分布式锁管理
 
       与分布式数据库相类似，MinIO对象存储系统也面临数据一致性问题：一个客户端程序在读取一个对象的同时，另一个客户端程序可能正在修改或者删除这个对象。为了避免出现数据不一致情况，MinIO相关开发人员为MinIO对象存储专门设计并实现了dsync分布式锁管理器。它采用如下分布式锁管理机制：
 
l  任何一个节点的锁请求都会广播给集群内所有在线节点；
 
l  如果n/2 + 1个节点回应“是”，则成功获得锁；
 
l  客户端获得锁以后可保留任意时间，不需要时自己释放即可。释放操作也会广播给所有的节点，从而恢复锁的可用状态。写锁仅能被一个写入者获得。
 
 
 
设计目标
 
•要求设计简单，因为简单的设计，可以避免程序中很多非常棘手的条件分支的支持。
 
•不存在主节点，因为一旦在设计上引入主节点，那么如果主节点宕机，整个锁管理器机制即将失效，这对MinIO对象存储系统影响非常严重，是不可接受的。
 
•系统必须是弹性的，即使存在多个失效的节点，只要它们的个数小于n/2, 整个锁管理系统是可以正常工作的。
 
•完全可以替代Golang标准库中的sync.RWMutex互斥锁。这样可以简化MinIO对象存储系统的编程。
 
•当失效节点重启以后，其它节点重新连接。
 
 
 
不使用zookeeper/raft等技术的原因
 
       zookeeper/raft功能丰富，而MinIO对象储存的使用用例其实很有限。在MinIO中使用zookeeper/raft，会使整个系统增加不必要的复杂性。
 
 
 
优势
 
•实际操作极其简单，有效代码不足一千行，易理解，易维护。
 
•超高的性能。详细数据请参考文献[12]
 
 
 
4 云网关模式
 
       MinIO存储系统的后端可以是磁盘，也可以作为云网关，对接第三方的NAS系统、分布式文件系统或公有云存储资源，并为业务系统转换提供标准的对象访问接口。
 
     目前MinIO支持Google 云存储、HDFS、阿里巴巴OSS、亚马逊S3, 微软Azure Blob 存储等第三方存储资源。
 
 
 
 
03 元数据
 
1 架构
 
      MinIO对象存储系统无元数据数据库，所有的操作都是对象级别的粒度的。这种做法的优势是:
 
• 个别对象的失效，不会溢出为更大级别的系统失效。
 
•便于实现“强一致性”这个特性。此特性对于机器学习与大数据处理非常重要。
 
 
 
2 管理
 
      元数据与数据一起存放在磁盘上：数据部分纠删分片以后存储在磁盘上，元数据以明文形式存放在元数据文件里（xl.json）。假定对象名字为obj-with-metadata, 它所在的桶的名字是bucket_name,  disk是该对象所在纠删组的任一个磁盘的路径，如下目录：
 
disk/bucket_name/obj-with-metadata 
 
记录了这个对象在此磁盘上的信息。其中的内容如下：
 
 
 
 
      其中的xl.json即是此对象的元数据文件。part.1 即此对象的第一个数据分片。对象的元数据文件xl.json的内容是如下这种形式的json字符串：
 
 
字段说明
 
 
 
1 format字段
 
     该字段指明了这个对象的格式是xl。MinIO内部存储数据主要有两种数据格式:xl与fs。使用如下命令启动的MinIO使用的存储格式是fs:
 
 
 
 
       这种模式主要用于测试， 对象存储很多API都是并没有真正实现的桩函数。在生产环境所用的部署方式（本地分布式集群部署、联盟模式部署、云网关模式部署）中，存储格式都是xl。
 
 
 
2 stat字段
 
      记录了此对象的状态，包括大小与修改时间，如下图：
 
 
3 erasure字段
 
      这个字段记录此对象与纠删码有关的信息，如下图：
 
 
• 其中的algorithm指明了此对象采用的是Klaus Post实现的纠删码，生成矩阵是范德蒙矩阵。
 
• data，parity指明了纠删组中数据盘、校验盘的个数。
 
• blockSize 指明了对象被分块的大小，默认是5M（请参见上一节“数据分布与均衡”）。
 
•index指明了当前磁盘在纠删组中的序号。
 
• distribution:每个纠删组的数据盘、校验盘的个数是固定的，但是不同的对象的分片写入这个纠删组的不同磁盘的顺序是不同的。这里记录了分布顺序。
 
• checksum:它下面的字段个数跟此对象的分片数量有关。在旧版本的MinIO对象存储系统，每一个分片经过hash函数计算出的checksum会记录在元数据文件的这个位置。最新版的MinIO会把checksum直接计入分片文件（即part.1等文件）的前32个字节。
 
      此字段之下algorithm的值是”highwayhash256S”表明checksum值是写入分片文件的。
 
      
 
4 minio字段
 
       这个字段记录了存储此对象的minio的版本。
 
 
 
 
5 meta字段
 
 
      Content-type, etag两个字段是MinIO对象存储系统自动生成的。
 
      用户在使用Python等语言的写作的访问MinIO的程序中，如果上传对象时候指定了几个自定义属性，比如：
 
author属性值为Zhangsan
 
Nation属性值为Cn
 
Type属性值为love
 
那么对象元数据文件的meta字段就会出现如下几个子字段：
 
X-Amz-Meta-Author
 
X-Amz-Meta-Nation
 
X-Amz-Meta-Type
 
6 parts字段
 
       记录各个分片的信息：
 
 
 
 
04 集群扩展
 
1 扩展方式
 
       MinIO支持联盟部署模式，即将多个MinIO集群组成一个统一命名空间（一个ETCD集群，若干个CoreDNS服务）。其中ETCD集群相当于整个对象存储系统的配置数据库，很多重要的信息，如桶IP地址等存储于其中。这种模式的MinIO的架构如下图：
 
 
联盟模式多集群部署
 
 
 
       同样，MinIO在扩展时也采用相同机制，而不是传统分布式存储的添加节点方式。MinIO主要通过添加新的集群来扩大整个系统，可用空间大幅增加且仍然保持统一命名空间。通过这种方式，MinIO对象存储系统几乎可以无限的扩展总体性能和容量。
 
 
 
2 统一域名访问
 
    MinIO集群扩展加入新了集群或桶后，对象存储的客户端程序需要通过统一域名/url（如bucket1.domain.com）来访问数据对象，这个过程涉及到了CoreDNS系统。
 
 
CoreDNS实现单一域名/URL访问
 
 
 
MinIO对象存储的某个客户端（比如mc），首先向某个MinIO服务发送创建桶的请求。MinIO服务把这个桶所在的MinIO集群的外部网址（一般为一个Nginx的IP地址，或者MinIO集群的每一台服务器的IP地址）,写入到etcd集群中。
 
假定域名为domain.com,桶名为buc-1，集群的服务器IP地址为192.168.1.108、192.168.1.109，那么写入etcd集群的共有两条数据.第一条数据的key，value二元组为：
 
 
第二条数据的key，value二元组为：
 
 
CoreDNS通过etcd系统获知”bucket1.domain.com”这个url所对应的两个IP地址为192.168.1.108, 192.168.1.109。对象存储的客户端主机设置如上所配置的CoreDNS服务之后，客户端程序就可以通过域名”bucket1.domain.com”来找到访问这个桶。
 
 
 
3 优势特性
 
单一的、超大的命名空间需要花费大量的创建、维护与停机时间，复杂的部署管理，进而带来更严重的次生故障。MinIO的设计理念就是化整为零，简化集群扩展，减小单个集群的体量，轻量化单个集群的运维，从而使得超大规模的存储管理与维护变得更加容易。
 
• 集群的节点完全对等，没有主节点，多个节点可以并发提供对象访问服务;
 
• 创建桶的时候，可以指定数据中心/地域，以匹配对应的业务访问;
 
• 无论添加多少个集群,原有集群的性能几乎是不变的;
 
• 集群不会过大（32个节点），可实现可靠的分布式锁管理器，进而保证更新、删除等操作的强一致性。传统的架构允许集群扩容到数百上千节点，此情况下的强一致性容易产生性能问题;
 
• 故障的影响范围小，限制在单个集群内部。
 
 
 
05 纠删码
 
      在同一集群内，MinIO会自动生成若干纠删组，用于存放桶数据。一个纠删组中的一定数量的磁盘发生的故障（故障磁盘的数量小于等于校验盘的数量），通过纠删码算法可以恢复出正确的数据。MinIO集成了Reed-Solomon纠删码库，MinIO存储对象数据时，首先把它生成若干等长的片段（对于大对象，默认按5MB切片)，然后每一个片段会纠删算法分成若干分片，包括数据分片与校验分片，每个分片放置在一个纠删组的某个节点上。对象的每一个数据分片、校验分片都被“防比特位衰减”算法所保护。
 
 
 
 
 
 
对于一个对象，MinIO是如何定位它所在的纠删组呢？
 
     假定所有的纠删组都有一个序号（从0开始，直至纠删组个数减1）。MinIO会根据对象名（类似于文件系统的全路径名)，使用crc32哈希算法计算出一个整数。然后使用这个整数除以纠删组的个数，得到一个余数。这个余数，可以作为纠删组的序号，这样就确定了这个对象所在的纠删组。MinIO采用CRC32哈希算法，与GlusterFs的Davies-Meyer哈希算法（性能、冲突概率与md4, md5相近）不一样的是， CRC32算法的哈希值分布较不均匀，但运算速度极快，高出md4数倍。相对于容量均衡，MinIO更看重数据的写入速度。
 
 
 
06 数据修复
 
比特位衰减（Bitrot）是指存在存储介质中的数据发生了缓慢的变化，如向存储介质写入一段比特流，一段时间后再读出来，二者并不一致。比特位衰减的原因大致有：磁记录磨损、磁盘幻象写(phantom writes)、磁盘指向错误(misdirectedreads/writes)、宇宙射线的辐射等。MinIO对象存储系统从设计之初即考虑到修复静默错误，从被修复的目标来说，按照大小可以分为以下三种类型的修复：某个对象、某个桶、整个集群。
 
在控制台上执行mc命令即开始进行数据修复。该命令一方面向minio发送数据修复的HTTP请求，另一方面不断地接收minio服务进程返回的修复进度信息，而后输出到控制台，直到修复工作完毕。
 
如前文所述，每个对象都被分成多个分片，然后存储于多台主机的磁盘上。数据修复可以分为正常、深度两种模式，正常模式下只是简单地检查分片状态信息，深度模式下会使用hash算法来校验分片的内容，找出比特位错误，同时也更耗费资源。
 
MinIO具体修复流程如下：
 
• mc命令作为MinIO对象存储的客户端软件、管理工具，它内部链接了minio软件（代码网址：https://github.com/minio/minio/）的madmin软件模块，通过调用madmin中的修复函数，mc包装了mc命令的命令行参数，然后向minio服务进程发送HTTP消息。
 
 
 
•mc发送一个修复请求，在minio中被类healSequence所描述。每一个healSequence可以启动、停止、查询状态。minio服务程序收到新的任务的时候，会检查是否跟原有的healSequence有重叠的任务，如果有重叠，则启动的修复任务失败。如果minio服务没有发现错误，则使用深度优先搜索的算法，按照磁盘元数据信息、桶、对象的顺序，不断地给后台修复线程推送任务。
 
 
 
•minio后台修复线程修复对象的流程算法：对于对象的每一个block（默认大小为5M），从纠删组的各个主机读取各个分片，如果有错误的分片，就需要修复，有两种可能：校验分片错误——minio使用各个数据分片重新计算缺失的校验片。数据分片错误——使用纠删算法恢复数据（需要计算逆矩阵）。
 
 
 
 
 
07 lambda计算
 
       MinIO对象存储软件支持lambda计算通知机制，即桶中的对象支持事件通知机制。MinIO当前支持的事件类型有：对象上传、对象下载、对象删除、对象复制等。MinIO对象存储软件当前支持的事件接受系统有：Redis,NATS, AMQP, MQTT,Apache Kafka, MySql, PostgreSQL, Elasticsearch等。
 
       对象通知机制，极大地增强了MinIO对象存储的扩展性，可以让用户通过自行开发来实现某些MinIO对象存储不便实现的功能，比如基于元数据进行的各种检索、各种跟用户的业务有关的计算。既方便了用户，又有助于MinIO对象存储的生态建设。
 
       对象通知机制，使用极为简单，用户只需在MinIO进行少许配置即可。请参考文献[15]。
 
 
 
08 持续备份
 
     传统的复制的一大问题是不能有效地扩展，很难超过几百TB。在当今的时代，为了支持灾难恢复，任何单位都需要一个备份策略。而且这个备份策略需要跨越不同的地理位置、不同的数据中心、多种多样的云环境。
 
    MinIO的持续备份是为跨数据中心的大型部署而设计的。通过使用lambda计算通知机制，它可以快速、有效地计算处需要增量备份的内容，这远比传统的批处理模式优秀。持续备份使得未备份的数据尽可能的少，这意味着发生灾难或者严重错误时候，丢失的数据尽可能的少，很好地保护了用户的数据资产。
 
 
 
9 软件模块
 
     MinIO对象存储系统主要由以下软件模块部分组成：存储服务器软件minio，存储客户端软件mc，多种语言的客户端SDK。minio分为上下两层，上层负责minio的系统管理与对外接口，下层实现具体的逻辑。
 
 
 
1 cmd模块
 
  这是minio的上层，也就是源代码中的cmd子目录，参见： https://github.com/minio/minio/tree/master/cmd。这一部分主要负责minio的命令行参数解析、初始化系统、格式化磁盘、管理内嵌的web服务器、S3 API的解析与逻辑处理。
 
 
 
2 各个软件包
 
     这个是minio底层逻辑实现，也就是源代码目录中的pkg子目录。其中一些软件包（比如madmin）, 可被其它组织（或个人）在编写辅助minio的软件的时候所重复使用。
 
• madmin：使用这个软件包可以自己使用Golang语言撰写MinIO集群的管理程序，比如获取服务的状态（磁盘、cpu等信息）、重启某个机器服务、启动修复某个桶的任务、重新配置系统、获取剖析信息等等。
 
• S3 select：如果对象存储系统中有很多超大型的对象，比如大小是几个GB甚至几个TB的对象。如果应用程序（比如spark分析程序），要把符合条件的若干个对象都读过去，然后再做分析，会及其的慢，浪费很多带宽(毕竟对象中可能只有很少的一部分是对某个分析程序有用的)。因此Amazon引入了S3 Select 的功能。通俗地说，就是把select 类型的sql语句在某个对象上执行，从对象中取出一部分内容返回给应用。MinIO提供了S3 Select 功能。相对于S3 Select, MinIO要求对象的内容必须是CSV、 JSON,或者 Parquet格式。S3Select API实现中使用的语法分析器是 Alec Thomas写的如下项目：
 
https://github.com/alecthomas/participle
 
这个实现的分析算法是带有栈的ll(k)分析算法。
 
 
 
三 性能测试
 
     MinIO已经为高性能做过高度优化，尤其是部分关键的算法已经使用SIMD指令对Intel(AVX2/AVX512)、Arm(NEON)的cpu做过特殊优化，主要包括：
 
1) 纠删码部分用到的伽罗瓦域的运算：加法、乘法、乘方等等；
 
2) 监测比特位衰减(bitrot)的哈希函数,如HighwayHash。
 
另外每一个MinIO集群都是无中心的，其中的每一个节点都是对等的，从而在性能上，不会存在单点瓶颈，也不会有单点故障。
 
    如下的硬件配置之下：Intel Skylake CPU, NVMe磁盘，以及Mellanox CX5 dual 100-GbE网卡。下图是MinIO inc的测试结果：
 
 
 
 
四 设计讨论
 
为什么MinIO单集群不支持扩展？
 
•传统的扩展方式的劣势
 
     通过增加节点来扩展单集群，一般需要进行数据均衡，否则群集内各存储节点会因负载不均而出现新的瓶颈。除了数据均衡操作的时机这个问题以外，在均衡过程中一般需要从存储使用率高的节点向使用率低的节点迁移数据。当集群扩容之后，大量已经写入的文件落点会出现改变，文件需要迁移到真实的落点。当存储系统容量比较大时，则会发生大量的文件/对象进行迁移,迁移过程可能由于占用大量资源而导致上层应用性能下降。而且当文件/对象迁移过程中，机器故障可能会导致一些意想不到的情况,尤其是有大量业务的时候。当然针对此类问题，Gluterfs之类的文件系统有一些比较复杂的处理办法。
 
 
 
•使用场景
 
      人工智能、大数据分析、视频监控等典型使用场景中，对象存储系统中存储的数据往往写入以后一般不再修改。如果现有MinIO集群存储空间使用完毕，重新添加新集群，然后继续写入新集群即可。MinIO对象存储的客户端应用，从业务层面自行决定那些对象存在于哪个集群里面，使用起来并不麻烦。
 
    单集群不可扩展，也就是说系统不需要处理扩展和数据均衡，不仅有效降低系统复杂性，而且可以使得系统部署规划具有很好的可预测性。
 
   对于海量对象存储应用场景，数据通常具有典型的生命周期特征，根据实际需求设计好单集群规模，按联合方式扩展，整个系统具有非常好的可维护性。
 
 
 
•MinIO方案的优势
 
     不支持对单个集群进行扩展，MinIO对象存储系统的这种设计，使得系统的很多模块更加简单（比如从一个对象转换到它所在的纠删组，只用简单的哈希即可。）降低了整个系统出错的概率，使得MinIO对象存储系统更加可靠、稳定。
 
详细的讨论参见文献[14]
 
 
 
MinIO是否有类似于GlusterFs 的translator类机制？
 
    没有，GlusterFs是使用c语言实现的，而c语言是比较低级的语言，本身没有模块机制。Golang语言自身有强大的模块机制，所以也就不需要类似于translator之类的机制。
 
 
 
MinIO的纠删码机制，为何没有采用柯西矩阵？
 
 
 
    就Reed-Solomon纠删码的生成矩阵来说，Klaus的纠删码库里面可以选择柯西生成矩阵。不过当前MinIO软件使用的仍然是范德蒙矩阵的Reed-Solomon纠删算法。这是因为:虽然柯西矩阵的生成相比范德蒙矩阵更快，不过MinIO编码矩阵的生成是只进行一次的操作（程序运行中，生成的这个矩阵会被保存起来）。使用柯西矩阵对数据的吞吐量并没有什么影响。
 
 
 
五 对象存储产品选型讨论
 
      开源对象存储软件以MinIO,Ceph为典型代表。为帮助相关人员在选择对象存储系统之时选择合适的产品，此处对二者的特点、特性做一定讨论。
 
01 MinIO优势
 
1 部署极其简单
 
     MinIO系统的服务程序仅有minio一个可执行文件，基本不依赖其它共享库或者rpm/apt包。minio的配置项很少（大部分都是内核之类系统级的设置），甚至不配置也可以正常运行起来。百度、google、bing等搜索引擎上基本没有关于MinIO部署问题的网页，可见在实践中，很少有使用者遇到这方面的问题。
 
      相比之下，Ceph系统的模块，相关的rpm、apt包众多，配置项非常多，难以部署，难调优。某些Linux发行版的Ceph安装包甚至有bug，需要使用者手动改动Ceph的python脚本，才能安装完毕。
 
 
 
2 二次开发容易
 
     MinIO对象存储系统除了极少数代码使用汇编实现以外，全部使用Golang语言实现。Ceph系统是使用业界闻名的难学难用的c++语言编写的。Golang语言由于产生较晚，吸收了很多语言尤其是c++的教训，语言特性比较现代化。相对而言，MinIO系统的维护、二次开发比较容易。
 
 
 
3 网管模式支持多种其他存储
 
     通过网关模式，MinIO对象存储后端，可以对接各种现有的常见其它存储类型，比如的NAS系统，微软Azure Blob 存储、Google 云存储、HDFS、阿里巴巴OSS、亚马逊S3等，非常有利于企业复用现有资源，有利于企业低成本（硬件成本约等于零，部署MinIO对象存储软件即可）地从现有系统平滑升级到对象存储。
 
 
 
02 Ceph优势 
 
•数据冗余策略更加丰富
 
     Ceph同时支持副本、纠删码，而MinIO只支持纠删码。对于个别的对于数据可靠性要求极高的单位，Ceph对象存储更加合适。
 
•社区目前更成熟
 
 
 
03 其他对比
 
1 厂商支持
 
     国内使用Ceph的厂商、基于Ceph进行自研的存储厂商都比较多，在使用过程中遇到的问题（有些时候，甚至需要修改、增强乃至重新实现Ceph本身的功能），可以向相关厂商寻求支持。国际方面，Ceph早已被红帽收购，而红帽近期又被IBM收购。
 
    MinIO开发与支持的厂商只有MinIO公司。由于架构比较先进，语言高级，MinIO本身的程序比较容易读懂、修改。招聘Golang程序员来 维护MinIO所花费的成本，显然低于招聘c++程序员来维护Ceph。 
 
 
 
2 多语言客户端SDK
 
    二者均有常见编程语言的客户端，比如：python, java等。MinIO对象存储软件的开发SDK另外支持纯函数式的语言Haskell。
 
 
 
3 技术文档  
 
     内部实现的文档MinIO基本不存在。想要了解内部实现乃至参与开发的技术人员，只能到如下社区：
 
http://minio.slack.com/ ，与MinIO的开发人员直接交流，或者自己阅读代码。Ceph的各种实现文档、算法说明文档非常丰富。这方面Ceph要比MinIO成熟很多。
 
 
 
04 结论
 
    由以上讨论，可见作为对象存储软件来说，MinIO， Ceph都非常优秀，各自有各自的优势。准备使用对象存储软件的用户，应该根据自己单位的需求、技术储备等实际情况，选择适当的软件。
 
 
 
六 参考硬件
 
 
 
     MinIO是符合软件定义存储SDS理念的，兼容主流X86服务器以及ARM/飞腾平台，同时也可以移植到诸如申威（Alpha架构）和龙芯（Mips架构）等硬件平台。
 
    下面这些符合工业标准的、广泛采用的服务器是经过MinIO inc.优化测试过的、MinIO对象存储软件表现优异的服务器：
 
 
 
 
参考文献
 
1https://github.com/krishnasrinivas/wikinotes/wiki/minio-scaling
 
2https://docs.aws.amazon.com/zh_cn/AmazonS3/latest/dev/Welcome.html
 
3Klaus Post官网：https://klauspost.com/
 
4https://github.com/klauspost/reedsolomon 
 
5https://developer.ibm.com/articles/cl-cloudstorage/
 
6https://github.com/minio/dsync
 
7https://github.com/minio/dsync/pull/22#issue-176751755
 
8https://github.com/minio/minio/blob/master/cmd/xl-sets.go 
 
9https://min.io/resources/docs/MinIO-throughput-benchmarks-on-NVMe-SSD.pdf 
 
10https://github.com/minio/minio/blob/master/cmd/admin-heal-ops.go
 
11https://github.com/klauspost/reedsolomon/blob/master/options.go
 
12https://github.com/minio/dsync
 
13https://min.io/resources/docs/CPG-MinIO-implementation-guide.pdf 
 
14https://github.com/minio/minio/issues/7986
 
15https://docs.min.io/docs/minio-bucket-notification-guide.html
 
（TaoCloud团队原创　《MinIO技术白皮书》微信公众号版）

前两篇介绍了对象存储的基础，包括存储类型，常用存储分类和分类方法。
 
SCSI,TCP/IP,FC等存储介质以及DAS\NAS\SAN等存储网络，请参考：对象存储1：传统存储类型和分类。
 
文件存储，块存储以及对象存储等数据存储格式，请参考： 对象存储2：云平台数据存储类型。
 
 
 
1.对象存储基础
 
对象存储的命名，是由其存储数据的格式来的，它的数据是以对象object的形式存储。
 
文件存储的数据存储单位为文件；块存储的数据存储单位为数据块；块存储的存储单位为对象。
 
1.1 数据格式
 
一个文件包含了两部分内容，属性和内容（即数据）；属性又称元数据metadata，是指数据的属性内容，比如文件大小、创建时间、修改时间、存储路径等。
 
像FAT32文件系统，是直接将一份文件的数据与metadata一起存储的。存储过程先将文件按照文件系统的最小块大小来打散（如4M的文件，假如文件系统要求一个块4K，那么就将文件打散成为1000个小块），再写进硬盘里面，过程中没有区分数据/metadata的。每个块最后会告知你下一个要读取的块的地址，然后一直这样顺序地按图索骥，最后完成整份文件的所有块的读取。所以无论系统性能多么强，都只能按顺序一个块一个块的读取，只有读完前一个块，才能开始读取下一个块。读写效率就成了最大的瓶颈。
 

 
 


 
 

 
 
 
 
1.2 对象存储原理
 
对象存储将元数据独立了出来，元数据里写明了数据的所有属性，包括打散后的每个块所存储的位置。对象存储将元数据和数据进行了分开存储，这样只要读取到了元数据，就能找到所有的数据块，并可以同时对数据块进行读取，大大提高了数据处理的效率。
 
对象存储中用来存储元数据的节点是控制节点，称为元数据服务器（服务器+对象存储管理软件），里面主要负责存储对象的属性（主要是对象的数据被打散存放到了那几台分布式服务器中的信息）；负责存储数据的分布式服务器叫做OSD，主要负责存储文件的数据部分。当用户访问对象，会先访问元数据服务器，元数据服务器只负责反馈对象存储在哪些OSD，假设反馈文件A存储在B、C、D三台OSD，那么用户就会再次直接访问3台OSD服务器去读取数据。这时候由于是3台OSD同时对外传输数据，所以传输的速度就加快了。当OSD服务器数量越多，这种读写速度的提升就越大，通过此种方式，实现了读写快的目的。
 
另一方面，对象存储软件是有专门的文件系统的，所以OSD对外又相当于文件服务器，那么就不存在文件共享方面的困难了，也解决了文件共享方面的问题。
 
1.3 对象
 
对象是系统中数据存储的基本单位，一个对象实际上就是文件的数据和一组属性信息（Meta Data）的组合，这些属性信息可以定义基于文件的RAID参数、数据分布和服务质量等，而传统的存储系统中用文件或块作为基本的存储单位，在块存储系统中还需要始终追踪系统中每个块的属性，对象通过与存储系统通信维护自己的属性。在存储设备中，所有对象都有一个对象标识，通过对象标识OSD命令访问该对象。通常有多种类型的对象，存储设备上的根对象标识存储设备和该设备的各种属性，组对象是存储设备上共享资源管理策略的对象集合等。
 

 
 

 
 
2.对象存储的结构
 
根据对象存储原理所讲的，核心是将数据通路（数据读或写）和控制通路（元数据）分离，并且基于对象存储设备（Object-based Storage Device，OSD）构建存储系统。每个对象存储设备具有一定的智能，能够自动管理其上的数据分布。对象存储的结构包括元数据服务器（控制节点MDS）和数据存储服务器（OSD），两者进行数据的存储，还需要客服端client进行存储的服务访问和使用。架构如下图：
 

 
 

 
 
2.1 对象存储设备OSD
 
对象存储设备是对象存储的核心设备，具有一定的智能，它有自己的CPU、内存、网络和磁盘系统，OSD同块设备的不同不在于存储介质，而在于两者提供的访问接口。OSD的主要功能包括数据存储和安全访问。目前国际上通常采用刀片式结构实现对象存储设备。OSD提供三个主要功能：
 （1） 数据存储。OSD管理对象数据，并将它们放置在标准的磁盘系统上，OSD不提供块接口访问方式，Client请求数据时用对象ID、偏移进行数据读写。
 （2） 智能分布。OSD用其自身的CPU和内存优化数据分布，并支持数据的预取。由于OSD可以智能地支持对象的预取，从而可以优化磁盘的性能。
 （3） 每个对象元数据的管理。OSD管理存储在其上对象的元数据，该元数据与传统的inode元数据相似，通常包括对象的数据块和对象的长度。而在传统的NAS系统中，这些元数据是由文件服务器维护的，对象存储架构将系统中主要的元数据管理工作由OSD来完成，降低了Client的开销。
 

 2.2 元数据服务器（Metadata Server，MDS）
 
MDS控制Client与OSD对象的交互，主要提供以下几个功能：
 （1） 对象存储访问。
 MDS构造、管理描述每个文件分布的视图，允许Client直接访问对象。MDS为Client提供访问该文件所含对象的能力，OSD在接收到每个请求时将先验证该能力，然后才可以访问。
 （2） 文件和目录访问管理。
 MDS在存储系统上构建一个文件结构，包括限额控制、目录和文件的创建和删除、访问控制等。
 （3） Client Cache一致性。
 为了提高Client性能，在对象存储系统设计时通常支持Client方的Cache。由于引入Client方的Cache，带来了Cache一致性问题，MDS支持基于Client的文件Cache，当Cache的文件发生改变时，将通知Client刷新Cache，从而防止Cache不一致引发的问题。
 
2.3 对象存储系统的客户端Client
 
为了有效支持Client支持访问OSD上的对象，需要在计算节点实现对象存储系统的Client，通常提供POSIX文件系统接口，允许应用程序像执行标准的文件系统操作一样。
  
 
3. 对象存储文件系统的关键技术：
 
3.1 分布元数据
 
传统的存储结构元数据服务器通常提供两个主要功能。

 （1）为计算结点提供一个存储数据的逻辑视图（Virtual File System，VFS层），文件名列表及目录结构。

 （2）组织物理存储介质的数据分布（inode层）。对象存储结构将存储数据的逻辑视图与物理视图分开，并将负载分布，避免元数据服务器引起的瓶颈（如NAS系统）。元数据的VFS部分通常是元数据服务器的10％的负载，剩下的90％工作（inode部分）是在存储介质块的数据物理分布上完成的。在对象存储结构，inode工作分布到每个智能化的OSD，每个OSD负责管理数据分布和检索，这样90%的元数据管理工作分布到智能的存储设备，从而提高了系统元数据管理的性能。另外，分布的元数据管理，在增加更多的OSD到系统中时，可以同时增加元数据的性能和系统存储容量。
 
3.2 并发数据访问
 
对象存储体系结构定义了一个新的、更加智能化的磁盘接口OSD。OSD是与网络连接的设备，它自身包含存储介质，如磁盘或磁带，并具有足够的智能可以管理本地存储的数据。计算结点直接与OSD通信，访问它存储的数据，由于OSD具有智能，因此不需要文件服务器的介入。如果将文件系统的数据分布在多个OSD上，则聚合I/O速率和数据吞吐率将线性增长，对绝大多数Linux集群应用来说，持续的I/O聚合带宽和吞吐率对较多数目的计算结点是非常重要的。对象存储结构提供的性能是目前其它存储结构难以达到的，如ActiveScale对象存储文件系统的带宽可以达到10GB/s。
  
 
 
 
 
 
 
 
3.对象存储常用场景