存储的控制器冗余与多路径

71 阅读 0 评论 47 点赞

我是靠谱客的博主激动滑板，最近开发中收集的这篇文章主要介绍存储的控制器冗余与多路径，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

1.存储的双控制器冗余

双控冗余有三种方式：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控而又无计可施的尴尬。

2.多路径如何管理发向双控的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。

3.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盘符，而这个盘符底层已经对应了多条路径，这样可以避免盘符层次过多引起的管理混乱。

4.存储的多控制器

至于多控存储系统，一般指分布式多控，也就是多控之间并不是共享访问所有后端JBOD的，富士通的高端存储除外，其后端采用SAS Expander将所有HDD呈现在一个大的SAS域中，富士通是真多控对称式多活。多数实现都是双控共享一堆JBOD，然后多组双控再结合成分布式存储，也就是所谓的”Server SAN，某厂商最近发布的系统其实是4控共享访问后端JBOD，当然，JBOD里只有两片Expander，接不了4控，所以4控和JBOD之间还需要增加两片SAS Expander作为路径扩充使用。由于并非共享式集群而是分布式集群，所以其原本就是非对称式多活了，各个节点或者节点组各管各的磁盘，但是每个控制器节点都可以接受IO，只不过遇到不是给自己管辖磁盘范围的IO则需要转发处理。有些厂商为了维持自己传统高端的共享内存架构的形象，在分布式集群内，实现了全局共享缓存，当然这个共享缓存并非传统高端那种真内存地址空间共享了。而有些则是赤裸裸的分布式架构，逼格直逼ServerSAN。