2010-08-04 6 views
5

L'applicazione Web è in procinto di passare da un server autonomo a un paio di server dietro un bilanciatore del carico e contiene una directory da 50 GB creata dall'utente dati che stanno crescendo rapidamente. Su rackspace, l'unico modo per aggiungere spazio su disco in modo dinamico è raddoppiando anche la RAM e il costo mensile, che non è necessario. Quindi, per fare il cloud dei file è (a meno che qualcuno non abbia in mente un'altra soluzione?). Utilizzando JungleDisk, posso spostare i file in un contenitore di file cloud e posso montare il contenitore cloud su entrambi i server e creare un collegamento simbolico dalle directory in cui il contenuto era sull'unità montata. Ciò non richiederebbe alcuna modifica del codice. In alternativa, potrei interfacciarmi direttamente con i file cloud usando le loro API PHP, ma ciò richiederebbe enormi modifiche al codice (tutti i percorsi? Davvero?). C'è qualche problema inerente a prendere la via più facile in questo caso? Ho creato una modella e sembra funzionare bene, ma di solito mi sembra che manchi qualcosa.unità cloud vs file cloud (o non dovremmo preoccuparci?)

Grazie, Brandon

+0

Questa domanda è probabilmente più adatta per serverfault.com –

+0

Probabilmente, ma sto parlando di storage per una piccola applicazione web, e non è una domanda molto tecnica. Suppongo che molti membri della comunità qui abbiano affrontato un problema simile. Più, forse, di quello della comunità dei guasti del server? – Orbit

risposta

0

penso di montaggio l'unità fa un sacco di senso per lo scenario, ma ad essere onesti non ho provato con qualsiasi carico. La buona notizia è che si può sempre provare l'approccio facile e poi refactoring se non funziona sotto carico. Spero che Rackspace sia stato valutato e testato per questo scenario esatto, mi sembra logico.

Per alcune informazioni estranee, abbiamo affrontato la stessa domanda qui e fatto un confronto dei costi dell'utilizzo di Cloud Site vs Cloud Files. Abbiamo dovuto tenere in considerazione sia la larghezza di banda che la quantità di storage nei costi, poiché la comunicazione tra Sites/Server e Cloud Files comporta ancora costi di larghezza di banda. In altre parole, hai un sacco di file che siedono in giro o hai pochi file a cui si accede spesso.

Passiamo molto tempo a parlare con il supporto di RackSpace sulle differenze di prestazioni e scalabilità tra i siti cloud e i file cloud: mi raccomando di dare loro una chiamata. Alla fine abbiamo scelto di utilizzare semplicemente Sites a causa delle nostre esigenze, la differenza di costo era piuttosto insignificante in quanto scalabile. Anche perché l'API Cloud Files non aveva la sicurezza granulare di cui avevamo bisogno, quindi avremmo dovuto comunque scrivere un servizio gateway.