存储的群集注意事项

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

请注意，在任一配置中，要使用任何 ReadZilla 设备，必须在分配了相应池所有权的机头上导入将设备分配到的池。也就是说，如果某个池因机头故障而被接管，即使导入该池的机头上也安装了未使用的 ReadZilla，也没有该池的读取缓存。出于这一原因，应按照Chapter 5, 存储配置文档中的说明配置主动-被动群集中的 ReadZilla。这不适用于 LogZilla 设备，LogZilla 位于存储结构中，始终可由已导入了池的机头访问。

表 10-5存储的群集注意事项

变量

单节点所有权

不同机头拥有多个池

总吞吐量(额定操作)

在任何时间最多可使用总 CPU 资源的 50%、DRAM 的 50% 和总网络连接的 50% 来提供服务。这种情况非常简单：只有一个机头处理客户机请求，因而另一个处于闲置状态。

在任何时间均可使用所有 CPU 和 DRAM 资源来提供服务。在任何时间最多可使用所有网络连接的 50%(需要在每个机头上安装备用网络设备来支持故障转移)。

总吞吐量(故障转移)

相对于额定操作，吞吐量无变化。

将使用未发生故障的机头的全部资源来提供服务。相对于额定操作，总吞吐量范围从大约 40% 到 100%，具体取决于额定操作期间的利用率。

I/O 延迟(故障转移)

ReadZilla 在故障转移操作期间不可用，对于适合可用的读取高速缓存的读取操作繁重的工作负荷，这会显著增加延迟。写入操作的延迟不受影响。

ReadZilla 在故障转移操作期间不可用，对于适合可用的读取高速缓存的读取操作繁重的工作负荷，这会显著增加延迟。读取和写入操作的延迟可能会因机头资源争用加剧而有所增加。原因是在未发生故障的机头上运行两种工作负荷而非通常的一种。每个机头上的额定工作负荷接近机头的最大能力时，故障转移状态下的延迟可能会非常高。

存储灵活性

共享资源和 LUN 可使用所有可用的物理存储。

特定池的共享资源和 LUN 只能使用分配给该池的存储。存储并不在池之间共享，因此如果一个池空间已满而另一个池具有可用空间，就会浪费某些存储。

网络连接

在每个机头提供服务的同时，可使用该机头上的所有网络设备。

在每个机头提供服务的同时，只能使用该机头上所有网络设备的一半。因此，每个池只能连接到物理上不相交的网络中的一半。

第二个重要的存储注意事项是采用无单点故障 (No Single Point of Failure, NSPF) 的池配置。由于使用群集意味着应用程序非常注重可用性，因此几乎没有充分的理由将存储池配置为允许单个 JBOD 发生故障导致可用性降低。这种方法的弊端是，NSPF 配置需要的 JBOD 数量多于单点故障配置，如果所需容量非常小，安装足够多的 JBOD 以在所需 RAID 级别实现 NSPF 可能并不经济。