La majorité de la configuration de l'appareil est représentée par des propriétés service ou des propriétés partage/LUN. Alors que les propriétés partage et LUN sont stockées avec les données de l'utilisateur sur le pool de stockage (et sont par conséquent toujours accessibles au propriétaire en cours de cette ressource de stockage), la configuration de service est stockée dans chaque tête. Afin de garantir que les deux têtes fournissent un service cohérent, toutes les propriétés service doivent être synchronisées en cas de modification ou lorsqu'une tête précédemment hors service rejoint son pair. Etant donné que tous les services sont représentés par des ressources réplique, la synchronisation est automatiquement effectuée par le logiciel de l'appareil dès lors qu'une propriété est modifiée sur l'une des têtes.
Par conséquent, il n'est pas nécessaire pour les administrateurs de répliquer les modifications de la configuration, et ce serait redondant. Les procédures de fonctionnement standard doivent refléter cet attribut et appeler à des modifications sur une seule des deux têtes en cas de modification de la configuration du cluster d'origine. Notez également que le processus de configuration du cluster d'origine réplique toute la configuration existante sur le pair bénéficiant d'une nouvelle configuration. Il en découle généralement deux meilleures pratiques en matière de modification de la configuration en cluster :
Apporter toutes les modifications de la configuration liées au stockage et au réseau sur la tête qui contrôle actuellement (ou contrôlera plus tard, si une nouvelle ressource est en cours de création) les ressources de stockage ou d'interface réseau sous-jacentes.
Apporter toutes les autres modifications sur une des têtes, mais pas les deux. La stratégie de site doit permettre de spécifier la tête principale à utiliser, qui doit à son tour dépendre de la tête qui fonctionne et du nombre de pools de stockage configurés. Notez que le logiciel de l'appareil ne fait pas cette distinction.
Le problème d'amnésie, selon lequel des modifications disjointes de configuration sont effectuées puis perdues sur chaque tête lorsque son pair ne fonctionne pas, est très surestimé. Cela est particulièrement vrai pour la série Oracle ZFS Storage Appliance, qui n'inclut aucun mécanisme pour effectuer des modifications indépendantes de la configuration système sur chaque tête. Cette simplification réduit considérablement le besoin de référentiels de configuration centralisés et plaide pour une approche simplifiée : la tête en cours de fonctionnement est censée détenir la configuration appropriée et son pair sera synchronisé par rapport à elle lors de l'initialisation. Alors que des améliorations futures du produit pourront permettre de sélectionner une stratégie alternative pour la résolution des divergences de configuration, cette approche basique est simple et facile à comprendre : la deuxième tête adopte un ensemble de paramètres de configuration déjà utilisés par un système de production existant (dont le degré d'exactitude est par conséquent très élevé). Pour s'assurer que cela reste vrai, les administrateurs doivent vérifier qu'une tête défaillante rejoint le cluster dès sa réparation.