群集环境中的配置更改

绝大多数设备配置都以服务属性或共享资源/LUN 属性表示。共享资源和 LUN 属性随用户数据存储在存储池自身中（因而始终可由该存储资源的当前所有者访问），而服务配置存储在每个机头中。为了确保两个机头提供一致的服务，发生更改或之前发生故障的机头与其对等设备重新链接时，必须同步所有服务属性。由于所有服务都由副本资源表示，因此任何时间在任一机头上更改属性时，设备软件都会自动执行此同步。

因此，管理员没有必要（实在多余）复制配置更改。标准操作过程应该反映这一属性，要求在初始群集配置完成后只对两个机头中的一个进行更改。另请注意，在初始群集配置过程中，会将现有全部配置复制到新配置的对等设备上。因此，一般来说，我们得出群集配置更改的两个最佳做法：

• 在当前控制（或者将控制（如果将要创建新资源））底层存储或网络接口资源的机头上进行所有与存储和网络相关的配置更改。

• 在任一机头而非两个机头上进行其他所有更改。站点策略应指定将哪个机头视为该用途的主机头，进而应取决于正常运行的机头以及已配置的存储池数量。请注意，设备软件并不做此区分。

失忆是指进行不相交配置更改，随后在每个机头上丢失，而对等设备无法正常运行，这一问题在很大程度上有所夸大。对于 Oracle ZFS Storage Appliance 尤其如此，因为没有在每个机头上对系统配置进行独立更改的机制。这种简化大大降低了对集中配置系统信息库的需求，并且支持一种更为简单的方法：假设当前正在运行的机头具有正确的配置，其对等设备将在引导时与其同步。随着将来产品功能的增强，可以选择替代策略来解决配置差异，这种基本方法非常简单而且易于理解：第二个机头将采用现有生产系统已经使用的一组配置参数（因此极有可能正确）。为确保这种方法合适，管理员应确保发生故障的机头在修复后立即重新链接群集。