Sun Cluster 3.1 データサービスの計画と管理

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

この章では、scrgadm(1M) を使って、クラスタ内のリソースや、リソースグループ、リソースタイプを管理する手順を説明します。手順を実行するその他のツールについては、データサービスリソースを管理するためのツールを参照してください。

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

リソースタイプ、リソースグループ、リソースの概念については、第 1 章「Sun Cluster データサービスの計画」と『Sun Cluster 3.1 の概念』を参照してください。

データサービスリソースの管理

表 2–1 に、データサービスリソースの管理作業を説明している節を示します。

表 2–1 作業マップ: データサービスの管理


作業	参照箇所
リソースタイプを登録する	リソースタイプを登録する
リソースタイプをアップグレードする	既存のリソースを新バージョンのリソースタイプに移行するアップグレードされたリソースタイプをインストールして登録する
フェイルオーバーリソースグループまたはスケーラブルリソースグループの作成	フェイルオーバーリソースグループを作成するスケーラブルリソースグループを作成する
論理ホスト名または共有アドレス、データサービスリソースをリソースグループに追加する	論理ホスト名リソースをリソースグループに追加する共有アドレスリソースをリソースグループに追加するフェイルオーバーアプリケーションリソースをリソースグループに追加するスケーラブルアプリケーションリソースをリソースグループに追加する
リソースとリソースモニターを有効にし、リソースグループを管理し、リソースグループおよび関連するリソースをオンラインにする	リソースグループをオンラインにする
リソース自体とは関係なく、リソースモニターだけを無効または有効にする	リソース障害モニターを無効にするリソース障害モニターを有効にする
クラスタからリソースタイプを削除する	リソースタイプを削除する
クラスタからリソースグループを削除する	リソースグループを削除する
リソースグループからリソースを削除する	リソースを削除する
リソースグループの主ノードを切り替える	リソースグループの主ノードを切り替える
リソースを無効にし、そのリソースグループを非管理状態に移行する	リソースを無効にしてリソースグループを非管理状態に移行する
リソースタイプ、リソースグループ、リソース構成情報を表示する	リソースタイプ、リソースグループ、リソース構成情報を表示する
リソースタイプ、リソースグループ、リソースプロパティの変更	リソースタイププロパティを変更するリソースグループプロパティを変更するリソースプロパティを変更する
失敗した Resource Group Manager (RGM) プロセスのエラーフラグの消去	リソースの `STOP_FAILED` エラーフラグを消去する
組み込みリソースタイプ `LogicalHostname` および `SharedAddress` の再登録	登録済みのリソースタイプを再登録する
ネットワークリソースのネットワークインタフェース ID リストの更新と、リソースグループのノードリストの更新	リソースグループにノードを追加する
リソースグループからノードを削除する	リソースグループからノードを削除する
リソースグループとディスクデバイスグループ間で起動の同期をとるために、リソースグループの `HAStorage` または `HAStoragePlus` を設定する	新しいリソース用に `HAStorage` リソースタイプを設定する
ディスク入出力負荷が高いフェイルオーバーデータサービスに対応するように、`HAStoragePlus` を設定してローカルファイルシステムの可用性を高める	`HAStoragePlus` リソースタイプを設定する
重要なデータサービスのためにノードを自動的に開放するようにリソースタイプを設定する	`RGOffload` リソースを設定する

注 –

この章の各手順では scrgadm(1M) コマンドを使ってこれらの作業を行いますが、これ以外のツールを使ってリソースを管理することもできます。これらの方法については、データサービスリソースを管理するためのツールを参照してください。

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

Sun Cluster の構成は、複数の手順から成る単一の作業です。これらの手順により次の作業を実行できます。

リソースタイプの登録
リソースタイプのアップグレード
リソースグループの作成
リソースグループへのリソースの追加
リソースをオンラインにする

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

リソースタイプの登録

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

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

この手順を実行するには、登録するリソースタイプに、データサービス名の略語で名前をつける必要があります。この名前は、データサービスのライセンス証明書に示されている名前に対応付ける必要があります。名前とライセンス証明書中の名前の対応については『Sun Cluster 3.1 ご使用にあたって』を参照してください。

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

注 –

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

クラスタメンバー上でスーパーユーザーになります。

リソースタイプを登録します。
# scrgadm -a -t resource-type
-a

指定したリソースタイプを追加します。

-t resource-type

追加するリソースタイプの名前を指定します。内部名を決定するには、『Sun Cluster 3.1 ご使用にあたって』を参照してください。

登録されたリソースタイプを確認します。
# scrgadm -pv -t resource-type

例 – リソースタイプの登録

次に、Sun Cluster HA for Sun ONE Web Server (内部名 iws) を登録する例を示します。

# scrgadm -a -t SUNW.iws
# scrgadm -pv -t SUNW.iws
Res Type name:                                   SUNW.iws
  (SUNW.iws) Res Type description:               None registered
  (SUNW.iws) Res Type base directory:            /opt/SUNWschtt/bin
  (SUNW.iws) Res Type single instance:           False
  (SUNW.iws) Res Type init nodes:                All potential masters
  (SUNW.iws) Res Type failover:                  False
  (SUNW.iws) Res Type version:                   1.0
  (SUNW.iws) Res Type API version:               2
  (SUNW.iws) Res Type installed on nodes:        All
  (SUNW.iws) Res Type packages:                  SUNWschtt

次の作業

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

リソースタイプの更新

新バージョンのリソースタイプがリリースされる際には、そのアップグレードされたリソースタイプをインストールして登録できます。また、既存のリソースを新しいリソースタイプバージョンにアップグレードすることも可能です。この節では、次の 2 つの作業、アップグレードされたリソースタイプをインストールして登録する方法と、既存のリソースを新しいリソースタイプバージョンにアップグレードする方法について説明します。

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

この作業は、scsetup の Resource Group オプションを使用しても行えます。scsetup の詳細は、scsetup(1M) のマニュアルページを参照してください。

すべてのクラスタノードに、リソースタイプアップグレードパッケージをインストールします。

注 –
リソースタイプパッケージがどのノードにもインストールされていない場合は、作業が別途必要です (手順 3)。

リソースタイプのアップグレードパッケージをインストールする際にノードを非クラスタモードで起動する必要があるかどうかは、アップグレードドキュメントに示されています。ダウンタイムを避けるには、パッケージをインストールするノードを非クラスタモード、残りのノードをクラスタモードに設定した状態で、一度に 1 台のノードに限定してローリングアップグレード方式で新しいパッケージを追加します。

この新しいリソースタイプバージョンを登録します。
scrgadm -a -t resource_type -f path_to_new_RTR_file
新しいリソースタイプの名前は次の形式をとります。
vendor_id.rtname:version
登録した新しいリソースタイプを表示するには、scrgadm —p または scrgadm —pv (詳細表示) を使用してください。

新しいリソースタイプをインストールしないノードがある場合は、実際にリソースタイプをインストールしたノードを Installed_nodes プロパティに設定します。
scrgadm -c -t resource_type -h installed_node_list

新バージョンのリソースタイプは、次の点で旧バージョンと異なっている可能性があります。

リソースタイププロパティの設定
標準プロパティ、拡張プロパティを含む宣言済みリソースプロパティ
リソースプロパティの属性 (default、min、max、arraymin、arraymax、または tunability)
宣言済みメソッド
メソッドやモニターの実装

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

この作業は、scsetup の Resource Group オプションを使用しても行えます。scsetup の詳細は、scsetup(1M) のマニュアルページを参照してください。

新しいバージョンタイプに移行する方法は、既存のリソースタイプバージョンと、新バージョンにおける変更によって決まります。移行が可能かどうかは、リソースタイプのアップグレードドキュメントに記載されています。移行がサポートされていない場合は、リソースを削除してアップグレードされた新しいリソースに交換するか、あるいはそのリソースを古いリソースタイプバージョンのままにするかを検討してください。

既存のリソースを移行する場合は、以下の値が変化する可能性があります。

デフォルトのプロパティ値

アップグレードされたリソースタイプバージョンがデフォルトプロパティに新しいデフォルト値を宣言している場合は、既存のリソースはこの新しいデフォルト値を継承します。

既存のプロパティ設定が適切かどうかは、新しいリソースタイプバージョンの VALIDATE メソッドによってチェックされます。この設定が不適切な場合は、プロパティを編集して適切な値に変更してください。プロパティの編集方法は、手順 3 を参照してください。

リソースタイプ名

RTR ファイルには、リソースタイプの完全修飾名の形成に使用される以下のプロパティが含まれます。

Vendor_id
Resource_type
RT_Version

アップグレードされたリソースタイプバージョンは、その登録時に vendor_id.rtname:version として保存されます。新バージョンに移行されたリソースには、上記のプロパティから構成される新しい Type プロパティが存在します。

Type_version リソースプロパティ

リソースのタイプの RT_Version プロパティは、標準のリソースプロパティ Type_version に格納されます。Type_Version プロパティは、RTR ファイルには現れません。次のコマンドを使用して Type_Version プロパティを編集してください。

scrgadm -c -j resource -y Type_version=new_version

既存のリソースを新しいリソースタイプバージョンに移行する前に、新しいリソースタイプに付属しているアップグレードマニュアルに目を通し、移行が可能かどうかを確認してください。

このマニュアルには、移行を実施すべきタイミングが記されています。
- 任意の時点
- リソースのマウントが解除されているとき
- リソースがオフラインのとき
- リソースが無効なとき
- リソースグループが管理されていないとき
移行がサポートされていない場合は、リソースを削除してアップグレードされた新しいリソースバージョンに置き換えるか、そのリソースを古いリソースタイプバージョンのままにしておく必要があります。

移行するリソースタイプのリソースごとに、アップグレードマニュアルに記載されている方法でそのリソースグループのリソースの状態を適切な状態に変更してください。次に例を示します。

リソースのマウントを解除する必要がある場合:
scswitch -M -n -j resource
リソースをオフラインにする必要がある場合:
scswitch -n -j resource
リソースを無効にする必要がある場合:
scswitch -n -j resource
リソースグループを非管理状態にする必要がある場合:
scsswitch -n -j resource-group scswitch -F -g resource_group scswitch -u -g resource_group

移行するリソースタイプのリソースごとに、リソースを編集し、その Type_version プロパティを新バージョンに変更します。
scrgadm -c -j resource -y Type_version=new_version \ -x extension_property=new_value -y extension_property=new_value
必要に応じ、-x または -y オプション (あるいはこの両方) を追加して同じコマンドを実行し、同じリソースのほかのプロパティを編集して適切な値に変更します。

手順 2 で入力したコマンドを逆に指定することにより、リソースまたはリソースグループの前の状態に戻します。次に例を示します。

リソースを監視状態に戻す場合:
scswitch -M -e -j resource
リソースを有効な状態に戻す場合:
scswitch -e -j resource
リソースグループをオンラインの管理状態に戻す場合:
scswitch -o -g resource_group scswitch -Z -g resource_group

例 1 – 既存のリソースを新しいリソースタイプバージョンに移行する

この例は、既存のリソースを新しいリソースタイプバージョンに移行する方法を示しています。新しいリソースタイプパッケージのメソッドは、新しいパスに配置されています。インストール時にメソッドは上書きされないため、アップグレードされたリソースタイプのインストールが完了するまでリソースを無効にする必要はありません。

この実例では、次のことを前提としています。

新しいリソースタイプバージョンは 2.0 である
移行を実行すべきタイミングは「リソースがオフラインのとき」である
リソース名は「myresource」である
リソースタイプ名は「myrt」である
新しい RTR ファイルは /opt/XYZmyrt/etc/XYZ.myrt に配置される
移行の対象となるリソースに依存していない
所属しているリソースグループをオンラインの状態にしたまま、移行の対象となるリソースをオフラインに切り替えることができる

(ベンダーの指示に従って全ノードに新しいパッケージをインストールする)
# scrgadm -a -t myrt -f /opt/XYZmyrt/etc/XYZ.myrt
# scswitch -n -j myresource
# scrgadm -c -j myresource -y Type_version=2.0
# scswitch -e -j myresource

例 2 – 既存のリソースを新しいリソースタイプバージョンに移行する

この例は、既存のリソースを新しいリソースタイプバージョンに移行する方法を示しています。新しいリソースタイプパッケージには、モニターと RTR ファイルしか含まれていません。モニターはインストール時に上書きされるため、アップグレードされたリソースタイプをインストールする前にリソースを無効にする必要があります。

この実例では、次のことを前提としています。

新しいリソースタイプバージョンは 2.0 である
移行を実行すべきタイミングは「リソースのマウントが解除しているとき」である
リソース名は「myresource」である
リソースタイプ名は「myrt」である
新しい RTR ファイルは /opt/XYZmyrt/etc/XYZ.myrt に配置される

# scswitch -M -n -j myresource
(ベンダーの指示に従って新しいパッケージをインストールする)
# scrgadm -a -t myrt -f /opt/XYZmyrt/etc/XYZ.myrt
# scrgadm -c -j myresource -y Type_version=2.0
# scswitch -M -e -j myresource

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

古いリソースタイプバージョンにリソースをダウングレードできます。古いリソースタイプバージョンにダウングレードする場合は、新しいリソースタイプバージョンにアップグレードする場合よりも条件が厳しくなります。まず、リソースグループの管理を解除する必要があります。アップグレードが可能なリソースタイプバージョンにしかダウングレードできないということにも注意してください。アップグレードが可能なバージョンは scrgadm -p コマンドを使用して確認できます。アップグレードが可能なバージョンの場合、接尾辞 version が表示されます。

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

リソースを古いリソースタイプバージョンにダウングレードできます。古いリソースタイプバージョンにダウングレードする場合は、新しいリソースタイプバージョンにアップグレードする場合よりも条件が厳しくなります。まず、リソースグループの管理を解除する必要があります。アップグレードが可能なリソースタイプバージョンにしかダウングレードできないということにも注意してください。アップグレードが可能なバージョンは scrgadm -p コマンドを使用して確認できます。アップグレードが可能なバージョンの場合、接尾辞 version が表示されます。

ダウングレードしたいリソースを含んでいるリソースグループをオフラインに切り替えます。
scswitch -F -g resource_group

ダウングレードしたいリソースと、そのリソースグループ内のすべてのリソースを無効にします。
scswitch -n -j resource_to_downgrade scswitch -n -j resource1 scswitch -n -j resource2 scswitch -n -j resource3 ...
注 –
リソースの無効化は、依存性の高いもの (アプリケーションリソース) から開始し、もっとも依存性の低いもの (ネットワークアドレスリソース) で終了するように行なってください。

リソースグループを非管理状態に切り替えます。
scswitch -u -g resource_group

ダウングレードしたいリソースタイプの古いバージョンがクラスタ内にまだ登録されているかどうか確認します。
- 登録されている場合は、次の手順に進みます。
- 登録されていない場合は、希望する旧バージョンを登録し直します。
  scrgadm -a -t resource_type_name

旧バージョンを Type_version に指定し、リソースをダウングレードします。
scrgadm -c -j resource_to_downgrade -y Type_version=old_version
必要に応じて、同じコマンドを使って、同じリソースのその他のプロパティに適切な値を設定します。

ダウングレードしたリソースを含んでいるリソースグループを管理状態に切り替え、すべてのリソースを有効にしたあと、このグループをオンラインに切り替えます。
scswitch -Z -g resource_group

リソースグループの作成

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

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

次の手順では、scrgadm(1M) コマンドを使ってデータサービスの登録と構成を行います。

リソースグループの概念については、第 1 章「Sun Cluster データサービスの計画」と『Sun Cluster 3.1 の概念』を参照してください。

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

フェイルオーバーリソースグループは、ネットワークアドレス (組み込みリソースタイプの LogicalHostname や SharedAddress など) と、フェイルオーバーリソース (フェイルオーバーデータサービスのためのデータサービスアプリケーションリソースなど) を含みます。ネットワークリソースは、データサービスがフェイルオーバーまたはスイッチオーバーする場合に、依存するデータサービスリソースと共に、クラスタノード間を移動します。

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

注 –

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

クラスタメンバー上でスーパーユーザーになります。

フェイルオーバーリソースグループを作成します。
# scrgadm -a -g resource-group [-h nodelist]
-a

指定したリソースグループを追加します。

-g resource-group

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

-h nodelist

このリソースグループをマスターできるノードの順位リストを指定します (省略可能)。このリストを指定しない場合は、デフォルトでクラスタ内のすべてのノードになります。

リソースグループが作成されていることを確認します。
# scrgadm -pv -g resource-group

例 – フェイルオーバーリソースグループの作成

次に、 2 つのノード (phys-schost-1、phys-schost-2) でマスターできるフェイルオーバーリソースグループ (resource-group-1) を追加する例を示します。

# scrgadm -a -g resource-group-1 -h phys-schost1,phys-schost-2
# scrgadm -pv -g resource-group-1
Res Group name:                                          resource-group-1
  (resource-group-1) Res Group RG_description:           <NULL>
  (resource-group-1) Res Group management state:         Unmanaged
  (resource-group-1) Res Group Failback:                 False
  (resource-group-1) Res Group Nodelist:                 phys-schost-1  
                                                         phys-schost-2
  (resource-group-1) Res Group Maximum_primaries:        1
  (resource-group-1) Res Group Desired_primaries:        1
  (resource-group-1) Res Group RG_dependencies:          <NULL>
  (resource-group-1) Res Group mode:                     Failover
  (resource-group-1) Res Group network dependencies:     True
  (resource-group-1) Res Group Global_resources_used:    All
  (resource-group-1) Res Group Pathprefix:

次の作業

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

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

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

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

注 –

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

クラスタメンバー上でスーパーユーザーになります。

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

スケーラブルリソースグループを作成します。
# scrgadm -a -g resource-group \ -y Maximum_primaries=m \ -y Desired_primaries=n \ -y RG_dependencies=depend-resource-group \ -h nodelist]
-a

スケーラブルリソースグループを追加します。

-g resource-group

追加するスケーラブルリソースグループの名前を指定します。

-y Maximum_primaries =m

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

-y Desired_primaries =n

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

-y RG_dependencies =depend-resource-group

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

-h nodelist

リソースグループを利用できるノードのリストを指定します (省略可能)。このリストを指定しない場合は、デフォルトですべてのノードになります。

スケーラブルリソースグループが作成されていることを確認します。
# scrgadm -pv -g resource-group

例 – スケーラブルリソースグループの作成

次に、2 つのノード (phys-schost-1、phys-schost-2) でホストされるスケーラブルリソースグループ (resource-group-1) を追加する例を示します。スケーラブルリソースグループは、共有アドレスを含むフェイルオーバーリソースグループ (resource-group-2) に依存します。

# scrgadm -a -g resource-group-1 \
-y Maximum_primaries=2 \
-y Desired_primaries=2 \
-y RG_dependencies=resource-group-2 \
-h phys-schost-1,phys-schost-2
# scrgadm -pv -g resource-group-1
Res Group name:                                          resource-group-1
  (resource-group-1) Res Group RG_description:           <NULL>
  (resource-group-1) Res Group management state:         Unmanaged
  (resource-group-1) Res Group Failback:                 False
  (resource-group-1) Res Group Nodelist:                 phys-schost-1
                                                         phys-schost-2
  (resource-group-1) Res Group Maximum_primaries:        2
  (resource-group-1) Res Group Desired_primaries:        2
  (resource-group-1) Res Group RG_dependencies:          resource-group-2
  (resource-group-1) Res Group mode:                     Scalable
  (resource-group-1) Res Group network dependencies:     True
  (resource-group-1) Res Group Global_resources_used:    All
  (resource-group-1) Res Group Pathprefix:

次の作業

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

リソースグループへのリソースの追加

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

論理ホスト名リソース。
共有アドレスリソース。
データサービス (アプリケーション) リソース。

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

リソースについての詳細は、『Sun Cluster 3.1 の概念』と、このマニュアルの第 1 章「Sun Cluster データサービスの計画」を参照してください。

論理ホスト名リソースをリソースグループに追加する

この手順を実行するには、次の情報が必要になります。

リソースを追加するフェイルオーバーリソースグループの名前
リソースグループに追加するホスト名

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

注 –

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

クラスタメンバー上でスーパーユーザーになります。

論理ホスト名リソースをリソースグループに追加します。
# scrgadm -a -L [-j resource] -g resource-group -l hostnamelist, … [-n netiflist]
-a

論理ホスト名リソースを追加します。

-L

論理ホスト名リソースの形式を指定します。

-j resource

リソース名を指定します (省略可能)。このオプションを指定しない場合は、デフォルトで -l オプションで最初に指定したホスト名になります。

-g resource-group

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

-l hostnamelist, …

クライアントがリソースグループでサービスと通信する UNIX ホスト名 (論理ホスト名) をコマンドで区切って指定します。

-n netiflist

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

注 –
Sun Cluster では、現在、netif にアダプタ名を使用することはできません。

論理ホスト名リソースが追加されていることを確認します。
# scrgadm -pv -j resource
リソースを追加すると、Sun Cluster ソフトウェアは、そのリソースの妥当性を検査します。妥当性が確認されると、そのリソースを有効にできるとともに、そのリソースグループを RGM の管理下に置くことができます。妥当性の検査に失敗すると、scrgadm コマンドはエラーメッセージを生成して終了します。妥当性の検査に失敗に失敗した場合は、エラーメッセージについて各ノード上の syslog を調べてください。メッセージは、妥当性の検査を実施したノードで表示されます。必ずしも scrgadm コマンドを実行したノードで表示されるわけではありません。

例 – 論理ホスト名リソースのリソースグループへの追加

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

# scrgadm -a -L -j resource-1 -g resource-group-1 -l schost-1
# scrgadm -pv -j resource-1
Res Group name: resource-group-1
(resource-group-1) Res name:                              resource-1
  (resource-group-1:resource-1) Res R_description:
  (resource-group-1:resource-1) Res resource type:        SUNW.LogicalHostname
  (resource-group-1:resource-1) Res resource group name:  resource-group-1
  (resource-group-1:resource-1) Res enabled:              False
  (resource-group-1:resource-1) Res monitor enabled:      True

次の作業

論理ホスト名リソースを追加したあと、リソースグループをオンラインにするの手順に従って、このリソースをオンラインにします。

共有アドレスリソースをリソースグループに追加する

この手順を実行するには、次の情報が必要になります。

リソースを追加するリソースグループの名前。このグループは、前の手順で作成したフェイルオーバーリソースグループでなければなりません。
リソースグループに追加するホスト名。

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

注 –

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

クラスタメンバー上でスーパーユーザーになります。

共有アドレスリソースをリソースグループに追加します。
# scrgadm -a -S [-j resource] -g resource-group -l hostnamelist, … \ [-X auxnodelist] [-n netiflist]
-a

共有アドレスリソースを追加します。

-S

共有アドレスリソースの形式を指定します。

-j resource

リソース名を指定します (省略可能)。このオプションを指定しない場合は、デフォルトで -l オプションで最初に指定したホスト名になります。

-g resource-group

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

-l hostnamelist, …

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

-X auxnodelist

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

-n netiflist

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

注 –
Sun Cluster では、現在、netif にアダプタ名を使用することはできません。

共有アドレスリソースが追加され、妥当性が検査されていることを確認します。
# scrgadm -pv -j resource
リソースを追加すると、Sun Cluster ソフトウェアは、そのリソースの妥当性を検査します。妥当性が確認されると、そのリソースを有効にできるとともに、そのリソースグループを RGM の管理下に置くことができます。妥当性の検査に失敗すると、scrgadm コマンドはエラーメッセージを生成して終了します。妥当性の検査に失敗に失敗した場合は、エラーメッセージについて各ノード上の syslog を調べてください。メッセージは、妥当性の検査を実施したノードで表示されます。必ずしも scrgadm コマンドを実行したノードで表示されるわけではありません。

例 – 共有アドレスリソースのリソースグループへの追加

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

# scrgadm -a -S -j resource-1 -g resource-group-1 -l schost-1
# scrgadm -pv -j resource-1
(resource-group-1) Res name:                                resource-1
    (resource-group-1:resource-1) Res R_description:
    (resource-group-1:resource-1) Res resource type:        SUNW.SharedAddress
    (resource-group-1:resource-1) Res resource group name:  resource-group-1
    (resource-group-1:resource-1) Res enabled:              False
    (resource-group-1:resource-1) Res monitor enabled:      True

次の作業

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

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

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

この手順を実行するには、次の情報が必要になります。

リソースを追加するフェイルオーバーリソースグループの名前
リソースが属するリソースタイプの名前
アプリケーションリソースが使用する論理ホスト名リソース。これは、以前に同じリソースグループに含めた論理ホスト名になります。

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

注 –

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

クラスタメンバー上でスーパーユーザーになります。

フェイルオーバーアプリケーションリソースをリソースグループに追加します。
# scrgadm -a -j resource -g resource-group -t resource-type \ [-x Extension_property=value, …] [-y Standard_property=value, …]
-a

リソースを追加します。

-j resource

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

-g resource-group

以前に作成したフェイルオーバーリソースグループの名前を指定します。

-t resource-type

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

-x Extension_property =value, …

特定のデータサービスに依存する拡張プロパティをコンマで区切って指定します。データサービスがこのプロパティの指定が必要かどうかについては、各データサービスについて説明している章を参照してください。

-y Standard_property =value, …

特定のデータサービスに依存する標準プロパティをコンマで区切って指定します。データサービスがこのプロパティの指定が必要かどうかについては、各データサービスについて説明している章と付録 A 「標準プロパティ」を参照してください。

注 –
別のプロパティを設定することもできます。詳細は、付録 A 「標準プロパティ」とこのマニュアルのフェイルオーバーデータサービスのインストールと構成に関する各章を参照してください。

フェイルオーバーアプリケーションリソースが追加され、妥当性が検査されていることを確認します。
# scrgadm -pv -j resource
リソースを追加すると、Sun Cluster ソフトウェアは、そのリソースの妥当性を検査します。妥当性が確認されると、そのリソースを有効にできるとともに、そのリソースグループを RGM の管理下に置くことができます。妥当性の検査に失敗すると、scrgadm コマンドはエラーメッセージを生成して終了します。妥当性の検査に失敗に失敗した場合は、エラーメッセージについて各ノード上の syslog を調べてください。メッセージは、妥当性の検査を実施したノードで表示されます。必ずしも scrgadm コマンドを実行したノードで表示されるわけではありません。

例 – フェイルオーバーアプリケーションリソースのリソースグループへの追加

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

# scrgadm -a -j resource-1 -g resource-group-1 -t resource-type-1 \
-y Network_resources_used=schost-1,schost2 \
# scrgadm -pv -j resource-1
(resource-group-1) Res name:                                resource-1
    (resource-group-1:resource-1) Res R_description:
    (resource-group-1:resource-1) Res resource type:        resource-type-1
    (resource-group-1:resource-1) Res resource group name:  resource-group-1
    (resource-group-1:resource-1) Res enabled:              False
    (resource-group-1:resource-1) Res monitor enabled:      True

次の作業

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

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

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

この手順を実行するには、次の情報が必要になります。

リソースを追加するスケーラブルリソースグループの名前
リソースが属するリソースタイプの名前
スケーラブルサービスリソースが使用する共有アドレスリソース。これは、以前にフェイルオーバーリソースグループに含めた共有アドレスになります。

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

注 –

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

クラスタメンバー上でスーパーユーザーになります。

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

# scrgadm -a -j resource -g resource-group -t resource-type \
-y Network_resources_used=network-resource[,network-resource...] \
-y Scalable=True
[-x Extension_property=value, …] [-y Standard_property=value, …]

-a: リソースを追加します。
-j resource: 追加するリソースの名前を指定します。
-g resource-group: 以前に作成したスケーラブルサービスリソースグループの名前を指定します。
-t resource-type: このリソースが属するリソースタイプの名前を指定します。
-y Network_resources_used = network-resource[,network-resource ...]: このリソースが依存するネットワークリソース (共有アドレス) のリストを指定します。
-y Scalable =True: このリソースがスケーラブルであることを指定します。
-x Extension_property =value, …: 特定のデータサービスに依存する拡張プロパティをコンマで区切って指定します。データサービスがこのプロパティの指定が必要かどうかについては、各データサービスについて説明している章を参照してください。
-y Standard_property =value, …: 特定のデータサービスに依存する標準プロパティをコンマで区切って指定します。データサービスがこのプロパティの指定が必要かどうかについては、各データサービスについて説明している章と付録 A 「標準プロパティ」を参照してください。
-y Standard_property =value, …: 特定のデータサービスに依存する標準プロパティをコンマで区切って指定します。データサービスがこのプロパティの指定が必要かどうかについては、各データサービスについて説明している章と付録 A 「標準プロパティ」を参照してください。

注 –

別のプロパティを設定することもできます。構成可能なほかのプロパティについては、付録 A 「標準プロパティ」とこのマニュアルのスケーラブルデータサービスのインストールと構成に関する各章を参照してください。スケーラブルサービスの場合は、通常、Port_list、Load_balancing_weights、Load_balancing_policy プロパティを設定します (付録 A 「標準プロパティ」を参照)。

スケーラブルアプリケーションリソースが追加され、妥当性が検査されていることを確認します。
# scrgadm -pv -j resource
リソースを追加すると、Sun Cluster ソフトウェアは、そのリソースの妥当性を検査します。妥当性が確認されると、そのリソースを有効にできるとともに、そのリソースグループを RGM の管理下に置くことができます。妥当性の検査に失敗すると、scrgadm コマンドはエラーメッセージを生成して終了します。妥当性の検査に失敗に失敗した場合は、エラーメッセージについて各ノード上の syslog を調べてください。メッセージは、妥当性の検査を実施したノードで表示されます。必ずしも scrgadm コマンドを実行したノードで表示されるわけではありません。

例 – スケーラブルアプリケーションリソースのリソースグループへの追加

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

# scrgadm -a -j resource-1 -g resource-group-1 -t resource-type-1 \
-y Network_resources_used=schost-1,schost-2 \
-y Scalable=True
# scrgadm -pv -j resource-1
(resource-group-1) Res name:                                resource-1
    (resource-group-1:resource-1) Res R_description:
    (resource-group-1:resource-1) Res resource type:        resource-type-1
    (resource-group-1:resource-1) Res resource group name:  resource-group-1
    (resource-group-1:resource-1) Res enabled:              False
    (resource-group-1:resource-1) Res monitor enabled:      True

次の作業

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

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

リソースが HA サービスの提供を開始できるようにするには、リソースグループのリソースおよびリソースモニターを有効にし、リソースグループを管理状態にし、リソースグループをオンラインにする必要があります。これらの作業は個々に実行できますが、次に示すように 1 つの手順で実行することもできます。詳細は、scswitch(1M) のマニュアルページを参照してください。

注 –

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

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

クラスタメンバー上でスーパーユーザーになります。

リソースを有効にし、リソースグループをオンラインにします。

リソースモニターを無効にしている場合は、これも有効になります。
# scswitch -Z -g resource-group
-Z

最初にリソースグループとそのモニターを有効にし、リソースグループをオンラインにします。

-g resource-group

オンラインにするリソースグループの名前を指定します。既存のリソースグループを指定する必要があります。

リソースがオンラインになっていることを確認します。

任意のクラスタノードで次のコマンドを実行し、Resource Group State のフィールドを調べ、ノードリストで指定されたノードでリソースグループがオンラインになっていることを確認します。
# scstat -g

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

次に、リソースグループ (resource-group-1) をオンラインにし、その状態を確認する例を示します。

# scswitch -Z -g resource-group-1
# scstat -g

次の作業

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

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

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

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

注 –

この手順は任意のノードから実行できます。

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

クラスタメンバー上でスーパーユーザーになります。

リソース障害モニターを無効にします。
# scswitch -n -M -j resource
-n

リソースまたはリソースモニターを無効にします。

-M

指定されたリソースの障害モニターを無効にします。

-j resource

リソースの名前

リソース障害モニターが無効になっていることを確認します。

各クラスタノードで次のコマンドを実行し、監視されるフィールド (RS Monitored) を確認します。
# scrgadm -pv

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

この例では、リソース障害モニターを無効にします。

# scswitch -n -M -j resource-1
# scrgadm -pv
...
RS Monitored: no...

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

クラスタメンバー上でスーパーユーザーになります。

リソース障害モニターを有効にします。
# scswitch -e -M -j resource
-e

リソースまたはリソースモニターを有効にします。

-M

指定されたリソースの障害モニターを有効にします。

-j resource

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

リソース障害モニターが有効になっていることを確認します。

各クラスタノードで次のコマンドを実行し、監視されるフィールド (RS Monitored) を確認します。
# scrgadm -pv

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

この例では、リソース障害モニターを有効にします。

# scswitch -e -M -j resource-1
# scrgadm -pv
...
RS Monitored: yes...

リソースタイプの削除

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

詳細は、scrgadm(1M) および scswitch(1M) のマニュアルページを参照してください。

注 –

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

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

リソースタイプを削除する前に、クラスタ内のすべてのリソースグループにある、そのタイプのリソースをすべて無効にし、削除する必要があります。scrgadm -pv コマンドを使用し、クラスタ内のリソースとリソースグループを確認します。

クラスタメンバー上でスーパーユーザーになります。

削除するリソースタイプの各リソースを無効にします。
# scswitch -n -j resource
-n

リソースを無効にします。

-j resource

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

削除するリソースタイプの各リソースを削除します。
# scrgadm -r -j resource
-r

指定したリソースを削除します。

-j

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

リソースタイプを削除します。
# scrgadm -r -t resource-type
-r

指定したリソースタイプを削除します。

-t resource-type

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

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

例 – リソースタイプの削除

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

# scswitch -n -j resource-1
# scrgadm -r -j resource-1
# scrgadm -r -t resource-type-1

リソースグループの削除

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

詳細は、scrgadm(1M) および scswitch(1M) のマニュアルページを参照してください。

注 –

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

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

クラスタメンバー上でスーパーユーザーになります。

次のコマンドを実行し、リソースグループをオフラインに切り替えます。
# scswitch -F -g resource-group
-F

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

-g resource-group

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

リソースグループに含まれているすべてのリソースを無効にします。

scrgadm -pv コマンドを使用し、リソースグループ内のリソースを表示できます。リソースグループ内の削除するすべてのリソースを無効にします。
# scswitch -n -j resource
-n

リソースを無効にします。

-j resource

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

依存性のあるデータサービスリソースがリソースグループに存在する場合、そのリソースを無効にするには、依存するすべてのリソースを無効にする必要があります。

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

scrgadm コマンドを使用して次の操作を行います。
- リソースの削除
- リソースグループの削除
# scrgadm -r -j resource # scrgadm -r -g resource-group
-r

指定したリソースやリソースグループを削除します。

-j resource

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

-g resource-group

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

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

例 — リソースグループの削除

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

# scswitch -F -g resource-group-1
# scrgadm -r -j resource-1
# scrgadm -r -g resource-group-1

リソースの削除

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

詳細は、scrgadm(1M) および scswitch(1M) のマニュアルページを参照してください。

注 –

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

リソースを削除する

クラスタメンバー上でスーパーユーザーになります。

削除するリソースを無効にします。
# scswitch -n -j resource
-n

リソースを無効にします。

-j resource

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

リソースを削除します。
# scrgadm -r -j resource
-r

指定したリソースを削除します。

-j resource

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

リソースが削除されていることを確認します。
# scrgadm -p

例 – リソースの削除

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

# scswitch -n -j resource-1
# scrgadm -r -j resource-1

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

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

詳細は、scrgadm(1M) および scswitch(1M) のマニュアルページを参照してください。

注 –

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

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

この手順を実行するには、次の情報が必要になります。

スイッチオーバーするリソースグループの名前
リソースグループをオンラインにする、またはオンラインを維持するノードの名前。スイッチオーバーを行うリソースグループの、潜在的マスターとして設定されているクラスタノードを指定する必要があります。リソースグループの潜在的主ノードの一覧を表示するには、scrgadm -pv コマンドを使用します。

クラスタメンバー上でスーパーユーザーになります。

主ノードを潜在的主ノードに切り替えます。
# scswitch -z -g resource-group -h nodelist
-z

指定したリソースグループをオンラインに切り替えます。

-g resource-group

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

-h nodelist

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

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

次のコマンドを実行し、スイッチオーバーされたリソースグループの状態に関する出力を調べます。
# scstat -g

例 – リソースグループを新しい主ノードに切り替える

次に、リソースグループ (resource-group-1) を現在の主ノード (phys-schost-1) から、潜在的主ノード (phys-schost-2) へ切り替える例を示します。まず、リソースグループが phys-schost-1 でオンラインになっていることを確認します。続いて、切り替えを行います。最後に、そのグループが phys-schost-2 でオンラインに切り替えられたことを確認します。

phys-schost-1# scstat -g
...
Resource Group Name:          resource-group-1
  Status                                           
    Node Name:                phys-schost-1
    Status:                   Online

    Node Name:                phys-schost-2
    Status:                   Offline
...
phys-schost-1# scswitch -z -g resource-group-1 -h phys-schost-2
phys-schost-1# scstat -g
...
Resource Group Name:          resource-group-1
  Status                                           
    Node Name:                phys-schost-2
    Status:                   Online

    Node Name:                phys-schost-1
    Status:                   Offline
...

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

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

詳細は、scrgadm(1M) および scswitch(1M) のマニュアルページを参照してください。

注 –

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

リソースを無効にしてリソースグループを非管理状態に移行する

この手順を実行するには、次の情報が必要になります。

無効にするリソースの名前
非管理状態に移行するリソースグループの名前

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

クラスタメンバー上でスーパーユーザーになります。

リソースを無効にします。

この手順を、リソースグループ内のすべてのリソースに対して実行します。
# scswitch -n -j resource
-n

リソースを無効にします。

-j resource

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

次のコマンドを実行し、リソースグループをオフラインに切り替えます。
# scswitch -F -g resource-group
-F

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

-g resource-group

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

リソースグループを非管理状態にします。
# scswitch -u -g resource-group
-u

指定したリソースグループを非管理状態にします。

-g resource-group

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

リソースが無効になり、リソースグループが非管理状態になっていることを確認します。
# scrgadm -pv -g resource-group

例 – リソースの無効化とリソースグループの非管理状態への移行

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

# scswitch -n -j resource-1
# scswitch -F -g resource-group-1
# scswitch -u -g resource-group-1
# scrgadm -pv -g resource-group-1
Res Group name:                                               resource-group-1
  (resource-group-1) Res Group RG_description:                <NULL>
  (resource-group-1) Res Group management state:              Unmanaged
  (resource-group-1) Res Group Failback:                      False
  (resource-group-1) Res Group Nodelist:                      phys-schost-1
                                                              phys-schost-2
  (resource-group-1) Res Group Maximum_primaries:             2
  (resource-group-1) Res Group Desired_primaries:             2
  (resource-group-1) Res Group RG_dependencies:               <NULL>
  (resource-group-1) Res Group mode:                          Failover
  (resource-group-1) Res Group network dependencies:          True
  (resource-group-1) Res Group Global_resources_used:         All
  (resource-group-1) Res Group Pathprefix:
 
  (resource-group-1) Res name:                                resource-1
    (resource-group-1:resource-1) Res R_description:
    (resource-group-1:resource-1) Res resource type:          SUNW.apache
    (resource-group-1:resource-1) Res resource group name:    resource-group-1
    (resource-group-1:resource-1) Res enabled:                True
    (resource-group-1:resource-1) Res monitor enabled:        False
    (resource-group-1:resource-1) Res detached:               False

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

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

詳細は、scrgadm(1M) および scswitch(1M) のマニュアルページを参照してください。

注 –

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

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

scrgadm コマンドは、構成状態に関する次の 3 つのレベルの情報を表示します。

--p オプションを指定した場合は、リソースタイプ、リソースグループ、リソースのプロパティ値に関する最小限の情報が表示されます。

-pv オプションを指定した場合は、ほかのリソースタイプ、リソースグループ、リソースプロパティに関する詳細が表示されます。

-pvv オプションを指定した場合は、リソースタイプメソッド、拡張プロパティ、すべてのリソースとリソースグループのプロパティを含む、詳細情報が表示されます。

また、表示したいオブジェクトの名前の後に -t (リソースタイプ)、-g (リソースグループ)、および -j (リソース) オプションを指定することによって、特定のリソースタイプ、リソースグループ、またはリソースのステータス情報を確認できます。たとえば、次のコマンドは、リソース apache-1 のみについて、特定の情報を表示することを指定します。

# scrgadm -p[v[v]] -j apache-1

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

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

リソースグループとリソースは、変更可能な標準の構成プロパティを持っています。次の各手順では、これらのプロパティの変更方法を説明します。

リソースは、拡張プロパティも持っており、一部の拡張プロパティはデータサービス開発者によってあらかじめ定義されているため、変更することができません。各データサービスの拡張プロパティの一覧については、このマニュアルのデータサービスに関する各章を参照してください。

リソースグループとリソースの標準の構成プロパティについては、scrgadm(1M) のマニュアルページを参照してください。

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

この手順を実行するには、次の情報が必要になります。

変更するリソースタイプの名前
変更するリソースタイププロパティの名前。リソースタイプの場合、変更できるのは 1 つのプロパティのみです。つまり、このリソースタイプをインスタンス化できるノードのリストのみです。

注 –

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

クラスタメンバー上でスーパーユーザーになります。

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

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

リソースタイプで変更できる唯一のプロパティは、Installed_node_list です。
# scrgadm -c -t resource-type -h installed-node-list
-c

指定したリソースタイププロパティを変更します。

-t resource-type

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

-h installed-node-list

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

リソースタイププロパティが変更されていることを確認します。
# scrgadm -pv -t resource-type

例 – リソースタイププロパティの変更

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

# scrgadm -c -t SUNW.apache -h phys-schost-1,phys-schost-2 
# scrgadm -pv -t SUNW.apache
Res Type name:                               SUNW.apache
  (SUNW.apache) Res Type description:        Apache Resource Type
  (SUNW.apache) Res Type base directory:     /opt/SUNWscapc/bin
  (SUNW.apache) Res Type single instance:    False
  (SUNW.apache) Res Type init nodes:         All potential masters
  (SUNW.apache) Res Type failover:           False
  (SUNW.apache) Res Type version:            1.0
  (SUNW.apache) Res Type API version:        2
  (SUNW.apache) Res Type installed on nodes: phys-schost1 phys-schost-2
  (SUNW.apache) Res Type packages:           SUNWscapc

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

この手順を実行するには、次の情報が必要になります。

変更するリソースグループの名前
変更するリソースグループプロパティの名前とその新しいプロパティ値

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

注 –

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

クラスタメンバー上でスーパーユーザーになります。

リソースグループプロパティを変更します。
# scrgadm -c -g resource-group -y property=new_value
-c

指定したプロパティを変更します。

-g resource-group

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

-y property

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

リソースグループプロパティが変更されていることを確認します。
# scrgadm -pv -g resource-group

例 – リソースグループプロパティの変更

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

# scrgadm -c -g resource-group-1 -y Failback=True
# scrgadm -pv -g resource-group-1

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

この手順を実行するには、次の情報が必要になります。

変更するプロパティを持つリソースの名前
変更するプロパティの名前

この手順は、リソースプロパティの変更方法について説明しています。リソースグループプロパティの一覧については、付録 A 「標準プロパティ」を参照してください。

注 –

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

クラスタメンバー上でスーパーユーザーになります。

scrgadm -pvv コマンドを実行し、現在のリソースプロパティ設定を表示します。
# scrgadm -pvv -j resource

リソースプロパティを変更します。
# scrgadm -c -j resource -y property=new_value | -x extension_property=new_value
-c

指定したプロパティを変更します。

-j resource

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

-y property =new_value

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

-x extension_property =new_value

変更する拡張プロパティの名前を指定します。Sun が提供するデータサービスについては、データサービスのインストールと構成に関する各章で説明されている拡張プロパティを参照してください。

リソースプロパティが変更されていることを確認します。
# scrgadm pvv -j resource

例 – 標準リソースプロパティの変更

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

# scrgadm -c -j resource-1 -y start_timeout=30
# scrgadm -pvv -j resource-1

例 – 拡張リソースプロパティの変更

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

# scrgadm -c -j resource-1 -x Log_level=3
# scrgadm -pvv -j resource-1

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

Failover_mode リソースプロパティが NONE または SOFT に設定されているときに、リソースの STOP に失敗した場合は、個々のリソースは STOP_FAILED 状態になり、リソースグループは ERROR_STOP_FAILED 状態になります。この状態のリソースグループは、ノード上でオンラインにできません。また、リソースの作成や削除、リソースグループやリソースプロパティの変更などの編集操作を行うこともできません。

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

この手順を実行するには、次の情報が必要になります。

リソースが STOP_FAILED であるノードの名前
STOP_FAILED 状態になっているリソースとリソースグループの名前

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

注 –

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

クラスタメンバー上でスーパーユーザーになります。

STOP_FAILED 状態のリソースと、どのノードでこの状態なのかを確認します。
# scstat -g

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

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

リソースを手作業で停止したすべてのノード上で、これらのリソースの状態を手作業で OFFLINE に設定します。
# scswitch -c -h nodelist -j resource -f STOP_FAILED
-c

フラグを消去します。

-h nodelist

リソースが実行されていたノード名を指定します。

-j resource

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

-f STOP_FAILED

フラグ名を指定します。

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

リソースグループの状態は、OFFLINE または ONLINE になっています。
# scstat -g
コマンド scstat -g は、リソースグループの状態が ERROR_STOP_FAILED のままかを示します。リソースグループがまだ ERROR_STOP_FAILED 状態の場合は、scswitch コマンドを実行し、該当するノード上でリソースグループをオフラインに切り替えます。
# scswitch -F -g resource-group
-F

グループをマスターできるすべてのノード上でリソースグループをオフラインにします。

-g resource-group

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

この状況は STOP メソッドに失敗し、停止に失敗したリソースがリソースグループ内のほかのノードの依存性を持っているときに、リソースグループをオフラインに切り替えた場合に発生します。これ以外の状況では、手順 4 のコマンドをすべての STOP_FAILED リソースで実行することによって、リソースグループは自動的に ONLINE または OFFLINE 状態に戻ります。

これで、リソースグループを ONLINE 状態に切り替えることができます。

登録済みのリソースタイプの再登録

あらかじめ登録されているリソースタイプには、SUNW.LogicalHostname と SUNW.SharedAddress があります。すべての論理ホスト名と共有アドレスリソースがこれらのリソースタイプを使用します。これら 2 つのリソースタイプは、誤って削除した場合を除き、登録する必要はありません。誤ってリソースタイプを削除した場合は、次の手順を使用して再登録してください。

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

注 –

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

登録済みのリソースタイプを再登録する

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

# scrgadm -a -t SUNW.resource-type

-a: リソースタイプを追加します。
-t SUNW.resource-type: 追加する (再登録する) リソースタイプを指定します。リソースタイプは、SUNW.LogicalHostname または SUNW.SharedAddress のいずれかになります。

例 – 登録済みのリソースタイプの再登録

次に、LogicalHostname リソースタイプを再登録する例を示します。

# scrgadm -a -t SUNW.LogicalHostname

リソースグループへのノードの追加と削除

この節の手順では、次の作業を行います。

リソースグループの追加のマスターとなるクラスタノードを構成する
リソースグループからノードを削除する

ノードの追加や削除をフェイルオーバーリソースグループに対して行うのか、スケーラブルリソースグループに対して行うのかによって、手順は異なります。

フェイルオーバーリソースグループは、フェイルオーバーとスケーラブルの両方のサービスによって使用されるネットワークリソースを含みます。クラスタに接続される各 IP サブネットワークは、指定された独自のネットワークリソースを持ち、フェイルオーバーリソースグループに含まれます。このネットワークリソースは、論理ホスト名または共有アドレスリソースのいずれかになります。各ネットワークリソースは、それが使用する IP ネットワークマルチパスグループのリストを含んでいます。フェイルオーバーリソースグループの場合は、リソースグループ (netiflist リソースプロパティ) に含まれる各ネットワークリソースに対し、IP ネットワークマルチパスグループの完全なリストを更新する必要があります。

スケーラブルリソースグループの場合は、スケーラブルグループをホストの新しいセット上でマスターされるように変更するほかに、スケーラブルリソースによって使用されるネットワークリソースを含むフェイルオーバーグループのための手順も実行する必要があります。

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

注 –

任意のクラスタノードから、以下に説明する手順のいずれかを実行します。

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

この作業は次のセクションに分かれています。

この手順を実行するには、次の情報が必要になります。

すべてのクラスタノードの名前とノード ID
ノードが追加されるリソースグループの名前
すべてのノード上のリソースグループによって使用されるネットワークリソースをホストする IP ネットワークマルチパスグループの名前

さらに、新しいノードがすでにクラスタメンバーになっていることも確認してください。

スケーラブルリソースグループにノードを追加する

リソースグループ内のスケーラブルリソースが使用する各ネットワークリソースごとに、そのネットワークリソースが配置されているリソースグループが新しいノードで実行されるようにします。

詳細は、以下の作業の手順 1 から手順 4 を参照してください。

スケーラブルリソースグループをマスターできるノードのリスト (nodelist リソースグループプロパティ) に新しいノードを追加します。

この手順は、nodelist の値を上書きするため、リソースグループをマスターできるすべてのノードをここに含める必要があります。
# scrgadm -c -g resource-group -h nodelist
-c

リソースグループを変更します。

-g resource-group

ノードが追加されるリソースグループの名前を指定します。

-h nodelist

リソースグループをマスターできるノードをコンマで区切って指定します。

(省略可能) スケーラブルリソースの Load_balancing_weights プロパティを更新し、リソースグループに追加するノードにウエイトを割り当てます。

ウエイトを割り当てない場合は、デフォルトで 1 になります。詳細は、scrgadm(1M) のマニュアルページを参照してください。

フェイルオーバーリソースグループにノードを追加する

現在のノードリスト、およびリソースグループ内の各リソース用に構成された IP ネットワークマルチパスグループの現在のリストを表示します。
# scrgadm -pvv -g resource-group | grep -i nodelist # scrgadm -pvv -g resource-group | grep -i netiflist
注 –
nodelist と netiflist のコマンド行出力では、ノード名でノードが識別されます。ノード ID を識別するには、コマンド scconf -pv | grep -i node_id を実行してください。

ノードの追加によって影響を受けるネットワークリソースの netiflist を更新します。

この手順は、netiflist の値を上書きするため、すべての IP ネットワークマルチパスグループをここに含める必要があります。
# scrgadm -c -j network-resource -x netiflist=netiflist
-c

ネットワークリソースを変更します。

-j network-resource

netiflist エントリ上でホストされているネットワークリソースの名前 (論理ホスト名または共有アドレス) を指定します。

-x netiflist =netiflist

各ノード上の IP ネットワークマルチパスグループをコンマで区切って指定します。netiflist 内の各要素は、netif@node という形式でなければなりません。netif は、IP ネットワークマルチパスグループ名 (sc_ipmp0 など) で指定できます。ノードは、ノード名またはノード ID (sc_ipmp0@1、sc_ipmp@phys-schost-1 など) で識別できます。

このリソースグループをマスターできるすべてのノードを含めるように、ノードリストを更新します。

この手順は、nodelist の値を上書きするため、リソースグループをマスターできるすべてのノードをここに含める必要があります。
# scrgadm -c -g resource-group -h nodelist
-c

リソースグループを変更します。

-g resource-group

ノードが追加されるリソースグループの名前を指定します。

-h nodelist

リソースグループをマスターできるノードをコンマで区切って指定します。

更新された情報を確認します。

# scrgadm -pvv -g resource-group | grep -i nodelist
# scrgadm -pvv -g resource-group | grep -i netiflist

例 – リソースグループへのノードの追加

次に、リソースグループ (resource-group-1) にノード (phys-schost-2) を追加する例を示します。このリソースグループは、論理ホスト名リソース (schost-2) を含んでいます。

# scrgadm -pvv -g resource-group-1 | grep -i nodelist
(resource-group-1) Res Group Nodelist:    phys-schost-1 phys-schost-3
# scrgadm -pvv -g resource-group-1 | grep -i netiflist
(resource-group-1:schost-2) Res property name: NetIfList
(resource-group-1:schost-2:NetIfList) Res property class: extension
(resource-group-1:schost-2:NetIfList) List of IP ネットワークマルチパス  
interfaces on each node
(resource-group-1:schost-2:NetIfList) Res property type: stringarray
(resource-group-1:schost-2:NetIfList) Res property value: sc_ipmp0@1 sc_ipmp0@3
 
(ノード 1 と 3 だけが IP ネットワークマルチパスグループを割り当てられています。
ノード 2 に IP ネットワークマルチパスグループを割り当てる必要があります。)

# scrgadm -c -j schost-2 -x netiflist=sc_ipmp0@1,sc_ipmp0@2,sc_ipmp0@3
# scrgadm -c -g resource-group-1 -h phys-schost-1,phys-schost-2,phys-schost-3
# scrgadm -pvv -g resource-group-1 | grep -i nodelist
(resource-group-1) Res Group Nodelist:     phys-schost-1 phys-schost-2 
                                           phys-schost-3
# scrgadm -pvv -g resource-group-1 | grep -i netiflist
(resource-group-1:schost-2:NetIfList) Res property value: sc_ipmp0@1 sc_ipmp0@2
                                                          sc_ipmp0@3

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

この作業は次のセクションに分かれています。

これらの手順を実行するには、次の情報が必要になります。

すべてのクラスタノードの名前とノード ID
# scconf -pv | grep “Node ID”
ノードが削除されるリソースグループまたはグループの名前
# scrgadm -pv | grep “Res Group Nodelist”
すべてのノード上のリソースグループによって使用されるネットワークリソースをホストする IP ネットワークマルチパスグループの名前
# scrgadm -pvv | grep “NetIfList.*value”

さらに、削除するノード上でリソースグループがマスターされていないことを確認してください。削除するノード上でマスターされている場合は、scswitch コマンドを実行し、そのノードでリソースグループをオフラインに切り替えてください。次の scswitch コマンドは、指定されたノードからリソースグループをオフラインにします。この場合、new‐masters にこのノードが含まれていてはなりません。

# scswitch -z -g resource-group -h new-masters

-g resource-group: オフラインに切り替えるリソースグループ (削除するノードでマスターされている) の名前を指定します。
-h new-masters: このリソースグループを現在マスターできるノードを指定します。

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

注意 –

すべてのリソースグループからノードを削除する場合で、スケーラブルサービス構成を使用するときは、最初にスケーラブルリソースグループからそのノードを削除してください。続いて、フェイルオーバーグループからそのノードを削除してください。

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

スケーラブルサービスは、次に示すように 2 つのリソースグループとして構成されます。

1 つは、スケーラブルサービスリソースを含むスケーラブルグループです。
もう 1 つは、スケーラブルサービスリソースが使用する共有アドレスリソースを含むフェイルオーバーグループです。

スケーラブルリソースグループの RG_dependencies プロパティは、フェイルオーバーリソースグループへの依存性を使用してスケーラブルグループを構成するように設定されます。このプロパティの詳細は、付録 A 「標準プロパティ」を参照してください。

スケーラブルサービス構成の詳細は、『Sun Cluster 3.1 の概念』を参照してください。

スケーラブルリソースグループからノードを削除すると、そのスケーラブルサービスはそのノード上でオンラインにすることができなくなります。スケーラブルリソースグループからノードを削除するには、以下の作業を行なってください。

スケーラブルリソースグループをマスターできるノードのリスト (nodelist リソースグループプロパティ) からノードを削除します。
# scrgadm -c -g scalable-resource-group -h nodelist
-c

リソースグループを変更します。

-g scalable-resource-group

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

-h nodelist

このリソースグループをマスターできるノードをコンマで区切って指定します。

(省略可能) 共有アドレスリソースが入ったフェイルオーバーリソースグループからノードを削除します。

詳細は、共有アドレスリソースを含むフェイルオーバーリソースグループからノードを削除するを参照してください。

(省略可能) スケーラブルリソースの Load_balancing_weights プロパティを更新し、リソースグループから削除するノードのウエイトを削除します。

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

フェイルオーバーリソースグループからノードを削除する

フェイルオーバーリソースグループからノードを削除するには、以下の作業を行なってください。

注意 –

すべてのリソースグループからノードを削除する場合で、スケーラブルサービス構成を使用するときは、最初にスケーラブルリソースグループからそのノードを削除してください。続いて、この方法を使用してフェイルオーバーグループからノードを削除してください。

注 –

フェイルオーバーリソースグループにスケーラブルサービスが使用する共有アドレスリソースが含まれる場合は、共有アドレスリソースを含むフェイルオーバーリソースグループからノードを削除するを参照してください。

このリソースグループをマスターできるすべてのノードを含めるように、ノードリストを更新します。

この手順はノードを削除してノードリストの値を上書きするため、リソースグループをマスターできるすべてのノードをここに含める必要があります。
# scrgadm -c -g failover-resource-group -h nodelist
-c

リソースグループを変更します。

-g failover-resource-group

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

-h nodelist

このリソースグループをマスターできるノードをコンマで区切って指定します。

リソースグループ内の各リソース用に構成した IP ネットワークマルチパスグループの現在のリストを表示します。
# scrgadm -pvv -g failover-resource-group | grep -i netiflist

ノードの削除によって影響を受けるネットワークリソースの netiflist を更新します。

この手順は netiflist の値を上書きするため、すべての IP ネットワークマルチパスグループをここに含める必要があります。
# scrgadm -c -j network-resource -x netiflist=netiflist
注 –
上記コマンド行の出力は、ノード名によってノードを識別します。ノード ID を識別するには、コマンド scconf -pv | grep “ノード ID” を実行してください。

-c

ネットワークリソースを変更します。

-j network-resource

netiflist エントリ上でホストされているネットワークリソースの名前を指定します。

-x netiflist =netiflist

各ノード上の IP ネットワークマルチパスグループをコンマで区切って指定します。netiflist 内の各要素は、netif@node という形式でなければなりません。netif は、IP ネットワークマルチパスグループ名 (sc_ipmp0 など) で指定できます。ノードは、ノード名またはノード ID (sc_ipmp0@1、sc_ipmp@phys-schost-1 など) で識別できます。

注 –
Sun Cluster では、現在、netif にアダプタ名を使用することはできません。

更新された情報を確認します。

# scrgadm -pvv -g failover-resource-group | grep -i nodelist
# scrgadm -pvv -g failover-resource-group | grep -i netiflist

共有アドレスリソースを含むフェイルオーバーリソースグループからノードを削除する

スケーラブルサービスが使用する共有アドレスリソースを含むフェイルオーバーリソースグループでは、ノードは次の場所に現れます。

フェイルオーバーリソースグループのノードリスト
共有アドレスリソースの auxnodelist

フェイルオーバーリソースグループのノードリストからノードを削除するには、フェイルオーバーリソースグループからノードを削除するに示されている作業を行なってください。

共有アドレスリソースの auxnodelist を変更するには、共有アドレスリソースを削除して作成し直す必要があります。

フェイルオーバーグループのノードリストからノードを削除すると、そのノード上の共有アドレスリソースを継続して使用し、スケーラブルサービスを提供できます。このためには、共有アドレスリソースの auxnodelist にそのノードを追加する必要があります。auxnodelist にノードを追加するには、以下の作業を行なってください。

注 –

以下の作業は、共有アドレスリソースの auxnodelist からノードを削除するためにも使用できます。auxnodelist からノードを削除するには、共有アドレスリソースを削除して作成し直す必要があります。

スケーラブルサービスリソースをオフラインに切り替えます。

フェイルオーバーリソースグループから共有アドレスリソースを削除します。

共有アドレスリソースを作成します。

フェイルオーバーリソースグループから削除したノードのノード ID またはノード名を auxnodelist に追加します。
# scrgadm -a -S -g failover-resource-group\ -l shared-address -X new-auxnodelist
failover-resource-group

共有アドレスリソースを含めるために使用されたフェイルオーバーリソースグループの名前。

shared-address

共有アドレスの名前。

new-auxnodelist

妥当なノードの追加または削除によって変更された新しい auxnodelist。

例 – リソースグループからのノードの削除

次に、リソースグループ (resource-group-1) からノード (phys-schost-3) を削除する例を示します。このリソースグループは、論理ホスト名リソース (schost-1) を含んでいます。

# scrgadm -pvv -g resource-group-1 | grep -i nodelist
(resource-group-1) Res Group Nodelist:       phys-schost-1 phys-schost-2 
                                             phys-schost-3
# scrgadm -c -g resource-group-1 -h phys-schost-1,phys-schost-2
# scrgadm -pvv -g resource-group-1 | grep -i netiflist
(resource-group-1:schost-1) Res property name: NetIfList
(resource-group-1:schost-1:NetIfList) Res property class: extension
(resource-group-1:schost-1:NetIfList) List of IP ネットワークマルチパス 
interfaces on each node
(resource-group-1:schost-1:NetIfList) Res property type: stringarray
(resource-group-1:schost-1:NetIfList) Res property value: sc_ipmp0@1 sc_ipmp0@2
                                                          sc_ipmp0@3

(sc_ipmp0@3 は削除するIP ネットワークマルチパスグループ)

# scrgadm -c -j schost-1 -x netiflist=sc_ipmp0@1,sc_ipmp0@2
# scrgadm -pvv -g resource-group-1 | grep -i nodelist
(resource-group-1) Res Group Nodelist:       phys-schost-1 phys-schost-2
# scrgadm -pvv -g resource-group-1 | grep -i netiflist
(resource-group-1:schost-1:NetIfList) Res property value: sc_ipmp0@1 sc_ipmp0@2

リソースグループとディスクデバイスグループ間での起動の同期

クラスタが起動した後、あるいは、サービスが別のノードにフェイルオーバーした後、グローバルデバイスとクラスタファイルシステムが利用できるようになるまでには、しばらく時間がかかることがあります。ただし、データサービスは、データサービスが依存する広域デバイスとクラスタファイルシステムがオンラインになる前に、START メソッドを実行できます。この例では、START メソッドがタイムアウトするため、データサービスが使用するリソースグループの状態をリセットし、データサービスを手動で再起動する必要があります。リソースタイプ HAStorage と HAStoragePlus は、広域デバイスとクラスタファイルシステムを監視し、同じリソースグループ内のほかのリソースが利用可能になるまでそれらの START メソッドを待機させます(どのリソースタイプを作成するか決定するには HAStorage または HAStoragePlus の選択を参照)。追加の管理作業を避けるには、データサービスリソースが広域デバイスまたはクラスタファイルシステムに依存しているすべてのリソースグループについて HAStorage または HAStoragePlus を設定します。

HAStorage リソースタイプの作成については、新しいリソース用に HAStorage リソースタイプを設定するを参照してください。

HAStoragePlus リソースタイプの作成については、HAStoragePlus リソースタイプを設定するを参照してください。

新しいリソース用に `HAStorage` リソースタイプを設定する

HAStorage は、今後の Sun Cluster でサポートされなくなる可能性があります。同等の機能が HAStoragePlus でサポートされています。HAStorage から HAStoragePlus へアップグレードするには、HAStorage から HAStoragePlus へのアップグレードを参照してください。

次の例では、リソースグループ resource-group-1 は、次の 3 つのデータサービスを含んでいます。

Sun ONE Web Server (/global/resource-group-1 に依存する)
Oracle (/dev/global/dsk/d5s2 に依存する)
NFS (dsk/d6 に依存する)

新しいリソースに対し、HAStorage リソースの hastorage-1 を resource-group-1 に作成するには、リソースグループとディスクデバイスグループ間での起動の同期を読み、その後次の手順を実行します。

HAStoragePlus リソースタイプを作成するには、高可用性ローカルファイルシステムの有効化を参照してください。

クラスタメンバー上でスーパーユーザーになります。

リソースグループ resource-group-1 を作成します。
# scrgadm -a -g resource-group-1

リソースタイプが登録されているかどうかを調べます。

次のコマンドは、登録されているリソースタイプのリストを出力します。
# scrgadm -p | egrep Type

必要であれば、リソースタイプを登録します。
# scrgadm -a -t SUNW.HAStorage

HAStorage リソースである hastorage-1 を作成し、サービスパスを定義します。
# scrgadm -a -j hastorage-1 -g resource-group-1 -t SUNW.HAStorage \ -x ServicePaths=/global/resource-group-1,/dev/global/dsk/d5s2,dsk/d6
ServicePaths には、次の値を含むことができます。
- 広域デバイスグループ名 (例:nfs-dg)
- 広域デバイスのパス (例:/dev/global/dsk/d5s2 または dev/d6)
- クラスタファイルシステムのマウントポイント (例:/global/nfs)
注 –
ServicePaths にクラスタファイルシステムパスが含まれる場合、広域デバイスグループはそれらに対応するリソースグループと共に使用されない場合があります。

hastorage-1 リソースを有効にします。
# scswitch -e -j hastorage-1

リソース Sun ONE Web Server、Oracle、NFS を resource-group-1 に追加し、これらの依存性を hastorage-1 に設定します。

たとえば、Sun ONE Web Server の場合、次のコマンドを実行します。

# scrgadm -a -j resource -g resource-group-1 -t SUNW.iws \
-x Confdir_list=/global/iws/schost-1 -y Scalable=False \
-y Network_resources_used=schost-1 -y Port_list=80/tcp \
-y Resource_dependencies=hastorage-1

リソースの依存性を正しく構成したかを確認します。
# scrgadm -pvv -j resource | egrep strong

resource-group-1 を管理状態に設定し、オンラインにします。
# scswitch -Z -g resource-group-1

HAStorage リソースタイプは、別の拡張プロパティ (AffinityOn) を含みます。この拡張プロパティは、HAStorage が ServicePaths で定義されている広域デバイスおよびクラスタファイルシステムの類似性スイッチオーバーを実行する必要があるかどうかを指定するブール値です。詳細は、SUNW.HAStorage(5) のマニュアルページを参照してください。

注 –

リソースグループがスケーラブルの場合、HAStorage と HAStoragePlus は AffinityOn が TRUE に設定されることを許可しません。スケーラブルリソースグループについては、HAStorage と HAStoragePlus は AffinityOn 値をチェックし、この値を内部的に FALSE に設定し直します。

既存のリソース用に `HAStorage` リソースタイプを設定する

既存のリソースのために HAStorage リソースを作成するには、リソースグループとディスクデバイスグループ間での起動の同期を読み、その後以下の作業を行なってください。

リソースタイプが登録されているかどうかを調べます。

次のコマンドは、登録されているリソースタイプのリストを出力します。
# scrgadm -p | egrep Type

必要であれば、リソースタイプを登録します。
# scrgadm -a -t SUNW.HAStorage

HAStorage リソースである hastorage-1 を作成します。

# scrgadm -a -g resource-group -j hastorage-1 -t SUNW.HAStorage \
-x ServicePaths= … -x AffinityOn=True

hastorage-1 リソースを有効にします。
# scswitch -e -j hastorage-1

必要に応じて既存の各リソースについて依存性を設定します。
# scrgadm -c -j resource -y Resource_Dependencies=hastorage-1

リソースの依存性を正しく構成したかを確認します。
# scrgadm -pvv -j resource | egrep strong

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

HAStorage は、今後の Sun Cluster でサポートされなくなる可能性があります。同等の機能が HAStoragePlus でサポートされています。HAStorage から HAStorage へアップグレードする方法については、以下の節を参照してください。

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

HAStorage は、今後の Sun Cluster でサポートされなくなる可能性があります。同等の機能が HAStoragePlus でサポートされています。デバイスグループまたは CFS を使用している場合に HAStorage から HAStoragePlus にアップグレードするには、以下の作業を行なってください。

この例では、HAStorage で単純な HA-NFS リソースが有効になっています。ServicePaths はディスクグループ nfsdg で、AffinityOn プロパティは TRUE です。さらに、この HA-NFS リソースは Resource_Dependencies を HAStorage リソースに設定しています。

HAStorage に対するアプリケーションリソースの依存性を除去します。
# scrgadm -c -j nfsserver-rs -y Resource_Dependencies=""

HAStorage リソースを無効にします。
# scswitch -n -j nfs1storage-rs

アプリケーションリソースグループから HAStorage リソースを削除します。
# scrgadm -r -j nfs1storage-rs

HAStorage リソースタイプの登録を解除します。
# scrgadm -r -t SUNW.HAStorage

HAStoragePlus リソースタイプを登録します。
# scrgadm -a -t SUNW.HAStoragePlus

HAStoragePlus リソースを作成します。

ファイルシステムのマウントポイントを指定するには、次のテキストを入力してください。
# scrgadm -a -j nfs1-hastp-rs -g nfs1-rg -t \ SUNW.HAStoragePlus -x FilesystemMountPoints=/global/nfsdata -x \ AffinityOn=True
広域デバイスパスを指定するには、次のテキストを入力してください。
# scrgadm -a -j nfs1-hastp-rs -g nfs1-rg -t \ SUNW.HAStoragePlus -x GlobalDevicePaths=nfsdg -x AffinityOn=True
注 –
HAStorage の ServicePaths プロパティではなく、HAStoragePlus の GlobalDevicePaths または FilesystemMountPoints プロパティを使用する必要があります。FilesystemMountPoints 拡張プロパティは、/etc/vfstab で指定されたシーケンスと一致する必要があります。

HAStoragePlus リソースを有効にします。
# scswitch -e -j nfs1-hastp-rs

アプリケーションサーバーとHAStoragePlus との間の依存性を設定します。
# scrgadm -c -j nfsserver-rs -y \ Resource_Depencencies=nfs1=hastp-rs

CFS による HAStorage からフェイルオーバーファイルシステムによる HAStoragePlus へアップグレードする

HAStorage は、今後の Sun Cluster でサポートされなくなる可能性があります。同等の機能が HAStoragePlus でサポートされています。CFS による HAStorage から Failover Filesystem (FFS) による HAStoragePlus にアップグレードするには、以下の作業を行なってください。

HAStorage リソースに対するアプリケーションリソースの依存性を除去します。
# scrgadm -c -j nfsserver-rs -y Resource_Dependencies=""'

HAStorage リソースを無効にします。
# scswitch -n -j nfs1storage-rs

アプリケーションリソースグループから HAStorage リソースを削除します。
# scrgadm -r -j nfs1storage-rs

HAStorage リソースタイプの登録を解除します。
# scrgadm -r -t SUNW.HAStorage

/etc/vfstab を変更して広域フラグを削除し、「mount at boot」を「no」に変更します。

HAStoragePlus リソースを作成します。

ファイルシステムのマウントポイントを指定するには、次のテキストを入力してください。
# scrgadm -a -j nfs1-hastp-rs -g nfs1-rg -t \ SUNW.HAStoragePlus -x FilesystemMountPoints=/global/nfsdata -x \ AffinityOn=True
広域デバイスパスを指定するには、次のテキストを入力してください。
# scrgadm -a -j nfs1-hastp-rs -g nfs1-rg -t \ SUNW.HAStoragePlus -x GlobalDevicePaths=nfsdg -x AffinityOn=True
注 –
HAStorage の ServicePaths プロパティではなく、HAStoragePlus の GlobalDevicePaths または FilesystemMountPoints プロパティを使用する必要があります。FilesystemMountPoints 拡張プロパティは、/etc/vfstab で指定されたシーケンスと一致する必要があります。

HAStoragePlus リソースを有効にします。
# scswitch -e -j nfs1-hastp-rs

アプリケーションサーバーとHAStoragePlus との間の依存性を設定します。
# scrgadm -c -j nfsserver-rs -y \ Resource_Depencencies=nfs1=hastp-rs

高可用性ローカルファイルシステムの有効化

HAStoragePlus リソースタイプを使用すると、ローカルファイルシステムを Sun Cluster 環境内で高可用性にすることができます。このためには、ローカルファイルシステムのパーティションが広域ディスクグループに存在し、アフィニティスイッチオーバーが有効であり、Sun Cluster 環境がフェイルオーバー用に構成されている必要があります。これによって、多重ホストディスクに直接接続された任意のホストから、多重ホストディスク上の任意のファイルシステムにアクセスできるようになります。(HAStoragePlus を使用して root ファイルシステムの高可用性を実現することはできません)。フェイルバックの設定は、リソースグループとデバイスグループで同一にする必要があります。

入出力の多いデータサービスの中には、HA ローカルファイルシステムの使用が強く望まれるものがあります。このため、このようなデータサービスの登録作業と構成作業には、HAStoragePlus リソースタイプを構成する方法が追加されています。これらのデータサービスの HAStoragePlus リソースタイプを設定する手順については、以下の節を参照してください。

『Sun Cluster 3.1 Data Service for Oracle ガイド』の「 Sun Cluster HA for Oracle の登録と構成」
『Sun Cluster 3.1 Data Service for Sybase ASE ガイド』の「Sun Cluster HA for Sybase ASE の登録と構成」

ほかのデータサービスの HAStoragePlus リソースタイプを設定する方法については、HAStoragePlus リソースタイプを設定するを参照してください。

`HAStoragePlus` リソースタイプを設定する

HAStoragePlus リソースタイプは、Sun Cluster 3.0 5/02 で導入されました。この新しいリソースタイプには HAStorage と同じ機能があり、リソースグループとディスクデバイスグループとの間で起動の同期をとります。HAStoragePlus リソースタイプには、ローカルファイルシステムを高可用性にするための機能が追加されています。(ローカルファイルシステムを高可用性にするための説明については、高可用性ローカルファイルシステムの有効化を参照)。これらの機能を両方とも使用するには、HAStoragePlus リソースタイプを設定します。

HAStoragePlus を設定するには、ローカルファイルシステムのパーティションが広域ディスクグループに存在し、アフィニティスイッチオーバーが有効であり、かつ Sun Cluster 環境がフェイルオーバー用に構成されている必要があります。

次の例では、簡単な NFS サービスを使用して、ローカルにマウントされたディレクトリ /global/local-fs/nfs/export/ からホームディレクトリのデータを共有します。この例では、次の条件を前提にしています。

マウントポイント /global/local-fs/nfs は、UFS ローカルファイルシステムを Sun Cluster 広域デバイスのパーティションにマウントするために使用されます。
/global/local-fs/nfs ファイルシステムの /etc/vfstab エントリには、このファイルシステムがローカルファイルシステムで、マウントブートフラグが「no」であるよう指定されている必要があります。
PathPrefix ディレクトリ (HA-NFS が管理情報と状態情報を保守するために使用するディレクトリ) は、マウントするファイルシステムのルートディレクトリ (たとえば、/global/local-fs/nfs) 上に存在します。

クラスタメンバー上でスーパーユーザーになります。

リソースタイプが登録されているかどうかを調べます。

次のコマンドは、登録されているリソースタイプのリストを出力します。
# scrgadm -p | egrep Type

必要であれば、リソースタイプを登録します。
# scrgadm -a -t SUNW.nfs

フェイルオーバーリソースグループ nfs-r を作成します。
# scrgadm -a -g nfs-rg -y PathPrefix=/global/local-fs/nfs

タイプ SUNW.LogicalHostname の論理ホストリソースを作成します。
# scrgadm -a -j nfs-lh-rs -g nfs-rg -L -l log-nfs

クラスタに HAStoragePlus リソースタイプを登録します。
# scrgadm -a -t SUNW.HAStoragePlus

タイプ HAStoragePlus のリソース nfs-hastp-rs を作成します。
# scrgadm -a -j nfs-hastp-rs -g nfs-rg -t SUNW.HAStoragePlus\ -x FilesystemMountPoints=/global/local-fs/nfs \ -x AffinityOn=TRUE
注 –
FilesystemMountPoints 拡張プロパティは、1 つ以上のファイルシステムマウントポイントをリストの形式で指定するために使用できます。このリストには、ローカルファイルシステムマウントポイントと広域ファイルシステムマウントポイントの両方を含めることができます。ブートフラグでのマウントは、広域ファイルシステムの HAStoragePlus によって無視されます。

リソースグループ nfs-rg をクラスタノード上でオンラインにします。

このノードは、/global/local-fs/nfs ファイルシステムの実際の広域デバイスのパーティション用の主ノードになります。次に、ファイルシステム /global/local-fs/nfs は当該ノード上にローカルにマウントされます。
# scswitch -Z -g nfs-rg

SUNW.nfs リソースタイプをクラスタに登録します。タイプ SUNW.nfs のリソース nfs-rs を作成して、リソース nfs-hastp-rs へのリソース依存関係を指定します。

dfstab.nfs-rs が /global/local-fs/nfs/SUNW.nfs に作成されます。
# scrgadm -a -t SUNW.nfs # scrgadm -a -g nfs-rg -j nfs-rs -t SUNW.nfs \ -y Resource_dependencies=nfs-hastp-rs
注 –
nfs リソースに依存関係を設定するには、nfs-hastp-rs リソースがオンラインである必要があります。

リソース nfs-rs をオンラインにします。
# scswitch -Z -g nfs-rg

注意 –

切り替えは、必ずリソースグループレベルで行なってください。デバイスグループレベルで切り替えを行うと、リソースグループが混乱し、フェイルオーバーが発生します。

これで、サービスを新しいノードに移行するときには常に、/global/local-fs/nfs 用のプライマリ入出力パスはオンラインになり、NFS サーバーに配置されます。ファイルシステム /global/local-fs/nfs は NFS サーバーが起動する前にローカルにマウントされます。

重要ではないリソースグループをオフロードすることによるノードリソースの解放

Prioritized Service Management (RGOffload) を使用すると、重要なデータサービス用にノードのリソースを自動的に解放できます。RGOffload は、重要なフェイルオーバーデータサービスを起動するために、重要でないスケーラブルデータサービスまたはフェイルオーバーデータサービスをオフラインにする必要があるときに使用します。RGOffload は、重要でないデータサービスを含むリソースグループをオフロードするときに使用します。

注 –

重要なデータサービスはフェイルオーバー可能でなければなりません。オフロードするデータサービスは、フェイルオーバーデータサービスでもスケーラブルデータサービスでもかまいません。

`RGOffload` リソースを設定する

クラスタメンバー上でスーパーユーザーになります。

RGOffload リソースタイプが登録されているかどうかを調べます。

次のコマンドは、リソースタイプのリストを出力します。
# scrgadm -p|egrep SUNW.RGOffload

必要であれば、リソースタイプを登録します。
# scrgadm -a -t SUNW.RGOffload

RGOffload リソースでオフロードするリソースグループごとに、Desired_primaries をゼロに設定します。
# scrgadm -c -g offload-rg -y Desired_primaries=0

RGOffload リソースを重要なフェイルオーバーリソースグループに追加して、拡張プロパティを設定します。

リソースグループを複数のリソースの rg_to_offload リストに追加してはいけません。リソースグループを複数の rg_to_offload リストに追加すると、リソースグループはオフラインになったあとにオンラインになるという動作を繰り返すことになります。

拡張プロパティについては、RGOffload 拡張プロパティを構成するを参照してください。
# scrgadm -aj rgoffload-resource\ -t SUNW.RGOffload -g critical-rg \ -x rg_to_offload=offload-rg-1, offload-rg-2, ...\ -x continue_to_offload=TRUE \ -x max_offload_retry=15
注 –
この場合、rg_to_offload 以外の拡張プロパティはデフォルト値で表示されます。rg_to_offload は、お互いに依存しないリソースグループをコンマで区切ったリストです。このリストには、RGOffload リソースを追加するリソースグループを含めることはできません。

RGOffload リソースを有効にします。
# scswitch -ej rgoffload-resource

重要なフェイルオーバーリソースから RGOffload への依存関係を設定します。
# scrgadm -c -j critical-resource \ -y Resource_dependencies=rgoffload-resource
Resource_dependencies_weak も使用できます。Resource_dependencies_weak を RGOffload リソースタイプに使用すると、offload-rg のオフロード中にエラーが発生しても、重要なフェイルオーバーリソースを起動できます。

オフロードするリソースグループを、オンラインにします。
# scswitch -z -g offload-rg, offload-rg-2, ... -h [nodelist]
リソースグループは、重要なリソースグループがオフラインであるすべてのノード上でオンラインのままになります。障害モニターは、重要なリソースグループがオンラインであるノード上でリソースグループが動作しないようにします。

オフロードするリソースグループの Desired_primaries はゼロに設定されているので (手順 4を参照)、“-Z” オプションを指定しても、このようなリソースグループはオンラインになりません。

重要なフェイルオーバーリソースグループがオンラインでない場合、オンラインにします。
# scswitch -Z -g critical-rg

例 – RGOffload リソースを構成する

この例では、RGOffload リソース (rgofl)、RGOffload リソースを含む重要なリソースグループ (oracle_rg)、および重要なリソースグループがオンラインになったときにオフロードされるスケーラブルリソースグループ (IWS-SC, IWS-SC-2) を構成する方法について説明します。この例では、重要なリソースは oracle-server-rs です。

この例では、oracle_rg、IWS-SC、および IWS-SC-2 はクラスタ "triped" の任意のノード、つまり、phys-triped-1、phys-triped-2、phys-triped-3 上でマスターできます。

[SUNW.RGOffload リソースタイプが登録されているかを確認する]
# scrgadm -p|egrep SUNW.RGOffload
 
[必要に応じ、リソースタイプを登録する]
# scrgadm -a -t SUNW.RGOffload

[RGOffload リソースによってオフロードされるリソースグループごとに Desired_primaries をゼロに設定する]
# scrgadm -c -g IWS-SC-2 -y Desired_primaries=0
# scrgadm -c -g IWS-SC -y Desired_primaries=0

[重要なリソースグループに RGOffload リソースを追加し、拡張プロパティを設定する]
# scrgadm -aj rgofl -t SUNW.RGOffload -g oracle_rg \
-x rg_to_offload=IWS-SC,IWS-SC-2 -x continue_to_offload=TRUE \
-x max_offload_retry=15
 
[RGOffload リソースを有効にする]
# scswitch -ej rgofl
 
[RGOffload リソースに対する重要なフェイルオーバーリソースの依存性を設定する]
# scrgadm -c -j oracle-server-rs -y Resource_dependencies=rgofl
 
[すべてのノード上で、オフロードされるリソースグループをオンラインにする]
# scswitch -z -g IWS-SC,IWS-SC-2 -h phys-triped-1,phys-triped-2,phys-triped-3
 
[重要なフェイルオーバーリソースグループがオンライン状態でない場合は、オンラインにする]
# scswitch -Z -g oracle_rg

RGOffload 拡張プロパティを構成する

通常、RGOffload リソースを作成するとき、拡張プロパティを構成するには、コマンド行 scrgadm -x parameter=value を使用します。Sun Cluster のすべての標準プロパティの詳細は、付録 A 「標準プロパティ」を参照してください。

表 2–2 に RGOffload に設定できる拡張プロパティを示します。「調整」の欄は、各プロパティをいつ更新できるかを示しています。

表 2–2 RGOffload 拡張プロパティ


名前 / データタイプ	デフォルト値
`rg_to_offload` (文字列)	重要なフェイルオーバーリソースグループがノード上で起動するときに、当該ノード上でオフロードする必要があるリソースグループをコンマで区切ったリスト。このリストには、互いに依存するリソースグループが含まれてはいけません。このプロパティにはデフォルト設定値がないので、必ず設定する必要があります。 RGOffload は、`rg_to_offload` 拡張プロパティに設定されたリソースグループのリストにおける依存関係ループを検査しません。たとえば、リソースグループ RG-B が RG-A に依存する場合、RG-A と RG-B が両方とも `rg_to_offload` に含まれてはいけません。初期値: `なし` 調整: 任意の時点 (Anytime)
`continue_to_offload` (ブール型)	リソースグループのオフロード中にエラーが発生した後に、`rg_to_offload` リスト内の残りのリソースグループをオフロードし続けるかどうかを示すブール型。このプロパティは `START` メソッドだけが使用します。初期値: `True` 調整: 任意の時点 (Anytime)
`max_offload_retry` (整数)	クラスタまたはリソースグループの再構成による障害時の起動中に、リソースグループをオフロードしようとする回数。再試行の間には 10 秒の間隔があります。 (オフロードされるリソースグループの数 * `max_offload_retry` * 10 秒) が RGOffload リソースの `Start_timeout` よりも小さくなるように `max_offload_retry` を設定します。この値が `Start_timeout` の値に近い (あるいは、より大きい) 場合、最大再試行数に到達する前に、RGOffload リソースの `START` メソッドがタイムアウトする可能性があります。このプロパティは `START` メソッドだけが使用します。初期値: `15` 調整: 任意の時点 (Anytime)

障害モニター

RGOffload リソースの障害モニター検証は、重要なリソースをマスターするノード上で、rg_to_offload 拡張プロパティに指定されたリソースグループをオフラインにし続けるために使用されます。各検証サイクルで障害モニターは、重要なリソースをマスターするノード上で、オフロードされるリソースグループ (offload-rg) がオフラインであることを確認します。重要なリソースをマスターするノード上で offload-rg がオンラインである場合、障害モニターは重要なリソースをマスターするノード以外のノード上で offload-rg を起動し、同時に、重要なリソースをマスターするノード上では offload-rg をオフラインにしようとします。

offload-rg の desired_primaries はゼロに設定されているので、このあとで利用可能になったノード上では、オフラインのリソースグループは再起動されません。したがって、RGOffload 障害モニターは maximum_primaries に到達するまで、重要なリソースをマスターするノード上では offload-rg をオフラインにしながら、可能な限りのプライマリ上で offload-rg を起動しようとします。

RGOffload は、保守状態または非管理状態でないかぎり、オフロードされたすべてのリソースを起動しようとします。リソースグループを非管理状態にするには、scswitch コマンドを使用します。

# scswitch -u -g resourcegroup

障害モニター検証サイクルは、Thorough_probe_interval が実行されたあとにかならず呼び出されます。

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

データサービスリソースの管理

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

リソースタイプの登録

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

例 – リソースタイプの登録

次の作業

リソースタイプの更新

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

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

例 1 – 既存のリソースを新しいリソースタイプバージョンに移行する

例 2 – 既存のリソースを新しいリソースタイプバージョンに移行する

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

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

リソースグループの作成

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

例 – フェイルオーバーリソースグループの作成

次の作業

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

例 – スケーラブルリソースグループの作成

次の作業

リソースグループへのリソースの追加

論理ホスト名リソースをリソースグループに追加する

例 – 論理ホスト名リソースのリソースグループへの追加

次の作業

共有アドレスリソースをリソースグループに追加する

例 – 共有アドレスリソースのリソースグループへの追加

次の作業

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

例 – フェイルオーバーアプリケーションリソースのリソースグループへの追加

次の作業

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

例 – スケーラブルアプリケーションリソースのリソースグループへの追加

次の作業

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

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

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

次の作業

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

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

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

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

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

リソースタイプの削除

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

例 – リソースタイプの削除

リソースグループの削除

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

例 — リソースグループの削除

リソースの削除

リソースを削除する

例 – リソースの削除

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

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

例 – リソースグループを新しい主ノードに切り替える

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

リソースを無効にしてリソースグループを非管理状態に移行する

例 – リソースの無効化とリソースグループの非管理状態への移行

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

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

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

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

例 – リソースタイププロパティの変更

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

例 – リソースグループプロパティの変更

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

例 – 標準リソースプロパティの変更

例 – 拡張リソースプロパティの変更

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

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

登録済みのリソースタイプの再登録

登録済みのリソースタイプを再登録する

例 – 登録済みのリソースタイプの再登録

リソースグループへのノードの追加と削除

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

スケーラブルリソースグループにノードを追加する

フェイルオーバーリソースグループにノードを追加する

例 – リソースグループへのノードの追加

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

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

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

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

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

新しいリソース用に `HAStorage` リソースタイプを設定する

既存のリソース用に `HAStorage` リソースタイプを設定する

`HAStoragePlus` リソースタイプを設定する

`RGOffload` リソースを設定する