HPE SimpliVity 380 ສໍາລັບ VDI ຈະເຮັດວຽກແນວໃດ: ການທົດສອບການໂຫຼດທີ່ເຄັ່ງຄັດ

ລູກຄ້າຕ້ອງການ VDI. ຂ້ອຍເບິ່ງການປະສົມປະສານຂອງ SimpliVity + VDI Citrix Virtual Desktop. ສໍາລັບຜູ້ປະກອບການທັງຫມົດ, ພະນັກງານຫ້ອງການເມືອງ, ແລະອື່ນໆ. ມີຫ້າພັນຜູ້ໃຊ້ຢູ່ໃນຄື້ນທໍາອິດຂອງການເຄື່ອນຍ້າຍຢ່າງດຽວ, ແລະດັ່ງນັ້ນເຂົາເຈົ້າໄດ້ insisted ໃນການທົດສອບການໂຫຼດ. VDI ສາມາດເລີ່ມຕົ້ນຊ້າລົງ, ມັນສາມາດສະຫງົບລົງໄດ້ - ແລະນີ້ບໍ່ໄດ້ເກີດຂື້ນເລື້ອຍໆຍ້ອນບັນຫາກັບຊ່ອງທາງ. ພວກເຮົາໄດ້ຊື້ຊຸດການທົດສອບທີ່ມີປະສິດທິພາບຫຼາຍໂດຍສະເພາະສໍາລັບ VDI ແລະໂຫລດໂຄງສ້າງພື້ນຖານຈົນກ່ວາມັນຫນັກເກີນໄປໃນແຜ່ນແລະໂປເຊດເຊີ.

ດັ່ງນັ້ນ, ພວກເຮົາຈະຕ້ອງການຂວດພາດສະຕິກແລະຊອບແວ LoginVSI ສໍາລັບການທົດສອບ VDI ທີ່ຊັບຊ້ອນ. ພວກເຮົາມີມັນດ້ວຍໃບອະນຸຍາດສໍາລັບຜູ້ໃຊ້ 300 ຄົນ. ຫຼັງຈາກນັ້ນ, ພວກເຮົາໄດ້ເອົາຮາດແວ HPE SimpliVity 380 ໃນຊຸດທີ່ເຫມາະສົມສໍາລັບວຽກງານຂອງຄວາມຫນາແຫນ້ນຂອງຜູ້ໃຊ້ສູງສຸດຕໍ່ເຄື່ອງແມ່ຂ່າຍ, ຕັດເຄື່ອງ virtual ດ້ວຍການສະຫມັກທີ່ດີ, ຕິດຕັ້ງຊອບແວຫ້ອງການໃນ Win10 ແລະເລີ່ມຕົ້ນການທົດສອບ.

ໃຫ້ໄປ!

ລະບົບ

ສອງ HPE SimpliVity 380 Gen10 nodes (ເຊີບເວີ). ໃນແຕ່ລະ:

• 2 x Intel Xeon Platinum 8170 26c 2.1Ghz.
• RAM: 768GB, 12 x 64GB LRDIMMs DDR4 2666MHz.
• ຕົວຄວບຄຸມແຜ່ນຫຼັກ: HPE Smart Array P816i-a SR Gen10.
• ຮາດດິດ: 9 x 1.92 TB SATA 6Gb/s SSD (ໃນການຕັ້ງຄ່າ RAID6 7+2, i.e. ນີ້ແມ່ນຮູບແບບຂະຫນາດກາງໃນເງື່ອນໄຂ HPE SimpliVity).
• ບັດເຄືອຂ່າຍ: 4 x 1Gb Eth (ຂໍ້ມູນຜູ້ໃຊ້), 2 x 10Gb Eth (SimpliVity ແລະ vMotion backend).
• ບັດ FPGA ທີ່ມີໃນຕົວພິເສດໃນແຕ່ລະ node ສໍາລັບ deduplication / compression.

nodes ແມ່ນເຊື່ອມຕໍ່ຫາກັນໂດຍຜ່ານ 10Gb Ethernet interconnect ໂດຍກົງໂດຍບໍ່ມີການສະຫຼັບພາຍນອກ, ເຊິ່ງຖືກນໍາໃຊ້ເປັນ backend SimpliVity ແລະສໍາລັບການໂອນຂໍ້ມູນ virtual machine ຜ່ານ NFS. ຂໍ້ມູນເຄື່ອງສະເໝືອນຢູ່ໃນກຸ່ມແມ່ນສະທ້ອນຢູ່ສະເໝີລະຫວ່າງສອງ nodes.

ໂນດຖືກລວມເຂົ້າເປັນກຸ່ມ Vmware vSphere ທີ່ຈັດການໂດຍ vCenter.

ສໍາລັບການທົດສອບ, ຕົວຄວບຄຸມໂດເມນແລະນາຍຫນ້າການເຊື່ອມຕໍ່ Citrix ໄດ້ຖືກນໍາໄປໃຊ້. ຕົວຄວບຄຸມໂດເມນ, ນາຍຫນ້າແລະ vCenter ແມ່ນຖືກຈັດໃສ່ຢູ່ໃນກຸ່ມແຍກຕ່າງຫາກ.


ໃນຖານະເປັນໂຄງສ້າງພື້ນຖານການທົດສອບ, 300 ເດັສທັອບ virtual ໄດ້ຖືກນໍາມາໃຊ້ໃນການຕັ້ງຄ່າ Dedicated – Full Copy, i.e., ແຕ່ລະ desktop ແມ່ນສໍາເນົາທີ່ສົມບູນຂອງຮູບພາບຕົ້ນສະບັບຂອງ virtual machine ແລະບັນທຶກການປ່ຽນແປງທັງຫມົດທີ່ເຮັດໂດຍຜູ້ໃຊ້.

ແຕ່ລະເຄື່ອງ virtual ມີ 2vCPU ແລະ 4GB RAM:

ຊອບ​ແວ​ຕໍ່​ໄປ​ນີ້​ທີ່​ຕ້ອງ​ການ​ສໍາ​ລັບ​ການ​ທົດ​ສອບ​ໄດ້​ຖືກ​ຕິດ​ຕັ້ງ​ຢູ່​ໃນ​ເຄື່ອງ virtual​:

• Windows 10 (64-bit), ຮຸ່ນ 1809.
• Adobe Reader XI.
• Citrix Virtual Delivery Agent 1811.1.
• Doro PDF 1.82.
• Java 7 ອັບເດດ 13.
• Microsoft Office Professional Plus 2016.

ລະຫວ່າງ nodes - synchronous replication. ແຕ່ລະບລັອກຂໍ້ມູນໃນກຸ່ມມີສອງສຳເນົາ. ນັ້ນແມ່ນ, ໃນປັດຈຸບັນມີຊຸດຂໍ້ມູນຄົບຖ້ວນສົມບູນໃນແຕ່ລະຂໍ້. ດ້ວຍກຸ່ມຂອງສາມຫຼືຫຼາຍກວ່ານັ້ນ, ສໍາເນົາຂອງທ່ອນໄມ້ຢູ່ໃນສອງບ່ອນທີ່ແຕກຕ່າງກັນ. ເມື່ອສ້າງ VM ໃໝ່, ສຳເນົາເພີ່ມເຕີມແມ່ນສ້າງຢູ່ໃນໜຶ່ງໃນກຸ່ມຂອງກຸ່ມ. ເມື່ອຫນຶ່ງ node ລົ້ມເຫລວ, VMs ທັງຫມົດທີ່ເຮັດວຽກໃນເມື່ອກ່ອນມັນຈະຖືກ restarted ໂດຍອັດຕະໂນມັດໃນ nodes ອື່ນໆທີ່ພວກເຂົາມີ replicas. ຖ້າ node ລົ້ມເຫລວເປັນເວລາດົນນານ, ການຟື້ນຟູເທື່ອລະກ້າວຂອງການຊ້ໍາຊ້ອນເລີ່ມຕົ້ນ, ແລະ cluster ກັບໄປ N+1 redundancy.

ການດຸ່ນດ່ຽງຂໍ້ມູນແລະການເກັບຮັກສາເກີດຂື້ນໃນລະດັບການເກັບຮັກສາຊອບແວຂອງ SimpliVity ຕົວຂອງມັນເອງ.

ເຄື່ອງຈັກສະເໝືອນແລ່ນກຸ່ມ virtualization, ເຊິ່ງວາງພວກມັນໄວ້ໃນບ່ອນເກັບຂໍ້ມູນຊອບແວ. ໂຕະເຮັດວຽກເອງໄດ້ຖືກປະຕິບັດຕາມແມ່ແບບມາດຕະຖານ: ໂຕະຂອງນັກການເງິນແລະເຈົ້າຫນ້າທີ່ປະຕິບັດງານມາສໍາລັບການທົດສອບ (ເຫຼົ່ານີ້ແມ່ນສອງແມ່ແບບທີ່ແຕກຕ່າງກັນ).

ການທົດສອບ

ສໍາລັບການທົດສອບ, ຊຸດທົດສອບຊອບແວ LoginVSI 4.1 ໄດ້ຖືກນໍາໃຊ້. ສະລັບສັບຊ້ອນ LoginVSI, ປະກອບດ້ວຍເຄື່ອງແມ່ຂ່າຍຄວບຄຸມແລະ 12 ເຄື່ອງສໍາລັບການເຊື່ອມຕໍ່ການທົດສອບ, ໄດ້ຖືກນໍາໄປໃຊ້ໃນເຈົ້າພາບທາງດ້ານຮ່າງກາຍແຍກຕ່າງຫາກ.


ການ​ທົດ​ສອບ​ໄດ້​ປະ​ຕິ​ບັດ​ໃນ​ສາມ​ຮູບ​ແບບ​:

ໂຫມດ Benchmark - ກໍລະນີການໂຫຼດ 300 ພະນັກງານຄວາມຮູ້ແລະ 300 ພະນັກງານເກັບຮັກສາ.

ຮູບແບບມາດຕະຖານ - ກໍລະນີການໂຫຼດ 300 ພະນັກງານພະລັງງານ.

ເພື່ອເຮັດໃຫ້ພະນັກງານພະລັງງານສາມາດເຮັດວຽກໄດ້ ແລະເພີ່ມຄວາມຫຼາກຫຼາຍຂອງການໂຫຼດ, ຫ້ອງສະໝຸດຂອງໄຟລ໌ Power Library ເພີ່ມເຕີມໄດ້ຖືກເພີ່ມໃສ່ LoginVSI complex. ເພື່ອຮັບປະກັນຄວາມຊໍ້າຄືນຂອງຜົນໄດ້ຮັບ, ການຕັ້ງຄ່າເບດທົດສອບທັງໝົດຖືກປະໄວ້ເປັນຄ່າເລີ່ມຕົ້ນ.

ການທົດສອບຜູ້ອອກແຮງງານຄວາມຮູ້ແລະພະລັງງານຈໍາລອງວຽກທີ່ແທ້ຈິງຂອງຜູ້ໃຊ້ທີ່ເຮັດວຽກຢູ່ໃນສະຖານີເຮັດວຽກ virtual.

ການທົດສອບພະນັກງານເກັບຮັກສາໄດ້ຖືກສ້າງຂື້ນໂດຍສະເພາະສໍາລັບການທົດສອບລະບົບການເກັບຮັກສາຂໍ້ມູນ; ມັນຢູ່ໄກຈາກການເຮັດວຽກທີ່ແທ້ຈິງແລະສ່ວນໃຫຍ່ແມ່ນກ່ຽວຂ້ອງກັບຜູ້ໃຊ້ທີ່ເຮັດວຽກກັບໄຟລ໌ຈໍານວນຫລາຍທີ່ມີຂະຫນາດທີ່ແຕກຕ່າງກັນ.

ໃນ​ລະ​ຫວ່າງ​ການ​ທົດ​ສອບ, ຜູ້​ໃຊ້​ເຂົ້າ​ສູ່​ລະ​ບົບ​ສະ​ຖາ​ນີ​ເຮັດ​ວຽກ​ສໍາ​ລັບ 48 ນາ​ທີ​ໃນ​ອັດ​ຕາ​ຂອງ​ຜູ້​ໃຊ້​ປະ​ມານ​ຫນຶ່ງ​ໃນ​ທຸກໆ 10 ວິ​ນາ​ທີ.

Результаты

ຜົນໄດ້ຮັບຕົ້ນຕໍຂອງການທົດສອບ LoginVSI ແມ່ນ VSImax metric, ເຊິ່ງລວບລວມຈາກເວລາປະຕິບັດຂອງວຽກງານຕ່າງໆທີ່ຜູ້ໃຊ້ເປີດຕົວ. ຕົວຢ່າງ: ເວລາທີ່ຈະເປີດໄຟລ໌ໃນ Notepad, ເວລາທີ່ຈະບີບອັດໄຟລ໌ໃນ 7-Zip, ແລະອື່ນໆ.

ລາຍລະອຽດຂອງການຄິດໄລ່ metrics ແມ່ນມີຢູ່ໃນເອກະສານທາງການສໍາລັບ ການເຊື່ອມຕໍ່.

ໃນຄໍາສັບຕ່າງໆອື່ນໆ, LoginVSI ເຮັດຊ້ໍາຮູບແບບການໂຫຼດປົກກະຕິ, ການຈໍາລອງການກະທໍາຂອງຜູ້ໃຊ້ໃນຊຸດຫ້ອງການ, ອ່ານ PDF, ແລະອື່ນໆ, ແລະວັດແທກ latencies ຕ່າງໆ. ມີຄວາມລ່າຊ້າໃນລະດັບທີ່ສໍາຄັນ "ທຸກສິ່ງທຸກຢ່າງຊ້າລົງ, ມັນເປັນໄປບໍ່ໄດ້ທີ່ຈະເຮັດວຽກ"), ກ່ອນທີ່ຈະພິຈາລະນາວ່າຈໍານວນຜູ້ໃຊ້ສູງສຸດຍັງບໍ່ທັນໄດ້ບັນລຸ. ຖ້າເວລາຕອບສະຫນອງແມ່ນ 1 ms ໄວກ່ວາ "ທຸກສິ່ງທຸກຢ່າງແມ່ນຊ້າ", ລະບົບຖືວ່າເຮັດວຽກເປັນປົກກະຕິ, ແລະຜູ້ໃຊ້ສາມາດເພີ່ມໄດ້.

ນີ້ແມ່ນຕົວຊີ້ວັດຕົ້ນຕໍ:

ວັດແທກ

ປະຕິບັດ

ລະອຽດ ຄໍາອະທິບາຍ

ອົງປະກອບທີ່ໂຫລດ

N.S.L.D.

ເວລາເປີດຂໍ້ຄວາມ
ໄຟລ໌ທີ່ມີນໍ້າໜັກ 1 KB

Notepad ເປີດແລະ
ເປີດເອກະສານ 1 KB ແບບສຸ່ມທີ່ຄັດລອກມາຈາກສະນຸກເກີ
ຊັບພະຍາກອນ

CPU ແລະ I/O

NFO

ເວລາເປີດການສົນທະນາ
windows ໃນ notepad

ການເປີດໄຟລ໌ VSI-Notepad [Ctrl+O]

CPU, RAM ແລະ I/O

 

ZHC*

ເວລາທີ່ຈະສ້າງໄຟລ໌ Zip ທີ່ຖືກບີບອັດສູງ

ການບີບອັດທ້ອງຖິ່ນ
ໄຟລ໌ .pst 5MB ແບບສຸ່ມທີ່ຄັດລອກມາຈາກ
ຊັບ​ພະ​ຍາ​ກອນ​

CPU ແລະ I/O

ZLC*

ເວລາທີ່ຈະສ້າງໄຟລ໌ Zip ທີ່ຖືກບີບອັດອ່ອນໆ

ການບີບອັດທ້ອງຖິ່ນ
ໄຟລ໌ .pst 5MB ແບບສຸ່ມທີ່ຄັດລອກມາຈາກ
ຊັບ​ພະ​ຍາ​ກອນ​

ຂ້າພະເຈົ້າ / O

 

CPU

ການ​ຄິດ​ໄລ່​ໃຫຍ່​
array ຂໍ້ມູນແບບສຸ່ມ

ການສ້າງ Array ໃຫຍ່
ຂໍ້ມູນແບບສຸ່ມທີ່ຈະໃຊ້ໃນຕົວຈັບເວລາປ້ອນ/ອອກ (ຕົວຈັບເວລາ I/O)

CPU

ເມື່ອການທົດສອບຖືກປະຕິບັດ, ຕົວຊີ້ວັດພື້ນຖານ VSIbase ໄດ້ຖືກຄິດໄລ່ໃນເບື້ອງຕົ້ນ, ເຊິ່ງສະແດງໃຫ້ເຫັນເຖິງຄວາມໄວທີ່ວຽກຖືກປະຕິບັດໂດຍບໍ່ມີການໂຫຼດຢູ່ໃນລະບົບ. ອີງຕາມມັນ, VSImax Threshold ຖືກກໍານົດ, ເຊິ່ງເທົ່າກັບ VSIbase + 1ms.

ບົດສະຫຼຸບກ່ຽວກັບການປະຕິບັດລະບົບແມ່ນອີງໃສ່ສອງຕົວຊີ້ບອກ: VSIbase, ເຊິ່ງກໍານົດຄວາມໄວຂອງລະບົບ, ແລະ VSImax threshold, ເຊິ່ງກໍານົດຈໍານວນຜູ້ໃຊ້ສູງສຸດທີ່ລະບົບສາມາດຈັດການໄດ້ໂດຍບໍ່ມີການຊຸດໂຊມທີ່ສໍາຄັນ.

300 ມາດຕະຖານພະນັກງານຄວາມຮູ້

ພະນັກງານຄວາມຮູ້ແມ່ນຜູ້ໃຊ້ທີ່ໂຫຼດຫນ່ວຍຄວາມຈໍາ, ໂປເຊດເຊີແລະ IO ເປັນປະຈໍາທີ່ມີຈຸດສູງສຸດຂະຫນາດນ້ອຍຕ່າງໆ. ຊອບແວໄດ້ຈຳລອງວຽກຂອງຜູ້ໃຊ້ຫ້ອງການທີ່ຕ້ອງການ, ຄືກັບວ່າເຂົາເຈົ້າກຳລັງຈົ່ມບາງອັນຢູ່ສະເໝີ (PDF, Java, office suite, photo viewing, 7-Zip). ໃນຂະນະທີ່ທ່ານເພີ່ມຜູ້ໃຊ້ຈາກສູນເຖິງ 300, ຄວາມລ່າຊ້າຂອງແຕ່ລະຄົນຈະເພີ່ມຂຶ້ນເທື່ອລະກ້າວ.

ຂໍ້ມູນສະຖິຕິ VSImax:

VSIbase = 986ms, VSI Threshold ບໍ່ຮອດ.

ສະຖິຕິການໂຫຼດລະບົບການເກັບຮັກສາຈາກການຕິດຕາມ SimpliVity:


ດ້ວຍປະເພດຂອງການໂຫຼດນີ້, ລະບົບສາມາດທົນກັບການໂຫຼດເພີ່ມຂຶ້ນໂດຍເກືອບບໍ່ມີການເຊື່ອມໂຊມໃນການປະຕິບັດ. ເວລາທີ່ມັນໃຊ້ເວລາເພື່ອເຮັດສໍາເລັດວຽກງານຂອງຜູ້ໃຊ້ເພີ່ມຂຶ້ນຢ່າງລຽບງ່າຍ, ເວລາຕອບສະຫນອງຂອງລະບົບບໍ່ປ່ຽນແປງໃນລະຫວ່າງການທົດສອບແລະສູງເຖິງ 3 ms ສໍາລັບການຂຽນແລະສູງເຖິງ 1 ms ສໍາລັບການອ່ານ.

ສະຫຼຸບ: ຜູ້ໃຊ້ຄວາມຮູ້ 300 ເຮັດວຽກຢູ່ໃນກຸ່ມປະຈຸບັນໂດຍບໍ່ມີບັນຫາໃດໆແລະບໍ່ແຊກແຊງເຊິ່ງກັນແລະກັນ, ເຖິງ pCPU / vCPU oversubscription 1 ຫາ 6. ຄວາມລ່າຊ້າໂດຍລວມເຕີບໂຕເທົ່າທຽມກັນຍ້ອນວ່າການໂຫຼດເພີ່ມຂຶ້ນ, ແຕ່ຂອບເຂດທີ່ກໍານົດໄວ້ຍັງບໍ່ທັນໄດ້ບັນລຸ.

300 ມາດຕະຖານພະນັກງານເກັບຮັກສາ

ເຫຼົ່ານີ້ແມ່ນຜູ້ໃຊ້ທີ່ຂຽນແລະອ່ານຢ່າງຕໍ່ເນື່ອງໃນອັດຕາສ່ວນ 30 ຫາ 70, ຕາມລໍາດັບ. ການທົດສອບນີ້ໄດ້ຖືກປະຕິບັດຫຼາຍສໍາລັບ sake ຂອງການທົດລອງ. ຂໍ້ມູນສະຖິຕິ VSImax:


VSIbase = 1673, VSI Threshold ບັນລຸຜູ້ໃຊ້ 240 ຄົນ.

ສະຖິຕິການໂຫຼດລະບົບການເກັບຮັກສາຈາກການຕິດຕາມ SimpliVity:

ປະເພດຂອງການໂຫຼດນີ້ແມ່ນເປັນການທົດສອບຄວາມກົດດັນຂອງລະບົບການເກັບຮັກສາ. ເມື່ອມັນຖືກປະຕິບັດ, ຜູ້ໃຊ້ແຕ່ລະຄົນຂຽນໄຟລ໌ແບບສຸ່ມຈໍານວນຫຼາຍທີ່ມີຂະຫນາດທີ່ແຕກຕ່າງກັນໃສ່ແຜ່ນ. ໃນກໍລະນີນີ້, ມັນສາມາດເຫັນໄດ້ວ່າເມື່ອຂອບເຂດການໂຫຼດທີ່ແນ່ນອນແມ່ນເກີນສໍາລັບຜູ້ໃຊ້ບາງຄົນ, ເວລາທີ່ມັນໃຊ້ເວລາເພື່ອເຮັດສໍາເລັດວຽກງານສໍາລັບການຂຽນໄຟລ໌ເພີ່ມຂຶ້ນ. ໃນຂະນະດຽວກັນ, ການໂຫຼດໃນລະບົບການເກັບຮັກສາ, ໂປເຊດເຊີແລະຫນ່ວຍຄວາມຈໍາຂອງເຈົ້າພາບບໍ່ມີການປ່ຽນແປງຢ່າງຫຼວງຫຼາຍ, ດັ່ງນັ້ນໃນປັດຈຸບັນມັນບໍ່ສາມາດກໍານົດໄດ້ຢ່າງແທ້ຈິງວ່າສິ່ງທີ່ເຮັດໃຫ້ເກີດຄວາມຊັກຊ້າ.

ການສະຫຼຸບກ່ຽວກັບການປະຕິບັດລະບົບໂດຍໃຊ້ການທົດສອບນີ້ສາມາດເຮັດໄດ້ພຽງແຕ່ເມື່ອປຽບທຽບກັບຜົນການທົດສອບໃນລະບົບອື່ນໆ, ເນື່ອງຈາກວ່າການໂຫຼດດັ່ງກ່າວແມ່ນສັງເຄາະແລະບໍ່ສົມຈິງ. ຢ່າງໃດກໍຕາມ, ໂດຍລວມ, ການທົດສອບໄດ້ດີ. ທຸກສິ່ງທຸກຢ່າງໄດ້ດີຈົນກ່ວາ 210 ຮອບ, ແລະຫຼັງຈາກນັ້ນການຕອບໂຕ້ທີ່ແປກປະຫຼາດໄດ້ເລີ່ມຕົ້ນ, ເຊິ່ງບໍ່ໄດ້ຕິດຕາມຢູ່ບ່ອນໃດກໍ່ຕາມ, ຍົກເວັ້ນການເຂົ້າສູ່ລະບົບ VSI.

ພະນັກງານໄຟຟ້າ 300 ຄົນ

ເຫຼົ່ານີ້ແມ່ນຜູ້ໃຊ້ທີ່ຮັກ CPU, ຫນ່ວຍຄວາມຈໍາແລະ IO ສູງ. "ຜູ້ໃຊ້ພະລັງງານ" ເຫຼົ່ານີ້ເປັນປົກກະຕິເຮັດວຽກທີ່ສັບສົນດ້ວຍການລະເບີດທີ່ຍາວນານ, ເຊັ່ນ: ການຕິດຕັ້ງຊອບແວໃຫມ່ແລະ unpacking ແຟ້ມຂະຫນາດໃຫຍ່. ຂໍ້ມູນສະຖິຕິ VSImax:


VSIbase = 970, VSI Threshold ບໍ່ຮອດ.

ສະຖິຕິການໂຫຼດລະບົບການເກັບຮັກສາຈາກການຕິດຕາມ SimpliVity:


ໃນລະຫວ່າງການທົດສອບ, ລະດັບການໂຫຼດຂອງໂປເຊດເຊີໄດ້ບັນລຸຢູ່ໃນຫນຶ່ງຂອງ nodes ຂອງລະບົບ, ແຕ່ນີ້ບໍ່ໄດ້ມີຜົນກະທົບຢ່າງຫຼວງຫຼາຍຕໍ່ການເຮັດວຽກຂອງມັນ:

ໃນກໍລະນີນີ້, ລະບົບສາມາດທົນກັບການໂຫຼດທີ່ເພີ່ມຂຶ້ນໂດຍບໍ່ມີການເສື່ອມໂຊມປະສິດທິພາບທີ່ສໍາຄັນ. ເວລາທີ່ມັນໃຊ້ເວລາເພື່ອເຮັດສໍາເລັດວຽກງານຂອງຜູ້ໃຊ້ເພີ່ມຂຶ້ນຢ່າງລຽບງ່າຍ, ເວລາຕອບສະຫນອງຂອງລະບົບບໍ່ປ່ຽນແປງໃນລະຫວ່າງການທົດສອບແລະສູງເຖິງ 3 ms ສໍາລັບການຂຽນແລະສູງເຖິງ 1 ms ສໍາລັບການອ່ານ.

ການທົດສອບປົກກະຕິບໍ່ພຽງພໍສໍາລັບລູກຄ້າ, ແລະພວກເຮົາໄດ້ໄປຕື່ມອີກ: ພວກເຮົາໄດ້ເພີ່ມຄຸນລັກສະນະ VM (ຈໍານວນຂອງ vCPUs ເພື່ອປະເມີນການເພີ່ມຂຶ້ນຂອງການຈອງເກີນແລະຂະຫນາດແຜ່ນ) ແລະເພີ່ມການໂຫຼດເພີ່ມເຕີມ.

ໃນເວລາເຮັດການທົດສອບເພີ່ມເຕີມ, ການຕັ້ງຄ່າຂາຕັ້ງຕໍ່ໄປນີ້ໄດ້ຖືກນໍາໃຊ້:
300 ເດັສທັອບສະເໝືອນຖືກນຳໃຊ້ໃນ 4vCPU, RAM 4GB, ການຕັ້ງຄ່າ HDD 80GB.

ການ​ຕັ້ງ​ຄ່າ​ຂອງ​ຫນຶ່ງ​ໃນ​ເຄື່ອງ​ທົດ​ສອບ​:


ເຄື່ອງໄດ້ຖືກນໍາໄປໃຊ້ໃນທາງເລືອກທີ່ອຸທິດຕົນ - ເຕັມຮູບແບບ:

ມາດຕະຖານພະນັກງານຄວາມຮູ້ 300 ຄົນທີ່ມີການສະໝັກສະມາຊິກເກີນ 12

ຂໍ້ມູນສະຖິຕິ VSImax:


VSIbase = 921 ms, VSI Threshold ບໍ່ຮອດ.

ສະຖິຕິການໂຫຼດລະບົບການເກັບຮັກສາຈາກການຕິດຕາມ SimpliVity:


ຜົນໄດ້ຮັບແມ່ນຄ້າຍຄືກັນກັບການທົດສອບການຕັ້ງຄ່າ VM ທີ່ຜ່ານມາ.

ພະ​ນັກ​ງານ​ພະ​ລັງ​ງານ 300 ທີ່​ມີ 12 oversubscriptions​

ຂໍ້ມູນສະຖິຕິ VSImax:


VSIbase = 933, VSI Threshold ບໍ່ຮອດ.

ສະຖິຕິການໂຫຼດລະບົບການເກັບຮັກສາຈາກການຕິດຕາມ SimpliVity:


ໃນ​ລະ​ຫວ່າງ​ການ​ທົດ​ສອບ​ນີ້​, ໄດ້​ບັນ​ລຸ​ເປົ້າ​ຫມາຍ​ການ​ໂຫຼດ​ຂອງ​ໂປ​ເຊດ​ເຊີ​ໄດ້​, ແຕ່​ວ່າ​ນີ້​ບໍ່​ໄດ້​ມີ​ຜົນ​ກະ​ທົບ​ທີ່​ສໍາ​ຄັນ​ຕໍ່​ການ​ປະ​ຕິ​ບັດ​:

ຜົນໄດ້ຮັບແມ່ນຄ້າຍຄືກັນກັບການທົດສອບການຕັ້ງຄ່າທີ່ຜ່ານມາ.

ຈະເກີດຫຍັງຂຶ້ນກັບການໂຫຼດເປັນເວລາ 10 ຊົ່ວໂມງ?

ຕອນນີ້ໃຫ້ເບິ່ງວ່າຈະມີ "ຜົນກະທົບສະສົມ" ແລະດໍາເນີນການທົດສອບເປັນເວລາ 10 ຊົ່ວໂມງຕິດຕໍ່ກັນ.

ການທົດສອບໄລຍະຍາວແລະລາຍລະອຽດຂອງພາກສ່ວນຄວນຈະມີຈຸດປະສົງໃນຄວາມຈິງທີ່ວ່າພວກເຮົາຕ້ອງການທີ່ຈະກວດສອບວ່າບັນຫາໃດໆທີ່ຈະເກີດຂຶ້ນກັບ truss ພາຍໃຕ້ການໂຫຼດ prolonged ສຸດມັນ.

300 ມາດຕະຖານພະນັກງານຄວາມຮູ້ + 10 ຊົ່ວໂມງ

ນອກຈາກນັ້ນ, ກໍລະນີການໂຫຼດຂອງພະນັກງານຄວາມຮູ້ 300 ຄົນໄດ້ຖືກທົດສອບ, ຕິດຕາມດ້ວຍການເຮັດວຽກຂອງຜູ້ໃຊ້ເປັນເວລາ 10 ຊົ່ວໂມງ.

ຂໍ້ມູນສະຖິຕິ VSImax:


VSIbase = 919 ms, VSI Threshold ບໍ່ຮອດ.

VSImax ຂໍ້ມູນສະຖິຕິລະອຽດ:


ເສັ້ນສະແດງສະແດງໃຫ້ເຫັນວ່າບໍ່ມີການເສື່ອມໂຊມການປະຕິບັດທີ່ສັງເກດເຫັນຕະຫຼອດການທົດສອບທັງຫມົດ.

ສະຖິຕິການໂຫຼດລະບົບການເກັບຮັກສາຈາກການຕິດຕາມ SimpliVity:


ການປະຕິບັດລະບົບການເກັບຮັກສາຍັງຄົງຄືກັນຕະຫຼອດການທົດສອບ.

ການທົດສອບເພີ່ມເຕີມດ້ວຍການເພີ່ມການໂຫຼດສັງເຄາະ

ລູກຄ້າໄດ້ຮ້ອງຂໍໃຫ້ເພີ່ມການໂຫຼດທໍາມະຊາດໃສ່ແຜ່ນ. ເພື່ອເຮັດສິ່ງນີ້, ວຽກງານໄດ້ຖືກເພີ່ມເຂົ້າໃນລະບົບການເກັບຮັກສາໃນແຕ່ລະເຄື່ອງ virtual ຂອງຜູ້ໃຊ້ເພື່ອດໍາເນີນການໂຫຼດສັງເຄາະຢູ່ໃນແຜ່ນເມື່ອຜູ້ໃຊ້ເຂົ້າສູ່ລະບົບ. ການໂຫຼດໄດ້ຖືກສະຫນອງໃຫ້ໂດຍ fio utility, ເຊິ່ງຊ່ວຍໃຫ້ທ່ານສາມາດຈໍາກັດການໂຫຼດໃນແຜ່ນໂດຍຈໍານວນຂອງ IOPS. ໃນແຕ່ລະເຄື່ອງຈັກ, ວຽກງານໄດ້ຖືກເປີດຕົວເພື່ອເປີດຕົວການໂຫຼດເພີ່ມເຕີມໃນຈໍານວນ 22 IOPS 70% / 30% Random Read/Write.

300 ມາດຕະຖານພະນັກງານຄວາມຮູ້ + 22 IOPS ຕໍ່ຜູ້ໃຊ້

ໃນການທົດສອບເບື້ອງຕົ້ນ, fio ໄດ້ຖືກພົບເຫັນວ່າບັງຄັບໃຊ້ CPU ທີ່ສໍາຄັນໃນເຄື່ອງ virtual. ນີ້ເຮັດໃຫ້ CPU overload ຢ່າງໄວວາຂອງ hosts ແລະມີຜົນກະທົບຢ່າງຫຼວງຫຼາຍຕໍ່ການເຮັດວຽກຂອງລະບົບທັງຫມົດ.

ການໂຫຼດ CPU ຂອງເຈົ້າພາບ:




ໃນເວລາດຽວກັນ, ຄວາມລ່າຊ້າຂອງລະບົບການເກັບຮັກສາຍັງເພີ່ມຂຶ້ນຕາມທໍາມະຊາດ:


ການຂາດພະລັງງານຄອມພິວເຕີໄດ້ກາຍເປັນທີ່ສໍາຄັນປະມານ 240 ຜູ້ໃຊ້:


ເນື່ອງຈາກຜົນໄດ້ຮັບທີ່ໄດ້ຮັບ, ມັນໄດ້ຖືກຕັດສິນໃຈທີ່ຈະດໍາເນີນການທົດສອບທີ່ມີ CPU ຫນ້ອຍລົງ.

230 ມາດຕະຖານພະນັກງານຫ້ອງການ + 22 IOPS ຕໍ່ຜູ້ໃຊ້

ເພື່ອຫຼຸດຜ່ອນການໂຫຼດໃນ CPU, ປະເພດການໂຫຼດຂອງພະນັກງານຫ້ອງການໄດ້ຖືກເລືອກ, ແລະ 22 IOPS ຂອງການໂຫຼດສັງເຄາະໄດ້ຖືກເພີ່ມເຂົ້າໃນແຕ່ລະກອງປະຊຸມ.

ການທົດສອບໄດ້ຖືກຈໍາກັດພຽງແຕ່ 230 sessions ເພື່ອບໍ່ໃຫ້ເກີນການໂຫຼດ CPU ສູງສຸດ.

ການທົດສອບໄດ້ຖືກດໍາເນີນການກັບຜູ້ໃຊ້ທີ່ເຮັດວຽກເປັນເວລາ 10 ຊົ່ວໂມງເພື່ອກວດເບິ່ງຄວາມຫມັ້ນຄົງຂອງລະບົບໃນລະຫວ່າງການດໍາເນີນງານໃນໄລຍະຍາວຢູ່ໃກ້ກັບການໂຫຼດສູງສຸດ.

ຂໍ້ມູນສະຖິຕິ VSImax:


VSIbase = 918 ms, VSI Threshold ບໍ່ຮອດ.

VSImax ຂໍ້ມູນສະຖິຕິລະອຽດ:


ເສັ້ນສະແດງສະແດງໃຫ້ເຫັນວ່າບໍ່ມີການເສື່ອມໂຊມການປະຕິບັດທີ່ສັງເກດເຫັນຕະຫຼອດການທົດສອບທັງຫມົດ.

ສະຖິຕິການໂຫຼດ CPU:




ເມື່ອປະຕິບັດການທົດສອບນີ້, ການໂຫຼດຢູ່ໃນ CPU ຂອງເຈົ້າພາບແມ່ນເກືອບສູງສຸດ.

ສະຖິຕິການໂຫຼດລະບົບການເກັບຮັກສາຈາກການຕິດຕາມ SimpliVity:


ການປະຕິບັດລະບົບການເກັບຮັກສາຍັງຄົງຄືກັນຕະຫຼອດການທົດສອບ.

ການໂຫຼດໃນລະບົບການເກັບຮັກສາໃນລະຫວ່າງການທົດສອບແມ່ນປະມານ 6 IOPS ໃນອັດຕາສ່ວນ 500/60 (40 IOPS ອ່ານ, 3 IOPS ຂຽນ), ເຊິ່ງແມ່ນປະມານ 900 IOPS ຕໍ່ສະຖານີເຮັດວຽກ.

ເວລາຕອບສະຫນອງສະເລ່ຍ 3 ms ສໍາລັບການຂຽນແລະສູງເຖິງ 1 ms ສໍາລັບການອ່ານ.

ຜົນໄດ້ຮັບ

ເມື່ອຈໍາລອງການໂຫຼດຕົວຈິງຢູ່ໃນໂຄງສ້າງພື້ນຖານ HPE SimpliVity, ຜົນໄດ້ຮັບໄດ້ຮັບການຢືນຢັນຄວາມສາມາດຂອງລະບົບເພື່ອສະຫນັບສະຫນູນ desktop virtual ຂອງຢ່າງຫນ້ອຍ 300 Full Clone machines ໃນຄູ່ຂອງຂໍ້ SimpliVity. ໃນເວລາດຽວກັນ, ເວລາຕອບສະຫນອງຂອງລະບົບການເກັບຮັກສາໄດ້ຖືກຮັກສາໄວ້ໃນລະດັບທີ່ດີທີ່ສຸດຕະຫຼອດການທົດສອບທັງຫມົດ.

ພວກເຮົາມີຄວາມປະທັບໃຈຫຼາຍໂດຍວິທີການຂອງການທົດສອບຍາວແລະການປຽບທຽບການແກ້ໄຂກ່ອນການປະຕິບັດ. ພວກເຮົາສາມາດທົດສອບປະສິດທິພາບສໍາລັບວຽກງານຂອງທ່ານເຊັ່ນດຽວກັນຖ້າຫາກວ່າທ່ານຕ້ອງການ. ລວມທັງການແກ້ໄຂ hyperconverged ອື່ນໆ. ລູກຄ້າທີ່ໄດ້ກ່າວມາໃນປັດຈຸບັນກໍາລັງສໍາເລັດການທົດສອບໃນການແກ້ໄຂອື່ນໃນຂະຫນານ. ໂຄງສ້າງພື້ນຖານໃນປະຈຸບັນຂອງມັນແມ່ນພຽງແຕ່ເຮືອ PCs, ໂດເມນແລະຊອບແວໃນແຕ່ລະບ່ອນເຮັດວຽກ. ການຍ້າຍໄປ VDI ໂດຍບໍ່ມີການທົດສອບແມ່ນ, ແນ່ນອນ, ຂ້ອນຂ້າງຍາກ. ໂດຍສະເພາະ, ມັນເປັນການຍາກທີ່ຈະເຂົ້າໃຈຄວາມສາມາດທີ່ແທ້ຈິງຂອງກະສິກໍາ VDI ໂດຍບໍ່ມີການຍົກຍ້າຍຜູ້ໃຊ້ທີ່ແທ້ຈິງກັບມັນ. ແລະການທົດສອບເຫຼົ່ານີ້ຊ່ວຍໃຫ້ທ່ານສາມາດປະເມີນຄວາມສາມາດທີ່ແທ້ຈິງຂອງລະບົບສະເພາະໃດຫນຶ່ງໄດ້ຢ່າງໄວວາໂດຍບໍ່ຈໍາເປັນຕ້ອງມີສ່ວນຮ່ວມກັບຜູ້ໃຊ້ທົ່ວໄປ. ນີ້ແມ່ນບ່ອນທີ່ການສຶກສານີ້ມາຈາກ.

ວິທີການທີ່ສໍາຄັນທີສອງແມ່ນວ່າລູກຄ້າທັນທີທັນໃດມຸ່ງຫມັ້ນທີ່ຈະປັບຂະຫນາດທີ່ເຫມາະສົມ. ໃນທີ່ນີ້ທ່ານສາມາດຊື້ເຄື່ອງແມ່ຂ່າຍເພີ່ມເຕີມແລະເພີ່ມກະສິກໍາ, ຕົວຢ່າງ, ສໍາລັບຜູ້ໃຊ້ 100 ຄົນ, ທຸກສິ່ງທຸກຢ່າງແມ່ນຄາດຄະເນໃນລາຄາຜູ້ໃຊ້. ຕົວຢ່າງ, ເມື່ອພວກເຂົາຕ້ອງການເພີ່ມຜູ້ໃຊ້ 300 ຄົນ, ພວກເຂົາຈະຮູ້ວ່າພວກເຂົາຕ້ອງການສອງເຄື່ອງແມ່ຂ່າຍໃນການຕັ້ງຄ່າທີ່ກໍານົດໄວ້ແລ້ວ, ແທນທີ່ຈະພິຈາລະນາປັບປຸງໂຄງສ້າງພື້ນຖານທັງຫມົດຂອງພວກເຂົາຄືນໃຫມ່.

ຄວາມເປັນໄປໄດ້ຂອງສະຫະພັນ HPE SimpliVity ແມ່ນຫນ້າສົນໃຈ. ທຸລະກິດໄດ້ຖືກແຍກອອກຕາມພູມສັນຖານ, ສະນັ້ນມັນເຮັດໃຫ້ຄວາມຮູ້ສຶກທີ່ຈະຕິດຕັ້ງຮາດແວ VDI ແຍກຕ່າງຫາກຂອງທ່ານເອງຢູ່ໃນຫ້ອງການທີ່ຫ່າງໄກ. ໃນສະຫະພັນ SimpliVity, ແຕ່ລະເຄື່ອງ virtual ແມ່ນ replicated ຕາມຕາຕະລາງທີ່ມີຄວາມສາມາດໃນການເຮັດເລື້ມຄືນລະຫວ່າງກຸ່ມຫ່າງໄກສອກຫຼີກທາງພູມິສາດຢ່າງໄວວາແລະບໍ່ມີການໂຫຼດຢູ່ໃນຊ່ອງທາງ - ນີ້ແມ່ນການສໍາຮອງຂໍ້ມູນທີ່ສ້າງຂຶ້ນໃນລະດັບທີ່ດີຫຼາຍ. ເມື່ອ replicating VMs ລະຫວ່າງສະຖານທີ່, ຊ່ອງທາງແມ່ນໃຊ້ຫນ້ອຍທີ່ສຸດເທົ່າທີ່ເປັນໄປໄດ້, ແລະນີ້ເຮັດໃຫ້ມັນເປັນໄປໄດ້ທີ່ຈະສ້າງສະຖາປັດຕະຍະກໍາ DR ທີ່ຫນ້າສົນໃຈຫຼາຍໃນທີ່ປະທັບຂອງສູນຄວບຄຸມດຽວແລະຊໍ່ຂອງສະຖານທີ່ເກັບຮັກສາການກະຈາຍ.

ສະຫະພັນ

ທັງຫມົດນີ້ຮ່ວມກັນເຮັດໃຫ້ມັນເປັນໄປໄດ້ທີ່ຈະປະເມີນດ້ານການເງິນໃນລາຍລະອຽດທີ່ຍິ່ງໃຫຍ່, ແລະ superimpose ຄ່າໃຊ້ຈ່າຍຂອງ VDI ໃນແຜນການຂະຫຍາຍຕົວຂອງບໍລິສັດ, ແລະເຂົ້າໃຈວິທີການແກ້ໄຂໄວແລະວິທີການທີ່ຈະເຮັດວຽກ. ເນື່ອງຈາກວ່າ VDI ໃດແມ່ນການແກ້ໄຂທີ່ສຸດທ້າຍຈະຊ່ວຍປະຢັດຊັບພະຍາກອນຫຼາຍ, ແຕ່ໃນເວລາດຽວກັນ, ສ່ວນຫຼາຍອາດຈະ, ໂດຍບໍ່ມີຄ່າໃຊ້ຈ່າຍປະສິດທິພາບໃນການປ່ຽນແປງມັນພາຍໃນ 5-7 ປີຂອງການນໍາໃຊ້.

ໂດຍທົ່ວໄປ, ຖ້າທ່ານມີຄໍາຖາມໃດໆທີ່ບໍ່ແມ່ນສໍາລັບຄໍາຄິດຄໍາເຫັນ, ຂຽນຫາຂ້ອຍທາງອີເມວ [email protected].

ແຫຼ່ງຂໍ້ມູນ: www.habr.com