| Sun Fire ハイエンドシステム Dynamic Reconfiguration ユーザーマニュアル |    
|
| Sun Fire ハイエンドシステム Dynamic Reconfiguration ユーザーマニュアル |
|
第3章 |
|
この章では、接続、構成、切り離し、および構成解除の 4 つの一般的な DR 操作について説明します。これらの操作の詳細については、第 5 章 DR ドメイン手順を参照してください。
この章では、ともに動作して DR 操作を遂行する、各種ソフトウェアコンポーネントについても説明します。DR 操作中に使用されるコンポーネントは、DR 操作がどこで開始されるかによってまったく異なります。たとえば、システムコントローラ (SC) から DR 操作を開始した場合は、ドメインから DR 操作を開始した場合よりもさらに多くのソフトウェアコンポーネントが使用されて、DR 操作が実行されます。
SC に常駐するソフトウェアコンポーネントの詳細は、『System Management Services (SMS) Dynamic Reconfiguration ユーザーマニュアル』を参照してください。
この節では、接続、構成、切り離し、および構成解除の 4 つの一般的な DR 操作について説明します。これらの操作をドメインの観点から説明します。SC に特定の情報は含まれません。
ドメインの起動後、最初の DR 操作を実行する前に、そのドメインで対象のボードが利用できることを確認してください。ドメインで利用できるボードは、cfgadm(1Ｍ) コマンドを -l オプション付きで実行すれば一覧できます。
次のいずれかの条件に該当するボードに DR 操作を試みると、エラーになります。
どちらの場合も、該当するボードはドメインで使用できません。使用可能構成要素リストの詳細は、『System Management Services (SMS) 管理者マニュアル』を参照してください。
ドメインの入出力ボードで DR 操作を実行する前に、そのドメインに少なくとも 2 つの CPU があることを確認してください。さらに、それら CPU のうち少なくとも 1 つは CPU/メモリーボード上にあり、どのプロセスにも結合していないことを確認してください。結合プロセスについての詳細は、pbind(1M) マニュアルページを参照してください。
DR を使用してドメインに入出力ボードを構成する (または、cfgadm(１M) を-t オプション付きで使用して、入出力ボードを明示的にテストする)場合、ボードをテストするために、同じドメインの CPU/メモリーボード上の占有装置である CPU が 1 つ選択されます。また、CPU にはプロセスを結合できず、少なくとも 1 つの追加 CPU がドメインに残っている必要があります。テストを実行するために使用する CPU がない場合、次のようなメッセージが表示されます。
WARNING: No CPU available for I/O cage test.
CPU はドメインから構成解除され、入出力ボードがテストされます。テストが完了すると、CPU はドメインに再構成されます。CPU が正常に再構成された後、psrinfo(1M) コマンドで表示されるタイムスタンプはそのドメインの他の CPU のタイムスタンプとは異なります。
接続操作中、システムボードが使用可能でどの論理ドメインの一部でもない場合、DR はスロットをドメインに割り当てようとします。スロットの割り当てが済むと、DR は SC に電源投入とボードのテストを要求します。ボードのテストが済むと、DR は SC に対して、ボードをシステムに電気的に接続して、ボードを物理ドメインの一部にするように要求します。次に、オペレーティングシステムがボード上のコンポーネントを検査します。
SC の代わりにドメインを経由してシステムボードを接続するには、cfgadm(1M) コマンドを次のように使用します。
# cfgadm -c connect SBx |
ここで、x は特定のボードの番号 (たとえば、Sun Fire 15K システムでは 0〜17、Sun Fire 12K システムでは 0〜8) を示します。
|
注 - DR 操作中に cfgadm(1M) コマンドの実行が失敗すると、対象のボードは元の状態に戻りません。dxs または dca のエラーメッセージが、ドメインのログに出力されます。エラーが回復可能であれば、失敗したコマンドを再試行できます。エラーが回復不能な場合、そのボードを使用するには、ドメインの再起動が必要です。 |
入出力ボードを接続する cfgadm(1M) コマンドの構文は、次のとおりです。
# cfgadm -c connect IOx |
ここで、x は特定のボードの番号を示します。たとえば、Sun Fire 15K サーバーでは 0〜17、Sun Fire 12K サーバーでは 0〜8 です。
ボードが挿入される前の接続点の状態と条件は、次のとおりです。
ボードが物理的に挿入されると、状態と条件は次のようになります。
接続点が論理的に接続されると、状態と条件は次のようになります。
構成操作中、ボードスロットの状態が disconnected であれば、DR はボードスロットを接続しようとします。さらに、接続操作中に作成されたデバイスツリーをたどります。(DR は、必要であれば Solaris デバイスツリーのノードを作成して、デバイスドライバを接続します。)
CPU が CPU リストに追加され、メモリーは初期化されてシステムメモリープールに追加されます。構成機能が正常に完了すると、CPU とメモリーは使用可能な状態になります。
入出力デバイスの場合は、mount(1M) コマンドと ifconfig(1M) コマンドを実行してからでないと、デバイスを使用できません。
cfgadm を使ってボードをドメインに構成すると、そのボードは自動的に接続され、構成されます。
SC の代わりにドメインを経由してシステムボード上の CPU を構成するには、cfgadm(1M) コマンドを次のように使用します。
# cfgadm -c configure SBx::cpuy |
ここで、x はボード番号 (たとえば、Sun Fire 15K システムでは 0〜17、Sun Fire 12K システムでは 0〜8)、y は CPU 番号 (0〜3) をそれぞれ示します。
メモリーを構成する cfgadm(1M) コマンドの構文は、次のとおりです。
# cfgadm -c configure SBx::memory |
ここで、x はボード番号 (たとえば、Sun Fire 15K システムでは 0〜17、Sun Fire 12K システムでは 0〜8) を示します。メモリーの場合、このコマンドはシステムボードのすべてのメモリーに適用されます。
システムボード上のすべての CPU とメモリーを一括して構成するには、次のコマンドを使用します。
# cfgadm -c configure SBx |
ホットプラグ機能を備えた PCI アダブタを装着している PCI スロットのひとつを構成する場合の cfgadm(1M) コマンドの構文は、次のとおりです。
# cfgadm -c configure pcisch0:e00b1slot1 |
詳細については、PCI アダプタカードのホットプラグ操作を参照してください。
# cfgadm -c configure IOx |
これでシステムはボードに常駐する使用可能なデバイスも認識するため、すべてのデバイスをマウントするか、または用途に合わせて構成できます。
切り離し操作中、DR フレームワークは SC との通信を通じて、システムボードが物理ドメインから削除されるように相互接続をプログラミングします。さらに、構成解除操作に関連するタスクを実行しようとします。
ボードは、電源を切断しなくても切り離された状態になります。ただし、スロットから取り外す前には、ボードの電源を切断して切り離された状態にしておく必要があります。
ボードを切り離す cfgadm(1M) コマンドの構文は、次のとおりです。
# cfgadm -c disconnect SBx |
ここで、x はボード番号 (たとえば、Sun Fire 15K システムでは 0〜17、Sun Fire 12K システムでは 0〜8) を示します。
構成解除操作は、常時メモリーの有無によって 1 つの操作か、異なる 2 つの操作からなります。システムボードが常時メモリーを収容する場合、DR は構成解除操作の前に、そのメモリーの内容を指定されたボードからドメイン内の別のターゲットボード上の利用可能メモリーに移動します。常時メモリーを収容するボードに関する詳細は、常時メモリーと非常時メモリーを参照してください。
Reconfiguration Coordination Manager (RCM) が存在する場合、DR は RCM に DR 操作について通知します。RCM はクライアントアプリケーションに通知し、クライアントアプリケーションはデバイスの使用を停止するなどの予備タスクを実行します。クライアントは準備ができたことを RCM に通知し、RCM はその準備ができたことを DR に通知します。応答に従って、DR は操作を続行するか、または中止してユーザーにエラーを報告します。
構成解除操作中、DR はボードの資源の構成を Solaris オペレーティングシステムから解除して、ボードを切り離された状態にします。
このボードが CPU またはメモリー、あるいはこの両方のホストである場合、DR はそれらを Solaris オペレーティングシステムから削除して、オペレーティングシステムで使用できないようにします。ボードが入出力ボードの場合、DR はデバイスドライバを切り離します。
以下の説明と例は、常時メモリーの構成解除操作を示しています。
次のコーディング例では、ボード 0 の常時メモリーをドメイン内の別のボード (ボード 1) に移動する必要があります。ボード 0 がソースボード、ボード 1 がターゲットボードです。
簡略化するために、CPU 情報はコーディング例から削除されています。ドメインでの構成解除操作は、次の cfgadm(1M) コマンドで開始されます。
# cfgadm -c unconfigure -y SB0::memory & |
まず、ソースボード上の常時メモリーと同じアドレス範囲にあるターゲットボード上のメモリーブロックを削除する必要があります。このフェーズでは、ソースボード、ターゲットボード、およびメモリー接続点が Busy と示されます。このときのステータスは、以下のコマンドを使用して表示できます。
ボード 1 のメモリーが削除されると、unconfigured と示されます。ソースボード上のメモリーは configured のままですが、次の例に示すように引き続き Busy と示されます。
Ap_Id Type Receptacle Occupant Busy SB0 CPU connected configured y SB0::memory memory connected configured y SB1 CPU connected configured y SB1::memory memory connected unconfigured n |
次に、ソースボード上のメモリーの内容がターゲットボードにコピーされます。コピーが完了すると、メモリーの占有状態が切り替わります。ソースボード上のメモリーは unconfigured になり、ターゲットボード上のメモリーが configured になります。この時点では、次の例に示すようにターゲットボードだけが Busy のままです。
Ap_Id Type Receptacle Occupant Busy SB0 CPU connected configured y SB0::memory memory connected unconfigured n SB1 CPU connected configured n SB1::memory memory connected configured n |
プロセス全体が完了すると、ソースボードのメモリーは unconfigured のままで、接続点は次の例に示すように Busy でなくなります。
Ap_Id Type Receptacle Occupant Busy SB0 CPU connected configured n SB0::memory memory connected unconfigured n SB1 CPU connected configured n SB1::memory memory connected configured n |
常時メモリーが移動されて、ソースボードのメモリーは構成解除されています。この時点では、どちらかのボードに対して新しい状態変更操作を開始できます。
この節では、ドメインに常駐し、DR 操作を可能にするソフトウェアコンポーネントについて説明します。ただし、システムプラットフォームの一部の DR コンポーネントについては説明しません。システムコントローラ (SC) に常駐するソフトウェアコンポーネントの説明は、『System Management Services (SMS) Dynamic Reconfiguration ユーザーマニュアル』を参照してください。
ドメイン構成サーバー (DCS) はドメインで実行されるデーモンプロセスであり、最初の遠隔 DR 要求を受け取った時点で、inetd(1M) によって起動されます。DCS の 1 つのインスタンスが各ドメインで実行されます。DCS は、SC で実行されるドメイン構成エージェント (DCA) から DR 要求を受け入れます。DCS は、DR 操作を受け入れると、要求を実行して結果を DCA に返します。DCA に関する詳細は、『System Management Services (SMS) Dynamic Reconfiguration ユーザーマニュアル』を参照してください。
|
注 - inetd.conf ファイルの sun-dr エントリを変更または削除する場合は、ipsecinit.conf ファイルの sun-dr エントリにも同じ変更を行ってください。 |
DR ドライバは、プラットフォーム独立ドライバ dr とプラットフォーム特定モジュール drmach からなります。DR ドライバは、DR 操作を制御できる場合には必ず Solaris オペレーティングシステムの標準機能を使用し、必要に応じてプラットフォーム特定モジュールを呼び出します。DR ドライバは、DR 操作の接続点として使用されるマイナーノードをファイルシステムに作成します。
Reconfiguration Coordination Manager (RCM) は、ドメイン内のリリースに対する DR 操作の同期をとるデーモンプロセスです。RCM デーモンは、汎用アプリケーションプログラムインタフェース (API) を使用して、DR 開始元と RCM クライアントの間で DR 操作の同期をとります。
RCM コンシューマーは、DR 操作を要求する DR 開始元と、DR 要求に応答する DR クライアントからなります。通常、DR 開始元は構成管理コマンド cfgadm(1M) です。ただしこれは、Sun
Management Center などの GUI の場合もあります。
DR は Solaris システムイベントフレームワークを使用して、他のソフトウェアエンティティに対して、DR 操作による変更の発生を通知します。DR は、システムイベントデーモン syseventd に DR イベントを送信して通知し、さらにこのデーモンが DR イベントの加入者にイベントを送信します。システムイベントデーモンについての詳細は、syseventd(1M) マニュアルページを参照してください。
| Sun Fire ハイエンドシステム Dynamic Reconfiguration ユーザーマニュアル | 817-5311-10 |
|
Copyright© 2003, Sun Microsystems, Inc. All rights reserved.