那我就直接开始吧我是来自英台网络与边缘部门处理软件方案的刘孝东我们这节的主题就是在SBK里基于YouBlog与Videos然后的用户态快存储服务这一节也是观众到有朋友们其实并不是工作在云原生的基础设施也不是设计到存储方向上的朋友所以在这里我会跳过PBT里面的一些反锁的细节然后可以就是通过我们这一次的分享然后让朋友们能够即使不熟悉基础设施也不熟悉存储的朋友然后在后面当你做一些容器存储方案的选信时候也能知道它背后的一些基础远近方向也能知道它一些背后的运行过程我们首先看一下目录第一个的话是关于我们这个工作的背景与动机这里会说明容器对存储的需求在明确下用户太快存储服务它到底指的是什么接下来的话其实就是关于存储方案与当下需求所需要的新兴设计里面的一些比较因为传统的可用方案它其实是有各种不同的优缺点那么基于目前的需求我们应该需要一个什么样子的存储的协议站设计来满足现在的这种容器需求第三部分的话是我们目前已经看到的两个已经出现了新兴的存储方案它们分别叫VDOS和Ublock然后是SPDK在这两个方案上面的一些进展和支持情况最后就是我们关于VDOS和Ublock这两个方案的比较它们在不同的情况下其实是有不同的优劣式的我们其实这也是一个很已经持续了几年的一个眼睛方向那就是语言声和容器它们已经是当下业界最热门的话题之一然后也是目前最流行的发展方向各种各样的应用的话其实都已经迁移的或者说正在往这个容器语言声方向去做迁移比如说最初支持的应用都是一些Stilets不依赖之前状态的一些无状态应用再之后是很多运行期对运行数据有依赖的Stilts for应用甚至到现在一些企业界的应用也都在往语言声环境上面切也就是语言声上承载应用的类别越来越丰富那么它们对存储的需求也是越来越迫切因为有的应用它需要一定的暂存空间然后来满足它对一些临时数据的存储需求还有一些很多有状态应用其实是需要一些持久化的数据券来把它们的数据持久化下来SBDK作为目前一个非常被广泛采用的一个开源的用户带的存储解决方案那么这几年来也是被频繁地问到我们有没有一些容器的解决方案可以对用语言声做到支持那么可能关心上层应用的朋友们也许并不熟悉SBDK但是一些流行的开源存储方案比如像OpenEBSLanhao还有一些商业的容器存储方案他们其实很多都有用到SBDK来作为他们的一些存储引擎去构建接下来我们进入到背景和动机环节一般来说给容器用的存储他们都是由内核直接来做提供的但是其实也可以看到最初的时候也有一些用户带的demo他们有时候也会去伺服本地的IO请求比如说我现在画了这个图它其实是一个NBD类型的方案然后我们有一个NBD的demo然后它通过内核的NBDrawer可以给本机上其他的精神呈现出来一个NBD类型的块设备那么容器用的话然后就可以通过NBD的块设备然后来发起IO同时让后端在同一个机器上的存储服务的进程来给它做一些服务的满足为什么会有需求需要让用户带的存储服务软件来处理本机上的IO呢也就是说为什么要把这些本来在内核里面的IO处理都要挪到用户带里面这其实就是因为目前在现在的这种系统环境里面对这方面还是有一些要求的用它的块服务它的那个好处是在于第一个是灵活性也就是说如果我的那个后续我这个软件这个服务软件它有任何的那个升级需求那我通过用它的话其实是可以很容易的做到第二个的话就是那个就是稳定性的支持如果我们这个存储服务站它在内核里面然后是任何软件它其实都会有bug对吧即使是那个一个小的bug在内核里面一引发其实都会造成我这个本地这个机器然后可能就会直接crush掉但是如果我是在用户带那我即使我这个服务进程它有任何的问题那其实这个影响面是非常小的所以这也是用户带的一个优势所以在这里我们就先把这个如果要说到用户带块存储服务的话可能会有一些奇异所以在这里我们就先明确一下我们这个块存储服务这里即使的就是这种由用户带进程提供的块存储服务经过了一些内核里面的drawer然后提供给本机的其他进程去做使用但是就是刚才提到用户带存储服务的优点但是它其实有一个非常明确的缺点那就是它的性能不好这里举一个非常形象的例子那就是我们可以给它来做货币对贩的一个类比吧就比如说假如我要出国旅行但是我只有一张银连的信用卡如果我要是去了支持银连的国家去玩的时候我其实是不用做任何货币对换的我到了它那边我需要买什么东西我直接刷卡就好了这里面不是到货币兑换这就像是内核的块存储服务一样没有任何的烤杯的需求但是如果要是放在用户带这里面就会像是我要去一个不支持银连的国家去旅行可能我一个比较繁琐的方式就是我需要首先在我们国内然后把人民币对换成美元这是一次货币对换然后到了当地不支持银连的小国家的话我还需要再把美元对换成一个当地的货币所以这一次又是一次对换的过程这个其实就和我们的用户带的存储方案它实际上的数据烤杯是一样的它会有两次显著的数据烤杯那么在这里我们至少一个非常明确的优化点在货币对换过程中我如果在国内可以直接把人民币对换成当地那个小国家的货币的话那其实我就可以只做一次对换我后面的话就不需要到那个国家再做额外一次对换那至少这个就是我们一些新兴的存储方案他们希望能够做到的事情除了刚才提到的NBD之外然后还有很多其他的几个网络协议然后被用在去支持用它的块存储方案比如说这里说到iSCSIiSCSI target的话是可以让那个host和存储控制器通过那个标准的IPIP网络然后来传送SCSI命令在这的话我来解释一下这里面几个存储比较相关的词吧因为我怕担心有些那个朋友可能不是很明白SCSI就是过去我们硬盘它所用到的那个命令格式它是在连接主机和那个我们之间硬盘那些插他线之间传输的命令那么iSCSI也是顾名思义就是IP加上SCSI也就是说让SCSI命令运行在IP上还有一个就是在这边有一个那个targettarget然后下面我们还有看到有一个initiator那其实这个target和initiator的话其实是在存储领域里面也用传统下来一个词就是在企业机存储里面出现的一个词在SCSI这个企业里面它其实是把那个server端就是那个就是我提供服务这一方它把它叫做target然后在client端它其实不叫client它把它叫做initiator那么在那个后续就包括NVME在在的spdk里面其他的服务它其实都会沿用这个命名方式那就是target和initiator所以后面如果朋友们在那个做一些技术选型的时候然后他告诉你这是什么什么target什么什么initiator你就需要知道这个是什么什么的server是他的那个服务进程那个是他的client是他的那个就是需求方后四方或者是计算节点方然后呢就是我们可以看到就是刚才说到sGaC是跑在ipa以太网上的嘛所以为了要支持那个本机服务我们就会用到这个tcp的luback模式那么这就其实是一种运费的方式能够让那个运行在就是本机本机用户台上的这些那个存储服务进程可以就是通过这个回换tcp然后能够伺服伺服伺服本机在那个OpenEBS的还有浪耗的一些那个原始版本它其实就用到的是sGaC然后来伺服本机的存储服务那么sGaC它有什么样的问题呢我们这里可以这个sbdk的sGaC target做一个那个解释首先就是单纯从这个initiator这个drawer来看的嘛它其实是不支持matiq的而matiq的话其实对于现在应用的话是一个非常关键的一个需求那就是如果我要只有一个q我有很多容器它要同时去发 out 请求那第一个问题就是这些容器他们请求是要去争夺这个q另外的话就是不同的应用他们的请求放在同一个q里面的话也会造成互相的那种干扰影响第二个的话是在那个sbdk本身因为在sbdk实现的时候它其实这个sGaC target它是基于session去做的但是并没有做那个cpu call的scaling也就是说如果我要对本机就是做一个s target那么我其实是只能那个用一个cpu call来支撑整个机器所有的那个iO请求所以它在这方面会遇到一个danspu的一个瓶进最后的话就是刚才我们提到的就是那个信用卡或者引领卡那个粒子一样就是它的那个会有多次的那个拷贝所以它的性能不好效率不高再接下来的话就是nvmeovertcp那这个的话它和那个sGaC其实是特别像的本身nvmeovertcp它其实是把这个nvme的meannvme的mean能把它那个端到端的传输在那个基于ip以太王的这个solo和client之间但是呢这个nvmeovertcp它要是去支持那个这个容器这种块服务的话它也是需要用到这个tcp的回发模式也是一种预汇的方式但是呢就是我们如果要是没有现在这些新的方案的话那可能至少在我们社区的话可能推荐的用的方式那就是使用nvmeovertcp用sbdictnvmeovertcp的target那么它的话首先是一个被那个整个项目会那个非常好的优化掉第二个的话就是具有那个CPU Core Scaling也就是说如果要是容器请求它们发的那个就是它们建了好多不同的ql建了发送了好多请求的话那么在sbdict内部它会做那个就是Core会从1然后到n个这样的一些先进扩展同时来其实我们就是不断增长的这种iO需求但是它和scasset还是一样那就是它的性能效率不高本身就是还是基于sockettcp那一套所以还是有非常显著的那个Core会在这边我们接着看的就是如果要从sbdict角度看的话就是以前知识企业机存储的时候我们有这个分立式存储方案比如说像nvme和scasset他们的target然后后续到了训议化时代的话不是都是一些训议化存储吗我们里面其实是有vhost以及有那个vfl user这两个训议化存储方案那么对于像一些应用他们可能会考虑像一些数据库或者是一些feed相关的这种进程他们会考虑把那种存储隐形直接放到他们应用本身里面那我们其实在sbdict里面它的bdiv层blopstop层以及blopfs层的话都可以直接变异到这个形成里面但是问题就在这边出现了那我们怎么样能够去高效的去支持这些普通的容器这里面的话一个关键词就是general container也就是说我们普通的容器因为对于cata容器来说的话它其实有一个训议化存我们可以通过vhost以及vfl user来支持但是对于普通容器的话我们一定得通过cernal来做一次iO的转发刚才提到我们迫切的需要一种新型的高效的这样一些本级的快存处服务来交换iO请求与数据所以对于本级的快存处服务习以来说它关键需求点的话就是在于这几个第一个的话就是iO请求的iO请求与iO完成的通知交互那么这里面的解释就是如果要是我的一个application把它的请求把它的iO请求放到一个服务端进程可以见的区域以后这个application需要告诉我这个服务端你看我往这儿放了一个请求你要把它去处理一下那么在服务端进程也一样当我把一个请求完成之后我需要告诉我这个应用端我这个请求完成了所以这里面的话它是有一个交互过程的当然就是如果要是服务端和容器进程那边它们都是以这种轮旋polling的模式去做执行的当然这里是不需要做任何的通知因为它们本身就不断去轮旋嘛但这种方式的话对于这种服务端类似于spc这种进程它是无所谓但是对于应用端我在这个容器里面我要讲究的是效率如果我要用它去做polling团它显然是一个不合适的方式第二的话就是怎么样去让这些数据传递过程中的话可以再少一些数据拷贝刚才也提到了就是我们希望它仅仅做一次的拷贝然后来屏蔽至少这一次的拷贝的话是可以满足内核对安全上的需求最后的话就是关于一些系统现在系统的讯求那就是关于热升级和热恢复这里我解释一下热升级和热恢复热升级的话就是指因为我们开发一个服务进程其实是和我们应用进程一样它不可能是在一开始第一阶段的话就能把所有的需求都满足把所有的费车都加上所以说我的服务端进程它的那个功能也是逐步去演化出来的然后如果我要有一个新的版本出来我是希望在我服务不重要的情况下我能够让我集训里面的计算级点都能把我服务进程新的版本更新上去这个就是热升级还有一个就是热恢复还是说到就是任何软件都有隐藏的bug如果要是因为某些原因把bug出发我这个服务进程挂掉了那我希望我能够很快的把这个服务进程再次拉起这样的话就是它可以继续去伺服我前段的应用那么对于我前面的这些容器来说我感知不到你这个服务进程的挂掉我可能看到就是突然有那么一下子我这个服务请求好像慢了那么一点这个是关于对于现在信统需求上然后对这种新的存储协议站存储协议的一些需求那怎么去满足就是用无态协议站对这方面的需求呢我们就是比较了一下它其实是有这样几个关键的几个点第一个的话就是我这些iO请求和iO完成的话他们交互应该是基于这种对列方式来做交互这样的好处是在于我可能一次通知的话就可以去通知另外一方我这边是有一批的请求或者完成已经好了所以这里面可以做到一个高效的批处理第二个的话就是关于数据的传递如果要是在服务端和应用端之间能够做一些内存印设那么的话其实在两方包括内核之间只要把内存印设做好了那可能就不需要再做额外的内存拷贝了第三个的话其实是关于怎么样能够把我这些iO的命令iO的请求命令已经完成能够就是以一种高效的方式能够做打包和解包因为所有的命令它其实最后就像我们做GRPC一样它其实都有一个现形化和非现形化的这样一个过程第四个的话就是如果我这个服务中断了我能够给它做容忍然后同时也能给它做恢复那在那个近一两年的时间内的话然后我们发现就是在那Linux内核内核那边的话确实是眼睛出来了两个就是我们可用的就是这种新的新的存储块服务站一个的话叫做Vidios另外一个叫做Ublog我们先从Vidios看起Vidios的话它其实是VDP deviceIn-User Space这样一个缩写那么如果我在这边解释这个VDP可能会更就是啰嗦一点所以我们直接去解释这个VDP它是个什么样的东西它就是说如果要是这个Virtial设备它是实现在一个那个硬件上面比如说IPU卡它就是一个VDP的设备那么Vidios的话它就实现了一个一个方式那就是在用舞台我可以再用软件去模拟这样一个本身应该由硬件来实现了这样一个设备那么主机就可以看到了一个它就仿佛看到了一个真实的物理设备一样所以它这样做之后这个Virtial Blog设备表现出来就是通过Vidios然后呈现给主机那么Vidios这个Drawer或者它这个后段期程所做的所有这些这个服务的话是可以完全去沿用以有这些Virtial整个生态里面的这些Drawer的所以它有着通用的那个Virtial的数据通路它的请求的话是通过WorldQ去做传递它的那个数据拷贝呢在这里的话有点不同那就是通过一个软件的LTLB把那个PageCatch里面放置的这些从运用过来的这些请求然后去拷贝到一个BounceBuffer里面而这个BounceBuffer的话又会被这个Vidios Banking的就是这个后端的我这个用舞台进程去硬折下来所以在在这里面的话可能只有一次从PageCatch到BounceBuffer的拷贝而BounceBuffer从我这个用舞台后端会直接去取直接去用那么最后的话就是Vidios它是从那个2021年然后被BounceBuffer提交应该是很早应该2020年可能我想想可能就是20年时候开始已经有最初的一些PageCatch进去PageCatch提交出来然后经过了多轮review可能在2021年的时候在Linux5.5的时候开始逐步地去拨质到Linux那盒里面去那么这里还需要再提一下那就是Vidios的话它后面加了一个Utopacememory就是用舞台内存的注册这样一个一个功能其实这个功能的话就是对像SPG这样一种用舞台的快耳服务就是非常友好的一个过程因为像一些NVME也好RDMA也好这种用舞台这些设备的那个用舞台Drawer的话它是需要能够访问我这个进程需要访问这种内存的但如果要是按原来这个Vidios它做MemoryMap的时候BounceBuffer其实是有内核然后去申请分配的但是有了这个用舞台的内存注册功能以后之后我就可以把那个类似于SPK这样的一些用舞台的它自己的内部的内存注册给内核然后去使用这样的话其实功能就可以帮助SPK去构建一个非常高效的这样一个数据通路来建立一个完整的一个用舞台的一个存储站出来所以这里也是感谢一下从字节永济和Red Hat Jason他们的帮助来把这个这个功能加进去然后在这里面的话那可能就是前面的话我想直接跳过最后就想说在性能这方面因为Vidios这个SPKVidios这个后端的话它其实是和Vhost是一个基本上类似的一个工作流程所以我们可以预见的话它的性能其实是和Vhost是一模一样的就是说它单号的性能是非常高的每个号的话应该是可以达到100万到200万的这些LPSLPS的这个处理能力再往后的话是关于UblockUblock的话它其实是一个基于Urun的这样一个通用的它自己给自己的命名的话就是一个基于Urun的一个通用的用舞台用舞台快设备那么它的那个就是设计或者是那个实现出众的话就有这么几个第一个的话它就是目标就是给这个渔原生的存储或者是分母室存储提供一些那个本机的快存储设备的接口第二个的话它就希望我这个设备是一个我这个站的话是一个高性能的存储站这也是可以理解的因为本身已经有了好一种不同的存储协议站如果我这个性能不够高的话那它其实就没有必要出现再往后的话就是Ublock它是希望我这种设备类型的话它能够支持多对列为什么这里面额外会提一下多对列那就是因为有一些的那个存储设备类型的话它可能是在某几种的那个就是某一种单打就是比如说我可能是那种负载发起端可能就是一两个进程在这种特定条件下的话它跑出来的性能比较好但如果要是它的那个客户段比较多那可能会出现一些竞争和干扰它的性能反而会降低但是支持MaticQ之后然后它在多种不同的场景下它的性能都能达到一个比较好的那个体现那所以它是需要支持MaticQ的然后接下来的话就是一个很明显就是它是希望可以把这个所有的QuarIO的处理都放到那个用户态里面那这其实就是一个整个业界的一个发展趋势吧那么Ublock的话它其实是在2022年年中的时候就是年中间的时候然后是被Rat Hat那边提出来然后在2022年年底的时候从Linux 6.0开始然后合入到那盒里面这Ublock特点的话刚才也说到它是基于LU RUN的那所以它的那个比如说设备的初始化然后设备的那个查询和配置其实都是通过LU RUN去做Divis的configure的然后呢它的那个L请求的L请求和完成的交互也是通过LU RUN它的那个数据的考备的话其实也是通过它的数据考备的话其实在那个内核里面的话也是只有一次那就是从那个也是数据在PageCache里面然后考备到有这个用户态它提前提前分配和预添中的这种buffer然后去做这个的话其实和VDOS是有一点不同的那就是说我这个用户态用户态的那个driver的话用户态这个存储服务端的话我需要通过LU RUN然后以这种LU RUN的命令的话把我可用的这些buffer先提交先预先预先提交到这个内核里面去给这个Ublock去去使用去放置那个数据出来那下面这个图的话就是从那个我们的这个然后那个号碑出来的它就是说整个Ublock的话它其实分为这么几块吧整个Ublock framework第一个的话就是它需要有一个Ublock driver比如说在那个现在客户里面它的名字就是Ublock DRV然后就是我还需要在用户态里面有这样一个服务端进程那SPDK的话在这边其实就表演就是一个服务端进程的在SPDK里面我们给它的名字就叫做SPDKUblock target也就叫SPDKUblock服务端那么前端的这些所有的workload的话其实就是对应在我们原生场景里面这些容器的那个应用他们如果要发起所有的IO请求的话都会通过Ublock这种快设备然后经过Ublock driver然后给到我们SPDK这个target然后去做处理那这里有一点需要看一下那就是在那个Ublock它的那个设备类型里面我们可以在这个DV目楼下面看到了它的那个那个前队是Ublock B1234567然后前面说到那个Vidioz的话它体现出来的话是WattL設备嘛所以它的那个设备类型的话是DV目楼下VDA VDB那这个的话是一个那个Vidioz是一个Ublock它的那个IO处理的过程那在这边的话其实是考虑它是给一些那个后续就真正做这方面的人然后去了解这边所以在这里我可能就会把它先跳过它的这个处理过程那后续我再说一下就是关于SBDK在那个Ublock和Vidioz这两方面的一些那个开发进展吧第一个的话就是我们SBDK实现了一个Ublock Target然后它是一个非常高兴的这样一个Ublock的Sower然后可以给那个渔原生环境或者是一些那个开源也好或者商用的这种渔原生处处方案可以去用的这样一个存出引擎那么从那个今年2023年1月份这个发行版的话SBDK Ublock Target的话已经是那个作为SBDK的应用之一然后发布出来了而且在那个就是这里面会提到一个No Dependency那就是说因为Ublock它本身它其实只对LU任有那个依赖关系所以它对其他所有任何的那个模块也好立不一好都没有什么其他依赖关系所以它在SBDK里面也是与SBDK其他的模块其实依赖关系也是很小的没有的接下来就是因为Ublock这个Drawer它其实是那个提出来的也快合入的也快所以它有很多方面的话其实考虑的并不是特别完善所以现在的话它也是在不断的那个去那个改善自己所以SBDK Ublock Target也一样然后也是跟着内核Drawer它功能的不断完善然后我们也不断的去完善我们这个Target比如说现在的话那个Drawer里面已经有了User CopyYou get a feature这样的一些那个新的feature进去那我们也是一样的然后把这个User Copy和Get a feature也同时支持起来了然后我们现在做的Recovery feature的话也是正在进行中最后的话就是Ublock它的更多的信息的话就是关于SBDK Ublock的话其实可以我们这个网页来或许到怎么样去配置它怎么样去使用它以及它的一些使用的一些推荐方式接下来的话就是关于Vidios在SBDK里面的一些进展吧就是我们其实在更早之前然后就已经评估了Vidios然后也得到了一些很好的一些性能出来但是就是到目前为止其实我们在代码层面上的话还是一个那个概念验证的方式然后这个蓝色的链接的话其实还是我们POC的一些Patch的地址之所以为什么没有把它现在还没把它合并到SBDK主线里面其实就是因为就是也提到了Vidios的话它其实对整个WattL那个生态的吧它是有依赖关系的而我们其实实现的很多功能都是需要去依赖DPDK所以在这里面的话它有一些DPDK的这种酷寒树的这样一些依赖关系而且与Vehlz里面会有一些附用的代码所以如果要把它放到主线里面的话首先就需要去解决关于DuplicatedCode然后以及Library的一些支持所以我们目前就是之所以没有做upstream就是在卡在这边但是我们其实可以预见到后面我们会有更多的这些进展去把它upstream到主线里面去因为现在的话在DPDK里面这个Vidios的Library已经完全合并到DPDK的Vehlz里面去了在那个前不久对于DPDK Simon的话DPDK Simon的上面Red Hat Maxim它其实是有一个topic它其实就在讲它已经是把Vidios的功能已经在DPDK里面已经做好了那么基于现在的这样一些Vidios和Ublog这两个target的功能完善我们其实在SBK内部的话就是已经有一个更加完整的这样一些可选项也就是说SBDK在支持容器的这种本机服务上现在可以有多个可选项供大家去选择然后尤其是现在新出现的UblogTarget以及后去马上就会有的VidiosTarget还有就是我们其实在就有了Vidios和Ublog以后再加上NV,ME, ORTCP还有SGATI其实SBDK已经是一个非常足够好的这样一个数据数据的通路引擎然后来帮助容器存储方案去构建一个高效的永远生块存储服务接下来的话是关于Vidios和UblogTarget之间的一些特性比较首先的话我们来看一下就是关于Vidios和UblogTarget的软件站刚才也提到Vidios的话它是依赖于一个非常厚重的一个Virtual和Vidios的这样一些依赖关系和Driver关系所以说从上到下如果我要把Vidios的功能用起来我需要加载好几个不同的内核驱动从下到上的话就是Vidios的话再去支持VDPAVDPA在网上的话还有一个Virtual VDPA总线Virtual VDPA的话再到Virtual上然后Virtual的话给内核看到的话就是呈现出了一个Virtual Block这样一个设备所以它这里面会依赖多个内核驱动但是Ublog的话它就是非常轻薄它的依赖关系也非常简单那就是它是自包含的如果我要去用它的话我只要加载一个UblogDriverUblogDriver这样一个UblogDriver我其实就可以去去启动我这个后端了就所以它仅仅是依赖IoUrun那么在那个承受度上我们去比较它们的话又会有什么样的不同呢首先就是Vidios它其实它的代码整个review的过程的话也是比较漫长所以它的代码至少我们看来的话是更高的它经过了一个非常严格而且也是生死熟略这样一个review和修改的过程然后在那个字节里面的话它其实也是经过了非常多的一些大规模的生产环境的验证所以它的那个可靠性也是值得信来的然后最后就是因为它在2020年的话就已经被提出然后从2021年的话就已经开始被末日所以它的那个就是在内核里面它的历史相对也要更长一点但是对于UblogDriver来说的话因为它是在2022年就是年中间的时候被提出但是很快的话也可能这个review过程的话也并不是特别长所以它末日也很快所以在2022年还没提出的时候已经末日出来了但是呢它还需要更多的workload去做验证因为本身就是Mintender把它合进的时候也是其实是就是没有经过很多这种数据或者是一些那个就是需用方使用方的一些反规就已经把它合进去了所以说如果要真正把它使用起来的话还是需要提前做更多的这样一些那个测试环节然后就是就是还是说到UblogDriver因为它是比较轻薄的所以说如果它要是有一些功能的那个播完上或者是哪里是有bug它其实修复起来也是比较快要支持起来也是比较快的再以后就是ecosystem因为vdiOS的话它是有整个的那个它是有那个它是嵌在vortail里面的所以它可以使用完整的这样它可以使用完整的vortail的设施然后如果要是以后需要支持这种FS这样一些语计的话那我其实非常容易的可以把这个vdiOS类型的设备然后扩展到那个其他的vortail语计里面比如像文件系统的这种语计当然对于那个Ublog来说的话它其实是兼容在那个LinuxBlog层然后以及iO uRN的设置上面所以它可能对iO uRN的设置兼容性比较好然后呢它仅仅是给那种跨服务做的那个设计所以它应该不是很容易能够扩展到其他的存储类型里面去但是呢也说到它是完全基于iO uRN的所以说如果要是在iO uRN里面有一些新的feature或者说这个Ublog它需要它自己需要加一些新的功能或者是命令定义它其实这个灵活性是更高的因为它没有依赖关系在以后的话那就是考虑它们的兼容性还是一样的就是vortailblog的话本身其实是在多种不同的环境里面然后都有去使用比如说在那个距离化环境里面的话我们买一些设计我们可以看到它里面是有一些vortailblog设备的如果我要买就是现在比如说阿里云也好或者其他云云公司也好他们不是会卖一些那个裸金属服务对吧然后它下面的一些神路或其他IPO卡的话它其实也会给你呈现出来一些不同的vortail设备所以说在裸金属也好在计计里面你都可以看到一个vortail设备那么在容器里面的话我还是可以同样通过videos给这个前端进程前端这些容器容器进程然后给他们看到vortail类型的设备那也就是说如果我我现在已经然后它是跑在一些传统的那个就是计计里面跑在裸金属里面同时我还需要签一部分上云的话那其实使用videos的话对我来说这个兼容性更好因为本身所有这些所有的这些设备类型都是完全一模一样的我看来都是vdavdb这样类型的设备但是对于uBlock来说的话那可能只能是在这种面向于云云生这种环境里面去用如果我要是在虚拟机或者是在裸金属里面的话那可能我是用不了这种设备的我跟独对它建容性可能就比较差了就在以后的话它就关于他们的效率和性能然后也提到videos的话是基于worldql和shadow memoryuBlock的话是基于iO语认和就是提前于天生的buffer所以他们的话其实如果要仔细继续用起来他们的其实整个机制还是非常相似的然后去观察他们的性能我们就确实也发现就是uBlock的性能确实是要比videos好一点如果再考虑整个机器里面CPU使用率的时候但是如果要看那盒的邮件列表然后他们其实有一些人会提到就是他们跑下来发现uBlock它的性能的话是videos的二到三倍这个其实在我们跑下来的话是比较夸张的也就是说uBlock它的性能好处也就是高那么百分之几而且基于现在这个差距的话从videos那方面我们也是知道其实videos它也是不断地去改善自己的一些限制的把这个性能提出来比如说他们在那个讯件的时候也把这个ARQ的回掉affinity这个功能加进去然后性能也提升了很大一部分再接下来的话就是和那个SBD一些互操作性这里面的话其实就是总的来说的话videos它的互操作性会更好因为单个SBDX的话能够达到一些极限性就是单靠一二百万的iO PS但对于uBlock来说的话因为它就是这个数据考备过程的话它其实是在SBDX上下文里面那SBDX就因为这考备的这样一些限制它的单核性能的话可能尤其是跑那个4K这种iO请求的话也就是到600K但是如果要考虑整个的CPU的整个机器的CPU使用率的话可能videos还是稍微好一点最后的话结论的就是uBlock和videos它其实都是新兴的这种QUAR的存储协议站来提供这种UFO带的QUAR服务尤其是对SBDX这样的应用它是比较友好的那么在SBDX里uBlock和videos都取得了非常不错的性能和开发收益尤其是在和之前的ASCASIA和NVMF相比同时对于uBlock和videos来说的话他们很难去定论哪个好哪个坏他们显示出了各有的一些优势所以也是希望云元生存储的一些关注者或者开发者在选型数据引擎的时候根据我们刚才说到的这样一些不同的好处来选择更合适的一个方案来做应用那我的分享就到这里了谢谢大家如果没有问题的话我就结束了你好我大概有两个问题第一个问题是关于这两个就是videos和uBlock我刚看到是videos背后其实是字节在做并且有生产环境做验证对但uBlock这边的sponsor是谁呢有这样子的案例吗uBlock的首先发起者的话也是在Red Hat然后它的额外sponsor的话其实在阿里云那边阿里云的话有内核团队然后也在往里面做一些提交但是从他们那边反悔来说他们也觉得目前放到生产环境里面的话可能还需要再多更多的验证因为本身还是缺乏一些生产环境的验证而且它的功能也确实还是在不断的改进我们其实spk这边我们在比如说是时间这个功能的时候也是发现写着写着发现突然这儿怎么会问题然后发现原来是有bug我们还帮他修复了几个bug在uBlock上面对了解第二个问题是其实可能跟整个spdk的这个bw会这一层有关就是我们在这一层上我们有更多的这种可观测性的一些就是真正把它比如说做成一个产品然后我们肯定想更多知道比如说我们在kernel里面我们有这种 outstats能看到这些性能统计数据对做一些chasing的东西对吧但是spdk这边的支持就是有计划或者是其实是关于如果要是比如说单看每个blog的这样一些统计数据的话其实是有一些rpc的我可以直接把每一个不同的blog设备他们的那些iO统计信息可以把它拉出来然后在做cues的时候的话其实也有一些cues设置可以设置说这个blog设备它可能支持的iO的吞吐或者是lps最大能够到多少另外一个的话如果要是考虑单纯spdk里面他们的真实的cpu使用率因为本身spdk是polling的如果我们直接通过linux top去看的话是100%但是如果要是想去细咎里面我可能某一部分它的那个站的使用率是多少的话其实可以通过spdk top去看或者直接通过rpc自己去把它profiling出来我们这些数据其实都是可以把它导出来的了解了解就是还是就是通rpc来来的那些数据来的做统计是吧对了解了解好的谢谢谢谢大家我有问题你好这套用户胎的那个存储的解决方案是有一个在用户胎一直运行的进程来运行的是吧对对的那我有问题就关于这个热身级的一个问题就是如果在这个用户胎进程因为某种原因挂掉的这段时间内它的那个iO请求是没办法没办法得到处理人那对于这种情况是有什么比较好的解决方案其实解决方案非常简单就是尽快的把我这个挂掉的进程赶快把它拉起来因为就是就包括这两种方案的话他们其实都会只能说在那个专管本身的话把这些数据给你或者请求这些纪录给你暂存起来或者不把它丢掉所以你快速起来之后自己再把它捡起来再赶紧干净给它做个处理OK那就是挂掉过程中如果这个iO请求就没有处理或者是丢掉的话它其实是不会丢掉它仅仅是在那边喷嚏下去比如说新的服务精神起来之后的话再给它把这个iO完成就好了就其实这个其实是和那个更多的是要和内核去做比较因为如果你要在内核里面如果它的Driver或者是内核里面就是实现了一个这种存守服务的话如果它要挂掉之后那其实那只能是卡死了就对吧对对对是经常遇到这些挂掉的卡住的情况对对所以说这也是为什么需要把这种iO处理的逻辑主要原因好的那我还有最后一个问题就是这个Pending的iO请求它是有数量上线吗应该这个上线其实因为本身这两个这样一种方案的话它们都是基于那种Q去做的对吧所以说上线的话就是你的Q数量乘以你的那个Q的长度OK好的谢谢好 谢谢