2009-11-07 10 views
5

Der verfügbare Speicher, die Bandbreite, die CPU und natürlich die Netzwerkkonnektivität sind begrenzt. Aber diese können oft vertikal skaliert werden. Gibt es andere einschränkende Faktoren auf Linux? Können sie ohne Kernel-Modifikationen überwunden werden? Ich vermute, dass der limitierende Faktor zumindest das Gigabit-Ethernet sein würde. Aber für effiziente Protokolle könnte es 50K gleichzeitige Verbindungen brauchen, um das zu überschwemmen. Würde etwas anderes brechen, bevor ich so hoch werden konnte?Wie viele offene UDP- oder TCP/IP-Verbindungen kann ein Linux-Rechner haben?

Ich denke, dass ich eine Software UDP und/oder Tcp/IP Load Balancer wollen. Leider scheint nichts dergleichen in der Open-Source-Gemeinschaft zu existieren, außer dem http-Protokoll. Aber es ist nicht über meine Fähigkeiten, mit epoll zu schreiben. Ich erwarte, dass es viele Optimierungen durchläuft, um es skalieren zu können, aber das ist Arbeit, die inkrementell erledigt werden kann, und ich wäre ein besserer Programmierer dafür.

Antwort

1

Auf Ihre Frage werden Sie nur durch Hardwareeinschränkungen eingeschränkt. Dies war die Design-Philosophie für Linux-Systeme. Sie beschreiben genau, was Ihre einschränkenden Faktoren wären.

4

Der einzige Parameter, mit dem Sie wahrscheinlich Schwierigkeiten haben werden, ist Jitter. Wenn Sie die Anzahl der Verbindungen pro Box skalieren, werden Sie zweifellos alle Ressourcen dieses Systems belasten. Als Ergebnis werden die Jitter Eigenschaften der Weiterleitungsfunktion wahrscheinlich leiden.

Je nach Zielanforderungen, die möglicherweise oder kein Problem sein, wenn Sie vorhaben, vor allem elastischen Verkehr (Verkehr, der von Jitter nicht viel leiden und Latenz) zu unterstützen, dann ist es in Ordnung. Wenn der Anteil von inelastischen Verkehr hoch ist (z. B. interaktiv Sprache/Video), dann könnte dies eher ein Problem sein.

Natürlich können Sie immer über Ingenieur in diesem Fall ;-)

+0

Sie heben einen guten Punkt, um Jitter und Latenz und die Auswirkungen auf dem unelastischen Verkehr – Eloff

+4

würde die Person, die meine Nachsorge abgelehnt hat, um das zu erklären? Drive-by Down-Voting ohne Kommentar ist einfach nur unhöflich. – jldupont

+0

Für TCP ist die andere Sorge die Menge der eingehenden Daten. Eingehende Daten belegen Kernel-Puffer, bis sie von einem Benutzerprozess verarbeitet werden. Wenn Ihre Anwendung den Speicher nicht "schnell genug" verarbeitet, kann der Kernel keine Puffer und keine Panne mehr haben. Dies kann verbessert werden, indem auf jedem Sockel eine kleine Rx-Puffergröße eingestellt wird. –

2

Wenn Sie beabsichtigen, einen Server zu haben, die pro Client eine Buchse offen hält, dann muss es sorgfältig geplant werden, damit sie effizient überprüfen können eingehende Daten von 10k + Clients. Dies ist bekannt als das 10k-Problem.

Moderne Linux-Kernel können viel mehr als 10k Verbindungen, in der Regel mindestens 100k. Möglicherweise müssen Sie etwas abstimmen, insbesondere die vielen TCP-Timeouts (bei Verwendung von TCP), um zu vermeiden, dass geschlossene/veraltete Sockets viele Ressourcen verbrauchen, wenn viele Clients sich häufig verbinden und trennen.

Wenn Sie das contrack-Modul von Netfilter verwenden, muss möglicherweise auch eine Abstimmung durchgeführt werden, um diese vielen Verbindungen zu verfolgen (dies ist unabhängig von tcp/udp-Sockets).

Es gibt viele Technologien für Load-Balancing, der bekannteste ist LVS (Linux Virtual Server), der als Front-End für einen Cluster von echten Servern fungieren kann. Ich weiß nicht, wie viele Verbindungen es kann, aber ich denke, wir verwenden es mit mindestens 50k in der Produktion.

0

Versuchen HAProxy Software Load Balancer: (. Dh speziell die Art von Datenverkehr Sie UDP verwenden würden)

http://haproxy.1wt.eu/