Facebook分布式文件系统Tectonic概览
发布时间：2022-12-07 11:08:57 所属栏目：云计算 来源：
导读： 像很多大公司一样，facebook也构建了自己的底层分布式文件系统主流分布式文件系统 云计算，名叫Tectonic，这个项目的起始时间大约在2012年前后主流分布式文件系统 云计算，今年，他们在FAST21上发布了一篇名为《
|
像很多大公司一样，facebook也构建了自己的底层分布式文件系统主流分布式文件系统 云计算，名叫Tectonic，这个项目的起始时间大约在2012年前后主流分布式文件系统 云计算，今年，他们在FAST21上发布了一篇名为《Facebook’s Tectonic Filesystem: Effificiency from Exascale》的论文。本文围绕这篇论文以及youtobe上的一些相关的视频资料，尝试概述性地介绍一下Tectonic。 Tectonic的出现是为了将公司中分布式存储的一些通用问题集中在一个系统中解决，降低研发成本。Tectonic在构建过程中尝试解决三类问题：一是真正的大规模（元数据的水平扩展）；二是提供多租户之间的性能隔离；三是提供per租户的性能调优。 一般拥有分布式文件系统的大公司往往都是将一个分布式文件系统集群服务于一类业务，比如这个集群只给对象存储用，或者只给块存储用，但是Tectonic在设计上，为了减少运维成本、增加集群的资源利用率，在同一个大的Tectonic集群上同时支持了诸多业务，最常见的是对象存储和数据仓库服务。 为什么要有Tectonic 在Tectonic之前，Facebook中的三大在离线存储系统Haystack、F4和HDFS都是各自独立构建的存储栈，存储热对象的Haystack系统，主要对外提供IOPS能力，本身对存储空间的要求并不是很高；而存储温对象的F4却恰恰相反，它对存储空间的要求较高，有很多富裕的IOPS能力；相应地，不同的HDFS业务的特点也区别较大，有些注重存储空间而IOPS较为富裕，另外一些重IOPS而存储空间较为富裕。 云计算与分布式的关系_主流分布式文件系统 云计算_云计算 分布式存储 Tectonic之前的Facebook三大存储系统 可以看出，孤立的存储系统无法最大化资源利用率，为了提高IOPS和Storage资源的利用率，Tectonic应运而生，本文的终点不在Tectonic的多租户方面，而是架构的整体概述。 主流分布式文件系统 云计算_云计算 分布式存储_云计算与分布式的关系 Tectonic在存储栈中的位置Tectonic的架构 Tectonic是一个只能部署在单数据中心的集群，可以容忍host、rack和供电单元的失效。Tectonic本身并不能容忍数据中心级别的故障，它之上的用户需要构建geo-replication的能力来解决单个数据中心故障造成的可用性和可靠性问题。分布式文件系统跨多个数据中心本身并不会带来成本明显的下降，反而会让系统本身的复杂性变高，分而治之是一个比较好的方案，据说Facebook中有个单独的团队做数据中心之间的数据迁移系统，包括不同数据中心Tectonic之间的数据迁移。 一个Tectonic集群的架构如下： 云计算与分布式的关系_云计算 分布式存储_主流分布式文件系统 云计算 Tectonic的基本架构 从模块的角度看，一个Tectonic集群由四大模块组成，分别是： 元数据服务Metadata Store数据服务Chunk Store 大量微服务组成的Background Services 客户端Client Library 从数据parition的角度看，一个文件会被默认切分成一个个Block，每个Block的默认大小是80MB，每个Block可以使用EC编码，EC编码的每个数据分片称为一个Chunk，同一个Block的Chunks会被分配到集群中的不同ChunkStore中。 Metadata Store Tectonic文件系统的所有元数据都通过Metadata Store维护，Metadata Store是一个可真正意义上水平扩展的元数据服务（而不像HDFS那样提供Federation这样的伪“水平扩展”的元数据服务） 云计算 分布式存储_云计算与分布式的关系_主流分布式文件系统 云计算 Metadata Store的基本结构 文件系统的元数据被分为了三层，第一层叫Name layer，主要存储目录和目录元素（子目录或文件）之间的映射关系；第二层叫File layer，主要存储文件和Block之间的映射关系；第三层叫Block layer，主要存储Block和chunk之间的映射关系。这三层元数据都以K-V的形式存储到key-value store中，这个key-value store是一个理论上可以无限扩展的分布式kv系统。Tectonic使用了ZippyDB作为Metadata Store之下的key-value store。 ZippyDB是Facebook自研的一款分布式kv系统，它有以下特点： 关于“每个副本都可以提供读服务”，找到了一篇ZippyDB团队的分享，大致有几点：1，读可以有多种配置，用户如果想获得最高的一致性，可以配置为只从primary读；2，follower会维护跟primary的log lag，如果超过一定的阈值，就拒绝提供读服务；3，客户端会维护数据的版本，如果从secondary读的话会带上该数据版本，secondary上的数据如果比客户端的版本更旧，就拒绝提供读服务。 三层元数据的具体key-value切分如下所示： 云计算与分布式的关系_主流分布式文件系统 云计算_云计算 分布式存储 Name layer中，key是，value是当前文件的属性和inode_id。这层维护目录和它下面的所有目录元素的映射关系。 File layer中，key是，value是当前block的元数据。这层维护文件和组成它的所有data block的映射关系。 Block layer中，key是blockid，value是该block的每个副本所在的location（即图中的list）；除此之外，Block layer还维护disk和block的反向映射，便于在盘或机器下线时快速定位它上面的block信息，从而做快速数据修复。 将目录树以KV的形式存储到分布式KV中是一个比较朴素的分布式目录树的技术方案，Tectonic有两个较为显著的特点： 1. 分布式KV做Shard操作的基本单位并不是整个key，而是key的部分前缀。例如Name layer中，并不是按照整个key做Shard，而是根据dir_id做Shard，这样一个目录下的所有元素都位于同一个Shard下面，便于做list dir等操作或目录内的元数据操作。相应地，同一个文件下面所有的block的元数据也都位于同一个shard下面。 2. mapping关系是expanded的，它的具体含义是：在做kv抽象时，如果value是一个列表，并不是将整个列表作为value，而是将列表中的每个元素作为一个单独的key，同时将真正的key作为当前元素的key的prefix。这样做的好处是如果key对应的内容被修改时，并不需要将整个value都读出来，例如一个文件系统中，某个目录下面可能会有百万个文件，如果通过非expanded的方式，那么需要将巨大的一个value读出来、修改、写入，这会显著降低文件系统的性能。在expanded模式下，只需要更改某个特定的kv对即可。 热点规避是设计一款分布式文件系统必须要面临的问题之一，在Tectonic中，大约有2/3的元数据操作都是针对文件的，Block layer使用Hash-partition的方式来划分Shard可以使得热点均匀分散在ZippyDB的所有Shards中。另外，Tectonic中的目录和文件都可以被Seal。一个目录被Seal是指它的当前孩子元素列表以及元数据无法被修改，并不影响它的孙子元素；另外文件也可以被Seal，Seal后无法再追加写。Tectonic可以将Seal状态的目录和文件做一层缓存服务，这样不仅可以做热点规避，也可以提高读性能和元数据服务失效后的可用性。 Name layer、File layer和Block layer都使用hash-parittion的方式划分shard。 元数据的一致性方面，因为ZippyDB只提供单个Shard内的事务，所以Tectonic在单个目录或文件上操作的一致性完全依赖于ZippyDB的分布式事务。Tectonic并不提供跨目录的move操作的原子性，也需要业务自己去保证在两个目录之间做move操作时不会有其他的并发操作。 ChunkStore ChunkStore负责存储Block的每个分片，在设计上，ChunkStore有两个特点： 平坦的。ChunkStore整体存储Chunk个数的能力可以随着存储节点的增加而完全线性扩展。对Block、File、Directory等概念完全透明。Directory、File以及Block的关系都由Client在实际执行时串联起来对外呈现为文件系统中的核心元素。 在具体的存储策略方面，ChunkStore使用了XFS作为底层文件系统，每个Chunk与XFS中的文件是一一对应的。看起来Tectonic并没有使用用户态文件系统。 ChunkStore对外只提供Chunk的核心API，如ReadChunk、WriteChunk、SealChunk、DeleteChunk、ScanChunk等功能。 在线上，一个ChunkStore运行的典型环境中有36块HDD和1块SSD。 Tectonic团队发现，一个文件系统中大约24%的IOPS都来自于元数据操作。所以他们考虑了以下办法来解决这个问题： Write less dataSmaller metadata Fewer flushes for writes Create a new filesystem Put the metadata elsewhere 前4种明显不可行，所以他们做了一个HybridXFS的文件系统，将XFS的journal和部分元数据写入到SSD上，如下图所示： 云计算与分布式的关系_主流分布式文件系统 云计算_云计算 分布式存储 picture from : usenix.org/sites/default/files/conference/protected-files/srecon19apac_slides_shamasunder.pdf Client Client将Metadata Store中的目录、文件、Block和ChunkStore中的Chunk串联起来，对外提供文件系统的语义。 Client提供单写多读的语义，它的写入也是并发写入到多个ChunkStore中的，而不像HDFS中的链式写入。 有了以上核心模块，一个典型的写入流程如下： 主流分布式文件系统 云计算_云计算 分布式存储_云计算与分布式的关系 一个典型的读流程如下： 云计算 分布式存储_云计算与分布式的关系_主流分布式文件系统 云计算 后台服务 除了MetadataStore、ChunkStore以及Client外，其他所有的服务都是无状态的微服务，可以在任意地方部署和运行，比较核心的后台任务有 Garbage collections Rebalancer Stat services Disk Inventory Block Repair/Scan Storage node health checker重要功能 从Tectonic的论文中，可以看到Tectonic的一些另外的核心功能。 Tectonci只支持单机房。这点在本文开始的时候有提及。Offline EC。Tectonic并不支持在线EC。很多在线EC的系统都需要业务对写入的数据做对齐，如果业务对写入的数据不做对齐，那么系统设计会较为复杂，工程化实现的难度较大。Tectonic针对这个问题给出了一个笔者也非常推崇的方案：前台三副本，当一个chunk被Seal掉之后，后台转EC。这既解决了用户不需要对齐数据的问题，也解决了三副本存储带来的成本问题，更使得系统较为简单。这个设计很好地践行了“以终为始”的设计原则，毕竟我们用EC的目的不就是最终降低成本嘛，中间先写三副本又有何妨？无处不在的Checksum。Tectonic中的数据校验机制不止存在于进程通信时，进程内部也会做校验，用来防止进程本身的bug导致的数据改错。EC 重构风暴问题。EC的重构会带来很大的读放大，而读放大又进一步会影响其他副本的正常读，进而又引起其他副本的EC重构，最终整个集群会出现“EC重构风暴”的问题，出现性能严重下降，甚至会影响到可用性。Tectonic通过限制单个客户端内只允许10%的读请求做EC重构来避免这个问题。总结 Tectonic的出现，使得Google、Microsoft和Facebook三家都各自有一篇顶会Paper讲述他们的分布式文件系统，超级公司也越来越意识到存储形态多样化后，构建一个统一的底层文件系统的必要性。国内的很多新老超级公司也都在构建底层分布式文件系统，统一的分布式文件系统在超级公司中未来可能会成为一个必备的基础设施。 从G、M、F三家的实现来看，作为一个最底层的基础设施，系统设计上保持简洁非常重要，适当地将某些功能推到上层或旁路去做，分布式文件系统只需要做到最基础的几个核心功能即可，优雅的、简洁的设计对于分布式文件系统本身的稳定性和生命力是至关重要的，尤其在快节奏的互联网企业，更是如此。 当你交付的版本质量数次被用户挑战、发布的版本在线上的稳定性屡屡被客户吐槽，功能约做越复杂时，找个安静的地方，冷静地问问自己，系统是不是做复杂了？当初就不应该这么设计？亦或是质量保障流程上哪里出了问题？如果你的设计缺陷越来越暴露无遗时，你是不是有勇气自己推翻自己，回到“以始为终”，重新做好事情以便快速有效地解决公司或用户的问题？ （编辑：财气旺网 - 海宁网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
站长推荐