分布式存储系统的一些理解和实践

《分布式存储系统的一些理解和实践》由会员分享，可在线阅读，更多相关《分布式存储系统的一些理解和实践（14页珍藏版）》请在装配图网上搜索。

1、分布式存储系统的一些理解和实践张建伟一、 分布式存储系统介绍1. 简介互联网数据规模越来越大，并发请求越来越高，传统的关系数据库，在很多使用场景下并不 能很好的满足需求。分布式存储系统应运而生。它有良好的扩展性，弱化关系数据模型，甚 至弱化一致性要求，以得到高并发和高性能。按功能分类，主要有以下几种：分布式文件系统hdfs ceph glusterfs tfs 分布式对象存储s3(dynamo) ceph bcs(mola) 分布式表格存储hbase cassandra oceanbase 块存储ceph ebs(amazon)分布式存储系统，包括分布式系统和单机存储两部分；不同的系统，虽在功

2、能支持、实现机 制、实现语言等方面是有差异的，但其设计时，关注的关键问题是基本相同的。单机存储的 主流实现方式，有hash引擎、B+树引擎和LSM树(Log Structured Merge Tree三种，不展开 介绍。本文第二章节，主要结合hbase、cassandra和ceph，讲下分布式系统设计部分，需要 关注的关键问题。2. 适用场景各分布式存储系统功能定位不尽相同，但其适用和不适用的场景，在一定程度上是相同的， 如下。1）适用大数据量（大于100T,乃至几十PB）key/value 或者半结构化数据高吞吐高性能高扩展2）不适用Sql 查询复杂查询,如联表查询复杂事务二、 分布式存储系

3、统设计要点1. 数据分布分布式存储,可以由成千甚至上万台机器组成,以实现海量数据存储和高并发。那它最先要 解决的就是数据分布问题，即哪些数据存储在哪些机器（节点）上。常用的有hash类算法 和用meta表映射两种方式。一般完全分布式的设计（无master节点），会用hash类算法； 而集中式的设计（有master节点）用meta表映射的方式。两者各有优缺点，后面讲到具体 问题时再做比较。1） 一致性 hash将存储节点和操作的key （key唯一标识存储的object，有时也叫object name）都hash到02 的32次方区间。映射到如下环中的某个位置。沿操作key的位置顺时针找到的第一

4、个节点 即为此 key 的 primary 存储节点。如下图所示：nodelI计篡帖出node2Uil十算 lyhrwd4计算hash计算ha曲计諄hashf :X 呼艸IJ图 1 一致性 hashCassandra 借鉴了 dynamo 的实现，用了一致性 hash 的方式。节点的 hash 值(也叫 token)， 可以手动分配或者自动生成。Key的hash值即md5(key)。每个表可以在建表时指定副本数, 当副本数为 3 时，找 primary 存储节点后，顺时针方向的下 2 个存储节点即为 replica 存储节 点。Hash类算法，优点是无需master节点，一个缺点是，不支持ke

5、y的顺序扫描。2) Crush 算法也是一种类hash算法，随着ceph诞生，也是ceph的一大亮点。Crush算法比较复杂，这里 简化介绍下。Ceph的每个Object最终都会映射到一组OSD中，由这组OSD保存这个Object，映射流程 如下：Object PG OSD set OSD先理解为机器节点吧 PG即Placement Groups，可以理解为存储在同一组OSD上的object的集合Object先映射到PG(Placement Group)，再由PG映射到OSD set。每个表空间有固定数量的 pg,在建表时指定。每个Object通过计算hash值并对pg数量取模得到它所对应的P

6、G。PG 再映射到一组OSD(OSD的个数由表的副本数决定，也是建表时指定)，第一个OSD是 Primary，剩下的都是 Replicas。PG 一 OSD set的映射由几个因素决定： CRUSH hash算法：一种伪随机算法。 OSD MAP:包含当前所有OSD的状态、OSD的机器机架信息等。 CRUSH Rules :数据映射的策略。这些策略可以灵活的设置object存放的区域。比 如可以指定tablel中所有objects放置在机架1上，所有objects的第1个副本放置在 机架1上的服务器A 上,第2个副本分布在机架1上的服务器B上。table2中所有 的object分布在机架2、3

7、、4上，所有Object的第1个副本分布在机架2的服务器 上，第2个副本分布在机架3的服器上，第3个副本分布在机架4的服务器上。具 体实现不再展开。FileObjectsPGs(inOj on o) oidhash(oid) & maskpgid(grouped by failure domain)图 2 ceph crush 算法伪代码如下所示：locator = object_name obj_hash = hash(locator) pg = obj_hash % num_pg osds_for_pg = crush(pg) # returns a list of osds primar

8、y = osds_for_pg0 replicas = osds_for_pg1:Crush相比一致性hash更加灵活。3) 按 range 查表 由master节点记录和管理每个表range的粒度，以及每个range的数据存储在哪些节点上。 range是根据key的字节序确定。Client在执行key存取操作是，先到master,根据其所在range, 查询其存储在哪些节点；再直接跟存储节点交互，实现存取。Hbase 是用这种方式实现，支持 key 的顺序扫描。如下图所示，region即一段range的数据（存储在mater server上），region sever即实际存储 节点。Reg

9、ion StrvfiF?gionTabledRegionlegionTabrelRegionRegkin图 3 hbase region 映射2. 数据可靠性数据可靠性，即数据不丢失，是存储系统的第一职责。图 4 数据中心分布式一般采用普通服务器，要假设服务器和硬盘都是不可靠的。如何保证在有硬件损坏时 数据不丢失，是任何分布式存储系统都必须考虑的。已有做法有以下几种。1) 多副本即数据保存N+1份(一般是3份)，每一份都存储在不同的节点上。在数据损坏N份时，仍 能修复数据。缺点是，需N倍的冗余存储空间。hbase、cassandra、ceph 都很好的支持。2) 纠删码即将一条数据切分成n等份

10、，通过对这n份数据编码，得到m份相等大小的校验数据块儿。 这n+m份数据，各自存储在不同的节点上，拿到n+m中的任意n份数据，均可计算得到原 始的数据。一般n取10，m取3。优点是，只需m/n倍的冗余空间，缺点是读写效率较低, 且耗费 cpu。图 5 纠删码 Hbase： hdfs层为hbase提供支持。 Cassandra :社区版本不支持，社区还无添加此功能的路线图，之前社区有讨论过此功 能，后来不了了之。应该是主要考虑到纠删码方式对现有系统的存储结构、一致性语义 都有较大影响，且性能较低。 Ceph :支持。但在功能上有些缺失，比如不支持partial read，适合读远多于写的场景，

11、应用较少。3) 跨级群自动备份一般为了更高的可靠性，数据会通过准实时备份机制，备份到另外一个IDC的存储集群。 Hbase:社区版本已经支持。 cassandra和ceph：都不支持，短期没有路线图，长远来讲，是需要添加的。4) 接入修复客户端写数据到存储集群，一般先按一定规则找到一个接入节点，再由次接入节点做proxy 将数据写到实际存储的节点。假设需要写入3副本，如果接入节点发现，有的副本对应的存 储节点此时不可用，或者写超时，那么会将写失败的节点及未写成功的数据存储下来。之后， 定时或者收到通知不可用节点变为可用时，尝试写入之前未写成功的数据。 Hbase： hdfs层会保证写入足够的副

12、本，因为hdfs的namenode记录了每个block的meta 数据(block存储在哪些datanode), 一个datanode写失败，换一个写，直至写成功。可 以看到，记录meta这种方式很灵活 Cassandra:有 hinthandoff 机制，原理如上 Ceph:有pglog机制，原理如上5) 全局扫描修复用以修复磁盘损坏、误删文件等原因引起的数据丢失。由master节点发起全局数据，或者 primary 节点发起自己负责的 range 的数据，的多个副本间的数据扫描。如果发现某个副本 缺失，则进行修复。 Hbase、 cassandra、 ceph 都有类似机制，原理类似，机制

13、不同，这里不 一一展开讲了。 Hbase： hdfs层的data node在发现盘损坏后，会收集剩下的所有block信息，并通知name node 对比修复 Cassandra:基于 Merkle tree 的 anti-entropy 机制 Ceph： scrub 和 deep-scrub 机制3. 可用性分布式存储系统，相比传统关系数据库，有更好的可用性。在个别机器硬件或软件故障，甚 至整个机房断电断网等极端情况下，仍不影响在线读写。对于个别机器硬件或者软件故障，一般数据保存多份副本或者纠删码方式就能解决。对于整 个机房断电，只能是多副本的跨idc存储，一般分布式存储系统都支持这种方式，只

14、是目前 实际应用的很少。保证可用性，另外一个影响因素是，整个系统是否有单点故障。完全分布式的设计是没有单 点的。集中式的设计，有meta信息，需要meta server的角色，一般也会将meta server做成 集群式，以避免单点问题。下面结合例子讲下。1) 分布式 or 集中式 Hbase： meta server是集群方式，通过zk的选举算法选出一个主节点来提供服务，主节 点挂掉后，会重新选一个。所以hbase的meta server也不算是单点的。但其region server 是单点的，即一个region server挂掉，在master没有为其负责的region进行重分配前，这个r

15、egion所负责的range，是无法提供在线读写的。之所以存在此单点问题，猜测因 为hbase设计之初，是为网页库这类离线存储设计的，而非在线服务。另外，region server 的这种设计能较方便是实现强一致性和简单事务，后面会提到。现在貌似已有 region server 的 stand by 机制，即一台 region server 挂掉，另一台准备就绪的能马上接替并提 供服务。 Hbase 架构如下:etflcsm 工口寸口 K匚口匚口“ JUUL_U石口口匚勺 呻吟n甲匚 DaaF炖图6 hbase架构 cassandra和ceph:是完全分布式的（ceph虽有monitor se

16、rver，但仍可理解为完全分布 式的，这里不展开了），无单点问题。4. 可扩展性存储系统的可扩展性，即扩容的难易程度。可扩展性是分布式系统相比传统关系数据库，最 大的优势。各分布式存储系统都能很好的支持横向扩展。由于实现方式的不同，扩容的难易 程度还是有差异的。一般集中式的系统扩容更加容易，完全分布式的系统会更加麻烦些。下 面结合例子讲下。1） 扩容 Hbase:比较容易，扩容的大致过程为：增加一些region server，由master server做一下 balance，即重新确定region server与region的对应关系（每个region负责一定范围的 key，对应于hdfs上

17、的一组文件），完全不需要拖数据。而hdfs本身扩容也较容易，因 为有name node存在（相当于master server，对写入hdfs的每个块儿都记录其存储节点）， 可以将新写入的文件写入到新扩容的server，这样不需要拖数据；如果要考虑写压力均衡（即不把写压力集中在新加入的机器上，仍然写所有机器），仍需要做数据迁移。 Cassandra和ceph:因为key定位是通过hash类算法，所以拖数据不可避免。拖的数据 量即新加的 node 所负责的数据量。一致性 hash 和 crush 算法不同，导致拖数据的源节 点不一样，但总的来说大同小异。5. 数据一致性一致性分强一致性和最终一致性

18、，解释如下:强一致性：写完一条数据keyl,马上读keyl,能读到最新数据。最终一致性：写完一条数据keyl，马上读keyl，可能读到老数据，但一段时间后，能够读 到新数据。最终一致性相比强一致性,有更高的性能。一致性跟primary和replica在读写时的地位相关， 不同系统在实现上会有不同的取舍，下面具体说明。1） 单主、多主、主从 Hbase： region server 是单点，可以理解问题单主方式，天然的强一致性。 Cassandra:最终一致性，通过客户端一致性级别的设置也可实现强一致性。Cassandra 多个副本节点的地位相同，可以理解为多主方式，并列提供读写，这种方式读写性

19、能很 高，除了牺牲了强一致性，还有造成写冲突问题，cassandra通过column级别的时间戳 解决此问题，但不彻底，时间戳相同时就没有办法了。 Ceph:的多个副本间有主从关系，一主多从，客户端写主节点，主节点负责写从节点。 客户端只能读主节点。以此实现强一致性。 Ceph 也支持配置为本地化（就近，不一定 是主节点）读方式，这种方式也牺牲了强一致性。 Ceph 的块儿存储和分布式文件系统 功能，要求它必须支持强一致性。6. 性能前面已经提到，不同的一致性会对性能有影响。另外，还有两点对对性能影响较大：1） 完全分布式 or 集中式集中式架构需要有meta server。读操作先查meta

20、 server，再向data node查询真正的数据; 写操作除更新data node也可能要更新meta servero完全分布式读写则少了与meta server 交互的过程。所以延时更低。且集中式，在数据量巨大或者压力很大时，meta server有 可能成为性能瓶颈，目前有meta server分层、静态子树等解决方案。 Hbase:是集中式的，但客户端维护meta server的缓存，一般读写时无需网络查询meta server，所以从hbase这层看，集中式并不影响其性能。但hdfs层读写必须要name node 参与，所以性能低些。 Hbase+hdfs 这种分层架构，有很多好处

21、，但显然性能会逊一筹。 Cassandra：是完全分布式的，客户端可以连接任一台node读写，这台接入node通过一 致性hash定位真正负责此次读写的node，再进行读写。效率要比hbase高些。 Ceph：是完全分布式的，客户端通过monitor server得到节点信息，缓存在本地，再通 过 crush 算法，直接定位到主节点实现读写。这个角度看， ceph 的效果比 cassandra 更 高些。2） 单机存储引擎分布式存储一般采用LSMT引擎，将随机写转化为顺序写log和memtable （内存）方式， 能极大提高写性能。读操作，还是通过索引来提高性能。分布式存储的数据模型一般是 s

22、chema-less 的，即不需要预先定义每行包括哪些列以及每个列的类型，多行之间允许包 括不同的列；一般只有主key索引；不需考虑数据完整性约束（比如外键约束）、列类 型约束、NOT NULL约束等；所以较适合用LSMT引擎实现，关系数据库则不太适合。 Schema-less 是分布式存储一般性能较高的原因之一。 Hbase、cassandra、ceph都是wal的方式。顺序写完journal log后，写实际数据。写数 据时，hbase和cassandra是写memtable （源自bigtable吧），更多的减少随机写硬盘。 Ceph不是memtable的方式，直接写文件系统，并定时sy

23、nc。Memtable的方式对小value 更加友好，但需要引入的 compaction， compaction 带来了更多的运维工作。 Ceph 由于 其块儿存储功能，经常会修改一个对象的某一小段，如果用 memtable 的方式，即使修 改一小段，也要重写整个对象，效率比较低。7. 易运维性主要是扩容、顶替（一台机器损坏，用另外一台机器代替之，可能涉及到迁移数据、）升级、 盘故障（数据修复）等操作的快速性和简单性。存储机器一般是12*2T盘，现在极端一些有24*4T盘。单机存储数据量是很大的。扩容或 者顶替一台机器，一般也要几个小时甚至 1 天的时间。在这段时间内存储系统是处于副本缺 失状

24、态的，万一这段时间好的副本又出问题，后果可能很严重；所以，要尽量避免数据迁移 或者缩短迁移时间。1）扩容、顶替、升级 Hbase:不考虑hdfs的话，其扩容、顶替更容易，因为不涉及迁移数据。Hbase因单点 问题，升级必然影响在线服务，这一点是一直在努力优化的，例如之前提到的 region server standby 机制， hdfs 的 name node 的热备机制。 Cassandra：由于其gossip广播的限制，较难做的很大，所以360有多达几十个cassandra 集群，给运维带来不少工作量。扩容和顶替因涉及到迁移数据，比较麻烦，一般会绕过 它，刚开始集群建设一步到位，后续不扩容

25、，如果有机器损坏，直接修，而不是顶替。 Cassandra的升级比较有优势，3副本的情况下，可以最多一次升级1/3的机器，而不影 响在线读写。 Ceph：还没搞过大集群，crush机制理论上可以将集群建的比较大（也许几千台），但扩 容、顶替拖数据不可避免。因为不能确定数据的几个副本在那几个节点上，或者说不能 确定几台机器上是否有同一批数据的副本，所以，升级为了不影响在线服务，最好一台 台升级。2）磁盘故障 盘故障引起的数据修复，衡量其好坏的标准，就是是否够快、是否足够自动化。磁盘写 性能是修复速度的瓶颈。全局修复机制都能够做到自动化。所以，三种系统在这一点上 差异不大。8. 复杂查询与事务分布

26、式存储系统相对于关系数据库之所以能做到高性能、高扩展，主要的原因之一就是选择 不支持复杂的联表查询与事务操作。联表查询，分布式存储系统一般都不支持，而是通过冗余存储的方式实现类似的功能需求。 复杂的事务，也不支持。但简单的事务，如单行事务、CAS （compare -nd-set）还是可以支 持的。1） 事务 Hbase：支持单行事务（可以是多个操作），由于region sever单点，可以在单机上较容 易的实现。这是region server单点的一个优势。 Cassandra:支持单次操作行级锁；单个column的cas操作（依赖paxos多机协商，较 为复杂，效率低）。 Ceph 则没有此类需求，自然不支持。以上有些是实践总结，有些则加了自己的理解，有不对之处，还请指出，多谢。