Oracle Cloud Infrastructure oferuje szeroką gamę usług, w tym moc obliczeniową, pamięć masową, sieć, bazę danych i równoważenie obciążenia – w efekcie całą infrastrukturę niezbędną do zbudowania centrum danych w chmurze. W kontekście niniejszej recenzji interesuje nas kategoria Oracle Cloud Infrastructure Compute, ze szczególnym uwzględnieniem ich fizycznych instancji. Podobnie jak większość dostawców usług chmurowych, Oracle oferuje zwirtualizowane instancje obliczeniowe, ale w przeciwieństwie do większości innych ofert wirtualnych, może je wesprzeć konfiguracjami zawierającymi do ~25 TB pamięci masowej NVMe dla aplikacji wymagających niskich opóźnień. Mimo że są one doskonałe, Oracle jeszcze bardziej podniosło poprzeczkę w zakresie wydajności obliczeń w chmurze, oferując pierwsze w branży wysokowydajne fizyczne instancje, idealne dla aplikacji o znaczeniu krytycznym, w których opóźnienia mają kluczowe znaczenie. Instancje są wyposażone w maksymalnie 52 jednostki OCPU, 768 GB pamięci RAM, dwie karty sieciowe 25 GbE i do 51 TB lokalnie podłączonej pamięci masowej NVMe. Dla tych, którzy pragną więcej, dostępne są bloki pamięci masowej NVMe podłączone do sieci o pojemności do 512 TB oraz opcje GPU. Wszystkie rozwiązania obliczeniowe Oracle działają w oparciu o wysoce zoptymalizowaną, programowo zdefiniowaną sieć, dostrojoną pod kątem minimalizacji rywalizacji i maksymalizacji wydajności.
Obecnie istnieje szeroka gama ofert chmurowych, a nawet kilka dużych, z AWS, Google Cloud Platform i Microsoft Azure na czele listy. Chociaż ci dostawcy usług chmurowych oferują wiele świetnych produktów i usług, to zazwyczaj brakuje im wydajności. Porównując chmurę z rozwiązaniami lokalnymi, rozwiązania lokalne zawsze wygrywają z chmurą. Oracle dąży do zmiany tego poglądu dzięki swojej ofercie infrastruktury chmurowej.
Oferty obliczeniowe Oracle spełniają obietnice, jakich można oczekiwać od lokalnych pamięci masowych lub serwerów, w tym wydajność, dostępność, wszechstronność i zarządzanie. Strona wydajnościowa obsługuje szczytową i spójną wydajność dla aplikacji o znaczeniu krytycznym i jest wspierana przez niedawno ogłoszoną kompleksową umowę SLA dotyczącą infrastruktury chmurowej , która w momencie pisania tego tekstu jest jedyną taką w branży. Oferta obsługuje dostępność na wielu warstwach, w tym DNS, równoważenie obciążenia, replikację, tworzenie kopii zapasowych, migawki pamięci masowej i klastrowanie. Oferty obliczeniowe obejmują zakres od jednordzeniowej maszyny wirtualnej do 52-rdzeniowego, pojedynczego dzierżawcy, bare metal, oferując wszechstronność do uruchamiania wszystkiego, od typowych obciążeń po klastry HPC. A dzięki instancjom bare metal Oracle klienci uzyskują izolację i kontrolę serwera lokalnego, ponieważ nie zawierają one żadnych innych dzierżawców ani oprogramowania dostawcy Oracle.
Oferta obliczeniowa Oracle Cloud jest dostępna w kilku „kształtach”, w tym instancjach fizycznych, instancjach fizycznych GPU i instancjach maszyn wirtualnych. W tym przeglądzie przyjrzymy się instancjom fizycznym, które według Oracle mogą zapewnić do 5.1 miliona IOPS i są przeznaczone do zastosowań takich jak krytyczne aplikacje bazodanowe, obciążenia HPC i aplikacje internetowe intensywnie wykorzystujące wejście/wyjście. Dla porównania przedstawimy również kształty maszyn wirtualnych Oracle z lokalną pamięcią masową NVMe (DenseIO) i sieciową pamięcią masową blokową (Standard).
Zarząd
Interfejs graficzny do zarządzania infrastrukturą Oracle Cloud jest dość prosty w obsłudze. Strona główna zawiera instrukcje i pomoc, jeśli zajdzie taka potrzeba. Na górze znajdują się informacje o dzierżawie lub koncie, używany region (w naszym przypadku us-ashburn-1), a także zakładki: Strona główna (która jest stroną główną), Tożsamość, Obliczenia, Baza danych, Sieć, Pamięć masowa, Audyt i Poczta e-mail. W naszych testach pokazane są DenseIO2 i Standard2.
Ponieważ ta recenzja koncentruje się na stronie obliczeniowej, patrząc na tę zakładkę, możemy zobaczyć instancje, których użyjemy do naszych testów wydajności. Każda instancja ma swoją nazwę, kształt, region, domenę dostępności i datę utworzenia. Po lewej stronie użytkownicy mogą zmienić listę, wybierając stan, na przykład „uruchomiona”.
Kliknięcie wielokropka po prawej stronie pozwala na głębsze zapoznanie się z instancją. Patrząc na BM.DenseIO2.52, można łatwo sprawdzić, czy instancja jest uruchomiona i uzyskać bardziej szczegółowe informacje na jej temat. Można również powiązać ją z tagami. W górnej części informacji znajduje się opcja tworzenia obrazu niestandardowego, uruchamiania, zatrzymywania lub restartowania instancji, zamykania jej działania oraz dodawania tagów. Przewijanie w dół umożliwia również dołączanie woluminów blokowych.
Na karcie Sieć można zobaczyć używaną sieć wirtualną w chmurze lub ją utworzyć. W przypadku sieci VCN dostępne są takie informacje, jak region, domyślna tabela tras, domena DNS i data utworzenia. Wielokropek po prawej stronie umożliwia również przejście do szczegółów, zastosowanie tagów i utworzenie podsieci.
Na karcie „Magazyn” użytkownicy mogą przeglądać woluminy blokowe w swoich przedziałach i tworzyć kolejne. Woluminy blokowe są wyświetlane według daty utworzenia, a użytkownicy mogą przeglądać je, aby uzyskać więcej informacji, tworzyć ręczne kopie zapasowe, odłączać wolumin blokowy od instancji, usuwać wolumin lub stosować tagi.
Jak sugeruje Audit, można szybko przejrzeć przeszłe zdarzenia, wybierając zakres daty i godziny. Pozwala to przedsiębiorstwom spełnić wymogi zgodności z przepisami, rejestrując użytkownika i działanie dla każdego zdarzenia lub zmiany w środowisku.
Wydajność
Analiza obciążenia VDBench
Aby ocenić wydajność tych instancji Oracle Cloud, wykorzystaliśmy vdbench zainstalowany lokalnie na każdej platformie. Nasze testy obejmowały jednocześnie wszystkie lokalne pamięci masowe, więc jeśli obecne były zarówno BV (wolumin blokowy), jak i pamięć masowa NVMe, testowaliśmy po jednej grupie na raz. W przypadku obu typów pamięci masowej, przydzieliliśmy 12% zasobów każdemu urządzeniu i zgrupowaliśmy je razem, aby ocenić szczytową wydajność 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 pełnego klonu VDI i klonów powiązanych
Analizujemy zarówno zdalne urządzenia blokowe (BV), jak i NVMe. Ze względu na tak drastyczną 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). W tym przeglądzie analizujemy zarówno konfiguracje Bare Metal (BM), jak i maszyny wirtualne, zarówno ze standardowymi, jak i gęstymi przebiegami wejścia/wyjścia na BV oraz tylko gęstymi przebiegami wejścia/wyjścia dla NVMe.
Patrząc na szczytowy odczyt 4K dla BV, wszystkie cztery przebiegi rozpoczęły się od dużego opóźnienia poniżej milisekundy. Pierwszy, który odskoczył, był VM.Standard, osiągając nieco poniżej 53 tys. IOPS, a następnie osiągając szczyt na poziomie 60 591 IOPS z opóźnieniem 15 ms. Kolejnym, który przekroczył opóźnienie poniżej milisekundy, był VM.DenseIO, przekraczając 1 ms mniej więcej w tym samym miejscu co standard, ale osiągając szczyt na poziomie 72 626 IOPS z opóźnieniem 7.5 ms. Oba przebiegi bez obciążenia wypadły znacznie lepiej, a DenseIO osiągnął opóźnienie poniżej milisekundy aż do około 235 tys. IOPS, osiągając szczyt na poziomie 252 275 IOPS z opóźnieniem 4.1 ms. BM.Standard osiągnął około 250 tys. IOPS, po czym przekroczył 1 ms i osiągnął szczyt na poziomie 258 329 IOPS z opóźnieniem 4.05 ms.
Analizując szczytową wydajność odczytu 4K dla NVMe, oba przebiegi charakteryzowały się opóźnieniem poniżej milisekundy. VM.DenseIO osiągnął szczytową wydajność 569 534 IOPS z opóźnieniem 214 μs. BM.DenseIO osiągnął szczytową wydajność 4 419 490 IOPS z opóźnieniem zaledwie 174.6 μs.
Przechodząc do losowego zapisu 4K w szczytowej wydajności BV, widzimy podobne wyniki jak poprzednio, z maszynami wirtualnymi osiągającymi szczyt znacznie wcześniej niż maszyny BM. VM.Standard osiągnął około 63 tys. IOPS, zanim przekroczył opóźnienie poniżej milisekundy, i osiągnął szczyt na poziomie 77 229 IOPS przy opóźnieniu 5.3 ms. VM.DenseIO wypadł nieco lepiej, osiągając około 69 tys. IOPS, zanim przekroczył 1 ms, i osiągnął szczyt na poziomie 84 274 IOPS z opóźnieniem 3.9 ms. BM.DenseIO osiągnął ponad 263 tys. IOPS, zanim przekroczył opóźnienie 1 ms, i osiągnął szczyt na poziomie 280 158 IOPS z opóźnieniem 2.02 ms. Najwydajniejszą konfiguracją okazała się BM.Standard, która osiągnęła około 278 tys. IOPS, a opóźnienie spadło poniżej milisekundy. Osiągnęła szczyt na poziomie 280 844 IOPS przy opóźnieniu 1.84 ms.
Przy zapisie NVMe do 4K, BM ponownie przewyższył VM, osiągając opóźnienia poniżej milisekundy. VM.DenseIO osiągnął szczytową wartość 412 207 IOPS z opóźnieniem 141 μs. BM.DenseIO osiągnął szczytową wartość 3 232 215 IOPS z opóźnieniem 125 μs.
Przechodząc do pracy sekwencyjnej, najpierw przyjrzymy się odczytowi 64 KB dla BV. Zarówno VM.Standard, jak i VM.DenseIO przekroczyły opóźnienie 1 ms przy około 15.5 tys. IOPS, czyli 968 MB/s. Oba utrzymały mniej więcej tę samą wydajność, a opóźnienie wzrosło do 8.2 ms. Ponownie zaobserwowaliśmy podobną sytuację w przypadku BM.Standard i BM.DenseIO, oba przekraczające 1 ms przy około 37.5 tys. IOPS, czyli 2.35 GB/s. Obie konfiguracje osiągnęły szczyt nieco powyżej 47 tys. IOPS, czyli 2.95 GB/s, przy opóźnieniu 8.4 ms.
W przypadku sekwencyjnego odczytu 64 KB przez NVMe obie konfiguracje utrzymywały opóźnienie poniżej milisekundy. VM.DenseIO osiągnął szczytową wartość 39 512 IOPS (2.5 GB/s) przy opóźnieniu 403 μs, natomiast BM.DenseIO osiągnął szczytową wartość 323 879 IOPS (20.2 GB/s) przy opóźnieniu 361 μs.
W przypadku 64 tys. sekwencyjnych zapisów dla BV ponownie obserwujemy podobne zjawisko: VM.Standard i VM.DenseIO przekraczają opóźnienie 1 ms przy wydajności 12 tys. operacji wejścia/wyjścia na sekundę (IOPS), czyli 770 MB/s. Obie operacje osiągają szczyt około 15.1 tys. operacji wejścia/wyjścia na sekundę (IOPS), czyli 943 MB/s, przy opóźnieniu 3.1 ms. Zarówno BM.Standard, jak i BM.DenseIO przekraczają opóźnienie 1 ms przy około 42 tys. operacji wejścia/wyjścia na sekundę (IOPS), czyli 2.6 GB/s, przy czym BM.DenseIO osiąga szczyt 46 768 operacji wejścia/wyjścia na sekundę (IOPS), czyli 2.92 GB/s, przy opóźnieniu 2.6 ms. BM.Standard osiąga szczyt 46 787 operacji wejścia/wyjścia na sekundę (IOPS), czyli 2.92 GB/s, przy opóźnieniu 3.4 ms.
W przypadku sekwencyjnych zapisów 64 KB dla NVMe, zarówno VM.DenseIO, jak i BM.DenseIO ponownie charakteryzowały się opóźnieniem poniżej milisekundy, ale oba odnotowały również gwałtowny wzrost opóźnienia (w połączeniu z ostatecznym spadkiem wydajności BM.DenseIO). VM.DenseIO osiągnął szczytową wydajność 25 000 IOPS (1.56 GB/s) z opóźnieniem 311 μs po skoku do 754 μs. BM.DenseIO osiągnął znacznie lepszą wydajność szczytową (160 895 IOPS lub 10.1 GB/s przy opóźnieniu 170 μs), ale pod koniec nastąpił pewien spadek, a opóźnienie również wzrosło, osiągając 132 192 IOPS (8.8 GB/s) z opóźnieniem 310 μs.
W naszym obciążeniu SQL dla BV, VM.Standard jako pierwszy przekroczył 1 ms przy około 50 tys. operacji wejścia/wyjścia na sekundę (IOPS). Osiągnął szczyt na poziomie 73 259 IOPS z opóźnieniem 3.4 ms. VM.DenseIO przekroczyło opóźnienie 1 ms przy około 58 tys. operacji wejścia/wyjścia na sekundę (IOPS), osiągając szczyt na poziomie 78 624 IOPS z opóźnieniem 3.1 ms. W przypadku BM, oba utrzymywały opóźnienie poniżej 1 ms do około 275 tys. operacji (przy czym BM.DenseIO działał nieco dłużej). BM.Standard osiągnął szczyt na poziomie 305 368 IOPS z opóźnieniem 1.7 ms, a BM.DenseIO osiągnął szczyt na poziomie 307 979 IOPS z opóźnieniem 1.35 ms.
SQL dla NVMe ponownie charakteryzował się opóźnieniem poniżej milisekundy, a VM.DenseIO osiągnął szczyt na poziomie 188 786 IOPS i 167 μs. BM.DenseIO osiągnął szczyt na poziomie 1 684 869 IOPS i 142 μs.
W teście porównawczym SQL 90-10 dla BV, obie maszyny wirtualne osiągnęły opóźnienie poniżej milisekundy, osiągając około 58 tys. operacji wejścia/wyjścia na sekundę (IOPS). VM.Standard osiągnął szczyt na poziomie 71 691 operacji wejścia/wyjścia na sekundę (IOPS) z opóźnieniem 3.5 ms. VM.DenseIO osiągnął szczyt na poziomie 79 033 operacji wejścia/wyjścia na sekundę (IOPS) z opóźnieniem 3.05 ms. BM.Standard przekroczył opóźnienie 1 ms przy wydajności około 270 tys. operacji wejścia/wyjścia na sekundę (IOPS) i osiągnął szczyt na poziomie 303 904 operacji wejścia/wyjścia na sekundę (IOPS) z opóźnieniem 1.7 ms. BM.DenseIO osiągnął opóźnienie poniżej milisekundy do około 290 tys. operacji wejścia/wyjścia na sekundę (IOPS), osiągając szczyt na poziomie 307 472 operacji wejścia/wyjścia na sekundę (IOPS) z opóźnieniem 1.34 ms.
W przypadku NVMe SQL 90-10, VM.DenseIO osiągnął szczytową wartość 172 693 IOPS przy opóźnieniu 182 μs. BM.DenseIO osiągnął szczytową wartość 1 328 437 IOPS przy opóźnieniu 165 μs.
W teście porównawczym SQL 80-20 dla BV, VM.Standard osiągnął około 54 tys. operacji wejścia/wyjścia na sekundę (IOPS), po czym przekroczył 1 ms i osiągnął szczyt 72 204 operacji wejścia/wyjścia na sekundę (IOPS) z opóźnieniem 3.4 ms. VM.DenseIO miał opóźnienie poniżej milisekundy do około 59 tys. operacji wejścia/wyjścia na sekundę (IOPS), a szczyt osiągnął 78 787 operacji wejścia/wyjścia na sekundę (IOPS) z opóźnieniem 2.99 ms. BM.Standard osiągnął około 280 tys. operacji wejścia/wyjścia na sekundę (IOPS) z opóźnieniem poniżej 1 ms i osiągnął szczyt 300 014 operacji wejścia/wyjścia na sekundę (IOPS) z opóźnieniem 1.6 ms. BM.DenseIO przekroczyło opóźnienie 1 ms przy około 285 tys. operacji wejścia/wyjścia na sekundę (IOPS), osiągając szczyt 299 730 operacji wejścia/wyjścia na sekundę (IOPS) z opóźnieniem 1.3 ms, po czym nastąpił spadek wydajności.
W teście porównawczym SQL 80-20 dla NVMe, VM.DenseIO osiągnął szczytową wartość 144 010 IOPS z opóźnieniem 218 μs. BM.DenseIO osiągnął szczytową wartość 1 114 056 IOPS z opóźnieniem 182 μs, po czym nastąpił niewielki spadek wydajności.
W naszym obciążeniu Oracle z BV, VM.Standard miał opóźnienie poniżej milisekundy do momentu osiągnięcia około 52 tys. operacji wejścia/wyjścia na sekundę (IOPS), a szczytowe wyniki wyniosły 70 096 IOPS i wynosiły 3.4 ms. VM.DenseIO przekroczyło opóźnienie 1 ms przy około 58 tys. operacji wejścia/wyjścia na sekundę (IOPS), a szczytowe wyniki wyniosły 75 000 IOPS i wynosiły 3.1 ms. BM.Standard przekroczyło opóźnienie 1 ms przy około 255 tys. operacji wejścia/wyjścia na sekundę (IOPS), a szczytowe wyniki wyniosły 280 599 IOPS i wynosiły 1.41 ms. BM.DenseIO miał opóźnienie poniżej milisekundy do momentu osiągnięcia około 260 tys. operacji wejścia/wyjścia na sekundę (IOPS), a szczytowe wyniki wyniosły 267 632 IOPS i wynosiły 1.3 ms.
Nasze obciążenie Oracle z NVMe wykazało szczytową wydajność VM.DenseIO na poziomie 132 553 IOPS przy opóźnieniu 257 μs. Z BM.DenseIO szczytowa wydajność wyniosła 1 043 104 IOPS przy opóźnieniu 199 μs.
W systemie Oracle 90-10 dla BV, VM.Standard osiągał opóźnienie poniżej milisekundy, aż do nieco ponad 54 tys. operacji wejścia/wyjścia na sekundę (IOPS), osiągając szczyt na poziomie 72 533 IOPS przy opóźnieniu 2.2 ms. VM.DenseIO przekroczyło opóźnienie 1 ms przy około 61 tys. operacji wejścia/wyjścia na sekundę (IOPS), osiągając szczyt na poziomie 76 908 IOPS przy opóźnieniu 1.86 ms. Oba BM osiągnęły 297 tys. operacji wejścia/wyjścia na sekundę (IOPS), zanim przekroczyły opóźnienie 1 ms. BM.Standard osiągnął szczyt na poziomie 305 771 IOPS przy opóźnieniu 1.17 ms. BM.DenseIO osiągnął szczytową wydajność na poziomie 297 509 IOPS przy opóźnieniu 1.03 ms.
W systemie Oracle 90-10 dla NVMe, VM.DenseIO osiągnął szczytową wydajność 133 330 IOPS i opóźnienie 163 μs. BM.DenseIO osiągnął szczytową wydajność 1 088 454 IOPS i opóźnienie 142 μs.
W systemie Oracle 80-20 z funkcją BV, VM.Standard osiągnął około 55 tys. operacji w czasie krótszym niż 1 ms i osiągnął szczyt 74 032 operacji wejścia/wyjścia na sekundę (IOPS) z opóźnieniem 2.14 ms. VM.DenseIO miał opóźnienie poniżej milisekundy do około 51 tys. operacji i osiągnął szczyt 75 666 operacji wejścia/wyjścia na sekundę (IOPS) z opóźnieniem 2 ms. Oba BM osiągnęły około 295 tys. operacji wejścia/wyjścia na sekundę (IOPS), po czym nastąpił spadek o 1 ms. BM.Standard osiągnął szczyt 306 955 operacji wejścia/wyjścia na sekundę (IOPS) z opóźnieniem 1.14 ms. BM.DenseIO osiągnął szczyt około 295 tys. operacji wejścia/wyjścia na sekundę (IOPS) z opóźnieniem 893 μs.
W systemie Oracle 80-20 z interfejsem NVMe, VM.DenseIO osiągnął szczytową wartość 108 483 IOPS przy opóźnieniu 195 μs. BM.DenseIO osiągnął szczytową wartość 956 326 IOPS przy opóźnieniu 158 μs.
Następnie przyjrzeliśmy się pełnemu klonowi VDI. Podczas rozruchu z BV, VM.Standard przekroczył 1 ms, osiągając nieco poniżej 40 tys. IOPS, a szczytowy wynik wyniósł 56 057 IOPS z opóźnieniem 4.2 ms. VM.DenseIO osiągnął opóźnienie poniżej milisekundy, aż do około 43 tys. IOPS, a szczytowy wynik wyniósł 61 570 IOPS z opóźnieniem 3.6 ms. Oba BM miały opóźnienie poniżej milisekundy, aż do przekroczenia progu 200 tys. IOPS. Oba osiągnęły szczytowy wynik około 220 tys. IOPS z opóźnieniem 2.1, po czym nastąpił spadek wydajności.
W przypadku rozruchu Full Clone z NVMe, VM.DenseIO osiągnął szczytową wartość około 136 tys. operacji wejścia/wyjścia na sekundę (IOPS) z opóźnieniem 235 μs. BM.DenseIO osiągnął szczytową wartość 1 032 322 operacji wejścia/wyjścia na sekundę (IOPS) z opóźnieniem 213 μs.
Po pierwszym zalogowaniu się do VDI Full Clone z BV, obie maszyny wirtualne osiągnęły około 41 tys. IOPS z opóźnieniem poniżej milisekundy. VM.Standard osiągnęła szczyt 55 522 IOPS z opóźnieniem 3.7 ms, a VMDenseIO 59 560 IOPS z opóźnieniem 3.6 ms. Opóźnienie poniżej milisekundy dla obu maszyn BM osiągnęło około 203 tys. IOPS (przy czym wersja standardowa wyprzedziła gęstą). BM.Standard osiągnęła szczyt około 225 tys. IOPS z opóźnieniem 2.04 ms, a BM.DenseIO 224 385 IOPS z opóźnieniem 1.8 ms.
W przypadku pierwszego logowania do pełnego klonu VDI z NVMe, VM.Standard osiągnął szczytową wartość 59 883 IOPS z opóźnieniem 506 μs. Natomiast BM.DenseIO osiągnął szczytową wartość 467 761 IOPS z opóźnieniem 262 μs.
Poniedziałkowe logowanie do pełnego klonu VDI przy użyciu BV wykazało opóźnienie VM.Standard poniżej milisekundy aż do niemal 36 tys. operacji wejścia/wyjścia na sekundę (IOPS), ze szczytem 50 685 operacji wejścia/wyjścia na sekundę (IOPS) i opóźnieniem 2.3 ms. VM.DenseIO działało poniżej 1 ms aż do nieco ponad 38 tys. operacji wejścia/wyjścia na sekundę (IOPS), osiągając szczyt na poziomie 53 304 operacji wejścia/wyjścia na sekundę (IOPS) z opóźnieniem 2.2 ms. BM.Standard przekroczyło opóźnienie 1 ms przy około 205 tys. operacji wejścia/wyjścia na sekundę (IOPS) i osiągnęło szczyt na poziomie 224 764 operacji wejścia/wyjścia na sekundę (IOPS) z opóźnieniem 1.5 ms. BM.DenseIO przekroczyło 1 ms około 210 tys. operacji wejścia/wyjścia na sekundę (IOPS) ze szczytem nieco ponad 220 tys. operacji wejścia/wyjścia na sekundę (IOPS) i opóźnieniem 1.2 ms.
W teście VDI Full Clone Monday Login z użyciem NVMe szczytowa wydajność VM.DenseIO wyniosła 44 384 IOPS, a opóźnienie 356 μs. BM.DenseIO osiągnął szczytową wydajność 356 691 IOPS, a opóźnienie 252 μs.
Nasz ostatni wybór testów dotyczy VDI Linked Clone. Zaczynając ponownie od testu rozruchu z BV, VM.Standard miał opóźnienie poniżej milisekundy do około 29 tys. IOPS, osiągając szczyt około 38 tys. IOPS przy opóźnieniu 2.4 ms. VM.DenseIO osiągnął około 32 tys. IOPS, po czym przekroczył 1 ms i osiągnął szczyt około 38 tys. IOPS przy opóźnieniu 2.16 ms. Oba BM osiągnęły około 100 tys. IOPS, po czym przekroczyły opóźnienie 1 ms. Oba osiągnęły szczytową wydajność około 114 tys. IOPS przy opóźnieniu 3 ms.
W przypadku VDI Linked Clone Boot dla NVMe, VM.DenseIO osiągnął szczyt na poziomie 65 384 IOPS z opóźnieniem 238 μs. BM.DenseIO osiągnął szczyt na poziomie 555 004 IOPS z opóźnieniem 217 μs.
Po pierwszym zalogowaniu się do BV, obie maszyny wirtualne przekroczyły opóźnienie 1 ms przy około 28 tys. operacji wejścia/wyjścia na sekundę (IOPS). VM.Standard osiągnęła szczyt 36 682 operacji wejścia/wyjścia na sekundę (IOPS) z opóźnieniem 1.6 ms, a VM.DenseIO osiągnęła szczyt 38 525 operacji wejścia/wyjścia na sekundę (IOPS) z opóźnieniem 1.6 ms. Obie maszyny BM przekroczyły opóźnienie 1 ms przy około 132 tys. operacji wejścia/wyjścia na sekundę (IOPS). BM.Standard osiągnęła szczyt 140 848 operacji wejścia/wyjścia na sekundę (IOPS) z opóźnieniem 1.3 ms, a BM.DenseIO osiągnęła szczyt 139 883 operacji wejścia/wyjścia na sekundę (IOPS) z opóźnieniem 1.2 ms.
Pierwsze logowanie przy użyciu protokołu NVMe wykazało maksymalną wydajność na poziomie 24 228 IOPS i 326 μs dla VM.DenseIO oraz 242 778 IOPS i 234 μs dla BM.DenseIO.
Wreszcie, dzięki VDI Linked Clone Monday Login z BV, VM.Standard osiągnął opóźnienie poniżej milisekundy do około 27 tys. IOPS, ze szczytem 39 874 IOPS i opóźnieniem 2.86 ms. VM.DenseIO przekroczyło 1 ms przy około 25 tys. IOPS i osiągnęło szczyt 42 469 IOPS z opóźnieniem 3 ms. Oba BM miały opóźnienie poniżej milisekundy do około 135 tys. IOPS, osiągając szczyt 146 tys. IOPS, przy czym denseIO miał opóźnienie 1.6 ms, a standard 1.76 ms.
W przypadku logowania VDI Linked Clone Monday z użyciem NVMe, VM.DenseIO osiągnęło szczyt na poziomie 34 016 IOPS i opóźnienie 464 μs. BM.DenseIO osiągnęło szczyt na poziomie 260 527 IOPS i opóźnienie 317 μs.
Wniosek
Infrastruktura chmurowa Oracle rozwiązuje jeden z głównych problemów chmury – wydajność, a raczej jej brak – i rozwiązuje go dzięki instancjom fizycznym (bare metal). Oracle oferuje instancje obliczeniowe fizyczne i wirtualne, a także wersje NVMe z pamięcią masową NVMe do 25 TB, co zapewnia wydajność niespotykaną dotąd w chmurze. Aby osiągnąć deklarowaną przez Oracle wydajność do 5.1 miliona IOPS, potrzeba czegoś więcej niż pamięci masowej NVMe; instancje oferują również do 52 jednostek OCPU, 768 GB pamięci RAM, dwie karty sieciowe 25 GbE i do 51 TB lokalnie podłączonej pamięci masowej NVMe. Ten poziom wydajności jest wykorzystywany głównie w takich zastosowaniach, jak krytyczne dla misji aplikacje bazodanowe, obciążenia HPC i aplikacje internetowe intensywnie wykorzystujące wejście/wyjście.
Jeśli chodzi o wydajność, przeprowadziliśmy testy VDBech zarówno dla konfiguracji bare metal (BM), jak i maszyn wirtualnych, wykorzystując lokalną pamięć masową NVMe (DenseIO), jak i blokową pamięć masową sieciową (Standard). Wydajność, mówiąc wprost, powaliła nas na kolana. Dla każdego testu uruchomiliśmy dwa zestawy wykresów, ponieważ różnica w opóźnieniach między DenseIO a Standard była tak duża, że wykresy byłyby trudne do odczytania, gdyby wszystkie znajdowały się na jednym zestawie. Jeśli chodzi o wydajność pamięci masowej na tych instancjach w porównaniu z tradycyjnymi, dorównują one wielu najlepszym opcjom pamięci masowej współdzielonej na rynku, nie mówiąc już o alternatywach w chmurze. Podłączone woluminy BV, hostowane przez iSCSI i objęte kopią zapasową, oferują solidne połączenie przepustowości i szerokości pasma przy niskich opóźnieniach. Dla porównania, wiele testów z 32 woluminami BV podłączonymi do 52 instancji OCPU przewyższało wydajność macierzy pamięci masowej all-flash testowanych w naszym laboratorium. Niektóre z nich mogłyby działać odrobinę szybciej, co jest całkiem imponujące, biorąc pod uwagę, że porównujemy instancję w chmurze z instancją AFA wartą ponad 250 tys. dolarów, przełączaniem FC i wieloma hostami obliczeniowymi.
To, co czyni instancje Oracle Cloud bare metal naprawdę niesamowitymi, to lokalnie podłączona pamięć masowa NVMe. DenseIO2.8 miał 1 urządzenie, podczas gdy DenseIO2.52 miało ich 8, co zapewniało tym instancjom wydajność mierzoną w milionach IOPS. Instancja z 1 dyskiem SSD NVMe osiągnęła maksymalną prędkość losowego odczytu 4K na poziomie 569 tys. IOPS, podczas gdy instancja z 8 dyskami osiągnęła wydajność 4.4 mln IOPS. Przepustowość również nie była bez zarzutu; mniejsza instancja osiągnęła szczyt odczytu 2.5 GB/s, a większa ponad 20 GB/s. Pamiętaj o przygotowaniu planu awaryjnego, ponieważ w końcu kształty NVMe to lokalnie podłączona pamięć masowa, którą należy chronić.
Oracle zbudowało serwery i pamięci masowe o najwyższej specyfikacji w chmurze; jedyną rzeczą, która może konkurować z ich instancjami bare metal, jest zbudowanie serwera o najwyższej specyfikacji hostowanego lokalnie wraz ze wszystkimi innymi komponentami i usługami, które go obsługują. Podobnie jak w przypadku wszystkich rozwiązań chmurowych, Oracle oferuje płynność włączania i wyłączania instancji oraz elastyczność dostosowywania wymagań dotyczących pamięci masowej w razie potrzeby. W przypadku tych instancji oczywistym problemem, który się pojawi, są koszty. Szybkość uruchomienia instancji w ramach Oracle Cloud w porównaniu z wysiłkiem i kosztami wymaganymi do skonfigurowania porównywalnego sprzętu we własnym centrum danych, jest prawdopodobnie kluczowym czynnikiem decydującym. Chociaż pamięć masowa z interfejsem NVMe jest droga, nie sposób zaprzeczyć korzyściom w zakresie wydajności, które zaobserwowaliśmy. Jeśli prowadzisz firmę, na którą wpływa czas przetwarzania dużych zbiorów danych, nie ma prostszego ani szybszego rozwiązania, aby ukończyć obciążenia, takie jak analityka, niż zastosowane przez nas konfiguracje oparte na technologii NVMe. I nie chodzi o to, że standardowe konfiguracje z dołączonymi blokami były złe – konfiguracje NVMe były po prostu tak nierealne, że przyćmiewały resztę. Podsumowując, firmy o przyszłościowym podejściu, które mogą czerpać wymierne korzyści z wydajnej chmury, zdecydowanie powinny rozważyć ofertę Oracle. Przechodząc do chmury, istnieje wiele możliwości, ale nic nie jest tak szybkie, jak to, co widzieliśmy w przypadku instancji bare metal Oracle Cloud. Rozwiązania te są zdecydowanym i zasłużonym zwycięzcą naszej pierwszej nagrody Editor's Choice Award przyznawanej dostawcy usług chmurowych.
Amazon