大部分のアプライアンス構成は、サービスプロパティーとシェア/LUN プロパティーのどちらかで表現されます。シェアおよび LUN プロパティーはストレージプール自体のユーザーデータとともに格納されます (したがって、そのストレージリソースの現在の所有者に常にアクセス可能です) が、サービス構成は各コントローラ内に格納されます。両方のコントローラが一貫性のあるサービスを確実に提供するためには、変更が発生したとき、または以前に停止したコントローラがそのピアに再度参加するときに、すべてのサービスプロパティーが同期化される必要があります。すべてのサービスはレプリカリソースで表現されるため、どちらかのコントローラでプロパティーが変更されるたびに、この同期化はアプライアンスソフトウェアによって自動的に実行されます。
そのため、管理者が構成変更をレプリケートすることは不要で冗長となります。標準の操作手順では、この属性が反映され、初期クラスタ構成が完了したら 2 つのコントローラのどちらかにのみ変更を加えることが求められます。初期クラスタ構成のプロセスでは、既存のすべての構成が新規に構成されたピアにレプリケートされることにも注意してください。一般に、クラスタ化された構成変更では、次の 2 つのベストプラクティスがあります。
基になるストレージまたはネットワークインタフェースリソースを現在制御している (新規リソースの作成中の場合は、制御する予定の) コントローラ上で、ストレージおよびネットワーク関連のすべての構成変更を行います。
両方のコントローラではなく、どちらかのコントローラ上で、ほかのすべての変更を行います。サイトポリシーでは、この目的でマスターと見なされるコントローラを指定する必要があります。また、機能しているコントローラと構成されているストレージプールの数によって異なります。アプライアンスソフトウェアでは、この区別が行われないことに注意してください。
アムネジア (ピアが機能していない間に個々の構成変更が行われた結果、各コントローラでの変更が失われる) の問題は、大幅に誇張して説明されています。これは、各コントローラ上のシステム構成に個々の変更を行うメカニズムが存在しない Oracle ZFS Storage Appliance で特に当てはまります。このような単純化によって、集中管理された構成リポジトリの必要性と、単純なアプローチに対する議論が大幅に緩和されます。現在どちらのコントローラが動作していても、適切な構成であると想定され、そのピアがブート時に同期化されます。今後の製品拡張では、構成の不一致を解決するための代替ポリシーを選択できるようになりますが、この基本アプローチは簡単で、理解のしやすさも備えています。つまり、2 番目のコントローラでは、既存の本番システムですでに使用されている構成パラメータセットが採用されます (したがって、適切である可能性が高くなります)。確実に適切な状態を維持するために、管理者はクラスタが修復されたらすぐに、障害が発生したコントローラがクラスタに再度参加することを確認してください。
関連トピック