Mēs turpinām jūs iepazīstināt ar Cisco HyperFlex hiperkonverģēto sistēmu.
2019. gada aprīlī Cisco atkal rīko jaunā hiperkonverģētā risinājuma Cisco HyperFlex demonstrāciju sēriju Krievijas un Kazahstānas reģionos. Jūs varat reģistrēties demonstrācijai, izmantojot atsauksmju veidlapu, sekojot saitei. Pievienojies mums!
Iepriekš mēs publicējām rakstu par slodzes testiem, ko 2017. gadā veica neatkarīgā ESG Lab. 2018. gadā ir ievērojami uzlabojusies Cisco HyperFlex risinājuma (versija HX 3.0) veiktspēja. Turklāt konkurētspējīgi risinājumi arī turpina uzlaboties. Tāpēc mēs publicējam jaunu, jaunāku ESG stresa etalonu versiju.
2018. gada vasarā ESG laboratorija atkārtoti salīdzināja Cisco HyperFlex ar konkurentiem. Ņemot vērā pašreizējo tendenci izmantot Programmatūras definētus risinājumus, salīdzinošajai analīzei tika pievienoti arī līdzīgu platformu ražotāji.
Testa konfigurācijas
Testēšanas ietvaros HyperFlex tika salīdzināts ar divām pilnībā programmatūras hiperkonverģētām sistēmām, kas ir instalētas standarta x86 serveros, kā arī ar vienu programmatūras un aparatūras risinājumu. Testēšana tika veikta, izmantojot standarta programmatūru hiperkonverģētām sistēmām - HCIBench, kas izmanto Oracle Vdbench rīku un automatizē testēšanas procesu. Jo īpaši HCIBench automātiski izveido virtuālās mašīnas, koordinē slodzi starp tām un ģenerē ērtus un saprotamus pārskatus.
Katrā klasterī tika izveidotas 140 virtuālās mašīnas (35 vienā klastera mezglā). Katra virtuālā mašīna izmantoja 4 vCPU, 4 GB RAM. Vietējais VM disks bija 16 GB un papildu disks bija 40 GB.
Pārbaudē piedalījās šādas klasteru konfigurācijas:
- četru Cisco HyperFlex 220C mezglu kopa 1 x 400 GB SSD kešatmiņai un 6 x 1.2 TB SAS HDD datiem;
- konkurents Pārdevējs Četru mezglu kopa 2 x 400 GB SSD kešatmiņai un 4 x 1 TB SATA HDD datiem;
- konkurents Vendor B klasteris ar četriem mezgliem 2 x 400 GB SSD kešatmiņai un 12 x 1.2 TB SAS HDD datiem;
- konkurents Vendor C klasteris ar četriem mezgliem 4 x 480 GB SSD kešatmiņai un 12 x 900 GB SAS HDD datiem.
Visu risinājumu procesori un operatīvā atmiņa bija identiski.
Pārbaudiet virtuālo mašīnu skaitu
Testēšana sākās ar darba slodzi, kas paredzēta standarta OLTP testa atdarināšanai: lasīšana/rakstīšana (RW) 70%/30%, 100% FullRandom ar mērķi 800 IOPS uz vienu virtuālo mašīnu (VM). Pārbaude tika veikta 140 VM katrā klasterī trīs līdz četras stundas. Testa mērķis ir saglabāt rakstīšanas latentumu pēc iespējas vairāk VM līdz 5 milisekundēm vai mazāk.
Pārbaudes rezultātā (skatiet diagrammu zemāk), HyperFlex bija vienīgā platforma, kas pabeidza šo testu ar sākotnējiem 140 VM un ar latentumu, kas mazāks par 5 ms (4,95 ms). Katrai pārējai klasterim tests tika restartēts, lai vairākās iterācijās eksperimentāli pielāgotu VM skaitu mērķa latentumam 5 ms.
Pārdevējs A veiksmīgi apstrādāja 70 VM ar vidējo reakcijas laiku 4,65 ms.
Pārdevējs B sasniedza nepieciešamo latentumu — 5,37 ms. tikai ar 36 VM.
Pārdevējs C spēja apstrādāt 48 virtuālās mašīnas ar reakcijas laiku 5,02 ms
SQL servera slodzes emulācija
Pēc tam ESG Lab emulēja SQL servera ielādi. Testā tika izmantoti dažādi bloku izmēri un lasīšanas/rakstīšanas attiecības. Tests tika veikts arī 140 virtuālajās mašīnās.
Kā parādīts zemāk esošajā attēlā, Cisco HyperFlex klasteris IOPS pārspēja gandrīz divas reizes pārdevējus A un B, bet pārdevēju C vairāk nekā piecas reizes. Cisco HyperFlex vidējais reakcijas laiks bija 8,2 ms. Salīdzinājumam, piegādātāja A vidējais reakcijas laiks bija 30,6 ms, piegādātāja B — 12,8 ms un piegādātāja C — 10,33 ms.
Visu testu laikā tika veikts interesants novērojums. Pārdevējs B uzrādīja ievērojamas atšķirības starp IOPS vidējo veiktspēju dažādās virtuālajās mašīnās. Tas ir, slodze tika sadalīta ārkārtīgi nevienmērīgi, dažas virtuālās mašīnas strādāja ar vidējo vērtību 1000 IOPS+, bet dažas - ar vērtību 64 IOPS. Cisco HyperFlex šajā gadījumā izskatījās daudz stabilāk, visas 140 VM no krātuves apakšsistēmas saņēma vidēji 600 IOPS, tas ir, slodze starp virtuālajām mašīnām tika sadalīta ļoti vienmērīgi.
Ir svarīgi atzīmēt, ka šāds nevienmērīgs IOPS sadalījums starp pārdevēja B virtuālajām mašīnām tika novērots katrā testēšanas iterācijā.
Reālajā ražošanā šāda sistēmas uzvedība var būt liela problēma administratoriem; patiesībā atsevišķas virtuālās mašīnas nejauši sāk sastingt, un praktiski nav iespējams kontrolēt šo procesu. Vienīgais, ne pārāk veiksmīgais veids, kā slodzes līdzsvaru, izmantojot piegādātāja B risinājumu, ir izmantot vienu vai otru QoS vai balansēšanas implementāciju.
secinājums
Padomāsim par to, kādas Cisco Hyperflex ir 140 virtuālās mašīnas uz 1 fizisko mezglu, salīdzinot ar 70 vai mazāk citiem risinājumiem? Uzņēmējdarbībai tas nozīmē, ka, lai Hyperflex atbalstītu tādu pašu lietojumprogrammu skaitu, ir nepieciešams 2 reizes mazāk mezglu nekā konkurentu risinājumos, t.i. galīgā sistēma būs daudz lētāka. Ja pievienojam visu tīkla, serveru un uzglabāšanas platformas HX Data Platform uzturēšanas darbību automatizācijas līmeni, kļūst skaidrs, kāpēc Cisco Hyperflex risinājumi tik strauji gūst popularitāti tirgū.
Kopumā ESG Labs ir apstiprinājusi, ka Cisco HyperFlex Hybrid HX 3.0 nodrošina ātrāku un konsekventāku veiktspēju nekā citi salīdzināmi risinājumi.
Tajā pašā laikā HyperFlex hibrīdkopas apsteidza konkurentus arī IOPS un latentuma ziņā. Tikpat svarīgi ir tas, ka HyperFlex veiktspēja tika sasniegta ar ļoti labi sadalītu slodzi visā krātuvē.
Atgādināsim, ka Cisco Hyperflex risinājumu varat apskatīt un pārbaudīt tā iespējas jau šobrīd. Sistēma ir pieejama demonstrācijai ikvienam:
Avots: www.habr.com