Linux中三种SCSI target的介绍之各个target的优劣

版权声明：本文为博主原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接和本声明。

本文链接：https://blog.csdn.net/scaleqiao/article/details/46761993

通过之前的三篇博文，我介绍了目前Linux中广泛使用的三个SCSI target的架构和使用方法。那如何在这三者之间做一个选择呢？这里给出我对它们之间优劣点的总结，欢迎高手指正错误。

1. STGT

在2.6.38之后，STGT默认只剩下用户态的实现，这对于iSCSI target来说，用户态即可满足要求。如果需要iSER等，需要自己将kernel的部分打上。另外从以上功能图表上可以看出，STGT主要专注于iSCSI上。

它的优点是：
1）简单，方便使用和维护；
2）另外已经有ceph的target driver，只是需要做性能优化；
3）因为工作在用户态，所以即使挂掉了，也不会对其他运行的程序产生影响；

它的缺点是：
1）支持的传输协议较少；
2）对SCSI协议支持比较简单，一些cluster中的特性比如PR等都不支持，所以基于stgt的方案不能在cluster中使用；
3）对于多initiator访问同一target的场景，性能表现不好，这个主要是因为tgt的实现所致，即它目前的策略是针对一个lun创建16个线程处理IO。不过可以通过one lun per target的方案解决；

2. SCST

SCST的核心模块工作在内核里，可以支持通过系统模块（VFS、块层）访问的后端存储如块设备、文件设备以及passthrough的scsi设备。对于通过library库访问的ceph
rbd以及glusterfs等后端存储，SCST也提供了一个模块scst_user，不过你得自己写插件。

它的优点是：
1）支持更多传输协议
2）针对性能做了特殊的优化
3）除了基本的SCSI协议支持外，还有一些高级支持：
SCST支持永久性预留（Persistent Reservation, PR）；这是一个用于高可用集群中的存储设备的 I/O
隔离与存储设备故障切换、接管的特性。通过使用 PR 命令，initiator 可以在一个 target
上建立、抢占、查询、重置预留策略。在故障接管过程中，新的虚拟资源可以重置老的虚拟资源的预留策略，从而让故障切换更快、更容易地进行。
SCST 可以使用异步事件通知（AEN）来通告会话状态的变更。AEN 是一个 SCSI target 用来向 initiator 进行
target 端的事件告知的协议特性，即使在没有服务请求的时候也可以进行。于是 initiator 就可以在 target
端发生事件时，如设备插入、移除、调整尺寸或更换介质时，可以得到通知。这让 initiator 可以以即插即用的方式看到 target 的变化。
4）SCST 的开发者声称，它们的设计在健壮性和安全性方面更加符合 SCSI 标准。SCSI 协议要求，如果一个 initiator
要清除另一个 initiator 的预留资源时，预留者必须要得到清除通知，否则，多个 initiator
都可能来改变预留数据，就可能会破坏数据。SCST 可以实现安全的预留、释放操作，避免类似事情发生。
5）SCST 也支持非对称逻辑卷分配（ALUA）。ALUA 允许 target 管理员来管理 target
的访问状态和路径属性。这让多路径路由机制可以选择最好的路径，从而根据 target
的访问状态，优化带宽的使用。换句话说，在多路径环境下，target 管理员可以通过改变访问状态来调整 initiator 的路径。
6）各大存储服务提供商都是基于SCST。
7）提供更细粒度的访问控制策略以及QoS保证机制（限制initiator连接的个数）。

它的缺点是：
1）结构复杂，二次开发成本较高。
2）工作在kernel，如果挂了，会导致整个机器down掉，影响其他程序。
3）kernel部分没有并入linux，需要手工编译。

关于scst_user，这里多说一点它的工作原理。它在内核创建一个字符设备作为用户态存储和SCST内核模块之间的接口，通过IOCTL，用户态存储可以向SCST注册一个块设备以及进行IO。当然就我了解到的情况是，你要扩展scst_user对你的存储的支持，你只能自己搞，目前没有任何案例可以参考，只有一个接口spec文档：
http://scst.sourceforge.net/scst_user_spec.txt

3. LIO

LIO的核心模块也工作在内核，和SCST一样即支持通过内核模块访问的后端存储，也支持通过library访问的分布式存储，对应的模块是TCMU。这个模块已经在3.17并入linux内核里了，可以参考它的设计文档：
https://www.kernel.org/doc/Documentation/target/tcmu-design.txt

优点：
1）支持较多传输协议
2）代码并入linux内核，减少了手动编译内核的麻烦。
3）提供了python版本的编程接口rtslib。
4）LIO在不断backport SCST的功能到linux内核，社区的力量是强大的。
5）LIO也支持一些SCST没有的功能。

LIO 还支持“会话多连接”（MC/S）。MC/S 让 initiator 可以和
target 在一条或多条物理路径上建立多条连接。这样，在一条路径发生错误的时候，已经建立好的会话可以不中断会话，直接使用其他的路径。MC/S
还可以用来进行所有连接之间的负载均衡。这种情况下，会在所有通信路径上保持会话命令的顺序性。
不过我觉得MCS是一个比较鸡肋的feature，因为现在Linux内核已经有Device Mapper的支持。
6）LIO支持最高级别的ERL。iSCSI
连接的错误可能会发生在三个层面上：会话、校验或是连接层。错误恢复工作也可以在这三个层面开始进行，这样就可以在当前的层面开始进行恢复，不会让错误到达下一个层面。错误恢复首先是检查断开的连接。在这种情况下，iSCSI
initiator 驱动会主动建立新的到 target 的 TCP 连接它会告诉 target，SCSI 指令路径已经变到新的连接上了。这样
target 就可以在新的连接上处理 SCSI 命令了。这时，上层的 SCSI
驱动对新的连接已经建立、控制信息已经通过新连接传输的事还是毫无知觉的。iSCSI
会话在这期间会保持正常，不会重新变换状态。LIO
支持的最大错误恢复级别（ERL）为2，这就是说，它可以在会话、校验或连接层进行错误恢复。而SCST 支持的 ERL 为
0，也就是说，它智能恢复会话级别的错误，所有连接层面的错误都会转到 SCSI 驱动层面来处理。

缺点：
1）不支持AEN，所以target状态发生变化时，只能通过IO或者用户手动触发以检测处理变化。
2）结构相对复杂，二次开发成本较高。
3）工作在内核态，出现问题会影响其他程序的运行。

4. 总结

总的来说，如果你的需求只是构建一个iSCSI target，并且规模不是很大，stgt是一个不错的选择。
如果你要构建一个企业级的存储方案，即高性能、高稳定性的，并且围绕这个有长远计划的，本人觉得SCST是正确的选择。
如果你对性能、稳定性要求不是那么高，但又想支持FC、SRP等协议，你可以选择LIO。