第4章 |
|
SMS の操作は一般に、一連のデーモンとコマンドにより実行されます。この章では、SMS の動作の概要を示し、SMS のデーモン、プロセス、コマンド、およびシステムファイルについて説明します。詳細については、『System Management Services (SMS) 1.5 リファレンスマニュアル』を参照してください。
注意 - /opt/SUNWSMSにあるファイルに変更を加えると、システムに重大な障害が発生する可能性があります。この章で説明される各ファイルへの変更は、十分な経験を積んだシステム管理者だけが行ってください。 |
1. ユーザーが、Sun Fire ハイエンド (CPU/ディスクおよび CD-ROM) プラットフォームに電源を入れます。SC 上の Solaris OS が自動的に起動します。
2. 起動プロセス中に /etc/init.d/sms スクリプトが呼び出されます。このスクリプトはセキュリティーを確保するため、MAN ネットワーク上での転送、ブロードキャスト、およびマルチキャストを無効化します。続いて、SMS ソフトウェアを起動するためにバックグラウンド処理を実行し、この処理により ssd が起動および監視されます。ssd は SMS の起動デーモンで、すべてのSMS のデーモンおよびサーバーの起動および監視を担当します。
3. 次に ssd(1M) は、デーモンとプロセス、mld、pcd、hwad、tmd、dsmd、esmd、mand、osd、dca、efe,codd、efhd、elad、erd、smnptd、picld、wcapp も起動します。
SMS デーモンについての詳細は、SMS デーモン を参照してください。efe の詳細については、http://docs.sun.com で入手可能な Sun Management Center の最新マニュアルを参照してください。
4. デーモンが起動したら、console などの SMS コマンドを使用できます。
SMS の起動には数分間を要します。起動中に実行したコマンドがエラーメッセージを返した場合、起動は完了していません。起動が完了すると、「SMS software start-up complete」というメッセージがプラットフォームのログに出力されます。このログの内容は、showlogs(1M) コマンドで確認できます。
SMS 1.5 の各デーモンは、Sun Fire ハイエンドシステム上で中心的な役割を果たします。デーモンは、API を使ってクライアントに SMS サービスを提供する持続的プロセスです。
注 - SMS デーモンは ssd により起動されるので、コマンド行から手動で起動しないでください。デーモンに対して kill コマンドを発行すると、SMS ソフトウェアの堅牢性に重大な影響を与えるため、サンの保守担当者から特に要求されない限り、このコマンドを発行しないでください。 |
デーモンは常に実行されており、システムの起動時に初期化され、必要なときにいつでも再起動されます。
各デーモンの詳細な説明は、対応するマニュアルページにあります。ただし、efe コマンドについては、Sun Management Center のマニュアルで別に説明されています。
この節では SMS の各デーモンについて、お互いの関係、およびどの CLI (存在する場合) が各デーモンを利用するかを説明します。
図 4-1 に、Sun Fire ハイエンドシステムのソフトウェアコンポーネントとその高度な対話を示します。
capacity on demand デーモン (codd (1M)) は、メインシステムコントローラ (SC) で実行されるプロセスです。
図 4-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 操作の結果を返信した時点で完了します。
図 4-3 は、ドメイン構成エージェント (DCA) と SMS デーモンおよび CLI の関係を示します。
ドメイン状態監視デーモン dsmd(1M) は、ドメイン状態のシグニチャー、CPU リセット条件、および Solaris の動作を Sun Fire 15K/E25K では 18 ドメインまで、Sun Fire 12K/E20K システムでは 9 ドメインまで監視します。また、ハードウェア障害に関係するドメイン停止イベントの処理も行います。
dsmd は、再起動トランザクションフローおよびパニックトランザクションフローで発生する可能性があるタイムアウトを検出して、さまざまなドメインハングアップ条件を処理します。
dsmd は、ドメイン X サーバー (dxs(1M)) および Sun Management Center に対してすべてのドメイン状態変更を通知してから、ドメイン状態のシグニチャー、ドメイン停止イベント、および自動システム回復 (ASR) のポリシーに基づいてドメインを自動的に復元します。ASR のポリシーは、1 つまたは複数のドメインがアクティブでなくなった場合に、すべてが適切に構成されたドメインの状態にシステムを復元するための各種手続きから成り立っています。ドメインがアクティブでなくなる理由は、ソフトウェアまたはハードウェアの障害や、不適切な環境条件などです。詳細については、ASR (Automatic System Recovery: 自動システム回復) およびドメイン停止イベント を参照してください。
また dsmd は、ドメイン停止に関連する自動診断 (AD) 情報も efhd に渡します。
図 4-4 は、DSMD と SMS デーモンおよび CLI の関係を示します。
ドメイン X サーバー dxs(1M) は、実行中のドメインのソフトウェアをサポートします。このサポートには、仮想コンソール機能、動的再構成のサポート、および HPCI のサポートが含まれます。dxs は、ドメインドライバの要求およびイベントを処理します。dxs は、HPCI スロットの状態を取得および設定するためのインタフェースを提供します。スロットの状態には、カセットの有無、カセットが存在した場合のカセットの電力、周波数、健全性が含まれます。このインタフェースにより、HPCI カセットをホットプラグ操作する際の電源の制御が可能となります。
仮想コンソール機能により、console プログラムを実行している 1 人または複数のユーザーが、ドメインの仮想コンソールを使用できるようになります。dxs は、SMS コンソールアプリケーションと、ドメインの仮想 console ドライバとの間のリンクとして動作します。
1 つの Sun Fire 15K/E25K システムは、18 個までのドメインを個別にサポートできます。1 つの Sun Fire 12K/E20K ドメインは 9 個までのドメインをサポートできます。各ドメインには SC によるソフトウェアサポートが必要な場合もありますが、dxs がこのサポートを提供します。ドメインに関連する以下のプロジェクトに、dxs のサポートが必要です。
各 Sun Fire ハイエンドシステムドメインには、ドメイン X サーバーが 1 台あります。dxs は ssd によりすべてのアクティブなドメイン (OS ソフトウェアを実行するドメイン) で開始され、ドメインがシャットダウンされるときに終了します。
図 4-5 は、DXS と SMS デーモンの関係を示します。
エラーおよび障害処理デーモン efhd(1M) は、次の処理を行います。
図 4-5 は、EFHD と SMS デーモンの関係を示します。
イベントログアクセスデーモン elad (1M) は、SMS イベントログへのアクセスを制御します。このイベントログには、Sun Fire ハイエンドシステムで、自動診断 (AD) エンジンまたは POST 診断エンジンによって特定される障害およびエラーイベントが記録されます。elad は、イベントログがいっぱいになったときに、イベントのアーカイブも行います。
図 4-7 は、イベントログアクセスデーモン (ELAD) と SMS デーモンおよび CLI コマンドの関係を示します。
イベントレポートデーモン erd(1M) は、障害イベントテキストメッセージをプラットフォームとドメインのログに書き込み、障害情報を Sun Management Center および Sun Remote Services (SRS) Net Connect に配信し、障害イベントメッセージが含まれた電子メールを送信するレポートサービスを提供します。
erd は、電子メールイベント通知があるたびに、電子メール制御ファイルと電子メールテンプレートファイルを読み取ります。
図 4-8 は、イベントレポートデーモン (ERD) と SMS デーモンの関係を示します。
環境状態監視デーモン esmd(1M) は、システムキャビネットの環境条件を監視します。たとえば、電圧、温度、ファントレー、電源装置、およびクロックフェージングなどです。esmd は異常な条件を記録し、必要ならば、ハードウェアを保護するアクションを起こします。
esmd の詳細については、環境イベント を参照してください。
図 4-9 は、ESMD と SMS デーモンの関係を示します。
SC フェイルオーバーメカニズムの中心には、フェイルオーバー管理デーモン (fomd(1M)) があります。fomd はローカルおよび遠隔の SC の障害を検出し、適切なアクションを起こします (フェイルオーバーまたはテイクオーバーの開始)。fomd は、重要な構成データの同期が 2 つの SC の間で保たれていることをテストして確認します。fomd はメイン SC およびスペア SC の両方で実行されます。
fomd についての詳細は、第 12 章を参照してください。
図 4-10 は、FOMD と SMS デーモンの関係を示します。
FRU アクセスデーモン frad(1M) は、SMS 用の保守部品 (FRU) アクセスデーモンです。frad により、SC がアクセスできる、Sun Fire ハイエンドプラットフォーム内の任意の SEEPROM に対するアクセスを制御できます。frad では、Solaris プラットフォーム情報と制御ライブラリデーモン (PICLD) を使用して、FRU データのアクセスを向上させる動的 FRUID をサポートしています。FRU の情報はサンの保守担当者だけが使用するものであり、ユーザーには意識されません。
図 4-11 は、FRAD と SMS デーモンの関係を示します。
ハードウェアアクセスデーモン hwad(1M) は、SMS デーモンへのハードウェアアクセスを提供し、すべてのデーモンについては、ハードウェアに対して排他的にアクセス、制御、監視、および構成ができるメカニズムを提供します。
hwad は、起動されればメインモードまたはスペアモードのどちらでも実行できます。hwad がどちらの役割を担当するかは、フェイルオーバーデーモン (fomd(1M)) によって決まります。
hwad は、動的再構成 (DR) では、IOSRAM (トンネルスイッチ) との通信を指定します。
hwad は dsmd(1M) に通知して、dstop または rstop が存在するかどうかを確認します。また、発生した Mbox 割り込みの種類に応じて、関連する SMS デーモン (複数可) に通知します。
hwad は、コンソールバスおよび JTAG のエラーを検出および記録します。
SC 上の Sun Fire ハイエンドシステムへのハードウェアアクセスは、PCI バスまたはコンソールバスを通じて行います。PCI バスを通じて、以下のものにアクセスできます。
図 4-12 は、HWAD と SMS デーモンおよび CLI の関係を示します。
キー管理デーモン kmd(1M) は、SC とドメインの間のソケット通信に関するセキュリティーを管理するメカニズムを提供します。
現在のデフォルト構成では、SC 上の dca(1M) および dxs クライアントに関する認証ポリシーが含まれています。これらのクライアントは、ドメインの dcs(1M) および cvcd(1M) サーバーに接続します。
kmd は、ドメインで実行中の SC およびサーバー間の通信のセキュリティー確保に必要な、IPSec セキュリティー関連付け (SA) を管理します。
kmd は、SC 上のクライアントにより開始されたドメイン上のサーバーへの接続に関する、ソケットごとのポリシーを管理します。
システムの起動時に、kmd はアクティブな各ドメインへのドメインインタフェースを作成します。アクティブなドメインには有効な IOSRAM があり、Solaris OS が実行中です。ドメイン変更のイベントにより、ドメインの 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
図 4-13 は、KMD と SMS デーモンの関係を示します。
管理ネットワークデーモン mand(1M) は、管理ネットワーク (MAN) をサポートします。MAN ネットワークについての詳細は、管理ネットワークのサービス を参照してください。デフォルトでは mand はスペアモードで起動し、フェイルオーバーデーモン (fomd(1M)) によってメインモードに切り換えるよう指定したときに、メインモードに切り換わります。mand がどちらの役割を担当するかは、fomd によって決まります。
システムの起動時に、mand はスペアとして起動し、SC 間のプライベートネットワークを構成します。この情報は、smsconfig(1M) コマンドにより作成される /etc/opt/SUNWSMS/config/MAN.cf というファイルから取得されます。フェイルオーバーデーモン (fomd(1M)) が、mand にメインの役割を引き継ぐよう指示します。
図 4-14 は、MAND と SMS デーモンの関係を示します。
メッセージロギングデーモンである mld(1M) は、ほかの SMS デーモンおよびプロセスの出力をキャプチャします。mld は、3 つの構成命令をサポートしています。具体的には File、Level、および Mode で、/var/opt/SUNWSMS/adm/.logger ファイルにあります。
mld は、各メッセージログファイルのサイズを監視します。メッセージログの種類ごとに、mld は一度に 10 個のメッセージファイルを保持しています。つまり x.0 から x.9 までです。ログメッセージの詳細については、メッセージロギング を参照してください。
図 4-15 は、メッセージロギングデーモン (MLD) と SMS デーモンおよび CLI の関係を示します。
OpenBoot PROM サポートデーモン osd(1M) は、ドメインで実行中の OpenBoot PROM プロセスをサポートします。osd と OpenBoot PROM の通信は、ドメイン上にあるメールボックスを介して行われます。osd デーモンは、OpenBoot PROM のメールボックスを監視します。OpenBoot PROM がメールボックスに要求を書き込むと、osd が要求を実行します。
osd は、構成済みのドメインがない場合でも、SC 上で常に実行されています。osd は仮想時刻 (TOD) サービス、仮想 NVRAM (Non-volatile Random Access Memory)、および仮想 REBOOTINFO を、OpenBoot PROM および dsmd(1M) へのインタフェースのために提供し、自動ドメイン復元を容易にしています。また osd は、以下のコマンドへのインタフェースも提供しています: setobpparams(1M)、showobpparams(1M)、setdate(1M)、および showdate(1M)。詳細については、第 5 章を参照してください。
osd は、他の SMS プロセスにインタフェースをまったくエクスポートしないという点で信頼できるデーモンです。osd は、OpenBoot PROM メールボックスとの読み取りおよび書き込みを排他的に行います。OpenBoot PROM メールボックスは、各ドメインに 1 つあります。
osd には主に 2 つのタスクがあります。ドメイン構成の現在の状態を維持すること、および OpenBoot PROM メールボックスを監視することです。
図 4-16 は、OpenBoot PROM サポートデーモン (OSD) と SMS デーモンおよび CLI の関係を示します。
プラットフォーム構成デーモン pcd(1M) は、SC 上で実行する Sun Fire ハイエンドシステム管理デーモンで、プラットフォームおよびドメインの構成データへのアクセスを管理および提供することが主な役割です。
pcd は、Sun Fire システムの構成を示す一連の情報を管理します。データベースの情報は、物理的にはフラットファイルの集まりであり、各ファイルはその内容で識別できます。データベース情報にアクセスする場合、SMS アプリケーションはすべて必ず pcd を経由しなければなりません。
プラットフォーム構成データの管理以外に、pcd はプラットフォーム構成が変更された場合の通知も行います。システム内でプラットフォーム構成に永続的な変更があったとき、pcd は、受信登録済みのクライアントに対して変更の通知を送信します。
図 4-17 は、プラットフォーム構成データベースデーモン (PCD) と SMS デーモンおよび CLI の関係を示します。
シャーシのホスト ID は、COD ライセンスを取得するために、COD 機能でプラットフォームを特定する際にのみ使用されます。シャーシのホスト ID はセンタープレーンのシリアル番号で、システム内部に記録されています。シャーシのホスト ID を表示するには、showplatform -p cod コマンドを実行します。
シャーシのシリアル番号は Sun Fire ハイエンドシステムを特定する番号で、メッセージとイベントでプラットフォームを特定するときに使用されます。この番号は、サービスプロバイダがイベントと保守アクションを該当するシステムに関連付けるときにも使用されます。シャーシのシリアル番号は、システムシャーシ正面の下部中央付近に貼付されているラベルに印刷されている。SMS 1.4 からは、シャーシのシリアル番号は、サンでの製造時に SMS をインストールして出荷するシステム上に自動的に記録されます。シャーシのシリアル番号を表示するには、showplatform -p csn コマンドを実行します。
旧バージョンの SMS から SMS 1.5 以降にアップグレードするときは、setcsn(1M) コマンドを使用して、シャーシのシリアル番号を記録します。setcsn コマンドについての詳細は、『System Management Services (SMS) 1.5 リファレンスマニュアル』のコマンドの説明を参照してください。
SMS 起動デーモン ssd(1M) は、すべての SMS デーモンおよびドメイン X サーバーの起動と管理を担当します。
ssd は環境チェックを通じて特定のファイルと Sun Fire ハイエンドシステムの利用可能状況を調べ、環境変数を設定し、さらにメイン SC の esmd(1M) を起動します。esmd は関連するハードウェアコンポーネントをポーリングして、環境の変更状況を監視します。異常な状況を検出すると、esmd は自身でそれを処理するか、またはイベントを生成して、対応するイベントハンドラに適切なアクションを実行させたり、現在のハンドラの状態を更新させたりします。イベントハンドラには、たとえば dsmd や pcd などがあります。Sun Management Center も、インストールされている場合には、イベントハンドラに含まれます。ssd の主な役割は、SMS のデーモンとサーバーを常時、確実に動作させることです。
図 4-18 は、SSD と SMS デーモンの関係を示します。
ssd は、構成ファイル ssd_start を使用して、起動する SMS コンポーネントとそれらの起動順序を判断します。この構成ファイルは、/etc/opt/SUNWSMS/startup ディレクトリにあります。
注意 - このファイルが、システム構成ファイルです。このファイルの編集で誤ってしまうと、システムが動作しなくなる可能性があります。このスクリプトでは、argsのフィールドだけを編集してください。特定のオプションについては、デーモンのマニュアルページを参照してください (スクリプトの構文には、特に注意してください)。 |
ssd_start は、以下のフォーマットのエントリからなります。
name:args:nice:role:type:trigger:startup_timeout:shut down_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 ファイルにあるプログラムを auto で (自動的に) 起動します。
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 つの要素に基づいてスケジューリングされます。
任意の拡張ボード 1 つに 1 度に作用できるのは、単一の hpost 呼び出しだけです。分割拡張ボードなしで構成された Sun Fire ハイエンドシステムの場合は、この制限に関わらず複数の hpost 呼び出しを実行できます。ただし、システムが分割拡張ボードありで構成されているときは、この制限事項の影響を受けます。
注意 - デフォルト値を変更すると、システムの機能に悪影響を与える場合があります。Sun のサービス担当者から指示されない限り、このパラメタは調節しないでください。 |
図 4-19 は、TMD と SMS デーモンの関係を示します。
SMS 環境の基本的なデフォルト値は、SMS のコマンドを実行する構成ファイルに設定されている必要があります。
ログイン時に他の環境変数を設定すると、時間を節約できます。表 4-2 に、便利な SMS 環境変数の一部を示します。
Copyright© 2005, Sun Microsystems, Inc. All rights reserved.