聚焦中小企业存储

存储是一块难啃的硬骨头。对企业而言，存储之所以困难，是因为它往往需要为看似含糊不清的收益付出高昂的价格。大多数高管都明白需要“存放”东西、而且要存放更多东西的必要性，但对于性能、访问方式、冗余与风险测算、备份和灾难恢复，他们却所知甚少。这使得 IT 的工作变得困难，因为我们需要解释，为什么对业务利益相关方而言看似一套无形系统的东西，其预算却往往必须如此庞大。

对 IT 而言，存储之所以困难，是因为存储系统十分复杂——往往是中小企业内部最为复杂的单一系统——而且由于其价格高昂且高度集中，这类系统在一家企业内部往往只以极少的数量存在。这意味着大多数中小企业即便拥有存储系统，也只有一套，而且会保留很长很长的时间。这种对存储系统缺乏广泛接触的状况，再加上与存储系统打交道的需求相对不那么频繁，使得中小企业的 IT 部门要去应对这样一个项目：它是一笔预算庞大、对业务具有极高关键性的开支，却只占其“工作”范畴中的一小部分，而且就这头“猛兽”本身的性质而言，他们实际上对它几乎没有什么经验。IT 的其他领域则要便于进行试验、测试和学习得多。

在这两大挑战之间，我们所面对的，是一种总体上既不被管理层、也不被 IT 部门所充分理解的产品。存储被误解得如此之深，以至于 IT 部门往往根本不清楚自己到底需要什么，而且常常无非是在朝着存储这块飞镖靶子掷飞镖，然后从飞镖落在哪里就从哪里开始——而且往往一开始就去找供应商而不是顾问，从而把自己引上了一条“决定早已做出”却又看似在征求意见的道路。

存储供应商对这一切心知肚明，却几乎不做什么来改善这一局面；因为一旦中小企业与某家供应商建立了联系，对该供应商而言最符合其利益的做法就是不去教育客户，毕竟客户早在掌握必要信息之前，就已经做出了找上这家供应商的决定。于是供应商只想把手头现有的东西卖出去就行了。单独一家存储供应商很少能在自家产品线中拥有种类宽泛的产品，因此在确切弄清究竟需要什么之前就径直去找供应商，相比技术领域的其他场合，会更加把客户推向“实际上已经决定好买什么”的境地，而这可能导致最终成本与实际所需相比相差好几个数量级。

举个例子：大多数服务器供应商都提供种类繁多的服务器，既有 x64 系列的，也有大规模 RISC 机器以及其他小众产品。而大多数存储供应商只提供存储产品中的一小部分子集，要么只提供 SAN，要么只提供 NAS，要么只提供“大型机”级别的存储，要么只提供小型的、非复制式的存储，如此等等。只有极少数供应商才拥有种类齐全、能满足大多数需求的存储产品；而即便是其中最出色的那些，也缺乏覆盖全部市场规模的能力，无法同时触及更小的中小企业市场以及中端和企业级市场。

那么，我们接下来该何去何从呢？显然，这是一个需要克服的严峻挑战。

显而易见的一个选择——也是各家机构不应排除的一个选择——就是求助于存储顾问。这样一个人，他并不在转售某种解决方案，或者至少不是在转售单一一种解决方案，而是拥有一整套完备的解决方案可供选择；他既能够提供低成本的、价值一千美元的解决方案，也能提供价值一百万美元的解决方案——这样一个人，他懂得 NAS、SAN、横向扩展存储、复制、故障切换等等。在去找你的顾问时，不要预设你已经知道自己的成本会是多少——其中牵涉到非常非常多的因素，通过审慎地权衡这些因素，你或许能花费比原先预想的少得多的钱。但务必心中有预算、把风险承受能力充分记录在案、算清楚停机的成本，并准备好一套非常完整的、对存储使用场景的预期清单。

不过，求助于顾问当然并不是唯一的途径。自己做研究、学习基础知识、遵循一套结构化的决策流程，即便不能让你找到完全正确的解决方案，至少也能让你在正确的道路上走出很长一段。在考量存储时，有四大要素需要权衡：功能（存储如何被使用和访问）、容量、速度和可靠性。

第一个要素，功能，是最容易被忽视、也最不被理解的。事实上，尽管这是最基本的考量，它却常常干脆被扫到地毯底下、被人遗忘。我们可以通过问自己一个问题来回答这一点：“我们为什么要购买存储？”

让我们系统地来处理这个问题。我们购买存储会有许多种理由。这里列举几个常见的：相比在单台服务器或台式机本地配备大量存储，借此降低成本；集中管理数据；提升性能；以及在系统发生故障时让数据更具可用性。

弄清这些要素中究竟是哪一个——或者是否还有此处未列出的另一个要素——在驱使你走向共享存储，这一点很重要，因为它很可能为你的决策流程提供一个起点。在我们弄清为什么需要共享存储之前，我们将无法去审视那套存储的功能；而正如我们已经知道的，功能正是最根本的决策要素。如果你无法确定存储的功能，那么可以稳妥地假定根本就不需要共享存储。不要害怕做出这一判断，绝大多数小型企业对共享存储几乎没有、甚至完全没有需求。

一旦确定了我们共享存储的功能，我们现在就能相对轻松地确定容量和性能需求了。容量是存储最容易、也最显而易见的方面。性能，或者说速度，说起来和解释起来都很容易，但要量化却困难得多，因为 IOPS 往好了说是一个含糊的概念，往坏了说则是完全被人误解的概念。IOPS 有不同的类型，围绕随机访问、顺序访问、突发速度、延迟和持续速率都有各自需要关注的地方，再加上读取与写入之间还存在差异！要确定所需的性能尚且困难，更不用说去确定一台设备的预期性能了。但只要做了审慎的研究，这一点是可以实现、也可以衡量的。

我们的最后一个要素是可靠性。这一点和功能一样，似乎是有意进军共享存储领域的 IT 专业人士反复遇到的一个绊脚石。至关重要——不，是绝对不可或缺——的是，要牢记“存储只不过是又一台服务器”这一观念，而适用于普通服务器的冗余和可靠性概念，同样适用于专用的共享存储系统。在几乎所有情况下，企业级存储系统都是构建在企业级服务器之上的——相同的机箱、相同的硬盘、相同的组件。常常令人困惑的是，即便是中小企业也会动用中端或高端的存储系统去支撑低端得多的服务器，这有时会使存储系统显得颇为神秘，正如大型主机服务器在只用惯了商用服务器硬件的人看来也可能显得神秘一样。但不要被误导，可靠性的原理是一样的，你需要像一直以来（或者说本应一直以来）所做的那样，以完全相同的方式去衡量风险，从而确定什么样的设备才适合你。

花时间去评估、研究并理解存储需求是非常重要的，因为由于更换存储系统的成本极其高昂、过程又极其复杂，你的存储系统很可能会作为网络上的骨干组件留存很长很长的时间。与最新版的 Microsoft Office 不同，购买一套新的共享存储系统并不会对某位高管的台式机产生直接的影响，因此它也就缺乏那种足以推动“功能更新”的光鲜亮丽。

现在我们已经把各种选择摆在了面前，可以开始审视真正的产品了。基于我们对功能的研究，我们现在应当能够判断出，我们究竟是需要 SAN、需要 NAS，还是两者都不需要。在许多情况下——远比人们所意识到的要多——两者都不需要才是正确的选择。往往，给现有服务器添加硬盘，或者在需要的地方接上一个 DAS 硬盘机箱，会比做一些更复杂的事情更具成本效益、也更可靠。这一点不应被忽视。事实上，如果 DAS 就能满足手头的需求，那么其他任何东西还能说得通的情况就会很罕见了。简单，是 IT 经理的朋友。

当然，也有很多时候 DAS 无法满足当前的需求。共享存储自有其用武之地，哪怕只是在台式机用户之间共享文件。借助当今现代化的虚拟化系统，共享存储正变得越来越流行——尽管即便在那种情况下，DAS 也太容易被人回避了，哪怕它本来可能很好地满足现有需求。

除极少数例外情况外，当需要共享存储时，NAS 就是应当求助的方向。NAS 代表网络附加存储（Network Attached Storage）。NAS 模仿文件服务器的行为方式（NAS 不过就是被打包成一台设备的文件服务器），从而使其易于管理、易于理解。NAS 往往非常多用途，它取代了传统的文件服务器，并且常常被用作虚拟化的共享后端。NAS 以 NFS 和 CIFS 协议为典型特征，但我们也并不罕见地会看到 NAS 设备上同样提供 HTTP、FTP、SFTP、AFS 等协议。NAS 作为一种连接纽带运作得很好，它让 Windows 和 UNIX 系统在彼此之间轻松共享文件，而各自只需使用自己的原生协议即可。NAS 通常被用作 VMWare 的 vSphere、Citrix XenServer、Xen 和 KVM 的共享存储。有了 NAS，你就能轻松地将共享存储用于许多不同的角色，也能轻松地从你的共享存储系统中获得良好的利用率。

NAS 并不总能满足我们的需求。一些特殊的应用程序仍然需要共享存储，却无法利用 NAS 协议。受此影响最显著的产品是 Microsoft 的 HyperV、各类数据库以及服务器集群。针对这些产品的答案就是 SAN。SAN，即存储区域网络（Storage Area Networking），是一个不易理解的概念，而且即便在最理想的情况下也很难加以归类。正如 NAS 只不过是呈现传统文件服务器的一种不同方式，SAN 也确实只不过是呈现直接附加磁盘的一种不同方式。虽然 SAN 与 DAS 之间的差异看似显而易见，但要真正把它们区分开来，往好了说也是含糊不清的，往坏了说则是不可能的。SAN 和 DAS 通常共用协议、机箱、局限性和介质。许多 SAN 设备都可以作为 DAS 来连接和使用，而大多数 DAS 设备也都可以接到一台交换机上当作 SAN 来用。实际上，我们使用这些术语，更多地不过是用来指代它们的使用场景而已。

SAN 难以被有效利用，原因有很多。首先是它不被人充分理解。SAN 其实很简单——简单到很难把握，反而使它复杂得出人意料。SAN 实质上不过就是被抽象化、被重新分区、然后又作为 DAS 重新呈现给主机的 DAS。“共享存储”这个说法令人困惑，因为虽然 SAN 技术和 NAS 一样可以允许多台主机连接到单一一套存储系统，但它并不为连接到同一文件系统的各台主机提供任何形式的协调仲裁。NAS 是智能的，它会处理好这一点，从而让“共享”共享存储变得容易。SAN 则做不到，它太简单了。SAN 简单到，实际发生的情况不过就是把单块硬盘（尽管它可能是被抽象化的）接到多台主机上的控制器里。当年共享存储意味着把两台服务器接到一根 SCSI 线缆上时，这一点还很容易想象。如今，有了 SAN 的种种抽象化以及 NAS 的普及，大多数 IT 机构都会忘记 SAN 究竟在做什么，于是灾难便可能降临。

SAN 自有其用武之地，这是毋庸置疑的，但 SAN 使用和管理起来都很复杂，而且非常受限。它往往也非常昂贵。关于 SAN 的经验法则是这样的：除非你需要 SAN，否则就用别的东西。就这么简单。SAN 应当被回避，直到它成为唯一的选择为止；而当它确实是唯一选择时，它就是正确的选择。它几乎从来不会、甚至根本不会因为性能或成本上的原因而被选用，因为它的性能通常逊于其他选择，成本也高于其他选择。但当你要为 HyperV 提供后端支撑、或要构建一个数据库集群时，别的任何东西对你来说都不会是可选项。对于中小企业中的大多数使用场景而言，要有效地使用 SAN，都需要在它前面摆上一台 NAS，以便把存储共享出去。

NAS 构成了共享存储使用场景中的绝大多数。它简单、广为人知、而且灵活。

如今许多（即便不是大多数）共享存储设备都能同时处理 SAN 和 NAS，而这两者之间的区别，更多地体现在它们的用途、协议和理念上，而非别的什么方面。它们的物理设备往往是相似的（即便不是相同的），当今的连接技术也是如此。

最重要的一点是，在寻找共享存储时，心中要有明确的目标。把这些目标写下来，然后逐一审视每一种技术和每一款产品，看看它们如何满足、或是否能满足这些目标。不要采取条件反射式的决策，也不要依据营销资料、或看似存在的市场势头来行事。先从判断共享存储是否真有必要开始。如果有必要，再确定 NAS 是否能满足你的需求。如果不能，再着眼于 SAN。存储是一笔巨大的投资，请花时间去考察各种替代方案，做大量的研究，只有在把范围缩小到少数几款、具体的、相互竞争的产品之后——再去找供应商敲定最终的细节和报价。