Pamięć masowa EC2: Instance Store a EBS

Instancje EC2 mogą korzystać z dwóch typów lokalnej pamięci masowej: Instance Store i Amazon EBS (Elastic Block Store). Instance Store jest fizycznie podłączony do serwera hosta i oferuje bardzo wysoką liczbę IOPS oraz przepustowość, ale ma istotne ograniczenie — dane są tracone po zatrzymaniu lub zakończeniu działania instancji. EBS zapewnia trwałą, blokową pamięć masową podłączoną przez sieć, która zachowuje dane po zatrzymaniu, ponownym uruchomieniu i zakończeniu działania instancji. Zrozumienie, kiedy używać każdego z tych rozwiązań, jest stałym tematem egzaminu SAA-C03.

Instance Store (nazywany także pamięcią efemeryczną) składa się z dysków SSD NVMe fizycznie podłączonych do sprzętu hosta, na którym działa instancja EC2. Dane w Instance Store są tracone, gdy instancja zostanie zatrzymana, zahibernowana lub zakończona, a także w przypadku awarii sprzętu bazowego. Dane zachowują się jednak po ponownym uruchomieniu. Instance Store idealnie nadaje się do przechowywania buforów, pamięci podręcznej i danych roboczych, plików tymczasowych oraz danych replikowanych w całej flocie (np. węzłów Cassandra). Nie wszystkie typy instancji zawierają Instance Store; należy szukać przyrostka d (np. i3.xlarge, m5d.large).

Woluminy Amazon EBS to pamięć masowa podłączana przez sieć, która zachowuje dane niezależnie od cyklu życia instancji EC2. Wolumin EBS znajduje się w określonej strefie Availability Zone i można go jednocześnie podłączyć do jednej instancji EC2 (z wyjątkiem funkcji multi-attach dla io1/io2). Po zatrzymaniu i ponownym uruchomieniu instancji wolumin EBS zachowuje wszystkie dane. Można odłączyć go od jednej instancji i podłączyć do innej w tej samej strefie AZ albo utworzyć snapshot, aby skopiować go do innej strefy AZ lub regionu.

AWS oferuje cztery typy woluminów EBS. gp3 (General Purpose SSD): bazowo 3000 IOPS i 125 MB/s, z możliwością niezależnej konfiguracji do 16 000 IOPS i 1000 MB/s — domyślny i najbardziej opłacalny wybór dla większości obciążeń. gp2: starszy typ General Purpose SSD, w którym liczba IOPS rośnie wraz z rozmiarem (3 IOPS/GB, maks. 16 000) — jest wycofywany na rzecz gp3. io2 Block Express: SSD z aprowizowanymi IOPS, zapewniający do 256 000 IOPS i 4000 MB/s — przeznaczony do baz danych intensywnie korzystających z operacji wejścia-wyjścia, takich jak SAP HANA czy Oracle. io1: starszy typ SSD z aprowizowanymi IOPS.

Dwa typy EBS oparte na dyskach HDD są zoptymalizowane pod kątem przepustowości, a nie liczby IOPS. st1 (Throughput Optimised HDD): bazowo 40 MB/s/TB, z możliwością chwilowego zwiększenia do 250 MB/s/TB — idealny do obsługi dużych zbiorów danych, przetwarzania logów i hurtowni danych wykonujących duże sekwencyjne odczyty. sc1 (Cold HDD): bazowo 12 MB/s/TB, z możliwością chwilowego zwiększenia do 80 MB/s/TB — najtańsza opcja EBS dla rzadko używanych danych odczytywanych sekwencyjnie. Woluminów HDD nie można używać jako woluminów rozruchowych (urządzeń głównych). Należy wybrać st1 lub sc1 tylko wtedy, gdy przepustowość jest ważniejsza niż liczba IOPS, a sposób dostępu do danych obejmuje duże sekwencyjne odczyty i zapisy.

Migawki EBS to kopie zapasowe woluminu z określonego punktu w czasie, przechowywane trwale w Amazon S3 (choć uzyskuje się do nich dostęp za pośrednictwem interfejsu API EC2, a nie bezpośrednio przez S3). Migawki są przyrostowe: pierwsza migawka obejmuje cały wolumin, a kolejne zapisują tylko bloki, które zmieniły się od utworzenia poprzedniej migawki, co ogranicza koszty przechowywania. Na podstawie dowolnej migawki można utworzyć nowy wolumin EBS w dowolnej strefie dostępności w tym samym Regionie albo skopiować migawkę do innego Regionu na potrzeby odzyskiwania po awarii obejmującej wiele Regionów.

Woluminy i migawki EBS można szyfrować za pomocą kluczy AWS KMS. Szyfrowanie jest niewidoczne dla instancji — dane są szyfrowane podczas przesyłania między instancją a woluminem oraz podczas przechowywania. Można włączyć domyślne szyfrowanie na poziomie konta, aby każdy nowy wolumin EBS utworzony na koncie był automatycznie szyfrowany bez konfiguracji dla poszczególnych woluminów. Aby zaszyfrować niezaszyfrowany wolumin, należy utworzyć migawkę, utworzyć zaszyfrowaną kopię migawki, a następnie utworzyć nowy wolumin na podstawie zaszyfrowanej migawki.

Funkcja EBS Multi-Attach umożliwia jednoczesne podłączenie woluminu io1 lub io2 do maksymalnie 16 instancji EC2 w tej samej strefie dostępności. Wszystkie podłączone instancje mają pełny dostęp do odczytu i zapisu. Funkcja ta służy do obsługi klastrowych aplikacji Linux (takich jak Oracle RAC czy Teradata), które zarządzają współbieżnością na poziomie aplikacji za pomocą systemu plików świadomego działania klastra. Multi-Attach nie zastępuje EFS w przypadku współdzielonych systemów plików — jest przeznaczona konkretnie do klastrowego dostępu na poziomie bloków ze skoordynowanym zarządzaniem przez aplikację.

Najważniejsze kryteria wyboru: Czy wymagana jest trwałość danych? → Należy użyć EBS. Czy dane można odtworzyć albo są replikowane? → Instance Store jest dopuszczalnym wyborem i zapewnia wyższą wydajność. Czy jest to baza danych zawierająca krytyczne dane? → Zawsze należy użyć EBS (wraz z migawkami i szyfrowaniem). Czy potrzebna jest tymczasowa przestrzeń robocza na potrzeby trenowania modeli ML lub operacji sortowania? → Instance Store zapewni maksymalną przepustowość bez dodatkowych kosztów. W egzaminie często pojawiają się scenariusze, w których należy określić, czy dla danego obciążenia odpowiednia jest pamięć nietrwała czy trwała.

Instancje zoptymalizowane pod kątem EBS zapewniają dedykowaną przepustowość sieci między instancją EC2 a EBS, niezależną od ogólnej przepustowości sieci instancji. Zapobiega to rywalizacji o zasoby sieci między ruchem aplikacji a operacjami wejścia-wyjścia pamięci masowej. Większość typów instancji bieżącej generacji jest domyślnie zoptymalizowana pod kątem EBS, bez dodatkowych opłat. W przypadku starszych typów instancji może być konieczne ręczne włączenie optymalizacji EBS, co wiąże się z dodatkową opłatą godzinową. W przypadku obciążeń baz danych intensywnie korzystających z operacji wejścia-wyjścia należy zawsze sprawdzić, czy dany typ instancji jest zoptymalizowany pod kątem EBS, aby uzyskać pełną aprowizowaną liczbę IOPS woluminu.

Amazon Data Lifecycle Manager (DLM) automatyzuje tworzenie, przechowywanie i usuwanie migawek EBS oraz AMI. Należy zdefiniować zasady cyklu życia określające, które woluminy mają być uwzględniane w kopiach zapasowych (według tagu), jak często mają być tworzone migawki (co 1, 2, 3, 4, 6, 8 lub 12 godzin albo codziennie) oraz ile migawek należy zachować. DLM eliminuje potrzebę tworzenia niestandardowych skryptów kopii zapasowych i integruje się z CloudWatch w celu monitorowania stanu zasad. W przypadku migawek międzyregionowych należy skonfigurować zasadę kopiowania w tej samej definicji DLM.

W tej lekcji nauczyli się Państwo, że: Instance Store zapewnia najwyższą wydajność lokalnych operacji wejścia-wyjścia, ale jest pamięcią nietrwałą — dane są tracone po zatrzymaniu lub zakończeniu instancji, EBS zapewnia trwałą, sieciową pamięć blokową z czterema typami woluminów zoptymalizowanymi pod kątem IOPS (gp3, io2) lub przepustowości (st1, sc1), a migawki EBS umożliwiają tworzenie kopii zapasowych z określonego punktu w czasie, przechowywanych w S3 i możliwych do wykorzystania podczas odzyskiwania między strefami dostępności lub Regionami. W następnej części omówimy podstawy magazynu obiektowego S3.