[samba-jp:22536] Re: Samba4の動作要件とチューニング要素

[Aramaki]

荒巻です。
こんばんわ。皆様コメントありがとうございます。

必要リソースが”簡単にはでない”とわかっても，
仮説や前提条件を考えるネタになるので，
とても助かります。


縮退しているときに，まかなうのが最大で2000人くらいです。
通常は1000人くらいかと思います。
（でもおそらく実態は2桁くらいかもしれません。汗）

64bit環境です。
samba関連のパッケージは，
アーキテクチャ：x86_64
バージョン：4.1.12
で考えています。

NWは10GbENIC×2枚のLACP
（FC）HBAは16GB（FC)×2枚のACT/STBY

クライアントとサーバ間は同一建物内です。NWのスイッチは１段しかいません。
たくさんホップしてとかはないです。通信品質は悪くないとおもいます。

TCPのオフロードエンジンは改めて意識したことがなかったですが
確認してみます。
（カニマークNICって単語は知りませんでした（汗））

通信の暗号化は，構外もWANにでていくところは暗号化ですが，
構内LANの中でSambaを使うところは，パスワードとか以外
暗号化なしかな？


> じゃぁ、中間でいっぱいバッファリングさせるとどうなるか…と言うと、Round Trip Time が派手にばらつきます。
すいません。中間でバッファリングさせるとは，どういう意味ですか？

ストレージはかなり高性能らしいですw

> 一方で、メモリ容量を大きくすると必ず「メモリの動作速度が遅くなる」という拘束条件が発生します。
これって，どういう理屈ですか？


・・・
今後は実機計測して評価はするのかなと思いますが，にしても
机上でも前提条件付きだとしても動作要件を整理しとかんと，計測したときに
マシンをうまいことつかえてるのかつかえてないのかもわかりませんので。

（ちなみに，このマシンにはSambaだけでなくて，NFSServerも同居します。）

色々ありがとうございます。m（__)m


On Thu, 28 May 2015 15:54:30 +0900
Kenichi Okuyama <okuyamak ＠ dd.iij4u.or.jp> wrote:

> 奥山です。
> 
> TCP/IPのポート番号は16bitなので「10万人を1台に同時接続する」とかはできません。
> という事は、まずNに上限値があります。どれぐらい専門機にするのかによりますが、6万は
> 止めておいた方が良いかと。
> 
> また、64bit環境であれば心配いらないと思いますが、32bit環境だとアドレス空間的に苦しいので、
> 最初から考慮すらしない方が良いかと。拡張性が無さすぎます。
> 
> 
> 
> 以上の制約のもとでですと、拘束条件は大雑把に5つに分けられます。
> 
> 1) CPU
> 2) Memory Size
> 3) メモリIO
> 4) Disk IO
> 5) Network IO
> 
> ここで最初にポイントになるのは5番です。
> 同時接続するユーザーの数がいくら多くても、ネットワークが非常に低速であれば問題ありません。
> IOが遅いのは「ネットワークのせい」ですから ( w )。
> 
> 別の言い方をしましょう。「1MBぐらいのExcelを…」と言うのは指標にならないんですよ。
> それを開くのに、何分までなら待てるのか…という問題とセットですから。
> 
> また、ネットワーク latency も問題にならないよね?という点も確認しておいた方が良い。
> 昔、ある会社で東京・大阪間が 6msec の RTT だったので「そういうものか…」と思ってたら、
> 別の会社では 20msec だった…とかもあるので。WAN経由での共有の有無で、ここの議論は
> 大幅に変動します。
> 
> 
> 
> で、ネットワークが早くなった場合…1Gbpsぐらいであっても…オフロードエンジン付きのNICを使うのか、
> カニマークNICを使うのか、でCPU負荷とメモリIO負荷は大幅に変化します。
> 個人的にはオフロードエンジンがしっかりした、高めのNICを使う事をお勧めします。
> 
> 一方でクライアント・サーバー間の通信速度に大きな差があると、ネットワークの途中で速度を落とす際に
> 一定の確率でパケットを落とさざるを得なくなります。すると必ず再送が発生する事になり、
> 通信効率が下がってしまい、結局性能が出ない…という事になります。
> 
> じゃぁ、中間でいっぱいバッファリングさせるとどうなるか…と言うと、Round Trip Time が派手にばらつきます。
> Nが大きい状態でこれをやると、確かにTCP/IP通信速度そのもののトータルは高くなるのですが、
> SSLなどを使った場合の TCP open fail 率が上がっていきます。大抵は retry で隠してくれますが、
> 遅く感じるのは間違いない。という事は「暗号化通信はするの?」というのも…
> 
> 
> Nをどうしても大きくしたいなら、end-to-end での通信速度自体は速くしておいて、Window Size などをいじって
> 一度に大量にパケットを送れないように流量制御する必要があります。つまりこの辺になると、
> 機材の性能だけでなく、それを使う側をどうチューンするか、という問題とセットで解かなくちゃいけなくなる。
> 
> 一見「高い機材を使ってるのに、その本来の性能を出せてない」ように見えるような使い方をしなくてはいけない、
> という事もあるという事です。これを回避しようとするとNを大幅に減らすしかない。
> 
> 
> 
> 仮に5の問題がひと段落したとしましょう。次に考慮するのは4です。
> 本質的に通信でIOするデータ量と disk IO量は disk IO量の方が多くなる、と思って下さい。
> ファイルシステムのメタデータ分を書き込む必要があるし、ジャーナルをかく必要があるし、Sambaだって
> ログも書くし…
> 
> 結局ランダムIOで5で定義した通信量の2倍ぐらいは負荷がかかると思ってよい。
> もちろん、1台で全部捌く必要はないのですが、きれいに分散させるのも難しい。
> そう考えると、小田切さんの言う通り、SSDに投資した方がよくない?!となります。
> 「速度は魅力的だけれど、絶対容量が足りない」
> と言う場合は SSD で RAID を組むとかする必要があると思います。
> 
> ただし、RAIDを組む際にも「ちゃんと外付けRAIDであること」が重要です。
> ソフトウェアRAIDだとその分のIO負荷もサーバー側に来てしまいます。
> サーバー側がこのせいでIO負荷に耐えられないのでは本末転倒ですから。
> 
> ちなみにSATAだってSASだって通信速度には上限と言うものがあります。
> そう簡単に溢れるとも思えませんが、この値を超えた要求は当然クリアする事は技術的に不可能です。
> 
> 
> 
> ここまできたら、次は3です。メモリIO。
> disk IOと Network IOは実は、結果を全部メモリに書きます。disk-NIC間直接通信っていまだにありません。
> 一方で、メモリ容量を大きくすると必ず「メモリの動作速度が遅くなる」という拘束条件が発生します。
> 
> メモリの速度そのものがボトルネックになった経験は、私はしたことがありません。が、IOを管理するチップセットが
> 安物過ぎて、あるIOと次のIOの間の無駄時間が大量に存在した…というケースは聞いたことがあります。
> メモリは遅くても良いですが、チップセットは高いものを選ぶべきです。別の言い方をすると「良いマザーボード」ですね。
> 
> 
> 
> ここまでくれば、問題はあらかたクリアできた、と言えます。
> 
> メモリサイズは「許容できる最大容量を、許容できる最低速度で」。
> CPUは「どうせメモリに比べて圧倒的に速すぎて暇しているんだから、動作クロックは抑えて。
> ただし、コア数は増やして負荷増大にもきれいに耐えられるように」。
> 
> 
> ====
> 
> 逆に言うと。
> 
> 「今、購入できる機材」の種類は非常に限定的なので、「同時アクセス数N」のような
> グラデーションモデルに綺麗にフィットしません。あるとき購入できても半年すれば時代遅れだったりもします
> (特にひどいバグが内包されていたチップなんか、「上位版」が出ると同時に売らなくなったりもします)。
> なので、時間をかけて計測しても、その結果が有効な期間があまりにも短くて話にならないのです。
> 
> 結果として「良い」あるいは「簡便な」指標式は、簡単には得られません ( w )ヾ
> 申し訳ない _o_
> 
> 
> 
> 2015年5月28日 5:00 Aramaki <tak99_ara99 ＠ yahoo.co.jp>:
> 
> > 荒巻です。
> > こんばんわ。
> >
> > Samba4を動作させるにあたって，CPUやメモリなどハードのリソー
> > スが必要かを求める指標・計算式などはありますか。
> >
> > （Sambaの共有フォルダに同時接続するユーザN人が100KB〜1MB程度のエクセルや
> > ワードを書き込むような場合）
> >
> > --
> > Aramaki<tak99_ara99 ＠ yahoo.co.jp>
> >
> >

-- 
Aramaki<tak99_ara99 ＠ yahoo.co.jp>