[Appendix B] B.3 Samba サーバのサイジング

B.3 Samba サーバのサイジング

サイジングはボトルネックが顕在化する前にそれを押える方法である。これを行なうための良い方法は、一秒間に何リクエスト、もしくは一秒間に何キロバイトの帯域がクライアントに必要かを把握し、サーバの全てのコンポーネントが最低でもそれだけのパフォーマンスを提供できることを確認することである。

考慮すべき3 つの主要なボトルネックとして、CPU、ディスクI/O およびネットワークがある。ほとんどのマシンで CPU はまずボトルネックにならない。一台の Sun SPARC 10 CPU は一秒間に 700 から 800 程度の I/O 操作を開始(もしくは完了)することができ、データの平均が 8KB 程度(共通のバッファサイズ)だとすると、大体 5,600 から 6,400KB のスループットがある。一台の Intel Pentium 133 はもう少し少ないがこれはキャッシュとバスが遅いためであり、CPU パワーが足りないからではない。Compaq のサーバのように、サーバとして設計された Pentium servers であれば、最高 4 CPU まで、CPU 毎に 700 の I/O操作程度は開始できるだろう。

一方メモリの不足は簡単にボトルネックになり得る; 各 Samba のプロセスは Intel プロセッサ上の Linux において 600 から 800KB 程度を使用し、RISC CPU では更にその量は多い。メモリが少ないと、仮想メモリへのページングが増加し、パフォーマンスに影響を与えるであろう。Solaris においては計測したところ smbd は 2.6 MB をプログラムと共有ライブラリで利用しており、更にクライアントからの接続毎に 768KB を使っていた。 nmbd は 2.1 MB を占め、一つの外部プロセス毎に更に 496KB ずつ使用していた。

ハードディスクが一秒間に可能なI/O操作の数値は常にボトルネックとなる: 例えば各 7200 RPM SCSI ディスクは一秒間に 70 操作を行なう能力があり、560KB/s のスループットがある; 4800 RPM のディスクは 50 以下であり、スループットは 360KB/s である。IDE ディスクは更に少ない。ディスクが独立していたり、RAID1 の設定でストライピングが行なわれていた場合、ピーク時のアウトプットは 400 から 560KB/s になり、ディスクを追加する毎に、その規模は線形的に増加するであろう。これは RAID1 の場合にのみあてはまることに注意。RAID 1(ストライピング)以外ではオーバーヘッドが増加する。

イーサネット(やその他のネットワーク)は明らかにボトルネックとなる: 10 Mb/s (メガ ビット/ 秒) イーサネットは 1500バイトのパケットの場合、大体 1100KB/s (キロ バイト/s)の能力がある。100 Mb/s の Fast Ethernet は同じパケットサイズだと 65,000KB/s を超えない限りボトルネックにならない。155 Mb/s の FDDI は最高で約 6,250KB/s の能力だが、100 パーセントの負荷でも充分な性能を発揮し、更に大きいサイズのパケット(4KB)を転送する。

ATM は更に良い、しかし本書の執筆時点では新技術であり性能を発揮するに至っていなかった; ATM は 9KB のサイズのパケットを用い、約 7,125 Mb/s の能力がある。

もちろんその他のボトルネックも存在し得る: 特にコントローラ毎に複数の IDE ディスクを接続するのは勧められない。従来の SCSI コントローラあたり 3 台以上の 3600 SCSI-I ディスクを接続したり、SCSI-II の fast/wide コントローラあたり 3 台以上の 7200 SCSI-II disks を接続するのも同様である。 RAID 5 も遅い、これは個別のディスクや RAID1 に書き込むのと比べ、2 倍の書き込みが必要だからである。

ISA や EISA バスを使っている場合は特に、イーサネットやディスクコントローラを複数接続するのであれば、バスのバンド幅にも注意したほうがよい。

B.3.2 ボトルネックの削減

上記の情報から、与えられたマシンの最大性能を算出するモデルを作成した。ほとんどのデータは Brian Wong の Configuration and Capacity Planning for Solaris Servers, [1] からのものであるため、サンプルには多少 Sun のバイアスが掛かっているだろう。

注意: これは完全なモデルではない。このモデルが全てのボトルネックを表しているとか、10 パーセント以内の誤差で見積もれる等と考えてはいけない。ボトルネックを警告するだけでなく、パフォーマンスを見積もれるようなモデルは非常に複雑であり、「SCSI バス毎にディスクを 3 台を越えない範囲で接続する」というようなルールが必要だろう。(実際的なモデルについての良書は Raj Jain の The Art of Computer Systems Performance Analysis である。[2]) 以上を注記した上で、システムを図 B.2 に示す。

[2] Jain. Raj の The Art of Computer Systems Performance Analysis, New York, NY (John Wiley and Sons), 1991, ISBN 0-47-150336-3 を参照のこと。

Figure B.2: Data flow through a Samba server, with possible bottlenecks

データの流れは明解である。例えば読み込みの場合、データはディスクからバスを経由して CPU を通過し、そしてネットワークインタフェースカード(NIC) に至る。それからデータはパケットに分割され、ネットワークに送出される。ここで認識しておくことは、データがシステム内をどう通過し、何のボトルネックがそれを妨げうるかを認識することである。信じると信ぜざるとに関わらず、システムのディスク、CPU、ネットワークカードで共通の最大パフォーマンスを一覧する表を作成するのはむしろ簡単なことである。従って、これが今からやるべきことになる。

実際の例で試してみよう: Pentium 133MHz の Linux マシンで 7200 RPM のデータディスクが 1台、PCI バスで 10Mb/s のイーサネットカードが付いているマシンである。これは非常にありがちなサーバである。まずは表 B.2 には、ハードディスクのスループットの表がある - ディスクはシステム中で最もボトルネックになりやすい箇所である。

Table B.2: ディスクスループット
Disk RPM	I/O 操作/秒	KB/秒
7200	70	560
4800	60	480
3600	40	320

ディスクのスループットはディスクが一秒間に転送できるデータをキロバイト単位で表したものである。これは一回8KB の I/O 操作をディスクがどれだけ行なえるかで算出した値であり、ディスクの RPM とビット密度と非常に関連している。実際のところ、質問というのは一秒間にどれだけのデータがドライブのヘッドを通過できるかであろう。7200 RPM のディスク一台であれば、このサーバは一秒 70 回のI/O 操作を実行でき、約 560KB/s の処理能力がある。

次の潜在的なボトルネックは CPU である。最近のマシンでは、実際のところデータが CPU 内を通過するわけではないので、スループットは間接的な方法で算出するしかない。

CPU は I/O 要求を発行し、戻って来る割り込み要求をハンドルする。そこでデータをバスを経由してネットワークカードに転送する。過去の経験から処理を左右するオーバーヘッドはファイルシステムのコードに依存するので、走行しているかもしれない他のソフトウェアに付いては無視する。 CPU が処理を行なうサイズが平均 8K であるファイルI/O 操作の測定値をかけ算してスループットを計算した。これによる結果は表 B.3 の通りである。

Table B.3: CPU スループット
CPU	I/O 操作/秒	KB/秒
Intel Pentium 133	700	5,600
Dual Pentium 133	1,200	9,600
Sun SPARC II	660	5,280
Sun SPARC 10	750	6,000
Sun Ultra 200	2,650	21,200

これでディスクと CPU のデータの両方が揃った: Linux の例では 560KB/秒の処理能力のある 7200 RPM のディスクと 5600KB の処理能力のある 700 I/O 操作を開始する能力がある CPU が存在する。ここまでのところ、期待通りに、ボトルネックは明確にハードディスクであることが分かる。

最後の潜在的なボトルネックはネットワークである。もしネットワークに速度が 100Mb/s 以下であれば、ボトルネックはネットワーク速度にあるかもしれない。またネットワークカードのデザインによっても速度が左右される。表 B.4 ではネットワークのタイプ別に平均的なスループットを表示した。ネットワークの速度はビット/秒で計算するのが便利ではあるが、表 B.4 ではディスクや CPU (Table B.2 and Table B.3) との比較を容易にするためバイト/秒で記述した。

Table B.4: ネットワークのスループット
ネットワークのタイプ	KB/秒
ISDN	16
T1	197
Ethernet 10m	1,113
Token ring	1,500
FDDI	6,250
Ethernet 100m	6,500[3]
ATM 155	7,125a

[3] これは更に向上しうる。例えば Cray、Sun Ultra、DEC/Compaq Alpha 等では既にこの数値よりよい値を達成している。

先程からの例でいえば、560KB/秒の処理能力のディスクにボトルネックがある。表 B.4 をみると標準的な 10Mビットのイーサネット(1,113KB/秒)はディスクよりも格段に早い。それゆえ、ハードディスクはが限界のファクターになる(この状況では、一般的な結果である)。表を見る限り、小規模なサーバでは CPU ネックになることはまずなく、複数 CPU をサポートしている大型サーバでも、ストライピングや複数のイーサネットがサポートされない限りCPU パワーが枯渇することはないということが分かる。これが実際のところ現実である。

B.3.3 実用的な例

Configuration and Capacity Planning for Solaris Servers (Wong) からの例を見ると、4 つのイーサネットと、6 台の 2.1GB ディスクを備えたデュアルプロセッサの SPARCstation 20/712 は全ての時間をディスクからのデータ待ちに費している。ディスクが満載されているとしても(Brian Wong は 34 台を推奨している)、イーサネットカードがネックとなり、1,200KB/秒以下のパフォーマンスしかでない。マシンが発揮可能なパフォーマンスを叩き出すには、イーサネットカードを複数装着するか、100Mbps の Fast Ethernet か 155Mbps の FDDI にする必要がある。

結論を導き出すために行なった作業は、以下の表 B.5 のようになる。

表 B.5: 中型サーバのチューニング
マシン	ディスクのスループット	CPU のスループット	Network のスループット	実際のスループット
Dual SPARC 10, ディスク1台	560	6000	1,113	560
ディスク5台追加	3,360	6000	1,113	1,113
3 イーサネットI/F を追加	3,360	16000	4,452	3,360
ディスク20台からなるディスクアレイに変更	11,200	6000	4,452	4,452
二つの 100 Mbps イーサネットI/Fを使用	11,200	6000	13,000	11,200

最初ボトルネックは、560KB/秒のスループットしか出せなかったディスクであった。その対策は5台のディスクを追加することであった。これでディスクはイーサネット以上のパフォーマンスを発揮するようになり、今度はイーサネットが問題となった。その後、更なる性能向上を目指して、何回かこのような作業を行き来した。ディスクや CPU やネットワークカードを追加することでボトルネックを解消した。基本的にこれは、ボトルネックを解消するため、パフォーマンスの限界に達するか、(不幸にして)資金がなくなりこれ以上追加できなくなるまでハードウェアを追加するという作業である。

経験的にもこうした計算は信頼できる。著者の一人が管理していた大型の SPARC 10 ファイルサーバは、2プロセッサの場合イーサネットとFDDIリングの1/3を飽和させるだけの能力を持っていた。高速なオペレーティングシステムと適切な最適化を行ったにも関わらず、1プロセッサの場合でもほぼ同様であった。

目的の異なる他社のサーバに対しても同じ方法が適用できる。最新の Compaq, Alpha マシンの DECstation 2100 や古い MIPS 3350 や新しい SGI O2 に対しても同じ方法を適用することができた。一般的にマルチCPU のサーバは充分なバス幅とCPU パワーを持っており、ファイルサービスを行なう場合はディスクI/O ネックになると考えられる。何かする時には、まずは費用を考えること!(As one would hope, considering the cost!)

B.3.4 Samba がサービスできるクライアント数は?

これは、各ユーザがどの程度のデータ量を利用するかに完全に依存する。 3 つの SCSI-1 ディスクがある小規模のサーバは960KB/秒のデータを処理出来るが、通常のオフィス環境で、典型的な負荷の元で同じサイズの表計算ソフトやワープロのドキュメントが保存される環境(36 台のクライアントが 12k のファイルを 1秒 2.3回転送し、1MB/秒の負荷を掛ける)では、36 から 80 台のクライアントをサポートできるだろう。

同じサーバを開発環境で利用した場合、プログラマーは非常に負荷の掛かる編集-コンパイル-テストの作業を行なうため、簡単に一人が1MB/秒程度の帯域を利用するため、25 台以下のクライアントしかサポートできないだろう。このことから考えると、各クライアントが10MB/秒の帯域を必要とするシステムでは、 10MB/秒のイーサネット上にある限り、どんな巨大なサーバであってもパフォーマンスはできないであろう。

平均的なユーザが消費する帯域が分からない場合、Samba サーバのサイジングを、現存する NFS, Netware, LAN Manager のサーバからの類推で行なうことも出来る。特に新しいサーバが現存するサーバと同じディスクやディスクコントローラを持っているかどうかに注意すること。このテクニックは「punt and hope(賭けと希望)」とでも呼んでおこう。

現在のサーバが何台のクライアントをサポートしているかが分かれば、 よりよい サイジングが可能になる。そのサーバを分析することでサーバに必要とされる能力の最大を把握したり、どの程度のデータ量が必要とされるかの見積もりを行ったりすることが可能である。例えば、2台のIDEディスクを持つPCサーバが30台のPCにホームディレクトリを提供している場合は非常に遅く、25クライアントであれば適切であったとしよう。この場合、ディスクI/O(最大640KB)ではなくイーサネットI/O(約375KB)がボトルネックであるということが確実に推測できる。その場合、クライアントは平均15(375/25)KBの帯域を必要としていることも推測できる。

75クライアントの新しい研究室をサポートするには、1,125KB/sの帯域が必要であり、複数(最適数は3)のイーサネットに分散させることになろう。またサーバには少なくとも3台の7200RPM のディスクとボトルネックにならないだけのCPUが必要である。これらの要求を満たすには、Pentium 133 以上のCPUと、ディスクの最大能力に対応できるバスアーキテクチャ(PCI等)が必要である。

自作したPCサーバや、SUN SPARC, DEC/Compaq Alpha, SGI 等のマルチプロセッサ可能なワークステーションであれば簡単に構成の拡張が行える。例えばFastイーサネットとスイッチングHUBを用いることで、10MB/秒のイーサネットのクライアントに対応することができる。

B.3.4.1 どのように推測するか

必要な情報が全くないのであれば、残された方法はだれかの経験に頼ることであろう。各クライアントマシンは平均1秒辺り1I/O(営業/経理部門の普通のPCやMacの場合)から最高でも4I/O(大型のアプリケーションを使用する高速ワークステーションの場合)である。コンパイラが実行されているような高速ワークステーションは、平均3-4MB/秒のデータ転送が必要であり、システムによってはより多くの帯域が必要な場合もある。

我々の推奨? それは、同様の設定のサイトを観察して、そこのボトルネックから必要な帯域幅とユーザからのクレームを推定することだろう。また Brian Wong の Configuration and Capacity Planning for Solaris Serversも推奨する。実例としては Sun Solaris が用いられてはいるが、ボトルネックとしてあげられるディスクやネットワークは、主要なベンダに共通するものである。FTPサーバに関する表は、我々がSambaサーバで計算した内容と非常に類似しており、最初のとりかかりとしてはよいであろう。

B.3.5 計測様式

表 B.6 と表 B.7 は、コピーして計測結果の記録に利用する目的で提供する表の枠組みである。ここまでの例にあったボトルネックの計算は、表計算ソフトウェアや表 B-8を使って手計算で行うことができる。もし、Samba が FTP と同等かより優れた性能をみせ、かつ平均値を非常に外れたテスト結果もないという場合、システムはよく設定されているといえる。ループバックインタフェースが他と比較してそれほど高速でないという場合は、TCP/IP ソフトウェアに何らかの問題がある。FTP と Samba の両者が共に遅い場合は恐らくネットワークに問題がある。動作不良のイーサネットカードもその原因となりうる。例えば偶然イーサネットカードが半二重に設定されているにも関わらず半二重のHUBに接続されていなかった場合などが考えられる。CPUとディスクの速度は通常バイト単位で計測され、ネットワークはビット単位で計測されることを忘れないように。

表にはバイトとビットの両方の列を含めている。最後の行では 10 MB/秒と比較しているが、これはその速度が伝統的なイーサネットの速度だからである。

表 B.6: 同一ホストのイーサネットインタフェース: FTP
実行回数	バイト数	時間 (秒)	バイト/秒	ビット/秒	10 Mb/秒に対する%
1
2
3
4
5
平均値:
偏差:

表B.7: 同一ホストのイーサネットインタフェース: FTP
実行回数	バイト数	時間 (秒)	バイト/秒	ビット/秒	10 Mb/秒に対する%
1
2
3
4
5
平均値:
偏差:

表 B.8: ボトルネック算出表
CPU	CPUスループット	ディスクの台数	ディスクのスループット	ネットワークの数	ネットワークのスループット	全体のスループット

表 B.8について:

CPU スループット = (KB/秒、図 6-5による)×(CPU個数)
ディスクスループット= (KB/秒、図 6-4による)×(ディスクの台数)
ネットワークスループット = (KB/秒、図 6-6による)×(ネットワークの数)
全体のスループット = min (ディスク、CPU、ネットワークスループット)

FTPgetの場合の典型的なテストの結果を表 B-9 に入力した:

表 B.9: 同一ホストからのイーサネットインタフェース: FTP
実行回数	バイト数	時間(秒)	バイト/秒	ビット/秒	10 Mb/秒に対する%
1	1812898	2.3	761580
2		2.3	767820
3		2.4	747420
4		2.3	760020
5		2.3	772700
平均値:		2.32	777310	6218480	62
偏差:		0.04

以前使用した SPARC の場合の例は表 B-10 のようになる。

Using Samba