第4章 |
|
SMS の操作は一般に、一連のデーモンとコマンドにより実行されます。この章では、SMS の動作の概要を示し、SMS のデーモン、プロセス、コマンド、およびシステムファイルについて説明します。詳細については、『System Management Services (SMS) 1.6 リファレンスマニュアル』を参照してください。
![]() |
注意 - /opt/SUNWSMSにあるファイルに変更を加えると、システムに重大な障害が発生する可能性があります。この章で説明される各ファイルへの変更は、十分な経験を積んだシステム管理者だけが行な。ってください。 |
1. ユーザーが、Sun Fire ハイエンド (CPU/ディスクおよび DVD-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.6 の各デーモンは、Sun Fire ハイエンドシステム上で中心的な役割を果たします。デーモンは、API を使ってクライアントに SMS サービスを提供する持続的プロセスです。
注 - SMS デーモンは ssd により起動されるので、コマンド行から手動で起動しないでください。デーモンに対して kill コマンドを発行すると、SMS ソフトウェアの堅牢性に重大な影響を与えるため、Sun の保守担当者から特に要求されないかぎり、このコマンドを発行しないでください。 |
デーモンは常に実行されており、システムの起動時に初期化され、必要なときにいつでも再起動されます。
各デーモンの詳細は、対応するマニュアルページで説明されています。ただし、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、または Solaris 10 ドメインで実行中のアプリケーションとドメイン構成サーバー (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 では最大 18 個のドメイン、Sun Fire 12K システムでは最大 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 システムは、18 個までのドメインを個別にサポートできます。1 つの Sun Fire 12K ドメインは 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) アクセスデーモンです。SC がアクセス可能な Sun Fire ハイエンドプラットフォーム内の任意の SEEPROM へのアクセスは、frad が制御します。frad では、Solaris プラットフォーム情報と制御ライブラリデーモン (PICLD) を使用して FRU データのアクセスを向上させる、動的 FRUID がサポートされています。FRU の情報は Sun の保守担当者だけが使用するものであり、ユーザーには意識されません。
図 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 に入っています。
図 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 は、/var/opt/SUNWSMS/adm/.logger ファイルにある File、Level、および Mode の 3 つの構成命令をサポートしています。
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 は、OpenBoot PROM 用の仮想時刻 (TOD) サービス、仮想 NVRAM (非揮発性のランダムアクセスメモリー)、および仮想 REBOOTINFO を提供し、さらに自動ドメイン回復を容易にするための 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 からは、シャーシのシリアル番号は、Sun での製造時に SMS をインストールして出荷するシステム上に自動的に記録されます。シャーシのシリアル番号を表示するには、showplatform -p csn コマンドを実行します。
前のバージョンの SMS から SMS 1.6 以降にアップグレードする場合は、setcsn(1M) コマンドを使用して、シャーシのシリアル番号を記録してください。setcsn コマンドについての詳細は、『System Management Services (SMS) 1.6 リファレンスマニュアル』のコマンドの説明を参照してください。
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© 2006, Sun Microsystems, Inc. All rights reserved.