分布式存储

一、Ceph简介： Ceph是一种为优秀的性能、可靠性和可扩展性而设计的统一的、分布式文件系统。ceph 的统一体现在可以提供文件系统、块存储和对象存储，分布式体现在可以动态扩展。在国内一些公司的云环境中，通常会采用 ceph 作为openstack 的唯一后端存储来提高数据转发效率。 Ceph项目最早起源于Sage就读博士期间的工作（最早的成果于2004年发表），并随后贡献给开源社区。在经过了数年的发展之后，目前已得到众多云计算厂商的支持并被广泛应用。RedHat及OpenStack都可与Ceph整合以支持虚拟机镜像的后端存储。 官网：https://ceph.com/ 官方文档：http://docs.ceph.com/docs/master/# 二、Ceph特点： 高性能： a. 摒弃了传统的集中式存储元数据寻址的方案，采用CRUSH算法，数据分布均衡， 并行度高。 b.考虑了容灾域的隔离，能够实现各类负载的副本放置规则，例如跨机房、机架 感知等。 c. 能够支持上千个存储节点的规模，支持TB到PB级的数据。 高可用性： a. 副本数可以灵活控制。 b. 支持故障域分隔，数据强一致性。 c. 多种故障场景自动进行修复自愈。 d. 没有单点故障，自动管理。 高可扩展性： a. 去中心化。 b. 扩展灵活。 c. 随着节点增加而线性增长。 特性丰富： a. 支持三种存储接口

一、基本简介 镜像服务（glance）使用户能够发现，注册和检索虚拟机镜像。 它提供了一个REST API，使您可以查询虚拟机镜像元数据并检索实际镜像。 您可以将通过镜像服务提供的虚拟机映像存储在各种位置，从简单的文件系统到对象存储系统（如OpenStack对象存储）。   为了简单起见，本指南描述了将Image服务配置为使用文件后端，该后端上载并存储在托管Image服务的控制节点上的目录中。 OpenStack Image服务是基础架构即服务（IaaS）的核心。 它接受磁盘或服务器映像的API请求，以及来自最终用户或OpenStack Compute组件的元数据定义。 它还支持在各种存储库类型（包括OpenStack对象存储）上存储磁盘或服务器映像。 OpenStack镜像服务包括以下组件： glance-api 接受镜像API调用以进行镜像发现，检索和存储。 glance-registry 存储，处理和检索有关镜像的元数据。 元数据包括例如大小和类型等项目。 Database 存储镜像元数据，您可以根据自己的喜好选择数据库。 大多数部署使用MySQL或SQLite。 Storage repository for image files（镜像文件的存储库） 支持各种存储库类型，包括常规文件系统（或安装在glance-api控制节点上的任何文件系统），Object Storage

HDFS Hadoop的核心就是HDFS与MapReduce。那么HDFS又是基于GFS的设计理念搞出来的。 HDFS全称是Hadoop Distributed System。HDFS是为以流的方式存取大文件而设计的。适用于几百MB，GB以及TB，并写一次读多次的场合。而对于低延时数据访问、大量小文件、同时写和任意的文件修改，则并不是十分适合。 优点： 1）适合存储非常大的文件 2）适合流式数据读取，即适合“只写一次，读多次”的数据处理模式 3）适合部署在廉价的机器上 缺点： 1）不适合存储大量的小文件，因为受Namenode内存大小限制 2）不适合实时数据读取，高吞吐量和实时性是相悖的，HDFS选择前者 3）不适合需要经常修改数据的场景 数据块： 每个磁盘都有默认的数据块大小，一般就是521字节。这是磁盘进行数据读写的最小单位。HDFS同样也有块（block）的概念，但是大得多，有64MB。与单一磁盘上的文件系统一样，HDFS上的文件也被划分为块大小的多个分块。但是还是有所不同，比如HDFS中小于一个块大小的文件不会占据整个块的空间。 对分布式文件系统中的快进行抽象的好处： 1）一个文件的大小可能会大于网络中任意一个磁盘的容量，文件的所有块并不需要存储在同一个磁盘上，因此可以利用集群上的任意一个磁盘进行存储，但是对于HDFS来说，它是存储了一个文件。 （这不就正是我们要的效果吗）

分布式文件系统 分布式文件系统：当数据集的大小超过一台独立物理计算机的存储能力时，就有必要对它进行分区（partition）并存储到若干台单独的计算机上。管理网络中夸多台计算机存储的文件系统。这种系统构架于网络之上，肯定会引入网络编程的复杂性，因此它比普通的磁盘文件系统更为复杂。 我们首先来简单的说明一下这个分布式，我们都知道现在要存储的数据量越来越大，但是一台电脑的存储能力是有限的，尽管我们可以通过提高某台电脑的存储能力来解决这个问题，但是这是无法根本解决这个问题，所以我们通过很多很多台廉价的电脑来分布式存储这些数据。简单说就是把要存的文件分割成一份一份存到许多台电脑上。 Google File System： 是由google开发并设计的一个面向大规模数据处理的一个分布式文件系统。 为了满足Google迅速增长的数据处理需求，Google设计并实现了Google文件系统。它是有几百甚至几千台普通的廉价设备组装的存储机器。以下是一些设计思路。 1）我们知道有这么多机器，那么这些设备中的某些机器出现故障是很常见的事情，所以在GFS要集成持续的监控、错误侦测、灾难冗 余以及自动恢复的机制。 2）我们要存的数据大小是很大，所以要是按照以往的存储文件块大小，那么就要管理数亿个KB大小的小文件，这是很不合理的，所以在这个系统里面他们定义一个文件块的大小是64M。 3

HDFS Hadoop的核心就是HDFS与MapReduce。那么HDFS又是基于GFS的设计理念搞出来的。 HDFS全称是Hadoop Distributed System。HDFS是为以流的方式存取大文件而设计的。适用于几百MB，GB以及TB，并写一次读多次的场合。而对于低延时数据访问、大量小文件、同时写和任意的文件修改，则并不是十分适合。 优点： 1）适合存储非常大的文件 2）适合流式数据读取，即适合“只写一次，读多次”的数据处理模式 3）适合部署在廉价的机器上 缺点： 1）不适合存储大量的小文件，因为受Namenode内存大小限制 2）不适合实时数据读取，高吞吐量和实时性是相悖的，HDFS选择前者 3）不适合需要经常修改数据的场景 数据块： 每个磁盘都有默认的数据块大小，一般就是521字节。这是磁盘进行数据读写的最小单位。HDFS同样也有块（block）的概念，但是大得多，有64MB。与单一磁盘上的文件系统一样，HDFS上的文件也被划分为块大小的多个分块。但是还是有所不同，比如HDFS中小于一个块大小的文件不会占据整个块的空间。 对分布式文件系统中的快进行抽象的好处： 1）一个文件的大小可能会大于网络中任意一个磁盘的容量，文件的所有块并不需要存储在同一个磁盘上，因此可以利用集群上的任意一个磁盘进行存储，但是对于HDFS来说，它是存储了一个文件。 （这不就正是我们要的效果吗）

最近工作需要接触一些Raft 相关的东西，下面简单整理几点： Raft内部相关接口 有自己的事物日志管理接口：支持append/get/ truncate 等操作； 有独立的日志同步模块：Replicator 逐一回探确定从和主日志开始分叉的位置，然后从主上拉取Follower 节点缺少的日志条目，同步给Follower，通常这是独立的线程做的事情； Raft内部可能有Cache功能，只有当待写的日志条目内容超过一定长度的时候，再会真正下发落盘； 同步日志的时候，Raft内部会检查index ID是否和目的节点的相匹配：预期应该保证 follower当前的index id + 1 和append过来的 LOG index ID 相等； 复制组创建流程 1.主控节点随机找一个存储节点创建一个复制组的副本； 2.成功之后检查复制组成员（副本）的数量是否达到复制组约定的成员的数量； 3.如果没有达到，主控节点继续 随机找一个存储节点创建一个复制组成员；如果有达到，到步骤 1 （向主控节点 返回成功） 如果上面节点副本创建成功，向主控节点返回副本创建成功，主控节点接着向第一个副本发添加复制组成员的请求, 以便把新创建的副本添加到复制组； 继续步骤2 常见问题 解析事物日志失败 向复制组添加成员失败 复制组的 Leader 里有Follower, 但是Follower