何时应当考虑 SAN？

似乎每个人都想一头扎进购买 SAN 的浪潮中，有时还相当狂热。不可否认，SAN 确实很酷。它们是大多数 IT 专业人员有机会在自己机房中拥有的、最有趣、最令人兴奋的大型硬件之一。想要拥有一台属于自己的 SAN，往往是一种“攀比”心理在作祟，因为使用 SAN 已经变成了某种身份的象征——它是大企业 IT 最后的堡垒之一，你只会在专用的服务器机柜里见到它，而几乎从不会在某人家里见到（嗯，几乎从不会）。SAN 被大力推销、铺天盖地地宣传和售卖，被描绘成内部冗余、令其坚不可摧、速度快得违背常理、并且塞满了各种你从不知道自己需要的功能的神奇盒子。在与设计新系统的 IT 专业人员交谈时，我最常听到的设计考量之一就是：“嗯，我们对最终设计还知之甚少，但我们知道我们需要一台 SAN。”

在本文的语境中，我使用 SAN 一词时取其最常见的含义，即指“块存储设备”，而不是指整个存储网络本身。存储网络可以为 NAS 而存在，却根本不使用 SAN 块存储设备。因此在本文中，SAN 专指作为设备的 SAN，而非作为网络的 SAN。SAN 是一个含义模糊的术语，在不同场合用来表示多种不同的事物，很容易造成混淆。一台未连接网络配置的 SAN 就变成了 DAS；接入网络的 DAS 就变成了 SAN。

让我们停下来想一想。SAN 是你的后端存储。在所有情况下，是否需要它，都取决于你架构的其他方面。如果你尚未确定许多其他部件，你根本无法知道在最终设计中是否会需要 SAN，甚至无法知道它是否有用。这是危险信号。到处都是危险信号。想象一场罗马战车赛，由马在后面推着战车跑（如果你明白我的意思的话）。

显然，实施 SAN 的冲动如此强烈，以至于常常有整个项目被设计出来，而其目的几乎只是——看起来——为了给购买 SAN 找一个理由。与任何项目一样，人们首先必须问的问题是：“我们试图满足的业务需求是什么？”然后以此为出发点开展工作，而不是“我们想买一台 SAN，能用在哪里呢？” SAN 很复杂，而复杂会带来脆弱性。SAN 往往成本高昂。但 SAN 最可怕的一点，是业界普遍缺乏对它们的深入了解。SAN 带来巨大的技术风险和业务风险，必须克服这些风险才能证明其使用的合理性。毫无疑问，SAN 非常令人兴奋，也相当有用，但这通常不足以成为想要拥有它的理由。

我们称 SAN 为“万不得已时才用的存储”。这意味着，在挑选存储类型时，你应当希望自己能够使用其他任何替代方案，例如本地硬盘、DAS（直连存储）或 NAS（网络附加存储），而不是 SAN。大多数时候，其他选项都能出色地完成任务。但在某些情况下，业务需求所提出的要求只有 SAN 才能合理地满足。当这种情况出现时，我们别无选择，必须使用 SAN。但通常情况下，都可以避免使用它，转而采用更简单、且往往成本更低或风险更小的选项。

我发现，大多数想要实施 SAN 的人都是在一系列误解之下这样做的。

第一个误解是，SAN 就其本质而言是高度可靠的。诚然，确实有许多 SAN 供应商和特定的 SAN 产品可靠得惊人，但同样的话也可以用在任何 IT 产品上。与高端 SAN 价位相当的高端服务器，其可靠性与 SAN 不相上下。由于 SAN 是用与普通服务器相同的硬件组件制造的，要让它们更可靠并没有什么魔法。任何能让 SAN 更可靠的技术，都是服务器 RAS（可靠性、可用性和可维护性）技术向下渗透的结果。就像 SAN 一样，NAS 和 DAS 以及本地磁盘都可以做得极其可靠。SAN 仅仅指被用来提供块存储、而非执行其他某项任务的那台设备。一台 SAN 不过是一台非常简单的服务器。SAN 涵盖了从顶端接近大型机级别的可靠性，到底端不过是外置硬盘——你网络上最不可靠的网络设备——的整个可靠性范围。因此，与其说 SAN 意味着可靠性，不如说它实际上提供了若干你能想象到的最低可靠性的特例。但是，归根结底，所有服务器在可靠性方面所面临的顾虑大致相当。SAN 之所以获得可靠的名声，是因为企业往往为其 SAN 投入了极高的预算，而这样的预算并不会投入到它们的服务器上，于是比较的对象就成了相对高端的 SAN 与相对廉价的服务器。

第二个误解是，SAN 意味着“大”，NAS 意味着“小”。两者之间根本不存在这样的关联。SAN 和 NAS 几乎可以是任何规模或任何品质的。它们都覆盖了完整的范围，而所选用的技术丝毫不能暗示一台设备是否大型。同样，如上所述，由于 SAN 可能具备的简单性，它在技术上实际上可以做得比 NAS 解决方案“更小”，但这属于特例，而且大多只停留在理论层面，尽管市面上确实有属于这一类别的 SAN 产品，只是在实际使用中非常罕见。

第三个误解是，SAN 和 NAS 在机箱内部有着天壤之别。事实绝非如此，因为当今大多数 SAN 和 NAS 设备都属于所谓的“统一存储”，意思是一台同时充当 SAN 和 NAS 的存储设备。这凸显出，两者之间的关键区别不在于后端技术、硬件、规模或可靠性，而其决定性的差异在于用来传输存储的协议。SAN 是块存储，使用诸如光纤通道、iSCSI、SAS、ZSAN、ATA over Ethernet（AoE）或 Fibre Channel over Ethernet（FCoE）等协议，将原始块设备暴露到网络上。而 NAS 则使用网络文件系统，借助 NFS、SMB、AFP、HTTP 和 FTP 等应用层协议（这些协议再承载于 TCP/IP 之上）将文件暴露到网络上。

第四个误解是，SAN 本质上是一种文件共享技术。这其实是 NAS。SAN 只是把你的块存储（硬盘子系统）拿来，使其可以通过网络远程访问。网络的特性意味着我们可以把那份存储同时连接到多个设备上，而且事实上，从物理上讲，我们确实可以做到。就像我们过去能够把多个控制器物理地连接到一条 SCSI 排线的两端、而硬盘悬挂在中间一样。在正常情况下，这样做会摧毁硬盘上的所有数据，因为彼此互不知情的控制器会互相覆盖对方的数据，几乎瞬间造成损坏。在一些专门的集群文件系统及其驱动程序中确实存在允许这样做的机制，但这需要专门的知识和理解，其技术深度远远超出了许多购置 SAN 的人所意识到的、为了实现他们常常认为正是 SAN 之根本用途的目标所需要具备的程度——这种灾难如此常见，以至于我大概每周都会与刚刚干了这件事的人交谈。SAN 恰恰把大多数人认为它本是为之而设计去处理的那个用例置于风险之中，不仅未能提供人们所追求的近乎神奇的保护，反而恰恰成为数据丢失的根源，这暴露出实施一项被误解的存储技术所伴随的风险之高。

第五个误解是，SAN 很快。SAN 可以很快；它们也可以慢得吓人。单凭使用 SAN 技术本身，并不会带来内在的速度提升。实际上，SAN 要克服其所处网络所引入的固有瓶颈是相当困难的。由于其他一些存储选项（例如 DAS）使用与 SAN 完全相同的技术，却没有实际网络所带来的瓶颈和延迟，因此一台等效的 DAS 还会比与之对应的 SAN 稍快一点。SAN 通常会比硬件完全相同的等效 NAS 稍快一些，但即便如此也并非板上钉钉。SAN 和 NAS 表现各异，在不同的使用场景中，两者中的任意一方都可能表现更佳。基于性能需求而选择 SAN 作为解决方案的情况是很少见的。

第六个误解是，只要是 SAN，与存储选型相关的固有问题就不再适用了。一个很好的例子是 RAID 5 的使用。在服务器中这样做会被视为不良实践，但在使用 SAN（理论上它比单台独立服务器要关键得多）时，人们却常常基于一种信念而放弃审慎的存储子系统规划，认为既然是 SAN，它就已经以某种方式解决了那些问题，或者那些问题不再适用。诚然，某些高端 SAN 确实具备一些在别处不太可能见到的风险缓解功能，但这种情况很罕见，并且仅限于那些原本采用脆弱设计就已不常见的、非常高端的机型。在为物理服务器规划存储时投入极大的细心和考量，而在使用 SAN 时却基于“SAN 在内部处理了这一切”或“干脆不再需要这样做”的假设，常常跳过同样的规划与把关——这是一种危险却非常普遍的做法。

在驳斥了诸多关于 SAN 的误解之后，人们或许会想，SAN 究竟有没有合适的应用场景。当然有，在被正确使用时，它们相当重要，价值也极高。SAN 最强的优势来自于整合，以及若干特殊类型的共享存储。

整合曾是历史上吸引客户采用 SAN 解决方案的推动力。SAN 让我们能够把许多文件系统合并到单个磁盘阵列中，从而大幅提高存储资源的利用效率。由于 SAN 是块级的，因此凡是传统本地磁盘子系统能够派上用场的场合，它都能做到这一点。在许多服务器、甚至许多台式机中，由于增长需要、规划以及磁盘容量粒度的限制，存储空间被白白浪费。如果我们有二十台服务器，每台都配有 300GB 的磁盘阵列，但每台只用了其中的 80GB 容量，那我们就有了巨大的浪费。有了 SAN，我们可以整合到仅 1.6TB，再加上必要的少量开销，从而在物理磁盘上的花费远低于每台服务器各自维护自身存储的情形。

一旦我们开始整合存储，我们就会开始寻找更高级的整合机会。在把许多服务器文件系统整合到单台 SAN 上之后，如果我们的 SAN 实现支持，我们就有机会对那些数据进行去重和压缩，而在许多情况下（例如服务器文件系统），这有可能带来显著的利用率下降。于是上例中我们的 1.6TB 实际上最终可能只有 800GB 甚至更少。突然之间，我们的整合数字变得越来越好。

要高效地利用整合，就必须具备规模，而这正是 SAN 真正大放异彩之处——当规模变得非常庞大时，不仅是容量上的规模，更重要的是接入节点数量上的规模。SAN 最适合大规模的存储整合。这是它们的最佳着力点，也正是它们在大型企业中几乎无处不在、而在小型企业中却非常罕见的原因。

SAN 对于某些类型的集群以及需要单一共享文件系统访问的共享存储也非常重要。除了一种特殊情形——数据库——之外，这其实是一种相当罕见的需求。大多数应用程序乐于使用提供给它们的任何类型的存储，但数据库往往需要低层级的块访问，才能最有效地正确操作其数据。正因如此，它们很少能够在 NAS 或文件服务器上使用，或者很少能在其上得到有效使用。长期以来，为数据库集群提供高可用存储环境一直是 SAN 存储的一个关键用例。

除了这两个证明了绝大多数 SAN 部署之合理性的主要用例之外，SAN 还提供了高度的存储灵活性，使得在大型环境中移动、扩展和修改存储有可能变得非常简单，而无需处理物理搬迁或繁琐的采购与配置流程。同样，与整合一样，这也是大规模所带来的产物。

在非常大型的环境中，SAN 还可以用来在存储团队和系统工程团队之间提供一个分界点，使得双方能够在网络层（通常是光纤通道或 iSCSI）进行交接。这种清晰的职责划分，对于那些希望拥有高度独立的存储、网络和系统团队的公司而言，可能至关重要，它使得各团队能够高度隔离。这让存储团队可以只专注于存储，系统团队可以只专注于系统，而双方都无需了解对方的具体实现。

在很长一段时间里，SAN 也把自己呈现为一种提升存储性能的便捷手段。这并非 SAN 的内在特性，而是其常被用于整合所衍生出的结果。与作为整合手段使用的虚拟化类似，共享式 SAN 天然具有一种优势：与分散在许多台独立服务器上的等效存储相比，它能更好地利用可用主轴、集中式缓存以及更大的硬件。就像共享 CPU 资源一样，当 SAN 没有同时收到来自多个客户端的请求时，它有能力把全部容量都投入到服务于单个客户端的请求上，从而提供一种平均性能体验，其水平有可能远高于单台服务器凭一己之力所能负担得起的水准。

然而，使用 SAN 来获取性能的做法正在迅速失宠，这是因为 SSD 存储的出现已变得极为普遍。随着具备极低延迟和高 IOPS 性能的 SSD 价格下降，以至于它们正被加入到独立服务器中充当本地缓存、甚至有可能被用作主线存储，SAN 网络所带来的瓶颈成为越来越大的因素，使得 SAN 的整合优势越来越难以抵消本地 SSD 所带来的性能优势。SSD 对共享存储市场有可能极具颠覆性，因为它们把性能优势重新拉回到了本地存储一侧——这只是存储架构设计起起落落中的最新一幕。

关于 SAN 使用，最重要的一点是要记住：SAN 不应成为存储规划的默认起点。它只是众多技术选择中的一种，而且往往无法如预期那样满足需求，或者虽然满足了，却要付出不必要的高昂代价——无论是金钱上的，还是复杂性上的。先从定义业务目标和需求开始。当 SAN 能最有效地解决这些需求时再选用它，但要保持开放的心态，全面考量环境的整体存储需求。