第 2 章 データサービスリソースの管理
この章では、scrgadm(1M) コマンドを使って、リソースや、リソースグループ、リソースタイプを管理する手順を説明します。 手順を実行するその他のツールについては、データサービスリソースを管理するためのツールを参照してください。
この章では、次の手順について説明します。
リソースタイプ、リソースグループ、およびリソースに関する概要情報については、第 1 章「Sun Cluster データサービスの計画 」 および『 Sun Cluster の概念 (Solaris OS 版)』マニュアルを参照してください。
データサービスリソースの管理
表 2–1 に、データサービスリソースの管理作業を説明している節を示します。
表 2–1 Task Map: データサービス管理|
作業 |
参照箇所 |
|---|---|
|
リソースタイプを登録する | |
|
リソースタイプをアップグレードする | |
|
フェイルオーバーリソースグループまたはスケーラブルリソースグループの作成 | |
|
論理ホスト名または共有アドレス、データサービスリソースをリソースグループに追加する | |
|
リソースとリソースモニターを有効にし、リソースグループを管理し、リソースグループおよび関連するリソースをオンラインにする | |
|
リソース自体とは関係なく、リソースモニターだけを無効または有効にする | |
|
クラスタからリソースタイプを削除する | |
|
クラスタからリソースグループを削除する | |
|
リソースグループからリソースを削除する | |
|
リソースグループの稼動系を切り替える | |
|
リソースを無効にし、そのリソースグループをUNMANAGEDに移行する | |
|
リソースタイプ、リソースグループ、リソース構成情報を表示する | |
|
リソースタイプ、リソースグループ、リソースプロパティの変更 | |
|
失敗した Resource Group Manager (RGM) プロセスのエラーフラグの消去 | |
|
組み込みリソースタイプ LogicalHostname および SharedAddress の再登録 | |
|
ネットワークリソースのネットワークインタフェース ID リストの更新と、リソースグループのノードリストの更新 | |
|
リソースグループからノードを削除する | |
|
リソースグループとディスクデバイスグループ間で起動の同期をとるために、リソースグループの HAStorage または HAStoragePlus を設定する | |
|
ディスク入出力負荷が高いフェイルオーバーデータサービスに対応するように、HAStoragePlus を設定してローカルファイルシステムの可用性を高める | |
|
重要なデータサービスのためにノードを自動的に開放するようにリソースタイプを設定する |
注 –
この章では、scrgadm(1M) コマンドを使用し、これらの作業を完了する手順について解説します。 これ以外のツールを使ってリソースを管理することもできます。 これらの方法については、データサービスリソースを管理するためのツールを参照してください。
Sun Cluster データサービスの構成と管理
Sun Cluster の構成は、複数の手順から成る単一の作業です。 これらの手順により次の作業を実行できます。
-
リソースタイプの登録
-
リソースタイプのアップグレード
-
リソースグループの作成
-
リソースグループへのリソースの追加
-
リソースをオンラインにする
データサービスの構成を変更するには、初期構成が終わった後で次の各手順を使用します。 たとえば、リソースタイプ、リソースグループ、およびリソースプロパティを変更する場合は、リソースタイプ、リソースグループ、リソースプロパティの変更へ進んでください。
リソースタイプの登録
リソースタイプは、指定されたタイプのすべてのリソースに適用される共通のプロパティとコールバックメソッドの仕様を提供します。 リソースタイプは、そのタイプのリソースを作成する前に登録する必要があります。 リソースタイプについての詳細は、第 1 章「Sun Cluster データサービスの計画 」を参照してください。
リソースタイプを登録する
この手順を実行するには、登録するリソースタイプに、データサービス名の略語で 名前をつける必要があります。 Sun Cluster に標準添付されているデータサービスのリソースタイプ名の詳細は、Sun Cluster のリリースノートを参照してください。
追加情報については、scrgadm(1M) のマニュアルページを参照してください。
注 –
この手順は、任意のクラスタノードから実行します。
-
クラスタメンバー上でスーパーユーザーになります。
-
リソースタイプを登録します。
# scrgadm -a -t resource-type
- -a
-
指定したリソースタイプを追加します。
- -t resource-type
-
追加するリソースタイプの名前を指定します。 指定する事前定義済みの名前を判別するには、Sun Cluster のリリースノートを参照してください。
-
登録されたリソースタイプを確認します。
# scrgadm -pv -t resource-type
例 – リソースタイプの登録
次に、Sun Cluster HA for Sun Java System Web Server (内部名 iws) を登録する例を示します。
# scrgadm -a -t SUNW.iws # scrgadm -pv -t SUNW.iws リソースタイプ 名前: SUNW.iws :4 (SUNW.iws) リソースタイプ 説明: None registered (SUNW.iws) リソースタイプ ベースディレクトリ: /opt/SUNWschtt/bin (SUNW.iws) リソースタイプ 単一のインスタンス: False (SUNW.iws) リソースタイプ 初期ノード: All potential masters (SUNW.iws) リソースタイプ フェイルオーバー: False (SUNW.iws) リソースタイプ バージョン: 4 (SUNW.iws) リソースタイプ API バージョン: 2 (SUNW.iws) リソースタイプ ノードにインストールされている: All (SUNW.iws) リソースタイプ パッケージ: SUNWschtt (SUNW.iws) リソースタイプ システム: False |
次に進む手順
リソースタイプを登録したあと、リソースグループを作成し、リソースをそのリソースグループに追加できます。 詳細は、リソースグループの作成を参照してください。
リソースタイプのアップグレード
新バージョンのリソースタイプがリリースされる際には、そのアップグレードされたリソースタイプをインストールして登録できます。 また、既存のリソースを新しいリソースタイプバージョンにアップグレードすることも可能です。 この節では、次の 2 つの作業、アップグレードされたリソースタイプをインストールして登録する方法と、既存のリソースを新しいリソースタイプバージョンにアップグレードする方法について説明します。
アップグレードされたリソースタイプをインストールして登録する
この作業は、scsetup の「リソースグループ」オプションを使用しても行えます。 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 の「リソースグループ」オプションを使用しても行えます。 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
-
既存のリソースを新しいリソースタイプバージョンに移行する前に、新しいリソースタイプに付属しているアップグレードマニュアルに目を通し、移行が可能かどうかを確認してください。
そのマニュアルには、移行を実施すべきタイミングが記されています。
-
任意の時点 (Anytime)
-
リソースが監視されていないとき
-
リソースがオフラインのとき
-
リソースが無効なとき
-
リソースグループが管理されていないとき
移行がサポートされていない場合は、リソースを削除してアップグレードされた新しいリソースバージョンに置き換えるか、そのリソースを古いリソースタイプバージョンのままにしておく必要があります。
-
-
移行するリソースタイプのリソースごとに、アップグレードマニュアルに記載されている方法でそのリソースグループのリソースの状態を適切な状態に変更してください。次に例を示します。
リソースの監視を解除する必要がある場合:
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 である
-
移行を実行すべきタイミングは「when_offline (リソースがオフラインのとき)」である
-
リソース名は「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 である
-
移行を実行すべきタイミングは「when_unmonitored (リソースの監視が解除しているとき)」である
-
リソース名は「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 が含まれます。
-
ダウングレードしたいリソースを含んでいるリソースグループをオフラインに切り替えます。
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 の概念 (Solaris OS 版)』マニュアルを参照してください。
フェイルオーバーリソースグループを作成する
フェイルオーバーリソースグループは、ネットワークアドレス (組み込みリソースタイプの LogicalHostname や SharedAddress など) と、フェイルオーバーリソース (フェイルオーバーデータサービスのためのデータサービスアプリケーションリソースなど) を含みます。 ネットワークリソースは、データサービスがフェイルオーバーまたはスイッチオーバーする場合に、依存するデータサービスリソースと共に、クラスタノード間を移動します。
追加情報については、scrgadm(1M) のマニュアルページを参照してください。
注 –
この手順は、任意のクラスタノードから実行します。
-
クラスタメンバー上でスーパーユーザーになります。
-
フェイルオーバーリソースグループを作成します。
# scrgadm -a -g resource-group [-h nodelist]
- -a
-
指定したリソースグループを追加します。
- -gresource-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
リソースグループ 名前: resource-group-1
(resource-group-1) リソースグループ RG_description: <NULL>
(resource-group-1) リソースグループ management state: Unmanaged
(resource-group-1) リソースグループ Failback: False
(resource-group-1) リソースグループ Nodelist: phys-schost-1
phys-schost-2
(resource-group-1) リソースグループ Maximum_primaries: 1
(resource-group-1) リソースグループ Desired_primaries: 1
(resource-group-1) リソースグループ RG_dependencies: <NULL>
(resource-group-1) リソースグループ mode: Failover
(resource-group-1) リソースグループ network dependencies: True
(resource-group-1) リソースグループ Global_resources_used: All
(resource-group-1) リソースグループ Pathprefix:
(resource-group-1) リソースグループ System: False
|
次に進む手順
フェイルオーバーリソースグループを作成した後で、そのリソースグループにアプリケーションリソースを追加できます。 手順については、リソースグループへのリソースの追加 を参照してください。
スケーラブルリソースグループを作成する
スケーラブルリソースグループは、スケーラブルサービスと共に使用されます。 共有アドレス機能は、スケーラブルサービスの多数のインスタンスを 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
リソースグループ 名前: resource-group-1
(resource-group-1) リソースグループ RG_description: <NULL>
(resource-group-1) リソースグループ management state: Unmanaged
(resource-group-1) リソースグループ Failback: False
(resource-group-1) リソースグループ Nodelist: phys-schost-1
phys-schost-2
(resource-group-1) リソースグループ Maximum_primaries: 2
(resource-group-1) リソースグループ Desired_primaries: 2
(resource-group-1) リソースグループ RG_dependencies: resource-group-2
(resource-group-1) リソースグループ mode: Scalable
(resource-group-1) リソースグループ network dependencies: True
(resource-group-1) リソースグループ Global_resources_used: All
(resource-group-1) リソースグループ Pathprefix:
|
次に進む手順
スケーラブルリソースグループを作成したあと、そのリソースグループにスケーラブルアプリケーションリソースを追加できます。 詳細は、スケーラブルアプリケーションリソースをリソースグループに追加する を参照してください。
リソースグループへのリソースの追加
リソースは、リソースタイプをインスタンス化したものです。 リソースは、RGM によって管理される前に、リソースグループに追加する必要があります。 この節では、3 種類のリソースタイプについて説明します。
-
論理ホスト名リソース。
-
共有アドレスリソース。
-
データサービス (アプリケーション) リソース。
論理ホスト名リソースと共有アドレスリソースは、常にフェイルオーバーリソースグループに追加してください。 フェイルオーバーデータサービス用のデータサービスリソースは、フェイルオーバーリソースグループに追加してください。 フェイルオーバーリソースグループは、そのデータサービス用の論理ホスト名リソースとアプリケーションリソースの両方を含みます。 スケーラブルリソースグループは、スケーラブルサービス用のアプリケーションリソースだけを含んでいます。 スケーラブルサービスが依存する共有アドレスリソースは、別のフェイルオーバーリソースグループに存在する必要があります。 データサービスをクラスタノード全体に渡ってスケールするには、スケーラブルアプリケーションリソースと共有アドレスリソース間の依存性を指定する必要があります。
リソースに関する詳細は、『 Sun Cluster の概念 (Solaris OS 版)』マニュアルおよび 第 1 章「Sun Cluster データサービスの計画 」 を参照してください。
論理ホスト名リソースをリソースグループに追加する
-
リソースを追加するフェイルオーバーリソースグループの名前
-
リソースグループに追加するホスト名
追加情報については、scrgadm(1M) のマニュアルページを参照してください。
注 –
この手順は、任意のクラスタノードから実行します。
-
クラスタメンバー上でスーパーユーザーになります。
-
論理ホスト名リソースをリソースグループに追加します。
# scrgadm -a -L [-j resource] -g resource-group -l hostnamelist, … [-n netiflist]
- -a
-
論理ホスト名リソースを追加します。
- -L
-
論理ホスト名リソースの形式を指定します。
- -j resource
-
リソース名を指定します (省略可能)。 このオプションを指定しない場合は、デフォルトで -l オプションで最初に指定したホスト名になります。
- -gresource-group
-
リソースを配置するリソースグループの名前を指定します。
- -l hostnamelist, …
-
クライアントがリソースグループでサービスと通信する UNIX ホスト名 (論理ホスト名) をコマンドで区切って指定します。
- -n netiflist
-
各ノード上の IP ネットワークマルチパスグループをコンマで区切って指定します (省略可能)。 netiflist の各要素は、netif@node の形式で指定する必要があります。 netif は IP ネットワークマルチパスグループ名 (sc_ipmp0 など) として指定できます。 ノードは、sc_ipmp0@1、sc_ipmp@phys-schost-1 などのノード名またはノード IDで特定できます。
注 –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 (resource-group-1) リソース 名前: resource-1 (resource-group-1:resource-1) リソース R_description: (resource-group-1:resource-1) リソース リソースタイプ: SUNW.LogicalHostname (resource-group-1:resource-1) リソース タイプのバージョン: 1.0 (resource-group-1:resource-1) リソース リソースグループ名: resource-group-1 (resource-group-1:resource-1) リソース リソースプロジェクト名: default (resource-group-1:resource-1) リソース 有効: False (resource-group-1:resource-1) リソース 有効なモニター: True |
次に進む手順
論理ホスト名リソースを追加したあと、リソースグループをオンラインにする の手順に従って、このリソースをオンラインにします。
共有アドレスリソースをリソースグループに追加する
-
リソースを追加するリソースグループの名前。 このグループは、前の手順で作成したフェイルオーバーリソースグループでなければなりません。
-
リソースグループに追加するホスト名。
追加情報については、scrgadm(1M) のマニュアルページを参照してください。
注 –
この手順は、任意のクラスタノードから実行します。
-
クラスタメンバー上でスーパーユーザーになります。
-
共有アドレスリソースをリソースグループに追加します。
# scrgadm -a -S [-j resource] -g resource-group -l hostnamelist, … \ [-X auxnodelist] [-n netiflist]
- -a
-
共有アドレスリソースを追加します。
- -S
-
共有アドレスリソースの形式を指定します。
- -j resource
-
リソース名を指定します (省略可能)。 このオプションを指定しない場合は、デフォルトで -l オプションで最初に指定したホスト名になります。
- -gresource-group
-
リソースグループの名前を指定します。
- -l hostnamelist, …
-
共有アドレスホスト名をコンマで区切って指定します。
- -X auxnodelist
-
共有アドレスをホストできるクラスタノード (ただし、フェイルオーバー時に稼動系として使用されない) を識別する物理ノード名または ID をコンマで区切って指定します。 これらのノードは、リソースグループのノードリストで潜在的マスターとして識別されるノードと相互に排他的です。
- -n netiflist
-
各ノード上の IP ネットワークマルチパスグループをコンマで区切って指定します (省略可能)。 netiflist の各要素は、netif@node の形式で指定する必要があります。 netif は IP ネットワークマルチパスグループ名 (sc_ipmp0 など) として指定できます。 ノードは、sc_ipmp0@1、sc_ipmp@phys-schost-1 などのノード名またはノード IDで特定できます。
注 –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) リソース 名前: resource-1
(resource-group-1:resource-1) リソース R_description:
(resource-group-1:resource-1) リソース リソースタイプ: SUNW.SharedAddress
(resource-group-1:resource-1) リソース タイプのバージョン: 1.0
(resource-group-1:resource-1) リソース リソースグループ名: resource-group-1
(resource-group-1:resource-1) リソース 有効: False
(resource-group-1:resource-1) リソース リソースプロジェクト名: default
(resource-group-1:resource-1) リソース 有効なモニター: 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) リソース 名前: resource-1
(resource-group-1:resource-1) リソース R_description:
(resource-group-1:resource-1) リソース リソースタイプ: resource-type-1
(resource-group-1:resource-1) リソース タイプのバージョン: 1.0
(resource-group-1:resource-1) リソース リソースグループ名: resource-group-1
(resource-group-1:resource-1) リソース リソースプロジェクト名: default
(resource-group-1:resource-1) リソース 有効: False
(resource-group-1:resource-1) リソース 有効なモニター: 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 「標準プロパティ」 を参照してください。
注 –別のプロパティを設定することもできます。 構成可能なほかのプロパティについては、付録 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) を含むフェイルオーバーリソースグループに依存することに注意してください。 リソースは、以前に定義した 1 つまたは複数のフェイルオーバーリソースグループに存在している共有アドレスリソース (schost-1 と schost-2) に依存しています。
# 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) リソース 名前: resource-1
(resource-group-1:resource-1) リソース R_description:
(resource-group-1:resource-1) リソース リソースタイプ: resource-type-1
(resource-group-1:resource-1) リソース タイプのバージョン: 1.0
(resource-group-1:resource-1) リソース リソースグループ名: resource-group-1
(resource-group-1:resource-1) リソース リソースプロジェクト名: default
(resource-group-1:resource-1) リソース 有効: False
(resource-group-1:resource-1) リソース 有効なモニター: 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 -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
...
|
リソースの無効化とリソースグループの UNMANAGED 状態への移行
リソースグループは、そのリソースグループに対して管理手順を実施する前に、UNMANAGED 状態に移行する必要があります。 リソースグループを UNMANAGED 状態に移行する前に、リソースグループに含まれるすべてのリソースを無効にし、リソースグループをオフラインにする必要があります。
追加情報については、scrgadm(1M) および scswitch(1M) のマニュアルページを参照してください。
注 –
この手順は、任意のクラスタノードから実行します。
リソースを無効にしてリソースグループを UNMANAGED 状態に移行する
この手順を実行するには、次の情報が必要になります。
-
無効にするリソースの名前
-
UNMANAGED 状態に移行するリソースグループの名前
この手順に必要なリソースとリソースグループの名前を判断するには、scrgadm -pv コマンドを使用します。
-
クラスタメンバー上でスーパーユーザーになります。
-
リソースを無効にします。
この手順を、リソースグループ内のすべてのリソースに対して実行します。
# scswitch -n -j resource
- -n
-
リソースを無効にします。
- -j resource
-
無効にするリソースの名前を指定します。
-
次のコマンドを実行し、リソースグループをオフラインに切り替えます。
# scswitch -F -g resource-group
- -F
-
リソースグループをオフラインに切り替えます。
- -g resource-group
-
オフラインにするリソースグループの名前を指定します。
-
リソースグループを UNMANAGED 状態にします。
# scswitch -u -g resource-group
- -u
-
指定したリソースグループを UNMANAGED 状態にします。
- -gresource-group
-
UNMANAGED 状態にするリソースグループの名前を指定します。
-
リソースが無効になり、リソースグループが UNMANAGED 状態になっていることを確認します。
# scrgadm -pv -g resource-group
例 – リソースの無効化とリソースグループの UNMANAGED 状態への移行
次に、リソース (resource-1) を無効にし、リソースグループ (resource-group-1) を UNMANAGED 状態に移行する例を示します。
# scswitch -n -j resource-1 # scswitch -F -g resource-group-1 # scswitch -u -g resource-group-1 # scrgadm -pv -g resource-group-1 リソースグループ 名前: resource-group-1 (resource-group-1) リソースグループ RG_description: <NULL> (resource-group-1) リソースグループ management state: Unmanaged (resource-group-1) リソースグループ Failback: False (resource-group-1) リソースグループ Nodelist: phys-schost-1 phys-schost-2 (resource-group-1) リソースグループ Maximum_primaries: 2 (resource-group-1) リソースグループ Desired_primaries: 2 (resource-group-1) リソースグループ RG_dependencies: <NULL> (resource-group-1) リソースグループ mode: Failover (resource-group-1) リソースグループ network dependencies: True (resource-group-1) リソースグループ Global_resources_used: All (resource-group-1) リソースグループ Pathprefix: (resource-group-1) リソース 名前: resource-1 (resource-group-1:resource-1) リソース R_description: (resource-group-1:resource-1) リソース リソースタイプ: SUNW.apache (resource-group-1:resource-1) リソース タイプのバージョン: 1.0 (resource-group-1:resource-1) リソース リソースグループ名: resource-group-1 (resource-group-1:resource-1) リソース リソースプロジェクト名: default (resource-group-1:resource-1) リソース 有効: True (resource-group-1:resource-1) リソース 有効なモニター: 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 リソースタイプ 名前: SUNW.apache (SUNW.apache) リソースタイプ 説明: Apache Resource Type (SUNW.apache) リソースタイプ ベースディレクトリ: /opt/SUNWscapc/bin (SUNW.apache) リソースタイプ 単一のインスタンス: False (SUNW.apache) リソースタイプ 初期ノード: All potential masters (SUNW.apache) リソースタイプ フェイルオーバー: False (SUNW.apache) リソースタイプ バージョン: 1.0 (SUNW.apache) リソースタイプ API バージョン: 2 (SUNW.apache) リソースタイプ ノードにインストールされている: phys-schost1 phys-schost-2 (SUNW.apache) リソースタイプ パッケージ: SUNWscapc (SUNW.apache) リソースタイプ システム: False |
リソースグループプロパティを変更する
この手順を実行するには、次の情報が必要になります。
-
変更するリソースグループの名前
-
変更するリソースグループプロパティの名前とその新しいプロパティ値
この手順では、リソースグループプロパティの変更方法について説明しています。 リソースグループプロパティの一覧については、付録 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
-
グループをマスターできるすべてのノード上でリソースグループをオフラインにします。
- -gresource-group
-
オフラインに切り替えるリソースグループの名前を指定します。
この状況は STOP メソッドに失敗し、停止に失敗したリソースがリソースグループ内のほかのノードの依存性を持っているときに、リソースグループをオフラインに切り替えた場合に発生します。 これ以外の状況では、手順 4 のコマンドをすべての STOP_FAILED リソースで実行することによって、リソースグループは自動的に ONLINE または OFFLINE 状態に戻ります。
これで、リソースグループを ONLINE 状態に切り替えることができます。
登録済みのリソースタイプの再登録
あらかじめ登録されているリソースタイプには、SUNW.LogicalHostname と SUNW.SharedAddress があります。 すべての論理ホスト名と共有アドレスリソースがこれらのリソースタイプを使用します。 これら 2 つのリソースタイプは、誤って削除した場合を除き、登録する必要はありません。 誤ってリソースタイプを削除した場合は、次の手順を使用して再登録してください。
追加情報については、scrgadm(1M) のマニュアルページを参照してください。
注 –
この手順は、任意のクラスタノードから実行します。
登録済みのリソースタイプを再登録する
- -a
-
リソースタイプを追加します。
- -t SUNW.resource-type
-
追加する (再登録する) リソースタイプを指定します。 リソースタイプは、SUNW.LogicalHostname または SUNW.SharedAddress のいずれかになります。
リソースタイプを再登録します。
# scrgadm -a -t SUNW.resource-type |
例 – 登録済みのリソースタイプの再登録
次に、LogicalHostname リソースタイプを再登録する例を示します。
# scrgadm -a -t SUNW.LogicalHostname |
リソースグループへのノードの追加と削除
この節の手順では、次の作業を行います。
-
リソースグループの追加のマスターとなるクラスタノードを構成する
-
リソースグループからノードを削除する
ノードの追加や削除をフェイルオーバーリソースグループに対して行うのか、スケーラブルリソースグループに対して行うのかによって、手順は異なります。
フェイルオーバーリソースグループは、フェイルオーバーとスケーラブルの両方のサービスによって使用されるネットワークリソースを含みます。 クラスタに接続される各 IP サブネットワークは、指定された独自のネットワークリソースを持ち、フェイルオーバーリソースグループに含まれます。 このネットワークリソースは、論理ホスト名または共有アドレスリソースのいずれかになります。 各ネットワークリソースは、それが使用する IP ネットワークマルチパスグループのリストを含んでいます。 フェイルオーバーリソースグループの場合は、リソースグループ (netiflist リソースプロパティ) に含まれる各ネットワークリソースに対し、IP ネットワークマルチパスグループの完全なリストを更新する必要があります。
スケーラブルリソースグループの場合は、スケーラブルグループをホストの新しいセット上でマスターされるように変更するほかに、スケーラブルリソースによって使用されるネットワークリソースを含むフェイルオーバーグループのための手順も実行する必要があります。
追加情報については、scrgadm(1M) のマニュアルページを参照してください。
注 –
任意のクラスタノードから、以下に説明する手順のいずれかを実行します。
リソースグループにノードを追加する
ノードをリソースグループに追加する手順は、リソースグループがスケーラブルリソースグループか、またはフェイルオーバーリソースグループかによって異なります。 詳細の手順については、以下の節を参照してください。
この手順を実行するには、次の情報が必要になります。
-
すべてのクラスタノードの名前とノード ID
-
ノードが追加されるリソースグループの名前
-
すべてのノード上のリソースグループによって使用されるネットワークリソースをホストする IP ネットワークマルチパスグループの名前
さらに、新しいノードがすでにクラスタメンバーになっていることも確認してください。
スケーラブルリソースグループにノードを追加する
-
リソースグループ内のスケーラブルリソースが使用する各ネットワークリソースごとに、そのネットワークリソースが配置されているリソースグループが新しいノードで実行されるようにします。
-
スケーラブルリソースグループをマスターできるノードのリスト (nodelist リソースグループプロパティ) に新しいノードを追加します。
この手順は、nodelist の値を上書きするため、リソースグループをマスターできるすべてのノードをここに含める必要があります。
# scrgadm -c -g resource-group -h nodelist
- -c
-
リソースグループを変更します。
- -gresource-group
-
ノードが追加されるリソースグループの名前を指定します。
- -hnodelist
-
リソースグループをマスターできるノードをコンマで区切って指定します。
-
(省略可能) スケーラブルリソースの Load_balancing_weights プロパティを更新し、リソースグループに追加するノードにウエイトを割り当てます。
ウエイトを割り当てない場合は、デフォルトで 1 になります。 詳細は、scrgadm(1M) のマニュアルページを参照してください。
フェイルオーバーリソースグループにノードを追加する
-
現在のノードリスト、およびリソースグループ内の各リソース用に構成された IP ネットワークマルチパスグループの現在のリストを表示します。
# scrgadm -pvv-gresource-group | grep -i nodelist # scrgadm -pvv-gresource-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
-
リソースグループを変更します。
- -gresource-group
-
ノードが追加されるリソースグループの名前を指定します。
- -hnodelist
-
リソースグループをマスターできるノードをコンマで区切って指定します。
-
更新された情報を確認します。
# scrgadm -pvv-gresource-group | grep -i nodelist # scrgadm -pvv-gresource-group | grep -i netiflist
例 – リソースグループへのノードの追加
次に、リソースグループ (resource-group-1) にノード (phys-schost-2) を追加する例を示します。このリソースグループは、論理ホスト名リソース (schost-2) を含んでいます。
# scrgadm -pvv -g resource-group-1 | grep -i nodelist (resource-group-1) リソースグループ Nodelist: phys-schost-1 phys-schost-3 # scrgadm -pvv-g resource-group-1 | grep -i netiflist (resource-group-1:schost-2) リソース property name: NetIfList (resource-group-1:schost-2:NetIfList) リソース property class: extension (resource-group-1:schost-2:NetIfList) List of IP Networking Multipathing interfaces on each node (resource-group-1:schost-2:NetIfList) リソース property type: stringarray (resource-group-1:schost-2:NetIfList) リソース 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) リソースグループ 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) リソース 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 の概念 (Solaris OS 版)』のマニュアルを参照してください。
スケーラブルリソースグループからノードを削除すると、そのスケーラブルサービスはそのノード上でオンラインにすることができなくなります。 スケーラブルリソースグループからノードを削除するには、以下の作業を行なってください。
-
スケーラブルリソースグループをマスターできるノードのリスト (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 -inodelist # scrgadm -pvv -g failover-resource-group | grep -inetiflist
共有アドレスリソースを含むフェイルオーバーリソースグループからノードを削除する
スケーラブルサービスが使用する共有アドレスリソースを含むフェイルオーバーリソースグループでは、ノードは次の場所に現れます。
-
フェイルオーバーリソースグループのノードリスト
-
共有アドレスリソースの 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) リソースグループ 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) リソース property name: NetIfList (resource-group-1:schost-1:NetIfList) リソース property class: extension (resource-group-1:schost-1:NetIfList) List of IP Networking Multipathing interfaces on each node (resource-group-1:schost-1:NetIfList) リソース property type: stringarray (resource-group-1:schost-1:NetIfList) リソース property value: sc_ipmp0@1 sc_ipmp0@2 sc_ipmp0@3 (sc_ipmp0@3 is the IP Networking Multipathing group to be removed.) # scrgadm -c -jschost-1-xnetiflist=sc_ipmp0@1,sc_ipmp0@2 # scrgadm -pvv -g resource-group-1 | grep -i nodelist (resource-group-1) リソースグループ Nodelist: phys-schost-1 phys-schost-2 # scrgadm -pvv-g resource-group-1 | grep -i netiflist (resource-group-1:schost-1:NetIfList) リソース 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 Java System Web Server (/global/resource-group-1 に依存する)
-
Oracle (/dev/global/dsk/d5s2 に依存する)
-
NFS (dsk/d6 に依存する)
新しいリソースに対し、HAStorage リソースの hastorage-1 を resource-group-1 に作成するには、リソースグループとディスクデバイスグループ間での起動の同期 を読み、その後次の手順を実行します。
HAStoragePlus リソースタイプを作成するには、HA ローカルファイルシステムの有効化 を参照してください。
-
クラスタメンバー上でスーパーユーザーになります。
-
リソースグループ 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 Java System Web Server、Oracle、NFS を resource-group-1 に追加し、これらの依存性を hastorage-1 に設定します。
たとえば、Sun Java System Web Server の場合、次のコマンドを実行します。
# scrgadm -a -jresource -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 を MANAGED 状態に設定し、オンラインにします。
# scswitch -Z -g resource-group-1
HAStorage リソースタイプは、別の拡張プロパティ (AffinityOn) を含みます。この拡張プロパティは、HAStorage が ServicePaths で定義されているグローバルデバイスおよびクラスタファイルシステムのアフィニティスイッチオーバーを実行する必要があるかどうかを指定するブール値です。 詳細は、SUNW.HAStorage(5) のマニュアルページを参照してください。
注 –
リソースグループがスケーラブルの場合、HAStorage と HAStoragePlus は AffinityOn が TRUE に設定されることを許可しません。 スケーラブルリソースグループについては、HAStorage と HAStoragePlus は AffinityOn 値をチェックし、この値を内部的に FALSE に設定し直します。
既存のリソース用に HAStorage リソースタイプを設定する
HAStorage は、今後の Sun Cluster でサポートされなくなる可能性があります。 同等の機能が HAStoragePlus でサポートされています。 HAStorage から HAStoragePlus へアップグレードするには、HAStorage から HAStoragePlus へのアップグレード を参照してください。
既存のリソースのために 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 で単純な 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
-
/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
HA ローカルファイルシステムの有効化
HAStoragePlus リソースタイプを使用すると、ローカルファイルシステムを Sun Cluster 環境内で高可用性にすることができます。 このためには、ローカルファイルシステムのパーティションがグローバルディスクグループに存在し、アフィニティスイッチオーバーが有効であり、Sun Cluster 環境がフェイルオーバー用に構成されている必要があります。 これによって、多重ホストディスクに直接接続された任意のホストから、多重ホストディスク上の任意のファイルシステムにアクセスできるようになります。 (HAStoragePlus では、ルートファイルシステムを高可用性にすることはできません)。 フェイルバック設定は、リソースグループとデバイスグループで同一にする必要があります。
入出力の多いデータサービスの中には、HA ローカルファイルシステムの使用が強く望まれるものがあります。このため、このようなデータサービスの登録作業と構成作業には、HAStoragePlus リソースタイプを構成する方法が追加されています。 これらのデータサービスの HAStoragePlus リソースタイプを設定する手順については、以下の節を参照してください。
-
『 Sun Cluster Data Service for Oracle ガイド (Solaris OS 版)』の「Sun Cluster HA for Oracle の登録と構成」
-
『 Sun Cluster Data Service for Sybase ASE ガイド (Solaris OS 版)』の「Sun Cluster HA for Sybase ASE の登録と構成」
ほかのデータサービスの HAStoragePlus リソースタイプを設定する方法については、HAStoragePlus リソースタイプを設定するを参照してください。
HAStoragePlus リソースタイプを設定する
HAStoragePlus リソースタイプは Sun Cluster 3.0 5/02 で導入されています。この新しいリソースタイプは、HAStorage と同じ機能を果たし、リソースグループとディスクデバイスグループ間で起動を同期します。 HAStoragePlus リソースタイプには、ローカルファイルシステムを高可用性にするための機能が追加されています。 (ローカルファイルシステムの可用性を高めるための背景情報については、HA ローカルファイルシステムの有効化 を参照してください)。 これら 2 つの機能を両方とも使用するには、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 -tSUNW.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 サーバーが起動する前にローカルにマウントされます。
プライオリティが低いリソースグループをオフロードすることによるノードリソースの解放
プライオリティ付きサービス管理 (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
SPARC: 例 – 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 をゼロに設定する] |
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 に含まれてはいけません。
デフォルト: なし 調整:任意の時点 |
|
continue_to_offload (ブール型) |
リソースグループのオフロード中にエラーが発生した後に、rg_to_offload リスト内の残りのリソースグループをオフロードし続けるかどうかを示すブール型。
このプロパティは START メソッドだけが使用します。
デフォルト: True 調整:任意の時点 |
|
max_offload_retry (整数) |
クラスタまたはリソースグループの再構成による障害時の起動中に、リソースグループをオフロードしようとする回数。 再試行の間には 10 秒の間隔があります。
(オフロードされるリソースグループの数 * max_offload_retry * 10 秒) が
RGOffload リソースの Start_timeout よりも小さくなるように
max_offload_retry を設定します。 この値が Start_timeout の値に近い (あるいは、より大きい) 場合、最大再試行数に到達する前に、RGOffload リソースの START メソッドがタイムアウトする可能性があります。
このプロパティは START メソッドだけが使用します。
デフォルト: 15 調整:任意の時点 |
フォルトモニター
RGOffload リソースのフォルトモニター検証は、プライオリティが高いリソースをマスターするノード上で、rg_to_offload 拡張プロパティに指定されたリソースグループをオフラインにし続けるために使用されます。 各検証サイクルでフォルトモニターは、プライオリティが高いリソースをマスターするノード上で、オフロードされるリソースグループ (offload-rg) がオフラインであることを確認します。 プライオリティが高いリソースをマスターするノード上で offload-rg がオンラインである場合、フォルトモニターは重要なリソースをマスターするノード以外のノード上で offload-rg を起動し、同時に、プライオリティが高いリソースをマスターするノード上では offload-rg をオフラインにしようとします。
offload-rg の desired_primaries はゼロに設定されているので、この後で利用可能になったノード上では、オフロードするリソースグループは再起動されません。 したがって、RGOffload フォルトモニターは maximum_primaries に到達するまで、重要なリソースをマスターするノード上では offload-rg をオフラインにしながら、可能な限りのプライマリ上で offload-rg を起動しようとします。
RGOffload は、MAINTENANCE 状態または UNMANAGED 状態でないかぎり、オフロードされたすべてのリソースを起動しようとします。 リソースグループを UNMANAGED 状態にするには、scswitch コマンドを使用します。
# scswitch -u -g resourcegroup |
フォルトモニター検証サイクルは、Thorough_probe_interval が実行されたあとにかならず呼び出されます。
- © 2010, Oracle Corporation and/or its affiliates