Հաճախորդը ցանկանում էր VDI: Ես իսկապես նայեցի SimpliVity + VDI Citrix վիրտուալ աշխատասեղանի համադրությանը: Բոլոր օպերատորների, քաղաքային գրասենյակի աշխատակիցների և այլնի համար: Միայն միգրացիայի առաջին ալիքում հինգ հազար օգտատեր կա, և, հետևաբար, նրանք պնդեցին բեռի փորձարկումը: VDI-ն կարող է սկսել դանդաղեցնել, այն կարող է հանգիստ պառկել, և դա միշտ չէ, որ տեղի է ունենում ալիքի հետ կապված խնդիրների պատճառով: Մենք գնեցինք շատ հզոր թեստավորման փաթեթ հատուկ VDI-ի համար և բեռնեցինք ենթակառուցվածքը այնքան ժամանակ, մինչև այն շատ ծանրացավ սկավառակների և պրոցեսորի վրա:
Այսպիսով, մեզ անհրաժեշտ կլինի պլաստիկ շիշ և LoginVSI ծրագրակազմ VDI-ի բարդ թեստերի համար: Մենք ունենք այն 300 օգտագործողների համար նախատեսված արտոնագրերով: Այնուհետև մենք վերցրեցինք HPE SimpliVity 380 ապարատը փաթեթով, որը հարմար էր յուրաքանչյուր սերվերի համար օգտագործողի առավելագույն խտության առաջադրանքին, կտրեցինք վիրտուալ մեքենաները լավ գերբաժանորդագրությամբ, տեղադրեցինք գրասենյակային ծրագրեր Win10-ի վրա և սկսեցինք փորձարկումը:
Եկեք գնանք.
Համակարգ
Երկու HPE SimpliVity 380 Gen10 հանգույց (սերվեր): Յուրաքանչյուրի վրա.
- 2 x Intel Xeon Platinum 8170 26c 2.1 ԳՀց:
- Օպերատիվ հիշողություն՝ 768 ԳԲ, 12 x 64 ԳԲ LRDIMMs DDR4 2666 ՄՀց:
- Սկավառակի հիմնական կարգավորիչ՝ HPE Smart Array P816i-a SR Gen10:
- Կոշտ սկավառակներ՝ 9 x 1.92 TB SATA 6Gb/s SSD (RAID6 7+2 կոնֆիգուրացիայով, այսինքն՝ սա միջին մոդել է HPE SimpliVity առումով):
- Ցանցային քարտեր՝ 4 x 1Gb Eth (օգտվողի տվյալներ), 2 x 10Gb Eth (SimpliVity և vMotion backend):
- Հատուկ ներկառուցված FPGA քարտեր յուրաքանչյուր հանգույցում կրկնօրինակման/սեղմման համար:
Հանգույցները միացված են միմյանց 10 Գբ Ethernet փոխկապակցման միջոցով անմիջապես առանց արտաքին անջատիչի, որն օգտագործվում է որպես SimpliVity backend և վիրտուալ մեքենայի տվյալները NFS-ի միջոցով փոխանցելու համար: Կլաստերում վիրտուալ մեքենայի տվյալները միշտ արտացոլվում են երկու հանգույցների միջև:
Հանգույցները միավորվում են Vmware vSphere կլաստերի մեջ, որը կառավարվում է vCenter-ի կողմից:
Փորձարկման համար տեղադրվել են տիրույթի վերահսկիչ և Citrix կապի բրոքեր: Դոմենի վերահսկիչը, բրոքերը և vCenter-ը տեղադրված են առանձին կլաստերի վրա:
Որպես փորձնական ենթակառուցվածք՝ 300 վիրտուալ աշխատասեղան տեղակայվել է Dedicated – Full Copy կազմաձևում, այսինքն՝ յուրաքանչյուր աշխատասեղան վիրտուալ մեքենայի բնօրինակ պատկերի ամբողջական պատճենն է և պահպանում է օգտագործողների կողմից կատարված բոլոր փոփոխությունները:
Յուրաքանչյուր վիրտուալ մեքենա ունի 2vCPU և 4GB RAM:
Վիրտուալ մեքենաների վրա տեղադրվել է փորձարկման համար անհրաժեշտ հետևյալ ծրագիրը.
- Windows 10 (64-bit), տարբերակ 1809:
- Adobe Reader XI.
- Citrix վիրտուալ առաքման գործակալ 1811.1.
- Doro PDF 1.82.
- Java 7-ի թարմացում 13.
- Microsoft Office Professional Plus 2016 թ.
Հանգույցների միջև - համաժամանակյա վերարտադրություն: Կլաստերի յուրաքանչյուր տվյալների բլոկ ունի երկու օրինակ: Այսինքն՝ այժմ հանգույցներից յուրաքանչյուրի վերաբերյալ տվյալների ամբողջական փաթեթ կա։ Երեք կամ ավելի հանգույցներից բաղկացած կլաստերի դեպքում բլոկների պատճենները գտնվում են երկու տարբեր տեղերում: Նոր VM ստեղծելիս լրացուցիչ պատճեն է ստեղծվում կլաստերի հանգույցներից մեկում։ Երբ մի հանգույցը ձախողվում է, բոլոր VM-ները, որոնք նախկինում աշխատում էին դրա վրա, ավտոմատ կերպով վերագործարկվում են այլ հանգույցներում, որտեղ նրանք ունեն կրկնօրինակներ: Եթե հանգույցը երկար ժամանակ ձախողվում է, ապա սկսվում է ավելորդության աստիճանական վերականգնումը, և կլաստերը վերադառնում է N+1 ավելորդության:
Տվյալների հավասարակշռումը և պահպանումը տեղի են ունենում հենց SimpliVity-ի ծրագրային ապահովման պահպանման մակարդակում:
Վիրտուալ մեքենաները գործարկում են վիրտուալացման կլաստեր, որը դրանք տեղադրում է նաև ծրագրային ապահովման պահեստում: Գրասեղաններն իրենք վերցվել են ստանդարտ ձևանմուշի համաձայն. ֆինանսիստների և գործառնական սպաների սեղանները եկել են փորձարկման (սրանք երկու տարբեր կաղապարներ են):
Փորձարկում
Փորձարկման համար օգտագործվել է LoginVSI 4.1 ծրագրային ապահովման թեստային փաթեթը: LoginVSI համալիրը, որը բաղկացած է հսկիչ սերվերից և 12 մեքենաներից՝ թեստային կապերի համար, տեղակայվել է առանձին ֆիզիկական հոսթի վրա:
Փորձարկումն իրականացվել է երեք ռեժիմով.
Հենանիշի ռեժիմ - բեռնման դեպքեր 300 Գիտելիքի աշխատող և 300 Պահպանման աշխատող:
Ստանդարտ ռեժիմ - բեռնման տուփ 300 Power աշխատողներ:
Power աշխատողներին աշխատելու և բեռների բազմազանությունը մեծացնելու համար լրացուցիչ Power Library ֆայլերի գրադարան ավելացվեց LoginVSI համալիրում: Արդյունքների կրկնելիությունն ապահովելու համար փորձարկման նստարանի բոլոր կարգավորումները մնացին որպես լռելյայն:
Գիտելիքի և հզորության աշխատողների թեստերը նմանակում են վիրտուալ աշխատանքային կայաններում աշխատող օգտատերերի իրական ծանրաբեռնվածությունը:
Պահպանման աշխատողների թեստը ստեղծվել է հատուկ տվյալների պահպանման համակարգերի փորձարկման համար, այն հեռու է իրական ծանրաբեռնվածությունից և հիմնականում ներառում է օգտվողին աշխատելու տարբեր չափերի մեծ թվով ֆայլերի հետ:
Փորձարկման ընթացքում օգտատերերը 48 րոպեով մուտք են գործում աշխատատեղեր՝ յուրաքանչյուր 10 վայրկյանը մեկ մոտավորապես մեկ օգտագործողի արագությամբ:
Արդյունքները
LoginVSI թեստավորման հիմնական արդյունքը VSImax չափիչն է, որը կազմված է օգտատիրոջ կողմից գործարկված տարբեր առաջադրանքների կատարման ժամանակից: Օրինակ՝ Notepad-ում ֆայլ բացելու ժամանակը, 7-Zip-ով ֆայլը սեղմելու ժամանակը և այլն:
Չափումների հաշվարկի մանրամասն նկարագրությունը հասանելի է պաշտոնական փաստաթղթերում .
Այլ կերպ ասած, LoginVSI-ն կրկնում է տիպիկ բեռնման օրինակ՝ մոդելավորելով օգտատերերի գործողությունները գրասենյակային փաթեթում, կարդալով PDF և այլն, և չափում է տարբեր հետաձգումներ: Կա ուշացումների կրիտիկական մակարդակ՝ «ամեն ինչ դանդաղում է, անհնար է աշխատել»), մինչ այդ համարվում է, որ օգտատերերի առավելագույն թիվը չի հասել։ Եթե արձագանքման ժամանակը 1 ms-ով ավելի արագ է, քան այս «ամեն ինչ դանդաղ է» վիճակից, ապա համարվում է, որ համակարգը նորմալ աշխատում է, և կարող են ավելի շատ օգտվողներ ավելացնել:
Ահա հիմնական ցուցանիշները.
Չափումներ
Կատարված գործողություններ
Մանրամասն описание
Բեռնված բաղադրիչներ
Ն.Ս.Լ.Դ.
Տեքստի բացման ժամը
1 ԿԲ քաշով ֆայլ
Նոթատետրը բացվում է և
բացում է պատահական 1 ԿԲ փաստաթուղթ, որը պատճենված է լողավազանից
ռեսուրսներ
CPU և I/O
NFO
Երկխոսության բացման ժամը
պատուհանները նոթատետրում
VSI-Notepad ֆայլի բացում [Ctrl+O]
CPU, RAM և I/O
ZHC*
Ժամանակն է ստեղծել խիստ սեղմված Zip ֆայլ
Տեղական սեղմում
Պատճենված է պատահական 5 ՄԲ .pst ֆայլից
ռեսուրսների լողավազան
CPU և I/O
ZLC*
Ժամանակն է ստեղծել թույլ սեղմված Zip ֆայլ
Տեղական սեղմում
Պատճենված է պատահական 5 ՄԲ .pst ֆայլից
ռեսուրսների լողավազան
I / O
CPU
Մեծ հաշվարկ
պատահական տվյալների զանգված
Մեծ զանգվածի ստեղծում
պատահական տվյալներ, որոնք կօգտագործվեն մուտքային/ելքային ժամանակաչափում (I/O ժամանակաչափ)
CPU
Երբ փորձարկումն իրականացվում է, սկզբնապես հաշվարկվում է VSIbase-ի հիմնական չափանիշը, որը ցույց է տալիս արագությունը, որով աշխատանքները կատարվում են առանց համակարգի վրա բեռի: Դրա հիման վրա որոշվում է VSImax շեմը, որը հավասար է VSIbase + 1ms-ի։
Համակարգի կատարողականի վերաբերյալ եզրակացությունները կատարվում են երկու չափումների հիման վրա՝ VSIbase, որը որոշում է համակարգի արագությունը, և VSImax շեմը, որը որոշում է օգտվողների առավելագույն թիվը, որոնց համակարգը կարող է աշխատել առանց էական դեգրադացիայի:
300 Գիտելիք աշխատողների չափանիշ
Գիտելիքի աշխատողներն այն օգտվողներն են, ովքեր պարբերաբար բեռնում են հիշողությունը, պրոցեսորը և IO-ն տարբեր փոքր գագաթներով: Ծրագիրը ընդօրինակում է պահանջկոտ գրասենյակի օգտատերերի ծանրաբեռնվածությունը, ասես նրանք անընդհատ ինչ-որ բան են թակում (PDF, Java, գրասենյակային փաթեթ, լուսանկարների դիտում, 7-Zip): Երբ ավելացնում եք օգտվողներին զրոյից մինչև 300, յուրաքանչյուրի ուշացումը աստիճանաբար մեծանում է:
VSImax վիճակագրության տվյալներ.
VSIbase = 986ms, VSI շեմը չի հասել:
Պահպանման համակարգի բեռնվածության վիճակագրությունը SimpliVity մոնիտորինգից.
Այս տեսակի բեռի դեպքում համակարգը կարող է դիմակայել մեծացած բեռին, գործնականում առանց կատարողականի դեգրադացիայի: Օգտագործողի առաջադրանքները կատարելու համար պահանջվող ժամանակը սահուն աճում է, համակարգի արձագանքման ժամանակը չի փոխվում թեստավորման ընթացքում և կազմում է մինչև 3 մվ գրելու և մինչև 1 մվ կարդալու համար:
Եզրակացություն. Գիտելիքի 300 օգտատերեր աշխատում են ընթացիկ կլաստերի վրա առանց որևէ խնդիրների և չեն խանգարում միմյանց՝ հասնելով pCPU/vCPU գերբաժանորդագրման 1-ից 6-ի: Ընդհանուր ուշացումները հավասարապես աճում են բեռի մեծացման հետ, բայց սահմանված սահմանը չի հասել:
300 Պահպանման աշխատողների չափանիշ
Սրանք օգտատերեր են, ովքեր անընդհատ գրում և կարդում են համապատասխանաբար 30-ից 70 հարաբերակցությամբ։ Այս թեստն ավելի շատ իրականացվել է փորձի համար։ VSImax վիճակագրության տվյալներ.
VSIbase = 1673, VSI շեմը հասել է 240 օգտագործողների:
Պահպանման համակարգի բեռնվածության վիճակագրությունը SimpliVity մոնիտորինգից.
Այս տեսակի բեռը, ըստ էության, պահեստավորման համակարգի սթրես-թեստ է: Երբ այն կատարվում է, յուրաքանչյուր օգտվող սկավառակի վրա գրում է տարբեր չափերի բազմաթիվ պատահական ֆայլեր: Այս դեպքում կարելի է տեսնել, որ երբ որոշ օգտատերերի համար բեռնվածության որոշակի շեմը գերազանցվում է, ֆայլեր գրելու համար առաջադրանքները կատարելու համար պահանջվող ժամանակը մեծանում է: Միևնույն ժամանակ, պահեստավորման համակարգի, պրոցեսորի և հոսթների հիշողության ծանրաբեռնվածությունը էապես չի փոխվում, ուստի ներկայումս անհնար է ճշգրիտ որոշել, թե ինչն է ուշացումների պատճառ:
Այս թեստի օգտագործմամբ համակարգի աշխատանքի վերաբերյալ եզրակացություններ կարելի է անել միայն այլ համակարգերի փորձարկման արդյունքների համեմատությամբ, քանի որ նման բեռները սինթետիկ են և անիրատեսական: Այնուամենայնիվ, ընդհանուր առմամբ թեստը լավ անցավ: Ամեն ինչ լավ էր ընթանում մինչև 210 սեանս, իսկ հետո սկսվեցին տարօրինակ արձագանքներ, որոնք ոչ մի տեղ չհետևեցին, բացի Login VSI-ից։
300 էլեկտրաէներգիայի աշխատողներ
Սրանք օգտվողներ են, ովքեր սիրում են պրոցեսոր, հիշողություն և բարձր IO: Այս «հզոր օգտվողները» կանոնավոր կերպով կատարում են բարդ առաջադրանքներ երկարատև պոռթկումներով, ինչպիսիք են նոր ծրագրերի տեղադրումը և մեծ արխիվների փաթեթավորումը: VSImax վիճակագրության տվյալներ.
VSIbase = 970, VSI շեմը չի հասել:
Պահպանման համակարգի բեռնվածության վիճակագրությունը SimpliVity մոնիտորինգից.
Փորձարկման ընթացքում պրոցեսորի բեռնվածության շեմը հասել է համակարգի հանգույցներից մեկի վրա, բայց դա էական ազդեցություն չի ունեցել դրա աշխատանքի վրա.
Այս դեպքում համակարգը կարող է դիմակայել ավելացած բեռին, առանց կատարողականի զգալի դեգրադացիայի: Օգտագործողի առաջադրանքները կատարելու համար պահանջվող ժամանակը սահուն աճում է, համակարգի արձագանքման ժամանակը չի փոխվում թեստավորման ընթացքում և կազմում է մինչև 3 մվ գրելու և մինչև 1 մվ կարդալու համար:
Հաճախորդի համար կանոնավոր թեստերը բավարար չէին, և մենք ավելի հեռուն գնացինք. մենք ավելացրինք VM-ի բնութագրերը (vCPU-ների թիվը՝ գերաբաժանորդագրման և սկավառակի չափի աճը գնահատելու համար) և ավելացրինք լրացուցիչ բեռ:
Լրացուցիչ թեստեր անցկացնելիս օգտագործվել է ստենդի հետևյալ կոնֆիգուրացիան.
300 վիրտուալ աշխատասեղան տեղակայվել է 4vCPU, 4GB RAM, 80GB HDD կոնֆիգուրացիայի մեջ:
Փորձարկման մեքենաներից մեկի կոնֆիգուրացիա.
Մեքենաները տեղակայված են Dedicated – Full Copy տարբերակում.
300 Գիտելիք աշխատողների չափանիշը գերաբաժանորդագրությամբ 12
VSImax վիճակագրության տվյալներ.
VSIbase = 921 ms, VSI շեմը չի հասել:
Պահպանման համակարգի բեռնվածության վիճակագրությունը SimpliVity մոնիտորինգից.
Ստացված արդյունքները նման են նախորդ VM կոնֆիգուրացիայի փորձարկմանը:
300 էլեկտրաէներգիայի աշխատողներ՝ 12 գերբաժանորդագրություններով
VSImax վիճակագրության տվյալներ.
VSIbase = 933, VSI շեմը չի հասել:
Պահպանման համակարգի բեռնվածության վիճակագրությունը SimpliVity մոնիտորինգից.
Այս թեստավորման ընթացքում հասել է նաև պրոցեսորի բեռնվածության շեմը, սակայն դա էական ազդեցություն չի ունեցել կատարողականի վրա.
Ստացված արդյունքները նման են նախորդ կոնֆիգուրացիայի փորձարկմանը:
Ի՞նչ կպատահի, եթե բեռը աշխատացնեք 10 ժամ:
Հիմա եկեք տեսնենք, թե արդյոք կլինի «կուտակման էֆեկտ» և 10 ժամ անընդմեջ թեստեր կատարենք:
Բաժնի երկարաժամկետ փորձարկումները և նկարագրությունը պետք է ուղղված լինեն նրան, որ մենք ցանկանում էինք ստուգել, թե արդյոք դրա վրա երկարատև ծանրաբեռնվածության դեպքում որևէ խնդիր կառաջանա ֆերմայի հետ:
300 Գիտելիք աշխատողների չափանիշ + 10 ժամ
Բացի այդ, փորձարկվել է 300 գիտելիքի աշխատողների ծանրաբեռնվածությունը, որին հաջորդել է օգտատերերի աշխատանքը 10 ժամ:
VSImax վիճակագրության տվյալներ.
VSIbase = 919 ms, VSI շեմը չի հասել:
VSImax Մանրամասն վիճակագրական տվյալներ.
Գրաֆիկը ցույց է տալիս, որ ամբողջ թեստի ընթացքում կատարողականի անկում չի նկատվում:
Պահպանման համակարգի բեռնվածության վիճակագրությունը SimpliVity մոնիտորինգից.
Պահպանման համակարգի աշխատանքը փորձարկման ընթացքում մնում է նույնը:
Լրացուցիչ փորձարկում սինթետիկ բեռի ավելացմամբ
Հաճախորդը խնդրեց սկավառակի վրա վայրի բեռ ավելացնել: Դա անելու համար օգտագործողի վիրտուալ մեքենաներից յուրաքանչյուրի պահեստավորման համակարգին ավելացվեց առաջադրանք՝ սինթետիկ բեռը սկավառակի վրա գործարկելու համար, երբ օգտվողը մուտք է գործում համակարգ: Բեռը տրամադրվել է fio կոմունալ ծրագրի կողմից, որը թույլ է տալիս սահմանափակել սկավառակի բեռը IOPS-ի քանակով: Յուրաքանչյուր մեքենայում գործարկվեց առաջադրանք՝ գործարկել լրացուցիչ բեռ՝ 22 IOPS 70%/30% Պատահական կարդալ/գրել:
300 գիտելիք աշխատողների չափանիշ + 22 IOPS մեկ օգտագործողի համար
Նախնական փորձարկումների ժամանակ պարզվեց, որ fio-ն զգալի CPU-ի գերավճար է դնում վիրտուալ մեքենաների վրա: Սա հանգեցրեց հոսթների արագ պրոցեսորի ծանրաբեռնվածությանը և մեծապես ազդեց ամբողջ համակարգի աշխատանքի վրա:
Հյուրընկալող պրոցեսորի բեռնվածություն.
Միևնույն ժամանակ, պահեստավորման համակարգի ուշացումները նույնպես բնականաբար ավելացել են.
Հաշվողական հզորության բացակայությունը դարձել է կրիտիկական մոտ 240 օգտագործողների համար.
Ձեռք բերված արդյունքների շնորհիվ որոշվեց անցկացնել թեստավորում, որն ավելի քիչ ինտենսիվ պրոցեսոր է:
230 գրասենյակային աշխատողների չափանիշ + 22 IOPS մեկ օգտագործողի համար
Պրոցեսորի ծանրաբեռնվածությունը նվազեցնելու համար ընտրվել է Office աշխատողների բեռնվածության տեսակը, և յուրաքանչյուր նիստին ավելացվել է նաև սինթետիկ բեռի 22 IOPS:
Թեստը սահմանափակվել է 230 նիստով՝ պրոցեսորի առավելագույն բեռնվածությունը չգերազանցելու համար:
Թեստն անցկացվել է 10 ժամ վազող օգտատերերի հետ, որպեսզի ստուգեն համակարգի կայունությունը երկարաժամկետ շահագործման ընթացքում առավելագույն ծանրաբեռնվածության դեպքում:
VSImax վիճակագրության տվյալներ.
VSIbase = 918 ms, VSI շեմը չի հասել:
VSImax Մանրամասն վիճակագրական տվյալներ.
Գրաֆիկը ցույց է տալիս, որ ամբողջ թեստի ընթացքում կատարողականի անկում չի նկատվում:
CPU բեռնվածության վիճակագրություն.
Այս թեստը կատարելիս հյուրընկալողի պրոցեսորի ծանրաբեռնվածությունը գրեթե առավելագույնն էր:
Պահպանման համակարգի բեռնվածության վիճակագրությունը SimpliVity մոնիտորինգից.
Պահպանման համակարգի աշխատանքը փորձարկման ընթացքում մնում է նույնը:
Փորձարկման ընթացքում պահեստավորման համակարգի ծանրաբեռնվածությունը մոտավորապես 6 IOPS էր 500/60 հարաբերակցությամբ (40 IOPS կարդալ, 3 IOPS գրել), որը մոտավորապես 900 IOPS է մեկ աշխատակայանի համար:
Արձագանքման ժամանակը միջինը կազմել է 3 ms գրելու համար և մինչև 1 ms կարդալու համար:
Լրիվ
HPE SimpliVity ենթակառուցվածքի վրա իրական բեռներ մոդելավորելիս արդյունքներ են ստացվել, որոնք հաստատում են համակարգի կարողությունը՝ աջակցելու առնվազն 300 Full Clone մեքենաների վիրտուալ աշխատասեղաններին մի զույգ SimpliVity հանգույցների վրա: Միևնույն ժամանակ, պահեստավորման համակարգի արձագանքման ժամանակը պահպանվել է օպտիմալ մակարդակի վրա ողջ փորձարկման ընթացքում:
Մենք շատ տպավորված ենք երկար փորձարկումների մոտեցումից և լուծումների համեմատությունից առաջ: Ցանկության դեպքում մենք կարող ենք նաև փորձարկել կատարողականությունը ձեր ծանրաբեռնվածության համար: Ներառյալ այլ հիպերկոնվերգացված լուծումներ: Նշված հաճախորդն այժմ զուգահեռաբար ավարտում է մեկ այլ լուծույթի թեստերը։ Նրա ներկայիս ենթակառուցվածքը պարզապես ԱՀ-ների նավատորմ է, տիրույթ և ծրագրակազմ յուրաքանչյուր աշխատավայրում: Առանց թեստերի VDI տեղափոխվելը, իհարկե, բավականին դժվար է։ Մասնավորապես, դժվար է հասկանալ VDI ֆերմայի իրական հնարավորությունները՝ առանց իրական օգտվողներին այնտեղ տեղափոխելու: Եվ այս թեստերը թույլ են տալիս արագ գնահատել կոնկրետ համակարգի իրական հնարավորությունները՝ առանց սովորական օգտատերերի ներգրավման անհրաժեշտության: Ահա թե որտեղից է եկել այս ուսումնասիրությունը:
Երկրորդ կարևոր մոտեցումն այն է, որ հաճախորդն անմիջապես հավատարիմ մնաց պատշաճ մասշտաբավորմանը: Այստեղ դուք կարող եք գնել հավելյալ սերվեր և ավելացնել ֆերմա, օրինակ՝ 100 օգտատերերի համար, ամեն ինչ կանխատեսելի է օգտատիրոջ գնով։ Օրինակ, երբ նրանք պետք է ավելացնեն ևս 300 օգտատեր, նրանք կիմանան, որ իրենց անհրաժեշտ են երկու սերվեր արդեն սահմանված կազմաձևով, այլ ոչ թե վերանայեն իրենց ամբողջ ենթակառուցվածքի արդիականացումը:
Հետաքրքիր են HPE SimpliVity ֆեդերացիայի հնարավորությունները։ Բիզնեսը աշխարհագրորեն առանձնացված է, ուստի իմաստ ունի տեղադրել ձեր սեփական առանձին VDI սարքավորումը հեռավոր գրասենյակում: SimpliVity ֆեդերացիայում յուրաքանչյուր վիրտուալ մեքենա կրկնօրինակվում է ըստ ժամանակացույցի՝ աշխարհագրորեն հեռավոր կլաստերների միջև շատ արագ և առանց ալիքի վրա բեռի վերարտադրվելու ունակությամբ. սա շատ լավ մակարդակի ներկառուցված պահուստավորում է: Կայքերի միջև VM-ները կրկնելիս ալիքն օգտագործվում է հնարավորինս նվազագույն, և դա հնարավորություն է տալիս ստեղծել շատ հետաքրքիր DR ճարտարապետություններ մեկ կառավարման կենտրոնի և մի շարք ապակենտրոնացված պահեստավորման կայքերի առկայության դեպքում:
Այս ամենը միասին հնարավորություն է տալիս մանրամասնորեն գնահատել ֆինանսական կողմը և VDI-ի ծախսերը վերագրել ընկերության աճի ծրագրերին և հասկանալ, թե որքան արագ լուծումը կվճարի և ինչպես կաշխատի: Որովհետև ցանկացած VDI լուծում է, որն ի վերջո խնայում է շատ ռեսուրսներ, բայց միևնույն ժամանակ, ամենայն հավանականությամբ, առանց օգտագործման 5-7 տարվա ընթացքում այն փոխելու ծախսարդյունավետ հնարավորության:
Ընդհանուր առմամբ, եթե ունեք հարցեր, որոնք մեկնաբանության համար չեն, գրեք ինձ էլ [էլեկտրոնային փոստով պաշտպանված].
Source: www.habr.com