EBS is een blokopslagservice die wordt aangeboden door AWS. Als u een EC2-instantie gebruikt, gebruikt u deze zeker, omdat deze dient als opslagschijf voor uw server. Het is echter niet veilig voor storingen en u moet nog steeds regelmatig back-ups maken.
“Fout-Tolerant” betekent niet veilig
Natuurlijk is EBS redelijk fouttolerant op de backend. AWS zijn geen stelletjes die een JBOD-array draaien; ze hebben gepland voor enkele schijfstoringen, dus een enkele slechte schijf zal uw server niet uitschakelen.
EBS-storingen kunnen en gebeuren echter ook, aangezien EBS-volumes een jaarlijks uitvalpercentage (AFR) tussen 0 hebben.1% -0,2%. Dit is niet veel, en het is erg laag in vergelijking met de ~4% van een enkele harde schijf, maar het is niet niets. Het is niet waarschijnlijk dat uw EBS-volume gewoon fa alt, maar als u er tonnen gebruikt, bestaat de kans dat u hier en daar een paar problemen tegenkomt.
De makkelijke oplossing is natuurlijk het maken van back-ups. EBS biedt hiervoor een geweldig hulpmiddel: de snapshot-functie. U kunt een momentopname maken, die fungeert als een back-up die is opgeslagen in S3, die veel duurzamer is. In het geval van een EBS-storing, kunt u herstellen vanaf een back-up. U hoeft dit niet zelf te automatiseren, omdat EBS Lifecycle Manager dit voor u kan doen, maar het is niet standaard ingeschakeld. U moet natuurlijk de extra opslagkosten betalen die gepaard gaan met het opslaan van gegevens in S3, maar het is goedkoper dan EBS.
AWS probeert dit feit niet te verbergen en raadt aan om regelmatig snapshot-back-ups te maken. De meeste mensen zullen ook aanraden om in het algemeen back-ups te maken, maar het is gemakkelijk om verstrikt te raken in de magie van de cloud en dit feit te vergeten. Aan het eind van de dag is het gewoon de computer van iemand anders en kan het net als elke andere falen. Een extreem voorbeeld hiervan is in september 2019, toen een AWS US-EAST-1 datacenter een stroomstoring had en een generatorstoring, waardoor de EBS-servers en de gegevens ermee werden uitgeschakeld.
De belangrijkste drijfveer achter architectuur met hoge beschikbaarheid en cloudcomputing in het algemeen is ervoor te zorgen dat wanneer geïsoleerde storingen onvermijdelijk optreden, niet de hele applicatie wordt uitgeschakeld. Je moet nog steeds stappen ondernemen om storingen te voorkomen, maar soms, zoals bij harde schijven, is het een hardwareprobleem, niet iets dat je met code kunt oplossen.
S3, aan de andere kant, is erg veilig, met 99,999999999% van de duurzaamheid (dat is elf negens). Als u 10.000 objecten opslaat in S3, kunt u gemiddeld eens in de 10.000 jaar een enkel object verliezen. Dit komt omdat, in tegenstelling tot EBS, S3 volledig wordt gerepliceerd in minimaal drie beschikbaarheidszones en constant wordt gecontroleerd op schijfstoringen binnen elke zone. Zelfs als een heel datacenter in vlammen opgaat, zouden je S3-buckets en de snapshots erin nog steeds veilig moeten zijn.
Hoe werken EBS-snapshots?
EBS snapshots zijn incrementele back-ups. Elke volgende back-up slaat alleen de gegevens op die zijn gewijzigd, dus u maakt geen gekke opslagkosten door regelmatig snapshots te maken.
Ze aanzetten is vrij eenvoudig. Ga vanuit de EC2-console naar Elastic Block Store > Lifecycle Manager in de zijbalk en maak een nieuw beleid.
Lifecycle Manager om een nieuw beleid te maken." />
Je moet een tag opgeven waarop dit beleid van toepassing is. Dit kan de naam zijn van een enkel EBS-volume, of een algemene tag die op alles van toepassing is.
U kunt het schema voor dit beleid instellen, evenals het beleid voor het bewaren van snapshots. U hoeft meestal geen uitgebreide back-ups te maken, dus een handvol daarvan, afhankelijk van de momentopnamefrequentie, zou in orde moeten zijn.
Als je serieus bent over hoge beschikbaarheid, kun je ook Fast Snapshot Restore inschakelen, waardoor het herstel volledig onmiddellijk wordt uitgevoerd. Het is echter vrij duur, dus dit is niet iets dat iedereen zou moeten inschakelen.
