この章では 2 種類のリソースについて解説していますが、新人のシステム管理者にとってはバンド幅は理解しずらい分野であり、通常は処理能力の方がずっと簡単にコンセプトを理解することができます。
また、これら2つのリソースはそれほど関連が深そうには見えません — では、なぜ一緒に解説しているのでしょうか。
これらのリソースは、 データを移動、処理するコンピュータの機能に直結するハードウェアに対応するためです。 このように、2つのリソースは相互関係にあります。
基本的には、バンド幅はデータ転送の容量になります — つまり、特定時間内に一カ所から他所へ移動が可能なデータの量ということになります。 ポイントツーポイントデータ通信を利用するということは次の2点ということになります。
低レベルの通信を可能にするために使用される電気的な導体の 1 セット
効率的で信頼性の高いデータ通信を容易にするプロトコル
こうした条件に合うシステムコンポーネントが2種類あります。
バス
データパス
次のセクションではそれぞれを詳細に探っていきます。
上記に述べたように、バスはポイントツーポイント通信を可能にし、 制御された方法ですべての通信が行われることを確認するある種のプロトコルを使用します。 ただし、バスには他に特徴的な機能があります。
標準化されている電気的な特性 (導体の数、ボルテージレベル、シグナルの速度など)
標準化されている機械的な特性 (コネクタの種類、カードサイズ、物理的なレイアウトなど)
標準化プロトコル
異なるシステムコンポーネント同士を接続させるのにバスは主要な手段となるため、 "標準化"が重要になります。
多くの場合、バスによって複数のメーカーが製造するハードウェアを相互接続できるようにします。 これは標準化なしには実現できないでしょう。しかし、バスがあるメーカーに対して登録商標となる状況であっても、一般的なインターフェイス(バス自体)を使って異なるコンポーネントをより簡単に実装できるようにするために標準化は重要です。
考慮しているコンピュータシステムに関わらずバスが存在します。 次が一般的なバスの例になります。
大容量ストレージバス(ATA及びSCSI)
ネットワーク[1] (イーサネットとトークンリング)
メモリバス(PC133 及び Rambus®)
拡張バス(PCI、ISA、USB)
データパスは識別が難しいと言えますが、バスのようなもので、あちこちに存在します。 また、バスと同様に、データパスによりポイントツーポイント通信が可能になります。 ただし、データパスは以下の点がバスと異なります。
簡易なプロトコルを使用する(ある場合には)
機械的な標準化が(あるとしても)非常に少ない
これらの違いは、データパスが通常はいくつかのシステムコンポーネントに内蔵で、 別のコンポーネントの臨時的な相互接続をするためには使用されないからです。 このように、データパスは特定の状況に対して高度に最適化され、 そのスピードや低コストは、スピードが遅くコストも高い一般使用目的の柔軟性に比べ 人気があります。
バンド幅に関連する問題が発生する可能性は2通りあります(バスまたはデータパスに対して)。
バスまたはデータパスは共有リソースを表すことがあります。 この場合、バスの高レベルの競合によりバス上のすべてのデバイスに対して 利用できる効果的なバンド幅が低下します。
使用頻度の高い複数ディスクドライブのSCSIバスがわかりやすいでしょう。 使用頻度の高いディスクドライブがSCSIバスを飽和状態にして、 同じバスにある他のデバイスがバンド幅をほとんど利用できないようにしてしまいます。 結果、このバスにある各デバイスが過剰使用ではない場合ですら、 このバスのあらゆるデバイスに対するすべてのI/Oの速度が低下します。
バスやデータパスは、接続している固定のデバイス数でリソース専用となっていることがあります。このような場合、そのバスの電気的な特性(及び、使用されるプロトコルの性質の範囲に対して)が利用可能なバンド幅を制限します。これは、通常、バスよりデータパスによく見られます。これが画面がリフレッシュするたびに高い解像度や色の深さで動作するときにグラフィックアダプタの動作が遅くなる傾向になる理由の一つで、データパスがビデオメモリとグラフィカルプロセッサに接続するのに応じて通過しなければならないデータが多くなります。
幸い、バンド幅関連の問題は対処が可能です。 実際、次のような方法をとることができます。
負荷を分散する
負荷を低減する
容量を拡大する
次のセクションではそれぞれの方法について詳細に見ていきます。
最初の方法は、バスの作業をより均等に分散することです。 つまり、あるバスがオーバーロードしているのに別のバスはアイドル状態である場合、 おそらく一定の負荷をアイドル状態のバスに移動すると状況が改善されるでしょう。
往々にしてシステムにはすでに余分のバスが存在するため、 システム管理者としてはこれがまず最初に考えるべき方法です。 例えば、ほとんどのPCには少なくともATA チャンネルが2つあります (これは単にバスの別名)。ATAディスクドライブが2つとATAチャンネルが2つある場合、 なぜ両方のドライブが同じチャンネルになければならないのでしょう?
システム設定に補助のバスが含まれていなくても、負荷分散は合理的な方法かもしれません。負荷分散を行なうのにかかるハードウェアの経費の方が、大容量ハードウェアのある既存バスを交換するより経済的でしょう。
一見したところでは、負荷の低減と負荷の分散は同じ硬貨の表と裏のように見えます。 つまり、負荷を分散するとき、負荷の低減を行う(少なくともオーバーロードしているバスで) ということではないでしょうか?
この見解は正しいのですが、負荷をグローバルに低減するのとは 異なります。ここで重要なのは、その特定バスがオーバーロードする原因となるシステム負荷の 状況があるかどうか見極めることです。 例えば、不必要な作業のためにネットワークに激しく負担がかかっていませんか? ひとつの小さなテンポラリファイルが重い読み取り/書き込みのI/Oを受け取っていることがあります。そのテンポラリファイルがネットワーク接続のファイルサーバーに存在する場合、そのファイルをローカルに作業することによりかなりのネットワーク通信量が削減される可能性があります。
バンド幅が不足している場合の明快なソリューションとしては、 何らかの方法でそれを拡大することです。 ただし、一般的に費用がかかる方法になります。 例えば、SCSIコントローラとそのオーバーロードしているバスを考えてみてください。 ハンド幅を拡大するには、SCSIコントローラ(及び、おそらく接続しているデバイスすべて)を 高速のハードウェアと交換する必要があるでしょう。 SCSIコントローラが独立したカードなら、比較的に単純な手順となりますが、 SCSIコントローラがシステムのマザーボードの一部である場合は、 このような変更は費用の面で釣り合いが取れるか判断するのが難しくなってきます。
システム管理者はバンド幅についての知識を持ち、 システム設定とその使用によって利用可能なハンド幅にどのような影響を与えるかを 知っておく必要があります。 残念ながら、問題がハンド幅に関連するものなのか、 そうではないのかは必ずしも明白ではありません。 問題がバス自身ではなく、バスに接続しているコンポーネントのひとつであることもあります。
例えば、PCIバスに接続しているSCSIアダプタを考えてみます。 SCSIディスクのI/Oにパフォーマンスの問題がある場合、SCSI 及び PCIバスのバンド幅にはまったく問題がなくても SCSI アダプタのパフォーマンス不足が原因となることがあります。
| [1] | システム内バスの代わりに、ネットワークが システム間バスとして考えられることができます。 |