Puoi collegare Amazon EBS a più istanze?

Attualmente utilizziamo più server Web accedendo a un server mysql e un file server. Per quanto riguarda il passaggio al cloud, posso utilizzare questa stessa configurazione e collegare l'EBS a più istanze di macchina o qual è un'altra soluzione?

AGGIORNAMENTO (aprile 2015) : per questo caso d'uso, dovresti iniziare a guardare il nuovo Amazon Elastic File System (EFS) , progettato per essere moltiplicato esattamente nel modo desiderato. La differenza chiave tra EFS ed EBS è che forniscono diverse astrazioni: EFS espone il protocollo NFSv4, mentre EBS fornisce l'accesso IO a blocchi non elaborati.

Di seguito troverai la mia spiegazione originale sul perché non è possibile montare in sicurezza un dispositivo a blocchi grezzi su più macchine.

POST ORIGINALE (2011):

Anche se tu fossi in grado di ottenere un volume EBS associato a più di un'istanza, sarebbe un _REALLY_BAD_IDEA_. Per citare Kekoa, "è come usare un disco rigido in due computer contemporaneamente"

Perché questa è una cattiva idea? ... Il motivo per cui non è possibile collegare un volume a più di un'istanza è che EBS fornisce un'astrazione di "archiviazione dei blocchi" su cui i clienti eseguono un filesystem come ext2 / ext3 / etc. La maggior parte di questi filesystem (es. Ext2 / 3, FAT, NTFS, ecc.) Sono scritti assumendo che abbiano accesso esclusivo al dispositivo a blocchi. Due casi che accedono allo stesso filesystem finirebbero quasi sicuramente con lacrime e corruzione dei dati.

In altre parole, il doppio montaggio di un volume EBS funzionerebbe solo se si eseguiva un filesystem cluster progettato per condividere un dispositivo a blocchi tra più macchine. Inoltre, anche questo non sarebbe abbastanza. EBS dovrebbe essere testato per questo scenario e per garantire che fornisca le stesse garanzie di coerenza di altre soluzioni di dispositivi a blocchi condivisi ... vale a dire che i blocchi non vengono memorizzati nella cache a livelli intermedi non condivisi come il kernel Dom0, il livello Xen, e kernel DomU. E poi ci sono le considerazioni sulle prestazioni della sincronizzazione di blocchi tra più client: la maggior parte dei filesystem in cluster sono progettati per funzionare su SAN dedicate ad alta velocità, non su una Ethernet di consumo ottimale. Sembra così semplice, ma quello che stai chiedendo è una cosa non banale.

In alternativa, verifica se il tuo scenario di condivisione dei dati può essere NFS, SMB / CIFS, SimpleDB o S3. Tutte queste soluzioni utilizzano protocolli di livello superiore destinati a condividere file senza un sottosistema di dispositivi a blocchi condivisi. Molte volte tale soluzione è effettivamente più efficiente.

Nel tuo caso, puoi comunque avere una singola istanza / fileserver MySql a cui accedono più front-end web. Quel file server potrebbe quindi archiviare i suoi dati su un volume EBS, consentendoti di eseguire backup notturni di snapshot. Se l'istanza che esegue il file server viene persa, è possibile scollegare il volume EBS e ricollegarlo a una nuova istanza del file server ed eseguire il backup e l'esecuzione in pochi minuti.

"Esiste qualcosa come S3 come filesystem?" - sì e no. Sì, esistono soluzioni di terze parti come s3fs che funzionano "ok", ma devono comunque effettuare chiamate di servizi Web relativamente costose per ogni lettura / scrittura. Per una directory di strumenti condivisi, funziona alla grande. Per il tipo di utilizzo di cluster FS che vedi nel mondo HPC, non è una possibilità. Per fare meglio, avresti bisogno di un nuovo servizio che fornisce un protocollo binario orientato alla connessione, come NFS. Offrire un tale filesystem multi-montato con prestazioni e comportamento ragionevoli sarebbe un GRANDE componente aggiuntivo per EC2. Sono stato a lungo un sostenitore di Amazon per costruire qualcosa del genere.

Aggiornamento (2020) Ora è possibile!

Ciò è ora possibile con i tipi di istanza più recenti in esecuzione in AWS Nitro all'interno della stessa zona di disponibilità. Ci sono alcuni avvertimenti, ma questo è ottimo per alcuni casi d'uso che richiedono la velocità di EBS e in cui EFS non è fattibile.

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volumes-multi.html

Original Post (2009)

No, è come usare un disco rigido in due computer.

Se desideri dati condivisi, puoi configurare un server a cui possono accedere tutte le tue istanze. Se desideri un'area di archiviazione semplice per tutte le tue istanze, puoi utilizzare il servizio di archiviazione S3 di Amazon per archiviare dati distribuiti e scalabili.

Passando al cloud, puoi avere la stessa identica configurazione, ma puoi eventualmente sostituire il file server con S3 o avere tutte le tue istanze connesse al tuo file server.

Hai molte opzioni, ma la condivisione di un disco rigido tra istanze non è probabilmente l'opzione migliore.

No, secondo i documenti EBS: "Un volume può essere collegato solo a un'istanza alla volta".

Come stai usando l'archivio condiviso attualmente? Se è solo per servire i file dal file server, hai preso in considerazione la possibilità di configurare un sistema in modo da poter delegare determinate richieste a un processo sul file server piuttosto che far sì che i server web servano quei file?

Sono abbastanza sicuro che non puoi, ma puoi clonare un EBS e collegarlo a un'altra istanza.

Ciò è utile per set di dati fissi o per test su dati "reali", ma non consente a più di 1 istanza di operare su un singolo archivio di blocchi

Più server Web che accedono a MySQL Server e File Server sono normali in AWS. Alcune delle migliori pratiche da seguire per l'architettura sopra menzionata sono:

Punto 1) MySQL su EC2 può essere configurato come Master-Slave in modalità asincrona / semi-sincronizzata in AWS. EBS-OPT + PIOPS in RAID 0 è consigliato per DB ad alte prestazioni

Punto 2) In alternativa puoi utilizzare Amazon RDS + modalità Multi-AZ. Per il ridimensionamento in lettura di più RDS Read Replica può essere collegato a MySQL RDS.

Punto 3) Il volume EBS non può essere collegato contemporaneamente a più EC2. È possibile creare un file server basato su GlusterFS su Amazon EC2 utilizzando EBS. Più server Web possono comunicare contemporaneamente con GlusterFS singolo su AWS infra.

Punto 4) Nel caso in cui l'applicazione possa essere integrata con S3 come archivio di file, è preferibile per la stabilità che introduce nell'architettura. Puoi anche accedere a S3 usando anche strumenti come S3fuse dalla tua applicazione.

EBS ha appena annunciato che è possibile: https://aws.amazon.com/about-aws/whats-new/2020/02/ebs-multi-attach-available-provisioned-iops-ssd-volumes/

C'è qualcosa nel mondo IT noto come Clustered Filesystem, Redhat GFS, Oracle OCFS2, Veritas CFS ...

La risposta breve è un "No" categorico. Altri lo hanno detto sopra.

Chi ha detto "sì" non ha risposto alla domanda, ma a una domanda diversa. Se EFS è solo un servizio NFS, non è la risposta alla domanda come indicato in origine. E non importa se EFS è "implementato in tutte le zone" oppure no, perché puoi fare abbastanza la tua istanza NFS e far montare NFS su più server. Non è una novità, l'abbiamo già fatto nel 1992. SMB e sshfs, tutti questi sono solo modi per montare le unità come file system remoto.

Coloro che hanno detto "perché dovresti farlo" o "finirà tutto in lacrime" hanno torto. Da decenni montiamo più dischi su più server. Se hai mai lavorato con una SAN (Storage Area Network), la possibilità di collegare lo stesso dispositivo a più nodi di solito tramite SAN FibreChannel è del tutto normale. Quindi chiunque abbia eseguito server una decina di anni prima che i server di virtualizzazione / cloud diventassero onnipresenti ha una certa esposizione a questo.

Presto ci furono file system in cluster in cui due sistemi potevano leggere e scrivere nello stesso volume esatto. Credo che questo sia già iniziato con il tempo VAX e Alpha VMS nella storia. I file system cluster utilizzano uno schema distribuito di esclusione reciproca per essere in grado di manipolare direttamente i blocchi.

Il vantaggio di montare lo stesso disco su più nodi è la velocità e la riduzione di singoli punti di errore.

Ora, i file system in cluster non sono diventati molto popolari nel settore dell'hosting "consumer", questo è vero. E sono complicati e presentano alcune insidie. Ma non è nemmeno necessario un file system in cluster per utilizzare un disco collegato a più nodi di calcolo. Cosa succede se si desidera un'unità di sola lettura? Non hai nemmeno bisogno di un file system in cluster! Hai appena inserito nel tuo / etc / fstab lo stesso dispositivo fisico di sola lettura (ro). Quindi si monta su 2 o 10 server EC2 e tutti possono leggere direttamente da quel dispositivo!

Esiste un ovvio caso d'uso nel mondo dei server cloud quando si creano farm in rapida scalabilità. Puoi preparare il tuo disco di sistema principale e utilizzare solo un disco di avvio e configurazione molto piccolo per ciascuno dei server. Puoi anche farli avviare tutti dallo stesso disco di avvio e subito prima del rimontaggio di / in modalità lettura-scrittura, puoi inserire un Union-FS con 3 livelli:

1. Il disco di sistema principale di sola lettura, con installazione boot, kernel e userland
2. Un file system di configurazione, con solo pochi file (principalmente in / etc) specifici per il singolo server. Questo disco può essere scritto da un altro server per preparare l'avvio di una nuova istanza. I file di esempio qui sarebbero / etc / hostname e solo pochissimi file di configurazione che devono rimanere diversi per nodo.
3. Il disco scrivibile, che potrebbe non essere necessario, potrebbe essere solo / tmp come file system di memoria.

Quindi, sì, la domanda aveva molto senso, e sfortunatamente la risposta è (ancora) "No". E nessun NFS non è un ottimo sostituto per quel caso d'uso in quanto penalizza tutte le attività di lettura dal disco di sistema. Tuttavia, l'avvio di rete da un disco di sistema NFS è l'unica alternativa all'implementazione del caso d'uso sopra descritto. Sfortunatamente, dal momento che la configurazione di Network Boot Agent e NFS è molto più complicata del semplice accesso allo stesso dispositivo a blocchi fisici.

PS: Mi sarebbe piaciuto inviare una versione più breve di questo come commenti, ma non posso a causa della sciocca soglia di 51 punti di credito, quindi devo scrivere una risposta con lo stesso "No" essenziale ma includere il mio punto perché questo è una domanda pertinente che non ha ricevuto una risposta meritata.

PPS: Ho appena trovato qualcuno su StackExchange che menziona iSCSI. iSCSI è un po 'come NFS, ma logicamente come una SAN FibreChannel. Puoi accedere (e condividere) i dispositivi a blocchi fisici. Ciò renderebbe più semplice la condivisione del disco di avvio, quindi non è necessario impostare l'avvio della rete bootd che può essere complicato. Ma poi su AWS, non è disponibile neanche l'avvio di rete.

Sebbene in precedenza EBS avesse consentito di collegare un'unica istanza EC2 a un determinato volume, ora è possibile eseguire il multi-attach, almeno per i volumi di io1. Per ulteriori informazioni, consulta questo post sul blog AWS .

Perché non crei un'istanza con volume e sshfs su quel volume in altre istanze?

Puoi utilizzare totalmente un'unità su più server in AWS. Uso sshfs per montare un'unità esterna e condividerla con più server in EC2.

Il motivo per cui avevo bisogno di connettere una singola unità a più server è quello di avere un unico posto per mettere tutti i miei backup prima di scaricarli in locale.