test

Sun Cluster 3.1 10/03 の概念

データサービスプロジェクトの構成

RGM を使ってデータサービスをオンラインにするときに、これを特定の Solaris プロジェクト名の下で起動することができます。そのためには、データサービスを構成するときに、RGM によって管理されるリソースまたはリソースグループと Solaris プロジェクト ID を対応付ける必要があります。リソースまたはリソースグループとプロジェクト ID を対応付けることによって、ユーザーは、Solaris 環境で提供される高度なコントロールを使ってクラスタ内の負荷や使用量を管理できるようになります。

注 –

この構成を行うためには、Sun Cluster ソフトウェアの最新リリースと Solaris 9 が必要です。

ノードを他のアプリケーションと共有している場合には、クラスタ環境で Solaris 管理機能を使用することによって、最も重要なアプリケーションに高い優先度を与えることができます。ノードを複数のアプリケーションで共有する例としては、サービスを統合した場合や、アプリケーションのフェイルオーバーが起った場合があります。ここで述べる管理機能を使用すれば、優先度の低いアプリケーションが CPU 時間などのシステムサプライを過度に使用するのを防止し、重要なアプリケーションの性能を高めることができます。

注 –

この機能に関連する Solaris のマニュアルでは、CPU 時間、プロセス、タスクや、これに類するコンポーネントを「リソース」と呼んでいます。一方、Sun Cluster のマニュアルでは、RGM の制御下にあるエンティティを「リソース」と呼んでいます。ここでは、RGM の制御下にある Sun Cluster エンティティを「リソース」と呼び、CPU 時間やプロセス、タスクなどを「サプライ」と呼びます。

以下の説明は、プロセスを指定した Solaris 9 の project(4) で起動するようにデータサービスを構成する方法を概念的に述べたものです。さらに、以下の説明では、Solaris 環境の管理機能を使用するために必要なフェイルオーバーのシナリオやヒントについて述べます。管理機能の概念や手順については、『Solaris 9 System Administrator Collection.』の『Solaris のシステム管理 (資源管理とネットワークサービス)』を参照してください。

クラスタ内で Solaris 管理機能を使用できるようにリソースやリソースグループを構成するための手順は次のようになります。

  1. アプリケーションをリソースの一部として構成します。

  2. リソースをリソースグループの一部として構成します。

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

  4. リソースグループを管理可能にします。

  5. リソースグループに対する Solaris プロジェクトを作成します。

  6. ステップ 5 で作成したプロジェクトとリソースグループ名を対応付けるために標準プロパティを構成します。

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

標準の Resource_project_name または RG_project_name プロパティを使って Solaris プロジェクト ID とリソースまたはリソースグループを対応付ける場合には、scrgadm(1M) コマンドに -y オプションを指定する必要があります。続いて、プロパティの値にリソースまたはリソースグループを設定します。プロパティの定義については、『 Sun Cluster 3.1 データサービスのインストールと構』の「標準プロパティ」を参照してください。 プロパティの説明については、 r_properties(5) と rg_properties(5) を参照してください。

指定するプロジェクト名はプロジェクトデータベース (/etc/project) に存在するものでなければなりません。さらに、指定するプロジェクトのメンバーとして root ユーザーが設定されていなければなりません。プロジェクト名データベースの概要については、『Solaris 9 System Administrator Collection』の『 Solaris のシステム管理 (資源管理とネットワークサービス)』の「プロジェクトとタスク」を参照してください。プロジェクトファイルの構文については、project(4) を参照してください。

RGM は、リソースまたはリソースグループをオンラインにする際に、関連するプロセスをこのプロジェクト名の下で起動します。

注 –

リソースまたはリソースグループとプロジェクトを対応付けることはいつでもできます。ただし、新しいプロジェクト名を有効にするためには、RGM を使ってプロジェクトのリソースやリソースグループをオフラインにしてから再びオンラインに戻す必要があります。

リソースやリソースグループをプロジェクト名の下で起動すれば、次の機能を構成することによってクラスタ全体のシステムサプライを管理できます。

プロジェクト構成に応じた要件の決定

Sun Cluster 環境で Solaris での制御を使用してデータサービスを構成する場合は、スイッチオーバーやフェイルオーバーの際にリソースの制御や管理をどのように行うかを決める必要があります。まず、新しいプロジェクトを構成する前にクラスタ内の依存関係を明確にします。たとえば、リソースやリソースグループはディスクデバイスグループに依存しています。次に、scrgadm(1M) で設定された nodelist、 failback、maximum_primaries、desired_primaries リソースグループプロパティを使って、使用するリソースグループのノードリスト優先度を確認します。リソースグループとディスクデバイスグループの間におけるノードリスト依存関係の簡単な説明については、『 Sun Cluster 3.1 データサービスのインストールと構』の「リソースグループとディスクデバイスグループの関連性」を参照してください。プロパティの詳しい説明については、rg_properties(5) のマニュアルページを参照してください。

scrgadm(1M) や scsetup(1M) で構成された preferenced および failback プロパティを使って、ディスクデバイスグループのノードリスト優先度を判別します。この手順については、『 Sun Cluster 3.1 10/03 のシステム管理』の「ディスクデバイスグループの管理」の「ディスクデバイスのプロパティを変更する」を参照してください。ノード構成の概念やフェイルオーバーおよびスケーラブルデータサービスの動作については、SunPlex システムハードウェアコンポーネントを参照してください。

すべてのクラスタノードを同じように構成すると、主ノードと二次ノードに対して同じ使用限度が割り当てられます。 各プロジェクトの構成パラメータは、すべてのノードの構成ファイルに定義されているすべてのアプリケーションに対して同じである必要はありません。特定のアプリケーションに対応するすべてのプロジェクトは、少なくとも、そのアプリケーションのすべての潜在的マスターにあるプロジェクトデータベースからアクセス可能でなければなりません。たとえば、アプリケーション 1 は phys-schost-1 によってマスターされているが、phys-schost-2 や phys-schost-3 にスイッチオーバーまたはフェイルオーバーされる可能性があるとします。アプリケーション 1 に対応付けられたプロジェクトは、これら 3 つのノード (phys-schost-1、phys-schost-2、phys-schost-3) 上でアクセス可能でなければなりません。

注 –

プロジェクトデータベース情報は、ローカルの /etc/project データベースファイルに格納することも、NIS マップや LDAP ディレクトリサーバー に格納することもできます。

Solaris 環境では、使用パラメータの柔軟な構成が可能です。Sun Cluster によって課せられる制約はほとんどありません。 どのような構成を選択するかはサイトの必要性によって異なります。システムの構成を始める前に、次の各項の一般的な指針を参考にしてください。

プロセス当たりの仮想メモリー制限の設定

仮想メモリーの制限をプロセス単位で制御する場合は、process.max-address-space コントロールを使用します。process.max-address-space 値の設定方法については、rctladm(1M) のマニュアルページを参照してください。

Sun Cluster で制御機能を使用する場合は、アプリケーションの不要なフェイルオーバーが発生したり、アプリケーションの「ピンポン」現象が発生するのを防止するためにメモリー制限を適切に設定する必要があります。そのためには、一般に次の点に注意する必要があります。

フェイルオーバーシナリオ

管理パラメータを適切に構成すれば、プロジェクト構成 (/etc/project) 内の割り当ては、通常のクラスタ操作でも、スイッチオーバーやフェイルオーバーの状況でも正常に機能します。

以下の各項ではシナリオ例を説明します。

クラスタ環境では、アプリケーションはリソースの一部として構成され、リソースはリソースグループ (RG) の一部として構成されます。障害が発生すると、対応付けられたアプリケーションと共にリソースグループが別のノードにフェイルオーバーされます。以下の例では、リソースは明示的に示されていません。各リソースには、1 つのアプリケーションが構成されているものとします。

注 –

フェイルオーバーは、RGM に設定されているノードリスト内の優先順位に従って行われます。

以下の例は次のように構成されています。

フェイルオーバーが起こると、各アプリケーションに割り当てられる CPU 時間の割合が変化します。ただし、割り当てられているシェアの数はそのままです。この割合は、そのノードで動作しているアプリケーションの数と、アクティブな各アプリケーションに割り当てられているシェアの数によって異なります。

これらのシナリオでは、次のように構成が行われているものとします。

2 つのアプリケーションを供う 2 ノードクラスタ

2 ノードクラスタに 2 つのアプリケーションを構成することによって、それぞれの物理ホスト (phys-schost-1、 phys-schost-2) を 1 つのアプリケーションのデフォルトマスターにすることができます。一方の物理ホストは、他方の物理ホストの二次ノードになります。アプリケーション 1 とアプリケーション 2 に関連付けられているすべてのプロジェクトは、両ノードのプロジェクトデータベースファイルに存在していなければなりません。クラスタが正常に動作している間、各アプリケーションはそれぞれのデフォルトマスターで動作し、管理機能によってすべての CPU 時間を割り当てられます。

フェイルオーバーかスイッチオーバーが起ると、これらのアプリケーションは同じノードで動作し、構成ファイルの設定に従ってシェアを割り当てられます。たとえば、 /etc/project ファイルに次のエントリが指定されていると、アプリケーション 1 に 4 シェアが、アプリケーション 2 に 1 シェアがそれぞれ割り当てられます。 

Prj_1:100:project for App-1:root::project.cpu-shares=(privileged,4,none)
Prj_2:101:project for App-2:root::project.cpu-shares=(privileged,1,none)

次の図は、この構成の正常時の動作とフェイルオーバー時の動作を表しています。割り当てられているシェアの数は変わりません。ただし、各アプリケーションに与えられる CPU 時間の割合は、CPU 時間を要求する各プロセスに割り当てられているシェア数によって異なります。

図の説明はこの図のすぐ前にあります。

3 つのアプリケーションを供う 2 ノードクラスタ

3 つのアプリケーションが動作する 2 ノードクラスタでは、1 つの物理ホスト (phys-schost-1) を 1 つのアプリケーションのデフォルトマスターとして構成し、もう 1 つの物理ホスト (phys-schost-2) を他の 2 つのアプリケーションのデフォルトマスターとして構成できます。各ノードには、次のサンプルプロジェクトデータベースファイルがあるものとします。フェイルオーバーやスイッチオーバーが起っても、プロジェクトデータベースファイルが変更されることはありません。 

Prj_1:103:project for App-1:root::project.cpu-shares=(privileged,5,none)
Prj_2:104:project for App_2:root::project.cpu-shares=(privileged,3,none) 
Prj_3:105:project for App_3:root::project.cpu-shares=(privileged,2,none)

クラスタが正常に動作している間、アプリケーション 1 には、そのデフォルトマスター phys-schost-1 で 5 シェアが割り当てられます。このノードで CPU 時間を要求するアプリケーションはこのアプリケーションだけであるため、この数は 100 パーセントの CPU 時間と同じことです。アプリケーション 2 と 3 には、それぞれのデフォルトマスターである phys-schost-2 で 3 シェアと 2 シェアが割り当てられます。したがって、正常な動作では、アプリケーション 2 に CPU 時間の 60 パーセントが、アプリケーション 3 に CPU 時間の 40 パーセントがそれぞれ割り当てられます。

フェイルオーバーかスイッチオーバーが起り、アプリケーション 1 が phys-schost-2 に切り替えられても、3 つのアプリケーションの各シェアは変わりません。ただし、割り当てられる CPU リソースの割合はプロジェクトデータベースファイルに従って変更されます。

次の図は、この構成の正常な動作とフェイルオーバー動作を示しています。

図の説明はこの図のすぐ前にあります。

リソースグループだけのフェイルオーバー

複数のリソースグループが同じデフォルトマスターに属している構成では、1 つのリソースグループ (および、それに関連付けられたアプリケーション) が 二次ノードにフェイルオーバーされたり、スイッチオーバーされることがあります。その間、クラスタのデフォルトマスターは動作を続けます。

注 –

フェイルオーバーの際、フェイルオーバーされるアプリケーションには、二次ノード上の構成ファイルの指定に従ってリソースが割り当てられます。この例の場合、主ノードと二次ノードのプロジェクトデータベースファイルの構成は同じです。

次のサンプル構成ファイルでは、アプリケーション 1 に 1 シェア、アプリケーション 2 に 2 シェア、アプリケーション 3 に 2 シェアがそれぞれ割り当てられています。 

Prj_1:106:project for App_1:root::project.cpu-shares=(privileged,1,none)
Prj_2:107:project for App_2:root::project.cpu-shares=(privileged,2,none)
Prj_3:108:project for App_3:root::project.cpu-shares=(privileged,2,none)

以下の図は、この構成の正常時の動作とフェイルオーバー時の動作を表しています。ここでは、アプリケーション 2 が動作する RG-2 が phys-schost-2 にフェイルオーバーされます。割り当てられているシェアの数は変わりません。ただし、各アプリケーションに与えられる CPU 時間の割合は、CPU 時間を要求する各アプリケーションに割り当てられているシェア数によって異なります。

図の説明はこの図のすぐ前にあります。