Archiviazione EC2: Instance Store ed EBS

Le istanze EC2 possono utilizzare due tipi di storage locale: Instance Store e Amazon EBS (Elastic Block Store). Instance Store è fisicamente collegato al server host e offre IOPS e throughput molto elevati, ma con un'importante limitazione: i dati vengono persi quando l'istanza viene arrestata o terminata. EBS fornisce storage a blocchi persistente collegato tramite rete, che sopravvive all'arresto, all'avvio e alla terminazione dell'istanza. Capire quando utilizzare ciascuna opzione è un argomento ricorrente nell'esame SAA-C03.

Instance Store, chiamato anche storage effimero, è costituito da SSD NVMe fisicamente collegati all'hardware host su cui viene eseguita l'istanza EC2. I dati nell'instance store vengono persi ogni volta che l'istanza viene arrestata, ibernata o terminata, oppure in caso di guasto dell'hardware sottostante. I dati persistono tuttavia dopo un riavvio. Instance Store è ideale per dati di buffer, cache o scratch, file temporanei e dati replicati in una fleet, ad esempio nodi Cassandra. Non tutti i tipi di istanza includono Instance Store; cercare il suffisso d, ad esempio i3.xlarge e m5d.large.

I volumi Amazon EBS sono storage collegato tramite rete che persiste indipendentemente dal ciclo di vita dell'istanza EC2. Un volume EBS risiede in una specifica Availability Zone e può essere collegato a una sola istanza EC2 alla volta, eccetto per il multi-attach io1/io2. Quando si arresta e riavvia un'istanza, il volume EBS conserva tutti i dati. È possibile scollegarlo da un'istanza e collegarlo a un'altra nella stessa AZ, oppure creare uno snapshot per copiarlo in un'altra AZ o Region.

AWS offre quattro tipi di volumi EBS. gp3 (SSD General Purpose): 3.000 IOPS e 125 MB/s di base, configurabili indipendentemente fino a 16.000 IOPS e 1.000 MB/s: la scelta predefinita e più conveniente per la maggior parte dei carichi di lavoro. gp2: precedente SSD General Purpose in cui gli IOPS aumentano con le dimensioni (3 IOPS/GB, massimo 16.000); viene gradualmente sostituito da gp3. io2 Block Express: SSD con IOPS provisioned fino a 256.000 IOPS e 4.000 MB/s, per database con uso intensivo dell'I/O come SAP HANA o Oracle. io1: SSD con IOPS provisioned di generazione precedente.

I due tipi di EBS basati su HDD sono ottimizzati per il throughput, non per gli IOPS. st1 (HDD ottimizzato per il throughput): 40 MB/s/TB di base, fino a 250 MB/s/TB in burst, ideale per big data, elaborazione dei log e data warehouse con letture sequenziali di grandi dimensioni. sc1 (HDD Cold): 12 MB/s/TB di base, fino a 80 MB/s/TB in burst, l'opzione EBS meno costosa per dati sequenziali consultati raramente. I volumi HDD non possono essere utilizzati come volumi di avvio (dispositivo root). Scelga st1 o sc1 solo quando il throughput è più importante degli IOPS e il modello di accesso ai dati prevede letture/scritture sequenziali di grandi dimensioni.

Gli snapshot EBS sono backup di un volume a un determinato punto nel tempo, archiviati in modo durevole in Amazon S3 (anche se vi si accede tramite l'API EC2, non direttamente tramite S3). Gli snapshot sono incrementali: il primo snapshot acquisisce l'intero volume, mentre gli snapshot successivi registrano solo i blocchi modificati dall'ultimo snapshot, riducendo i costi di archiviazione. È possibile creare un nuovo volume EBS da qualsiasi snapshot in qualsiasi AZ all'interno della stessa Region, oppure copiare lo snapshot in un'altra Region per il disaster recovery tra Region.

I volumi e gli snapshot EBS possono essere crittografati utilizzando le chiavi AWS KMS. La crittografia è trasparente per l'istanza: i dati vengono crittografati durante il transito tra l'istanza e il volume e quando sono inattivi nello storage. È possibile abilitare la crittografia predefinita a livello di account, in modo che ogni nuovo volume EBS creato nell'account venga crittografato automaticamente senza configurazioni per singolo volume. Per crittografare un volume non crittografato è necessario creare uno snapshot, creare una copia crittografata dello snapshot e quindi creare un nuovo volume dallo snapshot crittografato.

EBS Multi-Attach consente di collegare un volume io1 o io2 a un massimo di 16 istanze EC2 nella stessa Availability Zone contemporaneamente. Tutte le istanze collegate hanno accesso completo in lettura e scrittura. Questa funzionalità viene utilizzata per applicazioni Linux in cluster (come Oracle RAC o Teradata) che gestiscono la concorrenza a livello applicativo utilizzando un file system compatibile con i cluster. Multi-Attach non sostituisce EFS per i file system condivisi: è specificamente destinato all'accesso a livello di blocco in cluster, con coordinamento gestito dall'applicazione.

Criteri decisionali principali: È necessaria la persistenza? → Utilizzi EBS. I dati possono essere ricreati o sono replicati? → Instance Store è una scelta accettabile e offre prestazioni superiori. Database con dati critici? → Utilizzi sempre EBS (con snapshot e crittografia). Spazio temporaneo per lo scratch durante l'addestramento ML o per operazioni di ordinamento? → Instance Store offre il throughput massimo senza costi aggiuntivi. Nell'esame vengono spesso presentati scenari in cui è necessario stabilire se per un determinato carico di lavoro sia appropriato uno storage effimero o persistente.

Le istanze ottimizzate per EBS forniscono una larghezza di banda di rete dedicata tra l'istanza EC2 ed EBS, separata dalla larghezza di banda di rete generale dell'istanza. In questo modo si evita la contesa di rete tra il traffico dell'applicazione e l'I/O dello storage. La maggior parte dei tipi di istanza di generazione attuale è ottimizzata per EBS per impostazione predefinita e senza costi aggiuntivi. Per i tipi di istanza meno recenti potrebbe essere necessario abilitare manualmente l'ottimizzazione EBS (con un costo orario aggiuntivo). Per i carichi di lavoro di database con I/O elevato, verifichi sempre che il tipo di istanza sia ottimizzato per EBS, così da ottenere tutti gli IOPS provisioned del volume.

Amazon Data Lifecycle Manager (DLM) automatizza la creazione, la conservazione e l'eliminazione di snapshot EBS e AMI. È possibile definire policy del ciclo di vita che specificano quali volumi sottoporre a backup (in base ai tag), con quale frequenza creare gli snapshot (ogni 1, 2, 3, 4, 6, 8 o 12 ore, oppure ogni giorno) e quanti snapshot conservare. DLM elimina la necessità di script di backup personalizzati e si integra con CloudWatch per monitorare lo stato delle policy. Per gli snapshot tra Region, configuri una policy di copia nella stessa definizione DLM.

Verifichi la Sua comprensione dei concetti di AWS Solutions Architect (SAA-C03) trattati in questa lezione.

In questa lezione ha appreso che: Instance Store offre le migliori prestazioni di I/O locale, ma è effimero: i dati vengono persi quando l'istanza viene arrestata o terminata; EBS fornisce uno storage a blocchi persistente collegato tramite rete, con quattro tipi di volume ottimizzati per gli IOPS (gp3, io2) o per il throughput (st1, sc1); e gli snapshot EBS consentono di creare backup a un determinato punto nel tempo, archiviati in S3 e utilizzabili per il ripristino tra AZ o tra Region. Nel prossimo argomento esploreremo i fondamenti dello storage di oggetti S3.