我试图了解一些SAN基础设施，我希望有更多的经验比我更能帮助我理解SAN的扩展。
想象一下你有一些有HBA的计算机服务器。 它们可以直接连接，也可以通过交换机连接到SAN控制器。 SAN控制器然后提供一个或多个映射到存储设备上最可能的RAIDarrays的LUN。
所以如果我理解正确的话，“控制器”代表了一个性能瓶颈。 如果你需要很多的性能，那么你可以添加更多的控制器连接到自己的存储，然后映射到需要它们的服务器。
我想你可以得到一些非常高性能的控制器，具有巨大的存储容量和性能较低的控制器，最大的性能较低？ 但是，如果你有一个交换机，那么你可以添加几个性能较低的控制器到你的networking，因为你需要它们？
如果我弄错了，请撕开我的理解，但我试图弄清楚如何将HBA从服务器连接到存储器，而不用简单地表示“魔术”。
控制器作为一个性能瓶颈是非常正确的，在某些体系结构中它也可以表示一个单点故障。 这已经有一段时间了。 一段时间以来，针对这个问题的解决scheme都有供应商特定的技术，但从那以后，整个行业已经融合了MPIO或多pathI / O。
通过MPIO，您可以跨存储结构在多个path上呈现相同的LUN。 如果服务器的HBA和存储arrays的HBA每个都有两个到存储结构的连接，则服务器可以有四条到LUN的独立path。 如果存储支持它可以超越这个; 在较大的磁盘arrays系统中使用双控制器设置是非常常见的，每个控制器都提供一个到LUN的活动连接。 使用两个独立的HBA卡添加服务器，以及连接控制器/ HBA对的两条物理上分离的path，您可以拥有一条没有单点故障的存储path。
发烧友控制器确实是一个完整的主动/主动对，两个控制器实际上都在与存储器交谈（通常在控制器之间存在某种forms的共享caching以帮助协调）。 中间层设备可能伪装成主动/主动，但是在任何给定的时间，只有一个设备实际上正在执行工作，但是如果第一个设备静音并且没有I / O操作被丢弃，则备用控制器可以立即启动。 较低层设备处于简单的主动/备用状态，其中所有I / O沿着一条path前进，并且当主动path死亡时仅移动到其他path。
拥有多个主动控制器确实可以提供比单个主动控制器更好的性能。 是的，在控制器后面添加足够的存储系统和足够的快速存储空间，确保所有连接的服务器都能够感知足够的控制器。 一个很好的方法来模拟这个是导致奇偶校验RAID卷不得不重build。
并非所有的系统都能够利用MPIO来使用多个活动path，这还是有点新的。 另外，所有控制器都必须解决的问题之一是确保所有I / O操作都按顺序执行，尽pipeI / Opath和任何控制器接收操作的path。 这个问题变得越来越难控制你添加。 存储I / O是一个基本的序列化操作，并不适用于大规模的并行化。
你可以通过添加控制器来获得一些收益，但是由于所需的复杂性增加，收益迅速消失。
试图团伙低性能设备的问题是软件访问存储的方式的本质。 一个典型的程序将发出一个read请求， read操作的语义要求操作系统为进程提供read的结果。 一般而言，操作系统无法知道接下来要执行的过程或线程。 它可以尝试用readahead来猜测，但并不总是正确的。
所以，如果你尝试使用大量平庸的控制器，那么结果会很高，因为平庸的控制器需要更长的时间才能获得线上的请求并从线上传递请求。 事实上，你有一堆其他控制器闲置不会让你更多的速度。
这里有一些应用程序依赖。 有些工作负载会从很多不同的地方发出大量请求，或者使用asynchronous文件读取API，允许同一个线程在等待完成任何请求之前发出多个请求。 一些应用程序从readahead中获益很大，消除了很多延迟。 但是，如果您想要一个性能良好的通用解决scheme，则需要提供低延迟的控制器，以便在您甚至可以在下一步计算出您需要的数据之前，不等待控制器。