我正在尝试了解一些 SAN 基础设施，并希望一些比我更有经验的人可以帮助我理解使用 SAN 进行扩展。
假设您有一些带有 HBA 的计算机服务器。它们直接或通过交换机连接到 SAN 控制器。然后，SAN 控制器提供一个或多个 LUN，这些 LUN 最有可能映射到存储设备上的 RAID 阵列。
所以如果我理解正确的话，“控制器”代表着性能瓶颈。如果您需要大量性能，那么您可以添加更多控制器，这些控制器可以连接到自己的存储，然后映射到需要它们的服务器上。
我想您可以获得一些具有巨大存储容量的高性能控制器和具有较低最大性能的低性能控制器？但是如果您有交换机，那么您可以根据需要向网络添加几个低性能控制器吗？
如果我理解错了，请仔细分析一下，我正在尝试弄清楚如何将 HBA 从服务器连接到存储，而不需要仅仅代表“魔法”的结构。
答案1
控制器作为性能瓶颈是千真万确的，在某些架构中，它也可能代表单点故障。这一点已经为人所知有一段时间了。有一段时间，有针对此问题的供应商专用技术，但从那时起，整个行业已经融合到了一种称为 MPIO（即多路径 I/O）的技术上。
使用 MPIO，您可以在存储结构的多条路径上呈现相同的 LUN。如果服务器的 HBA 和存储阵列的 HBA 各自与存储结构都有两个连接，则服务器可以有四条通往 LUN 的独立路径。如果存储支持，它可以超越这一点；在较大的磁盘阵列系统中，双控制器设置很常见，每个控制器都与 LUN 呈现活动连接。添加一台具有两个独立 HBA 卡的服务器，以及连接控制器/HBA 对的两条物理上独立的路径，您就可以拥有一条没有单点故障的存储路径。
更高级的控制器实际上是一个完整的主动/主动对，两个控制器实际上都在与存储通信（通常控制器之间有某种形式的共享缓存来帮助协调）。中间层设备可能假装是主动/主动的，但实际上在任何给定时间只有一个设备在执行工作，但如果第一个设备沉默并且没有 I/O 操作被丢弃，备用控制器可以立即接手。较低层设备处于简单的主动/备用状态，其中所有 I/O 都沿着一条路径进行，并且只有在活动路径死亡时才移动到其他路径。
拥有多个活动控制器确实可以提供比单个活动控制器更好的性能。是的，添加足够多的系统访问存储并在控制器后面添加足够多的快速存储，您确实可以使控制器饱和到所有连接的服务器都会注意到的程度。模拟这种情况的一个好方法是导致奇偶校验 RAID 卷必须重建。
并非所有系统都能利用 MPIO 来使用多个积极的路径，这仍然有点新。此外，所有控制器必须解决的问题之一是确保所有 I/O 操作都按顺序提交，无论 I/O 进入的路径是什么，也无论哪个控制器接收了操作。添加的控制器越多，这个问题就越难解决。存储 I/O 是一种从根本上串行化的操作，与大规模并行化配合得不好。
您可以通过添加控制器来获得一些收益，但是，由于使其完全工作所需的复杂性增加，这些收益会迅速消失。
答案2
尝试将低性能设备组合在一起的问题在于软件访问存储的方式的性质。典型的程序会发出请求read，操作的语义read要求操作系统向进程提供操作的结果read。通常，操作系统无法知道该进程或线程接下来想要什么。它可以尝试使用预读进行猜测，但并不总是正确的。
因此，如果您尝试使用大量普通控制器，最终会面临高延迟，因为普通控制器需要更长的时间才能将其请求发送到网络并从网络中传递出去。事实上，您有一大堆其他控制器处于空闲状态并不能提高速度。
这里存在一些应用程序依赖性。一些工作负载从许多不同的地方发出大量请求，或者使用异步文件读取 API，允许同一线程在等待任何请求完成之前发出多个请求。一些应用程序从预读中受益匪浅，消除了很多延迟。但如果您想要一个性能良好的通用解决方案，您需要提供低延迟的控制器，这样您就不必等待控制器，甚至无法确定接下来需要什么数据。