La kliento volis VDI. Mi vere rigardis la kombinaĵon SimpliVity + VDI Citrix Virtual Desktop. Por ĉiuj funkciigistoj, urbaj oficejo-dungitoj, ktp. Estas kvin mil uzantoj nur en la unua ondo de migrado, kaj tial ili insistis pri ŝarĝtestado. VDI povas komenci malrapidiĝi, ĝi povas trankvile kuŝi - kaj tio ne ĉiam okazas pro problemoj kun la kanalo. Ni aĉetis tre potencan testan pakon specife por VDI kaj ŝarĝis la infrastrukturon ĝis ĝi estis tro peza sur la diskoj kaj la procesoro.
Do, ni bezonos plastan botelon kaj LoginVSI-programaron por kompleksaj VDI-testoj. Ni havas ĝin kun licencoj por 300 uzantoj. Poste ni prenis HPE SimpliVity 380 aparataron en pakaĵo taŭga por la tasko de maksimuma uzantdenseco per servilo, tranĉis virtualajn maŝinojn kun bona troabono, instalis oficejan programon sur Win10 sur ili kaj komencis testi.
Ni iru!
sistemo
Du HPE SimpliVity 380 Gen10 nodoj (serviloj). Sur ĉiu:
- 2 x Intel Xeon Platinum 8170 26c 2.1Ghz.
- RAM: 768GB, 12 x 64GB LRDIMM-oj DDR4 2666MHz.
- Ĉefa diskregilo: HPE Smart Array P816i-a SR Gen10.
- Malmolaj diskoj: 9 x 1.92 TB SATA 6Gb/s SSD (en RAID6 7+2-agordo, t.e. ĉi tio estas Meza modelo laŭ HPE SimpliVity).
- Retaj kartoj: 4 x 1Gb Eth (uzantdatenoj), 2 x 10Gb Eth (SimpliVity kaj vMotion backend).
- Specialaj enkonstruitaj FPGA-kartoj en ĉiu nodo por maldupliko/kunpremado.
La nodoj estas konektitaj unu al la alia per 10Gb Ethernet-interkonekto rekte sen ekstera ŝaltilo, kiu estas uzata kiel SimpliVity-backend kaj por translokado de virtualaj maŝinaj datumoj per NFS. Virtualaj maŝindatenoj en areto ĉiam estas spegulitaj inter du nodoj.
La nodoj estas kombinitaj en Vmware vSphere-areton administritan de vCenter.
Por testado, domajna regilo kaj Citrix-konektomakleristo estis deplojitaj. La domajna regilo, makleristo kaj vCenter estas metitaj sur aparta areto.
Kiel testa infrastrukturo, 300 virtualaj labortabloj estis deplojitaj en la Dediĉita - Plena Kopio-agordo, t.e., ĉiu labortablo estas kompleta kopio de la originala bildo de la virtuala maŝino kaj konservas ĉiujn ŝanĝojn faritajn de uzantoj.
Ĉiu virtuala maŝino havas 2vCPU kaj 4GB RAM:
La sekva programaro necesa por testado estis instalita sur la virtualaj maŝinoj:
- Vindozo 10 (64-bita), versio 1809.
- Adobe Reader XI.
- Citrix Virtual Delivery Agent 1811.1.
- Doro PDF 1.82.
- Ĝisdatigo 7 de Java 13.
- Microsoft Office Professional Plus 2016.
Inter nodoj - sinkrona reproduktado. Ĉiu datumbloko en la areto havas du kopiojn. Tio estas, nun estas kompleta aro de datumoj pri ĉiu el la nodoj. Kun areto de tri aŭ pli da nodoj, kopioj de blokoj estas en du malsamaj lokoj. Dum kreado de nova VM, kroma kopio estas kreita sur unu el la grapolnodoj. Kiam unu nodo malsukcesas, ĉiuj VM-oj antaŭe kurantaj sur ĝi estas aŭtomate rekomencitaj sur aliaj nodoj, kie ili havas kopiojn. Se nodo malsukcesas dum longa tempo, tiam laŭpaŝa restarigo de redundo komenciĝas, kaj la areto revenas al N+1-redundo.
Datenbalancado kaj stokado okazas ĉe la programara stokadonivelo de SimpliVity mem.
Virtualaj maŝinoj prizorgas virtualigan areton, kiu ankaŭ metas ilin sur programarstokadon. La skribotabloj mem estis prenitaj laŭ norma ŝablono: la skribotabloj de financistoj kaj operaciaj oficiroj venis por la testo (tio estas du malsamaj ŝablonoj).
Testado
Por testado, la programo LoginVSI 4.1 testserio estis uzita. La LoginVSI-komplekso, konsistanta el kontrolservilo kaj 12 maŝinoj por testkonektoj, estis deplojita sur aparta fizika gastiganto.
Testado estis farita en tri reĝimoj:
Benchmark-reĝimo - ŝarĝu kazojn 300 Knolaboristoj kaj 300 Stoklaboristoj.
Norma reĝimo - ŝarĝo kazo 300 Potencaj laboristoj.
Por rajtigi Power-laboristojn labori kaj pliigi ŝarĝan diversecon, biblioteko de kromaj Power Library-dosieroj estis aldonita al la LoginVSI-komplekso. Por certigi ripeteblecon de la rezultoj, ĉiuj testbenkaj agordoj estis lasitaj kiel Defaŭlte.
La testoj pri Knowledge and Power-laboristoj simulas la realan laborkvanton de uzantoj laborantaj sur virtualaj laborstacioj.
La Testo pri Stokado de Laboristoj estis kreita specife por testi datumsistemojn; ĝi estas malproksima de realaj laborŝarĝoj kaj plejparte implikas la uzanton laborantan kun granda nombro da dosieroj de malsamaj grandecoj.
Dum testado, uzantoj ensalutas en laborstacioj dum 48 minutoj kun rapideco de proksimume unu uzanto ĉiujn 10 sekundojn.
Результаты
La ĉefa rezulto de LoginVSI-testado estas la VSImax-metriko, kiu estas kompilita de la ekzekuttempo de diversaj taskoj lanĉitaj de la uzanto. Ekzemple: tempo por malfermi dosieron en Notepad, tempo por kunpremi dosieron en 7-Zip, ktp.
Detala priskribo de metrika kalkulo estas havebla en la oficiala dokumentaro por .
Alivorte, LoginVSI ripetas tipan ŝargan ŝablonon, simulante uzantajn agojn en oficeja aro, legante PDF kaj tiel plu, kaj mezuras diversajn latentecojn. Estas kritika nivelo de prokrastoj "ĉio malrapidiĝas, ne eblas labori"), antaŭ kiu oni konsideras, ke la maksimuma nombro da uzantoj ne estas atingita. Se la responda tempo estas 1 000 ms pli rapida ol ĉi tiu stato "ĉio malrapidas", tiam la sistemo estas konsiderata kiel normale funkcianta, kaj pli da uzantoj povas esti aldonitaj.
Jen la ĉefaj metrikoj:
Metriko
Agoj faritaj
Detala la priskribo
Ŝarĝitaj komponantoj
N.S.L.D.
Teksta malfermtempo
dosiero pezanta 1 KB
Notepad malfermiĝas kaj
malfermas hazardan 1 KB-dokumenton kiu estas kopiita el la naĝejo
rimedoj
CPU kaj I/O
NFO
Malferma tempo de dialogo
fenestroj en notbloko
Malfermu dosieron de VSI-Notepad [Ctrl+O]
CPU, RAM kaj I/O
ZHC*
Tempo krei tre kunpremitan Zip-dosieron
Loka kunpremo
hazarda 5MB .pst dosiero kopiita de
naĝejo de rimedoj
CPU kaj I/O
ZLC*
Tempo krei malforte kunpremitan Zip-dosieron
Loka kunpremo
hazarda 5MB .pst dosiero kopiita de
naĝejo de rimedoj
I / O
CPU
Kalkulo granda
hazarda datuma tabelo
Kreante Grandan Tabelon
hazardaj datumoj, kiuj estos uzataj en la eniga/eliga tempigilo (I/O-tempigilo)
CPU
Kiam testado estas farita, la baza VSIbase-metriko estas komence kalkulita, kiu montras la rapidecon kun kiu laboroj estas ekzekutitaj sen ŝarĝo sur la sistemo. Surbaze de ĝi, VSImax Threshold estas determinita, kiu estas egala al VSIbase + 1ms.
Konkludoj pri sistema rendimento estas faritaj surbaze de du metrikoj: VSIbase, kiu determinas la rapidecon de la sistemo, kaj VSImax sojlo, kiu determinas la maksimuman nombron da uzantoj kiujn la sistemo povas manipuli sen grava degenero.
Referenco de 300 Sciolaboristoj
Sciolaboristoj estas uzantoj kiuj regule ŝarĝas memoron, procesoron kaj IO kun diversaj malgrandaj pintoj. La programaro imitas la laborŝarĝon de postulemaj oficejaj uzantoj, kvazaŭ ili konstante pikas ion (PDF, Java, oficeja aro, fotospektado, 7-Zip). Dum vi aldonas uzantojn de nulo ĝis 300, la prokrasto por ĉiu iom post iom pliiĝas.
VSImax-statistikaj datumoj:
VSIbase = 986ms, VSI-Sojlo ne estis atingita.
Stoksistemo-ŝarĝostatistiko de SimpliVity-monitorado:
Kun ĉi tiu speco de ŝarĝo, la sistemo povas elteni pliigitan ŝarĝon kun preskaŭ neniu degenero en efikeco. La tempo necesa por plenumi uzanttaskojn pliiĝas glate, la sistemo respondtempo ne ŝanĝiĝas dum testado kaj estas ĝis 3 ms por skribo kaj ĝis 1 ms por legado.
Konkludo: 300 sciuzantoj laboras sur la nuna areto senprobleme kaj ne malhelpas unu la alian, atingante pCPU/vCPU-superan abonon de 1 ĝis 6. La ĝeneralaj prokrastoj kreskas egale dum la ŝarĝo pliiĝas, sed la kondiĉita limo ne estas atingita.
Referenco de 300 Stokaj laboristoj
Ĉi tiuj estas uzantoj, kiuj konstante skribas kaj legas en proporcio de 30 ĝis 70, respektive. Ĉi tiu provo estis farita pli por eksperimentado. VSImax-statistikaj datumoj:
VSIbase = 1673, VSI Sojlo atingita sur 240 uzantoj.
Stoksistemo-ŝarĝostatistiko de SimpliVity-monitorado:
Ĉi tiu speco de ŝarĝo estas esence streĉa provo de la stokada sistemo. Kiam ĝi estas ekzekutita, ĉiu uzanto skribas multajn hazardajn dosierojn de malsamaj grandecoj al disko. En ĉi tiu kazo, oni povas vidi, ke kiam certa ŝarĝa sojlo estas superita por iuj uzantoj, la tempo necesa por plenumi taskojn por skribi dosierojn pliiĝas. Samtempe, la ŝarĝo sur la stokadsistemo, procesoro kaj memoro de la gastigantoj ne ŝanĝas signife, do nuntempe estas neeble determini ĝuste kio kaŭzas la malfruojn.
Konkludoj pri sistema efikeco uzante ĉi tiun teston povas esti faritaj nur kompare kun testrezultoj sur aliaj sistemoj, ĉar tiaj ŝarĝoj estas sintezaj kaj nerealismaj. Tamen, entute la testo iris bone. Ĉio iris bone ĝis 210 sesioj, kaj tiam komenciĝis strangaj respondoj, kiuj ne estis spuritaj ie ajn krom Ensalutu VSI.
300 Potencaj laboristoj
Ĉi tiuj estas uzantoj, kiuj amas CPU, memoron kaj altan IO. Ĉi tiuj "potencaj uzantoj" regule plenumas kompleksajn taskojn kun longaj eksplodoj, kiel instali novan programaron kaj malpaki grandajn arkivojn. VSImax-statistikaj datumoj:
VSIbase = 970, VSI-Sojlo ne estis atingita.
Stoksistemo-ŝarĝostatistiko de SimpliVity-monitorado:
Dum testado, la sojlo de ŝarĝo de procesoro estis atingita sur unu el la sistemaj nodoj, sed ĉi tio ne havis gravan efikon sur ĝia funkciado:
En ĉi tiu kazo, la sistemo povas elteni pliigitan ŝarĝon sen grava rendimento-degenero. La tempo necesa por plenumi uzanttaskojn pliiĝas glate, la sistemo respondtempo ne ŝanĝiĝas dum testado kaj estas ĝis 3 ms por skribo kaj ĝis 1 ms por legado.
Regulaj testoj ne sufiĉis por la kliento, kaj ni iris plu: ni pliigis la VM-karakterizaĵojn (nombro da vCPU-oj por taksi la pliiĝon de troabono kaj diskgrandeco) kaj aldonis plian ŝarĝon.
Dum farado de kromaj testoj, la sekva standagordo estis uzata:
300 virtualaj labortabloj estis deplojitaj en 4vCPU, 4GB RAM, 80GB HDD-konfiguracio.
Agordo de unu el la testaj maŝinoj:
La maŝinoj estas deplojitaj en la opcio Dediĉita - Plena Kopio:
300 Sciolaboristoj komparnormo kun troabono 12
VSImax-statistikaj datumoj:
VSIbase = 921 ms, VSI-Sojlo ne estis atingita.
Stoksistemo-ŝarĝostatistiko de SimpliVity-monitorado:
La rezultoj akiritaj estas similaj al testado de la antaŭa VM-agordo.
300 Potencaj laboristoj kun 12 troabonoj
VSImax-statistikaj datumoj:
VSIbase = 933, VSI-Sojlo ne estis atingita.
Stoksistemo-ŝarĝostatistiko de SimpliVity-monitorado:
Dum ĉi tiu testado, la sojlo de ŝarĝo de procesoro ankaŭ estis atingita, sed ĉi tio ne havis signifan efikon al efikeco:
La rezultoj akiritaj estas similaj al testado de la antaŭa agordo.
Kio okazas se vi kuras la ŝarĝon dum 10 horoj?
Nun ni vidu ĉu estos "akuma efiko" kaj faru provojn dum 10 horoj sinsekve.
La longdaŭraj provoj kaj priskribo de la sekcio devas celi la fakton, ke ni volis kontroli ĉu iuj problemoj aperos kun la herniobandaĝo sub longedaŭra ŝarĝo sur ĝi.
Referenco de 300 Sciolaboristoj + 10 horoj
Aldone, ŝarĝokazo de 300 scilaboristoj estis testita, sekvita de uzantlaboro dum 10 horoj.
VSImax-statistikaj datumoj:
VSIbase = 919 ms, VSI-Sojlo ne estis atingita.
VSImax Detalaj statistikaj datumoj:
La grafikaĵo montras, ke ne estas agado-degenero observita dum la tuta testo.
Stoksistemo-ŝarĝostatistiko de SimpliVity-monitorado:
La rendimento de la stokadsistemo restas la sama dum la provo.
Pliaj provoj kun aldono de sinteza ŝarĝo
La kliento petis aldoni sovaĝan ŝarĝon al la disko. Por fari tion, tasko estis aldonita al la stokadsistemo en ĉiu el la virtualaj maŝinoj de la uzanto por funkciigi sintezan ŝarĝon sur la disko kiam la uzanto ensalutas en la sistemon. La ŝarĝo estis provizita de la fio-utilo, kiu permesas vin limigi la ŝarĝon sur la disko per la nombro da IOPS. En ĉiu maŝino, tasko estis lanĉita por lanĉi plian ŝarĝon en la kvanto de 22 IOPS 70%/30% Hazarda Legado/Skribo.
Referenco de 300 Sciolaboristoj + 22 IOPS per uzanto
En komenca testado, fio estis trovita trudi signifan CPU-superkompeton al virtualaj maŝinoj. Tio kondukis al rapida CPU-troŝarĝo de la gastigantoj kaj tre influis la funkciadon de la sistemo kiel tutaĵo.
Gastiga CPU-ŝarĝo:
Samtempe, prokrastoj de stokadsistemo ankaŭ nature pliiĝis:
La manko de komputika potenco iĝis kritika ĉirkaŭ 240 uzantoj:
Pro la rezultoj akiritaj, estis decidite fari testadon kiu estis malpli CPU-intensa.
Referenco de 230 oficejaj laboristoj + 22 IOPS per uzanto
Por redukti la ŝarĝon sur la CPU, la ŝarĝospeco de Oficejaj laboristoj estis elektita, kaj 22 IOPS de sinteza ŝarĝo ankaŭ estis aldonitaj al ĉiu sesio.
La testo estis limigita al 230 sesioj por ne superi la maksimuman CPU-ŝarĝon.
La testo estis farita kun uzantoj kurantaj dum 10 horoj por kontroli la stabilecon de la sistemo dum longdaŭra operacio ĉe proksima al maksimuma ŝarĝo.
VSImax-statistikaj datumoj:
VSIbase = 918 ms, VSI-Sojlo ne estis atingita.
VSImax Detalaj statistikaj datumoj:
La grafikaĵo montras, ke ne estas agado-degenero observita dum la tuta testo.
CPU-ŝarĝostatistiko:
Farinte ĉi tiun provon, la ŝarĝo sur la CPU de la gastigantoj estis preskaŭ maksimuma.
Stoksistemo-ŝarĝostatistiko de SimpliVity-monitorado:
La rendimento de la stokadsistemo restas la sama dum la provo.
La ŝarĝo sur la stokadsistemo dum la testo estis proksimume 6 IOPS en proporcio 500/60 (40 IOPS legado, 3 IOPS skriba), kio estas proksimume 900 IOPS per laborstacio.
Respondtempo averaĝe 3 ms por skribo kaj ĝis 1 ms por legado.
La rezulto
Dum simulado de realaj ŝarĝoj sur la HPE SimpliVity-infrastrukturo, rezultoj estis akiritaj konfirmante la kapablon de la sistemo subteni virtualajn labortablojn de almenaŭ 300 Full Clone-maŝinoj sur paro de SimpliVity-nodoj. Samtempe, la responda tempo de la stokada sistemo estis konservita je optimuma nivelo dum la tuta testado.
Ni estas tre impresitaj de la alproksimiĝo de longaj provoj kaj komparo de solvoj antaŭ efektivigo. Ni ankaŭ povas testi rendimenton por viaj laborŝarĝoj, se vi deziras. Inkluzive de aliaj hiperkonverĝaj solvoj. La menciita kliento nun finas testojn pri alia solvo paralele. Ĝia nuna infrastrukturo estas simple aro de komputiloj, domajno kaj programaro ĉe ĉiu laborejo. Transloĝiĝi al VDI sen testoj estas, kompreneble, sufiĉe malfacila. Specife, estas malfacile kompreni la realajn kapablojn de VDI-bieno sen migrado de realaj uzantoj al ĝi. Kaj ĉi tiuj provoj permesas vin rapide taksi la realajn kapablojn de aparta sistemo sen la bezono impliki ordinarajn uzantojn. De tie venis ĉi tiu studo.
La dua grava aliro estas, ke la kliento tuj kompromitis al taŭga skalo. Ĉi tie vi povas aĉeti plian servilon kaj aldoni bienon, ekzemple, por 100 uzantoj, ĉio estas antaŭvidebla ĉe la uzantprezo. Ekzemple, kiam ili bezonos aldoni 300 pliajn uzantojn, ili scios, ke ili bezonas du servilojn en jam difinita agordo, anstataŭ rekonsideri ĝisdatigi sian tutan infrastrukturon.
Interesaj estas la eblecoj de la federacio HPE SimpliVity. La komerco estas geografie apartigita, do havas sencon instali vian propran apartan VDI-aparaton en malproksima oficejo. En la federacio SimpliVity, ĉiu virtuala maŝino estas reproduktita laŭ horaro kun la kapablo reprodukti inter geografie malproksimaj aretoj tre rapide kaj sen ŝarĝo sur la kanalo - ĉi tio estas enkonstruita sekurkopio de tre bona nivelo. Reproduktante VM-ojn inter retejoj, la kanalo estas uzata kiel eble plej minimume, kaj ĉi tio ebligas konstrui tre interesajn DR-arkitekturojn en ĉeesto de ununura kontrolcentro kaj amaso da malcentralizitaj stokadejoj.
Ĉio ĉi kune ebligas taksi la financan flankon tre detale, kaj supermeti la kostojn de VDI al la kreskoplanoj de la kompanio, kaj kompreni kiom rapide la solvo pagos kaj kiel ĝi funkcios. Ĉar ajna VDI estas solvo, kiu finfine ŝparas multajn rimedojn, sed samtempe, plej verŝajne, sen la kostefika ŝanco ŝanĝi ĝin ene de 5-7 jaroj de uzo.
Ĝenerale, se vi havas demandojn, kiuj ne estas por komentoj, skribu al mi retpoŝte [retpoŝte protektita].
fonto: www.habr.com