Il modo migliore per bilanciare il carico su più file server statici anche per una distribuzione della larghezza di banda?


12

Prima di tutto, ti spiego la mia situazione. Sto gestendo un sito Web abbastanza popolare come progetto secondario, quindi non posso davvero investire un sacco di soldi in esso. Al momento ho solo un server con HAProxy nella parte anteriore che invia normali richieste ad Apache e tutte le richieste di file statici a Lighttpd. Funziona davvero bene perché tutte le richieste php e post vengono gestite da Apache, mentre tutte le immagini vengono inviate a Lighttpd più veloce (il sito è principalmente immagini, quindi è molto importante). Sarebbe bello non dover impostare un sottodominio per pubblicare le immagini, perché anche gli URL brevi sono davvero importanti, quindi la mia ragione per usare HAProxy.

Ho trovato un provider di hosting che offre una larghezza di banda illimitata piuttosto economica che sto usando, il problema si presenta quando comincio a spingere fuori tutta la larghezza di banda che la scheda di rete da 100 Mb può gestire, quindi è necessario un secondo server.

Ho pensato molto alle mie opzioni, quindi ti spiegherò ognuna. Spero che tu possa fornire qualche idea su quale sia l'opzione migliore per me, o forse c'è un'altra opzione là fuori che non ho ancora pensato.

Requisiti:

  • Anche la distribuzione della larghezza di banda è un must. Ho un server piuttosto potente, quindi il ridimensionamento non è un'opzione. Ho bisogno di ridimensionare per guadagnare più larghezza di banda.

  • URL brevi. Non voglio davvero impostare un sottodominio, come img.example.com, per pubblicare le mie immagini. example.com/image.jpg è come è adesso e come vorrei davvero che rimanesse. Ma se non c'è altro modo, allora capisco.

  • Il server più chiuso che gestisce la richiesta sarebbe davvero bello, ma non è un must. Qualcosa da tenere a mente.

HAProxy per bilanciamento del carico:

  • Sarebbe davvero facile da fare dato che sto già usando HAProxy comunque. Tuttavia, penso che il problema si presenti quando si distribuisce la larghezza di banda. Potrei sbagliarmi su questo, ma HAProxy non invia la richiesta a un server in cui il server la elabora e quindi la restituisce tramite HAProxy al client? Pertanto, tutto il traffico viene restituito attraverso il bilanciamento del carico, causando l'utilizzo della stessa larghezza di banda di tutti i server combinati.

DNS Round Robin:

  • Questa potrebbe essere la mia migliore opzione. Basta replicare il sito Web su più server e fare quello che sto facendo ora. Il rovescio della medaglia è che se un server si arresta, i client vengono comunque inviati ad esso. Avrei anche bisogno di replicare il sito su più server. Speravo in qualche modo di poter avere un server principale che gestisse tutto tranne i file statici e quindi un paio di file server statici. Ho anche letto che questo era una specie di "bilanciamento del carico del povero", e sarebbe bello avere qualcosa di un po 'più sofisticato.

Ritorno diretto al server:

  • Sembra davvero complicato, ma potrebbe essere una buona opzione. Sarei ancora in grado di inviare determinati URL a determinati server? Come in questo momento con HAProxy, ogni URL che termina con l'estensione di file corretta viene inviato a Lighttpd, mentre altre estensioni vengono inviate ad Apache. Quindi avrei bisogno di qualcosa di simile. Ad esempio, tutte le richieste php sono gestite dallo stesso server che esegue il software di bilanciamento, mentre tutte le richieste jpg vengono inviate a più server.

Idealmente, se HAProxy supportasse Direct Server Return, il mio problema sarebbe risolto. Inoltre, non voglio usare un CDN, perché sono davvero costosi, e questo è solo un progetto secondario dopo tutto.

Capisci il mio problema? Fammi sapere se non ho spiegato qualcosa di giusto o se hai bisogno di maggiori informazioni.


1
Questo è Imgur e recentemente ha raccolto 40 milioni di dollari. : O
L1th1um

Risposte:


3

Disegna un'immagine del tuo ciclo di richiesta / risposta per l'applicazione e isola il collo di bottiglia. È corretto affermare che un singolo proxy che distribuisce il carico a molti server delle applicazioni richiederà la larghezza di banda aggregata di tutti i server delle applicazioni. La soluzione classica è RR DNS. Google, Yahoo e Amazon usano tutti questa tecnica con un breve TTL. Qualche tempo fa ho fatto alcune indagini e documentato le mie scoperte .

Un'altra soluzione è quella di utilizzare una soluzione di bilanciamento del carico aziendale sofisticata utilizzando l'indirizzamento IP virtuale per bilanciare le richieste tra più server applicazioni con indirizzi IP reali. Ho lavorato con i prodotti Netscaler e Stonesoft. Entrambi funzionano bene ma hanno terribili idiosincrasie e sono piuttosto complessi.


Grazie mille. I risultati del sondaggio sono stati molto utili. Penso che questa sia la soluzione alla quale finalmente verrò. Tuttavia, "Come ogni buon ricercatore, non agisco fino a quando non ho abbastanza dati". :)
Alan,

Grazie per la comprensione. Sfortunatamente un link ironico alle tue scoperte sembra essere inattivo, puoi sistemarlo?
TCB13

3

Alcune risposte:

  • Sì, tutto il traffico passa attraverso HAProxy, poiché funziona come proxy a livello HTTP. Sarà lo stesso anche se HAProxy è installato su un server separato che bilancia il carico di più server back-end. Pertanto, se il tuo provider di hosting fornisce solo porte di rete da 100 MB e stai già spingendo 100 MB, allora hai un problema.
  • Per quanto riguarda il dominio, la cosa ottimale sarebbe quella di servire immagini di un dominio diverso rispetto alla tua webapp - non un sottodominio, uno diverso, in modo che i cookie non vengano inviati su richieste di immagini. Guarda il lavoro originale di Steve Souders o l'implementazione qui su StackTranslate.it . Se gli URL brevi sono molto importanti per te, forse la cosa migliore sarebbe spostare la webapp dall'URL principale, ovvero spostare l'applicazione di gestione dei file su login.sitename.com?

Hai bisogno di autenticazione per le richieste di immagini? In caso contrario, che ne dici di usare qualcosa come Amazon S3? È enormemente scalabile e il costo del trasferimento dei dati è abbastanza economico. In questo caso userei qualcosa come i.sitename.com come DNS CNAME per il nome host del bucket Amazon S3, vedi i documenti di Amazzoni . AFAIK non puoi avere il nome di dominio principale (sitename.com) come CNAME, quindi per questo devi usare un sottodominio come i.sitename.com.

Puoi anche eseguire l'hashing delle tue immagini su più server. Vale a dire creare una struttura DNS come login.sitename.com e a.sitename.com; b.sitename.com; c.sitename.com e così via. La "a". e B." I server ecc. contengono solo un file system con immagini e un server HTTP leggero (stai già utilizzando Lighttpd, quindi continua a usarlo. Per un progetto futuro, proporrei di considerare nginx come un sostituto migliore.) Quando un utente carica un'immagine, si crea un hash di un identificatore univoco, forse il suo nome utente, forse il nome file o una combinazione di più identificatori . Da questo hash, si determina su quale server archiviare l'immagine.

Modifica Avrei dovuto vedere che l'hashing era già stato discusso. In sostanza, ciò che sto proponendo qui è solo di utilizzare l'hash sul nome host, per distribuire uniformemente il traffico di rete su più host.

Non so quanto sia economico , ma quando spingi 100MBit di traffico di rete, allora "economico e buono" diventa rapidamente un'illusione. Forse dovresti prima cercare un buon modello di business, qualcosa che fornisca entrate ricorrenti, e poi implementare la tecnologia appropriata in seguito?


1

Presumo che HAProxy sia sullo stesso server delle altre tue applicazioni? È possibile suddividere HAProxy su un altro sistema per eseguire le richieste e inviarle richieste normali a un server e richieste di immagini a un altro server. Il problema è che tutte le richieste stanno ancora andando in una casella e se stai saturando la sua larghezza di banda, ciò potrebbe non aiutarti molto.

Dici che URL brevi sono importanti. Perché? È davvero un grosso problema passare da "example.com" a "i.example.com"? È possibile impostare "i" sul proprio IP sul proprio server con Lighttpd e bypassare completamente HAProxy, risolvendo il problema del throughput. Otterresti anche il vantaggio del browser Web che consente di aprire più richieste contemporaneamente poiché le considererebbe nomi di dominio diversi e potrebbe aprire più connessioni simultanee. Se il singolo server "i" si satura, è possibile utilizzare il round robin DNS per aggiungerne un altro. Spero che a quel punto stai generando entrate sufficienti per implementare una soluzione migliore.


Sì, HAProxy è sullo stesso server - ne ho solo uno finora. Anche se lo distribuissi a un altro server, tutti i dati non viaggerebbero comunque attraverso il server con HAProxy, come ho spiegato sopra? Gli URL brevi sono importanti perché è una sorta di scopo del sito. È un crossover tra ImageShack e TinyPic. Più è lungo l'URL, meno punti ha il mio sito. Ma come ho detto, se l'unica opzione praticabile è impostare un sottodominio, allora dovrei solo farlo. Preferirei davvero non farlo.
Alan,

1

Il tuo provider di hosting offre servizi di bilanciamento del carico? Penso che sia la soluzione migliore.

Un altro modo per farlo, ma deve essere testato, è riscrivere (in lighty o apache) le richieste. Ad esempio: example.com/file.html rimane in apache e example.com/image.jpg reindirizza a i.example.com/image.jpg. Tutte le richieste saranno gestite tramite apache ma le risposte (larghezza di banda upstream) andranno al server lighttpd. Il dominio è trasparente per l'utente. Devi comunque verificare se apache è in grado di gestire tutte le richieste o magari lasciare che lighttpd faccia questo lavoro.

Hai ragione tutti i dati passano attraverso HAProxy, quindi non puoi (per quanto ne so) restituire direttamente il server con esso.

AGGIORNARE

Guardando nella documentazione di HAproxy ho trovato il parametro "redir". Non so se può funzionare come riscrivere apache ma può essere utile. La documentazione dice:

L'uso principale consiste nell'aumentare la larghezza di banda per i server statici facendo in modo che i client si connettano direttamente a essi.

Forse funziona per il tuo caso.


Ehi, grazie per la risposta. In realtà l'ho già provato, e in pratica non funziona così come in teoria. Il motivo è che Apache gestisce tutte le richieste, quindi ogni volta che un utente colpisce un'immagine, Apache viene generato, guarda l'URL, quindi lo invia leggero. Il che non è diverso dal fatto che Apache gestisca l'immagine in primo luogo. Sono d'accordo che un bilanciamento del carico fornito dal mio host è l'opzione migliore, ma è anche uno dei più costosi. Fanno pagare per connessione simultanea e ne ottengo centinaia.
Alan,

È diverso nel modo in cui il server leggero invierà la risposta direttamente al client consumando la propria larghezza di banda. Il problema è che il server Apache gestirà molte richieste. Controlla l'aggiornamento alla mia risposta, ho trovato un'altra soluzione.
hdanniel,

1

Suppongo che con qualsiasi set considerevole di immagini non si stiano memorizzando le immagini in base al nome del file originale in quanto si potrebbero incontrare conflitti di nomi abbastanza rapidamente.

Molte applicazioni che affrontano questo tipo di problemi usano l'hash del file e una struttura di directory basata su quell'hash. La struttura della directory è simile alla seguente in cui il percorso della directory è i primi due caratteri dell'hash, quindi la directory di 2 ° livello è i due caratteri successivi nell'hash.

/image root/AA/AA/images  
/image root/AA/AB/images

Il vantaggio qui è che gli hash mantengono la distribuzione dei file abbastanza uniforme e ti offrono uno spazio dei nomi che è facile da suddividere su più server. Fondamentalmente servi porzioni di spazio hash da server diversi e mentre ridimensioni puoi suddividerlo ulteriormente come richiesto.

Il rovescio della medaglia è che gli hash non sono perfetti e ci possono essere collisioni. Non sono sicuro di come venga affrontato. Quindi questo potrebbe richiedere un po 'di ricerca da parte tua. Immagino che una regola di riscrittura nel proxy dovrebbe essere in grado di prendere un hash dire A3A8BBC83261.jpg e riscriverlo su http://img3.domain.com/A3/A8/BBC83261.jpg . Non puoi considerare che sia un breve URL però.


Sì, è esattamente così che sto memorizzando le immagini. Tuttavia, il problema non riguarda l'archiviazione, ma la distribuzione della larghezza di banda.
Alan,

Ma se archivi AA da 33 a un server e da 34 a 99 su un altro server non solo bilancerai il problema di archiviazione, ma anche la distribuzione della larghezza di banda.
3dinfluence,

0

Nel tuo post hai detto che pensavi che il round robbin DNS potesse essere la tua migliore opzione ma eri preoccupato che un singolo server non funzionasse ...

In questo caso dai un'occhiata al Simple Failover dal software JH. L'ho usato in passato e funziona molto bene.

http://www.simplefailover.com

Fondamentalmente monitora i tuoi server e quando ne vede uno andare giù riscrive rapidamente il DNS per estrarre il server morto dalla rotazione.

Ecco uno snippet dal loro sito Web:

Simple Failover monitora continuamente i tuoi server per scoprire quali sono attivi e quali inattivi, quindi aggiorna dinamicamente i tuoi record DNS di conseguenza in modo che il tuo nome di dominio punti sempre a un server funzionale.

Funziona con server Web (HTTP), server di posta (SMTP, IMAP, POP3), server FTP e praticamente qualsiasi altro tipo di server basato su TCP / IP.

Come accennato in precedenza, l'ho usato in passato per siti Web e server di posta. Ha funzionato abbastanza bene. Il failover è stato piuttosto rapido nella maggior parte dei casi (indovinando 2-5min) e direi che quasi tutti hanno fallito in meno di 15 minuti.

Non necessariamente PERFETTO ... ma sicuramente facile e veloce.

NOTA: questo è un prodotto Windows. Non sono sicuro che abbiano una versione di Linux o no, ma puoi eseguire il failover su qualsiasi server che ti piace dal momento che è basato su DNS.

Nel nostro caso, l'abbiamo appena lanciato su una macchina XP, abbiamo detto alla macchina di riavviarsi una volta a notte e ha funzionato bene per anni.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.