2009-11-07 12 views
5

Ci sono dei limiti imposti dalla memoria disponibile, dalla larghezza di banda, dalla CPU e, naturalmente, dalla connettività di rete. Ma quelli possono spesso essere ridimensionati verticalmente. Ci sono altri fattori limitanti su Linux? Possono essere superati senza modifiche al kernel? Sospetto che, se non altro, il fattore limitante diventerebbe la gigabit ethernet. Ma per protocolli efficienti potrebbe richiedere 50K connessioni simultanee per sommergerla. Qualcos'altro si romperebbe prima che potessi arrivare così in alto?Quante connessioni aperte udp o tcp/ip possono avere una macchina Linux?

Sto pensando che voglio un software udp e/o tcp/ip load balancer. Sfortunatamente non sembra esistere nulla di simile nella comunità open source, ad eccezione del protocollo http. Ma non è al di là delle mie capacità scrivere uno con epoll. Mi aspetto che ciò comporti un gran numero di modifiche per farlo scalare, ma questo è un lavoro che può essere fatto in modo incrementale, e sarei un programmatore migliore per questo.

risposta

1

Alla tua domanda, sei limitato solo dai limiti hardware. Questa era la filosofia del design per i sistemi linux. Descrivi esattamente quali sarebbero i tuoi fattori limitanti.

4

L'unico parametro che probabilmente avrà qualche difficoltà è jitter. Hai scalato il numero di connessioni per scatola, indubbiamente metti a dura prova tutte le risorse di detto sistema. Di conseguenza, le caratteristiche di jitter jitter della funzione di inoltro risentiranno probabilmente.

A seconda delle esigenze di destinazione, che potrebbe o non essere un problema: se si prevede di supportare principalmente elastica traffico (traffico, che non soffre molto dal jitter e latenza), allora è ok. Se la proporzione del traffico di inelastica è elevata (ad esempio interattiva voce/video), questo potrebbe essere più di un problema.

Naturalmente si può sempre sopra ingegnere in questo caso ;-)

+0

si alza un buon punto su jitter e latenza e l'effetto sul traffico anelastica – Eloff

+4

sarebbe il persona che ha votato il mio post cura per spiegare? il down-voting drive-by senza commenti è semplicemente scortese. – jldupont

+0

Per TCP, l'altra preoccupazione è la quantità di dati in entrata. I dati in arrivo occupano i buffer del kernel fino a quando non vengono elaborati da un processo utente. Se l'applicazione non elabora la memoria "abbastanza veloce", il kernel può rimanere senza panico e buffer. Questo può essere migliorato impostando una piccola dimensione del buffer Rx su ciascun socket. –

2

Se avete intenzione di avere un server che contiene un socket aperto per cliente, quindi ha bisogno di essere progettato con cura in modo che possa efficacemente verificare la presenza di dati in arrivo da 10k + client. Questo è noto come il problema 10k.

I moderni kernel Linux possono gestire molto più di 10k connessioni, in genere almeno 100k. Potrebbe essere necessario un po 'di tuning, in particolare i numerosi timeout TCP (se si utilizza TCP) per evitare la chiusura/i socket obsoleti utilizzando molte risorse se molti client si connettono e si disconnettono frequentemente.

Se si utilizza il modulo conntrack di netfilter, potrebbe essere necessaria anche la regolazione per tenere traccia di molte connessioni (questo è indipendente dai socket tcp/udp).

Esistono molte tecnologie per il bilanciamento del carico, il più noto è LVS (Linux Virtual Server) che può fungere da front-end per un cluster di server reali. Non so quante connessioni possa gestire, ma penso che la usiamo con almeno 50k di produzione.

0

Prova HAProxy carico software bilanciatore: (. Vale a dire in particolare il tipo di traffico si usa UDP per)

http://haproxy.1wt.eu/

Problemi correlati