Go to main content

Oracle® ZFS Storage Appliance 管理ガイド、Release OS8.8.x

印刷ビューの終了

更新: 2021 年 8 月
 
 

クラスタリソース管理

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

もっとも重要な 3 つのリソースタイプは、レプリカ、シングルトン、プライベートです。

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

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

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

もう 1 つのデータタイプがシンビオートです。シンビオートでは、インポートおよびエクスポートされたときにリソースが別のリソースに従うことができます。たとえば、シンビオートを使用して、ストレージプールのディスクおよびフラッシュデバイスを表現できます。

次の図は、シェアリソースを含むクラスタ構成の例を示しています。

図 4  ZS3-2 のクラスタ構成の例

image:クラスタ構成の例

次の表では、異なるクラスタリソースタイプの特性について説明します。

表 13  クラスタリソースタイプ
リソース
アイコン
遍在
障害時のテイクオーバー
シングルトン
image:無効になったロックアイコンを示す図
いいえ
はい
レプリカ
なし
はい
該当なし
プライベート
image:ロックアイコンを示す図
いいえ
いいえ
シンビオート
なし
親タイプと同じ
親タイプと同じ

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

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

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

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

  • シャーシに指定された名前は、割り当てられたコントローラにのみ表示されます。

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

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

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

関連トピック