简单美食网站模板,家装设计说明,免费咨询电话,销售新网站推广策略DAOS带来的思考
根据daos docs的描述#xff0c;DAOS是Intel基于NVMe全新设计开发并开源的异步对象存储#xff0c;充分利用下一代NVMe技术的优势#xff0c;对外提供KV存储接口#xff0c;提供非阻塞事物I/O#xff0c;端到端完整性#xff0c;细粒度的数据控制#x…DAOS带来的思考
根据daos docs的描述DAOS是Intel基于NVMe全新设计开发并开源的异步对象存储充分利用下一代NVMe技术的优势对外提供KV存储接口提供非阻塞事物I/O端到端完整性细粒度的数据控制数据保护以及弹性存储等特征。
intel daos给我们提供了基于NVMe实现高性能存储引擎的参考实现核心是并行性如何发挥多核CPU及NVMe设备提供的并行能力。
以大家熟悉的CephBeeGFS为例对并行不足及超额订购问题进行说明
Ceph的每个OSD管理一块SSD为提升并发能力每个OSD内部会划分多个ShardShard内I/O串行执行Shard间I/O可并发PG通过模Shard数映射到Shard接收到的I/O请求根据pg_id取模放入指定的Shard由Shard内的工作线程调度执行。I/O提交到引擎后通过单线程libaio批提交到设备独立的KV线程提交元数据I/O元数据提交后再归还工作线程。
Ceph OSD通过Shard来控制并发以粗粒度的PG为并发单位限制了PG及PG内对象I/O的并发能力导致系统的并行性不足理论上可以尽可能的增加PG及OSD Shard的数量及工作线程数量以此来提升系统的并发能力但这会带来严重的线程上下文切换开销大量的CPU时间被浪费在内核中导致CPU超额订购问题。
BeeGFS的每个OSD管理一块SSD采用Multi-reactor的网络模式从线程池给每个客户端连接分配一个工作线程用于处理I/O。I/O提交到引擎后通过POSIX接口pread/pwrite, read/write提交到设备I/O完成后再归还工作线程。
BeeGFS通过从线程池分配一个工作线程来处理每个客户端连接的I/O工作线程采用同步操作来处理I/O因此线程会被阻塞直到I/O完成这严重影响了系统的并行性SSD的性能很高需要很多的并发操作才能充分发挥其性能因此也可以往线程池中添加足够多的工作线程以此来提升系统的并发能力但这会带来严重的线程上下文切换开销大量的CPU时间被浪费在内核中导致CPU超额订购问题。
daos是如何解决上述问题的呢概括起来就两点轻量线程和非阻塞I/O。下图是我结合dao docs以及daos 代码绘制的一张daos 并行设计图 轻量线程在双路x86系统上一个DAOS节点DAOS Server通常包含两个存储引擎DAOS Engine每个引擎绑定一个Socket管理多个NVMe SSD。为了避免超额订购daos引擎使用了用户态轻量线程框架-argobots不仅减少了上下文切换的开销也实现了在没有内核干预下的完全调度控制。如上图daos_engine引擎启动时启动若干执行单元XS并绑定到独立的cpu core。每个XS内运行一个自定义的调度器Scheduler负责根据策略执行三个线程池pools中的轻量线程协程进而执行用户任务。从功能角色上XS分成3类系统XS负责处理系统管理任务如swim心跳dRPC请求dmg请求等主XS负责处理客户端I/O辅助XS协助主XS进行计算密集型任务如加密压缩重建等。daos引擎在运行时根据类型将用户任务添加到各XS的各线程池每类XS有若干其中每个主XS负责一个Target的I/O处理Target是逻辑设备一个Target和NVMe SSD设备的一个IO ChannelQP绑定通过多个主XS多个Targets和多个IO ChannelQP的绑定实现NMVe SSD设备的多队列并发能力。
非阻塞I/OLinux系统提供了多种存储I/O接口包括posix接口libaioio_uring以及spdk。posix接口是linux上使用最普遍的I/O接口通过posix接口发起文件系统I/O后调用线程会被阻塞知道I/O完成。libaio是异步I/O接口允许一次提交多个I/O请求减少用户态和内核态切换的开销。io_uring是Linux中新引入的异步I/O接口用于替代libaio它通过mmap共享内存在用户态和内核态直接交换数据允许一次提交多个I/O请求支持Polling模式减少中断带来的延迟及CPU开销。spdk是intel实现的存储性能开发套件它实现了用户态的NVMe驱动与其他的I/O接口不同spdk直接在用户态分配QP提交请求到内存的ring buffer接着更新标志通知SSD有新的请求到来。关于几种I/O的对比在2022 SYSTOR上发的一篇论文UnderStanding Modern Storage APIs有详细的分析daos中使用的是spdk。
DAOS服务端启动流程
下面这张图摘自daos internals很好的说明了daos server内部的服务分层及其和模块的交互关系 如上图daos服务端包括控制平面和数据平面两个平面daos的控制面是非中心化的全分布式设计和数据面部署在相同的节点两者通过dRPC通信Unix Socket这点与其他开源的分布式存储系统不同如glusterfscephbeegfs等。daos控制服务daos_server负责daos数据服务(daos_engine)的管理和资源的供给如网络、存储的供给数据服务的安装、启动等。各daos_server服务承担的角色并不完全对等根据配置其中有部分服务会启动raft一致性协议负责集群拓扑、节点状态的持久化。下图是我绘制的daos_server和daos_engine启动过程中的交互时序4节点集群配置了3个Raft节点各节点上的daos_server负责拉起本地的daos_engine在常见的两路x86服务器上每个socket上会启动一个daos_engine图中只画了一个
执行systemctl start daos_server启动daos_server过程中启动daos_enginedaos_engine启动后向daos_server发送ready的dRPC通知然后等待daos_server的SetUp消息更新init_state各daos_server向MS Leader发起JoinSys的gRPC消息MS Leader将daos_engine加入集群db置位needUpdateGroup标志各daos_server向daos_engine发起SetRank的dRPC消息daos_engine更新Cart group中的membs和swim membs以及缓存uri各daos_server向daos_engine发起SetUp的dRPC消息daos_engine设置init_state状态为DSS_INIT_STATE_SET_UP【daos_engine得以继续执行接着会完整各模块的SetUp最后激活utl barrier信号量启动所有的xs这样就可以提供服务了】MS Leader在检查到needUpdateGroup标志后向daos_engine发起GroupUpdate的dRPC消息任意一个daos_engine发送成功即可daos_engine更新Cart group中的membs和swim membs以及缓存uri。【MS Leader所在节点上的daos_engine学习到其他daos_engine的存在】MS Leader节点上的daos_engine启动ULT线程如果未启动向其他daos_engine发送MAP_UPDATE的gRPC消息广播membs及状态信息给其他daos_engine。【各daos_engine学习到其他daos_engine的存在】各daos_engine通过SWIM Gossip获取更新相互间的状态swim xs调用注册的回调直接或间接ping swim membs中其他daos_engine监测到dead engine就通过注册的网络事件回调向daos_server发送RAS_TYPE_STATE_CHANGE的RAS dRPC消息收到RAS dRPC消息的daos_server向MS Leader转发RAS消息发起ClusterEvent类型的gRPC消息MS Leader更新engine的状态到db置位needUpdateGroup标志【会激活过程6正是通过上述的过程6-9daos系统实现了engine状态的管理】
注上述的过程1-9隐藏了三个daos_server的raft选主。daos系统的集群信息由选出的raft leader负责更新并通过raft 日志复制在三个节点间实现集群配置的一致性和可靠性。
执行完上面的启动过程一套新的daos系统就准备就绪了下文是服务启动过程中核心的代码调用过程说明代码基于v2.4版本比较繁琐无趣对代码感兴趣的读者可以了解下希望对你走读代码有帮助。
Intel DAOS异步对象存储的实现涉及硬件、操作系统及KV等方面的知识其内部集成了很多的第三方库在研究其代码前建议各位读者
认真阅读daos docs掌握各种概念设计原理代码结构安装配置方法等了解各第三方库的工作原理结合examples掌握其使用方法如raft,argobots,cartmercury,spdk,pmdk等认真阅读代码中各模块的README文件如rsvc,rdb,vos,pool,container,object,mgmt,dtx等准备一套测试环境结合运行Log加深对代码细节的理解
DAOS Server的核心启动过程
DAOS Server是控制面服务通过systemctl start daos_server启动服务后会执行/usr/bin/daos_server start命令最终调用src/control/server/server.go中的Start方法核心过程如下
server.Start //环境检查及初始化初始化server实例初始化raftcontrol服务ms服务初始化网络实例化Engine实例化grpc启动raft注册raft回调newServer //初始化server实例createServices //初始化raftcontrol服务ms服务initNetwork //初始化网络,创建grpc监听addEngines //发起BdevPrepareRequest请求准备nvme设备实例化Engine注册onAwaitFormatonStorageReadyonReady等回调//实例化grpc注册controlms服务启动raft//MS Leader会在raft回调中启动Loop负责groupupdate的消息处理-将当前的EnginesRanks通过drpc发送给其中的一个Engine//Egnine收到消息后更新CART group中的membs列表启动rsvc mgmt服务启动广播ULT线程-发送MAP_UPDATE的grpc消息广播membs给其他Engine收到消息的Engine会更新membs执行通知回调crt_plugin_gdata.cpg_event_cbs这样就和SWIM关联起来了setupGrpc server::registerEvents //注册RAS事件注册raft回调server::start //启动server启动gRPC启动dRPC启动MS的异步Loop-处理PoolCreate、Join、PoolEvict消息启动EngineEngineHarness::Start //逐个启动EngineInstance安装newOnDrpcFailureFn回调【如果是MS Leader该回调在dRPC处理失败会触发并发起MS重新选主】EngineInstance::RunEngineInstance::startRunnerEngineInstance::format EngineInstance::awaitStorageReady //格式化检查SCM回调onAwaitFormat【记录一个NoticeInfo的Log】EngineInstance::createSuperblock //挂载SCM初始化Superblock并持久化到Superblock文件EngineInstance::onStorageReady //执行回调onStorageReady【发起BdevPrepareRequest请求清理大页更新cfg mem_size检查tmpfs的内存】EngineInstance::start Runner::Start //根据配置文件和环境变量初始化启动命令行Runner::Runner //启动Engine在协成中安装退出channel信号处理器等EngineInstance::waitReady //等待来自Engine的dRPC ready通知EngineInstance::finishStartup //更新Superblock发起RPC加入系统发起SetRank和SetUp dRPC请求执行OnReady回调EngineInstance::handleReadyEngineInstance::updateFaultDomainInSuperblock //更新Superblock中的FaultDomain故障域信息并持久化到Superblock文件EngineInstance::determineRank //向MS Replica发起RPC Join请求-Instance加入系统持久化到membership db分配Rank置位MS Leader的groupupdate标志返回后更新Superblock并持久化到Superblock文件//对于非MS Leader节点Leader会在上面的join请求中直接发起SetupRank的dRPC请求向Engine发起SetRank和SetUp dRPC请求接着设置ready标志MS Leader根据该标志进行一次groupupdate消息处理//收到SetRank dRPC消息Engine会更新Cart group中的mems列表和 swim membs列表缓存uri//收到SetUp dRPC消息Engine会更新init state至此Engine服务就完全run起来了EngineInstance::SetupRank EngineInstance::onReady //执行回调onReady【置位allStarted标志执行Server的onEnginesStarted回调-启动Prometheus exporter】DAOS Engine的核心启动过程
daos server负责daos engine的管理包括启停成员状态管理等它们直接通过dRPCUnix socket通信。在daos server启动过程中会根据配置文件及环境变量构建参数启动daos engine执行的命令是/usr/bin/daos_engine --args...调用的是src/engine/init.c中的main方法
main //初始化选项启动engine等待退出parse //根据命令行参数初始化选项server_init //启动hlc_recovery_begin //开始HLC时钟恢复dss_topo_init //初始化CPU topology信息这里会设置socket的core map以及engine上的目标target数最佳的core数2helperstargetsregister_dbtree_classes //注册各种btree class到全局数组btr_class_registeredabt_init //初始化argobots任务框架daos使用argobots来进行任务调度crt_init_opt //初始化cart网络框架初始化全局的cart结构根据配置初始化primary和secondary provider初始化primary和secondary的group信息NA配置及其他一些结构daos_hhash_init //初始化全局handle hash表pl_init //初始化全局placement hash表ds_iv_init //初始化incast variable树modules_load //加载各module各模块保存在全局列表中hlc_recovery_end //停止HLC时钟恢复dss_set_start_epoch() //初始化初始化epochdss_start_epochbio_nvme_init //根据配置初始化nvme全局结构初始化spdk环境//初始化各模块调用模块的init接口初始化模块如果有key添加模块到全局数组dss_module_keys添加gRPC handler到cart的opc_map 添加dRPC handler到全局register_table//vos注册containerdtxobject的btree结构到全局数组btr_class_registered添加模块到全局数组dss_module_keys//rdb:初始化rdb_hash表//rsvc:初始化rsvc_hash表用来暂存已open的rsvc服务如rsvc_pool//pool:初始化pool lru cache初始化pool handle hash表注册pool的各incast variable类到ds_iv_class_list列表初始化pool的默认ACL属性注册rsvc_pool类到rsvc_classes数组初始化nvme的reaction ops添加模块到全局数组dss_module_keys//container:初始化container lru cache初始化container handle hash表添加模块到全局数组dss_module_keys//object:注册btree class到全局数组btr_class_registered注册各副本类和EC类到全局数组oc_ident_array注册EC类到全局数组ecc_array添加模块到全局数组dss_module_keys//mgmt:设置id注册rsvc_mgmt类到rsvc_classes数组//dtx:根据环境变量初始化选项注册btree class到全局数组btr_class_registered添加模块到全局数组dss_module_keys//securty:初始化socket路径//rebuild:初始化全局结构rebuild_gst注册rebuild的各incast variable类到ds_iv_class_list列表添加模块到全局数组dss_module_keysdss_module_init_all dss_srv_init //初始化全局xs结构xstream_data初始化全局tls初始化系统db启动各xs启动dRPC监听vos_standalone_tls_init //初始化全局tlsself_mode.self_tlsdss_sys_db_init //初始化全局系统db打开系统pool及containerbio_register_bulk_ops //注册公共的bulk分配及释放方法//逐个启动xssystem xs main xs helper xsxs是argobots中的概念类比硬件执行单元可以将xs看成是其软件实现通常和硬件执行单元一对一映射如果将xs绑定到特定的core上//system xs包括sys_xs负责系统任务独占一个coreswim_xs负责保活心跳, drpc_xs负责drpc请求swim_xs和drpc_xs共享一个core//main xs每个target一个 main xstarget是daos里面的逻辑设备抽象与spdk中的io_channelnvme qp对应用于提高并行性每个main xs独占一个core//helper xs:用于协助target处理加密压缩等高CPU任务dss_xstreams_init dss_start_xs_id //分配 cpu coredss_start_one_xstreamdss_xstream_alloc //创建xs实例dss_sched_init //创建自定义argobots sheduler设置任务池pool来区分任务优先级网络nvme通用三个池添加到argobots框架的执行单元ULT和tasklet根据该scheduler定义的策略调度ABT_xstream_create_with_rank //创建xs并设置上述的schedulerdaos_abt_thread_create //创建xs的主ULTdss_srv_handler添加到网络池调度执行ABT_cond_wait //等待信号量直到上面的主ULT被调度执行bio_nvme_ctl //设置全局nvme bdev启动状态为BIO_CTL_NOTIFY_STARTED使得后文xs中spdk subsystem初始化及创建的nvme的ULT可以继续执行drpc_listener_init //在 dRPC xs中创建ULT线程启动dRPC监听drpc_notify_ready //向daos_server发起ready就绪通知daos_server会向MS Leader发送JoinSys的gRPC消息向daos_engine回发SetRank和SetUp的dRPC消息server_init_state_wait //等待来自daos_server的init_state更新收到daos_server的SetUp消息后会设置init_state状态为DSS_INIT_STATE_SET_UP//pool:在system xs创建ULT逐个启动各pool启动的pool服务添加到rsvc_hash表//mgmt:创建ULT清理僵尸pool如果有清理未完成pool如果有初始化pooltgts结构用于跟踪创建过程中的pool//dtx:给各main xs创建事务批提交ULTdtx_batched_commit聚合ULTdtx_aggregation_maindss_module_setup_all //安装各模块调用各模块的setup接口安装模块crt_register_event_cb //注册网络事件回调dss_crt_event_cb如groupupdate或者swim状态更新crt_register_hlc_error_cb //注册HLC错误回调dss_crt_hlc_error_cbdss_xstreams_open_barrier //激活utl barrier信号量启动所有的xs// xs的主线程ULTdss_srv_handlerdss_xstream_set_affinity //绑核dss_tls_init //初始化tls与该xs相关的信息会存储在tls中 crt_context_create //如果需要初始化Cart网络上下文sys_xs,swim_xs,main_xs以及每个main_xs的第一个helper_xs会起用网络crt_context_initcrt_hg_ctx_init //根据配置的网络provider初始化HGmercury注册HG rpc handled_tm_add_metric //添加metric指标crt_swim_init //如果是swim_xs初始化swim上下文注册swim回调crt_swim_progress_cb注册rpc handler到opc_mapcrt_context_register_rpc_task //注册rpc句柄dss_rpc_hdlr和dss_iv_resp_hdlrio请求首先由上述注册的HG rpc handle响应然后转发给这里注册的rpc handle做进一步的调度处理最终调用op code的处理函数tse_sched_init //初始化任务调度器bio_xsctxt_alloc //如果需要通常只有main xs才会使用nvme但是如果开启了metadata-on-ssdsys_xs也会第一个xsmain_xs或者sys_xs会根据配置文件初始化所有的spdk subsystem创建blobstore将初始化的bio_bdev设备挂接到nvme_glb全局列表中。给target选择合适的nvme设备(targets循环绑定到已有target数最少的nvme上dev和targets信息持久化到db中)并创建io_channel daos_abt_thread_create //创建ULT添加到nvme池等待argobots调度执行负责nvme设备的状态监测设备的热插拔监测等ABT_cond_signal //激活信号量以便调用线程能继续运行ABT_cond_wait //如果是swim_xs则立即开始后面的循环如果是非swim xs等收到daos_server的dRPC消息setUp后再执行for (;;) //主ULT循环如果该xs开启了Cart网络会调用HGmercury接口推进rpc的调用及回调处理swim xs会执行上述注册的crt_swim_progress_cb进行engine状态探测wait_all_exited //等待所有ULT退出engine退出参考资料
Argobots论文 高性能I/O引擎论文
