StorageReview.com

Recenzja VMware Virtual SAN: wydajność Sysbench OLTP

Enterprise   ◇  Hiperkonwergentny

Aby zmierzyć wydajność klastra VMware VSAN w obciążeniach transakcyjnych baz danych, najpierw wykorzystaliśmy test porównawczy Sysbench OLTP, zwracając szczególną uwagę na całkowitą wydajność łączną. Test porównawczy Sysbench OLTP działa na bazie danych Percona MySQL z wykorzystaniem silnika pamięci masowej InnoDB działającego w ramach instalacji CentOS. Podczas gdy tradycyjna infrastruktura SAN lepiej radzi sobie z dużymi, pojedynczymi obciążeniami, systemy hiperkonwergentne są zaprojektowane tak, aby rozłożyć to obciążenie na wszystkie węzły w systemie. W tym celu wdrożyliśmy cztery maszyny wirtualne Sysbench w klastrze VSAN, po jednej na węzeł, i zmierzyliśmy całkowitą wydajność klastra, działając jednocześnie.

Specyfikacje Dell PowerEdge R730xd VMware VSAN

  • Serwery Dell PowerEdge R730xd (x4)
  • Procesory: osiem Intel Xeon E5-2697 v3 2.6 GHz (14 rdzeni/28 wątków)
  • Pamięć: 64 x 16 GB DDR4 RDIMM
  • SSD: 16 dysków SSD 800 GB SAS Mix Use MLC 12 Gb/s
  • Dysk twardy: 80 x 1.2 TB 10 tys. obr./min SAS 6 Gb/s
  • Sieć: 4 x Intel X520 DP 10 Gb DA/SFP+, + I350 DP 1 Gb Ethernet
  • Pojemność magazynowa: 86.46TB

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 bazy danych, którą będziemy testować (400 GB). 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. Należy podkreślić, że ta konfiguracja nie została zaprojektowana tak, aby całkowicie wykorzystać wszystkie zasoby w naszym klastrze VSAN i w rzeczywistości pozostawiła wiele zasobów niewykorzystanych. Przy pełnym obciążeniu z uruchomionym testem porównawczym zaobserwowaliśmy, że maszyny wirtualne Sysbench zużywały od 7,200 do 7,900 MHz, a całkowite zasoby hosta wskazywały na około 10 000 MHz. Pozostawiło to dużo dodatkowej przestrzeni na procesor, a także pewną przestrzeń na operacje wejścia/wyjścia pamięci masowej na dodatkowe działania. Co więcej, wykorzystaliśmy tylko około 3.5 TB z 86.46 TB całkowitej pojemności pamięci masowej VSAN w naszej konfiguracji. W dalszych sekcjach poświęconych analizie wydajności przedstawimy więcej szczegółów na temat testów obejmujących wiele obciążeń, a także skalowane testowanie maszyn wirtualnych Sysbench.

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: 12 godziny
    • 6 godziny wstępnego kondycjonowania 32 wątków
    • 1 godzina 32 wątki
    • 1 godzina 16 wątki
    • 1 godzina 8 wątki
    • 1 godzina 4 wątki
    • 1 godzina 2 wątki

Przy 4 maszynach wirtualnych działających jednocześnie w klastrze, zmierzyliśmy szczytową wydajność 32-wątkową poszczególnych maszyn wirtualnych na poziomie 694TPS, 664TPS, 713TPS i 758TPS na hostach. Dało nam to średnią 707TPS ze wszystkich czterech maszyn wirtualnych, przy czym najwolniejsza była o 6.1% poniżej średniej, a najszybsza o 7.2% szybsza od średniej. Chociaż wyniki testów Sysbench nie były całkowicie równomierne, nie zaobserwowano dużych wahań w całym klastrze. Łącznie zmierzyliśmy łączną wydajność 2,829TPS w klastrze VSAN z 4 uruchomionymi maszynami wirtualnymi Sysbench.

Analizując średnie opóźnienie w teście hiperkonwergentnym Sysbench, zaobserwowaliśmy czasy reakcji wynoszące 46.07 ms, 48.18 ms, 44.86 ms i 42.21 ms przy pełnym obciążeniu. Średnia dla całego klastra wyniosła 45.33 ms. Różnica między najszybszą a najwolniejszą maszyną wirtualną wyniosła 12.3%.

W ostatniej części testu Sysbench MySQL sprawdzamy, jak platforma wypadła w pomiarze opóźnienia na poziomie 99. percentyla. Jest to obszar, w którym wyższe maksymalne czasy odpowiedzi zwiększą tę wartość raportowania. Na czterech maszynach wirtualnych Sysbench zaobserwowaliśmy czasy pod szczytowym obciążeniem w zakresie od 86.91 ms do 99.23 ms. Maksymalne opóźnienie w tym okresie wynosiło od 422 ms do 480 ms w sieci VSAN.

Infrastrukturę hiperkonwergentną najlepiej wykorzystać, rozkładając obciążenie na wszystkie zasoby obliczeniowe i pamięci masowej, co niekoniecznie ma miejsce w przypadku tradycyjnej infrastruktury IT. Wykorzystując wiele baz danych w węzłach VSAN, uzyskujemy bardziej przejrzysty obraz łącznej wydajności. W tym przypadku jest to podobne obciążenie działające na wszystkich węzłach – wkrótce przyjrzymy się temu problemowi. Ogólnie rzecz biorąc, ten typ konfiguracji ma kluczowe znaczenie dla uzyskania najlepszej możliwej wydajności VSAN lub dowolnego innego rozwiązania hiperkonwergentnego.

Dalej: Raport o wydajności VSAN Microsoft SQL Server

Recenzja VMware Virtual SAN: przegląd i konfiguracja
Recenzja VMware Virtual SAN: wydajność VMmark
Recenzja VMware Virtual SAN: wydajność Sysbench OLTP
Recenzja VMware Virtual SAN: wydajność serwera SQL
Recenzja VMware Virtual SAN: skalowana wydajność Sysbench OLTP
Recenzja VMware Virtual SAN: syntetyczna wydajność HCIbench

Strona produktu VMware VSAN

Zapisz się do newslettera StorageReview

Skontaktuj się z StorageReview

Biuletyn | YouTube | Podcast iTunes / Spotify | Instagram | Twitter | TikTok | Kanał RSS

StorageReview Enterprise Lab