test

Sun NFS サーバーの調整

ディスクドライブ

ディスクドライブの使用状況は、NFS サーバーの性能に依存する最も重要な要素です。ファイルシステムからのデータによって、キャッシュを素早く満たすことができない場合は、十分なメモリー構成でも、性能が改善しないことがあります。

性能の低下の原因がディスクにあるかどうかを確認する

NFS 要求のストリームには相関関係がほとんどないため、生成されるディスクアクセスには、ディスクに対する大量のランダムアクセスが含まれます。ランダム入出力の最大回数は、ディスク 1 台当たり 40 〜 90 回です。

1 台のディスクドライブが、最大ランダム入出力能力の 60 % を超えて使用されると、そのディスクが性能上の障害となります。

性能の低下の原因がディスクにあるかどうかを確認するには、iostat コマンドを使用して 1 秒あたりの読み取り・書き込み回数を調べます (NFS サーバーの検査を参照)。

ディスクボトルネックの緩和

NFS サーバーのディスク帯域幅は、NFS クライアントの性能に最も大きな影響を与えます。最高のファイルサーバー性能を得るには、ファイルシステムのキャッシュに十分な帯域幅とメモリーを用意します。また、読み取りや書き込みの待ち時間も重要です。たとえば、NFSop ごとにディスクアクセスが伴うと、ディスクサービス時間が NFSop 待ちの時間に加わるため、ディスク動作が遅くなると、NFS サーバーの動作も遅くなります。

ディスクのボトルネックを緩和するには、以下のガイドラインに従ってください。

ファイルシステムの複製の作成

通常、NFS サーバーでは、以下のファイルシステムが使用されます。

上記のファイルシステムの複製を作成すると、ファイルシステムの性能を向上させることができます。特定の 1 つのファイルシステムに対する要求を処理する場合に、NFS サーバーは、ディスク帯域幅の制限を受けます。データの複製を作成すると、NFS クライアントからデータ方向へのパイプの合計サイズが大きくなります。ただし、複製は、ホームディレクトリからなるファイルシステムなどの書き込み可能なデータ性能の改善には、実用的な手段ではありません。複製は、読み取り専用のデータに使用してください。

ファイルシステムを複製する

  1. 複製を作成するファイルまたはファイルシステムを特定します。

  2. 複数のファイルの複製を作成する場合は、1 つのファイルシステムにまとめます。

    頻繁に使用するファイルを 1 つのディスクにまとめることによって生じる可能性がある性能の低下は、複製を作成することによって補うことができます。

  3. 一般的に入手可能なツール (nfswatch) を使用して、NFS サーバーグループで最も頻繁に使用されるファイルおよびファイルシステムを確認します。

    表 A–1 に、nfswatch などの性能監視ツールと入手方法を紹介しています。

  4. クライアントがどのように複製を選択するかを決定します。

    /etc/vfstab ファイルにサーバー名を記述し、NFS クライアントからサーバーへの対応を指定します。別の方法として、オートマウンタのマップに全サーバー名を記述することによって、完全に動的な結合を指定することもできます。ただし、この方法を使用すると、クライアントが一部の NFS サーバーに偏る可能性があります。クライアントグループが、専用の複製 NFS サーバーをもつ「ワークグループ」パーティションを実施した場合は、最も予測可能な性能を得ることができます。

  5. 新しいデータを配布するための更新スケジュールと方法を選定します。

    新しい読み取り専用データを配布する計画と方法は、そのデータを変更する頻度によって決定してください。内容が完全に変更されてしまうファイルシステム、たとえば、毎月更新される履歴データを含むファイルは、各マシン上で配付媒体のデータをコピーするか、ufsdump と ufsrestore を組み合せる方法をお勧めします。ほとんど変更のないファイルシステムは、rdist などの管理ツールを使用して対処することができます。

  6. 複製サーバー上の古いデータをユーザーが使用したときに、どのような問題が生じるかを検討します。

    この場合は、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 を介した操作よりも多くのトラフィックが発生します。

キャッシュファイルシステムを監視する

  1. キャッシュファイルシステムの効果を監視するには、cachefsstat コマンドを使用します (Solaris 2.5 以降で使用可能です)。

    cachefsstat コマンドの構文は以下のとおりです。 

    system# /usr/bin/cachefsstat [-z] パス名

    -z は統計情報を初期化します。cachefsstat を実行してキャッシュ性能の統計情報を収集する前に、cachefsstat -z (スーパーユーザーのみ) を実行する必要があります。統計情報は、統計情報が再び初期化されるまでの情報を反映します。

    パス名は、キャッシュファイルシステムがマウントされているパス名です。パス名を指定しないと、マウントされているすべてのキャッシュファイルシステムが対象となります。

-z オプションを使用しないかぎり、このコマンドを通常の UNIX ユーザーとして使用することができます。

cachefsstat コマンドの使用例を以下に示します。 

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 は、キャッシュファイルシステムの統計情報が記録されている場合に情報を表示します。これらのコマンドを使用して、キャッシュファイルシステムの状態が適切かどうかを確認してください。

ディスクドライブを設定する上での規則

データを扱うことが多い環境や属性依存の環境の場合は、一般的なガイドラインの他に、それぞれの環境に応じたガイドラインがあります。

ディスクドライブを設定するときは、以下のガイドラインに従います。

データを扱うことが多い環境 (Data-Intensive)

データを扱うことが多い環境でのディスクドライブの構成では、以下のガイドラインに従います。

属性に依存する環境 (Attribute-Intensive)

属性に依存する環境でのディスクドライブの構成では、以下のガイドラインに従います。

Solstice DiskSuite または Online: DiskSuite によるディスクのアクセス負荷の分散

NFS サーバーでは、ディスクドライブとディスクコントローラに、負荷を効率よく分散できない場合があります 。

負荷のバランスをとるために、以下を行ってください。

Solstice DiskSuite または Online: DiskSuite のディスクミラー化機能は、同じデータのコピー (2 つまたは 3 つ) にアクセスすることによって、ディスクのアクセス時間を短縮し、ディスクの使用回数を減らします。読み取りを主とする環境では特に有効です。一方、ミラー化によって作成されたディスクに対する書き込みは、通常遅くなります。これは、論理的な 1 つの要求に対して、2 回または 3 回の書き込みを行う必要があるためです。

ディスクが均等に使用されるようにするには、数回にわたって監視を行い、データを再編成する必要があります。また、ディスクの使用パターンは時間とともに変化します。インストール時には最適に設定していたデータのレイアウトも、時間が経過するにしたがって、非常に効率が悪くなることがあります。ディスクドライブの使用状況を確認する方法についての詳細は、ディスクドライブを参照してください。

Solstice DiskSuite または Online: DiskSuite 3.0 によるファイルシステムのログベース化

Solaris 2.4 から Solaris 8 のソフトウェア環境と Online: DiskSuite 3.0 または Solstice DiskSuite を組み合わせることによって、標準の UNIX ファイルシステムをログベース化し、ディスクベースの Prestoserve NFS アクセラレータのように扱うことができます。

メインのファイルシステムのディスクの他に、ディスクの一部 (一般的に 10 MB の大きさ) が書き込みのシーケンシャルログ領域として使用されます。以下の 2 つの利点を持つ、このログベース化によって、Prestoserve NFS アクセラレータと同じ種類の動作が高速化されます。

注 -

1 つのファイルシステムに Prestoserve NFS アクセラレータとログを同時に使用することはできません。

最適なディスク領域の利用

ディスク上のデータレイアウトを分析する場合は、ゾーンビット記録方式の採用を検討してください。

サンの 207 MB ディスク以外のすべてのディスクには、回転するディスクに特有な幾何特性を利用し、円盤の縁に最も近い部分に、より多くのデータを詰め込むエンコーディング方式が採用されています。この方式により、通常は、外側のシリンダに対応する下位のディスクアドレスが、内側のアドレスと比較して、性能が 50 % 向上します。

  1. 若い番号のシリンダにデータを書き込みます。

    ゾーンビット記録方式のデータレイアウトでは、若い番号のシリンダが高速になります。

    この性能の差は、シリアル転送で顕著ですが、入出力時のランダムアクセスにも影響します。外側のシリンダ (ゼロ) は、読み取り・書き込みヘッドによるアクセスが速くなるだけでなく、サイズも大きくなります。データが分散するシリンダが少なくなることにより、シーク回数が少なくなり、シーク時間も短くなります。