ディスクドライブの使用状況は、NFS サーバーの性能に依存する最も重要な要素です。ファイルシステムからのデータによって、キャッシュを素早く満たすことができない場合は、十分なメモリー構成でも、性能が改善しないことがあります。
NFS 要求のストリームには相関関係がほとんどないため、生成されるディスクアクセスには、ディスクに対する大量のランダムアクセスが含まれます。ランダム入出力の最大回数は、ディスク 1 台当たり 40 〜 90 回です。
1 台のディスクドライブが、最大ランダム入出力能力の 60 % を超えて使用されると、そのディスクが性能上の障害となります。
性能の低下の原因がディスクにあるかどうかを確認するには、iostat コマンドを使用して 1 秒あたりの読み取り・書き込み回数を調べます (NFS サーバーの検査を参照)。
NFS サーバーのディスク帯域幅は、NFS クライアントの性能に最も大きな影響を与えます。最高のファイルサーバー性能を得るには、ファイルシステムのキャッシュに十分な帯域幅とメモリーを用意します。また、読み取りや書き込みの待ち時間も重要です。たとえば、NFSop ごとにディスクアクセスが伴うと、ディスクサービス時間が NFSop 待ちの時間に加わるため、ディスク動作が遅くなると、NFS サーバーの動作も遅くなります。
ディスクのボトルネックを緩和するには、以下のガイドラインに従ってください。
システムのすべてのディスクに入出力負荷を均等に分散する。
特定のディスクの負荷が大きく、他のディスクが能力の低いレベルで動作している場合は、ディレクトリや頻繁にアクセスするファイルを、あまり使用されていないディスクに移動してください。
負荷の大きいディスクのファイルシステムを分割し、複数のディスクに分散する。
ディスクを増設することによってディスク容量が増え、ディスクの入出力帯域幅が広くなります。
NFS クライアントが使用するファイルシステムが読み取り専用であり、変更することのないデータが含まれている場合は、ファイルシステムを複製し、クライアントに対するネットワークからディスクへの帯域幅を広くする。
ファイルシステムの複製の作成を参照してください。
頻繁に使用するファイルシステムデータを、メモリー上でアクセスできるように、オぺレーティングシステム内のキャッシュを適切な大きさに設定する。
i ノード (ファイル情報ノード) やファイルシステムのメタデータ (シリンダグループ情報など) 、名前から i ノードへの変換用のキャッシュは、十分な大きさにする必要があります。十分な大きさがない場合は、キャッシュに対するヒットミスでディスクトラフィックが増加します。たとえば 、NFS クライアントがファイルをオープンする場合に、NFS サーバーでは、名前から i ノードへの変換動作が複数回行われます。
ディレクトリ名ルックアップキャッシュ (DNLC) でヒットしなかった場合は、サーバーは、ディスク上のすべてのディレクトリエントリから適切なエントリ名を探します。通常はメモリー上の処理で行われることが、複数回のディスク動作となります。このような場合は、ファイルに関係するページもキャッシュされません。
通常、NFS サーバーでは、以下のファイルシステムが使用されます。
ディスクレスクライアントの /usr ディレクトリ
ローカルツールとライブラリ
サン製品以外の一般的なパッケージ
読み取り専用のアーカイブ版ソースコード
上記のファイルシステムの複製を作成すると、ファイルシステムの性能を向上させることができます。特定の 1 つのファイルシステムに対する要求を処理する場合に、NFS サーバーは、ディスク帯域幅の制限を受けます。データの複製を作成すると、NFS クライアントからデータ方向へのパイプの合計サイズが大きくなります。ただし、複製は、ホームディレクトリからなるファイルシステムなどの書き込み可能なデータ性能の改善には、実用的な手段ではありません。複製は、読み取り専用のデータに使用してください。
複製を作成するファイルまたはファイルシステムを特定します。
複数のファイルの複製を作成する場合は、1 つのファイルシステムにまとめます。
頻繁に使用するファイルを 1 つのディスクにまとめることによって生じる可能性がある性能の低下は、複製を作成することによって補うことができます。
一般的に入手可能なツール (nfswatch) を使用して、NFS サーバーグループで最も頻繁に使用されるファイルおよびファイルシステムを確認します。
表 A–1 に、nfswatch などの性能監視ツールと入手方法を紹介しています。
クライアントがどのように複製を選択するかを決定します。
/etc/vfstab ファイルにサーバー名を記述し、NFS クライアントからサーバーへの対応を指定します。別の方法として、オートマウンタのマップに全サーバー名を記述することによって、完全に動的な結合を指定することもできます。ただし、この方法を使用すると、クライアントが一部の NFS サーバーに偏る可能性があります。クライアントグループが、専用の複製 NFS サーバーをもつ「ワークグループ」パーティションを実施した場合は、最も予測可能な性能を得ることができます。
新しいデータを配布するための更新スケジュールと方法を選定します。
新しい読み取り専用データを配布する計画と方法は、そのデータを変更する頻度によって決定してください。内容が完全に変更されてしまうファイルシステム、たとえば、毎月更新される履歴データを含むファイルは、各マシン上で配付媒体のデータをコピーするか、ufsdump と ufsrestore を組み合せる方法をお勧めします。ほとんど変更のないファイルシステムは、rdist などの管理ツールを使用して対処することができます。
複製サーバー上の古いデータをユーザーが使用したときに、どのような問題が生じるかを検討します。
この場合は、Solaris 2.x JumpStart™ 機構と cron を組み合わせる方法があります。
キャッシュファイルシステムはクライアントが中心となります。クライアント上のキャッシュファイルシステムを使用して、サーバーの負荷を軽減します。キャッシュファイルシステムを使用した場合は、ファイルはブロックごとにサーバーから読み込まれます。ファイルは、クライアントのメモリーに送られ、ファイルに対する操作は直接行われます。操作されたデータは、サーバーのディスクに書き戻されます。
マウントを行うクライアントに、キャッシュファイルシステムを追加することによって、各クライアントにローカルの複製を作成することができます。キャッシュファイルシステムの /etc/vfstab エントリは、以下のようになります。
# device device mount FS fsck mount mount # to mount to fsck point type pass at boot options server:/usr/dist cache /usr/dist cachefs 3 yes ro,backfstype=nfs,cachedir=/cache
アプリケーションファイルシステムなど、頻繁に読まれるファイルシステムに対してキャッシュファイルシステムを使用してください。それ以外にキャッシュファイルシステムを使用する状況として、遅いネットワーク上でデータを共有している場合があります。複製サーバーとは異なり、キャッシュファイルシステムは、書き込み可能なファイルシステムと組み合わせることができますが、書き込みの割合が高くなるにしたがって性能が低下します。書き込みの割合が高すぎる場合は、キャッシュファイルシステムによって NFS の性能が低下することがあります。
また、使用しているネットワークがルーターによって相互接続された高速のネットワークである場合にも、キャッシュファイルシステムの使用を検討する必要があります。
NFS サーバーが頻繁に更新されている場合は、キャッシュファイルシステムを使用しないでください。キャッシュファイルシステムを使用すると、NFS を介した操作よりも多くのトラフィックが発生します。
キャッシュファイルシステムの効果を監視するには、cachefsstat コマンドを使用します (Solaris 2.5 以降で使用可能です)。
system# /usr/bin/cachefsstat [-z] パス名
-z は統計情報を初期化します。cachefsstat を実行してキャッシュ性能の統計情報を収集する前に、cachefsstat -z (スーパーユーザーのみ) を実行する必要があります。統計情報は、統計情報が再び初期化されるまでの情報を反映します。
パス名は、キャッシュファイルシステムがマウントされているパス名です。パス名を指定しないと、マウントされているすべてのキャッシュファイルシステムが対象となります。
-z オプションを使用しないかぎり、このコマンドを通常の UNIX ユーザーとして使用することができます。
system% /usr/bin/cachefsstat /home/sam cache hit rate: 73% (1234 hits, 450 misses) consistency checks: 700 (650 pass, 50 fail) modifies: 321
上記の例では、ファイルシステムにおけるキャッシュのヒット率は 30 % よりも高くなっている必要があります。キャッシュのヒット率が 30 % よりも低い場合は、ファイルシステムに対するアクセスが全体的に不規則であるか、キャッシュの大きさが不十分であることを意味しています。
cachefsstat コマンドを実行して得られる統計情報には、キャッシュのヒット率、一貫性の検査の実行数、および変更の数が含まれます。
表 3-1 cachefsstat コマンドを実行して得られる統計情報出力 | 説明 |
---|---|
cache hit rate |
キャッシュの試行の数と成功した数の比率。成功した数と失敗した数も表示されます。 |
consistency checks |
一貫性の検査の実行数。合格した数と、問題があった数も表示されます。 |
modifies |
変更の数 (書き込みと作成が含まれます)。 |
一貫性の検査の結果は、キャッシュファイルシステムがサーバーに対してデータが有効であるかどうかを検査した結果です。失敗率が高い場合は (15 〜 20 %)、検査対象のデータが頻繁に変更されていることを意味しています。キャッシュは、キャッシュされたファイルシステムよりも高速に更新することができる可能性があります。一貫性の検査の結果と変更の数を調べることによって、このクライアントが変更を行っているのか、他のクライアントが変更を行っているのかを調べることができます。
変更の数は、クライアントがファイルシステムに変更を行った回数です。この結果を調べることは、ヒット率が低い理由を調べるもう 1 つの方法です。変更の数が多い場合は、通常は一貫性の検査の数が多くなり、ヒット率が低くなります。
cachefswssize と cachefsstat を使用することができます。cachefswssize は、キャッシュファイルシステムで使用されるファイルのサイズの合計を表示します。cachefsstat は、キャッシュファイルシステムの統計情報が記録されている場合に情報を表示します。これらのコマンドを使用して、キャッシュファイルシステムの状態が適切かどうかを確認してください。
データを扱うことが多い環境や属性依存の環境の場合は、一般的なガイドラインの他に、それぞれの環境に応じたガイドラインがあります。
ディスクドライブを設定するときは、以下のガイドラインに従います。
アクティブなドライブ数が SCSI の標準ガイドラインを超えない範囲で、性能を低下させることなく、各ホストアダプタのドライブを増設する。
Solstice DiskSuite を使用し、多数のディスクにディスクアクセス負荷を分散させる。
詳細は、Solstice DiskSuite または Online: DiskSuite によるディスクのアクセス負荷の分散を参照してください。
ディスクの最高速の領域を使用する。
詳細は、最適なディスク領域の利用を参照してください。
データを扱うことが多い環境でのディスクドライブの構成では、以下のガイドラインに従います。
逐次的な環境に設定する。
最も高速な転送速度のディスクを使用する (可能であればストライプ化する)。
アクティブなバージョン 3 のクライアント 3 台に対して、1 台の RAID デバイス (論理ボリュームまたはメタディスク) を設定する。または、バージョン 2 のクライアント 4、5 台に対して、1 台のデバイスを設定する。
Ethernet またはトークンリング上のアクティブなクライアント 1 台に対して、少なくともディスクドライブ 1 台の構成にする。
属性に依存する環境でのディスクドライブの構成では、以下のガイドラインに従います。
適切な数の SCSI ホストアダプタ (ディスクアレイなど) に小型のディスクを多く接続する。
Fast SCSI ホストアダプタ 1 基に対して、4 台から 5 台の (または 8 台から 9 台以下の) ディスクドライブの構成にする。小型のディスクドライブを複数使用することは、大型のディスクドライブを 1 台使用するよりはるかに良い結果が得られます。
ネットワークのタイプに関係なく、クライアント 2 台に対して少なくともディスクドライブ 1 台の構成にする。
Fast-Wide SCSI ホストアダプタ 1 基に対して、6 台から 7 台以下の 2.9 GB ディスクドライブの構成にする。
NFS サーバーでは、ディスクドライブとディスクコントローラに、負荷を効率よく分散できない場合があります 。
負荷のバランスをとるために、以下を行ってください。
論理的な使用状況からではなく、物理的な使用状況から負荷のバランスをとってください。Solstice DiskSuite または Online: DiskSuite のストライプ機能とミラー機能により、透過的にディスクドライブに対するディスクアクセスが分散するようにします。
Solstice DiskSuite または Online: DiskSuite のディスクミラー化機能は、同じデータのコピー (2 つまたは 3 つ) にアクセスすることによって、ディスクのアクセス時間を短縮し、ディスクの使用回数を減らします。読み取りを主とする環境では特に有効です。一方、ミラー化によって作成されたディスクに対する書き込みは、通常遅くなります。これは、論理的な 1 つの要求に対して、2 回または 3 回の書き込みを行う必要があるためです。
ディスクが比較的一杯になっている場合に、ディスクを連結することによって、最低レベルの負荷の分散がなされます。
データ量の多い環境では、ディスクのスループットを改善し、サービス負荷を分散させるために飛び越し間隔の小さいストライプ処理を行ってください。ディスクのストライプ処理により、アプリケーションの連続した読み取り・書き込み速度が向上します。最初の飛び越し間隔の大きさは、ストライプを構成するディスク 1 台につき 64 KB にします。
属性に依存する環境 (ディスクに対するアクセスが不規則な環境) では、デフォルトの飛び越し (1 つのディスクシリンダ) でディスクをストライプ化してください。
iostat と sar コマンドを使用して、ディスクドライブの使用状況を調べてください。
ディスクが均等に使用されるようにするには、数回にわたって監視を行い、データを再編成する必要があります。また、ディスクの使用パターンは時間とともに変化します。インストール時には最適に設定していたデータのレイアウトも、時間が経過するにしたがって、非常に効率が悪くなることがあります。ディスクドライブの使用状況を確認する方法についての詳細は、ディスクドライブを参照してください。
Solaris 2.4 から Solaris 8 のソフトウェア環境と Online: DiskSuite 3.0 または Solstice DiskSuite を組み合わせることによって、標準の UNIX ファイルシステムをログベース化し、ディスクベースの Prestoserve NFS アクセラレータのように扱うことができます。
メインのファイルシステムのディスクの他に、ディスクの一部 (一般的に 10 MB の大きさ) が書き込みのシーケンシャルログ領域として使用されます。以下の 2 つの利点を持つ、このログベース化によって、Prestoserve NFS アクセラレータと同じ種類の動作が高速化されます。
デュアルマシンの高可用性 (HA) の構成では、Prestoserve NFS アクセラレータは利用できませんが、ログは共有できます。そのため、このような環境でも使用することができます。
オぺレーティングシステムに障害が起きた場合でも、ログベースのファイルシステムの fsck が、ログだけを順次読み取ります。大規模なファイルシステムの場合でも、ほとんど瞬時に読み取りが行われます。
1 つのファイルシステムに Prestoserve NFS アクセラレータとログを同時に使用することはできません。
ディスク上のデータレイアウトを分析する場合は、ゾーンビット記録方式の採用を検討してください。
サンの 207 MB ディスク以外のすべてのディスクには、回転するディスクに特有な幾何特性を利用し、円盤の縁に最も近い部分に、より多くのデータを詰め込むエンコーディング方式が採用されています。この方式により、通常は、外側のシリンダに対応する下位のディスクアドレスが、内側のアドレスと比較して、性能が 50 % 向上します。