1    パーティションによる負荷の管理

OpenVMS のユーザは,ハードおよびソフト・パーティションをサポートするシステムをさまざまな形で使用しています。 これらのシステムを最も効果的に使用するためには,コンピューティングとアプリケーションに対するユーザのニーズに最適な構成オプションを検討する必要があります。

この章では,ハード・パーティションとソフト・パーティションの使用方法, および,新しい AlphaServer システムでできるだけ効率良くアプリケーションを実行させる RAD (リソース・アフィニティ・ドメイン) に対する OpenVMS サポートについて説明します。

1.1    OpenVMS システムでのハード・パーティションとソフト・パーティションの使用

ハード・パーティショニングとは,ハードウェアで強制されたアクセス・バリアで コンピューティング・リソースを物理的に分離したものです。 ハード・パーティション境界を越えて読み込みや書き込みを行うことはできず, ハード・パーティション同士ではリソースは共用されません。

ソフト・パーティショニングとは,ソフトウェアで制御されたアクセス・バリアでコンピューティング・リソースを分離したものです。 ソフト・パーティション (サブパーティションと呼ぶこともあります) では,複数のオペレーティング・システム間でハードウェア・リソースを共用できます。 ソフト・パーティション境界を越えた読み込みと書き込みのアクセスは, オペレーティング・システムまたはアプリケーションによって制御されます。 OpenVMS Galaxy は,ソフト・パーティショニングの実装です。

新しい AlphaServer ES シリーズまたは GS シリーズのシステムでどのようなパーティション分割を選択するかは, コンピューティング環境とアプリケーションの要件によって決まります。 パーティショニングを計画するときには,アプリケーションに必要なメモリ量と,どのオペレーティング・システムを動作させるかを考慮する必要があります。 パーティショニングをサポートする OpenVMS システムの構成方法を決定するときには, 次の項目を検討します。

1.2    OpenVMS パーティショニングのガイドライン

ハード・パーティショニングは,AlphaServer ES47/ES80/GS1280 および GS80/160/320 システムでのみ利用できます。 AlphaServer ES47/ES80/GS1280 システム上でのパーティションの利用は,GS80/160/320 システムでパーティションを利用するのと同様です。

AlphaServer ES または GS シリーズ・システムでハード・パーティションやソフト・パーティションを使用するかどうかを決定するときには,次の点に注意してください。

注意

OpenVMS Galaxy を使ったコンピューティング環境では,MOP (Maintenance Operations Protocol) ブートはインスタンス 0 でしかサポートされません。

パーティションのセットアップでは,セットアップ規則に従わなければなりません。

QBB ベースのシステムでは,パーティション (ハードまたはソフト) それぞれにコンソール・ラインを持つ必要があります。 システム内の各 QBB はコンソール・ラインを 1 つ持つことができます。 したがって,システムのパーティション (ハードまたはソフト) の最大数は,システムの QBB の数と同じになります。

ハード・パーティションの規則

各ハード・パーティションは,次のものを備えている必要があります。

障害分離性と可用性を最大限に高めるため,ES47/ES80/GS1280 システムでは,システム・ビルディング・ブロック境界でハード・パーティションに分割します。 これは,ES47/ES80 では 2P SBB 境界になり,GS1280 では 8P SBB 境界になります。 システム・ビルディング・ブロック境界でハード・パーティションに分割することで,システム全体で単一点障害がなくなります。 電源と冷却装置も,そのハード・パーティションに含まれています。 プロセッサ間のリンクは遮断されます。 このようにパーティショニングを行うのが最も堅牢です。 1 つの堅牢なハード・パーティション内には複数のシステム・ビルディング・ブロックを含めることができます。

GS1280 システムでは,システム・ビルディング・ブロックをサブシステム・ビルディング・ブロック (SSBB) 単位のハード・パーティションに分割できます。 1 つの 8P SBB を 2P レベルに分割できます。 これらのハード・パーティションは個別に電源が供給され,修理が必要なときにはデュアル CPU モジュールの電源を切ることができます。 このパーティショニングのレベルでは,8P SBB 境界で分割されたシステムが持つ障害分離性や堅牢性はありません。

8P または 2P の SBB レベルでのハード・パーティションでは,ハード・パーティションごとに個別のシリアル・コンソール・ラインがサポートされます。 1 つの 8P SBB を複数のハード・パーティションに分割すると,シリアル・コンソールは同時に 1 つのサブパーティションにしか接続できません。 すべてのサブパーティションのコンソールに同時にアクセスする必要がある場合には,管理用の LAN を使った telnet セッションを使用しなければなりません。 1.2.1 項では,パーティションのセットアップ手順を説明しています。 また,1.3.1 項では,2 つの例を挙げて構成のセットアップ方法を説明しています。

注意

必要なコンソール

ES47/ES80/GS1280 シリーズのハード・パーティション機能では,最低限 V6.6 のコンソール・セットが必要です。 このコンソール・セットは,次の AlphaServer ファームウェアの Web サイトから入手できます。

http://ftp.digital.com/pub/Digital/Alpha/firmware/readme.html
 

この Web サイト・アドレスでは大文字と小文字が区別されることに注意してください。

ソフト・パーティションの規則

各ソフト・パーティションには次のものが含まれている必要があります。

1.2.1    パーティションのセットアップ手順

マネージメント・バックプレーン・モジュール (MBM または SCM) でハード・パーティションおよびソフト・パーティションをセットアップする基本的な手順は,次のとおりです。

  1. ハード・パーティションおよびソフト・パーティションを作成する。

  2. CPU,IO,およびメモリ・リソースをパーティションに割り当てる。

  3. CPU の電源を投入し,コンソールに接続する。

  4. コンソールの環境変数を確認し,必要に応じて再設定する。

この手順を図 1-1 に示します。

図 1-1:  パーティショニングの手順

物理的なハードウェアと所有関係を,システムごとに単一構成ツリーのブランチとして表します。 パーティション (ハードとソフトの両方) は,その構成内のすべてのリソースに対してアクセスできるかどうかを示す所有関係のコンテナと見なすことができます。 図 1-2 の最上位の構成のブランチには,ハードウェアとソフトウェアの両方の構成ツリーが含まれます。

図 1-2:  システム構成ツリー

図 1-3 のハードウェア構成ツリーでは,物理的構成に従って箱の要素が区切られています。 黒い丸は,ツリー中のノードを表します (ノードは個別のコンピュータではなく,ツリー中の接続ポイントです)。 ハードウェアのルートから,ツリーはビルディング・ブロックに分かれます。 各ビルディング・ブロックは,メモリ,I/O,CPU といった主要なシステム・カテゴリに分かれます。 構成ツリーの下位のレベル,たとえば I/O の中は,システム上の個別のデバイスに分かれます。 ツリーの各ノードは,親,兄弟,子,所有関係といった定義を持っています。

図 1-3:  ハードウェア構成ツリー

1 つのパーティションの範囲は必ず 1 つの枝の部分で,その上下部分を含みますが,枝にまたがることはできません。 図 1-4 に示すように,ソフト・パーティションは,常にツリーを上にたどって利用できるリソースを探します。 ハード・パーティションは,その下のすべてのノードで利用できるように割り当てられたリソースを所有します。

一般に,オペレーティング・システムの特定のインスタンスで使われるリソースは,構成ツリー中でそのパーティションを表すソフト・パーティションが所有します。 1 つのハード・パーティション内の複数のインスタンスで協調的なプッシュ・モデル使うことで,あるインスタンスが所有しているリソースは奪われることはなく,譲り渡すことだけが可能となります。 ツリー上で上にあるノードが所有するリソースは,協調的に使用したり (たとえば,コミュニティ・レベルでの共用メモリ),ツリーを下にたどって特定のソフト・パーティションに割り当てたり,利用可能になるまで上にたどって複数のソフト・パーティションに割り当てることができます。

ソフト・パーティション間でリソースを直接割り当てることを移動と呼びます。 ソフト・パーティション間で移動できるのは CPU だけです。 パーティショニングでの移動機能は Galaxy 固有の機能ではありません。 CPU は,あるソフト・パーティションから同じハード・パーティション内の他のソフト・パーティションに,ソフト・パーティション間で直接通信を行うことなく,移動できます。 CPU リソースの管理は,すべて OpenVMS の DCL コマンド SET/STOP CPU で行います。

注意

ES47/ES80/GS1280 システムでの移動に関する制限事項 IO が接続されている CPU を移動することはできません。 IO が接続されているか確認するには,実際の構成で CPU に接続されているケーブルを確認するか,MBM の show partition の出力で判断します。 この出力の IOPs セクションで,IO が接続されている CPU は破線で示されます。 CPU ID は,show partition の出力の CPUs セクション内の対応する PID です (1.3.1 項 の例を参照してください)。

図 1-4:  ソフトウェア構成のツリー

1.3    AlphaServer ES47/ES80/GS1280 でのパーティショニング

1.3.1    ハード・パーティションの構成例

以下の例では,ES47/ES80/GS1280 システムでのハード・パーティションのセットアップを示します。 GCM (Graphical Configuration Manager) を使って,パーティション分割された構成の表示と管理を行う方法については,本書の GCM の章を参照してください。 ソフト・パーティションのセットアップについては,第 10 章を参照してください。

次の例では,32 基のプロセッサを搭載したシステムで,3 つのハード・パーティションをセットアップしています。 パーティションのうち 2 つは,それぞれ 8 基のプロセッサを持ち,もう 1 つのパーティションは 16 基のプロセッサを持っています。 パーティションは 8P SBB 境界に割り当てられます。

サーバ管理のコマンド行インタフェース (CLI) については,次の場所にあるリファレンス・マニュアルを参照してください。

http://mediadocs.mro.cpqcorp.net/doc_library/GS1280/ServerMgnt/CLI_Reference.pdf

ハード・パーティションとソフト・パーティションの名前は,最大で 19 文字までです (英数字と下線のみ)。

注意

サーバ管理の CLI では,大文字と小文字が区別されます。

この例では,コンソールは telnet ポート 323,324,および 325 でアクセスできます。 ハード・パーティションは part0,part1,および part2 という名前にし,それぞれデフォルトで 255 基の CPU で作成します。 サブパーティションの種別は soft (ソフト・パーティション) です。 その後,CPU と IO リソースを各パーティションに割り当てます。 assign component コマンドでは,SBB 全体をコンポーネントに割り当てます。 この例では,キャビネット内の各ドローワには 8 基のプロセッサが搭載されています。

これらコマンドに対する変更点については,前述の CLI_Reference.pdf マニュアルを参照してください。

Welcome - GS1280 Server Manager - T2.1-5
MBM> create partition -hp part0 255 soft
MBM> create partition -hp part1 255 soft
MBM> create partition -hp part2 255 soft
MBM> assign component -hp part0 -cabinet 0 -drawer 0 sbb
MBM> assign component -hp part1 -cabinet 0 -drawer 1 sbb
MBM> assign component -hp part2 -cabinet 0 -drawer 2 sbb
MBM> assign component -hp part2 -cabinet 0 -drawer 3 sbb
MBM> show partition
-----------------------------------------------------------------
 

Hard Partition : HP Name = part0, HP No.= 0, SP count = 2
Attributes     : max CPUs = 16, SP type = soft, Non-stripe
Physical Memory: 16384MB (16.000GB)
 Community Memory: 0MB (0.000GB)
 Sub Partition: HP Name = part0, HP No.= 0
                SP Name = Default_SP, SP No.= 0
                State = Not Running, Telnet port = 323
 Assigned Memory: unspecified
 

 CPUs:
 
     Cab  Drw  CPU   (NS,EW)   PID    Type
      0    0    0    ( 0,0 )     0    Non-primary
      0    0    2    ( 0,1 )     2    Non-primary
      0    0    4    ( 0,2 )     4    Non-primary
      0    0    6    ( 0,3 )     6    Non-primary
      0    0    1    ( 1,0 )     1    Non-primary
      0    0    3    ( 1,1 )     3    Non-primary
      0    0    5    ( 1,2 )     5    Non-primary
      0    0    7    ( 1,3 )     7    Non-primary
 IOPs:
 

            SBB                          PCI Drawer
     Cab  Drw  IOP   (NS,EW)           Cab  Drw  IOR
      0    0    0    ( 0,0 ) ---------  2    4    0
      0    0    2    ( 0,1 )
      0    0    4    ( 0,2 )
      0    0    6    ( 0,3 )
      0    0    1    ( 1,0 )
      0    0    3    ( 1,1 )
      0    0    5    ( 1,2 )
      0    0    7    ( 1,3 )
 Sub Partition: HP Name = part0, HP No.= 0
                SP Name = Free_Pool, SP No.= 255
                State = Not Running
  Free Memory: 0MB (0.000GB)
  CPUs: None
  IOPs: None
-----------------------------------------------------------------
Hard Partition : HP Name = part1, HP No.= 1, SP count = 2
Attributes     : max CPUs = 16, SP type = soft, Non-stripe
Physical Memory: 16384MB (16.000GB)
 
 Community Memory: 0MB (0.000GB)
 Sub Partition: HP Name = part1, HP No.= 1
                SP Name = Default_SP, SP No. = 0
                 State = Not Running, Telnet port = 324
 

 Assigned Memory: unspecified
 

 CPUs:
 
     Cab  Drw  CPU   (NS,EW)   PID    Type
      0    0    0    ( 2,0 )     0    Non-primary
      0    0    2    ( 2,1 )     2    Non-primary
      0    0    4    ( 2,2 )     4    Non-primary
      0    0    6    ( 2,3 )     6    Non-primary
      0    0    1    ( 3,0 )     1    Non-primary
      0    0    3    ( 3,1 )     3    Non-primary
      0    0    5    ( 3,2 )     5    Non-primary
      0    0    7    ( 3,3 )     7    Non-primary
 IOPs:
 

            SBB                          PCI Drawer
     Cab  Drw  IOP   (NS,EW)           Cab  Drw  IOR
      0    1    0    ( 2,0 ) ---------  2    5    0
      0    1    2    ( 2,1 )
      0    1    4    ( 2,2 )
      0    1    6    ( 2,3 )
      0    1    1    ( 3,0 )
      0    1    3    ( 3,1 )
      0    1    5    ( 3,2 )
      0    1    7    ( 3,3 )
 

 Sub Partition: HP Name = part1, HP No.= 1
                SP Name = Free_Pool, SP No. = 255
                State = Not Running
 Free Memory: 0MB (0.000GB)
 CPUs: None
 IOPs: None
-----------------------------------------------------------------    
 

Hard Partition : HP Name = part2, HP No.= 2, SP count = 2
Attributes     : max CPUs = 16, SP type = soft, Non-stripe
Physical Memory: 36864MB (36.000GB)
 Community Memory: 0MB (0.000GB)
 Sub Partition: HP Name = part2, HP No.= 2
                SP Name = Default_SP, SP No.= 0
                State = Not Running, Telnet port = 325
 Assigned Memory: unspecified
 CPUs:
     Cab  Drw  CPU   (NS,EW)   PID    Type
      0    2    0    ( 0,4 )     0    Non-primary
      0    2    2    ( 0,5 )     2    Non-primary
      0    2    4    ( 0,6 )     4    Non-primary
      0    2    6    ( 0,7 )     6    Non-primary
      0    2    1    ( 1,4 )     1    Non-primary
      0    2    3    ( 1,5 )     3    Non-primary
      0    2    5    ( 1,6 )     5    Non-primary
      0    2    7    ( 1,7 )     7    Non-primary
      0    3    0    ( 2,4 )     8    Non-primary
      0    3    2    ( 2,5 )    10    Non-primary
      0    3    4    ( 2,6 )    12    Non-primary
      0    3    6    ( 2,7 )    14    Non-primary
      0    3    1    ( 3,4 )     9    Non-primary
      0    3    3    ( 3,5 )    11    Non-primary
      0    3    5    ( 3,6 )    13    Non-primary
      0    3    7    ( 3,7 )    15    Non-primary
 IOPs:
            SBB                          PCI Drawer
    Cab  Drw  IOP   (NS,EW)           Cab  Drw  IOR
     0    2    0    ( 0,4 ) ---------  2    6    0
     0    2    2    ( 0,5 )
     0    2    4    ( 0,6 )
     0    2    6    ( 0,7 )
     0    2    1    ( 1,4 )
     0    2    3    ( 1,5 )
     0    2    5    ( 1,6 )
     0    2    7    ( 1,7 )
     0    3    0    ( 2,4 ) ---------  2    7    0
     0    3    2    ( 2,5 ) 
     0    3    4    ( 2,6 )
     0    3    6    ( 2,7 )
     0    3    1    ( 3,4 )
     0    3    3    ( 3,5 )
     0    3    5    ( 3,6 )
     0    3    7    ( 3,7 )
Sub Partition: HP Name = part2, HP No.= 2
               SP Name = Free_Pool, SP No.= 255
               State = Not Running
 Free Memory: 0MB (0.000GB)
 CPUs: None
 IOPs: None
MBM> save partition
 

この後システムの電源が投入され,診断が実行されます。

MBM> power on -all
[2003/04/16 08:05:31]
~PCO-I-(pco_04) Powering on partition. HP: part0
[2003/04/16 08:05:32]
~PCO-I-(pco_03) Powering on partition. HP: part1
[2003/04/16 08:05:32]
~PCO-I-(pco_01) Powering on partition. HP: part2
[2003/04/16 08:05:51]
~PCO-I-(pco_04) Running diagnostics on HP: part0
[2003/04/16 08:05:55]
~PCO-I-(pco_03) Running diagnostics on HP: part1
[2003/04/16 08:06:00]
~PCO-I-(pco_01) Running diagnostics on HP: part2
[2003/04/16 08:06:50]
~PCO-I-(pco_04) Diagnostics completed on HP: part0
[2003/04/16 08:06:50]
~PCO-I-(pco_04) HP:part0 SP:Default_SP Primary is NS:0 EW:0
 which is cab:00 drw:0 cpu:0 [2003/04/16 08:06:51]
~PCO-I-(pco_04) Loading SRM on Primary for HP: part0,
 SP: Default_SP. [2003/04/16 08:06:54]
~PCO-I-(pco_03) Diagnostics completed on HP: part1 
2003/04/16 08:06:54]
~PCO-I-(pco_03) HP:part1 SP:Default_SP Primary is NS:2 EW:0
 which is cab:00 drw:1 cpu:0 [2003/04/16 08:06:54]
~PCO-I-(pco_03) Loading SRM on Primary for HP: part1,
 SP: Default_SP. [2003/04/16 08:06:55]
~PCO-I-(pco_04) Powered On HP:part0
[2003/04/16 08:06:59]
~PCO-I-(pco_03) Powered On HP:part1
[2003/04/16 08:07:24]
~PCO-I-(pco_01) Diagnostics completed on HP: part2
[2003/04/16 08:07:25]
~PCO-I-(pco_01) HP:part2 SP:Default_SP Primary is NS:0 EW:4
 which is cab:00 drw:2 cpu:0 [2003/04/16 08:07:25]
~PCO-I-(pco_01) Loading SRM on Primary for HP: part2,
 SP: Default_SP. [2003/04/16 08:07:29]
~PCO-I-(pco_01) Powered On HP:part2
MBM>
 

1.4    AlphaServer GS80/160/320 でのパーティショニング

ハード・パーティションは,次の要素を必要とします。

これ以降の項では,次の 3 つのハード・パーティション構成の例を説明します。

ここで説明したパーティショニング手順の詳細については, 『AlphaServer GS80/160/320 Firmware Reference Manual』 を参照してください。

1.4.1    ハード・パーティションの構成例 1

図 1-5 は, 4 つの QBB を使って 4 つのハード・パーティションを構成するものです。 それぞれのハード・パーティションには 1 つの QBB があります。

図 1-5:  構成例 1

2 つのハード・パーティションで AlphaServer GS160 システムを構成するには, 次の一連の SCM コマンドを入力します。

SCM コンソールから,hp NVRAM 変数の次の設定を入力します。 値はビット・マスクです。

SCM_E0> power off -all
 
SCM_E0> set hp_count 4
SCM_E0> set hp_qbb_mask0 1       
SCM_E0> set hp_qbb_mask1 2  
SCM_E0> set hp_qbb_mask2 4
SCM_E0> set hp_qbb_mask3 8
SCM_E0> set hp_qbb_mask4 0
SCM_E0> set hp_qbb_mask5 0
SCM_E0> set hp_qbb_mask6 0
SCM_E0> set hp_qbb_mask7 0
 
SCM_E0> power on -all
 
 

また,ハード・パーティションは電源を個別にオンまたはオフにできます。 たとえば,この構成を使って,次のように入力することもできます。

SCM_E0> power off -all
SCM_E0> set hp_count 4
SCM_E0> set hp_qbb_mask0 1
SCM_E0> set hp_qbb_mask1 2  
SCM_E0> set hp_qbb_mask2 4
SCM_E0> set hp_qbb_mask3 8
SCM_E0> set hp_qbb_mask4 0
SCM_E0> set hp_qbb_mask5 0
SCM_E0> set hp_qbb_mask6 0
SCM_E0> set hp_qbb_mask7 0
SCM_E0> power on -partition 0
SCM_E0> power on -partition 1
SCM_E0> power on -partition 2
SCM_E0> power on -partition 3
 
 

各ハード・パーティションの電源投入フェーズ中に, パーティションがどのようにオンラインになるかを示す状態情報が表示されます。 この情報をよく観察し,処理中に障害が何も発生しないことを確認してください。

ハード・パーティションがオンラインになると, そのハード・パーティションのコンソール・デバイスでの作業を開始できます。 また,NVRAM 変数 AUTO_QUIT_SCM の設定に応じて, それぞれのハード・パーティションのコンソールが,SCM または SRM のどちらのコンソール・モードでもオンラインになることに注意してください。

ハード・パーティションのそれぞれのコンソールから SRM コンソールに入ると, そのハード・パーティションに固有のコンソール変数を設定できます。 その後,標準の OpenVMS の手順に従って, それぞれのハード・パーティションで OpenVMS をブートします。 次の例を参照してください。

OpenVMS における典型的なハード・パーティション 0 SRM コンソールの設定:

P00>>>show bootdef_dev                  
bootdef_dev             dkb0.0.0.3.0    
P00>>>show boot_osflags
boot_osflags            0,0            
P00>>>show os_type
os_type                 OpenVMS         
 

OpenVMS における典型的なハード・パーティション 1 SRM コンソールの設定:

P00>>>show bootdef_dev
bootdef_dev             dkb0.0.0.3.0
P00>>>show boot_osflags
boot_osflags            1,0
P00>>>show os_type
os_type                 OpenVMS
 

OpenVMS における典型的なハード・パーティション 2 SRM コンソールの設定:

P00>>>show bootdef_dev
bootdef_dev             dkb0.0.0.3.0
P00>>>show boot_osflags
boot_osflags            2,1
P00>>>show os_type
os_type                 OpenVMS
 

Tru64 UNIX における典型的なハード・パーティション 3 SRM コンソールの設定:

P00>>>show bootdef_dev
bootdef_dev             dka0.0.0.1.16
P00>>>show boot_osflags
boot_osflags            A
P00>>>show os_type
os_type                 UNIX
 

1.4.2    ハード・パーティションの構成例 2

図 1-6 は, 4 つの QBB を使って 2 つのハード・パーティションを構成するものです。 それぞれのハード・パーティションには 2 つの QBB があります。

図 1-6:  構成例 2

2 つのハード・パーティションで AlphaServer GS160 を構成するには, 次の一連の SCM コマンドを実行します。

SCM コンソールから,hp NVRAM 変数の次の設定を入力します。

SCM_E0> power off -all
 
SCM_E0> set hp_count 2
SCM_E0> set hp_qbb_mask0 3
SCM_E0> set hp_qbb_mask1 c
SCM_E0> set hp_qbb_mask2 0
SCM_E0> set hp_qbb_mask3 0
SCM_E0> set hp_qbb_mask4 0
SCM_E0> set hp_qbb_mask5 0
SCM_E0> set hp_qbb_mask6 0
SCM_E0> set hp_qbb_mask7 0
 
SCM_E0> power on -all
 
 

ハード・パーティションがオンラインになると, そのハード・パーティションのコンソール・デバイスでの作業を開始できます。

それぞれのハード・パーティションのコンソールから, 構成例 1 と同様の手順で SRM コンソールに入り, そのハード・パーティションに固有のコンソール変数を構成してから, それぞれのハード・パーティションで OpenVMS をブートします。

1.4.3    ハード・パーティションの構成例 3

構成例 2 と同様,図 1-7 は 4 つの QBB を使って 2 つのハード・パーティションを構成するものです。 唯一の違いは,それぞれのハード・パーティションの QBB の数が異なることです。

図 1-7:  構成例 3

AlphaServer GS160 システムを構成するには,次の一連の SCM コマンドを実行します。

SCM コンソールから,hp NVRAM 変数の次の設定を入力します。

SCM_E0> power off -all
 
SCM_E0> set hp_count 2
SCM_E0> set hp_qbb_mask0 7
SCM_E0> set hp_qbb_mask1 8
SCM_E0> set hp_qbb_mask2 0
SCM_E0> set hp_qbb_mask3 0
SCM_E0> set hp_qbb_mask4 0
SCM_E0> set hp_qbb_mask5 0
SCM_E0> set hp_qbb_mask6 0
SCM_E0> set hp_qbb_mask7 0
 
SCM_E0> power on -all
 
 

他の例と同様,ハード・パーティションがオンラインになると, そのハード・パーティションのコンソール・デバイスでの作業を開始できます。

それぞれのハード・パーティションのコンソールから, 構成例 1 と同様の手順で SRM コンソールに入り, そのハード・パーティション固有の変数を構成して, それぞれのハード・パーティションで OpenVMS をブートします。

1.4.4    AlphaServer GS80/160/320 システムでのコンソール・ファームウェアの更新

ハード・パーティション分割されたシステムで SRM コンソール・ファームウェアを更新するには, それぞれのハード・パーティションに対して個別に更新を行う必要があります。 各パーティション上の全ファームウェアを一度にアップデートする方法はありません。

1.5    OpenVMS Galaxy サポート

OpenVMS Galaxy ソフトウェアは,共用メモリを通してオペレーティング・システムのインスタンスを制御し,複数のソフト・パーティション内のインスタンス間でリソース共有関係を実現します。 複数の独立したオペレーティング・システムのインスタンスは,Galaxy なしでも複数のソフト・パーティションで動作できます。 OpenVMS Galaxy の概念についての詳細は,第 2 章を参照してください。 複数のソフト・パーティションを作成するには,使用するハードウェアに応じて,第 4 章〜第 10 章に示す Galaxy 関連の手順に従ってください。

構成ツリーにより,各ハード・パーティション内でツリーの上下にリソースを操作できるようになります。 ツリーは物理的な接続とリソースの所有関係を定義します。 ハードウェア・リソースには,いくつもあるレベルのどれかのレベルで所有関係を割り当てることができますが,リソースを割り当てて使用するのは 1 つのインスタンスです。 インスタンスとは,ソフト・パーティション内で動作する 1 つのオペレーティング・システムのことです。

システム・リソースはソフト・パーティションが管理します。 CPU はソフト・パーティションによって所有されている場合にのみ使用され,そのパーティションで動作するインスタンスにより操作されます。 ただし,CPU は構成ツリーの上位レベルが所有することもできます。 この場合,どのインスタンスからも平等に利用できるようになります。 プラットフォーム・ボックスに電源を投入する前にブートの所有権が設定されておらず,CPU モジュールが後からシステムに追加された場合には,その CPU は追加されたハード・パーティションが所有することになり,そのハード・パーティション内の任意のソフト・パーティションにプログラム的に割り当てることができます (ES47/ES80/GS1280 では,コンポーネントのホット・スワップはサポートされません)。

オペレーティング・システムのインスタンスのどれかがブートするとすぐに,そのインスタンスが割り当てられているソフト・パーティションがインスタンスのすべてのリソースを排他的に所有し,その状態特性はそのインスタンスだけが操作できるようになります。 そのため,たとえ今は CPU がなかったとしても,使うことになった場合に備え,電源投入時の CPU の初期割り当てを検討し,リソースが最適に配分されるようにしておくのは重要なことです。

1 つのハード・パーティション内に複数のソフト・パーティションを作成するには,前述のように標準的なパーティショニング手順を使用して,各ソフト・パーティションでインスタンスが動作するような Galaxy 構成を作成します。 図 1-8 は,Galaxy インスタンス内でどのようにメモリが使われるかを示します。 各ソフト・パーティションには,最低限 OpenVMS 用のメモリが必要です。

図 1-8:  メモリの使われ方

Galaxy ID はハード・パーティションの内部にあり,そのハード・パーティションの範囲で同じになります。 つまり,たとえば,2 つのハード・パーティションがあって,両方で Galaxy を動かすと,それぞれの Galaxy が固有の Galaxy ID を持つことになります。 ネットワーク管理ツールを使うときにはこれを考慮してください。 2 つの Galaxy ID があると,ネットワーク管理ツールは 2 つの Galaxy 環境を参照します。

図 1-9 では,4 つのハード・パーティション (0, 1, 2, 3) を示しており,各パーティションには hp0 のような一意の名前がついています。 ハード・パーティション 0 には,一番左の sp1 と sp0の 2 つのソフト・パーティションを含む Galaxy があります。 他の各ハード・パーティションにも Galaxy があります。 ハード・パーティションで Galaxy が作成されておらず,Galaxy に参加もしていない場合には,複数の独立したオペレーティング・システムのインスタンスができることになります。 どのソフト・パーティションでも,オペレーティング・システムのインスタンスを 1 つ動作させることができます。 Galaxy が使用する共用メモリはコミュニティが所有しているため,コミュニティごとに Galaxy が 1 つ存在します。 これにより,Galaxy に属するすべてのインスタンスから共用メモリを参照したりアクセスしたりできるようになります。 コミュニティ・ノードの下のソフト・パーティションで動作するすべてのインスタンスは,その Galaxy に参加する資格があります。 メンバ・ノードは Galaxy によって制御される共有リソースを利用できます。 独立したインスタンスも CPU の割り当てと移動はできますが,共用メモリを利用できるのは Galaxy のメンバだけです。

コミュニティは,ハード・パーティションごとに 1 つしか存在できません。

図 1-9:  構成ツリーで表したソフト・パーティショニング

1.6    RAD (リソース・アフィニティ・ドメイン) に対する OpenVMS アプリケーション・サポート

新しい AlphaServer GS シリーズ・システムには大量の物理メモリがあるので, 非常に大きなデータベースを完全にメモリ内に入れることができます。 AlphaServer の NUMA (ノンユニフォーム・メモリ・アクセス) システム・アーキテクチャが, この大量のメモリを効率的にアクセスするための帯域幅を提供します。NUMA は, 物理メモリへのアクセス時間がすべての CPU で同じではないシステムの属性です。

OpenVMS エンジニアリング・グループは,OpenVMS Alpha バージョン 7.2-1H1 で, OpenVMS メモリ管理とプロセス・スケジューリングを NUMA 対応にしました。この機能 (RAD へのアプリケーション・サポート) によって, 複数のビルディング・ブロック上の単一の OpenVMS インスタンスで実行されるアプリケーションは NUMA 環境でできるだけ効率的に実行できるようになります。

オペレーティング・システムは,ハードウェアを RAD (リソース・アフィニティ・ドメイン) 群として扱います。 RAD とは,共通のアクセス特性を持つ一連のハードウェア・コンポーネント (CPU,メモリ,I/O) のことです。AlphaServer GS80/160/320 システムでは, RAD は QBB (quad building block) に相当します。 AlphaServer ES47/ES80/GS1280 システムでは,RAD は 2 プロセッサの CPU ボードに相当します。 CPU が同一の RAD 内のメモリを参照する速度は, 別の RAD 内のメモリを参照する速度より最大で約 3 倍速くなります。 このため,一部のプロセスにのみ常に利点を偏って提供しないように, コードの実行とメモリの参照をできるだけ同一の RAD 内に留めることが重要になります。 良い配置が良い性能の鍵になりますが, 公平さが重要なときにはできるだけ公平にしなければなりません。

OpenVMS スケジューラとメモリ管理サブシステムは,ともに次のようにして可能な限り最高の配置を行います。

OpenVMS RAD アプリケーション・プログラミング・インタフェースの 使用方法についての詳細は,第 3 章 を参照してください。