2012-02-03 23 views
19

Mi chiedevo quale sarebbe stato meglio ospitare un sito su EC2 con molte istanze micro o meno istanze più grandi come m1.large. Tutti siederanno dietro una o poche istanze più grandi come bilanciamento del carico. Dirò qual è la mia comprensione e chiunque mi conosca meglio può aggiungermi o correggermi se ho tortoEC2 server, molte istanze micro o meno istanze più grandi?

Il motivo principale per scegliere le istanze micro è il costo. Una singola istanza micro in media fornirà circa 0,35 ECU per $ 0,02/ora, mentre una piccola istanza darà 1 UCU per $ 0,085. Se fate i conti di $/ECU/ora, una micro istanza funziona a $ 0,057/ECU/ora, mentre per una piccola istanza è $ 0,085/ECU/ora. Quindi, per la stessa potenza di calcolo media, scegliere 100 micro istanze sarebbe più economico di 35 piccole istanze.

Il problema principale con le istanze micro è la prestazione più fluttuante, ma non sono sicuro se questo sarà meno un problema quando si hanno molte istanze.

Così qualcuno ha esperienza in panchina di tali configurazioni e vedere i vantaggi e gli svantaggi? Per favore fatemi sapere come sto cercando di scegliere quale strada da percorrere, grazie!

PS: un articolo su questo argomento, http://huanliu.wordpress.com/2010/09/10/amazon-ec2-micro-instances-deeper-dive/

risposta

0

direi: dipende da che tipo di architettura la vostra applicazione avrà e quanto è affidabile che dovrà essere:

  • AWS bilanciamento del carico fa non fornire istantanea (forse in tempo reale è una parola migliore?) auto-scala che è diverso dal concetto di failover. Funziona con i controlli di integrità di volta in volta e ha un piccolo ritardo perché è eseguito tramite richieste HTTP (altro overhead se si sceglie https).
  • Avrai più punti di errore se scegli più istanze a seconda dell'architettura. Per evitarlo, la tua app dovrà essere asincrona tra le istanze.
  • È necessario eseguire il benchmark e testare di più l'applicazione se si scelgono più istanze , per garantire che tali raffiche non influiscano eccessivamente sull'app.

Questo è il mio punto di vista e sarebbe una discussione molto piacevole tra persone esperte.

+0

Grazie per la risposta. Non so come funziona ELB (e ho sentito alcune esperienze non così eccezionali con altre persone), ma io uso HAProxy e il failover è generalmente in tempo reale (con verifiche da 500 o 1000 ms) . Il controllo viene eseguito anche con una richiesta HEAD o OPTION, quindi l'overhead non dovrebbe essere così grande, ma sicuramente lì. Inoltre sto parlando principalmente di server di app, con database altrove, quindi i server di app stessi sono indipendenti, e alcuni di essi non dovrebbero essere un problema, penso, ma girare le istanze di sostituzione richiede tempo che influirà sulle prestazioni di sicuro. – Jd007

12

Attenzione alle microstanze, potrebbero morderti. Abbiamo un ambiente di test tutto su micro-istanze. Dal momento che sono solo un ambiente di test funzionale, funziona perfettamente. Tuttavia, ci è capitato di aver aggiornato alcune applicazioni (beh, Jetty 7.5.3) che hanno rilevato bug di utilizzo della CPU più elevato. Ciò ha reso inutili queste istanze in quanto Amazon riduce al 2% la CPU disponibile.

Inoltre, le istanze micro sono supportate da EBS. EBS è non consigliabile (over instance-store) per operazioni di I/O elevate come quelle richieste per Cassandra or the likes.

Se si desidera risparmiare denaro e il software è architected to handle interruptions, è possibile optare per le istanze spot. Sono di solitocost less than on-demand ones.

Se tutti questi non sono un problema per te, direi, le micro-istanze sono la strada da percorrere!:)

Problemi correlati