大家好 欢迎来到我们的话题下面会有我和格续杨为大家介绍E-RF-S目前我们正在为容器做什么这个话题我们会由乌夏几封组成首先我会给大家简单介绍一下E-RF-S文件系统并且会为大家同步E-RF-S近几年的一个开发情况然后我会为大家介绍容器形象眼镜的过程并且会给大家介绍我们新的NITUS金像服务实现的一个与E-RF-S建容的Rufs V6的四盘格式再接下来 格续杨会为大家做一个关于NITUS金像加速服务的介绍并且为大家介绍新的NITUS体系结构的设计思路例如为什么我们要做新的NITUS以及我们这个新方案的价值最后我们会为大家做一个NITUS加E-RF-S加Rufs V6的一个测试情况的总结以及相关的测试数据披露最后我们会给大家我们未来工作的展望当然 最后一点时间我们会留给大家做一些集中的Q&A这就是我们大概的一个演讲的一个思路那么E-RF-S文件系统是什么E-RF-S代表的是增强型的指读文件系统它的实现首次出现在NITUS Daydream的4.19当中然后一年以后正式落地到了NITUS 5.4的FS的目录里面E-RF-S它是一个以QUAR为单位的一个指读的文件系统只不过在设计中它的QUAR的单位标准配置大小是配置大小也就是4K所有的原数据都会集中在一个一个的QUAR里面并且这些的QUAR不会QUARQUAR那么这样的话我们就不会产生任何的IO获取开始的方法就会有更好的性能除此之外 由于我们是一个以QUAR为单位的文件系统为了去避免它在QUAR中间的有空间的浪费我们使用了一个叫Telpacking技术通过这种技术我们可以让数据和原数据紧密的结合在一起并且可以通过单次的IO直接将原数据和数据一把加载起来那么我既可以实现空间的节省也可以通过Telpacking技术达到更好的性能URFS文件系统可以用于不同的高性能的止渡场景例如我们可以在安卓的手机中使用URFS它可以用于止渡分区或者是APEX的格式之中URFS也可以使用在其他各种各样的签入式的系统中例如路由器或者IoT等URFS文件系统还可以用在LeaveCD上例如市区的ARC-RSO已经将URFS作为它的一个LeaveCD的一个进向格式之一当我们将Blob和Metafin离并且去做一根的数据去除后URFS也可以用在实现高性能的容器进向也就是我们这个topic即将要展示的Nedas进向服务的RufsV6的这么一个整体的解决方案URFS也有一个可选择一个透明压缩技术我们可以将一些文件通过使用多个可配置的压缩的算法或者是压缩单位进行压缩那么这个压缩算法我们可以针对不同的文件选择不同的压缩算法我们也可以针对不同的文件去选择不同的压缩单位通过这种方式我们可以保证在端道端性能的情况下去尽量的去接受空间上的使用我们并不引入原数据因为原数据的压缩特别是缩引格式的压缩往往需要随机的访问那么这种随机的访问对性能的影响更严重当然有需要我们也可以去结合其他的压缩技术例如我们可以通过batchFS去压缩或者我们可以通过video去压缩我们通过这些技术来去解决原数据的压缩问题URFS目前还会有一些其他的一些比较有用的一些特性目前正在开发中那么这个下图的这个左边它就是URFS一个针对安卓手机应用的这么一个情况的一个试试图那么下图的右边就是我们即将要为大家介绍到Rafv6也就是URFS兼容容器进向的一个设计上的一个试营下面我会为大家去进一步的介绍URFS最近几年的一个开发动态首先在压缩的方面URFS支持的是固定输出的一个压缩的技术我们在5.3的版本我们已经支持了LED4的原地解压的技术然后我们会在即将的5.16的环境版本中我们会去支持LEDMA的散发在可配置华东窗口以及字典大小的方面我们在5.13我们就已经支持了LED4的一个华东窗口的一个可配置化那么我们后面会在5.16中我们会支持LEDMA也会我们也会支持LEDMA的一个字典的一个可配置化我们在压缩索隐的方面我们在5.3的版本上我们支持了压缩文件的一个紧凑的索隐那么通过压缩文件的紧凑索隐我们可以让压缩索隐的大小更小索隐的原数据如果它的大小更小那么它所产生的L量也就会更少那么也就会有一个更高的一个性能我们在5.13我们支持了一个大块压缩的这么一个技术那么我们通过最高可以允许每一兆币的一个PClusterSize来进行压缩也就是说我们最多数据压缩到一兆的一个PClusterSize的耳中我们也支持了原地以及缓存的IO的一个策略以及同步和义务的一个解压的策略我们除此之外我们在5.1的版本中我们还支持了Palsix ACL的一个全新管理的一个技术我们在5.15中我们支持了以创口为单位的一个非压缩的一个文件格式这个主要是因为数据的去虫我们在5.15版本我们支持了Directile和FSX的技术并且我们对压缩和不压缩的文件我们都设计了FileMap的接口那么我们在5.16我们会去支持多设备那么上述介绍的Trunk去虫以及多设备的特性那么就会为我们的Rox V6加Nedas也就是我们这个新的容器进向的方案提供一个坚实的保障下面我们来为大家介绍一下容器进向的发展历程那么首先容器进向最初也就是所谓的Docker进向当发展到Docker VR的时候在5.15年这时候OCI推出了一个所谓叫OCI-V1的一个进向格式的标准那么它对容器进向做了一轮的标准化那么他们不管是Docker VR也好还是OCI-V1也好他们都采用了一种把容器进向喘换为一种target的一种格式那么通过层与层之间的一种去重来去实现一种增量化的一种存储那么在2016年Fast的中有一篇swecker然后它提出了一种懒家载的一种方式它表明大概一个进向里面只有大约6%的一个数据然后在容器的启动阶段会被访问但是我们默认生成的target的这种格式其实它是不支持我们一种可以寻止的这种解压也就是说是没办法去直接去实现这种按许下载这种懒家载的基础然后到了2019年其实就开始逐渐的意识到了这个target是自身的一个圈械然后并且组织了一些对于ociv2的一个讨论的风暴然后去进一步的去扩散了相关的一些思路那么后续像现在我们目前比较流行的一些进向服务那么以及格式那么例如是EstarGZ以及Nedas那么总体来说就是结合我们前数的那个ociv2的相关一些讨论其实我们就可以知道一个比较优秀的一个容器进向的格式它实际上是具备无下的特点的首先第一个它是肯定它是要支持一个懒家载这么一种支持那么当然它除了懒家载之外我们还可以通过数据的一种驱虫然后我们能够进一步的去降低容器进向它自身的存储那么我们通过去分离原数据就是这容器进向的原数据以及相关的一些数据的一些blog那么我们就可以让原数据能够尽快的尽快的实现加来起来实现rally那么通过我们去进一步的去减少数据的blog的这个个数那么我们就可以实现一些我们就可以实现更有效化的一些方案并且我们能够去节省它存储的开销我们也可以去节省它传输过程中的开销例如我们如果采用profile的一种blog的方式那么其实我们就可以想到它自身的那个文件系统的存储的开销就会特别特别大但是如果我们采用曾经或者是一种比曾经更大力度的这么一种blog的一种存储的一种方案那么它的轻易成本以及它存储方案存储成本就会变得非常非常的低那么除此之外我们当然我们实际的格式最好还是具备它能够有最小化的一种运行态力一个运行态力这么一种运行态力开销然后并且它能够有一个整体上的一个整体上的一个性能上的一个优势那么这些优势包括我可以采取一种quad对齐的方式啊并且我们可以利用tile packing啊我们的格式最好也能做到map friendly当然我们oclv2我们最好也能实现镜像的一个验证的并且我们也能够做到一个内核状态下的一个文件系统的一个挂载那么当然它如果它要是在具备一定的灵活性以及扩展性来说的话那么其实这就是一种一种相对来说比较具备优势的一种下一代的一个容器倾向的一种格式那么通过以上的这些这些这些要点我们可以发现niters加urfs然后再加上ruf36其实它是能够比较完美的去满足上述的这些特点那么其实我们可以看到它其实是具备一些比较良好的一个发展的一个前景下面我来为大家介绍ruf v6磁盘格式的一个设计思路ruf v6是urfs兼容的一种磁盘格式那urfs它是一个比较灵活但是强大的一个开源的指读文件系统的磁盘格式首先它的原数据是不压缩但是可以直接寻止的它的原数据其实是对齐在一块为单位的边界中那么这个块每个块单位都是一个一个页的单位也就是4k那么其实它的好处就是我的在当前那些现在的存储介质中它其实它的iO的放大式基本上是可以忽略的那么它也对Page开始的回收以及它的迁移是比较油耗的它尤其是对定征存的情况下比较油耗当然我们的Metadata是没有压缩的它其实是也可以如果需要的话它其实也是可以通过一些其他的一些压缩技术例如8FS或者VDO的方式来进行压缩然后第二个是它iO2FS它是采用了一种叫Tailpacking inline的一种方式那么因为我们的原数据是不能夸业的所以说我们为了尽量的去有效的去使用存储空间并且能够去节省存储空间所以说我们采用了一种Tailpacking inline的这个技术然后将原数据和数据结合在一起那么这样的话我们相比于这些不对齐的Metadata不对齐的原数据的这种替代的方案我们这方案它的空间上有相似的结上但是它的性能会更好在iNote的Metadata下我们的iNote的格式其实是比较轻量的例如我们会有32或64次解的一个iNote的一个大小然后并且我们iNote的放置的也是比较灵活的就是它可以放置在任何一个地方只要你有相关的一些需求的话那么换句话来说其实我们iO2FS它其实是没有产生一些传统意义上的iNote或者是目录的一个表所以说就是说我们可以更加灵活的根据我们的需求来去安排我们的iNote的或者是我们目录的一个大概的一个组织的一个形式所有的数据其实在iO2FS中都是以Block为单位去寻止的那么其实相对的相对自己的方式去寻止的话其实它的iMap方式就会更加友好然后通过节省Tailpacking inline我们也是能够做到与字节寻止差不多的一个效果我们的目录的格式其实是支持随机的一个访问的那么我们就会有更好的一个目录的一个查询的一个性能那么iO2FS它也是比较容易去增加undisc payload的例如我们这次这个新的nandus容器倾向的这个方案就对iO2FS做了进一步的一个扩展那么iO2FS它也是比较易于眼镜的例如我们可以轻易的去增加一创可为单位的格式我们也可以去增加一些新的一些iNote的一些表示那么其实对于iO2FS来说这些都是非常易于修改的那么下面这个示意图就是我们容器Rox V6加航nandus这个新的容器倾向的方案它一个简单的一个示意图我们可以看到其实它的所有的原数据都集中在了一个单独的一个倾向中我们称它为一个boss jump那么剩余的所有的一些blog文件我们通过对它进行创可驱虫然后我们能够在boss jump中我们能够进行一个安度的一个索引那么索引结束了之后然后我们就可以去找到先进的一个创可那么最终这个boss jump加上各个blog结合在一起然后就现场我们的Rox V6的一个一种解决方案大家好刚才高强为大家介绍了Rox V6侧面课室我介绍它继续分享nandus相关的内容包括nandus的特性新价格特点怎么使用nandus最后会展示我们的测试数据nandus是我们为原生场景构建的一个高性能的纸图数据分发系统例如分发容器镜像软件包AI模型的nandus系统的核心是Rox的文件系统它是我们利用了可寻止的存储系统针对容器镜像和纸图数据看发的一个高性能的支持按需读取的文件系统如右下图Rox将数据分为两部分存储原数据的bootstrap文件和存储数据的blog文件bootstrap文件会在拉去镜像的时候以刺性下载好blog文件支持按需读取nandus是nandusCNCF副画项目DragFlight的字项目支持通过P2P的数据进行分发在原生生态机身方面我们支持了candend,buildcate,habra,runc,cutcandender等服务可以方便让原生业务使用Nadas我们的开发语言是Rust有很好的内存安全性并发安全性以及高性能现在的nandus也在内部多个产品线上得到了应用nandus其实早在三年前我们便开始投入开发第一弹实现的时候将镜像文件在House上解析好然后通过pass through的方式将文件直通到容器中这种方式能够很好的兼容以有生态但是也产生了较多的性能损失因为所有的文件操作都要转发到后端这样就会存在大量的fuse请求同时由于bottomofs实现的原因在运行过程中会打开大量文件消耗大量的fd带来更大的稳定性风险此外还有潜在的安全风险这种用法也是社区的用法但是个案方法在实际生产过程中问题较多在我们意识到之前问题后我们要主要从架构层面进行修复我们基于fuse设计了roughs的背误文件系统它可以直接mount Natas image而无需将其解压到House上在这个过程中我们做到了镜像数据按需加载和数据驱虫等特性从测试的数据看能够大大提高镜像的启动速度但是由于所有的文件操作都要转发到用户态的roughs来进行解析操作在实际运行过程中会发现有大量的fuse请求导致整体性能不佳这对以上问题今年我们提出了一个新的容器镜像文件系统roughsv6它兼容了内核文件系统EUFS使得我们可以直接在Gauss科能中利用EUFS直接解析镜像文件而不用将所有的文件请求转发到House上在新架构中我们在L路径上使用了dex你获得更好的性能和更少的内存占用量新的notice架构既可用于fuse也可用于内核文件系统EUFS可以同时支持装C和cutter容器以上除了不兼容roughsv11我们得到了大量的优势按需加载数据驱虫正确性教应高性能我们新的架构方案可以说领先摄取两代我们希望将该方案推往到摄取让更多的用户能够享受新架构带来的优势在设计新一代架构的时候我们根据略稳测试数据设计讨论和未来发展总结了我们几点重要的设计目标首要目标是提升使用容器时赶上最明显的启动速度容器启动时间中占比最大的是镜像拉取过程OZM1需要将所有数据拉回到本地后才能解压启动但是只有6%的镜像数据被真正使用到所以按需加载是解决该问题的首要方法同时按需加载还能大大降低容器启动阶段由于网络问题导致的启动失败比例在我们的生产环境中通过Nadas的按需加载将容器发取失败率降低了几十倍第二点是通过数据驱虫降低存储空间降低存储空间对内存占用本地及远端存储资源还有网络淡宽均能带来较高的收益第三点是提前考虑未来的扩展性比如机密容器镜像的安全扫描异常行为检测的第四点是要同时支持装塞原生容器和卡塔肯登的这种安全容器第五点是考虑在各种环境下的安全性问题运行中的高性能要求右图是架构减图每个Nadas的服务一个容器或炮的同一个代码它即可以支持装塞场景又可以支持卡塔安全容器场景我们通过一个后端支持寻执访问的远端存储一般是Rangitian对象存储NAS的并利用Rust的Bootstrike中保存的Metadata实现了按区夹载的功能并在下载过程中利用Dragonfly P2P网络进行数据分发减薪了后端存储的压力在安全容器场景中我们进行了架构优化通过按须夹载UFS和Dex等技术极大的提升了运行性能通过利用Fuse协议和Dex直接内存访问将House上的Blob进行Blob进行数据文件整个映射到Gaess可能中并利用UFS进行直接解析来提高性能因为Blob文件各数一般比较少所以我们Fuse请求各数也会比较少并且文件通过Dex直接按Map到Gaess中由于省掉了内存考备所以data减少了IO链路延迟同时Gaess可能不用再缓存文件数据节省了PageCache降低了整体内存消耗可以提高整体运行密度和运行的稳定性此外我们通过独放大和根据文件访问顺序进行文件重新排列来提高整体运行时的性能在实现文件重新排重排税讯时我们还利用了Mesh Learning寻找到一个最佳的布局方式提高IO命中率最终我们实现了Nadas文件系统格式在容器启动速度进行大小以及数据完整性等方面都优于当前OSM-1进行我们实现了进行的按区下载提高进行启动时候的速度实现了按照创立度的进行驱虫不仅实现进行内部驱虫还能实现进行之间的驱虫减小总的进行大小降低网络贷款的占用同时这里的创立大小也是可以配置的同时因为不同业务场景可能需要配置不同的创立大小实现了端断端进行数据教验我们在传输阶段和执行阶段都会进行数据和远数据的教应确保数据正确性还有正在开发的机密容器支持的基于唱歌的加密我们还支持多种存储后端包括Registry, NAS,对象存储Dragonfly, P2P,等实现让兼容了ocsback集成到了CNCF复华项目Dragonfly可以P2P方式返发容器进行减轻后端存储压力同时我们利用了摩什勒印进行数据重排的优化数据预取Io放大的测量分析以及异常行为检测接下来终点介绍我们的两个特性数据驱程和数据教验工作数据驱程工作在容器进行服务中的重要性不言而语如果驱程做得好不仅能加速容器启程速度还能降低单机的内存消耗并且还能降低Registry等后端存储的成本但是当前基于OSI V1基于Layer驱程效率比较低比如修改一个文件的语和数据会导致这个文件被重复保存到新的数据上被修改过的文件保存在不同数据层中且都需要被下载而实际上只有最上层的文件数据会被访问到了还有被删除过的文件仍然需要被下载比如右图中我们选择了三个常见的有一定业务特征及代表性的场景分别是韩路计算它代表了特定领域用户的场景比如外部应用视频处理应用程金融业务场景它代表一个会进行业务资深各种软件包部署的场景以及大数据莫生专应场景他们会周期性的迭代进向内容在每个场景中提取最常见的几十个进向进行数据居然分析反映在进向之间基于Layer驱程的效率远远低于了我们提出的基于进向技术进向驱程也就是Domai Specific Diplope数据驱程我们提出了两个可以迭押的驱程策略第一种是对一个进向内部所有的trunk进行分析在进向内部进行数据驱程每个文件的数据被固定大小切分成trunk并保存到数据层中数据trunk可以在不同的文件不同的进行之间共享所以既支持在进向内部驱程也支持跨进向的数据驱程仅通过进向内部数据驱程我们便获得了10%-30%的驱程收益在内部驱程的基础上我们更进一步我们提出了兼容的基于特定领域的驱程领域驱程权距驱程因为在一个特定的领域数据从权距来看相似度会更高重复率也会更高一些我们在一个特定的领域的常运进向中选择数据trunk出现频率大于某个预置时将该trunk加入到BaseImage中比如在还是计算场景中我们在11G的进向数据中选择trunk重复出现了5次G上的数据组合成一个layer一个生成我们的BaseImage其他进向基于BaseImage在生成新的进向这个BaseImage就类似于一个最基础的进向layer比如加碼进向层Passet进向层在制作的基础进向后我们根据基础进向进行数据取成得到了一个比较高的取成效率同时该方案是兼容BoseSback不会带来额外影响的唯一特殊的地方是需要对遗忧的进向进行分析经过统计也来生成基础进向比如在还是计算场景中我们生成的基础进向大小为578兆约等于平均进向大小然后其他进向都基于该进向进行数据取成最终整体可以结成34%的空间这个取成效率远大于按照layer方式进行取成在金融赞献业务AI业务中我们的取成效率也远高于按照layer进行取成那么新引入的BaseImage会不会影响整体成本呢我们简单画了个在各业务场景下进向各数和总体存储成本之间的关系可以看到在保存了两到三个进向之后该领域进行按领域进行去从的存储成本就会开始低于正常的存储成本并且进向越多优势越大所以总体来说你使用的进向越多你结成的空间就会越多接下来再看看数据教验和机密场景Nadaz进向结构分为BossStripe文件和Blog文件每个文件的数据会按照固定大小切分成一个个Chunk每个文件的Chunk会被压缩并存持到一个Blog数据文件里面BossStripe文件中存放了所有文件和目录的元数据包括文件在哪一个Blog中以及具体的偏移同时元数据中还包括了一个Hash值整个元数据是一个Hash数每个节点的Hash值都有其内容来进行计算叶子节点的Hash值尤其是其中的数据进行计算非叶子节点的Hash值尤其是叶子节点的Hash值进行计算跟叶子节点的Hash值来源于Manifest通过这种方式Nadaz实现了在下载阶段和运行阶段的双重教验确保数据的正确性基于元数据我们也正在开发对机密场景的机密融洩场景的支持接下来讲讲大家最关心的Nadaz怎么使用的问题镜像使用的经典三步Build Shape Raw在Build阶段我们开发了工具NadazFile来将OCI V1镜像转换成Nadaz镜像并上传到原来的Redis学中也支持使用大家熟悉的Buildkit从DockFile中生成Nadaz镜像在存储镜像方面当前Harbor和Alibaba Cloud Container Registry已经支持了存储Nadaz镜像并能提供自动将OCI V1镜像转换成Nadaz镜像的能力Nadaz和Harbor合作开发了Acceleration Service Framework使用Harbor Acceleration Service镜像被铺置到Harbor后通过Webhook调用Acceleration Service 启动镜像转换可以自动将OCI V1镜像转换成Nadaz镜像最后在运行的阶段需要安装ContentDinNadaz GRPC它作为一个ContentDin Snapshot的插件以Demo方式运行可以解析Nadaz格式的镜像将其提供给RomC和CartContent的运行欢迎大家点击下面的链击使用Nadaz这一页展示了我们测试的一些启动数据我们测试使用了三个大小地增的镜像进行的测试这三种镜像大小也是我们在业务中常见的镜像大小我们在安全容器场景下使用了CII Control进行的测试Portime代表拉取镜像花费的时间E2E代表镜像从敲下乱命令开始到执行用户程序花费的时间可以看到我们的启动时间基本上都是瞬间完成的L-O-C-I-V-E启动花费的时间和镜像大小成正比这就是我们新架构带来的优势做到了即使再大的镜像我们也能在一到两秒内完成启动同时我们还在利用陌生乐应统计分析等方法继续优化镜像拉取时间做到更快速的启动这就是我们新架构带来的性能收益关于我们未来的工作我们会继续推进Nadas永远生生态集成包括可能的D,Dark和Rossy并在机密计划上完成Nadas ROVS V6机密容器进行方案的设计和演技推动E6FS,FSCache上由支持来买足Rossy场景下的按需加载探索E-STAR-GZ和Rossy V6集成的可能性最后在镜像机器学习上我们会通过机器学习继续优化数据盘序数据运取和异常行为检测首先更高效更安全的容器进行方案感谢大家聆听我们的演讲下面是北线红的链接和我们的讨论群欢迎大家加入下面还有一点时间我们留作QA请大家多多指正谢谢大家