| System Management Services (SMS) 1.4 管理者マニュアル |    
|
| System Management Services (SMS) 1.4 管理者マニュアル |
|
第3章 |
|
SMS の操作は一般に、一連のデーモンとコマンドにより実行されます。この章では、SMS の動作の概要を示し、SMS のデーモン、プロセス、コマンド、およびシステムファイルについて説明します。詳細については、『System Management Services (SMS) 1.4 リファレンスマニュアル』を参照してください。
|
注意 - /opt/SUNWSMS にあるファイルに変更を加えると、システムに重大な障害が発生する可能性があります。この章で説明される各ファイルへの変更は、十分な経験を積んだシステム管理者だけが行ってください。 |
Sun Fire ハイエンド (CPU/ディスクおよび CD-ROM) プラットフォームの電源を入れると、SC 上の Solaris オペレーティング環境が自動的に起動します。
起動プロセス中に /etc/init.d/sms スクリプトが呼び出されます。このスクリプトはセキュリティーを確保するため、MAN ネットワーク上での転送、ブロードキャスト、およびマルチキャストを無効化します。続いて、SMS ソフトウェアを起動するためにバックグラウンド処理を実行し、この処理により ssd が起動および監視されます。ssd は SMS の起動デーモンで、すべての SMS のデーモンおよびサーバーの起動および監視を担当します。
次に、ssd(1M) は、mld、pcd、hwad、tmd、dsmd、esmd、mand、osd、dca、efe、codd、efhd、elad、erd、smnptd、picld および wcapp も起動します。
詳細については、SMS デーモンおよび メッセージロギングを参照してください。efeの詳細については、http://docs.sun.com で入手可能な Sun Management Center の最新マニュアルを参照してください。
デーモンが起動したら、console などの SMS コマンドを使用できます。
SMS の起動には数分間を要します。起動中に実行したコマンドがエラーメッセージを返した場合、起動は完了していません。起動が完了すると、「SMS software start-up complete」というメッセージがプラットフォームのログに出力されます。このログの内容は、showlogs(1M) コマンドで確認できます。
SMS 1.4 の各デーモンは、Sun Fire ハイエンドシステム上で中心的な役割を果たします。デーモンは、API を使ってクライアントに SMS サービスを提供する持続的プロセスです。
|
注 - SMS デーモンは ssd により起動されるので、コマンド行から手動で起動しないでください。デーモンに対して kill コマンドを発行すると、SMS ソフトウェアの堅牢性に重大な影響を与えるため、サンの保守担当者から特に要求されない限り、このコマンドを発行しないでください。 |
デーモンは常に実行されており、システムの起動時に初期化され、必要なときにいつでも再起動されます。
各デーモンの詳細な説明は、対応するマニュアルページにあります。ただし、efe コマンドについては、Sun Management Center のマニュアルで別に説明されています。
この節では SMS の各デーモンについて、お互いの関係、およびどの CLI (存在する場合) が各デーモンを利用するかを説明します。
図 3-1 は、Sun Fire ハイエンドシステムのソフトウェアコンポーネントと各コンポーネント間の高度なやり取りを示します。
|
注 - ドメイン X サーバー (dxs) およびドメイン構成エージェント (dca) は、デーモンではありませんが、主要なサーバープロセスなので以後の表および節に記載されています。各ドメインに対応して実行される dxs および dca のインスタンスは、18 個までです。 |
capacity on demand デーモン (codd (1M)) は、メインシステムコントローラ (SC) で実行されるプロセスです。
使用される COD 資源を監視し、その資源が COD ライセンスデータベースファイルのライセンスと一致していることを確認する。
インストールされているライセンス、資源の使用状況、およびボードの状態に関する情報を提供する。
COD ライセンスキーの追加または削除の要求を処理する。
ヘッドルームの数とドメイン RTU (right-to-use) ライセンスの予約を構成する。
図 3-2 は、COD デーモン (CODD) と SMS デーモンおよび CLI コマンドの関係を示します。
dca(1M) は、Solaris 8 または Solaris 9 ドメインで実行中のアプリケーションとドメイン構成サーバー (dcs) の通信を可能にすることで、遠隔からの動的再構成 (DR) をサポートします。SC で実行されるドメインごとに、1 つの dca が対応します。各 dca は、対応する dcs とは管理ネットワーク (MAN) を介して通信します。
ssd(1M) は、ドメインが作成されると dca を開始します。ssd は、ドメインの実行中に dca が終了されると、dca を再起動します。dca は、ドメインのシャットダウン時に終了されます。
dca は、動的再構成の要求を待機する SMS アプリケーションです。DR (動的再構成) 要求を受信すると、dca は dcs セッションを作成します。セッションが作成されると、dca は要求を dcs へ転送します。dcs は DR 要求への対応を試みて、その操作の結果を dca へ送信します。結果が送信されると、セッションは終了します。遠隔からの DR 操作は、dca が DR 操作の結果を返信した時点で完了します。
図 3-3 は、ドメイン構成エージェント (DCA) と SMS デーモンおよび CLI の関係を示します。
dsmd(1M) は、ドメイン状態のシグニチャー、CPU リセット条件、および Solaris の動作を、Sun Fire 15K では 18 ドメインまで、Sun Fire 12K では 9 ドメインまで監視します。また、ハードウェア障害に関係するドメイン停止イベントの処理も行います。
dsmd は、再起動トランザクションフローおよびパニックトランザクションフローで発生する可能性があるタイムアウトを検出して、さまざまなドメインハングアップ条件を処理します。
dsmd は、ドメイン X サーバー (dxs(1M)) および Sun Management Center に対してすべてのドメイン状態変更を通知してから、ドメイン状態のシグニチャー、ドメイン停止イベント、および自動システム回復 (ASR) のポリシーに基づいてドメインを自動的に復元します。ASR のポリシーは、1 つまたは複数のドメインがアクティブでなくなった場合に、すべてが適切に構成されたドメインの状態にシステムを復元するための各種手続きから成り立っています。ドメインがアクティブでなくなる理由は、ソフトウェアまたはハードウェアの障害や、不適切な環境条件などです。詳細については、ASR (Automatic System Recovery: 自動システム回復)およびドメイン停止イベントを参照してください。
dsmd は、ドメイン停止に関する自動診断 (AD) 情報も efhd に渡します。
図 3-4 は、ドメイン状態監視デーモン (DSMD) と SMS デーモンおよび CLI の関係を示します。
dxs(1M) は、実行中のドメインのソフトウェアをサポートします。このサポートには、仮想コンソール機能、動的再構成のサポート、および HPCI のサポートが含まれます。dxs は、ドメインドライバの要求およびイベントを処理します。dxs は、HPCI スロットの状態を取得および設定するためのインタフェースを提供します。スロットの状態には、カセットの有無、カセットが存在した場合のカセットの電力、周波数、健全性が含まれます。このインタフェースにより、HPCI カセットをホットプラグ操作する際の電源の制御が可能となります。
仮想コンソール機能により、console プログラムを実行している 1 人または複数のユーザーが、ドメインの仮想コンソールを使用できるようになります。dxs は、SMS コンソールアプリケーションと、ドメインの仮想 console ドライバとの間のリンクとして動作します。
1 つの Sun Fire 15K システムは、18 個までのドメインを個別にサポートできます。1 つの Sun Fire 12K ドメインは 9 個までのドメインをサポートできます。各ドメインには SC によるソフトウェアサポートが必要な場合もありますが、dxs がこのサポートを提供します。ドメインに関連する以下のプロジェクトに、dxs のサポートが必要です。
各 Sun Fire ハイエンドシステムドメインには、ドメイン X サーバーが 1 台あります。dxs は ssd によりすべてのアクティブなドメイン (OS ソフトウェアを実行するドメイン) で開始され、ドメインがシャットダウンされるときに終了します。
図 3-5 は、DXS クライアントサーバーと SMS デーモンの関係を示します。
dsmd(1M) から渡されたドメイン停止情報に基づいて、自動エラー診断を実行する。
診断エンジン (SMS または Solaris オペレーティング環境) または POST によって障害が特定されたときに、障害が発生したコンポーネントの健全性ステータスを更新する。
エラーのレポートを行う erd(1M) に障害イベントを渡す。
図 3-6 は、エラーおよび障害処理デーモン (EFHD) と SMS デーモンの関係を示します。
elad (1M) は、SMS イベントログへのアクセスを制御します。このイベントログには、Sun Fire ハイエンドシステムで、自動診断 (AD) エンジンまたは POST 診断エンジンによって特定される障害およびエラーイベントが記録されます。elad は、イベントログがいっぱいになったときに、イベントのアーカイブも行います。
図 3-7 は、イベントログアクセスデーモン (ELAD) と SMS デーモンおよび CLI コマンドの関係を示します。
erd(1M) は、障害イベントテキストメッセージをプラットフォームとドメインのログに書き込み、障害情報を Sun Management Center および SRS Net Connect に配信し、障害イベントメッセージが含まれた電子メールを送信するレポートサービスを提供します。
erd は、電子メールイベント通知があるたびに、電子メール制御ファイルと電子メールテンプレートファイルを読み取ります。
図 3-8 は、イベントレポートデーモン (ERD) と SMS デーモンの関係を示します。
esmd(1M) は、システムキャビネットの環境条件を監視します。たとえば、電圧、温度、ファントレー、電源装置、およびクロックフェージングなどです。esmd は異常な条件を記録し、必要ならば、ハードウェアを保護するアクションを起こします。
esmd の詳細については、環境イベントを参照してください。
図 3-9 は、環境状態監視デーモン (ESMD) と SMS デーモンの関係を示します。
fomd(1M) は、SC のフェイルオーバーメカニズムの中心です。fomd はローカルおよび遠隔の SC の障害を検出し、適切なアクションを起こします (フェイルオーバーまたはテイクオーバーの指示)。fomd は、重要な構成データの同期が 2 つの SC の間で保たれていることをテストして確認します。fomd はメイン SC およびスペア SC の両方で実行されます。
fomd についての詳細は、SC フェイルオーバーを参照してください。
図 3-10 は、フェイルオーバー管理デーモンと SMS デーモンの関係を示します。
frad(1M) は、SMS 用の保守部品 (FRU) アクセスデーモンです。frad は、SC でアクセスできる Sun Fire ハイエンドプラットフォーム内の任意の電気的に消去できるプログラム可能な読み出し専用メモリー (SEEPROM) へのアクセスを提供します。frad では、Solaris プラットフォーム情報と制御ライブラリデーモン (PICLD) を使用して、FRU データのアクセスを向上させる動的 FRUID をサポートしています。FRU の情報はサンの保守担当者だけが使用するものであり、ユーザーには意識されません。
図 3-11 は、FRU アクセスデーモン (FRAD) と SMS デーモンの関係を示します。
hwad(1M) は、SMS デーモンへのハードウェアアクセスを提供し、すべてのデーモンについては、ハードウェアにアクセス、制御、監視、および構成ができるメカニズムを排他的に提供します。
hwad は、起動されればメインモードまたはスペアモードのどちらでも実行できます。hwad がどちらの役割を担当するかは、フェイルオーバーデーモン (fomd(1M)) によって決まります。
すべてのドライバ (sbbc、echip、gchip、および consbus) を開き、ioctl(2) への呼び出しを各ドライバとのインタフェースとして使用する。
ローカルなシステムクロックを構成して、システムにある各ボードのクロックソースを指定する。
SC 割り込みに対して SC を使用不可にする。
SBBC システムの割り込みを許可するレジスタを消去することにより、DARB 割り込みを使用不可にする。
Echip ドライバからの割り込みを待機する、echip インタフェースを作成する。起動時の Echip ドライバからの割り込みは、SC ハートビート割り込みである。
装置存在レジスタの内容を読み取って、システム内に存在するボードを識別し、それらをクライアントからアクセスできるようにする。
I2C ステアリングを制御し、マシンに存在するすべてのボードの構成部品を初期化する。
クロックがフェーズロックされていることを確認する。フェーズロックされている場合、hwad は、すべてのクロックソースがメイン SC を指し示していることを確認する。クロックがフェーズロックされていない場合には、hwad はクロックソースを変更せず、自動クロックスイッチを使用不可にする。
DARB 割り込みを初期化して許可し、PCI 割り込みの生成を可能にする。gchip でのクロック障害割り込み、Echip でのコンソールバスエラー割り込み、echip での電源装置障害割り込みをすべて不可にする。
イベントの割り込みハンドラを初期化し、mand、dsmd、および各 osd のサービスイベントに対するスレッドを作成する。
18 個のドメインに対して、IOSRAM インタフェースを作成する。このインタフェースにより、SC とドメインの間の通信が可能になる。
hwad は、動的再構成 (DR) では、IOSRAM (トンネルスイッチ) との通信を指定します。
hwad は dsmd(1M) に通知して、dstop または rstop が存在するかどうかを確認します。また hwad は、発生した Mbox 割り込みの種類に応じて、関連する SMS デーモン (複数可) に通知します。
hwad は、コンソールバスおよび JTAG のエラーを検出および記録します。
SC 上の Sun Fire ハイエンドシステムへのハードウェアアクセスは、PCI バスまたはコンソールバスを通じて行います。PCI バスを通じて、以下のものにアクセスできます。
図 3-12 は、ハードウェアアクセスデーモン (HWAD) と SMS デーモンおよび CLI の関係を示します。
キー管理デーモンは、SC とドメインの間のソケット通信に関するセキュリティーを管理するメカニズムを提供します。
現在のデフォルト構成では、SC 上の dca(1M) および dxs クライアントに関する認証ポリシーが含まれています。これらのクライアントは、ドメインの dcs(1M) および cvcd(1M) サーバーに接続します。
kmd(1M) は、ドメインで実行中の SC およびサーバー間の通信のセキュリティー確保に必要な、IPSec セキュリティー関連付け (SA) を管理します。
kmd は、SC 上のクライアントにより開始された、ドメイン上のサーバーへの接続に関するソケットごとのポリシーを管理します。
システムの起動時に、kmd はアクティブな各ドメインへのドメインインタフェースを作成します。アクティブなドメインには有効な IOSRAM があり、Solaris オペレーティング環境が実行中です。ドメイン変更のイベントにより、ドメインの kmd インタフェースの作成または削除をトリガーできます。
kmd は、ドメイン上のクライアントにより開始された、SC 上のサーバーへの接続に関する共有ポリシーを管理します。kmd のポリシーマネージャは、構成ファイルを読み取って、セキュリティーの関連付けの管理に使用されるポリシーを格納します。kmd で受信された要求は現在のポリシーのセットと比較されて、要求が有効であり、要求のとおりに各種のパラメタを設定できることが確認されます。
静的なグローバルポリシーは、ipsecconf(1M) および関連データファイル (/etc/inet/ipsecinit.conf) を使用して構成されます。グローバルポリシーは、各ドメインで開始される、SC への接続で使用されます。対応するエントリは、kmd の構成ファイル中に作成されます。ドメインから SC への接続での共有セキュリティー関連付けは、ドメインがアクティブになるときに kmd により作成されます。
|
注 - 正常に動作するには、ipsecconf で作成されたポリシーと、kmd で作成されたポリシーが一致する必要があります。 |
kmd の構成ファイルは、SC とドメイン間、およびドメインと SC 間で開始された接続のどちらでも使用されます。kmd の構成ファイルは、次の場所に格納されています。
/etc/opt/SUNWSMS/config/kmd_policy.conf
dir:d_port:protocol:sa_type:aut_alg:encr_alg:domain:login
図 3-13 は、キー管理デーモン (KMD) と SMS デーモンの関係を示します。
mand(1M) は、管理ネットワーク (MAN) をサポートします。詳細については、管理ネットワークのサービスを参照してください。既定では mand はスペアモードで起動し、フェイルオーバーデーモン (fomd(1M)) によってメインモードに切り換えるよう指定したときに、メインモードに切り換わります。mand がどちらの役割を担当するかは、fomd によって決まります。
システムの起動時に、mand はスペアとして起動し、SC 間のプライベートネットワークを構成します。この情報は、smsconfig(1M) コマンドにより作成される /etc/opt/SUNWSMS/config/MAN.cf というファイルから取得されます。フェイルオーバーデーモン (fomd(1M)) が、mand にメインの役割を引き継ぐよう指示します。
プラットフォーム構成データベース (pcd) のドメイン変更イベントを登録し、ドメインのアクティブなボードのリストに加えられた変更を追跡する。
domain_tag と IP アドレス とのマッピングを pcd に作成する。
現在のドメイン構成で scman(7d) ドライバを初期化する。
hwad のイベントを登録し、dman(7d) ドライバからのアクティブな Ethernet 情報を追跡する。
scman ドライバと pcd を適宜更新する。
ドメインに電源投入されたとき (setkeyswitch がオンのとき) に、ドメインのキースイッチイベントを登録し、システム起動の MAN 情報を各ドメインに通知する。この情報には、Ethernet および MAN IP のアドレス情報と、ドメインでの初期ソフトウェアインストール時に使用されるアクティブなボードのリストが含まれている。
図 3-14 は、管理ネットワークデーモン (MAND) と SMS デーモンの関係を示します。
メッセージロギングデーモンである mld は、他の SMS デーモンおよびプロセスの出力をキャプチャします。mld は、3 つの構成命令をサポートしています。具体的には File、Level、および Mode で、/var/opt/SUNWSMS/adm/.logger ファイルにあります。
File -- メッセージファイルが出力されるデフォルトの場所を指定する。デフォルトは msgdaemon で、変更できない。
プラットフォームのメッセージは、SC の /var/opt/SUNWSMS/adm/platform/messages に格納される。
ドメインのメッセージは、SC の /var/opt/SUNWSMS/adm/domain_id/messages に格納される。
ドメインの console のメッセージは、SCの/var/opt/SUNWSMS/adm/domain_id/consoleに格納される。
ドメインの syslog のメッセージは、SC の /var/opt/SUNWSMS/adm/domain_id/syslogに格納される。
Level -- メッセージのログ記録に必要な最小レベルを指定する。サポートされているレベルは、NOTICE、WARNING、ERR、CRIT、ALERT、および EMERG である。デフォルトのレベルは NOTICE である。
Mode -- メッセージの詳細さを指定する。2 つのモードを使用できる。verbose および terse である。デフォルトは verbose である。
mld は、各メッセージログファイルのサイズを監視します。メッセージログの種類ごとに、mld は一度に 10 個のメッセージファイルを保持しています。つまり x.0 から x.9 までです。ログメッセージの詳細については、メッセージロギングを参照してください。
図 3-15 は、メッセージロギングデーモン (MLD) と SMS デーモンおよび CLI の関係を示します。
osd(1M) は、ドメイン上で実行中の OpenBoot PROM プロセスをサポートします。osd と OpenBoot PROM の通信は、ドメイン上にあるメールボックスを介して行われます。osd デーモンは、OpenBoot PROM のメールボックスを監視します。OpenBoot PROM がメールボックスに要求を書き込むと、osd が要求を実行します。
osd は、構成済みのドメインがない場合でも、SC 上で常に実行されています。osd は仮想 TOD サービス、仮想 NVRAM、および仮想 REBOOTINFOを、OpenBoot PROM および dsmd(1M) へのインタフェースのために提供し、自動ドメイン復元を容易にしています。また osd は、以下のコマンドへのインタフェースも提供しています: setobpparams(1M)、showobpparams(1M)、setdate(1M)、および showdate(1M)。詳細については、SMS の構成を参照してください。
osd は、他の SMS プロセスにインタフェースをまったくエクスポートしないという点で信頼できるデーモンです。osd は、OpenBoot PROM メールボックスとの読み取りおよび書き込みを排他的に行います。OpenBoot PROM メールボックスは、各ドメインに 1 つあります。
osd には主に 2 つのタスクがあります。ドメイン構成の現在の状態を維持すること、および OpenBoot PROM メールボックスを監視することです。
図 3-16 は、OpenBoot PROM サポートデーモン (OSD) と SMS デーモンおよび CLI の関係を示します。
pcd(1M) は、SC 上で実行する Sun Fire ハイエンドシステム管理デーモンで、プラットフォームおよびドメインの構成データへのアクセスを管理および提供することが主な役割です。
pcd は、Sun Fire システムの構成を示す一連の情報を管理します。データベースの情報は、物理的にはフラットファイルの集まりであり、各ファイルはその内容で識別できます。データベース情報にアクセスする必要がある SMS アプリケーションは、必ず pcd を経由しなければなりません。
プラットフォーム構成データの管理以外に、pcd はプラットフォーム構成が変更された場合の通知も行います。システム内でプラットフォーム構成に永続的な変更があったとき、pcd は、受信登録済みのクライアントに対して変更の通知を送信します。
図 3-17 は、プラットフォーム構成データベースデーモン (PCD) と SMS デーモンおよび CLI の関係を示します。
プラットフォームの種類
プラットフォーム名
シャーシのホスト ID は、COD ライセンスを取得するために、COD 機能でプラットフォームを特定する際にのみ使用されます。シャーシのホスト ID はセンタープレーンのシリアル番号で、システム内部に記録されています。シャーシのホスト ID を表示するには、showplatform -p cod コマンドを実行します。
シャーシのシリアル番号は Sun Fire ハイエンドシステムを特定する番号で、メッセージとイベントでプラットフォームを特定するときに使用されます。この番号は、サービスプロバイダがイベントと保守アクションを該当するシステムに関連付けるときにも使用されます。シャーシのシリアル番号は、システムシャーシ正面の下部中央付近に貼付されているラベルに印刷されています。SMS 1.4 リリースからは、シャーシのシリアル番号は、サンでの製造時に SMS 1.4 をインストールして出荷するシステム上に自動的に記録されます。シャーシのシリアル番号を表示するには、showplatform -p csn コマンドを実行します。
旧バージョンの SMS から SMS 1.4 にアップグレードするときは、setcsn(1M) コマンドを使用して、シャーシのシリアル番号を記録します。setcsn コマンドについての詳細は、『System Management Services (SMS) 1.4 リファレンスマニュアル』のコマンドの説明を参照してください。
キャッシュ可能なアドレススライスマップ
システムのクロック周波数
システムクロックの種類
SC の IP アドレス
SC0 から SC1 の IP アドレス
SC1 から SC0 の IP アドレス
SC から SC の IP ネットマスク
COD インスタントアクセス CPU (ヘッドルーム)
domain_id
domain_tag
OS のバージョン (現在は未使用)
OS の種類 (現在は未使用)
使用可能構成要素リスト
割り当てられているボードのリスト
アクティブなボードのリスト
Golden IOSRAM I/O ボード
ドメインの仮想キースイッチ設定
アクティブな Ethernet I/O ボード
ドメイン作成時刻
ドメインダンプの状態
ドメイン起動の優先順位
IP ホストアドレス
ホスト名
ホストのネットマスク
ホストのブロードキャストアドレス
仮想 OpenBoot PROM アドレス
物理 OpenBoot PROM アドレス
COD RTU ライセンス予約
拡張ボードの位置
スロットの位置
ボードの種類
ボードの状態
ボードに割り当てられたドメインID
使用可能構成要素リストの状態
ボードテストの状態
ボードテストのレベル
ボードメモリークリア状態
COD 使用可能フラグ
ssd(1M) は、すべての SMS デーモンおよびドメイン X サーバーの起動と管理を担当します。
ssd は環境チェックを通じて特定のファイルと Sun Fire ハイエンドシステムの利用可能状況を調べ、環境変数を設定し、さらにメインの esmd(1M) を起動します。esmd は関連するハードウェアコンポーネントをポーリングして、環境の変更状況を監視します。異常な状況を検出すると、esmd は自身でそれを処理するか、またはイベントを生成して、対応するイベントハンドラに適切なアクションを実行させたり、現在のハンドラの状態を更新させます。イベントハンドラには、たとえば dsmd や pcd などがあります。Sun Management Center も、インストールされている場合には、イベントハンドラに含まれます。ssd の主な役割は、SMS のデーモンとサーバーを常時、確実に動作させることです。
図 3-18 は、SMS 起動デーモン (SSD) と SMS デーモンの関係を示します。
ssd は構成ファイル ssd_start を使用して、SMS ソフトウェアのどのコンポーネントをどのような順序で起動するかを決定します。構成ファイルは、次の場所に格納されています。
/etc/opt/SUNWSMS/startup
|
注意 - このファイルが、システム構成ファイルです。このファイルの編集で誤ってしまうと、システムが動作しなくなる可能性があります。このスクリプトでは、args のフィールドだけを編集してください。特定のオプションについては、デーモンのマニュアルページを参照してください (スクリプトの構文には、特に注意してください)。 |
ssd_start は、以下のフォーマットのエントリからなります。
name:args:nice:role:type:trigger:startup_timeout:shutdown_timeout:uid:start_order:stop_order
|
ssd がデーモンを起動する順序を定義します。この値は変更しないでください。デフォルト値を変更すると、SMS デーモンが正しく機能しなくなる可能性があります。 |
|
|
ssd がデーモンを停止する順序を定義します。この値は変更しないでください。デフォルト値を変更すると、SMS デーモンが正しく機能しなくなる可能性があります。 |
ssd が起動するときは、必ず spare モードで起動します。ssd が起動するとプラットフォームのコアとなるデーモンが実行中なので、ssd は fomd(1M) に対して自身の役割を問い合わせます。fomd が spare を返した場合、ssd はスペアモードのままです。fomd が main を返した場合、ssd は main モードに移行します。
初期の問い合わせフェーズの後、ssd がモードを切り替えるのは fomd からイベントを受信した場合だけです。
spare モードでは、ssd は主要な Platform 役割のすべてを開始および監視し、ssd_start ファイルに記述されているプログラムを auto で (自動的に) 起動します。現在、このファイルには以下のプログラムが記述されています。
main モードのときに ssd が spare イベントを受信した場合、ssd は主要な platform 役割を除くすべてのプログラムをシャットダウンして、ssd_start ファイルにあるプログラムを自動的に起動します。
ssd は、main イベントを受信するまでは spare モードのままです。この時点で ssd が開始して、すでに実行中のデーモンの他に、ssd_start ファイルに記述されている、platform 役割 (メインのみ) event 起動プログラムのすべてを開始および監視します。このファイルには以下のプログラムが記述されています。
最後に、すべての platform 役割、event 起動プログラムを開始した後で、ssd は pcd に照会して、どのドメインがアクティブであるかを判別します。これらの各ドメインについて、ssd は domain 役割と、ssd_start ファイルに記述されている event 起動プログラムのすべてを開始します。
ssd は、pcd からのドメイン開始および停止のイベントを、ドメイン固有のサーバーを開始および停止するための命令として使用します。
命令を受信すると、ssd は domain 役割と、ssd_startファイルに記述されている event 起動プログラム (識別されたドメインのもの) のすべてを開始または停止します。
ssd は、いったんプロセスを開始したプロセスを監視して、プロセスが失敗した場合に再起動します。
SMS ソフトウェアをアップグレードする場合は、その SMS ソフトウェアをシャットダウンする必要があります。ssd は、自分自身と、自分の制御下にあるすべての SMS デーモンおよびサーバーをシャットダウンするメカニズムを提供します。
ssd は、自分の制御下にあるすべての SMS ソフトウェアコンポーネントにシャットダウンするよう通知します。すべての SMS ソフトウェアコンポーネントがシャットダウンした後で、ssd は自身をシャットダウンします。
tmd(1M) は、SMS のスケジューリングなど、タスク管理サービスを提供します。タスク管理デーモンにより、ハードウェアのテストとソフトウェアの構成を並行して実施する場合に起こりうるさまざまな衝突が減少します。
現時点では、tmd によりエクスポートされる唯一のサービスは hpost(1M) スケジューリングサービスです。Sun Fire ハイエンドシステムでは、hpost は 2 つの要素に基づいてスケジューリングされます。
hpost の制限事項。プラットフォームが最初に起動したときにドメインが構成されていないと、hpost の単一のインスタンスがすべての拡張ボードについて排他的な制御を取得し、センタープレーン ASIC を構成する。以後のすべての hpost 呼び出しは、この処理が完了するのを待ってから進むことになる。
任意の拡張ボード 1 つに 1 度に作用できるのは、単一の hpost 呼び出しだけである。分割拡張ボードなしで構成された Sun Fire ハイエンドシステムの場合は、この制限に関わらず複数の hpost 呼び出しを実行できる。ただし、システムが分割拡張ボードありで構成されているときは、この制限事項の影響を受ける。
システム全体での hpost 起動数の制限。システムを飽和させずに同時に起動できる hpost の数には制限がある。hpost 呼び出しの数を制限する機能は、ssd_startup の -t オプションを使用して実行できる。
|
注意 - デフォルト値を変更すると、システムの機能に悪影響を与える場合があります。Sun のサービス担当者から指示されない限り、このパラメタは調節しないでください。 |
図 3-19 は、タスク管理デーモン (TMD) と SMS デーモンの関係を示します。
SMS 環境の基本的なデフォルト値は、SMS のコマンドを実行する構成ファイルに設定されている必要があります。
ログイン時に他の環境変数を設定すると、時間を節約できます。表 3-2 に、便利な SMS 環境変数の一部を示します。
| System Management Services (SMS) 1.4 管理者マニュアル | 817-4175-10 |
|
Copyright © 2003, Sun Microsystems, Inc. All rights reserved.