第 15 章 データサービスリソースの管理
この章では、scrgadm(1M) を使って、クラスタ内のリソースや、リソースグループ、リソースタイプを管理する手順を説明します。手順を実行するその他のツールについては、データサービスリソースを管理するためのツール を参照してください。
この章の内容は次のとおりです。
リソースタイプ、リソースグループ、リソースの概念については、第 1 章「Sun Cluster データサービスの計画」と『Sun Cluster 3.1 の概念』を参照してください。
データサービスリソースの管理
表 15–1 に、データサービスリソースの管理作業を説明している節を示します。
表 15–1 作業マップ: データサービスの管理|
作業 |
参照箇所 |
|---|---|
|
リソースタイプの登録 | |
|
リソースタイプのアップグレード | |
|
フェイルオーバーリソースグループとスケーラブルリソースグループの作成 | |
|
論理ホスト名または共有アドレス、データサービスリソースのリソースグループへの追加 | |
|
リソースとリソースモニターの有効化、リソースグループの管理、リソースグループおよび関連するリソースのオンライン化 | |
|
リソース自体とは関係なく、リソースモニターだけを無効化または有効化 | |
|
クラスタからのリソースタイプの削除 | |
|
クラスタからのリソースグループの削除 | |
|
リソースグループからのリソースの削除 | |
|
リソースグループの主ノードへの切り替え | |
|
リソースの無効化、そのリソースグループの UNMANAGED 状態への移行 | |
|
リソースタイプ、リソースグループ、リソース構成情報の表示 | |
|
リソースタイプ、リソースグループ、リソースプロパティの変更 | |
|
失敗した Resource Group Manager (RGM) プロセスのエラーフラグの消去 | |
|
組み込みリソースタイプ LogicalHostname および SharedAddress の再登録 | |
|
ネットワークリソースのネットワークインタフェース ID リストの更新と、リソースグループのノードリストの更新 | |
|
リソースグループからのノードの削除 | |
|
リソースグループへの HAStorage または HAStoragePlus の設定、およびこれらのリソースグループとディスクデバイスグループ間での起動の同期 | |
|
HAStoragePlus の設定、ディスクの I/O に非常に負荷のかかるフェイルオーバーデータサービスのための高可用性ローカルファイルシステムの有効化 | |
|
重要なデータサービス用にノードを自動解放するようリソースタイプを構成 |
注 –
この章の各手順では scrgadm(1M) コマンドを使って作業を行いますが、これ以外のツールを使ってリソースを管理することもできます。その方法については、データサービスリソースを管理するためのツールを参照してください。
Sun Cluster データサービスの構成と管理
Sun Cluster の構成は、複数の手順から成る単一の作業です。これらの手順により次の作業を実行できます。
-
リソースタイプの登録
-
リソースタイプのアップグレード
-
リソースグループの作成
-
リソースグループへのリソースの追加
-
リソースのオンライン化
データサービスの構成を変更するには、初期構成が終わった後で次の各手順を使用します。たとえば、リソースタイプ、リソースグループ、およびリソースプロパティを変更する場合は、 リソースタイプ、リソースグループ、リソースプロパティの変更へ進んでください。
リソースタイプの登録
リソースタイプは、指定されたタイプのすべてのリソースに適用される共通のプロパティとコールバックメソッドの仕様を提供します。リソースタイプは、そのタイプのリソースを作成する前に登録する必要があります。リソースタイプについての詳細は、第 1 章「Sun Cluster データサービスの計画」を参照してください。
リソースタイプの登録
この手順を実行するには、登録するリソースタイプに、データサービス名の略語で名前をつける必要があります。この名前は、データサービスのライセンス証明書に示されている名前に対応付ける必要があります。名前とライセンス証明書中の名前の対応については『Sun Cluster 3.1 ご使用にあたって』を参照してください。
詳細は、scrgadm(1M) のマニュアルページを参照してください。
注 –
この手順は、任意のクラスタノードから実行します。
-
クラスタメンバー上でスーパーユーザーになります。
-
リソースタイプを登録します。
# scrgadm -a -t resource-type
- -a
-
指定したリソースタイプを追加します。
- -t resource-type
-
追加するリソースタイプの名前を指定します。既定名から指定する場合は、『Sun Cluster 3.1 ご使用にあたって』を参照してください。
-
登録されたリソースタイプを確認します。
# scrgadm -pv -t resource-type
例 – リソースタイプの登録
次に、Sun Cluster HA for Sun ONE Web Server (内部名 iws) を登録する例を示します。
# scrgadm -a -t SUNW.iws # scrgadm -pv -t SUNW.iws Res Type name: SUNW.iws (SUNW.iws) Res Type description: None registered (SUNW.iws) Res Type base directory: /opt/SUNWschtt/bin (SUNW.iws) Res Type single instance: False (SUNW.iws) Res Type init nodes: All potential masters (SUNW.iws) Res Type failover: False (SUNW.iws) Res Type version: 1.0 (SUNW.iws) Res Type API version: 2 (SUNW.iws) Res Type installed on nodes: All (SUNW.iws) Res Type packages: SUNWschtt |
次に進む手順
リソースタイプを登録したあと、リソースグループを作成し、リソースをそのリソースグループに追加できます。詳細については、リソースグループの作成を参照してください。
リソースタイプのアップグレード
新しいバージョンのリソースタイプがリリースされると、アップグレードされたリソースタイプのインストールと登録をしたくなるでしょう。また、既存のリソースを新しいバージョンのリソースタイプにアップグレードしたくなるかもしれません。この節の次の手順では、アップグレードされたリソースタイプをインストールして登録する方法、および既存のリソースを新しいバージョンのリソースタイプにアップグレードする方法について説明します。
リソースタイプのアップグレードのインストールと登録
この手順は、scsetup の Resource Group オプションを使用して実行することもできます。scsetup については、scsetup(1M) のマニュアルページを参照してください。
-
すべてのクラスタノードに、そのリソースタイプのアップグレードパッケージをインストールします。
注 –リソースタイプのアップグレードパッケージがすべてのノードにインストールされていない場合は、追加手順を実行する必要があります (手順 3)。
リソースタイプのアップグレードパッケージをインストールするために、ノードを非クラスタモードで起動する必要があるかどうかについては、アップグレードに関するマニュアルを参照してください。停止時間を無くすためには、ローリングアップグレード方式で一度に一ノードづつ新しいパッケージを追加します。つまり、対象ノードを非クラスタモードで起動し、別のノードはクラスタモードにしておきます。
-
新しいバージョンのリソースタイプを登録します。
scrgadm -a -t resource_type -f path_to_new_RTR_file
新しいリソースタイプは、次の書式の名前になります。
vendor_id.rtname:version
scrgadm —p または scrgadm —pv (詳細形式で表示) を使用して、新しく登録したリソースタイプを表示します。
-
新しいリソースタイプをすべてのノードにインストールしない場合、それが実際にインストールされるノードに Installed_nodes プロパティを設定します。
scrgadm -c -t resource_type -h installed_node_list
リソースタイプの新しいバージョンは、次の点において以前のバージョンと異なる可能性があります。
-
リソースタイププロパティの設定が変更されている可能性があります
-
標準および拡張プロパティを含む、宣言されたリソースプロパティのセットが変更されている可能性があります
-
リソースプロパティの属性 (default、min、max、arraymin、arraymax、tunability) が変更されている可能性があります
-
宣言されたメソッドのセットが異なる
-
メソッドおよびモニターの実装が変更されている可能性があります
既存のリソースの新しいバージョンのリソースタイプへの移行
この手順は、scsetup の Resource Group オプションを使用して実行することもできます。scsetup については、scsetup(1M) のマニュアルページを参照してください。
既存のリソースタイプのバージョン、および新しいバージョンの変更点により、新しいバージョンへの移行方法が決定されます。リソースタイプのアップグレードに関するマニュアルに、移行が可能かどうかが記載されていることでしょう。移行がサポートされない場合は、そのリソースを削除してアップグレードバージョンの新しいリソースで置き換えるか、そのリソースを古いバージョンのリソースタイプのままで維持します。
既存のリソースを移行すると、次の値が変わるかもしれません。
- デフォルトのプロパティ値
-
リソースタイプのアップグレードバージョンが、デフォルト値を持つプロパティに対して新しいデフォルト値を宣言する場合、新しいデフォルト値が既存のリソースによって継承されます。
新しいリソースタイプバージョンの VALIDATE メソッドは、既存のプロパティ設定が適切かどうかを検査します。設定が適切でない場合は、既存リソースのプロパティを編集して適切な値にしてください。プロパティを編集するには、手順 3を参照してください。
- リソースタイプ名
-
RTR ファイルには、次のプロパティが含まれており、リソースタイプの完全修飾名の形成に使用されます。
-
Vendor_id
-
Resource_type
-
RT_Version
リソースタイプのアップグレードバージョンを登録する場合、vendor_id.rtname:version という名前で格納されます。新しいバージョンに移行されたリソースは、上に示したプロパティから構成される、新しい Type プロパティを持ちます。
-
- リソースの type_version プロパティ
-
標準のリソースプロパティ Type_version は、リソースタイプの RT_Version プロパティを格納します。Type_Version プロパティは RTR ファイルに含まれません。次のコマンドを使用して、Type_Version プロパティを編集します。
scrgadm -c -j resource -y Type_version=new_version
-
既存リソースをそのリソースタイプの新しいバージョンに移行する前に、新しいリソースタイプに付属するアップグレードマニュアルを読んで、移行が実施できるかどうかを判断してください。
そのマニュアルには、移行をいつ行うべきかも示されるでしょう。
-
任意の時点
-
リソースが監視されていないとき
-
リソースがオフラインのとき
-
リソースが無効になっている時
-
リソースグループが管理されていないとき
移行がサポートされない場合は、そのリソースを削除しアップグレードバージョンの新しいリソースで置き換えるか、そのリソースを古いバージョンのリソースタイプのままで維持します。
-
-
移行するリソースタイプの各リソースごとに、リソースまたはそのリソースグループの状態をアップグレードマニュアルに示されている適切な状態に変更します。
たとえば、リソースを非管理状態にする場合は、次のように変更します。
scswitch -M -n -j resource
リソースをオフラインにするには、次のように変更します。
scswitch -n -j resource
リソースを無効化する場合は、次のように変更します。
scswitch -n -j resource
リソースグループを非管理状態にする場合は、次のように変更します。
scsswitch -n -j resource-group scswitch -F -g resource_group scswitch -u -g resource_group
-
移行するリソースタイプの各リソースごとにリソースを編集して、その Type_version プロパティを新しいバージョンに変更します。
scrgadm -c -j resource -y Type_version=new_version \ -x extension_property=new_value -y extension_property=new_value
必要に応じて、同じリソースの別のプロパティを適切な値で編集します。同じコマンドを使用して、コマンド行に —x と —y オプションのいずれかまたは両方を追加します。
-
手順 2 で入力したコマンドとは逆の操作を行うコマンドを実行して、リソースまたはリソースグループを前の状態に戻します。
たとえば、リソースを再び監視状態にするには、次のように入力します。
scswitch -M -e -j resource
リソースを再び有効状態にするには、次のように入力します。
scswitch -e -j resource
リソースグループを管理状態でオンラインにするには、次のように入力します。
scswitch -o -g resource_group scswitch -Z -g resource_group
例 1 – 既存のリソースを新しいバージョンのリソースタイプに移行する
この例では、既存リソースを新しいバージョンのリソースタイプに移行する方法を示します。新しいリソースタイプパッケージに含まれるメソッドは、新しいパスの場所にあります。メソッドはインストール時に上書きされないため、アップグレードされたリソースタイプがインストールされるまで、そのリソースを無効にする必要はありません。
この実例では、次の前提に基づいています。
-
新しいリソースタイプのバージョンは 2.0 です。
-
以前のバージョンの調整状態は、“when_offline” です。
-
リソース名は、“myresource” です。
-
リソースタイプ名は、“myrt” です。
-
新しい RTR ファイルは、/opt/XYZmyrt/etc/XYZ.myrt にあります。
-
移行されるリソースに対する依存関係はありません。
-
移行されるリソースはオフラインにできます (それに含まれるリソースグループはオンラインのまま)。
(ベンダの指示に従い、すべてのノードに新しいパッケージをインストールする) # scrgadm -a -t myrt -f /opt/XYZmyrt/etc/XYZ.myrt # scswitch -n -j myresource # scrgadm -c -j myresource -y Type_version=2.0 # scswitch -e -j myresource |
例 2 – 既存のリソースの新しいバージョンのリソースタイプへの移行
この例では、既存リソースを新しいバージョンのリソースタイプに移行する方法を示します。新しいリソースタイプパッケージは、モニターファイルと RTR ファイルのみを含みます。モニターファイルはインストール時に上書きされるため、アップグレードされたリソースタイプをインストールする前に、リソースを無効化する必要があります。
この実例では、次の前提に基づいています。
-
新しいリソースタイプのバージョンは 2.0 です。
-
以前のバージョンの調整状態は、“when_unmonitored” です。
-
リソース名は、“myresource” です。
-
リソースタイプ名は、“myrt” です。
-
新しい RTR ファイルは、/opt/XYZmyrt/etc/XYZ.myrt にあります。
# scswitch -M -n -j myresource (ベンダの指示に従って、新しいパッケージをインストールする) # scrgadm -a -t myrt -f /opt/XYZmyrt/etc/XYZ.myrt # scrgadm -c -j myresource -y Type_version=2.0 # scswitch -M -e -j myresource |
リソースグループの作成
リソースグループには、一連のリソースが含まれており、これらすべてのリソースは指定のノードまたはノード群で共にオンラインまたはオフラインになります。リソースを配置する前に、空のリソースグループを作成します。
リソースグループには、フェイルオーバーとスケーラブルの 2 つの種類があります。フェイルオーバーリソースグループの場合、同時にオンラインにできるのは 1 つのノードでのみです。一方、スケーラブルリソースグループの場合は、同時に複数のノードでオンラインにできます。
次の手順では、scrgadm(1M) コマンドを使ってデータサービスの登録と構成を行います。
リソースグループの概念情報については、このマニュアルの第 1 章「Sun Cluster データサービスの計画」と『Sun Cluster 3.1 の概念』を参照してください。
フェイルオーバーリソースグループの作成
フェイルオーバーリソースグループは、ネットワークアドレス (組み込みリソースタイプの LogicalHostname や SharedAddress など) と、フェイルオーバーリソース (フェイルオーバーデータサービスのためのデータサービスアプリケーションリソースなど) を含みます。ネットワークリソースは、データサービスがフェイルオーバーまたはスイッチオーバーする場合に、依存するデータサービスリソースと共に、クラスタノード間を移動します。
詳細は、scrgadm(1M) のマニュアルページを参照してください。
注 –
この手順は、任意のクラスタノードから実行します。
-
クラスタメンバー上でスーパーユーザーになります。
-
フェイルオーバーリソースグループを作成します。
# scrgadm -a -g resource-group [-h nodelist]
- -a
-
指定したリソースグループを追加します。
- -g resource-group
-
追加するフェイルオーバーリソースグループの名前を指定します。任意の名前の先頭文字は ASCII にする必要があります。
- -h nodelist
-
このリソースグループをマスターできるノードの順位リストを指定します (省略可能)。このリストを指定しない場合は、デフォルトでクラスタ内のすべてのノードになります。
-
リソースグループが作成されていることを確認します。
# scrgadm -pv -g resource-group
例 – フェイルオーバーリソースグループの作成
次に、 2 つのノード (phys-schost-1 と phys-schost-2) がマスターできるフェイルオーバーリソースグループ (resource-group-1) を追加する例を示します。
# scrgadm -a -g resource-group-1 -h phys-schost1,phys-schost-2 # scrgadm -pv -g resource-group-1 リソースグループ 名前: 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) リソースグループ モード: Failover (resource-group-1) リソースグループ ネットワーク依存関係: True (resource-group-1) リソースグループ Global_resources_used: All (resource-group-1) リソースグループ Pathprefix: |
次に進む手順
フェイルオーバーリソースグループを作成した後で、そのリソースグループにアプリケーションリソースを追加できます。手順については、リソースグループへのリソースの追加を参照してください。
スケーラブルリソースグループの作成
スケーラブルリソースグループは、スケーラブルサービスと共に使用されます。共有アドレス機能は、スケーラブルサービスの多数のインスタンスを 1 つのサービスとして扱える Sun Cluster のネットワーキング機能です。まず、スケーラブルリソースが依存する共有アドレスを含むフェイルオーバーリソースグループを作成しなければなりません。次にスケーラブルリソースグループを作成し、そのグループにスケーラブルリソースを追加します。
詳細は、scrgadm(1M) のマニュアルページを参照してください。
注 –
この手順は、任意のクラスタノードから実行します。
-
クラスタメンバー上でスーパーユーザーになります。
-
スケーラブルリソースが使用する共有アドレスを保持するフェイルオーバーリソースグループを作成します。
-
スケーラブルリソースグループを作成します。
# scrgadm -a -g resource-group \ -y Maximum_primaries=m \ -y Desired_primaries=n \ -y RG_dependencies=depend-resource-group \ -h nodelist]
- -a
-
スケーラブルリソースグループを追加します。
- -g resource-group
-
追加するスケーラブルリソースグループの名前を指定します。
- -y Maximum_primaries=m
-
このリソースグループのアクティブな主ノードの最大数を指定します。
- -y Desired_primaries=n
-
リソースグループが起動するアクティブな主ノードの数を指定します。
- -y RG_dependencies=depend-resource-group
-
作成されるリソースグループが依存する共有アドレスリソースを含むリソースグループを指定します。
- -h nodelist
-
リソースグループを利用できるノードのリストを指定します (省略可能)。このリストを指定しない場合は、デフォルトですべてのノードになります。
-
スケーラブルリソースグループが作成されていることを確認します。
# scrgadm -pv -g resource-group
例 – スケーラブルリソースグループの作成
次に、2 つのノード (phys-schost-1、phys-schost-2) でホストされるスケーラブルリソースグループ (resource-group-1) を追加する例を示します。スケーラブルリソースグループは、共有アドレスを含むフェイルオーバーリソースグループ (resource-group-2) に依存します。
# scrgadm -a -g resource-group-1 \ -y Maximum_primaries=2 \ -y Desired_primaries=2 \ -y RG_dependencies=resource-group-2 \ -h phys-schost-1,phys-schost-2 # scrgadm -pv -g resource-group-1 リソースグループ 名前: 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) リソースグループ モード: Scalable (resource-group-1) リソースグループ ネットワーク依存関係: True (resource-group-1) リソースグループ Global_resources_used: All (resource-group-1) Res Group Pathprefix: |
次に進む手順
スケーラブルリソースグループを作成したあと、そのリソースグループにスケーラブルアプリケーションリソースを追加できます。詳細は、スケーラブルアプリケーションリソースのリソースグループへの追加を参照してください。
リソースグループへのリソースの追加
リソースは、リソースタイプをインスタンス化したものです。リソースは、RGM によって管理される前に、リソースグループに追加する必要があります。この節では、3 種類のリソースタイプについて説明します。
-
論理ホスト名リソース
-
共有アドレスリソース
-
データサービス (アプリケーション) リソース
論理ホスト名リソースと共有アドレスリソースは、常にフェイルオーバーリソースグループに追加してください。フェイルオーバーデータサービス用のデータサービスリソースは、フェイルオーバーリソースグループに追加してください。フェイルオーバーリソースグループは、そのデータサービス用の論理ホスト名リソースとアプリケーションリソースの両方を含みます。スケーラブルリソースグループは、スケーラブルサービス用のアプリケーションリソースだけを含んでいます。スケーラブルサービスが依存する共有アドレスリソースは、別のフェイルオーバーリソースグループに存在する必要があります。データサービスをクラスタノード全体に渡って提供するには、スケーラブルアプリケーションリソースと共有アドレスリソース間の依存性を指定する必要があります。
リソースについての詳細は、『Sun Cluster 3.1 の概念』と、このマニュアルの第 1 章「Sun Cluster データサービスの計画」 を参照してください。
論理ホスト名リソースのリソースグループへの追加
-
リソースを追加するフェイルオーバーリソースグループの名前
-
リソースグループに追加するホスト名
詳細は、scrgadm(1M) のマニュアルページを参照してください。
注 –
この手順は、任意のクラスタノードから実行します。
-
クラスタメンバー上でスーパーユーザーになります。
-
論理ホスト名リソースをリソースグループに追加します。
# scrgadm -a -L [-j resource] -g resource-group -l hostnamelist, … [-n netiflist]
- -a
-
論理ホスト名リソースを追加します。
- -L
-
論理ホスト名リソースの形式を指定します。
- -j resource
-
リソース名を指定します (省略可能)。このオプションを指定しない場合は、デフォルトで -l オプションで最初に指定したホスト名になります。
- -g resource-group
-
リソースを配置するリソースグループの名前を指定します。
- -l hostnamelist, …
-
クライアントがリソースグループのサービスと通信する際に使用する UNIX ホスト名 (論理ホスト名) をコマンドで区切って指定します。
- -n netiflist
-
各ノード上の IP ネットワークマルチパスグループをコンマで区切って指定します (省略可能)。netiflist 内の各要素の書式は、 netif@node でなければなりません。 netif は、sc_ipmp0 などの IP ネットワークマルチパスグループ名として指定できます。ノードは、sc_ipmp@phys-schost-1 や sc_ipmp0@1 などのノード名またはノード ID で識別できます。
注 –現在 Sun Cluster では、netif にアダプタ名を使用できません。
-
論理ホスト名リソースが追加されていることを確認します。
# scrgadm -pv -j resource
リソースを追加すると、Sun Cluster ソフトウェアはそのリソースの妥当性を検査します。妥当性が確認されると、そのリソースを有効にできるとともに、そのリソースグループを RGM の管理下に置くことができます。妥当性の検査に失敗すると、scrgadm コマンドはエラーメッセージを生成して終了します。妥当性の検査に失敗した場合は、各ノード上の syslog でエラーメッセージを調べてください。メッセージは、妥当性の検査を実施したノードで表示されます。必ずしも scrgadm コマンドを実行したノードで表示されるわけではありません。
例 – 論理ホスト名リソースのリソースグループへの追加
次に、論理ホスト名リソース (resource-1) をリソースグループ (resource-group-1) に追加する例を示します。
# scrgadm -a -L -j resource-1 -g resource-group-1 -l schost-1 # scrgadm -pv -j resource-1 リソースグループ 名前: resource-group-1 (resource-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 |
次に進む手順
論理ホスト名リソースを追加したあと、リソースグループのオンライン化の手順に従って、このリソースをオンラインにします。
共有アドレスリソースのリソースグループへの追加
-
リソースを追加するリソースグループの名前。このグループは、前の手順で作成したフェイルオーバーリソースグループでなければなりません。
-
リソースグループに追加するホスト名。
詳細は、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 は、sc_ipmp0 などの IP ネットワークマルチパスグループ名として指定できます。ノードは、 sc_ipmp@phys-schost-1 やsc_ipmp0@1 などのノード名またはノード ID で識別できます。
注 –現在 Sun Cluster では、netif にアダプタ名を使用できません。
-
共有アドレスリソースが追加され、妥当性が検査されていることを確認します。
# scrgadm -pv -j resource
リソースを追加すると、Sun Cluster ソフトウェアはそのリソースの妥当性を検査します。妥当性が確認されると、そのリソースを有効にできるとともに、そのリソースグループを RGM の管理下に置くことができます。妥当性の検査に失敗すると、scrgadm コマンドはエラーメッセージを生成して終了します。妥当性の検査に失敗した場合は、各ノード上の syslog でエラーメッセージを調べてください。メッセージは、妥当性の検査を実施したノードで表示されます。必ずしも scrgadm コマンドを実行したノードで表示されるわけではありません。
例 – 共有アドレスリソースのリソースグループへの追加
次に、共有アドレスリソース (resource-1) をリソースグループ (resource-group-1) に追加する例を示します。
# scrgadm -a -S -j resource-1 -g resource-group-1 -l schost-1 # scrgadm -pv -j resource-1 (resource-group-1) リソース 名前: resource-1 (resource-group-1:resource-1) リソース R_description: (resource-group-1:resource-1) リソース リソースタイプ: SUNW.SharedAddress (resource-group-1:resource-1) リソース リソースグループ名: 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 「標準プロパティ」 を参照してください。
注 –別のプロパティを設定することもできます。詳細は、付録 A 「標準プロパティ」 とこのマニュアルのフェイルオーバーデータサービスのインストールと構成に関する各章を参照してください。
-
フェイルオーバーアプリケーションリソースが追加され、妥当性が検査されていることを確認します。
# scrgadm -pv -j resource
リソースを追加すると、Sun Cluster ソフトウェアはそのリソースの妥当性を検査します。妥当性が確認されると、そのリソースを有効にできるとともに、そのリソースグループを RGM の管理下に置くことができます。妥当性の検査に失敗すると、scrgadm コマンドはエラーメッセージを生成して終了します。妥当性の検査に失敗した場合は、各ノード上の syslog でエラーメッセージを調べてください。メッセージは、妥当性の検査を実施したノードで表示されます。必ずしも scrgadm コマンドを実行したノードで表示されるわけではありません。
例 – フェイルオーバーアプリケーションリソースのリソースグループへの追加
次に、リソース (resource-1) をリソースグループ (resource-group-1) に追加する例を示します。 リソースは、論理ホスト名リソース (schost-1、schost-2) に依存し、以前に定義したフェイルオーバーリソースグループと同じリソースグループに存在する必要があります。
# scrgadm -a -j resource-1 -g resource-group-1 -t resource-type-1 \ -y Network_resources_used=schost-1,schost2 \ # scrgadm -pv -j resource-1 (resource-group-1) リソース 名前: resource-1 (resource-group-1:resource-1) リソース R_description: (resource-group-1:resource-1) リソース リソースタイプ: resource-type-1 (resource-group-1:resource-1) リソース リソースグループ名: 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, …
-
特定のデータサービスに依存する標準プロパティをコンマで区切って指定します。データサービスにこのプロパティの指定が必要かどうかについては、各データサービスについて説明している章と付録 A 「標準プロパティ」 を参照してください。
- -y Standard_property=value, …
-
Specifies a comma-separated list of standard properties that depends on the particular data service. See the chapter for each data service and 付録 A 「標準プロパティ」 to determine whether the data service requires this property.
注 –別のプロパティを設定することもできます。構成可能な他のプロパティについては、付録 A 「標準プロパティ」とこのマニュアルのスケーラブルデータサービスのインストールと構成に関する各章を参照してください。スケーラブルサービスの場合は、通常、Port_list、 Load_balancing_weights、Load_balancing_policy プロパティを設定します (付録 A 「標準プロパティ」 を参照)。
-
スケーラブルアプリケーションリソースが追加され、妥当性が検査されていることを確認します。
# scrgadm -pv -j resource
リソースを追加すると、Sun Cluster ソフトウェアはそのリソースの妥当性を検査します。妥当性が確認されると、そのリソースを有効にできるとともに、そのリソースグループを RGM の管理下に置くことができます。妥当性の検査に失敗すると、scrgadm コマンドはエラーメッセージを生成して終了します。妥当性の検査に失敗した場合は、各ノード上の syslog でエラーメッセージを調べてください。メッセージは、妥当性の検査を実施したノードで表示されます。必ずしも scrgadm コマンドを実行したノードで表示されるわけではありません。
例 – スケーラブルアプリケーションリソースのリソースグループへの追加
次に、リソース (resource-1) をリソースグループ (resource-group-1) に追加する例を示します。 resource-group-1 は、使用されているネットワークアドレス (以下の例の schost-1 と schost-2) を含むフェイルオーバーリソースグループに依存することに注意してください。 このリソースは、共有アドレスリソース ( (schost-1、schost-2) に依存し、共有アドレスリソースは以前に定義した 1 つまたは複数のフェイルオーバーリソースグループに存在する必要があります。
# scrgadm -a -j resource-1 -g resource-group-1 -t resource-type-1 \ -y Network_resources_used=schost-1,schost-2 \ -y Scalable=True # scrgadm -pv -j resource-1 (resource-group-1) リソース 名前: 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 |
次に進む手順
スケーラブルアプリケーションリソースを追加したあと、リソースグループのオンライン化の手順に従ってリソースを有効にします。
リソースグループのオンライン化
リソースが HA サービスの提供を開始できるようにするには、リソースグループのリソースおよびリソースモニターを有効にし、リソースグループを管理状態にし、リソースグループをオンラインにする必要があります。これらの作業は個別に実行できますが、次に示すように 1 つの手順で実行することもできます。詳細は、scswitch(1M) のマニュアルページを参照してください。
注 –
この手順は、任意のクラスタノードから実行します。
リソースグループのオンライン化
-
クラスタメンバー上でスーパーユーザーになります。
-
リソースを有効にし、リソースグループをオンラインにします。
リソースモニターを無効にしている場合は、これも有効になります。
# scswitch -Z -g resource-group
- -Z
-
最初にリソースグループとそのモニターを有効にし、リソースグループをオンラインにします。
- -g resource-group
-
オンラインにするリソースグループの名前を指定します。既存のリソースグループを指定する必要があります。
-
リソースがオンラインになっていることを確認します。
任意のクラスタノードで次のコマンドを実行し、Resource Group State のフィールドを調べ、ノードリストで指定されたノードでリソースグループがオンラインになっていることを確認します。
# scstat -g
例 – リソースグループのオンライン化
次に、リソースグループ (resource-group-1) をオンラインにし、その状態を確認する例を示します。
# scswitch -Z -g resource-group-1 # scstat -g |
次に進む手順
リソースグループがオンラインになれば、リソースグループを構成し使用する準備が整ったことになります。リソースやノードで障害が発生した場合は、RGM は別のノードでそのリソースグループをオンラインに切り替えることでリソースグループの可用性を維持します。
リソースモニターの無効化と有効化
次の各手順では、リソース自体とは関係なくリソース障害モニターだけを無効または有効にします。したがって、障害モニターが無効にされても、そのリソース自体は正常に動作を続けます。ただし、障害モニターが無効になっていると、データサービスに障害が発生しても、障害回復は自動的には開始されません。
詳細は、scswitch(1M) のマニュアルページを参照してください。
注 –
この手順は任意のノードから実行できます。
リソース障害モニターの無効化
-
クラスタメンバー上でスーパーユーザーになります。
-
リソース障害モニターを無効にします。
# scswitch -n -M -j resource
- -n
-
リソースまたはリソースモニターを無効にします。
- -M
-
指定されたリソースの障害モニターを無効にします。
- -j resource
-
リソースの名前
-
リソース障害モニターが無効になっていることを確認します。
各クラスタノードで次のコマンドを実行し、監視されるフィールド (RS Monitored) を確認します。
# scrgadm -pv
例–リソース障害モニターの無効化
この例では、リソース障害モニターを無効にします。
# scswitch -n -M -j resource-1 # scrgadm -pv ... RS Monitored: no... |
リソース障害モニターの有効化
-
クラスタメンバー上でスーパーユーザーになります。
-
リソース障害モニターを有効にします。
# scswitch -e -M -j resource
- -e
-
リソースまたはリソースモニターを有効にします。
- -M
-
指定されたリソースの障害モニターを有効にします。
- -j resource
-
リソースの名前を指定します。
-
リソース障害モニターが有効になっていることを確認します。
各クラスタノードで次のコマンドを実行し、監視されるフィールド (RS Monitored) を確認します。
# scrgadm -pv
例–リソース障害モニターの有効化
この例では、リソース障害モニターを有効にします。
# scswitch -e -M -j resource-1 # scrgadm -pv ... RS Monitored: yes... |
リソースタイプの削除
使用されていないリソースタイプを削除する必要はありませんが、次の手順を使用して削除できます。
詳細は、scrgadm(1M) および scswitch(1M) のマニュアルページを参照してください。
注 –
この手順は、任意のクラスタノードから実行します。
リソースタイプの削除
リソースタイプを削除する前に、クラスタ内のすべてのリソースグループにある、そのタイプのリソースをすべて無効にし、削除する必要があります。scrgadm -pv コマンドを使用し、クラスタ内のリソースとリソースグループを確認します。
-
クラスタメンバー上でスーパーユーザーになります。
-
削除するリソースタイプの各リソースを無効にします。
# scswitch -n -j resource
- -n
-
リソースを無効にします。
- -j resource
-
無効にするリソースの名前を指定します。
-
削除するリソースタイプの各リソースを削除します。
# scrgadm -r -j resource
- -r
-
指定したリソースを削除します。
- -j
-
削除するリソースの名前を指定します。
-
リソースタイプを削除します。
# scrgadm -r -t resource-type
- -r
-
指定したリソースタイプを削除します。
- -t resource-type
-
削除するリソースタイプの名前を指定します。
-
リソースタイプが削除されていることを確認します。
# scrgadm -p
例 – リソースタイプの削除
次に、リソースタイプのすべてのリソース (resource-type-1) を無効にして削除したあとで、そのリソースタイプ自体を削除する例を示します。この例では、resource-1 は、リソースタイプ resource-type-1 のリソースです。
# scswitch -n -j resource-1 # scrgadm -r -j resource-1 # scrgadm -r -t resource-type-1 |
リソースグループの削除
リソースグループを削除するには、最初にそのリソースグループからすべてのリソースを削除する必要があります。
詳細は、scrgadm(1M) および scswitch(1M) のマニュアルページを参照してください。
注 –
この手順は、任意のクラスタノードから実行します。
リソースグループの削除
-
クラスタメンバー上でスーパーユーザーになります。
-
次のコマンドを実行し、リソースグループをオフラインに切り替えます。
# scswitch -F -g resource-group
- -F
-
リソースグループをオフラインに切り替えます。
- -g resource-group
-
オフラインにするリソースグループの名前を指定します。
-
リソースグループに含まれているすべてのリソースを無効にします。
scrgadm -pv コマンドを使用することにより、リソースグループ内のリソースを表示できます。リソースグループ内の削除するすべてのリソースを無効にします。
# scswitch -n -j resource
- -n
-
リソースを無効にします。
- -j resource
-
無効にするリソースの名前を指定します。
依存性のあるデータサービスリソースがリソースグループに存在する場合、そのリソースを無効にするには、依存するすべてのリソースを無効にする必要があります。
-
リソースグループからすべてのリソースを削除します。
-
リソースの削除
-
リソースグループの削除
# scrgadm -r -j resource # scrgadm -r -g resource-group
- -r
-
指定したリソースやリソースグループを削除します。
- -j resource
-
削除するリソースの名前を指定します。
- -g resource-group
-
削除するリソースグループの名前を指定します。
-
-
リソースグループが削除されていることを確認します。
# scrgadm -p
例 – リソースグループの削除
次に、リソースグループ (resource-group-1) のリソース (resource-1) を削除した後で、そのリソースグループ自体を削除する例を示します。
# scswitch -F -g resource-group-1 # scrgadm -r -j resource-1 # scrgadm -r -g resource-group-1 |
リソースの削除
リソースグループからリソースを削除する前に、そのリソースを無効にします。
詳細は、scrgadm(1M) および scswitch(1M) のマニュアルページを参照してください。
注 –
この手順は、任意のクラスタノードから実行します。
リソースの削除
-
クラスタメンバー上でスーパーユーザーになります。
-
削除するリソースを無効にします。
# scswitch -n -j resource
- -n
-
リソースを無効にします。
- -j resource
-
無効にするリソースの名前を指定します。
-
リソースを削除します。
# scrgadm -r -j resource
- -r
-
指定したリソースを削除します。
- -j resource
-
削除するリソースの名前を指定します。
-
リソースが削除されていることを確認します。
# scrgadm -p
例 – リソースの削除
次に、リソース resource-1 を無効にして削除する例を示します。
# scswitch -n -j resource-1 # scrgadm -r -j resource-1 |
リソースグループの主ノードへの切り替え
以下の手順を使用し、リソースグループの現在の主ノードを別のノードに切り替え (スイッチオーバー)、新しい主ノードにすることができます。
詳細は、scrgadm(1M) および scswitch(1M) のマニュアルページを参照してください。
注 –
この手順は、任意のクラスタノードから実行します。
リソースグループの主ノードへの切り替え
この手順を実行するには、次の情報が必要になります。
-
スイッチオーバーするリソースグループの名前
-
リソースグループをオンラインにする、またはオンラインを維持するノードの名前。スイッチオーバーを行うリソースグループの、潜在的マスターとして設定されているクラスタノードを指定する必要があります。リソースグループの潜在的主ノードの一覧を表示するには、scrgadm -pv コマンドを使用します。
-
クラスタメンバー上でスーパーユーザーになります。
-
主ノードを潜在的主ノードに切り替えます。
# scswitch -z -g resource-group -h nodelist
- -z
-
指定したリソースグループをオンラインに切り替えます。
- -g resource-group
-
切り替えるリソースグループの名前を指定します。
- -h nodelist
-
リソースグループをオンラインにする、またはオンラインを維持するノードを指定します。このリソースグループは、このノード以外のすべてのノードでオフラインに切り替えられます。
-
リソースグループが新しい主ノードに切り替えられていることを確認します。
次のコマンドを実行し、スイッチオーバーされたリソースグループの状態に関する出力を調べます。
# scstat -g
例 – リソースグループの新しい主ノードへの切り替え
次に、リソースグループ (resource-group-1) を現在の主ノード (phys-schost-1) から、潜在的主ノード (phys-schost-2) へ切り替える例を示します。まず、リソースグループが phys-schost-1 でオンラインになっていることを確認します。続いて、切り替えを行います。最後に、そのグループが phys-schost-2 でオンラインに切り替えられたことを確認します。
phys-schost-1# scstat -g
...
グループ名 ノード名 状態
---------- --------- -----
グループ: resource-group-1 phys-schost-2 オンライン
グループ: resource-group-1 phys-schost-1 オフライン
Node 名: phys-schost-2
状態: オフライン
...
phys-schost-1# scswitch -z -g resource-group-1 -h phys-schost-2
phys-schost-1# scstat -g
...
グループ名 ノード名 状態
---------- --------- -----
グループ: resource-group-1 phys-schost-2 オンライン
グループ: resource-group-1 phys-schost-1 オフライン
...
|
リソースの無効化とリソースグループの UNMANAGED 状態への移行
場合によっては、リソースグループは、そのリソースグループに対して管理手順を実施する前に、UNMANAGED 状態に移行する必要があります。リソースグループを UNMANAGED 状態に移行する前に、リソースグループに含まれるすべてのリソースを無効にし、リソースグループをオフラインにする必要があります。
詳細は、scrgadm(1M) および scswitch(1M) のマニュアルページを参照してください。
注 –
この手順は、任意のクラスタノードから実行します。
リソースの無効化とリソースグループの UNMANAGED 状態への移行
この手順を実行するには、次の情報が必要になります。
-
無効にするリソースの名前
-
UNMANAGED 状態に移行するリソースグループの名前
この手順に必要なリソースとリソースグループの名前を調べるには、scrgadm -pv コマンドを使用します。
-
クラスタメンバー上でスーパーユーザーになります。
-
リソースを無効にします。
この手順を、リソースグループ内のすべてのリソースに対して実行します。
# scswitch -n -j resource
- -n
-
リソースを無効にします。
- -j resource
-
無効にするリソースの名前を指定します。
-
次のコマンドを実行し、リソースグループをオフラインに切り替えます。
# scswitch -F -g resource-group
- -F
-
リソースグループをオフラインに切り替えます。
- -g resource-group
-
オフラインにするリソースグループの名前を指定します。
-
リソースグループを UNMANAGED 状態にします。
# scswitch -u -g resource-group
- -u
-
指定したリソースグループを UNMANAGED 状態にします。
- -g resource-group
-
UNMANAGED 状態にするリソースグループの名前を指定します。
-
リソースが無効になり、リソースグループが UNMANAGED 状態になっていることを確認します。
# scrgadm -pv -g resource-group
例 – リソースの無効化とリソースグループの UNMANAGED 状態への移行
次に、リソース(resource-1) を無効にし、リソースグループ (resource-group-1) を UNMANAGED 状態に移行する例を示します。
# scswitch -n -j resource-1 # scswitch -F -g resource-group-1 # scswitch -u -g resource-group-1 # scrgadm -pv -g resource-group-1 リソースグループ 名前: resource-group-1 (resource-group-1) リソースグループ RG_description: <NULL> (resource-group-1) リソースグループ management state: Unmanaged (resource-group-1) リソースグループ Failback: False (resource-group-1) リソースグループ Nodelist: phys-schost-1 phys-schost-2 (resource-group-1) リソースグループ Maximum_primaries: 2 (resource-group-1) リソースグループ Desired_primaries: 2 (resource-group-1) リソースグループ RG_dependencies: <NULL> (resource-group-1) リソースグループ モード: Failover (resource-group-1) リソースグループ ネットワーク依存関係: 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 コマンドは、構成状態に関する次の 3 つのレベルの情報を表示します。
-
-p オプションを指定した場合は、リソースタイプ、リソースグループ、リソースのプロパティ値に関する限定された情報が表示されます。
-
-pv オプションを指定した場合は、他のリソースタイプ、リソースグループ、リソースプロパティに関する詳細が表示されます。
-
-pvv オプションを指定した場合は、リソースタイプメソッド、拡張プロパティ、すべてのリソースとリソースグループのプロパティを含む、詳細情報が表示されます。
また、-t (リソースタイプ)、-g (リソースグループ)、および -j (リソース) オプションと、その後に表示したいオブジェクトの名前を指定することによって、特定のリソースタイプ、リソースグループ、またはリソースのステータス情報を確認できます。たとえば、次のコマンドは、リソース apache-1 のみについて、特定の情報を表示することを指定します。
# scrgadm -p[v[v]] -j apache-1 |
詳細は、scrgadm(1M) のマニュアルページを参照してください。
リソースタイプ、リソースグループ、リソースプロパティの変更
リソースグループとリソースは、変更可能な標準の構成プロパティを持っています。次の各手順では、これらのプロパティの変更方法を説明します。
リソースには拡張プロパティがあり、一部の拡張プロパティはデータサービス開発者によってあらかじめ定義されているため、変更することができません。各データサービスの拡張プロパティの一覧については、このマニュアルのデータサービスに関する各章を参照してください。
リソースグループとリソースの標準の構成プロパティについては、scrgadm(1M) のマニュアルページを参照してください。
リソースタイププロパティの変更
この手順を実行するには、次の情報が必要になります。
-
変更するリソースタイプの名前
-
変更するリソースタイププロパティの名前。リソースタイプの場合、変更できるのは 1 つのプロパティのみです。つまり、このリソースタイプをインスタンス化できるノードのリストのみです。
注 –
この手順は、任意のクラスタノードから実行します。
-
クラスタメンバー上でスーパーユーザーになります。
-
scrgadm コマンドを使用し、この手順に必要なリソースタイプの名前を判断します。
# scrgadm -pv
-
リソースタイププロパティを変更します。
リソースタイプで変更できる唯一のプロパティは、Installed_node_list です。
# scrgadm -c -t resource-type -h installed-node-list
- -c
-
指定したリソースタイププロパティを変更します。
- -t resource-type
-
リソースタイプの名前を指定します。
- -h installed-node-list
-
このリソースタイプがインストールされるノードの名前を指定します。
-
リソースタイププロパティが変更されていることを確認します。
# scrgadm -pv -t resource-type
例 – リソースタイププロパティの変更
次に、SUNW.apache プロパティを変更し、このリソースタイプが 2 つのノード (phys-schost-1 および phys-schost-2) にインストールされているように定義する例を示します。
# scrgadm -c -t SUNW.apache -h phys-schost-1,phys-schost-2 # scrgadm -pv -t SUNW.apache リソースタイプ 名前: SUNW.apache:3.1 (SUNW.apache) リソースタイプ 説明: Apache Web Server on Sun Cluster (SUNW.apache) リソースタイプ ベースディレクトリ: /opt/SUNWscapc/bin (SUNW.apache) リソースタイプ 単一のインスタンス: False (SUNW.apache) リソースタイプ 初期ノード: All potential masters (SUNW.apache) リソースタイプ フェイルオーバー: False (SUNW.apache) リソースタイプ バージョン: 3.1 (SUNW.apache) リソースタイプ API バージョン: 2 (SUNW.apache) リソースタイプ ノードにインストールされている: <All> (SUNW.apache) リソースタイプ パッケージ: SUNWscapc |
リソースグループプロパティの変更
この手順を実行するには、次の情報が必要になります。
-
変更するリソースグループの名前
-
変更するリソースグループプロパティの名前とその新しいプロパティ値
この手順では、リソースグループプロパティの変更方法について説明しています。リソースグループプロパティの一覧については、付録 A 「標準プロパティ」を参照してください。
注 –
この手順は、任意のクラスタノードから実行します。
-
クラスタメンバー上でスーパーユーザーになります。
-
リソースグループプロパティを変更します。
# scrgadm -c -g resource-group -y property=new_value
- -c
-
指定したプロパティを変更します。
- -g resource-group
-
リソースグループの名前を指定します。
- -y property
-
変更するプロパティの名前を指定します。
-
リソースグループプロパティが変更されていることを確認します。
# scrgadm -pv -g resource-group
例 – リソースグループプロパティの変更
次に、リソースグループ (resource-group-1) の Failback プロパティを変更する例を示します。
# scrgadm -c -g resource-group-1 -y Failback=True # scrgadm -pv -g resource-group-1 |
リソースプロパティの変更
この手順を実行するには、次の情報が必要になります。
-
変更するプロパティを持つリソースの名前
-
変更するプロパティの名前
この手順は、リソースプロパティの変更方法について説明しています。リソースグループプロパティの一覧については、付録 A 「標準プロパティ」を参照してください。
注 –
この手順は、任意のクラスタノードから実行します。
-
クラスタメンバー上でスーパーユーザーになります。
-
scrgadm -pvv コマンドを実行し、現在のリソースプロパティ設定を表示します。
# scrgadm -pvv -j resource
-
リソースプロパティを変更します。
# scrgadm -c -j resource -y property=new_value | -x extension_property=new_value
- -c
-
指定したプロパティを変更します。
- -j resource
-
リソースの名前を指定します。
- -y property=new_value
-
変更する標準プロパティの名前を指定します。
- -x extension_property=new_value
-
変更する拡張プロパティの名前を指定します。Sun が提供するデータサービスについては、データサービスのインストールと構成に関する各章で説明されている拡張プロパティを参照してください。
-
リソースプロパティが変更されていることを確認します。
# scrgadm pvv -j resource
例 – 標準リソースプロパティの変更
次に、リソース (resource-1) のシステム定義プロパティ (Start_timeout) を変更する例を示します。
# scrgadm -c -j resource-1 -y start_timeout=30 # scrgadm -pvv -j resource-1 |
例 – 拡張リソースプロパティの変更
次に、リソース (resource-1) の拡張プロパティ (Log_level) を変更する例を示します。
# scrgadm -c -j resource-1 -x Log_level=3 # scrgadm -pvv -j resource-1 |
リソースの STOP_FAILED エラーフラグの消去
Failover_mode リソースプロパティが NONE または SOFT に設定されているときに、リソースの STOP に失敗した場合は、個々のリソースは STOP_FAILED 状態になり、リソースグループは ERROR_STOP_FAILED 状態になります。この状態のリソースグループは、ノード上でオンラインにできません。また、リソースの作成や削除、リソースグループやリソースプロパティの変更などの編集操作を行うこともできません。
リソースの STOP_FAILED エラーフラグの消去
この手順を実行するには、次の情報が必要になります。
-
リソースが STOP_FAILED であるノードの名前
-
STOP_FAILED 状態になっているリソースとリソースグループの名前
詳細は、scswitch(1M) のマニュアルページを参照してください。
注 –
この手順は、任意のクラスタノードから実行します。
-
クラスタメンバー上でスーパーユーザーになります。
-
STOP_FAILED 状態のリソースと、どのノードがこの状態になっているのか確認します。
# scstat -g
-
STOP_FAILED 状態になっているノード上で、リソースとそのモニターを手作業で停止します。
この手順では、プロセスを強制終了するか、リソースタイプ固有のコマンドまたは別のコマンドを実行する必要があります。
-
リソースを手作業で停止したすべてのノード上で、これらのリソースの状態を手作業で OFFLINE に設定します。
# scswitch -c -h nodelist -j resource -f STOP_FAILED
- -c
-
フラグを消去します。
- -h nodelist
-
リソースが実行されていたノード名を指定します。
- -j resource
-
オフラインにするリソースの名前を指定します。
- -f STOP_FAILED
-
フラグ名を指定します。
-
手順 4 で STOP_FAILED フラグを消去したノード上で、リソースグループの状態を調べます。
リソースグループの状態は、OFFLINE または ONLINE になっています。
# scstat -g
コマンド scstat -g は、リソースグループの状態が ERROR_STOP_FAILED のままかどうかを示します。リソースグループがまだ ERROR_STOP_FAILED 状態の場合は、scswitch コマンドを実行し、該当するノード上でリソースグループをオフラインに切り替えます。
# scswitch -F -g resource-group
- -F
-
グループをマスターできるすべてのノード上でリソースグループをオフラインにします。
- -g resource-group
-
オフラインに切り替えるリソースグループの名前を指定します。
この状況は STOP メソッドに失敗し、停止に失敗したリソースがリソースグループ内のほかのノードへの依存性を持っているときに、リソースグループをオフラインに切り替えた場合に発生します。これ以外の状況では、手順 4 のコマンドをすべての STOP_FAILED リソースで実行することによって、リソースグループは自動的に ONLINE または OFFLINE 状態に戻ります。
これで、リソースグループを ONLINE 状態に切り替えることができます。
登録済みのリソースタイプの再登録
あらかじめ登録されているリソースタイプには、SUNW.LogicalHostname と SUNW.SharedAddress があります。すべての論理ホスト名と共有アドレスリソースがこれらのリソースタイプを使用します。これら 2 つのリソースタイプは、誤って削除した場合を除き、登録する必要はありません。誤ってリソースタイプを削除した場合は、次の手順を使用して再登録してください。
詳細は、scrgadm(1M) のマニュアルページを参照してください。
注 –
この手順は、任意のクラスタノードから実行します。
登録済みのリソースタイプの再登録
- -a
-
リソースタイプを追加します。
- -t SUNW.resource-type
-
追加 (再登録) するリソースタイプを指定します。リソースタイプは、SUNW.LogicalHostname または SUNW.SharedAddress のいずれかになります。
リソースタイプを再登録します。
# scrgadm -a -t SUNW.resource-type |
例 – 登録済みのリソースタイプの再登録
次に、SUNW.LogicalHostname リソースタイプを再登録する例を示します。
# scrgadm -a -t SUNW.LogicalHostname |
リソースグループへのノードの追加と削除
この節の手順では、次の作業を行います。
-
リソースグループの追加のマスターとなるクラスタノードの構成
-
リソースグループからのノードの削除
ノードの追加や削除をフェイルオーバーリソースグループに対して行うのか、スケーラブルリソースグループに対して行うのかによって、手順は異なります。
フェイルオーバーリソースグループは、フェイルオーバーとスケーラブルの両方のサービスによって使用されるネットワークリソースを含みます。クラスタに接続される各 IP サブネットワークは、指定された独自のネットワークリソースを持ち、フェイルオーバーリソースグループに含まれます。このネットワークリソースは、論理ホスト名または共有アドレスリソースのいずれかになります。各ネットワークリソースは、それが使用する IP ネットワークマルチパスグループのリストを含んでいます。フェイルオーバーリソースグループの場合は、リソースグループ (netiflist リソースプロパティ) に含まれる各ネットワークリソースに対し IP ネットワークマルチパスグループの完全なリストを更新する必要があります。
スケーラブルリソースグループの場合は、スケーラブルグループがホストの新しいセット上でマスターされるように変更するほかに、スケーラブルリソースによって使用されるネットワークリソースを含むフェイルオーバーグループのための手順も実行する必要があります。
詳細は、scrgadm(1M) のマニュアルページを参照してください。
注 –
任意のクラスタノードから、以下に説明する手順のいずれかを実行します。
リソースグループへのノードの追加
この作業は次のセクションに分かれています。
この手順を実行するには、次の情報が必要になります。
-
すべてのクラスタノードの名前とノード ID
-
ノードが追加されるリソースグループの名前
-
すべてのノード上のリソースグループによって使用されるネットワークリソースをホストする IP ネットワークマルチパスグループの名前
さらに、新しいノードがすでにクラスタメンバーになっていることも確認してください。
スケーラブルリソースグループへのノードの追加
-
リソースグループ内のスケーラブルリソースが使用する各ネットワークリソースごとに、そのネットワークリソースが配置されているリソースグループが新しいノードで実行されるようにします。
-
スケーラブルリソースグループをマスターできるノードのリスト (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 は、sc_ipmp0 などの IP ネットワークマルチパスグループ名として指定できます。ノードは、sc_ipmp@phys-schost-1 や sc_ipmp0@1 などのノード名またはノード ID で識別できます。
-
このリソースグループをマスターできるすべてのノードを含めるように、ノードリストを更新します。
この手順は、nodelist の値を上書きするため、リソースグループをマスターできるすべてのノードをここに含める必要があります。
# scrgadm -c -g resource-group -h nodelist
- -c
-
リソースグループを変更します。
- -g resource-group
-
ノードが追加されるリソースグループの名前を指定します。
- -h nodelist
-
リソースグループをマスターできるノードをコンマで区切って指定します。
-
更新された情報を確認します。
# scrgadm -pvv -g resource-group | grep -i nodelist # scrgadm -pvv -g resource-group | grep -i netiflist
例 – リソースグループへのノードの追加
次に、リソースグループ (resource-group-1) にノード (phys-schost-2) を追加する例を示します。このリソースグループは、論理ホスト名リソース (schost-2) を含んでいます。
# env LC_ALL=C scrgadm -pvv -g resource-group-1 | grep -i nodelist (resource-group-1) Res Group Nodelist: phys-schost-1 phys-schost-3 # env LC_ALL=C scrgadm -pvv -g resource-group-1 | grep -i netiflist (resource-group-1:schost-2) Res property name: NetIfList (resource-group-1:schost-2:NetIfList) Res property class: extension (resource-group-1:schost-2:NetIfList) List of IP ネットワークマルチパスグループ interfaces on each node (resource-group-1:schost-2:NetIfList) Res property type: stringarray (resource-group-1:schost-2:NetIfList) Res property value: sc_ipmp0@1 sc_ipmp0@3 (ノード1と3だけが IP ネットワークマルチパスグループに割り当てられている。ノード 2 を IP ネットワークマルチパスグループに追加する必要がある。) # scrgadm -c -j schost-2 -x netiflist=sc_ipmp0@1,sc_ipmp0@2,sc_ipmp0@3 # scrgadm -c -g resource-group-1 -h phys-schost-1,phys-schost-2,phys-schost-3 # env LC_ALL=C scrgadm -pvv -g resource-group-1 | grep -i nodelist (resource-group-1) Res Group Nodelist: phys-schost-1 phys-schost-2 phys-schost-3 # env LC_ALL=C scrgadm -pvv -g resource-group-1 | grep -i netiflist (resource-group-1:schost-2:NetIfList) Res property value: sc_ipmp0@1 sc_ipmp0@2 sc_ipmp0@3 |
リソースグループからのノードの削除
この作業は次のセクションに分かれています。
これらの手順を実行するには、次の情報が必要になります。
-
すべてのクラスタノードのノード名とノード ID
# env LC_ALL=C scconf -pv | grep "Node ID”
-
ノードを削除予定のリソースグループまたはグループの名前
# env LC_ALL=C scrgadm -pv | grep "Res Group Nodelist”
-
すべてのノード上のリソースグループによって使用されるネットワークリソースをホストする IP ネットワークマルチパスグループの名前
# env LC_ALL=C scrgadm -pvv | grep "NetIfList.*value”
さらに、削除するノード上でリソースグループがマスターされていないことを確認します。削除するノード上でマスターされている場合は、scswitch コマンドを実行し、そのノードでリソースグループをオフラインに切り替えてください。次の scswitch コマンドは、指定されたノードからリソースグループをオフラインにします。この場合、new-masters にこのノードが含まれていてはいけません。
# scswitch -z -g resource-group -h new-masters |
- -g resource-group
-
オフラインに切り替えるリソースグループ (削除するノードでマスターされている) の名前を指定します。
- -h new-masters
-
このリソースグループを現在マスターできるノードを指定します。
詳細は、scswitch(1M) のマニュアルページを参照してください。
注意 – すべてのリソースグループからノードを削除する場合に、スケーラブルサービス構成を使用するときは、最初にスケーラブルリソースグループからそのノードを削除します。続いて、フェイルオーバーグループからそのノードを削除します。
スケーラブルリソースグループからのノードの削除
スケーラブルサービスは、次に示すように 2 つのリソースグループとして構成されます。
-
1 つは、スケーラブルサービスリソースを含むスケーラブルグループです。
-
もう 1 つは、スケーラブルサービスリソースが使用する共有アドレスリソースを含むフェイルオーバーグループです。
スケーラブルリソースグループの RG_dependencies プロパティは、フェイルオーバーリソースグループへの依存性を使用してスケーラブルグループを構成するように設定されます。このプロパティの詳細は、付録 A 「標準プロパティ」を参照してください。
スケーラブルサービス構成の詳細は、『Sun Cluster 3.1 の概念』を参照してください。
スケーラブルリソースグループからノードを削除すると、そのスケーラブルサービスはそのノード上でオンラインにすることができなくなります。スケーラブルリソースグループからノードを削除するには、以下の作業を行なってください。
-
スケーラブルリソースグループをマスターできるノードのリスト (nodelist リソースグループプロパティ) からノードを削除します。
# scrgadm -c -g scalable-resource-group -h nodelist
- -c
-
リソースグループを変更します。
- -g scalable-resource-group
-
ノードが削除されるリソースグループの名前を指定します。
- -h nodelist
-
このリソースグループをマスターできるノードをコンマで区切って指定します。
-
(省略可能) 共有アドレスリソースが入ったフェイルオーバーリソースグループからノードを削除します。
詳細は、共有アドレスリソースを含むフェイルオーバーリソースグループからのノードの削除を参照してください。
-
(省略可能) スケーラブルリソースの Load_balancing_weights プロパティを更新し、リソースグループから削除するノードのウェイトを削除します。
詳細は、scrgadm(1M) のマニュアルページを参照してください。
フェイルオーバーリソースグループからのノードの削除
フェイルオーバーリソースグループからノードを削除するには、以下の作業を行なってください。
注意 – すべてのリソースグループからノードを削除する場合に、スケーラブルサービス構成を使用するときは、最初にスケーラブルリソースグループからそのノードを削除します。続いて、この方法を使用してフェイルオーバーグループからノードを削除します。
注 –
フェイルオーバーリソースグループにスケーラブルサービスが使用する共有アドレスリソースが含まれる場合は、共有アドレスリソースを含むフェイルオーバーリソースグループからのノードの削除を参照してください。
-
このリソースグループをマスターできるすべてのノードを含めるように、ノードリストを更新します。
この手順はノードを削除してノードリストの値を上書きするため、リソースグループをマスターできるすべてのノードをここに含める必要があります。
# scrgadm -c -g failover-resource-group -h nodelist
- -c
-
リソースグループを変更します。
- -g failover-resource-group
-
ノードが削除されるリソースグループの名前を指定します。
- -h nodelist
-
このリソースグループをマスターできるノードをコンマで区切って指定します。
-
リソースグループ内の各リソース用に構成した IP ネットワークマルチパスグループの現在のリストを表示します。
# scrgadm -pvv -g failover-resource-group | grep -i netiflist
-
ノードの削除によって影響を受けるネットワークリソースの netiflist を更新します。
この手順は netiflist の値を上書きするため、すべての IP ネットワークマルチパスグループをここに含める必要があります。
# scrgadm -c -j network-resource -x netiflist=netiflist
注 –上記コマンド行の出力は、ノード名でノードを識別します。ノード ID を検索するには、コマンド scconf -pv | grep “Node ID” を実行してください。
- -c
-
ネットワークリソースを変更します。
- -j network-resource
-
netiflist エントリ上でホストされているネットワークリソースの名前を指定します。
- -x netiflist=netiflist
-
各ノード上の IP ネットワークマルチパスグループをコンマで区切って指定します。netiflist 内の各要素の書式は、 netif@node でなければなりません。 netif は、sc_ipmp0 などの IP ネットワークマルチパスグループ名として指定できます。ノードは、sc_ipmp@phys-schost-1 や sc_ipmp0@1 などのノード名またはノード ID で識別できます。
注 –現在 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) を含んでいます。
# env LC_ALL=C scrgadm -pvv -g resource-group-1 | grep -i nodelist (resource-group-1) Res Group Nodelist: phys-schost-1 phys-schost-2 phys-schost-3 # scrgadm -c -g resource-group-1 -h phys-schost-1,phys-schost-2 # env LC_ALL=C scrgadm -pvv -g resource-group-1 | grep -i netiflist (resource-group-1:schost-1) Res property name: NetIfList (resource-group-1:schost-1:NetIfList) Res property class: extension (resource-group-1:schost-1:NetIfList) List of IP ネットワークマルチパスグループ interfaces on each node (resource-group-1:schost-1:NetIfList) Res property type: stringarray (resource-group-1:schost-1:NetIfList) Res property value: sc_ipmp0@1 sc_ipmp0@2 sc_ipmp0@3 (sc_ipmp0@3 は、削除対象となる IP ネットワークマルチパスグループです。 ) # env LC_ALL=C scrgadm -c -j schost-1 -x netiflist=sc_ipmp0@1,sc_ipmp0@2 # scrgadm -pvv -g resource-group-1 | grep -i nodelist (resource-group-1) Res Group Nodelist: phys-schost-1 phys-schost-2 # env LC_ALL=C scrgadm -pvv -g resource-group-1 | grep -i netiflist (resource-group-1:schost-1:NetIfList) Res property value: sc_ipmp0@1 sc_ipmp0@2 |
リソースグループとディスクデバイスグループ間での起動の同期
クラスタが起動した後、あるいは、サービスが別のノードにフェイルオーバーした後、グローバルデバイスとクラスタファイルシステムが利用できるようになるまでには、しばらく時間がかかることがあります。しかし、データサービスは、データサービスが依存する広域デバイスとクラスタファイルシステムがオンラインになる前に、START メソッドを実行できます。この場合、START メソッドがタイムアウトになるため、データサービスによって使用されるリソースグループの状態をリセットし、手動でデータサービスを再起動する必要があります。リソースタイプ HAStorage と HAStoragePlus は、広域デバイスとクラスタファイルシステムを監視し、利用可能になるまで、同じリソースグループ内のほかのリソースの START メソッドを待機させます(作成するリソースタイプを判断するには、HAStorage または HAStoragePlusの選択を参照してください)。 このような追加の管理作業を軽減するには、広域デバイスやクラスタファイルシステムに依存するデータサービスリソースを持つすべてのリソースグループに、HAStorage または HAStoragePlus を設定してください。
HAStorage リソースタイプを作成する方法については、新しいリソース用の HAStorage リソースタイプの設定を参照してください。
HAStoragePlus リソースタイプを作成する方法については、HAStoragePlus リソースタイプの設定を参照してください。
新しいリソース用の HAStorage リソースタイプの設定
次の例では、リソースグループ resource-group-1 は、次の 3 つのデータサービスを含んでいます。
-
Sun ONE Web Server (/global/resource-group-1 に依存)
-
Oracle (/dev/global/dsk/d5s2 に依存)
-
NFS (dsk/d6 に依存)
新しいリソース用に HAStorage リソースの hastorage-1 を resource-group-1 に作成するには、リソースグループとディスクデバイスグループ間での起動の同期を読んでから、次の手順を実行します。
HAStoragePlus リソースタイプを作成する方法については、高可用性ローカルファイルシステムの有効化を参照してください。
-
クラスタメンバー上でスーパーユーザーになります。
-
リソースグループ resource-group-1 を作成します。
# scrgadm -a -g resource-group-1
-
リソースタイプが登録されているかどうかを調べます。
次のコマンドは、登録されているリソースタイプのリストを出力します。
# scrgadm -p | egrep Type
-
必要であれば、リソースタイプを登録します。
# scrgadm -a -t SUNW.HAStorage
-
HAStorage リソースの hastorage-1 を作成し、サービスパスを定義します。
# scrgadm -a -j hastorage-1 -g resource-group-1 -t SUNW.HAStorage \ -x ServicePaths=/global/resource-group-1,/dev/global/dsk/d5s2,dsk/d6
ServicePaths には、次の値を含めることができます。
-
広域デバイスグループ名 (例:nfs-dg)
-
広域デバイスへのパス (例:/dev/global/dsk/d5s2 または dev/d6)
-
クラスタファイルシステムのマウントポイント (例:/global/nfs)
注 –ServicePaths にクラスタファイルシステムパスが含まれる場合、広域デバイスグループはそれらに対応するリソースグループと共に使用されるとは限りません。
-
-
hastorage-1 リソースを有効にします。
# scswitch -e -j hastorage-1
-
リソース Sun ONE Web Server、Oracle、NFS を resource-group-1 に追加し、これらの依存性を hastorage-1 に設定します。
たとえば、Sun ONE Web Server の場合には、次のコマンドを実行します。
# scrgadm -a -j resource -g resource-group-1 -t SUNW.iws \ -x Confdir_list=/global/iws/schost-1 -y Scalable=False \ -y Network_resources_used=schost-1 -y Port_list=80/tcp \ -y Resource_dependencies=hastorage-1
-
リソースの依存性を正しく構成したかを確認します。
# scrgadm -pvv -j resource | egrep strong
-
resource-group-1 を MANAGED 状態に設定し、resource-group-1 をオンラインにします。
# scswitch -Z -g resource-group-1
HAStorage リソースタイプは、別の拡張プロパティ (AffinityOn) を含みます。この拡張プロパティは、HAStorage が ServicePaths で定義されている広域デバイスおよびクラスタファイルシステムの類似性スイッチオーバーを実行する必要があるかどうかを指定するブール値です。詳細は、SUNW.HAStorage(5) のマニュアルページを参照してください。
注 –
リソースグループがスケーラブルの場合、HAStorage と HAStoragePlus は AffinityOn が TRUE に設定されることを許可しません。スケーラブルリソースグループの場合、HAStorage と HAStoragePlus は、AffinityOn 値を確認し、この値を内部で FALSE に設定し直します。
既存のリソース用の HAStorage リソースタイプの設定
既存のリソースのために HAStorage リソースを作成するには、リソースグループとディスクデバイスグループ間での起動の同期を読んでから、次の手順を実行します。
-
リソースタイプが登録されているかどうかを調べます。
次のコマンドは、登録されているリソースタイプのリストを出力します。
# scrgadm -p | egrep Type
-
必要であれば、リソースタイプを登録します。
# scrgadm -a -t SUNW.HAStorage
-
HAStorage リソースの hastorage-1 を作成します。
# scrgadm -a -g resource-group -j hastorage-1 -t SUNW.HAStorage \ -x ServicePaths= … -x AffinityOn=True
-
hastorage-1 リソースを有効にします。
# scswitch -e -j hastorage-1
-
必要に応じて既存の各リソースについて依存性を設定します。
# scrgadm -c -j resource -y Resource_Dependencies=hastorage-1
-
リソースの依存性を正しく構成したかを確認します。
# scrgadm -pvv -j resource | egrep strong
高可用性ローカルファイルシステムの有効化
HAStoragePlus リソースタイプを使用すると、ローカルファイルシステムを Sun Cluster 環境内で高可用性にすることができます。このためには、ローカルファイルシステムのパーティションが広域ディスクグループに存在し、アフィニティスイッチオーバーが有効であり、Sun Cluster 環境がフェイルオーバー用に構成されている必要があります。これによって、多重ホストディスクに直接接続された任意のホストから、多重ホストディスク上の任意のファイルシステムにアクセスできるようになります(ルートファイルシステムを高可用性にするために HAStoragePlus を使用することはできません)。フェイルバック設定は、リソースグループとデバイスグループの両方で同一でなければなりません。
I/O に負荷のかかる一部のデータサービスに対しては、高可用性ローカルファイルシステムの使用を推奨します。HAStoragePlus リソースタイプを構成するための手順は、このようなデータサービスの「登録と構成手順」に追加されています。このようなデータサービス用に HAStoragePlus リソースタイプを設定する手順については、以下の節を参照してください。
その他のデータサービスの HAStoragePlus リソースタイプを設定する手順については、HAStoragePlus リソースタイプの設定を参照してください。
HAStoragePlus リソースタイプの設定
HAStoragePlus リソースタイプは Sun Cluster 3.0 5/02 から導入されています。この新しいリソースタイプは HAStorage と同じ機能を実行し、リソースグループとディスクデバイスグループ間で起動の同期をとります。HAStoragePlus リソースタイプには、ローカルファイルシステムを高可用性にするための機能が追加されています(ローカルファイルシステムを高可用性にするための説明については、高可用性ローカルファイルシステムの有効化を参照してください)。これらの機能を両方とも使用するには HAStoragePlus リソースタイプを設定します。
HAStoragePlus を設定するには、ローカルファイルシステムのパーティションが広域ディスクグループに存在し、アフィニティスイッチオーバーが有効であり、Sun Cluster 環境がフェイルオーバー用に構成されている必要があります。
次の例では、簡単な NFS サービスを使用して、ローカルにマウントされたディレクトリ /global/local-fs/nfs/export/ home からホームディレクトリのデータを共有します。この例では、次の条件を前提にしています。
-
マウントポイント /global/local-fs/nfs は、UFS ローカルファイルシステムを Sun Cluster 広域デバイスのパーティションにマウントするために使用されます。
-
/etc/vfstab ファイルシステムの /global/local-fs/nfs エントリには、このファイルシステムがローカルファイルシステムで、マウントブートフラグが「no」であるよう指定されている必要があります。
-
PathPrefix ディレクトリ (HA-NFS が管理情報と状態情報を保守するために使用するディレクトリ) は、マウントするファイルシステムのルートディレクトリ (たとえば、/global/local-fs/nfs) 上に存在します。
-
クラスタメンバー上でスーパーユーザーになります。
-
リソースタイプが登録されているかどうかを調べます。
次のコマンドは、登録されているリソースタイプのリストを出力します。
# scrgadm -p | egrep Type
-
必要であれば、リソースタイプを登録します。
# scrgadm -a -t SUNW.nfs
-
フェイルオーバーリソースグループ nfs-r を作成します。
# scrgadm -a -g nfs-rg -y PathPrefix=/global/local-fs/nfs
-
タイプ SUNW.LogicalHostname の論理ホストリソースを作成します。
# scrgadm -a -j nfs-lh-rs -g nfs-rg -L -l log-nfs
-
HAStoragePlus リソースタイプをクラスタに登録します。
# scrgadm -a -t SUNW.HAStoragePlus
-
タイプ HAStoragePlus のリソース nfs-hastp-rs を作成します。
# scrgadm -a -j nfs-hastp-rs -g nfs-rg -t SUNW.HAStoragePlus\ -x FilesystemMountPoints=/global/local-fs/nfs \ -x AffinityOn=TRUE
注 –FilesystemMountPoints 拡張プロパティは、1 つまたは複数のファイルシステムのマウントポイントのリストを指定するために使用できます。このリストは、ローカルおよび広域の両ファイルシステムのマウントポイントで構成できます。
-
リソースグループ nfs-rg をクラスタノード上でオンラインにします。
このノードは、 /global/local-fs/nfs ファイルシステムの実際の広域デバイスのパーティション用の主ノードになります。次に、ファイルシステム /global/local-fs/nfs は当該ノード上にローカルにマウントされます。
# scswitch -Z -g nfs-rg
-
SUNW.nfs リソースタイプをクラスタに登録します。タイプ SUNW.nfs のリソース nfs-rs を作成して、リソース nfs-hastp-rs へのリソース依存関係を指定します。
dfstab.nfs-rs が /global/local-fs/nfs/SUNW.nfs に作成されます。
# scrgadm -a -t SUNW.nfs # scrgadm -a -g nfs-rg -j nfs-rs -t SUNW.nfs \ -y Resource_dependencies=nfs-hastp-rs
注 –nfs リソースに依存関係を設定するには、nfs-hastp-rs リソースがオンラインである必要があります。
-
nfs-rs をオンラインにします。
# scswitch -Z -g nfs-rg
注意 – 切り替えは、リソースグループレベルのときに行うよう注意してください。デバイスグループレベルで切り替えを行うと、リソースグループが混乱しフェイルオーバーが発生します。
これで、サービスを新しいノードに移行するときには常に、/global/local-fs/nfs 用のプライマリ入出力パスはオンラインになり、NFS サーバーに配置されます。ファイルシステム /global/local-fs/nfs は NFS サーバーが起動する前にローカルにマウントされます。
重要ではないリソースグループを取り外すことによるノードリソースの解放
Prioritized Service Management (RGOffload) を使用すると、重要なデータサービスのためにノードのリソースを自動的に解放できます。RGOffload は、重要なフェイルオーバーデータサービスを起動するために、重要でないスケーラブルデータサービスまたはフェイルオーバーデータサービスをオフラインにする必要がある場合に使用します。また、RGOffload は、重要でないデータサービスを含むリソースグループを取り外す場合にも使用します。
注 –
重要なデータサービスはフェイルオーバー可能でなければなりません。取り外されるデータサービスは、フェイルオーバーデータサービスでもスケーラブルデータサービスでもかまいません。
RGOffload リソースの設定
-
クラスタメンバー上でスーパーユーザーになります。
-
RGOffload リソースタイプが登録されているかどうかを調べます。
次のコマンドは、リソースタイプのリストを出力します。
# scrgadm -p|egrep SUNW.RGOffload
-
必要であれば、リソースタイプを登録します。
を参照してください。
# scrgadm -a -t SUNW.RGOffload
-
RGOffload リソースで取り外すリソースグループごとに、Desired_primaries をゼロに設定します。
# scrgadm -c -g offload-rg -y Desired_primaries=0
-
RGOffload リソースを重要なフェイルオーバーリソースグループに追加して、拡張プロパティを設定します。
リソースグループを複数のリソースの rg_to_offload リストに追加してはいけません。リソースグループを複数の rg_to_offload リストに追加すると、リソースグループはオフラインになった後にオンラインになるという動作を繰り返すことになります。
拡張プロパティについては、RGOffload 拡張プロパティの構成を参照してください。
# scrgadm -aj rgoffload-resource\ -t SUNW.RGOffload -g critical-rg \ -x rg_to_offload=offload-rg-1, offload-rg-2, ...\ -x continue_to_offload=TRUE \ -x max_offload_retry=15
注 –この場合、rg_to_offload 以外の拡張プロパティはデフォルト値で表示されます。rg_to_offload は、お互いに依存しないリソースグループをコンマで区切ったリストです。このリストには、RGOffload リソースを追加するリソースグループが含まれていてはいけません。
-
RGOffload リソースを有効にします。
# scswitch -ej rgoffload-resource
-
重要なフェイルオーバーリソースから RGOffload への依存関係を設定します。
# scrgadm -c -j critical-resource \ -y Resource_dependencies=rgoffload-resource
Resource_dependencies_weak も使用できます。Resource_dependencies_weak を RGOffload リソースタイプに使用すると、offload-rg の取り外し中にエラーが発生しても、重要なフェイルオーバーリソースを起動できます。
-
リソースグループを、取り外し可能なオンライン状態にします。
# scswitch -z -g offload-rg, offload-rg-2, ... -h [nodelist]
リソースグループは、重要なリソースグループがオフラインであるすべてのノード上でオンラインのままになります。障害モニターは、重要なリソースグループがオンラインであるノード上でリソースグループが動作しないようにします。
取り外されるリソースグループの Desired_primaries はゼロに設定されているので (手順 4を参照)、“-Z” オプションを指定しても、このようなリソースグループはオンラインになりません。
-
重要なフェイルオーバーリソースグループがオンラインでない場合、オンラインにします。
# scswitch -Z -g critical-rg
例 – RGOffload リソースの構成
この例では、RGOffload リソース (rgofl)、RGOffload リソースを含む重要なリソースグループ (oracle_rg)、および重要なリソースグループがオンラインになったときに取り外されるスケーラブルリソースグループ (IWS-SC, IWS-SC-2) を構成する方法について説明します。この例では、重要なリソースは oracle-server-rs です。
この例では、oracle_rg、IWS-SC、および IWS-SC-2 はクラスタ "triped" の任意のノード、つまり、phys-triped-1、phys-triped-2、phys-triped-3 上でマスターできます。
[SUNW.RGOffload リソースタイプが登録されているかどうかを判断する] # scrgadm -p|egrep SUNW.RGOffload [必要に応じて、リソースタイプを登録する] # scrgadm -a -t SUNW.RGOffload [RGOffload によって取り外される各リソースグループで、Desired_primaries をゼロに設定する] |
RGOffload 拡張プロパティの構成
通常、拡張プロパティは RGOffload リソースを作成するときに、コマンド行から scrgadm -x parameter=value を実行して構成します。Sun Cluster の全標準プロパティについては、付録 A 「標準プロパティ」 を参照してください。
表 15–2に RGOffload に構成できる拡張プロパティを示します。 「調整」エントリは、いつプロパティを更新できるかを示します。
表 15–2 RGOffload 拡張プロパティ|
名前/データタイプ |
デフォルト |
|---|---|
|
rg_to_offload (文字列) |
重要なフェイルオーバーリソースグループがノード上で起動するときに、当該ノード上で取り外す必要があるリソースグループをコンマで区切ったリスト。このリストには、お互いに依存するリソースグループが含まれてはいけません。このプロパティにはデフォルト設定値がないので、必ず設定する必要があります。
RGOffload は、rg_to_offload 拡張プロパティに設定されたリソースグループのリストにおける依存関係ループを検査しません。たとえば、リソースグループ RG-B が RG-A に依存する場合、RG-A と RG-B は両方とも rg_to_offload に含まれてはいけません。
デフォルト:なし 調整: 任意の時点 |
|
continue_to_offload (ブール型) |
リソースグループの取り外し中にエラーが発生した後に、rg_to_offload リスト内の残りのリソースグループの取り外し続けるかどうかを示すブール型。
このプロパティは START メソッドだけが使用します。
デフォルト:True 調整: 任意の時点 |
|
max_offload_retry (整数) |
クラスタまたはリソースグループの再構成による障害時の起動中に、リソースグループの取り外しを試みる回数。再試行の間には 10 秒の間隔があります。
(取り外されるリソースグループの数 * max_offload_retry * 10 秒)
の値が RGOffload の Start_timeout の値より少なくなるように
max_offload_retry を設定します。この値が Start_timeout の値に近い (あるいは、より大きい) 場合、最大再試行数に到達する前に、RGOffload リソースの START メソッドがタイムアウトする可能性があります。
このプロパティは START メソッドだけが使用します。
デフォルト:15 調整: 任意の時点 |
障害モニター
RGOffload リソースの障害モニター検証は、重要なリソースをマスターするノード上で、rg_to_offload 拡張プロパティに指定されたリソースグループをオフラインにし続けるために使用されます。各検証サイクルで障害モニターは、重要なリソースをマスターするノード上で、取り外すリソースグループ (offload-rg) がオフラインであることを確認します。重要なリソースをマスターするノード上で offload-rg がオンラインである場合、障害モニターは重要なリソースをマスターするノード以外のノード上で offload-rg を起動し、同時に、重要なリソースをマスターするノード上では offload-rg をオフラインにしようとします。
offload-rg の desired_primaries はゼロに設定されているので、この後で利用可能になったノード上では、取り外すリソースグループは再起動されません。したがって、 RGOffload 障害モニターは maximum_primaries に到達するまで、重要なリソースをマスターするノード上では offload-rg をオフラインにしながら、可能な限りのプライマリ上で offload-rg を起動しようとします。
RGOffload は、取り外されたリソースグループが MAINTENANCE または UNMANAGED 状態でない限り、取り外されたすべてのリソースグループを起動しようとします。リソースグループを UNMANAGED 状態にするには、scswitch コマンドを使用します。
# scswitch -u -g resourcegroup |
障害モニター検証サイクルは、Thorough_probe_interval が実行された後に毎回呼び出されます。
- © 2010, Oracle Corporation and/or its affiliates