クラスタリソース管理

リソースマネージャーは、適切なネットワークインタフェースセットが plumb され、適切なストレージプールがアクティブであり、数多くの構成パラメータがクラスタ化された 2 つのヘッド間で同期化された状態であることを確認する役割があります。このサブシステムのアクティビティーの大部分は、管理者には表示されません。ただし、重要な側面が 1 つ表示されます。リソースは、インポート (アクティブ化) されるタイミングおよびインポート (アクティブ化) するかどうかによって複数のタイプに分類されます。アクティブの定義は、リソースクラスによって異なることに注意してください。たとえば、ネットワークインタフェースはネットクラスに属し、インタフェースが起動したときにアクティブになります。もっとも重要な 3 つのリソースタイプは、シングルトン、プライベート、およびレプリカです。

レプリカはもっとも単純です。管理者には表示されず、クラスタ構成画面にも表示されません (図 4 を参照)。レプリカは常に存在し、両方のヘッドで常にアクティブです。一般に、これらのリソースは単純に、2 つのヘッド間で同期化する必要があるサービスプロパティー用のコンテナとして動作します。

レプリカと同様に、シングルトンリソースでは状態が同期化されます。ただし、シングルトンは正確に 1 つのヘッドで常にアクティブになっています。管理者は、各シングルトンが通常アクティブになっているヘッドを選択できます。該当ヘッドに障害が発生すると、そのピアでシングルトンがインポートされます。シングルトンは、クラスタ化の可用性特性にとって重要です。シングルトンは、障害が発生したヘッドから動作しているピアに移動すると一般に考えられているリソースであり、ネットワークインタフェースおよびストレージプールが含まれます。ネットワークインタフェースはクライアントが既知のストレージサービスセットを検索するときに使用する IP アドレスのコレクションであるため、該当するインタフェースのアドレスへのアクセス時にクライアントに表示されるであろうストレージプールと同じヘッドに、各インタフェースが割り当てられることが重要となります。図 4 では、PrimaryA インタフェースに関連付けられたすべてのアドレスは、常にインポート済みのプール 0 を含むヘッドで提供されます。一方、PrimaryB インタフェースに関連付けられたすべてのアドレスは、常にプール 1 と同じヘッドで提供されます。

プライベートリソースは、割り当てられたヘッドにのみ認識され、障害発生時にテイクオーバーされません。一般に、これはネットワークインタフェースでのみ役立ちます。特定のユースケースについては、以降の説明を参照してください。

図 2-22  ZS3-2 のクラスタ化の例

リソースタイプは、ほかにも複数存在します。これらは、管理者には表示されない実装の詳細です。このようなタイプの 1 つがシンビオートです。このリソースでは、インポートおよびエクスポートされたときに別のリソースに従うことができます。このリソースタイプのもっとも重要な使用法は、ストレージプールのディスクおよびフラッシュデバイスを表現するときです。このようなリソースはディスクセットと呼ばれ、リソースが含まれる ZFS プールよりも前に常にインポートされる必要があります。各ディスクセットは、外部ストレージ格納装置内のディスクの半分で構成されます。クラスタ化されたストレージシステムには、任意の数のディスクセットを接続でき (ハードウェアサポートによって異なる)、各 ZFS プールは 1 つ以上のディスクセット内のストレージデバイスで形成されます。ディスクセットには ATA デバイスが含まれる場合があるため、マルチパス環境で使用される ATA デバイスに固有のアフィリエーション関連の動作を回避するには、明示的にインポートおよびエクスポートする必要があります。ディスクをリソースとして表現することは、これらのアクティビティーを適切なときに実行するための簡単な方法です。管理者がストレージプールの所有権を設定または変更すると、同時にこれに関連付けられたディスクセットの所有権の割り当ても透過的に変更されます。すべてのシンビオートと同様に、ディスクセットリソースはクラスタ構成ユーザーインタフェースには表示されません。

表 2-36  クラスタリソース管理

リソース アイコン 偏在 障害時のテイクオーバー シングルトン いいえ はい レプリカ なし はい 該当なし プライベート いいえ いいえ シンビオート なし 親タイプと同じ 親タイプと同じ

新規リソースが作成されると、まずリソースが作成されるヘッドに割り当てられます。ヘッドが AKCS_OWNER 状態でないかぎり、この所有権は変更できません。したがって、通常はリソースを所有するヘッド上にリソースを作成するか、またはリソースの所有権を変更する前にテイクオーバーする必要があります。一般に、どちらか一方のヘッドからリソースを削除できますが、エクスポートされたストレージプールを削除することはできません。通常、割り当てられた所有者がどちらのヘッドであるかに関係なく、現在管理されているヘッド上のリソースを削除すると最適な結果が得られます。

大部分の構成設定 (サービスプロパティー、ユーザー、ロール、アイデンティティーマッピング規則、SMB 自動ホーム、iSCSI イニシエータ定義など) は、両方のヘッドで自動的にレプリケートされます。したがって、クラスタの状態に関係なく、これらの設定を両方のヘッドで構成する必要はありません。構成が変更されたときに一方のアプライアンスが停止した場合は、サービスを提供する前に、次のブートでクラスタに再度参加するときに他方のアプライアンスにレプリケートされます。次のような例外が多少あります。

• シェアおよび LUN の定義およびオプションは、そのプールが通常割り当てられているヘッドに関係なく、基になるプールを制御するヘッドにのみ設定できます。

• 「アイデンティティー」サービスの構成 (アプライアンス名や場所など) はレプリケートされません。

• シャーシに指定された名前は、割り当てられたヘッドにのみ表示されます。

• 各ネットワークルートは、特定のインタフェースにバインドされます。各ヘッドに特定のサブネット内のアドレスを持つインタフェースが割り当てられ、そのサブネットにアプライアンスがトラフィックを制御するためのルーターが存在する場合は、同じゲートウェイアドレスが使用されている場合でも、インタフェースごとにルートを作成する必要があります。これにより、基になるネットワークリソースが 2 つのヘッド間をシフトするときに、各ルートが個別にアクティブになることが可能になります。詳細は、ネットワークの考慮点を参照してください。

• SSH ホスト鍵はレプリケートされず、シェアも行われません。したがって、プライベート管理インタフェースが構成されていない場合、障害が発生したノードに割り当てられたアドレスを使用して CLI にログインしようとすると、鍵が一致しない可能性があります。同じ制限が、BUI へのアクセスに使用される SSL 証明書に適用されます。

そのあと、共通構成が透過的にレプリケートされ、管理者が各アプライアンスヘッドにリソースのコレクションを割り当てることが基本モデルとなります。次に、これらのリソース割り当てによって、クライアントに表示されるストレージリソースにネットワークアドレスがバインドされます。どちらのアプライアンスがリソースのコレクションを制御するのかに関係なく、クライアントは予期されるネットワークの場所で必要なストレージにアクセスできます。