Bilanciamento del carico in Amazon EC2?

Question

Abbiamo combattuto con HAProxy da alcuni giorni su Amazon EC2; l'esperienza è stata finora eccezionale, ma siamo bloccati a spremere più prestazioni dal bilanciamento del carico del software. Non siamo esattamente dei whizz di rete Linux (normalmente siamo un negozio .NET), ma finora abbiamo tenuto il nostro, tentando di impostare ulimits adeguati, ispezionando i messaggi del kernel e tcpdumps per eventuali irregolarità. Finora, tuttavia, abbiamo raggiunto un plateau di circa 1.700 richieste / sec, a quel punto abbondano i timeout dei client (abbiamo usato e ottimizzato httperf per questo scopo). Un collega e io stavamo ascoltando il podcast Stack Overflow più recente, in cui i fondatori di Reddit notano che il loro intero sito scorre su un nodo HAProxy e che finora non è diventato un collo di bottiglia. Ack! O in qualche modo non si vede che molte richieste simultanee, stiamo facendo qualcosa di orribilmente sbagliato, o la natura condivisa di EC2 sta limitando lo stack di rete dell'istanza Ec2 (stiamo usando un tipo di istanza di grandi dimensioni). Considerando il fatto che sia Joel che i fondatori di Reddit concordano sul fatto che la rete sarà probabilmente il fattore limitante, è possibile che sia la limitazione che stiamo vedendo?

Ogni pensiero è molto apprezzato!

Modifica Sembra che il problema reale non fosse, in effetti, con il nodo del bilanciamento del carico! Il colpevole era in realtà i nodi che eseguivano httperf, in questo caso. Poiché httperf crea e riduce un socket per ogni richiesta, trascorre una buona quantità di tempo della CPU nel kernel. Dato che abbiamo aumentato il tasso di richieste più elevato, il TCP FIN TTL (essendo 60s per impostazione predefinita) manteneva i socket troppo a lungo e il valore predefinito di ip_local_port_range era troppo basso per questo scenario di utilizzo. Fondamentalmente, dopo alcuni minuti del nodo client (httperf) che crea e distrugge costantemente nuovi socket, il numero di porte inutilizzate si è esaurito e le successive 'richieste' sono state errate in questa fase, producendo bassi numeri di richiesta / sec e una grande quantità di errori.

Abbiamo anche esaminato nginx, ma abbiamo lavorato con RighScale e hanno script drop-in per HAProxy. Oh, e abbiamo un termine troppo stretto [ovviamente] per sostituire i componenti a meno che non si riveli assolutamente necessario. Misericordiosamente, essere su AWS ci consente di testare un'altra configurazione usando nginx in parallelo (se garantito) e fare il passaggio da un giorno all'altro in seguito.

Questa pagina descrive abbastanza bene ciascuna delle variabili sysctl (ip_local_port_range e tcp_fin_timeout sono stati sintonizzati, in questo caso).

Answer 1

Non proprio una risposta alla tua domanda, ma nginx e pound hanno entrambi una buona reputazione come bilanciamento del carico. Wordpress è passato a nginx con buoni risultati.

Ma più specificamente, per eseguire il debug del problema. Se non visualizzi il 100% di utilizzo della CPU (inclusa l'attesa I / O), allora sei connesso alla rete, sì. EC2 utilizza internamente una rete gigabit, prova a utilizzare un'istanza XL, quindi hai l'hardware sottostante per te e non devi condividere quella porta di rete gigabit.

Answer 2

Non rispondere direttamente alla domanda, ma EC2 ora supporta il bilanciamento del carico tramite Elastic Load Balancing anziché in esecuzione il proprio bilanciamento del carico in un'istanza EC2.

EDIT: il servizio DNS Route 53 di Amazon ora offre un modo per puntare un dominio di primo livello a un ELB con un "alias" disco. Poiché Amazon conosce l'attuale indirizzo IP dell'ELB, può restituire un record A per quell'IP corrente anziché dover utilizzare un record CNAME, pur essendo comunque libero di modificare l'IP di volta in volta.

Answer 3

Sì, potresti usare un bilanciamento del carico off-site .. e su LVS bare metal è un'ottima scelta, ma la tua latenza sarà terribile! Si dice che Amazon risolverà il problema CNAME. Tuttavia, è improbabile che aggiungano https, controlli approfonditi o personalizzati, agenti di feedback, corrispondenza degli URL, inserimento dei cookie (e alcune persone con una buona architettura direbbero anche abbastanza bene.) Tuttavia, ecco perché Scalr, RightScale e altri stanno usando HAProxy di solito due di dietro una voce DNS round robin. Qui su Loadbalancer.org stiamo per lanciare il nostro appaliance di bilanciamento del carico EC2: http: // blog. loadbalancer.org/ec2-load-balancer-appliance-rocks-and-its-free-for-now-anyway/ Stiamo programmando di utilizzare gli script SSH per integrarli con il ridimensionamento automatico allo stesso modo dei diritti, tutti i commenti apprezzati sul blog. Grazie

Answer 4

Vorrei passare a un servizio di bilanciamento del carico off-site, non nel cloud ed eseguire qualcosa come IPVS su di esso. [Il motivo per cui sarebbe fuori dal cloud di Amazon è a causa di roba del kernel] Se Amazon non limita l'IP di origine dei pacchetti che escono da esso, potresti utilizzare un meccanismo unidirezionale di bilanciamento del carico. Facciamo qualcosa del genere e ci arrivano circa 800.000 richieste simultanee [anche se non ci occupiamo della latenza]. Direi anche di usare "ab2" (panca apache), in quanto è un po 'più user friendly e più facile da usare a mio modesto parere.

Answer 5

Anche se il problema è stato risolto. Le tecnologie KEMP ora dispongono di un bilanciamento del carico completo per AWS. Potrebbe risparmiarti un po 'di seccatura.