Oracle on NetApp Part Ⅲ：为什么应与协议无关

    有关 Oracle存储体系结构的这第三部系列的最后部分着眼于 Oracle on NetApp 的现实部署。以前的文章主要侧重于 NetApp 工程如何优化使用 Oracle on NFS 和 Oracle on FC SAN。

    当 Tech OnTap 联系我写一篇 Oracle on NetApp 文章时，他们特意要求我讲述我们运行 Oracle on SAN 和 NAS 的情况。我告诉他们，“真为你们感到遗憾，你们竟然还在想着 SAN 或 NAS 方面的事。你们应该谈谈统一存储以及使用哪一种协议可以最好地满足每个客户需求或应用程序需求。SAN 和 NAS 术语早就都同“totally tubular”和“awesome”一起消失了。（它们都消失了，难道不是吗？）

    在 Catholic Healthcare West （CHW），我们至少有 117 个运行约 150 个应用程序的 Oracle 数据库实例，其中的应用程序都是由附带 NFS、光纤通道和 iSCSI 协议的 55 个 NetApp 存储系统提供支持。总体算来，我们有 750TB 以上的存储。由于事实上有许多 IT 公司、应用程序供应商和 DBA 仍在考虑协议的条款，本文着重说明如下：

• 我们如何为某个给定的应用程序选择要使用的存储协议
• Oracle 统一存储的优势
• 各种协议的优缺点

    坦白说，我们认为第二章最有意思。统一存储和独有的 NetApp 数据管理工具的结合为我们管理 Oracle 环境提供了极大的能量。

    选择存储协议

    我们对 Oracle on NetApp 的第一次了解是许多年前从 NFS 开始的。如果 NetApp 说我们可以通过 NFS 运行 Oracle，我们的第一反应肯定会笑，因为在当时那是一种非常异类的方式（有人现在还是这么认为）；回到那时，我们的 DBA 仍然需要原始磁盘。当我们从 SAP 转换为 Lawson Financials 时，我们也从传统的存储转变为 NFS。Lawson 派出了一组工程师来保证配置。他们原来计划要呆 5 天时间。第一天过后他们非常满意；他们验证了解决方案之后就离开了。

    从那时起，我们添加了许多其它 Oracle 应用程序，在 NFS、光纤通道和 iSCSI 上都分别添加了一些。

    此时，您可能会想为什么我们会将不止一个存储协议与 Oracle 一起使用以及我们如何选择要使用的协议。

    现在，我们 Oracle 的标准是采用 NetApp 存储的 Linux，我们没有区分光纤通道、iSCSI 或 NFS。我们现在很有信心运行它。当我们部署新的应用程序时，我们会依据提供应用程序的供应商最支持的那个协议作出决策。我们总是设法知道供应商最适合或者在其上面部署最多的那个协议。有些供应商只喜欢光纤通道，而其他供应商则愿意甚至更想要支持其它选项。例如，我们的 Emageon 图像存档和通信系统 （PACS） 指定使用 NFS。

    以前，我们首选的选项不是 iSCSI，就是 NFS，是由于它们的协议弹性以及高昂的每个端口成本和光纤通道管理成本，但现在director级交换机上的每个端口成本已不再是问题（它不再明显有别于 FC 和 IP），因此供应商支持就成为我们考虑的首要标准。

    要考虑的其它因素

    如果您想要为您的 Oracle 环境决定选择哪个协议，则除了供应商支持，您可能还需要考虑其它一些因素。

• 与网络小组的关系：我曾与一些人交谈过，他们除了光纤通道之外其它任何因素都不想考虑，这是因为他们没有控制 IP 网络或者与其网络小组没有保持良好的关系。如果您是这种情况，您可能发现长期使用 FC SAN 很有利。反过来说，FC SAN 明显存在管理复杂性问题。如果您的公司不具备处理此事的技能，则采用驾驭标准以太网产品的协议可能是很好的选择。
• 您的 DBA 需要什么？让我们来看看，好的 Oracle DBA 很难找到，并且许多 Oracle DBA 都带有好的和不好的强烈个性。有些人会比其他人更喜欢 NFS 和 iSCSI。若非逼不得已，我不会强迫好的 DBA 使用他/她不满意的协议。

    许多人始终认为性能是一种因素，但坦白讲我还没有发现性能与任何协议问题有关。无论您选择哪一个，冗余都是很不错的选项。我们发现 iSCSI 比 FC 要多 2% 至 4% 的开销。这很可能是由于我们使用软件启动端而非 iSCSI HBA 所致，任何情况都不足以构成动摇我们对协议的决心和我们提到过的其它事情的差距。

    对我们而言，能够使用我们所需的任何存储协议的优势要大于任何特殊协议的相对优势或劣势。阅读了解我们在 Oracle 环境中使用统一存储的详细信息。

    我们的 Oracle 环境中的统一存储

    多年来，CHW 通过采购不断地发展。最后，我们形成了一个具有多种风格的 UNIX和无数应用程序的极具多样性的环境。作为一个非盈利组织，我们必须基于严格的标准以降低成本和复杂性；我们主要采用技术并部署属于开源、基于开放式标准或处于最低高度模块化的解决方案。这不仅仅是对我们采用那些可将我们困在一种专有的单个供应商解决方案的技术的很好的业务实践。作为组织，我们经常寻找创新且先进的技术帮助改善病人护理，同时减少费用。

    这就是统一存储很好的适应我们环境的原因。我们可以部署存储系统并确保我们将不需要其它部署来满足我们未来的协议需求。NetApp 的统一存储解决方案可满足我们的 Oracle 需求并为我们提供可在所有协议上运行的功能组合以简化我们的 Oracle 数据管理。

    Oracle 的要求

    毫不夸张地说，我们的 Oracle 环境由在 Oracle 8.0.5 一直到 Oracle11g和 Oracle RAC 所有产品上运行的数百个应用程序构成。许多人将其 Oracle 应用程序称为“关键应用程序”，但当您加入医疗保健时，您就会觉得某些应用程序确实至关重要。我们 Oracle 基础设施的最关键要求就是可靠性，其次是可支持性。对我们而言，最重要的就是能够不需要依靠外部各方就可以支持我们室内的存储。我们不喜欢这里成为玻璃房和大型 SAN，因为我们不想依靠外物帮助我们从事故中恢复。

 CHW 正在使用的几种应用程序

    每个存储系统具有多个应用程序

    目前，CHW 有 50 多个 Oracle 服务器（包括 3 个 RAC 群集）连接 NetApp 存储。我们的 55 NetApp 存储系统共有 750TB 数据符合 Oracle 和其它关键存储对我们设备的需求。这些存储系统易于配置和管理；由于我们拥有大量的系统，我们可以使用 NetApp Operations Manager 监视一切活动。

    我们的大多数存储系统都在为多个应用程序服务。除了 Emageon PACS 应用程序（放射图像）和 Exchange 之外，我们任何一个 NetApp 系统都不是专门服务于某个单个应用程序。有了 NetApp 灵活卷（FlexVol卷），我们就不必担心出现热磁盘或磁盘竞争的情况。更高效地分配工作负荷。

    将来我们将利用 FlexShare把承载多个负载的存储系统上的工作负荷区分优先次序。我们至今还未使用它是因为 DBA 和其它组织都尚未意识到此功能的存在。一旦知晓后，我们就应让大多数优质应用程序应用此技术。

    存储系统可靠性和快速恢复

    借助 Oracle on NetApp，我们知道存储具有可靠性，并且在数据库发生损坏时，我们还可以轻松恢复存储，完全无需任何外界协助。在损坏发生前，我们经常可以使用 SnapRestore恢复到指定的时间点，并且几分钟内就可以重新运行。此外，我们可以使用 FlexClone轻松地克隆数据库用于测试/开发或其他目的，而不会消耗两倍的存储资源。

    简化配置

    我们还可以使用 NetApp FlexVol 技术简化配置。几乎每次新 Oracle 应用程序（或其它项目）进入联机状态时，我们都可以看到数据库对存储量的要求都是非常巨大的。借助灵活卷，我们可以将卷与不同的性能和容量需求相结合，并根据要求变化对它们进行增长和压缩。我们可以跟客户说：“当然，我愿意提供 1TB 用于您的新项目。”我们知道如果不是真正需要空间，它是不会减少的。简化配置可让我们过量地配置存储并在必要时不断的增加卷，而不是预先分配大型卷并在第一年都从不使用它。

    数据保护

    依我的经验，大多数数据保护软件都很难配置，也很难掌握，并且往往不会像广告中所说的那么有效；最终会成为板凳软件。这就是我们如此依赖 Snapshot和 SnapRestore 的原因。它简单，大家都使用并且都相信它。

    我们的数据保护环境正利用 NetApp Snapshot 副本的组合用于满足快速恢复需求和定期磁带备份。既然可以利用 SnapManager for Oracle，我们正考虑将其用于新的部署。我们都知道，从脚本解决方案转移至产品解决方案需要一定时间，但我们也看到了使用产品简化这个过程以及供应商提供支持的优点。我们将最终实现这个目标！

    了解协议差别

    虽然我们对协议不太了解，但显然还是有些差别。正如我之前所说，这些差别还不足以让我们从其它协议中选出一个，但如果您要为您的环境选择一个存储协议那就应该考虑这些差别了。

    我们喜欢 NFS 的易管理性和无状态性。我们可以通过 NFS 一分钟内恢复 200GB 的数据库，这是难能可贵的。另一方面，支持 NFS 的供应商较少，并且 NFS 在各个平台上也不太一致。不同的客户端平台所要求的修补程序集和优化性能调整也各不一样。我们都也知道供应商修补程序会破坏 NFS。好像 direct NFS 会解决许多这样的问题。我们正在就未来部署积极研究这种技术。

    从另一方面看，光纤通道也是主流协议。它在平台之间更加一致、预测性更强、也更可靠。尽管借助 NetApp，它未发生很大改变。但是，它确实增加了管理复杂性并且配置速度也有一些减慢。

    iSCSI 协议易于管理并且和 NFS 一样富有弹性。我们有时为了执行维护采取手动故障转移 iSCSI 上的 NetApp 集群的方法，并且正如 NFS 一样，我们没有出现任何停机情况。由于故障转移速度要非常快，所以应用程序未曾中断。我对碰到不熟悉 iSCSI 的人一直都感到很惊讶，就好像 iSCSI 还没有成为主流。我们已经调查了使用基于硬件的 iSCSI initiator 的情况，但最后决定停止使用它们，因为 CPU 的最低开销不符合卡的成本和其它管理开销。

按协议列出的一些优点和缺点
*借助 Oracle11g 中的 direct NFS 客户端，不再需要修补和调整

    充分利用存储

    在 CHW，我们更愿意购买更少量且更大型的存储系统并将各个系统用于多个工作负荷。除非您有特别的性能要求，否则没有任何理由将存储系统专门分配给一个应用程序。目前的存储系统在大多数情况下都完全可以快速服务多个应用程序。通过选择支持 NFS、CIFS、光纤通道和 iSCSI 的统一存储，我们可以使用最适合应用程序的协议并在必要时作出更改。统一存储可以让我们灵活地满足 Oracle 和其它关键应用程序的所有存储要求。