Ich möchte in dieser Frage die bestmögliche Konfiguration / Hardware für die Bereitstellung von 40 Gbit / s von einem einzelnen Server herausfinden.

Lage

Wir haben einen Video-Share-Proxy-Server, der Spitzen von langsamen Speicherservern dahinter auslagert. Der gesamte Datenverkehr ist nur HTTP. Der Server fungiert als Reverse-Proxy (Dateien, die nicht auf dem Server zwischengespeichert sind) und als Webserver (Dateien, die auf lokalen Laufwerken gespeichert sind).

Derzeit befinden sich etwa 100 TB Dateien auf den Backend-Speicherservern.

Der Caching-Mechanismus wird unabhängig implementiert und bei dieser Frage geht es nicht um das Caching selbst, da er sehr gut funktioniert. Derzeit werden 14 Gbit / s bereitgestellt und nur 2 Gbit / s an die Back-End-Server übergeben. Die Cache-Nutzung ist also gut.

Tor

Erzielen Sie mit einer einzelnen Maschine einen Durchsatz von 40 Gbit / s oder mehr.

Hardware 1

HW: Supermicro SC825, X11SSL-F, Xeon E3-1230v5 (4C/8T@3,4 GHz), 16 GB DDR4-RAM, 2x Supermicro 10G STGN-i1S (LACP L3 + 4)

SSD: 1x 512 GB Samsung, 2x 500 GB Samsung, 2x480 GB Intel 535, 1x 240 GB Intel S3500

System:

• irqbalancer stoppte
• set_irq_affinity für jede Schnittstelle (per Skript im ixgbe-Treiber tarball)
• ixgbe-4.3.15
• Frist für den E / A-Planer
• iptables leer (entladene Module)
• Dateisystem: XFS

Nginx:

• sendfile off
• Aio-Threads
• directio 1M
• tcp_nopush ein
• tcp_nodelay on

Wie in den Grafiken zu sehen ist, konnten wir 12,5 Gbit / s pushen. Leider reagierte der Server nicht.

Es gibt zwei Dinge, die meine Aufmerksamkeit erregt haben. Der erste ist eine hohe Menge an IRQ. In diesem Fall habe ich leider keine Grafiken von / proc / interrupts. Das zweite Problem war die hohe Systemlast, die meiner Meinung nach darauf zurückzuführen ist, dass kswapd0 Probleme hatte, nur mit 16 GB RAM zu arbeiten.

Hardware 2

HW: Supermicro SC119TQ, X10DRW-i, 2x Xeon E5-2609v4 (8C/[email protected]), 128 GB DDR4-RAM, 2x Supermicro 10G STGN-i1S

SSD, Systemkonfiguration sind identisch mit Hardware 1. Nginx ist sendfile on (aio / sendfile weiter verglichen).

Dies scheint besser zu sein. Da wir nun einen Server haben, der in Spitzen arbeitet, können wir einige Optimierungen ausprobieren.

Sendfile vs Aio Threads

Ich habe versucht, sendfile zu deaktivieren und stattdessen aio-Threads zu verwenden.

• sendfile off
• Aio-Threads
• directio 1M (entspricht allen Dateien, die wir haben)

vs.

• sendfile on

Um 15:00 Uhr wechselte ich dann zurück zu sendfile und lud nginx neu (es dauerte also eine Weile, bis die bestehenden Verbindungen hergestellt waren). Es ist schön, dass die Laufwerksauslastung (gemessen von iostat) gesunken ist. Am Datenverkehr hat sich nichts geändert (leider hat zabbix beschlossen, die Daten von bond0 nicht zu sammeln).

sendfile ein / aus

Ich habe gerade versucht, das Senden ein- oder auszuschalten. Es hat sich nichts geändert, außer Interrupts neu zu planen.

irqbalancer als Server / cron / disabled

Wie @lsd erwähnt habe ich versucht, irqbalancer so einzurichten, dass es über cron ausgeführt wird:

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

Leider hat es in meinem Fall nicht geholfen. Eine der Netzwerkkarten verhielt sich merkwürdig:

Ich konnte nicht finden, was in Grafiken falsch war, und als es am nächsten Tag wieder passierte, loggte ich mich beim Server ein und stellte fest, dass ein Kern zu 100% ausgelastet war (Systemnutzung).

Ich habe versucht, irqbalance als Service zu starten, das Ergebnis war immer noch das gleiche.

Dann entschied ich mich für das Skript set_irq_affinity und es behebte das Problem sofort und der Server drückte erneut 17 Gbit / s.

Hardware 3

Wir haben ein Upgrade auf neue Hardware durchgeführt: 2U 24 (+2) Laufwerksgehäuse (6xSFF), 2x Xeon E5-2620v4, 64 GB DDR4-RAM (4x16 GB Module), 13x SSD, 2x Supermicro-Netzwerkkarten (mit Intel-Chip). Neue CPUs haben die Leistung erheblich verbessert.

Das aktuelle Setup bleibt erhalten - sendfile usw. Der einzige Unterschied besteht darin, dass nur eine einzige CPU beide Netzwerkkarten verarbeiten kann (über das Skript set_irq_affinity).

Das 20-Gbit / s-Limit wurde erreicht.

Nächste Ziel? 30 Gbit / s.

Fühlen Sie sich frei, mir Ideen zu geben, wie Sie die Leistung verbessern können. Ich werde es gerne live testen und hier einige schwere Grafiken teilen.

Irgendwelche Ideen, wie man mit einer großen Anzahl von SoftIRQs auf der CPU umgeht?

Dies ist keine Frage der Kapazitätsplanung - ich habe bereits die Hardware und den Datenverkehr. Ich kann den Datenverkehr jederzeit auf mehrere Server aufteilen (was ich in Zukunft sowieso tun muss) und das Problem mit Geld beheben. Dies ist jedoch eine Frage zur Systemoptimierung und Leistungsoptimierung in einem realen Live-Szenario.

Haftungsausschluss : Der gleiche Hinweis gilt für alle Dienste mit mehr als 10 Gbit / s. Enthalten, aber nicht beschränkt auf Load Balancer, Caching-Server, Webserver (HAProxy, Varnish, Nginx, Tomcat, ...)

Was Sie tun möchten, ist falsch, tun Sie es nicht

Verwenden Sie stattdessen ein CDN

CDN sollen zwischenspeicherbare statische Inhalte liefern. Verwenden Sie das richtige Tool für den Job (Akamai, MaxCDN, Cloudflare, Cloudfront, ...)

Jedes CDN, auch ein kostenloses, kann besser als alles, was Sie alleine erreichen können.

Skalieren Sie stattdessen horizontal

Ich erwarte, dass ein einzelner Server sofort 1-5 Gbit / s ohne große Anpassungen verarbeitet (Hinweis: Nur statische Dateien bereitstellen). Die 8-10 Gbit / s sind normalerweise mit erweiterter Abstimmung in Reichweite.

Trotzdem gibt es viele harte Grenzen, was eine einzelne Box aufnehmen kann. Sie sollten es vorziehen, horizontal zu skalieren.

Führen Sie eine einzelne Box aus, probieren Sie Dinge aus, messen Sie, messen Sie sie, optimieren Sie sie ... bis diese Box zuverlässig und zuverlässig ist und ihre Fähigkeiten gut bestimmt sind, und stellen Sie dann weitere Boxen wie diese mit einem globalen Load Balancer vor.

Es gibt einige globale Optionen für den Lastenausgleich: Die meisten CDN können dies, DNS-Roundrobin, ELB / Google-Lastenausgleich ...

Lassen Sie uns die guten Praktiken ignorieren und es trotzdem tun

Das Verkehrsmuster verstehen

            WITHOUT REVERSE PROXY

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

Es sind zwei Dinge zu beachten: die Bandbreite und die Richtung (Senden oder Empfangen).

Kleine Dateien sind 50/50 tx / rx, da die HTTP-Header und der TCP-Overhead größer sind als der Dateiinhalt.

Große Dateien haben eine Größe von 90/10 tx / rx, da die Anforderungsgröße im Vergleich zur Antwortgröße vernachlässigbar ist.

            WITH REVERSE PROXY

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

Der Reverse-Proxy leitet alle Nachrichten in beide Richtungen weiter. Die Last beträgt immer 50/50 und der Gesamtverkehr wird verdoppelt.

Bei aktiviertem Caching wird es komplexer. Anforderungen können auf die Festplatte umgeleitet werden, deren Daten im Speicher zwischengespeichert werden können.

Hinweis : Ich werde den Caching-Aspekt in diesem Beitrag ignorieren. Wir werden uns darauf konzentrieren, 10-40 Gbit / s im Netzwerk zu erreichen. Wenn Sie wissen, ob die Daten aus dem Cache stammen, und diesen Cache optimieren, ist dies ein weiteres Thema.

Monocore-Einschränkungen

Der Lastausgleich ist ein Monocore (insbesondere der TCP-Ausgleich). Das Hinzufügen von Kernen macht es nicht schneller, aber es kann es langsamer machen.

Gleiches gilt für den HTTP-Ausgleich mit einfachen Modi (z. B. IP, URL, Cookie-basiert. Der Reverse-Proxy liest Header im laufenden Betrieb, analysiert oder verarbeitet HTTP-Anforderungen nicht im engeren Sinne).

Im HTTPS-Modus ist die SSL-Entschlüsselung / Verschlüsselung intensiver als alles andere, was für das Proxy erforderlich ist. SSL-Verkehr kann und sollte auf mehrere Kerne aufgeteilt werden.

SSL

Vorausgesetzt, Sie machen alles über SSL. Sie möchten diesen Teil optimieren.

Das schnelle Ver- und Entschlüsseln von 40 Gbit / s ist ein ziemlicher Erfolg.

Nehmen Sie einen Prozessor der neuesten Generation mit den AES-NI-Anweisungen (für SSL-Vorgänge).

Optimieren Sie den von den Zertifikaten verwendeten Algorithmus. Es gibt viele Algorithmen. Sie möchten diejenige, die auf Ihrer CPU am effektivsten ist (Benchmarking durchführen), während sie von Clients unterstützt wird UND gerade sicher genug ist (keine notwendige Überverschlüsselung).

IRQ und Core Pinning

Die Netzwerkkarte generiert Interrupts (IRQ), wenn neue Daten gelesen werden müssen und die CPU vorbelegt ist, um die Warteschlange sofort zu verarbeiten. Es ist eine Operation, die im Kernel und / oder in den Gerätetreibern ausgeführt wird und streng monokern ist.

Es kann der größte CPU-Verbraucher sein, da Milliarden von Paketen in alle Richtungen gesendet werden.

Weisen Sie der Netzwerkkarte eine eindeutige IRQ-Nummer zu und befestigen Sie sie an einem bestimmten Kern (siehe Linux- oder BIOS-Einstellungen).

Stecken Sie den Reverse-Proxy in andere Kerne. Wir wollen nicht, dass diese beiden Dinge sich gegenseitig stören.

Ethernet-Adapter

Die Netzwerkkarte macht einen Großteil des schweren Hebens. In Bezug auf die Leistung sind nicht alle Geräte und Hersteller gleich.

Vergessen Sie den integrierten Adapter auf Motherboards (egal ob Server- oder Consumer-Motherboard), sie saugen nur.

TCP-Entladung

TCP ist ein sehr intensives Protokoll in Bezug auf die Verarbeitung (Prüfsummen, ACK, Neuübertragung, Zusammensetzen von Paketen, ...). Der Kernel erledigt den größten Teil der Arbeit, aber einige Vorgänge können auf die Netzwerkkarte verlagert werden, wenn er dies unterstützt.

Wir wollen nicht nur eine relativ schnelle Karte , wir wollen eine mit allen Schnickschnack.

Vergessen Sie Intel, Mellanox, Dell, HP, was auch immer. Sie unterstützen das alles nicht.

Es gibt nur eine Option auf dem Tisch: SolarFlare - Die Geheimwaffe von HFT-Firmen und CDN.

Die Welt ist in zwei Arten von Menschen aufgeteilt: " diejenigen, die SolarFlare kennen " und " diejenigen, die dies nicht tun ". (Der erste Satz entspricht genau " Personen, die 10-Gbit / s-Netzwerke betreiben und sich um jedes Bit kümmern "). Aber ich schweife ab, konzentrieren wir uns: D.

Kernel-TCP-Optimierung

Es gibt Optionen sysctl.conffür Kernel-Netzwerkpuffer. Was diese Einstellungen tun oder nicht. Ich weiß es wirklich nicht.

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

Das Spielen mit diesen Einstellungen ist das endgültige Zeichen für eine Überoptimierung (dh im Allgemeinen nutzlos oder kontraproduktiv).

In Ausnahmefällen könnte dies angesichts der extremen Anforderungen sinnvoll sein.

(Hinweis: 40 Gbit / s auf einer einzelnen Box sind zu stark optimiert. Der vernünftige Weg besteht darin, horizontal zu skalieren.)

Einige physikalische Grenzen

Speicherbandbreite

Einige Zahlen zur Speicherbandbreite (meistens in GB / s): http://www.tweaktown.com/articles/6619/crucial-ddr4-memory-performance-overview-early-look-vs-ddr2-ddr3/index.html

Angenommen, der Bereich für die Speicherbandbreite liegt zwischen 150 und 300 Gbit / s (maximale Grenze unter idealen Bedingungen).

Alle Pakete müssen irgendwann im Speicher sein. Das bloße Aufnehmen von Daten mit einer Leitungsrate von 40 Gbit / s ist eine schwere Belastung für das System.

Wird es noch Strom geben, um die Daten zu verarbeiten? Lassen Sie uns unsere Erwartungen nicht zu hoch setzen. Ich sage nur ^^

PCI-Express-Bus

PCIe 2.0 beträgt 4 Gbit / s pro Spur. PCIe 3.0 ist 8 Gbit / s pro Lane (nicht alles ist für die PCI-Karte verfügbar).

Eine 40-Gbit / s-Netzwerkkarte mit einem einzigen Ethernet-Port verspricht mehr als der PCIe-Bus, wenn der Anschluss gemäß den v3.0-Spezifikationen weniger als 16x lang ist.

Andere

Wir könnten andere Grenzen überschreiten. Der Punkt ist, dass Hardware dem Gesetz der Physik harte Einschränkungen unterliegt.

Software kann nicht besser sein als die Hardware, auf der sie ausgeführt wird.

Das Netzwerk-Backbone

Alle diese Pakete müssen irgendwann irgendwohin gehen und Switches und Router durchlaufen. Die 10-Gbit / s-Switches und der Router sind [fast] eine Ware. Die 40 Gbit / s sind definitiv nicht.

Außerdem muss die Bandbreite durchgehend sein. Welche Art von Links haben Sie zum Benutzer?

Als ich das letzte Mal bei meinem Rechenzentrums-Mitarbeiter nach einem kleinen Projekt auf der Seite von 10 Millionen Benutzern gesucht habe, war ihm ziemlich klar, dass es höchstens 2x 10-Gbit-Links zum Internet geben würde.

Festplatte

iostat -xtc 3

Metriken werden durch Lesen und Schreiben aufgeteilt. Überprüfen Sie die Warteschlange (<1 ist gut), die Latenz (<1 ms ist gut) und die Übertragungsgeschwindigkeit (je höher desto besser).

Wenn die Festplatte langsam ist, besteht die Lösung darin, mehr UND größere SSD in RAID 10 zu platzieren (beachten Sie, dass die SSD-Bandbreite linear mit der SSD-Größe zunimmt).

CPU-Auswahl

IRQ und andere Engpässe laufen nur auf einem Kern. Streben Sie daher die CPU mit den höchsten Einzelkernleistungen (dh der höchsten Frequenz) an.

Für die SSL-Verschlüsselung / -Entschlüsselung sind die AES-NI-Anweisungen erforderlich. Ziel ist daher nur die neueste Version der CPU.

SSL profitiert von mehreren Kernen, daher sollten viele Kerne angestrebt werden.

Lange Rede, kurzer Sinn: Die ideale CPU ist die neueste mit der höchsten verfügbaren Frequenz und vielen Kernen. Wählen Sie einfach das teuerste und das ist es wahrscheinlich: D.

Datei senden()

Sendedatei EIN

Einfach der größte Fortschritt moderner Kernel für leistungsstarke Webserver.

Schlussbemerkung

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
...

Eine Sache war auf eine CPU beschränkt. Das ist der richtige Weg.

Eine Netzwerkkarte, die zur Außenwelt führt. Eine Netzwerkkarte, die zum internen Netzwerk führt. Das Aufteilen von Verantwortlichkeiten ist immer nett (obwohl eine doppelte 40-Gbit / s-Netzwerkkarte möglicherweise übertrieben ist).

Das sind viele Dinge, die fein abgestimmt werden müssen, von denen einige Gegenstand eines kleinen Buches sein könnten. Viel Spaß beim Benchmarking. Kommen Sie zurück, um die Ergebnisse zu veröffentlichen.

Ich kann aufgrund des guten Rufs noch keinen Kommentar abgeben, muss also stattdessen eine Antwort hinzufügen ...

Im ersten Beispiel sagten Sie:

Es gibt zwei Dinge, die meine Aufmerksamkeit erregt haben. Der erste ist eine hohe Menge an IRQ. In diesem Fall habe ich leider keine Grafiken von / proc / interrupts. Das zweite Problem war die hohe Systemlast, die meiner Meinung nach darauf zurückzuführen ist, dass kswapd0 Probleme hatte, nur mit 16 GB RAM zu arbeiten.

Stimmen Sie absolut zu, dass dies wichtige Punkte sind.

1. Versuchen Sie es mit dem Collectd Agent, der IRQs sammeln und mit RRD speichern kann.

2. Haben Sie eine Tabelle zur Speichernutzung?

   An der Oberfläche sieht dies wie ein CPU-Problem aus. Der hohe Softirq% zeigt möglicherweise nur mit dem Finger auf den Speicher, wenn viele harte oder weiche Seitenfehler auftreten. Ich denke, das Give-away ist die plötzliche Eskalation der IRQs auf Kosten der System-CPU gegen 19:00 Uhr.

Nach allem, was ich aus den technischen Daten ersehen kann, sieht alles gleich aus, abgesehen von:

• die Erinnerung
• die CPU-Modelle - wenn ich mich nicht irre, würden Benchmarks anzeigen, dass sie ähnlich sein sollten, und in solchen Fällen würde ich die Box mit weniger schnelleren Kernen bevorzugen.