Vantaggi di EBS vs.store-store (e viceversa) [chiuso]

Non sono chiaro quali vantaggi ottengo da EBS rispetto al negozio di istanze per le mie istanze su Amazon EC2. Semmai, sembra che EBS sia molto più utile (arresto, avvio, persistenza + migliore velocità) con una differenza relativamente piccola di costo ...? Inoltre, c'è qualche metrica sul fatto che più persone stiano utilizzando EBS ora che è disponibile, considerando che è ancora relativamente nuovo?

La linea di fondo è che dovresti quasi sempre usare le istanze supportate da EBS.

Ecco perché

• Le istanze supportate da EBS possono essere impostate in modo che non possano essere (accidentalmente) terminate tramite l'API.
• Le istanze supportate da EBS possono essere interrotte quando non le si utilizza e possono essere riprese quando è necessario di nuovo (come mettere in pausa un PC virtuale), almeno con i miei modelli di utilizzo risparmiando molto più denaro di quanto spendo in poche decine di GB di spazio di archiviazione EBS.
• Le istanze supportate da EBS non perdono il loro archivio di istanze in caso di arresto anomalo (non è un requisito per tutti gli utenti, ma rende il recupero molto più veloce)
• È possibile ridimensionare dinamicamente lo spazio di archiviazione dell'istanza EBS.
• Puoi trasferire l'archiviazione dell'istanza EBS in un'istanza nuova di zecca (utile se l'hardware su Amazon su cui stavi funzionando si squama o muore, cosa che succede di tanto in tanto)
• È più veloce avviare un'istanza supportata da EBS perché non è necessario recuperare l'immagine da S3.
• Se l'hardware dell'istanza supportata da EBS è programmato per la manutenzione , l'arresto e l'avvio dell'istanza passano automaticamente al nuovo hardware. Sono stato anche in grado di spostare un'istanza supportata da EBS su hardware guasto arrestando forzatamente l'istanza e avviandola di nuovo (il chilometraggio può variare in caso di hardware guasto).

Sono un grande utente di Amazon e ho passato tutte le mie istanze allo storage supportato da EBS non appena la tecnologia è uscita dalla beta. Sono stato molto contento del risultato.

EBS può ancora fallire, non un proiettile d'argento

Tieni presente che qualsiasi infrastruttura basata su cloud può fallire in qualsiasi momento. Pianifica la tua infrastruttura di conseguenza. Mentre le istanze supportate da EBS offrono un certo livello di durabilità rispetto alle istanze di archiviazione effimere, possono e falliscono. Avere un AMI da cui è possibile avviare nuove istanze in qualsiasi zona di disponibilità, eseguire il backup dei dati importanti (ad es. Database) e, se il budget lo consente, eseguire più istanze di server per il bilanciamento del carico e la ridondanza (idealmente in più zone di disponibilità ).

Quando non farlo

In alcuni momenti, potrebbe essere più economico ottenere un IO più veloce nelle istanze di Instance Store. C'è stato un tempo in cui era certamente vero. Ora ci sono molte opzioni per l'archiviazione EBS, che soddisfano molte esigenze. Le opzioni e i relativi prezzi si evolvono costantemente al variare della tecnologia. Se hai un numero significativo di casi realmente disponibili (che non influiscono molto sulla tua attività se vanno semplicemente via), fai i conti con costi e prestazioni. Le istanze supportate da EBS possono anche morire in qualsiasi momento, ma la mia esperienza pratica è che EBS è più durevole.

Il 99% della nostra configurazione AWS è riciclabile. Quindi per me non importa se chiudo un'istanza: nulla è mai perso. Ad esempio, la mia applicazione viene automaticamente distribuita su un'istanza di SVN, i nostri registri vengono scritti su un server syslog centrale.

L'unico vantaggio dell'archiviazione dell'istanza che vedo sono i risparmi sui costi. Altrimenti vincono le istanze supportate da EBS. Eric ha menzionato tutti i vantaggi.

[2012-07-16] Oggi pronuncerei questa risposta in modo molto diverso.

Non ho avuto alcuna buona esperienza con istanze supportate da EBS nell'ultimo anno o giù di lì. Anche gli ultimi tempi di fermo su AWS hanno praticamente distrutto EBS.

Immagino che un servizio come RDS usi anche un qualche tipo di EBS e che sembra funzionare per la maggior parte. Sulle istanze che gestiamo noi stessi, ci siamo sbarazzati di EBS ove possibile.

Sbarazzarsi di un punto in cui abbiamo spostato un cluster di database su iron (= hardware reale). L'unico pezzo rimasto nella nostra infrastruttura è un server DB in cui eseguiamo lo striping di più volumi EBS in un RAID software e il backup due volte al giorno. Qualunque cosa andrebbe persa tra i backup, possiamo convivere.

EBS è una tecnologia in qualche modo instabile poiché è essenzialmente un volume di rete: un volume collegato al server da remoto. Non sto negando il lavoro fatto con esso - è un prodotto straordinario poiché l' archiviazione persistente essenzialmente illimitata è solo una chiamata API. Ma non è adatto per scenari in cui le prestazioni di I / O sono fondamentali.

Oltre a come si comporta l'archiviazione di rete, tutta la rete è condivisa su istanze EC2. Più piccola è un'istanza (ad es. T1.micro, m1.small), peggio diventa perché le interfacce di rete sul sistema host reale sono condivise tra più macchine virtuali (= istanza EC2) che girano su di essa.

Più grande è l'istanza, meglio diventa ovviamente. Meglio qui significa entro limiti ragionevoli .

Quando è necessaria la persistenza, consiglierei sempre alle persone di usare qualcosa come S3 per centralizzare tra le istanze. S3 è un servizio molto stabile. Quindi automatizza la configurazione dell'istanza al punto in cui è possibile avviare un nuovo server e si prepara da solo. Quindi non è necessario disporre di memoria di rete che dura più a lungo dell'istanza.

Quindi, tutto sommato, non vedo alcun beneficio per le istanze supportate da EBS. Preferisco aggiungere un minuto al bootstrap, quindi eseguire con un potenziale SPOF.

Ci piace l'istanza-store. Ci costringe a rendere le nostre istanze completamente riciclabili e possiamo automatizzare facilmente il processo di creazione di un server da zero su una determinata AMI. Questo significa anche che possiamo facilmente scambiare AMI. Inoltre, EBS ha ancora problemi di prestazioni di volta in volta.

Eric l'ha praticamente inchiodato. Noi ( Bitnami ) siamo un fornitore popolare di AMI gratuite per applicazioni e framework di sviluppo popolari (PHP, Joomla, Drupal, hai capito). Posso dirti che le AMI supportate da EBS sono significativamente più popolari di quelle supportate da S3. In generale, penso che le istanze supportate da s3 vengano utilizzate per lavori distribuiti e limitati nel tempo (ad esempio, elaborazione di dati su larga scala) in cui se una macchina si guasta, un'altra viene semplicemente aggiunta. Gli AMIS supportati da EBS tendono ad essere utilizzati per attività server "tradizionali", come server Web o database che mantengono lo stato localmente e richiedono quindi la disponibilità dei dati in caso di crash.

Un aspetto che non ho visto menzionato è il fatto che è possibile eseguire istantanee di un'istanza supportata da EBS durante l'esecuzione, consentendo in tal modo di avere backup molto convenienti della propria infrastruttura (le istantanee sono basate su blocchi e incrementali)

Ho avuto la stessa esperienza di Eric nella mia ultima posizione. Ora nel mio nuovo lavoro, sto attraversando lo stesso processo che ho eseguito nel mio ultimo lavoro ... ricostruendo tutte le loro AMI per le istanze supportate da EBS - e possibilmente come macchine a 32 bit (più economiche - ma non posso usare la stessa AMI su 32 e 64 macchine).

Le istanze supportate da EBS si avviano abbastanza rapidamente da poter iniziare a utilizzare l' API Amazon AutoScaling che consente di utilizzare le metriche CloudWatch per avviare il lancio di istanze aggiuntive e registrarle sull'ELB (Elastic Load Balancer) e anche per spegnerle quando non più richiesto.

Questo tipo di ridimensionamento automatico dinamico è ciò di cui si occupa AWS: dove possono entrare in gioco i reali risparmi nell'infrastruttura IT. È praticamente impossibile eseguire il ridimensionamento automatico con le vecchie istanze supportate da "InstanceStore" s3.

Ho appena iniziato a utilizzare EC2 da solo, quindi non un esperto, ma la documentazione di Amazon dice:

ti consigliamo di utilizzare l'archivio di istanze locale per i dati temporanei e, per i dati che richiedono un livello di durabilità più elevato , ti consigliamo di utilizzare i volumi Amazon EBS o il backup dei dati su Amazon S3.

Enfasi mia.

Faccio più analisi dei dati rispetto all'hosting Web, quindi la persistenza non è importante per me come potrebbe essere per un sito Web. Data la distinzione fatta dalla stessa Amazon, non presumo che EBS sia adatto a tutti.

Proverò a ricordare di pesare di nuovo dopo aver usato entrambi.

EBS è come il disco virtuale di una macchina virtuale:

• Durevoli, le istanze supportate da EBS possono essere avviate e fermate liberamente (risparmiando denaro)
• Può essere istantaneo in qualsiasi momento, per ottenere backup temporizzati
• Le AMI possono essere create da istantanee EBS, quindi il volume EBS diventa un modello per i nuovi sistemi

La memoria dell'istanza è:

• Locale, quindi generalmente più veloce
• Non in rete, in casi normali l'I / O EBS ha un costo per la larghezza di banda della rete (ad eccezione delle istanze ottimizzate EBS, che hanno una larghezza di banda EBS separata)
• Ha I / O limitato al secondo IOPS. Anche l'I / O di provisioning raggiunge il massimo a poche migliaia di IOPS
• Fragile. Non appena l'istanza viene arrestata, si perde tutto nella memoria dell'istanza.

Ecco dove utilizzare ciascuno:

• Utilizzare EBS per la partizione del sistema operativo di supporto e l'archiviazione permanente (dati DB, registri critici, configurazione dell'applicazione)
• Utilizzare l'archiviazione dell'istanza per dati in-process, registri non critici e stato transitorio dell'applicazione. Esempio: memoria di ordinamento esterna, tempfile, ecc.
• L'archiviazione delle istanze può essere utilizzata anche per dati critici in termini di prestazioni, quando è presente la replica tra istanze (DB NoSQL, sistemi di messaggi / code distribuiti e DB con replica)
• Utilizzare S3 per i dati condivisi tra i sistemi: input di set di dati e risultati elaborati, o per i dati statici utilizzati da ciascun sistema quando lanciato.
• Utilizzare le AMI per server preconfezionati e lavabili

Molte persone scelgono di utilizzare l'istanza supportata da EBS in quanto è stateful. È più sicuro perché tutto ciò che è in esecuzione e installato al suo interno sopravviverà all'arresto / arresto o a qualsiasi errore dell'istanza.

L'istanza dell'archivio è senza stato, si perde con tutti i dati all'interno in caso di qualsiasi situazione di errore dell'istanza. Tuttavia, è gratuito e più veloce perché il volume dell'istanza è legato al server fisico su cui è in esecuzione la VM.

Per qualcuno nuovo a tutto questo e se atterrato accidentalmente qui

A partire da ora tutti gli AMI nella sezione di avvio rapido sono supportati da EBS

Inoltre c'è una buona spiegazione nel documento ufficiale per la differenza tra EBS e l' istanza del negozio

e questa immagine lo riassume praticamente

Se esegui più istanze e assegni un servizio pianificato di AWS Instance come una delle tue priorità per evitare addebiti imprevisti , ti consiglio di non utilizzare l'istanza-archivio .

Come spiegato sulla documentazione di EBS Volumes e sulla risposta di j2d3 e Siddharth Sharma, l'istanza-store può funzionare per tutto il tempo che desideri, ma non può essere fermata . Significa che il servizio non può essere programmato da un avvio / arresto automatico o un ripristino dell'istanza .

Inoltre, per questo tipo di schema non vi è alcun vantaggio nell'utilizzare EBS Backed su Elastic Beanstalk in quanto è progettato per garantire che tutte le risorse necessarie siano mantenute in esecuzione . Farà sempre un riavvio automatico di tutti i servizi che interrompi. Esaminando tutto il resto , rispetto alle spese totali per l'utilizzo di VPC , EBS ed ELB aggiunte a EC2-Classic , l' EC2-VPC con ELB è principalmente la scelta migliore dove, a differenza di EC2-Classic , un'istanza arrestata mantiene l' elastico associato Indirizzi IPe il volume EBS viene memorizzato automaticamente.

Come conclusione , prendendo la parte principale della tua domanda:

sembra che EBS sia molto più utile (stop, start, persist + migliore velocità) con relativamente poca differenza di costo ...?

La risposta è sì ma se l'istanza è basata su EBS, può essere fermata. Rimarrà nel tuo account, non ti verrà addebitato . Ti verrà addebitato solo il volume ma EBS verrà addebitato ogni ora . Puoi anche considerare che tra tutti i tipi disponibili hai una flessibilità per ridimensionare il volume EBS .

Oltre ai vantaggi già elencati da Eric , deve anche essere consapevole che in termini di costo S3 può o meno essere più economico di EBS . Concordo sul fatto che la differenza di costo è relativamente ridotta se si continua a eseguire entrambi i tipi di istanza all'interno della stessa piattaforma e architettura dell'applicazione per tutto il tempo.

Tuttavia, se esiste uno scenario per eseguire l'applicazione su un servizio a basso costo, estrarre tutte le attività non gestite e assegnarle a VPC / EBS tramite una pipeline o lambda in breve tempo, ad esempio <1 ora al giorno, cosa impossibile da fare quando si usa un negozio di istanze , quindi sarà una storia diversa.