走在前往架构师的路上

文章目录前言Ozone Upgrade相关要素关系Ozone Upgrade的过程执行前言最近Ozone社区刚刚发布了Ozone 1.1版本，这也是Ozone发布GA版本以来的第二个版本release了。当越来越多Ozone版本release后，这里就会有个版本升级的问题。可能有同学会好奇：目前Ozone支持版本Upgrade功能吗？据社区目前的进展，这个功能第一阶段实现已经基本完成，预计会在Ozone 1.2版本中和大家见面。在Ozone第一阶段Upgrade功能的实现里，一个基本的Upgrade框

文章目录前言相关背景Ozone的S3方式的存储实现分析Ozone S3的Multipart Upload功能分析参考链接前言Ozone作为对象存储系统而言，在对于用户使用的方式上，我们难免会想到另外一个已经在业界十分成熟的对象存储系统：S3存储。不过本文笔者并不想比较二者系统孰优孰劣，从用户角度出发，在用户已经使用S3接口方式做对象存储时，我们是否有方式能够透明的将底层存储移到Ozone上。换言之来说，Ozone是否能够做到兼容S3接口方式的对象存储，这样客户端就不需要做大的改动了。Ozone在早期r

文章目录前言SCM HA和OM HA的区别SCM HA基于InvocationHandler的请求处理SCM HA请求处理过程图参考链接前言在前面的文章中，笔者阐述过关于Ozone SCM HA的设计原理，目前这个功能社区还没有完全做完，但是大部分的主要功能已经完善。本文笔者来简单聊聊SCM HA模式下的请求处理过程，它和早期实现的Ozone OM HA的实现略有不同（OM HA实现原理可参考此文：Ozone OM服务HA原理分析）。Ozone在已有OM HA下，再实现SCM HA后，Ozone系统整

文章目录前言Ozone Streaming的背景Ratis Streaming前言在Ozone目前数据写出的过程，是基于从对象文件的block，再从block到chunk粒度进行数据的写出的。每次Ozone写完一个chunk后，对应着会触发一次write chunk的RPC call。当我们写入的数据文件对象很大的时候，过程中将会涉及到很多次write chunk PRC的操作调用。这个RPC call的频繁调用意味着相应更多的transaction的发生。对于Ozone Datanode里使用Raf

前言之前笔者讲过一篇关于Ozone Upgrade相关的文章(HDFS数据In-place Upgrade到Ozone的原型方案)，本文笔者继续围绕Ozone Upgrade这个主题，聊聊在Ozone Upgrade时，OM新旧版本之间，它是如何做到元数据的一致性的。倘若是Upgrade后的版本意为地执行了老版本留下的请求，亦或是老版本执行了新版本下发来的请求，这些都不是预期应该发生的情况。Ozone社区对这块的逻辑做了详细的设计。本文我们来聊聊这块的内容。Ozone OM Upgrade的预期目标

前言在中心化管理的存储系统中，当系统内的数据出现个别副本损坏的情况时，作为中心控制中心，它需要能够感知系统内的这个情况，并且能够快速的进行副本的拷贝恢复。我们姑且称此类服务为ReplicationManager，或者叫做类似于ReplicationMonitor的服务。此类服务在分布式存储系统中扮演的功能为定期检查系统内所有数据的副本情况，并进行必要的修复工作或者其它类似操作。本文笔者来聊聊Ozone系统中的这个服务，名称就叫做ReplicationManager。Ozone ReplicationM

前言在大规模的分布式集群节点中，出现机器损坏的现象是十分常见的。但是为了保证数据的高可用性，系统在设计上往往采用多副本的形式来达到冗余的效果。对于那些“损坏”了的机器，正常的逻辑是要总正常下线过程，即decommission流程。Decommission最为核心的一点是，它要保证节点内的数据完好无恙的复制到其它健康的节点上，然后最后将此节点标记为Decommissioned状态，随后就可以从集群中移除了。Decommission过程能够减小因为坏节点下线对于集群产生的不利影响。在我们所熟知的HDFS里面

文章目录前言Ozone EC概述Ozone Container Group以及CGI前言在之前文章中，笔者写过一篇关于Ozone EC方案设计的文章(Ozone的Erasure Coding方案设计)，不过当时那篇文章讨论的EC设计方案主要在Container级别以及Block级别做EC实现的方案对比，社区并没有敲定选用哪种最终的具体方案设计。最近社区更新了Ozone EC最新的设计方案，在Block级别做最终的实现方式，本文笔者聊聊此方案的实现细节。Ozone EC概述说到EC以及Ozone的

文章目录前言Ozone的S3语义和FS语义Ozone S3语义和FS语义的联合使用引用前言在Ozone中，众所周知，它最开始设计仿照的原型即是S3语义的存储模式：基于volume, bucket, key三层的存储模型，底层的key是实际存储的对象文件。至于里面对于volume, bucket, key级别的API操作，基本也是实现了S3现有支持的API操作。不过Ozone作为同样Hadoop生态圈内的一个项目，它需要与现有别的系统框架能够很好地协调工作。因此，Ozone内部实现了Ozone FS的语

文章目录前言OzoneFileSystem的不足之处Ozone FS namespace的metadata结构Ozone FS基于Dir cache的高效查找引用前言Ozone作为又一个全新的存储系统，它在底层存储结构上和HDFS有着不小的区别，用户往Ozone内读写数据的方式也有所不同。不过为了兼容目前Hadoop FileSystem的读写，Ozone实现了一个叫做OzoneFileSystem的功能。通过使用OzoneFileSystem，用户能够使用往常Hadoop FileSystem的通用

文章目录前言存储类别(策略)抽象提炼的意义HDFS的Storage PolicyOzone的Storage Class定义引用前言Ozone作为正在快速迭代开发中的存储系统，相比于HDFS来说，其内部能支持更大规模量级的文件对象存储。不过作为存储系统来说，它同样面临一些数据如何来存储的问题，比如数据存几副本备份，数据replication的策略是什么，数据存储的载体介质是什么等等。本文我们来聊聊Ozone对于这块内容的抽象设计。为什么笔者提到的是抽象设计呢，因为这个功能设计还处在社区讨论中，还未开发完

文章目录前言EC技术以及EC下的存储效率的提升Ozone下的EC方案设计Container Level的EC实现Block Level的EC实现引用前言众所周知，在当下存储系统中为了存储效率的提升，Erasure Coding(纠删码)技术在扮演着一个越来越重要的角色。比如说目前Hadoop HDFS中，它就已经能够支持EC功能了。在EC模式下，HDFS 可以不必存储多打3份这样的冗余副本数来为了容灾保护。存储效率的提高意味着存储海量数据所需要的存储节点资源的减少。不过本文并不是聊HDFS的EC实现的

文章目录前言现有HDFS删除操作的性能问题HDFS删除操作的brainstorm改进想法相关设计：Ozone系统内的删除操作处理前言前段时间笔者一直在折腾HDFS大目录删除的性能问题，也尝试了很多不同的方案来降低大目录删除所带来的性能影响，包括改INodeDirectly内部child list结构，或者是在Snapshot层面做改进优化等等（详见此文章：HDFS大目录文件删除方案的实践思考）。不过后续笔者在对比HDFS的删除操作和新一代存储Ozone系统内部的删除操作时，发现二者还是存在不少区别的，

文章目录前言SCM HA相较于OM HA的区别点SCM HA服务内存状态数据一致性的控制Follower SCM内部管理服务的“失效”处理SCM HA failover行为处理SCM HA的整体架构图引用前言在前面的文章中，笔者写过关于Ozone OM HA实现的相关文章(Ozone OM服务HA原理分析)，里面谈论了目前OM HA的一些实现细节以及OM HA如何搭建这类的说明性文章。但是一...

文章目录前言全局锁的细粒度拆分化Ozone内部基于Resource的锁管理器模型Ozone内部锁管理器实现前言众所周知在HDFS中，为了保证元数据更新的一致性，它所使用的是全局锁的模式。不过这在一定模式下会导致激烈的锁竞争的情况发生，尤其当集群规模日趋膨胀的时候，获取锁的这种代价就会变得越来越高。如果在不降低集群请求吞吐量的情况下，我们如何优化这一点呢？一种很自然的想法是将锁的粒度变细，锁粒...

文章目录前言Ozone Datanode Chunk文件原有layoutOzone Datanode Chunk Layout：FILE_PER_CHUNK和FILE_PER_BLOCK引用前言在Ozone中，Ozone的文件对象数据是以Block的形式进行组织的，和HDFS想类似。不过Ozone对Block进行实际存储的时候，是以更细粒度的chunk文件的形式进行物理存储的。简单来说，Bl...

文章目录前言Ozone Container自增型TransactionId：BlockCommitSequenceId前言在Ozone中，Container以Pipeline节点组织的方式通过StateMachine的形式进行状态一致性的更新。不过这里面对可能存在的一些边缘情况，例如Pipeline节点的突然重启，Container目录的意外删除，我们需要有别的手段来表明Container当...

文章目录前言ContainerStateMachine对于StateMachine/RaftLog的语义实现前言上篇文章里笔者介绍了Ozone中使用的Apache Ratis的内部一致性实现原理，得益于底层的一致性封装实现，在Ozone层面，它只需要调用此库并实现自定义的StateMachine方法即可。在Ozone Datanode中，就自定义了ContainerStateMachine来...

文章目录前言Apache Ratis基于Raft协议的一致性同步过程Apache Ratis内部RaftLeader/RaftFollower过程调用分析前言在之前的文章中，笔者提过Ozone内部使用的是基于Raft协议的一致性控制，以此保证Ozone Container操作请求在Pipeline节点上的一致性。但是这里面具体是怎么样的一个过程呢？RaftLeader/RaftFollow...

文章目录前言Ozone FS Namespace综述Ozone FS Namespace的结构设计前言之前笔者介绍过Ozone如何作为Hadoop兼容性文件系统供外部应用使用，就是我们所说的Ozone FileSystem。但是Ozone FileSystem在本质上并没有改变底层Key在Ozone中的存储形式，它只是做了一个从树型结构的路径到Ozone的volume，bucket，key的...

文章目录前言Ozone Recon模式的运作原理总结引用前言当面对一个复杂的分布式系统时，如果我们想了解其内部运行的情况，我们通常的做法是进行内部指标metric的收集和暴露。但是如果我们遇到一些内部指标的统计需要进行系统服务内部逻辑的大规模改动或者目标metric的指标收集操作会影响到服务的正常请求处理，那么这个时候我们有没有好的办法呢？最完美的方法无疑是搭建出一个元数据完全一致的READ...

文章目录前言Multi-Raft的支持到Ozone多Pipeline的节点复用支持前言在前面介绍Ozone文章内容中，笔者多次提及Ozone使用的是Raft一致性协议来做副本间的数据一致性的。Ozone使用的是Raft的Java实现库Apache Ratis实现的，在早期Apache Ratis实现里，它需要传入一个Pipeline节点作为命令操作的对象。并且每个Pipeline之间是不能带...

文章目录前言SCM和Datanode之间的Container处理过程SCM Container的状态转化前言上一篇文章里，笔者对SCM的Pipeline的状态转化做了一定的分析。本文笔者将对SCM中另外一个重要概念Container做详细的分析。Container作为Ozone SCM提供服务的存储单元，SCM内部在Container级别进行数据的Replication，心跳汇报操作等等。这...

文章目录前言SCM的Pipeline处理流程SCM Pipeline的生命周期前言在前几篇讲述Ozone SCM的文章中，笔者多次提及到了Container，Pipeline的概念。Ozone SCM服务围绕着这2个概念，对外提供核心的存储服务。本文笔者将对其中的Pipeline进行更为深入的分析阐述。Pipeline在SCM中的生命周期是如何的呢？它在SCM是如何发挥作用的呢？SCM的P...

文章目录前言Ozone FileSystem的简单架构Hadoop FileSystem到Ozone的命名空间的转化Ozone FileSystem的“虚假”目录的处理Ozone FileSystem相关代码实现分析相关阅读前言在前一篇文章中(Ozone作为Hadoop FileSystem的配置使用)，笔者介绍了Ozone作为Hadoop兼容性文件系统来使用的配置说明，也给出了简单的使用例...

文章目录前言Ozone FileSystem的Hadoop兼容性文件系统实现原理Ozone FileSystem的配置Ozone FileSystem的使用前言Ozone作为同样隶属于Hadoop大数据生态圈的一个系统，尽管它提供的是K-V对象存储能力，但是它和其它现有的Hadoop生态圈组件之间的结合使用依然十分重要。比如说Ozone是否能够支持Hive，Spark应用程序的文件读写呢？但...

文章目录前言SCM内部的服务模块划分SCM服务和OM服务的交互过程前言前面笔者写了很多篇关于Ozone OM的相关文章，本文笔者介绍另外一个与此紧密管理的服务SCM服务，一个提供基于Datanode Container容器的中心管理服务。简单地来比喻，现有的HDFS NN服务的角色功能在Ozone中，被完美地拆成了OM+SCM服务的模式。而且这样拆分之后，SCM提供的Container存储服...

文章目录前言Ozone Datanode Container Replication过程前言在分布式存储系统中，为了保证文件数据的冗余性，系统往往会对数据进行多副本的设置保存，比如典型的HDFS三副本文件设置。在Ozone中，同样也有副本的概念，不过它的副本单位粒度比HDFS的Block要粗一些。Ozone的是以Datanode上的Container为粒度，进行Container级别的Rep...

文章目录前言Ozone Datanode的服务启动前言在之前的文章中，笔者分析过Ozone Datanode内的数据处理过程，包括Container，Chunk文件级别的操作处理逻辑。本文笔者继续阐述Datanode服务内部的另外一部分的处理过程：Datanode服务启动以及心跳发送给SCM服务的过程。了解此本部分过程，能更加地让我们了解Datanode服务的正常运行过程是怎样的。如文章标题...

文章目录前言OM HA的配置初始化OM HA模式下的服务启动OM HA下的CLI命令使用附：OM HA的样例配置前言在上文中，笔者阐述了Ozone OM服务HA的内部机理，但是没有介绍其是如何配置使用的。本文笔者结合自己在测试环境中的HA搭建过程，来补充介绍下这块的实际配置过程以及中间可能存在的坑。想了解OM HA背后更多的原理方面的内容，可阅读笔者的上一篇文章Ozone OM服务HA原理分...

文章目录前言OzoneManager HA的目标OM HA的Raft方式实现前言在分布式系统中，为了避免中心服务节点存在单点问题，我们往往会有HA(High Availability)的防御措施。比如一个简单的HA部署方案，额外在另一个机器上部署一个完全一样的服务。当当前的这个服务出现问题时，能够快速切换到这个用来做HA的服务。HA服务切换本身并不是重点，这里的重点是如何保持HA服务间的状态...

文章目录前言Ozone数据的读取过程：基于Block，Chunk offset的数据读取Ozone数据读取相关代码分析前言上篇文章Ozone数据写入过程分析，笔者分享了关于Ozone数据写入的过程分析。本文，笔者来分享对应另外一个过程，数据读取过程的分析。总体来说，Ozone数据的读取和写入过程中，有着部分共同点，都涉及到了Block，Chunk，buffer的概念。论复杂度而言，读取过程还...

文章目录前言Ozone Key(文件)数据的写入Ozone Block(Chunk)数据的写出前言上篇文章Ozone Datanode的分布式元数据管理，笔者阐述了关于Ozone Datanode的分布式元数据相关的内容以及Datanode上的数据layout。既然我们了解了Datanode上元数据的结构，那么一个很自然的问题：Datanode如何进行数据的写入的呢？里面的数据一致性是怎么做...

文章目录前言Ozone的分布式元数据Ozone Datanode数据的layout前言众所周知，当元数据空间达到一个比较庞大的规模量级的时候，HDFS会遇到一定的扩展性问题。首先HDFS将这些元数据INode信息都load在内存中进行管理，而且还有附属相关的mapping信息，这些庞大的信息被HDFS的NameNode所管理。相应地，NameNode也将会面临更大规模量级的请求处理。从更本质...

文章目录前言HDFS的Topology AwarenessHDFS Topology的层级，距离定义问题Ozone的Topology Awareness前言众所周知，在大规模分布式存储系统中，数据往往通过多副本的形式来保持其可用性。但是多副本如何进行位置放置又是一项值得深挖的领域。至少我们总不能将所有副本都放在一台机器这样的极端情况。对于副本数据的放置，其实涉及到的考量因素还是比较多的，副本...

文章目录前言Table Cache的作用Table Cache的核心要点：数据访问的一致性Table Cache的样例实现Full Table Cache的实现Partial Table Cache的实现引用前言在数据存储中，比较常见的一种存储形式是以表的形式进行数据的存储。表由一条条的数据记录所构成。当然，我们也会对表内的数据做各种维度的分析或者更新处理等等。而在这些过程中，我们免不了会对...

文章目录前言数据探查服务的初始点：元数据的同步数据探查服务的分析：索引结构的重新构建数据探查服务的结果：汇聚表DB的存储数据探查服务的额外功能：节点级别的统计数据探查服务的外部展现：用户控制台引用前言在大规模量级的分布式存储系统中，很多时候管理员以及用户都有特定条件的查询需求：比如用户哪个目录文件数据量是最多的？还有对于管理员的需求：哪个节点上存储的文件数量最多，又或者是否存在损坏数据块文件...

文章目录前言Data Scrubbing Vs Data CleaningData Scrubbing的缘起前言在大型的分布式存储系统内，当系统运行超过一段时间，个别存储节点出现数据块的损坏是再常见不过的事情了。这时候从系统层面，它最好能够自动发现并从其它节点同步副本数据。我们称这个过程为Data Scrubbing（数据清理）过程。对于一套成熟的分布式系统而言，Data Scrubbing...

文章目录前言系统的三大Insight视角三大Insight视角信息的收集Insight Tool的设计实现前言前一篇文章刚刚讨论过在分布式系统中如何构建一套metric框架来帮助我们做系统性能指标的收集，以此帮助我们能够更好地了解系统运行的情况。在这里，metric信息是一种能够让我们看到系统内在具体运行情况的一个信息。这里还会有其它信息，比如常见的系统log，这个也是广泛被用来查看定位系统...

文章目录前言HDFS存储系统数据的完全删除基于加解密的输入输出流的数据保护方案前言关于GDPR是什么，可能许多同学之前并不太了解，至少笔者在之前也是不清楚的。GDPR全称为通用数据保护条例，General Data Protection Regulation。它是一项来自欧盟的关于计算机数据保护相关的条约，旨在规范系统如何收集，管控用户私人数据的种种行为。但是当前的一些存储系统并没有完全符合...