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

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

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

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

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

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

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

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


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

注 –

この章の手順では、scrgadm(1M) コマンドを使用し、これらの作業を完了する方法について解説します。これ以外のツールを使ってリソースを管理することもできます。このようなオプションの詳細については、「データサービスリソースを管理するためのツール」を参照してください。

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

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

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

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

リソースタイプの登録

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

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

注 –

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

始める前に

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

手順

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

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

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

-t resource-type

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

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

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

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

# scrgadm -a -t SUNW.iws
# scrgadm -pv -t SUNW.iws
リソースタイプ 名前:                                     SUNW.iws
  (SUNW.iws) リソースタイプ 説明:                        None registered
  (SUNW.iws) リソースタイプ ベースディレクトリ:            /opt/SUNWschtt/bin
  (SUNW.iws) リソースタイプ 単一のインスタンス:            False
  (SUNW.iws) リソースタイプ 初期ノード:                   All potential masters
  (SUNW.iws) リソースタイプ フェイルオーバー:              False
  (SUNW.iws) リソースタイプ バージョン:                   1.0
  (SUNW.iws) リソースタイプ API バージョン:               2
  (SUNW.iws) リソースタイプ ノードにインストールされている:   All
  (SUNW.iws) リソースタイプ パッケージ:                   SUNWschtt

次の手順

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

参照

scrgadm(1M) のマニュアルページ。

リソースタイプの更新

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

リソースタイププロパティーのデフォルト設定が変更されている場合がある。
リソースタイプの新しい拡張プロパティーが導入されている場合がある。
リソースタイプの既存の拡張プロパティーがなくなっている場合がある。
リソースタイプに対して宣言されている標準プロパティーのセットが変更される場合がある。
min、 max、arraymin、arraymax、default、および tunability などのリソースプロパティーの属性が変更される場合がある。
宣言済みメソッドのセットが異なる場合がある。
メソッドまたは障害モニターの実装が変更される場合がある。

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

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

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

始める前に

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

非クラスタモードでノードを再起動する。
ノードをクラスタモードで動作させ続け、リソースタイプのすべてのインスタンスの監視をオフにする。
ノードをクラスタモードで動作させ続け、リソースタイプのすべてのインスタンスに対して監視をオンのままにする。

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

手順

スーパーユーザーになるか、同等の役割になります。

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

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

正しいバージョンのリソースタイプを登録するには、次の情報を指定する必要があります。
- リソースタイプ名
- リソースタイプを定義するリソースタイプ登録 (RTR) ファイル
# scrgadm -a -t resource-type-name -f path-to-new-rtr-file
リソースタイプ名の形式は次のとおりです。
```
vendor-id.base-rt-name:rt-version
```
この形式の詳細については、「リソースタイプ名の形式」を参照してください。

新しく登録されたリソースタイプを表示します。
# scrgadm -pv -t resource-type-name

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

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

リソースタイプのインスタンスを含むすべてのリソースグループの nodelist プロパティーは、リソースタイプの Installed_nodes プロパティーのサブセットである必要があります。
# scrgadm -c -t resource-type -h installed-node-list

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

始める前に

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

任意の時点 (Anytime)
リソースが監視されていないときのみ
リソースがオフラインのときのみ
リソースが無効のときのみ
リソースグループが管理されていないときのみ

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

リソースを削除し、アップグレードされたバージョンの新しいリソースに置き換える
リソースタイプの古いバージョンでリソースから離脱する

手順

スーパーユーザーになるか、同等の役割になります。

移行するリソースタイプの各リソースに関して、リソースまたはリソースグループの状態を適切な状態に変更します。
- 任意の時点でリソースを移行できる場合、アクションは必要ありません。
- リソースが監視されていない場合にのみリソースを移行できる場合は、次のコマンドを入力します。
  # scswitch -M -n -j resource
- リソースがオフラインである場合にのみリソースを移行できる場合は、次のコマンドを入力します。
  # scswitch -n -j resource
  注 –
  移行するリソースにそのほかのリソースが依存している場合、この手順は失敗します。このような場合は、出力されるエラーメッセージを参照して、依存しているリソースの名前を判別します。続いて、移行するリソースと依存するリソースを含むコンマ区切りリストを指定して、この手順を繰り返します。
- リソースが無効である場合にのみリソースを移行できる場合は、次のコマンドを入力します。
  # scswitch -n -j resource
  注 –
  移行するリソースにそのほかのリソースが依存している場合、この手順は失敗します。このような場合は、出力されるエラーメッセージを参照して、依存しているリソースの名前を判別します。続いて、移行するリソースと依存するリソースを含むコンマ区切りリストを指定して、この手順を繰り返します。
- リソースグループが管理されていない場合にのみリソースを移行できる場合は、次のコマンドを入力します。
  # scswitch -n -j resource-list # scswitch -F -g resource-group # scswitch -u -g resource-group
  上記コマンドの各項目の意味は次のとおりです。
  
  resource-list
  
  管理されていないリソースグループにあるすべてのリソースのコンマ区切りリストを指定します。
  
  resource-group
  
  管理されていないリソースグループを指定します。
  
  注 –
  resource-list では任意の順序でリソースを指定できます。scswitch コマンドにより、resource-list での順序に関係なく、リソース間の依存関係を満たすのに必要な順序でリソースが無効になります。

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

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

そのほかのプロパティーを設定する必要があるかどうかを判別するには、リソースタイプをアップグレードするための手順を参照してください。次の理由により、そのほかのプロパティーを設定しなければならない場合があります。
- 新しいバージョンのリソースタイプに拡張プロパティーが導入されている。
- 既存のプロパティーのデフォルト値が、新しいバージョンのリソースタイプにおいて変更されている。
# scrgadm -c -j resource -y Type_version=new-version \ [-x extension-property=new-value][ -y standard-property=new-value]
注 –
既存のバージョンのリソースタイプが、新しいバージョンへのアップグレードをサポートしていない場合、この手順は失敗します。

手順 2で入力したコマンドを逆にすることで、リソースまたはリソースグループの以前の状態を回復します。
- 任意の時点でリソースを移行できる場合、アクションは必要ありません。
  
  注 –
  いつでも移行できるリソースを移行した後、リソースの検証により、リソースタイプのバージョンが正しく表示されないことがあります。このような状況が発生した場合、リソースの障害モニターを一度無効にし、有効にし直すると、リソースの検証において、リソースタイプのバージョンが正しく表示されます。
- リソースが監視されていない場合にのみリソースを移行できる場合は、次のコマンドを入力します。
  # scswitch -M -e -j resource
- リソースがオフラインである場合にのみリソースを移行できる場合は、次のコマンドを入力します。
  # scswitch -e -j resource
  注 –
  手順 2で、移行するリソースに依存するそのほかのリソースを無効にした場合、依存するリソースも有効にします。
- リソースが無効である場合にのみリソースを移行できる場合は、次のコマンドを入力します。
  # scswitch -e -j resource
  注 –
  手順 2で、移行するリソースに依存するそのほかのリソースを無効にした場合、依存するリソースも有効にします。
- リソースグループが管理されていない場合にのみリソースを移行できる場合は、次のコマンドを入力します。
  # scswitch -e -j resource-list # scswitch -o -g resource-group # scswitch -z -g resource-group

例 2–2 オフラインである場合にのみ移行可能なリソースの移行

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

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

新しいリソースタイプバージョンは 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–3 監視対象外である場合にのみ移行可能なリソースの移行

この例では、リソースが監視対象外である場合にのみ移行可能なリソースの移行を示します。新しいリソースタイプパッケージには、モニターと 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
Type_version プロパティーを新しいバージョンに変更するには、次のコマンドを実行します。
# scrgadm -c -j myresource -y Type_version=2.0
移行後リソースの監視を有効にするには、次のコマンドを実行します。
# scswitch -M -e -j myresource

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

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

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

手順

スーパーユーザーになるか、同等の役割になります。

ダウングレードするリソースを含むリソースグループをオフラインに切り替えます。
scswitch -F -g resource-group

ダウングレードするリソースを含むリソースグループのすべてのリソースを無効にします。
scswitch -n -j resource-list
注 –
resource-list では任意の順序でリソースを指定できます。scswitch コマンドにより、resource-list での順序に関係なく、リソース間の依存関係を満たすのに必要な順序でリソースが無効になります。

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

ダウングレードするリソースを含むリソースグループの管理を解除します。
scswitch -u -g resource-group

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

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

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

必要に応じて、同じコマンドを使って、同じリソースのその他のプロパティーに適切な値を設定します。
scrgadm -c -j resource-todowngrade -y Type_version=old-version

手順 3で無効にしたすべてのリソースを有効にします。
# scswitch -e -j resource-list

ダウングレードしたリソースを含むリソースグループを管理状態にします。
# scswitch -o -g resource-group

ダウングレードしたリソースを含むリソースグループをオンラインにします。
# scswitch -z -g resource-group

リソースグループの作成

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

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

以下の手順では、scrgadm(1M) コマンドを使用し、データサービスを登録、構成する方法について解説します。

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

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

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

ネットワークアドレスリソース (組み込みリソースタイプ LogicalHostname および SharedAddress のインスタンス)
フェイルオーバーリソース (フェイルオーバーデータサービスのデータサービスアプリケーションリソース)

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

注 –

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

手順

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

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

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

-g resource-group

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

-h nodelist

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

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

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

次に、 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:

次の手順

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

参照

scrgadm(1M) のマニュアルページ。

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

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

注 –

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

手順

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

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

スケーラブルリソースグループを作成します。
# 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–5 スケーラブルリソースグループの作成

次に、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:

次の手順

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

参照

scrgadm(1M) のマニュアルページ。

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

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

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

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

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

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

注 –

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

注 –

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

始める前に

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

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

手順

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

論理ホスト名リソースをリソースグループに追加します。
# 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

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

次に、論理ホスト名リソース (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) リソース 名前:                              resource-1
  (resource-group-1:resource-1) リソース R_description:
  (resource-group-1:resource-1) 
  リソース  リソースタイプ:        SUNW.LogicalHostname
  (resource-group-1:resource-1) リソース リソースグループ名:  resource-group-1
  (resource-group-1:resource-1) リソース 有効:              False
  (resource-group-1:resource-1) リソース 有効なモニター:      True

例 2–7 IP ネットワークマルチパスグループを識別する論理ホスト名リソースの追加

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

cs23-rs という名前のリソースが、ノード 1 および 2 上で IP ネットワークマルチパスグループ sc_ipmp0 を識別します。
cs24-rs という名前のリソースが、ノード 1 および 2 上で IP ネットワークマルチパスグループ sc_ipmp1 を識別します。

# scrgadm -a -L -j cs23-rs -g nfs-fo-rg -l cs23-rs -n sc_ipmp0@1,sc_ipmp0@2
# scrgadm -a -L -j cs24-rs -g nfs-fo-rg -l cs24-rs -n sc_ipmp1@1,sc_ipmp1@2

次の手順

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

注意事項

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

参照

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

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

次に、共有アドレスリソース (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) リソース リソースグループ名:  resource-group-1
    (resource-group-1:resource-1) リソース 有効:              False
    (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 「標準プロパティー」を参照してください。

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

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

次に、リソース (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) リソース リソースグループ名:  resource-group-1
    (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, …: リソース用に設定する標準プロパティーのコンマ区切りリストを指定します。設定できる標準プロパティーはリソースタイプに依存します。スケーラブルサービスの場合、通常は Port_list、Load_balancing_weights、および Load_balancing_policy プロパティーを設定します。どの標準プロパティーを設定するかを決定するには、リソースタイプのマニュアルと付録 A 「標準プロパティー」を参照してください。

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

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

次に、リソース (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) リソース 名前:                                resource-1
    (resource-group-1:resource-1) リソース R_description:
    (resource-group-1:resource-1) リソース リソースタイプ:      resource-type-1
    (resource-group-1:resource-1) リソース リソースグループ名:  resource-group-1
    (resource-group-1:resource-1) リソース 有効:              False
    (resource-group-1:resource-1) リソース 有効なモニター:      True

次の手順

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

注意事項

参照

scrgadm(1M) のマニュアルページ。

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

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

リソースグループでのリソースの有効化
リソースモニターの有効化
リソースグループを管理対象にする
リソースグループをオンラインにする

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

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

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

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

手順

クラスタメンバーから、スーパーユーザーになるか、同等の役割を引き受けます。

コマンドを入力してリソースグループをオンラインにします。
- 無効のままでなければならないリソースまたは障害モニターを意図的に無効にしている場合は、次のコマンドを入力します。
  # scswitch -z -g rg-list
  -z
  
  リソースと障害モニターを有効にすることなく、リソースグループをオンラインにします。
  
  -g rg-list
  
  オンラインにするリソースグループの名前をコンマで区切って指定します。これらのリソースグループは存在する必要があります。このリストには、1 つまたは複数のリソースグループ名を指定できます。
  
  -g rg-list オプションは省略できます。このオプションを省略した場合、すべてのリソースグループがオンラインになります。
- リソースグループがオンラインになった時点でリソースと障害モニターを有効にする必要がある場合は、次のコマンドを入力します。
  # scswitch -Z -g rg-list
  -Z
  
  リソースと障害モニターを有効にしたあとで、リソースグループをオンラインにします。
  
  -g rg-list
  
  オンラインにするリソースグループの名前をコンマで区切って指定します。これらのリソースグループは存在する必要があります。このリストには、1 つまたは複数のリソースグループ名を指定できます。
  
  -g rg-list オプションは省略できます。このオプションを省略した場合、すべてのリソースグループがオンラインになります。
注 –
オンラインにしようとしている任意のリソースグループがほかのリソースグループに対して強いアフィニティーを宣言している場合、この操作は失敗します。詳細については、「オンラインのリソースグループをクラスタノード間で分散する」を参照してください。

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

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

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

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

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

次の手順

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

参照

scswitch(1M) マニュアルページ。

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

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

追加情報については、scswitch(1M) のマニュアルページを参照してください。

注 –

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

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

手順

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

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

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

-M

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

-j resource

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

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

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

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

この例では、リソースフォルトモニターを無効にします。

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

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

手順

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

リソースフォルトモニターを有効にします。
# scswitch -e -M -j resource
-e

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

-M

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

-j resource

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

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

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

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

この例では、リソースフォルトモニターを有効にします。

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

リソースタイプの削除

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

注 –

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

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

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

始める前に

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

# 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

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

次に、リソースタイプのすべてのリソース (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)

リソースグループの削除

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

注 –

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

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

始める前に

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

# scrgadm -pv

手順

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

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

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

-g resource-group

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

リソースグループ内の削除するすべてのリソースを無効にします。
# scswitch -n -j resource
-n

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

-j resource

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

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

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

リソースごとに次のコマンドを入力します。
# scrgadm -r -j resource
-r

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

-j resource

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

リソースグループの削除
# scrgadm -r -g resource-group
-r

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

-g resource-group

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

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

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

次に、リソースグループ (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

例 2–16 リソースの削除

次に、リソース 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

リソースグループをオンラインにするか、オンラインのままにしておくノードの名前をコンマで区切って指定します。このリストには、1 つまたは複数のノード名を指定できます。このリソースグループは、このノード以外のすべてのノードでオフラインに切り替えられます。

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

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

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

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

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

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

phys-schost-1# scstat -g
...-- Resource Groups --

            Group Name          Node Name           State
            ----------          ---------           -----
     Group: resource-group-1    phys-schost-1       Online
     Group: resource-group-1    phys-schost-2       Offline...

切り替えを実行するには、次のコマンドを実行します。
phys-schost-1# scswitch -z -g resource-group-1 -h phys-schost-2

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

phys-schost-1# scstat -g
...-- Resource Groups --

            Group Name          Node Name           State
            ----------          ---------           -----
     Group: resource-group-1    phys-schost-1       Offline
     Group: resource-group-1    phys-schost-2       Online...

参照

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

scrgadm(1M)
scswitch(1M)

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

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

追加情報については、scrgadm(1M) および scswitch(1M) のマニュアルページを参照してください。

注 –

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

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

注 –

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

始める前に

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

無効にするリソースの名前
UNMANAGED 状態にするリソースグループの名前

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

# scrgadm -pv

手順

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

リソースグループのすべてのリソースを無効にします。
# scswitch -n -j resource-list
-n

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

-j resource-list

リソースグループのリソースのコンマ区切りリストを指定します。

注 –
resource-list では任意の順序でリソースを指定できます。scswitch コマンドにより、resource-list での順序に関係なく、リソース間の依存関係を満たすのに必要な順序でリソースが無効になります。

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

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

-g resource-group

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

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

指定したリソースグループを UNMANAGED にします。

-g resource-group

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

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

例 2–18 リソースの無効化とリソースグループの `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) リソース リソースグループ名:  resource-group-1
    (resource-group-1:resource-1) リソース 有効:             True
    (resource-group-1:resource-1) リソース 有効なモニター:     False
    (resource-group-1:resource-1) リソース detached:         False

参照

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

scrgadm(1M)
scswitch(1M)

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

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

注 –

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

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

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

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

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

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

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

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

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

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

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

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

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

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

注 –

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

始める前に

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

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

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

手順

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

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

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

リソースタイプの場合、特定のプロパティーだけを変更できます。プロパティーを変更できるかどうかを判断するには、「リソースタイププロパティー」でプロパティーの Tunable エントリを参照してください。
# scrgadm -c -t resource-type \ [-h installed-node-list] \ [-y property=new-value]
-c

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

-t resource-type

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

-h installed-node-list

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

-y property =new-value

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

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

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

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

次に、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

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

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

注 –

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

始める前に

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

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

手順

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

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

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

-g resource-group

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

-y property

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

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

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

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

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

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

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

標準リソースプロパティーの詳細については、「リソースのプロパティー」を参照してください。
リソースの拡張プロパティーの詳細については、リソースのリソースタイプのマニュアルを参照してください。

注 –

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

始める前に

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

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

手順

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

現在のリソースプロパティー設定を表示します。
# scrgadm -pvv -j resource

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

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

-j resource

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

-y standard-property =new-value

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

-x extension-property =new-value

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

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

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

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

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

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

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

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

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

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

注 –

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

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

注 –

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

手順

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

リソースプロパティーを変更します。
# scrgadm -c -j resource -x CheckNameService=false
-j resource

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

-y CheckNameService=false

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

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

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

個々のリソースは STOP_FAILED 状態になります。
リソースを含むリソースグループは ERROR_STOP_FAILED 状態になります。

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

任意のノードでリソースグループをオンラインにする
リソースグループにリソースを追加する
リソースグループからリソースを削除する
リソースグループのプロパティーを変更する
リソースグループのリソースのプロパティーを変更する

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

注 –

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

始める前に

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

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

手順

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

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

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

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

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

フラグを消去します。

-h nodelist

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

-j resource

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

-f STOP_FAILED

フラグ名を指定します。

手順 4で STOP_FAILED フラグを消去したノードで、リソースグループの状態を調べます。
# scstat -g
リソースグループの状態は、OFFLINE または ONLINE になっています。

次の環境の組み合わせでは、リソースグループは ERROR_STOP_FAILED 状態のままになっています。
- STOP メソッドの失敗が発生した時点でリソースグループがオフラインに切り替えられている。
- 停止に失敗したリソースがリソースグループ内のそのほかのリソースに依存している。

リソースグループが ERROR_STOP_FAILED 状態のままである場合、次のようにエラーを修正します。
1. 適切なノード上でリソースグループをオフラインにします。
  # scswitch -F -g resource-group
  -F
  
  グループをマスターできるすべてのノード上でリソースグループをオフラインにします。
  
  -g resource-group
  
  オフラインに切り替えるリソースグループの名前を指定します。
2. リソースグループをオンラインにします。

参照

scswitch(1M) マニュアルページ。

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

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

SUNW.LogicalHostname は、論理ホスト名を表現します。
SUNW.SharedAddress は、共有アドレスを表現します。

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

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

以前のバージョンの Sun Cluster からアップグレードしている場合。
リソースタイプの新機能を使用する必要がある場合。

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

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

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

リソースタイプ	リソースタイプバージョン	Sun Cluster のリリース
`SUNW.LogicalHostname`	1.0	3.0
`SUNW.LogicalHostname`	2	3.1 9/04
`SUNW.SharedAddress`	1.0	3.0
`SUNW.SharedAddress`	2	3.1 9/04

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

scrgadm -p
scrgadm -pv

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

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

# scrgadm -a -t SUNW.LogicalHostname:2

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

次に、事前登録されているリソースタイプのインスタンスを移行する必要がある情報を示します。

移行はいつでも実行できます。
事前登録されているリソースタイプの新機能を使用する必要がある場合、Type_version プロパティーの値が 2 である必要があります。
ネームサービスをバイパスするようにリソースを変更する場合は、リソースの CheckNameService 拡張プロパティーを false に設定します。

例 2–24 論理ホスト名リソースの移行

この例では、論理ホスト名リソース lhostrs を移行するためのコマンドを示します。移行の結果として、このリソースは名前解決用のネームサービスをバイパスするように変更されます。

# scrgadm -c -j lhostrs -y Type_version=2 -x CheckNameService=false

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

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

注 –

事前登録されているリソースタイプをアップグレードしている場合は、「事前登録されているリソースタイプのアップグレード」の指示に従って、新しいリソースタイプのバージョンを登録してください。

注 –

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

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

手順

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

# scrgadm -a -t SUNW.resource-type

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

例 2–25 事前登録されているリソースタイプを誤って削除したあとに再登録する

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

# scrgadm -a -t SUNW.LogicalHostname

参照

scrgadm(1M) のマニュアルページ。

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

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

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

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

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

スケーラブルリソースグループの手順には、次の手順が含まれます。

スケーラブルリソースによって使用されるネットワークリソースを含むフェイルオーバーグループのための手順を繰り返す
スケーラブルグループをホストの新しいセット上でマスターされるように変更する

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

注 –

いずれの手順も任意のクラスタノードから実行できます。

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

ノードをリソースグループに追加する手順は、リソースグループがスケーラブルリソースグループであるか、またはフェイルオーバーリソースグループであるかによって異なります。詳細の手順については、以下の節を参照してください。

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

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

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

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

手順

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

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

スケーラブルリソースグループをマスターできるノードのリスト (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 など) で識別できます。

HAStorage または HAStoragePlus AffinityOn 拡張プロパティーが True に等しい場合、適切なディスクセットまたはデバイスグループにノードを追加します。
- Solstice DiskSuite または Solaris Volume Manager を使用している場合は、metaset コマンドを使用します。
  # metaset -s disk-set-name -a -h node-name
  -s disk-set-name
  
  metaset コマンドの実行対象となるディスクセットの名前を指定します。
  
  -a
  
  指定したディスクセットにドライブまたはホストを追加します。
  
  -h node-name
  
  ディスクセットに追加するノードを指定します。
- SPARC:VERITAS Volume Manager を使用している場合は scsetup ユーティリティーを使用します。
  1. アクティブなクラスタメンバー上で scsetup ユーティリティーを起動します。
    # scsetup
    メインメニューが表示されます。
  2. メインメニューで、デバイスグループおよびボリュームのオプションに対応する数字を入力します。
  3. 「Device Groups」メニューで、ノードを VxVM デバイスグループに追加するためのオプション対応する数字を入力します。
  4. プロンプトに応答し、VxVM デバイスグループにノードを追加します。

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

この手順は、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

例 2–26 リソースグループにノードを追加する

次に、リソースグループ (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 ネットワークマルチパス
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
# metaset -s red -a -h phys-schost-2
# 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 -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) リソース グループ 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 ネットワークマルチパス 
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 は削除される 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) リソース グループ 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 リソースタイプを使用します。広域デバイスやクラスタファイルシステムに依存するデータサービスリソースを持つすべてのリソースグループに、HAStorage または HAStoragePlus のインスタンスを追加します。このようなリソースタイプのインスタンスは、次の操作を実行します。

広域デバイスとクラスタファイルシステムを監視する
広域デバイスとクラスタファイルシステムが利用可能になるまで、同じリソースグループ内のほかのリソースの START メソッドを待機させる

どちらのリソースタイプを使用するかを決定するには、「HAStorage または HAStoragePlus の選択」を参照してください。

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

HAStoragePlus リソースを作成するには、「NFS エクスポートファイルシステム用に HAStoragePlus リソースタイプを設定する」を参照してください。

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

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

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

Sun Java System 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 Java System Web Server、Oracle、NFS を resource-group-1 に追加し、これらの依存性を hastorage-1 に設定します。

たとえば、Sun Java System 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 を MANAGED 状態に設定し、オンラインにします。
# scswitch -Z -g resource-group-1

アフィニティースイッチオーバー

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

注 –

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

既存のリソース用に `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 で単純な 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 リソースを作成します。

注 –
HAStorage の ServicePaths プロパティーを使用する代わりに、HAStoragePlus の FilesystemMountPoints プロパティーまたは GlobalDevicePaths プロパティーを使用する必要があります。
- ファイルシステムのマウントポイントを指定するには、次のコマンドを入力します。
  
  FilesystemMountPoints 拡張プロパティーは、/etc/vfstab で指定されたシーケンスと一致する必要があります。
  # 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

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

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

CFS による `HAStorage` からフェイルオーバーファイルシステムによる `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 リソースを作成します。

注 –
HAStorage の ServicePaths プロパティーを使用する代わりに、HAStoragePlus の FilesystemMountPoints プロパティーまたは GlobalDevicePaths プロパティーを使用する必要があります。
- ファイルシステムのマウントポイントを指定するには、次のコマンドを入力します。
  
  FilesystemMountPoints 拡張プロパティーは、/etc/vfstab で指定されたシーケンスと一致する必要があります。
  # 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

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

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

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

高可用性ローカルファイルシステムを使用すると、出入力負荷が高いデータサービスのパフォーマンスを改善できます。Sun Cluster 環境でローカルファイルシステムを高可用性にするには、HAStoragePlus リソースタイプを使用します。

出入力負荷が高い各 Sun Cluster データサービスの作業手順では、データサービスを構成して HAStoragePlus リソースタイプとともに動作させる方法が説明されています。詳細については、個別の Sun Cluster データサービスのガイドを参照してください。

NFS エクスポートファイルシステム用に HAStoragePlus リソースタイプを設定する手順については、「NFS エクスポートファイルシステム用に HAStoragePlus リソースタイプを設定する」を参照してください。

注 –

HAStoragePlus リソースタイプを使用してルートファイルシステムを高可用性にしないでください。

高可用性ローカルファイルシステムの構成要件

多重ホストディスク上のすべてのファイルシステムは、これらの多重ホストディスクに直接接続されたすべてのホストからアクセス可能である必要があります。この要件を満たすには、次のように、高可用性ローカルファイルシステムを構成します。

ローカルファイルシステムのディスクパーティションが広域デバイス上に存在するようにします。
これらの広域デバイスを指定する HAStoragePlus リソースの AffinityOn 拡張プロパティーを True に設定します。
フェイルオーバーリソースグループに HAStoragePlus リソースを作成します。
デバイスグループと、HAStoragePlus リソースを含むリソースグループのフェイルバック設定が同じであるようにします。

注 –

高可用性ローカルファイルシステム用の広域デバイスと、ボリュームマネージャーの併用は、任意に選択できます。

ボリュームマネージャーを使用しないデバイスのデバイス名の形式

ボリュームマネージャーを使用しない場合、基本のストレージデバイスの名前には適切な形式を使用します。使用する形式は、次のように、ストレージデバイスの種類に依存します。

ーブロックデバイスの場合: /dev/global/dsk/d DsS
raw デバイスの場合: /dev/global/rdsk/d DsS

これらの論理名の変数の意味は次のとおりです。

D はデバイス ID (DID) インスタンス番号を指定する整数です。
S はスライス番号を指定する整数です。

高可用性ローカルファイルシステムの `/etc/vfstab` のサンプルエントリ

次の例に、高可用性ローカルファイルシステムに使用される広域デバイスの /etc/vfstab ファイルにあるエントリを示します。

例 2–27 ボリュームマネージャーのない広域デバイスの `/etc/vfstab` にあるエントリ

この例に、ボリュームマネージャーを使用しない物理ディスク上の広域デバイス用の /etc/vfstab ファイルにあるエントリを示します。

/dev/global/dsk/d1s0       /dev/global/rdsk/d1s0
/global/local-fs/nfs  ufs     5  no     logging

例 2–28 Solaris ボリュームマネージャーを使用する広域デバイスの `/etc/vfstab` にあるエントリ

この例では、Solaris ボリュームマネージャーを使用する広域デバイス用の /etc/vfstab ファイルにあるエントリを示します。

/dev/md/kappa-1/dsk/d0   /dev/md/kappa-1/rdsk/d0
/global/local-fs/nfs ufs     5  no     logging

例 2–29 VxVM を使用する広域デバイス用の `/etc/vfstab` にあるエントリ

この例では、VxVM を使用する広域デバイス用の /etc/vfstab ファイルにあるエントリを示します。

/dev/vx/dsk/kappa-1/appvol    /dev/vx/rdsk/kappa-1/appvol
/global/local-fs/nfs vxfs     5 no     log

NFS エクスポートファイルシステム用に `HAStoragePlus` リソースタイプを設定する

HAStoragePlus リソースタイプには HAStorage と同じ機能があり、リソースグループとディスクデバイスグループとの間で起動の同期をとります。HAStoragePlus リソースタイプには、ローカルファイルシステムを高可用性にするための機能が追加されています。ローカルファイルシステムの可用性を高めるための背景情報については、「高可用性ローカルファイルシステムの有効化」を参照してください。これら 2 つの機能を両方とも使用するには、HAStoragePlus リソースタイプを設定します。

注 –

次では、UNIX ファイルシステムで HAStoragePlus リソースタイプを使用する方法を説明します。HAStoragePlus リソースタイプを Sun StorEdge^TM QFS ファイルシステムで使用する方法については、Sun StorEdge QFS のマニュアルを参照してください。

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

マウントポイント /global/local-fs/nfs は、UFS ローカルファイルシステムを Sun Cluster 広域デバイスのパーティションにマウントするために使用されます。
/global/local-fs/nfs ファイルシステムの /etc/vfstab エントリは、広域オプションを省略し、「mount at boot」フラグを「no」に指定する必要があります。
path-prefix ディレクトリは、マウントする同じファイルシステムのルートディレクトリ上に存在します (/global/local-fs/nfs など)。path-prefix ディレクトリは、HA-NFS が管理情報と状態情報を保持するために使用するディレクトリです。

手順

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

HAStoragePlus リソースタイプと SUNW.nfs リソースタイプが登録されているかどうかを判別します。

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

必要に応じて、HAStoragePlus リソースタイプと SUNW.nfs リソースタイプを登録します。
# scrgadm -a -t SUNW.HAStoragePlus # scrgadm -a -t SUNW.nfs

フェイルオーバーリソースグループ nfs-rg を作成します。
# 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 のリソース 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 のリソース nfs-rs を作成して、リソース nfs-hastp-rs へのリソース依存関係を指定します。

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

リソースグループ nfs-rg をオフラインにします。
# scswitch -F -g nfs-rg

nfs-rg グループをクラスタノード上でオンラインにします。
# scswitch -Z -g nfs-rg
注意 –
切り替えは、リソースグループに限定します。デバイスグループは切り替えないでください。デバイスグループを切り替えようとすると、リソースグループとデバイスグループの状態に矛盾が生じ、リソースグループのフェイルオーバーが発生します。

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

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

ファイルシステムを表現しているリソースを変更している間でも、高可用性ファイルシステムは利用できる必要があります。たとえば、ストレージが動的に提供されている場合、ファイルシステムは利用できる必要があります。このような状況では、高可用性ファイルシステムを表現しているリソースをオンラインのままで変更します。

Sun Cluster 環境では、高可用性ファイルシステムは HAStoragePlus リソースで表現されます。Sun Cluster では、HAStoragePlus をオンラインのままで変更するには、次のようにします。

ファイルシステムを HAStoragePlus リソースに追加する
ファイルシステムを HAStoragePlus リソースから削除する

注 –

Sun Cluster では、ファイルシステムの名前はオンラインのままでは変更できません。

オンラインの `HAStoragePlus` リソースにファイルシステムを追加する

HAStoragePlus リソースにファイルシステムを追加するとき、HAStoragePlus リソースはローカルファイルシステムをグローバルファイルシステムとは別に処理します。

HAStoragePlus リソースは常に、ローカルファイルシステムを自動的にマウントします。
HAStoragePlus リソースがグローバルファイルシステムを自動的にマウントするのは、HAStoragePlus リソースの AffinityOn 拡張プロパティーが True の場合だけです。

AffinityOn 拡張プロパティーについては、「リソースグループとディスクデバイスグループ間での起動の同期」を参照してください。

手順

クラスタの1つのノード上で、スーパーユーザーになります。

クラスタの各ノードの /etc/vfstab ファイルにおいて、追加する各ファイルシステムのマウントポイント用にエントリを追加します。

エントリごとに、mount at boot フィールドと mount options フィールドを次のように設定します。
- mount at boot フィールドを no に設定します。
- ファイルシステムがグローバルファイルシステムの場合、global オプションを含むように mount options フィールドを設定します。

HAStoragePlus リソースがすでに管理しているファイルシステムのマウントポイントのリストを取得します。
# scha_resource_get -O extension -R hasp-resource -G hasp-rg \ FileSystemMountPoints
-R hasp-resource

ファイルシステムを追加する先の HAStoragePlus リソースを指定します。

-G hasp-rg

HAStoragePlus リソースを含むリソースグループを指定します。

HAStoragePlus リソースの FileSystemMountPoints 拡張プロパティーを変更して、次のマウントポイントを含むようにします。
- HAStoragePlus リソースがすでに管理しているファイルシステムのマウントポイント
- HAStoragePlus リソースに追加しようとしているファイルシステムのマウントポイント
# scrgadm -c -j hasp-resource -x FileSystemMountPoints="mount-point-list"
-j hasp-resource

ファイルシステムを追加する先の HAStoragePlus リソースを指定します。

-x FileSystemMountPoints="mount-point-list "

HAStoragePlus リソースがすでに管理しているファイルシステムのマウントポイントと、追加しようとしているファイルシステムのマウントポイントをコンマで区切って指定します。

HAStoragePlus リソースのマウントポイントのリストと、手順 4で指定したリストが一致していることを確認します。
# scha_resource_get -O extension -R hasp-resource -G hasp-rg \ FileSystemMountPoints
-R hasp-resource

ファイルシステムを追加する先の HAStoragePlus リソースを指定します。

-G hasp-rg

HAStoragePlus リソースを含むリソースグループを指定します。

HAStoragePlus リソースがオンラインであり、障害が発生していないことを確認します。

HAStoragePlus リソースがオンラインであるが、障害が発生している場合、リソースの確認は成功しますが、HAStoragePlus によるファイルシステムのマウントは失敗します。
# scstat -g

例 2–30 オンラインの `HAStoragePlus` リソースへのファイルシステムの追加

次に、オンラインの HAStoragePlus リソースにファイルシステムを追加する例を示します。

HAStoragePlus リソースは rshasp という名前であり、リソースグループ rghasp に含まれます。
rshasp という名前の HAStoragePlus リソースはすでに、マウントポイントが /global/global-fs/fs1 であるファイルシステムを管理しています。
追加しようとしているファイルシステムのマウントポイントは /global/global-fs/fs2 です。

この例では、各クラスタノード上の /etc/vfstabファイルにはすでに、追加しようとしているファイルシステムのエントリが含まれていると仮定します。

# scha_resource_get -O extension -R rshasp -G rghasp FileSystemMountPoints
STRINGARRAY
/global/global-fs/fs1
# scrgadm -c -j rshasp \
-x FileSystemMountPoints="/global/global-fs/fs1,/global/global-fs/fs2"
# scha_resource_get -O extension -R rshasp -G rghasp FileSystemMountPoints
STRINGARRAY
/global/global-fs/fs1
/global/global-fs/fs2
# scstat -g

 -- Resource Groups and Resources --

             Group Name      Resources
             ----------      ---------
  Resources: rghasp          rshasp


 -- Resource Groups --

             Group Name      Node Name    State
             ----------      ---------    -----
      Group: rghasp          node46       Offline
      Group: rghasp          node47       Online


 -- Resources --

             Resource Name   Node Name    State     Status Message
             -------------   ---------    -----     --------------
   Resource: rshasp          node46       Offline   Offline
   Resource: rshasp          node47       Online    Online

オンラインの `HAStoragePlus` リソースからファイルシステムを削除する

HAStoragePlus リソースからファイルシステムを削除するとき、HAStoragePlus リソースはローカルファイルシステムをグローバルファイルシステムとは別に処理します。

HAStoragePlus リソースは常に、ローカルファイルシステムを自動的にアンマウントします。
HAStoragePlus リソースがグローバルファイルシステムを自動的にアンマウントするのは、HAStoragePlus リソースの AffinityOn 拡張プロパティーが True の場合だけです。

AffinityOn 拡張プロパティーについては、「リソースグループとディスクデバイスグループ間での起動の同期」を参照してください。

注意 –

オンラインの HAStoragePlus リソースからファイルシステムを削除する前には、そのファイルシステムを使用しているアプリケーションが存在しないことを確認してください。オンラインの HAStoragePlus リソースからファイルシステムを削除すると、そのファイルシステムは強制的にアンマウントされます。アプリケーションが使用しているファイルシステムが強制的にアンマウントされると、そのアプリケーションは異常終了またはハングする可能性があります。

手順

クラスタの1つのノード上で、スーパーユーザーになります。

HAStoragePlus リソースがすでに管理しているファイルシステムのマウントポイントのリストを取得します。
# scha_resource_get -O extension -R hasp-resource -G hasp-rg \ FileSystemMountPoints
-R hasp-resource

ファイルシステムを削除する元の HAStoragePlus リソースを指定します。

-G hasp-rg

HAStoragePlus リソースを含むリソースグループを指定します。

HAStoragePlus リソースの FileSystemMountPoints 拡張プロパティーを変更して、HAStoragePlus リソースに残すファイルシステムのマウントポイントだけを含むようにします。
# scrgadm -c -j hasp-resource -x FileSystemMountPoints="mount-point-list"
-j hasp-resource

ファイルシステムを削除する元の HAStoragePlus リソースを指定します。

-x FileSystemMountPoints="mount-point-list "

HAStoragePlus リソースに残そうとしているファイルシステムのマウントポイントをコンマで区切って指定します。このリストには、削除しようとしているファイルシステムのマウントポイントが含まれていてはなりません。

HAStoragePlus リソースのマウントポイントのリストと、手順 3で指定したリストが一致していることを確認します。
# scha_resource_get -O extension -R hasp-resource -G hasp-rg \ FileSystemMountPoints
-R hasp-resource

ファイルシステムを削除する元の HAStoragePlus リソースを指定します。

-G hasp-rg

HAStoragePlus リソースを含むリソースグループを指定します。

HAStoragePlus リソースがオンラインであり、障害が発生していないことを確認します。

HAStoragePlus リソースがオンラインであるが、障害が発生している場合、リソースの確認は成功しますが、HAStoragePlus によるファイルシステムのアンマウントは失敗します。
# scstat -g

(省略可能) クラスタの各ノードの /etc/vfstab ファイルから、削除しようとしている各ファイルシステムのマウントポイント用のエントリを削除します。

例 2–31 オンラインの `HAStoragePlus` リソースからのファイルシステムの削除

次に、オンラインの HAStoragePlus リソースからファイルシステムを削除する例を示します。

HAStoragePlus リソースは rshasp という名前であり、リソースグループ rghasp に含まれます。
rshasp という名前の HAStoragePlus リソースはすでに、次のようなマウントポイントのファイルシステムを管理しています。
- /global/global-fs/fs1
- /global/global-fs/fs2
削除しようとしているファイルシステムのマウントポイントは /global/global-fs/fs2 です。

# scha_resource_get -O extension -R rshasp -G rghasp FileSystemMountPoints
STRINGARRAY
/global/global-fs/fs1
/global/global-fs/fs2
# scrgadm -c -j rshasp -x FileSystemMountPoints="/global/global-fs/fs1"
# scha_resource_get -O extension -R rshasp -G rghasp FileSystemMountPoints
STRINGARRAY
/global/global-fs/fs1
 # scstat -g

 -- Resource Groups and Resources --

             Group Name      Resources
             ----------      ---------
  Resources: rghasp          rshasp


 -- Resource Groups --

             Group Name      Node Name    State
             ----------      ---------    -----
      Group: rghasp          node46       Offline
      Group: rghasp          node47       Online


 -- Resources --

             Resource Name   Node Name    State     Status Message
             -------------   ---------    -----     --------------
   Resource: rshasp          node46       Offline   Offline
   Resource: rshasp          node47       Online    Online

`HAStoragePlus` リソースの変更後に障害から回復する

FileSystemMountPoints 拡張プロパティーの変更中に障害が発生した場合、HAStoragePlus リソースの状態はオンラインであり、かつ、障害が発生しています。障害を修正した後、HAStoragePlus の状態はオンラインです。

手順

変更が失敗した原因となる障害を特定します。
# scstat -g
障害が発生した HAStoragePlus リソースの状態メッセージは、その障害を示します。可能性のある障害は、次のとおりです。
- ファイルシステムが存在するはずのデバイスが存在しません。
- fsck コマンドによるファイルシステムの修復が失敗しました。
- 追加しようとしたファイルシステムのマウントポイントが存在しません。
- 追加しようとしたファイルシステムがマウントできません。
- 削除しようとしたファイルシステムがアンマウントできません。

変更が失敗した原因となる障害を修正します。

HAStoragePlus リソースの FileSystemMountPoints 拡張プロパティーを変更する手順を繰り返します。
# scrgadm -c -j hasp-resource -x FileSystemMountPoints="mount-point-list"
-j hasp-resource

変更しようとしている HAStoragePlus リソースを指定します。

-x FileSystemMountPoints="mount-point-list "

高可用性ファイルシステムの変更が失敗したときに指定したマウントポイントをコンマで区切って指定します。

HAStoragePlus リソースがオンラインであり、障害が発生していないことを確認します。
# scstat -g

例 2–32 障害が発生した `HAStoragePlus` リソースの状態

次に、障害が発生した HAStoragePlus リソースの状態の例を示します。fsck コマンドによるファイルシステムの修復が失敗したため、このリソースには障害が発生しています。

# scstat -g
 -- Resource Groups and Resources --

             Group Name      Resources
             ----------      ---------
  Resources: rghasp          rshasp


 -- Resource Groups --

             Group Name      Node Name    State
             ----------      ---------    -----
      Group: rghasp          node46       Offline
      Group: rghasp          node47       Online


 -- Resources --

           Resource Name   Node Name    State   Status Message
           -------------   ---------    -----   --------------
 Resource: rshasp          node46       Offline Offline
 Resource: rshasp          node47       Online  Online Faulted - Failed to fsck: /mnt.

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

Sun Cluster 3.1 9/04 では、HAStoragePlus リソースタイプは高可用性ファイルシステムをオンラインのままで変更できるように拡張されました。HAStoragePlus リソースタイプのアップグレードは、次のすべての条件が満たされる場合に行ってください。

以前のバージョンの Sun Cluster からアップグレードしている場合。
HAStoragePlus リソースタイプの新機能を使用する必要がある場合。

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

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

次の表に、リソースタイプのバージョンと Sun Cluster のリリースの関係を示します。Sun Cluster のリリースは、リソースタイプが導入されたバージョンを表します。

リソースタイプバージョン	Sun Cluster のリリース
1.0	3.0 5/02
2	3.1 9/04

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

scrgadm -p
scrgadm -pv

このリソースタイプのリソースタイプ登録 (RTR) ファイルは /usr/cluster/lib/rgm/rtreg/SUNW.HAStoragePlus です。

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

HAStoragePlus リソースタイプのインスタンスを移行する際には、次の点に注意してください。

移行はいつでも実行できます。
HAStoragePlus リソースタイプの新機能を使用する場合は、Type_version プロパティーに設定する必要がある値は 2 です。

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

可用性を最大化するため、あるいは、性能を最適化するため、いくつかのサービスの組み合わせは、特定のオンラインのリソースグループをクラスタノード間で分散する必要があります。オンラインのリソースグループを分散するということは、リソースグループ間でアフィニティーを作成するということであり、次のような理由で行われます。

初めてリソースグループをオンラインにするときに必要な分散を強制的に実行するため
リソースグループのフェイルオーバーまたはスイッチオーバーの後に必要な分散を保持しておくため

この節では、次のような例を使用しながら、リソースグループのアフィニティーを使用して、オンラインのリソースグループをクラスタノード間で分散する方法について説明します。

あるリソースグループと別のリソースグループを強制的に同じ場所に配置する
あるリソースグループと別のリソースグループをできる限り同じ場所に配置する
リソースグループの集合の負荷をクラスタノード間で均等に分配する
重要なサービスに優先権を指定する
リソースグループのフェイルオーバーまたはスイッチオーバーを委託する
リソースグループ間のアフィニティーを組み合わせて、複雑な動作を指定する

リソースグループのアフィニティー

リソースグループ間のアフィニティーは、複数のリソースグループが同時にオンラインになる可能性があるノードを制限します。各アフィニティーにおいて、ソースのリソースグループには 1 つまたは複数のターゲットのリソースグループに対するアフィニティーを宣言します。リソースグループ間にアフィニティーを作成するには、ソースの RG_affinities リソースグループプロパティーを次のように設定します。

-y RG_affinities=affinity-list

affinity-list

ソースリソースグループとターゲットリソースグループ (複数可) の間のアフィニティーのコンマ区切りリストを指定します。リストでは 1 つまたは複数のアフィニティーを指定できます。

リストでは各アフィニティーを次のように指定します。

operator target-rg

注 –

operator と target-rg の間にはスペースを入れてはなりません。

operator: 作成しようとしているアフィニティーのタイプを指定します。詳細は、表 2–2を参照してください。
target-rg: 作成しているアフィニティーのターゲットであるリソースグループを指定します。

表 2–2 リソースグループ間のアフィニティーのタイプ


演算子	アフィニティーのタイプ	効果
`+`	弱い肯定的な	ソースは、できる限り、ターゲットがオンラインである (あるいは、起動している) 1 つまたは複数のノード上でオンラインになります。つまり、ソースとターゲットは異なるノード上でオンラインになることもあります。
`++`	強い肯定的な	ソースは、ターゲットがオンラインである (あるいは、起動している) 1 つまたは複数のノード上でのみオンラインになります。つまり、ソースとターゲットは異なるノード上でオンラインになることはありません。
`-`	弱い否定的な	ソースは、可能であれば、ターゲットがオンラインでない (あるいは、起動していない) 1 つまたは複数のノード上でオンラインになります。つまり、ソースとターゲットは同じノード上でオンラインになることもあります。
`--`	強い否定的な	ソースは、ターゲットがオンラインでない 1 つまたは複数のノード上でのみオンラインになります。つまり、ソースとターゲットは同じノード上でオンラインになることはありません。
`+++`	フェイルオーバー委託付きの強い肯定的な	強い肯定的なアフィニティーと似ていますが、ソースによるフェイルオーバーはターゲットに委託されます。詳細については、「リソースグループのフェイルオーバーまたはスイッチオーバーを委託する」を参照してください。

弱いアフィニティーは、Nodelist 優先順位より優先されます。

その他のリソースグループの現在の状態によっては、任意のノード上で、強いアフィニティーが成立しないことがあります。このような状況では、アフィニティーのソースであるリソースグループはオフラインのままです。その他のリソースグループの状態が変更され、強いアフィニティーが成立できるようになると、アフィニティーのソースであるリソースグループはオンラインに戻ります。

注 –

複数のターゲットリソースグループを持つソースリソースグループに強いアフィニティーを宣言するときは、注意が必要です。宣言されたすべての強いアフィニティーが成立しない場合、ソースリソースグループはオフラインのままになるためです。

あるリソースグループと別のリソースグループを強制的に同じ場所に配置する

あるリソースグループのサービスが別のリソースグループのサービスに強く依存する場合、これらのリソースグループは両方とも同じノード上で動作する必要があります。たとえば、あるアプリケーションがお互いに依存する複数のサービスのデーモンから構成される場合、すべてのデーモンは同じノード上で動作する必要があります。

このような状況では、依存するサービスのリソースグループを、強制的に、依存されるサービスのリソースグループと同じ場所に配置するように指定します。あるリソースグループを強制的に別のリソースグループと同じ場所に配置するには、あるリソースグループに別のリソースグループに対する強い肯定的なアフィニティーを宣言します。

# scrgadm -c|-a -g source-rg -y RG_affinities=++target-rg

-g source-rg: 強い肯定的なアフィニティーのソースであるリソースグループを指定します。このリソースグループは、別のリソースグループに対する強い肯定的なアフィニティーを宣言するリソースグループです。
-y RG_affinities=++target-rg: 強い肯定的なアフィニティーのターゲットであるリソースグループを指定します。このリソースグループは、強い肯定的なアフィニティーを宣言する対象のリソースグループです。

強い肯定的なアフィニティーを宣言しているソースのリソースグループは、ターゲットのリソースグループに従います。しかし、強い肯定的なアフィニティーを宣言しているソースのリソースグループは、ターゲットのリソースグループが動作していないノードにはフェイルオーバーできません。

注 –

フェイルオーバーされないのは、リソースモニターが起動したフェイルオーバーだけです。ソースとターゲットの両方のリソースグループが動作しているノードに障害が発生した場合、これらのリソースグループは、正常に動作している同じノード上で再起動されます。

たとえば、リソースグループ rg1 にリソースグループ rg2 に対する強い肯定的なアフィニティーが宣言されていると仮定します。rg2 が別のノードにフェイルオーバーすると rg1 もそのノードにフェイルオーバーします。rg1 内のすべてのリソースが操作可能であるとしても、このフェイルオーバーは発生します。しかし、rg1 内のリソースによって、rg2 が動作していないノードに rg1 をフェイルオーバーしようとした場合、このフェイルオーバーはブロックされます。

強い肯定的なアフィニティーを宣言しているリソースグループをフェイルオーバーする必要がある場合、そのフェイルオーバーは委託する必要があります。詳細については、「リソースグループのフェイルオーバーまたはスイッチオーバーを委託する」を参照してください。

例 2–33 あるリソースグループと別のリソースグループを強制的に同じ場所に配置する

この例では、リソースグループ rg1 を変更して、リソースグループ rg2 に対する強い肯定的なアフィニティーを宣言するためのコマンドを示します。このアフィニティーを宣言すると、rg1 は rg2 が動作しているノード上だけでオンラインになります。この例では、両方のリソースグループが存在していると仮定します。

# scrgadm -c -g rg1 -y RG_affinities=++rg2

あるリソースグループと別のリソースグループをできる限り同じ場所に配置する

あるリソースグループのサービスが別のリソースグループのサービスを使用していることがあります。結果として、これらのサービスは、同じノード上で動作する場合にもっとも効率よく動作します。たとえば、データベースを使用するアプリケーションは、そのアプリケーションとデータベースが同じノード上で動作する場合に、もっとも効率よく動作します。しかし、これらのサービスは異なるノード上で動作してもかまいません。なぜなら、リソースグループのフェイルオーバーの増加よりも効率の低下のほうが被害が小さいためです。

このような状況では、両方のリソースグループを、できる限り、同じ場所に配置するように指定します。あるリソースグループと別のリソースグループをできる限り同じ場所に配置するには、あるリソースグループに別のリソースグループに対する弱い肯定的なアフィニティーを宣言します。

# scrgadm -c|-a -g source-rg -y RG_affinities=+target-rg

-g source-rg: 弱い肯定的なアフィニティーのソースであるリソースグループを指定します。このリソースグループは、別のリソースグループに対する弱い肯定的なアフィニティーを宣言するリソースグループです。
-y RG_affinities=+target-rg: 弱い肯定的なアフィニティーのターゲットであるリソースグループを指定します。このリソースグループは、弱い肯定的なアフィニティーを宣言する対象のリソースグループです。

あるリソースグループに別のリソースグループに対する弱い肯定的なアフィニティーを宣言することによって、両方のリソースグループが同じノードで動作する確率が上がります。弱い肯定的なアフィニティーのソースは、まず、そのアフィニティーのターゲットがすでに動作しているノード上でオンラインになろうとします。しかし、弱い肯定的なアフィニティーのソースは、そのアフィニティーのターゲットがリソースモニターによってフェイルオーバーされても、フェイルオーバーしません。同様に、弱い肯定的なアフィニティーのソースは、そのアフィニティーのターゲットがスイッチオーバーされても、フェイルオーバーしません。どちらの状況でも、ソースがすでに動作しているノード上では、ソースはオンラインのままです。

注 –

ソースとターゲットの両方のリソースグループが動作しているノードに障害が発生した場合、これらのリソースグループは、正常に動作している同じノード上で再起動されます。

例 2–34 あるリソースグループと別のリソースグループをできる限り同じ場所に配置する

この例では、リソースグループ rg1 を変更して、リソースグループ rg2 に対する弱い肯定的なアフィニティーを宣言するためのコマンドを示します。このアフィニティーを宣言すると、rg1 と rg2 はまず、同じノード上でオンラインになろうとします。しかし、rg2 内のリソースによって rg2 がフェイルオーバーしても、rg1 はリソースグループが最初にオンラインになったノード上でオンラインのままです。この例では、両方のリソースグループが存在していると仮定します。

# scrgadm -c -g rg1 -y RG_affinities=+rg2

リソースグループの集合の負荷をクラスタノード間で均等に分配する

リソースグループの集合の各リソースグループには、クラスタの同じ負荷をかけることができます。このような状況では、リソースグループをクラスタ間で均等に分散することによって、クラスタの負荷の均衡をとることができます。

リソースグループの集合のリソースグループをクラスタノード間で均等に分散するには、各リソースグループに、リソースグループの集合のほかのリソースグループに対する弱い否定的なアフィニティーを宣言します。

# scrgadm -c|-a -g source-rg -y RG_affinities=neg-affinity-list

-g source-rg: 弱い否定的なアフィニティーのソースであるリソースグループを指定します。このリソースグループは、別のリソースグループに対する弱い否定的なアフィニティーを宣言するリソースグループです。
-y RG_affinities=neg-affinity-list: ソースリソースグループと、弱い否定的なアフィニティーのターゲットであるリソースグループの間の、弱い否定的なアフィニティーをコンマで区切って指定します。ターゲットリソースグループは、弱い肯定的なアフィニティーを宣言する対象のリソースグループです。

あるリソースグループにその他のリソースグループに対する弱い否定的なアフィニティーを宣言することによって、そのリソースグループが常に、もっとも負荷がかかっていないクラスタノード上でオンラインになることが保証されます。このノード上で動作しているその他のリソースグループは最小数です。したがって、弱い否定的なアフィニティーの最小数が違反されます。

例 2–35 リソースグループの集合の負荷をクラスタノード間で均等に分配する

この例では、リソースグループ rg1、rg2、rg3、および rg4 を変更して、これらのリソースグループを、クラスタで利用可能なノード間で均等に分配するためのコマンドを示します。この例では、リソースグループ rg1、rg2、rg3、および rg4 が存在していると仮定します。

# scrgadm -c -g rg1 RG_affinities=-rg2,-rg3,-rg4
# scrgadm -c -g rg2 RG_affinities=-rg1,-rg3,-rg4
# scrgadm -c -g rg3 RG_affinities=-rg1,-rg2,-rg4
# scrgadm -c -g rg4 RG_affinities=-rg1,-rg2,-rg3

重要なサービスに優先権を指定する

クラスタは、重要なサービスと重要でないサービス組み合わせて動作するように構成できます。たとえば、重要な顧客サービスをサポートするデータベースは、重要でない研究タスクと同じクラスタで実行できます。

重要でないサービスが重要なサービスに影響を与えないようにするには、重要なサービスに優先権を指定します。重要なサービスに優先権を指定することによって、重要でないサービスが重要なサービスと同じノード上で動作することを防ぐことができます。

すべてのノードが操作可能であるとき、重要なサービスは重要でないサービスとは異なるノード上で動作します。しかし、重要なサービスに障害が発生すると、このサービスは重要でないサービスが動作しているノードにフェイルオーバーします。このような状況では、重要でないサービスは直ちにオフラインになり、重要なサービスはコンピューティングリソースを完全に利用できるようになります。

重要なサービスに優先権を指定するには、重要でない各サービスのリソースグループに、重要なサービスを含むリソースグループに対する強い否定的なアフィニティーを宣言します。

# scrgadm -c|-a -g noncritical-rg -y RG_affinities=--critical-rg

-g noncritical-rg: 重要でないサービスを含むリソースグループを指定します。このリソースグループは、別のリソースグループに対する強い否定的なアフィニティーを宣言するリソースグループです。
-y RG_affinities=--critical-rg: 重要なサービスを含むリソースグループを指定します。このリソースグループは、強い否定的なアフィニティーが宣言されるリソースグループです。

強い否定的なアフィニティーのソースのリソースグループは、そのアフィニティーのターゲットのリソースグループから離れます。

例 2–36 重要なサービスに優先権を指定する

この例では、重要でないリソースグループ ncrg1 と ncrg2 を変更して、重要なリソースグループ mcdbrg に重要でないリソースグループよりも高い優先権を与えるためのコマンドを示します。この例では、リソースグループ mcdbrg、ncrg1、および ncrg2 が存在していると仮定します。

# scrgadm -c -g ncrg1 RG_affinities=--mcdbrg
# scrgadm -c -g ncrg2 RG_affinities=--mcdbrg

リソースグループのフェイルオーバーまたはスイッチオーバーを委託する

強い肯定的なアフィニティーのソースリソースグループは、そのアフィニティーのターゲットが動作していないノードにはフェイルオーバーまたはスイッチオーバーできません。強い肯定的なアフィニティーのソースリソースグループをフェイルオーバーまたはスイッチオーバーする必要がある場合、そのフェイルオーバーはターゲットリソースグループに委託する必要があります。このアフィニティーのターゲットがフェイルオーバーするとき、このアフィニティーのソースはターゲットと一緒に強制的にフェイルオーバーされます。

注 –

++ 演算子で指定した強い肯定的なアフィニティーのソースリソースグループでも、スイッチオーバーする必要がある場合もあります。このような状況では、このアフィニティーのターゲットとソースを同時にスイッチオーバーします。

リソースグループのフェイルオーバーまたはスイッチオーバーを別のリソースグループに委託するには、そのリソースグループに、その他のリソースグループに対するフェイルオーバー委託付きの強い肯定的なアフィニティーを宣言します。

# scrgadm -c|-a -g source-rg -y RG_affinities=+++target-rg

-g source-rg

フェイルオーバーまたはスイッチオーバーを委託するリソースグループを指定します。このリソースグループは、別のリソースグループに対するフェイルオーバー委託付きの強い肯定的なアフィニティーを宣言するリソースグループです。

-y RG_affinities=+++target-rg

source-rg がフェイルオーバーまたはスイッチオーバーを委託するリソースグループを指定します。このリソースグループは、フェイルオーバー委託付きの強い肯定的なアフィニティーが宣言されるリソースグループです。

あるリソースグループは、最大 1 つのリソースグループに対するフェイルオーバー委託付きの強い肯定的なアフィニティーを宣言できます。逆に、あるリソースグループは、その他の任意の数のリソースグループによって宣言されたフェイルオーバー委託付きの強い肯定的なアフィニティーのターゲットである可能性があります。

つまり、フェイルオーバー委託付きの強い肯定的なアフィニティーは対照的ではありません。ソースがオフラインの場合でも、ターゲットはオンラインになることができます。しかし、ターゲットがオフラインの場合、ソースはオンラインになることができません。

ターゲットが第三のリソースグループに対するフェイルオーバー委託付きの強い肯定的なアフィニティーを宣言する場合、フェイルオーバーまたはスイッチオーバーはさらに第三のリソースグループに委託されます。第三のリソースグループがフェイルオーバーまたはスイッチオーバーを実行すると、その他のリソースグループも強制的にフェイルオーバーまたはスイッチオーバーされます。

例 2–37 リソースグループのフェイルオーバーまたはスイッチオーバーを委託する

この例では、リソースグループ rg1 を変更して、リソースグループ rg2 に対するフェイルオーバー委託付きの強い肯定的なアフィニティーを宣言するためのコマンドを示します。このアフィニティー関係の結果、rg1 はフェイルオーバーまたはスイッチオーバーを rg2 に委託します。この例では、両方のリソースグループが存在していると仮定します。

# scrgadm -c -g rg1 -y RG_affinities=+++rg2

リソースグループ間のアフィニティーの組み合わせ

複数のアフィニティーを組み合わせることによって、より複雑な動作を作成できます。たとえば、関連する複製サーバーにアプリケーションの状態を記録できます。この例におけるノード選択条件は次のとおりです。

複製サーバーは、アプリケーションと異なるノード上で動作している必要があります。
アプリケーションが現在のノードからフェイルオーバーすると、アプリケーションは、複製サーバーが動作しているノードにフェイルオーバーする必要があります。
アプリケーションが複製サーバーが動作しているノードにフェイルオーバーすると、複製サーバーは異なるノードにフェイルオーバーする必要があります。その他のノードが利用できない場合、複製サーバーはオフラインになる必要があります。

これらの条件を満たすには、アプリケーションと複製サーバーのリソースグループを次のように構成します。

アプリケーションを含むリソースグループは、複製サーバーを含むリソースグループに対する弱い肯定的なアフィニティーを宣言します。
複製サーバーを含むリソースグループは、アプリケーションを含むリソースグループに対する強い否定的なアフィニティーを宣言します。

例 2–38 リソースグループ間のアフィニティーの組み合わせ

この例では、次のリソースグループ間のアフィニティーを組み合わせるためのコマンドを示します。

リソースグループ app-rg は、複製サーバーによって状態を追跡するアプリケーションを示します。
リソースグループ rep-rg は、複製サーバーを示します。

この例では、リソースグループはアフィニティーを次のように宣言します。

リソースグループ app-rg は、リソースグループ rep-rg に対する弱い肯定的なアフィニティーを宣言します。
リソースグループ rep-rg は、リソースグループ app-rg に対する強い否定的なアフィニティーを宣言します。

この例では、両方のリソースグループが存在していると仮定します。

# scrgadm -c -g app-rg RG_affinities=+rep-rg
# scrgadm -c -g rep-rg RG_affinities=--app-rg

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

注 –

重要でないリソースグループをオフロードするもっとも簡単な方法は、リソースグループ間で強い否定的なアフィニティーを使用することです。詳細については、「オンラインのリソースグループをクラスタノード間で分散する」を参照してください。

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 拡張プロパティーの詳細については、「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

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

この例では、RGOffload リソース rgofl を次のように構成する方法について説明します。

重要なリソースグループ oracle_rg には RGOffload リソースが含まれています。
重要なリソースは、oracle-server-rs です。
重要なリソースグループがオンラインになったときに、スケーラブルリソースグループ IWS-SC および IWS-SC-2 はオフロードされます。
リソースグループ 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 に対して構成可能な拡張プロパティーを示します。「調整可能」の欄には、そのプロパティーをいつ変更できるかが示されています。

通常、RGOffload リソースを作成するとき、拡張プロパティーを構成するには、コマンド行 scrgadm -x parameter=value を使用します。

continue_to_offload (ブール型)

リソースグループのオフロード中にエラーが発生したあとに、rg_to_offload リスト内の残りのリソースグループをオフロードし続けるかどうかを指定します。

このプロパティーは START メソッドだけが使用します。

初期値: True

調整: 任意の時点

max_offload_retry (整数型)

クラスタ再構成またはリソースグループ再構成によりオフロードに障害が発生した場合の起動中に、リソースグループをオフロードしようとする回数を指定します。連続する再試行の間の間隔は 10 秒です。

max_offload_retry が高すぎると、最大オフロード試行回数に到達する前に、RGOffload リソースの START メソッドがタイムアウトする可能性があります。この可能性を避けるために、次の式を使用して max_offload_retry を計算します。

max-offload-retry <  start-timeout /(num-rg  × offload-retry-interval)

max-offload-retry: max_offload_retry 拡張プロパティーの値
start-timeout: RGOffload リソースの Start_timeout プロパティーの値
num-rg: オフロードされるリソースグループの数
offload-retry-interval: 連続する再試行の間の間隔 (10 秒)

このプロパティーは START メソッドだけが使用します。

初期値: 15

調整: 任意の時点

rg_to_offload (文字列型)

プライオリティーが高いフェイルオーバーリソースグループがノード上で起動するときに、当該ノード上でオフロードされるリソースグループのコンマ区切りリストを指定します。このプロパティーにはデフォルト設定値がないので、必ず設定する必要があります。

このリストには、互いに依存するリソースグループが含まれてはいけません。RGOffload は、rg_to_offload 拡張プロパティーに設定されたリソースグループのリストにおける依存関係ループを検査しません。

たとえば、リソースグループ RG-B が何らかの形で RG-A に依存する場合、両方のリソースグループが rg_to_offload に含まれてはいけません。

初期値: なし

調整: 任意の時点

障害モニター

RGOffload 障害モニターは、重要なリソースをマスターするノード上で、重要ではないリソースグループがオンラインになるのを防止します。障害モニターは、重要なリソースをマスターするノード上で、重要ではないリソースグループがオンラインであることを検出する場合があります。このような場合、障害モニターはそのほかのノードでリソースグループを起動しようとします。また障害モニターは、重要なリソースをマスターするノード上でリソースグループをオフラインにします。

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

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

# scswitch -u -g resourcegroup

RGOffload リソースの Thorough_probe_interval プロパティーの値は、障害モニターの検証の間の間隔を指定します。

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

2 つのクラスタ上で同じリソース構成データが必要である場合、このデータを 2 番目のクラスタに複製することによって、もう一度同じ設定を行うという面倒な作業を省略できます。scsnapshot を使用して、あるクラスタから別のクラスタにリソース構成情報をコピーします。設定後、問題が生じないように、リソース関係の構成が安定していることを確認します。2 番目のクラスタに情報をコピーする前に、リソース構成に大きな変更を行う必要はありません。

リソースグループ、リソースタイプ、およびリソースの構成データは、クラスタ構成リポジトリ (CCR) から取得でき、シェルスクリプトとして書式化されています。このスクリプトを使用すると、次の作業を実行できます。

リソースグループ、リソースタイプ、およびリソースが構成されていないクラスタに構成データを複製する
リソースグループ、リソースタイプ、およびリソースが構成されているクラスタの構成データをアップグレードする

scsnapshot ツールは、CCR に格納されている構成データを取得します。ほかの構成データは無視されます。scsnapshot ツールは、異なるリソースグループ、リソースタイプ、およびリソースの動的な状態を無視します。

リソースグループ、リソースタイプ、およびリソースが構成されていないクラスタに構成データを複製する

この手順は、リソースグループ、リソースタイプ、およびリソースが構成されていないクラスタに構成データを複製します。この手順では、あるクラスタから構成データのコピーを取得し、このデータを使用して、別のクラスタ上で構成データを生成します。

手順

システム管理者役割を使用して、構成データをコピーしたいクラスタノードにログインします。

たとえば、node1 にログインすると仮定します。

システム管理者役割が与える役割によるアクセス制御 (RBAC) 権は、次のとおりです。
- solaris.cluster.resource.read
- solaris.cluster.resource.modify

クラスタから構成データを取得します。
node1 % scsnapshot -s scriptfile
scsnapshot ツールは、 scriptfile というスクリプトを生成します。scsnapshot ツールの使用法の詳細については、scsnapshot(1M) のマニュアルページを参照してください。

このスクリプトを編集して、構成データを複製したいクラスタに固有な特徴に合わせます。

たとえば、スクリプト内にある IP アドレスやホスト名を変更します。

このスクリプトを、構成データを複製したい任意のクラスタノードから実行します。

このスクリプトは、スクリプトが生成されたクラスタとローカルクラスタの特性を比較します。これらの特性が同じでない場合、このスクリプトはエラーを書き込んで終了します。次に、-f オプションを使用してスクリプトを実行し直すかどうかをたずねるメッセージが表示されます。-f オプションを使用した場合、上記のような特性の違いを無視して、スクリプトを強制的に実行します。-f オプションを使用した場合、クラスタ内に不整合がないことを確認します。

このスクリプトは、Sun Cluster リソースタイプがローカルクラスタ上に存在することを確認します。リソースタイプがローカルクラスタに存在しない場合、このスクリプトはエラーを書き込んで終了します。もう一度スクリプトを実行する前に、存在しないリソースタイプをインストールするかどうかをたずねるメッセージが表示されます。

リソースグループ、リソースタイプ、およびリソースが構成されているクラスタの構成データをアップグレードする

この手順は、リソースグループ、リソースタイプ、およびリソースがすでに構成されているクラスタ上の構成データをアップグレードします。この手順は、リソースグループ、リソースタイプ、およびリソースの構成テンプレートを生成するのにも使用できます。

この手順では、cluster1 上の構成データが cluster2 上の構成データに一致するようにアップグレードされます。

手順

システム管理者役割を使用して、cluster1 の任意のノードにログオンします。

たとえば、node1 にログオンすると仮定します。

システム管理者役割が与える RBAC 権は次のとおりです。
- solaris.cluster.resource.read
- solaris.cluster.resource.modify

scsnapshot ツールの image file オプションを使用して、クラスタから構成データを取得します。
node1% scsnapshot -s scriptfile1 -o imagefile1
node1 上で実行するとき、scsnapshot ツールは scriptfile1 というスクリプトを生成します。このスクリプトは、リソースグループ、リソースタイプ、およびリソースの構成データを imagefile1 というイメージファイルに格納します。scsnapshot ツールの使用法の詳細については、scsnapshot(1M) のマニュアルページを参照してください。

cluster2 のノード上で、手順 1 から手順 2 までの手順を繰り返します。
node2 % scsnapshot -s scriptfile2 -o imagefile2

node1 上で cluster2 の構成データを使用して cluster1 の構成データをアップグレードするためのスクリプトを生成します。
node1 % scsnapshot -s scriptfile3 imagefile1 imagefile2
この手順では、手順 2 と手順 3 で生成したイメージファイルを使用して、scriptfile3 という新しいスクリプトを生成します。

手順 4 で生成したスクリプトを編集して、cluster1 に固有な特徴に合わせて、cluster2 に固有なデータを削除します。

このスクリプトを node1 から実行して、構成データをアップグレードします。

このスクリプトは、スクリプトが生成されたクラスタとローカルクラスタの特性を比較します。これらの特性が同じでない場合、このスクリプトはエラーを書き込んで終了します。次に、-f オプションを使用してスクリプトを実行し直すかどうかをたずねるメッセージが表示されます。-f オプションを使用した場合、上記のような特性の違いを無視して、スクリプトを強制的に実行します。-f オプションを使用した場合、クラスタ内に不整合がないことを確認します。

このスクリプトは、Sun Cluster リソースタイプがローカルクラスタ上に存在することを確認します。リソースタイプがローカルクラスタに存在しない場合、このスクリプトはエラーを書き込んで終了します。もう一度スクリプトを実行する前に、存在しないリソースタイプをインストールするかどうかをたずねるメッセージが表示されます。

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

Sun Cluster 製品で提供されるデータサービスには、障害モニターが組み込まれています。障害モニターは、次の機能を実行します。

データサービスサーバーのプロセスの予期せぬ終了を検出する
データサービスの健全性の検査

障害モニターは、データサービスが作成されたアプリケーションを表現するリソースに含まれます。このリソースは、データサービスを登録および構成したときに作成します。詳細は、データサービスのマニュアルを参照してください。

障害モニターの動作は、当該リソースのシステムプロパティーと拡張プロパティーによって制御されます。事前に設定された障害モニターの動作は、これらのプロパティーのデフォルト値に基づいています。現在の動作は、ほとんどの Sun Cluster システムに適しているはずです。したがって、障害モニターを調整するのは、事前に設定されたこの動作を変更したい場合「だけに」留めるべきです。

障害モニターを調整するには、次の作業が含まれます。

障害モニターの検証間隔を設定する。
障害モニターの検証タイムアウトを設定する。
継続的な障害とみなす基準を定義する。
リソースのフェイルオーバー動作を指定する

これらの作業は、データサービスの登録と構成の際に行います。詳細は、データサービスのマニュアルを参照してください。

注 –

リソースの障害モニターは、そのリソースを含むリソースグループをオンラインにしたときに起動されます。障害モニターを明示的に起動する必要はありません。

障害モニターの検証間隔の設定

リソースが正しく動作しているかどうかを判断するには、障害モニターで当該リソースを定期的に検証します。障害モニターの検証間隔は、リソースの可用性とシステムの性能に次のような影響を及ぼします。

障害モニターの検証間隔は、障害の検出とその障害への対応にどの程度の時間がかかるかに影響を与えます。したがって、障害モニターの検証間隔を短くすると、障害の検出とその障害への対応にかかる時間も短くなります。このような時間の短縮は、リソースの可用性が向上することを意味します。
障害モニターの検証では、プロセッササイクルやメモリなどのシステムリソースが使用されます。したがって、障害モニターの検証間隔を短くすると、システムの性能は低下します。

さらに、障害モニターの最適な検証間隔は、リソースの障害への対応にどの程度の時間が必要かによって異なります。この時間は、リソースの複雑さが、リソースの再起動などの操作にかかる時間にどのような影響を及ぼすかに依存します。

障害モニターの検証間隔を設定するには、リソースの Thorough_probe_interval システムプロパティーを必要な間隔 (秒単位) に設定します。

障害モニターの検証タイムアウトの設定

障害モニターの検証タイムアウトでは、検証に対するリソースからの応答にどのくらいの時間を許すかを指定します。このタイムアウト内にリソースからの応答がないと、障害モニターは、このリソースに障害があるものとみなします。障害モニターの検証に対するリソースの応答にどの程度の時間がかかるかは、障害モニターがこの検証に使用する操作によって異なります。データサービスの障害モニターがリソースを検証するために実行する操作については、データサービスのマニュアルを参照してください。

リソースの応答に要する時間は、障害モニターやアプリケーションとは関係のない次のような要素にも依存します。

システム構成
クラスタ構成
システム負荷
ネットワークトラフィックの量

障害モニターの検証タイムアウトを設定する場合は、必要なタイムアウト値をリソースの Probe_timeout 拡張プロパティーに秒単位で指定します。

継続的な障害とみなす基準の定義

一時的な障害による中断を最小限に抑えるために、障害モニターは、このような障害が発生するとこのリソースを再起動します。継続的な障害の場合は、リソースの再起動よりも複雑なアクションをとる必要があります。

フェイルオーバーリソースの場合は、障害モニターがこのリソースを別のノードにフェイルオーバーします。
スケーラブルリソースの場合は、障害モニターがこのリソースをオフラインにします。

障害モニターは、指定された再試行間隔の中で、リソースの完全な障害の回数が、指定されたしきい値を超えると障害を継続的であるとみなします。ユーザーは、継続的な障害とみなす基準を定義することによって、可用性要件とクラスタの性能特性を満たすしきい値や再試行間隔を設定できます。

リソースの完全な障害と部分的な障害

障害モニターは、いくつかの障害を、リソースの「完全な障害」としてみなします。完全な障害は通常、サービスの完全な損失を引き起こします。次に、完全な障害の例を示します。

データサービスサーバーのプロセスの予期せぬ終了
障害モニターがデータサービスサーバーに接続できない

完全な障害が発生すると、障害モニターは再試行間隔内の完全な障害の回数を 1 つ増やします。

障害モニターは、それ以外の障害を、リソースの「部分的な障害」とみなします。部分的な障害は完全な障害よりも重大ではなく、通常、サービスの低下を引き起こしますが、サービスの完全な損失は引き起こしません。次に、障害モニターがタイムアウトするまでにデータサービスサーバーからの応答が不完全であるという部分的な障害の例を示します。

部分的な障害が発生すると、障害モニターは再試行間隔内の完全な障害の回数を小数点数だけ増やします。部分的な障害は、再試行間隔を過ぎても累積されます。

部分的な障害の次の特性は、データサービスに依存します。

障害モニターが部分的な障害とみなす障害のタイプ
それぞれの部分的な障害が完全な障害の回数に追加する小数点数

データサービスの障害モニターが検出する障害については、データサービスのマニュアルを参照してください。

しきい値や再試行間隔と他のプロパティーとの関係

障害のあるリソースが再起動するのに必要な最大時間は、次のプロパティーの値を合計したものです。

Thorough_probe_interval システムプロパティー
Probe_timeout 拡張プロパティー

再試行回数がしきい値に達しないうちに再試行間隔がきてしまうのを避けるためには、再試行間隔としきい値の値を次の式に従って計算します。

retry-interval ≥  threshold × (thorough-probe-interval  + probe-timeout )

しきい値と再試行間隔を設定するシステムプロパティー

しきい値と再試行間隔を設定するには、リソースの次のようなシステムプロパティーを使用します。

しきい値を設定するには、Retry_count システムプロパティーを完全な障害の最大値に設定します。
再試行間隔を設定する場合には、Retry_interval システムプロパティーに、必要な間隔を秒数で指定します。

リソースのフェイルオーバー動作を指定する

リソースのフェイルオーバー動作は、次の障害に対して RGM がどのように応答するかを決定します。

リソースの起動の失敗
リソースの停止の失敗
リソースの障害モニターの停止の失敗

リソースのフェイルオーバー動作を指定するには、リソースの Failover_mode システムプロパティーを設定します。このプロパティーに指定できる値については、「リソースのプロパティー」における Failover_mode システムプロパティーの説明を参照してください。

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

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

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

リソースタイプの登録

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

始める前に

手順

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

次の手順

参照

リソースタイプの更新

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

始める前に

手順

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

始める前に

手順

例 2–2 オフラインである場合にのみ移行可能なリソースの移行

例 2–3 監視対象外である場合にのみ移行可能なリソースの移行

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

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

手順

リソースグループの作成

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

手順

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

次の手順

参照

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

手順

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

次の手順

参照

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

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

始める前に

手順

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

例 2–7 IP ネットワークマルチパスグループを識別する論理ホスト名リソースの追加

次の手順

注意事項

参照

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

始める前に

手順

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

次の手順

注意事項

参照

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

始める前に

手順

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

次の手順

注意事項

参照

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

始める前に

手順

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

次の手順

注意事項

参照

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

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

手順

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

次の手順

参照

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

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

手順

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

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

手順

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

リソースタイプの削除

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

始める前に

手順

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

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

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

例 2–18 リソースの無効化とリソースグループの `UNMANAGED` 状態への移行

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

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

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