この質問で、単一のサーバーから40Gbpsを配信するのに最適な構成/ハードウェアを見つけたいと思います。

状況

背後にある低速のストレージサーバーからピークをオフロードするビデオ共有プロキシサーバーがあります。すべてのトラフィックはHTTPのみです。サーバーは、リバースプロキシ（サーバーにキャッシュされないファイル）およびWebサーバー（ローカルドライブに保存されるファイル）として機能します。

現在、100 TB程度のファイルがあり、バックエンドストレージサーバーで増加しています。

キャッシングメカニズムは独立して実装されており、非常にうまく機能するため、この質問はそれ自体をキャッシングすることに関するものではありません。したがって、キャッシュの使用状況は良好です。

ゴール

1台のマシンで40Gbps以上のスループットを実現します。

ハードウェア1

ハードウェア：Supermicro SC825、X11SSL-F、Xeon E3-1230v5（4C/8T@3.4GHz）、16GB DDR4 RAM、2x Supermicro 10G STGN-i1S（LACP L3 + 4）

SSD：512G​​B Samsung x 1、500GB Samsung x 2、480GB Intel 535 x 2、240GB Intel S3500 x 1

システム：

• irqbalancerが停止しました
• 各インターフェースのset_irq_affinity（ixgbeドライバーtarballのスクリプトを使用）
• ixgbe-4.3.15
• I / Oスケジューラーの期限
• iptables空（アンロードされたモジュール）
• ファイルシステム：XFS

Nginx：

• sendfile off
• aioスレッド
• directio 1M
• tcp_nopush on
• tcp_nodelay on

グラフからわかるように、12.5Gbpsをプッシュすることができました。残念ながら、サーバーは応答していませんでした。

気になったことが2つあります。1つ目は、大量のIRQです。この場合、残念ながら/ proc / interruptsからのグラフはありません。2番目の問題は、システム負荷が高いことでした。これは、kswapd0が16GのRAMでしか機能しないために発生したと考えられます。

ハードウェア2

ハードウェア：Supermicro SC119TQ、X10DRW-i、2x Xeon E5-2609v4（8C/8T@1.70GHz）、128GB DDR4 RAM、2x Supermicro 10G STGN-i1S

SSD、システム構成はハードウェア1と同じです。nginxはsendfileです（さらにaio / sendfileを比較）。

これはより良いように思えるので、ピーク時に動作するサーバーがあるので、いくつかの最適化を試すことができます。

Sendfileとaioスレッド

sendfileを無効にして、代わりにaioスレッドを使用しようとしました。

• sendfile off
• aioスレッド
• directio 1M（すべてのファイルに一致します）

対

• sendfileを

その後、15：00にsendfileに切り替えてnginxをリロードしました（そのため、既存の接続を完了するのにしばらく時間がかかりました）。ドライブ使用率（iostatで測定）が下がったのは素晴らしいことです。トラフィックに変更はありません（残念ながら、zabbixはbond0からデータを収集しないことを決定しました）。

sendfileのオン/オフ

送信のオン/オフを切り替えてみました。割り込みの再スケジュール以外は何も変更されていません。

server / cron / disabledとしてのirqbalancer

@lsdで述べたように、cron経由で実行されるようにirqbalancerを設定しようとしました：

*/5 * * * *   root    /usr/sbin/irqbalance --oneshot --debug 3 > /dev/null

残念ながら、私の場合は役に立ちませんでした。ネットワークカードの1つが異常な動作を始めました：

グラフのどこに問題があるのか​​を見つけることができませんでした。翌日に再び発生したため、サーバーにログインして、1つのコアが100％（システム使用率）であることがわかりました。

irqbalanceをサービスとして開始しようとしましたが、結果は同じでした。

次に、set_irq_affinityスクリプトを使用することを決定し、それによって問題がすぐに修正され、サーバーは再び17Gbpsをプッシュしました。

ハードウェア3

新しいハードウェアにアップグレードしました：2U 24（+2）ドライブシャーシ（6xSFF）、2x Xeon E5-2620v4、64GB DDR4 RAM（4x16GBモジュール）、13x SSD、2x Supermicro（Intelチップ搭載）ネットワークカード。新しいCPUはパフォーマンスを大幅に改善しました。

現在の設定はそのままです-sendfileなど。唯一の違いは、（set_irq_affinityスクリプトを介して）単一のCPUで両方のネットワークカードを処理できることです。

20Gbpsの制限に達しました。

次の目標は？30Gbps。

パフォーマンスを改善する方法についてのアイデアを私に自由に発射してください。私はそれをライブでテストし、ここでいくつかの重いグラフを共有したいと思います。

CPUで大量のSoftIRQを処理する方法はありますか？

これはキャパシティプランニングについての質問ではありません。すでにハードウェアとトラフィックを持っています。私はいつでもトラフィックをいくつかのサーバーに分割し（とにかくこれをやらなければならないでしょう）、お金の問題を解決できます。ただし、これは、実際のシナリオでのシステムの最適化とパフォーマンスの調整に関する問題です。

免責事項：同じアドバイスが10Gbpsを超えるすべてのサービスに適用されます。ロードバランサー、キャッシングサーバー、ウェブサーバー（HAProxy、Varnish、nginx、tomcatなど）が含まれていますが、これらに限定されません。

あなたがしたいことは間違っています、それをしないでください

代わりにCDNを使用してください

CDNはキャッシュ可能な静的コンテンツを配信するためのものです。仕事に適したツールを使用する（akamai、MaxCDN、cloudflare、cloudfrontなど）

CDNは、無料のものでも、自分で達成できるものよりも優れています。

代わりに水平方向にスケーリング

単一のサーバーで、1〜5 Gbpsの設定を調整せずに処理できることを期待しています（注：静的ファイルのみを提供）。8-10Gbpsは通常、高度なチューニングで到達可能です。

それでも、1つのボックスがとることができるものには多くの厳しい制限があります。水平方向にスケーリングすることをお勧めします。

単一のボックスを実行し、物事を試し、測定し、ベンチマークし、最適化します...そのボックスが信頼性と信頼性があり、その機能が十分に決定されるまで、グローバルロードバランサーを前面に配置して、より多くのボックスを配置します。

いくつかのグローバルな負荷分散オプションがあります：ほとんどのCDNはそれを行うことができます、DNSラウンドロビン、ELB / Googleロードバランサー...

良い習慣を無視して、とにかくやってみましょう

トラフィックパターンを理解する

            WITHOUT REVERSE PROXY

[request ]  user ===(rx)==> backend application
[response]  user <==(tx)===     [processing...]

考慮すべき点が2つあります。帯域幅と方向（放出または受信）です。

HTTPヘッダーとTCPオーバーヘッドがファイルの内容よりも大きいため、小さなファイルは50/50 tx / rxです。

リクエストサイズはレスポンスサイズと比較して無視できるため、大きなファイルは90/10 tx / rxです。

            WITH REVERSE PROXY

[request ]  user ===(rx)==> nginx ===(tx)==> backend application
[response]  user <==(tx)=== nginx <==(rx)===     [processing...]

リバースプロキシは、すべてのメッセージを双方向で中継しています。負荷は常に50/50で、トラフィックの合計は2倍になります。

キャッシングを有効にすると、さらに複雑になります。リクエストはハードドライブに転送され、そのデータはメモリにキャッシュされます。

注：この投稿ではキャッシングの側面を無視します。ネットワークで10〜40 Gbpsを取得することに焦点を当てます。データがキャッシュからのものであるかどうかを知り、そのキャッシュを最適化することは別のトピックであり、どちらの方法でもネットワーク経由でプッシュされます。

モノコアの制限

ロードバランシングはモノコアです（特にTCPバランシング）。コアを追加しても速くはなりませんが、遅くなる可能性があります。

シンプルモードのHTTPバランシング（IP、URL、Cookieベースなど）でも同じです。リバースプロキシは、ヘッダーを即座に読み取ります。厳密には、HTTPリクエストを解析したり処理したりしません。

HTTPSモードでは、SSL復号化/暗号化は、プロキシに必要な他のすべてのものよりも集中的です。SSLトラフィックは、複数のコアに分割でき、分割する必要があります。

SSL

SSLを介してすべてを行うことを考えると、その部分を最適化する必要があります。

オンザフライで40 Gbpsを暗号化および復号化することは、かなりの成果です。

AES-NI命令（SSL操作に使用）を備えた最新世代のプロセッサーを取ります。

証明書で使用されるアルゴリズムを調整します。多くのアルゴリズムがあります。CPUで最も効果的なもの（ベンチマークを実行）がクライアントによってサポートされ、十分に安全である（必要以上の暗号化は不要）必要があります。

IRQとコアの固定

読み取る新しいデータがあり、CPUがプリエンプトされてすぐにキューを処理する場合、ネットワークカードは割り込み（IRQ）を生成しています。これはカーネルやデバイスドライバーで実行される操作であり、厳密にモノコアです。

これは、あらゆる方向に送信される数十億のパケットで最大のCPU消費者になることができます。

ネットワークカードに一意のIRQ番号を割り当て、特定のコアにピン留めします（linuxまたはBIOS設定を参照）。

リバースプロキシを他のコアに固定します。私たちはこれら2つのことを妨害したくありません。

イーサネットアダプター

ネットワークカードは、多くの面倒な作業を行っています。パフォーマンスに関しては、すべてのデバイスとメーカーが同じではありません。

マザーボード上の統合アダプターを忘れて（サーバーとコンシューマーマザーボードのどちらでもかまいません）、問題はありません。

TCPオフロード

TCPは、処理（チェックサム、ACK、再送信、パケットの再構成など）に関して非常に集中的なプロトコルです。カーネルはほとんどの作業を処理していますが、一部の操作は、サポートしている場合はネットワークカードにオフロードできます。

比較的速いカードだけではなく、すべての機能を備えたカードが必要です。

Intel、Mellanox、Dell、HPなどは何も忘れてください。それらのすべてをサポートしているわけではありません。

テーブルには1つのオプションしかありません。SolarFlare - HFT企業とCDNの秘密兵器。

世界は、「SolarFlareを知っている人」と「知らない人」の 2種類に分かれています。（最初のセットは、「10 Gbpsネットワーキングを行い、あらゆる点に注意を払う人々」と厳密に同等です）。しかし、私は余談ですが、焦点を当てましょう：D

カーネルTCPチューニング

にsysctl.confはカーネルネットワークバッファのオプションがあります。これらの設定が行うこと、または行わないこと。本当にわからない。

net.core.wmem_max
net.core.rmem_max
net.core.wmem_default
net.core.rmem_default

net.ipv4.tcp_mem
net.ipv4.tcp_wmem
net.ipv4.tcp_rmem

これらの設定をいじることは、過剰最適化の決定的な兆候です（つまり、一般的に役に立たないか、逆効果です）。

例外的に、それは極端な要件を考えると理にかなっているかもしれません。

（注：1つのボックスで40Gbpsは最適化が行き過ぎです。合理的なルートは水平方向にスケーリングすることです。）

いくつかの物理的制限

メモリ帯域幅

メモリ帯域幅に関する数値（主にGB / s）：http : //www.tweaktown.com/articles/6619/crucial-ddr4-memory-performance-overview-early-look-vs-ddr2-ddr3/index.html

メモリ帯域幅の範囲が150〜300 Gbpsであるとしましょう（理想的な条件での最大制限）。

すべてのパケットは、ある時点でメモリに存在する必要があります。40 Gbpsのラインレートでデータを取り込むだけでは、システムに大きな負荷がかかります。

データを処理する力は残っていますか？さて、それについて私たちの期待を高くしすぎないでください。^^

PCI-Expressバス

PCIe 2.0は、レーンあたり4 Gb /秒です。PCIe 3.0はレーンあたり8 Gbpsです（PCIカードですべてが利用できるわけではありません）。

単一のイーサネットポートを備えた40 Gbps NICは、v3.0仕様でコネクタの長さが16倍未満の場合、PCIeバスよりも有望です。

その他の

他の制限を超える可能性があります。ポイントは、ハードウェアには物理法則に固有の厳しい制限があるということです。

ソフトウェアは、それが実行されているハードウェアよりも優れた性能を発揮できません。

ネットワークバックボーン

これらのパケットはすべて、最終的にどこかに行く必要があり、スイッチとルーターを通過します。10 Gbpsのスイッチとルーターは[ほとんど]汎用品です。40 Gbpsは間違いなく違います。

また、帯域幅はエンドツーエンドでなければならないので、ユーザーにはどのような種類のリンクがありますか？

前回、データセンターの担当者に1,000万人のユーザーサイドプロジェクトを確認したところ、最大10ギガビットのインターネットへのリンクが2つしかないことは明らかでした。

ハードドライブ

iostat -xtc 3

指標は読み取りと書き込みで分割されます。キュー（<1が良い）、待ち時間（<1 msが良い）、転送速度（速いほど良い）を確認します。

ディスクが遅い場合、解決策はレイド10にさらに大きなSSDを配置することです（SSD帯域幅はSSDサイズに比例して増加することに注意してください）。

CPUの選択

IRQおよびその他のボトルネックは1つのコアでのみ実行されるため、最高のシングルコアパフォーマンス（つまり、最高の周波数）を持つCPUを目指します。

SSL暗号化/復号化にはAES-NI命令が必要なので、CPUの最新リビジョンのみを対象にしてください。

SSLは複数のコアから利益を得るので、多くのコアを目指します。

要するに、理想的なCPUは、利用可能な最高の周波数と多くのコアを備えた最新のCPUです。最も高価なものを選ぶだけで、おそらくそれだけです：D

ファイルを送信（）

Sendfile ON

高性能Webサーバー向けの最新カーネルの最大の進歩です。

最終メモ

1 SolarFlare NIC 40 Gbps (pin IRQ and core)
2 SolarFlare NIC 40 Gbps (pin IRQ and core)
3 nginx master process
4 nginx worker
5 nginx worker
6 nginx worker
7 nginx worker
8 nginx worker
...

1つは1つのCPUに固定されました。それは行く方法です。

外の世界につながる1つのNIC。内部ネットワークにつながる1つのNIC。責任の分割は常に適切です（ただし、デュアル40 Gbps NICはやりすぎかもしれません）。

それは微調整すべき多くの事柄であり、そのいくつかは小さな本の主題であるかもしれません。そのすべてのベンチマークを楽しんでください。戻って結果を公開してください。

評判のため、まだコメントできません。回答を追加する必要があります...

最初の例では、次のように言っています。

気になったことが2つあります。1つ目は、大量のIRQです。この場合、残念ながら/ proc / interruptsからのグラフはありません。2番目の問題は、システム負荷が高いことでした。これは、kswapd0が16GのRAMでしか機能しないために発生したと考えられます。

これらは重要なポイントであることに絶対に同意します。

1. IRRDを収集してRRDを使用して保存できるcollectdエージェントを使用してみてください。

2. メモリ使用量のグラフはありますか？

   表面的には、これはCPUの問題のように見えますが、多くのハードまたはソフトページフォールトが発生している場合、高いsoftirq％はメモリに指を向けるだけかもしれません。ギブアウェイは、19時頃にシステムCPUを犠牲にしたIRQの突然のエスカレーションだと思います。

私がスペックから見ることができるものから、すべてを除いてすべてが同じに見えます：

• 想い出
• CPUモデル-私が間違っていない限り、ベンチマークはそれらが類似しているはずであることを示します。このようなケースでは、より高速なコアの少ないボックスを好みます。