Ceph iSCSI Gateway：架构原理详解

为什么Ceph需要iSCSI？

Ceph架构

Ceph官方https://docs.ceph.com/en/pacific/architecture/给出的基本架构如下图所示：

• RADOS：为Ceph的核心，是Ceph最底层架构。具有可靠、分布式等特性，提供ceph系统高可靠、高可拓展、高性能。用户数据最终通过这一层来存储数据到磁盘。
• LIBRADOS：为RADOS层的上一层，LIBRADOS是一个库，它允许应用程序通过访问该库来与RADOS系统进行交互，支持多种编程语言，比如C、C++、Python、Ruby和PHP等。
• RADOSGW + RBD + CEPH FS：为上层应用提供三种不同的接口。
  • RADOSGW：提供了两种类型的API，一种是和AWS的S3接口兼容的API，另一种是和OpenStack的Swift对象接口兼容的API。
  • RBD：通过librbd库提供了块存储访问接口。RBD通过Linux内核客户端和QEMU/KVM驱动来提供一个分布式的块设备。它可以为虚拟机提供虚拟磁盘，或者通过内核映射为物理主机提供磁盘空间。
  • CEPH FS：目前提供两种接口，一种是标准的posix接口，另一种通过libcephfs库提供文件系统访问接口。文件系统的元数据服务器MDS用于提供元数据访问。数据直接通过librados库访问。

Ceph在应用场景的局限性

局限有哪些？

Ceph虽然提供了RBD、RGW、CephFS三种应用服务，可以支持大部分应用场景和需求，但一部分特定场景仍需要解决。

• 兼容性：基于IP/FC-SAN的遗留应用程序需要，这些应用程序针对VMware（70%+），Hyperv，Xen等。
• 高级特性：（1）Multipath & load balance (Active/Active)，（2）VMware VAAI (vStorage APIs for Array Integration)，（3）Windows ODX (Offloaded Data Transfer)。

为什么存在局限？

局限原因：上述场景需要提供块接口支持，而RBD虽然有librbd和KRBD两种方式，但仍有如下限制。

• Librbd用户态接口，普通应用不能直接使用，需要适配Librbd提供的接口，客户经常用到的VMWare EXSi、Windows/Solaris操作系统是无法直接对接librbd，导致兼容性上的局限。
• KRBD通过rbd map方式将image在客户端映射成本地块设备，虽然在兼容性上有提高，但只能部署在linux高内核版本系统，上面兼容性部分场景仍无法满足。
• Multipath等高级特性也无法直接对接rbd image，但KRBD在不同客户端映射的本地块设备也是不同的wwn，因此也无法支持。

如何解决局限？

上面Ceph无法满足的特性场景在业界解决的通用方法就是使用iSCSI。块接口与SCSI块设备读写所要求的接口也比较一致，可以使用RBD作为SCSI 存储系统后端。因此在Ceph的基础上提供对接iSCSI能力就成为解决上面问题的最好方案。

什么是iSCSI？

SCSI

小型计算机系统接口（Small Computer System Interface；简写：SCSI），一种用于计算机和外部设备之间（硬盘、光驱、软驱、打印机等）系统级接口的独立处理器标准。SCSI是一种智能的通用接口标准，它是各种计算机和外部设备之间的接口标准。其发展历程可参考SCSI维基百科。

客户端-服务器架构

下面部分内容参考：iSCSI存储和存储多路径介绍

• 客户端（initiator）：通过SCSI通道向target发送请求。
  • 用CDB(Command Descriptor Blocks)的数据结构封装请求
  • 必须包括一个SCSI Port，和一个能发起请求的客户端
• 服务器（target）：通过SCSI通道向initiator发送响应
  • 任务分发器：负责将客户端的请求分到到适当的逻辑单元
  • 逻辑单元：真正处理任务的实体，包含任务管理器和真正响应请求的服务器
• SCSI通道：连接的是SCSI Port，SCSI initiator port和SCSI target port

SCSI约束

SCSI的约束在于SCSI通道，包括线缆长度、链接设备等，比如2003年发布的SCSI-3，其线缆长度为10m，设备数为16。

iSCSI

为了解决上面的约束。iSCSI发展起来了，iSCSI的本质还是对SCSI通道进行了优化。
iSCSI（Internet Small Computer System Interface），Internet小型计算机系统接口，又称为IP-SAN，是一种基于因特网及SCSI-3协议下的存储技术，由IETF提出，并于2003年2月11日成为正式的标准。与传统的SCSI技术比较起来，iSCSI技术有以下三个革命性的变化：

• 把原来只用于本机的SCSI协议透过TCP/IP网络发送，使连接距离可作无限的地域延伸；
• 连接的服务器数量无限（原来的SCSI-3的上限是15）；
• 由于是服务器架构，因此也可以实现在线扩容以至动态部署。
  其详细定义参考 iSCSI维基百科。

客户端-服务器架构

【客户端（initiator）】->【SCSI】->【iSCSI】->【TCP/IP network】->【iSCSI】->【SCSI】->【服务器（target）】

• 客户端（Initiator）
  • SCSI层：负责生成CDB，将CDB传给iSCSI。
  • iSCSI层：负责生成iSCSI PDU（含CDB），并通过IP网络将PDU发给target。注意，iSCSI层并不知道CDB的内容，只是简单的将整个CDB封装在PDU中。
• 服务端（Target）
  • iSCSI层：收到PDU，将CDB传给SCSI层。
  • SCSI层负责解释CDB的意义。必要时发送响应。

iSCSI的优势

在SCSI通道上有多种解决方案，比如使用光纤的FC等，iSCSI的优势在于如下方面：

• 数据传输：TCP/IP协议，运行于以太网之上，TCP/IP兼容性好。
• 传输速度：千兆以太网正在普及，成本较低。
• 网络管理：TCP/IP网络已经普及，有大量管理人才。

Ceph iSCSI Gateway架构介绍

客户端-服务器架构

Ceph架构与iSCSI架构相结合，就得到了Ceph iSCSI Gateway基本架构。

客户端（Initiator）

直接支持iSCSI的initiator，终端用户不用做任何改变，仍然继续使用原有的 iSCSI 系统或设备，所有的修改都在服务端即 ceph 集群侧进行。可以直接对接虚拟化系统。

服务端（Target）

服务端包含了iSCSI Gateway（GW）和RBD Module。RBD Module由librbd提供接口实现对image（卷/lun）的操作。iSCSI Gateway（iSCSI target）接收到SCSI命令字有进行解析，并调用RBD接口实现命令字的操作。

Target架构选择

现有的开源target架构主要有STGT、IET、SCST方式，但都在某些场景有不足，Ceph使用了LIO-TCMU的方式，下面是几种实现方式对比。下文参考https://blog.csdn.net/shuningzhang/article/details/90177872，并进行总结归纳。

STGT（SCSI target）

• 简介：一个用户态的 SCSI target 框架，对集成同在用户态的 RBD 接口是非常简单的。作为用户态框架，不可避免的就是性能问题，根据网上的相关数据，tgt 在使用本地存储的情况下，性能相比后面会提到的 IET、LIO 等是有一定差距的，如果从性能的角度考虑，tgt 应该是不推荐使用的，但在新特性验证等方面是很合适的。
• 实现：用户态
• 性能：最弱
• 缺陷：内核态到用户态内存拷贝性能瓶颈。

IET（iSCSI Enterprise Target ）

• 简介：IET 是 iSCSI Enterprise Target 的缩写，是一个纯粹的 iSCSI target 实现。实现分两部分， iSCSI 登录阶段的处理在用户态处理，然后 iSCSI 全特征阶段由于主要是数据的读写操作，对性能要求比较高，所以都放在内核态以内核驱动的形式实现。由于数据读写部分在内核态，但 RBD 接口在用户态，因此需要有一种机制将内核态的读写请求转发到用户态然后再由用户态 RBD 接口处理，目前比较流行的方法是使用 UIO，因此这里可以将读写命令进行封装然后提交给用户态程序调用 RBD 接口进行处理。
• 实现：用户态 + 内核态
• 性能：较强
• 缺陷：通过UIO途径，理论上是能够解决内核态调用用户态接口的问题的，但需要开发用户态驱动仍然不是一件非常容易的事情，因此不推荐。

SCST（SCSI target subsystem）

• 简介：代码继承自 IET，也分用户态和内核态两部分，不过由于已经扩展成一个 SCSI target 框架，因此功能远远比 IET 丰富，有多种前后端支持。实际上当时 SCST 是与 LIO 一起竞争进入 GNU/Linux 内核的，只是后来 SCST 失败了。SCST 支持用户态后端，而且根据其官方说明，相比纯内核态实现只有万分之一数量级的性能损失，因此实际上也就是说前面提到的 IET 需要自己实现的用户态驱动 SCST 框架已经实现了。
• 实现：用户态 + 内核态
• 性能：很强
• 缺陷：未进入内核。

LIO + TCMU

• 简介：是目前 GNU/Linux 内核自带的 SCSI target 框架（自 2.6.38 版本开始引入，真正支持 iSCSI 需要到 3.1 版本），对 iSCSI RFC 规范的支持非常好，包括完整的错误恢复都有支持。整个 LIO 是纯内核态实现的，包括前端接入和后端存储模块，为了支持用户态后端，从内核 3.17 开始引入用户态后端支持，即 TCMU(Target Core Module in Userspace)，TCMU 基于前面所提到的 UIO，其最初的设计目标就是为了支持用户态的 RBD、gluster 等，因此如果需要 LIO-TCMU 支持用户态 RBD，只需要设计用户态应用程序即可。 目前在 github 上已经有红帽的开发者写了一个 TCMU 的用户态程序框架，其设计目的是让用户态存储后端开发人员只需要开发相关的插件（即动态库）即可，由框架自动调用相关的插件处理 SCSI 命令。
• 实现：用户态 + 内核态
• 性能：很强

Ceph iSCSI Gateway模块设计

数据面（IO流程）：LIO + tcm-user + UIO + tcmu-runner

模块架构

下文参考并总结归纳。

模块及模块间交互概述

• LIO（Linux-IO）
  • LIO是内核态target实现，也称作target_core_mode（TCM），运行在内核态。包含了多种backstore，为不同的SCSI传输协议提供了组件，包括文件（target_core_file）、块设备（target_core_iblock）、RAMDISK（target_core_rd）、其他iSCSI设备（target_core_pscsi）等。
  • LIO接收initiator发的iSCSI命令，处理完成后将结果通过TCP/IP将结果发送到initator。
• TCMU（target_core_user）
  • LIO的用户态实现，即TCM-user，用来使TCM的兼容性和扩展性，虽然叫user但运行在内核态。
  • 通过ringbuffer存放命令字及其数据。并将ringbuffer放入UIO共享内存，实现与用户态TCMU-runner的交互。
• UIO
  • 实现了mmap()可以处理物理内存(physical memory)，逻辑内存(logical memory)，虚拟内存(virtual memory)。用来存储TCMU的ringbuffer数据，实现TCMU和TCMU-runner的共享内存通信。
• TCMU-runner
  • 运行在用户态，通过uio设备实现与TCMU通信，获取需要处理的命令字和数据。
  • 针对不同的backend（如librbd、libglfs等）提供了统一的管理框架。将每一种后端存储当做一个tcmu_handler，编译后会产生每一种后端存储的一个动态lib库，这些动态lib库安装在TCMU编译时某个指定的路径下。
  • 以ceph rbd为例，通过调用rbd的相关接口如write、read、discard等处理命令字。
  • 命令字处理完成后将结果填写到ringbuffer。

命令字处理流程

• 客户端initiator：接受到用户下发的SCSI命令字后，通过内核将数据通过TCP/IP发送到服务端内核。
• 服务端内核：接受到命令字后解析，交给LIO处理。
• 服务端内核LIO：将命令字解析后，识别需要处理的模块，将命令字和数据传递给TCMU。
• 服务端内核TCMU：将命令字和数据UIO的共享内存。
• 服务端UIO：建立内核TCMU和用户态TCMU-runner的共享内存passthrough机制。
• 服务端用户态TCMU-runner：从UIO共享内存中读取命令字和数据，根据命令字，调用librbd接口处理。完成后将结果写入UIO共享内存。
• 服务端内核TCMU：识别到有命令字处理完成，将结果返回LIO，并通过TCP/IP逐步将结果发回客户端。

配置工具：ceph-iscsi

Ceph iSCSI gateway包括gwcli、ceph-target-api、ceph-target-gw配置组件。

gwcli

• 通过CLI命令，可以创建、配置iSCSI target、RBD images和gateway。其实现方式是调用rtslib组件，通过LIO暴露在用户态的sysfs接口/sys/kernel/config/target创建、配置iSCSI target。
• 将类似iSCSI配置信息作为metadata存储在rbd pool中，这样配置信息就可以被多个ceph iSCSI gateway节点共享，ceph iSCSI gateway节点可以是单独的机器节点，也可以是与ceph osd所在的机器节点，gwcli能够同时管理多个ceph iSCSI target节点。

ceph-target-api

• 作为一个daemon，负责gateway重启或断电重启后target、gateway等资源的恢复，并监控rbd pool中配置信息的变化。
• 对外提供创建、查询、配置target、gateway等资源的rest api服务。

ceph-target-gw

• 作为另一个daemon，对外提供收集target、gateway等资源信息的rest api服务，尤其是Prometheus。
• Prometheus包括了网关、用户、卷的性能统计，其来源于内核SCSI的性能统计。

扩展阅读

Ceph iSCSI Gateway：Multipath支持
Ceph iSCSI Gateway：tcmu-runner代码原理详解

参考文献

Ceph官方文档
SCSI维基百科
iSCSI维基百科。
redhat tcmu介绍PPT。
H3C iSCSI介绍
target实现方式对比。