test

Sun Cluster の概念 (Solaris OS 版)

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

データサービスは、RGM でオンラインにしたときに Solaris プロジェクト名のもとで起動するように構成できます。そのためには、データサービスを構成するときに、RGM によって管理されるリソースまたはリソースグループと Solaris プロジェクト ID を対応付ける必要があります。リソースまたはリソースグループにプロジェクト ID を対応付けることによって、Solaris オペレーティングシステムの洗練されたコントロールを使用して、クラスタ内の負荷や使用量を管理できます。

注 –

Solaris 9 OS または Solaris 10 OS 上で Sun Cluster を使用する場合、この構成を実行できます。

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

注 –

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

この節では、指定した Solaris OS の project(4) でプロセスを起動するように、データサービスを構成する方法の概念について説明します。また、Solaris オペレーティングシステムの管理機能を使用するための、フェイルオーバーのシナリオやヒントについても説明します。

管理機能の概念や手順についての詳細は、『System Administration Guide: Network Services』の第 1 章「Network Service (Overview)」を参照してください。

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

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

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

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

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

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

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

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

Solaris プロジェクト ID をリソースやリソースグループに関連付けるように標準の Resource_project_name または RG_project_name プロパティーを構成するには、clresource set および clresourcegroup set コマンドとともに -p オプションを使用します。続いて、プロパティーの値にリソースまたはリソースグループを設定します。プロパティーの定義については、『Sun Cluster データサービスの計画と管理 (Solaris OS 版)』の付録 B「標準プロパティー」を参照してください。プロパティーの説明については、r_properties(5) および rg_properties(5) のマニュアルページを参照してください。

指定するプロジェクト名はプロジェクトデータベース (/etc/project) に存在するものでなければなりません。さらに、指定するプロジェクトのメンバーとして root ユーザーが設定されていなければなりません。プロジェクト名データベースの概念については、『System Administration Guide: Solaris Containers-Resource Management and Solaris Zones』の第 2 章「Projects and Tasks (Overview)」を参照してください。プロジェクトファイルの構文については、project(4) を参照してください。

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

注 –

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

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

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

Sun Cluster 環境で Solaris が提供する制御を使用するようにデータサービスを構成するには、まず、スイッチオーバーやフェイルオーバー時にリソースをどのように制御および管理するかを決めておく必要があります。新しいプロジェクトを構成する前に、まず、クラスタ内の依存関係を明確にします。たとえば、リソースやリソースグループはデバイスグループに依存しています。

リソースグループのノードリストの優先順位を識別するには、clresourcegroup set コマンドで構成する nodelist、failback、maximum_primaries および desired_primaries リソースグループのプロパティーを使用します。

デバイスグループのノードリストの優先順位を決めるには、cldevicegroup および clsetup コマンドで構成する preferenced プロパティーおよび failback プロパティーを使用します。詳細は、clresourcegroup(1CL)、cldevicegroup(1CL)、および clsetup(1CL) のマニュアルページを参照してください。

すべてのクラスタノードまたはゾーンを同じように構成すると、主ノードと二次ノードに対して同じ使用限度が割り当てられます。各プロジェクトの構成パラメータは、すべてのノードの構成ファイルに定義されているすべてのアプリケーションに対して同じである必要はありません。特定のアプリケーションに対応するすべてのプロジェクトは、少な くとも、そのアプリケーションのすべての潜在的マスターにあるプロジェクトデータベースからアクセス可能である必要があります。アプリケーション 1 が phys-schost-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) 内の割り当ては、通常のクラスタ操作でも、スイッチオーバーやフェイルオーバーの状況でも正常に機能します。

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

Sun Cluster 環境では、アプリケーションはリソースの一部として構成します。そして、リソースをリソースグループ (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 時間を要求する各アプリケーションに割り当てられているシェア数によって異なります。

図 : この図については、前の本文中で説明しています。