大部分のアプライアンス構成は、サービスプロパティーとシェア/LUN プロパティーのどちらかで表現されます。シェアおよび LUN プロパティーはストレージプール自体のユーザーデータとともに格納されるため、そのストレージリソースの現在の所有者に常にアクセス可能ですが、サービス構成は各コントローラ内に格納されます。両方のコントローラが一貫性のあるサービスを確実に提供するためには、変更が発生したとき、または以前に停止したコントローラがそのピアに再度参加するときに、すべてのサービスプロパティーが同期化される必要があります。すべてのサービスはレプリカリソースで表現されるため、どちらかのコントローラでプロパティーが変更されるたびに、この同期化はアプライアンスソフトウェアによって自動的に実行されます。
そのため、管理者が構成変更をレプリケートすることは不要で冗長となります。標準の操作手順では、この属性が反映され、初期クラスタ構成が完了したら 2 つのコントローラのどちらかにのみ変更を加えることが求められます。初期クラスタ構成のプロセスでは、既存のすべての構成が新規に構成されたピアにレプリケートされます。
クラスタ化された構成変更では、次のベストプラクティスがあります。
基になるストレージまたはネットワークインタフェースリソースを現在制御している (新規リソースの作成中の場合は、制御する予定の) コントローラ上で、ストレージおよびネットワークのすべての構成変更を行います。
両方のコントローラではなく、どちらかのコントローラ上で、ほかのすべての変更を行います。マスターコントローラとして指定するコントローラは、機能しているコントローラと構成されているストレージプールの数によって異なります。
Oracle ZFS Storage Appliance には、各コントローラ上のシステム構成に対して独立した変更を行うためのメカニズムが存在しません。この単純化によって、集中管理された構成リポジトリの必要性が減少します。現在動作しているコントローラが適切な構成であると想定され、そのピアがブート時に同期化されます。ピアは、既存の本番システムですでに使用されている構成パラメータのセットを採用しているため、適切である可能性が高くなります。ベストプラクティスとして、クラスタが修復されたらすぐに、障害が発生したコントローラがクラスタに再度参加することを確認してください。
関連トピック