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

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 的最低开销不符合卡的成本和其它管理开销。

按协议列出的一些优点和缺点。