Cinder是OpenStack中的一个项目，主要用于块存储。比如，Glance需存储的镜像、Nova所启动的虚拟机的Guest disk、以及虚拟机所attach的volume一般都是来源于Cinder的提供。而世界上有很多存储厂商，也有很多的存储技术（如Ceph、iSCSI、Fiber Channel等等），其中涉及到块存储的也很多，那么Cinder如何选择使用哪一家厂商的哪一种块存储硬件和技术呢？这就是通过设定Cinder driver来实现的了。比如，某家厂商出售某种其特有的块存储的硬件设备，那么它就希望在Cinder项目中添加一种专门的driver来支持它的块存储硬件了。因此，你可以在Cinder的项目中看到有IBM、HPE、Dell、Lenovo等等厂商的driver。
以上就是背景了。下面将介绍3种Cinder driver的架构。

Ceph RBD driver

Ceph作为一种开源的分布式的非常流行的存储技术，支持对象存储、块存储和文件存储。（其中，文件存储可能还不太成熟，暂不建议使用到生产环境中）作为Ceph的块存储来说，其有多种对外暴露的形式，比如：可以通过librbd接口暴露出去，也可以通过iSCSI gateway的方式暴露出去。这2种方式都可以是远程的，即使用者在Ceph集群之外，通过网络连接使用RBD image. (RBD即RADOS Block Device， 而RADOS即 Reliable Autonomic Distrubuted Object Storage.)
针对其中通过librbd这种方式，在Cinder中早已提供了Ceph RBD driver. 其架构图如下：

注意：
在这个架构中，首先，cinder-volume service通过Ceph RBD driver（其通过os-brick模块）调用Ceph的命令，而Ceph命令的实现会调用librbd和librados，从而完成了控制面的功能，比如create volume、create snapshot等。Ceph RBD driver其实就是一个Ceph client. 另外，虚拟机也是作为一个Ceph client存在的。因为Qemu进程（即虚拟机）向下调用librbd，进而调用librados，从而和远端的Ceph cluster建立了data panel的连接。

Lenovo iSCSI driver

Cinder中的iSCSI driver有很多。我们仅以Lenovo iSCSI driver为例。Lenovo iSCSI driver虽然继承了dothill的driver，但并不影响其清晰的架构：

从上面的架构图可以看出，Cinder的Lenovo iSCSI driver仍然负责的是control panel的连接。
注意，
在这个iSCSI driver的架构图中，虚拟机充当了一个iSCSI initiator的角色，它和Lenovo的SAN存储（通过iSCSI接口外联）之间需要建立一个iSCSI的连接。
当我们创建一个volume的时候，走的是Lenovo iSCSI driver所在的control panel的通路，即该driver发送了“/create/volume”的REST API告诉Lenovo的SAN存储，“我需要创建一个volume”，此时尚不会有iSCSI连接建立起来；
而当我们执行“nova volume-attach”命令的时候，nova的manager自libvirt开始，通过层层调用到Cinder的Lenovo iSCSI driver的时候，该driver向Lenovo SAN存储发送"/map/volume"的REST API让其做Host Map，同时也将iSCSI连接建立起来。

Ceph iSCSI driver

现在回到第一个driver. 既然Ceph可以通过iSCSI接口将RBD image暴露出来，那么能不能有一个Ceph iSCSI driver来帮助Cinder利用Ceph通过iSCSI gateway暴露出来的RBD image呢？关于Ceph iSCSI gateway的知识，请参见拙作。
理论上，当然是可以的。但是现实中，却是比较困难的。原因如下：
我们都知道，Ceph iSCSI gateway既是Ceph client，也是iSCSI target. 这就造成了Compute节点只可能是iSCSI Initiator，而不会再是Ceph client；虚拟机也不是Ceph client. 不是Ceph client就意味着和librbd以及llibrados都无缘了，不需要再用到它们。而作为iSCSI initiator，也就决定了data panel这边，只能是通过iSCSI连接走了。但是，Control panel呢？通过分析，我们发现，在Ceph iSCSI gateway上，缺少了一个daemon或者是一个web service，用来接收和处理control panel的请求，比如创建一个volume，创建一个snapshot，等等。这可能也正常，因为毕竟Ceph iSCSI gateway刚刚于Ceph的Luminous版本刚推出来，时间还不长。但是，对于创建一个Cinder的Ceph iSCSI driver就很困难了。-- 我们总不能让Cinder driver通过ssh连到gateway上执行gwcli命令吧？这对于安全性就无法忍受；另外要解析gwcli的执行结果也比较麻烦，因为其格式也不规则。
假设在Ceph iSCSI gateway上有一个daemon或web service能够用来接收和处理控制平面的请求，那么理想中的Ceph iSCSI driver的架构图如下：

以上是个人的一点粗浅理解。
（完）