绝大多数设备配置都以服务属性或共享资源/LUN 属性表示。共享资源和 LUN 属性随用户数据一起存储在存储池自身中（因而始终可由该存储资源的当前所有者访问），而服务配置存储在每台控制器中。为了确保两台控制器提供一致的服务，发生更改或之前发生故障的控制器与其对等设备重新链接时，必须同步所有服务属性。由于所有服务都由副本资源表示，因此任何时间在任一控制器上更改属性时，设备软件都会自动执行此同步。
因此，管理员没有必要（实在多余）复制配置更改。标准操作过程应该反映这一属性，要求在初始群集配置完成后只对两台控制器中的一个进行更改。另请注意，在初始群集配置过程中，会将现有全部配置复制到新配置的对等设备上。因此，一般来说，我们得出群集配置更改的两个最佳做法：
在当前控制（或者将控制（如果将要创建新资源））底层存储或网络接口资源的控制器上进行所有与存储和网络相关的配置更改。
在任一控制器上进行其他所有更改，但不能同时在两台控制器上进行更改。为此，站点策略应指定考虑将哪台控制器用作主控制器，进而确定哪一台控制器在起作用以及已配置的存储池的数量。请注意，设备软件并不做此区分。
失忆是指进行不相交配置更改，随后在每台控制器上丢失，而对等设备无法正常运行，这一问题在很大程度上有所夸大。对于 Oracle ZFS Storage Appliance 尤其如此，因为没有在每台控制器上对系统配置进行独立更改的机制。这种简化大大降低了对集中配置系统信息库的需求，并且支持一种更为简单的方法：假设当前正在运行的控制器具有正确的配置，其对等设备将在引导时与其同步。随着将来产品功能的增强，可以选择替代策略来解决配置差异，这种基本方法非常简单而且易于理解：第二台控制器将采用现有生产系统已经使用的一组配置参数（因此极有可能正确）。为确保这种方法合适，管理员应确保发生故障的控制器在修复后立即重新链接群集。
相关主题