Ozone

文章目录 前言 Ozone Streaming的实现背景：Ratis Streaming Ozone Streaming方式写过程 参考资料 前言 在Ozone目前数据写出的过程，是基于从对象文件的block，再从block到chunk粒度进行数据的写出的。每次Ozone写完一个chunk后，对应着会触发一次write chunk的RPC call。当我们写入的数据文件对象很大的时候，过程中将会涉及到很多次write chunk PRC的操作调用。这个RPC call的频繁调用意味着相应更多的transaction的发生。对于Ozone Datanode里使用Raft协议做数据一致性同步过程的影响而言，则意味着更多的raft log需要被apply以及对应Ratis snapshot的take操作也会变得更加频繁。在一定程度上，这会影响到Datanode节点本身的数据写出操作。最近社区提出了利用Ratis Streaming的特性来优化Ozone数据写出的流程。本文笔者来简单聊聊Ozone Streaming这种全新方式的数据写出过程，目前此功能处于有一个初步的设计方案阶段。 Ozone Streaming的实现背景：Ratis Streaming 首先我们来聊聊Ozone Streaming的一个大的背景，Ozone Streaming想法的提出源自于Ratis

前言 在大规模的分布式集群节点中，出现机器损坏的现象是十分常见的。但为了保证数据的高可用性，系统在设计上往往采用多副本的形式来达到冗余的效果。对于那些“损坏”了的机器，正常的逻辑是走正常下线过程，即decommission流程。Decommission最为核心的一点是，它要保证节点内的数据完好无恙的复制到其它健康的节点上，然后最后将此节点标记为Decommissioned状态，随后就可以从集群中移除了。Decommission过程能够减小因为坏节点下线对于集群产生的不利影响。在我们所熟知的HDFS里面，就有相当完整的Decommission过程以及命令使用方式。本文笔者不聊HDFS的Decommission，而是聊聊新一代对象存储系统Ozone的Decommission原理过程。尽管Ozone在底层数据存储原理上与HDFS差异较大，但是在Decommission部分逻辑上还是有许多共通之处的，笔者会在下文中具体阐述其中的一些区别点。 Ozone Decommission原理过程 Ozone Decommission过程用更为具体清晰的解释：Ozone基于Container的Decommission过程。Ozone在数据replication是在Datanode的Container level来做的，那么Decommission过程也就自然同样是根据Container来做的。

　　大家好，我是痞子衡，是正经搞技术的痞子。今天痞子衡给大家分享的是 为i.MXRT设计更新Segger J-Link Flash下载算法文件 。 　　想要在Flash中调试，基本是离不开Flash下载算法的，毕竟要先将代码烧写进Flash，然后才能调试。主流MCU开发环境（MCUX / IAR / Keil）以及调试工具（J-Link）的Flash下载算法设计思路基本都差不多，简单的说，就是把Flash擦写操作的底层驱动代码可执行文件通过JTAG/SWD预先加载到MCU内部RAM里，然后继续从JTAG/SWD接收应用程序代码数据并调用预加载的Flash擦写操作代码实现下载。 　　痞子衡前段时间为大家介绍过 《利用i.MXRT系列ROM提供的FlexSPI driver API可轻松IAP》 ，其实MCU开发环境和调试工具里的Flash下载算法也在某种程度上算是一种IAP，目前最新版本的开发环境和工具基本上都是基于ROM API来实现i.MXRT的Flash下载算法的。 　　在i.MXRT所有Flash下载算法里，痞子衡认为Segger J-Link版的Flash下载算法是最应该掌握的，毕竟Segger提供了完善的软件工具支持（Jlink commander、J-Flash、Ozone），既可独立使用，也可嵌入其他MCU开发环境中使用（实际上它与Keil算法文件是兼容的）

　　大家好，我是痞子衡，是正经搞技术的痞子。今天痞子衡给大家分享的是 为i.MXRT设计更新Segger J-Link Flash下载算法文件 。 　　想要在Flash中调试，基本是离不开Flash下载算法的，毕竟要先将代码烧写进Flash，然后才能调试。主流MCU开发环境（MCUX / IAR / Keil）以及调试工具（J-Link）的Flash下载算法设计思路基本都差不多，简单的说，就是把Flash擦写操作的底层驱动代码可执行文件通过JTAG/SWD预先加载到MCU内部RAM里，然后继续从JTAG/SWD接收应用程序代码数据并调用预加载的Flash擦写操作代码实现下载。 　　痞子衡前段时间为大家介绍过 《利用i.MXRT系列ROM提供的FlexSPI driver API可轻松IAP》 ，其实MCU开发环境和调试工具里的Flash下载算法也在某种程度上算是一种IAP，目前最新版本的开发环境和工具基本上都是基于ROM API来实现i.MXRT的Flash下载算法的。 　　在i.MXRT所有Flash下载算法里，痞子衡认为Segger J-Link版的Flash下载算法是最应该掌握的，毕竟Segger提供了完善的软件工具支持（Jlink commander、J-Flash、Ozone），既可独立使用，也可嵌入其他MCU开发环境中使用（实际上它与Keil算法文件是兼容的）

文章目录 前言 EC技术以及EC下的存储效率的提升 Ozone下的EC方案设计 Container Level的EC实现 Block Level的EC实现 引用 前言 众所周知，在当下存储系统中为了存储效率的提升，Erasure Coding(纠删码)技术在扮演着一个越来越重要的角色。比如说目前Hadoop HDFS中，它就已经能够支持EC功能了。在EC模式下，HDFS 可以不必存储多打3份这样的冗余副本数来为了容灾保护。存储效率的提高意味着存储海量数据所需要的存储节点资源的减少。不过本文并不是聊HDFS的EC实现的，而是谈谈时下另外一个存储系统Ozone的EC设计，也是简单聊聊在Ozone的对象存储模式下，EC要如何实现以及它能够带来的好处。 EC技术以及EC下的存储效率的提升 关于EC技术本身，全称Erasure Coding，中文称之为纠删码技术。EC的具体算法实现细节网上资料讲述的也已经很多了，本文不做过分细致的阐述。 简单的来说，就是将原始数据块进行划分成多个data block，然后根据EC算法的计算，产生出新的校验块(parity block)，如下所示： 当上述数据块或者校验块发生丢失或者损坏的情况时，系统可以根据EC算法进行重新生成来恢复，以此达到数据保护的效果。 还有一个问题，这里的数据存储效率的提升体现在哪里呢？ 继续以上述例子为例，在上面3个数据块

文章目录 前言 Hadoop ViewFs的问题痛点 Hadoop ViewFs的重载hdfs schema方式 ViewFs的mount point中心化管理问题 引用 前言 在大数据时代，随着业务的迅速扩张，很多大公司往往内部会有多cluster模式来支撑其内部的数据体量。在这期间就会涉及到一个多集群管理协调的问题，比如典型的HDFS的多集群管理。社区在早期实现的ViewFs以及后来的Router-based的功能在一定程度上能优化这块的管理。但是上述2个方案还不能完全cover住HDFS的多cluster管理的痛点问题，比如在一些用户写死在code中的地址，如何能做到纹丝不动的适配到viewfs多集群模式？本文我们来谈论谈论这个话题以及目前社区对此的解决方案。 Hadoop ViewFs的问题痛点 Hadoop ViewFs功能实现的时间可以说是非常早的了，当时最初解决的问题是在client端构建一个视图逻辑上统一的文件系统，ViewFs下不同的路径实际指向的具体的物理cluster地址。简单来说，就是我们在client端添加了一个类似mount point的映射表mapping关系。 因为是基于client side的改动，因此这会导致一个很容易出现的问题，ViewFs的重新部署更新会变得极为的麻烦，在这里面至少会涉及到如下相关服务的变更：

文章目录 前言 Single-Raft模式 Multi-raft改进 引用 前言 在之前笔者写过一篇关于Ozone利用Apache Ratis multi-raft功能来提升其系统的throughput的文章（ Ozone Multi-Raft机制对于更大throughput处理量的支持 ），不过那篇博文只是简单介绍了下在multi-raft的支持下，一个Ozone Datanode节点可以允许成为多个Pipeline的一员,从而达到加大Ozone请求处理量的目的。本文笔者来聊聊Apache Ratis multi-raft的具体实现原理，聊聊从multi-raft的应用到本质。 Single-Raft模式 既然我们有multi-raft模式，那也就是说还有对应的single-raft模式。这里说的Single-raft模式其实是最早RaftServer实现的模式，一个节点上面只启动一个RaftServer实例，它的正常server state无非两种Leader或者Follower（假设不考虑投票选举阶段）。 对应一个单节点单RaftServer实例而言，它在本地节点上以及服务自身会存有以下一些必要的信息： StateMachine，内部状态机。 RaftLog，持久化在本年底的transaction log。 还有Snapshot数据

文章目录 前言 SCM HA相较于OM HA的区别点 SCM HA服务内存状态数据一致性的控制 Follower SCM内部管理服务的“失效”处理 SCM HA failover行为处理 SCM HA的整体架构图 引用 前言 在前面的文章中，笔者写过关于Ozone OM HA实现的相关文章( Ozone OM服务HA原理分析 )，里面谈论了目前OM HA的一些实现细节以及OM HA如何搭建这类的说明性文章。但是一套完整，高可用的系统，它需要确保其服务整体的健壮性，目前Ozone依赖的SCM服务还没有实现HA，是一个单点的服务。Ozone社区在实现了OM HA之后，已经在设计考虑实现SCM的HA方案(相关JIRA： HDDS-2823 )，以此能够达到一个稳定可使用的Ozone发布版本。本文笔者根据目前社区JIRA上对SCM HA的部分设计要点，来聊聊关于Ozone SCM服务的HA，我们有哪些主要设计要点以及其与OM HA的不同之处。 SCM HA相较于OM HA的区别点 这里SCM是StorageContainerManager名称的简写，而OM是OzoneManager的简称。在Ozone服务中，SCM是底层提供存储能力的基础服务，OM则是其上的应用服务。对于OM这样的应用服务，它在实现HA时重要考虑的点在于Leader/Follower服务节点上db元数据状态的一致