 |
≫ |
|
|
|
OpenVMS のユーザは，ハードおよびソフト・パーティションをサポートするシステムをさまざまな形で使用しています。
これらのシステムを最も効果的に使用するためには，コンピューティングとアプリケーションに対するユーザのニーズに最適な構成オプションを検討する必要があります。
この章では，ハード・パーティションとソフト・パーティションの使用方法，
および，新しい AlphaServer システムでできるだけ効率良くアプリケーションを実行させる RAD (リソース・アフィニティ・ドメイン) に対する OpenVMS サポートについて説明します。
ハード・パーティショニングとは，ハードウェアで強制されたアクセス・バリアで
コンピューティング・リソースを物理的に分離したものです。
ハード・パーティション境界を越えて読み込みや書き込みを行うことはできず，
ハード・パーティション同士ではリソースは共用されません。
ソフト・パーティショニングとは，ソフトウェアで制御されたアクセス・バリアでコンピューティング・リソースを分離したものです。
ソフト・パーティション (サブパーティションと呼ぶこともあります) では，複数のオペレーティング・システム間でハードウェア・リソースを共用できます。
ソフト・パーティション境界を越えた読み込みと書き込みのアクセスは，
オペレーティング・システムまたはアプリケーションによって制御されます。
OpenVMS Galaxy は，ソフト・パーティショニングの実装です。
新しい AlphaServer ES シリーズまたは GS シリーズのシステムでどのようなパーティション分割を選択するかは，
コンピューティング環境とアプリケーションの要件によって決まります。
パーティショニングを計画するときには，アプリケーションに必要なメモリ量と，どのオペレーティング・システムを動作させるかを考慮する必要があります。
パーティショニングをサポートする OpenVMS システムの構成方法を決定するときには，
次の項目を検討します。
-
-
-
パーティションのサイズをどの程度小さくできるか
複数のハード・パーティションを使用することで，パーティション間でのハードウェア・セキュリティが最も高くなります。
ハード・パーティション上で 1 つのソフト・パーティションを動作させたときには，専用のマシンで動作しているのと同等になります。
1 つのハード・パーティション上で複数のソフト・パーティションを動作させると，CPU やメモリなどのリソースが共用でき，性能面でメリットがあります。
ハード・パーティショニングは，AlphaServer ES47/ES80/GS1280 および GS80/160/320 システムでのみ利用できます。
AlphaServer ES47/ES80/GS1280 システム上でのパーティションの利用は，GS80/160/320 システムでパーティションを利用するのと同様です。 AlphaServer ES または GS シリーズ・システムでハード・パーティションやソフト・パーティションを使用するかどうかを決定するときには，次の点に注意してください。
-
AlphaServer GS80/160/320 では，各パーティション (ハードまたはソフト) は，それぞれコンソール・ラインを持っている必要があります。
AlphaServer ES47/ES80 および GS1280 システムでは，コンソールへのネットワーク接続または直接アクセスが必要です。
AlphaServer GS80/160/320 では，システムの QBB ごとにコンソール・ラインを 1 つずつ持つことができます。
-
1 つのハード・パーティションには，複数のソフト・パーティションを作成できます。
-
ライセンシング・ポリシの例として，AlphaServer ES または GS シリーズのシステム全体でクラスタ・ライセンスは 1 つしか必要ありません。
インスタンスがいくつあり，それが内部的または外部的にどのようにクラスタ接続されるかには関係しません。
ライセンスについては，本書の 付録 C 「ライセンスのインストール」 と，ライセンシング・ポリシ自体を参照してください。
-
ハード・パーティションは，クォド・ビルディング・ブロック (QBB) またはシステム・ビルディング・ブロック (SBB) のビルディング・ブロック境界に作成します。
GS80/160/320 システムでは QBB が使われ，ES47/ES80/GS1280 システムでは SBB が使われます。
1 つのハード・パーティションには複数の SBB または QBB を含めることができます。
可用性を高めるため，ハード・パーティションは SBB 境界に作成することをお勧めします。
1 つのパーティションに 32 個より多くのプロセッサを含めることはできません。
サブシステム・ビルディング・ブロック (SSBB) は，GS1280 でのみ使用できます。
GS1280 の SSBB は，8P ビルディング・ブロックの中の 2P ビルディング・ブロックです。
AlphaServer ES47/ES80 システムでは，2 プロセッサ (2P) の SBB が使われ，GS1280 では 8 プロセッサ (8P) の SBB が使われます。
2P SBB には I/O が含まれますが，8P SBB では，外部の I/O 接続を準備する必要があります。
SSBB と SBB はどちらも，ハード・パーティションの障害分離のために使用できます。
2 種類の SBB とそのバリエーションについては，表 1-1 「システム・ビルディング・ブロック」 を参照してください。 -
ソフト・パーティションはビルディング・ブロック境界に置く必要はありません。
表 1-1 システム・ビルディング・ブロック システム | SBB の種類 | モデル | ハード・パーティションの最大数 |
|---|
| ES47/ES80 | 2P (2x1) | 2 | 1 |
| | 2P (2x2) | 4 | 2 |
| ES80 | 2P (2x3) | 6 | 3 |
| | 2P (2x4) | 8 | 4 |
| GS1280 | 8P (8x1) | 8 | 4 - 2P SSBB 使用時 |
| | 8P (8x2) | 16 | 8 - 2P SSBB 使用時 |
| | 8P (8x1) | 8 | 1 - 8P SBB 使用時 |
| | 8P (8x2) | 16 | 2 - 8P SBB 使用時 |
| 8P (8x4) | 32 | 4 - 8P SBB 使用時 |
パーティションのセットアップでは，セットアップ規則に従わなければなりません。 QBB ベースのシステムでは，パーティション (ハードまたはソフト) それぞれにコンソール・ラインを持つ必要があります。
システム内の各 QBB はコンソール・ラインを 1 つ持つことができます。
したがって，システムのパーティション (ハードまたはソフト) の最大数は，システムの QBB の数と同じになります。
ハード・パーティションの規則 各ハード・パーティションは，次のものを備えている必要があります。
-
マネージメント・バックプレーン・モジュール (MBM) または telnet によるコンソールへのアクセス -
パーティションごとに 1 つの I/O ドローワ (ES47/ES80 では 内部ドローワでよい)。 -
単一点障害を避けるため，ビルディング・ブロック境界で分割する必要があります。
障害分離性と可用性を最大限に高めるため，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 つの例を挙げて構成のセットアップ方法を説明しています。 ソフト・パーティションの規則 各ソフト・パーティションには次のものが含まれている必要があります。
-
MBM または telnet を使ったコンソールへのアクセス -
パーティションごとに 1 つの I/O ドローワ (ES47/ES80 では内部ドローワでよい) -
-
オペレーティング・システムとアプリケーションで使用するプライベート・メモリと共用メモリ。
共用メモリは独立したインスタンスには不要だが，共用メモリを使うアプリケーションには必要
1.2.1 パーティションのセットアップ手順 | |
マネージメント・バックプレーン・モジュール (MBM または SCM) でハード・パーティションおよびソフト・パーティションをセットアップする基本的な手順は，次のとおりです。
-
ハード・パーティションおよびソフト・パーティションを作成する。 -
CPU，IO，およびメモリ・リソースをパーティションに割り当てる。 -
CPU の電源を投入し，コンソールに接続する。 -
コンソールの環境変数を確認し，必要に応じて再設定する。
この手順を図 1-1 「パーティショニングの手順」 に示します。
物理的なハードウェアと所有関係を，システムごとに単一構成ツリーのブランチとして表します。
パーティション (ハードとソフトの両方) は，その構成内のすべてのリソースに対してアクセスできるかどうかを示す所有関係のコンテナと見なすことができます。
図 1-2 「システム構成ツリー」 の最上位の構成のブランチには，ハードウェアとソフトウェアの両方の構成ツリーが含まれます。
図 1-3 「ハードウェア構成ツリー」 のハードウェア構成ツリーでは，物理的構成に従って箱の要素が区切られています。
黒い丸は，ツリー中のノードを表します (ノードは個別のコンピュータではなく，ツリー中の接続ポイントです)。
ハードウェアのルートから，ツリーはビルディング・ブロックに分かれます。
各ビルディング・ブロックは，メモリ，I/O，CPU といった主要なシステム・カテゴリに分かれます。
構成ツリーの下位のレベル，たとえば I/O の中は，システム上の個別のデバイスに分かれます。
ツリーの各ノードは，親，兄弟，子，所有関係といった定義を持っています。
1 つのパーティションの範囲は必ず 1 つの枝の部分で，その上下部分を含みますが，枝にまたがることはできません。
図 1-4 「ソフトウェア構成のツリー」 に示すように，ソフト・パーティションは，常にツリーを上にたどって利用できるリソースを探します。
ハード・パーティションは，その下のすべてのノードで利用できるように割り当てられたリソースを所有します。
一般に，オペレーティング・システムの特定のインスタンスで使われるリソースは，構成ツリー中でそのパーティションを表すソフト・パーティションが所有します。
1 つのハード・パーティション内の複数のインスタンスで協調的なプッシュ・モデル使うことで，あるインスタンスが所有しているリソースは奪われることはなく，譲り渡すことだけが可能となります。
ツリー上で上にあるノードが所有するリソースは，協調的に使用したり (たとえば，コミュニティ・レベルでの共用メモリ)，ツリーを下にたどって特定のソフト・パーティションに割り当てたり，利用可能になるまで上にたどって複数のソフト・パーティションに割り当てることができます。
ソフト・パーティション間でリソースを直接割り当てることを移動と呼びます。
ソフト・パーティション間で移動できるのは CPU だけです。
パーティショニングでの移動機能は Galaxy 固有の機能ではありません。
CPU は，あるソフト・パーティションから同じハード・パーティション内の他のソフト・パーティションに，ソフト・パーティション間で直接通信を行うことなく，移動できます。
CPU リソースの管理は，すべて OpenVMS の DCL コマンド SET/STOP CPU で行います。
1.3.1 ハード・パーティションの構成例 | |
以下の例では，ES47/ES80/GS1280 システムでのハード・パーティションのセットアップを示します。
GCM (Graphical Configuration Manager) を使って，パーティション分割された構成の表示と管理を行う方法については，本書の GCM の章を参照してください。
ソフト・パーティションのセットアップについては，第10章 「AlphaServer ES47/ES80/GS1280 システムでの OpenVMS Galaxy の構築」を参照してください。 次の例では，32 基のプロセッサを搭載したシステムで，3 つのハード・パーティションをセットアップしています。
パーティションのうち 2 つは，それぞれ 8 基のプロセッサを持ち，もう 1 つのパーティションは 16 基のプロセッサを持っています。
パーティションは 8P SBB 境界に割り当てられます。
サーバ管理のコマンド行インタフェース (CLI) については，次の場所にあるリファレンス・マニュアルを参照してください。
http://mediadocs.mro.cpqcorp.net/doc_library/GS1280/ServerMgnt/CLI_Reference.pdf
ハード・パーティションとソフト・パーティションの名前は，最大で 19 文字までです (英数字と下線のみ)。
この例では，コンソールは 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>
|
|
ハード・パーティションは，次の要素を必要とします。
-
パーティションごとの標準 COM1 UART コンソール・ライン
-
-
-
パーティションごとに少なくとも 1 つの CPU モジュール
-
パーティションごとに少なくとも 1 つのメモリ・モジュール
メモリ・オプションは，メモリ帯域幅とメモリ容量に対するアプリケーションの感度，
およびハードウェア・パーティションの数に従って選択してください。
これによって必要なメモリ・ベース・モジュールとアップグレードの数が決まります。
必要な合計容量は，選択される配列のサイズを決定します。
メモリ・モジュールは，2 の倍数で構成してください。
つまり，QBB のベース・モジュールの個数は，0，1，2，4 のいずれかにします。
同様に，アップグレードでも QBB のベース・モジュールの個数は 2 の
倍数である 0，1，2，4 をインストールしてください。
これ以降の項では，次の 3 つのハード・パーティション構成の例を説明します。
-
構成例 1 には 4 つの QBB と 4 つのハード・パーティションがあります。
それぞれのハード・パーティションには 1 つの QBB があります。
-
構成例 2 には 4 つの QBB と 2 つのハード・パーティションがあります。
それぞれのハード・パーティションには 2 つの QBB があります。
-
構成例 3 には 4 つの QBB と 2 つのハード・パーティションがあります。
1 つのパーティションには 1 つの QBB があり，
もう 1 つのパーティションには 3 つの QBB があります。
ここで説明したパーティショニング手順の詳細については，
『AlphaServer GS80/160/320 Firmware Reference Manual』
を参照してください。
1.4.1 ハード・パーティションの構成例 1 | |
図 1-5 「構成例 1」 は，
4 つの QBB を使って 4 つのハード・パーティションを構成するものです。
それぞれのハード・パーティションには 1 つの QBB があります。
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 「構成例 2」 は，
4 つの QBB を使って 2 つのハード・パーティションを構成するものです。
それぞれのハード・パーティションには 2 つの QBB があります。
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 「構成例 3」 は 4 つの QBB を使って 2 つのハード・パーティションを構成するものです。
唯一の違いは，それぞれのハード・パーティションの QBB の数が異なることです。
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 コンソール・ファームウェアを更新するには，
それぞれのハード・パーティションに対して個別に更新を行う必要があります。
各パーティション上の全ファームウェアを一度にアップデートする方法はありません。
OpenVMS Galaxy ソフトウェアは，共用メモリを通してオペレーティング・システムのインスタンスを制御し，複数のソフト・パーティション内のインスタンス間でリソース共有関係を実現します。
複数の独立したオペレーティング・システムのインスタンスは，Galaxy なしでも複数のソフト・パーティションで動作できます。
OpenVMS Galaxy の概念についての詳細は，第2章 「OpenVMS Galaxy の概念」を参照してください。
複数のソフト・パーティションを作成するには，使用するハードウェアに応じて，第 4 章～第 10 章に示す Galaxy 関連の手順に従ってください。
構成ツリーにより，各ハード・パーティション内でツリーの上下にリソースを操作できるようになります。
ツリーは物理的な接続とリソースの所有関係を定義します。
ハードウェア・リソースには，いくつもあるレベルのどれかのレベルで所有関係を割り当てることができますが，リソースを割り当てて使用するのは 1 つのインスタンスです。
インスタンスとは，ソフト・パーティション内で動作する 1 つのオペレーティング・システムのことです。
システム・リソースはソフト・パーティションが管理します。
CPU はソフト・パーティションによって所有されている場合にのみ使用され，そのパーティションで動作するインスタンスにより操作されます。
ただし，CPU は構成ツリーの上位レベルが所有することもできます。
この場合，どのインスタンスからも平等に利用できるようになります。
プラットフォーム・ボックスに電源を投入する前にブートの所有権が設定されておらず，CPU モジュールが後からシステムに追加された場合には，その CPU は追加されたハード・パーティションが所有することになり，そのハード・パーティション内の任意のソフト・パーティションにプログラム的に割り当てることができます (ES47/ES80/GS1280 では，コンポーネントのホット・スワップはサポートされません)。
オペレーティング・システムのインスタンスのどれかがブートするとすぐに，そのインスタンスが割り当てられているソフト・パーティションがインスタンスのすべてのリソースを排他的に所有し，その状態特性はそのインスタンスだけが操作できるようになります。
そのため，たとえ今は CPU がなかったとしても，使うことになった場合に備え，電源投入時の CPU の初期割り当てを検討し，リソースが最適に配分されるようにしておくのは重要なことです。
1 つのハード・パーティション内に複数のソフト・パーティションを作成するには，前述のように標準的なパーティショニング手順を使用して，各ソフト・パーティションでインスタンスが動作するような Galaxy 構成を作成します。
図 1-8 「メモリの使われ方」 は，Galaxy インスタンス内でどのようにメモリが使われるかを示します。
各ソフト・パーティションには，最低限 OpenVMS 用のメモリが必要です。
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 つしか存在できません。 新しい 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 スケジューラとメモリ管理サブシステムは，ともに次のようにして可能な限り最高の配置を行います。
-
各プロセスに優先 RAD または “ホーム” RAD を割り当てる
-
ホーム RAD のメモリからプロセスのプライベート・ページを割り当てる
-
通常はホーム RAD 内の CPU にプロセスをスケジューリングする
-
各 RAD にオペレーティング・システムの読み込み専用コードを複製する
-
-
OpenVMS RAD アプリケーション・プログラミング・インタフェースの
使用方法についての詳細は，第3章 「OpenVMS アプリケーションに対する NUMA の影響」 を参照してください。
|
