EC2-tallennus: Instance Store ja EBS

Amazon EBS -taltiot ovat verkon kautta liitettyä tallennustilaa, joka säilyy EC2-instanssin elinkaaresta riippumatta. EBS-taltio sijaitsee tietyllä käytettävyysalueella, ja se voidaan liittää kerrallaan yhteen EC2-instanssiin, lukuun ottamatta io1/io2-multi-attachia. Kun pysäytät ja käynnistät instanssin uudelleen, EBS-taltio säilyttää kaikki tiedot. Voit irrottaa sen yhdestä instanssista ja liittää sen toiseen samassa käytettävyysalueessa tai luoda snapshotin kopioidaksesi sen toiseen käytettävyysalueeseen tai Regioniin.

AWS tarjoaa neljä EBS-taltiotyyppiä. gp3 (General Purpose SSD): perustaso on 3 000 IOPS ja 125 MB/s, ja arvot voidaan määrittää toisistaan riippumatta aina 16 000 IOPS:iin ja 1 000 MB/s:iin asti – oletusvalinta ja useimmille työkuormille kustannustehokkain vaihtoehto. gp2: vanhempi General Purpose SSD, jossa IOPS-arvo skaalautuu koon mukaan (3 IOPS/GB, enintään 16 000) – sitä ollaan korvaamassa gp3:lla. io2 Block Express: Provisioned IOPS SSD, joka tarjoaa enintään 256 000 IOPS:ia ja 4 000 MB/s – I/O-intensiivisiin tietokantoihin, kuten SAP HANAan tai Oracleen. io1: vanha Provisioned IOPS SSD.

Kaksi HDD-pohjaista EBS-tyyppiä on optimoitu läpimenokyvylle, ei IOPS-arvolle. st1 (Throughput Optimised HDD): perustaso on 40 MB/s/TB ja purskeena enintään 250 MB/s/TB – sopii suurten tietomäärien käsittelyyn, lokien käsittelyyn ja tietovarastoihin, joissa luetaan suuria peräkkäisiä tietomääriä. sc1 (Cold HDD): perustaso on 12 MB/s/TB ja purskeena enintään 80 MB/s/TB – edullisin EBS-vaihtoehto harvoin käytettäville peräkkäisille tiedoille. HDD-taltioita ei voi käyttää käynnistystaltiona (juurilaitteena). Valitkaa st1 tai sc1 vain, kun läpimenokyky on IOPS-arvoa tärkeämpi ja tietojen käyttötapa perustuu suuriin peräkkäisiin luku- ja kirjoitusoperaatioihin.

EBS-tilannevedokset ovat taltion ajankohdan mukaisia varmuuskopioita, jotka tallennetaan kestävästi Amazon S3:een (niitä käytetään kuitenkin EC2 API:n, ei suoraan S3:n, kautta). Tilannevedokset ovat inkrementaalisia: ensimmäinen tilannevedos sisältää koko taltion, ja seuraavat tilannevedokset sisältävät vain edellisen tilannevedoksen jälkeen muuttuneet lohkot, mikä pienentää tallennuskustannuksia. Voitte luoda uuden EBS-taltion mistä tahansa tilannevedoksesta missä tahansa saman Regionin AZ:ssa tai kopioida tilannevedoksen toiseen Regioniin alueiden välistä palautumista varten.

EBS-taltiot ja tilannevedokset voidaan salata AWS KMS -avaimilla. Salaus on instanssille läpinäkyvä: tiedot salataan sekä siirrettäessä instanssin ja taltion välillä että tallennettuina tallennusjärjestelmään. Voitte ottaa käyttöön tilitason oletussalauksen, jolloin jokainen tilille luotu uusi EBS-taltio salataan automaattisesti ilman taltiokohtaista määritystä. Salaamattoman taltion salaaminen edellyttää tilannevedoksen luomista, salatun kopion luomista tilannevedoksesta ja uuden taltion luomista salatusta tilannevedoksesta.

EBS Multi-Attach mahdollistaa io1- tai io2-taltion liittämisen samanaikaisesti enintään 16 EC2-instanssiin samassa Availability Zonessa. Kaikilla liitetyillä instansseilla on täydet luku- ja kirjoitusoikeudet. Tätä käytetään klusteroiduissa Linux-sovelluksissa, kuten Oracle RAC:ssa tai Teradatassa, jotka hallitsevat samanaikaisuutta sovelluskerroksessa klusterin tuntevan tiedostojärjestelmän avulla. Multi-Attach ei korvaa EFS:ää jaettuja tiedostojärjestelmiä käytettäessä, vaan se on tarkoitettu nimenomaan klusteroituun lohkotason käyttöön, jossa koordinoinnista vastaa sovellus.

Keskeiset valintaperusteet: Tarvitaanko tietojen säilymistä? → Käyttäkää EBS:ää. Voidaanko tiedot luoda uudelleen tai onko niistä replika? → Instance Store on sopiva ja tarjoaa paremman suorituskyvyn. Onko kyseessä tietokanta, joka sisältää kriittisiä tietoja? → Käyttäkää aina EBS:ää (tilannevedosten ja salauksen kanssa). Tarvitaanko ML-koulutukseen tai lajitteluoperaatioihin väliaikaista työtilaa? → Käyttäkää Instance Storea, joka tarjoaa parhaan läpimenokyvyn ilman lisäkustannuksia. Kokeessa esitetään usein tilanteita, joissa on tunnistettava, sopiiko tiettyyn työkuormaan haihtuva vai pysyvä tallennus.

EBS-optimointiin soveltuvat instanssit tarjoavat EC2-instanssin ja EBS:n välille omistetun verkkokaistan, joka on erillään instanssin yleisestä verkkokaistasta. Tämä estää sovellusliikenteen ja tallennuksen I/O:n välisen verkkokilpailun. Useimmat nykyisen sukupolven instanssityypit ovat oletusarvoisesti EBS-optimoituja ilman lisämaksua. Vanhemmissa instanssityypeissä EBS-optimointi on ehkä otettava käyttöön manuaalisesti (lisämaksua vastaan tuntiperusteisesti). Varmistakaa paljon I/O:ta käyttävissä tietokantatyökuormissa aina, että instanssityyppi on EBS-optimoitu, jotta taltiolle määritetty koko IOPS-kapasiteetti voidaan hyödyntää.

Amazon Data Lifecycle Manager (DLM) automatisoi EBS-tilannevedosten ja AMI-levykuvien luomisen, säilyttämisen ja poistamisen. Määritätte elinkaarikäytännöt, joissa ilmoitetaan tunnisteen perusteella varmuuskopioitavat taltiot, tilannevedosten luontitiheys (1, 2, 3, 4, 6, 8 tai 12 tunnin välein tai päivittäin) sekä säilytettävien tilannevedosten määrä. DLM poistaa mukautettujen varmuuskopiointiskriptien tarpeen ja integroituu CloudWatchiin käytäntöjen tilan valvontaa varten. Alueiden välisiä tilannevedoksia varten määrittäkää kopiointikäytäntö samaan DLM-määritykseen.

Tässä oppitunnissa opitte, että Instance Store tarjoaa parhaan paikallisen I/O-suorituskyvyn, mutta on haihtuva tallennus – tiedot menetetään pysäytyksen tai lopetuksen yhteydessä, EBS tarjoaa pysyvän verkon kautta liitetyn lohkotallennustilan, jossa on neljä IOPS-arvolle (gp3, io2) tai läpimenokyvylle (st1, sc1) optimoitua taltiotyyppiä ja että EBS-tilannevedokset mahdollistavat S3:een tallennetut taltion ajankohdan mukaiset varmuuskopiot, joita voidaan käyttää AZ:ien väliseen tai Regionien väliseen palautukseen. Seuraavaksi tutustumme S3 Object Storage Fundamentals -aiheeseen.