クラスタ化された環境での構成変更

大部分のアプライアンス構成は、サービスプロパティーとシェア/LUN プロパティーのどちらかで表現されます。シェアおよび LUN プロパティーはストレージプール自体のユーザーデータとともに格納されます (したがって、そのストレージリソースの現在の所有者に常にアクセス可能です) が、サービス構成は各ヘッド内に格納されます。両方のヘッドが一貫性のあるサービスを確実に提供するためには、変更が発生したとき、または以前に停止したヘッドがそのピアに再度参加するときに、すべてのサービスプロパティーが同期化される必要があります。すべてのサービスはレプリカリソースで表現されるため、どちらかのヘッドでプロパティーが変更されるたびに、この同期化はアプライアンスソフトウェアによって自動的に実行されます。

したがって、管理者が構成の変更をレプリケートする必要はありません (実際に冗長になります)。標準の操作手順では、この属性が反映され、初期クラスタ構成が完了したら 2 つのヘッドのどちらかにのみ変更を加えることが求められます。初期クラスタ構成のプロセスでは、既存のすべての構成が新規に構成されたピアにレプリケートされることにも注意してください。一般に、クラスタ化された構成変更では、次の 2 つのベストプラクティスがあります。

• 基になるストレージまたはネットワークインタフェースリソースを現在制御している (新規リソースの作成中の場合は、制御する予定の) ヘッド上で、すべてのストレージおよびネットワーク関連の構成変更を行います。

• 両方のヘッドではなく、どちらかのヘッド上で、その他のすべての変更を行います。サイトポリシーでは、この目的でマスターと見なされるヘッドを指定するべきです。また、どちらのヘッドが機能しているか、および構成されているストレージプールの数に依存するべきです。アプライアンスソフトウェアでは、この区別が行われないことに注意してください。

アムネジア (ピアが機能していない間に個々の構成変更が行われた結果、各ヘッドでの変更が失われる) の問題は、大幅に誇張して説明されています。これは、各ヘッド上のシステム構成に個々の変更を行うメカニズムが存在しない Oracle ZFS Storage Appliance で特に当てはまります。このような単純化によって、集中管理された構成リポジトリの必要性と、単純なアプローチに対する議論が大幅に緩和されます。現在どちらのヘッドが動作していても、適切な構成であると想定され、そのピアがブート時に同期化されます。今後の製品拡張では、構成の不一致を解決するための代替ポリシーを選択できるようになりますが、この基本アプローチが簡単で、理解のしやすさも備えています。つまり、2 番目のヘッドでは、既存の本稼動システムですでに使用されている構成パラメータセットが採用されます (したがって、適切である可能性が高くなります)。確実に適切な状態を維持するために、管理者はクラスタが修復されたらすぐに、障害が発生したヘッドがクラスタに再度参加することを確認してください。