冬瓜哥最近非常忙，没来得及写点东西。忙里偷闲，不能辜负大家的关注。 6 月 10 日在 OpenPower Summit 大会上冬瓜哥代表 PMC 公司现场讲了一下 CAPI ，会后有人反馈说 “ 你讲的才是真干货啊！都在吹 CAPI ，一头雾水，还是你一语道破天机！ ” ，瓜哥听了心里觉得安慰。讲技术，本应如此，纯硬货，纯干货。。现场还有人把我错当成 xi 瓜哥了，冬瓜哥觉得非常气愤，再这样下去，连大话存储都是被 xi 瓜哥写的了，这可不成。闲话少说，本次分享一些存储双控多控双活、多路径方面的知识。
说说双控
搞传统存储系统的人都知道传统存储起码是双控冗余的，两台服务器（高雅点说叫 “ 控制器 ” ）通过后端 SAS 控制器连接到 JBOD 上， JBOD 上通过两片 SAS Expander 分别上连到两台服务器的后端 SAS 控制器，同样，每块磁盘用两条路径上连到每片 Expander （ SAS 接口有两套数据金手指）。双控冗余有三种方式： HA 、互备（非对称双活）、双活（全对称双活）。 HA 模式是指平时只有一个控制器处理 IO ，另一个控制器完全不干活，开着机在那待着转等干活的控制器挂掉，它接管过来，传统存储产品中目前没有人使用 HA 方式因为不划算。目前多数产品为互备模式，或者叫非对称双活，是指每个 Lun 都有自己的 Owner 控制器，比如 A 控处理 Lun1 的 IO ， B 控处理 Lun2 的 IO ，如果 A 控收到发向 Lun2 的 IO ，则通过控制器间交换网络转发给 B 控处理而不能自己私自处理，双控各干各的互不干扰，不会产生冲突， “ 非对称 ” 意思就是 “ 各干各的 ” ，你坏了我接管，我怀了你接管，但是两个控制器都在干活，所以 “ 双活 ” 。而对称双活，则是指两个控制器角色完全对等，不再分 Lun 的 Ownership ，任何控制器都可以处理任何 Lun 的 IO ，这给系统设计带来了复杂性，首先要求双控要配合起来，针对已经应答的目标地址有重叠的写 IO ，要保证时序一致性，双控必须做好沟通保证后应答的 IO 后写入；另外，同时还要解决数据防撕裂问题，有时候阵列内部会自行读或者写某些目标地址数据块，此时双控要用锁来保证每次读写的防撕裂，对某个块的操作可能会被分为多次子 IO ，这些子 IO 是一个一致性组或者说组成一次原子操作，中途不能被交织入其他 IO ，否则就会撕裂导致不一致。正因如此，对称式双活增加了开发难度。但是对称式双活能够以 IO 粒度来平衡系统的负载，不会出现 Lun1 太忙而 Lun2 很闲从而导致 A 控负载远高于 B 控而又无计可施的尴尬。
多路径如何管理发向双控的 IO
存储系统提供了双控冗余，主机端如何利用起双控，要依靠多路径软件。通常主机会与 A 控和 B 控至少各保持一条连接，分别从两个控制器上发现到两份同一个物理 Lun 的两份副本，系统中会生成两个盘符，而多路径软件的功能则是负责链路故障后的路径切换、链路正常时的 IO 负载均衡以及冗余盘符的消除。针对非对称双活，因为有 Lun 的 Ownership 存在，发向对应 Lun 的 IO 要确保走最优路径，也就是不要发送给该 Lun 的非属主控制器，否则将引发内部转发，增加时延，除非在链路带宽达到瓶颈而控制器处理能力未达到瓶颈的时候可以利用这条非最优路径。探测某个 Lun 的最优路径以及其他一些阵列端的运行信息，需要多路径软件与阵列之间做一些信息交互，这些信息可以走带外通道比如以太网，也可以走带内通道也就是数据链路比如 FC/SAS/iSCSI ，通常使用后者，而 SCSI 指令体系内没有针对多路径软件与阵列之间的交互协议做什么规定，所以各个厂商都有自己不同的实现模式，比如通过一些特殊指令序列，或者封装到某些特殊指令内部。正是由于各厂家的交互协议不统一，所以 SCSI 体系最新的规范里定义了 ALUA （ Asymmetric Logical Unit Access ）协议，期望各厂商按照 ALUA 协议规范来实现多路径软件和阵列之间的交互。而对称式多活由于没有 Lun 属主的概念，多路径软件无需与阵列交互复杂的控制数据，最多是控制阵列控制器的切换，所以这块 SCSI 没有定义规范，但是人们俗称对称式多活为 “SLUA” 以与 ALUA 区分， S 标示 Symmetric 。
OS 在多路径问题是怎么演化的？
各种 OS 早期是不提供多路径管理的，后来陆续都被加入了原生的多路径软件，比如 Linux 下的 MPIO ， AIX 下的 MPIO ， Windows 下的 MPIO 等等，这些 OS 自带的多路径软件只提供简单的功能，比如盘符消除，通过识别磁盘的 wwn 来发现哪些盘符指向的是同一个物理 Lun ，从而消掉一个盘符。但是无法提供阵列相关的个性化功能，阵列厂商如果需要满足这些高级功能的话就必须提供自己的多路径软件，将其作为一个插件的形式，挂接到 MPIO 框架之下从而实现高级功能。有些多路径软件会保留原生的盘符，而创建一个新盘符，比如将 /dev/hdisk1 和 /dev/hdisk2 这两个冗余盘符生成一个 /dev/vpath1 盘符，系统中会同时存在这三个盘符，针对 /dev/vpath1 的访问会享受到多路径软件带来的路径自动切换， io 负载均衡等功能，而直接访问 /dev/hdisk1 或者 /dev/hdisk2 也是可以的，就无法享受多路径带来的利益了，一旦 /dev/hdisk1 这条路径 down 掉，这个盘符便会消失，应用比那会停掉。有些多路径软件运行在更底层，会直接生成一个 /dev/hdisk1 盘符，而这个盘符底层已经对应了多条路径，这样可以避免盘符层次过多引起的管理混乱。
多控咋玩的
至于多控存储系统，一般指分布式多控，也就是多控之间并不是共享访问所有后端 JBOD 的，富士通的高端存储除外，其后端采用 SAS Expander 将所有 HDD 呈现在一个大的 SAS 域中，富士通是真多控对称式多活。多数实现都是双控共享一堆 JBOD ，然后多组双控再结合成分布式存储，也就是所谓的 ”Server SAN“ （不过冬瓜哥觉得 Server SAN 这个名字，逼格着实不高，同样还有软件定义，逼格也是低的不可直视），某厂商最近发布的系统其实是 4 控共享访问后端 JBOD ，当然， JBOD 里只有两片 Expander ，接不了 4 控，所以 4 控和 JBOD 之间还需要增加两片 SAS Expander 作为路径扩充使用。由于并非共享式集群而是分布式集群，所以其原本就是非对称式多活了，各个节点或者节点组各管各的磁盘，但是每个控制器节点都可以接受 IO ，只不过遇到不是给自己管辖磁盘范围的 IO 则需要转发处理。有些厂商为了维持自己传统高端的共享内存架构的形象，在分布式集群内，实现了全局共享缓存，当然这个共享缓存并非传统高端那种真内存地址空间共享了。而有些则是赤裸裸的分布式架构，逼格直逼 ServerSAN 。
哎，处在这个乱世，冬瓜哥也不知道说啥好了，就让大家的逼格相互融合，提炼去吧！
（关注“大话存储”公众号，获得最前沿最底层最通俗逼格最高的存储知识。长按识别二维码。）
觉得文章写得好的话，可以给瓜哥点小费：
