Ich habe einen Server mit 8 Kernen bereitgestellt und plane, einen Netzwerkdienst bereitzustellen. Um die Anforderungslast zu verteilen, möchte ich 8 Instanzen meines Dienstes ausführen. Nichts Überraschendes dabei. Ich habe keinen Zugriff auf einen Hardware-Load Balancer. Ich sollte erwähnen, dass mir derzeit 5 öffentliche IP-Adressen zugewiesen sind (ich kann aber mehr bekommen).
Daher würde ich gerne Ihre Empfehlungen zum Aufbau einer Software-Lastausgleichslösung hören.
Die offensichtlichen Möglichkeiten wären entweder:
- verwenden Sie HAProxy; oder
- meine Anwendung vorab verzweigen (wie es sowohl Facebook Tornado als auch Unicorn tun);
- Tragen Sie hier Ihre Idee ein.
Meine Ziele sind:
- Verteilen Sie die Anfragelast auf die Serviceinstanzen.
- Ermöglichen Sie fortlaufende Neustarts meines Dienstes (Code-Upgrades).
Ich sollte erwähnen, dass dies kein HTTP-basierter Dienst ist, sodass NGiNX und ähnliche Dienste nicht in Frage kommen.
Ich bin kein Fan von HAProxy wegen seines Speicherbedarfs; es scheint einen Lese- und Schreibpuffer pro Clientverbindung zu erfordern. Daher hätte ich Puffer auf Kernelebene, in HAProxy und in meiner Anwendung. Das ist albern! Vielleicht übersehe ich in dieser Hinsicht aber etwas?
Danke!
Antwort1
egal welche Lösung Sie verwenden, wenn Sie einen Prozess zum Weiterleiten von Stream-Daten installieren, werden Puffer pro Verbindung benötigt. Das liegt daran, dass Sie nicht immer alles senden können, was Sie empfangen haben, also müssen Sie den Überschuss in einem Puffer aufbewahren. Der Speicherverbrauch hängt jedoch von der Anzahl gleichzeitiger Verbindungen ab. Eine große Site betreibt Haproxy problemlos mit Standardeinstellungen bei 150.000 gleichzeitigen Verbindungen (4 GB RAM). Wenn Sie mehr benötigen, können Sie die Puffergröße mit Version 1.4 anpassen, ohne neu kompilieren zu müssen. Bedenken Sie jedoch, dass die Kernelpuffer pro Socket nie unter 4 kB pro Richtung und pro Socket fallen, also mindestens 16 kB pro Verbindung. Das bedeutet, dass es sinnlos ist, Haproxy mit weniger als 8 kB pro Puffer laufen zu lassen, da es bereits weniger verbraucht als der Kernel.
Wenn Ihr Dienst reines TCP ist und ein Proxy keinen Mehrwert bietet, sollten Sie sich netzwerkbasierte Lösungen wie LVS ansehen. Diese sind viel günstiger, da sie Pakete verarbeiten und keine Puffer verwalten müssen. Socket-Puffer löschen Pakete, wenn sie voll sind. Außerdem können sie auf derselben Maschine wie der Dienst installiert werden.
Bearbeiten: Javier, vorgeforkte Prozesse, die sich auf das Betriebssystem verlassen, um den Lastenausgleich durchzuführen, sind überhaupt nicht so gut skalierbar. Das Betriebssystem erwachtjedenProzess wird gestartet, wenn eine Verbindung hergestellt wird, nur einer von ihnen bekommt sie und alle anderen gehen wieder in den Ruhezustand. Haproxy im Mehrprozessmodus zeigt seine beste Leistung bei etwa 4 Prozessen. Bei 8 Prozessen beginnt die Leistung bereits zu sinken. Apache verwendet einen netten Trick dagegen, es macht eine Sperre um die accept(), so dass nur ein Prozess auf die Annahme wartet. Aber das tötet die Lastausgleichsfunktion des Betriebssystems und stoppt die Skalierung zwischen 1000 und 2000 Prozessen. Es sollte ein Array von einigen Sperren verwenden, damit einige Prozesse aufwachen, aber das tut es nicht.
Antwort2
ohne Einzelheiten zu Ihrem Dienst ist das sehr schwer zu sagen; aber im Allgemeinen würde ich zum Preforking tendieren. Es ist eine bewährte Serverstrategie (und kein neumodischer Trick, wie manche Leute nach dem Lesen der Tornado-/Unicorn-Fanseiten denken).
Darüber hinaus noch ein paar Tipps:
Jeder vorgegabelte Prozess kann moderne Nicht-
selectStrategien (meistens Libevent) verwenden, um eine große Anzahl von Clients zu verarbeiten.Es kommt nur sehr selten vor, dass ein 1:1-Verhältnis zwischen Kernen und Prozessen optimale Leistung liefert. Normalerweise ist es weitaus besser, eine dynamische Anpassung an die Last vorzunehmen.