存储的群集注意事项

语言：

为了在群集中使用而对 Oracle ZFS Storage Appliance 进行大小调整时，另有两个非常重要的注意事项。或许最重要的决定是将所有存储池的所有权分配给同一机头还是在两个机头之间分割。此处有几点要加以权衡，如下表中所示。一般来说，应该在一个机头上配置池，但额定操作期间针对吞吐量优化或故障转移性能不容考虑时除外。处于故障转移状态时性能特征的确切变化在很大程度上取决于工作负荷的性质和大小。一般来说，某个机头沿任何特定轴提供的性能越接近最大值，工作负荷由该机头的对等设备接管时沿该轴的性能下降越明显。当然，如果包含多个池，两种工作负荷的性能都会下降。

ReadZilla 设备不遵循接管或故障恢复情况下的数据池。在 ReadZilla 驻留的节点上导入分配给读取高速缓存设备的池时，ReadZilla 仅在特定群集节点上处于活动状态。没有其他配置步骤，读取高速缓存将无法用于由于故障转移事件而迁移的池。为了对不是由群集对等设备所拥有的池启用 ReadZilla，请在非拥有节点上接管该池，然后添加存储并选择要配置的高速缓存设备。应按照Storage Configuration文档中的说明配置群集节点中的 ReadZilla。与 ReadZilla 不同，LogZilla 设备位于存储结构中，始终可由已导入了池的机头访问。

表 47 存储的群集注意事项

可变因素	单节点所有权	不同机头拥有多个池
总吞吐量（额定操作）	在任何时间最多可使用总 CPU 资源的 50%、DRAM 的 50% 和总网络连接的 50% 来提供服务。这种情况非常简单：只有一个机头处理客户机请求，因而另一个处于闲置状态。	在任何时间均可使用所有 CPU 和 DRAM 资源来提供服务。在任何时间最多可使用所有网络连接的 50%（需要在每个机头上安装备用网络设备来支持故障转移）。
总吞吐量（故障转移）	相对于额定操作，吞吐量无变化。	将使用未发生故障的机头的全部资源来提供服务。相对于额定操作，总吞吐量范围从大约 40% 到 100%，具体取决于额定操作期间的利用率。
I/O 延迟（故障转移）	ReadZilla 在故障转移操作期间不可用，对于适合可用的读取高速缓存的读取操作繁重的工作负荷，这会显著增加延迟。写入操作的延迟不受影响。	ReadZilla 在故障转移操作期间不可用，对于适合可用的读取高速缓存的读取操作繁重的工作负荷，这会显著增加延迟。读取和写入操作的延迟可能会因机头资源争用加剧而有所增加。原因是在未发生故障的机头上运行两种工作负荷而非通常的一种。每个机头上的额定工作负荷接近机头的最大能力时，故障转移状态下的延迟可能会非常高。
存储灵活性	共享资源和 LUN 可使用所有可用的物理存储。	特定池的共享资源和 LUN 只能使用分配给该池的存储。存储并不在池之间共享，因此如果一个池空间已满而另一个池具有可用空间，就会浪费某些存储。
网络连接	在每个机头提供服务的同时，可使用该机头上的所有网络设备。	在每个机头提供服务的同时，只能使用该机头上所有网络设备的一半。因此，每个池只能连接到物理上不相交的网络中的一半。

第二个重要的存储注意事项是采用无单点故障 (No Single Point of Failure, NSPF) 的池配置。由于使用群集意味着应用程序非常注重可用性，因此几乎没有充分的理由将存储池配置为允许单个磁盘机框发生故障导致可用性降低。这种方法的缺点是：NSPF 配置所需的磁盘机框数量比使用闪电战故障配置多；当所需容量很小时，为了在所需的 RAID 级别提供 NSPF 而安装足够的磁盘机框可能在经济上并不划算。