Mniej więcej o tej porze w zeszłym roku firma NetApp wprowadziła kilka nowych rozwiązań do swojej oferty rozwiązań do analityki Big Data. Wśród nich znalazła się najnowsza macierz all-flash (AFA) firmy NetApp – EF570. EF570 to macierz AFA klasy średniej, zaprojektowana z myślą o wysokiej wydajności, dostępności, prostocie i korzystnym stosunku ceny do wydajności w systemie 2U.
Firma NetApp twierdzi, że macierz EF570 charakteryzuje się „ekstremalną” wydajnością i choć nie przesadzamy, firma podaje imponujące liczby. NetApp twierdzi, że macierz może osiągnąć ponad milion operacji wejścia/wyjścia na sekundę (IOPS) i przepustowość sekwencyjną 21 GB/s, a wszystko to przy opóźnieniu poniżej 100 mikrosekund. Cała ta wydajność jest przeznaczona specjalnie do środowisk o mieszanym obciążeniu, w tym do analizy dużych zbiorów danych (Big Data). Oprócz obiecanej wydajności, macierz obsługuje kilka szybkich interfejsów hosta, w tym 32 Gb Fibre Channel, 25 Gb iSCSI, 100 Gb InfiniBand, 12 Gb SAS i 100 Gb NVMe przez InfiniBand. To nie tylko pomoże osiągnąć deklarowane prędkości, ale także pomoże chronić przyszłe inwestycje w sieci pamięci masowej.
Podobnie jak w przypadku wielu innych systemów NetApp, wysoka dostępność jest wbudowana; w tym przypadku EF570 nie stanowi wyjątku. Macierz nie posiada pojedynczego punktu awarii (SPI) i jest wyposażona w w pełni redundantne ścieżki wejścia/wyjścia oraz automatyczne przełączanie awaryjne. Charakteryzuje się również dostępnością rzędu sześciu dziewiątek. Dzięki tym funkcjom EF570 oferuje również standardowe funkcje zarządzania danymi, takie jak migawki, kopiowanie woluminów i tworzenie kopii lustrzanych. System operacyjny SANtricity OS zapewnia integralność danych, chroniąc je jednocześnie przed ukrytym uszkodzeniem. Macierz jest w stanie wykrywać i rozwiązywać większość problemów dzięki monitorowaniu w tle oraz rozbudowanym danym diagnostycznym i analizie.
NetApp EF570 ma modułową konstrukcję i jest łatwy w skalowaniu. System 2U może obsłużyć do 367 TB pojemności, a dodanie czterech półek rozszerzeń może zwiększyć całkowitą pojemność do 1.8 PB. Dzięki graficznemu interfejsowi użytkownika SANtricity użytkownicy mogą skalować system bez dodatkowych komplikacji związanych z zarządzaniem i uzyskać dostęp do danych w mniej niż 10 minut. Ta łatwość skalowania i wysoka pojemność zapewniają macierz EF570 korzystny stosunek ceny do wydajności. Możliwość skalowania do 1.8 PB sprawia również, że macierz jest atrakcyjnym wyborem, który może pomóc uniknąć modernizacji za pomocą wózków widłowych w przyszłości.
Specyfikacje NetApp EF570
| Budowa | 2U |
| Maksymalna pamięć systemowa | 128GB |
| Maksymalna liczba napędów (z rozszerzeniem) | 120 |
| Maksymalna pojemność | 1.8PB |
| Obsługiwane typy napędów | Dysk SSD 2.5” 800 GB, 1.6 TB, 3.2 TB, 15.3 TB, 1.6 TB Szyfrowanie FIPS |
| Porty wejścia/wyjścia hosta | |
| Porty bazowe |
|
| Opcjonalne porty dodatkowe |
|
| System operacyjny i zarządzanie | Menedżer systemu SANtricity w wersji 11.40 lub nowszej |
| Wydajność | |
| IOPS | Do 1M |
| Utrzymana przepustowość | Do 21 GB/s |
| Średnie opóźnienie |
|
| Fizyczny | |
| Wymiary (WxSxG) | 3.47 x 19 x 19.27 cali (8.81 x 48.26 x 48.95 cm) |
| Waga | 51.63lb (23.42kg) |
| Zasilanie i chłodzenie | |
| kVA |
|
| Watts |
|
| BTU |
|
Zaprojektuj i zbuduj
Jak wspomniano, EF570 to obudowa AFA o wysokości 2U. Podobnie jak w przypadku zdecydowanej większości produktów NetApp (przynajmniej tych nowszych), ramki wyglądają podobnie – stylowa, metalowa obudowa, wentylacja i logo NetApp po lewej stronie. Pod ramką znajdują się dwadzieścia cztery wnęki na dyski 2.5 cala, biegnące pionowo przez przód macierzy. Po prawej stronie macierzy znajduje się logo NetApp, a po lewej przyciski Power, Attention i Locate oraz diody LED.
Patrząc na tył urządzenia, wyraźnie widać konstrukcję o wysokiej dostępności i redundancji. Macierz jest lustrzanym odbiciem od lewej do prawej. Dolna część jest wypełniona zasilaczami. Górna połowa zawiera dwa kontrolery. Kontrolery zostały skonfigurowane z czteroportowymi kartami HIC (Host Interface Cards) 32 Gb/s, wykorzystującymi dwa układy ASIC na kontroler. Wbudowane porty FC nie były wykorzystywane, co zapewniłoby jedną dodatkową ścieżkę ASIC na kontroler. Do naszych testów zastosowaliśmy układ zgodny z najlepszymi praktykami, obejmujący dwa przełączniki 32 Gb/s.
Zarząd
W naszych poprzednich recenzjach produktów NetApp przyjrzeliśmy się systemowi operacyjnemu ONTAP tej firmy. Chociaż ONTAP jest bardziej popularnym i znanym systemem operacyjnym, seria EF działa na systemie operacyjnym SANtricity.
Ekran główny SANtricity zapewnia administratorom wgląd w układ całego systemu. Można łatwo sprawdzić wydajność (rozbitą na IOPS, MB/s i procesor lub w różnych przedziałach czasowych), pojemność, a także hierarchię pamięci masowej. Po lewej stronie ekranu znajdują się zakładki: Ekran główny, Pamięć masowa, Sprzęt, Ustawienia i Pomoc techniczna.
Na karcie głównej Pamięć masowa dostępnych jest kilka opcji do wyboru, umożliwiających szczegółowe informacje na temat działania pamięci masowej, w tym: Pule i grupy woluminów, Woluminy, Hosty, Wydajność, Migawki, Asynchroniczne kopiowanie lustrzane i Synchroniczne kopiowanie lustrzane.
Klikając „Pule i grupy woluminów”, możemy wyświetlić całą pojemność lub pojemność zarezerwowaną. W tym miejscu użytkownicy mogą tworzyć nowe pule lub grupy woluminów, dodawać do nich pojemność lub je edytować.
W obszarze Woluminy użytkownicy mogą tworzyć lub edytować woluminy, a także uzyskiwać informacje o bieżących woluminach, takie jak nazwa, status, czy włączone jest cienkie provisionowanie, gdzie są przypisane, ile jednostek LUN, do której puli lub grupy woluminów należą, a także pojemność.
Wydajność to temat, który zawsze nas interesuje, a administratorzy, którzy chcą wiedzieć, jak dobrze działa ich pamięć masowa, mogą to sprawdzić w sekcji „Wydajność” w obszarze „Magazyn”. Użytkownicy mają tam kilka różnych widoków wydajności opartych na określonych metrykach, które można przeglądać w widoku logicznym, fizycznym lub widoku aplikacji i obciążeń. Dostępna jest również opcja przejścia z całego AFA do pul i grup woluminów lub tylko do woluminów.
Przechodząc do szczegółów wydajności fizycznej, można sprawdzić wydajność kontrolerów, kanałów i dysków.
Karta Sprzęt, jak można się spodziewać, pokazuje sprzęt i jego działanie. Na przedniej stronie użytkownicy mogą sprawdzić dyski, aby sprawdzić, czy wszystko działa prawidłowo i czy coś wymaga wymiany (oznaczone kolorem, niebieski oznacza stan normalny).
Tylna część sprzętu wygląda podobnie, ale tym razem kontrolery i zasilacze są oznaczone kolorami, aby mieć pewność, że działają prawidłowo, lub wymagają interwencji.
Karta Ustawienia wyświetla ogólne informacje o systemie i ustawieniach iSCSI lub innych ustawieniach, które użytkownicy chcieliby dodać. Na tej karcie znajdują się również różne opcje konfiguracji.
Wydajność
Analiza obciążenia aplikacji
Testy obciążeniowe aplikacji dla NetApp EF570 obejmują wydajność MySQL OLTP w SysBench oraz wydajność Microsoft SQL Server OLTP z symulowanym obciążeniem TPC-C. W każdym scenariuszu macierz skonfigurowaliśmy z 26 dyskami SSD Toshiba PX04SV SAS 3.0, tworząc dwie 12-dyskowe grupy dysków RAID10, po jednym przypiętym do każdego kontrolera. W ten sposób pozostały 2 dyski SSD jako zapasowe. Następnie utworzono dwa woluminy o pojemności 5 TB, po jednym na grupę dysków. W naszym środowisku testowym zapewniło to zrównoważone obciążenie dla obciążeń SQL i Sysbench.
Wydajność serwera SQL
Każda maszyna wirtualna SQL Server jest skonfigurowana z dwoma dyskami wirtualnymi: woluminem 100 GB na rozruch i woluminem 500 GB na bazę danych i pliki dziennika. Z perspektywy zasobów systemowych, skonfigurowaliśmy każdą maszynę wirtualną z 16 procesorami wirtualnymi, 64 GB pamięci DRAM i wykorzystaliśmy kontroler LSI Logic SAS SCSI. Podczas gdy nasze obciążenia Sysbench testowane wcześniej obciążały platformę zarówno pod względem operacji wejścia/wyjścia, jak i pojemności pamięci masowej, test SQL sprawdza wydajność pod kątem opóźnień.
W tym teście wykorzystano SQL Server 2014 działający na gościnnych maszynach wirtualnych z systemem Windows Server 2012 R2 i został on obciążony programem Quest Benchmark Factory for Databases. Podczas gdy tradycyjnie testowaliśmy ten test w dużych bazach danych o skali 3,000 w pamięci lokalnej lub współdzielonej, w tej iteracji skupiamy się na równomiernym rozłożeniu czterech baz danych o skali 1,500 na kontrolerze NetApp EF570 (dwie maszyny wirtualne na kontroler).
Konfiguracja testowania serwera SQL Server (na maszynę wirtualną)
- Windows Server 2012 R2
- Zajętość pamięci masowej: 600 GB przydzielonych, 500 GB wykorzystanych
- SQL Server 2014
- Rozmiar bazy danych: skala 1,500
- Obciążenie wirtualnego klienta: 15 000
- Bufor RAM: 48 GB
- Długość testu: 3 godziny
- 2.5 godziny przygotowania wstępnego
- 30-minutowy okres próbny
Sprzęt do generowania obciążenia fabrycznego SQL Server OLTP Benchmark
- Dell EMC PowerEdge R740xd Wirtualizowany klaster SQL 4-węzłowy
- 8 procesorów Intel Xeon Gold 6130 o taktowaniu 269 GHz w klastrze (dwa na węzeł, 2.1 GHz, 16 rdzeni, pamięć podręczna 22 MB)
- 1 TB pamięci RAM (256 GB na węzeł, 16 GB x 16 DDR4, 128 GB na procesor)
- 4 x Emulex 16 GB dwuportowa karta HBA FC
- 4 x dwuportowa karta sieciowa Mellanox ConnectX-4 rNDC 25GbE
- VMware ESXi vSphere 6.5 / Enterprise Plus 8-CPU
W przypadku serwera SQL Server platforma NetApp EF570 działała szybko i spójnie, osiągając 3,160 transakcji na sekundę (TPS) i zmianę na wszystkich czterech maszynach wirtualnych, co dało łączną wartość 12 642,245 transakcji na sekundę (TPS).
Analizując opóźnienia, wszystkie maszyny wirtualne charakteryzowały się stałym czasem reakcji wynoszącym 3 ms.
Wydajność Sysbench
Każda maszyna wirtualna Sysbench jest skonfigurowana z trzema dyskami wirtualnymi: jednym do rozruchu (~92 GB), jednym z predefiniowaną bazą danych (~447 GB) i trzecim dla testowanej bazy danych (270 GB). Z perspektywy zasobów systemowych, każdą maszynę wirtualną skonfigurowaliśmy z 16 procesorami wirtualnymi, 60 GB pamięci DRAM i wykorzystaliśmy kontroler LSI Logic SAS SCSI. Systemami generacji obciążenia są serwery Dell R740xd.
Klaster MySQL 4-węzłowy z wirtualizacją Dell PowerEdge R740xd
- 8 procesorów Intel Xeon Gold 6130 o taktowaniu 269 GHz w klastrze (dwa na węzeł, 2.1 GHz, 16 rdzeni, pamięć podręczna 22 MB)
- 1 TB pamięci RAM (256 GB na węzeł, 16 GB x 16 DDR4, 128 GB na procesor)
- 4 x Emulex 16 GB dwuportowa karta HBA FC
- 4 x dwuportowa karta sieciowa Mellanox ConnectX-4 rNDC 25GbE
- VMware ESXi vSphere 6.5 / Enterprise Plus 8-CPU
Konfiguracja testów Sysbench (na maszynę wirtualną)
- CentOS 6.3 64-bit
- Zajęta przestrzeń dyskowa: 1 TB, wykorzystane 800 GB
- Percona XtraDB 5.5.30-rel30.1
- Tabele bazy danych: 100
- Rozmiar bazy danych: 10 000 000
- Wątki bazy danych: 32
- Bufor RAM: 24 GB
- Długość testu: 3 godziny
- 2 godziny wstępnego kondycjonowania 32 wątków
- 1 godzina 32 wątki
W ramach Sysbencha przetestowaliśmy kilka zestawów maszyn wirtualnych, w tym 8, 16 i 32 maszyny wirtualne. Celem tych testów jest pokazanie, jak dobrze dana macierz radzi sobie pod obciążeniem od umiarkowanego do pełnego nasycenia. Nie wszystkie recenzje powalają nas na kolana, jeśli chodzi o wyniki wydajności, ale NetApp EF570 właśnie to zrobił. Przy obciążeniu 8 maszyn wirtualnych, EF570 zmierzył 22 951 TPS, przewyższając większość macierzy w szczytowym momencie. Przy obciążeniu do 16 maszyn wirtualnych, EF570 nie wykazywał oznak spowolnienia, osiągając niewiarygodne 39 635 TPS. Jednak przy 32 maszynach wirtualnych EF570 był po prostu potworem, osiągając szczytowe 57 347 TPS, i zatrzymał się nie z powodu braku wejścia/wyjścia, ale całkowicie nasycając procesory w naszych 8 hostach. Powiedzenie, że EF570 jest szybki, to mało powiedziane; to potwór.
Analizując średnie opóźnienie dla naszych obciążeń 8, 16 i 32 maszyn wirtualnych, NetApp EF570 nadal robił na nas wrażenie. Przy obciążeniu 8 maszyn wirtualnych zmierzył zaledwie 11.15 ms, wzrastając wraz ze wzrostem obciążenia do 16 maszyn wirtualnych do zaledwie 12.98 ms. Przy obciążeniu 32 maszyn wirtualnych, gdzie większość macierzy zaczyna tracić moc, EF570 osiągnął zaledwie 17.98 ms.
Patrząc na 99. percentyl opóźnienia, NetApp EF570 zaczął się ujawniać. Nie tylko był w stanie utrzymać wysoką przepustowość, ale robił to przy bardzo niskich opóźnieniach szczytowych. To pokazuje, że nawet gdy ta macierz przeciąża wejścia/wyjścia, robi to w przewidywalny i spójny sposób.
Analiza obciążenia VDBench
W przypadku testów porównawczych macierzy pamięci masowej, testy aplikacji są najlepsze, a testy syntetyczne plasują się na drugim miejscu. Chociaż nie odzwierciedlają one idealnie rzeczywistych obciążeń, testy syntetyczne pomagają w ustaleniu punktu odniesienia dla urządzeń pamięci masowej, zapewniając powtarzalność, która ułatwia porównywanie konkurencyjnych rozwiązań. Obciążenia te oferują szereg różnych profili testowych, od testów „czterech kątów”, przez testy rozmiaru transferu baz danych, po przechwytywanie śladów z różnych środowisk VDI. Wszystkie te testy wykorzystują 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 dla szerokiej gamy urządzeń pamięci masowej, w tym macierzy flash i pojedynczych urządzeń pamięci masowej. Po stronie macierzy wykorzystujemy klaster serwerów Dell PowerEdge R740xd:
Profile:
- Losowy odczyt 4K: 100% odczytu, 128 wątków, 0-120% ioratu
- 4K losowy zapis: 100% zapisu, 64 wątki, 0-120% ioracji
- 64K Sekwencyjny odczyt: 100% odczytu, 16 wątków, 0-120% ioracji
- 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
W przypadku szczytowej wydajności odczytu 4K, EF570 rozpoczął od opóźnienia poniżej milisekundy, po czym na krótko wzrósł do ponad 1 ms przy około 510 tys. IOPS, a następnie spadł poniżej 1 ms, osiągając prawie milion IOPS. Macierz osiągnęła szczyt na poziomie około 1.03 miliona IOPS i opóźnienia 2 ms, po czym nieco spadła.
W przypadku losowego zapisu 4K, EF570 osiągnął nieco ponad 200 tys. IOPS, zanim przekroczył 1 ms. EF570 osiągnął szczyt na poziomie około 223 tys. IOPS z opóźnieniem 4 ms, po czym nastąpił niewielki spadek.
Po przełączeniu na sekwencyjne obciążenia 64 tys. operacji, EF570 osiągnął opóźnienie poniżej milisekundy do około 190 tys. operacji wejścia/wyjścia na sekundę (IOPS) lub 12 GB/s, a następnie osiągnął szczyt na poziomie 247 692 operacji wejścia/wyjścia na sekundę (IOPS) lub 15.5 GB/s przy opóźnieniu 2.1 ms.
W przypadku zapisu 64 KB, AFA charakteryzował się opóźnieniem poniżej milisekundy aż do osiągnięcia wartości 80 000 IOPS (5 GB/s). Macierz osiągnęła szczyt na poziomie 80 675 IOPS, czyli 5.04 GB/s, przy opóźnieniu 3.2 ms.
Przechodząc do naszych obciążeń SQL, EF570 osiągnął szczytową wydajność na poziomie 1 029 910 IOPS przy opóźnieniu 818 μs.
W przypadku SQL90-10 macierz osiągnęła szczyt na poziomie 876 833 IOPS przy opóźnieniu 957 μs.
SQL 80-20 był pierwszym testem SQL, który przekroczył 1 ms w pobliżu szczytu, przy szczytowej wydajności wynoszącej 740 691 IOPS i opóźnieniu 1.2 ms.
Następnie zajęliśmy się obciążeniami Oracle. Ponownie, EF570 przekroczył 1 ms w pobliżu szczytu, osiągając maksymalną wydajność 721 615 IOPS i opóźnienie 1.35 ms.
Oracle 90-10 osiągnął opóźnienia poniżej milisekundy, ze szczytowym wynikiem 875 567 IOPS i opóźnieniem 675 μs.
Oracle 80-20 utrzymał wydajność opóźnienia poniżej milisekundy, uzyskując szczytowy wynik 738 238 IOPS i opóźnienie 808 μs.
Następnie przeszliśmy do testu klonowania VDI, pełnego i połączonego. W przypadku rozruchu pełnego klonowania VDI, EF570 osiągnął około 835 tys. IOPS w czasie poniżej 1 ms, a następnie osiągnął szczyt na poziomie 841 945 IOPS z opóźnieniem 1.2 ms.
Po początkowym zalogowaniu VDI FC, EF570 osiągnął 250 tys. IOPS, zanim przekroczył 1 ms. Następnie osiągnął szczyt na poziomie 262 141 IOPS z opóźnieniem 3.3 ms.
W przypadku logowania VDI FC Monday, EF570 miał opóźnienie mniejsze niż milisekunda do około 300 tys. operacji wejścia/wyjścia na sekundę (IOPS), osiągając szczyt na poziomie 331 146 operacji wejścia/wyjścia na sekundę (IOPS) przy opóźnieniu 1.5 ms.
W przypadku VDI LC Boot układ EF570 osiągnął opóźnienie mniejsze od milisekundy, osiągając wynik szczytowy 519 975 IOPS i opóźnienie 980 μs.
Podczas początkowego logowania do VDI LC opóźnienie po raz kolejny pozostało poniżej 1 ms, przy maksymalnym wyniku 269 995 IOPS i opóźnieniu 944 μs.
W przypadku logowania VDI LC Monday układ EF570 był w stanie utrzymać opóźnienie poniżej 1 ms aż do osiągnięcia około 270 tys. operacji wejścia/wyjścia na sekundę (IOPS), a wartość szczytowa wyniosła 299 663 IOPS, a opóźnienie wyniosło 1.7 ms.
Wniosek
NetApp EF570 to macierz all-flash o wysokości 2U, przeznaczona dla systemów klasy średniej. Modułowa konstrukcja EF570 zapewnia wysoką dostępność i łatwą skalowalność. Bardzo interesującym aspektem macierzy jest jej wydajność. NetApp deklaruje, że EF570 może osiągnąć do miliona operacji wejścia/wyjścia na sekundę (IOPS) i przepustowość sekwencyjną do 21 GB/s. Firma dodaje, że wszystkie te parametry można uzyskać w czasie krótszym niż 100 μs. Ta wysoka wydajność, w połączeniu z wysoką dostępnością oraz prostotą zarządzania i skalowania, czyni ją atrakcyjną opcją pod względem stosunku ceny do wydajności.
Patrząc na wydajność aplikacji, NetApp EF570 wahał się od doskonałej wydajności do ustanowienia nowych rekordów w naszym laboratorium. Wydajność SQL Server pokazała, że EF570 był w stanie zapewnić bardzo ścisłą i spójną wydajność, mierząc 3 ms na naszych czterech maszynach wirtualnych SQL, zgodnie z pomiarami Benchmark Factory. W naszym skalowanym teście Sysbench, EF570 uzyskał tak wysoki wynik, że nasyciliśmy nasz klaster obliczeniowy, zanim macierz wyczerpała dostępne wejścia/wyjścia. Przy 8 maszynach wirtualnych zmierzyliśmy 22.9 tys. TPS, czyli mniej więcej tyle, ile większość testowanych przez nas macierzy flash zaczyna wyczerpywać. Przy 16 maszynach wirtualnych EF570 osiągnął 39.6 tys. TPS, bijąc poprzedni rekord w naszym teście Sysbench zmierzony na macierzy flash RAID0 NVMe-oF. Przy 32 maszynach wirtualnych osiągnęliśmy szczyt naszego testowego klastra z rekordowym wynikiem 57.3 tys. TPS. We wszystkich tych przypadkach średnie i 99. percentylowe opóźnienie były niskie i płynne jak masło. Nie trzeba dodawać, że byliśmy pod wrażeniem.
W naszych wynikach VDBench, macierz EF570 wypadła bardzo dobrze, przekraczając milion IOPS w kilku testach porównawczych, w tym w odczycie 4K (1.03 miliona z opóźnieniem zaledwie 2 ms) i SQL (1 029 910 IOPS z opóźnieniem zaledwie 818 μs). W testach sekwencyjnych, EF570 osiągnął 15.5 GB/s przy odczycie i 5.04 GB/s przy opóźnieniu odpowiednio 2.1 ms i 3.2 ms. Macierz odnotowała również kilka innych, wartych uwagi wyników pod względem wysokiej wydajności i niskich opóźnień. W SQL 90-10 osiągnięto 877 tys. IOPS (957 μs), w SQL 80-20 osiągnięto 741 tys. IOPS (1.2 ms), w Oracle odnotowaliśmy 722 tys. IOPS (1.35 ms), w Oracle 90-10 zarejestrowaliśmy 876 tys. IOPS (675 μs), w Oracle 80-20 odnotowaliśmy 738 tys. IOPS (808 μs), w przypadku VDI FC Boot odnotowaliśmy 842 tys. IOPS (1.2 ms), a w przypadku VDI LC Boot odnotowaliśmy 520 tys. IOPS (980 μs).
NetApp kieruje EF570 do rynku średniego, ale wynika to głównie ze skalowalności. Zazwyczaj, gdy myślimy o rynku średnim, termin ten przywodzi na myśl wizję ceny i wydajności, która jest „wystarczająco dobra”, aby wykonać zadanie. Powiedzmy sobie jasno: EF570 może mieć cenę ze średniej półki, ale oferuje profil wydajności klasy korporacyjnej, który przewyższa wszystko, co widzieliśmy w laboratorium. Co więcej, w niektórych testach (32VM Sysbench) osiągnęliśmy szczyt naszego klastra obliczeniowego, co oznacza, że prawdopodobnie istnieje jeszcze większa wydajność. W przypadku wymagających obciążeń pamięci blokowej, takich jak analityka i nowe zastosowania w stylu sztucznej inteligencji, gdzie opóźnienia i dostępność oznaczają koszty, ważne jest posiadanie narzędzia do przechowywania danych zaprojektowanego do tego zadania. NetApp EF570 to idealne rozwiązanie dla tych obciążeń, które z impetem poddaje te wymagające bazy danych, dostarczając inteligencję w najszybszy sposób, jaki widzieliśmy do tej pory.
Zapisz się do newslettera StorageReview
Amazon