Avanade谈NetApp阵列：Exchange Server的可行选择？

Avanade 是一家领先的系统集成商，专注于Microsoft企业平台。最近，Avanade进行了一系列全面的测试，以验证NetApp存储阵列用于Microsoft Exchange环境中的能力。为了解更多信息，Tech OnTap 采访了Avanade首席架构师Patrick Cimprich。

    问：在讨论有关测试设置和结果的具体细节之前，您能否概括解释一下为什么存储是 Exchange 基础设施的一个关键要素？

    Patrick：Exchange Server 处理存储的方式不同于其它任何应用程序。由于 Exchange I/O 事务处理的大小虽小但数量很大，因此 Exchange 是一个“贫穷的存储居民”，后端存储系统必须非常努力才能保持正常运行。从历史上看，存储一直是任何 Exchange 实施的大小和规模限制因素，这使其成为 Exchange 部署的关键要素。

    问：促使Avanade使用Exchange测试NetApp的主要动机是什么？

    Patrick：这些年来，Avanade 在各种项目中多次与 NetApp 不期而遇。最近，我们开始越来越频繁地接触到 NetApp 存储，客户请求我们就 NetApp 解决方案提供指导。

    我们认为这是重新审视 NetApp 技术的时候，在过去几年里，NetApp 技术有了明显发展，因此我们需要更好地装备自己才能响应用户的请求。

    在 Avanade 测试中心，我们制订了一个严格的测试计划，并与 NetApp 合作评估其产品，以测试这些产品与 Microsoft Exchange Server 2003 配合使用时的表现。

    问：我们得知您最初对NetApp持怀疑态度。这是为什么呢？

    Patrick：坦率地说，过去 Avanade内部有许多人都对NetApp保持一定的距离。这在很大程度上是基于我们在 NetApp提供光纤通道SAN和iSCSI之前与NetApp交往所获得的早期经验。尝试在 NAS 平台上支持要求块 I/O的Windows应用程序是非常困难的。

    当我们开始看到客户对 NetApp 的需求越来越多时，我们仍大多认为 NetApp 是一家 NAS 公司。我们不知道它的 SAN 产品是否能够真正满足 Exchange Server 2003 极高的 I/O 需求。

    而且，老实说，我本人对 NetApp 的态度充其量只是不冷不热而已。我在各种存储技术方面拥有十几年的经验，尤其是非常了解 EMC 技术。鉴于 NetApp 不同于其它存储技术，我对测试结果将会怎样并不确定。我确实产生过一定的怀疑，而且没有料到 NetApp 会完全成功。

    问：您是否仍持怀疑态度？

    Patrick：首先，答案是否定的。

    从性能角度而言，我们看到的大多数结果与其他供应商的类似配置相一致。延迟位于可接受的范围内，在我们测试的所有配置中，磁盘读写大大低于 Exchange 的 20 毫秒阈值。

    此外，NetApp 可以创建和存储多份 Snapshot™ 副本而不影响性能，因此具有巨大的增值。这绝对是我在此次体验中了解到的最酷功能之一；NetApp Snapshot 副本功能令人印象深刻。总的来说，与我在过去十年工作过的其它任何存储环境相比，我认为 NetApp 存储更易于学习和管理。

    问：请谈一谈测试过程以及先前表示怀疑的人们是如何变为相信 NetApp SAN 解决方案的。能否大致介绍一下你们所进行的测试？

    Patrick：我在我们进行这些测试时确立的其中一条指导原则是，我们测试的任何对象都必须受到支持（“正常的”配置）。我们必须选择我们能够通过致电有关的供应商来获得支持的配置。这意味着不含 beta 或 alpha 代码，只使用通用硬件和软件，并且所有配置必须位于 Microsoft 硬件兼容性列表中。换句话说，我们执行的是大多数客户会执行的操作。我们选择了获得支持和认证的配置以及我们在现实环境中为客户设计的配置。

    问：能否谈谈使用 Jetstress 进行的第一项特定于 Exchange 的测试？

    Patrick：我们运行的第一项特定于 Exchange 的测试使用了 Microsoft Jetstress 实用程序。此测试直接模拟 Exchange 模式的磁盘 I/O。它专为以下用途而设计：确保您计划为 Exchange Server 2003 部署的任何存储子系统符合预期的 I/O 需求（在本例中为 6,000 个 IOPs 以上）。

    我们完全按照客户部署中的实际使用情况配置 NetApp 存储系统和 Exchange 服务器。我们为 Exchange 数据和日志使用了 64 个驱动器，并配置了四个 Exchange 存储组，每组五个数据库。日志和数据库位于单独的聚合中。为每个存储组创建了 384GB 的单独 LUN，并为日志创建了相应的 115GB LUN。

    此测试的结果再次与其他供应商的类似配置相一致。此测试中的关键数值是延迟。20 毫秒被认为是上限。如果延迟超过 20 毫秒，Exchange 将开始出现故障。所有 FAS3050 配置均超过 6,000 个 IOPs，并且以非常良好的结果通过测试，平均响应时间为 15.5 毫秒。[编辑备注：此处指的是读取操作。]

图 1 Jetstress 测试结果

    图上显示的是 IOPs 合计以及 Exchange 数据库读取操作的延迟。显示了在测试期间使用的不同服务器和存储传输方式的结果。例如，HS40-FC 是使用光纤通道接口的 IBM HS-40 服务器的代码。

    问：使用 LoadSim 的下一项特定于 Exchange 的测试情况如何？

    Patrick：从 Exchange 的角度来看，此测试执行 Exchange 系统中的下一个功能层，从头到尾地测试整个配置。此测试与 Jetstress 测试使用相同的配置，服务器上加载 Exchange。Microsoft 的一个名为 LoadSim 的模拟工具用于在 Exchange 系统内实际传输邮件消息。在此测试中，我们将在末端观察相应的磁盘负载，同时记住用户响应时间。

    在权衡一系列因素（例如发送消息所用的时间、从磁盘中读取所用的时间以及写入磁盘所用的时间）之后，LoadSim 将创建分数。这些分数以毫秒计。Microsoft 将 1,000 毫秒（1 秒）的分数视为合格分数。

    所有 NetApp 分数均低于 500（半秒）。这些分数代表了卓越的性能，并且再次与其他供应商相一致。在所有情况下，磁盘读写都大大低于 20 毫秒阈值。

图 2 在测试期间使用的不同服务器和传输配置的 LoadSim 分数

    问：您是否测试了 NetApp 的备份和恢复能力？

    Patrick：是的。我们专门为 Exchange Server 2003 考察了基于存储的备份和恢复 — 对于 NetApp，这是指 Snapshot 副本。我们一天执行三次备份：一次在上午 7 点，一次在中午，另一次在下午 7 点 — 符合实际情况。我们在五天时间里运行了此测试。开始时不存在保存的备份。在测试过程中，我们添加备份，直至存在 7 个备份。Snapshot 数量达到 8 个时，我们复制出最早的备份，并为测试的其余部分保持由 7 个滚动备份组成的一组。

    如欲了解更多详细信息，请查阅白皮书。

    在测试的整个持续时间内，我们测量了最终用户响应时间、存储延迟、磁盘延迟等。我们看到，性能并未随着添加额外的 Snapshot 副本而受到影响。数据库延迟平稳保持在 4 毫秒（20 毫秒为上限），客户端延迟平均为 167 毫秒（1,000 毫秒被认为是上限）。

    这些结果非常出色，我相信它们是使 NetApp 与众不同的重要因素。其他存储供应商通常只能在使用完全拷贝或磁盘克隆而非 Snapshot 时获得类似的结果。在磁盘空间和维护多项备份的成本方面，完全拷贝显然要昂贵的多。如果客户不熟悉 NetApp，我认为您应该花一点时间来研究和理解 NetApp Snapshot 技术是如何工作的（与其他供应商的 Snapshot 相比）。

    图 3 添加额外的 Snapshot 副本对性能的影响微乎其微

    问：SnapManager for Exchange 和 Single Mailbox Recovery 情况如何？

    Patrick：我们利用了 SnapManager for Exchange 作为执行工具来协调和配置我们在备份和恢复测试中制作的所有 Snapshot 副本。我认为它是测试的另一个亮点。易于安装、易于使用而且并不复杂，这些都是明显的优势。该工具专门针对 Exchange 的 Snapshot 备份。坦白地说，相对于我用过的其它工具，使用该工具是一件令人愉快的事。

    我们未将 Single Mailbox Recovery 用作此测试的一部分，但我确实有使用它的经验。在 Exchange 环境中，我认为它是 NetApp 的另一个亮点。许多供应商提供类似的功能，但与其他一些供应商的单邮箱恢复工具相比，NetApp 提供的集成再次使这些工具变得简单直接、易于使用。

    问：灾难恢复也可以是 Exchange 基础设施的一个关键要素。您是否考察了 NetApp 的灾难恢复能力？

    Patrick：这不包括在这些测试中， 超出了本次评估的范围。

    但是，我最近在实验室中为我的 NetApp 系统进行了框架切换。我使用 SnapMirror® 进行整个迁移。我能够在大约 16 小时的执行时间内将 10TB 数据从一个系统迁移至另一个系统。其中四分之三的时间用于等待复制数据。这是我第一次使用 SnapMirror，以前从未在 NetApp 上进行这种类型的迁移。我只进行非常少的计划就完成了整个工作。我在其它存储平台方面拥有多年经验，我知道，使用其它任何存储阵列都是做不到这一点的。

    问：NetApp 存储与您为 Exchange 配置过的其它存储系统相比如何？

    Patrick：NetApp 与其他存储供应商不相上下。就 Exchange 而论，最关键的因素是轴数，因此我不会期望任何存储系统因性能明显高于其它系统而与众不同。缓存始终忙得不可开交；这并不要紧。？？除在实施中严重的磁盘 I/O 瓶颈之外，从性能角度而言，它可以归结为一次“冲洗”。因此，重要的问题变为“系统安装和管理的容易程度如何？”

    实施是 NetApp 真正与众不同之处。NetApp 采用独特的方式根据虚拟化和管理结合这些磁盘驱动器的功能。NetApp 的 Snapshot 拷贝方法以及 Snapshot 与应用程序的集成优于我用过的其它任何存储供应商产品。配置速度、配置简易性、日常运行和管理使 NetApp 在竞争中处于优势地位。

    为我们包含 6,000 位用户的 Exchange 配置 NetApp 大约执行了 10 个步骤。配置过程非常简单直接，我可以培训其中一位实习生协助执行这些测试。他是一个聪明的家伙，但是如果叫他去管理其它存储平台的话，我会非常紧张。

    问：一个反复出现的问题是，客户应该选择光纤通道还是 iSCSI 作为 Exchange 和其它要求块式存储的应用程序的存储基础设施。Avanade 测试中心评估是否使该问题变得清晰了？

    Patrick：除 NetApp 性能之外，我认为这是我们从测试中获得的最有趣的结果之一。我过去对 iSCSI 持怀疑态度，认为其性能比不上光纤通道。事实上，在亿万个 IOPs 和数百万封电子邮件之后并不存在差异，有时 iSCSI 实际上强于光纤通道。不过，即使 iSCSI 在这些测试中“打败”光纤通道，实际上只是舍入误差，但问题在于，对于具有 Exchange 负载的这些测试，光纤通道和 iSCSI 之间没有实质性差别。基于此评估，我可以放心地鼓励客户考虑将 iSCSI 作为企业级配置的可行解决方案。

    同样，白皮书中包含更多关于这些测试及其结果的详细信息。另外，最近我和 ComputerWorld 讨论了 10 千兆位以太网和 iSCSI。这个话题非常有意思，我想我们将听到更多关于这方面的消息。

    问：您是否从此次测试中了解到您认为 Tech OnTap 读者会感兴趣的其它任何事情？

    Patrick：总的来说，我认为此次测试确实说明了 NetApp 作为一家公司如何将发展转变为使用较为简单的硬件和软件。NetApp 一开始就为较小的需求（部门需求和更小的分部）提供解决方案，现已发展成为数据中心提供解决方案。NetApp 处理硬件和软件的方式非常适合降低复杂性和运作开销。在 Avanade 测试中心，我们发现它更加易于配置和设置，而且整个系列都使用单一的操作系统。

    有些竞争对手提供的管理产品范围较广。它们在单个产品中不仅涉及 Exchange，而且涉及 SQL Server、文件服务等。此策略确实具有优势，但是安装和维护起来比较困难。NetApp 为您提供一组针对特定应用程序的产品，更加便于配置和维护，为您提供您需要的功能。