test

Sun Cluster の概要 (Solaris OS 版)

第 2 章 Sun Cluster の主要な概念

この章では、Sun Cluster システムのハードウェアやソフトウェアに関連する主な概念を説明します。ユーザーは、Sun Cluster システムを使用する前にこれらの概念を理解しておく必要があります。

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

クラスタノード

クラスタノードは、Solaris ソフトウェアと Sun Cluster ソフトウェアが共に動作しているマシンです。Sun Cluster ソフトウェアでは、ハードウェア構成に応じて、1 つのクラスタで 1 から 16 個のノードを使用できます。どのハードウェア構成が最大何個のノードをサポートしているかについては、Sun の担当者にお問い合わせください。

クラスタノードは通常、1 つ以上のディスクに接続されます。ディスクに接続されていないノードは、クラスタファイルシステムを使用して多重ホストディスクにアクセスします。PDB データベース構成の下にある各ノードは、一部またはすべてのディスクに同時にアクセスします。

クラスタ内のすべてのノードは、別のノードがいつクラスタに結合されたか、またはクラスタから切り離されたかを認識します。さらに、クラスタ内のすべてのノードは、ローカルに実行されているリソースだけでなく、他のクラスタノードで実行されているリソースも認識します。

同じクラスタ内の各ノードの処理、メモリー、および入出力機能が同等で、パフォーマンスを著しく低下させることなく処理を継続できることを確認してください。フェイルオーバーの可能性があるため、各ノードには、ノードの障害時にもサービスレベル合意を満たせる十分な容量を持つ必要があります。

クラスタインターコネクト

クラスタインターコネクトは、クラスタノード間でクラスタプライベート通信やデータサービス通信を伝送する物理的なデバイス構成です。

冗長なインターコネクトの 1 つに障害が発生しても、操作は残りのインターコネクトを使って続けられます。そのため、システム管理者は、その間に障害を分離し、通信を修復することができます。Sun Cluster ソフトウェアは障害を検知し、修復し、修復されたインターコネクト経由の通信を自動的に再始動します。

詳細については、「クラスタインターコネクトコンポーネント」を参照してください。

クラスタメンバーシップ

クラスタメンバーシップモニター (CMM) は、クラスタインターコネクトを使ってメッセージを交換し、次の処理を行う一連の分散エージェントです。

CMM の主な機能はクラスタメンバーシップを確立することですが、そのためには、クラスタに逐次参加するノード群に関してクラスタ全体が合意していなければなりません。CMM は、1 つまたは複数のノード間での通信の途絶など、各ノードにおけるクラスタステータスの大きな変化を検知します。CMM は、トランスポートカーネルモジュールを使ってハートビートを生成し、トランスポート媒体を通してそれをクラスタのほかのノードに伝送します。定義されたタイムアウト時間内にノードからハートビートが送られてこないと、CMM は、そのノードに障害が発生したものとみなし、クラスタの再構成を通してクラスタメンバーシップの再設定を試みます。

CMM は、クラスタメンバーシップを確定し、データの整合性を確保するために、次の処理を行います。

クラスタが複数の独立したクラスタに分割されないように防止する方法については、「データの完全性」を参照してください。

クラスタ構成レポジトリ

クラスタ構成レポジトリ (CCR) は、クラスタの構成や状態に関する情報を格納するための、クラスタ全体に有効なプライベート分散データベースです。構成データを破損しないために、個々のノードは、クラスタリソースの現在の状態を知っている必要があります。この CCR のおかげで、すべてのノードが、一貫性のあるクラスタ像を持つことができます。CCR は、エラーや復旧の情況が発生したり、クラスタの一般的なステータスに変化があると更新されます。

CCR 構造には、次のような情報が含まれています。

フォルトモニター

Sun Cluster システムでは、アプリケーションそのものや、ファイルシステム、ネットワークインタフェースを監視することによって、ユーザーとデータ間の「パス」にあるすべてのコンポーネントの高い可用性を保ちます。

Sun Cluster ソフトウェアは、ノードを素早く検知し、そのノードと同等のリソースを備えたサーバーを作成します。Sun Cluster ソフトウェアのおかげで、障害のあるノードの影響を受けないリソースはこの復旧中も引き続き使用され、障害のあるノードのリソースは復旧すると同時に再び使用可能になります。

データサービス監視

Sun Cluster の各データサービスには、データサービスを定期的に検査してその状態を判断するフォルトモニターがあります。フォルトモニターは、アプリケーションデーモンが動作しているかどうかや、クライアントにサービスが提供されているかどうかを検証します。探索によって得られた情報をもとに、デーモンの再起動やフェイルオーバーの実行などの事前に定義された処置が開始されます。

ディスクパスの監視

Sun Cluster ソフトウェアは、ディスクパス監視 (DPM) がサポートします。DPM は、二次ディスクパスの障害を報告することによって、フェイルオーバーやスイッチオーバーの全体的な信頼性を高めます。ディスクパスの監視には 2 つの方法があります。1 つめの方法は cldevice コマンドを使用する方法です。このコマンドを使用すると、クラスタ内のディスクパスの状態を監視、監視解除、または表示できます。コマンド行オプションについての詳細は、cldevice(1CL) のマニュアルページを参照してください。

2 つめの方法は、Sun Cluster Manager の GUI (Graphical User Interface) を使用してクラスタ内のディスクパスを監視する方法です。Sun Cluster Manager では、監視されているディスクパスがトポロジで表示されます。このトポロジビューは 10 分ごとに更新され、失敗した ping の数が表示されます。

IP マルチパス監視

各クラスタノードには独自の IPMP 構成があり、これは他のクラスタノード上の構成と異なる場合があります。IP ネットワークマルチパス は、次のネットワークの通信障害を監視します。

定足数デバイス

定足数デバイスとは、複数のノードによって共有される共有ストレージデバイスまたは定足数サーバーで、定足数を確立するために使用される票を構成します。クラスタは、票の定足数が満たされた場合にのみ動作可能です。定足数デバイスは、クラスタが独立したノードの集合にパーティション分割されたときに、どちらのノード集合が新しいクラスタを構成するかを確定するために使用されます。

クラスタノードと定足数デバイスはどちらも、定足数を確立するために投票します。デフォルトにより、クラスタノードは、起動してクラスタメンバーになると、定足数投票数 (quorum vote count) を 1 つ獲得します。ノードは、ノードのインストール中や管理者がノードを保守状態にした時には、投票数は 0 になります。

定足数デバイスは、デバイスへのノード接続の数に基づいて投票数を獲得します。定足数デバイスは、設定されると、最大投票数 N-1 を獲得します。この場合、N は、投票数がゼロ以外で、定足数デバイスへ接続された投票数を示します。たとえば、2 つのノードに接続された、投票数がゼロ以外の定足数デバイスの投票数は 1 (2-1) になります。

データの完全性

Sun Cluster システムはデータ破損を防ぎ、データの完全性を保とうとします。それぞれのクラスタノードはデータとリソースを共有していますので、クラスタが、同時にアクティブである複数のパーティションに分割されることがあってはなりません。CMM は、必ず 1 つのクラスタだけが使用可能であることを保証します。

クラスタのパーティション分割によって起こる問題に split-brain と amnesia があります。split-brain が起こるのは、ノード間のクラスタインターコネクトが失われ、クラスタがサブクラスタにパーティション分割され、各サブクラスタが唯一のパーティションであると認識する場合です。ほかのサブクラスタの存在を認識していないサブクラスタは、ネットワークアドレスの重複やデータ破損など、共有リソースの対立を引き起こすおそれがあります。

amnesia は、すべてのノードがそのクラスタ内で不安定なグループの状態になっている場合に起こります。たとえば、ノード A とノード B からなる 2 ノードクラスタがあるとします。ノード A が停止すると、CCR の構成データはノード B のものだけが更新され、ノード A のものは更新されません。この後でノード B が停止し、ノード A が再起動されると、ノード A は CCR の古い内容に基づいて動作することになります。この状態を amnesia と呼びます。この状態になると、クラスタは、古い構成情報で実行されることがあります。

split-brain と amnesia の問題は、各ノードに 1 票を与え、過半数の投票がないとクラスタが動作しないようにすることで防止できます。過半数の投票を得たパーティションは「定足数 (quorum)」を獲得し、アクティブになります。この過半数の投票メカニズムは、クラスタのノード数が 2 を超える場合には有効です。しかし、2 ノードクラスタでは過半数が 2 であるため、このようなクラスタがパーティション分割されると、パーティションは外部からの投票で定足数を獲得します。この外部からの投票は、定足数デバイスによって行われます。定足数デバイスは、2 つのノードで共有されている任意のディスクにすることができます。

表 2–1に、 Sun Cluster ソフトウェアが定足数を使用して split-brain と anmesia を回避する様子を示します。

表 2–1 クラスタ定足数、および split-brain と amnesia の問題

問題 

定足数による解決策 

split brain 

過半数の投票を獲得したパーティション (サブクラスタ) だけをクラスタとして実行できるようにする (過半数を獲得できるパーティションは 1 つのみ)。ノードが定足数を獲得できないと、ノードはパニックになります。 

amnesia 

起動されたクラスタには、最新のクラスタメンバーシップのメンバーであった (したがって、最新の構成データを持つ) ノードが少なくとも 1 つあることを保証する。 

障害による影響の防止

クラスタの主要な問題は、クラスタがパーティション分割される (sprit-brain と呼ばれる) 原因となる障害です。このような状態になると、一部のノードが通信できなくなるため、個々のノードまたはノードの一部が、ノード単体または一部のノードによってクラスタを形成しようとします。各部分、つまりパーティションは、多重ホストディスクに対して単独のアクセスと所有権を持つものと誤って認識します。しかし、複数のノードがディスクに書き込もうとすると、データ破損を招くおそれがあります。

二重障害の防止機能は、ディスクへのアクセスを防止することによってノードが多重ホストディスクにアクセスすることを制限します。障害が発生するかパーティション分割され、ノードがクラスタから切り離されると、障害による影響の防止機能によって、ノードがディスクにアクセスできなくなります。現在のメンバーノードだけが、ディスクへのアクセス権を持つため、データの完全性が保たれます。

Sun Cluster システムは、SCSI ディスクリザベーションを使用して、二重障害の防止機能を実装します。SCSI 予約を使用すると、障害が発生したノードは、多重ホストディスクによって阻止されて、これらのディスクへのアクセスが防止されます。

クラスタメンバーは、別のノードがクラスタインターコネクトを介して通信していないことを検出すると、二重障害の防止手順を開始して、障害のあるそのノードが共有ディスクへアクセスするのを防止します。この二重障害の防止機能が動作すると、アクセスを阻止されたノードはパニック状態になり、そのコンソールに「reservation conflict」メッセージが表示されます。

障害の影響を防止するフェイルファースト機構

フェイルファースト機構は、障害のノードをパニック状態にしますが、そのノードの再起動を防ぐことはしません。パニックの後にこのノードは再起動を行ない、クラスタに再び参加しようとすることがあります。

定足数を獲得できるパーティションに属していないノードが、クラスタ内の他のノードとの接続を失うと、そのノードは別のノードによってクラスタから強制的に切り離されます。定足数を獲得できるパーティションに属しているノードはすべて、共有ディスク上でリザベーションを発行します。フェイルファースト機構の結果、定足数を満たしていないノードはパニック状態になります。

グローバルデバイス、ローカルデバイス、およびデバイスグループ

グローバルファイルシステムでは、クラスタのすべてのファイルがすべてのノードから同じように認識され、アクセス可能になります。それと同様に、Sun Cluster ソフトウェアの下では、クラスタのすべてのデバイスがクラスタ全体から認識され、アクセス可能になります。つまり、どのノードからでも入出力サブシステムを通してクラスタのどのデバイスにもアクセスできます。デバイスが物理的にどこに接続されているかは関係ありません。このアクセスをグローバルデバイスアクセスと呼びます。

グローバルデバイス

Sun Cluster システムでは、クラスタの任意のデバイスに任意のノードから高い可用性をもってクラスタレベルでアクセスできるようにするために、グローバルデバイスを使用します。

Sun Cluster でグローバルデバイスを使用する方法

通常、ノードからグローバルデバイスにアクセスできないことがあると、Sun Cluster ソフトウェアは、そのデバイスへのパスを別のパスに切り替え、アクセスをそのパスに振り向けます。グローバルデバイスでは、この変更は簡単です。どのパスを使用する場合でも、デバイスには同じ名前が使用されるからです。リモートデバイスへのアクセスは、同じ名前を持つローカルデバイスの場合と同じように行われます。さらに、クラスタのグローバルデバイスにアクセスする API は、ローカルのデバイスにアクセスする API と同じです。

Sun Cluster グローバルデバイスには、ディスク、CD-ROM、テープが含まれます。ただし、サポートされるマルチポートのグローバルデバイスはディスクだけです。つまり、CD-ROM とテープは、現在可用性の高いデバイスではありません。各サーバーのローカルディスクも多重ポート化されていないため、可用性の高いデバイスではありません。

クラスタは、クラスタ内の各ディスク、CD-ROM、テープデバイスに一意の ID を割り当てます。この割り当てによって、クラスタ内の任意のノードから各デバイスに対して一貫したアクセスが可能になります。

デバイス ID

Sun Cluster ソフトウェアは、デバイス ID (DID) ドライバと呼ばれるコンストラクトを通してグローバルデバイスを管理します。このドライバを使用して、多重ホストディスク、テープドライブ、CD-ROM を含め、クラスタ内のあらゆるデバイスに一意の ID を自動的に割り当てます。

DID ドライバは、クラスタのグローバルデバイスアクセス機能の重要な部分です。DID ドライバは、クラスタのすべてのノードを検査し、一意のディスクデバイスからなるリストを構築します。さらに、DID ドライバは、一意のメジャー番号とマイナー番号を各デバイスに割り当てます。この数字は、クラスタのすべてのノードで一貫性をもって管理されます。グローバルデバイスへのアクセスは、従来の Solaris DID と替わって DID ドライバによって割り当てられた 一意の DID を使って行われます。

このような方法をとれば、Solaris Volume Managerや Sun Java System Directory Server など、ディスクにアクセスするアプリケーションが何であれ、クラスタ全体で一貫性のあるパスが使用されます。多重ホストディスクの場合は、この一貫性がとりわけ重要です。各デバイスのローカルのメジャー番号とマイナー番号はノードによって異なる可能性があるからです。さらに、これらの数字は、Solaris デバイスの命名規約も同様に変更する可能性があります。

ローカルデバイス

Sun Cluster ソフトウェアはローカルデバイスも管理します。このようなデバイスは、サービスが動作しているノードだけでアクセスされるものであり、クラスタに物理的に接続されています。ローカルデバイスは、性能の点でグローバルデバイスよりも有利です。ローカルデバイスでは、状態情報を複数のノードに同時に複製する必要がないからです。デバイスのドメインに障害が発生すると、そのデバイスにはアクセスできなくなります。ただし、そのデバイスを複数のノードで共有できる場合を除きます。

デバイスグループ

デバイスグループは、ボリュームマネージャーのディスクグループを「グローバル」デバイスにします。デバイスグループは、使用しているディスクに対してマルチパスと多重ホストをサポートするからです。多重ホストディスクに物理的に接続された各クラスタノードは、デバイスグループへのパスを提供します。

Sun Cluster システムで Sun Cluster ソフトウェアを使用している多重ホストディスクを制御するには、多重ホストディスクをデバイスグループとして登録します。この登録によって、Sun Cluster システムは、どのノードがどのボリュームマネージャーディスクグループへのパスをもっているかを知ることができます。Sun Cluster ソフトウェアは、クラスタ内のディスクデバイスやテープデバイスごとに、raw デバイスグループを作成します。これらのクラスタデバイスグループは、ユーザーがグローバルファイルシステムをマウントするか、raw データベースファイルにアクセスすることによって、これらのデバイスグループをグローバルデバイスとしてアクセスするまでオフライン状態に置かれます。

データサービス

データサービスは、Sun Cluster 構成の下でアプリケーションを変更なしで実行できるようにする、ソフトウェアと構成ファイルの組み合わせです。Sun Cluster 構成の下で動作するアプリケーションは、リソースグループマネージャー (RGM) の制御下にある 1 つのリソースです。データサービスを使えば、Sun Java System Web Server や Oracle データベースなどのアプリケーションをクラスタで (単一のサーバーではなく) 実行するように構成できます。

データサービスのソフトウェアは、アプリケーションに対して次の操作を行う Sun Cluster 管理メソッドを実装しています。

データサービスの構成ファイルは、RGM にとってアプリケーションを意味するリソースのプロパティーを定義したものです。

クラスタのフェイルオーバーデータサービスやスケーラブルデータサービスの処理は RGM によって制御されます。RGM は、クラスタメンバーシップの変更に応じて選択されたクラスタのノードでデータサービスの起動や停止を行います。データサービスアプリケーションは、RGM を通してクラスタフレームワークを利用できます。

RGM はデータサービスをリソースとして制御します。これらの実装は Sun によって提供されるか、開発者によって作成されます。後者の場合には、汎用的なデータサービステンプレートや、 データサービス開発ライブラリ API (DSDL API)、リソース管理 API (RMAPI) が使用されます。クラスタ管理者は、リソースグループと呼ばれる入れ物 (コンテナ) の中でリソースの作成や管理を行います。リソースやリソースグループの状態は、RGM や管理者のアクションによってオンラインやオフラインにされます。

リソースタイプの説明

リソースタイプとは、あるアプリケーションをクラスタに説明するプロパティーの集まりのことです。この集合には、クラスタのノードでアプリケーションをどのように起動、停止、監視するかを示す情報が含まれています。さらに、リソースタイプには、アプリケーションをクラスタで使用するために必要なアプリケーション固有のプロパティーも含まれています。Sun Cluster データサービスには、いくつかのリソースタイプが事前に定義されています。たとえば、Sun Cluster HA for Oracle のリソースタイプは SUNW.oracle-server、Sun Cluster HA for Apache のリソースタイプ SUNW.apache です。

リソースの説明

リソースとは、クラスタ規模で定義したリソースタイプのインスタンスのことです。リソースタイプを使用すると、アプリケーションの複数のインスタンスをクラスタにインストールできます。ユーザーがリソースを初期化すると、RGM は、アプリケーション固有のプロパティーに値を割り当てます。リソースは、リソースタイプのレベルにあるすべてのプロパティーを継承します。

データサービスは、いくつかのタイプのリソースを使用します。たとえば、Apache Web Server や Sun Java System Web Server などのアプリケーションは、それらが依存するネットワークアドレス (論理ホスト名と共有アドレス) を使用します。アプリケーションとネットワークリソースは RGM が管理する基本単位です。

リソースグループの説明

RGM は、複数のリソースをリソースグループという 1 つの単位として扱うことができるようにします。リソースグループとは、関連する (あるいは、相互に依存する) リソースの集合のことです。たとえば、SUNW.LogicalHostname リソースタイプから派生したリソースは、Oracle データベースリソースタイプから派生したリソースと同じリソースグループに置かれることがあります。リソースグループ上でフェイルオーバーまたはスイッチオーバーが開始されると、リソースグループは 1 つの単位として移行されます。

データサービスのタイプ

データサービスを使用すると、アプリケーションは可用性の高いものやスケーラブルなサービスになります。クラスタで単一の障害が発生した場合、大幅なアプリケーションの中断を回避できます。

データサービスを構成する際には、次のデータサービスのタイプから 1 つを選択する必要があります。

フェイルオーバーデータサービスの説明

フェイルオーバーとは、クラスタがアプリケーションを障害のある稼動系から、指定の冗長化された待機系に自動的に再配置するプロセスのことをいいます。フェイルオーバーアプリケーションには、次の特徴があります。

フォルトモニターは、エラーを検出すると、データサービスの構成に従って、同じノードでそのインスタンスを再起動しようとするか、別のノードでそのインスタンスを起動 (フェイルオーバー) しようとします。フェイルオーバーサービスは、アプリケーションインスタンスリソースとネットワークリソース (論理ホスト名) のコンテナである、フェイルオーバーリソースグループを使用します。論理ホスト名とは、1 つのノードに構成して、後で自動的に元のノードや別のノードに構成できる IP アドレスのことです。

サービスが一時的に中断されるため、クライアントは、フェイルオーバーの完了後にサービスに再接続しなければならない場合があります。しかし、クライアントは、サービスの提供元である物理サーバーが変更したことを意識しません。

スケーラブルデータサービスの説明

スケーラブルデータサービスでは、複数のアプリケーションインスタンスが複数のノードで同時に動作します。スケーラブルサービスは、2 つのリソースグループを使用します。スケーラブルリソースグループにはアプリケーションリソースが、フェイルオーバーリソースグループには、スケーラブルサービスが依存するネットワークリソース (共有アドレス) がそれぞれ含まれています。スケーラブルリソースグループは、複数のノードでオンラインにできるため、サービスの複数のインスタンスを同時に実行できます。共有アドレスのホストとなるフェイルオーバーリソースグループは、一度に 1 つのノードでしかオンラインにできません。スケーラブルサービスをホストとするすべてのノードは、サービスをホストするための同じ共有アドレスを使用します。

クラスタは、同一のネットワークインタフェース (グローバルインタフェース) を通してサービス要求を受け取ります。これらの要求は、事前に定義されたいくつかのアルゴリズムの 1 つに基づいてノードに分配されます (アルゴリズムは負荷均衡ポリシーによって設定される)。クラスタは、負荷均衡ポリシーを使用し、いくつかのノード間でサービス負荷均衡をとることができます。

並列アプリケーションの説明

Sun Cluster システムは、パラレルデータベース (PDB) を使用することによってクラスタのすべてのノードでアプリケーションを並列で実行できるようにする環境を提供します。Sun Cluster Support for Oracle Real Application Clusters は、インストールされている場合、Oracle Real Application Clusters を Sun Cluster ノードで実行できるようにするパッケージ群です。さらに、このデータサービスでは、Sun Cluster コマンドを使って Sun Cluster Support for Oracle Real Application Clusters を管理できます。

パラレルアプリケーションはクラスタ環境で動作するように考えられたものです。したがって、このようなアプリケーションは、複数のノードから同時マスターされます。Oracle Real Application Clusters 環境では、複数の Oracle インスタンスが協力して同じ共有データベースへのアクセス権を提供します。Oracle クライアントは、任意のインスタンスを使用してデータベースにアクセスできます。したがって、1 つまたは複数のインスタンスで障害が発生しても、クライアントは残りのインスタンスに接続することによって、引き続きデータベースにアクセスできます。

システムリソースの使用状況

システムリソースは、CPU 使用率、メモリーの使用量、スワップの使用量、およびディスクとネットワークのスループットに関係します。

Sun Cluster を使用すると、ノード、ディスク、ネットワークインタフェース、Sun Cluster のリソースグループ、Solaris ゾーンなどのオブジェクトタイプにより特定のシステムリソースがどれだけ使用されているかを監視できます。システムリソースの使用状況の監視は、リソース管理ポリシーの一部とすることができます。また、Sun Cluster では、あるリソースグループに割り当てられた CPU を制御し、リソースグループが実行されるプロセッサセットのサイズを制御できます。

システムリソース監視

Sun Cluster を通じてシステムリソースの使用状況を監視することにより、特定のシステムリソースを使用するサービスがどのように実行されているかを反映するデータを収集したり、リソースのボトルネックや過負荷などを見つけたりすることができ、これによって問題に事前に対処し、ワークロードをより効率的に管理することができます。システムリソースの使用状況に関するデータは、どのハードウェアリソースが十分に利用されておらず、どのアプリケーションが大量のリソースを使用しているかを判別するのに役立ちます。このデータに基づき、必要なリソースを備えたノードにアプリケーションを割り当て、どのノードをフェイルオーバー先にするかを選択できます。このように統合することで、ハードウェアとソフトウェアのリソースの使用法を最適化できます。

あるデータの値がシステムリソースにとってクリティカルであると考えられる場合、この値のしきい値を設定できます。しきい値を設定する際には、しきい値に重要度を割り当てることにより、このしきい値のクリティカル度の選択も行います。しきい値を超えると、Sun Cluster はそのしきい値の重要度を、ユーザーが選択した重要度に変更します。データ収集としきい値の詳細については、『Sun Cluster のシステム管理 (Solaris OS 版)』の第 9 章「CPU 使用率の制御の構成」を参照してください。

CPU の制御

クラスタ上で動作する各アプリケーションおよびサービスには、それぞれ固有の CPU の要件があります。表 2–2 に、Solaris オペレーティングシステムのさまざまなバージョンで利用可能な CPU 制御動作を示します。

表 2–2 CPU の制御

Solaris のバージョン 

ゾーン 

制御 

Solaris 9 オペレーティングシステム 

該当なし 

CPU の配分の割り当て 

Solaris 10 オペレーティングシステム 

大域 

CPU の配分の割り当て 

Solaris 10 オペレーティングシステム 

非大域 

CPU の配分の割り当て 

CPU の数の割り当て 

専用のプロセッサセットの作成 

注 –

CPU の配分を行う場合、クラスタ上のデフォルトのスケジューラを Fair Share Scheduler (FSS) にする必要があります。

非大域ゾーンで専用のプロセッサセットのリソースグループに割り当てられた CPU を制御すると、CPU をもっとも厳密に制御できます。これは、あるリソースグループ向けに CPU を予約した場合、この CPU はほかのリソースグループからは使用できないためです。CPU の制御の構成の詳細については、『Sun Cluster のシステム管理 (Solaris OS 版)』の第 9 章「CPU 使用率の制御の構成」を参照してください。

システムリソースの使用状況の視覚化

システムリソースデータと CPU の帰属を視覚化する方法には、コマンド行を使用する方法と Sun Cluster Manager グラフィックユーザーインタフェースを使用する方法の 2 つがあります。コマンドからの出力は、ユーザーが要求する監視データの表形式の表現になります。Sun Cluster Manager を使用すると、データをグラフィック形式で視覚化できます。監視することを選択したシステムリソースは、ユーザーが視覚化できるデータを決定します。