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 contrôleur. Afin de garantir que les deux contrôleurs fournissent un service cohérent, toutes les propriétés service doivent être synchronisées en cas de modification ou lorsqu'un contrôleur 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'un des contrôleurs.
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 un seul des deux contrôleurs 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 :
Apportez toutes les modifications de la configuration liées au stockage et au réseau sur le contrôleur 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.
Apportez toutes les autres modifications à l'un des contrôleurs, mais pas aux deux. La stratégie du site doit indiquer quel contrôleur doit alors être considéré comme le maître, ce qui dépend à son tour de quel contrôleur est en cours de fonctionnement et du nombre de pools de stockage qui ont été 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 contrôleur 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 contrôleur. Cette simplification réduit considérablement le besoin de référentiels de configuration centralisés et plaide pour une approche simplifiée : le contrôleur en cours de fonctionnement est censé détenir la configuration appropriée et son pair sera synchronisé par rapport à lui 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 : le deuxième contrôleur 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'un contrôleur défaillant rejoint le cluster dès sa réparation.
Rubriques connexes