როგორ იმუშავებს HPE SimpliVity 380 VDI-სთვის: მძიმე დატვირთვის ტესტები

მომხმარებელს სურდა 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 Ghz.
• ოპერატიული მეხსიერება: 768 GB, 12 x 64 GB LRDIMMs DDR4 2666 MHz.
• ძირითადი დისკის კონტროლერი: HPE Smart Array P816i-a SR Gen10.
• მყარი დისკები: 9 x 1.92 TB SATA 6Gb/s SSD (RAID6 7+2 კონფიგურაციაში, ანუ ეს არის საშუალო მოდელი HPE SimpliVity თვალსაზრისით).
• ქსელის ბარათები: 4 x 1 გბ Eth (მომხმარებლის მონაცემები), 2 x 10 გბ Eth (SimpliVity და vMotion backend).
• სპეციალური ჩაშენებული FPGA ბარათები თითოეულ კვანძში დედუპლიკაციის/შეკუმშვისთვის.

კვანძები ერთმანეთთან დაკავშირებულია 10 გბ Ethernet-ის საშუალებით, უშუალოდ გარე გადამრთველის გარეშე, რომელიც გამოიყენება როგორც SimpliVity backend და ვირტუალური მანქანის მონაცემების გადასაცემად NFS-ის საშუალებით. ვირტუალური მანქანის მონაცემები კლასტერში ყოველთვის ასახულია ორ კვანძს შორის.

კვანძები გაერთიანებულია Vmware vSphere კლასტერში, რომელსაც მართავს vCenter.

ტესტირებისთვის განლაგდა დომენის კონტროლერი და Citrix კავშირის ბროკერი. დომენის კონტროლერი, ბროკერი და vCenter მოთავსებულია ცალკე კლასტერზე.


როგორც სატესტო ინფრასტრუქტურა, 300 ვირტუალური დესკტოპი განლაგდა Dedicated – Full Copy კონფიგურაციაში, ანუ თითოეული დესკტოპი არის ვირტუალური მანქანის ორიგინალური სურათის სრული ასლი და ინახავს მომხმარებლების მიერ განხორციელებულ ყველა ცვლილებას.

თითოეულ ვირტუალურ მანქანას აქვს 2vCPU და 4GB ოპერატიული მეხსიერება:

ვირტუალურ მანქანებზე დაინსტალირებული იყო ტესტირებისთვის საჭირო შემდეგი პროგრამული უზრუნველყოფა:

• Windows 10 (64-ბიტიანი), ვერსია 1809.
• Adobe Reader XI.
• Citrix Virtual Delivery Agent 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 Workers-ის მუშაობის გასააქტიურებლად და დატვირთვის მრავალფეროვნების გაზრდის მიზნით, LoginVSI კომპლექსს დაემატა Power Library დამატებითი ფაილების ბიბლიოთეკა. შედეგების განმეორებადობის უზრუნველსაყოფად, ყველა სატესტო სკამი პარამეტრი დარჩა ნაგულისხმევად.

ცოდნა და ძალაუფლების მუშაკთა ტესტები სიმულაციას უწევს ვირტუალურ სამუშაო სადგურებზე მომუშავე მომხმარებლების რეალურ დატვირთვას.

Storage მუშაკთა ტესტი შეიქმნა სპეციალურად მონაცემთა შენახვის სისტემების შესამოწმებლად, ის შორს არის რეალური დატვირთვისგან და ძირითადად გულისხმობს მომხმარებლის მუშაობას სხვადასხვა ზომის ფაილების დიდ რაოდენობასთან.

ტესტირების დროს, მომხმარებლები შედიან სამუშაო სადგურებში 48 წუთის განმავლობაში, დაახლოებით ერთი მომხმარებლის სიჩქარით ყოველ 10 წამში.

დასკვნები

LoginVSI ტესტირების მთავარი შედეგი არის VSImax მეტრიკა, რომელიც შედგენილია მომხმარებლის მიერ დაწყებული სხვადასხვა დავალების შესრულების დროიდან. მაგალითად: Notepad-ში ფაილის გახსნის დრო, 7-Zip-ში ფაილის შეკუმშვის დრო და ა.შ.

მეტრიკის გაანგარიშების დეტალური აღწერა ხელმისაწვდომია ოფიციალურ დოკუმენტაციაში ლინკები.

სხვა სიტყვებით რომ ვთქვათ, LoginVSI იმეორებს დატვირთვის ტიპურ შაბლონს, ახდენს მომხმარებლის მოქმედებების სიმულაციას საოფისე პაკეტში, კითხულობს PDF-ს და ა.შ. და ზომავს სხვადასხვა შეფერხებებს. არსებობს შეფერხებების კრიტიკული დონე „ყველაფერი ნელდება, მუშაობა შეუძლებელია“), მანამდე ითვლება, რომ მომხმარებელთა მაქსიმალური რაოდენობა არ არის მიღწეული. თუ პასუხის დრო 1 ms-ით უფრო სწრაფია, ვიდრე ეს „ყველაფერი ნელია“, მაშინ სისტემა ჩაითვლება ნორმალურად მომუშავეად და შეიძლება მეტი მომხმარებლის დამატება.

აქ არის ძირითადი მეტრიკა:

მეტრიკა

განხორციელებული ქმედებები

დეტალურად описание

დატვირთული კომპონენტები

ნ.ს.ლ.დ.

ტექსტის გახსნის დრო
ფაილი იწონის 1 KB

Notepad იხსნება და
ხსნის შემთხვევით 1 KB დოკუმენტს, რომელიც კოპირებულია აუზიდან
რესურსები

CPU და I/O

NFO

დიალოგის გახსნის დრო
ფანჯრები ნოუთბუქში

VSI-Notepad ფაილის გახსნა [Ctrl+O]

CPU, RAM და I/O

 

ZHC*

დროა შევქმნათ უაღრესად შეკუმშული Zip ფაილი

ადგილობრივი შეკუმშვა
შემთხვევითი 5MB .pst ფაილი კოპირებულია
რესურს ფონდი

CPU და I/O

ZLC*

დროა შევქმნათ სუსტად შეკუმშული Zip ფაილი

ადგილობრივი შეკუმშვა
შემთხვევითი 5MB .pst ფაილი კოპირებულია
რესურს ფონდი

I / O

 

CPU

დიდის გაანგარიშება
შემთხვევითი მონაცემთა მასივი

დიდი მასივის შექმნა
შემთხვევითი მონაცემები, რომლებიც გამოყენებული იქნება შეყვანის/გამოსვლის ტაიმერში (I/O ტაიმერი)

CPU

ტესტირების შესრულებისას თავდაპირველად გამოითვლება ძირითადი VSIbase მეტრიკა, რომელიც აჩვენებს სიჩქარეს, რომლითაც სამუშაოები შესრულებულია სისტემაზე დატვირთვის გარეშე. მასზე დაყრდნობით დგინდება VSImax Threshold, რომელიც უდრის VSIbase + 1ms.

სისტემის მუშაობის შესახებ დასკვნები მიიღება ორი მეტრიკის საფუძველზე: VSIbase, რომელიც განსაზღვრავს სისტემის სიჩქარეს და VSImax ბარიერი, რომელიც განსაზღვრავს მომხმარებელთა მაქსიმალურ რაოდენობას, რომელსაც სისტემა შეუძლია მნიშვნელოვანი დეგრადაციის გარეშე.

300 ცოდნის მუშაკების საორიენტაციო მაჩვენებელი

ცოდნის მუშაკები არიან მომხმარებლები, რომლებიც რეგულარულად იტვირთებენ მეხსიერებას, პროცესორს და IO-ს სხვადასხვა მცირე მწვერვალებით. პროგრამული უზრუნველყოფა ამსგავსებს მომთხოვნი ოფისის მომხმარებლების დატვირთვას, თითქოს ისინი მუდმივად რაღაცას ახდენენ (PDF, Java, საოფისე კომპლექტი, ფოტოების ყურება, 7-Zip). როგორც თქვენ დაამატებთ მომხმარებლებს ნულიდან 300-მდე, თითოეულის შეფერხება თანდათან იზრდება.

VSImax სტატისტიკის მონაცემები:

VSIbase = 986ms, VSI ბარიერი ვერ იქნა მიღწეული.

შენახვის სისტემის დატვირთვის სტატისტიკა SimpliVity მონიტორინგიდან:


ამ ტიპის დატვირთვით, სისტემას შეუძლია გაუძლოს გაზრდილ დატვირთვას შესრულების დეგრადაციის გარეშე. მომხმარებლის დავალებების შესრულების დრო შეუფერხებლად იზრდება, სისტემის პასუხის დრო არ იცვლება ტესტირების დროს და არის 3 ms-მდე წერისთვის და 1 ms-მდე წაკითხვისთვის.

დასკვნა: 300 ცოდნის მომხმარებელი მუშაობს მიმდინარე კლასტერზე უპრობლემოდ და არ ერევა ერთმანეთში, აღწევს pCPU/vCPU ზედმეტ გამოწერას 1-დან 6-მდე. მთლიანი შეფერხებები იზრდება თანაბრად დატვირთვის მატებასთან ერთად, მაგრამ დადგენილი ლიმიტი არ არის მიღწეული.

300 შემნახველი მუშაკი საორიენტაციო მაჩვენებელი

ესენი არიან მომხმარებლები, რომლებიც მუდმივად წერენ და კითხულობენ შესაბამისად 30-დან 70-მდე თანაფარდობით. ეს ტესტი ჩატარდა უფრო ექსპერიმენტების გულისთვის. VSImax სტატისტიკის მონაცემები:


VSIbase = 1673, VSI ბარიერი მიღწეულია 240 მომხმარებელზე.

შენახვის სისტემის დატვირთვის სტატისტიკა SimpliVity მონიტორინგიდან:

ამ ტიპის დატვირთვა არსებითად არის შენახვის სისტემის სტრეს ტესტი. როდესაც ის შესრულდება, თითოეული მომხმარებელი წერს სხვადასხვა ზომის მრავალ შემთხვევით ფაილს დისკზე. ამ შემთხვევაში, ჩანს, რომ როდესაც ზოგიერთი მომხმარებლისთვის გარკვეული დატვირთვის ზღვარი გადალახულია, ფაილების ჩაწერისთვის დავალებების შესრულების დრო იზრდება. ამავდროულად, დატვირთვა შენახვის სისტემაზე, პროცესორზე და ჰოსტების მეხსიერებაზე მნიშვნელოვნად არ იცვლება, ამიტომ ამჟამად შეუძლებელია ზუსტად დადგინდეს, თუ რა იწვევს შეფერხებებს.

ამ ტესტის გამოყენებით სისტემის მუშაობის შესახებ დასკვნები შეიძლება გაკეთდეს მხოლოდ სხვა სისტემების ტესტის შედეგებთან შედარებით, რადგან ასეთი დატვირთვები სინთეზური და არარეალურია. თუმცა, მთლიანობაში გამოცდამ კარგად ჩაიარა. ყველაფერი კარგად მიდიოდა 210 სესიამდე, შემდეგ კი დაიწყო უცნაური გამოხმაურებები, რომლებსაც ვერსად ადევნებდნენ თვალყურს Login VSI-ის გარდა.

300 ენერგეტიკის თანამშრომელი

ესენი არიან მომხმარებლები, რომლებსაც უყვართ CPU, მეხსიერება და მაღალი IO. ეს „ენერგიული მომხმარებლები“ ​​რეგულარულად ასრულებენ რთულ ამოცანებს ხანგრძლივი აურზაურით, როგორიცაა ახალი პროგრამული უზრუნველყოფის ინსტალაცია და დიდი არქივების ამოხსნა. VSImax სტატისტიკის მონაცემები:


VSIbase = 970, VSI ბარიერი ვერ იქნა მიღწეული.

შენახვის სისტემის დატვირთვის სტატისტიკა SimpliVity მონიტორინგიდან:


ტესტირების დროს, პროცესორის დატვირთვის ზღვარი მიღწეული იქნა სისტემის ერთ-ერთ კვანძზე, მაგრამ ამას მნიშვნელოვანი გავლენა არ მოუხდენია მის მუშაობაზე:

ამ შემთხვევაში, სისტემას შეუძლია გაუძლოს გაზრდილ დატვირთვას შესრულების მნიშვნელოვანი დეგრადაციის გარეშე. მომხმარებლის დავალებების შესრულების დრო შეუფერხებლად იზრდება, სისტემის პასუხის დრო არ იცვლება ტესტირების დროს და არის 3 ms-მდე წერისთვის და 1 ms-მდე წაკითხვისთვის.

რეგულარული ტესტები არ იყო საკმარისი მომხმარებლისთვის და ჩვენ უფრო შორს წავედით: გავზარდეთ 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 ზედნადები დააწესა ვირტუალურ მანქანებზე. ამან გამოიწვია მასპინძლების პროცესორის სწრაფი გადატვირთვა და დიდად იმოქმედა მთლიანად სისტემის მუშაობაზე.

მასპინძელი CPU დატვირთვა:




ამავდროულად, ბუნებრივად გაიზარდა შენახვის სისტემის შეფერხებები:


გამოთვლითი სიმძლავრის ნაკლებობა კრიტიკული გახდა დაახლოებით 240 მომხმარებლისთვის:


მიღებული შედეგებიდან გამომდინარე, გადაწყდა ტესტირების ჩატარება, რომელიც ნაკლებად ინტენსიური იყო CPU.

230 ოფისის თანამშრომელი + 22 IOPS თითო მომხმარებლისთვის

CPU-ზე დატვირთვის შესამცირებლად შეირჩა Office მუშაკთა დატვირთვის ტიპი და ყოველ სესიაზე ასევე დაემატა 22 IOPS სინთეზური დატვირთვა.

ტესტი შემოიფარგლებოდა 230 სესიით, რათა არ აღემატებოდეს CPU-ს მაქსიმალურ დატვირთვას.

ტესტი ჩატარდა მომხმარებლებთან ერთად, რომლებიც მუშაობდნენ 10 საათის განმავლობაში, რათა შეემოწმებინათ სისტემის სტაბილურობა გრძელვადიანი მუშაობის დროს მაქსიმალურ დატვირთვასთან ახლოს.

VSImax სტატისტიკის მონაცემები:


VSIbase = 918 ms, VSI ბარიერი არ იქნა მიღწეული.

VSImax დეტალური სტატისტიკის მონაცემები:


გრაფიკი აჩვენებს, რომ არ შეინიშნება შესრულების დეგრადაცია მთელი ტესტის განმავლობაში.

CPU დატვირთვის სტატისტიკა:




ამ ტესტის შესრულებისას ჰოსტების 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 წლის განმავლობაში მისი შეცვლის ეკონომიური შესაძლებლობის გარეშე.

ზოგადად, თუ თქვენ გაქვთ რაიმე შეკითხვა, რომელიც არ არის კომენტარისთვის, მომწერეთ ელექტრონული ფოსტით [ელ.ფოსტით დაცულია].

წყარო: www.habr.com