iscsi target tgt架构

简介: tgt是用户态实现的iscsi target,而iet(iscsi enterprise target)是在内核态实现的target,tgt相比于iet来说,因为其用户态实现,方便调试,新加入一些功能等,不过性能相比iet来说要稍差一点。

tgt是用户态实现的iscsi target,而iet(iscsi enterprise target)是在内核态实现的target,tgt相比于iet来说,因为其用户态实现,方便调试,新加入一些功能等,不过性能相比iet来说要稍差一点。下面就介绍一下tgt的程序框架(略过iscsi协议解析处理部分),以便于整体把握tgt的代码,方便后续的一些修改。

1.整体框架

这里借用tgt官网给出的一张图。

 

tgt中命令的操作,与initiator端的通信都是通过epoll来实现的,下面分别对这两部分进行说明。

1.1 tgtadm与tgtd的交互

在启动tgtd进程的时候,就会初始化一个unix socket,将该fd加到epoll中,监听EPOLLIN事件,后续每执行一条tgtadm命令,就会使用这个unix socket来和tgtd通信。

 

如图所示,当在命令行里敲一条tgtadm命令时,通过unix socket发起请求,就会触发epoll 的EPOLLIN事件,tgtd端accept,将连接fd加到epoll中,并注册回调函数mtask_recv_send_handler,返回连接建立的响应给tgtadm端,然后tgtadm命令触发EPOLLIN事件,tgtd端调用mtask_recv_send_handler,根据不同的mode调用不同的处理函数进行处理(这里有sys_mgmt/target_mgmt/portal_mgmt等),处理完后,将事件改为EPOLLIN|EPOLLOUT,然后发送响应给tgtadm端。

1.2 initiator与tgtd的交互

tgtd进程在启动的时候就会创建一个socket,用于监听initiator的请求(具体是iscsi_tcp_init_portal函数中的处理),将该socket加到epoll中,注册回调函数accept_connection。 initiator端的请求到来时,将新连接的fd加到epoll中,并注册回调函数iscsi_tcp_event_handler,然后当收到EPOLLIN事件时,会调用iscsi_rx_handler进行iscsi请求的一些解析处理操作,并调用backing store的接口进行io的操作,操作完成后,修改事件为EPOLLLOUT,就会触发调用到iscsi_tx_handler来发送响应给initiator。

 

1.3 函数调用栈

下面给出了iscsi_rx_handler的一些函数调用栈关系,其中涉及到与backing store中io处理接口的调用关系。给出下图作为参考。

 

2. backing store

tgt支持多种后端存储,比如rdwr,aio,sg,rbd,sheepdog等,默认的是rdwr,可以指定flag(O_SYNC|O_DIRECT)。了解清楚tgt的后端存储的处理模式,就可以添加新的后端存储用于支持自定义的功能。

 

其中主要的接口就是bs_open,bs_init,bs_cmd_submit,bs_close,bs_exit。 bs_open和bs_init就是做创建lun时的一些初始化操作,比如打开设备文件,创建处理现线程,注册处理回调函数等。 bs_cmd_submit:io请求到来时就会调用该函数进行处理。 bs_close和bs_exit就是删除lun的时候做一些销毁操作。 BS中支持同步和异步io两种模式(rdwr就是同步的,aio就是异步的),下面分别介绍这两种模式。

2.1 同步io

 

在同步io中,每个lun都会对应一个请求队列(pending_list),在bs_init时就会创建多个线程(目前新版本一个lun默认16个线程)。新请求到来时,调用bs_cmd_submit将请求添加到pending_list中,多个线程共享这个pending_list,分别从pending_list中取请求来进行处理。当没有请求时,这些线程就会等待在pending_list上,有新请求加入到pending_lsit后,就会唤醒等待的线程来进行处理。

2.2 异步io(aio)

tgt使用的是linux native aio来实现的,使用eventfd创建的fd将aio上下文和epoll联系起来。(具体可以参考aio与epoll结合起来如何使用的一些资料)。下面是一些具体的处理逻辑。

1)bs_aio_open:io_setup建立异步io上下文,然后afd=eventfd() ,将afd加到epoll中(回调函数bs_aio_get_completions) ,并且afd与aio的上下文关联。

2)bs_aio_cmd_submit:IO到来时调用,先把请求加到cmd_wait_list中,然后遍历list,确定此次能提交的io数并初始化iocb(因为限制了aio的最大处理个数为128,有些io还在处理中,当前提交的aio个数就有限),然后使用io_submit提交一批异步io。

3)IO处理完后,会通过afd触发EPOLLIN事件,调用回调函数bs_aio_get_completions进行处理,先read出当前完成的io数,然后调用io_getevents()获取出已完成io的信息,然后对每个完成的io调用bs_aio_comlete_one做一些结束的处理(修改处理状态),在这个函数中调用target_cmd_io_done,在target_cmd_io_done中会修改epoll的事件为EPOLLIN|EPOLLOUT,这样就会触发了EPOLLOUT事件,调用iscsi_tcp_event_handler,在这个函数里判断如果是EPOLLOUT,就会调用iscsi_tx_handler来发送响应。

 

3. 参考资料

http://stgt.sourceforge.net/ 
http://www.lenky.info/archives/2013/01/2183    

转载:

http://www.sysnote.org/?p=170

相关文章
|
6月前
|
存储 缓存 运维
ISCSI详解(三)——ISCSI原理和架构
ISCSI详解(三)——ISCSI原理和架构
275 2
|
存储
iscsi target IET架构
IET(iSCSI Enterprise Target)是内核态实现的iscsi target,相比于用户态实现的target(比如tgt),iet比较稳定,并且也算是历史悠久,io都直接经过内核态,性能比较好。
1250 0
|
13天前
|
缓存 负载均衡 JavaScript
探索微服务架构下的API网关模式
【10月更文挑战第37天】在微服务架构的海洋中,API网关犹如一座灯塔,指引着服务的航向。它不仅是客户端请求的集散地,更是后端微服务的守门人。本文将深入探讨API网关的设计哲学、核心功能以及它在微服务生态中扮演的角色,同时通过实际代码示例,揭示如何实现一个高效、可靠的API网关。
|
11天前
|
Cloud Native 安全 数据安全/隐私保护
云原生架构下的微服务治理与挑战####
随着云计算技术的飞速发展,云原生架构以其高效、灵活、可扩展的特性成为现代企业IT架构的首选。本文聚焦于云原生环境下的微服务治理问题,探讨其在促进业务敏捷性的同时所面临的挑战及应对策略。通过分析微服务拆分、服务间通信、故障隔离与恢复等关键环节,本文旨在为读者提供一个关于如何在云原生环境中有效实施微服务治理的全面视角,助力企业在数字化转型的道路上稳健前行。 ####
|
12天前
|
Dubbo Java 应用服务中间件
服务架构的演进:从单体到微服务的探索之旅
随着企业业务的不断拓展和复杂度的提升,对软件系统架构的要求也日益严苛。传统的架构模式在应对现代业务场景时逐渐暴露出诸多局限性,于是服务架构开启了持续演变之路。从单体架构的简易便捷,到分布式架构的模块化解耦,再到微服务架构的精细化管理,企业对技术的选择变得至关重要,尤其是 Spring Cloud 和 Dubbo 等微服务技术的对比和应用,直接影响着项目的成败。 本篇文章会从服务架构的演进开始分析,探索从单体项目到微服务项目的演变过程。然后也会对目前常见的微服务技术进行对比,找到目前市面上所常用的技术给大家进行讲解。
28 1
服务架构的演进:从单体到微服务的探索之旅
|
9天前
|
消息中间件 监控 安全
后端架构演进:从单体到微服务####
在数字化转型的浪潮中,企业应用的后端架构经历了从传统单体架构到现代微服务架构的深刻变革。本文探讨了这一演进过程的背景、驱动力、关键技术及面临的挑战,揭示了如何通过微服务化实现系统的高可用性、扩展性和敏捷开发,同时指出了转型过程中需克服的服务拆分、数据管理、通信机制等难题,为读者提供了一个全面理解后端架构演变路径的视角。 ####
27 8
|
10天前
|
Cloud Native 安全 API
云原生架构下的微服务治理策略与实践####
—透过云原生的棱镜,探索微服务架构下的挑战与应对之道 本文旨在探讨云原生环境下,微服务架构所面临的关键挑战及有效的治理策略。随着云计算技术的深入发展,越来越多的企业选择采用云原生架构来构建和部署其应用程序,以期获得更高的灵活性、可扩展性和效率。然而,微服务架构的复杂性也带来了服务发现、负载均衡、故障恢复等一系列治理难题。本文将深入分析这些问题,并提出一套基于云原生技术栈的微服务治理框架,包括服务网格的应用、API网关的集成、以及动态配置管理等关键方面,旨在为企业实现高效、稳定的微服务架构提供参考路径。 ####
35 5
|
13天前
|
监控 API 微服务
后端技术演进:从单体架构到微服务的转变
随着互联网应用的快速增长和用户需求的不断演化,传统单体架构已难以满足现代软件开发的需求。本文深入探讨了后端技术在面对复杂系统挑战时的演进路径,重点分析了从单体架构向微服务架构转变的过程、原因及优势。通过对比分析,揭示了微服务架构如何提高系统的可扩展性、灵活性和维护效率,同时指出了实施微服务时面临的挑战和最佳实践。
34 7
下一篇
无影云桌面