2010-10-01 22 views
14

Ho lavorato alla mia [prima] startup per un mese ora, e mentre è probabilmente almeno un mese più lontano da una versione alpha, voglio sapere come distribuirlo nel modo giusto. Il sito avrà una quantità iniziale elevata di carico (rete + CPU) per un nuovo utente, quindi sto pensando di avere un server/coda separato per questo processo iniziale, in modo che non rallenti il ​​sito per gli utenti esistenti.Come distribuire un sito [Ruby on Rails] in modo scalabile?

Sulla base delle mie ricerche fino ad ora, attualmente mi sto appoggiando a nginx + haproxy + unicorn/thin + memcached + mysql e distribuendo su Linode. Tuttavia, non ho alcuna esperienza precedente in nessuno dei precedenti; quindi spero di sfruttare l'esperienza della comunità.

  • L'architettura di cui sopra sembra ragionevole? Qualche suggerimento/articoli/libri che consiglieresti?
  • Linode è una buona scelta? Heroku/EY sembrano troppo costosi per me (almeno fino a quando non ho entrate sufficienti), ma mi manca qualche altra opzione migliore? MediaTemple?
  • Qualche buon suggerimento sull'architettura di bilanciamento del carico? Sto ancora leggendo su questo.
  • È meglio disporre di 2 istanze del server Rails separate su 2 linodi separati oppure eseguire 1 istanza su un linodo di capacità doppia (in termini di RAM/spazio di archiviazione/larghezza di banda)? Quanti linodi dovrei iniziare?
  • Quale distribuzione Linux devo scegliere? (Linode offre 8 diversi - http://www.linode.com/faq.cfm) Ci sono dei vantaggi/svantaggi relativi tra di loro per un sito di Rails?

Mi scuso se una delle mie domande è stupida o contraddittoria; per favore attribuiscilo alla mia inesperienza.

risposta

18

Architettura

Sei sulla strada giusta. Personalmente preferisco Passenger over thin/unicorn (avendo eseguito nginx su thin backend per molto tempo) solo per comodità, ma la tua configurazione proposta è abbastanza standard. Se sei su Ruby 1.8.7, ti consiglio comunque di considerare REE + Passenger per i risparmi della memoria di struttura.

Hosting & Load Balancing

Linode è fantastico, e io li uso per quasi tutto quello che posso, ma è necessario essere consapevoli dei limiti di RAM. Ogni processo di Rails utilizza una quantità non banale di RAM e eviterà che la macchina venga scambiata. Pianificare l'esecuzione di un numero sufficiente di istanze di Rails per macchina in modo che l'allocazione di memoria corrisponda al 90% della memoria sul Linode. Probabilmente vorrai un altro Linode dedicato al tuo database, sebbene tu possa iniziare con entrambi sullo stesso computer; preparati solo a dividere MySQL man mano che cresci. È possibile impostare le comunicazioni tra Linodes nello stesso centro dati su IP privati, che non vengono conteggiati rispetto alla quota di larghezza di banda.

La strategia di ridimensionamento dovrebbe essere il più orizzontale possibile, quindi consiglierei di ottenere un secondo Linodo e aggiungerlo al vostro pool haproxy quando avete bisogno di più potenza - Linode vi addebita $ 20 per 512 MB di RAM in più, o potete semplicemente ottenere un intero Linode (con CPU, RAM, HDD e quota di larghezza di banda) per lo stesso $ 20. Sembra un gioco da ragazzi!). Nel caso di Rails, un'istanza è un'istanza è un'istanza, quindi non importa se si trova sulla stessa VM o meno, a patto che il tempo di connettersi alla macchina del database o quant'altro sia più o meno lo stesso. Potresti eseguire 10 Linodes ognuno dei quali esegue 10 processi Rails a testa senza molto di un problema.Linode offre anche il failover IP, in modo tale che se il Linodo primario (con haproxy) non funziona, può eseguire automaticamente il failover su un Linode secondario, su cui si eseguirà quindi haproxy e pronto ad agire nella stessa capacità del primo.

Distribuzione

Onestamente, questo sta a voi! Molte persone usano distribuzioni Ubuntu o Redhat (CentOS/Fedora) - Mi piace CentOS da solo - ma in realtà è proprio quello che ti senti più a tuo agio. Se non hai una distribuzione preferita, ti consiglio di provare Ubuntu/CentOS, poiché tendono ad essere abbastanza amichevoli per i principianti e hanno un supporto della community estremamente solido.

Probabilmente si vorrà scegliere una distro a 32 bit a meno che non si abbia un motivo valido per scegliere una distro a 64 bit; Gli eseguibili a 64 bit richiedono più RAM rispetto ai loro equivalenti a 32 bit, e poiché la RAM è probabilmente la vostra risorsa più preziosa, ha senso salvarla dove è possibile.

+0

Grazie per la risposta dettagliata. Alcune domande di follow-up per voi: - (1) Sto usando Ruby 1.9.2. REE ha ancora un vantaggio in questo caso? (2) Quale vantaggio offre Passenger over Thin? –

+0

Il passeggero gestisce automaticamente il proprio cluster di processi. Con thin, devi gestire ogni back-end manualmente. Passenger sfrutta inoltre la funzionalità di copia su scrittura di REE per condividere la memoria framework su istanze di backend, risparmiandovi RAM. È anche abbastanza semplice da installare e configurare. –