test

Sun Cluster データサービスの計画と管理 (Solaris OS 版)

第 2 章 データサービスリソースの管理

この章では、Sun Cluster の保守コマンドを使って、クラスタ内のリソース、リソースグループ、およびリソースタイプを管理する手順を説明します。そのほかのツールを使用して手順を完了できるかどうかを判断するには、「データサービスリソースを管理するためのツール」を参照してください。

リソースタイプ、リソースグループ、およびリソースの概要については、第 1 章「Sun Cluster データサービスの計画」および『Sun Cluster の概念 (Solaris OS 版) 』を参照してください。

この章の内容は次のとおりです。

データサービスリソースの管理作業の概要

次の表に、Sun Cluster データサービスのインストールと構成作業の概要を示します。作業手順の詳細が記載されている参照先も示します。

表 2–1 データサービスリソースを管理するための作業

作業 

参照先 

リソースタイプを登録する 

「リソースタイプを登録する」

リソースタイプをアップグレードする 

「既存のリソースを新バージョンのリソースタイプに移行する」

「アップグレードされたリソースタイプをインストールして登録する」

リソースタイプをダウングレードする 

「古いバージョンのリソースタイプにダウングレードする方法」

フェイルオーバーリソースグループまたはスケーラブルリソースグループの作成 

「フェイルオーバーリソースグループを作成する」

「スケーラブルリソースグループを作成する」

論理ホスト名または共有アドレス、データサービスリソースをリソースグループに追加する 

「clsetup ユーティリティーを使用して論理ホスト名リソースをリソースグループに追加する」

「コマンド行インタフェースを使用して論理ホスト名リソースをリソースグループに追加する」

「clsetup ユーティリティーを使用して共有アドレスリソースをリソースグループに追加する」

「コマンド行インタフェースを使用して共有アドレスリソースをリソースグループに追加する」

「フェイルオーバーアプリケーションリソースをリソースグループに追加する」

「スケーラブルアプリケーションリソースをリソースグループに追加する」

リソースとリソースモニターを有効にし、リソースグループを管理し、リソースグループおよび関連するリソースをオンラインにする 

「リソースを有効にする」

「リソースグループをオンラインにする」

リソースグループを休止する 

「リソースグループを休止する」

「ただちにリソースグループを休止する」

リソースグループの自動回復アクションを保存停止および再開する 

「リソースグループの自動回復アクションを保存停止する」

「リソースグループの自動回復アクションをただちに保存停止する」

「リソースグループの自動回復アクションを再開する」

リソース自体とは関係なく、リソースモニターだけを無効または有効にする 

「リソース障害モニターを無効にする」

「リソース障害モニターを有効にする」

クラスタからリソースタイプを削除する 

「リソースタイプを削除する」

クラスタからリソースグループを削除する 

「リソースグループを削除する」

リソースグループからリソースを削除する 

「リソースを削除する」

リソースグループの稼動系を切り替える 

「リソースグループの主ノードを切り替える」

リソースを無効にし、そのリソースグループを UNMANAGED 状態に移行する

「リソースを無効にしてリソースグループを UNMANAGED 状態に移行する」

リソースタイプ、リソースグループ、リソース構成情報を表示する 

「リソースタイプ、リソースグループ、リソース構成情報の表示」

リソースタイプ、リソースグループ、リソースプロパティーの変更 

「リソースタイププロパティーを変更する」

「リソースグループプロパティーを変更する」

「リソースプロパティーを変更する」

失敗した リソースグループマネージャー (RGM) プロセスのエラーフラグの消去 

「リソースの STOP_FAILED エラーフラグを消去する」

Start_failed リソース状態の消去

「リソースグループのスイッチオーバーにより Start_failed リソース状態を解除する」

「リソースグループの再起動により Start_failed リソース状態を解除する」

「リソースの無効化および有効化によりリソース状態 Start_failed を解除する」

組み込みリソースタイプ LogicalHostname および SharedAddress の再登録

「事前登録されているリソースタイプを誤って削除した後に再登録する」

ネットワークリソースのネットワークインタフェース ID リストの更新と、リソースグループのノードリストの更新 

「リソースグループにノードを追加する」

リソースグループからノードを削除する 

「リソースグループからノードを削除する」

大域ゾーンから非大域ゾーンへアプリケーションを移行する 

「大域ゾーンから非大域ゾーンへアプリケーションを移行する」

リソースグループとデバイスグループ間で起動の同期をとるために、リソースグループの HAStoragePlus を設定する

「新しいリソース用に HAStoragePlus リソースタイプを設定する」

「既存のリソース用に HAStoragePlus リソースタイプを設定する」

「クラスタファイルシステム用に HAStoragePlus リソースを設定する」

「clsetup ユーティリティーを使用することで HAStoragePlus リソースタイプを設定する」

HAStoragePlus を設定してローカル Solaris ZFS を高可用性にする

「HAStoragePlus リソースタイプを設定し、ローカル Solaris ZFS を高可用性にする」

HAStorage から HAStoragePlus へアップグレードする

「デバイスグループまたは CFS を使用している場合に HAStorage から HAStoragePlus へアップグレードする」

「CFS による HAStorage から高可用性ローカルファイルシステムによる HAStoragePlus へアップグレードする」

高可用性ファイルシステムのリソースをオンラインのままで変更する 

「高可用性ファイルシステムのリソースをオンラインのままで変更する」

広域ファイルシステムを、HAStoragePlus リソースのローカルファイルシステムに変更する

「HAStoragePlus リソースの広域ファイルシステスムからローカルファイルシステムへの変更」

組み込みリソースタイプ LogicalHostname および SharedAddress のアップグレード

「リソースタイプの更新」

「事前登録されているリソースタイプのアップグレード」

HAStoragePlus リソースタイプをアップグレードする

「リソースタイプの更新」

「HAStoragePlus リソースタイプのアップグレード」

リソースグループをオンラインのままでクラスタノード間で分散する 

「オンラインのリソースグループをクラスタノード間で分散する」

リソースグループ、リソースタイプ、およびリソースの構成データを複製およびアップグレードする 

「リソースグループ、リソースタイプ、およびリソースの構成データを複製およびアップグレードする」

Sun Cluster 上で Solaris SMF サービスを有効にする 

「Sun Cluster 上で Solaris SMF サービスを有効にする」

Sun Cluster データベース用に障害モニターを調整する 

「Sun Cluster データサービス用に障害モニターを調整する」

注 –

この章の各手順では Sun Cluster の保守コマンドを使ってこれらの作業を行いますが、これ以外のツールを使ってリソースを管理することもできます。このようなオプションの詳細については、「データサービスリソースを管理するためのツール」を参照してください。

Sun Cluster データサービスの構成と管理

Sun Cluster データサービスの構成には次の作業が必要です。

データサービスの構成を変更するには、初期構成が終わった後で次の各手順を使用します。たとえば、リソースタイプ、リソースグループ、およびリソースプロパティーを変更するには、「リソースタイプ、リソースグループ、リソースプロパティーの変更」に進みます。

リソースタイプの登録

リソースタイプは、指定されたタイプのすべてのリソースに適用される共通のプロパティーとコールバックメソッドの仕様を提供します。リソースタイプは、そのタイプのリソースを作成する前に登録する必要があります。リソースタイプの詳細については、第 1 章「Sun Cluster データサービスの計画」を参照してください。

Procedureリソースタイプを登録する

注 –

この手順は、任意のクラスタノードから実行します。

始める前に

登録するリソースタイプに名前が付けられていることを確認します。リソースタイプの名前はデータサービス名の省略型です。Sun Cluster に標準添付されているデータサービスのリソースタイプ名の詳細は、Sun Cluster のリリースノートを参照してください。

  1. クラスタメンバーで、スーパーユーザーになるか、solaris.cluster.modify RBAC の承認を提供する役割になります。

  2. リソースタイプを登録します。


    # clresourcetype register resource-type
    resource-type

    追加するリソースタイプの名前を指定します。指定する事前定義済みの名前を判別するには、Sun Cluster のリリースノートを参照してください。

  3. 登録されたリソースタイプを確認します。


    # clresourcetype show
例 2–1 リソースタイプの登録

次の例では、Sun Cluster 構成の Sun Java System Web Server アプリケーションを表す SUNW.krb5 リソースタイプを登録します。


# clresourcetype register SUNW.krb5
# clresourcetype show SUNW.krb5

Resource Type:                                  SUNW.krb5
RT_description:                                  HA-Kerberos KDC server for Sun Cluster
RT_version:                                      3.2
API_version:                                     6
RT_basedir:                                      /opt/SUNWsckrb5/bin
Single_instance:                                 False
Proxy:                                           False
Init_nodes:                                      All potential masters
Installed_nodes:                                 <All>
Failover:                                        True
Pkglist:                                         SUNWsckrb5
RT_system:                                       False
次の手順

リソースタイプを登録したあと、リソースグループを作成し、リソースをそのリソースグループに追加できます。詳細は、「リソースグループの作成」を参照してください。

参照

次のマニュアルページを参照してください。

リソースタイプの更新

リソースタイプをアップグレードすると、新しいバージョンのリソースタイプで導入された新機能を使用できるようになります。新バージョンのリソースタイプは、次の点で旧バージョンと異なっている可能性があります。

リソースタイプのアップグレードには、次の各節で説明されている作業が必要です。

  1. 「アップグレードされたリソースタイプをインストールして登録する」

  2. 「既存のリソースを新バージョンのリソースタイプに移行する」

Procedureアップグレードされたリソースタイプをインストールして登録する

次の手順では、clresource(1CL) コマンドを使用してこの作業を実行する方法を説明します。ただし、この作業を行うには、clresource コマンドを使用する以外の方法もあります。clresource コマンドを使用する代わりに、Sun Cluster Manager や、clsetup(1CL) コマンドの Resource Group オプションを使用してこの作業を実行することもできます。

始める前に

ノードにアップグレードパッケージをインストールする前にどのような作業を行わなければならないかを判断するには、リソースタイプのドキュメントを参照してください。次のリストのいずれかのアクションが必要です。

非クラスタモードでノードを再起動する必要がある場合、順次アップグレードを実行することでサービスが失われるのを防止します。順次アップグレードでは、残りのノードをクラスタモードで動作させ続けながら、各ノードでパッケージを個別にインストールします。

  1. クラスタメンバーで、スーパーユーザーになるか、solaris.cluster.modify RBAC の承認を提供する役割になります。

  2. 対象となるリソースタイプのインスタンスをオンラインにするすべてのクラスタノード上で、リソースタイプアップグレード用のパッケージをインストールします。

  3. 新しいバージョンのリソースタイプを登録します。

    正しいバージョンのリソースタイプを登録するには、次の情報を指定する必要があります。

    • リソースタイプ名

    • リソースタイプを定義するリソースタイプ登録 (RTR) ファイル


    # clresourcetype register -f path-to-new-rtr-file resource-type-name

    リソースタイプ名の形式は次のとおりです。

    vendor-id.base-rt-name:rt-version

    この形式の詳細については、「リソースタイプ名の形式」を参照してください。

  4. 新しく登録されたリソースタイプを表示します。


    # clresourcetype show resource-type-name

  5. 必要に応じて、Installed_nodes プロパティーを、リソースタイプアップグレード用のパッケージがインストールされるノードに設定します。

    リソースタイプアップグレード用のパッケージが一部のクラスタノードでインストールされていない場合、この手順を実行する必要があります。

    リソースタイプのインスタンスを含むすべてのリソースグループの nodelist プロパティーは、リソースタイプの Installed_nodes プロパティーのサブセットである必要があります。


    # clresourcetype set -n installed-node-list resource-type
    -n installed-node-list

    このリソースタイプがインストールされるノードの名前を指定します。

Procedure既存のリソースを新バージョンのリソースタイプに移行する

次の手順では、clresource(1CL) コマンドを使用してこの作業を実行する方法を説明します。ただし、この作業を行うには、clresource コマンドを使用する以外の方法もあります。clresource コマンドを使用する代わりに、Sun Cluster Manager や、clsetup(1CL) コマンドの Resource Group オプションを使用してこの作業を実行することもできます。

始める前に

リソースを新しいバージョンのリソースタイプに移行できる時点を判断するには、リソースタイプをアップグレードするための手順を参照してください。

指示では、既存のバージョンのリソースをアップグレードできないことが規定されている場合があります。リソースを移行できない場合は、次の代替策を検討してください。

  1. クラスタメンバーで、スーパーユーザーになるか、solaris.cluster.modify RBAC の承認を提供する役割になります。

  2. 移行するリソースタイプの各リソースに関して、リソースまたはリソースグループの状態を適切な状態に変更します。

    • 任意の時点でリソースを移行できる場合、アクションは必要ありません。

    • リソースが監視されていない場合にのみリソースを移行できる場合は、次のコマンドを入力します。


      # clresource unmonitor resource

    • リソースがオフラインである場合にのみリソースを移行できる場合は、次のコマンドを入力します。


      # clresource disable resource
      注 –

      移行するリソースにそのほかのリソースが依存している場合、この手順は失敗します。このような場合は、出力されるエラーメッセージを参照して、依存しているリソースの名前を判別します。続いて、移行するリソースと依存するリソースを含むコンマ区切りリストを指定して、この手順を繰り返します。

    • リソースが無効である場合にのみリソースを移行できる場合は、次のコマンドを入力します。


      # clresource disable resource
      注 –

      移行するリソースにそのほかのリソースが依存している場合、この手順は失敗します。このような場合は、出力されるエラーメッセージを参照して、依存しているリソースの名前を判別します。続いて、移行するリソースと依存するリソースを含むコンマ区切りリストを指定して、この手順を繰り返します。

    • リソースグループが管理されていない場合にのみリソースを移行できる場合は、次のコマンドを入力します。


      # clresource disable -gresource-group +
# clresourcegroup offline resource-group
# clresourcegroup unmanage resource-group

      上記コマンドの各項目の意味は次のとおりです。

      resource-group

      管理されていないリソースグループを指定します。

  3. 移行するリソースタイプのリソースごとに、Type_version プロパティーを新バージョンに変更します。

    必要に応じて、同じコマンドで、同じリソースのそのほかのプロパティーを適切な値に設定します。これらのプロパティーを設定するには、コマンドで -p オプションを指定します。

    そのほかのプロパティーを設定する必要があるかどうかを判別するには、リソースタイプをアップグレードするための手順を参照してください。次の理由により、そのほかのプロパティーを設定しなければならない場合があります。

    • 新しいバージョンのリソースタイプに拡張プロパティーが導入されている。

    • 既存のプロパティーのデフォルト値が、新しいバージョンのリソースタイプにおいて変更されている。


    # clresource set -p Type_version=new-version \
[-p extension-property=new-value] [-p standard-property=new-value] resource
    注 –

    既存のバージョンのリソースタイプが、新しいバージョンへのアップグレードをサポートしていない場合、この手順は失敗します。

  4. 手順 2で入力したコマンドを逆にすることで、リソースまたはリソースグループの以前の状態を回復します。

    • 任意の時点でリソースを移行できる場合、アクションは必要ありません。

      注 –

      いつでも移行できるリソースを移行した後、リソースの検証により、リソースタイプのバージョンが正しく表示されないことがあります。このような状況が発生した場合、リソースの障害モニターを一度無効にし、有効にし直すると、リソースの検証において、リソースタイプのバージョンが正しく表示されます。

    • リソースが監視されていない場合にのみリソースを移行できる場合は、次のコマンドを入力します。


      # clresource monitor resource

    • リソースがオフラインである場合にのみリソースを移行できる場合は、次のコマンドを入力します。


      # clresource enable resource
      注 –

      手順 2で、移行するリソースに依存するそのほかのリソースを無効にした場合、依存するリソースも有効にします。

    • リソースが無効である場合にのみリソースを移行できる場合は、次のコマンドを入力します。


      # clresource enable resource
      注 –

      手順 2で、移行するリソースに依存するそのほかのリソースを無効にした場合、依存するリソースも有効にします。

    • リソースグループが管理されていない場合にのみリソースを移行できる場合は、次のコマンドを入力します。


      # clresource enable -g resource-group +
# clresourcegroup manage resource-group
# clresourcegroup online resource-group
例 2–2 オフラインである場合にのみ移行可能なリソースの移行

この例では、リソースがオフラインである場合にのみ移行可能なリソースの移行を示します。新しいリソースタイプパッケージには、新しいパスにあるメソッドが含まれています。インストール時にメソッドは上書きされないため、アップグレードされたリソースタイプのインストールが完了するまでリソースを無効にする必要はありません。

この例のリソースには次のような特徴があります。

この例では、サプライヤの指示に従って、アップグレードパッケージがすでにすべてのクラスタノードでインストールされていると仮定されています。


# clresourcetype register -f /opt/XYZmyrt/etc/XYZ.myrt myrt
# clresource disable myresource
# clresource set -p Type_version=2.0 myresource
# clresource enable myresource
例 2–3 監視対象外である場合にのみ移行可能なリソースの移行

この例では、リソースが監視対象外である場合にのみ移行可能なリソースの移行を示します。新しいリソースタイプパッケージには、モニターと RTR ファイルしか含まれていません。モニターはインストール時に上書きされるため、アップグレードパッケージをインストールする前にリソースの監視を無効にする必要があります。

この例のリソースには次のような特徴があります。

この例では、次の操作が実行されます。

  1. アップグレードパッケージをインストールする前に、次のコマンドを実行してリソースの監視を無効にします。


    # clresource unmonitor  myresource

  2. サプライヤの指示に従って、アップグレードパッケージはすべてのクラスタノードにインストールされます。

  3. 新しいバージョンのリソースタイプを登録するには、次のコマンドを実行します。


    # clresourcetype register -f /opt/XYZmyrt/etc/XYZ.myrt myrt

  4. Type_version プロパティーを新しいバージョンに変更するには、次のコマンドを実行します。


    # clresource set -p Type_version=2.0 myresource

  5. 移行後リソースの監視を有効にするには、次のコマンドを実行します。


    # clresource monitor myresource

リソースタイプのダウングレード

リソースをダウングレードして古いバージョンのリソースタイプにすることができます。リソースを古いバージョンのリソースタイプにダウングレードするための条件は、新しいバージョンのリソースタイプにアップグレードするための条件よりも厳しくなります。リソースを含むリソースグループを管理対象外にする必要があります。

Procedure古いバージョンのリソースタイプにダウングレードする方法

次の手順では、clresource(1CL) コマンドを使用してこの作業を実行する方法を説明します。ただし、この作業を行うには、clresource コマンドを使用する以外の方法もあります。clresource コマンドを使用する代わりに、Sun Cluster Manager や、clsetup(1CL) コマンドの Resource Group オプションを使用してこの作業を実行することもできます。

  1. クラスタメンバーで、スーパーユーザーになるか、solaris.cluster.modify および solaris.cluster.admin RBAC の承認を提供する役割になります。

  2. ダウングレードするリソースを含むリソースグループをオフラインに切り替えます。


    clresourcegroup offline resource-group

  3. ダウングレードするリソースを含むリソースグループのすべてのリソースを無効にします。


    clresource disable -gresource-group +

  4. ダウングレードするリソースを含むリソースグループの管理を解除します。


    clresourcegroup unmanage resource-group

  5. 必要に応じて、ダウングレード先の古いバージョンのリソースタイプを再登録します。

    ダウングレード先のバージョンがもう登録されていない場合にのみ、この手順を実行します。ダウングレード先のバージョンがまだ登録されている場合は、この手順を省略します。


    clresourcetype register resource-type-name

  6. ダウングレードするリソースに対して、Type_version プロパティーをダウングレード先の古いバージョンに設定します。

    必要に応じて、同じコマンドを使って、同じリソースのその他のプロパティーに適切な値を設定します。


    clresource set -p Type_version=old-version resource-todowngrade

  7. 手順 3で無効にしたすべてのリソースを有効にします。


    # clresource enable -gresource-group +

  8. ダウングレードしたリソースを含むリソースグループを管理状態にします。


    # clresourcegroup manage resource-group

  9. ダウングレードしたリソースを含むリソースグループをオンラインにします。


    # clresourcegroup online resource-group

リソースグループの作成

リソースグループには、一連のリソースが含まれており、これらすべてのリソースは指定のノードまたはゾーン、あるいはノード群またはゾーン群で共にオンラインまたはオフラインになります。リソースを配置する前に、空のリソースグループを作成します。リソースグループは、非大域ゾーンで動作するように構成できます。

注 –

リソースグループのノードリストで指定されるゾーンは、リソースグループの作成時点では存在する必要はありません。ノードリストに指定されているゾーンが RGM により検出されないと、警告メッセージが表示されますが、エラーにはなりません。

リソースグループには、フェイルオーバーとスケーラブルの 2 つの種類があります。フェイルオーバーリソースグループの場合、同時にオンラインにできるのは 1 つのノードまたはゾーンでのみです。一方、スケーラブルリソースグループの場合は、同時に複数のノードまたはゾーンでオンラインにできます。

次の手順では、clresourcegroup(1CL) コマンドを使用して、リソースグループを作成する方法を説明します。

リソースグループの概念については、第 1 章「Sun Cluster データサービスの計画」 および『Sun Cluster の概念 (Solaris OS 版) 』を参照してください。

Procedureフェイルオーバーリソースグループを作成する

フェイルオーバーリソースグループには、次の種類のリソースが含まれています。

ネットワークアドレスリソースと依存するデータサービスリソースは、データサービスがフェイルオーバーまたはスイッチオーバーする場合に、クラスタノードまたはゾーン間を移動します。

注 –

この手順は、任意のクラスタノードから実行します。

  1. クラスタメンバーで、スーパーユーザーになるか、solaris.cluster.modify RBAC の承認を提供する役割になります。

  2. フェイルオーバーリソースグループを作成します。


    # clresourcegroup create [-n node-zone-list] resource-group
    -n node-zone-list

    このリソースグループをマスターできるゾーンの、コンマ区切りの順序付けされたリストを指定します。リスト内の各エントリの形式は node:zone です。この形式では、 node はノード名を指定し、zone は非大域 Solaris ゾーンの名前を指定します。大域ゾーンを指定する、または非大域ゾーンを持たないノードを指定するには、node のみを指定します。

    このリストはオプションです。このリストを省略すると、クラス内のすべてのノード上でリソースグループが作成されます。

    注 –

    最高の可用性を実現するには、同一ノード上の異なるゾーンではなく、フェイルオーバーリソースグループのノードリストの異なるノード上でゾーンを指定します。

    resource-group

    追加するフェイルオーバーリソースグループの名前を指定します。任意の名前の先頭文字は ASCII にする必要があります。

  3. リソースグループが作成されていることを確認します。


    # clresourcegroup show resource-group
例 2–4 フェイルオーバーリソースグループの作成

この例で、フェイルオーバーリソースグループ resource-group-1 の作成を示します。ノード phys-schost-1 および phys-schost-2 の大域ゾーンは、このリソースグループをマスターできます。


# clresourcegroup create -n phys-schost1,phys-schost-2 resource-group-1
# clresourcegroup show -v resource-group-1

=== Resource Groups and Resources ===          

Resource Group:                                 resource-group1
RG_description:                                 <NULL>
RG_mode:                                        Failover
RG_state:                                       Unmanaged
RG_project_name:                                default
RG_affinities:                                  <NULL>
RG_SLM_type:                                    manual
Auto_start_on_new_cluster:                      True
Failback:                                       False
Nodelist:                                       phys-schost-1 phys-schost-2
Maximum_primaries:                              1
Desired_primaries:                              1
RG_dependencies:                                <NULL>
Implicit_network_dependencies:                  True
Global_resources_used:                          <All>
Pingpong_interval:                              3600
Pathprefix:                                     <NULL>
RG_System:                                      False
Suspend_automatic_recovery:                     False
次の手順

フェイルオーバーリソースグループを作成した後で、そのリソースグループにアプリケーションリソースを追加できます。手順については、「リソースをリソースグループに追加するためのツール」を参照してください。

参照

clresourcegroup(1CL) のマニュアルページ。

Procedureスケーラブルリソースグループを作成する

スケーラブルリソースグループは、スケーラブルサービスと共に使用されます。共有アドレス機能は、スケーラブルサービスの多数のインスタンスを 1 つのサービスとして扱える Sun Cluster のネットワーキング機能です。まず、スケーラブルリソースが依存する共有アドレスを含むフェイルオーバーリソースグループを作成しなければなりません。次にスケーラブルリソースグループを作成し、そのグループにスケーラブルリソースを追加します。スケーラブルリソースグループまたは共有アドレスリソースグループのノードリストには、同一ノードで複数の非大域ゾーンが含まれてはなりません。スケーラブルサービスの各インスタンスは、別々のクラスタノードで実行する必要があります。

また、スケーラブルリソースグループを非大域ゾーンで動作するように構成することもできます。スケーラブルリソースは、同一ノードの複数の非大域ゾーンで動作するようには構成しないでください。

注 –

この手順は、任意のクラスタノードから実行します。

  1. クラスタメンバーで、スーパーユーザーになるか、solaris.cluster.modify RBAC の承認を提供する役割になります。

  2. スケーラブルリソースが使用する共有アドレスを保持するフェイルオーバーリソースグループを作成します。

  3. スケーラブルリソースグループを作成します。


    # clresourcegroup create\-p Maximum_primaries=m\-p Desired_primaries=n\
-p RG_dependencies=depend-resource-group\
[-n node-zone-list] resource-group
    -p Maximum_primaries=m

    このリソースグループのアクティブな主ノードの最大数を指定します。

    -p Desired_primaries=n

    リソースグループが起動するアクティブな主ノードの数を指定します。

    -p RG_dependencies=depend-resource-group

    作成されるリソースグループが依存する共有アドレスリソースを含むリソースグループを指定します。

    -n node-zone-list

    このリソースグループが使用可能となる、コンマ区切りの順序付けられたリストを指定します。リスト内の各エントリの形式は node:zone です。この形式では、 node はノード名を指定し、zone は非大域 Solaris ゾーンの名前を指定します。大域ゾーンを指定する、または非大域ゾーンを持たないノードを指定するには、node のみを指定します。

    このリストはオプションです。このリストを省略すると、クラス内のすべてのノード上でリソースグループが作成されます。

    スケーラブルリソースのノードリストは、共有アドレスリソースのノードリストと同じリストまたは nodename:zonename ペアのサブセットを含むことができます。

    resource-group

    追加するスケーラブルリソースグループの名前を指定します。任意の名前の先頭文字は ASCII にする必要があります。

  4. スケーラブルリソースグループが作成されていることを確認します。


    # clresourcegroup show resource-group
例 2–5 スケーラブルリソースグループの作成

この例では、スケーラブルリソースグループ resource-group-1 の作成を示します。このリソースグループは、ノード phys-schost-1 および phys-schost-2 の大域ゾーンでホストされます。スケーラブルリソースグループは、共有アドレスリソースを含むフェイルオーバーリソースグループ resource-group-2 に依存します。


# clresourcegroup create\
-p Maximum_primaries=2\
-p Desired_primaries=2\
-p RG_dependencies=resource-group-2\
-n phys-schost-1, phys-schost-2\
resource-group-1

# clresourcegroup show resource-group-1

=== Resource Groups and Resources ===          

Resource Group:                                  resource-group-1
RG_description:                                  <NULL>
RG_mode:                                         Scalable
RG_state:                                        Unmanaged
RG_project_name:                                 default
RG_affinities:                                   <NULL>
Auto_start_on_new_cluster:                       True
Failback:                                        False
Nodelist:                                        phys-schost-1 phys-schost-2
Maximum_primaries:                               2
Desired_primaries:                               2
RG_dependencies:                                 resource-group2
Implicit_network_dependencies:                   True
Global_resources_used:                           <All>
Pingpong_interval:                               3600
Pathprefix:                                      <NULL>
RG_System:                                       False
Suspend_automatic_recovery:                      False
次の手順

スケーラブルリソースグループを作成したあと、そのリソースグループにスケーラブルアプリケーションリソースを追加できます。詳細は、「スケーラブルアプリケーションリソースをリソースグループに追加する」を参照してください。

参照

clresourcegroup(1CL) のマニュアルページ。

リソースをリソースグループに追加するためのツール

リソースは、リソースタイプをインスタンス化したものです。リソースは、RGM によって管理される前に、リソースグループに追加する必要があります。この節では、3 種類のリソースタイプについて説明します。

Sun Cluster には、リソースをリソースグループに追加するための次のツールがあります。

Sun Cluster Manager のウィザード、clsetup ユーティリティー、または Sun Cluster の保守コマンドを使用すると、論理ホスト名リソースと共有アドレスリソースをリソースグループに追加することができます。

Sun Cluster Manager および clsetup ユーティリティーを使用すると、対話形式でリソースをリソースグループに追加できます。これらのリソースを対話的に使うことにより、コマンドの構文エラーまたは脱落による設定エラーが起きる可能性が少なくなります。Sun Cluster Manager および clsetup ユーティリティーは、すべての必須リソースが作成され、リソース間のすべての必須依存関係が設定されるようにします。

論理ホスト名リソースと共有アドレスリソースは、常にフェイルオーバーリソースグループに追加してください。フェイルオーバーデータサービス用のデータサービスリソースは、フェイルオーバーリソースグループに追加してください。フェイルオーバーリソースグループは、そのデータサービス用の論理ホスト名リソースとアプリケーションリソースの両方を含みます。スケーラブルリソースグループは、スケーラブルサービス用のアプリケーションリソースだけを含んでいます。スケーラブルサービスが依存する共有アドレスリソースは、別のフェイルオーバーリソースグループに存在する必要があります。データサービスをクラスタノードまたはゾーン全体に渡って提供するには、スケーラブルアプリケーションリソースと共有アドレスリソース間の依存性を指定する必要があります。

注 –

DEPRECATED フラグは、論理ホスト名と共有アドレスリソースを非推奨アドレスにします。これらのアドレスは、アウトバウンド要求には適していません。これは、これらのアドレスがフェイルオーバーまたはスイッチオーバーにより、別のクラスタノードに移行する可能性があるためです。

リソースについては、『Sun Cluster の概念 (Solaris OS 版)』および第 1 章「Sun Cluster データサービスの計画」を参照してください。

Procedureclsetup ユーティリティーを使用して論理ホスト名リソースをリソースグループに追加する

次の手順では、clsetup ユーティリティーを使用することにより、論理ホスト名リソースをリソースグループに追加する方法を説明します。この手順は 1 つのノードからのみ実行します。

この手順では、Sun Cluster の保守コマンドの長い形式を使用します。多くのコマンドには短縮形もあります。コマンド名の形式を除き、コマンドは同じです。コマンドのリストとその短縮形については、 付録 A 「Sun Cluster オブジェクト指向コマンド」を参照してください。

始める前に

次の前提条件を満たしていることを確認します。

次の情報を用意してください。

  1. 任意のクラスタノードでスーパーユーザーになります。

  2. clsetup ユーティリティーを起動します。


    # clsetup

    clsetup のメインメニューが表示されます。

  3. データサービスのオプションに対応する番号を入力し、Return キーを押します。

    「データサービス」メニューが表示されます。

  4. 論理ホスト名リソースを構成するためのオプションに対応する番号を入力し、Return キーを押します。

    clsetup ユーティリティーは、この作業を実行するための前提条件のリストを表示します。

  5. 前提条件が満たされていることを確認し、Return キーを押して継続します。

    clsetup ユーティリティーは、論理ホスト名リソースをオンラインにすることができるクラスタノードまたはゾーンのリストを表示します。

  6. 論理ホスト名リソースをオンラインにすることができるノードまたはゾーンを選択します。

    • 任意の順序で並んでいる一覧表示されたすべてのノードのデフォルト選択をそのまま使用するには、a と入力し、Return キーを押します。

    • 一覧表示されたノードまたはゾーンのサブセットを選択するには、ノードに対応する番号のコンマ区切りまたはスペース区切りのリストを入力します。続いて、Return キーを押します。

    • 特定の順序ですべてのノードを選択するには、ノードに対応する番号のコンマ区切りまたはスペース区切りの順序付きリストを入力し、Return キーを押します。

      論理ホスト名リソースグループのノードリストにノードが表示される順序でノードが一覧表示されていることを確認します。リストの最初のノードは、このリソースグループの主ノードです。

  7. ノードの選択を確認するには、d を入力して、Return キーを押します。

    clsetup ユーティリティーは、リソースが使用可能にする論理ホスト名をユーザーが選択できる画面を表示します。

  8. このリソースが使用可能にする論理ホスト名を入力し、Return キーを押します。

    clsetup ユーティリティーは、このユーティリティーが作成する Sun Cluster オブジェクトの名前を表示します。

  9. Sun Cluster オブジェクトに別の名前が必要である場合、次のように名前を変更します。

    1. 変更する名前に対応する番号を入力し、Return キーを押します。

      clsetup ユーティリティーは、新しい名前を指定できる画面を表示します。

    2. 「新しい値」プロンプトで、新しい名前を入力し、Return キーを押します。

    clsetup ユーティリティーは、このユーティリティーが作成する Sun Cluster オブジェクトの名前のリストに戻ります。

  10. Sun Cluster オブジェクト名の選択を確認するには、d を入力して、Return キーを押します。

    clsetup ユーティリティーは、このユーティリティーが作成する Sun Cluster の構成に関する情報を表示します。

  11. 構成を作成するには、c を入力し、Return キーを押します。

    clsetup ユーティリティーは、構成を作成するためにこのユーティリティーがコマンドを実行していることを示す進行状況のメッセージを表示します。構成が完了した時点で、clsetup ユーティリティーは、構成を作成するためにユーティリティーが実行したコマンドを表示します。

  12. (省略可能) clsetup ユーティリティーが終了するまで、繰り返し q を入力し、Return キーを押します。

    必要に応じて、ほかの必要な作業を実行している間、clsetup ユーティリティーを動作させたままにし、そのあとでユーティリティーを再度使用することができます。clsetup を終了する場合、ユーザーがユーティリティーを再起動する際に、ユーティリティーは既存の論理ホスト名リソースグループを認識します。

  13. 論理ホスト名リソースが作成されていることを確認します。

    このためには、clresource(1CL) ユーティリティーを使用します。デフォルトでは、clsetup ユーティリティーは、リソースグループに名前 node_name-rg を割り当てます。


    # clresource show node_name-rg

Procedureコマンド行インタフェースを使用して論理ホスト名リソースをリソースグループに追加する

注 –

論理ホスト名リソースをリソースグループに追加すると、リソースの拡張プロパティーはデフォルト値に設定されます。デフォルト以外の値を指定するには、リソースをリソースグループに追加した後、そのリソースを変更する必要があります。詳細については、「論理ホスト名リソースまたは共有アドレスリソースを変更する」を参照してください。

注 –

この手順は、任意のクラスタノードから実行します。

始める前に

次の情報を用意してください。

  1. クラスタメンバーで、スーパーユーザーになるか、solaris.cluster.modify RBAC の承認を提供する役割になります。

  2. 論理ホスト名リソースをリソースグループに追加します。


    # clreslogicalhostname create -g resource-group -h hostnamelist, … [-N netiflist] resource
    -g resource-group

    リソースを配置するリソースグループの名前を指定します。

    -h hostnamelist, …

    クライアントがリソースグループでサービスと通信する UNIX ホスト名 (論理ホスト名) をコマンドで区切って指定します。論理ホスト名リソースが、非大域ゾーンで動作するリソースグループに追加される場合、対応する IP アドレスはそのゾーン内で構成されます。これらの IP アドレスは、そのゾーンで動作するアプリケーションのみが使用できます。

    完全修飾ホスト名が必要である場合は、-h オプションを使用して完全修飾名を指定します。

    -N netiflist

    各ノード上の IP ネットワークマルチパス グループをコンマで区切って指定します (省略可能)。netiflist の各要素は、netif@node の形式にする必要があります。netif は IP ネットワークマルチパス グループ名 (sc_ipmp0 など) として指定できます。ノードは、ノード名またはノード ID (sc_ipmp0@1、sc_ipmp@phys-schost-1 など) で識別できます。

    注 –

    Sun Cluster では、 netif にアダプタ名を使用できません。

    resource

    リソース名を指定します (省略可能)。リソース名では完全修飾名を使用できません。

  3. 論理ホスト名リソースが追加されていることを確認します。


    # clresource show resource
例 2–6 論理ホスト名リソースのリソースグループへの追加

次に、論理ホスト名リソース (resource-1) をリソースグループ (resource-group-1) に追加する例を示します。


# clreslogicalhostname create -g resource-group-1 -h schost-1 resource-1
# clresource show resource-1

=== Resources ===                              

Resource:                                        resource-1
Type:                                            SUNW.LogicalHostname:2
Type_version:                                    2
Group:                                           resource-group-1
R_description:                                   
Resource_project_name:                           default
Enabled{phats1}:                                 True
Enabled{phats2}:                                 True
Monitored{phats1}:                               True
Monitored{phats2}:                               True
例 2–7 IP ネットワークマルチパスグループを識別する論理ホスト名リソースの追加

次に、次の論理ホスト名リソースをリソースグループ nfs-fo-rg に追加する例を示します。


# clreslogicalhostname create -g nfs-fo-rg -h cs23-rs -N sc_ipmp0@1,sc_ipmp0@2 cs23-rs
# clreslogicalhostname create -g nfs-fo-rg -h cs24-rs -N sc_ipmp1@1,sc_ipmp1@2 cs24-rs
次の手順

論理ホスト名リソースを追加したあと、「リソースグループをオンラインにする」を参照してそれらをオンラインにします。

注意事項

リソースを追加すると、Sun Cluster ソフトウェアは、そのリソースの妥当性を検査します。妥当性の検査に失敗すると、clreslogicalhostname コマンドはエラーメッセージを出力して終了します。妥当性の検査に失敗した理由を判別するには、エラーメッセージについて各ノード上の syslog を調べてください。メッセージは、妥当性の検査を実施したノードで表示されます。必ずしも clreslogicalhostname コマンドを実行したノードで表示されるわけではありません。

参照

clreslogicalhostname(1CL) のマニュアルページ。

Procedureclsetup ユーティリティーを使用して共有アドレスリソースをリソースグループに追加する

次の手順では、clsetup ユーティリティーを使用することにより、共有アドレスリソースをリソースグループに追加する方法を説明します。この手順は、任意のクラスタノードから実行します。

この手順では、Sun Cluster の保守コマンドの長い形式を使用します。多くのコマンドには短縮形もあります。コマンド名の形式を除き、コマンドは同じです。コマンドのリストとその短縮形については、 付録 A 「Sun Cluster オブジェクト指向コマンド」を参照してください。

始める前に

次の前提条件を満たしていることを確認します。

次の情報を用意してください。

  1. 任意のクラスタノードでスーパーユーザーになります。

  2. clsetup ユーティリティーを起動します。


    # clsetup

    clsetup のメインメニューが表示されます。

  3. データサービスのオプションに対応する番号を入力し、Return キーを押します。

    「データサービス」メニューが表示されます。

  4. 共有アドレスリソースを構成するためのオプションに対応する番号を入力し、Return キーを押します。

    clsetup ユーティリティーは、この作業を実行するための前提条件のリストを表示します。

  5. 前提条件が満たされていることを確認し、Return キーを押して継続します。

    clsetup ユーティリティーは、共有アドレスリソースをオンラインにすることができるクラスタノードまたはゾーンのリストを表示します。

  6. 共有アドレスリソースをオンラインにすることができるノードまたはゾーンを選択します。

    • 任意の順序で並んでいる一覧表示されたすべてのノードのデフォルト選択をそのまま使用するには、a と入力し、Return キーを押します。

    • 一覧表示されたノードまたはゾーンのサブセットを選択するには、ノードに対応する番号のコンマ区切りまたはスペース区切りのリストを入力します。続いて、Return キーを押します。

    • 特定の順序ですべてのノードを選択するには、ノードに対応する番号のコンマ区切りまたはスペース区切りの順序付きリストを入力し、Return キーを押します。

  7. ノードの選択を確認するには、d を入力して、Return キーを押します。

    clsetup ユーティリティーは、リソースが使用可能にする共有アドレスをユーザーが指定できる画面を表示します。

  8. このリソースが使用可能にする共有アドレスを入力し、Return キーを押します。

    clsetup ユーティリティーは、このユーティリティーが作成する Sun Cluster オブジェクトの名前を表示します。

  9. Sun Cluster オブジェクトに別の名前が必要である場合、次のように名前を変更します。

    1. 変更する名前に対応する番号を入力し、Return キーを押します。

      clsetup ユーティリティーは、新しい名前を指定できる画面を表示します。

    2. 「新しい値」プロンプトで、新しい名前を入力し、Return キーを押します。

    clsetup ユーティリティーは、このユーティリティーが作成する Sun Cluster オブジェクトの名前のリストに戻ります。

  10. Sun Cluster オブジェクト名の選択を確認するには、d を入力して、Return キーを押します。

    clsetup ユーティリティーは、このユーティリティーが作成する Sun Cluster の構成に関する情報を表示します。

  11. 構成を作成するには、c を入力し、Return キーを押します。

    clsetup ユーティリティーは、構成を作成するためにこのユーティリティーがコマンドを実行していることを示す進行状況のメッセージを表示します。構成が完了した時点で、clsetup ユーティリティーは、構成を作成するためにユーティリティーが実行したコマンドを表示します。

  12. (省略可能) clsetup ユーティリティーが終了するまで、繰り返し q を入力し、Return キーを押します。

    必要に応じて、ほかの必要な作業を実行している間、clsetup ユーティリティーを動作させたままにし、そのあとでユーティリティーを再度使用することができます。clsetup ユーティリティーを終了する場合、ユーザーがユーティリティーを再起動する際に、ユーティリティーは既存の共有アドレスリソースグループを認識します。

  13. 共有アドレスリソースが作成されていることを確認します。

    このためには、clresource(1CL) ユーティリティーを使用します。デフォルトでは、clsetup ユーティリティーは、リソースグループに名前 node_name-rg を割り当てます。


    # clresource show node_name-rg

Procedureコマンド行インタフェースを使用して共有アドレスリソースをリソースグループに追加する

注 –

共有アドレスリソースをリソースグループに追加すると、リソースの拡張プロパティーはデフォルト値に設定されます。デフォルト以外の値を指定するには、リソースをリソースグループに追加した後、そのリソースを変更する必要があります。詳細については、「論理ホスト名リソースまたは共有アドレスリソースを変更する」を参照してください。

注 –

この手順は、任意のクラスタノードから実行します。

始める前に

次の情報を用意してください。

  1. クラスタメンバーで、スーパーユーザーになるか、solaris.cluster.modify RBAC の承認を提供する役割になります。

  2. 共有アドレスリソースをリソースグループに追加します。


    # clressharedaddress create -g resource-group -h hostnamelist, … \
[-X auxnodelist] [-N netiflist] resource
    -g resource-group

    リソースグループの名前を指定します。共有アドレスリソースのノードリストでは、同一ノード上では複数のゾーンを指定しないでください。共有アドレスリソースのノードリストは、同一ノード上で異なるゾーンを指定してはいけません。nodename:zonename のペアの同一リストをスケーラブルリソースグループのノードリストとして指定します。

    -h hostnamelist, …

    共有アドレスホスト名をコンマで区切って指定します。

    -X auxnodelist

    共有アドレスをホストできるクラスタノード (ただし、フェイルオーバー時に主ノードとして使用されない) を識別する物理ノード名または ID またはゾーンをコンマで区切って指定します。これらのノードは、リソースグループのノードリストで潜在的マスターとして識別されるノードと相互に排他的です。補助ノードリストが明示的に指定されていない場合、リストのデフォルトは、共有アドレスリソースを含むリソースグループのノードリストには含まれていない、すべてのクラスタノード名のリストになります。

    注 –

    サービスをマスターするために作成されたすべての非大域ゾーン内でスケーラブルサービスを動作させるには、共有アドレスリソースグループのノードリスト、または共有アドレスリソースの auxnodelist にゾーンの完全なリストを含めます。すべてのゾーンがノードリスト内にある場合は、auxnodelist を省略できます。

    -N netiflist

    各ノード上の IP ネットワークマルチパス グループをコンマで区切って指定します (省略可能)。netiflist の各要素は、netif@node の形式にする必要があります。netif は IP ネットワークマルチパス グループ名 (sc_ipmp0 など) として指定できます。ノードは、ノード名またはノード ID (sc_ipmp0@1、sc_ipmp@phys-schost-1 など) で識別できます。

    注 –

    Sun Cluster では、 netif にアダプタ名を使用できません。

    resource

    リソース名を指定します (省略可能)。

  3. 共有アドレスリソースが追加され、妥当性が検査されていることを確認します。


    # clresource show resource
例 2–8 共有アドレスリソースのリソースグループへの追加

次に、共有アドレスリソース (resource-1) をリソースグループ (resource-group-1) に追加する例を示します。


# clressharedaddress create -g resource-group-1 -h schost-1 resource-1
# clresource show resource-1

=== Resources ===                              

  Resource:                                        resource-1
  Type:                                            SUNW.SharedAddress:2
  Type_version:                                    2
  Group:                                           resource-group-1
  R_description:                                   
  Resource_project_name:                           default
  Enabled{phats1}:                                 False
  Enabled{phats2}:                                 False
  Monitored{phats1}:                               True
  Monitored{phats2}:                               True
次の手順

共有アドレスリソースを追加したあと、「リソースグループをオンラインにする」の手順を使用してリソースを有効にします。

注意事項

リソースを追加すると、Sun Cluster ソフトウェアは、そのリソースの妥当性を検査します。妥当性の検査に失敗すると、clressharedaddress コマンドはエラーメッセージを出力して終了します。妥当性の検査に失敗した理由を判別するには、エラーメッセージについて各ノード上の syslog を調べてください。メッセージは、妥当性の検査を実施したノードで表示されます。必ずしも clressharedaddress コマンドを実行したノードで表示されるわけではありません。

参照

clressharedaddress(1CL) のマニュアルページ。

Procedureフェイルオーバーアプリケーションリソースをリソースグループに追加する

フェイルオーバーアプリケーションリソースは、以前にフェイルオーバーリソースグループに作成した論理ホスト名を使用するアプリケーションリソースです。

注 –

この手順は、任意のクラスタノードから実行します。

始める前に

次の情報を用意してください。

注 –

この手順はプロキシリソースにも該当します。

  1. クラスタメンバーで、スーパーユーザーになるか、solaris.cluster.modify RBAC の承認を提供する役割になります。

  2. フェイルオーバーアプリケーションリソースをリソースグループに追加します。


    # clresource create -g resource-group -t resource-type \
[-p "extension-property[{node-specifier}]"=value, …] [-p standard-property=value, …] resource
    -g resource-group

    フェイルオーバーリソースグループの名前を指定します。このリソースグループはすでに存在している必要があります。

    -t resource-type

    リソースが属するリソースタイプの名前を指定します。

    -p "extension-property[{node-specifier}]"=value, …

    リソース用に設定する拡張プロパティーのコンマ区切りリストを指定します。設定できる拡張プロパティーはリソースタイプに依存します。どの拡張プロパティーを設定するかを決定するには、リソースタイプのマニュアルを参照してください。

    node-specifier は、-p オプションおよび -x オプションに対する「オプション」の修飾子です。この修飾子は、指定された 1 つまたは複数のノードまたはゾーン上でのみ、1 つまたは複数の拡張プロパティーがリソースの作成時に設定されることを示します。指定した拡張プロパティーは、クラスタ内のほかのノードまたはゾーン上では、設定されません。node-specifier を指定しないと、クラスタ内のすべてのノードおよびゾーン上の指定された拡張プロパティーが設定されます。node-specifier にはノード名またはノード識別子を指定できます。node-specifier の構文例を次に示します。


    -p "myprop{phys-schost-1}"

    中括弧 ({}) は、指定した拡張プロパティーをノード phys-schost-1 でのみ設定することを示します。大部分のシェルでは、二重引用符 (") が必要です。

    また次の構文を使用して、2 つの異なるノード上の 2 つの異なるゾーン内で拡張プロパティーを設定することもできます。


    -x "myprop{phys-schost-1:zoneA,phys-schost-2:zoneB}"
    注 –

    node-specifier を使用して指定する拡張プロパティーは、ノードごとのプロパティーとして RTR ファイルで宣言します。Per_node リソースプロパティーの属性の詳細は、付録 B 「標準プロパティー」を参照してください。

    -p standard-property=value, …

    リソース用に設定する標準プロパティーのコンマ区切りリストを指定します。設定できる標準プロパティーはリソースタイプに依存します。どの標準プロパティーを設定するかを決定するには、リソースタイプのマニュアルと付録 B 「標準プロパティー」を参照してください。

    resource

    追加するリソースの名前を指定します。

    リソースは有効状態で作成されます。

  3. フェイルオーバーアプリケーションリソースが追加され、妥当性が検査されていることを確認します。


    # clresource show resource
例 2–9 フェイルオーバーアプリケーションリソースのリソースグループへの追加

次に、リソース (resource-1) をリソースグループ (resource-group-1) に追加する例を示します。リソースは、以前に定義したフェイルオーバーリソースグループと同じリソースグループに存在している論理ホスト名リソース (schost-1、schost-2) に依存しています。


# clresource create -g resource-group-1 -t resource-type-1 \
-p Network_resources_used=schost-1,schost2  resource-1\
# clresource show resource-1

=== Resources ===

  Resource:                                        resource-1
  Type:                                            resource-type-1
  Type_version:                                    
  Group:                                           resource-group-1
  R_description:                                   
  Resource_project_name:                           default
  Enabled{phats1}:                                 False
  Enabled{phats2}:                                 False
  Monitored{phats1}:                               True
  Monitored{phats2}:                               True
次の手順

フェイルオーバーアプリケーションリソースを追加したあと、「リソースグループをオンラインにする」の手順を使用してリソースを有効にします。

注意事項

リソースを追加すると、Sun Cluster ソフトウェアは、そのリソースの妥当性を検査します。妥当性の検査に失敗すると、clresource コマンドはエラーメッセージを出力して終了します。妥当性の検査に失敗した理由を判別するには、エラーメッセージについて各ノード上の syslog を調べてください。メッセージは、妥当性の検査を実施したノードで表示されます。必ずしも clresource コマンドを実行したノードで表示されるわけではありません。

参照

clresource(1CL) のマニュアルページ。

Procedureスケーラブルアプリケーションリソースをリソースグループに追加する

スケーラブルアプリケーションリソースは、共有アドレスリソースを使用するアプリケーションリソースです。共有アドレスリソースはフェイルオーバーリソースグループ内にあります。

注 –

この手順は、任意のクラスタノードから実行します。

始める前に

次の情報を用意してください。

注 –

この手順はプロキシリソースにも該当します。

  1. クラスタメンバーで、スーパーユーザーになるか、solaris.cluster.modify RBAC の承認を提供する役割になります。

  2. スケーラブルアプリケーションリソースをリソースグループに追加します。


    # clresource create -g resource-group -t resource-type \
-p Network_resources_used=network-resource[,network-resource...] \
-p Scalable=True
[-p "extension-property[{node-specifier}]"=value, …] [-p standard-property=value, …] resource
    -g resource-group

    以前に作成したスケーラブルサービスリソースグループの名前を指定します。

    -t resource-type

    このリソースが属するリソースタイプの名前を指定します。

    -p Network_resources_used= network-resource[,network-resource...]

    このリソースが依存するネットワークリソース (共有アドレス) のリストを指定します。

    -p Scalable=True

    このリソースがスケーラブルであることを指定します。

    -p "extension-property[{node-specifier}]"=value, …

    リソース用に設定する拡張プロパティーのコンマ区切りリストを指定します。設定できる拡張プロパティーはリソースタイプに依存します。どの拡張プロパティーを設定するかを決定するには、リソースタイプのマニュアルを参照してください。

    node-specifier は、-p オプションおよび -x オプションに対する「オプション」の修飾子です。この修飾子は、指定された 1 つまたは複数のノードまたはゾーン上でのみ、1 つまたは複数の拡張プロパティーがリソースの作成時に設定されることを示します。指定した拡張プロパティーは、クラスタ内のほかのノードまたはゾーン上では、設定されません。node-specifier を指定しないと、クラスタ内のすべてのノードおよびゾーン上の指定された拡張プロパティーが設定されます。node-specifier にはノード名またはノード識別子を指定できます。node-specifier の構文例を次に示します。


    -p "myprop{phys-schost-1}"

    中括弧 ({}) は、指定した拡張プロパティーをノード phys-schost-1 でのみ設定することを示します。大部分のシェルでは、二重引用符 (") が必要です。

    また次の構文を使用して、2 つの異なるノード上の 2 つの異なるゾーン内で拡張プロパティーを設定することもできます。


    -x "myprop{phys-schost-1:zoneA,phys-schost-2:zoneB}"
    注 –

    node-specifier を使用して指定する拡張プロパティーは、ノードごとのプロパティーとして RTR ファイルで宣言します。Per_node リソースプロパティーの属性の詳細は、付録 B 「標準プロパティー」を参照してください。

    -p standard-property=value, …

    リソース用に設定する標準プロパティーのコンマ区切りリストを指定します。設定できる標準プロパティーはリソースタイプに依存します。スケーラブルサービスの場合、通常は Port_list、Load_balancing_weights、および Load_balancing_policy プロパティーを設定します。どの標準プロパティーを設定するかを決定するには、リソースタイプのマニュアルと付録 B 「標準プロパティー」を参照してください。

    resource

    追加するリソースの名前を指定します。

    リソースは有効状態で作成されます。

  3. スケーラブルアプリケーションリソースが追加され、妥当性が検査されていることを確認します。


    # clresource show resource
例 2–10 スケーラブルアプリケーションリソースのリソースグループへの追加

次に、リソース (resource-1) をリソースグループ (resource-group-1) に追加する例を示します。resource-group-1 は、使用されているネットワークアドレス (以下の例の schost-1 と schost-2) を含むフェイルオーバーリソースグループに依存することに注意してください。リソースは、共有アドレスリソース (schost-1 と schost-2) に依存し、以前に定義した 1 つまたは複数のフェイルオーバーリソースグループに存在する必要があります。


# clresource create -g resource-group-1 -t resource-type-1 \
-p Network_resources_used=schost-1,schost-2 resource-1 \
-p Scalable=True
# clresource show resource-1

=== Resources ===                              

  Resource:                                        resource-1
  Type:                                            resource-type-1
  Type_version:                                    
  Group:                                           resource-group-1
  R_description:                                   
  Resource_project_name:                           default
  Enabled{phats1}:                                 False
  Enabled{phats2}:                                 False
  Monitored{phats1}:                               True
  Monitored{phats2}:                               True
次の手順

スケーラブルアプリケーションリソースを追加したあと、「リソースグループをオンラインにする」の手順に従ってリソースを有効にします。

注意事項

リソースを追加すると、Sun Cluster ソフトウェアは、そのリソースの妥当性を検査します。妥当性の検査に失敗すると、clresource コマンドはエラーメッセージを出力して終了します。妥当性の検査に失敗した理由を判別するには、エラーメッセージについて各ノード上の syslog を調べてください。メッセージは、妥当性の検査を実施したノードで表示されます。必ずしも clresource コマンドを実行したノードで表示されるわけではありません。

参照

clresource(1CL) のマニュアルページ。

リソースグループをオンラインにする

リソースを有効にして HA サービスの提供を開始するには、次の操作を実行する必要があります。

以上の作業は個別に行うことも、1 つのコマンドを使用して行うこともできます。

リソースグループがオンラインになれば、リソースグループが構成されて使用する準備が整ったことになります。リソース、ノード、またはゾーンで障害が発生した場合は、RGM は別のノードまたはゾーンでそのリソースグループをオンラインに切り替えることでリソースグループの可用性を維持します。

Procedureリソースグループをオンラインにする

この作業は、任意のクラスタノードから実行します。

  1. クラスタメンバーで、スーパーユーザーになるか、solaris.cluster.admin RBAC の承認を提供する役割になります。

  2. コマンドを入力してリソースグループをオンラインにします。

    • 無効のままでなければならないリソースまたは障害モニターを意図的に無効にしている場合は、次のコマンドを入力します。


      # clresourcegroup online rg-list
      rg-list

      オンラインにするリソースグループの名前をコンマで区切って指定します。これらのリソースグループは存在する必要があります。このリストには、1 つまたは複数のリソースグループ名を指定できます。

      rg-list オプションは省略できます。このオプションを省略した場合、すべてのリソースグループがオンラインになります。

    • リソースグループがオンラインになった時点でリソースと障害モニターを有効にする必要がある場合は、次のコマンドを入力します。


      # clresourcegroup online -emM rg-list
      rg-list

      オンラインにするリソースグループの名前をコンマで区切って指定します。これらのリソースグループは存在する必要があります。このリストには、1 つまたは複数のリソースグループ名を指定できます。

      rg-list オプションは省略できます。このオプションを省略した場合、すべてのリソースグループがオンラインになります。

    注 –

    オンラインにしようとしている任意のリソースグループがほかのリソースグループに対して強いアフィニティーを宣言している場合、この操作は失敗します。詳細については、「オンラインのリソースグループをクラスタノード間で分散する」を参照してください。

  3. 手順 2で指定した各リソースグループがオンラインであることを確認します。

    このコマンドからの出力は、どのノードまたはゾーンで各リソースグループがオンラインであるかを示します。


    # clresourcegroup status
例 2–11 リソースグループをオンラインにする

次に、リソースグループ (resource-group-1) をオンラインにし、その状態を確認する例を示します。このリソースのすべてのリソースとその障害モニターも有効になります。


# clresourcegroup online -emM resource-group-1
# clresourcegroup status
次の手順

リソースと障害モニターを有効にすることなくリソースグループをオンラインにした場合、有効にする必要があるリソースの障害モニターを有効にします。詳細については、「リソース障害モニターを有効にする」を参照してください。

参照

clresourcegroup(1CL) のマニュアルページ。

リソースの有効化

リソースグループをオンラインにしたときに有効にしなかったリソースを有効にすることができます。

Procedureリソースを有効にする

注 –

この手順は、任意のクラスタノードから実行します。

始める前に

有効にするリソースを作成し、名前が付いていることを確認します。

  1. クラスタメンバーで、スーパーユーザーになるか、solaris.cluster.admin RBAC の承認を提供する役割になります。

  2. リソースを有効にします。


    # clresource enable [-n node-zone-list] resource
    -n node-zone-list

    リソースを有効にするノードまたはゾーンの、コンマ区切りの順序付きリストを指定します。ゾーンを指定する場合、リストの各エントリの形式は node:zone です。この形式では、 node はノード名を指定し、zone は非大域ゾーンの名前を指定します。大域ゾーンを指定する、または非大域ゾーンを持たないノードを指定するには、node のみを指定します。

    このリストはオプションです。このリストを省略すると、そのリソースグループのノードリスト内のすべてのノード上でリソースが有効になります。

    注 –

    -n オプションを使用して複数のノードまたはゾーンを指定した場合、1 つのリソースのみを指定できます。

    resource

    有効にするリソースの名前を指定します。

  3. リソースが有効であることを確認します。


    # clresource status

    このコマンドからの出力は、有効にしたリソースの状態を示します。

参照

clresource(1CL) のマニュアルページ。

リソースグループの休止

START または STOP メソッドに障害が発生した場合、あるノードまたはゾーンから別のノードまたはゾーンへリソースグループが継続的に切り替わるのを停止するには、そのリソースグループを休止状態にします。リソースグループを休止状態にするには、clresourcegroup quiesce コマンドを実行します。

リソースグループを休止する場合、実行中のリソースメソッドは、完了するまで実行することを許可されます。重大な問題が発生した場合は、ただちにリソースグループを休止する必要がある場合があります。このためには、次のメソッドを終了させる -k コマンドオプションを指定します。

注 –

このコマンドオプションを指定した場合、Init、Fini、Boot、および Update メソッドは終了しません。

ただし、メソッドを終了することによりリソースグループをただちに休止した場合、リソースのいずれかを Start_failed や Stop_failed などのエラー状態のままにしてしまう場合があります。ユーザーは自分自身でこれらのエラー状態を消去する必要があります。

Procedureリソースグループを休止する

  1. スーパーユーザーになるか、solaris.cluster.modify RBAC の承認を提供する役割になります。

  2. リソースグループを休止します。


    # clresourcegroup quiesce resource-group

Procedureただちにリソースグループを休止する

  1. スーパーユーザーになるか、solaris.cluster.modify RBAC の承認を提供する役割になります。

  2. ただちにリソースグループを休止します。


    # clresourcegroup quiesce -k resource-group

    リソースグループと関連付けられている Prenet_start、Start、Monitor_start、Monitor_stop、Stop、および Postnet_stop メソッドはただちに終了します。リソースグループは休止状態になります。

    clresourcegroup quiesce -k コマンドは、指定したリソースグループが休止状態になるまで作業をブロックします。

リソースグループの自動回復アクションの保存停止と再開

リソースグループの自動回復アクションを一時的に中断することもできます。クラスタ内の問題を調べて修正するため、リソースグループの自動回復を中断しなければならなくなる場合があります。または、リソースグループサービスの保守作業を実行しなければならなくなる場合もあります。

リソースグループの自動回復アクションを保存停止するには、clresourcegroup suspend コマンドを実行します。自動回復アクションを再開するには、clresourcegroup resume コマンドを実行します。

リソースグループの自動回復アクションを保存停止した場合は、そのリソースグループを休止状態にすることにもなります。

自動復旧を再開するコマンドを明示的に実行するまで、中断されたリソースグループが自動的に再開またはフェイルオーバーされることはありません。中断されたデータサービスは、オンラインかオフラインかにかかわらず、現在の状態のままとなります。指定したノードまたはゾーン上でリソースグループの状態を手作業で切り替えることもできます。また、リソースグループ内の個々のリソースも有効または無効にできます。

次のいずれかの状況でリソースグループの自動回復アクションを保存停止した場合、依存関係またはアフィニティーは保存停止され、行使されません。

これらのカテゴリのリソースグループのいずれかを保存停止した場合、Sun Cluster は、依存関係またはアフィニティーも保存停止されるという警告を表示します。

注 –

RG_system プロパティーを設定しても、リソースグループの自動回復アクションを保存停止または再開するユーザーの能力には影響しません。RG_system プロパティーが TRUE に設定されているリソースグループを保存停止すると、警告メッセージが表示されます。RG_system プロパティーは、リソースグループに重要なシステムサービスが含まれていることを指定します。TRUE に設定されている場合、RG_system プロパティーは、リソースグループまたはそのリソースをユーザーが誤って停止、削除、または変更できないようにします。

メソッドを終了することによる自動回復の即時保存停止

リソースグループの自動回復アクションを保存停止した場合、実行中のリソースメソッドは完了するまで実行を許可されます。重大な問題が発生した場合、リソースグループの自動回復アクションをただちに保存停止する必要がある場合があります。このためには、次のメソッドを終了させる -k コマンドオプションを指定します。

注 –

このコマンドオプションを指定した場合、Init、Fini、Boot、および Update メソッドは終了しません。

ただし、メソッドを終了することにより自動回復アクションをただちに保存停止した場合、リソースのいずれかを Start_failed や Stop_failed などのエラー状態のままにしてしまう場合があります。ユーザーは自分自身でこれらのエラー状態を消去する必要があります。

Procedureリソースグループの自動回復アクションを保存停止する

  1. スーパーユーザーになるか、solaris.cluster.modify RBAC の承認を提供する役割になります。

  2. リソースグループの自動回復アクションを保存停止します。


    # clresourcegroup suspend resource-group

    指定したリソースグループは、自動回復アクションを再開するまで、自動的に起動、再起動、またはフェイルオーバーされることはありません。「リソースグループの自動回復アクションを再開する」を参照してください。

Procedureリソースグループの自動回復アクションをただちに保存停止する

  1. スーパーユーザーになるか、solaris.cluster.modify RBAC の承認を提供する役割になります。

  2. リソースグループの自動回復アクションをただちに保存停止します。


    # clresourcegroup suspend -k resource-group

    リソースグループと関連付けられている Prenet_start、Start、Monitor_start、Monitor_stop、Stop、および Postnet_stop メソッドはただちに終了します。リソースグループの自動回復アクションは保存停止されます。リソースグループは、ユーザーが自動回復アクションを再開するまで、自動的に起動、再起動、またはフェイルオーバーされることはありません。「リソースグループの自動回復アクションを再開する」を参照してください。

    clresourcegroup suspend -k コマンドは、指定したリソースグループが休止状態になるまで作業をブロックします。

Procedureリソースグループの自動回復アクションを再開する

  1. スーパーユーザーになるか、solaris.cluster.modify RBAC の承認を提供する役割になります。

  2. リソースグループの自動回復アクションを再開します。


    # clresourcegroup resume resource-group

    指定したリソースグループは、自動的に起動、再起動、またはフェイルオーバーされます。

リソースモニターの無効化と有効化

この節の手順では、リソース自体ではなく、リソース障害モニターを有効または無効にする方法を説明します。したがって、障害モニターが無効にされても、そのリソース自体は正常に動作を続けます。ただし、フォルトモニターが無効になっていると、データサービスに障害が発生しても、障害回復は自動的には開始されません。

詳細は、clresource(1CL) のマニュアルページを参照してください。

注 –

これらの手順は、任意のクラスタノードから実行します。

Procedureリソース障害モニターを無効にする

  1. 任意のクラスタメンバーで、スーパーユーザーになるか、solaris.cluster.modify RBAC の承認を提供する役割になります。

  2. リソース障害モニターを無効にします。


    # clresource unmonitor [-n node-zone-list] resource
    -n node-zone-list

    リソースの監視を解除するノードまたはゾーンの、コンマ区切りの順序付きリストを指定します。ゾーンを指定する場合、リストの各エントリの形式は node:zone です。この形式では、 node はノード名を指定し、zone は非大域ゾーンの名前を指定します。大域ゾーンを指定する、または非大域ゾーンを持たないノードを指定するには、node のみを指定します。

    このリストはオプションです。このリストを省略すると、そのリソースグループのノードリスト内のすべてのノード上でリソースの監視が解除されます。

    注 –

    -n オプションを使用して複数のノードまたはゾーンを指定した場合、1 つのリソースのみを指定できます。

    resource

    1 つ以上のリソースの名前を指定します。

  3. 各クラスタノード上で clresource コマンドを実行し、監視対象フィールド (RS Monitored) をチェックし、リソース障害モニターが無効になったことを確認します。


    # clresource show -v
例 2–12 リソース障害モニターを無効にする


# clresource unmonitor resource-1
# clresource show -v
...
RS Monitored: no...

Procedureリソース障害モニターを有効にする

  1. 任意のクラスタメンバーで、スーパーユーザーになるか、solaris.cluster.modify RBAC の承認を提供する役割になります。

  2. リソース障害モニターを有効にします。


    # clresource monitor [-n node-zone-list] resource
    -n node-zone-list

    リソースを監視するノードまたはゾーンの、コンマ区切りの順序付きリストを指定します。ゾーンを指定する場合、リストの各エントリの形式は node:zone です。この形式では、 node はノード名を指定し、zone は非大域ゾーンの名前を指定します。大域ゾーンを指定する、または非大域ゾーンを持たないノードを指定するには、node のみを指定します。

    このリストはオプションです。このリストを省略すると、そのリソースグループのノードリスト内のすべてのノード上でリソースが監視されます。

    注 –

    -n オプションを使用して複数のノードまたはゾーンを指定した場合、1 つのリソースのみを指定できます。

    resource

    1 つ以上のリソースの名前を指定します。

  3. 各クラスタノード上で clresource コマンドを実行し、監視対象フィールド (RS Monitored) をチェックし、リソース障害モニターが有効になったことを確認します。


    # clresource show -v
例 2–13 リソース障害モニターを有効にする


# clresource monitor resource-1
# clresource show -v
...
RS Monitored: yes...

リソースタイプの削除

使用されていないリソースタイプを削除する必要はありませんが、リソースタイプを削除する場合は、次の手順に従います。

注 –

この手順は、任意のクラスタノードから実行します。

Procedureリソースタイプを削除する

リソースタイプを削除するには、リソースタイプを登録解除する前に、クラスタ内でそのタイプのすべてのリソースを無効にし、削除します。

始める前に

削除するリソースタイプのすべてのインスタンスを特定するには、次のコマンドを入力します。


# clresourcetype show -v

  1. クラスタメンバーで、スーパーユーザーになるか、solaris.cluster.modify RBAC の承認を提供する役割になります。

  2. 削除するリソースタイプの各リソースを無効にします。


    # clresource disable resource
    resource

    無効にするリソースの名前を指定します。

  3. 削除するリソースタイプの各リソースを削除します。


    # clresource delete resource
    resource

    削除するリソースの名前を指定します。

  4. リソースタイプの登録を解除します。


    # clresourcetype unregister resource-type
    resource-type

    登録を解除するリソースタイプの名前を指定します。

  5. リソースタイプが削除されていることを確認します。


    # clresourcetype show
例 2–14 リソースタイプの削除

次に、リソースタイプのすべてのリソース (resource-type-1) を無効にして削除したあとで、そのリソースタイプを登録解除する例を示します。この例では、resource-1 は、リソースタイプ resource-type-1 のリソースです。


# clresource disable resource-1
# clresource delete resource-1
# clresourcetype unregister resource-type-1
参照

次のマニュアルページを参照してください。

リソースグループの削除

リソースグループを削除するには、最初にそのリソースグループからすべてのリソースを削除する必要があります。

注 –

この手順は、任意のクラスタノードから実行します。

Procedureリソースグループを削除する

始める前に

削除するリソースタイプのすべてのリソースを特定するには、次のコマンドを入力します。


# clresource show -v

  1. クラスタメンバーで、スーパーユーザーになるか、solaris.cluster.modify RBAC の承認を提供する役割になります。

  2. 次のコマンドを実行し、リソースグループをオフラインに切り替えます。


    # clresourcegroup offline resource-group
    resource-group

    オフラインにするリソースグループの名前を指定します。

  3. リソースグループ内の削除するすべてのリソースを無効にします。


    # clresource disable resource
    resource

    無効にするリソースの名前を指定します。

  4. リソースグループからすべてのリソースを削除します。

    リソースごとに次のコマンドを入力します。


    # clresource delete resource
    resource

    削除するリソースの名前を指定します。

  5. リソースグループを削除します。


    # clresourcegroup delete resource-group
    resource-group

    削除するリソースグループの名前を指定します。

  6. リソースグループが削除されていることを確認します。


    # clresourcegroup show
例 2–15 リソースグループの削除

次に、リソースグループ (resource-group-1) のリソース (resource-1) を削除したあとで、そのリソースグループ自体を削除する例を示します。


# clresourcegroup offline resource-group-1
# clresource disable resource-1
# clresource delete resource-1
# clresourcegroup delete resource-group-1
参照

次のマニュアルページを参照してください。

リソースの削除

リソースグループからリソースを削除する前に、そのリソースを無効にします。

注 –

この手順は、任意のクラスタノードから実行します。

Procedureリソースを削除する

  1. クラスタメンバーで、スーパーユーザーになるか、solaris.cluster.modify RBAC の承認を提供する役割になります。

  2. 削除するリソースを無効にします。


    # clrsource disable resource
    resource

    無効にするリソースの名前を指定します。

  3. リソースを削除します。


    # clresource delete resource
    resource

    削除するリソースの名前を指定します。

  4. リソースが削除されていることを確認します。


    # clresource show
例 2–16 リソースの削除

次に、リソース resource-1 を無効にして削除する例を示します。


# clresource disable resource-1
# clresource delete resource-1
参照

clresource(1CL)

リソースグループの主ノードの切り替え

以下の手順を使用し、リソースグループの現在の主ノードを別のノードまたはゾーンに切り替え (スイッチオーバー)、新しい主ノードにすることができます。

Procedureリソースグループの主ノードを切り替える

注 –

この手順は、任意のクラスタノードから実行します。

始める前に

次の条件が満たされているか確認します。

リソースグループの潜在的主ノードの一覧を表示するには、次のコマンドを入力します。


# clresourcegroup show -v

  1. クラスタメンバーで、スーパーユーザーになるか、solaris.cluster.modify RBAC の承認を提供する役割になります。

  2. リソースグループを、新しい主ノードのセットに切り替えます。


    # clresourcegroup switch [-n node-zone-list] resource-group
    -n node-zone-list

    このリソースグループをマスターできるゾーンの、コンマ区切りの順序付けされたリストを指定します。このリソースグループは、このノード以外のすべてのノードでオフラインに切り替えられます。リスト内の各エントリの形式は node:zone です。この形式では、 node はノード名を指定し、zone は非大域 Solaris ゾーンの名前を指定します。大域ゾーンを指定する、または非大域ゾーンを持たないノードを指定するには、node のみを指定します。

    このリストはオプションです。このリストを省略すると、そのリソースグループのノードリスト内のすべてのノード上でリソースグループが切り替えられます。

    resource-group

    切り替えるリソースグループの名前を指定します。

    注 –

    切り替えようとしている任意のリソースグループが他のリソースグループに対して強いアフィニティーを宣言している場合、その操作は失敗するか、委任されます。詳細については、「オンラインのリソースグループをクラスタノード間で分散する」を参照してください。

  3. リソースグループが新しい主ノードへ切り替えられていることを確認します。

    このコマンドからの出力は、スイッチオーバーされたリソースグループの状態を示しています。


    # clresourcegroup status
例 2–17 リソースグループの新しい主ノードへの切り替え

次に、リソースグループ (resource-group-1) を現在の主ノード (phys-schost-1) から、潜在的主ノード (phys-schost-2) へ切り替える例を示します。

  1. phys-schost-1 でリソースグループがオンラインであることを確認するには、次のコマンドを実行します。


    phys-schost-1# clresourcegroup status 
            
=== Cluster Resource Groups ===

    Group Name                   Node Name          Suspended        Status
    ----------                   ---------          ---------         ------

resource-group1                phys-schost-1             No           Online
                               phys-schost-2             No           Offline

  2. 切り替えを実行するには、次のコマンドを実行します。


    phys-schost-1# clresourcegroup switch -n phys-schost-2 resource-group-1

  3. phys-schost-2 でグループがオンラインに切り替わったことを確認するには、次のコマンドを実行します。


    phys-schost-1# clresourcegroup status 
           
=== Cluster Resource Groups ===

    Group Name                   Node Name          Suspended        Status
    ----------                   ---------          ---------         ------

resource-group1                phys-schost-1             No           Offline
                               phys-schost-2             No           Online
参照

clresourcegroup(1CL) のマニュアルページ。

リソースの無効化とリソースグループの UNMANAGED 状態への移行

リソースグループは、そのリソースグループに対して管理手順を実施する前に、UNMANAGED 状態に移行する必要があります。リソースグループを UNMANAGED 状態に移行する前に、リソースグループに含まれるすべてのリソースを無効にし、リソースグループをオフラインにする必要があります。

詳細は、clresourcegroup(1CL) のマニュアルページを参照してください。

注 –

この手順は、任意のクラスタノードから実行します。

Procedureリソースを無効にしてリソースグループを UNMANAGED 状態に移行する

注 –

共有アドレスリソースを無効にしても、そのリソースは依然として一部のホストから ping(1M) コマンドに応答できる場合があります。無効にした共有アドレスリソースが ping コマンドに応答しないようにするには、そのリソースのリソースグループを UNMANAGED 状態にする必要があります。

始める前に

次の情報を用意してください。

この手順に必要なリソースとリソースグループの名前を判断するには、次のコマンドを入力します。


# clresourcegroup show -v

  1. 任意のクラスタメンバーで、スーパーユーザーになるか、solaris.cluster.admin RBAC の承認を提供する役割になります。

  2. リソースグループのすべてのリソースを無効にします。


    # clresource disable [-n node-zone-list] -g resource-group +
    -n node-zone-list

    リソースを無効にするノードまたはゾーンの、コンマ区切りの順序付きリストを指定します。ゾーンを指定する場合、リストの各エントリの形式は node:zone です。この形式では、 node はノード名を指定し、zone は非大域ゾーンの名前を指定します。大域ゾーンを指定する、または非大域ゾーンを持たないノードを指定するには、node のみを指定します。

    このリストはオプションです。このリストを省略すると、そのリソースグループのノードリスト内のすべてのノード上でリソースが無効になります。

    注 –

    -n オプションを使用して複数のノードまたはゾーンを指定した場合、1 つのリソースのみを指定できます。

  3. リソースグループをオフラインに切り替えます。


    # clresourcegroup offline resource-group
    resource-group

    オフラインにするリソースグループの名前を指定します。

  4. リソースグループをUNMANAGED 状態にします。


    # clresourcegroup unmanage resource-group
    resource-group

    UNMANAGED 状態にするリソースグループの名前を指定します。

  5. リソースが無効になり、リソースグループが UNMANAGED 状態になっていることを確認します。


    # clrsourcegroup show resource-group
例 2–18 リソースを無効化とリソースグループの UNMANAGED 状態への移行

次に、リソース (resource-1) を無効にし、リソースグループ (resource-group-1) を UNMANAGED 状態に移行する例を示します。


# clresource disable resource-1
# clresourcegroup offline resource-group-1
# clresourcegroup unmanage resource-group-1
# clresourcegroup show resource-group-1

=== Resource Groups and Resources ===

Resource Group:                                 resource-group-1
RG_description:                                 <NULL>
RG_mode:                                        Failover
RG_state:                                       Unmanaged
Failback:                                       False
Nodelist:                                       phys-schost-1 phys-schost-2

  --- Resources for Group resource-group-1 ---

  Resource:                                      resource-1
  Type:                                          SUNW.LogicalHostname:2
  Type_version:                                  2
  Group:                                         resource-group-1
  R_description:                                 
  Resource_project_name:                         default
  Enabled{phys-schost-1}:                        False
  Enabled{phys-schost-2}:                        False
  Monitored{phys-schost-1}:                      True
  Monitored{phys-schost-2}:                      True
参照

次のマニュアルページを参照してください。

リソースタイプ、リソースグループ、リソース構成情報の表示

リソース、リソースグループ、リソースタイプで管理手順を実施する前に、これらのオブジェクトの現在の構成設定を表示します。

注 –

任意のクラスタノードまたはゾーンから、リソース、リソースグループ、リソースタイプの構成設定を表示できます。

また、 clresourcetype、clresourcegroup、および clresource コマンドを使用して、特定のリソースタイプ、リソースグループ、およびリソースに関するステータス情報をチェックすることもできます。たとえば、次のコマンドは、リソース apache-1 のみについて、特定の情報を表示することを指定します。


# clresource show apache-1

詳細は、次のマニュアルページを参照してください。

リソースタイプ、リソースグループ、リソースプロパティーの変更

Sun Cluster は、リソースタイプ、リソースグループ、およびリソースを構成するための標準プロパティーを定義します。これらの標準プロパティーについては、次の節を参照してください。

また、リソースには、リソースを表現するデータサービスの拡張プロパティーも事前定義されています。データサービスの拡張プロパティーについては、データサービスのマニュアルを参照してください。

プロパティーを変更できるかどうかを判断するには、そのプロパティーの説明において、プロパティーの調整エントリを参照してください。

次の手順に、リソースタイプ、リソースグループ、およびリソースを構成するためのプロパティーを変更する方法について説明します。

Procedureリソースタイププロパティーを変更する

注 –

この手順は、任意のクラスタノードから実行します。

始める前に

次の情報を用意してください。

  1. クラスタメンバーで、スーパーユーザーになるか、solaris.cluster.modify RBAC の承認を提供する役割になります。

  2. clresourcetype コマンドを使用し、この手順に必要なリソースタイプの名前を判断します。


    # clresourcetype show -v

  3. リソースタイププロパティーを変更します。

    リソースタイプの場合、特定のプロパティーだけを変更できます。プロパティーを変更できるかどうかを判断するには、「資源タイプのプロパティー」でプロパティーの Tunable エントリを参照してください。


    # clresourcetype set -n installed-node-list \
[-p property=new-value]resource-type
    -n installed-node-list

    このリソースタイプがインストールされるノードの名前を指定します。

    -p property=new-value

    変更する標準プロパティーの名前と、そのプロパティーの新しい値を指定します。

    Installed_nodes プロパティーは明示的には変更できません。このプロパティーを変更するには、clresourcetype コマンドの -n installed-node-list オプションを指定します。

  4. リソースタイププロパティーが変更されていることを確認します。


    # clresourcetype show resource-type
例 2–19 リソースタイププロパティーの変更

次に、SUNW.apache プロパティーを変更し、このリソースタイプがノード (phys-schost-1 および phys-schost-2) の大域ゾーンにインストールされるように定義する例を示します。


# clresourcetype set -n phys-schost-1,phys-schost-2 SUNW.apache
# clresourcetype show SUNW.apache

Resource Type:                                     SUNW.apache:4
  RT_description:                                  Apache Web Server on Sun Cluster
  RT_version:                                      4
  API_version:                                     2
  RT_basedir:                                      /opt/SUNWscapc/bin
  Single_instance:                                 False
  Proxy:                                           False
  Init_nodes:                                      All potential masters
  Installed_nodes:                                 All
  Failover:                                        False
  Pkglist:                                         SUNWscapc
  RT_system:                                       False

Procedureリソースグループプロパティーを変更する

この手順では、リソースグループプロパティーの変更方法について説明します。リソースグループパーティーの詳細については、「 リソースグループのプロパティー」を参照してください。

注 –

この手順は、任意のクラスタノードから実行します。

始める前に

次の情報を用意してください。

  1. クラスタメンバーで、スーパーユーザーになるか、solaris.cluster.modify RBAC の承認を提供する役割になります。

  2. リソースグループプロパティーを変更します。


    # clresourcegroup set -p property=new-value resource-group
    -p property

    変更するプロパティーの名前を指定します。

    resource-group

    リソースグループの名前を指定します。

  3. リソースグループプロパティーが変更されていることを確認します。


    # clresourcegroup show resource-group
例 2–20 リソースグループプロパティーの変更

次に、リソースグループ (resource-group-1) の Failback プロパティーを変更する例を示します。


# clresourcegroup set-p Failback=True resource-group-1
# clrsourcegroup show resource-group-1

Procedureリソースプロパティーを変更する

この手順では、リソースの拡張プロパティーと標準プロパティーを変更する方法を説明します。

注 –

この手順は、任意のクラスタノードから実行します。

始める前に

次の情報を用意してください。

  1. クラスタメンバーで、スーパーユーザーになるか、solaris.cluster.modify RBAC の承認を提供する役割になります。

  2. 現在のリソースプロパティー設定を表示します。


    # clresource show -v resource

  3. リソースプロパティーを変更します。


    # clresource set -p standard-property=new-value | -p "extension-property[{node-specifier}]"=new-value resource
    -p standard-property=new-value

    変更する標準プロパティーの名前を指定します。

    -p "extension-property[{node-specifier}]"=new-value

    変更する拡張プロパティーの名前を指定します。

    node-specifier は、-p オプションおよび -x オプションに対する「オプション」の修飾子です。この修飾子は、指定された 1 つまたは複数のノードまたはゾーン上でのみ、1 つまたは複数の拡張プロパティーがリソースの作成時に設定されることを示します。指定した拡張プロパティーは、クラスタ内のほかのノードまたはゾーン上では、設定されません。node-specifier を指定しないと、クラスタ内のすべてのノードおよびゾーン上の指定された拡張プロパティーが設定されます。node-specifier にはノード名またはノード識別子を指定できます。node-specifier の構文例を次に示します。


    -p "myprop{phys-schost-1}"

    中括弧 ({}) は、指定した拡張プロパティーをノード phys-schost-1 でのみ設定することを示します。大部分のシェルでは、二重引用符 (") が必要です。

    また次の構文を使用して、2 つの異なるノード上の 2 つの異なるゾーン内で拡張プロパティーを設定することもできます。


    -x "myprop{phys-schost-1:zoneA,phys-schost-2:zoneB}"
    注 –

    node-specifier を使用して指定する拡張プロパティーは、ノードごとのプロパティーとして RTR ファイルで宣言します。Per_node リソースプロパティーの属性の詳細は、付録 B 「標準プロパティー」を参照してください。

    resource

    リソースの名前を指定します。

  4. リソースプロパティーが変更されていることを確認します。


    # clresource show -v resource
例 2–21 標準リソースプロパティーの変更

次に、リソース (resource-1) のシステム定義プロパティー (Start_timeout) の変更例を示します。


# clresource set -p start_timeout=30 resource-1
# clresource show -v resource-1
例 2–22 拡張リソースプロパティーの変更

次に、リソース (resource-1) の拡張プロパティー (Log_level) の変更例を示します。


# clresource set -p Log_level=3 resource-1
# clresource show -v resource-1

Procedure論理ホスト名リソースまたは共有アドレスリソースを変更する

デフォルトでは、論理ホスト名リソースと共有アドレスリソースは名前解決にネームサービスを使用します。 同じクラスタ上で動作するネームサービスを使用するようにクラスタを構成することも可能です。論理ホスト名リソースまたは共有アドレスリソースがフェイルオーバーされると、そのクラスタ上で動作しているネームサービスもフェイルオーバーされます。論理ホスト名リソースまたは共有アドレスリソースが使用するネームサービスがフェイルオーバーしている場合、このリソースはフェイルオーバーできません。

注 –

同じクラスタ上で動作しているネームサービスを使用するようにクラスタを構成すると、そのクラスタ上のほかのサービスの可用性を損なう可能性があります。

このようなフェイルオーバーの失敗を防ぐには、ネームサービスをバイパスするように論理ホスト名リソースまたは共有アドレスリソースを変更します。ネームサービスをバイパスするようにリソースを変更するには、リソースの CheckNameService 拡張プロパティーを false に設定します。CheckNameService プロパティーはいつでも変更できます。

注 –

リソースタイプのバージョンが 2 より前の場合、リソースを変更する前に、まず、リソースタイプをアップグレードする必要があります。詳細については、「事前登録されているリソースタイプのアップグレード」を参照してください。

  1. クラスタメンバーで、スーパーユーザーになるか、solaris.cluster.modify RBAC の承認を提供する役割になります。

  2. リソースプロパティーを変更します。


    # clresource set -p CheckNameService=false resource
    -p CheckNameService=false

    リソースの CheckNameService 拡張プロパティーを false に設定します。

    resource

    変更する論理ホスト名リソースまたは共有アドレスリソースの名前を指定します。

リソースの STOP_FAILED エラーフラグの消去

Failover_mode リソースプロパティーが NONE または SOFT に設定されている場合、リソースの STOP メソッドが失敗すると、次のような影響があります。

このような状況では、次の操作を行うことができません。

Procedureリソースの STOP_FAILED エラーフラグを消去する

注 –

この手順は、任意のクラスタノードから実行します。

始める前に

次の情報を用意してください。

  1. クラスタメンバーで、スーパーユーザーになるか、solaris.cluster.modify RBAC の承認を提供する役割になります。

  2. STOP_FAILED 状態のリソースと、どのノードまたはゾーンでこの状態なのかを確認します。


    # clresource status

  3. STOP_FAILED 状態になっているノードまたはゾーン上で、リソースとそのモニターを手作業で停止します。

    この手順では、プロセスを強制終了するか、リソースタイプ固有のコマンドまたは別のコマンドを実行する必要があります。

  4. リソースの STOP_FAILED エラーフラグを消去します。


    # clresource clear -f STOP_FAILED -n nodelist resource
    -f STOP_FAILED

    フラグ名を指定します。

    -n nodelist

    リソースが STOP_FAILED 状態であるノードの名前をコンマで区切って指定します。このリストには、1 つまたは複数のノード名を指定できます。

    resource

    リソースの名前を指定します。

  5. 手順 4で STOP_FAILED フラグを消去したノードまたはゾーンで、リソースグループの状態を調べます。


    # clresourcegroup status

    リソースグループの状態は、OFFLINE または ONLINE になっています。

    次の環境の組み合わせでは、リソースグループは ERROR_STOP_FAILED 状態のままになっています。

    • STOP メソッドの失敗が発生した時点でリソースグループがオフラインに切り替えられている。

    • 停止に失敗したリソースがリソースグループ内のそのほかのリソースに依存している。

  6. リソースグループが ERROR_STOP_FAILED 状態のままである場合、次のようにエラーを修正します。

    1. 適切なノードまたはゾーン上でリソースグループをオフラインにします。


      # clresourcegroup offline resource-group
      resource-group

      オフラインに切り替えるリソースグループの名前を指定します。

    2. リソースグループをオンラインにします。

参照

次のマニュアルページを参照してください。

Start_failed リソース状態の消去

Start_failed リソース状態は、Start メソッドまたは Prenet_start メソッドがリソース上で失敗またはタイムアウトしたが、そのリソースグループは結果的にオンラインになっていることを示します。リソースグループは、リソースが障害状態に置かれていてサービスを提供していなくても、オンライン状態になります。この状態は、リソースの Failover_mode プロパティーに None またはリソースグループのフェイルオーバーを妨げる別の値が設定されている場合に発生することがあります。

Stop_failed リソース状態とは異なり、 Start_failed リソース状態は、ユーザーや Sun Cluster ソフトウェアがリソースグループ上で操作を実行することを妨げません。該当リソースを再起動するコマンドを実行するだけで済みます。

この状態を消去するには、次のいずれかの手順を使用します。

Procedureリソースグループのスイッチオーバーにより Start_failed リソース状態を解除する

注 –

この手順は、任意のクラスタノードから実行します。

始める前に

次の条件が満たされているか確認します。

  1. クラスタメンバーで、スーパーユーザーになるか、solaris.cluster.modify RBAC の承認を提供する役割になります。

  2. リソースグループを新しいノードまたはゾーンに切り替えます。


    # clresourcegroup switch [-n node-zone-list] resource-group
    -n node-zone-list

    このリソースグループをマスターできるノードまたはゾーンの、コンマ区切りの順序付けされたリストを指定します。このリソースグループは、このノード以外のすべてのノードでオフラインに切り替えられます。リスト内の各エントリの形式は node:zone です。この形式では、 node はノード名を指定し、zone は非大域 Solaris ゾーンの名前を指定します。大域ゾーンを指定する、または非大域ゾーンを持たないノードを指定するには、node のみを指定します。

    このリストはオプションです。このリストを省略すると、そのリソースグループのノードリスト内のすべてのノード上でリソースグループが切り替えられます。

    resource-group

    切り替えるリソースグループの名前を指定します。

    注 –

    切り替えようとしている任意のリソースグループが他のリソースグループに対して強いアフィニティーを宣言している場合、その操作は失敗するか、委任されます。詳細については、「オンラインのリソースグループをクラスタノード間で分散する」を参照してください。

  3. リソースグループが新しいノードまたはゾーンに切り替えられ、Start_failed リソース状態が解除されたことを確認します。


    # clresourcegroup status

    このコマンドからの出力は、スイッチオーバーされたリソースおよびリソースグループの状態を示しています。

例 2–23 リソースグループのスイッチオーバーによる Start_failed リソース状態の解除

次の例で、resource-group-1 リソースグループの rscon リソースで発生した Start_failed リソース状態を解除する方法を示します。このコマンドは、リソースグループを大域ゾーン phys-schost-2 に切り替えることで、この状態を解除します。

  1. phys-schost-1 上でリソースが Start_failed リソース状態であること確認するには、次のコマンドを実行します。


    # clresource status

=== Cluster Resources ===

Resource Name             Node Name       Status        Message
--------------            ----------      -------        -------
 rscon               phys-schost-1       Faulted         Faulted
                     phys-schost-2       Offline          Offline

 hastor              phys-schost-1       Online          Online
                     phys-schost-2       Offline         Offline

  2. 切り替えを実行するには、次のコマンドを実行します。


    # clresourcegroup switch -n phys-schost-2 resource-group-1

  3. リソースグループが phys-schost-2 上でオンラインに切り替えられ、Start_failed リソース状態が解除されたことを確認するには、次のコマンドを実行します。


    # clresource status


=== Cluster Resources ===

Resource Name             Node Name       Status        Message
--------------            ----------      -------        -------
 rscon               phys-schost-1       Offline         Offline
                     phys-schost-2       Online          Online

 hastor              phys-schost-1       Online          Online
                     phys-schost-2       Offline         Offline
参照

clresourcegroup(1CL) のマニュアルページ。

Procedureリソースグループの再起動により Start_failed リソース状態を解除する

注 –

この手順は、任意のクラスタノードから実行します。

始める前に

次の条件が満たされているか確認します。

  1. クラスタメンバーで、スーパーユーザーになるか、solaris.cluster.modify RBAC の承認を提供する役割になります。

  2. リソースグループを再起動します。


    # clresourcegroup restart -n node resource-group
    -n node

    再起動するリソースグループのノードの名前を指定します。このリソースグループは、このノード以外のすべてのノードでオフラインに切り替えられます。

    resource-group

    再起動するリソースグループの名前を指定します。

  3. リソースグループが新しいノード上で再起動され、Start_failed リソース状態が解除されたことを確認します。


    # clresourcegroup status

    このコマンドからの出力は、再起動されたリソースおよびリソースグループの状態を示しています。

例 2–24 リソースグループの再起動による Start_failed リソース状態の解除

次の例で、resource-group-1 リソースグループの rscon リソースで発生した Start_failed リソース状態を解除する方法を示します。このコマンドは、リソースグループを大域ゾーン phys-schost-2 上で再起動することで、この状態を解除します。

  1. phys-schost-1 上でリソースが Start_failed リソース状態であること確認するには、次のコマンドを実行します。


    # clresource status

=== Cluster Resources ===

Resource Name             Node Name       Status        Message
--------------            ----------      -------        -------
 rscon               phys-schost-1       Faulted         Faulted
                     phys-schost-2       Offline          Offline

 hastor              phys-schost-1       Online          Online
                     phys-schost-2       Offline         Offline

  2. このリソースを再起動するには、次のコマンドを使用します。


    # clresourcegroup restart -n phys-schost-1 –g resource-group-1

  3. リソースグループが phys-schost-1 上で再起動され、Start_failed リソース状態が解除されたことを確認するには、次のコマンドを実行します。


    # clresource status

=== Cluster Resources ===

Resource Name             Node Name       Status        Message
--------------            ----------      -------        -------
 rscon               phys-schost-1       Offline         Offline
 rscon               phys-schost-2       Online          Online

 hastor              phys-schost-1       Online          Online
 hastor              phys-schost-2       Offline         Offline
参照

clresourcegroup(1CL) のマニュアルページ。

Procedureリソースの無効化および有効化によりリソース状態 Start_failed を解除する

注 –

この手順は、任意のクラスタノードから実行します。

始める前に

有効または無効にするリソースの名前を確認します。

  1. クラスタメンバーで、スーパーユーザーになるか、solaris.cluster.modify RBAC の承認を提供する役割になります。

  2. リソースを無効にしてから有効にします。


    # clresource disable resource
# clresource enable resource
    resource

    リソースの名前を指定します。

  3. リソースが無効になってから有効になり、Start_failed リソース状態が解除されたことを確認します。


    # clresource status

    このコマンドからの出力は、無効にしてから再度有効にしたリソースの状態を示します。

例 2–25 リソースの無効化および有効化によるリソース状態 Start_failed の解除

次の例で、リソースを無効にしてから有効にすることで、rscon リソースで発生した Start_failed リソース状態を解除する方法を示します。

  1. リソースが Start_failed リソース状態であることを確認するには、次のコマンドを実行します。


    # clresource status

=== Cluster Resources ===

Resource Name             Node Name       Status        Message
--------------            ----------      -------        -------
 rscon               phys-schost-1       Faulted         Faulted
                     phys-schost-2       Offline          Offline

 hastor              phys-schost-1       Online          Online
                     phys-schost-2       Offline         Offline

  2. リソースを無効にしてから再度有効にするには、次のコマンドを実行します。


    # clresource disable rscon
# clresource enable rscon

  3. リソースが再度有効にされ、Start_failed リソース状態が解除されたこと確認するには、次のコマンドを実行します。


    # clresource status


=== Cluster Resources ===

Resource Name             Node Name       Status        Message
--------------            ----------      -------        -------
 rscon               phys-schost-1       Online         Online
                     phys-schost-2       Offline        Offline

 hastor              phys-schost-1       Online          Online
                     phys-schost-2       Offline         Offline
参照

clresource(1CL) のマニュアルページ。

事前登録されているリソースタイプのアップグレード

Sun Cluster 3.1 9/04 では、次の事前登録されているリソースタイプが拡張されています。

これらのリソースタイプが拡張された目的は、名前解決用のネームサービスをバイパスするように論理ホスト名リソースと共有アドレスリソースを変更できるようにするためです。

以下の条件が当てはまる場合は、これらのリソースタイプをアップグレードします。

リソースタイプをアップグレードする方法については、 「リソースタイプの更新」を参照してください。以下の各項では、事前登録されているリソースタイプのアップグレードに必要な情報について説明します。

新しいリソースタイプバージョンの登録に関する情報

次の表に、事前登録されている各リソースタイプバージョンと Sun Cluster のリリース間の関係を示します。Sun Cluster のリリースは、リソースタイプが導入されたバージョンを表します。

リソース型 

リソースタイプバージョン 

Sun Cluster のリリース 

SUNW.LogicalHostname

 

1.0 

3.0 

2 

3.1 9/04 

SUNW.SharedAddress

 

1.0 

3.0 

2 

3.1 9/04 

登録されているリソースタイプのバージョンを調べるには、次のどちらかのコマンドを使用します。

例 2–26 SUNW.LogicalHostname リソースタイプの新しいバージョンの登録

この例では、アップグレード時に、SUNW.LogicalHostname リソースタイプのバージョン 2 を登録するためのコマンドを示します。


# clresourcetype register SUNW.LogicalHostname:2

リソースタイプの既存インスタンスの移行に関する情報

次に、事前登録されているリソースタイプのインスタンスを移行する必要がある情報を示します。

例 2–27 論理ホスト名リソースの移行

この例では、論理ホスト名リソース lhostrs を移行するためのコマンドを示します。移行の結果として、このリソースは名前解決用のネームサービスをバイパスするように変更されます。


# clresource set -p CheckNameService=false -p Type_version=2 lhostrs

事前登録されているリソースタイプを誤って削除した後の再登録

リソースタイプ SUNW.LogicalHostname および SUNW.SharedAddress は事前に登録されています。すべての論理ホスト名と共有アドレスリソースがこれらのリソースタイプを使用します。これら 2 つのリソースタイプは、誤って削除した場合を除き、登録する必要はありません。誤ってリソースタイプを削除した場合は、次の手順を使用して再登録してください。

注 –

事前登録されているリソースタイプをアップグレードしている場合は、「事前登録されているリソースタイプのアップグレード」の指示に従って、新しいリソースタイプのバージョンを登録してください。

注 –

この手順は、任意のクラスタノードから実行します。

Procedure事前登録されているリソースタイプを誤って削除した後に再登録する

  1. リソースタイプを再登録します。


    # clresourcetype register SUNW.resource-type
    resource-type

    追加する (再登録する) リソースタイプを指定します。リソースタイプは、SUNW.LogicalHostname または SUNW.SharedAddress のいずれかになります。

例 2–28 事前登録されているリソースタイプを誤って削除したあとに再登録する

次に、SUNW.LogicalHostname リソースタイプを再登録する例を示します。


# clresourcetype register SUNW.LogicalHostname
参照

clresourcetype(1CL) のマニュアルページ。

リソースグループへのノードの追加と削除

この節の手順では、次の作業を行います。

ノードまたはゾーンの追加や削除をフェイルオーバーリソースグループに対して行うのか、スケーラブルリソースグループに対して行うのかによって、手順は異なります。

フェイルオーバーリソースグループは、フェイルオーバーとスケーラブルの両方のサービスによって使用されるネットワークリソースを含みます。クラスタに接続される各 IP サブネットワークは、指定された独自のネットワークリソースを持ち、フェイルオーバーリソースグループに含まれます。このネットワークリソースは、論理ホスト名または共有アドレスリソースのいずれかになります。各ネットワークリソースは、それが使用する IP ネットワークマルチパスグループのリストを含んでいます。フェイルオーバーリソースグループの場合は、リソースグループ (netiflist リソースプロパティー) に含まれる各ネットワークリソースに対し、IP ネットワークマルチパスグループの完全なリストを更新する必要があります。

スケーラブルリソースグループの手順には、次の手順が含まれます。

  1. スケーラブルリソースによって使用されるネットワークリソースを含むフェイルオーバーグループのための手順を繰り返す

  2. スケーラブルグループをホストの新しいセット上でマスターされるように変更する

詳細は、clresourcegroup(1CL) のマニュアルページを参照してください。

注 –

いずれの手順も任意のクラスタノードから実行できます。

リソースグループにノードを追加する

ノードまたはゾーンをリソースグループに追加する手順は、リソースグループがスケーラブルリソースグループであるか、またはフェイルオーバーリソースグループであるかによって異なります。詳細の手順については、以下の節を参照してください。

この手順を実行するには、次の情報が必要になります。

さらに、新しいノードがすでにクラスタメンバーになっていることも確認してください。

Procedureスケーラブルリソースグループにノードを追加する

  1. リソースグループ内のスケーラブルリソースが使用する各ネットワークリソースごとに、そのネットワークリソースが配置されているリソースグループが新しいノードで実行されるようにします。

    詳細は、以下の作業の手順 1 から手順 5 を参照してください。

  2. スケーラブルリソースグループをマスターできるノードまたはゾーンのリスト (nodelist リソースグループプロパティー) に新しいノードまたはゾーンを追加します。

    この手順は、nodelist の値を上書きするため、リソースグループをマスターできるすべてのノードをここに含める必要があります。


    # clresourcegroup set [-n node-zone-list] resource-group
    -n node-zone-list

    このリソースグループをマスターできるノードまたはゾーンの、コンマ区切りの順序付けされたリストを指定します。このリソースグループは、このノード以外のすべてのノードでオフラインに切り替えられます。リスト内の各エントリの形式は node:zone です。この形式では、 node はノード名を指定し、zone は非大域 Solaris ゾーンの名前を指定します。大域ゾーンを指定する、または非大域ゾーンを持たないノードを指定するには、node のみを指定します。

    このリストはオプションです。このリストを省略すると、Nodelist プロパティーがクラスタ内のすべてのノードに対して設定されます。

    resource-group

    ノードまたはゾーンが追加されるリソースグループの名前を指定します。

  3. (省略可能) スケーラブルリソースの Load_balancing_weights プロパティーを更新し、リソースグループに追加するノードまたはゾーンにウエイトを割り当てます。

    ウエイトを割り当てない場合は、デフォルトで 1 になります。詳細は、clresourcegroup(1CL) のマニュアルページを参照してください。

Procedureフェイルオーバーリソースグループにノードを追加する

  1. 現在のノードリスト、およびリソースグループ内の各リソース用に構成された IP ネットワークマルチパスグループの現在のリストを表示します。


    # clresourcegroup show -v resource-group | grep -i nodelist
# clresourcegroup show -v resource-group | grep -i netiflist
    注 –

    nodelist と netiflist のコマンド行出力では、ノード名でノードが識別されます。ノード ID を識別するには、コマンド clnode show -v | grep -i node-id を実行してください。

  2. ノードまたはゾーンの追加によって影響を受けるネットワークリソースの netiflist を更新します。

    この手順は、netiflist の値を上書きするため、すべての IP ネットワークマルチパスグループをここに含める必要があります。


    # clresource set  -p netiflist=netiflist network-resource
    -p netiflist=netiflist

    各ノードまたはゾーン上の IP ネットワークマルチパス グループをコンマで区切って指定します。netiflist の各要素は、netif@node の形式にする必要があります。netif は IP ネットワークマルチパス グループ名 (sc_ipmp0 など) として指定できます。ノードは、ノード名またはノード ID (sc_ipmp0@1、sc_ipmp@phys-schost-1 など) で識別できます。

    network-resource

    netiflist エントリ上でホストされているネットワークリソースの名前 (論理ホスト名または共有アドレス) を指定します。

  3. HAStoragePlus AffinityOn 拡張プロパティーが True に等しい場合、適切なディスクセットまたはデバイスグループにノードを追加します。

    • Solstice DiskSuite または Solaris Volume Manager を使用している場合は、metaset コマンドを使用します。


      # metaset -s disk-set-name -a -h node-name
      -s disk-set-name

      metaset コマンドの実行対象となるディスクセットの名前を指定します。

      -a

      指定したディスクセットにドライブまたはホストを追加します。

      -h node-name

      ディスクセットに追加するノードを指定します。

    • SPARC:VERITAS Volume Manager を使用している場合は clsetup ユーティリティーを使用します。

      1. アクティブなクラスタメンバー上で clsetup ユーティリティーを起動します。


        # clsetup

        メインメニューが表示されます。

      2. メインメニューで、デバイスグループおよびボリュームのオプションに対応する数字を入力します。

      3. 「デバイスグループとボリューム」メニューで、ノードを VxVM デバイスグループに追加するためのオプション対応する数字を入力します。

      4. プロンプトに応答し、VxVM デバイスグループにノードを追加します。

  4. このリソースグループをマスターできるすべてのノードまたはゾーンを含めるように、ノードリストを更新します。

    この手順は、nodelist の値を上書きするため、リソースグループをマスターできるすべてのノードまたはゾーンをここに含める必要があります。


    # clresourcegroup set [-n node-zone-list] resource-group
    -n node-zone-list

    このリソースグループをマスターできるゾーンの、コンマ区切りの順序付けされたリストを指定します。このリソースグループは、このノード以外のすべてのノードでオフラインに切り替えられます。リスト内の各エントリの形式は node:zone です。この形式では、 node はノード名を指定し、zone は非大域 Solaris ゾーンの名前を指定します。大域ゾーンを指定する、または非大域ゾーンを持たないノードを指定するには、node のみを指定します。

    このリストはオプションです。このリストを省略すると、Nodelist プロパティーがクラスタ内のすべてのノードに対して設定されます。

    resource-group

    ノードまたはゾーンが追加されるリソースグループの名前を指定します。

  5. 更新された情報を確認します。


    # clresourcegroup show -vresource-group | grep -i nodelist
# clresourcegroup show -vresource-group | grep -i netiflist
例 2–29 リソースグループにノードを追加する

次に、リソースグループ (resource-group-1) に大域ゾーン (phys-schost-2) を追加する例を示します。このリソースグループは、論理ホスト名リソース (schost-2) を含んでいます。


# clresourcegroup show -v resource-group-1 | grep -i nodelist
( Nodelist:    phys-schost-1 phys-schost-3
# clresourcegroup show -v resource-group-1 | grep -i netiflist
( Res property name: NetIfList
 Res property class: extension
 List of IP ネットワークマルチパス
interfaces on each node
 Res property type: stringarray
 Res property value: sc_ipmp0@1 sc_ipmp0@3
 
(Only nodes 1 and 3 have been assigned IP ネットワークマルチパス groups. 
You must add an IP ネットワークマルチパス group for node 2.)

# clresource set  -p netiflist=sc_ipmp0@1,sc_ipmp0@2,sc_ipmp0@3 schost-2
# metaset -s red -a -h phys-schost-2
# clresourcegroup set -n  phys-schost-1,phys-schost-2,phys-schost-3 resource-group-1
# clresourcegroup show -v resource-group-1 | grep -i nodelist
 Nodelist:     phys-schost-1 phys-schost-2
               phys-schost-3
# clresourcegroup show -v resource-group-1 | grep -i netiflist
 Res property value: sc_ipmp0@1 sc_ipmp0@2
                     sc_ipmp0@3

リソースグループからノードを削除する

ノードまたはゾーンをリソースグループから削除する手順は、リソースグループがスケーラブルリソースグループであるか、またはフェイルオーバーリソースグループであるかによって異なります。詳細の手順については、以下の節を参照してください。

この手順を実行するには、次の情報が必要になります。

さらに、削除するノードまたはゾーン上でリソースグループがマスターされていないことを確認してください。削除するノードまたはゾーン上でマスターされている場合は、clresourcegroup コマンドを実行し、そのノードまたはゾーンでリソースグループをオフラインに切り替えてください。次の clresourcegroup コマンドは、指定されたノードまたはゾーンからリソースグループをオフラインにします。この場合、new‐masters にこのノードまたはゾーンが含まれていてはなりません。


# clresourcegroup switch -n new-masters resource-group
-n new-masters

このリソースグループを現在マスターできるノードまたはゾーンを指定します。

resource-group

切り替えるリソースグループの名前を指定します。このリソースグループは、削除するノードまたはゾーン上でマスターされます。

詳細は、clresourcegroup(1CL) のマニュアルページを参照してください。

注意 – 注意 –

すべてのリソースグループからノードまたはゾーンを削除する場合で、スケーラブルサービス構成を使用するときは、最初にスケーラブルリソースグループからそのノードまたはゾーンを削除してください。続いて、フェイルオーバーグループからそのノードまたはゾーンを削除してください。

Procedureスケーラブルリソースグループからノードを削除する

スケーラブルサービスは、次に示すように 2 つのリソースグループとして構成されます。

スケーラブルリソースグループの RG_dependencies プロパティーは、フェイルオーバーリソースグループへの依存性を使用してスケーラブルグループを構成するように設定されます。このプロパティーの詳細については、付録 B 「標準プロパティー」を参照してください。

スケーラブルサービス構成の詳細は、『Sun Cluster の概念 (Solaris OS 版)』を参照してください。

スケーラブルリソースグループからノードまたはゾーンを削除すると、そのスケーラブルサービスはそのノードまたはゾーン上でオンラインにすることができなくなります。スケーラブルリソースグループからノードまたはゾーンを削除するには、以下の作業を行なってください。

  1. スケーラブルリソースグループをマスターできるノードまたはゾーンのリスト (nodelist リソースグループプロパティー) からノードまたはゾーンを削除します。


    # clresourcegroup set [-n node-zone-list] scalable-resource-group
    -n node-zone-list

    このリソースグループをマスターできるゾーンの、コンマ区切りの順序付けされたリストを指定します。このリソースグループは、このノード以外のすべてのノードでオフラインに切り替えられます。リスト内の各エントリの形式は node:zone です。この形式では、 node はノード名を指定し、zone は非大域 Solaris ゾーンの名前を指定します。大域ゾーンを指定する、または非大域ゾーンを持たないノードを指定するには、node のみを指定します。

    このリストはオプションです。このリストを省略すると、Nodelist プロパティーがクラスタ内のすべてのノードに対して設定されます。

    scalable-resource-group

    ノードまたはゾーンが削除されるリソースグループの名前を指定します。

  2. (省略可能) 共有アドレスリソースが入ったフェイルオーバーリソースグループからノードまたはゾーンを削除します。

    詳細については、「共有アドレスリソースを含むフェイルオーバーリソースグループからノードを削除する」を参照してください。

  3. (省略可能) スケーラブルリソースの Load_balancing_weights プロパティーを更新し、リソースグループから削除するノードまたはゾーンのウエイトを削除します。

参照

clresourcegroup(1CL) のマニュアルページ。

Procedureフェイルオーバーリソースグループからノードを削除する

フェイルオーバーリソースグループからノードまたはゾーンを削除するには、以下の作業を行なってください。

注意 – 注意 –

すべてのリソースグループからノードまたはゾーンを削除する場合で、スケーラブルサービス構成を使用するときは、最初にスケーラブルリソースグループからそのノードまたはゾーンを削除してください。続いて、この方法を使用してフェイルオーバーグループからノードまたはゾーンを削除してください。

注 –

フェイルオーバーリソースグループに、スケーラブルサービスが使用する共有アドレスリソースが含まれる場合は、「共有アドレスリソースを含むフェイルオーバーリソースグループからノードを削除する」を参照してください。

  1. このリソースグループをマスターできるすべてのノードを含めるように、ノードリストを更新します。

    この手順はノードまたはゾーンを削除してノードリストの値を上書きするため、リソースグループをマスターできるすべてのノードまたはゾーンをここに含める必要があります。


    # clresourcegroup set [-n node-zone-list] failover-resource-group
    -n node-zone-list

    このリソースグループをマスターできるゾーンの、コンマ区切りの順序付けされたリストを指定します。このリソースグループは、このノード以外のすべてのノードでオフラインに切り替えられます。リスト内の各エントリの形式は node:zone です。この形式では、 node はノード名を指定し、zone は非大域 Solaris ゾーンの名前を指定します。大域ゾーンを指定する、または非大域ゾーンを持たないノードを指定するには、node のみを指定します。

    このリストはオプションです。このリストを省略すると、Nodelist プロパティーがクラスタ内のすべてのノードに対して設定されます。

    failover-resource-group

    ノードまたはゾーンが削除されるリソースグループの名前を指定します。

  2. リソースグループ内の各リソース用に構成した IP ネットワークマルチパスグループの現在のリストを表示します。


    # clresourcegroup show -v failover-resource-group | grep -i netiflist

  3. ノードまたはゾーンの削除によって影響を受けるネットワークリソースの netiflist を更新します。

    この手順は netiflist の値を上書きするため、すべての IP ネットワークマルチパスグループをここに含める必要があります。


    # clresource set -p netiflist=netiflist network-resource
    注 –

    上記コマンド行の出力は、ノード 名によってノードを識別します。ノード ID を識別するには、コマンド clnode show -v | grep -i "Node ID" を実行してください。

    -p netiflist=netiflist

    各ノード上の IP ネットワークマルチパスグループをコンマで区切って指定します。netiflist の各要素は、netif@node の形式にする必要があります。netif は IP ネットワークマルチパス グループ名 (sc_ipmp0 など) として指定できます。ノードは、ノード名またはノード ID (sc_ipmp0@1、sc_ipmp@phys-schost-1 など) で識別できます。

    network-resource

    netiflist エントリ上でホストされているネットワークリソースの名前を指定します。

    注 –

    Sun Cluster では、 netif にアダプタ名を使用できません。

  4. 更新された情報を確認します。


    # clresourcegroup show -vfailover-resource-group | grep -i nodelist
# clresourcegroup show -vfailover-resource-group | grep -i netiflist

Procedure共有アドレスリソースを含むフェイルオーバーリソースグループからノードを削除する

スケーラブルサービスが使用する共有アドレスリソースを含むフェイルオーバーリソースグループでは、ノードまたはゾーンは次の場所に現れます。

フェイルオーバーリソースグループのノードリストからノードまたはゾーンを削除するには、「フェイルオーバーリソースグループからノードを削除する」に示されている作業を行なってください。

共有アドレスリソースの auxnodelist を変更するには、共有アドレスリソースを削除して作成し直す必要があります。

フェイルオーバーグループのノードリストからノードまたはゾーンを削除すると、そのノードまたはゾーン上の共有アドレスリソースを継続して使用し、スケーラブルサービスを提供できます。共有アドレスリソースを継続して使用するには、共有アドレスリソースの auxnodelist にそのノードまたはゾーンを追加する必要があります。auxnodelist にノードまたはゾーンを追加するには、以下の作業を行なってください。

注 –

以下の作業は、共有アドレスリソースの auxnodelist からノードまたはゾーンを削除するためにも使用できます。auxnodelist からノードまたはゾーンを削除するには、共有アドレスリソースを削除して作成し直す必要があります。

  1. スケーラブルサービスリソースをオフラインに切り替えます。

  2. フェイルオーバーリソースグループから共有アドレスリソースを削除します。

  3. 共有アドレスリソースを作成します。

    フェイルオーバーリソースグループから削除したノードのノード ID またはノード名、あるいはゾーンのゾーン名を auxnodelist に追加します。


    # clressharedaddress create -g failover-resource-group \
 -X new-auxnodelist shared-address
    failover-resource-group

    共有アドレスリソースを含めるために使用されたフェイルオーバーリソースグループの名前

    new-auxnodelist

    妥当なノードまたはゾーンの追加または削除によって変更された新しい auxnodelist

    shared-address

    共有アドレスの名前

例 – リソースグループからのノードの削除

次に、リソースグループ (resource-group-1) からノード (phys-schost-3) を削除する例を示します。このリソースグループは、論理ホスト名リソース (schost-1) を含んでいます。


# clresourcegroup show -v resource-group-1 | grep -i nodelist
Nodelist:       phys-schost-1 phys-schost-2
                                             phys-schost-3
# clresourcegroup set -n phys-schost-1,phys-schost-2 resource-group-1
# clresourcegroup show -v resource-group-1 | grep -i netiflist
( Res property name: NetIfList
Res property class: extension
( List of IP ネットワークマルチパス 
interfaces on each node
( Res property type: stringarray
 Res property value: sc_ipmp0@1 sc_ipmp0@2
                     sc_ipmp0@3

(sc_ipmp0@3 is the IP ネットワークマルチパス group to be removed.)

# clresource set  -p  netiflist=sc_ipmp0@1,sc_ipmp0@2 schost-1
# clresourcegroup show -v resource-group-1 | grep -i nodelist
Nodelist:       phys-schost-1 phys-schost-2
# clresourcegroup show -v resource-group-1 | grep -i netiflist
 Res property value: sc_ipmp0@1 sc_ipmp0@2

大域ゾーンから非大域ゾーンへのアプリケーションの移行

アプリケーションリソースを大域ゾーンから非大域ゾーンに移行することができます。

注 –

移行するデータサービスはスケーラブルであり、また非大域ゾーンでサポートされる必要があります。

Procedure大域ゾーンから非大域ゾーンへアプリケーションを移行する

この手順では、3 つの各ノード上に作成された非大域ゾーンを持つ 3 つのノードクラスタがあると仮定しています。HAStoragePlus リソースを使用することで高可用性を実現している構成ディレクトリも、非大域ゾーンからアクセス可能であるべきです。

  1. スケーラブルリソースが使用する共有アドレスを保持する大域ゾーンを使用してフェイルオーバーリソースグループを作成します。


    # clresourcegroup create -n node1,node2,node3 sa-resource-group
    sa-resource-group

    追加するフェイルオーバーリソースグループの名前を指定します。任意の名前の先頭文字は ASCII にする必要があります。

  2. 共有アドレスリソースをフェイルオーバーリソースグループに追加します。


    # clressharedaddress create -g sa-resource-group -h hostnamelist, … \
[-X auxnodelist] -N netiflist network-resource
    -g sa-resource-group

    リソースグループの名前を指定します。共有アドレスリソースのノードリストでは、同一ノード上では複数のゾーンを指定しないでください。共有アドレスリソースのノードリストは、同一ノード上で異なるゾーンを指定してはいけません。nodename:zonename のペアの同一リストをスケーラブルリソースグループのノードリストとして指定します。

    -h hostnamelist, …

    共有アドレスホスト名をコンマで区切って指定します。

    -X auxnodelist

    共有アドレスをホストできるクラスタノード (ただし、フェイルオーバー時に主ノードとして使用されない) を識別する物理ノード名または ID またはゾーンをコンマで区切って指定します。これらのノードは、リソースグループのノードリストで潜在的マスターとして識別されるノードと相互に排他的です。補助ノードリストが明示的に指定されていない場合、リストのデフォルトは、共有アドレスリソースを含むリソースグループのノードリストには含まれていない、すべてのクラスタノード名のリストになります。

    注 –

    サービスをマスターするために作成されたすべての非大域ゾーン内でスケーラブルサービスを動作させるには、共有アドレスリソースグループのノードリスト、または共有アドレスリソースの auxnodelist にゾーンの完全なリストを含めます。すべてのゾーンがノードリスト内にある場合は、auxnodelist を省略できます。

    -N netiflist

    各ノード上の IP ネットワークマルチパス グループをコンマで区切って指定します (省略可能)。netiflist の各要素は、netif@node の形式にする必要があります。netif は IP ネットワークマルチパス グループ名 (sc_ipmp0 など) として指定できます。ノードは、ノード名またはノード ID (sc_ipmp0@1、sc_ipmp@phys-schost-1 など) で識別できます。

    注 –

    Sun Cluster では、 netif にアダプタ名を使用できません。

    network-resource

    リソース名を指定します (省略可能)。

  3. スケーラブルリソースグループを作成します。


    # clresourcegroup create\-p Maximum_primaries=m\-p Desired_primaries=n\
-n node1,node2,node3\
-p RG_dependencies=sa-resource-group resource-group-1
    -p Maximum_primaries=m

    このリソースグループのアクティブな主ノードの最大数を指定します。

    -p Desired_primaries=n

    リソースグループが起動するアクティブな主ノードの数を指定します。

    resource-group-1

    追加するスケーラブルリソースグループの名前を指定します。任意の名前の先頭文字は ASCII にする必要があります。

  4. HAStoragePlus のリソース hastorageplus-1 を作成し、ファイルシステムのマウントポイントを定義します。


    # clresource create -g resource-group-1 -t SUNW.HAStoragePlus \
-p FilesystemMountPoints=/global/resource-group-1 hastorageplus-1

    リソースは有効状態で作成されます。

  5. アプリケーションのリソースタイプを登録します。


    # clresourcetype register resource-type
    resource-type

    追加するリソースタイプの名前を指定します。指定する事前定義済みの名前を判別するには、Sun Cluster のリリースノートを参照してください。

  6. アプリケーションリソースを resource-group-1 に追加し、依存関係を hastorageplus-1 に設定します。


    # clresource create -g resource-group-1 -t SUNW.application \
[-p "extension-property[{node-specifier}]"=value, …] -p Scalable=True \
-p Resource_dependencies=network-resource -p Port_list=port-number/protocol \
-p Resource_dependencies=hastorageplus-1 resource

  7. フェイルオーバーリソースグループをオンラインにします。


    # clresourcegroup online sa-resource-group

  8. すべてのノード上でスケーラブルリソースグループをオンラインにします。


    # clresourcegroup online resource-group-1

  9. 各ノード上 (node1,node2,node3) で zone1 をインストールし、起動します。

  10. 2 つのノード (node1, node2) 上でアプリケーションリソースグループをオフラインにします。

    注 –

    共有アドレスを node3 上でオンラインにします。


    # clresourcegroup switch -n node3 resource-group-1
    resource-group-1

    切り替えるリソースグループの名前を指定します。

  11. フェイルオーバーリソースグループの nodelist プロパティーを更新し、ノードリストから削除された対応するノードの非大域ゾーンを含めます。


    # clresourcegroup set -n node1:zone1,node2:zone1,node3 sa-resource-group

  12. アプリケーションリソースグループの nodelist プロパティーを更新し、ノードリストから削除された対応するノードの非大域ゾーンを含めます。


    # clresourcegroup set node1:zone1,node2:zone1,node3 resource-group-1

  13. 新しく追加されたゾーンでのみ、フェイルオーバーリソースグループとアプリケーションリソースグループをオンラインにします。

    注 –

    両方のリソースグループは、node1:zone1 および node2:zone1 のみでオンラインになります。


    # clresourcegroup switch -n node1:zone1,node2:zone1 sa-resource-group


    # clresourcegroup switch -n node1:zone1,node2:zone1 resource-group-1

  14. 広域ノード node3 をリストから削除することで、両方のリソースグループの nodelist プロパティーを更新し、node3 の非大域ゾーンを含めます。


    # clresourcegroup set node1:zone1,node2:zone1,node3:zone1 sa-resource-group


    # clresourcegroup set node1:zone1,node2:zone1,node3:zone1 resource-group-1

  15. すべての非大域ゾーン上で両方のリソースグループをオンラインにします。


    # clresourcegroup switch -n node1:zone1,node2:zone1,node3:zone1 sa-resource-group


    # clresourcegroup switch -n node1:zone1,node2:zone1,node3:zone1 resource-group-1

リソースグループとデバイスグループ間での起動の同期

クラスタが起動したあと、あるいは、サービスが別のノードにフェイルオーバーしたあと、広域デバイスとローカルおよびクラスタファイルシステムが利用できるようになるまでには、しばらく時間がかかることがあります。ただし、データサービスは、広域デバイスとローカルおよびクラスタファイルシステムがオンラインになる前に、START メソッドを実行できます。データサービスが、まだオンラインになっていない広域デバイスまたはローカルおよびクラスタファイルシステムに依存する場合、START メソッドはタイムアウトします。この場合、データサービスが使用するリソースグループの状態をリセットし、手動でデータサービスを再起動する必要があります。

このような余分な管理作業を回避するため、HAStoragePlus リソースタイプを使用します。広域デバイスやローカルおよびクラスタファイルシステムに依存するデータサービスリソースを持つすべてのリソースグループに、HAStoragePlus のインスタンスを追加します。このようなリソースタイプのインスタンスは、次の操作を実行します。

HAStoragePlus リソースを作成するには、「新しいリソース用に HAStoragePlus リソースタイプを設定する」を参照してください。

Procedure新しいリソース用に HAStoragePlus リソースタイプを設定する

次の例では、リソースグループ resource-group-1 は、次のデータサービスを含んでいます。

注 –

Solaris ZFS (Zettabyte File System) を使用して HAStoragePlus リソースを高可用性ローカルファイルシステムとして作成するには、「HAStoragePlus リソースタイプを設定し、ローカル Solaris ZFS を高可用性にする」の節を参照してください。

新しいリソースに対し、HAStoragePlus リソースの hastorageplus-1 を resource-group-1 に作成するには、「リソースグループとデバイスグループ間での起動の同期」を読み、その後次の手順を実行します。

HAStoragePlus リソースを作成するには、「高可用性ローカルファイルシステムの有効化」を参照してください。

  1. クラスタメンバーで、スーパーユーザーになるか、solaris.cluster.modify および solaris.cluster.admin RBAC の承認を提供する役割になります。

  2. リソースグループ resource-group-1 を作成します。


    # clresourcegroup create resource-group-1

  3. リソースタイプが登録されているかどうかを調べます。

    次のコマンドは、登録されているリソースタイプのリストを出力します。


    # clresourcetype show | egrep Type

  4. 必要であれば、リソースタイプを登録します。


    # clresourcetype register SUNW.HAStoragePlus

  5. HAStoragePlus のリソース hastorageplus-1 を作成し、ファイルシステムのマウントポイントと広域デバイスパスを定義します。


    # clresource create -g resource-group-1 -t SUNW.HAStoragePlus \
-p GlobalDevicePaths=/dev/global/dsk/d5s2,dsk/d6 \
-p FilesystemMountPoints=/global/resource-group-1 hastorageplus-1

    GlobalDevicePaths は、次の値を含むことができます。

    • 広域デバイスグループ名 (例:nfs-dg、dsk/d5)

    • 広域デバイスへのパス (例: /dev/global/dsk/d1s2、 /dev/md/nfsdg/dsk/d10)

    FilesystemMountPoints は、次の値を含むことができます。

    • ローカルまたはクラスタファイルシステムのマウントポイント (例: /local-fs/nfs、/global/nfs)

    注 –

    HAStoragePlus は、ZFS ストレージプールの構成に使用する Zpools 拡張プロパティーと、ZFS ストレージプールのデバイス検索の指定に使う、ZpoolsSearchDir 拡張プロパティーを持っています。ZpoolsSearchDir 拡張プロパティーのデフォルト値は、/dev/dsk です。ZpoolsSearchDir 拡張プロパ ティーは、zpool(1M) コマンドの -d オプションの指定と似ています。

    リソースは有効状態で作成されます。

  6. リソース Sun Java System Web Server、Oracle、NFS を resource-group-1 に追加し、これらの依存性を hastorageplus-1 に設定します。

    たとえば、Sun Java System Web Server の場合、次のコマンドを実行します。


    # clresource create  -g resource-group-1 -t SUNW.iws \
-p Confdir_list=/global/iws/schost-1 -p Scalable=False \
-p Network_resources_used=schost-1 -p Port_list=80/tcp \
-p Resource_dependencies=hastorageplus-1 resource

    リソースは有効状態で作成されます。

  7. リソースの依存性を正しく構成したかを確認します。


    # clresource show -v resource | egrep Resource_dependencies

  8. resource-group-1 を MANAGED 状態に設定し、オンラインにします。


    # clresourcegroup online -M resource-group-1
アフィニティースイッチオーバー

HAStoragePlus リソースタイプには別の拡張プロパティーである AffinityOn が含まれます。これは、GLobalDevicePaths および FileSystemMountPoints 拡張プロパティーで定義されている広域デバイスのアフィニティースイッチオーバーを HAStoragePlus が実行する必要があるかどうかを指定するブール値です。詳細は、SUNW.HAStoragePlus(5) のマニュアルページを参照してください。

注 –

スケーラブルサービスの場合、AffinityOn フラグの設定は無視されます。スケーラブルリソースグループでアフィニティースイッチオーバーを実行することはできません。

Procedure既存のリソース用に HAStoragePlus リソースタイプを設定する

始める前に

「リソースグループとデバイスグループ間での起動の同期」を読んでください。

  1. リソースタイプが登録されているかどうかを調べます。

    次のコマンドは、登録されているリソースタイプのリストを出力します。


    # clresourcetype show | egrep Type

  2. 必要であれば、リソースタイプを登録します。


    # clresourcetype register SUNW.HAStoragePlus

  3. HAStoragePlus のリソース hastorageplus-1 を作成します。


    # clresource create -g resource-group \
-t SUNW.HAStoragePlus -p GlobalDevicePaths= … \
-p FileSystemMountPoints=... -p AffinityOn=True hastorageplus-1

    リソースは有効状態で作成されます。

  4. 必要に応じて既存の各リソースについて依存性を設定します。


    # clresource set -p Resource_Dependencies=hastorageplus-1 resource

  5. リソースの依存性を正しく構成したかを確認します。


    # clresource show -v resource | egrep Resource_dependencies

クラスタファイルシステム用の HAStoragePlus リソースの構成

HAStoragePlus リソースがクラスタファイルシステム用に構成され、オンラインになると、これらのファイルシステムは使用可能になります。クラスタファイルシステムは UFS (Unix File System) と VxFS (Veritas File System) でサポートされています。データサービスの入出力負荷が高い場合は、HAStoragePlus とローカルファイルシステムを併用します。HAStoragePlus リソースのファイルシステムを変更する方法については、「HAStoragePlus リソースの広域ファイルシステムをローカルファイルシステムに変更する」を参照してください。

クラスタファイルシステム用の /etc/vfstab のサンプルエントリ

次の例に、クラスタファイルシステムに使用される広域デバイスの /etc/vfstab ファイルにあるエントリを示します。

注 –

クラスタファイルシステム用の /etc/vfstab ファイルのエントリには、マウントオプションに global キーワードが含まれているべきです。

例 2–30 Solaris ボリュームマネージャー を使用する広域デバイスの /etc/vfstab にあるエントリ

この例では、Solaris ボリュームマネージャー を使用する広域デバイス用の /etc/vfstab ファイルにあるエントリを示します。

/dev/md/kappa-1/dsk/d0   /dev/md/kappa-1/rdsk/d0
/global/local-fs/nfs ufs     5  yes     logging,global
例 2–31 VxVM を使用する広域デバイス用の /etc/vfstab にあるエントリ

この例では、VxVM を使用する広域デバイス用の /etc/vfstab ファイルにあるエントリを示します。

/dev/vx/dsk/kappa-1/appvol    /dev/vx/rdsk/kappa-1/appvol
/global/local-fs/nfs vxfs     5 yes     log,global

Procedureクラスタファイルシステム用に HAStoragePlus リソースを設定する

  1. クラスタ内の任意のノードで、スーパーユーザーになるか、solaris.cluster.modify RBAC の承認を提供する役割になります。

  2. フェイルオーバーリソースグループを作成します。


    # clresourcegroup create resource-group-1

  3. HAStoragePlus リソースタイプを登録します。


    # clresourcetype register SUNW.HAStoragePlus

  4. HAStoragePlus リソースを作成し、ファイルシステムのマウントポイントを定義します。


    # clresource create -g resource-group -t SUNW.HAStoragePlus \
 -p FileSystemMountPoints="mount-point-list" hasp-resource

    リソースは有効状態で作成されます。

  5. resource-group-1 にデータサービスリソースを追加し、hasp-resource 対する依存関係を設定します。

  6. HAStoragePlus リソースを含むリソースグループをオンラインにし、管理状態にします。


    # clresourcegroup online -M resource-group-1

Procedureクラスタファイルシステム用の HAStoragePlus リソースタイプを削除する

    クラスタファイルシステム用に構成された HAStoragePlus リソースを無効にし、削除します。


    # clresource delete -F -g resource-group -t SUNW.HAStoragePlus resource

高可用性ローカルファイルシステムの有効化

高可用性ローカルファイルシステムを使用すると、出入力負荷が高いデータサービスのパフォーマンスを改善できます。Sun Cluster 環境でローカルファイルシステムを高可用性にするには、HAStoragePlus リソースタイプを使用します。

グローバルまたはローカルのどちらのファイルシステムも指定できます。グローバルファイルシステムには、クラスタのすべてのノードまたはゾーンからアクセス可能です。ローカルファイルシステムには、1 つのクラスタノードまたはゾーンからアクセス可能です。SUNW.HAStoragePlus リソースによって管理されているローカルファイルシステムは、1 つのクラスタノードまたはゾーンにマウントされます。これらのローカルファイルシステムでは、配下のデバイスは Sun Cluster グローバルデバイスであることが必要です。

これらのファイルシステムのマウントポイントは、paths[,...] という書式で定義されます。非大域ゾーンのパスと大域ゾーンのパスの両方を次の書式で指定できます。

Non-GlobalZonePath:GlobalZonePath

大域ゾーンのパスは省略可能です。大域ゾーンパスを指定しない場合、Sun Cluster は非大域ゾーンのパスと大域ゾーンのパスが同じであることを前提とします。Non-GlobalZonePath:GlobalZonePath のようにパスを指定する場合、大域ゾーンの /etc/vfstab にある GlobalZonePath を指定してください。

このプロパティーのデフォルト設定は、空のリストです。

SUNW.HAStoragePlus リソースタイプを使用すると、ファイルシステムを非大域ゾーンで利用可能にすることができます。 SUNW.HAStoragePlus リソースタイプを使用してこのようにするには、大域ゾーンと非大域ゾーンにマウントポイントを作成してください。ファイルシステムを非大域ゾーンで利用可能にするために、SUNW.HAStoragePlus リソースタイプは、まず大域ゾーンにあるファイルシステムをマウントします。このリソースタイプは、次に非大域ゾーンでループバックマウントを実行します。すべてのクラスタノードおよびすべての大域ゾーンにある /etc/vfstab には、各ファイルシステムのマウントポイントに対応する等価なエントリが存在するはずです。 SUNW.HAStoragePlus リソースタイプは、非大域ゾーンにある /etc/vfstab をチェックしません。

注 –

ローカルファイルシステムには、Unix File System (UFS)、Quick File System (QFS)、Veritas File System (VxFS)、Solaris ZFS (Zettabyte File System) などがあります。

出入力負荷が高い各 Sun Cluster データサービスの作業手順では、データサービスを構成して HAStoragePlus リソースタイプとともに動作させる方法が説明されています。詳細については、個別の Sun Cluster データサービスのガイドを参照してください。

注 –

HAStoragePlus リソースタイプを使用してルートファイルシステムを高可用性にしないでください。

Sun Cluster には、HAStoragePlus リソースタイプを設定してローカルファイルシステムを高可用性にするための、次のツールがあります。

Sun Cluster Manager および clsetup ユーティリティーを使用すると、対話形式でリソースをリソースグループに追加できます。これらのリソースを対話的に使うことにより、コマンドの構文エラーまたは脱落による設定エラーが起きる可能性が少なくなります。Sun Cluster Manager および clsetup ユーティリティーは、すべての必須リソースが作成され、リソース間のすべての必須依存関係が設定されるようにします。

高可用性ローカルファイルシステムの構成要件

多重ホストディスク上のすべてのファイルシステムは、これらの多重ホストディスクに直接接続されたすべてのホストからアクセス可能である必要があります。この要件を満たすには、次のように、高可用性ローカルファイルシステムを構成します。

注 –

高可用性ローカルファイルシステム用の広域デバイスと、ボリュームマネージャーの併用は、任意に選択できます。

ボリュームマネージャーを使用しないデバイスのデバイス名の形式

ボリュームマネージャーを使用しない場合、基本のストレージデバイスの名前には適切な形式を使用します。使用する形式は、次のように、ストレージデバイスの種類に依存します。

これらのデバイス名の置換可能な要素の意味は次のとおりです。

高可用性ローカルファイルシステムの /etc/vfstab のサンプルエントリ

次の例に、高可用性ローカルファイルシステムに使用される広域デバイスの /etc/vfstab ファイルにあるエントリを示します。

注 –

Solaris ZFS (Zettabyte File System) は、/etc/vfstab ファイルを使用しません。

例 2–32 ボリュームマネージャーのない広域デバイスの /etc/vfstab にあるエントリ

この例に、ボリュームマネージャーを使用しない物理ディスク上の広域デバイス用の /etc/vfstab ファイルにあるエントリを示します。

/dev/global/dsk/d1s0       /dev/global/rdsk/d1s0
/global/local-fs/nfs  ufs     5  no     logging
例 2–33 Solaris ボリュームマネージャー を使用する広域デバイスの /etc/vfstab にあるエントリ

この例では、Solaris ボリュームマネージャー を使用する広域デバイス用の /etc/vfstab ファイルにあるエントリを示します。

/dev/md/kappa-1/dsk/d0   /dev/md/kappa-1/rdsk/d0
/global/local-fs/nfs ufs     5  no     logging
例 2–34 VxVM を使用する広域デバイス用の /etc/vfstab にあるエントリ

この例では、VxVM を使用する広域デバイス用の /etc/vfstab ファイルにあるエントリを示します。

/dev/vx/dsk/kappa-1/appvol    /dev/vx/rdsk/kappa-1/appvol
/global/local-fs/nfs vxfs     5 no     log

Procedureclsetup ユーティリティーを使用することで HAStoragePlus リソースタイプを設定する

次の手順では、clsetup ユーティリティーを使用することで HAStoragePlus リソースタイプを設定する方法を説明します。この手順は、任意のクラスタノードから実行します。

この手順では、Sun Cluster の保守コマンドの長い形式を使用します。多くのコマンドには短縮形もあります。コマンド名の形式を除き、コマンドは同じです。コマンドのリストとその短縮形については、 付録 A 「Sun Cluster オブジェクト指向コマンド」を参照してください。

始める前に

次の前提条件を満たしていることを確認します。

  1. 任意のクラスタノードでスーパーユーザーになります。

  2. clsetup ユーティリティーを起動します。


    # clsetup

    clsetup のメインメニューが表示されます。

  3. データサービスのオプションに対応する番号を入力し、Return キーを押します。

    「データサービス」メニューが表示されます。

  4. ファイルシステムを構成するためのオプションに対応する番号を入力し、Return キーを押します。

    clsetup ユーティリティーは、この作業を実行するための前提条件のリストを表示します。

  5. 前提条件が満たされていることを確認し、Return キーを押して継続します。

    clsetup ユーティリティーは、高可用性 HAStoragePlus リソースをマスターできるクラスタノードまたはゾーンのリストを表示します。

  6. 高可用性 HAStoragePlus リソースをマスターできるノードまたはゾーンを選択します。

    • 任意の順序で並んでいる一覧表示されたすべてのノードのデフォルト選択をそのまま使用するには、a と入力し、Return キーを押します。

    • 一覧表示されたノードまたはゾーンのサブセットを選択するには、ノードに対応する番号のコンマ区切りまたはスペース区切りのリストを入力します。続いて、Return キーを押します。

      HAStoragePlus リソースグループのノードリストにノードが表示される順序でノードが一覧表示されていることを確認します。リストの最初のノードは、このリソースグループの主ノードです。

    • 特定の順序ですべてのノードを選択するには、ノードに対応する番号のコンマ区切りまたはスペース区切りの順序付きリストを入力し、Return キーを押します。

  7. ノードの選択を確認するには、d を入力して、Return キーを押します。

    clsetup ユーティリティーは、データが格納される共有ストレージタイプの種類のリストを表示します。

  8. データの格納に使用する共有ストレージの種類に対応する番号を入力し、Return キーを押します。

    clsetup ユーティリティーは、クラスタ内で構成されているファイルシステムのマウントポイントを表示します。既存のマウントポイントが存在しない場合は、clsetup ユーティリティーで新しいマウントポイントを定義できます。

  9. デフォルトのマウントディレクトリ、raw デバイスのパス、Global Mount オプション、および Check File System Periodically オプションを指定して、Return キーを押します。

    clsetup ユーティリティーは、ユーティリティーが作成するマウントポイントのプロパティーを返します。

  10. マウントポイントを作成するには、d を入力し、Return キーを押します。

    clsetup ユーティリティーは、使用可能なファイルシステムのマウントポイントを表示します。

    注 –

    c オプションを使用すると、新しい別のマウントポイントを定義できます。

  11. ファイルシステムのマウントポイントを選択します。

    • 任意の順序で並んでいる一覧表示されたすべてのファイルシステムのマウントポイントのデフォルト選択をそのまま使用するには、a と入力し、Return キーを押します。

    • 一覧表示されたファイルシステムのマウントポイントのサブセットを選択するには、ファイルシステムのマウントポイントに対応する番号の、コンマまたはスペースで区切られたリストを入力し、Return キーを押します。

  12. ノードの選択を確認するには、d を入力して、Return キーを押します。

    clsetup ユーティリティーは、クラスタ内で構成されている広域ディスクセットとデバイスグループを表示します。

  13. 広域デバイスグループを選択します。

    • 任意の順序で並んでいる一覧表示されたすべてのデバイスグループのデフォルト選択をそのまま使用するには、a と入力し、Return キーを押します。

    • 一覧表示されたデバイスグループのサブセットを選択するには、デバイスグループに対応する番号の、コンマまたはスペースで区切られたリストを入力し、Return キーを押します。

  14. ノードの選択を確認するには、d を入力して、Return キーを押します。

    clsetup ユーティリティーは、このユーティリティーが作成する Sun Cluster オブジェクトの名前を表示します。

  15. Sun Cluster オブジェクトに別の名前が必要である場合、次のように名前を変更します。

    1. 変更する名前に対応する番号を入力し、Return キーを押します。

      clsetup ユーティリティーは、新しい名前を指定できる画面を表示します。

    2. 「新しい値」プロンプトで、新しい名前を入力し、Return キーを押します。

    clsetup ユーティリティーは、このユーティリティーが作成する Sun Cluster オブジェクトの名前のリストに戻ります。

  16. Sun Cluster オブジェクト名の選択を確認するには、d を入力して、Return キーを押します。

    clsetup ユーティリティーは、このユーティリティーが作成する Sun Cluster の構成に関する情報を表示します。

  17. 構成を作成するには、c を入力し、Return キーを押します。

    clsetup ユーティリティーは、構成を作成するためにこのユーティリティーがコマンドを実行していることを示す進行状況のメッセージを表示します。構成が完了した時点で、clsetup ユーティリティーは、構成を作成するためにユーティリティーが実行したコマンドを表示します。

  18. (省略可能) clsetup ユーティリティーが終了するまで、繰り返し q を入力し、Return キーを押します。

    必要に応じて、ほかの必要な作業を実行している間、clsetup ユーティリティーを動作させたままにし、そのあとでユーティリティーを再度使用することができます。clsetup を終了する場合、ユーザーがユーティリティーを再起動する際に、ユーティリティーは既存のリソースグループを認識します。

  19. HAStoragePlus リソースが作成されたことを確認します。

    このためには、clresource(1CL) ユーティリティーを使用します。デフォルトでは、clsetup ユーティリティーは、リソースグループに名前 node_name-rg を割り当てます。


    # clresource show node_name-rg

ProcedureHAStoragePlus リソースタイプを設定し、ローカル Solaris ZFS を高可用性にする

ローカル Solaris ZFS (Zettabyte File System) を高可用性にするには、主に次の作業を実行します。

この節では両方の作業を完了する方法を説明します。

  1. ZFS ストレージプールを作成する。

    注意 – 注意 –

    構成済みの定足数デバイスは、 ZFS ストレージプールに追加しないでください。構成済みの定足数デバイスをストレージプールに追加すると、ディスクは EFI ディスクとしてラベルが変更され、また定足数構成情報が失われ、ディスクはクラスタへの定足数投票を提供しなくなります。ディスクがストレージプールにある場合、そのディスクを定足数デバイスとして構成できます。または、ディスクの定足数デバイス構成を解除し、ディスクをストレージプールに追加した後に、そのディスクを定足数デバイスとして再構成することができます。

    Sun Cluster 構成で ZFS ストレージプールを作成する際には、次の必要条件を確認します。

    • ZFS ストレージプールの作成元であるすべてのデバイスが、クラスタ内のすべてのノードからアクセス可能であることを確認します。これらのノードは、HAStoragePlus リソースが属するリソースグループのノードリストで構成します。

    • zpool(1M) コマンドに対して指定した Solaris デバイス識別子 (/dev/dsk/c0t0d0 など) が cldevice list -v コマンドで認識できることを確認します。

    注 –

    ZFS ストレージプールは、ディスク全体またはディスクスライスを使用して作成できます。ディスクの書き込みキャッシュを有効にして ZFS の性能が向上するように Solaris 論理デバイスを指定し、ディスク全体を使用した ZFS ストレージプールを作成することをお勧めします。完全なディスクが提供されている場合、ZFS は EFI を使用してディスクにラベルを付けます。

    ZFS ストレージプールの作成方法の詳細は、「『Solaris ZFS Administration Guide』」の『「Creating a ZFS Storage Pool」』を参照してください。

  2. 作成した ZFS とストレージプール内で、ZFS を作成します。

    同一の ZFS ストレージプール内で複数の ZFS を作成できます。

    注 –

    HAStoragePlus は、ZFS ボリューム上に作成されたファイルシステムをサポートしていません。

    ZFS は FilesystemMountPoints 拡張プロパティーには配置しないでください。

    ZFS ストレージプール内での ZFS の作成方法の詳細は、『『Solaris ZFS Administration Guide』』の「「Creating a ZFS File System Hierarchy」」を参照してください。

  3. クラスタ内の任意のノードで、スーパーユーザーになるか、solaris.cluster.modify RBAC の承認を提供する役割になります。

  4. フェイルオーバーリソースグループを作成します。


    # clresourcegroup create resource-group

  5. HAStoragePlus リソースタイプを登録します。


    # clresourcetype register SUNW.HAStoragePlus

  6. ローカル ZFS 用の HAStoragePlus リソースを作成します。


    # clresource create -g resource-group -t SUNW.HAStoragePlus \
-p Zpools=zpool -p ZpoolsSearchDir=/dev/did/dsk \
resource

    ZFS ストレージプールのデバイスのデフォルトの検索場所は、/dev/dsk です。これは、ZpoolsSearchDir 拡張プロパティーを使用して上書きできます。

    リソースは有効状態で作成されます。

  7. HAStoragePlus リソースを含むリソースグループをオンラインにし、管理状態にします。


    # clresourcegroup online -M resource-group
例 2–35 HAStoragePlus リソースタイプを設定してローカル ZFS を高可用性にする

次の例では、ローカル ZFS を高可用性にするためのコマンドを示します。


phys-schost-1% su
Password: 
# cldevice list -v

DID Device          Full Device Path
----------          ----------------
d1                  phys-schost-1:/dev/rdsk/c0t0d0
d2                  phys-schost-1:/dev/rdsk/c0t1d0
d3                  phys-schost-1:/dev/rdsk/c1t8d0
d3                  phys-schost-2:/dev/rdsk/c1t8d0
d4                  phys-schost-1:/dev/rdsk/c1t9d0
d4                  phys-schost-2:/dev/rdsk/c1t9d0
d5                  phys-schost-1:/dev/rdsk/c1t10d0
d5                  phys-schost-2:/dev/rdsk/c1t10d0
d6                  phys-schost-1:/dev/rdsk/c1t11d0
d6                  phys-schost-2:/dev/rdsk/c1t11d0
d7                  phys-schost-2:/dev/rdsk/c0t0d0
d8                  phys-schost-2:/dev/rdsk/c0t1d0
you can create a ZFS storage pool using a disk slice by specifying a Solaris device 
identifier:
# zpool create HAzpool c1t8d0s2
or or you can create a ZFS storage pool using disk slice by specifying a logical device 
identifier
# zpool create HAzpool /dev/did/dsk/d3s2
# zfs create HAzpool/export
# zfs create HAzpool/export/home
# clresourcegroup create hasp-rg
# clresourcetype register SUNW.HAStoragePlus
# clresource create -g hasp-rg -t SUNW.HAStoragePlus \
                    -p Zpools=HAzpool hasp-rs
# clresourcegroup online -M hasp-rg

Procedureローカル Solaris ZFS を高可用性にしている HAStoragePlus リソースを削除する

    ローカルSolaris ZFS (Zettabyte File System) を高可用性にしている HAStoragePlus リソースを無効にし、削除します。


    # clresource delete -F -g resource-group -t SUNW.HAStoragePlus resource

HAStorage から HAStoragePlus へのアップグレード

HAStorage は、Sun Cluster ソフトウェアの現在のリリースではサポートされていません。同等の機能が HAStoragePlus でサポートされています。HAStorage から HAStorage へアップグレードするには、次の節を参照してください。

注 –

HAStorage がサポートされなくなったため、HAStorage リソースが構成されているリソースグループは STOP_FAILED 状態になります。リソースの ERROR_STOP_FAILED フラグを消去し、HAStorage を HAStoragePlus にアップグレードするための手順に従ってください。

Procedureデバイスグループまたは CFS を使用している場合に HAStorage から HAStoragePlus へアップグレードする

この例では、HAStorage で単純な HA-NFS リソースが有効になっています。ServicePaths はディスクグループ nfsdg で、AffinityOn プロパティーは True です。さらに、この HA-NFS リソースは Resource_Dependencies を HAStorage リソースに設定しています。

  1. リソースグループ nfs1-rg をオフラインにします。


    # clresourcegroup offline nfs1-rg

  2. HAStorage に対するアプリケーションリソースの依存性を除去します。


    # clresource set -p Resource_Dependencies="" nfsserver-rs

  3. HAStorage リソースを無効にします。


    # clresource disable nfs1storage-rs

  4. アプリケーションリソースグループから HAStorage リソースを削除します。


    # clresource delete nfs1storage-rs

  5. HAStorage リソースタイプの登録を解除します。


    # clresourcetype unregister SUNW.HAStorage

  6. HAStoragePlus リソースタイプを登録します。


    # clresourcetype register SUNW.HAStoragePlus

  7. HAStoragePlus リソースを作成します。

    注 –

    HAStorage の ServicePaths プロパティーを使用する代わりに、HAStoragePlus の FilesystemMountPoints プロパティーまたは GlobalDevicePaths プロパティーを使用する必要があります。

    • ファイルシステムのマウントポイントを指定するには、次のコマンドを入力します。

      FilesystemMountPoints 拡張プロパティーは、/etc/vfstab で指定されたシーケンスと一致する必要があります。


      # clresource create -g nfs1-rg -t \
SUNW.HAStoragePlus -p FilesystemMountPoints=/global/nfsdata -p \
AffinityOn=True nfs1-hastp-rs

    • グローバルデバイスパスを指定するには、次のコマンドを入力してください。


      # clresource create -g nfs1-rg -t \
SUNW.HAStoragePlus -p GlobalDevicePaths=nfsdg -p AffinityOn=True nfs1-hastp-rs

    リソースは有効状態で作成されます。

  8. アプリケーションサーバーリソースを無効にします。


    # clresource disable nfsserver-rs

  9. nfs1-rg グループをクラスタノード上でオンラインにします。


    # clresourcegroup online nfs1-rg

  10. アプリケーションサーバーとHAStoragePlus との間の依存性を設定します。


    # clresource set -p Resource_dependencies=nfs1-hastp-rs nfsserver-rs

  11. nfs1-rg グループをクラスタノード上でオンラインにします。


    # clresourcegroup online -eM nfs1-rg

ProcedureCFS による HAStorage から高可用性ローカルファイルシステムによる HAStoragePlus へアップグレードする

この例では、HAStorage で単純な HA-NFS リソースが有効になっています。ServicePaths はディスクグループ nfsdg で、AffinityOn プロパティーは True です。さらに、この HA-NFS リソースは Resource_Dependencies を HAStorage リソースに設定しています。

  1. HAStorage リソースに対するアプリケーションリソースの依存性を除去します。


    # clresource set -p Resource_Dependencies="" nfsserver-rs

  2. HAStorage リソースを無効にします。


    # clresource disable nfs1storage-rs

  3. アプリケーションリソースグループから HAStorage リソースを削除します。


    # clresource delete nfs1storage-rs

  4. HAStorage リソースタイプの登録を解除します。


    # clresourcetype unregister SUNW.HAStorage

  5. /etc/vfstab を変更して広域フラグを削除し、「mount at boot」を「no」に変更します。

  6. HAStoragePlus リソースを作成します。

    注 –

    HAStorage の ServicePaths プロパティーを使用する代わりに、HAStoragePlus の FilesystemMountPoints プロパティーまたは GlobalDevicePaths プロパティーを使用する必要があります。

    • ファイルシステムのマウントポイントを指定するには、次のコマンドを入力します。

      FilesystemMountPoints 拡張プロパティーは、/etc/vfstab で指定されたシーケンスと一致する必要があります。


      # clresource create -g nfs1-rg -t \
SUNW.HAStoragePlus -p FilesystemMountPoints=/global/nfsdata -p \
AffinityOn=True nfs1-hastp-rs

    • グローバルデバイスパスを指定するには、次のコマンドを入力してください。


      # clresource create -g nfs1-rg -t \
SUNW.HAStoragePlus -p GlobalDevicePaths=nfsdg -p AffinityOn=True nfs1-hastp-rs

    リソースは有効状態で作成されます。

  7. アプリケーションサーバーリソースを無効にします。


    # clresource disable nfsserver-rs

  8. nfs1-rg グループをクラスタノード上でオンラインにします。


    # clresourcegroup online nfs1-rg

  9. アプリケーションサーバーとHAStoragePlus との間の依存性を設定します。


    # clresource set -p Resource_dependencies=nfs1-hastp-rs nfsserver-rs

  10. nfs1-rg グループをクラスタノード上でオンラインにします。


    # clresourcegroup online -eM nfs1-rg

高可用性ファイルシステムのリソースをオンラインのままで変更する

ファイルシステムを表現しているリソースを変更している間でも、高可用性ファイルシステムは利用できる必要があります。たとえば、ストレージが動的に提供されている場合、ファイルシステムは利用できる必要があります。このような状況では、高可用性ファイルシステムを表現しているリソースをオンラインのままで変更します。

Sun Cluster 環境では、高可用性ファイルシステムは HAStoragePlus リソースで表現されます。Sun Cluster では、HAStoragePlus をオンラインのままで変更するには、次のようにします。

注 –

Sun Cluster ソフトウェアでは、ファイルシステムの名前はオンラインのままでは変更できません。

ProcedureSolaris ZFS 以外のファイルシステムをオンラインの HAStoragePlus リソースに追加する

ローカルまたは広域ファイルシステムを HAStoragePlus リソースに追加する場合、HAStoragePlus リソースは自動的にファイルシステムをマウントします。

  1. クラスタの 1 つのノードで、スーパーユーザーになるか、solaris.cluster.modify RBAC の承認を提供する役割になります。

  2. クラスタの各ノードの /etc/vfstab ファイルにおいて、追加しようとしている各ファイルシステムのマウントポイント用のエントリを追加します。

    エントリごとに、mount at boot フィールドと mount options フィールドを次のように設定します。

    • ローカルファイルシステムの場合

      • mount at boot フィールドを no に設定します。

      • global フラグを削除します。

    • クラスタファイルシステムの場合

      • ファイルシステムがグローバルファイルシステムの場合、global オプションを含むように mount options フィールドを設定します。

  3. HAStoragePlus リソースがすでに管理しているファイルシステムのマウントポイントのリストを取得します。


    # scha_resource_get -O extension -R hasp-resource -G hasp-rg \
FileSystemMountPoints
    -R hasp-resource

    ファイルシステムを追加する先の HAStoragePlus リソースを指定します。

    -G hasp-rg

    HAStoragePlus リソースを含むリソースグループを指定します。

  4. HAStoragePlus リソースの FileSystemMountPoints 拡張プロパティーを変更して、次のマウントポイントを含むようにします。

    • HAStoragePlus リソースがすでに管理しているファイルシステムのマウントポイント

    • HAStoragePlus リソースに追加しようとしているファイルシステムのマウントポイント


    # clresource set -p FileSystemMountPoints="mount-point-list" hasp-resource
    -p FileSystemMountPoints="mount-point-list"

    HAStoragePlus リソースがすでに管理しているファイルシステムのマウントポイントと、追加しようとしているファイルシステムのマウントポイントをコンマで区切って指定します。リスト内の各エントリの形式は、LocalZonePath:GlobalZonePath です。この形式では、大域パスはオプションです。大域パスが指定されていない場合、大域パスはローカルパスと同じになります。

    hasp-resource

    ファイルシステムを追加する先の HAStoragePlus リソースを指定します。

  5. HAStoragePlus リソースのマウントポイントのリストと、手順 4で指定したリストが一致していることを確認します。


    # scha_resource_get -O extension -R hasp-resource -G hasp-rg \
 FileSystemMountPoints
    -R hasp-resource

    ファイルシステムを追加する先の HAStoragePlus リソースを指定します。

    -G hasp-rg

    HAStoragePlus リソースを含むリソースグループを指定します。

  6. HAStoragePlus リソースがオンラインであり、障害が発生していないことを確認します。

    HAStoragePlus リソースがオンラインであるが、障害が発生している場合、リソースの確認は成功しますが、HAStoragePlus によるファイルシステムのマウントは失敗します。


    # clresource status hasp-resource
例 2–36 オンラインの HAStoragePlus リソースへのファイルシステムの追加

次に、オンラインの HAStoragePlus リソースにファイルシステムを追加する例を示します。

この例では、各クラスタノード上の /etc/vfstabファイルにはすでに、追加しようとしているファイルシステムのエントリが含まれていると仮定します。


# scha_resource_get -O extension -R rshasp -G rghasp FileSystemMountPoints
STRINGARRAY
/global/global-fs/fs
# clresource set  \
-p FileSystemMountPoints="/global/global-fs/fs,/global/local-fs/fs"
# scha_resource_get -O extension -R rshasp -G rghasp FileSystemMountPoints rshasp
STRINGARRAY
/global/global-fs/fs
/global/local-fs/fs
# clresource status rshasp


=== Cluster Resources ===

Resource Name          Node Name      Status        Message
--------------        ----------      -------       --------
   rshasp               node46       Offline         Offline
                        node47       Online          Online

Procedureオンラインの HAStoragePlus リソースから Solaris ZFS 以外のファイルシステムを削除する

HAStoragePlus リソースからファイルシステムを削除するとき、HAStoragePlus リソースはローカルファイルシステムをグローバルファイルシステムとは別に処理します。

注意 – 注意 –

オンラインの HAStoragePlus リソースからファイルシステムを削除する前には、そのファイルシステムを使用しているアプリケーションが存在しないことを確認してください。オンラインの HAStoragePlus リソースからファイルシステムを削除すると、そのファイルシステムは強制的にアンマウントされます。アプリケーションが使用しているファイルシステムが強制的にアンマウントされると、そのアプリケーションは異常終了またはハングする可能性があります。

  1. クラスタの 1 つのノードで、スーパーユーザーになるか、solaris.cluster.modify RBAC の承認を提供する役割になります。

  2. HAStoragePlus リソースがすでに管理しているファイルシステムのマウントポイントのリストを取得します。


    # scha_resource_get -O extension -R hasp-resource -G hasp-rg \
FileSystemMountPoints
    -R hasp-resource

    ファイルシステムを削除する元の HAStoragePlus リソースを指定します。

    -G hasp-rg

    HAStoragePlus リソースを含むリソースグループを指定します。

  3. HAStoragePlus リソースの FileSystemMountPoints 拡張プロパティーを変更して、HAStoragePlus リソースに残すファイルシステムのマウントポイントだけを含むようにします。


    # clresource set -p FileSystemMountPoints="mount-point-list" hasp-resource
    -p FileSystemMountPoints="mount-point-list"

    HAStoragePlus リソースに残そうとしているファイルシステムのマウントポイントをコンマで区切って指定します。このリストには、削除しようとしているファイルシステムのマウントポイントが含まれていてはなりません。

    hasp-resource

    ファイルシステムを削除する元の HAStoragePlus リソースを指定します。

  4. HAStoragePlus リソースのマウントポイントのリストと、手順 3で指定したリストが一致していることを確認します。


    # scha_resource_get -O extension -R hasp-resource -G hasp-rg \
FileSystemMountPoints
    -R hasp-resource

    ファイルシステムを削除する元の HAStoragePlus リソースを指定します。

    -G hasp-rg

    HAStoragePlus リソースを含むリソースグループを指定します。

  5. HAStoragePlus リソースがオンラインであり、障害が発生していないことを確認します。

    HAStoragePlus リソースがオンラインであるが、障害が発生している場合、リソースの確認は成功しますが、HAStoragePlus によるファイルシステムのアンマウントは失敗します。


    # clresource status hasp-resource

  6. (省略可能) クラスタの各ノードの /etc/vfstab ファイルから、削除しようとしている各ファイルシステムのマウントポイント用のエントリを削除します。

例 2–37 オンラインの HAStoragePlus リソースからのファイルシステムの削除

次に、オンラインの HAStoragePlus リソースからファイルシステムを削除する例を示します。


# scha_resource_get -O extension -R rshasp -G rghasp FileSystemMountPoints
STRINGARRAY
/global/global-fs/fs
/global/local-fs/fs
# clresource set -p FileSystemMountPoints="/global/global-fs/fs"
# scha_resource_get -O extension -R rshasp -G rghasp FileSystemMountPoints rshasp
STRINGARRAY
/global/global-fs/fs
 # clresource status rshasp


=== Cluster Resources ===

Resource Name          Node Name      Status        Message
--------------        ----------      -------       --------
   rshasp               node46       Offline         Offline
                        node47       Online          Online

ProcedureSolaris ZFS ストレージプールをオンラインの HAStoragePlus リソースに追加する

Solaris ZFS (Zettabyte File System) ストレージプールをオンラインの HAStoragePlus リソースに追加する場合、HAStoragePlus リソースは次の処理を行います。

  1. クラスタ内の任意のノードで、スーパーユーザーになるか、solaris.cluster.modify RBAC の承認を提供する役割になります。

  2. HAStoragePlus リソースがすでに管理している ZFS ストレージプールを判別します。


    # clresource show -g hasp-resource-group -p Zpools hasp-resource
    -g hasp-resource-group

    HAStoragePlus リソースを含むリソースグループを指定します。

    hasp-resource

    ZFS ストレージプールを追加する先の HAStoragePlus リソースを指定します。

  3. HAStoragePlus リソースがすでに管理している ZFS ストレージプールの既存のリストに、新しい ZFS ストレージプールを追加します。


    # clresource set -p Zpools="zpools-list" hasp-resource
    -p Zpools="zpools-list"

    HAStoragePlus リソースがすでに管理している既存の ZFS ストレージプール名のコンマ区切りリストと、追加する新しい ZFS ストレージプール名を指定します。

    hasp-resource

    ZFS ストレージプールを追加する先の HAStoragePlus リソースを指定します。

  4. HAStoragePlus リソースが管理する ZFS ストレージプールの新しいリストと、手順 2 で生成したリストを比較します。


    # clresource show -g hasp-resource-group -p Zpools hasp-resource
    -g hasp-resource-group

    HAStoragePlus リソースを含むリソースグループを指定します。

    hasp-resource

    ZFS ストレージプールの追加先である HAStoragePlus リソースを指定します。

  5. HAStoragePlus リソースがオンラインであり、障害が発生していないことを確認します。

    HAStoragePlus リソースがオンラインで障害が発生した場合は、リソースの検証自体は成功したことになります。ただし、HAStoragePlus リソースによる ZFS のインポートとマウントの試みは失敗しています。この場合、以前の一連の手順を繰り返す必要があります。


    # clresourcegroup status hasp-resource

Procedureオンラインの HAStoragePlus リソースから Solaris ZFS ストレージプールを削除する

オンラインの HAStoragePlus リソースから Solaris ZFS (Zettabyte File System) ストレージプールを削除する場合、HAStoragePlus リソースは次の処理を行います。

  1. クラスタ内の任意のノードで、スーパーユーザーになるか、solaris.cluster.modify RBAC の承認を提供する役割になります。

  2. HAStoragePlus リソースがすでに管理している ZFS ストレージプールを判別します。


    # clresource show -g hasp-resource-group -p Zpools hasp-resource
    -g hasp-resource-group

    HAStoragePlus リソースを含むリソースグループを指定します。

    hasp-resource

    ZFS ストレージプールの削除元である HAStoragePlus リソースを指定します。

  3. HAStoragePlus リソースが現在管理している ZFS ストレージプールのリストから ZFS ストレージプールを削除します。


    # clresource set -p Zpools="zpools-list" hasp-resource
    -p Zpools="zpools-list"

    HAStoragePlus リソースが現在管理している ZFS ストレージプール名のコンマ区切りリストから、削除する ZFS ストレージプール名を除いたものを指定します。

    hasp-resource

    ZFS ストレージプールの削除元である HAStoragePlus リソースを指定します。

  4. HAStoragePlus リソースが現在管理する ZFS ストレージプールの新しいリストと、手順 2 で生成したリストを比較します。


    # clresource show -g hasp-resource-group -p Zpools hasp-resource
    -g hasp-resource-group

    HAStoragePlus リソースを含むリソースグループを指定します。

    hasp-resource

    ZFS ストレージプールの削除元である HAStoragePlus リソースを指定します。

  5. HAStoragePlus リソースがオンラインであり、障害が発生していないことを確認します。

    HAStoragePlus リソースがオンラインで障害が発生した場合は、リソースの検証自体は成功したことになります。ただし、HAStoragePlus リソースによる ZFS のアンマウントとエクスポートの試みは失敗しています。この場合、以前の一連の手順を繰り返す必要があります。


    # clresourcegroup status SUNW.HAStoragePlus +

ProcedureHAStoragePlus リソースの FileSystemMountPoints プロパティーを変更したあと障害から回復する

FileSystemMountPoints 拡張プロパティーの変更中に障害が発生した場合、HAStoragePlus リソースの状態はオンラインであり、かつ、障害が発生しています。障害を修正した後、HAStoragePlus の状態はオンラインです。

  1. 変更が失敗した原因となる障害を特定します。


    # clresource status hasp-resource

    障害が発生した HAStoragePlus リソースの状態メッセージは、その障害を示します。可能性のある障害は、次のとおりです。

    • ファイルシステムが存在するはずのデバイスが存在しません。

    • fsck コマンドによるファイルシステムの修復が失敗しました。

    • 追加しようとしたファイルシステムのマウントポイントが存在しません。

    • 追加しようとしたファイルシステムがマウントできません。

    • 削除しようとしたファイルシステムがアンマウントできません。

  2. 変更が失敗した原因となる障害を修正します。

  3. HAStoragePlus リソースの FileSystemMountPoints 拡張プロパティーを変更する手順を繰り返します。


    # clresource set -p FileSystemMountPoints="mount-point-list" hasp-resource
    -p FileSystemMountPoints="mount-point-list"

    高可用性ファイルシステムの変更が失敗したときに指定したマウントポイントをコンマで区切って指定します。

    hasp-resource

    変更しようとしている HAStoragePlus リソースを指定します。

  4. HAStoragePlus リソースがオンラインであり、障害が発生していないことを確認します。


    # clresource status
例 2–38 障害が発生した HAStoragePlus リソースの状態

次に、障害が発生した HAStoragePlus リソースの状態の例を示します。fsck コマンドによるファイルシステムの修復が失敗したため、このリソースには障害が発生しています。


# clresource status

  === Cluster Resources ===

  Resource Name     Node Name     Status       Status Message
  --------------    ----------    -------      -------------
  rshasp            node46        Offline      Offline
                    node47        Online       Online Faulted - Failed to fsck: /mnt.

ProcedureHAStoragePlus リソースの Zpools プロパティーを変更したあと障害から回復する

Zpools 拡張プロパティーの変更中に障害が発生した場合、HAStoragePlus リソースの状態はオンラインであり、かつ、障害が発生しています。障害を修正した後、HAStoragePlus の状態はオンラインです。

  1. 変更が失敗した原因となる障害を特定します。


    # clresource status hasp-resource

    障害が発生した HAStoragePlus リソースの状態メッセージは、その障害を示します。可能性のある障害は、次のとおりです。

    • ZFS のプール zpool がインポートに失敗した。

    • ZFS のプール zpool がエクスポートに失敗した。

  2. 変更が失敗した原因となる障害を修正します。

  3. HAStoragePlus リソースの Zpools 拡張プロパティーを変更する手順を繰り返します。


    # clresource set -p Zpools="zpools-list" hasp-resource
    -p Zpools="zpools-list"

    HAStoragePlus が現在管理している ZFS ストレージプール名のコンマ区切りリストから、削除する ZFS ストレージプール名を除いたものを指定します。

    hasp-resource

    変更しようとしている HAStoragePlus リソースを指定します。

  4. HAStoragePlus リソースがオンラインであり、障害が発生していないことを確認します。


    # clresource status
例 2–39 障害が発生した HAStoragePlus リソースの状態

次に、障害が発生した HAStoragePlus リソースの状態の例を示します。ZFS のプール zpool がインポートに失敗したため、このリソースには障害が発生しています。


# clresource status hasp-resource

  === Cluster Resources ===

  Resource Name     Node Name     Status            Status Message
  --------------    ----------    -------           -------------
  hasp-resource     node46        Online            Faulted - Failed to import:hazpool
                    node47        Offline           Offline

HAStoragePlus リソースの広域ファイルシステスムからローカルファイルシステムへの変更

HAStoragePlus リソースのファイルシステムを、広域ファイルシステムからローカルファイルシステムに変更できます。

ProcedureHAStoragePlus リソースの広域ファイルシステムをローカルファイルシステムに変更する

  1. フェイルオーバーリソースグループをオフラインにします。


    # clresourcegroup offline resource-group

  2. HAStoragePlus リソースを表示します。


    # clresource show -g resource-group -t SUNW.HAStoragePlus

  3. 各リソースのマウントポイントのリストを取得します。


    # clresource show -p FilesystemMountPoints  hastorageplus-resource

  4. 広域ファイルシステムをアンマウントします。


    # umount mount-points

  5. リソースグループのノードリストで構成されているすべてのノード上で、マウントポイントの /etc/vfstab エントリを変更します。

    • マウントオプションから global キーワードを削除します。

    • mount at boot オプションを yes から no に変更します。

    リソースグループで構成されているすべての HAStoragePlus リソースのすべてのクラスタファイルシステムに対して手順を繰り返します。

  6. リソースグループをオンラインにします。


    # clresourcegroup online -M resource-group

HAStoragePlus リソースタイプのアップグレード

Sun Cluster 3.1 9/04 では、HAStoragePlus リソースタイプは高可用性ファイルシステムをオンラインのままで変更できるように拡張されました。HAStoragePlus リソースタイプのアップグレードは、次のすべての条件が満たされる場合に行ってください。

リソースタイプをアップグレードする方法については、 「リソースタイプの更新」を参照してください。以下の各項では、HAStoragePlus リソースタイプのアップグレードに際して必要になる情報について説明します。

新しいリソースタイプバージョンの登録に関する情報

次の表に、リソースタイプのバージョンと Sun Cluster のリリースの関係を示します。Sun Cluster のリリースは、リソースタイプが導入されたバージョンを表します。

リソースタイプバージョン 

Sun Cluster のリリース 

1.0 

3.0 5/02 

2 

3.1 9/04 

4 

3.2 

6 

3.2 2/08 

登録されているリソースタイプのバージョンを調べるには、次のどちらかのコマンドを使用します。

このリソースタイプの RTR ファイルは /usr/cluster/lib/rgm/rtreg/SUNW.HAStoragePlus です。

リソースタイプの既存インスタンスの移行に関する情報

HAStoragePlus リソースタイプのインスタンスを移行する際には、次の点に注意してください。

オンラインのリソースグループをクラスタノード間で分散する

可用性を最大化するため、あるいは、性能を最適化するため、いくつかのサービスの組み合わせは、特定のオンラインのリソースグループをクラスタノードおよびゾーン間で分散する必要があります。オンラインのリソースグループを分散するということは、リソースグループ間でアフィニティーを作成するということであり、次のような理由で行われます。

この節では、次のような例を使用しながら、リソースグループのアフィニティーを使用して、オンラインのリソースグループをクラスタノードおよびゾーン間で分散する方法について説明します。

リソースグループのアフィニティー

リソースグループ間のアフィニティーは、複数のリソースグループが同時にオンラインになる可能性があるノードまたはゾーンを制限します。各アフィニティーにおいて、ソースのリソースグループには 1 つまたは複数のターゲットのリソースグループに対するアフィニティーを宣言します。リソースグループ間にアフィニティーを作成するには、ソースの RG_affinities リソースグループプロパティーを次のように設定します。


-p RG_affinities=affinity-list
affinity-list

ソースリソースグループとターゲットリソースグループ (複数可) の間のアフィニティーのコンマ区切りリストを指定します。リストでは 1 つまたは複数のアフィニティーを指定できます。

リストでは各アフィニティーを次のように指定します。


operator target-rg
注 –

operator と target-rg の間にはスペースを入れてはなりません。

<操作>

作成しようとしているアフィニティーのタイプを指定します。詳細は、表 2–2を参照してください。

target-rg

作成しているアフィニティーのターゲットであるリソースグループを指定します。

表 2–2 リソースグループ間のアフィニティーのタイプ

オペレータ 

アフィニティーのタイプ 

効果 

+

弱い肯定的な

ソースは、できる限り、ターゲットがオンラインである (あるいは、起動している) 1 つまたは複数のノードまたはゾーン上でオンラインになります。つまり、ソースとターゲットは異なるノードまたはゾーン上でオンラインになることもあります。 

++

強い肯定的な

ソースは、ターゲットがオンラインである (あるいは、起動している) 1 つまたは複数のノードまたはゾーン上でのみオンラインになります。つまり、ソースとターゲットは異なるノードまたはゾーン上でオンラインになることはありません。 

-

弱い否定的な

ソースは、可能であれば、ターゲットがオンラインでない (あるいは、起動していない) 1 つまたは複数のノードまたはゾーン上でオンラインになります。つまり、ソースとターゲットは同じノードまたはゾーン上でオンラインになることもあります。 

--

強い否定的な

ソースは、ターゲットがオンラインでない 1 つまたは複数のノードまたはゾーン上でのみオンラインになります。つまり、ソースとターゲットは同じノードまたはゾーン上でオンラインになることはありません。 

+++

フェイルオーバー委託付きの強い肯定的な

強い肯定的なアフィニティーと似ていますが、ソースによるフェイルオーバーはターゲットに委任されます。詳細については、「リソースグループのフェイルオーバーまたはスイッチオーバーを委託する」を参照してください。

弱いアフィニティーは、Nodelist 優先順位より優先されます。

そのほかのリソースグループの現在の状態によっては、任意のノードまたはゾーン上で、強いアフィニティーが成立しないことがあります。このような状況では、アフィニティーのソースであるリソースグループはオフラインのままです。その他のリソースグループの状態が変更され、強いアフィニティーが成立できるようになると、アフィニティーのソースであるリソースグループはオンラインに戻ります。

注 –

複数のターゲットリソースグループを持つソースリソースグループに強いアフィニティーを宣言するときは、注意が必要です。宣言されたすべての強いアフィニティーが成立しない場合、ソースリソースグループはオフラインのままになるためです。

あるリソースグループと別のリソースグループを強制的に同じ場所に配置する

あるリソースグループのサービスが別のリソースグループのサービスに強く依存する場合、これらのリソースグループは両方とも同じノードまたはゾーン上で動作する必要があります。たとえば、あるアプリケーションがお互いに依存する複数のサービスのデーモンから構成される場合、すべてのデーモンは同じノードまたはゾーン上で動作する必要があります。

このような状況では、依存するサービスのリソースグループを、強制的に、依存されるサービスのリソースグループと同じ場所に配置するように指定します。あるリソースグループを強制的に別のリソースグループと同じ場所に配置するには、あるリソースグループに別のリソースグループに対する強い肯定的なアフィニティーを宣言します。


# clresourcegroup set|create -p RG_affinities=++target-rg source-rg
source-rg

強い肯定的なアフィニティーのソースであるリソースグループを指定します。このリソースグループは、別のリソースグループに対する強い肯定的なアフィニティーを宣言するリソースグループです。

-p RG_affinities=++target-rg

強い肯定的なアフィニティーのターゲットであるリソースグループを指定します。このリソースグループは、強い肯定的なアフィニティーを宣言する対象のリソースグループです。

強い肯定的なアフィニティーを宣言しているソースのリソースグループは、ターゲットのリソースグループに従います。ターゲットのリソースグループが別のノードに再配置された場合、ソースのリソースグループは自動的にターゲットと同じノードに切り替わります。しかし、強い肯定的なアフィニティーを宣言しているソースのリソースグループは、ターゲットのリソースグループが動作していないノードまたはゾーンにはフェイルオーバーできません。

注 –

フェイルオーバーされないのは、リソースモニターが起動したフェイルオーバーだけです。ソースとターゲットの両方のリソースグループが動作しているノードまたはゾーンに障害が発生した場合、これらのリソースグループは、正常に動作している同じノードまたはゾーンにフェイルオーバーします。

たとえば、リソースグループ rg1 にリソースグループ rg2 に対する強い肯定的なアフィニティーが宣言されていると仮定します。rg2 が別のノードまたはゾーンにフェイルオーバーすると、rg1 もそのノードまたはゾーンにフェイルオーバーします。rg1 内のすべてのリソースが操作可能であるとしても、このフェイルオーバーは発生します。しかし、rg1 内のリソースによって、rg2 が動作していないノードまたはゾーンに rg1 をフェイルオーバーしようとした場合、このフェイルオーバーはブロックされます。

強い肯定的なアフィニティーのターゲットをオンラインにしたときに、強い肯定的なアフィニティーのソースがすべてのノード上でオフラインになっている場合があります。このような場合、強い肯定的なアフィニティーのソースは、ターゲットと同じノード上で自動的にオンラインになります。

たとえば、リソースグループ rg1 にリソースグループ rg2 に対する強い肯定的なアフィニティーが宣言されていると仮定します。最初は両方のリソースグループともすべてのノード上でオフラインです。管理者があるノード上で rg2 をオンラインにすると、rg1 は自動的に同じノード上でオンラインになります。

clresourcegroup suspend コマンドを使用すると、強いアフィニティーまたはクラスタ再構成によりリソースグループが自動的にオンラインになるのを防止できます。

強い肯定的なアフィニティーを宣言しているリソースグループをフェイルオーバーする必要がある場合、そのフェイルオーバーは委託する必要があります。詳細については、「リソースグループのフェイルオーバーまたはスイッチオーバーを委託する」を参照してください。

例 2–40 あるリソースグループと別のリソースグループを強制的に同じ場所に配置する

この例では、リソースグループ rg1 を変更して、リソースグループ rg2 に対する強い肯定的なアフィニティーを宣言するためのコマンドを示します。このアフィニティーを宣言すると、rg1 は rg2 が動作しているノードまたはゾーン上だけでオンラインになります。この例では、両方のリソースグループが存在していると仮定します。


# clresourcegroup set -p RG_affinities=++rg2 rg1

あるリソースグループと別のリソースグループをできる限り同じ場所に配置する

あるリソースグループのサービスが別のリソースグループのサービスを使用していることがあります。結果として、これらのサービスは、同じノードまたはゾーン上で動作する場合にもっとも効率よく動作します。たとえば、データベースを使用するアプリケーションは、そのアプリケーションとデータベースが同じノードまたはゾーン上で動作する場合に、もっとも効率よく動作します。しかし、これらのサービスは異なるノードまたはゾーン上で動作してもかまいません。なぜなら、リソースグループのフェイルオーバーの増加よりも効率の低下のほうが被害が小さいためです。

このような状況では、両方のリソースグループを、できる限り、同じ場所に配置するように指定します。あるリソースグループと別のリソースグループをできる限り同じ場所に配置するには、あるリソースグループに別のリソースグループに対する弱い肯定的なアフィニティーを宣言します。


# clresourcegroup set|create -p RG_affinities=+target-rg source-rg
source-rg

弱い肯定的なアフィニティーのソースであるリソースグループを指定します。このリソースグループは、別のリソースグループに対する弱い肯定的なアフィニティーを宣言するリソースグループです。

-p RG_affinities=+target-rg

弱い肯定的なアフィニティーのターゲットであるリソースグループを指定します。このリソースグループは、弱い肯定的なアフィニティーを宣言する対象のリソースグループです。

あるリソースグループに別のリソースグループに対する弱い肯定的なアフィニティーを宣言することによって、両方のリソースグループが同じノードまたはゾーンで動作する確率が上がります。弱い肯定的なアフィニティーのソースは、まず、そのアフィニティーのターゲットがすでに動作しているノードまたはゾーン上でオンラインになろうとします。しかし、弱い肯定的なアフィニティーのソースは、そのアフィニティーのターゲットがリソースモニターによってフェイルオーバーされても、フェイルオーバーしません。同様に、弱い肯定的なアフィニティーのソースは、そのアフィニティーのターゲットがスイッチオーバーされても、フェイルオーバーしません。どちらの状況でも、ソースがすでに動作しているノードまたはゾーン上では、ソースはオンラインのままです。

注 –

ソースとターゲットの両方のリソースグループが動作しているノードまたはゾーンに障害が発生した場合、これらのリソースグループは、正常に動作している同じノードまたはゾーン上で再起動されます。

例 2–41 あるリソースグループと別のリソースグループをできる限り同じ場所に配置する

この例では、リソースグループ rg1 を変更して、リソースグループ rg2 に対する弱い肯定的なアフィニティーを宣言するためのコマンドを示します。このアフィニティーを宣言すると、rg1 と rg2 はまず、同じノードまたはゾーン上でオンラインになろうとします。しかし、rg2 内のリソースによって rg2 がフェイルオーバーしても、rg1 はリソースグループが最初にオンラインになったノードまたはゾーン上でオンラインのままです。この例では、両方のリソースグループが存在していると仮定します。


# clresourcegroup set -p RG_affinities=+rg2 rg1

リソースグループの集合の負荷をクラスタノード間で均等に分配する

リソースグループの集合の各リソースグループには、クラスタの同じ負荷をかけることができます。このような状況では、リソースグループをクラスタ間で均等に分散することによって、クラスタの負荷の均衡をとることができます。

リソースグループの集合のリソースグループをクラスタノード間で均等に分散するには、各リソースグループに、リソースグループの集合のほかのリソースグループに対する弱い否定的なアフィニティーを宣言します。


# clresourcegroup set|create -p RG_affinities=neg-affinity-list source-rg
source-rg

弱い否定的なアフィニティーのソースであるリソースグループを指定します。このリソースグループは、別のリソースグループに対する弱い否定的なアフィニティーを宣言するリソースグループです。

-p RG_affinities=neg-affinity-list

ソースリソースグループと、弱い否定的なアフィニティーのターゲットであるリソースグループの間の、弱い否定的なアフィニティーをコンマで区切って指定します。ターゲットリソースグループは、弱い否定的なアフィニティーを宣言する対象のリソースグループです。

あるリソースグループにその他のリソースグループに対する弱い否定的なアフィニティーを宣言することによって、そのリソースグループが常に、もっとも負荷がかかっていないクラスタノード上でオンラインになることが保証されます。 このノード上で動作しているその他のリソースグループは最小数です。したがって、弱い否定的なアフィニティーの最小数が違反されます。

例 2–42 リソースグループの集合の負荷をクラスタノード間で均等に分配する

この例では、リソースグループ rg1、rg2、rg3、および rg4 を変更して、これらのリソースグループを、クラスタで利用可能なノード間で均等に分配するためのコマンドを示します。この例では、リソースグループ rg1、rg2、rg3、および rg4 が存在していると仮定します。


# clresourcegroup set -p RG_affinities=-rg2,-rg3,-rg4 rg1
# clresourcegroup set -p RG_affinities=-rg1,-rg3,-rg4 rg2
# clresourcegroup set -p RG_affinities=-rg1,-rg2,-rg4 rg3
# clresourcegroup set -p RG_affinities=-rg1,-rg2,-rg3 rg4

重要なサービスに優先権を指定する

クラスタは、重要なサービスと重要でないサービス組み合わせて動作するように構成できます。たとえば、重要な顧客サービスをサポートするデータベースは、重要でない研究タスクと同じクラスタで実行できます。

重要でないサービスが重要なサービスに影響を与えないようにするには、重要なサービスに優先権を指定します。重要なサービスに優先権を指定することによって、重要でないサービスが重要なサービスと同じノード上で動作することを防ぐことができます。

すべてのノードが操作可能であるとき、重要なサービスは重要でないサービスとは異なるノード上で動作します。しかし、重要なサービスに障害が発生すると、このサービスは重要でないサービスが動作しているノードにフェイルオーバーします。このような状況では、重要でないサービスは直ちにオフラインになり、重要なサービスはコンピューティングリソースを完全に利用できるようになります。

重要なサービスに優先権を指定するには、重要でない各サービスのリソースグループに、重要なサービスを含むリソースグループに対する強い否定的なアフィニティーを宣言します。


# clresourcegroup set|create -p RG_affinities=--critical-rg noncritical-rg
noncritical-rg

重要でないサービスを含むリソースグループを指定します。このリソースグループは、別のリソースグループに対する強い否定的なアフィニティーを宣言するリソースグループです。

-p RG_affinities=--critical-rg

重要なサービスを含むリソースグループを指定します。このリソースグループは、強い否定的なアフィニティーが宣言されるリソースグループです。

強い否定的なアフィニティーのソースのリソースグループは、そのアフィニティーのターゲットのリソースグループから離れます。

強い否定的なアフィニティーのターゲットをオフラインにした場合、強い否定的なアフィニティーのソースは、すべてのノード上でオフラインになる場合があります。このような状況では、強い否定的なアフィニティーのソースは自動的にオンラインになります。通常、ノードリストのノードの順序および宣言されたアフィニティーに基づいて、リソースグループは最も優先されるノード上でオンラインになります。

たとえば、リソースグループ rg1 にリソースグループ rg2 に対する強い否定的なアフィニティーが宣言されていると仮定します。最初はリソースグループ rg1 がすべてのノード上でオフラインになりますが、リソースグループ rg2 は 1 つのノード上でオンラインになります。管理者が rg2 をオフラインにすると、rg1 は自動的にオンラインになります。

clresourcegroup suspend コマンドを使用すると、強いアフィニティーまたはクラスタ再構成により強い否定的なアフィニティーのソースが自動的にオンラインになるのを防止できます。

例 2–43 重要なサービスに優先権を指定する

この例では、重要でないリソースグループ ncrg1 と ncrg2 を変更して、重要なリソースグループ mcdbrg に重要でないリソースグループよりも高い優先権を与えるためのコマンドを示します。この例では、リソースグループ mcdbrg、ncrg1、および ncrg2 が存在していると仮定します。


# clresourcegroup set -p RG_affinities=--mcdbrg ncrg1 ncrg2

リソースグループのフェイルオーバーまたはスイッチオーバーを委託する

強い肯定的なアフィニティーのソースリソースグループは、そのアフィニティーのターゲットが動作していないノードにはフェイルオーバーまたはスイッチオーバーできません。強い肯定的なアフィニティーのソースリソースグループをフェイルオーバーまたはスイッチオーバーする必要がある場合、そのフェイルオーバーはターゲットリソースグループに委託する必要があります。このアフィニティーのターゲットがフェイルオーバーするとき、このアフィニティーのソースはターゲットと一緒に強制的にフェイルオーバーされます。

注 –

++ 演算子で指定した強い肯定的なアフィニティーのソースリソースグループでも、スイッチオーバーする必要がある場合もあります。このような状況では、このアフィニティーのターゲットとソースを同時にスイッチオーバーします。

リソースグループのフェイルオーバーまたはスイッチオーバーを別のリソースグループに委託するには、そのリソースグループに、その他のリソースグループに対するフェイルオーバー委託付きの強い肯定的なアフィニティーを宣言します。


# clresourcegroup set|create source-rg -p RG_affinities=+++target-rg
source-rg

フェイルオーバーまたはスイッチオーバーを委託するリソースグループを指定します。このリソースグループは、別のリソースグループに対するフェイルオーバー委託付きの強い肯定的なアフィニティーを宣言するリソースグループです。

-p RG_affinities=+++target-rg

source-rg がフェイルオーバーまたはスイッチオーバーを委託するリソースグループを指定します。このリソースグループは、フェイルオーバー委託付きの強い肯定的なアフィニティーが宣言されるリソースグループです。

あるリソースグループは、最大 1 つのリソースグループに対するフェイルオーバー委託付きの強い肯定的なアフィニティーを宣言できます。逆に、あるリソースグループは、その他の任意の数のリソースグループによって宣言されたフェイルオーバー委託付きの強い肯定的なアフィニティーのターゲットである可能性があります。

つまり、フェイルオーバー委託付きの強い肯定的なアフィニティーは対照的ではありません。ソースがオフラインの場合でも、ターゲットはオンラインになることができます。しかし、ターゲットがオフラインの場合、ソースはオンラインになることができません。

ターゲットが第三のリソースグループに対するフェイルオーバー委任付きの強い肯定的なアフィニティーを宣言する場合、フェイルオーバーまたはスイッチオーバーはさらに第三のリソースグループに委託されます。第三のリソースグループがフェイルオーバーまたはスイッチオーバーを実行すると、その他のリソースグループも強制的にフェイルオーバーまたはスイッチオーバーされます。

例 2–44 リソースグループのフェイルオーバーまたはスイッチオーバーを委託する

この例では、リソースグループ rg1 を変更して、リソースグループ rg2 に対するフェイルオーバー委託付きの強い肯定的なアフィニティーを宣言するためのコマンドを示します。このアフィニティー関係の結果、rg1 はフェイルオーバーまたはスイッチオーバーを rg2 に委託します。この例では、両方のリソースグループが存在していると仮定します。


# clresourcegroup set -p RG_affinities=+++rg2 rg1

リソースグループ間のアフィニティーの組み合わせ

複数のアフィニティーを組み合わせることによって、より複雑な動作を作成できます。たとえば、関連する複製サーバーにアプリケーションの状態を記録できます。この例におけるノード選択条件は次のとおりです。

これらの条件を満たすには、アプリケーションと複製サーバーのリソースグループを次のように構成します。

例 2–45 リソースグループ間のアフィニティーの組み合わせ

この例では、次のリソースグループ間のアフィニティーを組み合わせるためのコマンドを示します。

この例では、リソースグループはアフィニティーを次のように宣言します。

この例では、両方のリソースグループが存在していると仮定します。


# clresourcegroup set -p RG_affinities=+rep-rg app-rg
# clresourcegroup set -p RG_affinities=--app-rg rep-rg

リソースグループ、リソースタイプ、およびリソースの構成データを複製およびアップグレードする

2 つのクラスタ上で同じリソース構成データが必要である場合、このデータを 2 番目のクラスタに複製することによって、もう一度同じ設定を行うという面倒な作業を省略できます。scsnapshot を使用して、あるクラスタから別のクラスタにリソース構成情報をコピーします。設定後、問題が生じないように、リソース関係の構成が安定していることを確認します。2 番目のクラスタに情報をコピーする前に、リソース構成に大きな変更を行う必要はありません。

リソースグループ、リソースタイプ、およびリソースの構成データは、クラスタ構成リポジトリ (CCR) から取得でき、シェルスクリプトとして書式化されています。このスクリプトを使用すると、次の作業を実行できます。

scsnapshot ツールは、CCR に格納されている構成データを取得します。ほかの構成データは無視されます。scsnapshot ツールは、異なるリソースグループ、リソースタイプ、およびリソースの動的な状態を無視します。

Procedureリソースグループ、リソースタイプ、およびリソースが構成されていないクラスタに構成データを複製する

この手順は、リソースグループ、リソースタイプ、およびリソースが構成されていないクラスタに構成データを複製します。この手順では、あるクラスタから構成データのコピーを取得し、このデータを使用して、別のクラスタ上で構成データを生成します。

  1. システム管理者役割を使用して、構成データをコピーしたいクラスタノードにログインします。

    たとえば、node1 にログオンすると仮定します。

    システム管理者役割が与える役割によるアクセス制御 (RBAC) 権は、次のとおりです。

    • solaris.cluster.resource.read

    • solaris.cluster.resource.modify

  2. クラスタから構成データを取得します。


    node1 % scsnapshot -s scriptfile

    scsnapshot ツールは、 scriptfile というスクリプトを生成します。scsnapshot ツールの使用法の詳細については、scsnapshot(1M) のマニュアルページを参照してください。

  3. このスクリプトを編集して、構成データを複製したいクラスタに固有な特徴に合わせます。

    たとえば、スクリプト内にある IP アドレスやホスト名を変更します。

  4. このスクリプトを、構成データを複製したい任意のクラスタノードから実行します。

    このスクリプトは、スクリプトが生成されたクラスタとローカルクラスタの特性を比較します。これらの特性が同じでない場合、このスクリプトはエラーを書き込んで終了します。次に、-f オプションを使用してスクリプトを実行し直すかどうかをたずねるメッセージが表示されます。-f オプションを使用した場合、上記のような特性の違いを無視して、スクリプトを強制的に実行します。-f オプションを使用した場合、クラスタ内に不整合がないことを確認します。

    このスクリプトは、Sun Cluster リソースタイプがローカルクラスタ上に存在することを確認します。リソース型がローカルクラスタに存在しない場合、このスクリプトはエラーを書き込んで終了します。もう一度スクリプトを実行する前に、存在しないリソースタイプをインストールするかどうかをたずねるメッセージが表示されます。

Procedureリソースグループ、リソースタイプ、およびリソースが構成されているクラスタの構成データをアップグレードする

この手順は、リソースグループ、リソースタイプ、およびリソースがすでに構成されているクラスタ上の構成データをアップグレードします。この手順は、リソースグループ、リソースタイプ、およびリソースの構成テンプレートを生成するのにも使用できます。

この手順では、cluster1 上の構成データが cluster2 上の構成データに一致するようにアップグレードされます。

  1. システム管理者役割を使用して、cluster1 の任意のノードにログオンします。

    たとえば、node1 にログオンすると仮定します。

    システム管理者役割が与える RBAC 権は次のとおりです。

    • solaris.cluster.resource.read

    • solaris.cluster.resource.modify

  2. scsnapshot ツールの image file オプションを使用して、クラスタから構成データを取得します。


    node1% scsnapshot -s scriptfile1 -o imagefile1

    node1 上で実行するとき、scsnapshot ツールは scriptfile1 というスクリプトを生成します。このスクリプトは、リソースグループ、リソースタイプ、およびリソースの構成データを imagefile1 というイメージファイルに格納します。scsnapshot ツールの使用法の詳細については、scsnapshot(1M) のマニュアルページを参照してください。

  3. cluster2 のノード上で、手順 1 から手順 2 までの手順を繰り返します。


    node2 % scsnapshot -s scriptfile2 -o imagefile2

  4. node1 上で cluster2 の構成データを使用して cluster1 の構成データをアップグレードするためのスクリプトを生成します。


    node1 % scsnapshot -s scriptfile3 imagefile1 imagefile2

    この手順では、手順 2 と手順 3 で生成したイメージファイルを使用して、scriptfile3 という新しいスクリプトを生成します。

  5. 手順 4 で生成したスクリプトを編集して、cluster1 に固有な特徴に合わせて、cluster2 に固有なデータを削除します。

  6. このスクリプトを node1 から実行して、構成データをアップグレードします。

    このスクリプトは、スクリプトが生成されたクラスタとローカルクラスタの特性を比較します。これらの特性が同じでない場合、このスクリプトはエラーを書き込んで終了します。次に、-f オプションを使用してスクリプトを実行し直すかどうかをたずねるメッセージが表示されます。-f オプションを使用した場合、上記のような特性の違いを無視して、スクリプトを強制的に実行します。-f オプションを使用した場合、クラスタ内に不整合がないことを確認します。

    このスクリプトは、Sun Cluster リソースタイプがローカルクラスタ上に存在することを確認します。リソース型がローカルクラスタに存在しない場合、このスクリプトはエラーを書き込んで終了します。もう一度スクリプトを実行する前に、存在しないリソースタイプをインストールするかどうかをたずねるメッセージが表示されます。

Sun Cluster 上で Solaris SMF サービスを有効にする

SMF (Service Management Facility) を使用すると、ノードの起動中またはサービス障害中に自動的に SMF サービスを起動および再起動することができます。SMF は、単一ホスト上の SMF サービスに、ある程度の高可用性を実現します。この機能は、クラスタアプリケーションに高可用性とスケーラビリティーを実現する、Sun Cluster Resource Group Manager (RGM) に似ています。SMF サービスと RGM の機能は相互に補完的です。

Sun Cluster には、3 つの新しい SMF プロキシリソースタイプが含まれています。これらを使用すると、フェイルオーバー、マルチマスター、またはスケーラブル構成の Sun Cluster とともに SMF サービスが実行できるようになります。プロキシリソースタイプは次のとおりです。

SMF プロキシリソースタイプを使用すると、相互関係のある SMF サービスのセットを 1 つのリソースにカプセル化し、SMF プロキシリソースを Sun Cluster で管理することができます。この機能では、SMF は 1 つのノード上の SMF サービスの可用性を管理します。Sun Cluster は、SMF サービスの、クラスタ全体にわたる高い可用性とスケーラビリティーを提供します。

SMF プロキシリソースタイプを使用すると、独自の SMF の制御によるサービスを Sun Cluster に統合できます。これらのサービスには、ユーザーがコールバックメソッドやサービスマニフェストを書き換えることなく、クラスタ全体のサービス可用性が与えられます。SMF サービスを SMF プロキシリソースに統合したあとは、SMF サービスはデフォルトの再起動プログラムにより管理されなくなります。Sun Cluster により委任された再起動プログラムが、SMF サービスを管理します。

SMF プロキシリソースはほかのリソースと同じで、使用法に制限はありません。たとえば、SMF プロキシリソースは、ほかのリソースとともにリソースグループにグループ化することができます。SMF プロキシリソースは、ほかのリソースと同じように作成、管理することができます。SMF プロキシリソースは、1 点のみほかのリソースとは異なります。SMF プロキシリソースタイプのリソースを作成する場合、拡張プロパティー Proxied_service_instances を指定する必要があります。SMF リソースによってプロキシされる SMF サービスに関する情報を含めます。拡張プロパティーの値は、プロキシされるすべての SMF サービスを含むファイルへのパスです。ファイル内の各行は 1 つのSMF サービス専用で、svc fmri および対応するサービスマニフェストファイルのパスを指定します。

たとえば、リソースが 2 つのサービス、 restarter_svc_test_1:default と restarter_svc_test_2:default を管理する必要がある場合、ファイルには次に示す 2 行が含まれているはずです。


<svc:/system/cluster/restarter_svc_test_1:default>,\
</var/svc/manifest/system/cluster/restarter_svc_test_1.xml>
 

<svc:/system/cluster/restarter_svc_test_2:default>,\
</var/svc/manifest/system/cluster/restarter_svc_test_2.xml>

SMF プロキシリソースの下でカプセル化されたサービスは、大域ゾーンまたは非大域ゾーンに存在できます。ただし、同じプロキシリソースの下のすべてのサービスは同じゾーン内に配置します。

注意 – 注意 –

SMF svcadm は、プロキシリソース内にカプセル化される SMF サービスを有効または無効にするためには使用しないでください。プロキシリソースにカプセル化される SMF サービス (SMF リポジトリ内) のプロパティーは変更しないでください。

ProcedureSMF サービスのフェイルオーバープロキシリソース構成へのカプセル化

フェイルオーバー構成の詳細については、「リソースグループの作成」を参照してください。

注 –

この手順は、任意のクラスタノードから実行します。

  1. クラスタメンバーで、スーパーユーザーになるか、solaris.cluster.modify RBAC の承認を提供する役割になります。

  2. プロキシ SMF フェイルオーバーリソースタイプを登録します。


    # clresourcetype register -f\
/opt/SUNWscsmf/etc/SUNW.Proxy_SMF_failover SUNW.Proxy_SMF_failover

  3. 登録されたプロキシリソースタイプを確認します。


    # clresourcetype show

  4. SMF フェイルオーバーリソースグループを作成します。


    # clresourcegroup create [-n node-zone-list] resource-group
    -n node-zone-list

    このリソースグループをマスターできるゾーンの、コンマ区切りの順序付けされたリストを指定します。リスト内の各エントリの形式は node:zone です。この形式では、 node はノード名を指定し、zone は非大域 Solaris ゾーンの名前を指定します。大域ゾーンを指定する、または非大域ゾーンを持たないノードを指定するには、node のみを指定します。

    このリストはオプションです。このリストを省略すると、クラスタノードのすべての大域ゾーン上でリソースグループが構成されます。

    注 –

    最高の可用性を実現するには、同一ノード上の異なるゾーンではなく、SMF フェイルオーバーリソースグループのノードリストの異なるノード上でゾーンを指定します。

    resource-group

    追加するスケーラブルリソースグループの名前を指定します。任意の名前の先頭文字は ASCII にする必要があります。

  5. SMF リソースグループが作成されていることを確認します。


    # clresourcegroup status resource-group

  6. SMF フェイルオーバーアプリケーションリソースをリソースグループに追加します。


    # clresource create -g resource-group -t SUNW.Proxy_SMF_failover \
[-p "extension-property[{node-specifier}]"=value, …] [-p standard-property=value, …] resource

    リソースは有効状態で作成されます。

  7. SMF フェイルオーバーアプリケーションリソースが追加され、妥当性が検査されていることを確認します。


    # clresource show resource

  8. フェイルオーバーリソースグループをオンラインにします。


    # clresourcegroup online -M +
例 2–46 SMF プロキシフェイルオーバーリソースタイプの登録

次の例では、SUNW.Proxy_SMF_failover リソースタイプを登録します。


# clresourcetype register SUNW.Proxy_SMF_failover
# clresourcetype show SUNW.Proxy_SMF_failover

Resource Type:              SUNW.Proxy_SMF_failover
RT_description:             Resource type for proxying failover SMF services 
RT_version:                 3.2
API_version:                6
RT_basedir:                 /opt/SUNWscsmf/bin
Single_instance:            False
Proxy:                      False
Init_nodes:                 All potential masters
Installed_nodes:            <All>
Failover:                   True
Pkglist:                    SUNWscsmf 
RT_system:                  False
Global_zone:			       False
例 2–47 SMF プロキシフェイルオーバーアプリケーションリソースのリソースグループへの追加

次の例に、プロキシリソースタイプ SUN.Proxy_SMF_failover のリソースグループ resource-group-1 への追加を示します。


# clresource create -g resource-group-1 -t SUNW.Proxy_SMF_failover
-x proxied_service_instances=/var/tmp/svslist.txt resource-1
# clresource show resource-1

=== Resources ===

  Resource:                                  resource-1
  Type:                                      SUNW.Proxy_SMF_failover
  Type_version:                              3.2 
  Group:                                     resource-group-1
  R_description:                             
  Resource_project_name:                     default
  Enabled{phats1}:                           True 
  Monitored{phats1}:                         True

ProcedureSMF サービスのマルチマスタープロキシリソース構成へのカプセル化

  1. クラスタメンバーで、スーパーユーザーになるか、solaris.cluster.modify RBAC の承認を提供する役割になります。

  2. SMF プロキシマルチマスターリソースタイプを登録します。


    # clresourcetype register -f\ 
/opt/SUNWscsmf/etc/SUNW.Proxy_SMF_multimaster SUNW.Proxy_SMF_multimaster

  3. SMF マルチマスターリソースグループを作成します。


    # clresourcegroup create\-p Maximum_primaries=m\-p Desired_primaries=n\
[-n node-zone-list]\
resource-group
    -p Maximum_primaries=m

    このリソースグループのアクティブな主ノードの最大数を指定します。

    -p Desired_primaries=n

    リソースグループが起動するアクティブな主ノードの数を指定します。

    -n node-zone-list

    このリソースグループが使用可能となる、コンマ区切りの順序付けられたリストを指定します。リスト内の各エントリの形式は node:zone です。この形式では、 node はノード名を指定し、zone は非大域 Solaris ゾーンの名前を指定します。大域ゾーンを指定する、または非大域ゾーンを持たないノードを指定するには、node のみを指定します。

    このリストはオプションです。このリストを省略すると、クラスタノードの大域ゾーン上でリソースグループが構成されます。

    resource-group

    追加するスケーラブルリソースグループの名前を指定します。任意の名前の先頭文字は ASCII にする必要があります。

  4. SMF プロキシマルチマスターリソースグループが作成されたことを確認します。


    # clresourcegroup show resource-group

  5. SMF プロキシマルチマスターリソースをリソースグループに追加します。


    # clresource create -g resource-group -t SUNW.Proxy_SMF_multimaster\
[-p "extension-property[{node-specifier}]"=value, …] [-p standard-property=value, …] resource
    -g resource-group

    以前に作成したスケーラブルサービスリソースグループの名前を指定します。

    -p "extension-property[{node-specifier}]"=value, …

    リソース用に設定する拡張プロパティーのコンマ区切りリストを指定します。設定できる拡張プロパティーはリソースタイプに依存します。どの拡張プロパティーを設定するかを決定するには、リソースタイプのマニュアルを参照してください。

    node-specifier は、-p オプションおよび -x オプションに対する「オプション」の修飾子です。この修飾子は、指定された 1 つまたは複数のノードまたはゾーン上でのみ、1 つまたは複数の拡張プロパティーがリソースの作成時に設定されることを示します。指定した拡張プロパティーは、クラスタ内のほかのノードまたはゾーン上では、設定されません。node-specifier を指定しないと、クラスタ内のすべてのノードおよびゾーン上の指定された拡張プロパティーが設定されます。node-specifier にはノード名またはノード識別子を指定できます。node-specifier の構文例を次に示します。


    -p "myprop{phys-schost-1}"

    中括弧 ({}) は、指定した拡張プロパティーをノード phys-schost-1 でのみ設定することを示します。大部分のシェルでは、二重引用符 (") が必要です。

    また次の構文を使用して、2 つの異なるノード上の 2 つの異なるゾーン内で拡張プロパティーを設定することもできます。


    -x "myprop{phys-schost-1:zoneA,phys-schost-2:zoneB}"
    -p standard-property=value, …

    リソース用に設定する標準プロパティーのコンマ区切りリストを指定します。設定できる標準プロパティーはリソースタイプに依存します。スケーラブルサービスの場合、通常は Port_list、Load_balancing_weights、および Load_balancing_policy プロパティーを設定します。どの標準プロパティーを設定するかを決定するには、リソースタイプのマニュアルと付録 B 「標準プロパティー」を参照してください。

    resource

    追加するリソースの名前を指定します。

    リソースは有効状態で作成されます。

  6. SMF プロキシマルチマスターアプリケーションリソースが追加され、妥当性が検査されていることを確認します。


    # clresource show resource

  7. マルチマスターリソースグループをオンラインにします。


    # clresourcegroup online -M +
例 2–48 SMF プロキシマルチマスターリソースタイプの登録

次の例では、 SUNW.Proxy_SMF_multimaster リソースタイプを登録します。


# clresourcetype register SUNW.Proxy_SMF_multimaster
# clresourcetype show SUNW.Proxy_SMF_multimaster

Resource Type:            SUNW.Proxy_SMF_multimaster
RT_description:           Resource type for proxying multimastered SMF services 
RT_version:               3.2
API_version:              6
RT_basedir:               /opt/SUNWscsmf/bin
Single_instance:          False
Proxy:                    False
Init_nodes:               All potential masters
Installed_nodes:          <All>
Failover:                  True
Pkglist:                   SUNWscsmf 
RT_system:                 False
Global_zone:				   False
例 2–49 SMF プロキシマルチマスターアプリケーションリソースの作成とリソースグループへの追加

次の例に、マルチマスタープロキシリソースタイプ SUN.Proxy_SMF_multimaster の作成とリソースグループ resource-group-1 への追加を示します。


# clresourcegroup create\
-p Maximum_primaries=2\
-p Desired_primaries=2\
-n phys-schost-1, phys-schost-2\
resource-group-1
# clresourcegroup show resource-group-1

=== Resource Groups and Resources ===          

Resource Group:                        resource-group-1
RG_description:                        <NULL>
RG_mode:                               multimastered
RG_state:                              Unmanaged
RG_project_name:                       default
RG_affinities:                         <NULL>
Auto_start_on_new_cluster:             True
Failback:                              False
Nodelist:                              phys-schost-1 phys-schost-2
Maximum_primaries:                      2
Desired_primaries:                      2
Implicit_network_dependencies:         True
Global_resources_used:                 <All>
Pingpong_interval:                      3600
Pathprefix:                            <NULL>
RG_System:                             False
Suspend_automatic_recovery:                      False
 

# clresource create -g resource-group-1 -t SUNW.Proxy_SMF_multimaster
-x proxied_service_instances=/var/tmp/svslist.txt resource-1
# clresource show resource-1

=== Resources ===

  Resource:                               resource-1
  Type:                                  SUNW.Proxy_SMF_multimaster
  Type_version:                          3.2 
  Group:                                 resource-group-1
  R_description:                         
  Resource_project_name:                 default
  Enabled{phats1}:                       True 
  Monitored{phats1}:                     True

ProcedureSMF サービスのスケーラブルプロキシリソース構成へのカプセル化

スケーラブル構成の詳細については、「スケーラブルリソースグループを作成する」を参照してください。

注 –

この手順は、任意のクラスタノードから実行します。

  1. クラスタメンバーで、スーパーユーザーになるか、solaris.cluster.modify RBAC の承認を提供する役割になります。

  2. SMF プロキシスケーラブルリソースタイプを登録します。


    # clresourcetype register -f\
/opt/SUNWscsmf/etc/SUNW.Proxy_SMF_scalable SUNW.Proxy_SMF_scalable

  3. スケーラブルリソースグループが使用する共有アドレスを保持する SMF フェイルオーバーリソースグループを作成します。フェイルオーバーリソースグループの作成については、「フェイルオーバーリソースグループを作成する」を参照してください。

  4. SMF プロキシスケーラブルリソースグループを作成します。


    # clresourcegroup create\-p Maximum_primaries=m\-p Desired_primaries=n\
-p RG_dependencies=depend-resource-group\
[-n node-zone-list]\
resource-group
    -p Maximum_primaries=m

    このリソースグループのアクティブな主ノードの最大数を指定します。

    -p Desired_primaries=n

    リソースグループが起動するアクティブな主ノードの数を指定します。

    -p RG_dependencies=depend-resource-group

    作成されるリソースグループが依存する共有アドレスリソースを含むリソースグループを指定します。

    -n node-zone-list

    このリソースグループが使用可能となる、コンマ区切りの順序付けられたリストを指定します。リスト内の各エントリの形式は node:zone です。この形式では、 node はノード名を指定し、zone は非大域 Solaris ゾーンの名前を指定します。大域ゾーンを指定する、または非大域ゾーンを持たないノードを指定するには、node のみを指定します。

    このリストはオプションです。このリストを省略すると、クラス内のすべてのノード上でリソースグループが作成されます。

    スケーラブルリソースのノードリストは、共有アドレスリソースのノードリストと同じリストまたは nodename:zonename ペアのサブセットを含むことができます。

    resource-group

    追加するスケーラブルリソースグループの名前を指定します。任意の名前の先頭文字は ASCII にする必要があります。

  5. スケーラブルリソースグループが作成されていることを確認します。


    # clresourcegroup show resource-group

  6. SMF プロキシスケーラブルリソースをリソースグループに追加します。


    # clresource create-g resource-group -t SUNW.Proxy_SMF_scalable \
-p Network_resources_used=network-resource[,network-resource...] \
-p Scalable=True
[-p "extension-property[{node-specifier}]"=value, …] [-p standard-property=value, …] resource
    -g resource-group

    以前に作成したスケーラブルサービスリソースグループの名前を指定します。

    -p Network_resources_used= network-resource[,network-resource...]

    このリソースが依存するネットワークリソース (共有アドレス) のリストを指定します。

    -p Scalable=True

    このリソースがスケーラブルであることを指定します。

    -p "extension-property[{node-specifier}]"=value, …

    リソースの拡張プロパティーを設定していることを指定します。どの拡張プロパティーを設定するかを決定するには、リソースタイプのマニュアルを参照してください。

    node-specifier は、-p オプションおよび -x オプションに対する「オプション」の修飾子です。この修飾子は、指定された 1 つまたは複数のノードまたはゾーン上でのみ、1 つまたは複数の拡張プロパティーがリソースの作成時に設定されることを示します。指定した拡張プロパティーは、クラスタ内のほかのノードまたはゾーン上では、設定されません。node-specifier を指定しないと、クラスタ内のすべてのノードおよびゾーン上の指定された拡張プロパティーが設定されます。node-specifier にはノード名またはノード識別子を指定できます。node-specifier の構文例を次に示します。


    -p "myprop{phys-schost-1}"

    中括弧 ({}) は、指定した拡張プロパティーをノード phys-schost-1 でのみ設定することを示します。大部分のシェルでは、二重引用符 (") が必要です。

    また次の構文を使用して、2 つの異なるノード上の 2 つの異なるゾーン内で拡張プロパティーを設定することもできます。


    -x "myprop{phys-schost-1:zoneA,phys-schost-2:zoneB}"
    -p standard-property=value, …

    リソース用に設定する標準プロパティーのコンマ区切りリストを指定します。設定できる標準プロパティーはリソースタイプに依存します。スケーラブルサービスの場合、通常は Port_list、Load_balancing_weights、および Load_balancing_policy プロパティーを設定します。どの標準プロパティーを設定するかを決定するには、リソースタイプのマニュアルと付録 B 「標準プロパティー」を参照してください。

    resource

    追加するリソースの名前を指定します。

    リソースは有効状態で作成されます。

  7. SMF プロキシスケーラブルアプリケーションリソースが追加され、妥当性が検査されていることを確認します。


    # clresource show resource

  8. SMF プロキシスケーラブルリソースグループをオンラインにします。


    # clresourcegroup online -M +
例 2–50 SMF プロキシスケーラブルリソースタイプの登録

次の例では、SUNW.Proxy_SMF_scalable リソースタイプを登録します。


# clresourcetype register SUNW.Proxy_SMF_scalable
# clresourcetype show SUNW.Proxy_SMF_scalable

Resource Type:           SUNW.Proxy_SMF_scalable
RT_description:          Resource type for proxying scalable SMF services 
RT_version:              3.2
API_version:             6
RT_basedir:              /opt/SUNWscsmf/bin
Single_instance:          False
Proxy:                    False
Init_nodes:               All potential masters
Installed_nodes:          <All>
Failover:                 True
Pkglist:                  SUNWscsmf 
RT_system:                 False
Global_zone:				  False
例 2–51 SMF プロキシスケーラブルアプリケーションリソースの作成とリソースグループへの追加

この例では、スケーラブルプロキシリソースタイプ SUN.Proxy_SMF_scalalble の作成と resource-group-1 への追加を示します。


# clresourcegroup create\
-p Maximum_primaries=2\
-p Desired_primaries=2\
-p RG_dependencies=resource-group-2\
-n phys-schost-1, phys-schost-2\
resource-group-1
# clresourcegroup show resource-group-1

=== Resource Groups and Resources ===          

Resource Group:                      resource-group-1
RG_description:                     <NULL>
RG_mode:                             Scalable
RG_state:                            Unmanaged
RG_project_name:                     default
RG_affinities:                       <NULL>
Auto_start_on_new_cluster:           True
Failback:                            False
Nodelist:                            phys-schost-1 phys-schost-2
Maximum_primaries:                   2
Desired_primaries:                   2
RG_dependencies:                     resource-group2
Implicit_network_dependencies:       True
Global_resources_used:               <All>
Pingpong_interval:                   3600
Pathprefix:                          <NULL>
RG_System:                            False
Suspend_automatic_recovery:           False
 

# clresource create -g resource-group-1 -t SUNW.Proxy_SMF_scalable
-x proxied_service_instances=/var/tmp/svslist.txt resource-1
# clresource show resource-1

=== Resources ===

  Resource:                            resource-1
  Type:                                SUNW.Proxy_SMF_scalable
  Type_version:                        3.2 
  Group:                               resource-group-1
  R_description:                       
  Resource_project_name:               default
  Enabled{phats1}:                     True 
  Monitored{phats1}:                   True

Sun Cluster データサービス用に障害モニターを調整する

Sun Cluster 製品で提供されるデータサービスには、障害モニターが組み込まれています。障害モニターは、次の機能を実行します。

障害モニターは、データサービスが作成されたアプリケーションを表現するリソースに含まれます。このリソースは、データサービスを登録および構成したときに作成します。詳細は、データサービスのマニュアルを参照してください。

障害モニターの動作は、このリソースのシステムプロパティと拡張プロパティによって制御されます。事前に設定された障害モニターの動作は、これらのプロパティーのデフォルト値に基づいています。現在の動作は、ほとんどの Sun Cluster システムに適しているはずです。したがって、障害モニターを調整するのは、事前に設定されたこの動作を変更したい場合「だけに」留めるべきです。

障害モニターを調整するには、次の作業が含まれます。

これらの作業は、データサービスの登録と構成の際に行います。詳細は、データサービスのマニュアルを参照してください。

注 –

リソースの障害モニターは、そのリソースを含むリソースグループをオンラインにしたときに起動されます。障害モニターを明示的に起動する必要はありません。

障害モニターの検証間隔の設定

リソースが正しく動作しているかどうかを判断するには、障害モニターで当該リソースを定期的に検証します。障害モニターの検証間隔は、リソースの可用性とシステムの性能に次のような影響を及ぼします。

さらに、障害モニターの最適な検証間隔は、リソースの障害への対応にどの程度の時間が必要かによって異なります。この時間は、リソースの複雑さが、リソースの再起動などの操作にかかる時間にどのような影響を及ぼすかに依存します。

障害モニターの検証間隔を設定するには、リソースの Thorough_probe_interval システムプロパティーを必要な間隔 (秒単位) に設定します。

障害モニターの検証タイムアウトの設定

障害モニターの検証タイムアウトでは、検証に対するリソースからの応答にどのくらいの時間を許すかを指定します。このタイムアウト内にリソースからの応答がないと、障害モニターは、このリソースに障害があるものとみなします。障害モニターの検証に対するリソースの応答にどの程度の時間がかかるかは、障害モニターがこの検証に使用する操作によって異なります。データサービスの障害モニターがリソースを検証するために実行する操作については、データサービスのマニュアルを参照してください。

リソースの応答に要する時間は、障害モニターやアプリケーションとは関係のない次のような要素にも依存します。

障害モニターの検証タイムアウトを設定する場合は、必要なタイムアウト値をリソースの Probe_timeout 拡張プロパティーに秒単位で指定します。

継続的な障害とみなす基準の定義

一時的な障害による中断を最小限に抑えるために、障害モニターは、このような障害が発生するとこのリソースを再起動します。継続的な障害の場合は、リソースの再起動よりも複雑なアクションをとる必要があります。

障害モニターは、指定された再試行間隔の中で、リソースの完全な障害の回数が、指定されたしきい値を超えると障害を継続的であるとみなします。ユーザーは、継続的な障害とみなす基準を定義することによって、 可用性要件とクラスタの性能特性を満たすしきい値や再試行間隔を設定できます。

リソースの完全な障害と部分的な障害

障害モニターは、いくつかの障害を、リソースの「完全な障害」としてみなします。完全な障害は通常、サービスの完全な損失を引き起こします。次に、完全な障害の例を示します。

完全な障害が発生すると、障害モニターは再試行間隔内の完全な障害の回数を 1 つ増やします。

障害モニターは、それ以外の障害を、リソースの「部分的な障害」とみなします。部分的な障害は完全な障害よりも重大ではなく、通常、サービスの低下を引き起こしますが、サービスの完全な損失は引き起こしません。次に、障害モニターがタイムアウトするまでにデータサービスサーバーからの応答が不完全であるという部分的な障害の例を示します。

部分的な障害が発生すると、障害モニターは再試行間隔内の完全な障害の回数を小数点数だけ増やします。部分的な障害は、再試行間隔を過ぎても累積されます。

部分的な障害の次の特性は、データサービスに依存します。

データサービスの障害モニターが検出する障害については、データサービスのマニュアルを参照してください。

しきい値や再試行間隔と他のプロパティーとの関係

障害のあるリソースが再起動するのに必要な最大時間は、次のプロパティーの値を合計したものです。

再試行回数がしきい値に達しないうちに再試行間隔がきてしまうのを避けるためには、再試行間隔としきい値の値を次の式に従って計算します。

retry_interval >= 2 x threshold × (thorough_probe_interval + probe_timeout)

係数 2 は、ただちにリソースをフェイルオーバーしたりオフラインにすることはない部分的な検証障害を考慮したものです。

しきい値と再試行間隔を設定するシステムプロパティー

しきい値と再試行間隔を設定するには、リソースの次のようなシステムプロパティーを使用します。

リソースのフェイルオーバー動作を指定する

リソースのフェイルオーバー動作は、次の障害に対して RGM がどのように応答するかを決定します。

リソースのフェイルオーバー動作を指定するには、リソースの Failover_mode システムプロパティーを設定します。このプロパティーに指定できる値については、「リソースのプロパティー」における Failover_mode システムプロパティーの説明を参照してください。