クラスタリソース管理
リソースマネージャーは、適切なネットワークインタフェースセットが plumb され、適切なストレージプールがアクティブであり、多数の構成パラメータが 2 つのクラスタ化コントローラ間で同期化された状態であることを確認する役割があります。このサブシステムのアクティビティーの大部分は、管理者には表示されません。ただし、重要な側面が 1 つ表示されます。リソースは、インポート (アクティブ化) されるタイミングおよびインポート (アクティブ化) するかどうかによって複数のタイプに分類されます。アクティブの定義は、リソースクラスによって異なることに注意してください。たとえば、ネットワークインタフェースはネットクラスに属し、インタフェースが起動したときにアクティブになります。
もっとも重要な 3 つのリソースタイプは、シングルトン、プライベート、およびレプリカです。
-
レプリカリソース - レプリカはもっとも単純です。管理者には表示されず、クラスタ構成画面にも表示されません。レプリカは常に存在し、両方のコントローラで常にアクティブです。一般に、これらのリソースは単純に、2 つのコントローラ間で同期化する必要があるサービスプロパティー用のコンテナとして動作します。
-
シングルトンリソース - レプリカと同様に、シングルトンリソースでは状態が同期化されます。ただし、シングルトンは正確に 1 つのコントローラで常にアクティブになっています。管理者は、各シングルトンが通常アクティブになっているコントローラを選択できます。該当コントローラに障害が発生すると、そのピアでシングルトンがインポートされます。シングルトンは、クラスタ化の可用性特性にとって重要です。シングルトンは、通常、障害が発生したコントローラから動作しているピアに移動すると考えられているリソースであり、ネットワークインタフェースおよびストレージプールが含まれます。ネットワークインタフェースはクライアントが既知のストレージサービスセットを検索するときに使用する IP アドレスのコレクションであるため、該当するインタフェースのアドレスへのアクセス時にクライアントに表示されるであろうストレージプールと同じコントローラに、各インタフェースが割り当てられることが重要となります。図 4 では、PrimaryA インタフェースに関連付けられたすべてのアドレスは、常にインポート済みのプール 0 を含むコントローラで提供されます。一方、PrimaryB インタフェースに関連付けられたすべてのアドレスは、常にプール 1 と同じコントローラで提供されます。
-
プライベートリソース - プライベートリソースは、割り当てられたコントローラにのみ認識され、障害発生時にテイクオーバーされません。一般に、これはネットワークインタフェースでのみ役立ちます。特定のユースケースについては、以降の説明を参照してください。
図 16 ZS3-2 のクラスタ化の例
リソースタイプは、ほかにも複数存在します。これらは、管理者には表示されない実装の詳細です。このようなタイプの 1 つがシンビオートです。このリソースでは、インポートおよびエクスポートされたときに別のリソースに従うことができます。このリソースタイプのもっとも重要な使用法は、ストレージプールのディスクおよびフラッシュデバイスを表現するときです。このようなリソースはディスクセットと呼ばれ、リソースが含まれる ZFS プールよりも前に常にインポートされる必要があります。各ディスクセットは、外部ストレージエンクロージャー内のディスクの半分で構成されます。クラスタ化されたストレージシステムには、任意の数のディスクセットを接続でき (ハードウェアサポートによって異なる)、各 ZFS プールは 1 つ以上のディスクセット内のストレージデバイスで形成されます。ディスクセットには ATA デバイスが含まれる場合があるため、マルチパス環境で使用される ATA デバイスに固有のアフィリエーション関連の動作を回避するには、明示的にインポートおよびエクスポートする必要があります。ディスクをリソースとして表現することは、これらのアクティビティーを適切なときに実行するための簡単な方法です。管理者がストレージプールの所有権を設定または変更すると、同時にこれに関連付けられたディスクセットの所有権の割り当ても透過的に変更されます。すべてのシンビオートと同様に、ディスクセットリソースはクラスタ構成ユーザーインタフェースには表示されません。
|
新規リソースが作成されると、まずリソースが作成されるコントローラに割り当てられます。コントローラが AKCS_OWNER 状態でないかぎり、この所有権は変更できません。したがって、通常はリソースを所有するコントローラ上にリソースを作成するか、またはリソースの所有権を変更する前にテイクオーバーする必要があります。一般に、どちらか一方のコントローラからリソースを削除できますが、エクスポートされたストレージプールを削除することはできません。通常、割り当てられた所有者がどちらのコントローラであるかに関係なく、現在管理されているコントローラ上のリソースを破棄すると最適な結果が得られます。
大部分の構成設定 (サービスプロパティー、ユーザー、ロール、アイデンティティーマッピング規則、SMB 自動ホーム、iSCSI イニシエータ定義など) は、両方のコントローラで自動的にレプリケートされます。したがって、クラスタの状態に関係なく、これらの設定を両方のコントローラで構成する必要はありません。構成が変更されたときに一方のアプライアンスが停止した場合は、サービスを提供する前に、次のブートでクラスタに再度参加するときに他方のアプライアンスにレプリケートされます。次のような例外が多少あります。
-
シェアおよび LUN の定義およびオプションは、そのプールが通常割り当てられているコントローラに関係なく、基になるプールを制御するコントローラにのみ設定できます。
-
「アイデンティティー」サービスの構成 (アプライアンス名や場所など) はレプリケートされません。
-
シャーシに指定された名前は、割り当てられたコントローラにのみ表示されます。
-
各ネットワークルートは、特定のインタフェースにバインドされます。各コントローラに特定のサブネット内のアドレスを持つインタフェースが割り当てられ、そのサブネットにアプライアンスがトラフィックを制御するためのルーターが存在する場合は、同じゲートウェイアドレスが使用されている場合でも、インタフェースごとにルートを作成する必要があります。これにより、基になるネットワークリソースが 2 つのコントローラ間をシフトするときに、各ルートが個別にアクティブになることが可能になります。詳細は、クラスタ化におけるネットワークの考慮点を参照してください。
-
SSH ホスト鍵はレプリケートされず、シェアも行われません。したがって、プライベート管理インタフェースが構成されていない場合、障害が発生したノードに割り当てられたアドレスを使用して CLI にログインしようとすると、鍵が一致しない可能性があります。同じ制限が、BUI へのアクセスに使用される SSL 証明書に適用されます。
そのあと、共通構成が透過的にレプリケートされ、管理者が各アプライアンスコントローラにリソースのコレクションを割り当てることが基本モデルとなります。次に、これらのリソース割り当てによって、クライアントに表示されるストレージリソースにネットワークアドレスがバインドされます。どちらのアプライアンスがリソースのコレクションを制御するのかに関係なく、クライアントは予期されるネットワークの場所で必要なストレージにアクセスできます。
関連トピック