Nie ma wątpliwości, że Amazon jest liderem, jeśli chodzi o różnorodność usług chmurowych oferowanych za pośrednictwem usługi internetowej EC2 (Elastic Compute Cloud). Dzięki stosunkowo prostemu procesowi provisioningu i możliwości łatwego skalowania instancji i potrzeb w zakresie pamięci masowej, EC2 ma na celu spełnienie wszystkich obietnic chmury w opłacalnej cenie. Dla niektórych jednak chmura to nie tylko elastyczność i łatwość wdrożenia; to także wydajność. Korzyści biznesowe wynikające z możliwości uruchamiania lub wyłączania wydajnych środowisk dla krytycznych aplikacji, takich jak analityka, często znacznie przewyższają koszty operacyjne zamiast długoterminowych inwestycji w CAPEX. W tym celu w maju Amazon wprowadził na rynek rodzinę instancji i3 bare metal, która zapewnia bezpośredni dostęp do zasobów procesora i pamięci serwera bazowego.
Instancje i3.metal są zbudowane w oparciu o system Nitro, który stanowi zbiór komponentów AWS do sprzętowego odciążania i ochrony serwerów, które „bezpiecznie zapewniają instancjom EC2 zasoby sieciowe i pamięci masowej o wysokiej wydajności”. Instancje i3.metal korzystają również ze wszystkich innych usług oferowanych przez AWS Cloud, takich jak Elastic Block Store (EBS), z którego korzystaliśmy w ramach tej recenzji. Instancje oferują również do 15.2 TB pamięci masowej opartej na dyskach SSD NVMe, a także procesory Intel Xeon 2.3 GHz z 36 rdzeniami hiperwątkowymi (72 procesory logiczne) i 512 GB pamięci. Po stronie infrastruktury, instancje i3.metal zapewniają łączną przepustowość sieci do 25 Gb/s, co przekłada się na wysoką przepustowość sieci i niższe opóźnienia dzięki technologii Enhanced Networking opartej na Elastic Network Adapter (ENA).
W EC2 istnieje wiele typów instancji. Instancje i3 należą do kategorii „Zoptymalizowane pod kątem pamięci masowej”, a instancje i3.metal są najwydajniejsze w tej grupie. Poniższa tabela przedstawia rodzinę i konfigurację typów instancji.
| Model | procesor wirtualny | Pamięć (GiB) | Wydajność sieciowa | Pamięć masowa (TB) |
| i3.duży | 2 | 15.25 | Do 10 gigabitów | Dysk SSD 1x0.475 NVMe |
| i3.xlarge | 4 | 30.5 | Do 10 gigabitów | Dysk SSD 1x0.95 NVMe |
| i3.2xduży | 8 | 61 | Do 10 gigabitów | Dysk SSD 1x1.9 NVMe |
| i3.4xduży | 16 | 122 | Do 10 gigabitów | Dysk SSD 2x1.9 NVMe |
| i3.8xduży | 32 | 244 | 10 Gigabit | Dysk SSD 4x1.9 NVMe |
| i3.16xduży | 64 | 488 | 25 Gigabit | Dysk SSD 8x1.9 NVMe |
| i3.metal | 72 | 512 | 25 Gigabit | Dysk SSD 8x1.9 NVMe |
Instancje i3.metal są dostępne w regionach AWS US East (Północna Wirginia), US East (Ohio), US West (Oregon), Europe (Frankfurt) i Europe (Irlandia) i można je zakupić jako instancje na żądanie, instancje rezerwowe (3-letnie, roczne i konwertowalne) lub jako instancje spot. Na potrzeby niniejszej recenzji przeprowadziliśmy testy w regionie Północnej Wirginii. Testy przeprowadzono zarówno z pamięcią masową NVMe, jak i woluminami blokowymi EBS.
Wydajność
Analiza obciążenia VDBench
Aby ocenić wydajność instancji EC2 i3.metal, wykorzystaliśmy lokalnie zainstalowany program VDBench do przetestowania pamięci masowej EBS (30 x 1 TB) i NVMe (8 x 1.7 TB). W przypadku obu typów pamięci masowej, przydzieliliśmy 12% zasobów każdego urządzenia i zgrupowaliśmy je w celu sprawdzenia szczytowej wydajności systemu przy umiarkowanej lokalizacji danych.
Te obciążenia oferują szereg zróżnicowanych profili testowych, od testów „czterech narożników”, przez testy rozmiaru transferu wspólnej bazy danych, po przechwytywanie śladów z różnych środowisk VDI. Wszystkie te testy wykorzystują wspólny generator obciążeń vdBench z silnikiem skryptowym do automatyzacji i przechwytywania wyników w dużym klastrze obliczeniowym. Pozwala to nam powtarzać te same obciążenia w szerokiej gamie urządzeń pamięci masowej, w tym w macierzach flash i indywidualnych urządzeniach pamięci masowej.
Profile:
- Losowy odczyt 4K: 100% odczytu, 128 wątków, 0-120% ioratu
- Losowy zapis 4K: 100% zapisu, 64 wątki, 0-120% ioracji
- 64K Sekwencyjny odczyt: 100% odczytu, 16 wątków, 0-120% ioratu
- 64K Sekwencyjny zapis: 100% zapisu, 8 wątków, 0-120% ioratu
- Syntetyczna baza danych: SQL i Oracle
- Ślady klonów połączonych VDI
W tej recenzji analizujemy zarówno EBS, jak i NVMe. Ze względu na znaczną różnicę w wydajności, podzieliliśmy wyniki na dwa wykresy (opóźnienia byłyby tak duże, że wykresy byłyby bardzo trudne do odczytania).
Nasz pierwszy test dotyczy losowego odczytu 4K. W tym przypadku instancja EBS osiągała opóźnienie poniżej milisekundy aż do samego końca. Przy około 64K IOPS opóźnienie gwałtownie wzrosło do 59.46 ms, a wydajność wyniosła 64 047 IOPS.
Patrząc na szczytowy odczyt losowy NVMe 4K, widzimy, że instancja działa znacznie lepiej. Osiągnęła szczytowy wynik 2 802 904 IOPS z opóźnieniem 348 μs.
Losowy zapis 4K z EBS dał niemal taki sam wynik, jak odczyt 4K z EBS. Instancja załamała się nieco 1 ms wcześniej, osiągając około 60 tys. operacji wejścia/wyjścia na sekundę (IOPS), a szczytowy wynik wyniósł 64 003 IOPS z opóźnieniem 29.97 ms.
W przypadku wersji instancji NVMe wystąpił niewielki wzrost opóźnienia, ale nadal poniżej 1 ms. Instancja osiągnęła szczytową wartość 920 975 IOPS z opóźnieniem 545 μs.
Przechodząc do testów sekwencyjnych, w przypadku szczytowej wydajności odczytu EBS wynoszącej 64 KB, instancja miała opóźnienie mniejsze od milisekundy do około 70 000 IOPS lub około 450 MB/s i osiągnęło szczyt na poziomie 17 360 IOPS lub 1.08 GB/s przy opóźnieniu wynoszącym 27.65 ms.
Odczyt sekwencyjny 64 KB przy użyciu interfejsu NVMe pozwolił nam osiągnąć szczytową wydajność na poziomie 244 037 IOPS, czyli 15.25 GB/s, przy opóźnieniu 514 μs.
Przy zapisie 64 KB z EBS instancja rozpoczęła działanie z prędkością powyżej 1 ms i osiągnęła szczyt na poziomie 17 359 IOPS lub 1.08 GB/s przy opóźnieniu 13.8 ms.
Sekwencyjny zapis 64 KB to pierwszy przypadek, gdy instancja NVMe przekroczyła 1 ms. Instancja osiągnęła szczytową wartość 58 572 IOPS, czyli 3.66 GB/s, z opóźnieniem 1.08 ms.
Po przełączeniu się na obciążenia SQL, instancja EBS osiągnęła opóźnienie poniżej milisekundy do około 55 tys. operacji wejścia/wyjścia na sekundę (IOPS), a szczytowe opóźnienie wyniosło 64 036 operacji wejścia/wyjścia na sekundę (IOPS) i 14.93 ms.
W przypadku wersji instancji NVMe osiągnęliśmy szczytową wydajność na poziomie 834 231 IOPS przy opóźnieniu 302 μs podczas testu SQL.
W przypadku SQL 90-10 z EBS instancja ponownie przekroczyła opóźnienie 1 ms przy około 55 tys. operacji wejścia/wyjścia na sekundę (IOPS), a następnie osiągnęła szczyt na poziomie 64 036 operacji wejścia/wyjścia na sekundę (IOPS) z opóźnieniem 14.99 ms.
Wersja NVMe instancji w SQL 90-10 osiągnęła szczytową wydajność 605 150 IOPS i opóźnienie 415 μs.
SQL 80-20 z EBS ponownie dał niemal takie same wyniki, przy opóźnieniu poniżej milisekundy wynoszącym ostatecznie około 55 tys. operacji wejścia/wyjścia na sekundę (IOPS) i wartości szczytowej 64 036 operacji wejścia/wyjścia na sekundę (IOPS) przy opóźnieniu 14.93 ms.
W przypadku SQL 80-20 z NVMe liczba wywołań instancji wyniosła 511 840 IOPS, a opóźnienie 493 μs.
Testy Oracle dla EBS wykazały tę samą, nietypową wydajność szczytową, niemal identyczną. W przypadku Oracle instancja osiągnęła 64 036 IOPS z opóźnieniem 13.6 ms. Opóźnienie instancji było niższe niż milisekunda do około 55 tys. IOPS.
Dzięki NVMe instancja osiągnęła 457 372 IOPS przy opóźnieniu 613 μs w teście Oracle.
W przypadku Oracle 90-10 szczytowa wydajność instancji EBS wyniosła 64 035 IOPS, a opóźnienie 10.3 ms. Przy około 55 tys. IOPS instancja zanotowała spadek o 1 ms.
Wersja NVMe instancji w Oracle 90-10 osiągnęła 520 448 IOPS przy opóźnieniu 333 μs.
W systemie Oracle 80-20 przerwa EBS wynosiła 1 ms przy około 55 tys. operacji wejścia/wyjścia na sekundę (IOPS), a szczyt wyniósł 64 036 operacji wejścia/wyjścia na sekundę (IOPS) przy opóźnieniu wynoszącym 10.3 ms.
Instancja z NVMe osiągnęła szczytową wydajność 435 265 IOPS przy opóźnieniu 400 μs.
Następnie przyjrzymy się naszym testom VDI Linked Clone (LC). Począwszy od Boot, wersja instancji EBS miała opóźnienie poniżej milisekundy, aż do około 35 tys. operacji wejścia/wyjścia na sekundę (IOPS), osiągając szczyt na poziomie 42 893 operacji wejścia/wyjścia na sekundę (IOPS) z opóźnieniem 11.2 ms.
Wersja NVMe instancji osiągnęła szczytową wydajność 349 799 IOPS i opóźnienie 363 μs w naszym teście rozruchu VDI LC.
Podczas początkowego logowania do VDI LC instancja EBS przez pewien czas utrzymywała się na poziomie 1 ms, po czym spadła do około 31 tys. IOPS. Instancja osiągnęła szczyt na poziomie 34 486 IOPS i opóźnieniu 6.95 ms.
Podczas początkowego logowania do VDI LC instancja NVMe osiągnęła szczyt na poziomie 93 405 IOPS przy opóźnieniu 677 μs.
Podczas poniedziałkowego logowania VDI LC instancja EBS ponownie przez pewien czas utrzymywała się na poziomie 1 ms, po czym nastąpił spadek do około 25 tys. operacji wejścia/wyjścia na sekundę (IOPS), a szczytowy wynik wyniósł 34 643 IOPS, a opóźnienie wyniosło 13.85 ms.
I wreszcie, w naszym VDI LC Monday Login z NVMe szczytowa liczba operacji wejścia/wyjścia na sekundę wyniosła 119 615, a opóźnienie 1.1 ms.
Wniosek
Usługi chmurowe Amazon są zazwyczaj uważane za najbardziej wszechstronne na rynku. Chociaż moc obliczeniowa i pamięć masowa są z pewnością zróżnicowane, Amazon oferuje również opcje wydajnościowe. Amazon oferuje mnóstwo opcji wydajnościowych w ramach swojej usługi sieciowej EC2, w tym instancję bare metal i3. Instancje te wykorzystują system AWS Nitro, składający się ze specjalnie zaprojektowanego sprzętu i oprogramowania. Instancje i3.metal zapewniają lepszą wydajność dzięki bezpośredniemu dostępowi do procesorów i pamięci, jednocześnie oferując użytkownikom możliwość korzystania z innych funkcji, takich jak podłączona pamięć masowa AWS EBS i lokalna pamięć masowa NVMe.
Pod kątem wydajności przetestowaliśmy zarówno pamięć blokową (EBS), jak i NVMe. Ma to na celu dać czytelnikom pojęcie, czego można się spodziewać pod względem opcji, a mniej o tym, czy jedna jest lepsza od drugiej (zazwyczaj pamięć NVMe działa lepiej i ma znacznie niższe opóźnienia, dlatego zamieszczono dwa zestawy wykresów). Analizując EBS, zaobserwowaliśmy schemat, w którym instancja przekraczała 1 ms, a wkrótce potem wzrastało opóźnienie i czas wykonania. Podczas naszych testów EBS osiągnął szczyt na poziomie około 64 tys. IOPS, co jest maksymalną wartością dozwoloną dla EBS. Dotyczyło to testów 4K oraz wszystkich trzech testów SQL i Oracle. Instancja nieco zwolniła podczas naszych testów VDI. Amazon wskazuje, że możliwe jest dostosowanie ustawień, aby osiągnąć więcej niż zalecane 64 tys. IOPS, ale procesy dojścia do tego nie są tym, czego doświadczyłaby większość klientów, dlatego nie podążaliśmy tą ścieżką.
W naszych testach NVMe uzyskaliśmy wyniki bardziej zbliżone do naszych standardowych testów porównawczych. Najważniejsze wyniki to: losowy odczyt 4K na poziomie 2.8 mln IOPS, zapis 4K na poziomie 920 tys. IOPS, odczyt 64K na poziomie 15.25 GB/s oraz wydajność SQL przekraczająca 500 tys. IOPS we wszystkich trzech testach (przy czym w teście SQL wynik wyniósł około 834 tys. IOPS). Testy Oracle również wypadły dobrze z NVMe, z wynikami od 435 tys. IOPS do 520 tys. IOPS. Nasz klon VDI Linked Clone wykazał wysoką wydajność rozruchu, wynoszącą około 350 tys. IOPS. Jedynym rozczarowaniem jest brak możliwości wyboru lokalnej wydajności NVMe w instancjach i3.metal.
Ogólnie rzecz biorąc, instancja i3.metal dała nam dokładnie to, co obiecał Amazon. To pocieszające dla klientów, którzy chcą mieć pewność, że otrzymają obiecany poziom usług. Oczywiście nie jest to bezkosztowe, ponieważ jak w przypadku każdego wdrożenia w chmurze, problemem jest łatwość obsługi i wyniki w porównaniu z chmurą w porównaniu z innymi dostawcami chmury i rozwiązaniami lokalnymi. Niemniej jednak klienci, których obciążenia mogą obejść się bez niższego poziomu IOPS, mogą sporo zaoszczędzić. Jednak tak naprawdę wszystko sprowadza się do ostatecznych wymagań konkretnej instancji. W tym kontekście instancje i3.metal doskonale sprawdzają się w przypadku popularnych aplikacji, które nie przekroczą lub nie są w stanie przekroczyć limitów wydajności oferowanych przez i3.metal i nie potrzebują IOPS, jakie zapewnia na przykład macierz all-flash lokalna. Ponadto, jeśli korzystasz już z rozwiązań Amazon, przejście na serwery fizyczne jest znane i prawdopodobnie wiąże się z korzyściami finansowymi przy jednoczesnym korzystaniu z kilku programów AWS naraz.
Amazon