| 前へ | 次へ | 目次 | 索引 |
ここ数年，CPU による情報処理能力は，I/O サブシステムによるプロセッサに対するデータ提供能力を越えています。その結果，プロセッサが I/O 処理の終了を待機する時間が増えています。
半導体ディスク (SSD)，DECram，そして RAID レベル 0 は，処理速度と磁気ディスクのアクセス速度のギャップをとりもつテクノロジです。磁気ディスクのパフォーマンスは，シーク待ち時間と回転待ち時間による制約を受けますが，SSD と DECram はメモリを使用するため，即時アクセスが可能です。
RAID レベル 0 は，1 つのファイルを複数のディスク・ボリュームに分散 (または "ストラインピング") するための技術です。その目的は，アクセス頻度の高いファイルをストライプ・セットにパーティション化し，複数のデバイスに保存することにより，1 つのディスクにボトルネックが発生するのを防ぐことです。この技術では，1 つの I/O を多数のディスクで併行処理することができます。
表 10-5 は，ディスク・テクノロジとその機能をまとめたものです。
| ディスク・テクノロジ | 特性 |
|---|---|
| 磁気ディスク | アクセス時間がかかる。
低費用。 複数のインターコネクトで使用可能。 |
| 半導体ディスク | あらゆる I/O サブシステム・デバイス内で最速のアクセス時間。
書き込み頻度が高いファイルの場合に最高のスループット。 複数のインターコネクトで使用可能。 |
| DECram | 中小サイズの I/O 要求で最高のスループット。
揮発性ストレージ領域; 一時読み取り専用ファイルに最適。 Alpha システムや VAX システムで利用可能。 |
| RAID レベル 0 | HSD コントローラ，HSJ コントローラ，および HSG コントローラで使用可能。 |
注意: I/O をスケーリングする最も速い方法は，半導体ディスクや DECram に対して共用直接アクセスする場合です。
10.8.3 読み込み/書き込みの比率
I/O をシャドウ・セットに対して行う場合，アプリケーションの読み込み/書き込みの比率が重要です。シャドウ・セットに対する MSCP は，インターコネクト上でコピーされます。
したがって，100% (100/0) 読み込み処理のアプリケーションでは，シャドウイングにより I/O 処理に複数のパスを利用できるため，ボリューム・シャドウイングの恩典を受けることができます。読み込み/書き込みの比率が 50/50 のアプリケーションでは，さらにインターコネクトが活用されます。これは，書き込み処理では，I/O を各シャドウ・メンバに送信する必要があるからです。最も処理速度の遅い I/O を完了するために必要な時間により，遅延が発生する可能性があります。
I/O 読み込み/書き込みの比率は，DCL コマンド MONITOR IO で知ることができます。
10.8.4 I/O サイズ
I/O パケットごとに，プロセッサとメモリにオーバヘッドが生ずるので，I/O を 1 つのパケットにまとめれば，すべての I/O 処理のオーバヘッドを節約することができます。アプリケーションで使用できるパケット・サイズが大きければ，スループットが高くなります。パケット・サイズが小さいとオーバヘッドが大きくなります。
10.8.5 キャッシュ
キャッシュとは，最新のデータや使用頻度の高いデータを，メモリ，コントローラ，またはディスク内のアクセスしやすい場所に保存する技術です。キャッシュは半導体ディスク，DECram，RAID を補完する技術です。特別なコーディングをしなくてもアプリケーションはキャッシュの利点をそのまま利用できます。キャッシュすると， OpenVMS Cluster システム内で構成要素間の I/O 数が減少し，現在の I/O ボトルネックや潜在的な I/O ボトルネックを緩和できます。
表 10-6 は，3 種類のキャッシュ方式をまとめたものです。
| キャッシュの種類 | 説明 |
|---|---|
| ホスト方式 | ホスト・システムのメモリにキャッシュが常駐。ホストからの I/O をサービス。 |
| コントローラ方式 | ストレージ・コントローラにキャッシュが常駐。すべてのホストにデータをサービス。 |
| ディスク | ディスクに常駐するキャッシュ。 |
ホスト方式のディスク・キャッシュの特長は，コントローラ方式やディスク方式のキャッシュとは異なります。ホスト方式のディスク・キャッシュでは，キャッシュそのものをノード間で共用できません。コントローラ方式やディスク方式のキャッシュは共用できます。これは，共用できるコントローラやディスクにキャッシュがあるためです。
10.8.6 "ホット"・ファイルの管理
"ホット"・ファイルは，システム内でほとんどの処理が発生する場所です。多くの環境でホット・ファイルが存在するのは，全 I/O のおよそ 80% がデータの 20% に集中するためです。つまり， 図 10-24 に示すように，ディスク・ドライブで領域は均等に分散しているのに，転送されるデータの 80% がディスクの 1 個所に集中するためです。
図 10-24 ホット・ファイルの分散
I/O のスケーラビリティを強化するには，管理が不適切だとボトルネックになりかねないホット・ファイルに着目します。この領域の処理は，I/O，MB 単位の転送データ量，キュー深度で表します。
RAID レベル 0 では，1 つのファイルを複数のディスクに分散してホット・ファイルのバランスを調整します。これにより，パフォーマンスに対するホット・ファイルの影響を緩和できます。
ホット・ファイルによる処理の解析には，以下の DCL コマンドを使用します。
ホット状態のディスクやサーバを探すには，MONITOR IO コマンドと MONITOR MSCP コマンドを使用します。
10.8.7 ボリューム・シャドウイング
Volume Shadowing for OpenVMS 製品では，複数のディスクにデータのコピーを作成してアプリケーションとエンド・ユーザに対するデータの可用性を強化します。ボリューム・シャドウイングでは，データの冗長性と可用性が高くなるものの，以下の 2 つのレベルで OpenVMS Cluster I/O に影響が生じることがあります。
| 要因 | 影響 |
|---|---|
| 物理的な距離 | ホスト方式のボリューム・シャドウイングでは， MSCP サーバからサービスを受けるボリュームも含め，OpenVMS Cluster システム内の任意のディスク・ボリュームのシャドウイングが可能です。この機能では，長距離通信が可能ですが，MSCP のオーバヘッドも生じます。たとえば，FDDI を使用する OpenVMS Cluster システムは，25 マイル離れて配置することができます。距離と MSCP の相乗効果により I/O スループットが低下する場合があります。 |
| 読み込み/書き込みの比率 | シャドウイングでは，データが複数のボリュームに書き込まれるので，書き込みの激しいアプリケーションでは，シャドウイングをするソフトウェアは，スループットが低下します。これは最も効率よくデータを取り出せるディスク・メンバを選択するからです。 |
この章では，OpenVMS Cluster をフルに活用するための主なシステム管理の手法について説明します。OpenVMS Cluster の一般的なシステム管理の実践については，『OpenVMS Cluster システム』を参照してください。
この章では，システム・ディスク，クォーラム・ディスク，OpenVMS Cluster 遷移など，システム管理の基本的な概念を理解していることを前提としています。
この章の構成は，以下のとおりです。
OpenVMS Cluster ソフトウェアは，大半のシステム管理のタスクが 1 回で済むため，システム管理者の仕事が軽減されます。このことは，OpenVMS Cluster の全機能を必要とせず，シンプルな構成で対応できるビジネス要件において特にはっきりとした効果が出ます。シンプルな構成は，新しくシステム管理者になった人だけでなく，経験豊かなシステム管理者にとっても魅力的であり，ノードが 3 個から 7 個，ユーザが 20 人から 30 人，ストレージが 100 GB 程度の小規模な OpenVMS Clusterに最適です。
関連項目： シンプルな OpenVMS Cluster 構成の例については， 図 11-1 を参照してください。
さらに複雑な OpenVMS Cluster 構成の場合で，可用性，スケーラビリティ，パフォーマンスを実現するには，高度なシステム管理方法が必要です。
関連項目： 複雑な OpenVMS Cluster 構成の例については， 図 11-3 を参照してください。
システム管理の選択にあたっては，簡潔性と，複雑な OpenVMS Clusterで要求されるその他の管理タスクとの調和を考慮したシステム管理方法を選択してください。
11.2 システム・ディスクの手法
システム・ディスクには，システム・ファイルと環境ファイルが含まれています。
システム・ファイルは，ランタイム・ライブラリなど主に読み込み専用のイメージとコマンド・プロシージャであり，クラスタ規模でアクセスします。
環境ファイルは，個々のユーザに合った環境を作成するためのファイルです。すべての環境ファイルをクラスタ規模でアクセスできるようにすれば共通環境ができます。また，特定の環境ファイルについてアクセスできるユーザやシステムを限定すればマルチ環境になります。
11.2.1 シングル・システム・ディスク
シングル・システム・ディスクと共通環境という簡潔な構成の場合は，システム管理も簡単です。必要なほとんどの作業は 1 回で済みます。また，システム・ファイルと環境ファイルは同じディスクに常駐します。 ページ・ファイルとスワップ・ファイルもシステム・ディスクに常駐します。
図 11-1 は，シングル・システム・ディスクと共通環境の OpenVMS Cluster システムの例です。
図 11-1 シングル・システム・ディスクの共通環境
図 11-1 で示すシンプルな CI OpenVMS Cluster は，シャドウ・システム・ディスクを 1 つ使用しています。このシステム・ディスクには，システム・ファイル，環境ファイル，ページ・ファイル，スワップ・ファイルが常駐します。ここには環境ファイルが 1 セットしかないので，これは共通環境です。
図 11-2 は，共通環境を備えたシンプルな OpenVMS Cluster の別の例です。
図 11-2 シングル・システム・ディスクのシンプルな LAN OpenVMS Cluster
図 11-2 では，6 つのサテライトと 1 つのブート・サーバを Ethernet で接続しています。各サテライトには，専用のページ・ディスクとスワップ・ディスクがあり，これでシステム・ディスクの領域を節約するとともに， Ethernet からのページ・ファイルとスワップ・ファイルの I/O 処理を取り除きます。システム・ディスクからページ・ファイルとスワップ・ファイルを取り除いたことで， OpenVMS Cluster のパフォーマンスが強化できます。
シングル・システム・ディスクの構成で，多くの OpenVMS Cluster 要件に対応できますが，マルチ・システム・ディスクにもいくつかの長所があります。
11.2.2 マルチ・システム・ディスク
Alpha システムと VAX システムの両方を組み込んだ OpenVMS Clusterには， VAX システム・ディスクと Alpha システム・ディスクのマルチ・システム・ディスクが必要です。 表 11-1 で，(アーキテクチャに関係なく) システム管理者が OpenVMS Cluster で複数のシステム・ディスクを必要とする理由を補足説明します。
| 長所 | 説明 |
|---|---|
| 短縮されたブート時間 | 3 つ以上のシステムを同時にブートしようとすると，シングル・システム・ディスクでは，ボトルネックになる可能性があります。
ブート時間は以下の要素によって大きく異なります。
書き込み処理の負荷が高い環境ファイル (SYSUAF.DAT など) がシステム・ディスクにない場合，Volume Shadowing for OpenVMS ソフトウェアは，ディスクの読み込みパフォーマンスの強化に有効です。 |
| 強化されたシステムとアプリケーションのパフォーマンス | 一定以上の使用頻度の各種アプリケーションを搭載した OpenVMS Cluster では，ノードごとにローカル・システム・ディスクを設けるか，システム・ディスクが担当するシステムを少数に限定するとパフォーマンス面で効果的です。長所は，イメージ起動時間が短く，LAN のサービス対象になるファイルが少ない点です。
Alpha ワークステーションは，ローカル・システム・ディスクに適しています。強力な Alpha プロセッサでは，システム・ディスク・アクセス程待たなくてもすむためです。 関連項目： 詳細については， 第 10.7.5 項 を参照してください。 |
| LAN の利用率の削減 | システム・ディスクによる LAN の利用率が下がれば， LAN によるサービス対象のファイルも減ります。LAN セグメントとそのブート・サーバを，セグメント外の不要なトラフィックから分離すれば，LAN パス接続も少なくて済みます。
関連項目： 詳細については， 第 11.2.4 項 を参照してください。 |
| OpenVMS Cluster 可用性の増加 | シングル・システム・ディスクは，単一点障害の要因になる可能性があります。ブート・サーバとシステム・ディスクを増加すれば，シングル・リソースにおける OpenVMS Cluster に対する依存度が下がり，可用性が高くなります。 |
11.2.3 マルチ・システム・ディスク OpenVMS Cluster
図 11-3 のようにシステム・ディスクを配置すると，ブート時間と LAN の利用率を下げることができます。
図 11-3 共通環境におけるマルチ・システム・ディスク
図 11-3 は，マルチ・システム・ディスクの OpenVMS Cluster です。
この構成におけるマルチ・システム・ディスクと，LAN セグメントの分割使用形態は，効率的でタイミングの良いブート・シーケンスを可能にします。
11.2.4 OpenVMS Cluster システムの分割
第 10.7 節 に示すワークステーション・サーバの例で，障害後の OpenVMS Cluster のリブートは比較的簡潔です。これはサーバ当たりのサテライト数が少ないためです。ただし， 図 11-3 に示す大規模な OpenVMS Cluster 構成のリブートは慎重に計画する必要があります。この項で説明する OpenVMS Cluster の分割とシステム・ディスクの配置により，ブート時間を大幅に節約できます。OpenVMS Cluster を分割すると，LAN セグメントのサテライトの利用率も低下し，サテライト・パフォーマンスが向上します。
この OpenVMS Cluster のディスクには， 表 11-2 に示すように決められた機能があります。
| ディスク | 内容 | 目的 |
|---|---|---|
| 共通ディスク | OpenVMS Cluster 全体のすべての環境ファイル | SYSUAF.DAT，NETPROXY.DAT，QMAN$MASTER.DAT などの環境ファイルは，ブート時に，サテライトを始めすべてのノードがアクセスできます。これにより，サテライト・ブート・サーバは，システム・ファイルとサテライトまでのルート情報だけを扱うことで済むようになります。
共通環境を作成し，すべてのシステム・ディスクのパフォーマンスを強化する方法については， 第 11.3 節 を参照してください。 |
| システム・ディスク | Alpha 1，Alpha 2，Alpha 3 のシステム・ルート | サーバ・システムのパフォーマンスの強化。書き込み処理をする環境ファイルをこのシステム・ディスクから取り除き，このディスクをできるだけ読み込み専用にします。ディスクは，スタートアップ時に，SYLOGICALS.COM にクラスタ規模でマウントできます。 |
| サテライト・ブート・サーバのシステム・ディスク | サテライト用のシステム・ファイルまたはルート | Alpha 1，Alpha 2，Alpha 3 に関連付けられたシステム・ディスクを解放し，サテライトのサービス専用とし，各 Ethernet セグメントの全 LAN トラフィックを分割します。 |
| ページ・ディスクとスワップ・ディスク | 1 つ以上のシステムのページ・ファイルとスワップ・ファイル | システム・ディスクの I/O 処理を削減し，システム・ディスクの領域をアプリケーションとシステム・ルートに開放します。 |
図 11-3 に示す構成用のブート・シーケンスでは，共通ディスクのファイルをサテライトがアクセスできるよう，LAN Ethernet セグメントをブートする前に，ノード Alpha 1，Alpha 2，Alpha 3 がすべてブートされているか確認してください。サテライトが Alpha 1，Alpha 2，Alpha 3 のシステム・ディスクからブートしないよう， Ethernet-to-FDDI (10/100) ブリッジで MOP(Maintenance Operations Protocol) のフィルタリングを可能にしておきます。この OpenVMS Cluster をブートする順序は，次のとおりです。
関連項目： 拡張 LAN については， 第 10.7.6 項 を参照してください。
| 前へ | 次へ | 目次 | 索引 |